Dolby Vision for Minix U22X-J (Max) and Ugoos AM6+

I have just tried this on my Philips 808, and first of all I don’t know if this TV supports TV-led but I’ve had no issues in that mod so far.

In my tests rpu is not processed at all when that flag is set to 2.

I’ve used the out of sync test files from this folder, they have easily noticable rpu changes throughout the video.

RPU RESPONSE TEST - Google Drive

Movies probably don’t do such drastic changes by scene, so please test your findings with these videos instead.

2 Likes

Thanks Kaan.

Yep you are correct it is not processing the RPU set to 2, guess I am just preferring something about that setting.

Back to the drawing board to understand more…

I think the bulk of the RPU processing logic is contained in these rather large methods:
parse_sei_and_meta_ext (line 6148)
which is called by:
parse_sei_and_meta

The parse_sei_and_meta_ext calls the function is_meson_tvmode repeatedly in several if statements. Only tm2 and txlx SOC types ever return true for that function.

Further it seems like those two SOCs specifically have an additional CORETV_BASE address. My guess is that’s related to the metadata processing that the g12 SOCs do always. My hunch is indeed the SC2 and G12 SOCs lack that crucial difference.

This section is interesting though:

FLAG_CERTIFICAION
/* bypass dither/PPS/SR/CM*/
/*   bypass EO/OE*/
/*   bypass vadj2/mtx/gainoff */

So may want to play with that flag setting.

Perhaps?

#define FLAG_BYPASS_CVM				0x02
#define FLAG_BYPASS_VPP				0x04
#define FLAG_CERTIFICAION			0x40

#define FLAG_DISABLE_COMPOSER		0x100
#define FLAG_BYPASS_CSC				0x200
#define FLAG_FORCE_RGB_OUTPUT		0x8000

0x8346

1 Like

I think you are referring to the code base under Android TV 13.

https://android.googlesource.com/kernel/arm64/+/refs/tags/android-tv-13.0.0_r0.6/drivers/amlogic/media/enhancement/amdolby_vision/amdolby_vision.c

I am thinking this box would be similar to the code under Android TV 9?

https://android.googlesource.com/kernel/arm64/+/refs/tags/android-tv-9.0.0_r0.3/drivers/amlogic/media/enhancement/amdolby_vision/amdolby_vision.c

Though had noticed the parameters that are being created (below), some of those only seem to apply to the Android TV 13 code. like force_best_pq.

Will look into the TV 13 code next.

As I understand this box is not Android TV but Android 9 - AOSP, and I believe Ugoos must be adding the amlogic library for a custom build - do you know a way to be sure what the code behind the build is?

-rw-rw-r--    1 root     root          4096 Feb 29 23:33 vtotal_add
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 vpotch
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 set_backlight_delay_vsync
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 sdr_ref_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 primary_debug
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 panel_max_lumin
-r--r--r--    1 root     root          4096 Feb 29 23:33 is_mel
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 g_vtiming
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 force_update_reg
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 force_mel
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 force_best_pq
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_ll_output_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_graphic_blend_test
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_cert_graphic_width
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_cert_graphic_height
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_wait_on
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_wait_delay
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_tuning_mode
-r--r--r--    1 root     root          4096 Feb 29 23:33 dolby_vision_target_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_status
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_src_format
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_run_mode_delay
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_run_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_reset_delay
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_reset
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_profile
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_policy
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_mask
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_ll_policy
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_level
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_hdr10_policy
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_graphics_priority
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_graphic_min
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_graphic_max
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_flags
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_enable
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_efuse_bypass
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 debug_dolby_frame
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 debug_dolby
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 cfg_ll_id
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 cfg_id
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 atsc_sei
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 ambient_test_mode

FLAG_BYPASS_CVM looks to always switch the RPU processing off.

dolby_vision_graphics_priority always looks to be being set to 1, cannot override - thinking maybe a settng in the base Android OS, need to check there.

I have been referring to:
https://github.com/CoreELEC/linux-amlogic/tree/amlogic-4.9-20-DV/drivers/amlogic/media/enhancement/amdolby_vision

1 Like

I’m using CoreELEC on the Fire TV 2nd gen Cube (s922x) with Dolby Vision working. The Cube uses a 64bit Dolby Vision module which is a little different than the AM6 & U22X-J that use a 32bit module. Perhaps the AM6 & U22X-J could also make use of the Cube’s DV module.

