[Live-devel] UDP packets appear to be empty, forcing switch to TCP in VLC

[Ross Finlayson]

> 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.

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.


> 			boost::this_thread::sleep(boost::posix_time::milliseconds(20));

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.

“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.

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.

See, for example, the model code in “liveMedia/DeviceSource.cpp”.

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.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150508/04d8b138/attachment.html>