Closed mitzsch closed 1 month ago
If the file has metadata values like 0.0000 cd/m2
Then it is an invalid file, and there is nothing we can do about it.
Okay, but those values are found on commercially available discs. The 4K UK version of La La Land for example. In passthrough mode (-target-colorspace-hint=yes), I would rather have this "wrong" value to be transmitted instead of an entirely wrong max value.
Edit: The output looks wrong with the value of max 10.000 cd/m2 - with a "working" version of mpv it looks fine.
Specification is clear on this:
min_display_mastering_luminance, when in the range of 1 to 50 000, specifies the nominal minimum display luminance of the mastering display in units of 0.0001 candelas per square metre. When min_display_mastering_luminance is not in the range of 1 to 50 000, the nominal maximum display luminance of the mastering display is unknown or unspecified or specified by other means not specified in this Specification. When max_display_mastering_luminance is equal to 50 000, min_display_mastering_luminance shall not be equal to 50 000.
If the official distribution disc exist with 0 value, we can make an exception for this. It has to be validated, if this is more common issues or isolated incident.
Thanks for linking the specifications. However, there are multiple discs out there with min values of 0.0000 cd/m2 - Baywatch and The Martian in 4K are other examples.
we can make an exception for this.
This would be great, at least for "untouched" processing modes like passthrough it would be great if the values of the file could just be sent as is. For tone mapping done by libplacebo/mpv/ffmpeg it's probably fine to handle it differently - although I think forcing it to a max value of 10.000 creates wrong results....
@haasn: Would you be able to handle this case on ffmpeg side? I'm not sure sending patch myself would get reviewed anyway.
Anything new on this one? :)
Thanks!
mpv Information
Other Information
Reproduction Steps
Introduced with mpv v0.37.0-766-ge42a8d53 because of presumably this ffmpeg commit https://github.com/FFmpeg/FFmpeg/commit/1c45104f74e59beb25ce7451c98527f7a3c518f6. (I know its a ffmpeg issue but the commit is made by mpv devs*) The commit causes metadata to be wrongly handled.
If the file has metadata values like 0.0000 cd/m2, max: 1000 cd/m2, the max value gets reported as 10.000 cd/m2. =>![Screenshot 2024-05-19 185427](https://github.com/mpv-player/mpv/assets/43502191/bfb7d614-8efb-4531-a7b7-5a419b45bb71)
This is not only a reporting bug, the wrong max value is also reported to the display. (checked by a hdfury arcana)
The 0.0000 cd/m2 value for the min value triggers the wrong handling. Any other file with a non-0.0000 value, is treated correctly - the max value stays at 1000 cd/m2
mpv.com file.mkv -vo=gpu-next
is enough to trigger this behavior, hit i and you will see the wrong metadata valueExpected Behavior
Do not "alter" the value, process them like they are encoded in the file. file => 0.0000 cd/m2, max: 1000 cd/m2 => output => 0.0000 cd/m2, max: 1000 cd/m2
Actual Behavior
file => 0.0000 cd/m2, max: 1000 cd/m2 => output => 0.0000 cd/m2, max: 10.000 cd/m2
Log File
mpv_log_metadata_value.txt mpv_log_metadata_value_upstream_mpv.txt
Sample Files
No response
I carefully read all instruction and confirm that I did the following:
--log-file=output.txt
.