Belajar FFmpeg lewat Contoh

 (ffmpegbyexample.com)
9 poin oleh GN⁺ 2025-01-15 | 1 komentar | Bagikan ke WhatsApp
  • Operasi FFmpeg mudah menjadi rumit karena kombinasi opsinya, dan FFmpeg By Example adalah situs dokumentasi yang membantu Anda cepat menemukan cara pemrosesan media yang dibutuhkan melalui contoh perintah nyata
  • Situs ini juga menyediakan repositori GitHub, komunitas Discord, dan halaman kontribusi, sehingga pengguna dapat mengirimkan sendiri ide pemanfaatan FFmpeg baru
  • Seperti contoh filter testsrc, situs ini menampilkan sumber input, resolusi, frame rate, dan file output dalam satu perintah, sehingga struktur perintahnya bisa langsung diikuti
  • Contohnya mencakup berbagai pekerjaan pemrosesan media, seperti perhitungan bitrate, resize gambar, pengurangan noise audio, efek transisi, stream mapping, akselerasi hardware, dan penanganan metadata
  • Setiap contoh dipisahkan dengan tag dan halaman tersendiri, sehingga mudah menelusuri perintah FFmpeg yang dibutuhkan berdasarkan filter tertentu atau tujuan konversi

Situs dokumentasi FFmpeg berbasis contoh

  • FFmpeg By Example adalah situs web yang merangkum berbagai cara menggunakan FFmpeg dalam unit contoh
  • Situs ini juga menyediakan tautan untuk partisipasi komunitas dan kontribusi

Contoh membuat video uji dengan testsrc

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 testsrc.mpg

Encoding, konversi, dan akselerasi hardware

Pemrosesan audio

Gambar dan animasi

Filter dan efek visual

Ekstraksi, analisis, dan metadata