I made a separate post with a little more details as to not sidetrack the discussion here.

Thanks - been checking this code, and the Dolby debug log output.


I think the graphics priority is on constantly - have not found a way to turn off, set by this code:

is_graphics_output_off

It is like the On Screen Display is on all the time even if not showing - not sure if that is effecting the picture quality for AMLogic SOC - The Dolby docs state video priority should be used when playing video, graphics only for when onscreen menus are showing etc.

Logging is showing the same (note the gpr [graphic priority] at end of the log):
Mar 01 15:54:31 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700),g 1: 1920x1080 50->3000000,gpr


Some other observations:

FLAG_BYPASS_CSC → FEL and MEL play with purple and green colours

FLAG_DISABLE_COMPOSER → FEL gives a grey screen → MEL looks normal
(Seems Composer is required for the 12 bit composition BL+EL)

FLAG_BYPASS_VPP → FEL turns the RPU Off
(Need to get a file to test the effect conclusively on MEL, but would assume the same)

FLAG_CERTIFICAION → Causes a large frame rate drop maybe of half to 10-12 fps - no obvious picture difference


0->0(T:1-700) from the debug indicates source DV → dest DV with 1-700 nit range (the nits are possibly being picked up from the TV LG E8 though the HDMI comms)

g 1: 1920x1080 50->3000000 is the graphics overlay it thinks is on - can alter the “graphics” nit range with parameters:

dolby_vision_graphic_min
dolby_vision_graphic_max

Setting min to 1 to match TV and max to 1 (lowest acceptable value) - the brightness of the on screen controls (play / pause etc.) of Kodi are greatly reduced - so doing something. picture quality no obvious difference.

log when changed to:

Mar 01 16:33:21 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700),g 1: 1920x1080 1->10000,gpr

Changing the Kodi screen resolution had no effect of the graphics size reported in the logging.


My take at this point is this code is extracting the RPU meta data, BL and EL video and passing all to the kernel object dovi.ko (which is driving the SOC), alongside setting up registry values for the same.

Any RPU application is in these lower levels, possibly in the SOC itself.

My take on the SOC variations are they are basically divided into STB (Set Top Box) and TV (Embedded TV) RPU is passed on in both cases to the driver.

Just got my am6b+, FINALLY! I can confirm my remux of Dune has the exact same behavior. Interesting observation: with lossless set the movie immediately starts with 65 skipped frames. If I rewind to the start again another 65 skipped frames.
Also seems to stop at the Legendary logo for a little under 3 seconds. I think this is somehow related? With minimal EL set, it played to at least 5 minutes without any skipped frames.

I found a MEL title that’s even worse than Dune (and not entirely surprised): Gemini Man. On lossless it played maybe once out of 10 tries. Basically it just doesn’t want to play properly. With minimal EL it plays fine. That movie is the only 60FPS UHD 4K movie I have so it’s definitely unique in that way.

Are folks able to play the mehanik mortal engines fel test mkv? The copy I have immediately hangs when I play and there’s video corruption towards the bottom of the screen. I redownloaded again to make sure it was a good copy–it is and same behavior. It did play saving Private Ryan (which is FEL) fine, so not sure…

Also if I set to player-led I get a blanked out screen (TV reports no signal). My Dune HD Boxy does only player led so I know this TV can support that mode. Hopefully it’s just something I’m missing that’s obvious. I have an LG GX OLED TV. Oddly with the TV-led it’s reporting as RGB 12-bit whereas that reports correctly as RGB 8-bit in every other device I have doing TV-led (several Roku ultra, shield, fire tv, Panasonic UHD player, etc).

The dualboot firmware configuration was pretty simple and worked just as I suspected. It even updated itself to 19.5 and then I injected the 20.4-dv tar file and had to use the .nocompat file to make it go.

Yeah, that happens when I turn off refresh rate change, but I actually never use without that option so it never bothered me.

Did you try increasing “dolby_vision_wait_delay”? There is no need to switch to minimal el.

Some more observations:

Leaving the flags at the default 0x05 (using Display Led):

FLAG_FORCE_CVM		0x01
FLAG_BYPASS_VPP		0x04

I get:
Mar 02 12:00:19 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:50-4000),g 1: 1920x1080 50->3000000,gpr

Changing to 0x0D, i.e. adding:

FLAG_USE_SINK_MIN_MAX 0x08

