Live slow motion: from idea to product

(1)

2010:046 CIV

E X A M E N S A R B E T E

Live Slow Motion

- from idea to product

Johan Gavelin Joachim Koitsalu

Carl Lindqvist

Luleå tekniska universitet Civilingenjörsprogrammet

Medieteknik

Institutionen för Systemteknik Avdelningen för Medieteknik

2010:046 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--10/046--SE

(2)

Instant Replay maskin - LTU Page 2

Förord

Examensarbetet på 30 poäng utfördes på Luleå Tekniska Universitet (LTU) under höstterminen 2009.

Med hjälp av egna datorer är vi tre studenter som tillsammans har arbetat mot ett gemensamt mål.

Examensarbetet blev för oss en spännande upptäcktsresa i problemlösning rörande teknologier ännu inte införda i LTUs läroplan.

Projektiden ifråga föddes i en bil någonstans mellan Luleå och Piteå vilket är en passande beskrivning över vad detta projekt har betytt för oss som jobbat med det och för universitetet. LTU står för fakta, teori och grundkunskaper medans Piteå filialen står för kunskapernas praktiska branschförankring.

Via denna unika brygga mellan lärosätets teoretiska och verklighetens aspekter har vi fått lära oss både hur tekniken i mediebranschen används men även hur dess tekniska hjälpmedel är

konstruerade. Det kändes därför rätt att försöka sig på lite nytänkande och sätta ihop en lågbudget professionell Instant-Replay maskin mestadels baserad på en vanlig dators komponenter. En maskin där även design och användarvänlighet i form av intuitiva grafiska gränssnitt genomtänktes. Detta samtidigt som den inte fick bli för avvikande från marknadens invanda metoder.

Vi vill nu tacka nyckelpersoner som hjälpt oss under vår tid med detta projekt. Först, vår examinator Kåre Synnes för den hjälp han gett oss med att komma igång och fullborda vårt projekt. Sedan vår handledare Daniel Rosdahl som aldrig tvekat att fungera som bollplank och alltid gett oss sitt fulla stöd. Tack vare hans hjälp har maskinen kommit ihop och kommer förhoppningsvis kunna användas i olika evenemang. Slutligen vill vi också tacka Institutionen för musik och medier i Piteå som från början trott på vårt projekt och bidragit med budgeten som krävts.

Tack!

Joachim Koitsalu Carl Lindqvist Johan Gavelin

(3)

Sammanfattning

Vi ville undersöka om det var möjligt att på en begränsad budget bygga och programmera en Live Slow Motion-maskin för att generera repriser under en TV-sändning. Utan tillgång till dyrare specialtillverkad hårdvara skulle allt skötas i mjukvara på i grunden en vanlig konsument-PC.

Vi ville så långt som möjligt att vår maskin skulle efterlikna de etablerade produkter som används i TV-branchen då vår förhoppning var att maskinen skulle kunna utnyttjas av TV-studenter efter färdigställandet. Vi ville dock inte begränsa oss för mycket, utan vi skulle försöka förbättra de saker vi ansåg behövde förändras.

(4)

Inledning

Detta examensarbete visar hur utvecklingen av vår idé genomgick olika faser. Först positioneringen av idén mot existerande produkter. Sen konkretiseringen av idén och slutligen utvärdering av resultatet. Dessa tre faser utgör även grunden för denna rapport.

I fas 1 fördjupade vi oss i den Instant-Replay maskin som är vanligast och mest använd i branschen.

Innan vi kunde sätta upp mål för vad vi ville uppnå var vi tvungna att lära oss så mycket som möjligt om hur en sådan maskin fungerar eller förväntas fungera av deras användare. I vilka sammanhang de används, samt hur och varför. Under denna första fas tog vi oss igenom manualerna på maskinen. Vi åkte även på en studieresa till Skellefteå på en hockey sändning där vi i detalj kunde undersöka hur Instant-Replay maskiner användes och fungerade. Med en viss inblick i vad marknaden erbjuder och kräver kunde vi fokusera på vad vi ville uppnå med vårt projekt. Mål och idéer fastslogs och fas 1 på arbetet var nu färdig. Utvecklingen av produkten kunde börja.

Till fas 2 av arbetet var vi tvungna att sätta oss in i nya programmeringsverktyg som skulle behövas för projektet. Det vi utgick från var att vi kunde alla tre programmera Java. Därifrån sökte vi efter verktyg, programmeringsbibliotek och Application Programming Interface (API) för att kunna planera och börja arbetet. Tekniken för datahanteringen var hjärtat av projektet. Det var kring denna resten av koden skulle skrivas, maskinen sättas ihop och det grafiska gränssnittet ritas (Graphical User Interface, GUI). Datahanteringsrutinerna tog därför det mesta av vår tid och skrevs om flera gånger från grunden. Tredje gången gillt fick vi ett system vi inom ramarna av arbetet var nöjda med.

Därpå fortsatte vi på den andra delen i fas 2 i vilken vi utvecklade GUI:t för maskinen och lade till extra funktioner. Då sattes all fokus på hur enkel och användarvänlig maskinen kunde bli. Varje detalj var tvungen att ha en nödvändig funktion. Oväsentlig information fick inte visas samtidigt som vissa detaljer fick göras övertydliga. Efter i vårt tycke en lyckad implementering av de flesta funktioner kunde vi samtidigt som GUI:t fortfarande finslipades börja på fas 3 av arbetet.

Fas 3 påbörjades med att testa maskinen så utförligt som möjligt. Projektet tidsplan medgav inte tid för fälttest men i vårt labb testades så många möjliga scenarion vi kunde komma på. Både

synkroniseringen av datan samt GUI:t var tvungna att vara så felfria som möjliga. Det är helt enkelt stabiliteten på programkoden vi testade. Användaren skall inte genom olika knapptryckningar eller funktioner krascha programmet. Kombinationer av händelser skall inte heller störa maskinens funktioner. Vi insåg så småningom att denna fas aldrig tar slut då vi även så sent som när denna rapport skrevs kunde hitta kod som behövde justeras då vissa extrema om än osannolika kombinationer av händelser kunde få programmet att hänga sig.

På 3 personer och 16 arbetsveckor, där ca 60% av arbetstiden gick åt tekniken för datahanteringen, lyckades vi till slut utveckla en produkt från A till O där både mjukvara, hårdvara och GUI:t valdes respektive utvecklades för detta projekt. Med mål att skapa en billig, användarvänlig och mångsidig maskin går det kanske att hitta nischade marknader som kan finna maskinen intressant. I sista delen på rapporten diskuteras därför denna Instant-Replay maskins möjliga framtid inom branschen.

(6)

EVS – standard i en bildkontroll Vad är en Instant-Replay maskin?

I dagens tv-bransch används Instant-Replay maskiner i de flesta produktioner. Det finns en växande marknad där både ledande public service kanaler men även privata produktionsbolag använder sig mer och mer av sådana maskiner. Idag är företaget EVS störst på marknaden med försäljning och utveckling av Instant-Replay maskiner. De erbjuder därutöver skräddarsydda lösningar och uppgraderingar som passar enskilda produktioner och behov. Det finns alltså otalig varianter och storlekar av Instant-Replay maskiner utrustade med många och olika funktioner. Alla har dock ett fåtal grundfunktioner som definierar de som Instant-Replay maskiner.

- En hårddiskbaserad inspelningsfunktion. Utan fördröjning går det att spela in en eller flera insignaler på hårddisk i ett passande format. På så sätt undviks mängder av band och all information samlas på ett ställe

- Omedelbar åtkomst av sparat material i ett sändbart format

- Möjligheten att blixtsnabbt peka ut och spela upp godtycklig sekvens från det inspelade materialet.

Kort och gott skall det vara möjligt för en operatör att i direktsändning spela in flera kamerasignaler och på beställning mixa de för att skicka ut ett färdigt klipp och repris av det som just hänt, därav namnet Instant-Replay. En sista smidig funktion som har letat in sig i de flesta modeller och som vi därför skall försöka implementera är att spela upp filer i långsammare uppspelningshastighet (Slow Motion).

Den maskin vi har störst möjlighet att studera och jämföra vårt arbete med är Multicam Live Slow Motion (LSM) som är en maskin utvecklad och byggd av företaget EVS.

EVS lösning på en Instant-Replay maskin består av två delar. Deras Multicam[LSM] (Live Slow Motion) fjärkontroll och en XT2 Server.

Servern kommer i olika storlekar, format och lagringsutrymmen beroende på behoven men den har samma roll oavsett. Att på ett redundant och säkert sätt kunna spara ner mycket material i realtid. Detta förklarar att de ofta har 2 Power Supply Units (PSU) på 550W styck. Men också 5, 10 eller 15

