slow opening video with `vo=libmpv` on intel chips mac

[eko5624]

mpv Information

mpv v0.38.0-539-g1225bcbd41 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
  built on Jun 24 2024 07:02:29
libplacebo version: v7.349.0 (v7.349.0-rc1-3-g1fd3c7bd)
FFmpeg version: git-2024-06-23-0b67c83
FFmpeg library versions:
    libavcodec      61.8.100
    libavdevice     61.2.100
    libavfilter     10.2.102
    libavformat     61.3.104
    libavutil       59.25.100
    libswresample   5.2.100
    libswscale      8.2.100

Other Information

• device: macbook pro 2017
• macOS version: 13.6.7 (22G720)
• Source of mpv:
• Introduced in version: unknown

Reproduction Steps

On intel chips mac, default vo=gpu seems poor performance because of using macvk , so I use vo=libmpv to reduce performance consumption. But when using vo=libmpv, loading OSC needs longer time.

Expected Behavior

OSC loading less time

Actual Behavior

OSC loading needs longer time

Log File

mpv.log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• [X] I tested with the latest mpv version to validate that the issue is not already fixed.
• [X] I provided all required information including system and mpv version.
• [x] I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• [X] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• [X] I attached the full, untruncated log file.
• [X] I attached the backtrace in the case of a crash.

[Akemi]

please be more specific what you mean with slow OSC loading. is it just the time between opening a file and when the window appears? try with --no-config like the issue template asked you to do. try with --vo=gpu-next. provide a log of a run with "fast OSC loading" (with --vo=gpu(-next)). try older versions of mpv and see if it behaves the same way.

[eko5624]

It's just the time between opening a file and the video start to play. Double clicks the video file, the video start to play immediately when using vo=gpu-next, but not when using vo=libmpv Here's the log when trying vo=gpu-next.

mpv.log

[llyyr]

You were asked to provide a log file with --no-config, neither that nor the log in the OP are with --no-config. Nobody has the time to shift through logs about thumbfast or you setting 20 options to their default values to find the relevant line.

Although with a rough look, it seems related to videotoolbox initialization rather than vo init.

[eko5624]

Here comes the logs with --no-config. Any help would be great, thanks.

mpv-with-libmpv.log mpv-with-gpu-next.log

[Akemi]

so yeah this has nothing todo with OSC being slow. the title is very misleading.

from your no-config logs both seems quite similar in startup time and libmpv catches up a bit at the end.

gpu-next

[   0.664][v][cplayer] first video frame after restart shown
...
[   0.688][d][cplayer] starting video playback

libmpv (faster by ~0.2s)

[   0.465][v][cplayer] first video frame after restart shown
...
[   0.466][d][cplayer] starting video playback

in your initial run without --no-config a significant amount of time is being wasted in initialising videotoolbox libmpv. though the whole things in general is a bit slower and adding up.

[   0.740][v][vd] Requesting pixfmt 'videotoolbox_vld' from decoder.
[   1.976][d][ffmpeg/video] h264: Reinit context to 1920x960, pix_fmt: videotoolbox_vld

gpu-next (which is ffmpeg and we can't do too much about it)

[   0.262][v][vd] Requesting pixfmt 'videotoolbox_vld' from decoder.
[   0.396][d][ffmpeg/video] h264: Reinit context to 1920x960, pix_fmt: videotoolbox_vld

since your no-config run seems perfectly normal. something in your config or the various scripts you use are just bottlenecking the startup.

also like i suggested try some older versions of mpv and see if they exhebit the same problem.

[eko5624]

I did some research, the problem appeared since https://github.com/mpv-player/mpv/commit/8a61929eb8e62097cf8ef0764dba233000fd1e5f , https://github.com/mpv-player/mpv/commit/cb75ecf19f28cfa00ecd348da13bca2550e85963 no problem.

mpv-8a61929-libmpv.log mpv-cb75ecf-libmpv.log

[eko5624]

I did some tests, remove https://github.com/mpv-player/mpv/commit/8a61929eb8e62097cf8ef0764dba233000fd1e5f , the problem is gone.

[Akemi]

do you have the same problem with the changes from https://github.com/mpv-player/mpv/pull/15087?

[eko5624]

https://github.com/mpv-player/mpv/actions/runs/11326777006/artifacts/2052868292

Good job. This build fix the issue now.

[Akemi]

i pushed another fix to the same branch/PR to narrow it down a bit more. could you please test again when the new build is done? it should update the links in the same comment.

for now it's not really a fix, just trying to narrow down which flag makes the initialising slow. if my assumptions is correct, we need a bit more code changes. though the underlying problem needs to be fixed in ffmpeg or videotoolbox itself.

[eko5624]

This build also works. https://github.com/mpv-player/mpv/actions/runs/11327239651/artifacts/2053006598

[Akemi]

okay, thank you for testing. i am going to try to fix this issue on our side as much as possible.

[Akemi]

updated the PR with hopefully a proper fix. would be nice if you could test it again.

[eko5624]

Yes, this build works fine. https://github.com/mpv-player/mpv/actions/runs/11329918761/artifacts/2053735163