So try this:
set Qantize values all to 3, and then change bitate 1147 for test one, and 3211 for test two. Do you se the difference in file size? I don't I might be wrong, but file size (for quantizer 3 in both cases) should be almost 3 times larger for second file, right? So why it is IDENTICAL.
From my tests (same sample):
VBV40 (CBR1147) -> file size 6,77 MB (7*106*685 bytes)
VBV112 (CBR3211) -> file size 6,77 MB (7*106*685 bytes)
And the BV "bitratescape" (for landscape ) is identical in both cases.
This is not fake. This are real tests

In fact my way of predicting average bitrate is by changing quantizer values (aspecialy for macroblocks). I think that TMPG uses the same function (adaptive min/max quantizer values) for obtain expected file size, while min and max bitrate values are set sharp.

And this is only one complience. Max bitrate is as encoder wants is to be, same for min (but I dont know how big problem is bad min bitrate value).

__________________
Go for SECAM =)

I think this is where you're doing it wrong.
Leave min=3 and MAX=24 on all the three, and see how ypur filesize differs.
At least mine did.
What version of ffvfw are u using currently?
Cheers

__________________
Rui

I know that when I'll set frealy Q value I'll get differend values, and I do. But for sharp Q value bitrate should be also differend (If we tend to cal this "bitrateslider")
Im runing 27.09.2003, as for I've readet it is last "bugless" (and fastest) build.

__________________
Go for SECAM =)

@Hydeus: Obviously you didn't took the time to read carefully my early post, like Rds_correia did. I know it's hard, being very long, but I don't think it would be a waste of time.

To cut it short and taking the chance to sound like a broken record, basically my point of view is that Milan put a smart algorithm in it's program to make a "constant bitrate" encoding. That algorithm relies on having free the max Q values, so it (the algorithm) could decide what q value will use every second. If you mess up with the max Q value you take that decision in your own hands and you have to make some tweaking at every encoding to obtain a certain bitrate, trying to make FFVFW work like Tmpegenc.

If you follow my method I strongly believe you will obtain every time a file with a medium bitrate identical or very close to what you set in the "constant bitrate" box. As I learned from RDS, if that file is or not playable on your player is another story. On mine it plays fine, on anybody's here it seems the opposite is true. So, check your luck.

Obviously, beside that cool algorithm of "constant bitrate" encoding and beside the cool encoding core based on ffmpeg, Milan forgot (or didn't finished it) to put in FFVFW another cool routines (I refer to VBV/Max bitrate stuff) that could make this encoder what everybody will ever need in matter of mpeg2 encoding.

With frienship
marcellus

Hi guys,
I completly subscribe Marcellus point of view and this is easily proven if you leave the
quantization values min=2 and max=31 and "have a ball" with the constant bitrate slider.
Mind you all that this procedure leads to unpredictable max bitrates and vbv buffer=7 or something similar.
The other option is using Karl's method of using min and max quantizers with the same figure (i.e 3 or 4) and use a fixed constant bitrate value with the slider that can produce standard vbv values.
Either way we still have problems...
Somebody ever emailed Athos from doom9?
Maybe he could give some help.
I sure wouldn't like to give up on ffvfw so easily.
Even because we have no other choice at the moment.
Maybe mencoder but it's still early to say something about it.
Cheers

__________________
Rui

Obviously I did

Ergo -> I get predicted (from bitrate) file size.

I know that your way works. I've tested this before, but it didn't satisfy my, while I don't like large quantizer values in smal resolution movies, cause picture streched in large TV screen will look like "Fashion TV" (if you have seen this). A large amount od blocks, and a do not like this.

Conclusion: You have your way, I have mine.
But still don't know why encoder (of any kind) does not respect bitrate with sharp Q value. I've tested this on XVID (min/max q=2) and for bitrate 700 and 1400 I obtain same size files

EDIT:
I "feel the pulse" of ffdshow development, provided by Andy2222 (Milan's co-developer of ffdshow). I've asked him if he plans ffvfw development in future, but on this time he is very busy with ffdshow. There is a slight possibility that he will start ffvfw development, but it could take some time

__________________
Go for SECAM =)

I'm sorry if I offended you. Perhaps I was overreacting.
Well, you can't eat a cake an have it!
The quantization is what encoder is using (along with DCT and motion estimation, I'm not an expert) to compress the movie (i.e. to reduce the amount of information that describes a frame). If you have a specific constant Q then you will always have the same medium bitrate for a specific source independently on what you set as bitrate value, since you don't let the encoder to compress "more" or "less" (read "to rise or lower the Q"), as it would need in order to reach a specific bitrate.

Bye
marcellus

Yes, I see now, that bitrate value/slider on encoder, also determines quantizer value. But I've always thought that bitrate is bitrate: if I want to get 1GB/s CBR, and swarm my 80GB disk with 80 sec movie, it is my business But obviously algorithm want to prove that "he is" very smart, and can free my tired HD drive

__________________
Go for SECAM =)

I hope I solved non-reachable images issue, I signed for a free site at tripod. I updated the links in my posts
Bye
Marcellus