When re-encoding MKV files I want to retain the HDR information which is pretty easy now with the relevant x265 options.
However I'm having trouble determining values for --max-cll based on the CLL and FALL values in the source.
I've seen lots of examples of this output in mediainfo, but for the source files I have (straight rips from MakeMKV) there never seems to be these values (although there are all the other appropriate HDR values for mastering/color profiles).
Should these values _always_ exist if a UHD Blu Ray source has HDR, and therefore mediainfo is for some reason not displaying them? Or is it the case that these values only sometimes exist, so in my examples they're just not there?
Max FALL and CLL values
Re: Max FALL and CLL values
What program are you trying to get help on? You didn't mention it.
MakeMKV Frequently Asked Questions
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
Re: Max FALL and CLL values
I assume you mean values like this:
What version of MakeMKV was used to create the MKVs that don't seem to have this data?
Code: Select all
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 168 cd/m2
-
- Posts: 13
- Joined: Mon Oct 26, 2020 3:00 pm
Re: Max FALL and CLL values
Those are the values I mean yes. Sorry I should've attached more information!
I used MakeMKV 1.15.3 from the Linux CLI (makemkvcon) just using the standard mkv rip. I've attached a copy of the mediainfo output from the ripped DVD (using mediainfo 20.09) that cuts off just after the audio track information starts for brevity.
I'm assuming during the re-encode that the MaxCLL and MaxFALL values are valuable and that encoding HDR info without them isn't of much use (or will produce non-optimal HDR results at least)?
I used MakeMKV 1.15.3 from the Linux CLI (makemkvcon) just using the standard mkv rip. I've attached a copy of the mediainfo output from the ripped DVD (using mediainfo 20.09) that cuts off just after the audio track information starts for brevity.
I'm assuming during the re-encode that the MaxCLL and MaxFALL values are valuable and that encoding HDR info without them isn't of much use (or will produce non-optimal HDR results at least)?
- Attachments
-
- makemkv-hdr.txt
- (2.65 KiB) Downloaded 587 times
Re: Max FALL and CLL values
I looked at the mediaInfo for all of my UHDs. Many had what appeared to be reasonable values. A few had no values. At least one had what appeared to be wrong values.
Probably wrong values:
At first I thought it was a difference between SMPTE 2084, SMPTE 2086, or SMPTE 2094, but I don't think that it is the case. I strongly doubt it is a value that MakeMKV is calculating. I suspect it is a value that is written to the movie when it is mastered by the studio & MakeMKV is just copying it when it is present.
Next I used ffprobe to look at one of my UHD rips that had no values. The data in the file shows 0.
See the link below for an example of the ffprobe command line.
https://codecalamity.com/encoding-uhd-4 ... th-ffmpeg/
Using ffprobe is probably a more reliable way to find those values than relying on mediaInfo.
Probably wrong values:
Code: Select all
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 1000 cd/m2
Next I used ffprobe to look at one of my UHD rips that had no values. The data in the file shows 0.
Code: Select all
"side_data_type": "Content light level metadata",
"max_content": 0,
"max_average": 0
https://codecalamity.com/encoding-uhd-4 ... th-ffmpeg/
Using ffprobe is probably a more reliable way to find those values than relying on mediaInfo.
Last edited by dcoke22 on Wed Oct 28, 2020 12:57 am, edited 1 time in total.
-
- Posts: 13
- Joined: Mon Oct 26, 2020 3:00 pm
Re: Max FALL and CLL values
Presumably that means it doesn't matter if they're set to 0 in that case if they sometimes are? I tried the ffprobe method with a demuxed m2ts rip that was originally Dolby Vision (but just the HDR encoded video track, not the Dolby Vision track) and that reported CLL and FALL values of 0, so looks like these may sometimes just be the values.
I don't have any standard (non-DV) HDR sources to test on at the moment (just encoded ones that I'm now curious as to whether they're wrong), so I'll try that shortly.
I don't have any standard (non-DV) HDR sources to test on at the moment (just encoded ones that I'm now curious as to whether they're wrong), so I'll try that shortly.