Infrastruktura pro přenosy videa

22. 1. 2002
Doba čtení: 4 minuty

Sdílet

Jednou z aplikací, která má přinést zájem běžných uživatelů o vysokorychlostní Internet, jsou bezesporu přenosy videa IP sítí. Čím to, že dnes až na několik globálních hráčů není o aplikacích tolik slyšet? A přitom vlastní provoz toho zas nechce tolik.
Pokud odmyslíme triviální přenosy filmů a MP3 v sítích peer-to-peer, které jednak nejsou nic jiného než dávkové přenosy doplněné vyhledáváním a jednak nejsou vůbec zajímavé po finanční stránce (pomineme-li potenciál náhrad škody vlastníků autorských práv), komentování hodnou zajímavostí je fakt, že dnes se provoz Internetu tvořený výměnou videa a MP3 blíží polovině provozu ve vysokorychlostních sítích. My se však soustředíme na přenos videa (či audia) v reálném čase.

Přenosy videa lze rozdělit podle několika kritérií. Pro nás je zajímavé dělení podle auditoria a podle nároků na přenosové pásmo. Lze vytyčit tyto skupiny:

  1. Přenosy mezi vysílacím centrem a několika málo partnery (často obousměrně).
  2. Přenosy mezi vysílacím serverem a mnoha klienty.

Ač se to může zdát nepravděpodobné, obě skupiny se neliší ani tak požadavky na přenosové pásmo, pro které obě nabízejí širokou škálu technologií od modemového spojení až po řády megabitů. Každá z technologií ovšem s přenosovým pásmem zachází jinak.

První skupina požaduje stejné přenosové pásmo u celé komunity, která komunikuje (a to obvykle symetricky dovnitř i ven). Prvním zástupcem je videokonference, která v případě režimu point-to-multipoint využívá například skupinového adresování (multicastu) nebo používá centrálního prvku, který funkcionalitu skupinového adresování emuluje (může jít například o MCU u H.323 systémů nebo o zrcadlo systému VRVS). Bohužel skupinové adresování používá ve své síti v ČR pouze CESNET (totéž platí i o VRVS). Používání MCU žádný ISP veřejně (byť za peníze) nenabízí. Druhým zástupcem jsou specializované videoslužby, například virtual-training, kdy se z jednoho pracoviště předvádí nějaká aplikace, ke které se nemůže široká komunita dostat. Příkladem mohou být přenosy z vysoce infekčního prostředí v nemocnicích.

Druhým ostře sledovaným parametrem, závažnějším než šířka pásma, je zpoždění. Především při potřebě zpětné vazby, tj. především při videokonferenci, musíme dbát na to, aby zpoždění bylo maximálně v řádu stovek milisekund (komfortní dojem je při řádově desítkách milisekund). Velké zpoždění je problém především pro lidské účastníky.

Technika má problém s jiným parametrem. Tím je rozptyl zpoždění (jitter). Veškeré přenosy videa se dějí v komprimované formě (nekomprimovaný PAL spotřebuje 270 Mb/s, nekomprimované HDTV pak 1,5 Gb/s). Komprese je samozřejmě ztrátová a při výpadku jednoho balíku dat může dojít i k několikav­teřinové deformaci videa. Pro přijímací software je jedno, jestli se data ztratila nebo přijdou pozdě. Protože systém běží v reálném čase, není dost dobře možné zobrazit „přesýpací hodiny“ a vyčkat příchodu správného balíku dat (mimochodem minimalizace jitteru je jedním z důvodů, proč ve vysokorychlostních sítích implementovat QoS).

Takže pro provoz první skupiny systémů potřebujeme dostatečnou kapacitu u všech účastníků, minimální zpoždění a ještě menší rozptyl zpoždění. Pokud máme k dispozici skupinové adresování nebo jeho emulaci, můžeme se směle vrhnout k výběru partnera pro vstup do světa videokonferencí.

Druhou skupinu aplikací lze nejsnáze přirovnat k televiznímu vysílání. Máme k dispozici jeden zdroj signálu a několik desítek (stovek, tisíc …) klientů. Z principu nám tak vyplývá potřeba připojení centrálního prvku na silnou páteřní síť. Podobně jako u první skupiny můžeme přenášet video již v „modemové kvalitě“, nicméně zajímavé pro diváky to začne být až od rychlostí 256 Kb/s (stačí směrem od serveru ke klientovi). Pro sto klientů jsme na metě 25 Mb/s, pro 400 klientů potřebujeme na serveru plných 100 Mb/s – podotýkám, že nejde o port na ethernetovém přepínači, který sdílíte s dvacítkou dalších serverhosterů. Připojení u klienta obvykle nedokážete ovlivnit, nicméně většina streamovacích technologií disponuje mechanismem tzv. bandwidth negotiation, kdy klient serveru pošle dostupnou šířku pásma, a server mu pak posílá videodata v nejbližší nižší kvalitě.

Zajímavostí je, že při tomto typu přenosů nejde o zpoždění vůbec. Pokud se totiž udrží v řádu sekund, divák nic nepozná. Podobně jsme na tom s jitterem. Všechny streamovací systémy totiž načtou několik sekund vysílání do mezipaměti. Vzhledem k tomuto faktu není možné získat opravdu přímý přenos vysílané akce.

Přestože se pravděpodobně zdá, že na streamingu není nic zajímavého a jedná se o běžnou službu, není tomu tak úplně. Chyby nevršíme jen my (například streamingem rádií nevhodnou technologií MS Netshow), chyby dělají i ti velcí. Už od roku 1996 má společnost Disney celou svojí produkci digitalizovanou a připravenou ke streamingu. Chybka je ve faktu, že potřebná šířka pásma je 4 Mb/s, kterou vyhodnotili analytici Disney jako nejnižší možnou k zachování potřebné kvality pro diváky.

U nás rozvoji streamingu brání především fakt, že prakticky neexistuje trh s broadband Internetem. Počítané bezdráty a stejně zpoplatňované xDSL bohužel nejsou streamingu nakloněny.

Kolik byste byli ochotni maximálně platit za zhlédnutí jednoho filmu přes DSL?

Autor článku

Autor je nezávislý konzultant v oblasti Internetu, telekomunikací, videa a komercionalizace technologických výsledků výzkumu a vývoje. Pohybuje se na rozhraní akademické vs. komerční sféry a internetové infrastruktury vs. přenosů videoobsahu.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).