Sammendrag. Tittel: livenetconcept. Dato: Forfatter: Anders Gimmestad Gule, Joachim Øyre. Veileder: Høgskolelektor Monica Strand

Transkript

1 Sammendrag Tittel: livenetconcept Dato: Forfatter: Anders Gimmestad Gule, Joachim Øyre Veileder: Høgskolelektor Monica Strand Oppdragsgiver: NM på ski 2009 Kontaktperson: Erik Røste Nøkkelord: NM 2009, flerkamera streaming, web-applikasjon Antall sider: 89 Antall vedlegg: 11 Tilgjengelighet: Åpen Sammendrag: Prosjektet er gjennomført på Høgskolen i Gjøvik med NM på ski 2009 som oppdragsgivere og Monica Strand som veileder. Vi har laget en webapplikasjon som skal brukes under NM Vårt mål med dette prosjektet var å lage virtuell tilstedeværelse for alle brukere av systemet. At de som ikke var i løypene og fulgte med kunne heller sitte hjemme på datamaskinen å føle enn viss tilstedeværelse. Måten vi tenkte å løse dette på var å streame kameraene som var på arenaen ut til brukere av systemet. Her kan de da være sin egen produsent i den forstand at de kan velge hvilket kamera de vil følge med på, som om de gikk rundt fra den ene tidspasseringen til den andre på selve arrangementet. Og når de har valgt et kamera, så kan de prate med alle andre brukere som «står» på samme sted som dem selv ved hjelp av en chat. Hver kanal har en egen chat der du kan prate med de som er på den samme kanalen som deg. Det skal representere de du hadde stått ved siden av dersom du hadde vært tilstede fysisk. side 1

2 side 2

3 side 3

4 side 4

5 Forord Som avslutning på den treårige bachelorutdanningen ved Høgskolen i Gjøvik skal alle studentene gjøre et større, selvstendig prosjekt, bacheloroppgaven. Disse oppgavene kommer gjerne fra eksterne bedrifter eller fra høgskolen selv. Under en hovedoppgave skal det tas utgangspunkt i en realistisk og faglig problemstilling. Den skal legges opp slik at kunnskap og ferdigheter fra flere fagområder benyttes. Etter fullført oppgave skal studentene ha kompetanse til å: - utføre en større selvstendig oppgave av tverrfaglig og vitenskapelig art. - planlegge, finne løsninger og dokumentere disse. - forstå fordeler og ulemper med arbeid i grupper. - forstå viktigheten av god planlegging og oppfølging. - vurdere alternative arbeidsformer, deriblant en metode- og problemorientert måte. Oppgaven vi har arbeidet med omhandler publisering av streaming på nett, nærmere bestemt flerkanals live-streaming. Konseptet er utarbeidet i samarbeid med Organisasjonskomitéen NM på ski 2009 der Tron Ragnar Strand og Erik Røste har vært våre kontaktpersoner. Vi vil takke de for et konstruktiv og godt samarbeid gjennom prosjektperioden. En takk går også til Kent Are Andersen for at han ville dele sin erfaring med VLC-streaming, videre også til Einar Jørgen Haraldseid for utlån av hans rapport fra FirstLegoLeague 2007 og testgruppen vår Vlad Caia og Per Christian Utheim. Til slutt vil vi takke vår veileder Monica Strand for gode og konstruktive tilbakemeldinger gjennom prosjektperioden. Joachim Øyre Anders Gimmestad Gule side 5

6 side 6

7 Innholdsfortegnelse: 1 Introduksjon3 1.1 Idé og konsept3 1.2 Oppdragsgiver3 2 Problemstilling5 2.1 Mål5 2.2 Problemstilling5 2.3 Fremgangsmåte/metodevalg6 3 Analyse av problemstillingen9 3.1 Dokumentasjon9 3.2 Mulige løsninger9 4 Utviklingsmiljø Plattform11 5 Streaming Hva er streaming? Valg av format og protokoll Implementasjon Live streaming Testing Problemer Løsninger Konklusjon25 6 Web-applikasjon Løsninger Arkitektur Databasen Moduler Sikkerhet Design Konklusjon40 7 Testing Testing av stream Testing av webapplikasjonene43 8 Oppsummering Evaluering av prosjektarbeidet Evaluering av produktet Videre arbeid47 9 Vedlegg49 side 1

