ctstream 5 aneb HTML5 podle Apple

17.2.2012 23:04 | Přečteno: 2921×

Pátá verze nástroje pro sledování vysílání České televize po Internetu přidává podporu pro čistý HTTP přenos.

Možná jste si všimli, že naše veřejnoprávní televize seznala, že přehrávání skrze SWF není univerzální, a tak nabídla HTML5 verzi.

Samozřejmě nic není, jak se zdá. HTML5 verzi dostanete jen na zařízeních od firmy Apple. Server věští z hlavičky User-Agent, takže s Firefoxem vyzbrojeným rozšířením User Agent Switcher se lze dopracovat k takovémuto iframu:

<div id="iPlayer">
	<video>
	</video>
</div>

Nepsaným požadavkem je JavaScript, který po rozhovoru s DRM systémem serveru doplní potřebné atributy:

<video xmlns="http://www.w3.org/1999/xhtml" tabindex="0" poster="http://img5.ceskatelevize.cz/ivysilani/gfx/empty/player.jpg" src="http://wcdn34.nacevi.cz/CT24/_definst_/smil:CT24-ios-MP4_Web.smil/playlist.m3u8?id=MTQzMDg5MTcyOHw2MzQ2NTExMzE1MzQ4NTAwMDA=&amp;type=wpl" style="width: 636px; height: 357px;">
</video>

Firefox správně vykreslí podokno přehrávače, ale také skončí s hláškou Ouha, video se nepodařilo načíst. Zkuste to prosím znovu, nebo se podívejte do nápovědy.

Problém je totiž v tom, co klient dostane z odkazované adresy: dostaně zvláštní M3U playlist s MIME typem application/vnd.apple.mpegurl.

Jedná se o zvláštní playlist, který Apple chce standardizovat pod názvem HTTP Live Streaming. Princip tohoto způsobu šíření multimédií je následující:

Playlist nese (mimo jiné) seznam alternativních datových toků, což není nic jiného než seznam odkazů na playlisty druhé úrovně. Na druhé úrovni se již nachází adresy multimédií. Jednotlivé adresy avšak nejsou nekonečné proudy, jedná se o krátké (například 10sekundové) segmenty, které přehrávač má za úkol postahovat a přehrát v pořadí, v jakém jsou uvedeny v playlistu. Přehrávač pak načte playlist ze stejné adresy znovu a v něm najde adresy následujících segmentů. A takto může pokračovat do nekonečna.

Netřeba dodávat, že mnohé přehrávače si s takovým playlistem zatím neporadí.

Proto jsem ctstream rozšířil o možnost vypsat playlist:

$ ctstream -A -l http://www.ceskatelevize.cz/ivysilani/zive/ct24/
2000: http://wcdn34.nacevi.cz/CT24/_definst_/ct24live1.sdp/playlist.m3u8?id=MTQzMDk1MjI1MXw2MzQ2NTExNTUzMzg0NDM3NTA%3D&wowzasessionid=1731073766&type=wpl
1000: http://wcdn34.nacevi.cz/CT24/_definst_/ct24live2.sdp/playlist.m3u8?id=MTQzMDk1MjI1MXw2MzQ2NTExNTUzMzg0NDM3NTA%3D&wowzasessionid=1731073766&type=wpl
500: http://wcdn34.nacevi.cz/CT24/_definst_/ct24live3.sdp/playlist.m3u8?id=MTQzMDk1MjI1MXw2MzQ2NTExNTUzMzg0NDM3NTA%3D&wowzasessionid=1731073766&type=wpl

možnost vypsat potenciálně nekonečný seznam adres jednotlivých segmentů vybraného datového toku:

$ ctstream -A -f http://www.ceskatelevize.cz/ivysilani/zive/ct24/ 500
http://wcdn34.nacevi.cz/CT24/_definst_/ct24live3.sdp/media_14901.ts?id=MTQzMDk1NTMyM3w2MzQ2NTExNTY2NDg0NDM3NTA%3D&wowzasessionid=821653514&type=wpl
http://wcdn34.nacevi.cz/CT24/_definst_/ct24live3.sdp/media_14902.ts?id=MTQzMDk1NTMyM3w2MzQ2NTExNTY2NDg0NDM3NTA%3D&wowzasessionid=821653514&type=wpl
http://wcdn34.nacevi.cz/CT24/_definst_/ct24live3.sdp/media_14903.ts?id=MTQzMDk1NTMyM3w2MzQ2NTExNTY2NDg0NDM3NTA%3D&wowzasessionid=821653514&type=wpl
^C

a možnost chrlit multimediální proud na standardní výstup:

$ ctstream -A -s http://www.ceskatelevize.cz/ivysilani/zive/ct24/ 500 | mplayer -cache 2048 -noconsolecontrols -
MPlayer SVN-r34625 (Gentoo)-4.5.3 (C) 2000-2012 MPlayer Team

