Video Bitrate Calculator

◆ Other calculators: File sizes — Time ◆

About

This calculator is intended to make bitrate calculations for encoding movies easier. Fields used as inputs for a button or edit field are highlighted in green, and output fields in pale yellow. When pushing a button or having edited a field, fields updated by this action will flash bright yellow.
Highlighting behaviour differs between desktop and touch browsers due to differences between a cursor- or touch-driven UI. If you prefer either or the other, or if touch UI detection should fail, the button below the calculator allows to override it.

Usage

The classic use case is to determine the required video bitrate to fill a fixed-size medium like a CD-R or DVD+R, given a fixed audio bitrate and movie duration. To do this, enter the duration, audio bitrate and target size, and press the “Video from time,size,audio” button. You can do the same for audio. Total audio bitrate is the number of audio tracks times the given audio bitrate. You can use this to either represent multiple tracks (for instance languages), or multiple discrete surround channels.

Another useful scenario is to determine whether a video file can fit in a fixed-size medium like a DVD-R at acceptable quality. Or likewise, if you want to avoid wasting download time on a file that just seems too small to possibly offer good quality. In these cases, do the same as above to calculate the actual video bitrate and write down or memorise this number. Then enter the film's image dimensions and frame rate in the lower part of the calculator. Push the appropriate ‘Suggest bitrate’ button (see instructions below). If the suggested video bitrate is much higher than the actual one (about double or more), video quality will probably be unacceptably bad. Just to give an example: with H.264 there is no way to fit a normal two-hour film on a single CD-R at anything higher than DVD resolution without making it look or sound awful, so please do not try it.

Mind that sizes are given in two ‘flavours.’ If you don't know the difference between a MB and a MiB, check out my other page that explains it. Unfortunately a lot of software still uses the ‘MB’ symbol while they actually mean MiB. In case of doubt, assume KiB, MiB and GiB values: if the software does use kB, MB, and GB, your file will be slightly too small, which is not as bad as too large.

Overhead is what is left of the file after removing actual video and audio data. This is heavily dependent on the container format, codecs and parameters, and includes any extra streams like subtitles. This calculator assumes overhead is proportional to the length of the video, which is a simplification. In reality there will also be a one-time overhead for the file itself and metadata. In case of doubt and if the file must fit within a certain size, it's better to use a conservatively high overhead estimate.

Bitrate suggestion

The ‘Suggest bitrate’ buttons try to give an OK average video bitrate estimate for a movie, based on given dimensions, frame rate, and the video codec. (If you don't know what a codec is, I have another page that explains this.) Most likely you should use either the “H.264 high” button because practically everything nowadays supports the ‘high’ H.264 profile, or the “H.265” button if you are encoding with that codec. The other buttons are legacy: the “MP4” button represents encoding with the old MPEG-4 based Xvid or DivX which only makes sense if the target is some old constrained playback device. The “H.264 baseline” button represents encoding with H.264 without advanced options like trellis, CABAC, RD, etc., which also would only be appropriate in limited situations.
For giggles, the “Raw” button shows bitrate for raw (uncompressed) video—try it and you'll see why codecs were invented.

Beware that this is not exact science. It is wet-finger guesswork because except for raw video, the actual required bitrate depends heavily on video contents. The calculation assumes you're using double-pass encoding and a ‘typical’ frame rate (around 25fps). A few checkboxes are provided to allow somewhat tuning the guess: check the ‘CGI’ box if the film consists purely or mostly of smooth computer-generated images (like Toy Story, Ice Age, …); check the ‘Dark’ box for films that have many dark shots with large parts of the image often almost pure black or out-of-focus (e.g., Dark City). Check the ‘Noisy’ button if the image is noticeably noisy throughout, has a lot of fast movement, and/or contains a lot of footage of trees, bushes or other cluttered things. For a movie like Avatar, you should check this: even though it is mostly CGI, the images are very detailed and there is a lot of action.

I tuned this estimator by encoding various 1080p24 video fragments at a quality where I couldn't see any image degradation in the result without rigorously comparing to the source material. The estimates deliver in my opinion a “good enough” quality on average if the goal is to stay close to the source material.
The main purpose of this tool is to check whether the bitrate you're going to use is reasonable. If you encode a film with an actual video bitrate more than twice what this estimate gives, you're probably wasting disk space unless you are adamant on preserving film grain. If your bitrate is considerably lower than this estimate, the quality of the encoding will probably be bad. How bad, depends on both the codec and the content of the video. The less detail, movement, and noise in the image, the easier it is to encode. For instance computer animations with very clean images and generally static backgrounds (like the Toy Story series) can fit in a surprisingly low bitrate without obvious quality loss. As for the codec: H.264 and similar modern codecs are very capable at gracefully degrading the image, therefore even if you go far below what this calculator suggests, it may still look OK on its own. Compared to the original or a higher bitrate encoding however, it will look obviously washed-out if bitrate is too low.

Bitrate requirements also tend to become less strict for higher-resolution video. This calculator does not take this fact into account, therefore you may consider the estimate the more conservative the larger your video frame size is. The same goes for higher frame rates.

Hints

Avoid relying on bitrate altogether

If you are encoding a film and it doesn't really matter how large the resulting file is yet you don't want to waste disk space, consider using quality-based encoding, which in most cases makes a lot more sense than using a fixed bitrate. A fixed bitrate only makes sense for streaming or storage on a fixed-size medium. I explain this in more detail in my article with video encoding tips.

If you're planning to encode multiple movies that must fit within a specific size, e.g., three movies in 4.7GB, do not just encode each movie to be 4.7/3 = 1.56GB. That does not make sense unless they are all the same length, frame rate, and frame size. To get a sensible idea of what the relative sizes of the movies should be, use the ‘Suggest bitrate’ feature to determine their ‘ideal’ sizes and then try to divide the total available size in chunks that have the same proportions. For instance if the calculator says that film A should be 3 GB, B 2 GB and C 1.5 GB, and you want to squeeze all three on a single 4.7 GB DVD-R, you should try to make them respectively 2.17 GB, 1.45 GB and 1.08 GB.

Also do not try to steal bitrate from the audio stream in order to get marginally more bits for video. The audio stream is typically much smaller anyway so there is not much to gain, and worse audio is much more annoying than slightly worse video. If you really are short on bits, consider reducing the number of audio channels (5.1 to stereo, or stereo to mono), instead of trying to squeeze too many audio channels in too low a bitrate.

Get true bitrates with mediainfo

Mediainfo normally only shows bitrates if they are stored in the file's metadata. If the bitrate numbers are not in there, they will be missing from mediainfo's output no matter what you try, unless you run it in a special mode that forces a full analysis of the file. By adding the --ParseSpeed=1 option, it will parse the entire file and recompute bitrates. This is of course way slower but you will obtain the actual values. The following example (for bash-like shells) prints true average bitrates for both video and audio.

mediainfo --ParseSpeed=1 --Inform=$'Video;Video: %BitRate/String%\\n\nAudio;Audio: %BitRate/String%' yourfile.mkv

Short note about DTS

If you are confused about DTS bitrates: the classic DTS audio stream has an actual bitrate of 1509 kbps (sometimes also 1509.75) but when sending it over a cable, it is encapsulated in a transmission stream of 1536 kbps, the exact rate of uncompressed stereo PCM audio. (Similar for the to-be-avoided half-bitrate variant: 754.5 and 768 kbps respectively.) Obviously when using such track in an efficient media file, only the true rate will be used.