9 points par GN⁺ 2025-01-15 | 1 commentaires | Partager sur WhatsApp
  • Les tâches FFmpeg peuvent vite impliquer des combinaisons d’options complexes ; FFmpeg By Example est un site de documentation qui permet de trouver rapidement la méthode de traitement média voulue à partir d’exemples de commandes réels
  • Le site propose aussi un dépôt GitHub, une communauté Discord et une page de contribution, afin que les utilisateurs puissent soumettre eux-mêmes de nouvelles idées d’usage de FFmpeg
  • Comme dans l’exemple du filtre testsrc, il montre en une seule commande la source d’entrée, la résolution, la fréquence d’images et le fichier de sortie, ce qui permet de reprendre directement la structure de la commande
  • Les exemples couvrent l’ensemble des tâches de traitement média : calcul de bitrate, redimensionnement d’images, réduction du bruit audio, effets de transition, mapping de flux, accélération matérielle, traitement des métadonnées, etc.
  • Chaque exemple est organisé avec des tags et une page dédiée, ce qui facilite la recherche de la commande FFmpeg nécessaire selon un filtre précis ou un objectif de conversion

Un site de documentation FFmpeg centré sur les exemples

  • FFmpeg By Example est un site web qui organise, sous forme d’exemples, différentes façons d’utiliser FFmpeg
  • Il fournit également des liens pour participer à la communauté et contribuer

Exemple de génération d’une vidéo de test avec testsrc

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 testsrc.mpg

Encodage, conversion et accélération matérielle

Traitement audio

Images et animations

Filtres et effets visuels

Extraction, analyse et métadonnées

Sources de génération et pipes de sortie

