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

mpv blue screen, on latest build #3293

Closed
zhangn1985 opened this issue Jun 29, 2016 · 2 comments
Closed

mpv blue screen, on latest build #3293

zhangn1985 opened this issue Jun 29, 2016 · 2 comments

Comments

@zhangn1985
Copy link

mpv version:

mpv git-9ca1592 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Wed Jun 29 07:57:12 CST 2016
ffmpeg library versions:
   libavutil       55.17.103
   libavcodec      57.24.102
   libavformat     57.25.100
   libswscale      4.0.100
   libavfilter     6.31.100
   libswresample   2.0.101
ffmpeg version: 3.0.2-4

mpv.conf:

ao=pulse
vo=opengl
hwdec=vaapi
cache-default=1048576
cache-secs=300
#user-agent='Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.1'
save-position-on-quit
video-sync=display-resample
no-ytdl

error log:

[vo/opengl] fragment shader source:
[vo/opengl] [  1] #version 120
[vo/opengl] [  2] #define texture texture2D
[vo/opengl] [  3] varying vec2 texcoord;
[vo/opengl] [  4] varying vec4 ass_color;
[vo/opengl] [  5] uniform sampler2D osdtex;
[vo/opengl] [  6] #define LUT_POS(x, lut_size) mix(0.5 / (lut_size), 1.0 - 0.5 / (lut_size), (x))
[vo/opengl] [  7] void main() {
[vo/opengl] [  8] vec4 color = vec4(0.0, 0.0, 0.0, 1.0);
[vo/opengl] [  9] // OSD (libass)
[vo/opengl] [ 10] color = vec4(ass_color.rgb, ass_color.a * texture(osdtex, texcoord).r);
[vo/opengl] [ 11] // color management
[vo/opengl] [ 12] color.rgb = clamp(color.rgb, 0.0, 1.0);
[vo/opengl] [ 13] color.rgb = mix(color.rgb / vec3(12.92), pow((color.rgb + vec3(0.055))/vec3(1.055), vec3(2.4)), lessThan(vec3(0.04045), color.rgb));
[vo/opengl] [ 14] color.rgb = clamp(color.rgb, 0.0, 1.0);
[vo/opengl] [ 15] color.rgb = pow(color.rgb, vec3(1.0/2.4));
[vo/opengl] [ 16] gl_FragColor = color;
[vo/opengl] [ 17] }
[vo/opengl] fragment shader compile log (status=0):
[vo/opengl] 0:13(13): error: no matching function for call to `mix(vec3, vec3, bvec3)'; candidates are:
[vo/opengl] 0:13(13): error:    float mix(float, float, float)
[vo/opengl] 0:13(13): error:    vec2 mix(vec2, vec2, float)
[vo/opengl] 0:13(13): error:    vec3 mix(vec3, vec3, float)
[vo/opengl] 0:13(13): error:    vec4 mix(vec4, vec4, float)
[vo/opengl] 0:13(13): error:    vec2 mix(vec2, vec2, vec2)
[vo/opengl] 0:13(13): error:    vec3 mix(vec3, vec3, vec3)
[vo/opengl] 0:13(13): error:    vec4 mix(vec4, vec4, vec4)
[vo/opengl] 
[vo/opengl] shader link log (status=0): error: linking with uncompiled shader

video card: intel
video driver: xserver-xorg-video-intel
OS: debian 9 (testing)

reproduce: play any movie, and move mouse to player window.
reproducibility: 100%

I just git pull mpv, and rebuild.
and git update to: 4ce5302..9ca1592

@zhangn1985
Copy link
Author

checkout to 4ce5302 , and rebuild, everything goes fine.

@haasn
Copy link
Member

haasn commented Jun 29, 2016

Bug is caused by an (unintended) change in behavior to subtitle color management. I'm thinking it might be time to revisit this behavior, since pass_colormanage has grown to be much more than a simple routine for adapting colors (and more of a big auto-detection heuristic function).

haasn added a commit to haasn/mp that referenced this issue Jun 29, 2016
This involves multiple changes:

1. Brightness metadata is split into nominal peak and reference peak.

For a quick and dirty explanation: nominal peak is the brightest value
that your color space can represent (i.e. the brightness of an encoded
1.0), and reference peak is the brightest value that actually occurs in
the video.

2. vo_opengl uses a new decision logic to figure out the right nom_peak
and ref_peak for all situations. It also does a better job of picking
the right target gamut/colorspace to use for the OSD. (Which still is
and still should be treated as sRGB). This change in logic also
fixes mpv-player#3293 en passe.

3. Since it was growing rapidly, the logic for auto-guessing / inferring
the right colorimetry configuration (in pass_colormanage) was split from
the logic for actually performing the adaptation (now pass_color_map).

Right now, the new logic doesn't do a whole lot since HDR metadata is
still ignored (but not for long).
haasn added a commit to haasn/mp that referenced this issue Jun 29, 2016
This involves multiple changes:

1. Brightness metadata is split into nominal peak and signal peak.

For a quick and dirty explanation: nominal peak is the brightest value
that your color space can represent (i.e. the brightness of an encoded
1.0), and signal peak is the brightest value that actually occurs in
the video (i.e. the brightest thing that's displayed).

2. vo_opengl uses a new decision logic to figure out the right nom_peak
and sig_peak for all situations. It also does a better job of picking
the right target gamut/colorspace to use for the OSD. (Which still is
and still should be treated as sRGB). This change in logic also
fixes mpv-player#3293 en passant.

3. Since it was growing rapidly, the logic for auto-guessing / inferring
the right colorimetry configuration (in pass_colormanage) was split from
the logic for actually performing the adaptation (now pass_color_map).

Right now, the new logic doesn't do a whole lot since HDR metadata is
still ignored (but not for long).
haasn added a commit to haasn/mp that referenced this issue Jul 3, 2016
This involves multiple changes:

1. Brightness metadata is split into nominal peak and signal peak.

For a quick and dirty explanation: nominal peak is the brightest value
that your color space can represent (i.e. the brightness of an encoded
1.0), and signal peak is the brightest value that actually occurs in
the video (i.e. the brightest thing that's displayed).

2. vo_opengl uses a new decision logic to figure out the right nom_peak
and sig_peak for all situations. It also does a better job of picking
the right target gamut/colorspace to use for the OSD. (Which still is
and still should be treated as sRGB). This change in logic also
fixes mpv-player#3293 en passant.

3. Since it was growing rapidly, the logic for auto-guessing / inferring
the right colorimetry configuration (in pass_colormanage) was split from
the logic for actually performing the adaptation (now pass_color_map).

Right now, the new logic doesn't do a whole lot since HDR metadata is
still ignored (but not for long).
@ghost ghost closed this as completed in 923e3c7 Jul 3, 2016
This issue was closed.
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

2 participants