WebVtt undertekst produksjon: forbedring for NRK nett-tv

Kategorier: Dev, Nett-tv, NRKTV & Uten kategori

«Example of subtitles (Charade, 1963)» by Directed and produced by Stanley Donen – Charade Blu-ray [Criterion edition]. Licensed under Public Domain via Commons – https://commons.wikimedia.org/wiki/File:Example_of_subtitles_(Charade,_1963).jpg#/media/File:Example_of_subtitles_(Charade,_1963).jpg

Prototype i produksjon

Jeg har tidligere skrevet om hvordan undertekster fra tekstekontoret vårt kommer ut i nett-tv. I den artikkelen sto det mye om våre utfordringer rundt synkronisering av tekstefil med video. Det viktigste å legge merke til er den kompliserte veien man må gå for å generere WebVtt tekster. Den involverer en mac mini, en kø, et python script og proprietær Apple programvare. Hvis dette høres mye ut har du rett. Det er en prototype satt i produksjon.

Ingen hadde designet noe sånt fra bar bakke, så hvordan gikk det allikevel ut av døra?

iOS flyt
iOS flyt

Det kortet svaret er tid. iDingsifiserte Norge skreik etter undertekster på sine favoritt tidstrøytemaskiner. Et prototype-prosjekt ble startet. Prototypen fungerte. Prototypen ble “midlertidig” satt i produksjon. “Time-to-market» vant. Igjen.

Problemene (ja problemer, ikke utfordringer)

Løsningen fungerte, hvis ikke hadde den aldri blitt satt i produksjon. Problemet med prototyper er at de kun fungerer til en viss grad. Ser man tilbake på dem er de sjeldent optimale.

Om man produksjonsetter en prototype vil det alltid komme et tidspunkt hvor ting må gjøres på nytt. Feilene blir for mange. Løsningen blir for vanskelig å drifte og vedlikeholde. Heldigivis jobber vi med software som i større grad kan gjøres om på i etterkant enn for eksempel en bro.

Så hva var galt med vår prototype?

  1. Det største problemet med løsningen var den proprietære Apple softwaren (multimedia segmenter) som kjørte på macen for å generere WebVtt teksteformatet.  Softwaren er ikke open source så vi har liten mulighet for å undersøke hva den gjør. Den har også lite output og vi har opplevd at den sluker feil ved å «faile silently». Dette gav feilsituasjoner hvor vi rett og slett ikke kunne finne ut av hvorfor. Vi kunne bare konstatere at «det er en bug». Ikke bra.
  2. Unødvendig kompleks arkitektur. Arkitekturen var splittet opp i relativt enkeltstående komponenter, en slags microservice arkitektur. Utfordringen her  ligger i overvåkning av meldingsflyt og integrasjonspunktene.
  3. Dobble tekstelinjer på Chromecast. Chromecast håndterer ikke at samme cue ligger i to forskjellige filer, selv om dette er en del av WebVTT-standaren. Jeg kommer nærmere innpå dette senere.

Det er tydelig at noe må gjøres!. Etter å ha sett på specen til WebVtt fant vi ut at det burde være mulig å produsere dette formatet selv. Det er ikke et veldig komplisert format og ligner ganske mye på Srt som vi allerede lagde.

Ny løsning

Under er tegning av hvordan tekst flyter i det nye oppsettet. No more mac mini eller python script. Vi produserer teksteformatene vi trenger direkte for så å lagre dem på San og fortsatt eksponere ut via en web server.

ny flyt for produsering av undertekster
ny flyt for undertekster

Produsere WebVtt formatet

WebVtt er ikke veldig ulikt Srt. De er begge veldig enkle formater, med små forskjeller som at WebVtt bruker punktum i stedet for komma for å skille mellom sekund og hundredeler. WebVtt kan se slik ut:

WEBVTT

416
00:48:28.440 –> 00:48:31.400
De liker å vokse opp her.

