Elke dag kyk miljoene kykers video's op die internet. Maar vir die video om beskikbaar te word, moet dit nie net na die bediener opgelaai word nie, maar ook verwerk word. Hoe vinniger dit gebeur, hoe beter vir die diens en sy gebruikers.
My naam is Askar Kamalov, 'n jaar gelede het ek by die Yandex-videotegnologiespan aangesluit. Vandag sal ek Habr-lesers kortliks vertel hoe ons, deur die enkoderingsproses te paralleliseer, daarin geslaag het om die aflewering van video aan die gebruiker aansienlik te bespoedig.
Hierdie pos sal hoofsaaklik van belang wees vir diegene wat nie voorheen gedink het oor wat onder die kap van videodienste gebeur nie. In die kommentaar kan jy vrae vra en onderwerpe voorstel vir toekomstige plasings.
'n Paar woorde oor die taak self. Yandex help jou nie net om na video's op ander webwerwe te soek nie, maar stoor ook video's vir sy eie dienste. Of dit nou 'n oorspronklike program of 'n sportwedstryd op die lug is, 'n film op KinoPoisk of video's op Zen en Nuus - dit alles word na ons bedieners gelaai. Vir gebruikers om die video te kyk, moet dit voorberei word: omgeskakel na die vereiste formaat, 'n voorskou geskep, of selfs deur tegnologie hardloop . 'n Onvoorbereide lêer neem net spasie op. Boonop praat ons nie net oor die optimale gebruik van hardeware nie, maar ook oor die spoed van aflewering van inhoud aan gebruikers. Voorbeeld: 'n opname van die beslissende oomblik van 'n hokkiewedstryd kan binne 'n minuut na die gebeurtenis self gesoek word.
Opeenvolgende enkodering
Dus, die geluk van die gebruiker hang grootliks af van hoe vinnig die video beskikbaar word. En dit word hoofsaaklik bepaal deur die transkoderingspoed. As daar geen streng vereistes vir video-oplaaispoed is nie, is daar geen probleme nie. Jy neem 'n enkele, ondeelbare lêer, skakel dit om en laai dit op. Aan die begin van ons reis is dit hoe ons gewerk het:
Die kliënt laai die video op na die berging, die ontleder-komponent versamel meta-inligting en dra die video oor na die Werker-komponent vir omskakeling. Alle stadiums word opeenvolgend uitgevoer. In hierdie geval kan daar baie enkoderingsbedieners wees, maar net een is besig om 'n spesifieke video te verwerk. Eenvoudige, deursigtige diagram. Dit is waar die voordele daarvan eindig. Hierdie skema kan slegs vertikaal afgeskaal word (as gevolg van die aankoop van kragtiger bedieners).
Opeenvolgende enkodering met intermediêre resultaat
Om die pynlike wag op een of ander manier glad te maak, het die bedryf met 'n vinnige koderingsopsie vorendag gekom. Die naam is misleidend, want in werklikheid vind volledige kodering opeenvolgend plaas en neem net so lank. Maar met 'n intermediêre resultaat. Die idee is dit: berei en publiseer 'n lae-resolusie-weergawe van die video so vinnig as moontlik, en eers dan hoër-resolusie weergawes.
Aan die een kant word video vinniger beskikbaar. En dit is nuttig vir belangrike gebeurtenisse. Maar aan die ander kant blyk die prentjie vaag, en dit irriteer kykers.
Dit blyk dat jy nie net die video vinnig moet verwerk nie, maar ook die kwaliteit daarvan moet handhaaf. Dit is wat gebruikers nou van 'n videodiens verwag. Dit mag lyk asof dit genoeg is om die mees produktiewe bedieners te koop (en gereeld almal gelyktydig op te gradeer). Maar dit is 'n doodloopstraat, want daar is altyd 'n video wat selfs die kragtigste hardeware sal laat vertraag.
Parallelle enkodering
Dit is baie meer doeltreffend om 'n komplekse probleem in baie minder komplekse te verdeel en dit parallel op verskillende bedieners op te los. Dit is MapReduce vir video. In hierdie geval word ons nie beperk deur die werkverrigting van een bediener nie en kan ons horisontaal skaal (deur nuwe masjiene by te voeg).
Terloops, die idee om video's in klein stukkies te verdeel, parallel te verwerk en saam te plak, is nie 'n geheim nie. Jy kan baie verwysings na hierdie benadering vind (byvoorbeeld op Habré beveel ek 'n plasing oor die projek aan ). Maar dit maak dit in die algemeen nie makliker nie, want jy kan nie net ’n klaargemaakte oplossing neem en dit in jou huis inbou nie. Ons benodig aanpassing by ons infrastruktuur, ons video en selfs ons vrag. Oor die algemeen is dit makliker om jou eie te skryf.
Dus, in die nuwe argitektuur het ons die monolitiese Werker-blok met opeenvolgende kodering verdeel in mikrodienste Segmenter, Tcoder, Combiner.
- Segmenter breek die video in fragmente van ongeveer 10 sekondes op. Fragmente bestaan uit een of meer GOP's (). Elke GOP is onafhanklik en afsonderlik geënkodeer sodat dit gedekodeer kan word sonder verwysing na rame van ander GOP's. Dit wil sê, fragmente kan onafhanklik van mekaar gespeel word. Hierdie versplintering verminder latensie, sodat verwerking vroeër kan begin.
- Tcoder verwerk elke fragment. Dit neem 'n taak uit die tou, laai 'n fragment van die berging af, enkodeer dit in verskillende resolusies (onthou dat die speler 'n weergawe kan kies gebaseer op die verbindingspoed), plaas dan die resultaat terug in die berging en merk die fragment as verwerk in die databasis. Nadat al die fragmente verwerk is, stuur Tcoder die taak om resultate vir die volgende komponent te genereer.
- Combiner versamel die resultate saam: laai al die fragmente af wat deur Tcoder gemaak is, genereer strome vir verskillende resolusies.
'n Paar woorde oor klank. Die gewildste AAC-klankkodek het 'n onaangename kenmerk. As jy fragmente afsonderlik enkodeer, dan sal jy eenvoudig nie in staat wees om hulle naatloos aan mekaar vas te plak nie. Oorgange sal merkbaar wees. Video-kodeks het nie hierdie probleem nie. Teoreties kan jy 'n komplekse tegniese oplossing soek, maar hierdie speletjie is eenvoudig nog nie die kers werd nie (klank weeg aansienlik minder as video). Daarom word slegs die video parallel geënkodeer, en die hele klankbaan word verwerk.
Bevindinge
Danksy parallelle videoverwerking het ons die vertraging aansienlik verminder tussen 'n video wat na ons opgelaai word en dit vir gebruikers beskikbaar is. Byvoorbeeld, voorheen kon dit twee uur neem om verskeie volledige weergawes van verskillende gehalte te skep vir 'n FullHD-film wat 'n uur en 'n half geduur het. Nou neem dit alles 15 minute. Verder, met parallelle verwerking, skep ons 'n hoë-resolusie weergawe selfs vinniger as 'n lae-resolusie weergawe met die ou intermediêre resultaat benadering.
En nog een ding. Met die ou benadering was daar óf nie genoeg bedieners nie, óf hulle was ledig sonder take. Parallelle kodering laat jou toe om die aandeel van ysterherwinning te verhoog. Nou is ons groep van meer as 'n duisend bedieners altyd besig met iets.
Trouens, daar is nog ruimte vir verbetering. Ons kan byvoorbeeld aansienlike tyd bespaar as ons fragmente van die video begin verwerk voordat dit in sy geheel by ons opdaag. Soos hulle sê, meer om te kom.
Skryf in die kommentaar oor watter take op die gebied van werk met video jy graag wil lees.
Nuttige skakels na die ervaring van bedryfskollegas
Bron: will.com