Vlákno názorů k článku Petr Pobořil: HDTV je náročné na datový tok, našli jsme ale řešení od Michal Krsek - Panasonic Televize implementuji obycejny HTTP progresivni download. Pokud...

Panasonic Televize implementuji obycejny HTTP progresivni download. Pokud vim, tak YT nestreamuje vubec nic.

To je samozrejme otazka pouziteho hardware, napr. nove modely PZM TM Panasonicu podporuji prehravani streamu z YouTube tusim, cili ciste Internetova zalezitost, navic VOD se streamuje vetsinou pres RTSP (resp. RTP streamem), takze to s tou podporou i jinych formatu asi nebude zase tak spatne, pochpitelne idealni by bylo, kdyby se podarilo prosadit nejaky format optimalizovany pro IP prenos jako celosvetovy standard, ale toho se asi jen tak nedockame, vetsine provideru jde o cenu a jednoduchost implementace nez o optimalizaci, protoze bandwidth obvykle k dispozici je a nacpat jednoduze MPEG TS do IP paketu je to nejsnazsi.

Ja bych rekl, ze v pripade IPTV nemate na vyber a musite posilat korektni MPEG-2 TS. Ano, oproti DVB muzete vynechat napriklad NIT, SDT a dalsi, ale to je tak vse. Resp. abych byl presny, muzete posilat co chcete, ale budete velice omezen poctem zarizeni, ktera takove reseni dokaze prijmout a zpracovat.
Poznamka: vyse uvedene se tyka _pouze_ IPTV, u obsahu streamovaneho na internetu je situace pochopitelne jina.

Tak to jsme si asi nerozumeli, samozrejme, ze pokud budete balit DVB-TS do IP tak tam bude rezije vetsi nez v pripade samotneho DVB-TS, ale to je celkem nesmyslna implementace, kdyz uz posilat cely MPEG stream tak treba v PS, ktery ma delsi ramce a tudiz mensi overhead, ty kratke ramce v TS byly zvoleny proto, ze nic moc korekce chyb v DVB obvykle dokaze pouze detekovat vadny ramec a cely jej zahodit, takze v pripade kratsich ramcu se ztrati mene dat a celkovy vliv na obraz a zvuk je nizssi (resp. mene rusivy), pres IP se ale obvykle streamuje uplne jinak, chybovost se blizi nule, a pokud se (na Internetu je tomu tak prakticky vyhradne) nepouziva multicasting, tak nema smysl streamovat cely paket, staci pouze zvoleny program (kanal) a i ten multicasting nema problem po jednom mediu prenaset vice multicastu, kazdy s jinym video/audio streamem, takze posilat neustale kompletni TS vsem je zbytecne (narozdil od DVB-S nebo DVB-T, kde to jinak nejde). Kazdopadne mate pravdu, ze na gigabitovem Ethernetu rezije nejakeho 30-ti megabitoveho TS nehraje roli, ale zbytecne plytvat by se proste nemelo uz z principu, ze ?

Souhlas, při přenosu TS nad IP se přibalí ještě IP hlavičky a hlavičky nižších vrstev. Podle výše uvedeného tedy UDP/IP přidá 24B na každý IP paket. 1476/188 = 7.8, takže při MTU=1500 se do jednoho UDP paketu vejde 7 TS rámců. Pokud by se ale balil každý TS rámec do samostatného UDP+IP paketu (+24B), tak by UDP+IP přidalo režii cca 12%. A dalších 26B hlaviček a patiček přidá Ethernet (nepočítaje v to 12B ochranný interval, nepočítaje případné VLAN tagy).
http://cs.wikipedia.org/wiki/Ethernet
A jsme na nějakých +25% režie při použití transportu UDP/IP/Ethernet, při balení jednotlivých TS rámců po jednom do paketů. Nebo-li režie cca 20% počítáno "směrem dolů".

Až bude běžným způsobem rozvodu televize Ethernet na nativních metalických a optických médiích (na nativních rychlostech), tak ta režie v podstatě nebude hrát roli :-)

Nojo, ale neni prave tech 1476 bajtu ramce plneno prave tim TS s rámci 188 bajtů? Pak by bylo IP vzdy mene ucinne nez raw TS bitstream.

