[FFmpeg-devel] Evolution of lavfi's design and API

[Paul B Mahol]

On 9/4/16, Nicolas George <george at nsup.org> wrote:
> Le quintidi 15 fructidor, an CCXXIV, Michael Niedermayer a ecrit :
>> ./ffmpeg -i tickets//679/oversized_pgs_subtitles.mkv -filter_complex
>> '[0:s:1]scale=848x480,[0:v]overlay=shortest=1' test.avi
>> fails assertion:
>> Assertion progress failed at libavfilter/avfilter.c:1391
>>
>> https://trac.ffmpeg.org/attachment/ticket/679/oversized_pgs_subtitles.mkv
>
> This one was an easy fix.
>
>> ffmpeg -v 0 -i tickets/3539/crash.swf -map 0 -t  1  -f framecrc -
>> output changes, not sure this is a bug but reporting it anyway as i
>> noticed
>
> This one is much more tricky. When a format change is detected, ffmpeg
> resets the graphs but does not drain them first. With this big change,
> frames inserted do not reach as far as previously: less immediate
> processing, more possibility to work in a thread.
>
> But the issue also happens with the current code:
>
> ffmpeg -i a%02d.png -vf fps=50 -f framecrc -
>
> with two input PNGs of different size, will only output the second one,
> because the first one is buffered by vf_fps and discarded when the graph is
> reconfigured.
>
> This is very tricky, because flushing the graph on format change is not the
> same thing as flushing it at EOF. Imagine the input format for an overlay
> change: flushing would mean finishing the background video with the last
> image before the format change, this is not at all what expected.
>
> I do not see a clean way of getting this particular example and all similar
> ones working. I can see an ugly solution, but I would rather avoid it and
> wait for a cleaner implementation of handling format changes.

And what would that cleaner implementation do?

At current rate your lavfi changes will never get in, which sucks.