Bhinish Dhiman

Video ke GIF: byte per piksel per frame, hasil pengukuran

Diterjemahkan dari versi asli berbahasa Inggris. Baca versi asli

Melalui encoder di balik alat kami, 50 frame pada 480 × 270 membutuhkan 0.644 byte per piksel per frame untuk foto bergerak (4.17 MB) dan 0.111 untuk rekaman antarmuka yang di-scroll (716 KB). Sebagai H.264 pada CRF 23, ukurannya 78 KB dan 132 KB: GIF-nya 53 dan 5.4 kali lebih besar. Palet 16 warna memangkas ukuran foto menjadi separuh.

Alat video-to-GIF kami memperkirakan ukuran output dari konstanta 0.45 byte per piksel per frame dan menyatakan angka itu bisa meleset hingga dua kali lipat, lebih besar atau lebih kecil. Kami mengukur seberapa jauh melesetnya, dan pada konten apa.

Satuannya

Byte per piksel per frame adalah ukuran GIF dibagi lebar, tinggi, dan jumlah frame-nya. Satuan ini memisahkan hal yang buruk dilakukan GIF, yaitu menyimpan setiap frame sebagai gambar 8-bit utuh yang dikompresi dengan LZW tanpa merujuk ke frame sebelumnya, dari pilihan-pilihan yang hanya menskalakannya. Memangkas lebar menjadi separuh membuat file menjadi seperempatnya pada nilai berapa pun dari angka ini; angka itu sendiri ditentukan oleh gambarnya.

Pengukurannya

Dua klip berdurasi empat detik, keduanya didekode menjadi 50 frame pada 480 × 270 dan 12.5 frame per detik: sebuah foto dengan pan dan zoom lambat, sehingga setiap frame berbeda dari frame sebelumnya, dan rekaman layar Chromium dari dua halaman di situs ini yang sedang di-scroll. Setiap set frame di-encode di Chromium headless dengan modern-gif 2.1.0, encoder di balik alat ini, pada lima ukuran palet, dengan dan tanpa dithering Floyd–Steinberg. Ke-50 frame yang sama juga di-encode dengan FFmpeg 6.0 sebagai H.264 pada CRF 23 dan CRF 18, serta sebagai VP9 pada CRF 33. Dijalankan pada 1 Oktober 2026.

Palet Foto bergerak Byte per piksel per frame Rekaman layar Byte per piksel per frame
255 warna, dengan dither 4 171 930 B 0.644 716 151 B 0.111
255 warna, tanpa dither 4 188 639 B 0.646 685 764 B 0.106
128 warna, dengan dither 3 674 083 B 0.567 685 507 B 0.106
64 warna, dengan dither 3 115 969 B 0.481 637 659 B 0.098
32 warna, dengan dither 2 569 888 B 0.397 549 810 B 0.085
16 warna, dengan dither 2 010 333 B 0.310 506 418 B 0.078

Baris pertama adalah yang dihasilkan alat ini, karena alat ini meng-encode pada 255 warna dengan dithering aktif. Encoder palet milik FFmpeg sendiri menghasilkan 3 670 375 byte dan 726 687 byte untuk dua input yang sama pada 256 warna, terpaut tidak sampai 12% dari modern-gif pada foto dan 1.5% pada rekaman, jadi angka-angka ini menggambarkan formatnya, bukan satu library tertentu.

Frame yang sama sebagai video

Encoding Foto bergerak Rekaman layar
GIF, 255 warna, dengan dither 4 171 930 B 716 151 B
H.264, CRF 18 178 684 B 179 566 B
H.264, CRF 23 78 138 B 131 975 B
VP9, CRF 33 39 613 B 105 788 B

“GIF kira-kira sepuluh kali ukuran MP4” adalah angka yang biasa disebut. Pada foto, hasilnya 53 kali pada CRF 23, 23 kali bahkan pada CRF 18, dan 105 kali dibandingkan VP9. Pada rekaman layar, hasilnya 5.4 kali. Foto adalah kasus di mana codec video bekerja paling baik, karena motion prediction mengubah gambar yang bergeser menjadi beberapa instruksi per blok; GIF tidak punya mekanisme semacam itu dan harus membayar setiap piksel di setiap frame.

Hasil dari mengurangi palet

Memangkas dari 255 warna menjadi 16 membuat ukuran foto menjadi separuh dan mengurangi 29% dari rekaman. Penghematannya nyata, tetapi juga yang paling jelek hasilnya: banding di setiap gradien dan kulit yang tampak terposterisasi. Menurunkan lebar dari 480 menjadi 340 menghemat 50% yang sama dan jauh lebih tidak terlihat, itulah sebabnya alat kami menampilkan lebar dan frame rate sebelum pengaturan lainnya.

Dithering hampir tidak menambah byte, kurang dari 1% pada foto dan 4% pada rekaman, tetapi membuat waktu encoding dua hingga empat kali lebih lama. Pada 16 warna, file dengan dan tanpa dither berukuran sama persis sampai ke byte-nya di kedua klip.

Perkiraan dibandingkan pengukuran

Dengan 0.45 byte per piksel per frame, alat ini akan memperkirakan 2.92 MB untuk kedua klip. Foto ternyata 43% di atas angka itu dan rekaman layar 75% di bawahnya. Satu konstanta tidak bisa menggambarkan format yang rasionya sepenuhnya ditentukan oleh konten, itulah sebabnya perkiraan diberi label kasar dan angka sebenarnya ditampilkan di sampingnya setelah proses selesai. Diukur pada satu frame, foto membutuhkan 0.668 byte per piksel dan antarmuka 0.224, jadi jika Anda perlu tahu sebelumnya, satu frame yang dilewatkan ke encoder adalah prediktor yang lebih baik daripada konstanta apa pun.

Versi singkatnya

Untuk rekaman fotografis, perkirakan sekitar 0.6 byte per piksel per frame dan file lima puluh kali ukuran MP4; untuk rekaman antarmuka yang datar, sekitar 0.1 dan lima kali. Lebar adalah tuas utamanya; palet adalah pilihan terakhir; dan jika lebih dari beberapa detik, GIF hanyalah video yang memakai ekstensi yang salah.