2 poin oleh GN⁺ 2025-08-23 | 1 komentar | Bagikan ke WhatsApp
  • FFmpeg 8.0 "Huffman" menambahkan codec berbasis komputasi Vulkan serta decoding·encoding dengan akselerasi perangkat keras, bersama berbagai format file dan filter baru
  • Infrastruktur telah dimodernisasi secara menyeluruh, dan proses kontribusi serta kualitas kode juga diperkuat
  • Bidang codec audio dan video utama juga mengalami kemajuan, termasuk stabilisasi decoder VVC, decoder xHE-AAC, serta dukungan MV-HEVC dan LC-EVC
  • Tetap berperan sebagai pusat perkembangan teknologi multimedia open source, sambil melanjutkan peningkatan fitur dan penguatan keamanan

Pengenalan FFmpeg

  • FFmpeg adalah toolkit pemrosesan multimedia serbaguna yang lengkap, solusi yang fleksibel dan kuat untuk merekam, mengonversi, dan melakukan streaming audio maupun video
  • Dengan perintah sederhana seperti ffmpeg -i input.mp4 output.avi, pemrosesan video dan audio dapat dilakukan

23 Agustus 2025, FFmpeg 8.0 "Huffman" dirilis

  • FFmpeg 8.0 "Huffman" telah diumumkan. Setelah beberapa kali tertunda dan melalui proses modernisasi infrastruktur, rilis ini menjadi yang paling besar sejauh ini
  • Fitur baru mencakup penambahan decoder native seperti APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728, peningkatan dukungan IBC, ACT, dan Palette Mode pada decoder VVC, serta codec berbasis komputasi Vulkan seperti FFv1 (encode·decode), ProRes RAW (hanya decode)
  • Diperkenalkan pula decoding berakselerasi perangkat keras berbasis Vulkan (misalnya VP9, VVC, H264/5) dan encoding (AV1, H264/5), beragam format baru (MCC, G.728, Whip, APV) serta filter (colordetect, pad_cuda, scale_d3d11, Whisper, dll.)
  • Keluarga decoder dan encoder baru berbasis compute shader yang berjalan di Vulkan 1.3 juga ditambahkan. Strukturnya tidak memerlukan akselerator perangkat keras khusus, dan bekerja sama seperti API hwaccel. Saat menggunakan encoder, encoder baru tersebut harus ditentukan, dan saat ini hanya mendukung FFv1 (encode·decode) serta ProRes RAW (decode). ProRes (dua arah) dan VC-2 (dua arah) sedang dipersiapkan
  • Struktur ini hanya dapat diterapkan pada codec yang dioptimalkan untuk decoding paralel, dan ke depan diharapkan membawa peningkatan performa tinggi serta pemanfaatan baru seperti penyuntingan video nonlinier dan perekaman lossless di lebih banyak bidang
  • Infrastruktur proyek juga diperbarui secara besar-besaran. Server mailing list telah diganti sepenuhnya, dan kini mendukung kolaborasi kode berbasis Forgejo di code.ffmpeg.org
  • Pengguna disarankan untuk memperbarui ke versi terbaru

