Because it can’t read the master display meta and it defaults to P3 and 5,000/0.005nits. Are you able to see anything in those files about how/where that meta is stored which might help us? I don’t know anything about the workings of HEVC.
If you are right about mastering, maybe we should make the default 2,000nits as the average of 1000 and 4000.
That is NOT a solution. You’d be actively CHOOSING to run every single movie that couldn’t be read (something that should be figured out) at an incorrect luminance. I’m kind of astonished this is even being discussed.
I’d honestly rather it stay broken until it’s fixed. I don’t like the idea of fudging something because I get the feeling “if it’s good enough”, it won’t get fully addressed.
Not a conclusion but something to make these films present better while we get to the bottom of it. You an always watch the disk while you are waiting.
Concerning the mastering issue: in a short mail exchange after being temporarily banned for commenting on their Marrowbone release about wrong colour specs, a member of RARBG support told me
More than 25% of the 4k blurays don’t have proper HDR mastering.
Interesting. So…why do other devices seem to deal with this issue without trouble? Is it just a fall-back protocol these other devices have or something else?
I thought I had explained that. Either they are managing to read the mastering meta or they are ‘falling back’ to values which are correct for the file. For Coco, this seems to be max luma 1000, and it seems lots of other disks use the same value. The primaries and white point are pretty universally P3 and D65 I’m guessing, and surprisingly, the content lumis don’t seem to matter.
Some HDR HEVC streams that definitely do have the mastering metadata, sourced directly from UHD Blu-ray discs.
MediaInfo, ffprobe, and presumably wesk’s commercial tool are reading it, so it is there, just slightly different so the Vero doesn’t pick it up.
The trick is to find out why the Vero doesn’t pick it up.
Samples of this from Coco, Thor Ragnarok, and Wonder Woman have been submitted.
Some HDR HEVC streams that really don’t have the mastering metadata.
The solution here is to come up with a sane default.
The Dolby Pulsar is “exclusive”, so I figure the folks that use such a thing would definitely check that box. I suggest 1,000 as the fallback, and maybe a video option in Kodi to change it to 4,000.
A sample of this from Terminator 2 has been submitted. I can’t say for certain this is how it came on the disc, but it isn’t dim on other players.
Wonder Woman is dim and mastered with max luma 4,000 and non-zero content light level, different from Thor and Coco, so I’ve submitted a sample of that, too. Outer space in the opening loses a lot of detail on the Vero.
If Wonder Woman is dim at 4,000 nits mastering, then I guess I’m really confused. If the Vero is falling back to 5,000 nits when it can’t read or isn’t reading the metadata, then if in the meantime we set playback to 2,000 nits in this scenario - surely it doesn’t solve the issue, if I’m reading into this correctly.
i.e. if 4,000 nits source at 5,000 nits playback looks dim, won’t a 1,000 nits source played at 2,000 nits also be an issue?
There is really only one way to write the HDR10 metadata if the file has to be in conformance with HEVC specifications. It has to be present in the SEI messages and has to be repeated with every coded video sequence. nVIDIA encoder seems to write it only once at the beginning of the bitstream. This is basically incorrect. You could also add the metadata to MKV header, but Amlogic decoders seem to ignore container header values.
The Coco clip does have several HEVC non-conformance errors, but I didn’t see anything that could be attributed to the issue being discussed. I do have Thor Ragnork, Wonder Woman and Terminator 2 4K Blu-rays, but haven’t “backed” up them. It would be interesting to check what is different with these titles.
Is ‘nVIDIA encoder’ what is being used to make these rips? If so, that could explain it.
I believe it’s Kodi that does the demuxing, then just uses amcodec for the decode. Amplayer is not used. So amlogic doesn’t know what’s in the mkv header.