There is still the concern that because syncplay takes commands over the network and converts them to whatever is needed to control vlc and mpv, its users could be exposed to flaws. In the case of mpv, that would be sharing a binary (likely wrapped by a script to set things like LD_LIBRARY_PATH) and in the case of vlc, a writable area to put the LUA script the snaps to be controlled (eg, vlc and mpv) expose a content slot that allows the controller (ie syncplay) to access the resources needed to control it.To accommodate something like syncplay, there would be some mechanism to specify which applications syncplay would be allowed to launch (eg, vlc and mpv), and userd would mediate this access. I envision this potentially working similar to xdg-open in that the snap calls a binary that communicates with userd (or similar) over dbus, telling it which desktop file to launch and then userd launches the application.
This is needed for a desktop shell to launch arbitrary applications.
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.ĭata exchanged between the media player and Syncplay use a different protocol from the one used to exchange data between Syncplay client and remote server. Hence, we had to create our custom LUA script with support from the VLC team. http or telnet), but neither provides the control mechanism nor the information that Syncplay needs. VLC provides some LUA-based alternative protocols (e.g. To the best of our knowledge, these advanced features would not have been possible using the JSON IPC system. Furthermore, we provide a chat/notification system on mpv, based on a custom LUA script. While technically possible, this would make running Syncplay quite cumbersome. 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.
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. Mpv provides an alternative control method based on JSON IPC, which uses a socket to pipe commands and data. This is only feasible if Syncplay has access to the media player binaries. 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. VLC is controlled using a custom LUA script executed by the player. We use different ways to interact with each media player.
Furthermore, in terms of features we have worked with the developers of those media players to make the most of the functionality of each media player to provide the best user experienceĪs such, I hope that Syncplay can be granted permission for classic confinement as it is necessary for the operation of the software. We have not limited our supported media players (VLC, mpv, MPC-HC, MPC-Be) or supported operating systems (Windows, Linux, *BSD, macOS) to those which work with mpris. In answer to your query, Syncplay was not designed to be used with mpris. Playback rate (for slowdown due to time difference).OSD / On-screen display (for the display of messages).The following aspects of the media player are affected, but not controlled, by the server: Currently playing file if shared playlists are enabled (only opens files located in user-specified media directories or on whitelisted websites).Current play state (pause and unpause commands).Syncplay does not take input from over the internet to run arbitrary commands.Īs noted at what can be controlled is strictly limited to the following: Thank you for considering classic confinement for Syncplay, which is an open source project with over 2,000 weekly active users that has been actively maintained and developed over the past seven years.
0 kommentar(er)
