12. TELEVÍZIÓ- ÉS HANGTECHNIKAI KONFERENCIA ÉS KIÁLLÍTÁS Adatátviteli hálózatokon nyújtott videós szolgáltatások Lois László

Videós szolgáltatások terjesztése Alapvetően 3 jellemző kézbesítő hálózat:  Hagyományos műsorterjesztő hálózat (analóg vagy digitális)  Elsődlegesen videó átviteli hálózat adatátviteli platformon: pl. IP TV  Általános adatátviteli (van nem elsődlegesen videóátviteli) hálózat járulékosan videós szolgáltatással, például: Adatátviteli hálózat: Internetes multimédia Mobiltelefonos hálózat: videó GPRS/UMTS felett

IP alapú átvitel Az Internet a legnagyobb és a legtöbb ember számára elérhető hálózat. Az alkalmazások 3 fő osztálya:  Fájlok, adatok átvitele (ftp, http, levelezés, Kazaa stb.)  Streaming és interaktív média  Interaktív alkalmazások (játékok, chat) Média átvitel mindhárom osztályban elképzelhető.

1. Alkalmazás: fájl átvitel A lejátszás elindítása:  Miután letöltöttük  Ha már elegendő mennyiség megérkezett ahhoz, hogy a lejátszást el tudjuk kezdeni az elejétől úgy, hogy ne kelljen megállni. Szükség esetén a megállás elfogadható. A cél a tartalom biztonságos kinyerése, a késleltetés csak másodlagos.

Példa fájl átvitel alapú médiaátvitelre: „http streaming” Feladat: mostantól számítva T idő hosszú M bitnyi anyagot kell letölteni r becsült bitsebességen:  Akkor játszhatunk le, ha M < T·r becsült  Azaz: hátralévő fájlméret < hátralévő idő alatt letölthető adatmennyiség Megoldandó problémák a fenti képlettel:  Teljesülni kell keretenként (pl. képenként) is  r becsült meghatározandó, sőt időben változhat

Internet Letöltési puffer Példa fájl átvitel alapú médiaátvitelre: „http streaming” Jellemző megvalósítás: TCP Média lejátszó Tárolt média tartalom

2. Alkalmazás: media streaming Nem csak egyedül a tartalom célba juttatása, hanem az időbeli hűség is fontos:  Néhány másodperces késleltetést elviselünk az indulásig  Ha már elegendő mennyiség megérkezett ahhoz, hogy a lejátszást el tudjuk kezdeni, akkor folyamatos lejátszást kell biztosítani.

Valósidejű átvitelre alkalmas formátumok a jelenlegi hálózatokon Hálózati kapcsolatTeljes bitsebesség Videó bitsebesség KépméretKépvált. Frekv. GPRS32 kbit/s24 kbit/s160 x 1206¼ Hz EDGE50 kbit/s48 kbit/s160 x 1208⅓ Hz UMTS128 kbit/s112 kbit/s160 x 12012½ Hz UMTS, WLAN192 kbit/s176 kbit/s320 x 24012½ Hz HSDPA, WLAN256 kbit/s224 kbit/s320 x 24012½ Hz WLAN, DSL320 kbit/s288 kbit/s320 x 24012½ Hz DSL, LAN512 kbit/s448 kbit/s352 x Hz DSL, LAN1800 kbit/s1500 kbit/s704 x Hz i

Internet Letöltési puffer, jitter kiegyenlítés Media streaming jellemző megvalósítása Most csak az átvitelre koncentrálva: UDP Média lejátszó (Tárolt) média tartalom CTRL Küldés Ismétlés Majdnem minden keret ACK NACK puffer állapot

3. Alkalmazás: interaktív átvitel Az időbeli hűség az elsődleges szempont:  Azonnali indulás fogadható csak el  Körbefordulási idő: 200 ms jó, max. 400 msec A megbízhatóság csak másodlagos szempont: legyen a lehető legjobb a minőség, de ez semmiképpen sem ronthat az időbeliségen.

Az átviteli hálózat számunkra releváns tulajdonságai  Garantált bitsebesség  Maximális átviteli késleltetés  Maximális átviteli késleltetés ingadozás  Bithiba arány  Csomagvesztés vagy csomaghiba arány  Maximális körbefordulási idő  Maximális szolgáltatás kimaradási idő

