On Jul 27, 2023, at 4:13 AM, Anton Khirnov <an...@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 <jamr...@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-requ...@ffmpeg.org with subject "unsubscribe".
