Fullscreen performance regression on OS X El Capitan

[franzf]

This is a regression I've noticed since upgrading from Yosemite. Drawing the OSD and progress bar are way too CPU intensive, to the point where mpv will skip frames. To illustrate it, I've recorded the screen of my old, weaker laptop:

While just playing a panning scene normally skips 2 frames, moving the mouse to trigger the OSD makes the CPU usage shoot up, where even mpv notices, skipping 98 frames. That's a worst case scenario on a Core 2 Duo, but the CPU usage is noticeable even on my newer machines.

mpv git-78caf6a, ffmpeg 2.8, OS X 10.11 15A284

[NiLuJe]

OpenGL performance seems to have taken a hit (at least some aspects of it), I've also had to tone down my config since moving to 10.11 (that's on a relatively recent MB Air).

I haven't noticed anything on the OSD end, but then I don't rely on it very much. On the contrary, CPU usage seems to be down a tiny bit, but unless I tone down my opengl settings (killing deband, for instance), I get skipped frames where I never did before.

[AirPort]

Regarding OpenGL general performances, yesterday in IRC we discovered that for some reason the --fs-black-out-screens option improve them drastically in fullscreen on 10.11, you can try it and see if it's useful in your case too.

[ghost]

Yes, pigoz was talking about something like a window server performance regression.

[pigoz]

Anyway I don't think its our bug :/

[NiLuJe]

At a (very) quick glance, fs-black-out-screens doesn't seem to help on my end (I'm not using any external screens, FWIW), the only thing it does is spawn an extra black mpv window that I can see in Mission Control. Speaking of Mission Control, strangely enough, the mpv thumbnail is completely smooth in there, during stuff that will skip like hell if I focus the window or go fullscreen. :?

[haasnhoff]

I've noticed the full-screen performance issue after upgrading to El Capitan, very annoying. It appears often if file operations are performed like copying a bigger file or using a VM in the background. My laptop has issues with it frequently. Reverting the config does obviously not fix it. Happens on both my desktop, and my laptop, so it's clearly not a device issue.

Unfocusing the mpv window does speed it up considerably when in full-screen. It's like the issue only happens if the window is in focus. Setting --quiet on helps, but doesn't fix it. Might as well also mention that I tried a very old build of mpv and it seemed to fix it too, but I can't confirm that 100%.

Seems like the --fs-black-out-screens option does fix the full-screen issue, though that is also annoying since I have three monitors connected and often have something I'm working on in one of the other monitors, but I guess that's a good temporary fix, especially on the laptop. I assume this is something on Apple's end since it isn't fixed yet, though only mpv has this problem as far as I know(?).

The full-screen thing might not related to the issue you are having however. Haven't noticed any noticeable skips on either of the rigs with the OSD, though when you do mention it I changed the msg-level to check and the dropped frames are indeed increasing whenever the OSD is showing.

[greentop]

Not sure if related, but recently on Ubuntu 14.04 64bit, I've been seeing the player shoot up to a consistent full CPU usage whenever I use vo=opengl-hq or vo=opengl in the config. Before, the player would rarely breach half the cpu usage in vo=opengl-hq on most 720p h264 video on the AMD Athlon II X4 640. If I switch to vo=vdpau (no hwdec=vdpau option), the CPU usage sees not much more than around 8%.

mpv-build: From https://github.com/FFmpeg/FFmpeg 2a4d1a6..624057d master -> origin/master eca7b0d..c149a4a release/2.8 -> origin/release/2.8

From https://github.com/mpv-player/mpv 78caf6a..bddd1e9 master -> origin/master

Playback test vo=opengl: Playing: /home/green/Videos/Video Shared/screen tearing test.mp4 (+) Video --vid=1 () (h264) (+) Audio --aid=1 --alang=und () (aac) libEGL warning: DRI2: failed to authenticate [vo/opengl] Suspected software renderer or indirect context. AO: [pulse] 44100Hz stereo 2ch float VO: [opengl] 1280x720 yuv420p AV: 00:00:12 / 00:00:30 (41%) A-V: 0.000 Dropped: 126

