FOSSGIS 2014

• drei Säle (H1 bis H3)
  • Es gibt noch einen großen Saal der nur zur Eröffnung und Verabschiedung genutzt wird.
• Programm (Pentabarf)
• FOSSGIS Seite im OSM Wiki
• Vorträge der letzte drei Jahre: http://ftp5.gwdg.de/pub/misc/openstreetmap/ → FOSSGIS201*
  • Upload via Auphonic

• Andi
• MaZderMind
• Sven
• Marc

Das Einrichten der Systeme für die Konferenz (tracker-scripte für die richtige Konferenz konfigurieren, symlinks für vor/abspann-Ordner anlegen, den live-Server Konfigurieren) ist für jemanden ohne Erfahrungen mit dem Setup praktisch unmöglich. Ohne die Remote-Unterstützung von florolf, atze, derpeter und ein paar anderen hätte das nicht geklappt.

Daher Notiz No.1: Wenn du das Zeug nicht sehr gut kennst, sprich dich vorher ab und sorg dafür, dass Leute mit Ahnung Zeit haben dir zu helfen und auch von aussen auf die Maschinen kommen (Feste, Externe IP für alle Cubes und keine fiesen Firewall-Regeln!)

Während der Konferenz hatten wir durchgehend Helfer, die das Video-Mixing sowie einen Teil der Schnittarbeiten übernommen haben. Dadurch konnten wir bereits mittags die Talks des Vormittags und abends die Recordings des ganzen Tages final online haben.

Es gab zwei große Bottlenecks in unseren Publishing-Zyklus:

• wir hatten zum schneiden nur einen Rechner vorbereitet. Auf einer Nicht-Nerd-Konferenz ist die Anzahl an Debian-Stable-Notebooks, welche die richtige Version glusterfs fahren, eher begrenzt. Daher habe ich ein USB-Stick/SD-Karten-Image vorbereitet, von dem potentielle Helfer ihr Gerät booten können.
• Wir haben - der Kompatibilität mit Browser wegen - in h264 und WebM encoded. Der WebM-Encoder in ffmpeg ist unglaublich langsam, weil er 2-Pass Single-Core läuft. Es wäre daher Ratsam, in Zukunft zwei WebM-Encoder parallel zu verwenden.

Der Produktionszyklus erforderte es, dass die Cubes tagsüber alle Schritte gleichzeitig bearbeiten: Recorden, Schneiden, Encoden. Wir hatten dabei fast keine Probleme; das parallele encoden stellt zumindest für das Recording kein Problem dar.

Beim Schneiden hatten wir zeitweilig Hänger und Ruckler beim betrachten der dv-Dateien. Ich vermute hier aber keinen IO-Engpass sondern eher einen CPU/Scheduling-Engpass für den gluster-Server. Wir sollten man versuchen dessen Prio erhöhen oder die der Encoder senken.

Auphonic kennen Andi und ich vom Podcasten und wir wollten nach möglichkeit alle Videos da durch schieben. Zum einen putzt Auphonic das Audio noch mal sauber, zum anderen übernimmt es die Verteilung der Dateien zu verschiedenen Zielen. In unserem Fall hat Auphonic alle Videos samt Audio-Only-Version in verschiedenen Formaten auf einen FTP-Server der GWDG sowie zu YouTube geschoben.

Wir haben zum Upload ein eigenes Script benutzt, welches aber derzeit noch keine Tracker-Anbindung hat und daher alles hochlädt, was fertig encoded ist – unabhängig vom checked-Status im Tracker.

Wir haben eine modifizierte Version von DV-Switch verwendet, welche die PIP-Funktion wieder einschaltet; das PIP jedoch fest in die untere rechte Ecke setzt. Der Helfer am Mixer-Notebook kann nur noch mit 'p' das PIP ein- und ausschalten. Unserer Erfahrung nach funktioniert das ziemlich gut, die nicht-technischen Helfer waren damit nicht überfordert und haben auch keinen Blödsinn gemacht.

Probleme hatten wir aber in der Kombination PIP und Framegrabber. Das PIP schien teilweise mit verringerter Framerate zu laufen. Andi meint, dass die Framegrabber eine variable Framerate liefern, wenn auf dem Bildschirm wenig passiert.

auf dem cube läuft ein ffmpeg-Prozess, der den mjpeg-Stream des Framegrabbers in einen dv-stream umrechnet. Dieser müsste aus der variablen Framerate einen 25fps DV-Stream generieren. Wir haben das mit einem “-r 25” zu hotfixen versucht, hat aber nicht geklappt. Eventuell kann man auch in den Framegrabbern was umstellen.

In einem der Räume (H3) wurden wir vom lokalen RZ vor brüchigen Netzwerkleitungen gewarnt und tatsächlich hatten wir 10-20% Packet Drops (sogar aus den anderen beiden Räumen). Die Scripte, die mit dem Tracker sprechen, sind nicht darauf vorbereitet, kein Netz zu haben. Wenn das Script beispielsweise nach dem Encoden beim Tracker nicht bescheid geben kann, gibt es einfach auf.

Teilweise sind die Scripte richtig gecrasht und wir mussten sie erneut starten, nur weil für einen kurzen Zeitraum keine Netzverbindung bestand. Es wäre schöner, wenn die Scripte dann einfach noch ein paar mal loopen würden, bis das Netz wieder da ist.

Außerdem war es recht schwierig, den Status der Scripte zu ermitteln. Das war son' bisschen Anhalter alike: Im screen 21 des root-users im 4. Window läuft im Hintergrund das Encoder-Script.

Cool wäre es, wenn die Scripte in benannten Screen-Sessions starten würden; dann wüsste man was läuft, was da drin eigentlich laufen müsste und wie man's neu starten kann.

Wenn während der Konferenz was “horribly wrong” geht, ist es gut einen schnellen reset zu haben. Cube aus, Cube wieder an, läuft. Leider klappt das so nicht, weil z.B. die Tracker-Scripte nicht von selbst starten. Meine Empfehlung an andere Konferenzen lautet, nach dem Aufbau alle Cubes neu zu starten und zu schauen, ob auch alles wieder hoch kommt. Sonst besser jetzt fixen als mitten in nem Talk.

GlusterFS ist geil. Quasi supergeil. Schnittnotebook in einem Raum abziehen, im anderen dranstecken, die Gluster-Mounts finden sich einfach wieder ein. Rocksolid, kein Vergleich zu NFS oder SMB.

Hab ich mit Python und RSVG gemacht und einzelne Komponenten mit Animationkurven aus dem jQueryUI animiert. Sollte sich leicht umbauen lassen, um andere Animationen (extra Logos, eine Rakete) zu animieren.

• Konferenzeinrichtung Dokumentieren → https://c3voc.de/wiki/eventhowto?&#event_einrichten
  • ggf. Scripten
• Tracker-Scripte beim Boot automatisch in Screens starten
• Verhalten der Scripte bei Netzausfall prüfen und ggf. verbessern
• Framegrabber-Videoquelle auf 25fps einstellen oder mit ffmpeg auf 25fps transcodieren

• Auphonic-Publishing-Script
• 2x WebM-Encoder Parallel erlauben
• IO-Prio der encoder-ffmpegs senken