On Tue, 6 Oct 2015 20:07:08 -0500 Rodger Combs <rodger.co...@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). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
