NRK går nye veier for å vise Sjakk-OL på TV

Da NRK planla TV-overføringen av det nå pågående Sjakk-OL-arrangementet i Tromsø, støtte vi på en utfordring: Hvordan mikse video, grafikk og resultater fra mange pågående sjakkpartier samtidig? Løsningen var et rack fullt av mini-billedmiksere, åpen kildekode, html5-kode i beta – og en haug med 500-kroners miniatyr-datamaskiner.

Illustrasjon som viser hvordan de ulike elementene vi viser fra hvert parti er satt sammen.

Sjakk på TV?

I takt med Magnus Carlsens stigende stjerne i sjakkverden har interessen for spillet økt voldsomt i Norge, og under Carlsens VM-oppgjør mot Viswanathan Anand i Chennai India i fjor fant vi en form som gjorde at spillet også ble spennende TV. Formelen bestod av et bilde av utøverene ved bordet, i tillegg til grafisk fremstilling av brettet og computerens beregning av stillingen, alt sammen pakket inn i en grafisk bakgrunn.

I studio hadde vi med eksperter som kunne forklare spillets gang – muntlig og via grafiske analysebrett – og svare på spørsmål fra programleder og publikum via epost og sosiale medier.

Sjakk-OL til Norge

Når Sjakk-OL så skulle arrangeres på hjemmebane i Tromsø, ønsket vi selvfølgelig at sendingene våre derfra skulle bygge videre på formen vi fant under VM i India. Utfordringen er at mens det i Chennai foregikk ett parti av gangen, er det i Tromsø rundt 650. I tillegg er det i OL ikke individuelle oppgjør som avgjør, men landskamper med fire spillere på hvert lag, der alle partiene teller.

Utfordrende billedmessig

En utfordring for oss billedmessig, var at spillerne sitter veldig tett i den gigantiske hallen, med publikumsområder som går nær opp mot mange av spillebordene. Det gjør at det ofte er tettpakket med tilskuere foran bordene, og selv om det under spillet skal være helt stille i salen, har spillerne likevel mulighet til å forlate sin plass og vandre rundt mellom bordene.

Dette gjør det komplisert å billedlegge spillene med de store betjente kameraene vi tradisjonelt bruker. Både fordi det er vanskelig å finne posisjoner som kan dekke mange partier, men også fordi vi heller ikke har noen garantier for at det ikke vil komme publikum, dommere, lagledere eller spillere og stille seg midt i bildene våre.

Planen vår ble derfor å bruke små ubetjente vidvinklede kameraer, montert rett ved siden av hver av spillebordene.

Omfattende billedmiksing

Da vi begynte arbeidet, så vi redaksjonelt for oss å alltid dekke Norges førstelag i både kvinneklassen og åpen klasse, og i tillegg de to nasjonene som til en hver tid lå i toppen av tabellen. Til sammen 4 landskamper à fire parter, ga et behov for 16 kameraer ved bordene.

Når vi i tillegg ønsket å pakke bildene fra disse 16 kameraene inn i grafikk etter modell fra India, og vise blant annet sjakkbrett med automatiske oppdateringer, samt informasjon om stillingen i de andre partiene i landskampen på toppen, ble det raskt en svært kompleks billedproduksjon, der det kontinuerlig må mikses veldig mye forskjellig grafikk og videoer sammen.

Under VM i Chennai brukte vi grafikkgenerator fra VizRT til de grafiske elementene. Maskinene er utbredt i NRK, og brukes på de fleste av våre produksjoner, og vi har mange som arbeider med både oppsett og avvikling av grafikk på systemet, men de hadde allerede fullt opp med blant annet fotball-VM, og hadde ikke kapasitet til å løse dette kompliserte oppdraget i tillegg.

Det er fortsatt en VizRT med operatør med i produksjonen. Den brukes til all annen grafikk enn den fra partiene, som for eksempel navn på gjester og programledere, twittermeldinger, visning av bilder fra Instagram, tickere og tabell-oversikter.

Alternative løsninger

En idé i begynnelsen var å bruke en PC med webkamera for hver av de 16 partiene, og så mikse videobildene, bakgrunnsanimasjonen og resultatene i software på hver av dem.