1 commentaires

 
GN⁺ 2025-01-15
Avis sur Hacker News
  • Le plaisir d’utiliser ffmpeg a augmenté de 1000 %
    Avant, je devais péniblement chercher sur Google des réponses Stack Overflow et les assembler pour fabriquer une commande ; maintenant, ChatGPT écrit la commande à ma place, c’est bien plus pratique

    • Grâce aux LLM, j’utilise ffmpeg plusieurs fois par semaine
      C’est le meilleur cas d’usage de mon outil llm cmd :

      uv tool install llm
      llm install llm-cmd

      llm cmd use ffmpeg to extract audio from myfile.mov and save that as mp3

      https://github.com/simonw/llm-cmd

    • Pendant longtemps, j’ai rangé ffmpeg dans la même boîte que les expressions régulières : ce sentiment de « je devrais vraiment apprendre ça, mais je sens que je vais détester »
      Puis ChatGPT est arrivé et a réglé les deux problèmes

    • Pareil pour moi. Ce genre de tâche est entièrement pris en charge par l’IA, et je ne suis plus qu’un intermédiaire qui copie-colle les traces d’erreur

    • Beaucoup d’autres outils sont sortis, mais je viens de faire un script qui simplifie pas mal ce genre de chaînage de commandes : llmpeg https://github.com/jjcm/llmpeg
      Si ffmpeg est installé et que la clé d’API OpenAI est définie dans les variables d’environnement, ça devrait fonctionner directement

      Démo : https://image.non.io/1c7a92ef-0917-49ef-9460-6298c7a9116c.we...

    • Mon expérience avec ffmpeg s’est améliorée quand j’ai appris comment fonctionnent les filtres complexes

  • Ça m’a rappelé que je devrais publier une méthode pour convertir en clips des cassettes vidéo familiales numérisées grâce à la détection de scènes
    Au cas où quelqu’un chercherait ça, je laisse un gist qui a plutôt bien fonctionné [0]. Cela dit, il se faisait parfois piéger par des flashs d’appareil photo ou des mouvements, donc il fallait fournir séparément les fichiers de début/fin puis les recoller avec ffmpeg [1]

    Ce qui est étrange, c’est que sur les dernières mises à jour de Mac, les performances étaient meilleures sans -c:v h264_videotoolbox. C’est peut-être une régression de performances dans Sequoia, je n’en sais rien. Sur une machine Windows avec un GPU Nvidia, le flag correspondant est -c:v h264_nvenc. Je me demande pourquoi ffmpeg ne le détecte pas automatiquement. Avec ça, j’ai obtenu une amélioration des performances d’environ
    Le seul moment où j’ai vraiment mérité mon salaire au travail, c’est quand j’ai découvert, alors qu’on s’apprêtait à payer cher pour un serveur cloud avec GPU afin de traiter de la vidéo, que le ffmpeg installé avait été compilé sans accélération GPU

    [0] https://gist.githubusercontent.com/nielsbom/c86c504fa5fd61ae...

    [1] https://gist.githubusercontent.com/jazzyjackson/bf9282df0a40...

    • Le problème des CPU cloud, c’est qu’ils n’ont pas l’encodeur vidéo matériel présent dans les CPU grand public, donc il faut passer à des machines GPU beaucoup plus chères
      Honnêtement, je n’ai pas fait de vraie comparaison de prix avec l’accélération matérielle dans le cloud ; je me demande si cela veut dire que tu l’as fait et que le rapport coût/performance était correct

    • J’ai essayé la détection des scènes vides avec ffmpeg
      J’ai une caméra orientée vers la trajectoire d’approche de SFO, et en supprimant toutes les images sans mouvement, je n’obtiens plus qu’une vidéo continue des avions qui passent, sans les passages ennuyeux

    • -c:v h264_nvenc est utile pour l’encodage par lots de plusieurs vidéos à la fois, car cela permet d’augmenter le débit d’encodage
      En revanche, lors de tests limités que j’avais faits auparavant, la qualité de sortie était légèrement inférieure à celle de libx264. Je ne sais pas s’il existe un contournement, mais je n’étais pas le seul à l’avoir constaté

    • Si ffmpeg ne le détecte pas automatiquement, c’est parce que l’encodage matériel offre généralement moins de réglages, implique davantage de compromis que des codecs logiciels sophistiqués, et ne produit pas exactement le même résultat avec les mêmes paramètres
      En plus, il y a souvent plusieurs API matérielles possibles sur un même système, avec des fonctionnalités différentes

      FFmpeg est un outil en ligne de commande complexe destiné à des utilisateurs prêts à en apprendre les détails ; je ne suis donc pas sûr qu’il soit pertinent de choisir des valeurs par défaut sur la base d’hypothèses

    • À voir l’extrait, il ne semble pas faire de désentrelacement
      Si le clip a déjà été désentrelacé avant la numérisation, c’est très bien ; sinon, encoder du contenu entrelacé en progressif revient à en dégrader la qualité. Il faudrait essayer d’ajouter le filtre bwdif pour que le contenu 30i soit encodé en 60p. Le résultat devrait ressembler davantage à la cassette vidéo d’origine

  • Avec le temps, je me suis pas mal familiarisé avec différentes parties de ffmpeg. La CLI a sa propre logique et elle dépend de l’ordre des arguments. Ce n’est pas le cas de toutes les CLI Unix
    Ces derniers temps, je touche à des fonctionnalités un peu plus obscures. Par exemple, enregistrer directement le flux brut d’une caméra vidéo sur une machine assez lente. J’ai construit un microscope et je lis depuis la caméra des images dans un format vidéo brut (YUYV 1280x720) à 120 FPS ; si je les écris telles quelles sur le disque, ça monte à plusieurs gigaoctets par minute. Les disques ne coûtent pas cher, mais ça me semblait du gaspillage, alors j’ai étudié des techniques quasi sans perte capables de compresser et d’enregistrer rapidement une image fidèle

    J’ai découvert que la conversion RGB24 dans ffmpeg était très lente ; après avoir bricolé diverses lignes de commande, je me suis arrêté sur celle-ci :

    ffmpeg -f rawvideo -pix_fmt yuyv422 -s 1280x720 -i test.raw -vcodec libx264 -pix_fmt yuv420p movie.mp4 -crf 13 -y

La vidéo brute n’a pas de conteneur, donc pas de métadonnées comme le « format de pixels » ou la « taille de l’image » ; il faut donc les fournir soi-même. C’est dépendant de l’ordre : tout ce qui se trouve avant -i test.raw sert au décodage de l’entrée, et tout ce qui vient après sert à l’écriture de la sortie. On ne fait qu’une toute petite conversion de format de pixels (que ffmpeg peut traiter très vite), puis on écrit les données dans un format avec conteneur, quasiment sans perte. Dans la plupart des cas, le meilleur conteneur était .mkv

