For the moment I've been more focused in bitrates than quantizers. vrc_minrate and vrc_maxrate work well.

I use vqblur=0 because I don't want quantizer delay. IMHO it would be better to have bitrate delay than quantizer delay, because if you keep the quantizer instead of increase it when the bitrates go up then the bitrate peaks will be bigger.


Bilu

Yeah...
It must be a problem with Portuguese people.
I should also look for mine: almost 30yrs old, 1.72mt, 94Kg
Again I would say that it's almost the same with me.
At the age of 20 I was 1.72mt and 72Kg.
Around 25 I weighted 80Kg.
Soon I'll be breaking the 100Kg barrier...
I need to take my bike and go out on it like when I was 15 yrs
I fully understand that. I've been doing the same myself. It's not easy working for ~12 hours a day and still get in front of the PC for 5 or 6 hours at home at night.
That's why I think you're fundamental to our forum .
Of course you don't need to be so dedicated as you've shown us lately.
Just go with the flow and drop by when you can or you feel like doing so.
Cheers mate.

__________________
Rui

@Inc,
I would just like to express that I think it's damn good to see you here at mencoder forum buddy.
I've been testing it with Slicer since the begining but I'm still in doubt on the arguments to make mencoder drop or raise the filesize.
Anyway I've always used the vbitrate=vrc_maxrate "way" as digi.doc, bilu and others here.
Have you tried to author yet?
Are you using DVDLab? If not which auth. tool do you use?
I'm targetting KDVD with 2 movies using mencoder, headac3he and ifoedit for auth. since I don't keep menus and extras.
I've been doing tests on MA vs FuPP too with mencoder and I still haven't made up my mind on which one to use...
Nice to have you with us.
Cheers

__________________
Rui

incredible,
I did all my tests with StarWars II, and I found several complex scenes (at least as I see them), for instance that of the battle of Jedi... And in my tests I didn't notice that too high bitrate prob. Maybe because I didn't try a really complex scene.
I think that the explanation that gave bilu is the reason why we use vqblur=0. If you take a look at BitrateViewer, you'll see that just when bitrate is begining to raise, Q raises and this way bitrates stop or slowers the raising... (don't know if I explained well ).
But, answering to your question about creating a thread with "standard" command/settings, I don't think we have a well stablished settings. For instance, you could test with vqblur and see what happens. I don't remember well the range of values now, but if 1 is maximum, you could test with vqblur=1 in that same scene, and see what happens to the file when you see it on TV, and what happens to bitrate and Q in BitrateViewer. That's the way I/we tested several settings (for instance, vbitrate values, or vqcomp,...).
Make me know what happens taking vqblur just opposite (that is: "static" quantizer value), but I'm afraid that if you're at q=2 and comes a bitrate demanding scene, as encoder will tend to keep q=2, bitrate will increase further (...hmmm, isn't this the same explanation bilu gave, but using far more words and far more complicated my explanation... )

Till now I did author many DVD-Rs using Mencode'd captured streams with success ("massage" afterwards using Restream to fix timestaps).
I that case I used TmpgEnc DVD Author as my captures do come with one Audiotrack only.

I use Vbitrate and Vmaxbitrate setted only, no VminBitrate!
And thats the point what I again saw yesterday when rising Vqmin again to 2! That resulted in blocks on underwaterscenes so I switched again to Vqmin 1 ... and there's no filesize rise that much (maybe 1%) BUT better Q curve and so Q factor allocation where it makes sense. In these Underwater Scenes, Bitrate dropped till 500kbit but the Q also lowered to approx. 1.5 = no Blocks = fantastic.
The average Q factor by this (in my case) does depend on the settet Vbitrate, if Vbitrate is lower, therefore the average Q also rises.
I defenitely try to avoid almost linear Quantizer Curves as it makes no sense, means its not that economically.
BUT if Im using VminBitrate bitrate that always causes "underrun" errors
If I kick out that VminBitrate parameter everything encodes fine and Bitrate lows do only lower till 500kbit ... no playback problems.

I testet also "trells" and "MBD=2" ... but no recognisable quality rise but it lowers the speed about of 20%!

Im very happy with my settings and you know my quality-ponit-of-view
Yesterday I did encode "The Core" from a DVD and the average Quantizer was 2,4!! CCE only can dream of this if a wanted endfilesize should fit a half DVD incl sound

I've fond here on the www a nice comparison of mencoder and CCE, ok there's not the commandline posted but the behaviour in my cases is almost the same: http://mitglied.lycos.de/sem12022004...pics_indy.html

BTW: Thanks for the "welcome"

PS: How do you get IfoEdit to author more than 1 stream to a DVD-R?

I'll have to try quantizer 1

Meanwhile I tried to compile both Mencoder and FFMPEG.
Compiled both under MinGW, no problems, but Mencoder crashes.
Already reported at the mailing list.

http://thread.gmane.org/gmane.comp.v...yer.user/27742

FFMPEG online documentation is Reeaaaallly outdated, just run ffmpeg with no options piping to a text file and see the difference

About the interface and docs, Mencoder is friendlier and able to support Windows codecs, that's the reason why we can handle AVS files

Idea: If one player could pipe the AVS to standard output, maybe Mencoder could grab standard input, hence no need for MakeAVIS.
I'll have to check this out


Bilu

From my tests so far the best way to flat the bitrates is to use vrc_minrate almost as big as vbitrate and increase lmin.

lmin/lmax are the most flatpriority related parameters in Mencoder IMHO.
Search for Lagrange Multiplier and you'll see why.

Example: vqcomp=1:scplx_mask=0.3:vbitrate=3000:vrc_minrate= 2900:
vrc_maxrate=9800:vqblur=0:vqmin=1:mbqmin=1:lmin=2. 5

seems to me like one of the best ways to achieve 3000 Kbps with nice quality.

In my former tests with scplx_mask=0.3 it seemed perfectly capable of achieve avg bitrates under 3000 Kbps (even with peaks greater than 8000 Kbps) with complex streams.

By limiting minrate but still giving space for the ratecontrol to aim at the average ( 100kbps only, because scplx_mask=0.3 + lmin=2.5 are a pretty strong combo to lower bitrate) you'll get you a pretty good result for such a bitrate.

High bitrate peaks will still exist but will be flattened a bit.
IMHO high peaks are normally high motion and don't get as much noticed as the other scenes.

EDIT: Don't care about this post, bad quality on underwater scenes. Read my last post in the other thread.

Bilu

Well, inc was right, this became the second mencoder thread, and lost its initial purpose. Hope bilu won't mind.

incredible, lot of information in your post. I'll learn a lot.
When do you get underrun errors? During encoding or when muxing?. Because during encoding mencoder advise from underrun errors, but already bilu explained that we don't have to take too seriously if they are reported just at the begining. And I never got underrun errors when muxing.
Related to your vrc_minrate problem, I didn't understand where is it. Is it in the underrun problem?. Since I encoded everything at vrc_minrate=300 (taken from CCE settings we use) and didn't have a single error. What are the problems you find setting a vrc_minrate?. And if you don't set a minrate, as there's no minrate default setting, it is supposed that encoder can go down to 0, isn't it?
I tried a encoding with vqmin=1 mbqmin=1 and lmin=1. For a 2 min sample (not good, a noisy capture), file size grew from 80 to 110 Mb, and avg Q dropped almost 1 point. It's nice since, in certain circunstances, we can make use o quantizer 1. But it may make grow too much filesize. I think we can play with lmin value (it's advised in man_page to use lmin equal or little smaller than vqmin. In tests I did vqmin=2 and lmin=1.5 helped to keep Q value closer to 2 than just vqmin=2).
In that blocky underwater scene, what was your bitrate, what vbitrate value did you use?. Since in my tests, with complex scenes (smoke, dust,...), and vbitrate=maxrate=9800, bitrate just raised a lot, and if needed Q raised also and then bitrate lowered. Don't know how vqmin=1 can help more than vqmin=2 in these scenes.
Yes, it's better avoiding linear Q values (we dropped vqscale for that reason): it has no sense, and makes bitrates go up crazily.
Related to trellis (cannot remember if also mbd=2, but >I clearly remember that in "other"forum they stated that it really does a difference) I did get different results. But, of course, it's a matter of taste...
Again, I'm very happy you came to play with us
Ah!, in IfoEdit, the way to add two audio streams is the same for the second as for the first: hit in the "point" button againg after loading the first stream, and load the second one.