Přehrávám -
Čtu ze std. vstupu...
Naplnění cache: 17.52% (367357 bajtů)   

libavformat version 53.31.100 (external)
Detekován formát souboru TS.
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
VIDEO H264(pid=256) AUDIO AAC(pid=257) NO SUBS (yet)!  PROGRAM N. 1
FPS seems to be: 25.000000
Load subtitles in ./
Cache not responding! [performance issue]
Cache not responding! [performance issue]
Otevírám video filtr: [eq2]
==========================================================================
Otevírám video dekodér: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 53.60.100 (external)
Vybrán video kodek: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Pokouším se vynutit rodinu audiokodeku -dmo...
Pokouším se vynutit rodinu audiokodeku ...
Otevírám audio dekodér: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->192000)
Vybrán audio kodek: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Začínám přehrávat...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
Poměr stran obrazu filmu je 1.78:1 - škáluji na správný poměr.
VO: [xv] 512x288 => 512x288 Planar YV12 

Jak je vidět z výpisu, tak se jedná o H.264 video a AAC zvuk zabalený do kontejneru MPEG-2 TS.

       

Komentáře

[xkucf03]

Jedním slovem: sračka. Aneb, jak zmrvit relativně dobrou a jednoduchou* technologii :-/

Tobě díky za zápisek a za program. Lidi v ČT a Applu nakopat…

*) ne že by to bylo ideální, to ani zdaleka, ale zpočátku to vypadalo neuvěřitelně skvěle – na stránce bude odkaz na soubor s videem a prohlížeč ho přehraje, nebo si ho uživatel stáhne a všechno bude stejně jednoduché a průzračné jako práce s obrázky. Ale asi to bylo moc dobré, než aby se to stalo skutečností. (on to mrví i Google/YouTube, ale ne tolik, aby to nešlo používat)

[Jendа]

Why? Somebudy please tell me why!

My vysíláme přes HTTP FLV kontejner, ve kterém je H.264+AAC. Přehraje to jak flashový nesmysl, tak normální přehrávače (testovány MPlayer a VLC). Záznamy jsou dostupné v MKV s tímtéž, ke stažení po obyčejném HTTP.

Můžete mi někdo vysvětlit, v čem je nevýhoda našeho řešení, a proč ČT nemůže udělat totéž?

[Grunt]

Why? Somebudy please tell me why!

Tohle se řeší už tak od roku 1995 co započal svoji činnost RealNetwork, teda aspoň co moje paměť sahá. Už tehdy se začal z jejich strany používat a kryplit standard vydaný IETF jako RFC 1889 alias RTP, který sám o sobě byl plně funkční a jednoduchý jako facka(na tom se snad ani nemělo dát co pokazit). Už tehdy (kdo ještě pamatuje takový ten starý RealPlayer s tlačítkama jako z Motif widget toolkititu, dole s černým status-barem v zeleném písmu a paměťovými nároky pomalu většími jako dnešní Firefox a reklamami narvaný od spodu, přes strany až po strop?) se začínalo s všelijakým chunkováním a procedurováním a ověřováním (handshake jejich protokolů pomalu těžší než přístupová sekvence do Pentagonu). Pár-sekundové chunky po jejichž stažení bylo skrze nový HTTP požadavek na jiném kanálu s nějakým smetím (asi nějaký hash z bůh ví čeho) vždycky validovat byl donedávna doménou Silverlightu (ten to měl v Linuxové verzi Moonlightu dokonce ošéfované tak, že po stažení chunku se provedl reload v prohlížeči, takže to bylo absolutně nepoužitelné a většinou to skončilo pořádným zákusem). Teď se k té zoufalosti bohužel uchýlilo i jablko (aneb jablko od stromu daleko nepadá). Celé je to jediné: Zoufalá snaha o streaming, alias pokoření fyzikálního zákonu, že cokoliv přehratelné na libovolné obrazovce může být logicky přesměrováno na pevný disk přehrávače a dál barterovatelné (tohle tu existovalo ještě dávno před tím než kdokoliv znal tři magické písmena DRM). Tento fyzikální zákon bohužel jde ne-fyzikálně pokořit: Nadělat v tom takový bordel, že se v tom vrtat kohokoliv přestane zhnusením bavit. Bohužel se jim to čim dál víc daří. Ale jak říkám, tohle už započalo dávno v minulosti. Už mezi roky 1995-2000 se do toho boje o internetový stremovatelný koláč přidal Apple (jimi použité zvukové kodeky, které i několik let po vydání standardu MPEG-1 utrhly nejedny uši a u kterých se pořádně neví jak fungují dodnes, jsou nezapomentulné i když oni v tom kryplení čehokoliv byly přeborníci už mnohem dříve), Microsoft (ten se o to chudák nepříliš úspěšně pokouší už několik desetiletí, zas z kryplení MPEG-4 ASP se podařilo hackerům vypreparovat aspoň DivX). Za těch cca dvacet let se moc nezměnilo, snad se do boje o obří ocukrovaný koláček přidal jen Macromedia/Adobe (ještě pamatuju když tak cca někdy krátce po přelomu tisíciletí začínali se sekvencí JPEGů). Co je smutnější, je fakt, že pokaždé když už to vypadá, že někdo přišel s něčím tak debilně jednoduchým a prostým, že už se to snad nepovede nikomu dodrbat v jeho prospěch a v oblasti internetového videa zavládne utopie se to dodrbe tak, že by se člověk klidně vrátil o jednu dodrbanou generaci zpět a ještě se slzou v oku vzpomíná a že u toho giganty zadupou doslova někoho do zemi (naposled to odnesl chudák Ian). Možnost že obří sladký koláček propadne nikomu (jediná možnost jak zavést v oblasti internetového videa doslova drogové opojení na věky) a že už z něj nebudou moci trhnout ani plátek je pro ně ještě horší než spát s konkurencí nebo riskovat že většinový podíl konkurenci připadne. Mě už tím bohužel umořili.