417

00:48:31.480 –> 00:48:38.800

Med den rette innstillingen gjør

problemene barna sterke og besluttsomme.

Som man kan se er det ikke veldig komplisert å lage selv, selv om specen er omfattende nok.

Specen er en såkalt working draft hos W3C, men er i praksis implementert av alle browsere 

HLSifisere

WebVtt-formatet over er gyldig, men for å bli spist av Apple og deres HLS format for video avspilling trengs det litt ekstra. En forenklet graf viser hvordan tekst, video og playlister henger sammen:

playlist
playlist

 

HLS specen krever en ekstra linje i selve teksten:

“X-TIMESTAMP-MAP=MPEGTS:900000,LOCAL:00:00:00.000”

Denne linjen synkroniserer teksten med videoen og angir når tekstefilen (local) skal begynne relativ til videoen. Starten blir da slik:

WEBVTT

X-TIMESTAMP-MAP=MPEGTS:900000,LOCAL:00:00:00.000

416

00:48:28.440 –> 00:48:31.400

De liker å vokse opp her.

Playlister

I tillegg krever HLS en egen undertekstplaylist referert i master videoplaylist. I undertekstplaylisten angis lengden på segmentene og hva de heter, for eksempel:

#EXTM3U

#EXT-X-TARGETDURATION:120

#EXT-X-VERSION:3

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-PLAYLIST-TYPE:VOD

#EXTINF:120.00000,

Segment0.webvtt

#EXTINF:120.00000,

Segment1.webvtt

#EXTINF:120.00000,

Segment2.webvtt

Targetduration er i eksempelet over satt til 120 sekunder, det betyr at tekstene stykkes opp i 120 sekunders bolker. Apples software ville ha det enda finere med 30 sekunders bolker og det var når Chromecast skiftet mellom disse vi fikk problemer.

Ifølge HLS specen er det ingenting som sier at du må stykke teksten opp i mange biter. Så vi fant ut at det var bedre å lage ett segment i stedet. Et argument for å lage flere segmenter, er at klienten kan laste ned mindre data litt etter litt, men vi snakker om en tekstefil ved siden av videoavspilling, datamengden er ikke stor i forhold. Vi har sett at forskjellen typisk er ca 30 segmenter a 1 til 2 kB vs èn fil på rundt 40 kB for et timeslangt program. Andre fordeler med å lage 1 fil er mindre kompleks logikk og færre IO skriveoperasjoner.

Konklusjon

  • Ikke sett prototype i produksjon
  • Produser enkle formater/standarder selv eller finn et enkelt bibliotek, helst open source

