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 <c...@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
_______________________________________________
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".
