HDR too dark on TV

uhh, do people in this thread even read the posts? I’m gonna quote myself again from the previous post:

It’s literally the same bytes, bit for bit. Like I said in my previous post, it’s more likely the combination of the high bandwidth of the video stream and the high bandwidth of the audio stream that creates a bottleneck somewhere and the audio drops out.

I’m sorry. Since you chimed in with samples from not a remuxed video, I assumed you meant it was the same audio track - but also just ripped, and not byte for byte the same. Some people use the word “remuxed” when they mean re-encoded.

As an addendum, this is the first I’ve heard that the Atmos issue could be a combination bit-rate ceiling problem. Everything I’ve read on the subject PLUS the fix indicate it’s all the Atmos itself that’s the issue.

Read here:


And we can continue this in the original thread if we need to. The reason I bring this up is to cast doubt on your remuxed audio actually being a remux. I’m quite content to be wrong, but that thread suggests it is specifically in the audio track.

I tested re-encodes of Coco with intentionally wrong mastering display metadata. Re-encoding without master display metadata at all looks like the remux (HDR signaled but dim), while with it the brightness is back up, no matter the values, but otherwise doesn’t seem to affect the video. The Kodi GUI is affected though, the example “doctorG” changed green and strongly shaded the Kodi GUI yellow, and example “doctorWP” changed the white point and shaded the GUI blue. Bundle of re-encodes

Playing from the TV’s internal player looks unaffected by any of these changes, as does playing from my Samsung UHD Blu-ray player.

I would like to revise my answer :smile:. I just bought and ripped Coco UHD with MakeMKV 1.12.3 and I get the same result. I also got Wonder Woman, which is dim as well. I have ripped several other physical discs with this and one or two previous versions of MakeMKV, and these two are the only ones that look obviously different on the Vero. Also got IT today and that rip looks OK.

I uploaded samples from Thor Ragnarok and Terminator 2 remuxes to that LGissues link above. T2 truly is missing both mastering display metadata and content light level, but not Thor.

Inception is another one that I switched over to the TV because it was dim on the Vero. Black Panther maybe, but not as obvious.

You mean the GUI looks different after playing one of these clips? What means ‘multiplying green min/max’ and ‘boosting the white point’? Sorry for my ignorance.

FWIW, this is not limited to LG. The difference between the first two Coco clips posted is clear on my entry-level Panasonic.

Great info, thanks. Based on your Black Panther comment, it sounds like we don’t have a surefire way to check in MediaInfo if a movie will be dim on the Vero?

(One of the major issues with watching movies on the LG OLEDs directly is they do a poor job in general with UHD MKVs, with what looks like macroblocking errors at specific points during movies (easily repeatable). None of these issues occur on any other devices EXCEPT my OLED devices (LG C7, and the new LG Laser 4K projector). And yes, this is not a source issue, as these are remuxed directly from the UHD.

e.g. Lego Batman 4K UHD, at 7 mins 35 seconds, watch the Joker hanging onto his car for the next 10-15 seconds - and you’ll catch some nice macro-blocking-like glitching, which continues to occur sporadically afterwards throughout that scene. There’s a BUNCH of movies with this issue (the Harry Potter UHDs, for example). I never did figure out why.)

Anyway, thanks, all, for helping investigate the dim HDR issue.

The GUI is affect while playing these clips, like the video OSD with play and pause buttons, but goes back to normal when the clip ends. here’s a picture of the general effect from another user.

I intentionally re-encoded with wrong mastering display metadata (MediaInfo labels it Mastering display color primaries) that should clearly change the way the video looks if it was being applied directly. I don’t really know how these numbers actually work, and when I slapped an extra zero on them I ended up wrapping around the 16bit value so “doctorG” and “doctorWP” ended up with lower values rather than higher, but these should be helpful for a quick and obvious look at how a display or device utilizes them.

MediaInfo shows the expected info for all of these, so no, I don’t think it can. I wonder if potentially all remuxes are affected, and the extent of the dimness comes down to other factors of the video.

Edit: sorry for putting that out there, testing with The Matrix and Pacific Rim convinces me that’s not true. Those remuxes are good on the Vero, and I ripped Pacific Rim from my disc with MakeMKV v1.12.0.

Ugh that sucks… I may just continue to use the Vero for 1080p Blu-rays, and find something else for UHDs. At least for the timing being I’m using the Apple TV 4K for UHDs via Plex Direct Play.

This is way too big of an issue to leave not addressed, though, so I expect Sam will do some of his wizardry-figuring-out-of-things to fix it. You’d think that since it appears it’s ONLY the Vero with this specific UHD issue that it would be “simple” to figure out, right?

Nothing is simple when you have two or maybe three devices sniffing around each other like dogs trying figure out what each is capable of and which is responsible for doing translations.

I’m no programmer, but when one device out of zillions is behaving completely differently to those others, it FEELS like it should be something of an, “OOPS!” moment, and not something crazily hard to find.

Of course, it might be literally the opposite of that. In which case, I present my sad face. :smiley:


I must say that this topic is starting to make me paranoid. I orderd the vero 4k+ specifically to play uhd & uhd hdr remuxes on my new lg oled c8 and from what I read here it’s having problems doing that very thing :frowning:

We’ll work it out. This issue was only reported less than a week ago though, so it might need a small bit of time to resolve it.

HDR content is generally well tolerated on Vero 4K +. There will always be corner cases; so we will work on those.



With the Coco sample provided, Vero 4K is outputting incorrect mastering display metadata. Instead of 1000/0.000 nits, the output metadata is 5000/0.005 nits. It’s correct on the Shield (haven’t checked any other device). I’m not sure what is triggering this because I wasn’t able to reproduce this with other clips even when I change the metadata similar to the Coco one (P3, D65, 1000/0.000 nits, no maxCLL/maxFALL).


Well that’s interesting…

I will add some pr_info messages to amcsc later to see if we can work out where in the chain this is happening.


1 Like

I mean, that “Enable HDR Autoswitch”-option only works like 30% of the time for me. In most cases I have to restart the movie at least 3 times until it actually switches to 10bit. Sometimes even five times. In some rare cases (seems movie dependent) even trying it 10 times and a fresh restart doesn’t work, so I have to SSH into the Vero 4k and do the echo 444-thingy. Kinda annoying to be honest that this is still an issue.

You can just enable it permanently for now unless you keep swapping between SDR and HDR displays. I think this is what most people do.

There will be a build with improved HDR autoswitching shortly.

I further checked the Coco clip on two other Amlogic S905X devices (LE nightly on a M8S Pro+ and Mi Box 3 Android Oreo). The output metadata was correct on both the devices. I also noticed that I could simply overwrite the SEI messages for this clip in the commercial program that I use to edit SEI and the new clip would play with correct metadata. This makes me wonder whether there is something odd with SEI message parsing on Vero 4K (? HDR autoswitching code).

1 Like

That’s useful to know. I’ll check latest 3.14 drop from AML for any core changes. It may just be that simple; although I understand that LE’s current 3.14 kernel has some regressions re. HDR.

If it’s OK on Android it suggests that we’re lacking something, rather than having broken something.


Mi Box 3 has 4.9.54 kernel, but LE is 3.14. So, if it works fine on LE, it may be something that can be fixed easily.

Great detective work. I wish I were more understanding of this sort of metadata so I could contribute. I feel like all I’ve been successful in doing is yelling, “FIX IT!!” :smile: