Simple example on macOS

[mpv-player]

Simple example on macOS

[Akemi]

thank for letting me know about the Main Tread Checker. i could fix a few more issues because of that.

i will close this issue since everything concerning the issue should be fine now or cleared up now.

[pixlwave]

Super, thanks for all your help, and keep up the great work on the macOS side of mpv. It’s the only third party player I would ever install on the Mac 👍🏻

I guess this is probably broken on OSX in random ways with thew "simple" example program. OSX is different from windows and linux because cocoa needs to be used from the "main thread", and that thread really must be the thread entered in main(). libmpv creates a separate thread, so it can't initialize cocoa.

This causes a lot of problems in mpv CLI too (breaking abstractions that are working well on windows and linux), and I guess nobody thought about the libmpv case.

You might have more luck if you initialize cocoa in main(), enter its runloop, and then try to play a file with libmpv, but I have no idea if it works. In ancient times, embedding with cocoa and --wid sort of worked, but this is probably broken with mpv's swift backend. The libmpv/cocoa/cocoabasic.m backend uses this.

On the other hand, examples that use the "render API" are almost guaranteed to work (like the qml_direct or ios examples), but it's much harder to use, because you need to drive the render loop yourself.

[pixlwave]

Thanks wm4, this is helping. Oh good ol' Apple eh.

You might have more luck if you initialize cocoa in main(), enter its runloop, and then try to play a file with libmpv, but I have no idea if it works.

I just tried the following (in Swift) and can get the playback window and a playing video from the app delegate. However I get a couple of warnings about mpv calling the UI API from a background thread, and keypresses just "🔊 Funk". Is there a way to pass a reference to the main thread into libmpv so it can do the UI updates on main?

import AppKit

_ = NSApplication.shared
NSApp.setActivationPolicy(.regular)

let delegate = AppDelegate()
NSApp.delegate = delegate
NSApp.activate(ignoringOtherApps: true)
NSApp.run()

import Cocoa
import mpv

class AppDelegate: NSResponder, NSApplicationDelegate {
    func applicationDidFinishLaunching(_ notification: Notification) {
        if let ctx = mpv_create() {
            mpv_set_option_string(ctx, "input-default-bindings", "yes")
            mpv_set_option_string(ctx, "input-vo-keyboard", "yes")
            mpv_set_property_string(ctx, "fullscreen", "yes")
            var val = 1
            mpv_set_option(ctx, "osc", MPV_FORMAT_FLAG, &val)
            
            mpv_initialize(ctx)
            
            mpv_command_string(ctx, "loadfile \"/Users/Shared/Movies/test.mov\"")
            mpv_observe_property(ctx, 0, "pause", MPV_FORMAT_FLAG)
        }
    }
}

In ancient times, embedding with cocoa and --wid sort of worked, but this is probably broken with mpv's swift backend. The libmpv/cocoa/cocoabasic.m backend uses this.

Well I just tried cocoabasic.m and it crashed with the following: Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSApplication remoteCommandCenter]: unrecognized selector sent to instance 0x7fe87b502770' so I guess it's broken in modern macOS.

I can only say that the "new" mpv Swift backend didn't particular care about the libmpv case. Rather, it uses the libmpv backend itself, so it's basically like a libmpv application, stuffed into the mpv code itself. So it's possible that some OSX-specific mpv internals erroneously assume that either the mpv app is running somewhere, or that the libmpv user uses the render API. (The latter is known to work for iina.)

I suppose cocoabasic.m is broken either due to modern OSX as you suggested, or just due to simple code rot. But I recall that it wasn't very stable back then, and nobody has touched it for years. We've been going around and suggested API users to use the render API. (About which I now have second thoughts, because the API is complicated, and e.g. iina had deadlocks because they used it slightly incorrectly.)

Anyway, I don't even know much about the mpv OSX code.

CC @Akemi

[Akemi]

that's the problem (remoteCommandCenter) i wanted to fix that the iina guys had and i was completely ignored with my fix. the fix can be found here iina/iina#2694 (comment). if you can confirm it fixed i will merge it.

the UI Api calls from a background thread should be fixed, my assumptions somewhere are probably not correct.

yeah --wid embedding isn't supported by the new swift backend and even if added you most likely won't get all benefits of it like that.

since the swift backend is just using libmpv, i didn't really pay much care about embedding it tbh. with a bit of work the internals can be completely ripped out and used stand alone too.

to be frank, currently there is a bit of a mess in the macOS application code (the one independent from the backend). partially due to me, partially because the old architecture is not very clean. we need a clean separation between the Application main runloop and related stuff, and the actual macOS backend independent features that should also be usable via libmpv. in some instanced, for example, the code assumes that NSApp is our Application and not an external one and that messes up some things.

in conclusion, if something macOS specific doesn't work it's most likely my fault and i will try to fix it eventually if fixable and reported.

[pixlwave]

the fix can be found here iina/iina#2694 (comment). if you can confirm it fixed i will merge it.

Fixes cocoabasic.m for me 👍🏻

in conclusion, if something macOS specific doesn't work it's most likely my fault and i will try to fix it eventually if fixable and reported.

If I put together a simple project and post any issues I see from libmpv on the mpv-player/mpv repo, will that help?

[pixlwave]

I've uploaded a simplemac example here: https://github.com/pixlwave/mpv-examples/tree/master/libmpv/simplemac - happy to submit a pull request once it's working.