hårddiskar på 73/146/300GB. Dessutom är servern HD-SDI kompatibel och kommer med 4 eller 6

ingångar/utgångar som kan programmeras helt efter behov. Dessutom har servern

inbyggd loop funktion som gör att maskinen kan kontinuerligt spara data i 5 timmar innan den börjar skriva över gammalt material. Även detta kan förprogrammeras och olika mycket lagringsutrymmen kan tilldelas varje insignal.

Figur 1 || Baksidan på en XT2 server 6RU

(7)

Instant Replay maskin - LTU Page 7 Multicam[LSM] fjärkontrollen kan internt spara in och ut markeringar

till 900 enskilda klipp per signal eller kamera. Den kan även spara 256 enskilda Cue markeringar. Med hjälp av en spak, en ratt samt ett fåtal specifika knappar kan operatören (även kallad LSM operatör i

branschen efter maskinens namn) snabbt starta och använda inbyggda funktioner. Spaken styr startandet av klippen samt deras uppspelningshastigheter och ratten hjälper att sätta precisa in och ut markeringar.

Det som gör maskinen unik är dess mjukvara som medger alla funktioner och effekter på de klippen som sparas ner på servern.

Några av de funktioner som erbjuds är slowmotion, live editering, snabb klippning och skapandet av spellistor.

Gränssnitt

Det är dock imponerande hur så många funktioner och effekter kan skapas via nyttjandet av så få knappar, en ratt och en spak.

Efter lite djupläsning av manualer blir dock maskinens inre detaljer och funktioner mer självklara och tydliga. I grunden väljer man en insignal (t.ex. en av kamerorna) och spelar upp den i realtid. Då är man i så kallad E2E(Enter to Exit) läge där signalen bara går igenom maskinen i stort sett orörd.

Så fort man börjar röra på ratten aktiveras SEARCH läge. På så sätt kan LSM operatören spola tillbaks eller framåt i signalen för att sätta en Cue markering. En fiffig funktion (om aktiverad) sätter då en Cue markering på alla andra insignaler vid samma tidskod. Därifrån kan operatören då spela upp videon i önskad hastighet. Allt samtidigt som alla insignaler fortsätter att sparas på XT2 servern.

När material spelas upp går maskinen in i ett så kallat PLAYBACK läge. Hastigheten på uppspelningen kan även styras med hjälp av spaken.

Ett sista mode som förenklar uppspelningen av material är SYNCHRONISATION läge. Denna kan vara på eller av och styr hur hoppen mellan insignaler sker. Spelar du upp signal A och vill byta till signal B kommer detta att ske vid samma tidskod om SYNC läget är av. Om SYNC läget däremot är på kommer uppspelningen fortsätta från senaste Cue markering på signal B när du går över till signal B.

Med endast dessa lägen, Cue knappen (även kallad Mark), Play knappen och insignalknapparna går det att skapa snabba och snygga repriser på valfritt material i önskad hastighet. Det går alltså att göra ganska mycket med ganska lite vilket vi hoppas efterlikna i vår maskin.

Det finns även otaligt många inställningar och funktioner som spellistfunktionen och skapandet av klipp som gör maskinen mer komplett. Dessa är dock inte lika lättanvända och kräver ganska mycket inlärning. Samma knappar på fjärrkontrollen används till olika saker i olika lägen och shift-knappen

Figur 2 || Multicam [LSM]

fjärrkontroll

Figur 3 || Förklaring av SYNC mode; exempel ur LSM manualen

(8)

Instant Replay maskin - LTU Page 8 måste tryckas ner för att komma åt vissa funktioner. Även om vi inte kommer ha tid eller kunna implementera så många finesser och funktioner kommer vi att försöka förbättra inlärningskurvan och användarvänligheten av vår maskins mer komplexa funktioner.

Studiebesök i Skellefteå

För att se hur en Multicam LSM används har vi besökt en sändning av en elitseriematch i ishockey. På denna match var de tre ”EVS-operatörer”. Varje operatör hade hand om olika kameravinklar och hade dessutom lite annorlunda uppgifter. Vi pratade en del med dem och frågade hur de använder maskinen. Vi stod även och kollade över deras axel när de jobbade.

Det är mycket klickande och knappande när en EVS-operatör arbetar, och står man och ser på är det svårt att hänga med i vad som händer. Multicam[LSM]-kontrollen i sig har en liten LCD-display som visar den nödvändigaste informationen. LED-belysta knappar indikerar också vilka knappar och lägen som är aktiva. Handtaget styr själva XT2-servern och det är ur den man kopplar en enskild bildskärm till varje utgång för att se vad som händer. Har man fyra ingångar och två utgångar behöver man alltså sex stycken bildskärmar för att hålla koll på det man jobbar med.

Operatörerna vi pratade med använde sig nästan enbart av funktionen att skapa klipp och spara dessa i olika banker. Vad dessa banker innehöll och vad klippen bestod av antecknades på ett papper på bordet bredvid maskinen.

I sina banker satte operatörerna också ihop block som exempelvis ”matchens höjdpunkter”. För att få dessa att hänga ihop spelade man även in vinjetter på EVS:en. De kopplade helt enkelt in en

bandspelare på en insignal i XT2-servern och kunde på så vis spara ner den som ett enskilt klipp.

Detta system användes en hel del under sändningen och var även det huvudsakliga sättet att spela upp inslag i programmet.

Genom att se hur dessa maskiner faktiskt används har vi fått en inblick i vad som är de viktigaste funktionerna att implementera.

(9)

Våra målsättningar

Av realistiska skäl kan vi inte duplicera EVS XT2 server och Multicam[LSM] fjärrkontrollen då vi varken har tillgång till samma kunskap, tid, budget och personal som detta världsledande företag. Hoppet och drivkraften bakom vårt projekt är att dagens datorer och komponenter har nått så pass höga standarder att mycket kan göras med enkla medel och ny mjukvara.

EVS maskiner har anpassad hårdvara som är specifikt byggd och programmerad för dess ändamål. Vi hoppas programmera mjukvara som kan göra liknande uppgifter och åstadkomma samma resultat med hjälp av mer lättillgänglig och framförallt billigare hårdvara. Vi vågar därför sätta ganska höga mål på vårt projekt och det vi hoppas uppnå är följande.

 Maskinen skall i dess grundprinciper och funktioner efterlikna en modern Instant-Replay maskin av typen Multicam[LSM]. Maskinen skall alltså kontinuerligt kunna spela in två skilda signaler och samtidigt spela upp en signal. Det skall även gå att ändra

uppspelningshastigheten.

 Maskinen skall kunna spela in och spela upp i HD-SDI/SDI med embedded ljud.

 Operatören skall kunna skapa spellistor av klipp från både insignaler eller externt sparade filer och spela upp de vid önskad tid.

 De avancerade funktionerna såsom skapandet av spellistor skall styras via ett nyutvecklat och användarvänligt Graphical User Interface (GUI)

Maskinen skall alltså vara en förenklad version av EVS motsvarighet. Detta för att studenter som skall använda sig av den får en idé om hur riktiga Multicam[LSM] används och funkar. Samtidigt är vårt mål att utveckla GUI:t och göra den mer praktisk, användarvänlig och anpassad de produktioner studenterna på media musik institutionen brukar tillverka.

Planering av hårdvaror

Efter att målsättningarna fastställts är det möjligt att planera för vilken hårdvara vi kommer behöva.

Det första vi behöver lösa är ett sätt att läsa in eller skicka ut HD-SDI/SDI signaler. Efter lite sökande hittar vi olika kort från ett flertal tillverkare och leverantörer men alla passar inte riktigt varken vår budget eller ändamål. En tillverkare med både bra rekommendationer och bra priser erbjuder dock en intressant Software Development Kit (SDK) tillsammans med korten. Då vi är ute efter ett kort vi kan anpassa lite efter våra behov känns denna tillverkare helt rätt. Kortmodellen i sig själv väljer vi för att den är billig och har precis det vi är ute efter. Varken mer eller mindre.

Vi bestämmer oss för tre stycken Decklink SDI kort som har varsin inport, utport och REF-inport som kan synkronisera kortets signaler. Det finns även en annan tillverkare som heter Bluefish444 som tillverkar kort som också skulle passa men de kostar mer än vår budget. Två av korten kommer användas till att ta insignaler och det tredje kortet kommer stå för utsignalen. Dessutom är korten

kompatibla med RS-422 protokollet som är ett

