c3voc in a nutshell - Text deutsch

Da wir uns anscheinend alle irgendwie schwer tun lange Texte zu produzieren hier mal ein anderer Ansatz: Dieser Text basiert auf dem Froscon 2015 Vortrag von derpeter und meise. Die Audiospur wurde von Barbara netterweise transkribiert. Der Videomitschnitt ist unter folgenden URLs abrufbar:

• https://media.ccc.de/v/froscon2015-1520-conference_recording_und_streaming
• https://www.youtube.com/watch?v=s6JuZ1_AGps

derpeter hat eine aktualisierte Version des Vortrags vor kurzem auch bei der MiniDebConf in Cambride gehalten. Die Folien dazu findet man unter

• http://derpeter.net/share/MiniDebConf-VOC-slides.pdf

— Andi 2015/11/08 11:39

TODOs

• restliche Bilder aus Präsentation hier einbinden soweit sinnvoll.
• Überschriften im Abschnitt Postprocessing einbauen
• Text einmal überarbeiten

–––––

Dieser Text soll einen Überblick über das c3voc Team und die dazugehörigen Projekte geben. Wir versuchen seit 2011 so viele Veranstaltungen wie möglich – vor allem CCC Events – mit Vortragsaufzeichnungen abzudecken. Der Text gliedert sich in folgende Abschnitte:

• Einführung
• Hardware
• Postprocessing
• Live streaming
• Operation
• Zukunft bzw. WiP

Zunächst wird das Team und unsere Arbeitsbereiche vorgestellt:

In Köln/Bonn bzw. St. Augustin haben derpeter und meise als das FrOSCon Videoteam angefangen. Aus München (Easterhegg 2010) kam Andi dazu und von der Gulasch Programmiernacht (GPN) in Karlsruhe stieß florolf zu uns. Erstes gemeinsames Projekt in dieser Zusammensetzung und bereits unter dem Label VOC war die Aufzeichnung der Vortäge beim CCCamp 2011.

Die Forschungsgemeinschaft für elektronische Medien (FeM) an der TU Ilmenau hatte schon seit 2005 (22C3) die Vorträge des Chaos Communication Congress als Live-Stream angeboten und mitgeschnitten. Mit dem Umzug des Congress nach Hamburg in 2012 (29C3) wurden wir auch stärker eingebunden und firmierten nun auch dort als VOC. Zum 30C3 (2013) kam die wissenschaftliche Arbeitsgemeinschaft für Studio und Sendefragen (AGS) an der TU Braunschweig, ebenfalls ein studentischer Verein, und eine weitere Einzelperson mit ins Team, die uns beide mit sehr viel Know-how bzw. auch Hardware unterstützten.

Mit dem Congress und den kleinen Veranstaltungen der lokalen CCCs sind immer mehr Leute zum Team hinzugestoßen, so dass wir inzwischen ein Kernteam von ca. 15 Leuten sind.

[TODO: Team-Bild von irgend einem Geekend einfügen?]

Wir kümmern uns in den Vortragssälen um den ganzen Audio und Videokram, sprich das die Vorträge aufgenommen, gestreamt und der Mitschnitt veröffentlicht wird. Auf großen CCC Events passiert das manchmal auch per DVB-T, DAB, FM, Teletext, DRM, etc. – was man alles so an Broadcasting Technologien findet.

Die Arbeitsbereiche lassen sich thematisch wie folgt aufteilen: AV ist alles was im Saal passiert: Kameras, Audioaufnahme und andere Saal-Technik. Leider auch mit der eingebauten Saaltechnik, die einem manchmal nicht das ermöglicht was man möchte.

Anschließend folgt Recording und Post-Processing, einer der zeitaufwendigsten Aufgaben. Nach so einer Veranstaltung liegen ein paar 100 Video Schnipsel/ Vorträge herum. Ohne entsprechende Tools verliert man ziemlich schnell die Übersicht, was jetzt eigentlich wo ist.

Live-Streaming ist der Betrieb des CDN, womit wir die Zuschauer mit Live-Streams versorgen. Operation ist die IT-Administration hinter dem Ganzen.

Weiter gibt es um uns herum eine ganze Menge Projekte ohne die das alles nicht so schön wäre. Ganz vornen weg media.ccc.de, das ist die Videoplattform von CCC die unsere primäre Publishing Plattform ist. Kommt ursprünglich aus dem CCC Köln ist aber inzwischen im VOC aufgegangen.

Dann hat sich über die letzten Jahre ein Subtitles Projekt gegründet, die zu den meisten oder zu vielen der Talks die wir machen dann Live oder kurz nach Veröffentlichung Untertitel in verschiedenen Sprachen bereitstellen.

Es gibt für das beliebte Mediacenter Kodi (früher XBMC) sowie für das Plex Media Streaming Dingsi Plugins, womit man direkt den Content von media.ccc auf seinem Fernseher schön vom Sofa aus klicken kann. Mittlerweile ist in allen möglichen Fahrplan Apps, Fahrplan bezeichnen wir immer die Konferenz-Schedules, da gibt es für das iPhone und Android mittlerweile eine ganze Menge Apps und da ist überall auch in vielen mittlerweile unser Content integriert.