A streaming átvitel sajátosságai Az ábra alapján látható, hogy a streaming átvitel sajátosságát a vezérlés (az ábrán: CTRL) határozza meg. Ennek feladatai:  Csomag küldés a média lejátszás és a hálózat által biztosított bitsebesség szerint  Csomag újraküldés, ha van értelme  Küldési sebesség változtatás szükség szerint  A fentiekhez szükséges paraméterek meghatározása

A streaming átvitel vezérlési sémái Küldő alapú séma: médiát küldő eszköz (szerver vagy médiaproxi) határozza meg a médiafolyam bitsebességét Kódoló/transzkódoló alapú séma: a bitsebesség változtatása mellett a formátumot is változtatja a küldő Vevő alapú séma: a küldő minden reprezentációt elküld, és a vevő annyi reprezentációhoz kapcsolódik rá, amennyihez lehetősége van

IETF Multimédia protokoll készlet  RTP/RTCP: média átvitele és annak vezérlése vételi jelentésekkel  SIP (Session Initiation Protocol): felépíti és újrakonfigurálja a multimédia átvitelt  RTSP (Real Time Streaming Protocol): VCR jellegű funkciók  SDP (Session Description Protocol): a média- átviteli paraméterek közlése és rögzítése  SAP (Session Announcement Protocol): a multicast jellegű médiaátvitelek broadcast- jellegű bejelentését teszi lehetővé

IP átvitel: garantált tulajdonságok  Best effort szolgáltatás ...de előfordulhat az IP csomagokkal: Késleltetés: várakozási sorok hossza miatt Csomagvesztés: várakozási sor túlcsordulása miatt, továbbá a vezeték nélküli hálózaton a csatorna miatt is Csomagok sorrendje változik Duplikáció  Ingadozó késleltetés, bitsebesség

UDP átvitel  Hozzáadott szolgáltatásként az alábbi fejléc kerül be az IP csomaghoz: Adó és vevő port (2-2 bájt) Hossz (2 bájt) és ellenőrző összeg (2 bájt)  Demultiplexálás és ellenőrző összeg.  Továbbra sincs hibakezelés, sorrend kezelés, torlódás vezérlés  De vannak előnyei is: torlódáskezelés nélkül kisebb a késleltetés

Miért nem jó a médiának a TCP?  A média átviteli alkalmazás igényei: Az átlagos átviteli kapacitás „látszódjon” Dönthessen az újraküldésről Sokkal simább paraméterek, mint a TCP-nél  A TCP a médiaátvitelre nem kedvező: Nagyon ingadozó küldési sebesség nem változó hálózati helyzetben is (AIMD) A nagy ablaknyi adat elvesztése-újraküldése a média számára túl nagy késleltetést jelen Felesleges újraküldések

Miért lehet mégis jó a TCP? Az adatátviteli hálózat vagy a kliens készülékek speciális tulajdonságai miatt:  A tűzfalak csak a HTTP forgalmat engedik át: kénytelen vagyunk a médiát is HTTP protokollal átvinni  Az UDP megvalósítás akkora pufferelést igényel (pl. szolgáltatás kiesési idő nagy), hogy az már TCP átvitel ingadozását is kiegyenlítené  A dekóder adott (pl. nagyon sokféle kliens), és nem tolerálja a csomagvesztést

Multimédia átvitele UDP felett  Real-time multimédia igényli: Időbélyeg: AV szinkron, órajel regenerálás Sorszámozás: csomagvesztés detektálása Kodek azonosítás, on-the-fly váltáshoz (a tartalom a lényeg, nem a formátum) Forrás azonosítás  1. megoldás: RTP  2. megoldás: rendszerfolyam (MPEG-2 TS, MPEG-4)

RTP és QoS  Az RTP és RTCP nem biztosít QoS-t, de…  Az RTCP üzenetekkel fontos QoS paramétereket lehet mérni: Csomagvesztési arány Késleltetés ingadozás Átlagos átviteli sávszélesség (az adott idő alatt átment bájtok számából)  Az RTCP üzenetek értelmezésével alkalmazás szinten kell a QoS-t megvalósítani.

