[FFmpeg-devel] [PATCH v2 6/7] avformat/matroskaenc: support writing Dynamic HDR10+ packet side data

James Almer jamrial at gmail.com
Fri Mar 24 17:39:22 EET 2023


On 3/24/2023 12:11 PM, Jerome Martinez wrote:
> On 24/03/2023 13:59, James Almer wrote:
>> On 3/24/2023 8:58 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2023-03-24 12:50:40)
>>>> On 3/24/2023 8:45 AM, Anton Khirnov wrote:
>>>>> Quoting James Almer (2023-03-21 19:00:01)
>>>>>> @@ -3095,6 +3153,12 @@ after_cues:
>>>>>>                avio_seek(mkv->track.bc, 
>>>>>> track->blockadditionmapping_offset, SEEK_SET);
>>>>>>                   put_ebml_uint(mkv->track.bc, 
>>>>>> MATROSKA_ID_TRACKMAXBLKADDID, track->max_blockaddid);
>>>>>> +            if (track->max_blockaddid == 4) { // HDR10+
>>>>>
>>>>> Maybe this magic 4 deserves a name too?
>>>>
>>>> Is has no name. See
>>>> https://www.matroska.org/technical/codec_specs.html#itu-t35-metadata
>>>>
>>>> It only defines a name for the BlockAddIDType, which i used, and
>>>> constricts the BlockAddIDValue to be used for it to 4.
>>>> It's not necessarily HDR10+ (i can remove that comment if it makes it
>>>> look like it should be named), it's potentially any ITU-T T35 
>>>> payload of
>>>> which we only care about HDR10+, so i can't name it that. It's 
>>>> simply 4.
>>>
>>> MATROSKA_BLOCKADDITIONAL_ITUT35_VAL then?
>>
>> 4 as BlockAddID is valid for any mapped BlockAddIDType value, not just 
>> MATROSKA_BLOCK_ADD_ID_TYPE_ITU_T_T35.
>> But ok, i'll add a #define for it. If we ever start writing other 
>> types, like SMPTE ST 12-1 Timecode, we could just make sure to never 
>> use 4 for it.
> 
> SMPTE ST 12-1 would have a BlockAddIDType of 121 [1] for differentiating 
> timecode streams from ITU T.35, true, but using 4 as BlockAddID for 
> something not ITU T.35 may create problems with some legacy decoders and 
> would not be recommended.
> So IMO flagging 4 as MATROSKA_BLOCKADDITIONAL_ITUT35_VAL would make 
> sense there.
> I suggested a patch to the Matroska spec for being explicit about this 
> value 4 in [2].
> 
> A small comment about "// HDR10+", as it is not only for HDR10+ (ITU 
> T.35 may contain lot of other things, depending on 
> itu_t_t35_terminal_provider_code etc), IMO it should be commented as "// 
> ITU T.35".
> 
> By the way, it is great to see this patch, it is very useful and would 
> help in making a similar patch for SMPTE ST 12-1 timecode.
> 
> [1] 
> https://github.com/ietf-wg-cellar/matroska-specification/blob/master/block_additional_mappings/smpte-st12-1-timecode.md

Currently, the block_additional_mappings page only lists SMPTE ST 12-1 
timecode. For the rest (ITU-T T.35, Dovi stuff, Opaque data, etc) you 
need to stumble upon them in 
https://www.matroska.org/technical/codec_specs.html#block-addition-mappings, 
which is confusing.
Could these be added to the proper section too?

> [2] https://github.com/ietf-wg-cellar/matroska-specification/pull/745
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list