On 9/4/16, Nicolas George <geo...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
