[FFmpeg-devel] [PATCH] lavc: deprecate AV_CODEC_FLAG_DROPCHANGED

[Gyan Doshi]

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 color range was not part of the practical problem I was solving at 
the time. At best, that calls for converting this from a bitmask in 
flags to a dedicated parameter with bitmask per attribute.

Regards,
Gyan