DEV Community: mengyuxuan

WebCodecs is 10x faster than ffmpeg.wasm — and sometimes worse

mengyuxuan — Tue, 15 Sep 2026 06:49:50 +0000

WebCodecs is 7.5–10.1× faster than ffmpeg.wasm. That's the headline, and it's the least interesting thing we measured.

In the same benchmark, at identical settings, ffmpeg.wasm produced a smaller file — 10.23 MB against WebCodecs' 11.20 MB. Not noise, not a bug.

And there's a 5× performance spread hiding inside WebCodecs itself that no feature detection will tell you about.

A while back I wrote up three things that broke when I moved video compression into the browser — the AVI remux that produced a 1151-byte file, the AAC priming delay that permanently defeats mediabunny's copy path, and why the multithreaded ffmpeg core costs you your ad revenue. That post was about the failures. This one is about the numbers.

The comparison is usually posed wrong

Two mechanisms compress video in a browser without uploading it. ffmpeg.wasm is FFmpeg compiled to WebAssembly — the whole toolchain running as a program in the tab. WebCodecs is a browser API that hands JavaScript the platform's own encoder, usually the same hardware block your phone uses to record video.

Written up as a versus, the answer is always some variation of "WebCodecs if you can, ffmpeg.wasm if you must."

That's true, and it's not very useful. It describes a decision made once, at the top of a project. The decision that actually matters is made per file — and the two engines are not the only options on that decision.

The measurements

Same clip, same settings, compressed twice through the production UI.

The ffmpeg run is not a debug mode. The harness deletes window.VideoEncoder and window.VideoDecoder before any page script runs, so the engine selector takes the fallback branch exactly as it would in a browser that never shipped the API.

Both runs start from a cold browser context, so the ffmpeg figures include fetching its WebAssembly core — a real visitor pays for that too.

Clip	Source	WebCodecs	ffmpeg.wasm	Slower by	Output (WC / ff)
5 s, 1080p	5.2 MB	1.3 s	9.8 s	7.5×	3.24 / 3.33 MB
15 s, 1080p	15.6 MB	2.8 s	28.4 s	10.1×	9.72 / 9.83 MB
30 s, 720p	15.9 MB	2.8 s	27.4 s	9.8×	11.20 / 10.23 MB

Apple M3, 16 GB, Chromium 145, macOS.

The gap grows with duration. Fetching and instantiating the wasm core is a fixed cost, so on a five-second clip it's a large share of the ten seconds. By fifteen seconds it's been amortised — and the ratio still gets worse, not better. That's the encoder itself, not the startup.

The last row is the interesting one. ffmpeg produced a smaller file on identical settings. libx264 is running CRF with a bitrate ceiling, so it spends what each scene needs and banks the rest. The WebCodecs encoder is given an average bitrate and hits it. On footage with large easy regions, CRF wins that trade comfortably.

So the honest summary isn't "WebCodecs is better." It's:

WebCodecs is much faster and usually close enough on size, and on some content it gives up a real amount of it.

The 5× spread hiding inside WebCodecs

This is the part I'd most like other people to check.

Our router has to guess how long a re-encode will take before committing to one, so it carries a throughput figure in megapixels of source video per second:

Encoder	Mpx/s
WebCodecs, hardware AVC (Apple M-series)	305
WebCodecs, software fallback (no hardware AVC)	60
What the router actually assumes for WebCodecs	150
ffmpeg.wasm, single-threaded libx264	15

A hardware AVC encoder on an M-series measured 305. The same API on a machine with no hardware AVC — falling back to a software encoder behind the same interface — lands near 60.

That's a 5× spread inside what the code calls "WebCodecs," and nothing in the API tells you which one you got.

VideoEncoder.isConfigSupported() will happily tell you the config is supported. It will not tell you whether it's supported by silicon or by a software path that's five times slower. You can measure it at runtime — but only by encoding something first, which is the thing you were trying to decide about.

So the shipped figure is 150. Deliberately between them, and deliberately not the number either machine produces:

const ENCODE_MEGAPIXELS_PER_SEC = { webcodecs: 150, ffmpegWasm: 15 } as const;

Over-estimating the machine costs the user a wait they didn't agree to. Under-estimating it costs them compression they wanted. Splitting the difference isn't indecision — it's the only position where both errors stay small.

