[FFmpeg-devel] [PATCH] RTP H.264 / AVC support

[Howard Chu]

Luca Abeni wrote:
> Hi,
>
> On 06/16/2010 12:40 AM, Howard Chu wrote:
> [...]
>>> Ok; good to see that we are finally converging :)
>>> I do not like some of your changes to the sdp.c patch, but to find a
>>> tradeoff I think I can live with them.
>>> I'll split the h264_mp4toannexb_bsf.c part, and repost it for review;
>>> then, when it is accepted I'll commit the sdp.c part (after adding a
>>> check for "bsfc == NULL", which is still missing).
>>>
>>> After that, we can move to the rtpenc* part (yesterday I tried my
>>> ff_avc_find_startcode_avc() idea, and I think it can allow to simplify
>>> the code a little bit). In particular, I am still not sure about the
>>> need for the "NALP" data type.
>>
>> Thanks for getting the sdp part fixed. What do we need to do now for
>> rtpenc?
>
> I think you started discussing with Michael about exporting the NAL
> parsing code from h264.c, right?

Oh, actually I was waiting to see what idea you had first. You mentioned 
above, an idea about ff_avc_find_startcode_avc(). You've already seen what I 
came up with...

> You need to find a way to use that code without duplications; then,
> we can use it in rtpenc.c (the goal is to have a patch as simple
> as possible - so, I still think that introducing a NALP data type
> is not a good idea - that reuses as much code as possible).
>
> I was going to commit the rtpenc.* part of the patch (adding
> nal_length_size to struct RTPMuxContext), but then I noticed:
> 	s->nal_length_size = ((*(((char*)(st->codec->extradata))+4))&0x03)+1;
> and I am wondering why casting extradata to (char *)... I think this
> can be simplifed to
> 	s->nal_length_size = (st->codec->extradata[4]&  0x03) + 1;
> what do you think?

Sounds good.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/