On 10/10/2023 8:09 AM, Anton Khirnov wrote:
Quoting James Almer (2023-10-07 18:25:00)
Signed-off-by: James Almer <jamr...@gmail.com>
---
libavformat/avformat.h | 1 +
libavformat/mux.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9e7eca007e..c099ca8a01 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -500,6 +500,7 @@ typedef struct AVProbeData {
The user or muxer can override this
through
AVFormatContext.avoid_negative_ts
*/
+#define AVFMT_CROPPING 0x80000 /**< Format supports storing cropping
values */
I have mixed feeelings about this patch, for a bunch of reasons:
* It is quite ad-hoc - we don't do this for other side data types, and
this approach would not scale if we did.
* If we do want to signal this, we probably want to distinguish between
support for global and per-packet values.
This patch came to be after some discussion from the first iteration of
the set, where concerns about the cropping information being silently
lost if apply_cropping was disabled during a transcoding or codec copy
scenario where the output format didn't support storing said values.
* How do you expect this to be useful to the callers? I don't see this
flag actually being used in the ffmpeg CLI patch.
It's a format flag. Muxers use it, and the generic mux.c code will print
a warning if needed.
_______________________________________________
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".
