Ensimmäinen osa:
Mitä? Videokoodekki on ohjelmisto/laitteisto, joka pakkaa ja/tai purkaa digitaalisen videon.
Mitä? Tietyistä rajoituksista huolimatta sekä kaistanleveyden että
ja datatallennustilan osalta markkinat vaativat yhä laadukkaampaa videota. Muistatko, kuinka viime viestissä laskimme vaaditun minimin 30 kehykselle sekunnissa, 24 bittiä per pikseliä, resoluutiolla 480x240? Saimme 82,944 Mbit/s ilman pakkausta. Pakkaus on tällä hetkellä ainoa tapa yleisesti lähettää HD/FullHD/4K televisioruutuihin ja Internetiin. Miten tämä saavutetaan? Katsotaanpa nyt lyhyesti tärkeimpiä menetelmiä.
Käännös on tehty EDISON Softwaren tuella.Olemme kihloissa Ja .
Codec vs Container
Aloittelijoiden yleinen virhe on digitaalisen videokoodekin ja digitaalisen videosäiliön sekoittaminen. Säiliö on tietyn muotoinen. Kääri, joka sisältää videon (ja mahdollisesti äänen) metatietoja. Pakattu video voidaan pitää kontin hyötykuormana.
Tyypillisesti videotiedoston tunniste osoittaa sen säiliötyypin. Esimerkiksi tiedosto video.mp4 on luultavasti säilö MPEG-4, osa 14, ja tiedosto nimeltä video.mkv on todennäköisimmin . Voit olla täysin varma koodekin ja säilön muodosta tai .
Vähän historiaa
Ennen kuin pääsemme Miten?, sukeltakaamme hieman historiaan ymmärtääksemme joitain vanhempia koodekkeja hieman paremmin.
Videokoodekki H.261 ilmestyi vuonna 1990 (teknisesti - vuonna 1988) ja luotiin toimimaan 64 Kbps:n tiedonsiirtonopeudella. Se käytti jo ideoita, kuten värin alinäytteenottoa, makrolohkoja jne. Videokoodekkistandardi julkaistiin vuonna 1995 H.263, joka kehittyi vuoteen 2001 asti.
Ensimmäinen versio valmistui vuonna 2003 H.264 / AVC. Samana vuonna TrueMotion julkaisi ilmaisen häviöllisen videokoodekin nimeltä VP3. Google osti yrityksen vuonna 2008 ja julkaisi VP8 samana vuonna. Joulukuussa 2012 Google julkaisi VP9, ja sitä tuetaan noin ¾ selainmarkkinoista (mukaan lukien mobiililaitteet).
AV1 on uusi ilmainen ja avoimen lähdekoodin videokoodekki, jonka on kehittänyt Alliance for Open Media (AO Media), joka sisältää tunnetuimmat yritykset, kuten: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel ja Cisco. Pakkauksenhallinnan ensimmäinen versio, 0.1.0, julkaistiin 7. huhtikuuta 2016.
AV1:n syntymä
Alkuvuodesta 2015 Google työskenteli VP10Xiph (jonka omistaa Mozilla) työskenteli daala, ja Cisco teki oman ilmaisen videokoodekin nimeltä Thor.
Sitten MPEG LA ensimmäisen kerran julkistetut vuosirajat HEVC (H.265) ja 8 kertaa korkeampi maksu kuin H.264:stä, mutta pian he muuttivat sääntöjä uudelleen:
ei vuosirajaa,
sisältömaksu (0,5 % liikevaihdosta) ja
yksikkömaksu on noin 10 kertaa korkeampi kuin H.264.
Alliance for Open Media sen ovat luoneet eri alojen yritykset: laitevalmistajat (Intel, AMD, ARM, Nvidia, Cisco), sisällöntuottajat (Google, Netflix, Amazon), selainvalmistajat (Google, Mozilla) ja muut.
Yrityksillä oli yhteinen tavoite – rojaltivapaa videokoodekki. Sitten ilmestyy AV1 paljon yksinkertaisemmalla patenttilisenssillä. Timothy B. Terryberry piti upean esityksen, josta tuli nykyisen AV1-konseptin ja sen lisenssimallin alkuperä.
Yllätyt, kun tiedät, että voit analysoida AV1-koodekkia selaimen kautta (kiinnostuneet voivat mennä osoitteeseen).
Universaali koodekki
Katsotaanpa yleisen videokoodekin taustalla olevia päämekanismeja. Useimmat näistä käsitteistä ovat hyödyllisiä ja niitä käytetään nykyaikaisissa koodekeissa, kuten VP9, AV1 и HEVC. Varoitan, että monet selitetyistä asioista yksinkertaistuvat. Joskus tekniikan esittelyyn käytetään tosielämän esimerkkejä (kuten H.264:ssä).
1. vaihe - kuvan jakaminen
Ensimmäinen vaihe on jakaa kehys useisiin osiin, alaosiin ja muihin osiin.
Minkä vuoksi? Syitä on monia. Kun jaamme kuvan, voimme ennustaa liikevektorin tarkemmin käyttämällä pieniä osia pienille liikkuville osille. Staattisella taustalla voit rajoittaa itsesi suurempiin osiin.
Koodekit järjestävät tyypillisesti nämä osat osioihin (tai osiin), makrolohkoihin (tai koodauspuulohkoihin) ja useisiin alaosioihin. Näiden osioiden enimmäiskoko vaihtelee, HEVC asettaa sen kooksi 64 x 64, kun taas AVC käyttää kokoa 16 x 16, ja aliosioita voidaan jakaa 4 x 4 kokoon.
Muistatko edellisen artikkelin kehystyypit?! Samaa voidaan soveltaa lohkoihin, joten meillä voi olla I-fragmentti, B-lohko, P-makrolohko jne.
Niille, jotka haluavat harjoitella, katso kuinka kuva on jaettu osiin ja alaosiin. Voit tehdä tämän käyttämällä edellisessä artikkelissa jo mainittua. (se, joka on maksullinen, mutta ilmaisella kokeiluversiolla, joka on rajoitettu 10 ensimmäiseen kehykseen). Tässä analysoidut osiot VP9:
2. vaihe - ennustaminen
Kun meillä on osiot, voimme tehdä niille astrologisia ennusteita. varten INTER ennusteet on siirrettävä liikevektorit ja loput, ja INTRA-ennustusta varten se lähetetään ennusteen suunta ja loput.
3. vaihe - muunnos
Kun meillä on jäännöslohko (ennustettu osa → todellinen osa), on mahdollista muuntaa se siten, että tiedämme, mitkä pikselit voidaan hylätä säilyttäen samalla yleisen laadun. On joitain muunnoksia, jotka tarjoavat tarkan käyttäytymisen.
Vaikka muitakin menetelmiä on, katsotaanpa niitä tarkemmin. diskreetti kosinimuunnos (DCT - alkaen diskreetti kosinimuunnos). DCT:n päätoiminnot:
- Muuntaa pikselilohkot samankokoisiksi taajuuskertoimien lohkoiksi.
- Kondensoi tehoa ja auttaa poistamaan spatiaalista redundanssia.
- Tarjoaa palautuvuuden.
2. helmikuuta 2017 Sintra R.J. (Cintra, RJ) ja Bayer F.M. (Bayer FM) julkaisi artikkelin DCT:n kaltaisesta kuvanpakkauksen muunnoksesta, joka vaatii vain 14 lisäystä.
Älä huoli, jos et ymmärrä kunkin tuotteen etuja. Käytetään nyt konkreettisia esimerkkejä nähdäksemme niiden todellisen arvon.
Otetaan tämä 8x8 pikselilohko:
Tämä lohko hahmonnetaan seuraavaksi 8 x 8 pikselin kuvaksi:
Käytä DCT:tä tähän pikselilohkoon ja hanki 8x8 kerroinlohko:
Ja jos renderöimme tämän kerroinlohkon, saamme seuraavan kuvan:
Kuten näette, se ei näytä alkuperäiseltä kuvalta. Voit nähdä, että ensimmäinen kerroin on hyvin erilainen kuin kaikki muut. Tämä ensimmäinen kerroin tunnetaan DC-kertoimena, joka edustaa kaikkia tulotaulukon näytteitä, jotenkin keskiarvoa.
Tällä kerroinlohkolla on mielenkiintoinen ominaisuus: se erottaa korkeataajuiset komponentit matalataajuisista.
Kuvassa suurin osa tehosta keskittyy alemmille taajuuksille, joten jos muunnat kuvan sen taajuuskomponenteiksi ja hylkäät korkeammat taajuuskertoimet, voit vähentää kuvan kuvaamiseen tarvittavan datan määrää tinkimättä liikaa kuvanlaadusta.
Taajuus tarkoittaa, kuinka nopeasti signaali muuttuu.
Yritetään soveltaa testitapauksessa saatua tietoa muuntamalla alkuperäinen kuva sen taajuudelle (kertoimien lohko) käyttämällä DCT:tä ja hylkäämällä sitten osa vähiten tärkeistä kertoimista.
Ensin muunnetaan se taajuusalueeksi.
Seuraavaksi hylkäämme osan (67 %) kertoimista, pääasiassa oikean alaosan.
Lopuksi rekonstruoimme kuvan tästä hylätystä kerroinlohkosta (muista, sen on oltava käännettävä) ja vertaamme sitä alkuperäiseen.
Näemme, että se muistuttaa alkuperäistä kuvaa, mutta siinä on monia eroja alkuperäiseen verrattuna. Heitimme 67,1875% ja saimme silti jotain alkuperäistä muistuttavaa. Kertoimet oli mahdollista hylätä harkitummin saadakseen vielä paremman kuvan, mutta se on seuraava aihe.
Jokainen kerroin luodaan käyttämällä kaikkia pikseleitä
Tärkeää: kutakin kerrointa ei ole kuvattu suoraan yhteen pikseliin, vaan se on kaikkien pikselien painotettu summa. Tämä hämmästyttävä kaavio näyttää, kuinka ensimmäinen ja toinen kerroin lasketaan käyttämällä kunkin indeksin ainutlaatuisia painoja.
Voit myös yrittää visualisoida DCT:tä katsomalla siihen perustuvaa yksinkertaista kuvanmuodostusta. Esimerkiksi tässä on symboli A, joka on luotu käyttämällä kutakin kertoimen painoa:
4. vaihe - kvantisointi
Kun olemme heittäneet pois joitain kertoimia edellisessä vaiheessa, viimeisessä vaiheessa (muunnos) suoritamme erityisen kvantisoinnin. Tässä vaiheessa tietojen menettäminen on hyväksyttävää. Tai yksinkertaisemmin, kvantisoimme kertoimet kompression saavuttamiseksi.
Kuinka voit kvantisoida kertoimien lohkon? Yksi yksinkertaisimmista menetelmistä on tasainen kvantisointi, kun otamme lohkon, jaetaan se yhdellä arvolla (10:llä) ja pyöristetään tulos.
Voimmeko kääntää tämän kertoimien lohkon? Kyllä, voimme kertoa samalla arvolla, jolla jaoimme.
Tämä lähestymistapa ei ole paras, koska siinä ei oteta huomioon kunkin kertoimen merkitystä. Voidaan käyttää kvantisoijien matriisia yhden arvon sijasta, ja tämä matriisi voisi hyödyntää DCT-ominaisuutta kvantisoimalla suurimman osan oikeasta alaosasta ja vähemmistön vasemmasta yläkulmasta.
Vaihe 5 - entropiakoodaus
Kun olemme kvantisoineet tiedot (kuvalohkot, fragmentit, kehykset), voimme silti pakata sen häviöttömästi. Tietojen pakkaamiseen on monia algoritmisia tapoja. Aiomme tarkastella nopeasti joitain niistä. Syvempää ymmärtämistä varten voit lukea kirjan Understanding Compression: Data Compression for Modern Developers ("").
Videon koodaus VLC:tä käyttäen
Oletetaan, että meillä on joukko hahmoja: a, e, r и t. Tässä taulukossa on esitetty todennäköisyys (välillä 0-1), kuinka usein kukin merkki esiintyy virrassa.
| a | e | r | t | |
|---|---|---|---|---|
| todennäköisyys | 0,3 | 0,3 | 0,2 | 0,2 |
Voimme antaa yksilöllisiä binäärikoodeja (mieluiten pieniä) todennäköisimpiin ja suurempia koodeja vähemmän todennäköisimpiin.
| a | e | r | t | |
|---|---|---|---|---|
| todennäköisyys | 0,3 | 0,3 | 0,2 | 0,2 |
| Binäärikoodi | 0 | 10 | 110 | 1110 |
Pakkaamme streamin olettaen, että kulutamme lopulta 8 bittiä jokaista hahmoa kohden. Ilman pakkausta tarvitaan 24 bittiä per merkki. Jos korvaat jokaisen merkin sen koodilla, saat säästöjä!
Ensimmäinen askel on koodata merkki e, joka on yhtä suuri kuin 10, ja toinen merkki on a, joka lisätään (ei matemaattisesti): [10][0] ja lopuksi kolmas merkki t, mikä tekee lopullisesta pakatusta bittivirrasta yhtä suureksi kuin [10][0][1110] tai 1001110, joka vaatii vain 7 bittiä (3,4 kertaa vähemmän tilaa kuin alkuperäinen).
Huomaa, että jokaisen koodin on oltava yksilöllinen koodi, jossa on etuliite. auttaa sinua löytämään nämä numerot. Vaikka tämä menetelmä ei ole vailla puutteita, on videokoodekkeja, jotka tarjoavat edelleen tämän algoritmisen menetelmän pakkausta varten.
Sekä kooderilla että dekooderilla on oltava pääsy symbolitaulukkoon binäärikoodeineen. Siksi syötteenä on myös lähetettävä taulukko.
Aritmeettinen koodaus
Oletetaan, että meillä on joukko hahmoja: a, e, r, s и t, ja niiden todennäköisyys on esitetty tässä taulukossa.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| todennäköisyys | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Tämän taulukon avulla rakennamme alueita, jotka sisältävät kaikki mahdolliset merkit, lajiteltuina suurimman numeron mukaan.
Koodataan nyt kolmen merkin virta: syödä.
Valitse ensin ensimmäinen merkki e, joka on alialueella 0,3 - 0,6 (ei sisällä). Otamme tämän alialueen ja jaamme sen uudelleen samoissa suhteissa kuin ennen, mutta tälle uudelle alueelle.
Jatketaan striimimme koodaamista syödä. Ota nyt toinen merkki a, joka on uudella alialueella 0,3–0,39, ja ota sitten viimeinen merkki t ja toistamalla sama prosessi uudelleen, saamme lopullisen alialueen 0,354 - 0,372.
Meidän on vain valittava numero viimeiseltä alaväliltä 0,354 - 0,372. Valitaan 0,36 (mutta voit valita minkä tahansa muun luvun tältä alaalueelta). Vain tällä numerolla voimme palauttaa alkuperäisen streamimme. Tuntuu kuin piirtäisimme viivan alueiden sisälle koodataksemme streamimme.
Käänteinen toiminta (eli dekoodaus) on aivan yhtä yksinkertainen: voimme suorittaa saman prosessin numerollamme 0,36 ja aloitusvälillämme. Mutta nyt, käyttämällä tätä numeroa, tunnistamme tällä numerolla koodatun streamin.
Ensimmäisellä alueella huomaamme, että numeromme vastaa siivua, joten tämä on ensimmäinen merkkimme. Nyt jaamme tämän alialueen uudelleen noudattamalla samaa prosessia kuin aiemmin. Tästä näet, että 0,36 vastaa symbolia a, ja prosessin toistamisen jälkeen saavuimme viimeiseen merkkiin t (muodostaa alkuperäisen koodatun streamimme syödä).
Sekä kooderissa että dekooderissa tulee olla symbolien todennäköisyystaulukko, joten se on lähetettävä myös syöttötiedoissa.
Aika tyylikäs, eikö? Kuka tahansa tämän ratkaisun keksi, oli pirun älykäs. Jotkut videokoodekit käyttävät tätä tekniikkaa (tai ainakin tarjoavat sen lisävarusteena).
Ideana on pakata kvantisoitu bittivirta häviöttömästi. Tästä artikkelista puuttuu varmasti paljon yksityiskohtia, syitä, kompromisseja jne. Mutta jos olet kehittäjä, sinun pitäisi tietää enemmän. Uudet koodekit yrittävät käyttää erilaisia entropiakoodausalgoritmeja, kuten ANS.
Vaihe 6 - bittivirtamuoto
Kun kaikki tämä on tehty, ei jää enää muuta kuin purkaa pakatut kehykset suoritettujen vaiheiden yhteydessä. Dekooderille on ilmoitettava nimenomaisesti kooderin tekemistä päätöksistä. Dekooderissa on oltava kaikki tarvittavat tiedot: bittisyvyys, väriavaruus, resoluutio, ennustetiedot (liikevektorit, suunta INTER-ennustus), profiili, taso, kuvataajuus, kehystyyppi, kehysnumero ja paljon muuta.
Katsomme nopeasti bittivirtaa H.264. Ensimmäinen askel on luoda minimaalinen H.264-bittivirta (FFmpeg oletusarvoisesti lisää kaikki koodausvaihtoehdot, kuten SEI NAL - Selvitämme vähän kauempana, mikä se on). Voimme tehdä tämän käyttämällä omaa arkistoamme ja FFmpegiä.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Tämä komento luo raakabittivirran H.264 yhdellä kehyksellä, 64×64 resoluutiolla, väriavaruudella YUV420. Tässä tapauksessa seuraavaa kuvaa käytetään kehyksenä.
H.264-bittivirta
Standardi AVC (H.264) määrittää, että tiedot lähetetään makrokehyksissä (verkon merkityksessä), kutsutaan AT (tämä on verkon abstraktiotaso). NAL:n päätavoitteena on tarjota "verkkoystävällinen" videoesitys. Tämän standardin pitäisi toimia televisioissa (stream-pohjainen), Internetissä (pakettipohjainen).
NAL-elementtien rajat määritetään synkronointimerkinnällä. Jokainen synkronointitunnus sisältää arvon 0x00 0x00 0x01, paitsi aivan ensimmäinen, joka on yhtä suuri 0x00 0x00 0x00 0x01. Jos käynnistämme hexdump luodulle H.264-bittivirralle tunnistamme vähintään kolme NAL-mallia tiedoston alussa.
Kuten todettiin, dekooderin täytyy tietää kuvatietojen lisäksi myös videon yksityiskohdat, kehys, värit, käytetyt parametrit ja paljon muuta. Jokaisen NAL:n ensimmäinen tavu määrittää sen kategorian ja tyypin.
| NAL-tyypin tunniste | Kuvaus |
|---|---|
| 0 | Tuntematon tyyppi |
| 1 | Koodattu kuvafragmentti ilman IDR:ää |
| 2 | Koodattu siivutietoosio A |
| 3 | Koodattu siivutietoosio B |
| 4 | Koodattu siivutietoosio C |
| 5 | IDR-kuvan koodattu IDR-fragmentti |
| 6 | Lisätietoja SEI-laajennuksesta |
| 7 | SPS-sekvenssin parametriasetus |
| 8 | Joukko PPS-kuvaparametreja |
| 9 | Pääsyn erotin |
| 10 | Sarjan loppu |
| 11 | Langan loppu |
| ... | ... |
Tyypillisesti bittivirran ensimmäinen NAL on PLC. Tämän tyyppinen NAL vastaa yleisten koodausmuuttujien, kuten profiilin, tason, resoluution jne., tiedottamisesta.
Jos ohitamme ensimmäisen synkronointimerkin, voimme purkaa ensimmäisen tavun selvittääksemme, mikä NAL-tyyppi on ensimmäinen.
Esimerkiksi ensimmäinen tavu synkronointitunnuksen jälkeen on 01100111, missä ensimmäinen bitti (0) on kentässä forbidden_zero_bit. Seuraavat 2 bittiä (11) kertoo meille kentän nal_ref_idc, joka osoittaa, onko tämä NAL viitekenttä vai ei. Ja loput 5 bittiä (00111) kertoo meille kentän nal_unit_type, tässä tapauksessa se on SPS-lohko (7) NAL.
Toinen tavu (binaarinen=01100100, hex=0x64, joulukuu=100) SPS:ssä NAL on kenttä profile_idc, joka näyttää enkooderin käyttämän profiilin. Tässä tapauksessa käytettiin rajoitettua korkeaa profiilia (eli korkeaa profiilia ilman kaksisuuntaista B-segmentin tukea).
Jos katsot bittivirran eritelmiä H.264 SPS NAL:lle löydämme monia arvoja parametrin nimelle, kategorialle ja kuvaukselle. Katsotaanpa esimerkiksi kenttiä pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Parametrin nimi | Категория | Kuvaus |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
Jos suoritamme joitain matemaattisia operaatioita näiden kenttien arvoilla, saamme resoluution. Yksi voi edustaa 1920 x 1080 käyttämällä pic_width_in_mbs_minus_1 jonka arvo on 119 ((119 + 1) * makrolohkon_koko = 120 * 16 = 1920). Jälleen, tilan säästämiseksi, 1920-koodauksen sijaan teimme sen 119:llä.
Jos jatkamme luomamme videon tarkistamista binäärimuodossa (esimerkiksi: xxd -b -c 11 v/minimal_yuv420.h264), voit siirtyä viimeiseen NAL:iin, joka on itse kehys.
Tässä näemme sen ensimmäiset 6 tavun arvot: 01100101 10001000 10000100 00000000 00100001 11111111. Koska ensimmäisen tavun tiedetään osoittavan NAL-tyyppiä, tässä tapauksessa (00101) on IDR-fragmentti (5), ja voit sitten tutkia sitä tarkemmin:
Spesifikaatiotietojen avulla on mahdollista purkaa fragmenttityyppi (slice_type) ja kehyksen numero (frame_num) muiden tärkeiden alojen joukossa.
Saadaksesi joidenkin kenttien arvot (ue(v), me(v), se(v) tai te(v)), meidän on purettava fragmentti käyttämällä erityistä dekooderia, joka perustuu . Tämä menetelmä on erittäin tehokas muuttujien arvojen koodaamiseen, varsinkin kun oletusarvoja on useita.
Arvot slice_type и frame_num Tästä videosta 7 (I-fragmentti) ja 0 (ensimmäinen ruutu).
Bittivirtaa voidaan pitää protokollana. Jos haluat tietää enemmän bittivirrasta, sinun tulee katsoa spesifikaatiota ITU H.264. Tässä on makrokaavio, joka näyttää missä kuvatiedot ovat (YUV puristetussa muodossa).
Muita bittivirtoja voidaan tutkia, esim VP9, H.265 (HEVC) tai jopa uusi paras bittivirta AV1. Ovatko ne kaikki samanlaisia? Ei, mutta kun ymmärrät ainakin yhden, on paljon helpompi ymmärtää loput.
Haluatko harjoitella? Tutustu H.264-bittivirtaan
Voit luoda yhden kehyksen videon ja käyttää MediaInfoa bittivirran tutkimiseen H.264. Itse asiassa mikään ei estä sinua edes katsomasta lähdekoodia, joka analysoi bittivirran H.264 (AVC).
Käytännössä voit käyttää Intel Video Pro Analyzeria (sanoinko jo, että ohjelma on maksullinen, mutta siellä on ilmainen kokeiluversio, jonka enimmäismäärä on 10 kehystä?).
Arvostelu
Huomaa, että monet nykyaikaiset koodekit käyttävät samaa mallia, jota juuri tutkimme. Katsotaanpa tässä videokoodekin lohkokaaviota Thor. Se sisältää kaikki vaiheet, jotka olemme käyneet läpi. Tämän viestin tarkoitus on ainakin antaa sinulle parempi käsitys tämän alan innovaatioista ja dokumentaatiosta.
Aikaisemmin laskettiin, että tunnin mittaisen videotiedoston tallentamiseen 139p-laadulla ja 720 fps:llä tarvittaisiin 30 Gt levytilaa. Jos käytät tässä artikkelissa käsiteltyjä menetelmiä (kehysten väliset ja sisäiset ennusteet, muunnos, kvantisointi, entropiakoodaus jne.), voit saavuttaa (sen perusteella, että käytämme 0,031 bittiä pikseliä kohti), videon melko tyydyttävä laatu, vie vain 367,82 Mt, ei 139 Gt muistia.
Kuinka H.265 saavuttaa paremman pakkaussuhteen kuin H.264?
Nyt kun tiedämme enemmän koodekkien toiminnasta, on helpompi ymmärtää, kuinka uudemmat koodekit voivat tarjota korkeamman resoluution pienemmillä biteillä.
Jos verrataan AVC и HEVC, on syytä muistaa, että tämä on melkein aina valinta suuremman suorittimen kuormituksen ja pakkaussuhteen välillä.
HEVC on enemmän osio- (ja alaosio) vaihtoehtoja kuin AVC, enemmän sisäisiä ennustusohjeita, parannettu entropiakoodaus ja paljon muuta. Kaikki nämä parannukset on tehty H.265 pystyy puristamaan 50 % enemmän kuin H.264.
Ensimmäinen osa:
Lähde: will.com