EDID Override - Injecting a Dolby VSVDB Block

cpm · 3 July 2024 03:05

Can add a simple string, but question is how to parse into the values needed:

hdr10_data.features =
		  (1 << 29)		/* 1 video available / present */
		| (5 << 26)		/* 5 unspecified */
		| (0 << 25)		/* 0 limited range */
		| (1 << 24)		/* 1 color available / present */
		| (9 << 16)		/* 9 primaries bt2020 */
		| (0x10 << 8)	/* 16 transfer char. smpte-st-2084 */
		| (10 << 0);	/* 10 matrix co. bt2020c / 9  bt2020nc */
	
	for (i = 0; i < 3; i++) {
		hdr10_data.primaries[i][0] = 0;
		hdr10_data.primaries[i][1] = 0;
	}
	hdr10_data.white_point[0] = 0;
	hdr10_data.white_point[1] = 0;
	hdr10_data.luminance[0] = 0;
	hdr10_data.luminance[1] = 0;
	hdr10_data.max_content = 0;
	hdr10_data.max_frame_average = 0;
	
	if (vinfo && vinfo->vout_device &&
	    vinfo->vout_device->fresh_tx_hdr_pkt)
		vinfo->vout_device->fresh_tx_hdr_pkt(&hdr10_data);

i.e. what are you trying to override here, if you can work out on a spreadsheet first and ping back I can translate into code later.

cpm · 3 July 2024 03:11

There is additional UserData SEI NAL parsing in the 5.15 kernel that maybe the difference if those other players are using a newer kernel to solve the problem - possibly the MDL is expressed in that data rather than the dedicated SEI - but then no DV (dovi.ko) for that kernel yet - iirc.

DMDreview · 3 July 2024 06:43

There’s the question of why this same am6b+ but with Android doesn’t have the problem, even though there’s clearly an older version and an older version of Android itself

cpm · 3 July 2024 08:40

It is a software issue - the HEVC Elementary Stream contains the SEI NAL (which has this MDL/MDC metadata) this is not being parsed correctly from the looks of it (AMLogic Linux 4.9 i.e. the Kernel - HEVC Decoder).

The Android side will be based on the AMLogic Android n.n. i.e. a different software stack and HEVC Decoder.

DMDreview · 3 July 2024 12:44

If you compare the mediainfo of a normal and ATEME file, the difference is a few lines, maybe the system doesn’t expect the Writing library parameter and ends up just ignoring and not reading the rest of the data, below.
But maybe I’m wrong

cpm · 3 July 2024 12:56

The structure of the SEI is different top is ATEME one SEI has 3 messages in it including the MDL.

The bottom is none-ATEME the MDL is in it’s own SEI with one message.

DMDreview · 3 July 2024 15:11

now I see, then it will be a challenge to make a proper reading.
Is it possible to apply some condition, if MDL is not 1000, then substitute 4000. Is there such a possibility, but there are movies where MDL is not specified at all.

OCEFDA · 3 July 2024 16:01

@cpm, here is the info you requested in terms of parsing the string:

The HDR infoframe:

Header Bytes:
Byte 1 - Info Frame Type = 0x07
Byte 2 - Version = 0x01
Byte 3 - Number of Metadata Bytes following the header = generally 0x1A (26)

Data Bytes:
Byte 1 - Transfer Function:
00 = Power Gamma SDR
01 = Power Gamma HDR
02 = PQ Gamma
03 = HLG Gamma
04-07 = Reserved
Byte 2 - Metadata Descriptor = 0x00, Static Metadata
Byte 3 - Byte n - Content Metadata
Byte 3 - 14 - Primaries (Group 1)
Byte 3 - display_primaries_x[0], LSB
Byte 4 - display_primaries_x[0], MSB
Byte 5 - display_primaries_y[0], LSB
Byte 6 - display_primaries_y[0], MSB
Byte 7 - display_primaries_x[1], LSB
Byte 8 - display_primaries_x[1], MSB
Byte 9 - display_primaries_y[1], LSB
Byte 10 - display_primaries_y[1], MSB
Byte 11 - display_primaries_x[2], LSB
Byte 12 - display_primaries_x[2], MSB
Byte 13 - display_primaries_y[2], LSB
Byte 14 - display_primaries_y[2], MSB
Byte 15 - 18 - White Point (Group 2)
Byte 15 - white_point_x, LSB
Byte 16 - white_point_x, MSB
Byte 17 - white_point_y, LSB
Byte 18 - white_point_y, MSB
Byte 19 - 20 - Max MDL (Group 3)
Byte 19 - max_display_mastering_luminance, LSB
Byte 20 - max_display_mastering_luminance, MSB
Byte 21 - 22 - Min MDL (Group 4)
Byte 21 - min_display_mastering_luminance, LSB
Byte 22 - min_display_mastering_luminance, MSB
Byte 23 - 24 - MaxCLL (Group 5)
Byte 23 - Maximum Content Light Level, LSB
Byte 24 - Maximum Content Light Level, MSB
Byte 25 - 26 - MaxFALL (Group 6)
Byte 25 - Maximum Frame-average Light Level, LSB
Byte 26 - Maximum Frame-average Light Level, MSB

