Dolby Vision - VS10 Engine on Ugoos AM6+

Looking forward to any progress you make.,

If anyone has a better way of toning down the white/light brightness on SD content besides lowering the TV brightness setting, I would love to hear it.

Yeah, I noticed this last month with Yojimbo actually. So probably nothing to do with this build. These movies are listed as SDR but HLG gets triggered somehow.

1 Like

Ok i have tested now with my set up Am6b-> ezcoo-> Epson ls12000

-sdr 720/1080 mkv =ok get lldv
-dv 4k mkv = ok get lldv
-uhd iso = ok get lldv
-hdr 4k mkv = not ok , black screen , only sound.
I only have 2 hdr rips and booth had black screen . Both files is something like “moviename.2023.hdr.web.h265.mkv”

Avatar 2 from uhd iso looked amziing playing in lldv. Great work , big thanks !

edit , with this:
echo 0 > /sys/module/amdolby_vision/parameters/dolby_vision_policy
echo 45 > /sys/module/amdolby_vision/parameters/dolby_vision_hdr10_policy
moviename.2023.hdr.web.h265.mkv played but wrong colors: green/purple

Possible to try without the ezcoo in the path?
(presuming that is advertising your Epson to the Ugoos as being a DV projector)

Without ezcoo i wont get lldv :upside_down_face:
Is there some command to send all videos , but not hdr10 videos trough vs10?
Anyway not a big problem for me as i only have 2 hdr 10 files.
But funny uhd.iso played in lldv but not hdr.mkv …

Add up the sink values for the non-HDR and echo that to the parameter, should then treat as normal for HDR

looks consistently wrong for HEVC SDR10 with bt2020


Off topic but this is the only thing I could find about the HLG issue, I can’t link to the forum because it’s blocked for whatever reason.

Topic title: SDR bt2020 tagged as HLG

Question: Odd thing I noticed today: if I set Settings / Videos / Processing / HDR processing to “BT2020SDR”, and play an HDR video vfile, the video output is reported to the display as HLG HDR instead of SDR. I assume that’s not intentional?

Answer: Sadly, it is intentional. AMLogic assume any HDR video that’s not HDR10[+] is HLG. And a couple of years ago they removed the ability to identify an HLG SEI from their microcode.

So yeah, I guess there is a bug with sdr bt2020.

1 Like

Sorry but no ide what you are talking about :face_with_hand_over_mouth: Can you please give me the command to try ?

Not complex once you see it -

Filtering out the sink values we get:


So if just want to convert to DV from HLG and SDR add up 8 and 32 = 40 and echo that I.e.

echo 40 > /sys/module/amdolby_vision/parameters/dolby_vision_hdr10_policy

For just SDR then:

echo 32 > /sys/module/amdolby_vision/parameters/dolby_vision_hdr10_policy

HDR10+ is a slightly special case as will discard the + metadata and just convert HDR10 to DV.

For that need to add:


So if wanted SDR and HDR10+ then would be 32+4

echo 36 > /sys/module/amdolby_vision/parameters/dolby_vision_hdr10_policy


@cpm one more thing (good) GUI stays on dolby vision after first playback
On boot my Nad reciever reports YCbCr 422 12bits , and for HDR ----- (no dolby vision shows here)
On first play my projector goes black for resolution switch to YCbCr 422 12bits , HDR Dolby vision
after i stop the Nad reciever reports YCbCr 422 12bits , and for HDR Dolby vision. So next time i play the same file , video starts with no black screen/ resolution switch . This is great !! I watch a lot of live tv so if i had have black screen/resolution switch every time that would have been bad.

Now to the question: is it possible in the future to boot the box with 1080p50 YCbCr 422 12bits , HDR Dolby vision right from start ? Without the need for first resolution switch ? And then have the box change back to 1080p50 YCbCr 422 12bits , HDR Dolby vision after i play some 4k 24p files ?

I think what you are after is a setting for DV in the standard Kodi UI setting/setup - you would need to ask with the CoreELEC / Kodi team to see if they can add that - I do know these boxes are capable to boot into DV directly if desired.

At present the premise for Kodi is to switch into the correct mode for the video playing and then back after to your preferred UI settings (if those match then fine no switch needed - and I think there is some stuff around upscaling and whitelisting that changes this behaviour a bit - though don’t know the detail on that), unfortunately it is more a bug causing it to stay in DV after playing so expect that to revert later!


I compared the output against Zidoo’s implementation - looks very very similar if not identical. I wish I could screencap both and compare.

I was trying to look for difference between the real tv-led on the ugoos box vs the fake-tv led from Zidoo in VS10 mode. If there is one, I cannot easily spot when toggling sources between the 2x.

