Synkroniserad videouppspelning över Internet

Synkroniserad videouppspelning

över Internet

Fredrik Vestermark

15 december 2011

Examensarbete för kandidatexamen i datavetenskap, 15 HP

Handledare på CS-UmU: Thomas Johansson

Examinator: Pedher Johansson

Umeå Universitet

Sammanfattning

Målet med projektet var att uppnå realtidssynkroniserad videouppspelning över internet, vilket innebär att era klienter spelar upp samma del av en video samtidigt.

Resultatet visar hur det är möjligt att skapa protokoll som ger upplevelsen att uppspelning är synkroniserad mellan datorer när videon spelas upp från en lokal l, strömmas eller laddas ned progressivt från internet. Detta uppnåddes genom att först designa, sedan rollspela för att hitta svagheter och till sist implementera protokollen för att se hur de fungerade i praktiken. Genom att använda ett sådant protokoll är det möjligt att navigera och diskutera kring en video i exempelvis en telefonkonferens, och veta att alla tittar på samma bild.

Synchronized video playback over the Internet

Abstract

The goal with this project was to achieve real-time synchronized video playback over the Internet, or in other words, that multiple clients play the same part of a video at the same time.

Innehåll

1 Inledning 1

1.1 Flaunt Kit . . . 1

1.2 Grundläggande begrepp . . . 2

2 Projektspecikation 3 2.1 Projektspecikation från Flaunt Kit . . . 3

2.1.1 Synkroniserad videouppspelning för samarbete . . . 3

2.1.2 Synkroniserad videouppspelning under möte . . . 3

2.1.3 Synkronisering . . . 4

2.1.4 Fildelning . . . 4

2.2 Egna tillägg till specikationen . . . 4

2.2.1 Tillvägagångssätt . . . 4 2.2.2 Resurser . . . 5 2.2.3 Övriga kommentarer . . . 5 3 Förundersökning 7 3.1 Flaunt Kit . . . 7 3.2 Video i Flash . . . 7

iv INNEHÅLL

3.2.2 Leverera video . . . 8

3.3 Video i HTML5 . . . 10

3.4 Intressanta strömningsservrar . . . 10

3.4.1 Adobe Flash Media Streaming Server 4 . . . 11

3.4.2 Wowza Media Server . . . 11

3.4.3 C++ RTMP Server . . . 11

3.4.4 Övriga strömningsservrar . . . 12

3.5 LibVLC . . . 12

4 Utförande 15 4.1 Projektplan . . . 15

4.2 Hur arbetet utfördes . . . 16

4.2.1 PyVLC . . . 16

4.2.2 Mediaserver & strömningsprotokoll . . . 17

4.2.3 Meddelandeprotokoll, server och bibliotek . . . 17

4.2.4 Synkronisering . . . 17

4.2.5 Prototyp av spelare . . . 18

4.2.6 Prototyp av systemet . . . 18

4.3 Vad som kunde ha gjorts annorlunda . . . 19

5 Synkronisering 21 5.1 Synkroniserad uppspelning av lokalt lagrad video . . . 21

5.1.1 Fokus på synkronisering . . . 21

5.1.2 Fokus på responsivitet . . . 23

5.1.3 Problem . . . 24

INNEHÅLL v

5.2.1 Möjligheter att spara bandbredd . . . 27

5.3 Synkroniserad uppspelning av VOD . . . 27

Figurer

4.1 Uppbyggnad av systemprototypen . . . 19

4.2 Jämförelse av lösningar för muspekarrörelser . . . 20

5.1 Kommunikationsöde för uppspelning vid fokus på synkronisering . . . 22

5.2 Exempel på överföringstid av meddelanden. . . 22

5.3 Två sätt att distribuera en liveström . . . 26

Tabeller

3.1 Ljud- och videoformat vilka stödjs av Adobe Flash Player . . . 7

3.2 Videoformat som i skrivande stund stödjs av respektive webbläsare . . . 10

3.3 Tillgänglig data i Access-pluginen i Flash Media Server . . . 11

4.1 Ursprunglig projektplan . . . 15

5.1 Exempel på pause vid fokus på synkronisering . . . 23

5.2 Exempel på pause vid fokus på responsivitet . . . 24

Kapitel 1

Inledning

1.1 Flaunt Kit

Flaunt Kit är ett mötesverktyg för designers, illustratörer och andra som vill diskutera högkvalitativt graskt material över internet. Det kan köras direkt i webbläsaren, och kräver ingen installation.

En förenklad beskrivning av användarödet i detta verktyg är [12]: 1. Ladda upp de bilder du vill diskutera.

2. Ange ditt namn.

3. Skicka mötets URI till övriga deltagare.

När mötet väl är igång kan mötesledaren med ett musklick växla mellan bilderna, och samtli-ga deltasamtli-gare peka med sina muspekare och lägsamtli-ga till kommentarer till bilderna. Röstkom-munikation sker via exempelvis Skype.

När mötet avslutas får mötesledaren en lista över bilder med kommentarer om denne är en registrerad användare.

Med stöd för synkroniserad video skulle verktyget få ännu er tillämpningar och en större målgrupp. Videoproducenter skulle då sinsemellan kunna diskutera videosekvenser på dis-tans, och även kunna använda det i kommunikation med kunder.

Detta arbete handlar därför om att undersöka hur det är möjligt att uppnå synkroniserad video över internet i följande tre fall:

 Videon nns tillgänglig från en server.  Samtliga deltagare har videon lagrad lokalt.

2 Kapitel 1. Inledning

1.2 Grundläggande begrepp

I denna rapport används några begrepp som kan behöva förtydligas. Video-on-Demand (VOD)

Video levereras till användaren på begäran, och användaren kan navigera fram och tillbaka under uppspelningen.

Strömning

Multimedia skickas i realtid till användaren, och spelas upp utan att lagras på hård-disken. Ofta är det möjligt att navigera fram och tillbaka i strömmen. Median nns ofta lagrad på en mediaserver eller sänds till mediaservern via en liveström.

Liveströmning

Direktsänd ström distribueras till användarna. Ofta kommer ljud och bild från en kamera, men i denna rapport är källan istället en klients video.

Progressiv nedladdning

Multimedia laddas ned och lagras på användarens hårddisk, men användaren kan börja spela upp innan hela videon är hämtad.

Mediaserver

Kapitel 2

Projektspecikation

Projektspecikationen är uppdelad i två delar. Först den projektspecikation som tillhan-dahölls av Flaunt Kit, sedan egna tillägg.

2.1 Projektspecikation från Flaunt Kit

Projektet handlar om att skapa ett mötes- och samarbetsverktyg, anpassat för företag som jobbar med videoproduktion. Målet är att det skall vara lika smidigt att jobba på distans, som att sitta på samma kontor. För att uppnå detta krävs utforskning av en rad tekniker.