8 side 2

9 1 Introduksjon 1.1 Idé og konsept Vi valgte å basere bacheloroppgaven vår på et prosjekt vi gjennomførte i «Fordypning i Medieteknikk» høsten Det var et selvvalgt prosjekt hvor vi utforsket mulighetene for å utvikle et konsept som kunne gi brukere muligheten til å «være tilstede, uten å fysisk være tilstede». Dette innebar live-streaming av parallelle kanaler og live-kommunikasjon mellom brukerne. Prosjektet ble i utgangspunktet utviklet med en konsert som case, men under arbeidet valgte vi å bruke en «universal» tilnærming for å kunne bruke løsningen i mer generelle sammenhenger også. Prosjektet i forrige semester gav oss mange gode idéer, som vi i år vil videreføre til et forhåpentligvis høyere nivå. Idéen er å lage et system som skal brukes under NM på ski 2009 i månedsskiftet januar/februar. Ved hjelp av dette systemet skal man kunne se de ulike ski-grenene via vår web-applikasjon. Applikasjonen skal streame flere kameravinkler parallellt slik at brukerne skal kunne velge kameravinkelen selv. Der de også skal kunne kommunisere med andre brukere som ser på samme stream. Vi har startet et samarbeid med NM ski 2009 organisasjonskomiteen som igjen har tett kontakt med NRK, som vi håper stiller seg positiv til å gi oss kamerasignaler. 1.2 Oppdragsgiver Vår oppdragsgiver i dette prosjektet er Organisasjonskomitéen for NM på ski NM på ski 2009 blir arrangert på Gjøvik og Raufoss der studenter ved Høgskolen i Gjøvik har fått oppdraget å utvikle nettløsningen for arrangementet. Nettløsningen vil inneholde skreddersydde løsninger som eksempelvis tidtakings- og kartfunksjonalitet. Organisasjonskomitéen så også positivt på å bli vår oppdragsgiver etter forespørsel og framlegg av konseptet vårt. De ville også at konseptet skulle bakes inn i web-løsningen de andre prosjektene studenter fra Høgskolen i Gjøvik skulle utvikle. side 3

10 side 4

11 2 Problemstilling 2.1 Mål Utforske mulighetene for å gjøre live-streaming med flere parallelle kanaler tilgjengelig for brukerne gjennom en web-applikasjon. Sentrale punkter: - Brukerne velger selv hvilken kameravinkel de vil se på - Kommunikasjon mellom brukere - Modulbasert systemstruktur - Streamingteknologiene skal så langt det lar seg gjøre bestå av åpen-kildekode Prosjektmål Streaming av live lyd og bilde er ingen ny teknologi, men det er derimot mindre vanlig at du kan finne flere kanaler på et og samme sted. Formålet med denne oppgaven er å utforske hvor langt dette lar seg gjøre ved bruk av fri programvare. Brukerne av det ferdige systemet skal altså ha mulighet til å være sin egen produsent og selv velge hva det vil se på. Og kommunisere med de som har valgt å se på samme kanal. Løsningsforslag til dette vil bli drøftet i pkt. «3.2 Mulige Løsninger» Effektmål Å jobbe med et så stort prosjekt, og for en såpass stort arrangement som NM, er veldig spennende. Vi vil ha som mål å bli bedre til å jobbe i store prosjekter etter endt hovedprosjekt, som å utvikle applikasjoner som har et større arbeidsområde. Et mål er å skaffe oss bedre innsikt i ulike medieteknologier som er vanlige å bruke idag, spesielt gjelder dette streaming og webprogrammering, men også praktiske problem som hvordan et kamera streames ute på lokasjon Resultatmål Det er viktig at oppdragsgiverene er tilfreds med produktet vi leverer og at det har nytteverdi. Samtidig skal systemet kunne utvides av oss eller andre, rapporten inneholder nok dokumentasjon slik det er mulig å fortsette arbeidet. Et annet mål er at systemet blir satt i bruk basert på vårt arbeid eller utvidet for å møte andre krav. 2.2 Problemstilling Som nevnt tidligere skal det lages en web-applikasjon med tilhørende streaming-løsning. Denne skal utvikles med «NM på ski 2009», som case og side 5