Es gibt das Infobeamer Projekt, was ihr hier immer in den Pausen seht, was das ganze Coming-up und so zeigt, dass kommt aus Karlsruhe von dividuum.

Dann sind wir aktiv dabei Chaos Radio und den Berliner Datengarten immer live zu streamen und zu recorden. Es gibt das Engelssystem-Projekt. Wer hier Helfer ist hat sich vielleicht da schon eingetragen, nie, hier wird es glaube ich nicht genutzt..

Es gibt auf jeden Fall das Engelssystem wo für uns dann extra Videohelfer und solche Spezialfälle abgedeckt wurden.

TODO: Bild Wort-Wolke einbinden

Um diesen ganzen Kram zusammen zu bauen braucht man eine ganze Menge verschiedene Software. Wie ich gerade sehe ist das auch nicht die letzte Version davon, da fehlen eigentlich noch ein paar Sachen. Auf vieles davon wird Daniel nachher noch einmal eingehen, nur mal so ein Überblick, was man eigentlich, , wir hören oft: „Ach mit meinem Mac ist das ganz einfach, das macht man an und es geht. “ Wir brauchen ein bisschen mehr Software.

Hier eine Grobübersicht vom 30C3, wie das ganze technisch abläuft:

Von links nach rechts fängt es im Saal an: Dort haben wir ein bis zwei Kameras, kommt immer so ein bisschen darauf an. Auf der FrOSCon haben wir nur eine, durch die hohe Anzahl der Säle, haben wir einfach nicht genug Kameras. Die landen per SDI auf unseren Encoder Cubes. Weiterhin haben wir einen Framegrabber auf der Bühne, der die Slides mit grabbt, daraus einen IP Stream macht. Diese Signalquellen laufen auf unserem Videomischer zusammen, wird dort dann vom Video Engel gemischt: entweder Kamera, Slides oder beides per PIP oder Side-By-Side und geht von dort zum zentralen Storage, wo wir es dann weiterverarbeiten. Parallel wird das gemischte Summensignal vom Encoder Cube aus live zu unseren CDN Master Relay gestreamt.

Das ist jetzt alles ein bisschen unscharf, weil es davon sehr viele Spielarten von gibt. Da gehen wir hinterher noch etwas darauf ein.

Dann gibt es das eigentliche VOC, der Raum wo wir alle sitzen, wo wir unser post processing machen und das ganze geht dann einmal als Livestream raus auf der rechten Seite und wird dann noch einmal per FTP usw. veröffentlicht. Was jetzt noch fehlt, das gab es damals noch nicht, es gibt dann noch das Publishing über YouTube, den wir vor einem Jahr hinzugefügt haben.

Nachdem ihr jetzt so grob wisst was wir machen, gehen wir auf die einzelnen Bereiche etwas genauer ein. In diesem Abschnitt geht es zunächst einmal um die verwendeten Geräte, sprich PCs, Kameras, Mixer usw.

Was nimmt man da eigentlich so an Hardware, wir haben lange herumgeschaut, irgendwie Anforderungen bei Video ist immer viel CPU Leistung und da ein Teil der Hardware in den Sälen steht, möglichst leise Hardware. Auf dem obersten Bild seht ihr unsere Encoder cubes, die stehen hier auch neben jeder Kamera. Das sind recht potente Maschinen die dafür dann aber auch FullHD Video in Echtzeit streamen können. Neu im Grunde sind die Minions, das sind so kleine so große Bricks nennt sich das Produkt glaube ich. Ja, machen CPU-mäßig fast so viel weg wie die großen Encoder, sind vor allem für unsere Master encodings notwendig. Hier war ja jetzt leider wieder alles SD, weil wir noch keinen passenden Videomischer für HD hier hatten. Auf Events wie dem Camp haben wir alles in HD produziert, da werden dann all die Maschinen voll ausgelastet und zeitnah die Releases hinzu bekommen. Ja, und wenn man dann so Streams verteilen will braucht man auch streaming Server. Wir haben da vor zwei Jahren Xeon Maschinen gekauft, mit denen wir mit einem 10 Gb Interface so um die 8K 8000 voll HD Viewer ausliefern können. D.h., da geht schon einiges.

In den Sälen steht darüber weiterhin natürlich Kamera, haben wir eben schon gesagt, wir haben da momentan eine Panasonic und auf diesem Event ganz neu eine JVC Kamera. Das coole an der JVC Kamera ist, dass die direkt einen IP Stream, Strom erzeugen kann, sodass man sich ein bisschen Encoder Hardware sparen kann. Das ist ja noch sehr experimentell, wir hoffen damit vor allem ein Set-up zusammenzustellen was deutlich günstiger ist um es auch zum Beispiel den kleinen Erfas oder Gruppen die selber so etwas machen wollen, mal so ein Plan auszulegen, hier wenn ihr das und das kauft, das funktioniert zusammen und das ist nicht so unendlich teuer.