1 komentar

 
GN⁺ 2025-08-23
Komentar Hacker News
  • Menyampaikan terima kasih kepada para pengembang dan kontributor FFmpeg

    • Setiap kali membutuhkan otomatisasi audio/video, saya selalu menggunakan FFmpeg, dan sebagian besar alat video online juga memakai alat ini sebagai mesin inti atau sebagai pembungkus UI
    • Hari ini saya juga baru tahu ada proyek FFmpeg.Wasm(https://github.com/ffmpegwasm/ffmpeg.wasm)
    • Membagikan pengalaman pada Januari 2024 saat mengekstrak frame dari film animasi tahun 1993 per 15 menit, lalu melakukan upscaling menggunakan Real-ESRGAN-ncnn-vulkan(https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan), dan merangkai kembali frame hasilnya ke 4K
    • Terlintas bahwa jika alur kerja ini diberi UI, hasilnya bisa menjadi alat seperti Topaz AI yang sedang populer belakangan ini
    • Juga membagikan gambar sampel hasil upscale(gambar sampel)
    • Bahkan saat tidak memakai ffmpeg secara langsung, saya tetap sering memakai alat yang menanamkannya
      • Baru-baru ini saya melakukan upscale anime lawas berkualitas rendah yang diekstrak dari DVD lama melalui k4yt3x/video2x, pemasangannya mudah dan sudah dibundel dengan libffmpeg
      • Saat encoding, saya bisa memakai argumen yang sama seperti di FFmpeg
      • Untuk memilih argumen terbaik, saya meng-encode adegan pendek dengan beberapa set parameter menggunakan ffmpeg, lalu mengekstrak gambar diam lagi dengan ffmpeg untuk dibandingkan
  • Senang melihat FFmpeg memperkenalkan encoder dan decoder video berbasis compute shader

    • Codec yang didukung luas di perangkat keras kira-kira hanya H.264, H.265, dan AV1, jadi akan bagus jika codec lain juga bisa mendapat akselerasi platform (meski efisiensinya sedikit lebih rendah, tetap berarti)
    • Encoder ProRes baru terasa berguna untuk proyek yang sedang saya kerjakan saat ini
    • Saya paham penjelasan bahwa codec umum yang banyak dipakai tidak cocok untuk decoding paralel sehingga sulit didukung
    • Perlu memakai puluhan ribu thread, tetapi dependensi data antarfame dan antartile membuat paralelisasi tidak mudah
    • Encoder tampaknya sedikit lebih fleksibel daripada decoder, tetapi meng-encode sesuatu seperti VP9(https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) dengan compute shader sepertinya akan menjadi tantangan berat
    • Sekali lagi membagikan kabar gembira tentang implementasi encoder/decoder video dengan compute shader

      • Dulu hanya ada antarmuka perangkat keras in-silicon yang terstandarisasi, jadi saya pernah ditertawakan ketika bertanya apakah encoder/decoder berbasis Vulkan bisa bersifat general-purpose
      • Sangat keren bahwa peningkatan seperti ini juga tersedia di perangkat keras lama, semoga ini membuka jalur untuk codec baru dan peningkatan kualitas secara menyeluruh
    • Saya belum mengikuti perkembangan terbaru decoder selama lebih dari 10 tahun, tetapi secara intuitif saya menduga akselerasi GPU akan sangat membantu untuk pemrosesan tahap akhir saat data berubah menjadi piksel

      • Dekompresi awal mungkin dilakukan di CPU, lalu data yang sudah didekompresi dikirim ke GPU untuk transformasi akhir (menerapkan motion vector, iDCT, dan sebagainya)
      • Jika frame akhir sudah berada sebagai tekstur GPU, overhead tampilan juga akan rendah
      • Saya penasaran sejauh mana intuisi saya ini benar
    • Setiap kali saya kagum pada bakat para maintainer FFmpeg, luar biasa bahwa mereka melakukan pekerjaan sesulit ini secara gratis

    • Catatan rilis ini sangat menarik

      • Dalam beberapa minggu terakhir saya membuat decoder ProRes dengan WebGPU compute shader, dan performanya cukup cepat (saya kira Apple mungkin akan memakai akselerasi perangkat kerasnya sendiri)
      • Jalur ini tampaknya juga cocok untuk codec APV baru di Android
      • Spesifikasi bitstream ProRes sudah diajukan ke SMPTE, tetapi sulit menemukan informasi tentang ProRes RAW
      • Munculnya implementasi berbasis software dan compute terasa sangat menarik, mungkin para pengembang ffmpeg melakukan reverse engineering
      • Sekilas melihat kodenya, tampaknya tidak jauh berbeda dari ProRes biasa
      • Dokumen spesifikasi ProRes
  • Setiap kali memakai FFmpeg saya selalu dibuat terkesan (meski tetap perlu membuka manual lagi atau meminta bantuan LLM, bahkan saat memakai GUI yang membangunkan perintah dari opsi visual)

    • Sepertinya sekarang ini sudah menjadi multitool transcoding yang esensial
    • Menurut saya keputusan untuk mengadopsi pemrosesan berbasis Vulkan 1.3 adalah keputusan yang bagus
    • Kemarin saya juga baru tahu bahwa Asahi Linux on Mac mendukung standar yang sama
    • Meninggalkan ungkapan jenaka bahwa argumen FFmpeg adalah “prompt engineering versi asli”

    • LLM dan alat command-line kompleks seperti FFmpeg dan ImageMagick adalah kombinasi yang fantastis

      • Rasanya seperti UI/UX masa depan yang sempurna: cukup jelaskan pekerjaan yang diinginkan dalam bahasa alami, lalu langsung terwujud
      • Sebagai contoh, membayangkan skenario memotong semua gambar dalam folder ke ukuran tertentu, menyesuaikan saturasi, menyimpannya sebagai TIFF, merakitnya menjadi loop video, lalu meng-encode-nya untuk web dalam satu alur sekaligus
    • LLMs bekerja sangat baik sebagai antarmuka untuk FFmpeg

  • Membagikan realitas setengah bercanda bahwa 50% usaha saat membuat perintah CLI rumit dengan ffmpeg terbuang untuk menyusun perintah, dan 50% sisanya untuk bertarung dengan shell escaping

    • Khususnya saat menaruh teks ke video, escaping teks terasa sangat sulit
    • Ia penasaran apakah ada yang menemukan cara sempurna untuk memanggil ffmpeg dari Python dengan banyak argumen (filter dan sebagainya) (r-strings? heredocs? dan lain-lain)
  • Penasaran apakah ada frontend GUI yang bagus untuk menangani beragam fungsi FFmpeg dengan mudah

    • Kadang yang dibutuhkan hanya remux, atau sekadar menggabungkan stream video/audio dengan codec yang sama
    • Menekankan bahwa menggabungkan video terdengar mudah, tetapi ternyata memiliki banyak variabel dan masalah

      • Variabel seperti timebase, start offset, crop frame, perbedaan FPS, B-frame, open GOP, dan lain-lain bisa menimbulkan masalah di lingkungan pemutaran tertentu
      • Audio juga memiliki banyak variabel seperti perbedaan sample rate
      • Program Lossless-Cut sempat disebut, dan fitur pemeriksaan kompatibilitasnya berguna
      • Namun mengubah video ke MPEG-TS terlebih dahulu lalu menggabungkannya baik untuk menghindari banyak masalah, dan bisa diproses cepat di ramdisk
      • Juga membagikan urutan command line ffmpeg yang bisa dipakai sebagai contoh
    • Handbrake menjalankan peran itu dengan baik

      • Dari sisi fitur sudah memadai, sedikit terkesan lawas tetapi tetap berguna sampai sekarang
    • Jika pengguna Mac, merekomendasikan ffWorks(https://www.ffworks.net/index.html)

      • Sebagian besar fungsi mudah diakses, dan juga mendukung pemrosesan batch serta pengaturan preset
      • Pengembangnya sangat aktif membantu sehingga ini menjadi salah satu aplikasi favoritnya, bahkan ia juga berdonasi karena nilainya tinggi
      • Handbrake dan Losslesscut juga hebat, tetapi tampaknya tidak ada aplikasi di platform lain yang bisa menandingi kematangan ffWorks
    • Menurutnya frontend terbaik baginya adalah ChatGPT

      • Jika menjelaskan pekerjaan yang diinginkan dalam bahasa alami, alat itu menghasilkan perintah ffmpeg yang sangat akurat
    • Menyarankan untuk melihat program Lossless-cut

  • Membagikan tautan untuk melihat changelog FFmpeg(https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • Mengungkapkan secara singkat bahwa ini berita yang menarik

    • Bertanya-tanya apakah video ini satire atau serius
  • Menyampaikan pendapat pribadi bahwa ffmpeg mungkin adalah pustaka ke-4 yang paling banyak digunakan setelah ssl, zlib, dan sqlite (dengan asumsi bahwa video benar-benar ada di mana-mana pada 2025)

    • Rasanya sulit setuju, karena pemrosesan video terutama dibutuhkan di server yang menerima media

      • Menyebut bahwa sebagian besar ponsel tidak memproses video dengan ffmpeg
    • Bisa jadi curl berada lebih atas, dan “SSL” punya banyak implementasi sehingga angkanya akan terpecah

    • Mengusulkan log metrik fastly milik infrastruktur NixOS(https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md) sebagai sumber data

    • Berpendapat bahwa ada cukup banyak pustaka seperti Qt, libpng, dan libusb yang dipakai lebih luas daripada ffmpeg

    • Statistik paket Arch Linux(https://pkgstats.archlinux.de/packages) juga layak dicek

  • Menilai implementasi Vulkan compute shader sangat keren, terutama untuk FFv1 dan ProRes RAW

    • Karena sepenuhnya melewati decoder perangkat keras fixed-function, saya penasaran bagaimana dampaknya terhadap bandwidth memori
    • Pengkodean aritmetika adaptif berbasis konteks pada FFv1 tampaknya secara inheren bersifat serial sehingga seharusnya sulit dipercepat, jadi saya terkejut melihat peningkatan kecepatan yang sangat besar
    • Saya penasaran apakah caranya dengan memparalelkan banyak simbol sekaligus atau per slice, dan trade-off apa yang diambil tim ffmpeg, mengingat secara tradisional akselerasi pengkodean aritmetika di GPU memang sulit
    • Jika ada yang punya pengalaman profiling implementasi tersebut, saya ingin mendengar tentang tingkat okupansi pada tahap entropy decoding dan pilihan bandwidth-nya
  • ffmpeg menjadi fondasi bagi sangat banyak alat

    • Publik sering kali tidak menyadari seberapa besar kontribusi ffmpeg bagi industri media
    • Ini adalah alat yang selalu saya cari setiap kali membutuhkan otomatisasi audio/video