File sizes for "iPod High" preset

[BradleyS]

I hate to supplement what the other devs have written, but I think it might be all of this "bit" talk that's confusing people. If you have no idea what a bit is, this is for you.

There are 8 bits in a byte.
There are 1024 bytes in a kilobyte (kibibyte, proper).
There are 1024 kilobytes in a megabyte (mebibyte).
There are 1024 megabytes in a gigabyte (gibibyte).
There are 1024 gigabytes in a terabyte (tibibyte).

If your video bitrate is 1500 kilobits per second, and your audio is 128, that's 1628 kiloBITS per second. You can divide by 8 to get kiloBYTES per second, since there are 8 bits in a byte. That's 203.5 kilobytes per second.

Using this advanced wizardry, it is easy to figure out the approximate size of a video once you know its length (bitrate * length, as stated before). If your video was one hour, the duration in seconds is 3600 (that's 60 seconds * 60 minutes). 203.5 * 3600 = 732,600 kilobytes.

Lastly, you might do one last conversion (getting this?). Divide by 1024 to get 715.42 megabytes.

The reason you might end up with a 710MB encode or a 705MB encode, etc., is that the encoder might not actually be able to put exactly 203.5 kilobytes of data in the stream every second. It could be slightly more or slightly less, which makes the resultant file slightly larger or smaller in size. Regardless, the math here is an exact science.

It does not matter whether you are encoding H.264, DivX, Xvid, Theora, Motion JPEG, or whatever. Your resolution is irrelevant. If you increase resolution, you need to compensate by increasing BITRATE. Likewise, when you decrease resolution you can lessen your bitrate.

Finally, an easy way to convert approximate bitrates per resolution. Say you have 640x480 video. Multiply that to get the number of pixels, 307,200. Likewise, 320x240 video is 76,800 pixels. From this, we can conclude that there are 4 times fewer pixels in the latter. Thus, as a *general* rule, it would require approximately 4 times less *video* bitrate (not overall bitrate) to achieve the same quality. Your resulting file will be 4 times smaller in size.

Again, while there are various factors in play that can skew your results slightly, the math here is an exact science, and is perfect for approximations.

Edit: Added tibibyte proper. Thanks jbrjake.

[nightstrm]

I hate to supplement what the other devs have written, but I think it might be all of this "bit" talk that's confusing people. If you have no idea what a bit is, this is for you.

There are 8 bits in a byte.
There are 1024 bytes in a kilobyte (kibibyte, proper).
There are 1024 kilobytes in a megabyte (mebibyte).
There are 1024 megabytes in a gigabyte (gibibyte).
There are 1024 gigabytes in a terabyte (tibibyte).

If your video bitrate is 1500 kilobits per second, and your audio is 128, that's 1628 kiloBITS per second. You can divide by 8 to get kiloBYTES per second, since there are 8 bits in a byte. That's 203.5 kilobytes per second.

Using this advanced wizardry, it is easy to figure out the approximate size of a video once you know its length (bitrate * length, as stated before). If your video was one hour, the duration in seconds is 3600 (that's 60 seconds * 60 minutes). 203.5 * 3600 = 732,600 kilobytes.

Lastly, you might do one last conversion (getting this?). Divide by 1024 to get 715.42 megabytes.

The reason you might end up with a 710MB encode or a 705MB encode, etc., is that the encoder might not actually be able to put exactly 203.5 kilobytes of data in the stream every second. It could be slightly more or slightly less, which makes the resultant file slightly larger or smaller in size. Regardless, the math here is an exact science.

It does not matter whether you are encoding H.264, DivX, Xvid, Theora, Motion JPEG, or whatever. Your resolution is irrelevant. If you increase resolution, you need to compensate by increasing BITRATE. Likewise, when you decrease resolution you can lessen your bitrate.

Finally, an easy way to convert approximate bitrates per resolution. Say you have 640x480 video. Multiply that to get the number of pixels, 307,200. Likewise, 320x240 video is 76,800 pixels. From this, we can conclude that there are 4 times fewer pixels in the latter. Thus, as a *general* rule, it would require approximately 4 times less *video* bitrate (not overall bitrate) to achieve the same quality. Your resulting file will be 4 times smaller in size.

Again, while there are various factors in play that can skew your results slightly, the math here is an exact science, and is perfect for approximations.

Edit: Added tibibyte proper. Thanks jbrjake.

This post reminds me of the first day of my first class in college... one of those good old intro classes they make you take when you start in a CSE program. Ah... memories.

[BradleyS]

This post reminds me of the first day of my first class in college... one of those good old intro classes they make you take when you start in a CSE program. Ah... memories.

Heh. For me it was, "how to explain bits to people without being condescending". Sorta ended up like a class, huh. I could have been a jerk about it.

[Se7enLC]

You people are insane.

A bit is a bit is a bit is a bit is a bit is a bit is a bit!

You can do an encode at a width of 320 or at a full anamorphic width, but as long as you use the same bitrate they will be pretty much the same size, except for minor fluctuations in container overhead.

Code: Select all

$ ./HandBrakeCLI -i ~/Movies/DVD_VIDEO -c 8 -e x264 -w 320 -b 1000 -v -o /Volumes/MyBook/small.mp4
$./HandBrakeCLI -i ~/Movies/DVD_VIDEO -c 8 -p -b 1000 -v -o /Volumes/MyBook/big.mp4 -e x264

<snip>

Results in:

Code: Select all

Khaybet:hb-conan jonr$ ls -la /Volumes/MyBook/ | egrep "small.mp4|big.mp4"
-rw-r--r--    1 jonr  staff    10944453 Jan 29 11:33 big.mp4
-rw-r--r--    1 jonr  staff    10829996 Jan 29 11:32 small.mp4

Yes, I understand that part. We all understand what a bit is. When you specify a bitrate, it ensures that the resulting filesize will be approx the same as any other video of the same length and bitrate, regardless of resolution. And the example you posted proves that quite nicely. That should clear up the confusion anybody else had before.

My question, however, was about the OTHER example. The one where the bitrate was NOT specified. There are screenshots posted that clearly show a 320x200 video with a larger filesize than a 640x480 video. Yes, we've established that it is bitrate and not resolution that defines the resulting filesize. But my question remains unanswered - why is it that the default bitrate for 320x200 is such that it results in a larger filesize than the 640x480 video? The example clearly shows that the only difference in the commandline was the specification of a resolution.

Logic would dictate that if you don't specify a bitrate manually, it should do one of two things:
1). It should use the same bitrate for everything. If that's the case, both files should be the same size, right?
2). It should intelligently pick a bitrate to provide good quality. If that were the case, the larger resolution should have used a higher bitrate, and thus had a larger filesize.
3). I guess since it didn't do either of those two things, it must have decided for some reason to use a higher bitrate for the lower resolution video. WHY?

[jbrjake]

Yes, I understand that part. We all understand what a bit is.

If we "all" understood then Polygon wouldn't have insisted that "that can't be right" and BradleyS wouldn't have felt compelled to turn the thread into a remedial computer science class.

My question, however, was about the OTHER example. The one where the bitrate was NOT specified.

I've ignored it because I can't reproduce it, indicating to me that this is a PEBKAC issue, like so much else in this thread. I just did two ffmpeg encodes at default bitrate, the 720 width one came out at 1158kb/s, the 320 width one came out at 1050kb/s. That's damned close for one-pass in lavc.