Jika Anda membuat video, mengonversi berkas yang sudah ada, atau menyiapkan konten video untuk situs web, salah satu keputusan terpenting adalah memilih format dan pengaturan kompresi yang tepat. Berkas sekecil mungkin belum tentu menjadi pilihan terbaik. Video juga harus dapat diputar dengan andal di browser, berfungsi di ponsel, mudah didekode, dan mempertahankan kualitas visual yang memadai untuk tujuan penggunaannya.
Saya mempelajari MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, preset encoder x264, kompatibilitas browser, dekode perangkat keras di perangkat seluler, serta pengukuran kualitas video. Saya juga melakukan eksperimen kompresi langsung: mengodekan video sumber yang sama dengan beberapa nilai CRF, lalu membandingkan hasilnya secara visual dan melalui pengukuran objektif.
Keputusan akhir saya adalah mengutamakan MP4 dengan H.264 ketika satu berkas video harus dapat digunakan di sebanyak mungkin browser, ponsel, dan aplikasi eksternal.
Untuk video pendek yang terutama ditonton melalui ponsel, ketika pemuatan cepat dan ukuran berkas kecil lebih penting daripada mempertahankan setiap detail halus, saya memilih x264 CRF 30. Dalam pengujian, saya tidak melihat perbedaan berarti antara CRF 22 dan 30 saat pemutaran normal, bahkan di monitor desktop berukuran besar.
Namun, keputusan tersebut perlu diberi batasan penting: CRF 30 bukan rekomendasi untuk film, produksi video premium, atau rekaman yang sangat mengutamakan ketepatan visual. Untuk penggunaan seperti itu, nilai yang jauh lebih konservatif, sering kali sekitar CRF 20, bisa menjadi titik awal yang lebih baik. Saya tidak melakukan penelitian pembanding yang setara terhadap film panjang atau rekaman sinematik berkualitas tinggi. Karena itu, pengaturan tersebut perlu dianggap sebagai titik awal untuk pengujian tersendiri.
Artikel ini menjelaskan alasan teknis, hasil kompresi yang benar-benar diperoleh, batasan hasil tersebut, dan cara memilih format serta pengaturan kualitas video yang sesuai untuk proyek Anda.
1. Kontainer Video dan Codec Adalah Dua Hal Berbeda
Sebelum membandingkan MP4 dengan WebM, kita perlu memahami perbedaan antara kontainer dan codec.
Kontainer menyimpan video, audio, penanda waktu, dan metadata bersama-sama dalam satu berkas. Codec video menentukan bagaimana frame video dikompresi dan didekode.
Misalnya, MP4 dapat memuat video H.264, HEVC, atau AV1. Kombinasi tersebut memiliki karakteristik kompresi dan kebutuhan perangkat yang berbeda, meskipun ekstensi berkasnya sama.
| Komponen | Contoh | Fungsi |
|---|---|---|
| Kontainer video | MP4, WebM, MOV, MKV | Mengemas video, audio, dan data waktu |
| Codec video | H.264, HEVC, VP9, AV1 | Mengompresi dan mendekompresi frame video |
| Codec audio | AAC, Opus, MP3 | Mengompresi dan mendekompresi audio |
| Encoder video | x264, x265, SVT-AV1, libvpx-vp9 | Mengimplementasikan kompresi video |
Mengganti nama berkas dari .webm menjadi .mp4 tidak mengonversi codec videonya. Demikian pula, menyimpan AV1 di dalam MP4 tidak membuat video tersebut dapat diputar pada perangkat yang tidak mendukung dekode AV1.
Ketika membahas kompatibilitas video, selalu pertimbangkan keseluruhan kombinasinya: kontainer, codec video, codec audio, profil codec, kedalaman bit, dan lingkungan pemutaran.
2. MP4 vs WebM: Mana yang Lebih Baik untuk Video Web?
MP4 dan WebM sama-sama merupakan kontainer video modern yang layak digunakan. Tidak ada yang selalu lebih unggul karena karakteristik praktisnya bergantung pada codec yang digunakan di dalamnya.
MP4 dengan H.264: Kompatibilitas Praktis Terluas
MP4 yang berisi video H.264 dan audio AAC memiliki rekam jejak kompatibilitas yang sangat luas. Kombinasi ini didukung oleh browser desktop dan seluler utama, pemutar video bawaan sistem operasi, dan banyak aplikasi pihak ketiga.
Kombinasi tersebut juga umum didukung oleh dekoder video perangkat keras di ponsel dan komputer. Dekode perangkat keras dapat mengurangi penggunaan CPU, meningkatkan efisiensi pemutaran, dan menurunkan konsumsi daya dibandingkan dekode melalui perangkat lunak.
Kekurangan utamanya adalah efisiensi kompresi. Codec yang lebih baru sering kali dapat menghasilkan kualitas visual serupa dengan bitrate lebih rendah.
Namun, H.264 tetap merupakan pilihan yang sangat baik ketika pemutaran yang andal lebih penting daripada memperoleh berkas sekecil mungkin.
WebM dengan VP9: Efisien dan Ramah Browser
WebM umumnya berisi video VP8, VP9, atau AV1, dengan audio yang biasanya dikodekan menggunakan Opus atau Vorbis.
VP9 sering kali memiliki efisiensi kompresi lebih baik daripada H.264 pada kualitas visual yang sebanding. Codec ini didukung luas oleh browser masa kini, termasuk Safari versi modern.
Keliru jika menyatakan bahwa Safari sama sekali tidak mendukung WebM atau VP9. Kompatibilitas browser telah meningkat secara signifikan seiring waktu.
Batasan yang lebih penting justru terletak pada kompatibilitas di luar browser. Aplikasi bawaan sistem operasi, perangkat lama, dan perangkat lunak pihak ketiga mungkin tidak menangani WebM sekonsisten MP4/H.264 konvensional.
Untuk aplikasi yang hanya berjalan di browser dan kemampuan pemutarannya dapat dikendalikan, WebM adalah opsi yang kuat. Namun, jika pengunjung dapat mengunduh video lalu membukanya di berbagai aplikasi, MP4/H.264 tetap lebih dapat diprediksi.
Perbedaan dalam Praktik
| Kebutuhan | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Pemutaran di browser modern | Istimewa | Sangat baik |
| Dukungan browser dan perangkat lama | Umumnya lebih luas | Lebih bergantung pada lingkungan |
| Kompatibilitas berkas unduhan | Umumnya lebih luas | Kurang dapat diprediksi pada aplikasi bawaan |
| Efisiensi kompresi | Baik | Sering kali lebih baik |
| Dekode perangkat keras | Sangat luas | Umum tersedia, tetapi bergantung pada perangkat |
| Penggunaan paling sesuai | Satu berkas dengan kompatibilitas luas | Pengiriman video web yang efisien untuk klien yang diketahui |
Pertanyaan utamanya bukan apakah WebM merupakan format yang bagus, melainkan apakah keunggulan kompresinya sepadan dengan kompromi kompatibilitas dalam lingkungan Anda.
3. H.264 vs H.265 vs VP9 vs AV1: Codec Mana yang Sebaiknya Dipilih?
Setiap codec video utama menawarkan keseimbangan berbeda antara efisiensi kompresi, biaya encoding, dukungan perangkat keras, kompatibilitas perangkat lunak, dan lisensi.
| Codec | Efisiensi Kompresi | Kompatibilitas Praktis | Penggunaan Umum |
|---|---|---|---|
| H.264 / AVC | Baik | Sangat baik | Video web umum, pemutaran seluler, unduhan |
| H.265 / HEVC | Umumnya lebih baik daripada H.264 | Bergantung pada lingkungan | Perangkat Apple yang kompatibel, lingkungan terkendali, video resolusi tinggi |
| VP9 | Umumnya lebih baik daripada H.264 | Sangat baik di browser modern | Pengiriman video melalui browser |
| AV1 | Potensi efisiensi sangat tinggi | Terus meningkat, tetapi terbatas pada perangkat lama | Streaming modern dan perangkat yang kompatibel |
Perbandingan ini bersifat kualitatif, bukan peringkat bitrate yang berlaku universal. Efisiensi sebenarnya bergantung pada konten video, implementasi encoder, sasaran kualitas, preset encoding, dan metode pengukuran.
H.264: Matang, Cepat Didekode, dan Didukung Luas
H.264 telah dioptimalkan secara ekstensif dan didukung oleh sangat banyak perangkat keras serta perangkat lunak. Kematangannya menjadi keunggulan ketika video harus dapat diputar dengan andal tanpa aplikasi pemutar khusus.
Kelemahannya, codec baru sering kali dapat mengompresi video dengan lebih efisien. H.264 juga melibatkan pertimbangan paten dan lisensi yang perlu ditinjau dalam skenario distribusi komersial yang relevan.
H.265 / HEVC: Kompresi Lebih Baik dengan Kompromi Kompatibilitas
HEVC dapat mengurangi bitrate secara signifikan dibandingkan H.264 pada kualitas serupa. Codec ini terutama menarik untuk konten beresolusi tinggi dan lingkungan dengan kompatibilitas perangkat yang terkendali.
Banyak perangkat Apple mendukung HEVC dengan sangat baik. Namun, dukungan browser dan aplikasi eksternal berbeda-beda menurut sistem operasi serta komponen dekode yang terpasang. Lisensi juga perlu dipertimbangkan.
HEVC bisa menjadi pilihan yang sangat baik, tetapi saya tidak akan otomatis menjadikannya satu-satunya format video unduhan untuk situs web serbaguna.
VP9: Alternatif Terbuka yang Praktis
VP9 menawarkan kompresi yang baik dan kompatibilitas luas pada browser modern. Format ini menarik jika video hanya diputar di browser dan lingkungan pemutarannya dapat diprediksi.
Kekurangan utamanya untuk kebutuhan saya adalah ketidakpastian saat pengguna mengunduh video atau membukanya di aplikasi bawaan yang mungkin tidak mendukung WebM atau VP9 secara konsisten.
AV1: Efisiensi Sangat Baik, tetapi Dukungan Perangkat Keras Belum Universal
AV1 merupakan salah satu codec video modern yang paling menjanjikan. Codec ini dapat menghasilkan penghematan bitrate yang besar dibandingkan codec lama, dan dukungan dekode perangkat kerasnya terus meluas.
Meski demikian, perangkat lama mungkin tidak memiliki dekoder AV1 sehingga memerlukan dekode perangkat lunak. Dekode perangkat lunak untuk video beresolusi tinggi dapat menghabiskan lebih banyak CPU dan baterai, serta menimbulkan masalah pemutaran pada perangkat yang lebih lemah.
Jika Anda mengendalikan lingkungan pemutaran, AV1 layak dipertimbangkan secara serius. Jika satu berkas harus dapat diputar di perangkat lama maupun baru serta pemutar video eksternal biasa, H.264 masih menjadi pilihan awal yang lebih aman.
Panduan codec video MDN menyediakan penjelasan bermanfaat tentang berbagai codec ini dan persyaratan browsernya.
4. Satu Format Video atau Beberapa Versi?
Ini merupakan salah satu keputusan arsitektur terpenting dalam pengiriman video.
Jika beberapa versi dimungkinkan, situs web dapat menyediakan AV1 atau VP9 untuk perangkat yang kompatibel dan menggunakan H.264 sebagai fallback bagi lingkungan lainnya. Cara ini dapat meningkatkan efisiensi kompresi sekaligus mempertahankan cakupan pemutaran yang luas.
Namun, memelihara beberapa versi berarti menambah kerumitan encoding, penyimpanan, caching, validasi, dan pemilihan format saat pemutaran.
Jika Anda membutuhkan tepat satu berkas video jadi untuk setiap sumber, strategi yang mendahulukan kompatibilitas sering kali lebih sesuai.
Saya memilih MP4/H.264 karena menginginkan satu berkas yang dapat diputar di browser utama, ponsel, dan alur kerja unduhan video yang umum tanpa bergantung pada format alternatif.
Keputusan ini bukan berarti MP4/H.264 menghasilkan kompresi terbaik. Saya hanya menempatkan pemutaran yang dapat diprediksi di atas potensi keunggulan ukuran berkas dari codec yang lebih baru.
5. Mengapa Video Seluler Memiliki Prioritas Berbeda
Kompresi video seharusnya disesuaikan dengan cara konten tersebut benar-benar dikonsumsi.
Klip pendek yang terutama ditonton di ponsel memiliki kebutuhan berbeda dari film panjang yang ditonton di televisi besar. Pada kasus pertama, pemuatan cepat dan penggunaan data seluler yang lebih hemat mungkin lebih berharga daripada mempertahankan detail visual yang sangat halus. Pada kasus kedua, kualitas gambar bisa menjadi prioritas utama.
Untuk video pendek yang ditujukan bagi perangkat seluler, berkas lebih kecil dapat memberikan beberapa keuntungan:
- Data yang perlu ditransfer sebelum pemutaran menjadi lebih sedikit.
- Unduhan dapat selesai lebih cepat pada koneksi terbatas.
- Ruang penyimpanan perangkat yang diperlukan berkurang.
- Pengguna menghabiskan lebih sedikit kuota data seluler.
- Pemutaran dapat lebih tahan terhadap keterbatasan kecepatan koneksi jika bitrate hasil encoding lebih rendah.
Namun, berkas yang lebih kecil tidak menjamin video tidak akan pernah mengalami buffering atau macet. Variasi jaringan, bitrate puncak, perilaku server, buffer pemutaran, dan kemampuan dekode perangkat juga berpengaruh.
Kompatibilitas seluler tidak hanya bergantung pada ekstensi berkas, tetapi juga pada dekode perangkat keras, profil dan level codec, kedalaman bit, subsampling kroma, resolusi, frame rate, dan bitrate puncak. Video yang ditampilkan selebar 390 piksel CSS dapat menempati jauh lebih banyak piksel fisik pada layar ponsel berkepadatan tinggi. Karena itu, memeriksa frame yang diperkecil menjadi lebar 390 piksel tidak selalu setara dengan menonton video aslinya di ponsel tersebut. Lakukan pengujian pada perangkat nyata dan kondisi pemutaran sesungguhnya.
CRF mengendalikan kualitas, bukan menetapkan batas bitrate maksimum yang pasti. Video kompleks tetap dapat memiliki lonjakan bitrate yang tinggi meskipun ukuran berkas keseluruhannya relatif kecil. Jika pemutaran yang andal pada koneksi sangat lambat sangat penting, pertimbangkan batas bitrate atau VBV yang eksplisit, pembatasan resolusi yang sesuai, dan pengujian pada kondisi jaringan realistis.
Prinsip utamanya sederhana: optimalkan pengalaman menonton yang dituju, bukan sasaran kualitas maksimum yang abstrak.
6. Memahami CRF x264: Lebih Rendah Berarti Kualitas Lebih Tinggi, Lebih Tinggi Berarti Berkas Lebih Kecil
Setelah memilih H.264, tantangan berikutnya adalah menentukan seberapa agresif video akan dikompresi.
Dalam x264, Constant Rate Factor atau CRF mengendalikan kompromi antara detail visual yang dipertahankan dan ukuran berkas.
CRF lebih rendah umumnya menghasilkan kualitas lebih tinggi dan berkas lebih besar. CRF lebih tinggi umumnya menghasilkan berkas lebih kecil dengan kehilangan kualitas kompresi yang lebih besar.
CRF tidak menetapkan bitrate atau ukuran keluaran yang pasti. Encoder mengalokasikan bit berdasarkan karakteristik sumber, sehingga adegan sederhana dan adegan dengan detail tinggi dapat menghasilkan ukuran yang sangat berbeda meskipun menggunakan CRF yang sama.
CRF juga tidak menentukan kompatibilitas dasar dekoder. Dua video H.264 yang dikodekan dengan benar pada CRF 22 dan CRF 30 dapat memiliki codec, profil, level, format piksel, dimensi, dan frame rate yang sama.
Perbedaan utamanya terletak pada kualitas kompresi dan karakteristik bitrate.
Yang penting, angka CRF tidak dapat dibandingkan secara langsung antarimplementasi codec yang berbeda. CRF 30 pada x264 tidak berarti kualitas visual yang sama dengan CRF 30 pada encoder AV1.
7. Eksperimen Kompresi Nyata Saya: CRF 22 hingga 32
Saya ingin mengetahui seberapa besar kompresi yang bisa diterapkan sebelum perbedaannya menjadi penting saat pemutaran normal.
Saya menggunakan satu video pendek yang sebelumnya sudah dikompresi, lalu membuat berkas pembanding H.264 dengan CRF 22, 24, 26, 28, 29, 30, 31, dan 32.
Karakteristik utama video tetap dipertahankan, termasuk resolusi, frame rate, durasi, dan jumlah frame. Pengujian juga memakai pengaturan encoder yang konsisten agar dampak perubahan CRF dapat dievaluasi.
Hasilnya menunjukkan perbedaan ukuran berkas yang cukup besar.
| CRF | Perkiraan Ukuran Dibandingkan Berkas Asli | Artinya |
|---|---|---|
| 22 | 63% | Kompresi lebih konservatif dengan detail yang lebih terjaga |
| 24 | 49% | Berkas lebih kecil dengan sedikit tambahan penurunan kualitas |
| 26 | 38% | Ukuran semakin hemat dengan banyak detail tetap terjaga |
| 28 | 30% | Hasil ringkas dengan kemiripan terhadap sumber yang relatif tinggi |
| 29 | 26% | Kompresi lebih agresif |
| 30 | 23% | Kompromi yang saya pilih untuk materi uji ini |
| 31 | 21% | Penghematan tambahan dengan kesetiaan yang lebih rendah terhadap sumber |
| 32 | 19% | Hasil terkecil yang diuji dan penurunan kualitas terukur paling besar |
Persentase ini berasal dari satu sumber yang diuji dan tidak boleh ditafsirkan sebagai penghematan yang lazim untuk video apa pun. Angka persentase pada tabel dibulatkan secara terpisah; untuk menghitung penghematan relatif secara tepat, gunakan ukuran berkas aslinya, bukan membagi angka hasil pembulatan.
Hasil yang paling mengejutkan adalah saya tidak melihat perbedaan visual yang berarti antara CRF 22 dan CRF 30 saat pemutaran normal, bahkan pada monitor desktop besar.
Saya juga memeriksa versi dengan kompresi yang lebih agresif, termasuk CRF 32, tanpa melihat perbedaan signifikan saat memutar klip tersebut secara biasa.
Pengamatan ini penting karena video yang sama terutama ditujukan untuk layar ponsel yang lebih kecil. Jika penurunan kualitas tidak mengganggu saat dilihat di monitor desktop saya, tidak banyak alasan untuk menerima tambahan ukuran berkas yang besar demi detail yang tidak meningkatkan pengalaman menonton sesuai tujuan saya.
Namun, ini merupakan pengamatan subjektif terhadap satu jenis materi sumber. Hal itu tidak membuktikan semua pengguna, semua ponsel, atau semua video akan memberikan hasil yang sama. Layar seluler berkepadatan piksel tinggi dan jarak pandang dekat tetap dapat memperlihatkan artefak, terutama pada detail halus atau gradasi warna.
8. Pengukuran Objektif Memastikan Adanya Penurunan Kualitas yang Nyata
Tidak terlihatnya perbedaan saat pemutaran bukan berarti dua video identik secara matematis.
Saya juga membandingkan hasil encoding melalui pengukuran kualitas gambar yang objektif. Ketika CRF meningkat, kemiripannya dengan sumber menurun.
Untuk perbandingan dengan pengecilan resolusi yang konsisten, yang dimaksudkan untuk mendekati tampilan seluler berkepadatan tinggi, beberapa pengukuran SSIM yang mewakili hasil adalah:
| CRF | Perkiraan SSIM | Ukuran Hasil Dibandingkan CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
Trennya jelas: kompresi lebih kuat menurunkan kesetiaan terukur video hasil encoding terhadap sumber. Pemeriksaan lebih dekat juga menemukan perbedaan halus pada garis tipis dan tekstur.
Meski begitu, pengalaman menonton biasa tetap sangat mirip untuk sumber yang diuji. Inilah alasan pengukuran objektif perlu digunakan bersama penilaian subjektif.
SSIM mengukur kemiripan gambar, bukan keseluruhan pengalaman visual manusia. Metrik ini tidak sepenuhnya memperhitungkan artefak temporal, ketajaman yang dirasakan, karakteristik gerakan, atau pentingnya detail visual tertentu secara subjektif.
VMAF merupakan metrik kualitas perseptual lain yang berguna. Netflix merilis model VMAF v1 pada Juni 2026, termasuk model yang dirancang berdasarkan kondisi menonton di ponsel. Model-model tersebut secara eksplisit mengakui bahwa kualitas yang dirasakan sebagian bergantung pada ukuran layar dan jarak pandang relatif.
Satu sampel dengan encoding konservatif dalam penelitian ini dilaporkan memiliki VMAF rata-rata sekitar 95. Namun, rangkaian nilai VMAF yang konsisten tidak tersedia untuk semua pengaturan CRF agresif. Karena itu, saya tidak menggunakan VMAF untuk mengklaim bahwa CRF 30 atau 32 mencapai ambang kualitas universal tertentu.
Kesimpulan praktisnya lebih terbatas: video pendek yang diuji sangat mampu mempertahankan pengalaman pemutaran normal meskipun dikompresi secara agresif dengan H.264.
9. Mengapa Saya Memilih CRF 30 untuk Video Seluler Pendek
Setelah membandingkan berkas-berkas tersebut, saya memutuskan menggunakan CRF 30 untuk video pendek serupa yang terutama ditonton di perangkat seluler.
Alasannya sederhana:
- Video tersebut pendek dan tidak ditujukan untuk kualitas gambar sinematik.
- Pemuatan cepat dan unduhan berukuran kecil merupakan prioritas.
- Saya tidak melihat perbedaan berarti antara CRF 22 dan 30 pada monitor desktop besar.
- CRF 30 menghasilkan berkas jauh lebih kecil daripada pengaturan konservatif.
- CRF 32 juga tampak dapat diterima pada sampel uji, tetapi memberi keyakinan lebih rendah untuk materi yang lebih kompleks.
Dibandingkan CRF 28, CRF 30 mengurangi ukuran keluaran yang diuji sekitar 21%. Dibandingkan CRF 22, ukurannya berkurang lebih dari 60%.
Untuk klip pendek berorientasi seluler dengan tujuan gambar yang nyaman ditonton, pemuatan cepat, dan penggunaan bandwidth yang wajar, kompromi tersebut sepadan.
Namun, syaratnya sangat penting: saya memilih 30 karena tujuan menonton yang sebenarnya dan hasil pada materi yang diuji, bukan karena 30 secara inheren merupakan CRF terbaik untuk ponsel.
Perangkat seluler tidak mengharuskan penggunaan CRF 30. Perangkat tersebut juga mampu menampilkan video berkualitas jauh lebih tinggi dengan baik. CRF 30 merupakan keputusan sadar untuk menukar sebagian kesetiaan terhadap sumber dengan berkas yang lebih kecil ketika pertukaran tersebut dapat diterima.
Sebelum menerapkannya pada koleksi berisi konten yang sangat beragam, saya akan menguji beberapa klip yang mewakili, termasuk gerakan sulit, adegan gelap, gradasi warna, teks, dan tekstur halus.
10. Mengapa Saya Tidak Merekomendasikan CRF 30 untuk Film atau Video Berkualitas Tinggi
Inilah batasan terpenting dari eksperimen saya.
Jangan menerapkan hasil CRF 30 saya begitu saja pada film panjang, konten video premium, rekaman profesional, atau video yang ditujukan untuk layar besar.
Konten semacam itu dapat mengandung gradasi halus, butiran film, adegan bercahaya rendah, gerakan kompleks, permukaan bertekstur sangat halus, dan warna yang disesuaikan secara cermat. Mempertahankan detail ini bisa lebih penting daripada menghemat bandwidth dalam jumlah yang relatif kecil.
Untuk video 1080p konvensional yang berkualitas tinggi, saya akan memulai dengan pengaturan x264 yang jauh lebih konservatif, sekitar CRF 20, lalu mengevaluasi nilai di kedua sisinya sesuai materi.
Rentang awal yang praktis mungkin CRF 18–22 ketika kesetiaan visual menjadi prioritas, meskipun nilai yang tepat dapat berada di luar rentang tersebut, tergantung resolusi, konten, dan kebutuhan.
Saran ini selaras dengan panduan encoding yang umum dipublikasikan. Sebagai contoh, dokumentasi kualitas HandBrake merekomendasikan sekitar RF 20–24 untuk banyak penggunaan x264 1080p.
Saya tidak melakukan penelitian terkontrol yang sama pada film panjang atau rekaman sinematik premium. Karena itu, saya tidak dapat mengklaim CRF 20 selalu optimal, CRF 22 selalu cukup, atau film tertentu pasti tampak buruk pada CRF 30.
Metode yang tepat adalah memilih adegan yang mewakili, mengodekannya pada beberapa tingkat kualitas, membandingkannya pada layar sasaran, lalu menentukan titik ketika kompresi tambahan mulai menimbulkan kerusakan visual yang terlihat.
Jika video akan diarsipkan, diedit lagi, atau dipakai sebagai sumber encoding di masa depan, simpan berkas master berkualitas tinggi secara terpisah dari versi terkompresi untuk distribusi.
11. Mengapa Saya Menggunakan Preset x264 veryslow
CRF mengendalikan salah satu aspek kualitas kompresi, sedangkan preset x264 mengendalikan seberapa besar upaya encoder dalam mencari keputusan pengodean yang efisien.
x264 menyediakan preset dari yang sangat cepat hingga sangat lambat. Secara umum, preset lebih lambat menggunakan lebih banyak waktu CPU dan dapat menghasilkan kompresi yang lebih efisien pada kualitas visual sebanding.
Saya membandingkan preset medium dan veryslow pada sumber yang sama. Pada pengaturan kualitas yang diuji, veryslow menghasilkan berkas lebih kecil.
Untuk encoding offline yang hanya dilakukan sekali tetapi hasilnya digunakan berulang kali, tambahan waktu pemrosesan bisa sepadan.
Karena itulah saya memilih -preset veryslow.
Namun, preset ini tidak selalu optimal. Jika video harus segera diproses, sumber daya CPU mahal, atau ada antrean encoding yang sangat besar, slow atau medium mungkin memberikan keseimbangan operasional lebih baik.
Preset terutama mengubah kompleksitas encoding dan efisiensi kompresi. Preset tidak mengubah H.264 menjadi codec lain atau secara inheren membuat hasilnya tidak kompatibel dengan perangkat seluler.
12. Untuk Video Anime, Saya Menggunakan Tune Animation pada x264
Jika sumbernya berupa animasi gambar tangan atau visual bergaya anime, saya menggunakan -tune animation pada x264.
Pengaturan ini berbeda dari CRF. Sebuah tune mengubah beberapa keputusan encoder agar sesuai dengan karakteristik visual tertentu. Tune animation ditujukan untuk materi dengan garis gambar, bidang warna rata, dan gerakan bergaya.
Karena itu, preferensi saya adalah:
- Anime atau video animasi gambar tangan:
-preset veryslow -tune animation. - Rekaman biasa dengan objek nyata: jangan otomatis mengaktifkan tune animation; mulai dari pengaturan bawaan encoder atau evaluasi tune lain secara terpisah.
Penting untuk memahami batasannya. -tune animation tidak menjamin kualitas yang tampak lebih baik atau ukuran berkas lebih kecil. Pengaturan ini mengubah perilaku encoder, dan hasilnya bergantung pada materi.
Saya melakukan perbandingan terpisah pada CRF tetap dengan menggunakan tune animation. Dalam perbandingan tersebut, pengaktifannya membuat berkas sekitar 6% lebih besar dan sedikit meningkatkan kemiripan gambar yang terukur. Perbedaan visualnya kecil.
Perbandingan utama ukuran berkas pada CRF 22–32 dilakukan tanpa tune animation. Oleh karena itu, ukuran dan rasio kompresi persis dari eksperimen tersebut tidak boleh diasumsikan tetap sama ketika -tune animation diaktifkan.
Meski demikian, untuk rekaman anime, saya lebih suka menggunakan tune khusus animasi dan mengevaluasi ukuran serta kualitas hasilnya sebagai bagian dari profil encoding konten tersebut.
Penyesuaian encoder sebaiknya selalu dipandang sebagai pengaturan yang bergantung pada konten, bukan peningkatan kualitas yang berlaku universal.
13. Pengaturan FFmpeg yang Saya Sarankan untuk Video Anime Pendek Berorientasi Seluler
Untuk video anime SDR konvensional yang memang perlu ditranskode, perintah berikut menggambarkan profil yang akan saya gunakan sebagai titik awal:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Perintah ini memperjelas pilihan utama:
-c:v libx264menggunakan encoder H.264 berbasis perangkat lunak.-preset veryslowmengutamakan efisiensi kompresi daripada kecepatan encoding.-tune animationmengaktifkan penyesuaian encoder yang ditujukan untuk animasi.-crf 30menerapkan sasaran kualitas konstan yang agresif untuk jenis video pendek ini.-profile:v highmemilih profil H.264 yang umum didukung perangkat modern.-pix_fmt yuv420pmenghasilkan video 8-bit 4:2:0.-map 0:v:0memilih aliran video pertama.-map '0:a:0?'memilih aliran audio pertama jika tersedia.-c:a aac -b:a 128kmengodekan audio AAC konvensional jika sumber memiliki audio.-movflags +faststartmemindahkan metadata inisialisasi MP4 ke dekat awal berkas.
Ini hanya contoh, bukan perintah universal untuk semua sumber. Kebutuhan khusus video sumber Anda mungkin memerlukan penanganan tambahan.
Secara khusus, materi HDR dan 10-bit tidak boleh langsung dikonversi menjadi SDR 8-bit tanpa manajemen warna yang tepat. Konversi sembarangan dapat menghasilkan warna yang keliru, hilangnya detail area terang, atau pita warna yang terlihat. Metadata rotasi, frame rate variabel, rasio aspek sampel, sumber interlaced, tata letak audio yang tidak biasa, dan batasan resolusi yang tidak kompatibel juga perlu diperhatikan.
Jika frame rate dan dimensi sumber sudah sesuai, mempertahankannya umumnya memudahkan perbandingan dan menghindari perubahan skala atau gerakan yang tidak diperlukan. Hindari memaksakan frame rate konstan pada sumber dengan frame rate variabel kecuali memang diperlukan: konversi dapat menggandakan atau membuang frame. Jika mengubah ukuran, pertahankan rasio aspek tampilan dan pastikan dimensi kompatibel dengan format piksel 4:2:0 yang dipilih. Resolusi, frame rate, atau level H.264 yang sangat tinggi dapat melampaui kemampuan dekode perangkat lama, sehingga kompatibilitas kadang memerlukan penurunan resolusi atau frame rate secara sengaja.
14. Titik Awal FFmpeg yang Lebih Konservatif untuk Video Berkualitas Tinggi
Jika kesetiaan visual video jauh lebih penting daripada ukuran berkas, mulailah dengan CRF lebih rendah dan evaluasi hasilnya.
Misalnya, perintah berikut merupakan titik awal eksperimen yang masuk akal untuk video SDR konvensional dengan rekaman nyata:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Preset slow dalam contoh ini adalah titik awal serbaguna yang praktis, bukan klaim bahwa preset tersebut mengungguli veryslow. Menggunakan veryslow juga masuk akal jika tambahan waktu encoding dapat diterima.
Profil berkualitas tinggi ini adalah rekomendasi untuk diuji, bukan konfigurasi yang sudah dibuktikan melalui eksperimen video pendek saya.
Untuk video premium, uji nilai CRF sekitar 18, 20, dan 22, kemudian pilih berdasarkan hasil yang terlihat. Butiran film atau gerakan yang sulit mungkin membutuhkan pengaturan lain, sedangkan berkas master arsip mungkin memerlukan kompresi yang jauh lebih ringan.
15. Jangan Mengodekan Ulang Video Tanpa Alasan
Kompresi video lossy selalu memiliki konsekuensi. Mengodekan ulang berkas yang sudah dikompresi dapat menimbulkan artefak tambahan, sekalipun hasil barunya terlihat mirip dengan sumber.
Sebelum melakukan transkode, tanyakan apakah berkas asli sudah memenuhi kebutuhan kompatibilitas, ukuran, dan kualitas Anda.
Jika berkas sudah berisi video H.264 dan audio AAC yang kompatibel, serta tidak perlu ada perubahan visual, menyalin aliran data mungkin lebih baik daripada melakukan encoding lossy sekali lagi.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Operasi ini menyalin aliran data yang sudah terkompresi tanpa mengodekannya ulang. Susunan kontainer dapat berubah, tetapi tidak terjadi generasi baru kehilangan kualitas akibat kompresi video.
Biasanya, cara ini tidak memberikan pengurangan ukuran berkas sebesar ketika kualitas diturunkan melalui encoding baru.
Jika video yang Anda miliki sudah ringkas, kompatibel, dan cukup baik secara visual, mempertahankannya mungkin justru merupakan optimasi terbaik.
16. Validasi Video Hasil Encoding, Jangan Hanya Mempercayai Ukuran Berkas
FFmpeg yang selesai dengan kode keluar sukses tidak otomatis membuktikan bahwa video sudah memenuhi semua persyaratan.
Mulailah dengan memeriksa aliran data hasilnya menggunakan FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Periksa codec, format piksel, dimensi, frame rate, durasi, dan aliran audio.
Selanjutnya, dekode seluruh berkas untuk mendeteksi jenis kerusakan atau kesalahan dekode tertentu:
ffmpeg -v error -xerror -i output.mp4 -f null -Dalam eksperimen kompresi, bandingkan hasil yang dibuat dari sumber yang sama. Pertahankan variabel penting agar tetap konstan dan ubah hanya satu pengaturan utama setiap kali pengujian.
Tonton video hasilnya saat bergerak, periksa detail halus, dan perhatikan gradasi warna, area gelap, objek bergerak, serta teks.
Jika memungkinkan, gunakan metrik objektif seperti SSIM, PSNR, atau VMAF untuk melengkapi perbandingan visual. Jangan menganggap satu skor tinggi sebagai bukti bahwa semua artefak tidak terlihat.
Terakhir, uji video pada perangkat yang mewakili pengguna dan dalam alur kerja membuka berkas unduhan. Informasi dukungan browser memang berguna, tetapi pengujian pemutaran sesungguhnya sangat penting jika kompatibilitas merupakan prioritas utama.
17. Pastikan Berkas MP4 Anda Dikirim dengan Benar
Pengaturan encoding yang bagus tidak dapat menutupi pengiriman video web yang buruk.
Untuk pemutaran MP4 progresif biasa, atur header Content-Type: video/mp4 yang tepat dan dukung permintaan byte-range HTTP ketika pengambilan sebagian data dan perpindahan posisi pemutaran diperlukan.
Opsi FFmpeg +faststart memindahkan informasi inisialisasi MP4 ke dekat awal berkas konvensional. Hal ini membantu pemuatan progresif, tetapi tidak meningkatkan kualitas visual atau mengurangi bitrate.
Elemen video HTML sederhana dapat menyajikan satu MP4 H.264:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>Atribut preload adalah petunjuk bagi browser, bukan batas unduhan yang ketat. Kebijakan autoplay browser juga mungkin mengharuskan video dibisukan atau tidak memiliki suara.
Jika halaman memuat banyak video, hindari mengunduh semuanya sekaligus sejak awal. Memuat video hanya ketika diperlukan dapat menghemat data seluler dan meningkatkan responsivitas yang dirasakan.
Untuk klip seluler pendek, mengoptimalkan jadwal unduhan dapat sama pentingnya dengan mengurangi ukuran berkas hasil encoding.
18. Format dan Kualitas Video Apa yang Sebaiknya Dipilih?
Jawaban yang tepat bergantung pada hal yang ingin Anda optimalkan.
| Tujuan Anda | Titik Awal yang Disarankan |
|---|---|
| Satu video untuk web dan unduhan dengan kompatibilitas luas | MP4 + H.264 + AAC jika ada audio |
| Pengiriman melalui browser modern dengan beberapa pilihan format | AV1 atau VP9, dengan H.264 sebagai fallback |
| Kompresi maksimum pada perangkat yang mendukung | Evaluasi AV1 |
| Lingkungan pemutaran terkendali yang mendukung HEVC | Pertimbangkan MP4 + HEVC |
| Klip pendek untuk seluler saat ukuran berkas paling penting | Pertimbangkan x264 CRF 30 setelah pengujian pada sampel representatif |
| Anime atau video animasi gambar tangan | Evaluasi x264 dengan -tune animation |
| Film berkualitas tinggi atau video premium | Mulai dengan CRF yang lebih konservatif, sekitar 20, lalu uji |
| Encoding offline saat waktu CPU kurang menjadi masalah | Pertimbangkan x264 slow atau veryslow |
| Pemrosesan cepat dengan sumber daya CPU terbatas | Pertimbangkan x264 medium atau slow |
| Video yang ada sudah memenuhi kebutuhan Anda | Pertahankan atau kemas ulang tanpa encoding ulang |
| Pengarsipan atau pengeditan di masa mendatang | Simpan berkas master berkualitas tinggi secara terpisah dari berkas distribusi |
19. Keputusan Akhir Saya dan Apa yang Sebenarnya Dibuktikan Eksperimen Ini
Setelah meneliti format video, kompatibilitas, efisiensi encoding, dan hasil kompresi nyata, saya memilih profil distribusi praktis untuk video pendek yang terutama ditujukan bagi perangkat seluler.
Format yang saya pilih adalah MP4 dengan H.264, karena kompatibilitas yang dapat diprediksi di browser, ponsel, alur unduhan, dan aplikasi eksternal lebih penting daripada mendapatkan berkas sekecil mungkin dengan codec yang lebih baru.
Encoder yang saya pilih adalah libx264 dengan preset veryslow, karena video dapat dikodekan secara offline dan tambahan waktu pemrosesannya dapat diterima.
Untuk video anime, saya menggunakan tune animation, sambil menyadari bahwa pengaturan ini mengubah perilaku encoder dan tidak menjamin berkas lebih kecil atau kualitas visual yang selalu lebih baik.
Untuk video pendek berorientasi seluler, saya memilih CRF 30, karena perbandingan yang saya lakukan menunjukkan pengurangan ukuran berkas yang besar tanpa perbedaan visual berarti selama pemutaran normal, bahkan ketika dibandingkan pada monitor desktop besar.
Hasil itu bukan berarti CRF 30 adalah pengaturan ideal bagi film atau rekaman berkualitas tinggi. Untuk konten yang lebih mengutamakan detail halus, gradasi, butiran film, dan kesetiaan visual secara keseluruhan, saya akan mulai menguji sekitar CRF 20 atau nilai lain yang cukup konservatif. Saya tidak melakukan penelitian terkontrol yang setara pada rekaman sinematik, sehingga angka tersebut tidak saya nyatakan sebagai nilai optimal yang terbukti melalui eksperimen.
Kesimpulan terpenting adalah tidak ada satu codec, format, atau nilai CRF yang secara universal paling baik untuk semua video.
Jika Anda mengutamakan kompatibilitas maksimum dan hanya menginginkan satu berkas, MP4/H.264 merupakan pilihan awal yang kuat. Jika Anda bisa menyediakan format cadangan dan menginginkan kompresi lebih baik, pelajari VP9 dan AV1. Jika Anda mengodekan video pendek yang terutama ditonton di ponsel, uji apakah CRF lebih tinggi menghasilkan berkas yang cukup kecil tanpa merusak pengalaman menonton yang dituju. Jika Anda mengodekan film atau rekaman premium, gunakan pengaturan kualitas lebih konservatif dan periksa hasilnya dengan cermat.
Tentukan kebutuhan pemutaran terlebih dahulu, pilih codec berikutnya, lalu tetapkan kualitas kompresi terakhir. Setelah itu, uji hasilnya pada perangkat dan kondisi yang benar-benar relevan. Pendekatan ini lebih andal daripada langsung mengikuti suatu codec atau nilai CRF hanya karena lebih baru, lebih efisien, atau sering direkomendasikan.