Hugeeee File

[Gorf]

Not necessarily true. There are many things embedded into files that have nothing to do with the bitrate.

Not relevant. There are a handful of items in a file header that don't contribute to the bitrate, but they are negligible when dealing with files of more than a few MB. Also, I do not feel that packet information contained within the stream exempts itself from being classed as part of the bitrate. Even though it is negligible in the same way the file header is, at least it repeats itself depending on the duration of the film. You said it yourself:

This is a tiny part of the data transmitted with a MPEG-2 video stream, large amounts of which are optional.

Also - you're confusing the issue by trying to split out the audio bitrate. I didn't, it would be kinder to the OP if you had the same courtesy.

I sometimes wonder if you get your jollies from trying to confuse novices, or whether you really know what you're talking about.

Let me put it this way, you have a 30 Mb file containing 2 minutes of MPEG-2. What is the video bitrate? 2 Mbit/s? WRONG:

1. Is it low level, main level, high 1440 level or high level?
2. Which profile/I/P/B frame macroblocks are used?
3. What is the GOP?
4. What quantisation is used
5. What audio layers are used?
6. Which audio encoding is used?
7. What is the audio bitrate?
8. Is motion compensation used?
9. Who makes the encoder (algorithms change with the maker)?

Why does any of that have any relevance to what we're saying here? For example, why does the algorithm matter? Surely that just affects the picture quality at a given bitrate? What you're suggesting is that a two-minute 2mbps file encoded using ulead's encoder will be a significantly different size to a two-minute 2mbps file encoded using CinemaCraft encoder.

That's just garbage. The quality will be different (I can testify to that - it's why I use CCE) but the filesize and bitrate will be more or less identical.


What you're suggesting is that a two-minute 2mbps file encoded using I frames only will be a significantly different size to a two-minute 2mbps file encoded using a standard IBP structure.

That's just garbage. The quality will be different (IBP frames will yield better quality) but the filesize and bitrate will be the same.


In a video stream, the effect of metadata is pretty much negligible. It's a bit like planning a 100 mile journey without accomodating the extra distance you'll travel because of lane changes or driving over studs in the road.

...Put it another way: if you encode exactly the same clip with three different encoders at the same constant bitrate, you will obtain three different file lengths and they can vary quite considerably.

I fully agree. Finally.

And then when you run those three files through a program such as BitRateViewer, you'll see three different bitrates reported. If the encoder you use is incapable of sticking to the bitrate you request, you need to accommodate that shortcoming when starting the process.

For example, I was getting pretty consistent results with all the encoders I tried, until I put DivX on its highest quality setting. The resulting file was 20% bigger than it should have been. Does that mean the file was full of extra cr*p, or does it mean that DivX did not keep to the requested bitrate, concentrating instead on quality? (For those of you trying to keep up with this rant, it was the latter.)

BTW, did you know that even CBR varies in both bitrate and quantisation? Not much, but the bitrate is typically ¡Ó5-10%.

Yes - I know CBR is basically a narrow-deviation VBR. On most encoders there's a "padding" option that allows you to fill out the data packets if there's not enough picture data to do it.

...I guess what I meant, is that by reducing the frame rate and frame size, you can also then reduce the bitrate without affecting quality too much. These 3 things should all be reduced together to find a happy medium between quality and file size.

Yep - it's a balancing act between all the factors I mentioned - I've had the option of dropping the bitrate way below what I've been comfortable with, or going to half D1 resolution, to produce a wedding DVD. Neither were acceptable, so I ended up spreading the content over two discs rather than edit stuff out.

To illustrate my point, in MSP8, if you increase frame size in the MPEG encoder options dialog, then it automatically increases the bitrate, to keep quality high.

I didn't know that - it's very bad that it behaves that way, because you're left "chasing the gauges" (a flying term).

[troppo]

I didn't know that - it's very bad that it behaves that way, because you're left "chasing the gauges" (a flying term).

Yes, and even more annoying, if you select a large frame size, then select the standard size again it keeps the high bit rate setting. You have to manually change it back again. Also it's on a different tab so unless you look for it you wouldn't notice it had changed. Which caught me out once.
Oh well, add it to the fix list for MSP9, haha.

Nice rant btw

[dabear]

Guys this file size stuff is driving me nutz! I've tried sooo manny times to drop the file says. What do you recommand? It is an mpeg file 211mb. So what setting should I use.

[sjj1805]

Please view:
What bit rate settings should I use?

[Gorf]

