Compresia H.

265/HEVC
Encoderul software de referință – HM

Organizația care reglementează/standardizează noile tehnologii în industrie și implicit în domeniul

comunicațiilor și al sistemelor de codare/decodare video, ITU, a propus odată cu dezvoltarea recomandării
Rec. ITU-T H.265 și un software considerat ”de referință”, pentru a oferi un model de encoder și decoder
video care respectă întocmai prevederile standardului H.265. Recomandarea ” H.265 : High Efficiency
video coding” impune doar sintaxa fluxului video comprimat și decodorul, lasând liberă realizarea
encoderului (similar H.264, recomandarea anterioară). Encoderul are în continuare incorporat un decoder.

Figura 1. Schema bloc a unui codec H.265/HEVC.

Prin flux video comprimat (”bitstream”) se înțelege o secvență binară a cărei sintaxă corespunde
Rec. ITU-T H.265, conține unul sau mai multe cadre de tip intra, precum și cadre de tip P și B. HM permite
codarea video conform unui set extins de profile, principalul profil folosit în această lucrare fiind Main10.
Semnalul video sursă se consideră în format YCbCr sau YUV cu eșantionare 4:2:0, astfel: Y
reprezintă canalul de luminanță, iar U și V sunt canale de crominanță cu înălțime și lățime înjumătățite față
de luminanță. Predicția în H.265 este bazată de asemenea pe blocuri denumite unități de codare sau CUs
(Coding Units) care pot avea însă mai multe dimensiuni posibile, începând cu 64x64 pixeli și până la 8x8
pixeli. În figura 2 se pot observa demarcate cu albastru unitățile de codare, iar cu roșu unitățile de
transformare sau TUs (Transform Units). TU poate varia de la 4x4 pixeli până la 32x32 pixeli. Arborii se
parcurg în ordinea specificată de valorile asociate fiecărui CU / TU.

Figura 2. CTB (coding tree block) partiționat în CU (linie albastră) și TU (linie roșie).

În HEVC sunt permise slice-uri de tip I, P sau B. Structurile GOP sunt: IPPPPPPP, IBBBBBBB
sau IBBPBBP. Un cadru video HEVC este împărțit în CTBs de dimensiuni 64x64, 32x32 or 16x16. Un
CTB are asociat un arbore CTU (coding tree unit) pentru fiecare componentă Y,U,V. Unitățile de codare
CU din HEVC pot avea dimensiunile 64x64, 32x32, 16x16 sau 8x8. Blocurile CU din CTB sunt parcurse
în ordine Z. Blocurile TU de aplicare a transformatei pentru codarea texturii reziduale pot fi de 4x4, 8x8,
16x16 sau 32x32 pixeli.

1.
a. Se va studia setul de parametri din fișierul de configurare „encoder_intra_main.cfg”. Descrieți tipul de
codare așa cum este aceasta prefigurată de valorile parametrilor din fișierul de configurare (secvență,
rezoluție, factor de cuantizare, structura GOP, etc.).
b. Se va lansa aplicația TAppEncoder.exe pentru a obține un flux video comprimat. Deschideți o fereastră
de Command Prompt (de la butonul de Start al sistemului de operare Windows, în fereastra de search se
va căuta cmd). Se va seta directorul curent cel care conține binarul și fișierul de configurare, de exemplu:
cd:\\_work\desktop\HM\bin apoi se va executa: TAppEncoder.exe -c config.cfg
c. Folosind aplicația Elecard StreamEye, să se analizeze fluxul video comprimat. Sunt codate cadrele
integral sau există mai multe slice-uri într-un cadru? Ce dimensiuni minime/maxime au blocurile CU și TU
efectiv codate? Se vor urmări setările din meniu Overlays – Partitions pentru aceasta.
d. Din secțiunea Stream a aplicației Elecard StreamEye, să se precizeze operațiile care ocupă procentual
cel mai mare număr de biți în fluxul video comprimat.
e. Pentru un arbore cuaternar CTU precum cel din figura de mai jos se cere să se precizeze ordinea de
parcurgere a blocurilor CU (marcate cu linie continuă) / TU (marcate cu linie întreruptă). Să se figureze
structura arborilor cuaternari. Ce tip de textură se poate observa în Elecard ca fiind asociată unor CU de
dimensiuni mari (32x32 pixeli sau 64x64 pixeli)? Dar unor CU de dimensiuni mici?

2.
a. Se va studia setul de parametri din fișierul de configurare „encoder_lowdelay_main.cfg”. Descrieți tipul
de codare așa cum este aceasta prefigurată de valorile parametrilor din fișierul de configurare (secvență,
rezoluție, factor de cuantizare, structura GOP, etc.).
b. Câte cadre de referință sunt folosite în procesul de predicție al cadrelor P? câte referințe sunt maxim
permise de standardul H.265?
c. Reluați semnificația parametrului ”SearchRange” în cadrul schemei de estimare/compensare a mișcării.
Cum influențează acest parametru timpul global de codare? Se vor compara algoritmii de compensare a
mișcării FullSearch și TZSearch (Test Zone Search este o combinație între algoritmii de căutare de tip raster
și cel în formă de diamant).
d. Realizați o comparație între cadrele I și B din fluxul binar comprimat, din punct de vedere al numărului
de biți per cadru, al factorului de cuantizare folosit la I și la B, precum și al calității video (PSNR).

3.
a. Se va studia setul de parametri din fișierul de configurare „encoder_lowdelay_P_main.cfg”. Descrieți
tipul de codare așa cum este aceasta prefigurată de valorile parametrilor din fișierul de configurare
(secvență, rezoluție, factor de cuantizare, structura GOP, etc.).
b. Pentru o secvență de rezoluție mică precum ORIG_TM_352x288.yuv există diferențe mari între fluxurile
comprimate cu secvența IBBB și apoi IPPP ? Se vor păstra aceiași factori de cuantizare la ambele encodări.
Dar dacă se codează o secvență de rezoluție 1920x1080 cu encoder_lowdelay_main.cfg și apoi
encoder_lowdelay_P_main.cfg ? Ce tip de codare inter aduce un câștig mai mare și în ce condiții?

4.
Se vor construi 2 grafice de tip Bjontegaard în care ordonata reprezintă valoarea PSNR și abscisa
este dată de bitrate (Total Bitrate) și se vor figura împreună pe aceeași pereche de axe. Un asemenea grafic
permite evaluarea calității video simultan cu cea a eficienței compresiei. Concret, curba se va obține din 4
puncte ce corespund unui factor de cuantizare pentru cadrele I și P de: QP={ 10, 20, 30, 40} . Secvența
video sursă se va alege de rezoluție minim VGA și se vor encoda minim 3 cadre. Pentru cele– 2 seturi de
codări se vor alege corespunzător parametrii din secțiunea Unit definition din
encoder_lowdelay_P_main.cfg astfel încât să se pornească de la CU / TU de dimensiune maximă (la primul
grafic Bjontegaard) și să se ajungă la aproximativ minimul permis de standard pentru dimensiunea CU (la
al doilea grafic Bjontegaard), modificând corespunzător și dimensiunea TU.
Ce concluzie se poate trage din aceste două seturi de simulări: există o dimensiune optimă de
CU/TU?