Deretter skulle de ferdig miksede bildene streames til hver sin kanal i vår nett-tv, slik at publikum på nettet selv kunne velge hvilket parti de ønsket å følge. Denne løsningen skulle i tillegg gi OB-bussen vår 16 ferdige kilder sammensatt av video, grafikk og resultater. Noe som ville gjøre den komplekse miksejobben der mer gjennomførbar.

Men etter noen runder i tenkeboksen, kom vi frem til at det for nettbrukernes del ville være bedre å droppe streamingen av enkeltpartiene, og i stedet bruke resurser på å bygge nettsider for html-visning av alle partiene i mesterskapet sann tid. Dette ville også gi publikum mulighet til å bla seg frem og tilbake i trekkene, samt hente frem alle de tidligere partiene i mesterskapet. Arbeidet ble satt i gang, og resultatet ligger på nrk.no/sjakk.

Forenkling

For å holde TV-sendingene mer oversiktlige fant vi ut av vi burde konsentrere oss om én landskamp av gangen, og tok samtidig en avgjørelse om å redusere antall kamper fra fire til tre, ved å hver dag velge bare en toppkamp.

Med den beslutningen fattet, satt vi fortsatt igjen med behovet for å sette videoene fra de 12 partiene sammen med grafikk og resultater, før det ble sendt videre til OB-bussen vår.

Kun for TV

Siden produktet vi nå skulle lage kun skulle brukes på TV, var det med ett mindre naturlig å løse oppgaven med enkel webteknologi. Vi begynte derfor å se på løsninger der vi kunne holde oss til produksjonsformatet vårt for TV, som er 1080i50 via HDSDI.

Bedre kamera

Kameramessig kunne vi da benytte oss av Canon XA25. Det er små handycams som i tillegg til den vanlige HDMI-utgangen også har HDSDI ut, og som det allerede finnes en del av rundt i NRK.

Hjelp fra «søta bror»

For å avvikle grafikken og sette det hele sammen, kikket vi blant annet på programvaren CasparCG. Dette er en open source grafikk- og video- utspillingsserverer, utviklet av våre kollegaer i SVT. Den kjører på kraftige Windows 7 PCer med Nvidia grafikk-kort, og har støtte for HDSDI inn og ut via Decklink PCIe-kort.

Adobe Flash?? I 2014???

En ulempe ved CasparCG er at den bruker den nå aldrende teknologien Adobe Flash for å tegne ut all grafikk som skal endres dynamisk under produksjon. I vårt tilfelle vil det si all tekst, sjakkbrikker og computerevalueringen.

Belgisk Beta

Men i januar i år ble det sluppet en betaversjonen av CasparCG 2.07, og i den var det lagt inn en ny funksjon, som er utviklet av den Flamske almennkringkasteren VRT i Belgia. Den gjør det mulig å tegne ut den dynamiske grafikken i HTML5, med støtte for javascript og CSS.

Det vil si at vi mye enklere kunne benytte store deler av den underliggende løsningen som brukes på nrk.no/sjakk, for å levere resultatene, og så skrive spesifikke nettsider for visning av dem på TV på toppen.

Nesten, men ikke helt

Selv om de på CasparCG’s nettsider advarer mot å bruke betaversjonen i produksjon, valgte vi å teste den. Både looping av bakrunnsanimasjonen og uttegning av den dynamisk grafikken fungerte glimrende, men et skår i gleden var at CPU-bruken var høy, samt at bildene fra kameraene fikk en uakseptabel lang forsinkelse når de ble sendt gjennom serveren. Så da hadde vi kommet dit at vi hadde bra kameraer og en god løsning for å generere grafikk, men fortsatt hadde vi ikke funnet ut hvordan vi skulle mikse de to sammen.

Eureka

Det vi vanligvis gjør når vi skal mikse to HDSDI-kilder sammen, er selvfølgelig å bruke en bildemikser, og så fort den tanken var tenkt, dukket løsningen opp.

Ved hjelp av fire små bildemiksere og en CasparCG-server med et firekanals Decklink HDSDI-kort, kunne vi bygge en bildemiksermatrise, hvor vi ikke lenger trenger 12 kraftige PCer for å gjøre jobben, men kun en. Resultatet er at vi til en hver tid kan sende hvert av de fire partiene i en landskamp mikset med riktig grafikk fra CasparCG til OB-bussen. Ulempen er at vi i bussen ikke får forhåndsvisning av de to andre landskampene samtidig, men i og med at planen var å alltid gå via studio før vi skiftet kamp, var det egentlig ikke noe stort problem.

