(If you’re just here for the formulas, you can jump down to the formulas.)
A codec’s bitrate can seriously affect your workflow, so as a video creator you must be able to understand and calculate video bitrates. This article explains in detail what a bitrate is and how to use it to calculate file sizes, and it’s a follow-up to our huge article on How to Choose the Right Codec for Every Project.
What if you’re shooting with a new camera, and you need to know how long your memory card will last you? All you need to know is the bitrate of the camera’s codec and a simple formula. There are video bitrate calculators out there, but they don’t include every codec, and doing this by hand is actually really simple. The formulas are at the end of the article, but I encourage you to read through the process, step by step. This will empower you to be able to work with any type of file or video stream, no matter the format.
Don’t be scared by all of the numbers – anyone can do this.
There’s only one thing you need to watch out for, and that is the difference between bits and bytes. The concept is simple: One byte is 8 bits. That’s all there is to it.
To convert between bits and bytes, you multiply by 8 or divide by 8. You just need to make sure you know which of them you’re dealing with. When they’re abbreviated, people use a lowercase b for bits and an uppercase B for bytes. Unfortunately, though, some people are not aware of the difference, and they will sometimes use the wrong one. Nearly all of the mistakes people make when talking about bitrates come from confusing bits and bytes.
When someone tells you about a bitrate, they usually give you that number in megabits per second (Mbps or Mb/s). That’s straightforward. Occasionally (less common) someone will give you the number in megabytes per second (MBps or MB/s). Whether or not the M is capitalized doesn’t matter – just look at the B.
A video bitrate is the amount of data that the file contains for each second of video. A simple formula describes the bitrate, the file size, and the length of the video. If you have two of those three, you can calculate the third.
For example, let’s say we have 2 hours of footage (120 minutes), we’re converting our footage to Avid DNxHD 175, and we want to know how much storage space we need.
Avid DNxHD 175 footage is 175 Mb/s (isn’t that handy?). We pretty much always talk about storage space in terms of bytes, though (megabytes, gigabytes, and terabytes). So the first step is to take the number in Mb/s and convert it to MB/s. But do we divide by 8 or multiply by 8? I think of it like the word “yard,” which is 3 feet. If I have 12 feet, that’s 4 yards. We have more feet than yards, just as we have more bits than bytes. We are starting with bits in this case, so we should end up with fewer bytes. That tells me that I need to divide by 8, not multiply by 8:
175 / 8 = 21.875MB/s.
Now we have MB/s (megabytes per second), but we need that in terms of minutes, not seconds. So let’s convert from MB/s to MB/m (megabytes per minute). The number of megabytes in one minute should be a lot more than the number of megabytes in one second, right? So we know we need to multiply by 60, not divide by 60.
21.875 * 60 = 1,312.5MB/m.
Now we have MB/m. All we do is multiply by the number of minutes we have. We shot 2 hours, so that’s 120 minutes.
1,312.5 * 120 = 157,500MB.
Ok, we have our result, but it’s kind of a big number, isn’t it? It would be easier to talk in numbers of gigabytes, not megabytes, so let’s convert to gigabytes.
One terabit/byte is one trillion (1,000,000,000,000) bits/bytes.
One gigabit/byte is one billion (1,000,000,000) bits/bytes.
One megabit/byte is one million (1,000,000) bits/bytes.
One kilobit/byte is one thousand (1,000) bits/bytes
You’ll notice that each one is a thousand times larger than the next. So if you’re going up the scale, you divide by a thousand, and if you’re going down the scale, you multiply by a thousand. We want to go up the scale from megabytes to gigabytes, so we divide by 1000.
157,500 / 1,000 = 157.5GB.
There we go – now we know how much hard drive space our 2 hours of DNxHD 175 footage will take up!
The explanation above should allow you to take whatever number you have (bitrate, file size, length of video) and calculate whichever one you don’t know yet. It’s important to understand why things work the way they do, because you won’t always be able to apply a simple formula.
But hey, we like formulas, right?
So here are the simplified formulas which you can calculate instantly. In these formulas, you need the bitrate in megabits and the file size in gigabytes.
File size = bitrate * number of minutes * .0075.
Bitrate = file size / (number of minutes * .0075).
Number of minutes = file size / (bitrate * .0075).
GB = mbps * minutes * .0075.
Mbps = GB / (minutes * .0075).
Minutes = GB / (mbps * .0075).
Wondering where .0075 comes from? Remember that we divided by 8, then multiplied by 60, then divided by 1,000?
1/8 * 60 / 1000 = 0.0075.
It’s important to note that, if you are calculating video bitrates with this method, you are calculating the average bitrate. If your codec is variable bitrate (VBR), then the bitrate will at times be higher or lower than that number.
How to find out codec information from a file
QuickTime and VLC can both do this very easily, though they only give you basic information. There are a few different tools that can give you a lot of information, but my favorite is MediaInfo. It’s available to download for Windows or Mac here, or you can get it on the Mac App Store for 99¢.
In QuickTime: open the file that you’re interested in, and then go to the menu bar and select Window > Show Movie Inspector, and a window will appear with basic codec information.
In VLC, go to Window > Media Information, and click on Codec Details to view a little bit more information.
In MediaInfo, just drag any clip into the main window, and you’ll see a ton of details about the file. Pretty cool, huh?
If you have any questions or suggestions, please comment away. I will actually read all of them.
And if you’re interested in joining our writing team, get in touch: blog at frame.io.