fjärrstyrningsprotokoll. Detta passar perfekt då vi planerar att programmera en Sony RM-450CE bandarkontroll till att funka som fjärrkontroll åt vår maskin.

Figur 4 || Decklink SDI kort.

(10)

Instant Replay maskin - LTU Page 10 Utöver korten behöver vi egentligen bara en vanlig persondator. Dock har vi i tankarna att datorns olika delar skall kunna hantera och bearbeta mycket information i realtid. Det behövs alltså komponenter som klarar specifika lagrings- och hastighetskrav. För att veta mer om vilka

komponenter vi kommer behöva har vi en testdator på vilken vi kommer installera SDI korten och utveckla vårt program. På så sätt kan vi se var flaskhalsarna ligger, om sådana dyker upp, för att beställa passande komponenter. Utöver det har vi även grundliga redundansplaner som att ha en eller flera hårddiskar i raid per inspelningskort. Beroende på budgeten kan vi även kanske satsa på Solid State Diskar (SSD) för prestandan och för att undvika så mycket som möjligt rörliga delar. Alla andra komponenter kommer även att väljas noggrant enligt deras pålitlighet och stabilitet.

För användarens skull har vi också planer på att sätta ihop datorn i en praktisk låda som skall kunna monteras på standard rack. SDI kortens kontakter skall monteras på lådan så att om kablar rycks är det lådan som tar stryk och inte SDI-korten. Det svåraste blir egentligen att få till ett fungerande, pålitligt, stabilt och användarvänligt program.

Planering av mjukvaran

Vi har satt som preliminärt mål att maskinen skall kunna spela in 3 timmar av video per insignal, dvs totalt 6 timmar material innan diskarna behöver tömmas. Detta valde vi då det räcker till att spela in de flesta sportevenemang med god marginal. Med detta bestämt kan vi bemöta de grundproblemen vi ser framför oss. Hur och i vilket format skall materialet sparas ner för att på ett smidigt sätt kunna spelas upp och samtidigt inte kräva för mycket processorkraft eller arbetsminne. Utöver det måste vi hitta lösningar som hjälper oss utveckla programvaran.

Valet av programmeringsspråk föll på C#. Vi har tidigare programmerat i Java som ligger väldigt nära C# i syntax. C# är en del av .NET som är modernt och uppdaterat och har bra dokumentation från Microsoft. Vi skriver programmet i Microsoft Visual C# som förenklar GUI-programmeringen jämfört med att koda exempelvis med API:t Swing i Java.

För att prata med kortet valde vi att använda oss av DirectShow. Drivrutinerna till SDI-korten kommer med bra stöd för DirectShow, och det är möjligt att använda sig av DirectShow från .Net.

Directshow är ett slags API som på en relativ hög nivå tillåter hantering av data strömmar (bl.a. bild och ljud). Med hjälp av denna API går det att sätta ihop olika filter, decoders och encoders för att passa våra behov. Den har även en inbyggd så kallad Stream Buffer Engine vi tror blir perfekt för vår maskin.

Hårddiskar (tillverkarnas siffror)

Western Dig. Black Intel SSD X25 G2 Western Dig Velociraptor

Storlek (GB) 640 80 300

AccesTid (ms) 8,9 0,1 4,2

Läshastighet (MB/s) 85 230 103

Skrivhastighet (MB/s) 85 82,5 103

Pris (kr) 600 2200 1400

Hårddiskarna vi köpt Om budget tillåter skulle Snabbaste konsumenthårddisken vilja köpa dessa med rörliga delar

Figur 5 || Prestandatabell över tre hårddiskar.

(11)

Instant Replay maskin - LTU Page 11 Vi sätter då ihop en grund för hur vårt program skall funka genom att bygga en filtergraf till

Directshow. Oavsett graf krävs alltid minst tre komponenter. Ett så kallad ”Sourcefilter”, en

”Transformfilter” och en ”Render/Sink-filter”. En dataström måste alltså in i grafen via sourcefiltret som antingen kan hämta det från en fil eller i vårt fall Decklink SDI kortet. Därefter behandlas den av vanligtvis flera transformfiltrar som kan tolka, muxa, avmuxa, koda och avkoda dataströmmar. Till slut skickas dataströmmen (eller dataströmmarna) till ett renderingsfilter. De kan antingen skrivas till disk i form av en fil eller renderas och visas på skärmen. Till vår maskin behöver vi kunna konstant spela in dataströmmen. Dock vill vi samtidigt kunna läsa från denna fil. Det är där Stream Buffer Engine kommer in då endast den tillåter tack vare sitt format att man läser från en fil som inte är färdigskriven. Med hjälp av den kan vi skapa två Directshow grafer som ihop möjliggör vår maskin.

Den första grafen i figur 5 visar hur materialet skall sparas ner på datorn. Signalen som kommer in i kortet skickas till en splitter. Den ena signalen encodas och komprimeras i MPEG2 för att sparas på hårddisk i form av en buffrad dataström. Den andra renderas och visas på skärmen så att användaren kan se vad som spelas in. För att snabbt kunna hitta till en specifik bildruta valde vi att inrikta oss på intraframe-kompression. Det betyder att varje bildruta sparas för sig, utan att referera till andra bildrutor i dataströmmen.

Figur 6 || Två filtergrafer som tillsammans visar planeringen för hur vårt program är tänkt att funka – skapade i graphEditPlus.

(12)

Instant Replay maskin - LTU Page 12 Den andra grafen visar hur datan läses från den buffrade dataströmmen enligt användarens villkor.

Användaren skall kunna spola runt i buffern och välja vad han vill spela upp och i vilken hastighet.

Denna signal avkodas och delas än en gång. Den ena signalen går till skärmen så att användaren kan se vad han gör och den andra går till kortet och ut ur maskinen i önskat HD SDI format.

Det är just separationen av båda graferna, den som sparar ner på disk och den som läser ifrån disk, som gör programmet smidigt. Då kan man hur man vill styra över det sparade materialet och oberoende av vad man gör med det fortsätter insignalen att kontinuerligt spelas in i realtid.

Med dessa mål och planer i grunden börjar vi testa oss fram.

(13)

Maskinens utveckling Steg 1 - Trial and Error

I väntan på att få de beställda Decklink SDI-korten läser vi igenom manualerna på korten och den medföljande SDK:n. Vi läser även Programming Directshow for digital video and television samt all annan information vi kan hitta om ämnet. Det första vi märker är att Directshow är mer utbredd för användning i C++ och att stöd i bibliotek i C# inte är lika omfattande. Vi hittar även företaget

MediaLooks som erbjuder ett intressant SDK för just Decklink kort som stödjer C# och en eget Stream Buffer Engine som är mer modern än den Directshow har. Vår budget är dock för liten för detta inköp. Vilket är synd då vi efter påläsning lär oss att Directshows egna streambuffer engine som vi tänkt använda inte är tänkt att klara dataströmmar som är mycket större än 20Mbps. Detta kommer vi förmodligen överskrida om vi ska jobba med MPEG2-komprimerat 720p50 material. Vi räknar med ca 40Mbps dataström, åtminstone om denna skall återges utan märkbara komprimeringsartifakter.

Spekulationerna lämnar plats åt testandet av filtrer och format då Decklinkkorten levereras.

Det är härifrån ett konstant arbete för att hitta och testa olika filter och filtergrafer för att få

programmet att funka enligt våra önskemål. För detta sätter vi ena kortet i en testdator (där mjukvaran skall utvecklas) och ett annat kort i en fristående dator som enbart har i uppgift att skicka ut en signal. På så sätt får vi in till testdatorn en kontinuerlig testsignal att jobba med. Testsignalen skapar vi själv enligt de mål vi planerat att maskinen skall klara; dvs en 720p50 videosignal som skickas ut via SDI kortet. Signalen är en minut lång och

innehåller en detaljrik bild, en tidskod och en trekant som rör sig. Rörelsen och detaljrikedom tillåter kontrollen av komprimeringsartifakter och hack i bilden medans tidskoden visar oss hela tiden var i tiden vi ligger och hur noggrann vi lyckas programmera uppspelningen av signalen.

Användaren skall ju kunna spola fram och tillbaka på ett smidigt sätt och helst kunna ratta mellan specifika bildrutor (frames); därav tidskoden som visar tiden i HH:MM:SS:FF format (timmar, minuter, sekunder, frames)

Samtidigt som en i gruppen jobbar med testdatorn för att skapa en fungerande buffer engine enligt figur 5 försöker en annan i gruppen att utveckla styrningen av programmet via en bandarkontroll.

