Skip to content

Blog

I asked for 1 Mbps and got a file 2.8 times that size

3 min readWritten by the site’s operator

Six seconds at 1 Mbps is about 750 KB, give or take. The file that came out was 2 MB.

This is a number measured while building the compression tool on this site. A six-second clip, requested at 900 kbps of video and 96 kbps of audio. Multiply it out and you expect roughly 725 KB. What came back was 2.0 MB — 2.8 times the request.

Size implied by the requestabout 725 KBThe file that came out2.0 MB (2.8x)Measured on deliberately hard-to-compress footage. The factor for ordinary video is not measured — see below.
The same six seconds of video: what the arithmetic said, and what was actually written out.

A bitrate is a request, not a ceiling

The cause is not mysterious. The bitrate handed to a browser’s recorder is a target, not a cap. It has no lookahead, so it cannot reason that the next three seconds are busy and it should save room now. It encodes the frame in front of it at the quality asked for, and moves on. Where there is a lot of movement, it goes over.

A dedicated video editor can hit a size because it passes over the footage twice, deciding where to spend the data before writing anything. A browser recording in real time, as the video plays, does not have that luxury.

Which is why the estimates run high

Before it starts, image and video compression shows an estimate of the result. That estimate is deliberately biased to overshoot. The same is true for images: a high-detail picture predicted at 221 KB actually came out at 385 KB, so image estimates carry a 1.3x pad.

The reason is simple. Nobody complains that the file came out smaller than promised. Say "about 1 MB" and deliver 1.5 MB and you have told them something untrue. If the estimate has to be wrong in one direction, the direction is not a hard call.

Whether the target was actually met is then checked by measuring the finished file, not by trusting the arithmetic. If it came out over, it gets encoded again.

So what should you change?

There is an order of operations here, and the bitrate number is not the top of it.

  1. Cut the length. Size is roughly bits-per-second multiplied by seconds. Fitting ten minutes into 20 MB and fitting the two minutes you need into 20 MB are different problems — the second gets five times the bitrate. This is the biggest lever by far.
  2. Drop the resolution. Going from 1080p to 720p roughly halves the bitrate needed. For something that will be watched on a phone, 720p is plenty.
  3. Lower the frame rate. Last resort. Motion starts looking wrong, and the saving is modest for how visible it is.

Trimming is a job for audio trim and join or a video editor; resolution is chosen for you when you pick a destination in the compression tool. Choosing the destination gets you there faster than tuning numbers does.

One more thing that cannot be changed

Re-encoding video in a browser takes real time: ten minutes of video takes ten minutes. Because the frames come from playback, speeding the playback up does not help — the recorder works against the wall clock, so playing at 2x simply records a video that runs at 2x.

That is stated in the tool before you start. The wait itself cannot be fixed, but knowing about it in advance is a different thing from discovering it.

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

Next article

4 min readHow much faster is "tempo +1" on a karaoke machine?

Press tempo +1 and the song speeds up — by how much? Makers do not publish the step size, so here is how to measure it yourself and how to build a practice track at the same speed at home. Changing the tempo does not change the key.

All articles

Sponsored links