BTW: Ale to je jen jedna oblast. Např. na TCP/IP sítích se už komunikovalo (ve smyslu, že už se stalo a už asi nestane). Pamatuje ještě někdo NetMeeting (zas nic jiného jen implementace dobře vymyšlených standardů)?

[xxx]

Tak ona to zas takova kokotina neni. Kdyz se podivate na navrh toho standardu, konkretne na kap. 6.2.4., tak pochopite k cemu je dobre, rozsekat ten stream na segmenty.

[Ondra]

6.2.4. Providing variant streams

[pc2005]

New Apple internet protocol: We need to go deeper .

[AsciiWolf]

[xHire]

U mě ČT zařezává stahování (live) rtmpdumpem delších pořadů z archívu. Dovolí mi to stáhnout jen ~10 minut záznamu (vždycky přesně stejně, nikdy se to nekousne jinde). Testoval to i další člověk a kouše se mu to naprosto stejně.

Ty desetivteřinové kousíčky jsou sice příšernost na takovéhle stahování, ale při té bídě už je člověk vděčný za jakoukoli možnost stáhnutí videa od ČT. Ale upřímně řečeno, použitelnost takových minikousíčků je mizerná (ve vlc ještě jakš takš, v mplayeru bída).

Každopádně za ctstream díky. :c)

[Limoto]

Jak rychle se z toho stahuje? Dá se neomezeně, nebo si to něčím limituje na realtime?

[Limoto]

Hmm, vytáhl jsem z toho 2,5MiB/s. Takže super, nejspíš to doplním do tv-dl... Děkuji autorovi za objevení a za blogpost

[petr_p]

Neměřil jsem. Živý přenos rychleji než reálný čas z objektivních důvodů nepůjde. Odkazy na záznam jsou s k dispozici všechny najednou, takže předpokládám, že omezení budou dány jen linkou a datovým úložištěm v NACEVI.

[petr_p]

Měřím sekvenčí přenos http://www.ceskatelevize.cz/ivysilani/1096898594-udalosti-komentare/212411000370207/ a ten kolísá mezi 5,3 a 6,4 Mb/s. Stáhl jsem přes 300 MB, pak mě to přestalo bavit, průměr byl 5,964 Mb/s.

[Limoto]

Já jsem teď z

perl ctstream-5 -A -s http://www.ceskatelevize.cz/ivysilani/10195164142-vypravej/ | pv > /dev/null

dostal 2,32MiB/s (18,5Mbit). Ale je škoda, že to tímhle způsobem nabízí jenom 576p, ostatní jsou jenom na RTMP...

[petr_p]

Mně se linka saturuje na 10 Mb/s, tak jsem myslel, že úzké hrdlo je na serveru. Když máte víc, tak mám asi problém u sebe. Nebo to taky bude perlem, mám docela pomalý stroj, sebere mi to 40 % procesorového času. Třeba dosáhnete lepších čísel, když si parametrem -f vypíšete URL a postahujete je něčím efektivnějším.

Akorát nechápu poznámku s RTMP. Mně ctstream na RTMP nenabízí vyšší rozlišení.

[Limoto]

U toho Vyprávěj mi to po RTMP nabízí 720p, 576p, 404p, 288p.720p  720p

[petr_p]

Jasný, nevšiml jsem, si že stahujete jiné video.

[Jurand]

Vypadá to, že Česká televize opět něco změnila, nicméně se mi povedlo rozchodit ctstream-5 touhle opravou:

491c491
< $response = $ua->request(POST $smil_generator_url, \@data);
---
> $response = $ua->request(POST $smil_generator_url, \@data, Referer => "http://www.ceskatelevize.cz/", 'x-client' => "127.0.0.1");

Vypadá to, že hlavičky "Referer" a "x-client" jsou teď povinné.

Bez této úpravy vrací http://www.ceskatelevize.cz/ajax/playlistURL.php kód 403.