On August 29, 2026, FFmpeg merged "fruc_vulkan," a frame rate conversion filter that uses NVIDIA GPUs' optical flow hardware, into its master branch. The filter estimates motion from preceding and following frames in low-frame-rate video and synthesizes new frames in between. NVIDIA has offered similar FRUC (Frame Rate Up-Conversion) functionality to developers since Optical Flow SDK 4.0, but a 2023 implementation for FFmpeg never made it into mainline due to licensing barriers. What changed this time is that the approach of embedding NVIDIA's interpolation library was abandoned; instead, motion computation and frame compositing were separated.
What Stalled FRUC in 2023, and What Changed
In January 2023, Philip Langdale submitted an FFmpeg filter to the developer mailing list that called NVIDIA Optical Flow SDK's NvFRUC library. It achieved near-real-time interpolation, but the SDK's EULA was difficult to accommodate even as an FFmpeg nonfree filter, and Langdale stated from the outset that he had no intention of merging it. It remained an experiment where users would obtain the SDK themselves and build it in their own environment.
The 2026 version still obtains bidirectional motion vectors from the NVIDIA Optical Flow Accelerator (NVOFA) on the GPU, just as before. However, it does not use NVIDIA's NvFRUC binary. Motion alone is extracted via VK_NV_optical_flow, and a Vulkan compute shader inside FFmpeg generates the intermediate frames.
| Comparison axis | 2023 vf_nvoffruc proposal | NVIDIA's NvFRUC library | 2026 fruc_vulkan |
|---|---|---|---|
| Path to NVOFA | NVIDIA SDK's FRUC API | NVOFA API and CUDA | Vulkan's VK_NV_optical_flow |
| Intermediate frame generation | Delegated to NvFRUC | Vector validation, invalid-region compensation, and hole-filling all performed | FFmpeg's shader warps and blends preceding/following frames |
| Input format | CUDA hardware frames | NV12 or ARGB | Most YUV/RGB formats on Vulkan |
| FFmpeg mainline | Shelved due to licensing constraints | Distributed by NVIDIA as an SDK | Merged into master |
The 2023 NvOFFRUC proposal and the 2026 fruc_vulkan share the use of NVOFA, but the former delegated even post-interpolation processing to an NVIDIA library with redistribution restrictions, while the latter obtains bidirectional flow from Vulkan and composites intermediate frames using FFmpeg's own LGPL shader. This confirms both the design change that enabled upstreaming and the fact that, despite sharing the FRUC name, the quality-processing pipeline is not identical.
A Dedicated Optical Flow Engine, and a Shader That Builds the Picture
fruc_vulkan first extracts luminance from the input frames and passes two consecutive frames to NVOFA. NVOFA outputs bidirectional flow: from the first frame to the second, and from the second to the first. FFmpeg's shader traces each pixel's reference position through six Picard iterations, converging the position with a relaxation coefficient of 0.5, then blends the preceding and following colors according to the desired timestamp. This is not neural-network-based frame generation.
This separation also brings implementation benefits. Two sets of optical flow resources are maintained, allowing NVOFA to compute the flow for the next frame pair while the shader is reading the vectors for the current pair. The compute queue and optical flow queue are connected via a timeline semaphore, reducing the CPU-side wait time for each stage to complete. Since NVOFA itself operates serially, the design is such that increasing to three or more sets does not increase throughput.
On the other hand, the constants that determine image quality still carry an experimental character. Langdale explained that the number of Picard iterations and the coefficient were chosen empirically using a small number of samples containing both uniform and non-uniform motion. A problem was also found where NVOFA generates large spurious motion in low-texture backgrounds, dragging ghosting artifacts to areas far from moving objects. The current shader mitigates this spurious flow with an empirical guard based on the luminance difference and displacement distance between the preceding and following frames.
60fps Is the Default; perf and grid Control the Workload
The output defaults to 60fps, but this is a fixed value regardless of the input frame rate—it is not necessarily a straight doubling. To scale relative to the source video, an expression such as source_fps*2 can be specified. The filter also supports configurations that composite multiple frames from the same frame pair.
Two settings adjust the speed-versus-detail tradeoff. perf has three levels—slow, medium, and fast—with the default slow prioritizing quality the most. grid selects the pixel width handled by a single flow vector, choosing from auto, 1, 2, 4, or 8. Auto uses the finest grid the GPU supports; coarsening the grid reduces computation and memory usage at the cost of being less able to capture motion in thin objects or at boundaries.
According to reference figures NVIDIA presented for SDK 5.0, when processing 1920×1080 YUV 4:2:0 with the slow preset, Ampere achieved 200fps at a 4×4 grid and 94fps at 2×2, while Ada achieved 536fps and 210fps respectively. These figures measure the optical flow API alone and do not include fruc_vulkan's luminance extraction, warping, or video decoding/re-encoding. Even so, they show that finer grids sharply increase NVOFA's workload.
As an example of processing a 2160p24 film without strain, the developer cited perf=medium and grid=2. However, no GPU model or output fps was given. This is a rough starting point for initial tuning, not a performance guarantee.
Not "Any RTX Card Will Do"
NVOFA has been included since the Turing generation, but NVIDIA's official documentation lists the Vulkan-based Optical Flow mode as unsupported on Turing. Furthermore, TU117 lacks NVOFA entirely. It cannot be summarized as "Turing or later works," including the RTX 20 series—the effective starting point for fruc_vulkan is the Ampere generation. The Vulkan interface supports Windows 10 and later, and Linux, but not WSL.
The conditions on FFmpeg's side are also new. Building requires Vulkan Headers 1.4.317 or later and an SPIR-V compiler. At runtime, in addition to VK_NV_optical_flow, it requires a compute queue and an optical flow queue, VK_KHR_maintenance9, and the capability to implicitly pass images between queues. According to NVIDIA's Vulkan driver history, maintenance9 was first listed in Windows 573.38 and Linux 570.123.18, both dated June 8, 2025. On older drivers, filter initialization will fail even on GPUs equipped with NVOFA.
Input is also restricted to Vulkan hardware frames. Most YUV and RGB formats are supported, but subsampled packed YUV formats like yuyv422 and uyvy422, formats with more than 16 bits per component, and Bayer formats are excluded. To chain decoding, interpolation, and encoding entirely within the GPU, the filters before and after must also be configured to pass Vulkan frames between them.
A line must also be drawn regarding distribution timing. FFmpeg's Changelog places fruc_vulkan under version <next> and does not include it in the version 9.0 release notes. Being merged into master is separate from being immediately selectable through OS packages or video applications. For now, this is a feature that requires building master or waiting for the next stable release and adoption by individual apps.
The Next Test Is Failure Rate, Not Smoothness
fruc_vulkan detaches video frame interpolation from a hard-to-redistribute SDK component and brings it into FFmpeg's ordinary filter chain. It could potentially be used for batch conversion, playback preprocessing, and frame rate unification for streaming. On the other hand, it is not a general-purpose Vulkan filter that also runs on AMD or Intel—it presupposes NVIDIA-specific extensions and a supporting driver.
Adoption decisions require tests that compare the same video against NvFRUC and FFmpeg's minterpolate, counting failures that occur at occlusions, scene changes, and thin outlines. Furthermore, speed must be measured from decoding through re-encoding rather than optical flow alone, and quality differences across perf and grid settings need to be published. If it is included in a stable release and major applications can reproduce that verification, GPU frame interpolation could move from being a display feature of dedicated players to a traceable step in video processing pipelines.