[FFmpeg-devel] [PATCH 1/4] avcodec/frame: add AV_FRAME_FLAG_LOSSLESS
Marton Balint
cus at passwd.hu
Fri Jan 3 01:43:08 EET 2025
On Mon, 23 Dec 2024, Marton Balint wrote:
>
>
> On Mon, 16 Dec 2024, Marton Balint wrote:
>
>>
>>
>> On Mon, 16 Dec 2024, Anton Khirnov wrote:
>>
>>> Quoting Marton Balint (2024-12-16 09:47:39)
>>>>
>>>>
>>>> On Mon, 16 Dec 2024, Anton Khirnov wrote:
>>>>
>>>>> Quoting Marton Balint (2024-12-15 01:02:42)
>>>>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>>>>> ---
>>>>>> doc/APIchanges | 3 +++
>>>>>> libavcodec/version.h | 2 +-
>>>>>> libavutil/frame.h | 4 ++++
>>>>>> 3 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>>>>> index 3a75b803a9..bfba0946d3 100644
>>>>>> --- a/doc/APIchanges
>>>>>> +++ b/doc/APIchanges
>>>>>> @@ -2,6 +2,9 @@ The last version increases of all libraries were on
>>>>>> 2024-03-07
>>>>>>
>>>>>> API changes, most recent first:
>>>>>>
>>>>>> +2024-12-xx - xxxxxxxxxx - lavc 61.27.100 - frame.h
>>>>>> + Add AV_FRAME_FLAG_LOSSLESS.
>>>>>
>>>>> I feel ambivalent about this. This is really a decoder property, and
>>>>> attaching it to frames allows it propagate far away to places where it
>>>>> makes no sense (the same holds for other existing AVFrame fields, but
>>>>> I'd prefer for them to be removed).
>>>>
>>>> The way this flag is set in patch 2 in the series kind of shows why
>>>> this
>>>> is a per-frame property, directly originated from the bitstream of
>>>> codecs
>>>> supporting both lossy and lossless encoding. The encoder for such
>>>> codecs
>>>> is allowed to decide on a frame-by-frame basis if it will use lossy or
>>>> lossless encoding.
>>>
>>> I realize this can change per-frame, my point is that it's a per-frame
>>> property of the decoding process, not of the decoded frame itself.
>>
>> As you said yourself, we have similar fields already in AVFrame (keyframe,
>> pict_type, decoder_error_flags). I guess we could return those in a struct
>> alongside with AVFrame when decoding, but that would complicate stuff in a
>> lot of places having to deal with two structs, so I am not sure that it's
>> worth doing just for the somewhat "cleaner" AVFrame...
>
> Ping. So how should we resolve this? Actually the whole point of introducing
> it was to not lose a "feature" when deprecating the
> AVCodecContext->properties in patch 4...
Will apply the patchset in 2-3 days.
Regards,
Marton
More information about the ffmpeg-devel
mailing list