I re-did the tests, with the same sample (slices from StarWars II, 2% of whole movie).
With your settings/command (without denoiser, avisynth script): 28094 kB
With the settings I posted: 33633 kB... buff, almost 120% your filesize. That means that the whole film would "weight" 1681650 kB, and 2129138 kB if I add the AC3 audio stream (just one ). Well, I could fit 2 long-lasting films like this per media, but just 1 audio track. Well, maybe with subtitles.
And related to the image, to my eyes, with your settings the image looks like it was "dirty" (sorry me for my poor english), the colors aren't bright, looks washed up. With my settings colors are brighter, and image looks to me cleaner. And now that I got rid off blocks, my main problems are improve speed and compresibility...
Any help will be apreciated,... or call me crazy if I'm trying to get what it's impossible.

Main differences between our methods, easier to check this way:

setDVDHQ.ini:
=========
vrc_eq=tex
vbitrate=1500
vrc_maxrate=5000
scplx_mask=0.5

naq
trell:cbp
mbd=2:mv0
vmax_b_frames=2
cmp=2:subcmp=2redia=-2:dia=-2
lmin=2.5:lmax=11:vqmin=3:mbqmin=3

SETTINGS.INI
========
vqcomp=0
vbitrate=300
vrc_maxrate=9800
scplx_mask=0.3


I'll have a look now.


Bilu

@digitall.doc

This will be our framework: settings at bold are my first proposal and the rest is a common framework, so it's easier to change

Settings I removed for now:
vrc_eq=tex (it says "do not follow the bitrate parameter")
vrc_maxrate=5000 (I've seen scenes growing up to 7600 kbps even with my settings)
scplx_mask=0.5:naq (better results and filesizes not using naq and using a lower mask, try it)
vqmin=3:mbqmin=3 (min q=3 is limiting quality)

lmin=2.5:lmax=11
It says "you can read quantizer from 2 to 31, but you can change it so much that you can have quantizers between 0.01 and 255". Not something you'd want to mess with

Don't worry so much about vqcomp=0, since you also have vqblur=0.
I got to bitrates like 7600 Kbps even using this setting

Strategy will be trying to see if quality fits your taste; reduce scplx_mask if it doesn't. When it matches your taste we'll try:

1) removing mbd=2:mv0
2) removing trell:cbp
3) removing cmp=2:subcmp=2redia=-2:dia=-2

Each of them will be tried in separate. We won't remove B-frames since you're pleased with the quality. I only abandoned them because I had a weird interlaced stream.


Bilu

First of all: thanx a lot for helping me, since you found the settings that fit your needs/taste and there's no need to mess with somebody's else crazy command. You always
Also thank you for traslating some settings in a way I can better understand them.
Sorry if I don't give feed back to fast, since I'm very busy right now (my job, nothing to do with image, neither encoding,...) and have lots of things to do. I'll try to keep you regularly informed.
What does this mean: "don't follow the bitrate parameter"?, does it refer to vbitrate parameter?, since in my experience, mencoder tries to follow vbitrate (in my tests, avg bitrate was 1632, and vbitrate=1500). And from man_page, vrc_eq=tex does mean "constant quality" (try to keep CQ, I guess). Am I wrong?
I took this parameter from CCE experience (where maxrate is set to 5000), but as we are with mencoder, you're right, I'll try it and see if file size doesn't grow too much. It'll avoid some blocks, for sure.
Related to filesize, you're absolutely right: filesize almost doubles with naq. I remember you advised this some time ago, and tried it. The settings where almost the same I last posted, but vbitrate=3000, vqmin=2, without naq and scplx_mask=0.2... the filesize was 26166 kB (really low) but colors washed, and really blocky. That's why I kept naq. And raised scplx_mask to 0.5 to lower filesize. But that was with vrc_eq=tex, maybe with vqcomp=0 will be different...
I raised it to lower filesize, and quality didn't suffer much (maybe due to my different approach). I get avg Q 3.63 (with your settings is 3.95, and never got below 3) and peak Q 7.08 (5.54 with your settings). But with my CQ approach, Q is quite stable between 3 and 4, and just raises in complex scenes.
I didnt understand this at all. I don't think mencoder reads that can change between 0.01 and 255, since lmin is set at 2.5 and lmax at 11. I first thought it was for this purpose: I kind of "your Q limits are vqmin and vqmax, but if it's really needed you can go down to lmin and up to lmax". But didn't find documentation on lagrange multiplier. And believe me: with them, I get less blocks (almost none), without them some macroblocks appear.
bilu, but I "worry" about vqcomp=0, since I think this is the key dfference between our approaches: CBR vs CQ. I know bitrate raises (I tested your command), but mencoder is more "focused" in keeping low bitrates than in keeping constant quality (the Q curve raises and lowers continously) with your command. I think the key in my approach is vrc_eq=tex. Leaving it, I'm sure the better will be your way. If possible, I want "constant quality"
Don't think from my comments I won't try your suggestions, I'll try every. But I aim CQ, since, in my tests, is more sharp and clean, not so blurry.
BTW bilu, did you make a test with my command/settings. I'm curious about your opinion/result.

