@ bilu,

I commend you on your willing/desire to forge ahead in the things of MEn and
best encoding param setup etc :!: :!:

I have not given up on MEn (or my own gui app) but I've ben very busy w/
my other love hobby - laserdisc movies.. since I got my Pioneer CLD-V2600,
it's ben pretty busy for me, among other things :)

I just wanted to thank you; inc; .dot and others here, for contributing non-stop,
for the last few months now :mrgreen: - - great work from you all :!:

Just some long overdue pep-talk and pat on the back for you all, hehe..
-vhelp

bilu,
what do you want to happen when setting vqmin=1 and lmin=2.49?. I didn't test that yet, all my test where done following the "official" way, with lmin <= vqmin. And what I've noticed is that vqmin=2:lmin=1.8 makes Q value keep closer to 2 than without lmin; and vqmin=2:lmin=1 makes Q almost constantly 2, but keeps raising when bitrate raises too much. From my tests, I guess that vqmin=1:lmin=2.49 will make Q value stay above 1 almost all the time (around 2 maybe?). Did you test with and without lmin?. Please, report your bitrate and Q values, and how looks the graphic.
I again advise you (if still didn't) to test with vqmin=2:lmin=1.5 I'm quite satisfied with results I get, along with bitrate=9800.

Related to adjusting final file size, I have some ideas. With other encoders, we just adjust CQ/Q value, knowing that if we go under 60/40 we'd better change resolution or filter more the image.
With mencoder we can play with vqmin between 1-3, but 1 maybe makes filesizes too big to fit 2-3 films per DVD-R, and 3 maybe is not that good. But I think we have three ways to adjust final size:
- vbitrate and/or vrc_maxrate. Changing vbitrate alone doesn't make much difference, until you go a lot down, and... blocks. changing vrc_maxrate=vbitrate=8000, 5000, 4000 makes more difference, but if too low also... blocks. I tested this way, I would like you also tested. But this is not the way we used before. If mencoder 1pass respected vbitrate, it would be very useful for accurate file size prediction, but it doesn't.
- scplx_mask: we can work between 0.099 and 0.299 (and bilu reports good results with 0.4 and vqmin=1, I didn't test). Well, it's like when we filtered more the video to reduce file size. If not too blured, it may be a way.
- vqmin, mbqmin, lmin: I think this is the way. But as I stated, vqmin and mbqmin doesn't give too many chances to play with (I would stay in general at 2, and in certain circumstances at 1). Maybe if they allow fractional figures for Q value... So maybe lmin will help. I'm going now to make several tests with vqmin=2 and lmin=1, 1.5, 2, 2.5, 3, and will report what happens.

And, of course, as we know how every parameter affects the encoding, we can use altogether. Bt it would be better to find a stable set of parameters, and just 1 or 2 to afjust final quality/size.

I will also test maestro incredible matrix.
And maestro bilu, you did a nice set of tests, I will give lmin>vqmin a try (man_page isn't always write, at least for us :wink: ) and see if it helps in adjusting file size. Using vqmin=1 is good since, if needed, mencoder can go down close to 1. And lmin>1 can help to keep Q the majority of time over 1. In your results I see that, even with vqmin=1, your avg Q value is 4.66. Maybe you'd better redo your tests with a more "normal life" source, because quantizers are high for your settings, and maybe is due to your source.

Finally, I think we can keep at vqcomp=1: is giving us good results, and if we introduce another value to adjust... :roll:

EDIT: sorry for this too large post. I was thinking while writing, and got too big :oops:

bilu, kwag,
I'm mencoding know with a Cygwin compilation made by Amnon ( :roll: ), that didn't come with installer and all his usual things... Just compressed in an ace file.
Is working fine for me (I didn't try yet to mencode directly from vob... I'll test).
EDIT: already running with a vob... and it runs like hell (13-18 fps), withour cropping, just autoaspect...
EDIT2: wow, buff, pheeew, oooohhhh yeah. When cropping: 30 fps!!! (to tell the truth, the source is matrix reloaded, dark scenes, but... buf)
If we could load avs directly, and get close to this speed... even in my turtlespeed PC.

WWWOOOOOWWWW 8O
I just tested the latest CVS ( I compiled it myself, but on Linux ) and WOW 8O
This thing blows away everything I've seen 8O
Now I see why people are so frantic about mencoder :lol:
I'm going to keep trying to get a Windows compile wiith Mingw.
In the mean time, I think I'll be FTP'ing some of my VOBs to my Linux machine, and doing some test encodes :mrgreen:

-kwag

Downloading the last official CVS build:

http://www.mplayerhq.hu/MPlayer/rele...CVS-040403.zip

Will see if this one also crash :?

EDIT: It works,uploaded a stripped version with just mencoder and the man page to http://clientes.netvisao.pt/bilu/bru...er20040403.zip

Bilu

I always got blocks on dark scenes when Vqmin was set to 2 as 2 is still very quantizing on veeeery low bitrate scenes like underwater ones. Thats why I got vqmin=1 working very well. I everytime got my prediction by changing Vbitrate=xxxx only. Yesterday I did an encode of K19 DVD source which ended up fantastic BUT as I did set Vqmin=3 this decision was very bad as this caused mega high bitrate peaks like 16000kbit which I never had before 8O
Maybe the movie or something othe I did set different. I did recognise that if a looong dark/low bitrate scenes changes fast into a mega complex one ... the delay or fading to the correct bitrate or Q isnt done well, seems like the encoder gets "panic" and "tries to run above to get away" ;-)

In mpeg encoding speach, less Quantization at high action/complex scenes means much higher bitrate to keep same quality and thats exactly how behaved MY mencoder build.

So I will test the latest mencoder build posted by bilu (or do you got a diff. Version KWAG??) and do the tests on Vqmin=1 and Vqmax=5 or 8 which should do keep the bitrate curve in its senseful areas.

I did some tests on XVID today where the quantization thing is meant the same ...... and bilu, Im going to test your new parameters this week as I still got much to do at the office :(

I haven't played with mencoder for a while but I decided to try this latest build Bilu posted.
I am using this settings.ini
Since I am encoding an AVI, I used some resizing and filtering:
Even doing this, mencoder is very fast. 34 fps in my Atlhon 2000+, and I am not even using the CPU specifib build. (I remenber that CPU-specif build used to encode 10% faster) I think it's much faster than when I tried a while ago. And looks like all the wierd error messages I used to get that made some frames be dropped and caused audio desynch is gone. Let's see how it comes out. :D :D :D :D

bilu, I change mencoder.exe in mplayers folder to your provided above one, but ...

when the bat file opens the logfile while processing the whole report does contain that

"MEncoder dev-CVS-040326-12:20-3.3.1 (C) 2000-2004 MPlayer Team"

is that correct??? 04 03 26 ??

@incredible

I'm not at home now so I can't confirm.
Better to download the version from the mplayerhq.hu site and compare yourself :roll:


Bilu

@incredible

Yes, that's the version contained in the downloadable package. :D

With the last command line posted here I cant do any correct vbitrate determination anymore .... :(

I settet it back to my command line and the settet vbitrate=xxxx gives me almost the wanted output (means still prediction by adjust. Vbitrate)

Can you try your settings but with vqblur=0 to see if you can aim at a certain bitrate?

And could you try my last command line but adding :naq=1 in the settings.ini file?


Bilu

It's nice to see more people involved in this mencoder thing... :D

vmesquita, related to vbitrate, I advise you, if you think it's of interest, to try also vbitrate=9800, and later, vbitrate=3000. Since with mencoder 1pass, by now, we cannot make use of vbitrate to set final average bitrate, use it just as a "tendency" for mencoder. In my tests, never was respected at all (again, just in 1pass). I did most of my tests with vbitrate=vrc_maxrate=9800, and looks to me that mencoder raises bitrate whenever needed faster than when vbitrate<maxrate (don't know if it makes sense, but these are my results).

bilu, did you drop p_mask=1?, do you think it doesn't help at all?.

kwag, could you put a link to your compilation, or is it just working on linux?

Well, after all the excitement looking at mencoder encoding at 30 fps... it was an error :( :( :cry:
When encoding, I realised it gave a message about video encoder being DIVX (!!??). And later, when I tried to load the file in BitrateViewer, it said it wasn't a correct stream. When trying to play in PowerDVD, it hung.
Is it a bug?. I was encoding from a vob, with aspect=16/9. When I reencoded with autoaspect, it encoded well (but at 10 fps :( ), and in PowerDVD aspect is 4:3 (egghead) !!??
I redid the test with a different vob from a different film, and with aspect=16/9 encodes with a message about DIVX, and doesn't seem to be a mpeg stream, and with autoaspect encodes well, but in 4:3 aspect.
Again, is it a bug, or just that vobs must be encoded with autoaspect?. And if the last is true, how do I say mencoder to encode in 16/9 aspect?.

It's for Linux only.
This beast behaves different on Windoze :!:

-kwag

@digitall.doc

My testing method is a bit like the Lagrange Multiplier concept: imagine a graphic of quality/bitrate being like a circle, X axis being bitrate and Y axis being quality.

At 45 degrees you'd find the "best bang for your buck", i.e. quality wouldn't grow as fast from that point when you'd increase the bitrate.

My point is this: aim at the lowest possible bitrate needed to get an acceptable quality. Then when you have bitrate to spend, you'll know which values you can mess with to get the best possible quality for that bitrate.

I don't pretend to use it like this on real encodings: it's just a learning base, trying to stretch Mencoder to it's acceptable limits.

This is the best way to be able to take the maximum advantages of the available bitrate and to learn about Mencoder's behaviours.

The underwater scene I've been testing is very sensitive: it's taken from the intro of "The Abyss", you see only the blue underwater and then slowly a submarine starts to appear. It's really good to test gradients, better than anything else I've tested. The clean anime stream is good to study the ringing effects of certain testings.

Trust me, this is not my final word ;)


Bilu

I ended up with my last posted line better so or so :?
(BUT bilu Ill try to test your last hint accord. to the command line again! :) )

AND!!! I found out that the diff mencoder builds do output diff. qualities!

Look here:
(Same!!! Line used 1500kbit for testing ... exact same parameters but on the build I used till now and the new one posted at this page of the thread)

Much more sensible in case of low bitrate areas where it should rise the Q. the result is more blocks on dark and plain surfaces.

http://www.digitalfaq.com/archives/error.gif

Well, here are the results of my last tests.

I'm using Mencoder dev-CVS-040401-06:00-3.3.1 build, compiled with Cygwin.
The sample is the 4th vob of Matrix Reloaded film (it lasts about 9:29 min). Loaded directly, no filter, just crop and expand.
My command-line:
And my settings:
I know they are a little different (not that much) from what is being posted, but I put strength on quality. The problem is that maybe will be a little confusing in the end with so many different settings. But as I'm satisfied with my results...

With this test I aimed: 1. test the incredible/bilu approach of lmin>vqmin. 2. see if through lmin I could adjust quality/final file size (like when we set CQ or Q in traditional encoders, and just forget about the rest of parameters...)
I want to keep quality as constant as possible (but not with a linear Q), and let bitrate vary as needed related to image complexity...

Well, the results:

vqmin=2:lmin=1
=============
File size: 257376 Kb
Bitrate: max 8097 avg 3616
Q value: max 2.57 avg 2.06
Q graphic: almost flat, stuck to 2, but sometimes raises.
Visual: a m a z i n g !

vqmin=2:lmin=1.5
==============
File size: 187359 Kb
Bitrate: max 6339 avg 2631
Q value: max 3.20 avg 2.49
Q graphic: varies between 2 and 3, with tendency to 2.

vqmin=2:lmin=2
==============
File size: 148882 Kb
Bitrate: max 5165 avg 2090
Q value: max 4.08 avg 3.21
Q graphic: it keeps around 3, but seems to raise easily when needed.

vqmin=2:lmin=2.5
==============
File size: 115904 Kb
Bitrate: max 4093 avg 1627
Q value: max 5.26 avg 4.29
Q graphic: varies between 4 and 5, with tendency around 4.

vqmin=2:lmin=3
==============
File size: 103841 Kb
Bitrate: max 3595 avg 1458
Q value: max 6.19 avg 5.12
Q graphic: it oscilates a lot, going down to 4.5 and up to 6.2.
Visual: not good, in quiet scenes I can see some blocks. Didn't finish visualization.

My conclusion, to sum up, is that lmin can help in adjusting final size/quality (even better if it makes difference with second decimal number, I'll test) the way I think is better: adjusting final Q value. Of course bitrates varied from test to test, but related to Q values. And, in order to predict file size, we'd have to keep making slices...

I hope you'll find this of a help, and your comments will help me.
Cheers

I did a test on a sliced() video and still there's some kind of reaction delay issue??!. (maybe becuase its just a fast scene changing sliced input?!)

As you see in most cases the Q curve behaves as I want = less quantisation on low bitrate scenes like underwater ones and therefor in relation higher Qs on high bitrate scenes where the picture is more complex and where you wont notice a jump to Q=3.

Thats all IMHO :)

http://www.digitalfaq.com/archives/i.../2004/04/2.jpg

bilu, you're a really good "explainer". Many times I thought that your settings aimed to determine the effect of a particular parameter, and now I see I was right.
Sorry me but, even you gave a really good explanation, I didn't understand it at all. I understood you want to fing the minimum bitrate needed to get acceptable quality... but you will find it in the context of many other settings (with which we feed mencoder), so you won't really know if the effect you get is really just due to bitrate... And if I don't mind a lot about bitrate, it's because I leave it free, between min=300 and max=9800, and just tweak the rest of parameters, to adjust the quality.
But I'm not an expert on this matter (even I'm the worst pupil :lol: ) and I'm sure wrong.

Did you see my results?. Make me know what do you think... don't be cruel

@digitall.doc

I'd like to see if naq helps making predictable filesizes :)

I didn't abandon p_mask=1, I'll retest the underwater scene with it when I get home. May improve over vqmin=1.

I've made tests over that 35 sec underwater sample all morning and last night until about 4 am. I allways tested lmin without using scplx_mask, and lmin=2.49 was the highest acceptable value, 2.5 was too much and looked completely different and much less sensistive to light variations.

I'll retest with p_mask=1, I'm sure it will help.
To improve quality the best option (on my settings) is to reduce scplx_mask and add p_mask=1.

About your tests I had made them all, just didn't keep records. :)
In this point of testing the video would speak louder than filesizes or average bitrates, it would be better to upload videos than those values.


Bilu

incredible,
sorry me if I'm wrong (I'll sure be), but in the graphis, each line means 1 Q value, but 1000 Kb. So, when bitrate drops below 1000 Kb, Q should be 0 to be under... I think you're right that we can use this visual aspect of Q under bitrate as a general guide, but I also think Q can go over bitrate, without meaning bad quality. Again, I'll be sure wrong... :roll:

Anyway, if you read my last test result, for vqmin=2, I got almost always Q below bitrate with lmin=1 or 1.5. And they were my best results.

It doesn't work like that :D
My testing samples have been small (between 2 and 7 minutes) so the average bitrate is meaningless here. It's the resulting bitrate and quality of the tested settings that matters to me :)

Bilu

You already did them?, I wasted my time :(
And, yes, you're right, better see the resulting videos. But if I cannot upload a single image capture, imagine a video sample... :wink:

You'll see that vqmin=2:lmin=2.49 still behaves like lmin=2.
But with vqmin=1 it will look better and the filesize won't grow ;)

I imagine that using p_mask=1 it will look even better :D

Bilu

Q should not only base on the low bitrate count as you said like "1000kbit"!
IF the bitrate goes very low and I do set a determined "border" using VQmin=2 ... then the quantization is much too high for these underwaterscenes as it will be kept at 2!, means there WILL result blocks (in all my tests).. So as you can see in most parts of the graphic its working right, means the lower bitrate also lets drop the Q to about 1.5 which is really recognisable! ;-)

Hi guys!
Has anyone heard anything about the re-writing of the bitrate control yet? (It was the rate control they were gonna change, right? :roll: ) Looking good fellas. Very interesting info you're sharing with us here!

@bilu
Do you have a sample we could download - just to see the quality? I'm VERY curious! :wink:

Not at home right now :roll:

And I don't have the space for hosting it :D

Why don't you try my settings on a sample? ;)

NOTE: my settings are not quality-oriented but "acceptable quality vs bitrate" oriented

Bilu

@bilu
I sure will try. I haven't had any luck with getting MEncoder to work so far :cry: . I'm no computer wiz but I'll keep on trying. I'll even rip the intro scene from The Abyss to use for experimental sample! :)
Newbe alert :arrow: I just copy the bat and ini steeings you posted earlier, right? I must be missing something since everybody else seems to be able to use MEncoder... What compile do you recommend for me to download?

Download this one:

http://clientes.netvisao.pt/bilu/bru...er20040403.zip

Bilu

Thanks. Downloading right now...

About the *.bat and *.ini files:
What setting shall I use here? Please forgive my ignorance but as I said earlier; I haven't had much luck so far - with MEncoder that is.
Sorry to be a pain in the -BEEP- :oops:

Hmm, no luck yet...
This is what I used:

abyss.batI have my fake avi in the same folder as MEncoder

settings.ini Do I need to delete the linebreaks somewhere in settings.ini?

When I start the abyss.bat a DOS window pops up and a bunch of text scrolls down then the windows disappears. It goes by so fast I don't have a chance to read anything in the DOS window... What am I doing wrong? :cry: I really wanna test this encoder, believe me.

EDIT: I managed to see something about a config file that couldn't be found but I don't know were the file is supposed to be located or what kind of file it is... :roll:

Ok, I finished my encode.

The idea of using temporal noise for AVI was not good, the temporal noise became even worse dancing blocks. I am trying now with gaussian noise, looks much better. Also for AVIs, the internal post-processing looks very good, much better than denoise3DHQ (to remove DCT blocks).

@digitall.doc
Looks like vbitrate=9800 makes the encoder use more bitrate, but I still don't know the effects quality-wise... Very good idea using lmin to make a CQ like prediction. :D

Oh, man... This was really complicated. I have read the newbie guide to MEncoder but guess what - I still can't make it work! Could you gurus please help me finding out what's missing? I really hope so. Here we go;

1) I downloaded MEncoder from the link bilu posted - "mencoder20040403.zip" - and unpacked it to "D:\DVDRip\MEncoder".
2) I downloaded "mencoder_avs.zip" and unpacked it to "D:\DVDRip\MEncoder" - same folder as MEncoder.
3) I copied and pasted bilu's settings.ini and saved it as "settings.ini" to "D:\DVDRip\MEncoder".
4) I have made a fake avi and saved it as "video.avi" to "D:\DVDRip\MEncoder" (It's a clip from the NTSC version of "The Abyss").
5) I used this for *.bat:No line breaks...
6) When I run the *.bat file a DOS window pops up and then immediately closes. There's text in the window but it all happens so fast I can't see what it says...

