Maybe you got the filename incorrect?
sudo echo 444,10bit > /sys/class/amhdmitx/amhdmitx0/attr
Maybe you got the filename incorrect?
Just a type error from me in my last post, it was echo “444,10bit” | sudo tee /sys/class/amhdmitx/amhdmitx0/attr i have in my rc.local and type this in a shell…
And also same result… with HDR auto switch off = banding and with HDR auto switch on = sometimes banding and sometimes not!
So the command has no effect and the HDR auto switch on doesn´t solve the banding completely - what now?
Maybe check with the info from your TV, AVR or Projector if it is in 10bit mode when you got the banding, atleast then you know if that is the issue or something else.
This advice is good:
Post a debug log if you still have issues, because banding / flickering is now solved.
This has been resolved, but auto switch is experimental. If you see a few posts up you should see some more detailed explanation, let me know if you have any questions.
My TV or AVR hasn´t an option to show the mode but the banding comes back after the April Update - tested the 4k demo before often and no banding occured !
Will post a debug log tomorrow playing the 4k demo with the blue sky… the user Conncect has the same problem, sometimes banding and sometimes not after the April Update…
cat /sys/class/amhdmitx/amhdmitx0/attr and check if it displays the
Suggests the autoswitch option may still be on (which is not 100% there yet)
Yes – you should do this when you see banding.
Do a last short test bevore going to bed… set the HDR auto switch to “off”, reboot the vero and play the 4k demo 7 times… no banding occured - cat /sys/class/amhdmitx/amhdmitx0/attr shows me 444,10bit… I´m absolut confused now! Will do more tests later after work!
Anyone have issues with the “444,10bit” using an Epson TW9300 / (5040ub/6040ub) projector ?
The projector always says it is 444 8bit due to HDR is only supported with 12bit 422 email@example.com…
I use a HD Vertex convert 4k Signals to 422 at this resolutions whichs works fine with all my players, except for the Vero4K. Using the “444,10bit” results in no output from the Vero (according to the HD Fury). 422,10bit results in output, but all colors are way off and only 8bit output ?
Ok so when I get back from work later I should be able to switch off ‘auto switch’ and all should be good? The release notes say that the banding is fixed. So what exactly is the HDR auto switch for if we don’t need it? Sorry for the basic question. I’d just like to understand what is going on.
I would also like to know what the update actually does and if we can remove the line from rc.local.
Just another reporting in, after April update the issue isn’t fixed for me, still need to run “sudo echo 444,10bit > /sys/class/amhdmitx/amhdmitx0/attr”
I have explained this above, but I’ll explain it one more time to make things clear.
The flickering and banding issues are resolved in the April update.
Additionally, a GUI option has been added to automatically switch in to HDR mode only when necessary, i.e only when playing HDR content. It doesn’t always detect all HDR content however, so you may wish to stick with rc.local. You will need to have 10-bit output when playing HDR content that is 10-bit or you would naturally see banding. The role of the GUI setting is to spare people of using the command line and switching only when necessary.
This topic seems to have run its course now, as banding & flickering is now fixed, and we move on to perfecting HDR autoswitching.
I’ll keep this thread open for a few days until the last reply, but I’d like us to now move on and nail the final bits of a good HDR implementation.
I must be misunderstanding.
The banding/flickering issue (as fas as it affects me) is the same in the april update as it was in march. Aka, it happens, unless i run the command that’s been mentioned.
In the march update, any files that were HDR would switch to HDR, and they still do. There was never a false positive, and there still isn’t. I’m not sure what the autoswitching is for.
If the above is irrelevant then please just disregard.
The autoswitching is meant to sit bit depth, colour space etc properly.
Reading some of the earlier comments might make more sense.
So if the autoswitching isn’t changing bit depth accurately, you’ll want to enable the 10-bit via the CLI. Obviously if you try and display 10-bit content with 8-bits you’ll get banding. But the actual banding issues when playing 4K HDR 10-bit content when having the bitdepth set correctly is resolved, and other users have confirmed this. Prior to this update, users would get flickering even if they set the bit depth.
So while saying it’s fixed, it’s still not fully automatic as we either need to set rc.local to fix 10bit output, or use the new auto switch thing which isn’t working 100% yet
Ok so as a general user who is not modifying / editing files to set depths and such like it’s still not working? I have the April 25 update, I have HDR auto switching set to off. In fact I have reset to default settings, I have tried different HDMI cables. I still do get banding when watching 4K HDR movies.
Should I, as a general end user, without tinkering with rc.local or whatever these types of setting are be able to watch 4K HDR without banding? If the answer is yes what the hell could I be doing wrong?! I’m getting frustrated with my ability to sort this out myself.