15 kommentarer

    • Erlend Wiig (NRK) (svar til digi_owl)

      Hei, i denne artikkelen var det meningen å belyse at vi hadde problemer med WebVtt på Chromecast ikke Apple enheter. Apples software var en del av problemet. Jeg vet ikke om media er så veldig opphengt i Apple, men det er en stor plattform for oss og vi gir det derfor en del oppmerksomhet.

    • Det har vel med historie å gjøre? Nå gjøres jo en del i Autodesk Maya på KDE-desktopen på Linux, så ting går litt fremover. Men at en bransje er «opphengt i» Mac, BeOS, Windows, Linux, QNX … de bruker vel stort sett det verktøyet som passer, og skviser windows inn et par steder hvor det ikke er det beste valget fordi det er det de er vant med?

  1. Tov Are Jacobsen

    Hei,

    Hva kan gå galt når man ikke legger WebVTT i m3u8?

    For meg ser det ut it til å fungerer fint (Android, iPhone) å bare ha helt standard undertekster i video-taggen (subtitle tracks), og HLS som et alternativ til vanlig mp4 som source.

    Svar på denne kommentaren

    • Erlend Wiig (NRK) (svar til Tov Are Jacobsen)

      Hei,
      det burde gå finfint det som du sier. Det er jo en litt annen approach med Html5 avspilling direkte. Så lenge du er komfortabel med browserne som støtter dette er det ikke noe problem.

    • Har testet dette med DOM-editoren I MS Edge og det fungerer fint.
      La inn følgende i video-tagen:
      track id=»entrack» label=»Norsk Bokmål» kind=»captions» src=»URL TIL TEKST» srclang=»no» default
      (> & < mangler)
      Selve teksten fungerte fint, men ble vist helt til venstre på skjermen i fullskjermmodus. Burde ikke ta lang tid å få juster det slik at det vises riktig.

    • Erlend Wiig (NRK) (svar til Per)

      Prøvde med vår tekst eller noe av ditt eget? Skiller Edge seg ut blant browserne?

    • Har kun testet med Edge, da det ser ut til at Firefox ikke støtter HLS og jeg Opera fikk jeg ikke til å utføre testen. Chrome bruker jeg ikke, men burde fungere ut ifra dokumentasjonen jeg har funnet. Jeg testet med teksten som hørte til programmet. Så ut til å fungere fint og tekst og dialog holdt seg i synk de 5 minuttene jeg testet. Mitt inntrykk er at Edge følger HTML5-standarden på dette området.

      Mer info: https://msdn.microsoft.com/en-us/library/jj152145(v=vs.85).aspx

    • Per (svar til Per)

      Har dere fått sett nærmere på dette? Mitt inntrykk er at dette er HTML5-måten å legge inn tekst til video.

    • Erlend Wiig (NRK) (svar til Per)

      Hei, det jobbes med ny avspillingsteknologi og da er det god sjanse for at tekstespor gjøres på denne måten.

  2. Har dere noen som helst planer om å kode kildespråket, slik at vi kan få teksting på det som ikke er norsk? Det som er norsk har de fleste av oss minimalt behov for teksting av!

    Selvsagt er det ikke spesielt for norsk – mange trenger ingen teksting av f.eks. engelsk; det er bare forstyrrende. Det vi ønsker er at TV-applikasjonen har en liste med språk der vi kan krysse av ja/nei for teksting av hvert enkelt språk.

    For meg er det uvesentlig om lista av språk som skal tekstes sendes til webserveren, slik at tekstingen filtreres der, eller om alt sendes til klient-applikasjonen som bestemmer om teksten skal vises eller ikke. Sammenlignet med video-volumet er teksten minimal, så filtereringen kan like gjerne gjøres på klient-siden.

    Svar på denne kommentaren

    • Erlend Wiig (NRK) (svar til j b)

      Hei, det jobbes med å kunne tilby flere tekstespor ut istedet for å slå de sammen slik vi gjør nå.

      Det er det flere som har etterspurt.

  3. Hei.

    Mange av problemene deres er knyttet til at subtitles spilles av mediespilleren.

    Hvis dere i stedet kan legge et transparent HTML overlay over spilleren kan dere ta full kontroll over presentasjonen av subtitles og trenger ikke å forholde dere til noen standarder (med mindre dere absolutt vil da). Det eneste som kreves er synkronisering av subtitles i JavaScript relativt til videoen.

    Så lenge det er en HTML5 media spiller det er snakk om, så ligger alt dere trenger tilgjengelig på GitHub. http://webtiming.github.io/timingsrc/

    Tilnærmingen vil løse en rekke problemer, la dere ha så mange tekstespor dere vil, skrive/editere dem rett inn i web-leserene til folk (mens programmer går), la folk få lage sine egne sosiale tekstespor og dele dem med andre seere, presentere tekstesporet eller annen timet info på andre skjermer samtidig etc. Mao, mange muligheter til nye features, og mange muligheter for å tenke litt fremover samtidig som dere forenkler dagens løsninger.

    Denne tilnærmingen er også foreslått for W3C som ny standard for timing på web.

    Svar på denne kommentaren

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.