FFmpeg 8.0 リリース

 (ffmpeg.org)
2 ポイント 投稿者 GN⁺ 2025-08-23 | 1件のコメント | WhatsAppで共有
  • FFmpeg 8.0 "Huffman" では、Vulkan演算ベースのコーデックとハードウェアアクセラレーションによるデコード・エンコード、複数の新しいファイルフォーマットとフィルターが追加された
  • インフラを全面的にモダン化し、貢献プロセスとコード品質も強化した
  • VVCデコーダの安定化、xHE-AACデコーダ、MV-HEVCおよびLC-EVC対応など、主要なオーディオ・ビデオコーデック分野でも進展があった
  • オープンソースマルチメディア技術の発展の中心的役割を果たしつつ、継続的な機能改善とセキュリティ向上を進めている

FFmpeg紹介

  • FFmpegは完全な汎用マルチメディア処理ツールキットであり、音声や映像の録画・変換・ストリーミングに柔軟かつ強力なソリューションを提供する
  • ffmpeg -i input.mp4 output.avi のような簡単なコマンドだけで、映像および音声の処理が可能

2025年8月23日、FFmpeg 8.0 "Huffman" リリース

  • FFmpeg 8.0 "Huffman" が公開された。度重なる遅延とインフラの近代化を経て、これまでで最大規模のリリースとなった
  • 新機能には、APV、ProRes RAW、RealVideo 6.0、Sanyo LD-ADPCM、G.728 などのネイティブデコーダ追加、VVCデコーダにおけるIBC、ACT、Palette Mode対応の強化、Vulkan演算ベースのFFv1（エンコード・デコード）、ProRes RAW（デコードのみ） などのコーデックが含まれる
  • Vulkan ベースのハードウェアアクセラレーションによるデコード（例: VP9、VVC、H264/5）とエンコード（AV1、H264/5）、さまざまな新しい*フォーマット（MCC、G.728、Whip、APV）とフィルター（colordetect、pad_cuda、scale_d3d11、Whisper など）*が導入された
  • Vulkan 1.3 で動作するコンピュートシェーダベースのデコーダおよびエンコーダ群が新たに追加された。特別な専用ハードウェアアクセラレータを必要としない構造で、hwaccel APIと同様に動作する。エンコーダ使用時には新しいエンコーダを指定する必要があり、現在対応しているのはFFv1（エンコード・デコード）とProRes RAW（デコード）のみ。ProRes（双方向）とVC-2（双方向）は準備中
  • この構造は並列デコード最適化コーデックにのみ適用でき、今後はさらに幅広い分野で高い性能向上とノンリニア映像編集・ロスレス録画などの新たな活用が期待される
  • プロジェクトのインフラも大幅に近代化された。メーリングリストサーバーを全面的に刷新し、現在は code.ffmpeg.org でForgejoベースのコードコラボレーションをサポートしている
  • ユーザーには最新バージョンへのアップグレードを推奨する

関連記事

