Well, that's not bad at all :!:
Considering there was no prediction used at all :D
On my KDVD encode (Red Planet), the file size was about 30MB lower. Still, that was about 2% off from the wanted file size, and I'm happy with that. :cool:

-kwag

@kwag
You're absolutely right, that's not bad at all :D
But since I wanted to pack the CD-R to the limit I usually use the afore mentioned multiply trick :wink: But hey, that's just me.

To get the real average bitrate, don't trust Bitrate Viewer :!:
Drag your MPEG over to Vdub. and there, check the file information.

-kwag

Are you using 2-pass VBR???

@VMesquita
I am NOT using 2-pass, but I don't know what's best/recommended...

BTW What is Trellis Quant?

From the docs:

"Trellis searched quantization
This will find the optimal encoding for each 8x8 block.
Trellis searched quantization is quite simple a optimal quantization in the PSNR vs bitrate sense (assuming that there would be no rounding errors introduced by the IDCT, which is obviously not the case) it simply finds a block for the minimum of error + lambda*bits. Lambda is a qp dependant constant Bits is the amount of bits needed to encode the block Error is simple the sum of squared errors of the quantization "

Edit: Simple, eh :?: :lol:

I also used 1-pass.

-kwag

I don't see how 1-Pass can give high quality and still hit the filesize right on target. :?: Because if the movie has low action areas and high action areas, seems to me that the best the encoder will be able to do is:
a) found a high action area: use more bitrate for a small while. But if the action area is a bit longer, drop bitrate since it will deviate from the bitrate asked.
b) found a low action area: use less bitrate for a while. But if the low action is longer, high bitrate again so it doesn't deviates from bitrate asked.

Visually, this makes the movie look like stuff encoded with those old MS MPEG4 codecs. All I am saying is theory, please remeber. :wink:

After having read your previous post, I did my first try with QuEnc and I obtained a video right in the target in 1-pass.
So I think Kwag is right : do not trust Bitrate viewver to obtained the final bitrate.

I didn't use Bitrate viewer to calc bitrate, I did it manually. :wink: It's a 98 minutes movie, I encoded at 976 kbps, so I should have a file of 700 Mb... Instead I got a 521 Mb file... Very wierd, uh?
But did you like 1-Pass quality? I still have no idea about how it can work as I explained in my last post. 8O

Actually I just did a qucik test to compare to MCE and TMGPENC.
All I can say is : QuEnc has big problems on flat areas (big DCT blocks) and I will never use MCE (tooooo much gibs) !

I'm currently looking for a convenient way to post side-by-side comparison snaphots to show you all this. I'm not sure that using JPG will be good. Png is too big (> 500 Ko each snap) :-(

Dialhot, are you using MCE or QuEnc?

As I told you, I did a quick test with QuEnc in order to compare it with MCE and TMPGENC. I was doing an encoder comparison test for Procoder64 so I thought "why doing 2 when I can do 3 ?" :-)

Now I understood.... Sorry. :oops:
Wouldn't blockbuster noise help? Have you tried trellis quantization? :?

Phil,

This was probably at low bitrates, right :?:
Because QuEnc at averages above ~1,500 looks extremely good :!:

-kwag

@Kwag
I did a KDVD at 1800 Kbit/s. Perhaps not enought for a DVD resolution, but I try to compare encoders : I do not need to have perfect picture on all ! That's on purpose that I give them few meat to chew :-)


@Vmesquita
Blockbuster surely help. I used the same script for all of them of course in order to compare the results.
And yes, I used Trellis.

I don't know about QuEnc but I often check the ffvfw feedback graph during encoding and periodically throw the partially encoded m2v file in BV to see how it "evolves". That way I learned that ffvfw (and perhaps it's the same with all ffmpeg encoders) have a very smart algorithm for 1 pass encoding, that it's alike with (but not quite) your method. You can read my findings in this old thread:
http://www.kvcd.net/forum/viewtopic.php?t=9191&start=0
Basically, the encoder compares permanently the "so far" obtained medium bitrate with target bitrate and acts consequently rising or lowering the quantization, with some latency.

Although it usually gives good results, the algorithm is not working every time. Because it compares the target bitrate with "so far" medium bitrate, the more material is encoded -> the less effect in changing the "so far" medium bitrate has a sudden higher motion part -> less quantization variation -> good quality. But if a high motion section occurs at the beginning of the movie -> the quantization rises a lot -> bad quality.

I remember a movie with not very high motion overall, but with a high motion battle that occured in min 6 or 8 -> quantization rised like hell to 10 or 11 (although stayed at 2 almost all the rest of the movie) -> unwatchable (and undersized also) -> I ended up with that movie on 2 CDs, with a higher target bitrate. (I don't remember why, but even 2 pass didn't work as expected).

Now, you can control the behaviour of the algorithm with the settings in the rate control tab (in ffvfw) - actually it makes a lot of difference. I'm sure that QuEnc uses some similar settings but I'm not sure that they are optimal (since we can't see them). With ffvfw I usually obtain constant q lines on large sections of encodings, with QuEnc -never, so, since I've seen in doom9 QuEnc thread that you are not alone obtaining undersized files, I blame the default settings of QuEnc for that.
bye
marcellus

Yep, you're right marcellus :D
Your explanation is exactly what's happening.
For sure, if anyone want's 99% file target accuracy, then the only option is 2-pass.
I'll have to give that a try :cool:

-kwag

Alright. Testet QuEnc .45 today, and here's my result:

High Quality checked, 2-Passes checked, Trellis checked, closed GOP, Bitrate 2350kb/sec. 704x576 resolution 25fps...
Output: MPEG-2 w/ KVCD-Notch Matrix

Results look rather bad, I can clearly see the big DCT blocks in low detail areas, Phil talked about.
This actually might be due to the fact that the encoded file is way undersized. According to VDub, it has 1701kb/sec, where should be 2350kb/sec...
Note: This is with 2-pass used

Could it be due to the number of B-Frames I used (standard 2)?
@kwag: what kind of settings did you use to get those accurate results? :roll:

I actually used 1-pass :!:
Trellis+Notch+VBR+High Quality
2 B frames
Open GOP

-kwag