Le navigateur comme environnement de traitement
Il y a cinq ans, si vous aviez dit à un développeur qu'un navigateur pouvait exécuter FFmpeg et traiter des fichiers vidéo localement, vous auriez eu droit à quelques regards très sceptiques. JavaScript était considéré comme trop lent pour des tâches de calcul lourdes comme le traitement multimédia. Le navigateur servait à afficher des pages web, pas à exécuter des outils qui demandaient traditionnellement des binaires natifs compilés.
WebAssembly a fondamentalement changé cette équation. Il fournit une cible de compilation pour des langages comme C, C++ et Rust qui s'exécute dans le navigateur à une vitesse proche du natif. Et FFmpeg, le framework multimédia qui alimente aussi bien le backend de YouTube que votre éditeur vidéo préféré, a été compilé en WebAssembly sous la forme de FFmpeg.wasm.
J'ai passé les deux dernières années à travailler avec cette technologie pour créer Remove Audio, et j'ai appris énormément sur ce que le traitement vidéo dans le navigateur peut faire, et sur ce qu'il ne peut pas faire. Voici la réalité technique derrière le discours marketing.
"WebAssembly n'a pas seulement rendu possible le traitement vidéo dans le navigateur. Il l'a rendu pratique. L'écart de performance entre le natif et le wasm s'est réduit au point où, pour la plupart des tâches courantes, les utilisateurs ne voient plus la différence."
Qu'est-ce que WebAssembly, au juste ?
WebAssembly, souvent abrégé en wasm, est un format d'instructions binaire qui tourne dans une machine virtuelle à l'intérieur de votre navigateur. Pensez-y comme à une sorte d'assembleur standard que tous les navigateurs acceptent d'exécuter, quel que soit le matériel sous-jacent. Le processeur de votre ordinateur peut être en x86 ou en ARM, mais WebAssembly fournit une couche d'abstraction qui fonctionne sur les deux.
Les deux propriétés qui rendent WebAssembly utile pour la vidéo sont la performance et l'isolation. En termes de vitesse, le code wasm tourne à 80 à 95 % de la vitesse native dans la plupart des tâches. C'est énormément plus rapide que JavaScript pour des opérations lourdes comme le demuxing vidéo ou certaines opérations codec. L'isolation signifie que le code wasm ne peut pas accéder directement à votre système de fichiers, au réseau ou à d'autres onglets. Il ne peut travailler qu'avec les données qu'on lui donne explicitement.
Pour un outil axé sur la confidentialité comme Remove Audio, cette isolation compte autant que la performance. Même s'il y avait un bug dans FFmpeg.wasm, le code ne pourrait pas exfiltrer vos données vidéo, car le sandbox bloque tout accès réseau non autorisé. Votre vidéo entre dans le sandbox wasm, elle est traitée, puis elle en ressort. C'est tout le flux de données.
FFmpeg.wasm : une centrale multimédia dans le navigateur
FFmpeg est le framework multimédia open source qui forme l'épine dorsale du traitement audio et vidéo depuis plus de vingt ans. Il prend en charge pratiquement tous les codecs et tous les formats conteneurs existants. Des plateformes vidéo comme YouTube, des services de streaming et des logiciels de montage professionnels utilisent FFmpeg ou ses bibliothèques sous le capot.
FFmpeg.wasm est une compilation des bibliothèques principales de FFmpeg vers WebAssembly. Cela signifie que vous obtenez les capacités multimédia éprouvées de FFmpeg directement dans un onglet de navigateur. Quand vous utilisez Remove Audio, votre navigateur télécharge un module wasm compact — environ 30 Mo — qui contient le code FFmpeg nécessaire pour analyser, manipuler et générer des fichiers vidéo.
L'opération précise effectuée par Remove Audio est simple du point de vue de FFmpeg : le fichier d'entrée est lu, le flux vidéo est copié vers la sortie, et le flux audio est omis. Comme le flux vidéo est copié sans décodage ni réencodage, l'opération est rapide et sans perte. Les données vidéo restent inchangées. Seule la piste audio est supprimée.
Comment cela fonctionne, étape par étape
Quand vous chargez remove-audio.com, votre navigateur télécharge les ressources de la page ainsi que le module FFmpeg.wasm. Ce module est mis en cache après la première visite, ce qui rend les visites suivantes plus rapides.
Quand vous sélectionnez une vidéo, le navigateur la lit en mémoire via la File API. Les données du fichier restent dans la mémoire allouée du navigateur. Aucune requête réseau n'est faite. Tout le monde peut le vérifier avec les outils de développement : ouvrez l'onglet Réseau, ajoutez un fichier, et constatez qu'aucun téléversement n'apparaît.
Les données du fichier sont ensuite passées à l'instance FFmpeg.wasm, qui analyse le conteneur, identifie les flux vidéo et audio et exécute l'opération de multiplexage. Pour retirer l'audio, cela signifie écrire un nouveau conteneur qui ne contient que le flux vidéo, ainsi que d'éventuels flux de sous-titres ou de métadonnées. Le flux audio n'est tout simplement pas inclus dans la sortie.
Le fichier de sortie existe alors dans la mémoire du navigateur, techniquement dans le système de fichiers virtuel de l'instance wasm. Une fois le traitement terminé, l'outil crée un lien de téléchargement vers ce fichier en mémoire. En cliquant sur Télécharger, vous déclenchez le mécanisme natif de téléchargement du navigateur, qui enregistre le fichier sur votre appareil.
Après le téléchargement, la mémoire est libérée. Le fichier d'origine, la mémoire de travail de l'instance wasm et le fichier de sortie sont récupérés par le navigateur. Rien n'est conservé, sauf si vous avez explicitement enregistré le téléchargement.
Performance : à quoi s'attendre
Le traitement vidéo dans le navigateur est rapide, mais il a des caractéristiques différentes de celles d'un logiciel natif. Voici ce que j'ai observé sur des milliers d'utilisations réelles.
Pour la suppression audio en particulier — qui ne demande ni décodage ni réencodage de la vidéo — la performance est principalement limitée par les entrées/sorties de fichiers, c'est-à-dire la vitesse à laquelle le navigateur peut lire le fichier d'entrée et écrire le fichier de sortie. Un MP4 de 100 Mo se traite généralement en 2 à 5 secondes sur un ordinateur récent et en 5 à 15 secondes sur un téléphone.
Le temps de traitement évolue à peu près linéairement avec la taille du fichier. Un fichier de 500 Mo mettra environ cinq fois plus longtemps qu'un fichier de 100 Mo. Le goulot d'étranglement est donc le débit des données, pas la puissance de calcul.
Là où le navigateur devient plus lent, c'est pour les opérations qui nécessitent un décodage et un réencodage, comme la conversion de format, le transcodage ou l'application de filtres. Ce sont des tâches intensives, et l'écart de 5 à 20 % entre wasm et natif devient perceptible. Pour la suppression audio, cet écart est pratiquement sans importance puisque nous évitons totalement le réencodage.
Les limites, honnêtement
Je veux être franc sur ce que le traitement dans le navigateur ne fait pas bien, parce que je pense qu'être honnête sur les limites crée davantage de confiance que de faire semblant qu'elles n'existent pas.
La mémoire est la plus grosse contrainte. Les navigateurs limitent la mémoire disponible pour un onglet, et cette limite est plus faible sur mobile. Un téléphone avec 4 Go de RAM n'accordera peut-être qu'1 à 2 Go à un onglet de navigateur, et l'outil doit garder en mémoire à la fois le fichier d'entrée et le fichier de sortie. En pratique, cela limite la taille maximale des fichiers à environ la moitié de la mémoire disponible pour l'onglet.
Le traitement en arrière-plan n'est pas pris en charge. Si vous fermez l'onglet ou quittez la page, le traitement s'arrête. Les applications natives peuvent tourner en arrière-plan, mais les outils navigateur dépendent du fait que l'onglet reste ouvert et actif.
Tous les codecs ne sont pas inclus dans le build wasm. Pour garder un poids de téléchargement raisonnable — environ 30 Mo — FFmpeg.wasm inclut les codecs les plus courants, mais pas tous les formats exotiques. Les fichiers qui utilisent des codecs inhabituels peuvent donc échouer.
Le support du multithreading en wasm continue d'évoluer. Certains navigateurs supportent SharedArrayBuffer, ce qui permet le wasm multithread, tandis que d'autres le restreignent pour des raisons de sécurité. Résultat : certaines opérations s'exécutent sur un seul thread dans certains navigateurs, ce qui peut les ralentir.
"Je préfère construire un outil honnête sur ses limites plutôt qu'un outil qui promet l'impossible. Le traitement dans le navigateur est réellement puissant, et réellement contraint. Les deux sont vrais en même temps."
Où va le traitement dans le navigateur
La plateforme web continue d'évoluer de manière à rendre le traitement multimédia dans le navigateur toujours plus capable. L'API WebCodecs donne un accès direct aux encodeurs et décodeurs vidéo matériels, ce qui évite de dépendre uniquement d'implémentations codec en wasm. L'API File System Access permet de lire et écrire des fichiers sans devoir les charger entièrement en mémoire. Les Web Workers permettent un traitement en arrière-plan dans des threads séparés.
Je m'attends à ce que, dans quelques années, les outils vidéo dans le navigateur soient fonctionnellement équivalents à de petites applications natives pour la plupart des tâches courantes. L'écart se réduit à chaque version de navigateur, et les avantages de confidentialité du traitement local attirent de plus en plus de développeurs.
Pour les développeurs intéressés par la création d'outils similaires, l'écosystème est plus mûr qu'on pourrait le croire. FFmpeg.wasm dispose d'une documentation solide et d'une communauté active. Les chaînes de compilation pour C et Rust vers wasm sont bien établies. Et la demande pour des outils respectueux de la confidentialité qui traitent les données localement est en hausse. C'est un très bon moment pour explorer cet espace.
Votre navigateur est plus puissant que vous ne le pensez
WebAssembly a discrètement transformé ce qu'il est possible de faire dans un onglet de navigateur. Des opérations qui exigeaient auparavant un logiciel natif ou un upload serveur peuvent aujourd'hui se faire localement, de façon privée, avec un niveau de performance tout à fait utilisable dans la vraie vie.
Remove Audio n'est qu'un exemple de ce que cette technologie permet. Un outil vidéo qui ne demande ni installation, ni compte, ni upload vers un serveur, et qui vous donne malgré tout le résultat voulu en quelques secondes. La pile technique est fascinante, mais ce qui compte pour l'utilisateur, c'est l'expérience : déposer un fichier, obtenir un résultat, et savoir que votre vidéo n'a jamais quitté votre appareil.
Si la technologie vous intrigue ou si vous voulez la tester vous-même, essayez de traiter une vidéo sur remove-audio.com. Ouvrez l'onglet Réseau dans les outils de développement du navigateur. Vous verrez la page se charger, puis plus rien. Aucun upload. Aucune requête vers un serveur. Juste votre navigateur qui fait le travail localement. Voilà WebAssembly à l'œuvre.