how is it that only the bitrate value is affect the filesize

[shimi]

how is it that only the bitrate value is affect the filesize and the resolution not?

[guns1inger]

Bitrate determines the amount of data being transfered to make up the picture (and audio). The higher the bitrate, the more space required. Two movies with different resolutions but the same bitrate will occupy the same amount of space. A lower resolution (e.g. Half D1) might allow you to use a lower bitrate for the same quality, thereby saving you space. The space saving comes from the lower bitrate though, not the lower resolution.

[jimmalenko]

how is it that only the bitrate value is affect the filesize and the resolution not?

Irregardless of resolution, the bitrate tells you how many bits are used to describe any second of footage. The file size is only affected by the bitrate and the running time, since all you're doing when calculating the file size is adding up the number of bits that each second takes up. So Size = Bitrate * Running Time, remembering that 8 bits = 1 byte, 1024 bytes = 1 KiloByte and so on.

Of course, quality can be adversely affected as resolution changes, because you need to use a bitrate that can adequately describe the data, and the bigger the resolution, the more bitrate it takes to achieve the same end quality, all things being equal.

But at the end of the day, the same bitrate on two different resolutions over the same running time results in the exact same filesize.

[DarrellS]

Of course, quality can be adversely affected as resolution changes, because you need to use a bitrate that can adequately describe the data, and the bigger the resolution, the more bitrate it takes to achieve the same end quality, all things being equal.

Exactly.

But at the end of the day, the same bitrate on two different resolutions over the same running time results in the exact same filesize.

I did some tests with VDub/XviD and was surprised to find that the higher resolution files were smaller (8,712 kb) than the lower resolution files (9,028 kb) at the same bitrate (2000 kb/s) and same number of frames (1150). The original captures were 13448 kb/s for the 320x240 and 57515 kb/s for the 740x480.

I assume that the 320x240 files had alot of overhead which is why they were bigger.
I've never seen a 38 second, 9,028 kb, 320x240 file on the internet that looked as good as the one I made.

[garryheather]

Don't forget there's also audio - different bitrates for PCM and MPG, multiple soundtracks in Dolby and DTS, plus the small amount of space used in subtitles...

[thecoalman]

Of course, quality can be adversely affected as resolution changes, because you need to use a bitrate that can adequately describe the data, and the bigger the resolution, the more bitrate it takes to achieve the same end quality, all things being equal.

To elaborate a little more on what Jim said, it's important that you pick an appropiate bitrate for the resolution. There's thresholds where it becomes too little or too much depending on the resolution. If your using a lower bitrate lower resolutions will produce better results. If you use too much at lower resolutions it won't produce a better video just a larger file. For example a resolution of 720x480 should be 4000 to 8000. If you go below 4000 the quality suffers quite a bit, above 8000 and your really not doing much but increasing the file size. Here's some example pics.

720x480 @8000


720x480 @3000, as you can see this produces heavy macroblocking and would be really bad to watch.


352x240 @3000, as you can see the macroblocking has disappearred. The difference is that it no longer has the detail of the 8000 bitrate screenshot.

[vhelp]

Here is another way to look at it..

First, some HT numbers..

1 kb (pixel) = 1 kb
4 kb (4 pixles) = 4 kb
16kb (16 pixels) = 10 kb
64kb (64 pixels) = 64 kb (total of pic below)

Below, is a 16x16 (64 pixel) grid layout.

0000 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000
0000 0000 0000 0000

The maximum bitrate you could use on this (hyper-thetically speaking)
would be 64 kb to encode exactly as original image, and would produce
no macro-blocks in final MPEG. (Of course, in reality, the final
outcome of an encoded MPEG file, will depend on many other factors,
such as ( ie, Encoding: method; internal Algorithems; motion-compensation
Algorithem; Bitrate Algorthem.. ) and many more factors.

Now, say you used 16 kb to encode that 64 pixel grid (resolution) That is not
enough bitrate to cover the whole 64 pixle grid image (macro-block'wise)
when you want to duplicate the image exactly. The image will still look
like it does, but will have macroblocks because it was not enought to
cover the whole resolution - motion compentation adds some +/- to this
as well.

.. in real mpeg specs, a Macroblock is a 16x16 pixel gird, and a Block
.. is an 8x8 pixel grid.. and the bitrate is determend by some factor of
.. how it all gets processed (ie, DCT; Runlengh; etc etc) Somewhere in the
.. encoding process, the bitrate is determined. (I'm still learning the
.. machanics of an MPEG encode process, which include bitrate calculations,
.. etc, and I'm not there yet)

The above will encode with just 16 kb bitrate, for that resolution.

If you were to encode this same grid with 64 kb bitrate, then you would
have the same size file +/- 'wise, but would look better. I think that
the bitrate is like a table that points to the amount of xxx to reproduce
a given macroblock to reassemble itself as closest to the original image.
.
So, whatever bitrate you use, between 1 kb to 64 bk, the size will still
be the same. In a way, you are just filling in the container (64 pixel grid)
with bitrate information on the image to reproduce it as best it can.

(swallow that with a grain of salt)

Remember, I did say, hyper-thetically speaking.

-vhelp 3376