Mpv: Control mpv from command line in Windows

[axbw]

It seems JSON IPC support on Windows platform is still a fantasy. Is there a way we could have a wrapper for the JSON IPC that would allow one to control an already running instance of mpv from the command line ?

So, instead of passing/receiving the requests though http socket, one would forward the requests from the command line (say mpv.exe -j ) and the JSON string would be forwarded to the JSON module which would interpret it and execute it. We could simply return the response as a JSON string or discard it. Regardless we would at least have a way of controlling it from the command line ?

Thanks.

[siikamiika]

You can use lua scripts to implement your own IPC protocol. You might be interested in this https://github.com/siikamiika/mpv-python-ipc. It works, but it uses some horrible methods to achieve it. It basically launches an mpv instance with a lua script that listens to stdin for commands that are encoded in script_messages and the script sends responses or events by printing them to stdout. A better way would probably be to use some lua library like luasocket.

[ghost]

You currently can use pipes to control it on windows. The pipe just won't accept json and takes only normal input.conf-style commands. You could also compile mpv with cygwin and get "normal" pipes with it (but I'm unsure how compatible this will be with the rest of Windows).

Yes, we could select some other IPC mechanism for this, but it's some work to implement it, and we'd still have to know _which_ IPC mechanism. Is there an IPC mechanism in Windows that actually works?

[axbw]

Thanks siikamiika and wm4.

Siikamiika, I am not very familiar with Lua or python, I will have to spend some time to understand and experiment with your scripts.
Wm4, I read the other issue about the JSON IPC feature request here https://github.com/mpv-player/mpv/issues/1882. I have never had the need to use IPC on WIndows, so I cannot really comment on which is the most efficient IPC mechanism in Windows.

I read up on MSDN about the different IPC mechanisms Windows offers, it seems using pipes, RPC and sockets might be a major undertaking, but as I mentioned earlier if we could simple devise a mechanism to forward the JSON commands we could bypass the http listener and forward the JSON string to the module/function that parses and executes it.

If we could use Data Copy (WM_COPYDATDA) which I get to read is efficient for use on the same host. This should permit passing arguments to an already running instance of mpv. The command line argument could be JSON string that will be passed to JSON module or say, comma separated strings literals/numbers which will be passed to command parser module for validation and subsequent execution. The data passed to the already running instance will include HWND to the caller, so that the response can be sent back to the caller using Data Copy again, the caller will terminate after returning the response as it's return value.

Just a thought, not sure if it makes sense as I haven't browsed the mpv source code yet.

[siikamiika]

@axbw If you're having trouble installing or using it, feel free to open an issue and I'll try to improve the README. I wouldn't suggest trying to understand how it works, though.

From the IPC mechanisms you mentioned I think (TCP) sockets are the best alternative. They work on every platform mpv supports and are reliable. I'm wondering how different it would be from the existing JSON IPC (https://github.com/mpv-player/mpv/blob/master/input/ipc.c) and how much platform specific code it would require.

Then there's the alternative of extending the slave mode commands to a bidirectional JSON protocol, but if I've understood correctly, this isn't an easy task on Windows (because of blocking).

[ghost]

nd how much platform specific code it would require.

Windows provides no POSIX sockets or pipes, so _everything_ would be different.

[chainikdn]

TCP server socket for Windows: #2917

[chainikdn]

That closed pull request shows that it's not like "everything would be different" but just a question of a few lines of code.
So, what exactly stops you from adding TCP server "your way"?

[ghost]

That closed pull request shows that it's not like "everything would be different" but just a question of a few lines of code.

Not sure what you mean, but your change is exactly what we're trying to avoid in this project. No horrible ifdeffery all over the place.

So, what exactly stops you from adding TCP server "your way"?

Windows is too different from POSIX, and TCP is not the only problem. Your PR also breaks parts of event handling.

[chainikdn]

Not sure that copying 95% of code into "ipc_win.c" will be much better than "horrible ifdeffery". But you're the boss.

Windows is too different from POSIX

And the biggest difference so far is WSAPoll() vs. poll() ;)

Your PR also breaks parts of event handling.

What do you mean? From my tests all events work exactly as they should.

[rossy]

It seems JSON IPC support on Windows platform is still a fantasy.

It finally got added! Controlling mpv from the command line is now somewhat doable. Start mpv with:

mpv file.mkv --input-ipc-server=\\.\pipe\mpv-pipe

and it can be controlled from a command prompt with:

echo cycle pause >\\.\pipe\mpv-pipe

A batch script or similar could be used to make this simpler. For example, if your ipc server is always running on \.pipempv-pipe (because it's in your config,) you could make, say, mpv-remote.bat, containing the following:

@>\\.\pipe\mpv-pipe echo %*

then run commands like this:

mpv-remote cycle pause

[axbw]

Thanks a million for implementing the TCP sockets.
I will have to try and test this.

Thanks again.