2.1.1 Synkroniserad videouppspelning för samarbete

En videoproduktion har era delar, där stora delar handlar om nslipning av klippning, färgkorrigering, animationer och grak. De delarna görs ofta av olika personer och resultat nås genom dialog med regissörer och producenter. För att jobba med detta på distans krävs det att man på ett enkelt sätt kan titta på varandras lmklipp, lägga kommentarer samt synkroniserat kunna styra en videouppspelning under ett onlinemöte. Detta måste även gå att göra i hög upplösning och god kvalité. Det är även viktigt att kunna göra detta på säkert sätt, då produktionerna ofta är hemliga.

Möjliga tekniker att utforska: Adobe AIR för graskt interface, VLC för videouppspelning, node.js eller Ejabberd för realtidsstyrning.

2.1.2 Synkroniserad videouppspelning under möte

4 Kapitel 2. Projektspecikation lerna inte skall kunna hamna på villovägar. Därför krävs det alltså att videon skall kunna strömmas till de som vill titta på den. Möjligtvis vill företagen kunna strömma video direkt från klippborden till onlinemötet.

Möjliga tekniker att utforska: Adobe Flash för graskt gränssnitt, Wowza eller Red5 för videoströmning.

2.1.3 Synkronisering

En viktig del i projektet handlar om synkronisering och realtidskommunikation under ett möte. Där handlar det både om att göra en snabb och lättviktig lösning för 2-50 deltagare, som samtidigt ska ta sig genom de esta brandväggar.

2.1.4 Fildelning

För vissa samarbetsöden kan det vara nödvändigt med en mjukvara som förenklar ldelning mellan företagen. Där kan det bli aktuellt med integration av existerande lösningar som t.ex Dropbox.

2.2 Egna tillägg till specikationen

Målet med projektarbetet är att utforska hur olika typer av synkroniserad video fungerar, vilka fördelar och nackdelar dessa har, samt att utvärdera vilka tekniker som bäst motsvarar Flaunt Kits behov.

När en sådan utvärdering är gjord skall, om tid nns, en prototyp designas för att visa hur lösningen skulle kunna integreras i Flaunt Kit för att skapa synkroniserad videouppspelning. En mer optimerad kommunikationskanal skall skapas i mån av tid.

2.2.1 Tillvägagångssätt

För att välja vilken servermjukvara som skall användas för videoströmning måste de tekniska aspekterna, enkelheten att använda lösningarna, samt priset jämföras. Finns ändå ingen klar vinnare måste någon typ av stresstest göras för att se vilken server som kräver minst serverkraft och kan hantera est anslutningar.

Om realtidsstyrning inte är möjligt att åstadkomma med hjälp av en mediaserver måste protokoll skapas för att uppnå synkronisering. Dessa protokoll ska då testas med hjälp av rollspel för att reducera antalet buggar, och sedan implementeras för att kunna visa att de fungerar även vid praktisk användning.

2.2. Egna tillägg till specikationen 5 meddelande att en ny kommentar lagts till eller att en ny bild ska visas. Detta innebär att servern måste hantera 4∗n inkommande meddelanden samt (n−1)2_{utgående meddelanden}

per sekund, där n är antalet mötesdeltagare. Skulle servern istället bara lagra undan inkom-ma positioner, och sända ut samtliga positioner fyra gånger varje sekund skulle antalet meddelanden bli 4 ∗ n inkommande samt 4 ∗ n utgående. Även det faktum att XMPP1

an-vänds av Ejabberd skapar förhållandevis stor overhead på grund av protokollets design. Om en specialdesignad kommunikationskanal skapas bör den också jämföras med den existerande lösningen som använder Ejabberd.

2.2.2 Resurser

Nedan följer en tabell över vilka resurser som nns att tillgå för examensarbetet. Handledare på företaget Anders Gunnarsson

Universitetshandledare Thomas Johansson

Arbetsplats Kontorsplats hos Flaunt Kit

Dator Packard Bell EasyNote TK

AMD Phenom II X4 N950

AMD Radeon HD 6650M, 1 GB VRAM 4 GB 1333 MHZ DDR3 RAM

Den ovan nämnda datorn används vid såväl utveckling som eventuella prestandatest.

2.2.3 Övriga kommentarer

Kapitel 3

Förundersökning

Förundersökningen beskriver information som samlats in för att skapa en relevant lösning för Flaunt Kit.

3.1 Flaunt Kit

Flaunt Kit-klienten är skriven i ActionScript 3.0, och är alltså Flash-baserad. Att skapa och underhålla en ny version av Flaunt Kit som inte kan köras i Adobe Flash Player ses i nuläget inte som en acceptabel lösning, men i framtiden kommer troligtvis en HTML5-version att utvecklas. Därför nns det ändå ett visst intresse för videoformat som stödjs av HTML5.

3.2 Video i Flash

Flash har stöd för tre lformat, nämligen FLV, F4V och ISO base media le format. Tabell 3.1 visar vilka typer av ljud- och videoformat som stödjs av respektive lformat [4].

FLV F4V & ISO base

media le-format Video On2 VP6, Sorenson Spark (Sorenson H.263), Screen

video, H.264 H.264

Ljud MP3, ADPCM, Linear PCM, Nellymoser, Speex, AAC AAC, MP3

Tabell 3.1: Ljud- och videoformat vilka stödjs av respektive lformat, som stödjs av Adobe Flash Player

8 Kapitel 3. Förundersökning FLV är att bilden inte uppdateras när man hoppar i en pausad video. Strömmas istället en MP4-l i H.264-format är det möjligt att hoppa även om videon är pausad.

3.2.1 FLVPlayback och Open Source Media Framework

FLVPlayback är en komponent för att skapa videospelare i Flash, och Open Source Media Framework (OSMF) är ett ramverk för det ändamålet. FLVPlayback kan användas un-der Flash Player 9.0.28.0, medan OSMF kräver Flash Player 10.0. Båda har stöd för F4V och ISO base media le-format, vilket är det mest intressanta i detta fall. För den bästa bakåtkompatibiliteten bör alltså FLVPlayback användas.

3.2.2 Leverera video

Det nns huvudsakligen två olika sätt att leverera video till Flash, nämligen progressiv nedladdning och strömning [13].

Vid progressiv nedladdning laddas len ned till användarens dator, och kan börja spelas upp när tillräckligt mycket är nedladdat. Exempelvis YouTube använder sig av detta. Även om användaren ser en lm era gånger behöver denne bara ladda hem lmen en gång. Två nackdelar med att medialen sparas på slutanvändarens dator är att det underlättar olovlig kopiering och att den kräver utrymme hos användaren. En personlig teori är att detta kan undvikas till viss del om videon levereras via HTTP, genom att sätta headerfältet Cache-Control till 'no-store, no-cache'. Information om hur detta skulle kunna göras i praktiken, samt källa saknas dock.

