Hi, Le lun. 27 avr. 2026 à 08:52, Nicolas George via ffmpeg-devel <[email protected]> a écrit : > > Hi. I am trying to decide the right way to fix the design flaw behind > this reported crash: > https://lists.ffmpeg.org/lore/ffmpeg-devel/[email protected]/ > > Preamble: Proper support for format change in a filter graph is not for > tomorrow. It requires sub-graph renegotiation, which in turns requires > identifying exactly the parts of the graph that need renegotiation or > reinitialization. (And in particular it requires that format conversion > happen at single places.) > > But right now, we have a quick-and-dirty support for resolution changes > that works when filters do not care about changes because they do not > pre-allocate or pre-compute things at init time. There are enough to be > useful. > > But quick-and-so-dirty-it-crashes is not acceptable, so we need to cleat > this up a bit.
This might not be in the scope of the changes you're considering at the moment but I wanted to report a complicated issue we had to debug recently with filters re-configuration in the `ffmpeg` CLI: When using `trim` with a max number of frames, a resolution change would trigger the filter reconfiguration which would, in turn, reset the number of frames the filter had already seen, resulting in incorrect output. -- Romain _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
