2010:046 civ examensarbete live slow motion

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 SystemteknikAvdelningen för Medieteknik

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

Instant Replay maskin - LTU

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


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.


Table of Contents Förord ...................................................................................................................................................... 2

Sammanfattning ...................................................................................................................................... 3

Inledning .................................................................................................................................................. 5

EVS – standard i en bildkontroll .............................................................................................................. 6

Vad är en Instant-Replay maskin? ....................................................................................................... 6

Gränssnitt ............................................................................................................................................ 7

Studiebesök i Skellefteå ...................................................................................................................... 8

Våra målsättningar .................................................................................................................................. 9

Planering av hårdvaror ........................................................................................................................ 9

Planering av mjukvaran ..................................................................................................................... 10

Maskinens utveckling ............................................................................................................................ 13

Steg 1 - Trial and Error ....................................................................................................................... 13

Datahanteringssytemet ................................................................................................................. 14

Bandarkontrollen ........................................................................................................................... 15

Gränssnittet ................................................................................................................................... 16

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

GMFBridge ..................................................................................................................................... 17

Val av komprimering ..................................................................................................................... 18

Hit men inte längre ........................................................................................................................ 19

Steg 3 – Dataflöde hela vägen ........................................................................................................... 19

SampleGrabber .............................................................................................................................. 19

Tredje gången gillt ......................................................................................................................... 20

Implementeringen av extrafunktioner .............................................................................................. 22

Tidsaxeln – en visuell hjälp ............................................................................................................ 22

Klippbanker.................................................................................................................................... 22

Externa filer ................................................................................................................................... 24

Slutfasen – Maskinen tar form .......................................................................................................... 26

Val av operativsystem ................................................................................................................... 26

Kontinuerliga tester ....................................................................................................................... 26

Synkroniseringsproblem ................................................................................................................ 27

Diskussion och framtida utsikter ........................................................................................................... 28

Nåddes de olika målen? .................................................................................................................... 28

Framtida förbättringar ...................................................................................................................... 29

Maskinens framtida utsikter ............................................................................................................. 30

Slutsaster ............................................................................................................................................... 33

Slutord ................................................................................................................................................... 33

Referenser och hjälpmedel ................................................................................................................... 34


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.


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


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


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.


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.


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.


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.


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.


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


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


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.


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.


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


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


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.


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.


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.


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.


- 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


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


ä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.


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


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.


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


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


material som går igenom maskinen men man skulle även kunna ha klipp från externa källor (USB-

minnen eller från andra datorer om maskinen är kopplad på något nät). Denna hårddisk skulle bli en

central hub där alla klipp skulle kunna sparas, t.ex. höjdpunkter från tidigare sändningar eller

vinjetter och inslag som behövs i produktionen. Denna hårddisk skulle liksom den nuvarande

Importfunktionen representeras i GUI:t som en klippbank. Detta skulle förverkliga

inslagsmaskinsfunktionen och den mångsidighet vi vill ge vår maskin.

En annan förbättring vi vill jobba på är antalet insignaler maskinen har. I vår prototyp satte vi som

mål att hantera 2 stycken. Detta både av budgetskäl men även för att två signaler kändes som en bra

gräns för vår första prototyp. Klarar vi att programmera hanteringen av 2 insignaler borde det bara

vara en fråga om tid och justeringar för att implementera fler. Nu när vi vet vad implementeringen av

2 insignaler kräver samt hur mjukvaran och GUI:t måste skrivas för att kunna hantera flera signaler

kan vi planera för fler insignaler. Med fler hårddiskar, bättre processorkraft, bättre kod och mer tid

borde det därför i en framtida maskin vara möjligt att ha t.ex. 4 insignaler.

En sista funktion som skulle öka maskinens värde är möjligheten att mixa mellan de olika

insignalerna. Vid uppspelning sker just nu raka klipp när det klipps mellan de olika signalerna. Det

vore därför smidigt att kunna välja om övergångarna mellan klipp antingen sker via mix eller via raka

klipp. Detta skulle då ske internt med hjälp av programmeringen av de sampleGrabbers som hanterar

signalerna.

En ordentlig implementering av alla dessa funktioner tror vi skulle göra vår Instant-Replay maskin till

en värdig konkurrent i branschen då dessa är de grundfunktionerna som förväntas av en Instant-

Replay maskin.

Maskinens framtida utsikter Tack vare sina klippbanker och sin Importfunktion är vår maskin mångsidig. Allt som går in i maskinen

sparas och kan spelas upp igen. Dessutom kan externt material laddas in via t.ex. USB minne vilket

gör att maskinen kan på OB produktioner även användas som en enklare inslagsmaskin. Med tidigare

OB produktioner vid Institutionen för media och musik i Piteå i tankarna har vi försökt ge framtida

bildproducenter en maskin som kan göra mycket. Allt detta samtidigt som den i grunden är lik en EVS

maskin vilket ger användaren erfarenhet.

Vi ser ingen realistisk chans att konkurrera med EVS eller GrassValley på deras marknader men