Strömmas videon från en mediaserver kan den spelas upp nästan direkt. Det är även möjligt att hoppa till en position som inte blivit hemladdad. Ofta nns inbyggd funktionalitet för att optimera videon efter användarens internetuppkoppling, och videon skyddas i viss mån från kopiering, eftersom den spelas upp direkt istället för att lagras på användarens dator. I motsats till progressiv nedladdning måste videon överföras igen om användaren hoppar tillbaka till en redan uppspelad tidpunkt.

Kort om RTMP och dess derivat RTMP

Ett protokoll som utvecklades för att strömma ljud, video och data mellan olika teknologier för Flash-plattformen, exempelvis mellan en Flash-spelare och en serv-er [6]. Varianten RTMPT innebär att kommunikationen är inkapslad i HTTP-headserv-ers (RTMP Tunneled), vilket förbättrar chansen att komma förbi brandväggar. RTMPS kapslar in kommunikationen i HTTPS, och minskar således risken för att någon läser av eller förändrar strömmen.

RTMPE

3.2. Video i Flash 9 någon säkerhet alls, och att 'krypteringsnyckeln' består av kända strängar. Huruvida detta stämmer eller ej kommer inte att undersökas vidare.

RTMFP

Ett protokoll som möjliggör direktkommunikation mellan Flash-applikationer. Använ-der sig av NAT-traversering.

Åtkomstkydd

Adobe nämner följande sätt att skydda sin video [1]:

 Strömma via RTMP eller RTMFP, för att undvika att videon blir cachad.

 Kryptera strömmen (RTMPE, RTMFP eller RTMPS), i kombination med 'SWF le verication' för att veriera ash-len.

 Adobe Flash Access.

SWF le verication innebär att klienten skickar en hashsumma skapad av SWF-len och dess storlek till servern. Servern jämför sedan denna hashsumma mot hashsumman av de SWF-ler som av servern har rätt att komma åt strömmen. Detta är dock ingen säker lösning, eftersom det endast krävs att en oönskad användare har åtkomst till SWF-len för att kunna generera hashsumman [9]. Eftersom SWF-len kommer vara åtkomlig för alla, innebär detta inget riktigt skydd.

På grund av tidsbrist har dock Adobe Flash Access inte testats. Ingen värdering har lagts i valet att utesluta det, och det kan mycket väl vara ett bra skydd.

Under arbetets gång har ytterligare sätt att skydda strömmar dykt upp. Genom att lägga till användarnamn och lösenord till sökvägen, som sedan kontrolleras med ett skript på servern, kan man neka användare rättigheter till strömmen. Ett exempel på en URI vore då rtmps://example.com/streamName?username=User&password=Pass

Detta kräver att RTMPS används för att undvika att någon avlyssnar nätverket och får reda på användarnamn och lösenord. Ibland är det dock önskvärt att kunna dela med sig av strömmen till utomstående. Det kan då vara mer lämpligt att generera en hemlig sträng istället för att använda användarnamn och lösenord, men använda den på liknande sätt. Ett alternativ som inte involverar skript på servern är att den hemliga strängen i fråga helt enkelt används som namn på strömmen.

rtmps://example.com/035697ff43ec194[...]c3b910b1c

10 Kapitel 3. Förundersökning

3.3 Video i HTML5

I dagsläget nns inget videoformat som i en standardinstallation stödjs av samtliga stora webbläsare.

Webbläsare Ogg Theora H.264 VP8 (WebM)

Internet Explorer Y M Mozilla Firefox Y Y Google Chrome Y Y* Y Chromium Y M Y Safari M M M Opera Y Y Konqueror Y M Y Epiphany Y M Y

*Stöd kommer tas bort.

Tabell 3.2: Vilka videoformat som i skrivande stund stödjs av respektive webbläsare [15]. Format markerade med Y stödjs i en standardinstallation, och M kräver manuell installa-tion. Denna lista har förändrats ofta, och kan mycket väl vara utdaterad i läsande stund. Video-taggen i HTML5 kan hantera era källor, och webbläsaren väljer då den första len som stödjs [11]. Genom att kombinera Ogg Theora eller VP8 med H.264 går det alltså att stödja samtliga webbläsare i Tabell 3.2. Nackdelen är att servern då måste lagra dubbla uppsättningar av varje video. Ett alternativ till att använda video-taggen är att bädda in en Flash-spelare, vilket innebär att servern bara behöver lagra videon som H.264.

3.4 Intressanta strömningsservrar

För att en strömningsserver ska vara intressant måste den, utifrån projektspecikationen och förundersökningen ovan stödja följande:

 Video-on-Demand.

 Distribuering av en liveström, till exempel MPEG-TS1_.

 Skydd av ler och strömmar - helst genom att både kryptera traken och begränsa åtkomst till strömmen till en specik användare.

 Linux, helst Ubuntu.

Flaunt Kit är ännu ett litet företag, så vid val av strömningsserver kan priset vara en avgörande faktor. Att en server är fri mjukvara är alltså en fördel, men eftersom även tid är en kostnad är det inget krav. Den budgeten ligger på ungefär 10 000 kronor.

3.4. Intressanta strömningsservrar 11

3.4.1 Adobe Flash Media Streaming Server 4

Flash Media Server 4-sviten (FMS) stödjer Linux-distributionerna Red Hat R Enterprise

Linux R Server 5.3 (32 bit and 64 bit) och Linux CentOS 5.3 (32 bit and 64 bit). Efter några

enklare tester tycks det även fungera under Ubuntu 11.04, och stödja ovanstående krav, med reservation för 'skydd av ler och strömmar'. Detta eftersom Flash Media Streaming Server (FMSS) saknar stöd för skript på serversidan. FMS-sviten har stöd för någonting som heter 'C++ plug-in architecture', men just FMSS har endast stöd för Access-pluginen [5]. När en klient ansluter anropas metoden IFCAccessAdaptor::onAccess(IFCAccess *pAccess) [2]. Om en klient ansluter med URI

rtmp://localhost/app/stream?user=myUser&password=myPassword innehåller pAccess följande information (testet utfördes med VLC):

Namn Värde

c-referrer tomma strängen c-user-agent tomma strängen

s-uri rtmp://localhost/app

c-ip 127.0.0.1

c-proto rtmp

coreIdNum -1

Tabell 3.3: Tillgänglig data i Access-pluginen i Flash Media Server

Här ser vi alltså att frågan (?user=myUser&password=myPassword) inte är tillgänglig. I mer avancerade produkter i sviten är den dock tillgänglig i 'Authorization plug-in', vid händelserna E_PLAY och E_CLIENT_PAUSE [3]. Det är dock möjligt att Adobe Flash Access kan lösa autentiseringen.

3.4.2 Wowza Media Server