Sumber generatif dan pipe output

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-15
Opini Hacker News

  • Kesenangan memakai ffmpeg meningkat 1000%
    Dulu saya bosan mencari jawaban Stack Overflow lewat Google lalu merangkainya jadi perintah, tapi sekarang ChatGPT menuliskan perintahnya untuk saya jadi jauh lebih nyaman

    • Berkat LLM, saya memakai ffmpeg beberapa kali seminggu
      Ini adalah penggunaan terbaik untuk alat llm cmd saya:

      uv tool install llm
      llm install llm-cmd

      llm cmd use ffmpeg to extract audio from myfile.mov and save that as mp3

      https://github.com/simonw/llm-cmd

    • Sudah lama saya menempatkan ffmpeg di kotak yang sama dengan regex: “saya benar-benar harus mempelajarinya, tapi rasanya saya akan sangat membencinya”
      Lalu ChatGPT muncul dan menyelesaikan keduanya

    • Saya juga sama. Hal seperti ini sudah sepenuhnya diambil alih AI, dan saya cuma perantara yang menyalin-tempel pelacakan error

    • Banyak alat lain juga sudah muncul, tapi saya baru saja membuat skrip yang cukup menyederhanakan rantai perintah seperti ini: llmpeg https://github.com/jjcm/llmpeg
      Seharusnya langsung berjalan jika ffmpeg sudah terpasang dan API key variabel lingkungan OpenAI sudah disetel

      Demo: https://image.non.io/1c7a92ef-0917-49ef-9460-6298c7a9116c.we...

    • Setelah memahami cara kerja filter kompleks, pengalaman saya memakai ffmpeg jadi lebih baik

  • Saya jadi terpikir bahwa saya harus merapikan dan mempublikasikan cara mengubah kaset video rumahan yang sudah didigitalkan menjadi klip dengan deteksi adegan
    Kalau-kalau ada yang mencarinya, saya meninggalkan gist [0] yang bekerja cukup baik. Namun kadang ia tertipu oleh flash kamera atau guncangan, jadi saya harus memberi file awal/akhir terpisah lalu menyambungkannya lagi dengan ffmpeg [1]

    Yang aneh, pada update Mac terbaru performanya justru lebih baik tanpa -c:v h264_videotoolbox. Mungkin ini regresi performa di Sequoia, tapi saya tidak yakin. Flag yang setara di mesin Windows dengan GPU Nvidia adalah -c:v h264_nvenc. Saya penasaran kenapa ffmpeg tidak mendeteksinya secara otomatis. Dengan ini saya mendapat sekitar peningkatan performa 8x
    Satu-satunya momen di kantor ketika saya benar-benar terasa layak digaji adalah saat saya menyadari bahwa ffmpeg yang terpasang dikompilasi tanpa akselerasi GPU, tepat ketika mereka hendak mengeluarkan biaya lebih untuk server cloud ber-GPU demi pemrosesan video

    [0] https://gist.githubusercontent.com/nielsbom/c86c504fa5fd61ae...

    [1] https://gist.githubusercontent.com/jazzyjackson/bf9282df0a40...

    • Masalah dengan CPU cloud adalah tidak adanya encoder video hardware yang ada di CPU konsumen, jadi Anda harus naik ke mesin GPU yang jauh lebih mahal
      Sejujurnya saya belum pernah membandingkan harga secara serius dengan memakai akselerasi hardware di cloud, jadi saya penasaran apakah maksudnya Anda benar-benar sudah mencobanya dan hasil biaya vs manfaatnya cukup layak

    • Saya pernah mencoba deteksi adegan kosong dengan ffmpeg
      Ada kamera yang mengarah ke jalur penerbangan SFO, dan setelah semua frame tanpa gerakan dihapus, yang tersisa hanyalah rangkaian video kontinu saat pesawat melintas tanpa bagian membosankan

    • -c:v h264_nvenc berguna untuk batch encoding banyak video sekaligus. Karena throughput encoding bisa lebih tinggi
      Namun dari eksperimen terbatas yang pernah saya lakukan dulu, kualitas output-nya sedikit lebih buruk daripada libx264. Saya tidak tahu apakah ada cara mengatasinya, tapi ini bukan hanya saya yang mengalaminya

    • Alasan ffmpeg tidak mendeteksi ini secara otomatis adalah karena encoding hardware biasanya punya rentang pengaturan yang lebih sempit dan komprominya lebih besar dibanding codec software yang lebih canggih, serta tidak selalu menghasilkan keluaran yang persis sama bahkan dengan parameter yang sama
      Selain itu, sering kali ada beberapa API hardware yang bisa dipilih di sistem, dan kemampuannya juga berbeda-beda

      FFmpeg adalah alat command line yang kompleks dan ditujukan untuk pengguna yang mau mempelajari detailnya, jadi saya tidak yakin menetapkan default berdasarkan asumsi adalah pilihan yang tepat

    • Dari snippet-nya, sepertinya tidak ada deinterlace
      Jika klip sebelum didigitalkan memang sudah di-deinterlace, tidak masalah, tetapi jika tidak, berarti Anda merusak kualitas materi interlaced dengan mengenkodenya sebagai progressive. Sebaiknya tambahkan filter bwdif agar konten 30i dienkode menjadi 60p. Hasilnya akan terlihat lebih mirip dengan kaset video aslinya

  • Seiring waktu saya jadi cukup terbiasa dengan berbagai bagian ffmpeg. CLI-nya punya logika tersendiri, dan bergantung pada urutan. Tidak semua Unix CLI seperti itu
    Belakangan ini saya mengutak-atik fitur yang lebih rumit. Misalnya menyimpan langsung rekaman mentah dari kamera video pada mesin yang cukup lambat. Saya membuat mikroskop, dan membaca frame dari kamera dalam format video mentah 120FPS (YUYV 1280x720), tetapi kalau disimpan begitu saja ke disk ukurannya membengkak sampai gigabita per menit. Disk memang murah, tapi tetap terasa boros, jadi saya meneliti teknik yang nyaris lossless untuk mengompres dan menyimpan citra akurat dengan cepat

    Saya mendapati bahwa konversi RGB24 di ffmpeg sangat lambat, jadi setelah mengutak-atik command line cukup lama, saya akhirnya menetap pada ini:

    ffmpeg -f rawvideo -pix_fmt yuyv422 -s 1280x720 -i test.raw -vcodec libx264 -pix_fmt yuv420p movie.mp4 -crf 13 -y

Video mentah tidak memiliki kontainer sehingga tidak punya metadata seperti “format piksel” atau “ukuran gambar”, jadi itu harus diberikan secara manual. Ini bergantung pada urutan, jadi semua yang ada sebelum -i test.raw dipakai untuk dekode input, dan semua yang setelahnya dipakai untuk penulisan output. Hanya melakukan satu konversi format piksel yang sangat kecil saja (yang bisa diproses ffmpeg dengan sangat cepat), lalu menulis data dalam format nyaris lossless yang memiliki kontainer. Dalam kebanyakan kasus, kontainer .mkv adalah yang terbaik

