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.
English version: NRK breaks new ground to show chess on television
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.
(foto: NRK)
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.
(Foto: Blackmagic design)
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.
(Foto: Blackmagic design)
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.
(Foto: Tore Zakariassen, NRK)
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.
Takk for veldig interesant artikkel, utrolig hva dere har greid å få til med sjakksendingen. Men jeg har et spørsmål, hvilket analyseprogram er det Torstein Bae benytter seg av? Er det mulig å få se noen demo av dette programmet?
Hei, Tore!
Torstein bruker den norskproduserte open-source sjakkanalyseprogrammet Stockfish. Det er den som vurderer stillingene og foreslår trekk. Et glimrende program, som finnes gratis tilgjengelig her:
stockfishchess.org/
Det finnes til og med en hendig iPhone-app. Veldig gøy å bruke den, for ingen annen app jeg har opplevd får telefonen til å bli så varm eller suger batteri så fort. Kraftige utregninger på gang.
Stockfish er selve motoren som gjør beregninger, men jeg mistenker at spørsmålet går på hvilken frontend/programvare blir brukt på tv-bildene for å vise sjakkbrettet med piler og mulighet for å «markere» felter med grønn/rød etc.
Lurer i alle fall på det selv 🙂
Programmet som brukes for analyse med piler etc er Chessbase. Dette er det ledende programmet for behandling av databaser og partier.
Noen som vet om det finnes det en analyzer-app for android som gir en enkel fremstilling av stillingen til hhv svart og hvit a la den røde streken som vises på TV? (Dvs. «hvem som leder partiet»)
Hadde vært moro å ha når man spiller mot hverandre…
Jeg bruker «analyze this (free)» og synes den er meget god til analyse av mine egne partier. Enkel i bruk og gir gode analyser med bruk av to analysemotorer.
Kjempefin artikkel! Artig å få innsikt i hva som ligger bak en sending som sjakk-OL. Selvfølgelig rettet mot folk med interesse for teknologien, men desto mer interessant for oss. En artikkel trenger ikke være «mainstream» for å være lesbar.
Flott artikkel. Morsomt at dere er såpass åpne om hvordan dere gjennomfører dette. Veldig spennende å se at profesjonelle TV-produksjoner kan gjøres ved hjelp av enkle midler og litt tankekraft!
For en fantastisk interessant og detaljert artikkel! Dere må ha verdens beste jobb!
Meget god artikkel. Tusen takk!
Ser gjerne mer slikt… =D
-ED-
Hei!
Fin artikkel, selv om veldig mye gikk langt over mitt hode er det artig å lese om alt arbeidet som ligger bak.
Mulig artikkelen svarte på det, men jeg stusser litt over forsinkelsene. Altså, vi kan se spilleren gjør et trekk, men så endres ikke grafikken før opp til et minutt senere? Burde det ikke egentlig være omvendt? Altså- bildet inneholder jo meget mer datamengder enn trekket og burde vel således gå saktere..?
Espen
Grunnen til at det tar litt tid før brikkene vises er at datene er innom flere databaser og servere før de kommer tilbake til Tromsø, og vises på TV-skjermen.
JA VI ELSKER CASPARCG!
Gratulerer med seieren. Den teknologiske altså.
Kjempebra artikkel! Artig å lese om hvordan dere jobber og bra at dere er så åpen om løsningene som dere har brukt.
Glimrende artikkel, kjør på med flere slike!
Håper dere gjør en kort engelsk versjon som Case study for casparcg.com, og håper jeg får høre mer fra dere under EBU Open Source Meetup på IBC.
IBC EBU Open Source Meetup: tech.ebu.ch/Jahia/site/tech/cache/offonce/news/ebu-hosts-open-source-meetup-at-ibc-2014-07aug14;jses…
Engelsk versjon av saken.
nrkbeta.no/2014/08/13/nrk-breaks-new-ground-to-show-chess-on-television/
Jon Ståle, du er awesome… bare så du veit det!
Imponerende sendinger, både teknisk og i panelet . Bra jobba NRK!
Glittrende artikkel! Hvordan løser dere lyd? Hadde vært morro med et innblikk fra det lydtekniske også.
Viser at det jobber mange dyktige folk i NRK.
Når dere legger ut slike saker på nett.
Bruker dere da koding, slik at man koder hele innlegget med koder …. eller har dere et publiserings program?
Når man skal legge ut video på nett. må man ha en spesiell nett eller maskin/serverfor at hastigheten skal gå raskere?
NrkBeta bruker publiseringsverktøyet WordPress for å publisere artikler, og til video bruker vi ofte Youtube.
Så er nrkbeta.no en wordpress side? er nrk.no det også?
nrkbeta.no er WordPress, og om du er godt kjent med nettleseren din kan du sjekke kildekoden som gjentatte ganger vil hinte til dette. Der finnes 4 treff på «wordpress», og 99 treff på «wp».
Selve nrk.no er nok en spesialkomponert, og ikke WordPress, men det kan kanskje nrkbeta-gjengen bedre svare på. En slik medieforside vil trenge mye mer funksjonalitet enn en ordinær WordPress-installasjon, selv om resultatet kanskje kan se ganske likt ut. På en side som nrk.no ønsker man å finkontrollere hvor og hvor lenge saker vises på forsiden, antageligvis linke til interne videoressurser, tilpasse bilder som brukes på forside, til toppbilde, osv. Den viktigste forskjellen på disse to nettstedene må vel være graden av brukerengasjement, hvor nrkbeta.no er ørlitegranne mer uformelt og samtidig tilrettelegger for vesentlig mer samhandling. Der har WordPress gode egenskaper. Et sånt publiseringsverktøy (CMS) velger man gjerne etter hva slags innhold man har, samt hvor store ressurser man har til rådighet for å tilpasse design og funksjoner. WordPress m.fl kan du prøve ut her for eksempel: opensourcecms.com/scripts/show.php?catid=1
The Verge er en annen passe godt kjent nyhetsside, og der er nok nettopp valg og utvikling av CMS en nøkkelfaktor til suksess. techcrunch.com/2012/05/07/a-closer-look-at-chorus-the-next-generation-publishing-platform-that-runs-…
Fantastisk artikkel, og ikke minst teknisk imponerende arbeid som er gjort! Utrolig imponerende, og veldig morsomt at dere bruker open source i så stor grad som dere gjør. Jeg er stor fan av open source, og når man leser dette, håper jeg flere andre også blir det … 🙂
Jeg er ikke den som henger meg på den enorme selv-skrytet .
Sammenlignet med VM- overføringene faller jo dette helt igjennom !
Jeg nevner i fleng:
Hva med vurdering av vinnersjanser, anbefalte trekkk, hvor langt i spillet de er kommet,
en skikkelig klokke osv. osv.
Til slutt:
Er det ikke mulig å gjøre den informasjonen som er på skjermen leselig ?
mvh
Arnold Rettedal
Interessant artikkel! Hadde vært kult om dere delte flere slike case-studies!
Tusen takk for innblikket! Dere er dyktige!
Utrolig bra artikkel. Jeg har storkost meg med gode sendinger og fin grafikk i sjakk ol.
håper vi kan fortsette å få innsyn i hvordan dere løser slike utfordringer.
..og som flere andre nevner, dere må ha verdens kuleste jobb 🙂
Bra lesning, og interessant stoff! Flott å se at dere tør (eller får lov) å satse på «nye ting» på denne måten. Er nok ikke mange andre mediehus/bedrifter generelt som uten videre våger seg med betaversjoner til driftskritiske ting. Men som dere skriver, med nok testing i forkant kan man forsikre seg ganske bra.
Mer sånt 🙂
Jeg har ikke peiling på hva jeg leser engang, men jeg digger det. Kult å få et innblikk i kulissene, og en får sett det utrolige arbeidet som ligger bak noe som virker så enkelt!
Takk for en interessant artikkel!
Til neste gang:
Jeg syntes for mye av skjermflaten (på TV-skjermen) ble brukt til unødvendig fyllstoff.
Bakgrunnen (stjernebilde?) fikk for mye plass i ytterkant av skjermbildet.
Med såpass mye informasjon på skjermen hadde det vært bra om skjermbildet ble utnyttet til det fulle. I noen av de grafiske elementene kunne det også vært brukt noe større skrift, kanskje kombinert med en annen skrifttype. Enkelte ganger er det dårlig lesbarhet.
Få gjerne inne anbefalte trekke fra Stockfish når det er fokus på ett parti.
Sjakksendingene til NRK er kjempegode, jeg koser meg med sjakk, grafikk, ekspertkommentatorer som engasjerer og spenningen som følger med.
Jeg støtter det Roy skriver om å utnytte skjermen bedre. På en 42″ eller større var det vel ikke noe problem, men på en mindre tv var det omtrent umulig å lese det som stod.
Tanken bak å gjøre alle partiene tilgjengelig var veldig bra, men dere må gjøre noe for å minske forsinkelsen som kunne være opptil ett minutt både på tv og nettsiden. Jeg brukte chess24 og der kom trekkene nesten umiddelbart.
Dere bør gjøre de forskjellige livestreamene som er på nettsiden tilgjengelig i appen slik at en ikke trenger å gå inn på nettsiden og åpne de der.
Ellers må jeg si det er utrolig interessant å lese om hvordan dere jobber og utvikler ting. Dere har antagelig produsert den beste store sjakkturneringen!
Hvilken avdeling i NRK er det som kommer opp med disse løsningene? Er det dere i Beta eller er det en dedikert R&D avdeling?
Utvikling foregår i alle avdelinger i NRK, men løsningen som er beskrevet her har vi utviklet i NRKBeta.
Ah!, Det må jo være drømmejobben!
Ser at dere støtte på en utfordring med arduino’en fordi den ikke uten videre kunne kjøre en telnet og en http session i parallell.
Kunne det vært en løsning å bruke et par raspberry pi’s istedet?
T.
Det er godt mulig det kunne vært løst med en PI, men meg bekjent finnes det ikke noe atembibliotek for den. I tillegg ville vi med en PI antagligvis fått de samme problemene med flere Atemmiksere i samme nettverk.
Synes at Torstein Bae og Atle Grønn gjør en fantastisk jobb som kommentatorer, men jeg savner en rubrikk for trekken spillerne utfører.
Jeg er klar over at dette har sikket noe å gjøre med det datatekniske,
men det hadde vært fint om trekkene av noen av partiene til de høyeste rangerte spillerne kunne vises.
Vi får ikke plass til alt i TV-sendingene, men på nrk.no/sjakk kan du hente opp alle partiene fre hele mesterskapet, og bla deg gjennom.
[…] Sjakk-OL bak kulissene […]
[…] utflyttere som ikke får sett sendingene fra tidligere hjemfylker? Tvinge folk over på nett? Bruke Rasberriene de hadde under sjakk-VM? Trenger utviklerne noe å gjøre for å føle seg […]