Bagian pertama:
Apa? Codec video adalah perangkat lunak/perangkat keras yang mengompresi dan/atau mendekompresi video digital.
Untuk apa? Meskipun ada keterbatasan tertentu baik dari segi bandwidth dan
dan dalam hal ruang penyimpanan data, pasar menuntut kualitas video yang semakin tinggi. Ingat bagaimana di postingan terakhir kami menghitung persyaratan minimum untuk 30 frame per detik, 24 bit per piksel, dengan resolusi 480x240? Kami menerima 82,944 Mbit/s tanpa kompresi. Kompresi saat ini merupakan satu-satunya cara untuk mentransmisikan HD/FullHD/4K secara umum ke layar televisi dan Internet. Bagaimana hal ini dicapai? Sekarang mari kita lihat secara singkat metode utama.
Terjemahan dibuat dengan dukungan Perangkat Lunak EDISON.Kami bertunangan Dan .
Codec vs Kontainer
Kesalahan umum yang dilakukan pemula adalah membingungkan codec video digital dan wadah video digital. Wadah adalah format tertentu. Pembungkus yang berisi metadata video (dan mungkin audio). Video terkompresi dapat dianggap sebagai muatan kontainer.
Biasanya, ekstensi file video menunjukkan jenis wadahnya. Misalnya, file video.mp4 mungkin merupakan sebuah wadah MPEG-4 Bagian 14, dan kemungkinan besar file bernama video.mkv . Untuk benar-benar yakin dengan codec dan format container, Anda dapat menggunakan ΠΈΠ»ΠΈ .
Sedikit sejarah
Sebelum kita sampai ke sana Bagaimana?, mari kita menyelami sedikit sejarah untuk memahami beberapa codec lama dengan lebih baik.
Kodek video H.261 muncul pada tahun 1990 (secara teknis - pada tahun 1988) dan diciptakan untuk beroperasi pada kecepatan transfer data 64 Kbps. Itu sudah menggunakan ide-ide seperti subsampling warna, blok makro, dll. Standar codec video diterbitkan pada tahun 1995 H.263, yang berkembang hingga tahun 2001.
Versi pertama selesai pada tahun 2003 H.264 / AVC. Pada tahun yang sama, TrueMotion merilis codec video lossy gratis yang disebut VP3. Google membeli perusahaan itu pada tahun 2008, merilis VP8 tahun yang sama. Pada bulan Desember 2012, Google merilis VP9, dan didukung di sekitar ΒΎ pasar browser (termasuk perangkat seluler).
AV1 adalah codec video sumber terbuka dan gratis baru yang dikembangkan oleh Aliansi untuk Media Terbuka (AOMedia), yang mencakup perusahaan paling terkenal, seperti: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel dan Cisco. Versi pertama codec, 0.1.0, diterbitkan pada 7 April 2016.
Kelahiran AV1
Pada awal tahun 2015, Google sedang mengerjakannya VP10Xiph (yang dimiliki oleh Mozilla) sedang dikerjakan Daala, dan Cisco membuat codec video gratisnya sendiri yang disebut Thor.
kemudian MPEG LA pertama kali mengumumkan batas tahunan untuk HEVC (H.265) dan biayanya 8 kali lebih tinggi dibandingkan H.264, tetapi mereka segera mengubah aturannya lagi:
tidak ada batasan tahunan,
biaya konten (0,5% dari pendapatan) dan
biaya unitnya sekitar 10 kali lebih tinggi dari H.264.
Aliansi untuk Media Terbuka dibuat oleh perusahaan dari berbagai bidang: produsen peralatan (Intel, AMD, ARM, Nvidia, Cisco), penyedia konten (Google, Netflix, Amazon), pembuat browser (Google, Mozilla) dan lain-lain.
Perusahaan-perusahaan tersebut memiliki tujuan yang sama - codec video bebas royalti. Kemudian muncul AV1 dengan lisensi paten yang lebih sederhana. Timothy B. Terryberry memberikan presentasi memukau yang menjadi cikal bakal konsep AV1 saat ini dan model lisensinya.
Anda akan terkejut mengetahui bahwa Anda dapat menganalisis codec AV1 melalui browser (bagi yang berminat dapat mengunjunginya).
Kodek universal
Mari kita lihat mekanisme utama yang mendasari codec video universal. Sebagian besar konsep ini berguna dan digunakan dalam codec modern seperti VP9, AV1 ΠΈ HEVC. Saya memperingatkan Anda bahwa banyak hal yang dijelaskan akan disederhanakan. Terkadang contoh dunia nyata (seperti H.264) akan digunakan untuk mendemonstrasikan teknologinya.
Langkah pertama - memisahkan gambar
Langkah pertama adalah membagi frame menjadi beberapa bagian, subbagian dan seterusnya.
Untuk apa? Ada banyak alasan. Saat kita membagi gambar, kita dapat memprediksi vektor gerak secara lebih akurat dengan menggunakan bagian kecil untuk bagian kecil yang bergerak. Sedangkan untuk latar belakang statis Anda dapat membatasi diri pada bagian yang lebih besar.
Codec biasanya mengatur bagian-bagian ini menjadi beberapa bagian (atau potongan), blok makro (atau blok pohon pengkodean), dan beberapa subbagian. Ukuran maksimum partisi ini bervariasi, HEVC menyetelnya ke 64x64 sedangkan AVC menggunakan 16x16, dan subpartisi dapat dipecah hingga ukuran 4x4.
Apakah Anda ingat jenis bingkai dari artikel terakhir?! Hal yang sama dapat diterapkan pada blok, sehingga kita dapat memiliki fragmen I, blok B, blok makro P, dan seterusnya.
Bagi yang ingin berlatih, perhatikan bagaimana gambar dibagi menjadi beberapa bagian dan subbagian. Untuk melakukan ini, Anda bisa menggunakan yang sudah disebutkan di artikel sebelumnya. (yang berbayar, tapi dengan versi trial gratis yang dibatasi 10 frame pertama). Bagian dianalisis di sini VP9:
Langkah ke-2 - peramalan
Setelah kami memiliki bagian, kami dapat membuat ramalan astrologi untuk bagian tersebut. Untuk Perkiraan INTER harus ditransfer vektor gerak dan sisanya, dan untuk peramalan INTRA ditransmisikan arah perkiraan dan sisanya.
Langkah ke-3 - transformasi
Setelah kita memiliki blok sisa (bagian yang diprediksi β bagian nyata), kita dapat mengubahnya sedemikian rupa sehingga kita mengetahui piksel mana yang dapat dibuang dengan tetap menjaga kualitas secara keseluruhan. Ada beberapa transformasi yang memberikan perilaku yang tepat.
Meskipun ada metode lain, mari kita lihat lebih detail. transformasi kosinus diskrit (DCT - dari transformasi kosinus diskrit). Fungsi utama DCT:
- Mengonversi blok piksel menjadi blok koefisien frekuensi berukuran sama.
- Memadatkan kekuatan untuk membantu menghilangkan redundansi spasial.
- Memberikan reversibilitas.
2 Februari 2017 Sintra R.J. (Cintra, RJ) dan Bayer F.M. (Bayer FM) menerbitkan artikel tentang transformasi mirip DCT untuk kompresi gambar yang hanya memerlukan 14 penambahan.
Jangan khawatir jika Anda belum memahami manfaat setiap itemnya. Sekarang mari kita gunakan contoh spesifik untuk melihat nilai sebenarnya.
Mari kita ambil blok piksel 8x8 ini:
Blok ini dirender menjadi gambar berukuran 8 kali 8 piksel berikut:
Terapkan DCT ke blok piksel ini dan dapatkan blok koefisien 8x8:
Dan jika kita merender blok koefisien ini, kita akan mendapatkan gambar berikut:
Seperti yang Anda lihat, ini tidak terlihat seperti gambar aslinya. Anda dapat melihat bahwa koefisien pertama sangat berbeda dari koefisien lainnya. Koefisien pertama ini dikenal sebagai koefisien DC, yang mewakili semua sampel dalam array input, seperti rata-rata.
Blok koefisien ini memiliki sifat menarik: memisahkan komponen berfrekuensi tinggi dari komponen berfrekuensi rendah.
Dalam sebuah gambar, sebagian besar daya terkonsentrasi pada frekuensi yang lebih rendah, jadi jika Anda mengubah gambar menjadi komponen frekuensinya dan membuang koefisien frekuensi yang lebih tinggi, Anda dapat mengurangi jumlah data yang diperlukan untuk mendeskripsikan gambar tanpa mengorbankan terlalu banyak kualitas gambar.
Frekuensi mengacu pada seberapa cepat sinyal berubah.
Mari kita coba menerapkan pengetahuan yang diperoleh dalam kasus uji dengan mengubah gambar asli menjadi frekuensinya (blok koefisien) menggunakan DCT dan kemudian membuang sebagian koefisien yang paling tidak penting.
Pertama kita ubah ke domain frekuensi.
Selanjutnya, kita membuang sebagian (67%) koefisien, terutama bagian kanan bawah.
Terakhir, kita merekonstruksi gambar dari blok koefisien yang dibuang ini (ingat, gambar tersebut harus dapat dibalik) dan membandingkannya dengan aslinya.
Terlihat mirip dengan gambar aslinya, namun terdapat banyak perbedaan dengan aslinya. Kami membuang 67,1875% dan masih mendapatkan sesuatu yang mirip dengan aslinya. Dimungkinkan untuk membuang koefisien dengan lebih hati-hati untuk mendapatkan gambar dengan kualitas yang lebih baik, tetapi itu adalah topik berikutnya.
Setiap koefisien dihasilkan menggunakan semua piksel
Penting: setiap koefisien tidak secara langsung dipetakan ke satu piksel, namun merupakan jumlah tertimbang dari semua piksel. Grafik menakjubkan ini menunjukkan bagaimana koefisien pertama dan kedua dihitung menggunakan bobot unik untuk setiap indeks.
Anda juga dapat mencoba memvisualisasikan DCT dengan melihat formasi gambar sederhana berdasarkan DCT. Sebagai contoh, berikut adalah simbol A yang dihasilkan menggunakan masing-masing bobot koefisien:
Langkah ke-4 - kuantisasi
Setelah kita membuang beberapa koefisien pada langkah sebelumnya, pada langkah terakhir (transformasi) kita melakukan bentuk kuantisasi khusus. Pada tahap ini, kehilangan informasi dapat diterima. Atau, lebih sederhananya, kita akan mengkuantisasi koefisien untuk mencapai kompresi.
Bagaimana cara mengkuantifikasi blok koefisien? Salah satu metode paling sederhana adalah kuantisasi seragam, ketika kita mengambil sebuah blok, membaginya dengan satu nilai (dengan 10) dan membulatkan hasilnya.
Bisakah kita membalikkan blok koefisien ini? Ya, kita bisa, mengalikannya dengan nilai yang sama dengan yang kita bagi.
Pendekatan ini bukan yang terbaik karena tidak memperhitungkan pentingnya setiap koefisien. Seseorang dapat menggunakan matriks quantizer alih-alih menggunakan nilai tunggal, dan matriks ini dapat mengeksploitasi properti DCT dengan mengkuantisasi mayoritas kelompok kanan bawah dan minoritas kiri atas.
Langkah 5 - pengkodean entropi
Setelah kami mengkuantisasi data (blok gambar, fragmen, bingkai), kami masih dapat mengompresnya tanpa kehilangan. Ada banyak cara algoritmik untuk mengompresi data. Kita akan melihat sekilas beberapa di antaranya, untuk pemahaman lebih dalam Anda dapat membaca buku Memahami Kompresi: Kompresi Data untuk Pengembang Modern ("").
Pengodean video menggunakan VLC
Katakanlah kita memiliki aliran karakter: a, e, r ΠΈ t. Probabilitas (mulai dari 0 hingga 1) seberapa sering setiap karakter muncul dalam suatu aliran disajikan dalam tabel ini.
| a | e | r | t | |
|---|---|---|---|---|
| Kemungkinan | 0,3 | 0,3 | 0,2 | 0,2 |
Kita dapat menetapkan kode biner unik (sebaiknya yang kecil) ke kode yang paling mungkin terjadi, dan kode yang lebih besar ke kode yang kecil kemungkinannya.
| a | e | r | t | |
|---|---|---|---|---|
| Kemungkinan | 0,3 | 0,3 | 0,2 | 0,2 |
| Kode biner | 0 | 10 | 110 | 1110 |
Kami mengompresi aliran, dengan asumsi bahwa kami akan menghabiskan 8 bit untuk setiap karakter. Tanpa kompresi, dibutuhkan 24 bit per karakter. Jika Anda mengganti setiap karakter dengan kodenya, Anda mendapat penghematan!
Langkah pertama adalah mengkodekan karakter e, yang sama dengan 10, dan karakter kedua adalah a, yang ditambahkan (bukan secara matematis): [10][0], dan terakhir karakter ketiga t, yang membuat bitstream terkompresi akhir kita sama dengan [10][0][1110] atau 1001110, yang hanya membutuhkan 7 bit (ruang 3,4 kali lebih sedikit dari aslinya).
Harap dicatat bahwa setiap kode harus berupa kode unik dengan awalan. akan membantu Anda menemukan angka-angka ini. Meskipun metode ini bukannya tanpa kekurangan, ada codec video yang masih menawarkan metode kompresi algoritmik ini.
Baik encoder maupun decoder harus memiliki akses ke tabel simbol dengan kode binernya. Oleh karena itu perlu juga dikirimkan tabel sebagai masukan.
Pengkodean aritmatika
Katakanlah kita memiliki aliran karakter: a, e, r, s ΠΈ t, dan probabilitasnya disajikan dalam tabel ini.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Kemungkinan | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Dengan menggunakan tabel ini, kita akan membuat rentang yang berisi semua kemungkinan karakter, diurutkan berdasarkan angka terbesar.
Sekarang mari kita menyandikan aliran tiga karakter: makan.
Pertama pilih karakter pertama e, yang berada dalam subrentang 0,3 hingga 0,6 (tidak termasuk). Kami mengambil subrentang ini dan membaginya lagi dalam proporsi yang sama seperti sebelumnya, tetapi untuk rentang baru ini.
Mari lanjutkan pengkodean aliran kita makan. Sekarang ambil karakter kedua a, yang berada di subrentang baru dari 0,3 hingga 0,39, lalu ambil karakter terakhir kita t dan mengulangi proses yang sama lagi, kita mendapatkan sub-rentang terakhir dari 0,354 hingga 0,372.
Kita hanya perlu memilih angka di subrange terakhir dari 0,354 hingga 0,372. Mari kita pilih 0,36 (tetapi Anda dapat memilih nomor lain di subrentang ini). Hanya dengan nomor ini kami dapat mengembalikan aliran asli kami. Seolah-olah kita sedang menggambar garis dalam rentang untuk menyandikan aliran kita.
Operasi sebaliknya (yaitu, penguraian kode) sama sederhananya: dengan angka 0,36 dan rentang awal, kita dapat menjalankan proses yang sama. Namun sekarang, dengan menggunakan nomor ini, kami mengidentifikasi aliran yang dikodekan menggunakan nomor ini.
Dengan rentang pertama, kita melihat bahwa nomor kita sesuai dengan irisan, oleh karena itu ini adalah karakter pertama kita. Sekarang kita membagi sub-rentang ini lagi dengan mengikuti proses yang sama seperti sebelumnya. Di sini Anda dapat melihat bahwa 0,36 sesuai dengan simbol a, dan setelah mengulangi proses tersebut kita sampai pada karakter terakhir t (membentuk aliran berkode asli kami makan).
Baik encoder maupun decoder harus memiliki tabel probabilitas simbol, sehingga perlu dikirimkan juga pada data masukan.
Cukup elegan, bukan? Siapa pun yang menemukan solusi ini sangat cerdas. Beberapa codec video menggunakan teknik ini (atau setidaknya menawarkannya sebagai opsi).
Idenya adalah untuk mengompresi aliran bit terkuantisasi secara lossless. Tentunya artikel ini kehilangan banyak detail, alasan, trade-off, dll. Namun jika Anda seorang pengembang, Anda harus tahu lebih banyak. Codec baru mencoba menggunakan algoritma pengkodean entropi yang berbeda seperti ANS.
Langkah 6 - format bitstream
Setelah melakukan semua ini, yang tersisa hanyalah membongkar frame terkompresi dalam konteks langkah-langkah yang dilakukan. Decoder harus diberitahu secara eksplisit tentang keputusan yang dibuat oleh encoder. Dekoder harus dilengkapi dengan semua informasi yang diperlukan: kedalaman bit, ruang warna, resolusi, informasi prediksi (vektor gerak, prediksi arah INTER), profil, level, kecepatan bingkai, jenis bingkai, nomor bingkai, dan banyak lagi.
Kita akan melihat sekilas bitstreamnya H.264. Langkah pertama kami adalah membuat bitstream H.264 minimal (FFmpeg secara default menambahkan semua opsi pengkodean seperti SEI NAL β kita akan mencari tahu lebih jauh lagi). Kita dapat melakukan ini menggunakan repositori dan FFmpeg kita sendiri.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Perintah ini akan menghasilkan bitstream mentah H.264 dengan satu bingkai, resolusi 64x64, dengan ruang warna YUV420. Dalam hal ini, gambar berikut digunakan sebagai bingkai.
Aliran bit H.264
Standar AVC (H.264) menentukan bahwa informasi akan dikirim dalam makroframe (dalam pengertian jaringan), disebut akhir (ini adalah tingkat abstraksi jaringan). Tujuan utama NAL adalah menyediakan presentasi video yang "ramah web". Standar ini dapat digunakan di TV (berbasis streaming), Internet (berbasis paket).
Ada penanda sinkronisasi untuk menentukan batas elemen NAL. Setiap token sinkronisasi berisi nilai 0x00 0x00 0x01, kecuali yang pertama, yaitu sama dengan 0x00 0x00 0x00 0x01. Jika kita meluncurkannya hexdump untuk bitstream H.264 yang dihasilkan, kami mengidentifikasi setidaknya tiga pola NAL di awal file.
Seperti yang disebutkan, decoder tidak hanya harus mengetahui data gambar, tetapi juga detail video, bingkai, warna, parameter yang digunakan, dan banyak lagi. Byte pertama dari setiap NAL mendefinisikan kategori dan tipenya.
| Pengidentifikasi tipe NAL | ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ |
|---|---|
| 0 | Tipe tidak diketahui |
| 1 | Fragmen gambar yang dikodekan tanpa IDR |
| 2 | Bagian data irisan berkode A |
| 3 | Bagian data irisan berkode B |
| 4 | Bagian data irisan berkode C |
| 5 | Fragmen IDR yang dikodekan dari gambar IDR |
| 6 | Informasi lebih lanjut tentang ekstensi SEI |
| 7 | Kumpulan Parameter Urutan SPS |
| 8 | Kumpulan parameter gambar PPS |
| 9 | Pemisah akses |
| 10 | Akhir dari urutan |
| 11 | Akhir utas |
| ... | ... |
Biasanya NAL pertama dari bitstream adalah SPS. Jenis NAL ini bertanggung jawab untuk menginformasikan tentang variabel pengkodean umum seperti profil, level, resolusi, dll.
Jika kita melewatkan penanda sinkronisasi pertama, kita dapat mendekode byte pertama untuk mengetahui tipe NAL mana yang pertama.
Misalnya, byte pertama setelah token sinkronisasi adalah 01100111, di mana bit pertama (0) ada di bidang forbidden_zero_bit. 2 bit berikutnya (11) memberi tahu kita bidangnya akhir_ref_idc, yang menunjukkan apakah NAL ini merupakan bidang referensi atau tidak. Dan 5 bit sisanya (00111) memberi tahu kita bidangnya tipe_unit_akhir, dalam hal ini adalah blok SPS (7) NAL.
Byte kedua (biner=01100100, hex=0x64, Desember=100) di SPS NAL adalah lapangan profil_idc, yang menunjukkan profil yang digunakan pembuat enkode. Dalam hal ini, profil tinggi yang terbatas digunakan (yaitu, profil tinggi tanpa dukungan segmen B dua arah).
Jika Anda melihat spesifikasi bitstream H.264 untuk SPS NAL kita akan menemukan banyak nilai untuk nama parameter, kategori dan deskripsi. Misalnya, mari kita lihat bidangnya pic_width_in_mbs_minus_1 ΠΈ pic_height_in_map_units_minus_1.
| Nama parameter | Kategori | ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | kamu(v) |
| pic_height_in_map_units_minus_1 | 0 | kamu(v) |
Jika kita melakukan beberapa operasi matematika dengan nilai bidang ini, kita akan memperoleh resolusi. Seseorang dapat mewakili 1920 x 1080 menggunakan pic_width_in_mbs_minus_1 dengan nilai 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). Sekali lagi, untuk menghemat ruang, alih-alih mengkodekan 1920, kami melakukannya dengan 119.
Jika kita terus memeriksa video yang kita buat dalam bentuk biner (misalnya: xxd -b -c 11 v/minimal_yuv420.h264), lalu Anda dapat menuju ke NAL terakhir, yaitu frame itu sendiri.
Di sini kita melihat nilai 6 byte pertamanya: 01100101 10001000 10000100 00000000 00100001 11111111. Karena byte pertama diketahui menunjukkan tipe NAL, dalam hal ini (00101) adalah pecahan IDR (5), dan kemudian Anda dapat menjelajahinya lebih jauh:
Dengan menggunakan informasi spesifikasi, dimungkinkan untuk memecahkan kode tipe fragmen (irisan_tipe) dan nomor bingkai (bingkai_num) di antara bidang penting lainnya.
Untuk mendapatkan nilai dari beberapa bidang (ue(v), me(v), se(v) atau te(v)), kita perlu memecahkan kode fragmen menggunakan decoder khusus berdasarkan . Cara ini sangat efisien untuk mengkodekan nilai variabel, terutama bila nilai defaultnya banyak.
Nilai-nilai irisan_tipe ΠΈ bingkai_num video ini adalah 7 (fragmen I) dan 0 (frame pertama).
Bitstream dapat dianggap sebagai sebuah protokol. Jika Anda ingin tahu lebih banyak tentang bitstream, Anda harus merujuk pada spesifikasinya ITU H.264. Berikut adalah diagram makro yang menunjukkan di mana data gambar berada (YUV dalam bentuk terkompresi).
Bitstream lain dapat diperiksa, seperti VP9, H.265 (HEVC) atau bahkan bitstream terbaik kami yang baru AV1. Apakah semuanya serupa? Tidak, tetapi begitu Anda memahami setidaknya satu, akan lebih mudah untuk memahami sisanya.
Ingin berlatih? Jelajahi aliran bit H.264
Anda dapat membuat video bingkai tunggal dan menggunakan MediaInfo untuk memeriksa bitstream H.264. Faktanya, tidak ada yang menghalangi Anda untuk melihat kode sumber yang menganalisis aliran bit H.264 (AVC).
Untuk latihannya bisa menggunakan Intel Video Pro Analyzer (apa sudah saya bilang programnya berbayar, tapi ada versi trial gratis dengan batasan 10 frame?).
Tinjau
Perhatikan bahwa banyak codec modern menggunakan model yang sama yang baru saja kita pelajari. Di sini, mari kita lihat diagram blok codec video Thor. Ini berisi semua langkah yang telah kita lalui. Inti dari postingan ini adalah untuk setidaknya memberi Anda pemahaman yang lebih baik tentang inovasi dan dokumentasi di bidang ini.
Sebelumnya, diperkirakan diperlukan ruang disk sebesar 139 GB untuk menyimpan file video berdurasi satu jam dengan kualitas 720p dan 30 fps. Jika Anda menggunakan metode yang dibahas dalam artikel ini (prediksi antar-frame dan internal, transformasi, kuantisasi, pengkodean entropi, dll.), maka Anda dapat mencapai (berdasarkan fakta bahwa kami menghabiskan 0,031 bit per piksel), video yang cukup kualitas memuaskan, hanya menempati 367,82 MB, bukan memori 139 GB.
Bagaimana H.265 mencapai rasio kompresi yang lebih baik daripada H.264?
Kini setelah kita mengetahui lebih banyak tentang cara kerja codec, akan lebih mudah untuk memahami bagaimana codec yang lebih baru dapat memberikan resolusi yang lebih tinggi dengan bit yang lebih sedikit.
Jika kita membandingkan AVC ΠΈ HEVC, perlu diingat bahwa ini hampir selalu merupakan pilihan antara beban CPU yang lebih besar dan rasio kompresi.
HEVC memiliki lebih banyak opsi bagian (dan subbagian) daripada AVC, lebih banyak arah prediksi internal, peningkatan pengkodean entropi, dan banyak lagi. Semua perbaikan ini telah dilakukan H.265 mampu mengompresi 50% lebih dari H.264.
Bagian pertama:
Sumber: www.habr.com