Guys this file size stuff is driving me nutz! I've tried sooo manny times to drop the file says. What do you recommand? It is an mpeg file 211mb. So what setting should I use.

Before you read on - think about your basic arithmetic skills: If you can't work out your average speed for a journey, even with a calculator, you're wasting your time reading this. Don't take offence: some people can't.


Just think of file size as distance, and bitrate as speed. The faster you drive, the more distance you cover per minute. If you know how far you've gone and how long it took, you can work out your (average) speed for the journey.

Your file is 211 MB and four minutes long.

If that's 211 MB as shown in windows explorer, then it's actually 221¼ decimal MB (that's the number base used for bitrates). Multiply it by eight to get the number of megabits. Your file is 1770 megabits.

Divide that by the duration - 240 seconds - to get a current bitrate of 7.375 mbps. It's possibly 7 for video, 0.224 for Dolby audio and the inaccuracy is down to the clip not being exactly 211MB and not exactly 4 minutes. It could be 6 for video, 1.536 for PCM audio, who knows - it doesn't really matter at this stage: The reason for calculating it is so you know what's currently going on - it also gives you an idea as to whether or not the bitrate you requested is actually being maintained* in the finished file.

You know your target - 100MB - and you know the duration, so working backwards from that, you can work out the bitrate you need to apply. 100MB is 104,857,600 bytes, which is 838,860,800 bits - or 839 megabits. Divide this by the 240 second duration to get 3.495 mbps.

You should keep the audio at 224 or 256 kbps (0.224 or 0.256 mbps) in case it gets recompressed, which means the video should be 3.271 or 3.239 mbps. Note that these figures are not gospel - you'll definitely need to adjust it to the right duration for the clip, you might want to target 95MB so that you're not right up against the filesize limit (we're all assuming YouTube submission, here). You might also want to allow a factor for the difference between the bitrate you request and the bitrate you get.

Whatever you do with the video, if you want to get that duration in at that filesize, then your bitrate is set in stone. You may be able to make other changes to accommodate quality at that bitrate, but the bitrate itself should not be changed. Be aware - changing some video attributes may change the bitrate setting, so you'll need to change the bitrate back to your target value (thanks to Troppo for that one, I didn't know).

3.239 mbps for D1 resolution (standard DVD or DV) is a bit on the low side - depending on your content you might get away with it if you use multi-pass VBR. If, as we all suspect, you're aiming for YouTube (would you confirm that, please) then you should maintain the framerate and make your saving in framesize instead: Youtube will downsize it anyway, so make your saving there. If your target is YouTube, you'll find their recommended settings here. To be honest, 3.495mbps for 320x240 30fps video is very high. You can probably go much lower than that, you won't notice a significant loss of quality, but you'll cut your upload time dramatically.


* As Brian says, not all encoders maintain the requested bitrate, so you should work it out yourself rather than trusting the program. MSP's MPEG encoder isn't so bad, but DivX pretty much ignores the requested bitrate if you tell it to concentrate on quality. The quicktime encoder doesn't give you the option (within MSP, at least) to even specify the bitrate.

[Devil]

If, as we all suspect, you're aiming for YouTube (would you confirm that, please) then you should maintain the framerate and make your saving in framesize instead: Youtube will downsize it anyway, so make your saving there. If your target is YouTube, you'll find their recommended settings here.

If that is all the OP is after, I stated in an earlier post an easier, foolproof, way that works:

I presume he wants to upload his video to YouTube or similar, with a 10 min/100 Mb limit. I find that it is simple and I've described my OM before on this forum, such as at http://phpbb.ulead.com.tw/EN/viewtopic.php?t=26405 and elsewhere. Many who have viewed this unedited clip have been surprised at the quality from this simple method, which is ideal for MSP8.

I really do not understand what the fuss is about.

[dabear]

I understand what's going on. My target was under 100mb. I didn't see "options" and never really played around with it. So I did a ton of test runs with the best version at 128mb but anything under 100mb really warped the video, Thats the problem.

I got the idea of taking the created video off Msp and loading it up into UVS 9.0 and trying to create a copy off that. It actually worked and reduced the video from 211mb to 46mb with very little quality reduced.

Mpeg1 352x240 29.97fps

So I guess I got it done.

I got bad results off msp with all the settings I was doing something wrong and the encoding was over the target of 100mb the best I got it converted to was 128mb and just couldn't go any lower then that.

I think i should play around some more with the settings get a better feel of it. I'm just a bit fed up after creating like 30+ vids.

[skier-hughes]

Did you use mpeg1 352x240 29.97fps in MSP as well?
What did that come out at?