In jedem Saal gibt es eben die Info Beamer, haben wir eben schon darüber gesprochen, wir haben nicht Laptops, das ist das wo die ganzen Engel immer daran sitzen, wo Live das Bild gemischt wird. Um mit den Videoengeln zu kommunizieren haben wir in jedem Raums-IP Telefone stehen. Dann braucht man zwingend notwendig eine Winkelkatze, die ist sogar wirklich notwendig, denn wenn man die Tests macht und der Raum leer ist, dann kann man sich leicht einbilden, dass alles funktioniert, in Wirklichkeit hat man ein Standbild, daher stellen wir immer die Katzen auf die Bühne um sicherzugehen, dass es auch wirklich ein kontinuierliches Idiot ist. Und wie man sich denken kann kiloweise die absurderen Video- und Audioadapter in alle Richtungen, weil so Hausanlagen alle anders sind und alle anders funktionieren, wenn sie funktionieren.

Framegrabben ist eigentlich die Königsdisziplin des ganzen, weil die Leute kommen mit den verschiedensten Notebooks, muss man sagen die Macs sind eigentlich ganz handlich, weil die sich alle gleich verhalten. Linux Desktops verhalten sich generell alle unterschiedlich und Hausanlagen sind dann noch einmal ganz speziell. Solange man nur den Beamer hinten dran steckt, ist alles gut, aber so Anlagen wie hier möchten ganz bestimmte Auflösungen mit ganz bestimmten Herzraten… Naja, jedenfalls muss das dieser Framegrabber alles leisten, er muss dafür sorgen, dass der Speaker auf seinem Laptop die richtige Auflösung auswählt und keine andere, er muss dafür sorgen dass wir die Slides überhaupt bekommen, d.h. er muss verstehen was dort ankommt und im optimalen Fall das Bild dann auch wieder herausgeben, loop through damit die Anlage es versteht. Dazu kommt dann noch so etwas wie, heutzutage findet man fast überall mehr und mehr HDMI in den Fällen, die Speaker kommen aber durchaus noch mit VGA Laptops, was man, zumindest der obere Grabber auf dem Bild dann sogar adaptieren kann. Bei anderen Grabbern muss man dann oft noch irgendwelche Stunts machen. Wir haben dieses Mal jetzt auch noch Videoscaler ausgeliehen, weil wir nicht genug von den Grabbern haben. Die stammen von der FOSDEM. Das ist dann ein reiner SDI, HDMI to SDI Converter und davor steht so eine lustige China Kiste die so all to HDMI konvertiert, das ist das was ihr in den Räumen sieben und acht gesehen hat. Das funktioniert so mäßig, aber weder unser Grabber noch diese Lösung sind wirklich schön. Wenn man richtig viel Geld hat kann man sich so Scanline-Converter ausleihen, zum Beispiel von Roland oder Barco. Die machen das dann ganz ordentlich solange niemand zwischendurch von 4:3 zu 16:9 wechselt, dann ist auch wieder alles Tränen.

Die zweite große Frage: wie mischt man eigentlich Videobild? Da gibt es eben den Ansatz Software. Wir haben dieses Jahr auch wieder und auf der FrOSCon bisher immer DVSwitch eingesetzt, das ist ein Open Source Tool, was von der DebConf kommt, von den Debian Leuten. Eigentlich eine super tolle, super stabile Software, krankt aber daran, dass dabei auf SD Videoschluss ist, da sie auf raw DV Video aufbauen, das gibt es eben nur in SD und wenn man dann zu HD möchte muss man sich eben überlegen, was nehme ich für einen Container. Da bietet sich dann so etwas wie MPEG TS an. Da müssen dann direkt wieder viel mehr CPU darauf geworfen werden. Alles sehr schwierig, deshalb haben wir bisher, wenn wir HD produziert haben auf geliehene kommerzielle Video Switcher zurückgegriffen, das waren bis jetzt immer verschiedene Television Studio Versionen von Black Magic oder von Panasonic die MX100. Das sind schöne Geräte, aber Kosten richtig viel Geld und ist eben für jemanden, der sagt er möchte mal eben ein Video Set-up bauen eigentlich keine Option und für uns auch nicht, bei Black Magic ist eben ein Programm, man hat eine schwarze Box auf dem Tisch und die macht irgendetwas. Weder Firmware noch sonst irgendetwas ist Open Source oder dokumentiert, es gibt da manchmal so ein bisschen API, manchmal aber auch nicht und da möchten wir eigentlich, hoffen wir bald, mit einer Alternative fertig zu sein, kommt dann im Ausblick.

TODO: Folie war beim Froscon Talk noch nicht drin.

Wir sind nun bei Recording gelandet. Das Ganze funktioniert so, bei Recording meine ich jetzt das was an Video rein kommt, wir haben SDI Grabber Karten in unseren Cubes, da kommt das Video von der Kamera bzw. wenn man einen Bettwäsche davor hat, vom Bildmischer rein. Ein gepatchter ffmpeg ließt die Daten von der Grabber Karte und schreibt 3 Minuten lange MPEG TS Schnipsel weg. Hier, zweite Spalte legacy, hier machen wir es noch in DV gerade, aber normalerweise ist das mittlerweile immer mpeg TS. Von da aus ziehen wir uns das dann aus den Sälen zu unserem zentralen storage. Wir haben einmal versucht das anders zu machen und den Kram direkt aufs dadurch zu ziehen, das ist eine total dumme Idee, immer lokal im Raum aufnehmen, denn wenn das Netz wackelt, habt ihr sonst kein Recording. Dort läuft fuseTS, das ist ein Fuse Dateisystem, was auch die Kollegen von der FEM geschrieben haben, was zusammen mit den Daten aus dem Fahrplan uns aus diesen einzelnen 3 Minuten Chunk virtuelle Videodateien erzeugt, die genau das Stück sind was der Fahrplan denkt, was ist der Talk.

