Multimédia v sítích 1. prosince 2012 Proč multimédia a datové sítě? ► Dobrý zdroj dat, relativně velké objemy, specifické nároky na samotný přenos Aplikace multimediálních přenosů ► Streaming ► Videokonference ► aplikace požadující zcela konkrétní vlastnosti přenosu multimediálních dat (např. end-to-end zpoždění) ► požadavky na přenos zásadně ovlivňují možnosti zpracování multimediálních dat Parametry kódování videa pro přenos sítí ► Objem komprimovaných dat (rozlišení x reprezentace barevného prostoru x framerate) vs. kapacita sítě vs. rychlost kódování multimediálního streamu ► Typicky malý bitrate (řádově max. jednotky Mbps), ačkoliv pro kvalitní přenosy se používá bitrate v řádu desítek i stovek Mbps ► Lze snížit rozlišení ► Lze snížit framerate - u videokonferencí není framerate tolik podstatný ► Problematické použití VBR ► Nemá smysl používat B frames, opatrně např. i s délkou GOP Protokoly na transportní vrstvě - TCP ► Stavový protokol na transportní vrstvě ISO/OSI modelu ► Vlastnosti významné pro multimediální přenosy ► Bezchybný přenos ► Retransmise ztracených paketů Pakety vždy dorazí ve správném pořadí ► Kontrola zahlcení linky ► Férový protokol ► Nevýhody TCP pro multimediální přenosy ► Bezchybnost přenosu je na úkor nízké latence ► Férovost nedovoluje dostatečnou šířku pásma na vytížených linkách Protokoly na transportní vrstvě - UDP ► Bezstavový protokol na transportní vrstvě ISO/OSI modelu ► Nespolehlivý protokol ► Pakety mohou přicházet mimo původní pořadí ► Pakety se mohou ztratit bez jakéhokoliv upozornění ► Ale odpadá režie s ověřováním, ze každý paket dorazil v pořádku a hlavně s retransmisemi ► V porovnání s TCP minimalistický, efektívnejšia rychlejší ► UDP prakticky nezvyšuje latenci při přenosu multimediálních dat ► Multimediální aplikace využívají v drtivé většině případů protokol UDP pro přenos dat (až na speciální případy) Protokoly na transportní vrstvě ► RTP ► Real-Time Transport Protocol ► Postavený nad protokolem UDP ► Klíčové vlastnosti ► Identifikace obsahu ► Sekvenční číslovaní paketů ► Časové značky pro jednotlivé pakety ► Protokol sám od sebe nezaručuje kvalitu přenosu, pouze poskytuje prostředky pro zaručení kvality aplikacím ► RTCP - RTP Control Protocol (RTCP) ► Real time control protocol doplňuje protokol RTP ► Poskytuje out-of-band informace pro řízení proudu dat přenášeného pomocí RTP ► RTCP poskytuje aplikaci zpětnou vazbu na kvalitu přenosu pomocí protokolu RTP Protokoly pro přenos multimediálního obsahu ► RTSP ► Real-time Streaming Protocol Stavový protokol založený na HTTP požadavcích (GET apod.) ► Ovládání streaming serveru (VCR příkazy jako Play, Pause a Stop) a přístup k souborům podle času ► Pro přenos dat se používá protokol RTP + RTCP případně jeho proprietami obdoba RDT ► ► MMS ► Microsoft Media Services nebo také Netshow services Proprietami protokol pro streaming ► Pro přenos dat se používají protokoly UDP nebo i TCP pokud se nezdaří vyjednat spojení na protokolu UDP ► Jako poslední z možností je "streaming" pomocí upraveného protokolu HTTP (tedy opět nad protokolem TCP) Chybovost přenosu a oprava chyb ► Nutnější hlavně u zvuku, používá se samozřejmě i u přenosu obrazu Buffery ► Forward Error Correction (FEC) ► XORování ► posílání druhého proudu (v nižší kvalitě) ► prokládání (interleaving) ► oprava chyb na straně klienta ► nahrazení daty z předchozího paketu ► interpolace Posílání druhého proudu 1 2 2 3 3 síť r 1 2 výpadek 3 Interleaving sít |1|2 3 4 | 5 | 6 7|8| 9 |10|11|12| 13|14|15|16| r 75 9 13 | 2 | 6 10|14| 3 | 7 |11|15| 4 8 12|16| > i- 5 9 13 | 2 | 6 10|14| výpadek | 4 I S 12|16| | 1 | 2 4 |5|6| |s| 9 |10| |12| 13|14 |16| Point-to-point vs. multipoint ► Point-to-point ► Multipoint ► 1:N ► Rozšíření point-to-point schématu ► Streaming - VOD ► Streaming - push schéma ► Multimediální stream se může šířit sítí v mnoha kopiích a zahlcovat ji ► M:N ► Typicky videokonference ► Problémy šíření multimediálních streamů ► Firewally ► Nat Unicast Multicast ► Efektivní schéma pro posílání multimediálních dat ► Routery vytvářejí optimální strom cest po kterých se šíří multimediální data Postavený na protokolu UDP (nad TCP nemá smysl, TCP vytváří spojení mezi dvěma konkrétními uzly) ► Relativně nespolehlivé schéma ► Multicast se v nešíří napříč všemi sítěmi ► Bezpečnostní rizika Multicast Zrcadla, Content Delivery Networks ► SW který přijímá multimediální streamy od jednotlivých klientů a přeposílá je ostatním připojeným klientům ► Vytváří překryvovou síť, která emuluje multicast v síti, kde se multicast nešíří ► Neřeší problém redundance multimediálních streamů na jednotlivých linkách ► Možná schémata použití - 1:N, M:N Video konference vs. Streaming ► Streaming ► Způsob doručení multimediálního obsahu klientům prostřednictvím sítě ► Přidaná hodnota porovnání s prostým stažením multimediálního obsahu ► Live streaming ► Doručování multimediálního obsahu, který vzniká živě během streamování ► Video on Demand vs. pasivní příjem ► Pasivní příjem se obvykle používá pro příjem živých streamů ► Je samozřejmě možné streamovat i multimediální archivy ► Video a audio nelze kódovat libovolně. ► Videokonference ► Jednoznačný požadavek na interaktivitu ► V porovnání se streamingem přináší další omezující požadavky na zpracování videa a audia. Videokonference vs. Streaming ► Videokonference ► Při přenosu nelze používat bufFery ani na straně odesílajícího ani na straně příjemce - vyžadujeme interaktivitu a tedy nízké latence ► Potřeba využívat kodeky s nízkou latencí ► Latence a její rozptyl při přenosu sítí je také velmi problematická ► Streaming ► Díky jednosmernosti provozu můžeme data bufFerovat ► Latence při přenosu vznikající při kompresi videa není problém ► Latence vznikající přenosem v síti a její rozptyl také není podstatná - lze řešit bufFerem Streaming HTTP GET Web browser Web server W presentation desc. SETUP media player media server PLAY media stream PAUSE TEARDOWN client server Formáty Vhodné pro streaming ► Kompresní mechanismy ► Nejsme limitování nutností udržet nízkou end-to-end latenci -z tohoto hlediska lze použít prakticky libovolný kodek Komprese musí být realtime což diskvalifikuje zejména vaweletovou kompresi ale i některé pokročilé MPEG profily ► Obvykle pouze CBR kódování - u VBR nejsme dobře schopni předvídat, zda nepřekročíme bitrate daný dostupným pásmem ► Obálkové formáty ► Zapouzdření více proudů videa a audia ► Metadata ► Podpora pro zotavení z chyb způsobených přenosem ► Adaptace na změny parametrů přenosových linek RealVideo ► Proprietami kompresní formát od RealNetworks ► Zaměření na streamované video ► Celkem 4 různé kodeky. ► Počáteční verze postavené na H.263 (RV10, RV20). ► Dnes proprietami kodek údajně postavený na silně modifikovaném H.263 resp. MPEG-4 AVC (RV30, RV40). ► Podpora pro CBR i VBR kódování ► Použití ve spojení s obálkovým formátem Real Media, Real Time Streaming protokolem (RTSP), Real streaming serverem a technologií SureStream Windows Media Video ► Proprietátrní množina kompresních mechanismů původně vyvinutých pro streaming na nízkých bitratech ► Komprese založená na nestandardních verzích MPEG-4 ASP, dnes téměř výhradně VC-1 ► Obvykle ve spojení s obálkovým formátem ASF (pro streaming) ► Jako podmnožina možností obálkového formátu ASF existuje obálkový formát nazvaný Windows Media Video (neplést s kodekem a už vůbec ne s kompresními mechanismy) MPEG-TS vs. MPEG-PS ► MPEG-TS ► Definuje způsob synchronizace a přenosu MPEG audia a videa ► Součást rodiny standardů MPEG-2, ale neomezuje se pouze na MPEG-2 video nebo audio ► Přenos po nespolehlivých linkách —>• error correction ► Lze multiplexovat i dalši data (např.: televizní program) ► Použití: streaming MPEG videa, DVB ► MPEG-PS ► Prostý kontejner pro video a audio ve formátu MPEG RealMedia ► Obálkový formát podporující formáty RealAudio resp. RealVideo ► Proprietami formát ► Dva obálkové formáty ► rm - přenos CBR kódovaného videa ► rmvb - přenos VBR kódovaného videa ► Podpora pro streaming ► Podpora pro SureStream - v obálce je uložený tentýž stream vícekrát s různými parametry kódování a zejména bitratem ► Dále definuje maximální a průměrný bitrate uloženého videa, doporučenou velikost bufferu přehrávače apod. Široká podpora metadat ► Včetně například hodnocení závadnosti obsahu ASF ► Advanced Systems Formát, dříve Advanced Streaming Formát ► Proprietami obálkový formát Microsoftu, podpora streamování ► Podpora pro přehrávání obsahu ze streaming serveru, HTTP serveru nebo z lokálního disku ► Specifikuje strukturu pro ukládání audia a videa a přístup k jednotlivým multimediálním proudům ► Nespecifikuje konkrétní formáty pro kódování audia nebo videa, ale obvykle se používá spolu s Windows Media Video resp. Windows Media Audio ► Implementuje techniky pro korekci chyb vzniklých během přenosu ► Podpora DRM (pouze ve spojení s WMW nebo WMA) Flash video ► Obvykle varianta H.263, prípadne MJPEG, MPEG4 AVC ► Audio ve formátu PCM, ADPCM nebo MP3, AAC Široká podpora v přehrávačích napříč platformami (nejen Macromedia Flash player) ► Streaming pomocí proprietarního Real Time Messaging Protocol (RTMP) protokolu od Adobe a Flash Media serveru ► Progressive download ► Přenos protokolem HTTP —>• neblokované firewally ► Libovolný přístup k videu «— není nutné přehrávat sekvenčně ► BufFer na straně klienta ► Neporadí si s kolísající šírkou pásma a s nižší šírkou pásma než je bitrate videa Standardy ve videokonferencích ► H.323 a SIP (Session Initiation Protocol) ► často komerční řešení s HW podporou Polycom ViewStation FX, Tandberg 880 ► MS Netmeeting, GnomeMeeting, Ekiga, OHphoneX, CUSeeMe, OpenH323, OpenWengo ► Voice over IP Architektura H.323 videokonferencí ► HW a SW klienti (SW klienti nejsou většinou příliš kompatibilní se zbytkem světa) ► Brány (gateways) ► přechody mezi sítěmi ► konverze dat pro různé sítě ► Gatekeepery ► překlady adres, management šířky pásma ► autentizace, autorizace, accounting (AAA) ► Multipoint Connection Units (MCU) ► H.323 je v podstatě point-to-point protokol ► MCU přidává možnost spojení point-to-multipoint Multipoint Control Unit Obdoba zrcadel pro videokonference Používá se ve spojení s H.323 videokonferencemi a H.260 telekonferencemi nad ISDN (viz příští přednáška) Vyjednává parametry komunikace s jednotlivými klienty (kodeky, šířku pásma apod.) Na rozdíl od zrcadla MCU řeší mixování audia a videa od jednotlivých účastníků Typicky drahé zařízení implementované v HW Architektura H.323 H.323 stack Audio signal [ G.711 ] [ Q.72S j ~T HAS ][ HTP Supplementary [ H.450.3 ][ H.4S0.2~~] T [ H.JbO/1 ] H.2d5 T H.Z2S Control [ T12S T.125.T.122 < □ ► Komunikace v H.323 H.323 GW Signalizační část Setup Xh.225(TCP) — T (Q.931) £a£abiMtie^xchancji^ Open Logical Channel Ogen Logical Channel Ackriovvledfl; hovorové A RTP Stream -*. RTP Stream spojeni 1 RTCP Stream -*- H.245 (TCP) (UDP) H.323 GW Ukázka H.323 videokonference SIP ► Session Initiation Protocol ► RFC 3261 (starší RFC 2543) a řada dalších navazujících RFC ► Čistě textový protokol ► Entity ► klient (UAC) i server (UAS) současně ► proxy server ► redirect server ► na rozdíl od proxy serverů jen překládá adresy, ale nejedná za klienty ► Registrar ► přebírá registrační funkci gatekeeperu v H.323 SIP - zprávy ► INVITE: Přizvání účastníka ► ACK: Potvrzení přizvání. ► BYE: Zrušení spojení mezi účastníky ► CANCEL: Zrušení vyhledávání účastníka nebo zrušení požadavku INVITE ► OPTIONS: Vyjednání informací o možnostech serveru ► REGISTER: Registruje uživatelovo aktuální umístění ► INFO: Signalizace v rámci sezení SIP - příklad zpráv Message Request example INVITE sip:bob@biloxi.example.corn SIP/2.0 Via: SIP/2,0/TCP client.atlanta.example.com:5060. ;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag = 9fxced76sl To: Bob -^sipibobtSbiloxi,example.ccrn:=- Call-ID: 334S276293220183511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 o=alice 2330344526 2390844526 IN IP4 client.atlanta.exarnple.com s = - Message Response example c=IN IP4 192.0.2.101 t=0 0 m = audio 49172 RTP/AVP Q a=rtpmap:0 PCMU/3000 SIP/2.0 130 Ringing Via: SIP/2.0/TCP client,atlanta .example .com; 5060 ;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice --jtag=9fxced76sl To: Bob -^sipibobi^biloxi.example.corn> ;tag=B321234356 Call-ID: 3B43276298220l3e511@atlanta.exarnple.com CSeq: 1 INVITE Contact: -=:sip:bobrjSclient.biloxi.example.com;trans port=tcp> Content-Length: 0 SDP - Session Description Protoco ► Informace o sezení (session) ► jméno sezení, účel sezení, čas ► informace o šířce pásma ► kontaktní informace ► Informace o médiích ► typy médií (audio, video) ► transportní protokol (RTP, UDP) ► formát médií (H.261, H.263, GSM) ► v případě použití multicastu adresa a port SIP - navázání a ukončení spojení Alice's PC 1DD TRYING F2 100 TRYING F4 180 RINGING F7 ISO RINGING F6 RTF Media Session in Progress BYE F13 200 OK F14 SIP - složitější scénáře ► S přesměrováním ► UAC zkontaktuje RedirectServer, který pošle informaci o momentálním umístění UAC ► UAC zkontaktuje přímo UAS ► S proxy serverem proxy server vytvoří za UAC spojení ► na závěr utváření spojení přijde klientovi od UAS přes proxy 200/OK s přímou adresou UAS ► UAC pošle ACK přímo UAS a další komunikace jde přímo nebo je možno udržovat komunikaci přes proxy SIP - konference multipoint-to-multipoint ► Dialup conference bridge (podobné MCU, volá se adresa mostu) ► Distributed multiparty conference (bez serveru) ► Multicast (INVITE se posílá do multicastové skupiny, neuplatňuje se full-mesh signalizace) ► V případě pouze 3 účastníků může jeden UA pozvat třetího účastníka a sám fungovat jako mixer