macOS: vo gpu and gpu-next fail to play video smoothly

[torque]

Important Information

mpv version:

mpv v0.37.0-707-g92cb47338f Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Mar 29 2024 18:12:36
libplacebo version: v7.349.0 (v6.338.0-120-g7b294350)
FFmpeg version: N-114518-ge99c273fec
FFmpeg library versions:
   libavutil       59.10.100
   libavcodec      61.4.100
   libavformat     61.2.100
   libswscale      8.2.100
   libavfilter     10.2.100
   libswresample   5.2.100

macOS version:

MacBook Pro M2 Max 16-inch, 2023
macOS: Sonoma 14.4.1

Reproduction steps

Play a video that is more than a couple of minutes long.

Expected behavior

The video plays back smoothly.

Actual Behavior

I recently updated my local build of mpv which crossed the commit boundary from when vo=libmpv was the default to when vo=gpu became the default on macOS (i.e. 0e441525cfc2c0d56b6d4a5fc67016d7e29d1b2c as best I can tell). I immediately started noticing non-smooth playback of videos that had previously played back smoothly. This happens with --no-config, though in the included data I have osc=no, vo=gpu-next, and video-sync=display-resample (which apparently adds vsync information to the information display). I am also running this with the environment variable MTL_HUD_ENABLED=1 for additional info in the screenshots. The issue appears to happen regardless of whether or not mpv is in full screen but maybe happens slightly faster in full screen?

This is most obvious when watching 60fps videos at 2x speed. What appears to be happening is that a minute or so after playback begins, the display refresh rate starts dropping, which causes vsyncs to start getting missed, resulting in frames getting dropped on output like crazy and massive stuttering. Note that on videos without audio, rather than stuttering, the playback simply slows down. I've attached a generated 60fps video with a smoothly scrolling sine wave that demonstrates this problem for me. I've seen this behavior on both the laptop's built-in screen (which uses Apple® ProMotion® Technology™) as well as on external monitors. I have not tried with the built-in display turned off.

I do not build the macOS bundle locally, so mpv is not loading a plist, but I was able to reproduce this issue with one of the recent CI builds, so I guess that shouldn't matter.

vo=libmpv does not have any of the fancy diagnostic information, but it also does not have this stuttering problem at all.

Log file

mpv.log.txt

Here's also a screenshot of the metal debug info

Sample files

The aforementioned smooth scrolling video (has silent audio for maximum stutter action) smootha.mp4

[hooke007]

remove it video-sync=display-resample

[Akemi]

since he already tried with --no-config and only the included data is with --video-sync=display-resample, that is most definitely not the problem.

[torque]

Yeah. I think the behavior is maybe a little less noticeable on my sample video without --video-sync=display-resample but it is still there. While I see stuttering on the sample video I attached, it seems to be much less pronounced than, for example, streaming VODs from twitch or youtube. All of the network streams I've tried with the default settings exhibit this behavior for me, so I'd assume it'll be easy to reproduce once the factors causing it have been determined.

An additional data point, which I don't know if it even matters (but I expect is outside of normal usage on mac) is that I essentially exclusively launch mpv from the terminal. I wouldn't expect this to make a difference, but I haven't tested trying to launch it as a standard application bundle.

[Akemi]

i couldn't look into it much yet, though it seems like you are using a vulkan sdk from december 2022 ([ 0.030][d][vo/gpu-next/libplacebo] Available instance version: 1.3.236). could you try using at least 1.3.275 from january this year (it's the version i am testing with atm)?

if you can still reproduce the problem with a newer SDK it would be nice to get another log with the new version.

[edit] you can also try --vd-lavc-dr=no. also trying some combinations of --vulkan-swap-mode=immediate, --vulkan-queue-count=, --vulkan-async-transfer=no and --vulkan-async-compute=no.

[torque]

Good catch. I thought I was keeping vulkan up-to-date, but it appears I had failed to notice an old version clunking around from some fiddling a while ago. I updated to 1.3.280 and the problem appears to have essentially gone away. The diagnostics show a dropped frame every once in a while (unlike the thousands before) but this is not really noticeable while watching. This does make me wonder why I was seeing the same behavior with one of the builds from CI, but I think I'm okay with leaving that as a mystery for now.

Thanks for the help.

[Akemi]

might be some weird priority how the vulkan loaders are/were loaded or some problem with the bundle creation.

but great that we could fix your problem.

[Akemi]

according to https://vulkan.lunarg.com/doc/view/1.3.216.0/mac/loader_and_layer_interface.html#user-content-macos-layer-discovery search priority should be like this and the bundle path should always be the first priority.

  <bundle>/Contents/Resources/vulkan/implicit_layer.d
  /Users/Me/.config/vulkan/implicit_layer.d
  /etc/xdg/vulkan/implicit_layer.d
  /usr/local/etc/vulkan/implicit_layer.d
  /etc/vulkan/implicit_layer.d
  /Users/Me/.local/share/vulkan/implicit_layer.d
  /usr/local/share/vulkan/implicit_layer.d
  /usr/share/vulkan/implicit_layer.d

i fixed the bundling of the vulkan driver and layers in a later commit, maybe the bundle was a build prior to that fix. otherwise no idea what could have happened.