Den tredje i gruppen försöker hitta ett API som tillåter användaren att snabbt växla mellan de två inkommande dataströmmarna som ska visas upp.

Figur 7 || Testbilden vi skapat själv och använder oss av. Här stoppad vi 02 sek och 42 frames

Figur 8 || Bild av en Sony RM450CE bandarkontroll

(14)

Instant Replay maskin - LTU Page 14 Datahanteringssytemet

Det svåra med att få Directshows inbyggda buffer engine att fungera är att den endast kan spara ner material i dvrmsfiler av MPEG2 eller DV data. Först är själva dvrms-filformatet lite ovanligt och Microsoft verkar ha minimalt stöd för detta format. Dessutom är en av de två accepterade dataströmmarna DV vilket inte tillåter HD kvalité vilket vi skulle vilja uppnå för att göra en HDSDI maskin. Vi riktar därför oss in på att lyckas koda de inkommande insignalerna till MPEG2 för att sedan spara ner de som dvrms-filer via Directshows stream buffer engine.

GMFBridgeGraph är ett litet API som en Microsoft anställd satt ihop och delar ut på internet. Dess primära funktion som kommer många användare av Directshow till användning är möjligheten att koppla samman flera grafer på ett snabbt, sömlöst och smidigt sätt. Den bygger på att olika grafers strömmar kopplas ihop via en så kallad BridgeGraph där en enda SourceGraph kan välja vilken av dataströmmarna som ska visas för tillfället. Lite som en smidig växel som gör de olika graferna oberoende av varandra i likhet med en stream buffer engine. Det är med hjälp av en sådan vi vill sätta ihop varje inkommande Decklinkkorts graf för att kunna välja vilken av dataströmmarna som ska till det tredje DeckLinkkortet.

Figur 9 || Förenklad schema som visar hur GMFBridge kopplar samman båda insignalerna. Varje korts första grafruta representerar det som görs i figur 5.

GMFBridgegraph API:n är väldigt smidig då den har egna inbyggda möjligheter för att skapa smarta grafer av sig själv. Med detta menas att den själv skapar en graf med passande filter mellan ett

(15)

Instant Replay maskin - LTU Page 15 sourcefilter och ett sinkfilter. Det är dock denna funktion som gör det lite svårare för oss då vi vill använda våra egna färdigbyggda grafer och koppla samman dessa. I exempelkoden som följer med GMFBridgegraph spelas filer upp via en CreateSinkGraph- respektive en CreateSourceGraph-funktion.

Dessa märker vilka filter filen som ska spelas upp behöver och skapar en passande graf på direkten.

Vi vill som ovanstående figur visar koppla dit egna specifika grafer. För detta tvingas vi koppla GMF:s Sink filter till vår egen graf för hand. Likaså med GMF:s Source filter och vårt renderingskort. Det tog lite tid att sätta sig in i koden och hitta exempelkod från andra personer som velat åstadkomma samma sak men till slut får vi det att funka. Vi lyckas alltså via en simpel knapptryckning byta mellan vilken dataström som ska spelas upp och det går både smidigt och snabbt.

Bandarkontrollen

Vi har fått av Piteås medieinstitution en Sony RM450CE bandarkontroll. Denna har en ratt och flera knappar och borde på så sätt kunna programmeras till att styra vårt program. På så sätt efterliknar den mer en vanlig Multicam[LSM] kontroll än om vårt program styrts med mus och tangentbord.

Bandaren styrs av RS-422-protokollet via en COM port. Det första målet är att se om vi kan få någon signal överhuvudtaget från bandarkontrollen men detta visar sig lättare sagt än gjort. Efter att ha testat olika kablar och till och med en separat USB till RS422 adapter får vi inte någon kontakt från kontrollen. Vi felsöker i vårt program men då vi inte har tillgång till någon annan RS422 maskin är det svårt att felsöka. Vi lyckas dock simulera två COM portar och virtuellt koppla ihop dem. På så sätt kan vi testa om vår testmjukvara funkar och visst gör den det. Det vi tyvärr märker ganska fort efter testerna är att det inte verkar vara något fel med porten, mjukvaran eller bandarkontrollen själv då vi testat även den på en bandare. Det är någonting med signalen och dess protokoll som vi måste ha missförstått eller misstolkat men som vi inte lyckats klura ut.

Figur 10 || Enkel program som testar om porten COM5 får någon data. I det här fallet skickades data från det virtuella COM6 "hello world" som togs emot av COM5 porten.

(16)

Instant Replay maskin - LTU Page 16 Efter att ha fastnat i utvecklingen av en fungerande Sony bandarkontroll och en RS422-anpassad mjukvara inser vi att det enklaste funkar oftast bäst. Det som faktiskt behövs till vår maskin är knappar och ett joghjul. Dessa kan hittas för en ganska billig peng i form av ett USB-joghjul och en knappsats. Finns budget kan vi investera i finare former av hjul och knappsatser men tillsvidare blir detta mer än nog. Dessa passar dessutom för den användningen av gränssnittet som nu har framställts i en första version.

Gränssnittet

Det vi tänkte på då vi designade detta GUI är att visa på tydliga sätt det som användaren gör. Det skall vara lätt att se vad man gör med de olika klippen och lätt att följa med i ens arbetsflöde så att man kan alltid snabbt se vad man gör och var man är i sitt genomförande av en specifik uppgift.

Maskinen har två funktioner. Antingen är man i JOG läget eller i PLAY läget. I det förstnämnda kan man söka runt i materialet till önskad punkt både framåt och bakåt. Så fort man valt en RATE (uppspelningshastighet) och trycker på PLAY går man in i PLAY läget då materialet spelas upp i önskad hastighet. Hastigheten ska också kunna ändras under uppspelning.

På de fyra mindre skärmarna kan användaren se de två liveströmmarna respektive de två

reprisströmmarna. På den stora PGM OUT-skärmen visas vilken av reprisströmmarna som för tillfället skickas ut ur maskinen. Under den stora skärmen finns ett antal lysande markeringar som lyser olika beroende på vad användaren gör för tillfället. Vi hoppas även kunna implementera en stor tidsaxel som sträcker sig över hela skärmen för att visa användaren genomflödet av sitt arbete. På denna skall enbart tidskod, IN och OUT markeringar visas. Dessa gör det möjligt att snabbt spola till önskade markeringar på tidsaxeln. Under tidsaxeln visas de tre klippbankerna. I dessa kan användaren bygga spellistor eller enbart spara enstaka klipp så att han snabbt kan komma åt dem för uppspelning vid senare tillfällen. Längst ner finns utrymme att köa upp importerade klipp (vinjetter eller inslag) som alltid är redo att spelas upp.

(17)

Figur 11 || Ett schema över det GUI:t vi hoppas utveckla till vår maskin

Följande är de hittills planerade funktionerna:

 PLAY Sätter igång uppspelning i 100% hastighet från nuvarande position

 LIVEPLAY Hoppar till senaste möjliga tidskod och spelar upp därifrån i 100%

 JOG Stannar uppspelningen. Gör det möjligt att jogga runt i materialet

 LOG Skapar ett klipp av materialet mellan IN och OUT punkterna

 IN Sätter en IN markering på tidsaxeln (skriver över föregående IN)

 OUT Sätter en OUT markering på tidsaxeln (skriver över föregående OUT)

 BANK 1 Sätter bank 1 som den aktiva klipp banken.

 12.5% Sätter uppspelningshastigheten till 12.5% av den normala hastigheten.

 25% Sätter uppspelningshastigheten till 25% av den normala hastigheten.

Steg 2 – Ny grund tar oss till nästa steg

GMFBridge

Vid den här punkten förstår vi hur grafer och Directshow funkar. Vi har även testat olika

operativsystem (OS) och märkt att det är svårt att hitta ett bra MPEG2-encoderfilter då de som är bra kostar och de som är gratis är av sämre prestanda. Utöver det märker vi att dataströmmar som sparas i dvrms format har en samplefrekvens på 500ms. Detta innebär att det enbart går att hoppa steg på 500ms när man spolar runt i filen vilket omöjliggör en snygg tillbaka eller framspolning i vårt program. Då Windows 7 som vi jobbat med hittills saknar dessutom stöd för dvrms filer och det kan

(18)

Instant Replay maskin - LTU Page 18 ta månader innan den uppdateringen släpps slopar vi StreamBufferEngine. Då vi testat den i standard definition-formatet DV har den fungerat ganska bra, men samplefrekvensgränsen samt

krångligheterna med att få den att fungera med MPEG2 blev för mycket. Dessutom kändes de nya möjligheterna som GMFBridge erbjuder ganska lockande. Med hjälp av den sätter vi ihop ett nytt datahanteringssytem för att spara ner dataströmmar och spela upp dessa på önskat sätt. Detta med hjälp av GMFBridge API:t.

