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

Development Development & Testing
671

Hi buddy,

I know this a stretch but can your development.tar with cmv4.0 be made into a kodi android apk?

My minix u22 xj with Coreelec doesn’t process 8 channel atmos hd sound on my lg c6 tv but in android with kodi nightlies it convert it to pcm. This is without without soundbar or amp as I can’t afford one right now.

Many thanks.

1 Like
672

No, CoreELEC is not Android. Also does Android not support TrueHD passthrough, CoreELEC does.

673
  1. You need a J or K chip for DV support in general, not just P7 FEL. So the answer is it’s highly unlilkely that a normal S922X will play DV.
  2. Same goes for the S922H to the best of my knowledge.
674

FYI, testing with my HD Fury, indeed the colorimetry is no longer passed in DV TV-LED. Shows RGB 8b DV.

For what it’s worth, it’s now showing DV-Std BT.709 in the player process OSD.

675

I just tested this myself. It doesn’t go through this method every single time for me.
It only happened once for me, and in that case - obviously, I got 12-bit output.
So I don’t think that removing this line is the correct fix. This line has been there from the early days of DV support in the 4.9 amlogic hdmitx driver.

I think that there’s something “bad”/“weird” going on in the handshake between TV and box, leading to a plugout event. But I can’t really find it.
Maybe @Portisch can figure it out. Here’s my dmesg, search for the system: plugout event, this is where I got 12-bit instead of 8-bit. Tried to start P7 MEL remux.
https://paste.coreelec.org/qoqQgM

676

How does this work with profile 8 content? I thought the underlying hdr10 part of the video was bt2020, is that converted to iCtCp before being tunnelled?

678

I think @TheCoolest is correct; clearing the flag and having the display interpret the RGB Full 8-bit tunnel as Rec709 is the proper behavior.

679

On films with Truehd/8.1, i get no sound (lg c6 to minix direct), but in android (monsoon apk) it convert it to pcm and i get sound. Have enabled all settings (aml,hdmi,multi pcm, passthrough etc) in coreelec but still no sound, any ideas please?

681

This is not the thread to ask for help on such topics. Please keep this thread on the topic of DV.

683

Hey @PurplePlayer

If you get time give this one a try, reworked the MEL detection to another way - can leave the wait delay set to 2 now (the original value), and should play the full contents from the start (re: Dune skipping the first scene)

Seems the 12bit issue still occurs now and again but it is better now, mostly get 8bit.

2 Likes
684

So based on what I can tell. There’s 3 functions to set video format depending on HDR type (i.e. hdr10, hdr10+ DV)

  • hdmitx_set_drm_pkt() is for HDR 2084 SMPTE, HLG, etc.
  • hdmitx_set_vsif_pkt() is for DV
  • hdmitx_set_hdr10plus_pkt is for HDR10+

For the DV function I can definitely tell it’s being done here as well. So it’s looking like there’s two competing places this is getting set and as a result they are clobbering each other other ( I guess you could call it a race condition?).
set_disp_mode_auto(void) is the other place.

In fact stripping all the code from that auto method would still make TV-LED properly set itself. And in fact correctly every time because once this code is stripped out there’s no chance it ever can get set to 12-bit for this type of media.
So ultimately it seems the place to set the format is in one of those methods instead of a shared method like how it’s currently coded. depending on HDR type as it appears set-disp_mode_auto can’t reliably determine it.

However while LLDV and HDR are close they are missing correct bitrate, the foolproof setting of TV-Led by stripping the excess code out the other formats get somewhat sacrificed. : HDR 10 gets set to 8-bit and oddly LLDV gets set to 16-bit. I think the key is somewhere in the HDR 10 code for non -DV media and for the LLDV it’s close but not quite.

685

Is the “21.0-Omega_rc1” version on Github the same as the latest nightly from this link?: CoreELEC nightly builds

686

I gave it a try with Dune, and Ghost in the Shell. Didn’t encounter any freeze at known scenes.

1 Like
687

This is a milestone build so no daily update as nightly

1 Like
688

Cool update. My experience is the same.

Wait delay back at 2, but no issues on Dune or Ghost in the Shell. Only tested TV-led.

1 Like
689

This patch fixed that problematic Dune file in Player-LED/LLDV while in auto cd/cs for me! Applied after updating to the 20240319 nightly.
MediaInfo: Imgur: The magic of the Internet
dispinfo during playback: https://paste.coreelec.org/HEcUWE
dmesg: https://pastebin.com/raw/Nx48UCLC

Start of playback was also much faster, no delay and I could see the opening caption text before the WB logo.

1 Like
690

I suggest trying some HDR10 titles. You should get bt.2020 and at least 4:2:0 10-bit. though this was before cpms code change for the MEL detection my HDR10 titles kept outputting as 4:4:4 YUV 8-bit. Was driving me nuts lol.

691

Regarding the BT.2020 flag when tunneling rgb 8 bit. The video from Ycbcr is converted to ITP and then the RGB tunnel video is sent to TV, but the color space remains BT2020. But theoretically, not all videos can be made under Bt2020, maybe bt.709. Therefore, this flag may prevent the TV from correctly understanding the color. But I doubt anyone will encounter BT709 in DV. Therefore, from the point of view of fidelity, it may be logical not to transmit it with an RGB tunnel.
But I checked several videos on my LG CX and compared Oppo and Am6b, especially on videos where there are colors up to the Bt2020 color when exceeding DCI-p3 and vice versa when the colors do not go beyond the DCI-P3 triangle. And I didn’t find any difference between Oppo and am6b. I did not see the difference with my eyes, when capturing in rgb 8 bit according to graphs, there is also no difference.
But still, probably, if possible, it is better to remove this flag when using TV-led output mode

692

With the Omega_nightly_20240319 update, I’m seeing a very strange issue. When the debug-log is on, everything works perfectly:
https://paste.coreelec.org/Axrgne

But the moment I disable debug-log, playback starts getting stalled from the beginning, including DV and standard HDR material.
https://paste.coreelec.org/Hoi8bO

I cannot come up with any sensible reason behind it but that’s what happening for me. I tested at least 4 times, before posting here. Can anyone explain to me what’s possiblly happening?

693

You made a pretty informative video about how RPU gets passed in TV-led and how the fake TV-LED basically output a zeroed out RPU payload. Were you ever able to confirm that was no longer happening when you confirmedb mv4.0 was happening with cpm’s fix?