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?
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?
- 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.
- 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.
- 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.
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:
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
[…] Ny artikkel om deler av dette innholdet […]
Har enda til gode å forstå hvorfor media er så opphengt på å bruke Apple.
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?
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.
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.
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: msdn.microsoft.com/en-us/library/jj152145(v=vs.85).aspx
Har dere fått sett nærmere på dette? Mitt inntrykk er at dette er HTML5-måten å legge inn tekst til video.
Hei, det jobbes med ny avspillingsteknologi og da er det god sjanse for at tekstespor gjøres på denne måten.
Om du har feedback på själva specen så är du varmt välkommen att öppna issues på github. Det är värdefullt med åsikter från dem som använder standarden. 🙂
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.
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.
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. 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.
[…] ganger mangler én kvalitet, noen ganger har ikke videoen kommet fram i det hele tatt. Det er også egne filer for undertekst, som sjekkes for overlapp i tidskoder, og om sekvensnumrene er […]