Framöver vill vi spara ner dataströmmen som en följd av 1 sekunder långa filer som sparar materialet i intraframeformatet motionJPEG (MJPEG). Detta gör det möjligt att spola runt i varenda frame för sig. För att få det att funka krävs en smart hopsättning av GMFBridges som jobbar var sin tur med att spara ner filen. Det viktigaste är att inga frames får gå förlorade varken vid sparning eller vid

uppspelning av filen vilket skulle förskjuta synkroniseringen av signalerna. Med sitt inbyggda buffer och smarta växlingsfunktion kan GMFBridge spara ner en fil samtidigt som den förbereder vägen för nästa dataström och nästa fil. Så fort första filen når sitt slut kopplas nästa graf in som då är beredd att spara ner fil nummer två. Under tiden återställs den första grafen och görs beredd för att ta emot fil nummer tre. Så fort fil två når sitt slut kopplas dataströmmen tillbaks till första grafen igen. På så sätt fortsätter filen att kontinuerligt sparas ner. Samma princip appliceras sedan vid uppspelning av de nedsparade filerna. Den enda begränsningen med detta system är att vi inte kan spela upp det som sänds direkt. I vårt fall, där våra filer är 1 sekund långa kommer vi alltid att befinna oss minst 1 sekund, plus eventuell buffer, efter realtiden. Detta tycker vi dock inte gör maskinen sämre då denna försening inte påverkar maskinens prestanda och påverkar endast minimalt dess användbarhet.

Vårt nya system bygger alltså på en loop mellan två grafer som skriver ner materialet och en till loop mellan ytterligare två grafer som turas om att spela upp materialet. Uppspelningsloopen kan till exempel beskrivas på följande sätt. Den består av tre grafer där två stycken turas om med att spela upp materialet. De två första graferna som heter LäsGraf1 repsektive LäsGraf2 ser likadana ut och består av ett FileSourceReaderFilter, ett omkodningsfilter och ett SinkFilter. Den tredje grafen består av ett SourceFilter och ett videoRenderingsFilter. Loopen startas med att LäsGraf1 läser in den första filen och kollar att det finns en färdig fil bakom denna. Den första filen läses upp och den andra filen görs beredd i LäsGraf2. När en fil tar slut aktiveras en funktion som meddelar LäsGraf2 att börja spela sin fil samtidigt som den kopplas till videoRenderingsFiltret. Samtidigt nollställs LäsGraf1 som då börjar förbereda nästa fil för uppspelning. GMFBridge lyckas växla sömlöst mellan de två graferna tack vare sin inbyggda buffer som sparar de sista bilderna på varje fil. Dessutom är varje graf beredd och startad innan den kopplas vidare.

Val av komprimering

När man sparar videomaterial blir det väldigt mycket data att hantera. Det bästa vore att spara ner allt material precis som det kommer in, men tyvärr är detta inte så smidigt. En bildruta av HD- material i upplösningen 720p, vilket är den upplösning vi jobbar med, tar med 10 bitars färgdjup 3,3MB utrymme. Vi sparar två stycken sådana signaler 50 gånger i sekunden vilket resulterar i en dataström på nästan 330MB i sekunden. Ska vi dessutom samtidigt spela upp en signal dubblas denna siffra. Det skulle de datorkomponenter vi har valt inte klara av men lyckligtvis finns det sätt att minska datamängden med hjälp av komprimering.

I det första stadiet fångas materialet med 8 bitars färgdjup i 4:2:2 chroma subsampling. Det betyder att färginformationen sparas med halva upplösningen mot ljusinformationen. Vi ser inte färger med

(19)

Instant Replay maskin - LTU Page 19 lika stor noggrannhet som ljus, så det märks inte att man kastar hälften av färginformationen. 4:2:2 räknas fortfarande som tillräckligt bra för att användas i professionell TV-produktion. Det som återstår komprimeras med MJPEG komprimering. Detta är en förstörande komprimering där man kan väga av hur mycket man komprimerar gentemot hur pass bra bild man vill ha kvar. En sekunds material i 720p50 blir nu endast några megabyte stor och ser fortfarande riktigt bra ut.

Som tidigare nämnt är MJPEG ett intraframe codec där varje bild sparas utan att referera till någon föregående eller efterkommande bild. Detta ger en större dataström men i gengäld kan man hoppa till vilken bildruta som helst utan fördröjning då en bild inte måste framräknas av många andra bilder. Då vi kommer behöva kunna hoppa runt i materialet väldigt fort är detta ett format som passar bra till vår maskin.

Hit men inte längre

Med hjälp av våra idéer tar projektet form och vi är nu vid punkten där vi har två fungerande och synkade men ändå självständiga recorders. Båda spelar in material kontinuerligt och vi kan på ett synkat sätt kontrollera uppspelningen av materialet. Det som krävs nu är ett sätt att välja vilket av signalerna som ska visas som PGM ut och därmed skickas ut via det sista SDI kortet – och här slår vi i väggen.

Hittills har vi delat på dataströmmen med hjälp av Directshows egna Smart Tee Filter. Dessa kräver dock att en klocka ”drar” i dem så att de förblir synkade och inte skickar vidare dataströmmen på ett okontrollerat sätt. Då vi försökte med ännu en GMFBridge koppla den ena signalen till det utgående DeckLinkkortet blev den andra signalen utan klocka vilket gjorde att den hamnade i osynk med resten av materialet. Vi påbörjade då en lång påläsning om Smart Tee samt Infinite Tee filter. Dessa två är de enda tillgängliga filter som duplicerar en dataström men båda utvecklades för ganska många år sen och många programmerare på internet rekommenderar idag att skriva och implementera ett eget så kallad splitter(delnings)-filter. Dessa skrivs dock i C++ och kräver delar från ett flertal

programmeringsbibliotek vi har alldeles för lite kunskap om. Vi försöker istället förstå hur Smart Tee och Infinite Tee funkar och är uppbyggda för att se om vi kan pussla ihop en lösning. Med enbart användning av Smart Tee filter funkar utsignalen men den dataströmmen som för tillfället inte visas i PGM ut hamnar efter. Med användning av endast Infinite Tee filter blir bilderna hackiga då detta filter prioriterar de två utsignalerna olika vilket gör att den ena hamnar efter den andra. En lösning vi testar är att skapa ett NullRenderer filter som kan fortsätta dra i den oanvända signalen medans den andra visas på PGM ut. På så sätt hoppas vi att denna förblir synkad. Även där sker tyvärr en

fördröjning. Oavsett försök får vi att förhandsvisningsskärmarna på GUI:t ser bra ut men PGM ut signalen blir hackig eller vice-versa. En helt och hållet ny lösning måste fram och efter några tuffa dagar fångas vår uppmärksamhet av ännu ett litet filter som kan rädda dagen.

Steg 3 – Dataflöde hela vägen

SampleGrabber

SampleGrabber är ett DirectShow-filter som ger en inbilck i mediaströmmen. Varje gång en bildruta eller annan mediadata passerar filtret kallas en funktion i koden. I den funktionen kan man sedan manipulera strömmen som man vill innan den skickas vidare ut igen.

(20)

Instant Replay maskin - LTU Page 20 Vi tänkte då att detta filter skulle kunna ersätta GMFbridge i vissa fall. Istället kopierar man datan från en sampleGrabber i en graf och klistrar in denna i en annan sampleGrabber i en helt annan graf.

På så sätt förbigår vi problemet med synkningen av GMFBridgegraphs i slutskedet på programmet.

SampleGrabber skulle även kunna användas för att fånga bildrutorna och sedan spara ner dessa till individuella bildfiler. Detta var även något vi testade, men vi lyckades inte nå den prestanda vi behövde för att kunna spela upp och spara ner två signaler på detta vis. .NET och C# har en del bibliotek för att komprimera bilder till JPG, men dessa är inte riktigt snabba nog för att komprimera de 100 bilder/sekund det rör sig om. Idén är ändå bra, och med varje bildruta sparad som en separat fil istället för i en DirectShow-vänlig AVI-fil skulle mycket annat underlättas. För detta behövs dock en mer optimerad komprimeringsalgoritm.

De MJPEG-filter som finns att välja på ger betydligt bättre prestanda och gör i grunden det vi vill, så vi väljer att fortsätta använda ett MJPEG-filter för komprimeringen.

Tredje gången gillt

