PROGRAMMERING AV INTERAKTIV VIDEO

Espen S. Ore

Siden våren 1989 har undertegnede samarbeidet med forsker Signe Marie Sanne ved Senteret om utviklingen av interaktive videosystemer for språkundervisning på universitetsnivå. Tidligere har vi ved Senteret også arbeidet med koblinger mellom referansedatabaser og videoplater med stillbilder. I denne artikkelen vil jeg gjøre rede for erfaringer med enkelte programmeringsverktøy og maskinkonfigurasjoner.
En arbeidsstasjon for interaktiv video består av en videoplatespiller og en datamaskin som er koblet sammen med en seriekabel og skjerm(er) til visning av video og datatekst og -grafikk. (Det finnes også andre løsninger, f.eks. strekkodeleser og videospiller, men her har Senteret liten erfaring, og de vil ikke bli omtalt i denne artikkelen.) Fra datamaskinen sendes kommandoer til videoplatespilleren over seriekabelen. Kommandoene sendes som klartekst (ASCII), og kommandosettene er forskjellige for de forskjellige spillerne.

ÉNSKJERMS- ELLER TOSKJERMSLØSNING?

Det skjelnes gjerne mellom énskjerms- og toskjermsløsninger. I toskjermsløsningene er det én skjerm (monitor) for videobildene og én for datatekst og -grafikk. Dette er som regel de rimeligste løsningene, fordi man kan bruke vanlig videomonitor og dataskjerm. Énskjermsløsningene kan igjen deles i to: de som legger datagrafikken ut på et videobilde og de som digitaliserer videobildet inn på dataskjermbildet. Dette siste er som regel dyrest, men det gir best kvalitet. Velger man en énskjermsløsning trenger man ekstrautstyr (utvidelseskort) til datamaskinen som blander video- og datasignalet og synkroniserer disse.
Hvorvidt det er best med én eller to skjermer, er i stor grad avhengig av hva man skal bruke det hele til. Det er likevel vår erfaring at spesielt i undervisning virker to skjermer ofte forvirrende. Enten vil brukeren konsentrere seg om videobildet eller om den skjermen som inneholder signalene fra datamaskinen. Det er imidlertid situasjoner der det er ønskelig med to skjermer.
Bildet på skjermen dannes ved at en elektronstråle sveiper over den linje for linje. Et vanlig video/fjernsynsbilde er satt sammen av to halvbilder. Det ene består av skjermlinjene 1, 3, 5, 7 osv., det andre av linjene 2, 4, 6 osv. De to halvbildene vises etter hverandre slik at ett helt bilde blir vist hvert 25dels sekund. Dette virker vanligvis utmerket, men hvis man legger datagrafikk ut på et slikt bilde, kan det oppstå problemer. Dersom datamaskinen tegner en vannrett strek som er akkurat én skjermlinje bred, vil den bare være med på halvparten av halvbildene, og vi vil se tydelig flimring på skjermen. Dette er spesielt merkbart hvis man bruker en Macintosh, siden det aktive skjermvinduet på denne maskinen har åtte parallelle vannrette streker øverst. Det må understrekes at dette problemet bare oppstår der man legger datagrafikken ut på et (vanlig) videobilde. Velger man en løsning der videobildet hentes inn på dataskjermen (jfr. ovenfor), er det ingen problemer.

HVILKEN PLATESPILLER TRENGER MAN?

Det brukes idag tre forskjellige fjernsynsstandarder. Det er to av disse, PAL (Europa) og NTSC (Nordamerika/Japan) som det er mest aktuelt å ta hensyn til. En overvekt av de kommersielt tilgjengelige videoplatene er laget i NTSC-standard. De fleste videoplatespillerne har modeller som er laget enten for PAL eller NTSC, men det har etterhvert kommet på markedet spillere som kan ta begge standarder. Her må man også tenke på resten av utstyret som skal brukes. Et vanlig fjernsyn innkjøpt i Norge kan være en rimelig videomonitor, men det vil som regel ikke kunne vise NTSC. Enkelte av utvidelseskortene til datamaskinen som må brukes i en énskjermsløsning, er også laget slik at de enten tar NTSC eller PAL.

Å SKAFFE SEG PLATER

Idealet er for mange å presse sin egen plate slik at materialet er spesialtilpasset den applikasjonen man ønsker å lage. Dette kan bli et stort prosjekt der omkostningene ved selve pressingen utgjør en liten del av totalkostnadene. I tillegg kommer behovet for fotografi/film/videokompetanse, eventuelle utgifter til skuespillere, redigering osv. Mange velger derfor gjenbruk (repurposing) av eksisterende plater.
Hvis man kjøper kommersielt tilgjengelige plater, må man, bortsett fra spørsmålet om NTSC eller PAL standard, også være klar over at de fleste tilgjengelige filmplater er i CLV-format. (CLV = Constant Linear Velocity) Dette formatet tillater produsenten å legge flere bilder (dvs. lengre spilletid) inn på hver plateside. Imidlertid er det stort sett uegnet til interaktiv video siden det normalt ikke tillater full kontroll over platen. Til bruk i interaktiv video må platen være i CAV-format (Constant Angular Velocity).

HVORLEDES KOMME I GANG?

En første, nødvendig forutsetning for interaktiv video er at man har kontakt mellom datamaskinen og videospilleren slik at det er mulig å sende kommandoer til spilleren. Dette er ikke alltid like enkelt. RS232C er sannsynligvis en av verdens minst standardiserte standarder. Dette betyr at en seriekabel som virker på én videospiller ikke nødvendigvis virker på en annen. En teknisk referansehåndbok for den eller de spillerne som skal brukes, er derfor nødvendig, men det hender at den selges som (dyrt) ekstrautstyr. Spillerne må også være stilt inn på riktig kommunikasjonshastighet. Dette gjøres ved å stille små brytere (dip-switches) som i ekstreme tilfeller befinner seg dypt inne i spillerens indre. En god hjelp under kabeltilpasningen er et vanlig kommunikasjonsprogram, f.eks. Kermit. Med det kan man sette opp et terminalvindu mot spilleren, prøve å sende kommandoer og se om man får fornuftige svar.

PROGRAMMER SOM STYRER VIDEOPLATESPILLEREN

For i det hele tatt å lage en interaktiv videopresentasjon, må vi kjenne videoplaten (selvfølgelig). Det betyr at vi må vite hvor på platen de forskjellige sekvenser og enkeltbilder vi ønsker å bruke, befinner seg. Vi må også vite om det er aktuelt å bruke begge, bare én eller ingen av lydkanalene. Platene har nemlig to lydkanaler. Dette var opprinnelig beregnet på stereolyd, men det finnes plater der innholdet i de to lydkanalene er vidt forskjellig. En plate Senteret eier, har tysk tale på det ene lydsporet og engelsk på det andre. Slike faktorer gir muligheter for "dobbelt" utnyttelse av platene idet samme videosekvens kan spilles med bruk av forskjellige lydspor.
Som nevnt ovenfor styres spillerne ved at forskjellige kommandostrenger sendes over en seriekabel. Blant de grunnleggende kommandoene som trenges for en interaktiv videoapplikasjon er:

- gå til bilde nummer x
- spill til bilde nummer y
- slå av/på lydkanal 1
- slå av/på lydkanal 2

Dessuten er det viktig å kunne finne ut hvor på platen man egentlig er, dvs. at forespørselen "Hvor er vi?" må kunne sendes til spilleren og et svar komme tilbake. Dette hadde vi ved Senteret enkelte problemer med i forbindelse med en eldre platespiller. Problemet kan omgås ved at programmet som styrer spilleren fører nøye regnskap med hvor lang tid det har gått fra spilleren startet å spille fra et kjent bildenummer.
Dessverre bruker spillerne forskjellige kommandosett. Sonys LDP-serie spillere bruker for eksempel kommandoen "F" til å slå på lydkanal 1, mens en Pioneer 4200 spiller bruker kommandoen "1 AD" til det samme. For at det i det hele tatt skal være mulig å bruke det samme programmet med forskjellige videospillere, er det viktig å holde de spillerspesifikke kommandoene ute fra den generelle delen av programmet. Dette kan gjøres ved at man skriver en gruppe rutiner som er spesifikke for hver spiller (en "driver" for hvert kommandosett). I hovedprogrammet sørger man så for at det på ett sted (gjerne i begynnelsen) blir definert hvilken driver (dvs. hvilken spiller) som er aktiv. Dette er i praksis også det som blir gjort i ferdige forfatterverktøy for interaktiv video.