Jak jsem jiz napsal, zalezi na tom, co mate za linku. Napr. ADSL od O2 pouziva PPPoE a MTU muze byt snizena z 1500B az na cca 1400B, pak to jiz samozrejme vychazi jinak, ale u optickych siti byva obvykle vyuziti celeho Ethernetoveho ramce pro IP datagram a pokud nepouzivate zadne VPN, nebo jina IP rozsireni prodluzujici hlavicku (treba IPSEC) a pracujete s UDP streamem, tak je to tak jak uvadim. Maximalne dalsi 4B muze zabirat hlavicka RTP pokud je pouzit RTP stream, ale to je jiz zalezitost konkretniho aplikacniho protokolu a i tak je to porad jeste 98.1%. Dale je tu jeste problem samotnych Ethernetovych hlavicek, ktere vam Ethereal zrejme meri take, ale jak jsem jiz psal, linkovou vrstvou se v porovnani nezabyvam, DVB-T/S ma take nad TS jeste celkem velmi slusny overhead, ovsem zalezi na konkretnim nastaveni toho ktereho vysilace, takze je to neporovnavatelne a jako uzivatel to vetsinou ani neuvidite, protoze tato data se odrezou jiz v DSP tuneru a software se o nich prakticky nedozvi. Navic Ethernet umi i Jumbo frames, cca 9kiB je dnes jiz celkem bezne podporovano vetsinou switchu a karet a tomu se uz TS nemuze efektivitou nikdy vyrovnat, ovsem zatim neznam ISP, ktery by to verejne podporoval/nabizel na svych routerech, takze jsem to ani nezminoval, ovsem v privatni siti ISP to nasadit v principu lze.

Zajimave, ze mi Etheral ukazuje neco jineho.

Tak to jste tedy pekne na omylu! Predevsim nevim, proc nazyvte IP Ethernetovym protokolem, ale budiz. Nicmene plati, ze TS pouziva ramce o delce 188 bytu, 4 byty je hlavicka, 184 data (v optimalnim pripade), takze ucinnost prenosu dat je cca 97.9%. IP na zminenem Ethernetu pouziva typicky 1500 bytu na ramec, v pripade UDP protokolu pak na data zbyva maximalne 1476 bytu, coz dava ucinnost prenosu dat 98,4%! O datech [prenasenych na nizsich linkovych vrstvach nema smysl se bavit, nebot u kazde varinaty je to jine, ale troufnu si odhadovat ze i tady na tom bude 100Mbps Ethernet lepe nez treba DVB-T pouzivane v soucasnosti v CR. Samozrejme, je pravdepodobne, ze v pripade zhuverilosti typu PPPoE pres ATM (casto pouzivane mne naprosto nepochopitelne u ADSL, kdyz unbundling tu stejne prakticky nefrci a k nicemu jinemu se to stejne nehodi kdyz uz tu mame nativni IP over ATM nebo jine efektivnejsi alternativy) to asi bude horsi, ale to je jiz nizsi linkova vrstva a se samotnym IP to nema moc spolecneho, stejne jako netvrdim, ze nativni IP v ATM zvladne IP ramce maximalni delky 64kiB, cili efektivita prenosu by zde byla 99.96%!

Uz z principu TCP/IP je tento Ethernetovy protokol "ukecanejsi" nez jednosmerny DVB-T/S.

Mně to taky tak přišlo, dokud jsem se nedočetl k implementaci H264 tak mi to přišlo jako kdyby přišli s nějakým vlastním revolučním řešením.

V cem je "ukecanejsi"? Pokud mam CBR nejakem bitrate, je jedno jestli je v DVB nebo v IPTV, jedna se o ten samy MPEG2-TS.

Spise si nekteri neuvedomuji, ze v IP streamu je pri stejne kvalite bitstream "ukecanejsi" a proto tam ma 13-15Mbps, kdezto v transport streamu u DVB-T ma to same jen 8-11Mbps.
Ono neni bitstream jako bitstream.

Ale jinak souhlasim, konecny boj o zakaznika vyhraje to ISP, ktere jako PRVNI zavede vlakno az do domacnosti (minimalne k pate baraku)... FTTH.

A podle čeho tak soudíte? Podle těchto vět?
"Každé většinou pochází od jiného výrobce a naším úkolem bylo doladit vzájemnou kompatibilitu těchto zařízení tak, aby se obraz korektně zobrazoval u koncového zákazníka - televizního diváka."

"Kritériem pro úspěšnost byla úroveň inovace v dané kategorii, kde my jsme implementovali ve spolupráci s výrobcem hlavně toho zařízení, které bylo ve studiu, kodek H264/MPEG-4. Ten při velmi vysoké úrovni kvality obrazu měl poměrně nízký datový tok."

Kde vidíte argumenty pro vaše tvrzení?

akokeby ten úspernejší kodek zbastlili sami vo firme.