MXF Add HDR Vivid supoort

[SHEN925]

Hello, last year we communicated with you regarding the addition of the "HDR Vivid" label to the HDR Format in MediaInfo (see issue 1653). At that time, support was added for MP4 and MOV formats, and dynamic metadata extraction was incorporated into HEVC encoding.

Now, I would like to enable support for the HDR Format label in the analysis of MXF files. However, when I use MediaInfo to analyze an MXF file, it is unable to recognize the codec ID. I have an MXF stream that contains HDR Vivid dynamic metadata. Could you please advise on how to proceed? Any suggestions?

Wishing you my sincerest regards.

[JeromeMartinez]

First step: providing a sample file.

Then we analyze the file and depending on the complexity:

• if easy, we implement it for free.
• if complex, we put it in the queue of the things to do in free support, no commitment that it is done soon but you can sponsor its prioritization (it was the case for support in MP4 and MOV formats).

[JeromeMartinez]

Is the file you provided in production?
It is weird:
There seems to be a descriptor with 060E2B34027F01010E23060701010103 , the registry is 7F which is reserved and it seems that the registry should be the classic 53 (2-byte key, 2-byte length).
Additionally the InstanceID of this descriptor is not registered in any sequence so it is orphelin.
There is a private organization 23 which is not registered at SMPTE, is it UWA and the SMPTE registry is not up to date?

We find the UWAFrameData element in the file, it is a new XML format not supported yet.

[JeromeMartinez]

@SHEN925 any specification?
T/UWA 005.2-1-2022 does not mention MXF integration.

[SHEN925]

--There seems to be a descriptor with 060E2B34027F01010E23060701010103 , the registry is 7F which is reserved and it seems that the registry should be the classic 53 (2-byte key, 2-byte length).

You can refer to the PDF file on the HDR Vivid MXF Encapsulation Method in the documentation, which provides an explanation of the descriptor and the location of the dynamic metadata.

--There is a private organization 23 which is not registered at SMPTE, is it UWA and the SMPTE registry is not up to date?

The 23rd entry in the CRIFST registration on https://www.smpte-ra.org/class-1314-registrations is for HDR Vivid dynamic metadata.

--T/UWA 005.2-1-2022 does not mention MXF integration.

T/UWA 005.2-1-2022 currently does not have updated MXF-related information in this document, so you won’t find the details there.

In MXF, dynamic metadata is stored in XML format, and the documentation includes XML template files for your reference!

[SHEN925]

HDR Vivid MXF Source.zip
This is the material mentioned above.

[JeromeMartinez]

You can refer to the PDF file on the HDR Vivid MXF Encapsulation Method in the documentation, which provides an explanation of the descriptor and the location of the dynamic metadata.

Thank you, I see that it is similar to PHDR tracks (SMPTE RDD 56, DataDefinition + SourceTrackID + SimplePayloadSID in descriptor, and Generic Stream Data Element Key at the end) , so I can know what is the meaning of each private UL.

But it does not change the issue about "7f" registry designator.
SMPTE ST 377: "Table 18 – Common Universal Label Value for all Abstract Structural Metadata Groups"
"6 Registry Designator: 7fh Abstract Groups, no KLV encoding syntax specified"

"060e2b34.027f0101.0e230607.01010103" is not an abstract group, it is a classic group coded as a local set using 2-byte tag values and 2-byte length values consistent with all MXF descriptors, with private ULs listed in the Primer Pack, check the note e.g. "Note 2: According to SMPTE ST 336, the xx has the value of 13h for BER long or short form encoded length and 53h for 2-byte length".
(I already saw in some specs, if I remember well, the "7f" thing but with a note that "7f" must be replaced by the value corresponding to the encoded content, so if 2-byte tag values and 2-byte length values the registry byte shall be "53")

It is incoherent; either this is a Abstract Structural Metadata Group and there is no additional private ULs in the Primer pack and no Generic Stream Data Element Key, or it is a standard group with the private ULs in the Primer Pack. It can not be abstract and with private ULs in the Primer Pack at the same time.

You can check MXF RDD 56, the Descriptor UL has 53 in the registry byte, as all other standardized descriptors.

I also note that there is no link between the video stream and the Vivid XML stream, so as is they are 2 independent streams not related to each other. The Vivid descriptor instance ID should be be referenced as a subdescriptor in the SubDescriptor item in the CDCI descriptor, in addition to the already listed HEVC subdescriptor instance ID.
I don't see something explicit in the SMPTE RDD 56 but all SMPTE RDD 56 files I have up to now have the Generic Stream Data Element Key related descriptor in the list of subdescriptors of the CDCI or RGBA main descriptor.
I can guess to which video stream the Vivid content applies because there is only 1 video stream but technically I should not do that with what is in this file. Anyway, if a HDR Vivid stream is orphelin and if there is a video stream, I'll force an association between both stream, but it would be preferable that you fix your muxer for adding the HDR Vivid descriptor in the list of sub descriptors of the main descriptor, in addition to fix the UL of the descriptor to "060e2b34.02530101.0e230607.01010103".

The 23rd entry in the CRIFST registration on https://www.smpte-ra.org/class-1314-registrations is for HDR Vivid dynamic metadata.

The XML registry, even the draft one, is not up to date :(.
I added CRIFST manually.

[SHEN925]

This is the updated MXF file. You can use it for testing.
hevc_420p10_5s.zip