Artikel top billede

(Foto: Computerworld)

Videokodning i dybden

Næstegenerations-kodere giver bedre kvalitet og mindre filer; nu skal der fart på.

Af Torben Okholm, Alt om Data

Denne artikel er oprindeligt bragt på Alt om Data. Computerworld overtog i november 2022 Alt om Data. Du kan læse mere om overtagelsen her.

En ny generation af videokodere er ankommet. Nogle lyder bekendt, for eksempel H.265, nogle lyder eksotiske og nye, for eksempel VP9 og AV1, men uanset navnene taler sandsynligheden for, at du falder over en af dem inden længe. Og du kan roligt regne med, at du vil skælde ud over, at din cpu-belastning truer med at nå himlen.

Hvorfor har vi brug for et væld af nye kodere? Hvorfor er din hardware-acceleration holdt op med at virke? Kan du afspille en 4K-fil på dit 4K-UHD-tv? Hvad med HDR på pc’en? Hvordan kan du kode din egen video, og kan du til al overflod få glæde af noget GPGPU-acceleration? Kan vi simplificere det hele til glæde for din overbebyrdede hjerne?

Vi agter at foretage et dyk ned i videkodernes inderste væsen for at se, hvordan flere gigabyte data lader sig komprimere 100 gange, uden at det menneskelige øje kan se forskel.

Hvis du vil kontrollere dine kodere bedre, hjælper det virkelig at have en forståelse for, hvad der foregår i en koder. Ingen af disse standarder definerer koderen. De angiver kun det, der er krævet til koderen. Som vi skal se, sætter det brugeren i stand til at bruge alle mulige former for teknikker og brugerindstillinger til at forbedre koderne. Prisen er som regel længere kodningstider og mere processorbelastning; gevinsten er enten en mindre fil eller forbedret kvalitet.

Animerede GIF’er, og de var hårrejsende. Du kan formentlig se problemet: Folk vil lagre levende billeder på deres computere, og en fikseret paletstandard med 256 farver var ikke fremtiden. Det var i 1987.

Siden da har vi været vidner til 30 års stadige forbedringer i kodning fra en velorganiseret komité for internationale standarder. Eller rettere: indtil det seneste årti. Det vender vi tilbage til.

Vi har ikke tænkt os at dvæle ved det historiske, men det er værd at bemærke et par ting, der har fastlagt rammerne for konventioner og systemer. Før vi fik levende billeder, havde vi stillbilleder. Den første fungerende jpeg-kode blev lanceret i slutningen af 1991, og standarden kom i 1992 – takket være Joint Photographic Experts Group, der begyndte at arbejde på jpeg i 1986.

Tilsvarende dannede International Telecommunications Union (ITU) Video Coding Expert Group (VCEG) tilbage i 1984 med det formål at udvikle en international digital videostandard til telekonferencer. Den standard var den første H.261, der blev færdiggjort i 1990, og som var beregnet til at sende levende billeder ved en opløsning på hele 176 x 144 over ISDN-links på 64 kB/sek. Herfra så H.262, H.263, H.264 og H.265 alle dagens lys, og efter H.261 blev den næste videostandard kendt under navnet mpeg-1.

Det er altså tydeligt, hvor disse standarder kom fra. Vi har nævnt jpeg af to årsager: For det første blev mpeg (Moving Picture Experts Group) dannet efter jpeg’s succes. Den brugte også nogle af de samme teknikker til at reducere størrelsen på de kodede filer, og det var et enormt fremskridt i forhold til det eksisterende tabsløse digitale lager, at man brugte lossy-teknikker.

En af de vigtigste ting, man skal forstå, når det drejer sig om moderne lossy kompression, er den måde, hvorpå billedet bliver behandlet og komprimeret. Vi begynder fra grunden med at se på, hvordan jpeg-kompression [Billede A] fungerer, for her er vi ved det centrale i hele denne branche. Derefter udvider vi denne viden og går til film og mpeg. Når vi er nået så langt, skal vi se, hvordan disse områder blev forbedret og udvidet til de standarder, vi har i dag: H.264 og H.265.

Billede A: Man kan se, at jpeg-kompression døjer med at opretholde detaljerne ved lave kvalitetsindstillinger.

Farverummet ændrer sig

Vi begynder med at få begreb om ændringer i farverummet. Du er sandsynligvis vant til at tænke på alt det, der er lagret på en pc, i 16-, 24- eller 32-bit-farve, fordelt over de røde, grønne og blå kanaler. Det lægger lige stor vægt på alle informationer om farve, nuance og lysstyrke. Sagen er imidlertid, at menneskets øje er langt mere følsomt over for lysstyrke, også kaldet luminans, end noget andet. Derefter kommer nuance og til sidst farvemætning.

