Weblabor

Jó pár éve volt egy online-tévés téma a Weblaboron. Most a HTML5 videó kapcsán talán ideje pár szót ejteni a mai helyzetről. Alig több, mint egy éve bonyolították a világ első élő WebM közvetítését. Nyílt forrású projektet azonban azóta sem találtam a feladatra. Az apropót a cikkhez egy napokban debütált munkadarabom adta: ajánlom a nagyérdemű figyelmébe.

Az online média tájkép négy és fél évvel (a régi téma indítása óta) meglehetősen átrendeződött. A Flash egyeduralkodó lett, emellett a H.264 tündöklése után remélhetőleg bukása következik.

Eközben erőre kapott a HTML5, és életre hívta új kedvencünket, a WebM formátumot (ami a már korábban is nyílt Ogg Vorbis és a Google által felszabadított On2 VP8 házasságából született, a Matroska konténer vigyázó bábáskodása alatt).

Média kiszolgálása

Egy előre rögzített média fájl kiszolgálása nem egy bonyolult dolog. Ha pusztán annyit teszünk, hogy „padlógáz” helyett a média bitrátájával szolgáljuk ki a fájlt, már el is végeztük a munka oroszlánrészét. Kényelmi szolgáltatásként ezt még kibővíthetjük: mondjuk az első egy megát maximális sebességgel leadjuk a kliensnek, aki így teli pufferrel biztonságban érezheti magát, és el is kezdheti játszani a videót. Bár megjegyezném, hogy a pufferelés manapság kihalófélben lévő mesterség. A kényelem jegyében a legtöbb lejátszó azonnal nekikezd a lejátszásnak, és reménykedik, hogy a kiszolgálás zavartalan lesz (meg hogy egy kis puffert majd menet közben is fel tud tölteni).

Töredékek

Élő videó kiszolgálása némileg trükkösebb feladat. A médiába menet közben kell bekapcsolódni. A mozgókép tömörítésénél a legalapvetőbb dolog az, hogy az egyes képkockák közötti különbségeket rögzítjük ahelyett, hogy minden egyes képet külön-külön tömörítenénk. Egy képkocka hivatkozhat egyszerre több másikra is, amelyek tartalma elegedhetetlen a jelen kép kiszámításához. Könnyen belátható, hogy egy élő stream esetén vagy lemondunk erről a lehetőségről (vagyis csak kulcsképkockákat használunk), amivel a tömörítés legfontosabb eszközét veszítenénk el, vagy szükség van önálló egységekre, amik egymástól függetlenül kezelhetők.

Ezek az egységek a fragmentek (töredékek). Egy töredék mindig kulcsképkockával kezdődik (ez egy önmagában dekódolható állókép, nem tartalmaz hivatkozást megelőző kockára). Az ezt követő képkockák már számíthatnak arra, hogy az előttük érkezőknek birtokában vagyunk, így már használható a különbség-alapú tömörítés.

Élő adás sugárzása

Élő adásnál van héhány könnyebbség és pár nehezítés a képleten. Először is nem kell bitrátákkal foglalkoznunk, hiszen a feltöltés eleve a valódi bitrátával történik, így ahogy a tartalom elérhetővé válik, küldhetjük is a nézőknek (a statikus fájllal ellentétben, ahol célszerű nekünk ütemezni a kiszolgálás sebességét).

Plusz feladat viszont, hogy a WebM (vagyis a Matroska) nem tartalmaz strukturális elemet (metaadatot) a töredékek jelzésére, azaz nekünk kell detektálnunk a kulcsképkockákat, és ezek ismeretében felépíteni a töredékeket szállító darabokat.

A folyamat

