<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><base href="x-msg://6331/"><style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:'
        panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.apple-tab-span
        {mso-style-name:apple-tab-span;}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks. I do understand how the event model works (Quite eloquent BTW).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The fact that it throws away complete NAL units if a piece of a fragment has loss explains why it appears as dropping NALs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Here is the only part I cannot figure out. Why does it not lose any packets if I use OpenRtsp on the command line.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Why does VLC have no problem with the video live.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Almost like the sender is not following standard flow control and only a simple flat out copy will grab it fast enough. This is not high resolution or large NALS.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>21k for a key frame 1K-2K for the P-Frames 30fps with a GOP size that varies but averages 38. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>My class is almost identical to the PLayCommon.cpp + OpenRtsp.cpp code. I have a memorySink, filter, and async file writing queue. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><P> </P>
<P> </P>
<P>This message and any attachments contain confidential and proprietary 
information, and may contain privileged information, belonging to one or more 
affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege 
is waived by this transmission. Unauthorized use, copying or disclosure of such 
information is prohibited and may be unlawful. If you receive this message in 
error, please delete it from your system, destroy any printouts or copies of it, 
and notify the sender immediately by e-mail or phone.</P><br><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> live-devel-bounces@ns.live555.com [mailto:live-devel-bounces@ns.live555.com] <b>On Behalf Of </b>Ross Finlayson<br><b>Sent:</b> Thursday, May 02, 2013 4:04 PM<br><b>To:</b> LIVE555 Streaming Media - development & use<br><b>Subject:</b> Re: [Live-devel] H264 dropped P frames<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Could it be that the packets are incorrect and live555 cannot find the beginning and end, so it doesn’t clear out the buffer? Then it hits the max, dumps it and starts over.</span><span style='font-family:"&apos","serif"'><o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>No, but note that if - as with all payload formats - if one frame (in this case, one H.264 NAL unit) is fragmented over multiple RTP packets, then if any one of these RTP packets gets lost, then the entire NAL unit will get discarded.  That's why - yet again - H.264 encoders should not create excessively large NAL units.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In any case, everyone (and especially you :-) needs to read and understand this sentence that's at the end of the FAQ entry:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>**********<o:p></o:p></p></div><div><div><p class=MsoNormal><span class=apple-tab-span>            </span>It's important to understand that because a LIVE555 Streaming Media application runs as a single thread (never writing to, or reading from, sockets concurrently), if packet loss occurs, then it MUST be happening either (i) on the network, or (ii) in the operating system of the sender or receiver. There's nothing in our code that can be 'losing' packets. <o:p></o:p></p></div><div><div><p class=MsoNormal>**********<o:p></o:p></p></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal><span class=apple-style-span><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>Ross Finlayson</span></span><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'><br><span class=apple-style-span>Live Networks, Inc.</span><br><span class=apple-style-span><a href="http://www.live555.com/">http://www.live555.com/</a></span></span> <o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>