[FFmpeg-devel] [PATCH v3 0/7] Merge lazy filter initialization in ffmpeg CLI

[wm4]

On Thu, 2 Mar 2017 14:03:18 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Mar 02, 2017 at 09:53:02AM +0100, wm4 wrote:
> > These patches merge the previously skipped Libav commits, which made
> > avconv lazily initialize libavfilter graphs. This means the filters
> > are initialized with the actual output format, instead of whatever
> > libavformat reports.
> > 
> > It's a prerequisite to making hardware decoding support saner, as
> > hardware decoders will output a different pixfmt than the software
> > format reported by libavformat. This can be seen on ffmpeg_qsv.c
> > and ffmpeg_cuvid.c, which don't lose any functionality, even though
> > half of the code is removed.
> > 
> > There are some differences in how ffmpeg.c and avconv.c filter-flow
> > works. Also, avconv.c doesn't have sub2video. Relatively intrusive
> > changes were required.
> > 
> > I will push this tomorrow, except if critical failures are found.  
> 
> I think the patchset improved in terms of regressions but there are
> still several
> 
> ./ffmpeg -i ~/tickets/3015/test_video -filter:a apad -f flv -vcodec flv -ar 22050  -shortest test.flv
> 
> looses the audio stream

This is because the test_video has an audio stream without any audio
packets. The filter is never initialized, so apad can't do its work
either. no audio is output, which in turn means that with the flv muxer
no audio stream is created.

To "fix" this you'd have to introduce a heuristic that determines that
audio is starting too late, and then maybe come up with a fake format
to initialize the filters anyway. This is out of scope of the merge,
and it's not worth fixing anyway.

> 
> also this code crashes with some private files:
> ==7506== Process terminating with default action of signal 11 (SIGSEGV)
> ==7506==  Access not within mapped region at address 0x8
> ==7506==    at 0x471529: av_buffersink_get_frame_rate (buffersink.c:193)
> ==7506==    by 0x435B54: init_output_stream_encode (ffmpeg.c:3217)
> ==7506==    by 0x4364A8: init_output_stream (ffmpeg.c:3351)
> ==7506==    by 0x42E4DB: reap_filters (ffmpeg.c:1428)
> ==7506==    by 0x43AA44: transcode_step (ffmpeg.c:4452)
> ==7506==    by 0x43AB28: transcode (ffmpeg.c:4496)
> ==7506==    by 0x43B2FD: main (ffmpeg.c:4701)

I don't know if you're shitting me on purpose. I can't fix what I can't
reproduce, and you never gave me access to those files. Fix it yourself
if you think it's important. Seriously, what is this.

> This one produces a silent audio channel as previous patchsets did too
> ./ffmpeg -i ~/tickets/1726/Mono.thd out.wav

While libavformat signals a mono channel configuration, the decoder
actually outputs stereo, with one channel muted. You can reproduce this
with current master ffmpeg too by adding "-ac 2". If this is a bug,
then it's merely an old bug that is made more obvious by this patch,
rather than introducing it.

I don't know why you could not determine this yourself. It would have
been easy to check.

> 
> This one looses the first displayed subtitle (the green "help")
> ./ffmpeg -i ~/tickets/153/bbc_small.ts -filter_complex '[0:v][0:s]overlay' -qscale 2 -t 3 test.avi

The first time you mentioned this. Why didn't you do so a week ago?
When I complained that you come up with a new case punctually at
exactly the time when I want to merge the patches.

I have to analyze this one (the only real/actionable issue in your
whole post).

> This one changes timebase
> ./ffmpeg -i ~/fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4  -movflags frag_keyframe+empty_moov test.mp4

So what? If you had even bothered to read my patches, you would have
noticed that some fate tests are adjusted accordingly too. The
time_base gets more precise, which is not a bad thing.

> Also some files still require max_muxing_queue_size to be manually set
> to not fail
>     [libmp3lame @ 0x31dbea0] Queue input is backward in time
>     Too many packets buffered for output stream 0:1.
>     [libmp3lame @ 0x31dbea0] 5 frames left in the queue on closing
> 
> This is worsened by the fact that the user has no hint towards this
> option in the error messages
> 
> [...]

No context, can't do anything about it.