I get:
Mar 02 12:09:03 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700),g 1: 1920x1080 1->7000000,gpr

Changing back to 0x05 does not reset this and it stays at 1-700 (until I rebooted)
50-4000 are defaults from the code:

static unsigned int dolby_vision_target_min = 50; /* 0.0001 */
static unsigned int dolby_vision_target_max[3][3] = {
		{4000, 1000, 100}, /* DOVI => DOVI/HDR/SDR */
		{1000, 1000, 100}, /* HDR =>  DOVI/HDR/SDR */
		{600,  1000, 100},  /* SDR =>  DOVI/HDR/SDR */
};

DOVI src => DOVI dest


Not found a way to switch off the OSD, probably needs a code change.

From the CE source for linux-amlogic it has some docs on the - Amlogic Meson Display Controller from that I think we can confirm:

VPP: Video Post Processing
CSC: Colorspace Conversion

CVM - still not finding a definition

That FEL test video should play fine in lossless.
Here’s a link to the one I have

1 Like

I found another test video with flashing solid colors and some watermark (ie exclusively in the FEL layer) that says this device is capable of FEL playback or something along those lines. That played at least whereas it was only the flashing solid colors on my Shield Pro, so indeed it seems it’s handling FEL.

I have to retract some of what I said about especially Gemini Man and a few other titles that I reported about yesterday because the issue was related to my receiver. It has a Auto/Standard/Enhanced, setting for the HDMI Inputs. They were set at auto, but I ended up getting more issue with setting it to enhanced. I thought that meant the setting the HDMI to handle 18.0 Gbit/s but now not sure. The receiver I’m currently using is still pretty new and has its share of quirks.

Maybe CVM means:
“Our previous study [19] has shown that standard FP detection algorithms (Harris Corner [22] and DoG [23]) can be modified to improve detection in HDR images by using the coefficient of variation mask (CVM).”

That 1-700 sounds like it’s the luminance range of your TV and was probably determined via the HDMI EDID.

If you are referring to the code itself of the tv and stb named methods/variables, from what I can tell it’s the difference between TV-led vs player (ie the stb) led DV? I don’t think it means SOC types…

@Portisch Btw I briefly tried 20.5 and for the life of me, I couldn’t get either MEL or FEL DV titles to consistently work with in either player or TV-led, and by trying the force options. Either it eventually froze playback, I got only a black screen, or a blue-tinted screen (e.g. Gemini Man). I ended up rolling back to 20.4. Would you need logs for that?

For reference, with 20.4 I had to set force 4:2:2 and 12-bit for player-led, and force 8-bit for TV-led, and then set the dolby_vision_wait_delay of 16 in a startup script. The forced settings for player-led would appear to work for any video with a capable HDMI 2.0 setup (that can do the 594MHz signal) including SDR and HDR, for up to the max 60Hz. For TV-led that forced 8-bit would impact HDR playback it seems so I set it back when testing HDR media types. For Gemini Man which is a 60fps title, with the blue tint behavior, that issue seemingly went away with TV-led mode once I set 8-bit forced. So I’m wondering if the erroneously set 12-bit RGB on TV-led was causing that? With player-led and forced 4:2:2 and 12-bit, I seemingly also couldn’t trigger the blue-tint.

Nothing was changed, no. Forced cd or C’s is ignored on DV. Auto should do his job.
P7 is not really proof, so it’s more luck it works.
It’s to much time consuming to debug and play with this so maybe it get improved in future someday
Like when S5 with FEL and 5.15 kernel support come up. Homatics doesn’t support FEL at all. And I don’t have time to work on 4.9 EOL kernel.

I’m on 20.4. Does anyone else get crashes while seeking or resuming on P7 FEL/MEL films?

If I stop a movie 3/4th in, I will crash multiple times to the point I can’t get back to the same spot. Even when trying to seek it while eventually crash the player/Kodi and enter safe mode.

Log attached: https://paste.coreelec.org/aURidW

I see there is a line in the 20.5 changelog that reads that DV updates were made.

Does this address the MEL issues? Do we still need the startup script to set the wait delay?

Link the commit. There is no change done to DV.

" * Fixed Dolby Vision on Amlogic-ng"

Or that’s just for the regular ng… Is it possible to get a more permanent fix for the MEL issue vs a startup script?

Not Amlogic-ng-dv…

Use refresh rate change, then you don’t have to force anything. It sets 8bit in tv-led correctly.