FFmpeg memperkenalkan pipeline transcoding multithread

 (ffmpeg.org)
2 poin oleh GN⁺ 2023-11-07 | 1 komentar | Bagikan ke WhatsApp
  • Transcoding multithread di FFmpeg CLI dirilis dalam bentuk pertama yang “berfungsi penuh” setelah sekitar 2 tahun pengerjaan dan lebih dari 700 commit persiapan
  • Karena cakupan perubahannya besar, masih ada kemungkinan sebagian fitur rusak, dan pengujian serta review tetap menjadi tugas utama sebelum benar-benar digabungkan
  • -fix_sub_duration_heartbeat sulit menghindari perilaku nondeterministik dalam eksekusi asinkron karena asumsi sinkronisasi antara dekoder, encoder, dan muxer
  • Overhead threading umumnya kecil, tetapi pada pekerjaan dengan beban kerja per paket yang sangat rendah, biayanya bisa lebih terlihat daripada manfaat performanya
  • Jika bottleneck tidak terpusat pada satu komponen dan tiap komponen belum sudah jenuh oleh multithreading internalnya sendiri, pemanfaatan CPU dan waktu pemrosesan nyata di lingkungan multicore dapat meningkat signifikan

Inti patch multithreading FFmpeg CLI

  • Setelah sekitar 2 tahun pengerjaan dan lebih dari 700 commit persiapan, versi “fully functional” pertama dari FFmpeg CLI multithread dipublikasikan sebagai satu set patch
  • Karena skala perubahannya besar, ada kemungkinan kerusakan yang belum ditemukan, sehingga pengujian dan review berbasis kasus penggunaan nyata diperlukan
  • Dalam kasus umum, overhead threading kecil, tetapi pada workload dengan beban kerja per paket yang sangat rendah, overhead bisa menjadi signifikan
  • Jika transcoding tidak didominasi oleh satu komponen tunggal dan tiap komponen belum sudah jenuh oleh multithreading internalnya sendiri, pemanfaatan CPU dan waktu eksekusi pada sistem multicore dapat meningkat

Batasan operasi dan masalah yang diketahui

  • Opsi -fix_sub_duration_heartbeat dalam struktur saat ini mengasumsikan sinkronisasi antar komponen yang terpisah
    • Alur targetnya adalah sinkronisasi dari encoder·muxer ke dekoder
    • Jika tiap komponen berjalan secara asinkron, perilakunya secara fundamental menjadi nondeterministik
    • Saat ini pun perilakunya sulit diprediksi, tetapi jika dijalankan dengan opsi yang sama, hasil antar eksekusi tetap deterministik
    • Pada patch 16/24, opsi ini dinonaktifkan, dan dibutuhkan pendekatan penanganan yang lebih baik

Susunan set 24 patch

  • Set patch terdiri dari total 24 patch
    • 01-09/24 adalah perbaikan persiapan, dan dapat di-push lebih dulu daripada seri lainnya
    • 10-17/24 memindahkan encoding dan filtering ke thread serta melakukan perubahan persiapan yang diperlukan
      • Threading pada tahap ini adalah threading “palsu”, di mana thread utama menunggu thread lain selesai, sehingga belum merupakan eksekusi paralel yang sesungguhnya
      • Karena overhead sementara bisa besar atau beberapa corner case bisa rusak, lebih tepat jika di-push setelah seluruh set siap
    • 18/24 adalah patch individual terbesar yang menambahkan scheduler transcode, tetapi pada titik itu belum benar-benar berfungsi
    • 19-24/24 mengubah tiap komponen agar menggunakan scheduler
      • Dipisah untuk keperluan review, tetapi pada push akhir seharusnya digabungkan
  • Materi terkait dapat dilihat di video presentasi VDD terbaru dan branch ffmpeg_threading

Bacaan terkait

