Hoe werkt een videocodec. Deel 2. Wat, waarvoor, hoe

Eerste deel: Basisprincipes van werken met video en afbeeldingen

Wat? Een videocodec is een onderdeel van software/hardware dat digitale video comprimeert en/of decomprimeert.

Waarom? Ondanks bepaalde beperkingen qua bandbreedte en
opslagcapaciteit vraagt de markt om steeds kwaliteitsvollere video. Herinnert u zich hoe we in de vorige post de minimale vereisten voor 30 frames per seconde, 24 bits per pixel, met een resolutie van 480×240 hebben berekend? Dit gaf 82.944 Mbit/s zonder compressie. Compressie is momenteel de enige manier om HD/FullHD/4K naar televisieschermen en het internet te verzenden. Hoe wordt dit bereikt? Laten we nu kort de belangrijkste methoden bekijken.

De vertaling is mede mogelijk gemaakt door EDISON Software.

Wij zijn bezig met de integratie van bewakingssystemen, evenals de ontwikkeling van een microtomograaf.

Codec vs Container

Een veelgemaakte fout van beginners is het verwarren van de codec van digitale video met de container van digitale video. Een container is namelijk een bepaald formaat. Een omhulsel dat metadata van video (en mogelijk audio) bevat. Gecomprimeerde video kan worden beschouwd als de nuttige lading van de container.

Over het algemeen geeft de bestandsextensie van het videobestand aan welk type container het is. Bijvoorbeeld, het bestand video.mp4 is waarschijnlijk een container MPEG-4 Deel 14, terwijl een bestand met de naam video.mkv waarschijnlijk een matrjosjkais. Om volledig zeker te zijn van de codec en het formaat van de container, kan men gebruik maken van FFmpeg of MediaInfo.

Een beetje geschiedenis

Voordat we verder gaan naar Hoe?, laten we even in de geschiedenis duiken om enkele oude codecs beter te begrijpen.

Videocodec H.261 werd in 1990 geïntroduceerd (technisch gezien in 1988) en was ontworpen voor dataverbindingen van 64 Kbit/s. Het maakte al gebruik van ideeën zoals kleurensubdiscretisatie, macroblokken, enz. In 1995 werd de standaard videocodec H.263uitgebracht en is ontwikkeld tot 2001.

In 2003 werd de eerste versie van H.264/AVCafgerond. In hetzelfde jaar bracht het bedrijf 'TrueMotion' zijn gratis videocodec uit, die video met verlies comprimeert en de naam VP3droeg. In 2008 kocht Google dit bedrijf, dat 'VP8' in hetzelfde jaar uitbracht. In december 2012 lanceerde Google , en deze wordt ondersteund op ongeveer ¾ van de browsermarkt (inclusief mobiele apparaten). VP9is een nieuwe gratis videocodec met een open bron, ontwikkeld door

AV1 de Alliance for Open Media Bondgenootschap voor Open Media (AOMedia), waarvan de bekendste bedrijven zijn: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel en Cisco. De eerste versie van de codec 0.1.0 werd gepubliceerd op 7 april 2016.

De geboorte van AV1

Begin 2015 werkte Google aan VP10, Xiph (dat toebehoort aan Mozilla) werkte aan Daala, terwijl Cisco zijn gratis videocodec genaamd Thor.

Vervolgens MPEG LA sloot aanvankelijk jaarlijkse limieten af voor HEVC (H.265) en een vergoeding die 8 keer hoger was dan die voor H.264, maar al snel veranderden ze hun regels weer:

zonder jaarlijkse limiet,
een vergoeding voor inhoud (0,5% van de omzet) en
een vergoeding per eenheid die ongeveer 10 keer hoger is dan die voor H.264.

De Alliance for Open Media werd opgericht door bedrijven uit verschillende sectoren: hardwarefabrikanten (Intel, AMD, ARM, Nvidia, Cisco), contentleveranciers (Google, Netflix, Amazon), browserontwikkelaars (Google, Mozilla) en anderen.