I hope this is all the info needed to be able to solve my problem?
Thankful for help.

Open a DOS window, go to that directory and run that command.

This way we can at least know what is the error message :)


Bilu

@ Audioslave
Add the mecoder Path to your systems environment variables in the system settings window of windows.

Explained here:
http://www.kvcd.net/forum/viewtopic.php?t=9093&start=24

Well vmesquita, I don't know if this is the right way, making mencoder use every bitrate is needed without a limits (in fact limited to 9800). I think bilu is going the other way, and sure he is right. But this approach is giving me very good results for KDVD encoding. Of course, when talking about SKVCD or KVCD, we should go other way, but for KDVD...
I have a doubt: if we want mencoder output better quality, do we set lower quantizer values?. With lower quantizer values, what will the tendency of the encoder, to raise or lower bitrate?. Thinking on this is why I let mencoder raise whatever it wants bitrates, in order to keep as much quality as possible. But, again, I'm no expert in this matter, and I'm sure wrong. But didn't find yet a better explanation.

I'm happy I got a reaction to my tests!. I was begining to think it wasn't of interest for anybody :( . As you see, keeping the rest of parameters without change, I did get different final filesizes and quality files. For a vob that was 468350 Kb I got a file size range from 257376 to 103841... but lmin 2.5 and 3 wasn't that good, and maybe would need some changes else. I still think that, once we get a set of good standard parameters for KDVD, we can adjust file size through lmin.

@incredible,
I'll redo the tests I did, but now with vqmin=1 and lmin between 0.5 and 2 or 2.5 to see the results. I agree we should let mencoder the opportunity to go down to 1 when needed, but I don't know the way to do that, since the majority of times a Q value of 2 will be enough. But I'll do tests with vqmin=1 and see quality and filesizes.

@bilu,
But it didn't, bilu, my friend. lmin=2 looked better than lmin=2.5, and related to filesizes, bitrate and Q value, you saw my results...

I'm begining to worry that with different compilations, we are getting different results...

Well Digi.Doc ...

As I said EVEN when using the build I do use ... at Vqmin=2 blocks on very low bitrates liek underwaterscenes do appear as "maybe" in mencoderspeach a quantisation of 2 already does its job too deep ;-)
Another approach could be a new Matrix where low frequencies will be almost "untouched" means veeeery less filtered.
Im very shure that mencoder does cry out for a special "mencoder egoistic" matrix as he behaves totally different then TmpgEnc or CCE!
He does Quantize in average veeeery less (seen as values) but at very low bitrate scenes he likes to punch the quantisation (no matter if Vqmin is set to 1).

