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

Pour une raison que je ne m'explique pas, parfois quand j'upload des vidéos sur mon WordPress, celles-ci ne fonctionnent pas correctement une fois l'article publié. Je pense que c'est parce qu'elles sont mal encodées et que par conséquent le navigateur ne sait pas les lire. Pour remédier à ça, je faisais donc un petit coup de FFmpeg , mais ouvrir le terminal et recoller les mêmes paramètres à chaque fois, c'était un peu lourdingue.

Alors j'ai repris un peu l'idée Magicbrake , mais en version automatique gérée directement dans le Finder de macOS. Un clic droit sur une ou plusieurs vidéos, et hop, le MP4 apparaît à côté de l'original sous le nom compressed_nom-original.mp4 et la source est préservée.

Étape 1 - Récupérer le kit

Je vous ai tout mis dans cette archive ZIP qui réunit le script, l'installateur, le désinstallateur et le mode d'emploi. Tout est sous licence MIT , donc modifiable et redistribuable.

Le seul prérequis est FFmpeg. Installez-le d'abord via Homebrew si nécessaire, puis lancez ceci dans le Terminal :

brew install ffmpeg

Étape 2 - Installer l'Action rapide

Décompressez l'archive. Dans le Terminal, tapez cd avec une espace, glissez le dossier compresser-video-macos dans la fenêtre et validez avec Entrée. Lancez ensuite :

chmod +x *.sh
./install.sh

L'installateur copie le convertisseur dans votre bibliothèque utilisateur et crée une Action rapide Automator dans le Finder. Du coup, aucune app de conversion à garder ouverte ni réglage à refaire.

L'Action rapide installée dans Automator, avec son unique script shell

Le hic, c'est que l'Action peut ne pas apparaître tout de suite. Relancez le Finder, ouvrez Actions rapides et cliquez sur Personnaliser… tout en bas. Activez ensuite Compresser la vidéo dans les extensions du Finder . Elle reste aussi disponible dans Services. Et si votre clic droit est désactivé, faites un Ctrl + clic sur le fichier.

Étape 3 - Compresser depuis le Finder

Sélectionnez une vidéo, ou carrément plusieurs, puis faites clic droit > Actions rapides > Compresser la vidéo. La conversion tourne en arrière-plan et, pour les vidéos un peu longues, un pourcentage d'avancement s'affiche dans la barre des menus en haut de l'écran. Une notification vous prévient quand le nouveau MP4 est prêt, dans le même dossier que sa source.

Le script ajoute compressed_ devant le nom, remplace l'extension par .mp4 et ne touche pas à l'original. Si ce nom existe déjà, il ajoute -2, puis -3. Pas d'écrasement !

Si l'Action ne marche pas, le détail est dans ~/Library/Logs/Compresser-la-video.log. Depuis le dossier du kit, lancez ./compress.sh "/chemin/vers/video.mov" pour voir FFmpeg pédaler. Si un fichier d'un lot échoue, les conversions réussies restent à côté de leurs sources.

Ce que le script fabrique vraiment

La sortie est un MP4 en H.264, avec une image plafonnée à 1080p, une cadence moyenne limitée à 30 images par seconde et une piste AAC stéréo si la source contient du son. J'ai choisi un CRF de 22 car je voulais un compromis simple entre poids et qualité. Une petite vidéo n'est pas agrandie, et faststart place l'index MP4 au début pour accélérer la lecture web.

J'ai testé du 60 i/s, du 24 i/s et une définition impaire. La première est tombée à 30, la deuxième a gardé ses 24 et la troisième a reçu des dimensions paires pour libx264 et yuv420p. Finalement, ça marche !

Perso, je garde ce réglage. Après pour mieux maîtriser la taille finale, utilisez HandBrake avec un débit moyen et deux passes .

Les limites à connaître

Par contre, ce bouton vise les vidéos SDR courantes à partager et ne garantit pas une sortie plus petite. Il ne conserve que la première piste vidéo et la première piste audio. Attention, les sous-titres, les pistes supplémentaires et le HDR demanderont un réglage sur mesure.

