Hoe browsergebaseerde videoverwerking werkt met WebAssembly

Vijf jaar geleden zou je heel wat sceptische blikken hebben gekregen als je een developer vertelde dat een browser FFmpeg kon draaien en videobestanden lokaal kon verwerken. JavaScript werd als te traag beschouwd voor rekenintensieve taken zoals multimediaverwerking. De browser was bedoeld voor het weergeven van webpagina's, niet voor het draaien van tools die traditioneel native gecompileerde binaries vereisten.

WebAssembly veranderde die vergelijking fundamenteel. Het biedt een compilatiedoel voor talen als C, C++ en Rust dat in de browser draait op bijna native snelheid. En FFmpeg, het multimediaframework dat alles aandrijft van de backend van YouTube tot je favoriete video-editor, is gecompileerd naar WebAssembly als FFmpeg.wasm.

Ik heb de afgelopen twee jaar met deze technologie gewerkt om Remove Audio te bouwen, en ik heb veel geleerd over wat browsergebaseerde videoverwerking wel en niet kan. Hier is de technische realiteit achter de marketing.

"

"WebAssembly heeft browsergebaseerde videoverwerking niet alleen mogelijk gemaakt. Het heeft het praktisch gemaakt. Het prestatieverschil tussen native en wasm is verkleind tot het punt waarop gebruikers het verschil niet merken voor de meeste gangbare taken."

WebAssembly (vaak afgekort als wasm) is een binair instructieformaat dat draait in een virtuele machine in je browser. Zie het als een standaard assembleertaal die elke browser afspreekt uit te voeren, ongeacht de onderliggende hardware. De CPU van je computer is x86 of ARM, maar WebAssembly biedt een abstractielaag die op beide werkt.

De belangrijkste eigenschappen die WebAssembly nuttig maken voor videoverwerking zijn prestaties en sandboxing. Qua prestaties draait wasm-code op 80 tot 95 procent van native snelheid voor de meeste taken. Dat is dramatisch sneller dan JavaScript voor rekenintensief werk zoals video-demuxing en codecbewerkingen. De sandboxing betekent dat wasm-code niet direct bij je bestandssysteem, netwerk of andere browsertabbladen kan. Het kan alleen werken met gegevens die er expliciet aan worden doorgegeven.

Voor een privacy-gerichte tool als Remove Audio is de sandboxing net zo belangrijk als de prestaties. Zelfs als er een bug zou zitten in de FFmpeg.wasm-code, zou die je videogegevens niet kunnen lekken omdat de sandbox ongeautoriseerde netwerktoegang voorkomt. Je video gaat de wasm-sandbox in, wordt verwerkt en komt er weer uit. Dat is de enige gegevensstroom.

FFmpeg is het open-source multimediaframework dat al meer dan twee decennia de ruggengraat vormt van audio- en videoverwerking. Het ondersteunt in wezen elke codec en elk containerformaat dat bestaat. Videoplatforms zoals YouTube, streamingdiensten en professionele bewerkingssoftware gebruiken allemaal FFmpeg of de bibliotheken ervan onder de motorkap.

FFmpeg.wasm is een compilatie van de kernbibliotheken van FFmpeg naar WebAssembly. Dit betekent dat je de beproefde multimediamogelijkheden van FFmpeg krijgt die in een browsertabblad draaien. Wanneer je Remove Audio gebruikt, downloadt je browser een compact wasm-module (ongeveer 30 megabyte) dat de FFmpeg-code bevat die nodig is om videobestanden te parsen, bewerken en uit te voeren.

De specifieke bewerking die Remove Audio uitvoert is in FFmpeg-termen eenvoudig: het leest het invoerbestand, kopieert de videostream naar de uitvoer en laat de audiostream weg. Omdat het de videostream kopieert zonder te decoderen en hercoderen, is de bewerking snel en lossless. De videogegevens gaan ongewijzigd door. Alleen de audiotrack wordt weggelaten.

Wanneer je remove-audio.com laadt, downloadt je browser de pagina-assets en de FFmpeg.wasm-module. De wasm-module wordt na het eerste bezoek gecached, dus volgende bezoeken laden sneller.

Wanneer je een videobestand selecteert, leest de browser het in het geheugen met de File API. De bestandsgegevens blijven in het toegewezen geheugen van je browser. Er wordt geen netwerkverzoek gedaan. Dit is controleerbaar door iedereen met de ontwikkelaarstools van de browser: open het tabblad Netwerk, upload een bestand en zie dat er geen uploadverzoek plaatsvindt.

De bestandsgegevens worden vervolgens doorgegeven aan de FFmpeg.wasm-instantie, die de container parseert, de video- en audiostreams identificeert en de muxingbewerking uitvoert. Voor audioverwijdering betekent dit het schrijven van een nieuwe container die alleen de videostream bevat (en eventuele ondertitel- of metadatastreams). De audiostream wordt simpelweg niet in de uitvoer opgenomen.

Het uitvoerbestand bestaat in het geheugen van de browser (technisch gezien in het virtuele bestandssysteem van de wasm-instantie). Wanneer de verwerking klaar is, maakt de tool een downloadlink die naar dit in-memory bestand wijst. Klikken op download activeert het native downloadmechanisme van de browser, waardoor het bestand op je apparaat wordt opgeslagen.

Na de download wordt het geheugen vrijgegeven. Het originele bestand, het werkgeheugen van de wasm-instantie en het uitvoerbestand worden allemaal door de browser ge-garbage-collect. Er blijft niets bewaard tenzij je de download hebt opgeslagen.

