Hlavní navigace

Vlákno názorů k článku Na kolik přijde O2TV? od Void - Zapping Time neboli přepínání kanálů je problém. 3...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 9. 2006 13:21

    Void (neregistrovaný)
    Zapping Time neboli přepínání kanálů je problém. 3 až 4 vteřiny je obecně považováno za nepřijatelné. V oboru u klasických TV se hovoří o horním limitu běžném 300ms a max 500 ms. U IPTV dosáhnout jedné sekundy je problém. Taktéž odborné studie hovoří že v případě více požadavků na přepnutí v jedné části sítě může dojít k problémům. Jinak zapping time je závislý na tom jak často je ve streamu klíčový rámec od kterého začne rekonstrukce obrazu mezi klíčovými rámci se posílají jen změny pro jednoduchost. Dále vliv než router otevře Multicast a starý zruší jetaky prodlení a pak taky závisý na implementaci bufferu jestli se přehrává ihned nebo až po jeho naplnění. Jediný kdo má nejrychlejší zapping time je MS ale jen díky tomu že přepnutí znamená že se využije unicast a počká se na multicast a pak STB plynule přejde z unicastu na multicast.

    Přeci jenom 3 až 4 vteřiny je nepoužitelné dalo by se hovořit možná tak o 1 až dvou ale i tak. Z uživatelského hlediska jde však o strašné zhoršení kvality v tomto parametru vůči obyčejnému analogu
  • 6. 9. 2006 14:13

    Zdenek (neregistrovaný)
    Počítám že provider neposílá streamy obyčejným multicastem, ale že jsou "zamknuté", tj všechny kanály jsou na všech dslamech neustále k dispozici i když se na ně zrovna nikdo nedívá. Přepnutí multicastu by pak mělo být záležitostí jednoho hopu, tedy zhruba 10ms.

    Keyframe chodí u MPEG4 běžně jen jednou za vteřinu až tři, proto by se na něj čekat nemělo. Proč tedy nemít server, který bude stream průběžně dekódovat, a na požádání pošle unicastem jeden "virtuální" keyframe?

    Buffering: Předpokládám že se používá pro korekci jitteru a hlavně dopřednou korekci chyb, a to bude také hlavní důvod proč je celé vysílání zpožděno. Není problém, prostě korekce chyb prvních pár vteřin nebude.. na 3-4 devítkové lince to není nic hrozného; když obraz naskočí ihned po přepnutí, nevadí když krátce poté výjimečně vypadne.

    Korekci jitteru by šlo udělat tak že po přepnutí kanál chvíli poběží nepatrně pomaleji a bez korekce, dokud se buffer nedostane na střed. Čekat není třeba. Samozřejmě nejlepší by bylo aby linka mezi dslamem a STB byla bez jitteru, což by technicky neměl být takový problém, a kompenzaci dělal jen dslam.

    Závěr: Nevidím důvod proč by přepínání kanálů nemohlo být v desítkách milisekund.
  • 6. 9. 2006 14:30

    Void (neregistrovaný)
    No není to tak jednoduché, výborný článek a vysvětlení od cisca je na http://www.cisco.com/en/US/netsol/ns610/networking_solutions_white_paper0900aecd802808e5.shtml

    Jinak v článku popisované přetížení linky kdy routru trvá než zruší starý multicat je řešeno teď pomocí fast leave detaily nemám nastudované jen vím že to řeší problém souběhu více multicast kanálů na koncové míly při přepínání.
  • 7. 9. 2006 10:07

    Zdenek (neregistrovaný)
    Díky za link.

    > No není to tak jednoduché

    Jistěže ne. Když se 100 věcí udělá špatě, nejde udělat správně ani tu 101-ní, přestože je všem poměrně jasné jak by měla správně fungovat.

    > If the join latency is short (let's say negligible, for the sake of illustration) and the leave latency is long (say 2 seconds-not an unusual number in an IGMPv2 implementation)

    Jak můžou být latence různý? Proč není IGMP join i leave jednoduše v jednom packetu?

    > feature called Explicit Host Tracking (EHT), which keeps track of who from downstream is currently subscribed to what multicast group.

    Nechápu. Pokud je router mcast aware, tak samozřejmě musí trackovat členy mcast groups alespoň na úrovni downstream interfaců, aby věděl kam co forwardovat. Nechápu k čemu je nějaký podrobný EHT dobrý, a jak souvisí s fast leave. Prostě od RG přijde v jednom packetu žádost o leave jedné a join druhé MG, router daný interface vyhodí z jedné a přidá do druhé tabulky, a dál není co řešit- záležitost na pár mikrosekund, přetížení linky vyloučeno.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).