Skip to content
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

Thumbnails have wrong colors for Dolby Vision files #84

Open
Keith94 opened this issue Feb 27, 2023 · 19 comments
Open

Thumbnails have wrong colors for Dolby Vision files #84

Keith94 opened this issue Feb 27, 2023 · 19 comments

Comments

@Keith94
Copy link

Keith94 commented Feb 27, 2023

With Dolby Vision files you have to use --vo=gpu-next to get proper colors. However, thumbnails are not color corrected like the actual video, so you get the purple and green hues in the thumbnail.

Reference: mpv-player/mpv#7326

mpv_8dEPiFSySZ

@Demetter
Copy link

Demetter commented Mar 8, 2023

Same with HDR. Thumbnails look washed out.

@hooke007
Copy link
Contributor

vo_lavc lacks the full support for HDR. Nothing we could do here.

@Keith94
Copy link
Author

Keith94 commented Apr 27, 2023

I wonder if the thumbnail can automatically use the default video renderer as well.

@Keith94 Keith94 closed this as completed Apr 27, 2023
@Keith94 Keith94 reopened this Apr 27, 2023
@hooke007
Copy link
Contributor

It never used renderer. Just decoding and encoding.

@po5
Copy link
Owner

po5 commented Apr 27, 2023

The only way that I know of which would let us do tonemapped thumbnails would be to take screenshots.
Sadly screenshot-raw isn't accessible by lua scripts so we'd need to use screenshot-to-file.
Would likely require a lot of changes, but I am looking into it.

@po5
Copy link
Owner

po5 commented May 13, 2023

Found a good compromise in 6c99377.
It will do good-enough tonemapping on HDR files (and DV files with an HDR fallback?).
The algorithm is copied from your mpv config, if it's available in ffmpeg. Otherwise it falls back to hable.

It's enabled for videos with bt.2020 primaries, is that a good enough check or are there more subtleties?

ffmpeg needs to be compiled with --enable-libzimg. Will automatically disable itself if the filter fails.
If you know of a way to detect (without spawning a process) which lavfi filters are available, that'd be nice to have.

ffmpeg wizards, is there a way to approximate DV tonemapping too, without a GPU? libplacebo can be used but I don't think -init_hw_device is exposed in any way, so it fails.

@hooke007
Copy link
Contributor

ffmpeg‘s tonemapping values doesn't fully match mpv’s ones.
https://ffmpeg.org/ffmpeg-filters.html#Options-3

@hooke007
Copy link
Contributor

Currently property tone-mapping will always return auto unless user manually set it to one of the algorithms.

@po5
Copy link
Owner

po5 commented May 13, 2023

Yup, and nothing that can be done about that. This commit falls back to hable if you configured an unsupported tonemapping algorithm.
I don't think it fully matches libplacebo's tonemapping even with a matching algorithm, ffmpeg's implementation does the minimum.

Currently property tone-mapping will always return auto unless user manually set it to one of the algorithms.

Have you tried it? properties["tone-mapping"] correctly returns hable for my setup. Maybe you didn't see the observe_property line?

@hooke007
Copy link
Contributor

I’m talking about mpv. It returns hable because there is no auto in ffmpeg.

@po5

This comment was marked as duplicate.

@hooke007

This comment was marked as duplicate.

@po5
Copy link
Owner

po5 commented May 13, 2023

Have you tried it? properties["tone-mapping"] correctly returns hable for my setup. Maybe you didn't see the observe_property line?

Please try it, I beg you. properties is populated by your mpv options. It does not come from the fallback. If you explicitly set the algorithm from mpv, it will be taken into account. I don't have access to the final value of auto when that's set as the mpv value. That's too bad.

In most cases, mpv will pick bt2390 for hdr, but mpv’s propertytone-mapping will not change its value.

So that's irrelevant since bt2390 is not supported in ffmpeg.

@hooke007
Copy link
Contributor

No,

I don't have access to the final value of auto when that's set as the mpv value.

which was what I’m talking about.

@po5
Copy link
Owner

po5 commented May 13, 2023

Can it? This is what the performance page of stats.lua uses, but I don't see my tonemapping (even explicit) anywhere.
I get the same values by printing vo-passes myself.

Seems to be the "color conversion" step.
Love Death and Robots S02E01 Automated Customer Service 1080p NF WEB-DL DDP5 1 Atmos DV HDR H 265-CRFW mkv_000014 167
Fresh config:
image

I see that it's available when vo=gpu-next. I guess we can check for it...

@hooke007
Copy link
Contributor

no. and prop vo-passes is not available for all vo

@po5
Copy link
Owner

po5 commented May 13, 2023

Now resolves auto when possible, and allows runtime changes.
I made sure it only fetches vo-passes when necessary.

@po5
Copy link
Owner

po5 commented May 13, 2023

Very cool, will play around with it.

@po5
Copy link
Owner

po5 commented May 14, 2023

It does work but it's slow, to the point of not being useful for generating thumbnails on the fly, at 1-2 full seconds between seeks.
I can only see a use for it if we add support for generating thumbnails in the background, though that's tricky to do with our current model.

Couldn't get hwmap/hwupload/hwdownload to work, either because I don't know how to do it or because it's impossible.
Here's hoping there is/will be a way to tonemap on the gpu from our thumbnailer process.

Sticking to the wrong-but-not-too-slow tonemap filter for now.
mpv-player/mpv#10678 someday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants