Každý den sledují videa na internetu miliony diváků. Aby však bylo video dostupné, musí být nejen nahráno na server, ale také zpracováno. Čím rychleji k tomu dojde, tím lépe pro službu a její uživatele.
Jmenuji se Askar Kamalov, před rokem jsem se připojil k týmu videotechnologie Yandex. Dnes stručně povím čtenářům Habra o tom, jak se nám paralelizací procesu kódování podařilo výrazně zrychlit doručení videa k uživateli.
Tento příspěvek bude zajímat především ty, kteří dosud nepřemýšleli o tom, co se děje pod poklicí video služeb. V komentářích můžete klást otázky a navrhovat témata pro budoucí příspěvky.
Pár slov k samotnému úkolu. Yandex vám nejen pomáhá hledat videa na jiných webech, ale také ukládá videa pro své vlastní služby. Ať už jde o originální program nebo sportovní zápas ve vysílání, film na KinoPoisk nebo videa na Zen a News – to vše se nahrává na naše servery. Aby uživatelé mohli video sledovat, musí být připraveno: převést do požadovaného formátu, vytvořit náhled nebo dokonce projít technologií . Nepřipravený soubor jen zabírá místo. Navíc se nebavíme jen o optimálním využití hardwaru, ale také o rychlosti doručování obsahu uživatelům. Příklad: záznam rozhodujícího okamžiku hokejového utkání lze vyhledat do minuty po samotné události.
Sekvenční kódování
Štěstí uživatele tedy do značné míry závisí na tom, jak rychle bude video dostupné. A to je dáno především rychlostí překódování. Pokud neexistují žádné přísné požadavky na rychlost odesílání videa, neexistují žádné problémy. Vezmete jeden nedělitelný soubor, převedete ho a nahrajete. Na začátku naší cesty jsme pracovali takto:
Klient nahraje video do úložiště, komponenta Analyzer shromažďuje meta informace a přenáší video do komponenty Worker ke konverzi. Všechny fáze se provádějí postupně. V tomto případě může existovat mnoho kódovacích serverů, ale pouze jeden je zaneprázdněn zpracováním konkrétního videa. Jednoduchý, transparentní diagram. Zde jeho výhody končí. Toto schéma lze škálovat pouze vertikálně (kvůli nákupu výkonnějších serverů).
Sekvenční kódování s mezivýsledkem
Aby se nějak vyrovnalo bolestivé čekání, průmysl přišel s možností rychlého kódování. Název je zavádějící, protože ve skutečnosti k úplnému kódování dochází postupně a trvá stejně dlouho. Ale s průběžným výsledkem. Myšlenka je tato: připravit a publikovat verzi videa v nízkém rozlišení co nejrychleji a teprve poté verze s vyšším rozlišením.
Na jedné straně je video dostupné rychleji. A hodí se to při důležitých událostech. Ale na druhou stranu je obraz rozmazaný a to diváky obtěžuje.
Ukazuje se, že musíte video nejen rychle zpracovat, ale také udržet jeho kvalitu. To je to, co nyní uživatelé od video služby očekávají. Může se zdát, že stačí koupit ty nejproduktivnější servery (a pravidelně je upgradovat všechny najednou). To je ale slepá ulička, protože se vždy najde video, které zpomalí i ten nejvýkonnější hardware.
Paralelní kódování
Mnohem efektivnější je rozdělit komplexní problém na mnoho méně složitých a řešit je paralelně na různých serverech. Toto je MapReduce pro video. V tomto případě nejsme omezeni výkonem jednoho serveru a můžeme horizontálně škálovat (přidáním nových strojů).
Mimochodem, myšlenka rozdělovat videa na malé kousky, zpracovávat je paralelně a slepovat je není žádným tajemstvím. Na tento přístup můžete najít mnoho odkazů (například na Habrém doporučuji příspěvek o projektu ). To to ale celkově neusnadňuje, protože nemůžete jen tak vzít hotové řešení a zabudovat ho do svého domova. Potřebujeme přizpůsobení naší infrastruktuře, našemu videu a dokonce i našemu zatížení. Obecně je jednodušší napsat vlastní.
V nové architektuře jsme tedy rozdělili monolitický blok Worker se sekvenčním kódováním na mikroslužby Segmenter, Tcoder, Combiner.
- Segmenter rozdělí video na fragmenty o délce přibližně 10 sekund. Fragmenty se skládají z jedné nebo více GOP (). Každá GOP je nezávislá a kódovaná samostatně, takže ji lze dekódovat bez odkazu na snímky z jiných GOP. To znamená, že fragmenty lze přehrávat nezávisle na sobě. Toto sharding snižuje latenci, což umožňuje zahájení zpracování dříve.
- Tcoder zpracovává každý fragment. Vezme úkol z fronty, stáhne fragment z úložiště, zakóduje jej do různých rozlišení (nezapomeňte, že hráč si může vybrat verzi podle rychlosti připojení), poté uloží výsledek zpět do úložiště a označí fragment jako zpracovaný. v databázi. Po zpracování všech fragmentů Tcoder odešle úkol, aby vygeneroval výsledky pro další komponentu.
- Combiner shromažďuje výsledky dohromady: stahuje všechny fragmenty vytvořené Tcoderem, generuje proudy pro různá rozlišení.
Pár slov o zvuku. Nejoblíbenější audio kodek AAC má nepříjemnou vlastnost. Pokud fragmenty kódujete samostatně, pak je jednoduše nebudete moci bez problémů slepit. Přechody budou patrné. Video kodeky tento problém nemají. Teoreticky můžete hledat složité technické řešení, ale tahle hra prostě zatím nestojí za svíčku (audio váží výrazně méně než video). Paralelně se tedy kóduje pouze video a zpracovává se celá zvuková stopa.
výsledky
Díky paralelnímu zpracování videa jsme výrazně zkrátili prodlevu mezi nahráním videa k nám a zpřístupněním uživatelům. Například dříve mohlo vytvoření několika plných verzí různé kvality pro film FullHD trvající hodinu a půl trvat dvě hodiny. Nyní to vše trvá 15 minut. Navíc s paralelním zpracováním vytváříme verzi s vysokým rozlišením ještě rychleji než verzi s nízkým rozlišením se starým přístupem k mezivýsledkům.
A ještě jedna věc. Se starým přístupem buď nebyl dostatek serverů, nebo byly nečinné bez úkolů. Paralelní kódování umožňuje zvýšit podíl recyklace železa. Nyní je náš cluster s více než tisíci servery neustále něčím zaneprázdněn.
Ve skutečnosti je stále co zlepšovat. Můžeme například ušetřit značný čas, pokud začneme zpracovávat fragmenty videa dříve, než k nám dorazí celé. Jak se říká, další přijdou.
Napište do komentářů, o jakých úkolech v oblasti práce s videem byste si rádi přečetli.
Užitečné odkazy na zkušenosti kolegů z oboru
Zdroj: www.habr.com