DevNews

FFmpeg accueille l'interpolation d'images NVIDIA

Sur cette page
  1. Un filtre Vulkan, pas un filtre CUDA
  2. Les deux options qui décident de l'utilisabilité
  3. Ce qui n'a pas tenu
  4. Ce que cela change
  5. Sources et pour aller plus loin

FFmpeg a reçu le samedi 29 août 2026 un filtre d'augmentation de cadence, fusionné sous la forme d'une série de commits fruc_vulkan. Le filtre prend une séquence à faible cadence et invente les images manquantes, en calculant le mouvement avec l'extension de flux optique NVIDIA exposée par Vulkan et non par CUDA. C'est ce dernier point qui compte pour quiconque construit une chaîne de transcodage : il s'agit d'un filtre Vulkan ordinaire, dans une chaîne Vulkan ordinaire. Les deux nouvelles options, perf et grid, décident si le filtre tient la cadence sur vos contenus ou décroche.

The short answer

FFmpeg a fusionné un filtre d'augmentation de cadence dans git master le samedi 29 août 2026, sous la forme d'une série de commits fruc_vulkan. Il calcule le mouvement entre les images avec l'extension de flux optique NVIDIA exposée par Vulkan, puis déforme les images voisines le long de ce mouvement pour fabriquer les images intermédiaires. Deux nouvelles options pilotent le coût : perf choisit une estimation de mouvement slow, medium ou fast, et grid choisit la grille de sortie du champ de flux, de la plus fine que le matériel supporte jusqu'à huit pixels. La documentation précise qu'un contenu 2160p24 demande des réglages réduits, donnés comme perf=medium et grid=2. Un pilote Vulkan exposant VK_NV_optical_flow reste nécessaire.

fruc_vulkannouveau filtre FFmpeg, fusionné le 29 août 2026
3 niveauxde flux optique : slow, medium, fast
grille 1 à 8pixels par vecteur, plus grossier est plus rapide
Carte décrivant le filtre fruc_vulkan fusionné dans FFmpeg le 29 août 2026, ses trois niveaux de performance de flux optique et ses tailles de grille de 1 à 8 pixels.
Ce qui a atterri dans FFmpeg ce week end, et les deux options qui décident du débit. PNG

L'interpolation d'images vit depuis des années dans les lecteurs propriétaires et les panneaux de configuration de pilotes. La retrouver comme filtre dans l'outil que tout le monde scripte déjà change la donne.

Un filtre Vulkan, pas un filtre CUDA

Le détail qui mérite qu'on s'arrête, c'est l'endroit où vit le code. NVIDIA embarque un moteur de flux optique depuis plusieurs générations, et la voie habituelle pour l'atteindre était le SDK maison. Ce filtre passe par VK_NV_optical_flow, une extension Vulkan, ce qui en fait un membre ordinaire de la chaîne de filtres Vulkan.

Cela compte si vous construisez une chaîne plutôt qu'une commande isolée. Les images déjà en mémoire Vulkan y restent. Vous ne recopiez pas vers la mémoire système pour interpoler, puis en sens inverse pour redimensionner ou encoder. La série de commits montre la tuyauterie : le filtre commence comme une copie du filtre framerate, devient un filtre Vulkan, puis reçoit un vrai pipeline de flux optique, des ressources de flux en double tampon et des soumissions pipelinées entre files. Un commit d'appoint ajoute ff_vk_exec_add_dep_signal_sem au code Vulkan partagé, exactement le genre de changement que l'on fait quand deux files doivent se passer du travail sans se bloquer.

Les commits suivants élargissent les formats supportés au RGB planaire et à d'autres formats empaquetés, cessent de recalculer la déformation pour chaque plan, et suppriment le flux parasite dans les zones sans relief. Ce dernier point est un problème classique : un ciel uniforme ou un mur nu ne donne aucune accroche au moteur de flux optique, et les vecteurs qu'il renvoie là sont du bruit le long duquel on ne veut surtout pas déformer.

Les deux options qui décident de l'utilisabilité

Le filtre est arrivé avec fps, évalué comme une expression, avec source_fps disponible et 60 par défaut. Le commit qui compte pour dimensionner une machine a ajouté les deux autres.

Carte terminal montrant une commande ffmpeg qui envoie les images vers Vulkan, applique le filtre fruc_vulkan avec les options fps, perf et grid, puis redescend les images pour l'encodage.
Le filtre s'insère dans une chaîne Vulkan, les images restent donc sur le GPU entre la montée et la descente. PNG

perf fixe le niveau de performance du flux optique à slow, medium ou fast. Il était figé sur slow auparavant, et slow reste la valeur par défaut. La documentation en fait le coût dominant en haute résolution, ce qui est une formulation honnête : en 1080p vous n'y toucherez peut être jamais, en 4K c'est le premier levier que vous chercherez.

grid fixe la taille de la grille de sortie du champ de flux en pixels. auto est la valeur par défaut et choisit la grille la plus fine que le matériel supporte, en général un vecteur par pixel. Vous pouvez demander 1, 2, 4 ou 8, et seules les tailles annoncées par le matériel sont acceptées. Plus grossier signifie moins de vecteurs à calculer et moins de mémoire à leur consacrer, au prix du détail du flux, ce qui se voit d'abord sur les petits objets rapides.

