stage_director

sync protocol spec (German)
Parent 6b79f33
Stefan Schuermans

Stefan Schuermans commited on 2014-01-15 22:03:27
Showing 1 changed files, with 144 additions and 0 deletions.

SyncProtokoll.txt
View file @ eb427c6
... ... 
@@ -0,0 +1,144 @@
1 
+Synchronisierungs-Protokoll für Po.W.E.R.
2 
+=========================================
3 
+
4 
+Version: 20131106
5 
+Autor: Stefan Schürmans
6 
+
7 
+Aufgabenstellung
8 
+----------------
9 
+
10 
+Für die Theateraufführung Po.W.E.R.ist es notwendig, verschiedene Rechner, die
11 
+Audio, Video und/oder Effekte abspielen miteinander zu synchronisieren.  Dabei
12 
+soll nicht nur die aktuelle Zeit innerhalb eines Audio-Stücks bzw. Films
13 
+synchronisiert werden, sondern auch das aktuelle Stück (z.B. der Dateiname)
14 
+mit behandelt werden.  Da kein Standard-Protkoll für diese Aufgabe gefunden
15 
+werden konnte, soll nun ein einfaches Protokoll neu definiert werden.
16 
+
17 
+Grundprinzip
18 
+------------
19 
+
20 
+Ein sogenannter Master soll als zentrale Instanz die Synchronisations-
21 
+Informationen periodisch per Ethernet/WLAN an die einzelnen Abspielrechner
22 
+(auch Clients genannt) verteilen.  Die Abspielrechner empfangen den Namen
23 
+des aktuellen Stücks und die aktuelle Position in diesem Stück.  Sie
24 
+vergleichen diese Soll-Information mit der lokalen Ist-Information und passen
25 
+das Stück und die Position eigenständig an, wenn eine signifikante Abweichung
26 
+vorliegt.
27 
+
28 
+Die Übermittlung der Synchronisations-Informationen soll ohne An-/Abmeldung
29 
+der Clients beim Server erfolgen und keine Speicherungs eines Zustands der
30 
+Gegenstelle auf Seiten des Servers oder der Clients erfordern, damit die
31 
+einzelnen Geäte autonom arbeiten können.  Es soll gewährleistet sein,
32 
+dass der Ausfall eines Gerätes (Client oder Server) die Funktion der anderen
33 
+Geräte nicht beeinträchtigt.  Im Falle des Ausfalls des Servers steht
34 
+allerdings die Synchronisations-Funktion nicht mehr zur Verfügung und die
35 
+Clients laufen unsynchronisert weiter.  Wird das ausgefallene Gerät
36 
+neu gestartet, soll es direkt wieder den Normalbetrieb aufnehmen, ohne
37 
+dass die anderen Geräte mitwirken.
38 
+
39 
+Datenformat
40 
+-----------
41 
+
42 
+Die Synchronisations-Informationen werden periodisch per UDP-Broadcast
43 
+gesendet.  Sowohl Quell- als auch Ziel-Port sind 5740.  Die Sendung erfolgt
44 
+alle 0.1 Sekunden.  Jedes gesendete Informations-Paket enthält den Namen des
45 
+aktuellen Stücks und die aktuelle Position im Stück.
46 
+
47 
+Da die Informations-Pakete häufig versand werden und schnell bearbeitet werden
48 
+müssen, soll sowohl deren Erstellung als auch deren Verarbeitung möglichst
49 
+effizient sein.  Es wir daher ein einfaches Binärformat verwendet.  Die
50 
+Nutzdaten des UDP-Pakets sind wie folgt aufgebaut:
51 
+
52 
+Start   Länge   Typ     Beschreibung
53 
+-----   -----   ---     ------------
54 
+    0       4   ASCII   feste Kennung, immer "PoSy"
55 
+                        (steht für "Po.W.E.R. Synchronisation")
56 
+    4       4   U32be   Bitfeld mit Steuerinformationen
57 
+    8      64   UTF-8   Name des aktuellen Stücks
58 
+   72       4   U32be   aktuelle Position im Stück (in Millisekunden)
59 
+
60 
+Die Bedeutung der Typkürzel ist wie folgt:
61 
+
62 
+Typ     Bedeutung
63 
+---     ---------
64 
+ASCII   ASCII-String mit fester Maximal-Länge, ggf. mit Null-Zeichen aufgefüllt
65 
+UTF-8   UTF-8-String mit fester Maximal-Länge, ggf. mit Null-Zeichen aufgefüllt
66 
+U32be   vorzeichenlose Ganzzahl, 32 bit Länge, byte order big-endian
67 
+
68 
+Das Bitfeld für Steuerinformationen enthält folgende Informationen (mit
69 
+bitweisem Oder verknüpt):
70 
+
71 
+Wert   Beschreibung
72 
+----   ------------
73 
+   1   Pause aktiv
74 
+
75 
+Bei der Generierung der Pakete muss das Datenformat strikt eingehalten werden.
76 
+In späteren Versionen des Protokoll können ggf. weitere Felder angefügt werden.
77 
+Daher ist nicht erlaubt, nicht benutzerspezifische Felder anzuhängen.  Nicht
78 
+definierte Werte in Bitfeldern sind stets mit 0 zu kodieren.
79 
+
80 
+Beim Empfang eines Pakets ist die Länge und die Kennung zu überprüfen.  Pakete
81 
+mit zu geringer Länge und/oder anderer Kennung sind zu verwerfen.  Längere
82 
+Pakete sind abzuschneiden und wie Pakete korrekter Länge zu behandeln.  Nicht
83 
+definierte Werte in Bitfeldern sind zu ignorieren.
84 
+
85 
+Anhang (nicht normativ)
86 
+=======================
87 
+
88 
+Master
89 
+------
90 
+
91 
+Der Synchronisierungs-Master verwaltet die globale Playliste und spielt diese
92 
+ab.  Dabei ist unter Abspielen nur das Aussenden der Synchronisations-Pakete
93 
+zu verstehen.  Auf dem Bildschirm wir dem Benutzer eine Fenster ähnlich zu dem
94 
+eines normalen PC-Video-Players angeboten, welches die Playliste mit den
95 
+einzelnen Stücken beinhaltet und außerdem Knöpfe für Abspielen, Pause, Stopp,
96 
+nächstes Stück, vorheriges Stück und eine Positionsleiste (Scrollbalken)
97 
+anbietet.  Damit kann der Master wie ein Video-Player bedient werden.  Die
98 
+verschiedenen Clients passen sich dann über das Synchronisations-Protokoll
99 
+automatisch an den Master an.
100 
+
101 
+Master Web-Interface (bisher nur Idee, optional)
102 
+--------------------
103 
+
104 
+Der Master bietet zusätzlich zum Fenster auf dem lokalen bildschirm ein
105 
+Webinterface an, auf dem die gleichen Elemente wie im Fenster zu sehen sind.
106 
+Damit kann der Master auch über mobile Geräte aus dem WLAN heraus gesteuert
107 
+werden.
108 
+
109 
+Video-Abspieler für Pixelwände
110 
+------------------------------
111 
+
112 
+Alle Pixelwände werden von einem zentralen Rechner angesteuert.  Die Filme
113 
+für die einzelnen Wände werden zur Unterscheidung in verschiedenen
114 
+Verzeichnissen abgelegt.  In jedem dieser Verzeichnisse liegen die Filme mit
115 
+Namen gemäß der Playliste des Masters (plus eine geeignete Dateinamen-
116 
+Erweiterung).  Außerdem besitzt der Rechner eine Kopie Playliste, so dass er
117 
+bei Ausfall des Masters autonom die Stücke abspielen kann.
118 
+
119 
+Audio-Abspieler für Roboter
120 
+---------------------------
121 
+
122 
+Auf jedem Roboter befindet sich ein Rechner, der die Audiodateien für den
123 
+jeweiligen Roboter sowie eine Kopie der Playliste besitzt.  Im Normalbetrieb
124 
+wird das abzuspielende Stück und die Position über das Synchronisations-
125 
+Protokoll gesteuert.  Durch die lokale Kopie der Playliste ist aber bei
126 
+Ausfall des Masters ein autonomes Abspielen möglich.
127 
+
128 
+Ein mögliche Implementierung könnte das MPlayer slave interface verwenden:
129 
+mplayer -slave -quiet -input nodefault-bindings -noconfig all -idle
130 
+Über "get_file_name" und "get_time_pos" ist das aktuelle Stück und die aktuelle
131 
+Position auf 0.1s genau ermittelbar.  Im Falle einer signifikanten Abweichung
132 
+kann die Postion mittels "seek <pos> 2" neu eingestellt werden.  Die
133 
+abzuspielende Datei kann mit "loadfile <file>" geändert werden.
134 
+
135 
+Effekt-Abspieler für Roboter
136 
+----------------------------
137 
+
138 
+Der Rechner auf jedem Roboter steuert zusätzlich Effekt-Beleuchtungen.  Diese
139 
+können entweder durch Zusatz-Informationen in den Audio-Datein (z.B. Matroska)
140 
+enthalten sein und von einem entsprechen MPlayer-Plugin ausgewertet werden.
141 
+Alternativ können die Effekte in einer Textdatei (Zeilen mit Zeitstempel
142 
+und Effekt) gespeichert werden und von einem separaten Player ausgelöst werden,
143 
+der durch das Synchronisations-Protokoll passend gesteuert wird.
144 
+
0 145