Mpv: Add support for JSON IPC control in Windows via Named Pipes

[daviwil]

Hi all,

I use Windows primarily and would love to use MPV and control it from within Emacs. Since MingW/MSYS2 doesn't seem to provide a UNIX socket implementation, the next best thing would be to use Win32's Named Pipes.

Some questions:

• Would this be a reasonable thing to add to MPV?
• Has it ever been attempted before?
• If added, should a new command line option (i.e. "input-named-pipe") be added or should we just reuse "input-unix-socket"?

I've already started working on adding named pipes support in my fork of the MPV repo so I'll be happy to send a pull request in the near future if this feature is desired.

Thanks!

[ghost]

Windows named pipes are completely different from unix domain socket, and the overlap doesn't seem to be overly big. The json ipc code is pretty much written against POSIX, so this would require some major refactoring. (Or a duplicated protocol implementation, which would be unacceptable.)

I'm really hoping on http://midipix.org/ to provide complete POSIX support on Windows, but unfortunately it's vaporware.

[daviwil]

There are definitely some differences in usage semantics between named pipes and sockets, but do you think it's different enough that it would require a completely separate implementation? Could I get away with having minimal open/close and send/receive abstractions and then keep the rest of the code mostly the same? I've read the existing IPC code and the part that touches sockets seems to be pretty contained.

If I get this working, would you be open to reviewing the changes to see whether they're beyond the scope of inclusion into MPV? I'm certainly happy to make any changes to keep things in line with MPV design and standards.

Thanks!

[rossy]

Windows named pipes are completely different from unix domain socket, and the overlap doesn't seem to be overly big. The json ipc code is pretty much written against POSIX, so this would require some major refactoring.

The API is totally different, but they seem to behave the same way. If mpv ever gets JSON IPC support on Windows, I think named pipes are the way to go. Refactoring to separate the protocol from the transport would probably be a good thing. I also had a look at doing this a while back, but I'm swamped with uni work at the moment, and I probably won't be able to finish it any time soon.

If added, should a new command line option (i.e. "input-named-pipe") be added or should we just reuse "input-unix-socket"?

I think it would be great if they used the same option. That way Qt programs could use JSON IPC without caring about the platform, since QLocalSocket is implemented with unix sockets on unix and named pipes on Windows.

[ghost]

The hard part is dealing with blocking. The current IPC code is not supposed to block. It calls poll() until there's new data to read. (Although it does block when sending events or replies to the socket, which is not really good.)

Windows in the other hand uses overlapped I/O to handle this.

Anyway, if you can get it to work...

Preferably without ifdeffery, but somehow separated using callbacks (the rest of the player does this a lot, like video output drivers etc.).

If I get this working, would you be open to reviewing the changes to see whether they're beyond the scope of inclusion into MPV?

Yes.

[daviwil]

Yep, was planning to do it using callbacks as you mentioned. I've seen other places in the code where this technique is used so I'll follow the same pattern.

Thanks for the feedback!

[ghost]

Ping?

[daviwil]

Apologies for the radio silence. As I was digging deeper into Emacs, it seemed that I might not easily be able to connect to mpv over named pipes after all. It seems pretty tied to Unix sockets. Because of that, I didn't spend much more time looking into named pipes support for mpv.

We may be in luck for a POSIX sockets implementation for Windows though: it appears that http://midipix.org is back up and seems on track for a release in June.

Feel free to close this bug if you want to clear it from view. If it turns out later that named pipes support is a viable option, I could try giving it a shot.

Thanks!

[ghost]

Feel free to close this bug if you want to clear it from view.

Clearing from view. Midipix is still vapourware, btw.

[rossy]

Well, this is finally done!

[daviwil]

That's awesome news, thanks a lot!