I just wanted to say that I get a BT.2020 signal on every 4K file, even if they're only 709. Someone mentioned having the same problem a while back, can't remember who.
It's weird because it used to work, but I haven't checked in a while and it broke sometime in the past moths. Anyone else affected?
The default branches on kszaq's github for both linux-amlogic-le and libreelec have all these kernel changes merged in.
Found them. My bad. 
P.S.: I'm wondering if we will ever see fully functional upstream kernel support (including the video decoding functionality). Would be awesome!
I currently recommend kszaq's 8.2 builds over these, all changes here have been merged in.
Are you sure? I couldn't find them on kszaq's Github.
Just a heads up for people interested in HDR content, but not owning an HDR TV:
It's probably better to stick to SDR content, since there is no defined standard conversion from HDR to SDR. All existing solutions are more or less hacks that need individual tweaks to get acceptable output. Color accuracy is impossible to achieve.
I also couldn't see macroblocking in the Samsung demo. No vertical lines either.
Maybe there are different revisions of S905X floating around and this is a hardware issue?
For completeness' sake: I use a Beelink Mini MXIII II bought in February.
Can someone explain, where / how I can see those vertical lines you are talking about? Haven't noticed them so far.
Also the Wonderland Demo has been removed from demo-uhd3d.com apparently. Does anyone have a mirror?
ps. Not sure if my TV supports 44410bit 50/60hz at 4K, but i know it supports 422 10 & 12 bits at 50/60hz.
No current TV supports 44410bit@50Hz or above, because it exceeds the 18 Gbit/s bandwidth limit of HDMI 2.0.
Ok. I've found the culprit.
My TV has a "Smooth gradation" setting, which i had on low. Funny enough, turning it off (or to high) gets rid of the banding.
So I'm sorry to have caused confusion here. I consider this build to be just about perfect now.
After a bit more testing, I think you're comparing to a build that still had dithering enabled for 10bit output.
That's probably it. My TV's internal player does not exhibit banding though. Is dithering supposed to be turned on?
I'll just post the clip again.
hdr_banding.mkv
To all the people with an HDR capable set:
Play this file and please report back whether or not you can see banding artifacts within the white gradient.
I believe you, but really can't recreate. Is the banding as extreme as your previous image from krypton (OZsfOvG.jpg)? Additionally on the 8bit output, you should see a bit of a "jitter" around where the banding would occur.
It appears less severe, but I'm largely going from memory here. I'll do some more testing, when I have time.
Maybe someone else can chime in.
Edit: The gradation is definitely less bad than on the old kszaq builds.
Since I got a video of the same name from a post on this forum I've been using for testing, is that a smurfs intro? Could you upload the dmesg of playback with and without attr set to 10bit? I unfortunately can't recreate in 8bit with dithering, or 10bit without dithering.
Edit: there might still be issues if there's any playback before it's set.
That's right, I created that file.
10bit attr:
hdmitx: set clk: VIC = 93 cd = 5 frac_rate = 18bit attr:
hdmitx: set clk: VIC = 93 cd = 4 frac_rate = 1Output is 10bit and 8bit respectively (confirmed by AVR), but both appear identical.
I write to the attr node in autostart.sh. The GUI output after boot is 10bit.
Edit: complete kernel log snippet
I can report that the frame skips seem to be gone.
I was previously on the 20170603182409 Frankenstein build and had a perfectly smooth gradient in my hdr_banding.mkv file. With the full Nougat build, the banding returned. There appears to be no difference between 8bit and 10 bit in attr.
I'll switch to a mediafire account (still ads) unless there is a site you can recommend.
Why not use github releases (About Releases - User Documentation)?
Seems to be the easiest way to me.
I can confirm that weirdly, H.264 is extremely buggy, it looks like slow motion.
However, both x264 and x265 seem fine.
Also, a/v is severely out of sync, at least for DTS, DTS-HD and Dolby TrueHD.
All tested videos were 23.976fps, but the async goes far beyond the usual 175ms...
Weird that x264 bitstreams are fine, but other encoders are not. Are you sure that's the only difference?
I don't have sync issues at all (never had them on any build).
Edit: Have you tried disabling HDMI lip sync on your AVR?
Which LibreELEC is recommended for 4K HDR playback?
johngalt's test build from here [DEV ONLY][S905/X] 8.0 with "full Nougat" kernel preview builds
But your AVR also shows BT.2020, so wesk05 was wrong about that.
Did you test this with Jarvis too?
Again, I would not be surprised if Jarvis truncated to 8 bit as well, but if so, it does it much better.
I tested it with Jarvis too, albeit without taking pictures. It's also 8bit, but the banding might well be less noticeable. I haven't tried out other clips (I am running Krypton since the day I got the box).
wesk05 probably didn't do the steps outlined in my previous post to get 2020. It seems when starting playback, 2020 is triggered for a split second, but then the mode changes from GUI (most likely 60 Hz, default) to video (probably 23.976 Hz) and it gets "lost". This is a kernel bug. It can possibly be worked around by switching mode before initializing decoding via introduction of a timeout.
Take a look at this clip:
hdr_banding.mkv
This is cut from an untouched 4K HDR BD (for educational purposes) and highlights the banding issue very well.
I took photos of both the LibreELEC output and my TV's internal player output (same manual exposure). It also shows my AVR's info menu, confirming 8bit. One can clearly see the banding in the top part. This is Krypton by the way.
http://imgur.com/a/VV5HH
I have to add that this is an extreme case and it's not nearly as noticeable in real film material, hence people saying that they don't see the difference.
I'm not a Color expert, but setting my TV to BT2020 when playing a HDR movie, I can really see the difference. Any more technical details from your friend wesk05 ?
That's because skin tones are desaturated, when displaying a 2020 signal with 709 primaries, which is the default. If you manually set it to 2020 (technically DCI-P3), the colors are as intended. The box can output the 2020 color space, if you disable auto frequency switching or, more conveniently, set your GUI frequency to 23.976 Hz (or whatever frame rate your HDR content is in). This way there's no mode switch, when starting HDR playback and the TV will automatically go into 2020 mode. That bug was introduced after the nougat video code had been merged.