Nice mencodings

bilu, I read somewhere else that compiling with Cygwin is more "stable".

I hope you'll be able to solve this avs prob (I don't like at all having to use makeavis, I have the idea that it lowers encoding speed), as Nic already did for QuEnc.

That's a nice idea, and this way you can "force" a kind of average bitrate in mencoder. But, what will happen when the scene doesn't need even those minimum 2900 Kb?, mencoder won't be able to go under, isn't it?.
And I don't say it's wrong, but the way you use lmin is different from taht advised in man page (equal or less than vqmin). But if it works... nevermind. Did you try to compare with vqmin=2:lmin=1?.
A doubt bilu, is there any problem with high bitrate peaks, but within DVD bitrate specifications?. In a bitrate peak, does visual quality degrade?. I ask since I don't know the answer.
Happy to see you back to posts friend

Tried it now, it works as fine as vqmin=1:lmin=1.
Even on anime or underwater scenes I couldn't tell the difference

EDIT: LOL Just encoded a file where it got a bit bigger using vqmin=2:lmin=1 than vqmin=1:lmin=1.

Bilu

I don't understand a single word of this mencoder thing

i can really talk the same and in deep sadness !


...but, the stimulus from you all give me high confidence
great guys !!!

Amazing...

The pictures look great, but I wonder whoever did the tests, if the file sizes are equal for both comparisons
It could be that CCEs samples are way smaller in file size, which would render the comparisons useless.

-kwag

Look at the top of the page:
Same bitrate -> Same size (the guy probably used 2pass VBR)

yes, ...really cool !
!

Yes, but where are the samples
I would like to see the actual MPEG files

-kwag

I think I see your poit now: they guy may have got the pictures from the parts mencoder did a better job, but there could be other parts where CCE did a better job that he did not choose.

yeah!
we need to see that samples !