De gemeenschappelijke doelstelling van de bedrijven was een videocodec zonder royalty's. Vervolgens verschijnt AV1 met een veel eenvoudigere patentlicentie. Timothy B. Terryberry gaf een indrukwekkende presentatie die de basis vormde voor het huidige concept van AV1 en zijn licentiemodel.

U zult verrast zijn te horen dat u de AV1-codec via een browser kunt analyseren (geïnteresseerden kunnen naar aomanalyzer.org).

universelle codec

Laten we de belangrijkste mechanismen bespreken die aan de basis liggen van de universele videocodec. De meeste van deze concepten zijn nuttig en worden gebruikt in moderne codecs, zoals VP9, AV1 en HEVC. Ik waarschuw dat veel dingen die worden uitgelegd, vereenvoudigd zullen zijn. Soms worden echte voorbeelden gebruikt (zoals in het geval van H.264) om de technologieën te demonstreren.

1e stap - het opdelen van het beeld

De eerste stap is het verdelen van het frame in meerdere secties, subsecties en verder.

Waarom? Er zijn veel redenen. Wanneer we een afbeelding opdelen, kunnen we de bewegingsvector nauwkeuriger voorspellen door kleine secties te gebruiken voor kleine bewegende delen. Terwijl voor een statische achtergrond grotere secties voldoende kunnen zijn.

Gewoonlijk organiseren codecs deze secties in secties (of fragmenten), macroblokken (of codecboomblokken) en vele subsecties. De maximale grootte van deze secties varieert; HEVC stelt 64×64 in, terwijl AVC 16×16 gebruikt, en subsecties kunnen worden opgedeeld tot 4×4.

Herinnert u zich de soorten frames uit het vorige artikel?! Dit kan ook op blokken worden toegepast, zodat we I-fragmenten, B-blokken, P-macroblokken, enz. kunnen hebben.

Voor degenen die willen oefenen — kijk hoe een afbeelding wordt opgedeeld in secties en subsections. Hiervoor kunt u gebruikmaken van wat al in het vorige artikel werd genoemd. Intel Video Pro Analyzer (de betaalde versie, maar met een gratis proefversie, met een beperking op de eerste 10 frames). Hier worden de secties geanalyseerd. VP9:

Stap 2 — prognose

Zodra we secties hebben, kunnen we astrologische prognoses opstellen op basis van deze. Voor INTER-prognose moeten bewegingsvectoren en de rest worden doorgegeven, en voor INTRA-prognose wordt de richting van de prognose en de rest doorgegeven.

Stap 3 — transformatie

Nadat we het resterende blok (voorspelde sectie → werkelijke sectie) hebben verkregen, kan het zodanig worden getransformeerd dat we weten welke pixels kunnen worden weggelaten, terwijl we de algemene kwaliteit behouden. Er zijn enkele transformaties die een nauwkeurige werking garanderen.

Hoewel er ook andere methoden zijn, laten we dieper ingaan op discrete cosinus transformatie (DCT — van discrete cosine transform). De belangrijkste functies van DCT:

• Zet pixelblokken om in blokken frequentiecoëfficiënten van gelijke grootte.
• Concentreert de energie, waardoor ruimtelijke redundanties worden geëlimineerd.
• Biedt reversibiliteit.

Op 2 februari 2017 publiceerden Cintra R.J. en Bayer F.M. een artikel over DCT-achtige transformatie voor afbeeldingscompressie, die slechts 14 aanvullingen vereist.

Maak je geen zorgen als je de voordelen van elk punt niet begrijpt. We zullen nu met concrete voorbeelden de echte waarde ervan aantonen.

Laten we een blok pixels van 8×8 nemen:

Dit blok wordt gerenderd naar de volgende afbeelding van 8 op 8 pixels:

Pas DCT toe op dit blok pixels en we krijgen een coëfficiëntenblok van 8×8:

En als we dit coëfficiëntenblok renderen, krijgen we de volgende afbeelding:

