summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-11-16 19:02:36 +0100
committerwm4 <wm4@nowhere>2019-11-16 19:02:36 +0100
commit73c3dc0a7bc70cba374508d698d57a311b70f175 (patch)
treefd8e6203327d83a2a8f588f16feee91ad6f925f4
parentb2006eeb74f909c6e23b0b46907ada42b892f10a (diff)
downloadmpv-73c3dc0a7bc70cba374508d698d57a311b70f175.tar.bz2
mpv-73c3dc0a7bc70cba374508d698d57a311b70f175.tar.xz
vo_gpu: sync duplicated condition on peak computation
pass_color_map() (in video_shaders.c) and pass_colormanage() (video.c) both duplicate the condition on whether to do peak computation. Peak computation requires a compute shader, so if the duplicated conditions don't match, video_shaders.c will generate a compute shader, but video.c will try to run it as fragment shader. This leads to a "blue screen". This can be reproduced by playing a HDTV video with --target-peak=99. It's not clear how to fix this. Should pass_tone_map() be only invoked if mp_trc_is_hdr() == true (what pass_colormanage() uses to decide whether to enable peak computation), or should pass_colormanage() just tell pass_color_map() to skip peak computation? Decide for the latter, as it's more robust. Even if not correct, at least it gets rid of the blue shit. Fixes: #7149
-rw-r--r--video/out/gpu/video.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/video/out/gpu/video.c b/video/out/gpu/video.c
index a6db4ebaa9..7d9101239d 100644
--- a/video/out/gpu/video.c
+++ b/video/out/gpu/video.c
@@ -2629,6 +2629,8 @@ static void pass_colormanage(struct gl_video *p, struct mp_colorspace src,
"uint frame_max;"
"uint counter;"
);
+ } else {
+ tone_map.compute_peak = -1;
}
// Adapt from src to dst as necessary