As Chienworks said, the file size is primarily determined by two things, LENGTH of the video and bitrate. IF you can't shorten the video, your other option is to lower the bitrate, which in some cases can lower the quality of the image.

Dave T2

If the render took a long time and you don't want to wait, AND if the project is just a little too large, go ahead and prepare your DVD and then use DVD Shrink to reduce the size.

Guys how exactly do I lower the bit rate?

to johnmeyer:

I know how to use dvd shrink, but that shrinks it to fit onto a DVD using ISO or IFO. I meant that I had an mpg file whose data size I simply wanted to reduce to fit requirements for uploading...

When you have the Render As dialog box open click the Custom button, then click the Video tab. You'll be able to enter custom bitrates there.

Please note ... do NOT place your already rendered MPEG file on the timeline and render from that. Open up your original project and render that again.

I don't know why, but the "Custom" button does not work, no dialog box pops open, for rendering in mpg1 or mpg2. it works for the other extensions however?

>the file size is primarily determined by two things, LENGTH of the video and bitrate.<

There is a third important factor. The CONTENT can have a big impact on file size as well. If there is little change from frame to frame (e.g. computer screen capture) the file size will be smaller. If you have a high noise to signal ratio such as a VHS source, the noise counts as information and the file size will be larger.

Gary

Omar, are you using Vegas or Vegas Movie Studio?

If the custom button does not work, there are two possible reasons:

1) You're using Vegas Movie Studio instead of the full version of Vegas and this is one of the limitations.

2) If you are on the full version of Vegas, check this.

There is a third important factor. The CONTENT can have a big impact on file size as well.

Gary,

I have been reading this for years in various video forums. It is a rather misleading concept.

First, the initial statement I made earlier is still correct: The only thing that determines the size of the final render is bitrate and length. If the encoder is "honest," and encodes at the rate at which you set it, then the final file will have an exactly predictable size which you can determine simply by multiplying bitrate times length, times the appropriate constant.

I just did a test to prove this. I took 10 seconds of solid black and rendered it at 6,000,000 CBR. I then did the same thing with 10 seconds of DV AVI video. The two files were virtually identical (7,484 KB vs. 7,464 KB) **. The 0.3% difference was likely due to the way in which Vegas reports selection times. A longer selection would probably reduce even this slight error.

I then did exactly the same test, except I switched to variable bitrate encoding. This time there was a HUGE difference, with the solid black encode being only 5% of the size of the moving video.

However, this is due entirely to the fact that the Vegas/MainConept encoder is failing to do its job. I am sure that if I inspected these VBR renders with a tool that reports bitrates, the average bitrate for the solid black would not be anywhere close to the Average bitrate that I requested. I could further argue that this is actually a bug, and in fact I think it is exactly that. If my video happens to be cleaner (less noise), why should the encoder arbitrarily assign fewer bits, on average, to that encode? This will result in less quality than what I want.

Thus, if the encoder does its job, and really achieves the average bitrate that you request, there should be no difference in file sizes based on the content of the video. The fact that this is not true when using VBR in Vegas is, I believe, a bug.

** [Edit] I should have included this before:

6,000,000 bits per second times 10 seconds is 60,000,000 bits. Divide by 8 to convert to bytes and you get 7,500,000 bytes, or 7,500 KB, which is within roundoff error of the size file that Vegas created when I chose CBR.

John,

An interesting topic.
I have done quite a few Mpeg renders with Vegas, and I know that it behaves this way for VBR. It would be interesting to see how different encoders handle the same content.

Gary

On the other hand, while we can tell Omar to reduce the bitrate, we won't really be helping him much by telling him to replace all his video clips with empty black frames. ;)

I have done quite a few Mpeg renders with Vegas, and I know that it behaves this way for VBR. It would be interesting to see how different encoders handle the same content.

I think other encoders may do the same thing because I have seen lots of posts similar to yours, namely that if you reduce the noise in your video, you will get a smaller file size.

Hmmm ... I still have TMPGEnc ... let's see what it does ...

OK, first part of the test is done. When using CBR, the two files are exactly the same size, down to the last byte.

Now for the VBR test ... hmmm, TMPGEnc doesn't let you specify an average unless you use 2-pass ... wonder if the problem with my Vegas VBR test was that I only used 1-pass VBR ... this would make sense because the encoder, when encoding the all-black video assumes that something with motion must be ahead somewhere, and therefore encodes at the lowest possible rate. I bet if I had done the test with 2-pass, it would have been smarter ...

Still waiting for TMPGEnc ... it is a slow encoder ...

Well, even with 2-pass, and even with totally different technology, it does the same thing as Vegas, although not quite to the same degree. The all-black is about 14% of the video that contains motion.

But wait, I went back and encoded the DV Video using VBR at exactly the same average VBR as I used for the CBR (I had used a lower setting, out of habit). This time I got exactly the same size as I did with the CBR encode, which in turn was exactly what the math I posted earlier would have predicted.

