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

Choppy playback/framedrops with videos with fps close to the display refresh rate #3739

Closed
Argon- opened this issue Oct 27, 2016 · 36 comments
Closed
Labels

Comments

@Argon-
Copy link
Member

Argon- commented Oct 27, 2016

mpv version and platform

OSX 10.11

mpv git-90b968a (C) 2000-2016 mpv/MPlayer/mplayer2 projects
 built on Wed Oct 26 23:25:12 CEST 2016
ffmpeg library versions:
   libavutil       55.28.100
   libavcodec      57.48.101
   libavformat     57.41.100
   libswscale      4.1.100
   libavfilter     6.47.100
   libswresample   2.1.100
ffmpeg version: 3.1.5

Reproduction steps

Watch a video as specified below.

Expected behavior

Proper video playback, no dropped frames.

Actual behavior

Choppy video playback, lots of dropped frames. Using hwdec (successfully) does not help. Using --no-audio does not help.

Log file

http://sprunge.us/jbBQ

Sample files

5 seconds, 7 MB: https://0x0.st/eJP.mp4

More info:
I made a recording from a h264 720p (p as in progressive) channel with a DVB-C USB stick and its bundled software. The recording is a MPEG-TS file and the recorder software offers me, among others, remuxes to .mp4. Such a remux as well as the MPEG-TS file have a framerate of 50 and a bitrate around 13Mbit/s. While the recorder software itself as well as Quicktime play these files fine, mpv drops frames like crazy no matter the quality settings I use. The frame timings are low (enough) and yet I drop around 20 frames per second (even with --no-config).

