Sortie de FFmpeg 8.0

 (ffmpeg.org)
2 points par GN⁺ 2025-08-23 | 1 commentaires | Partager sur WhatsApp
  • FFmpeg 8.0 "Huffman" ajoute des codecs basés sur le calcul Vulkan, ainsi que le décodage et l’encodage accélérés par le matériel, et plusieurs nouveaux formats de fichier et filtres
  • L’infrastructure a été entièrement modernisée, et le processus de contribution ainsi que la qualité du code ont aussi été renforcés
  • Les principaux domaines des codecs audio et vidéo ont également progressé, avec la stabilisation du décodeur VVC, le décodeur xHE-AAC, ainsi que la prise en charge de MV-HEVC et LC-EVC
  • Le projet continue de jouer un rôle central dans le développement des technologies multimédia open source, avec des améliorations continues des fonctionnalités et de la sécurité

Présentation de FFmpeg

  • FFmpeg est une boîte à outils complète et généraliste de traitement multimédia, offrant une solution souple et puissante pour enregistrer, convertir et diffuser en streaming de l’audio et de la vidéo
  • Avec une simple commande comme ffmpeg -i input.mp4 output.avi, il est possible de traiter facilement la vidéo et l’audio

23 août 2025, sortie de FFmpeg 8.0 "Huffman"

  • FFmpeg 8.0 "Huffman" a été publié. Après plusieurs retards et une modernisation de l’infrastructure, il s’agit de la version la plus vaste jamais publiée à ce jour
  • Parmi les nouveautés figurent l’ajout de décodeurs natifs pour APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728, un renforcement de la prise en charge de l’IBC, de l’ACT et du mode Palette dans le décodeur VVC, ainsi que des codecs comme FFv1 basé sur le calcul Vulkan (encodage et décodage) et ProRes RAW (décodage uniquement)
  • Le décodage accéléré matériel basé sur Vulkan (par ex. VP9, VVC, H264/5) et l’encodage (AV1, H264/5), ainsi que divers nouveaux formats (MCC, G.728, Whip, APV) et filtres (colordetect, pad_cuda, scale_d3d11, Whisper, etc.) ont été introduits
  • Une nouvelle famille de décodeurs et d’encodeurs basée sur des compute shaders fonctionnant avec Vulkan 1.3 a été ajoutée. Cette architecture ne nécessite pas d’accélérateur matériel spécialisé distinct et fonctionne de la même manière que l’API hwaccel. Pour utiliser les encodeurs, il faut spécifier les nouveaux encodeurs ; seuls FFv1 (encodage/décodage) et ProRes RAW (décodage) sont actuellement pris en charge. La prise en charge de ProRes (dans les deux sens) et de VC-2 (dans les deux sens) est en préparation
  • Cette architecture ne peut s’appliquer qu’aux codecs optimisés pour le décodage parallèle ; elle devrait à l’avenir apporter d’importants gains de performances dans davantage de domaines, ainsi que de nouveaux usages comme le montage vidéo non linéaire et l’enregistrement sans perte
  • L’infrastructure du projet a également été fortement modernisée. Le serveur de listes de diffusion a été entièrement remplacé, et code.ffmpeg.org prend désormais en charge la collaboration au code basée sur Forgejo
  • Il est recommandé aux utilisateurs de passer à la dernière version

À lire aussi

