10.11.-97, Tätä dokumenttiä ei päivitetä.

Liikkuvan kuvan välitys internetissä

Tässä dokumentissa liikkuvan kuvan (videokuvan) siirrolla tarkoitetaan realiaikaisen on-demand tai
live-broadcast periaatteella käyttäjälle välitettyä datavuota. Audion koodamiseen tai siirtämiseen ei
kiinnitetä huomiota, mutta voitaneen todeta, että audiodatan siirtäminen aiheuttaa verkkoyhteydelle
videotakin kovemmat QoS-vaatimukset suuremman aikakriittisyytensä vuoksi, tosin käytettävä kaista
on tietenkin huomattavasti kapeampi.
 

Johdanto

Internetin kasvun myötä verkkoon on alettu laittaa saataville myös kontenttia, jonka levitystä varten
nettiä ei ole suunniteltu. Yhteydettömässä verkossa ei voida taata minkäänlaista tiedonsiirtokapasiteettiä
yksittäiselle yhteydelle ja kun tiedämme, että pakkaamaton CCIR-601-standardin mukaan digitoitu
kuva käyttää tiedonsiirtokapasiteettiä 165 megabittiä sekunnissa, täytyy todeta että laadukkaan
liikkuvan kuvan saaminen internetiin on melkoinen haaste. CCIR-601 määrittelee kuvan muodostavien
juovien määrän ja digitalisoitaessa pikselidimensiot [1]. Ongelma on siis kaksijakoinen; kuinka saada
taattua riittävä varmuus tiedonsiirto kapasiteetista yhteydettömässä verkossa ja kuinka saada pakattua
videokuvan sisältämää runsasta informaatio määrää riittävän tiiviiksi, jotta vaatimus liikkuvasta kuvasta
katsojan päässä toteutuu. Tässä dokumentissä käsitellään yleisluontoisesti näitä kahta kysymystä ja
lopuksi tarkastellaan  IP-pohjaiseen videokuvan välitykseen tehtyjä sovelluksia ja lopuksi esitellään
lyhyt pohdinta internetin ja videon tulevaisuudesta.
 
 

Osa 1, Suuren tietomäärän ongelma

Kuten edellä todettiin jo yksi sekunti digitoitua videokuvaa sisältää mammuttimaisen tietomäärän.
Pakkaamattoman kuvasekvenssin siirtäminen on kuitenkin erittäin epätaloudellista, sillä  peräkkäiset
kuvat sisältävät usein samaa informaatiota -> lähetetään esim. vain muuttunut informaatio, säästetään
tiedonsiirtokapasiteettia (häviötön pakkaus). Lisäksi ihmisen havaitsemiskyky värivaihtelun
(hue/saturation) suhteen on paljon heikompi kuin valon voimakkuuden (intensity) vaihtelun osalta ->
värinilmaisuun käytettyjä bittejä voidaan vähentää, tai yhdistetään isompia kokonaisuuksia
samanvärisiksi (häviöllinen pakkaus) [2]. Mm. näitä ominaisuuksia hyväksikäyttäen on MPEG (Moving
Pictures Experts Group <http://www.mpeg.org> ) organisaatio kehittänyt kansainvälisesti tunnustetut videon
kompressointimenetelmät MPEG-1 ja MPEG-2 (sekä tulossa oleva MPEG-4, joka on itseasiassa
'median'pakkaus menetelmä). MPEG käyttää pakkauksessa DCT-muunnosta [3]. Näillä kompressointimenetelmillä
päästään laadullisesti hyväksyttävään tulokseen
(MPEG-1 >1.5Mbit/s = vhs, MPEG-2 >2.0Mbit/s,>6.0Mbit/s = s-vhs, D-1 ), mutta ne ovat
kuitenkin nykyinternetille liian kaistasyöppöjä metodeja. Tosin paikallisesti, esim. HPY:n Helsingin
alueen multimediaverkossa tai yrityksen sisäisessä lähiverkossa, tälläisia nopeuksia päästään
käyttämään.

Yleisesti  kotikäyttäjälle suunnatussa materiaalissa voidaan kuitenkin internetin nykyisenä kaistarajana
pitää ISDN:n kahta B-kanavaa (128kbit/s) ja oletusarvona normaalia modeminopeutta 28.8kbit/s.
Näin kapeaan kaistaan hyvälaatuisen videokuvan mahduttaminen on nykyään tiedossa olevilla keinoilla
mahdotonta. Yleisesti käytössä olevissa sovelluksissa on kuvanopeus per sekunti näillä kaistoilla
laskettu viitentoista (tai alemmas) kahdenkymmenenneljän kuvan asemasta per sekunti. Käytetyt
pakkausmenetelmät ovat usein hyvin eksoottisia (wavelet- ja fraktaalikoodaus) ja standareista
poikkeavia. Tällä hetkellä ainoa low-bitrate videon enkoodaus standardi on
ITUn H.263.  H.263 käyttää tiedon pakkaamiseen DCT-muunnosta [4]. Kuitenkin vain
yksi tunnetuimmista videon välitykseen tehdyistä sovelluksista käyttää
ainoastaan tätä koodaustapaa internet-nopeuksilla (14.4-128kbit/s). Empiirisissä kokeissa voi
kuitenkin todeta, että standardin mukainen koodekki jää laadullisesti ei-standardien koodekkien
jalkoihin [5]. Käytettäessä ei-standardeja koodekkeja vaaditaan tietenkin ei-standardin koodekin tehneen
yhtiön client-sovellus voidakseen katsella tällä tavalla koodattuja videopätkiä. Ja jos sattumalta joku
yhtiö pääsisi omalla koodekillaan de-facto standardin asemaan internetin videokuvan välityksessä....  eli
standardoidun koodekin jäykkyys -> huonous ei ole välttämättä ainoa syy eri yhtiöiden intoon
implementoida omia ratkaisuja low-bitrate videokoodekeiksi. MPEG siirron vaatiman kaistan tuominen
kaikille internetin käyttäjille on kuitenkin vielä useamman vuoden päässä. Näitä softakohtaisia asioita
käsitellään enemmän osassa 3., sovellukset.
Internetin hitaille tiedonsiirtoyhteyksille täytyy kuvainformaatiota karsia rankalla kädellä, jolloin tulos
näkyy laadussa. Koska painetta videokuvan siirtoon kuitenkin on, uusia pakkausmenetelmiä kehitetään
jatkuvasti ja vanhoja parannellaan sitäkin innokkaammin.
Tämän hetken tilanteen valossa ei ole kuitenkaan odotettavissa, että alle 128kbit/s käyttäville
tiedonsiirtoyhteyksille ei saada edes välttävän tasoista (vhs) videokuvaa välittävää koodausmenetelmää.
 

Osa 2, yhteydettömän verkon ongelma

Internet Protocol versio4 ei takaa minkäänlaista tiedonsiirtokapasiteettia kahden pisteen välille.
Videokuvan siirto vaatii tasaisen kaistan ja melko virheettömän yhteyden, puskureiden koosta riipuen,
eli IPv4 on vihoviimeinen protokolla, jonka päällä streamingvideota pitäisi siirtää. Yhteydettömyyden
ongelmaa voidaan korjata myös puskuroinnilla, mutta puskurin kokoa ei voida käyttömukavuuden
takia rajattomasti kasvattaa. Lisäksi TCP:n käyttäminen IP:n päällä aiheuttaa turhia uudelleen
lähetyksiä, koska myöhässä saapunutta videoframea ei voida jälkeenpäin käyttää, eli videostreaming
on erittäin aikakriittistä verkkoyhteyden kannalta. (Tämä riippuu tietenkin vastaanottopään bufferin
suuruudesta). Tämän takia videostreaming sovelluksissa käytetäänkin usein UDP:tä IP:n päällä, koska
UDP ei välitä hukkuneista paketeista, vaan ottaa saapuvia paketteja vastaan riippumatta siitä, puuttuko
välistä muutama paketti. Monet uusimmista sovelluksista käyttävät lisäksi RTP:tä UDP/IP:n päällä
datapakettien synkronointiin, jolloin mahdollistetaan bufferointi. RTP on realiaikasovelluksille tarkoitettu
siirtoprotokolla, jonka kontrolliprotokollana toimii RTCP. UDP-lähetyksissä ongelmaksi muodostuvat
palomuurit, jotka sallivat usein yhteyden 'ulkomaailmaan' vain tiettyjen porttien kautta. Tällöin video jää
joko kokonaan näkemättä tai sitten video-sovellus voi ajaa esim. http:tä TCP/IP:n päällä, jolloin
palomuuri ohitetaan näppärästi, käyttämällä tunnettua porttia. Mutta samalla menetetään UDP/IP:n
tuoma nopeusetu ja hukutaan overheadeihin ja uudelleen lähetyksiin.

Video-sovellusten tekijät ovat kuitenkin lähteneet protokolla-tasollakin rakentelemaan omia virityksiä
yhteyden laadun parantamiseksi. Varteenotettavin 'oma-viritys' on RealNetworksin RTSP
(RealTime Streaming Protocol), joka kulkee RTP:n päällä ja josta on jätetty standardoimis ehdous
IETF:lle lokakuussa –96 [6]. Myös Microsoftilla on 'oma' streamaavaa mediaa tukeva Active Streaming
Formaattinsa (*.asf), joka ei ole pelkästään protokolla, vaan pikemminkin streamattava
mediakehys, jonka sisään voidaan laittaa mitä tahansa mediaelementtejä [7].

Ratkaisu IP-yhteyden laadun takaamiseen häämöttää kuitenkin lähitulevaisuudessa IPv6-standardin
muodossa. Tähän uuteen Internet Protokollaan sisällytetään jonkinasteinen Qos(Quality of Service)
parametri, jolla saadaan helpotusta nykyään vallitsevaan toivottomaan tilanteeseen. Toivottomaksi
tilannetta voi kuvailla siksi, että edes lisäkapasiteetin rakentaminen ei välttämättä auta asiaa, sillä miten
voidaan yhteydettömässä verkossa IPv4:n avulla saavutettu lisäkapasiteetti allokoida juuri kyseiselle
videoyhteydelle ? Lisäksi tulevaisuudessa videokuvansiiron lisääntyessä ja multicastin
mahdollistaessa todelliset broadcast-mahdollisuudet, jäljelle jää kysymys missä vaiheessa ja miten
aletaan veloittaa reitittimien läpi kulkevia MPEG tai muita video-streameja. Multicast mahdollistaa yhdeltä
valitulle joukolle suunnatut lähetykset [8].
 
 

Osa 3, sovellukset

Tässä osassa käsitellään videokuvan välitykseen tehtyjä ohjelmia. Verkossa voidaan välittää kahden
tyyppisiä videostreameja; on-demand -lähetys ja live -stream. On-demandilla tarkoitetaan esim.
uutispalvelua, jossa katsoja voi käynnistää uutisten katselun haluamanaan ajankohtana, eli datan siirto
alkaa katselijan aloitteesta. Tällöin katselijalla on usein myös mahdollisuus kelata tai pysäyttää lähetys,
eli käyttö muistuttaa videofilmin katselua nauhurilta. Live-lähetys taas on suoraan verrattavissa
normaaliin uutislähetykseen, jolloin katsoja liittyy haluamalleen kanavalle, jossa lähetys on käynnissä,
voimatta pysäyttää tai kelata lähetystä.

Ohjelmistoratkaisut voidaan jakaa kahteen päätyyppiin; server-based ja serverless -softat. Edellinen on
palvelin-asiakas tyyppinen ratkaisu, jossa videostreamit lähetetään palvelimelta katselijalle, jolloin
videopalvelin voi sijaita fyysisesti eri paikassa kuin www-palvelin josta linkit videostreameihin löytyvät.
Serverless ratkaisussa videon streamaus tapahtuu suoraan www-palvelimelta. Nämä streamit tulevat
siis http-protokollaa käyttäen, jolloin videokuva tulee katselijalle asti, jos hänen selaimensa on näyttänyt
sen web-sivun jolta videon katselu käynnistettiin. Tällä tavalla voidaan siis ohittaa osassa 2 todettu
palomuurien ongelma. Ratkaisujen paremmuuden sanelee käyttötarkoitus. Karkeasti ottaen serverless
vaihtoehto sopii pienimuotoisiin esim. omalle kotisivulle laitettujen videopätkien esittämiseen, jos
pidetään lisäksi todennäköisenä, että kovin moni ihminen ei yritä katsella videota yhtä aikaa.
Server-based streaming kokonaisuus on tarkoitettu 'yleiradiomaisempaan' jakeluun, jolloin on
oletettavissa että katselijoita on useampia ja halutaan jotenkin kontrolloida lähetysiä yleensä esim. mistä
IP-osoiteavaruudesta tulleita pyyntöjä suostutaan palvelemaan.
Lisäksi kaupallisuuden lisääntyessä server-based ratkaisuihin on alettu sisällyttää esim.
laskutusominaisuuksia, eli ken katsoo, se maksaa. Televisiomaisuus on muutenkin kovasti tulossa, sillä
ainakin RealNetworks ja Microsoft tarjoavat streamingserveri tuotteissaan kanava-palvelua, eli kaikki
live- (ja/tai on-demand) lähetykset pyritään kiinnitämään tiettyyn multicast-osoitteeseen, jolle
konfiguroidaan oma 'kanava' [9, 10]. Client-softa hakee käynnistyessään tiedon kanavista, jolloin katselijan
tehtäväksi jää vain valita mielenkiintoinen lähetys. Ennenhän piti aina ensin löytää web-sivu, jolta oli
sitten linkki lähetettävään videostreamiin. Tämä trendi on myös verkkkokapasiteettia säästävää sillä
'aidot' on-demand lähetykset joudutaan lähettämään unicastina.

Erilaisia sovelluksia videon streamaukseen on kymmeniä. Suurin osa internetistä löytyvästä
streamattavasta materiaalista on kuitenkin muutaman hallitsevan ohjelmistovalmistajan tuotteille tehtyä.
Tällä hetkellä low-bitrate puolella kärkinimet ovat verkosta löytyvän materiaalin määrän perusteella
[kts. lopussa oleva liite 1]; RealVideo ,  NetShow, VDOLive ja VivoActive . Näistä ensimmäiset
kolme ovat serveri pohjaisia tuotteita [9,10,11] ja vain VivoActive on serverless ratkaisu [12]. Serverless
tuotteiden olemassaolo tulleekin tulevaisuudessa nojautumaan yksityisten ihmisten ja pienten yritysten
käyttöhalukkuuteen. Tosin joillain internet-palveluntarjoajilla on jo joku videoserveri-softa jo olemassa,
ja asiakkaita kannustetaan varmaankin käyttämään tämän valmistajan sovellusta. Lisäksi 'pienkäyttäjät'
eivät ole yleensä valmiita maksamaan tälläisistä softista, vaan ottavat ISP:n tarjoaman ratkaisun
vastaan, koska se sisältyy palvelun hintaan. Nähtäväksi jääkin, kuinka pitkään serverless-sovellukset
tulevat sinnittelemään kuvioissa mukana.
Toisen kokonaisuuden muodostavat high-bitrate sovallukset, jotka on tarkoitettu yli 1,5megabitin
kaistoille, eli vhs-tasoisen ja sitä paremman kuvamateriaalin välitykseen. Näillä videoservereillä
tarkoitetaan pääasiassa laitteisto-ohjelmisto kokonaisuuksia, joissa tehokkaaseen RAID-levyillä
varustettuun tietokoneeseen on asennettu videopalvelinohjelmisto. Esimerkkinä videonsiirtoon
tarkoitetusta palvelimesta voi mainita vaikka SGI:n mediabasen [13]. Saatavilla on myös software-only
ratkaisuja, joissa videopalvelin ohjelmisto asennetaan mihin tahansa riittävän tehokkaaseen ja
muutenkin tähän käyttöön soveltuvaan oikeanlaisen käyttöjärjestelmän omaavaan koneeseen.
Esimerkiksi NetShowFullScreen ja XingStreamworks ovat tällaisia tuotteita [14, 15]. Suorituskyvyn
vertailussa software-only ratkaisut jäävät tietenkin hopealle, mutta täytyy muistaa että hinnaltaan ne
ovat n. 20-50% vastaavista laitteistopohjaisista ratkaisuista. Käyttötarkoitus sanelee ratkaisun.
Laajakaistaverkon tilausvideokokeiluun kannattanee tuskin valita Streamworksia, mutta tuskinpa
kukaan yrityksen lähiverkkoon autokerhon teemapäivä videota varten Mediabasea alkaa hankkimaan.
Nämä laajakaistasovellukset eivät ole kuitenkaan internetin kannalta merkitseviä, mutta kun lokaaleja
broadband-saarekkeita ja niitä yhditäviä linkkejä alkaa löytymään, alkaa näillä high-end sovelluksillakin
olla kysyntää. Kysyntää on kuitenkin turha odottaa tavallisten kuluttajien taholta ennenkuin sisältöä
löytyy, koska laajakaistainen siirto maksaa eri tavalla kuin modeemin käyttely puhelinlinjan avulla.
 

LÄHDELUETTELO

[1] CCIR601 standardin kuvaus, 8.11.1996
      <http://nebo.cs.byu.edu/~scoville/luigi/ccir601.html>
      ***

[2] MORE ABOUT WHAT VISION DOES, 28.6.1997
      <http://isd.saginaw.k12.mi.us/~mobility/vsionsys.html>
      ***

[3] MPEG Compression Algorithm, 19.1. 1995
      <http://icsl.ee.washington.edu/~woobin/papers/General/node2.html>
      ****

[4] H.263 Video Coding, 4.4.1997
      <http://www-mobile.ecs.soton.ac.uk/peter/h263/h263.html>
      ***

[5] VOLVO Algorithm, 15.3.1997
      <http://www.bk.isy.liu.se/~haibo/research/volvo.html>
      **

[6] RTSP, 11.10.1997
      <http://www.real.com/rtsp/index.html>
      *****

[7] ASF, 30.6.1997
      <http://www.eu.microsoft.com/netshow/about/whtepprs/asf-wp.htm#1.0>
      ****

[8] Multicast Routing, 6.6.1997
     <http://www.cisco.com/warp/public/614/17.html>
     ***

LISÄTIETOA SOVELLUKSISTA

[9] RealVideo, kotisivut, 30.10.1997
        <http://www.real.com>
  ****

[10] Microsoft, kotisivut, 7.11.1997
       <http://www.eu.microsoft.com/netshow/>
  ****

[11] VDOLive, kotisivut, 8.9.1997
        <http://www.vdo.net>
  ***
[12] VivoActiven, kotisivut, 16.8.1997
        <http://www.vivo.com/>
***

[13] SGI, kotisivut, 17.9.1997
        <http://www.sgi.com>
***

[14] Microsoft Fullscreen, 7.11.1997
        <http://www.eu.microsoft.com/netshow/theater/>
****

[15] Xing, kotisivut, 25.9.1997
       <http://www.xingtech.com/>
  ***
 

Liite 1.
Sähköposti RealNetworksin työntekijältä. Kyseessä on vain yhden tuotteen edustajan
näkemys, mutta myös henkilökohtainen näkemykseni on että tällä hetkellä RealNetworks on
internet-streamingin (<500kbit/s) markkinajohtaja.
 
Our market share at the moment with streaming technology is as follows:
Of all the streaming content on the WWW approx:
78% is RealAudio
11% is RealVideo
4% is Netshow
2% is VDO
3% is Vivo
1% is Vxtreme
1% is Xing