Hlavní navigace

Video přehrávač od Seznamu: přehrávat video na webu stále není maličkost

22. 9. 2020
Doba čtení: 10 minut

Sdílet

 Autor: Seznam.cz
Seznam.cz je moderní technologická firma, která by se na svých webech jen těžko obešla bez multimédií, zejména pak videa. Co obnáší vývoj vlastního video přehrávače a co všechno musí umět?

Už jste někdy uvažovali nad tím, jak funguje televize? Stisknete tlačítko na dálkovém ovladači a zatímco se kdesi za obrazovkou odehrává nějaká technologická magie, pohodlně se usadíte do křesla a za okamžik už můžete sledovat svůj oblíbený pořad. Zní to opravdu jednoduše, ale skutečně je to tak jednoduché i pod pokličkou? Co kdybyste se rozhodli sestrojit televizní přijímač vlastními silami? „Proč bych něco takového dělal,“ říkáte si asi. 

Co kdyby na trhu neexistovala žádná televize, která by dokázala právě to, co nutně potřebujete? Třeba proto, že na tu vaši se nebudete dívat jen vy, ale také vaši sousedé, jejich sousedé a společně s nimi i velká část této země. A třeba i všichni současně. To už bude chtít opravdu velkou televizi, co říkáte? Co kdyby ona televize nebyla u vás v obýváku, ale někde ve virtuálním prostoru internetu? Seznamte se s video přehrávačem od Seznamu.

Podobně jako většina uživatelů nikdy neměla potřebu uvažovat o tom, jak přesně funguje televize, nemusí ani uživatelé webových služeb Seznamu hloubat nad tím, co obnáší vývoj webového video přehrávače, který je jejich nedílnou součástí. Je to ten známý černý obdélník, nástroj umožňující konzumaci video obsahu tak samozřejmou a intuitivní, že jeho existenci prakticky ani nevnímáte. Jen místo tlačítka na ovladači stisknete tlačítko na obrazovce. Pojďme teď společně nahlédnout do útrob tohoto produktu a poodhalit některé z konceptů, které běžně zůstávají před zraky uživatelů ukryty.

Od Flashe k HTML

První verze webového přehrávače Seznamu byly vytvořené pro platformu Flash, která v té době doslova dominovala multimédiím na webu. Postupem času na to naštěstí zareagovaly i webové prohlížeče a pod záštitou W3C vznikla specifikace Media Source Extension (MSE). Ta umožnila vkládat binární data přímo do bufferů video, resp. audio HTML5 elementu pomocí JavaScriptu a otevřela tak úplně nové možnosti streamování videa na Webu bez použití Flashe. Příchod tohoto technologického milníku umožnil implementaci adaptivního streamování v kombinaci s HTML5 video elementem, které bylo do té doby výsadou Flashe.

Až do loňského roku jste se mohli na obsahových webech Seznamu setkávat s oběma variantami přehrávače, flashovou i HTML. Vzhledem ke klesajícímu počtu klientů, kteří Flash využívali, byla jeho podpora v přehrávači Seznamu definitivně ukončena a nyní spoléhá již výhradně na HTML5 video element právě v kombinaci s MSE.

Od souboru k adaptivnímu streamování

Webový video obsah se stále častěji přesouvá na mobilní zařízení a ruku v ruce s tím jde i potřeba o jeho rychlý přenos, v co nejvyšší kvalitě a přitom s minimální zátěží v podobě množství přenesených dat. Nenávratně pryč jsou tedy doby, kdy k přehrání videa na webu stačil pouhý HTML video element a samotný obsah uložený jako jeden velký soubor v jednom či několika málo video formátech. Štafetu převzalo adaptivní streamování obsahu, které dnes, s výjimkou zastaralých zařízení, hraje v přehrávači Seznamu prim.

Namísto jednoho velkého video souboru stahuje přehrávač pouze malé segmenty (někdy označované jako tzv. chunky), které následně spojuje dohromady a vytváří z nich opět jedno souvislé video resp. audio. Tyto segmenty se mohou vzájemně lišit po stránce datového toku (bitrate), rozlišení i použitých kodeků. Některé mohou obsahovat pouze audio stopu, jiné zase jen video a další obojí najednou. Přehrávač je tak schopen reagovat na výkyvy kvality a rychlosti připojení na straně klienta a poskytovat mu maximální možnou kvalitu obsahu.

Mezi dnes nejpoužívanější standardy pro adaptivní streamování obsahu patří MPEG-DASH a HLS. V Seznamu se lze setkat s oběma z nich, primární volbou zůstává standard HLS, který spatřil světlo světa jako první (již v roce 2009) a byl vyvinut společností Apple jako standard pro adaptivní streamování na jejich zařízeních (nepodporujících Flash). Tato technologie původně stavěla na transportním kontejneru MPEG-TS přepravujícím video data nejčastěji v kodeku MPEG-4 AVC (též známý jako H.264) a audio data zpravidla v kodeku AAC.

