Alugha encodiert Videos in die Champions League

Zu Beginn von alugha hatten wir einen Server und dieser erledigte seinen Dienst. Hier und da wurde ein Video encodiert, doch irgendwann kam der Punkt, an dem wir erste Performance Probleme hatten und lagerten daher die Entwicklungsumgebung aus. Es wurden immer mehr Funktionen und Videos. Von 1-2 kurzen Videos die Woche zu 1-2 am Tag. Von 3-5 Minuten je Video zu 20 Minuten oder gar ganze Spielfilme. Nachdem wir immer wieder Performance Probleme hatten, mussten wir uns etwas überlegen. Wir brauchten eine Strategie, die sich sehen lassen konnte. Schon von Anfang an wollen wir unser Produkt stetig optimieren und unsere User damit glücklich machen. 

Was haben wir also getan? Wir haben alles, was wir 2016 gebaut hatten, sehr kritisch begutachtet und festgestellt, dass wir für den nächsten großen Ansturm so nicht weitermachen konnten. Hier musste was komplett neues her.

Schauen wir uns mal die einzelnen Bereiche an, welche wir von Grund auf neu implementiert bzw. optimiert haben:

Formate Input/Output

Die Menge an Aufnahmegeräten, mit denen man Videos aufnimmt, scheint schier unendlich zu sein. Es gibt Leute, die noch heute mit dem Amiga oder Atari Falcon arbeiten. Manche haben ein älteres Mobiltelefon, andere ein hochmodernes iPhone. Dann gibt es die, die vor vielen Jahren ein erstes Archiv angelegt und mit DivX, XviD oder MPEG1 gearbeitet haben. Wir könnten diese Liste so weit fortführen, dass wir in der Tat locker auf 150 oder mehr Videoformate kommen könnten. Genau dies ist eine große Herausforderung, denn während der eifrige Filmemacher sein Video auf seinem Gerät anschauen kann, bedeutet das noch lange nicht, dass eine Videoplattform (in dem Fall unsere) damit auch etwas anfangen kann. Wir müssen also dafür sorgen, dass wir möglichst viele Formate bedienen können. In der Regel decken wir sehr viele bekannte Formate ab, wie z. B. MP4, AVI, MOV, MKV, HLS, MPEG‑2 (TS & PS), MXF, ASF, ProRes, XDCAM, DNx, MPEG1, M4A, M4V, F4V, F4A, M4B, M4R, FLV, VOB, 3GP, 3GP2, um nur einige zu nennen... Sehr selten kommt es vor, dass wir ein Video nicht so verarbeiten können, dass es den Schritt zum Encoding schafft.

Warum müssen wir eigentlich das Video encodieren und was kommt dabei heraus?

Stell dir vor, du hättest ein altes Nokia mit dem du filmen könntest.... Oh ja, lange ist es her mit den guten alten Geräten, die eine Woche Akkuleistung hatten. Ich habe so ein Gerät nicht und damit ist es recht unwahrscheinlich, dass ich das Video anschauen kann, wenn es online in dem von Nokia bereitgestellten Format ist. Das ist einer der Gründe, warum wir das Video enkodieren müssen. 

Die Welt könnte so einfach sein, ist sie aber nicht, weil jeder Hersteller seine eigenen Ideen verfolgt. Mit der Zeit haben sich wenige Formate deutlich durchgesetzt. Die heute bekanntesten und am meisten genutzten Standards für adaptives Streaming sind MPEG DASH und HLS. Während wir vorher HLS MPEG TS genutzt haben, enkodieren wir heute in ein "fragmented MP4".

Jetzt wird's cool: Wir lieben es, die Dinge ständig zu optimieren und dabei so grün wie möglich zu arbeiten. Durch das fragmented MP4 können wir heute HLS und MPEG DASH in der gleichen Video-Datei verwenden. Hierdurch können wir nach dem Enkodieren sicherstellen, dass beide Formate (und damit der Zugang zu sehr vielen Endgeräten) gleichzeitig und sofort zur Verfügung stehen. Und nicht nur das! Wir konnten hierdurch die Videos um bis zu 60% in der Größe reduzieren und damit den unnötigen Verbrauch von Speicherplatz dramatisch verringern. Der Clou dabei: Die Qualität wird nicht beeinträchtigt!

Performance

Ja, das ist so eine Sache... Wie schnell kann man eigentlich so ein Video enkodieren? Performantes Enkodieren war bis zu diesem Update bei uns nicht ernsthaft vorhanden. Wir haben 5 Videos gleichzeitig in die Pipeline übertragen und dann diese nacheinander abgearbeitet. Da es auf unseren Standard-Servern stattfand, welche wir in keiner Weise dafür optimiert hatten, konnte es durchaus vorkommen, dass man 3-5h warten musste, bis das letzte Video fertig war. Dies war besonders stark davon abhängig, welche Videos in der Pipeline waren. 

Nach dem Update können wir tausend und mehr ganze Spielfilme in HD-Qualität gleichzeitig enkodieren! Wir prüfen dabei die Computer-Cluster, die wir weltweit dafür haben, und entscheiden, wo gerade am meisten Leistung bereitsteht und schieben das Video verschlüsselt dorthin, enkodieren es und holen es wieder zurück in den Object-Storage, wo es dann wieder für den User bereitsteht. Hierbei haben wir eine Encoding-Rate von ca. 10 : 1. Ein Spielfilm in 1080p (FHD), mit einer Länge von 90 Minuten steht dann also in unter 10 Minuten in allen Formaten und Auflösungen, die wir anbieten, bereit und können sofort veröffentlicht werden. Dabei fragen wir auch mehrfach den Status des Vorgangs ab und können genaue Angaben zum Encoding-Status eines Videos machen.

Sicherheit

Die Sicherheit ist ein großes Thema für uns. Viele unserer Nutzer nutzen alugha besonders in Kombination mit dem dubbr und für interne Schulungsvideos oder für (Spiel-)Filmprojekte und Serien. Wenn also ein Video auf alugha hochgeladen wird, möchten eben diese Anwender oft absolut sicherstellen, dass keiner darauf Zugriff hat. Besonders dann nicht, wenn wir die Daten zwischen den Encoding-Boxen hin- und herschieben. Daher werden die Videos auf beiden Seiten verschlüsselt, um den sicheren "Transport" zu gewährleisten.

Fazit

Encoding war eine unserer ganz großen Baustellen und wir haben uns absichtlich Zeit gelassen. Wir haben über die Jahre viel Erfahrung sammeln und diese in die Planung einfließen lassen können. Wir haben uns die letzten 12 Monate massiv mit dem Thema auseinandergesetzt und beim Implementieren gleich noch viele kleine Fehler ausgebessert und Lücken geschlossen. Dies ist das Tor in eine komplett neue Liga für uns und war einer der ganz wichtigen Bausteine, um unseren Kunden einen noch viel besseren Service anbieten zu können. Aber... nach dem Spiel ist vor dem Spiel! Wir haben noch einiges auf der Roadmap zu diesem Thema!