BTW, I did some days ago a test I forgot to post.
I encoded the same sample I'm doing tests, with CCE (the same slices and the same avisynth script). With Q set at 30 the filesize was 43221 kB, and with Q at 40 (the maximum advised to get acceptable quality) filesize was 36903 kB (above my last settings).
To my eyes, mencoder quality beats CCE at 40, and maybe at Q 30. And if I raise bitrate to 3000 or 5000, maybe filesize wouldn't grow as much as those 36903, and I would get definitely rid of those blocks that still appear from time to time, and quality would be much better...
Nice mencoder

... some other thing is speed, with my settings/command mencoder is slower than CCE. But still developing and improving, isn't it?.

My new settings, still being tested but seems very good now:

Without any quantizer limits but using naq this time.
I also increased scplx_mask but difference in quality/filesize is not significative.
On my most sensitive test (low motion, clean anime) it made a big difference in quality. Of course it got bigger

Old settings:
Filesize -> 30.879.651 -> 11.448.379
Bitrate/QP -> 3460/6.06 -> 984/4.42

New settings:
Filesize -> 30.879.651 -> 16.962.725
Bitrate/QP -> 3460/6.06 -> 1453/3.52

I'll never leave naq again

Other recommended settings for quality improving (if you have the CPU): trell,cbp,mbd=2,mv0. trell makes the biggest difference and you need mbd=2 to use mv0. But on my PIII-500 it gets 50% faster without them (4fps->6fps )

@digitall.doc: still under investigation


Bilu

The result from my last settings. Quality is much better.

Bilu

Bold: settings that may vary according to taste.
Green: needed for interlaced and NTSC encodes.
Blue: settings that improve quality at CPU cost.
Orange: Quality trigger when used with *_mask

I didn't include cmp=2:subcmp=2redia=-2:dia=-2 because I think this brings speed down and quality improvements are nowhere near those provided by the "Blue" settings.

I marked naq=1 differently because I intend to use it for high-quality encodes and remove it for extras/lower-quality encodes.
I'm curious about its behavious in 2-pass, maybe it's the opposite: if we don't try to normalize per-MB quantizing, more bitrate is available

If you're more demanding about quality remove the denoiser and the spatial mask and use the "Blue" settings.

I still don't have an opinion about vqcomp/vrc_eq, I haven't seen side effects yet using vqcomp=0 or vqcomp=1


Bilu

