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

I need opengl-early-flush #3670

Closed
tholin opened this Issue Oct 16, 2016 · 11 comments

Comments

Projects
None yet
6 participants
@tholin

tholin commented Oct 16, 2016

commit 6789f9b09411f83034883357303b4acfda9569ed
Author: wm4 <wm4@nowhere>
Date:   Wed Oct 5 12:18:44 2016 +0200

    vo_opengl: disable glFlush() by default, and add an option to enable it

    It seems this can cause issues with certain platforms, so better to
    disable it by default. The original reason for this isn't overly
    justified, and display-sync mode should get rid of the need for it
    anyway.

    The new option is meant for testing, and will probably be removed if
    nobody comes up and reports that enabling the option actually improves
    anything.

I just want to report that this option do improve things for me.

I used intel graphics on a linux desktop with dual head monitors. I use xf86-video-intel-2.99.917_p20160621-r1 (just some random revision because intel has stopped releasing stable drivers). I use AccelMethod=uxa because SNA is broken in various ways and I run without compositioning because that's also broken.

With opengl-early-flush=yes and video-sync=audio I get frame drops & repeats perhaps once every 30 sec and at the same time I might get a torn frame. On average I get a torn frame every few minutes.

With video-sync=display-resample I get a torn frame about once per second always in the top part of the monitor. Opengl-early-flush doesn't change that.

With opengl-early-flush=no and video-sync=audio I get tearing every frame so the best option for me is opengl-early-flush=yes and video-sync=audio.

@wm4 wm4 added the intel-bug label Oct 17, 2016

@wm4

This comment has been minimized.

Contributor

wm4 commented Oct 17, 2016

Thanks for letting us know. This is extremely strange. Not sure what to make of this. By now this would probably conflict with OSX...

@ghost

This comment has been minimized.

ghost commented Oct 19, 2016

opengl-early-flush=yes fixes flickering for me on macOS Sierra with Intel graphics (Iris Pro). I can reliably reproduce the flickering with 10-bit videos, and it usually happens after resizing the window a couple of times or going to fullscreen.

Here's an example of it happening: https://my.mixtape.moe/okhyaf.mp4

@Argon-

This comment has been minimized.

Member

Argon- commented Oct 19, 2016

When watching the movie (mpv window in the front), can you see elements or whole windows behind it as a black, short flicker?
Because that's what I recently get sometimes on 10.11 (El Crapsomething). Haven't had the time to check when exactly it happens and how to reliably reproduce though.

@ghost

This comment has been minimized.

ghost commented Oct 19, 2016

Nope, I can only see it if there's a system overlay (like the alt-tab view or volume thingy) or a window on top of mpv's window.

@limbirdk

This comment has been minimized.

limbirdk commented Oct 20, 2016

Don't know if there should be a separate issue for AMD hardware, but I'm experiencing frame dropping with some videos that wasn't occurring on 0.20.0. It seems to just be happening with subtitle streams that use heavy typesetting. Using opengl-early-flush solves the issue for me.

GPU: HD Radeon 6870
Driver: r600g
Mesa: 12.0.3
XServer: 1.18.4
Linux Kernel: 4.7.6

@Argon-

This comment has been minimized.

Member

Argon- commented Oct 20, 2016

It seems to just be happening with subtitle streams that use heavy typesetting

That was always the case though. Heavy subs will cause drops when they take too long to render.

@limbirdk

This comment has been minimized.

limbirdk commented Oct 20, 2016

Yeah I'm saying that those drops don't occur for me with opengl-early-flush enabled. Nor occur on release 0.20.0.

@wm4

This comment has been minimized.

Contributor

wm4 commented Oct 20, 2016

Yeah, seems like this had some real worth on non-OSX, at least in audio-sync mode.

@lachs0r

This comment has been minimized.

Member

lachs0r commented Oct 21, 2016

OT:
@tholin you might want to remove xf86-video-intel entirely because the modesetting driver + glamor is mature enough these days and the Intel DDX gets worse and worse every year. Seems like they’re not even trying to fix any problems with it.

@wm4

This comment has been minimized.

Contributor

wm4 commented Oct 21, 2016

So I'm considering adding an "auto" choice for --opengl-early-flush, which would run glFlush if audio sync mode is used and it's not on OSX, and making it the default. Opinions?

wm4 pushed a commit that referenced this issue Oct 21, 2016

wm4
vo_opengl: partially re-enable glFlush() calls
It turns out the glFlush() call really helps in some cases, though only
in audio timing mode (where we render, then wait for a while, then
display the frame). Add a --opengl-early-flush=auto mode, which does
exactly that.

It's unclear whether this is fine on OSX (strange things going on
there), but it should be.

See #3670.
@Cpuroast

This comment has been minimized.

Cpuroast commented Oct 22, 2016

It seems it's needed:

  1. When using audio sync on Linux and possibly windows
  2. When using audio sync and display sync on OSX because of kCGLPFADoubleBuffer removal which was required to stabilize display-sync playback on OSX 10.11 and up.

And not needed:

  1. When using display sync on Linux and possibly windows

So now with 202f695, there's code to only enable it when it's not using display-sync and it's not OSX and with e543853, there's code to only enable it when it's OSX regardless of sync method.

With these 2 commits the end result is the desired one, but I'm pretty sure the goal of both commits could be simplified so it's only defined in 1 location.

Unless it's simply better to leave everything as is and let dogs lie and all that.

@lachs0r lachs0r closed this Dec 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment