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.
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).
--
Anton Khirnov
_______________________________________________
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".
