[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