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

Martin Storsjö martin
Tue Jun 1 10:57:17 CEST 2010

On Tue, 1 Jun 2010, Luca Abeni wrote:

> On 06/01/2010 09:16 AM, Howard Chu wrote:
> [...]
> > > Moreover, the code introduced in ff_rtp_send_h264() and in
> > > sdp.c:extradata2psets()
> > > did the same thing (split an "AVC format" frame in NALs) using slightly
> > > different code (compare "len = (len<< 8) | *r++;" with "nalsize =
> > > AV_RB16(r);").
> > > 
> > > Regarding the new patch: as I said, I do not think this
> > > ff_avc_parse_nal_units_inplace() is the correct thing to simplify the
> > > code.
> > > (moreover, I am still convinced that this function does the same things
> > > done by the h264.c code I mentioned above).
> > 
> > OK, this set of patches consolidates the code using a callback function.
> Regarding the h264.c modifications, I cannot comment on them, but I do not
> like this callback approach. Did you try the approach I suggested?
> The rtpenc.{c,h} part of the patch is ok.
> The rtpenc_h264.c part of the patch depends on the h264.c patch; if someone
> approves that one, the rtpenc_h264.c patch looks ok (modulo the fact that I
> do not know if libavformat can use ff_* functions defined in libavcodec).

No, lavf shouldn't use ff_* prefixed functions from libavcodec. (It 
currently uses a few, but we shouldn't be adding more of them.) Either 
they're proper, public functions in the external libavcodec API, or lavf 
shouldn't use them. People packaging them as separate, shared libraries 
will experience this as a part of the ABI between the two modules 
regardless of if it's public or not, and will break if it is 
removed/changed later.

// Martin

More information about the ffmpeg-devel mailing list