Those are all Remux-files we were talking about, aka nothing was reencoded, the videostream is a direct copy off the UHD-BD.
Also, MediaInfo doesn’t display any HDR-metadata for Terminator 2 (not just for me/us, but seems like for everybody on the Internet). It’s either not there (???) and all the players just use the default 0.0005/1000 values as fallback or MediaInfo can’t read it properly.
Yes, that’s why mention of an encoder confused me. Wondered what an encoder had to do with it.
We’ve implemented a more realistic fallback now.
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
- Login via the command line
- Edit the file
/etc/apt/sources.list - Add the following line:
deb http://apt.osmc.tv stretch-devel main - Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot - Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.
hmmm. Better wait 1/2 hour or so?
Yep, I accidentally clicked send before Jenkins finished.
Safe to try the update now? And what’s the fallback?
edit
Tried anyway, got vero364-image-3.14.29-117-osmc:arm64
Hopefully that’s correct. Will test now…
edit
No change. Tested Coco and it’s still really dim.
You aren’t testing the latest changes. Try again in 20 minutes or so when the mirror syncs
Good to know. Thanks!
Just out of insterest - How obvious is the difference between the posted Coco clips?
Is 3.14.29-118 the one with the latest changes? If it is, then it hasn’t changed anything. The output metadata still shows 5000/0.005 nits.
When you asked for good/bad AVI InfoFrame, what exactly were you looking for? A “bad” one from Vero 4K and a “good” one from another device?
It all depends on your display and its tonemapping. You may not see a difference on some lower end HDR displays.
I made the comment about nVIDIA encoder as an example scenario for the SEI message not being read properly. If the file is as is from the 4K Blu-ray or has been re-encoded with x265, then this won’t be an issue. If it was encoded using NVENC, then there could possibly an issue. The Coco sample provided is a cut from the original file authored using Scenarist and encoded by ATEME Titan encoder.
Don’t know what’s gone on there. The source still seems to say 5000.
Edit: problem found and a new kernel is cooking now. Ready in an hour or so.
If you could just grab an infoframe from vero and from some other device with a different presentation, we can have a look at the differences and whether vero is actually outputting what it should be according to the registers.
So you are saying all the clips we have here are (re)encoded, not just demuxed? i thought the WilliamG dark one was “original” ie just remuxed.
I’ve kicked off a new build and it should be ready in just over an hour
Sam
Mine is remuxed. Untouched. I’ll check the new build when it goes live.
How are you checking the output metadata?
So that means ATEME Titan is what Disney used to make the disc, or am I still behind the curve, here?
kernel 119 is ready if ppl want to test it, please.
I’ll try and get this going now.
vero364-image-3.14.29-119-osmc:arm64
Ok, some results.
Yes, Coco and T2 look MUCH better.
This part is interesting. Coco looks better now on the Vero than even on the LG C7 OLED built-in app, - and similar to the Apple TV 4K. It’s easy to tell in the first 2 seconds of the sample in the sky. More contrast on the Vero and ATV4K, and more grey/washed out on the TV (yes, same picture settings on both).
However, Cars 3 - that same intro is still FAR brighter than Coco’s intro. The luminance difference is STARK, and it doesn’t look washed out on any devices, Vero included. It’s positively BLINDING in the intro compared to Coco.
I really wonder if Coco is just not mastered correctly?