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ó [email protected]
Jan 07, 2016
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ó[email protected]
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!