IPTV a CH zapping (Bylo:OT: jakou poridit videokameru?)

[jan.kuba]

Rollfree napsal(a):

>Nechci se prit, protoze kyslikove IPTV je mi dost volne.
>  
>
No ale psal jste o tom dost zasvěceně, hlavně ten silne komprimovany 
tok..... :-)

>Nicmene kdyz jsem to videl bezet na Invexu, tak to vykazovalo
>priznaky dlouheho GOPu - doba prepnuti byla nedeterministicka,
>od snesitelne cca 1 sec. do cca 5 sec.
>  
>
To co jste viděl na invexu, bylo nejspíš předvádění HDTVve stadiu testů  
a  server ( a DVB-T vysílač, ze kterého to jelo) byl co já vím zkušebně  
přímo na Invexu:
http://www.digizone.cz/tiskove-zpravy/telefonica-o2-otestovala-prvni-pozemni-vysilani-ve-vysokem-rozliseni-hdtv/

Mohu Vas ubezpecit, ze doba prepnuti kanalu na komerční IPTV je vicemeně 
konstantni ( 3-4 sec)  a vůbec nezávisi na právě vysílanem obrazu ( 
rychlé/ pomalé střihy )

viz. http://www.lupa.cz/clanky/na-kolik-prijde-o2tv/

>Zpozdeni, dane jen plnenim bufferu, by bylo pomerne nelogicke.
>  
>
Ja psal , ze to neni jen na tom buferu, ty odezvy serveru nejsou 
nenulove a s pribyvajicim poctem uziatelu se tez nebudou zmensovat.
Ono samotné zpracování v dekodéru má také nějaké zpoždění. ( pozn. kde 
se bere zpoždění v řádu desítek msec na GSM hovorovém kanálu ? - a to je 
rychlost dat  v řádu jednotek kb/s )

>Tato vlastnost (prepinani programu, ktere dlouhodobe neni mozne
>prezit bez trvalych nasledku na nervove soustave) 
>
Ano, lidé jsou zvyklí prepínat kanály nahorů, dolů, čím rychleji, tím 
lépe a najednou to nejde. Pravda u některých TV maniaků to může opravdu 
mít za následek
poruchu nervové soustavy.

>totiz tuto
>technologii natolik diskvalifikuje, ze by to za to testalo.
>
Ono je tam víc "diskvalifikačních faktorů " podle mě například daleko 
větší je fakt, že lze sledovat ( zatím )  pouze jeden kanál.
Dokážu si představit rodinu zvyklou mít na každé televizi jiný kanál a 
teď to najednou nejde......!?


> <>Buffer je prece mozne plnit uz za soucasneho prehravani (pri 
> spolupraci nejakeho nevelkeho bufferu nekde po ceste)


Ono je to celé ještě trochu složitější. Díky jinému protokolu při službě 
IPTV trpí i přidaná služba - INTERNET a to hlavně jeho odezvy.
Ty jsou mnohonásobně horší, než pokud je na ADSL lince využívána jen a 
pouze služba připojení k internetu. A to právě kvůli zabezpečení přenosu 
dat z buferu DSLAMU do modemu a set top boxu. Ani jeden packet nelze 
opakovat, je tedy nutno prave pomoci buferů a  dalších navazujicich 
algoritmů ( nejen v set top boxu ) zabezpečit cely  zranitelný prenosový 
řetezec k zákaznikovi.

>, navic u multimedialnich
>dat se na nejaky drobny vypadek moc nehledi.
>  
>
 Jaky multimedialni data? Vam by se libilo, kdyby Vam televize obcas jen 
tak cukla a poposkočil obraz? Pokud je to jednou služba, ktera nabizi TV 
pořady, je
úplně jedno jestli běži na nějakem multimedialnim "principu" nebo 
analogově, divák chce kvalitu bez jakýchkoliv DROBNÝCH výpadků nebo 
jiných kompromisů.

Ta IP TV neběží z internetu jako takového ale je pomocí broadcastu 
šířena na všechny DSLAMy.  A odtud se  k  zákazníkovi  dostává sice 
stejným modemem jako potenciální internet, ale v jiném zapouzdření . 
Jsou použity nezávislé "kontejnery" a datové toky  ( PVC0, PVC1) z čehož 
právě ten PVC pro IPTV musí být nějak zabezpečen proti případné  
"chybovosti" .

>Treba ale mate pravdu a fakt to zpozdeni delaji takhle "zamerne".
>  
>

"Zamerne" to zpozdeni nedelaji :-)  Ale neni to kvůli  struktuře MPEG toku.

>**********************
>
>  
>
>>K prepnuti dojde az po prichodu I-frame,
>>proto na silne komprimovanych trasach (napr. IPTV od O2) se ceka
>>na prepnuti programu az nekolik sekund.
>> 
>>
>>    
>>
>To je ale  blbost.....
>... na přepnutí se čeká opravdu  několik sekund ( jsou asi  4  :-)  )  
>ale to hlavně proto, že se také musí komunikovat se serverem ( 
>distribuční "Imagineo" v Praze ) Tenhle server obsluhuje všechny koncové 
>body až k zákazníkovi.  Tam nějaké nepatrné zpoždění ( závisí od 
>momentálního zatížení serveru)  vznikne, hlavně ale vlastní set top box 
>určitou část  datového toku ukládá a přehrává se zpožděním. Je to krásně 
>vidět, když se přeruší LAN k set top boxu od modemu, chvíli to ještě 
>jede. Když je jen malé přerušení, není nic poznat. Ten buffer  je tam 
>kvůli případným krátkodobým  výpadkům, které mohou z principu  nastat na 
>ADSL  lince. A přehrávání  po přepnutí začne, až se bufer naplní.  
>Narozdíl od Internetu je IPTV vysílán broadcastem a nelze jenoduše 
>pakety na vyžádání opakovat. Proto tahle "komplikace" s buferem, který 
>se podílí na  té prodlevě při přepnutí z kanálu na kanál.
>Další , jiné spoždění - posun už vzniká i v encodérech  a podílí se též 
>na celkovém časovém posunu sledovaného programu -  pravda tohle nemá 
>vliv na dobu přepnutí kanálu.
> Dále  ....3,5M datovy tok na IP TV  při  MPEG 4 je málo? Nebo silně 
>komprimované?   Když CZECHLINK (teď  nově už přejmenován na  CS LINK) má 
>při MPEG2 na nějakých programech  4-5 Mbit. ( používá VBR)
>Jestli  někdo silně komprimuje ( nemá kapacitu na transpodérech ) tak 
>UPC na Astře. Obraz hnus, prý už se ani na tu erotiku se nedá koukat, 
>jak je něco víc v  pohybu je to hranaté. A že se na těchdle kanálech 
>furt něco ( někdo) hejbe  :-)
>Jinak ta teorie je v pořádku, jen je špatne "zasazena" do praxe. ( 
>IPTVod o2)
>
>_______________________________________________
>HW-list mailing list  -  sponsored by www.HW.cz
>Hw-list@list.hw.cz
>http://list.hw.cz/mailman/listinfo/hw-list
>
>__________ Informace od NOD32 1.1807 (20061017) __________
>
>Tato zprava byla proverena antivirovym systemem NOD32.
>http://www.nod32.cz
>
>
>
>  
>