<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">I spent some time going through older posts on this mailing list and noticed the requirement that we not send multiple NALs to the H264VideoStreamDiscreteFramer. I put in a test looking for multiple NALs by matching the 0x00000001 start code and found that most encoded frame buffers have two NALs-- the first one appears to be SPS/PPS information. So I added code to split these NALs and deliver them one-at-a-time without the start sequence. The result was no video over TCP or UDP even though the NALs looked correct.</div></div></div></div></div></blockquote><div><br class=""></div>Nonetheless, feeding a single NAL unit at a time (without start code) to “H264VideoStreamDiscreteFramer” is the correct thing to be doing, if you want a standards-compliant stream that all receivers will be able to handle.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><span class="" style="white-space: pre;"> </span>boost::this_thread::sleep(boost::posix_time::milliseconds(20));</div></div></div></div></blockquote><div><br class=""></div>That’s a big problem: You’re blocking the *entire* server (including all streaming) while you wait for a new encoded H.264 NAL unit to arrive.</div><div><br class=""></div><div>“doGetNextFrame()” (and/or the functions that it calls) should not block at all. Remember that the server is single-threaded and event-driven. If - when you call “doGetNextFrame()” - no frame (or, in this case, “H.264 NAL unit”) is currently available to be delivered, then you should immediately return from “doGetNextFrame()” (so that the code will immediately get back to the event loop). DO NOT ‘block’, waiting for a new frame to arrive.</div><div><br class=""></div><div>The way that most people implement this is to have their encoder use a separate thread that does not call *any* LIVE555 code (except for calls to “triggerEvent()”). Then, the implementation of “doGetNextFrame()” (in the LIVE555 thread) uses ‘event triggers’ to get notified (via the event loop) of the availability of a new frame (“NAL unit”) to be delivered.</div><div><br class=""></div><div>See, for example, the model code in “liveMedia/DeviceSource.cpp”.</div><div><br class=""></div><div>This doesn’t explain why you were able to stream over TCP but not over UDP - but it is a problem that you’ll need to fix.</div><br class=""><div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; 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; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; 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; ">Ross Finlayson<br class="">Live Networks, Inc.<br class=""><a href="http://www.live555.com/" class="">http://www.live555.com/</a></span></span>
</div>
<br class=""></body></html>