On 3/5/2024 11:54 AM, Anton Khirnov wrote:
Quoting James Almer (2024-03-05 15:35:02)
On 3/5/2024 11:29 AM, Anton Khirnov wrote:
Quoting James Almer (2024-03-05 13:30:58)
+ {"dynamic_hdr10_plus", .default_val.i64 = AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
.type = AV_OPT_TYPE_CONST, .flags = A|D, .unit = "side_data_pkt" },
This one packet/frame level only, not global.
It is in sd_global_map
Then that's a mistake, and I'm probably he culprit. HDR10+ is per frame
metadata. Static HDR metadata are mastering_display and ccl.
Ok, dropped from the options table locally.
Is this option meant to also choose which one of those to use?
???
You can have packet side data at the container level that corresponds to
the same thinga per frame side data at the bitstream level does. In
HDR10+ case, Matroska may have it in block additional, and then afaik it
could be present in the hevc bitstream.
One of them should have priority, or the user could be given the choice.
Right, I've thought about this a bit, but then couldn't find any side
data types that some container could export per-packet AND could also be
present in the bitstream.
Aside from HDR10+, I'm sure this scenario can also happen with closed
captions.
One possible solution is to rename the option to something like
side_data_prefer_external (better names welcome), and have it switch
between user-supplied (i.e. global or per-packet) and in-bitstream side
data.
This adds an ambiguity for the hypothetical case where some side data
exists as global and per-packet - then I'd say lavc should default to
per-packet and leave the other case to the caller (should be very rare,
possibly could be handled with a bitstream filter).
If a given side data type at the container level were to be duplicated
in the header (global) and per packet, then IMO the packet must have
priority, given it's the container overriding its own parameters.
_______________________________________________
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".
