Elke dag bekijken miljoenen kijkers video's op internet. Maar voordat de video beschikbaar komt, moet deze niet alleen naar de server worden geüpload, maar ook worden verwerkt. Hoe sneller dit gebeurt, hoe beter voor de dienst en zijn gebruikers.
Mijn naam is Askar Kamalov, een jaar geleden trad ik toe tot het Yandex-videotechnologieteam. Vandaag zal ik Habr-lezers kort vertellen hoe we, door het coderingsproces te parallelliseren, erin zijn geslaagd de levering van video aan de gebruiker aanzienlijk te versnellen.
Dit bericht zal vooral interessant zijn voor degenen die nog niet eerder hebben nagedacht over wat er gebeurt onder de motorkap van videodiensten. In de reacties kun je vragen stellen en onderwerpen voor toekomstige berichten voorstellen.
Een paar woorden over de taak zelf. Yandex helpt je niet alleen bij het zoeken naar video's op andere sites, maar slaat ook video's op voor zijn eigen services. Of het nu gaat om een origineel programma of een sportwedstrijd in de ether, een film op KinoPoisk of video's op Zen en News - dit alles wordt naar onze servers geüpload. Voordat gebruikers de video kunnen bekijken, moet deze worden voorbereid: geconverteerd naar het gewenste formaat, een voorbeeld gemaakt of zelfs door de technologie gehaald . Een onvoorbereid bestand neemt alleen maar ruimte in beslag. Bovendien hebben we het niet alleen over het optimale gebruik van hardware, maar ook over de snelheid waarmee inhoud aan gebruikers wordt geleverd. Voorbeeld: een opname van het beslissende moment van een hockeywedstrijd kan binnen een minuut na het evenement zelf worden opgezocht.
Sequentiële codering
Het geluk van de gebruiker hangt dus grotendeels af van hoe snel de video beschikbaar komt. En dit wordt vooral bepaald door de transcodeersnelheid. Als er geen strikte eisen zijn aan de uploadsnelheid van video's, zijn er geen problemen. U neemt een enkel, ondeelbaar bestand, converteert het en uploadt het. Aan het begin van onze reis werkten we als volgt:
De client uploadt de video naar de opslag, de Analyzer-component verzamelt meta-informatie en draagt de video over naar de Worker-component voor conversie. Alle fasen worden opeenvolgend uitgevoerd. In dit geval kunnen er veel coderingsservers zijn, maar slechts één is bezig met het verwerken van een specifieke video. Eenvoudig, transparant diagram. Dit is waar de voordelen eindigen. Dit schema kan alleen verticaal worden opgeschaald (vanwege de aanschaf van krachtigere servers).
Sequentiële codering met tussenresultaat
Om het pijnlijke wachten op de een of andere manier glad te strijken, kwam de industrie met een snelle coderingsoptie. De naam is misleidend, omdat de volledige codering in feite opeenvolgend plaatsvindt en net zo lang duurt. Maar met een tussenresultaat. Het idee is dit: bereid en publiceer zo snel mogelijk een versie met een lage resolutie van de video, en pas dan versies met een hogere resolutie.
Enerzijds komt video sneller beschikbaar. En het is handig voor belangrijke evenementen. Maar aan de andere kant wordt het beeld wazig, en dit irriteert kijkers.
Het blijkt dat je de video niet alleen snel moet verwerken, maar ook de kwaliteit ervan moet behouden. Dit is wat gebruikers tegenwoordig van een videodienst verwachten. Het lijkt misschien dat het voldoende is om de meest productieve servers te kopen (en ze regelmatig allemaal tegelijk te upgraden). Maar dit is een doodlopende weg, want er is altijd wel een video die zelfs de krachtigste hardware langzamer maakt.
Parallelle codering
Het is veel efficiënter om een complex probleem in veel minder complexe problemen te verdelen en deze parallel op verschillende servers op te lossen. Dit is MapReduce voor video. In dit geval worden we niet beperkt door de prestaties van één server en kunnen we horizontaal opschalen (door nieuwe machines toe te voegen).
Trouwens, het idee om video's in kleine stukjes te splitsen, ze parallel te verwerken en aan elkaar te lijmen is geen geheim. Je kunt veel verwijzingen naar deze aanpak vinden (op Habré raad ik bijvoorbeeld een bericht over het project aan ). Maar dit maakt het er in het algemeen niet makkelijker op, want je kunt niet zomaar een kant-en-klare oplossing in je huis inbouwen. We hebben aanpassing nodig aan onze infrastructuur, onze video en zelfs onze lading. Over het algemeen is het gemakkelijker om uw eigen te schrijven.
Dus in de nieuwe architectuur hebben we het monolithische Worker-blok met sequentiële codering verdeeld in microservices Segmenter, Tcoder, Combiner.
- Segmenter verdeelt de video in fragmenten van ongeveer 10 seconden. Fragmenten bestaan uit een of meer GOP's (). Elke GOP is onafhankelijk en afzonderlijk gecodeerd, zodat deze kan worden gedecodeerd zonder verwijzing naar frames van andere GOP's. Dat wil zeggen dat fragmenten onafhankelijk van elkaar kunnen worden afgespeeld. Deze sharding vermindert de latentie, waardoor de verwerking eerder kan beginnen.
- Tcoder verwerkt elk fragment. Het neemt een taak uit de wachtrij, downloadt een fragment uit de opslag, codeert het in verschillende resoluties (onthoud dat de speler een versie kan kiezen op basis van de verbindingssnelheid), plaatst het resultaat vervolgens terug in de opslag en markeert het fragment als verwerkt in de databank. Nadat alle fragmenten zijn verwerkt, verzendt Tcoder de taak om resultaten voor het volgende onderdeel te genereren.
- Combiner verzamelt de resultaten bij elkaar: downloadt alle fragmenten gemaakt door Tcoder, genereert streams voor verschillende resoluties.
Een paar woorden over geluid. De meest populaire AAC-audiocodec heeft een onaangename functie. Als je fragmenten afzonderlijk codeert, kun je ze eenvoudigweg niet naadloos aan elkaar lijmen. Overgangen zullen merkbaar zijn. Videocodecs hebben dit probleem niet. Theoretisch kun je op zoek gaan naar een complexe technische oplossing, maar deze game is de kaars simpelweg nog niet waard (audio weegt aanzienlijk minder dan video). Daarom wordt alleen de video parallel gecodeerd en wordt het volledige audiospoor verwerkt.
Bevindingen
Dankzij parallelle videoverwerking hebben we de vertraging tussen het uploaden van een video en het beschikbaar zijn voor gebruikers aanzienlijk verminderd. Voorheen kon het bijvoorbeeld twee uur duren om meerdere volledige versies van verschillende kwaliteit te maken voor een FullHD-film van anderhalf uur. Nu duurt dit allemaal 15 minuten. Bovendien creëren we met parallelle verwerking nog sneller een versie met hoge resolutie dan een versie met lage resolutie met de oude tussenresultaatbenadering.
En nog een laatste ding. Met de oude aanpak waren er óf niet genoeg servers, óf stonden ze stil zonder taken. Door parallel te coderen kunt u het aandeel ijzerrecycling vergroten. Nu is ons cluster van ruim duizend servers altijd wel ergens mee bezig.
Sterker nog, er is nog ruimte voor verbetering. We kunnen bijvoorbeeld veel tijd besparen als we beginnen met het verwerken van fragmenten van de video voordat deze in zijn geheel bij ons binnenkomt. Zoals ze zeggen, er komt nog meer.
Schrijf in de reacties over welke taken op het gebied van werken met video jij graag zou willen lezen.
Nuttige links naar de ervaringen van collega's uit de sector
Bron: www.habr.com