12 testarena. Det finnes mange måter å løse dette på, men vi skal basere oss på målene opplistet i prosjektmålene ovenfor (jf. 2.2 Mål). Noe som blant annet innebærer bruk av åpen-kildekode. Vi har satt oss det målet at vi skal ha et fungerende system når hovedprosjektet er ferdig. Dette systemet har forhåpentligvis et stort nok omfang og fungerer så godt at det kan brukes i NM Vi vil også sitte med et system som er så universalt og lett implementere at vi kan bruke det i forskjellige arrangementer der det er flerkameraproduksjon. 2.3 Fremgangsmåte/metodevalg Fase 1 Første fase bestod i stor grad av å utvikle en plattform som kunne strukturere koden i moduler som vi igjen kunne bygge løsningen vår på. Dette forutsatte at vi hadde en godt strukturert database som ikke måtte endres strukturelt sett og en kravspesifikasjon som klart definerte rammevilkårene for prosjektet (jf. Vedlegg: H Kravspesifikasjon). Det første skrittet vi tok, var å tilegne oss kunnskap om det sentrale emnet i oppgaven, nemlig streamingen. Selve konseptet med å kunne se på en stream av gangen er ikke vanskelig å utvikle på front-end siden, men når det kommer til selve streaming-teknologien møter vi utfordringer. Vi snakker om hvilke format, plattform, streaming-server, encoder 1 og protokoll 2 vi skal benytte. Alle disse variablene skulle falle på plass utfra hvilke retning prosjektet skulle ha. Etterhvert som brikkene med mulige løsninger falt på plass, rette vi blikket mot selve plattformen og strukturen rundt dette skulle kjøre på. Plattformen ble kodet i PHP som skulle gjøre det mulig å legge til/fjerne moduler. Blant disse kan vi nevne «forum», «blog», «chat» og «video». Alle disse skulle kunne kjøre uavhengig av andre moduler eller selve plattformen Fase 2 1 «encoder», algoritme som brukes til å konvertere en strøm av data til kode. 2 «protokoll», regler for overføring av data mellom to punkter i et nettverk. side 6

13 I andre fase konsentrerte vi oss om streaming og hvilke teknologier som var best egnet for oss og for brukerne. Vi testet ut flere streamingløsninger og hadde god og dårlig erfaring. Vi fant løsninger som vi valgte å arbeide videre med, men ikke alle teorier falt i like god jord praktisk. Fordi de ikke var kompatible med hverandre, brukervennlige eller kostet mye penger. Samtidig kom praktiske problemstillinger som «kan vi få kamerasignaler fra kameraene til f.eks. NRK?» også frem noe som også til en viss grad måtte tas stilling til. side 7

14 side 8

15 3 Analyse av problemstillingen 3.1 Dokumentasjon Siden problemstillingen klart forteller at vi skulle benytte oss av åpen-kildekode -teknologier under utviklingen av systemet så møtte vi problemer som den kommersielle verden ikke står ovenfor. Hele applikasjonen baseres på åpen-kildekode programvare, som betydde begrenset tilgang til dokumentasjon, liten grad av tilgjengelig support og lite data om tidligere liknende prosjekter. De kildene til kunnskap vi har hatt kommer fra relevante «forum» 1 og diskusjonstråpen-kildekodeder derfra der brukere deler sine erfaringer og diskuterer mulige løsninger på problemer. 3.2 Mulige løsninger Streaming Før vi kunne sette i gang med testingen av forskjellige streaming-løsninger måtte det kartlegges hvilke muligheter som var tilgjengelige. Fordi vi skulle konsentrere oss om åpen-kildekode ble mulige løsninger dramatisk redusert, men noen muligheter skilte seg raskt ut. Disse var VLC 2, DSS 3 og QuickTime Broadcaster 4 (herunder QTB). Spørsmålet er hvordan VLC og DSS snakker sammen siden de ikke er laget med tanke på hverandre. VLC tenkes som encoder av kamerainput, mens DSS skal være serveren. Skulle dette imidlertid ikke fungere gjør QTB seg gjeldende, dette programmet kjører kun på Mac OS X noe som ødelegger mulighetene for en gjennomført løsning med åpen-kildekode Interaksjon For at brukerne skal kunne kommunisere seg imellom må vi opprette en form for påvirkningskraft. De må kunne påvirke et resultat, diskusjon eller en mottaker for at vi skal kunne kalle det vellykket. Med denne tanken lagt til grunn fant vi to muligheter for kommunikasjon. Den ene er direkte kommunikasjon mellom brukere og den andre en form som kan ligne «en-til-mange» kommunikasjon. 1 «forum», et internett forum er en web-applikasjon for diskusjoner og brukergeneret innhold. 2 «VLC», Video Lan Client 3 «DSS», Darwin Streaming Server 4 «QuickTime Broadcaster», encoder for Mac OS X. side 9

