[Ffmpeg-devel] RTP patches & RFC

Ryan Martell rdm4
Thu Oct 12 23:29:09 CEST 2006

On Oct 12, 2006, at 1:42 PM, Derk-Jan Hartman wrote:

> On 12-okt-2006, at 15:59, Ryan Martell wrote:
>> The other part of the issue is that the rtp stuff wouldn't start  
>> until the extradata for the codec was filled in; the only way to  
>> fill it in (I thought) was giving it a valid AvC block, which is  
>> why I ended up going down that path.  I'll reinvestigate.
> if you use avcC in the extradata, libavcodec expects lengthsize  
> header prepended nalunits. But if you use startcodes, the extradata  
> needs to use those as well.
> Take the SPS/PPS from the SDP and prepend them with 4 byte  
> startcodes ( 0 0 0 1 ) and put them in the extradata. SPS's before  
> the PPS's. Then use startcodes in the bitstream, and it should be  
> just fine.
> The level info is information you don't need to pass, since they  
> are actually byte 1,2,3 from the SPS (starting from byte 0). The  
> lengthsize is not required because you use startcodes.
> IDR/SPS/PPS nals require 0 0 0 1 as startcode, all the other nals  
> require 0 0 1. Note that an arbitrary number of 0's prepended to  
> the startcodes is allowed. In theory you can prepend 0 0 0 1 for  
> all nals, but it's not known how well the other h264 products  
> handle that.

Thanks Derk, I had figured that out.

My code allows you to specify if you want to precede it with length  
bytes (then it will fill in the extradata with avcc block), or start  
sequence (in which case it will fill it in with sps/pps).  This  
appears to work currently.  It's interesting though, as I was not  
filling SPS/PPS nals with 0001, only 001.

On Oct 12, 2006, at 5:29 AM, Michael Niedermayer wrote:
> Hi
> On Wed, Oct 11, 2006 at 10:41:36PM -0500, Ryan Martell wrote:
> [...]
>>> either way you should set AVStream->need_parsing=1 and leave the
>>> merging
>>> of packets to the AVParser
>> Okay, sorry to be dense about this, but I'm still confused.  The
>> packets that come over rtp have their size indicated in various ways,
>> depending on the packet.  That information is NOT in the NAL, and the
>> NAL is NOT preceeded by the start sequence.  So what I was doing was
>> converting them to AvC style (preceded by length) packets.  This is
> iam more in favor of adding the startcode prefix instead of the length
> i dont think the avc style length stuff is supported by our AVParser

I changed the code, so that in my init routine you can specify if you  
want the bitstream version or the avcc version.  Both work, as long  
as I don't set needs_parse= 1 for the stream.  When I do that, I  
never get past the setup code (I don't know why).  (Maybe it's  
because I only had 001 instead of 0001 on the sps/pps packets, from  
derk above?).  This is the same issue i was having when i first  
started this, where there was no data in the extradata field, it  
wouldn't get to the point where it showed the stream types.

> it doesnt need the pts for this, it will analize the nal units

This doesn't work for me; probably because I am not using the  
AVParser yet?

> [...]
>> I'm also having to get the rtsp rtcp packet (receiver reports)
>> working, because that's why the server is cutting me off after two
>> minutes.
> great

I have this working, but I can't send on the url_port.  I was opening  
it RDWR (I changed it back for the patches), and it was still giving  
me the -2 error.  Something must be closing the connection, or they  
must be half open (for tcp)...

>> Finally, I can give a Blocksize parameter to the server on RTSP
>> initial handshake.  With this, I could specify a maximum packet size,
>> which would allow me to preallocate all of my internal packets (using
>> around 2k buffers each, since MTU is 1500 by default).  This would
>> basically mean that there would be initial memory allocation for
>> packets until I had enough in the packet pool, and I could retire
>> them to another linked list and pull them from there.  So there would
>> be no malloc's after an initial startup period.  I think this would
>> be a good thing, but I'm not sure how the rest of FFMPEG feels about
>> memory allocation.  Is this a better approach?
> yes, less *malloc() and *free() is better

This is not done yet; but I still plan on doing it.

>> /* ---------------- code */
>> void *new_h264_extradata()
> non static functions need some av_ or ff_ prefix to avoid namespace  
> clashes

All my functions are static (and made available through a parameter  
block).  I tried to keep the other naming conventions the same for  
other visible functions (rtsp_ or rtp_ if I had to add some for  
those).  I'm not happy with rtsp_get_word and rtsp_get_word_sep, but  
i needed them in two places..

>>     //    fprintf(stderr, "Buf: %p Length: %d\n", buf, len);
> this should be av_log or removed (and that of course applies to all  
> these
> // *printf lines

I left a few fprintf's in, but they are all commented out.  this was  
just since it's still a work in progress. (old habits)

> stuff starting with underscores is reserved in c
> and comments should be doxygen compatible
> and the enum should get a name which is used in the types which are

doxygen is pretty cool; never used it before.

Here's all of my code; I didn't really want to get into rtp/rtsp that  
much, but I had to.  It's still a work in progress (it times out  
after 2 minutes on Darwin Streaming Server, because i don't send the  
rtcp packets).  But it's a start.  I'd like to get this out there, in  
case others need it, but I have some other requirements that might  
pull me away from this for the next few days/week.

All the jitter calculation/rtp sequence updating algorithms come from  
the rtp rfc.

Michael, thanks for the code review, and hopefully this is more  
inline with the other code.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061012/6b6b52b6/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtp_h264.c
Type: application/octet-stream
Size: 39493 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061012/6b6b52b6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtp_h264.h
Type: application/octet-stream
Size: 955 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061012/6b6b52b6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtp_internal.h
Type: application/octet-stream
Size: 4438 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061012/6b6b52b6/attachment-0002.obj>

More information about the ffmpeg-devel mailing list