Transloadit annonce la prise en charge de WebM avec filigrane
Aujourd’hui, nous annonçons officiellement la prise en charge du format vidéo WebM de Google.
Nous avons dû surmonter bon nombre d’obstacles pour y parvenir. J’aimerais partager avec vous quelques-unes de nos expériences.
Notre compilation personnalisée de FFmpeg était auparavant un fork de FFmpeg SoC. Bien que ce fork ait quelques versions de retard, il était riche en fonctionnalités et, surtout, il prenait en charge l’incrustation de filigranes (English). Malheureusement, le fork SoC n’était pas maintenu et le travail moderne sur WebM se faisait dans FFmpeg « head », ce qui signifiait que notre version n’allait jamais prendre en charge libvpx (le codec vidéo de WebM).
L’incrustation de filigranes ne fonctionnait tout simplement pas avec le nouveau FFmpeg, et WebM ne fonctionnait pas avec « notre ancien » FFmpeg. Nous n’avions vraiment pas d’autre choix que de trouver une solution, car supprimer purement et simplement cette fonctionnalité très appréciée n’était certainement pas envisageable pour nous.
Il nous restait donc deux options : exécuter des compilations distinctes de FFmpeg pour différentes tâches (aïe), ou faire réintégrer par quelqu’un l’incrustation de filigranes (le vfilter movie source) dans FFmpeg « head ».
Nous avons décidé de contacter l’un des développeurs de FFmpeg et nous avons travaillé ensemble à la mise en œuvre du correctif nécessaire. Dès lors, FFmpeg était capable d’incruster des filigranes dans des fichiers WebM, et nous avions déjà fait un énorme pas en avant.
Mais la ligne d’arrivée n’était pas encore franchie.
Le passage à une nouvelle version de FFmpeg nous obligeait à mettre à niveau la majeure partie de notre pile logicielle en même temps (pensez à libfaac, x264, etc.). Nous adorons Ubuntu et APT, mais à ce stade (malgré l’épinglage de versions, les paquets personnalisés, etc.), cela nous apportait plus de problèmes que cela n’en résolvait. Nos exigences en matière de versions et de compilation étaient tout simplement trop spécifiques. Comme chaque dépendance en entraînait une autre, nous avons conclu que la maîtrise complète de la pile était la seule option viable pour nous. Nous avons donc commencé à compiler des versions spécifiques d’ExifTool, ImageMagick, Theora, FAAC, JPEG, Ogg, TIFF, FAAD, LAME, opencore-amr, Vorbis, FFmpeg, live_segmenter, PNG, VPX, Ghostscript, MPlayer, SDL et x264. C’était pénible au début, mais grâce à des scripts de compilation automatisés et à notre immense suite de tests (qui compare visuellement les résultats), nous pouvons désormais cibler et corriger des problèmes d’encodage au moyen de la plus petite montée de version de n’importe quelle bibliothèque multimédia sous-jacente. Nous pouvons le faire rapidement, en toute sécurité, avec une relative facilité et sans rencontrer de conflits de paquets. Mieux encore, nous pouvons même passer d’une distribution à une autre sans affecter nos capacités d’encodage.
Ainsi, même si cela nous a pris un peu plus de temps que prévu, nous pouvons enfin – et avec joie – annoncer la prise en charge de WebM avec incrustation de filigranes, et nous disposons en prime d’une meilleure base. Et ai-je mentionné que nous n’avons cassé aucune installation client au passage ? Vive la couverture de tests !