Vero 4K H265 movies (8-bit encoded only?) - blacks show as grey, colours washed out (reduced colourspace)

Help and Support Vero 4K / Vero 4K +
1

Hi,

Summary: When playing H265 movies which are not explicitly 10-bit encoded, the colourspace appears to be reduced; colours are washed out, with blacks appearing noticably grey.

System:Vero 4K

Release: OSMC (Kodi 17.6) April 25 2018

Add-ons: iPlayer; YouTube; Keymap editor; FTP; Veracrypt

Detail:

Tonight I noticed that various H265 encoded movies appeared visibly washed out; black backgrounds are appearing as grey (although the letterboxing area displays the black level correctly). The issue doesn’t affect all files; my investigations, detailed below, lead me to believe it is restricted to 8-bit H265 movies only (oddly enough no TV shows I tested show the problem).

X264 files:

I checked a large number of X264 movies, and found that all play correctly (with black backgrounds being as dark as the TV and monitor allow).

H265 TV Shows:

I also tested at least 50 TV shows encoded in H265 from a wide varitey of sources, and found no problems with any of them, which I hadn’t expected (in fact I thought the opposite would be the case).

H265 10-bit Movies:

All H265 movie files which explicitly include ‘10bit’ in the filename work correctly.

Unfortunately I cannot determine if an H265 file is encoded in 8 or 10 bits from the information available via OSMC itself.

H265 Movie Testing (8 and 10 bit files):

I selected 21 H265 movies at random. 6 played with correct black levels, whilst 15 exhibit the problem; I tested these 15 on a Raspberry Pi 3, which was able to play them all perfectly (using software decoding); the other 6 would play audio only, which I believe confirms them to be 8-bit (as no 10bit H265 files will play on that hardware).

System version and updates:

I installed the April update on the Vero 4k a few days ago; whilst I definitely did not notice the colour problem prior to the update, I can’t say whether it is the cause of the issue, as I’ve not had the unit many weeks, and only this evening noticed a problem when playing various H265 movies (but not all).

I had previously modified the ‘attr’ file located in:
/sys/class/amhdmitx/amhdmitx0/

  • adding ‘444, 10bit’ (minus the quotes), despite not having HDR capable displays. Removing this entry makes no difference.

I tried setting the ‘Force RGB output’ option to on, however this just causes the display to output garish greens and oranges.

I also tried switching the automatic HDR detection mode on, but again this made no difference.

Regarding add-ons, I have the iPlayer, YoutTube, and keymap editor.
I have also installed the Raspbian build of Veracrypt.
Earlier today I enabled FTP via ‘My OSMC’, but disabling this made no difference (as expected).

Display Hardware:

I’ve tested the Vero 4K on a cheap 22" ‘e-motion’ branded full 1080p TV, and a 27" Acer S271HL 1080p PC monitor, both connected via HDMI. The results are identical on both systems. Changing contrast and brightness levels only does not allievate the issue (the relative grey / black levels change in sync).

Other related information:

For what it’s worth, I noticed a very similar problem on my PC with an Nvidia GTX 570 gpu; in that case a setting in the driver allowed the entire colourspace to be utilised, which fixed the problem (however in this case all files, in all formats, were affected).

Conclusion:

Hopefully somebody can enlighten me on how to resolve this issue; I purchased the Vero 4K after several years of using Raspberry Pi’s (models 1,2,3) for Kodi / OSMC, specifically as files are increasingly using H265, which is not natively handled by the Pi’s Broadcom IV video hardware.

Many thanks in advance

2

Confirming you are using NOT configuring any of these displays for RGB only HDMI input ?

AMLogic devices use a YCbCr color space by default.

1 Like
3

We’d need a log and make and model of TV to know what’s going on

Cheers

Sam

1 Like
4

@dk.ecom:
you can check your video files regarding 8bit/10bit and colorspace (BT.709 or BT.2020} with the tool mediainfo

1 Like
5

Hi,
Thanks for responding.
I performed one test with the Acer monitor set to force RGB, which caused the UI to output in garish orange and green.
Normally the system display settings are at default, with the rgb option off.
Thanks

6

Hi,
Thanks, I’ll cross-check the format of my test files and see if my assumptions were correct.

Speaking of test files, is there a set of H265 files in different formats (8, 10 bit etc), preferably 1080p, which I can use? - hopefully this would aid diagnostics by eliminating any oddities in my files.