Då vi insett att sampleGrabber inte kan ersätta hela systemet för datahanteringen i vårt program stod det ändå tydligt att en hel del kan ändras med hjälp av den och många system kan göras enklare och mer effektiva.

DirectShow vill hemskt gärna att allt ska vara uppstyrt som färdiga strömmar med förbestämt innehåll. Det vanligaste användningsområdet är att fånga en inkommande mediaström till fil, eller spela upp en mediafil på bildskärmen och/eller via ljudkortet. Detta görs som sagt via grafer som styrs av en klocka och mediabitarnas tidsstämplar. Vad vi hade problem med var att vi spelade upp flera DirectShow-grafer som internt hade varsin klocka baserade på olika faktiska klockor. Det vi egentligen ville var att all uppspelning skulle styras av klockan på utgående bilds SDI-kort. Vad vi till sist gjorde för att uppnå detta var att skapa en graf som genererade svarta bildrutor direkt till SDI- kortet. Mitt i denna satte vi en SampleGrabber. Det enda vi nu behövde göra var att leta reda på rätt bildruta och kopiera in denna i SampleGrabberns buffer innan rutan skickas vidare till kortet. På så sätt är själva renderingen ut till kortet bortkopplat från resten av programmet.

Vår nedsparningsklass fungerade mycket bra som den var. Den fick därför behålla sin utformning med en liten justering. Eftersom DirectShow är byggt för att hantera strömmar av data har det vissa begränsningar. Det är exempelvis svårt att fånga ett exakt antal bilder från våra SDI-kort till en fil. Vi kan däremot när filen är färdigskriven se hur lång den blivit. Vi kan även bli informerade varje gång en buffrad bildruta åker förbi en SampleGrabber. Det vi gjorde var helt enkelt att spara en lista med heltal där varje index står för bildrutans nummer och heltalet beskriver vilken fil bildrutan återfinns i.

Vi sparade också på samma sätt en lista som beskrev vilken bildruta varje fil börjar på. Denna information kan vi sedan hämta i vår nyskrivna uppspelningsklass.

(21)

Figur 12 || Schema over hur dataflödet ser ut I våra DirectShow-grafer.

För att leta upp rätt bildrutor och se till att det alltid finns något att kopiera till vår utgående bild skapade vi en ny klass i en egen tråd. Denna tråd snurrar på och har som uppgift att se till att buffern alltid fylls på med det som ska visas. Denna tråd har även den en DirectShow-graf som laddar in rätt fil beroende på vilken bildruta som ska visas och hoppar till rätt bildruta. Denna kopieras till RAM- minnet och sparas i en FIFO-lista (First in First Out). Så länge programmet är i uppspelningsläge försöker tråden hålla buffern fylld med upp till 50 bildrutor. När utgående signal vill ha en ny bild hämtar den helt enkelt den första bildrutan i listan, kopierar den över den genererade svartrutan och tar bort den ur listan. För att spela upp i en långsammare hastighet kopierar man helt enkelt bilden flera gånger innan man tar bort den ur buffern.

Varje input har en egen sådan tråd. För att skicka ut rätt bild väljer vi bara vilken buffer vi ska kopiera från. Det hela fungerar mycket smidigt, åtminstone för att vara byggt på DirectShow.

(22)

Figur 13 || Gränssnittet I sin slutgiltiga form.

Implementeringen av extrafunktioner

Har man en Instant-Replay maskin kan man ha den till mycket mer en bara snygga repriser och till viss mån försöker vi också ge vår maskin egenskaper och funktioner som gör den användbar och praktisk i ett flertal produktioner.

Tidsaxeln – en visuell hjälp

Tidskod är det EVS operatörer använder sig av för att hålla koll på var de befinner sig i sitt dataflöde och för att hålla koll på sina filer och klipp. Vi tycker dock att lite extra visuell hjälp kan förenkla användarens jobb genom att visa var han är i tiden och vad han gör för tillfället. En användare följer och bevakar det mesta av materialet och informationen med hjälp av sin syn. Istället för en skriven tidskod som kräver att operatören sätter denna tidskod i kontext kan han med hjälp av en tidsaxel direkt se var han är. Han kan följa tidens utveckling framåt eller bakåt samt se om han håller på att skapa ett klipp med hjälp av IN och UT markeringar.

Användaren kan därför behålla fokus på bilden samtidigt som korta sneglingar på tidsaxeln räcker för att försäkra sig om vad som faktiskt pågår istället. Pennan och pappret försvinner i fördel av klipp med redigerbara namn. Dessutom visar tidsaxeln var i dataflödet operatören är samt var tidigare klipp har sparats.

Klippbanker

Det är mycket praktiskt att kunna spola runt i materialet men detta kan över en längre tid bli alldeles för mycket för en människa att komma ihåg. Därför implementerar vi tre så kallade klippbanker. I dessa kan man spara specifika klipp som användaren själv skapat. Dessa kan omorganiseras och enkelt spelas upp igen vid valfritt tillfälle. På så sätt kan en användare enkelt välja att spara ner alla måltillfälle i en bank och alla häftiga tacklingar i en annan för att snabbt skapa spelningslistor som är redo för användning vid t.ex. nästa halvlek. Då vi tänkte på hur bankernas användning skulle ske tänkte vi på följande punkter.

(23)

Instant Replay maskin - LTU Page 23 - Det ska gå snabbt att spara ett klipp.

- Användaren ska lätt få en överblick för de klipp han har och arbetar med aktivt för tillfället - Få knappar och knapptryckningar räcker för styrningen av alla banker och klipp

- Det ska bli omöjligt att krocka mellan banker, dvs. att arbetet sker en bank åt gången.

Figur 14 || Exempel på hur klipp ser ut sparade I en klippbank.

Ett klipp i vårt program definieras av fem parametrar – ett namn, en IN punkt, en UT punkt, en Go To Next boolean och ett Input heltal. När användaren har satt ut med hjälp av joghjulet IN och UT markeringar blir det möjligt att spara ner klippet i den förvalda banken med hjälp av LOG knappen.

Då skapas ett klipp som läggs till i bankens klipplista. Denna lista syns på GUI:t i form av en så kallad ListView där alla fem parametrar syns. Med hjälp av knappar kan varje parameter ändras när som helst till att passa användaren. Namnet kan enkelt bytas ut för att göra sin lista mer tydlig för en själv.

Go To Next boolean som kan sättas till true eller false bestämmer om uppspelningen automatiskt ska hoppa till nästa klipp när första klippet har spelat klart. Input parametern sparar vilken Input som var vald då klippet sparas (1 eller 2) men kan ändras till valfri för uppspelning. Det går även att redigera IN och UT punkter till en viss del. Med detta menas att de inte kan ändras på det klippet som faktiskt redan är sparad men varje gång ett klipp väljs laddas IN och UT punkterna ut till GUI:t och kan då lätt justeras för att spara ner klippet igen med de nya och ändrade IN och UT punkter.

Med hjälp av en Go To Clip metod kan man enkelt hoppa till valfritt klipp i valfri bank och med Play Clip kan man lika enkelt börja uppspelningen av ett enskilt klipp eller ett flertal klipp efter varandra.

Med allt ovanstående i tankarna kom vi fram till att en av de tre bankerna alltid skulle vara aktiv medans de två andra inte gick att nå. Användaren får alltså en knapp per bank som gör just denna klippbank aktiv medans de två andra avaktiveras. På så sätt behöver inte alla banker en egen

knappuppsättning då alla bankrelaterade knappar jobbar med den banken som är vald. Då räcker de följande knappar till att styra över alla banker och klipp på ett avancerat men användarvänligt sätt.

- Bank1/Bank2/Bank3 Tre knappar som aktiverar respektive bank.

- LOG Om möjligt skapas ett klipp av de valda IN och UT markeringarna - Go To Clip Hoppar i tidskoden och materialet till det valda klippets IN punkt - Play Clip Börjar uppspelningen av det valda klippet

- Go To Next Sätter Go To Next värdet på det valda klippet (true eller false) - Input Sätter Input värdet på det valda klippet (1 eller 2)

- Remove Clip Tar bort det valda klippet från banken - Move Clip Up Flyttar det valda klippet uppåt i listan - Move Clip Down Flyttar det valda klippet ner i listan

- Plus / Minus Två knappar för att välja vilket klipp som är vald i en specifik bank Med dessa få knappar kan användaren göra i stort sett allt han vill med ett klipp. Det går enkelt att

spara kopior i olika banker och bygga ihop flera klipp till specifika uppspelningslistor. Samtidigt

(24)

Instant Replay maskin - LTU Page 24 hjälper varje banks ListView att grafiskt hålla koll på vad man gör och vilka klipp man har tillgängliga.

