Join GitHub today
Screenshots do not preserve GPU-accelerated features such as HDR. #5498
mpv version and platform
Running on Arch Linux with version 4.14.15-1 of the Linux kernel. The VO driver used is
Currently, screenshots do not properly output and preserve GPU-accelerated feature(s) such as HDR. Instead, the screenshot that is outputted is an 8-bit version of the 10-bit HDR frame, resulting in a very washed-out image that is not representative of the image displayed in mpv in the slightest. This happens on both the
I'm unsure if there are other features not present in the outputted image, as I've only tested HDR as of this time. Below are a few examples I tested with "Life of Pi" sample HDR footage, and a ripped UHD BD HDR copy of the animated film "Your Name". All comparison images have been downscaled to 1280x720 for smaller file sizes, and all tone-mapping & related HDR options have been kept to default. The
"Life of Pi" sample HDR footage
“Regular” screenshots and “window” screenshots go through very different code paths.
Regular screenshots take the frame, pass them through libswscale to convert to RGB, and then save this to disk. The data never touches the VO, or the GPU for that matter.
Window screenshots go through the VO's rendering path - as you said, they're basically hard screenshots of what's visible on-screen. Since the
There are a couple of possible work-arounds and long-term solutions:
The fourth solution seems to be the one with the most benefits with the least disadvantages.
Do you have any specific opinions as well?
The fourth would probably be the easiest for me to get going, it would also be a good test case for
On the other hand, further downsides are the fact that libplacebo is still WIP/beta and therefore might not be the best fit for an on-by-default solution. It'd be more of an experimental branch for now, I think. libplacebo also only currently supports vulkan, so there would be little hope for getting this running on a system that doesn't, at least for the immediate foreseeable future. There is no CPU-emulation of the libplacebo algorithms planned. So with that in mind, especially on systems with older or weaker GPUs or where vulkan is not available, the zimg/tonemap approach might be more reasonable.
That said, we could also do both: I wouldn't be opposed to adding libplacebo as a strictly optional dependency that users who do meet all the prerequisites can use it for higher quality screenshots, but mpv will otherwise fall back to zimg/tonemap's CPU algorithms.
My main issue is that I don't really know my way around FFmpeg code at all, so I'd have trouble working on any sort of zimg/tonemap based approach.
tl;dr I could implement 3. 4. and with difficulty 5., but not 2.
You could always try out the fourth option for now and tag it under "experimental" features, and then when an alternative for lower-end users like the second option comes around, likely developed by someone else, then both features could move out of the "experimental" label. Whatever "experimental" ends up being, that is.
referenced this issue
Feb 7, 2018
I'd tend to agree that the current renderer should be used or be fixed so that it can be used, otherwise there are two code-paths that do the same thing and we'd have to fight to get the results consistent between them. If someone has spent 3 hours tweaking their mpv.conf vo options, those should be honoured in making the screenshot as applicable.