Come funziona un codec video. Parte 2. Cosa, perché, come

Prima parte: Fondamenti del lavoro con video e immagini

Cosa? Il codec video è una parte del software / hardware che comprime e / o decomprime video digitale.

A cosa serve? Nonostante alcuni limiti sia in termini di larghezza di banda che
di spazio di archiviazione, il mercato richiede video di qualità sempre migliore. Ricordate come nel post precedente abbiamo calcolato il minimo necessario per 30 fotogrammi al secondo, 24 bit per pixel, con risoluzione 480×240? Abbiamo ottenuto 82,944 Mbps senza compressione. La compressione è attualmente l'unico modo per trasferire HD / FullHD / 4K su schermi televisivi e Internet. Come si ottiene? Ora daremo una rapida occhiata ai principali metodi.

Traduzione realizzata con il supporto di EDISON Software.

Ci occupiamo di integrazione di sistemi di videosorveglianza, e inoltre sviluppiamo un microtomografo.

Codec vs Contenitore

Un errore comune tra i principianti è confondere il codec video digitale e il contenitore video digitale. Un contenitore è un certo formato. Un involucro che contiene metadati video (e, possibilmente, audio). Il video compresso può essere visto come un payload del contenitore.

Solitamente, l'estensione del file video indica il suo tipo di contenitore. Ad esempio, il file video.mp4 è probabilmente un contenitore MPEG-4 Parte 14, mentre un file chiamato video.mkv è molto probabilmente una matrёška. Per essere completamente certi del codec e del formato del contenitore, si può utilizzare FFmpeg o MediaInfo.

Un po' di storia

Prima di passare a Come?, immergiamoci un po' nella storia per comprendere meglio alcuni codec più vecchi.

Il codec video H.261 è stato introdotto nel 1990 (tecnicamente nel 1988) ed è stato creato per funzionare con una velocità di trasmissione dati di 64 Kbps. Già in esso si utilizzavano idee come la sottocomposizione cromatica, i macroblocchi e così via. Nel 1995 è stato pubblicato lo standard del codec video H.263, che è stato sviluppato fino al 2001.

Nel 2003 è stata completata la prima versione H.264 / AVC. Nello stesso anno, la società "TrueMotion" ha rilasciato il proprio codec video gratuito, che comprimeva video con perdita chiamato VP3. Nel 2008 Google ha acquisito questa azienda, rilasciando VP8 nello stesso anno. Nel dicembre 2012 Google ha rilasciato VP9, ed è supportato da circa ¾ del mercato dei browser (inclusi i dispositivi mobili).

AV1 è un nuovo codec video gratuito e open source, sviluppato dall'Alleato per i media aperti (AOMedia), che comprende famosissime aziende come: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel e Cisco. La prima versione del codec 0.1.0 è stata pubblicata il 7 aprile 2016.

La nascita di AV1

All'inizio del 2015 Google stava lavorando su VP10, Xiph (che appartiene a Mozilla) stava lavorando su Daala, mentre Cisco ha creato il suo codec video gratuito chiamato Thor.

Poi MPEG LA ha inizialmente annunciato limiti annuali per HEVC (H.265) e una tariffa che era 8 volte superiore a quella di H.264, ma presto hanno cambiato le regole di nuovo:

senza limite annuale,
una tariffa per il contenuto (0,5% dei ricavi) e
una tariffa per unità di prodotto circa 10 volte superiore a quella di H.264.

L'alleanza per i media aperti è stata creata da aziende di diversi settori: produttori di hardware (Intel, AMD, ARM, Nvidia, Cisco), fornitori di contenuti (Google, Netflix, Amazon), creatori di browser (Google, Mozilla) e altri.

Le aziende avevano un obiettivo comune: un codec video senza royalties. Poi è arrivato AV1 con una licenza sui brevetti molto più semplice. Timothy B. Terriberry ha fatto una presentazione straordinaria che è diventata la fonte dell'attuale concetto di AV1 e del suo modello di licenza.

Resterete sorpresi di sapere che è possibile analizzare il codec AV1 attraverso il browser (chi è interessato può andare su aomanalyzer.org).

Codec universale

Esaminiamo i principali meccanismi alla base del codec video universale. La maggior parte di questi concetti è utile e viene utilizzata nei codec moderni, come VP9, AV1 e HEVC. Avviso: molte delle cose spiegate saranno semplificate. A volte verranno utilizzati esempi reali (come nel caso di H.264) per dimostrare le tecnologie.

Primo passo - suddivisione dell'immagine

