0 lyhenneluettelo

1. johdanto

2.1 Liikkuvan kuvan määrittely

2.2 Videokuvan käyttöalueet

2.3 Videokuvan pakkausmenetelmät

2.4 Videokuvan pakkausmenetelmien vertailua

3.1 Bittivirtakontrollointi

3.2 Multiplexointitavat ja videokuvan siirto

3.3 Viiveen vaikutus ja kompensointi

3.4 Virhekompensointi ja korjaus

3.5 Videosiirto ATM-verkossa

3.6 Videosiirto internetissä

3.7 Videosiirto matkapuhelinverkossa

3.8 Videosiirto lähiverkossa

4 Yhteenveto

5 viitteet

Multimedia on saanut yhä tärkeämmän aseman nykypäivän verkkottuneessa ympäristössä. Kuitenkin on helppo unohtaa että verkon resurssit eivät ole loputtomat - eikä niitä kannata loputtomiin lisätä. Siksi on tärkeää ymmärtää tiedonsiirron laadun muodostumismekanismit ja multimedian - erityisesti videokuvan - tiedonsiirrolle asetettamat vaatimukset.

Esitelmä koostuu kahdesta osasta, joista ensimmäinen käsittelee yleisesti liikkuvaa kuvaa ja sen koodausta. Toinen osa käsittelee tuon koodatun bittivirran käsittelyä verkossa, käyden läpi eri ongelma-alueita ja lopussa esittelee joidenkin verkkojen erikoispiirteitä videokuvan siirron kannalta.

Kun puhutaan liikkuvasta kuvasta, niin mitä tarkoitetaan? Kyseessä voi olla animaatio, simuloitu eli tietokoneen mallista renderoima kuva tai videokuva. Animaatio voidaan kuitenkin verrastaa videokuvaan jos siinä on paljon yksityiskohtia. Animaationa voidaan pitää myös telekonferenssin datakonferenssiosuutta, eli jaettua työpöytää. Renderoidun kuvan siirrossa kysymykseksi nousee onko mahdollista luoda kuva vastaanottajakoneessa mallin perusteella tarpeeksi nopeasti. Jos voidaan, niin on järkevintä siirtää vain malli tai sen muutokset. Tämä lähestymistapa on käytössä esimerkiksi verkkopeleissä ja virtuaalitodellisuudessa. Kaikkein eniten verkkoresursseja vaatii kuitenkin videokuva.

Laji Kaistanleveys Siirtotapa Konevaatimukset

Näistä tärkein verkon kannalta on videokuva, ja se on se joka tarjoaa suurimmat kasvumahdollisuudet. Tässä esitelmässä tullaan käsittelemään yksinomaan videokuvan siirtoa. Animaatiosta ja simulaatiosta kiinnostuneiden kannattaa lukea tämän kurssin esitelmät: "Java" (Markku Merikoski) ja "VRML" (Jouni Korte).

Videokuvaa siirretään analogisesti ja digitalisesti. Analogiset lähetykset ovat kaikkein tutuimpia, eli radioaalloilla ja kaapeleita pitkin siirrettävä perinteiset TV-lähetykset. Nämä ovat väistyviä tekniikoita, sillä digitaalinen kuvainformaatio voidaan usein siirtää tehokkaammin ja virheettömämmin kuin analoginen.

Digitaalista videokuvaa käyttävät videokonferenssit,näköpuhelimet, digitaalinen televisio, multimedia-arkistot ja video-on-demand. Nämä ovat periaatteellisesti melko lähellä toisiaan, mutta videokonferenssi ja näköpuhelin eroavat muista siinä, että siirto on kaksisuuntainen ja siirtoviive ei saa olla suuri.

Erilaisissa valvonta- ja hälytysjärjestelmissä käytetään sekä analogista että digitaalista kuvansiirtoa.

Koska videokuvan viemä kaistanleveys pakkaamattomana on hyvin suuri, on järkevää pyrkiä pienentämään kaistanleveyttä hyödyntämällä kuvakehyksen sisäistä ja erityisesti kuvakehyksien välisiä riippuvuuksia.

