Vlákno názorů k článku Česká televize zrušila tendr na iVysílání, vyřadila tři zájemce ze čtyř od totoCZ - To si úplně nemyslím, vzhledem k tomu, co...
-
totoCZ (neregistrovaný)
To si úplně nemyslím, vzhledem k tomu, co jsem o spolehlivosti PDC slyšel. Ze stejného důvodu je ve smlouvě už poněkolikáté taky věta o budoucím řízení rekordérů přes API (které zatím ČT nemá), chtějí se toho zbavit.
> Smooth Streaming je pouze a jenom zpusob dorucovani MPEG-4/H.264 souboru do prehravace.
Ano, ale je to zastaralý protokol, který to řešení mírně komplikuje a na to jsem narážel. (spousta nového softwaru s MSS už třeba nepočítá). Ve smlouvě je podobných specialit víc. -
totoCZ (neregistrovaný)
Jedna firma, co by to postavit dokázala málem zvítězila ;-)
Jinak je to na úhlu pohledu. Krabicové řešení enkodérů a tři administrátoři vychází ve výsledku levněji a efektivněji pro všechny včetně ČT, než to psát celé vlastními silami. MSS pak může být jedna z těch věcí, která je v roce 2016 s tímhle řešením celkem nestandardní, protože jednoduše není podpora. To byla pointa. (Přesto nevěřím, že jen kvůli tomuhle je nutné psát celý streaming server a utrácet peníze a čas za jednou už vymyšlené věci.)
HTTP 2.0 má budoucnost před sebou, MSS už moc ne, to není to správné přirovnání.
Je to v kontextu prvního příspěvku v threadu, na který jsem dal pár příkladů, aby bylo jasno, jaké tam jsou zajímavosti.
Mluvím za sebe, ne za SN. Dodat to není problém, jen ne na YouTube (viz kontext celého threadu :-).
th. -
CT by rada mela neco jineho, ale potrebuji mit "neco" na strane odbavovaciho pracoviste. Bude zajimave sledovat, jak se nejake API vyrovna se zpozdenim koderu/dekoderu. Predpokladam, ze tam budou nejake hodiny a nebude to realtime rizeni.
Smooth Streaming je http :-) To je sice zastaraly protokol, ale zase na nej spoleha vetsina uzivatelu.
Mimochodem nemyslim, ze reseni komplikuje - samozrejme pokud mate spravne navrzenou architekturu systemu. Jasne, ze ma CT v zadavaci dokumentaci nejake specificke veci, ale neni to nic dramatickeho, co by cloveka prekvapilo. Ale samozrejme, pokud je to vas prvni projekt, skladate reseni z krabicoveho software a necetl jste zadavacky predchozich vyberovych rizeni, tak vas to muze prekvapit.
Dneska uz neni rok 2000, kdy v CR dokazali podobne reseni postavit tri lidi. Dneska jich budou desitky, tak staci nekoho z nich pozadat o pomoc.
-
Aha, uz jsem to asi take pochopil. Asi mel pisatel na mysli, ze by mi mel zavolat nejaky uchazec :-)
V poslednim cca roce nemam zadnou kapacitu, kterou bych pripadnemu zajemci nabidl :-( Takze i kdyby zavolal, tak by z toho nic nebylo. A fakt je na trhu dost lidi, kteri takovy system dokazi postavit.
Resim jine projekty a je s tim dost prace.
-
Chapu, ze nepisete za SN, predpokladam, ze za nej pise zkratka ZC :-) Jinak co se tyce "dokazani postavit", bych to nevztahoval na firmy.
Uhly pohledu mohou byt ruzne. Zapominate na to, ze pro CT je reseni iVysilani podruzne. Oni si resi svoje televizni systemy v rozpoctech minimalne o rad vetsim (tim prosim nehodnotim jejich kvalitu). To znamena, ze pokud maji volit to, zda rozhrani prizpusobi dodavatel iVysilani za X nebo dodavatel playoutu za X*10, tak clovek nemusi byt Einstein, aby videl, kdo to bude resit.
Streamovacich serveru pro MSS je par. A pokud neni Vase CDN pripravena na to, ze mate rozdilny set serveru pro protokol X a pro protokol Y, tak Vas muze cekat neprijemne prekvapeni (at uz jste kdokoliv). Streaming server je ta uplne nejvic spotrebni vec v celem reseni. Teda pokud nebudujete kristalovy palac na nejake singularni plafrome, kde vsechno souvisi se vsim.
Bohuzel musim konstatovat, ze pouzivani http (ci http/2) pro distribuci videa ma skutecne budoucnost pred sebou, coz opravdu nepovazuju za optimalni (no, ale kdo jsem ja, ze :-) ).
Skutecne neni problem to dodat, problem je to provozovat (obvykle v kontextu vysoutezene ceny). Ale to poznate, az vyhrajete.
Naimplementovat to pres YouTube bude mit i jine problemy nez jen podporu streaming protokolu. A cast z nich bude pravni, na urovni zakona o CT.
ČLÁNKY DO MAILU