IPC: socat equivalent on Windows

[Hrxn]

Important Information

• mpv version: mpv 0.28.0 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
• Windows Version: Windows 10, Version 10.0.19043.1645
• Source of the mpv binary: mpv.io .. this was kinda official I think, back then when @lachs0r made releases 😄

The correct way to make use of the JSON IPC interface on Windows?

As the mpv manual mentions here

Unfortunately, it's not as easy to test the IPC protocol on Windows, since Windows ports of socat (in Cygwin and MSYS2) don't understand named pipes. In the absence of a simple tool to send and receive from bidirectional pipes, the echo command can be used to send commands, but not receive replies from the command prompt.

To be able to simultaneously read and write from the IPC pipe, like on Linux, it's necessary to write an external program that uses overlapped file I/O (or some wrapper like .NET's NamedPipeClientStream.)

Okay, so I gave it shot, and wanted to know how to best progress from here on..

Required First Step

• Use a separate terminal window/tab/pane and start mpv with IPC, named pipe and idle mode
  mpv --input-ipc-server=\\.\pipe\ipc_mpv --idle=yes
  (yes, I know how to start it as a separate process without any window etc., but it's good for debugging to do it like this)

Put this into a .ps1 file, e.g. mp.ipc.ps1 and make it accessible via PATH

#Requires -Version 7.2

param (
	[String] $CommandMessage,
	[String] $MpvPipeName = 'ipc_mpv'
)

if ([String]::IsNullOrEmpty($CommandMessage)) {
	Write-Host '[mp.ipc] Usage: mp.ipc.ps1 [-CommandMessage] <mpv IPC Command Message> [[-MpvPipeName] <mpv IPC Pipe Name>]'
	exit 0
}
if ($null -eq ([System.IO.Directory]::GetFiles('\\.\\pipe\\') | Where-Object {$_ -match $MpvPipeName})) {
	Write-Host '[mp.ipc] Error: Named pipe not found, make sure that an mpv instance with IPC enabled is running!'
	exit 1
}

#### Processing of the Command Message
# Remove all line breaks in the command message
$RelayMessage = $CommandMessage -replace "`n|`r"
# According to https://github.com/mpv-player/mpv/blob/master/DOCS/man/ipc.rst, every message must be terminated with \n
$RelayMessage = [String]::Concat($RelayMessage.Trim(), "`n")

if ($RelayMessage.StartsWith('{')) {
	$ExpectReply = $true
} else {
	$ExpectReply = $false
}

#### Init()
$PipeDirectiOpt   = [System.IO.Pipes.PipeDirection]::InOut
$PipeOptionsOpt   = [System.IO.Pipes.PipeOptions]::Asynchronous
$PipeImpersonlOpt = [System.Security.Principal.TokenImpersonationLevel]::Impersonation

$PipeClient = [System.IO.Pipes.NamedPipeClientStream]::new('.', $MpvPipeName, $PipeDirectiOpt, $PipeOptionsOpt, $PipeImpersonlOpt)
$PipeReader = [System.IO.StreamReader]::new($PipeClient)
$PipeWriter = [System.IO.StreamWriter]::new($PipeClient)

#### Main()
try {
	$PipeClient.Connect()

	$PipeWriter.AutoFlush = $true

	$PipeWriter.WriteLine($RelayMessage)

	if ($ExpectReply) {
		$IncomingData = $PipeReader.ReadLine()
		Write-Output $IncomingData
	}
}
catch {
	Write-Host '[mp.ipc] Unhandled exception occured!' -ForegroundColor Red
	Write-Host $_ -ForegroundColor DarkRed
	Write-Host $_.ScriptStackTrace -ForegroundColor DarkRed
}
finally {
	$PipeWriter.Dispose()
	$PipeReader.Dispose()
	$PipeClient.Dispose()
}

This can now be used like this, for example: mp.ipc '{ "command": ["get_property", "idle-active"] }'

And it basically works, because it's not just sending commands, but also receiving replies from the terminal.

I'm just not sure if this is really the optimal way to do it. Because you have to be careful when using any read()-like method on the stream, otherwise the script will simply not terminate. It's not immediately obvious, but there are two ways to send commands to mpv here, the JSON messages and simple strings like as in the input commands (same format as input.conf, basically). mpv receives and handles both kinds just fine, but the latter will not trigger any reply of any kind, apparently, and will bork any reads.

This script does not really do any handling with incoming reply messages, but it can easily be extended, and I checked that it works with simple, normal replies.
Of course, commands like { "command": ["observe_property", 1, "volume"] } work a bit different here, and I'm not sure how to approach this yet. A similar issue with the event messages that get sent back. I can see them, but I don't know how to properly handle them. As I understand it from the manual, every single event (just like any message, etc.) is separated by the newline char (\n),
but how and when do these events end, for example, after sending a "loadfile" command? Is there any way to know this in advance?
Or does the stream has to be read and handled constantly, all the time?

Another question, which might be an actual issue, unlike everything else mentioned in here so far, is that when sending this command: { "command": ["loadfile", "E:/path/to/file.mp4", "append"] }, I can see that this gets added to the internal default playlist (is that what it's called?), but if I follow this up with { "command": ["playlist-next"] }, nothing is happening. Is this expected?
I mean, when checking for { "command": ["get_property", "pause"] } I see that this is false, but playback does simply not start?

Edit:

Small addendum:
I use some value for impersonationLevel when using the constructor for NamedPipeClientStream above, but I think this might be entirely optional. I'm not really sure what this does, actually. Just wanted to mention this, just in case.