[FFmpeg-devel] [PATCH 07/29] lavc: add a decoder option for configuring side data preference

Anton Khirnov anton at khirnov.net
Tue Mar 5 16:54:18 EET 2024


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


More information about the ffmpeg-devel mailing list