Pjesa e parë:
Çfarë? Një kodek video është një pjesë e softuerit/hardware që ngjesh dhe/ose dekompreson videon dixhitale.
Per cfare Pavarësisht kufizimeve të caktuara si në aspektin e gjerësisë së brezit ashtu edhe
dhe për sa i përket hapësirës së ruajtjes së të dhënave, tregu kërkon video me cilësi gjithnjë e më të lartë. A ju kujtohet se si në postimin e fundit kemi llogaritur minimumin e kërkuar për 30 korniza në sekondë, 24 bit për pixel, me një rezolucion 480x240? Ne morëm 82,944 Mbit/s pa kompresim. Kompresimi është aktualisht mënyra e vetme për të transmetuar në përgjithësi HD/FullHD/4K në ekranet televizive dhe në internet. Si arrihet kjo? Tani le të shohim shkurtimisht metodat kryesore.
Përkthimi është bërë me mbështetjen e EDISON Software.Ne jemi të angazhuar në Dhe .
Codec kundër kontejnerit
Një gabim i zakonshëm që bëjnë fillestarët është ngatërrimi i kodekut dixhital të videos dhe kontejnerit të videos dixhitale. Një enë është një format i caktuar. Një mbështjellës që përmban të dhëna meta të videos (dhe ndoshta audio). Videoja e ngjeshur mund të mendohet si një ngarkesë kontejneri.
Në mënyrë tipike, zgjerimi i një skedari video tregon llojin e kontejnerit të tij. Për shembull, skedari video.mp4 është ndoshta një kontejner MPEG-4 Pjesa 14, dhe ka shumë të ngjarë një skedar me emrin video.mkv . Për të qenë plotësisht i sigurt për kodekun dhe formatin e kontejnerit, mund të përdorni ose .
Pak histori
Para se të arrijmë në Si?, le të zhytemi pak në histori për të kuptuar pak më mirë disa kodekë më të vjetër.
Kodeku i videos H.261 u shfaq në 1990 (teknikisht - në 1988) dhe u krijua për të funksionuar me një shpejtësi të transferimit të të dhënave prej 64 Kbps. Ajo tashmë përdori ide të tilla si nën-kampionimi me ngjyra, makroblloqet, etj. Standardi i kodikut të videove u botua në 1995 H.263, e cila u zhvillua deri në vitin 2001.
Versioni i parë u përfundua në 2003 H.264 / AVC. Në të njëjtin vit, TrueMotion lëshoi kodekun e tij falas të videos me humbje të quajtur VP3. Google bleu kompaninë në vitin 2008, duke e lëshuar VP8 të njëjtin vit. Në dhjetor 2012, Google u lëshua VP9, dhe mbështetet në rreth ¾ e tregut të shfletuesit (përfshirë pajisjet celulare).
AV1 është një kodek i ri video pa pagesë dhe me burim të hapur i zhvilluar nga Aleanca për Media të Hapur (AOMedia), ku përfshihen kompanitë më të njohura, si: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel dhe Cisco. Versioni i parë i kodikut, 0.1.0, u publikua më 7 Prill 2016.
Lindja e AV1
Në fillim të vitit 2015, Google po punonte VP10Xiph (e cila është në pronësi të Mozilla) ishte duke punuar në Daala, dhe Cisco bëri kodekun e vet falas të videove të quajtur Thor.
Pastaj MPEG LA Kufijtë vjetorë të shpallur për herë të parë për HEVC (H.265) dhe një tarifë 8 herë më e lartë se për H.264, por shpejt ndryshuan rregullat përsëri:
pa kufi vjetor,
tarifa e përmbajtjes (0,5% e të ardhurave) dhe
tarifa për njësi është rreth 10 herë më e lartë se H.264.
Aleanca për Media të Hapur është krijuar nga kompani nga fusha të ndryshme: prodhuesit e pajisjeve (Intel, AMD, ARM, Nvidia, Cisco), ofruesit e përmbajtjes (Google, Netflix, Amazon), krijuesit e shfletuesve (Google, Mozilla) dhe të tjerë.
Kompanitë kishin një qëllim të përbashkët - një kodek video pa pagesë. Pastaj shfaqet AV1 me një licencë patentimi shumë më të thjeshtë. Timothy B. Terryberry dha një prezantim mahnitës që u bë origjina e konceptit aktual AV1 dhe modelit të tij të licencimit.
Do të habiteni kur të dini se mund të analizoni kodekun AV1 përmes një shfletuesi (të interesuarit mund të shkojnë te).
Kodeku universal
Le të shohim mekanizmat kryesorë që qëndrojnë në themel të kodekut universal të videos. Shumica e këtyre koncepteve janë të dobishme dhe përdoren në kodekët modernë si p.sh VP9, AV1 и HEVC. Ju paralajmëroj se shumë nga gjërat e shpjeguara do të thjeshtohen. Ndonjëherë shembuj të botës reale (si me H.264) do të përdoren për të demonstruar teknologjitë.
Hapi i parë - ndarja e imazhit
Hapi i parë është ndarja e kornizës në disa seksione, nënseksione dhe më gjerë.
Per cfare? Ka shumë arsye. Kur ndajmë një imazh, ne mund të parashikojmë më saktë vektorin e lëvizjes duke përdorur seksione të vogla për pjesë të vogla lëvizëse. Ndërsa për një sfond statik mund të kufizoheni në seksione më të mëdha.
Kodekët zakonisht i organizojnë këto seksione në seksione (ose copa), makroblloqe (ose blloqe pemësh koduese) dhe nënseksione të shumta. Madhësia maksimale e këtyre ndarjeve ndryshon, HEVC e vendos atë në 64x64 ndërsa AVC përdor 16x16 dhe nënndarjet mund të ndahen deri në madhësi 4x4.
Ju kujtohen llojet e kornizave nga artikulli i fundit?! E njëjta gjë mund të zbatohet për blloqet, kështu që mund të kemi një fragment I, një bllok B, një makrobllok P, etj.
Për ata që duan të praktikojnë, shikoni se si imazhi ndahet në seksione dhe nënseksione. Për ta bërë këtë, mund të përdorni atë të përmendur tashmë në artikullin e mëparshëm. (ai që paguhet, por me një version provë falas që është i kufizuar në 10 kornizat e para). Seksionet e analizuara këtu VP9:
Hapi i dytë - parashikimi
Pasi të kemi seksione, ne mund të bëjmë parashikime astrologjike për to. Për Parashikimet e INTER-it duhet të transferohen vektorët e lëvizjes dhe pjesa e mbetur, dhe për parashikimin INTRA transmetohet drejtimi i parashikimit dhe pjesa e mbetur.
Hapi i tretë - transformimi
Pasi të kemi një bllok të mbetur (seksioni i parashikuar → seksion real), është e mundur ta transformojmë atë në atë mënyrë që të dimë se cilët piksel mund të hidhen duke ruajtur cilësinë e përgjithshme. Ka disa transformime që ofrojnë sjelljen e saktë.
Edhe pse ka metoda të tjera, le t'i shohim ato në mënyrë më të detajuar. transformimi kosinus diskret (DCT - nga transformimi kosinus diskret). Funksionet kryesore të DCT:
- Shndërron blloqe pikselësh në blloqe me madhësi të barabartë të koeficientëve të frekuencës.
- Kondenson fuqinë për të ndihmuar në eliminimin e tepricës hapësinore.
- Ofron kthyeshmëri.
2 shkurt 2017 Sintra R.J. (Cintra, RJ) dhe Bayer F.M. (Bayer FM) publikoi një artikull në lidhje me një transformim të ngjashëm me DCT për kompresimin e imazhit që kërkon vetëm 14 shtesa.
Mos u shqetësoni nëse nuk i kuptoni përfitimet e secilit artikull. Tani le të përdorim shembuj specifik për të parë vlerën e tyre reale.
Le të marrim këtë bllok pikselësh 8x8:
Ky bllok jepet në imazhin e mëposhtëm 8 me 8 pixel:
Aplikoni DCT në këtë bllok pikselësh dhe merrni një bllok koeficientësh 8x8:
Dhe nëse e japim këtë bllok koeficientësh, do të marrim imazhin e mëposhtëm:
Siç mund ta shihni, nuk duket si imazhi origjinal. Ju mund të shihni se koeficienti i parë është shumë i ndryshëm nga të gjithë të tjerët. Ky koeficient i parë njihet si koeficienti DC, i cili përfaqëson të gjitha mostrat në grupin e hyrjes, diçka si një mesatare.
Ky bllok koeficientësh ka një veti interesante: ndan komponentët me frekuencë të lartë nga ato me frekuencë të ulët.
Në një imazh, pjesa më e madhe e fuqisë është e përqendruar në frekuenca më të ulëta, kështu që nëse e konvertoni imazhin në komponentët e tij të frekuencës dhe hiqni koeficientët e frekuencës më të lartë, mund të zvogëloni sasinë e të dhënave të nevojshme për të përshkruar imazhin pa sakrifikuar shumë cilësinë e figurës.
Frekuenca i referohet sa shpejt ndryshon sinjali.
Le të përpiqemi të zbatojmë njohuritë e marra në rastin e testit duke konvertuar imazhin origjinal në frekuencën e tij (bllokun e koeficientëve) duke përdorur DCT dhe më pas duke hedhur poshtë një pjesë të koeficientëve më pak të rëndësishëm.
Fillimisht e konvertojmë në domenin e frekuencës.
Më pas, hedhim një pjesë (67%) të koeficientëve, kryesisht pjesën e poshtme të djathtë.
Së fundi, ne rindërtojmë imazhin nga ky bllok koeficientësh të hedhur poshtë (mos harroni, ai duhet të jetë i kthyeshëm) dhe e krahasojmë atë me origjinalin.
Shohim që i ngjan imazhit origjinal, por ka shumë dallime nga origjinali. Ne hodhëm 67,1875% dhe përsëri morëm diçka që i ngjan origjinalit. Ishte e mundur të hidheshin më me mend koeficientët për të marrë një imazh me cilësi edhe më të mirë, por kjo është një temë tjetër.
Çdo koeficient gjenerohet duke përdorur të gjithë pikselët
E rëndësishme: çdo koeficient nuk është i lidhur drejtpërdrejt me një piksel, por është një shumë e ponderuar e të gjithë pikselëve. Ky grafik mahnitës tregon se si llogariten koeficientët e parë dhe të dytë duke përdorur peshat unike për secilin indeks.
Ju gjithashtu mund të përpiqeni të vizualizoni DCT duke parë një formim të thjeshtë imazhi të bazuar në të. Për shembull, këtu është simboli A i krijuar duke përdorur çdo peshë koeficienti:
Hapi i 4-të - kuantizimi
Pasi hedhim disa koeficientë në hapin e mëparshëm, në hapin e fundit (transformimin) kryejmë një formë të veçantë kuantizimi. Në këtë fazë është e pranueshme humbja e informacionit. Ose, më thjesht, ne do të kuantizojmë koeficientët për të arritur kompresimin.
Si mund të kuantizoni një bllok koeficientësh? Një nga metodat më të thjeshta është kuantizimi uniform, kur marrim një bllok, e ndajmë atë me një vlerë (me 10) dhe rrumbullakosim rezultatin.
A mund ta kthejmë këtë bllok koeficientësh? Po, ne mundemi, duke shumëzuar me të njëjtën vlerë me të cilën kemi ndarë.
Kjo qasje nuk është më e mira sepse nuk merr parasysh rëndësinë e secilit koeficient. Dikush mund të përdorë një matricë kuantizuesish në vend të një vlere të vetme, dhe kjo matricë mund të shfrytëzojë veçorinë DCT duke kuantizuar shumicën e pjesës së poshtme të djathtë dhe pakicës së së majtës së sipërme.
Hapi 5 - kodimi i entropisë
Pasi të kemi kuantizuar të dhënat (blloqet e imazhit, fragmentet, kornizat), ne mund t'i kompresojmë ato pa humbje. Ka shumë mënyra algoritmike për të kompresuar të dhënat. Ne do t'i hedhim një vështrim të shpejtë disa prej tyre, për një kuptim më të thellë mund të lexoni librin Kuptimi i ngjeshjes: Kompresimi i të dhënave për zhvilluesit modernë ("").
Kodimi i videos duke përdorur VLC
Le të themi se kemi një rrjedhë personazhesh: a, e, r и t. Probabiliteti (duke filluar nga 0 në 1) se sa shpesh shfaqet çdo karakter në një transmetim është paraqitur në këtë tabelë.
| a | e | r | t | |
|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,2 | 0,2 |
Ne mund të caktojmë kode unike binare (mundësisht të vogla) për ato më të mundshmet, dhe kode më të mëdha për ato më pak të mundshme.
| a | e | r | t | |
|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,2 | 0,2 |
| Kodi binar | 0 | 10 | 110 | 1110 |
Ne ngjeshim transmetimin, duke supozuar se do të përfundojmë duke shpenzuar 8 bit për çdo karakter. Pa kompresim, do të nevojiteshin 24 bit për karakter. Nëse zëvendësoni çdo karakter me kodin e tij, ju merrni kursime!
Hapi i parë është kodimi i karakterit e, e cila është e barabartë me 10, dhe karakteri i dytë është a, e cila shtohet (jo në mënyrë matematikore): [10][0], dhe në fund karakteri i tretë t, që e bën bitstream-in tonë përfundimtar të kompresuar të barabartë me [10][0][1110] ose 1001110, e cila kërkon vetëm 7 bit (3,4 herë më pak hapësirë se origjinali).
Ju lutemi vini re se çdo kod duhet të jetë një kod unik me një parashtesë. do t'ju ndihmojë të gjeni këta numra. Edhe pse kjo metodë nuk është pa të meta, ka kodekë video që ende ofrojnë këtë metodë algoritmike për kompresim.
Si koduesi ashtu edhe dekoderi duhet të kenë akses në një tabelë simbolesh me kodet e tyre binare. Prandaj, është gjithashtu e nevojshme të dërgoni një tabelë si hyrje.
Kodimi aritmetik
Le të themi se kemi një rrjedhë personazhesh: a, e, r, s и t, dhe probabiliteti i tyre është paraqitur në këtë tabelë.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Duke përdorur këtë tabelë, ne do të ndërtojmë vargjet që përmbajnë të gjithë karakteret e mundshme, të renditura sipas numrit më të madh.
Tani le të kodojmë një rrjedhë prej tre karakteresh: ha.
Së pari zgjidhni karakterin e parë e, e cila është në nënrangun nga 0,3 në 0,6 (pa përfshirë). Ne e marrim këtë nënvarg dhe e ndajmë përsëri në të njëjtat përmasa si më parë, por për këtë varg të ri.
Le të vazhdojmë të kodojmë transmetimin tonë ha. Tani merrni karakterin e dytë a, e cila është në nënrangun e ri nga 0,3 në 0,39, dhe më pas marrim karakterin tonë të fundit t dhe duke përsëritur të njëjtin proces përsëri, marrim nën-vargun përfundimtar nga 0,354 në 0,372.
Thjesht duhet të zgjedhim një numër në nëndarjen e fundit nga 0,354 në 0,372. Le të zgjedhim 0,36 (por ju mund të zgjidhni çdo numër tjetër në këtë nënvarg). Vetëm me këtë numër do të mund të rivendosim transmetimin tonë origjinal. Është sikur të kishim tërhequr një vijë brenda intervaleve për të koduar rrjedhën tonë.
Operacioni i kundërt (d.m.th. dekodimi) është po aq e thjeshtë: me numrin tonë 0,36 dhe gamën tonë fillestare, ne mund të kryejmë të njëjtin proces. Por tani, duke përdorur këtë numër, ne identifikojmë rrymën e koduar duke përdorur këtë numër.
Me diapazonin e parë, vërejmë se numri ynë korrespondon me fetën, prandaj ky është karakteri ynë i parë. Tani e ndajmë përsëri këtë nën-gamë duke ndjekur të njëjtin proces si më parë. Këtu mund të shihni se 0,36 korrespondon me simbolin a, dhe pas përsëritjes së procesit arritëm te karakteri i fundit t (duke formuar rrjedhën tonë origjinale të koduar ha).
Si koduesi ashtu edhe dekoderi duhet të kenë një tabelë të probabiliteteve të simboleve, kështu që është e nevojshme ta dërgoni atë edhe në të dhënat hyrëse.
Mjaft elegante, apo jo? Kushdo që doli me këtë zgjidhje ishte i zgjuar. Disa kodekë video e përdorin këtë teknikë (ose të paktën e ofrojnë atë si opsion).
Ideja është të kompresojmë pa humbje një rrjedhë bit të kuantizuar. Me siguri këtij artikulli i mungojnë shumë detaje, arsye, kompromise, etj. Por nëse jeni një zhvillues, duhet të dini më shumë. Kodekët e rinj përpiqen të përdorin algoritme të ndryshme të kodimit të entropisë si p.sh ANS.
Hapi 6 - formati bitstream
Pasi të keni bërë të gjitha këto, mbetet vetëm të shpaketoni kornizat e kompresuara në kontekstin e hapave të kryera. Dekoderi duhet të informohet në mënyrë eksplicite për vendimet e marra nga koduesi. Dekoderi duhet të pajiset me të gjithë informacionin e nevojshëm: thellësinë e bitit, hapësirën e ngjyrave, rezolucionin, informacionin e parashikimit (vektorët e lëvizjes, parashikimi INTER i drejtuar), profili, niveli, shpejtësia e kornizës, lloji i kornizës, numri i kornizës dhe shumë më tepër.
Ne do të hedhim një vështrim të shpejtë në bitstream H.264. Hapi ynë i parë është të krijojmë një rrymë bit minimale H.264 (FFmpeg si parazgjedhje shton të gjitha opsionet e kodimit si p.sh. SEI NAL - do të zbulojmë se çfarë është pak më tej). Ne mund ta bëjmë këtë duke përdorur depon tonë dhe FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Kjo komandë do të gjenerojë një bitstream të papërpunuar H.264 me një kornizë, rezolucion 64×64, me hapësirë ngjyrash GJ420. Në këtë rast, imazhi i mëposhtëm përdoret si kornizë.
H.264 bitstream
Standard AVC (H.264) përcakton se informacioni do të dërgohet në makrokorniza (në kuptimin e rrjetit), të quajtur nal (ky është një nivel abstraksioni i rrjetit). Qëllimi kryesor i NAL është të ofrojë një video prezantim "miqësor në ueb". Ky standard duhet të funksionojë në televizorë (të bazuar në transmetim), në internet (të bazuar në paketa).
Ekziston një shënues sinkronizimi për të përcaktuar kufijtë e elementeve NAL. Çdo shenjë sinkronizimi përmban një vlerë 0x00 0x00 0x01, përveç të parës, e cila është e barabartë me 0x00 0x00 0x00 0x01. Nëse nisim hexdump për bitstream-in e gjeneruar H.264, ne identifikojmë të paktën tre modele NAL në fillim të skedarit.
Siç u tha, dekoderi duhet të dijë jo vetëm të dhënat e imazhit, por edhe detajet e videos, kornizën, ngjyrat, parametrat e përdorur dhe shumë më tepër. Bajti i parë i çdo NAL përcakton kategorinë dhe llojin e tij.
| Identifikuesi i tipit NAL | Përshkrim |
|---|---|
| 0 | Lloj i panjohur |
| 1 | Fragment imazhi i koduar pa IDR |
| 2 | Seksioni i të dhënave të pjesëve të koduara A |
| 3 | Seksioni i të dhënave të pjesëve të koduara B |
| 4 | Seksioni i të dhënave të pjesëve të koduara C |
| 5 | Fragment IDR i koduar i një imazhi IDR |
| 6 | Më shumë informacion rreth shtrirjes SEI |
| 7 | Set i parametrave të sekuencës SPS |
| 8 | Set i parametrave të imazhit PPS |
| 9 | Ndarësi i aksesit |
| 10 | Fundi i sekuencës |
| 11 | Fundi i fillit |
| ... | ... |
Në mënyrë tipike NAL-i i parë i një bitstream është SPS. Ky lloj NAL është përgjegjës për informimin rreth variablave të zakonshëm të kodimit si profili, niveli, rezolucioni, etj.
Nëse e kapërcejmë shënuesin e parë të sinkronizimit, mund të deshifrojmë bajtin e parë për të zbuluar se cili lloj NAL është i pari.
Për shembull, bajt i parë pas shenjës së sinkronizimit është 01100111, ku biti i parë (0) është në fushën forbidden_zero_bit. 2 bitet e ardhshme (11) na tregon fusha nal_ref_idc, që tregon nëse kjo NAL është fushë referimi apo jo. Dhe 5 bitet e mbetura (00111) na tregon fusha nal_unit_lloji, në këtë rast është blloku SPS (7) NAL.
Bajt i dytë (dyjor=01100100, magji=0x64, dhjetor=100) në SPS NAL është fusha profile_idc, e cila tregon profilin që përdori koduesi. Në këtë rast, u përdor një profil i kufizuar i lartë (dmth., një profil i lartë pa mbështetje të segmentit B të dyanshëm).
Nëse shikoni specifikimin e bitstream H.264 për SPS NAL, do të gjejmë shumë vlera për emrin, kategorinë dhe përshkrimin e parametrit. Për shembull, le të shohim fushat pic_width_në_mbs_minus_1 и pic_lartësia_në_njësitë_map_minus_1.
| Emri i parametrit | Kategori | Përshkrim |
|---|---|---|
| pic_width_në_mbs_minus_1 | 0 | ue(v) |
| pic_lartësia_në_njësitë_map_minus_1 | 0 | ue(v) |
Nëse kryejmë disa operacione matematikore me vlerat e këtyre fushave, do të marrim rezolucionin. Dikush mund të përfaqësojë 1920 x 1080 duke përdorur pic_width_në_mbs_minus_1 me një vlerë prej 119 ((119 + 1) * madhësia e makrobllokut = 120 * 16 = 1920). Përsëri, për të kursyer hapësirë, në vend që të kodojmë 1920, ne e bëmë atë me 119.
Nëse vazhdojmë të kontrollojmë videon tonë të krijuar në formë binare (për shembull: xxd -b -c 11 v/minimal_yuv420.h264), atëherë mund të shkoni në NAL-in e fundit, që është vetë korniza.
Këtu shohim vlerat e tij të para prej 6 bajt: 01100101 10001000 10000100 00000000 00100001 11111111. Meqenëse bajt-i i parë dihet se tregon llojin NAL, në këtë rast (00101) është një fragment IDR (5), dhe më pas mund ta eksploroni më tej:
Duke përdorur informacionin e specifikimit, do të jetë e mundur të deshifrohet lloji i fragmentit (lloji i fetës) dhe numri i kornizës (korniza_num) ndër fusha të tjera të rëndësishme.
Për të marrë vlerat e disa fushave (ue(v), me(v), se(v) ose te(v)), duhet të deshifrojmë fragmentin duke përdorur një dekoder special të bazuar në . Kjo metodë është shumë efikase për kodimin e vlerave të variablave, veçanërisht kur ka shumë vlera të paracaktuara.
kuptimi lloji i fetës и korniza_num e kësaj videoje janë 7 (I-fragment) dhe 0 (korniza e parë).
Një rrjedhë bit mund të mendohet si një protokoll. Nëse dëshironi të dini më shumë rreth bitstream-it, duhet t'i referoheni specifikimeve ITU H.264. Këtu është një diagram makro që tregon se ku janë të dhënat e imazhit (YUV në formë të ngjeshur).
Mund të ekzaminohen bitstream të tjerë, si p.sh VP9, H.265 (HEVC) ose edhe bitstream-i ynë i ri më i mirë AV1. A janë të gjithë të ngjashëm? Jo, por pasi kupton të paktën një, është shumë më e lehtë të kuptosh pjesën tjetër.
Dëshironi të praktikoni? Eksploroni rrjedhën e bitave H.264
Mund të gjeneroni një video me kornizë të vetme dhe të përdorni MediaInfo për të ekzaminuar rrjedhën e bitave H.264. Në fakt, asgjë nuk ju pengon të shikoni edhe kodin burimor që analizon rrjedhën e biteve H.264 (AVC).
Për praktikë, mund të përdorni Intel Video Pro Analyzer (a thashë tashmë që programi është i paguar, por ekziston një version provë falas me një kufi prej 10 kornizash?).
Rishikimi
Vini re se shumë kodekë modernë përdorin të njëjtin model që sapo kemi studiuar. Këtu, le të hedhim një vështrim në bllok diagramin e kodekut të videos Thor. Ai përmban të gjitha hapat që kemi kaluar. E gjithë qëllimi i këtij postimi është që të paktën t'ju japë një kuptim më të mirë të inovacioneve dhe dokumentacionit në këtë fushë.
Më parë, ishte llogaritur se 139 GB hapësirë në disk do të nevojiteshin për të ruajtur një skedar video që zgjat një orë me cilësi 720p dhe 30 fps. Nëse përdorni metodat e diskutuara në këtë artikull (parashikimet ndërmjet kornizave dhe të brendshme, transformimi, kuantizimi, kodimi i entropisë, etj.), atëherë mund të arrini (bazuar në faktin se shpenzojmë 0,031 bit për piksel), një video me mjaft cilësi e kënaqshme, duke zënë vetëm 367,82 MB, jo 139 GB memorie.
Si arrin H.265 raport më të mirë kompresimi se H.264?
Tani që dimë më shumë se si funksionojnë kodekët, është më e lehtë të kuptojmë se si kodekët më të rinj mund të ofrojnë rezolucion më të lartë me më pak bit.
Nëse krahasojmë AVC и HEVC, vlen të kujtohet se kjo është pothuajse gjithmonë një zgjedhje midis ngarkesës më të madhe të CPU dhe raportit të kompresimit.
HEVC ka më shumë opsione seksionesh (dhe nënseksionesh) sesa AVC, më shumë drejtime të brendshme të parashikimit, kodim i përmirësuar i entropisë dhe më shumë. Të gjitha këto përmirësime janë bërë H.265 të aftë për të ngjeshur 50% më shumë se H.264.
Pjesa e parë:
Burimi: www.habr.com