[FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values
James Almer
jamrial at gmail.com
Tue Oct 10 14:13:46 EEST 2023
On 10/10/2023 8:09 AM, Anton Khirnov wrote:
> Quoting James Almer (2023-10-07 18:25:00)
>> Signed-off-by: James Almer <jamrial at 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.
More information about the ffmpeg-devel
mailing list