Die Speaker machen manchmal ein bisschen länger, mal ein bisschen kürzer, das kann man dann wieder anpassen, und dann macht das FUSE File System dann wieder etwas Neues. Dazu gibt es dann auch gleich noch ein bisschen mehr und dann kann man.. Das viertens File System erstellt dann dazu einen Kdenlive Projekt File. Kdenlive ist ein aus dem KDE Umfeld Videoschnitt Tool. Alternative kann man mittlerweile auch Shortcut benutzen, weil wir ein paar Leute haben die unter Mac OS schneiden wollten. Da gibt es kein Kdenlive. Das schöne ist, man öffnet dann einfach das Projekt File von dem Video das man bearbeiten möchte, von dem Talk den man bearbeiten möchte, setzt Anfang und Endzeit, dass dieses Filesystem weiß dann über den.. weiß dann das es sich geändert hat, macht einmal einen neuen FUSE-Mount und indem ist dann der Talk, wie man ihn geschnitten hat, mit Vorspann, Abspann und allem. Man kuckt noch einmal ob alles gut ist und kann dann auch dieses virtuelle File einfach direkt den Encodern vorsetzen, die daraus dann die Releases machen. Genau, so sieht der Tracker aus, habe ich hier noch mal ein größeres Bild. Das ist die Software die die Worker, die das FUSE steuert. Es ist ein komplettes Ticketsystem, was zu jedem Tag, hier zum Beispiel die Überschrift mit der Zeile daneben, das ist das Master-Ticket, da steht der Votragsname drin und das sieht man jetzt darunter, es gibt die Aufgabe Recording, das eigentliche Aufnehmen des Videos, dann darunter verschiedene encodings Tickets, die kann man einfach beliebig hinzufügen.

Wenn wir jetzt sagen, o. k. wir möchten unseren Releases irgendwie mp3, WebM, vorbis, opus und sowas haben, dann klickt man sich so ein Encodingprofil zusammen, man sagt ich hätte gern folgende Auflösung, ich hätte gerne folgenden Videocontainer, die Metadaten da rein usw. Wenn man das Profil einmal definiert hat, das ist ein XML File, kann man es in der Zukunft in neue Projekte, wie jetzt die FrOSCon, einfach rein schieben und sagen o. k., folgende Subformate sollen für das Releasing erzeugt werden und der Tracker kümmert sich dann darum, dass die angelegt werden und kleine Worker Skripte die momentan in Perl und Python geschrieben sind können sich diese encoding Jobs abholen, encoden das ganze mittels ffmpeg, sagen dem Tracker Bescheid, o. k. ich habe es encoded, dann sagt der Tracker: Okay, lieber VOC Mitarbeiter, schau es dir mal an ob alles in Ordnung ist und wenn alles in Ordnung ist wird das ganze dann veröffentlicht.

Hier sieht man dann noch mal unten am Rand, das sieht man auch direkt welche Worker gerade ein File encoden. In diesem Fall sind das unsere Encoder in der Cloud. Mit HD wurde es langsam schwierig alle Releases auf dem Event zu encoden, man müsste echt viel Rechner hierher schleppen. Deswegen können wir dankenswerterweise im momentan auf einen großen ESX Cluster zugreifen, der im Internet steht, dort nutzen wir gerade sechs VMs mit jeweils zwölf Xeon CPUs und die rechnen dann schön alle Subformate. Leider ist WebM immer noch ein bottle neck, weil das nicht multithreadet, da kann man so viele CPUs gegen werfen wie man will. Das ist auch unser großes Problem, die WebMs dauern immer länger.

Wenn dann alles encodet ist, dann wird es gepublisht: Wie gesagt unsere primäre Plattform ist media.ccc.de, wir publishen mittlerweile aber auch auf YouTube, zum einen weil der Kram sowieso auf YouTube landet und dann lieber von uns mit richtigen Metadaten und richtiger Lizenz, als wenn irgendjemand das macht. Zum anderen aber auch weil viele Leute Endgeräte haben in denen ein YouTube Client eingebaut ist, aber leider kein media.ccc.de Client. Das müssten dann die Anwesenden hier noch ändern und noch ein paar mehr Clients programmieren. So sieht das dann bei media.ccc.de im Backend aus. Die Software dafür ist auch auf Github, könnt ihr euch auch einfach alles selber aufsetzen, naja einfach aber, könnt ihr euch selber aufsetzen. Dort teilt man das ganze in Konferenzen ein und legt dazu Events an. Es hat auch eine API, wir machen das natürlich nicht von Hand sondern unsere Skripte machen das gegen die API von media.ccc.de und dort hinterlegt man einfach alle Metadaten die man zu einem Talk haben möchte, klickt dann auf publishing und dann sieht das ungefähr so aus. Das sind jetzt, ein Event ist quasi eine Veranstaltung und das sind jetzt quasi alle Veranstaltungen die zu dem Zeitpunkt zu dem ich den Screenshot gemacht habe zuletzt releast wurden. Die Liste ist mittlerweile ziemlich lang und sobald das dadurch ist landet es dann im Frontend und ihr könnt das auf der Webseite anschauen. media.ccc.de generiert dazu direkt auch Torrent Files und ist selber das CDN dahinter, Webseed für die Torrents. Das ganze CDN selber sind drei Server die uns gehören plus eine ganze Menge Uniserver die auf ihren FTP es Platz spenden, dazu wird Daniel glaube ich noch was sagen.