But you have to say mencoder that he has on exactly these scenes to lower the quantisation ... which works as you see in my pics above, not continously but its an approach. And exactly thats what (to me) makes mencoder amazing.

Sorry if I didn't test your parameters till now, cause with my settings I can just use Vbitrate to determine (almost) final average bitrate ... and in 80% of cases it really matches 8O ... bu anyway ... a prediction is obligatory ... as Vmesquita also mentioned that in here as NO encoder knows what will happen in further treatments of the movie ;-)
But as I said, this Weekend I got my first movie where a Bitrate Peak-Juuuump happened! So my settings wheren't optimal ... yesterday I did set the Q between 1-8 (before 1-3) and a Vmax_bitrate used at 8000 I did change to 5000kbit, .... today I will let encode that stream again and lets see how it will behave.
For me its logic ... the encoder did encounter a very complex scene, the reaction delay got crazy and only was to be allowed to rise Q till 3 means therefore a Veeeeery high bitrate resulted to keep that Q edge of 3.

Well I do my "K19" Encoding again as this seems to be a very "sensible" one for mencoders engine.

According to quality still I do keep my old version of mencoder but on the other hand I cant encode in m2v directly without that nonsense space needed demuxing way :(

Try 2.49 and you'll see that the behaviour is much closer to 2 than to 2.5


Bilu

It would be veeery interesting if people do tweak lmin etc HOW that results in the relation from Q to bitrate! Means could you also post a pic from Bitrateviewer added by a quote of the commandline or parameters used??

Thanks in advance a lot! :)

