🥇Wie wir die Videokodierung um das Achtfache beschleunigt haben

Jeden Tag schauen Millionen von Zuschauern Videos im Internet. Damit ein Video jedoch verfügbar wird, muss es nicht nur auf den Server hochgeladen, sondern auch bearbeitet werden. Je schneller dies geschieht, desto besser ist der Service für die Nutzer.

Ich heiße Askar Kamalov und bin vor einem Jahr zum Team der Videotechnologien von Yandex gestoßen. Heute möchte ich den Lesern von Habr kurz erzählen, wie wir durch Parallelisierung des Kodierungsprozesses die Auslieferung von Videos an die Nutzer erheblich beschleunigen konnten.

Dieser Beitrag richtet sich in erster Linie an diejenigen, die sich bisher nicht mit den Vorgängen hinter Videodiensten beschäftigt haben. In den Kommentaren können Fragen gestellt und Themen für zukünftige Beiträge vorgeschlagen werden.

Einige Worte zur Aufgabe selbst. Yandex hilft nicht nur dabei, Videos auf anderen Seiten zu suchen, sondern speichert auch Videos für die eigenen Dienste. Sei es eine Autorenproduktion, ein Sportereignis im Stream, ein Film auf KinoPoisk oder Clips in Zen und Nachrichten – all das wird auf unseren Servern hochgeladen. Damit die Nutzer die Videos ansehen können, müssen sie vorbereitet werden: in das erforderliche Format konvertiert, ein Vorschaubild erstellt oder sogar durch Technologien verarbeitet werden. DeepHD. Eine unprepared Datei nimmt einfach Speicherplatz ein. Dabei geht es nicht nur um die optimale Nutzung der Hardware, sondern auch um die Geschwindigkeit der Datenübertragung zu den Nutzern. Beispiel: Ein Video mit dem entscheidenden Moment eines Eishockeyspiels kann bereits eine Minute nach dem Ereignis in der Suche gefunden werden.

Sequenzielle Kodierung

Das Nutzererlebnis hängt stark davon ab, wie schnell das Video verfügbar wird. Dies wird hauptsächlich durch die Transkodierungsgeschwindigkeit bestimmt. Wenn keine strengen Anforderungen an die Geschwindigkeit der Videoveröffentlichung bestehen, gibt es auch keine Probleme. Man nimmt eine einheitliche, unteilbare Datei, konvertiert sie und veröffentlicht sie. Zu Beginn unserer Reise haben wir genau so gearbeitet:

Der Kunde lädt ein Video in den Speicher hoch, das Analysemodul sammelt die Metainformationen und überträgt das Video zur Umwandlung an das Modul Worker. Alle Schritte erfolgen nacheinander. Dabei kann es mehrere Server zum Kodieren geben, jedoch ist immer nur einer mit der Verarbeitung des spezifischen Videos beschäftigt. Ein einfaches, transparentes Schema. Damit enden jedoch auch die Vorteile. Dieses Modell lässt sich nur vertikal skalieren (durch den Erwerb leistungsfähigerer Server).

Nacheinander kodieren mit einem Zwischenprodukt

Um die quälende Wartezeit irgendwie zu lindern, wurde in der Branche eine Option für schnelles Kodieren erfunden. Täuschend einfacher Name, denn die vollständige Kodierung erfolgt tatsächlich nacheinander und dauert genauso lange. Aber dafür mit einem Zwischenprodukt. Die Idee ist, so schnell wie möglich eine Version des Videos in niedriger Auflösung bereitzustellen und danach die Versionen in höheren Auflösungen.

Einerseits wird das Video schneller verfügbar. Das ist nützlich für wichtige Ereignisse. Andererseits ist das Bild verschwommen, was die Zuschauer stört.

Es ist notwendig, nicht nur Videos schnell zu verarbeiten, sondern auch deren Qualität zu erhalten. Das ist das, was Nutzer von einem Videoservice heutzutage erwarten. Es mag scheinen, dass es ausreicht, die leistungsfähigsten Server zu kaufen (und diese regelmäßig aufzurüsten). Doch das ist ein aussichtsloser Weg, denn es wird immer Videos geben, die selbst die leistungsstärkste Hardware ins Stocken bringen.

Parallele Codierung

