android seems to have the same problem, and when I tested it, sometimes it extends to video, i.e. it can also start with floating pixels, like png, for example, Apple tv always works this way. it outputs all videos with floating pixels. and Amlogic issues this under certain conditions. I didn’t try to figure out the reason.
Use patterns / lossless videos with the metadata already embedded like the test pattern or samples from your captures. I’ll given it a try from my laptop at some point.
Yup, exactly.
I’ve now decoded the embedded metadata for all 14 frames of the file am6b-min p7-rgb-.mov. Each frame contains the common vdr_dm_data metadata, one Level 1 metadata extension block, two Level 2 metadata extension blocks, and one Level 4 metadata extension block.
I’ve assumed this capture comes from the sample Minions Rise of Gru - P7 ST-DL FEL (original).mkv. When comparing to the metadata extracted from the mkv using the dovi_tool, I’ve found a few differences:
- All
ycc_to_rgb_coefvariables are significantly different. ycc_to_rgb_offset0is zero in the capture, but is non-zero from the dovi_toolsignal_color_spacereported by dovi_tool is0, and from the capture is2. From the patent US10701399, this corresponds to YCbCr and ICtCp, respectively. Manually unpacking the luma and chroma channels from the RGB tunnel and assuming they are YCbCr results in a pink and green RGB image. Does this show the value should be set as2?signal_chroma_formatreported by dovi_tool is0, and from the capture is1. From US10701399 ifsignal_color_space == 0, this variable indicates thatsignal_chroma_formatvalues of 0, 1, and 2 correspond to 4:2:0, 4:2:2, and 4:4:4. Ifsignal_color_space > 0,signal_chroma_formatshould be set to2.- All
RGBtoLMS_coefvariables are significantly different. - The
min_pqin the Level 1 extension variable is12from dovi_tool, but62from the capture.
All the other variables present in the metadata extracted from the capture exactly matches that from the dovi_tool.
@DMDreview Given the number of different samples floating around, could you add the exact file you played for this capture to your uploads? This is to make sure I’m comparing with the right file in case something has been modified. Could you also confirm if this was played with CoreELEC set to lossless DV mode? In your original set of uploads you also had .dpx screenshots for the same file from an oppo, any chance of uploading the corresponding .mov to see if it is any different.
1 Like
Yes. test file is Minions Rise of Gru - P7 ST-DL FEL (original).mkv upload to disk it file.
It’s interesting that there are differences, perhaps this is due to tweaking to the EDID data reported by the TV. the signal in the tunnel is transmitted as ITP and 422. At least as I see it.
I made an additional capture of a regular 8 profile, there is L2 and L1 there too.
am6-rgb-colors-CX-5frames.mov
Try to decode it, whether there will be a difference. The source is called
03-DV-Color clipping P8 (1000nits).mkv
Pretty much the exact same results. Only difference is that the min_pq in the level 1 matches. I also find it interesting that in the gru sample the min_pq in the captured Level 1 block matches the source_min_pq. In the new sample, the level 1 min_pq matches the source_min_pq in both.
Would you be able to provide a sample from a ‘more trusted’ device, i.e., the oppo, not the am6?
I didn’t mention it before, but the captured metadata doesn’t include the Level 5 and Level 6 extension blocks that are reported by dovi_tool - I wonder if they are only transmitted once / infrequently and are assumed to remain constant until overridden. I’ll have to look into the dovi_tool and see if the metadata it reports for a frame involves any sort of history in the metadata blocks. @quietvoid any input about this?
oppo-min p7-rgb.mov minion from Oppo. but when i comparing with am6b, its the same.
As you already know, composing is done at the device and uses part of the metadata.
It’s possible that some mapping is done in advance to match the mastering display min luminance.
L5 is not used if the video is transmitted over HDMI, so I guess devices are removing it rather than the TV ignoring it.
It makes sense.
L6 is useless so that’s not surprising either.
1 Like
You are right, the embedded metadata is exactly the same to the bit when comparing the am6 and oppo.
The picture itself is not. Here are the differences in the luma and chroma channels.
| max | min | median | mean | |
|---|---|---|---|---|
| Iuma | 89 | 0 | 2 | 2.4066 |
| chroma 1 | 290 | 0 | 1 | 4.3741 |
| chroma 2 | 298 | 0 | 2 | 7.2217 |
This is a maximum difference of ~7% of the full 12-bit range. The image, in particular edges within the image, are clearly visible in normalised grayscale images of these differences.
luma:
chroma 1
chroma 2
Given that the picture seems to have been converted away from YUV before being tunnelled, this seems logical. @DMDreview could we have a profile 5 capture to see if this avoids conversions and more of the metadata aligns?
Not been following closely but throw this out there:
The AM6b is doing at least bicubic to convert from 4:2:0 storage to 4:2:2 transmission standards, understand the the Oppo does Nearest Neighbour which would result in sharper edges though not as overall good image.
If the processing in the composer is picking up min and max luminance, then will want the follow sink flag on otherwise it will be defaulting to 50 (1/10000 nits min) and 4000 nits max.
From a code perspective it looks like can also do RGB in the RGB Tunnel - not sure which Dolby Profile would allow that.
Do you think it’s possible to create a test image with RGB in the RGB Tunnel?
That what was being talked about previously. The linked test pattern in a 8-bit RGB png that is what should be tunnelled - with the metadata already encoded into the image. That is why bit perfect RGB output was being discussed - if this can be achieved (and maybe some flag set? - unsure on this one) - outputting this image should trigger tv-led DV on an unlicensed device. Just as has been done on a Raspberry Pi.
Shoutout to anyone with a device that is known to output bit-perfect 8-bit RGB images to try this please.
Could also just use the data from the captures
Thanks for the info. I was referring to cpm’s post where it seemed possible for the S922 to output RGB and I was wondering if it was possible to create a test build for this feature.
The metadata that is embedded in the tunnel does define options for color space, chroma format, and bit depth. I suppose these could be set to 8-bit RGB 4:4:4. The document does say the metadata should be placed into the lower bit of the chroma channel though - it seems likely though sinks (TV’s) are looking at the same bit in the RGB transmitted over the hdmi though regardless of what is in the metadata. So I suppose, I could then create a test pattern with metadata signalling RGB (I think this is what was being referred to as RGB in the RGB tunnel).
Seems a bit pointless to do so until someone can make the existing test pattern work though …
edit: if you want a test image for CoreELEC. you will need to ask someone else. At the moment I can only do the test png’s.
It also looks possible to transmit YCbCr in the RGB tunnel. Despite this, the profile 8 sample was clearly converted to IPT before being tunnelled - wonder if this is causing the differences in the metadata for the YCCtoRGB and RGBtoLMS seen in the captured data as compared to the dovi_tool
Forgive anything already been over and I missed - trying to lay this out to understand better.
For: Dolby Vision bit-stream Profile 8:
presuming dvhe.08 10-bit HEVC with CCID 1, Metadata carried in Unspecified NALu 63 ( None or limited[a] compression - imagine not using compression here so just like p7?)
Then would it go something like this:
p8 file HEVC YCbCr 4:2:0 Storage → convert to YCbCr 4:2:2 Transmission using bicubic → blend OSD (possibly need RGB conversion for this?) → convert to ICtCp 12bit → add scrambled RPU + CRC into chroma lsb → send data inside RBG 8 bit 4:4:4 (tunnel).
Yes for RGB in RGB Tunnel was talking about can transmit different types in the tunnel though starting to step outside the norm of p7 which I suspect is the path of least resistance for hw/sw compatibility - I would also think the Pi Gen would be doing this for that PNG to work.
I don’t think RGB in RGB Tunnel is needed for Pi Gen to make test patterns work - seems no need for it.
My understanding is essentially the png is the RGB 8 bit 4:4:4 data that corresponds with what is sent over the hdmi after everything is packed into the tunnel. The pattern is meant to show a blue tick in the SDR box when dolby vision is not working (easily seen by opening the image on a computer), and a blue tick when dolby vision tunnelling is working.
I have unpacked the 12-bit luma and chroma channels from the png and reformed the image - and the tick does move to the dolby vision window. But when forming the image, I used a YCbCr conversion to get RGB - and the resulting image is has that pink/green look. This makes me think that the actual color space of the data is IPT and not RGB - despite this the metadata embedded in the image does indicate a YCbCr 4:2:2 full range data.
My current thinking is that signal_bit_depth (8-16 inclusive), signal_color_space (YCbCr, RGB, or IPT), and signal_chroma_format (4:2:0, 4:2:2, or 4:4:4 - document says only applies for YCbCr color space, despite this the two captures we have seem to show the variables simple match the format of the tunnelled data) might be able to be used in any combination with a matching bitrate to RGB 8 bit 4:4:4 (or maybe higher bit depth? - 8 bit RGB could just be a typical example that matches 12-bit 4:2:2). The document places no other limitation on the combination of these, as you say though - who knows what sinks are actually compatible with
1 Like
What part of this would need any special DV hardware / license? Seems like all these pieces are now known. Where does the DV module/license currently become involved in this process in CoreELEC?
I wonder if this could be potentially simplified for profile 8 (even more so if the osd is ignored for now) by tunnelling in YCbCr format. Not sure when the change from 10 bit to 12 bit would happen though …
If this is the right reference color space conversions seem to happen before blending (in what space?) the osd and video planes.
Can someone that actually know how CoreELEC (not even DV specific) actually works with the OSD plane, video plane, blending, and what color space conversions happen for blending/hdmi output please provide some input into what goes on?