16 For å skape direkte kommunikasjon finnes IM-løsninger 1 som chat. Det er mulig å skape en chat der vi har «en-til-en» kommunikasjon og chat som har en «mange-til-mange» løsning. Denne formen for kontakt mellom brukere skaper en sterkere følelse av deltagelse hos brukeren og det er denne kommunikasjonen vi vil utforske. På den andre siden kan vi benytte oss av «forum» prinsippene der brukerne kan poste meninger og diskutere. Samt finnes også «blogger», som har blitt veldig populære, der brukerne skriver innholdet selv. Siden vi skal opprette kommunikasjon mellom brukere er dette noen av løsningene som skal utforskes og eventuelt benyttes Praktiske løsninger Praktiske problemstillinger som fysisk plassering av kamera og trekking av kabler vil i liten grad gjøre seg gjeldende i dette prosjektet, uansett er det aktuelt å se på dem. Vi tenker på hvilke kamerasignaler vi kan få tilgjengelig om konseptet settes i gang under NM på ski 09. Det aller enkleste for er å motta et digitalt som går rett til encoderen fordi vi slipper å konvertere et analogt signal. For å gjøre dette trenger vi en konverter som som tar inn det analoge signalet og gjør det digitalt, som encoderen kan lese og sende fra seg. Ulempen med dette er at det kan dukke opp uforutsette kompabilitetsproblemer, i henhold til encoder og type digitalt signal vi mottar. 1 «IM», Instant Messaging - øyeblikkelige meldingstjenester. side 10

17 4 Utviklingsmiljø 4.1 Plattform Første skritt i prosessen var å plukke ut hvilke plattformer som skulle benyttes. Vi visste hva vi ville ende opp med, så med å velge rett plattform ville vi komme på riktig spor. Det finnes flere muligheter, vi har imidlertid to problemstillinger, det ene var hvilke plattform som egnet seg best for streaming av lyd og bilde, og hvilke plattform som skulle stå som web-server. Det skal også nevnes at siden vi ville bruke åpen-kildekode miljøer er det noen løsninger som skiller seg ut Streaming Om man ser bort fra ønsket om åpen-kildekode finne det flere kommersielle muligheter som streamingplattform og alle disse ble tatt med i betraktningen etter hvordan resultatet skulle bli. Ikke bare kommer paramtre som operativsystem og streamingservere inn, men også hvilke formater vi skulle streame i. Samtidig også hvilke maskinvare vi hadde tilgjengelig, og hva de var kompatible med. Prosjektet var også basert på den maskinvaren Høgskolen i Gjøvik lånte ut til oss siden oppdragsgiveren hadde lite eller ingen penger til å bruke på vårt prosjekt. Maskinvaren vi fikk utlånt av skolens IT-avdeling var to maskiner med preinstallert Windows XP service pack 2, og eventuelt å legge inn Linux i stedet. Det skulle vise seg at vi også fikk låne en helt ny Dell Optiplex Ghz quad core med firewire-kontroller og en MacPro med BlackMagic SDI kontroller, som utganspunkt for testing av de forskjellige streaming-løsningene. Microsoft Windows Media Services Dette alternativet kommer fra Microsoft og benytter seg av RTSP 1 som er mye brukt og godt støttet. Ulempen med dette alternativet er imidlertid at brukerne må ha Windows Media Player for å kunne motta innholdet, noe som er nærmest umulig å gjennomføre på en annen plattform uten å ha et utall av tredjeparts plugins installert. Situasjonen blir mye verre om vi i tillegg legger til de forskjellige nettleserne som brukes idag. Løsningen fra Microsoft kan konkluderes som enkel og praktisk fra en utviklers synsvinkel, men samtidig tungvint, upraktisk og lite brukervennlig for brukerne. Adobe Flash Mediaserver 1 «RTSP», Real Time Streaming Protocol side 11

