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

Howard Chu hyc
Sun May 30 20:41:00 CEST 2010


Luca Abeni wrote:
> On Fri, 2010-05-28 at 21:12 -0700, Howard Chu wrote:
>> In particular, h264_mp4toannexb_bsf is not relevant. RTP sends raw NAL units,
>> not H.264 Annex B byte streams.
>
> Sigh... I give up :(
> In a previous email I already explained that the RTP muxer gets full
> frames as input, and needs to split them in NALs.

Yes, understood. I just don't believe that the right solution for AVC format 
frames is to copy them into a newly malloc'd buffer so that a startcode can be 
inserted which is just going to be stripped off again.

>>>> Indeed. These functions ought to be collected into a single place. I
>>>> believe the "clean split" between decoder, muxer, and network layer
>>>> you're alluding to is a distinct disadvantage here. Anything that
>>>> touches H264 has to understand how to parse NALUs; that code belongs in
>>>> a single place usable from all of those layers.
>>>
>>> So, a helper function doing this can be introduced, and used in all the
>>> relevant places...
>>
>> I've written such a helper function here. However, I haven't found any other
>> places where it is useful yet. In particular, factoring out the similar code
>> in h264.c decode_nal_units() actually makes that function more complicated and
>> less efficient, so it was best to just leave that as-is.
>
> I fully agree, here. I do not think this particular helper function is
> not going in the right direction.

> This function seems to make everything more complex. What you
> need to do is to factorise the code you copied from h264.c, not to
> introduce this new function.

I've tried to reduce the duplication as much as possible. But if you refer 
back to the previous patch I posted

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100518/b5cd4c64/attachment.txt

Only 3 lines of code in rtpenc.c were copied literally from h264.c. Is it 
really worth the trouble to factorize that into a function? I think not.

The rest of the parsing logic is deeply entangled in the surrounding loop 
constructs. I guess it could be factorized if a callback function is passed in 
to take some action after a unit has been parsed. Otherwise, separating it 
from the containing logic is just a mess.
-- 
    -- Howard Chu
    CTO, Symas Corp.           http://www.symas.com
    Director, Highland Sun     http://highlandsun.com/hyc/
    Chief Architect, OpenLDAP  http://www.openldap.org/project/



More information about the ffmpeg-devel mailing list