Utöver det har vi gett varje bank en färgkod där bank1 är röd, bank2 är grön och bank3 är blå. Varje sparat klipp i en bank syns i sin respektive färg på tidsaxeln så att användaren lätt kan se vad han har

sparat och i vilken bank det klippet finns. På så sätt kan han behålla fokus på det som händer för tillfället istället för att undra om han redan har sparat ner ett klipp eller inte.

Figur 15 || Knappsatsen med dess slutgiltiga layout.

Externa filer

Det är inte ovanligt att något dyker upp i sista stund med en eller flera videoklipp som måste visas under programmet. Den importfunktion vi vill implementera skall möjliggöra detta. Med hjälp av en enkel men genomtänkt spellista som även den är en ListView skall användaren lätt kunna importera externa filer och organisera de i spelordning för att spela upp de vid önskat tillfälle.

På grund av strukturen på den uppspelningskoden vi skapat med hjälp av Directshow och GMFBridge måste alla filer som spelas upp i vår importdel vara av samma format som första filen som

importerades in i programmet. Dessutom måste filer hålla vissa specifikationer för att kunna kodas om av DeckLink kortet till en HDSDI signal.

För att lösa detta testade vi ett program som heter AviSynth. Via en .avs fil som innehåller några rader kod (script) kan videofiler kodas om i realtid. Eftersom DirectShow har stöd för att spela upp dessa scriptfiler verkade det vara en bra lösning på problemet. Vi skrev därför ett script som kollar om videons upplösning och ljud stämmer överens med de krav maskinen har, samt om materialet är interlaced. Om ett klipp inte uppfyller kraven kodas den om live av AviSynth. Tanken med en script var att inte hela filen behövde kodas om utan bara de delar som inte uppfyllde kraven. Om t.ex.

endast ljudet inte följde specifikationerna ändrade scriptet bara ljudet. Nackdelen med denna lösning

(25)

Instant Replay maskin - LTU Page 25 är att det kräver mycket processorkraft. Att spela upp en fil tar ungefär 20 procent av

processorkraften och över 100mb RAM-minne. För att kunna spela upp filerna sömlöst var vi tvungna att hela tiden ha två förladdade filer vilket blir för mycket för maskinen att hantera då den

fortfarande måste kunna spara ner allt material från båda signalingångarna. Vi gick då tillbaka till att bara stödja ett enda filformat. Detta begränsar användarvänligheten då användare måste veta precis vilken typ av fil de måste ha för att kunna spela upp dem i maskinen men samtidigt drar detta väldigt lite kraft. Formatet valdes både för att passa maskinens utsignal och för att vara lätt för studenter att exportera på skolans datorer. Det blev då 1280x720 progressiv 50 fps h.264 codec i .mov container med okomprimerat PCM 48kHz ljud. För enkelhetens skull kommer vi ge lärarna en exporteringsprofil de kan ha till Final Cut Pro.

Uppspelningen av externa filer sköts av tre DirectShow-grafer, två läsgrafer som läser in videofilerna och skickar dem till ett sinkfilter och en renderingsgraf som har ett sourcefilter och kan växla mellan läsgrafernas sinkfilter. Renderingsgrafen skickar den valda strömmen till en SampleGrabber som utsignalen kan välja att hämta bildrutor ifrån.

Figur 16 || En första version av Importfunktionen som skall implementeras längst ner på den slutgiltiga GUI:t i vårt program (se figur 10).

Förutom denna begränsning i filformat är dock importfunktionen väldigt smidig. Tack vare den kan vår maskin enkelt spela upp inslag, en åt gången eller efter varandra. Det går även att loopa ett enskilt klipp eller en hel spellista. På så sätt kan maskinen i nödsituationer till och med användas till att skapa loopande bakgrundsgrafiker. GUI:t utvecklades för att vara så lättförstått, smidigt och användarvänligt som möjligt. De importerade filerna hamnar i en ListView. Denna Importfunktion bakades in i resten av GUI:t och programmet som en 4:e klippbank. Den styrs på samma sätt som klippbankerna och antingen är denna aktiv eller så är en av bankerna aktiv.

Med dessa få men praktiska och enkla funktioner blir maskinen plötsligt även en inslagsmaskin som gör denna ännu mer användbar och mångsidig vid till exempel små OB-produktioner.

(26)

Slutfasen – Maskinen tar form

Val av operativsystem

Som nämnt i kapitlet ”Steg 2 – Ny grund tar oss till nästa steg” bestämde vi att testa ett annat OS än Windows 7 då detta inte än har stöd för dvrms-filer. Då ingen av oss har större erfarenhet med Linux kändes det onödigt krångligt att testa sig på det. Mac och dess OS var definitivt inga alternativ då Mac datorer inte går att anpassa på samma sätt som PC och Mac delar är även dyrare än flesta PC delar. Vi har dessutom störst erfarenhet med Windows och Microsoft har faktiskt väldigt mycket dokumentation och stöd för sina OS. Det fick därför bli Windows XP då är tillräckligt gammalt för att ha uppdaterats till att bli väldigt stabilt.

I led med de försök att göra maskinen mer användarvänlig startas programmet automatiskt när maskinen startas. Vi har även gömt undan systemfiler som inte behöver kommas åt med hjälp av

”hide” funktionen i Windows. Detta hindrar inte folk från att rota runt på dumma ställen i maskinen, men det kanske hindrar några från att oavsiktigt göra något dumt.

Kontinuerliga tester

Efter 16 veckor av utveckling och programmering sedan projektet börjades når vi äntligen fas 3 i vårt projekt. Vi det här stadiet är grundfunktionerna, nedsparningsgraferna samt uppspelningsfunktioner färdigimplementerade. Allt som återstår är att koppla ihop alla programrutiner till ett

sammanhängande och buggfritt program.

Steg för steg implementeras de olika funktionerna som styr dataströmmen. Olika kommandon ges till knappar och GUI:t tar form på riktigt. Det mest intressanta i denna fas av utvecklingen är ändå återkopplingen man kan göra med våra tidigare mål samt hur vi planerat och tänkt olika funktioner.

När dessa nu tar form upptäcker vi att vissa saker funkar precis som vi tänkt medans andra är opraktiska och onödiga eller funkar rentav inte alls. Allt blir som ett stort pussel där bitarna sätts ihop. Vissa bitar passar perfekt men andra måste filas och justeras och ett fåtal måste till och med tas bort. För varje funktion som implementeras kommer vi på en rad olika tester som måste genomföras för att göra koden mer buggfri. Implementeringen av klippbankerna är ett typisk sådant exempel där vi ett bra tag testade olika sätt att kontrollera klippen. Antingen med hjälp av mus och tangentbord eller endast via knappar. Vi testade även hur de skulle kunna representeras grafiskt och med hjälp av den kunskapen vi fått under studiebesöket i Skellefteå men även tack vare våra många kurser i bildproduktion kan vi föreställa oss vad en användare vill få ut av maskinen. Vad som är onödigt eller jobbigt samt vad som man snabbt vill veta och kunna göra. Därpå gjordes stabilitetstester. Under dessa trycker vi på kommandoknappar och aktiverar så många funktioner som möjligt på så många olika sätt som möjligt för att kontrollera att inget oönskat händer.

Då vi inte har budget till att göra maskinen så redundant som möjligt på hårdvarunivån försöker vi åtminstone göra det på mjukvarunivån. Programmet får inte bugga för att användaren tryckt vissa knappar i en viss kombination eller vid ett visst tillfälle och därför spenderar vi nu i fas 3 många timmar på att testa olika möjligheter. En bugg som t.ex. trädde fram är att maskinen inte kan användas i mer än ca 20min då vissa grafer fastnar i RAM-minnet som långsamt fylls upp. Ett annat problem är att det inte ska gå att bugga maskinen genom att hamra på vissa knappar. Vi märkte under ett studiebesök att användarna kan trycka otaligt många gånger på samma knapp och detta skall inte få störa programmet. Vi kom också på iden med att koppla varje bank till en färg för att göra det lättare för användaren att veta vilken bank han jobbar i. Alla dessa detaljer och tester är

(27)

Instant Replay maskin - LTU Page 27 tidskrävande och ganska jobbiga då många if satser och booleans måste insättas i koden för att vissa rutiner skall anropas vid önskade och specifika tillfällen. Det finns på så sätt väldigt mycket kod som måste avskärmas från användaren. Denne skall ju inte kunna spola förbi det inspelade materialet eller ta bort klipp som spelas. Det skall inte heller gå att aktivera två banker samtidigt eller spara ner ett klipp vars UTpunkt ligger före INpunkten. Dessa exempel och många till gör koden lite mer komplicerd för varje tillägg. Det är många saker att komma ihåg och det kan ta ett antal tester innan en funktion är implementerad som den ska.

