I wonder if you guys rips are 1:1 with the stability issues?
DMDReview mentioned above that the AMB6+ is sending a Bt.2020 flag in TV-Led Dolby Vision (not sure about LLDV). The Zidoo also did this, and it was proven beyond a reasonable doubt that it was causing color innacuracies. Do you think that this is an issue that can be fixed in Core Elec? Or does this have something to do with the Ugoos’ hardware? Intuitively, it seems logical to assume that this issue would also cause innacuracies on the Ugoos, just as it does on the Zidoo.
FYI, from the code:
/* Dolby Vision Source System-on-Chip Platform Kit Version 2.6:
* 4.4.1 Expected AVI-IF for Dolby Vision output, need BT2020 for DV
*/
I’m not 100% sure I understand what that says, but it gives me the impression that it’s by design to send the bt.2020 flag? If so, and I’m not misunderstanding, is there a reason why it would cause an issue on the Zidoo and not this device?
Why do you think that causes a problem on the Zidoo? No issue:
Use mediainfo to check DV remuxes, BT.2020 is present everywhere, maybe 99%+ of DV remuxes. Nothing wrong with that flag.
Which flag would you expect the device to send? I’m fairly sure that it’s supposed to be BT.2020 for all HDR formats.
In general, I think that this can be changed if needed, but I would assume that it depends on how your display handles this flag.
Refer to Reset_9999 BT2020 Flag description?It is not correct to have BT2020 Flag in TV-LED mode
Hello!
I found a bug when installing AM6B Plus!
When playing Mission Impossible 3 FEL+TV-Led, after the Paramount intro a red screen appears!
No problem with LLDV!
video
Do we know what it should be set to?
My tv (philips) shows RGB in colorspace when in tv led and bt2020 in player led.
I think this is the relevant commit:
But I can’t find the docs listed in there.
We can revert it partially to only set the BT.2020 flag for LLDV.
With the above said, I’m not really familiar with who RESET_9999 is, so I’m not sure whether what he said should be taken as gospel.
Maybe it’s something about HDMI version?
So “older” TV don’t support but newer will do?
I asked RESET what should be sent instead of a BT2020 flag and here’s what he had to say:
RGB 444 tunneling is done in a DV proprietary colorspace: iCtCp, not bt2020.
I see that it’s just a flag. It can be on or off.
I think that setting this flag is relevant to DV over HDMI 1.4b and for LLDV.
I can’t check this flag on the equipment I have, though. I can make a quick build without it.
@rome1931 @Randy420 @bluesea @speedy
Here’s a build without the BT.2020 flag for TV-LED, while keeping it enabled for player-led.
@DMDreview
Does having the BT.2020 flag on in TV-LED configuration really matter to what is displayed on the screen?
Tested your build and now my TV Panasonic displays instead of BT2020, BT709
What this means?
I can’t say. Maybe nothing really.
I guess it will depend on the manufacturer of the TV and how they decided to handle this flag. I don’t know if BT.2020 is detrimental to the color accuracy as this RESET_9999 guy is claiming or not.
Some people say that it is, some say that it isn’t.
I don’t know exactly what the standard requires it to be.
I couldn’t really see a noticeable difference between having this flag on or off on my TV (LG C1)
I am running into one sort of bug on the 20240316 nightly. I have a Sony X950H with a Marantz SR6012 in between the TV and the AM6B+. The TV does not support TV-LED on its external inputs, only Player-LED, so I have CoreELEC set to Player-LED and DV Lossless. Additionally its HDMI ports are limited to HDMI 2.0 18gbps. When I have depth and subsampling set to auto, 1080p SDR and 2160p HDR10 content plays correctly, but DV content fails to show any picture (the TV says no signal found). When I set CoreELEC to force 4:2:2, leaving depth as auto, then DV works fine. I took a few dispinfo outputs for the various scenarios in case they are helpful tracking down what is getting sent to the TV when it is in auto subsampling where DV content was failing. Niche “older” TV at this point I know, and it works fine forcing 4:2:2, but in case it’s helpful info for some of the edge cases. Previously on the 20.5 stable release, depth and subsampling set to auto still allowed DV to play, so this seams to be related to the changes.
CoreELEC in auto depth and auto subsampling (resolution changed after setting to make effective):
Nothing playing, in menu: https://paste.coreelec.org/2FWG6J (picture and sound worked correctly)
Playing 1080p SDR: https://paste.coreelec.org/tPqGOf (picture and sound worked correctly)
Playing 2160p HDR: https://paste.coreelec.org/McE34C (picture and sound worked correctly)
Playing 2160p DV: https://paste.coreelec.org/nRSDim (failed to show picture, only sound came through)
CoreELEC in auto depth forced 4:2:2 (resolution changed after setting to make effective):
Nothing playing, in menu: https://paste.coreelec.org/D7UEr2 (picture and sound worked correctly)
Playing 1080p SDR: https://paste.coreelec.org/BDP3JR (picture and sound worked correctly)
Playing 2160p HDR: https://paste.coreelec.org/SGCFiW (picture and sound worked correctly)
Playing 2160p DV: https://paste.coreelec.org/MGPBsz (picture and sound worked correctly)
MediaInfo for 1080p SDR: Imgur: The magic of the Internet
MediaInfo for 2160p HDR: Imgur: The magic of the Internet
MediaInfo for 2160p DV: Imgur: The magic of the Internet
To me it sort of looks like in auto mode, DV content is being sent as 10-bit 4:2:2, even though the TV says it supports “LL_YCbCr_422_12BIT”. When forcing 4:2:2, DV content gets sent as 12-bit 4:2:2. No expert here, but a difference I noticed.
