I’m interest in learning more about how DV is implemented in CoreELEC, which parts of the implementation fall in the parts of the code that we have access to vs which parts are in the kernel module/licensed soc hardware.
To start with, I’ve had an idea of trying to enable a dolby vision output myself - not playback of a DV file, just triggering the DV logo on the TV. The device I have available to play with has a S905X3-B processor, which in here was determined not to be a certified SoC that supports DV based on the DV capability reported by the dovi.ko module.
My question to those that have a better understanding is: Despite this, do we know if it is technically possible to trigger the DV logo on a TV with that SoC?
If so, any pointers to relevant parts of the code? If not, what is the technical reason?
I also invite anyone that can provide any information / links that would help understanding how DV is implemented. I have struggled to find any documentation on this - only snippets of code.
Updates: I was able to make some progress by changing line here to look for a 6 instead of a 7. This enables the DV options in the CoreElec settings menu. When trying to play DV files my TV does not engage DV mode and CoreElec shows that the output 12 bit YUV444 in SDR. In dmesg, however, I did find
I find this more interesting as it indicates success in creating a metadata parser instance. I don’t know if this message is incorrect, if the message shows that not all parts of dolby vision require a licensed chip, or that the chip actually is licensed. Does anyone know how to determined which of these it is?
Adding to my uncertainty is that it appears that this message comes from the dovi.ko - this is based on me not being able to find the text string Creating Dolby Vision metadata parser instance success in the corelec code, but in the file dovi.a.c provided by @djnice in this post.
As mentioned by @YadaYadahere the dv capability is apparently determined by an efuse that we can’t change. We can however, change the code that reads that efuse, which I have done by simply adding the line efuse_mode = 0; before the dv capability is determined by support_info = efuse_mode ? 0 : 1;/*bit0=1 => no efuse*/ in the file amdolby_vision.c.
After doing this I am now able to trigger the DV logo on my TV when using player-led mode - no video plays though and the screen is black. In TV-led mode, I get a pink screen - but the DV mode does not trigger on the TV. Instead it reports BT.2020, but does not report HDR.
I have no idea if any of this info is helpful, but it does show that a non-licensed device can output a signal recognised as DV in player led mode. Next up is trying to do the same in TV-led mode…
I haven’t been yet been able to engage TV-led dolby vision, but it does appear that the coreelec box seems to be entering the correct 8 bit RGB full hdmi mode with a DV-Std EOTF. I suspect the problem is the TV needs the correct DV RPU metadata to be encoded within the data in the RGB tunnel.
In light of this, I have found the idea of using ‘pre-encoded’ images to enable TV-led DV. The idea here is that you output a 8 bit RGB image (that is essentially what is sent over the RGB tunnel) that contains the required metadata. This idea is discussed here and appears to be successfully used by PGenerator 1.3 (see here and here) to enable TV-led DV using a Raspberry Pi.
While I assume these images could be from captured data from a working RGB tunnel, I have found this test pattern that should clearly demonstrate if a TV-led mode is working correctly. I have manually verified that this pattern does contain metadata embeded into the correct bits of the image.
Help wanted
While I have the test pattern, and can force RGB 8-bit mode from the CoreELEC settings menu, I don’t know how (or even where to look in the code if it needs to be modified) to enable all the correct HDMI modes, EOTF, flags, etc for TV-led DV when displaying an image.
Could someone that has a much better understanding of CoreELEC help me out in doing this? Essentially, I want to output the contents of the linked test pattern, with the HDMI mode setup as it should be for TV-led dolby vision.
As far as I can tell, this is all that is required to activate TV-led dolby vision mode and doesn’t require a license soc.
Interesting possibility - the patent doc I posted on the other thread also states the sink (TV) identifies by the scrambled RPU data and associated CRC:
“The Dolby Vision display verifies that it is connected to a Dolby Vision capable source device (i.e. the UltraHD Blu-ray player) by checking the validity of the metadata CRC (CyclicRedundancyCheck) as defined later”
I don’t think anything other than RGB 8bit is required for the HDMI setup, the issue I would think is sending your test data though verbatim from the source.
The open source amlogic code is already doing the RPU extraction / bit scrambling (with Core 3) maybe that can work without the licence, the closed element could well be just for processing the RPU on box (i.e. the true IP of dolby is really in the processing of the RPU in application to the image)
There is an outside possibility the current code maybe able to be used in true tv-led - maybe just bypassing the dv enabled checks?
My first attempt was to manually set the kodi resolution to 1080p (to match the image), force 8-bit RGB mode, and then open the image - didn’t work though.
Thinking it may be the EOTF / other hdmi settings, I modified the code with a flag I can set via SSH to skip doing anything in the hdmitx_set_current_vmode function. I then started a 1080p dolby vision file to get a reported 8-bit RGB full DV-Std ouput, set the flag, stoppped the video, checked the reported output hadn’t changed and navigated to the image using the live video of hyperion (as the TV doesn’t show anything as some as the box enters DV mode). Still didn’t work.
Next I’ll try to see if the output is actually being output ‘bit perfect’. Thought was to try and use the screenshot code from here to see if the image is exactly being output. I’m not sure though if this captures the data exactly as it would go out of the hdmi though… Does anyone know the answer to this?
A way to exactly capture the raw bytes that are transmitted over the hdmi would be ideal and would make it easy for other with boxes that can do DV to provide samples without needing external hardware. Does anyone know how to do this? Bonus points if we can modify/set the data as well just before it is sent.
I’m also not entirely sure of the test pattern, I’ve extracted the metadata bits and can make sense it some of it, but I cannot seem to get a calculated crc to match the one in the data. Actual samples from someone with a working TV-led setup and an external capture device would be ideal at this point.
Already said he would provide data here. Haven’t received anything yet though.
I have now fully decoded the embedded metadata in the test image I linked in a previous post. It only has level 1 data though, but I believe I can also decode all the other levels. Bumping @DMDreview@djnice and anyone else that can provide captured data of tv-led DV from a known sample that has as many possible levels to confirm the decoding.
“The Dolby Vision display verifies that it is connected to a Dolby Vision capable source device (i.e. the UltraHD Blu-ray player) by checking the validity of the metadata CRC (CyclicRedundancyCheck) as defined later"
I don’t think anything other than RGB 8bit is required for the HDMI setup, the issue I would think is sending your test data though verbatim from the source.
Yet in TV-led mode the function hdmitx_set_vsif_pkt still seems to be setting specific DV related packets, i.e., hdev->hwop.setpacket(HDMI_PACKET_VEND, VEN_DB1, VEN_HB); or hdev->hwop.setpacket(HDMI_PACKET_VEND, VEN_DB2, VEN_HB);
My thinking is that tiggers the TV into the correct “mode” - i.e. AVI info setup, but the dolby code (running on the tv) also verifies in the actual signal in tv-led - so both are needed, if the CRC is not good then no processing.
That makes the most sense. I’ll try to modify the code so I can set those packets without turning on the rest on the dolby vision code. Me being able to test that though relies on the test png being output bit perfectly…
For anyone with capture hardware, I’ll make that another request - a capture of this test pattern open in coreelec with the kodi gui set to 1080p 8-bit RGB.
I apologize, I’ve been busy these days, in a couple of hours I’ll discount the dpx files with rgb capture.
By the way I was thinking that theoretically it is possible to tv-led video sent from PC, initiating DV by sending RPU data. It is possible to do such a trick and get DV tv-led from PC.
What exactly would you like to provide, I can capture from Oppo and am6b? +CE.
Here is my wish list of captured data, all in TV-led tunnelled mode and ideally from known samples / frames on that google drive link (so that I can compare to the actual RPU data)
Capture of the RGB tunnel from a profile 7 FEL sample (oppo or am6b in true-tv led mode)
Capture of the RGB tunnel from a profile 7 MEL sample (oppo or am6b in true-tv led mode)
Capture of the RGB tunnel from a profile 8.1 sample (oppo or am6b in true-tv led mode)
Capture of the RGB tunnel from a profile 5 sample (oppo or am6b in true-tv led mode)
Capture of the RGB tunnel from a sample that is actively using cmv4.0 data / as many different metadata levels as possible (oppo or am6b in true-tv led mode) ( this probably doesn’t need to be a separate test, should be covered by the others)
Capture of the RGB tunnel from of this test pattern open in coreelec with the kodi gui set to 1080p 8-bit RGB. (from am6b, this is to test if CE produces a bit-perfect output, which is needed for me to be able to test / get tv-led dolby vision working.)
If possible, a video capture (just so I can test on lots of frames - less important at this point)
I’ll take as many of these as you are willing to provide. Thanks in advance.
I do agree with you in that I think it is possible to do TV-led DV on unlicensed devices - with the current interest in DV I’d like to see how far we all can get towards this point.
The success of Pgenerator using a RPi 4 to enable TV-led DV shows standard hardware can output TV-led DV.
This just leaves how to handle the DV metadata from a video to form the correct data to put into the RGB tunnel and what bits to embed in the stream. There are two components of the total DV metadata:
Composing metadata. This is used to map the base layer with polynomial or MMR mapping and also to perform the non-linear quantization of the enhancement layer video. This is essentially the metadata used to form the 12-bit 4:2:2 data that goes into the tunnel. From what I can see in the patents / and the existence of tools like DoviBaker, it is known how to use this metadata to form the signal that should be tunnelled.
Display management metadata. I haven’t seen anything on how this is used - but I don’t believe we need to - this is the metadata that is embedded into the video stream in TV-led mode for the display to use. From playing with the test pattern I linked, it appears the metadata embedded within the RGB tunnel is actually a minor and straightforward repacking of the display management metadata from the original video stream that the dovi_tool already extracts.
Based on these two point, it appears to me that TV-led DV is partially a passthrough format - and the part that is not a straight passthrough is known how to be done. Can anyone with a better understanding of DV please provide comments on the correctness of this
I did a test on the CM4.0 video and the Oppo was outputting different RPU data than the Am6b.
But on cm2.9 video they were identical.
I will try to send some tests today.