Browsergebaseerde videoverwerking is snel, maar heeft andere prestatiekenmerken dan native software. Hier is wat ik heb gemeten over duizenden real-world gebruiken.

Voor audioverwijdering specifiek (wat geen decodering of hercodering van video vereist) worden prestaties primair beperkt door de I/O-snelheid van bestanden, oftewel hoe snel de browser het invoerbestand kan lezen en het uitvoerbestand kan schrijven. Een MP4 van 100 megabyte wordt doorgaans in 2 tot 5 seconden verwerkt op een moderne desktop en 5 tot 15 seconden op een telefoon.

De bewerking schaalt ruwweg lineair met bestandsgrootte. Een bestand van 500 megabyte duurt ongeveer 5 keer langer dan een bestand van 100 megabyte. Dit komt doordat de bottleneck de gegevensdoorvoer is, niet de berekening.

Waar browsergebaseerde verwerking trager wordt, is bij bewerkingen die decodering en hercodering vereisen, zoals formaatconversie, transcodering of het toepassen van filters. Deze taken zijn rekenintensief en het prestatieverschil van 5 tot 20 procent tussen wasm en native code wordt merkbaar. Voor audioverwijdering is dit verschil irrelevant omdat we hercodering volledig vermijden.

Ik wil eerlijk zijn over wat browsergebaseerde verwerking niet goed kan, omdat ik denk dat eerlijkheid over beperkingen meer vertrouwen opbouwt dan doen alsof ze niet bestaan.

Geheugen is de grootste beperking. Browsers beperken het beschikbare geheugen voor elk tabblad, en deze limiet is lager op mobiele apparaten. Een telefoon met 4 gigabyte RAM kan slechts 1 tot 2 gigabyte toewijzen aan een browsertabblad, en de tool moet zowel het invoer- als het uitvoerbestand tegelijkertijd in het geheugen houden. Dit beperkt de maximale bestandsgrootte effectief tot ruwweg de helft van het beschikbare tabbladgeheugen.

Achtergrondverwerking wordt niet ondersteund. Als je het tabblad sluit of wegnavigieert, stopt de verwerking. Native apps kunnen op de achtergrond draaien, maar browsergebaseerde tools zijn afhankelijk van het tabblad dat open en actief blijft.

Sommige codecs zijn niet opgenomen in de wasm-build. Om de downloadgrootte beheersbaar te houden (ongeveer 30 megabyte) bevat de FFmpeg.wasm-build de meest gangbare codecs maar niet elk obscuur formaat. Bestanden met ongewone codecs kunnen mislukken bij verwerking.

Multi-threading ondersteuning in wasm is nog in ontwikkeling. Hoewel sommige browsers SharedArrayBuffer ondersteunen (wat multi-threaded wasm mogelijk maakt), beperken anderen het om veiligheidsredenen. Dit betekent dat sommige bewerkingen single-threaded draaien in bepaalde browsers, wat langzamer kan zijn.

"

"Ik bouw liever een tool die eerlijk is over zijn beperkingen dan een die het onmogelijke belooft. Browsergebaseerde verwerking is oprecht krachtig, en oprecht beperkt. Beide dingen zijn waar."

Het webplatform blijft evolueren op manieren die browsergebaseerde mediaverwerking capabeler maken. De WebCodecs API biedt directe toegang tot hardware video-decoders en -encoders, waardoor wasm-gebaseerde codec-implementaties niet meer nodig zijn. De File System Access API maakt het lezen en schrijven van bestanden mogelijk zonder ze volledig in het geheugen te laden. De Web Workers API staat achtergrondverwerking toe in aparte threads.

Ik verwacht dat browsergebaseerde videotools binnen een paar jaar functioneel gelijkwaardig zullen zijn aan lichte native apps voor de meeste gangbare taken. Het verschil verkleint met elke browserrelease, en de privacyvoordelen van lokale verwerking stimuleren de interesse van developers.

Voor developers die geinteresseerd zijn in het bouwen van vergelijkbare tools is het ecosysteem volwassener dan je misschien verwacht. FFmpeg.wasm heeft goede documentatie en een actieve community. De toolchain voor het compileren van C en Rust naar wasm is goed gevestigd. En de vraag naar privacyrespecterende tools die gegevens lokaal verwerken groeit. Het is een goed moment om deze ruimte te verkennen.

WebAssembly heeft in stilte getransformeerd wat mogelijk is in een browsertabblad. Bewerkingen die vroeger native software of serveruploads vereisten, kunnen nu lokaal, privé en op prestatieniveaus plaatsvinden die oprecht praktisch zijn voor real-world gebruik.

Remove Audio is een voorbeeld van wat deze technologie mogelijk maakt. Een videoverwerkingstool die geen installatie vereist, geen account aanmaakt, geen serverupload doet en toch het resultaat levert dat je nodig hebt in seconden. De technische stack is fascinerend, maar wat voor gebruikers telt is de ervaring: sleep een bestand, krijg een resultaat en weet dat je video je apparaat nooit heeft verlaten.

Als je nieuwsgierig bent naar de technologie of het zelf wilt testen, probeer dan een video te verwerken op remove-audio.com. Bekijk het tabblad Netwerk in de ontwikkelaarstools van je browser. Je zult de paginalading zien, en dan niets. Geen upload. Geen serververzoek. Gewoon je browser die lokaal het werk doet. Dat is WebAssembly in actie.