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

[Cosmin Stejerean <cosmin@cosmin.at>]

On Jul 27, 2023, at 4:13 AM, Anton Khirnov <anton@khirnov.net> 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.


I agree. I see this similar to rotation. And edit lists.

For remuxing we want to keep the metadata and have the muxer write it, but if we're going to transcode anyway we should simplify the stream (apply rotation, apply cropping, keep only visible frames, etc) and write out something as simple as possible. Anyone that doesn't want this can opt out of it like opting out of autorotation.

Not doing this means compatibility is worse when downstream players inevitably don't handle something properly (edit lists are still a mess in terms of compatibility for example). And of potentially displaying content that the user did not intend to be displayed.

- Cosmin
_______________________________________________
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".