BlinkenArea - GitList
Repositories
Blog
Wiki
stage_director
Code
Commits
Branches
Tags
Search
Tree:
1c44773
Branches
Tags
master
stage_director
SyncProtokoll.txt
Grammatik-Fix
Stefan Schuermans
commited
1c44773
at 2014-03-22 13:21:57
SyncProtokoll.txt
Blame
History
Raw
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.
