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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