Farverummet bliver ændret fra RGB til YCbCr, det vil sige luminans og to krominanskanaler (her rød og blå), og dette er relateret til YUV. Formålet er at muliggøre chroma-subsampling af billedet. Det vil sige, at vi vil reducere opløsningen i kanalerne Cb og Cr for at spare plads uden noget mærkbart fald i kvalitet.

Billede B: Sådan bliver farvekanalerne underopdelt til forskellige
farverum.

Dette bliver udtrykt som en ratio af luminansen til chroma-kanalerne. Den højeste kvalitet – fuld RGB – ville være 4:4:4 med hver pixel forsynet med Y-, Cb- og Cr-data. Den bliver kun brugt i videoudstyr af meget høj kvalitet. Den meget anvendte 4:2:2-kvalitet har Y for hver pixel, men halverer den vandrette opløsning for chroma-data; det er den, der bliver brugt på de fleste former for videohardware. 4:2:0 holder den vandrette opløsning halveret, men springer over hver anden lodrette linje [Billede B]. Det er den kodning, der bliver brugt i mpeg og i enhver H.26x-standard, dvd/Blu-ray og andet. Årsagen? Den halverer kravet til båndbredde.

Kan du høre mig?

I denne artikel glimrer omtale af audio ved sit fravær. Vi er her på gyngende grund, og vi vil hævde, at der ikke længere er nogen, der går op i standalone-audiokodning. Vi tror gerne, at der blandt læserne er en eller flere, der har en samling på mængder af gigabyte, men de er som vinylelskere: De er snarere undtagelsen end reglen. Det føles, som om folk markant har ændret den måde, hvorpå deres audioforbrug finder sted – fra det gamle ejer/samler-system til en nye streamer/abonnent-model.

Selv hvis vi tager det i betragtning, vil du – hvis du vil lagre din egen audio og tage den alvorligt – komme til at gøre det med en tabsløs codec. Eftersom lagerplads er billig, og FLAC er dit valg af codec, er der ikke meget for os at skrive om. Og hvis du er ligeglad, vil du sandsynligvis være fornøjet med at holde dig til mp3-kodning – skønt du burde bruge Ogg Vorbis. Begge disse standarder (FLAC og Ogg Vorbis) er åbne (mp3 er faktisk også åben, fordi patenterne er udløbet).

Teknisk set kan alle og enhver derfor understøtte dem. FLAC har bred bracheopbakning, herunder Windows, MacOS, iOS, Android og Linux. Lige så vigtigt er det, at FLACs enhedssupport er fremragende, herunder Sonos, et væld af bil-audiosystemer, Denon, Synology og Plex for blot at nævne nogle få. Ogg har mere begrænset support, men den kan understøttes af Windows, MacOS og iOS. Nogle vil måske hævde, at et nyere format, Opus, tilbyder endnu bedre kvalitet med dit tabsløse format, men dets lave alder betyder, at hardwaresupport er mere begrænset end hos Ogg.

Videnskabeligt set

Nu kommer vi til den tunge matematik, så skru op for øverste etage. For hver kanal Y, Cb og Cr bliver billedet delt op i pixelblokke på 8 x 8. I video kalder man disse blokke for makroblokke. Hver blok bliver bearbejdet med en såkaldt “forward discrete cosine transform” (DCT) – af type to, for at være nøjagtig. Nu hører vi dig spørge “hvad pokker det for noget?” Vores lokale matematiknørd hævder, at det er ret enkelt. Men det skal han naturligvis sige. Hvorefter han giver sig til at installere Arch Linux på alle vores pc’er. Ach, du lieber ...

DCT-processen transformerer de diskrete spatielle domænepixel til en frekvensdomæne-repræsentation, men af hvad? Kig engang på de sorte og hvide interferensagtige mønstre [Billede C]. DCT leverer en 8 x 8-matrix af tal. Hvert tal repræsenterer, i hvor høj grad den oprindelige 8 x 8-billedblok svarer til hvert korresponderende funk-
tionselement. Hvis man kombinerer dem med den specificerede vægtning, får man et tilstrækkeligt tæt match til originalen, og det menneskelige øje kan ikke se forskel.

Billede C: Man kan groft sagt lave ethvert billede ud fra dette. Matematik.

