Learning about Dolby Vision and CoreELEC development

Unsupported/EOL HW/SW Community Projects
465

They are completely incorrect.

The BL_EL test image works in LLDV so that means it cannot be converted into P8.

In that conversion, the EL (enhancement layer) is completely dropped, only RPU is kept. So if the BL_EL test image works (EL being processed), it means there cannot be any conversion into P8 where it would be dropped.

All LLDV means is the EL and BL are combined at the player based on TV EDID settings vs the TV doing the processing. There is absolutely no conversion to P8, and conversion to P5 isn’t even possible.

1 Like
466

If related to this, the hdmi captures (p8.1, p5, and p7 FEL) of the tv-led tunnel showed that the display management metadata are embedded in the top rows of the video signal. Guess this shows the tv is processing that information, and not the player (i.e., as it would in LLDV mode).

For p7 FEL, the player does need to do some “processing” to apply reshaping to the base layer and then compose with the enhancement layer - this process uses DV metadata that is not sent to the display. Similar for profile 5, but only the reshaping part.

Not sure which discussion you are referring to, but the hdmi captures also show the video from all profiles were transmitted in the ICtCp colorspace. Maybe this is related? In any case, for profiles that are not ‘natively’ in the ICtCp colorspace, this show an unnecessary conversion as the colorspace can be specified in the metadata sent to the TV.

3 Likes
467

Thank you. That is what I thought but wanted to confirm.

468

“Not sure which discussion you are referring to, but the hdmi captures also show the video from all profiles were transmitted in the ICtCp colorspace. Maybe this is related? In any case, for profiles that are not ‘natively’ in the ICtCp colorspace, this show an unnecessary conversion as the colorspace can be specified in the metadata sent to the TV.”

Thank you for the further detail explanation. The debate is solely based on LLDV capabilities and limitations. - I thought that for LLDV the colorspace used to send to the TV through hdmi is always YCbCr since it is already processed by the source device?

469

What @doppingkoala is saying is DV-Std can be YCbCr but commercial products always look to be using ICtCp even though with a P8.1 source that looks to be a wasted conversion.

DV-LL is typically always YCbCr (basically a HDR10 signal) but it can also be RGB 10 or 12 bit! in the later DV standards but again not seen that used commercially both player and display would both need to support.

2 Likes
470

Whoa that’s incredible. I need to give this a try on my N2.

471

Yes, unbelievable to me also until I tried it and got Dolby Vision on my old N2 :joy:

472

Hi @doppingkoala, can you help me please as I am still getting crashes on NG-NO-Beelink GSKX.
https://paste.coreelec.org/FlashesHanks
https://paste.coreelec.org/ToothedSlamming

Thanks.

473

Seems like there are still some kinks to be worked out? Is it worth running as a daily or just to experiment?

474

Not for a daily driver, I use it just to experiment; for everyday use I molest an AM6B+ :slight_smile:

475

For sure I have a Ugoos as well for my main TV setup. But just got a new set and moved the old one to a bedroom so now the bedroom set does DV. I’ll play around with this when I get some free time.

476

Lets start with getting the -ng version working. To simplify things

  • Clean install of 20.5 without changing any settings
  • Update to the build from this post
  • Change only the following settings and reboot

If you have issues after that

  • Photo of the kodi settings page to confirm you have made the correct changes
  • After a reboot enter
echo 2 > /sys/module/amvideo/parameters/dv_injection_log_level
  • Play a DV file and post a dmesg log

After we get -ng working we can move onto looking at the -no version.

477

For the -ng version, all reported issues so far have been solved by following the setup instructions correctly…

I haven’t seen any issues at all while using it.

Only issue I am aware of is using the whitelist to play 1080p DV files with a 1080p output would probably cause a problem with the current build available to download.

The -no version may have an unresolved issue for some devices. I suspect @xmlcom has found a problem when using a gs king-x.

478

The -no version is for me unwatchable because of distinct subtitle stutter on my Odroid N2 and Ugoos AM6B+ devices.

479

Should go without saying that these builds will also have all the problems of the builds they are based from. Do you also have the subtitle stutter problem in the -no nighties?

480

On the topic of problems with the CE builds this work is based from, I am seeing a audio offset in the -ng builds.

I haven’t managed to find any build of CE without audio sync problems, does anyone know of one?

481

Haven’t tried any newer, last about a month ago. Gave up trying since it’s a known behavior, and have not seen that it has been solved…

482

Update:

Changes:

  • Removed need to any particular settings. Nothing is required to be done after installing.
  • Now DV works in both 1080p and 4K output modes. For anyone that changes the default kodi settings, outputting in the native resolution of the file is required for correct L5 trims.
  • Use the (hopefully) improved method for DV from hdr10+ from this post.
  • Injects the metadata using pixels with a much lower luma value than before. For those with TV’s that a L5 trim causes a semi-transparent bar this should make the injected data close to invisible. fyi @noggin
  • Change to use the 12-bit YUV422 tunnel mode.
1 Like
483

This one is actually interesting. In the amlogic code there are four different tunnel modes YUV422_BIT12, RGB_8BIT, RGB_10_12BIT, and YUV444_10_12BIT. Up until this point, I have been using the 8-bit RGB option as that is what everyone said was needed to do tv-led DV.

