Integration with syncplay

[josch]

I'm working on adding clapper support to syncplay. In https://github.com/Syncplay/syncplay/issues/577 @Rafostar suggested to use the webrtc interface to communicate with clapper. I'm opening this issue to track the missing features of clapper for successful integration with syncplay. Let me start with a couple of thoughts:

• in #76 we talked about a feature that would clapper load an additional video without replacing an existing one. When designing the webrtc protocol this feature should probably be kept in mind?
• when syncplay opens up clapper, could we add a way such that clapper would start with the webrtc server enabled, independent on whether the user enabled this manually before? Could we maybe have a command line flag that is able to enable remote control support and configure a port for a newly started clapper process but leave the global configuration unaffected?

I have implemented a minimal clapper interface for syncplay using dbus. From that experience I can tell that the webrtc interface needs to support at least:

• open a uri {"action":"set_playlist","value":["file:///path/to/video.mp4"]}
• query the position
• query playback status (paused/playing)
• set the position {"action":"seek","value":$time_in_ns}
• set the playback status (paused/playing) {"action":"play"} and {"action":"pause"}
• send an unsolicited message when playback status changes
• send an unsolicited message when the position changes

[Rafostar]

First and foremost, as I mentioned in that syncplay issue, this functionality (WebSocket communication) is considered very new and message syntax may be changed before we reach an API stable Clapper 1.0 version release. Please bear that in mind if you want to already start working on it.

When designing the webrtc protocol this feature should probably be kept in mind?

Yes, it should. Same probably goes for MPRIS too. The latter one needs checking how other apps or spec says to do it correctly.

query the position and playback status

The design I have in mind is to send the current media info (with these) upon client connection/reconnection and later only inform client with changes/updates in real time. So, I hope that there will be no need for query, but we might add a request to send media info again if necessary.

send an unsolicited message when playback status changes

This already happens.

[Rafostar]

When #374 is done and merged, it should be a better alternative then websocket communication for your use-case, as:

1. You will be able to use and control Clapper from Python directly thanks to GObject bindings
2. Faster, since you do not have to spawn and talk to a separate app/process
3. You will be able to add/remove any features from Clapper you want as GTK also works from Python