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ólois@hit.bme.hu

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 rbecsült bitsebességen:

Akkor játszhatunk le, ha M < T·rbecsü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

rbecsü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 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 kapcsolat Teljes bitsebesség

Videó bitsebesség

Képméret Képvált. Frekv.

GPRS 32 kbit/s 24 kbit/s 160 x 120 6¼ Hz

EDGE 50 kbit/s 48 kbit/s 160 x 120 8⅓ Hz

UMTS 128 kbit/s 112 kbit/s 160 x 120 12½ Hz

UMTS, WLAN 192 kbit/s 176 kbit/s 320 x 240 12½ Hz

HSDPA, WLAN 256 kbit/s 224 kbit/s 320 x 240 12½ Hz

WLAN, DSL 320 kbit/s 288 kbit/s 320 x 240 12½ Hz

DSL, LAN 512 kbit/s 448 kbit/s 352 x 288 25 Hz

DSL, LAN 1800 kbit/s 1500 kbit/s 704 x 576 50 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 UDP

Média lejátszó

(Tárolt) média tartalom

CTRL 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ánya 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/Tkö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égp csomagvesztési arány ésM csomagméret esetén endendlásikörbefordu pT

MR

22.1

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 pend-end és Tkörbefordulási-t, kb. minden Tkörbefordulási idő alatt.

A szerver a kijátszási sebességet az ez alapján kiszámított értékben határozza meg.

endendlásikörbefordu pT

MkR

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

UDP TCP

IP

RTP

Audió dekóder Vezérlés AdatátvitelVideó 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!