Zoals we zien, lijkt dit niet op de oorspronkelijke afbeelding. Het valt op dat de eerste coëfficiënt sterk verschilt van alle andere. Deze eerste coëfficiënt staat bekend als de DC-coëfficiënt, die alle monsters in de invoerarray vertegenwoordigt, iets dat lijkt op het gemiddelde.

Dit blok van coëfficiënten heeft een interessante eigenschap: het scheidt hoge frequentiecomponenten van lage frequenties.

In de afbeelding is het merendeel van de kracht geconcentreerd op lagere frequenties, dus als we de afbeelding omzetten in zijn frequentiecomponenten en de hogere coëfficiënten weggooien, kunnen we de hoeveelheid gegevens die nodig is om de afbeelding te beschrijven verminderen, zonder al te veel in te boeten op de kwaliteit van het beeld.

Frequentie betekent hoe snel het signaal verandert.

Laten we proberen de kennis die we hebben opgedaan in het testvoorbeeld toe te passen door de originele afbeelding naar zijn frequentie (de coëfficiëntenblok) om te zetten met behulp van DCT, en vervolgens een deel van de minst belangrijke coëfficiënten weg te gooien.

Eerst zetten we het om in het frequentiedomein.

Daarna gooien we een deel (67%) van de coëfficiënten weg, voornamelijk de rechter onderkant.

Ten slotte herstellen we de afbeelding uit dit weggegooide coëfficiëntenblok (onthoud dat dit omkeerbaar moet zijn) en vergelijken we deze met het origineel.

We zien dat het lijkt op de originele afbeelding, maar er zijn veel verschillen met het origineel. We hebben 67,1875% weggegooid en toch iets ontvangen dat lijkt op de bron. Het had een doordachtere coëfficiëntselectie kunnen zijn om een afbeelding van nog betere kwaliteit te krijgen, maar dat is een volgend onderwerp.

Elke coëfficiënt wordt gevormd met behulp van alle pixels.

Belangrijk: elke coëfficiënt komt niet rechtstreeks overeen met één pixel, maar vertegenwoordigt een gewogen som van alle pixels. Deze indrukwekkende grafiek toont aan hoe de eerste en tweede coëfficiënt worden berekend met behulp van gewichten die uniek zijn voor elke index.

Je kunt ook proberen DCT te visualiseren door naar een eenvoudige afbeelding te kijken die er op is gebaseerd. Bijvoorbeeld, hier is het symbool A, gevormd met behulp van elke coëfficiëntgewicht:

Stap 4 - kwantificatie

Nadat we in de vorige stap enkele coëfficiënten hebben weggegooid, voeren we in de laatste stap (transformatie) een speciale vorm van kwantificatie uit. In deze fase is het toegestaan om informatie te verliezen. Of eenvoudiger gezegd, we zullen de coëfficiënten kwantificeren om compressie te bereiken.

Hoe kunnen we een blok coëfficiënten kwantiseren? Een van de eenvoudigste methoden is uniforme kwantisatie, waarbij we het blok delen door één waarde (door 10) en het resultaat afronden.

Kunnen we dit blok coëfficiënten omkeren? Ja, dat kunnen we, door het te vermenigvuldigen met dezelfde waarde als waarmee we gedeeld hebben.

Deze aanpak is niet de beste, omdat het de belangrijkheid van elke coëfficiënt niet in aanmerking neemt. We zouden een matrix van kwantiseerders in plaats van één waarde kunnen gebruiken, en deze matrix kan gebruik maken van de DCT-eigenschap, waarmee de meeste onderste rechter coëfficiënten en een paar bovenste linker coëfficiënten gekwantiseerd worden.

Stap 5 — entropiecodering

Nadat we de gegevens (beeldblokken, fragmenten, frames) gekwantiseerd hebben, kunnen we ze nog steeds zonder verlies comprimeren. Er zijn veel algoritmische methoden voor datacompresie. We zullen kort enkele hiervan bekijken; voor een diepgaand begrip kunt u het boek "Understanding Compression: Data Compression for Modern Developers" lezen.Understanding Compression: Data Compression for Modern Developers»).

Video coderen met VLC