Playback test vo=vdpau: Playing: /home/green/Videos/Video Shared/screen tearing test.mp4 (+) Video --vid=1 () (h264) (+) Audio --aid=1 --alang=und () (aac) AO: [pulse] 44100Hz stereo 2ch float VO: [vdpau] 1280x720 yuv420p [vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate. (Paused) AV: 00:00:07 / 00:00:30 (23%) A-V: 0.000

[ghost]

There are several factors here:

• El Crapitan has some sort of performance regression that affects us, and which --fs-black-out-screens appears to work around
• vo_opengl_hq has become much slower due to the addition of debanding (enabled by default)
• vo_opengl may have become somewhat slower due to the removal of the single-pass optimization, which can be restored with --vo=opengl:dumb-mode=yes (but which also disables almost all other filtering)

The VO changes were both included in release 0.11.0 for the first time.

[pigoz]

The performance regression seems to only affect full screen mode though.

[NiLuJe]

FWIW, --fs-black-out-screens doesn't seem to help on my end (MB Air, no external screens).

Stupid question: What about resurrecting native-fs?

[pigoz]

We could look into resurrecting --native-fs and see if it helps with performance.

[greentop]

The vo=opengl:dumb-mode=yes brings the total cpu usage down to 54%, which is still way too high. That number (54%) is about where vo=opengl-hq when debanding was enabled by default last month would take my cpu up to (~50% cpu usage then).

[marlencrabapple]

Am I right to think --fs-black-out-screens won't help those of us without external monitors? I should probably mention other video players (namely VLC) aren't affected by the El Capitan performance regression. I'm assuming this is because VLC uses OS X's native full screen API. Is implementing this in mpv a reasonable solution?

Edit: --native-fs is probably what I'm thinking of. First time I saw it I just assumed 'fs' stood for file system. Time to adjust my caffeine intake I guess.

[pigoz]

We might look into implementing something like that. --fs-black-out-screens apparently helps regardless of the number of screens.

[FrostedMint]

Here’s what I’ve observed, mpv-0.11, 10.11.1, 1.1 GHz 12” MacBook (so, very slow hardware). Default full screen is slow. Full screen with --fs-black-out-screens works fine. If I hit the zoom button on the titlebar (i.e. native full screen) it’s fine.

My video output is set as vo=opengl:icc-profile-auto:blend-subtitles:interpolation:scale=spline36:cscale=spline36:dscale=mitchell:pbo

My full config.

[NiLuJe]

Sadly, --fs-black-out-screens still doesn't help on my end ;'(.

[sumyungguy]

In case it's not clear from FrostedMint's comment, despite --native-fs having been removed some time ago, you can already get native fullscreen in 10.11 without it being resurrected, by clicking the green button on the titlebar.

[chyiz]

On my end, both --fs-black-out-screens and native fullscreen doesn't help. This minimal vo is enough to cause framedrop: vo=opengl:scale=spline36:interpolation

[chyiz]

I made some more test. I set my vo back to a demanding one: opengl-hq:scale=ewa_lanczossharp:icc-profile-auto:interpolation, and also set framedrop=decoder. The video was choppy at first but after about 5 seconds it started to play smoothly. I can see the avsync dropped to 0 and there were no more frame drop.

I then tried framedrop=no, the video was a bit slow at first, but after few seconds it suddenly speed up for a second and then started to play smoothly. The avsync also dropped to 0 at the same time.

[ghost]

framedrop=decoder might just not work, but the default framedrop mode should not cause any issues.

[franzf]

I don't know if it's just an impression, but I think today's 10.11.4 beta (15E27e) improved the performance a lot. I'm not getting any frameskips on mouse movement with the same file as the original post at all. Can someone confirm I'm not going crazy? Would be way too convenient for Apple to fix everything at once in this release lol

[pigoz]

Would not be surprising because x.4 is generally the good release when stuff gets fixed.

[chyiz]

I'm on 10.11.4 beta now but I didn't notice any difference. I'm glad that your problem is fixed. I made some more test and I feel like I'm the one going crazy. I'm using this osd suggested by @FrostedMint to monitor my frame drop:

osd-msg2='VO: ${vo-drop-frame-count}\nDecoder: ${drop-frame-count}\nAV/Sync: ${avsync}'

Here is what I noticed:

On default framedrop=vo, framedrop starts as soon as I enter fullscreen. I can see avsync jumping back and forth, from around 0.005 to around 0.2xx and never settle down. vo frame drop count keep rising. I then use a keyboard shortcut to switch framedrop mode to framedrop=decoder, decoder frame drop count increases to about 100, but in the mean time avsync quickly drop to zero. After that, video plays smoothly. Now even if I cycle framedrop back to framedrop=vo, exit full screen and come back, I still won't experience any frame drop. However if I leave it at framedrop=vo, and make a seek action, like seek forward 5 seconds, all the frame drops come back.

The last interesting part is, when I'm trying to record my screen with Quicktime to show you guys how it behaves, the framedrop doesn't happen when the recording is on...

Here are my logs: mpv-log.txt mpv-stats.txt

[FrostedMint]

The frame drops have mysteriously stopped for me. A few days ago I did a brew upgrade, and rebuilt libass without harfbuzz (for #2585). I tried rebuilding libass with harfbuzz, but I can't get the frame drops to come back. So, maybe try a brew upgrade?

[chyiz]

ok, I came across #2567 and played with video-sync options today. Here are my observations:

• display-resample-vdrop doesn't seem to have any effect on framedrop. A/V Sync keeps fluctuating in fullscreen mode.
• display-resample-desync can actually play video smoothly in fullscreen mode! However, when entering fullscreen for the first time, or seek while in fullscreen, or exit fullscreen then seek then go back to fullscreen, video will stuck for a second and about 20 frames would be dropped. Seeking outside fullscreen or going in and out fullscreen without seeking were fine. Having Quicktime screen recording running also prevent this frame drop from happening.

I think I would keep this display-resample-desync option for now.

[chyiz]

I think yesterday's commits have resolved my issue. Just installed the latest master branch, and I'm able to use video-sync=display-resample together with default framedrop in fullscreen mode. kudos to @wm4 and @pigoz !

[ghost]

As far as I'm aware, there was no fix though. I doubt the commits yesterday actually changed anything about this issue.

[pigoz]

I think yesterday's commits have resolved my issue.

Are you sure? That's totally unintended.

[vmsp]

Using mpv git-0d3a67a (HEAD) installed with Homebrew.

A lot of frame drops using whatever config with mpv fullscreen. These framedrops stop if using native fullscreen. If I set video-sync=display-* frame drops return in both native and mpv fullscreen.

Everything runs absolutely perfect with any options, including video-sync=display-*, if I run mpv in a window.

Mid 2014 Macbook Pro, 2.2Ghz i7 with an integrated graphics card.

[anonova]

I recently upgraded OS X from 10.10 to 10.11 and am seeing this full screen performance issue as well. I tried homebrew's mpv package and building master from source with the same problem. I decided to try ChrisK's builds, and surprisingly, they work flawlessly using either the gui or cli. Any idea how these are built differently from homebrew?

[pigoz]

Hello, can someone test whether the native-fs branch helps?

[selsta]

@pigoz Seems to fix the issue.

[chyiz]

@pigoz Unfortunately native-fsdoesn't fix my issue. Sorry for not reporting back after my last comment. I was unable to triangulate any particular commits that fix this, and the framedrop did come back after a few days. However I find a weird workaround, that may help diagnose the real issue. It turns out, at least for me, it doesn't matter whether mpv is in fullscreen mode or not. As long as mpv window covers the whole screen, the framedrop starts. I tested with these scenarios:

• I disabled Displays have separate Spaces in order to hide the menu bar on the second monitor, and then resized the mpv window to cover the whole screen. I notice the framedrop started right away.
• I used another application to draw 1 pixel floating on top of all windows, then disable window-on-top in mpv. Framedrop stopped even in full screen, since mpv didn't cover the whole window.
• Using the native-fs branch, whenever I moved the mouse to the top of the screen, the menu bar shown and the framedrop stopped immediately.

[ghost]

I wonder if it's something else, like mpv accidentally creating a transparent window or something? (Even if we only write opaque data to it.)

[AirPort]

Due to an annoying hardware failure I had to change my machine with a 15'' retina MBP in the past month, so I decided to play around this mess of an issue with a more powerful GPU (two of them actually) and report my observations.

First of all I'm not able to reproduce anymore the fullscreen issue with "regular" mpv (audio video-sync mode), "solved" before using --fs-black-out-screens. Yet, I'm sure that the last time I experimented on the old computer (same Os X version, 10.11.4) it was still present, so maybe in this case it's more likely a matter of bigger graphic power than the evidence that this half of the issue is solved.

Regarding the display-resample sync mode, with mpv windowed the estimated Display FPS value tend to continuosly drift a little (values roughly between 59.900 and 60.100) but remains* really close to the specified one (59.990), and everything works fine. In fullscreen instead, the estimated value is almost never close to the specified one, drifting from 55-56 to even 35. Using native fullscreen doesn't help at all in this case, and I haven't noticed any significant difference between using the iGPU or the discrete one, nor between using --no-config and my (not too heavy) configuration, and finally not even playing around ontop combinations was useful.

If you need any more infos or tests I'll be glad to provide them.

*Once in my tests it took a big dip in windowed mode too, but as far as I saw it was an isolated incident. I'm reporting it nonetheless.

[pigoz]

I wonder if it's something else, like mpv accidentally creating a transparent window or something? (Even if we only write opaque data to it.)

Oh fuck, that might be the thing fucking with the compositor. I didn't recall we added that important feature.

[tewe]

I wonder if it's something else, like mpv accidentally creating a transparent window or something?

I can provoke frame drops by hitting the volume buttons in full screen, causing the OS to show the current level using transparency, blur and animation.

[pigoz]

Guys, sorry for the delay, I forgot to reply about this. Can you try to use vo=opengl:alpha=no?

[NiLuJe]

It doesn't seem to help on my end...

But then, my fresh ffmpeg/mpv rebuild seems to have broken VideoToolbox support right now (throwing the usual failed to init video toolbox decoder: Hardware doesn't support accelerated decoding for this stream or Videotoolbox decoder is not available at the moment (another application is using it). (-78)error, even on a fresh reboot), so, take that with a grain of salt until this is resolved.

[tewe]

Can you try to use vo=opengl:alpha=no?

Changes nothing on my end.

This includes Exposé showing a weird second window and this message. Related?

May 22 12:21:42  mpv[6273] <Error>: CGContextSetFillColorWithColor: invalid context 0x0. Backtrace:
  <-[NSNextStepFrame drawRect:]+94>
   <-[NSView _drawRect:clip:]+3626>
    <-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]+1873>
     <-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]+838>
      <-[NSNextStepFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]+284>
       <-[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]+2449>
        <-[NSView displayIfNeeded]+1950>
         <-[NSWindow _setFrameCommon:display:stashSize:]+3835>
          <-[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:]+222>
           <-[NSWindow setFrameOrigin:]+373>
            <-[NSWindow _fromScreenCommonCode:]+161>
             <-[NSWindow initWithContentRect:styleMask:backing:defer:screen:]+87>
              <-[NSView(NSFullScreenMode) enterFullScreenMode:withOptions:]+1681>
               <-[MpvEventsView setFullScreen:]+387>
                <vo_cocoa_fullscreen+93>
                 <__vo_cocoa_config_window_block_invoke+1200>
                  <_dispatch_client_callout+8>
                   <_dispatch_barrier_sync_f_slow_invoke+523>
                    <_dispatch_client_callout+8>
                     <_dispatch_main_queue_callback_4CF+1685>
                      <__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__+9>
                       <__CFRunLoopRun+1949>
                        <CFRunLoopRunSpecific+296>
                         <RunCurrentEventLoopInMode+235>
                          <ReceiveNextEventCommon+432>
                           <_BlockUntilNextEventMatchingListInModeWithFilter+71>
                            <_DPSNextEvent+1067>
                             <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454>
                              <-[NSApplication run]+682>
                               <cocoa_main+864>
                                <start+1>

[pigoz]

The above is a total blind try but it might help with multi display setups (hopefully).

[NiLuJe]

@tewe: That black second window is from the fs-black-out-screens option.

@pigoz: I'm not on a multi-display setup, but I'll give it a try anyway ;).

[pigoz]

Btw, can any of you test with Quartz Debug that the video is running at 60fps at all time with mpv --no-config --video-sync=display-resample?

[AirPort]

With mpv windowed the indicator in Quartz Debug is pretty much always fixed at 60, but going fullscreen makes it waver between 50 and 60 (it's not continuous: it mostly stays on 60, and every now and then it decreases for a bit).

[Akemi]

i tested this with git master (de4c74e5a4a996e8ff431c8f33a32c4b580be203) + native-fs commit from the native-fs branch. i played a 8 minute long 576p sample with constant 23.97fps. copied the relevant part of the mpv status line after playback was finished.

1: Single Monitor, windowed             DS: 2.470/27
2: Single Monitor, fullscreen           DS: 2.480/122 Dropped: 51

window is started on main display and moved to the secondary one in case 5 and 6.
3: Multi Monitor, Main, windowed        DS: 2.470/14
4: Multi Monitor, Main, fullscreen      DS: 2.470/123 Dropped: 41
5: Multi Monitor, Secondary, windowed   DS: 2.480/595 Dropped: 385
6: Multi Monitor, Secondary, fullscreen DS: 2.100/1160 Dropped: 403

starting mpv on the secondary display switches the situation around, now it works better on the secondary display. moving the window from the secondary to the primary display and playing the video there causes massive frame drops like in case 5 and 6. switching primary and secondary display in the system preferences doesn't change anything, just that the situation is now switched around like expected.

so depending on which display mpv is started, it works better there. seems like moving the window to a different display causes problems and the refresh rate is not reported correctly. maybe still uses the original display instead of the new one?

another observation; starting mpv on the primary display, moving it off the edge of the screen area by a few pixels towards the secondary screen also causes massive frame drops and mistimings. this doesn't happen with only one monitor.

[Akemi]

i updated to 10.12 (sierra) beta to test everything again. same as above git master (a30e7272669478ca1a04469c0ab3614b0e99dd98) + native-fs.

1: Single Monitor, windowed                 DS: 2.470/3
2: Single Monitor, fullscreen               DS: 2.500/15 Dropped: 3

3: Multi Monitor, Main, windowed            DS: 2.470/1
4: Multi Monitor, Main, fullscreen          DS: 2.470/26 Dropped: 6
5: Multi Monitor, Secondary, windowed       DS: 2.060/670 Dropped: 433
6: Multi Monitor, Secondary, fullscreen     DS: 2.470/1044 Dropped: 360

since the multi monitor problem seems like something entirely unrelated i leave it out for now. above is just for reference with previous comment.

just git master

windowed                                    DS: 2.470/3
fullscreen                                  DS: 2.190/2570 Dropped: 1484

lockfocus branch

windowed                                    DS: 2.480/2
fullscreen                                  DS: 2.070/2554 Dropped: 1535

lockfocus branch + native-fs

windowed                                    DS: 2.480/0
fullscreen                                  DS: 2.470/19 Dropped: 3

seems like the situation has improved quite a bit, though it's still not perfect yet like on 10.10.

[Akemi]

i was testing some more things and could drastically improve the current fullscreen with a little workaround. just adding or removing 1px from either direction makes fullscreen perform nearly as good as the native fullscreen. the patch to test it.

master + patch
fullscreen                                   DS: 2.470/85 Dropped: 15

lockfocus branch + patch
fullscreen                                   DS: 2.470/84 Dropped: 15

a local test branch without native-fs
fullscreen                                   DS: 2.470/91 Dropped: 11

it doesn't perform as well as the native-fs but a lot better than before. also it isn't really nice to do that and is quite a bit of hackery.

[excelwang]

This issue has disappeared since my MacBook Pro upgraded to macOS 11.2 public beta 6

[pigoz]

Can anyone test whether removing the glFlush call improves this? I made a branch here: https://github.com/mpv-player/mpv/tree/no-flush

Someone suggested on IRC this might be the issue.

[Akemi]

this is on sierra beta 8, same sample as above with mpv --no-config --video-sync=display-resample

master                                          DS: 2.470/59 Dropped: 18
no-flush branch                                 DS: 2.470/41 Dropped: 15
master + native-fs                              DS: 2.480/18 Dropped: 4

native-fs still performs the best. though it seems that they also partially fixed the behaviour for our normal fs. i will try GM or the release when i get my hands on either.