Første del:
Hva? En videokodek er et stykke programvare/maskinvare som komprimerer og/eller dekomprimerer digital video.
For hva? Til tross for visse begrensninger både når det gjelder båndbredde og
og når det gjelder datalagringsplass, krever markedet stadig høyere kvalitet på video. Husker du hvordan vi i det siste innlegget beregnet minimumskravet for 30 bilder per sekund, 24 biter per piksel, med en oppløsning på 480x240? Vi mottok 82,944 Mbit/s uten komprimering. Komprimering er for øyeblikket den eneste måten å generelt overføre HD/FullHD/4K til TV-skjermer og Internett. Hvordan oppnås dette? La oss nå kort se på hovedmetodene.
Oversettelsen ble laget med støtte fra EDISON Software.Vi er engasjert i Og .
Codec vs Container
En vanlig feil nybegynnere gjør er å forveksle digital videokodek og digital videobeholder. En beholder er et bestemt format. En innpakning som inneholder video (og muligens lyd) metadata. Den komprimerte videoen kan betraktes som en containernyttelast.
Vanligvis indikerer utvidelsen av en videofil dens type beholder. For eksempel er filen video.mp4 sannsynligvis en beholder MPEG-4 Del 14, og en fil kalt video.mkv er mest sannsynlig . For å være helt sikker på kodeken og beholderformatet kan du bruke eller .
En bit av historien
Før vi kommer til Hvordan?, la oss ta et lite dykk inn i historien for å forstå noen eldre kodeker litt bedre.
Videokodek H.261 dukket opp i 1990 (teknisk - i 1988) og ble opprettet for å operere med en dataoverføringshastighet på 64 Kbps. Den brukte allerede ideer som fargesubsampling, makroblokker, etc. Videokodekstandarden ble publisert i 1995 H.263, som utviklet seg frem til 2001.
Den første versjonen ble fullført i 2003 H.264 / AVC. Samme år ga TrueMotion ut sin gratis videokodek kalt VP3. Google kjøpte selskapet i 2008, og ga ut VP8 samme år. I desember 2012 ga Google ut VP9, og den støttes i omtrent ¾ av nettlesermarkedet (inkludert mobile enheter).
AV1 er en ny gratis og åpen kildekode videokodek utviklet av Allianse for åpne medier (AOMedia), som inkluderer de mest kjente selskapene, som: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel og Cisco. Den første versjonen av kodeken, 0.1.0, ble publisert 7. april 2016.
Fødsel av AV1
Tidlig i 2015 jobbet Google med VP10Xiph (som eies av Mozilla) jobbet med Daala, og Cisco laget sin egen gratis videokodek kalt Thor.
Deretter MPEG LA første annonserte årlige rammer for HEVC (H.265) og en avgift 8 ganger høyere enn for H.264, men de endret snart reglene igjen:
ingen årlig grense,
innholdsgebyr (0,5 % av inntekten) og
enhetsavgiften er ca. 10 ganger høyere enn H.264.
Allianse for åpne medier ble opprettet av selskaper fra forskjellige felt: utstyrsprodusenter (Intel, AMD, ARM, Nvidia, Cisco), innholdsleverandører (Google, Netflix, Amazon), nettleserskapere (Google, Mozilla) og andre.
Selskapene hadde et felles mål – en royaltyfri videokodek. Deretter vises AV1 med en mye enklere patentlisens. Timothy B. Terryberry holdt en fantastisk presentasjon som ble opphavet til det nåværende AV1-konseptet og dets lisensieringsmodell.
Du vil bli overrasket over å vite at du kan analysere AV1-kodeken gjennom en nettleser (de som er interessert kan gå til).
Universell kodek
La oss se på hovedmekanismene som ligger til grunn for den universelle videokodeken. De fleste av disse konseptene er nyttige og brukes i moderne kodeker som f.eks VP9, AV1 и HEVC. Jeg advarer deg om at mange av tingene som blir forklart, vil bli forenklet. Noen ganger vil eksempler fra den virkelige verden (som med H.264) bli brukt for å demonstrere teknologien.
1. trinn - dele bildet
Det første trinnet er å dele opp rammen i flere seksjoner, underseksjoner og utover.
For hva? Det er mange grunner. Når vi deler et bilde, kan vi mer nøyaktig forutsi bevegelsesvektoren ved å bruke små seksjoner for små bevegelige deler. Mens du for en statisk bakgrunn kan begrense deg til større deler.
Kodeker organiserer vanligvis disse seksjonene i seksjoner (eller biter), makroblokker (eller kodende treblokker) og flere underseksjoner. Maksimal størrelse på disse partisjonene varierer, HEVC setter den til 64x64 mens AVC bruker 16x16, og underpartisjoner kan deles opp til 4x4 størrelser.
Husker du typene rammer fra forrige artikkel?! Det samme kan brukes på blokker, så vi kan ha et I-fragment, en B-blokk, en P-makroblokk osv.
For de som vil øve, se hvordan bildet er delt inn i seksjoner og underseksjoner. For å gjøre dette kan du bruke den som allerede er nevnt i forrige artikkel. (den som er betalt, men med en gratis prøveversjon som er begrenset til de første 10 rammene). Seksjoner analysert her VP9:
2. trinn - prognoser
Når vi har seksjoner, kan vi lage astrologiske prognoser for dem. Til INTER-prognoser må overføres bevegelsesvektorer og resten, og for INTRA-prognose blir det overført prognoseretning og resten.
3. trinn - transformasjon
Når vi først har en gjenværende blokk (forutsagt seksjon → reell seksjon), er det mulig å transformere den på en slik måte at vi vet hvilke piksler som kan forkastes samtidig som den generelle kvaliteten opprettholdes. Det er noen transformasjoner som gir den nøyaktige oppførselen.
Selv om det finnes andre metoder, la oss se på dem mer detaljert. diskret cosinustransformasjon (DCT - fra diskret cosinustransformasjon). Hovedfunksjoner til DCT:
- Konverterer blokker med piksler til like store blokker med frekvenskoeffisienter.
- Kondenserer kraft for å eliminere romlig redundans.
- Gir reversibilitet.
2. februar 2017 Sintra R.J. (Cintra, RJ) og Bayer F.M. (Bayer FM) publiserte en artikkel om en DCT-lignende transformasjon for bildekomprimering som bare krever 14 tillegg.
Ikke bekymre deg hvis du ikke forstår fordelene med hvert punkt. La oss nå bruke spesifikke eksempler for å se deres virkelige verdi.
La oss ta denne 8x8 blokken med piksler:
Denne blokken gjengis til følgende bilde på 8 x 8 piksler:
Bruk DCT på denne blokken med piksler og få en 8x8 blokk med koeffisienter:
Og hvis vi gjengir denne blokken med koeffisienter, vil vi få følgende bilde:
Som du kan se, ser det ikke ut som originalbildet. Du kan se at den første koeffisienten er veldig forskjellig fra alle de andre. Denne første koeffisienten er kjent som DC-koeffisienten, som representerer alle prøvene i inngangsmatrisen, noe som et gjennomsnitt.
Denne blokken med koeffisienter har en interessant egenskap: den skiller høyfrekvente komponenter fra lavfrekvente.
I et bilde er mesteparten av kraften konsentrert til lavere frekvenser, så hvis du konverterer bildet til dets frekvenskomponenter og forkaster de høyere frekvenskoeffisientene, kan du redusere mengden data som trengs for å beskrive bildet uten å ofre for mye bildekvalitet.
Frekvens refererer til hvor raskt signalet endres.
La oss prøve å bruke kunnskapen oppnådd i testsaken ved å konvertere det originale bildet til dets frekvens (blokk av koeffisienter) ved å bruke DCT og deretter forkaste en del av de minst viktige koeffisientene.
Først konverterer vi det til frekvensdomenet.
Deretter forkaster vi en del (67%) av koeffisientene, hovedsakelig den nedre høyre delen.
Til slutt rekonstruerer vi bildet fra denne forkastede koeffisientblokken (husk at den må være inverterbar) og sammenligner den med originalen.
Vi ser at det ligner originalbildet, men det er mange forskjeller fra originalen. Vi kastet ut 67,1875% og fikk fortsatt noe som ligner originalen. Det var mulig å mer gjennomtenkt forkaste koeffisientene for å få et bilde av enda bedre kvalitet, men det er neste tema.
Hver koeffisient genereres ved å bruke alle piksler
Viktig: hver koeffisient er ikke direkte kartlagt til én piksel, men er en vektet sum av alle piksler. Denne fantastiske grafen viser hvordan den første og andre koeffisienten beregnes ved å bruke vekter unike for hver indeks.
Du kan også prøve å visualisere DCT ved å se på en enkel bildeformasjon basert på den. For eksempel, her er symbolet A generert ved hjelp av hver koeffisientvekt:
4. trinn - kvantisering
Etter at vi har kastet ut noen koeffisienter ved forrige trinn, utfører vi i det siste trinnet (transformasjon) en spesiell form for kvantisering. På dette stadiet er det akseptabelt å miste informasjon. Eller, enklere, vil vi kvantisere koeffisientene for å oppnå kompresjon.
Hvordan kan du kvantisere en blokk med koeffisienter? En av de enkleste metodene er enhetlig kvantisering, når vi tar en blokk, deler vi den med én verdi (med 10) og runder resultatet.
Kan vi reversere denne blokken med koeffisienter? Ja, det kan vi, multiplisere med samme verdi som vi delte med.
Denne tilnærmingen er ikke den beste fordi den ikke tar hensyn til viktigheten av hver koeffisient. Man kan bruke en matrise av kvantiserere i stedet for en enkelt verdi, og denne matrisen kan utnytte DCT-egenskapen ved å kvantisere majoriteten av nedre høyre og minoriteten til øvre venstre.
Trinn 5 - entropikoding
Når vi har kvantisert dataene (bildeblokker, fragmenter, rammer), kan vi fortsatt komprimere dem uten tap. Det er mange algoritmiske måter å komprimere data på. Vi skal ta en rask titt på noen av dem, for en dypere forståelse kan du lese boken Understanding Compression: Data Compression for Modern Developers ("").
Videokoding ved hjelp av VLC
La oss si at vi har en strøm av karakterer: a, e, r и t. Sannsynligheten (fra 0 til 1) for hvor ofte hvert tegn dukker opp i en strøm er presentert i denne tabellen.
| a | e | r | t | |
|---|---|---|---|---|
| sannsynlighet | 0,3 | 0,3 | 0,2 | 0,2 |
Vi kan tilordne unike binære koder (helst små) til de mest sannsynlige, og større koder til de mindre sannsynlige.
| a | e | r | t | |
|---|---|---|---|---|
| sannsynlighet | 0,3 | 0,3 | 0,2 | 0,2 |
| Binær kode | 0 | 10 | 110 | 1110 |
Vi komprimerer strømmen, forutsatt at vi ender opp med å bruke 8 bits for hvert tegn. Uten komprimering ville 24 bits være nødvendig per tegn. Hvis du erstatter hvert tegn med sin kode, får du besparelser!
Det første trinnet er å kode tegnet e, som er lik 10, og det andre tegnet er a, som legges til (ikke på en matematisk måte): [10][0], og til slutt det tredje tegnet t, som gjør vår endelige komprimerte bitstrøm lik [10][0][1110] eller 1001110, som krever bare 7 bits (3,4 ganger mindre plass enn originalen).
Vær oppmerksom på at hver kode må være en unik kode med et prefiks. vil hjelpe deg med å finne disse tallene. Selv om denne metoden ikke er uten feil, er det videokodeker som fortsatt tilbyr denne algoritmiske metoden for komprimering.
Både koderen og dekoderen må ha tilgang til en symboltabell med sine binære koder. Derfor er det også nødvendig å sende en tabell som input.
Aritmetisk koding
La oss si at vi har en strøm av karakterer: a, e, r, s и t, og deres sannsynlighet er presentert i denne tabellen.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| sannsynlighet | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Ved å bruke denne tabellen vil vi bygge områder som inneholder alle mulige tegn, sortert etter det største tallet.
La oss nå kode en strøm med tre tegn: spise.
Velg først det første tegnet e, som er i underområdet fra 0,3 til 0,6 (ikke inkludert). Vi tar dette underområdet og deler det igjen i samme proporsjoner som før, men for dette nye området.
La oss fortsette å kode strømmen vår spise. Ta nå det andre tegnet a, som er i det nye underområdet fra 0,3 til 0,39, og ta deretter vårt siste tegn t og gjenta den samme prosessen igjen, får vi det endelige underområdet fra 0,354 til 0,372.
Vi trenger bare å velge et tall i det siste underområdet fra 0,354 til 0,372. La oss velge 0,36 (men du kan velge et hvilket som helst annet tall i dette underområdet). Bare med dette nummeret vil vi kunne gjenopprette den opprinnelige strømmen vår. Det er som om vi tegnet en linje innenfor områdene for å kode strømmen vår.
Den omvendte operasjonen (det vil si dekoding) er like enkelt: Med vårt nummer 0,36 og vårt startområde kan vi kjøre den samme prosessen. Men nå, ved å bruke dette nummeret, identifiserer vi strømmen som er kodet med dette nummeret.
Med det første området merker vi at tallet vårt tilsvarer skiven, derfor er dette vårt første tegn. Nå deler vi dette underområdet igjen ved å følge samme prosess som før. Her kan du se at 0,36 tilsvarer symbolet a, og etter å ha gjentatt prosessen kom vi frem til det siste tegnet t (som danner vår opprinnelige kodede strøm spise).
Både koderen og dekoderen må ha en tabell over symbolsannsynligheter, så det er nødvendig å sende den i inngangsdataene også.
Ganske elegant, ikke sant? Den som kom opp med denne løsningen var jævla smart. Noen videokodeker bruker denne teknikken (eller tilbyr den i det minste som et alternativ).
Ideen er å tapsfritt komprimere en kvantisert bitstrøm. Denne artikkelen mangler sikkert tonnevis av detaljer, årsaker, avveininger osv. Men hvis du er en utvikler, bør du vite mer. Nye kodeker prøver å bruke forskjellige entropi-kodingsalgoritmer som f.eks ÅR.
Trinn 6 - bitstrømsformat
Etter å ha gjort alt dette, gjenstår det bare å pakke ut de komprimerte rammene i sammenheng med trinnene som er utført. Dekoderen må være eksplisitt informert om beslutningene som tas av koderen. Dekoderen må være utstyrt med all nødvendig informasjon: bitdybde, fargerom, oppløsning, prediksjonsinformasjon (bevegelsesvektorer, retningsbestemt INTER-prediksjon), profil, nivå, bildefrekvens, bildetype, bildenummer og mye mer.
Vi tar en rask titt på bitstrømmen H.264. Vårt første trinn er å lage en minimal H.264 bitstrøm (FFmpeg legger som standard til alle kodingsalternativer som f.eks. SEI NAL – Vi finner ut hva det er litt lenger. Vi kan gjøre dette ved å bruke vårt eget depot og FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Denne kommandoen vil generere en rå bitstrøm H.264 med én ramme, 64×64 oppløsning, med fargerom YUV420. I dette tilfellet brukes følgende bilde som en ramme.
H.264 bitstrøm
Standard AVC (H.264) bestemmer at informasjon vil bli sendt i makrorammer (i nettverksforstand), kalt nal (dette er et nettverksabstraksjonsnivå). Hovedmålet til NAL er å gi en "nettvennlig" videopresentasjon. Denne standarden skal fungere på TV-er (strømbasert), Internett (pakkebasert).
Det er en synkroniseringsmarkør for å definere grensene til NAL-elementer. Hvert synkroniseringstoken inneholder en verdi 0x00 0x00 0x01, bortsett fra den aller første, som er lik 0x00 0x00 0x00 0x01. Hvis vi lanserer hexdump for den genererte H.264-bitstrømmen identifiserer vi minst tre NAL-mønstre i begynnelsen av filen.
Som nevnt må dekoderen ikke bare kjenne til bildedataene, men også detaljene til videoen, rammen, farger, parametere som brukes og mye mer. Den første byten til hver NAL definerer dens kategori og type.
| NAL-typeidentifikator | beskrivelse |
|---|---|
| 0 | Ukjent type |
| 1 | Kodet bildefragment uten IDR |
| 2 | Seksjon for kodet skivedata A |
| 3 | Seksjon for kodet skivedata B |
| 4 | Seksjon for kodet skivedata C |
| 5 | Kodet IDR-fragment av et IDR-bilde |
| 6 | Mer informasjon om SEI-utvidelsen |
| 7 | SPS-sekvensparametersett |
| 8 | Sett med PPS-bildeparametere |
| 9 | Adgangsskiller |
| 10 | Slutt på sekvensen |
| 11 | Slutt på tråden |
| ... | ... |
Vanligvis er den første NAL i en bitstrøm PLC. Denne typen NAL er ansvarlig for å informere om vanlige kodingsvariabler som profil, nivå, oppløsning osv.
Hvis vi hopper over den første synkroniseringsmarkøren, kan vi dekode den første byten for å finne ut hvilken NAL-type som er først.
For eksempel er den første byten etter synkroniseringstokenet 01100111, hvor den første biten (0) er i felt forbidden_zero_bit. Neste 2 biter (11) forteller oss feltet nal_ref_idc, som indikerer om denne NAL er et referansefelt eller ikke. Og de resterende 5 bitene (00111) forteller oss feltet nal_unit_type, i dette tilfellet er det SPS-blokken (7) NAL.
Andre byte (binære=01100100, hex=0x64, desember=100) i SPS NAL er feltet profile_idc, som viser profilen som koderen brukte. I dette tilfellet ble det brukt en begrenset høy profil (dvs. en høy profil uten toveis B-segmentstøtte).
Hvis du ser på bitstrømspesifikasjonen H.264 for SPS NAL vil vi finne mange verdier for parameternavn, kategori og beskrivelse. La oss for eksempel se på feltene pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Parameternavn | kategori | beskrivelse |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Hvis vi utfører noen matematiske operasjoner med verdiene til disse feltene, får vi oppløsning. Man kan representere 1920 x 1080 ved hjelp av pic_width_in_mbs_minus_1 med en verdi på 119 ((119 + 1) * makroblokkstørrelse = 120 * 16 = 1920). Igjen, for å spare plass, i stedet for å kode 1920, gjorde vi det med 119.
Hvis vi fortsetter å sjekke den opprettede videoen vår i binær form (for eksempel: xxd -b -c 11 v/minimal_yuv420.h264), så kan du gå til siste NAL, som er selve rammen.
Her ser vi de første 6 byte-verdiene: 01100101 10001000 10000100 00000000 00100001 11111111. Siden den første byten er kjent for å indikere NAL-typen, i dette tilfellet (00101) er et IDR-fragment (5), og så kan du utforske det videre:
Ved å bruke spesifikasjonsinformasjonen vil det være mulig å dekode fragmenttypen (skivetype) og rammenummer (frame_num) blant andre viktige felt.
For å få verdiene til noen felt (ue(v), me(v), se(v) eller te(v)), må vi dekode fragmentet ved hjelp av en spesiell dekoder basert på . Denne metoden er veldig effektiv for å kode variabelverdier, spesielt når det er mange standardverdier.
som betyr skivetype и frame_num av denne videoen er 7 (I-fragment) og 0 (første bilde).
En bitstrøm kan tenkes som en protokoll. Hvis du vil vite mer om bitstrømmen, bør du se spesifikasjonen ITU H.264. Her er et makrodiagram som viser hvor bildedataene er (YUV i komprimert form).
Andre bitstrømmer kan undersøkes, som f.eks VP9, H.265 (HEVC) eller til og med vår nye beste bitstream AV1. Er de like alle sammen? Nei, men når du først forstår minst én, er det mye lettere å forstå resten.
Vil du øve? Utforsk H.264-bitstrømmen
Du kan generere en enkeltbildevideo og bruke MediaInfo til å undersøke bitstrømmen H.264. Faktisk er det ingenting som hindrer deg i å se på kildekoden som analyserer bitstrømmen H.264 (AVC).
For praksis kan du bruke Intel Video Pro Analyzer (sa jeg allerede at programmet er betalt, men det er en gratis prøveversjon med en grense på 10 bilder?).
Gjennomgå
Merk at mange moderne kodeker bruker samme modell som vi nettopp studerte. La oss her ta en titt på blokkskjemaet til videokodeken Thor. Den inneholder alle trinnene vi har gått gjennom. Hele poenget med dette innlegget er i det minste å gi deg en bedre forståelse av innovasjonene og dokumentasjonen på dette området.
Tidligere ble det beregnet at 139 GB diskplass ville være nødvendig for å lagre en videofil som varer i én time i 720p-kvalitet og 30 fps. Hvis du bruker metodene som er omtalt i denne artikkelen (inter-frame og interne spådommer, transformasjon, kvantisering, entropikoding, etc.), kan du oppnå (basert på det faktum at vi bruker 0,031 biter per piksel) video av ganske tilfredsstillende kvalitet , opptar bare 367,82 MB, ikke 139 GB minne.
Hvordan oppnår H.265 bedre kompresjonsforhold enn H.264?
Nå som vi vet mer om hvordan kodeker fungerer, er det lettere å forstå hvordan nyere kodeker kan levere høyere oppløsninger med færre biter.
Hvis du sammenligner AVC и HEVC, er det verdt å huske at dette nesten alltid er et valg mellom større CPU-belastning og komprimeringsforhold.
HEVC har flere seksjons- (og underseksjons-) alternativer enn AVC, flere interne prediksjonsretninger, forbedret entropikoding og mer. Alle disse forbedringene er gjort H.265 i stand til å komprimere 50 % mer enn H.264.
Første del:
Kilde: www.habr.com