[FFmpeg-devel] [PATCH 1/4] avformat/avformat: add a new disposition to signal the stream is an HDR gainmap
James Almer
jamrial at gmail.com
Thu Sep 26 17:25:11 EEST 2024
On 9/26/2024 11:17 AM, Anton Khirnov wrote:
> Quoting James Almer (2024-09-26 14:06:25)
>> On 9/26/2024 3:00 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2024-09-26 00:52:16)
>>>> HDR images photos taken by certain cameras split this as a separate image.
>>>>
>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>> ---
>>>> libavformat/avformat.h | 5 +++++
>>>> libavformat/dump.c | 2 ++
>>>> 2 files changed, 7 insertions(+)
>>>>
>>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>> index 56c1c80289..6d9f5c4399 100644
>>>> --- a/libavformat/avformat.h
>>>> +++ b/libavformat/avformat.h
>>>> @@ -718,6 +718,11 @@ typedef struct AVIndexEntry {
>>>> * Annex G/H, or HEVC Annex F).
>>>> */
>>>> #define AV_DISPOSITION_MULTILAYER (1 << 21)
>>>> +/**
>>>> + * The video stream contains an HDR gainmap. Only ever used with
>>>> + * AV_DISPOSITION_DEPENDENT.
>>>> + */
>>>> +#define AV_DISPOSITION_GAINMAP (1 << 22)
>>>
>>> Presumably we want this information available in codecs and filters as
>>> well, so then should it not be side data instead?
>>
>> There is no other information than "This is a gainmap", and that's
>> container level information (Same as "This is a tile" for heif). How
>> would side data work for this?
>
> You could e.g. have side data that has no payload, and its presence
> signals the same information.
Is there precedent for this? Would it be a side data with size 0 (but
data still pointing to an AVBufferRef)?
>
>> I'm including it in the tile grid stream group in patch 4/4, so that
>> should give the caller all the information they need.
>
> Assuming all they ever need is handle everything manually.
I don't understand what you mean. A side data entry, assuming it's
propagated to the decoder context and then the decoded frame, would
indeed pass this information through but will still be missing what
image this gainmap is for, so the caller still needs to be aware of it
(This is what the group is for) and do some things manually, namely
inserting an hypothetical filter for the merging process.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240926/eecfe5f3/attachment.sig>
More information about the ffmpeg-devel
mailing list