Streaming média szerver  Sok kliens kezelése párhuzamosan  Egyetlen kliensre (unicast): A szükséges R kijátszási bitsebesség meghatározása. R bitsebesség és a kliens képességének megfelelő kodek használata. Kijátszás előéletének nyilvántartása: újraküldés és statisztikai célból. Újraküldés: a tényleges kijátszás megismétlése vagy kulcsképként új predikciós láncot indítva.

Küldési bitsebesség vezérlés  A vezérlés alapja, hogy a média forrás (küldő) változtatni tudjon a küldési sebességen az átviteli út állapotának függvényében.  Megvalósítás: a szabályozás alapja szinte mindig: a két végpont közötti csomagvesztési arány a körbefordulási idő figyelése, és ennek változása esetén döntenek másik (nagyobb, kisebb) bitsebesség mellett

Küldési sebesség vezérlés vezetékes hálózatokon - TCP  Feltevés: csomagvesztés csak a torlódás miatt  Ablakméret változtatásán alapul: AIMD (Additive Increase, Multiplicative Decrease)  Esemény vezérelt: ACK vagy timeout esetén  Küldési sebesség: W·csomagméret/T körbefordulási  Ablakméret változtatás (állandósult helyzet): Ha ACK érkezik: W = W + 1/W Ha csomagvesztés lesz: W = W/2  Megfigyelt küldési sebesség p csomagvesztési arány és M csomagméret esetén

TCP-hez hasonló küldési sebesség vezérlés vezetékes médiaátvitelre  Feltételek: a média kódolás olyan, hogy a bitsebesség változtatható menet közben, csomagvesztés csak torlódás miatt van.  Küldési sebesség: mint TCP-re a heurisztikus képlet  Vezérlési algoritmus: Szerver és kliens: mérik a p end-end és T körbefordulási -t, kb. minden T körbefordulási idő alatt. A szerver a kijátszási sebességet az ez alapján kiszámított értékben határozza meg.

Küldési sebesség vezérlés vezeték nélküli hálózatokon  Csomagvesztés a rádiós csatornahiba miatt is  Nem teljesül az a feltétel, hogy a csomagvesztést csak a torlódás okozza.  Megoldások: A világ összes hálózati eszközét módosítani (Alkalmazás réteg?, Transzport réteg?, Hálózati réteg?, Hardver?) Vezetékes és nem-vezetékes esetre külön protokoll Heurisztikusan: sok hiba →kisebb bitsebesség

Média küldési sebesség vezeték nélküli hálózatokon  Cél a mai viszonyok mellett: A teljes rendelkezésre bocsátott rádiós kapacitás kihasználása. A rádiós csatornán a csomagvesztést állandónak tekintve meghatározzuk a nettó átviteli sebességet.  Problémák: Bearer alapú átviteli modell, csomag alapú átvitelnél (HSUPA!) kérdéses Bizonyos közegeken (GPRS, WLAN) a csomagvesztési arány sem állandó.

Streaming média lejátszó  Csomagvesztés, sorrend hiba kezelése  A „megmaradt” adatok dekódolása.  A forrás órajelének visszaállítása: órajel regenerálás jitter kiküszöbölés A kijátszás ingadozó bitsebességének kiküszöbölése  Megjelenítés a pontos időpontban  Interaktivitást biztosító felhasználói felület.

Streaming média lejátszó jellemző protokoll rétegei UDPTCP IP RTP Audió dekóderVezérlés Adatátvitel Videó dekóder Csomagolás, szinkronizáció Hozzáférési hálózat

Példa: atomi videós szolgáltatások mobiltelefonokra Atomi szolgáltatások:  Streaming videó megtekintése mobil készülékkel  Hibrid készülék DVB-H, DMB stb. képességekkel  Rögzített kép/videó elküldése MMS üzenetként  Kép vagy mozgókép felvételek elküldése IP felett  Videó telefonhívás mobil készülék és számítógép között A fenti alapszolgáltatásokból építhető fel a komplexebb szolgáltatás

Köszönöm a figyelmet!