Zidoo flashes the VS10 logo on the screen in addition to the Dolby Vision logo on start/stop. Very small detail, but I wonder if Ugoos can do the same thing, I don’t know if that’s controlled by the dovi.ko module or if that is something the Zidoo team cooked up.

1 Like

I think the only method to compare would be like R3S3T_9999 in a controlled environment and capture from the TV with a manual set camera.

For the “fake” vs "real’ tv-led - one way maybe the brightness of the dolby vision bright modes on the TV - if seeing any difference, otherwise need equipment like DMDreview to capture the hdmi and inspect the image for the embedded RPU data.

Not sure on the VS10 logo, VS10 is only mentioned once in code around the hdmi tx so maybe something there. When converting SDR etc to DV the code comments call it “Dolby Core”.

If someone had both devices and an HDFury, and was willing could capture the VSI Info Frame and see if there is anything different that may trigger a VS10 logo (if it is a standard DV thing)

Next task for me is add some menus to control this - I think will stick with the VS10 name for those.

  • Add Menu Control for VS10
  • Add Menu Control for tv-led colorimetry
  • Attempt to fix SDR10 bt.2020 issue (looks like code incorrectly interprets the signal transfer characteristics 14 as being HDR HLG - from the ITU docs it look like it should only be 18) - though some other online sources also mention 14.

I don’t understand 99% of the work you’re having to do but I appreciate it nonetheless. Thanks for working on this. I’m gonna pick up an SD card tomorrow and try your test build. My other SD card died last week. :roll_eyes:

Thank you for your awesome work. It seems for the colorimetry flag, the most correct thing to do would be to read the flag from the metadata and then set it in the same manner as FEL/MEL. I’ve actually seen UHD media have a BT.709, P3, and BT.2020 flag. I think for the menu setting, it might be best to have it set to Automatic by default and off by choice.


  • New menu items under Settings → CoreELEC
  • DV Display Led (tv-led) Colorimetry
  • DV VS10 enabling by SDR, HDR, HLG
  • DV Luminance use the Min and Max from the HDMI Connection

Edit: Version removed - please see new version in later post.

Quick testing so far in tv-led.
DV VS10 enabling / disabling ok for :

  • SDR8 bt.709
  • SDR10 bt.709
  • HDR10 bt.2020
  • HDR HLG bt.2020

There is an issue with the AMLogic code for SDR10 bt.2020 - not found a solution for that yet, it will play as HDR HLG by mistake. (Note: not related to these changes but just noticed because testing more!)

Kodi currently does not differentiate HDR10 and HDR10+ where I am checking in code - so both HDR10 and HDR10+ settings trigger both to be processed by VS10 - until I can find away to isolate them. If I cannot then will need to reduce to just one setting for both which is not ideal.

With this version no need to change anything using the command line or use now.

Can still use command line if want to change on the fly to more easily compare.


Thanks, great work!
Can you also get it to use VS10 for HDR->SDR conversion?

Did not come across that so far, though I think there maybe something along those lines for when TV cannot support DV, HDR it will down convert.

There is already a setting for Tone Mapping HDR → SDR (don’t known what that uses)

I think the colorimetry referred for those UHD (assuming they are DV UHD) is for the BL (fallback) layer, that would make sense to send that if was using just that fallback layer - for example in on non-DV aware equipment.

Caveat: My reading and understanding below - very likely missing something but this is my best understanding at present:

For DV from my reading it is all getting converted to an ITP (BT.2100 variant) and the DV Engine in the TV knows how to covert correctly to the RGB of the display.

So in the common case tv-led for UHD DV FEL it is: 10bit YUV420 BL and I think 10bit IPT420 EL (really carrying just the delta 2bits of difference between the BL and the upstream master) composed into an 12bit IPT422 (with the RPU embedded into the LSB of some of the pixels) final image sent down an RGB 8bit tunnel (in the same format structure of 12bit YUV422) !! - so all rather simple - not.

So having a colorimetry at all is really not informative in this case - hence those that think it should be “blank”. The whole 8bit RGB Tunnel thing was before the ITU BT.2100 was created to formally cover this standard, otherwise that may have been a sensible flag to use.

The argument to have a colorimetry is for likely “bugs” or mis-processing in older TV implementation where somewhere in the processing it still picks it up - in that case BT.2020 is the closest as at least it in the same WCG ball park and the one advised to use from the Dolby SoC IDK (likely to cover those issues).

Whilst on this subject I also have a suspicion that the BL for DV UHD although backward compatible and normally in BT.2020 is “made” to favour the conversion to IPT, so another reason really want to watch these properly converted.

BTW thanks everyone for the complements and encouragement - I do this as a hobby, learn new things and help stay up to date in different tech in the development world, but really appreciate all the feedback.