2026/03/17 10:02
ビデオエンコーディングとデコード：FFmpegにおけるVulkanコンピュートシェーダーの活用
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
（抜けている要素を組み込む）**
Summary
コンシューマデバイスは専用ハードウェアアクセラレータとロイヤリティフリーコーデックのおかげで、ほぼすべてのビデオエンコード／デコードを解決していますが、プロフェッショナルなワークフローでは、生映像・8Kマスター・ロスレスVFXレンダーなど、現在のGPUビデオ拡張機能の限界に挑む素材が依然として課題です。FFmpegは現在、Vulkan Computeシェーダーを活用して、多くのプロフェッショナルコーデック（FFv1、APV、ProRes、DPX、VC‑2、JPEG）にフルGPUアクセラレーションを提供し、固定機能のVulkan Videoサポートが残すギャップを埋めています。
このシフトは、高いスループットへのニーズとCPU／GPUハイブリッドアプローチの固有非効率性（メモリレイテンシが性能を低下させる）によって推進されています。最新GPUは大規模なスレッドプール、クロスインボケーション通信、および高度なVulkan Compute機能（サブグループ演算、共有メモリアライシング、64ビットアドレス指定）を活用して、これらのコーデックを完全にコンピュートシェーダーで実装し、消費者向けハードウェア上で効率的かつベンダーニュートラルなアクセラレーションを可能にします。
将来の作業ではJPEG2000、PNG、および残余フォーマットが対象です。クリエイターやVFXスタジオにとっては、より安価なGPUで高速処理が実現できるためインフラコストが削減されます。また、プロフェッショナルビデオパイプラインを提供または依存する企業にとっては、広範なGPUアクセラレーションがスループットを向上させつつ、高価な専用機器への依存を低減します。
本文
ビデオのエンコード・デコードは、日常的な利用者にとってほぼ完璧に解決された問題です。現在では多くの消費者向け機器が専用ハードウェアアクセラレーターを搭載しており、Vulkan® Video拡張のようなAPIで直接アクセスできます。さらに、新しいコーデックはロイヤリティフリーでオープン仕様になったものや、ライセンス制限が切れることで誰でも利用できるようになっています。
720 p H.264 のデコードが CPU でいかに負荷の大きかったかを忘れがちです。18 年前はその課題がソフトウェア実装間の激しい競争と最適化を駆動し、性能限界まで追い込まれた結果、ハードウェアデコードが普及しました。
しかしプロフェッショナルなワークフローではまだパフォーマンス障壁があります。長時間のRAW映像をスクリーニングする編集者、8K 16‑bit マスターで作業するカラーリスト、32‑bit 浮動小数点 ACEScg ビデオをレンダリングする VFX アーティスト、極端に高解像度のロスレスフィルムスキャンを扱うアーカイブ担当者などは、いまだにパフォーマンス制約に直面しています。かつてはたまにフレームドロップが許容できたユーザーと比べ、今日のプロフェッショナルは高価な専用ソリューションや液体冷却で数百コアを備え、数百ギガバイトの RAM を搭載したワークステーションへと駆り出されています。
本稿では FFmpeg が Vulkan Compute を利用して、プロフェッショナルグレードのビデオも消費者 GPU でシームレスにエンコード・デコードを加速する方法を探ります。これにより、GPU の計算パラレル性を大規模に活用しつつ専用ハードウェア不要となります。この手法は Vulkan Video が提供する固定機能のコーデックサポートと補完的であり、対象外のフォーマットやワークフローへのアクセラレーションも実現します。
コーデック
コーデックとは、信号に存在する冗長性やパターンを利用して圧縮し、保存・送信を効率化するアルゴリズムです。GPU でコーデック処理を並列化するのはどれほど容易でしょうか？
JPEG（圧縮コーデックの C. elegans）を例に挙げます。
- エンコード：2D 周波数変換（行・列順で部分的に並列可能）、DC 予測（完全直列）、量子化（完全並列）、ハフマン符号化（極めて直列）。並列と直列の混在が GPU コーデックアクセラレーションの中心課題です。
- デコード：同様に逆処理を行いますが、直列ボトルネックは依然として問題です。
この基本的な緊張関係は、コーデックパイプラインは直列依存性で満ちている一方、GPU は数千の独立した演算を同時に実行するよう設計されているという対照から生じます。
妥協策
歴史的に一般的だったアプローチはハイブリッドデコードです。直列ステップ（係数デコードなど）を CPU で処理し、中間結果を GPU に転送、GPU が得意とする並列ステップを実行します。しかし、GPU はシステムメモリから物理的に離れているため、DMA や高速転送でも往復レイテンシが高く、CPU で単独で並列処理した方が速いケースが多いです。特に現代の SIMD 対応 CPU が非常に強力になった現在では顕著です。
ハイブリッド実装の実際の結果はこの問題を裏付けます。dav1d デコーダーは最後のフィルタパス（複雑だが高い並列性）を GPU にオフロードしようとしましたが、モバイル環境でも CPU 以上の利得は見られませんでした。x264 は OpenCL™ をベースにした簡易サポートを追加しましたが、フレームアップロード遅延でパフォーマンスメリットが消え、コードは徐々に劣化しました。
これらの失敗はマルチメディアコミュニティ内でハイブリッド実装に悪評を残し、教訓として「常に高速・保守性・普及性を確保するには、CPU への手渡しなしに GPU 上だけで完結する計算ベースのコーデック実装が必要だ」という結論へと至ります。
意志があるなら…
ほとんどのコーデックは ASIC ハードウェア（GPU の専用ビデオエンジン）を前提に設計されています。Vulkan Video を通じて公開されています。しかし ASIC でも無限に高速というわけではなく、コーデックは通常「スライス」や「ブロック」と呼ばれる最小単位で並列処理が可能な範囲を定義します。
多くの人気コーデックは数十年前にビデオ解像度がずっと低い時代に設計されたため、現在のように高解像度になるとその固定サイズの最小単位はフレーム全体のごく一部しか占めません。つまり、より多くを並列で処理できるようになります。また、近年の GPU にはクロスインボケーション通信機能が追加され、さらなる最適化機会が生まれています。
これらのトレンドにより、今日では特定のコーデックを完全に計算シェーダーで実装し、CPU の介在なしに処理することが実際的になりました。さらに計算ベースのエンコーダはメモリ使用量と探索時間に制約がないため、多数のスレッドでブロックを網羅的に走査すればソフトウェアエンコーダの品質と同等かそれ以上を実現可能です。
アクセシビリティ
FFmpeg はフォーマットやコーデックに関係なくマルチメディアストリームを扱うためのフリー・オープンソースライブラリおよびツール群です。多くのプラットフォームで手書きアセンブリ最適化が施されたコーデック実装を有する一方、ハードウェアアクセラレーションへのアクセスも簡単に提供しています。
重要なのは、FFmpeg のハードウェアアクセラレーションはソフトウェアコーデックの上に構築されている点です。ヘッダー解析、スレッド管理、フレーム・スライスのスケジューリング、エラー訂正/処理はすべてソフトウェアで行われます。ビデオデータのデコードだけがハードウェアに任せられます。この組み合わせは堅牢で検証済みのコードとハードウェアアクセラレーションを併用できる点が強みです。
また、ソフトウェア実装が独立フレームを並列デコードするために複数フレームを同時にディスパッチするように設計されているので、Vulkan Compute シェーダーで GPU を完全に飽和させることも可能です。さらに、ユーザーはソフトウェアとハードウェア実装の切替をトグルで動的に行えます。ここで「ハードウェアデコード」が Vulkan Video か Compute シェーダーで実装されているかどうかは区別されません。
FFmpeg は編集ソフト、メディアプレーヤー、ブラウザなどで広く使われており、任意のソフトウェア実装にハードウェアアクセラレーションを追加できるため、計算ベースのコーデック実装を普及させる理想的な出発点です。
FFv1
FFmpeg Video Codec version #1（FFv1）は、ロスレス圧縮が必要なアーカイブコミュニティやアプリケーションで定番となっています。オープンかつロイヤリティフリーで、IETF 標準にも認められています。
FFmpeg で計算シェーダー実装を行う最初のプロジェクトがここから始まりました。FFv1 エンコーダとデコーダは CPU 上で非常に遅いですが、最大 1024 スライスまでサポートしています。これは高解像度 RGB ビデオで必要な帯域幅とエントロピー符号化設計のボトルネックが原因でした。
FFv1 バージョン3 は 10 年前に設計され、アーカイブコミュニティによって採用されたことで広く使われるようになりました。しかし、ボトルネックにより高解像度アーカイブフィルムスキャンのエンコード・デコードは時間的に実用不可能でした。
そこで、FFv1 のエンコーダとデコーダはソフトウェア版を GPU 用に段階的に最適化しながら書き直されました。最大の課題は範囲符号器（range coder）システムで、AV1 のような高度な最適化がないためです。各ピクセル差分値は 8‑bit 適応値を持ち、エンコード・デコード時に数千個の連続した値をランダムに参照します。
この処理を高速化するため、ワークグループサイズを 32 に設定し、各ローカル呼び出しが適応と検索を並列で行い、単一呼び出しが実際の符号化・復号を担当します。
RGB では再帰的色変換（RCT）を行ってピクセル値の相関をさらに除去します。元々は別シェーダーで別画像にエンコードしていましたが、帯域幅要件が高くなり、2 行だけ必要な点を利用し「width × horizontal_slices × 2」画像を確保し、32 のヘルパー呼び出しで各行の RCT を先に実施します。
APV
APV はサムスンが開発したロイヤリティフリー・オープンなメッセンジャービデオ圧縮コーデックです。最近 IETF 標準にも採用され、VFX やプロフェッショナルメディア制作コミュニティ、およびスマートフォンのカメラ録画フォーマットとして広がっています。
本稿で紹介するほとんどのコーデックとは異なり、APV は設計段階から並列性を重視しています。JPEG と同様にフレームはコンポーネントに分割され、各コンポーネントはタイルへさらに分割され、タイルは複数ブロックで構成されます。各ブロックは単純な変換・量子化（スカラー除算）を経て可変長符号で符号化され、DC 予測は不要です。
計算シェーダーとして実装するには、まずタイルごとにデコード処理を一つのシェーダーで行い、次に別のシェーダーでブロックの各行を呼び出し単位で変換します。
ProRes
ProRes は編集・カメラ映像・マスタリングで使われる実質的な標準メッセンジャーコーデックです。JPEG や APV と同様に比較的シンプルで、デコーダの実装が可能でした。また需要に応じてエンコーダも実装されました。
デコードでは APV とほぼ同じ手順を踏みます。しかしエンコード時はレート制御と推定を行い、ブロックがフレーム全体のビット予算内に収まる量子化器を探すシェーダーを走らせます。
残念ながら ProRes コーデックはロイヤリティフリーではなく、仕様もオープンではありません。FFmpeg での実装は非公式です。しかしその人気ゆえに、プロフェッショナル環境との互換性が必要不可欠です。開発者は自身の実装をテストし、公式実装と同等になるよう監視しています。
ProRes RAW
ProRes RAW は ProRes とはビットストリームがほぼ共通していないフォーマットで、RAW（デベイリング前）ロスィーセンサーデータを圧縮するために設計されました。各コンポーネントに対して DCT を実行し、係数符号化器は DC を複数コンポーネント間で予測し、AC 値を通常のジグザグ順序で効率的に符号化します。エントロピー符号化は従来型可変長コードではなく指数符号化に近いです。
スライスには複数ブロックがあり、各コンポーネントは並列にデコード可能です。FFv1 とは違い、画像ごとにタイル数の制限がないため、何十万もの独立ブロックを処理する必要があります。これが高い並列性をもたらし、効率的な実装へつながります。
デコーダは 2 パスで実装されました：
- 最初のシェーダーが各タイルをデコードし、
- 二番目のシェーダーがタイル内のすべてブロックを行/列並列で変換（shred configuration と呼ばれ、GPU のワークグループサイズ上限まで飽和できる）します。
DPX
DPX はコーデックではなく、ヘッダー付きのパックドピクセルコンテナです。公式 SMPTE 標準であり、フィルムスキャナーに人気があります。最適に配置されたピクセルをタイトに詰めるわけではなく、32‑bit チャンク単位でピクセルを格納し、必要に応じてパディングします。またヘッダー切替によってピクセルを詰めない設定も可能です。
非圧縮フォーマットで規制が緩いものは、数十年前に作られたため、ベンダーが仕様を創造的に解釈し、デコードを壊すケースが多くあります。幸いにもヘッダー内に「producer」フィールドが残されており、実装者はそれで正しいアンパック方法を推測できます。
結局のところ、シェーダーでヒューリスティックを書くだけです。オーバーヘッドはピクセル集合を検索する計算ではなく、メモリからデータを取得し別所へ書き込む処理にあります。
VC‑2
VC‑2 は BBC が作成したもう一つのメッセンジャーコーデックです。Dirac コーデックをベースにしており、ロイヤリティフリーで公式 SMPTE 仕様があります。主な用途はリアルタイムストリーミングで、高解像度ビデオをギガビット回線上でサブフレームレイテンシーで送ることです。
APV や ProRes と異なり、ウェーブレット変換に基づいています。各フレームは 2 の冪サイズのスライスへ分割されます。ウェーブレットはフレームを四分の一解像度の画像と残差として三つの四分の一解像度画像に分離します。DCT と違い、局所的であり各スライス単位で実行可能ですが、再結合時には全体が変換されたかのように機能します。これにより DCT ベースコーデック特有のブロッキングアーティファクトを排除できます。
ただしウェーブレットは周波数分解が犠牲になるためエンコード効率が低く、歪み特性も DCT より視覚的に魅力が劣ります。これが 2000 年代以降のコーデックで採用されなかった主因です。
係数は単純なインタリーブド Golomb–exp コードで符号化され、並列化は難しいですがデコードではビット解析をすべて除去しバイト単位で操作できるように簡素化できます。
JPEG
冒頭で例示したコーデックは、パラレル化への扉を開く興味深いアプローチを持っています。VLC（可変長符号）ストリーム自体は並列化が難しいものの、VLC デコーダ—実際には Kraft–McMillan の不等式を満たすすべてのコード—は誤差で再同期できます。短時間後に有効データを出力します。
必要なのは JPEG ストリーム内の開始点を 4 シェーダーで段階的に同期させるだけです。JPEG は進行型やロスレスプロファイルなど複数バリエーションがあり、同様に並列化可能です。
DC 予測はパラレルプレフィックス和で実装し、DCT は shred configuration（他のコーデックと同じ）で行います。
今後
FFmpeg 8.1 のリリースにより、FFv1 のエンコード・デコード、ProRes のエンコード・デコード、ProRes RAW デコード、および DPX アンパックが実装されました。GPU ベースの処理は自動的に有効化され、Vulkan 加速デコードがオンの場合に使用されます。
VC‑2 エンコーダとデコーダ、JPEG および APV デコーダはまだ進行中で、マージ前に追加作業が必要です。
さらに遠い将来を見れば、GPU アクセラレーションの有効性が残る可能性のあるコーデックは JPEG2000 と PNG のみとなります。JPEG2000 は多くの現代コーデックとは異なり、半直列化された符号化システムと複雑なビットストリームを持ち、ソフトウェアデコードは最も遅い側面です。その ASIC 依存設計と未完成な算術符号器が原因ですが、デジタルシネマ、医療、法医学で主流のコーデックです。
PNG のアクセラレーションは未解決課題であり、その実装可能性は DEFLATE をどれだけ並列化できるかに依存します。
Vulkan Compute
Vulkan は「グラフィックス API + 計算」という捉え方が古く、実際には計算機能が進化し、多くの場合専用計算 API を凌駕しています。現代の Vulkan ではポインタ、サブグループ演算、共有メモリエイリアス、ネイティブビット演算、明確なメモリモデル、シェーダー特殊化、64‑bit アドレス指定、および GPU 行列ユニットへの直接アクセスが可能です。これらにより、より低レベルで最適化できます。
ただし Vulkan Compute はまだ SPIR‑V™ の全機能を露出していません。SPIR‑V は非常に表現力豊かな中間表現であり、未だサポートが拡張されています。未型ポインタと 64‑bit アドレス指定は既に利用可能で、非32ビット整数のビット演算も近々サポートされる予定です。
GPU ベンダー別の計算 API は多くの専門化されたアルゴリズム実装を提供しますが、ベンダーロックインという問題があります。FFmpeg のように長寿で移植性の高いソフトウェアでは重要な懸念事項です。
FFmpeg ではハッシュ関数やソート、CRC、周波数変換など一般的アルゴリズムを自前実装して依存を排除しています。大規模かつオブジェクト指向の API が必ずしも必要というわけではなく、プリプロセッサでテンプレート化したり
#includeVulkan は小型 SoC からタブレット・組み込み GPU、ディスクリート GPU、そしてプロフェッショナルサーバー GPU に至るまでほぼ全てのプラットフォームに普及しています。業界主導のガバナンスモデルは新しい拡張を広く支援するインセンティブを生み出し、自動化テストが包括的な互換性テストスイートで行われます。またデバッグ・最適化・プロファイルツールも充実しており、世界中の開発者コミュニティにより GPU の特性や最適化トリックが継続的に共有されています。
Vulkan Video か Vulkan Compute シェーダーを使うかは問いません。どちらでも GPU アクセラレーション付きビデオ処理へのアクセス手段として魅力的です。
FFmpeg ダウンロード: https://ffmpeg.org/download.html
Khronos® と Vulkan® は登録商標であり、SPIR‑V™ は The Khronos Group Inc. の商標です。OpenCL™ は Apple Inc. の商標で、Khronos にライセンス下で使用されています。他の全ての商品名・商標・会社名は識別目的のみで使用され、該当所有者に帰属します。