Gerade im CCC Umfeld ist, sind die Anzahl der Veranstaltungen in den letzten Jahren so dermaßen explodiert, dass man es eigentlich überhaupt nicht mehr schafft auf allen Veranstaltungen vor Ort zu sein, trotzdem gibt es immer wieder Talks die dann doch interessant sind und vielleicht hat man dann zu Hause doch noch Zeit sich ein paar Talks anzuschauen um nicht auf die Releases warten zu müssen und dafür machen wir eigentlich live streaming.

Für uns ist das in unserer derzeitigen Konfiguration die derpeter ja schon vorgestellt hat eigentlich nur eine weitere Quelle die wir im Prinzip aus dem Videomischer ziehen, das livestreaming fällt bei uns derzeit einfach so ab. wenn Recording das Mixing und alles irgendwie aufgebaut ist, dann ist dein Livestream zu machen nicht mehr so der große Aufwand, das meiste encoding für das livestreaming passiert auf besagten Encoder Rechnern hier direkt im Saal. Für WebM ist das noch mal eine ganz andere Nummer, weil die derpeter schon sagte ist das so ein bisschen CPU bound und das threadet nicht vernünftig und da braucht man ziemlich viel Gigahertz um da wirklich das dann auch in Echtzeit machen zu können, gerade wenn es um HD geht ist das eigentlich, da müsste man extrem viel Hardware wirklich ankarren um das in unterschiedlichen Formaten dann auch machen zu können.

In den letzten Jahren hat sich irgendwie herauskristallisiert, dass es für uns am besten ist, dass wir Livestream für die Clients in WebM oder hls anbieten. WebM ist letztendlich ein Container in den man Open Source oder Lizenz günstige Codecs letztlich fahren kann und der Vorteil bei uns vor allem ist, dass viele Clients das per Default ohne zusätzliche Plugins Flash usw. einfach abspielen können. Wir machen HTTP Live Streaming vor allem für Apple und Android Geräte und für die interne Verarbeitung von einem streaming Relay zum anderen benutzen wir RTMP und dass letztendlich dieser Strom, dieser RTMP Strom ist dann letztendlich die Basis eben für das hls oder auch für das WebM.

Dadurch dass wir wirklich nur noch letztendlich HTTP verwenden als Übertragungsprotokoll zu den Clients verwenden wir als balancing Methode, oder als balancing Software haproxy, der kann hervorragend mit HTTP umgehen und da kann man dann relativ dynamisch Redirects machen oder man macht einen Proxy und das funktioniert für uns hervorragend.

HTTP only ist eben gerade für uns auch ganz wichtig, weil die Clients, jeder hat letztendlich mehrere unterschiedliche Devices und HTTP ist eigentlich so das was eigentlich fast alle sprechen und damit ist das für uns auch nicht so, der Support dafür ist deutlich besser am Endgerät.

• Encoding stream has the rightTM encoding already
• nginx-RTMP generates playlists and divides MPEG-2 TS streams into fragments

ffmpeg -re -f mpegts -i RTMP://encoder.cube/stream \
  -c:v:0 libx264 -c:a:0 libfdk_aac \
  -b:a 96k -ar 44100 -f flv RTMP://hls.streaming.master 

HLS ist letztendlich für uns auch relativ, auf den Cubes laufen letztendlich die Encoding Jobs für..??? wir generieren für HLS, ist letztendlich ein Abfallprodukt der RTMP-Streams die wir eben für die interne Weitervermittlung machen und der Codec der in diesem RTMP Strom ist den können wir direkt weiterverwenden für HLS, das ist in diesem Fall h264 und für Audio aac und was wir für HLS letztendlich machen müssen sind Playlisten generieren und wir müssen entsprechende Chunk die in den Playlisten referenziert werden generieren und das machen wir mit nginx RTMP, das ist ein Nginx Modul was man für den Nginx baut und der kann sowohl die Playlisten generieren, als auch die entsprechenden Chunk erstellen und wie schon gesagt, das wird hauptsächlich von Apple Geräten verwendet. Ich habe da unten mal so eine ffmpeg Zeile gecopy und pastet, das ist relativ simpel und was wir letztendlich machen ist einfach nur zu sagen: naja für Video verwende ich libx264 und nimm aac für Audio und setzt da noch ein paar Parameter. 96 kb für Audio und dann passiert das eigentlich so halbwegs vollautomatisch.

