-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong metadata handling when file has min: 0.0000 cd/m2, max: 1000 cd/m2 values #14177
Comments
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. Edit: |
Specification is clear on this:
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.
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! |
The H.265 specification is quite clear on this case: > When min_display_mastering_luminance is not in the range of 1 to > 50000, the nominal maximum display luminance of the mastering display > is unknown or unspecified or specified by other means not specified in > this Specification. And so the current code is correct in marking luminance data as invalid if min luminance is set to 0. However, this breaks playback of at least several real-world Blu-ray releases, for example La La Land, Planet of the Apes, and quite possibly a lot more. These come with ostensibly valid max_luminance tags (1000 nits), but min_luminance set to 0. Loosen up this requirement by guarding it behind FF_COMPLIANCE_STRICT. We still reject blatantly invalid metadata (wrong value range on luminance, max set to 0, max below min, min above 50 nits etc.), so this shouldn't cause any unintended regressions. Fixes: mpv-player/mpv#14177
Fixed in FFmpeg/FFmpeg@9fd88bd |
The H.265 specification is quite clear on this case: > When min_display_mastering_luminance is not in the range of 1 to > 50000, the nominal maximum display luminance of the mastering display > is unknown or unspecified or specified by other means not specified in > this Specification. And so the current code is correct in marking luminance data as invalid if min luminance is set to 0. However, this breaks playback of at least several real-world Blu-ray releases, for example La La Land, Planet of the Apes, and quite possibly a lot more. These come with ostensibly valid max_luminance tags (1000 nits), but min_luminance set to 0. Loosen up this requirement by guarding it behind FF_COMPLIANCE_STRICT. We still reject blatantly invalid metadata (wrong value range on luminance, max set to 0, max below min, min above 50 nits etc.), so this shouldn't cause any unintended regressions. Fixes: mpv-player/mpv#14177 Signed-off-by: Paul B Mahol <onemda@gmail.com>
mpv Information
Other Information
Reproduction Steps
Introduced with mpv v0.37.0-766-ge42a8d53 because of presumably this ffmpeg commit FFmpeg/FFmpeg@1c45104. (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.
=>
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
.The text was updated successfully, but these errors were encountered: