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.
Eftersom VLC endast kan pusha video via RTP borde det ha undersökts vilka andra möjlig-heter som nns för att publicera video. Exempelvis är det möjligt att koda om och publicera en ström med hjälp av mpeg och RTMP [10]. Denna ström kan börja spelas upp redan innan den är fullt uppladdad. Detta upptäcktes dock i slutskedet av arbetet, och om det hade upptäckts tidigare skulle troligtvis mpeg och Xuggler använts istället för libvlc.
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 tra ken 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
Figur 4.2: Jämförelse av lösningar för muspekarrörelser. Bilden visar kvadratisk interpo-lation mellan punkter i en musrörelse. Interpointerpo-lationen längst till vänster är uppbyggd av samtliga relevanta registrerade pekarpositioner, och för det nya protokollet visas hur varan-nan position gallras bort för varje steg till höger. Muspekarrörelsen längst till höger visar resultatet av en rörelse där punkterna bestämts av en förenklingsalgoritm.
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 video l 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.
I Tabell 5.1 ser vi hur klienterna spelar exakt samma delar av videon, men med en liten förskjutning på 200 ms.
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
Detta skapar en spelare som upplevs lika responsiv som en vanlig videospelare för den som kontrollerar den, men blir osynkroniserad om er än en person ska kunna styra spelaren.
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
Om en ny deltagare ansluter måste denne på något sätt få reda på vilken l som ska spelas upp, status och tidskod. Under arbetets gång har fyra möjliga lösningar uppkommit.
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