<html><head><style type='text/css'> P {padding:0px; margin:2px; border:0px;font-size:13px;font-family:'arial';} body {padding:5px; margin:0px; border:0px;font-size:13px;font-family:'arial';} td {font-size:12px;font-family:'gulim';} </style></head><body><table width=99% align=center height='100'><tr valign=top><td><font size=2><P>Hi Ross, thank you for your response,</P>
<P> </P>
<P>All our boards IPNC DM368, DM8148 that use Live555 for streaming commit that problem. But when I use VLC to playback the HD H.264 from a streaming board I don't get that kinda error. (Actually I don't know what kind of streaming libraries they use inside ). When I use RTSPClient to retrieve and save that stream to a .h264 file and use live555 to stream out that file over rtsp, at the client side I also use VLC player to playback then the errors happen. I don't know but are you sure this problem is not caused by Live555?</P>
<P> </P>
<P>BTW, I read the VLC source code then I find out that they have a module call 'access->mms->mmstu.h' which is used to initially retrieve data from the server has a buffer of 100000 bytes. I increase that buffer to have enough room for incoming I-frames. But it doesn't help me out. Do you have any ideas?</P>
<P> </P>
<P>I appreciate your help.</P>
<P><BR> </P>
<BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">Re: [Live-devel] Errors when streaming HD H.264 using Live555<BR><BR><X-BODY style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV>VLC is not our software, and problems with VLC should be posted on a VLC mailing list - not here. However, in this case, I know the answer to your question.</DIV>
<DIV><BR></DIV>
<DIV>Your problem is that your stream's I-frames are too large. VLC uses an initial buffer size of 100,000 bytes when receiving data. If a data frame (in this case, your stream's first I-frame) is larger than this, then the remaining data will be truncated (i.e., lost). VLC recovers from this by doubling the size of the buffer for receiving future frames, but it cannot recover the data that was lost from the first I-frame.</DIV>
<DIV><BR></DIV>
<DIV>The solution is to not send very large I-frames as single NAL units. Instead, you should encode these I-frames into multiple 'slice' NAL units. (Alternatively, if you can't do that, then try to encode I-frame NAL units to be smaller than 100,000 bytes.)</DIV><BR><BR>
<DIV apple-content-edited="true"><SPAN style="LINE-HEIGHT: normal; WIDOWS: 2; TEXT-TRANSFORM: none; FONT-VARIANT: normal; FONT-STYLE: normal; TEXT-INDENT: 0px; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT-FAMILY: Helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); FONT-WEIGHT: normal; WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" class=Apple-style-span><SPAN style="LINE-HEIGHT: normal; WIDOWS: 2; TEXT-TRANSFORM: none; FONT-VARIANT: normal; FONT-STYLE: normal; TEXT-INDENT: 0px; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT-FAMILY: Helvetica; WHITE-SPACE: normal; ORPHANS: 2; COLOR: rgb(0,0,0); FONT-WEIGHT: normal; WORD-SPACING: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" class=Apple-style-span>Ross Finlayson<BR>Live Networks, Inc.<BR><A href="http://www.live555.com/">http://www.live555.com/</A></SPAN></SPAN> </DIV><BR></BLOCKQUOTE></font></td></tr></table><br>
<img id='mailexp' width=0 heigh=0 border=0 src='http://mail.ssu.ac.kr/mail/mail_receipt_check.jsp?ukey=52aad30b3fdb951e1899de3c&userid=phuocpham&mhost=ssu.ac.kr&ahost=d0001'></body></html>