ffmpeg – Doubler le framerate d’une vidéo avec votre GeForce

Depuis ce week-end, bonne nouvelle les zamis, puisque ce bon vieux ffmpeg sait maintenant fabriquer des images qui n’ont jamais été filmées. Oui oui ! Et ça c’est possible grâce à un filtre qui s’appelle fruc_vulkan, qui permet de calculer le mouvement entre deux images grâce au bloc dédié des GeForce RTX, pour ensuite synthétiser ce qui manque entre les deux. Grâce à ça, un 24 images par seconde ressort sans souci en version 60 images par seconde.

La cadence de sortie se paramètre, donc vous pouvez aussi faire du 25 vers du 50, du 30 vers 60, ou n’importe quelle valeur intermédiaire. C’est donc beaucoup plus souple que le filtre équivalent côté AMD, frc_amf, qui ne sait que doubler la fréquence et ne fonctionner qu’en DirectX…

Fabriquer ce genre d’images intercalaires n’a rien de neuf, cela dit… L’outil

RIFE convertissait déjà du 24 fps en 96

en 2020. Mais ce qui change ici, c’est qu’il n’y a plus de chaîne externe, plus d’aller-retour par des milliers de PNG, puisque tout tient dans le graphe de filtres, entre le décodage et l’encodage.

Le filtre logiciel historique de ffmpeg, minterpolate, existe pourtant depuis des années mais c’était loin d’être du temps réel. Alors que là, le vrai gain avec cette nouvelle feature, c’est qu’on passe en full temps réel. Ça veut dire que sur un catalogue à réencoder, l’interpolation cesse d’être l’élément qui bloque toute la chaîne de conversion.

Pour l’essayer il vous faut une RTX 30 ou plus récente. Il faut aussi compiler une version de développement car ce filtre est arrivé après la sortie de ffmpeg 9.0, ce qui veut dire que pour le moment, il n’est dans aucune release et ne sera dans aucun paquet avant la prochaine.

La commande suit ensuite le motif habituel des filtres Vulkan, qui veulent les images en mémoire GPU :

ffmpeg -init_hw_device vulkan=vk:0 -filter_hw_device vk -i entree.mp4 -vf "format=yuv420p,hwupload,fruc_vulkan=fps=60,hwdownload,format=yuv420p" sortie.mp4

L’auteur du filtre prévient quand même qu’en 2160p24, les réglages par défaut ne suivront pas en temps réel et qu’il faudra alors descendre la qualité d’estimation du mouvement. Ça s’écrit comme ceci :

fruc_vulkan=fps=60:perf=medium:grid=2

En traitement par lots maintenant, la question ne se pose pas, c’est juste plus lent.

Maintenant, les pros de l’encodage, redescendez de votre chaise parce que j’ai quand même quelques mauvaises nouvelles… Tout d’abord, on n’a aucune stat indépendante sur le débit ou la qualité. Et il y a aussi un défaut que l’auteur du patch documente lui-même… En fait, dans les zones sans texture, le moteur invente un mouvement faux mais cohérent, qui laisse des “fantômes” autour des objets. La

parade

existe heureusement, mais c’est une heuristique, qui demande quelques réglages à la main sur des échantillons.

Et il y a aussi un coût qu’on oublie… Car doubler la cadence, c’est donner deux fois plus d’images à avaler à l’encodeur, donc, il y a toujours une espèce de goulot d’étranglement. Et puis après il y a le rendu… un film de cinéma en 24 images par seconde qu’on monte à 60 prend immédiatement un aspect téléfilm que les cinéastes détestent !! Imaginez l’Odyssée de Nolan avec l’aspect visuel de Plus Belle La Vie… Ahahaha. Après sur de l’animation ou un ralenti, ça se défend bien sûr mais sur du cinéma, c’est un choix à prendre et pas une amélioration. En tout cas, c’est mon avis.

Ah et dernier point, parce que la confusion est déjà partout dans les commentaires sur le net : Tout ça se passe à l’encodage ! Je répète : A L’ENCODAGE ! Le fichier qui sort de ffmpeg est une vidéo NORMALE. Absolument personne n’aura besoin d’une carte graphique GeForce pour la regarder ! OK ? 😘

Source :

Phoronix