FFmpeg、マルチスレッド・トランスコーディングパイプラインを導入

 (ffmpeg.org)
2 ポイント 投稿者 GN⁺ 2023-11-07 | 1件のコメント | WhatsAppで共有
  • FFmpeg CLI のマルチスレッド・トランスコーディングが、約2年の作業と700件以上の準備コミットを経て、初の「完全に動作する」形で公開された
  • 変更範囲が大きいため一部機能が壊れている可能性が残っており、実際のマージ前にはテストとレビューが重要な課題となる
  • -fix_sub_duration_heartbeat は、デコーダとエンコーダ・マクサー間の同期を前提としているため、非同期実行では非決定的な動作を避けにくい
  • スレッド化のオーバーヘッドは概ね小さいが、パケット当たりの処理量が非常に少ない作業では、性能向上よりもコストが目立つ可能性がある
  • ボトルネックが単一コンポーネントに集中しておらず、各コンポーネントがすでにマルチスレッド化されて飽和している状態でなければ、マルチコア環境でCPU利用率と実処理時間が大きく改善される可能性がある

FFmpeg CLI マルチスレッド化パッチの要点

  • 約2年の作業と700件以上の準備コミットを経て、マルチスレッド版 FFmpeg CLI の初の「fully functional」バージョンがパッチセットとして公開された
  • 変更規模が大きいぶん、未発見の破損が残っている可能性があり、実際のユースケースに基づくテストとレビューが必要
  • 一般的な場合、スレッド化のオーバーヘッドは小さいが、パケット当たりの処理量が非常に少ないワークロードでは、オーバーヘッドが無視できなくなる可能性がある
  • トランスコーディングが単一コンポーネントに支配されておらず、各コンポーネントがすでに独自のマルチスレッド化で飽和している状態でなければ、マルチコアシステムでCPU利用率と実行時間が改善される可能性がある

動作上の制約と既知の問題

  • -fix_sub_duration_heartbeat オプションは、現在の構造では離れたコンポーネント間の同期を前提としている
    • 対象となる流れは、エンコーダ・マクサーからデコーダへ続く同期である
    • 各コンポーネントが非同期に実行されると、動作は根本的に非決定的になる
    • 現状でも動作は予測しにくいが、同じオプションで実行すれば、実行間の結果は決定的である
    • 16/24 のパッチではこのオプションが無効化され、より良い処理方法が必要になる

24件のパッチセットの構成

  • パッチセットは計24件で構成される
    • 01-09/24 は準備修正であり、残りのシリーズより先にプッシュされる可能性がある
    • 10-17/24 はエンコードとフィルタリングをスレッドへ移し、必要な準備変更を行う
      • この段階のスレッド化は、メインスレッドが他スレッドの完了を待つ「擬似」スレッド化であり、実際の並列実行ではない
      • 一時的なオーバーヘッドが大きかったり、一部のコーナーケースが壊れたりする可能性があるため、全体セットが準備できてからプッシュするのが適切である
    • 18/24 は最大の個別パッチで、トランスコードスケジューラを追加するが、その時点ではまだ実際には動作しない
    • 19-24/24 は個別コンポーネントをスケジューラ利用方式へ変換する
      • レビューのために分割されているが、最終プッシュではまとめられるべきである
  • 関連資料は最近の VDD 発表動画と ffmpeg_threading ブランチで確認できる

関連記事

