INDUSTRY OPINION: Johan Skaneby, Eyevinn Technology
Spara data genom att effektivisera redan befintliga videoströmningstekniker
Text & foto: Johan Skaneby
I denna artikel tittar Johan Skaneby närmare på hur vi kan definiera våra videotranskodningsinställningar efter kvalitet och inte som många gör i dag, enbart efter data per sekund (bitrate), bilder per sekund och bildstorlek.
Johan Skaneby, Eyevinn Technology
Spara data genom att effektivisera redan befintliga videoströmningstekniker – är detta möjligt? Och varför är det intressant? Att minimera mängden data som behöver överföras för att vi ska kunna uppleva tv över internet sparar inte bara CDN-lagring (lagring av data på näten), utan även datatrafikkostnader för tittaren som också får bättre förutsättningar att se tv över internet på resan eller i sommarstugan där bandbredden är låg. Jag tror vi alla känner igen oss, särskilt under semestertider då alla även försöker få plats med sina tv-vanor tillsammans med fiskespön och badbyxor i resväskan.
Jag ska i denna artikel titta närmare på hur vi kan definiera våra videotranskodningsinställningar efter kvalitet och inte som många gör i dag, enbart efter data per sekund (bitrate), bilder per sekund och bildstorlek. Till min hjälp har jag tagit Carl Lindqvist på Bonnier Broadcasting som arbetat med en kvalitetsbaserad teknik under de senaste åren och utvärderat resultaten på ”fältet”.
En kort bakgrund
Olika typer av produktion och distribution av digital video kräver att video och ljud anpassas därefter. I detta hantverk ingår att välja rätt kodek, bitrate, format, och mycket mer – oftast enligt fastslagna tekniska standarder. Den ”heliga graalen” är kunskapen att minimera mängden data som behöver överföras med bibehållen bild- och ljudkvalitet. I en tid med nya standarder, mallar och allmänna bästa rekommendationer för videotranskodning kan det tyckas att vi borde veta hur vi uppnår allt detta vid det är laget. Men även om vi ser nya och effektivare kodekar som utvecklas och släpps är det fortfarande viktigt att vi diskuterar hur videokomprimering verkligen fungerar för att bättre förstå̊ hur vi kan utveckla, förbättra och effektivisera befintliga modeller för distribution.
Hur vi gör och varför
“I OTT-världen har branschen länge arbetat med att försöka enas om standard för att underlätta för tillverkarna att anpassa sina spelare att kunna visa upp video.”
Alla som till vardags arbetar med dessa frågor förstår hur kvaliteten på videobilden påverkas av bildstorlek, antal bilder per sekund i relation till den data rate/bitrate som vi tillåter i varje videoström. Distributionsmodellen för tv på internet brukar allmänt refereras och kallas OTT (Over The Top) – och det innefattar all video som vi ser via klienter som Chromecast, Apple TV, dator, mobiler, med mera. I OTT-världen har branschen länge arbetat med att försöka enas om standard för att underlätta för tillverkarna att anpassa sina spelare att kunna visa upp video.
Standardiseringen har väl gått ganska bra, får man säga. Själva paketeringen av videon kommer fortfarande i antal olika smaker, där HLS (iOS) och DASH är de kanske mest använda i dag. Dessa paketeringar innehåller livsviktig metadata för att spelaren på respektive klient ska kunna växla mellan olika versioner av samma video, beroende på den uppkopplingshastighet, växla mellan undertext, hoppa fram och tillbaka i tid, med mera. Fram till nu har samtliga aktörer för de olika OTT-standarderna enats om att använda videokodeken H.264 oavsett paketering (HLS, DASH, MSS, HDS) och transkodera denna video enligt samma inställningar som bland annat innebär att videon klipps upp i 4-8 sekunders sekvenser som alla startar med en IDR-bild (beskrivning av en fullbild som efter följande bilder kan referera rörelseförändringar till). Detta gör att man kan producera video en (1) gång men paketera samma video enligt olika krav, till exempel just DASH eller HLS. Men en av de viktigaste funktionerna i hur OTT-distributionen fungerar är alltså hur vi kan anpassa strömmen beroende på tillgänglig bandbredd. För att göra detta måste vi först producera ett antal versioner av vårt källmaterial, låt oss säga sex versioner. De första versionerna ska användas under förhållanden med lägre bandbredd, medan de andra har större bildstorlekar och kan användas under bättre förhållanden som kräver mer bandbredd.
Så fungerar det
Klienten kommer att kommunicera med servern enligt ett antal regeluppsättningar och om bandbredden blir lägre kommer klienten, det vill säga din mobil, Chromecast, webbläsare eller Apple TV, att be servern att tillhandahålla en lägre bandbreddsversion av samma material, alltså en av de andra versionerna av samma video. En växling kommer så småningom att inträffa och bildkvaliteten sänks när den nya strömmen är tillgänglig. (För att göra så att detta fungerar felfritt krävs att videon i strömmen transkodas enligt en standard som bland annat förutsätter att det just finns ”start”-bilder, så kallade IDR frames, i början på varje videosekvens.) Men nog om dessa detaljer – som kräver en separat artikel för att förklaras bättre.
Här följer ett antal exempel på profiler som versioner av videoströmmar ofta kallas: 256 x 144 300 kbps, 426 x 240 500 kbps, 640 x 360 800 kbps, 1024 x 576 2000 kbps 1280 x 720 4000 kbps och 1920 x 1080 6000 kbps. Det här är det traditionella sättet att koda video. Vi har en lägre bitrate och mindre bildstorlek (256 x 144) för dig när din bandbredd är låg. Å andra sidan - när du har en bra bandbredd, har vi en fullstor bildstorlek (1920 x 1080) att visa för dig.
“Videotranskodning fungerar ju så att om vi har mycket rörelse i videosekvensen så går det åt mer data att beskriva en sådan videosekvens, medan en videosekvens med väldigt lite rörelse behöver mindre data för att visa lika hög visuell kvalitet, eftersom pixlar som inte har förändrats inom bilder (spatialt) eller mellan bilder (temporalt) kan återanvändas.”
Det är det här som är det listiga med OTT-standarden – det finns ju en videoström för varje tillfälle! Är inte det bara bra, då? Är problemet med olika uppkopplingshastigheter löst? Jo, till viss del är det ju det – men det förutsätter att vårt inkommande material håller samma karaktär. Videotranskodning fungerar ju så att om vi har mycket rörelse i videosekvensen så går det åt mer data att beskriva en sådan videosekvens, medan en videosekvens med väldigt lite rörelse behöver mindre data för att visa lika hög visuell kvalitet, eftersom pixlar som inte har förändrats inom bilder (spatialt) eller mellan bilder (temporalt) kan återanvändas. Det flesta program vi ser innehåller ju dock väldigt många olika typer av rörliga och mindre rörliga scener. Låt mig ta ett exempel.
En intensiv hockeymatch sänds med ovanstående profiler. Klienten har en tillgänglig bandbredd som tillåter 1280 x 720 (höjd x bredd) vid 4 000 kbps (dataöverföring per sekund). (Kom ihåg ovan terminologi – jag kommer att återanvända den.) Vi ser en hel del snabba rörelser och rörliga kamerapanoreringar som naturligtvis behöver all tillgängliga data som tillåts i denna ström – 4 000 kbps.
I en intensiv hockeymatch ser vi en hel del snabba rörelser och rörliga kamerapanoreringar som naturligtvis behöver all tillgänglig data som tillåts i denna ström – 4 000 kbps.
Vid halvtid klipper vi till studion. Detta är en motsatt typ av situation. Kommentatorerna diskuterar spelet. Den statiska bilden av studiokameran beskriver diskussionen. Allt är bra – men en närmare titt kommer att avslöja att kodaren fortfarande använder nästan 4 000 kbps för att beskriva den här tekniskt sett enkla studioscenen.
Vid halvtid klipper vi till studion. Detta är en motsatt typ av situation.
I det här exemplet, som är ett väldigt vanligt sätt att transkoda och presentera video, använder vi faktiskt samma mängd data för att beskriva de krävande hockeyscenerna som den stillsamma studiodiskussionen. Något är ju inte riktigt bra här – och priset vi betalar är sannolikt onödiga CDN-kostnader och onödig dataöverföring överallt för att fortsätta distribuera video med denna ganska trubbiga generella modell. För att inte tala om sms-meddelandet om att du har förbrukat din tillgängliga datamängd för denna månad…
Kvalitetsbaserad komprimering och metod
Att definiera videotranskodning med hjälp av en kvalitetsstege är inget nytt, men i många fall får du bara möjlighet att välja mellan kvalitet eller bitrate (dataöverföring per sekund). Varför kan vi inte bara använda båda?
För att visa vad jag menar tänker jag visa ett exempel med hjälp av ett verktyg ur open source-kodeken x264. Ibland de verktyg som finns i x264 hittar vi en kvalitetsparameter som kallas CRF (Constant Rate Factor). Detta är enkelt beskrivet ett kvalitetsläge som sträcker sig från 0 till 51, där nivån 0 är "förlustfri" och 51 är så hårt komprimerad att bilden blir oacceptabelt dålig.
Det är ett känt faktum att nivåerna 18 till 24 är en mycket bra balans mellan dataåtgång per sekund och visuell kvalitet. Men kom ihåg att CRF-funktionen i sig alltså inte ger några löften hur mycket data som går åt för att du ska få den kvalitet du frågar efter. Du kommer helt enkelt bara att berätta för kodeken x264 att du vill ha kvalitet på 18 – använd den data som behövs för att ge mig denna kvalitet.
I hockeystudio-exemplet kommer datamängden som behövs för att nå CRF 18 sannolikt sjunka till kanske endast 2 000 kbps, men när vi sedan klipper till själva hockeymatchen igen med mycket rörliga klipp kan datamängden behöva stiga upp till 5 000 kbps eller 6 000 kbps – vi vet inte, eftersom vi bara bad om en kvalitet CRF 18 här.
Så, kvalitetsbaserad komprimering i sig själv här är inte det bästa sättet att skapa våra sex videoströmmar eftersom vi inte alls har någon kontroll på hur mycket data som kommer att behövas. Men det finns faktiskt ett sätt att styra detta beteende i x264 genom att kombinera CRF med ett bandbreddstak vid 4 000 kbps. Ta en titt: c: v libx264 -crf 18 -maxrate 4000k -bufsize 8000k
Vi ber här ovan x264 att i första hand eftersträva kvaliteten 18. Om det är möjligt att nå denna kvalitet redan vid exempelvis 2 000 kbps - då är allt bra, men om vi behöver mer data än 4 000 kbps för att nå denna kvalitet kommer kodaren att justera CRF till ett högre värde för att inte kräva mer än 4 000 kbps. Kom ihåg att ju högre CRF-värde, desto lägre kvalitet. Höjer vi CRF-värdet så sänker vi kvalitetsambitionen och kan därför hålla vårt 4 000-kbit-tak om det behövs.
För att visa detta har jag angivit ett exempel på exakt samma mediefil som komprimerats med de två beskrivna teknikerna. Mina videoexempel börjar med en intervju vid första delen och klipper till actionscener i sista delen.
I bitrate-baserad kodning kan vi se att intervjun och actionscenerna kodas med mer eller mindre samma bitrate …
… medan i den kvalitetsbaserade kodningen så har dataåtgång per sekund/bitrate sjunkit dramatiskt vid den stillsamma intervjun, men ökat som förväntat i actionscenerna. Detta eftersom kvalitetsmålet CRF 22 uppnåddes redan vid en betydligt lägre dataåtgång per sekund/bitrate under intervjudelen. Allt enligt tidigare resonemang i artikeln.
Ovanstående exempel visar med ett enkelt sätt hur man alltså kan effektivisera sin transkodning genom att utgå från ett kvalitetsvärde snarare än ett bitratevärde. Minskningen från 3 333 kbps till 2 582 kbps ger oss också en fingervisning om den lagringsvolym och bandbredd på näten som kan sparas vid de stora volymer som dagens operatörer tillhandahåller.
Vi måste dock ta hänsyn i OTT-paketeringen som skapar manifesten för detta sätt att transkoda video på. Paketeraren kan behöva ”manipuleras” att kommunicera maximal bitrate som samma som genomsnittlig bitrate. Allt för att den faktiska strömmen inte skall överstiga det maxvärde vi eftersträvar. Inte alla paketerare på marknaden tillåter detta – det kan vara värt att undersöka.
“Några scener av ditt innehåll behöver fler bitar, medan andra scener behöver färre – gör dina beslut baserade på kvalitet, inte bara bitrate. ”
Många har kanske läst Netflix-artiklar om encode-per-title och encode-per-scene. Dessa tekniker går betydligt djupare i analysen av vilken exakt bitrate och även bildstorlek som behövs för varje scen – baserat på VMAF – som är ett analysverktyg som ”lärt sig” vad människor uppskattar i en bild. Vår lösning i artikeln är betydligt enklare men kanske tar er 75 % av hela vägen med betydligt enklare insatser och integrationskostnader. Ge också denna teknik en tanke när du bestämmer hur du arkiverar. Några scener av ditt innehåll behöver fler bitar, medan andra scener behöver färre – gör dina beslut baserade på kvalitet, inte bara bitrate.
Kvalitetsbaserad komprimering av video i verkligheten
Carl Lindqvist, Solutions Architect på Bonnier Broadcasting i Stockholm, har studerat denna kvalitetsbaserade transkoderingsteknik i ett antal år.
Vad gjorde dig intresserad av kvalitetsbaserad transkodning från början?
– Den allmänna regeln har alltid varit att använda VBR för att utnyttja alla nödvändiga bitar som behövs för att lagra video och att använda CBR för videostreaming. Men jag kunde inte riktigt sluta tänka på alla de bitar som slösades bort i en videoström bara för att spelarna inte kunde förstå̊ olika bildstorlekar. Så jag började undersöka möjliga alternativ att kombinera kvalitet med en maxhastighet för dataåtgång per sekund (bitrate) i stället. Och tekniken de flesta transkodare erbjöd var bara 2-pass. Den typen av kodningsstrategi adresserar mer hur många bitar totalt som finns tillgängliga för att distribuera video med en bestämd kvalitet. Det var inte vad jag sökte. Jag letade snarare efter en kvalitetsdefinition i kombination med en maxhastighet för dataåtgång per sekund (max-bitrate) för att effektivisera kontrollen av hur strömmen komprimeras baserat på ingående komplexitet. Det vill säga om det är stillsamt eller mycket rörelse i originalmaterialet.
Carl Lindqvist
Varför är det viktigt? Var ser du fördelarna?
“Jag menar, varför distribuera en stillsamt animerad film med en bitrate på 8 Mbit som ett exempel, när det är troligt att bara 2 Mbit behövs för just den delen av scenen?”
– Genom att använda en sådan kvalitetsbaserad transkoderstrategi sparar vi inte bara mycket bandbredd för kunden (vilket är viktigt för tv över mobilnät), det sparar oss också mycket pengar eftersom att vi betalar för de gigabyte vi streamar med tillhörande CDN-kostnader. Jag menar, varför distribuera en stillsamt animerad film med en bitrate på 8 Mbit som ett exempel, när det är troligt att bara 2 Mbit behövs för just den delen av scenen? Med den här tekniken har mobilanvändare också en bättre chans att få tillgång till en högre videokvalitetsström vid samma tillgängliga bandbredd.
Har du några siffor på hur mycket datatrafik ni sparar på detta vis?
– Det är så beroende av typen av material vi får in. Om du har en rörlig film med full action, kanske vi oftast använder den högsta tillåtna bithastigheten. Men i en vanlig film med många olika typer av stillsamma och rörliga scener kan jag faktiskt se besparingar på upp till 30 till 40 % jämfört med våra tidigare transkodningar, vilket givetvis är ganska mycket.
Om du vill prova den här tekniken "hemma" – hur hittar du rätt balans mellan bitrate och kvalitet?
– Det här måste naturligtvis testas. Om du ställer in ett lågt värde (= hög kvalitet) för CRF så kommer du troligtvis att nå det max-tak för bitrate som du ställt in hela tiden. Om du ställer in ett högt CRF-värde (= låg kvalitet) så kommer kodaren tycka att den gjort ett bra jobb vid konsekvent lägre hastigheter än vad som är maximalt tillåtet per ström. Men har den det?
Så, är detta den lösningen för alla eller saknar vi något?
– Den här kvalitetsbaserade kodningsstrategin kräver att paketeraren justeras i enlighet med genomsnitts- och max-bitrate. Vi vill inte att paketeraren automatiskt ska beräkna en övergripande genomsnittlig bandbredd baserat på den faktiska bitraten i strömmen. I stället anger jag genomsnittlig och max-bitrate till samma värde i manifesten för att se till att videoströmmen levereras baserat på den max-bitrate som vi har angett som ett tak i våra inställningar.
Vad har du hittills upplevt i verkliga tester jämfört med standardbaserade bitrate-inställningar?
– I våra fälttester har vi funnit att denna strategi fungerar helt enligt våra förväntningar och vi är mycket nöjda med resultaten.
Det finns naturligtvis fler detaljer med den här kvalitetsbaserade kodningstekniken som måste både diskuteras och testas ut, men målet med den här artikeln är först och främst att göra dig som läser detta medveten att det finns fler en ett sätt att transkoda video för OTT-distribution och lagring. Kan det finnas något i din miljö som skulle kunna förbättras? Vad säger era leverantörer av OTT-lösningar?
Fler och fler kommersiella transkodningslösningar implementerar också sedan ett år tillbaka den här tekniken. Den CRF-del som finns i x264 är sannolikt tillgänglig redan på alla kommersiella transkodningslösningar som har en licensierad x264-komponent med de avancerade alternativen. Telestreams Vantage och Cambrias Capella är två exempel. Andra lösningar med egna kvalitetsalgoritmer på marknanden är enligt vad jag känner till Harmonics EyeQ och Beamr.
Tveka inte att diskutera det här ämnet med produktledningen hos din egna transkoder-leverantör. Det kan finnas intressanta nyheter runt hörnet.
