FFmpeg untuk Pemula: Perintah yang Sebenarnya Anda Butuhkan
Perintah FFmpeg pertama saya membutuhkan waktu 45 menit untuk ditulis dan menghasilkan file 0 byte. Saya menyalinnya dari Stack Overflow, mengganti nama file input, menekan enter, dan melihat terminal menggulir dengan pesan-pesan sulit tentang "muxing overhead" dan "duplikasi bingkai" sebelum mengeluarkan file yang tidak bisa dibuka di pemutar mana pun. Saya mencoba lagi. File 0 byte lainnya. Coba ketiga membuat laptop saya crash. Sekarang, tujuh tahun kemudian, saya dapat mengubah format apa pun dalam tidur saya. Saya telah menulis lebih dari 10.000 perintah FFmpeg untuk segala sesuatu mulai dari grading warna HDR 4K hingga pipeline streaming waktu nyata yang menangani jutaan pemirsa. Saya mengelola wiki FFmpeg internal perusahaan kami, yang telah berkembang menjadi 247 halaman resep, jebakan, dan pengetahuan yang sulit diperoleh tentang keanehan codec yang tidak didokumentasikan di tempat lain. Inilah yang ingin saya katakan kepada saya pada hari pertama: FFmpeg tidak sulit karena sintaksisnya rumit. Ini sulit karena tidak ada yang menjelaskan model mentalnya. Setelah Anda memahami bagaimana FFmpeg memikirkan aliran, kontainer, dan codec, semuanya akan mulai masuk akal. Anda berhenti menyalin perintah secara membabi buta dan mulai menyusunnya seperti kalimat. Panduan ini berisi perintah yang benar-benar saya gunakan setiap minggu, bukan kasus tepi eksotis yang mengisi sebagian besar tutorial. Ini adalah kuda kerja yang menangani 90% tugas video dunia nyata. Saya akan menjelaskan bukan hanya apa yang dilakukan setiap perintah, tetapi juga mengapa itu berhasil dan kapan Anda akan memilihnya dibandingkan alternatif lainnya.Bagaimana FFmpeg Sebenarnya Bekerja (Dan Mengapa Perintah Pertama Anda Gagal)
FFmpeg beroperasi pada prinsip sederhana yang salah dimengerti semua orang pada awalnya: ia membaca aliran dari input, memprosesnya melalui filter, dan menulisnya ke output. Kebingungan muncul dari fakta bahwa satu file video berisi beberapa aliran—biasanya satu aliran video, satu atau lebih aliran audio, dan terkadang aliran subtitle atau aliran metadata. Ketika Anda menjalankan `ffmpeg -i input.mp4 output.mp4`, FFmpeg membuat banyak asumsi tentang apa yang Anda inginkan. Ia memilih aliran video "terbaik", aliran audio "terbaik", menyalinnya melalui pengkode default, dan menggabungkannya ke dalam kontainer output. Ini berfungsi dengan baik untuk konversi sederhana, tetapi mulai runtuh saat Anda memerlukan kontrol. Alasan mengapa perintah pertama saya menghasilkan file 0 byte adalah karena saya telah menentukan kombinasi codec dan kontainer yang tidak kompatibel. Saya mencoba memasukkan aliran video VP9 ke dalam kontainer MP4, yang tidak didukung. FFmpeg mulai mengenkode, menyadari bahwa ia tidak bisa menulis output, dan menyerah. Pesan kesalahan terkubur dalam 200 baris output yang tidak tahu bagaimana membacanya. Inilah model mental yang mengubah segalanya bagi saya: pikirkan FFmpeg sebagai jalur dengan tiga tahap. Pertama, demuxing—FFmpeg membuka file input Anda dan memisahkannya menjadi aliran individu. Kedua, pemrosesan—setiap aliran melewati codec (pengkode/pengdecod) dan filter opsional. Ketiga, muxing—aliran yang telah diproses dikemas ke dalam kontainer output. Setiap perintah FFmpeg mengikuti pola ini: ``` ffmpeg [global options] [input options] -i input [output options] output ``` Urutannya sangat penting. Opsi sebelum `-i` berlaku untuk input. Opsi setelah `-i` berlaku untuk output. Jika Anda menempatkan `-c:v libx264` sebelum `-i`, FFmpeg akan mencoba mendekode input sebagai H.264, yang mungkin bukan yang Anda inginkan. Letakkan setelah `-i`, dan ia mengkode output sebagai H.264. Konsep penting lainnya adalah penentu aliran. Ketika Anda menulis `-c:v`, Anda mengatakan "terapkan codec ini ke aliran video." `-c:a` menargetkan aliran audio. `-c:s` menargetkan subtitle. Anda dapat menjadi lebih spesifik dengan `-c:v:0` untuk aliran video pertama atau `-c:a:1` untuk aliran audio kedua. Setelah saya memahami struktur ini, saya berhenti menghasilkan file 0 byte. Saya dapat membaca output FFmpeg dan memahami apa yang dilakukannya di setiap tahap. Saya bisa memecahkan masalah dengan mengisolasi apakah masalah ada di demuxing, pemrosesan, atau muxing.Hari Ketika Saya Mengubah 50.000 Video (Dan Apa yang Saya Pelajari)
Tiga tahun yang lalu, perusahaan kami mengakuisisi pesaing. Bagian dari akuisisi termasuk seluruh perpustakaan video mereka—50.000 video dalam format yang kami tidak dukung. Mereka telah menggunakan codec proprietary yang memerlukan pemutar khusus, dan kami perlu mengonversi semuanya ke H.264 standar untuk platform kami. Pendekatan naif adalah menulis loop sederhana: untuk setiap video, jalankan FFmpeg dengan pengaturan dasar, tunggu sampai selesai, pindah ke yang berikutnya. Dengan rata-rata waktu 2 menit per video, itu akan memakan waktu 69 hari pemrosesan terus-menerus. Kami hanya memiliki dua minggu. Proyek ini mengajarkan saya lebih banyak tentang FFmpeg daripada tiga tahun sebelumnya digabungkan. Saya belajar tentang akselerasi perangkat keras, pemrosesan paralel, dan puluhan pengaturan pengkode yang benar-benar penting. Saya belajar tentang indikator kualitas yang berarti dan yang merupakan omong kosong pemasaran. Yang paling penting, saya belajar bahwa perintah FFmpeg "terbaik" sepenuhnya tergantung pada batasan Anda. Kami akhirnya membangun sistem pengkodean terdistribusi yang memproses 200 video secara bersamaan di 40 mesin. Setiap mesin menjalankan 5 instance FFmpeg, diatur dengan cermat untuk memaksimalkan penggunaan CPU tanpa thrashing. Kami menggunakan pengkodean yang dipercepat perangkat keras jika tersedia, tetapi pengkodean perangkat lunak karena perbedaan kualitasnya signifikan untuk kasus penggunaan kami. Perintah yang kami pilih terlihat seperti ini: ```bash ffmpeg -hwaccel auto -i input.mov \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -movflags +faststart \ -max_muxing_queue_size 1024 \ output.mp4 ``` Biarkan saya memecahkan mengapa setiap opsi itu penting. `-hwaccel auto` memberi tahu FFmpeg untuk menggunakan dekoding perangkat keras jika tersedia—ini mempercepat waktu dekode kami hingga 60% pada mesin dengan GPU yang kompatibel. `-preset medium` menyeimbangkan kecepatan pengkodean dengan efisiensi kompresi. Kami menguji semua preset; `medium` adalah titik manis yang memberi kami 95% kualitas `slower` dalam setengah waktu. Pengaturan `-crf 23` mengontrol kualitas menggunakan Faktor Laju Konstan. Nilai yang lebih rendah berarti kualitas lebih tinggi dan file lebih besar. Kami menguji nilai CRF dari 18 hingga 28 pada sampel 100 video dan meminta tim video kami untuk melakukan perbandingan kualitas secara buta. Tidak ada yang bisa dengan handal membedakan CRF 23 dari CRF 20, tetapi ukuran file lebih kecil 30%. `-movflags +faststart` memindahkan atom moov ke awal file, yang memungkinkan pemutaran progresif melalui HTTP. Tanpa flag ini, browser harus mengunduh seluruh file sebelum bisa mulai memutar. Opsi ini saja meningkatkan metrik pengalaman pengguna kami sebesar 15%. Opsi `-max_muxing_queue_size 1024` memecahkan masalah yang membuat kami menghabiskan tiga hari untuk debugging. Beberapa video sumber memiliki frame rate variabel yang menyebabkan buffer internal FFmpeg meluber. Ukuran antrian default adalah 8 paket, yang tidak cukup untuk konten VFR. Meningkatkannya menjadi 1024 menghilangkan kesalahan "Terlalu banyak paket yang dibuffer untuk aliran output" yang gagal 5% konversi kami. Kami menyelesaikan proyek dalam 11 hari. Sistem terdistribusi memproses 4.545 video per hari, dengan tingkat keberhasilan 99,2%. Kegagalan semuanya berasal dari file sumber yang rusak atau menggunakan codec yang tidak bisa kami dekode. Saya masih menggunakan variasi perintah itu hari ini—itu adalah fondasi dari seluruh pipeline pemrosesan video kami.Matriks Kompatibilitas Codec dan Kontainer
Salah satu aspek paling frustrasi dari FFmpeg bagi pemula adalah memahami codec mana yang bekerja dengan kontainer mana. Anda bisa menghabiskan satu jam merancang perintah yang sempurna hanya agar gagal karena Anda mencoba menempatkan codec yang tidak kompatibel dalam kontainer yang tidak mendukungnya. Berikut adalah matriks kompatibilitas yang selalu saya rujuk:| Kontainer | Codec Video | Codec Audio | Terbaik Untuk |
|---|---|---|---|
| MP4 | H.264, H.265, AV1 | AAC, MP3, Opus | Pemutaran web, perangkat seluler, kompatibilitas universal |
| WebM | VP8, VP9, AV1 | Vorbis, Opus | Streaming web, proyek sumber terbuka, YouTube |
| MKV | Apa saja | Apa saja | Arsip, beberapa trek audio, subtitle |
| MOV | H.264, ProRes, DNxHD | AAC, PCM | Penyuntingan profesional, ekosistem Apple |
| AVI | MPEG-4, H.264 (terbatas) | MP3, PCM | Sistem lama (hindari untuk proyek baru) |
| TS | H.264, H.265, MPEG-2 | AAC, MP3, AC-3 | Siaran, streaming HLS |
Pengaturan Kualitas yang Tidak Ada yang Menjelaskan Dengan Benar
Setiap tutorial FFmpeg memberi tahu Anda untuk menggunakan `-crf 23` untuk "kualitas baik" atau `-b:v 5M` untuk "5 megabit per detik." Tetapi tidak ada yang menjelaskan apa sebenarnya pengaturan ini lakukan atau bagaimana memilih nilai yang tepat untuk konten Anda. Saya telah menghabiskan ratusan jam menguji pengaturan kualitas pada berbagai jenis konten. Inilah yang saya pelajari: tidak ada pengaturan "terbaik" universal. Parameter kualitas yang optimal tergantung pada jenis konten Anda, audiens target, dan metode distribusi."Faktor Laju Konstan (CRF) adalah mode pengkodean berbasis kualitas di mana Anda menentukan tingkat kualitas dan membiarkan pengkode menggunakan sebanyak mungkin bit yang diperlukan untuk mencapai kualitas tersebut. Nilai CRF yang lebih rendah berarti kualitas lebih tinggi dan file lebih besar. Rentangnya adalah 0-51 untuk H.264, di mana 0 adalah lossless dan 51 adalah kualitas terburuk yang mungkin. Defaultnya adalah 23, yang dianggap 'secara visual transparan' untuk sebagian besar konten—berarti kebanyakan orang tidak bisa membedakannya dari sumber."Masalah dengan CRF adalah bahwa ia menghasilkan output bitrate variabel. Adegan aksi dengan gerakan tinggi mungkin menggunakan 10 Mbps sementara adegan berbicara statis menggunakan 2 Mbps. Ini efisien untuk ukuran file, tetapi bisa menyebabkan masalah untuk streaming di mana Anda memerlukan penggunaan bandwidth yang dapat diprediksi. Untuk streaming, Anda ingin bitrate konstan (CBR) atau bitrate variabel dengan batasan (VBR). Inilah perintah yang saya gunakan untuk streaming: ```bash ffmpeg -i input.mp4 \ -c:v libx264 -preset medium \ -b:v 5M -maxrate 5M -bufsize 10M \ -c:a aac -b:a 128k \ output.mp4 ``` Opsi `-b:v 5M` menetapkan bitrate target ke 5 megabit per detik. `-maxrate 5M` memastikan ia tidak pernah melebihi laju tersebut. `-bufsize 10M` menetapkan ukuran buffer pengode menjadi dua kali lipat dari bitrate, yang merupakan rekomendasi standar. Ini menghasilkan output yang dapat di-streaming dengan lancar tanpa buffering. Tetapi inilah yang biasanya salah dipahami banyak orang: kebutuhan bitrate berukuran dengan resolusi dan gerakan, bukan secara linier. Video 1080p tidak memerlukan dua kali bitrate video 720p—ia membutuhkan sekitar 1,5x. Video 4K tidak memerlukan empat kali bitrate 1080p—ia membutuhkan sekitar 2,5x.
"Sistem visual manusia bersifat logaritmik, bukan linier. Menggandakan bitrate tidak..."