1 commentaires

 
GN⁺ 2025-08-23
Commentaires sur Hacker News

  • Remerciements aux développeurs et contributeurs de FFmpeg

    • J’ai toujours utilisé FFmpeg dès que j’avais besoin d’automatiser de l’audio ou de la vidéo, et la plupart des outils vidéo en ligne s’appuient aussi sur cet outil comme moteur principal ou comme wrapper d’interface
    • J’ai aussi découvert aujourd’hui l’existence du projet FFmpeg.Wasm (https://github.com/ffmpegwasm/ffmpeg.wasm)
    • Partage d’une expérience de janvier 2024 : extraction des images d’un film d’animation de 1993 toutes les 15 minutes, upscaling avec Real-ESRGAN-ncnn-vulkan (https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan), puis réassemblage des images résultantes en 4K
    • Si une UI avait été ajoutée à ce workflow, cela aurait pu devenir un outil du type de Topaz AI, très populaire en ce moment
    • Une image d’exemple upscalée a aussi été partagée (image d’exemple)
    • Même quand je n’utilise pas directement ffmpeg, j’emploie souvent des outils qui l’intègrent
      • J’ai récemment upscalé un vieil anime de mauvaise qualité extrait d’un vieux DVD via k4yt3x/video2x ; l’installation était simple et libffmpeg était intégré
      • Il était possible d’utiliser les mêmes arguments d’encodage qu’avec FFmpeg
      • Pour choisir les meilleurs arguments, j’ai encodé une courte scène avec plusieurs jeux de paramètres via ffmpeg, puis extrait des images fixes avec ffmpeg pour les comparer

  • Je me réjouis que FFmpeg ait introduit des encodeurs et décodeurs vidéo basés sur des compute shaders

    • Les codecs largement pris en charge matériellement se limitent plus ou moins à H.264, H.265 et AV1, donc il serait très utile d’avoir aussi une accélération de plateforme pour d’autres codecs, même si elle est un peu moins efficace
    • Le nouvel encodeur ProRes semble utile pour un projet en cours
    • Je comprends l’explication selon laquelle les codecs génériques les plus répandus sont difficiles à prendre en charge, car ils se prêtent mal au décodage parallèle
    • Il faut utiliser des dizaines de milliers de threads, mais les dépendances de données entre images et entre tuiles rendent la parallélisation difficile
    • Les encodeurs semblent un peu plus flexibles que les décodeurs, mais encoder quelque chose comme VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) avec des compute shaders resterait un défi

    • Heureux de voir, une fois encore, l’implémentation d’encodeurs/décodeurs vidéo en compute shaders

      • À une époque, comme il n’existait que des interfaces matérielles standardisées gravées dans le silicium, j’avais demandé si des encodeurs/décodeurs Vulkan pouvaient être génériques, ce qui avait fait rire
      • Le fait que ces améliorations soient aussi disponibles sur du matériel ancien est vraiment formidable ; j’espère que cela ouvrira la voie à de nouveaux codecs et à une amélioration globale de la qualité

    • Je n’ai pas suivi l’évolution récente des décodeurs depuis plus de dix ans, mais intuitivement je m’attendrais à ce que l’accélération GPU soit surtout très utile pour le post-traitement qui transforme les données en pixels

      • La décompression initiale pourrait se faire sur CPU, puis les données décompressées seraient envoyées au GPU pour les transformations finales comme l’application des vecteurs de mouvement, l’iDCT, etc.
      • Si l’image finale se trouve déjà sous forme de texture GPU, le coût d’affichage est aussi réduit
      • Je me demande dans quelle mesure mon intuition est juste

    • Je suis toujours impressionné par le talent des mainteneurs de FFmpeg ; c’est remarquable qu’ils réalisent gratuitement un travail d’un tel niveau de difficulté

    • Ces notes de version sont vraiment passionnantes

      • Ces dernières semaines, j’ai développé un décodeur ProRes en compute shaders WebGPU, et il fonctionne suffisamment vite (j’imagine qu’Apple utilisera probablement sa propre accélération matérielle)
      • Cette approche semblerait aussi bien adaptée au nouveau codec APV d’Android
      • La spécification du bitstream ProRes a bien été soumise au SMPTE, mais il est difficile de trouver des informations sur ProRes RAW
      • Je trouve très intéressant de voir apparaître des implémentations logicielles et basées sur le compute ; j’imagine que les développeurs de ffmpeg ont sans doute fait de la rétro-ingénierie
      • D’après un rapide coup d’œil au code, cela ne semble pas très différent du ProRes standard
      • Document de spécification ProRes

  • Chaque fois que j’utilise FFmpeg, je suis impressionné (même s’il faut souvent rouvrir le manuel ou demander de l’aide à un LLM, y compris quand on utilise une GUI qui génère les commandes à partir d’options visuelles)

    • C’est devenu un multitool de transcodage indispensable
    • L’adoption de traitements basés sur Vulkan 1.3 me semble être une très bonne décision
    • J’ai aussi découvert hier qu’Asahi Linux sur Mac prenait en charge le même standard

    • Les arguments de FFmpeg sont en quelque sorte la « forme originelle du prompt engineering »

    • Les LLM et des outils en ligne de commande complexes comme FFmpeg ou ImageMagick forment une combinaison fantastique

      • On a presque l’impression d’un UI/UX futuriste parfait : il suffit de décrire en langage naturel ce qu’on veut faire pour que ce soit immédiatement réalisé
      • Par exemple, on peut imaginer un scénario où l’on recadre toutes les images d’un dossier à une taille donnée, ajuste la saturation, les enregistre en TIFF, les assemble en boucle vidéo, puis les encode pour le web en une seule fois

    • Les LLMs fonctionnent très bien comme interface pour FFmpeg

      • Il existe beaucoup d’outils qui aident à l’utiliser en langage naturel, et une personne a aussi partagé son propre script (https://github.com/jjcm/llmpeg)

  • Partage, sur le ton de la blague mais avec un fond de vérité, qu’on gaspille 50 % de son temps à construire des commandes CLI complexes pour ffmpeg, et les 50 % restants à se battre avec l’échappement shell

    • En particulier, l’échappement du texte est très difficile lorsqu’on veut incruster du texte dans une vidéo
    • La personne se demande si quelqu’un a trouvé une bonne méthode pour appeler ffmpeg depuis Python avec beaucoup d’arguments, notamment des filtres (r-strings ? heredocs ? etc.)

  • Quelqu’un demande s’il existe un bon frontend GUI permettant de manipuler facilement les nombreuses fonctions de FFmpeg

    • Parfois, on a juste besoin de faire un remux, ou simplement de combiner des flux vidéo/audio avec le même codec

    • Assembler des vidéos semble simple, mais il y a en réalité beaucoup de variables et de problèmes potentiels

      • Base de temps, offset de départ, recadrage d’image, différences de FPS, B-frames, open GOP, etc. peuvent tous poser problème selon l’environnement de lecture
      • Côté audio aussi, il existe de nombreuses variables comme les différences de fréquence d’échantillonnage
      • Le programme Lossless-Cut a été mentionné, sa fonction de vérification de compatibilité étant utile
      • Mais convertir d’abord les vidéos en MPEG-TS avant de les concaténer permet souvent de contourner plusieurs problèmes, tout en restant rapide sur un disque RAM
      • Une séquence de lignes de commande ffmpeg utilisable en exemple a également été partagée

    • Handbrake remplit bien ce rôle

      • C’est suffisamment complet sur le plan fonctionnel, un peu daté peut-être, mais toujours très utile

    • Pour les utilisateurs Mac, recommandation de ffWorks (https://www.ffworks.net/index.html)

      • La plupart des fonctions sont facilement accessibles, avec prise en charge du traitement par lots et des préréglages
      • Le développeur fournit un support très actif ; c’est l’une de leurs applications préférées et elle leur semble suffisamment précieuse pour mériter un don
      • Handbrake et Losslesscut sont excellents, mais sur les autres plateformes, rien ne semble rivaliser avec le niveau de finition de ffWorks

    • La meilleure interface pour cette personne, c’est ChatGPT

      • En décrivant la tâche souhaitée en langage naturel, il génère des commandes ffmpeg remarquablement précises

    • Recommandation de jeter un œil au programme Lossless-cut

  • Partage d’un lien permettant de consulter le changelog de FFmpeg (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • Brève réaction pour dire que c’est une nouvelle intéressante

    • Quelqu’un se demande si cette vidéo est satirique ou sérieuse

  • Avis personnel selon lequel ffmpeg est peut-être la 4e bibliothèque la plus utilisée après ssl, zlib et sqlite, en partant du principe qu’en 2025, la vidéo est vraiment partout

    • Une autre personne n’est pas d’accord, estimant que le traitement vidéo est surtout nécessaire sur les serveurs qui reçoivent des médias

      • Il est mentionné que la plupart des téléphones ne traitent pas la vidéo avec ffmpeg

    • curl est peut-être encore plus haut dans le classement, et « SSL » regroupe en réalité plusieurs implémentations, ce qui disperse les chiffres

    • Les logs de métriques Fastly de l’infrastructure NixOS (https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md) sont proposés comme source de données

    • Certains pensent qu’il existe pas mal de bibliothèques plus utilisées que ffmpeg, comme Qt, libpng ou libusb

    • Les statistiques de paquets d’Arch Linux (https://pkgstats.archlinux.de/packages) valent aussi le détour

  • L’implémentation en compute shaders Vulkan est jugée particulièrement impressionnante, surtout pour FFv1 et ProRes RAW

    • Comme cela contourne complètement les décodeurs matériels à fonction fixe, la question se pose de savoir quel est l’impact sur la bande passante mémoire
    • Le codage arithmétique adaptatif au contexte de FFv1 semble intrinsèquement séquentiel, donc il est surprenant d’obtenir un gain de vitesse aussi important
    • On se demande s’il s’agit d’une parallélisation de plusieurs symboles en même temps ou par slices, et quels compromis l’équipe ffmpeg a faits, sachant que l’accélération GPU du codage arithmétique a traditionnellement été difficile
    • Si quelqu’un a déjà profilé cette implémentation, il serait intéressant d’entendre des retours sur l’occupation et les choix de bande passante au niveau du décodage entropique

  • ffmpeg constitue la base d’un très grand nombre d’outils

    • Le grand public mesure souvent mal à quel point ffmpeg a contribué à l’industrie des médias
    • C’est l’outil vers lequel on revient toujours dès qu’on a besoin d’automatiser de l’audio ou de la vidéo