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

[Nicolas George]

Le quintidi 15 fructidor, an CCXXIV, Michael Niedermayer a écrit :
> ./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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160904/11816603/attachment.sig>