Som du kan se, er basisfunktionen øverst til venstre tom (beskrevet som lav frekvens) og vil beskrive den generelle intensitet i gitteret. De progressivt højere frekvenselementer spiller en stadig mindre rolle i forhold til det generelle mønster. Meningen er, at vi i den yderste konsekvens er i stand til at droppe mange af de højfrekvente data (detaljerne) uden at miste noget af den oplevede kvalitet.

Denne DCT-matrix bliver kørt gennem en 8 x 8 quantizer-matrix; standard-matricer bliver leveret (på baggrund af konstaterede mængder), men software-kodere kan oprette deres egne og opnå en kvalitet på for eksempel 50 procent undervejs. Denne quantizer er beregnet til at prioritere lavfrekvente detaljer – som øjet har nemmere ved at se – frem for højfrekvente detaljer.

Hvert DCT-element bliver divideret med hvert korresponderende quantizer-element, og resultatet bliver afrundet til det nærmeste heltal. Slutresultatet er en matrix med lavfrekvente elementer, der forbliver i den øverste venstre del af matricen, og flere af de højfrekvente elementer bliver reduceret til nul nær matricens nederste højre hjørne. Det er her, det tabsløse element ved jpeg spiller ind [Billede D].

Billede D: Tag værdierne for et enkelt-kanal pixel-net på 8 x 8 ind i en matrix.

På grund af matricens vægtning øverst til venstre bliver den omarrangeret til en liste, der bruger et zigzag-mønster. Matricen bliver bearbejdet i diagonaler, der begynder øverst til venstre, og som skubber de fleste nuller til enden [Billede E]. Huffman Encoding komprimerer disse endelige data. Kvaliteten af jpeg-billedet bliver styret af, hvor aggressiv quantizer-matricen er. Jo stærkere den forsøger at afrunde elementer til nul, desto flere genstande. Til lykke – du har komprimeret et stillbillede.

Hvis jpeg er så god til kompression, hvorfor samler man så ikke en masse af dem og laver et format til levende billeder? Det kan man godt – det kaldes Motion JPEG – men det er ineffektivt i sammenligning med metoderne til kodning af levende billeder.

Bevægelseskompression