förnekar inte heller vår maskins starka punkter. För det första är den billig att bygga. Delarna

maskinen består av är vanliga datordelar som vem som helst kan beställa på de vanligaste

datorkomponentsbutiker.

- Processor: Intel core i7 860 – 2500kr

Denna valdes för att den är både bra på att arbeta med flera trådar

samtidigt som att den vid köptillfället var mest prisvärd

Kylare NH-U9B – SE2 – 525kr

Lagom stor och kyler bättre än standard processorkylaren. Medger viss

överklockningsmarginal.

- HD/SDI-kort 3 st DeckLink SDI Blackmagicdesign – 7500kr


Dessa kort hade både bra omdömen och var helt enkelt billigast på

marknaden. Dessutom följer med ett SDK som möjliggör utvecklingen

av egen mjukvara.

- Moderkort: Gigabyte p55-ud4 – 1600kr

Moderkortet valdes för att den hade tillräckligt med PCI platser (minst

3st utöver grafikkortets plats) och har fått goda omdömen.

- RAM-minnen: 2st Corsair Dominator 1600 MHz 2GB – 1400kr

Känd tillverkare med vältilltagen kylning. De går dessutom att använda

på lägre frekvenser för att bli mer stabila vilket vi gör.

- Grafikkort: ATI HD4350 – 350kr

Detta kort är fläktlöst vilket minskar antalet rörliga delar i maskinen och

i förlängningen chansen att något går sönder. Den är dessutom billig

och räcker väl för den användning vi planerat.

- Hårddiskar: 2st Western Digital Black 640GB – 1000kr

På dessa ska datat sparas. Se figur 5 på sida 11 för specifikationer.

1st Intel SSD X25 V – 1000kr

Operativsystemet installeras på denna då denna blir en bra och snabb

systemdisk.

- Nätaggregat: Corsair HX650 – 1200kr

Senaste modellen med endast en 12V-lina vilket förbättrar dess

prestanda.

- Skärm: Samsung Syncmaster 2233 – 1000kr

Praktiskt demonterbar fot, full HD upplösning (1920x1980), 16:9 format

- Knappsats XKeys Professional (58 knappar) – 2200kr

58 modulära knappar som kan namnsättas och programmeras enligt

våra önskemål. Billig men professionell lösning som passar bra till

maskinen.

- Joghjul Contour ShuttleXpress – 500kr

Denna kontroll kan via USB enkelt kopplas till vår maskin. Den har

dessutom medföljande mjukvara för att snabbt och smidigt kunna

programmera enligt våra önskemål. Billig för att vara ett joghjul och

sitter bra i handen.

Kostnaden för maskinens delar hamnar alltså på 21000kr. Priset och dessa möjliga förbättringar gör

att en billig men proffsig maskin skulle kunna utvecklas till att bli som en mindre variant av EVS- och

GrassValley-maskinerna. Det finns då möjligheter att nischa sig hos kunder som söker en mångsidig,

enklare men framförallt billigare variant av en vanlig Instant-Replay maskin. Det har varit svårt att

undersöka om vad en Multicam LSM med XT2 server kostar men i VästerviksTidningen från 2008-05-

13 finns en artikel i vilken en skola fått köpa en sådan maskin för 1 miljon kronor.


I utvecklingen av vår prototyp lade vi ner cirka 640 timmar per person. Det vill säga en summa av

1920 timmar. Med dessa siffror och de erfarenheterna från utvecklingen av prototypen kan vi göra

en prognos över kostnaderna för utvecklingen av en förnyad och förbättrad version av vår maskin. I

följande prognos räknar vi med att det skulle ta oss ungefär dubbelt så lång tid att utveckla den nya

versionen av maskinen.

I ovanstående kalkyl kan man då se att kostnaden för en enda maskin hamnar på 680tkr. Om man

dessutom lyckas sälja flera stycken kan de rörliga kostnaderna (löner) och andra fasta kostnader

(lokal med mera) slås ut över flera maskiner. Planerar man att sälja 10 maskiner kan priset sättas på

650 000 / 10 = 65 000kr. Lägg till de 30 000 för hårdvarorna kostar en maskin totalt 95 000 kr.

Planerar man att sälja så många som 20 maskiner hamnar det totala priset på 65 000 kr per maskin.

Dessa beräkningar är spekulativa, ungefärliga och planerar inte för vinst men visar vilka möjligheter

en sådan produkt kan ha på marknaden. Dessutom kan fokus i försäljningen ligga på att vinna andelar

av marknaden ej än nådda av vanliga och dyra Instant-Replay maskiner. På så sätt kanske köpare

senare uppgraderar sig till större, mer komplexa, mer funktionsspecifika och dyrare maskiner.

Det går att spekulera mycket om hur framtiden kommer se ut men på många håll effektiviseras

maskiner samtidigt som de måste kunna klara av fler uppgifter. Dessutom måste maskinen ha ett

konkurrenskraftigt pris och det är just dessa tre punkter vi tänkt på då vi utvecklat maskinen.

