Pjesa e parë:
ĂfarĂ«? Video kodeku Ă«shtĂ« njĂ« pjesĂ« e softuerit/harduerit qĂ« kompreson dhe/ose zhbllokon video dixhitale.
Për çfarë? Pavarësisht disa kufizimeve si në kapacitetin e bandwidth-it ashtu
dhe nĂ« sasinĂ« e hapĂ«sirĂ«s pĂ«r ruajtje tĂ« tĂ« dhĂ«nave, tregu kĂ«rkon video mĂ« tĂ« cilĂ«sisĂ« gjithnjĂ« nĂ« rritje. A e mbani mend si nĂ« postimin e kaluar llogaritĂ«m minimumin e nevojshĂ«m pĂ«r 30 kadra nĂ« sekondĂ«, 24 bits pĂ«r piksel, me njĂ« rezolutĂ« prej 480Ă240? Kemi marrĂ« 82.944 Mbit/s pa kompresim. Kompresimi Ă«shtĂ« aktualisht mĂ«nyra e vetme pĂ«r tĂ« transmetuar HD/FullHD/4K nĂ« ekranet televizive dhe nĂ« Internet. Si arrihet kjo? Tani do tĂ« shqyrtojmĂ« shkurtimisht metodat kryesore.
Përkthimi është bërë me mbështetje nga EDISON Software.Ne merremi me , si dhe .
Kodeku vs Container
NjĂ« gabim i zakonshĂ«m i fillestarĂ«ve Ă«shtĂ« tĂ« ngatĂ«rrojnĂ« kodekun e videos dixhitale me kontejnerin e videos dixhitale. NjĂ« kontejner Ă«shtĂ« njĂ« format. ĂshtĂ« njĂ« mbĂ«shtetje, qĂ« pĂ«rmban metadonet e videos (dhe, ndoshta, audio). Videoja e kompresuar mund tĂ« konsiderohet si ngarkesĂ« e dobishme e kontejnerit.
Zakonisht, zgjedhja e skedarit të videos tregon llojin e kontejnerit. Për shembull, skedari video.mp4 ndoshta është një kontejner MPEG-4 Part 14, ndërsa skedari me emrin video.mkv është, shumë të gjitha, . Për të qenë plotësisht të sigurt për kodekun dhe formatin e kontejnerit, mund të përdorni ose .
Pak histori
Para se të kalojmë në Si?, le të përfundojmë pak në histori, për të kuptuar më mirë disa kodeka të vjetër.
Kodeku video H.261 shkoi në vitin 1990 (teknikisht - në 1988) dhe u krijua për të punuar me një shpejtësi transmetimi të të dhënave prej 64 Kbit/s. Aty u përdorën tashmë ide të tilla si sub-discretizimi i ngjyrave, makrobloku etj. 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 versione e parĂ« H.264/AVC. NĂ« tĂ« njĂ«jtin vit, kompania "TrueMotion" lĂ«shoi kodekun e saj videore tĂ« lirĂ«, qĂ« kompresonte video me humbje tĂ« quajtur VP3. NĂ« vitin 2008, Google e bleu kĂ«tĂ« kompani, duke lĂ«shuar VP8 nĂ« tĂ« njĂ«jtin vit. NĂ« dhjetor 2012, Google lĂ«shoi VP9, dhe ai mbĂ«shtetet nga rreth Ÿ e tregut tĂ« shfletuesve (duke pĂ«rfshirĂ« pajisjet mobile).
AV1 është një kodek video i ri i lirë me burim të hapur, i zhvilluar nga Aleanca për Media të Hapura (AOMedia), që përfshin kompani të njohura si: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel dhe Cisco. Versioni i parë i kodek-ut 0.1.0 u publikua më 7 prill 2016.
Lindja e AV1
Në fillim të vitit 2015, Google punonte mbi VP10, Xiph (i cili i përket Mozilla) po punonte mbi Daala, ndërsa Cisco zhvilloi kodekun e tyre falas me emrin Thor.
Pastaj MPEG LA Në fillim shpalli kufij vjetor për HEVC (H.265) dhe tarifën, 8 herë më të lartë se për H.264, por së shpejti ata ndryshuan rregullat përsëri:
pa kufij vjetor,
tarifa për përmbajtjen (0,5% të të ardhurave) dhe
tarifa për njësi produkti ishte rreth 10 herë më e lartë se për H.264.
Alyansa për Media të Hapura u krijua 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ë.
Kompani kishin njĂ« qĂ«llim tĂ« pĂ«rbashkĂ«t â kodek video pa taksa licencimi. Pastaj shfaqet AV1 me njĂ« licencĂ« patenti shumĂ« mĂ« tĂ« thjeshtĂ«. Timothy B. Terryberry bĂ«ri njĂ« prezantim tĂ« mahnitshĂ«m, qĂ« u bĂ« burimi i konceptit aktual tĂ« AV1 dhe modelit tĂ« tij tĂ« licencĂ«s.
Do të befasoheni, duke marrë parasysh se mund të analizoni kodekun AV1 përmes shfletuesit (ata të interesuar mund të vizitojnë).
Kodeku Universal
Le të shqyrtojmë mekanizmat kryesorë që qëndrojnë pas kodekut universale të videove. Shumica e këtyre koncepteve janë të dobishme dhe përdoren në kodekët modernë, të tillë si VP9, AV1 dhe HEVC. Paralajmëroj se shumë gjëra të shpjeguara do të thjeshtohen. Ndonjëherë do të përdoren shembuj realë (si në rastin e H.264) për të demonstruar teknologjitë.
Hapi i parĂ« â ndarja e imazhit
Hapi i parë është ndarja e kuadratit në disa pjesë, nën-pjesë dhe më tej.
Pse? Ka shumë arsye. Kur ndajmë imazhin, mund të parashikojmë më saktë vektorin e lëvizjes, duke përdorur pjesë të vogla për pjesë të vogla lëvizëse. Ndërsa për sfondin statik, mund të limitohemi në pjesë më të mëdha.
Zakonisht kodekĂ«t i organizojnĂ« kĂ«to pjesĂ« nĂ« seksione (ose fragmente), makrobllokĂ« (ose blloqe tĂ« pemĂ«s sĂ« kodimit) dhe njĂ« sĂ«rĂ« nĂ«n-pjesĂ«sh. MadhĂ«sia maksimale e kĂ«tyre pjesĂ«ve variaton, HEVC vendos 64Ă64, ndĂ«rsa AVC pĂ«rdor 16Ă16, dhe nĂ«n-pjesĂ«t mund tĂ« ndahen nĂ« madhĂ«si 4Ă4.
A e kujtojmë llojet e kuadrove nga artikulli i kaluar?! Kjo mund të aplikohet edhe për blloqet, kështu që mund të kemi I-fragmente, B-bllok, P-makrobllok etj.
PĂ«r ata qĂ« duan tĂ« praktikojnĂ« â shikoni si do tĂ« ndajĂ« imazhi nĂ« seksione dhe nĂ«nseksione. PĂ«r kĂ«tĂ« mund tĂ« pĂ«rdorni atĂ« qĂ« Ă«shtĂ« pĂ«rmendur mĂ« parĂ« nĂ« artikullin e kaluar. (ai qĂ« Ă«shtĂ« me pagesĂ«, por me njĂ« version provĂ« falas, i cili ka kufizime nĂ« dhjetĂ« kuadro tĂ« parat). KĂ«tu janĂ« analizuar seksionet. VP9:
Hapi 2 â parashikimi
Sa herë që kemi krijuar seksionet, mund të përgatisim parashikime astrologjike për to. Për INTER-parashikimin është e nevojshme të transmetohet vektorët e lëvizjes dhe mbetja, ndërsa për parashikimin INTRA transmetohet direksioni i parashikimit dhe mbetja.
Hapi 3 â transformimi
Pasi tĂ« kemi marrĂ« bllokun mbetje (seksioni i parashikuar â seksioni real), Ă«shtĂ« e mundur ta kthejmĂ« atĂ« nĂ« mĂ«nyrĂ« qĂ« tĂ« dimĂ« cilat piksele mund tĂ« hiqen, duke ruajtur kĂ«shtu cilĂ«sinĂ« e pĂ«rgjithshme. Ka disa transformime qĂ« sigurojnĂ« njĂ« sjellje tĂ« saktĂ«.
MegjithatĂ« ka edhe metoda tĂ« tjera, le tĂ« shqyrtojmĂ« mĂ« nĂ« detaje transformimin e kosinusit diskrĂ«tar (DCT â nga transformimi i kosinusit diskrĂ«tar). Funksionet kryesore tĂ« DCT:
- Transformon blloqet e pikseleve në blloqe të barabarta të koeficientëve të frekuencës.
- Komprimon energjinë, duke ndihmuar në eliminimin e tepërt të hapësirës.
- Ofron reversibilitet.
Më 2 shkurt 2017, Sintra R.J. (Cintra, R.J.) dhe Bayer F.M. (Bayer F.M.) publikuan një artikull mbi transformimin e ngjashëm me DCT për kompresimin e imazheve, që kërkon vetëm 14 shtesa.
Mos u shqetësoni nëse nuk e kuptuat përparësitë e secilës pikë. Tani në shembuj konkretë do të sigurohemi për vlerën e tyre reale.
Le tĂ« marrim njĂ« bllok pikselesh 8Ă8:
Ky bllok renderohet në imazhin e mëposhtëm 8 me 8 pikselë:
TĂ« aplikojmĂ« DCT nĂ« kĂ«tĂ« bllok pikselesh dhe marrim njĂ« bllok koeficientesh me madhĂ«si 8Ă8:
Dhe nëse renderojmë këtë bllok koeficientesh, do të marrim një imazh të tillë:
Siç e shohim, kjo nuk i ngjan imazhit origjinal. Mund të vëmë re se koeficienti i parë ndryshon ndjeshëm nga të tjerët. Ky koeficient i parë njihet si koeficienti DC, që përfaqëson të gjitha mostrave në masivin hyrës, diçka e ngjashme me vlerën e mesme.
Ky kyç i këtij blloku koeficientësh ka një veçori interesante: ndan komponentët me frekuenca të larta nga ata me frekuenca të ulta.
Në imazh, pjesa më e madhe e fuqisë është e përqendruar në frekuenca më të ulta, prandaj, nëse e shndërrojmë imazhin në komponentët e tij frekuencialë dhe heqim koeficientët me frekuenca më të larta, mund të zvogelojmë sasinë e të dhënave të nevojshme për të përshkruar imazhin pa sakrifikuar shumë cilësinë e tij.
Frekuenca do të thotë sa shpejt ndryshon sinjali.
Le të provojmë të aplikojmë njohuritë e marra në shembullin testues duke e shndërruar imazhin origjinal në frekuencën e tij (bllokun e koeficientëve) 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.
Më pas, heqim një pjesë (67%) të koeficientëve, kryesisht nga pjesa e poshtme e djathtë.
Së fundmi, rikonstruktojmë imazhin nga ky bllok koeficientësh të hequr (mbani mend, duhet të jetë i reversueshëm) dhe e krahasojmë me origjinalin.
Shohim se ai i ngjan imazhit origjinal, por ka shumë dallime nga origjinali. Ne hodhëm poshtë 67.1875% dhe gjithsesi morëm diçka që i ngjante burimit. Ishte e mundur të hidhnim më mendshëm koeficientët për të marrë një imazh me cilësi akoma më të mirë, por kjo është një temë tjetër.
Ădo koeficient formohet duke pĂ«rdorur tĂ« gjitha pikselĂ«t.
ĂshtĂ« e rĂ«ndĂ«sishme: çdo koeficient nuk pĂ«rfaqĂ«son drejtpĂ«rsĂ«drejti njĂ« piksel, por paraqet njĂ« shumĂ« tĂ« peshuar tĂ« tĂ« gjithĂ« pikselĂ«ve. Ky grafik befasues tregon se si llogaritet koeficienti i parĂ« dhe i dytĂ« duke pĂ«rdorur peshat unike pĂ«r çdo indeks.
Ju gjithashtu mund të përpiqeni të vizualizoni DCT duke parë formimin e thjeshtë të imazhit mbi të. Për shembull, këtu është simboli A, i formuar duke përdorur çdo peshë koeficienti:
Hapi 4 - Kquantizimi
Pas heqjes së disa koeficientëve në hapin e kaluar, në hapin e fundit (transformimi), bëjmë një formë të veçantë kquantizimi. Në këtë fazë, lejohet të humbasim informacion. Ose, thjesht, do të kquantizojmë koeficientët për të arritur kompresimin.
Si mund të kvantizojmë një bllok koeficientësh? Një nga metodat më të thjeshta është kvantizimi i barabartë, kur marrim bllokun, e ndajmë në një vlerë (në 10) dhe e rrumbullakosim atë që kemi marrë.
A mund ta anulojmë këtë bllok koeficientësh? Po, mundemi, duke e shumëzuar me të njëjtën vlerë me të cilën e kemi ndarë.
Ky qasje nuk është më e mira, sepse nuk merr parasysh rëndësinë e secilit koeficient. Mund të përdorim një matricë kvantizuesish në vend të një vlerë të vetme, dhe kjo matricë mund të përdorë pronën DCT, duke kvantizuar shumicën e këndit të poshtëm të djathtë dhe pak të këndit të sipërm të majtë.
Hapi 5 â kodimi i entropisĂ«
Pasi të kemi kvantizuar të dhënat (blloqet e imazheve, fragmentet, kadra), akoma mund të kompresojmë ato pa humbje. Ekzistojnë shumë metoda algoritmike për kompresimin e të dhënave. Ne do të njohim shkurtimisht disa prej tyre, për një kuptim më të thellë mund të lexoni librin 'Kuptimi i Kompresimit: Kompresimi i të Dhënave për Zhvilluesit e Bashkëkohshëm'»).
Kodimi i videos me VLC
Supozoni se kemi një rrjedhë simbolesh: a, e, r dhe t. Probabiliteti (në intervalin nga 0 në 1) i asaj se sa shpesh shfaqet secili simbol në rrjedhë përfaqësohet në këtë tabelë.
| a | e | r | t | |
|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,2 | 0,2 |
Mund të atribuoni kode binare unike (preferohet të jenë të vogla) atyre që janë më të mundshme, dhe kode më të mëdha për ato që janë më pak të mundshme.
| 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 do të shpenzojmë 8 bite për çdo simbol. Pa kompresim, do të nevojiteshin 24 bite për simbol. Nëse çdo simbol zëvendësohet me kodin e tij, rezulton një kursim!
Hapi i parë është kodimi i simbolit e, i cili është 10, dhe simboli i dytë është a, i cili shtohet (në mënyrë jo matematikore): [10] [0], dhe, përfundimisht, simboli i tretë t, i cili e bën rrjedhën tonë të fundit të koduar të jetë [10] [0] [1110] ose 1001110, për të cilin nevojiten vetëm 7 bite (3.4 herë më pak hapësirë se origjinali).
Kujtoni, që çdo kod duhet të jetë një kod unik me prefiks. do të ndihmojë në gjetjen e këtyre numrave. Megjithëse ky metodë nuk është pa mangësi, ekzistojnë kodekët e videos që ende ofrojnë këtë metodë algoritmike për kompresim.
Shtypësi dhe dekoduesi duhet të kenë qasje në tabelën e simboleve me kodet e tyre binarë. Prandaj, është e nevojshme të dërgohet gjithashtu tabela si input.
Kodimi aritmetik
Supozoni se kemi një rrjedhë simbolesh: a, e, r, s dhe t, dhe probabiliteti i tyre paraqitet në këtë tabelë.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probabiliteti | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Me këtë tabelë do të ndërtosh intervale që përmbajnë të gjitha simbolet e mundshme, të renditura sipas numrit më të madh.
Tani le të kodojmë një rrjedhë me tre simbole: eat.
Së pari, zgjedhim simbolin e parë e, i cili ndodhet në nënintervalin nga 0,3 deri në 0,6 (pa e përfshirë). E marrim këtë nëninterval dhe e ndajmë sërish në proporcione të njëjta si më parë, por 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, arrijmë në nënintervalin e fundit nga 0,354 deri në 0,372.
Ne thjesht duhet 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 do tĂ« jemi nĂ« gjendje tĂ« rikthejmĂ« rrjedhĂ«n tonĂ« origjinale. ĂshtĂ« sikur ne po vizatonim njĂ« vijĂ« brenda intervaleve pĂ«r kodimin e rrjedhĂ«s sonĂ«.
Operacioni i kundërt (dmth. dekodimi) është gjithashtu i thjeshtë: me numrin tonë 0,36 dhe intervalin tonë origjinal mund të fillojmë të njëjtin proces. Por tani, duke përdorur këtë numër, zbulojmë rrjedhën e koduar me këtë numër.
Me intervalin e parë vërejmë se numri ynë korrespondon me prerjen, prandaj ky është simboli ynë i parë. Tani ndarim përsëri këtë nëninterval, duke kryer të njëjtin proces si më parë. Këtu mund të vërejmë se 0,36 korrespondon me simbolin a, dhe pasi të përsëritim procesin, arrijmë në simbolin e fundit. t (duke formuar rrjedhën tonë të koduar origjinale. eat).
Shtypësi dhe dekoduesi duhet të kenë një tabelë probabiliteti të simboleve në dispozicion, prandaj është e nevojshme të dërgohet gjithashtu në input.
Mjaft elegant, apo jo? Disa nga ata që e shpikën këtë zgjidhje ishin jashtëzakonisht të zgjuar. Disa kodekëve video përdorin këtë teknikë (ose, së paku, e ofrojnë atë si një opsion).
Ideja është të kompresosh një rrjedhë bitesh të kuantizuar pa humbje. Sigurisht, ky artikull mund të mos përmbajë tonelata detajesh, arsyesh, kompromisesh etj. Por ju, nëse jeni një zhvillues, duhet të dini më shumë. Kodet e reja përpiqen të përdorin algoritme të ndryshme kodimi të entropisë, siç janë ANS.
Hapi 6 â formati i rrjedhĂ«s sĂ« bitĂ«ve
Pasi të keni bërë të gjitha këto, mbetet të çpaketoni kadrët e kompresuar në kontekstin e hapave të realizuar. Duhet ta informoni në mënyrë të qartë dekoduesin për vendimet e marra nga koduesi. Dekoduesi duhet të ketë gjithçka informacionin e nevojshëm: thellësia e bitëve, hapësira e ngjyrave, rezolucioni, informacioni mbi parashikimet (atëra lëvizjeje, parashikimi drejtues INTER), profili, niveli, frekuenca e kadrave, tipi i kadrave, numri i kadrave dhe shumë të tjera.
Ne do tĂ« njohim nĂ« mĂ«nyrĂ« tĂ« pĂ«rgjithshme rrjedhĂ«n e bitĂ«ve H.264. Hapi ynĂ« i parĂ« Ă«shtĂ« tĂ« krijojmĂ« njĂ« rrjedhĂ« minimale bitĂ«sh H.264 (FFmpeg nĂ« mĂ«nyrĂ« tĂ« paracaktuar i shton tĂ« gjithĂ« parametrat e kodimit, siç janĂ« SEI NAL â pak mĂ« vonĂ« do tĂ« mĂ«sojmĂ« se çfarĂ« Ă«shtĂ« kjo). Mund ta bĂ«jmĂ« kĂ«tĂ« duke pĂ«rdorur repositorin tonĂ« dhe FFmpeg.
.\/s\/ffmpeg -i \/files\/i\/minimal.png -pix_fmt yuv420p \/files\/v\/minimal_yuv420.h264
Kjo komandĂ« do tĂ« gjenerojĂ« njĂ« rrjedhĂ« tĂ« papĂ«rpunuar bitĂ«sh H.264 me njĂ« kadĂ«r, rezolucion 64Ă64, me hapĂ«sirĂ«n e ngjyrave YUV420. NĂ« kĂ«tĂ« rast, si kornizĂ« do tĂ« pĂ«rdoret imazhi i mĂ«poshtĂ«m.
Rrjedha e bitëve H.264
Standarti AVC (H.264) përcakton se informacioni do të dërgohet në makrokadra (në kuptimin e rrjetit), të quajtura NAL (kjo është një nivel abstraksioni i rrjetit). Qëllimi kryesor i NAL është të ofrojë një pamje "të miqshme për rrjetin" të videos. Ky standard duhet të funksionojë në televizorë (të bazuar në rrjedha), në internet (të bazuar në paketa).
Ekziston njĂ« shenjĂ« sinkronizimi pĂ«r tĂ« pĂ«rcaktuar kufijtĂ« e elementeve NAL. Ădo shenjĂ« sinkronizimi pĂ«rmban njĂ« vlerĂ« 0x00 0x00 0x01, pĂ«rveç asaj tĂ« parĂ«, e cila Ă«shtĂ« 0x00 0x00 0x00 0x01. NĂ«se e fillojmĂ« hexdump pĂ«r rrjedhĂ«n e gjeneruar tĂ« bitĂ«ve H.264, do tĂ« identifikojmĂ« sĂ« paku tre modele NAL nĂ« fillim tĂ« skedarit.
Siç u tha, dekoduesi duhet të dijë jo vetëm të dhënat e imazhit, por gjithashtu detajet e videos, kadrin, ngjyrat, parametrat e përdorur dhe shumë të tjera. Bytes e para të çdo NAL përcaktojnë kategorinë dhe tipin e tij.
| Identifikuesi i tipit NAL | PĂ«rshkrimi |
|---|---|
| 0 | Tip i panjohur |
| 1 | Fraksioni i koduar i imazhit pa IDR |
| 2 | Fraksioni i koduar i të dhënave të prerjes A |
| 3 | Fraksioni i koduar i të dhënave të prerjes B |
| 4 | Fraksioni i koduar i të dhënave të prerjes C |
| 5 | Fraksioni IDR i koduar i imazhit IDR |
| 6 | Informacion shtesë mbi zgjatjen SEI |
| 7 | Grupi i parametrave SPS të sekuencës |
| 8 | Grupi i parametrave PPS të imazhit |
| 9 | Ndarësi i aksesit |
| 10 | Fund i sekuencës |
| 11 | Fund i rrjedhës |
| ⊠| ⊠|
Zakonisht, NAL i parë në rrjedhën bit është SPS. Ky lloj NAL është përgjegjës për informimin mbi variablat e zakonshme të kodimit, si profili, niveli, rezolucioni dhe të tjera.
Nëse e injorojmë markerin e parë të sinkronizimit, mund të dekodojmë bajtin e parë për të mësuar se çfarë lloji NAL është i pari.
Për shembull, bajti i parë pas markerit të sinkronizimit është i barabartë me 01100111, ku biti i parë (0) ndodhet në fushën forbidden_zero_bit. Dy bitët e ardhshëm (11) na informojnë për fushën nal_ref_idc, e cila tregon nëse ky NAL është një fushë referuese apo jo. Dhe pesë bitët e tjerë (00111) na informojnë për fushën nal_unit_type, në këtë rast është blloku SPS (7) NAL.
Bajti i dytë (binary=01100100, hex=0x64, dec=100) në SPS NAL është fusha profile_idc, e cila tregon profilin që përdori koduesi. Në këtë rast, përdorej profili i kufizuar i lartë (dmth, profili i lartë pa mbështetje për segmentin B me dy drejtime).
Nëse shqyrtojmë specifikimin e rrjedhës bit 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ë hedhim një vështrim në 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, do të marrim rezolucionin. Mund ta 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, për të kursyer hapësirë, në vend që të kodojmë 1920, e bëmë këtë me 119.
Nëse vazhdojmë të kontrollojmë videon tonë të krijuar në formë binarike (për shembull: xxd -b -c 11 v/minimal_yuv420.h264), mund të kalojmë në NAL-in e fundit, i cili është vetë kadri.
Këtu shohim gjashtë vlerat e para të bajtave: 01100101 10001000 10000100 00000000 00100001 11111111. Duke qenë se dihet se bajti i parë tregon tipin e NAL, në këtë rast (00101) është fraksioni IDR (5), dhe atëherë mund të hulumtojmë më tej:
Duke përdorur informacionin e specifikimit, mund të dekodojmë llojin e fraksionit (slice_type) dhe numrin e kadrit (frame_num) midis 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 nevojitet të dekodojmë fraksionin, duke përdorur një dekoder të veçantë, të bazuar në . Kjo metodë është shumë efektive për kodimin e vlerave të variablave, veçanërisht kur ka shumë vlera standarde.
Vlerat slice_type dhe frame_num e këtij video janë 7 (fragments I) dhe 0 (kadrin e parë).
Biti i rrjedhës mund të konsiderohet si një protokoll. Nëse dëshironi të dini më shumë rreth bitit të rrjedhës, duhet të referoheni në specifikimin ITU H.264. Ja një makrodiagramë që tregon se ku ndodhen të dhënat e imazhit (YUV në formë të kompresuar).
Mund tĂ« eksploroni edhe rrjedha tĂ« tjera bitĂ«sh, si VP9, H.265 (HEVC) ose madje edhe rrjedhĂ«n tonĂ« tĂ« re mĂ« tĂ« mirĂ« AV1. Ato janĂ« tĂ« ngjashme? Jo, por duke kuptuar tĂ« paktĂ«n njĂ«rĂ«n â Ă«shtĂ« shumĂ« mĂ« e lehtĂ« tĂ« kuptosh tĂ« tjerat.
Dëshironi të praktikoni? Eksploroni rrjedhën e të dhënave H.264
Mund tĂ« gjeneroni njĂ« video me njĂ« kadr dhe tĂ« pĂ«rdorni MediaInfo pĂ«r tĂ« analizuar rrjedhĂ«n e bitĂ«ve H.264. NĂ« fakt, sâka asgjĂ« qĂ« ndalon tĂ« shqyrtoni edhe 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 e kam thënë që programi është me pagesë, por ka një version provues falas, me kufizim në 10 kadrë?).
PĂ«rmbledhje
Vlen të theksohet se shumë kodekë të sotëm përdorin të njëjtën model, që sapo studiuam. Ja, le të shikojmë në diagramin e kodekut video Thor. Ai përmban të gjitha hapat që kemi kaluar. Qëllimi i këtij shënimi është që ju, të paktën, të kuptoni më mirë novacionet dhe dokumentacionin në këtë fushë.
Më parë llogaritëm 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ë kemi shqyrtuar në këtë artikull (parashikimi ndër-kadrov, parashikimi i brendshëm, transformimi, quantizimi, kodimi i entropisë etj.), mund të arrijmë (duke marre parasysh që harxhojmë 0.031 bit për piksel), një video mjaft të kënaqshme që zë vetëm 367.82 MB, e jo 139 GB memorie.
Si e arrin H.265 një shkallë më të lartë kompresimi se H.264?
Tani, kur dihet më shumë rreth mënyrës se si funksionojnë kodekët, është më e lehtë të kuptohet se si kodekët e rinj mund të ofrojnë rezolucione më të larta me më pak bita.
Kur krahasojmë AVC dhe HEVC, është e rëndësishme të mos harrojmë se kjo është pothuajse gjithmonë një zgjedhje midis një ngarkese më të madhe për CPU dhe shkallës së kompresimit.
HEVC ka më shumë mundësi ndarjesh (dhe nënndarjesh) se AVC, më shumë drejtime të parashikimit të brendshëm, kodim më të përmirësuar të entropisë dhe shumë më tepër. Të gjitha këto përmirësime e bënë H.265 të aftë të comprimojë 50% më shumë se H.264.
Pjesa e parë:
Burimi: habr.com
