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