Kontejner MPEG-TS ovšem nemá své kořeny na webu. Vznikl již několik dekád před příchodem HLS pro účely televizního vysílání (tehdy v kombinaci s kodekem MPEG-2) a práce s ním na webu má svá specifika. Zejména u nižších datových toků přináší významnou režii a s výjimkou několika málo prohlížečů (např. Safari právě od společnosti Apple) není přímo podporován HTML elementem video. Protože ale na mobilních zařízeních od Applu (s operačním systémem iOS) není k dispozici rozhraní MSE, představuje zde HLS jedinou cestu k adaptivnímu streamování obsahu.

Vzniká tak zásadní otázka: Je v rámci dosažení maximální kompatibility se všemi typy zařízení opravdu nutné ukládat data v několika formátech, a tím efektivně znásobit potřebnou kapacitu pro jejich uložení? Nebo je možné nějak docílit podpory formátu MPEG-TS na straně prohlížečů? Řešením se ukázalo být dynamické přebalování dat (audio a video rámců) do jiného transportního formátu (tzv. remuxing) podporovaného většinou moderních prohlížečů, pokud možno s minimální režií a dobrou dokumentací. Takovým formátem je fMP4 (fragmentované MP4), který je výchozí volbou také v případě standardu MPEG-DASH. Při stažení každého MPEG-TS segmentu tak v přehrávači dochází k jeho detailnímu parsování až na úroveň jednotlivých audio a video rámců, pro které se vytvoří nová obálka ve formátu fMP4.

Když v roce 2016 zařadila společnost Apple podporu formátu fMP4 do svého standardu HLS, vypadalo to, že se bude při adaptivním streamování konečně možné obejít bez parsingu binárních dat na straně klienta. Realita už tak idylická bohužel není. Audio a video rámce, coby základní jednotky tohoto typu obsahu, mají definovanou časovou značku svého začátku, aby byla možná jejich dokonalá synchronizace. Časová značka prvního rámce v pořadí, který je třeba přehrát, však obecně nemusí být nulová. Obsah se nemusí přehrávat od začátku anebo může být tvořen několika skupinami segmentů s nesourodými časovými značkami (hovoříme pak o tzv. diskontinuitách).

Před vložením dat do bufferu video resp. audio HTML elementu je tak třeba zajistit, aby byly časové značky spojité a udávaly skutečný čas, kam se mají data v bufferu vložit. Tímto přepočtem vznikají drobné nepřesnosti, které mají za následek miniaturní trhliny v bufferu, jež je třeba zacelit, aby nedocházelo k pozastavení přehrávání. Ani v případě fMP4 segmentů se tak přehrávač Seznamu neobejde bez jejich parsingu za účelem zjištění a korekcí časových značek.

Protože audio rámce AAC a video rámce AVC obecně nezačínají na stejných časech (kvůli odlišným délkám rámců audia a videa ani nemohou), je třeba řešit i situace, kdy na začátku a konci obsahu schází miniaturní kousek videa či naopak audia. Řešením je prodlužování délky video rámců, resp. vkládání nových audio rámců s tichem. Pokud se tedy rozhodnete implementovat vlastní přehrávač, pravděpodobně se neobejdete bez generátoru schopného vyprodukovat požadovaný počet prázdných audio rámců v požadovaném kodeku, které případné přílišné nesourodosti v časových značkách začátku audio a video stopy snižují na minimum bezpečně tolerované prohlížeči.

HLS

V kontextu adaptivního streamování zde byl již několikrát zmíněn standard HLS. Pojďme se trochu blíže podívat jak funguje. Jak už sám jeho název (HTTP Live Streaming) napovídá, staví nad protokolem HTTP, který zajišťuje vlastní přenos dat. Díky tomu odpadá potřeba dodatečné infrastruktury pro distribuci obsahu nad rámec té používané přímo pro web.

K popisu obsahu používá standard HLS tzv. playlisty, též označované jako manifesty. Hlavní (master) manifest definuje varianty (s určitým rozlišením, bitratem, kodekem atd.), ze kterých si lze vybrat. Lze je chápat jako rozdílné kvality téhož obsahu, mezi kterými si klient dynamicky volí právě tu, která nejlépe odpovídá jeho rychlosti připojení.

Manifest konkrétní varianty uvádí seznam segmentů (vč. jejich délek), kterými je tvořena a které obsahují požadovaná audio resp. video data. Kromě variant může hlavní manifest definovat také alternativní stopy (audio i video), mezi kterými může uživatel přepínat. Typicky se jedná o audio stopy v odlišné jazykové mutaci. Manifesty používají formát M3U8, tj. Unicode verzi formátu M3U. Jedná se o jednoduchý textový formát rozlišující příkazy uvozené znakem # a data. Jako oddělovač slouží znak konce řádku.

HLS podporuje nejen VOD (Video On Demand) obsah, ale také živá vysílání. Manifest se segmenty v takovém případě samozřejmě nemůže obsahovat kompletní výčet všech (dosud ještě neexistujících) segmentů. Místo toho se zde nachází pouze několik málo segmentů a na konci manifestu schází značka #EXT-X-ENDLIST. Přehrávač následně v pravidelných intervalech znovu načítá manifest a postupně stahuje segmenty, které se v něm nově objevily.

