Unua parto:
Kio Videokodeko estas peco de programaro/aparataro kiu kunpremas kaj/aŭ malkunpremas ciferecan videon.
Por kio? Malgraŭ certaj limigoj kaj laŭ bendolarĝo kaj
kaj koncerne datumstokan spacon, la merkato postulas ĉiam pli pli altkvalitan videon. Ĉu vi memoras kiel en la lasta afiŝo ni kalkulis la bezonatan minimumon por 30 kadroj por sekundo, 24 bitoj por pikselo, kun rezolucio de 480x240? Ni ricevis 82,944 Mbit/s sen kunpremado. Kunpremado estas nuntempe la nura maniero por ĝenerale transdoni HD/FullHD/4K al televidaj ekranoj kaj interreto. Kiel tio estas atingita? Nun ni mallonge rigardu la ĉefajn metodojn.
La traduko estis farita kun la subteno de EDISON Software.Ni estas engaĝitaj Kaj .
Kodeko vs Ujo
Ofta eraro kiun novuloj faras estas konfuzi ciferecan videokodekon kaj ciferecan videoujon. Ujo estas certa formato. Envolvaĵo enhavanta video (kaj eventuale aŭd) metadatenojn. La kunpremita video povas esti opiniita kiel ujo utila ŝarĝo.
Tipe, la etendo de videodosiero indikas ĝian specon de ujo. Ekzemple, la dosiero video.mp4 verŝajne estas ujo MPEG-4 Parto 14, kaj dosiero nomita video.mkv plej verŝajne . Por esti tute certa pri la kodeko kaj ujo-formato, vi povas uzi aŭ .
Iom da historio
Antaŭ ol ni atingos Kiel?, ni iomete plonĝu en la historion por kompreni iom pli bone kelkajn pli malnovajn kodekojn.
Videokodeko H.261 aperis en 1990 (teknike - en 1988) kaj estis kreita por funkcii kun transdono de datumoj de 64 Kbps. Ĝi jam uzis ideojn kiel kolora subspecimenado, makroblokoj ktp. La videokodeknormo estis publikigita en 1995 H.263, kiu formiĝis ĝis 2001.
La unua versio estis kompletigita en 2003 H.264 / AVC. Tiun saman jaron, TrueMotion publikigis sian liberan perdan videokodekon nomitan VP3. Google aĉetis la firmaon en 2008, liberigante VP8 en la sama jaro. En decembro 2012, Google publikigis VP9, kaj ĝi estas subtenata en ĉirkaŭ ¾ de la retumila merkato (inkluzive de porteblaj aparatoj).
AV1 estas nova senpaga kaj malfermfonta videokodeko evoluigita de Alianco por Malferma Amaskomunikilaro (AOMedia), kiu inkluzivas la plej famajn kompaniojn, kiel: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel kaj Cisco. La unua versio de la kodeko, 0.1.0, estis publikigita la 7-an de aprilo 2016.
Naskiĝo de AV1
Komence de 2015, Guglo laboris pri tio VP10Xiph (kiu estas posedata de Mozilla) laboris pri Daala, kaj Cisco faris sian propran liberan videokodekon nomitan Thor.
tiam MPEG LA unue anoncis jarajn limojn por HEVC (H.265) kaj kotizo 8 fojojn pli alta ol por H.264, sed ili baldaŭ ŝanĝis la regulojn denove:
neniu jara limo,
enhavkotizo (0,5% de enspezo) kaj
la unuopa kotizo estas ĉirkaŭ 10 fojojn pli alta ol H.264.
Alianco por Malferma Amaskomunikilaro estis kreita de kompanioj el diversaj kampoj: fabrikantoj de ekipaĵoj (Intel, AMD, ARM, Nvidia, Cisco), provizantoj de enhavo (Google, Netflix, Amazon), kreintoj de retumilo (Google, Mozilla) kaj aliaj.
La kompanioj havis komunan celon - senpaga videokodeko. Tiam aperas AV1 kun multe pli simpla patentlicenco. Timothy B. Terryberry faris mirindan prezenton, kiu fariĝis la origino de la nuna AV1-koncepto kaj ĝia licenca modelo.
Vi surprizos scii, ke vi povas analizi la AV1-kodekon per retumilo (la interesiĝantoj povas iri al).
Universala kodeko
Ni rigardu la ĉefajn mekanismojn sub la universala videokodeko. La plej multaj el ĉi tiuj konceptoj estas utilaj kaj estas uzataj en modernaj kodekoj kiel ekzemple VP9, AV1 и HEVC. Mi avertas vin, ke multaj el la klarigitaj aferoj estos simpligitaj. Foje realaj mondaj ekzemploj (kiel kun H.264) estos uzataj por pruvi la teknologion.
1-a paŝo - disigo de la bildo
La unua paŝo estas dividi la kadron en plurajn sekciojn, subsekciojn kaj pretere.
Por kio? Estas multaj kialoj. Kiam ni disigas bildon, ni povas pli precize antaŭdiri la movvektoron uzante malgrandajn sekciojn por malgrandaj moviĝantaj partoj. Dum por statika fono vi povas limigi vin al pli grandaj sekcioj.
Kodekoj tipe organizas tiujn sekciojn en sekciojn (aŭ pecojn), makroblokojn (aŭ kodigajn arbblokojn), kaj multoblajn subsekciojn. La maksimuma grandeco de ĉi tiuj sekcioj varias, HEVC fiksas ĝin al 64x64 dum AVC uzas 16x16, kaj subsekcioj povas esti dividitaj ĝis 4x4 grandecoj.
Ĉu vi memoras la specojn de kadroj de la lasta artikolo?! La sama povas esti aplikata al blokoj, do ni povas havi I-fragmenton, B-blokon, P-makrobblokon, ktp.
Por tiuj, kiuj volas praktiki, rigardu kiel la bildo estas dividita en sekciojn kaj subsekciojn. Por fari tion, vi povas uzi tiun jam menciitan en la antaŭa artikolo. (tiu, kiu estas pagita, sed kun senpaga prova versio, kiu estas limigita al la unuaj 10 kadroj). Sekcioj analizitaj ĉi tie VP9:
2-a paŝo - prognozo
Post kiam ni havas sekciojn, ni povas fari astrologiajn prognozojn por ili. Por INTER-prognozoj devas esti translokigita movaj vektoroj kaj la resto, kaj por INTRA prognozo ĝi estas elsendita prognoza direkto kaj la resto.
3-a paŝo - transformo
Post kiam ni havas restan blokon (antaŭdirita sekcio → reala sekcio), estas eble transformi ĝin tiel ke ni scias kiuj pikseloj povas esti forĵetitaj konservante ĝeneralan kvaliton. Estas iuj transformoj, kiuj provizas la ĝustan konduton.
Kvankam ekzistas aliaj metodoj, ni rigardu ilin pli detale. diskreta kosinus transformo (CSD - de diskreta kosinus transformo). Ĉefaj funkcioj de DCT:
- Konvertas blokojn de pikseloj en samgrandajn blokojn de frekvencaj koeficientoj.
- Kondensigas potencon por helpi forigi spacan redundon.
- Provizas inversigeblecon.
2-a de februaro 2017 Sintra R.J. (Cintra, RJ) kaj Bayer F.M. (Bayer FM) publikigis artikolon pri DCT-simila transformo por bildkunpremado kiu postulas nur 14 aldonojn.
Ne maltrankviliĝu se vi ne komprenas la avantaĝojn de ĉiu objekto. Nun ni uzu specifajn ekzemplojn por vidi ilian realan valoron.
Ni prenu ĉi tiun 8x8-blokon de pikseloj:
Ĉi tiu bloko estas prezentita en la sekvan 8 je 8-pikselan bildon:
Apliku DCT al ĉi tiu bloko de pikseloj kaj ricevu 8x8 blokon de koeficientoj:
Kaj se ni redonas ĉi tiun blokon de koeficientoj, ni ricevos la sekvan bildon:
Kiel vi povas vidi, ĝi ne aspektas kiel la originala bildo. Vi povas vidi, ke la unua koeficiento estas tre malsama de ĉiuj aliaj. Ĉi tiu unua koeficiento estas konata kiel la Dc-koeficiento, kiu reprezentas ĉiujn specimenojn en la eniga tabelo, io kiel mezumo.
Ĉi tiu bloko de koeficientoj havas interesan econ: ĝi apartigas altfrekvencajn komponantojn de malaltfrekvencaj komponantoj.
En bildo, la plej granda parto de la potenco estas koncentrita ĉe pli malaltaj frekvencoj, do se vi konvertas la bildon en ĝiajn frekvenckomponentojn kaj forĵetas la pli altajn frekvenckoeficientojn, vi povas redukti la kvanton da datumoj necesaj por priskribi la bildon sen oferi tro da bildkvalito.
Ofteco rilatas al kiom rapide la signalo ŝanĝiĝas.
Ni provu apliki la sciojn akiritajn en la testkazo konvertante la originan bildon al ĝia frekvenco (bloko de koeficientoj) uzante DCT kaj poste forĵetante parton de la malplej gravaj koeficientoj.
Unue ni konvertas ĝin al la frekvenca domajno.
Poste, ni forĵetas parton (67%) de la koeficientoj, ĉefe la malsupran dekstran parton.
Fine, ni rekonstruas la bildon el ĉi tiu forĵetita bloko de koeficientoj (memoru, ĝi devas esti inversigebla) kaj komparas ĝin kun la originalo.
Ni vidas, ke ĝi similas al la originala bildo, sed estas multaj diferencoj de la originalo. Ni elĵetis 67,1875% kaj ankoraŭ ricevis ion similan al la originalo. Eblis pli penseme forĵeti la koeficientojn por akiri bildon de eĉ pli bona kvalito, sed tio estas sekva temo.
Ĉiu koeficiento estas generita uzante ĉiujn pikselojn
Grava: ĉiu koeficiento ne estas rekte mapita al unu pikselo, sed estas laŭpeza sumo de ĉiuj pikseloj. Ĉi tiu mirinda grafikaĵo montras kiel la unua kaj dua koeficientoj estas kalkulitaj uzante pezojn unikajn al ĉiu indekso.
Vi ankaŭ povas provi bildigi la DCT rigardante simplan bildformadon bazitan sur ĝi. Ekzemple, jen la simbolo A generita uzante ĉiun koeficientan pezon:
4-a paŝo - kvantigo
Post kiam ni elĵetas kelkajn koeficientojn ĉe la antaŭa paŝo, ĉe la lasta paŝo (transformo) ni faras specialan formon de kvantigo. En ĉi tiu etapo estas akcepteble perdi informojn. Aŭ, pli simple, ni kvantigos la koeficientojn por atingi kunpremadon.
Kiel vi povas kvantigi blokon de koeficientoj? Unu el la plej simplaj metodoj estas unuforma kvantigo, kiam ni prenas blokon, dividas ĝin per unu valoro (per 10) kaj rondigas la rezulton.
Ĉu ni povas inversigi ĉi tiun blokon de koeficientoj? Jes, ni povas, multobligante per la sama valoro per kiu ni dividis.
Ĉi tiu aliro ne estas la plej bona ĉar ĝi ne konsideras la gravecon de ĉiu koeficiento. Oni povus uzi matricon de kvantigiloj anstataŭe de ununura valoro, kaj ĉi tiu matrico povus ekspluati la DCT-posedaĵon kvantigante la plimulton de la malsupra dekstro kaj la malplimulto de la supra maldekstro.
Paŝo 5 - entropia kodigo
Post kiam ni kvantigis la datumojn (bildaj blokoj, fragmentoj, kadroj), ni ankoraŭ povas kunpremi ĝin senperde. Estas multaj algoritmaj manieroj kunpremi datumojn. Ni tuj rigardos kelkajn el ili, por pli profunda kompreno vi povas legi la libron Understanding Compression: Data Compression por Modernaj Programistoj ("").
Videokodado uzante VLC
Ni diru, ke ni havas fluon de karakteroj: a, e, r и t. La probablo (inter 0 ĝis 1) de kiom ofte ĉiu signo aperas en rivereto estas prezentita en ĉi tiu tabelo.
| a | e | r | t | |
|---|---|---|---|---|
| Probablo | 0,3 | 0,3 | 0,2 | 0,2 |
Ni povas asigni unikajn binarajn kodojn (prefere malgrandajn) al la plej verŝajnaj, kaj pli grandajn kodojn al la malpli verŝajnaj.
| a | e | r | t | |
|---|---|---|---|---|
| Probablo | 0,3 | 0,3 | 0,2 | 0,2 |
| Binara kodo | 0 | 10 | 110 | 1110 |
Ni kunpremas la fluon, supozante, ke ni finos elspezante 8 bitojn por ĉiu karaktero. Sen kunpremado, 24 bitoj estus bezonataj per signo. Se vi anstataŭigas ĉiun signon per ĝia kodo, vi ricevas ŝparaĵojn!
La unua paŝo estas kodi la karakteron e, kiu estas egala al 10, kaj la dua signo estas a, kiu estas aldonita (ne matematike): [10][0], kaj fine la tria signo t, kiu faras nian finan kunpremitan bitfluon egala al [10][0][1110] aŭ 1001110, kiu postulas nur 7 bitojn (3,4 fojojn malpli da spaco ol la originalo).
Bonvolu noti, ke ĉiu kodo devas esti unika kodo kun prefikso. helpos vin trovi ĉi tiujn nombrojn. Kvankam ĉi tiu metodo ne estas sen difektoj, ekzistas videokodekoj, kiuj ankoraŭ ofertas ĉi tiun algoritman metodon por kunpremado.
Kaj la kodilo kaj la malĉifrilo devas havi aliron al simboltabelo kun siaj binaraj kodoj. Tial ankaŭ necesas sendi tabelon kiel enigaĵon.
Aritmetika kodigo
Ni diru, ke ni havas fluon de karakteroj: a, e, r, s и t, kaj ilia probablo estas prezentita en ĉi tiu tabelo.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probablo | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Uzante ĉi tiun tabelon, ni konstruos gamojn enhavantajn ĉiujn eblajn signojn, ordigitajn laŭ la plej granda nombro.
Nun ni kodu fluon de tri signoj: manĝi.
Unue elektu la unuan signon e, kiu estas en la subintervalo de 0,3 ĝis 0,6 (ne inkluzivante). Ni prenas ĉi tiun subgamon kaj dividas ĝin denove en la samaj proporcioj kiel antaŭe, sed por ĉi tiu nova gamo.
Ni daŭrigu kodi nian rivereton manĝi. Nun prenu la duan karakteron a, kiu estas en la nova subintervalo de 0,3 ĝis 0,39, kaj tiam prenu nian lastan signon t kaj ripetante la saman procezon denove, ni ricevas la finan sub-gamon de 0,354 ĝis 0,372.
Ni nur bezonas elekti nombron en la lasta subgamo de 0,354 ĝis 0,372. Ni elektu 0,36 (sed vi povas elekti ajnan alian nombron en ĉi tiu subintervalo). Nur per ĉi tiu numero ni povos restarigi nian originalan fluon. Estas kvazaŭ ni desegnas linion ene de la intervaloj por kodi nian rivereton.
La inversa operacio (tio estas, malkodigo) estas same simpla: kun nia numero 0,36 kaj nia komenca intervalo, ni povas ruli la saman procezon. Sed nun, uzante ĉi tiun numeron, ni identigas la rivereton kodita uzante ĉi tiun numeron.
Kun la unua gamo, ni rimarkas, ke nia nombro respondas al la tranĉaĵo, tial ĉi tiu estas nia unua signo. Nun ni dividas ĉi tiun sub-gamon denove sekvante la saman procezon kiel antaŭe. Ĉi tie vi povas vidi, ke 0,36 respondas al la simbolo a, kaj ripetante la procezon ni alvenis al la lasta karaktero t (formante nian originalan ĉifritan fluon manĝi).
Kaj la kodilo kaj la malĉifrilo devas havi tabelon de simbolprobabloj, do necesas sendi ĝin ankaŭ en la enirdatumojn.
Sufiĉe eleganta, ĉu ne? Kiu elpensis ĉi tiun solvon, estis diable saĝa. Iuj videokodekoj uzas ĉi tiun teknikon (aŭ almenaŭ proponas ĝin kiel opcion).
La ideo estas senperde kunpremi kvantigitan bitfluon. Verŝajne ĉi tiu artikolo mankas tunoj da detaloj, kialoj, kompromisoj, ktp. Sed se vi estas programisto, vi devus scii pli. Novaj kodekoj provas uzi malsamajn entropiajn kodigajn algoritmojn kiel ekzemple ANS.
Paŝo 6 - bitstream formato
Post fari ĉion ĉi, restas nur malpaki la kunpremitajn kadrojn en la kunteksto de la faritaj paŝoj. La malĉifrilo devas esti eksplicite informita pri la decidoj faritaj de la kodilo. La malĉifrilo devas esti provizita per ĉiuj necesaj informoj: bitprofundo, kolorspaco, rezolucio, prognozaj informoj (movvektoroj, direkta INTER-prognozo), profilo, nivelo, framfrekvenco, framtipo, framnumero kaj multe pli.
Ni rigardos la bitfluon H.264. Nia unua paŝo estas krei minimuman H.264-bitfluon (FFmpeg defaŭlte aldonas ĉiujn kodajn opciojn kiel ekzemple SEI NAL — ni ekscios, kio ĝi estas iom pli). Ni povas fari tion uzante nian propran deponejon kaj FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Ĉi tiu komando generos krudan bitfluon H.264 kun unu kadro, 64×64 rezolucio, kun kolorspaco YUV420. En ĉi tiu kazo, la sekva bildo estas uzata kiel kadro.
H.264 bitfluo
Norma AVC (H.264) determinas ke informoj estos senditaj en makrokadroj (en la retosenco), nomitaj AT (ĉi tio estas reto abstrakta nivelo). La ĉefa celo de NAL estas provizi "ret-amika" videoprezento. Ĉi tiu normo devus funkcii ĉe televidiloj (fluo-bazita), la Interreto (pako-bazita).
Estas sinkroniga markilo por difini la limojn de NAL-elementoj. Ĉiu sinkroniga ĵetono enhavas valoron 0x00 0x00 0x01, krom la unua, kiu egalas al 0x00 0x00 0x00 0x01. Se ni lanĉos hexdump por la generita H.264-bitfluo, ni identigas almenaŭ tri NAL-ŝablonojn komence de la dosiero.
Kiel dirite, la malĉifrilo devas scii ne nur la bildajn datumojn, sed ankaŭ la detalojn de la video, kadro, koloroj, parametroj uzataj kaj multe pli. La unua bajto de ĉiu NAL difinas ĝian kategorion kaj tipon.
| NAL-tipa identigilo | Priskribo |
|---|---|
| 0 | Nekonata tipo |
| 1 | Ĉifrita bildfragmento sen IDR |
| 2 | Kodigita tranĉaĵo datumoj sekcio A |
| 3 | Kodigita tranĉaĵo datumoj sekcio B |
| 4 | Kodigita tranĉaĵo datumoj sekcio C |
| 5 | Ĉifrita IDR-fragmento de IDR-bildo |
| 6 | Pliaj informoj pri la etendo de SEI |
| 7 | SPS-Sekvenca Parametro-Aro |
| 8 | Aro de PPS-bildaj parametroj |
| 9 | Aliro apartigilo |
| 10 | Fino de sekvenco |
| 11 | Fino de fadeno |
| ... | ... |
Tipe la unua NAL de bitfluo estas SPS. Ĉi tiu speco de NAL respondecas pri informado pri oftaj kodaj variabloj kiel profilo, nivelo, rezolucio ktp.
Se ni preterlasas la unuan sinkronigan markilon, ni povas malkodi la unuan bajton por ekscii, kiu NAL-tipo estas la unua.
Ekzemple, la unua bajto post la sinkroniga ĵetono estas 01100111, kie la unua bito (0) estas en kampo forbidden_zero_bit. Sekvaj 2 bitoj (11) rakontas al ni la kampon nal_ref_idc, kiu indikas ĉu ĉi tiu NAL estas referenca kampo aŭ ne. Kaj la ceteraj 5 bitoj (00111) rakontas al ni la kampon nal_unit_tipo, ĉi-kaze ĝi estas la SPS-bloko (7) NAL.
Dua bajto (duumaj=01100100, hex=0x64, Dec=100) en SPS NAL estas la kampo profile_idc, kiu montras la profilon kiun la kodilo uzis. En ĉi tiu kazo, limigita alta profilo estis uzita (te, alta profilo sen dudirekta B-segmento subteno).
Se vi rigardas la bitstream-specifon H.264 por SPS NAL, ni trovos multajn valorojn por parametronomo, kategorio kaj priskribo. Ekzemple, ni rigardu la kampojn pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Parametronomo | kategorio | Priskribo |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue (v) |
| pic_height_in_map_units_minus_1 | 0 | ue (v) |
Se ni faras iujn matematikajn operaciojn kun la valoroj de ĉi tiuj kampoj, ni ricevos rezolucion. Oni povas reprezenti 1920 x 1080 uzante pic_width_in_mbs_minus_1 kun valoro de 119 ((119 + 1) * makrobloko_grandeco = 120 * 16 = 1920). Denove, por ŝpari spacon, anstataŭ kodi 1920, ni faris ĝin per 119.
Se ni daŭre kontrolas nian kreitan videon en binara formo (ekzemple: xxd -b -c 11 v/minimal_yuv420.h264), tiam vi povas iri al la lasta NAL, kiu estas la kadro mem.
Ĉi tie ni vidas ĝiajn unuajn 6-bajtajn valorojn: 01100101 10001000 10000100 00000000 00100001 11111111. Ĉar la unua bajto povas indikas la NAL-tipo, ĉi-kaze (00101) estas IDR-fragmento (5), kaj tiam vi povas plu esplori ĝin:
Uzante la specifinformojn, eblos malkodi la fragmentan tipon (tranĉaĵo_tipo) kaj kadra nombro (frame_num) inter aliaj gravaj kampoj.
Por akiri la valorojn de iuj kampoj (ue(v), me(v), se(v) aŭ te(v)), ni devas malkodi la fragmenton uzante specialan malĉifrilon bazitan sur . Ĉi tiu metodo estas tre efika por kodi variajn valorojn, precipe kiam ekzistas multaj defaŭltaj valoroj.
Valoroj tranĉaĵo_tipo и frame_num de ĉi tiu video estas 7 (I-fragmento) kaj 0 (unua kadro).
Bitfluo povas esti opiniita kiel protokolo. Se vi volas scii pli pri la bitfluo, vi devus raporti al la specifo ITU H.264. Jen makrodiagramo montranta kie estas la bildaj datumoj (YUV en kunpremita formo).
Aliaj bitfluoj povas esti ekzamenitaj, kiel ekzemple VP9, H.265 (HEVC) aŭ eĉ nia nova plej bona bitfluo AV1. Ĉu ili ĉiuj similas? Ne, sed kiam vi komprenas almenaŭ unu, estas multe pli facile kompreni la ceterajn.
Ĉu vi volas praktiki? Esploru la H.264-bitfluon
Vi povas generi ununuran kadran videon kaj uzi MediaInfo por ekzameni la bitfluon H.264. Fakte, nenio malhelpas vin eĉ rigardi la fontkodon, kiu analizas la bitfluon H.264 (AVC).
Por praktiko, vi povas uzi Intel Video Pro Analyzer (ĉu mi jam diris, ke la programo estas pagita, sed ekzistas senpaga prova versio kun limo de 10 kadroj?).
trarigardo
Notu, ke multaj modernaj kodekoj uzas la saman modelon, kiun ni ĵus studis. Ĉi tie, ni rigardu la blokdiagramon de la videokodeko Thor. Ĝi enhavas ĉiujn paŝojn, kiujn ni trapasis. La tuta celo de ĉi tiu afiŝo estas almenaŭ doni al vi pli bonan komprenon pri la novigoj kaj dokumentado en ĉi tiu areo.
Antaŭe, oni kalkulis, ke 139 GB da diskospaco estus bezonata por stoki videodosieron daŭran unu horon je 720p kvalito kaj 30 fps. Se vi uzas la metodojn diskutitajn en ĉi tiu artikolo (inter-kadraj kaj internaj prognozoj, transformo, kvantigo, entropia kodado, ktp.), tiam vi povas atingi (surbaze de la fakto, ke ni elspezas 0,031 bitojn por pikselo), videon de sufiĉe kontentiga kvalito, okupante nur 367,82 MB, ne 139 GB da memoro.
Kiel H.265 atingas pli bonan kunpremoproporcion ol H.264?
Nun kiam ni scias pli pri kiel funkcias kodekoj, estas pli facile kompreni kiel pli novaj kodekoj povas liveri pli altajn rezoluciojn kun malpli da bitoj.
Se ni komparas AVC и HEVC, Indas memori, ke ĉi tio preskaŭ ĉiam estas elekto inter pli granda CPU-ŝarĝo kaj kunprema proporcio.
HEVC havas pli da sekcio (kaj subsekcio) opcioj ol AVC, pli internaj antaŭdiroj, plibonigita entropia kodigo, kaj pli. Ĉiuj ĉi tiuj plibonigoj estis faritaj H.265 kapabla kunpremi 50% pli ol H.264.
Unua parto:
fonto: www.habr.com