On 2023-07-12 07:14 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2023-07-12 15:31:57)
On 2023-07-12 06:51 pm, James Almer wrote:
On 7/12/2023 10:14 AM, Gyan Doshi wrote:
On 2023-07-12 06:12 pm, James Almer wrote:
On 7/9/2023 9:57 AM, Anton Khirnov wrote:
This decoding flag makes decoders drop all frames after a parameter
change, but what exactly constitutes a parameter change is not well
defined and will typically depend on the exact use case.
This functionality then does not belong in libavcodec, but rather in
user code
NAK.
The applicable parameters are well defined as set by the implementation.
The implementation defined its own interpretation of what constitutes
a parameter change, yes, but callers may have their own
interpretations too. The result is they either don't set this flag, or
set it but still manually check every frame for other parameters.
They are whatever leads to a change in the size of the decoded frame
payload or the layout/semantics of the elemental unit in a decoded
frame, so width, height, pixel format, sample format/size,
interleaving..etc
You give pixel format as an example, which would include a change from
yuv to a yuvj pseudo format. What about decoders that export yuv +
color_range mpeg and then yuv + color_range jpeg? This implementation
will not consider that a parameter change, despite being practically
the same scenario.
Once the yuvj formats are removed, this will be true for all decoders.
And suddenly starting to check for color_range would be a change in
implementation here.
This is definitely something that should be left to the caller. They
get a frame out of the decoder, they decide if they want to drop it.
They can still do that. Don't set the flag (default) and check
manually. Keeping the flag in lavc doesn't prevent callers from
inserting their own gate.
The point is that what this code considers a parameter change is
entirely arbitrary.
Why does it not consider any of the colorspace parameters? Or
interlacing, cropping, display transform matrix, or any of the other
AVFrame fields or side data we might add in the future that someone
migth consider a parameter change in their use case.
This flag considers the changes to AVframe raster data that can lead to
out of bounds read/writes or mangling of that data.
All the side data add-ons are irrelevant.
When is major bump to 61 expected?
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".