1件のコメント

 
GN⁺ 2023-11-07
Hacker Newsのコメント

  • 4コアARMサーバーで約2倍高速化し、並列化のオーバーヘッドもそれほど大きくなさそう
    ffmpeg_threading/ffmpeg は7.771秒、従来の ffmpeg は13.841秒で、CPU使用率はそれぞれ218%、114%だった

    • ここではデコード側のハードウェアアクセラレーションは使っておらず、映像出力も外した状態
      NVIDIAカードで映像のデコードとエンコードの両方にハードウェアアクセラレーションを使うとどうなるのか気になる: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • どの部分がマルチスレッド化されるのか気になる。動画圧縮はすでにマルチスレッドだが、動画の伸張についてはよく分からない
      そのほかの処理は性能コストの面では比較的小さい気がするので、改善は歓迎だが実際の影響はかなり限定的だと予想している

  • ツイートの代わりに https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... をリンクしたほうがよかった気がする
    ツイートの要点も結局はこのリンクだから

    • 今はもう単にpostと呼べばいい。280文字制限ももうなく、長文はデフォルトで折りたたまれているだけだ

  • これを理解するには、VideoLAN Dev Days 2023でAntonが行った発表を見るのがよい: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • 発表はよかったし、「Future directions」で触れられていたdynamic pipelinesと「scripting (Lua?)」が何を想定しているのか気になる
      プロパティアニメーションをより強力に扱う方向を想像してしまう
    • 動画の33分あたりのスライドに出てきたExtrasに関する問題は本当に何度も経験してきた
    • ぜひ見たい発表なのだが、音質がひどすぎて集中しづらい。今どきどうすればここまでひどくできるのか分からない
    • 何が分かりにくいのか分からない。動画トランスコーディングの分野ではマルチスレッドが別の意味で使われるのだろうか？

  • ツイートは http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655... に飛び、そこからさらにコード https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading を参照している

    • ツイートは、パッチセットの公式な出典であるメーリングリストへつながっている。続けて読むには「Next in Thread」を選べばよい

  • これが自動で適用されるのか、それともコマンドライン引数を複雑に組み合わせる必要があるのか気になる

  • ffmpegを活用する動画編集ソフトウェアがあるのか気になる
    以前、SVGで図形を描いてffmpegを使ったり、UIを付けたり、あるいはテキスト追加だけのものを作ってみようかと思ったが、始めはしなかった
    Avidemuxは少しそんな感じで、ffmpegの内部はかなり生っぽいので、GUIから扱う前提で作られておらず、ベースにしたエディタは鈍重で奇妙になり、保守も難しそうだ
    コマンドの説明器やパイプラインビューアでプレビューを作るような、モジュール式エディタなら可能かもしれない
    ffmpegは強力だが、コマンドライン専用で使われる点が一部のユーザーの障壁になっている。以前、ランダムな数のクリップを受け取って xstack フィルターでモザイクを作るPythonスクリプトを書いたことがあるが、簡単ではなかった

    • 探している中間地点としてはVapourSynthが合うかもしれない。ffmpeg CLIの代わりにPythonで映像を操作でき、拡張機能のおかげで純粋なffmpegより拡張性や表現力が高いことも多い
      https://vsdb.top/
      https://www.vapoursynth.com/
      ffmpegベースのニッチなソフトウェアとしてはlosslesscutを見たことがある: https://github.com/mifi/lossless-cut
      Staxripも大きい: https://github.com/staxrip/staxrip
      ただし「総合的な」エディタはよく分からない
    • https://shotcut.org/ もffmpegを使っている
    • KDEnliveがある。素晴らしい自由・オープンソースの動画編集ソフトウェアだ

  • Plex向けのちょっとしたトランスコーディング処理がもっと速くなるとうれしい
    グラフィックカードでハードウェアトランスコーディングをサポートしていないので期待している

  • トランスコーディング速度を上げる方法を探していて、1つはGPUアクセラレーション、もう1つはスレッド数を増やすことだった
    ただし最適なスレッド数を見つけるのが難しい

    • 最適値を探すのにハイパーパラメータ最適化を使えばいいのでは？ SherpaやScikit-optimizeのようなツールで、スレッド数、入力タイプ、CPUタイプのような探索空間をなめられる
    • ほとんどの作業では、スレッド数をvCPU数に合わせればよい。つまりハイパースレッディングされたコアは2つとして数える
      ただし可能ならGPUアクセラレーションのほうがずっとよい

  • 大規模なffmpeg配布におけるライセンス要件がどうなるのか気になる。どんな場合に費用が必要なのだろう？

    • 「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
      つまり無料だが、一部モジュールを使うと独自コードと組み合わせる際に問題になる可能性がある
    • 独自ソフトウェア内でffmpegを使う一般的な方法は、利用するffmpegバージョンを静的コンパイルして実行ファイルにリンクするか、独自ソフトウェアが別の実行ファイルとして呼び出す形にすることだ

  • FFmpegが改善されていくのを見るのはうれしい。近いうちにDolby AC4対応も見られるといいな