Add feature to write display management metadata suited for tv-led DV.

[doppingkoala]

TV-led DV requires the display management metadata to be embedded into the top pixels as detailed in ETSI GS CCM 001. To do this requires access to the dm metadata in the format given by Table 3 in that doc.

Would like a function added to the c-api that writes nal units in this format. Very similar to the existing code for writing dm metadata. Only real differences are

• affected_dm_metadata_id written as 4 bits.
• current_dm_metadata_id written as 4 bits.
• scene_refresh_flag written as 8 bits.
• Only write the total number of metadata blocks (i.e., sum cmv2.9 and cmv4.0 block) as 32bits, rather than writing the number of each separately.
• Write all other variables with a bit-depths of 8,16, or 32. i.e. if was written as 12-bit, now use 16-bit.
• Don't write level 6 metadata.

Sure you don't want to actually use my code, but I have a working hack-job of your code that output in the right format. Changes I made are here

[quietvoid]

This doesn't seem convenient to add. It would need to be totally different functions that write the payload.

[doppingkoala]

Might not be convenient, but your tool already has almost all the code that would be needed for this functionality, mostly just with different numbers of bits being written.

To me, this feature seems very useful and your tool seems like the natural place to get this output from given it already has almost all the needed code in place and is integrated into other projects like kodi to rewrite bitstreams.

[quietvoid]

Is there better documentation than the ETSI GS CCM 001 doc?
It's not describing much of what you mention or do in your code example.

I guess it's mostly the syntax tables but it just seems like old versions of the RPU spec.

[doppingkoala]

Not that I found. That doc does seem fairly old, and that table was missing some info with reserved bits. As what was there aligned with your existing work, I filled in the blanks and assumed what was missing followed the same pattern, i.e. promoting bit depths.

The other info was inferred from examining captures of hdmi tunnels. Only writing the total number of metadata blocks was taken by looking at a capture of the hdmi tunnel when playing a cmv4.0 file. Only using 4 bits for affected_dm_metadata_id and current_dm_metadata_id was based on these variable having a range of 0-15, and assuming they packed into the first reserved_0x00_8bits field at the start of Table 3 in that doc. Not writing L6 data was again from looking at a hdmi tunnel capture. For all the other reserved fields in Table 3, I assumed that they would match the fields in newer work.

I've then checked all of these minimal assumptions against data captured of the hdmi tunnel from a oppo and a AM6B+. I've then worked it the other way - taking some DV metadata, injecting it into the hdmi signal in this format, and observed the expected responses.

Would you like the raw data I extracted from the hdmi tunnel captures to be provided?

[quietvoid]

Would you like the raw data I extracted from the hdmi tunnel captures to be provided?

Sure, it can be useful.

[doppingkoala]

Will do.

The format for this data can also be seen in the function dm_rpu_payload_2_byte_sequence that can be seen in dovi.a.c from this c code

[quietvoid]

The format for this data can also be seen in the function dm_rpu_payload_2_byte_sequence that can be seen in dovi.a.c from this c code

The OneDrive links are not working for me.
edit: Apparently 1drv might just be down ATM.

[doppingkoala]

This byte sequence:
0,1,32,0,3,31,6,145,32,0,252,91,4,67,32,0,1,11,234,87,0,0,0,0,8,0,0,0,8,0,0,0,66,185,254,163,254,163,254,163,66,185,254,163,254,163,254,163,66,185,255,255,0,0,0,0,0,0,0,0,12,2,1,1,0,7,12,7,0,42,9,0,0,0,6,1,0,7,12,7,8,0,0,0,0,14,2,8,33,7,43,7,244,6,180,8,0,8,0,8,0,0,0,0,14,2,11,35,8,177,8,6,10,62,8,0,8,0,8,0,0,0,0,14,2,12,7,8,179,8,9,11,14,8,0,8,0,8,0,0,0,0,4,4,4,124,4,136,0,0,0,6,3,8,0,8,0,6,60,0,0,0,1,9,2,0,0,0,4,11,0,0,0,0,0,0,0,2,254,0,2
is the data corresponding to Table 3 of the doc taken from a capture of multi.pattern.DV.P5.mp4 available here.

[doppingkoala]

The OneDrive links are not working for me.
edit: Apparently 1drv might just be down ATM.

Here is a copy.