Vlákno názorů k článku Stream.cz: čtyři roky, nové technologie, HD kvalita od vyvojar v Berline - Misto otevrene technologie typu h.264/http podporujici implictne zarizeni...
-
Miran (neregistrovaný)
Mě spíš připadá jako dost blbej nápad, že pro přehrávání videa vyžadují mít otevřený port TCP/1935. Pokud máte ve firmě a není vám bezpečnost úplně kradená, tak se povolují pouze některý nejvíce frekventované porty a to port TCP/1935 rozhodně není. Tak že se Stream připravil asi o dost diváků z řad firemních zaměstnanců.
-
janforman (neregistrovaný)
Řekl bych že v té firmě třeba nechtí aby zaměstnanci civěli na video :-)))
Navíc 1935 (rtmp) má automatický fallback na port 80 a 8080 kde se komunikace zabalí do http požadavků (přenos dat je méně efektivní).Podle mého je smutné že stream nemá HD už dávno. Přechod na plnohodnotný streaming mi příjde zbytečný. (to bych si šetřil na živé vysílání).
Obzvlášť pokud se pokusí používat nějakej ultra JAVA hrůzu.
Dneska ovšem existuje implementace rtmp v C a ta už má výkon opravdu velmi slušný.
Jen tak jsem kouknul - mě binárka zabírá cca 3MB.Upnul bych se na kvalitu h264 komprese a její akceleraci přes GPU (to si myslím že dělá nějvíc)
-
Hm, zkousel jste nekdy ten "automaticky fallback na port 80 a 8080" v realnem provozu? Pokud ne, tak verte, ze ja naposledy pred rokem a vysledkem je, ze jsme zustali u rmtp na portu 80 (pri vedomi, ze moje karma je opravdu spatna, nedostanu zadne tvrde darky a budu se smazit v pekle).
Nevim, proc chce stream.cz prejit na streaming, ale vezte ze z hlediska systemovych zdroju Vas delivery 10 Gb/s konektivity pres http download vyjde mnohem draz nez streaming.
"Kvalita h264 komprese" je dana algoritmem, ktery je standardizovan.
-
janforman (neregistrovaný)
progresivní streaming vás nemusí vyjít o mnoho dráž... není problém omezit datový tok.
"Kvalita h264 komprese" je dana algoritmem, ktery je standardizovan
tak tohle sám víte že je nesmysl (nic tak variabilního jako MPEG4 snad ani neznám)
ano automatický fallback mám ozkoušený a funguje normálně. -
Omezeni datoveho toku Vas muze vyjit na procesorovy vykon pomerne draho. Tedy pohybujeme se v oblastech serveru, ktere jsou schopne odbavit kolem 2 Gb/s provozu.
Ano, MPEG-4 je pomerne variabilni standard, nicmene prece jen ma nejake mantinely. Jednim z nich je ta "kvalita komprese" - pokud mame na mysli kompresni algoritmus. Nebavim se o tom, ze muzete do prislusneho kontejneru cokoliv, ale o tom, ze to "cokoliv" musi byt schopno klientske prostredi prehrat.
Je velky rozdil mezi laboratornim vyzkousenim a provozem v realnem svete :-(
-
janforman (neregistrovaný)
Z mého pohledu traffic shaping na něčem normálním (tím nemyslím apache, tomcat nebo podobný příšernosti) nemusí mít nějak velkou režii.
2Gbit/s na jednom serveru už by byl možná problém, to někdy vyzkouším pokud budu mít náladu. (mám nějaký SSD disky)
MPEG4 sice má mantinely, ale od nevidím do nevidím a já jsem schválně napsal GPU kompresi :-) měl jsem k tomu sakra dobrý důvod.
Všechny služby na internetu totiž při rekompresi volí velmi nízkou kvalitu komprese (ošizené výpočty atd.) z důvodu úspory výpočetního výkonu jejich farmy.
Ano H264 můžete komprimovat 5 minut a nebo taky hodinu (výsledek bude dost odlišný a délka videa totožná profil se nebude příliš nebo vůbec lišit). -
Nevim, na jakou kapacitu sizuji servery panove ve streamu, nicmene pro nas jsou 2 Gb/s entry level. To nepisu proto, ze bych si chtel honit triko, ale paklize mate mit system na odbaveni 60 Gb/s, tak uz musite jit do podobnych zarizeni. V opacnem pripade se zblaznite ze spravy tolika serveru :-)
Nerozumim moc te poznamce o delce kodovani (zcela jiste mate na mysli kodovani, nikoliv komprimaci). Ano, existuji ruzna nastaveni a ruzne kodery, ale kompresni algoritmus je dany. Bohuzel mymi zakazniky jsou vetsinou televize a ty si s kvalitou obrazu dost vyhrajou - zdravim MS.
-
vyvojar v Berline (neregistrovaný)
Tak se podivejte, co Apple prosazuje jako standard pro streamovani videa. To oni sazi na HTTP.
Ty obfuskace proste nechapu. Stahovani videa to stejne nezabrani, jak pepak svymi aplikacemi dokazuje. Proc rovnou nevlozit nutnou reklamu do videa a nenabidnout uzivatelum otevrenou technologii, kterou si prehrajou na vsech zarizenich, pocinaje PC, pres mobilni zarizeni a konce televizemi Samsung, LG, Toshiba a dalsimi podporujicimi YCTV?
-
janforman (neregistrovaný)
je to zanedbatelné... přesto nechápu v čem jim fandíte?
všechny streamovací technologie mají fallback na http-tunel (v případě nouze aby to nějak fungovalo i ty s DRM).
přirovnal bych to k tomu když k vám chodí pošťák s balíkama tak mu přihodíte štrůdl pro paní z vedlejšího domu protože hned potom jde tam (on ho třeba i doručí), ale opravdu mu to nepřísluší a nemá to v popisu práce :-) -
Dobry den,
me ale vubec nezajima, co prosazuje Apple. Dorucovani videa pres http je cunarna, at uz to prosazuje kodkoliv. Na tom nic nemeni ani to, kdyby to prosazovali Apple, Microsoft, Adobe, Google a Richard Stallman vsichni dohromady.Vubec nechapu, o jakych obfuskacich hovorite. Na dorucovani medialnich dat tady mame protokoly dobre popsane v RFC (napriklad rtsp).
Me je uplne jedno, zda a jak si drzitel licence schrani svuj obsah, to je jeho vec (dokazu mu doruceni ohlidat ve srovnatelne urovni at uz to bezi pres rtsp nebo http). Me zajima, jak efektivne dorucit video od zdroje k uzivatelum.
-
vyvojar v Berline (neregistrovaný)
"Me zajima, jak efektivne dorucit video od zdroje k uzivatelum." Muzete tedy vy specifikovat, o kolik procent je http mene efektivni nez napriklad rtsp? (ano, byte range a time range protokoly, ale pro http hovori network effect)
To, kdo standard prosazuje je take dulezite. Kdyz prijde s navrhem Apple, uz to neco znamena. (soudit kvalitu nezavisle na navrhovateli je samozrejme spravne, nicmene je treba zvazit kontext)
Obfuskace - mineno z pohledu uzivatele - kdyz si chce prehrat video ze stream.cz na sve televizi, jake ma moznosti? Pokud je nasazena technologie, ktera ztizi stahovani, bez toho aby mu zamezila, je to obfuskace. Cituji: "Streaming má mimo to také znatelně lepší zabezpečení dat proti nežádoucímu stahování, nasazení DRM se prý ale neplánuje." Proc tedy nenabidnout data primo ke stazeni? Toto Vam jako obfuskace nepripada?
Na druhou stranu, stream.cz nevlastni hodnotny obsah a napr. pro TV Prima je pouze prostrednik a ti budou v budoucnu odstraneni (pockejme si jake problemy ceakaji na Netflix s obnovovanim licenci k obsahu). Tudiz za tuto politiku sam nejspis nemuze.
-
Dobry vecer,
ja neresim, "o kolik procent". Ja resim, zda je ten protokol pro konkretni dorucovani navrzen. Chapu, ze kdyz mate v ruce kladivo, vypada kazdy problem jako hrebik - ale muze to byt i sroubek nebo porcelanovy hrnek. Nerozumim vubec poznamce o "network effectu".Priznam se, ze je tomto vlakne jsem se od clanku zcela odpoutal, protoze nenabizi prilis zivne pudy pro technologickou diskusi.
Duvod, proc pouzit protokoly pro dorucovani videa, jsem jaksi sdelil. Mame protokoly pro dorucovani videa a proto bychom je meli pouzivat. V opacnem pripade nam hrozi, ze ten soub opravdu zatlucem.
Na diskusi o licencich se necitim byt erudovan. Nejsem ani pravnik ani obchodnik :-)
-
Vanishing Point (neregistrovaný)
Nejvetsi overhead HTTP je v tom, ze nebyl navrzen na streaming videa - tudiz server nevi, jestli klient sleduje nebo pauznul (coz je dulezita informace pro load balancing; i u HTTP by to slo nejak ochcat, ale je to obezlicka, ne reseni).
RTSP na druhou stranu neni moc rozsiren u klientu (BFU network effect & neprotlaci ho zadna velka firma).
Tim padem zustava jen RTMP. Nastesti Adobe ("castecne") otevrel RTMP protokol (dokumentace je online), proto existuje celkem dost free implementaci klientu a alespon jedna decentni free implementace serveru.
"Nezadouci stahovani" je jenom PR blud, kazdy, kdo trochu rozumi programovani vi, ze DRM je nesmysl.
-
vyvojar v Berline (neregistrovaný)
Neresi nahodou tohle ten navrh standardu od Apple?
RTMP bohuzel nepodporuje zadna televize s Yahoo! frameworkem. Kdyz vezmete v uvahu, ze tento framework je v kazde novejsi televizi od Samsungu a v soucasnosti to vypada jako jedine prakticke reseni VOD bez nejakeho dalsiho zarizeni, tak to jiste stoji za zvazeni.
Jedine na co se v tomto frameworku muzete spolehnout je prave HTTP (+mp4/h264 nebo wmv/vc-1), s tim, ze v budoucnu se prida M3U8 a RTSP, s RTMP se ale ani nepocita.
Na "nezadouci stahovani" mame stejny nazor :)
-
Jan (neregistrovaný)
Moznosti ma, i primo z TV spustit (bez pocitace), dnesni TV to umoznuji, dnesni TV jsou v podstate pocitac, ve kterem bezi linux, maji 512MB flashky a prehraji temer cokoliv, kdyz se vi jak na to (ale asi neni vhodne to verejne popisovat, protoze provozovatel streamu zije z hitu na reklamy...).
Ach jo.
-
Vanishing Point (neregistrovaný)
Placete na spatnem hrobe. Spravny smer je smerem k zmrdum z OSA, DILIA apod (neumeji pochopit ze DRM fakt nikdy nemuze fungovat) a taky Apple. RTMP je otvevreny protokol (ma nejake licencni podminky, ale nic hrozneho pokud chcete vytvaret prehravac, existuje spousta free implementaci v jave/c).
