Et TV-programs reise: Fra våre interne systemer til din Apple TV

---

Har du noen sinne lurt på hvordan ting ser ut bak kulissene på NRK TV? Hvordan NRK-programmene kommer fra våre interne systemer og ut på din Apple-TV, Smart-TV og Chromecast? 

I en artikkel før jul slo vi følge med et program på dets reise gjennom NRK. Med utgangspunkt i en innkjøpt dokumentarfilm så vi veien det tok fra det ble plukket opp av innkjøper, til det var trygt tatt hånd om i NRKs interne systemer. I denne saken skal vi se på hvor veien går videre, og hvordan det når endestasjonen: Deg.

Om du ikke har lest del 1, foreslår jeg at du tar en titt her.

Vi avsluttet forrige artikkel med dokumentarfilmen vår trygt plassert i PRF og Programbank. PRF er hjertet av organisasjonen, systemet hvor de grunnleggende metadata og rettighetsinformasjonen om alle programmene våre ligger. Programbank er mastodonten hvor all video oppbevares, med en god klatt utfyllende metadata atpå.

Gamle systemer blir nye byggeklosser

Første stopp på veien for programmets metadata er PI. PI er kort for ProgramInformasjon, og er (nok) en database hvor vi samler informasjon om programmene våre. PI er et egenutviklet NRK-system som hovedsaklig ble laget av to grunner: For å kunne samle data fra flere kilder i en database, og for å gjøre det enklere å hente og bearbeide data fra PRF (i en tid da PRF var trøblete å integrere med). Data strømmer fra PRF til PI i en databasesync som kjører daglig og etter behov.

PI baserer seg hovedsaklig på data fra PRF, men mottar også informasjon fra ENPS og Musikkrapp. ENPS er et nyhetsplanleggingsverktøyet som brukes til planlegging, organisering og avvkikling av nyhetssendinger – selve hovedpulsåren i nyhetsredaksjonen.  Musikkrapp er et musikkrapporteringssystem som leverer musikkstatistikk over hvilke låter som er spilt i hvilket program.

Det er PI som er kilden når vi sender data over til TONO for å fortelle hvilke låter som er avspilt på radio og TV. PI brukes til rapportering internt av hva som faktisk er sendt. Og litt lettere å relatere til for den normale forbruker: PI er kilden til informasjonen i programguiden du bruker for å finne ut hva som går på TV, både bakerst i avisa og i den elektroniske program guiden (EPG) på den digitale TV receiveren din. Sist men ikke minst er PI et steg på veien fra PRF til Nett-tv. Den ble ikke designet med det som formål, men viste seg å bli et viktig steg på veien.

Da NRK TV på nett (heretter kalt Programspiller, navnet vi bruker internt) ble startet så man at PI allerede hadde løst mye av problematikken for integrering med PRF. Enkelt fortalt: PRF er et transaksjonssystem som ikke er bygget for rapportering eller uthenting av data. Systemet har opp mot 700 daglige brukere og bør ikke belastes med stadige spørringer fra eksterne systemer. PI derimot, hadde all dataen fra PRF med mer, og var laget nettopp med formål om å distribuere data til de som trenger det. Match made in heaven!

La meg introdusere Oda

En kjapp oppsummering: Vi har generelle metadata og rettighetsinformasjon i PRF, vi har samlet data fra PRF og andre systemer i PI, vi har tekstefiler liggende hos tekstekontoret, og vi har video og ekstra metadata i Programbank. Data fra alle systemene er relevante når vi skal vise programmet til deg på web, så hvordan samler vi dette i en pakke som er spiselig på alle platformer?

La meg introdusere Oda, et av flere egenutviklete systemer i NRK med menneskelige navn (vi kan snakke om Guri, Thomas og Terje en annen gang). Oda er en snerten frøken som elsker å tygge data. Hun snakker daglig med PRF, PI, tekstekontoret og Programbank, og tar vare på informasjonen i sin egen database kalt Granitt.

Granitt bruker et eget databaseskjema for programinformasjonen, og informasjonen kommer først og fremst inn gjennom en nattlig samtale med PI, populært kalt Granitt-syncen. I Granitt-syncen opprettes alle programmer og serier i databasen, og de grunnleggende metadata som tittel og beskrivelse blir knyttet til programmene. Sendeskjema, kategorier og andre metadata med kilde i PRF blir også lagt inn i Granitt.

En trakt for data

Dataen som synces fra PI er grunnlaget i Granitt, men verdiskapningen i Oda skjer ikke før dette blir knyttet sammen med data fra andre systemer. Oda har nemlig et sett med servicer som kommuniserer med de andre systemene i løpet av dagen.

