I don't think S905X supports Dolby Vision. In the kernel source you will see this:
Code
if (is_meson_gxm_cpu() && is_dolby_vision_on())S905X/905D is GXL and S912 is GXM.
Posts by wesk05
-
-
Edit2: That LG Wonders file is their early HDR spec that will only work on LG displays (and probably never kodi)
The clip that I have was downloaded from demo-uhd3d. I don't think that is the original one. It looks like a recode (at least it was processed in a x265 application). The clip does play fine in the Android 4K MoviePlayer app on Amlogic devices and also in Photos & Videos app on the Shield. It looks like a Kodi TS issue because when you put in MKV container, the clip plays fine in Kodi.
-
It is intriguing why there is this difference in playback performance. I checked the clips that jd17 has listed and all of them played fine except for the LG OLED Wonders one. I think Kodi has issues with that file. It doesn't play in Kodi on any plaftform.
I tried the echo 444 10bit command at both 2160p and 1080p. It was fine for both resolutions. I also tried some Blu-ray 1:1 rips. I did find 2-3 movies that had issues with DTS-HD audio, but the video playback was OK. I didn't have any issue with the clips koenkooi has provided.
YCbCr 4:2:0 mode is supported under HDMI 2.0 specs for only 4K 50/59.94/60Hz. It seems that Amlogic has issues switching to YCbCr 4:4:4 mode from 4:2:0 mode. I get a blank screen on Android Nougat firmware (M8S Pro) also.
-
wesk05 If no sampling is enabled, is there anything wrong about having 4:4:4 10bit output for 4:2:0 8bit video?
On Android Amlogic output is YCbCr 4:4:4 for <50Hz and 4:2:0 for 50/59.94/60Hz.
-
Why 4:4:4?
4:2:0 10bit has an output issue, and with 4:2:2 10bit I got some flickering in parts of the video that was fixed when setting 4:4:4 10bit on a 4:2:0 10bit source.
4:4:4 10-bit will work only for <50 frame rate content.
-
In Marshmallow Kernel builds, I have not witnessed any decrease in color saturation or luminosity when I playback 1080p / BT.709 / 10 Bit sources (upsampled to 10 Bit from an 8 Bit original).
I did quite a bit of comparing on that because I encode my Blu-rays in x265 10-Bit.You are referring to obvious banding in Nougat Frankenstein builds vs. smooth gradations in Marshmallow builds, correct?
We discussed this here:
[BUG] S905X Krypton: Horrible banding in 10 Bit videos
What you call noise looks like proper dithering to me and works quite well to make 10 Bit look close to like it is supposed to.My comment was primarily for 10-bit Rec.2020 content. I have only checked 8-bit Rec.709 and 10-bit Rec.2020. It is possible that Amlogic conversions kick in only for HDR/Rec.2020 content.
Yes, what I call noise is proper dithering. The adjacent pixels even in a test pattern box that doesn't have any gradient are slightly different. This certainly can explain the smoother gradation in Marshmallow builds.
I suppose the black level changes on some displays are a mystery then?
I suspect this is the result of a typo from an amlogic commit updating dithering for GXM and newer boards, which disabled the old 10-8 dithering for <=GXL in the process. I have a fix for it aml/hdmitx: fix 10->8 dithering for <=GXL & cleanup · amillogical/linux-amlogic@3304772 · GitHub
re: hdr/sdr conversions, Amlogic "optimizes" their conversions with very different results. I suspect if you revert their "optimizations," you'd get close to standards. Amlogic also has a static saturation boost on sdr -> hdr conversion that was added separately from their conversion "optimizations." When I played with sdr ->hdr, I had to remove the saturation boost to get decent output.
It definitely makes a difference on my LG TV (OLED65B6V).
I do get the washed out colors when I set black level to high, both on Marshmallow and Nougat Frankenstein.
That also goes for the RPi2. I always had that set to YCbCr limited, but I could still mess up the range when I set the TV to high...You know what, now that you have brought up this black level difference on your LG TV and some other displays, I will have to check whether the output is set differently when the display EDID supports selectable YCbCr quantization.
Regarding HDR-SDR and inverse conversions, it is possible that Amlogic has messed it up with their optimizations. ETSI specifications are heavy on computation and I am not sure whether Amlogic has even adopted it. The Ultra HD Forum has adopted that specification. ITU BT.2020 to BT.709 conversion recommendation is only at the draft level.
-
I have checked 8.0.1mm, 8.0.1l, 8.0.2a and 8.0 (full nougat) builds on a Mini M8S II. There are only two differences between Marshmallow and Nougat builds.
1) Marshmallow builds have incorrect luminance upon boot, but it is corrected as soon as you play a video (resolution doesn’t matter). I see that jd17 has mentioned this a couple of times.
2) Nougat builds do not have noise in 10-8-bit dithering whereas, there is noise in Marshmallow builds.
3) BT.2020 color space is set automatically in the full Nougat build. On the other builds, it is set only when refresh rate switching is disabled or the frame rate matches the set desktop refresh rate.
When Cb=Cr, luminance (Y) is simply truncated from 10-8-bit. When Cb and Cr are different, there is some sort of conversion happening along with 10-8-bit dithering. The conversion end up decreasing the color saturation and luminosity. Amlogic Nougat SDK does have a HDR to SDR and SDR to HDR conversion feature. I have tested this on a M8S Pro. The conversion in LE doesn’t quite match with the Android one.These conversions are specified in ETSI TS 103 433 and ITU-R BT.2087 standards. I don’t think Amlogic conversions seen in Android or LE or following those specifications.
- There are black level changes between the kernels depending on display capabilities.
I haven’t measured any black level difference in the output between the kernels other than the boot issue associated with Marshmallow.
Mix in that many current displays have broken "auto" black level (like Samsung's entire lineup), this is why some of us have seen the black changes, and others haven't.
If this is with YCbCr input, I won’t call it as broken. While CTA 861/HDMI specs do have a selectable YCbCr quantization option, this is
not implemented in the majority of the displays. YCbCr quantization is indicated by YQ0, YQ1 bits in data byte 5 of the AVI Infoframe. If the display doesn’t indicate selectable YCbCr quantization the source will set this to “0” and will default to 16-235 setting. Sony TVs are an exception. They do have selectable quantization, but only few devices can output full range YCbCr (Pi2 for sure, I am not sure of other LE devices).So, users who complained about washed out colors with MM builds - please check your TV's RGB range setting and manually set it to limited (HDMI black level / black level = low in some devices).
As mentioned above, dynamic range (black level) setting will have no effect on YCbCr input on almost all displays. If you force RGB mode
output, then you do have to set the black level to limited or low on the display. Amlogic RGB output is limited with BTB (1-15) and WTW
(236-254) passthrough.
