A prima parte:
Chi? Un codec video hè un pezzu di software / hardware chì compresses è / o decompresse u video digitale.
Perchè chì? Malgradu certe limitazioni sia in termini di larghezza di banda è
è in quantu à u spaziu di almacenamiento di dati, u mercatu esige un video di qualità sempre più altu. Ti ricordi cumu in l'ultimu post avemu calculatu u minimu necessariu per 30 frames per seconda, 24 bits per pixel, cù una risoluzione di 480x240? Avemu ricevutu 82,944 Mbit/s senza cumpressione. A cumpressione hè attualmente l'unicu modu per trasmette in generale HD / FullHD / 4K à i schermi di televisione è Internet. Cumu hè questu questu? Avà, fighjemu brevemente i metudi principali.
A traduzzione hè stata fatta cù u sustegnu di EDISON Software.Semu ingaghjati , cum'è ancu .
Codec vs Container
Un sbagliu cumuni chì i principianti facenu hè cunfundendu u codec di video digitale è u containeru di video digitale. Un containeru hè un certu furmatu. Un wrapper chì cuntene metadati video (è possibbilmente audio). U video cumpressu pò esse cunsideratu cum'è una carica di cuntainer.
Di genere, l'estensione di un schedariu video indica u so tipu di cuntainer. Per esempiu, u schedariu video.mp4 hè probabilmente un containeru MPEG-4 Part 14, è un schedariu chjamatu video.mkv hè più prubabile . Per esse completamente sicuru di u codec è u furmatu di u containeru, pudete aduprà o .
Un pocu di storia
Prima di ghjunghje Cumu?, Andemu un pocu in a storia per capisce un pocu di più vechji codecs.
Codec video H.261 apparsu in u 1990 (tecnicu - in u 1988) è hè statu creatu per uperà à una velocità di trasferimentu di dati di 64 Kbps. Hè digià utilizatu idee cum'è subsampling di culore, macroblocchi, etc. U standard di codec video hè statu publicatu in u 1995 H.263, chì hà sviluppatu finu à u 2001.
A prima versione hè stata cumpletata in u 2003 H.264 / AVC. Ddu stessu annu, TrueMotion hà liberatu u so codec video senza perdita chjamatu VP3. Google hà compru a cumpagnia in 2008, liberatu VP8 in u listessu annu. In dicembre 2012, Google hà liberatu VP9, è hè supportatu in circa ¾ di u mercatu di u navigatore (cumpresi i dispositi mobili).
AV1 hè un novu codec video gratuitu è open source sviluppatu da Alliance for Open Media (AOMedia), chì include e cumpagnie più famose, cum'è: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel è Cisco. A prima versione di u codec, 0.1.0, hè stata publicata u 7 d'aprile di u 2016.
Nascita di AV1
In principiu di 2015, Google hà travagliatu VP10Xiph (chì hè propiu di Mozilla) stava travagliatu Daala, è Cisco hà fattu u so propiu codec video gratuitu chjamatu Thor.
tandu MPEG LA i primi limiti annuali annunciati per HEVC (H.265) è una tarifa 8 volte più altu ch'è per H.264, ma prestu cambiatu e regule di novu:
senza limiti annuali,
tassa di cuntenutu (0,5% di i rivenuti) è
a tarifa unità hè di circa 10 volte più altu ch'è H.264.
Alliance for Open Media hè statu creatu da cumpagnie di diversi campi: fabricatori d'equipaggiu (Intel, AMD, ARM, Nvidia, Cisco), fornituri di cuntenutu (Google, Netflix, Amazon), creatori di navigatori (Google, Mozilla) è altri.
E cumpagnie avianu un scopu cumunu - un codec video senza royalty. Allora appare AV1 cù una licenza di patente assai più simplice. Timothy B. Terryberry hà datu una presentazione stupente chì diventò l'urìgine di u cuncettu AV1 attuale è u so mudellu di licenza.
Sarete sorpresu di sapè chì pudete analizà u codec AV1 attraversu un navigatore (quelli chì sò interessati ponu andà à).
Codec universale
Fighjemu i meccanismi principali sottumessi à u codec video universale. A maiò parte di sti cuncetti sò utili è sò usati in codecs muderni cum'è VP9, AV1 и HEVC. Vi avvistu chì assai di e cose spiegate seranu simplificate. A volte, esempii di u mondu reale (cum'è H.264) seranu utilizati per dimustrà a tecnulugia.
1u passu - splitting the image
U primu passu hè di dividisce u quadru in parechje rùbbriche, sottosezzioni è oltre.
Perchè? Ci sò parechje ragioni. Quandu dividemu una maghjina, pudemu predichendu più accuratamente u vettore di muvimentu usendu sezioni chjuche per e picculi parti in muvimentu. Mentre chì per un fondo staticu pudete limità à sezioni più grande.
I codecs urganizanu tipicamente queste sezioni in sezzioni (o pezzi), macroblocchi (o blocchi di l'arburu di codificazione) è parechje subsezzioni. A dimensione massima di queste partizioni varieghja, HEVC a mette in 64x64 mentre AVC usa 16x16, è i subpartizioni ponu esse divisi finu à 4x4.
Vi ricordate i tipi di frames da l'ultimu articulu ?! U listessu pò esse applicatu à i blocchi, cusì pudemu avè un frammentu I, un bloccu B, un macrobloccu P, etc.
Per quelli chì volenu praticà, fighjate cumu l'imaghjini hè divisu in sezzioni è sottosezzioni. Per fà questu, pudete aduprà quellu chì hè digià citatu in l'articulu precedente. (quellu chì hè pagatu, ma cù una versione di prova gratuita chì hè limitata à i primi 10 frames). Sezzioni analizate quì VP9:
2nd passu - previsione
Una volta avemu sezzioni, pudemu fà previsioni astrologiche per elli. Per Previsioni di INTER deve esse trasferitu vettori di muvimentu è u restu, è per a previsione INTRA hè trasmessa direzione di previsione è u restu.
3rd passu - trasfurmazioni
Una volta avemu un bloccu residuale (sezione prevista → sezione reale), hè pussibule di trasfurmà in tale manera chì sapemu chì pixelli ponu esse scartati mentre mantene a qualità generale. Ci sò qualchi trasfurmazioni chì furnisce u cumpurtamentu esatta.
Ancu s'ellu ci sò altri metudi, fighjemu in più in detail. Trasformazione discreta di cosenu (DCT - da Trasformazione discreta di cosenu). Funzioni principali di DCT:
- Cunverte blocchi di pixel in blocchi uguali di coefficienti di frequenza.
- Condensa u putere per aiutà à eliminà a redundanza spaziale.
- Fornisce a reversibilità.
2 di ferraghju di u 2017 Sintra R.J. (Cintra, RJ) è Bayer F.M. (Bayer FM) hà publicatu un articulu nantu à una trasfurmazioni DCT-like per a compressione di l'imaghjini chì esige solu 14 addizzioni.
Ùn vi preoccupate micca sè ùn avete micca capitu i benefici di ogni articulu. Avà usemu esempi specifichi per vede u so valore reale.
Pigliemu stu bloccu 8x8 di pixel:
Stu bloccu hè resu in l'imaghjini seguenti 8 per 8 pixel:
Applica DCT à stu bloccu di pixel è uttene un bloccu 8x8 di coefficienti:
È se rendemu stu bloccu di coefficienti, averemu a seguente maghjina:
Comu pudete vede, ùn s'assumiglia micca à l'imagine originale. Pudete vede chì u primu coefficient hè assai sfarente di tutti l'altri. Stu primu coefficient hè cunnisciutu cum'è u coefficient DC, chì rapprisenta tutti i campioni in l'array di input, qualcosa cum'è una media.
Stu bloccu di coefficienti hà una pruprietà interessante: separa i cumpunenti d'alta freccia da quelli di freccia bassa.
In una maghjina, a maiò parte di a putenza hè cuncentrata à frequenze più bassu, perchè si cunvertisce l'imaghjini in i so cumpunenti di freccia è scaccià i coefficienti di freccia più altu, pudete riduce a quantità di dati necessarii per descriverà l'imaghjini senza sacrificà a qualità di stampa troppu.
A frequenza si riferisce à quantu rapidamente cambia u signale.
Pruvemu d'applicà a cunniscenza acquistata in u casu di prova cunvertisce l'imaghjini uriginale à a so frequenza (bloccu di coefficienti) utilizendu DCT è dopu scartà una parte di i coefficienti menu impurtanti.
Prima avemu cunvertisce à u duminiu di freccia.
In seguitu, scartate una parte (67%) di i coefficienti, principarmenti a parte inferjuri destra.
Infine, ricustruemu l'imaghjini da stu bloccu scartatu di coefficienti (ricurdatevi, deve esse invertibile) è paragunate cù l'uriginale.
Avemu vistu chì s'assumiglia à l'imaghjini uriginale, ma ci sò parechje differenzi da l'uriginale. Avemu cacciatu u 67,1875% è avemu sempre qualcosa chì s'assumiglia à l'uriginale. Hè pussibule di scartà più pensativu i coefficienti per ottene una maghjina di qualità ancu megliu, ma questu hè un tema dopu.
Ogni coefficient hè generatu cù tutti i pixel
Impurtante: ogni coefficientu ùn hè micca direttamente mappatu à un pixel, ma hè una somma ponderata di tutti i pixel. Stu graficu maravigghiusu mostra cumu u primu è u sicondu coefficienti sò calculati utilizendu pesi unichi per ogni indice.
Pudete ancu pruvà à visualizà u DCT fighjendu una furmazione simplice di imaghjini basatu annantu à questu. Per esempiu, quì hè u simbulu A generatu cù ogni pesu di coefficient:
4th step - quantization
Dopu avè cacciatu qualchi coefficienti à u passu precedente, à l'ultimu passu (trasfurmazione) facemu una forma speciale di quantizazione. In questu stadiu hè accettatu per perde l'infurmazioni. O, più simplice, quantizeremu i coefficienti per ottene a compressione.
Cumu pò quantificà un bloccu di coefficienti? Unu di i metudi più sèmplice hè a quantizazione uniforme, quandu pigliamu un bloccu, dividite per un valore (per 10) è arrotonda u risultatu.
Pudemu inversà stu bloccu di coefficienti ? Iè, pudemu, multiplicà da u listessu valore da quale avemu divisu.
Stu approcciu ùn hè micca u megliu perchè ùn piglia micca in contu l'impurtanza di ogni coefficient. Puderia usà una matrice di quantificatori invece di un valore unicu, è sta matrice puderia sfruttà a pruprietà DCT quantizing a maiuranza di l'inferiore à diritta è a minurità di a parte superiore sinistra.
Passu 5 - codificazione entropia
Una volta avemu quantificatu i dati (blocchi d'imaghjini, frammenti, frames), pudemu ancu cumpressà senza perdita. Ci hè parechje modi algoritmichi per cumpressà e dati. Avemu da piglià un sguardu rapidu à alcuni di elli, per una cunniscenza più profonda pudete leghje u libru Comprensione di Cumpressione: Cumpressione di Dati per Sviluppatori Moderni ("").
Codifica video cù VLC
Diciamu chì avemu un flussu di caratteri: a, e, r и t. A probabilità (da 0 à 1) di quantu spessu ogni caratteru appare in un flussu hè presentata in questa tabella.
| a | e | r | t | |
|---|---|---|---|---|
| Probabilità | 0,3 | 0,3 | 0,2 | 0,2 |
Pudemu assignà codici binari unichi (preferibbilmente chjuchi) à i più probabili, è codici più grande à i menu prubabile.
| a | e | r | t | |
|---|---|---|---|---|
| Probabilità | 0,3 | 0,3 | 0,2 | 0,2 |
| codice binariu | 0 | 10 | 110 | 1110 |
Cumpressemu u flussu, assumendu chì finiscemu per passà 8 bits per ogni caratteru. Senza cumpressione, 24 bits seranu necessarii per caratteru. Se rimpiazzate ogni caratteru cù u so codice, avete un risparmiu!
U primu passu hè di codificà u caratteru e, chì hè uguali à 10, è u sicondu caratteru hè a, chì hè aghjuntu (micca in modu matematicu): [10][0], è infine u terzu caratteru t, chì rende u nostru bitstream finale cumpressu uguale à [10][0][1110] or 1001110, chì richiede solu 7 bits (3,4 volte menu spaziu di l'uriginale).
Per piacè nutate chì ogni codice deve esse un codice unicu cù un prefissu. vi aiuterà à truvà sti numeri. Ancu s'è stu metudu ùn hè micca senza i so difetti, ci sò codecs video chì offrenu ancu stu metudu algoritmicu per a compressione.
Tramindui l'encoder è u decoder deve avè accessu à una tabella di simboli cù i so codici binari. Dunque, hè ancu necessariu di mandà una tavola cum'è input.
Codificazione aritmetica
Diciamu chì avemu un flussu di caratteri: a, e, r, s и t, è a so probabilità hè presentata in sta tabella.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probabilità | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Utilizendu sta tabella, custruiremu intervalli chì cuntenenu tutti i caratteri pussibuli, ordinati da u più grande numeru.
Avà codificà un flussu di trè caratteri: manghjà.
Prima selezziunate u primu caratteru e, chì hè in u subrange da 0,3 à 0,6 (senza include). Pigliemu stu subrange è dividite dinò in i stessi proporzioni cum'è prima, ma per questa nova gamma.
Continuemu à codificà u nostru flussu manghjà. Avà pigliate u sicondu caratteru a, chì hè in u novu subrange da 0,3 à 0,39, è poi piglià u nostru ultimu caratteru t è ripitendu u listessu prucessu di novu, avemu a sub-range finale da 0,354 à 0,372.
Avemu bisognu di selezziunà un numeru in l'ultimu subrange da 0,354 à 0,372. Scegliemu 0,36 (ma pudete sceglie qualsiasi altru numeru in questu subrange). Solu cù stu numeru seremu capaci di restaurà u nostru flussu originale. Hè cum'è s'è no avemu tracciatu una linea in i intervalli per codificà u nostru flussu.
L'operazione inversa (vale à dì, decodificazione) hè cusì simplice: cù u nostru numeru 0,36 è u nostru intervallu iniziale, pudemu eseguisce u listessu prucessu. Ma avà, usendu stu numeru, identificemu u flussu codificatu cù stu numeru.
Cù u primu intervallu, avemu nutatu chì u nostru numeru currisponde à a fetta, dunque questu hè u nostru primu caratteru. Avà dividemu stu sub-range di novu da seguità u listessu prucessu cum'è prima. Quì pudete vede chì 0,36 currisponde à u simbulu a, è dopu avè ripetutu u prucessu avemu ghjuntu à l'ultimu caratteru t (formendu u nostru flussu codificatu originale manghjà).
Tramindui l'encoder è u decoder deve avè una tabella di probabilità di simbulu, per quessa, hè necessariu di mandà ancu in i dati di input.
Piuttostu elegante, ùn hè micca? Quellu chì hè venutu cù sta suluzione era dannatamente intelligente. Certi codecs video utilizanu sta tecnica (o almenu offrenu cum'è una opzione).
L'idea hè di cumpressà senza perdita un flussu di bit quantized. Surely stu articulu hè mancatu tunnellati di ditagli, mutivi, trade-off, etc. Ma sè site un sviluppatore, duvete sapè di più. Nuvelli codecs pruvate d'utilizà diversi algoritmi di codificazione di entropia cum'è ANS.
Passu 6 - furmatu bitstream
Dopu fattu tuttu questu, tuttu ciò chì resta hè di sbulicà i frames compressi in u cuntestu di i passi realizati. U decodificatore deve esse infurmatu esplicitamente di e decisioni prese da u codificatore. U decodificatore deve esse furnitu cù tutte l'infurmazioni necessarii: prufundità di bit, spaziu di culore, risoluzione, infurmazione di predizione (vettori di muvimentu, predizione INTER direzionale), prufilu, livellu, freccia di quadru, tipu di quadru, numeru di quadru è assai di più.
Fighjemu un rapidu sguardu à u bitstream H.264. U nostru primu passu hè di creà un bitstream H.264 minimu (FFmpeg per automaticamente aghjunghje tutte l'opzioni di codificazione cum'è SEI NAL - Scupreremu ciò chì hè un pocu più in là). Pudemu fà questu utilizendu u nostru propiu repository è FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Stu cumandimu generarà un bitstream crudu H.264 cù un quadru, risoluzione 64 × 64, cù spaziu di culore YUV420. In questu casu, l'imaghjini seguenti sò utilizati cum'è un quadru.
H.264 bitstream
Standard atr (H.264) determina chì l'infurmazioni seranu mandati in macroframes (in u sensu di a rete), chjamatu nal (questu hè un livellu di astrazione di a rete). U scopu principale di NAL hè di furnisce una presentazione video "web-friendly". Stu standard deve travaglià in TV (basatu in flussu), Internet (basatu in pacchetti).
Ci hè un marcatu di sincronizazione per definisce e fruntiere di elementi NAL. Ogni token di sincronia cuntene un valore 0x00 0x00 0x01, fora di u primu, chì hè uguali à 0x00 0x00 0x00 0x01. Si lanciamu hexdump per u bitstream H.264 generatu, identificemu almenu trè mudelli NAL à u principiu di u schedariu.
Cum'è dichjaratu, u decoder deve cunnosce micca solu i dati di l'imaghjini, ma ancu i dettagli di u video, u quadru, i culori, i paràmetri utilizati è assai più. U primu byte di ogni NAL definisce a so categuria è u tipu.
| identificatore di tipu NAL | discrizzione |
|---|---|
| 0 | Tipu scunnisciutu |
| 1 | Frammentu d'immagine codificata senza IDR |
| 2 | Sezione di dati di fetta codificata A |
| 3 | Sezione di dati di fetta codificata B |
| 4 | Sezione di dati di fetta codificata C |
| 5 | Frammentu IDR codificatu di una maghjina IDR |
| 6 | Più infurmazione nantu à l'estensione SEI |
| 7 | Set di parametri di sequenza SPS |
| 8 | Set di paràmetri di l'imagine PPS |
| 9 | Separatore di accessu |
| 10 | Fine di a sequenza |
| 11 | A fine di u filu |
| ... | ... |
Di genere, u primu NAL di un bitstream hè SPS. Stu tipu di NAL hè rispunsevuli di informà nantu à e variàbili di codificazione cumuni cum'è u prufilu, u livellu, a risoluzione, etc.
Se saltamu u primu marcatu di sincronia, pudemu decodificà u primu byte per sapè quale tipu NAL hè u primu.
Per esempiu, u primu byte dopu à u token di sincronia hè 01100111, induve u primu bit (0) hè in u campu forbidden_zero_bit. I prossimi 2 bit (11) ci dice u campu nal_ref_idc, chì indica se stu NAL hè un campu di riferimentu o micca. E i restanti 5 bits (00111) ci dice u campu nal_unit_type, in questu casu hè u bloccu SPS (7) NAL.
Second byte (binariu=01100100, hex=0x64, Dec=100) in SPS NAL hè u campu profile_idc, chì mostra u prufilu chì l'encoder hà utilizatu. In questu casu, hè stata utilizata un prufilu altu limitatu (vale à dì, un prufilu altu senza supportu di segmentu B bidirezionale).
Se guardate a specificazione di bitstream H.264 per SPS NAL, truveremu assai valori per u nome di u paràmetru, a categuria è a descrizzione. Per esempiu, fighjemu i campi pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Nome paràmetru | catigurìa | discrizzione |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue (v) |
| pic_height_in_map_units_minus_1 | 0 | ue (v) |
Sè eseguite alcune operazioni matematiche cù i valori di sti campi, uttene una risoluzione. Un pò rapprisintà 1920 x 1080 usendu pic_width_in_mbs_minus_1 cù un valore di 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). In novu, per risparmià spaziu, invece di codificà 1920, avemu fattu cù 119.
Se continuemu à verificà u nostru video creatu in forma binaria (per esempiu: xxd -b -c 11 v/minimal_yuv420.h264), allora pudete andà à l'ultimu NAL, chì hè u quadru stessu.
Quì vedemu i so primi valori di 6 byte: 01100101 10001000 10000100 00000000 00100001 11111111. Siccomu u primu byte hè cunnisciutu per indicà u tipu NAL, in questu casu (00101) hè un fragmentu IDR (5), è poi pudete scopre più:
Utilizendu l'infurmazioni di specificazione, serà pussibule decodificà u tipu di fragmentu (slice_type) è u numeru di quadru (frame_num) frà altri campi impurtanti.
Per piglià i valori di certi campi (ue(v), me(v), se(v) o te(v)), avemu bisognu di decodificà u frammentu utilizendu un decoder speciale basatu . Stu metudu hè assai efficace per codificà i valori variabili, soprattuttu quandu ci sò parechji valori predeterminati.
I valori slice_type и frame_num di stu video sò 7 (I-fragment) è 0 (primu quadru).
Un bitstream pò esse pensatu cum'è un protocolu. Se vulete sapè più nantu à u bitstream, duvete riferite à a specificazione ITU H.264. Eccu un diagramma macro chì mostra induve sò i dati di l'imaghjini (YUV in forma compressa).
Altri bitstreams ponu esse esaminati, cum'è VP9, H.265 (HEVC) o ancu u nostru novu megliu bitstream AV1. Sò tutti simili ? No, ma quandu avete capitu almenu unu, hè assai più faciule per capisce u restu.
Vulete praticà? Esplora u bitstream H.264
Pudete generà un video unicu quadru è aduprà MediaInfo per esaminà u bitstream H.264. In fatti, nunda ùn impedisce ancu di fighjà u codice fonte chì analizà u flussu di bit H.264 (atr).
Per a pratica, pudete aduprà Intel Video Pro Analyzer (aghju digià dettu chì u prugramma hè pagatu, ma ci hè una versione di prova gratuita cù un limitu di 10 frames ?).
riassuntu
Nota chì parechji codecs muderni utilizanu u listessu mudellu chì avemu studiatu. Eccu, fighjemu un ochju à u schema di bloccu di u codec video Thor. Contene tutti i passi chì avemu passatu. U puntu tutale di stu post hè di almenu dà un megliu capiscenu di l'innuvazioni è a documentazione in questa zona.
In precedenza, era calculatu chì 139 GB di spaziu di discu seranu necessarii per almacenà un schedariu video chì dura una ora in qualità 720p è 30 fps. Sè vo aduprate i metudi discututi in stu articulu (inter-frame è prediczioni internu, trasfurmazioni, quantization, codificazione entropia, etc.), allura pudete ottene (basatu nantu à u fattu chì avemu passatu 0,031 bits per pixel), un video di abbastanza qualità satisfacente, occupendu solu 367,82 MB, micca 139 GB di memoria.
Cumu H.265 ottene un rapportu di compressione megliu cà H.264?
Avà chì sapemu di più nantu à u funziunamentu di i codecs, hè più faciule per capisce cumu i codec più recenti ponu furnisce risoluzioni più altu cù menu bit.
Se paragunate atr и HEVC, vale a pena ricurdà chì questu hè quasi sempre una scelta trà una carica di CPU più grande è u rapportu di compressione.
HEVC hà più opzioni di sezione (è sottosezione) chè atr, più direzzione di prediczione interna, codificazione di entropia mejorata, è più. Tutte queste migliure sò state fatte H.265 capaci di cumpressione 50% di più cà H.264.
A prima parte:
Source: www.habr.com