Synchronisierungs-Protokoll für Po.W.E.R.
=========================================
Version: 20131106
Autor: Stefan Schürmans
Aufgabenstellung
----------------
Für die Theateraufführung Po.W.E.R.ist es notwendig, verschiedene Rechner, die
Audio, Video und/oder Effekte abspielen miteinander zu synchronisieren. Dabei
soll nicht nur die aktuelle Zeit innerhalb eines Audio-Stücks bzw. Films
synchronisiert werden, sondern auch das aktuelle Stück (z.B. der Dateiname)
mit behandelt werden. Da kein Standard-Protkoll für diese Aufgabe gefunden
werden konnte, soll nun ein einfaches Protokoll neu definiert werden.
Grundprinzip
------------
Ein sogenannter Master soll als zentrale Instanz die Synchronisations-
Informationen periodisch per Ethernet/WLAN an die einzelnen Abspielrechner
(auch Clients genannt) verteilen. Die Abspielrechner empfangen den Namen
des aktuellen Stücks und die aktuelle Position in diesem Stück. Sie
vergleichen diese Soll-Information mit der lokalen Ist-Information und passen
das Stück und die Position eigenständig an, wenn eine signifikante Abweichung
vorliegt.
Die Übermittlung der Synchronisations-Informationen soll ohne An-/Abmeldung
der Clients beim Server erfolgen und keine Speicherungs eines Zustands der
Gegenstelle auf Seiten des Servers oder der Clients erfordern, damit die
einzelnen Geäte autonom arbeiten können. Es soll gewährleistet sein,
dass der Ausfall eines Gerätes (Client oder Server) die Funktion der anderen
Geräte nicht beeinträchtigt. Im Falle des Ausfalls des Servers steht
allerdings die Synchronisations-Funktion nicht mehr zur Verfügung und die
Clients laufen unsynchronisert weiter. Wird das ausgefallene Gerät
neu gestartet, soll es direkt wieder den Normalbetrieb aufnehmen, ohne
dass die anderen Geräte mitwirken.
Datenformat
-----------
Die Synchronisations-Informationen werden periodisch per UDP-Broadcast
gesendet. Sowohl Quell- als auch Ziel-Port sind 5740. Die Sendung erfolgt
alle 0.1 Sekunden. Jedes gesendete Informations-Paket enthält den Namen des
aktuellen Stücks und die aktuelle Position im Stück.
Da die Informations-Pakete häufig versand werden und schnell bearbeitet werden
müssen, soll sowohl deren Erstellung als auch deren Verarbeitung möglichst
effizient sein. Es wir daher ein einfaches Binärformat verwendet. Die
Nutzdaten des UDP-Pakets sind wie folgt aufgebaut:
Start Länge Typ Beschreibung
----- ----- --- ------------
0 4 ASCII feste Kennung, immer "PoSy"
(steht für "Po.W.E.R. Synchronisation")
4 4 U32be Bitfeld mit Steuerinformationen
8 64 UTF-8 Name des aktuellen Stücks
72 4 U32be aktuelle Position im Stück (in Millisekunden)
Die Bedeutung der Typkürzel ist wie folgt:
Typ Bedeutung
--- ---------
ASCII ASCII-String mit fester Maximal-Länge, ggf. mit Null-Zeichen aufgefüllt
UTF-8 UTF-8-String mit fester Maximal-Länge, ggf. mit Null-Zeichen aufgefüllt
U32be vorzeichenlose Ganzzahl, 32 bit Länge, byte order big-endian
Das Bitfeld für Steuerinformationen enthält folgende Informationen (mit
bitweisem Oder verknüpft):
Wert Beschreibung
---- ------------
1 Pause aktiv
Bei der Generierung der Pakete muss das Datenformat strikt eingehalten werden.
In späteren Versionen des Protokoll können ggf. weitere Felder angefügt werden.
Daher ist nicht erlaubt, benutzerspezifische Felder anzuhängen. Nicht
definierte Werte in Bitfeldern sind stets mit 0 zu kodieren.
Beim Empfang eines Pakets ist die Länge und die Kennung zu überprüfen. Pakete
mit zu geringer Länge und/oder anderer Kennung sind zu verwerfen. Längere
Pakete sind abzuschneiden und wie Pakete korrekter Länge zu behandeln. Nicht
definierte Werte in Bitfeldern sind zu ignorieren.
Anhang (nicht normativ)
=======================
Master
------
Der Synchronisierungs-Master verwaltet die globale Playliste und spielt diese
ab. Dabei ist unter Abspielen nur das Aussenden der Synchronisations-Pakete
zu verstehen. Auf dem Bildschirm wir dem Benutzer eine Fenster ähnlich zu dem
eines normalen PC-Video-Players angeboten, welches die Playliste mit den
einzelnen Stücken beinhaltet und außerdem Knöpfe für Abspielen, Pause, Stopp,
nächstes Stück, vorheriges Stück und eine Positionsleiste (Scrollbalken)
anbietet. Damit kann der Master wie ein Video-Player bedient werden. Die
verschiedenen Clients passen sich dann über das Synchronisations-Protokoll
automatisch an den Master an.
Master Web-Interface (bisher nur Idee, optional)
--------------------
Der Master bietet zusätzlich zum Fenster auf dem lokalen bildschirm ein
Webinterface an, auf dem die gleichen Elemente wie im Fenster zu sehen sind.
Damit kann der Master auch über mobile Geräte aus dem WLAN heraus gesteuert
werden.
Video-Abspieler für Pixelwände
------------------------------
Alle Pixelwände werden von einem zentralen Rechner angesteuert. Die Filme
für die einzelnen Wände werden zur Unterscheidung in verschiedenen
Verzeichnissen abgelegt. In jedem dieser Verzeichnisse liegen die Filme mit
Namen gemäß der Playliste des Masters (plus eine geeignete Dateinamen-
Erweiterung). Außerdem besitzt der Rechner eine Kopie Playliste, so dass er
bei Ausfall des Masters autonom die Stücke abspielen kann.
Audio-Abspieler für Roboter
---------------------------
Auf jedem Roboter befindet sich ein Rechner, der die Audiodateien für den
jeweiligen Roboter sowie eine Kopie der Playliste besitzt. Im Normalbetrieb
wird das abzuspielende Stück und die Position über das Synchronisations-
Protokoll gesteuert. Durch die lokale Kopie der Playliste ist aber bei
Ausfall des Masters ein autonomes Abspielen möglich.
Ein mögliche Implementierung könnte das MPlayer slave interface verwenden:
mplayer -slave -quiet -input nodefault-bindings -noconfig all -idle
Über "get_file_name" und "get_time_pos" ist das aktuelle Stück und die aktuelle
Position auf 0.1s genau ermittelbar. Im Falle einer signifikanten Abweichung
kann die Postion mittels "seek <pos> 2" neu eingestellt werden. Die
abzuspielende Datei kann mit "loadfile <file>" geändert werden.
Effekt-Abspieler für Roboter
----------------------------
Der Rechner auf jedem Roboter steuert zusätzlich Effekt-Beleuchtungen. Diese
können entweder durch Zusatz-Informationen in den Audio-Datein (z.B. Matroska)
enthalten sein und von einem entsprechen MPlayer-Plugin ausgewertet werden.
Alternativ können die Effekte in einer Textdatei (Zeilen mit Zeitstempel
und Effekt) gespeichert werden und von einem separaten Player ausgelöst werden,
der durch das Synchronisations-Protokoll passend gesteuert wird.