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

From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 07/29] lavc: add a decoder option for configuring side data preference
Date: Tue, 5 Mar 2024 12:07:05 -0300
Message-ID: <e9c0bf33-c9eb-4481-bdf8-d6c548e00ccb@gmail.com> (raw)
In-Reply-To: <170965045875.29002.15043263301458990476@lain.khirnov.net>

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-request@ffmpeg.org with subject "unsubscribe".