I just randomly downloaded a TV show from a related broadcasting channel (through the channel's online offering) with similar encoding aspects: 50 FPS, h264 (created using x264), 720p and it has the same problem (Quicktime plays it just fine). This should rule out a messed up encode/remux by my software, as this file was produced by the channel's staff.

@ghost
Copy link

ghost commented Oct 27, 2016

[lavf] Edit lists are not correctly supported (FFmpeg issue).

Not useable.

@Argon-
Copy link
Member Author

Argon- commented Oct 27, 2016

I don't get it, what?

@Argon-
Copy link
Member Author

Argon- commented Oct 27, 2016

In case you wanted to say it's a ffmpeg bug: just downloaded VLC and it plays these files just fine as well.

@ghost
Copy link

ghost commented Oct 27, 2016

These files have edit list elements, which is not really supported.

Anyway, that's probably not the problem here, since the file played without any frame drops for me.

@AirPort
Copy link

AirPort commented Oct 27, 2016

I tested it and I can confirm that the sample drops a lot of frame even on macOS 10.12, with both intel iGPU and AMD dGPU, no matter the vo settings.

@Hrxn
Copy link
Contributor

Hrxn commented Oct 28, 2016

--no-config

Did you try it not just without any config settings, but without any scripts whatsoever?

@Argon-
Copy link
Member Author

Argon- commented Oct 28, 2016

Scripts are not auto loaded with --no-config.

@Hrxn
Copy link
Contributor

Hrxn commented Oct 28, 2016

Okay, wasn't aware of that.

Just trying to eliminate all possible causes...
Does the same issue occur with ffplay?

@Argon-
Copy link
Member Author

Argon- commented Oct 28, 2016

No, it's fluent with ffplay. It's fluent with everything I've tested so far.

@Hrxn
Copy link
Contributor

Hrxn commented Oct 28, 2016

Maybe related to the latest changes made to cocoa_common.m? Don't have a better idea yet..

@Argon-
Copy link
Member Author

Argon- commented Oct 28, 2016

--opengl-early-flush=no indeed fixes the stuttering/frame drops. I'm a bit confused as the manual states this would be default, I assume it isn't on OSX.
Considering I was not the only OSX user who could reproduce this, using videos of different codecs (all generally having higher FPS), I'd say this is not a very sensible default? As previously said, no other tested video player has this problem.

Edit: Maybe useful to ping @Akemi

@Akemi
Copy link
Member

Akemi commented Oct 28, 2016

@wm4 changed the default to auto for --opengl-early-flush. i am not quite sure what it does.

@Argon-
Copy link
Member Author

Argon- commented Nov 28, 2016

From commit message:

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

Well, at least for two a few users it's not.
Wondering if we are the only ones or if others just didn't notice it (yet)?

@Hamuko
Copy link

Hamuko commented Nov 28, 2016

--opengl-early-flush=auto results in lots of dropped frames on my old early-2011 MacBook Pro running Sierra when I play almost any video in full screen. It also results in some dropped frames on my newer and more powerful Hackintosh depending on the video type. I remember it happening on some 720p HEVC video I watched not too long ago and on 60 FPS YouTube videos.

--opengl-early-flush=no fixed the issues on my Hackintosh, where both the HEVC video and 60 FPS YouTube video both started playing smoothly with the option. And from what little I have tested with my laptop thus far (I only noticed to turn it off today), I no longer drop frames in full screen. After 44 minutes of 720p playback, I dropped exactly one frame, which most likely resulted from going to full screen mode. Previously, I would have dropped thousands if not tens of thousands of frames.

@ghost
Copy link

ghost commented Nov 28, 2016

With the current OSX code, mpv can't really know if there were any dropped frames.

@Akemi Akemi added the os:mac label Feb 4, 2017
@Akemi Akemi changed the title Choppy playback/framedrops with certain videos Choppy playback/framedrops with videos with fps close to the display refresh rate Mar 3, 2017
@tmkk
Copy link

tmkk commented Mar 4, 2017

As far as I've tested, on OSX calling glFlush() in gl_video_render_frame when --opengl-swapinterval is set to 1 (vsync enabled, default) causes a stuttering.

@tmkk
Copy link

tmkk commented Mar 4, 2017

And this change seems to solve the issue - enable double buffering and call CGLFlushDrawable() instead of glFlush() on cocoa_swap_buffers:

--- video/out/opengl/context_cocoa.c.orig	2017-03-04 23:23:58.000000000 +0900
+++ video/out/opengl/context_cocoa.c	2017-03-04 23:34:40.000000000 +0900
@@ -55,6 +55,7 @@ static CGLError test_gl_version(struct v
         kCGLPFAOpenGLProfile,
         (CGLPixelFormatAttribute) version,
         kCGLPFAAccelerated,
+        kCGLPFADoubleBuffer,
         #if MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_8
         // leave this as the last entry of the array to not break the fallback
         // code
@@ -153,7 +154,8 @@ static int cocoa_control(struct MPGLCont
 static void cocoa_swap_buffers(struct MPGLContext *ctx)
 {
     vo_cocoa_swap_buffers(ctx->vo);
-    ctx->gl->Flush();
+    struct cgl_context *p = ctx->priv;
+    CGLFlushDrawable(p->ctx);
 }
 
 const struct mpgl_driver mpgl_driver_cocoa = {

@Akemi
Copy link
Member

Akemi commented Mar 4, 2017

we are aware and already established that. we can't add doublebuffering back at the moment, see #2392.

@Akemi
Copy link
Member

Akemi commented Mar 4, 2017

just for historical reason:
9f30cd8 'fixed' the fullscreen problems and #3364
6789f9b first time the cocoa backend broke because of the missing flush
e543853 fix for it, since CGLFlushDrawable or the NSOpenGLContext one won't to anything without double buffering
202f695 commit that causes the current problem

the only 'real' fix for the current state, is to disable the early flush completely on macOS.

@ghost
Copy link

ghost commented Mar 4, 2017

I suggest setting gl->Flush to a function that does nothing. This way there wouldn't be a need for yet another mechanism and special case when to call Flush in the generic code. Of course the cocoa backend would still have to call the real glFlush.

@ballo
Copy link

ballo commented Apr 3, 2017

flush doesn't do crap for me, however switch to the discrete graphics on my 2011 MacBook 17 solved the problem (albeit while taking a hit on playtime since I'm using more power).

To do this, use a free app called gfxCardStatus:

https://gfx.io

@Akemi
Copy link
Member

Akemi commented Apr 3, 2017

then it's an unrelated problem and there is no need to post it on this issue.

@Akemi
Copy link
Member

Akemi commented May 4, 2017

thx for testing.

@pxia
Copy link

pxia commented Sep 13, 2017

Is there any downside of using --opengl-early-flush=no for all videos on MacOS? The man page says this option

Can fix stuttering in some cases, in other cases probably causes it.

I wonder if it's platform-specifc.

(Also I'm not sure wether it means "the option being on" can fix stuttering in some cases, or "being off".)

@Hrxn
Copy link
Contributor

Hrxn commented Sep 13, 2017

Both can do both..

@Akemi
Copy link
Member

Akemi commented Sep 13, 2017

out of my experience early flush left activated causes only problems, deactivating doesn't. on macOS that is.

@Argon-
Copy link
Member Author

Argon- commented Sep 13, 2017

Yeah same. I have it set to no since this issue and never noticed any downsides.

I'm wondering if this issue should be closed as the cause/a fix is known? However, it's something users (still) have to do on their own and the default case for OSX is still the stutters-when-high-fps-case, or am I mistaken?

@Akemi
Copy link
Member

Akemi commented Sep 13, 2017

it kinda depends on how well #4833 will work, though @AirPort said it still causes some problems with it. so i plan to deactivate early flush for macOS completely (see the TODO list on that PR).

Akemi added a commit to Akemi/mpv that referenced this issue Dec 11, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 11, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 28, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 28, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 28, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 14, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 14, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 20, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 20, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 30, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 30, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
an it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217

cocoa-cb: initial implementation via opengl-cb API
Akemi added a commit to Akemi/mpv that referenced this issue Jan 31, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 31, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 3, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 7, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can't
be properly worked around. there are also certain regressions on newer
macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 12, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 12, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 12, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
kevmitch pushed a commit that referenced this issue Feb 12, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.

- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations

all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.

this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.

this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.

some credit goes to @pigoz for the initial swift build support which
i could improve upon.

Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739,
#2392, #2217
@Akemi
Copy link
Member

Akemi commented Feb 12, 2018

fixed via c5e4538.

@Akemi Akemi closed this as completed Feb 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants