[FFmpeg-devel] [PATCH] RTP H.264 / AVC support
Wed Jun 16 09:26:51 CEST 2010
Luca Abeni wrote:
> 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
> 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& 0x03) + 1;
> what do you think?
-- 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