[FFmpeg-devel] [PATCH] avformat/concatdec: port to the new bitstream filter API
jamrial at gmail.com
Sat Apr 29 17:33:12 EEST 2017
On 4/28/2017 9:16 PM, James Almer wrote:
> On 4/27/2017 10:59 PM, Michael Niedermayer wrote:
>> On Wed, Apr 26, 2017 at 04:40:55PM -0300, James Almer wrote:
>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>> libavformat/concatdec.c | 86 +++++++++++++++----------------------------------
>>> 1 file changed, 26 insertions(+), 60 deletions(-)
>> ./ffmpeg -f concat -i ~/tickets/3108/concatfile.txt -codec copy test.avi
>> (output produces many warnings/errors on playback)
> Huh, this was more broken than i thought. Apparently, concatdec was
> never really filtering anything before this patch.
> detect_stream_specific() frees up the stream's extradata before the code
> ever has the chance to call the bsf init function because, despite the
> name, the compat code in av_bitstream_filter_init() does not call it.
> That only happens in the first av_bitstream_filter_filter() call. The
> h264_mp4toannexb bsf looks at extradata during init to figure out if it
> needs to filter anything or just do a packet passthrough.
> That aside, concatdec was also copying the input file's stream extradata
> to the matched output stream extradata *before* it called
> detect_stream_specific(), so any filtered extradata would have been
> ignored anyway.
> I don't know if this started happening after the new bsf API was
> introduced and the old converted into a wrapper for the new, or if it
> was always like this, but after this conversion it will not matter.
Commit 0cb19c30c6 essentially disabled the bsf.
The "fix" it mentions is because matroska stores avcc instead of annexb,
so it just muxed the stream untouched. This means actual filtering was
broken beforehand, probably by b8fa374fb6 (Letting unfiltered extradata
make it to the output file's matched stream while the actual h264 stream
More information about the ffmpeg-devel