Skip to content

Blog

The browser said it could do it, and produced a broken file

2 min readWritten by the site’s operator

The file was 1,690 bytes. Not zero — which is exactly why nothing caught it.

This is the nastiest defect found while building the video compression on this site. Browsers offer a way to ask "can you record in this format?". It answered yes for every combination — and one of them produced a file with essentially nothing in it.

The four combinations, measured

ContainerAudioWhat came out
MP4no15,947 bytes — fine
MP4yes1,690 bytes — corrupt
WebMno21,896 bytes — fine
WebMyes26,827 bytes — fine
Measured in Chrome. Asked whether it could record, all four rows answered yes.

Only the second row is broken. Muxing audio into MP4 from a canvas stream yields a file with no usable content — and because it is 1,690 bytes rather than zero, a "failed if empty" check walks straight past it.

"Just always use WebM" does not work

That was the first idea. MP4 is what breaks, so record WebM. Except that breaks Safari, which is the mirror image: it records MP4 natively and cannot do WebM at all. Fixing one breaks the other.

Branching on the browser — "Chrome gets this, Safari gets that" — just bakes in today’s assumptions. It has nothing to say about a browser that does not exist yet, or about the next release changing its mind.

So it stopped asking and started measuring

AskCan you record this format?"Yes"MeasureRecord 600 ms for real0 bytes: rejectedThe probe runs while the visitor is still reading the options, so it costs no visible time.
Two ways to answer the same question. The lower one records 600 milliseconds for real and judges by how much data comes back.

What happens now is that it records 600 milliseconds through the exact pipeline it is going to use, and keeps the first container that returns a plausible share of the requested bitrate. Not a question — a measurement.

The result was instructive: in Chrome the fully-specified MP4 came back at 0 bytes in the probe and was rejected, and it fell through to plain unspecified MP4, which encodes correctly. No hand-written preference list would have discovered that ordering. End to end, a 5.0 MB clip became a 2.0 MB MP4 that plays back correctly at 854x480 for 5.99 seconds.

What to take from it

This reads as a builder’s problem, but there is something in it for anyone using these tools: open the file after a conversion says it succeeded. Be especially suspicious when the compression ratio looks wonderful. If ten minutes of video became a few hundred kilobytes, that is not compression — the contents are gone.

Image and video compression on this site now reads the finished file back and checks it actually decodes. That check exists because the 1,690-byte file shipped once.

The stem separation in this article runs free in your browser — no sign-up, and your audio never leaves your device.

Next article

3 min readI asked for 1 Mbps and got a file 2.8 times that size

Setting a bitrate when compressing video does not give you a file of that size. Measured here: 2.8 times what was requested. Why that happens, and what to change instead.

All articles

Sponsored links