Data Bytes 3 – 22 contain the Display Mastering data defined in SMPTE ST 2086.

Data Bytes 3 – 18 are coded as unsigned 16-bit values in units of 0.00002, where 0x0000 represents zero and 0xC350 represents 1.0000.

Data Bytes 3 - 14 describes the chromaticity of the Red, Green and Blue color primaries of the mastering display.

All possible mappings of the chromaticity of Red, Green and Blue color primaries to indices 0,1 and 2 are allowed and shall be supported by the sink.

The correspondence between Red, Green and Blue color primaries and indices 0, 1, or 2 is determined by the following relationship:

The Red color primary corresponds to the index of the largest display_primaries_x value.
The Green color primary corresponds to the index of the largest display_primaries_y value.
The Blue color primary corresponds to the index with neither the largest display_primaries_y value nor the largest display_primaries_x value.

Data Bytes 19 – 20 specify a value for the max_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m and 0xFFFF represents 65535 cd/m.

Data Bytes 21 – 22 specify a value for the min_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 0.0001 cd/m, where 0x0001 represents .0001 cd/m and 0xFFFF represents 6.5535 cd/m.

Data Bytes 23 – 24 contain the Maximum Content Light Level (MaxCLL). This value is coded as an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m and 0xFFFF represents 65535 cd/m.

Data Bytes 25 – 26 contain the Maximum Frame-Average Light Level (MaxFALL). This value is coded as an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m and 0xFFFF represents 65535 cd/m.

The data in Data Bytes 3 – 26 are arranged into groups. When ALL of the Data Bytes in a group are set to zero, then the Sink shall interpret the data for that group as unknown, NOT zero.

SAMPLES:

EOTF = SMPTE ST 2084
Primaries = ITU-R BT 2020-2
White Point = D65
Max Luminance [nits]: 10000
Min Luminance [nits]: 0.0001
MaxCLL [nits]: 4000
MaxFALL [nits]: 1000

07:01:1a:02:00:34:21:aa:9b:96:19:fc:08:48:8a:08:39:13:3d:42:40:10:27:01:00:a0:0f:e8:03

EOTF = SMPTE ST 2084
Primaries = ITU-R BT 2020-2
White Point = D65
Max Luminance [nits]: 4000
Min Luminance [nits]: 0.0001
MaxCLL [nits]: 1000
MaxFALL [nits]: 400

07:01:1a:02:00:34:21:aa:9b:96:19:fc:08:48:8a:08:39:13:3d:42:40:a0:0f:01:00:e8:03:90:01

EOTF = SMPTE ST 2084
Primaries = ITU-R BT 2020-2
White Point = D65
Max Luminance [nits]: 1000
Min Luminance [nits]: 0.0001
MaxCLL [nits]: 1000
MaxFALL [nits]: 400

07:01:1a:02:00:34:21:aa:9b:96:19:fc:08:48:8a:08:39:13:3d:42:40:e8:03:01:00:e8:03:90:01

EOTF = SMPTE ST 2084
Primaries = ITU-R BT 2020-2
White Point = D65
Max Luminance [nits]: Unknown
Min Luminance [nits]: Unknown
MaxCLL [nits]: Unknown
MaxFALL [nits]: Unknown

07:01:1a:02:00:34:21:aa:9b:96:19:fc:08:48:8a:08:39:13:3d:42:40:00:00:00:00:00:00:00:00

OCEFDA · 3 July 2024 16:06

I am not a good spreadsheet coder although I will try to do an HDR infoframe calculator. If anyone knows enough excel/spreadsheet to create a HDR infoframe calculator (as cpm did for the VSVDB block) that would be great. It can be an addition to cpm’s spreadsheet for the VSVDB block.

cpm · 3 July 2024 16:14

Right - so thats the HDR info frame that goes out on the HDMI, not quite what we need - needs to align to the code snippet I sent - somewhere else later in code that gets converted into the info frame (which the HDFury overrides).

cpm · 3 July 2024 16:18

Could write our own parser for the raw data - but something not right with he raw data as well! some bits appear missing or just wrong - frustratingly can see the data needed (which actually looks ok) but no logical way to extract it because of the wrong data markers around it.

chuckster · 3 July 2024 16:35