[Akemi]

just to clarify, the new cocoa-cb swift backend doesn't work at all with libmpv. it is initialised when the NSApplication within mpv is started, which is never the case with an external runloop with libmpv.

your example ported to objective-c works as expected and within the limit of the old backend. no warnings or sound. also this uses the old deprecated cocoa backend and if there are issues with it i won't fix it if not very minor and obvious.

// Build with: clang -o cocoabasic cocoabasic.m `pkg-config --libs --cflags mpv` -framework cocoa

#include <mpv/client.h>
#import <Cocoa/Cocoa.h>

@interface AppDelegate : NSObject <NSApplicationDelegate>
{
}
@end

@implementation AppDelegate
- (void) applicationDidFinishLaunching:(NSNotification *)notification {
    mpv_handle *mpv = mpv_create();
    mpv_set_option_string(mpv, "input-default-bindings", "yes");
    mpv_set_option_string(mpv, "input-vo-keyboard", "yes");
    mpv_set_property_string(mpv, "pause", "yes");
    int val = 1;
    mpv_set_option(mpv, "osc", MPV_FORMAT_FLAG, &val);

    mpv_initialize(mpv);

    mpv_command_string(mpv, "loadfile \"/Volumes/AkemiData/Desktop/1.png\"");
    mpv_observe_property(mpv, 0, "pause", MPV_FORMAT_FLAG);
}
@end

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        NSApplication *app = [NSApplication sharedApplication];
        [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
        AppDelegate *delegate = [AppDelegate new];
        app.delegate = delegate;
        [NSApp activateIgnoringOtherApps:YES];
        [app run];
    }
    return 0;
}

your other issue will be fixed with mpv-player/mpv#7463. please test it if possible.

[edit]

If I put together a simple project and post any issues I see from libmpv on the mpv-player/mpv repo, will that help?

see my comment above

[Akemi]

@pixlwave tried your swift example and it works 'as expected' i don't see or have any issues. did you have in particular besides the sound on key press you mentioned? key don't work at all, which is currently expected, though could possible be fixed.

[pixlwave]

Oh gosh, I think I've lead this conversation in about 3 different directions! 🥴 Sorry! So just to confirm, the original issue of the simple example not working on mac is expected and I really should close this issue.

your other issue will be fixed with mpv-player/mpv#7463. please test it if possible.

This definitely works for me with the cocoabasic.m example now.

tried your swift example and it works 'as expected' i don't see or have any issues. did you have in particular besides the sound on key press you mentioned? key don't work at all, which is currently expected, though could possible be fixed.

If I run that example through Xcode I see the following warning from thread sanitizer:

Clicking play/pause sometimes updates the button image, sometimes stays with the previous image in it's clicked colour. Keys don't work at all as you mentioned (I'm not sure where I would fix that though).

If I summarised the backends situation as "Please use the render api as there isn't a stable backend that provides a window on macOS anymore" would that be correct? (I'm not sure I fully understand what cocoa-cb is in relation to cocoa and the render api).

[Akemi]

yeah the simple example just doesn't work.

good then i will merge it, probably after you can confirm the below.

does this patch fix the warnings? also wonder if i can get such warning on the command line for mpv.

diff --git a/video/out/cocoa_common.m b/video/out/cocoa_common.m
index 4779d35a1f..1940861dca 100644
--- a/video/out/cocoa_common.m
+++ b/video/out/cocoa_common.m
@@ -395,8 +395,10 @@ void vo_cocoa_init(struct vo *vo)
     cocoa_add_event_monitor(vo);
 
     if (!s->embedded) {
-        [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
-        set_application_icon(NSApp);
+        run_on_main_thread(vo, ^{
+            [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
+            set_application_icon(NSApp);
+        });
     }
 }

the play/pause button in the osc you mean?

the keys probably can't be really fixed on your side, besides doing your own keybindings and sending them via the libmpv API. within mpv something has to be done about this part (https://github.com/mpv-player/mpv/blob/master/osdep/macosx_application.m#L112-L117). in the case of libmpv we probably need to register a local event monitor. something i removed here mpv-player/mpv@063ca8f. also see the commit message that's probably related to your warning sound problem.

cocoa is the old NSView/CGLContext that has some inherent problems. this uses the normal mpv core mechanisms to render. cocoa-cb is the new swift backend the internally uses libmpv to render (eg the render API). it has to use libmpv because we use CAOpenGLLayer to render. which is the Apple recommended way and less buggy. i never really though about an 'external' libmpv user using our internal libmpv user via libmpv.

i made a few basic tests before integrating this into mpv. they are simple but are basically what is within mpv.
https://github.com/Akemi/libmpv-objc-swift
https://github.com/Akemi/libmpv-CAOpenGLLayer-test

[pixlwave]

does this patch fix the warnings? also wonder if i can get such warning on the command line for mpv.

Yep sure does 👍🏻. I think you can get those checks anywhere by injecting libMainThreadChecker.dylib.

also see the commit message that's probably related to your warning sound problem.

Ah so the Funk sound is likely happening on my side of the app, as I need to set up a responder chain (ignoring whether I forward those events).

i never really though about an 'external' libmpv user using our internal libmpv user via libmpv.
i made a few basic tests before integrating this into mpv. they are simple but are basically what is within mpv.

I'll have a look through those tests because the first option sounds like it would end the universe if done wrong.