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?
--
Anton Khirnov
_______________________________________________
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".