Turns out this is not true, I am getting tv-led DV using a 12-bit YUV 422 signal that is flagged as full range YUV in the avi packet. For refence, I am using a X90J tv, from which CE reports

CoreELEC:~ # cat /sys/devices/virtual/amhdmitx/amhdmitx0/dv_cap
DolbyVision RX support list:
VSVDB Version: V2
2160p60hz: 1
Support mode:
  DV_RGB_444_8BIT
  LL_YCbCr_422_12BIT
IEEEOUI: 0x00d046
EMP: 0
VSVDB: eb0146d00048238288627697

Key point here is that the reported RX capabilities are clearly incorrect as the TV is doing tv-led in a 12-bit YCbCr 422 mode. Raises the interesting question of what other modes are supported by both my tv and more generally. Does anyone know what is the source of this displayed info? i.e., how to correctly determine the DV capabilities of the tv?

Under the assumption that many other TV’s also support tv-led in 12-bit YUV 422, this also solves what could have been a major difficulty in getting tv-led DV from a computer. It avoids the need to abuse the avi packet in a way that is easy in CoreELEC due to the very low level access, but likely very difficult on a computer. For a minimal proof-of-concept fro tv-led DV on a computer, all that is now required is finding a way to send the correct vsif.

This may actually not be impossible, from a quick look it appears the nvidia api can do it with the NV_HDR_MODE option of NV_HDR_MODE_DOLBY_VISION which is described as

Experimental mode only, not for production! Source: RGB8 Dolby Vision encoded (12 bpc YCbCr422 packed into RGB8) Output: Dolby Vision encoded : Application is to encoded frames in DV format and embed DV dynamic metadata as described in Dolby Vision specification.

Source of the quote (NVAPI Reference Documentation)

TL;DR

  • TV-led does not require a 8-bit RGB signal, or for the avi packet to be incorrectly set to full range RGB.
  • The reported DV capabilities of a TV by CE are incorrect. TV’s don’t correctly report the supported modes…, i.e., X90J.
  • Unknown how many TV’s support tv-led DV with the hdmi signal in 12-bit YCbCr 422 mode. Can anyone that tests my latest build comment if it works or and the model of TV?
  • A proof-of-concept (using a pre-encoded video with baked in metadata) of tv-led DV from a computer now just requires a way to send the vsif.
484

I think the EDID tells the player what it supported.

This is my C2 edid:

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    DM Version: 4.x
    Backlt Min Luma: 75 cd/m^2
    Interface: Standard + Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 20 (0.00063665 cd/m^2)
    Target Max PQ v2: 3030 (896 cd/m^2)
    Unique Rx, Ry: 0.67968750, 0.32031250
    Unique Gx, Gy: 0.26171875, 0.68750000
    Unique Bx, By: 0.14843750, 0.04687500

Hisense TV:

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    Supports YUV422 12 bit
    DM Version: 5.x
    Backlt Min Luma: 75 cd/m^2
    Interface: Standard + Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 0 (0.00000000 cd/m^2)
    Target Max PQ v2: 3095 (1037 cd/m^2)
    Unique Rx, Ry: 0.67578125, 0.30468750
    Unique Gx, Gy: 0.25781250, 0.69531250
    Unique Bx, By: 0.15234375, 0.05468750

Old vizio TV:

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 0 (26 bytes)
    Supports 2160p60
    DM Version: 2.8
    Target Min PQ: 124 (0.02015421 cd/m^2)
    Target Max PQ: 2908 (681 cd/m^2)
    Rx, Ry: 0.67651367, 0.30566406
    Gx, Gy: 0.25732422, 0.65771484
    Bx, By: 0.15234375, 0.04956055
    Wx, Wy: 0.31274414, 0.32910156
  Video Capability Data Block:
    YCbCr quantization: Selectable (via AVI YQ)
    RGB quantization: Selectable (via AVI Q)
    PT scan behavior: Supports both over- and underscan
    IT scan behavior: Supports both over- and underscan
    CE scan behavior: Supports both over- and underscan

Sony A1

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    Supports YUV422 12 bit
    DM Version: 3.x
    Backlt Min Luma: 100 cd/m^2
    Interface: Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 0 (0.00000000 cd/m^2)
    Target Max PQ v2: 3225 (1387 cd/m^2)
    Unique Rx, Ry: 0.70703125, 0.29296875
    Unique Gx, Gy: 0.17187500, 0.79687500
    Unique Bx, By: 0.13281250, 0.04687500
  Colorimetry Data Block:
    xvYCC601
    xvYCC709
    BT2020cYCC
    BT2020YCC
    BT2020RGB

Sone A95

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    DM Version: 4.x
    Backlt Min Luma: 100 cd/m^2
    Interface: Standard + Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 0 (0.00000000 cd/m^2)
    Target Max PQ v2: 3290 (1604 cd/m^2)
    Unique Rx, Ry: 0.70703125, 0.29296875
    Unique Gx, Gy: 0.17187500, 0.79687500
    Unique Bx, By: 0.13281250, 0.04687500