Hver dag ser millioner av seere videoer på Internett. Men for at videoen skal bli tilgjengelig, må den ikke bare lastes opp til serveren, men også behandles. Jo raskere dette skjer, jo bedre for tjenesten og brukerne.
Mitt navn er Askar Kamalov, for et år siden ble jeg med i Yandex videoteknologiteam. I dag vil jeg kort fortelle Habr-leserne om hvordan vi, ved å parallellisere kodingsprosessen, klarte å fremskynde leveringen av video til brukeren betydelig.
Dette innlegget vil først og fremst være av interesse for de som ikke tidligere har tenkt på hva som skjer under panseret til videotjenester. I kommentarfeltet kan du stille spørsmål og foreslå emner for fremtidige innlegg.
Noen få ord om selve oppgaven. Yandex hjelper deg ikke bare med å søke etter videoer på andre nettsteder, men lagrer også videoer for sine egne tjenester. Enten det er et originalt program eller en sportskamp på lufta, en film på KinoPoisk eller videoer på Zen og News - alt dette lastes opp til serverne våre. For at brukere skal se videoen, må den være forberedt: konvertert til ønsket format, opprettet en forhåndsvisning, eller til og med kjøre gjennom teknologi . En uforberedt fil tar bare opp plass. Dessuten snakker vi ikke bare om optimal bruk av maskinvare, men også om hastigheten på levering av innhold til brukerne. Eksempel: et opptak av det avgjørende øyeblikket i en hockeykamp kan søkes etter innen et minutt etter selve begivenheten.
Sekvensiell koding
Så, brukerens lykke avhenger i stor grad av hvor raskt videoen blir tilgjengelig. Og dette bestemmes hovedsakelig av transkodingshastigheten. Når det ikke er strenge krav til videoopplastingshastighet, er det ingen problemer. Du tar en enkelt, udelelig fil, konverterer den og laster den opp. I begynnelsen av reisen vår jobbet vi slik:
Klienten laster opp videoen til lagringen, Analyzer-komponenten samler inn metainformasjon og overfører videoen til Worker-komponenten for konvertering. Alle stadier utføres sekvensielt. I dette tilfellet kan det være mange kodingsservere, men bare én er opptatt med å behandle en bestemt video. Enkelt, gjennomsiktig diagram. Det er her fordelene slutter. Denne ordningen kan bare skaleres vertikalt (på grunn av kjøp av kraftigere servere).
Sekvensiell koding med mellomresultat
For på en eller annen måte å jevne ut den smertefulle ventetiden, kom industrien med et raskt kodealternativ. Navnet er misvisende, for faktisk skjer full koding sekvensielt og tar like lang tid. Men med et mellomresultat. Tanken er denne: klargjør og publiser en lavoppløselig versjon av videoen så raskt som mulig, og først da versjoner med høyere oppløsning.
På den ene siden blir video tilgjengelig raskere. Og det er nyttig for viktige begivenheter. Men på den annen side blir bildet uskarpt, og dette irriterer seerne.
Det viser seg at du ikke bare må behandle videoen raskt, men også opprettholde kvaliteten. Dette er hva brukerne forventer av en videotjeneste nå. Det kan virke som det er nok å kjøpe de mest produktive serverne (og jevnlig oppgradere dem alle samtidig). Men dette er en blindvei, for det er alltid en video som vil få selv den kraftigste maskinvaren til å bremse ned.
Parallell koding
Det er mye mer effektivt å dele opp et komplekst problem i mange mindre komplekse og løse dem parallelt på forskjellige servere. Dette er MapReduce for video. I dette tilfellet er vi ikke begrenset av ytelsen til én server og kan skalere horisontalt (ved å legge til nye maskiner).
Forresten, ideen om å dele videoer i små biter, behandle dem parallelt og lime dem sammen er ikke noen hemmelighet. Du kan finne mange referanser til denne tilnærmingen (for eksempel på Habré anbefaler jeg et innlegg om prosjektet ). Men dette gjør det ikke enklere totalt sett, for du kan ikke bare ta en ferdig løsning og bygge den inn i hjemmet ditt. Vi trenger tilpasning til infrastrukturen vår, videoen vår og til og med lasten vår. Generelt er det lettere å skrive din egen.
Så i den nye arkitekturen delte vi den monolitiske Worker-blokken med sekvensiell koding i mikrotjenester Segmenter, Tcoder, Combiner.
- Segmenter deler videoen i fragmenter på omtrent 10 sekunder. Fragmenter består av en eller flere GOP-er (). Hver GOP er uavhengig og kodet separat slik at den kan dekodes uten referanse til rammer fra andre GOPer. Det vil si at fragmenter kan spilles uavhengig av hverandre. Denne sønderdelingen reduserer ventetiden, slik at behandlingen kan starte tidligere.
- Tcoder behandler hvert fragment. Den tar en oppgave fra køen, laster ned et fragment fra lagringen, koder det til forskjellige oppløsninger (husk at spilleren kan velge en versjon basert på tilkoblingshastigheten), legger deretter resultatet tilbake i lagringen og merker fragmentet som behandlet i databasen. Etter å ha behandlet alle fragmentene, sender Tcoder oppgaven for å generere resultater for neste komponent.
- Combiner samler resultatene sammen: laster ned alle fragmentene laget av Tcoder, genererer strømmer for forskjellige oppløsninger.
Noen ord om lyd. Den mest populære AAC-lydkodeken har en ubehagelig funksjon. Hvis du koder fragmenter separat, vil du ganske enkelt ikke kunne lime dem sømløst sammen. Overganger vil være merkbare. Videokodeker har ikke dette problemet. Teoretisk sett kan du se etter en kompleks teknisk løsning, men dette spillet er rett og slett ikke verdt lyset ennå (lyd veier betydelig mindre enn video). Derfor er bare videoen kodet parallelt, og hele lydsporet behandles.
Funn
Takket være parallell videobehandling har vi betydelig redusert forsinkelsen mellom en video blir lastet opp til oss og den er tilgjengelig for brukerne. Tidligere kunne det for eksempel tatt to timer å lage flere fullversjoner av ulik kvalitet for en FullHD-film som varte i halvannen time. Nå tar alt dette 15 minutter. Med parallell prosessering lager vi dessuten en versjon med høy oppløsning enda raskere enn en versjon med lav oppløsning med den gamle metoden for mellomresultat.
Og en ting til. Med den gamle tilnærmingen var det enten ikke nok servere, eller så var de inaktive uten oppgaver. Parallell koding lar deg øke andelen jerngjenvinning. Nå er klyngen vår på mer enn tusen servere alltid opptatt med noe.
Faktisk er det fortsatt rom for forbedring. For eksempel kan vi spare betydelig tid hvis vi begynner å behandle fragmenter av videoen før den kommer til oss i sin helhet. Som de sier, mer kommer.
Skriv i kommentarfeltet hvilke oppgaver innen arbeid med video du ønsker å lese om.
Nyttige lenker til erfaringene til bransjekolleger
Kilde: www.habr.com