Thanks for the feedback.
Thanks for that - whatâs the mediainfo on Cars 3?
To update. In terms of best picture in Cocoâs intro with this test OMSC build, itâs definitely Apple TV 4K the best. Nice contrast, looks great. Then the Vero. I may need to check again because itâs very close and my eyes are burning from checking. And then the LG OLED - super washed out. Looks dreadful by comparison.
edit
Checked again. No question Apple TV 4K outputs the nicest image. Vero is a relatively close second (my eyes need a break from this), and the LG OLED a VERY VERY distant third.
Format : Matroska
Format version : Version 4 / Version 2
File size : 36.4 GiB
Duration : 1h 42mn
Overall bit rate mode : Variable
Overall bit rate : 50.9 Mbps
Movie name : Cars 3 4K
Encoded date : UTC 2017-12-23 03:37:27
Writing application : mkvmerge v19.0.0 (âBrave Captainâ) 64-bit
Writing library : libebml v1.3.5 + libmatroska v1.4.8
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Commercial name : HDR10
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1h 42mn
Bit rate : 44.5 Mbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) fps
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.224
Stream size : 31.9 GiB (87%)
Writing library : ATEME Titan File 3.8.3 (4.8.3.0)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0000 cd/m2, max: 1000 cd/m2
hmmm. Looks like we need to do what the TV makers are doing: here are some options - play around with them until you like what you see.
With new build (119) it now outputs 1000/0.005nits. However, I noticed something else when I was copying the HDR InfoFrame. The values sent for mastering display primaries are actually for BT.2020. It should be for DCI-P3. What does a display do with this information is something that only the engineers who designed the display can answer.
These are the captured HDR InfoFrames from Vero 4K and Amazon Fire TV 4K (the only digital media player than I know of that outputs complete & perfect HDR10 metadata that matches the source content).
Fire TV 4K, no MaxFALL /Max CLL
87:01:1a:22:02:00:c2:33:c4:86:4c:1d:b8:0b:d0:84:80:3e:13:3d:42:40:e8:03:00:00:00:00:00:00
Fire TV 4K, with custom MaxFALL/MaxCLL (277/42nits) appropriate for the Coco sample provided 87:01:1a:e2:02:00:c2:33:c4:86:4c:1d:b8:0b:d0:84:80:3e:13:3d:42:40:e8:03:00:00:15:01:2a:00
Vero 4K
87:01:1a:5d:02:00:34:21:aa:9b:96:19:fc:08:48:8a:08:39:13:3d:42:40:88:13:32:00:00:00:00:00
display primaries are in units of 0.00002, Max luminance/MaxFALL/MaxCLL are in 1cd/m2 unit, Min luminance is in 0.0001cd/m2 (1nit = 1cd/m2).
3 Likes
Apple TV 4K replaces the HDR10 metadata with its own generic one (BT.2020, D65, 1000/0.005nits, MaxFALL/MaxCLL-4000/1000nits). This only applies to Kodi, MrMC, Infuse Pro etc. It doesnât apply to Netflix, Amazon Prime Video etc.
For these tests, Iâm only using HDFury Vertex.
Interesting, thank you. So⌠Iâm at a loss. Are we in good shape/bad shape/indifferent shape at this point?
No. If you see ATEME Titan in MediaInfo, you can be assured that it is a direct copy from the retail disc (Unless you just happen to own ATEME Titan Encoder or you are a studio employee misusing studio property).
As far as Coco and other titles that have similar Max/Min mastering display luminance is concerned, this patch should be OK. As I said before, I really canât comment on what LG or Samsung does with gamut mapping.
OK good to know. Thank you for all your efforts, here - and thanks Sam etc for getting this build out so speedily.
A quick test has all the noted movies looking better. I canât point to any clear differences from the TVâs internal player, now. My eyes canât say they are definitely the same after flipping across inputs and such, but I like the results.
Are they supposed to look the same? I donât have Cars 3, but I assumed Cocoâs intro was specifically designed to be dusky. It is that way on the standard Blu-ray, too.
I canât say theyâre supposed to look the same at all, but itâs clear from the first two seconds of the sample clips that Cars 3 is staggeringly brighter. Iâd need to dig out my discs from the garage and compare. I may get to it this weekend.
Cars 3 opening sequence has been graded to be slightly brighter than Coco sequence. You can see it in the graphs below.
Cars 3
Coco
3 Likes
I also probably know the reason for this issue. Both titles have seamless branching. Vero 4K is having difficulty reading SEI messages from the joined m2ts file. May be has to do with the version of FFmpeg being used?
Once again, thank you for the efforts. Seems like weâre getting closer to figuring this out once and for all. Interesting about the grading. Certainly not slight to my eyes (at least not in that intro)! 
Sam will likely have the answers here to your FFmpeg question.
This is getting complicated. Can you recommend a reference explaining seamless branching? Iâve seen the word in the code but donât know what the implications are. Is that about the mux or the stream? Reason: ffmpeg does the demux, amcodec does the decode.
I donât think I have come across publicly available documentation on BD ROM seamless branching. I also donât know how exactly MakeMKV etc. joins the m2ts segments. To explain it briefly, these discs have the main playlist segmented into several m2ts files. MakeMKV etc. is capable of reading the order of the segments in the playlist and joins the segments into one single m2ts file. Depending on what triggers the HDR mode on Vero 4K, it could be a problem with demux or decode. I am assuming that HDR mode is set by parsing the file before the playback begins. This is why I mentioned FFmpeg.
Thanks again. We see this comment in the HEVC decoder as a parameter for search control:
bit 0: 0, header auto parse; 1, header manual parse
bit 1: 0, auto skip for noneseamless stream; 1, no skip
bit [3:2]: valid when bit1==0;
0, auto skip nal before first vps/sps/pps/idr;
1, auto skip nal before first vps/sps/pps
2, auto skip nal before first vps/sps/pps,
and not decode until the first I slice (with slice address of 0)
3, auto skip before first I slice (nal_type >=16 && nal_type<=21)
From your knowledge, can you decipher it? At the moment, only bit 3 is set.
I donât think that code will have an effect on this issue. SEI messages are in non VCL NAL units. The code is for VPS/SPS/PPS. There is also the fact that the HEVC decoder is actually presented with a single elementary stream. The seamless segments were already joined together by makeMKV etc. It would be interesting to see whether the problem occurs with backups made with other software. In all likelihood, @WilliamG used makeMKV for the backup.