Hi:
I am testing encoding with avs, makeavis, makeavis combo, and I have some questions.
1 - When we use avs script, almost for sure, we have resize with bicubic or lanczos. Why sws (maybe if not needed not used) is present, as autoaspect too. I think that both option, could use resources and make encoding slower.
2 - Maybe it is useful and this option would be better only available for, mplayer reproduction. (MencodeMe would send this option only for play preview with mplayer).
3 - "mbqmin" is present twice. Is it well? 4 - About "vqmin" we can read:
and
Why don't use option 3? Maybe can solves buffer underflow issue.

In fact, I just finish a test with this temp.cofg
Original sample was 6997KB.
Modified sample was 5661KB.
No so difference related to quality.

Can somebody to confirm this?

----------------------
Visit: Intermediate guide: MencodeMe/Win32 - Avisynth - MakeAvis by Prodater64.
Visit: KVCD - MencodeMe - Auxiliar Task - KVCD Docking Gate by Prodater64.
Visit: Mencoder scripting with AVSEdit and Guide for Multiple Files by Prodater64.
Visit: Mini-guide quick and easy - DVD to (S)KVCD with MencodeMe by Maurus.
Visit: Mencode-me: a newbie oriented GUI - 0.23 is out! by VMesquita.
----------------------

Here 2 samples. They are from XviD source, so, don't compare it with any DVD source result. Compare it between sample 1 and sample 2, in the sense quality vs. size.
I keep it on my server for a short time.

Edited JUN 02 2004: Samples retired.

See you.

---------------------
Visit: Intermediate guide: MencodeMe/Win32 - Avisynth - MakeAvis by Prodater64.
Visit: KVCD - MencodeMe - Auxiliar Task - KVCD Docking Gate by Prodater64.
Visit: Mencoder scripting with AVSEdit and Guide for Multiple Files by Prodater64.
Visit: Mini-guide quick and easy - DVD to (S)KVCD with MencodeMe by Maurus.
Visit: Mencode-me: a newbie oriented GUI - 0.23 is out! by VMesquita.
---------------------

Don't worry : these option tell to mencoder wich resizer to use and what behavior to have (keeping aspect) IF A RESIZE IS NEEDED.
As you don't do any resize in your process, these option are just useless. You don't lose any time.

Hi Prodater. That's good, from time to time sit down and review hoew things are being done...
Already answered. Didn't know that, Dialhot.
I think I commented this in the bug thread some time ago. Yes, it's not needed at all. Not really a bug, just useless.
Also this has been commented. I tested encoding with vqmin=2 and vqmin=1, and VBR, and the difference in final filesize isn't that big.
I know in man-page it's said what you posted/pasted. But there are two things:
- Is refering to mpeg4 encodings, but maybe also to mpeg2...
- I think this may be true when encoding with constant quantizer (vqscale=1 or vqscale=2). In this case, mencoder keeps quantizers at the given value, and yes, 1 maybe would be too low.
But in our encodings, with VBR and variable quantizers, you can see in BitrateViewer (even if little to be trusted in) that quantizers vary a lot, and usually keep above the vqmin value, and around 1.5-2. But setting vqmin at 1, mencoder has the possibility to lower quantizers a lot when needed (dark scenes,...) and obtain maximum quality possible.
I would keep with vqmin=1 (believe me: it has been hard-tested ). In very few cases, when mencoder has difficulties to get to desired vbitrate, I had to raise vqmin=2 to let mencoder work Ok. But as a general advice keep at 1.
Cheers

Exact!
I remeber very well when I had that dicussion with bilu in the mencoder thread where a vqmin at 2 is a too high quantizer in dark underwater scenes.
So you wont recognise a difference now prodater with the low avg bitrate u used and with the content of your movie.

But if you are going to DVD for example there you will see clearly the difference.

Also IF we wouldnt allow to less quantize in dark scenes .... the still higher quantize at 2 would cause even lower bitrates!

But, does somebody test if with "vqmin=3" dissapears buffer underflows?

BTW: Does somebody take a look at samples? I need your opinion to learn how I must to see a samples comparison.
---------------------
Visit: Intermediate guide: MencodeMe/Win32 - Avisynth - MakeAvis by Prodater64.
Visit: KVCD - MencodeMe - Auxiliar Task - KVCD Docking Gate by Prodater64.
Visit: Mencoder scripting with AVSEdit and Guide for Multiple Files by Prodater64.
Visit: Mini-guide quick and easy - DVD to (S)KVCD with MencodeMe by Maurus.
Visit: Mencode-me: a newbie oriented GUI - 0.23 is out! by VMesquita.
---------------------