1 komentar

 
GN⁺ 2023-11-07
Opini Hacker News

  • Di server ARM 4-core, sekitar 2x lebih cepat, dan overhead paralelisasi tampaknya tidak besar
    ffmpeg_threading/ffmpeg memakan waktu 7,771 detik, sedangkan ffmpeg lama 13,841 detik; penggunaan CPU masing-masing 218% dan 114%

    • Di sini mereka tidak memakai akselerasi hardware di sisi decoding, dan output video juga dihapus
      Penasaran bagaimana hasilnya jika decoding dan encoding video sama-sama memakai akselerasi hardware di kartu NVIDIA: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Saya penasaran bagian mana yang dibuat multithread. Kompresi video sudah multithread, sedangkan dekompresi video saya kurang tahu
      Pekerjaan lainnya sepertinya relatif kecil dari sisi biaya performa, jadi peningkatan ini disambut baik, tetapi dampak nyatanya saya perkirakan cukup terbatas

  • Sepertinya lebih baik menautkan https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... daripada tweet
    Inti tweet itu pada akhirnya juga tautan ini

    • Sekarang cukup disebut post saja. Batas 280 karakter juga sudah tidak ada lagi, dan tulisan panjang pada dasarnya hanya dilipat secara default

  • Untuk memahami ini, sebaiknya tonton presentasi Anton di VideoLAN Dev Days 2023: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • Presentasinya bagus, dan saya penasaran apa yang ia bayangkan dengan dynamic pipelines dan “scripting (Lua?)” yang disebut di bagian “Future directions”
      Itu membuat saya membayangkan arah untuk menangani animasi properti dengan lebih kuat
    • Saya benar-benar sering mengalami masalah yang terkait dengan Extras yang muncul di slide sekitar menit ke-33 video itu
    • Saya sangat ingin menonton presentasinya, tetapi kualitas audio-nya terlalu buruk sehingga sulit berkonsentrasi. Tidak tahu bagaimana di zaman sekarang hal seperti ini masih bisa begitu parah
    • Saya tidak tahu bagian mana yang sulit dipahami. Apakah multithread dipakai dengan makna berbeda di ranah transcoding video?

  • Tweet itu mengarah ke http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655..., lalu dari sana merujuk lagi ke kode https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

    • Tweet itu mengarah ke mailing list, sumber resmi patchset. Untuk membacanya berurutan, pilih “Next in Thread”

  • Saya penasaran apakah ini diterapkan otomatis, atau perlu merangkai parameter command line yang rumit

  • Saya penasaran apakah ada software penyunting video yang memanfaatkan ffmpeg
    Dulu saya sempat berpikir untuk membuat sesuatu yang menggambar bentuk dengan SVG lalu memakai ffmpeg, atau menambahkan UI, atau hanya menambahkan teks, tetapi tidak pernah memulainya
    Avidemux agak terasa seperti itu, dan bagian dalam ffmpeg cukup mentah sehingga tidak dipakai agar bisa diakses dari GUI; editor berbasisnya mungkin akan lamban, aneh, dan sulit dirawat
    Sesuatu seperti editor modular yang membuat pratinjau lewat deskriptor perintah atau viewer pipeline sepertinya mungkin
    ffmpeg sangat kuat, tetapi karena hanya dipakai lewat command line, hal itu menghalangi sebagian pengguna. Dulu saya menulis skrip Python yang menerima jumlah klip acak lalu membuat mosaik dengan filter xstack, dan itu tidak mudah

  • Semoga pekerjaan transcoding kecil yang saya lakukan untuk Plex jadi lebih cepat
    Kartu grafis saya tidak mendukung hardware transcoding, jadi saya menantikannya

  • Saya sedang mencari cara untuk meningkatkan kecepatan transcoding; salah satunya akselerasi GPU, dan yang lain menambah jumlah thread
    Namun sulit menemukan jumlah thread yang optimal

    • Bukankah bisa memakai optimisasi hiperparameter untuk mencari nilai optimalnya? Dengan alat seperti Sherpa atau Scikit-optimize, kita bisa menjelajahi ruang pencarian seperti jumlah thread, jenis input, dan jenis CPU
    • Untuk sebagian besar pekerjaan, jumlah thread bisa disamakan dengan jumlah vCPU. Artinya core yang di-hyperthread dihitung sebagai 2
      Namun kalau memungkinkan, akselerasi GPU jauh lebih baik

  • Saya penasaran bagaimana persyaratan lisensi untuk deployment ffmpeg berskala besar. Dalam kasus apa perlu biaya?

    • “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.”
      http://ffmpeg.org/legal.html
      Dengan kata lain, gratis, tetapi jika memakai beberapa modul tertentu, bisa muncul masalah saat digabungkan dengan kode proprietary
    • Cara umum memakai ffmpeg di dalam software proprietary adalah mengompilasi statis versi ffmpeg yang digunakan lalu menautkannya ke executable, atau membuat software proprietary memanggilnya sebagai executable terpisah

  • Senang melihat FFmpeg makin membaik. Semoga segera ada dukungan Dolby AC4 juga