ctstream 5 aneb HTML5 podle Apple (diskuse)

[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.