Lehenengo zatia:
Zer? Bideo-kodeka bideo digitala konprimitzen edo/eta deskonprimitzen duen software/hardware bat da.
Zertarako? Muga batzuk izan arren, bai banda zabalerari dagokionez, bai
eta datuak biltegiratzeko espazioari dagokionez, merkatuak gero eta kalitate handiagoko bideoa eskatzen du. Gogoratzen al duzu nola kalkulatu genuen azken mezuan 30 fotograma segundoko, 24 bit pixeleko, 480x240 bereizmenarekin? 82,944 Mbit/s jaso genuen konpresiorik gabe. Gaur egun konpresioa da HD/FullHD/4K telebista pantailetara eta Internetera transmititzeko modu bakarra. Nola lortzen da hori? Orain labur ditzagun metodo nagusiak.
Itzulpena EDISON Software-ren laguntzarekin egin da.Konprometituta gaude Eta .
Codec vs edukiontzia
Hasiberriek egiten duten akats arrunta bideo digitalaren kodeka eta bideo digitalaren edukiontzia nahastea da. Edukiontzi bat formatu jakin bat da. Bideo (eta agian audioa) metadatuak dituen bilgarri bat. Konprimitutako bideoa edukiontzi karga gisa har daiteke.
Normalean, bideo-fitxategi baten luzapenak bere edukiontzi mota adierazten du. Adibidez, video.mp4 fitxategia edukiontzi bat izango da ziurrenik MPEG-4 14. zatia, eta video.mkv izeneko fitxategi bat izango da ziurrenik . Kodeka eta edukiontziaren formatua guztiz ziur izateko, erabil dezakezu edo .
Historia apur bat
Iritsi baino lehen Nola?, murgil ditzagun historian pixka bat kodec zaharrago batzuk hobeto ulertzeko.
Bideo-kodeka H.261 1990ean agertu zen (teknikoki - 1988an) eta 64 Kbps-ko datu-transferentzia-tasa batean funtzionatzeko sortu zen. Lehendik ere koloreen azpilaginketa, makroblokeak, etab bezalako ideiak erabiltzen zituen. Bideo-kodeka estandarra 1995ean argitaratu zen H.2632001era arte garatu zena.
Lehen bertsioa 2003an amaitu zen H.264 / AVC. Urte berean, TrueMotion-ek kaleratu zuen doako bideo-kodeka izenekoa VP3. Googlek 2008an erosi zuen konpainia, kaleratuz VP8 urte berean. 2012ko abenduan, Google kaleratu zuen VP9, eta arakatzaileen merkatuaren ΒΎ inguruetan onartzen da (gailu mugikorrak barne).
AV1 kode irekiko eta doako bideo-kodeka berria da Komunikabide Irekietarako Aliantza (AOMedia), enpresa ospetsuenak biltzen dituena, hala nola: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel eta Cisco. Kodecaren lehen bertsioa, 0.1.0, 7ko apirilaren 2016an argitaratu zen.
AV1aren jaiotza
2015 hasieran, Google lanean ari zen VP10Xiph (Mozillarena da) lanean ari zen Daala, eta Cisco-k bere doako bideo-kodeka egin zuen Thor.
Ondoren MPEG LA lehenengo urteko mugak iragarri HEVC (H.265) eta H.8rako baino 264 aldiz handiagoa den kuota, baina laster aldatu zituzten berriro arauak:
urteko mugarik ez,
edukien kuota (sarreren %0,5) eta
unitate-kuota H.10 baino 264 aldiz handiagoa da.
Komunikabide Irekietarako Aliantza alor ezberdinetako enpresek sortu zuten: ekipoen fabrikatzaileak (Intel, AMD, ARM, Nvidia, Cisco), eduki hornitzaileak (Google, Netflix, Amazon), arakatzaileen sortzaileak (Google, Mozilla) eta beste.
Konpainiek helburu komun bat zuten: eskubiderik gabeko bideo-kodeka. Gero agertzen da AV1 patente lizentzia askoz errazagoa duena. Timothy B. Terryberry-k gaur egungo AV1 kontzeptuaren eta bere lizentzia-ereduaren jatorri bihurtu zen aurkezpen harrigarria egin zuen.
Harrituta geldituko zara AV1 kodeka arakatzaile baten bidez azter dezakezula jakiteak (interesa dutenek helbidera jo dezakete).
Kodeka unibertsala
Ikus ditzagun bideo-kodec unibertsalaren azpian dauden mekanismo nagusiak. Kontzeptu horietako gehienak erabilgarriak dira eta kodec modernoetan erabiltzen dira VP9, AV1 ΠΈ HEVC. Azaldutako gauza asko sinplifikatu egingo direla ohartarazten dizut. Batzuetan, mundu errealeko adibideak (H.264rekin bezala) erabiliko dira teknologiak erakusteko.
1. urratsa - irudia zatitzea
Lehenengo urratsa markoa hainbat atal, azpiatal eta haratago banatzea da.
Zertarako? Arrazoi asko daude. Irudi bat zatitzen dugunean, mugimendu-bektorea zehatzago iragar dezakegu zati txiki mugikorretarako sekzio txikiak erabiliz. Atzeko plano estatikorako, berriz, atal handiagoetara muga dezakezu.
Codec-ek normalean atal hauek ataletan (edo zatitan), makroblokeetan (edo kodetze-zuhaitz-blokeetan) eta hainbat azpiataletan antolatzen dituzte. Partizio hauen gehienezko tamaina aldatu egiten da, HEVC-k 64x64 gisa ezartzen du, AVC-k 16x16 erabiltzen duen bitartean, eta azpipartizioak 4x4 tamainara arte banatu daitezke.
Gogoratzen al dituzu azken artikuluko fotograma motak?! Berdin aplika dakioke blokeei, beraz, I-fragmento bat, B-bloke bat, P-makrobloke bat, etab.
Landu nahi duenarentzat, ikusi nola banatzen den irudia atal eta azpiataletan. Horretarako, aurreko artikuluan aipatutakoa erabil dezakezu. (ordaintzen dena, baina lehen 10 fotogrametara mugatzen den doako probako bertsioarekin). Hemen aztertutako atalak VP9:
2. urratsa - aurreikuspena
Behin atalak ditugunean, iragarpen astrologikoak egin ditzakegu. Izan ere INTER iragarpenak transferitu egin behar da higidura-bektoreak eta gainerakoa, eta INTRA aurreikuspenerako transmititzen da iragarpenaren norabidea eta gainontzekoa.
3. urratsa - eraldaketa
Hondar-bloke bat dugunean (aurreikusitako sekzioa β sekzio erreala), eraldatzea posible da, zein pixel baztertu daitezkeen jakitea kalitate orokorra mantenduz. Portaera zehatza ematen duten eraldaketa batzuk daude.
Beste metodo batzuk badaude ere, ikus ditzagun zehatzago. kosinu-eraldaketa diskretua (DCT - bertatik kosinu-eraldaketa diskretua). DCTren funtzio nagusiak:
- Pixel-blokeak maiztasun-koefizienteen tamaina berdineko blokeetan bihurtzen ditu.
- Potentzia kondentsatzen du erredundantzia espaziala ezabatzen laguntzeko.
- Itzulgarritasuna ematen du.
2ko otsailaren 2017an Sintra R.J. (Cintra, RJ) eta Bayer F.M. (Bayer FM) DCT antzeko eraldaketa bati buruzko artikulu bat argitaratu zuen 14 gehikuntza baino ez dituen irudien konpresioarako.
Ez kezkatu puntu bakoitzaren onurak ulertzen ez badituzu. Orain, erabil ditzagun adibide zehatzak haien benetako balioa ikusteko.
Har dezagun 8x8 pixel bloke hau:
Bloke hau 8 x 8 pixeleko irudi honetan errendatzen da:
Aplikatu DCT pixel bloke honi eta lortu 8x8 koefiziente bloke bat:
Eta koefizienteen bloke hau errendatzen badugu, irudi hau lortuko dugu:
Ikusten duzunez, ez du jatorrizko irudiaren itxurarik. Lehen koefizientea beste guztien aldean oso ezberdina dela ikusten duzu. Lehen koefiziente hau DC koefiziente bezala ezagutzen da, sarrerako arrayko lagin guztiak adierazten dituena, batez bestekoa bezalako zerbait.
Koefiziente-bloke honek propietate interesgarri bat du: maiztasun handiko osagaiak maiztasun baxuko osagaiak bereizten ditu.
Irudi batean, potentzia gehiena maiztasun baxuagoetan kontzentratzen da, beraz, irudia bere maiztasun-osagaietan bihurtzen baduzu eta maiztasun handiagoko koefizienteak baztertzen badituzu, irudia deskribatzeko behar den datu kopurua murriztu dezakezu irudiaren kalitatea gehiegi uko egin gabe.
Maiztasunak seinalea zenbateraino aldatzen den adierazten du.
Saia gaitezen proba-kasuan lortutako ezagutza aplikatzen, jatorrizko irudia bere maiztasunera (koefiziente-blokea) bihurtuz DCT erabiliz eta gero garrantzi gutxien duten koefizienteen zati bat baztertuz.
Lehenik eta behin maiztasun-domeinura bihurtzen dugu.
Jarraian, koefizienteen zati bat (%67) baztertzen dugu, batez ere beheko eskuineko zatia.
Azkenik, baztertutako koefiziente-bloke horretatik irudia berreraikitzen dugu (gogoratu, alderantzigarria izan behar dela) eta jatorrizkoarekin alderatzen dugu.
Jatorrizko irudiaren antza duela ikusten dugu, baina jatorrizkoarekiko desberdintasun asko daude. %67,1875 bota genuen eta oraindik jatorrizkoaren antzeko zerbait lortu genuen. Posible zen koefizienteak hobeto baztertzea kalitate hobeagoko irudia lortzeko, baina hori da hurrengo gaia.
Koefiziente bakoitza pixel guztiak erabiliz sortzen da
Garrantzitsua: koefiziente bakoitza ez dago zuzenean pixel batean mapatzen, pixel guztien batura haztatua baizik. Grafiko harrigarri honek lehen eta bigarren koefizienteak indize bakoitzaren pisuak erabiliz nola kalkulatzen diren erakusten du.
DCTa bistaratzen ere saia zaitezke, bertan oinarritutako irudi-eraketa soil bati erreparatuz. Adibidez, hona hemen koefizienteen pisu bakoitza erabiliz sortutako A ikurra:
4. urratsa - kuantizazioa
Aurreko urratsean koefiziente batzuk bota ondoren, azken urratsean (eraldaketa) kuantizazio forma berezi bat egiten dugu. Fase honetan onargarria da informazioa galtzea. Edo, besterik gabe, konpresioa lortzeko koefizienteak kuantizatuko ditugu.
Nola kuantifikatu koefiziente-bloke bat? Metodo errazenetako bat kuantizazio uniformea ββda, bloke bat hartzen dugunean, balio batekin zatitu (10) eta emaitza biribildu.
Koefiziente bloke hau alderantzikatu al dezakegu? Bai, ahal dugu, zatitu genuen balio berarekin biderkatuz.
Planteamendu hau ez da onena, ez baitu koefiziente bakoitzaren garrantzia kontuan hartzen. Balio bakarraren ordez kuantizatzaileen matrize bat erabil liteke, eta matrize honek DCT propietatea ustiatu dezake beheko eskuineko gehiengoa eta goiko ezkerreko gutxiengoa kuantizatuz.
5. urratsa - entropia kodetzea
Datuak kuantifikatu ondoren (irudi-blokeak, zatiak, fotogramak), oraindik galerarik gabe konprimi ditzakegu. Datuak konprimitzeko modu algoritmiko asko daude. Horietako batzuei begirada azkar bat emango diegu, sakonago ulertzeko Understanding Compression: Data Compression for Modern Developers liburua irakur dezakezu ("").
Bideo-kodeketa VLC erabiliz
Demagun karaktere-jario bat dugula: a, e, r ΠΈ t. Taula honetan karaktere bakoitza korronte batean agertzeko maiztasunaren probabilitatea (0tik 1era) azaltzen da.
| a | e | r | t | |
|---|---|---|---|---|
| Probabilitatea | 0,3 | 0,3 | 0,2 | 0,2 |
Kode bitar esklusiboak (ahal izanez gero, txikiak) esleitu diezazkiekegu ziurrenekoei, eta kode handiagoak ez direnei.
| a | e | r | t | |
|---|---|---|---|---|
| Probabilitatea | 0,3 | 0,3 | 0,2 | 0,2 |
| Kode bitarra | 0 | 10 | 110 | 1110 |
Korrontea konprimitzen dugu, pertsonaia bakoitzeko 8 bit gastatuko ditugula suposatuz. Konpresiorik gabe, 24 bit beharko lirateke karaktere bakoitzeko. Karaktere bakoitza bere kodearekin ordezkatzen baduzu, aurrezkiak lortuko dituzu!
Lehenengo urratsa karakterea kodetzea da e, hau da 10 berdina, eta bigarren karakterea da a, gehitzen dena (ez modu matematikoan): [10][0], eta azkenik hirugarren karakterea t, gure azken bit-korronte konprimitua [10][0][1110]-ren berdina bihurtzen duena edo 1001110, 7 bit baino ez ditu behar (originalak baino 3,4 aldiz espazio gutxiago).
Kontuan izan kode bakoitzak aurrizki batekin kode bakarra izan behar duela. zenbaki hauek aurkitzen lagunduko dizu. Metodo hau akatsik gabekoa izan arren, badira oraindik konpresio metodo algoritmiko hau eskaintzen duten bideo-kodekak.
Kodetzaileak zein deskodetzaileak bere kode bitarrekin sinbolo-taula batera sarbidea izan behar dute. Hori dela eta, sarrera gisa taula bat bidaltzea ere beharrezkoa da.
Kodeketa aritmetikoa
Demagun karaktere-jario bat dugula: a, e, r, s ΠΈ t, eta haien probabilitatea taula honetan aurkezten da.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probabilitatea | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Taula hau erabiliz, posible diren karaktere guztiak dituzten barrutiak eraikiko ditugu, kopuru handienaren arabera ordenatuta.
Orain kodetu dezagun hiru karaktereko korronte bat: jan.
Lehenik eta behin, hautatu lehenengo karakterea e, hau da, 0,3 eta 0,6 arteko azpibarrutian (ez barne). Azpibarruti hau hartu eta berriro zatitzen dugu lehengo proportzio berdinetan, baina barruti berri honetarako.
Jarrai dezagun gure korrontea kodetzen jan. Hartu orain bigarren pertsonaia a, hau da, 0,3 eta 0,39 bitarteko azpibarruti berrian dagoena, eta gero hartu gure azken karakterea t eta prozesu bera berriro errepikatuz, 0,354tik 0,372 arteko azken azpibarrutia lortuko dugu.
0,354tik 0,372ra arteko azken azpibarrutiko zenbaki bat hautatu besterik ez dugu egin behar. Aukera dezagun 0,36 (baina azpibarruti honetako beste edozein zenbaki hauta dezakezu). Zenbaki honekin bakarrik gure jatorrizko korrontea berreskuratu ahal izango dugu. Gure korrontea kodetzeko tarteen barruan marra bat marrazten ariko bagina bezala da.
Alderantzizko eragiketa (hau da, deskodetzea) bezain sinplea da: gure 0,36 zenbakiarekin eta gure hasierako barrutiarekin, prozesu bera exekutatu dezakegu. Baina orain, zenbaki hori erabiliz, zenbaki hori erabiliz kodetutako korrontea identifikatzen dugu.
Lehenengo barrutiarekin, gure zenbakia xerrari dagokiola nabarituko dugu, beraz, hau da gure lehen karakterea. Orain azpi-barruti hau berriro zatituko dugu lehengo prozesu bera jarraituz. Hemen ikus dezakezu 0,36 sinboloari dagokiola a, eta prozesua errepikatu ondoren azken karakterera iritsi ginen t (gure jatorrizko kodetutako korrontea osatuz jan).
Kodetzaileak zein deskodetzaileak sinboloen probabilitateen taula izan behar dute, beraz, sarrerako datuetan ere bidaltzea beharrezkoa da.
Nahiko dotorea, ezta? Irtenbide hau asmatu zuena buru-belarri zen. Bideo-kodek batzuek teknika hau erabiltzen dute (edo, behintzat, aukera gisa eskaintzen dute).
Ideia bit-korronte kuantizatu bat galerarik gabe konprimitzea da. Segur aski, artikulu honetan xehetasun, arrazoi, truke-off, etab. Baina garatzailea bazara, gehiago jakin beharko zenuke. Kodec berriak entropia kodetzeko algoritmo desberdinak erabiltzen saiatzen dira, adibidez ANS.
6. urratsa - bitstream formatua
Hori guztia egin ondoren, konprimitutako fotogramak egindako urratsen testuinguruan deskonprimitzea besterik ez da geratzen. Deskodetzaileari berariaz jakinarazi behar zaio kodetzaileak hartutako erabakien berri. Deskodetzaileari beharrezko informazio guztia eman behar zaio: bit-sakonera, kolore-espazioa, bereizmena, iragarpen-informazioa (mugimendu-bektoreak, INTER iragarpen noranzkoa), profila, maila, fotograma-abiadura, fotograma mota, fotograma zenbakia eta askoz gehiago.
Bitstream-ari begirada azkar bat emango diogu H.264. Gure lehen urratsa H.264 bit-stream minimo bat sortzea da (FFmpeg-ek lehenespenez kodetze aukera guztiak gehitzen ditu, hala nola SEI NAL β Zer den pixka bat aurrerago jakingo dugu). Gure biltegia eta FFmpeg erabiliz egin dezakegu.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Komando honek bit-stream gordin bat sortuko du H.264 fotograma batekin, 64Γ64 bereizmenarekin, kolore espazioarekin YUV420. Kasu honetan, hurrengo irudia marko gisa erabiltzen da.
H.264 bit-stream
Standard AVC (H.264) zehazten du informazioa makromarkoetan bidaliko dela (sarearen zentzuan), deiturikoa nal (hau sareko abstrakzio maila da). NAL-en helburu nagusia bideo-aurkezpen "web-erresten" bat eskaintzea da. Estandar honek telebistetan (korronteetan oinarrituta), Interneten (paketeetan oinarrituta) funtzionatu beharko luke.
Sinkronizazio-markatzaile bat dago NAL elementuen mugak definitzeko. Sinkronizazio-token bakoitzak balio bat dauka 0x00 0x00 0x01, lehenengoa izan ezik, berdina dena 0x00 0x00 0x00 0x01. Abian jartzen badugu hexdump sortutako H.264 bit-korronterako, gutxienez hiru NAL eredu identifikatzen ditugu fitxategiaren hasieran.
Esan bezala, deskodetzaileak irudiaren datuak ez ezik, bideoaren xehetasunak, fotograma, koloreak, erabilitako parametroak eta askoz gehiago ezagutu behar ditu. NAL bakoitzaren lehenengo byteak bere kategoria eta mota definitzen ditu.
| NAL motaren identifikatzailea | Description |
|---|---|
| 0 | Mota ezezaguna |
| 1 | IDRrik gabeko irudi-zati kodetua |
| 2 | Kodetutako xerra datuen atala A |
| 3 | Kodetutako xerra datuen atala B |
| 4 | Kodetutako xerra datuen atala C |
| 5 | IDR irudi baten IDR zati kodetua |
| 6 | SEI luzapenari buruzko informazio gehiago |
| 7 | SPS sekuentzia parametro multzoa |
| 8 | PPS irudi-parametroen multzoa |
| 9 | Sarbide-bereizlea |
| 10 | Sekuentziaren amaiera |
| 11 | Hariaren amaiera |
| ... | ... |
Normalean bit-korronte baten lehen NAL da PLC. NAL mota hau kodetze-aldagai arruntei buruz informatzeaz arduratzen da, hala nola profila, maila, bereizmena, etab.
Lehen sinkronizazio-markatzailea saltatzen badugu, lehenengo bytea deskodetu dezakegu zein NAL mota den lehena jakiteko.
Adibidez, sinkronizazio-tokenaren osteko lehen bytea da 01100111, non lehen bit (0) f eremuan dagoorbidden_zero_bit. Hurrengo 2 bit (11) eremua esaten digu nal_ref_idc, NAL hori erreferentzia-eremua den ala ez adierazten duena. Eta gainerako 5 bitak (00111) eremua esaten digu nal_unit_type, kasu honetan SPS blokea da (7) NAL.
Bigarren byte (binary=01100100, hex=0x64, dec=100) SPSn NAL eremua da profile_idc, kodetzaileak erabili duen profila erakusten duena. Kasu honetan, profil altu mugatu bat erabili zen (hau da, B segmentu bikoitzeko euskarririk gabeko profil altua).
Bitstream zehaztapena ikusten baduzu H.264 SPS NALentzat, parametroaren izenaren, kategoriaren eta deskribapenaren balio asko aurkituko ditugu. Esaterako, ikus ditzagun eremuak pic_width_in_mbs_minus_1 ΠΈ pic_height_in_map_units_minus_1.
| Parametroaren izena | kategoria | Description |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Eremu horien balioekin eragiketa matematiko batzuk egiten baditugu, ebazpena lortuko dugu. 1920 x 1080 irudikatu daiteke erabiliz pic_width_in_mbs_minus_1 119 balioarekin ((119 + 1) * makroblokearen_tamaina = 120 * 16 = 1920). Berriz ere, lekua aurrezteko, 1920 kodetu beharrean, 119rekin egin dugu.
Gure sortutako bideoa forma bitarrean egiaztatzen jarraitzen badugu (adibidez: xxd -b -c 11 v/minimal_yuv420.h264), ondoren azken NALera joan zaitezke, hau da, markoa bera.
Hemen bere lehen 6 byteko balioak ikusiko ditugu: 01100101 10001000 10000100 00000000 00100001 11111111. Lehenengo byteak NAL mota adierazten duela ezagutzen denez, kasu honetan (00101) IDR zati bat da (5), eta gero gehiago arakatu dezakezu:
Zehaztapenaren informazioa erabiliz, zati mota deskodetu ahal izango da (xerra_mota) eta fotograma zenbakia (fotograma_zenb) beste alor garrantzitsu batzuen artean.
Eremu batzuen balioak lortzeko (ue(v), me(v), se(v) edo te(v)), zatia deskodetu behar dugu oinarritutako deskodetzaile berezi bat erabiliz . Metodo hau oso eraginkorra da balio aldagaiak kodetzeko, batez ere balio lehenetsi asko daudenean.
esanahia xerra_mota ΠΈ fotograma_zenb bideo honen 7 (I-fragmentoa) eta 0 (lehen fotograma) dira.
Bit stream bat protokolo gisa pentsa daiteke. Bitstream-ari buruz gehiago jakin nahi baduzu, zehaztapena jo beharko zenuke ITU H.264. Hona hemen irudiaren datuak non dauden erakusten duen makro diagrama bat (YUV forma konprimituan).
Beste bit-korronteak aztertu daitezke, adibidez VP9, H.265 (HEVC) edo baita gure bitstream onena berria ere AV1. Antzekoak al dira guztiak? Ez, baina behin gutxienez bat ulertuta, askoz errazagoa da gainerakoak ulertzea.
Praktikatu nahi? Arakatu H.264 bit-streama
Fotograma bakarreko bideo bat sor dezakezu eta MediaInfo erabil dezakezu bit-fluxua aztertzeko H.264. Izan ere, ezerk ez dizu eragozten bit-fluxua aztertzen duen iturburu-kodea begiratzea ere H.264 (AVC).
Praktika egiteko, Intel Video Pro Analyzer erabil dezakezu (esan al dut programa ordainpekoa dela, baina badago doako probako bertsio bat 10 fotogramako mugarekin?).
ΠΠ±Π·ΠΎΡ
Kontuan izan kodec moderno askok aztertu berri dugun eredu bera erabiltzen dutela. Hemen, ikus dezagun bideo-kodekaren bloke-diagrama Thor. Bertan eman ditugun urrats guztiak jasotzen dira. Post honen xedea da gutxienez arlo honetako berrikuntzak eta dokumentazioa hobeto ulertzea.
Aurretik, kalkulatu zen 139 GB-ko espazioa beharko zela ordubeteko bideo-fitxategi bat gordetzeko 720p kalitatean eta 30 fps-n. Artikulu honetan eztabaidatutako metodoak erabiltzen badituzu (fotograma arteko eta barneko iragarpenak, eraldaketa, kuantizazioa, entropia kodetzea, etab.), orduan (pixel bakoitzeko 0,031 bit gastatzen ditugula oinarritzat hartuta) kalitate nahiko egokia duen bideoa lor dezakezu. , 367,82 MB baino ez ditu okupatzen, ez 139 GB memoria.
Nola lortzen du H.265ek H.264 baino konpresio-erlazio hobea?
Kodec-ek nola funtzionatzen duten buruz gehiago dakigunez, errazagoa da kodec berriek bit gutxiagorekin bereizmen handiagoa nola eman dezaketen ulertzea.
Konparatzen badugu AVC ΠΈ HEVC, gogoratzea komeni da hau ia beti PUZaren karga handiagoaren eta konpresio-erlazioaren arteko aukera bat dela.
HEVC baino atal (eta azpiatal) aukera gehiago ditu AVC, barne iragarpen norabide gehiago, entropia kodeketa hobetua eta gehiago. Hobekuntza horiek guztiak egin dira H.265 baino %50 gehiago konprimitzeko gai da H.264.
Lehenengo zatia:
Iturria: www.habr.com