Améliorer FFmpeg pour des performances d’encodage supérieures

Kevin van Zonneveld

Cofondateur · Amsterdam, Pays-Bas · Afficher la bio

Avis historique : cet article de 2015 décrit la stack FFmpeg v2.2.3. Cette stack a atteint sa fin de vie le 1er février 2020 et n’est plus acceptée. Consultez la documentation des Robots pour connaître la valeur ffmpeg_stack actuellement recommandée.

Transloadit, c’est une petite équipe d’ingénieurs, c’est du code, c’est une plateforme hautement évolutive, c’est une bande de Robots excentriques à qui vous pouvez demander d’importer et de convertir des médias. Au cœur de ces Robots se trouvent souvent des outils open source qui font le gros du travail. L’un d’eux se distingue en particulier : FFmpeg⁠.

Historique

Nous utilisons FFmpeg depuis nos débuts en 2009. À l’époque, nous n’avions qu’une seule version, que nous appelons aujourd’hui v0.0.1. En 2011, nous avons sponsorisé Stefano Sabatini, membre de l’équipe de développement principale de FFmpeg, afin qu’il conçoive une nouvelle version sur mesure pour nous, car nous voulions que nos clients puissent ajouter des filigranes aux fichiers webm, ce qui n’était pas possible à l’époque.

La technologie évolue toujours vite, et l’encodage de médias ne fait pas exception. Pour rester à jour, nous devons continuer à mettre à niveau FFmpeg. Dans le même temps, nous ne voulons pas casser les configurations existantes de nos clients en raison de problèmes de rétrocompatibilité. Transloadit propose des préréglages pratiques, par exemple pour optimiser une vidéo pour iPad, qu’il est relativement facile de porter d’une version à l’autre, mais nous offrons aussi aux utilisateurs avancés un contrôle fin du comportement de FFmpeg. Cette dernière catégorie de clients, en particulier, serait à juste titre mécontente si ses instructions détaillées n’étaient soudainement plus prises en charge à cause d’une mise à niveau.

Plusieurs versions

C’est le souhait d’avancer sans casser les configurations existantes qui a motivé la conception d’un système dans lequel les nouvelles versions de nos outils d’encodage peuvent coexister et ne s’appliquent que lorsque le client choisit explicitement de les activer.

Jusqu’à présent, nous avons lancé les versions de stack suivantes :

• v0.0.1 le 13 juillet 2009
• v1.0.0 le 27 avril 2011
• v2.0.0 le 7 juillet 2013
• v2.1.0 le 12 novembre 2013
• v2.2.3 le 3 juin 2014

Nous avons toujours utilisé des compilations personnalisées ; c’est pourquoi nous proposons une page dédiée qui présente tous les formats et codecs pris en charge pour chaque stack.

Lancements progressifs

Au fil des années, nous avons accumulé 9905 tests automatisés, dont beaucoup s’appuient sur des comparaisons visuelles pour vérifier que notre encodage fonctionne comme prévu. Malgré cela, il existe toujours ce scénario étrange où un utilisateur final étrange produit un mp4 étrange avec un second flux vidéo étrange, qui provoque des problèmes pour lesquels nous n’avions pas encore de tests. Bien sûr, à la fin de la journée, nous aurons ces tests en place. 😄

C’est pourquoi nous avons jusqu’ici toujours opté pour des lancements progressifs de nos versions de stack. Nous travaillons généralement avec une poignée de clients puis, à mesure que la confiance dans la nouvelle compilation grandit, nous commençons à la recommander à de plus en plus de clients.

Au final, notre documentation recommandera cette version comme stack de référence. Une mise à niveau organique.

Comme nous n’avons jamais déprécié de stack, cette approche a bien fonctionné pour nous et pour nos clients. Cependant, cela pourrait changer, et nous allons expliquer pourquoi.

Dépréciation

Jusqu’ici, nous n’avons jamais déprécié de stack. Pourtant, en réalité, chaque stack ajoutée ralentit un peu nos déploiements et augmente légèrement la charge de notre support client. De plus, à chaque mise à niveau du système d’exploitation que nous déployons sur nos clusters, les stacks anciennes deviennent plus difficiles à compiler et moins capables de fonctionner sans accroc. Même si nous passons aux conteneurs⁠, qui aideront à résoudre ces problèmes de compatibilité, ils ne contribueront pas à réduire notre charge de déploiement, de support et de maintenance.

C’est pourquoi nous envisageons désormais de déprécier notre stack FFmpeg v1.0.0 de 2009 au cours de l’année à venir. Il nous a semblé préférable de vous en informer dès que possible. Nous ne ferons certainement rien d’imprudent. Si nous vous en parlons maintenant, c’est uniquement parce que nous y avons réfléchi aujourd’hui.

Stack FFmpeg v2.2.3

Remarque : notre gestion des versions peut ressembler à SemVer⁠, mais ce n’est pas le cas. Il s’agit d’une numérotation interne à Transloadit, sans signification sémantique publique. Toute version peut rompre la rétrocompatibilité et doit être traitée comme telle lors d’une mise à niveau.

Notre dernière version de stack est celle dont nous tirons le plus de fierté. Certes, v1.0.0 est peut-être restée plus longtemps en production, et elle était sans aucun doute en avance sur son temps 😄, mais nous avons investi plus d’efforts dans v2.2.3 que dans toute autre version. Elle est déjà en production depuis plus d’un an. Elle a traité plus de trafic que toutes les versions précédentes. Nous rencontrons très rarement (jamais est un mot dangereux que nous préférons éviter) des problèmes imputables à un défaut de cette compilation.

Le fait qu’elle soit utilisée par certains de nos plus grands clients entreprise, avec les cas les plus extrêmes, nous a donné la confiance nécessaire pour recommander sans réserve cette compilation à tous nos clients, pour tous leurs besoins d’encodage audio et vidéo.

