On 10/10/2023 8:16 AM, Anton Khirnov wrote:
Quoting James Almer (2023-10-10 13:13:46)
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.
Why is it public then?
So the library user can know beforehand if the cropping information will
be lost or not, and choose accordingly. The warning is there for the
cases where it was ignored.
I can add a check to the CLI for it, but other than to abort or outright
ignore the user request to not apply cropping i don't see what it could
do, as mux.c already prints a warning.
_______________________________________________
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".
