Hver dag ser millioner af seere videoer på internettet. Men for at videoen bliver tilgængelig, skal den ikke kun uploades til serveren, men også behandles. Jo hurtigere dette sker, jo bedre for tjenesten og dens brugere.
Mit navn er Askar Kamalov, for et år siden sluttede jeg mig til Yandex videoteknologiteam. I dag vil jeg kort fortælle Habr-læserne om, hvordan vi ved at parallelisere kodningsprocessen formåede at fremskynde leveringen af video til brugeren markant.
Dette indlæg vil primært være interessant for dem, der ikke tidligere har tænkt over, hvad der sker under videotjenesternes hætte. I kommentarerne kan du stille spørgsmål og foreslå emner til fremtidige indlæg.
Et par ord om selve opgaven. Yandex hjælper dig ikke kun med at søge efter videoer på andre websteder, men gemmer også videoer til sine egne tjenester. Uanset om det er et originalt program eller en sportskamp i luften, en film på KinoPoisk eller videoer på Zen og News - alt dette uploades til vores servere. For at brugerne kan se videoen, skal den være forberedt: konverteret til det krævede format, oprettet en forhåndsvisning eller endda køre gennem teknologi . En uforberedt fil fylder bare. Desuden taler vi ikke kun om den optimale brug af hardware, men også om hastigheden af levering af indhold til brugerne. Eksempel: En optagelse af det afgørende øjeblik i en hockeykamp kan søges efter inden for et minut efter selve begivenheden.
Sekventiel kodning
Så brugerens lykke afhænger i høj grad af, hvor hurtigt videoen bliver tilgængelig. Og dette bestemmes hovedsageligt af omkodningshastigheden. Når der ikke er strenge krav til video upload hastighed, så er der ingen problemer. Du tager en enkelt, udelelig fil, konverterer den og uploader den. I begyndelsen af vores rejse arbejdede vi sådan her:
Klienten uploader videoen til lageret, Analyzer-komponenten indsamler metainformation og overfører videoen til Worker-komponenten til konvertering. Alle stadier udføres sekventielt. I dette tilfælde kan der være mange kodningsservere, men kun én er optaget af at behandle en bestemt video. Enkelt, gennemsigtigt diagram. Det er her, dets fordele slutter. Denne ordning kan kun skaleres lodret (på grund af køb af mere kraftfulde servere).
Sekventiel kodning med mellemresultat
For på en eller anden måde at udjævne den smertefulde ventetid kom industrien med en hurtig kodningsmulighed. Navnet er vildledende, for faktisk sker fuld kodning sekventielt og tager lige så lang tid. Men med et mellemresultat. Ideen er denne: Forbered og udgiv en lavopløsningsversion af videoen så hurtigt som muligt, og først derefter versioner med højere opløsning.
På den ene side bliver video hurtigere tilgængelig. Og det er nyttigt til vigtige begivenheder. Men på den anden side bliver billedet sløret, og det irriterer seerne.
Det viser sig, at du ikke kun skal behandle videoen hurtigt, men også bevare dens kvalitet. Det er, hvad brugerne forventer af en videotjeneste nu. Det kan se ud til, at det er nok at købe de mest produktive servere (og jævnligt opgradere dem alle på én gang). Men dette er en blindgyde, for der er altid en video, der får selv den mest kraftfulde hardware til at bremse.
Parallel kodning
Det er meget mere effektivt at opdele et komplekst problem i mange mindre komplekse og løse dem parallelt på forskellige servere. Dette er MapReduce til video. I dette tilfælde er vi ikke begrænset af en servers ydeevne og kan skalere horisontalt (ved at tilføje nye maskiner).
Forresten er ideen om at opdele videoer i små stykker, behandle dem parallelt og lime dem sammen ikke nogen hemmelighed. Du kan finde mange referencer til denne tilgang (for eksempel anbefaler jeg på Habré et indlæg om projektet ). Men det gør det samlet set ikke nemmere, for du kan ikke bare tage en færdig løsning og bygge den ind i dit hjem. Vi har brug for tilpasning til vores infrastruktur, vores video og endda vores belastning. Generelt er det nemmere at skrive dit eget.
Så i den nye arkitektur opdelte vi den monolitiske Worker-blok med sekventiel kodning i mikrotjenester Segmenter, Tcoder, Combiner.
- Segmenter deler videoen op i fragmenter på cirka 10 sekunder. Fragmenter består af en eller flere GOP'er (). Hver GOP er uafhængig og kodet separat, så den kan afkodes uden reference til rammer fra andre GOP'er. Det vil sige, at fragmenter kan afspilles uafhængigt af hinanden. Denne sharding reducerer latens, så behandlingen kan begynde tidligere.
- Tcoder behandler hvert fragment. Det tager en opgave fra køen, downloader et fragment fra lageret, koder det til forskellige opløsninger (husk at afspilleren kan vælge en version baseret på forbindelseshastigheden), sætter derefter resultatet tilbage i lageret og markerer fragmentet som behandlet i databasen. Efter at have behandlet alle fragmenterne, sender Tcoder opgaven for at generere resultater for den næste komponent.
- Combiner samler resultaterne sammen: downloader alle fragmenter lavet af Tcoder, genererer streams til forskellige opløsninger.
Et par ord om lyd. Den mest populære AAC audio codec har en ubehagelig funktion. Hvis du koder fragmenter separat, vil du simpelthen ikke være i stand til at lime dem sammen sømløst. Overgange vil være mærkbare. Video-codecs har ikke dette problem. Teoretisk set kan du lede efter en kompleks teknisk løsning, men dette spil er simpelthen ikke stearinlyset værd endnu (lyd vejer væsentligt mindre end video). Derfor er det kun videoen, der kodes parallelt, og hele lydsporet behandles.
Fund
Takket være parallel videobehandling har vi reduceret forsinkelsen betydeligt mellem, at en video bliver uploadet til os, og den er tilgængelig for brugerne. For eksempel kunne det tidligere tage to timer at skabe flere fulde versioner af forskellig kvalitet til en FullHD-film, der varer halvanden time. Nu tager alt dette 15 minutter. Desuden skaber vi med parallel behandling en version med høj opløsning endnu hurtigere end en version med lav opløsning med den gamle metode til mellemresultat.
Og en ting mere. Med den gamle tilgang var der enten ikke nok servere, eller også var de inaktive uden opgaver. Parallel kodning giver dig mulighed for at øge andelen af jerngenanvendelse. Nu er vores klynge på mere end tusinde servere altid travlt med noget.
Faktisk er der stadig plads til forbedringer. For eksempel kan vi spare betydelig tid, hvis vi begynder at behandle fragmenter af videoen, før den kommer til os i sin helhed. Som de siger, der kommer mere.
Skriv i kommentarerne, hvilke opgaver inden for arbejdet med video, du gerne vil læse om.
Nyttige links til branchekollegers erfaringer
Kilde: www.habr.com