(ffmpeg.wasm gets 15 because we're on the single-threaded core. That's a revenue decision, not an oversight — explained in the earlier post.)

Four routes, not three

The earlier post described three paths. Shipping it properly turned out to need four — and the two that are neither engine are where a surprising share of the wins live.

Route	What runs	When
Passthrough	Copy encoded samples into a new container. No decode, no encode.	Already meets target, is H.264 + AAC, and re-encoding would take >20 s
WebCodecs transcode	Decode + re-encode via the browser's codec API	Browser exposes WebCodecs, can read the container, can encode the target
Remux first, then transcode	Losslessly rewrap to Matroska with ffmpeg.wasm, then hand to WebCodecs	WebCodecs can't read the container (AVI, FLV, WMV) but can decode the codec inside
ffmpeg.wasm	Full libx264 encode in wasm	Nothing above applies

The engine decision itself is trivial:

export function decideEngine(caps: EngineCaps): CompressionEngine {
  return caps.hasWebCodecsApi && caps.inputReadable && caps.canEncodeTarget
    ? "webcodecs"
    : "ffmpeg";
}

All the interesting work is in deciding whether to encode at all, and in making an unreadable container readable.

Passthrough: the threshold is on the wrong axis if you use bitrate

Copying encoded samples buys exactly one thing: time. It can't win on size, because the encoder is separately instructed to spend at most the source's own bitrate — so a re-encode is essentially always smaller than a copy.

On a five-second clip, skipping the encode saved 0.8 seconds and forfeited about 19% of the file. Nobody asked for that trade.

On a ten-minute file the same skip saves minutes.

So the rule isn't about bitrate at all. It's about the wait:

export const PASSTHROUGH_MIN_TRANSCODE_SECONDS = 20;

A threshold on the wrong axis would have been easy to ship and hard to notice.

One trap while you're in there:

A source's audio codec being unknown is not the same as it having no audio.

The two want opposite handling — an unidentified track is precisely the kind you must not copy blind. Collapse both into a null check and you get silent audio in an output that otherwise looks fine.

What remux-first costs in memory

Rewrapping an unreadable container so the fast encoder can take the job is the single best trick in the pipeline. Getting it to work at all was its own adventure. What I didn't appreciate until later is what it costs.

The Matroska output is built in the wasm heap → copied out to a Uint8Array → copied again into a File → and then mediabunny accumulates the whole MP4 output in a buffer on top of that.

Four resident near-source-sized copies, against the plain transcode's zero — that path mounts the input through the filesystem shim, and its output is smaller than its input.

So the fast path has a ceiling: 256 MiB of source on the 8 GB that nearly every desktop Chrome reports. Above it we simply transcode with ffmpeg, exactly as before remux-first existed.

An optimisation that declines to apply is fine. An out-of-memory crash on a file that used to work is not.

And if you budget against that number, know this:

navigator.deviceMemory caps its reported value at 8. A 64 GB workstation and an 8 GB laptop are indistinguishable through that API. Budgets keyed to it are keyed to a number that stops rising.

The second bug that only a real browser found

Last time it was an AVI that came out as 1151 bytes — loud, obvious once you looked. This one was the opposite, and I think it's the more instructive shape.

There's a harness that drives a corpus of real files through the full pipeline in an actual Chromium, pulls the output back out, inspects it with ffprobe, and observes which route each file took by stubbing the analytics sink the page already calls.

It earned its keep on a regression that both code review and unit tests missed.

The ffmpeg probe parses ffmpeg's own log output to learn what streams a file contains. It had begun reading ffmpeg's description of its own output stream as though it were an input stream.

Nothing threw. Nothing failed a test.

AVI, FLV and WMV silently stopped qualifying for the remux-first fast path and quietly fell back to a full wasm transcode — the failure mode being that everything still worked, just several times slower, on exactly the formats the optimisation existed for.

That's the shape of bug that survives code review indefinitely. No exception, no red test, no error rate. Just a fast path that stopped being taken.

If you're building this

Use WebCodecs when you can. The speed difference isn't marginal and it grows with file length.

But budget for the fallback properly, rather than treating it as a rare edge. Containers WebCodecs can't parse, codecs it can't decode (AudioDecoder has no AC-3, MP2 or WMA), and browsers that don't ship it are collectively common enough that the fallback is a feature, not a safety net.

