[Live-devel] H264 RTP multicast

[Goran Ambardziev]

Ross, thanks a lot for your help!

> From the encoder, I get buffers with multiple NAL Units. NAL Units are all with 0x00000001 start codes. I strip this codes from the buffers, break the buffer and send the packets as separate NAL units.

>> Yes, this is correct (provided that you deliver NAL units to the downstream "H264VideoStreamDiscreteFramer" one at a time)

Yes, when I receive the buffer, I look for start codes, break the buffer and send NALU's to the downstream "H264VideoStreamDiscreteFramer" one by one (off course, without start codes).

In this situation, in VLC I just get the first image and the following error(s):
	direct3d warning: trying surface pixel format: YV12
	main error: ES_OUT_RESET_PCR called
	
In openRTSP, which I start to create mp4 files with 5 seconds length (openRTSP -4 -P 5 -w 720 -h 576 -f 25 rtsp://...) I get mp4 files, which VLC reports that are 40 seconds long (also MediaInfo) and not a single frame can be decoded.

Now, this is the first approach I'm trying.

> Also, I get NAL Units with fragments.

>> What specifically do you mean by "fragments" here?  Do you mean slices?  I.e., are you talking about NAL units that each represent just one 'slice' of a frame (picture)?  If so, then yes, we support this.  You can treat these NAL units just like any other; deliver them (one at a time) to the downstream "H264VideoStreamDiscreteFramer".

>> Or are you instead referring to multiple chunks of data (that are *not* NAL units themselves) that, if combined together, form a single (large) NAL unit?  If so, then you *must not* deliver these chunks of data separately.  Instead, you *must* combine these chunks into a single NAL unit, and deliver this completely (without the 'start code', of course) to the downstream "H264VideoStreamDiscreteFramer").

I'm not all that much familiar with H264 specification or the inner workings of the encoder. I based my code on a working RTSP server (wrapped as a DirectShow filter, from here: http://www.gdcl.co.uk/2013/05/16/RTSP-Jukebox.html).

Now, in that code, there's a NAL unit parser, which my code is based on. The code there presumes that:

const int max_packet_size = 1514 - 42; // observed from Wireshark
const int rtp_header_size = 12;

static int SinglePacketSize()	{ return max_packet_size - rtp_header_size; }
static int FragmentSize()	{ return SinglePacketSize() -2; }

If the NALU size is <= SinglePacketSize, it gets forwarded as it is, but when NALU is bigger then SinglePacketSize, then the code fragments the buffer by the value of FragmentSize. So if NALU buffer size is 2 x SinglePacketSize, then it will fragment it to buffers with FragmentSize size and send it downstream one by one.
Now, I don't know why is this, but this RTSP server (unicast) is working fine with the Media Foundation H264 Encoder and playing fine in VLC and/or other Streaming Clients.
If I try this approach in my code, in VLC I get the error: "live555 warning: unsupported NAL type for H264" and after that, "avcodec warning: cannot decode one frame (1614 bytes)"
In openRTSP the same situation as in previous case.

This is the second approach I'm trying.

> Another thing to be aware of is that if a NAL unit can be very large, you may need to change the value of "OutPacketBuffer::maxSize" (in "testH264VideoStreamer.cpp" from 100000 (bytes) to something larger.

The max size of the NALU packets I'm forwarding to live555 isn't bigger then 4000-5000 bytes.

Thanks and sorry for the long post,
Goran.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140328/2f5b96ee/attachment.html>