Math questions

[jgombos]

I'd like to know how to compute a bitrate for a given resolution, source VOB size, and target AVI size.

For example, suppose I have 4.7G worth of VOB content (which was generated using DVD shrink to exactly fill a single layer dvd). I want the resulting Xvid AVI to fill a single 700 MB CD right to the brim. Without scaling the resolution, what bitrate would I set gui4ffmpeg to? Is there enough known variables to solve this, or do I need to figure out what bitrate the source is first?

[mill48]

How about using the Search Tools facility (https://www.videohelp.com/tools) to search for a bitrate calculator? The result of such a search would lead you to https://www.videohelp.com/tools?toolsearch=bitrate+calculator&s=&orderby=Name&hits=50&c...res=&listuser=, and then you could check out the VideoHelp Bitrate Calculator (https://www.videohelp.com/calc.htm).

Search is your friend!

[junkmalle]

runtime * bitrate (audio and video) = file size

[jgombos]

How about using the Search Tools facility (https://www.videohelp.com/tools) to search for a bitrate calculator?
Search is your friend!

It helps to know what to search for. Searching for "calculate" and "compute" and "math" didn't help in this case.

btw- I'm skeptical about the second calculator you mentioned, which is a java app served from videohelp.com, because it does not account for the number of pixels.

runtime * bitrate (audio and video) = file size

How do you get away with neglecting pixel addressability?

[hhhhbk]

get autogk and set filesize to 700mb
it will run the encode
and has hit target size exactly(or 1mb below) 99% of the time

so easy to set up takes about 30 seconds tops
then encode total time will be about 2.5 hours judging by the spec of your pc 2.33ghz p4

[junkmalle]

runtime * bitrate (audio and video) = file size

How do you get away with neglecting pixel addressability?

Because the number of pixels has nothing to do with it.

Suppose you're going to drive 50 miles an hour for 2 hours. How far would you go? Does it matter how big your car is?

[jgombos]

Because the number of pixels has nothing to do with it.

You're definately overlooking something. People would not be producing media files with such puny resolutions if resolution did not affect size constraints. Ever compare file sizes of images with different resolutions? What you'll find is that images with more pixels also take up more space. More pixels = more information. It's the same thing with motion video, only you're dealing with many images.

Suppose you're going to drive 50 miles an hour for 2 hours. How far would you go? Does it matter how big your car is?

You're asking the wrong question. The question is, how much fuel would you consume? If your car is bigger, chances are it will use more fuel than that of a small car.

If you're logic were applicable, you could encode a movie at 16,000 x 9,000 pixels, and fit it all on a CD. You could then store an array of 15 or so movies in that space, and get 15 movies on one dvd. Heck, if resolution can be neglected, I can store every dvd in existence on a single dvd.

[canadateck]

Less Pixels on an oversized canvas look bad.

[junkmalle]

jgombos,

Your original question wasn't asking how to determine the best compromise of image size and bitrate, for a given filesize. You asked "Without scaling the resolution, what "bitrate would I set gui4ffmpeg to?" I gave you the equation that answers that question.

If you compress an hour long 1600x1200x60fps video and an hour 320x240x30fps video both at 1000 kbps you will get 450MB files (excluding audio). The 1600x1200 video will not look much like the source. The 352x230 image will look a lot more like its source.

1000 kbps = 1,000,000 bits per second
1 hour = 3,600 seconds

1,000,000 * 3,600 = 3,600,000,000 bits

divide by 8 to get bytes

3,600,000,000 / 8 = 450,000,000

If you want to know what combination of bitrate, frame size and frame rate will get you the best quality image -- I can't answer that for you. And neither can anybody else. The answer depends on the video in question and what "quality" is in your eyes.

[jimmalenko]

Because the number of pixels has nothing to do with it.

You're definately overlooking something. People would not be producing media files with such puny resolutions if resolution did not affect size constraints. Ever compare file sizes of images with different resolutions? What you'll find is that images with more pixels also take up more space. More pixels = more information. It's the same thing with motion video, only you're dealing with many images.

uhhhh .... NO

The reason why files with bigger resolutions tend to be bigger in filesize is because they tend to have a bigger video bitrate, to allow for the bigger resolution so that quality is retained

As far as the calculation itself goes, resolution plays no part whatsoever. However you need to choose a suitable resolution for your bitrate or a suitable bitrate for your resolution if you want quality video that doesn't have pixelation and macroblocks through it everywhere. By the same token there is such a thing as overkill as well. The Videohelp.com Bitrate Calculator is fine to use, and is a godsend.

If you're logic were applicable, you could encode a movie at 16,000 x 9,000 pixels, and fit it all on a CD. You could then store an array of 15 or so movies in that space, and get 15 movies on one dvd. Heck, if resolution can be neglected, I can store every dvd in existence on a single dvd.

You can, but at 1kbps, I doubt you'd be able to watch them

[jgombos]

I'm not too impressed with the results of these calculators. The best result produced a 650 MB file when the target was 700 MB. The worst result so far was a 559 MB file, when the target was 700 MB.

I can understand that variable bit rates probably cannot be handled with too much precision, but these underestimates seem excessive.

DVD Shrink his the target filesize right on the money every time. I suppose it has the advantage of being able to change the target bitrate on the fly as the end nears. Are there any VOB to AVI/Xvid tools that do that?

[jgombos]

Does anyone know a way to use the results of an unsuccessful conversion to compute a better bitrate? I'm tempted to try a linear equation. ie a bitrate of 1083 produced 559 MB, so I should step the bitrate up to 1356. I'm just wondering if it would make any sense to try to incorporate the original formula in that.

update: The linear equation did not work. I ended up with a 630 MB file.

[junkmalle]

I'm not too impressed with the results of these calculators. The best result produced a 650 MB file when the target was 700 MB. The worst result so far was a 559 MB file, when the target was 700 MB.

It's not the calculators' fault. It's the codec's fault. Are you using the latest XVID? I know some releases of XVID weren't very good at hitting the average bitrate target. And it can sometimes get stuck -- the "Load Defaults" button usually un-sticks it. Of course you'll have to set all the values you want again...

[jgombos]

Are you using the latest XVID? I know some releases of XVID weren't very good at hitting the average bitrate target.

I'm not sure if I have the latest. I know I'm using the latest ffmpeg implementation of XVID (version 0.4.9-pre1 build 4747), but I don't know if ffmpeg is keeping up with the latest xvid libraries. I guess this is a sign that they may not be.

[Abond]

The rate control of ffmpeg is far from accurate especially with 1 pass.

[jgombos]

The rate control of ffmpeg is far from accurate especially with 1 pass.

So what are you saying; I need to add a "-pass 2" switch? What exactly does that do?

update: Bitrate accuracy does not seem to be the problem here. I encoded a file targetting 1356 kbps, and VirtualDubMod reports that the file is 1364 kbps. That seems to be reasonably close to what I asked for. Yet the size is nearly 70 megs less that the calculations projected.

So the next question is - how does VirtualDubMod know what the bitrate of a file is? Does it measure this value, or does it merely trust a (potentially flawed) header value?