Neither of these clips report maximum or average luminances in mediainfo. I’m no expert, but isn’t this essential for correct rendering?
If you take a look at metadata_v5 - Google Sheets
You’ll notice a lot of movies don’t contain MaxCLL or MaxFALL data at all. Like yourself, I’m no expert but I read most displays actually don’t care about this information and do their own thing anyway.
One interesting thing, is the movies that people have noted can appear dark on the Vero 4K vs internal players are those with such data missing.
I’ve also had a chance to check Coco using my Nvidia Shield and it displays as bright as via the internal player, so I’m guessing it’s doing something different when it’s given a file without this information.
Indeed. We are looking at just setting some sane default values.
Nice spreadsheet, thanks!
Ideally we do want that data to know what to do.
I suspect there’s some ‘sane fallback’ that should be used when a file is played without this data. It might be tricky for us to work out the values used by an internal player, but we can trial and error it.
First we need to pass some attributes; presumably via the DRM_DB AVI packet. This needs some work.
That sheet is useful, cheers.
If anyone out there has an HDMI analyser, maybe it would be possible to snoop the default values sent by a device (eg: nvidia shield) that plays these HDR files that are missing information without issues?
I have an analyser, but limited hardware to test re. playback.
I have an idea though…
Sam
1 Like
I am confused by that statement. My scene-reencode from Coco has the same exact HDR metadata as that remux discussed here (tested with latest version of MediaInfo). Both files have no MaxCLL and no MaxFALL. One plays fine on the Vero 4k, one doesn’t.
To clarify for the rest: Yes, my uploaded sample file is from the scene-reencode. I stated this in my original post but that information was edited by Sam 
I uploaded it to maybe help these guys track down the issue because it’s the same video with (seemingly) the same HDR meta information but without the issues on the Vero 4k.
Yep, dead sure. I just recently discussed a different issue in another thread with Sam and ActionA which involved 444 and 10 bit setting in attr.
I did the test with the whole movie that was identical in media info k2u3 posted above. Just redid the test with the sample provided on https://collab.osmc.tv/s/CCDAKiBr9SQOIlO and it’s the same. It also looks the same as the whole movie.
You can do screenshots with LG’s WebOS: LG WEBOS 3.0 (PAP & Freez Screen & ScreenShot ) - YouTube but I’m not sure about how to get them from the TV to another device so you can upload them on here, show the difference, and compare.
I have many UHDs without MaxCLL/MaxFALL and have no issues with a dim picture with the Vero 4K barring a likely growing set that I haven’t watched yet. Most movies don’t have this information, which is super annoying because my projector has a 1000-nit and 4000-nit calibration, and can read that data and present it on screen.
Since many/most movies don’t get mastered with that info I have to use MediaInfo before watching a movie to determine said info and set my projector to the right calibration so highlights etc are presented correctly. Annoying! 4K HDR is at times a darn nuisance since it feels like there’s a billion standards vying for relevancy out there.
This Vero issue is peculiar. Using MediaInfo I couldn’t see any difference between Cars 3 and Coco, yet Coco is dim and Cars 3 is not. This is clearly beyond my pay-grade, but I’ll have to keep a list so I can use an alternative playback device (for the time being, at least) for those trouble movies. Maybe we can keep this thread updated with movies that are dimmer on the Vero. The more feedback the better in this case.
I’ve been quite busy this week but can definitely confirm Terminator 2 and Coco.
Since re-encoding packs in the metadata that the Vero can’t find in the remuxes, I experimented a bit with re-encoding to see what a sensible default might be. Adjusting maxcll / maxfall didn’t help Coco, Thor Ragnarok, nor Terminator 2, but setting the “master-display” did. The Coco and Thor Ragnarok remuxes do have that metadata in the frame SIDE_DATA, but Terminator 2 does not (and looking at that spreadsheet a lot of the HDR metadata is zeroed out so that seems reasonable). Setting the master display metadata for T2 to the same as Coco produced a good looking result, however.
Further research shows this matches DCI-P3 with D65 white point, and luminance at 1000 nits max 0 nits min, which looks like a sensible default considering the spreadsheet. Maybe min luminance at 0.005 nits instead.
All three Iron Man (remuxes of the not-great UHDs released only in Germany) have even weirder behavior: they start out properly bright, but after seeking go dim, then within ~10 seconds pop back bright. Here’s a sample, but as it’s cut in the middle it starts out dim, then when the camera changes about 6 seconds in it gets brighter. Seeking back will go dim again. They all have SIDE_DATA for mastering display metadata, but no MaxCLL/FALL, not even set to 0. Re-encoding with master-display set these to 0, even though I didn’t explicitly set that option. Maybe it will serve to default these to 0,0 if the stream is missing them completely.
Interesting info, thank you. So so far we have Coco, T2 and Thor: Ragnarok as issues. I can certainly re-encode those if necessary, but would of course prefer a fix at the playback device - the Vero.
So, master-display seems to be the key, you think?
Ironically, Ragnarok UHD is already one of the Disney movies with Atmos dropout issues on the Vero 4K, so for now at least people should put off watching that movie for more than one reason!
The “Mastering Display”-fields shouldn’t be the issue. Again, my Coco x265-crf17 file has the exact same HDR meta data in MediaInfo as your Coco file. Mine plays fine on the Vero 4k. So unless MediaInfo is not displaying all the HDR fields or the Vero4k reads them wrong in your files for some reason, it shouldn’t be the issue. According to MediaInfo, both samples have the same media information.
Also, I watched Thor Ragnarok 4k a few weeks ago and had no issues with Atmos. Again, this was a x265-crf17 file created from the BR-UHD. Maybe your Atmos dropout issues were related to your bandwidth? High bitrate video stream + high bitrate audio stream. Because the Atmos audio stream on my file is exactly the same as yours, “remuxed” from the BR-UHD.
I have precisely zero opinion on the Mastering Display issue. The Atmos issue you wouldn’t have an issue with because your version isn’t the full bandwidth Atmos track. The Atmos dropouts issue is only when tracks go above 10Mbit - during those scenes. A growing bunch of Disney movies have this issue (Incredibles, the latest Pirates movie etc).
I know the Atmos issue has been addressed in other Kodi devices (since it affects ALL of them as far as I’ve been aware).
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:
https://forum.kodi.tv/showthread.php?tid=327153
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 
. 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.