FFmpeg memperkenalkan multithreading CLI lewat "refactoring paling kompleks" dalam beberapa dekade

Dukungan multithreading untuk CLI FFmpeg

• Fitur yang memungkinkan antarmuka baris perintah (CLI) FFmpeg mendukung multithreading telah digabungkan ke Git FFmpeg.
• Ini merupakan perubahan yang dilakukan sebelum FFmpeg 7.0 dirilis pada awal tahun depan, dan menjadi peningkatan besar bagi proyek open source penting yang banyak digunakan untuk transcoding video.
• Di era saat prosesor multi-core telah menjadi hal umum, peningkatan seperti ini sangat bermanfaat.

Pekerjaan refactoring yang kompleks

• Dalam pengumuman teknis terbaru, para pengembang FFmpeg menjelaskan pekerjaan multithreading ini sebagai "salah satu refactoring paling kompleks yang pernah dilakukan pada CLI FFmpeg dalam beberapa dekade".
• Para pengembang meminta pengguna untuk melakukan pengujian, dan mendorong agar masalah yang ditemukan dilaporkan ke FFmpeg Trac.

Perubahan teknis yang diimplementasikan

• Patch yang digabungkan mencakup penambahan infrastruktur penjadwalan transcode yang sadar thread, memindahkan encoding ke thread terpisah, serta berbagai perubahan low-level lainnya.
• Mengubah FFmpeg ke arsitektur thread berarti setiap komponen (demuxer, decoder, filter, encoder, muxer) sebelumnya sudah berjalan di thread terpisah, tetapi kini benar-benar dapat berjalan secara paralel.

Pendapat GN⁺

• Dukungan multithreading FFmpeg merupakan perkembangan penting yang dapat sangat meningkatkan efisiensi pekerjaan transcoding video.
• Pekerjaan refactoring yang kompleks ini menghadirkan banyak tantangan bagi para pengembang, dan menunjukkan bahwa FFmpeg terus beradaptasi serta berkembang mengikuti lingkungan komputasi modern.
• Menarik untuk mengamati bagaimana perubahan ini akan memengaruhi performa nyata bagi pengguna dan pengembang.

[GN⁺]

Opini Hacker News

• Teori tentang optimasi multithreading/multiprocessing

  • Di masa lalu, membaca, memproses, dan merender satu gambar memerlukan waktu yang cukup lama, tetapi berkat perkembangan teknologi perangkat keras dan perangkat lunak, sekarang prosesnya jauh lebih cepat.
  • Dulu, beberapa worker memproses satu frame merupakan pendekatan yang efisien, tetapi sekarang satu worker dapat memproses frame dengan lebih efisien daripada mengerahkan beberapa worker.
  • Sistem modern memiliki lingkungan yang sepenuhnya berbeda dari sistem saat FFmpeg pertama kali dibuat, sehingga perlu memikirkan ulang bagaimana beban kerja didefinisikan, dijadwalkan, dibagikan, dilacak, lalu digabungkan menjadi hasil akhir.
  • Pujian untuk tim FFmpeg yang menerima tantangan ini. FFmpeg adalah puncak dari infrastruktur open source dan elemen penting tempat peradaban dibangun.

• Rekaman presentasi dari acara VDD@Dublin

  • Sedang mencari rekaman presentasi tersebut, tetapi tidak mudah ditemukan baik di situs penulis maupun di sini.
  • Pembaruan: ditemukan di YouTube!

• Pemikiran tentang peningkatan performa multicore

  • Encoder saat ini menggunakan beberapa thread untuk memproses frame yang sama secara bersamaan. Cara yang umum adalah membagi frame menjadi beberapa area lalu tiap thread menangani area tertentu.
  • Sebagai alternatif, diusulkan metode untuk memproses segmen keyframe secara independen. Metode ini dapat memparalelkan codec dengan cara yang umum dan efisien, tanpa penurunan efisiensi kompresi akibat membagi frame menjadi area atau overhead komunikasi antarthread.
  • Masalah dari metode ini adalah frame sebanyak N*siklus keyframe harus dimuat ke memori, dan ada overhead memori tambahan yang diperlukan untuk meng-encode N frame.
  • Namun, dalam banyak kasus kelemahan ini tampaknya bukan masalah besar. Dalam kebanyakan situasi, penggunaan RAM yang besar dan output dengan interval keyframe tetap dapat diterima.
  • Pemrosesan paralel intra-frame dan pemrosesan paralel segmen keyframe dapat digabungkan untuk mencapai paralelisme tinggi sambil meminimalkan penurunan kualitas.

• Tantangan rebase yang berkelanjutan

  • Melakukan rebase terus-menerus terhadap perubahan yang masuk setiap hari merupakan tantangan yang cukup besar.
  • Sekarang karena sudah diintegrasikan ke FFmpeg, pekerjaan ke depannya akan jauh lebih mudah.
  • Ini kemenangan besar, dan akan sangat berkontribusi pada peningkatan kecepatan.

• Harapan akan peningkatan waktu mulai streaming virtual display buffer FFmpeg

  • Proyek LLMStack menggunakan FFmpeg untuk melakukan streaming video browser.
  • Saat ini ada latensi yang terlihat saat mem-boot pipeline setiap kali memanggil masing-masing alat.
  • Peningkatan di FFmpeg pasti akan membantu pekerjaan optimasi seperti ini.

• Promosi kursus FFmpeg C API

  • Mempromosikan kursus yang mengajarkan FFmpeg C API di Udemy.

• Rasa ingin tahu tentang codebase FFmpeg

  • Tidak terlalu memahami codebase FFmpeg, tetapi penasaran bagaimana perubahan seperti ini bisa dilakukan secara bertahap tanpa satu commit raksasa.
  • Menurut presentasinya ada 700 commit; penasaran apakah itu dilakukan di branch terpisah atau perlahan-lahan di-merge ke proyek.

• Sudut pandang operator layanan cloud

  • Jika mengoperasikan layanan cloud seperti Netflix, kemungkinan sudah menjalankan ribuan proses FFmpeg di tiap mesin, jadi pada dasarnya itu sudah merupakan pekerjaan multicore.

• Berbagi pengalaman pemrosesan filter thread di VapourSynth

  • Sudah hampir 10 tahun menikmati pemrosesan filter thread di VapourSynth.
  • Peningkatan FFmpeg kali ini juga bagus, tetapi tidak akan banyak mengubah alur kerja prapemrosesan VapourSynth + encoding av1an untuk encoding video "berkualitas".

• Pertanyaan tentang dukungan multicore di FFmpeg

  • Penasaran apakah FFmpeg kini bisa menggunakan multicore di semua codec yang disertakan.
  • Menggunakan FFmpeg untuk layanan hosting audio guna meng-encode MP3 dengan LAME, dan akan bagus jika waktu encoding file panjang bisa ditingkatkan.