[Live-devel] H264 RTP multicast

[Goran Ambardziev]

Ross (and everybody),

Sorry for wasting your time!

live555 can handle NAL units as I send them, and there's no need for 
fragmentation (as I've mentioned before). My error was in timing the 
packets in my H264FramedSource class. I feel so silly now.

Thanks,
Goran.

On 28.03.2014 23:49, Goran Ambardziev wrote:
> 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/20140329/0f9616fd/attachment.html>