Thus, the all-black is apparently such a pathological case that it fools both MPEG encoders, but when using normal video, the encoders do what I would expect, namely they always give a file size that is solely a function of bitrate and length.

> Please note ... do NOT place your already rendered MPEG file on the timeline and render from that. Open up your original project and render that again.

I dont understand. If I open my project and just render again, it does the same thing over. If I render it creates a 110mb mpg file. If I open the vegas file and render again it just creates another 110 mb mpg file...

Yes, but you are creating a new 110 MB file from the old one, thus creating a new file that has been compromised by already having been compressed.
Bitrate is everything. Reduce your filesize from the original project/timeline by reducing the bitrate. That's ALL you need to do to make a smaller file. Reduce the bitrate.

Omar, I think Chienworks was concerned you only had a finished MPG file to render from. Hopefully if you are opening up your Vegas project and are using media that it is still contains the original AVI content then you should be good to go. The point Chienworks is making is that I/we should not re-render an already rendered and prepared MPG.

Do you see? can you please confirm that you are using AVIs rather than MPGs as your editing content? I guess your statement that when you re-render you are in fact getting 110mbs of MPG confirms this.

Grazie

Omar, you got the same file size because you didn't reduce the bitrate. This is done by choosing a smaller bitrate under the custom button. If you can't open the custom button then you either are using Vegas Movie Studio instead of Vegas, or you haven't registered your MPEG plugin. Can you tell us which of these is the case?

Do you need to use MPEG? If you are trying to upload a web video then WMV is probably a better choice. You'll get better quality in a smaller file than you can get from MPEG.

I just (re-)rendered a program because the first, default render was too big for a DVD. A specified bitrates given by a bitrate calculator, and my "Customized" render was successful.
I was griping about this to a friend who uses Adobestuff, and he alleges that Adobe (Premiere, I think) automatically selects an appropriate bitrate based on the length of the material about to be rendered to mpg.

Is that really true? If it is, can we have that feature in the next release of Vegas?

DVD Architect already has this feature; it's called "fit to disc". Probably one of the reasons that Vegas doesn't have it is that it can be used to render MPEG for many different purposes besides DVDs. Also, as has been pointed out, videos will substantially little action will often result in much smaller VBR renders so it's difficult to judge the final size accurately.

I did a test using Vegas 4 with 5 seconds of video. The first video was solid red color, the second was VHS wedding footage. Using the same defautl MPEG1 VBR setting, the wedding footage was 1,201kb in size. The solid red was 1.185kb in size. This gives some creedence to the idea that content does affect size.

So MY statement about bitrate and length being the primary affectors of file size may not be totally correct. when using a compressed format such as MPEG. But I would assume that uncompressed or a codec with a fixed compression (such as DV) would only be affected by bitrate and length.

But am I wrong in saying that COMPRESSION RATE (or amount) is not product of bitrate? The MPEG file will be compressed the same amount regardless of bitrate (depending upon the compression software used), the bitrate will just determine how fast the data is transferred. Right?

Dave T2

So MY statement about bitrate and length being the primary affectors of file size may not be totally correct. when using a compressed format such as MPEG.

You almost exactly duplicated my test, but in both cases, we were feeding the encoder a "pathological" case (video that consists of no movement and only one color). It appears the encoder does indeed encode to a smaller size in these circumstances. However, if you read both my earlier posts, you will see that all the other encodes produced exactly the size you would predict by multiplying bitrate times length (and I provided the math in those earlier posts, so you can check the results).

"But am I wrong in saying that COMPRESSION RATE (or amount) is not product of bitrate? The MPEG file will be compressed the same amount regardless of bitrate (depending upon the compression software used), the bitrate will just determine how fast the data is transferred. Right?"

Sorry, you are wrong. ;)

The amount of compression is determined by the bitrate. Bitrate is a realtime thing, not a data transfer thing. If you compress video to 3Mbps then the file would have to be half the size of 6Mbps, and therefore compressed twice as much. This is why lower bitrates look worse and why we try to use the highest bitrate we can in each situation. Otherwise we'd all encode at 28Kbps and save petabytes of drive space and bandwidth every day.

Now, what differs is how well various codecs compress to different bitrates. MPEG results in excellent images at higher bitrates used for DVDs and digital broadcast. It sucks at web-friendly bitrates. WMV is far better at low rates. At higher rates it's nearly as good as MPEG, but seems just a bit softer to me. Even within the same codec, various implementations can do better or worse. A striking example is SONY's DV vs. Microsoft's DV. SONY's DV is amazingly faithful with almost no image degradation at all. Microsoft's DV simply looks awful.

YOu are probably right Chienworks, but the QUALITY of the compressor used does not affect the amount of compression, only the image quality, correct.

So are we saying the the two factors in filesize are BITRATE and LENGTH, since it seems that content (such as amount of noise or video vs. static video source) does not affect file size?

That was my original statement, that the two PRIMARY factors are length and bitrate. Was I wrong here?

Content only becomes an issue when using a VBR, and even then, if I understand Johnmeyer's math, that is a small amount of difference if any.



Dave T2