Pjesa e parë:
ĂfarĂ«? Kodeku i videos Ă«shtĂ« njĂ« pjesĂ« e softuerit/aparatit qĂ« comprimon dhe/ose deshifron videot digjitale.
PĂ«r çfarĂ«? PavarĂ«sisht nga disa kufizime si nĂ« bandwidth ashtu edhe nĂ« hapĂ«sirĂ«n e ruajtjes, tregu kĂ«rkon video me cilĂ«si gjithnjĂ« e mĂ« tĂ« lartĂ«. A e mban mend se si nĂ« postimin e kaluar ne llogaritĂ«m minimumin e nevojshĂ«m pĂ«r 30 korniza nĂ« sekondĂ«, 24 bita pĂ«r piksel, me rezolucion prej 480Ă240? Kemi arritur 82,944 Mbit/s pa comprimim. Comprimi Ă«shtĂ« ende mĂ«nyra e vetme pĂ«r tĂ« transmetuar HD/FullHD/4K nĂ« ekranet televizive dhe nĂ« Internet. Si arrijmĂ« nĂ« kĂ«tĂ«? Tani le tĂ« shqyrtojmĂ« shkurtimisht metodat kryesore.
Ne jemi të angazhuar në
Përkthimi është bërë me mbështetje nga kompania EDISON Software.integrimin e sistemeve të mbikëqyrjes video , dhe gjithashtu .
Një gabim i zakonshëm i fillestarëve është të ngatërrojnë kodekun e videos digjitale dhe kontejnerin e videos digjitale. Kontejneri është një format, një mbështjellje që përmban metadatat e videos (dhe, ndoshta, audio). Videot e comprimuara mund të merren si ngarkesë e kontejnerit.
Oblikimi i zakonshëm i skedarit të videos tregon për llojin e tij të kontejnerit. Për shembull, skedari video.mp4 është me shumë mundësi një kontejner
MPEG-4 Pjesa 14 , ndërsa skedari me emrin video.mkv është, më shumë se të gjitha,një matryoshka Para se të kalojmë tek ose .
Pak histori
, le të shohim pak histori për të kuptuar më mirë disa kodekë të vjetër. Si?H.261
Kodeku i videos u shfaq nĂ« vitin 1990 (teknikisht â nĂ« 1988) dhe u krijua pĂ«r tĂ« punuar me njĂ« shpejtĂ«si transmetimi prej 64 Kbit/s. Ai pĂ«rfshinte tashmĂ« ide si sub-sample-ngjyra, makrobloket dhe tĂ« tjera. NĂ« vitin 1995 u publikua standardi i kodekut tĂ« videos H.263 , i cili u zhvillua deri nĂ« vitin 2001.NĂ« vitin 2003 u pĂ«rfundua versioni i parĂ«
H.264/AVC . NĂ« tĂ« njĂ«jtin vit kompania "TrueMotion" lĂ«shoi kodekun e saj pa pagesĂ«, qĂ« comprimonte videot me humbje dhe quhejVP3 . NĂ« vitin 2008 Google bleu kĂ«tĂ« kompani, duke lĂ«shuarVP8 nĂ« tĂ« njĂ«jtin vit. NĂ« dhjetor 2012 Google lĂ«shoi , dhe ai mbĂ«shtetet nga afĂ«rsisht Ÿ e tregut tĂ« shfletuesve (pĂ«rfshirĂ« pajisjet mobile). VP9â Ă«shtĂ« njĂ« kodek i ri video pa pagesĂ« me burim tĂ« hapur, i zhvilluar
AV1 nga Aleanca për Mediat e Hapura ), përfshirë kompani të njohura si: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel dhe Cisco. Versioni i parë i kodekut 0.1.0 u publikua më 7 prill 2016. (AOMediaLindja e AV1
Në fillim të vitit 2015 Google punoi mbi
VP10 , Xiph (i përket Mozilla) punoi mbiDaala , dhe Cisco bëri kodekun e saj video pa pagesë që quhejThor MPEG LA.
Pastaj fillimisht shpalli kufij vjetorë për HEVC H.265 () dhe tarifën, e cila ishte 8 herë më e lartë se H.264, por shpejt ata ndryshuan rregullat:pa kufij vjetorë,
tarifë për përmbajtjen (0.5% e të ardhurave) dhe
taksa për përmbajtjen (0.5% e të ardhurave) dhe
kostoja për njësi produkte është afërsisht 10 herë më e lartë se për H.264.
Aleanca për media të hapura u krijua nga kompani nga fusha të ndryshme: prodhues të pajisjeve (Intel, AMD, ARM, Nvidia, Cisco), furnizues të përmbajtjes (Google, Netflix, Amazon), krijues të shfletuesve (Google, Mozilla) dhe të tjerë.
KĂ«to kompani kishin njĂ« qĂ«llim tĂ« pĂ«rbashkĂ«t â njĂ« kodek video pa pagesa licencash. MĂ« pas shfaqet AV1 me njĂ« licencĂ« patentimi shumĂ« mĂ« tĂ« thjeshtĂ«. Timothy B. Terriberry bĂ«ri njĂ« prezantim tĂ« jashtĂ«zakonshĂ«m, i cili shĂ«rbeu si burim pĂ«r konceptin aktual tĂ« AV1 dhe modelin e saj tĂ« licencĂ«s.
Do të befasoheni kur të mësoni se mund të analizoni kodekun AV1 përmes shfletuesit (ata që janë të interesuar mund të vizitojnë).
Kodek universalisht
Le të shqyrtojmë mekanizmat kryesorë që qëndrojnë pas kodekut universalisht. Shumica e këtyre koncepteve janë të dobishme dhe përdoren në kodekët modernë, të tillë si VP9, AV1 dhe H.265. Të paralajmëroj se shumë nga gjërat që do të shpjegohen do të thjeshtohen. Ndonjëherë do të përdoren shembuj realë (si në rastin e H.264) për të demonstruar teknologjitë.
Hapi 1 â ndarja e imazhit
Hapi i parë është ndarja e kadrave në disa seksione, nënseksione dhe më tej.
Pse? Ka shumë arsye. Kur e ndajmë pamjen, mund të parashikojmë më saktë vektorin e lëvizjes, duke përdorur seksione të vogla për pjesë të vogla në lëvizje. Ndërsa për sfondin statik, mund të mjaftohemi me seksione më të mëdha.
Zakonisht kodekĂ«t organizojnĂ« kĂ«to seksione nĂ« seksione (ose fragmente), makroblloqe (ose blloqe tĂ« pemĂ«s sĂ« kodimit) dhe shumĂ« nĂ«nseksione. MadhĂ«sia maksimale e kĂ«tyre seksioneve ndryshon; HEVC vendos 64Ă64, ndĂ«rsa AVC pĂ«rdor 16Ă16, dhe nĂ«nseksionet mund tĂ« ndahen deri nĂ« madhĂ«sinĂ« 4Ă4.
A e mbani mend llojet e kadrave nga artikulli i kaluar?! Kjo mund të aplikohet edhe për blloqet, kështu që mund të kemi bllok I, bllok B, makrobllok P, etj.
PĂ«r ata qĂ« dĂ«shirojnĂ« tĂ« praktikojnĂ« â shikoni se si imazhi ndahet nĂ« seksione dhe nĂ«nseksione. PĂ«r kĂ«tĂ«, mund tĂ« pĂ«rdorni instrumentin qĂ« pĂ«rmenden nĂ« artikullin e kaluar (ai qĂ« Ă«shtĂ« me pagesĂ«, por me njĂ« version provues falas, i cili ka njĂ« kufizim pĂ«r 10 kadrin e parĂ«). KĂ«tu analizohen seksionet VP9:
Hapi 2 â parashikimi
Sa herë që kemi seksi, mund të bëjmë parashikime astrologjike mbi to. Për parashikimin INTER duhet të dërgojmë vektorët e lëvizjes dhe mbetjen, ndërsa për parashikimin INTRA dërgohet drejtimi i parashikimit dhe mbetja.
Hapi 3 â transformimi
Pas marrjes sĂ« bllokut mbetje (seksioni i parashikuar â seksioni real), mund tĂ« transformohet nĂ« njĂ« mĂ«nyrĂ« qĂ« tĂ« dimĂ« se cilat piksele mund tĂ« hiqen, duke ruajtur gjithashtu cilĂ«sinĂ« e pĂ«rgjithshme. Ka disa transformime qĂ« sigurojnĂ« njĂ« sjellje tĂ« saktĂ«.
Megjithëse ka edhe metoda të tjera, le të shqyrtojmë më në detaje transformimi diskret i kosinusit (DCT Display Aspect Ratio transformimi diskret i kosinusit). Funksionet kryesore të DCT:
- Konverton blloqet e pikselëve në blloqe të barabarta të koeficientëve të frekuencës.
- Kompakton fuqinë, duke ndihmuar në eliminimin e tepërsisë hapësinore.
- Siguron reversibilitet.
Më 2 shkurt 2017, Cintra R.J. dhe Bayer F.M. publikuan një artikull rreth transformimit të ngjashëm me DCT për kompresimin e imazheve, duke kërkuar vetëm 14 shtesa.
Mos u shqetësoni nëse nuk e kuptoni përfitimet e secilit pikë. Tani do të konfirmojmë vlerën e tyre reale me shembuj konkretë.
Le tĂ« marrim njĂ« bllok pikselĂ«sh 8Ă8:
Ky bllok renderohet në imazhin e mëposhtëm 8 me 8 pikselë:
AplikojmĂ« DCT nĂ« kĂ«tĂ« bllok pikselĂ«sh dhe marrim njĂ« bllok koeficientĂ«sh me madhĂ«si 8Ă8:
Dhe nëse e renderojmë këtë bllok koeficientësh, do të marrim një imazh të tillë:
Siç e shohim, kjo nuk duket si imazhi origjinal. Mund të vërehet se koeficienti i parë ndan të gjithë të tjerët. Ky koeficient i parë është i njohur si koeficienti DC, që përfaqëson të gjitha mostrat në masivin hyrës, diçka e ngjashme me mesataren.
Ky bllok koeficientësh ka një pronë interesante: ndan komponentët me frekuencë të lartë nga ata me frekuencë të ulët.
Në imazh, shumica e fuqisë është e përqendruar në frekuenca më të ulëta, kështu që, nëse e konvertojmë imazhin në komponentët e tij të frekuencës dhe heqim koeficientët me frekuencë më të lartë, mund të reduktojmë sasinë e të dhënave të nevojshme për të përshkruar imazhin, pa sakrifikuar shumë cilësinë e fotos.
Frekuenca nënkupton se sa shpejt ndryshon sinjali.
Le të përpiqemi të aplikojmë njohuritë e marra në shembullin testues, duke transformuar imazhin origjinal në frekuencën e tij (bllok koeficientësh), duke përdorur DCT, dhe pastaj heqim një pjesë të koeficientëve më pak të rëndësishëm.
Së pari, e konvertojmë atë në fushën e frekuencës.
Pastaj heqim një pjesë (67%) të koeficientëve, kryesisht pjesën e poshtme të djathtë.
Së fundmi, rikthejmë imazhin nga ky bllok koeficientësh të hequr (mbahteni mend, duhet të jetë reversibël) dhe e krahasojmë me origjinalin.
Shohim se ajo i ngjan imazhit origjinal, por ka shumë ndryshime nga origjinali. Ne hodhëm 67,1875% dhe ende morëm diçka që i ngjan burimit. Mund të ishim hequr më me strategji koeficientët për të marrë një imazh me cilësi akoma më të mirë, por ajo është një temë tjetër.
Ădo koeficient formohet duke pĂ«rdorur tĂ« gjithĂ« pikselĂ«t
à rëndësishme: çdo koeficient nuk shfaqet drejtpërdrejt në një piksel, por përfaqëson një shumë të peshkuar të të gjithë pikseve. Ky diagram i mrekullueshëm tregon si llogaritet koeficienti i parë dhe i dytë duke përdorur peshat, të cilat janë unike për çdo indeks.
Ju gjithashtu mund të përpiqeni të vizualizoni DCT-në, duke parë formimin e thjeshtë të imazhit mbi të. Për shembull, ja simboli A, i formuar duke përdorur secilin peshë koeficienti:
Hapi 4 - kuantizimi
Pasi në hapin e mëparshëm heqim disa koeficientë, në hapin e fundit (transformimi), realizojmë një formë të veçantë kuantizimi. Në këtë fazë është e pranueshme të humbasim informacion. Ose, më thjesht, do të kuantizojmë koeficientët për të arritur kompresimin.
Si mund të kuantizojmë një bllok koeficientësh? Një nga metodat më të thjeshta do të ishte kuantizimi uniform, ku marrim një bllok, e ndajmë atë në një vlerë (në 10) dhe e rrumbullakojmë atë që kemi marrë.
A mund ta kthejmë këtë bllok koeficientësh? Po, mundemi, duke e shumëzuar me të njëjtin vlerë me të cilën e ndajmë.
Ky qasje nuk është më e mira, pasi nuk merr parasysh rëndësinë e secilit koeficient. Do të ishte e mundur të përdornim një matricë kuantizuesish në vend të një vlerë, dhe kjo matricë mund të përdorë pronësinë e DCT, duke kuantizuar shumicën e të poshtme të djathtës dhe pak të sipërm të majtës.
Hapi 5 - kodimi i entropisë
Pasi kemi kuantizuar të dhënat (blloqe imazhesh, fragmente, kadrin), mund të kompresojmë ato ende pa humbje. Ka shumë mënyra algoritmike për kompresimin e të dhënave. Ne do të prezantojmë shkurtimisht disa prej tyre, për një kuptim më të thellë mund të lexoni librin "Të Kuptojmë Kompresionin: Kompresimi i të Dhënave për Zhvilluesit Modernë"»).
Kodimi i videos me VLC
Imagjinoni se kemi një rrjedhë simboresh: a, e, r dhe t. Probabiliteti (në intervalin nga 0 në 1) i sa shpesh paraqitet çdo simbol në rrjedhë tregohet në këtë tabelë.
| a | e | r | t | |
|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,2 | 0,2 |
Mund të caktojmë kode unike binarë (preferohet të jenë të vogla) për ata më të mundshëm, ndersa kode më të mëdha për ata më pak të mundshëm.
| a | e | r | t | |
|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,2 | 0,2 |
| Kodi binar | 0 | 10 | 110 | 1110 |
Kompresojmë rrjedhën, duke supozuar se në fund do të shpenzojmë 8 bit për çdo simbol. Pa kompresim çdo simbol do të duhej 24 bite. Nëse çdo simbol e zëvendësojmë me kodin e tij, atëherë rezulton një kursim!
Hapi i parë përfshin kodimin e simboleve e, që është 10, dhe simbolet e dyta janë a, që shtohet (në mënyrë jo matematikore): [10] [0], dhe, përfundimisht, simboli i tretë t, që bën që rrjedha jonë përfundimtare e kompresuar e bitëve të jetë [10] [0] [1110] ose 1001110, për të cilën nevojitet vetëm 7 bite (3.4 herë më pak hapësirë se origjinali).
Kujdesi, çdo kod duhet të jetë një kod unik me një prefiks. do të ndihmojë në gjetjen e këtyre numrave. Megjithëse kjo metodë nuk është pa mangësi, ekzistojnë kodekë video që ende e ofrojnë këtë metodë algoritmike për kompresim.
Si koduesi ashtu edhe dekoduesi duhet të kenë akses në tabelën e simboleve me kodet e tyre binarë. Prandaj, është gjithashtu e nevojshme të dërgoni si të dhëna hyrëse tabelën.
Kodinimi aritmetik
Imagjinoni se kemi një rrjedhë simboresh: a, e, r, s dhe t, dhe probabiliteti i tyre është paraqitur nga kjo tabelë.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Me këtë tabelë do të ndërtojmë intervale që përmbajnë të gjithë simbolet e mundshme, të renditura sipas numrit më të madh.
Tani le të kodojmë një rrjedhë prej tre simbolesh: eat.
Së pari, zgjidhim simbolin e parë e, i cili ndodhet në nënintervalin nga 0,3 deri në 0,6 (pa përfshirë). E marrim këtë nëninterval dhe e ndajmë përsëri në proporcione të njëjta si më parë, por tashmë për këtë interval të ri.
Le të vazhdojmë të kodojmë rrjedhën tonë eat. Tani marrim simbolin e dytë a, i cili ndodhet në nënintervalin e ri nga 0,3 deri në 0,39, dhe pastaj marrim simbolin tonë të fundit t dhe, duke përsëritur të njëjtin proces përsëri, marrim nënintervalin e fundit nga 0,354 deri në 0,372.
Na nevojitet thjesht tĂ« zgjedhim njĂ« numĂ«r nĂ« nĂ«nintervalin e fundit nga 0,354 deri nĂ« 0,372. Le tĂ« zgjedhim 0,36 (por mund tĂ« zgjedhim çdo numĂ«r tjetĂ«r nĂ« kĂ«tĂ« nĂ«ninterval). VetĂ«m me kĂ«tĂ« numĂ«r mund ta rikthejmĂ« rrjedhĂ«n tonĂ« origjinale. ĂshtĂ« si tĂ« vizatojmĂ« njĂ« vijĂ« brenda intervaleve pĂ«r kodimin e rrjedhĂ«s tonĂ«.
Operacioni i kundërt (dmth, dekodimi) është po aq i thjeshtë: me numrin tonë 0,36 dhe intervalin tonë fillestar mund të fillojmë të njëjtin proces. Por tani, duke përdorur këtë numër, zbulojmë rrjedhën e koduar në këtë numër.
Me intervalin e parë vërejmë se numri ynë përputhet me prerjen, pra, ky është simboli ynë i parë. Tani përsëri ndajmë këtë nëninterval duke bërë të njëjtin proces si më parë. Këtu mund të vërejmë se 0,36 përputhet me simbolin a, dhe pas përsëritjes së procesit arritëm në simbolin e fundit t (duke formuar rrjedhën tonë origjinale të koduar. eat).
Si për koduesin ashtu edhe për dekoduesin duhet të jetë e pranishme tabela e probabiliteteve të simboleve, prandaj është e nevojshme të dërgoni atë në të dhënat hyrëse.
Mjaft elegant, apo jo? Disa njerëz që e shpikën këtë zgjidhje ishin të jashtëzakonshëm. Disa kodekë video përdorin këtë teknikë (ose, përndryshe, e ofrojnë atë si opsion).
Ideja është të kompresosh pa humbje një rrjedhë bitësh të kuantizuar. Sigurisht, ky artikull mungon shumë detaje, arsye, kompromis, etj. Por ju, nëse jeni zhvillues, duhet të dini më shumë. Kodekët e rinj përpiqen të përdorin algoritme të ndryshme të kodimit të entropisë, siç është ANS.
HAPI 6 - formati i rrjedhës së bitëve
Pas të keni bërë të gjitha këto, mbetet të shkarkoni kadrot e kompresuara në kontekstin e hapave të kryer. Duhet ta njoftoni qartë dekoduesin për vendimet e marra nga koduesi. Dekoduesi duhet të ketë të gjitha informacionet e nevojshme: thellësia e bitit, hapësira e ngjyrave, rezolucioni, informacion mbi parashikimet (vektorët e lëvizjes, parashikimi i drejtuar INTER), profili, niveli, frekuenca e kornizës, lloji i kornizës, numri i kornizës dhe shumë më tepër.
Ne do tĂ« njohim shkurtimisht rrjedhĂ«n e bitĂ«ve. H.264. Hapi ynĂ« i parĂ« Ă«shtĂ« krijimi i njĂ« rrjedhe minimale tĂ« bitĂ«ve H.264 (FFmpeg nĂ« mĂ«nyrĂ« tĂ« parazgjedhur shton tĂ« gjitha parametrat e kodimit, si p.sh. SEI NAL â do tĂ« mĂ«sojmĂ« pĂ«r kĂ«tĂ« mĂ« vonĂ«). Mund ta bĂ«jmĂ« kĂ«tĂ«, duke pĂ«rdorur depozitĂ«n tonĂ« dhe FFmpeg.
.\/s\/ffmpeg -i \/files\/i\/minimal.png -pix_fmt yuv420p \/files\/v\/minimal_yuv420.h264
Ky komandĂ« do tĂ« gjenerojĂ« njĂ« rrjedhĂ« tĂ« papĂ«rpunuar bitĂ«sh H.264 me njĂ« kornizĂ«, rezolucion 64Ă64, me hapĂ«sirĂ« ngjyre YUV420. SĂ« bashku me kĂ«tĂ«, pĂ«rdoret si kornizĂ« imazhi i mĂ«poshtĂ«m.
Rrjedha e bitëve H.264
Standardi AVC (H.264) përcakton se informacioni do të dërgohet në makrokorniza (në kuptimin e rrjetit), të quajtura NAL (ky është një nivel abstraksioni i rrjetit). Qëllimi kryesor i NAL është të ofrojë një përfaqësim "miqësor me rrjetin" të videos. Ky standard duhet të funksionojë në televizione (në bazë të rrjedhave), në Internet (në bazë të pakove).
Ekziston njĂ« shenjĂ« sinkronizimi pĂ«r tĂ« pĂ«rcaktuar kufijtĂ« e elementĂ«ve NAL. Ădo shenjĂ« sinkronizimi pĂ«rmban njĂ« vlerĂ« 0x00 0x00 0x01, pĂ«rveç atij tĂ« parĂ«, i cili Ă«shtĂ« 0x00 0x00 0x00 0x01. NĂ«se ekzekutojmĂ« hexdump pĂ«r rrjedhĂ«n e gjeneruar tĂ« bitĂ«ve H.264, do tĂ« identifikojmĂ« tĂ« paktĂ«n tri modele NAL nĂ« fillim tĂ« skedarit.
Siç u tha, dekoduesi duhet të dijë jo vetëm të dhënat e imazhit, por edhe detajet e videos, kornizës, ngjyrës, parametrat e përdorur dhe shumë më tepër. Byte i parë i çdo NAL përcakton kategorinë dhe llojin e tij.
| Identifikuesi i tipit NAL | PĂ«rshkrimi |
|---|---|
| 0 | Lloj i panjohur |
| 1 | Fragmen i koduar i imazhit pa IDR |
| 2 | Një pjesë e koduar e të dhënave të prerjes A |
| 3 | Një pjesë e koduar e të dhënave të prerjes B |
| 4 | Një pjesë e koduar e të dhënave të prerjes C |
| 5 | Fragment i koduar i imazhit IDR |
| 6 | Informacione shtesë mbi zgjerimin SEI |
| 7 | Grupi i parametrave SPS të sekuencës |
| 8 | Grupi i parametrave PPS të imazhit |
| 9 | Separatori i qasjes |
| 10 | Fund i sekuencës |
| 11 | Fund i rrjedhës |
| ⊠| ⊠|
Zakonisht NAL i parë i rrjedhës së bitëve është SPS. Ky tip NAL përgjigjet për informacionin mbi variablat e përgjithshëm të kodimit, si profili, niveli, rezolucioni dhe të tjera.
Nëse kalojmë shenjën e parë të sinkronizimit, mund të dekodojmë byte të parë për të mësuar se cili tip NAL është i pari.
Për shembull, byte i parë pas shenjës së sinkronizimit është 01100111, ku biti i parë (0) ndodhet në fushën forbidden_zero_bit. Dy bitet e ardhshëm (11) na informojnë për fushën nal_ref_idc, që tregon nëse ky NAL është një fushë referencë apo jo. Dhe 5 bitët e tjerë (00111) na informojnë për fushën nal_unit_type, në këtë rast është blloku SPS (7) NAL.
Bytes i dytë (binary=01100100, hex=0x64, dec=100) në SPS NAL - kjo është një fushë profile_idc, që tregon profilin që përdori koduesi. Në këtë rast, u përdor një profil i lartë i kufizuar (dmth, një profil i lartë pa mbështetje për segmentin B me dy drejtim).
Nëse shqyrtojmë specifikimin e rrjedhës së bitëve H.264 për SPS NAL, do të zbulojmë shumë vlera për emrin e parametrave, kategorinë dhe përshkrimin. Për shembull, le të shikojmë fushat pic_width_in_mbs_minus_1 dhe pic_height_in_map_units_minus_1.
| Emri i parametrave | Kategoria | PĂ«rshkrimi |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Nëse kryejmë disa operacione matematikore me vlerat e këtyre fushave, ne do të marrim rezolucionin. Mund të paraqesim 1920 x 1080, duke përdorur pic_width_in_mbs_minus_1 me vlerën 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Përsëri, duke kursyer hapësirë, në vend që të kodojmë 1920 e bëmë këtë me 119.
Nëse vazhdoni të kontrolloni videon tonë të krijuar në formë binare (p.sh.: xxd -b -c 11 v/minimal_yuv420.h264), mund të kaloni në NAL-in e fundit, që është vetë korniza.
Këtu shohim vlerat e tij të para 6 byte-ve: 01100101 10001000 10000100 00000000 00100001 11111111. Duke qenë se dihet se byte i parë tregon tipin NAL, në këtë rast (00101) është segmenti IDR (5), dhe atëherë mund të hulumtojmë më tej këtë:
Duke përdorur informacionin e specifikimit, do të jetë e mundur të dekodojmë tipin e segmentit (slice_type) dhe numrin e kornizave (frame_num) mes fushave të tjera të rëndësishme.
Për të marrë vlerat e disa fushave (ue(v), me(v), se(v) ose te(v), na duhen të dekodojmë segmentin, duke përdorur një dekoder të veçantë të bazuar në Ky metodë është shumë efikase për kodimin e vlerave të variablave, veçanërisht kur ka shumë vlera në standard.
Vlerat slice_type dhe frame_num këtë video është 7 (I-segment) dhe 0 (korniza e parë).
Rrjedha e bitëve mund të shihet si një protokoll. Nëse dëshironi të dini më shumë për rrjedhën e bitëve, është mirë të referoheni në specifikimin ITU H.264.Këtu është diagrami që tregon se ku ndodhen të dhënat e imazhit (YUV në formë të kompresuar).
Mund të shqyrtojmë edhe rrjedha të tjera bitësh, si VP9, ) dhe tarifën, e cila ishte 8 herë më e lartë se H.264, por shpejt ata ndryshuan rregullat: (H.265) ose madje edhe rrjedhën tonë më të mirë të re AV1. A janë të gjitha ato të ngjashme? Jo, por duke kuptuar të paktën një - është shumë më e lehtë të kuptosh të tjerat.
Doni të praktikoni? Hulumtoni rrjedhën e bitëve H.264.
Mund të gjeneroni një video me një kornizë dhe të përdorni MediaInfo për të hulumtuar rrjedhën e bitëve. H.264Në fakt, asgjë nuk e ndalon as të shikoni kodin burimor që analizon rrjedhën e bitëve. H.264 (AVC).
Për praktikë mund të përdorni Intel Video Pro Analyzer (më duket se kam përmendur se programi është me pagesë, por ka një version provues falas, me kufi në 10 korniza?).
PĂ«rmbledhje
Vlen të theksohet se shumë kodekët modernë përdorin të njëjtën model që sapo studiuam. Ja, le të shikojmë skemën e koduesit të videove. MPEG LAAjo përmban të gjitha hapat që kemi ndjekur. Kuptimi i kësaj shënimi është që ju, të paktën, të kuptoni më mirë inovacionet dhe dokumentacionin në këtë fushë.
Më parë kemi llogaritur se do të nevojiteshin 139 GB hapësirë disku për të ruajtur një skedar video me gjatësi një orë në cilësinë 720p dhe 30 fps. Nëse përdoren metodat që u diskutuan në këtë artikull (parashikimet midis kadrove dhe të brendshme, transformimi, kuantizimi, kodimi i entropisë, etj.), mund të arrihet (duke u bazuar në shpenzimin e 0,031 bit për piksel), një video me cilësi të kënaqshme që zë vetëm 367.82 MB, në vend të 139 GB memories.
Si arrin H.265 një shkallë më të mirë kompresimi se H.264?
Tani, me më shumë njohuri rreth mënyrës se si punojnë kodet, është më e lehtë të kuptohet se si kodekët e rinj janë në gjendje të ofrojnë një rezolutë më të lartë me më pak bite.
Nëse krahasojmë AVC dhe H.265, është e rëndësishme të mos harrojmë se ky është pothuajse gjithmonë një zgjedhje midis ngarkesës më të madhe në CPU dhe shkallës së kompresimit.
H.265 ka më shumë mundësi seksionesh (dhe nënseksionesh) se AVC, më shumë drejtime parashikimi të brendshëm, kodim i përmirësuar i entropisë dhe shumë të tjera. Të gjitha këto përmirësime bënë ) dhe tarifën, e cila ishte 8 herë më e lartë se H.264, por shpejt ata ndryshuan rregullat: të aftë të comprimojë 50% më shumë se H.264.
Pjesa e parë:
Burimi: habr.com