Stel dat we een stroom van symbolen hebben: a, e, , die de eerste regel van het verzoek, de headers en de gegevens scheidt. en t. De kans (tussen 0 en 1) dat elk symbool in de stroom voorkomt, wordt in deze tabel gepresenteerd.

We kunnen unieke binaire codes (bij voorkeur kleine) toewijzen aan de meest waarschijnlijke symbolen, en grotere codes aan de minder waarschijnlijke.

We comprimeren de stroom en veronderstellen dat we uiteindelijk 8 bits per symbool gebruiken. Zonder compressie zouden we 24 bits per symbool nodig hebben. Als we elk symbool vervangen door zijn code, dan besparen we ruimte!

De eerste stap is het coderen van het symbool e, dat gelijk is aan 10, en het tweede symbool is a, dat wordt toegevoegd (niet wiskundig): [10] [0], en tenslotte is het derde symbool t, waardoor onze uiteindelijke gecomprimeerde bitstroom [10] [0] [1110] of 1001110, waarvoor slechts 7 bits nodig zijn (3,4 keer minder ruimte dan het origineel).

Houd er rekening mee dat elke code een unieke prefixcode moet zijn. Het Huffman-algoritme zal helpen deze cijfers te vinden. Hoewel deze methode niet zonder tekortkomingen is, zijn er videocodexen die nog steeds deze algoritmische methode voor compressie aanbieden.

Zowel de coder als de decoder moeten toegang hebben tot de symbolentabel met hun binaire codes. Daarom moet ook de tabel in de invoer worden verzonden.

Aritmetische codering

Stel dat we een stroom van symbolen hebben: a, e, , die de eerste regel van het verzoek, de headers en de gegevens scheidt., str1 != str2 en t, en hun waarschijnlijkheid wordt weergegeven in deze tabel.

Met deze tabel zullen we de bereiken construeren die alle mogelijke symbolen bevatten, gesorteerd op het grootste aantal.

Laten we nu een stroom van drie symbolen coderen: eat.

Kies eerst het eerste symbool e, dat zich in het subbereik van 0,3 tot 0,6 (exclusief) bevindt. We nemen dit subbereik en splitsen het opnieuw in dezelfde verhoudingen als eerder, maar nu voor dit nieuwe bereik.

Laten we doorgaan met het coderen van onze stroom eat. Nu nemen we het tweede symbool a, dat zich in het nieuwe subbereik van 0,3 tot 0,39 bevindt, en daarna nemen we ons laatste symbool t en, door hetzelfde proces opnieuw te herhalen, krijgen we het laatste subbereik van 0,354 tot 0,372.

We hoeven alleen maar een getal te kiezen in het laatste subbereik van 0,354 tot 0,372. Laten we 0,36 kiezen (maar we kunnen ook een ander getal in dit subbereik kiezen). Alleen met dit getal kunnen we onze oorspronkelijke stroom herstellen. Het is alsof we een lijn tekenen binnen de bereiken voor het coderen van onze stroom.

De omgekeerde operatie (oftewel decodering) is net zo eenvoudig: met ons getal 0,36 en ons oorspronkelijke bereik kunnen we hetzelfde proces starten. Maar nu gebruiken we dit getal om de stroom te onthullen die met dit getal is gecodeerd.

Met het eerste bereik merken we dat ons getal overeenkomt met de snede, dus dit is ons eerste symbool. Laten we dit subbereik opnieuw splitsen door hetzelfde proces als eerder uit te voeren. Hier zien we dat 0,36 correspondeert met het symbool a, en na herhaling van het proces komen we bij het laatste symbool t (vormend onze oorspronkelijke gecodeerde stroom eat).

En voor zowel de coder als de decoder moet er een tabel met de waarschijnlijkheden van symbolen zijn, dus het is noodzakelijk om deze ook in de invoer mee te sturen.

Best elegant, toch? Iemand die deze oplossing verzon, was verdomd slim. Sommige videocodecs gebruiken deze techniek (of bieden deze in ieder geval als optie aan).

