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.
Right now, the template for filters that actively support and can cause
resolution changes is the scale filter, and it works like that:
(1) it detects resolution changes by the mismatch of width and/or height
values between the input frame and the input link;
(2) when a resolution changes happens, either from input or from the
logic of the filter (“eval=frame” and formulas that depend on t or
n), it updates the value of both input and output links.
But if two filters using that logic are directly connected together, the
second one will miss the change because the first one will have updated
the values on their shared link.
You can observe it by inserting some debug message in
vf_scale.c:scale_frame() to report frame_changed. Here is an example
filter graph:
testsrc2=s=640x480,
scale=32*(1+15*mod(n\,2)):24*(16-15*mod(n\,2)):eval=frame,
showinfo,
scale=640:480
Remove showinfo and the debug message in the second scale filter no
longer reports any change.
The solution I am inclined to favor is: never update the resolution on
the links, just leave it at what it was at init time.
- If filters do not care about resolution change, then let them just use
the resolution from the frame.
- If filters need to detect resolution change, let them make the
comparison with something in their own private context.
I checked, and it seems the frame pool system will work with that, it
does not use the resolution from the link, only from the get_buffer()
calls.
Optionally, we could have the framework set the resolution to an invalid
value, 0×0 or -1×-1: that way, if the code reaches a pace it should not,
the error will stand out.
Before I start working on that, I would appreciate comments by other
people who know the code. It is possible I am missing something.
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