Il primo passo è dividere il fotogramma in diverse sezioni, sottosezioni e così via.

Perché? Ci sono molte ragioni. Quando dividiamo l'immagine, possiamo prevedere più accuratamente il vettore di movimento usando piccole sezioni per parti in movimento ridotte. Mentre per uno sfondo statico possiamo anche limitarci a sezioni più grandi.

Di solito, i codec organizzano queste sezioni in sezioni (o frammenti), macroblocchi (o blocchi dell'albero di codifica) e numerose sottosezioni. La dimensione massima di queste sezioni varia, HEVC imposta 64×64, mentre AVC utilizza 16×16, e le sottosezioni possono essere suddivise fino a dimensioni 4×4.

Ricordate le varietà di frame dall'articolo precedente?! Questo si può applicare anche ai blocchi, quindi possiamo avere I-frammento, B-blocco, P-macroblocco, e così via.

Per coloro che vogliono esercitarsi — guardate come l'immagine verrà suddivisa in sezioni e sottosezioni. A questo scopo, si può utilizzare quanto già citato nell'articolo precedente Intel Video Pro Analyzer (quello a pagamento, ma con una versione di prova gratuita, con un limite sui primi 10 frame). Qui sono stati analizzati i settori VP9:

2° passo — previsione

Appena abbiamo le sezioni, possiamo fare previsioni astrologiche su di esse. Per INTER-previsione è necessario trasmettere i vettori di movimento e il resto, mentre per INTRA-previsione viene trasmesso la direzione della previsione e il resto.

3° passo — trasformazione

Dopo aver ottenuto il blocco residuo (sezione prevista → sezione reale), è possibile trasformarlo in modo da sapere quali pixel possono essere scartati, mantenendo così la qualità generale. Ci sono alcune trasformazioni che garantiscono un comportamento preciso.

Anche se ci sono altri metodi, consideriamo più in dettaglio la trasformazione discreta del coseno (DCT — da discrete cosine transform). Le funzioni principali della DCT:

• Trasforma blocchi di pixel in blocchi di coefficienti di frequenza di dimensioni identiche.
• Compatta la potenza, aiutando a eliminare la ridondanza spaziale.
• Garantisce l'invertibilità.

Il 2 febbraio 2017, Cintra R.J. (Cintra, R.J.) e Bayer F.M. (Bayer F.M.) hanno pubblicato un articolo sulla trasformazione DCT-simile per la compressione delle immagini, che richiede solo 14 somme.

Non preoccupatevi se non avete compreso i vantaggi di ogni punto. Adesso, con esempi concreti, ci renderemo conto del loro reale valore.

Prendiamo ad esempio un blocco di pixel 8×8:

Questo blocco viene reso nell'immagine 8 su 8 pixel seguente:

Applichiamo la DCT a questo blocco di pixel e otteniamo un blocco di coefficienti di dimensioni 8×8:

E se rendiamo questo blocco di coefficienti, otteniamo l'immagine seguente:

Come vediamo, non assomiglia all'immagine originale. Possiamo notare che il primo coefficiente è molto diverso da tutti gli altri. Questo primo coefficiente è noto come coefficiente DC, che rappresenta tutte le campionature dell'array di input, simile a una media.

Questo blocco di coefficienti possiede una proprietà interessante: separa le componenti ad alta frequenza da quelle a bassa frequenza.

Nell'immagine, la maggior parte della potenza è concentrata su frequenze più basse, quindi, se convertiamo l'immagine nelle sue componenti di frequenza e scartiamo i coefficienti ad alta frequenza, possiamo ridurre la quantità di dati necessari per descrivere l'immagine senza sacrificare troppo la qualità dell'immagine.

La frequenza indica quanto velocemente cambia il segnale.

Proviamo a applicare le conoscenze acquisite nell'esempio di test, convertendo l'immagine di origine nella sua frequenza (blocco di coefficienti) utilizzando la DCT e poi scartando parte dei coefficienti meno importanti.

Iniziamo convertendolo nell'area di frequenza.

Successivamente, scartiamo parte (67%) dei coefficienti, principalmente la parte inferiore destra.

Infine, ripristiniamo l'immagine da questo blocco di coefficienti scartati (ricorda, deve essere invertibile) e la confrontiamo con l'originale.

Vediamo che somiglia all'immagine originale, ma ci sono molte differenze rispetto all'originale. Abbiamo scartato il 67,1875% e abbiamo comunque ottenuto qualcosa che ricorda l'originale. Avremmo potuto scartare i coefficienti in modo più ponderato per ottenere un'immagine di qualità ancora migliore, ma questo è un argomento successivo.

Ogni coefficiente viene formato utilizzando tutti i pixel.

Importante: ogni coefficiente non corrisponde direttamente a un pixel, ma rappresenta una somma pesata di tutti i pixel. Questo sorprendente grafico mostra come viene calcolato il primo e il secondo coefficiente utilizzando pesi unici per ogni indice.

Puoi anche tentare di visualizzare la DCT, guardando la semplice formazione di un'immagine sulla sua base. Ad esempio, ecco il simbolo A, formato utilizzando ciascun peso del coefficiente:

Passo 4: quantizzazione

Dopo aver scartato alcuni coefficienti nel passaggio precedente, nell'ultimo passaggio (trasformazione) realizziamo una particolare forma di quantizzazione. In questa fase è accettabile perdere informazioni. In altre parole, quantizzeremo i coefficienti per ottenere compressione.

Come possiamo quantizzare un blocco di coefficienti? Uno dei metodi più semplici è la quantizzazione uniforme, in cui prendiamo il blocco, lo dividiamo per un valore (per 10) e arrotondiamo il risultato ottenuto.

Possiamo invertire questo blocco di coefficienti? Sì, possiamo, moltiplicando per lo stesso valore con cui abbiamo diviso.

Questo approccio non è il migliore, poiché non considera l'importanza di ogni coefficiente. Si potrebbe utilizzare una matrice di quantizzatori invece di un singolo valore, e questa matrice può sfruttare la proprietà DCT, quantizzando la maggior parte dei coefficienti inferiori destri e una minoranza superiore sinistra.

5 passo — codifica dell'entropia

Dopo aver quantizzato i dati (blocchi di immagini, frammenti, fotogrammi), possiamo ancora comprimerli senza perdita. Esistono molte modalità algoritmiche di compressione dei dati. Ci proponiamo di dare una breve introduzione ad alcune di esse; per una comprensione più profonda puoi leggere il libro "Understanding Compression: Data Compression for Modern Developers" (Understanding Compression: Data Compression for Modern Developers»).

Codifica video con VLC

Supponiamo di avere un flusso di simboli: a, e, r e t. La probabilità (compresa tra 0 e 1) con cui ogni simbolo appare nel flusso è rappresentata in questa tabella.

Possiamo assegnare codici binari unici (preferibilmente brevi) ai simboli più probabili e codici più lunghi ai simboli meno probabili.

Comprimiamo il flusso assumendo che alla fine spenderemo 8 bit per ogni simbolo. Senza compressione, ci vorrebbero 24 bit per simbolo. Se sostituiamo ogni simbolo con il suo codice, otteniamo un risparmio!

Il primo passo consiste nella codifica del simbolo e, che è uguale a 10, e il secondo simbolo è a, che viene aggiunto (non in modo matematico): [10] [0], e infine, il terzo simbolo t, che fa sì che il nostro flusso di bit compresso finale sia [10] [0] [1110] o 1001110, il che richiede solo 7 bit (3,4 volte meno spazio rispetto all'originale).

Si prega di notare che ogni codice deve essere un codice unico con prefisso. L'algoritmo di Huffman aiuterà a trovare questi numeri. Anche se questo metodo non è privo di difetti, ci sono codec video che ancora offrono questo metodo algoritmico per la compressione.

Sia il codificatore che il decodificatore devono avere accesso alla tabella dei caratteri con i loro codici binari. È quindi necessario inviare i dati in ingresso anche la tabella.

Codifica aritmetica

Supponiamo di avere un flusso di simboli: a, e, r, s e t, e la loro probabilità è rappresentata da questa tabella.

Con questa tabella costruiremo intervalli che contengono tutti i caratteri possibili, ordinati per la maggiore quantità.

Ora codifichiamo una sequenza di tre caratteri: eat.

Iniziamo scegliendo il primo carattere e, che si trova nell'intervallo da 0,3 a 0,6 (escluso). Prendiamo questo sottointervallo e lo suddividiamo di nuovo nelle stesse proporzioni di prima, ma per questo nuovo intervallo.

Continuiamo a codificare la nostra sequenza eat. Ora prendiamo il secondo carattere a, che si trova nel nuovo sottointervallo da 0,3 a 0,39, e poi prendiamo il nostro ultimo carattere t e, ripetendo lo stesso processo di nuovo, otteniamo l'ultimo sottointervallo da 0,354 a 0,372.

Dobbiamo semplicemente scegliere un numero nell'ultimo sottointervallo da 0,354 a 0,372. Scegliamo 0,36 (ma possiamo scegliere anche un altro numero in questo sottointervallo). Solo con questo numero saremo in grado di ricostruire la nostra sequenza originale. È come se disegnassimo una linea all'interno degli intervalli per codificare la nostra sequenza.

L'operazione inversa (ossia decodifica) è altrettanto semplice: con il nostro numero 0,36 e il nostro intervallo di partenza possiamo avviare lo stesso processo. Ma ora, utilizzando questo numero, rileviamo la sequenza codificata con questo numero.

Con il primo intervallo notiamo che il nostro numero corrisponde a un taglio, quindi questo è il nostro primo carattere. Ora suddividiamo di nuovo questo sottointervallo, eseguendo lo stesso processo di prima. Qui possiamo notare che 0,36 corrisponde al carattere a, e dopo aver ripetuto il processo siamo arrivati all'ultimo carattere t (formando la nostra sequenza codificata originale eat).

Sia per il codificatore che per il decodificatore deve essere disponibile una tabella delle probabilità dei caratteri, quindi è necessario inviarla anche nei dati in ingresso.

Piuttosto elegante, vero? Chi ha ideato questa soluzione era davvero molto intelligente. Alcuni codec video utilizzano questa tecnica (o, in ogni caso, la offrono come opzione).

L'idea è quella di comprimere senza perdita un flusso di bit quantizzato. Sicuramente in questo articolo mancano tonnellate di dettagli, motivi, compromessi, ecc. Ma se sei un sviluppatore, dovresti sapere di più. I nuovi codec cercano di utilizzare diversi algoritmi di codifica dell'entropia, come ANS.

Passo 6 - formato del flusso di bit

Dopo aver fatto tutto questo, resta da decomprimere i frame compressi nel contesto dei passaggi eseguiti. È necessario informare esplicitamente il decodificatore delle decisioni prese dal codificatore. Al decodificatore deve essere fornita tutta l'informazione necessaria: profondità del bit, spazio colore, risoluzione, informazioni sulle previsioni (vettori di movimento, previsione INTER direzionale), profilo, livello, frequenza dei fotogrammi, tipo di fotogramma, numero di fotogramma e molto altro.

Daremo un'occhiata superficiale al flusso di bit H.264. Il nostro primo passo è creare un flusso di bit H.264 minimo (FFmpeg per impostazione predefinita aggiunge tutti i parametri di codifica, come SEI NAL — scopriremo più avanti di cosa si tratta). Possiamo farlo utilizzando il nostro stesso repository e FFmpeg.

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

Questo comando genererà un flusso di bit non elaborato H.264 con un fotogramma, risoluzione 64×64, con spazio colore YUV420. Utilizzeremo come fotogramma la seguente immagine.

Flusso di bit H.264

Standard AVC (H.264) definisce che l'informazione verrà inviata in macroblocchi (nel senso di rete), chiamati NAL (questo è un certo livello di astrazione della rete). L'obiettivo principale di NAL è fornire una rappresentazione video "friendly per la rete". Questo standard deve funzionare su televisori (basato su flussi), su Internet (basato su pacchetti).

Esiste un marcatore di sincronizzazione per definire i confini degli elementi NAL. Ogni marcatore di sincronizzazione contiene un valore 0x00 0x00 0x01, eccetto il primo, che è uguale a 0x00 0x00 0x00 0x01. Se lanciamo hexdump per il flusso di bit H.264 generato, identificheremo almeno tre pattern NAL all'inizio del file.

Come detto, il decodificatore deve conoscere non solo i dati dell'immagine, ma anche i dettagli del video, del fotogramma, dei colori, dei parametri utilizzati e molto altro. Il primo byte di ogni NAL determina la sua categoria e tipo.

Di solito, il primo NAL del flusso bit è SPS. Questo tipo di NAL è responsabile di fornire informazioni sulle variabili di codifica generali, come profilo, livello, risoluzione e altro.

Se saltiamo il primo marker di sincronizzazione, possiamo decodificare il primo byte per scoprire di che tipo di NAL si tratta.

Ad esempio, il primo byte dopo il marker di sincronizzazione è 01100111, dove il primo bit (0) si trova nel campo forbidden_zero_bit. I successivi 2 bit (11) ci informano sul campo nal_ref_idc, che indica se questo NAL è un campo di riferimento o meno. E i restanti 5 bit (00111) ci informano sul campo nal_unit_type, in questo caso è un blocco SPS (7) NAL.

Il secondo byte (binary=01100100, hex=0x64, dec=100) nell'SPS NAL è il campo profile_idc, che mostra il profilo utilizzato dal codificatore. In questo caso è stato utilizzato un profilo alto limitato (cioè un profilo alto senza supporto per il segmento B bidirezionale).

Se consultiamo la specifica del flusso di bit H.264 per l'SPS NAL, possiamo trovare molti valori per il nome del parametro, la categoria e la descrizione. Ad esempio, diamo un'occhiata ai campi pic_width_in_mbs_minus_1 e pic_height_in_map_units_minus_1.

Se eseguiamo alcune operazioni matematiche con i valori di questi campi, otteniamo la risoluzione. Possiamo rappresentare 1920 x 1080, usando pic_width_in_mbs_minus_1 con valore 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Ancora una volta, risparmiando spazio, invece di codificare 1920, lo abbiamo fatto con 119.

Se continuiamo a controllare il nostro video creato in formato binario (ad esempio: xxd -b -c 11 v/minimal_yuv420.h264), possiamo passare all'ultimo NAL, che è il fotogramma stesso.

Ecco i suoi primi 6 valori byte: 01100101 10001000 10000100 00000000 00100001 11111111. Poiché è noto che il primo byte indica il tipo di NAL, in questo caso (00101) è un frammento IDR (5), e possiamo quindi esaminare ulteriormente:

Utilizzando le informazioni della specifica, possiamo decodificare il tipo di frammento (slice_type) e il numero del fotogramma (frame_num) tra gli altri campi importanti.

Per ottenere i valori di alcuni campi (ue(v), me(v), se(v) oppure te(v), dobbiamo decodificare il frammento utilizzando un decodificatore speciale basato su codice esponenziale di Golomb. Questo metodo è molto efficace per codificare i valori delle variabili, soprattutto quando ci sono molti valori predefiniti.

Valori slice_type e frame_num di questo video sono 7 (frammento I) e 0 (primo fotogramma).

Il flusso di bit può essere considerato come un protocollo. Se desideri saperne di più sul flusso di bit, è utile fare riferimento alla specifica ITU H.264. Ecco un diagramma a blocchi che mostra dove si trovano i dati dell'immagine (YUV in forma compressa).

Puoi esplorare anche altri flussi di bit, come VP9, H.265 (HEVC) o persino il nostro nuovo miglior flusso di bit AV1. Sono tutti simili? No, ma comprendendo almeno uno di essi sarà molto più facile capire gli altri.

Vuoi provare? Esplora il flusso di bit H.264

Puoi generare un video a fotogramma singolo e utilizzare MediaInfo per esaminare il flusso di bit H.264. In effetti, nulla impedisce di dare anche un'occhiata al codice sorgente che analizza il flusso di bit H.264 (AVC).

Per la pratica, puoi utilizzare Intel Video Pro Analyzer (sembra che abbia già detto che il programma è a pagamento, ma c'è una versione di prova gratuita, limitata a 10 fotogrammi?).

Panoramica

È importante notare che molti codec moderni utilizzano lo stesso modello che abbiamo appena studiato. Dai, diamo un'occhiata al diagramma del codec video Thor. Contiene tutti i passaggi che abbiamo seguito. L'obiettivo di questa nota è che tu possa, almeno in parte, comprendere meglio le innovazioni e la documentazione in questo campo.

In precedenza, abbiamo calcolato che sarebbero necessari 139 GB di spazio su disco per memorizzare un file video di un'ora alla qualità 720p e 30 fps. Se utilizziamo i metodi esaminati in questo articolo (previsioni interframe e interne, trasformazione, quantizzazione, codifica entropica, ecc.), possiamo ottenere (assumendo che spendiamo 0,031 bit per pixel) un video di qualità soddisfacente che occupa solo 367,82 MB invece di 139 GB di memoria.

Come fa H.265 a raggiungere un migliore rapporto di compressione rispetto a H.264?

Ora che sappiamo di più su come funzionano i codec, è più facile capire come i nuovi codec possano fornire una risoluzione più alta con meno bit.

Se confrontiamo AVC e HEVC, è importante non dimenticare che si tratta quasi sempre di una scelta tra un maggiore carico sulla CPU e il livello di compressione.

HEVC ha più opzioni di divisioni (e suddivisioni) rispetto a AVC, più direzioni di previsione interna, codifica entropica migliorata e molto altro. Tutti questi miglioramenti hanno reso H.265 in grado di comprimere il 50% in più rispetto a H.264.

Prima parte: Fondamenti del lavoro con video e immagini

Fonte: habr.com