Dolby Vision - VS10 Engine on Ugoos AM6+

no, the function partially works, DV in profile 5 is shown in HDR. So you can’t say that it is pointless.

Well, in this case, my guess would be DV8/DV7 all have base HDR10 layer. VS10 just play HDR10 as it is. What can we expect of DV8/DV7 to HDR10? Tone mapping? Isn’t that the same as LLDV does?

It is very similar to LLDV, but the Display does not need to be DV capable, for example could plug into a Samsung TV without any third party device and would just work in HDR10.

Though a bug AMLogic side somewhere so it is not working correctly, and I think that bug is in the proprietary code of the dovi.ko so not something can help fix.

Super excited for the next major release that adds this and the dual-track FEL compatibility.

1 Like

DTDL is already in the latest nightly which I suggest running.

Sorry if this is a noob question. But I thought the CE OS was Read-only. So how is this possible?

It is not read only. You can issue commands on the fly for certain parameters to adjust and tweak to your liking. The colorimetry flags are one of those parameters.

Connect to your box via SSH, and you can issue commands to adjust or find out more information.

1 Like

Just tried on my Odroid N2 with this result:


N2:~ # echo Y > /sys/module/hdmitx20/parameters/test
-sh: /sys/module/hdmitx20/parameters/test: Permission denied
N2:~ #

The parameter is created in the code when the module loads, so need the version that creates it, once created it has permissions set to then allow you to overwrite it.

1 Like

Understand now, thank you.

Also,
echo Y > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry

is more correct for DoVi. I put this is autostart.sh until CPM’s upcoming changes are merged.

Thank you, much appreciated.

Noob question - what is CPM?

A lead developer of the CoreELEC dovi code.

1 Like

Thanks again.

So once CPM’s changes have been done, what needs to happen if you have setup:
echo Y > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry
in autostart.sh.

Delete autostart.sh.

1 Like

What I mean is that it might not be a ‘bug’ in dovi.ko because DV5 works. DV5 uses a different color space so DV5 to HDR10 is required on HDR10-only TV. DV8/DV7 has HDR10 base layer. If user wants the best of DV8/DV7 either with STD-DV or LLDV, go buy a DV capable TV from business point of view.

If my assumption is true, can you do something after dovi.ko processes video? i.e., do LLDV first, then remove LLDV requirement before passing the signal to HDR10-only TV? (as you add/remove/change color space flag)

The defects are ignoring the hdmi luminance and ignoring the RPU.

An easy one to test yourself is using an out of sync RPU dv file:

For DV → SDR10 can see the RPU change being applied
For DV → HDR10 cannot see the RPU change being applied

——-

That aside it maybe possible to fake the EDID / work around the VSI not being present and thus allow LLDV (presuming the dovi.ko does no further checking hidden to us)

For DV p5 LLDV I am thinking it is not ITP space on the output but is already converted to YUV because of the devices that can be used to fake the EDID - but have not checked to be sure - ie the only true ITP is the tunnelled tv-led signal?

Note: I am pivoting to some of my other projects but may come back to this in the future.

1 Like

I think DV p5 LLDV should have been already converted to YUV. Otherwise, user should see green or purple picture on non-DV display.

Thank you for your efforts. DVtoHDR is not my concern. Just curious how can make it work under current situation. :slight_smile:

Is it Possible to somehow blacklist SD / HD TV Channels (TV Headend) so they don’t trigger VS10 but HD videos do? Thank you.

2nd gen Cube source is available here, kernel source is in the platform.tar