Kuvan pakkauksessa on hyvä muistaa, että tarkoitus ei ole pyrkiä täydelliseen tai edes lähes täydelliseen alkuperäistä vastaavaan kuvaan. Ihminen ei esimerkiksi pysty erottamaan värejä toisistaan läheskään yhtä hyvin kuin valoisuusasteita, jonka ansiosta jo analogisessa televisiokuvassa on väri-informaatiolla vain puolet valoisuusinformaation kaistasta. Toinen merkittävä ihmisen näön epäideaalisuus on se, jonka näkee joka päivä televisiosta: Silmä ei pysty erottamaan nopeampia kuin noin 30 Hz muutoksia. [1] ( Televisiokuvan näyttötaajuus: Eurooppa 25 Hz, USA ja Japani 30 Hz) Huomaa, että tässä taajuudella tarkoitetaan uuden kuvakehyksen näyttätaajuutta, ei näytön virkistystaajuutta.

Kuvaa voidaan lisäkompressoida useilla eri menetelmillä jotka muuntavat videokuvan VBR-koodatuksi. Yleistä kaikille menetelmille -ehkä morphologisia lukuunottamatta- on, että pakkaussuhteen kasvattaminen lisää kuvan virhettä. Alla lueteltuina muutamia kuvanpakkausstandardeja ja menetelmiä.

MPEG 1,2,4

Ovat Moving Pictures Expert Groupin kehittämiä pakkausmenetelmiä, jossa käytetään DCT:tä ja liikkeen kompensointia. Koodattu video sisältää I-,P- ja B-kehyksiä. I-kehys on koodattu vain kuvan sisäistä ylimääräistä informaatiota, P-kehyksessä hyödynnetään edellistä kehystä ja B-kehyksessä edellistä ja B-kehystä seuraavaa kehystä (B-kehystä ei siis voi purkaa ennen seuraavan kehyksen saapumista). [2]

MPEG 2 on digitaalisessa TV:ssä ja HDTV:ssä käytettäväksi valittu menetelmä.

MPEG 3:a suunniteltiin HDTV:lle, mutta siitä luovuttiin.

MPEG 4 on kehitysvaiheessa.

H261,H263

Ovat ITU-T:n (ent. CCIT) standardeja videokoodaukseen. Ovat hyvin samankaltaisia kuin MPEG. H261 on suunniteltu n*64kbit/s yhteyksiä (ISDN) varten. H263 on tarkoitettu alhaisen bittimopeuden siirtoon. Toimivat kuvaformaatteilla QCIF ja CIF. H263 myös sub-QCIF,4CIF,16CIF. Erot formaateissa lähinnä koot. ( QCIF: 176*144, 16CIF: 1408*1152 ) [3]

Wavelet-vektori-koodaus

Liikkuvaan kuvaan laajennettu wavelet-koodaus. Wavelet-koodauksessa koostetaan signaali funktion w(t) expansiosta ja transformaatioista. Liikkuvan kuvan koodauksessa saadaan liikekompensoinnin tulosta parannettua kun kuva paloitellaan toistensa yli meneviin paloihin. [4]

Esimerkki 1.ulotteisesta koodauksesta: (Haar)

koodaus: 7 5 6 10

1. aste : (7+5)/2 (6+10)/2 (7-(7+5)/2) (6-(6+10)/2) = 6 8 1 -2

2. aste : (6+8)/2 (6-(6+8)/2) 1 -2 = 7 -1 1 -2

purku: 7 -1 1 -2

