Hogyan gyorsítottuk fel a videó kódolását nyolcszorosára

Hogyan gyorsítottuk fel a videó kódolását nyolcszorosára

Nap mint nap nézők milliói néznek videókat az interneten. De ahhoz, hogy a videó elérhető legyen, nem csak fel kell tölteni a szerverre, hanem fel is kell dolgozni. Minél gyorsabban történik ez, annál jobb a szolgáltatásnak és felhasználóinak.

A nevem Askar Kamalov, egy éve csatlakoztam a Yandex videótechnológiai csapatához. Ma röviden elmondom a Habr olvasóinak, hogy a kódolási folyamat párhuzamosításával hogyan sikerült jelentősen felgyorsítani a videó eljuttatását a felhasználóhoz.

Ez a bejegyzés elsősorban azok számára lesz érdekes, akik korábban nem gondoltak arra, hogy mi történik a videószolgáltatások burkolata alatt. A megjegyzésekben kérdéseket tehet fel, és témákat javasolhat a jövőbeni bejegyzésekhez.

Néhány szó magáról a feladatról. A Yandex nemcsak abban segít, hogy videókat keressen más webhelyeken, hanem videókat is tárol saját szolgáltatásai számára. Legyen szó eredeti műsorról vagy adásban lévő sportmérkőzésről, filmről a KinoPoiskon vagy videókról a Zenen és a News-on – mindezt feltöltjük szervereinkre. Ahhoz, hogy a felhasználók megnézhessék a videót, elő kell készíteni: a szükséges formátumra konvertálni, előnézetet kell készíteni, vagy akár át kell futni a technológián DeepHD. Egy előkészítetlen fájl csak helyet foglal. Sőt, nemcsak a hardver optimális használatáról beszélünk, hanem a tartalom felhasználókhoz eljuttatásának sebességéről is. Példa: egy jégkorongmérkőzés sorsdöntő pillanatának felvétele az esemény után egy percen belül megkereshető.

Szekvenciális kódolás

Tehát a felhasználó boldogsága nagyban függ attól, hogy milyen gyorsan válik elérhetővé a videó. Ezt pedig elsősorban az átkódolási sebesség határozza meg. Ha nincsenek szigorú követelmények a videó feltöltési sebességére vonatkozóan, akkor nincs probléma. Fogsz egyetlen, oszthatatlan fájlt, konvertálsz és feltöltöd. Utunk elején a következőképpen dolgoztunk:

Hogyan gyorsítottuk fel a videó kódolását nyolcszorosára

A kliens feltölti a videót a tárhelyre, az Analyzer komponens összegyűjti a metainformációkat, és átküldi a videót a Worker komponensbe átalakítás céljából. Minden szakaszt egymás után hajtanak végre. Ebben az esetben sok kódolószerver lehet, de csak egy van elfoglalva egy adott videó feldolgozásával. Egyszerű, átlátható diagram. Itt ér véget az előnyei. Ez a séma csak vertikálisan méretezhető (erősebb szerverek vásárlása miatt).

Szekvenciális kódolás köztes eredménnyel

Hogy a fájdalmas várakozást valahogy elsimítsa, az iparág egy gyors kódolási lehetőséggel állt elő. A név félrevezető, mert valójában a teljes kódolás egymás után történik, és ugyanannyi ideig tart. De köztes eredménnyel. Az ötlet a következő: a lehető leggyorsabban készítse elő és tegye közzé a videó alacsony felbontású verzióját, és csak azután nagyobb felbontású verziót.

Egyrészt a videó gyorsabban elérhetővé válik. És fontos eseményeknél hasznos. De másrészt a kép homályos lesz, és ez bosszantja a nézőket.

Kiderült, hogy nemcsak gyorsan kell feldolgoznia a videót, hanem meg kell őriznie a minőségét is. Ezt várják a felhasználók most egy videoszolgáltatástól. Úgy tűnhet, hogy elég megvenni a legproduktívabb szervereket (és rendszeresen frissíteni őket egyszerre). De ez egy zsákutca, mert mindig van egy videó, amely még a legerősebb hardvert is lelassítja.

Párhuzamos kódolás

