File size is one multiplication
Resolution does not set the size of a video file and neither does frame rate. Bitrate does. Multiply the bits per second by the number of seconds, divide by eight, and you have bytes.
bytes = (video Mbps x 1,000,000 + audio kbps x 1,000) x seconds / 8
Resolution and frame rate matter only through the back door: they determine how much bitrate you need before the picture starts falling apart. Shoot in 4K and cap the encoder at 5 Mbps and you get a small file containing a smeared 4K picture. The encoder does what you told it.
Two different megabytes
This is where the arithmetic usually goes wrong. The M in Mbps is 1,000,000. The MB your file manager reports is 1,048,576 bytes. Same letter, 4.86% apart.
| Written as | Actually | Used by |
|---|---|---|
| 1 Mbps | 1,000,000 bits per second | Encoder settings, ISP speeds, broadcast specs |
| 1 MB (binary, MiB) | 1,048,576 bytes | Windows Explorer, Android, iOS |
| 1 MB (decimal, SI) | 1,000,000 bytes | Drive and card packaging, macOS, most Linux tools |
Ten minutes at 8 Mbps is 4,800,000,000 bits, which is 600,000,000 bytes. A drive maker calls that exactly 600 MB. Windows calls the same file 572 MB. Nothing changed but the divisor. This page prints both and leads with the binary figure, because the binary figure is the one you will see when you go looking for the file. Which convention a given service means by its "25 MB attachment limit" is not documented anywhere useful, so when you are close to a limit, size against the binary number and you have a margin either way.
Where the recommended bitrates come from
The table is built from the figures platforms publish for standard-dynamic-range uploads, with two adjustments. Frame rates above 30 get roughly 50% more bitrate, because there are that many more frames to describe. Codec efficiency is applied as a flat factor: H.265 at about 60% of H.264 for a comparable result, AV1 at about 50%.
Those factors are averages across typical content and should be read as such. A locked-off interview at 1080p compresses far better than confetti falling in front of a moving camera, and the gap between codecs widens on the difficult material and narrows on the easy material. Treat the recommendation as the middle of a range roughly half as wide again in either direction, not as a target to hit precisely.
Working backwards from a limit
Switch the first field to bitrate mode when the constraint is the size and the bitrate is the unknown. Give it the limit and the running time and it subtracts the audio budget first, since audio is a fixed cost that does not scale with picture complexity, and reports what is left for the video.
If what comes back is well below the recommendation, adding compression is the wrong move. Take a resolution step down instead. Going from 1080p to 720p cuts the bitrate requirement by around 40%, while a 720p picture at an adequate bitrate looks better on any screen than a 1080p picture starved to the same file size. Re-encoding to H.265 or AV1 is the other move that buys real headroom, at the cost of encode time and some compatibility with older players.
Questions people ask
Why does my exported file not match this number exactly?
Two reasons, and both usually push the file slightly larger. Container overhead is the first: MP4 and MKV both add an index, timing data and stream headers, which typically costs a fraction of a percent but can be more on a file with many small fragments. Variable bitrate encoding is the second and the bigger one. A CBR encode holds the average and lands close to the calculation. A VBR or CRF encode treats your bitrate as a target or ignores it entirely in favour of a quality level, so a busy clip overshoots and a static one undershoots, sometimes by a lot. If you need to hit a size precisely, use two-pass encoding with an explicit average bitrate.
Is a higher bitrate always better quality?
Up to a point, then it stops mattering. Every encoder reaches a level where it has enough bits to represent the source and additional bits go into encoding noise that nobody can see. Where that point sits depends on the content, but past roughly double the recommendation for the resolution you are usually paying storage and upload time for nothing. Uploading to a platform makes this stricter still, because the platform re-encodes to its own targets on receipt and anything above what its encoder can use is discarded on arrival.
How do I find the bitrate of a file I already have?
Divide it out, or ask a tool. The arithmetic is file size in bits divided by duration in seconds: a 600 MB file that runs ten minutes is 600 x 1,048,576 x 8 bits over 600 seconds, about 8.4 Mbps combined. For the exact per-stream figures, MediaInfo reports video and audio bitrates separately on every platform, and ffprobe prints the same data if you already have ffmpeg installed. Both distinguish the nominal bitrate stored in the header from the measured average, which can differ on a VBR file.
Does the audio bitrate really matter?
It matters when the clip is long or the video bitrate is low. At 8 Mbps of video, 192 kbps of audio is under 2.4% of the file and you can ignore it. At 1 Mbps for a screen recording, that same audio is 16% of the total, and dropping to 96 kbps mono for speech gets that back with no audible loss. The other case is a size limit that a clip barely misses. Audio is a fixed cost per second, so on a long clip near a hard cap it is often the easiest place to find the last few megabytes.