Many thanks?

7

Hi Sam,

I’ll switch debug mode on.

Can you advise as to what you’d like me to run tests on? I don’t want to swamp you with massive debug files from playing a load of different videos, if just a couple will suffice.

As per a previous reply, is there a set of H265 files in different formats (8, 10 bit etc), preferably 1080p, which I can use? - hopefully this would aid diagnostics by eliminating any oddities in my files.

Regarding TV model, it’s some generic full 1080p unit purchased at Sainsbury’s, which uses the ‘e-motion’ brand.
Model no. U215/98G-GB-FTCUP-UK
Product code: EU21A98BFTCUPG094
‘Assembled by Universal Media Corporation /Slovakia/’

Many thanks

8

Hi,

I see that mediainfo is available for Windows, Mac, and a variety of Linux distros.

Whilst I primarily run Linux Mint, with Win7 as a fallback in dual boot, is there a version that is suitable for running directly on the Vero4k (perhaps a plugin which will show info on the currently playing file?)

Thanks

9

for testclips in different formats look at
https://kodi.wiki/view/Samples

and there are more reference links at the bottom of the page

10

Just login via ssh and install it.

$ sudo apt install mediainfo
11

Many thanks. I’ll grab some samples and see what results I get.

12

Thanks, I guessed the Debian release would work.
I installed the full GUI version on Mint Linux and have just finished processing the data via regex for the 21 files tested last night. I’ll update my original post with the findings.

13

Hi,

Using MediaInfo on the 21 H265 movie files tested last night (details in the post, above), I can confirm that all of the files exhibiting the reduced colourspace / washed out colours / black-as-grey issue are 8-bit; the 6 which work correctly on the Ver0 4K are 10-bit

[All 15 tested files which exhibit the problem on the Vero 4k, but which work fine with software decoding on a Pi 3]

Bit depth: “8-bit”
Color space: “YUV”
Chroma subsampling: “4:2:0 (Type 1 / Type 0)”
Color primaries | Transfer characteristics | Matrix coefficients; all: “BT.709”

[All 6 files which work correctly on the Vero 4K]

Bit depth: “10-bit”
Color space: “YUV”
Chroma subsampling: “4:2:0”
No entries present for at all for Color primaries, or Transfer characteristics, or Matrix coefficients

Hopefully this will help pinpoint the issue.

I’m happy to upload debug logs, but not sure how much data you’d like.

Thanks again in advance

14

Can you post some debug logs? I suspect something isn’t quite configured right.

Cheers

1 Like
15

Sure. I’ll playback on 10bit, and one 8bit file, then post the logs.

I have found one 8-bit HEVC movie amongst my collection which works correctly, and just tested 3 downloaded via the samples sites listed by another of the posters, above, which appear to work (however they don’t have any obvious black areas, so it’s hard to tell).

16

Hi Sam,

I’ve uploaded full logs to:
[redacted]

Debugging was enabled, the system rebooted, then, from an external usb drive, I played a few seconds from the start of four files:

  1. A working 10-bit h265 movie
  2. A working 10-bit h265 movie
  3. A problematic (blacks displaying as grey 8-bit h265 movie
  4. A problematic (blacks displaying as grey 8-bit h265 movie

Many thanks

17

Hi Sam,

re: /sys/class/amhdmitx/amhdmitx0/attr

I’ve re-checked cd /sys/class/amhdmitx/amhdmitx0/attr, which was modified by a hotfix to add ‘444, 10bit’ (this was the first thing I thought of as the likely cause of the colourspace issues I’ve been hacving).

Yesterday I changed the file’s permissions, and commented out the line. Checking it just now, it’s back to being uncommented, and the file permissions have reverted to non-writable.

I assume that a script is recreating the file (possibly triggered by cron), but have no idea where to look for it.

Can you advise on how to permanently remove this file or prevent my changes being overwritten?

Thanks,

18

Not a cron job but I assume you applied the hotfix which added it to /etc/rc.local/

1 Like
19

Hi fzinken,

Thanks for your help. Yes, that seems to be it - I’d actually just backtracked it to rc.local a few minutes ago, and removed the entry.

Unfortunately whilst it is no longer populating the /sys/class/amhdmitx/amhdmitx0/attr file, it hasn’t fixed the issue.

Thanks

20

Did you reboot?
Nothing obvious from logs. Maybe reinstall OSMC if you are able.