Hi bilu,
I'm happy to see you came closer to my settings (BTW, and I always explain that, they are your settings, before you started making tests).
naq improves really a lot the quality. It comes at a filesize expense, but it really worth it, and as we're talking about KDVD, we can afford it.
And I also agree with you about trellis, since quality improves, and it even makes filesize be less. Ah!, I tried qprd, and is not working: mencoder hungs (don't know if it was already posted in mencoder newslists, but if you have the time you could announce it, maybe a bug?, or I did something wrong).
And I wait for your feedback on CQ vs CBR. It's not I want you to change your mind, or I want to always be right, I wouldn't like you got finally to think like this. Here I'm just learning, and learned a lot of mencoder from you. But I like best the output of constant quality, and is the way I'm accostumed to from previous encoders. Just test it, and tell me if it can be improved in a way.
Of course, I'll give your last settings a try, but I think we're getting closer, and we have just to make clear if it is better the CQ approach (through vrc_eq=tex or vqcomp=1) or the CBR approach (through vqcomp=0). And a possibility of course, is that both be good ones.

I'm thinking... I'm afraid there's more experience in mencoder encoding CBR since it has been mainly used to make divx ---> now you'll see I don't have much knowledge, but AFAIK divx is CBR based, isn't it?. That's why maybe CQ with VBR has not been too tested under mencoder till now. But I tasted it, and liked it a lot, and want to take the best possible of this approach. If it doesn't worth, I'll forget it. And if I arrived to this point, was thanx to your (and everybody else in here) help.

Divx is VBR too. The 2-pass process was probably invented for MPEG-4

qprd hanged on me too.

I'll check today this vqcomp=0 vs vqcomp=1 thingy


Bilu

I was writing while you were posting.
You explain so clearly things that can't be clearer.
I also thought to remove cmp=2:subcmp=2redia=-2:dia=-2 to see what happens. I took this idea from man_page, where it says (if I remember well) quality improves. I'll try and remove.

You mean you already tried vqcomp=1 and didn't notice a difference between output?. Neither in visual quality, nor in filesize, nor bitrate, nor Q value?. Hmmm, surprising. Maybe is due to having vbitrate=vrc_minrate, could it be?. I'll test also this (buff, begining to have too much to test and too little time).
And maybe is just due to vrc_eq is not absolutely based on vqcomp, and you have to change vrc_eq to tex instead vqcomp=1 (I also wanted to test vrc_eq=tex_vqcomp=0, even it does not have any sense. Just a test to see what happens, if mencoder follows vqcomp or vrc_eq).

And again simultaneously posting
... well, here you can see my broad knowledge on video encoding
I'm really curious about your results with CQ (vqcomp=1 or vrc_eq=tex, whatever).

I have just tested qns=3 with trellis.
Brrr, horrible, encoded at 1 fps, and looks really bad.
And it was already advised in man_page...
I'll try qns 1 or 2 to see if it does worth, and doesn't slow down encoding.

Remember that original vrc_eq is tex^qComp, so:

tex^0=1
tex^1=tex

So

vrc_eq=tex is the same as vqcomp=1
vrc_eq=1 is the same as vqcomp=0

if the vrc_eq formula is the default one.


Bilu

A benchmark I found:
http://www1.mplayerhq.hu/pipermail/m...er/039821.html

And a nice link about parameters:
http://www.ee.oulu.fi/~tuukkat/mplay...ts/readme.html

Seems to me that qns is CPU expensive and qprd is crappy.

Bilu

First test (anime low-motion)

Vqcomp=0
=======
10240 KB
avg 3792/4.62
peak 6975/13.18

Vqcomp=1
=======
10213 KB
avg 3782/4.66
peak 6972/13.38

So this test worked the opposite way
Will do another with live video.


Bilu

Second test (movie low-motion, high detail):

vqcomp=0
=======
14604 KB
5868/4.35

vqcomp=1
=======
14616 KB
5873/4.33

So this time won vqcomp=1, by numbers.

Having a look at the Bitrate Viewer graphics I almost couldn't distinguish each other. They are different, but difference is so little it is hard to see.


Bilu

The only thing left to test in your command-line is:

cmp=2:subcmp=2redia=-2:dia=-2

Will have a look at it when possible, but I've read in the links I posted that larger diamonds is not necessarily good, even negative ones.

Bilu

Already tested qns with values 1 and 2, and didn't like the result.
Don't know what is it supposed to be doing, but file generated at both values look blocky. I'll drop it by now.

I still didn't have time to test your last settings, sorry.

When you compared vqcomp=0 and vqcomp=1, did you use the same vbitrate=vrc_minrate?. Since in the CBR approach, with vqcomp=0, this was your setting. But in my CQ tests, I used vrc_eq=tex (supposed to be the same as vqcomp=1 if using default vrc_eq formula) and vbitrate at least 1500 (below quality dropped a lot, and I used it to adjust filesize). I say this since I'm surprised you getting the same results with vqcomp=0 and =1.
And your comparison refers to BitrateViewer analysis, what about the visual quality to your eyes?.

If vqcomp=1 and vqcomp=0, at the same vbitrate, give the same result (filesize, avg and max bitrates, avg and max Q, and visual quality), then I'll have to say that I don't understand a word my friend.

EDIT: 2 doubts else left:
Are you still using vrc_maxrate=9800 for both vqcomp=0 and =1?, since in my tests this raised quality, no blocks, but bigger filesizes of course.
And, are you using vqmin at default (=2). The same comentary I did before applies to this one. Did you give lmin=2.5 (for vqmin=3) and lmax=11 (for vqmax=10) a try?. When I was close to my limits (in filesize) they removed many blocks.

@all

I'd like some feedback about dvdauthor, dvdunauthor and spuunmux.
Please post here if you have experience with that software.

http://www.kvcd.net/forum/viewtopic.php?p=68222#68222

@vmesquita

Would like your opinion too

Seems to me that we're coming into a command-line cross-platform DVD authoring era

Bilu