• (single) CPU bound
• Destination streaming server: Icecast 2
• Plays natively an „up to date“ browser

ffmpeg -re -y -i RTMP://... -threads:0 0 \
  -c:v libvpx -g 75 -keyint_min 75 -deadline realtime \
  -b:v 2800k -maxrate:a 96k \
  -c:v libvpx -c:a libvorbis -f WebM - | \
mse_WebM_remuxer -cm 2000 - - | \
oggfwd -w icecast.streaming.master 8000

Vergleichbar ist das mit WebM, wie gesagt das ist CPU bound. Für das Streaming vom WebM verwenden wir Icecast, das ist extrem stabil und funktioniert hervorragend unter niedrigsten Bedingungen. Der Vorteil vom WebM ist letztendlich spielt in allen modernen Browsern. Auch hier noch einmal die ffmpeg Zeile. Für HD verwenden wir betraten von, sodass am Ende ungefähr drei MBit herauskommen, wir müssen ja letztendlich keine Filme oder Actionmovies übertragen, das sind drei Mbit vollkommen ausreichend für HD.

(Unverständliches aus dem Publikum)

Die Frage war wie das eigentlich mit dem thread Parameter ist, den man ffmpeg angeben kann. ffmpeg muss man dazu sagen ist in gewisser Weise bei bestimmten Optionen sehr penibel an welcher Stelle sie stehen im Kommandaufruf und das Problem war bei WebM, dass nur bestimmte Teile des encoding Prozesses multithreaded sein können. D.h., dass hängt eben auch ganz stark vom Content ab, der da rein kommt und nach unserer Erfahrung bringt das nicht so viel. man kann das irgendwie setzen, diesen Threadparameter aber in der Regel, in der Regel kann ffmpeg eben doch automatisch schon erkennen wie viel CPUs habe ich eigentlich, nutze ich die dann alle oder nicht. Wir haben auch schon diverse Tests gemacht um wirklich perfekten, boah jetzt threaded der wie bei h264 über alle möglichen Kerne. Ja, das geht bei WebM leider nicht so schön. die libvpx ist da nicht so toll. Wir verwenden da auch letztendlich VP8 für die Livestreams, aktuell ist ja VP9, aber die Implementierung dafür ist bei weitem nicht production ready und für uns nutzbar. Wir hatten auch in letzter Zeit Erfahrungen gesammelt mit entsprechender Hardwareencoder die WebM teilweise in Hardware encoden, aber die Ergebnisse davon waren auch eher ernüchternd. nicht nur dass die Qualität geringer ist, auch das Handling, wie man damit der CPU spricht ist nicht so optimal.

unser Setup, was ich gerade vorgestellt habe, zusammen mit dem haproxy, nginx RTMP und Icecast das scalt auch in großen Installationen wie jetzt zum Beispiel auf dem Chaos Communication Congress. Das ist eine klassische CDN Infrastruktur. Diese roten Punkte sind letztendlich sogenannte Master-Server wo keine Clients darauf connecten und damit verteilt man erst einmal eine breite Anzahl an Streams. Die entsprechenden grünen Blubbel hier sind edge relays wo letztendlich wirklich die Clients darauf connecten. Sieht man das? Ja sieht man. [unverständliche Zwischenfrage]

Das ist gut skalierbar. Das was ihr jetzt hier seht ist zum 31C3 gelaufen. Da hatten wir Peak 10GBit an Zuschauern – über sehr viele Server verteilt. Die Anzahl der Server war aber auch hoch, weil wir wissen nicht wie viele Leute dieses Jahr wirklich schauen. Die wirkliche Limitierung ist die Netzwerkkapazitat. Das Schubsen der Daten braucht man nicht so viel CPU und nur wenig Speicher – je nach dem was man machen will.

Bei ReLive ist das schon wieder etwas anders. Es kommt darauf an wie viel Speicher meine Kisten so haben, damit nicht permanent von der Platte gelesen werden muss, aber dazu kann ich gleich nochmal etwas sagen.

ReLive ist dadurch entstanden, dass wir vermehrt festgestellt haben, dass Leute unsere Live-Streams mitschneiden und die dann schon mal so, „naja ich schneide das jetzt mal mit und hau das mal schon mal auf YouTube“ oder so und das hat letztendlich zur Folge, dass sehr viele halb-fertige, ohne Lizenz veröffentliche Vorträge im Internet aufzufinden sind. Letztendlich ist das auch schwierig die dann wieder da wegzubekommen.