L'exemple donné dans le message de commit est la partie utile. Pour un contenu cinéma en 2160p24, la documentation propose perf=medium et grid=2 comme réglages qui laissent le filtre tourner confortablement. Si vous dimensionnez une machine pour cet usage, partez de là plutôt que des valeurs par défaut.

Ce qui n'a pas tenu

Le même week end, une branche de filtres vidéo NVIDIA RTX est également apparue dans le dépôt FFmpeg avant d'en disparaître. Elle apportait la vibrance dynamique via le réseau DeepDVC de NVIDIA sur CUDA, de la mise à l'échelle via DLPP et NGX, la génération d'images Smooth Motion, RTX TrueHDR et RTX Video Super Resolution. Au matin du 30 août, ce code n'était plus dans master.

Voyez y un rappel du fonctionnement de l'amont. Une fusion n'est pas une publication, et une branche qui touche autant de surface propriétaire fait généralement l'objet d'un second examen. La série fruc_vulkan est celle qui est restée, et c'est déjà elle qui porte une montée de version et une entrée dans le Changelog.

Ce que cela change

Pour qui maintient une ferme de transcodage, la question n'est pas de savoir si les images interpolées sont belles dans une démonstration. C'est ce que coûte le filtre par flux, et si ce coût est prévisible. Deux réglages documentés et un exemple chiffré en 4K, c'est plus que ce que livrent la plupart des filtres accélérés.

Le motif général mérite aussi d'être noté. Les fonctions de calcul des fabricants arrivent de plus en plus dans les chaînes ouvertes par l'interface graphique plutôt que par le SDK de calcul, ce qui explique une partie de la lenteur du portage d'une pile de calcul complète vers un autre système, comme le montre l'effort ROCm sur FreeBSD, et pourquoi ROCm 10.0 s'est réorganisé autour d'une pile pour développeurs. Quand la fonction est une extension Vulkan, tout ce qui parle déjà Vulkan en hérite.

Sources et pour aller plus loin

Questions fréquentes

Que fait exactement le filtre fruc_vulkan ?

Il augmente la cadence d'une séquence en fabriquant des images qui n'ont jamais été tournées. Pour chaque paire d'images réelles, le filtre demande au moteur de flux optique NVIDIA un champ de mouvement, puis déforme les images voisines le long de ce mouvement pour construire les images intermédiaires exigées par la cadence demandée. C'est différent de l'ancien filtre framerate, qui mélange ou duplique. Le mélange produit du dédoublement sur les mouvements, la duplication produit des saccades. Déformer le long d'un mouvement mesuré donne quelque chose qui ressemble à une image prise au bon instant, tant que l'estimation de mouvement tient.

Quel matériel et quels pilotes faut il ?

Un pilote Vulkan qui annonce l'extension VK_NV_optical_flow, ce qui suppose en pratique un GPU NVIDIA doté du moteur de flux optique et un pilote récent. NVIDIA documente l'augmentation de cadence bâtie sur ce moteur pour l'architecture Ada dans la documentation de son Optical Flow SDK. Comme il s'agit d'un filtre Vulkan et non CUDA, il s'insère dans un graphe de filtres Vulkan existant et partage les images Vulkan avec le reste de la chaîne, sans aller retour par la mémoire système.

Que changent perf et grid ?

Les deux échangent de la qualité d'estimation de mouvement contre du débit, et la documentation de FFmpeg annonce clairement que vous en aurez besoin. perf accepte slow, medium ou fast, avec slow par défaut, et il est décrit comme le coût dominant en haute résolution. grid fixe la taille de la grille de sortie du champ de flux en pixels : auto choisit la grille la plus fine que le matériel supporte, en général un vecteur par pixel, et 1, 2, 4 et 8 sont acceptés si le matériel les annonce. Une grille plus grossière calcule moins de vecteurs, donc elle est plus rapide et consomme moins de mémoire, au prix du détail du flux.

Quels réglages la documentation conseille t elle sur du contenu réel ?

Le commit qui ajoute les options donne un exemple travaillé : un contenu cinéma en 2160p24 exige des réglages réduits, cités comme perf=medium et grid=2, pour que le filtre tourne confortablement. Voyez y la forme du problème plutôt qu'une recette universelle. Un flux de qualité maximale à un vecteur par pixel sur une image 4K représente beaucoup de travail par paire d'images, et la grille la plus fine n'est pas ce que vous voulez dès que la résolution monte.

Comment fixer la cadence de sortie ?

L'option fps accepte une chaîne évaluée comme une expression, et la constante source_fps y est disponible. La valeur par défaut est 60. Vous pouvez donc écrire une cible fixe, ou exprimer la cible par rapport à l'entrée, ce qui est utile dans un traitement par lots où les sources n'ont pas toutes la même cadence. Le filtre réduit la cadence obtenue vers une base de temps raisonnable et retombe sur une base de temps simple quand cette réduction dégénère.