Het idee is om een kwantum binaire stroom verliesvrij te comprimeren. Er ontbreken ongetwijfeld talloze details, redenen, compromissen, enz. in dit artikel. Maar als je een ontwikkelaar bent, zou je meer moeten weten. Nieuwe codecs proberen verschillende algoritmes voor entropiecodering te gebruiken, zoals ANS.

Stap 6 - formaat van de binaire stroom

Nadat dit alles is gedaan, blijft er nog maar één ding over: de gecomprimeerde frames terugpakken binnen de context van de uitgevoerde stappen. De decoder moet expliciet worden geïnformeerd over de beslissingen die de coder heeft genomen. Alle benodigde informatie moet aan de decoder worden verstrekt: bitsdiepte, kleurruimte, resolutie, prognose-informatie (bewegingsvectoren, gerichte INTER-prognose), profiel, niveau, framerate, type frame, frame-nummer en nog veel meer.

We zullen de binaire stroom oppervlakkig verkennen H.264. Onze eerste stap is het creëren van een minimale H.264 binaire stroom (FFmpeg voegt standaard alle coderingseigenschappen toe, zoals SEI NAL — later zullen we ontdekken wat dit is). We kunnen dit doen met behulp van onze eigen repository en FFmpeg.

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

Dit commando genereert een onbewerkte binaire stroom H.264 met één frame, een resolutie van 64×64, met een kleurschema YUV420. Het volgende afbeelding wordt hiervoor als frame gebruikt.

De H.264 binaire stroom

De standaard AVC (H.264) bepaalt dat informatie wordt verzonden in macroframes (in de netwerkomgeving), die worden genoemd NAL (dit is een abstractieniveau in netwerken). Het primaire doel van NAL is het bieden van een netwerkvriendelijke weergave van video. Deze standaard moet werken op televisies (op basis van stromen), op internet (op basis van pakketten).

Er is een synchronisatie-marker om de grenzen van NAL-elementen te bepalen. Elke synchronisatie-marker bevat een waarde 0x00 0x00 0x01, tenzij het de allereerste is, die gelijk is aan 0x00 0x00 0x00 0x01. Als we hexdump uitvoeren voor de gegenereerde H.264 binaire stroom, kunnen we minstens drie NAL-patronen aan het begin van het bestand identificeren.

Zoals eerder vermeld, moet de decoder niet alleen de afbeeldingsgegevens kennen, maar ook de details van de video, het frame, de kleuren, de gebruikte parameters en nog veel meer. De eerste byte van elk NAL bepaalt zijn categorie en type.

Normaal gesproken is het eerste NAL van de bitstroom SPS. Dit type NAL is verantwoordelijk voor het informeren over de algemene coderingsvariabelen zoals profiel, niveau, resolutie, enzovoort.

Als we de eerste synchronisatiemarker overslaan, kunnen we de eerste byte decoderen om te weten welk type NAL de eerste is.

Bijvoorbeeld, de eerste byte na de synchronisatiemarker is gelijk aan 01100111, waarbij de eerste bit (0) zich in het f-veld bevindtorbidden_zero_bit. De volgende 2 bits (11) geven ons het veld nal_ref_idc, dat aangeeft of dit NAL een referentieveld is of niet. En de overige 5 bits (00111) geven ons het veld nal_unit_type, in dit geval is dit een SPS-blok (7) NAL.

De tweede byte (binair=01100100, hex=0x64, dec=100) in SPS NAL is het veld profile_idc, dat het profiel toont dat door de encoder is gebruikt. In dit geval is het een beperkt high profile gebruikt (d.w.z. high profile zonder ondersteuning voor bidirectionele B-segmenten).

Als we de specificatie van de bitstroom H.264 voor SPS NAL bekijken, vinden we veel waarden voor de parameternaam, categorie en beschrijving. Laten we bijvoorbeeld de velden pic_width_in_mbs_minus_1 en pic_height_in_map_units_minus_1.

