[FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values

[Anton Khirnov]

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 <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.

Why is it public then?

-- 
Anton Khirnov