Mise à niveau

Considérez ces exemples d’instructions, dans lesquelles les fichiers envoyés sont convertis au format iPad, des miniatures d’aperçu sont extraites, puis tous les résultats sont exportés vers votre serveur privé via SFTP :

steps:
  ipad:
    use         : ":original"
    robot       : "/video/encode"
    preset      : "ipad-high"
  thumbnails:
    use         : "ipad"
    robot       : "/video/thumbs"
  store:
    use         : [ ":original", "ipad", "thumbnails" ]
    robot       : "/sftp/store"
    user        : "transloadit-uploader"
    host        : "my.website.com"
    path        : "./transloadit-uploads"
    url_template: "https://my.website.com/transloadit-uploads/${file.url_name}"

Pour que ces instructions utilisent notre dernière stack, ajoutez un paramètre ffmpeg_stack aux Steps d’encodage :

steps:
  ipad:
    use         : ":original"
    robot       : "/video/encode"
    preset      : "ipad-high"
    ffmpeg_stack: "v2.2.3"
  thumbnails:
    use         : "ipad"
    robot       : "/video/thumbs"
    ffmpeg_stack: "v2.2.3"
  store:
    use         : [ ":original", "ipad", "thumbnails" ]
    robot       : "/sftp/store"
    user        : "transloadit-uploader"
    host        : "my.website.com"
    path        : "./transloadit-uploads"
    url_template: "https://my.website.com/transloadit-uploads/${file.url_name}"

C’est tout ! 😄

Vous pouvez appliquer le paramètre ffmpeg_stack aux Robots suivants :

 EN (English)  EN (English)  EN (English)

Non seulement votre encodage sera plus rapide, mais vous profiterez aussi d’une meilleure qualité et pourrez prendre en charge davantage de formats d’entrée qu’avec toute version précédente.

Mises en garde

Trop beau pour être vrai ? Eh bien non, mais il y a quelques points à surveiller : le mappage et les noms de paramètres modifiés.

Mappage

Tous les préréglages v2.2.3 (comme android ou iphone) ont été ajustés pour ignorer les flux de données et de sous-titres. Très peu de clients utilisaient ces flux, mais comme nous essayions auparavant de leur faire une place dans les fichiers de sortie, en échouant parfois, nous avons involontairement donné bien du fil à retordre à la majorité de nos clients, qui « veulent juste des résultats ».

Si vous dépendez de flux de données ou de sous-titres, vous pouvez toujours utiliser les préréglages v2.2.3 et profiter des autres améliorations de cette version, mais vous devrez surcharger le paramètre map avec 0. Ainsi, tous les flux d’entrée trouveront leur place dans le fichier de sortie, au prix de certains fichiers qui feront échouer FFmpeg, puisqu’il tentera d’interpréter des flux de données non pris en charge.

Un client a signalé un problème avec un fichier d’entrée qui comportait deux flux vidéo. Nos préréglages v2.2.3 tentent de faire une place à tous les flux vidéo et audio dans le nouveau fichier. Si seuls un flux vidéo et un flux audio vous intéressent, définissez le mappage ainsi :

ipad:
  use         : ":original"
  robot       : "/video/encode"
  preset      : "ipad-high"
  ffmpeg_stack: "v2.2.3"
  ffmpeg:
    map: [
      "0:v:0?"
      "0:a:0?"
      "-0:d"
      "-0:s"
    ]

Même si cela vous offre le mappage le plus robuste, notez qu’un second flux du même type de média serait ignoré.

À vrai dire, cela ne semble pas poser de problème aux utilisateurs finaux dans 99 % des cas que nous observons ; nous envisageons donc d’en faire le comportement par défaut des préréglages de notre prochaine stack destinés aux appareils mobiles.

Nous recommandons toujours d’exporter les fichiers :original avec les résultats d’encodage : ainsi, si vos réglages ne vous satisfont pas, vous pourrez facilement rejouer l’Assembly avec de nouveaux paramètres d’encodage.

Noms de paramètres modifiés

Là où FFmpeg utilisait auparavant un paramètre -b pour le débit vidéo et un paramètre -ab pour le débit audio, il évolue vers une syntaxe -b:v et -b:a. C’est également le cas pour de nombreux autres paramètres, comme -codec:v par rapport à -codec:a.

En plus d’être plus cohérente, cette syntaxe offre aussi davantage d’expressivité. Par exemple, si vous voulez uniquement spécifier le codec du deuxième flux audio, vous pouvez écrire -codec:a:1 (le premier flux a l’indice 0, le deuxième a donc l’indice 1).

Ainsi, si vous voulez surcharger le débit audio d’un préréglage ipad-high v2.2.3, sachez que ab est désormais devenu b:a, sinon vos modifications du préréglage risquent de rester sans effet :

ipad:
  use         : ":original"
  robot       : "/video/encode"
  preset      : "ipad-high"
  ffmpeg_stack: "v2.2.3"
  ffmpeg:
    "b:a": 144000

Conclusion

Nous constatons de nettes améliorations avec notre dernière stack FFmpeg. Elle est plus rapide, offre une meilleure qualité, prend en charge le streaming adaptatif HTTP Live Streaming (HLS), et bien plus encore.

Nous recommandons à tous nos clients de commencer à l’utiliser, même au départ pour un petit pourcentage seulement de leurs Assemblies, et de nous signaler tout problème qu’ils rencontreraient au-delà des mises en garde que nous avons mentionnées.

Plus tard cette année, en fonction surtout de vos retours, nous prévoyons de déprécier notre stack v1.0.0, qui aura alors 7 ans, et nous lèverons certainement notre verre ensemble à cette occasion ! 😄