hi, fresh meat here) been using AM6B+ for a while and have only recently discovered the CE (esp CPM’s build) and how awesome it is compared to the buggy-ish android).
Do you know if ATEME always leaves the info in the Writing Library and if this info gets dropped during stream manipulations (e.g. hybrid remux creation)?
asking in order to split the watching flow (ATEME → Android, others → CE) or do you think the issue is not that bad to constantly switch? Thanks!

OCEFDA · 3 July 2024 16:47

Ok understand, not sure I can help since I do not know that specific code. Will take a look anyway. Thanks.

OCEFDA · 3 July 2024 20:06

@cpm, not sure if this is what you wanted but looking at the snippet code you send and showing a sample of how it would work to match a string that the user could provide on the screen:

Sample Target:

Primaries = ITU-R BT 2020-2
White Point = D65
Max Luminance [nits]: 4000
Min Luminance [nits]: 0.0001
MaxCLL [nits]: 1000
MaxFALL [nits]: 400

Sample String user would input on screen = 34:21:aa:9b:96:19:fc:08:48:8a:08:39:13:3d:42:40:a0:0f:01:00:e8:03:90:01

I am using the same convention on the string format above as used in the CTA-861.3-A and HDFury - Starting from Byte 3 of the Data Bytes section.

Parsing in variables:

Using hex format (digit grouping little endian) as above, I not sure what data type is the hdr10_data structure. Assuming that it is hex format (digit grouping little endian) then the parsing would be - every two bytes would fill each variable:

hdr10_data.primaries[0][0] = 34:21;
hdr10_data.primaries[0][1] = aa:9b;
hdr10_data.primaries[1][0] = 96:19;
hdr10_data.primaries[1][1] = fc:08;
hdr10_data.primaries[2][0] = 48:8a;
hdr10_data.primaries[2][1] = 08:39;

hdr10_data.white_point[0] = 13:3d;
hdr10_data.white_point[1] = 42:40;

Values above are coded as unsigned 16-bit values in units of 0.00002, where 0x0000 represents zero and 0xC350 represents 1.0000.

hdr10_data.luminance[0] = a0:0f;

Value above for the max_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 1 cd/m, where 0x0001 represents 1 cd/m and 0xFFFF represents 65535 cd/m.

hdr10_data.luminance[1] = 01:00;

Value for the min_display_mastering_luminance. This value is coded as an unsigned 16-bit value in units of 0.0001 cd/m, where 0x0001 represents .0001 cd/m and 0xFFFF represents 6.5535 cd/m.

hdr10_data.max_content = e8:03;
hdr10_data.max_frame_average = 90:01;

Does this make sense?

okvcos · 3 July 2024 21:55

sorry OCEFDA , but I didn’t understand the point of going deeper into the HDR10 thing, now all TV displays and projectors are able to receive the correct signal and if I think that the AM6B+ is not able to do it correctly I don’t understand what the fuss is about speaking, in the sense that you can enter all the parameters you use in the HDFury but the signal source must be correct.
Personally I have always used the HDfury to have DV (LLDV trick) on HDR panels, now that I have a DV, HDR, HDR10 projector I no longer use it.
And just to understand your purpose/request

What type of TV or projector do you have?

OCEFDA · 3 July 2024 23:18

The reason is two fold: one the is the problem with ATEME files which is around 40% of the HDR movies. From what I understand this would override this problem and would be a temporary fix until the CE code is fixed. Second there are still a number of HDR projectors and TVs that use the HDR info frame with the LLDV signal. This would enable to only need the this device and nothing else (such as an HDFury) to have tweak control of dtm.

cpm · 3 July 2024 23:38

Yep makes sense, so not looking to alter the
hdr10_data.features (e.g. the type of the characteristics and matrix coefficients etc.)

But just the values for the primaries, white point and luminance.

This is more doable, probably be one long string rather than : separated, to align with the VSVDB.

Will see when can do, next week I am off on holiday for 3 weeks so not expecting to do much if anything on this so may be a while.

FYI, this would only be for Player Led (HDR) output.
Also would not help with the VS10 HDR → DV issue around HDR10 metadata as needs to be earlier in the process - got other thoughts on how to solve that albeit in a rather unsatisfactory and maybe not 100% fool proof way.

cpm · 3 July 2024 23:41

It is in a HEVC stream itself unless specifically trying to drop those NAL I think it would come into a Hybrid as well.

Looking at a “hack” way to try and identify and pull out the correct info as long as ATEME do not change the approach again later.

OCEFDA · 4 July 2024 00:16

Ok, enjoy your vacation!

Wag · 4 July 2024 05:29

Interesting thread.

Now that I have a 2nd gen cube running Coreelec on my main TV (Vizio PQX-85H1) which supports DV, I am thinking about picking up a 2nd for my older bedroom Sony XBR 65900E which is HDR10 only. I already have a an Odroid N2 in there but it would be cool if I could get DV rips to play back on it as well.