{"id":75722,"date":"2020-03-28T07:42:04","date_gmt":"2020-03-28T05:42:04","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-uskorili-kodirovanie-video-v-vosem-raz"},"modified":"2020-03-28T07:42:04","modified_gmt":"2020-03-28T05:42:04","slug":"kak-my-uskorili-kodirovanie-video-v-vosem-raz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-uskorili-kodirovanie-video-v-vosem-raz","title":{"rendered":"Wie wir die Videoenkodierung verachtfachten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wie
\n
\nJeden Tag schauen Millionen von Zuschauern Videos im Internet. Damit ein Video jedoch verf\u00fcgbar wird, muss es nicht nur auf den Server hochgeladen, sondern auch bearbeitet werden. Je schneller dies geschieht, desto besser ist der Service f\u00fcr die Nutzer. <\/p>\n

Ich hei\u00dfe Askar Kamalov und bin vor einem Jahr zum Team der Videotechnologien von Yandex gesto\u00dfen. Heute m\u00f6chte ich den Lesern von Habr kurz erz\u00e4hlen, wie wir durch Parallelisierung des Kodierungsprozesses die Auslieferung von Videos an die Nutzer erheblich beschleunigen konnten. <\/p>\n

Dieser Beitrag richtet sich in erster Linie an diejenigen, die sich bisher nicht mit den Vorg\u00e4ngen hinter Videodiensten besch\u00e4ftigt haben. In den Kommentaren k\u00f6nnen Fragen gestellt und Themen f\u00fcr zuk\u00fcnftige Beitr\u00e4ge vorgeschlagen werden.
\n<\/a><\/noindex>
\nEinige Worte zur Aufgabe selbst. Yandex hilft nicht nur dabei, Videos auf anderen Seiten zu suchen, sondern speichert auch Videos f\u00fcr die eigenen Dienste. Sei es eine Autorenproduktion, ein Sportereignis im Stream, ein Film auf KinoPoisk oder Clips in Zen und Nachrichten \u2013 all das wird auf unseren Servern hochgeladen. Damit die Nutzer die Videos ansehen k\u00f6nnen, m\u00fcssen sie vorbereitet werden: in das erforderliche Format konvertiert, ein Vorschaubild erstellt oder sogar durch Technologien verarbeitet werden. DeepHD<\/a><\/noindex>. 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\u00fcbertragung zu den Nutzern. Beispiel: Ein Video mit dem entscheidenden Moment eines Eishockeyspiels kann bereits eine Minute nach dem Ereignis in der Suche gefunden werden.<\/p>\n

Sequenzielle Kodierung<\/h3>\n

\nDas Nutzererlebnis h\u00e4ngt stark davon ab, wie schnell das Video verf\u00fcgbar wird. Dies wird haupts\u00e4chlich durch die Transkodierungsgeschwindigkeit bestimmt. Wenn keine strengen Anforderungen an die Geschwindigkeit der Videover\u00f6ffentlichung bestehen, gibt es auch keine Probleme. Man nimmt eine einheitliche, unteilbare Datei, konvertiert sie und ver\u00f6ffentlicht sie. Zu Beginn unserer Reise haben wir genau so gearbeitet:<\/p>\n

\"Wie
\n
\nDer Kunde l\u00e4dt ein Video in den Speicher hoch, das Analysemodul sammelt die Metainformationen und \u00fcbertr\u00e4gt 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\u00e4ftigt. Ein einfaches, transparentes Schema. Damit enden jedoch auch die Vorteile. Dieses Modell l\u00e4sst sich nur vertikal skalieren (durch den Erwerb leistungsf\u00e4higerer Server). <\/p>\n

Nacheinander kodieren mit einem Zwischenprodukt<\/h3>\n

\nUm die qu\u00e4lende Wartezeit irgendwie zu lindern, wurde in der Branche eine Option f\u00fcr schnelles Kodieren erfunden. T\u00e4uschend einfacher Name, denn die vollst\u00e4ndige Kodierung erfolgt tats\u00e4chlich nacheinander und dauert genauso lange. Aber daf\u00fcr mit einem Zwischenprodukt. Die Idee ist, so schnell wie m\u00f6glich eine Version des Videos in niedriger Aufl\u00f6sung bereitzustellen und danach die Versionen in h\u00f6heren Aufl\u00f6sungen. <\/p>\n

Einerseits wird das Video schneller verf\u00fcgbar. Das ist n\u00fctzlich f\u00fcr wichtige Ereignisse. Andererseits ist das Bild verschwommen, was die Zuschauer st\u00f6rt.<\/p>\n

Es ist notwendig, nicht nur Videos schnell zu verarbeiten, sondern auch deren Qualit\u00e4t zu erhalten. Das ist das, was Nutzer von einem Videoservice heutzutage erwarten. Es mag scheinen, dass es ausreicht, die leistungsf\u00e4higsten Server zu kaufen (und diese regelm\u00e4\u00dfig aufzur\u00fcsten). Doch das ist ein aussichtsloser Weg, denn es wird immer Videos geben, die selbst die leistungsst\u00e4rkste Hardware ins Stocken bringen. <\/p>\n

Parallele Codierung<\/h3>\n

\nEs ist erheblich effektiver, eine komplexe Aufgabe in viele weniger komplexe aufzuteilen und diese parallel auf verschiedenen Servern zu l\u00f6sen. So funktioniert MapReduce f\u00fcr Videos. In diesem Fall sto\u00dfen wir nicht an die Leistungsgrenzen eines einzelnen Servers und k\u00f6nnen horizontal skalieren (durch Hinzuf\u00fcgen neuer Maschinen). <\/p>\n

\u00dcbrigens ist die Idee, Videos in kleine St\u00fccke zu zerlegen, sie parallel zu bearbeiten und dann wieder zusammenzuf\u00fcgen, kein Geheimnis. Sie finden zahlreiche Erw\u00e4hnungen dieses Ansatzes (zum Beispiel empfehle ich den Beitrag \u00fcber das Projekt DistVIDc<\/a><\/noindex>). Aber das macht es insgesamt nicht einfacher, denn man kann nicht einfach eine fertige L\u00f6sung 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\u00f6sung zu entwickeln. <\/p>\n

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

\"Wie
\n<\/p>\n

    \n
  1. Der Segmenter unterteilt das Video in etwa 10-sek\u00fcndige Fragmente. Jedes Fragment besteht aus einer oder mehreren GOP (group of pictures<\/a><\/noindex>). Jede GOP ist unabh\u00e4ngig und wird separat kodiert, sodass sie ohne Bezug auf Frames aus anderen GOP dekodiert werden kann. Das bedeutet, dass die Fragmente unabh\u00e4ngig voneinander wiedergegeben werden k\u00f6nnen. Diese Segmentierung verringert die Verz\u00f6gerung, da die Verarbeitung fr\u00fcher beginnen kann.<\/li>\n
  2. Tcoder verarbeitet jedes Fragment. Er entnimmt die Aufgabe aus der Warteschlange, l\u00e4dt das Fragment aus dem Speicher herunter, kodiert es in verschiedene Aufl\u00f6sungen (denken Sie daran, dass der Player die Version je nach Verbindungsgeschwindigkeit ausw\u00e4hlen kann) und legt das Ergebnis wieder im Speicher ab, w\u00e4hrend er das Fragment in der Datenbank als verarbeitet kennzeichnet. Nachdem er alle Fragmente bearbeitet hat, sendet Tcoder die Aufgabe zur Ergebnisbildung an die n\u00e4chste Komponente.<\/li>\n
  3. Der Combiner fasst die Ergebnisse zusammen: Er l\u00e4dt alle Fragmente, die von Tcoder erstellt wurden, herunter und bildet Streams f\u00fcr verschiedene Aufl\u00f6sungen.<\/li>\n<\/ol>\n

    \nEin paar Worte zum Sound. Der beliebteste Audiocodec AAC hat eine unangenehme Eigenheit. Wenn Fragmente separat codiert werden, lassen sie sich einfach nicht nahtlos zusammenf\u00fcgen. \u00dcberg\u00e4nge werden deutlich h\u00f6rbar sein. Bei Videocodecs besteht dieses Problem nicht. Theoretisch k\u00f6nnte man nach einer komplexen technischen L\u00f6sung 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\u00e4hrend die Audiospur vollst\u00e4ndig verarbeitet wird.<\/p>\n

    Ergebnisse<\/h3>\n

    \nDank der parallelen Bearbeitung von Videos haben wir die Verz\u00f6gerung zwischen dem Hochladen des Videos und dessen Verf\u00fcgbarkeit f\u00fcr die Nutzer erheblich verringert. Zum Beispiel konnte die Erstellung mehrerer vollst\u00e4ndiger Versionen in unterschiedlicher Qualit\u00e4t f\u00fcr einen 1,5-st\u00fcndigen FullHD-Film fr\u00fcher bis zu zwei Stunden dauern. Jetzt ben\u00f6tigt dies nur noch 15 Minuten. Dar\u00fcber hinaus erstellen wir bei der parallelen Bearbeitung die Version in hoher Aufl\u00f6sung sogar schneller als die Version in niedriger Aufl\u00f6sung nach dem alten Ansatz mit einem Zwischenergebnis. <\/p>\n

    Und noch etwas. Bei der alten Methode gab es entweder nicht genug Server oder sie waren unt\u00e4tig. Paralleles Kodieren erm\u00f6glicht eine h\u00f6here Auslastung der Hardware. Jetzt ist unser Cluster mit \u00fcber tausend Servern st\u00e4ndig besch\u00e4ftigt. <\/p>\n

    Tats\u00e4chlich gibt es noch viel Entwicklungspotenzial. Zum Beispiel k\u00f6nnten wir erheblich Zeit sparen, wenn wir beginnen, Videofragmente zu verarbeiten, noch bevor sie vollst\u00e4ndig an uns \u00fcbertragen werden. Wie man so sch\u00f6n sagt, nach dem ersten Schritt folgt der n\u00e4chste. <\/p>\n

    Bitte teilen Sie in den Kommentaren mit, \u00fcber welche Videoverarbeitungsaufgaben Sie gerne lesen w\u00fcrden. <\/p>\n

    N\u00fctzliche Links zu den Erfahrungen von Kollegen in der Branche<\/h3>\n

    <\/p>\n