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

Trying now the same movie, the same script but 1-pass. Let's see what comes out. :wink:

Phil, did you test the commandline I did send to you via PN a while ago for testing? Its very simple and fast (no Trellis etc.).

Using that one I do get much less Quantisation peaks and very well plain/dark surfaces.

Less Quantisation then CCE and even mooore less quantisation then TmpgEnc .... MCE not mention about it! :lol:

Compared to QuEnc well ... Im not happy with QuEnc ... some days ago I did a high avg bitrate test (3500 avg) and mencoder via commandline resulted better .... but that should be a parameter thing which could be easely included in QuEnc by Nic.

But Be aware that there are some mencoder/windows builds that do output more worse files than other builds! Do look at the doom9 thread.

Shure, menocder does output some pts or so errors, but after a simple "restream" Timestamps correcting, EVERYTHING works well in my standalone, even if I do encode interlaced material as progressive! After using restream and the header patch to TFF and "interlaced" ... no probs! 8)

Didn't you said some lines above taht this was a bad option ?

Edit:

@INC
No I didn't. In fact I didn't had any time for. I'm testing MCE because I gave my words to Procoder but this is again on my sleeping time :-(

Are there any difference in quality between 1 pass & 2 pass encodings? I did a small sample right now and thought I saw a little less blocks in the 2 pass encoding but I'm not quite sure :roll: . Anyone else that have been doing comparisons between 1 pass & 2 pass encoding :?:

EDIT
Correction: I must be really tired and my eyes are playing trick on me. I DON'T see a quality difference between the two methods... :banghead:

Yes, but after several tests, I got the same behaviour with "Closed" too.
Maybe Inc's comment about processing the .m2v with restream, is the ticket to the correction :)

-kwag

You're not tired :lol:
There is NO difference :cool:

-kwag

Is ReStream a stand alone program or is it integrated in any program package? Anyways, download locations :?:

(Off-topic
@kwag
Don't you use Skype anymore? I never see you online :( )


EDIT: I found ReStream here:
http://www.sysh.net/restream.html

Do I need to change any setting within ReStream when correcting the video file or do I just open the file and press write?

Alright, tested QuEnc 0.45 once again, this time, same settings but 1-pass... FileSize came about 7% lower than wanted.
I can almost live with that but:

I get bitrate peaks of 9800 kb/sec which is way too much for my taste. The strange thing about this is: it only happens at the beginning after ~1 minute of play-time, after that the Q-Curve stabilizes and also the bitrate curve. Before that, it's like a rollercoaster... :roll:

This is a common problem with ffvfw and this had made me tell some days ago: "and you call THAT a good encoder ?".
Because you're right Jelly, that is a BIG problem.

But as Marcellus explained above, this is probably due to 1-pass mode. During second pass the logic wants that the encoder "smoothes" The Q curve.

I've been away from the computer lately :?

-kwag

It is not due to 1-pass mode unfortunately. The first minute of the movie looks almost identical in 2-pass mode, although the bitrate peaks are not as high. However the Average bitrate is also lower, so I guess that is the reason... :?

As I said, the encoder behaviour for that matter varies very much with the settings in ratecontrol tab. I'm sure that there are not such thing as "optimal settings" that work for every encoding at any resolution, PAL/NTSC, (non)interlaced. That is why I think everybody should be able to tweak his encoder untill is satisfied, so having access to as many as possible tweaks is a must for a good encoder. I tweaked my ffvfw untill I was pleased with the results, so that should be the case with QuEnc too (I mean we should be able to tweak it).

Because I do some encodings on a daily basis with same character sources I made up my mind on some settings that work for me every day (352x288, PAL,~730 kbps, Seinfeld series, black border of 16 pixels). My ffvfw ratecontrol settings are (GOP size: 15, 2 B frames):
-Filesize tolerance: 4096 (default 1024)
-Quantizer compression: 1 (default 0.5) -actually 1 means 100%
-One/First pass quantizer blur: 1 (default 0.5)
-Max quantizer difference: 31 (default 3)
-Use countinous function to limit quantizers within q min/ q max: checked

With those settings the begining is no more so problematic and the q line is stable for long segments, the "rollercoaster" thing is almost never seen. The q line stays (for the source I mentioned) between 2.5 and 3.5. The settings worked well even for 120 - 180 mins movies on one CD but I already mentioned in the post above what problem I had with a particular movie.

So, untill I have with QuEnc the same freedom as with ffvfw, it will not be "my encoder".

Yes, that was the issue with my problematic movie too, even with 2-pass the quantization peaks were still so high that the movie was unwatchable at the bitrate targeted for only one CD. I guess the 2-pass encoding algorithm has even more problems in libavcodec than 1 pass, it eats double time and the results are not as expected (not to say disapointing). An ideal 2-nd pass encoding should have the same q value from the first frame to the last, not only a "smoothed" q line.
bye
marcellus

Nic posted here:

http://forum.doom9.org/showthread.ph...018#post465018

Michael Niedermayer is working on that, let's see where that leads :)


Bilu

Is it important to use trellis? I noticed it slows down QuEnc a little :D :twisted:

@ Kwag

Restream is like a "massage" to the encode afterwards :lol:

@ tickey

It does not count what gives more speed, quality is our way, but ..... I NEVER use trellis and with or without trellis in QuEnc ... I do get better outputs via mencoder even no trellis is activated.

But .... as always .. that could be a build issue??? Ok, I got the latest QuEnc, and Mencoder is from Marcellus MencoderGUI site (It was marcellus or not :oops: ?)

8O 8O 8O
Of course not!!
Try again, I didn't touch Mencoder encoding, much less building or hosting... :? I'm just a simple user... :D
8)

:)

It was Amenophis !!!! :oops:

Thanks 4 the tip.