FFmpegは2026年8月29日、NVIDIA GPUの光学フロー演算器を使うフレームレート変換フィルター「fruc_vulkan」をmasterへ統合した。低いフレームレートの動画で前後の画像から動きを推定し、その間に新しい画像を合成する。NVIDIAは同種のFRUC（Frame Rate Up-Conversion）をOptical Flow SDK 4.0以降で開発者へ提供してきたが、2023年のFFmpeg向け実装はライセンスの壁で本流に入らなかった。今回動いたのは、その補間ライブラリを組み込む方法を捨て、動きの計算と画面の合成を分けたことである。

AD

2023年に止まったFRUCと何が変わったか

2023年1月、Philip LangdaleはNVIDIA Optical Flow SDKのNvFRUCライブラリを呼び出すFFmpegフィルターを開発者リストへ投稿した。リアルタイムに近い補間を実現した一方、SDKのEULAはFFmpegのnonfreeフィルターとしても扱いにくく、Langdaleは当初からマージする意図がないと明記していた。利用者がSDKを取得し、自分の環境でビルドする実験にとどまった。

2026年版も、GPU上のNVIDIA Optical Flow Accelerator（NVOFA）から前後方向の動きベクトルを得る点は同じだ。しかし、NVIDIAのNvFRUCバイナリは使わない。VK_NV_optical_flowで動きだけを取り出し、FFmpeg内のVulkan compute shaderが中間画像を作る。

比較軸 2023年のvf_nvoffruc案 NVIDIAのNvFRUCライブラリ 2026年のfruc_vulkan
NVOFAへの経路 NVIDIA SDKのFRUC API NVOFA APIとCUDA VulkanのVK_NV_optical_flow
中間画像の生成 NvFRUCへ委ねる ベクトル検証、無効部分の補完、画像の穴埋めまで実施 FFmpegのshaderが前後画像をwarpして混合
入力形式 CUDAハードウェアフレーム NV12またはARGB Vulkan上の大部分のYUV/RGB
FFmpeg本流 ライセンス制約で見送り NVIDIAがSDKとして配布 masterへ統合済み

2023年のNvOFFRUC案と2026年のfruc_vulkanはNVOFAを使う点は共通するが、前者は再配布制約のあるNVIDIAライブラリに補間後処理まで委ね、後者はVulkanから双方向フローを取得してFFmpeg自身のLGPLシェーダーで中間画像を合成する。したがって上流化を可能にした設計変更と、同じFRUC名でも品質処理が同一ではないことを同時に確認できる。

光学フロー専用器と、絵を作るシェーダー

fruc_vulkanは最初に入力画像から輝度を抽出し、NVOFAへ連続する2枚を渡す。NVOFAは1枚目から2枚目、2枚目から1枚目という双方向のフローを出力する。FFmpegのshaderは各画素の参照位置をPicard反復で6回たどり、緩和係数0.5で位置を収束させてから、希望する時刻に合わせて前後の色を混ぜる。ニューラルネットワークによるフレーム生成ではない。

この分離には実装上の利点もある。光学フロー用の資源を2組持ち、あるフレーム対のベクトルをshaderが読んでいる間に、次の対のフローをNVOFAで計算する。compute queueとoptical flow queueの間はtimeline semaphoreでつなぎ、CPU側で各工程の完了を待つ時間を減らした。NVOFA自体は直列に動くため、3組以上へ増やしても処理量は伸びないという設計である。

一方、画質を決める定数には実験色が残る。LangdaleはPicard反復の回数と係数を、均一な動きと不均一な動きを含む少数のサンプルで経験的に選んだと説明している。特徴の乏しい背景でNVOFAが大きな偽の動きを作り、移動物体から離れた場所へ残像を引く問題も見つかった。現行shaderは前後の輝度差と移動距離を使う経験的なguardで、この偽フローを弱める。

AD

60fpsは既定値、perfとgridが処理量を変える