Wowza Media Server (WMS) 2 tycks ha stöd för samtliga av ovan listade krav, även skript på serversidan. Vid några enklare tester av VOD och live-strömning tycks WMS även vara relativt enkelt att kongurera.

3.4.3 C++ RTMP Server

12 Kapitel 3. Förundersökning

3.4.4 Övriga strömningsservrar

Adobe Flash Media Server 4 är Adobes mjukvarufamilj för mediaströmning. Endast kost-naden för den tidigare nämnda FMSS 4 (se Kapitel 3.4.1) ansågs tillräckligt låg för att kunna vara ett alternativ, trots att övriga servrar i sviten kan uppnå kraven.

Även Erlyvideo testades, men servern kraschade direkt vid start. Detta tycks inte längre vara fallet och kan ha varit en konsekvens av felaktig användning, men eftersom det nns många er strömningsservrar var det ej motiverat att lägga ner mycket tid på att leta efter problemet.

Red5 Media Server tycktes länge vara ett intressant alternativ, men var tyvärr inte så lätt att kongurera. Detta i kombination med tidsbrist innebar att det inte var möjligt att testa allt som enligt specikationen och förundersökningen krävs av mediaservern.

3.5 LibVLC

LibVLCs funktionalitet för att skicka en ström av data kallas för stream output. De till-handahåller era olika moduler, men de som är intressanta för strömning över nätverk är standard, transcode och rtp. Modulen standard har stöd för att strömma via udp, http, https och mmsh2_.

HTTP, HTTPS och MMSH tycks här endast gå att använda som pull-protokoll, så använd-ning av dessa för att strömma från klientsidan kräver alltså att användaren öppnar en port i eventuell router  någonting som ej är önskvärt.

Kvar är alltså UDP och RTP. RTP brukar användas ovanpå UDP, men introducerar bland annat ett sekvensnummer, vilket gör det möjligt att upptäcka förlorade paket och återge rätt ordning på paketen. RTP är dessutom ett välkänt protkoll för att strömma live-media, och torde lämpa sig även i detta fall.

För att sända en liveström med RTP-modulen anges följande argument till lib-vlc_media_add_option:

rtp{mux=ts,dst=X.X.X.X,port=N} eller

--sout "#rtp{mux=ts,dst=X.X.X.X,port=N}" till VLC på kommandoraden [8].

VLC tycks i skrivande stund inte kunna pusha via RTMP. Transcoding

Transcoding innebär att konvertera multimedia till ett annat format eller en annan bit rate [8]. Efter att ha testat bland annat olika kodekar och buerstorlekar, har följande

3.5. LibVLC 13 inställningar visat sig ligga på gränsen vad gäller kvalité på och krav på beräkningskraft vid användning av en kärna på datorn beskriven i kapitel 2.2.2:

transcode{vcodec=h264,vb=128,width=320,height=240,deinterlace,acodec=mp3,ab=64} :rtp{mux=ts,dst=X.X.X.X,port=N,caching=0}

Kapitel 4

Utförande

Detta kapitel behandlar hur arbetet planerades att utföras, hur det var utfört och vad som kunde ha gjorts annorlunda.

4.1 Projektplan

Arbetsuppgifterna i den ursprungliga tidsplanen var ganska specika och gav inte mycket utrymme för att något steg skulle gå fel. Denna projektplan kan ses i Tabell 4.1.

Vecka Uppgift

1-2 Spela lokala ler

1 Sätta upp en utvecklingsmiljö för Adobe Air Starta VLC genom Adobe Air

2 Styr VLC från Adobe Air, och skapa ett interface mot VLC

3 Strömning av uppladdad l (från mediaserver)

Format, skalning & konvertering Välja server

4-6 Sänd ström till samtliga deltagare

4 Skicka en ström från den egna datorn

5 Distribuera strömmen till övriga klienter via en mediaserver

6 Kontrollera möjligheten att skicka metadata via strömningsprotokollet, och därigenom uppnå synkronisering

6-8 Synkroniseringslösning, gruppmeddelanden

6-7 Stängd gruppchat, protokoll för synkronisering 8 Undvika brandväggar & proxies

9-10 Färdigställande av rapport

10 Förberedelse av presentation

11 Opposition

16 Kapitel 4. Utförande Av era anledningar kunde tidsplanen inte hållas.

 Det var svårt att sätta upp en Air-utvecklingsmiljö under Linux  utvecklingen kunde ha skett på Windows.

 VLC kunde inte kontrolleras från Adobe Air i Windows  det slutade med en spe-cialiserad spelare.

 För många mediaservrar testades.

 Den specialiserade meddelandeservern och dess ActionScript-bibliotek borde inte ha skapats  den existerande lösningen med XMPP borde ha använts istället.

 Prototypen gjordes för avancerad  det skulle ha räckt med en väldigt enkel prototyp. Den största anledningen till förseningen var dock att projektplanen inte justerades trots att arbetet drog ut på tiden. Detta eftersom uppgiften ansågs vara mycket intressant, och det därför till en början inte heller var ett problem att det tog mer tid än planerat.

4.2 Hur arbetet utfördes

Nedan ges en överblick över hur arbetet utfördes i praktiken. Det kan ses som ett slags komplement till den delvis bristfälliga veckovisa rapporteringen.

4.2.1 PyVLC

Den ursprungliga idén gick ut på att spela upp lokala ler och skicka en live-ström genom att använda sig av VLCs kommandoradsgränssnitt, och att styra VLC inifrån Flash. Problemet var att VLC under Windows startar en ny kommandotolk och tolkar dess stdin istället för ordinarie stdin. En ny ansats prövades, där VLC startades med HTTP-gränssnitt, och kontrollerades via socketanrop. Detta fungerade visserligen både under Windows och Linux, men HTTP-gränssnittet kunde inte positionera och ändra storlek på spelaren bortsett från att växla till fullskärm. Den tredje och slutliga lösningen gjordes genom att skapa en egen videospelare som använde sig av libvlc, och styrdes interaktivt via stdin.

Spelaren designades så att det skulle vara enkelt att ladda och strömma nya videor utan att starta om applikationen.

libVLC för ActionScript

4.2. Hur arbetet utfördes 17 libVLC behövde inte längre interaktivt ladda videoler, kontrollera om laddningen lyckades etcetera. I princip behövde det efter ändringen bara ta hand om play-, pause-, stop- och seek-kommandon.

4.2.2 Mediaserver & strömningsprotokoll

Flera olika mediaservrar installerades och testades, och den som slutligen verkade passa bäst var Wowza, eftersom den är lätt att kongurera och har stöd för skript på serversidan. Risken nns att Red5 uteslöts för snabbt eftersom det var svårare än Wowza att kongurera, och RTMPD eftersom den en gång låste sig.

För att strömma från Wowza valdes protokollet RTMPS, eftersom det skyddar strömmen och ofta tar sig förbi brandväggar. Mycket tid lades ned på att hitta ett sätt att skicka en live-ström via RTMP eller RTSP med hjälp av libvlc. Enligt kommentarer på diverse forum kan libvlc endast pusha en ström via RTP, vilket är anledningen till att RTP valdes till det ändamålet.

4.2.3 Meddelandeprotokoll, server och bibliotek

Flaunt Kit använder sig av XMPP för att skicka meddelanden mellan klienter, vilket kan innebära overhead i form av nätverkstrak om man jämför med ett specialiserat protokoll. Utöver detta så skickades muspekarens position med korta intervall, för att uppnå en mjuk och synkroniserad rörelse, vilket skapade ännu mer overhead. Detta påverkade främst klien-ter med långsam inklien-ternetuppkoppling negativt. Därför utvecklades ett mer lättviktigt, spe-cialiserat protokoll, med stöd för klientstyrd ödesstyrning.

Protokollet skapades med två kategorier av meddelanden, nämligen en kategori som direkt skickas vidare till övriga mötesdeltagare, och en som lagras på servern, gallras och sänds ut med ett visst tidsintervall. Klienten kan själv ge förslag på hur många av dessa med-delanden den vill ta emot vid varje tidsintervall, och på så sätt är det möjligt att uppnå viss grad av ödesstyrning. Denna kategori av meddelande är främst tänkt att användas för att skicka muspekarpositioner. För att kunna konstruera en mjuk rörelse från få punkter gallras punkterna jämnt fördelat över samtliga inkomna punkter från den användaren. I nuläget skickas dock meddelanden inte över HTTP med detta protokoll, vilket resulterar i att kommunikationen lätt fastnar i brandväggar.

4.2.4 Synkronisering

18 Kapitel 4. Utförande terna hade tillgång till videon. Detta försökte lösas genom att klienten sände en ström till övriga klienter via en mediaserver. Övriga klienter skulle då helt enkelt kunna styra ström-men genom att sända meddelanden till sändaren (Kapitel 5.2 beskriver detta). Mycket tid lades ned på att uppnå en användbar responsivitet. Mycket tid lades även ner på att hitta en praktiskt användbar konguration för transcodingen. Även detta var näst intill resultatlöst. Det första försöket att skapa ett protokoll för att spela lokalt lagrad video grundades i att en användare styrde videospelaren lokalt, och kommandona skickades till övriga mötesdelt-agare. Detta resulterade i en väldigt responsiv spelare, men på viss bekostnad av synkro-niseringen. Vid rollspelet visade det sig att denna design inte kunna hantera att er än en användare simultant kontrollerar spelaren, men det kunde lösas genom att även hantera sina egna meddelanden i vissa fall. För mer information, se kapitel 5.1.2.

I projektspecikationen var det inte klart uttryckt att era klienter skulle ha möjlighet till att navigera i videon, men detta togs för givet. Eftersom ovanstående lösning hade nämn-da svagheter användes en ny anfallsvinkel; att skicka ett kommando till samtliga klienter inklusive sig själv istället för att direkt navigera spelaren lokalt. Det visade sig dock att det fortfarande uppstår fel om pause-kommandot innehåller en tidskod, varför tidskoden togs bort och ersattes med ett korrigeringsmeddelande i form av en seek som skickas av den klient som tog initiativ till att pausa uppspelningen. För mer information, se kapitel 5.1.1. Vid ett försök att använda protokollet som utvecklats för synkronisering av lokalt lagrad video även för att strömma från en mediaserver visade det sig vara praktiskt användbart även där, till och med för högupplöst video. För långsammare internetanslutningar som inte har kapacitet att strömma videon måste dock progressiv nedladdning användas, varför ett tillägg till protokollet skapades. Detta gick ut på att samtliga klienter skickade ett med-delande för att konrmera att tillräckligt mycket av videon hade burats. När en klient mottagit konrmationsmeddelandet från samtliga deltagare kunde uppspelningen startas. Detta tillägg implementerades dock inte. För mer information, se kapitel 5.3.

4.2.5 Prototyp av spelare

Ovanstående tekniker sattes samman till en Flash-spelare. Då tidigare erfarenhet av Flash helt saknades och ingen tid åsidosatts för att sätta sig in i plattformen blev koden lång och svårtolkad. Efter en tid upptäcktes dock Adobe Flex, vilket gör det möjligt att deniera graska gränssnitt med det XML-baserade märkspråket MXML. Den nya koden blev kortare och mer lättläst, och gränssnittet blev mer enhetligt.

4.2.6 Prototyp av systemet

4.3. Vad som kunde ha gjorts annorlunda 19 Synced Player Players Player/Streamer of local files Wowza libVLC PyVLC Progressive Download Player Stream Player Message Client Library Message Server Sync Permission Tester MySQL Database Incoming Stream Authenticator Web Server API Auth

Figur 4.1: Uppbyggnad av systemprototypen och kommunikation mellan komponenter i systemet. Heldragna pilar representerar en utgående anslutning, och prickade pilar innebär lokal kommunikation. Riktningen på pilen visar vem som ansluter till vem snarare än åt vilket håll kommunikationen går. Dubbla cirklar visar en server.

4.3 Vad som kunde ha gjorts annorlunda

Ett ertal saker kunde med fördel ha gjorts annorlunda.

I början av arbetet borde det ha undersökts hur en mediaserver fungerar, istället för att utgå ifrån antaganden. Om detta gjorts först av allt skulle möjligen liveströmmningsde-len kunnat ersättas med en publiceringslösning och mediaservern kunde ha använts som kommunikationskanal.

20 Kapitel 4. Utförande krävande, och även om det möjligtvis innebar vissa prestandaförbättringar jämfört med att använda den existerande lösningen med XMPP så är det större risk att paket fastnar i brandväggar. Det utvecklande protokollet är nämligen inte är inkapslat i HTTP, medan det existerar HTTP-proxies för XMPP.

Med det utvecklade kommunikationsprotokollet anger klienten hur många paket den vill ta emot per sekund, och servern ltrerar bort vissa paket beroende på denna sira (se Figur 4.2 för visualisering av resultatet). Ett bättre tillvägagångssätt för att minska traken hade varit att klienterna använt sig av en förenklingsalgoritm som reducerade antalet punkter pekarens kurva, baserat på vinklar och avstånd mellan punkter (se längst till höger i Figur 4.2).

Original Nytt protokoll Förenklad musrörelse

Kapitel 5

Synkronisering

I detta kapitel beskrivs de synkroniseringslösningar som utvecklades. Ordet 'uppspel-ningsstatus', eller bara 'status', används för att beskriva huruvida en video spelas, är stoppad eller är pausad för tillfället. 'Videoinformation' inkluderar utöver status även tidskod. Protokollen som beskrivs utgår ifrån att alla meddelanden levereras globalt sorterade i kausal ordning.

5.1 Synkroniserad uppspelning av lokalt lagrad video

