[FFmpeg-devel] [PATCH] RFC: Automatic bitstream filtering

wm4 nfxjfg at googlemail.com
Wed Oct 7 14:10:22 CEST 2015


On Tue,  6 Oct 2015 20:07:08 -0500
Rodger Combs <rodger.combs at gmail.com> wrote:

> This solves the problem discussed in https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
> by allowing AVCodec::write_header to be delayed until after packets have been
> run through required bitstream filters in order to generate global extradata.
> 
> It also provides a mechanism by which a muxer can add a bitstream filter to a
> stream automatically, rather than prompting the user to do so.
> 
> I'd like to split this into 4 commits:
> - Moving av_apply_bitstream_filters from ffmpeg.c to its own API function
> - Other lavf API changes
> - Use of the new API in matroskaenc
> - The minor style tweak in matroskaenc
> 
> There are a few other changes I think should be made before this is applied:
> - Adding BSF arguments to AVBitStreamFilterContext rather than passing them
> manually on each packet
> - Providing an API to add a bitstream filter to an AVStream, rather than doing
> so manually, and using it in check_bitstream
> - Using said API in ffmpeg_opt.c and removing ffmpeg.c's own BSF handling
> - Adding check_bitstream to other muxers that currently prompt the user to add
> bitstream filters (such as aac_adtstoasc and h264_mpeg4toannexb). It could also
> be used by e.g. movenc for generating the EAC3-specific atom.
> ---

Seems like a good idea. As far as I can see, all added fields are
explicitly marked as internal, so that's fine with me.

I just wonder why av_apply_bitstream_filters() is public, and ffmpeg.c
accesses an internal AVStream field (which it shouldn't be allowed to
access).


More information about the ffmpeg-devel mailing list