Spend the effort on routing rather than on picking a winner. The two paths that are neither engine are where a meaningful share of the wins are, and neither shows up if you've framed the problem as a choice between two encoders.

And test in a browser. Both bugs — the loud one and the silent one — were found by running real files through real Chromium and inspecting what came out. Neither broke a unit test.

Measurements from VideoCompress, a browser-based video compressor — the files never leave the tab, which is why all of this had to work client-side in the first place.

Three things that surprised me shipping a 200-line npm package

mengyuxuan — Mon, 07 Sep 2026 01:14:20 +0000

I published a small thing last week — video-bitrate-calculator, a zero-dependency library that works out what video bitrate fits under a target file size. About 200 lines of arithmetic.

The code was the easy part. Shipping it surfaced three failures that all had the same shape: the tool told me something, the something was misleading, and the correct response was the opposite of the obvious one.

1. npm said my bin was "invalid and removed". It was neither.

npm publish, and this scrolls past:

npm warn publish "bin[video-bitrate-calculator]" script name src/cli.js was invalid and removed
npm warn publish "bin[vbc]" script name src/cli.js was invalid and removed

Both CLI entry points, gone. That's the headline feature of the package — npx video-bitrate-calculator discord 90s is the first line of the README. I hit Ctrl+C.

My package.json had:

"bin": {
  "video-bitrate-calculator": "./src/cli.js",
  "vbc": "./src/cli.js"
}

Nothing wrong with that. ./ prefixes are normal. So I went and read npm's own normalizer, @npmcli/package-json/lib/normalize.js:

const binTarget = secureAndUnixifyPath(pkg.bin[binKey])   // "./src/cli.js" → "src/cli.js"

if (binTarget !== pkg.bin[binKey]) {
  changes?.push(`"bin[${base}]" script name ${binTarget} was invalid and removed`)
}
pkg.bin[base] = binTarget     // ← assigned anyway

The assignment runs unconditionally. The warning fires whenever the path is normalized, and describes a deletion that never happens. Stripping a leading ./ is enough to trigger it.

I confirmed it by running npm's own normalizer over my package:

bin after normalize: {"video-bitrate-calculator":"src/cli.js","vbc":"src/cli.js"}

Both entries alive. The publish would have been fine.

The fix is to write the normalized form yourself — "src/cli.js", no ./ — so the warning never appears. Not because the warning was right, but because nobody should have to read npm's source to dismiss it.

The lesson isn't "ignore npm warnings". It's that a warning claiming destructive behaviour deserves 60 seconds of verification before you trust or dismiss it. I nearly published without checking; I also nearly rewrote half my package layout to appease something that wasn't broken.

2. My tests silently didn't run on two Node versions

I used Node's built-in test runner, no framework:

"scripts": {
  "test": "node --test \"test/*.test.js\""
}

Green locally. First CI run, Node 22 passed and Node 18 and 20 failed:

Could not find '/home/runner/work/.../test/*.test.js'