FORFATTERVERKTØY ELLER "EGEN PROGRAMMERING"?

Et forfatterverktøy er et program eller en gruppe av programmer som skal gjøre det lett for en ikke-programmerer å programmere. Det er vanskelig å trekke noen absolutt grense mellom et generelt programmeringsspråk og et forfatterverktøy, og det har kanskje heller ingen hensikt. Undertegnede har hatt visse problemer med "rene" forfatterverktøy som Quest og Icon Author. Hvis man ønsker å gjøre programmeringen lettvint, blir de ferdige produktene lett presset inn i en form som tilsvarer den formen utviklerne av forfatterverktøyet har som ideal. Hvis man ønsker å sprenge grensene, å lage noe helt etter sitt eget hode, blir det lett mye tukling med et knotete "forfatterspråk", og programmeringen hadde sannsynligvis gått vel så greit (og blitt bedre) om det hele var skrevet i f.eks. Pascal fra bunnen av. (NB! Dette er undertegnedes høyst personlige oppfatning og deles ikke nødvendigvis av andre som har arbeidet med interaktiv video ved Senteret. NB!)
Når det gjelder verktøy som HyperCard (med slektninger) stiller saken seg anderledes. Her er det også til en viss grad faste former - det skal f.eks. svært meget til for å få en HyperCard stakk (kortbunke er Apple Norges offisielle term) til å se ut som noe annet enn en HyperCard stakk. Men på den andre siden er programmeringsmulighetene her så utrolig mye bedre enn i de rene forfatterverktøyene. Det har nå også kommet tilsvarende verktøy på MS-DOS siden (ToolBook under Windows), og jeg tror det store flertall av fremtidens (dvs. de neste par års) interaktive videoprodukter vil være laget med slike verktøy.
De ovenfor omtalte verktøyene gir gratis en god del i form av forhåndsdefinerte rutiner til å behandle lyd og bilder og ikke minst pekeverktøy (mus). Dette står for meg som den viktigste grunnen til at det blir slike utviklingsomgivelser og ikke ren programmering som blir mest aktuelt fremover. Et verktøy som ikke er omtalt her, er det norskutviklede Mosaikk. Grunnen til dette er at da det var aktuelt å bruke det ved Senteret (høsten 1989), var Mosaikk inne i en utvikling som gjorde det umulig å få tilgang på den nødvendige dokumentasjon. Det kan imidlertid bli aktuelt å ta det opp igjen senere.

PROSJEKT SATYRICON

