@ 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 - - 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 ) 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...

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

bilu, kwag,
I'm mencoding know with a Cygwin compilation made by Amnon ( ), 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
I just tested the latest CVS ( I compiled it myself, but on Linux ) and WOW
This thing blows away everything I've seen
Now I see why people are so frantic about mencoder
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

-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
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.

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


Bilu

@incredible

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

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...

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
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.

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

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 ) 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