Karena tidak suka command line, akhirnya saya memakai ffmpeg-python dan membiarkannya menyusun command line dari kode berikut:

self.process = (
ffmpeg.
input(
"pipe:",
format="rawvideo",
pix_fmt="yuyv422",
s="{}x{}".format(1280, 720),
threads=8
)
.output(
fname, pix_fmt="yuv422p", vcodec="libx264", crf=13
)
.overwrite_output()
.global_args("-threads", "8")
.run_async(pipe_stdin=True)
)

Lalu pada praktiknya frame ditulis ke stdin proses tersebut dengan write(). Mesin saya punya 12 core, dan karena setidaknya 2 core selalu dipakai untuk menggerakkan mikroskop, jumlah thread perlu dibatasi

Saya masih mencari encoding YUV lossless yang lebih baik dan lebih cepat

  • Ketergantungan pada urutan itu masuk akal. Pipeline Unix juga bergantung pada urutan komponen, dan pemanggilan FFMpeg yang kompleks melakukan hal yang mirip dengan itu
    Banyak orang menyukai estetika “fluent interface” seperti ffmpeg-python, tetapi dalam Python itu sering dianggap kurang Pythonic. Sepemahaman saya, ffmpeg-python memang dirancang untuk merefleksikan urutan command line dengan cukup dekat

    Preferensi yang diperkuat oleh desain pustaka standar dan tipe bawaan adalah https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... yang cukup kuat. Menurut prinsip ini, bentuknya kira-kira akan seperti berikut:

    ffmpeg(global_args=..., overwrite_output=True).process_async(piped_input(...), output(...))

    Jika input dijadikan proses konfigurasi terpisah, akan muncul tipe runtime lain dan itu juga bisa memberi sinyal pada kode pemrosesan bahwa data harus dibaca dari stdin

  • Tidak perlu mencari lagi: FFV1 https://trac.ffmpeg.org/wiki/Encode/FFV1

  • Saya cuma ingin merekomendasikan satu kata: ramdisk
    Jika ada file untuk tahap perantara yang perlu diproses tetapi tidak ingin disimpan, gunakan ramdisk. Benar-benar bagus

  • Saya kira ini akan menjadi situs web yang mengumpulkan dan mengelola pengetahuan yang dibangun para ahli FFmpeg, tetapi langsung kecewa dari contoh pertama yang saya klik
    https://www.ffmpegbyexample.com/examples/l1bilxyl/get_the_du...

    Jangan memanggil dua alat tambahan hanya untuk memproses string. Dengan FFprobe saja, Anda bisa langsung mendapatkan durasi atau nilai yang diinginkan:

    ffprobe -loglevel quiet -output_format csv=p=0 -show_entries format=duration video.mp4

    Jangan berhenti hanya karena sesuatu sudah berjalan; setelah berhasil, pikirkan apakah masih ada cara untuk memperbaikinya

    • Saya penulis posting aslinya. Menyebutnya “gila” rasanya agak berlebihan
      Meski begitu, saya lebih suka solusi yang Anda ajukan

  • Bagus. Ini mengingatkan saya pada cheatsheet ffmpeg yang saya pakai. Sepertinya semua orang yang sering memakai ffmpeg punya kumpulan catatan serupa
    https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md

  • FFmpeg adalah salah satu alat yang terlalu jarang saya pakai sehingga sintaks pastinya tidak pernah benar-benar melekat di kepala. Pada akhirnya saya mendiktekan command line yang dibutuhkan ke LLM
    Satu-satunya alat lain yang sama sulitnya bagi saya adalah MegaCLI bergaya 1990-an dari LSI Logic. Itu juga hampir tidak saya pakai tiap tahun, tetapi termasuk jenis alat yang harus digunakan dengan tepat di bawah tekanan

    • Saya sudah memakai FFMPEG lebih dari 15 tahun, tetapi masih hampir tidak bisa mengingat perintahnya. Meski begitu, saat memakai FFMPEG, LLM benar-benar luar biasa
      Kalau Anda meminta ChatGPT dan Claude, “remux video ke mkv, sertakan subtitle.srt di dalam file, dan saya hanya ingin bagian dari 0:00:05 sampai 0:01:00,” mereka menanganinya dengan sangat baik. Kalau penasaran, hasilnya seperti ini: ffmpeg -i input.mp4 -i subtitle.srt -ss 00:00:05 -to 00:01:00 -map 0 -map 1 -c copy -c:s mov_text output.mkv

      Saya penasaran, kalau tujuannya hanya menghasilkan perintah ffmpeg, seberapa kecil LLM yang bisa dibuat. Mungkin cukup kecil untuk ditaruh di halaman web statis dan dijalankan secara lokal?

    • Selama 15 tahun saya memelihara dokumen catatan pribadi berisi sintaks yang sering saya pakai. Kalau itu pun tidak cukup, saya grep riwayat bash

    • Saya juga sama. Yang melekat di kepala cuma cara mengubah format X ke .mp4. Selebihnya harus saya cari lagi setiap kali
      XKCD terkait https://xkcd.com/1168/

    • Beberapa hari lalu saya bercanda setengah serius bahwa kalau LLM bisa memberi tahu flag ffmpeg yang saya inginkan, mungkin membakar seluruh hutan hujan pun terasa sepadan

  • Jangan lupa juga bahwa ada GStreamer. Karena berbasis pipeline, baris perintah dan dokumentasinya sedikit lebih mudah dipahami daripada ffmpeg, dan penyusunannya juga terasa lebih masuk akal
    Untuk pekerjaan video berat, saya sudah sepenuhnya berhenti memakai ffmpeg dan hanya menggunakan GStreamer

    • GStreamer bisa memberi kontrol yang lebih besar dan API yang lebih ramah saat membangun pipeline secara terprogram
      Namun untuk pekerjaan sekali pakai, ffmpeg terlihat jauh lebih ramah. Misalnya, ffmpeg punya default x264 yang masuk akal, tetapi dengan gst-launch, untuk melakukan encoding x264 berkualitas baik Anda benar-benar harus tahu apa yang sedang Anda lakukan
    • Saya kira FFmpeg juga berbasis pipeline. Bukankah ada filter graph? Apakah saya melewatkan sesuatu
      Kita bisa menyusun graf yang kompleks dari source, sink, dan filter transformasi
    • GStreamer terasa seperti proyek yang telantar. Baru-baru ini juga ada kerentanan besar dan dokumentasinya pun cukup berantakan

  • Ada repositori GitHub berupa buku ffmpeg yang tampaknya bagus untuk melengkapi situs ini:
    https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook

  • ffmpeg selalu terasa seperti aplikasi GUI yang dipaksa dijejalkan ke bentuk TUI
    Saya juga pernah beberapa kali memakai API C-nya dengan pengalaman yang kurang menyenangkan; di banyak sisi memang intuitif, tetapi terlalu mudah untuk merepresentasikan state yang salah. Akan bagus kalau ada framework encoding AV1 real-time yang “langsung bekerja”

    • Ini pada dasarnya hampir satu-satunya alat yang membuat saya cenderung mencari HandBrake terlebih dahulu sebagai pengganti GUI. Satu-satunya pengecualian adalah saat melakukan pemrosesan batch
      Ada juga beberapa GUI ffmpeg murni. Ada sesuatu dalam pekerjaan video yang membuat baris perintah tidak terlalu cocok dengan cara otak saya memprosesnya

    • Untuk API, saya bisa merekomendasikan GStreamer. Saya tidak terlalu akrab dengan API C-nya karena memakai binding Rust, tetapi kesannya bagus
      Memang ada bagian yang jadi bertele-tele karena GObject, tetapi setelah dipahami, Anda bisa berinteraksi dengan semua objek di API secara konsisten. Kompleksitas yang dibutuhkan memang sangat banyak (video itu sulit), tetapi desain, implementasi, dan dokumentasinya cukup baik

      Untuk kasus penggunaan umum, Bins(decodebin, transcodebin, playbin) membuatnya cukup mudah. Bahkan untuk kasus yang lebih kompleks pun tetap dimungkinkan berkat fleksibilitas desainnya

    • Saya suka wawasannya, tetapi TUI itu sesuatu yang grafis, sedangkan ffmpeg hanyalah CLI
      Akan keren kalau ada alat TUI. Sesuatu seperti https://github.com/Twinklebear/fbed tetapi dengan fitur yang lebih matang akan bagus

  • Di sistem Linux, saya suka membangun ffmpeg secara statis. Alasannya, versi distro sering terlalu lama atau tidak menyertakan modul yang saya sukai
    Versi terkontainerisasi ini sangat berguna: https://github.com/wader/static-ffmpeg