Webspace does exist at lycos or wherever ... no matter if advertising added, it should at least have the permission to link to jpegs/Gifs so they can be posted/called in/from here.
Everything else is just assuming ... and the Bitrate-Pic postage would make develeopemend faster :wink:

Some results else from a new test. This time I tested incredible/bilu way with vqmin=1, and tested several lmin values.

Mencoder dev-CVS-040401-06:00-3.3.1 build, compiled with Cygwin.
The sample is the 4th vob of Matrix Reloaded film (it lasts about 9:29 min). Original file size: 468350 Kb Again no filter, just crop and expand.
Command-line and settings as posted before. Encoded at 9-11 fps.

vqmin=1:lmin=0.5
=============
File size: 497146 Kb (bigger than the vob :lol: )
Bitrate: max 10254 avg 6986
Q value: max 1.88 avg 1.08

vqmin=1:lmin=1
==============
File size: 285186 Kb
Bitrate: max 8661 avg 4006
Q value: max 2.40 avg 1.79

vqmin=1:lmin=1.51
==============
File size: 177093 Kb
Bitrate: max 6063 avg 2487
Q value: max 3.31 avg 2.83

vqmin=1:lmin=1.52
==============
File size: 176753 Kb
Bitrate: max 6045 avg 2482
Q value: max 3.31 avg 2.84

vqmin=1:lmin=2
==============
File size: 148882 Kb
Bitrate: max 5165 avg 2090
Q value: max 4.08 avg 3.21

vqmin=1:lmin=2.5
===============
File size: 115904 Kb
Bitrate: max 4093 avg 1627
Q value: max 5.26 avg 4.29

Related to filesizes, 1:1 gave a big file. I'm sure that you look at the figures you get, but with this filesize I won't be able to fit 2 films in a DVD-R (not to mention putting 2 audio streams...). 1:2 gave the same filesize and bitrate/Q values as did vqmin=2:lmin=2 (I think it was bilu said it happens), and maybe is closer to desired final file size. But I don't see the advantage of using vqmin=2 with lmin=2 (Q value are always above 2).
I tested with lmin=1.51 vs lmin=1.52 to see if is there any difference... and there is: file size, in this small sample, decreased 0.2%... that means this is a way to adjust final size, since from lmin=1 to lmin=2 there's a 48% file size decrease, and lmin=2 is still very good. Again, I think that this can be the way to adjust final file size, since with 1pass CQ-VBR we cannot make a better file size prediction.

incredible, I still have to give your matrix a test. When you talk about a specific matrix for mencoder, could be yours the matrix :wink: . I'll test.