The quotes are the bug. They stop the shell from expanding the glob, so Node receives the literal string test/*.test.js. Newer Node expands that itself. Node 18 and 20 don't — they look for a file with an asterisk in its name, find nothing, and exit.

What makes this worth writing down is the failure mode one Node version over. On Node 22+, the runner expands the pattern itself — and a pattern that matches nothing is not an error. node --test "test/*.test.js" in a tree where that matches zero files prints tests 0 and exits 0. Green CI, no coverage, no signal. Node 18 and 20 were doing me a favour by failing loudly.

The fix was not better quoting:

"scripts": { "test": "node --test" }

Bare node --test discovers the test directory itself, consistently, on every version that still gets security patches. I also dropped Node 18 from the matrix — it went EOL in April 2025, and keeping it was buying compatibility debt with no user attached to it.

Never let your test command's meaning depend on which shell expands it. Hand the discovery to the runner.

3. A registry mirror redirected my publish, quietly

npm login opened a signup page for a registry I'd never heard of, showing:

Public registration is not allowed

My ~/.npmrc, set up years ago for faster installs in China:

registry=https://registry.npmmirror.com

That mirror is read-only. Installs work beautifully. Publishing silently goes to a host that will never accept it — and the failure surfaces as a confusing signup wall, not as "you cannot publish here".

The --registry flag fixes the immediate problem, but it fixes it on my machine, for this invocation. The durable fix belongs in the package:

"publishConfig": {
  "registry": "https://registry.npmjs.org",
  "access": "public"
}

The publish destination is a property of the package, not of whoever runs the command. With that in place, a contributor behind any mirror — or CI with an inherited .npmrc — publishes to the right place without knowing this trap exists. If you maintain a public package and haven't set publishConfig, you're relying on every future publisher having a clean config.

The pattern

All three were the same mistake in different clothes: I read a message instead of verifying a state.

npm said "removed" → I should have checked whether bin was actually gone. It wasn't.
CI said "passed" on one version → I should have checked whether tests ran on the others. They didn't.
npm login showed a signup page → I should have checked which registry I was talking to. Not the one I thought.

Each check took under a minute. Each message, taken at face value, pointed the wrong way — one toward unnecessary work, one toward false confidence, one toward confusion.

The tooling is not lying to you. It is describing its own internals in language that sounds like it's describing yours.

The package that surfaced all this: video-bitrate-calculator — size = bitrate × duration, plus the safety margins that stop your file from missing a hard upload limit by 40 KB. Zero dependencies, MIT.

It came out of videocompress.dev, a video compressor that runs entirely in the browser. Same arithmetic, extracted and made standalone.

Three things that broke when I moved video compression into the browser

mengyuxuan — Wed, 19 Aug 2026 02:41:10 +0000

I run a video compressor that works entirely in the browser.
No upload, no server, nothing leaves the machine. Two of the three bugs below
only showed up when I stopped reading code and started timing things, so I want
to write them down while the numbers are still in front of me.

The pipeline has three paths. If the file already meets the target, copy the
encoded samples and encode nothing. If the browser can decode the container,
transcode with WebCodecs. Otherwise fall back to ffmpeg.wasm, which is roughly
an order of magnitude slower. mediabunny handles the demux and remux.

AVI to Matroska with -c copy produces a 1151 byte file

The fast path needs mediabunny to be able to read the container. It cannot read
AVI, but plenty of AVI files carry H.264 inside, so the plan was to rewrap
losslessly and stay on the fast path:

ffmpeg -i in.avi -map 0:v:0 -map 0:a? -c copy \
       -avoid_negative_ts make_zero out.mkv

That fails. Not slowly, not subtly:

[matroska] Timestamps are unset in a packet for stream 0
[matroska] Can't write packet with unknown timestamp
[out#0/matroska] Error muxing a packet

AVI has no per-packet timestamps. It stores a fixed frame rate plus an index and
lets the demuxer work them out. Matroska requires timestamps on every block, so
the copy has nothing to write. What comes out is a 1151 byte header with zero
clusters, which is a valid Matroska file containing no media.

-avoid_negative_ts does not help, and it took me longer than it should have to
see why: the timestamps are not negative, they are absent. Two different
problems that produce similar looking errors.

The fix is one flag on the input side:

ffmpeg -fflags +genpts -i in.avi -map 0:v:0 -map 0:a? -c copy \
       -avoid_negative_ts make_zero out.mkv

+genpts synthesises presentation timestamps from the stream's frame rate.
Output went from 1151 bytes to 55.8 MB on a 20 second 1080p30 clip, all 600
frames decoding cleanly.

Then I measured it against a control. Same geometry, same duration, same target,
but Xvid instead of H.264 so it takes the ffmpeg path:

H.264 AVI, rewrap then WebCodecs   7.5 s    53.3 MB to 12.3 MB
Xvid AVI, ffmpeg.wasm             53.4 s    48.2 MB to 12.5 MB

Output sizes within 2 percent, wall clock 7x apart. Both numbers come from
headless Chromium with software encoding, so a real machine with a hardware
encoder should do better than this.

One more thing worth doing: ffmpeg.wasm resolves with the exit code instead of
rejecting, and a muxer that dies mid run still leaves a readable file behind. A
truncated remux looks exactly like a complete one unless you check.

Every AAC track defeats mediabunny's copy path, by design

The passthrough case is supposed to touch nothing. Give mediabunny an empty
video config and it copies encoded samples straight through, since
forceTranscode defaults to false.

It worked for video and not for audio. A 3.3 MB source came back at 3.6 MB, so
I parsed the output boxes:

source   moov 33,948   mdat 3,432,287
output   moov 17,879   mdat 3,788,908

The moov got smaller. The growth was all in mdat. Per track:

avc1   900 samples   3,071,520 bytes
mp4a  1295 samples     717,380 bytes

Video was byte identical to the source. Audio was double: 717 KB against the
source's 360 KB, about 191 kbps from a 96 kbps original.

The reason is in mediabunny's copy conditions. The fast path requires, among
other things, !needsTrimming, where needsTrimming is
firstTimestamp < startTimestamp. I asked the library what it saw:

video codec: avc   firstTimestamp: 0
audio codec: aac   firstTimestamp: -0.023219954648526078

Negative. And 0.0232 seconds at 44100 Hz is 1024 samples, which is exactly one
AAC frame. That is encoder priming delay, and every AAC track produced by any
normal encoder has it. So the audio copy path is not occasionally unavailable,
it is never available.

You cannot fix this from the outside. Passing a bitrate to keep the size down
forces a transcode by itself, because !trackOptions.bitrate is one of the
copy conditions. Passing nothing lets the library re-encode at its own default.

I went with a floor instead: if a passthrough would return more bytes than it
received, and the source is already MP4, hand back the source untouched.
Verified byte exact, 3,466,275 in and 3,466,275 out where it used to be
3,806,815. For a file that was already close to optimal, "nothing needed doing"
is a more honest answer than a 10 percent larger file.

The multithreaded ffmpeg core costs you your ad revenue

@ffmpeg/core-mt is 4 to 8 times faster than the single threaded core. It needs
SharedArrayBuffer, which needs cross origin isolation, which means sending
COOP and COEP headers.

COEP: require-corp breaks third party embeds that do not opt in. On a site
funded by AdSense that is not a technical tradeoff, it is a revenue decision.
I stayed single threaded and put the effort into not reaching for ffmpeg at all,
which is what the rewrap path above is for.

What I would take away from this

Both real bugs were invisible to code review and to unit tests. The AVI failure
had a passing test suite and a plausible looking implementation sitting on top
of it. What found it was dragging an actual AVI file into an actual browser and
noticing that a 54 MB input had produced 1151 bytes.

If you want to try it on something awkward, the two cases I get asked about most
have their own pages: compress video for Discord
if you are fighting the 10 MB free tier limit, and
compress video to 10 MB if the
cap is the whole problem. Both run on your own machine.

I built a video compressor with zero backend — your files never leave the tab

mengyuxuan — Wed, 22 Jul 2026 08:07:50 +0000

Drop a 200 MB screen recording into most "free video compressor" sites and here's what actually happens: the file uploads to someone's server, gets transcoded there, and you download the result. Your video sat on a stranger's disk. The site paid for bandwidth and CPU, so it pays that back with aggressive ads or a paywall at 3 files a day.

I wanted the opposite: the compression runs in your browser tab, the file never leaves your machine, and because there's no server doing the work, the whole thing is genuinely free to run.

That's videocompress.dev. This post is how it works under the hood.

The core constraint: no upload, ever

The entire architecture falls out of one rule — the video bytes stay client-side. That immediately kills the "rent a beefy transcoding server" design and forces the work into the browser. Two APIs can do it:

WebCodecs — a low-level browser API that talks to the OS's hardware video encoder/decoder. Fast, uses almost no CPU, native-quality H.264.
ffmpeg.wasm — the full FFmpeg compiled to WebAssembly. Works literally everywhere, but it's a software encoder running in a WASM sandbox, so it's slower.

WebCodecs is the better experience when it's available. It isn't always. So the app probes the browser and picks.

Picking an engine at runtime

The selection logic is deliberately boring — a pure function that's trivial to unit test:

export type CompressionEngine = "webcodecs" | "ffmpeg";

export interface EngineCaps {
  hasWebCodecsApi: boolean;   // VideoEncoder + VideoDecoder exist
  inputReadable: boolean;     // we can actually demux + decode this file
  canEncodeTarget: boolean;   // the target H.264 config is encodable here
}

export function decideEngine(caps: EngineCaps): CompressionEngine {
  return caps.hasWebCodecsApi && caps.inputReadable && caps.canEncodeTarget
    ? "webcodecs"
    : "ffmpeg";
}

The important detail is the third capability. Having the WebCodecs API isn't enough — the browser also has to be able to demux the specific container you dropped in and encode the target config. So before committing, the app asks mediabunny whether it can read the input's primary video track and whether VideoEncoder.isConfigSupported() accepts the output config.

Any false, anything unprobed, anything that throws → fall back to ffmpeg.wasm. WebCodecs is the fast path you earn by passing every check; ffmpeg is the floor that always catches you. Users on the happy path get hardware speed; everyone else still gets a working compressor. Nobody gets a broken page.

The actual "compression": it's bitrate math

"Compress this to 25 MB for email" sounds like a quality knob, but under the hood it's arithmetic. A video file's size is roughly bitrate × duration. If you know the target size and the duration, you can solve for the bitrate:

export const AUDIO_KBPS = 128;
export const TARGET_SIZE_SAFETY = 0.94; // aim slightly under so we don't overshoot

export function computeTargetVideoKbps({
  targetSizeMB,
  durationSec,
  removeAudio,
}: {
  targetSizeMB: number;
  durationSec: number;
  removeAudio: boolean;
}): number {
  const audioKbps = removeAudio ? 0 : AUDIO_KBPS;
  const safeTargetMB = targetSizeMB * TARGET_SIZE_SAFETY;
  const videoKbps = (safeTargetMB * 8192) / Math.max(durationSec, 1) - audioKbps;
  return Math.max(Math.round(videoKbps), 100);
}

Two things I learned the hard way and baked in:

The 6% safety margin (0.94). Encoders don't hit a bitrate target exactly; they hover around it. If you aim for exactly 25 MB you'll ship 26 and blow the email limit. Aiming for ~23.5 lands under it reliably.
Subtract the audio budget first. The size cap is for the whole file. Spend 128 kbps on audio and the video has to fit in what's left — otherwise your "target size" mode quietly ignores the audio track and overshoots.

The other mode is quality-based, which maps straight to H.264's CRF (constant rate factor):

const QUALITY_CRF = { high: 20, balanced: 23, small: 28 };

Lower CRF = better quality + bigger file. 23 is a genuinely good default for most footage; 28 is where you go when "smaller" matters more than "pristine."

Why "no server" changes the whole economics

This is the part I think other devs will appreciate. Because the transcode happens in the tab:

Hosting is basically free. The app is 100% static — it's just HTML, JS, and a WASM blob on a CDN. No transcoding boxes, no per-video cost, no scaling worries. A traffic spike costs bandwidth on static assets, nothing more.
Privacy is architectural, not a promise. Plenty of sites say "we delete your files." Here there's nothing to delete because nothing was ever sent. Open DevTools → Network tab and compress a file: zero upload requests.
It works offline once the page and core are cached.

The one gotcha: @ffmpeg/core-mt (the multithreaded build) needs SharedArrayBuffer, which needs cross-origin isolation (COOP/COEP headers), which breaks a lot of third-party embeds. I chose the single-thread @ffmpeg/core on purpose — slightly slower, but no header gymnastics and full compatibility with everything else on the page. Know your tradeoff before you reach for the MT build.

The stack

Nothing exotic, deliberately:

Next.js 16 (App Router) + React 19 + TypeScript
Tailwind CSS 4
@ffmpeg/ffmpeg 0.12 for the fallback path, mediabunny for WebCodecs demux/probing
Static export — every page is SSG, deployable to Vercel / Cloudflare Pages / Netlify free tiers

The compression parameter functions (the bitrate/CRF math above) are pure and covered by node --test unit tests. When the thing that matters is "did we compute the right bitrate," you want that logic testable without spinning up a browser or a real encoder.

Try it / read it

The tool: videocompress.dev — drop a file in, pick a target size or quality, download. No account, no upload, no watermark.
If you're building something similar, the WebCodecs-with-ffmpeg-fallback pattern and the bitrate math are the two pieces worth stealing.

If you end up shipping in-browser media processing, I'd genuinely like to hear how you handled the engine-selection edge cases — the "API exists but can't encode this" gap is where most of the real bugs live. Drop a comment.