La prima parte:
Che cosa? Un codec video è un componente software/hardware che comprime e/o decomprime il video digitale.
Per che cosa? Nonostante alcune limitazioni sia in termini di larghezza di banda che
e in termini di spazio di archiviazione dei dati, il mercato richiede video di qualità sempre più elevata. Ricordi come nell'ultimo post abbiamo calcolato il minimo richiesto per 30 fotogrammi al secondo, 24 bit per pixel, con una risoluzione di 480x240? Abbiamo ricevuto 82,944 Mbit/s senza compressione. La compressione è attualmente l'unico modo per trasmettere generalmente HD/FullHD/4K sugli schermi televisivi e su Internet. Come si ottiene questo risultato? Vediamo ora brevemente i metodi principali.
La traduzione è stata realizzata con il supporto di EDISON Software.Siamo impegnati in e .
Codec contro contenitore
Un errore comune commesso dai neofiti è confondere il codec video digitale e il contenitore video digitale. Un contenitore è un determinato formato. Un wrapper contenente metadati video (e possibilmente audio). Il video compresso può essere pensato come un carico utile di un contenitore.
In genere, l'estensione di un file video indica il tipo di contenitore. Ad esempio, il file video.mp4 è probabilmente un contenitore MPEG-4 Parte 14e molto probabilmente è un file denominato video.mkv . Per essere completamente sicuri del codec e del formato contenitore, è possibile utilizzare o .
Un po 'di storia
Prima di arrivare a Come?, facciamo un piccolo tuffo nella storia per comprendere un po' meglio alcuni codec più vecchi.
Video codec H.261 è apparso nel 1990 (tecnicamente - nel 1988) ed è stato creato per funzionare ad una velocità di trasferimento dati di 64 Kbps. Utilizzava già idee come il sottocampionamento del colore, i macroblocchi, ecc. Lo standard del codec video è stato pubblicato nel 1995 H.263, che si è sviluppato fino al 2001.
La prima versione è stata completata nel 2003 H.264 / AVC. Nello stesso anno, TrueMotion ha rilasciato il suo codec video con perdita di dati gratuito chiamato VP3. Google ha acquistato l'azienda nel 2008, rilasciandola VP8 lo stesso anno. Nel dicembre 2012, Google ha rilasciato VP9ed è supportato in circa ¾ del mercato dei browser (compresi i dispositivi mobili).
AV1 è un nuovo codec video gratuito e open source sviluppato da Alleanza per i media aperti (AO Media), che comprende le aziende più famose, 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.
Nascita di AV1
All'inizio del 2015, Google stava lavorando VP10Xiph (di proprietà di Mozilla) stava lavorando Daalae Cisco ha creato il proprio codec video gratuito chiamato Thor.
Poi MPEG LA primi limiti annuali annunciati per HEVC (H.265) e una tariffa 8 volte superiore a quella dell'H.264, ma presto cambiarono nuovamente le regole:
nessun limite annuale,
tariffa sui contenuti (0,5% delle entrate) e
la tariffa unitaria è circa 10 volte superiore a H.264.
Alleanza per i media aperti è stato creato da aziende di diversi settori: produttori di apparecchiature (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 esente da royalty. Quindi appare AV1 con una licenza di brevetto molto più semplice. Timothy B. Terryberry ha tenuto una presentazione straordinaria che è diventata l'origine dell'attuale concetto AV1 e del suo modello di licenza.
Rimarrai sorpreso di sapere che puoi analizzare il codec AV1 tramite un browser (chi è interessato può andare su).
Codec universale
Diamo un'occhiata ai principali meccanismi alla base del codec video universale. La maggior parte di questi concetti sono utili e vengono utilizzati nei codec moderni come VP9, AV1 и HEVC. Ti avviso che molte delle cose spiegate verranno semplificate. A volte verranno utilizzati esempi del mondo reale (come con H.264) per dimostrare le tecnologie.
1° passo: dividere l'immagine
Il primo passo è dividere il frame in più sezioni, sottosezioni e oltre.
Per quello? Ci sono molte ragioni. Quando dividiamo un'immagine, possiamo prevedere con maggiore precisione il vettore di movimento utilizzando piccole sezioni per piccole parti mobili. Mentre per uno sfondo statico potete limitarvi a sezioni più grandi.
I codec in genere organizzano queste sezioni in sezioni (o blocchi), macroblocchi (o blocchi dell'albero di codifica) e più sottosezioni. La dimensione massima di queste partizioni varia, HEVC la imposta su 64x64 mentre AVC utilizza 16x16 e le sottopartizioni possono essere suddivise fino a dimensioni 4x4.
Vi ricordate le tipologie di montature dello scorso articolo?! Lo stesso può essere applicato ai blocchi, quindi possiamo avere un frammento I, un blocco B, un macroblocco P, ecc.
Per chi vuole esercitarsi, guarda come l'immagine è divisa in sezioni e sottosezioni. Per fare ciò potete utilizzare quello già citato nell’articolo precedente. (quello a pagamento, ma con una versione di prova gratuita limitata ai primi 10 fotogrammi). Sezioni qui analizzate VP9:
2° passo: previsione
Una volta che abbiamo le sezioni, possiamo fare previsioni astrologiche per esse. Per Previsioni Inter deve essere trasferito vettori di movimento e il resto, e per le previsioni INTRA viene trasmesso direzione della previsione e il resto.
3° passo: trasformazione
Una volta ottenuto un blocco residuo (sezione prevista → sezione reale), è possibile trasformarlo in modo tale da sapere quali pixel possono essere scartati mantenendo la qualità complessiva. Esistono alcune trasformazioni che forniscono il comportamento esatto.
Sebbene esistano altri metodi, esaminiamoli più in dettaglio. trasformata discreta del coseno (DCT - da trasformata discreta di coseno). Principali funzioni del DCT:
- Converte blocchi di pixel in blocchi di coefficienti di frequenza di uguali dimensioni.
- Condensa la potenza per contribuire a eliminare la ridondanza spaziale.
- Fornisce reversibilità.
2 febbraio 2017 Sintra R.J. (Cintra, RJ) e Bayer F.M. (Bayer FM) ha pubblicato un articolo su una trasformazione simile alla DCT per la compressione delle immagini che richiede solo 14 aggiunte.
Non preoccuparti se non comprendi i vantaggi di ciascun articolo. Ora utilizziamo esempi specifici per vedere il loro reale valore.
Prendiamo questo blocco di pixel 8x8:
Questo blocco viene visualizzato nella seguente immagine da 8 x 8 pixel:
Applica DCT a questo blocco di pixel e ottieni un blocco di coefficienti 8x8:
E se rendiamo questo blocco di coefficienti, otterremo la seguente immagine:
Come puoi vedere, non assomiglia all'immagine originale. Puoi vedere che il primo coefficiente è molto diverso da tutti gli altri. Questo primo coefficiente è noto come coefficiente DC, che rappresenta tutti i campioni nell'array di input, qualcosa come una media.
Questo blocco di coefficienti ha una proprietà interessante: separa le componenti ad alta frequenza da quelle a bassa frequenza.
In un'immagine, la maggior parte della potenza è concentrata alle frequenze più basse, quindi se converti l'immagine nelle sue componenti di frequenza e scarti i coefficienti di frequenza più alti, puoi ridurre la quantità di dati necessari per descrivere l'immagine senza sacrificare troppo la qualità dell'immagine.
La frequenza si riferisce alla velocità con cui il segnale cambia.
Proviamo ad applicare le conoscenze acquisite nel caso test convertendo l'immagine originale alla sua frequenza (blocco di coefficienti) utilizzando DCT e quindi scartando parte dei coefficienti meno importanti.
Per prima cosa lo convertiamo nel dominio della frequenza.
Successivamente, scartiamo parte (67%) dei coefficienti, principalmente la parte in basso a destra.
Infine, ricostruiamo l'immagine da questo blocco di coefficienti scartato (ricorda, deve essere invertibile) e confrontala con l'originale.
Vediamo che assomiglia all'immagine originale, ma ci sono molte differenze rispetto all'originale. Abbiamo buttato via il 67,1875% e abbiamo comunque ottenuto qualcosa che somigliava all'originale. Era possibile eliminare i coefficienti in modo più accurato per ottenere un'immagine di qualità ancora migliore, ma questo è un argomento successivo.
Ciascun coefficiente viene generato utilizzando tutti i pixel
Importante: ciascun coefficiente non è direttamente mappato su un pixel, ma è una somma ponderata di tutti i pixel. Questo straordinario grafico mostra come vengono calcolati il primo e il secondo coefficiente utilizzando pesi unici per ciascun indice.
Puoi anche provare a visualizzare il DCT osservando una semplice formazione di immagini basata su di esso. Ad esempio, ecco il simbolo A generato utilizzando ciascun coefficiente di peso:
4° passo: quantizzazione
Dopo aver eliminato alcuni coefficienti nel passaggio precedente, nell'ultimo passaggio (trasformazione) eseguiamo una forma speciale di quantizzazione. In questa fase è accettabile perdere informazioni. O, più semplicemente, quantizzeremo i coefficienti per ottenere la compressione.
Come si può quantizzare un blocco di coefficienti? Uno dei metodi più semplici è la quantizzazione uniforme, quando prendiamo un blocco, lo dividiamo per un valore (per 10) e arrotondiamo il risultato.
Possiamo invertire questo blocco di coefficienti? Sì, possiamo, moltiplicando per lo stesso valore per cui abbiamo diviso.
Questo approccio non è il migliore perché non tiene conto dell’importanza di ciascun coefficiente. Si potrebbe usare una matrice di quantizzatori invece di un singolo valore, e questa matrice potrebbe sfruttare la proprietà DCT quantizzando la maggioranza della parte in basso a destra e la minoranza della parte in alto a sinistra.
Passaggio 5: codifica entropica
Una volta quantizzati i dati (blocchi di immagine, frammenti, fotogrammi), possiamo ancora comprimerli senza perdite. Esistono molti modi algoritmici per comprimere i dati. Daremo una rapida occhiata ad alcuni di essi, per una comprensione più approfondita puoi leggere il libro Understanding Compression: Data Compression for Modern Developers ("").
Codifica video utilizzando VLC
Diciamo che abbiamo un flusso di personaggi: a, e, r и t. In questa tabella viene presentata la probabilità (compreso tra 0 e 1) della frequenza con cui ogni carattere appare in uno stream.
| a | e | r | t | |
|---|---|---|---|---|
| probabilità | 0,3 | 0,3 | 0,2 | 0,2 |
Possiamo assegnare codici binari univoci (preferibilmente piccoli) a quelli più probabili e codici più grandi a quelli meno probabili.
| a | e | r | t | |
|---|---|---|---|---|
| probabilità | 0,3 | 0,3 | 0,2 | 0,2 |
| Codice binario | 0 | 10 | 110 | 1110 |
Comprimiamo lo stream, partendo dal presupposto che alla fine spenderemo 8 bit per ogni carattere. Senza compressione sarebbero necessari 24 bit per carattere. Se sostituisci ogni carattere con il suo codice, ottieni un risparmio!
Il primo passo è codificare il carattere e, che è uguale a 10, e il secondo carattere è a, a cui viene aggiunto (non in modo matematico): [10][0], ed infine il terzo carattere t, che rende il nostro bitstream compresso finale uguale a [10][0][1110] o 1001110, che richiede solo 7 bit (3,4 volte meno spazio dell'originale).
Tieni presente che ogni codice deve essere un codice univoco con un prefisso. ti aiuterà a trovare questi numeri. Sebbene questo metodo non sia esente da difetti, esistono codec video che offrono ancora questo metodo algoritmico per la compressione.
Sia l'encoder che il decoder devono avere accesso ad una tabella di simboli con i loro codici binari. Pertanto è necessario inviare anche una tabella come input.
Codifica aritmetica
Diciamo che abbiamo un flusso di personaggi: a, e, r, s и te la loro probabilità è presentata in questa tabella.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| probabilità | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Utilizzando questa tabella, creeremo intervalli contenenti tutti i caratteri possibili, ordinati in base al numero più grande.
Ora codifichiamo uno stream di tre caratteri: mangiare.
Selezionare innanzitutto il primo carattere e, che è nel sottointervallo da 0,3 a 0,6 (escluso). Prendiamo questo sottointervallo e lo dividiamo nuovamente nelle stesse proporzioni di prima, ma per questo nuovo intervallo.
Continuiamo a codificare il nostro stream mangiare. Ora prendi il secondo carattere a, che si trova nel nuovo sottointervallo compreso tra 0,3 e 0,39, quindi prendiamo il nostro ultimo carattere t e ripetendo nuovamente lo stesso processo, otteniamo il sottointervallo finale da 0,354 a 0,372.
Dobbiamo solo selezionare un numero nell'ultimo sottointervallo compreso tra 0,354 e 0,372. Scegliamo 0,36 (ma puoi scegliere qualsiasi altro numero in questo sottointervallo). Solo con questo numero potremo ripristinare il nostro stream originale. È come se stessimo tracciando una linea all'interno degli intervalli per codificare il nostro flusso.
L’operazione inversa (ovvero decodifica) è altrettanto semplice: con il nostro numero 0,36 e il nostro intervallo iniziale, possiamo eseguire lo stesso processo. Ma ora, utilizzando questo numero, identifichiamo il flusso codificato utilizzando questo numero.
Con il primo intervallo notiamo che il nostro numero corrisponde alla fetta, quindi questo è il nostro primo carattere. Ora dividiamo nuovamente questo sottointervallo seguendo lo stesso procedimento di prima. Qui puoi vedere che 0,36 corrisponde al simbolo a, e dopo aver ripetuto il procedimento siamo arrivati all'ultimo carattere t (formando il nostro flusso codificato originale mangiare).
Sia il codificatore che il decodificatore devono avere una tabella delle probabilità dei simboli, quindi è necessario inviarla anche nei dati di input.
Abbastanza elegante, non è vero? Chiunque abbia trovato questa soluzione è stato dannatamente intelligente. Alcuni codec video utilizzano questa tecnica (o almeno la offrono come opzione).
L'idea è di comprimere senza perdita di dati un flusso di bit quantizzato. Sicuramente in questo articolo mancano tantissimi dettagli, ragioni, compromessi, ecc. Ma se sei uno sviluppatore, dovresti saperne di più. I nuovi codec tentano di utilizzare diversi algoritmi di codifica entropica come ANNI.
Passaggio 6: formato bitstream
Dopo aver fatto tutto ciò, non resta che decomprimere i frame compressi nel contesto dei passaggi eseguiti. Il decoder deve essere esplicitamente informato delle decisioni prese dal codificatore. È necessario fornire al decoder tutte le informazioni necessarie: profondità di bit, spazio colore, risoluzione, informazioni di previsione (vettori di movimento, previsione INTER direzionale), profilo, livello, frame rate, tipo di frame, numero di frame e molto altro.
Daremo una rapida occhiata al bitstream H.264. Il nostro primo passo è creare un bitstream H.264 minimo (FFmpeg per impostazione predefinita aggiunge tutte le opzioni di codifica come SEI NAL – scopriremo di cosa si tratta un po’ più avanti). Possiamo farlo utilizzando il nostro repository e FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Questo comando genererà un bitstream non elaborato H.264 con un fotogramma, risoluzione 64×64, con spazio colore YUV420. In questo caso, l'immagine seguente viene utilizzata come cornice.
Flusso di bit H.264
Standard AVC (H.264) determina che le informazioni verranno inviate in macroframe (nel senso di rete), detti NAL (questo è un livello di astrazione di rete). L'obiettivo principale di NAL è fornire una presentazione video "web-friendly". Questo standard dovrebbe funzionare su TV (basato su streaming), Internet (basato su pacchetti).
C'è un marcatore di sincronizzazione per definire i confini degli elementi NAL. Ogni token di sincronizzazione contiene un valore 0x00 0x00 0x01, tranne il primo, che è uguale a 0x00 0x00 0x00 0x01. Se lanciamo dump esadecimale per il bitstream H.264 generato, identifichiamo almeno tre pattern NAL all'inizio del file.
Come detto, il decoder deve conoscere non solo i dati dell'immagine, ma anche i dettagli del video, l'inquadratura, i colori, i parametri utilizzati e molto altro. Il primo byte di ciascun NAL ne definisce la categoria e il tipo.
| Identificatore del tipo NAL | descrizione |
|---|---|
| 0 | Tipologia |
| 1 | Frammento di immagine codificato senza IDR |
| 2 | Sezione dati sezione codificata A |
| 3 | Sezione dati sezione codificata B |
| 4 | Sezione dati sezione codificata C |
| 5 | Frammento IDR codificato di un'immagine IDR |
| 6 | Maggiori informazioni sull'estensione SEI |
| 7 | Set di parametri della sequenza SPS |
| 8 | Insieme di parametri dell'immagine PPS |
| 9 | Separatore di accesso |
| 10 | Fine della sequenza |
| 11 | Fine del filo |
| ... | ... |
In genere il primo NAL di un bitstream è SPS. Questo tipo di NAL è responsabile di informare sulle variabili di codifica comuni come profilo, livello, risoluzione, ecc.
Se saltiamo il primo marcatore di sincronizzazione, possiamo decodificare il primo byte per scoprire quale tipo NAL è il primo.
Ad esempio, il primo byte dopo il token di sincronizzazione è 01100111, dove il primo bit (0) è nel campo forbitden_zero_bit. Prossimi 2 bit (11) ci dice il campo nal_ref_idc, che indica se questo NAL è un campo di riferimento oppure no. E i restanti 5 bit (00111) ci dice il campo tipo_unità_nale, in questo caso si tratta del blocco SPS (7) NAL.
Secondo byte (binario=01100100, hex=0x64, dicembre=100) in SPS NAL è il campo profilo_idc, che mostra il profilo utilizzato dall'encoder. In questo caso è stato utilizzato un profilo alto limitato (cioè un profilo alto senza supporto bidirezionale del segmento B).
Se guardi le specifiche del bitstream H.264 per SPS NAL troveremo molti valori per nome parametro, categoria e descrizione. Consideriamo ad esempio i campi pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Nome parametro | categoria | descrizione |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Se eseguiamo alcune operazioni matematiche con i valori di questi campi, otterremo la risoluzione. È possibile rappresentare 1920 x 1080 utilizzando pic_width_in_mbs_minus_1 con un valore di 119 ((119 + 1) * dimensione_macroblocco = 120 * 16 = 1920). Ancora una volta, per risparmiare 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), quindi puoi andare all'ultimo NAL, che è il frame stesso.
Qui vediamo i suoi primi 6 valori byte: 01100101 10001000 10000100 00000000 00100001 11111111. Poiché è noto che il primo byte indica il tipo NAL, in questo caso (00101) è un frammento IDR (5), quindi puoi esplorarlo ulteriormente:
Utilizzando le informazioni sulle specifiche, sarà possibile decodificare il tipo di frammento (tipo_fetta) e il numero di telaio (numero_fotogramma) tra gli altri campi importanti.
Per ottenere i valori di alcuni campi (ue(v), me(v), se(v) o te(v)), dobbiamo decodificare il frammento utilizzando un decodificatore speciale basato su . Questo metodo è molto efficiente per codificare i valori delle variabili, soprattutto quando sono presenti molti valori predefiniti.
senso tipo_fetta и numero_fotogramma di questo video sono 7 (frammento I) e 0 (primo fotogramma).
Un flusso di bit può essere pensato come un protocollo. Se vuoi saperne di più sul bitstream, dovresti fare riferimento alle specifiche ITU H.264. Di seguito è riportato un diagramma macro che mostra dove si trovano i dati dell'immagine (YUV in forma compressa).
È possibile esaminare altri flussi di bit, ad esempio VP9, H.265 (HEVC) o anche il nostro nuovo miglior bitstream AV1. Sono tutti simili? No, ma una volta che ne capisci almeno uno, è molto più facile capire il resto.
Vuoi esercitarti? Esplora il bitstream H.264
Puoi generare un video a fotogramma singolo e utilizzare MediaInfo per esaminare il flusso di bit H.264. In effetti, nulla ti impedisce anche solo di guardare il codice sorgente che analizza il flusso di bit H.264 (AVC).
Per fare pratica puoi utilizzare Intel Video Pro Analyser (ho già detto che il programma è a pagamento, ma esiste una versione di prova gratuita con limite di 10 fotogrammi?).
panoramica
Tieni presente che molti codec moderni utilizzano lo stesso modello che abbiamo appena studiato. Qui diamo un'occhiata allo schema a blocchi del codec video Thor. Contiene tutti i passaggi che abbiamo seguito. Lo scopo centrale di questo post è almeno darti una migliore comprensione delle innovazioni e della documentazione in quest'area.
Precedentemente era stato calcolato che sarebbero stati necessari 139 GB di spazio su disco per archiviare un file video della durata di un'ora con qualità 720p e 30 fps. Se utilizzi i metodi discussi in questo articolo (previsioni inter-frame e interne, trasformazione, quantizzazione, codifica entropica, ecc.), puoi ottenere (in base al fatto che spendiamo 0,031 bit per pixel) video di qualità abbastanza soddisfacente , occupando solo 367,82 MB, non 139 GB di memoria.
In che modo H.265 ottiene un rapporto di compressione migliore rispetto a H.264?
Ora che sappiamo di più su come funzionano i codec, è più facile capire come i codec più recenti possano fornire risoluzioni più elevate con meno bit.
Se confronti AVC и HEVC, vale la pena ricordare che si tratta quasi sempre di una scelta tra un maggiore carico della CPU e un maggiore rapporto di compressione.
HEVC ha più opzioni di sezione (e sottosezione) di AVC, più direzioni di previsione interna, migliore codifica entropica e altro ancora. Tutti questi miglioramenti sono stati apportati H.265 capace di comprimere il 50% in più rispetto a H.264.
La prima parte:
Fonte: habr.com