För att uppnå synkroniserad uppspelning av en lokal videol måste klienterna kommunicera om uppspelningsstatus och tidskod. Vi utgår här ifrån att klienterna redan vet vilken l som skall spelas. Inom videoredigering anges ofta tider i millisekunder eller i frames. För att undvika problem om parterna har samma video men med olika bildfrekvens kan det argumenteras att det skulle vara bäst att ange position i millisekunder.

Vilka meddelanden som skickas och hur de är utformade kan påverka hur synkroniseringen uppfattas av användaren. Två metoder utarbetades under projektets gång, där en fokuserar på att få en så synkroniserad spelare som möjligt och den andra fokuserar på att den ska vara responsiv. Nedan diskuteras för- och nackdelar med de två metoderna, och hur de fungerar.

5.1.1 Fokus på synkronisering

Lösningen för att få en så synkroniserad uppspelning som möjligt utgår ifrån fyra olika typer av meddelanden, nämligen:

 Play - startar uppspelning från nuvarande position.

22 Kapitel 5. Synkronisering  Pause - stannar uppspelning utan att hoppa till början.

 Seek tidskod - hoppar till tidskod utan att påverka huruvida uppspelning pågår eller ej.

Figur 5.1 visar hur dessa meddelanden skickas när klienten C1 tar initiativ att spela upp, stoppa, hoppa i videon samt att pausa.

P l a y / S t o p / S e e k S e r v e r C 1 2MSG C 2 2MSG 1MSG P a u s e S e r v e r C 1 2PA 4 S E C 2 2PA 4 S E 1PA 3 S E

Figur 5.1: Kommunikationsöde för uppspelning vid fokus på synkronisering. Lägg märke till hur C1 väntar med att hantera sin egen videospelare tills denne fått tillbaka sitt meddelande från servern, och sedan skickar ett seek-meddelande för att korrigera eventuella klienter vars tid skiljer sig något från tiden i C1.

Utgår man från att överföringstiden mellan server och klient är konstant och att det inte nns några övriga latenser, då spelar klienterna exakt samma video även om överföringstiden skiljer sig mellan klienterna. Dock innebär det inte realtidssynkronisering i strikt mening, eftersom klienterna inte nödvändigtvis tar emot meddelandena samtidigt. Detta kan vi visa med hjälp av ett kort exempel och överföringstiderna i Figur 5.2.

S e r v e r C 1 2 0 0 m s C 2 4 0 0 m s 3 0 0 m s 5 0 0 m s

Figur 5.2: Exempel på överföringstid av meddelanden.

5.1. Synkroniserad uppspelning av lokalt lagrad video 23 Global tid [ms] C1 [ms] C2 [ms] Händelse

0 - - C1 sänder initial 'Play' till Server

300 - - Server mottager och sänder 'Play' till C1 och

C2

500 0 - C1 mottager 'Play', och börjar spela

700 200 0 C2 mottager 'Play', och börjar spela

. . .

10700 10200 10000 C2 sänder 'Pause'

11200 10700 10500 Server mottager och sänder 'Pause'

11400 10900 10700 C1 mottager 'Pause'

11600 - 10900 C2 mottager 'Pause', och sänder 'Seek'

12000 - - Server mottager och sänder 'Seek'

12200 10900 - C1 mottager 'Seek'

12400 - 10900 C2 mottager 'Seek'

Tabell 5.1: Exempel på pause vid fokus på synkronisering. De tider som ej förändrats sedan föregående händelse markeras med ett streck.

Konstant överföringstid är naturligtvis inte någon man kan utgå ifrån. Därför måste någon, förslagsvis personen som skickade paus-kommandot, skicka 'Seek' för den nya positionen (Figur 5.1, Pause) efter att denne mottagit sitt eget meddelande. I exemplet ovan kommer det då alltså att dröja 900 ms från det att C2 trycker på 'Pause' till dess att dennes spelare stannar, och lika länge för att söka till rätt tidskod, om den skulle skilja sig från den väntade.

5.1.2 Fokus på responsivitet

Ligger fokus på att spelarna snabbt ska reagera på användarens input, snarare än att den måste vara så synkroniserad som möjligt, då är det relevant att lägga till tidskod till pause-kommandot samt att utföra pause-kommandot på den lokala spelaren samtidigt som meddelandet skickas. När meddelandet kommer tillbaka till sändaren kasseras det.

För att förtydliga är kommandona i detta fall:  Play tidskod

 Stop

 Pause tidskod  Seek tidskod

24 Kapitel 5. Synkronisering Global tid [ms] C1 [ms] C2 [ms] Händelse

0 0 - C1 sänder initial 'Play 0' till Server, och

bör-jar spela

300 300 - Server mottager och sänder 'Play 0' till C1

och C2

700 700 0 C2 mottager 'Play 0', och börjar spela

. . .

10700 10700 10000 C2 sänder 'Pause 10000', och pausar

11200 11200 - Server mottager och sänder 'Pause 10000'

11400 11400 - C1 mottager 'Pause 10000'

- 10000 - C1 hoppar till 10000

Tabell 5.2: Exempel på pause vid fokus på responsivitet. De tider som ej förändrats sedan föregående händelse markeras med ett streck.

Utöver dessa latensproblem öppnar denna typ av synkronisering för synkroniseringsfel om två användare samtidigt exempelvis hoppar i lmen, se Tabell 5.3. Lägg dock märke till att dessa problem endast uppstår om era klienter har möjlighet att styra spelaren.

Global tid [ms] C1 [ms] C2 [ms] Händelse

0 0 - C1 sänder initial 'Play 0' till Server, och

bör-jar spela

0 - 0 C2 sänder 'Stop' till Server

300 300 - Server mottager och sänder 'Play 0' till C1

och C2

500 500 - Server mottager och sänder 'Stop 0' till C1

och C2

700 700 - C1 mottager 'Stop'

700 0 - C1 hoppar till 0

700 - 0 C2 mottager 'Play 0', och börjar spela

900 - 200 C1 mottager egen 'Play 0', och gör ingenting

. . .

10700 - 10000 C2 fortsätter att spela, men inte C1

Tabell 5.3: Exempel på error vid fokus på responsivitet. De tider som ej förändrats sedan föregående händelse markeras med ett streck.

En lösning på detta synkroniseringsproblem är att en klient Ci hanterar sitt egna

inkom-mande meddelande Mi,m om ett meddelande Mj6=i,n har mottagits sedan Mi,m skickades.

Anledningen till att detta löser problemet, är att samtliga meddelanden innehåller den in-formation som behövs för att tilldela spelaren rätt videoinin-formation.

5.1.3 Problem

5.1. Synkroniserad uppspelning av lokalt lagrad video 25 1. Med hjälp av en valalgoritm utses en 'gammal' klient som ansvarar för att skicka

informationen till nya klienter.

2. När en klient begär ändrad uppspelningsstatus eller sökning skickas kommandot även till ett webb-API, som nya klienter kontaktar.

3. Samtliga kommandon byts ut mot ett enda 'Update'-kommando och ett webb-API. 4. En specialiserad meddelandeserver som känner till protokollet och uppdaterar sin

in-formation automatiskt och sänder ut den till nya klienter. Samtliga lösningar har sina för- och nackdelar.

Lösning 1, att utse en klient som ansvarar för att informera nya klienter med informa-tion, påverkar endast protokollet. Meddelandeservern kan alltså lämnas orörd. En potentiell nackdel är att informationen då försvinner om samtliga användare lämnar mötet.

Lösning 2, att klienter informerar ett webb-API varje gång de begär ändrad status, är kanske den enklaste lösningen. Både protokoll och meddelandeserver kan lämnas orörda. Här är det dock svårt att garantera att korrekt information når nya klienter, men det är möjligt exempelvis genom att webbservern agerar sequencer för kommandon.

Lösning 3 kan ses som en utvidgning av lösningen ovan. Genom att all information går via webbservern kommer samtliga klienter ha samma information, senast när alla har hämtat datan från webbservern och inget ytterligare 'Update'-meddelande är skickat. Detta kommer dock att öka belastningen på webbservern, och troligtvis vara en långsammare lösning på grund av det extra steget.

Lösning 4, att med hjälp av en specialiserad meddelandeserver som tolkar inkomna med-delanden, kan dock enkelt garantera att nya klienter får korrekt information. Synkroniser-ingsprotokollet behöver inte ändras, men servern måste känna till det och ändras så den skickar ut informationen till nya klienter.

Den server som lagrar videoinformationen bör också lagra tidsstämplar för när status-uppdateringar sker. På detta sätt är det möjligt att, som Algoritm 1 visar, beräkna vilken tidskod som skall skickas till nya klienter.

Algoritm 1 Sänd rätt tidskod till nya klienter time := video.time

if video.state = P LAY ING then

time := time + system.time − video.state_change_timestamp end if

return [video.source, video.state, time]

26 Kapitel 5. Synkronisering Algoritm 2 Kontrollera tidskoden skickad från servern

video.source := video_information.source

if video_information.time ≤ video.totalT ime then video.time := video_information.time

video.state := video_information.state end if

5.2 Synkroniserad uppspelning genom liveströmning

Eftersom en klient sänder strömmen till övriga deltagare behöver endast seek-meddelandet innehålla tidskod. Synkronisering sker automatiskt.

När en klient (nedan 'sändaren') skall sända en liveström till övriga klienter kan detta ske på åtminstone två sätt. Antingen ansluter övriga klienter direkt till sändaren, eller så sänds strömmen till en mediaserver som i sin tur får distribuera den vidare.

C 1 Recv C 2 Recv C 3 Recv Media-s e r v e r C 1 S e n d Recv C 2 Recv C 3 Recv

Figur 5.3: Två olika sätt att distribuera en liveström - pilarna visar utgående anslutningar. Anslutningar som i teorin skulle kunna uteslutas eftersom klienten har tillgång till videon representeras av streckade linjer.

Att strömma direkt från sändaren är generellt sett snabbare än alternativet, eftersom man slipper en mellanhand. Om all överföring sker via TCP kan man dessutom garantera att alla klienter så småningom sett samma video. De främsta nackdelarna med att strömma direkt från sändaren är:

 Det tar lång tid från det att en klient styr spelaren till dess att det får ett resultat.  Sändaren måste öppna en port för inkommande trak i eventuella brandväggar och

routrar.

 Sändaren måste ha tillräcklig bandbredd för att kunna sända till samtliga klienter.  Övriga klienter måste veta sändarens IP-nummer, vilket kan vara en potentiell

säker-hetsrisk.

5.3. Synkroniserad uppspelning av VOD 27 Genom att använda en mediaserver som mellanhand yttas ovanstående krav till den som tillhandahåller mediaservern, och kan alltså förbättra användarvänligheten avsevärt för klienterna.

Nackdelarna med att distribuera liveströmmen via en mediaserver är:  Ännu sämre responsivitet.

 Kraven på bandbredd hos servern ökar.

Gemensamma nackdelar för båda typerna av liveströmmning är:  Det är svårt att veta vilken frame som spelas upp.

 Om sändningen är pausad och någon hoppar i videon märks det inte förrän videon börjar spelas upp igen.

5.2.1 Möjligheter att spara bandbredd

I Figur 5.3 visades möjligheten att sändaren direkt spelar upp len lokalt istället för att läsa sin ström. På detta vis kan man spara lite bandbredd. Görs detta är det dock sannolikt att synkroniseringsproblem uppstår, eftersom mediaservern och klienten burar. Dessutom får användarna olika upplevelser, vilket kan vara negativt. Genom att bura minskar klienten risken för att videon hackar, och mediaservern minskar risken för att segment av videon försvinner eftersom de anländer för sent till mediaservern. Buringen innebär dock även att om strömningen pausas hos sändaren, kan videodata nnas kvar i burarna, och andra klienter 'pausar' tidigare i videon. Därför kan man inte ens garantera att klienterna ser samma pausade bild. Ett möjligt sätt att komma runt detta vore att konstant strömma en stillbild vid paus, vilket innebär att klienterna visar samma bild till slut. Det kostar dock mycket bandbredd. Det enklaste sättet torde dock vara att alla klienter har samma storlek på burarna, och att även sändaren läser från sin eller mediaserverns ström.

5.3 Synkroniserad uppspelning av VOD

28 Kapitel 5. Synkronisering

C 1 3BU

C 2 1PL 3BU 2BU

2BU

Figur 5.4: Tillägg till protokollet, för att ta hänsyn till buringstider. För läsbarhetens skull har servern dolts.

5.4 Nyckelbildrutor

Ofta går det bara att hoppa till nyckelbildrutor i en video, vilket kan medföra att synkro-niseringen inte uppför sig som väntat, och istället för att hoppa till önskad tidskod hoppar den till den första nyckelbildrutan efter den tidskoden. Ett sätt att minska detta problem är att videon transcodas med korta intervall mellan nyckelbildrutorna.

5.5 NAT-traversering

NAT-traversering är ett samlingsnamn för olika tekniker vars mål är att upprätta en IP-anslutning mellan klienter bakom routrar och andra NAT (Network Address Translation). Det har inte funnits tid att behandla detta i examensarbetet, trots att det kan vara högst relevant ämne för synkroniserad videouppspelning. Valet att ändå nämna det gjordes för att hjälpa eventuella personer som läser rapporten för att själva skapa synkroniserad videospel-ning.

5.5.1 RTMFP och Cirrus