1. aste : (7+(-1) (7-(-1)) 1 -2 = 6 8 1 -2

2. aste : (6+1) (6-1) (8+(-2)) (8-(-2)) = 7 5 6 10

Säästö syntyy purkuparametrien pienuudesta.

Morphologinen, rajapinta ym. koodaukset

Näissä pyritään jakamaan kuvapinta erimuotoisiin alueisiin. Kuvan liikkuessa siirretään alueiden muotoja ja paikkaa kuvaavat parametrit. Tehokas esimerkiksi silloin kun kuva on "puhuva pää". Ongelmana algoritmien monimutkaisuus ja epätarkkuus.

MPEG 1 on jo vanha tekniikka, sen tarjoama VHS-videolaatua heikompi kuvanlaatu vie noin 1,5 Mbit/s kaistan.

MPEG 2 tarjoaa hyvän kuvanlaadun, TV-kuvan tasoa 1,5 - 5 Mbit/s kaistalla. Sillä on kuitenkin ongelmana se, että pienillä bittinopeuksilla sen laatu tippuu pahasti. Se taas johtuu siitä, että DCT koodatun kuvan laatu on hyvin riippuvainen taajuuskomponent-tien esitystarkkuudesta.

H261 tarjoaa paremman kuvanlaadun kuin MPEG 2 pienillä bittinopeuksilla. Sen kaistavaatimus on n*64 kbit/s, missä n on 1..30. Standardi tarjoaa katsottavan kuvanlaadun, mutta ei sovellu korkealaatuisen kuvan välitykseen. H261 on yleisin videokonferenssi ja näköpuhelin sovelluksissa käytetty pakkausmenetelmä. Sen ongelmana on tuettujen kuvakokojen pienuus : QCIF:144*176 ja CIF:288*352.

H263 on suunniteltu alhaisen bittinopeuden sovelluksiin. Sen tukemat kuvakoot antavat jo mahdollisuuden laadukkaimpiin sovelluksiin. Se ei ole rajoitettu 64kbit moninkertoihin kuten H621. Sen tarjoama laatu ei kuitenkaan riitä näköpuhelinta laadukkaimpiin sovelluksiin.

Ei olisi järkevää verrata MPEG ja H.62x koodattuja videoita, koska ne ovat suunnattu eri laatutasoille. Tässä on vertailtu H.621 ja H.623 koodattuja videoiden laatua nopeuksilla 15, 30 ja 45 kbit/s.[2]

On selvää, että esimerkiksi näköpuhelin ja digitaalinen TV ovat erilaisia siinä, minkälaiset laatuvaatimukset ne asettavat verkolle, esimerkiksi näköpuhelin esimerkitsi tarvitsee VOD:ia huomattavasti pienemmän kaistan heikomman sallittavan laadun ja pienemmän koodaustarpeen takia. Yhteistä kaikille digitaalisen videokuvan siirroille on se, että ne vaativat suhteellisen paljon kaistanleveyttä ja koska ne ovat VBR-koodattuja, niin tätä kaistanleveyttä on vaikea ennustaa, mikä on ryöppyisen tiedonsiirron ongelma yleisestikin, mutta videokuvan siirrossa ongelmana on se, että kuvakehysten näyttötaajuuden on pysyttävä lähes vakiona.

Koska perinteisessä verkkossa on tiedonsiirtonopeus yhteydellä vakio kuten ISDN yhteydellä n*64 kbit/s, joudutaan VBR (Variable BitRate) koodattu videokuva muuttamaan FBR (Fixed BitRate) koodatuksi. Tämä voidaan toteuttaa lisäämällä bufferi VBR kooderin ja verkon väliin. Tällöin aiheutuu kuitenkin viivettä, koska ollakseen toimiva bufferin on oltava tarpeeksi iso. Eli jos kuvakehys sattuukin olemaan kovin iso, eikä sitä voida lähettää käytettävissä olevan taajuuskaistan avulla, siitä lähetetään vain osa ja loput heti kun ehditään. Tämä toimii, vaikkakin aikaansaa viivettä, koska bittivirta pitkällä ajanjaksolla on keskimäärin tasainen. Ongelmana tässä ratkaisussa on se, että sen lisäksi että tarvitaan suuri bufferi, on enemmän kuin todennäköistä, että tulee tilanteita joissa bufferissa tapahtuu ylivuotoa. Tämä voidaan ratkaista lisäämällä systeemiin takaisinkytkentä kooderin ja bufferin välille. Tällöin kun bufferi alkaa täyttyä käsketään kooderia koodaamaan tehokkaammin ja jos bufferi alkaa olla tyhjä, niin kooderia käsketään parantamaan laatua eli koodaamaan tehottomammin. Ongelma tässä ratkaisussa on se, että kuvan laatu vaihtelee, sekä tehottoman koodauksen ongelma tyhjenevän bufferin tapauksessa, jolloin ei siis käytetä taajuuskaistaa tehokkaasti hyväksi. [1]

ATM-verkossa ei ylläolevaa ongelmaa läheskään samassa mitassa ole. Koska ATM tarjoaa säädettävän taajuuskaistan, ei bufferi ole tarpeen - teoriassa. Todellisuudessa myös ATM-verkkoa käytettäessä ylivuoto-ongelma saattaa esiintyä - tosin nyt verkon sisällä koska kutsunhyväksyntäkontrollikriteerit saattavat pettää johtuen bittivirran mallinnuksen puutteista.[5]

2. Multipleksointitavat ja videokuvan siirto

Multipleksointi voidaan tehdä joko laatutakeitta,deterministisesti tai tilastollisesti. Tarkoitus multipleksointialgoritmeillä on varata tarjolla olevasta kaistasta luotettava ja tehokas osuus yhteyden tarpeisiin.

Laatutakeettomassa multipleksoinnissa kutsu hyväksytään aina. Tällöin luotetaan siihen, että järjestelmä sisältää tarpeeksi bufferointia jotta pakettien katoamista ei tapahdu. Videodekoodausalgoritmi voi myös sisältää virheistä toipumismekanismeja.

Laatutakeeton multiplexointi on yleisesti käytössä videokuvan siirrossa. [5]

Deterministisessä multipleksoinnissa varataan yhteydelle "varmasti tarpeeksi" kaistaa yhteydenmuodostuksessa annettujen tietojen perusteella. Verkkopalvelun laatu taataan siis yhteystasolla, jolloin jos ei ole tarpeeksi varaamattomana olevaa kaistaa täyttämään pyyntöä, yhteys hylätään. Haittapuolena tässä on se, että taajuuskaistaa hukkaantuu koska kaistaa joudutaan varaamaan keskimääräisen bittivirran perusteella ja ryöppyisessä liikenteessä suurimman osan ajasta liikenne on huomattavasti alle keskiarvon.

Tilastollisessa multipleksoinnissa mallinnetaan yhteydet todennäköisyysjakautumien perusteella. Kun tiedetään haluttu häviötodennäköisyys verkkolle (yleensä noin 10^-8 - 10^-9) ja bittivirtojen todennäköisyystiheysfunktioiden keskiarvot ja varianssit, voidaan konvoluutiotodennäköisyystiheysfunktion keskiarvo ja varianssi laskea yksinkertaisesti laskemalla yksittäisten virtojen komponentit yhteen. Tämän jälkeen valitsemalla sopiva jakauma voidaan haluttu häviötodennäköisyys tutkia. Kun yhteyksiä on tarpeeksi monta, esimerkiksi yli sata, on Gaussin käyrä sopiva tähän.[1]

Multipleksointia voidaan tehdä myös palvelun mukaan. Esimerkiksi ääni ja data voidaan hyvin siirtää erossa kuvainformaatiosta, kunhan huolehditaan äänen ja kuvan synkronoinnista (noin 100 ms maksimiero). Data tarkoittaa tässä videokuvaan liittyvää muuta tietoa, kuten tekstitystä. Palveluiden multipleksoinnissa voidaan mennä vieläkin pidemmälle ja jakaa kuvainformaatio useampaan tasoon jotka vastaavat kuvan eri laatutasoja. Ylimmällä tasolla voisi olla HDTV:hen liittyvä lisäinformaatio, sen alla TV-tasoiseen kuvan lisäinformaatio ja alla näköpuhelintasoinen data.

Viivettä syntyy:

• Kuvan A/D muunnoksessa ja näyttämisessä näyttömuistin hitaudesta ja värioptimoinnissa.
• Koodauksessa, bittivirtakontrollissa ja dekoodauksessa
• Segmentaatiossa ja kokoamisessa
• Protokollan käsittelyssä
• Siirtojohdoissa
• Vuorojonoissa (queuing) reitityksessä

Suurimmat viiveet syntyvät protokollan käsittelyssä ja reitityksen jonoissa. Jonoihin voidaan vaikuttaa äykkäillä multipleksointialgoritmeillä. Protokollan käsittelyssä tulee suurin osa viiveestä. Siihen kuuluu protokollakehyksen asettaminen, tarkistussummien laskeminen ja osoitteiden haut ja muunnokset. Protokollaviivettä ei pahemmin voi pienentää paitsi vaihtamalla protokollaa, joka on turhan radikaali ratkaisu. Näin ollen viiveen kompensointi jää sovellusohjelman harteille.

Kun kuvakehykset saapuvat vastaanottajalle, on niille löydettävä yhteinen kello. Miksi ?. No oikeastaan tämä ei ole tarpeellista läheskään kaikissa sovelluksissa. Ainoastaan interaktiivisen monilähteisen kuvainformaation (eli videokonferenssi) käsittelyssä on hyvä, että eri lähetykset synkronoidaan. Tässä on kuitenkin hyvä muistaa, että jos äänidata lähetetään erillään kuvasta, on nämä tässä synkronoitava.

Jotta voitaisiin korjata virheitä, on oltava tietoa millä korjata ne. Videokuvan siirrossa virheenkorjauskoodi kannattaa laskea bittitasolla sarakkeittain lähetettävästä kuvakehyksestä ja lähettää koodit kuvan perässä.[1] Nopeassa videosiirrossa ei normaalia uudelleenlähetysmenetelmää voida käyttää.

Toinen vaihtoehto, itseasiassa suositeltavampi on jättää virhe korjaamatta ja yrittää minimoida vahinko. Tämä on mahdollista esimerkiksi jättämällä puuttuvan tai virheellisen paketin kuvaama alue kuvasta päivittämättä ja pyytämällä lähettäjää lähettämään päivittämättön alue koodaamattomana seuraavassa kehyksessä, jonka jälkeen jatketaan kuten ennen.[6] Tämä tietysti toimii vain interaktiivisilla yhteyksillä. Muilla yhteyksillä voidaan yrittää ennustaa virheellisen alueen sisältö edellisten kuvakehysten perusteella, mutta tällöin syntyy virhettä, joka tulee etenemään seuraaviin kehyksiin kunnes saapuu ennusteita käyttämätön kehys.

5. Videosiirto ATM-verkossa

ATM verkko tarjoaa nopean siirtotien ja näin ollen on sopiva korkealaatuisen kuvan siirtoon. AAL 1 soveltuu FBR videosiirtoon ja AAL 5:sta voidaan käyttää VBR siirtoon. ITU-T suositus J.82 sisältää määritelmät AAL 1:_lle ja AAL 5:lle MPEG 2 koodatun videon siirtoon. AAL 2 on osoitettu VBR videon siirtoon, mutta sitä ei ole tarkemmin standardisoitu.

Videosiirto internetissä käyttää yleensä UDP:tä tiedonsiirtoon. Sen päällä voi toimia RTP. RTP ei takaa yhteyden laatua. Esimerkkinä tuotteesta joka käyttää internettiä videosiirtoon voidaan mainita vaikkapa CU-SeeMe. Cornvellin yliopiston kehittämä ilmainen videokonferenssiohjelma.

Matkapuhelinverkkojen pienen kaistanleveyden takia ei niissä ole mahdollista siirtää muuta kuin näköpuhelintasoista videokuvaa, eli koodattuna H.623 standardin mukaisesti ilman virheenkorjauksia. Tällöin on oletuksena hyva kuuluvuusalue. Koska katsottavan kuvan pienimmilläänkin vievä tila on suurehko verrattuna tarjolla olevaan kaistanleveyteen, on kuva ja ääni siirrettävä eri kanavilla. [6]

Lisäksi on huomattava, että mikäli vastaaottaja liikkuu paljon, tulee virheiden runsaan esiintymisen takia siirrosta käytännöstä mahdotonta.

8. Videosiirto lähiverkoissa

Kun lähiverkko yleisesti ottaen tarkoittaa ethernet-verkkoa, tulee esille ethernetille ominaiset ongelmat tukkeutumisesta. Ethernetverkon tarjoama 10 Mbit/s kaistanleveys on sinänsä riittävä lähiverkolle järkevän videosiirron, eli videokonferenssin/näköpuhelimen, toteuttamiseen. Ongelmana on, että vaikka ethernet takaa paketin perillepääsyn, se ei pysty antamaan takeita minkäänlaisista aikarajoista. Videokuvan siirtämiseen vaaditaan että ainakaan pitempiä katkoksia ei synny. Ethernetin puutteita korvaamaan on kehitetty isoEthernet, joka lisää ethernetin päälle 6,144 Mbit/s kaistanleveyden. Tämä lisäkapasiteetti on jaettu 64kbit/s isynkronisiin kanaviin. Tätä konfiguraatiota pystyy hyödyntämään mm. Ericssonin Multimedia Workgroup System.

Multimedia valtaa maailmaa, ja se pakottaa panostamaan verkonsuunnitteluun. Koska verkon kapasiteetti on ja tulee todennäköisesti aina olemaan kortilla, pitäisi verkon kapasiteetti käyttää tehokkaasti hyväksi. Tämän seurauksena on pyrittävä kehittämään liikenteen mallinnus- ja hallintamenetelmiä, jotka ottavat entistä paremmin tietoliikenteen uuden luonteen huomioon. Kaikki verkkoinvestoinnit on myös maksettava ja maksaja on kuluttaja. Jos kuluttajalle ei pystytä tarjoamaan laadukasta palvelua, hän ei maksa. Videokuvan lähetys tietoverkoissa on uusi ja monin osin vielä kokeiluasteella oleva palvelu. Halutaanko kokeilusta edetä käytäntöön ? Ainakin internetin trendit näyttävät siltä. Saa nähdä ... toivottavasti ei vain kuulla.

[2] http://www.mpeg.org

[3] http://www.info.itu.org.br