18 Det store selskapet Adobe har ingen operativsystem å begrense programvaren sin på, de har basert sine strategier på å utvikle multiplattform-formater. Ved å gjøre dette følger det en strøm av applikasjoner for hver plattform som gjør formatene deres tilgjengelige overalt. Adobe Flash er et format som kan benyttes av den største brukergruppen, de fleste kan nå et flash innhold uavhengig av hvilke plattform de sitter på. Noe som gjør at denne streaminløsningen er særs aktuell for å nå en bred målgruppe samt oppnå stor grad av brukevennlighet. Ulempen derimot, er igjen at denne løsningen er svært dyr og har store krav til maskinpark. Løsningen fra Adobe kan konkluderes: brukevennlig, enkelt og attraktivt, men likevel stort, dyrt og krevende. Apple QuickTime Streaming Server - «QTSS» Apple er store, og har i likhet med Microsoft deres eget format QuickTime (herunder QT) og.mov containerene. Dette støtter flere kodeker som MPEG-4 og H264 pluss flere andre. QT medieplayer er spilleren som må være installert hos klienten for at brukerne skal kunne aksessere innholdet, denne er imidlertid mye enklere å installere på ulike plattformer enn Windows Media Player. Å bruke QTSS som streamingløsning ville blitt et spennende prosjekt da Apple sine produkter alltid er gjennomførte og driftsikre. QTSS kan konkluderes: avansert funksjonalitet, brukervennlig og bred støtte for kodeker, men koster penger og man gjør seg avhengig av betalingsprogramvare. Darwin Streaming Server - «DSS» Etterhvert som vi har beskrevet de største kommersielle streaming-løsningerne kommer vi etterhvert inn på åpen-kildekode, her finnes noen verdige alternativer. DSS er kort og godt QTSS, men ribbet for mye avansert funksjonalitet likevel seiler den opp som et godt alternativ siden den er av åpen-kildekode. DSS har kun server muligheter og mangler således encoder mulighetene som lå i QTSS så man er avhengig av et program som kan stå for video-inputen, mer om disse senere. DSS kan kjøres på de tre store plattformene Windows, OS X og Linux og er det første alternativet vi brukte tid på sette opp. side 12

