300 likes | 415 Views
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)
E N D
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ültmeghatározandó, sőt időben változhat
Példa fájl átvitel alapú médiaátvitelre: „http streaming” Jellemző megvalósítás: Internet TCP TCP Letöltési puffer 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ű átvitelrealkalmas formátumok a jelenlegi hálózatokon
Media streaming jellemző megvalósítása Most csak az átvitelre koncentrálva: Internet Letöltési puffer, jitter kiegyenlítés UDP UDP Küldés Ismétlés Majdnem minden keret ACK NACK puffer állapot CTRL CTRL Média lejátszó (Tárolt) média tartalom
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/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
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: mintTCP-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.
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 Audió dekóder Videó dekóder Vezérlés Adatátvitel Csomagolás, szinkronizáció RTP UDP TCP IP 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