1. A feltöltőtől beérkezik a fejléc (A), ezt egy külön pufferben megőrizzük, minden kliens ezt fogja megkapni csatlakozás után, hiszen ennek tartalma változatlan lesz a stream életciklusa alatt.
2. Egy töredéképítő pufferben (B) elkezdjük építeni az első töredéket, ezalatt a kliens nem kap adatot, neki csupán kész töredékeket küldünk. Ez addig folytatódik, amíg új kulcsképkocka nem érkezik (ami a következő töredék része lesz).
3. A (B) puffert átmentjük az aktuális töredék pufferbe (C), a kliens szál időről időre ellenőrzi, érkezett-e új töredék, ha igen, ezt azonnal elküldi a néző gépére, majd várakozó állásba helyezkedik.

A 2. és 3. lépések ismétlődnek a stream kiszolgálása alatt. A töredékeket sorszámmal látjuk el, így a kliens szál érzékeli, amikor elérhető új információ. Ezzel a módszerrel az egyes szálak érzékelhetik, hogyha a sorszám egynél többel nőtt, ami arra utal, hogy (lassú átvitel miatt) fragment skip történt. Ilyenkor dönthetünk, hogy bontjuk a kapcsolatot, esetleg átlépünk egy alacsonyabb bitrátás módba.

„Képeslap” módszer

Érdekes fejleszési irány lehet egy csökkentett stream, ami a teljes audio mellett a videó tartalomból csak a kulcsképkockákat küldi el. A szerver automatikusan átállhat erre a módra lassú kapcsolatok esetén. Így az élő hang mellett 1-2 másodpercenként frissülő „diafilmként” élvezhető az adás újrakódolás nélkül.

HTTP alapú kiszolgálás

A kiszolgálás maga HTTP fölött történik, lényegében egy fájlt emulálunk. Egyelőre nincs rögzítve szabványban, hogyan vihetjük át a WebM médiát UDP vagy RTP protokol fölött. Konténerformátumnak csak a Matroskát választhatjuk, így kiesik a TS vagy az ISO konténer (.mp4), amiknél már lefektetett az csomagolás módja ezekre a protokolokra.

A programról

A minta a Shoutcast volt, amit egyszerűen elindítva a szerveren, bonyolult konfigurálás nélkül haszálhatunk átjátszóként a kliensek fele. Ez tarthatónak bizonyult.

Egy ajaxos sávszélesség monitor is megtalálható a csomagban, ez tizedmásodperc felbontással jeleníti meg a bejövő és kimenő bájtok számát az adott időszeletben. Remélhetőleg ezzel könnyen lokalizálhatók az esetleges hálózati problémák. Az egyes töredékek is fel vannak tüntetve a grafikonokon, kontextusba helyezendő az adatokat. A fejlesztés Google Chrome-on zajlott, egyelőre csak itt lett tesztelve.

További lehetőség itt egy „sávszélesség tipp” funkció, ami a csúcsok és átlagsebesség alapján megtippeli a valódi sávszélesség kihasználtságát (a szolgáltatótól kapott 100 Mbit nem mindig annyi amennyinek tűnik).

CDN-be kötéshez könnyen fejleszthető egy polling alapú input funkció, amikor nem egy klienstől várjuk a feltöltést, hanem az aktuális szerver proxy-ként képes átvenni egy másikra publikát streamet, így egyes site-ok között elég egyetlen példányban átvinni az adást, ami itt tovább osztható.

Hogyan tovább

A jelenlegi programban a kellő refaktorizáció nélkül lettek új funciók (például a sávszélesség mérése) implementálva, és amúgy is az első inkarnáció. Ráférne néhány óra áramvonalasítás.

Sok extra funkcióra van még lehetőség, de több órát nincs kedvem beleölni amíg nem látom, hogy van-e értelme, helye egy ilyen szervernek.

Szivesen rendeznék egy tesztet nagyobb méretben (jelenleg 5-6 kliensnél nem próbáltam többel).

Hol?

A Google Project Hostingján elérhető a forrás és egy fordított verzió. Ezúton invitálnék mindenkit kipróbálásra, akit érdekel a téma.