Od adaptivního obsahu k adaptivnímu UI

Všimli jste si někdy, v kolika různých velikostech můžete přehrávač Seznamu potkat na jeho obsahových webech? Tyto weby jsou samozřejmě responzivní, což přináší zajímavý problém. Jak zajistit to, aby byla samotná komponenta přehrávače také responzivní a dokázala tak reagovat na změny ve stránce?

První verze přehrávače Seznamu řešily tento problém hned několika samostatnými verzemi uživatelského rozhraní (UI), mezi kterými se přepínalo na základě detekovaných vlastností klienta. To přirozeně není ideální a nelze tak postihnout všechny myslitelné scénáře. Zejména situace, kdy změnu ve stránce iniciuje přímo webová aplikace a nikoli změna velikosti okna prohlížeče (detekovatelná pomocí události  resize).

Technologie mezi tím naštěstí dozrála a do většiny prohlížečů se dostala podpora rozhraní ResizeObserver. S jeho pomocí lze implementovat skutečně responzivní komponenty, které průběžně sledují svou velikost a podle toho uzpůsobují vzhled svého uživatelského rozhraní, bez ohledu na to, co za změnou velikosti stálo. V případě přehrávače Seznamu toto rozhraní umožňuje konzumovat video na mobilu, tabletu nebo klasickém počítači a využívat při tom jediné uživatelské rozhraní přehrávače, které jen s použitím CSS mění svůj vzhled.

U uživatelského rozhraní přehrávače ještě chvíli zůstaneme. Na první pohled to tak ani nevypadá, ale tvoří ho více jak stovka komponent zasazená do téměř desítky různých rozvržení (video, audio, rádio atd.) – nejrůznější tlačítka, nabídky, panely, doplňující informace o obsahu, výčty doporučených videí a mnohé další prvky. Celá řada z nich se musí často aktualizovat a překreslovat. Některé dokonce v každém animačním rámci, tj. až 60krát za vteřinu.

Naše měření ukázala, že při spuštění přehrávače může i více než polovinu celkové doby trvat jen vykreslení UI a podobné je to s vytížením klientova CPU v průběhu přehrávání. Na základě tohoto zjištění jsme začali hledat způsob, jak překreslování UI zrychlit a co nejvíce ho omezit.

Jako jednoznačně nejvýkonnější se v našem případě ukázalo řešení využívající funkcionalitu JavaScriptu (konkrétně verze ES6) s názvem template literals. Na její bázi vznikla celá řada knihoven pro vykreslování UI. Pro její jednoduchost, robustnost a technologickou vyspělost jsme zvolili HyperHTML v kombinaci s Reduxem pro ukládání stavových informací. Že to nebyla volba špatná, dokládají čísla. Tato změna technologie, realizovaná v loňském roce, měla za následek až trojnásobné zrychlení úvodního načtení a snížení zatížení CPU při přehrávání až na pětinu. Od té doby dozrála do produkčního stavu řada dalších knihoven podobného ražení jako zmíněný HyperHTML. Za zmínku určitě stojí µhtml, která je ještě o něco menší a rychlejší a úspěšně se osvědčila v našich nejnovějších projektech.

Backend

Přehrávač od Seznamu netvoří pouze jeho klientská část, která přehrává samotný obsah. Má také svůj backend sloužící pro analytické účely. Že to není jen tak ledajaký backend, dokazuje množství požadavků, které musí být schopen odbavit.

Umíte si představit 100 požadavků za sekundu? A co třeba 10 000? Připadá-li vám to jako hodně, věřte, že se jedná o běžnou zátěž v průběhu dne. Ve špičkách se musí backend postavený na platformě Node.js a napsaný v jazyce TypeScript umět poprat i s mnohonásobkem těchto hodnot.

Právě díky těmto parametrům se jednalo o projekt doslova předurčený pro Node.js. V rámci zajištění co možná nejvyššího výkonu jsme nakonec nesáhli po osvědčeném webovém aplikačním frameworku Express, ale po jeho výrazně rychlejší alternativě nesoucí název Fastify.

UX DAy - tip 2

Mnoho dalších funkcí

Je zřejmé, že přehrávač musí být schopen především přehrávat obsah. K němu se však váže i celá řada dalších, doplňkových funkcí. Od implementace plejády API (PIP, AirPlay, Google Cast atd.), komunikace s reklamními systémy až po zobrazování titulků a doporučeného následujícího obsahu.

Náš přehrávač neslouží jen ke sledování videa. Na domovské stránce Seznamu najdete nově i rádio přehrávač, na webu Seznam Zprávy zase přehrávač podcastů. Výčet dalších funkcí a jejich technologických detailů by mohl ještě dlouho pokračovat. Třeba si o nich řekneme něco víc zase jindy.

Byl pro vás článek přínosný?

Autor článku

Pracuje jako vedoucí vývojového týmu ve společnosti Seznam.cz. Zabývá se technologiemi souvisejícími s videem na webu a vývojem webových aplikací.