Styring

Etter dette gjenstår bare en utfordring, og det er hvordan vi skal styre skiftet mellom de ulike landskampene. Det som må til er å velge ny kamerainngang på alle fire mikserne, samt laste nye html-sider på de fire kanalene på CasparCG-serveren. Det hele må foregå samtidig, og helst automatisk basert på GPI-pulser fra mikseren i bussen for å forenkle avviklingen.

Vi hadde allerede fire rimelige bildemiksere fra Atem tilgjengelig, så da var det bare å begynne å teste.

CasparCG er server-programvare som ikke opereres direkte, men styres via en grafisk klientprogramvare eller telnet-kommandoer over nettet. Atem-mikserne er litt på samme viset, de kan styres fra dedikerte styringspaneler eller via programvare over ethernet.

Siden alle enhetene kan styres over nettverket, begynte vi å undersøke der. Telnetkommandoene CasparCG bruker er helt åpne, mens protokollen for å kontrollere Atemmikserene ikke er like enkel. Men heldigvis er internett fullt av flinke folk, og Kasper Skårhøj fra Danmark har skrevet et bibliotek til Arduino for å kontrollere Atemmikserne.

Arduino er en åpen-kildekode elektronikk-plattform basert på maskinvare og programvare som er enkel å bruke. Den skal gjøre det enklere for alle å lage interaktive prosjekter.

Vi fant fort også ferdige eksempler på hvordan Arduino kan koble seg til telnet-servere, så dette så lovende ut. I teorien skulle vi nå kunne koble GPI-triggerene fra OB-bussen til Arduinoen, og så koble den til samme nettverk som de fire Atem bildemikserene og CasparCG-serveren.

Nettverkstrøbbel

VI begynte så å teste eksempelkoden som fulgte med biblioteket til Kasper Skårhøj. Det fungerte 100% med én bildemikser, men med to eller flere ble det straks veldig ustabilt. i tillegg fik vi ikke arduinoen til å kjøre både telnet over http, og Atem over UDP samtidig.

Separate nett

Etter å ha grunnet litt over dette problemet, kom vi frem til at vi kunne løse det hele ved å kjøre hver av enhetene i et eget lukkede nett. En master-arduino, som tar i mot GPI-triggerne fra Bussen, og kommuniserer med CasparCG-serveren, i tillegg til fire slave-arduinoer som kommuniserer med hver av bildemikserene.

For å løse dette måtte vi få arduino-slavene til å lytte på masteren via noe annet enn nettverket. Løsningen ble en helt enkel 2-bits buss melleom to av de digitale pinnene på alle fem arduinoene. Når OB-bussen sender en GPI-trigger for å få landskamp 1, settes pinnene på master-arduinoen til 00, ved landskamp 2 til 01, og ved landskamp 3 til 10. Slave-arduinoene leser pinnene kontinuerlig, og om de forandrer seg, sender den en kommando til Atem-mikseren for å skifte kamerakilde. Siden det ikke sendes noen verifisering tilbake til master-arduinoen, bygget vi det inn i hver slave slik at det hele tiden leser tilbake fra Atem-mikseren hvilket kamera som er aktivt, sammenligner det med 2-bitsbussen, og korrigerer om de ikke er like.

Testing

Endelig hadde vi en prototype som gjorde det vi satte oss fore, det som gjenstod var å gjøre den produksjonsklar ved å montere og kable alt ferdig i en transportkasse. Og selvfølgelig teste, teste og teste.

Vi ville sørge for å avdekke eventuelle svakheter ved både på egen kode i Arduinoene, og i  CasparCG-serveren, som jo er en betaversjon.

Vi brukte derfor nok en Arduino som vi satt opp til å simulere GPI-triggere fra OB-bussen med tilfeldige intervaller mellom 5 og 50 sekunder, og lot den stå og gå hele juni, uten at det dukket opp noen feil.

Tilbake fra ferie i slutten av juli var det så bare å pakke det hele sammen og sende nyskapningen til Tromsø, hvor løsningen nå har gått som en klokke siden starten, og vært med på å gjøre sendingene våre fra Sjakk-OL til den suksessen de har blitt.