Re: [FFmpeg-devel] [PATCH v2 5/5] fftools/ffmpeg: support applying container level cropping

["Tomas Härdin" <git@haerdin.se>]

tor 2023-07-27 klockan 08:59 -0300 skrev James Almer:
> On 7/27/2023 8:13 AM, Anton Khirnov wrote:
> > Quoting Tomas Härdin (2023-07-26)
> > > tis 2023-07-25 klockan 14:09 -0300 skrev James Almer:
> > > > Signed-off-by: James Almer <jamrial@gmail.com>
> > > > ---
> > > > Now inserting a filter into the graph.
> > > 
> > > This looks useful for MXF
> > > 
> > > > +    { "apply_cropping",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> > > > +                          OPT_EXPERT |
> > > > OPT_INPUT,                                { .off =
> > > > OFFSET(apply_cropping) },
> > > > +        "Apply frame cropping instead of exporting it" },
> > > 
> > > Hm. Can this be applied automatically for ffplay? When
> > > transcoding I
> > > expect the typical use case is to not crop and to carry the
> > > metadata
> > > over.
> > 
> > Why? We do apply decoder cropping by default. There's also no
> > guarantee
> > that your container will be able to write it, so it seems better to
> > apply it by default.

Not necessarily. Doing this by default may break some downstream
projects. The relevant metadata must be deleted if this is done, so
that the cropping isn't done twice when you get to playout.

> I agree. In a transcoding scenario you want to apply the container
> level 
> cropping since it's defining a subrectangle with the actual content 
> meant for display, so why force the encoder handle pixels that were 
> meant to be discarded to being with, potentially ruining encoding 
> quality for neighboring pixels?
> 
> For codec copy scenarios though, the side data is going to be copied,
> so 
> Tomas' idea of having muxers report they support writing it is good 
> either way.

My main concern is not losing pixels if we can avoid it, even if those
pixels are invisible. On the other hand, when transcoding, we could go
with always cropping unless the user requests otherwise. This has the
benefit of essence dimensions not changing with container. Also less
work for the encoder. But again, this is a behavior change that may
break things downstream.

Basically what I'm suggesting is that ffplay behave as playout. We
could have ffmpeg behave similarly but we should keep in mind this may
break some workflows.

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".