Video Bitrate Calculator
Give it any two of file size, duration and bitrate, and it solves the third. The audio bitrate is a separate field because it comes out of the budget before the picture gets anything.
Every result is shown in both decimal MB and binary MiB. That is the whole reason two bitrate calculators disagree, and neither of them usually says which one it means.
Audio comes out of the budget before the picture gets anything. Use 0 for a silent clip, 128–192 kbps for normal stereo delivery, 384 kbps if you are matching YouTube's upload recommendation.
This is the payload. MP4 container overhead adds roughly 1%, so when a hard ceiling is involved, aim about 2% under it.
Pick an exported video and this fills in its size and duration, then shows the average bitrate it actually used. The file never leaves your browser — there is no upload and no server involved.
ffmpeg -i input.mp4 -c:v libx264 -b:v 8M -pass 1 -an -f null /dev/null && \ ffmpeg -i input.mp4 -c:v libx264 -b:v 8M -pass 2 -c:a aac -b:a 128k output.mp4
Two passes because a size target needs the encoder to measure the whole file before it decides where the bits go. If you do not have a hard size limit, encode with -crf instead and let the size fall where it falls.
The Formula
That is all of it. Bitrate is bits per second, a byte is eight bits, and a file is its bitrate held for its duration. Ten minutes of 8 Mbps video with a 128 kbps audio track is 8.128 Mbps × 600 seconds = 4,876,800,000 bits, which is 609.6 MB — or 581.4 MiB, depending on who is counting.
Bitrate is always decimal. 1 Mbps is 1,000,000 bits per second, never 1,048,576. Storage is where the ambiguity lives: a megabyte is a million bytes, a mebibyte is 220 bytes, and the binary figure comes out about 4.6% lower at the MB scale and about 6.9% lower at the GB scale. macOS Finder, drive manufacturers and most upload limit pages use the decimal figures. Windows Explorer uses the binary ones and labels them "MB" and "GB" anyway. So the same file is 609.6 MB on one machine and 581 MB on another, and nothing about the video changed.
One consequence worth carrying: when a service publishes a size limit it rarely says which base it means. Aim a couple of percent under it. MP4 container overhead is around 1% on its own.
Why the Audio Field Is Separate
At a 4K budget, audio is a rounding error. At an attachment-sized budget it is the whole argument. A 25 MB ceiling on a three-minute video is 1.11 Mbps total. Take 128 kbps out for stereo AAC and the picture is left with 0.98 Mbps — audio just consumed 11.5% of everything you had. Calculators that fold audio into a single "total bitrate" field quietly hand that shortfall to the encoder, and you find out when the result looks like a JPEG from 2004.
YouTube's recommended 384 kbps stereo is unusually high for a reason: it is an upload recommendation, not a delivery bitrate. YouTube re-encodes your audio anyway, so the number exists to give their encoder clean input. For a file a person will actually play, 128–192 kbps AAC stereo is the normal range.
What Bitrate Actually Is
Bitrate is how many bits per second the encoder is allowed to spend describing your video. It is not a quality setting. It is a budget, and quality is what the encoder manages to buy with it — which depends entirely on how expensive your footage is to describe.
Modern codecs work by predicting. A frame is mostly encoded as the difference from the frames around it, so footage that barely changes costs almost nothing: a locked-off screen recording of a text editor can look perfect at 2 Mbps in 1080p, because from frame to frame there is hardly any new information. Now shake the camera, add film grain, or point it at water, confetti or foliage, and every pixel is new every frame. Prediction fails, the encoder has to describe the picture from scratch, and 12 Mbps starts to block up.
This is why "what bitrate for 1080p" has no honest single answer, and why every table of recommended bitrates — including the one below — is a starting point rather than a specification. Resolution and frame rate set the size of the problem. Motion and grain set its difficulty.
CBR, VBR and CRF — and Why CRF Is Usually Right
CBR (constant bitrate) spends the same number of bits every second regardless of what is on screen. It wastes bits on a static title card and starves a fast pan of them. You use it when the transport cannot cope with variation: live streaming to an RTMP endpoint, broadcast multiplexes, some hardware decoders with fixed buffers. Outside those cases it is the worst of the three.
VBR (variable bitrate) lets you name an average and redistributes around it, spending more on hard passages and less on easy ones. Two-pass VBR does it properly: the first pass measures the entire file, the second allocates the budget with full knowledge of where the difficulty is. This is the correct tool when a size ceiling is genuinely non-negotiable — an email attachment, an upload limit, a client's CMS.
CRF (constant rate factor) inverts the question. You specify a quality and the encoder spends whatever that quality costs, scene by scene. The file size is an output, not an input. x264 defaults to CRF 23 and 18–23 is the usual range for 1080p delivery; x265's scale sits about five points higher for a comparable look (its default is 28), and SVT-AV1 defaults to around 35. Lower is better quality and a larger file, and the scales are not interchangeable between encoders.
For delivery, CRF is usually the right answer, and the reason is straightforward: quality is the thing you actually care about, and bitrate is only a proxy for it. Pick a bitrate and you have committed the same budget to your talking-head intro and your drone shot — one gets more than it needed, the other less. Pick a CRF and both come out looking the same, which is what you wanted in the first place. Encode with CRF, look at the file size, and only reach for two-pass VBR if something is forcing you under a specific number.
Where Higher Bitrate Stops Helping
There are two ceilings, and they are different problems.
The encoder's ceiling. Every codec has a point where the quantiser bottoms out and the picture is as close to the input as that codec can get. Bits past that point are spent encoding sensor noise and dithering with perfect fidelity. On clean 1080p24 interview footage, the visible difference between 12 and 25 Mbps of H.264 is close to nothing. On grainy 4K60, 25 Mbps is genuinely short. Same codec, same claim, opposite verdicts — which is why a number quoted without the footage it applies to is not information.
The source's ceiling. This one is absolute. Encoding cannot add information that was never captured. A 1080p file that came off a phone at 20 Mbps and gets re-encoded at 80 Mbps is an 80 Mbps copy of a 20 Mbps picture: four times the size, identical detail, plus a fresh layer of its own compression on top. Bitrate buys the absence of new artifacts. It never buys detail back.
Re-encoding Loses What No Bitrate Recovers
Lossy compression throws information away on purpose and permanently. Detail below the quantiser's threshold is rounded off. 4:2:0 chroma subsampling keeps a quarter of the colour resolution. Motion prediction approximates whole regions as "close enough to that other frame". None of it comes back.
Now decode that file and encode it again. The second encoder is not looking at your footage — it is looking at the artifacts of the first encode, which it cannot distinguish from real detail. So it dutifully spends bits preserving blocking and ringing while introducing its own. Every generation compounds, and the losses are multiplicative rather than additive. Turning the bitrate up on the second pass reduces the damage that pass adds; it does nothing at all about the first one.
The practical rule that follows: count generations, not megabits. Camera to editor to export to YouTube is three encodes minimum, and one of them — YouTube's — you do not control. That is exactly why platform recommendations are so generous: they are not asking for a good-looking file, they are asking for enough headroom that their own re-encode starts from something clean.
Why Valmera Exports From the Original File
This is the same problem, and it drove a real decision in how Valmera is built.
When you upload footage, Valmera builds a small, fast proxy alongside it. Previews render from the proxy, which is what makes iteration quick — you ask for a change, you see it in a reasonable amount of time. But that proxy is a second generation by construction: smaller, more compressed, degraded deliberately so it renders fast.
The obvious way to build the export is to hand you the preview. It already exists, it already looks right, and nobody would notice for a while. It also means every video anyone ever downloads is a compressed copy of a compressed copy, and no export bitrate setting fixes that — see the two sections above for why.
So Valmera renders the final export from the original uploaded file. The agent edits an edit decision list — instructions, not pixels — so at export time the same instruction set that produced the preview is replayed against the source. The proxy is a viewing convenience with no path into the deliverable. Your export is one encoding generation from your camera instead of two, which is a larger real-world quality difference than any bitrate slider would have given you.
It has a second consequence worth stating plainly: because the original is never modified, nothing you ask the agent to do can degrade your source. Cuts, grades and effects are decisions layered on top of a file that stays exactly as you uploaded it, and any of them can be reversed by asking. More on how that works in the export docs.
Recommended Bitrates by Resolution and Frame Rate
The H.264 column is YouTube's published SDR upload recommendation, quoted as-is. The H.265 and AV1 columns are those figures scaled by 0.65 and 0.5 — neither codec has a published YouTube upload recommendation to quote, so the honest thing is to scale a real anchor and say so. All figures are Mbps.
| Resolution | fps | H.264 | H.265 | AV1 |
|---|---|---|---|---|
| 2160p (4K) | 24–30 | 35–45 | 23–29 | 18–23 |
| 2160p (4K) | 48–60 | 53–68 | 34–44 | 27–34 |
| 1440p (2K) | 24–30 | 16 | 10 | 8 |
| 1440p (2K) | 48–60 | 24 | 16 | 12 |
| 1080p | 24–30 | 8 | 5 | 4 |
| 1080p | 48–60 | 12 | 8 | 6 |
| 720p | 24–30 | 5 | 3.3 | 2.5 |
| 720p | 48–60 | 7.5 | 4.9 | 3.8 |
| 480p | 24–30 | 2.5 | 1.6 | 1.3 |
| 480p | 48–60 | 4 | 2.6 | 2 |
| 360p | 24–30 | 1 | 0.65 | 0.5 |
| 360p | 48–60 | 1.5 | 1 | 0.75 |
HDR needs more. YouTube's HDR recommendations are 44–56 Mbps for 4K at 24–30fps and 66–85 at 48–60, 20/30 for 1440p, 10/15 for 1080p and 6.5/9.5 for 720p. Ten-bit colour needs the extra bits to keep shadows from banding. 480p and 360p are not supported for HDR uploads.
Audio, per YouTube: 128 kbps mono, 384 kbps stereo, 512 kbps for 5.1. Again — upload recommendations. 128–192 kbps AAC stereo is the normal range for a file someone will actually play.
The savings ratios are conservative on purpose. HEVC's verification tests reported better than 50% subjective bitrate savings over H.264, but only 40–45% by PSNR; AV1 adds roughly another 20% over HEVC, and an independent teardown of Netflix's shipped AV1 streams measured them running about 48% below the H.264 renditions of the same titles. Savings shrink on grainy, high-motion footage and grow on clean, static footage — so a 0.65x and 0.5x table will rarely be wrong in the direction that hurts.
How to Pick a Bitrate
- 1Decide whether a size limit actually existsIf nothing is forcing you under a specific number, skip bitrate entirely and encode with CRF — quality target in, file size out. Bitrate targeting only earns its complexity when a ceiling is real: an attachment limit, an upload cap, a hard delivery spec.
- 2If a ceiling exists, work backwards from itPut the ceiling and the duration into the calculator above and read off the total bitrate, then subtract your audio track. Aim about 2% under the published limit — MP4 container overhead is roughly 1%, and services rarely say whether their limit is MB or MiB.
- 3If you are uploading to a platform, use its numbers or moreYouTube, and every platform like it, re-encodes what you send. Their recommended bitrates are headroom for that re-encode rather than a delivery target, so meeting or exceeding them costs you upload time and buys the viewer a cleaner picture.
- 4Sanity-check against the footage, not the tableA static screen recording and a handheld shot of moving foliage at the same resolution are not the same encoding problem. Encode a difficult thirty seconds, look at it at full size, and adjust from what you see rather than from what a table said.
If you find yourself tuning bitrate repeatedly, that is usually a sign the job wanted CRF.
Editing, Not Just Encoding
Bitrate is the last decision in a video's life, and the least interesting one. Valmera is an agentic AI video editor: you upload real footage, describe the edit in plain English, and an agent indexes the video — word-level transcript, silence detection, shot detection, labeled frames it looks at — then performs the edit, renders a preview, checks the frames it produced, and revises.
It cuts the dead air, burns word-accurate captions, mixes music under your voice and reframes for vertical — and then exports from your original file, at source quality, for the reason described above. Every account starts with 50 free credits and no card. See the full list on the tools hub or what the plans cost.
Frequently Asked Questions
Stop Re-encoding Your Footage to Death
Valmera edits from an instruction list and exports from your original file. 50 free credits, no card required.
Start free →