Synkroniseringsproblem

Ett problem vi stötte på i våra tester var att signalerna lätt kunde hamna ur synk. Med två stabila insignaler i en TV-studio är detta inget stort problem eftersom de kommer leverera bildrutor synkroniserade av en extern klocksignal. I våra tester har vi dock stött på en del problem. Om en bildruta inte kommer fram som den ska skrotas denna och den signalen blir en bildruta för kort.

Samma problem uppstår om kamerorna inte är externt uppsynkade. En kamera kan då ha en intern klocka som går lite fortare än den andra vilket leder till problem efter en längre tids inspelning. Vi hade också problem när vi kopplade ur en signal och kortet gick helt efter systemklockan i datorn.

För att lösa detta problem lade vi till en liten funktion som varje gång insignalen delas av i en ny ensekundersfil kollar ifall det finns lika många bildrutor sparade från båda signalerna.

Förhoppningsvis är det så, men om en signal skulle råka vara kortare än den andra dubbleras den senaste bildrutan tills de är lika långa igen. Detta skulle kunna uppfattas som hack i signalen, men detta fenomen ska inte uppkomma särskilt ofta och synkroniseringen är viktigare enligt oss.

(28)

Diskussion och framtida utsikter Nåddes de olika målen?

I kapitlet om våra målsättningar listades fyra stycken mål som vi själva satte i början av projektet.

Dessa ligger till grunden för vad vi hela tiden försökt nå och grundar sig på den användning vi tror att maskinen kommer få. Beställd av Institutionen för musik och medier i Piteå är detta en maskin som delvis kommer ha ett utbildningssyfte. Vi vill alltså efterlikna EVS Instant-Replay maskiner som används flitigt i många produktioner. Samtidigt vill vi ändra och förbättra en sådan enligt de tankar och idéer vi utvecklat. En annan väsentlig punkt är den lilla budgeten vi fick att jobba med. Alla dessa faktorer påverkade de målsättningar som sattes fast i början av projektet och som vi nu ska

återkoppla vårt arbete till.

 Maskinen skall i dess grundprinciper och funktioner efterlikna en modern Instant-Replay maskin av typen Multicam[LSM]. Maskinen skall alltså kontinuerligt kunna spela in två skilda signaler och samtidigt spela upp en signal. Det skall även gå att ändra

uppspelningshastigheten.

Med hjälp av Directshow och GMFBridge lyckades vi sätta ihop ett datahanteringssystem i vår maskin. De hinder vi överkom var att datorn och dess hårdvara skulle klara av hanteringen av den mängd data som 2 HD-SDI dataströmmar har. Detta samtidigt som det går att spela upp en av strömmarna från valfri tidspunkt. Mjukvaran fick därför anpassas och justeras så att processorn respektive RAM-minnet räckte till och inte fylldes av data. Det avgörande på processorkraftsidan var att vi hittade en MJPEG encoder/decoder som var mindre krävande än andra vi testat. Med hjälp av smidiga filter och funktioner blev det då ganska enkelt att implementera funktioner som styr över uppspelningshastigheten. Det var därför en positiv känsla att avklara denna första målsättning som faktiskt är den viktigaste av alla fyra.

 Maskinen skall kunna spela in och spela upp i HD/SD-SDI med embeddat ljud.

Då fas 2 av utvecklingen tog så lång tid (ovanstående målsättning) fanns det mycket lite tid kvar att implementera kod som möjliggör att insignalen även kan vara SD-SDI. Det skulle rent praktiskt gå att implementera så att maskinen kan ha ett HD-SDI läge och ett SD-SDI läge beroende på vilka signaler man vill få in i maskinen men detta skulle helt enkelt kräva mer tid vilket vi tyvärr prioriterade bort då vi tyckte andra punkter var viktigare.

Att skicka ljud igenom maskinen är också en punkt som hamnat efter i prioriteringen. Då

maskinens primära funktion är att spela upp repriser i valbara hastigheter tycker vi att det räckte om vi implementerade ljud på de importerade klippen. Detta än en gång för att tiden inte räckte till. Det är dock även här möjligt att i ett senare skede vidareutveckla maskinen till att kunna hantera embeddat ljud på sina SDI insignaler. Detta skulle dock med nuvarande

datahanteringssystem kräva en del jobb då ljudet skulle tvingas sparas helt för sig för att sedan synkroniseras upp med bilden igen i slutet av dataflödet

(29)

 Operatören skall kunna skapa spellistor av klipp från både insignaler eller externt sparade filer och spela upp de vid önskad tid.

Som tidigare nämnt lyckades vi implementera både klippbanker och klippImport funktioner. Den förstnämnda funktionen finns i EVS Instant-Replay maskiner och kändes nästan som ett måste för att ge maskinen ett användarvärde. Med möjligheten att skapa klipp och spellistor av det

nedsparade materialet blir möjligheterna av vad man kan göra med maskinen så mycket större.

Om än begränsad lyckades vi ändå implementera möjligheten att importera filer via t.ex. ett USB minne. Filerna måste hålla ett visst format men detta ger ändå än möjligheten för maskinen att användas som inslagsmaskin.

 De avancerade funktionerna såsom skapandet av spellistor skall styras via ett nyutvecklat och användarvänligt Graphical User Interface (GUI)

På en vanlig EVS Instant-Replay maskin arbetar användaren med en Multicam[LSM] och vanliga monitorer som visar de olika signaler som maskinen jobbar med. De EVS operatörer vi pratat med är väldigt nöjda med EVS system. Vi upplevde dock att detta påverkas mycket av den

komforten av att använda sig av samma maskin och system så länge. Då andra system med andra GUI:n är nästintill obefintliga finns inga empiriska argument för hur bra EVS GUI faktiskt är. Även om det onekligen är ett fungerande och faktiskt mycket smart system tycker vi flera saker skulle kunna förbättras genom att skapa ett GUI som ger användaren mer information om hans arbete med klippbankerna. Dessutom samlas all information på en skärm vilket möjliggör en snabb överblick av arbetet.

Framtida förbättringar

Efter att ha utvecklat denna prototyp har vi upptäckt maskinens begränsningar och möjligheter. Vi har också lärt oss mycket om datahantering och GUI programmering. Med dessa kunskaper och erfarenheter i bagaget har vi redan nu idéer på ändringar som skulle kunna förbättra maskinen. De följande punkterna blev alltså inte implementerade i vår maskin men de är ändringar vi skulle vilja göra i en nyare version av maskinen.

Ett datahanteringssytem grundat på JPEG bilder är det första och största ändringen vi skulle vilja genomföra. För tillfället är allt inspelat material en följd av 1 sekund långa videofiler. Som tidigare nämnt beror detta på den begränsade prestandan i .NETs jpeg-algoritmer. Med hjälp av bättre prestanda och bättre kod tror vi dock att allt material skulle kunna sparas som en följd av JPEG bilder där varje bild är en videoframe. All datahantering skulle då bli smidigare att jobba med och

hanteringen av olika signaler samt uppspelningssystemet skulle förenklas.

I vår maskin har vi en otymplig Importfunktion. Den kan bara spela upp en typ av filer och man kan inte styra över dessa filers uppspelningshastigheter eller IN och UT punkter. Vi hann heller inte implementera den Exportfunktion vi hoppades skriva som skulle tillåta användaren att spara enskilda klipp som filer på maskinens egen hårddisk eller på ett separat USB-minne. Däremot har vi en idé om hur både import- och exportfunktionerna skulle kunna bakas ihop till en klippbank. Maskinen skulle kunna ha en dedikerad hårddisk för klipp. I den skulle man kunna spara klipp som skapats av det

Live slow motion: from idea to product

E X A M E N S A R B E T E

Live Slow Motion

- from idea to product

Johan Gavelin Joachim Koitsalu

Carl Lindqvist

Förord

Sammanfattning

Table of Contents

Inledning

EVS – standard i en bildkontroll Vad är en Instant-Replay maskin?

Gränssnitt

Studiebesök i Skellefteå

Våra målsättningar

Planering av hårdvaror

Planering av mjukvaran

Maskinens utveckling Steg 1 - Trial and Error

Steg 2 – Ny grund tar oss till nästa steg

Steg 3 – Dataflöde hela vägen

Implementeringen av extrafunktioner

Slutfasen – Maskinen tar form

Diskussion och framtida utsikter Nåddes de olika målen?

Framtida förbättringar