A webalkalmazások és a mobilweb a hálózatok felhasználásában nem az egyedüli izgalmas fejlesztés. Sokak számára a multimédia jelenti a számítógépes hálózatok csúcsát. Amikor ez szóba kerül, mind a kockafejűeknek, mind az öltönyös alakoknak mintegy varázsütésre felcsillan a szemük. Az előbbiek hatalmas műszaki kihívásokat látnak abban, hogy minden számítógépen lehetővé tegyék az IP-hálózaton keresztül történő beszédátvitelt és a hálózati videózást. Az utóbbiak ugyanilyen hatalmas profitot látnak benne.
Míg az interneten keresztül történő hang és mozgókép küldésének ötlete az 1970-es években vagy még korábban megszületett, a valós idejű hang és mozgókép átvitel forgalma csak nagyjából 2000 óta növekedett meg, talán túlságosan is. A valós idejű forgalom abban különbözik a webes forgalomtól, hogy azt egy bizonyos előre meghatározott sebességgel kell lejátszani, hogy használható legyen. Elvégre a legtöbb embernek nem az az elképzelése a szórakozásról, hogy egy megakadó és elinduló lassított mozgóképet néz. Ezzel ellentétben a világhálón előfordulhatnak rövid megszakítások, az oldalbetöltések bizonyos kereteken belül több-kevesebb időt vehetnek igénybe anélkül, hogy ez komoly gond lenne.
Két dolog történt, ami lehetővé tette ezt a növekedést. Először is, a számítógépek sokkal nagyobb teljesítményűvé váltak, valamint felszerelték azokat mikrofonokkal és kamerákkal. Így könnyedén képesek a hangot és a mozgóképet beolvasni, feldolgozni és kiadni. Másodszor, lehetővé vált az internet sávszélességének jelentős növelése. Az internet belsejének hosszú távú összeköttetései több gigabit/s sebességgel működnek, a széles sávú és 802.11 vezeték nélküli szolgáltatás pedig eléri az internet szélén lévő felhasználókat. Ezek a fejlesztések lehetővé tették az internetszolgáltatók (ISP-k) számára, hogy hatalmas forgalmat bonyolítsanak le a gerinchálózatukon, ami azt jelenti, hogy az átlagos felhasználó így százszor-ezerszer gyorsabban fér hozzá az internethez, mint egy 56 kb/s sebességű telefonos modemmel.
A sávszélesség jelentős növekedése idézte elő a hang- és videoátviteli forgalom növekedését, de az okok eltérőek. A telefonhívások aránylag kis sávszélességet igényelnek (elvileg 64 kb/s-ot, tömörítéskor kevesebbet), de a telefonszolgáltatás hagyományosan drága. A vállalatok lehetőséget láttak arra, hogy a telefonszámláik csökkentése érdekében, a meglévő sávszélességet felhasználva a beszédforgalmat interneten keresztül továbbítsák. Az első ilyen cégek, mint például a Skype, megtalálták a módját annak, ahogyan lehetővé tehetik ügyfeleik számára az ingyenes telefonálást internet-hozzáférésük felhasználásával. A hirtelen meggazdagodott telefontársaságok meglátták azt, hogyan lehet a hagyományos hanghívásokat IP-hálózati berendezések felhasználásával olcsón továbbítani. Ennek eredménye az internethálózaton továbbított hangadatok robbanásszerű növekedése lett, amit IP-hálózaton keresztül történő beszédátvitelnek (voice over IP, VoIP) vagy internetes telefonálásnak (Internet telephony) neveznek.
A hangátvitellel ellentétben a mozgókép (videó) átvitele nagy sávszélességet igényel. Az elfogadható minőségű internetes videókat 1 Mb/s körüli adatsebességgel tömörítik, és egy tipikus DVD 2 GB adatot tartalmaz.[35] A széles sávú internet-hozzáférés előtt a filmek átküldése a hálózaton megengedhetetlen volt. Többé nem az. A széles sávú elérések elterjedésével először vált lehetővé a felhasználók számára, hogy a körülményekhez képest elfogadható minőségű, folyamszerűen letöltött (streaming) videót nézzenek az otthonukban. Az emberek szeretik ezt. Becslések szerint az internet felhasználóinak körülbelül a negyede mindennap meglátogatja a YouTube-ot, a népszerű videomegosztó helyet. A mozifilmek kölcsönzésével kapcsolatos üzlet eltolódott az online letöltések irányába. Az internetre feltöltött döbbenetes mennyiségű videó megváltoztatta az internet forgalmának teljes összetételét. Az internetes forgalom többségét ma már a videó adja, és úgy becsülik, hogy néhány éven belül az internet forgalmának 90%-a videoforgalom lesz [Cisco, 2010].
Tekintettel arra, hogy a hang- és videoátvitelhez elegendő a sávszélesség, a folyamszerű átvitelt és konferenciaszolgáltatásokat megvalósító alkalmazások tervezése szempontjából a hálózati késleltetés a kulcsfontosságú kérdés. A hang és a mozgókép valós idejű megjelenítést igényel, ami azt jelenti, hogy előre meghatározott sebességgel kell lejátszani ezeket ahhoz, hogy használhatók legyenek. A hosszú késleltetés azt jelenti, hogy a hívások, amelyeknek interaktívnak kellene lenniük, többé nem azok. Ez a probléma eléggé nyilvánvaló, ha Ön valaha is beszélt már műholdas telefonon, ahol ez az akár fél másodperces késleltetés meglehetősen zavaró. Zene és filmek hálózaton keresztüli lejátszásánál az abszolút késleltetés nem számít, mert annak csak akkor van hatása, amikor a média lejátszása megkezdődik. De a késleltetés változása (szórása), amit dzsitternek (jitter) neveznek, gondot okoz. Ezt el kell fednie a lejátszónak, különben a hang érthetetlen, a videó pedig szaggatott lesz.
Ebben a szakaszban meg fogunk tárgyalni néhány, a késleltetés problémáját kezelő stratégiát, valamint a hang- és video-munkamenetek létrehozására szolgáló protokollt. A digitális hang és mozgókép témakörébe történő bevezetés után ismertetőnk három eset tárgyalására tagolódik, melyek közül mindegyikben eltérő konstrukciót használnak. Az első és legkönnyebb eset a tárolt média folyamszerű letöltése, mint amilyen egy videó megtekintése a YouTube-on. A nehézség szempontjából a következő eset az élő médiaközvetítés. Ennek két példája az internetes rádió és az IPTV, amelyekkel a rádió- és televízióállomások sok felhasználó számára élőben sugározzák műsorukat az interneten. Az utolsó és legbonyolultabb eset a telefonbeszélgetések lebonyolítása, amit Skype-pal lehetne megtenni, vagy általában az interaktív audio- és videokonferencia.
Mellesleg, a multimédia (multimedia) kifejezést az internettel kapcsolatban gyakran használják a hangra és a mozgóképre. Szó szerint értelmezve, a multimédia két vagy több médiumot jelent. E definíció szerint ez a könyv egy multimédia-bemutató, mert szöveget és grafikát (ábrákat) tartalmaz. Valószínűleg azonban Ön nem erre gondolt, ezért a „multimédia” kifejezés alatt két vagy több folytonos médiát (continuous media) értünk, vagyis olyan médiumokat, amelyeket valamely jól meghatározott időintervallum alatt kell lejátszani. A két médium rendszerint az audio és a video, vagyis mozgókép hanggal. Sokan a puszta hangátvitelre, például az internettelefóniára vagy az internetes rádiózásra is multimédiaként hivatkoznak, pedig itt nyilván nem erről van szó. Valójában minden ilyen esetben helyesebb lenne a folyamszerű letöltésű média (streaming media) kifejezés használata. Mindazonáltal mi is követjük a nyájat, és a valós idejű hangátvitelt is multimédiának fogjuk tekinteni.
A hanghullám egy egydimenziós akusztikai (nyomás) hullám. Amikor egy akusztikai hullám belép a fülbe, a dobhártya elkezd rezegni, erre a belsőfül kicsiny csontjai is elkezdenek vele együtt rezegni, és ingerimpulzusokat küldenek az agyba. Ezeket az impulzusokat a hallgató hangként érzékeli. Hasonló módon, amikor egy akusztikai hullám elér egy mikrofont, a mikrofon egy villamos jelet állít elő, amely a hang amplitúdóját jellemzi az idő függvényében.
Az emberi fül által hallható hangok frekvenciatartománya 20 Hertztől 20 000 Hertzig terjed, bár néhány állat, főképpen a kutyák, képesek magasabb frekvenciákat is meghallani. A fül logaritmikusan érzékeli a hangerőt, így két A és B amplitúdójú hang arányát szokásosan dB-ben (decibel) fejezik ki, amely a 
összefüggéssel határozható meg. Ha egy 1 kHz-es szinuszhullám hallhatóságának alsó határát (amely kb. 20 
Pa hangnyomásnak felel meg) 0 dB-nek definiáljuk, akkor egy szokásos beszélgetés 50 dB körül van, a fájdalomküszöb pedig 120 dB. A dinamikatartomány több mint egymilliószoros.
A fül meglepően érzékeny az akár csak pár ezredmásodpercig tartó hangváltozásokra is. A szem, ezzel ellentétben, nem veszi észre a fényerősség olyan változásait, amelyek csak pár ezredmásodpercig tartanak. Ennek a megfigyelésnek az eredménye az, hogy egy multimédia lejátszásnál bekövetkező pár ezredmásodperces dzsitter az észlelt hangminőséget sokkal jobban befolyásolja, mint az észlelt képminőséget.
A digitális hang egy hanghullám digitális ábrázolása, ami felhasználható a hang újbóli előállításához. A hanghullámokat egy ADC (Analog Digital Converter – analóg-digitális átalakító) segítségével lehet digitális formára alakítani. Az ADC villamos feszültséget kap a bemenetén, és a kimenetén bináris számokat állít elő. A 7.42.(a) ábrán látható egy szinuszhullám példája. Hogy digitálisan kezelhessük ezt a jelet, minden 
időközönként mintát veszünk belőle, ahogy a 7.42.(b) ábrán az oszlopok mutatják. Ha egy hanghullám nem tiszta szinuszhullám, de szinuszhullámok lineáris szuperpozíciója, amelyek közt a legmagasabb frekvenciájú f, akkor a Nyquist-tétel értelmében (lásd 2. fejezet) elegendő 2f frekvenciával mintákat venni. Gyakrabban mintavételezni nincs értelme, mivel azok a magasabb frekvenciák, amelyeket egy ilyen mintavételezés észlelni tudna, nincsenek jelen.
7.42. ábra - (a) Egy szinuszhullám. (b) A szinuszhullám mintavételezettje. (c) A minták 3 bitre történt kvantáltja
A fordított folyamat digitális értékeket használ fel, és analóg villamos feszültséget állít elő. Ezt a feladatot a DAC (Digital-to-Analog Converter – digitális-analóg átalakító) végzi el. Az analóg villamos feszültséget azután a hangszóró hanghullámokká alakítja, így az emberek hallhatják a hangokat.
A digitális minták soha nem teljesen pontosak. A 7.42.(c) ábra mintái csak nyolc értéket tesznek lehetővé –1,00 és +1,00 közt, 0,25-ös lépésekben. Egy 8 bites minta 256 különböző értéket tenne lehetővé. Egy 16 bites minta 65 536 különböző értéket tenne lehetővé. A mintánkénti véges számú bit által behozott hibát kvantálási zajnak (quantization noise) nevezik. Ha ez túl nagy, a fül ezt érzékeli.
A mintavételezett hangok két jól ismert példája a telefon és a hang-CD-k. A pulzuskód-moduláció, amelyet a telefonrendszerben használnak, 8 bites mintákkal dolgozik, és másodpercenként 8000 mintát vesz. A skála az érzékelhető torzítás csökkentése érdekében nem lineáris, és a másodpercenkénti mindössze 8000 minta miatt a 4 kHz fölötti hangok elvesznek. Észak-Amerikában és Japánban a 
-law, Európában és nemzetközileg az A-law kódolást használják. Mindkét kódolás 64 000 b/s adatsebességet eredményez.
A hang-CD-k digitálisak, másodpercenként 44 100 mintával, amely elég ahhoz, hogy 22 050 Hz-ig visszaadja a hangokat, amely az emberek számára jó, de a zenerajongó kutyák számára rossz. Mindegyik minta 16 bites, és az amplitúdótartományon belül lineáris. Vegyük észre, hogy a 16 bites minták csak 65 536 különböző értéket tesznek lehetővé, bár a fül dinamikatartománya 1 millió fölötti. Tehát annak ellenére, hogy a CD-minőségű hang sokkal jobb a telefonminőségűnél, mintánként csak 16 bit használata észrevehető kvantálási zajt okoz (bár nincs lefedve a teljes dinamikatartomány, a CD-knek nem szabad fájdalmat okozniuk). Néhány fanatikus audiofil még mindig előnyben részesíti a 33-as fordulatú bakelitlemezeket a CD-kkel szemben, mert ezeknél nem jelentkezik a Nyquist frekvencialevágás 22 kHz-nél, és nincs kvantálási zaj sem. (Azonban sercegnek, ha nem kezelik őket rendkívül óvatosan.) Másodpercenként 44 100 16 bites minta esetén a tömörítetlen CD-minőségű hangnak 705,6 kb/s (mono) vagy 1,411 Mb/s (sztereo) sávszélességre van szüksége.
Annak ellenére, hogy a hangátvitelhez szükséges sebesség sokkal kisebb, mint a mozgóképátvitelhez szükséges sebesség, a hangokat gyakran tömörítik a sávszélességigény és az átviteli idő csökkentése érdekében. Minden tömörítő rendszernek két algoritmusra van szüksége: az egyik a forrásnál tömöríti össze az adatokat, a másik pedig a célban kibontja azokat. Az irodalomban ezekre mint kódoló (encoding) és dekódoló (decoding) algoritmusokra hivatkoznak. Mi is ezt a terminológiát fogjuk használni.
A tömörítő algoritmusok bizonyos aszimmetriákat mutatnak, amelyeket fontos megérteni. Annak ellenére, hogy először a hangokkal foglalkozunk, ezek az aszimmetriák a videókra is érvényesek. Sok alkalmazás esetén egy multimédiás dokumentumot csak egyszer kódolják (a multimédiakiszolgálón történő tároláskor), de több ezerszer dekódolják (amikor az ügyfelek lejátsszák). Ez az aszimmetria azt jelenti, hogy a kódoló algoritmus lehet lassú, és igényelhet drága hardvert, feltéve, hogy a dekódoló algoritmus gyors és nem igényel drága hardvert. Egy népszerű hang (vagy videó) kiszolgáló üzemeltetője lehet, hogy nagyon szívesen vásárol egy több számítógépből álló fürtöt (clustert) teljes könyvtárának kódolásához, de nem valószínű, hogy nagy sikert aratna, ha ugyanezt követelné meg az ügyfelektől a zene hallgatásához vagy a film nézéséhez. Sok gyakorlati tömörítő rendszer sokat megtesz azért, hogy a dekódolást gyorssá és egyszerűvé tegye, még annak árán is, hogy a kódolás lassú és komplikált lesz.
Másrészről viszont az élő hang és videó esetében, mint amilyen például az IP-hálózaton keresztül történő beszédhívás, a lassú kódolás elfogadhatatlan. A kódolásnak röptében, valós időben kell megtörténnie. Következésképpen a valós idejű multimédia más algoritmusokat vagy paramétereket használ, mint a filmek lemezen való tárolása, gyakran jelentősen kisebb tömörítéssel.
Egy másik aszimmetria, hogy a kódolási/dekódolási folyamatnak nem kell visszafordíthatónak lennie. Egy adatállomány tömörítése, átvitele és visszaállítása után a felhasználó arra számít, hogy az eredetivel az utolsó bitig megegyező eredményt kap vissza. A multimédiában ez a követelmény nem létezik. Általában elfogadható, ha a hang (vagy videó) jel a kódolás és az azt követő dekódolás után csak kissé tér el az eredetitől mindaddig, amíg ugyanolyannak hangzik (látszik). Amikor a dekódolt kimenet nem teljesen azonos az eredeti bemenettel, a rendszert veszteségesnek (lossy) nevezzük. Ha a bemenet és a kimenet megegyeznek, a rendszer veszteségmentes (lossless). A veszteséges rendszerek fontosak, mivel egy kismértékű információvesztést elfogadva általában hatalmas nyereség elérhető el a tömörítési arányban.
Régen, a telefonhálózatokban, a nagy távolságon biztosított sávszélesség nagyon drága volt, ezért jelentős munka hárult a vokóderekre (vocoder, ami a „vocal coder”, azaz a hangtömörítő rövidítése), amelyek kimondottan emberi beszédhangokat tömörítenek. Az emberi beszéd általában 600 és 6000 Hz közé esik, és olyan mechanikai folyamat állítja elő, ami a beszélő hangképző szervétől, nyelvétől és állkapcsától függ. Néhány vokóder a hangképző rendszer modelljét használja, hogy a beszédet mindössze pár paraméterre sűrítse össze (a különféle üregek méretére és alakjára), az adatátviteli sebességet pedig mindössze 2,4 kb/s-ra csökkentse. Az ilyen vokóderek működése azonban túlmutat könyvünk keretein.
Mi az interneten keresztül küldött hangokra fogunk koncentrálni, ami általában közel CD-minőségű. Az ilyen hangok adatátviteli sebességét is kívánatos volna csökkenteni. A sztereó hang 1,411 Mb/s sebessége sok széles sávú adatkapcsolatot foglalna le, kevesebb helyet hagyva a videóknak és más webes forgalomnak. Ennek adatátviteli sebessége tömörítéssel egy nagyságrenddel csökkenthető, észrevehetelen vagy alig észrevehető minőségromlás mellett.
A tömörítéshez és kibontáshoz jelfeldolgozás szükséges. Szerencsére a digitalizált hang és filmek a számítógépes szoftverrel könnyen feldolgozhatók. Valójában több tucat olyan program létezik személyi számítógépekre, amelyek lehetővé teszik, hogy a felhasználók különböző forrásokból származó médiát rögzítsenek, megjelenítsenek, szerkesszenek, keverjenek és eltároljanak. Ez vezetett oda, hogy nagy mennyiségű zene és film érhető el az interneten – nem mindegyik legálisan –, ez az oka annak, hogy a művészek és a szerzőijog-tulajdonosok számos bírósági pert kezdeményeztek.
Számos hangtömörítő algoritmust fejlesztettek ki. A legnépszerűbb formátumok valószínűleg az MP3 (MPEG audio layer 3 – MPEG-hangréteg 3) és az MP4 (MPEG-4) állományokban alkalmazott AAC (Advanced Audio Coding – fejlett hangkódolás). A félreértés elkerülése végett jegyezzük meg, hogy az MPEG hang- és videotömörítést is biztosít. Az MP3 az MPEG-1 szabvány hangtömörítő részére (3. rész) utal, nem pedig az MPEG harmadik változatára. Az MPEG harmadik változatát valójában nem is adták ki, csak az MPEG-1-et, MPEG-2-t és az MPEG-4-et. Az AAC az MP3 utóda, és az MPEG-4 alapértelmezett hangkódolása. Az MPEG-2 megengedi mind az MP3, mind az AAC használatát is. Világos most már? Az a szép a szabványokban, hogy oly sok közül lehet választani. És ha valakinek ezek közül valamelyik nem tetszik, csak várjon egy-két évet!
A hangtömörítést kétféleképpen lehet megoldani. A hullámforma-kódolás (waveform coding) során a jelet matematikai eszközökkel, Fourier-transzformációval a frekvenciatartományba transzformálják. A 2. fejezetben a 2.1.(a) ábrán egy időfüggvényre és a hozzá tartozó Fourier-amplitúdókra mutattunk egy példát. Ezután minden komponens amplitúdóját minimális módon kódolják. A cél az, hogy a másik oldalon elég pontosan visszaállítható legyen a hullámforma, a lehető legkevesebb bit felhasználásával.
A másik megoldás az érzékelési kódolás (perceptual coding), mely az emberi hallórendszer bizonyos hiányosságait használja ki a jelek kódolására. Ezeket a kódolt jeleket az emberi fül ugyanolyannak hallja, mint az eredeti jeleket, pedig egy oszcilloszkópon egészen más képet mutatnak. Az érzékelési kódolás a pszichoakusztika (psychoacoustics) tudományán alapszik, mely azzal foglalkozik, hogy az emberek hogyan érzékelik a hangokat. Az MP3 és az AAC is az érzékelési kódoláson alapul.
Az érzékelési kódolás kulcsa az, hogy egyes hangok elfedhetnek (mask) másokat. Képzeljük el, hogy egy élő fuvolakoncertet közvetítünk egy meleg nyári napon. Egy csapat munkás a közelben egyszer csak beindítja a légkalapácsokat, és elkezdik felbontani az utcát. Onnan kezdve a fuvolát senki nem fogja hallani – a hangját elfedik a légkalapácsok. Az átvitel szempontjából ezután elég lesz csak a légkalapácsok frekvenciasávját kódolni, mert a hallgatók úgysem fogják meghallani a fuvolát. Azt a jelenséget, amikor az egyik frekvenciasávban lévő erősebb hang képes elnyomni egy másik frekvenciasávban lévő halkabb hangot, mely az erősebb hang hiányában amúgy hallható lenne, frekvenciaelfedésnek (frequency masking) nevezik. A fuvola valójában még a légkalapácsok leállítása után sem fog hallatszani egy kis ideig, mert a fül érzékenysége csökken, amikor a légkalapácsok beindulnak, és utána eltart egy bizonyos ideig, míg ez az érzékenység újra helyreáll. Ezt a jelenséget ideiglenes elfedésnek (temporal masking) nevezik.
Ahhoz, hogy ezek a hatások mennyiségileg is szemléletesebbé váljanak, képzeljük el az alábbi első kísérletet. A kísérleti alany egy csendes szobában felvesz egy fejhallgatót, melyet egy számítógép hangkártyájához kötöttek. A számítógép egy 100 Hz-es tiszta szinuszhullámot generál, először halkan, aztán fokozatosan egyre hangosabban. A kísérleti alanynak egy gombot kell megnyomnia, amikor először meghallja a hangot. A számítógép ekkor feljegyzi az aktuális hangerőt, majd megismétli a kísérletet 200 Hz-en, 300 Hz-en és így tovább, az összes frekvencián az emberi hallástartományon belül. Ha sok ember eredményeit átlagolják, akkor a 7.43.(a) ábrán láthatóhoz hasonló logaritmikus görbét kapnak, mely megmutatja, hogy az egyes hangoknak milyen hangerővel kell megszólalniuk ahhoz, hogy hallhatók legyenek. A görbe közvetlen következménye, hogy soha sincs szükség azon frekvenciák kódolására, melyek hangereje a hallhatósági küszöb alatt marad. Például, ha a 7.43.(a) ábrán látható esetben a 100 Hz-es hang hangereje 20 dB lenne, akkor azt érzékelhető minőségvesztés nélkül is kihagyhatnánk a kimenetből, mert a 20 dB 100 Hz-en a hallhatósági küszöb alatt marad.
Tekintsünk most egy második kísérletet. A számítógép ismét az előző kísérletet futtatja, de a teszthangokra ezúttal egy másik, állandó hangerővel rendelkező, mondjuk 150 Hz-es szinuszhullámot ültet. Azt tapasztaljuk, hogy a hallhatósági küszöb a 150 Hz körüli frekvenciák esetében megemelkedik, ahogy azt a 7.43.(b) ábra mutatja.
Új megfigyelésünknek az a következménye, hogy egyre több frekvenciát hagyhatunk ki a kódolt jelből, vagyis biteket takaríthatunk meg, ha számon tartjuk, hogy milyen jeleket takarnak el a közeli frekvenciasávok erősebb jelei. A 7.43. ábrán a 125 Hz-es jelet teljesen elhagyhatjuk a kimenetből, mégse fogja meghallani a különbséget senki. Sőt az ideiglenes elfedési tulajdonságok ismeretében egy bizonyos ideig még azután is elhagyhatjuk az elfedett frekvenciákat, hogy az erősebb jel egy adott frekvenciasávban véget ért; egészen addig, míg a hallás helyre nem áll. Az MP3 lényege az, hogy a hangot Fourier-transzformálják, hogy megkapják az egyes frekvenciák teljesítményét, majd ezek közül csak a nem elfedett frekvenciákat viszik át, a lehető legkevesebb bitben kódolva.
Ezzel a háttérrel már nekivághatunk a kódolás tárgyalásának is. A hangtömörítéshez a hullámformát az AAC esetében 8 és 96 kHz közötti frekvenciával mintavételezik, a CD hangjának utánzása érdekében gyakran 44,1 kHz-en. A mintavételezés történhet egy (mono) vagy két (sztereo) csatornán. Ezt követően a kimeneti adatsebességet határozzák meg. Az MP3 segítségével egy sztereó rock and roll CD-t akár 96 kb/s adatsebességgel is be lehet tömöríteni úgy, hogy a minőségvesztést még a nem halláskárosult rajongók is alig veszik észre. Egy zongorakoncerthez ugyanakkor már legalább 128 kb/s adatsebességű AAC szükséges. A különbség abból fakad, hogy a rock and roll jel/zaj viszonya sokkal magasabb, mint a zongorakoncerté (legalábbis mérnöki értelemben). Persze kisebb kimeneti sebességet is lehet választani, ha el tudunk fogadni némi minőségromlást.
A mintákat kis kötegekben dolgozzák fel. Minden köteget egy digitális szűrősorozaton visznek át, hogy frekvenciasávokat kapjanak. A frekvenciainformációt egy pszichoakusztikus modellel dolgozzák fel, hogy meghatározzák az elfedett frekvenciákat. Ezután a rendelkezésre álló bitkészletet felosztják a sávok között, melynek során több bitet osztanak ki azoknak a sávoknak, ahol több elfedetlen spektrális teljesítmény van, kevesebb bitet azoknak az elfedetlen sávoknak, melyeknek kisebb a spektrális teljesítménye, és egyetlen bitet sem adnak az elfedett sávoknak. A biteket végül a Huffman-kódolás segítségével kódolják, ami rövid kódszavakat rendel a gyakran előforduló számokhoz és hosszú kódszavakat a ritkábbakhoz. Sokkal több részlet is létezik a kíváncsi olvasó számára. További információért lásd Brandenburg [1999] munkáját.
Most, hogy már mindent tudunk a fülről, ideje áttérnünk a szemre. (Nyugalom, ezután már nincs egy következő fejezet az orról.) Az emberi szemnek megvan az a tulajdonsága, hogy ha egy kép jelenik meg a retinán, akkor az pár ezredmásodpercig ott is marad, mielőtt eltűnne. Ha egy képsorozatot 50 kép/másodperc sebességgel rajzolnak ki, akkor a szem nem észleli, hogy valójában különálló képeket lát. Minden videorendszer ezt az elvet használja ki a mozgóképek előállítására.
A mozgókép legegyszerűbb digitális reprezentációja képek sorozata, ahol mindegyik kép képelemek (pixelek, képpontok) téglalap alakú rácsából áll. Minden képpont lehet egyetlen bit, amely vagy fehéret, vagy feketét jelképez. Egy ilyen rendszer minősége azonban szörnyű. Próbálja meg kedvenc képszerkesztője segítségével egy színes kép képelemeit feketére és fehérre (és nem szürkeárnyalatosra) alakítani!
A következő szint az, hogy 8 bitet használjunk képpontonként, így 256 szürkeárnyalatot tudunk leírni. Ez az eljárás jó minőségű „fekete-fehér” mozgóképet eredményez. A színes mozgóképhez sok rendszer a vörös, a zöld és a kék (RGB) elsődleges színösszetevőket használja úgy, hogy mindegyikhez 8 bitet használ. Azért van lehetőség ennek az ábrázolásnak a használatára, mert bármilyen szín előállítható a megfelelő intenzitású vörös, zöld és kék színek lineáris szuperpozíciójaként. Képpontonként 24 bit használatával a színek száma körülbelül 16 millió, ami több, mint amennyit az emberi szem képes megkülönböztetni.
A színes LCD-monitorokon és -televíziókon minden diszkrét képpont egymáshoz közel elhelyezett vörös, zöld és kék pontrészből, ún. szubpixelekből (subpixel) épül fel. A képkockákat (kereteket) a szubpixelek intenzitásának beállításával jelenítik meg, és a szem összemossa a színösszetevőket.
Gyakori képkockasebességek a (35 mm-es mozifilmtől örökölt) 24 képkocka/s, (az NTSC szabványú Egyesült Államokbeli televízióktól örökölt) 30 képkocka/s, és (a csaknem a világ összes többi részén használt PAL televíziós rendszertől örökölt) 30 képkocka/s. (Az igazán igényesek számára megjegyezzük, hogy az NTSC-rendszerű színes televíziók 29,97 képkocka/s sebességgel működnek. Az eredeti, fekete-fehér rendszer 30 képkocka/s sebességgel működött, de a színek bevezetésekor a mérnököknek további egy bit sávszélességre volt szükségük a jelzésekhez, ezért lecsökkentették a képkockasebességet 29,97 képkocka/s sebességre. A számítógépekhez készített NTSC-videók valóban 30 képkocka/s-t használnak.) A PAL-t az NTSC után találták ki, és valójában 25 képkocka/s sebességet használ. Hogy teljes legyen a történet, Franciaországban, frankofon Afrikában és Kelet-Európában egy harmadik rendszert, a SECAM-ot használják. Kelet-Európában először Kelet-Németországban vezették be, így a kelet-németek nem tudták nézni a nyugat-német (PAL) televíziót. Sok ilyen ország azonban átváltott PAL-ra. Ez a legtöbb, amire a technika és a politika képes.
A sugárzott televízióadások számára valójában nem elég jó a 25 képkocka/s az egyenletes mozgáshoz, ezért a képeket két mezőre (field) bontják, az egyik a páratlan sorszámú pásztázási sorokat tartalmazza, a másik a párosakat. A két (feleakkora felbontású) mezőt egymást követően sugározzák, ami majdnem 60 mező/s (NTSC-nél) vagy pontosan 50 mező/s (PAL-nál) sebességet biztosít. Ez a megjelenítési rendszer sorugrásos megjelenítés (interlacing) néven ismert. A számítógépen történő megjelenítésre szánt mozgóképek progresszívek (progressive), tehát nem használják a sorugrásos megjelenítést, mert a számítógép monitorokhoz kapcsolt grafikus kártyák pufferekkel rendelkeznek, ami lehetővé teszi a CPU számára, hogy másodpercenként 30 alkalommal helyezzen új képet a pufferbe, de a villogás megszüntetése érdekében a grafikus kártyának másodpercenként 50 vagy akár 100 alkalommal kell újrarajzolnia a képernyőt. Az analóg televíziókészülékeknek nincs olyan képkockapufferük, mint a számítógépeknek. Amikor egy gyors mozgásokat tartalmazó sorugrásos videót számítógépen jelenítenek meg, rövid vízszintes vonalak válnak láthatóvá az éles széleknél. Ezt a hatást fésülésnek (combing) nevezik.
Az interneten továbbított videókhoz használt képkockák méretei erősen változóak abból az egyszerű okból kifolyólag, hogy a nagyobb képkockák nagyobb sávszélességet igényelnek, ami nem áll mindig rendelkezésre. A kis felbontású videó 320 × 240 képpontból állhat, a „teljes képernyős” pedig 640 × 480 képpontból. Ezek a méretek megközelítik a régi számítógép-monitorokét és az NTSC-televíziókét. A képarány (aspect ratio) vagy szélesség-magasság arány 4:3, ugyanaz, mint a szabvány televíziónál. A HDTV (High Definition TeleVision – nagy felbontású tv) videók 1280 × 720 képpont felbontással tölthetőek le. Ezeknek a „szélesvásznú” képeknek a képaránya 16:9, hogy jobban megfeleljen a mozifilm 3:2 képarányának. Összehasonlításképpen, egy szabványos DVD-videó általában 720 × 480 képpont felbontású, a Blu-ray lemezeken lévő videók pedig általában HDTV típusúak 1080 × 720 képpont[36] felbontással.
Az interneten a képpontok száma csak a történet egyik része, mert a médialejátszók ugyanazt a képet különféle méretekben képesek megjeleníteni. A videó is csak egy ablak a számítógép képernyőjén, amit fel lehet nagyítani vagy össze lehet zsugorítani. A több képpont szerepe az, hogy a kép minőségét javítani lehet annak érdekében, hogy ne tűnjön elmosódottnak, amikor felnagyítják. Sok monitor azonban még a HDTV-nél is több képpontot tartalmazó képeket (és így mozgóképeket is) képes megjeleníteni.
A digitális videó tárgyalása után már nyilvánvaló kell, hogy legyen: a tömörítés kritikus fontosságú a videók interneten történő továbbítása szempontjából. Még egy 640 × 480 képpontos képkockákkal, képpontonként 24 bit színinformációval és 30 képkocka/s sebességgel működő videó is több mint 200 Mb/s sávszélességet igényel. Ez messze meghaladja azt a sávszélességet, amivel a legtöbb vállalati iroda csatlakozik az internethez, nem beszélve az otthoni felhasználókról, és ez még csak egyetlen videofolyam. Mivel a tömörítetlen videoátvitel – legalábbis a nagy kiterjedésű hálózatokon – teljességgel kizárt, az egyedüli remény az, hogy lehetséges a nagymértékű tömörítés. Szerencsére az utolsó néhány évtized nagy mennyiségű kutatása sok tömörítő technikához és algoritmushoz vezetett, ami lehetségessé tette a mozgókép-továbbítást.
Sok formátumot használnak az interneten történő mozgóképátvitelhez, amelyek közül némelyik egyedi, némelyik szabványos. A legnépszerűbb kódoló a különféle formában megjelenő MPEG. Ez egy nyílt szabvány, melyet az .mpg és .mp4 kiterjesztésű állományokban, valamint más tároló formátumokban is megtalálhatunk. Ebben a szakaszban a videotömörítés végrehajtásának tanulmányozása céljából megtekintjük az MPEG-et. Kezdetben megvizsgáljuk az állóképek tömörítését JPEG-gel. A mozgókép pusztán képek (és hangok) sorozata. A videó tömörítésének egyik módja az összes kép kódolása egymás után. Első megközelítésben az MPEG csupán az összes képkocka JPEG-kódolása, és még néhány további képesség a képek közötti redundancia eltávolításához.
A JPEG- (Joint Photographic Experts Group) szabványt, amely folytonos tónusú állóképek (vagyis fényképek) tömörítésére szolgál, az ITU, az ISO és az IEC felügyelete alatt dolgozó fényképszakértők fejlesztették ki. Széleskörűen használják (keressen .jpg kiterjesztésű állományokat), és gyakran 10:1 vagy jobb tömörítési arányt nyújt természetes képekre.
A JPEG-et az ISO 10918 Nemzetközi Szabvány definiálja. Valójában jobban hasonlít egy bevásárlólistára, mint egy algoritmusra, de a négy meghatározott működési mód közül csak a veszteséges soros mód (lossy sequential mode) bír jelentőséggel ismertetőnk szempontjából. Ezenkívül a JPEG normál használati módjára összpontosítunk, amely a 24 bites RGB-képek tömörítése, és némely apróbb részletet az egyszerűség kedvéért ki fogunk hagyni.
Az algoritmust a 7.44. ábra mutatja. Az első lépés a blokkok előkészítése. Az egyszerűség kedvéért tegyük fel, hogy a JPEG bemenetén egy 640 × 480-as, képpontonként 24 bites RGB kép van, amint a 7.45.(a) ábrán látszik. Az RGB nem a legjobb modell a tömörítéshez. A szem sokkal érzékenyebb a videojelek luminanciájára vagy fényességére, mint azok krominanciájára vagy színességére. Ezért először kiszámítjuk az Y luminanciát és a két, Cb és Cr krominanciát az R, G és B színösszetevőkből. A következő képleteket használjuk a 8 bites értékek meghatározására, melyek 0 és 255 közöttiek lehetnek:
Az Y, Cb és Cr számára külön mátrixokat készítünk. Következőnek az Cb és Cr mátrixokban a négy pixelből álló négyzetes blokkokat átlagoljuk, hogy azok méretét 320 × 240-re csökkentsük. Ez a csökkenés veszteséges, de a szem alig veszi észre a különbséget, mivel a fényességre érzékenyebb, mint a színekre. Viszont ez a teljes adatmennyiséget a felére tömöríti össze. Most mindhárom mátrix elemeiből kivonunk 128-at, hogy a 0 legyen az értelmezési tartomány közepén. Végül minden mátrixot 8 × 8-as blokkokra osztunk fel. Az Y mátrixnak 4800 blokkja lesz, a másik kettőnek egyenként 1200, ahogy a 7.45.(b) ábrán látszik.
A JPEG-kódolás 2. lépésében mind a 7200 blokkra külön-külön alkalmaznunk kell egy DCT-t (Discrete Cosine Transformation – diszkrét koszinusztranszformáció). Minden DCT kimenete egy DCT-együtthatókból álló 8 × 8-as mátrix. A (0, 0) elem a blokk átlaga. A többi elem azt mondja meg, hogy mennyi spektrális teljesítmény van az egyes térbeli frekvenciákban. Rendszerint ezek az elemek az origótól, a (0, 0)-tól való távolsággal arányosan rohamosan csökkennek, ahogy a 7.46. ábra is jelzi.
Amint a DCT kész van, a JPEG-kódolás továbblép a 3. lépésre, amelyet kvantálásnak (quantization) hívnak. Itt a kevésbé fontos DCT-együtthatókat kitöröljük. Ezt a (veszteséges) transzformációt úgy végezzük, hogy a 8 × 8-as DCT-mátrixban minden együtthatót elosztunk egy táblázatból vett súllyal. Ha mindegyik súly értéke 1, akkor a transzformáció semmit sem csinál. Ha viszont a súlyok az origótól távolodva gyorsan csökkennek, akkor a nagyobb térbeli frekvenciák gyorsan kiesnek.
Erre a lépésre látható példa a 7.47. ábrán. Itt a kezdeti DCT-táblázat, a kvantálási táblázat és az eredmény látható, amelyet úgy kapunk, hogy minden DCT-elemet elosztunk a kvantálási táblázat megfelelő elemével. A kvantálási táblázatban található értékek nem képezik a JPEG-szabvány részét. Minden alkalmazásnak rendelkeznie kell egy saját táblázattal, ezáltal lehetséges a veszteség és a tömörítés arányának a szabályozása.
A 4. lépésben lecsökkentjük minden blokk (0, 0) értékét (amelyik a bal felső sarokban van) azáltal, hogy az előző blokk ugyanezen a helyen lévő elemétől való eltérésével helyettesítjük. Mivel ezek az elemek a saját blokkjaik átlagai, várhatóan csak lassan fognak változni, ezáltal a különbségi értékek kis számok lesznek. A többi értéknél nem számolunk eltérést.
Az 5. lépésben sorba rakjuk a 64 elemet és a listára futamhosszkódolást alkalmazunk. A blokk balról jobbra, és azután fentről lefele történő pásztázása nem gyűjtené össze a 0-kat, így egy cikcakkos pásztázási mintát alkalmaznak (lásd 7.48. ábra). Ebben a példában a cikcakk minta 38 egymás utáni 0-t eredményez a mátrix végén. Ezt a sorozatot össze lehet vonni egyetlen számba, mely megmondja, hogy 38 nullánk van. Ezt a módszert futamhosszkódolásnak (run-length encoding) nevezik.
Most már van egy számsorozatunk, ami (a transzformált térben) leírja a képet. A 6. lépés Huffman-kódolja a számokat tárolás vagy átvitel céljából, azaz a gyakorabban előforduló számokhoz rövidebb kódszavakat rendel, mint a ritkábban előforduló számokhoz.
A JPEG bonyolultnak tűnhet, de ez csak azért van, mert tényleg bonyolult. Mégis megéri használni az akár 1:20 arányú tömörítés előnyei miatt. Egy JPEG-kép dekódolásához az algoritmus fordítottját kell lefuttatni. A dekódolás pont olyan hosszú, mint a kódolás, vagyis a JPEG nagyjából szimmetrikus. Ez nem minden tömörítő algoritmusra jellemző, amint azt rövidesen látni fogjuk.
Végre eljutottunk a dolgok lényegéig: az MPEG- (Motion Picture Experts Group – mozgókép szakértői csoport) szabványokig. Bár számos egyedi algoritmus létezik, ezek a szabványok határozzák meg a mozgóképek tömörítésére használt főbb algoritmusokat. Ezek 1993 óta nemzetközi szabványok. Mivel a filmek képeket és hangokat is tartalmaznak, az MPEG mind hangtömörítésre, mind képtömörítésre alkalmas. A hangok és az állóképek tömörítését már tanulmányoztuk, lássuk most tehát a mozgókép-tömörítést.
Az MPEG-1 szabványt (ami magába foglalja az MP3-at is) először 1993-ban jelentették meg, és azóta is széleskörűen használják. Az volt a cél, hogy a videomagnókkal azonos minőségű kimenetet eredményezzen, ami a 40:1 arányú tömörítés mellett körülbelül 1 Mb/s adatsebességet igényelt. Az ilyen mozgókép már alkalmas a széles körű internetes használatra a webhelyeken. Ne aggódjon, ha nem emlékszik a videomagnókra – az MPEG-1-et is a filmek CD-n történő tárolására használták, amikor még léteztek olyanok. Ha nem tudja, hogy mik azok a CD-k, akkor tovább kell lépnünk az MPEG-2-re.
Az 1996-ban megjelent MPEG-2 szabványt műsorszórásra alkalmas minőségű mozgókép tömörítésére tervezték. Mára nagyon elterjedt, minthogy ez képezi a DVD-n lévő kódolt mozgókép (ami elkerülhetetlenül megtalálja útját az internet felé) és a digitális televíziós műsorszórás (DVB) alapját is. A DVD-minőségű mozgóképeket általában 4-8 Mb/s adatsebességgel kódolják.
Az MPEG-4 szabvány két videoformátummal rendelkezik. Az első, 1999-ben megjelent formátum a mozgóképet objektumalapú ábrázolással kódolja. Ez lehetővé teszi a természetes és szintetikus képek, valamint másfajta média összekeverését, például egy időjárási térkép előtt álló meteorológus esetén. Ennek a felépítésnek köszönhetően könnyű elérni, hogy a programok kezelhessék a film adatait. A második, 2003-ban megjelent formátum H.264 vagy AVC (Advanced Video Coding – fejlett mozgóképkódolás) néven ismert. Ennek célja, hogy a mozgóképet a korábbi kódolók adatsebességének felével kódolja azonos minőség mellett, hogy még jobban támogassa a mozgóképek hálózaton keresztül történő átvitelét. Ezt a kódolót használják a HDTV-adásokhoz a legtöbb Blu-ray lemezen.
Ezeknek a szabványoknak sok és változatos részlete van. A későbbi szabványok sokkal több képességgel és kódolási lehetőséggel is rendelkeznek, mint a korábbi szabványok. A részletekbe azonban nem fogunk belemenni. A mozgóképtömörítésben az idők során elért előrelépéseket legnagyobb részben az apró továbbfejlesztgetések eredményezték, és nem a videotömörítésben bekövetkező alapvető változások. Ezért az átfogó koncepciókat fogjuk felvázolni.
Az MPEG a hangot és a mozgóképet is összetömöríti. Mivel a hang- és videokódolók függetlenül dolgoznak, felmerül a kérdés, hogy hogyan lehet a két folyamot a vevőnél szinkronizálni. A megoldás egyetlen óra alkalmazása, amely mindkét kódoló számára rendelkezésére bocsátja a pontos időt tartalmazó időbélyegeket. Ezeket az időbélyegeket tartalmazza a kódolt kimenet, és így eljutnak a vevőig, amely ezeket a hang- és képfolyamok szinkronizálásához használhatja fel.
Az MPEG-videotömörítés a filmekben előforduló kétféle, térbeli és időbeli redundanciát használja ki. A térbeli redundancia kihasználható úgy, hogy egyszerűen minden képet külön kódolnak JPEG-gel. Ezt a megközelítést alkalomszerűen használják, különösen akkor, amikor tetszőleges hozzáférés szükséges minden egyes képkockához, mint a videók szerkesztése közben. Ebben a módban JPEG-szintű tömörítés érhető el.
További tömörítés érhető el azt a tényt kihasználva, hogy az egymás után következő képkockák gyakran majdnem teljesen azonosak. Ez a hatás kisebb, mint elsőre tűnhet, mert sok filmkészítő 3-4 másodpercenként iktat be vágást (hogy mérje egy filmrészlet időtartamát, és számolja a vágásokat). Ennek ellenére még a 75 vagy több, nagymértékben hasonló képkockából álló futamok is nagy csökkentési lehetőséget kínálnak ahhoz képest, hogy az egyes képeket külön-külön JPEG-gel kódoljuk.
Az olyan jelenetekben, ahol a kamera és a háttér áll, és egy vagy több színész lassan mozog, majdnem minden képpont képről képre ugyanaz marad. Itt jól működne az, hogy minden képet kivonunk az előzőből, és a különbségre JPEG-kódolást alkalmazunk. Ám ez az eljárás látványosan csődöt mond olyan jelenetek esetében, ahol a kamera mozog, vagy ráközelít valamire. Valamilyen módon ezeket a mozgásokat kompenzálni kell. Az MPEG pontosan ezt teszi, és ez a lényegi különbség az MPEG és a JPEG között.
Az MPEG-kimenet három fajta képből áll:
I (Intracoded) képek: önállóan tömörített állóképek.
P (Predictive) képek: blokkonkénti eltérés az előző képektől.
B (Bidirectional) képek: az előző és a jövőbeli képek közötti blokkonkénti eltérések.
Az I képek egyszerűen JPEG-kódolt állóképek. Ezek kódolása JPEG vagy más hasonló módszerrel történhet. Három ok miatt érdemes a kimeneti folyamban rendszeres időközönként (például másodpercenként egyszer vagy kétszer) I képeket megjeleníteni. Először is, az MPEG használható többesküldésre is, ahol a nézők tetszés szerint kapcsolódhatnak be az adásba. Ha minden kép függ az előzőktől, egészen az első képig visszamenőleg, bárki, aki az első képet elmulasztotta, nem tudná a további képeket dekódolni. Másodszor, ha valamely kép hibásan érkezne meg, nem lenne lehetséges a további dekódolás: innentől kezdve minden értelmetlen szemét lenne. Harmadszor, I képek nélkül az előre- vagy visszatekerésnél a dekódernek minden képet ki kellene számolnia, amelyen áthalad, hogy tudja annak a képnek teljes értékét, amelyen megáll.
Ezzel ellentétben a P képek a képek közti különbségeket kódolják. Ezek a makroblokkokon (macroblocks) alapulnak, amelyek a luminanciamátrixból például egy 16 × 16 képpontot, a krominanciamátrixokból pedig 8 × 8 képpontot fednek le. Egy makroblokkot úgy kódolnak, hogy az előző képen megkeresik ugyanazt, vagy egy ettől csak kevéssé eltérő makroblokkot.
A 7.49. ábrán látható egy olyan példa, ahol a P képek hasznosak lehetnek. Itt három egymás után következő képet látunk, amelyeknek ugyanaz a hátterük, csupán egy ember helyzete különböző. A hátteret tartalmazó makroblokkok pontosan illeszkedni fognak, de azoknak a makroblokkoknak a pozíciója, amelyek az embert tartalmazzák, valamilyen ismeretlen értékkel eltolódnak, és azokat meg kell keresni.
Az MPEG-szabványok nem határozzák meg, hogy hogyan kell a keresést véghezvinni, milyen messzire kell a keresést kiterjeszteni, és mi számít jó illeszkedésnek. Ezt minden megvalósításnak egyedül kell eldöntenie. Például egy megvalósítás az előző képen az aktuális pozícióban, és attól vízszintesen 
, függőlegesen 
távolságig kereshet illeszkedést. Minden pozícióhoz ki kell számolni a luminanciamátrix illeszkedő elemeinek számát. A legmagasabb pontszámú pozíciót kiálthatnák ki nyertesnek, feltéve, hogy az valamilyen küszöbszint felett van. Egyébként a makroblokkot hiányzónak nevezik. Természetesen sokkal kifinomultabb algoritmusok is lehetségesek.
Ha egy makroblokkot megtalálnak, akkor veszik az aktuális és az előző kép értéke közötti különbséget, luminanciában is és krominanciákban is. Ezeket a különbségmátrixokat azután szokás szerint diszkrét koszinusz-transzformációnak, kvantálásnak, futamhosszkódolásnak és Huffman-kódolásnak vetik alá. A makroblokkra vonatkozó érték ezután a kimeneti folyamban úgy jelenik meg ekkor, mint a mozgásvektor (azaz, hogy mennyit mozdult el a makroblokk előző helyzetéhez képest mindkét irányban), amelyet különbségének kódolása követ. Ha a makroblokk nem szerepel az előző képen, akkor a jelenlegi értékét kódolják úgy, mintha az egy I képben lenne.
Nyilvánvaló, hogy ez az algoritmus nagymértékben aszimmetrikus. Egy megvalósítás akár minden lehetséges pozíciót kipróbálhat az előző képen, ha mindenképpen meg akarja találni az utolsó makroblokkot is, bárhol is legyen az. Ez a megközelítés minimalizálni fogja a kódolt MPEG-folyamot azon az áron, hogy nagyon lassú lesz a kódolás. Ez jó lehet egy filmkönyvtár egyszeri lekódolásához, de a valós idejű videokonferenciához nagyon nem alkalmas.
Hasonlóan, minden megvalósítás maga döntheti el, hogy mit vesz „megtalált” makroblokknak. Ez a szabadság lehetővé teszi a megvalósítás programozóinak, hogy versenyezzenek a minőség és a használt kereső algoritmus területén, de mindig az MPEG-nek megfelelő kimenetet állítanak elő.
Eddig az MPEG dekódolása magától értetődő. Az I képek dekódolása hasonló, mint a JPEG-képek dekódolása. A P képek dekódolásához a dekódernek el kell tárolni az előző képeket, így képes lesz felépíteni a következő képet egy külön pufferben a teljesen kódolt makroblokkok és az előző képek óta történt változásokat tartalmazó makroblokkok alapján. Az új képet makroblokkról makroblokkra rakják össze.
A B képek hasonlók a P képekhez, azzal a különbséggel, hogy ezek lehetővé teszik, hogy a hivatkozott makroblokk a megelőző vagy rákövetkező képekben legyen. Ez a további szabadság javított mozgáskompenzációt tesz lehetővé. Akkor hasznos, amikor például a tárgyak más tárgyak előtt vagy mögött haladnak el. A B képek kódolásához a kódolónak egy képsorozatot kell egyszerre a memóriában tartania: a korábbi képeket, az aktuális, éppen kódolás alatt levő képet és a későbbi képeket. A dekódolás hasonlóképpen bonyolultabb, és némi késleltetést is okoz. Ennek az az oka, hogy egy adott B képet nem lehet dekódolni mindaddig, amíg a rákövetkező képek közül azok, amelyektől függ, nincsenek dekódolva. Tehát annak ellenére, hogy a B képek biztosítják a legjobb tömörítést, nem mindig használják azokat nagyobb bonyolultságuk és a pufferelés igénye miatt.
Az MPEG-szabványok ezeknek a technikáknak sok továbbfejlesztett változatát tartalmazzák a kiváló tömörítési szintek érdekében. Az AVC a mozgókép 50:1 arányt meghaladó mértékű tömörítésére használható, ami a hálózati sávszélességigényt is ugyanekkora mértékben csökkenti. Az AVC-vel kapcsolatos további információért lásd Sullivan és Wiegand [2005] munkáját.
Most térjünk át a hálózati alkalmazásokra! Ezek közül az első az olyan média folyamszerű átvitele, amelyet állományokban tárolnak. Ennek leggyakoribb példája a mozgóképek interneten keresztül történő megtekintése. Ez a VoD (Video on Demand – igény szerinti videonézés) egyik formája. Az igény szerinti videonézés többi formája egy, az internettől független szolgáltató-hálózatot (például kábelhálózat) használ a filmek továbbításához.
A következő szakaszban az élő médiaközvetítést, például az IPTV-műsorszórást és az internetes rádiót vizsgáljuk meg. Ezután a harmadik esetet jelentő valós idejű konferenciát tárgyaljuk. Ilyen például az IP-hálózaton keresztül történő beszédátvitel és a Skype-on lebonyolított videokonferencia. Ez a három eset egyre szigorúbb követelményeket támaszt a hangnak és mozgóképnek hálózaton keresztül történő továbbításával kapcsolatban, mert egyre növekvő figyelmet kell szentelnünk a késleltetésnek és a dzsitternek.
Az internet tele van zenei és videooldalakkal, amelyek tárolt médiaállományokat továbbítanak. Valójában a legegyszerűbb módja a tárolt média kezelésének az, ha nem folyamszerűen továbbítjuk. Képzeljük el, hogy létre akarunk hozni egy online videokölcsönző oldalt, hogy versenyre keljen az Apple iTunes-szal! Egy szokásos webhely lehetővé fogja tenni a felhasználóknak, hogy letöltsék, majd megnézzék a mozgóképeket (természetesen csak az után, hogy fizettek). A lépések sorozatát a 7.50. ábra mutatja. Ki fogjuk silabizálni ezeket, hogy összevethessük a következő példával.
A böngésző akkor lép akcióba, amikor a felhasználó rákattint egy filmre. Az 1. lépésben elküld egy, a filmre vonatkozó HTTP-kérést annak a webszervernek, amelyre a film hiperhivatkozása mutat. A 2. lépésben a kiszolgáló előveszi a filmet (ami csak egy MP4, vagy valamilyen más formátumban lévő állomány), és visszaküldi azt a böngészőnek. A MIME-típus, például video/mp4 felhasználásával a böngésző meghatározza, hogy hogyan kellene megjeleníteni az állományt. Ebben az esetben egy segédalkalmazásként feltüntetett médialejátszó szolgál erre a célra, de beépülő modul is lehetne. A 3. lépésben a böngésző az egész filmet kimenti egy lemezen elhelyezett ideiglenes állományba. Ezután elindítja a médialejátszót, átadva neki az ideiglenes állomány nevét. Végül a 4. lépésben a médialejátszó elkezdi beolvasni az állományt, és lejátszani a filmet.
Ez a megközelítés elvileg teljesen helyes. Le fogja játszani a filmet. Nincsenek megoldandó problémák sem a valós idejű hálózati átvitellel kapcsolatban, mert a letöltés egy egyszerű állományletöltés. Az egyetlen probléma az, hogy az egész filmet át kell vinni a hálózaton, mielőtt a lejátszás megkezdődhet. A legtöbb ügyfél nem kíván egy órát várni egy igény szerinti videonézésre. Ez a modell még a hangok számára is problémás lehet. Képzeljen el egy dalba történő belehallgatást az album megvásárlása előtt! Ha a dal 4 MB méretű, ami egy MP3 dal jellemző mérete, és a széles sávú kapcsolat sebessége 1 Mb/s, a felhasználót fél perc csend fogadja, mielőtt a belehallgatás elkezdődik. Ez a modell nem alkalmas arra, hogy túl sok albumot eladjanak.
A webhelyek a 7.51. ábrán látható felépítést alkalmazhatják annak érdekében, hogy a böngészők működésének megváltoztatása nélkül megkerüljék a problémát. A filmre hivatkozó oldal nem a tényleges filmállomány, hanem egy úgynevezett metaállomány (metafile), azaz egy nagyon rövid állomány, ami mindössze megnevezi az adott filmet (és valószínűleg más kulcsleírókat is tartalmaz). Egy egyszerű metaállomány lehet akár egyetlen ASCII-szöveg is, mint ez itt:
rtsp://joes-movie-server/movie-0025.mp4
A böngésző a szokásos módon megkapja az egysoros állományt az 1. és 2. lépésekben. Ezután elindítja a médialejátszót és átadja neki az egysoros állományt a 3. lépésben, ahogy megszokhattuk. A médialejátszó beolvassa a metafájlt és látja azt az URL-t, ahonnan a filmet meg kell kapnia. Kapcsolatba lép a joes-movie-server-rel, és elkéri a filmet a 4. lépésben. Ezután az 5. lépésben a médiakiszolgáló a filmet folyamszerűen továbbítja a médialejátszónak. Ennek a kialakításnak az az előnye, hogy a médialejátszó gyorsan elindul egy nagyon rövid metafájl letöltését követően. Miután ez megtörtént, a böngésző többé nem részese a folyamatnak. A médiát a médiakiszolgáló közvetlenül a médialejátszóhoz küldi, így az a teljes film letöltése előtt elkezdheti a film megjelenítését.
Két kiszolgálót látunk a 7.51. ábrán, mert a metafájlban megnevezett kiszolgáló gyakran nem azonos a webszerverrel. Valójában többnyire még csak nem is HTTP-kiszolgáló, hanem egy specializált médiakiszolgáló. Ebben a példában a médiakiszolgáló RTSP-t (Real Time Streaming Protocol – valós idejű adatfolyam protokoll) használ, ahogy azt az rtsp sémanév is jelzi.
A médialejátszónak négy főbb feladata van:
Kezelni a felhasználói csatlakozó felületet.
Kezelni az átviteli hibákat.
Kibontani (expandálni) a tartalmat.
Kiküszöbölni a dzsittert.
Manapság a legtöbb médialejátszónak cicomás felhasználói csatlakozó felülete van, ami néha a sztereo hifiberendezéseket utánozza, gombokkal, tekerőkkel, csúszkákkal és vizuális kijelzőkkel. Az ilyen lejátszóknál gyakran megtalálható a cserélhető előlap, az ún. skin, amit a felhasználó maga rakhat rá a lejátszóra. A médialejátszónak mindezt kezelnie kell, és együtt kell működnie a felhasználóval.
A többi feladat a hálózati protokollokkal kapcsolatos, illetve azoktól függ. Sorjában mindegyiken végig fogunk menni, kezdve az átviteli hibák kezelésével. A hibák kezelésének módja attól függ, hogy a média továbbításához olyan TCP-alapú protokollt használnak-e, mint a HTTP, vagy olyan UDP-alapút, mint az RTP. A gyakorlatban mindkettő használatos. Ha TCP-alapú szállítást használnak, akkor nincs hiba, amit a médialejátszó kijavíthatna, mert a TCP már megbízható szállítást biztosít. Ez könnyű módja a hibák kezelésének, legalábbis a médialejátszó számára, de ez a következő lépésben bonyolulttá teszi a dzsitter eltávolítását.
Másik lehetőségként az adatok mozgatásához olyan UDP-alapú átvitelt használhatnak, mint az RTP. Ezt a 6. fejezetben tanulmányoztuk. Ezeknél a protokolloknál nincsenek újraküldések. Így a torlódás következtében történő csomagvesztés vagy az átviteli hibák azt fogják eredményezni, hogy a média egy része nem érkezik meg. Ennek a problémának a megoldása a médialejátszóra hárul.
Lássuk, milyen nehézséggel állunk szemben! A csomagvesztés gond, mert az ügyfelek nem kedvelik a hosszú kimaradásokat kedvenc dalaikban és filmjeikben. Ez azonban nem akkora probléma, mint egy hagyományos állomány továbbítása közben történt csomagvesztés, mert a média egy kis darabjának elvesztése nem feltétlenül rontja le a felhasználónak tartott megjelenítést. Mozgóképek esetén a felhasználó valószínűleg észre sem veszi, ha valamelyik másodpercben 25 új képkocka helyett véletlenül csak 24 új képkocka van. A hangoknál a lejátszás során előforduló rövid kimaradásokat el lehet fedni az időben közeli hangokkal. A felhasználó valószínűleg nem veszi észre ezt a helyettesítést, hacsak nem kifejezetten erre figyel.
A fenti érvelés kulcsa azonban az, hogy a kimaradások nagyon rövidek. A hálózati torlódás vagy egy átviteli hiba általában egy egész csomag elvesztését okozza, és a csomagok gyakran kisebb löketekben vesznek el. Két stratégia használható a csomagvesztésnek a médiára gyakorolt hatásának csökkentésére: a FEC és az összefésülés. A következőkben mindegyiket ismertetjük.
Az FEC (Forward Error Correction – előre irányuló hibajavítás) egyszerűen annak a hibajavító kódolásnak az alkalmazási szinten történő felhasználása, amit a 3. fejezetben tanulmányoztunk. Erre egy példa a csomagok közötti paritásképzés [Shacham és McKenny, 1990]. Minden négy elküldött adatcsomaghoz létrehoznak és elküldenek egy ötödik, ún. paritáscsomagot (parity packet). Ez látszik a 7.52. ábrán, az A, B, C és D csomagokkal. A P paritáscsomag redundáns biteket tartalmaz, amelyek a négy adatcsomagban található bitek paritásai vagy „kizáró-vagy” (kizáró vagy) összegei. Remélhetőleg az öt csomagból álló csoportok nagy részének minden csomagja megérkezik. Amikor ez megtörténik, a vevő a paritáscsomagot egyszerűen figyelmen kívül hagyja. Akkor sincs baj, ha csak a paritáscsomag hiányzik.
Néha azonban egy adatcsomag elveszhet az átvitel során, mint a B csomag a 7.52. ábrán. A médialejátszó csak három adatcsomagot, az A-t, C-t és D-t, továbbá a P paritáscsomagot kapja meg. Az elveszett adatcsomagban lévő bitek helyreállíthatók a paritásbitek segítségével. Hogy konkrétak legyünk, a „+” jelet a „kizáró-vagy” vagy modulo 2 összeadás jelölésére használva, a B csomag helyreállítható a következőképpen: 
, felhasználva a „kizáró-vagy” tulajdonságait (például 
).
Az FEC képes csökkenteni a médialejátszó által észlelt csomagvesztési szintet néhány elvesztett csomag javításával, de ez csak egy bizonyos szintig működik. Ha az ötelemű csoportból két csomag elveszik, semmit sem tudunk tenni az adatok visszaszerzése érdekében. Az FEC másik, figyelembe veendő tulajdonsága az ár, amit ennek a védelemnek az eléréséért kell fizetni. Minden négy csomagból öt lett, így a média sávszélesség-igénye 25%-kal nagyobb. A dekódolás késleltetési ideje is megnőtt, mert szükségünk lehet rá, hogy várjunk, amíg a paritáscsomag megérkezik, mielőtt helyreállíthatnánk az előtte érkezett adatcsomagot.
Van egy okos trükk is a fenti technikában. A 3. fejezetben azt írtuk a paritásról, hogy hibadetektálást biztosít. Mi itt hibajavítást végzünk. Hogyan képes elvégezni mindkét feladatot? A válasz az, hogy ebben az esetben ismert, hogy melyik csomag veszett el. Az elveszett adatot törlődésnek (erasure) nevezik. A 3. fejezetben, amikor megvizsgáltunk egy keretet, ami néhány bithibával érkezett, nem tudtuk, melyik bit hibásodott meg. Ennek az esetnek a kezelése nehezebb, mint a törlődéseké. Tehát a paritásképzés törlődések esetén hibajavítást biztosít, törlődések hiányában csak hibajelzést. Hamarosan látni fogjuk a paritásnak egy másik, váratlan előnyét, amikor elérünk a többesküldést tartalmazó forgatókönyvhöz.
A második stratégiát összefésülésnek (interleaving) nevezik. Ez a megközelítés azon alapul, hogy átvitel előtt a média sorrendjét összekeverik vagy összefésülik, vételnél pedig a sorrendet visszaállítják vagy kifésülik. Ily módon, ha egy csomag (vagy csomagok lökete) elvész, a sorba rendezés során a veszteség időben szét fog szóródni. Nem eredményez egyetlen, nagy kiesést a média lejátszásakor. Egy csomag tartalmazhat például 220 sztereo mintát, mindegyikben két darab 16 bites számmal, ami rendszerint 5 ms hosszú zenének felel meg. Ha a mintákat sorban küldenék el, az elvesztett csomag 5 ms hosszú kiesést jelentene a zenében. Ehelyett a mintákat úgy továbbítják, ahogyan az a 7.53. ábrán látható. Egy 10 ms-os intervallum minden páros mintáját elküldik egy csomagban, amelyet az összes páratlan mintát tartalmazó követ. A 3-as csomag elvesztése most nem 5 ms kimaradást jelent a zenében, hanem minden második minta elvesztését 10 ms-on keresztül. Ez a veszteség könnyen kezelhető, ha a médialejátszó az előző és a következő minták felhasználásával interpolálja a hiányzó értékeket. Az eredmény: kisebb átmeneti felbontás 10 ms-on keresztül, és nem egy észrevehető időbeli kimaradás a médiában.
7.53. ábra - Amikor a csomagok váltakozó mintákat szállítanak, a csomagvesztés csak átmeneti felbontáscsökkenést okoz és nem időbeli kimaradást
Ez az összefésülési séma csak tömörítetlen mintavétel esetén működik. Az összefésülés azonban (rövid időn keresztül, és nem egyedi mintákkal) tömörítés után is alkalmazható mindaddig, amíg valahogyan meg lehet találni a minta határait a tömörített folyamban. Az RFC 3119 egy olyan sémát ír le, amely tömörített hanggal működik.
Az összefésülés, amikor használható, egy jó megoldás, mert nincs szüksége nagyobb sávszélességre, mint ahogy azt az FEC-nél láttuk. Az összefésülés azonban, akárcsak az FEC, növeli a késleltetést, mert meg kell várni egy csomagokból álló csoport megérkezését (azért, hogy ki lehessen fésülni).
A médialejátszó harmadik feladata a tömörített tartalom kibontása (decompressing). Ez ugyan nagyon számításigényes, de eléggé magától értetődő feladat. A nehéz kérdés az, hogy hogyan dekódoljuk a médiát, ha a hálózati protokoll nem javítja ki az átviteli hibákat. Sok tömörítő sémában a későbbi adatot nem lehet kibontani, amíg a korábbi adat nincs kibontva, mert a későbbi adatot a korábbi adatra vonatkozóan kódolják. Egy UDP-alapú átvitel esetén előfordulhat csomagvesztés. Tehát a kódolási folyamatot úgy kell megtervezni, hogy a dekódolást a csomagvesztés ellenére is lehetővé tegye. E követelmény miatt használ az MPEG I, P és B képeket. Minden I kép a többi képtől függetlenül dekódolható, így bármely korábbi kép elvesztése után is helyre tud állni.
A negyedik teendő a minden valós idejű rendszer rémének tekintett dzsitternek a kiküszöbölése. Az általános módszer, amit a 6.4.3. szakaszban ismertettünk, egy lejátszási puffer használata. Minden folyamszerű átvitelt alkalmazó rendszer úgy indul, hogy körülbelül 5-10 másodpercnyi médiát pufferel, mielőtt a lejátszást megkezdené, amint azt a 7.54. ábra is mutatja. A lejátszáskor a média szabályosan folyik ki a pufferből, ezért a hang tiszta és a mozgókép egyenletes. A kezdeti késleltetés megadja az esélyt a puffernek arra, hogy megteljen az alsó vízjelig (low-water mark). Az elépzelés az, hogy az adatoknak innen kezdve eléggé szabályosan kell érkezniük ahhoz, hogy a puffer soha ne ürüljön ki teljesen. Ha ez megtörténne, a médialejátszás leállna. A pufferelés értelme az, hogy ha az adatok a torlódás miatt időnként lassan érkeznek meg, akkor a pufferben lévő média lehetővé teszi a lejátszás normális folytatását az új médiaadatok megérkezéséig és a puffer újbóli feltöltéséig.
7.54. ábra - A médialejátszó puffereli a médiakiszolgálótól érkező bemenetet, és a lejátszás nem közvetlenül a hálózatról, hanem a pufferből történik
Az, hogy mekkora pufferre van szükség és a médiakiszolgáló milyen gyorsan küldi a puffer feltöltéséhez az adatokat, a hálózati protokollokon múlik. Számos lehetőség kínálkozik. A tervezésnél az a legfontosabb tényező, hogy UDP-alapú vagy TCP-alapú továbbítást alkalmaznak.
Tételezzük fel, hogy olyan UDP-alapú továbbítást alkalmaznak, mint az RTP. Továbbá tételezzük fel azt is, hogy elegendő sávszélesség áll rendelkezésre ahhoz, hogy a csomagokat kis csomagvesztéssel és kis egyéb hálózati forgalom mellett küldik el a médiakiszolgálótól a médialejátszóhoz. Ebben az esetben a csomagokat pontosan akkora sebességgel lehet küldeni, amekkora a média lejátszási sebessége. Minden csomag áthalad a hálózaton, és a terjedési késleltetés után, nagyjából pont akkor érkezik meg a médialejátszóhoz, amikor annak a médiát le kell játszania. Nagyon kis puffer szükséges, mivel a késleltetés nem változik. Ha összefésülést vagy FEC-t használnak, nagyobb pufferre van szükség, hogy legalább azok a csomagok elférjenek, amelyek az összefésülést vagy FEC-t végrehajtják. Ez azonban csak kissé növeli a puffer méretét.
Sajnos ez a forgatókönyv két szempontból is légbőlkapott. Először is, a hálózati utak sávszélessége változó, így a médiakiszolgáló számára általában nem világos, hogy elegendő lesz-e a sávszélesség, mielőtt elkezdené a médiát folyamszerűen továbbítani. Egy egyszerű megoldás a média többféle felbontásban történő kódolása, és annak lehetővé tétele, hogy minden felhasználó olyan felbontást válasszon, amelyet az internetkapcsolata lehetővé tesz. Gyakran csak két szint létezik: csúcsminőség, mondjuk 1,5 Mb/s vagy nagyobb sebességgel kódolva, és gyenge minőség, mondjuk 512 kb/s vagy kisebb sebességgel kódolva.
Másodszor, mindig lesz egy kis dzsitter vagy ingadozás a médiamintáknak a hálózaton történő áthaladásának idejében. Ez a dzsitter két forrásból fakad. Gyakran van érzékelhető mennyiségű versengő forgalom a hálózaton – ezek egy részét maguk a több feladatot egyszerre végző felhasználók idézik elő a világháló böngészésével, miközben látszólag a folyamszerűen átvitt filmet nézik. Ez a forgalomban lüktetéseket okoz a média megérkezésekor. Továbbá, bennünket a videó képkockáinak és a hangmintáknak a megérkezése érdekel, nem a csomagok megérkezése. Tömörítés esetén különösen a videó képei lehetnek nagyobbak vagy kisebbek, a tartalomtól függően. Egy akciósorozat kódolásához általában több bitre van szükség, mint egy békés tájképéhez. Ha a hálózati sávszélesség állandó, az egységnyi idő alatt szállított média mennyisége változni fog. Minél nagyobb az ezekből a forrásokból származó dzsitter, vagyis a késleltetés ingadozása, annál magasabbra kell helyezni a puffer alsó vízjelét az alulcsordulás elkerülése érdekében.
Most képzeljük el, hogy olyan TCP-alapú átvitelt használnak a média elküldésére, mint a HTTP. A TCP azáltal, hogy újraküldéseket végez, és megvárja, amíg a csomagok a megfelelő sorrendben megérkeznek, meglehet, hogy jelentősen megnöveli a médialejátszó által megfigyelt dzsittert. Az eredmény az, hogy nagyobb pufferre és magasabb felső vízjelre van szükség. Van azonban egy előnye is. A TCP olyan gyorsan küldi az adatokat, ahogy azokat a hálózat szállítani képes. A média néha késhet, ha az elveszett adatokat javítani kell. Az idő nagy részében azonban a hálózat képes gyorsabban szállítani a médiát, mint ahogyan a lejátszó felhasználja azt. Ezekben az időszakokban a puffer töltődni fog, és megelőzi a jövőbeli alulcsordulásokat. Ha a hálózat jelentősen gyorsabb, mint az átlagos médiasebesség, amint ez gyakran megesik, akkor a puffer az indítást követően gyorsan feltöltődik úgy, hogy annak kiürülésétől egyhamar nem kell tartani.
TCP-t vagy UDP-t és akkora átviteli sebességet használva, amely meghaladja a lejátszási sebességet, felmerül az a kérdés, hogy a médialejátszó és a médiakiszolgáló a lejátszási ponttól mekkora távolságig hajlandó előrefutni. Gyakran az egész állományt akarják letölteni.
A lejátszási ponttól messzire előremenni azonban sok olyan munka elvégzését jelenti, amire még nincs szükség, amely jelentős tárterületet igényelhet, és amely egyáltalán nem szükséges a puffer alulcsordulásának kivédéséhez. Ennek elkerülésére az a megoldás, hogy a médialejátszó egy felső vízjelet (high-water mark) definiál a pufferben. A kiszolgáló alapvetően továbbra is csak ontja az adatokat egészen addig, amíg a puffer telítettsége el nem éri a felső vízjelet. Ekkor a médialejátszó felszólítja, hogy tartson szünetet. Mivel az adatok ezután egy ideig még tovább özönlenek, amíg a kiszolgáló meg nem kapja a szünetre vonatkozó kérést, ezért a felső vízjel és a puffer vége közt a távolságnak nagyobbnak kell lennie, mint a hálózatban a sávszélesség és a késleltetés szorzata. Miután a kiszolgáló leállt, a puffer elkezd ürülni. Amikor a szintje eléri az alsó vízjelet, a médialejátszó felszólítja a médiakiszolgálót, hogy kezdjen el újból adni. Az alulcsordulás elkerülése érdekében az alsó vízjelnek figyelembe kell vennie a hálózat sávszélesség-késleltetés szorzatát, amikor a médialejátszó felszólítja a médiakiszolgálót a média küldésének folytatására.
A média áramlásának elindítását és leállítását a médialejátszónak a távolból kell tudnia vezérelni – pontosan erre való az RTSP. Ezt az RFC 2326 definiálja, mely egy olyan eljárást biztosít, amellyel a lejátszó vezérelheti a kiszolgálót. A médiafolyam elindításán és leállításán kívül képes egy adott pozíció hátra- vagy előrekeresésére, meghatározott intervallumok lejátszására és gyorsabb vagy lassabb lejátszásra. Noha az RTSP nem gondoskodik az adatfolyamról, ez gyakran az RTP az UDP felett, vagy az RTP a TCP és HTTP felett.
Az RTSP fontosabb parancsait a 7.55. ábra sorolja fel. Egyszerű szöveges formátumúak, mint a HTTP-üzenetek, és általában TCP felett továbbítják ezeket. Az RTSP UDP felett is futhat, mivel minden parancsot nyugtázás követ (és így újra lehet küldeni, ha a nyugtázás elmaradt).
Annak ellenére, hogy a TCP nem tűnik alkalmasnak a valós idejű forgalom megvalósítására, a gyakorlatban gyakran használják. Ennek legfőbb oka az, hogy könnyebben képes átjutni a tűzfalakon, mint az UDP, különösen akkor, ha a HTTP portjával használják. Sok rendszergazda úgy állítja be a tűzfalakat, hogy azok megvédjék a hálózatukat a nem szívesen látott látogatóktól. Csaknem mindig engedélyezik egy távoli gép 80-as portjáról érkező TCP-összeköttetések áthaladását a HTTP és a webes forgalom számára. Ennek a portnak a blokkolása hamar boldogtalan kempingezőket eredményez. A többi port nagy része azonban blokkolva van, beleértve egyebek mellett az RTSP-t és az RTP-t is, amelyek többek között az 554-es és 5004-es portokat használják. Ezért a legkönnyeb módja annak, hogy a folyamszerűen továbbított médiát a tűzfalon keresztül megkapjunk, ha a webhely úgy tesz, mintha – legalábbis a tűzfal felől nézve – egy HTTP-kiszolgáló lenne, ami a szokásos HTTP-választ küldi.
A TCP-nek van néhány további előnye is. Mivel a TCP megbízható összeköttetést biztosít, a média teljes példányát adja az ügyfélnek. Ez megkönnyíti a felhasználó dolgát, ha egy korábban megtekintett lejátszási pontra kíván visszalépni, mivel nem kell az elveszett adatok miatt aggódnia. Végül, a TCP annyit fog pufferelni a médiából, amennyit csak lehet, és olyan gyorsan, ahogyan az csak lehetséges. Amikor a puffer olcsó (akkor olcsó, amikor a lemezt használják tárolásra), a médialejátszó letöltheti a médiát, miközben a felhasználó megtekinti azt. Amikor a letöltés megtörtént, a felhasználó megszakítás nélkül nézheti, még akkor is, ha megszakadt az összeköttetése. Ez a tulajdonság hasznos a mobiltelefonok számára, mert az összeköttetés gyorsan változhat mozgás közben.
A TCP hátránya a plusz indítási késleltetés (a TCP-összeköttetés létesítése miatt), és a magasabb alsó vízjel. Ez azonban ritkán okoz problémát, amíg a hálózati sávszélesség nagymértékben meghaladja a média sebességét.
Nem csak a rögzített mozgóképek örvendenek hihetetlen népszerűségnek a világhálón, az élő média folyamszerű továbbítása, közvetítése[37] is nagyon népszerű. Amint lehetővé vált a hang- és videoanyagok folyamszerű továbbítása az interneten, a kereskedelmi rádió- és televízióállomásoknak az az ötletük támadt, hogy adásukat az éter mellett az interneten is közvetíteni fogják. Nem sokkal később az egyetemi állomások is elkezdték kirakni műsorukat az internetre. Végül már egyes egyetemi hallgatók is elkezdték saját műsorukat sugározni az interneten.
Manapság az emberek és mindenféle méretű vállalatok is közvetítenek élő hangot és mozgóképet. Ez a terület az innováció melegágya a technika és a szabványok fejlődése miatt. A nagyobb televízióállomások az élő média folyamszerű továbbítását online jelenlétük megmutatására használják. Ezt IPTV-nek (IP TeleVision – IP-televízió) nevezik. Élő közvetítéseket rádióadók – például a BBC – adásának sugárzására is használnak. Ezt nevezik internetes rádiónak (Internet radio). Mind az IPTV, mind az internetes rádió olyan eseményekkel érik el a közönséget, melyek a divatbemutatóktól a futball-világkupáig és a Melbourne-i krikettpályáról közvetített élő nemzetközi krikettmérkőzésekig terjednek. A kábelszolgáltatók az IP-hálózaton keresztül történő élő közvetítés technikáját használják saját műsorszóró rendszerük kiépítéséhez. Széles körben alkalmazzák alacsony költségvetésű produkciókhoz, a pornótól a természetfilmekig. A mai technikával gyakorlatilag bárki gyorsan és alacsony költséggel indíthat élő közvetítést.
Az élő média folyamszerű továbbításának egyik megközelítése az, hogy a programokat lemezre mentik. A nézők csatlakozhatnak a kiszolgáló archívumaihoz, feliratkozhatnak bármelyik programra, és letölthetik azt meghallgatásra. A podcast[38] egy ilyen módon letöltött epizód. Időzített események esetén az is lehetséges, hogy a tartalmat közvetlenül az élő közvetítés után tárolják, és az archívum – mondjuk – csak fél órával, vagy még annyival sem lesz lemaradva az élő adástól.
Ez a megközelítés valójában pontosan megegyezik az imént tárgyalt folyamszerű médiaközvetítéssel. Egyszerűen megvalósítható, az összes eddig tárgyalt módszer használható hozzá, és a nézők az archívum teljes műsorválasztékából válogathatnak.
Egy ettől eltérő megoldás az élő internetes közvetítés. A nézők beállítanak egy éppen közvetített médiafolyamot, épp úgy, mintha bekapcsolnák a televíziót. A médialejátszók azonban olyan további képességekkel rendelkeznek, amelyek lehetővé teszik a felhasználó számára a lejátszás szüneteltetését vagy visszatekerését. Az élő média közvetítése tovább folytatódik, és a lejátszó továbbra is pufferelni fogja azt, ameddig erre a felhasználó kész. A böngésző szempontjából ez pontosan úgy néz ki, mint a tárolt média közvetítésének esete. A lejátszónak nem számít, hogy a tartalom egy állományból származik, vagy élőben közvetítik, és ezt a lejátszó általában nem is képes megmondani (kivéve, hogy egy élő közvetítésben nem lehet előre ugrani). Adottak a működés hasonlóságai, a korábban megtárgyaltak nagy része továbbra is használható, de van néhány jelentős különbség is.
Fontos, hogy az ügyfél oldalán a dzsitter kisimításához továbbra is szükség van pufferelésre. Valójában az élő közvetítésekhez gyakran nagyobb méretű pufferre van szükség (függetlenül attól a megfontolástól, hogy a felhasználó szüneteltetheti a lejátszást). Amikor egy állomány az, amelynek a tartalmát közvetítik, a média nagyobb sebességgel is érkezhet, mint a lejátszás sebessége. Így a puffer gyorsan megtelik, ami kiegyenlíti a hálózati dzsittert (és a lejátszó megállítja a folyamot, ha nem kíván több adatot pufferelni). Ezzel ellentétben az élő médiaközvetítést mindig pontosan akkora sebességgel továbbítják, mint amekkora sebességgel előállították, ami egyben megegyezik a lejátszás sebességével is. Ennél gyorsabban nem lehet elküldeni. Következésképpen a puffernek elég nagynak kell lennie a hálózati dzsitter teljes tartományának kezeléséhez. A gyakorlatban 10-15 másodperc indulási késleltetés általában megfelelő, tehát ez nem egy komoly probléma.
Egy további fontos különbség az, hogy az élőben közvetített eseményeknél ugyanazt a tartalmat rendszerint több százan vagy ezren nézik egyszerre. Ilyen körülmények között az élő közvetítések megvalósítására a természetes megoldás a többesküldés használata. Ez nem azonos a tárolt média közvetítésének esetével, mert ott a felhasználók általában minden pillanatban különböző tartalmakat kérnek le. A több felhasználóhoz közvetített média ekkor sok független közvetítési munkamenetből áll, amelyek történetesen egyszerre zajlanak.
A többesküldést alkalmazó közvetítés sémája a következőképpen működik. A kiszolgáló minden médiacsomagot egyszer küld el IP-többesküldés segítségével egy csoportcímre. A hálózat a csoport minden tagjához eljuttatja a csomag egy másolati példányát. Minden olyan ügyfél, amelyik meg akarja kapni a folyamot, korábban csatlakozott a csoporthoz. Az ügyfelek ezt az IGMP segítségével teszik meg ahelyett, hogy RTSP-üzenetet küldenének a médiakiszolgálónak. Ennek az az oka, hogy a médiakiszolgáló már az élő folyamot küldi (de nem az első felhasználó csatlakozása előtt). Arról gondoskodni kell, hogy a folyamot mindenki helyileg megkapja.
Mivel a többesküldés „egy-a-többhöz” típusú kézbesítési szolgáltatás, a médiát az UDP szállítási protokoll felett RTP-csomagok hordozzák. TCP csak egyetlen küldő és egyetlen vevő között működik. Mivel az UDP nem nyújt megbízható szolgáltatást, néhány csomag elveszhet. A médiaveszteség elfogadható szintre csökkentéséhez FEC-t vagy összefésülést használhatunk, ahogy azt már korábban is megtettük.
FEC használata esetén a többesküldésnél előnyös együttműködés van, ami a 7.56. ábra paritásképzést bemutató példáján látható. Ha a csomagokat többesküldéssel továbbítják, a különböző ügyfelek különböző csomagokat veszíthetnek el. Például az 1. ügyfél a B csomagot veszítette el, a 2. ügyfél a P paritáscsomagot, a 3. ügyfél a D-t, a 4. ügyfél pedig egyetlen csomagot sem vesztett el. Annak ellenére azonban, hogy az ügyfelek három különböző csomagot vesztettek el, ebben a példában minden egyes ügyfél képes visszaállítani az összes adatcsomagot. Mindössze arra van szükség, hogy egyetlen ügyfél se veszítsen el egynél több csomagot. Bármelyik is legyen az elvesztett csomag, paritás számításával visszaállítható. Nonnenmacher és mások [1997] munkája leírja, hogyan lehet ezt az elképzelést a megbízhatóság fokozására használni.
Egy sok ügyfelet kiszolgáló szerver számára egyértelműen a média RTP- és UDP-csomagokkal történő többesküldése a leghatékonyabb működési mód. Máskülönben a kiszolgálónak N ügyfél esetén N folyamot kell továbbítania, amely a kiszolgálónál nagyon nagy hálózati sávszélességet igényel a nagy folyamú események számára.
Talán meglepi önt, amikor azt tanulja, hogy az internet a gyakorlatban nem így működik. Ami általában történik, az az, hogy minden egyes felhasználó külön TCP-összeköttetést hoz létre a kiszolgálóval, és a média ezen az összeköttetésen keresztül folyamszerűen továbbítódik. Az ügyfél számára ez ugyanolyan, mint a tárolt média közvetítése. És ugyanúgy, mint a tárolt média közvetítésének esetében, számos oka van ennek a látszólag rossz választásnak.
Az első ok az, hogy az IP-többesküldés nem érhető el széles körben az interneten. Néhány internetszolgáltató (ISP) és hálózat belül támogatja, de a hálózatok határain át általában ez a szolgáltatás nem elérhető, pedig szükség lenne erre a nagy távolságra történő közvetítésekhez. A további okok azok az előnyök, amelyekkel a TCP az UDP-vel szemben rendelkezik, ahogyan azokat korábban már megtárgyaltuk. A TCP-vel megvalósított közvetítés csaknem minden ügyfelet elér az interneten, különösen akkor, amikor HTTP-nek álcázzák a tűzfalakon történő átjutás miatt, a média megbízható továbbítása pedig lehetővé teszi a felhasználók számára, hogy könnyen visszatekerjenek.
Van azonban egy fontos eset, amelyben az UDP és a többesküldés felhasználható a médiaközvetítéshez: ez a szolgáltató hálózatán belüli közvetítés. Például egy kábeltársaság dönthet úgy, hogy a hagyományos videoközvetítés helyett a tv-programokat IP-technikával juttatja el az ügyfelek beltéri egységeihez (set-top box). A video-műsorszórásra használt IP-technikát általában IPTV-nek nevezik, amint azt feljebb megtárgyaltuk. Mivel a kábeltársaság teljesen ellenőrzése alatt tartja a saját hálózatát, kiépítheti azt úgy, hogy támogassa az IP-többesküldést és legyen elegendő sávszélessége az UDP-alapú szétosztáshoz. Mindez az ügyfél számára láthatatlan, mivel az IP-technika csak a szolgáltató saját hálózatán (walled garden – bekerített kert) belül létezik.[39] A szolgáltatás szempontjából ez pontosan úgy néz ki, mint egy kábeltévé, de a szolgáltatás mögött IP áll, a beltéri egység egy UDP-t használó számítógép, a tévé pedig egyszerűen csak egy számítógéphez csatlakoztatott monitor.
Visszatérve az internet esetéhez, a TCP felett megvalósított élő közvetítés hátránya az, hogy a kiszolgálónak a média egymástól független másolatait kell elküldenie minden egyes ügyfélnek. Ez nem túl sok ügyfél esetén, különösen hangközvetítésnél, megvalósítható. A trükk az, hogy a kiszolgálót jó internetkapcsolatot biztosító helyre kell elhelyezni, ahol elegendő a sávszélesség. Ez általában egy adatközpontban lévő kiszolgáló bérlését jelenti egy tárhelyszolgáltatótól, és nem egy otthoni kiszolgáló csak széles sávú kapcsolattal történő használatát. A tárhelypiacon nagy a verseny, így ez nem feltétlenül költséges.
Valójában bárki, még egy egyetemista is könnyen felállít és működtet egy folyamszerűen továbbító médiakiszolgálót, például egy internetes rádióállomást. Ennek az állomásnak a főbb alkotóelemei a 7.57. ábrán láthatók. Az állomás lelke egy hagyományos PC tisztességes hangkártyával és mikrofonnal. Népszerű szoftvereket használnak a hang felvételéhez és különféle, például MP4-formátumba történő kódolásához, valamint rendszerint médialejátszókat használnak a hangfelvételek meghallgatásához.
A PC-n létrehozott hangfolyamot ezután az interneten keresztül egy jó hálózati kapcsolattal rendelkező médiakiszolgálóba töltik, hogy podcastokként tárolt állományokat közvetítsen, vagy élő közvetítést valósítson meg. A kiszolgáló a média szétosztását nagyszámú TCP-összeköttetés segítségével kezeli. A kiszolgáló egy webhely formájában felhasználói felületet is biztosít az adóállomásról szóló oldalakkal és a közvetítéssel elérhető tartalomra mutató hivatkozásokkal. Léteznek kereskedelmi szoftvercsomagok, melyek az összes részletet kezelik, de vannak nyílt forráskódú csomagok is, mint például az icecast.
Nagyon nagy számú ügyfél esetén azonban a TCP használata alkalmatlanná válik arra, hogy a médiát minden egyes ügyfélhez egyetlen kiszolgálóról küldje el. Ehhez egyetlen kiszolgálónak egyszerűen nincs elegendő sávszélessége. Nagy médiaközvetítő oldalak esetén a közvetítést földrajzilag szétszórtan elhelyezkedő kiszolgálók halmaza végzi, így egy ügyfél a legközelebbi kiszolgálóhoz csatlakozhat. Ez egy tartalomelosztó hálózat, amit ennek a fejezetnek a végén fogunk tanulmányozni.
A hanghívásokat valaha a nyilvános, kapcsolt távbeszélő-hálózaton továbbították, a hálózati forgalom elsősorban hangforgalomból állt, és csak itt-ott volt benne egy kis adatforgalom. Aztán jött az internet és a világháló. Az adatforgalom egyre csak nőtt, és 1999-re akkora lett az adatforgalom, mint a hangforgalom (mivel a hangot ma már digitalizálják, mindkettő mérhető bitekben). 2002-re az adatforgalom mérete egy nagyságrenddel meghaladta a hangforgalom méretét, és még mindig exponenciálisan nő, miközben a hangforgalom szinte stagnál.
Ennek a növekedésnek az lett a következménye, hogy a telefonos hálózat a feje tetejére állt. A hangforgalmat ma internetes technikával továbbítják, és a hálózati sávszélességnek csak egy csekély töredékét jelenti. Ezt a bomlasztó technikát IP-n keresztül történő hangátvitelként (voice over IP, VoIP) és internettelefóniaként (Internet telephony) ismerik.
Az IP-n keresztül történő hangátvitelt különféle formában használják, melyek mögött erős gazdasági tényezők működnek. (Magyarul: pénzt takarít meg, ezért az emberek használják.) Ennek egyik formája a hagyományos (régimódi?) telefonokra hasonlít, amely az Ethernetre csatlakozik, és hívásokat továbbít a hálózaton keresztül. Pehr Anderson egyetemi hallgató volt az M.I.T.-n, amikor barátaival létrehozta ennek az elgondolásnak a prototípusát egy osztályprojekt keretében. A munkára jó (4) osztályzatot kapott. Nem volt elégedett, ezért NBX néven 1996-ban céget alapított, elsőként alkalmazta ezt a fajta IP-n keresztül történő hangátvitelt, és három évvel később eladta a céget a 3Com-nak 90 millió dollárért. A vállalatok szeretik ezt a megoldást, mert lehetővé teszi számukra, hogy megszüntessék a különálló telefonvonalakat, és a hangátvitelt azzal a hálózattal valósítsák meg, amivel már egyébként is rendelkeznek.
Egy másik megoldás az IP-technikát nagy távolságú telefonos hálózat kiépítésére használja. Az olyan országokban, mint az Egyesült Államok, az ilyen szolgáltatás egymással versengő, nagy távolságú összeköttetéseket biztosító szolgáltatókon keresztül érhető el egy különleges előhívószám tárcsázásával. A hangmintákat a hálózatba injektált csomagokba helyezik, majd amikor a csomagok elhagyják a hálózatot, akkor kiveszik belőlük. Mivel az IP-berendezések sokkal olcsóbbak, mint a telekommunikációs berendezések, ez olcsóbb szolgáltatásokat eredményez.
Mellesleg az árkülönbségnek nem csak technikai okai vannak. A telefonszolgáltatás több évtizeden keresztül szabályozott monopólium volt, ami a telefontársaságoknak a költségeiket egy rögzített százalékkal meghaladó nyereséget garantált. Nem meglepő módon ez a költségek növelésére késztette őket, például sok-sok redundáns hardverrel rendelkeztek, melyet a nagyobb megbízhatósággal indokoltak (a telefonrendszer 40 év alatt összesen csak 2 órára állhatott le, vagy átlagosan évi 3 percre). Ezt a hatást gyakran „aranyozott telefonpózna szindrómaként” emlegetik. A szabályok fellazítása (dereguláció) óta ez a hatás természetesen csökkent, de a megörökölt berendezések még mindig léteznek. Az IT-ipar történetében soha nem fordult elő ilyesmi, így az mindig karcsú és fitt volt.
Mi azonban az IP-n keresztül történő hangátvitelnek arra a formájára fogunk koncentrálni, ami a felhasználók számára valószínűleg a legszembetűnőbb: amikor az egyik számítógépet arra használják, hogy felhívjon egy másik számítógépet. Ez a forma hétköznapivá vált, amint a PC-ket elkezdték mikrofonokkal, hangszórókkal, kamerákkal és a médiafeldolgozáshoz kellően gyors CPU-kkal szállítani, az emberek pedig elkezdtek otthonról, széles sávú átvitellel csatlakozni az internetre. Ennek jól ismert példája a Skype szoftver, amely 2003-ban jelent meg. A Skype és más társaságok is átjárókat biztosítanak annak érdekében, hogy a hagyományos telefonszámok felhívását, valamint az IP-címmel ellátott számítógépek felhívását könnyűvé tegyék.
A hálózati sávszélesség növekedésével a hanghívásokhoz a videohívások is csatlakoztak. Videohívások kezdetben csak a vállalatok területén belül történtek. A videokonferencia-rendszereket arra tervezték, hogy két vagy több helyszín között továbbítsa a mozgóképet, ami lehetővé teszi a különböző helyeken lévő vezetőknek, hogy lássák egymást, miközben a megbeszéléseiket tartják. Jó, széles sávú internet-összeköttetéssel és videotömörítő szoftverrel azonban otthoni felhasználók is videokonferenciázhatnak. Az olyan eszközök, mint a Skype, amelyek kezdetben csak hangátvitelt támogattak, ma már rutinszerűen mozgóképet is tartalmazó hívásokra is képesek, így barátok és családok láthatják és hallhatják is egymást szerte a világon.
A mi szempontunkból az internetes hang- vagy videohívás is egy médiaközvetítési probléma, de olyan, aminek sokkal több kikötésnek kell megfelelnie, mint egy tárolt állomány vagy egy élő esemény közvetítése. További megkötés a kis késleltetés, ami a kétirányú beszélgetéshez szükséges. A telefonhálózatok az elfogadható használathoz legfeljebb 150 ms egyirányú késleltetést engednek meg, e fölötti késleltetésnél a részvevők elkezdik érzékelni azt, és ez bosszantja őket. (A nemzetközi hívásoknak akár 400 ms késleltetése is lehet, és ezen a ponton messze vannak a pozitív felhasználói élménytől.)
Ilyen kis késleltetést nehéz elérni. 5-10 másodpercnyi média pufferezése biztosan nem fog működni (ami az élő sportesemények közvetítésekor működne). Ehelyett az IP-n keresztül történő video- és hangátviteli rendszereket olyan műszaki megoldásokkal kell megvalósítani, amelyek minimalizálják a késleltetést. Ez a cél azt jelenti, hogy az UDP az egyértelmű választás a TCP helyett, mert a TCP újraküldések legalább egy körülfordulási időnyi késleltetést jelentenek. A késleltetés bizonyos formái azonban nem csökkenthetők, még UDP-vel sem. Például a Seattle és Amszterdam közötti távolság közel 8000 km. A fénysebességű terjedési késleltetés az optikai kábelben ekkora távolságon 40 ms. Sok sikert a megdöntéséhez! A gyakorlatban, a hálózatban a terjedési késleltetés nagyobb lesz, mert nagyobb távolságot ölel fel (mivel a bitek nem követik a szélességi köröket), és továbbítási késleltetések lépnek fel, mert minden IP-útválasztó tárolja és továbbítja a csomagokat. Ez a rögzített késleltetés feléli az elfogadható késleltetés előirányzott mértékét.
A késleltetés másik forrása a csomagmérettel áll összefüggésben. Általában a nagy csomagok jelentik a hálózati sávszélesség kihasználásának legjobb módját, mert ezek hatékonyabbak. 64 kb/s mintavételezési sebességű hang esetében azonban egy 1 KB-os csomagot 125 ms ideig tartana megtölteni (és még tovább, ha a minták tömörítve vannak). Ez a késleltetés elfogyasztaná a teljes késleltetési előirányzat legnagyobb részét. Ráadásul, ha az 1 KB-os csomagot pontosan 1 Mb/s sebességű, széles sávú adatkapcsolaton keresztül küldik el, az átvitel 8 ms-ot fog igénybe venni. Aztán adjunk hozzá még 8 ms-ot, hogy a csomag a túlsó oldalon lévő széles sávú kapcsolaton is áthaladhasson. Nyilvánvaló, hogy nagy csomagokra ez nem fog működni.
Ehelyett a VoIP-rendszerek rövid csomagokat használnak a késleltetés csökkentése érdekében, a sávszélesség-kihasználás hatékonyságának rovására. A hangmintákat kisebb, általában 20 ms-os egységekbe zárják. 64 kb/s-os sebességen ez 160 bájt adatot jelent, tömörítéssel kevesebbet. Definíció szerint azonban az ebből a csomagolásból eredő késleltetés 20 ms lesz. Az átviteli késleltetés is kisebb lesz, mivel a csomag kisebb. A mi példánkban ez körülbelül 1 ms-ra csökkenne. A kis csomagok használatával egy Seattle-ből Amszterdamba tartó csomag legkisebb egyirányú késleltetése az elfogadhatatlan 181 ms-ról (40 + 125 + 16) az elfogadható 62 ms-ra (40 + 20 + 2) csökkent.
Eddig még nem beszéltünk a szoftver által okozott többletteherről, de ez is elhasználja a késleltetési előirányzat egy részét. Ez különösen igaz a mozgóképekre, mert általában tömörítésre van szükség ahhoz, hogy a mozgókép beleférjen a rendelkezésre álló sávszélességbe. Egy tárolt állomány közvetítésével ellentétben itt nincs idő számításigényes kódoló használatára a nagyfokú tömörítéshez. A kódolónak és a dekódolónak is gyorsan kell futnia.
A média mintáinak időben történő lejátszásához továbbra is szükség van pufferre (az érthetetlen beszéd és a szaggatott videó elkerülése érdekében), de a puffer méretét nagyon kis értéken kell tartani, mert a késleltetési előirányzatban megmaradó időt ezredmásodpercekben mérik. Amikor egy csomag megérkezéséhez túl hosszú idő szükséges, a lejátszó átlépi a hiányzó mintákat, és ilyenkor esetleg a környezetéből vett zajt játszik vagy megismétel egy képkockát, hogy elfedje a veszteséget a felhasználó elől. Kompromisszumot kell kötni a dzsitter kezeléséhez használt puffer mérete és a médiából elvesző mennyiség között. Egy kisebb puffer csökkenti a késleltetést, de több csomagvesztést eredményez a dzsitter miatt. Végül, ahogyan a puffer mérete csökken, a veszteség a felhasználó számára úgy válik egyre észrevehetőbbé.
A figyelmes olvasók észrevehették, hogy eddig ebben a szakaszban semmit sem mondtunk a hálózati rétegbeli protokollokról. A hálózat képes csökkenteni a késleltetést, vagy legalábbis a dzsittert, a szolgáltatásminőségi mechanizmusok használatával. Az az oka annak, hogy ez a kérdés korábban nem merült fel, hogy a médiaközvetítések képesek jelentős késleltetéssel is működni, még élő közvetítés esetén is. Ha a késleltetés nem komoly gond, egy fogadó oldali puffer elegendő a dzsitter problémájának megoldásához. A valós idejű konferenciahívás esetén azonban általában fontos, hogy a hálózat csökkentse a késleltetést és a dzsittert, ezzel segítve a késleltetési előirányzat teljesülését. Az egyetlen olyan alkalom, amikor ez nem lényeges akkor van, amikor olyan nagy a hálózati sávszélesség, hogy mindenki jó minőségű szolgáltatást kap.
Az 5. fejezetben két szolgáltatásminőséget biztosító mechanizmust ismertettünk, amelyek segítenek elérni ezt a célt. Az egyik mechanizmus a DS (Differentiated Services – differenciált szolgáltatások), amelyben a csomagokat különböző osztályokhoz tartozóként jelölik meg, amelyeket különbözőképpen kezelnek a hálózaton. A VoIP-csomagoknak megfelelő jelzés az kis késleltetés. A gyakorlatban a rendszerek beállítják a DS kódpontot a sürgős továbbítás (Expedited Forwarding) osztálynak megfelelő jól ismert értékre, kis késleltetés (Low Delay) szolgáltatástípussal. Ez különösen hasznos a széles sávú hozzáférési adatkapcsolatoknál, mivel ezek a kapcsolatok hajlamosak rá, hogy torlódás alakuljon ki rajtuk, amikor a webforgalom vagy más forgalom verseng a kapcsolat használatáért. Egy adott stabil hálózati úton a késleltetést és a dzsittert a torlódás megnöveli. Minden 1 KB-os csomagnak egy 1 Mb/s sebességű adatkapcsolaton keresztül történő elküldéséhez 8 ms-ra van szüksége, és egy VoIP-csomag ezeknek a késleltetéseknek teszi ki magát, ha a webes forgalom mögötti várakozási sorban foglal helyet. Egy kis késleltetésjelzéssel azonban a VoIP-csomagok a sor elejére ugranak, megkerülve a webes csomagokat és csökkentve késleltetésüket.
A késleltetés csökkentését szolgáló második mechanizmus szerint meg kell bizonyosodni arról, hogy van elegendő sávszélesség. Ha a rendelkezésre álló sávszélesség változik vagy az átviteli sebesség ingadozik (mint a tömörített mozgóképnél), és néha nincs elegendő sávszélesség, várakozási sorok alakulnak ki, és megnövelik a késleltetést. Ez még DS-nél is előfordulhat. Az elegendő sávszélesség biztosítása érdekében le lehet foglalni a hálózat erőforrásait. Ezt a képességet az integrált szolgáltatások biztosítják. Ez sajnos nem terjedt el széles körben. Ehelyett a hálózatokat egy várható forgalomnagyságra méretezik, vagy a hálózati ügyfeleket egy adott szintű forgalomnak megfelelő szolgáltatási szintű szerződésekkel látják el. Az alkalmazásoknak ez alatt a szint alatt kell működniük, hogy elkerüljék a torlódások kialakulását és a szükségtelen késleltetések megjelenését. Alkalmi otthoni videokonferencia-hívások esetén a felhasználó a sávszélességi igények helyettesítéseként videominőséget választhat, vagy a szoftver ellenőrizheti a hálózati utat és automatikusan választhat egy megfelelő minőséget.
A fenti tényezők közül bármelyik azt okozhatja, hogy a késleltetés elfogadhatatlanná válik, ezért a valós idejű videokonferenciák esetén mindegyikre figyelmet kell fordítani. Az IP-hálózaton keresztül történő hangátvitel áttekintéséhez és ezeknek a tényezőknek az analizálásához lásd Goode [2002] munkáját.
Most, hogy megtárgyaltuk a médiaközvetítés útvonalán keletkező késleltetés problémáját, áttérünk a következő fő gondra, amit a konferenciahívó rendszereknek meg kell oldaniuk. Ez a hívások felépítésének és lebontásának problémája. Két protokollt vizsgálunk meg, amelyeket széles körben alkalmaznak erre a célra: a H.323-at és az SIP-t. A Skype egy másik fontos rendszer, de ennek belső működése szabadalmaztatott.
Egyvalami mindenki számára világos volt már az interneten lebonyolított hang- és videohívások előtt, mégpedig az, hogy ha minden egyes szállító saját protokollkészletet tervez, akkor a rendszer sosem fog működni. Ennek elkerülésére számos érdekelt fél jött össze az ITU védnöksége alatt, hogy szabványokat dolgozzanak ki. 1996-ban az ITU kiadta a H.323-as ajánlását, „Nem-garantált szolgáltatásminőség nyújtására szolgáló vizuális telefonrendszerek és helyi hálózati eszközök” címmel. Ilyen címet is csak a távbeszélőipar tud kitalálni. Az 1998-as átdolgozás során gyorsan „csomagalapú multimédia kommunikációs rendszerek”-re változtatták. A H.323 lett az első, széles körben elterjedt internetes telefonrendszerek alapja. Ez is maradt a legszélesebb körben alkalmazott megoldás, 2009-ben készült el a hetedik változata.
A H.323 inkább az internettelefónia architekturális áttekintése, mintsem egy konkrét protokoll. A beszédkódolás, hívásfelépítés, jelzések, adatátvitel stb. területén számos konkrét protokollra hivatkozik ahelyett, hogy maga határozna ezekben a kérdésekben. Az általános modellt a 7.58. ábra mutatja. Középen található az átjáró (gateway), mely az internetet a telefonhálózattal köti össze. Ez beszéli a H.323-protokollokat az internet felőli oldalon, és a PSTN-protokollokat a telefonos oldalon. Az egymással kommunikáló eszközöket termináloknak (terminals) nevezzük. Egy LAN-on lehet még kapuőr (gatekeeper) is, ami a hatáskörébe tartozó végpontokat vezérli, melyek összességét zónának (zone) nevezik.
A telefonhálózat számos protokollt vesz igénybe. Először is van egy protokoll a hang és mozgókép kódolására és dekódolására. A szabványos telefonok egyetlen, 64 kb/s adatsebességű digitális hangcsatornával történő ábrázolását (8000, 8-bites hangminta másodpercenként) az ITU G.711 ajánlása definiálja. Az összes H.323 rendszernek támogatnia kell a G.711-et. Más beszédtömörítő protokollok is engedélyezettek, de ezek támogatása nem kötelező. Az ilyen protokollok különböző tömörítő algoritmusokat használnak és különböző kompromisszumot érnek el a minőség és a sávszélesség között. Mozgóképek esetén a fentebb ismertetett MPEG-formátumú tömörítéseket támogatják, beleértve a H.264-et is.
Mivel többfajta tömörítő algoritmus is engedélyezett, egy külön protokoll szükséges ahhoz is, hogy a terminálok megegyezzenek, hogy melyik algoritmust fogják használni. Ez a protokoll a H.245. Ez a kapcsolat egyéb szempontjairól, például az adatsebességről való tárgyalást is lehetővé teszi. Az RTP-csatornák vezérléséhez RTCP szükséges. Kell még egy protokoll a kapcsolatok kiépítéséhez és lebontásához, a tárcsahangok biztosításához, a csengetési hangokhoz és a hagyományos telefónia többi részéhez. Itt az ITU Q.931-et használják. A termináloknak szükségük van egy olyan protokollra is, mellyel a kapuőrökhöz beszélhetnek (ha vannak ilyenek). Erre a H.225 használatos, mely a RAS (Registration/Admission/Status – regisztráció/beléptetés/státus) nevű PC–kapuőr csatornát kezeli. Ez a csatorna lehetővé teszi, hogy a terminálok csatlakozzanak egy zónához, vagy hogy kilépjenek onnan, hogy sávszélességet kérjenek vagy adjanak vissza, frissítsék a státusukat stb. Végül kell egy protokoll a tényleges adatátvitelre is. Erre a célra RTP-t használnak, amit szokás szerint az RTCP kezel. Mindezen protokollok elhelyezkedését a 7.59. ábra mutatja.
Ahhoz, hogy lássuk, hogyan kapcsolódnak össze ezek a protokollok, vegyük azt az esetet, melyben egy PC terminál LAN-on (kapuőrrel) egy távoli telefont hív. A PC-nek először meg kell találnia a kapuőrt, ezért egy UDP kapuőr-felfedezési csomagot sugároz a 1718-as porton. Ha a kapuőr válaszol, a PC megtudja az IP-címét. Ezután elküld a kapuőrnek egy RAS-üzenetet egy UDP-csomagban, hogy regisztrálja magát nála. Ha ezt elfogadta, a PC elküld a kapuőrnek egy RAS-beléptetőcsomagot, melyben sávszélességet kér. A hívás csak akkor kezdődhet, ha ezt elfogadta. A sávszélesség előre való lefoglalása lehetővé teszi a kapuőr számára, hogy korlátozza a hívások számát. Így elkerülhető, hogy túl legyen jegyezve a kimeneti vonal, és biztosítható a szükséges szolgáltatásminőség.
Mellesleg a telefonrendszerek ugyanígy működnek. Amikor felemeljük a kagylót, egy jelzés fut be a helyi központba. Ha a központnak van elég szabad kapacitása egy másik híváshoz, előállítja a tárcsahangot. Ha nincs, akkor nem fogunk hallani semmit. Manapság a rendszer annyira túldimenzionált, hogy a tárcsahang csaknem azonnal megérkezik, de a telefonálás hajnalán ez gyakran néhány másodpercet vett igénybe. Tehát ha az unokák majd egyszer megkérdezik, „Miért vannak tárcsahangok?”, most már tudja. Kivéve, ha akkorra már valószínűleg telefon sem lesz.
A PC erre kiépít egy TCP-összeköttetést a kapuőrrel, hogy megkezdje a hívásfelépítést. A hívásfelépítés a meglevő telefonhálózati protokollokat használja, melyek összeköttetés-alapúak, ezért van szükség a TCP-re. A telefonrendszerben ellenben nincs semmi olyasmi, mint az RAS, amivel a telefonok a jelenlétüket bejelenthetnék, ezért a H.323 tervezői szabadon választhattak az UDP és a TCP közül az RAS számára, és végül a kevésbé költséges UDP-t választották.
Most, hogy már a sávszélességet is kiosztották, a PC elküldhet egy Q.931 SETUP üzenetet a TCP-összeköttetésen keresztül. Ez az üzenet meghatározza a hívott készülék telefonszámát (vagy egy IP-címet és egy portot, ha számítógépet hívtak). A kapuőr egy Q.931 CALL PROCEEDING üzenettel válaszol, hogy nyugtázza a kérés helyes vételét, majd továbbítja a SETUP üzenetet az átjárónak.
Az átjáró, ami félig számítógép, félig telefonos kapcsoló, egy hagyományos telefonhívás segítségével felhívja a keresett (hagyományos) telefont. Az a helyi központ, amelyre a telefont kötötték, megcsöngeti a készüléket, és visszaküld egy Q.931 ALERT üzenetet, hogy tudassa a PC-vel, hogy megkezdődött a csengetés. Amikor a másik oldalon felveszik a telefont, a helyi központ visszaküld egy Q.931 CONNECT üzenetet, hogy jelezze a PC-nek, hogy az összeköttetés kiépült.
Amint megvan az összeköttetés, a kapuőr kimarad a körből, de nem így az átjáró. Az ezután következő csomagok elkerülik a kapuőrt, és közvetlenül az átjáró IP-címére érkeznek. Ezen a ponton csak egy sima cső köti össze a két felet. Ez egy fizikai rétegbeli összeköttetés, mely pusztán biteket visz át, semmi több. Egyik fél sem tud semmit a másikról.
Ezután a H.245 protokollt használják, hogy egyezkedjenek a hívás paramétereiről. Ez a protokoll a H.245 vezérlőcsatornát használja, mely mindig nyitva áll. Mindkét oldal azzal kezdi, hogy bejelenti a képességeit, például, hogy tud-e kezelni mozgóképeket (a H.323 erre is képes) vagy konferenciahívásokat, milyen kodekeket támogat stb. Amikor mindkét oldal megtudta, hogy mire képes a másik, két egyirányú adatcsatornát állítanak fel, és mindegyikhez egy kodeket és egyéb paramétereket rendelnek. Mivel a berendezések a két oldalon különbözők lehetnek, minden további nélkül lehetséges, hogy az előre- és visszairányú csatornákon különböző kodekeket használnak. A tárgyalások befejezése után megindulhat az adatfolyam az RTP felhasználásával. Ezt az RTCP kezeli, melynek a torlódáskezelésben van szerepe. Ha mozgókép is van, akkor az RTCP kezeli a hang/kép szinkronizációt. A különböző csatornákat a 7.60. ábra mutatja. Ha bármelyik fél lerakja a kagylót, a hívás befejeződött. Ezt követően a Q.931 hívásjelzési csatorna segítségével lebontják az összeköttetést, hogy felszabadítsák azokat az erőforrásokat, amelyekre többé nincs szükség.
Amikor a hívás véget ért, a hívó PC egy RAS-üzenettel újból megkeresi a kapuőrt, hogy visszaadja a kapott sávszélességet, de kezdeményezhet esetleg egy újabb hívást is.
Még semmit nem szóltunk a H.323 részét képező szolgáltatásminőségről, annak ellenére, hogy azt mondtuk, ez fontos részét képezi a valós idejű konferenciahívás sikerre vitelének. Ennek az az oka, hogy a QoS kívül esik a H.323 körein. Ha a hívások alapjául szolgáló hálózat képes megbízható, dzsittermentes összeköttetést kiépíteni a hívó PC-től az átjáróig, akkor a hívás során jó lesz a szolgáltatásminőség, egyébként nem. A telefonos oldalon azonban a hívás minden része dzsittermentes lesz, mert a telefonhálózatot így tervezték meg.
A H.323-at az ITU dolgozta ki. Az internetes közösségből sokan tipikus telefontársasági terméknek: nagynak, bonyolultnak és rugalmatlannak tekintették. Következésképp az IETF is felállított egy bizottságot, hogy kidolgozzon egy egyszerűbb és még modulárisabb megoldást az IP-n keresztül történő hangátvitelre. A munka legfőbb eredménye az SIP (Session Initiation Protocol – viszonykezdeményező protokoll) lett. A legutolsó változatot, ami 2002-ben készült, az RFC 3261 írja le. A protokoll leírja, hogyan kell internetes telefonhívásokat, videokonferenciákat és más multimédiás összeköttetéseket felépíteni. A H.323 teljes protokollkészlet, míg az SIP csak egyetlen modul, de ezt arra tervezték, hogy jól együtt tudjon működni a meglevő internetes alkalmazásokkal. A telefonszámokat például URL-ként definiálja, hogy weboldalakon is fel lehessen tüntetni azokat, és egy kattintással lehessen hívást kezdeményezni (ugyanúgy, ahogyan a mailto sémával egy kattintással elő lehet hozni egy programot az e-levél küldéséhez).
Az SIP-vel két résztvevős (hagyományos telefonhívások), több résztvevős (mindenki beszélhet és hallható is) és többesküldéses (egy adó, több vevő) kapcsolatokat is létre lehet hozni. A kapcsolatokban lehet hang-, mozgókép- vagy adatforgalom is, ez utóbbi például a többszereplős, valós idejű játékoknál hasznos. Az SIP csak a kapcsolatok kiépítéséért, kezeléséért és lebontásáért felelős; az adatátvitelt más protokollok végzik, mint például az RTP/RTCP. Az SIP az alkalmazási réteg protokollja, és igény szerint futhat UDP vagy TCP fölött is.
Az SIP különféle szolgáltatásokat támogat, beleértve a hívott fél felkutatását (aki lehet, hogy nem az otthoni gépénél ül) és a hívott fél képességeinek meghatározását, valamint a hívásfelépítés és -bontás eljárásait. A legegyszerűbb esetben az SIP egy kapcsolatot épít fel a hívó és a hívott fél gépe között, először tehát ezt az esetet fogjuk tanulmányozni.
Az SIP-ben a telefonszámokat URL-ként ábrázolják a sip séma használatával. A sip:ilse@cs.university.edu utalhat például egy Ilse nevű felhasználóra a cs.university.edu DNS-nevű hoszton. Az SIP URL-ek tartalmazhatnak IPv4-címeket, IPv6-címeket vagy tényleges telefonszámokat is.
Az SIP a HTTP mintájára készült szöveges protokoll. Az egyik fél elküld egy ASCII-szöveges üzenetet, mely egy metódus nevét tartalmazza az első sorban, amit további sorok követnek az átadandó paramétereket tartalmazó fejlécekkel. Sok fejlécet a MIME-ből vettek át, hogy az SIP együtt tudjon működni a meglevő internetes alkalmazásokkal. Az alapspecifikáció által definiált hat eljárást a 7.61. ábra sorolja fel.
Egy munkamenet kiépítéséhez vagy a hívó hoz létre egy TCP-összeköttetést a hívott féllel, és azon küldi át az INVITE üzenetet, vagy pedig egy UDP-csomagban küldi át az INVITE-ot. A fejlécek mindkét esetben a második és az azt követő sorokban írják le az üzenet törzsének szerkezetét, mely a hívó képességeit, médiatípusait és formátumait tartalmazza. Ha a hívott fél fogadja a hívást, akkor egy HTTP-típusú válaszkóddal válaszol (ez egy háromjegyű szám, mely a 7.38. ábra csoportjait használja, például 200 jelenti az elfogadást). A válaszkód sora után a hívott fél is információt adhat a képességeiről, médiatípusairól és formátumairól.
Az összeköttetés egy „háromutas kézfogás” révén épül ki, vagyis a hívó végül egy ACK üzenet visszaküldésével nyugtázza a 200-as üzenet vételét.
Bármelyik fél kérheti a munkamenet bontását egy olyan üzenet elküldésével, mely a BYE eljárást tartalmazza. Ha a másik oldal ezt nyugtázza, akkor a viszony véget ér.
Az OPTIONS metódus egy gép képességeinek lekérdezésére való. Ezt rendszerint a munkamenet létrejötte előtt használják, hogy megtudják, hogy a kérdéses gép egyáltalán képes-e IP-n keresztül történő hangátvitelre vagy bármely adott viszonytípusra.
Az SIP lehetőséget ad egy otthonától éppen távol lévő felhasználó követésére és elérésére – ehhez a képességhez kötődik a REGISTER metódus. Ezt az üzenetet egy SIP helymeghatározó kiszolgálónak küldik el, ami nyomon követi, hogy ki hol tartózkodik éppen. Ettől a kiszolgálótól később le lehet kérdezni a felhasználó aktuális tartózkodási helyét. Az átirányítás műveletét a 7.62. ábra szemlélteti. Itt a hívó elküld egy INVITE üzenetet a helyettes kiszolgálónak, mely elrejti az esetleges átirányítást. A helyettes ezután megkeresi a felhasználó tartózkodási helyét, és oda küldi az INVITE üzenetet. Ezt követően átjátszóként működik a további üzenetek számára a „háromutas kézfogásban”. A LOOKUP és REPLY üzenetek nem részei az SIP-nek; itt tetszés szerinti protokoll használható a helymeghatározó kiszolgálótól függően.
Az SIP-nek számos olyan funkciója van, amit most nem tárgyalunk, mint például a hívásvárakoztatás, hívásszűrés, titkosítás és hitelesítés. A protokollnak megvan az a képessége is, hogy hívásokat létesítsen egy számítógépről egy hagyományos telefonra, ha rendelkezésre áll egy megfelelő átjáró az internet és a telefonrendszer között.
A H.323 és az SIP is lehetővé teszi a két résztvevős és több résztvevős hívásokat mind számítógépes, mind telefonos végpontok között. Mindkettő támogatja a paraméterekkel kapcsolatos egyezkedéseket, a titkosítást és az RTP/RTCP-protokollokat. A különbségek és hasonlóságok összegzését a 7.63. ábra adja meg.
Bár a funkciókészletek hasonlók, a két protokoll filozófiája nagyban eltér. A H.323 egy tipikus, nehézsúlyú távbeszélő-ipari szabvány, amely meghatározza a teljes protokollkészletet, és pontosan definiálja, hogy mit szabad és mit nem. Ez a megközelítés ahhoz vezet, hogy a protokollok minden rétegben nagyon jól meghatározottak, ami megkönnyíti az átjárhatóságot is. Ennek az ára egy nagy, bonyolult és merev szabvány, amit nehéz a jövőbeli alkalmazásokhoz igazítani.
Az SIP ezzel szemben egy tipikus internetes protokoll, amely rövid ASCII-sorok cseréjével működik. Ez egy könnyűsúlyú modul, ami jól együtt tud működni más internetes protokollokkal, de kevésbé jól a már meglevő telefonos jelzési protokollokkal. Az IETF-féle IP-s hangátvitel különösen moduláris, rugalmas és könnyen igazítható az új alkalmazásokhoz. A hátránya az, hogy folyamatosan átjárhatósági problémák merülnek fel, amikor az emberek megpróbálják értelmezni a szabvány jelentését.
[35] Jelenleg (2011-ben) a legnagyobb kapacitású DVD-18 már 17 GB adatot tartalmaz. Tipikus inkább a DVD-5, amely 4,7 GB adatot tartalmaz. (A fordító megjegyzése)
[36] Újabban a nagyobb felbontású HDTV is megjelent 1920 × 1080 képpontos felbontással. (A lektor megjegyzése)
[37] A továbbiakban a média közvetítése mindig folyamszerű továbbítást jelent. (A lektor megjegyzése)
[38] A weben rendszertelenül (epizódonként) közzétett audio- vagy videoállományok sorozata. A szó az iPod és a webcast összevonásából származik. (A lektor megjegyzése)
[39] A témát részletesebben lásd a http://mediapedia.hu/musorszolgaltato-portal honlapon. (A fordító megjegyzése)