A 25 MB video target came back at 14 MB, and the fix is checking how far under you landed

I asked x264 for a 25 MB file from a 60-second, 1080p screen recording. It returned 14.0 MB on the single pass and 14.3 MB on the two-pass run.

Then I let a quality-based search try as hard as it could, and the smallest it would go down to was still 11.05 MB, with the quality setting pushed almost to the bottom of its scale. The budget was simply bigger than the video needed.

Most of the target-size math I know is about not going over, and this run is the opposite case. Everything below is a single local run on an M4 Mac: FFmpeg 7.1, libx264 at the medium preset, AAC at 128 kbps, one pass per cell, nothing repeated. Sizes are real bytes, and 1 MB here is 1,000,000 bytes.

The formula was never the hard part

The formula is the familiar one: target size times 8, divided by duration. For 25 MB over 60 seconds that is 3,333,333 bits per second, minus the audio.

At 128 kbps, 60 seconds of AAC takes about 0.97 MB, and the MP4 container adds roughly 66 KB.

On a 1080p action clip I will call clip A, skipping the audio subtraction put the file 3.1% over at 25 MB and 9.2% over at 10 MB. With the subtraction, single pass landed at -0.66% and -0.35%. On clip A the arithmetic works.

The open question is a clip where rate control has nothing hard to chew on, so I made clip B: a synthetic screen recording, 60 seconds at 1080p and 30 fps, with a slide-like page, a moving cursor and scrolling, all drawn frame by frame. It is calmer than a real recording, so read everything about B as this one clip, not as screen recordings in general.

What the 25 MB budget did on a quiet clip

The CRF row settled it. I bisected the quality value for the largest file that stayed under the target, and it ran down to CRF 0.4 and stopped at 11.05 MB, with no room left to spend.

My first attempt used a range of 14 to 51 and stopped at 4,111,034 bytes, because 14 was the lowest value allowed. When a search ends on the edge of its range, the answer is the range, not the video.

None of this is a bug, since the encoder simply spent less than it was given. The gap is in the wrapper that says "25 MB target, done": it cannot tell you that you were sitting at 56% of the budget (14.0 MB of 25 MB) and never needed the rest, or that the full 1080p frame size fit with room to spare.

The same clip at 10 MB is a different story

Drop the target to 10 MB and the budget is tight again, so the same clip B behaves differently. Single pass with audio subtracted came back 8.65% under, the CRF search 1.6% under (CRF 1.99), and two pass 11,195,510 bytes, which is 12.0% over.

On clip B the video bitrate swings from 40 to 5,000 kbps, with sharp spikes where the page changes. My reading, which I did not verify, is that two pass plans around those spikes and ends up too generous.

So a bigger budget is not the only way to miss. Two pass was also the only method that went over target on clip A at both sizes, and CRF bisection never overshot but costs a full encode per trial: 157 to 217 seconds for seven trials on clip A, against about 23 seconds for a single pass.

What I would do with a budget

Treat the target as a ceiling rather than a goal. Subtract the audio and about 70 KB of container first, run one fast pass, and look at the size. If it came back near half of the target, keep that file or spend the spare room on resolution.

Whether a hard rate cap such as a maximum bitrate would keep a two-pass run from overshooting on a clip like B, I have not tested.

One note on tools that wrap all this. ImgIng (https://imging.ai/) runs in a desktop browser and has no "compress to this size" setting; it works from presets. Its interface also counts a "MB" as 1,048,576 bytes, so a "25 MB" there is about 4.9% more bytes than the figure I used.

On clip B its smart recommendation was accepted and wrote 9,351,418 bytes, while on clip A the same feature rejected its own candidate because the saving was 10.3%, under its 12% bar.

The hosted 8mb.video does have a size picker, and for clip B it returned 7,550,319 bytes when I chose 25 MB, at 1280x720. A picker tells you the ceiling, not whether the video needed it, so the under-target check above is still yours to do.