Media Production Tools
Menu

Why Your Actual Video File Size Differs From the Estimate

A bitrate estimate is exact arithmetic on an assumption, and the assumption is what moves. This guide covers the four documented reasons an export misses the estimate, and shows how to model each one instead of guessing.

Published 2026-08-11 · Updated date pending

The short answer

The estimate is not wrong; its assumption is. A bitrate-based estimate assumes the stated bitrate is the average the encoder actually achieved, that the container adds nothing, and that you and your operating system are using the same unit system.

Four things break those assumptions: rate control that never targeted your bitrate, container overhead, decimal against binary units, and an audio track that was included or excluded differently than you thought. Each is modellable, and the Video File Size Calculator has a field for the ones that are yours to supply.

Reason one: the encoder was never aiming at your bitrate

This is the largest discrepancy by far, and it is usually invisible because the setting responsible is a default.

x265’s documentation states that CRF “is the default rate control method; it does not try to reach any particular bitrate target, instead it tries to achieve a given uniform quality and the size of the bitstream is determined by the complexity of the source video.” An encode left on its defaults therefore produces whatever size the footage demands. Comparing it against an estimate built from a bitrate you never requested is comparing two unrelated numbers.

Even when you do request a bitrate, the mode matters. x265 documents --bitrate as enabling “single-pass ABR rate control” — an average bitrate over the whole encode, approached as the encode proceeds, not held at every instant. Single-pass ABR can miss its target, particularly on short clips where there is little runtime to converge over.

The fix is to request a bitrate explicitly, and to use a multi-pass mode when the size has to be right. See CBR vs VBR.

Reason two: the container costs bytes of its own

A media file is not just an encoded stream. It is a structure that carries the stream plus everything needed to find your way around it.

The Matroska specification is a readable illustration because its structure is enumerated element by element. Inside the Segment it defines SeekHead, which “Contains seeking information of Top-Level Elements”; Info, which “Contains general information about the Segment”; Tracks; Clusters carrying the block structure; and Cues, “A Top-Level Element to speed seeking access”, which the specification says “SHOULD be set when the Segment is not transmitted as a live stream.”

Every one of those is bytes on disk that are not your picture. The same principle applies to any container: an index that lets a player seek has to be stored, and per-frame structure has to be stored.

The pattern is general. RFC 9293 shows it on the network side, deriving the default IPv4 maximum segment size of 536 octets as 576 minus 40 octets of fixed IP and TCP headers — structure travelling alongside payload, exactly as it sits alongside it in a file.

This project publishes no overhead percentage, because the real figure is codec-, container- and muxer-specific and no measurement has been made here. The calculator exposes the knob and defaults it to zero:

storedBytes = payloadBytes x (1 + overheadFraction)

If you have measured your own pipeline, enter it. Otherwise zero is the honest default, and it means the estimate is a payload figure.

Reason three: you and your computer are using different units

NIST’s note gives the two systems. In SI, giga is 10^9, so 1 GB is 1,000,000,000 bytes. The binary quantity is a gibibyte, 2^30 bytes, which is 1,073,741,824.

2 653 800 000 bytes = 2.65 GB
2 653 800 000 bytes = 2.47 GiB

Same file, two labels, a 7.4% apparent difference. If your estimate says 2.65 and your file manager says 2.47, nothing has gone wrong and there is nothing to fix. The calculator’s unit-system control switches between decimal and binary, and always labels binary units with their binary names.

Reason four: audio was counted differently

The formula adds the audio bitrate before dividing:

totalBitrate = videoBitrate + (includeAudio ? audioBitrate : 0)

At high video bitrates this hardly registers; at low ones it dominates. Ten minutes at 1 Mbps of video is 75.00 MB without audio and 84.60 MB with a 128 Kbps track — a 12.8% difference from a setting that is easy to overlook. If your export includes audio and your estimate did not, that is where the gap is.

Worked example: overhead applied and not applied

Take the simplest case that isolates the container term — 10 Mbps of video, sixty seconds, audio switched off:

without overhead
  payloadBits   = 10 000 000 x 60 = 600 000 000 bits
  payloadBytes  = 600 000 000 / 8 =  75 000 000 bytes

with 5% overhead
  storedBytes   = 75 000 000 x 1.05 = 78 750 000 bytes

3,750,000 bytes of difference from a single advanced field. Add a 128 Kbps audio track back at zero overhead and the same minute becomes 75,960,000 bytes, or 75.96 MB — which is 72.44 MiB if your file manager is reporting binary units. Three of this guide’s four reasons, visible in one worked example. Every line reproduces in the Video File Size Calculator.

What this does not tell you

  • No overhead percentage is recommended, because none has been measured here. The field exists so you can supply a figure you trust.
  • No codec efficiency is modelled. The arithmetic uses the bitrate you give it. See H.264 vs H.265.
  • Variable-bitrate behaviour is not predicted. The encoder documentation quoted above describes what the modes do, not what your footage will produce.
  • Editing-application defaults are not catalogued. Every application names its rate control differently. Read yours.

Frequently asked questions

My export is much smaller than the estimate. What happened?

Most often the encoder was in a quality-targeted mode and never aimed at your bitrate. x265’s documentation states that in its default CRF mode the bitstream size “is determined by the complexity of the source video”. Simple footage in that mode produces a small file regardless of what you estimated.

My export is larger than the estimate. What happened?

Check three things in order: whether audio was included in the export but not in the estimate; whether the estimate used decimal units and the file size is being reported in binary; and whether the encoder overshot an average-bitrate target. Container overhead is real but is usually the smallest of the four.

What overhead should I enter?

Zero, unless you have measured your own pipeline. Zero gives the payload size, which is a well-defined quantity. A number you did not measure gives a false precision.

Why does the estimate not ask which codec I am using?

Because the codec reaches file size only through the bitrate, and you supply the bitrate. A calculator that asked for a codec would have to apply an efficiency factor, and this project has measured none.

Is the estimate useful if it can be off?

Yes, as a planning figure. It tells you exactly what a given average bitrate costs per minute and per hour, which is what card and upload planning need. It is a calculation, not a prediction of your encoder’s behaviour.

Sources

  • Command Line Options — x265 documentation. https://x265.readthedocs.io/en/stable/cli.html. Accessed and verified 2026-08-11. Supports the CRF default statement, the complexity-determined bitstream size, and the single-pass ABR description of --bitrate.
  • Matroska Element Specification — Matroska. https://www.matroska.org/technical/elements.html. Accessed and verified 2026-08-11. Supports the existence and purpose of SeekHead, Info, Tracks, Cluster and Cues as non-payload structural elements.
  • RFC 9293: Transmission Control Protocol (TCP) — IETF / RFC Editor. https://www.rfc-editor.org/rfc/rfc9293.html. Accessed and verified 2026-08-11. Supports the 40-octet fixed IP and TCP header figure behind the default 536-octet MSS, as an illustration of structure carried alongside payload.
  • Definitions of the SI units: The binary prefixes — NIST. https://physics.nist.gov/cuu/Units/binary.html. Accessed and verified 2026-08-11. Supports giga being 10^9, gibi being 2^30, and the resulting byte counts.