On 2024-03-13 05:54 pm, Niklas Haas wrote:
From: Niklas Haas<g...@haasn.dev> This filter's existing design has a number of issues: - There is no guarantee whatsoever about the order in which frames are pushed onto the main and ref link, due to this being entirely dependent on the order in which downstream filters decide to request frames from their various inputs. As such, there is absolutely no synchronization for ref streams with dynamically changing resolutions (see e.g. fate/h264/reinit-*).
The only raison d'etre for scale2ref was to have some way to access another stream's parameters. Dynamic streams weren't really the focus.
- For some (likely historical) reason, this filter outputs its ref stream as a second ref output, which is in principle completely unnecessary (complex filter graph users can just duplicate the input pin), but in practice only required to allow this filter to "eventually" see changes to the ref stream (see first point). In particular, this means that if the user uses the "wrong" pin, this filter may break completely.
This change is fine but you should note in the manual docs that this change has occurred (and when) as existing scripts will fail due to the surplus output pad.
Regards, Gyan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