Viele Vortragende stellen dann am Ende doch fest „oah jetzt habe ich da doch etwas gesagt, das wollte eich eigentlich gar nicht sagen, jetzt ist das im Internet“. Das ist so oder so schwierig, aber um da eben auch die Möglichkeit zu haben im Zweifelsfall wirklich das nochmal zu löschen haben wir eben gedacht, naja vielleicht können wir ja selbst Streamdumps bereitstellen. Dann haben wir was gebaut, was letztendlich diese HLS Schnipsel – von denen ich eben schon erzählt habe – intelligent, im Sinne von „Ich nehme schon die Daten die sowieso aus dem Fahrplan kommen und bereite die so auf, dass man die auch auf der Streaming-Webseite direkt pro Talk als Playlist bekommt um sich dann anschauen kann. Das hat so ein paar negative Aspekte auch, unter anderem, wie auch schon gesagt, HLS ist eben eher so bei Apfel Geräten vertreten. Wenn man das auf einem Linux Rechner schauen will, braucht man einen Flash- oder eben einen VLC-Player.

Dazu vielleicht auch noch der Hinweis: Teile unsere Software sind leider nur so ein bisschen Pseudo-Open-Source. die Software die das ReLive implementiert ist derzeit nicht veröffentlicht, weil das wirklich Software ist wo man noch Zeit investieren müsste um die.. um die eben veröffentlichen zu können, dass sie auch einfach von jemand anderes verwendet werden kann. Nichts desto trotz, wer daran Interesse hat, sich das ankucken will, die Software haben will, kann gerne auf uns zukommen, wir helfen da gerne und geben die dann auch raus, aber so ein bisschen Disclaimer, so ein paar Sachen, ist eben schwierig die zu veröffentlichen, weil da eben wirklich auch Zeit sein muss, wo dann auch Zeit zur Verfügung stehen muss, um das vernünftig unter die Massen zu hauen.

Eine ganze Menge Kisten, ihr habt das jetzt am CDN gesehen für das Post Processing usw. brauchen wir sehr viele Server, sehr viele Informationen und wir wollen eben auch auf dem Event nicht völlig am Rad drehen und dafür haben wir uns ein paar Sachen gebaut, unter anderem einen Notification Bot für das IRC. sehr viele Sachen organisatorisch laufen bei uns über das IRC ab und dafür haben wir uns „viri“ gebaut der auf MQTT-Basis funktioniert und da gibt es eben unterschiedliche Consumer, Provider.

Consumer sind Clients, die sich eben auf diesen MQTT-Channel hängen können und dann mitlesen können und wenn da irgendetwas interessantes dabei ist, kann man da so eine notifications bekommen.

Provider, wir haben zum Beispiel solche Sachen, das sieht man hier, hier rechts, dieses Fahrplan Warning, wir Pausen eben den Fahrplan und sobald ein Tag ein Opt-Out hat bekommen wir eine notification dafür. Das hilft uns extrem dabei, dass nicht permanent im Kopf zu behalten, sondern einfach zugucken, ja diese Software erinnert mich daran, wann ich jetzt einen Stream aufschalten muss, oder jetzt sagen muss, jetzt mal bitte nicht recorden. Weiterhin haben wir sehr viele Events in den letzten Jahren dazu bekommen, wir haben jetzt einen Eventkalender, wo eben alles darin steht, da bekommt man unterschiedliche Feeds, ich habe das auch unten verlinkt, wenn ihr immer upzudaten sein wollt wo wir sind, dann könnt ihr da ein iCal Feed euch abonnieren.

Je mehr Kisten man hat umso weniger will man da manuell schauen was geht da eigentlich gerade ab. Wir setzen darauf Icinga und auf Graphite. Kann man sich schöne lustige Graphen zusammen malen. Wer da Interesse hat an den Configs usw. kommt auf uns zu.

Full HD Video mischen ist ein Herausforderung: Es gibt ein - zwei Open Source Lösungen die sich dem Problem schon gewidmet haben. Allerdings ist es bei Video immer, das macht man dann so an und dann sieht das irgendwie toll aus und dann guckt man am Ende des Tages noch einmal rein und stellt fest, dass es Audio leider komplett asynchron gelaufen ist und da gibt es dann auch so Effekte, die ich technisch gar nicht so richtig erklären kann. es ist nicht damit getan das Audio zu verschieben sondern, die Zeitvorstellungen verschiedener Audio und Videoquellen sind einfach unterschiedlich. Es gibt da, Quarze sind unterschiedlich schnell, Timestamps sind, manche Leute haben da andere Vorstellung was ein Timestamp denn sein könnte und das führt eben bei allem was wir uns bisher angeschaut haben eigentlich dazu, dass man es, man könnte das eben nach jedem Tag neu starten, am besten alle Geräte und dann hätte man die Chance, dass es irgendwie geil ist.

Aber letztendlich haben wir nichts gefunden, was funktioniert und dann hat sich einer aus unserem Team netterweise an den Rechner gesetzt und angefangen voctomix zu programmieren, das ist jetzt noch der Arbeitstitel, ob die Anwendung hinterher so heißen wird.