出力は標準で60fpsだが、入力フレームレートにかかわらず固定であり、必ず2倍になる設定ではない。元動画に合わせて増やす場合は、source_fps*2のような式で指定できる。同じフレーム対から複数枚を合成する構成にも対応する。

速度と細かさを調整する設定は2つある。perfはslow、medium、fastの3段階で、既定のslowが最も品質を重視する。gridはフローベクトル1本が受け持つ画素幅をauto、1、2、4、8から選ぶ。autoはGPUが対応する最も細かいgridを使い、gridを粗くすると計算量とメモリ消費が下がる代わりに、細い物体や境界の動きを捉えにくくなる。

NVIDIAがSDK 5.0で示した参考値では、1920×1080のYUV 4:2:0をslow presetで処理した場合、Ampereは4×4 gridで200fps、2×2で94fps、Adaはそれぞれ536fpsと210fpsだった。この数字は光学フローAPIだけの測定であり、fruc_vulkanの輝度抽出、warp、動画のデコードと再エンコードを含まない。それでも、gridを細かくするとNVOFAの処理量が急増することは分かる。

開発者は2160p24の映画を無理なく処理する例としてperf=mediumとgrid=2を挙げた。ただし、GPU型番と出力fpsは示していない。これは初期調整の目安であり、性能保証ではない。

「RTXなら使える」ではない

NVOFAはTuring世代から搭載されたが、NVIDIAの公式資料はVulkan経由のOptical Flow modeをTuringで非対応としている。さらに、TU117にはNVOFA自体がない。RTX 20シリーズを含めて「Turing以降なら動く」とまとめることはできず、fruc_vulkanの実効的な出発点はAmpere世代となる。Vulkan interfaceはWindows 10以降とLinuxに対応するが、WSLでは使えない。

FFmpeg側の条件も新しい。ビルドにはVulkan Headers 1.4.317以上とSPIR-V compilerが要る。実行時にはVK_NV_optical_flowに加えて、compute queueとoptical flow queue、VK_KHR_maintenance9、queue間で画像を暗黙に受け渡せる能力が必要だ。NVIDIAのVulkanドライバー履歴では、maintenance9が初めて記載されたのは2025年6月8日のWindows 573.38とLinux 570.123.18だった。古いドライバーでは、NVOFAを持つGPUでもフィルターの初期化を通らない。

入力もVulkan hardware frameに限られる。大部分のYUVとRGBを扱えるが、yuyv422やuyvy422のようなサブサンプリング済みpacked YUV、1成分が16bitを超える形式、Bayer形式は対象外だ。デコード、補間、エンコードをGPU内でつなげるには、前後のフィルターもVulkanフレームを受け渡せるよう構成しなければならない。

配布時期にも線を引く必要がある。FFmpegのChangelogはfruc_vulkanをversion <next>へ置き、version 9.0の収録項目には含めていない。masterへ入ったことと、OSのパッケージや動画アプリですぐ選べることは別である。現時点ではmasterをビルドするか、次の安定版と各アプリの採用を待つ機能だ。

AD

次の評価は滑らかさより破綻率

fruc_vulkanは、動画のフレーム補間を再配布しにくいSDK部品から切り離し、FFmpegの通常のフィルターチェーンへ持ち込んだ。バッチ変換、再生前処理、配信向けのフレームレート統一で使える可能性がある。一方、AMDやIntelでも動く汎用Vulkanフィルターではなく、NVIDIA固有拡張と対応ドライバーが前提だ。

採用判断には、同じ動画をNvFRUCやFFmpegのminterpolateと比較し、遮蔽、場面転換、細い輪郭で生じる破綻を数える試験が欠かせない。さらに、光学フロー単体ではなくデコードから再エンコードまでの速度を測り、perfとgridごとの画質差を公開する必要がある。安定版へ収録され、主要アプリがその検証を再現できれば、GPUフレーム補間は専用プレーヤーの表示機能から、追跡可能な動画処理工程へ移れる。