1件のコメント

 
GN⁺ 2025-08-23
Hacker Newsのコメント

  • FFmpeg の開発者と貢献者に感謝を述べている

    • オーディオ/ビデオの自動化が必要になるたびにいつも FFmpeg を使ってきたし、オンラインの動画ツールの多くもこのツールをコアエンジンとして使うか、UI ラッパーとして活用している
    • 今日になって FFmpeg.Wasm プロジェクト(https://github.com/ffmpegwasm/ffmpeg.wasm)の存在も知った
    • 2024年1月に、1993年のアニメ映画のフレームを15分単位で抽出し、Real-ESRGAN-ncnn-vulkan(https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan)を使ってアップスケーリングし、その結果フレームを 4K に再結合した経験を共有している
    • もしこのワークフローに UI を追加していたら、最近人気の Topaz AI のようなツールになっていたかもしれないと考えている
    • アップスケーリングしたサンプル画像も共有している(サンプル画像)
    • 直接 ffmpeg を使わないときでさえ、それを内蔵したツールをよく使っている
      • 最近、古い DVD から抽出した低画質アニメを k4yt3x/video2x でアップスケールしたが、インストールが簡単で libffmpeg が内蔵されていた
      • エンコード時には FFmpeg と同じ引数を使えた
      • 最適な引数を選ぶために、ffmpeg で短いシーンを複数のパラメータセットでエンコードし、再び ffmpeg でスチル画像を抽出して比較した

  • FFmpeg がコンピュートシェーダベースのビデオエンコーダとデコーダを導入したことをうれしく思っている

    • ハードウェアで広くサポートされているコーデックは H.264、H.265、AV1 くらいなので、他のコーデックでもプラットフォームアクセラレーションが使えるとよいと思う（多少効率が落ちても意味はある）
    • 新しい ProRes エンコーダは現在進行中のプロジェクトで役立ちそうに感じる
    • 広く使われる一般的なコーデックは並列デコードに向いておらず、サポートが難しいという説明には納得できる
    • 数万個のスレッドを使う必要があるが、フレーム間やタイル間のデータ依存のため並列化は容易ではない
    • エンコーダはデコーダより多少柔軟性がありそうだが、VP9(https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/)のようなものをコンピュートシェーダでエンコードするのは難しい課題に思える

    • ビデオエンコーダ/デコーダをコンピュートシェーダで実装したという朗報を改めて喜んでいる

      • 以前は標準化されたインシリコンのハードウェアインターフェースしかなかったので、Vulkan ベースのエンコーダ/デコーダが汎用的かと尋ねて笑われたことがある
      • こうした改善が旧型ハードウェアでも提供されるのは本当にすばらしく、この形で新しいコーデックや全体的な品質向上への道が開けてほしいと願っている

    • デコーダの最新動向を10年以上追っていないが、直感的には GPU アクセラレーションはピクセルデータへ変換される後処理で大いに役立ちそうだと見ている

      • 初期の伸長は CPU で行い、その後に伸長済みデータを GPU に送って最終変換処理（モーションベクトル適用、iDCT など）を行えばよさそうに思える
      • 完成フレームがすでに GPU テクスチャ上にあれば、表示オーバーヘッドも少ない
      • 自分の直感がどの程度当たっているのか気になっている

    • FFmpeg メンテナたちの才能には毎回驚かされるし、こんな高難度の仕事を無償でやってくれているのはすごい

    • このリリースノートはとても興味深い

      • ここ数週間、WebGPU コンピュートシェーダで ProRes デコーダを作っていたが、十分に高速に動作している（Apple はおそらく独自のハードウェアアクセラレーションを使うだろうと思う）
      • この経路は Android の新しい APV コーデックにもよく合いそうだ
      • ProRes ビットストリーム仕様は SMPTE に提出されているが、ProRes RAW に関する情報は見つけにくかった
      • ソフトウェアおよびコンピュートベースの実装が登場してとても興味深いし、おそらく ffmpeg 開発者たちがリバースエンジニアリングしたのだろうと感じる
      • コードをざっと見た限りでは通常の ProRes と大差ないように見える
      • ProRes 仕様書

  • FFmpeg を使うたびに感心させられる（マニュアルを調べ直したり LLM の助けを借りたりする必要はあるが、視覚的なオプションからコマンドを組み立ててくれる GUI を使うときでさえそう感じる）

    • いまや不可欠なトランスコーディングのマルチツールになったように思える
    • Vulkan 1.3 ベースの処理を導入したのはよい判断だと思う
    • 昨日、Mac 上の Asahi Linux も同じ標準をサポートしていることを知った

    • FFmpeg の引数は「元祖プロンプトエンジニアリング」だという洒落た表現を残している

    • LLM と FFmpeg、ImageMagick のような複雑なコマンドラインツールは最高の組み合わせだ

      • やりたい作業を自然言語で説明するだけですぐ実現できる、完璧な未来型 UI/UX だと感じるほどだ
      • 例として、フォルダ内のすべての画像を特定サイズにクロップし、彩度を調整し、TIFF で保存し、動画ループに組み立てて Web 向けにエンコードするところまで一括処理するシナリオを想像している

    • LLM は FFmpeg 用インターフェースとして非常にうまく機能する

      • 自然言語で使えるようにするツールはたくさんあり、自分のスクリプトも共有している(https://github.com/jjcm/llmpeg)

  • ffmpeg で複雑な CLI コマンドを作るのに労力の 50% を浪費し、残りの 50% はシェルエスケープとの格闘に費やしているという、冗談まじりの現実を共有している

    • 特にテキストを動画に重ねるとき、テキストのエスケープがとても難しく感じられる
    • Python から多くの引数（フィルタなど）付きで ffmpeg を呼ぶときの完璧な方法を見つけた人がいるのか気になっている（r-strings? heredocs? など）

  • FFmpeg の多様な機能を簡単に扱えるよい GUI フロントエンドがあるか気にしている

    • ときには単にリマックス remux したいだけだったり、同じコーデックの映像/音声ストリームを結合したいだけのこともある

    • 映像の結合は簡単そうに聞こえるが、実際には変数や問題が多いことを強調している

      • タイムベース、開始オフセット、フレームクロップ、FPS の差、B フレーム、オープン GOP などの要因により、特定の再生環境で問題が起こりうる
      • 音声にもサンプルレート差などさまざまな変数がある
      • Lossless-Cut が言及されており、互換性チェック機能が有用だという
      • ただし、映像を MPEG-TS に変換してから結合するのが多くの問題を回避するのによく、RAM ディスク上で高速に処理できる
      • 例として使える ffmpeg コマンドラインシーケンスも共有している

    • Handbrake がその役割をうまく果たしてくれる

      • 機能面で十分で、やや古さはあるものの今でも有用に使える

    • Mac ユーザーなら ffWorks(https://www.ffworks.net/index.html)を勧める

      • ほとんどの機能に簡単にアクセスでき、バッチ処理やプリセット設定もサポートしている
      • 開発者のサポートが非常に手厚く、お気に入りのアプリの1つで、価値が高いので寄付もしている
      • Handbrake や Losslesscut もすばらしいが、ffWorks の完成度に競えるアプリは他プラットフォームにはないように思える

    • 自分にとって最高のフロントエンドは ChatGPT だと思っている

      • 自然言語でやりたい作業を説明すると、かなり正確な ffmpeg コマンドを生成してくれる

    • Lossless-cut を確認することを勧めている

  • FFmpeg の変更履歴（Changelog）を確認できるリンク(https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)を共有している

  • 興味深いニュースだと短く述べている

    • この動画が風刺なのか、本気なのか気になっている

  • ffmpeg は ssl、zlib、sqlite に次いで4番目によく使われるライブラリではないかという個人的な意見を述べている（2025年には動画が本当にどこにでもあるという前提で）

    • それには同意しにくい、動画処理は主にメディアを受け取るサーバ側で必要になるからだという見方がある

      • ほとんどの携帯電話が ffmpeg で動画処理しているわけではないと指摘している

    • curl のほうが上位かもしれないし、「SSL」は実装がさまざまなので数値が分散するだろうという意見もある

    • NixOS インフラの fastly メトリクスログ(https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md)をデータソースとして提案している

    • Qt、libpng、libusb など、ffmpeg より広く使われているライブラリはかなりあると思うという意見もある

    • Arch Linux のパッケージ統計(https://pkgstats.archlinux.de/packages)も見てみる価値がある

  • Vulkan コンピュートシェーダ実装は、とくに FFv1 と ProRes RAW で見事だと思っている

    • 固定機能ハードウェアデコーダを完全に迂回するため、メモリ帯域幅への影響がどうなるのか気になっている
    • FFv1 のコンテキスト適応型算術符号化は本質的に逐次的なので高速化は難しそうだが、それでも非常に大きな速度向上を得ている点に驚いている
    • 複数のシンボルを同時に並列化しているのか、あるいはスライス単位で並列化しているのか、従来 GPU で算術符号化を高速化しにくかった理由がある中で ffmpeg チームがどんなトレードオフをしたのか気になっている
    • この実装をプロファイリングした経験のある人がいれば、エントロピーデコード段階での占有率や帯域幅の選択について聞いてみたい

  • ffmpeg は実に多くのツールの基盤になっている

    • 一般の人は、メディア業界に対する ffmpeg の貢献がどれほど大きいかをあまり知らないことが多い
    • オーディオ/ビデオの自動化が必要になるたびに、いつも頼るツールだ