Eigentlich hatten wir vor sich hier einzusetzen, da es aber doch noch sehr alpha ist, haben wir uns dann entschieden SD auf bewährtem Set-up zu machen. Was es ist, es ist eine, letztendlich eine gstreamer Pipeline auf Basis von gstreamer 1.5 geschrieben, der Glue-Code ist in Python und benutzt natürlich auch ffmpeg, wie alles andere bei uns. Es ist eine kleine Serverarchitektur, d.h. man hat ein UI was man zum Beispiel auf dem Mischer Laptop laufen lassen kann, der letztendlich außer das Userinterface anzuzeigen nichts tun muss, wo aber die eigentliche Arbeit, das eigentliche Video switchen auf einer Kiste passieren kann die viele CPUs hat, wie in diesem Fall unsere Encoder cubes. Größenordnung da ist bisher so in den Tests, sieht es so aus als ob wir momentan auf einem aktuellen I7 in der höchsten Ausbaustufe Full HD switchen und streamen können, dann ist die Kiste aber auch komplett dicht.

Das was bei professionellem Videoequipment der SDI Port ist, ist in diesem Fall dann ein TCP Socket und letztendlich kann man jetzt schon und wird noch besser werden alles an Videomaterial, was man eben irgendwie in IP verpacken kann dem Ding zu werfen und nach ein paar gstreamer Patches die, oh wer hat die gemacht? Mithro oder? Ich glaube ich hatte es zuerst von einem anderen Videoprojekt aus Kanada mitgemacht wurden, von TimVideos. Sieht es jetzt so aus, dass das ganze auch synchron bleibt. Der Kram liegt jetzt schon auf Github, ist noch nicht so richtig, wie Daniel gerade sagt de, viele unsere Software funktioniert eben für uns, es müsste mal jemanden geben, der sie packagt, der sie mit ausgiebiger Doku versieht und sie vielleicht auch einmal nicht in unserem usecase testet, das sind sicherlich noch eine ganze Menge Sachen glatt zu bügeln, aber da freuen wir uns auch sehr über Leute die es einsetzen und ausprobieren wollen.

Ja das ist auf jeden Fall die Zukunft: HD-Video mischen auf der CPU mischen mit freier Software.

Das leidige Problem des framegrabben hatte ich auch eben beschrieben, alle Framegrabber die es gibt sind komplett closed Hard- und closed Software und auch da gibt es aus der Richtung der TimVideos-Leute: Das hdmi2usb Projekt. Ich erzähle jetzt nur was man mir darüber gesagt wurde, richtig Ahnung habe ich davon nicht. Der Entwickler sitzt auch dort oben. Da ist eben auch die Idee auf einem FPGA Board, wenn ich es richtig verstanden habe mittlerweile sogar Opernhardware ist, HDMI in und out selber zu machen inklusive der Kommunikation mit dem Beamer. das was man so unter, wenn man im Videobereich unterwegs ist, EDID. EDID ist letztendlich eine I2C-Geschichte worüber sich Beamer, Laptop und was man sonst noch so dazwischen steckt unterhalten und das muss man eben mal in die eigene Hand bekommen, weil diese ganzen Kisten die man kaufen kann funktionieren einfach nicht. Da wären glaube ich auch noch Entwickler gesucht, die sich mit VHDL und ähnlichem auskennen, ist aber auch schon sehr weit das Projekt, funktioniert alle schon so weit, wir hoffen dass auch das in dem nächsten Jahr in unser Standard Set-up einfließt und die ganzen anderen Black Boxen weg fliegen. Das würde einfach so unendlich viel einfacher machen.

Das ist zweimal, die Streams haben eine deutlich geringere Qualität vom Encoding Profil her und eine geringere Bandbreite als die finalen Releases, der Stream hat wie Daniel eben gesagt hat so um die 3 MBit und ist eben ein streaming Profil. Die Release Files haben, was haben die, ich weiß es gar nicht auswendig, eine deutlich höhere Qualität. Das ist auch ein Grund warum wir diese Streamdumps nicht so gern mögen, weil die Streamdumps sehen einfach schlechter aus als die finalen recordings, sie spielen nicht auf allen Geräten, weil die Profile eben für Streams ausgelegt sind und nicht für Player. Das was wir als Releases releasen funktioniert unserer Erfahrung nach auf so ziemlich allem was irgendwie h264 abspielen kann, das ist bei Streams nicht immer genauso.

• https://c3voc.de ist unsere Webseite, unter https://c3voc.de/wiki findet ihr unser Wiki. Da ist, das Wiki ist aufgeteilt in öffentlich und privaten Bereich, das geht da weniger darum dass wir Leuten die Information vorenthalten wollen, als dass da dann auch zum Beispiel auf Events auch einmal Configs oder Passwörter temporär stehen. Sprich, wenn ihr da irgendwo merkt ihr steht vor einer Wand, dass eine Information dir haben wollt, die ihr haben wollt, die nicht da ist, dann ist das vermutlich keine Absicht. Einfach eine Mail schreiben.
• https://github.com/voc Wir haben auch eine Github Seite wo unsere öffentlichen Repositories alle hin gemirrort sind und dann gibt es noch mal das Github Reposetory vom CCC Köln,
  * https://github.com/cccc wo ihr zum Beispiel den Code für media.ccc.de findet.
• https://twitter.com/c3voc und https://twitter.com/c3voc_releases
• Wenn ihr mal hallo sagen möchtet, auf hackint.eu, dem IRC Netzwerk der Wahl findet ihr uns in #voc-lounge. Könnt ihr gerne vorbeischauen, wenn ihr Fragen habt.