Oda har en dedikert web-service til mottak av undertekster. Teksterne skriver først teksten i EZTitles, før den korrekturleses og lagres i PAC-format. Etter å ha verifisert at fila er gyldig, eksporteres teksten til Oda med et museklikk i et egenutviklet eksportprogram. Når Oda mottar en undertekst blir den konvertert til et format Programspilleren forstår, og knyttet til det riktige programmet i Granitt basert på produksjonskode. Teksteflyten har nok utfordringer til at min kollega Erlend Wiig skrev en egen sak om det i fjor. Interessant lesning for deg som liker å gå i dybden.

En annen web-service i ODA mottar meldinger direkte fra PRF.

“Hæ? Kommer ikke PRF-data til Oda gjennom syncen fra PI?”

Joda, den gjør i utgangspunktet det. Utfordringen er at syncen mellom PRF og PI (og PI og Granitt) er en tung og tidkrevende jobb. Databasen har referanser til over 1,2 millioner programmer for radio og TV. Å utføre hele synkroniseringsprosessen ved hver eneste lille endring i et program i PRF skalerer ikke. Samtidig er det krav om at feil på titler og rubrikker skal kunne endres umiddelbart i Programspiller om det oppdages en feil. Da er det kjekt å ha en web service!

En endring i PRF trigger en generering og sending av en XML til Oda. Oda parser og oppdaterer informasjonen i Granitt. En essensiell bestanddel i XML-en fra PRF, som ikke kommer via PI, er OnDemand-rettigheter. Dette er infoen som sier noe om når og hvor lenge et program skal vises i Programspilleren. Da syncen mellom PRF og PI ble laget fantes ikke konseptet OnDemand-rettigheter, så dataen finnes ikke i PI. Da er det kjekt å ha en web-service!

Programbank: En viktig brikke

Oda snakker også med Programbank. I motsetning til PRF dytter ikke Programbank meldinger i retning Oda så fort det gjøres en endring; det er det ikke støtte for. Derfor bruker Oda en pull-strategi gjennom API-ene til Programbank. Oda spør kontinuerlig hvilke programmer det er gjort endringer på siden sist, og henter pliktoppfyllende informasjonen som trengs.

Fra Programbank er det hovedsaklig indekspunkter, tagger og medvirkende som hentes. Du husker kanskje at videoinnholdet bor i Programbank? Det er derfor indekspunktene ligger her. Indekspunkter er svært tett knyttet til selve videoen. Om man klipper vekk 5 minutter av et program må man huske å forskyve indekspunktene tilsvarende. Dette fikser Programbank for oss.

Siden videoinnholdet bor i Programbank skulle man kanskje tro at videoen overføres herfra til Oda, og deretter til Programspilleren. Sånn er det ikke.

Transkoding og videoopplasting

Råfilene i Programbank er enorme og egner seg ikke for bruk på web. For at videoen skal vises ut må den transkodes til et nettvennlig-format. Det har vi selvfølgelig også et system for. I NRK er det Vantage som er sjef for transkodingen. Vantage henter råvideo fra Programbank, produserer fem videokvaliteter (180p, 270p, 360p, 540p og 720p), og lagrer filene på et internt SAN.

Transkoding av et program initieres ikke i Programbank, men i PRF. Det er fordi både sendeplan og rettigheter holdet til her, informasjonen som avgjør om og når et program skal være tilgjengelig på nett. Når PRF får beskjed om at transkodingen er fullført, gir den beskjed videre til til Oda, som lagrer status i Granitt.

Deretter er det distribusjonsmotoren som tar over. Motoren er en komponent som leser fra Granitt og kommuniserer med Akamai, CDN vi benytter til å distribuere innhold. Basert på status i Granitt skjønner den at nye videofiler er tilgjengelige på SAN-et. Motoren tar tak i filene, og dytter de opp i skyen. Når jobben er utført lagrer den en lenke til videoinnholdet i Granitt, som blir gjort tilgjengelig for Programspiller.

Grunnen til at vi laster opp flere filer per program er for å kunne tilby flere kvaliteter. I tillegg hjelper Akamai oss med å kutte opp filene i mange små segmenter. Dette gjør at vi kan benytte en teknikk som heter adaptive streaming. Adaptive streaming gjør at man kan hoppe mellom kvalitetene underveis i strømmingen. Hendig om du strømmer på telefonen og plutselig sliter med dekningen.

Nok for i dag

Med videofilene på plass i Akamai er ikke Underholdningsavdelingen langt unna din mobilskjerm. Da er det er bare en liten komponent som gjenstår å fortelle om. Programspilleren. Programspilleren er i seg selv en såpass interessant applikasjon at den fortjener en egen bloggpost, så derfor lar vi det ligge i denne saken som allerede er blitt for lang. I korte trekk består den av et API bygget på Granitt-databasen som benyttes av frontend-applikasjoner. Alt hostes i Azure.

Neste gang du spiller av et program på din Apple TV kan du fryde deg over å at du kjenner den lange prosessen det har vært igjennom. Du vet at metadata hentes fra API i Azure, og video strømmes fra Akamai, men du kjenner også til krikene og krokene det har vært innom i NRK – fra Vantage til PRF.