macOS: libmpv cannot get a VO.

[j77h]

It seems to boil down to this: either the libmpv dylib or the python wrapper cannot establish a VO on macOS, although mpv-player can.

The fact that mpv-player can do it suggests that a solution to libmpv's problem can't be far away.

Both with and without a Qt window, libmpv hangs at "vo/gpu/opengl Initializing GPU context 'cocoa'", but mpv-player seems to use osx/cocoacb and vo/libmpv.

Setting 'gpu' or 'libmpv' or 'cocoacb' as the vo does not help.

The uploaded zip contains full debug logs. j77h_macos_no_vo.zip

Although my 'mac' is a VBox VM on Linux, I've ruled out that being in a VM is the cause, by showing that mpv-player works in the same VM, and libmpv works in Windows in a VM. Both the macOS VM and the Windows VM use the VBoxSVGA device.

Creating a GUI window first does not seem to help now. My PySide6_libmpv_test.py on Linux clearly opens a window first then inserts the player into it, but on macOS the window never appears. (My PySide6 tests without libmpv work fine on macOS.)

Vydia's code does not work with current Python or libmpv. Robozman's code is too complex for me -- don't need it and don't understand it. :)

Note: I don't use Mac and don't know it well; all I have is the VM, just for testing my code. Also, I'm not a great coder, I know only a bit of Python...

[jaseg]

The python wrapper has no part in VO initialization except for passing whatever VO options you give it through to libmpv, so either you have to change your VO options, or the problem is with libmpv. When comparing mpv and libmpv, did you make sure that both are the same mpv version? mpv tells you when you call it with the --version argument, and you can ask libmpv by running import mpv; player = mpv.MPV(); print(player.mpv_version).

[j77h]

change your VO options

Tried everything I could think of; problem seemed to be getting the right "context" (whatever that is).

mpv and libmpv ... both are the same mpv version?

Both 0.35.1

I relocated and used IINA's dylibs, but got the same error. Interesting, because IINA uses only libmpv, and it works. I'll try to find out what IINA passes to the libmpv dylib.

[edited to remove many surplus words]

[j77h]

TL;DR At the end of mpv.py there is class MpvRenderContext. Should I be doing something with it in my own code?

---

In iina-develop/iina/MPVController.swift in func mpvInit() at line 394 : chkErr(mpv_set_property_string(mpv, MPVOption.Video.vo, "libmpv"))

So IINA uses vo="libmpv", but when I tried that, it got "No render context set": fatal vo/libmpv No render context set. Error opening/initializing the selected video_out (--vo) device.

IINA has func mpvInitRendering(), which seems to be about "OpenGL context".

At the end of mpv.py there is class MpvRenderContext and I can't see that it's instantiated or used anywhere. Should I be doing something with it in my own code? Maybe set OpenGL render context to 'cocoacb'. I have no idea how to do that.

[jaseg]

libmpv by default just creates its own window, where it draws the video. AFAIK most people use it like this, because it's also how the command-line player behaves.

If you want to integrate libmpv into an application that already has a window, you can instead create your own window and openGL context, and hand it to libmpv. That's what that render context stuff is for. To just display video in a new window, you don't need it.

[j77h]

create your own window and openGL context, and hand it to libmpv

I'll try creating an openGL context for it, and report back.

In the meantime, a bit more background:

I'm writing an app on Linux/x11, where using your libmpv wrapper works fine, whether in a window or not; I don't have to give it a vo context either way.

On macOS the opposite is true: your libmpv wrapper does not work, whether in a window or not; but as yet I haven't given it a vo context (will try it asap).

I put it in a window because it's mentioned in #36 (from 2017) (https://github.com/jaseg/python-mpv/issues/36#issuecomment-346938221). But that code snippet doesn't provide a vo context, and doesn't seem to work on macOS now.

[jaseg]

I just realized you were talking about vo='libmpv'. This is yet another different thing, separate from the OpenGL VO. vo='libmpv' tells libmpv that you want to do the rendering all by yourself. The render context object in that instance contains a bunch of callbacks that libmpv calls whenever a frame is ready. This is probably not what you want.

If your code works on Linux but not on MacOS, I am fairly sure that that's an issue either inside libmpv or inside your installation of libmpv, so it may be worth your time asking at the upstream mpv project for advice.

[olivierfriard]

Hi @j77h I have exactly the same problem with my program (www.boris.unito.it). Everything works well on Linux and Windows (PyQt5) but not on MacOS (physical machine not a VM) I tried with the relocated libmpv from IINA without success

[j77h]

@olivierfriard I haven't had time to work on this, so haven't yet mentioned it upstream. The mpv people might have very little knowledge of macOS, so I thought asking the IINA people as well might be worthwhile. (But IINA is done in Swift, and their methods might not translate to Python/Qt.) I know very little about video rendering - don't even know what a "vo" is really.

[j77h]

@olivierfriard

There's a new active thread about this at https://github.com/mpv-player/mpv/issues/12518

[olivierfriard]

Hello, any news about this issue? Thanks

[j77h]

Well, that mpv issue was closed, they think they've fixed it.

But that happened a few days after the last mpv release. Homebrew makes 'bottles' (binaries) only from releases, mpv releases are usually many months apart, and I don't want to compile it from source.

mpv compiling requires meson, and meson compiling requires the full Xcode, a huge download, ~7GB in 2022, but might be less now.

My 'customers' are non-techie mac users, who won't be able to install it until brew makes a new bottle.

Been too busy with other things, my mac vm does not boot now, so haven't checked status at homebrew.