We use different ways to interact with each media player. On Linux, we support mpv and VLC. mpv is controlled primarily via its CLI. VLC is controlled using a custom LUA script executed by the player. In both cases, we need to run an instance of the media player in a python-controlled subprocess, using a lot of custom CLI options, and redirect stdout/stderr to our software. This is only feasible if Syncplay has access to the media player binaries.
mpv provides an alternative control method based on JSON IPC, which uses a socket to pipe commands and data. However, at this moment Syncplay does not support at all this IPC, so we would have to rewrite our control system for mpv from the ground up. In addition, without access to the mpv binary, the user would have to manually run the player outside the snap, supplying the CLI arguments needed (including our configuration and the socket used for the IPC), then pass all this to the snap instance of Syncplay. While technically possible, this would make running Syncplay quite cumbersome. Furthermore, we provide a chat/notification system on mpv, based on a custom LUA script. To the best of our knowledge, these advanced features would not have been possible using the JSON IPC system.
VLC provides some LUA-based alternative protocols (e.g. http or telnet), but neither provides the control mechanism nor the information that Syncplay needs. Hence, we had to create our custom LUA script with support from the VLC team. Additionally, we need to run VLC from Syncplay to specify the loopback port and prevent issues when more than one instance of Syncplay is being run at a time.
Data exchanged between the media player and Syncplay use a different protocol from the one used to exchange data between Syncplay client and remote server. The latter protocol runs on TCP, is JSON-based, and is documented here.