Eerste deel:
Wat? Een videocodec is een stukje software/hardware dat digitale video comprimeert en/of decomprimeert.
Voor wat? Ondanks bepaalde beperkingen, zowel qua bandbreedte als qua bandbreedte
en wat betreft de ruimte voor gegevensopslag vraagt de markt om video van steeds hogere kwaliteit. Weet je nog hoe we in de vorige post het vereiste minimum berekenden voor 30 frames per seconde, 24 bits per pixel, met een resolutie van 480x240? We ontvingen 82,944 Mbit/s zonder compressie. Compressie is momenteel de enige manier om HD/FullHD/4K algemeen naar televisieschermen en internet te verzenden. Hoe wordt dit bereikt? Laten we nu kort naar de belangrijkste methoden kijken.
De vertaling is gemaakt met ondersteuning van EDISON Software.We zijn verloofd En .
Codec versus container
Een veelgemaakte fout die nieuwelingen maken is het verwarren van digitale videocodec en digitale videocontainer. Een container is een bepaald formaat. Een wrapper met video- (en mogelijk audio-)metagegevens. De gecomprimeerde video kan worden gezien als een containerlading.
Normaal gesproken geeft de extensie van een videobestand het type container aan. Het bestand video.mp4 is bijvoorbeeld waarschijnlijk een container MPEG-4 deel 14, en waarschijnlijk is er een bestand met de naam video.mkv . Om helemaal zeker te zijn van de codec en het containerformaat, kunt u gebruik maken van of .
Een beetje geschiedenis
Voordat we er zijn Hoe?, laten we een kleine duik in de geschiedenis nemen om enkele oudere codecs een beetje beter te begrijpen.
Video codec H.261 verscheen in 1990 (technisch gezien - in 1988) en werd gemaakt om te werken met een gegevensoverdrachtsnelheid van 64 Kbps. Er werden al ideeën gebruikt zoals kleursubsampling, macroblokken, enz. De videocodecstandaard werd in 1995 gepubliceerd H.263, die zich tot 2001 ontwikkelde.
De eerste versie werd in 2003 voltooid H.264 / AVC. Datzelfde jaar bracht TrueMotion zijn gratis verliesgevende videocodec uit, genaamd VP3. Google kocht het bedrijf in 2008 en bracht het uit VP8 hetzelfde jaar. In december 2012 bracht Google dit uit VP9, en het wordt ondersteund in ongeveer ¾ van de browsermarkt (inclusief mobiele apparaten).
AV1 is een nieuwe gratis en open source videocodec ontwikkeld door Alliantie voor Open Media (AO Media), waaronder de bekendste bedrijven, zoals: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel en Cisco. De eerste versie van de codec, 0.1.0, werd op 7 april 2016 gepubliceerd.
Geboorte van AV1
Begin 2015 was Google bezig met VP10Xiph (eigendom van Mozilla) werkte aan Daala, en Cisco maakte zijn eigen gratis videocodec genaamd Thor.
dan MPEG LA eerste aangekondigde jaarlijkse limieten voor HEVC (H.265) en een vergoeding die 8 keer hoger is dan voor H.264, maar al snel veranderden ze de regels opnieuw:
geen jaarlijkse limiet,
inhoudsvergoeding (0,5% van de omzet) en
de eenheidskosten zijn ongeveer 10 keer hoger dan die van H.264.
Alliantie voor Open Media is gemaakt door bedrijven uit verschillende vakgebieden: fabrikanten van apparatuur (Intel, AMD, ARM, Nvidia, Cisco), contentproviders (Google, Netflix, Amazon), browsermakers (Google, Mozilla) en anderen.
De bedrijven hadden een gemeenschappelijk doel: een royaltyvrije videocodec. Dan verschijnt AV1 met een veel eenvoudiger patentlicentie. Timothy B. Terryberry gaf een verbluffende presentatie die de oorsprong werd van het huidige AV1-concept en het bijbehorende licentiemodel.
Het zal je verbazen dat je de AV1-codec via een browser kunt analyseren (geïnteresseerden kunnen naar).
Universele codec
Laten we eens kijken naar de belangrijkste mechanismen die ten grondslag liggen aan de universele videocodec. De meeste van deze concepten zijn nuttig en worden gebruikt in moderne codecs zoals VP9, AV1 и HEVC. Ik waarschuw u dat veel van de uitgelegde zaken vereenvoudigd zullen worden. Soms worden voorbeelden uit de echte wereld (zoals bij H.264) gebruikt om de technologie te demonstreren.
1e stap - het splitsen van de afbeelding
De eerste stap is het verdelen van het frame in verschillende secties, subsecties en meer.
Waarvoor? Er zijn veel redenen. Wanneer we een beeld splitsen, kunnen we de bewegingsvector nauwkeuriger voorspellen door kleine secties te gebruiken voor kleine bewegende delen. Terwijl je voor een statische achtergrond je kunt beperken tot grotere secties.
Codecs organiseren deze secties doorgaans in secties (of brokken), macroblokken (of coderingsboomblokken) en meerdere subsecties. De maximale grootte van deze partities varieert, HEVC stelt deze in op 64x64, terwijl AVC 16x16 gebruikt, en subpartities kunnen worden opgesplitst in een grootte van 4x4.
Herinner jij je de soorten kozijnen nog uit het laatste artikel?! Hetzelfde kan worden toegepast op blokken, dus we kunnen een I-fragment, een B-blok, een P-macroblok, enz. Hebben.
Voor degenen die willen oefenen, kijk hoe de afbeelding is verdeeld in secties en subsecties. Om dit te doen, kunt u degene gebruiken die al in het vorige artikel werd genoemd. (degene die betaald is, maar met een gratis proefversie die beperkt is tot de eerste 10 frames). Secties die hier worden geanalyseerd VP9:
2e stap - voorspellen
Zodra we secties hebben, kunnen we er astrologische voorspellingen voor doen. Voor INTER-voorspellingen moet worden overgedragen bewegingsvectoren en de rest, en voor INTRA-voorspellingen wordt het verzonden voorspelde richting en de rest.
3e stap - transformatie
Zodra we een restblok hebben (voorspelde sectie → echte sectie), is het mogelijk om het zo te transformeren dat we weten welke pixels kunnen worden weggegooid terwijl de algehele kwaliteit behouden blijft. Er zijn enkele transformaties die het exacte gedrag opleveren.
Hoewel er andere methoden zijn, laten we ze in meer detail bekijken. discrete cosinustransformatie (DCT - van discrete cosinustransformatie). Belangrijkste functies van DCT:
- Converteert blokken pixels naar blokken met frequentiecoëfficiënten van gelijke grootte.
- Condenseert het vermogen om ruimtelijke redundantie te helpen elimineren.
- Biedt omkeerbaarheid.
2 februari 2017 Sintra R.J. (Cintra, RJ) en Bayer F.M. (Bayer FM) publiceerde een artikel over een DCT-achtige transformatie voor beeldcompressie waarvoor slechts 14 toevoegingen nodig zijn.
Maak je geen zorgen als je de voordelen van elk punt niet begrijpt. Laten we nu specifieke voorbeelden gebruiken om hun echte waarde te zien.
Laten we dit 8x8 blok pixels nemen:
Dit blok wordt weergegeven in de volgende afbeelding van 8 bij 8 pixels:
Pas DCT toe op dit blok pixels en verkrijg een blok coëfficiënten van 8x8:
En als we dit blok coëfficiënten weergeven, krijgen we het volgende beeld:
Zoals u kunt zien, lijkt het niet op de originele afbeelding. Je kunt zien dat de eerste coëfficiënt heel anders is dan alle andere. Deze eerste coëfficiënt staat bekend als de DC-coëfficiënt, die alle monsters in de invoerarray vertegenwoordigt, zoiets als een gemiddelde.
Dit blok coëfficiënten heeft een interessante eigenschap: het scheidt hoogfrequente componenten van laagfrequente componenten.
In een afbeelding is het grootste deel van de kracht geconcentreerd op lagere frequenties. Als u de afbeelding dus omzet in zijn frequentiecomponenten en de hogere frequentiecoëfficiënten buiten beschouwing laat, kunt u de hoeveelheid gegevens die nodig is om de afbeelding te beschrijven verminderen zonder al te veel beeldkwaliteit op te offeren.
Frequentie verwijst naar hoe snel het signaal verandert.
Laten we proberen de kennis die we in de testcase hebben opgedaan toe te passen door het originele beeld met behulp van DCT naar zijn frequentie (blok met coëfficiënten) te converteren en vervolgens een deel van de minst belangrijke coëfficiënten weg te gooien.
Eerst converteren we het naar het frequentiedomein.
Vervolgens negeren we een deel (67%) van de coëfficiënten, voornamelijk het deel rechtsonder.
Ten slotte reconstrueren we het beeld uit dit weggegooide blok coëfficiënten (onthoud dat het omkeerbaar moet zijn) en vergelijken het met het origineel.
We zien dat het lijkt op de originele afbeelding, maar er zijn veel verschillen met het origineel. We gooiden 67,1875% weg en kregen nog steeds iets dat leek op het origineel. Het was mogelijk om de coëfficiënten zorgvuldiger weg te laten om een beeld van nog betere kwaliteit te verkrijgen, maar dat is een volgend onderwerp.
Elke coëfficiënt wordt gegenereerd met behulp van alle pixels
Belangrijk: elke coëfficiënt wordt niet rechtstreeks toegewezen aan één pixel, maar is een gewogen som van alle pixels. Deze verbazingwekkende grafiek laat zien hoe de eerste en tweede coëfficiënten worden berekend met behulp van gewichten die uniek zijn voor elke index.
Je kunt ook proberen de DCT te visualiseren door te kijken naar een eenvoudige beeldvorming die daarop is gebaseerd. Hier is bijvoorbeeld het symbool A gegenereerd met behulp van elk coëfficiëntgewicht:
4e stap - kwantisering
Nadat we bij de vorige stap enkele coëfficiënten hebben weggegooid, voeren we bij de laatste stap (transformatie) een speciale vorm van kwantisering uit. In dit stadium is het acceptabel om informatie te verliezen. Of, eenvoudiger gezegd, we zullen de coëfficiënten kwantiseren om compressie te bereiken.
Hoe kun je een blok coëfficiënten kwantiseren? Een van de eenvoudigste methoden is uniforme kwantisering, wanneer we een blok nemen, dit door één waarde delen (door 10) en het resultaat afronden.
Kunnen we dit blok coëfficiënten omkeren? Ja, dat kan, vermenigvuldigen met dezelfde waarde waarmee we hebben gedeeld.
Deze benadering is niet de beste omdat er geen rekening wordt gehouden met het belang van elke coëfficiënt. Men zou een matrix van kwantiseerders kunnen gebruiken in plaats van een enkele waarde, en deze matrix zou de DCT-eigenschap kunnen exploiteren door de meerderheid van rechtsonder en de minderheid van linksboven te kwantiseren.
Stap 5 - entropiecodering
Zodra we de gegevens (beeldblokken, fragmenten, frames) hebben gekwantiseerd, kunnen we deze nog steeds verliesvrij comprimeren. Er zijn veel algoritmische manieren om gegevens te comprimeren. We gaan er een paar bekijken. Voor een beter begrip kun je het boek Understanding Compression: Data Compression for Modern Developers lezen ("").
Videocodering met behulp van VLC
Laten we zeggen dat we een stroom karakters hebben: a, e, r и t. De waarschijnlijkheid (variërend van 0 tot 1) van hoe vaak elk personage in een stream voorkomt, wordt in deze tabel weergegeven.
| a | e | r | t | |
|---|---|---|---|---|
| Waarschijnlijkheid | 0,3 | 0,3 | 0,2 | 0,2 |
We kunnen unieke binaire codes (bij voorkeur kleine) toewijzen aan de meest waarschijnlijke, en grotere codes aan de minder waarschijnlijke.
| a | e | r | t | |
|---|---|---|---|---|
| Waarschijnlijkheid | 0,3 | 0,3 | 0,2 | 0,2 |
| Binaire code | 0 | 10 | 110 | 1110 |
We comprimeren de stream, ervan uitgaande dat we uiteindelijk 8 bits voor elk personage zullen uitgeven. Zonder compressie zouden er 24 bits per teken nodig zijn. Als u elk teken vervangt door de bijbehorende code, krijgt u besparingen!
De eerste stap is het coderen van het karakter e, wat gelijk is aan 10, en het tweede teken is a, dat wordt toegevoegd (niet op een wiskundige manier): [10][0], en ten slotte het derde teken t, waardoor onze uiteindelijke gecomprimeerde bitstream gelijk is aan [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 code met een voorvoegsel moet zijn. zal u helpen deze nummers te vinden. Hoewel deze methode niet zonder gebreken is, zijn er videocodecs die deze algoritmische methode voor compressie nog steeds aanbieden.
Zowel de encoder als de decoder moeten toegang hebben tot een symbooltabel met hun binaire codes. Daarom is het ook nodig om een tabel als invoer te verzenden.
Rekenkundige codering
Laten we zeggen dat we een stroom karakters hebben: a, e, r, s и t, en hun waarschijnlijkheid wordt in deze tabel weergegeven.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Waarschijnlijkheid | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Met behulp van deze tabel gaan we reeksen samenstellen die alle mogelijke tekens bevatten, gesorteerd op het grootste getal.
Laten we nu een stroom van drie tekens coderen: eten.
Selecteer eerst het eerste teken e, wat in het subbereik ligt van 0,3 tot 0,6 (exclusief). We nemen dit deelbereik en verdelen het opnieuw in dezelfde verhoudingen als voorheen, maar dan voor dit nieuwe bereik.
Laten we doorgaan met het coderen van onze stream eten. Neem nu het tweede teken a, dat zich in het nieuwe subbereik van 0,3 tot 0,39 bevindt, en neem dan ons laatste teken t en door hetzelfde proces opnieuw te herhalen, krijgen we het uiteindelijke subbereik van 0,354 tot 0,372.
We hoeven alleen maar een getal in het laatste subbereik van 0,354 tot 0,372 te selecteren. Laten we 0,36 kiezen (maar u kunt elk ander getal in dit deelbereik kiezen). Alleen met dit nummer kunnen we onze oorspronkelijke stream herstellen. Het is alsof we een lijn trekken binnen de bereiken om onze stream te coderen.
De omgekeerde werking (dat wil zeggen decoderen) is net zo eenvoudig: met ons getal 0,36 en ons initiële bereik kunnen we hetzelfde proces uitvoeren. Maar nu identificeren we met dit nummer de stream die met dit nummer is gecodeerd.
Bij het eerste bereik merken we dat ons nummer overeenkomt met het segment, daarom is dit ons eerste teken. Nu verdelen we dit subbereik opnieuw door hetzelfde proces te volgen als voorheen. Hier kun je zien dat 0,36 overeenkomt met het symbool a, en na herhaling van het proces kwamen we bij het laatste teken t (die onze originele gecodeerde stream vormt eten).
Zowel de encoder als de decoder moeten een tabel met symboolkansen hebben, dus het is noodzakelijk om deze ook in de invoergegevens te verzenden.
Best elegant, nietwaar? Degene die deze oplossing heeft bedacht, was verdomd slim. Sommige videocodecs gebruiken deze techniek (of bieden deze in ieder geval als optie aan).
Het idee is om een gekwantiseerde bitstroom verliesvrij te comprimeren. Dit artikel mist ongetwijfeld heel veel details, redenen, afwegingen, enz. Maar als u een ontwikkelaar bent, zou u meer moeten weten. Nieuwe codecs proberen verschillende entropiecoderingsalgoritmen te gebruiken, zoals JAAR.
Stap 6 - bitstream-formaat
Nadat je dit allemaal hebt gedaan, hoef je alleen nog maar de gecomprimeerde frames uit te pakken in de context van de uitgevoerde stappen. De decoder moet expliciet op de hoogte worden gesteld van de beslissingen die de encoder neemt. De decoder moet worden voorzien van alle benodigde informatie: bitdiepte, kleurruimte, resolutie, voorspellingsinformatie (bewegingsvectoren, directionele INTER-voorspelling), profiel, niveau, framesnelheid, frametype, framenummer en nog veel meer.
We zullen de bitstream even bekijken H.264. Onze eerste stap is het creëren van een minimale H.264 bitstream (FFmpeg voegt standaard alle coderingsopties toe, zoals SEI NAL – wat het is, zullen we verderop ontdekken). 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
Deze opdracht genereert een onbewerkte bitstream H.264 met één frame, resolutie 64×64, met kleurruimte YUV420. In dit geval wordt de volgende afbeelding als frame gebruikt.
H.264-bitstream
Standaard AVC (H.264) bepaalt dat informatie wordt verzonden in macroframes (in netwerkzin), genaamd BIJ (dit is een netwerkabstractieniveau). Het voornaamste doel van NAL is het verzorgen van een “webvriendelijke” videopresentatie. Deze standaard zou moeten werken op tv's (stream-based), internet (packet-based).
Er is een synchronisatiemarkering om de grenzen van NAL-elementen te definiëren. Elk synchronisatietoken bevat een waarde 0x00 0x00 0x01, behalve de allereerste, die gelijk is aan 0x00 0x00 0x00 0x01. Als we lanceren hexdump voor de gegenereerde H.264-bitstream identificeren we ten minste drie NAL-patronen aan het begin van het bestand.
Zoals gezegd moet de decoder niet alleen de beeldgegevens kennen, maar ook de details van de video, het frame, de kleuren, de gebruikte parameters en nog veel meer. De eerste byte van elke NAL definieert de categorie en het type ervan.
| NAL-type-ID | beschrijving |
|---|---|
| 0 | Onbekend type |
| 1 | Gecodeerd beeldfragment zonder IDR |
| 2 | Gecodeerde segmentgegevenssectie A |
| 3 | Gecodeerde segmentgegevenssectie B |
| 4 | Gecodeerde segmentgegevenssectie C |
| 5 | Gecodeerd IDR-fragment van een IDR-afbeelding |
| 6 | Meer informatie over de SEI-extensie |
| 7 | SPS-sequentieparameterset |
| 8 | Set PPS-beeldparameters |
| 9 | Toegangsscheider |
| 10 | Einde van de reeks |
| 11 | Einde draad |
| ... | ... |
Meestal is dit de eerste NAL van een bitstream PLC. Dit type NAL is verantwoordelijk voor het informeren over algemene coderingsvariabelen zoals profiel, niveau, resolutie, enz.
Als we de eerste synchronisatiemarkering overslaan, kunnen we de eerste byte decoderen om erachter te komen welk NAL-type het eerste is.
De eerste byte na het synchronisatietoken is bijvoorbeeld 01100111, waarbij het eerste bit (0) bevindt zich in veld forbidden_nul_bit. Volgende 2 bits (11) vertelt ons het veld nal_ref_idc, die aangeeft of deze NAL een referentieveld is of niet. En de overige 5 bits (00111) vertelt ons het veld uiteindelijke_eenheid_type, in dit geval is het het SPS-blok (7) NAL.
Tweede byte (binair=01100100, hex=0x64, december=100) in SPS NAL is het veld profiel_idc, waarin het profiel wordt weergegeven dat de encoder heeft gebruikt. In dit geval is gebruik gemaakt van een beperkt hoog profiel (dwz een hoog profiel zonder bidirectionele B-segmentondersteuning).
Als je naar de bitstreamspecificatie kijkt H.264 voor SPS NAL zullen we veel waarden vinden voor parameternaam, categorie en beschrijving. Laten we bijvoorbeeld eens naar de velden kijken pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Parameternaam | categorie | beschrijving |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Als we enkele wiskundige bewerkingen uitvoeren met de waarden van deze velden, krijgen we resolutie. Men kan 1920 x 1080 weergeven met behulp van pic_width_in_mbs_minus_1 met een waarde van 119 ((119 + 1) * macroblokgrootte = 120 * 16 = 1920). Nogmaals, om ruimte te besparen, in plaats van 1920 te coderen, hebben we het met 119 gedaan.
Als we onze gemaakte video in binaire vorm blijven controleren (bijvoorbeeld: xxd -b -c 11 v/minimal_yuv420.h264), dan kun je naar de laatste NAL gaan, wat het frame zelf is.
Hier zien we de eerste 6 bytewaarden: 01100101 10001000 10000100 00000000 00100001 11111111. Omdat bekend is dat de eerste byte het NAL-type aangeeft, in dit geval (00101) is een IDR-fragment (5), en dan kun je het verder verkennen:
Met behulp van de specificatie-informatie is het mogelijk om het fragmenttype te decoderen (segment_type) en framenummer (framenummer) naast andere belangrijke velden.
Om de waarden van sommige velden te verkrijgen (ue(v), me(v), se(v) of te(v)), moeten we het fragment decoderen met een speciale decoder op basis van . Deze methode is zeer efficiënt voor het coderen van variabelewaarden, vooral als er veel standaardwaarden zijn.
betekenis segment_type и framenummer van deze video zijn 7 (I-fragment) en 0 (eerste frame).
Een bitstream kan worden gezien als een protocol. Als je meer wilt weten over de bitstream, raadpleeg dan de specificatie ITU H.264. Hier is een macrodiagram dat laat zien waar de afbeeldingsgegevens zich bevinden (YUV in gecomprimeerde vorm).
Andere bitstreams kunnen worden onderzocht, zoals VP9, H.265 (HEVC) of zelfs onze nieuwe beste bitstream AV1. Zijn ze allemaal vergelijkbaar? Nee, maar zodra je er tenminste één begrijpt, is het veel gemakkelijker om de rest te begrijpen.
Wil je oefenen? Verken de H.264-bitstream
U kunt een video met één frame genereren en MediaInfo gebruiken om de bitstream te onderzoeken H.264. In feite belet niets u om zelfs maar naar de broncode te kijken die de bitstroom analyseert H.264 (AVC).
Om te oefenen kun je Intel Video Pro Analyzer gebruiken (heb ik al gezegd dat het programma betaald is, maar er is een gratis proefversie met een limiet van 10 frames?).
Recensie
Merk op dat veel moderne codecs hetzelfde model gebruiken dat we zojuist hebben bestudeerd. Laten we hier eens kijken naar het blokdiagram van de videocodec Thor. Hierin staan alle stappen die wij hebben doorlopen. Het hele doel van dit bericht is om u in ieder geval een beter inzicht te geven in de innovaties en documentatie op dit gebied.
Eerder werd berekend dat er 139 GB schijfruimte nodig zou zijn om een videobestand van een uur op te slaan in 720p-kwaliteit en 30 fps. Als je de methoden gebruikt die in dit artikel worden besproken (inter-frame en interne voorspellingen, transformatie, kwantisering, entropiecodering, enz.), dan kun je (gebaseerd op het feit dat we 0,031 bits per pixel uitgeven) video van redelijk bevredigende kwaliteit bereiken , dat slechts 367,82 MB in beslag neemt, en niet 139 GB geheugen.
Hoe bereikt H.265 een betere compressieverhouding dan H.264?
Nu we meer weten over hoe codecs werken, is het gemakkelijker te begrijpen hoe nieuwere codecs hogere resoluties kunnen leveren met minder bits.
Als we vergelijken AVC и HEVC, is het de moeite waard om te onthouden dat dit bijna altijd een keuze is tussen een grotere CPU-belasting en een compressieverhouding.
HEVC heeft meer sectie- (en subsectie-)opties dan AVC, meer interne voorspellingsrichtingen, verbeterde entropiecodering en meer. Al deze verbeteringen zijn doorgevoerd H.265 in staat om 50% meer te comprimeren dan H.264.
Eerste deel:
Bron: www.habr.com