Comme je déteste la ligne de commande, j’ai fini par utiliser ffmpeg-python, et je lui ai fait composer la ligne de commande avec le code suivant :

self.process = (
ffmpeg.
input(
"pipe:",
format="rawvideo",
pix_fmt="yuyv422",
s="{}x{}".format(1280, 720),
threads=8
)
.output(
fname, pix_fmt="yuv422p", vcodec="libx264", crf=13
)
.overwrite_output()
.global_args("-threads", "8")
.run_async(pipe_stdin=True)
)

Et en pratique, je fais un write() des frames sur l’entrée standard de ce processus. La machine a 12 cœurs, et comme le pilotage du microscope en utilise toujours au moins 2, il fallait limiter le nombre de threads

Je cherche encore un encodage YUV sans perte meilleur et plus rapide

  • La dépendance à l’ordre est appropriée. Les pipelines Unix dépendent eux aussi de l’ordre des composants, et les appels FFMpeg complexes font quelque chose d’assez similaire
    Beaucoup de gens aiment l’esthétique des « interfaces fluides » comme ffmpeg-python, mais en Python elles sont souvent jugées peu pythoniennes. Je comprends que ffmpeg-python a été conçu pour refléter de près l’ordre de la ligne de commande

    La préférence renforcée par la conception de la bibliothèque standard et des types intégrés est une forte https://en.wikipedia.org/wiki/Command%E2%80%93query_separati.... Avec ce principe, cela ressemblerait à peu près à ceci :

    ffmpeg(global_args=..., overwrite_output=True).process_async(piped_input(...), output(...))

    Faire de l’entrée une étape de configuration distincte crée un autre type à l’exécution, et peut aussi indiquer au code de traitement qu’il doit lire depuis l’entrée standard

  • Plus besoin de chercher : FFV1 https://trac.ffmpeg.org/wiki/Encode/FFV1

  • Je n’ai qu’un mot à recommander : ramdisk
    Si vous avez des fichiers à traiter comme étape intermédiaire mais que vous ne voulez pas les conserver, c’est ramdisk. Vraiment excellent

  • Je pensais que ce serait un site qui rassemble et maintient le savoir accumulé par des utilisateurs expérimentés de FFmpeg, mais j’ai été déçu dès le premier exemple sur lequel j’ai cliqué
    https://www.ffmpegbyexample.com/examples/l1bilxyl/get_the_du...

    Il ne faut pas appeler deux outils de plus pour faire du traitement de chaîne. FFprobe peut à lui seul donner directement la durée, ou la valeur souhaitée :

    ffprobe -loglevel quiet -output_format csv=p=0 -show_entries format=duration video.mp4

    Il ne faut pas s’arrêter à la première chose qui marche ; une fois que ça marche, il faut se demander s’il existe une meilleure façon de faire

    • Je suis l’auteur du billet original. Dire que c’est « dingue » me semble un peu exagéré
      Cela dit, je préfère la solution proposée
  • Bien. Ça me rappelle mon pense-bête ffmpeg. J’imagine que tous ceux qui utilisent souvent ffmpeg ont une collection de notes assez similaire
    https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md

  • FFmpeg fait partie de ces outils que j’utilise trop rarement pour que la syntaxe exacte me reste jamais en tête. Au final, je demande à un LLM la ligne de commande dont j’ai besoin
    Le seul outil qui m’ait posé des difficultés comparables était le MegaCLI façon années 1990 de LSI Logic. Lui aussi, je ne l’utilisais presque jamais d’une année sur l’autre, mais c’était le genre d’outil qu’il fallait savoir utiliser exactement, sous pression

    • J’utilise FFMPEG depuis plus de 15 ans, mais je ne me souviens toujours presque jamais des commandes. Cela dit, les LLM sont vraiment extraordinaires pour FFMPEG
      Si vous dites à ChatGPT et Claude : « remuxe la vidéo en mkv, inclue subtitle.srt dans le fichier, et je ne veux que la partie de 0:00:05 à 0:01:00 », ils s’en sortent très bien. Au cas où vous seriez curieux, le résultat était : ffmpeg -i input.mp4 -i subtitle.srt -ss 00:00:05 -to 00:01:00 -map 0 -map 1 -c copy -c:s mov_text output.mkv

      Je me demande jusqu’à quel point on pourrait faire un petit LLM si l’objectif se limitait à générer des commandes ffmpeg. Peut-être assez petit pour être mis sur une page web statique et exécuté localement ?

    • Depuis 15 ans, je maintiens un document de notes personnel avec les syntaxes que j’utilise souvent. Et si ça ne suffit pas, je fais un grep dans mon historique bash

    • Pareil pour moi. La seule chose qui me reste en tête, c’est comment convertir du format X vers .mp4. Pour tout le reste, je dois rechercher à nouveau à chaque fois
      XKCD lié https://xkcd.com/1168/

    • Il y a quelques jours, à moitié en plaisantant, à moitié sérieusement, j’ai dit que si un LLM pouvait juste me donner les flags ffmpeg que je veux, cela vaudrait peut-être le coup de brûler toute la forêt tropicale

  • Il ne faut pas oublier qu’il existe aussi GStreamer. Comme il est basé sur des pipelines, sa ligne de commande et sa documentation sont un peu plus faciles à comprendre que celles de ffmpeg, et les compositions sont aussi un peu plus sensées
    Pour les gros travaux vidéo, j’ai complètement abandonné ffmpeg et je n’utilise plus que GStreamer

    • GStreamer peut offrir davantage de contrôle et une API plus agréable quand on construit des pipelines par programmation
      Mais pour les tâches ponctuelles, ffmpeg semble beaucoup plus convivial. Par exemple, ffmpeg a des valeurs par défaut raisonnables pour x264, alors qu’avec gst-launch, il faut vraiment savoir ce qu’on fait pour obtenir un encodage x264 de bonne qualité
    • Je pensais que FFmpeg était aussi basé sur des pipelines. Il y a bien les graphes de filtres, non ? Est-ce que je rate quelque chose ?
      On peut construire des graphes complexes de sources, de sinks et de filtres de transformation
    • GStreamer donne l’impression d’être un projet laissé à l’abandon. Il y a aussi eu une grosse vulnérabilité récemment, et la documentation est assez cassée
  • Il existe un dépôt GitHub d’un livre sur ffmpeg qui pourrait bien compléter ce site :
    https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook

  • ffmpeg m’a toujours donné l’impression d’être une application GUI qu’on aurait forcée à rentrer dans un format TUI
    J’ai aussi eu quelques expériences désagréables avec l’API C ; elle est intuitive à bien des égards, mais il est beaucoup trop facile de représenter un état invalide. J’aimerais qu’il existe un framework d’encodage AV1 en temps réel qui « marche tout simplement »

    • C’est quasiment le seul outil pour lequel je me tourne d’abord vers HandBrake, qui est en gros une alternative GUI. La seule exception, c’est pour le traitement par lots
      Il existe aussi quelques GUI pour ffmpeg pur. Il y a quelque chose, dans le travail vidéo, qui ne correspond pas bien à ma manière de penser avec la ligne de commande

    • Côté API, je peux recommander GStreamer. Je l’ai utilisé avec les bindings Rust, donc je ne suis pas très familier de l’API C, mais elle m’a semblé bonne
      Il y a des aspects verbeux à cause de GObject, mais une fois qu’on les a compris, on peut interagir de manière cohérente avec tous les objets de l’API. Il y a vraiment beaucoup de complexité nécessaire (la vidéo, c’est difficile), mais la conception, l’implémentation et la documentation sont plutôt bien faites

      Pour les cas d’usage courants, les Bins (decodebin, transcodebin, playbin) rendent les choses assez faciles. Même pour des cas d’usage plus complexes, la flexibilité de la conception les rend possibles

    • J’aime bien l’idée, mais une TUI, c’est quelque chose de graphique, alors que ffmpeg est simplement une CLI
      Ce serait sympa d’avoir un outil TUI. Quelque chose comme https://github.com/Twinklebear/fbed, mais avec des fonctionnalités plus abouties

  • Sur les systèmes Linux, j’aime bien faire un build statique de ffmpeg, parce que la version de la distribution est parfois trop ancienne ou qu’il manque des modules que je préfère
    Cette version conteneurisée m’a été très utile : https://github.com/wader/static-ffmpeg