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

Argon- · 2016-10-27T16:35:14Z

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.

The text was updated successfully, but these errors were encountered:

ghost · 2016-10-27T16:37:30Z

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

Not useable.

Argon- · 2016-10-27T16:40:47Z

I don't get it, what?

Argon- · 2016-10-27T18:56:36Z

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

ghost · 2016-10-27T19:00:36Z

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 · 2016-10-27T19:06:58Z

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 · 2016-10-28T01:19:47Z

--no-config

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

Argon- · 2016-10-28T08:46:43Z

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

Hrxn · 2016-10-28T19:20:23Z

Okay, wasn't aware of that.

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

Argon- · 2016-10-28T19:34:47Z

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

Hrxn · 2016-10-28T19:43:24Z

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

Argon- · 2016-10-28T20:07:51Z

--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 · 2016-10-28T22:43:22Z

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

Argon- · 2016-11-28T11:38:22Z

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 · 2016-11-28T15:09:43Z

--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 · 2016-11-28T15:36:22Z

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

tmkk · 2017-03-04T13:37:18Z

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 · 2017-03-04T14:44:17Z

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 · 2017-03-04T14:46:47Z

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

Akemi · 2017-03-04T15:00:36Z

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 · 2017-03-04T15:05:59Z

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 · 2017-04-03T19:30:01Z

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 · 2017-04-03T20:11:44Z

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

Akemi · 2017-05-04T14:03:10Z

thx for testing.

pxia · 2017-09-13T02:18:50Z

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 · 2017-09-13T02:49:52Z

Both can do both..

Akemi · 2017-09-13T09:26:20Z

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

Argon- · 2017-09-13T10:18:57Z

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 · 2017-09-13T10:22:34Z

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).

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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

@pigoz

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 · 2018-02-12T12:54:41Z

fixed via c5e4538.

Argon- mentioned this issue Nov 28, 2016

Frame drops on 0.22 with 24hz output #3837

Closed

Akemi mentioned this issue Feb 4, 2017

Frame drops on high bitrate parts #4080

Closed

Akemi added the os:mac label Feb 4, 2017

Akemi mentioned this issue Mar 3, 2017

Choppy 60fps video playback with --video-sync=audio on macOS #4201

Closed

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

Akemi mentioned this issue Mar 13, 2017

Fullscreen performance regression on OS X El Capitan #2392

Closed

Akemi mentioned this issue Apr 2, 2017

(Mac) full screen jerky; windowed mode smooth #4295

Closed

Akemi mentioned this issue Apr 30, 2017

cocoa: layer backed view #4391

Closed

Akemi mentioned this issue Jun 2, 2017

Mpv renders video at 2x container's frame rate #4476

Closed

Akemi mentioned this issue Sep 4, 2017

macOS opengl-cb backend #4833

Merged

Akemi mentioned this issue Sep 16, 2017

60 fps playback frame drops #4877

Closed

Akemi closed this as completed Feb 12, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Argon- commented Oct 27, 2016 •

edited

Loading

ghost commented Oct 27, 2016

Argon- commented Oct 27, 2016

Argon- commented Oct 27, 2016

ghost commented Oct 27, 2016

AirPort commented Oct 27, 2016

Hrxn commented Oct 28, 2016

Argon- commented Oct 28, 2016 •

edited

Loading

Hrxn commented Oct 28, 2016

Argon- commented Oct 28, 2016 •

edited

Loading

Hrxn commented Oct 28, 2016

Argon- commented Oct 28, 2016 •

edited

Loading

Akemi commented Oct 28, 2016

Argon- commented Nov 28, 2016 •

edited

Loading

Hamuko commented Nov 28, 2016

ghost commented Nov 28, 2016

tmkk commented Mar 4, 2017

tmkk commented Mar 4, 2017

Akemi commented Mar 4, 2017

Akemi commented Mar 4, 2017

ghost commented Mar 4, 2017

ballo commented Apr 3, 2017

Akemi commented Apr 3, 2017

Akemi commented May 4, 2017

pxia commented Sep 13, 2017

Hrxn commented Sep 13, 2017

Akemi commented Sep 13, 2017 •

edited

Loading

Argon- commented Sep 13, 2017

Akemi commented Sep 13, 2017

Akemi commented Feb 12, 2018

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

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

Comments

Argon- commented Oct 27, 2016 • edited Loading

mpv version and platform

Reproduction steps

Expected behavior

Actual behavior

Log file

Sample files

ghost commented Oct 27, 2016

Argon- commented Oct 27, 2016

Argon- commented Oct 27, 2016

ghost commented Oct 27, 2016

AirPort commented Oct 27, 2016

Hrxn commented Oct 28, 2016

Argon- commented Oct 28, 2016 • edited Loading

Hrxn commented Oct 28, 2016

Argon- commented Oct 28, 2016 • edited Loading

Hrxn commented Oct 28, 2016

Argon- commented Oct 28, 2016 • edited Loading

Akemi commented Oct 28, 2016

Argon- commented Nov 28, 2016 • edited Loading

Hamuko commented Nov 28, 2016

ghost commented Nov 28, 2016

tmkk commented Mar 4, 2017

tmkk commented Mar 4, 2017

Akemi commented Mar 4, 2017

Akemi commented Mar 4, 2017

ghost commented Mar 4, 2017

ballo commented Apr 3, 2017

Akemi commented Apr 3, 2017

Akemi commented May 4, 2017

pxia commented Sep 13, 2017

Hrxn commented Sep 13, 2017

Akemi commented Sep 13, 2017 • edited Loading

Argon- commented Sep 13, 2017

Akemi commented Sep 13, 2017

Akemi commented Feb 12, 2018

Argon- commented Oct 27, 2016 •

edited

Loading

Argon- commented Oct 28, 2016 •

edited

Loading

Argon- commented Oct 28, 2016 •

edited

Loading

Argon- commented Oct 28, 2016 •

edited

Loading

Argon- commented Nov 28, 2016 •

edited

Loading

Akemi commented Sep 13, 2017 •

edited

Loading