Signe Marie Sanne omtaler de pedagogiske aspektene ved dette prosjektet et annet sted i dette nummer av HD. Her vil jeg istedet komme litt inn på valg av teknologi, programmeringsverktøy og datastrukturer.
Prosjekt Satyricon er en énskjermsløsning der video og datagrafikk blir vist på en vanlig Apple fargemonitor. Utvidelseskortene som brukes (ColorSpace IIc/ColorSpace FX) tillater at videoen blir vist i fulle farger (24 bit pr. skjermpunkt/pixel) selv om datagrafikken bare blir vist som 8 bits farger. Disse utvidelseskortene tillater oss også å manipulere videovinduet i sanntid. Det vil si at det kan flyttes, forminskes og forstørres mens videoen spiller. (Kortene tillater også andre "festlige" manipulasjoner som å invertere fargene i videobildet, speile bildet osv., men det har vi ikke funnet noen anvendelse for i denne forbindelse.) Satyricon (platen) følger amerikansk standard (NTSC) og vi bruker for tiden en Sony kombinertspiller.
Som utviklingsverktøy har vi valgt SuperCard. Litt forenklet er SuperCard et overbygg på HyperCard. Blant det som går utover HyperCard, kan nevnes at SuperCard tillater at flere vinduer i forskjellig størrelse er åpne samtidig, bruk av farger, muligheten til å lage egne menyer og bruk av "standard" Macintosh vinduer. Alt er imidlertid ikke bare rosenrødt med SuperCard. Hvis man ønsker å utvikle og testkjøre samtidig bør man ikke satse på å ha mindre enn 4 MB RAM i maskinen. HyperCard har i alle fall hittil blitt gitt gratis med maskinen. Derfor har man alltid kunnet regne med at der det finnes en Macintosh, finner man også en kopi av HyperCard. Imidlertid er ikke dette noe stort problem, siden det er mulig å lage frittstående programmer av SuperCard-prosjektene.
Det var videodriverne som skapte de største problemene for oss i begynnelsen. Senteret har tidligere anskaffet Videodisc Toolbox - et sett med programvare og drivere for bruk sammen med HyperCard - fra APDA (Apple Programmers' and Developers' Association). I teorien skal eksterne kommandoer og funksjoner for HyperCard kunne konverteres til SuperCard. Utviklerne av SuperCard har dessverre valgt en ikke helt standard måte å håndtere disse eksterne funksjonene på. Dette er ikke stedet for å diskutere de mer intrikate delene av Macintosh-systemets ressurshåndtering, men for den Mac-kyndige kan jeg si at problemet vesentlig skyldes at SuperCard lagrer koderessursene i et prosjekts datagren og ikke i ressursgrenen. Vi kunne heldigvis bruke deler av programmene fra APDA: de som direkte styrer kommunikasjonen over serieporten. Selve videodriveren (altså den spillerspesifikke delen) skrev vi så i SuperTalk (SuperCards svar på HyperTalk). Hittil har prosjektet bare brukt en Sony-spiller, så vi har ikke prøvd hvor lett eller vanskelig det er å legge inn en ny driver, men ut fra tidligere erfaringer virker det ikke spesielt komplisert.
Prosjekt Satyricon er forskjellig fra mange produksjoner av interaktiv video idet det her skal være mulig når som helst under visningen av video å stoppe denne, få frem italiensk tekst, lese norsk oversettelse osv. Oftere er det slik at brukeren stilles overfor et valg, som et resultat av dette valget vises en videosekvens, og brukeren får muligheten til å gjøre et nytt valg. Dette er den modellen de fleste forfatterverktøy legger opp til. Sannes valg av interaksjonsmodell har nødvendigvis påvirket valget av datastrukturer.
Videomaterialet som benyttes, er delt opp i ti sekvenser. Disse er i det store og hele uavhengige av hverandre, og det er naturlig å se på hver av dem som en enhet. Sekvensene er igjen delt opp i språklig betingede enheter som for eksempel en setning. Dette er de minste videoenhetene, og det er disse det refereres til når brukeren får anledning til å se om igjen eller få en norsk oversettelse.
For å ivareta den nødvendige informasjon definerte vi skjulte referansekort (se fig. 1), ett for hver av de ti hovedsekvensene. I disse kortene er det felt for italiensk tekst, norsk tekst, start- og stoppbilde for de minste språkenhetene og start- og stoppbilde for hovedsekvensen. Når brukeren har valgt en sekvens fra valgkortet (se Sannes artikkel), lagres informasjon om hva som nå er gyldig referansekort. Når brukeren kommer til valgkortet første gang, er alltid første sekvens valgt som standardverdi. Det skal ikke være mulig å starte videovisning uten at det er valgt en gyldig sekvens. Dette er en forutsetning som hele systemets programlogikk bygger på.
Referansekortene ble laget ved at Sanne transkriberte og oversatte den italienske teksten samtidig som hun noterte informasjon om start- og stoppbilder. Dette ble gjort i et vanlig tekstbehandlingsprogram. Deretter ble tekstene lest inn i referansekort med hjelp av et lite program som skjuler seg bak knappen "Lagny" i fig. 1. Ordboken ble også fremstilt halvautomatisk. Et lite program plukket ut alle ord i den italienske teksten og lagret dem sammen med tekstlinjen de var plukket fra, opplysninger om hvilket referansekort de var hentet fra og hvilken linje i kortfeltene de kom fra. Deretter ble de sortert og til slutt etterredigert for hånd. Denne fremgangsmåten var mulig nettopp fordi SuperTalk (og HyperTalk) er så generelle programmeringsspråk at undertegnede kunne hente frem sine gamle algoritmer for ordboksproduksjon og "oversette" dem fra Pascal eller Simula.
Vi har hele tiden hatt for øye å utvikle et program som er mest mulig generelt. Derfor kan deler av programvaren i Prosjekt Satyricon benyttes til annet videomateriale uten særlig ny programmering, forutsatt at vi ikke ønsker et vesentlig forskjellig pedagogisk opplegg.

Figur 1.