Well, if the warning refers to a too low bitrate, I think Inc already gave an answer.
But as those buffer underflows (who was the one who said it just was a warning when buffer was empty, but didn't mean nothing...) are not giving me a single trouble, and if I raise vqmin I can see blocks ( ), I still keep the advise to, in general, stick at 1.

@digi.doc
sure i was (not the one but one of that ) but ... i never told it meant nothing. it means what it says; no more bit in the buffer so no way of feeding the apparent bitrate need any more. if it gets steady it may distort the bitrate significantly (& also worsen the quality) it would occur not only in the low but also in the high br region.
however, i'm not sure whether menc can distinguish 'under' & 'over'flow. sometimes i feel it does not.

@prodater
imho, vqmin has no direct effect on buffer insufficiency if u keep the same settings in each pass ... & if ratecontrol is good. but it's very frequent in my encodes that it occurs even where it did not happen in the 1st pass so ... ???
it's trivial effect is narrowing the quant distribution producing more even quality. some ppl do prefer it but instead of limiting the quants they rather use quant matrices producing such quant distributions.

all in all, i would not recommend to use qmin=1 unless it's really necessary (say, high bitrate encodings of very compressible stuffs) . it may produce jerks in the quality a/o in the bitrate which may lead to buffer exhaust. the risk of quant noise may also increase. safe usage needs a good & tricky bitrate (quantizer) distribution algo. do we have it ?

the bests
y

Well in case even of vqmin=2 we found out after many tests, that dark areas and underwaterareas etc. (means areas where normally the bitrate drops significantly) ... will end up too much quantized.
As by vqmin=2 at those parts the bitrate drops even more and also by having a vqmin =2 on those parts you see blocks immediately.

I did tests on "Titanic" as it gots a wonderful mix of parts of underwater- / fast moving- and (very important) uneasy watersurface- scenes. Means the whole range of VBR when encoding is given.
Vqmin=1 gave me the best quality as the quantize (not bitrate) value at the needed scenes - like underwater - dropped down(=less blocks) and kept the low bitrate above our wanted limit.
BUT there are still "problems" (well not if I use MY StandAlone Player) in scenes where the screen is "Black", ... like in slow scene changes etc.
But as Kwag did tests on mencoders intern. NoiseGenerator these Problems got less.

Prodater, I took a look at your samples ... yep, almost no difference, but that sample does not contain such a VBR dynamic as If you would do a test on a sliced one like the example I did mention above (Titanic).

So we should look at these "BIAS" Settings of Mencoder as in CCE this affects the bitrate dynamic.
But someone did say in here that this will only have an effect on mencoder mpeg4 encodings !?

@inc
i got your point. of course, if u drop lower quantizer onto a frame u got better looking output (quant ~ drf) but ...
- what about the other frames. in general, decreasing min quant means increasing the max so as to keep the same target rate. i.e. the price of having better frames here is having worse frames there. sure it is. here the average bitrate is a crucial point.
- the other point is that q1 is not restricted to scenes having low luma variation ('dark' scenes as u called it ) any frame may benefit from it. everything depends on the codecs choice.
- imho, imposing fine noise is much more effective against blocking then quant lowering. using a higher bitrate matrix is an other way. sharpening is the third ... so we've got possibilities.

i'm sure u deal with high bitrate encodes (only?) where these probplems are not so serious. just get back & try some mid or low bitrate encodes. u can better see what u gain & what u loose with some tweak. imho, the options can be tested much better in that region, in general.

i hope u don't find me too offensive. it wasn't meant. i highly appreciate your results here around.

the bests
y

I think I'm going to keep from using MEncoder till the rate control is rewritten (I've heard that it's in the works).

I just encoded Star Trek 2: The Wrath of Khan with both MEncoder (2-pass, 1360kbps avg bitrate) and CCE (one-pass variable, Q=22) and MEncoder gave me pure crap in some scenes. When I looked at the Bitrate Viewer graph, I noticed that the rate control doesn't always deliver the necessary bits whereas CCE came out much better.

With ordinary scenes MEncoder does a good job but I'm not prepared to start tweaking the settings to get it working with scenes like this. The settings I used were the ones that PackShot uses.

Here's MEncoder:


Here's CCE:


Here are the Bitrate Viewer graphs from the surrounding region:




You can probably guess which one belongs to MEncoder and which one to CCE

Notice that in CCE the max bitrate was 5000kbps and in MEncoder it was 7500kbps.

Boulder,
was using CCE250 ?
i ask cos i saw some posts showing opinions that 250 is slow but give better quality then others versions,this is mine too!
great tests!
thanks.

I've used the latest version, I never noticed any quality differences between 2.50 and 2.67. Plus it's faster on my P4 system

Hi Boulder,

Have you tried any NTSC sources
I think the issue is related to PAL high resolutions (+ 704x576)
I haven't been able to duplicate or see that at 704x480.

-kwag

No, I've not tested any NTSC sources. I could try encoding the same movie to NTSC resolution and see if it breaks up again.

Another thing to test would be to encode a similar 2-pass but use different filenames for both passes. I'm suspecting that the second pass screws up the encode as based on BV it looks as if the rate control spent all the bits just before that spot!

Boulder that strange, in my case it was the opposite!
I did a test on The core (beside many others) and the samples (and the whole movie) got much less blocks on exactly such scenes you showed here

And I do use Packshots settings already for a long time manually when I did used the .bat file way.

Well ... seems that there are many things which do affect mencoders quality

@ yaz

No, I defenitely didnt see that as an offense!
Thanks for your words!

@boulder
imho, no freeware can beat multipass cce (at the moment) in the mid-low bitrate region. especially when min/max bitrate restrictions are also important. but at high bitrates mencoder is pretty good.
imho, cce 2.67.xx is much(!) better than any cce 2.5x.
the bests
y