Cirrus är en teknologi från Adobe, ännu i beta-version, som kan anvädas för att via RTMFP kommunicera mellan Flash Player 10-klienter utan att behöva gå genom en server [14]. För mer information, besök Adobes Wiki-sida som behandlar RTMFP och Cirrus1_.

Kapitel 6

Slutsatser

I dagsläget är det av internets natur omöjligt att helt uppnå realtidssynkroniserad videoup-pspelning mellan klienter, eftersom det kan ta en obestämd tid innan ett paket kommer fram. Eftersom paket 'vanligtvis' levereras till mottagaren 'relativt snabbt' går det däremot att skapa illusionen av realtidssynkroniserad videouppspelning. Det kan därför ha många användningsområden, inte bara för videoproducenter. Exempelvis har Google nu lanserat synkroniserad YouTube-video i Google+ Hangouts, naturligtvis oberoende av detta exa-mensarbete men med liknande funktionalitet, vilket av kommentarer att döma tycks vara användbart även ur en social aspekt.

Eftersom Flaunt Kit riktar in sig mot företag är det möjligt att förutsätta att kunderna har relativt snabb internetuppkoppling. Med denna utgångspunkt är mitt förslag att synkronis-ering sker på det vis som beskrivs i kapitel 5.1, utan att ta hänsyn till buringstider, både för uppspelning av lokalt lagrad video och strömmad video.

6.1 Synkronisering

När det gäller synkronisering av lokal video och VOD kan det teoretiska resultatet beskrivet i kapitel 5.1 och 5.3 vara relevant för många som vill skapa en egen lösning för att synkronisera videouppspelning över internet. Dock bör det betonas att protokollen inte tar hänsyn till tappade paket eller att klienter kopplar från. Dessutom utgår de från att alla inkommande meddelanden är globalt sorterade.

30 Kapitel 6. Slutsatser

6.2 Begränsningar i prototypen

Live-video som skickas till WMS sker i prototypen via RTP, och är inte krypterad. Det går inte heller att vara säker på att videon verkligen skickats från det IP-nummer som syns i paketet, vilket gör det möjligt för en eventuell angripare att förstöra ett möte genom att sända RTP-paket till den port som används av just det mötet. Om något annat bibliotek än libvlc använts skulle det varit möjligt att publicera videon via ett annat protokoll, och på så vis lägga till ytterligare säkerhet.

Att publicera en liveström med libvlc på detta vis ger enligt mina tester dessutom mycket låg ljud- och bildkvalité, har dålig responsivitet samtidigt som den kräver hög CPU-användning från klienten. Det ger inte heller ett bra skydd mot kopiering. Den fördel som nns kvar med denna typ av strömning är således möjligheten att inte behöva ladda upp lmen. Troligtvis skulle även den delen skulle gå att lösa på ett bättre sätt, exempelvis med hjälp av mpeg. Det är inte känt hur många deltagare som kan delta i ett möte, eller vilka delar av systemet som utgör potentiella askhalsar.

Generellt har koden för spelaren många buggar. Exempelvis är hanteringen av muspekare trasig, vilket gör den ointressant att använda i nuläget.

6.3 Framtida arbete

Eftersom liveströmningen misslyckades och det fortfarande inte hittats någon användbar lösning för att synkroniserat distribuera en lokal video till övriga klienter är detta område kanske mest intressant för framtida arbete. Just nu är den bästa lösningen att ladda upp len till servern, som sedan transcodar den. Eftersom det visade sig vara möjligt att strömma högupplöst video, att mpeg kan publicera en ström under tiden det transcodar, och att det är möjligt att spela upp strömmen direkt när mpeg börjar transcoda och publicera strömmen, skulle ett framtida arbete kunna gå ut på att skapa ett front-end för mpeg, specialiserat för att användas med Flaunt Kit.

Ett problem som dök upp var att kunna garantera att nya klienter ck relevant information om vilken video som skulle spelas, om videon skulle vara pausad eller spelas upp, samt tidskod. Denna del av synkroniseringen gavs väldigt lite tid, och är nog även den svagaste delen. Den bör därför utvecklas mer innan den används praktiskt.

Kapitel 7

Tacksamhetsbetygelser

Litteraturförteckning

[1] Adobe. Adobe - ash media server: Faq. http://www.adobe.com/products/ flashmediaserver/faq/ (visited 2011-04-17).

[2] Adobe. Adobe ash media server 4.0 * developing an access

plug-in. http://help.adobe.com/en_US/FlashMediaServer/4.0_Dev/

WS5b3ccc516d4fbf351e63e3d11a0d662434-7fed.html (visited 2011-11-18).

[3] Adobe. Adobe ash media server 4.0 * developing an authorization

plug-in. http://help.adobe.com/en_US/FlashMediaServer/4.0_Dev/

WS5b3ccc516d4fbf351e63e3d11a0d662434-7fe8.html (visited 2011-11-18).

[4] Adobe. Create video for use in ash. http://help.adobe.com/en_US/flash/cs/ using/WSb03e830bd6f770ee-70a39d612436d472f4-8000.html (visited 2011-04-15). [5] Adobe. media server for streaming video | help me choose. http://www.adobe.com/

products/flashmediaserver/helpmechoose.html (visited 2011-05-06).

[6] Adobe. Real-time messaging protocol (rtmp) specication. http://www.adobe.com/ devnet/rtmp.html (visited 2011-04-21).

[7] Adobe. Rtmpe. http://livedocs.adobe.com/flashmediaserver/3.0/docs/help. html?content=01_overview_basics_13.html (visited 2011-04-21).

[8] Alexis de Lattre, Johan Bilien, Anil Daoud, Clément Stenac, Antoine Cellerier and Jean-Paul Saman. Chapter 3. advanced streaming using the command line. http: //www.videolan.org/doc/streaming-howto/en/ch03.html (visited 2011-09-26).

[9] Andrej Stepanchuk, Howard Chu, The Flvstreamer Team. http://rtmpdump.

mplayerhq.hu/rtmpdump.1.html (visited 2011-09-01).

[10] Art Clarke, ConnectSolutions, LLC. Xuggle now has librtmp support. http://xuggle. wordpress.com/2010/06/18/xuggle-now-has-librtmp-support/ (visited 2011-09-23).

[11] Refsnes Data. Html5 video. http://w3schools.com/html5/html5_video.asp (visited 2011-04-15).

34 LITTERATURFÖRTECKNING [13] Richard Harrington and Marcus Geduld. After Eects for Flash - Flash for After Eects: Dynamic animation and video with Adobe After Eects CS4 and Adobe Flash CS4 Professional (read 2011-04-18, 2011-04-19). Peachpit, 2009.

[14] Adobe Labs. Cirrus. http://labs.adobe.com/wiki/index.php/Cirrus (visited 2011-06-27).

[15] Unknown. Html5 video. http://en.wikipedia.org/wiki/HTML5_video#Table (vis-ited 2011-12-12).