Sokkal hatékonyabb, ha egy összetett problémát sok kevésbé bonyolultra osztunk, és párhuzamosan oldjuk meg őket különböző szervereken. Ez a MapReduce videóhoz. Ebben az esetben nem korlátoz minket egy szerver teljesítménye, és vízszintesen is méretezhetünk (új gépek hozzáadásával).

Egyébként nem titok, hogy a videókat apró darabokra kell osztani, párhuzamosan feldolgozni és összeragasztani. Sok hivatkozást találhat erre a megközelítésre (például a Habré-n ajánlok egy bejegyzést a projektről DistVIDc). Ez azonban összességében nem könnyíti meg a dolgát, mert nem lehet egyszerűen egy kész megoldást beépíteni az otthonába. Alkalmazkodnunk kell az infrastruktúránkhoz, a videónkhoz és még a terhelésünkhöz is. Általában egyszerűbb sajátot írni.

Tehát az új architektúrában a monolitikus Worker blokkot szekvenciális kódolással mikroszolgáltatásokra osztottuk Segmenter, Tcoder, Combiner.

Hogyan gyorsítottuk fel a videó kódolását nyolcszorosára

  1. A Segmenter a videót körülbelül 10 másodperces töredékekre bontja. A töredékek egy vagy több GOP-ból állnak (képcsoport). Minden GOP független és külön kódolható, így dekódolható anélkül, hogy más GOP-okból származó keretekre hivatkozna. Vagyis a töredékek egymástól függetlenül játszhatók. Ez a felosztás csökkenti a késleltetést, lehetővé téve a feldolgozás korábbi megkezdését.
  2. A Tcoder minden egyes töredéket feldolgoz. Felvesz egy feladatot a sorból, letölt egy töredéket a tárolóból, különböző felbontásokba kódolja (ne feledje, hogy a játékos a csatlakozási sebesség alapján választhat verziót), majd az eredményt visszarakja a tárolóba, és feldolgozottként jelöli meg a töredéket. az adatbázisban. Az összes töredék feldolgozása után a Tcoder elküldi a feladatot, hogy eredményeket generáljon a következő komponens számára.
  3. A Combiner összegyűjti az eredményeket: letölti a Tcoder által készített összes töredéket, streameket generál különböző felbontásokhoz.

Néhány szó a hangzásról. A legnépszerűbb AAC audiokodek kellemetlen tulajdonsággal rendelkezik. Ha a töredékeket külön kódolja, akkor egyszerűen nem fogja őket zökkenőmentesen összeragasztani. Az átmenetek észrevehetőek lesznek. A videokodekeknél nincs ilyen probléma. Elméletileg lehet bonyolult technikai megoldást keresni, de ez a játék egyszerűen még nem éri meg a gyertyát (a hang lényegesen kevesebbet nyom, mint a videó). Ezért csak a videó kódolása történik párhuzamosan, és a teljes hangsáv feldolgozásra kerül.

Álláspontja

A párhuzamos videófeldolgozásnak köszönhetően jelentősen lecsökkentettük a videó hozzánk való feltöltése és a felhasználók számára elérhetővé válása közötti késést. Korábban például egy másfél órás FullHD filmhez több, különböző minőségű teljes verzió elkészítése két órát is igénybe vehetett. Most mindez 15 percig tart. Sőt, párhuzamos feldolgozással még gyorsabban készítünk egy nagy felbontású verziót, mint egy kis felbontású változatot a régi köztes eredmény megközelítéssel.

És még egy dolog. A régi megközelítéssel vagy nem volt elég szerver, vagy tétlenül álltak feladatok nélkül. A párhuzamos kódolás lehetővé teszi a vas-újrahasznosítás arányának növelését. Mostanra a több mint ezer szerverből álló fürtünk mindig el van foglalva valamivel.

Valójában van még hova fejlődni. Például jelentős időt takaríthatunk meg, ha elkezdjük feldolgozni a videó töredékeit, mielőtt az teljes egészében megérkezne hozzánk. Ahogy mondani szokták, jön még.

Írd meg kommentben, hogy a videóval való munkavégzés területén milyen feladatokról szeretnél olvasni.

Hasznos linkek iparági kollégák tapasztalataihoz

Forrás: will.com

Hozzászólás