2026年3月16日（現地時間）- Khronos Groupの公式ブログにて、FFmpeg 8.1のメジャーアップデートに合わせ、Vulkan Computeを活用した動画処理の高速化に関する詳細な解説記事が公開されました。
この記事では、公開された記事をベースに、これまでCPU処理に依存することが多かったProResやFFv1といったプロフェッショナル向けコーデックを、GPUのCompute Shader（汎用計算能力）を用いて並列化するアプローチについて紹介しています。専用のハードウェアデコーダー（ASIC）がサポートしていないフォーマットに対してどのようにアプローチしているか、その技術的な背景と各コーデックの実装状況をまとめてみました。
そもそも「FFmpeg」とは？
FFmpeg（エフエフエムペグ）は、動画・音声を含むマルチメディアデータの記録、変換、ストリーミング、再生などを包括的に扱うための、世界で最も広く利用されているオープンソースのマルチメディアフレームワークです。
一般的には動画変換用のコマンドラインツール（ffmpeg）として知られていますが、その本質は強力なライブラリ群から構成される総合的な処理基盤です。コマンドラインツール自体は、以下のライブラリ群を呼び出す「フロントエンド」として機能しています。
libavcodec：ビデオ・オーディオのエンコード・デコード処理libavformat：コンテナ（MP4やMKVなど）の多重化・分離処理libswscale：画像のリサイズや色空間の変換libavfilter：クロップやテキスト合成などの各種フィルタ処理libswresample：音声のリサンプリングlibavdevice：カメラや画面キャプチャなどのデバイス入出力（記録機
これらの強力なライブラリ群は他のアプリケーションに組み込んで利用できるよう設計されており、以下のような有名なソフトウェアやサービスで直接的・間接的に広く採用されています。
- VLC media player（独自実装と併用しつつFFmpegのコーデックやデマルチプレクサを利用）
- Webブラウザ（Chrome / FirefoxのLinux版などで
libffmpegを利用） - 動画制作・配信ツール（OBS Studio、HandBrake、各種動画編集ソフトなど）
- 動画配信プラットフォーム（YouTubeなどのエンコードパイプラインや内部処理）
一般ユーザーがFFmpegを直接操作する機会は多くありませんが、動画の再生・配信・編集・ストリーミングといった日常的な処理の多くが、FFmpegの技術やその派生実装によって支えられています。エンドユーザーが意識しないところで機能する「マルチメディア処理基盤」として、現代の動画インフラにおいて極めて重要な役割を担っています。
インターネット上での一般的なビデオエンコード・デコードは、日常的な用途においてはほぼ解決済みの課題となっています。現代のコンシューマ向けデバイスの多くには専用のハードウェア・アクセラレーター・チップが搭載されており、Vulkan® Video拡張などのAPIを通じて直接アクセスが可能です。
また、新しいコーデックの多くはロイヤリティフリーでオープンな仕様を採用しているため、誰もが標準技術を広く利用できる環境が整っています。
プロフェッショナル現場の壁とVulkan Computeによる解決
しかし、プロフェッショナルの現場では、依然としてパフォーマンスの限界が大きな課題として残っています。
数日分の RAW カメラ映像を途切れなくスクラブ再生するエディター、8K 16bit マスターを扱うカラリスト、32bit 浮動小数点 ACEScg ビデオをレンダリングする VFX アーティスト、そして超高解像度のロスレスフィルムスキャンを扱うアーキビストなど、最前線のクリエイターたちは常に膨大な計算負荷と向き合っています。
もはや「多少のフレーム落ちは仕方ない」とゆるされていた時代ではなく、現代のプロフェッショナルは独自の高価なソリューションや、数百コア・数百 GB の RAM を搭載した水冷ワークステーションの導入を余儀なくされることも少なくありません。
今回の発表では、FFmpegが「Vulkan Compute」を使用し、コンシューマ向けGPUであってもプロ品質のビデオのエンコード・デコードをシームレスに高速化する手法が紹介されています。これは、Vulkan Videoがサポートする固定機能のコーデックを補完し、ハードウェアがカバーしていないフォーマットやワークフローにまでGPUアクセラレーションを拡張するものです。
コーデック並列化の課題
コーデックは、信号の冗長性やパターンを利用してデータを圧縮するアルゴリズムですが、その処理を GPU で並列化するのは簡単ではありません。
圧縮コーデックの基本モデルとも言える「JPEG」を例にとると、画像エンコードには2D周波数変換（行・列ごとに処理するため部分的に並列化可能）、DC値の予測（完全に直列）、量子化（完全に並列）、ハフマン符号化（極めて直列）というプロセスが必要です。このように、並列処理できる部分と直列処理しかできない部分が混在していることが、GPU によるコーデック処理を難しくしている最大の理由です。
デコードではこれらの手順を逆に辿りますが、直列処理によるボトルネックはそのまま残ります。一方、GPU は数千単位の独立した処理を同時に実行するよう設計されているため、直列依存の多いコーデック処理とは根本的に相性が悪いという矛盾が生じます。
過去の妥協とハイブリッド方式の限界
これまで一般的に検討されてきたアプローチは、CPU と GPU を組み合わせる ハイブリッド・デコード方式 でした。直列処理が必要な係数デコードなどは CPU が担当し、その中間結果を GPU に転送して並列処理を行う、という手法です。
しかし実際には、GPU がシステムメモリから物理的に離れているという根本的な問題に突き当たります。DMA や高帯域幅の転送を使っても、CPU と GPU の間でデータを往復させる際にどうしても 通信レイテンシ（遅延） が発生するため、最新の SIMD に最適化された強力な CPU ですべての処理を完結させた方が速いというケースが多く見られました。
実際、dav1d デコーダー や x264 で過去に試みられた GPU 併用のアプローチも、この転送遅延がボトルネックとなり、十分な性能向上が得られず開発が停滞した歴史があります。
こうした教訓から、GPU を使ったコーデック処理にはCPUを介さずにすべてをGPU上で完結させる「完全なGPUネイティブ実装」が求められるようになりました。
Compute Shaderによる解決への道
多くのコーデックは、最新 GPU に搭載されている専用ビデオエンジン（ASIC）を前提に設計されています。しかし、ASIC も無限に高速というわけではなく、通常は「スライス」や「ブロック」といった 独立して処理できる最小単位 を定義することで性能を確保しています。
解像度が飛躍的に向上した現代では、この固定サイズの最小単位がフレーム全体に占める割合が非常に小さくなり、結果として膨大な数の単位を並列処理できるようになりました。さらに、最新 GPU はスレッド間通信の性能が大幅に向上しており、これらが組み合わさることで、CPUを介さずに特定のコーデックを完全にCompute Shader（演算シェーダー）で実装することが現実的になりました。
また、Compute ベースのエンコーダーは ASIC のようなメモリ使用量や探索範囲の制約を受けないため、十分なスレッドを割り当てることで ソフトウェアエンコーダーと同等以上の品質 を実現できるというメリットもあります。
FFmpegのアーキテクチャによるアクセシビリティ
FFmpegはマルチメディアストリームを扱うためのオープンソースツールですが、ソフトウェアコーデックの上にハードウェアアクセラレーションを構築している点が強みです。ヘッダーの解析、スレッド化、フレームやスライスのスケジューリング、エラー処理などはソフトウェア側で行い、ビデオデータのデコード部分のみをハードウェアにオフロードします。
この設計により、ユーザーは Vulkan Video によるハードウェアデコード と Vulkan Compute Shader によるデコード を意識する必要がなく、FFmpeg が内部で最適なパスを選択してくれます。つまり、アプリケーション側は複雑な実装を気にせず、同じ API で両者をシームレスに切り替えて利用することができます。
実装された各コーデックの状況
FFmpeg 8.1および8.0のリリースにおいて、プロフェッショナル用途で需要の高い以下のフォーマットに対して、Vulkan Computeを用いた実装が公式に追加、あるいは現在も開発が進められています。
FFv1
FFv1 は、ロスレス圧縮が求められる映像アーカイブ分野で標準的に使用されている IETF のコーデックです。高解像度RGBビデオのエンコード/デコードは帯域幅の問題やエントロピー符号化の制約からCPUでは非常に時間がかかっていました。
FFmpeg では、ワークグループサイズを 32 に設定し、各グループが並列して値の検索や適応処理を行うことで、このボトルネックを解消しています。また、RGB の可逆色変換（RCT）も別シェーダーから統合し、帯域幅の使用効率を最適化しています。
APV
APV は Samsung が設計した新しいオープンコーデックで、メザニン（中間）圧縮として VFX 制作やプロ向け映像制作、さらにはスマートフォンの記録フォーマットとして注目されています。
APV は最初から 並列化を前提に設計されており、フレームをコンポーネント → タイル → ブロックへと細かく分割して処理します。FFmpegでは、最初のシェーダーでタイルごとのデコードを処理し、2つ目のシェーダーでブロックの変換を行う手法をとっています。
ProRes / ProRes RAW
ProRes は編集やカメラ収録の事実上の標準フォーマットで、構造が比較的シンプルなため、デコーダーとエンコーダーの両方が Compute Shader で実装されました。
また、センサーの非デバイヤー RAW データを圧縮する ProRes RAW は並列性が高く、FFmpegでは2パスのアプローチ（タイルごとのデコード後、行・列の並列性を持たせて全ブロックを変換）で効率的な実装が行われています。
DPX
DPX はフィルムスキャナーで広く使われる非圧縮の連番画像フォーマットです。仕様の解釈がベンダーによって異なるため、デコードが崩れる（異常な色になる）問題が頻発します。
FFmpeg では、ヘッダー情報を読み取り、正しいデータ展開方法を シェーダー内のヒューリスティクス（経験則アルゴリズム） で判断することで、この問題に対応しています。
VC-2 と JPEG
BBCが開発したウェーブレット変換に基づくVC-2は、スライスごとに完全に独立して処理が可能なため並列化に適しています。また、JPEGはVLC（可変長符号）ストリームであるため、一般的には並列化が難しいと考えられがちですが、FFmpeg ではVLCデコーダーが持つ「短時間での擬似的な再同期特性」を利用し、複数のシェーダーを同時に走らせることで並列化を実現するという、興味深いアプローチが採用されています。
今後の展望とVulkan Computeの可能性
FFmpeg 8.1のリリースにより、FFv1のエンコード・デコード、ProResのエンコード・デコード、ProRes RAWのデコード、DPXのアンパックが公式に実装されました。Vulkanアクセラレーションを有効にすると、自動的にこれらのGPU処理が使用されます。
一方、VC‑2 や JPEG、APV については現在も開発が進行中で、将来的なターゲットとして JPEG2000 や PNG も挙げられています。ただし、これらは仕様が複雑であるため、依然として技術的なハードルが残されています。
最後に、FFmpeg VulkanメンテナーのLynne氏は、Vulkanを単なる「グラフィックスAPI」と捉えるのは時代遅れであると指摘しています。最新のVulkanは、ポインター、サブグループ操作、共有メモリ、ネイティブなビット演算、64ビットアドレッシングなどをサポートし、専用のCompute APIと同等以上の機能を備えています。特定のベンダー（メーカー）にロックインされることなく、幅広いプラットフォームやデバイスで動作するVulkan Computeは、FFmpegのような寿命の長いオープンソースソフトウェアにとって理想的な基盤であると結んでいます。
FFmpeg ダウンロード:
https://ffmpeg.org/download.html
Video Encoding and Decoding with Vulkan Compute Shaders in FFmpeg
コメント