[FFmpeg-devel] [RFC] Reviewing merges

[Marton Balint]

On Wed, 3 May 2017, wm4 wrote:

>> >>> https://trac.ffmpeg.org/ticket/6323
>
> Rather tricky to fix, so I didn't. The problem is that the filter graph
> remains unconfigured, so it can't know about unconnected outputs. It
> remains unconfigured because the first input file is connected to two
> filters (one trivial that keeps shuffling input to the output file, and
> one connected to the unconfigured graph). To get the graph configured,
> the second input file would have to decode 1 frame - this doesn't
> happen because there's nothing in ffmpeg.c scheduling that would make
> the second input file produce output.
>
> The scheduling should be fixed. In theory it would be best to move the
> input "duplication" (single input to several filter inputs) into
> libavfilter, and make libavfilter do proper data flow that blocks
> instead of queuing up frames until OOM.
>
> but I'm not sure how to do that, so I posted a hacky fix for it that
> checks for unconnected outputs on start, instead of in the old place.
>

Thanks!

>> >>> https://trac.ffmpeg.org/ticket/6318
>
> Works here, I suspect it was the same as one of the other issues that
> was fixed recently.

The original report is a bit vague, have you also tried the command line I 
provied?

ffmpeg -threads 11 -i "DNxHD_4_Mono_Channels.mov" -filter_complex 
"[0:v]null[vout];[0:a:0][0:a:1]amerge[aout]" -map [vout] -map [aout] 
"test.mp4"

It fails for me even with the current git master. Maybe with the increased 
number of threads, the video decoding becomes "so delayed" that lavfi 
rejects you to push all audio frames into the filter graph which you got 
before you get a decoded video frame? Although I don't see why this issue 
appeared with the delayed filter initialization.

Thanks,
Marton