Idag styr marknaden vilka maskiner som används. Den bästa maskinen behöver inte vara den som

används mest. En annan äldre maskin kan dominera marknaden då den har många invanda

användare. Företagen vill slippa köpa in nya maskiner och träna upp personalen till nya gränssnitt.

Därför försökte vi skapa en Instant-Replay maskin som är mer än det. Allra viktigast är dock

maksinens pålitlighet. I TV-branschen måste köpare och användare kunna lita på maskinen. Den får

inte krångla under sändning då det ofta handlar om väldigt stora summor pengar. Fokus på hur

robust maskinen och dess kod är har därför varit stort. För att maskinen skall ha en framtid på

marknaden måste den få ett förtroende från branschen.

Figur 17 || Ungefärlig uppskattning över kostnaden för utvecklingen av en ny prototyp


Slutsaster Vi lyckades med att färdigställa en fungerande prototyp som levde upp till många av de

målsättningar vi haft. Dagens PC-datorer är definitivt tillräckligt välpresterande för att klara av att

hantera flera parallella bildströmmar i HD-kvalitet.

Vi valde att använda Microsofts DirectShow för att enkelt kunna implementera olika

tredjepartsprodukter för kodning och avkodning på ett enkelt sätt. Även om detta fungerade till vår

prototyp har vi kommit fram till att det inte är helt lämpat för den här typen av applikationer. I en

eventuell framtida lösning kommer vi titta på andra alternativ.

Maskinens grundläggande funktionalitet liknar till viss del den etablerade standarden med styrning

via joghjul och knappsats. Till slut hamnade fokus mer på användarvänlighet och en enkel

presentation av data till användaren.

Slutord Allt som allt har detta varit en mycket lärorik tid då vi alla tre som var med och utvecklade denna

maskin lärt oss mycket om ämnet men även om hur det är att i grupp framställa en produkt från

planeringen till leverans. Även om ingen av oss vet vad framtiden håller för denna maskin eller oss

själva är vi alla nyfikna över hur maskinen kommer i de kommande månaderna mottas av

studenterna i Piteå. Är reaktionerna positiva och något företag visar intresse för vårt arbete kanske

projektet kan vidareutvecklas och en ny och bättre maskin blir följderna av vårt arbete. Förutom

maskinens användbarhet och pris blir den största utmaningen att övertyga potentiella köpare om

maskinens pålitlighet. En utmaning vi kanske tar på oss.


Referenser och hjälpmedel

Litteratur

- Mark D Pesce, (2003), Programming Directshow for digital video and television, Microsoft

Press, Redmond Washington

- Peter D Symes (2004), Digital Video Compression, McGraw Hill Companies, ISBN 0-07-

142487-3

- Mats Danielsson, (2001), Teknisk Psykologi, Berlings Skogs Ab, Trelleborg

- Bertil Thomas, (2003), Framtidens Intelligens, Studentlitteratur, Lund

Hemsidor med information

- EVS, Technical Specifications: Xt2 server,

http://www.evs.tv/01/MyDocuments/XT2_tech_spec.pdf

- EVS, Multicam[LSM] Manual,

http://www.evs.tv/01/MyDocuments/MULTICAM_userman_9.00_ENG_080219_web.pdf

- Geraint Davies, GMFBRidge, http://www.gdcl.co.uk/gmfbridge/index.htm

- Microsoft Corporation, MSDN Directshow documentation, http://msdn.microsoft.com/en-

us/library/dd375454(VS.85).aspx

- Opensource project, Directshowlib.NET, http://directshownet.sourceforge.net/

- AviSynth developpers and contributors, AviSynth, http://avisynth.org/mediawiki/Main_Page

Documentation released under CreativeCommons Attribution-ShareAlike 3.0 License

Muntliga källor

- Daniel Rosdahl, lärare och handledare på Institutionen för musik och medier I Piteå. Han har

även tidigare jobbat som TOM (Technical Operations Manager) på flera tv-sändningar under

vilka han jobbat med Instant-Replay maskiner.

Hjälpmedel till programutvecklingen

- Visual C# 2008 (free version) - Microsoft, http://www.microsoft.com/express/vcsharp/

- GraphEditPlus (trial version) - Infognition, http://www.thedeemon.com/GraphEditPlus/

http://www.evs.tv/01/MyDocuments/XT2_tech_spec.pdf

http://www.evs.tv/01/MyDocuments/MULTICAM_userman_9.00_ENG_080219_web.pdf

http://www.gdcl.co.uk/gmfbridge/index.htm

http://msdn.microsoft.com/en-us/library/dd375454(VS.85).aspx

http://msdn.microsoft.com/en-us/library/dd375454(VS.85).aspx

http://directshownet.sourceforge.net/

http://avisynth.org/mediawiki/Main_Page

http://creativecommons.org/licenses/by-sa/3.0/

http://www.microsoft.com/express/vcsharp/

http://www.thedeemon.com/GraphEditPlus/