<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><br>I have no problems receiving 150+Kb K-frames over UDP with Live555. What I do is increase socket receive buffer and make sure I don't block <font color="#040004"><font color="#040004">CUMediaSink</font></font>::<font color="#040004"><font color="#040004">continuePlaying() for too long. In fact, all my implementation of CUMediaSink<font color="#000000">::</font><font color="#040004"><font color="#040004">continuePlaying() does is move received sample into my private queue. All sample processing is done on separate thread.</font></font></font></font><BR><font color="#040004"></font> <BR><font color="#040004">Krishna.</font><BR><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: jshanab@smartwire.com<br>To: live-devel@ns.live555.com<br>Date: Thu, 2 May 2013 21:37:30 +0000<br>Subject: Re: [Live-devel] H264 dropped P frames<br><br><style><!--
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal {
font-size:12.0pt;
font-family:"Times New Roman","serif";
}
.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink {
color:blue;
text-decoration:underline;
}
.ExternalClass span.ecxMsoHyperlinkFollowed {
color:purple;
text-decoration:underline;
}
.ExternalClass span.ecxapple-tab-span {
}
.ExternalClass span.ecxapple-style-span {
}
.ExternalClass span.ecxEmailStyle19 {
font-family:"Calibri","sans-serif";
color:#1F497D;
}
.ExternalClass .ecxMsoChpDefault {
font-size:10.0pt;
}
.ExternalClass div.ecxWordSection1 {
}
--></style><div class="ecxWordSection1"><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>Thanks. I do understand how the event model works (Quite eloquent BTW).</span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'> </span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>The fact that it throws away complete NAL units if a piece of a fragment has loss explains why it appears as dropping NALs.</span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'> </span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>Here is the only part I cannot figure out. Why does it not lose any packets if I use OpenRtsp on the command line.</span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>Why does VLC have no problem with the video live.</span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'> </span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>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.</span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>21k for a key frame 1K-2K for the P-Frames 30fps with a GOP size that varies but averages 38. </span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>My class is almost identical to the PLayCommon.cpp + OpenRtsp.cpp code. I have a memorySink, filter, and async file writing queue. </span></p><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'> </span></p> <BR>
<BR>
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.<BR><br><div><div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentColor currentColor; padding: 3pt 0in 0in;"><p class="ecxMsoNormal"><b><span style='font-family: "Tahoma","sans-serif"; font-size: 10pt;'>From:</span></b><span style='font-family: "Tahoma","sans-serif"; font-size: 10pt;'> 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</span></p></div></div><p class="ecxMsoNormal"> </p><div><blockquote><div><div><p class="ecxMsoNormal"><span style='color: rgb(31, 73, 125); font-family: "Calibri","sans-serif"; font-size: 11pt;'>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></span></p></div></div></blockquote><div><p class="ecxMsoNormal"> </p></div><p class="ecxMsoNormal">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.</p></div><div><p class="ecxMsoNormal"> </p></div><div><p class="ecxMsoNormal">In any case, everyone (and especially you :-) needs to read and understand this sentence that's at the end of the FAQ entry:</p></div><div><p class="ecxMsoNormal"> </p></div><div><p class="ecxMsoNormal">**********</p></div><div><div><p class="ecxMsoNormal"><span class="ecxapple-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. </p></div><div><div><p class="ecxMsoNormal">**********</p></div></div></div><p class="ecxMsoNormal"> </p><div><p class="ecxMsoNormal"><span class="ecxapple-style-span"><span style='color: black; font-family: "Helvetica","sans-serif"; font-size: 13.5pt;'>Ross Finlayson</span></span><span style='color: black; font-family: "Helvetica","sans-serif"; font-size: 13.5pt;'><br><span class="ecxapple-style-span">Live Networks, Inc.</span><br><span class="ecxapple-style-span"><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span></span> </p></div><p class="ecxMsoNormal"> </p></div><br>_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel</div> </div></body>
</html>