[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