HDR Banding issue

I’m using:

deb http://apt.osmc.tv stretch-devel main

Is this the wrong one?

That’s fine.

The build only recently finished, so it’s possible it hasn’t reached your local mirror yet. Let me know if nothing shows in an hour.

Sam

Got the kernel update but does not get the expected result:

echo “dither1” | sudo tee /sys/class/amhdmitx/amhdmitx0/debug

gives me only:

[ 628.067419] hdmitx: system:
[ 636.023198] hdmitx: system:

shouldn’t it be:

adjust dither to 1

What am I doing wrong?

OK, I’ll double check that.

The message shouldn’t matter though, you should still see visible differences (if the banding / flickering is indeed caused by this). This needs to be done during playback.

These are the only regs really changed in the HDR flicker patch.

Sam

Will check it later and post the results. Fingers crossed.

Just tested using @Martorias 's banding clip.

dither1 immediately re-introduces flickering. Setting dither back to 0 removes the flickering. :+1:

Here’s the slightly weird bit. Setting round1, reduces the banding significantly. Setting round0… also reduces the banding significantly… :thinking:

I think there might still be a little visible banding in my Marvel intro clip but I’d need to do some side by side comparisons with my K8500 to see if it is any different to that. Suffice to say the “round” value makes a dramatic improvement. :slight_smile:

edit - my dmesg output is the same as @mule 's

I can confirm that dither1 brings back the flickering and dither0 removes it. The “dither” switch has no impact on the banding issue.

Edit: Made a mistake with my setup: I now can confirm that “round1” solves the banding issue.
I made some side by side comparison

  • Zidoo X9S with external player: no difference
  • Minix U9 (S912 chipset) with LibreELEC 8.2.2.3 (special build by wrxtasy with latest kernel): no difference
  • Samsung K8500: At first look It seems that this player produces even slightly less banding, BUT: If one take a second look one can see that there is some kind of noise filtering which seems to be responsible for this “even less banding”-effect. This noise filter (which can not be deactivated) has already been discussed on different forums and for sure this has the disadvantage of loosing some slight details.

My conclusion: With “round1” the banding issues can be solved.

@fluffyredlobster: I’m curious about your side by side comparison results with the K8500.

1 Like

I will produce a kernel with this set by default.

Thank you for your testing @mule and @fluffyredlobster and many thanks to @Martorias for his sample clip. I’ll let you know when this is available for testing.

Exposing the registers via sysfs seems to have helped us get to the bottom of the problem quickly. I believe I have found the problem now.

With any joy, this should do the trick:

https://github.com/osmc/vero3-linux/commit/7a9f286dd7c573d003045e4e1777ceed07832b4b

This is now built so you can update using the staging repository again.

Sam

Thanks Sam for the quick work.

I just did a really quick test before heading out to work and it doesn’t seem to have done the trick sadly. Martorias’ clip still shows the same level of banding as previously.

uname shows I’m running the correct kernel:
Linux osmc 3.14.29-63-osmc

Took a really quick look at the change in github and looks like it might be dependent on the colorspace? I am running 444 @ 12bit. I’ll do some more testing this evening if someone else hasn’t already figured it out by then :slight_smile: It’s also possible I missed something in my testing as I was in a rush so probably worth waiting for confirmation on my results…

Hey. Just tried but I don’t see any changes at all and changing the debug things does nothing so not sure what’s wrong. My IR remote stopped working atleast so I guess something happened :confused:

I used 444 / 10Bit, Martorias’ clip and Life of Pi for testing. Immediately after applying „round1“ banding went away and this was reproducable. What was the exact command for the „round“-debug switch you used?
Did you check dmesg returned a message after applying?

I use 444,10bit as well, and tried both the command sam posted and the one you posted with sudo tee. I couldn’t check dmsg will do later when I got the TV for myself… :expressionless:

@mule did you test with the latest latest build? That has the rounding automagically applied?

No, I did not test the latest build yet, only the build from yesterday evening.

Ok could you give it a shot when you get a chance? As its not working for me or fluffy, in case something changed

Are there instructions for testing this?
Happy to try it out and report back.

Beeing now at work. Giving it a shot in the evening.
Did you try it with the build version from yesterday evening?

@mule no i never got a chance, kids and all.
@captainmoody yes there are, kinda. Be wary that its a test build so things could go wrong and you might have to reinstall (probably not)
To test this update:

  1. Login via the command line6
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb http://apt.osmc.tv jessie-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot

Your system should have have received the update

Then you try to commands in this thread via ssh while watching something

I just tested “Linux osmc 3.14.29-63-osmc” with 444,10Bit: out of the box there are no changes compared to the stable build. But if I execute

echo “round1” | sudo tee /sys/class/amhdmitx/amhdmitx0/debug

during playback, there is an improvement. Tested with Martorias’ clip (banding alomost gone) and beginning of Inception (Sky now almost “pixel-free”).

Tried it with the latest build and there’s definitive improvement! However, not until I changed the parameters via bash.

dither1 -> Clearly visible
dither0 -> No improvement
dither1 + round0 -> Some slight additional improvement
dither1 + round1 -> No improvement

The last two are more subjective, dither1 is what does it. I also tried to set round0 and round1 before doing dither1, those seemed to do the same thing as dither1 alone…

And I also tried with 444,10 and 444,12 which made no real difference to me (but were output according to my AVR).