Es ist erheblich effektiver, eine komplexe Aufgabe in viele weniger komplexe aufzuteilen und diese parallel auf verschiedenen Servern zu lösen. So funktioniert MapReduce für Videos. In diesem Fall stoßen wir nicht an die Leistungsgrenzen eines einzelnen Servers und können horizontal skalieren (durch Hinzufügen neuer Maschinen).

Übrigens ist die Idee, Videos in kleine Stücke zu zerlegen, sie parallel zu bearbeiten und dann wieder zusammenzufügen, kein Geheimnis. Sie finden zahlreiche Erwähnungen dieses Ansatzes (zum Beispiel empfehle ich den Beitrag über das Projekt DistVIDc). Aber das macht es insgesamt nicht einfacher, denn man kann nicht einfach eine fertige Lösung nehmen und in die eigene Infrastruktur integrieren. Eine Anpassung an unsere Infrastruktur, unser Video und sogar unsere Last ist erforderlich. Am besten ist es, selbst eine Lösung zu entwickeln.

In der neuen Architektur des monolithischen Blocks Worker mit sequentieller Kodierung haben wir ihn in die Mikrodienste Segmenter, Tcoder und Combiner aufgeteilt.

Der Segmenter unterteilt das Video in etwa 10-sekündige Fragmente. Jedes Fragment besteht aus einer oder mehreren GOP (group of pictures). Jede GOP ist unabhängig und wird separat kodiert, sodass sie ohne Bezug auf Frames aus anderen GOP dekodiert werden kann. Das bedeutet, dass die Fragmente unabhängig voneinander wiedergegeben werden können. Diese Segmentierung verringert die Verzögerung, da die Verarbeitung früher beginnen kann.
Tcoder verarbeitet jedes Fragment. Er entnimmt die Aufgabe aus der Warteschlange, lädt das Fragment aus dem Speicher herunter, kodiert es in verschiedene Auflösungen (denken Sie daran, dass der Player die Version je nach Verbindungsgeschwindigkeit auswählen kann) und legt das Ergebnis wieder im Speicher ab, während er das Fragment in der Datenbank als verarbeitet kennzeichnet. Nachdem er alle Fragmente bearbeitet hat, sendet Tcoder die Aufgabe zur Ergebnisbildung an die nächste Komponente.
Der Combiner fasst die Ergebnisse zusammen: Er lädt alle Fragmente, die von Tcoder erstellt wurden, herunter und bildet Streams für verschiedene Auflösungen.

Ein paar Worte zum Sound. Der beliebteste Audiocodec AAC hat eine unangenehme Eigenheit. Wenn Fragmente separat codiert werden, lassen sie sich einfach nicht nahtlos zusammenfügen. Übergänge werden deutlich hörbar sein. Bei Videocodecs besteht dieses Problem nicht. Theoretisch könnte man nach einer komplexen technischen Lösung suchen, aber dieses Spiel lohnt sich derzeit einfach nicht (Audio ist deutlich leichter als Video). Daher wird bei uns parallel nur das Video codiert, während die Audiospur vollständig verarbeitet wird.

Ergebnisse

Dank der parallelen Bearbeitung von Videos haben wir die Verzögerung zwischen dem Hochladen des Videos und dessen Verfügbarkeit für die Nutzer erheblich verringert. Zum Beispiel konnte die Erstellung mehrerer vollständiger Versionen in unterschiedlicher Qualität für einen 1,5-stündigen FullHD-Film früher bis zu zwei Stunden dauern. Jetzt benötigt dies nur noch 15 Minuten. Darüber hinaus erstellen wir bei der parallelen Bearbeitung die Version in hoher Auflösung sogar schneller als die Version in niedriger Auflösung nach dem alten Ansatz mit einem Zwischenergebnis.

Und noch etwas. Bei der alten Methode gab es entweder nicht genug Server oder sie waren untätig. Paralleles Kodieren ermöglicht eine höhere Auslastung der Hardware. Jetzt ist unser Cluster mit über tausend Servern ständig beschäftigt.

Tatsächlich gibt es noch viel Entwicklungspotenzial. Zum Beispiel könnten wir erheblich Zeit sparen, wenn wir beginnen, Videofragmente zu verarbeiten, noch bevor sie vollständig an uns übertragen werden. Wie man so schön sagt, nach dem ersten Schritt folgt der nächste.

Bitte teilen Sie in den Kommentaren mit, über welche Videoverarbeitungsaufgaben Sie gerne lesen würden.