8-bit RGB is correct. I believe you are conflating the colorspace with the sampling method or how that colorspace is represented. Let me take a stab at this.
BT.2020, Rec709 these are color gamuts or colorspaces, or all the potential colors that can be displayed. They are represented and coded to a format, this is called chroma sampling: 8-bit RGB, 12-bit YUV, etc, this is the sampling method.
Dolby Vision is coded in a proprietary colorspace. Neither Bt2020 or Rec709. This is why some believe the correct colorimetry to send to the TV, the SSH command you ran, is to blank out the colorimetry.
However, the DV colorspace still needs to be represented and carried to the TV. What colors does the scene actually have? It does so by sampling that colorspace via ICtCp 12-bit. However, to get that to the TV, it “tunnels” that information inside an 8-bit RGB container with no information loss.
So what your Vertex device shows is correct. That the Ugoos/CoreElec is sending the DV data appropriately inside the 8-bit RGB container. For the colorimetry, actually check your TV info menu. On my LG, if I playback DV, it will show the colorimetry in an info popup. Whether bt.2020 or blank.
In any case that will still be carried in an 8-bit RGB container to the TV… Basically the color space is all the potential colors that can be displayed, and the sampling method is to tell the TV which color to actually display, and how bright it should be. Now for someone to tell me I’m technically wrong
I appreciate the explanation. Out of curiosity, why does it change from DV 8bit to DV 12bit when I reset the HDMI handshake during playback? And if I stop playback, and then start again, it goes back to 8bit.
Switching HDMI or edid to hdfury during playback is how it should work. It’s normal. On dune pro one 8k plus, switching inputs or edid at all causes the player to reboot. So it’s not adequate to check the player’s operation during playback like that, especially DV. When the current edid is very much dependent on the current image output mode
I was still unable to play Godzilla, and it consistently froze my box. The only similarity between the files I created and others was that they all utilized some version of mkvmerge.
However, after trying MakeMKV, the file now starts flawlessly and does so repeatedly.
I suspect this bluray disc is strangely authored. The audio has a huge delay and when you remux with mkvtoolnix, it ends up with a negative delay. I heard it also freezes on the Shield. IIRC, my Scripts also fails to demux the layers from the mkvtoolnix remux.
Respectfully, I wasn’t trying to test a convoluted setup or unlikely scenario. I was setting up the Vertex, happened to click the reset button and noticed the behavior. It seemed odd, so I wanted to report it as I am testing nightlies. My bringing it up wasn’t meant to imply it needed to be fixed or addressed. Just sharing feedback and data.
The same behavior happens if I change inputs on my HDMI Switch during playback.
Just as a data point - I was able to mux this without issue using MakeMKV and it played fine on the Ugoos.
The hard part was finding subs that were synced to the UHD
Get new releases. That FGT release has been trumped at every site I see (HDB, BHD, PTP). I have not seen DTDL MKVs in a very long time since there is no reason too… FEL muxed into the STDL.
This is similar to my box incorrectly triggering 12-bit on DV playback, if my receiver wasn’t turned on an initial CoreELEC boot up (a full boot up, not resume from suspend). I can get my HD fury to similarly cause this behavior as well with manipulating the EDID.
Why are you triggering HDMI reset during playback? There’s absolutely no need and you’re adding in issues.
. Just unplug DC power?