19 RED 5 Vi slipper ikke flash som streaming-format helt enda, fordi det finnes en server som kan tilby nettopp dette. Den er basert på åpen-kildekode og kan skreddersys etter behov. Ulempen er at det ikke er en streaming-server før det installeres en modul for dette, som må lages selv for at den skal fungere etter våre kriterier. Selve plattformen er skrevet i Java 1 dette må modulene også gjøre, som skaper en stor arbeidsmengde. RED 5 ble installert og testet ut, men ble vi konkluderte med at streaming av live-video gjennom denne ville bli for arbeidskrevende viss vi måtte utvikle mye av funksjonaliteten selv. VideoLan Client - «VLC» Mange kjenner VLC player som en avspiller som leser de fleste formater på flere plattformer. VLC er den mest komplette løsning som kan gjøre et bredt spekter med oppgaver. Ikke bare avspilling av både eksisterende streamer og lokale filer, men støtter også alle former for video-input som er tilgjengelig på datamaskinen den er installert på. Disse kildene kan den encode til de formatene og containere den støtter (link: Det mest spennende med VLC er at den inkluderer en streamingserver som har støtte både for «Unicast» 2 og «Multicast» 3. Protokollene den støtter inkluderer UDP, MMSH, HTTP, RTSP og RTP noe som gjør den til et multiverktøy med et bredt spekter av brukssområder. Konklusjon Valget av streaming-plattform baserte vi mye på hvilke utfordringer det ville bringe brukerne. Der en optimal løsning ikke ville bety installasjon av ekstra programvare hos brukeren for å kunne aksessere innholdet. Etter drøfting av de forskjellige streaming-løsningene ovenfor ser vi at det er flash-formatet som er det mest brukervennlige og enkleste, men dette ville gi oss kun to alternativer. Det første alternativet er å benytte Adobe Media Services, som er uaktuelt siden det er et kommersielt produkt som koster penger. Det andre alternativet er å basere seg på RED 5 konseptet der vi ville måtte utvikle store deler av løsningen selv for å kunne benytte oss av 1 «Java», programmeringsspråk basert på C++. 2 «Unicast», levering av informasjon én destinasjon. 3 «Multicast», levering av informasjon til en gruppe destinasjoner. side 13

20 en eksisterende encoder. Noe som vi konkluderte med at ville bli for mye arbeid i forhold til tiden vi har til rådighet. Siden live flash streaming ikke lar seg gjennomføre og bruk av Apple eller Microsoft sine kommersielle produkter ikke er aktuelt må vi se på de resterende alternativene. Disse to er VLC og Darwin Streaming Server begge basert på åpen-kildekode og gratis å bruke. Siden DSS kun støtter QuickTime-formatene ble dette formatet vi tok utgangspunkt i. Operativsystem Både VLC og DSS kan installeres og kjøres på Windows, OS X og Linux. Vi hadde allerede Windows XP installert på våre to maskiner, men valgte uansett å installere U b u n t u L i n u x p å streaming-serveren. Blant annet fordi at det er en svært stabil og behagelig plattform å bruke som server. Det er f.eks. enkelt å fjernstyre serveren, og enkelt å installere ekstra programvare ved behov. Og siden vi hadde en MacPro tilgjengelig, valgte vi også installere DSS på denne, men ikke med VLC som encoder. Istedet testet vi ut et Apple-program QuickTime Broadcaster 1 (link: som er utviklet for QTSS og DSS. På grunnlag av undersøkelsene endte vi opp med: - PC (DELL OptiPlex 755) med Ubuntu Linux med VLC som encoder av rådata og DSS som streaming-server. - MacPro med OS 10.4 med QT Broadcaster som encoder og DSS som streaming-server. 1 «QuickTime Broadcaster», Apple-applikasjon for encoding av live video- side 14

21 4.1.2 Web-plattform Uavhengig av hvilken plattform streaming-løsningen kjører på skulle vi utvikle en web-applikasjon som kunne gjøre nytte av det den leverte. Å konfigurere en web-server stiller andre krav enn en streaming-server. Den skal være rask, stabil og enkel å konfigurere/oppgradere slik at vi kan bruke tid på utviklingen og ikke drifting av servere. Et utviklingsmiljø har mange variabler som byttes ut etter hvilke prosjekt som kjøres, i vårt tilfelle er det et web-utviklingsprosjekt, som setter noen grenser for hvilke valg vi kan ta. Dette innebærer f.eks. at Apache HTTP web-server og MySQL database-server er alternativer Operativsystem Maskinen vi skulle bruke som web-server hadde som nevnt tidligere allerede Windows XP installert og klart til bruk. Problemet er at det er mye arbeid å installere nødvendig programvare dette er fordi Windows Shell Access 1 (herunder SSH) ikke gir de mulighetene de f.eks. gir i Ubuntu og andre Linux distribusjoner. I Ubuntu kan man utføre alle nødvendige oppgaver gjennom SSH uten å være i nærheten av den fysiske maskinen. Dette gir frihet til å arbeide på en server uten begrensninger, som var hovedgrunnen til at vi valge å installere Ubuntu over den eksisterende Windows installasjonen. At vi baserte oss på Linux som OS hadde vi et utviklingsmiljø som i stor grad baserer seg på åpen-kildekode, og fikk dermed tilgang til store mengder gratis programvare lett tilgjengelig Web-server Vi hadde altså installert Ubuntu 7.10 «Gutsy Gibbon» på vår DELL Optiplex GX240 som skulle bli vår web-server, neste skritt var å installere Apache 2 2, som er en HTTP-server for å kunne kunne kommunisere gjennom HTTP-protokollen 3 som gjorde vår MySQL database tilgjengelig fra utsiden gjennom port 80 (jf. pkt Database). Serveren fikk forøvrig den lokale IP-adressen på HiG-nettverket. For at vi skulle få tilgang til serveren fra utsiden satte vi opp tilgang via SSH, som gjør at vi kan administrere serveren uten å være på samme sted fysisk. Det gav oss også tilgang til å overføre filer fra den lokale maskinen vi arbeidet på eller å 1 «SSH», nettverksprotokoll for sikker kommunikasjon mellom to datamaskiner. 2 «Apache», web-server som benytter HTTP-protokollen for å kunne vise web-applikasjoner. 3 «HTTP», Hypertext Transfer Protocol, protokoll for overføring av data mellom klient og server. side 15

22 arbeide direkte på filene ved hjelp av f.eks. PHP-editoren Zend Studio 5.50 for utvikle selve koden Database Som database har valgte vi å benytte den kjente og mye brukte MySQL databasen. Den er basert på åpen-kildekode og er enkel å sette opp å bruke. Vi brukte så database administrasjons grensesnittet phpmyadmin som portal til å administrere database-strukturen og innholdet. Både databasen og web-serveren ble altså installert på samme maskin siden vi ikke så behovet for å legge de på hver sin maskin. Det er tross alt kun i utviklingsøyemed denne maskinen skal benyttes. MySQL Vi valgte open-source databasen MySQL til prosjektet, som er en database som vi kjenner godt fra før og som er rask og stabil. Den lar seg lett integrere med PHP og ved hjelp av programmet phpmyamin lar det oss administrere databasen gjennom et web-grensesnitt. MySQL tilbyr flere lagringsmotorer 1 som har forskjellig grad av funksjonalitet. Blant annet finnes det bare en lagringsmotor som støtter fremmednøkler nemlig InnoDB. Denne lagringsmotoren er ikke den mest brukte siden flere web-hosting selskaper kun tilbyr MyISAM som er standard i MySQL, men ikke tilbyr fremmednøkler. Noe som gjør bruk av relasjonsdatabaser vanskelig, mer om dette senere Web-teknologier Det er etter hvert blitt mange alternative metoder å bruke for å utvikle en web-applikasjon, ofte er det utviklerens preferanser og kunnskaper som avgjør hvilke av de som benyttes i et utviklingsprosjekt. Vi kjenner oss til en viss grad igjen i denne påstanden siden vi også foretrekker å arbeide med teknologier som vi har god erfaring med. Således har vi et knippe programmeringsspråk vi kommer til å konsentrere oss om: - PHP (jf. pkt PHP) - JavaScript (jf. pkt JavaScript) - XML (jf. pkt XML) - DOM (jf. pkt DOM) - AJAX (jf. pkt AJAX) 1 «lagringsmotor», en motor som skriver og leser data fra disk, den håndterer data, kontrollerer og ivaretar logg-filer. side 16

23 PHP Hovedsaklig som utviklingsspråk har vi valgt å bruke PHP 5 1, dette er et veldokumentert og «utviklervennlig» språk som er mye brukt. Vi valgte dette fordi det er et språk vi har brukt mye, som gjør det lettere å produsere kode effektivt som igjen gjør at vi sparer tid. Vi har også hatt «Grunnleggende programmering» og «Objekt-orientert programmering» i løpet av studiet, som baseres på C++. PHP og C++ er programmeringspåk som er ganske like. PHP er skrevet i C og er ganske lite så det laster og utfører oppgavene raskt. Videre er PHP et språk som det følger mye dokumentasjon og funksjonalitet med. PHP fungerer godt med Apache og Mysql samtidig som det finnes mange tilgjengelige moduler til bruk av for eksempel PDF, FTP og XML JavaScript Det er vanskelig å få funksjonalitet til å flyte sømløst i en web-applikasjon uten å ha noe form for klientbasert kode. Dette har vi løst ved bruk av JavaScript, som gir oss muligheten til å programmere hvordan klienten skal oppføre seg mot serveren. Og det gir oss mulighet til å la applikasjonen gjøre oppgaver i bakgrunnen avhengig av hva brukerens handlinger er. JavaScriptet hjelper oss med å ha en rikere brukervennlighet som øker brukerens opplevelse av applikasjonen. Språket har sentrale funksjoner i AJAX-teknologien, men vi kommer mer tilbake dette senere i avsnittet om AJAX (jf. pkt AJAX) XML Denne «relativt» nye standarden for lagring og øverføring av data er noe vi har dratt mye nytte av. Den hjelper oss med å kunne lagre unna enkel data uten å måtte benytte oss av tunge database-kall. XML 2 prinsippene bygger på lagring av data i en forhåndsdefinert trestruktur, som organiserer dataene hierarkisk. Alle skript som kjenner til denne strukturen kan «parse» dataene og bruke de på en nyttig måte. RSS-feeds bygger på XML, men har et sett med regler for hvordan de skal se ut slik at en RSS-parser kan lese alle RSS-dokumenter som følger standarden. I prosjektet vår benyttet vi XML til å lagre unna hvilke brukere som var tilknyttet hvilke stream, som vi brukte til å opplyse brukerne hvem som så på samme kamera-vinkel. 1 «PHP 5», «Hypertext Preprosessor» versjon 5 server-side programmeringsspråk. 2 «XML», extensible Markup Language side 17

24 DOM DOM 1 er funksjonalitet som er knyttet til å lete seg frem i et hierarki. Det kan lete opp tagger ved hjelp av hva de heter eller hvilke type de er, og deretter finne ut hvilke data de inneholder. Dette gjør det mulig å manupilere f.eks. en HTML kode slik at innholdet på en i utangspunktet statisk side blir dynamisk. Der kan man legge til, fjerne eller forandre utseende til dataene i en trestruktur. DOM blir også mye brukt i forbindelse med XML for å kunne lete seg frem i hierakiet for så å legge til eller fjerne data. Det skal også nevnes at både PHP og Javascript har muligheter for å benytte seg av DOM-teknologien for å kunne dra nytte av innholdet i en XML fil AJAX AJAX 2 er ingen egen teknologi i seg selv, men baseres på JavaScript, DOM og på XMLHttpRequest objektet som er tilgjengelig for de fleste skript-språk i nyere nettlesere. Prinsippet med AJAX er at det arbeider asynkront i bakgrunnen ut fra brukerens avgjørelse, og henter eller sender data fra serveren basert på det. Dette gjør at man kan slippe å laste inn siden på nytt hver gang man skal gjøre en forspørsel til serveren, men istedet hente dataene automatisk og presentere de. Ved å bruke denne formen for klient-server interaksjon kan brukeren få et bedre grensesnitt og brukeropplevelse. 1 «DOM», Document Object Model 2 «AJAX», Asynchron JavaScript And XML side 18

25 5 Streaming Dette var en viktig del av vår webapplikasjon. Vi ville ha en streamingtjeneste der klienter kunne velge mellom ulike kameravinkler og ut ifra det aksessere våre tilbudte streamer. For å få den tilstedeværelsen som vi ville oppnå så måtte vi levere live-streamer til alle våre klienter. 5.1 Hva er streaming? Streaming er samtidig overføring av data slik at det blir mottatt som en kontinuerlig strøm av lyd og/eller bilde. Datastrømmen blir sendt fra en server-applikasjon, mottatt og avspilt hos klienten. Klientens applikasjon kan starte å spille av lyd eller bilde så snart nok data er blitt lagret i det allokerte minnet (buffer). Man slipper med andre ord å laste ned store filer, for så å kunne se dem. Unicast og Multicast Unicast-streaming vil si en en-til-en forbindelse mellom server og klient. Multicast-streaming er en en-til-mange forbindelse mellom en server og et antall klienter som mottar streamen. Serveren streamer media til en multicast IP adresse på nettverket, og klientene mottar streamen ved å gå til den IP adressen. Alle klientene mottar den samme streamen. Fordi det bare blir sendt en stream fra serveren, uavhengig av antall klienter som mottar, så krever en multicast stream samme båndbredde som en enkel unicast som sender det samme innholdet. Dersom du skal streame ut til et stort antall klienter, og båndbredden og serverkapasiteten er begrenset, så er multicast den foretrukne metoden. Ulempen ligger derimot i de forskjellige nettverksnodene den skal igjennom. Det er ikke uvanlig at de ikke støtter denne metoden og du vil ikke kunne aksessere streamen. 5.2 Valg av format og protokoll Streaming og filformater Vi har masse ulike video filformater å velge mellom. Det som er viktig når vi skal velge hvilket vi vil bruke er å tenke på hvor mange får sett streamen vår med minst mulig, eller helst ingen, problemer. Forhåpentligvis slipper klientene å måtte laste ned plugins eller annet ekstra utstyr Windows media side 19