ugrás a tartalomhoz

WebM alapú élő közvetítés

vbence · 2011. Feb. 22. (K), 21.48
WebM alapú élő közvetítés

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.

 
vbence
Twitter: #vbwow
1

Érdekes és hasznosnak tűnő projekt

Poetro · 2011. Feb. 22. (K), 23.36
Érdekes és hasznosnak tűnő projekt. Mondjuk azt sajnálom, hogy Java alatt készült, és nem Python, Ruby, JavaScript hármasból valamelyikben.

A forrás link URLjéből hiányzik egy h.
2

Tetszett

zzrek · 2011. Feb. 23. (Sze), 17.34
Tetszett a cikk, nagyon jól összefoglalta a lényeget. Szeretem az ilyet, köszönöm!
3

Nagyon jó ötletek vannak a

virág · 2011. Feb. 26. (Szo), 19.54
Nagyon jó ötletek vannak a cikkben!
(A végén a "fordítottt" szóban 3 darab "t" betű van :))
4

Kösz, javítottam.

Joó Ádám · 2011. Feb. 26. (Szo), 23.54
Kösz, javítottam.
5

Köszi

vbence · 2011. Feb. 28. (H), 15.20
Köszönöm a méltató hosszászólásokat. A teljes kép érdekében megtoldanám egy (eredetileg is tervezett) bekezdéssel. A "HTTP alapú" bekezdés elé be is illik, ha megérhetek egy szerkesztőt a módosításra.

WebP

Korábban említettem, hogy a kulcsképkockák (keyframe) önmagukban tartalmazzák a teljes képkocka anyagát (másokra való hivatkozás nélkül). Ez függetlenül igaz minden video tömörítési eljárásra. A Google, saját szabványával megtette azt a logikus lépést amit eddig valami rejtélyes okból mindegyik tömörítő elfelejtett. Vagyis, hogy egy kulcsképkocka a multimédia fájlból kiemelve egy önálló képfájllal megegyező módon legyen használható.

Eltekintve attól, hogy az adott tömörítési eljárás jobb vagy rosszabb eredményeket hoz állóképek esetén a jól bevált JPEGnél, a lépés ár/érték aránya vitathatatlan. Képzeljük csak el milyen szerver oldali aparátus szükséges egy pillanatkép kinyerésére például egy H.264 adafolyamból. Ezzel szemben WebM esetén csak meg kell keresnünk a kulcsképkockákat és egy 20 bájtos fejléc hozzáadásával már is WebP képeink vannak.
7

Kép kinyerése - H264

Hodicska Gergely · 2011. Már. 12. (Szo), 13.42
Nálunk van live thumbnail a streamekre, és simán a streamből van a kép kimentve minden módosítás nélkül. FMS szerverenként simán 2-300 streamből készül x másodpercenként live thumbnail.
9

Lehetséges

vbence · 2011. Már. 12. (Szo), 15.03
Nem mondtam, hogy lehetetlen, de erőforrás tekintetében ég és föld a különbség. H.264-nél dekódolnod kell a képet és újratömöríteni JPEG vagy PNG formátumba, nem tudod az inta frémet egyből elküldeni ahogy van. - Gondolom a frissítés gyakorisága az erőforrás-kihasználtság függvényében változhat, a WebM-es megoldásnál viszont gond nélkül megkaphatod az utolsó keyframe-t, ami kb 2 másodrces frissítést jelent.
6

H624?

Hodicska Gergely · 2011. Már. 12. (Szo), 13.38
Mi bajod van a H264-gyel?
8

tippre a royalty fee. Tyrael

Tyrael · 2011. Már. 12. (Szo), 14.50
tippre a royalty fee.

Tyrael
10

szoftver-szabadalmak

vbence · 2011. Már. 13. (V), 13.57
Technikailag nincs vele problémám. Nem ismerem eléggé ahhoz. A probléma a szoftver-szabadalmakkal van. Az 5 millió USD amit egy alternatív böngészőnek kéne fizetnie hogy kompatibilis legyen. Minden eszköz ami igyekszik itt tartani csak meghosszabbítja a fájdalmas átmeneti időszakot amíg valami nyílt technológia átveheti a helyét, ami tudom, nem holnap lesz. - De merjünk nagyot álmodni :)

Melelsleg olyannyira nincs bajom vele, hogy az első verzió fragmetned h264 alapú volt (TS over UDP-t muxolt át fragmetned MP4be keyframe-ek detektálásával), csak aztán észrevettem, hogy a Chrome nem tudja streamelni, hiába volt MOOF alapú. Persze, nem a Chrome a világ közepe, de a WebM-nek legalább esélye van, hogy a HTML5 de facto videoformátuma legyen.
11

apple

Hodicska Gergely · 2011. Már. 17. (Cs), 23.16
Defacto szvsz sosem lesz. Ráadásul a H264 ingyenessé tételével totálisan ki lehetne nyírni, mert onnantól nincs létjogosultsága.
12

Amire kíváncsi lennék

vbence · 2011. Már. 17. (Cs), 23.36
A VP8 mellett szokták felhozni hogy ksiebb a processzorigénye. Jelenleg a H.264 kódolásért/dekódolásért külön hardveres egység felel a mobilokban/kamerákban. Egy olcsó, minőségi codec akár új kategóriájú eszközökhöz is vezethet az ár-érzékeny vásárlókat megcélzó off-brandek (bárcsak tudnám szebben mondani) kínálatában. - Mint ahogy annak idején a flash drive alapú MP3 lejátszó is a nóném gyártók kínálatából indult.
13

"Ráadásul a H264 ingyenessé

Tyrael · 2011. Már. 18. (P), 10.38
"Ráadásul a H264 ingyenessé tételével totálisan ki lehetne nyírni, mert onnantól nincs létjogosultsága."
bar csak ott tartanank, hogy ingyenesse tettek a h264-et, es a webm-et temetnenk.
viszont a jelenlegi szituacioban en orulok neki, hogy terjed a webm, es ha valaki video contentet akar hostolni/streamelni a neten, akkor van lehetoseg normalis minosegben royalty free modon megtenni ezt.

Tyrael
14

Fejlemények

vbence · 2014. Szep. 28. (V), 19.00
Némi kihagyás után rászántam az időt hogy felrázzam a projektet.

Megérkezett a H.264 (és AAC) támogatás, lett beépítettt RTMP szerver és átköltözött mindenki kedvenc Githubjára.

Aki unatkozik tessen kipróbálni:
stream-m a githugon