Til mpeg (og andre kompressionsmetoder bliver hver frame delt op i makroblokke på 16 x 16 pixel. Hvorfor ikke de 8 x 8, der bliver brugt af jpeg og i forbindelse med MPEG-standarden? Fordi mpeg bruger et 4:2:0-farverum, der springer hver vandret linje over, og vi derfor er nødt til at fordoble, så vi kan opretholde en lige mængde data vandret og lodret.

Mpeg-standarden bruger tre typer frames til at skabe et levende billede. I-frames (intra) er i realiteten et full-frame jpeg-billede. P-frames (predicted) gemmer kun forskellen mellem en I-frame og den fremtidige P-frame. Imellem dem er der en række B-frames (bidirectional eller inter), der gemmer vektoroplysninger for hver makroblok – B-frames er i stand til opregne frames både før og efter.

Hvad sker der så med bevægelses-vektorer og makroblokke? Koderen sammenligner den aktuelle frames makroblok med tilstødende dele af videoen fra anker-framen, som kan være en I- eller P-frame. Det afhænger af makroblokkens foruddefinerede radius. Hvis der bliver fundet et match, bliver bevægelsesvektoren – retning og afstandsdata – gemt i B-framen. Kodningen af den bliver kaldt bevægelseskompensation eller MC (motion compensation).

Billede l: MeGUI – eller med George Harrison: “I Me Mine”.

Forudsigelsen vil imidlertid ikke matche nøjagtigt med den aktuelle frame, og derfor bliver forudsigelsesdata også gemt. Jo større fejlen er, desto flere data skal der gemmes. Derfor skal en effektiv koder kunne levere et godt bevægelsesestimat, også kaldet ME.

Fordi de fleste makroblokke i den samme frame har de samme eller lignende bevægelsesvektorer, kan man komprimere dem godt. I mpeg-1 lagrer P-frames én bevægelsesvektor pr. makroblok;

B-frames er i stand til at have to – en fra den forrige frame og en fra den fremtidige frame. Koderen samler grupper af I-, P- og B-frames, og den genopbygger videoen på baggrund af dem ud fra mpeg-bitstreamen. Som man kan forestille sig, er der plads til, at koderen kan inddrage en lang række af kvalitets- og effektivitetsvariabler ud fra forholdet mellem I-, P- og B-frames i sin bevægelseskompensation.
Hidtil har vi dækket det basale ved en komprimeret mpeg-1-video. Audio bliver integreret i bitstrea-men, og mpeg-1 understøtter mp3-
stereo-audio.

Billede E: DCT producerer en frekvens-domæne-matrix. Den kvantiserer vi for at få den endelige lossy-komprimerede matrix.

Vi agter ikke at komme ind på audiokompressionen. Mpeg-2 (eller H.262) [Billede F] bruger i store træk det samme system, men det er blevet udvidet, så det understøtter en længere række af profiler, herunder dvd, interlaced video, højkvalitets-farverum på op til 4:4:4 og multi-channel-audio. Mpeg-3 blev rullet ind i mpeg-2 med inddragelsen af 1080p-HD-profiler.

Kodning med MeGUI

Hvis du er interesseret i videokodning af høj kvalitet, kan du finde et væld af tjenester, der står på spring for at hjælpe dig. Handbrake.fr bliver ofte nævnt som en god open source-løsning, men det virker, som om mange kyndige folk ser ned på den. Et bedre forslag er tilsyneladende MeGUI [Billede 1], der er blevet udviklet af genierne på det antikke site http:// forum.doom9.org. MeGUI er open source-licenseret GPL v2, det er stadig under aktiv udvikling, det understøtter uden videre x.264 og x.265, og det opdaterer automatisk alle de mange påkrævede komponenter undervejs.

Det betyder, at når man første gang koder noget, bliver nødvendige komponenter downloadet. Det hele foregår meget glat. Man kan finde masser af nyttig dokumentation og guider på https://en.wikibooks.org/wiki/MeGUI, og når det gælder hoved-downloadet, bliver man ledt til https://sourceforge.net/projects/megui. Hent det, pak ud, og du er klar til at gå i gang. MeGUI blev oprindelig udviklet med henblik på dvd-ripping, men det kan i dag håndtere blandt andet Blu-ray-filer. Vi vover slet ikke at gå i detaljer med indstillingerne her, men vi vil nævne, at der findes en one-click-tilstand. Træk og slip en fil, som du vil gen-kode, og vælg “One Click.”

I den heraf følgende dialogboks klikker du “Config” i sektionen “Output”. Du kan vælge at satse på “Keep Input Resolution”, men du kan også vælge en standardbredde på 1280 eller 1920. Brug koderen til at vælge x265 og “Config” til at justere bitrate og antallet af passes. Klik OK til det hele, og når du klikker “Queue”, går sagerne i gang.

Mpeg-4: zoom og udvid

Mpeg-4 – også kendt som H.264 – lagde ud med det formål at udvide standarden for digital streaming. Bedre billedkvalitet til den halve bitrate. Men med fremkomsten af Blu-ray og HD-dvd (kan du huske det?) opstod begrebet mpeg-4 Part 10, også kendt som mpeg-4 Advanced Video Coding (AVC).

Arbejdet med AVC begyndte i 1998, og den første ratifikation kom frem i 2003, 10 år efter at udviklingen af mpeg-1 begyndte. Standardens ratifikation kom i 1993. Der blev indført nogle seriøse forbedringer, som udnyttede de enorme stigninger i processorhastighed og systemressourcer på både kodesystemer og afkodningsenheder. Vi er gået fra Video CD-tiden til fuld HD Blu-ray i løbet af blot et par codec’er.

Vi vil ikke her gå så meget i detaljer, som vi plejer at gøre, med de forskellige aspekter ved mpeg-1, dels fordi nogle af dem er justeringer af grundlæggende teknikker, som vi har dækket, dels fordi kompleksiteten er så meget større, og vi er ved at løbe tør for plads!
Til at begynde med blev I-frame-forudsigelsen markant forbedret på grund af den øgede kompleksitet. Det vigtigste skridt var variabel blokstørrelse for bevægelseskompensation i makroblokkene – fra 16 x 16 ned til 4 x 4 plus variationer imellem disse størrelser, for eksempel 8 x 16 eller 8 x 4 [Billede G].

Flere bevægelsesvektorer pr. makroblok, og antallet af tilgængelige referenceframes blev øget til 16 med et bufferbehov på fire eller fem mod kun én eller to tidligere. Bevægelseskompensation fungerer med en præcision på en kvart pixel. Et indbygget deblocking-filter hjælper med til at eliminere 16 x 16-rester.

Dette er blot en lille del af forbedringerne. Der er for eksempel en hel sektion om tabs-modstandskraft med henblik på at forbedre ydelsen med beskadigede datastrømme plus udvidet protokolkompression, tabsløse funktioner og funktionsspecifikke muligheder for at forbedre sort/hvid optagelse, visuelle overgange eller fading.

Mpeg-5: patentkrige

Som med den forrige generation skulle et designmål for H.265 – også kendt som High Efficiency Video Coding (HEVC) – opnå den samme grad af billedkvalitet som H.264, men til den halve bitrate [Billede H]. Subjektive test viser, at man kan opnå en reduktion i bitrates på mindst 56 procent ved 720p, hvilket stiger til 64 ved 2160p. Flot.
Hvad er ændret? De fikserede makroblokke på 16 x 16 er væk, og i stedet har vi blokke af kodetræer (CTB). De kan være 64 x 64, 32 x 32 eller 16 x 16 pixel. Et CTB kan opdeles rekursivt i kodeenhed-blokke fra 32 x 32 i størrelse ned til 8 x 8, gemt som et “quadtree,” idet hver CU-underdivision er en firkant af mindre kvadrater.

Hver CU er rekursivt delt op i transform-enheder (TU), der igen kan være 32 x 32 og ned til 4 x 4, som bliver bearbejdet med DCT. Hertil kommer, at den alternative og mere effektive “discrete sine transform” (DST) bliver brugt på 4 x 4-blokke. Den fleksibilitet og en stigning i nøjagtighed forbedrer H.265’s effektivitet enormt.

H.265-codec’en griber chancen for at vende op og ned på bevægelsessensorer, og den begynder med forudsigelses-enheder (PU) – alting skal være enheder! En CU kan deles op i en af otte PU-typer: hele enheden, en halv vandret eller lodret, en fjerdedel og en kvart linje øverst/nederst eller venstre/højre. Vi springer intra-forudsigelse (in-frame) over. Den bliver brugt til at forbedre “flade” områder, men vi holder os til, at HEVC har 35 tilstande i sammenligning med de ni hos H.264.

Musklerne finder vi hos det, man kalder “inter prediction motion vector”-systemet. Det har stadig to referencelister med hver 16 elementer, men det kan omfatte otte billeder, som kan rumme den samme frame flere gange med henblik på vægtede forudsigelser. Der er forbedrede bevægelseskompensationsfiltre på både luma- og chrome-kanalerne plus et optimeret deblocking-filter, som kan bearbejdes parallelt.

Endelig er H.265 udviklet med tanke på multithreadet beregning til moderne systemer. CTB-designet producerer et net af uafhængige kodbare blokke. Så nåede vi i mål. Vi har fået stor respekt for codec-udviklere og de folk, der skal implementere disse standarder i smartphones og tv’er. Det får mildt sagt fantasien til at stejle, men det hele virker.

Næste generations HEVC

Codec-udviklerne har gjort et stort arbejde for at reducere bitrates og forbedre billedkvaliteten – uden en drastisk forøgelse af afkodningens kompleksitet. Et mindre appetitligt aspekt ved codec-verdenen er softwarepatenter, der medfører licenser. Licenser er fine, hvis de er rimelige. Men sagkundskaben (http://bit.ly/MPC154hevc) siger, at der skete en markant stigning for HEVC, og branchen begyndte derfor at se sig om efter alternativer.

Google har med sin vlog- platform YouTube en indlysende interesse i ikke at betale licens for sin voksende bruger-base. Google købte sin VP8 codec-teknologi og bruger nu den H.265-ækvivalente, men royalty-fri VP9 til YouTube-streaming. Netflix, der massivt har brugt H.264 AVC, har skiftet til VP9 for kompatible enheder. Det førte til, at Alliance for Open Media (http://aomedia.org) blev dannet af Google, Mozilla, Microsoft, Netflix, Amazon, Intel, AMD, ARM og Nvidia. AV1 er alliancens codec, og den blev frigivet i marts 2018. Test fra Netflix viser en bitrate- reduktion på omkring 25 procent i forhold til HEVC og VP9, men kodningen er op til ti gange så kompleks, og et projekt fra Moskvas statsuniversitet viser, at en ikkeoptimeret koder var op til 3500 gange langsommere.

En stor hurdle for AV1 er hardwaresupport; der kommer ingen før slutningen af 2019. HEVC-folkene sidder ikke med hænderne i skødet – der er blevet dannet et Joint Video Exploration Team, som skal arbejde på en næstegenerations-codec til slutningen af 2020. Den bliver op til 50 procent mere effektiv og understøtter næstegenerations-display-teknologi.