Als we enkele wiskundige bewerkingen op de waarden van deze velden uitvoeren, krijgen we de resolutie. We kunnen 1920 x 1080 voorstellen als pic_width_in_mbs_minus_1 met de waarde 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Nogmaals, om ruimte te besparen, hebben we in plaats van 1920 dit met 119 gedaan.

Als we blijven controleren of ons gemaakte video in binaire vorm (bijv.: xxd -b -c 11 v/minimal_yuv420.h264) gaan we naar de laatste NAL die het frame zelf is.

Hier zien we de eerste 6 bytewaarden: 01100101 10001000 10000100 00000000 00100001 11111111. Aangezien bekend is dat de eerste byte het type NAL aangeeft, in dit geval (00101) is dit een IDR-fragment (5), en dan kunnen we verder onderzoeken:

Met behulp van de informatie uit de specificatie kunnen we het type fragment decoderen (slice_type) en het frame nummer (frame_num) onder andere belangrijke velden.

Om waarden van sommige velden (ue(v), me(v), se(v) of tum(v) te krijgen, moeten we het fragment decoderen met behulp van een speciale decoder gebaseerd op exponentiële Golomb-code. Deze methode is zeer effectief voor het coderen van variabele waarden, vooral wanneer er veel standaardwaarden zijn.

Waarden slice_type en frame_num deze video is gelijk aan 7 (I-fragment) en 0 (eerste frame).

De bitstream kan worden beschouwd als een protocol. Als je meer wilt weten over de bitstream, is het de moeite waard om de specificatie te raadplegen ITU H.264. Hier is een macro-schema dat laat zien waar de afbeeldingsgegevens zich bevinden (YUV in gecomprimeerde vorm).

Je kunt ook andere bitstreams onderzoeken, zoals VP9, H.265 (HEVC) of zelfs onze nieuwe beste bitstream AV1. Zijn ze allemaal vergelijkbaar? Nee, maar als je ten minste één begrijpt, is het veel gemakkelijker om de anderen te begrijpen.

Wil je oefenen? Verken de H.264 bitstream

Je kunt een enkel-frame video genereren en MediaInfo gebruiken om de bitstream te onderzoeken H.264. In feite is er niets wat je tegenhoudt om zelfs de broncode te bekijken die de bitstream analyseert. H.264 (AVC).

Voor praktische oefeningen kun je de Intel Video Pro Analyzer gebruiken (ik heb al eerder gezegd dat het programma betaald is, maar er is een gratis proefversie met een beperking van 10 frames?).

Overzicht

Laten we opmerken dat veel moderne codecs hetzelfde model gebruiken dat we net hebben bestudeerd. Laten we eens kijken naar het stroomdiagram van de video-codec Thor. Het bevat alle stappen die we hebben doorlopen. Het hele doel van deze nota is dat je in ieder geval de innovaties en documentatie op dit gebied beter begrijpt.

Eerder schatten we dat er 139 GB schijfruimte nodig is voor het opslaan van een videobestand van één uur op 720p en 30 fps. Als we de methoden analyseren die in dit artikel zijn behandeld (inter-frame en intra-frame voorspellingen, transformatie, kwantisatie, entropiecodering, enz.), kunnen we (uitgaande van 0,031 bit per pixel) een video van voldoende kwaliteit bereiken die slechts 367,82 MB groot is, in plaats van 139 GB aan geheugen.

Hoe bereikt H.265 een betere compressiegraad dan H.264?

Nu, nu we meer weten over hoe codecs werken, is het gemakkelijker om te begrijpen hoe nieuwe codecs in staat zijn om hogere resoluties te bieden met minder bits.

Bij vergelijking AVC en HEVC, moet je niet vergeten dat dit bijna altijd een keuze is tussen een grotere belasting op de CPU en de compressiegraad.

HEVC heeft meer secties (en subsectoren) dan AVC, meer richtingen voor interne voorspellingen, verbeterde entropiecodering en nog veel meer. Al deze verbeteringen hebben H.265 de mogelijkheid om 50% meer te comprimeren dan H.264.

Eerste deel: Basisprincipes van werken met video en afbeeldingen

Bron: habr.com