Et si ça ne vous convient pas, pour retirer l'Action rapide, retournez dans le dossier du kit et lancez ./uninstall.sh.

Bref, vous avez maintenant la compression vidéo directement sous le clic droit... En tout cas, même si le besoin est niche, moi ça va me servir.

Amusez-vous bien !

Vous avez déjà pesté contre votre télé qui refuse de lire une vidéo pourtant toute bête trouvée sur le web ? Hé bien Kilian Houpeurt aussi et c'est pourquoi il a décidé, plutôt que de râler dans le vide comme un mec lambda sur Twitter, qu'il allait prendre le taureau par les cornes et coder sa propre solution.

Ça s'appelle Castor et évidemment ça envoie du bois, lol. En fait c'est un outil en ligne de commande écrit en Go qui est open source et qui permet d'envoyer le vrai flux vidéo d'une page Web directement sur votre télévision en qualité max sans avoir besoin de Chromecast, ni d'AirPlay.

L'astuce, c'est qu'il ne recopie pas votre écran comme le ferait un mirroring (qui rame et qui compresse tout, on est d'accord...). Vous lui donnez simplement l'adresse d'une page Web et lui va la charger dans un Chrome Headless, c'est-à-dire sans interface et capter le trafic réseau grâce au Chrome Devtools Protocol. C'est le flux vidéo ensuite qui transite qui est repéré et qu'il prend à la source.

Derrière, vous vous en doutez, ffmpeg transcode à la volée pour votre télé pendant que ffprobe détecte le format qui arrive. Pour alimenter Castor, vous avez alors trois possibilités, soit vous lui fournissez une page Web avec la commande castor cast player, soit vous lui passez un flux brut en .m3u8 avec la commande castor cast url, ou alors simplement un identifiant IMDB/TMDB que Castor résoudra via les sources que vous avez configurées de votre côté.

Et si vous renseignez une clé TMDB, castor cast tout court vous sortira alors un navigateur interactif en plein terminal Et c'est là-dedans que vous pourrez filtrer par genre (ou peu importe la métadonnée que vous voulez) ou parcourir les films comme vous le feriez sur Netflix, ou encore aller explorer les épisodes d'une série. Qui vous fait envie. Tout ça sans jamais quitter votre terminal. Ça a quand même un peu de gueule !

Le navigateur TMDB de Castor, directement dans le terminal.

Castor sait les générer lui-même les sous-titres avec whisper.cpp avant de les incruster dans la vidéo, Mais attention quand même, le modèle par défaut ne comprend que l'anglais, si vous voulez du français, faudra faire pointer Castor vers un modèle whisper multilingue.

Enfin, côté réception, Castor sait causer DLNA / UPnP, un protocole que Samsung, LG, Sony Bravia, Panasonic, Philips, Hisense ou encore TCL savent gérer depuis des années. Un petit castor scan et il vous liste tous les récepteurs qui traînent sur votre réseau et vous verrez que Kodi, VLC et Plex répondront aussi présents. Pour ce qui est du support du Chromecast, c'est encore un peu expérimental, donc ne comptez pas trop dessus pour le moment.

L'installation sur Mac se fait via brew install --cask stupside/tap/castor. Prévoyez juste Chrome ou Chromium sur la machine + ffmpeg et ffprobe accessibles dans le PATH. Une image Docker existe avec tout dedans, mais méfiance sur Docker Desktop macOS ou Windows puisque la découverte réseau ne passe pas le bridge, donc le conteneur ne verra jamais votre télé.

Maintenant, ce n'est pas un outil de piratage, puisque Castor n'héberge rien du tout. C'est un outil générique qui pousse un flux vers une TV, et c'est à vous de respecter la loi ainsi que les conditions d'usage des sites. Bref, ne castez que ce que vous avez le droit de regarder. Pour envoyer un flux IPTV ou un bête .m3u8 sur l'écran du salon, c'est en tout cas, super pratique.

Si vous bidouillez un serveur média maison, allez donc jeter un œil à Castor , le dépôt vaut le détour !