Hi bilu,
I still find your results surprising, compared to my tests results. I'm with you that the better is finding a common way to use mencoder for everybody. But as I'm in PAL land, I cannot help with NTSC films. And if I find a nice way that just helps with PAL films, I won't through it away, but will post it, since it can help other people (as you do). Anyway, I'm not completely sure that the differences in our results are due to being NTSC or PAL, but don't know what the reason is.

I'm also with you with vbitrate=vrc_maxrate (lowering maxrate to 5000), but for long length films this will mean fitting just 1 film per DVD media. If you want to fit at least 2 films, you will have to lower vbitrate (with 1500 it worked for me) and maybe raise quantizers.

BTW: you could ask in mencoder news if it is possible to have working floating values for quantizers, it would be of much help.

I see you get no differences at all between vqcomp=0 or =1 when vbitrate=maxrate. I didn't reproduce that in my tests, I got differences.
And filesize differences between vbitrate=min or max are very little, taht again wasn't my case. You even get very little differences in avg and peak bitrate, but just in quantizers...

I'll keep making tests. But we could advise to employ notch-matrix, vqblur=0, naq (and scplx_mask), and vbitrate close or equal to vrc_maxrate. And for quality, use trellis+cbp+mv0. Quantizers min at 2 and max maybe at 10 (but if filesize too big it may be necessary to lower vbitrate and raise min quantizer). About vqcomp... I just would advise to test both and see results, by now. Let's see if we can come to a conclusion .

... and related to b-frames, I don't see much "enworsement", and it also helps to decrease filesize (and quality may be tweaked).

Nothing beats 2-pass encoding in this area
I'll try now with progressive streams, maybe B-frames are buggy with interlaced streams only. So I'll avoid them anyway, but PAL-only encoder won't need to

Now testing vbitrate=vrc_maxrate without naq...
EDIT: Quantizers decrease even with vbitrate=9800. It never lost much quality in real life movies, will now test on anime ...
EDIT2: Tested. Still no good.

Bilu

Confirmed: B-frames work fine with progressive streams but not with NTSC. I'll try to find info on this subject. Removed every interlace-related setting before encode and it worked.

Will now repeat the vqcomp/vbitrate tests.

EDIT: Same conclusion, better to use vbitrate=vrc_maxrate. vqcomp=0 or vqcomp=1 is irrelevant.

EDIT2: A progressive stream done with interlaced parameters can do B-frames. An interlaced stream gets screwed up

@digitall.doc
Please read this whole thread:
http://www1.mplayerhq.hu/pipermail/m...er/040946.html


Bilu

Bold: Denoiser.May help with compressibility. il=d,il=i are for interlaced filtering.
Blue: needed for interlaced and NTSC encodes.
Violet: settings that improve quality at CPU cost.
Orange: May also help with compressibility. (raises quantizers)
Red: Only when using VOB sources directly.
Brown: Only with non-interlaced and non-telecined sources.
Green: Bitrate settings - using vbitrate=vrc_maxrate is recommended.

I said in the "brown" item that it was for non-interlaced and non-telecined sourced. I didn't said progressive because some guys call progressive to telecined sources (like Mencoder says :"24fps progressive detected, changing framerate...").


Bilu

I've abandoned scplx_mask=0.3:naq and quality improved a lot. Despite using naq, the spatial mask was raising quantizers even when I specified vbitrate=9800

Not anymore....

Bilu

@bilu,
I still have lots of tests to do (very busy at the moment, don´t have spare time). I even didn't read that thread you pointed me to (just read first post, and lost myself a little, but I want to read it thoroughly).

Well bilu, I think KVCD "philosophy" (and maybe I'm not the right person to talk about this forum philosophy, since I'm very new to this. And of course, you may already know the following) is not that. I think we try here to get the best results with 1pass encoding, and with constant quality. And with some other "flavours" (like notch-matrix, GOP, avisynth MA script,...) is what make the "miracle" . I don't remember many people here doing 2pass. And don't think that doesn't mean it hasn't to be done, since here people are very open-minded and accept suggestions out of the "official" (if any) line, but we're, in general, very happy with 1pass results.

Yes, I remember I tried this once. And maybe it works with high bitrates and low quantizers,... but this also means biiiig file sizes, isn't it?. And the advantage of making KDVD (apart from quality) is manage to fit 2, or even 3 films per DVD+-R media. And I'm afraid that without naq, if you have to lower bitrate to fit films, image will get worse (at least is what happened to me). For high bitrate encoding (that is, vbitrate=vrc_maxrate=9800), maybe is not necessary... but maybe also is not necessary notch-matrix, or filtering the film, since you will just be able to fit one film per media, and you'll have lots of bits to spare in standard matrix.

But, of course, this is just my opinion, and I'm not a very knowledge person

And, as everything that is suggested here and sounds intelligent to me, I'll also test it to see if it really raises filesize so much.

As some posts before, I'll say again that I feel sad that we're the only ones posting here our results with this encoder and our settings. It would be nice if other people posted here their results with these (vqcomp=0 or =1) settings to see if we can get at a point, and find a better way to employ this tool... since it looks thst it worth th effort.

Cheers.

Time always beats 2-pass

-kwag

New tests, 1-pass encoding without B-frames:

- p_mask=1 increases quality;
- naq isn't worth it (better not to use scplx_mask at all);
- vrc_maxrate does the 1-pass bitrate control, vbitrate isn't worth it;
- using scplx_mask without naq can be used as an alternative to B-frames in interlaced encodings. And it's very good at lowering bitrates since it distributes the "damage", probably the best alternative in 1-pass encodings.But be careful with anime, edges are very sensitive to quantizing;

Couln't test vqblur=1 because I was working a very small sample.
But I don't think that is what we're looking for


Bilu

Yes kwag, you're right. I just said that we try here to encode 1pass, and take out the best of 1pass encoding, but didn't explain why. Of course, the reason is 2pass doubles encoding time.

bilu, what are sample length (in time) and what the file sizes you get?. I explained in my previous post that I wouldn't drop naq, since it helps when you have to lower vbitrate to shrink file size. If not, there begin to appear blocks all over

When you state that vrc_maxrate does the 1pass bitrate control, and vbotrate doesn't worth it, what do you mean?. Does it mean that you don't give vbitrate a value since bitrate is adjusted through maxrate (so, you leave it default=800)?. I ask because I noticed that when I lower vbitrate for filesize reasons, avg bitrate lowers...

Do you know how p_mask works?. I wanted to test it, but I don't know really how it works (and I think, as a *_mask it is, it will benefit from naq )

BTW, I read the thread you pointed me at. If I understood well, it was on b_frames. And sorry me if I didn't get it, but I took no conclusion. In a post was stated that knowledge "people" dropped b-frames (but no explanation why, and I even believe that they were mainly refering to mpeg4). In other post they argumented that b-frames gave little advantage in file size,... I have different experience, filesize decreased without noticeable loss of quality. And you always can adjust b-frames quality through qfactor,... Well, no conclusion for me.

Please, take a look at filesizes and stimated file size for the whole movie, and make me know. In my first tests I was also surprised by the quality I got, but then I realised I had to lose quality if I wanted to compare mencoder to other encoder in my real life KDVD encodings (at least, 2 films per media). For 1 film we have lots of tools out their (of course, without KDVD quality )

If I remember correctly, the original reason was that Tmpgenc does a much better job in CQ mode than in 2-pass VBR. But later when I created CCE templates, I found the quality to be pretty much the same (1pass vs 2 pass), but 2-pass was of course much slower.

If you don't want blocks, don't use scplx_mask at all.
I compared scplx_mask+naq against no scplx_mask at all and strangely the bitrates through the encoded sample are about the same but quantizers were bigger. No matter if I tried scplx_mask=0.1, 0.2 or 0.3, quantizers allways got bigger than using no scplx_mask but the bitrates were almost unchanged. Tried with vbitrate=300,1000 and 9800 and it never helped keeping the bitrate.
But using no scplx_mask looked better of course. Try it yourself comparing small samples through Bitrate Viewer.

But one of the most effective ways to lower the bitrate by distributing the quantizer increasing is scplx_mask *WITHOUT* naq.
Not a specific value, but it would be nice if we could somewhat do a compressibility test and increase scplx_mask as needed: scplx_mask=0.2, 0.3 ....
B-frames are a better method of course, if you're doing progressive encodes.
On all my tests so far (longest samples are 5 minutes long) it didn't made that much of a difference if I used vbitrate=300,1000 or 9800 - results were almost the same.
But vbitrate=vrc_maxrate looks a tiny bit better.
It won't benefit from naq IMHO because it's already seems to be kind of a temporal naq
Well, you're right: no conclusion for you
It's about MPEG-2, interlaced support and B-frames. It explains why it doesn't work well with interlaced encodings:
I'm getting to these conclusions:

Low-motion movies: Reduce vrc_maxrate.
High-motion movies: Use scplx_mask without naq. Don't reduce vrc_maxrate.
Anime: Just use a denoiser. Don't even try quantizing limits.

On low-motion most stuff won't get restricted so you can specify a max rate that you can trust (unlike vbitrate).

On high-motion it's important not to limit the max rate: explosions, blasts, pursuits, whatever, consume a lot of bitrate. So the bitrate decreasing must be distribuited though the whole stream. Besides B-frames, this is the best alternative left. Using naq here would cut the downsizing effect and you'd have to force a lower maxrate again.

Anime: every quantizer looks bad on edges
Denoiser is the best choice to decrease bitrate, but still no garantees.

PS: I didn't kept the files for measuring bitrates and filesizes, but I remember my conclusions and BV comparisons well. I can repeat the tests if it's that important, but I already know the conclusions I'll get

Bilu

@digitall.doc

I'd like you to do a comparison between scplx_mask=0.3:naq and no scplx_mask or naq at all, in Bitrate Viewer.

You'll notice that quantizers are much higher using scplx_mask=0.3:naq but the bitrates will be almost untouched.

I know, it sounds strange
But check it yourself to see what I mean


EDIT: Maybe the problem is that I'm asking too much from the rate control with such small samples, I shouldn't try with less than 30 minutes.
But I have a PIII-500 laptop that I need for other stuff, so don't blame me
If that wasn't the problem maybe I'd be doing two pass instead of one

Bilu

They talk about b-frames in interlaced coding. And I live in a PAL country, no interlaced sources at all (maybe yes when I begin to encode my TV captures, but NOT now).
So, again, no conclusion for me. I keep with b-frames, and advise them for progressive source encoding.

Well, I did get differences in smaller samples, related to filesize and visual quality, of course being better with vbitrate=vrc_maxrate.

So, do you already know what p_mask is supposed to do?. I still don't, even didn't test it at all. If I thought that naq could help, it was because it was stated in man_page (naq helps when using *_mask).

bilu, I followed your last thoughts,... and got surprising results indeed .
Even if don't completely agree with you , always test (most of) your suggestions. My main objections to your suggestions were related to good quality but with very big filesizes (you erased your tests but I kept them, and they were too big). But here are my lasts results:
- with naq and scplx=0.5 33683 kB BR 4924-1634 Q 7.07-3.63
- without naq and without scplx 35917 kB BR 4764-1742 Q 7.64-3.46 (well different bitrates, and higher max quantizer with lower avg... not what we expected at all )
- no naq scplx=0.5 18858 kB BR 3784-915 Q 9.00-7.37 --> hey, hey wait a minute, quantizers raised a lot, and bitrate lowered a lot as file size, may it be a way? (you already suggested). Maybe 0.5 too high... and was done with maxrate=5000 and avg=1500. Let's change them:
- no naq scplx=0.2 vbitrate=maxrate=9800 33364 kB BR 5599-1619 Q 4.29-3.45
BINGO!!! file size similar to the first ("gold standard") test, better quantizers,... good.

Did several tests else, with this approach: vbitrate=vrc_maxrate=9800 (even =5000 with similar quality results, and little decrease in filesize), vrc_eq=tex (keep on ), naq=0 (you were right), and variable scplx_mask values... I have realised that scplx_mask accepts more figures (I even tested =0.255, and gave different results than =0.256), what helps us to adjust final filesize... very good.

Vissually it seems to me that image gets a little blurred (what does scplx_mask do?, does it filter/blur the image or just acts on quantizers?. Do you know the answer?), but very little, and NO blocks at all. Nice.

And with this high bitrates, quantizers keep low (but surprisingly didn't see them go under 3, even I set vqmin=2), independently what vrc:eq setting you use... but I prefer to keep at =tex, because it may be needed in other films-settings, and in my previous tests it helped more.

To sum up (too long post): better approach to use scplx_mask=0.15-0.35 (even 3 decimals) without naq. The rest, as we were using (I see you already opened a thread with this new settings, I post there some suggestions).

Keep on testing here

IMHO p_mask=1 averages between inter-MB quantizers, but I don't know if it does it spatially or temporally. Quality does improve a bit, bitrate rises a bit, may be a good thing to use with scplx_mask.

Best values for scplx_mask are between 0.2 and 0.3, I think.
0.3 is my favorite I've tried 0.5 but it was too much.

A little blurred is not that bad considering that you'll watch them on a TV output It will allways be better than VCD and at least as good as a sharp SVCD, the quality is prettty good.

The *_mask settings just act on quantizers.

I'd suggest 0.2 for better quality and 0.3 for better bitrates.
But for anime we should only use denoisers, even scplx_mask=0.1 is bad

And as you've seen from my previous tests using scplx_mask=0.3 without naq together with hqdn3d the bitrates got allways under 3000 Kbps.
Maybe without the denoiser results are still that nice, and would be faster.
And my tests were without B-frames.

Bilu

It sounds like naq function...

Remember that you can use 0.22 and even 0.222 (maybe, this way, it can fit more to your taste)

So, if it just acts on quantizers, it shouldn't blur the image, isn't it?.
And... no, even to be seen on a TV set, I prefer not to have a blurred KDVD. Other thing is KVCD, that needs some blurring to make file smaller. But for KDVD I want the best image possible, since I don't know if the day after tomorrow I'll have a 60 inch TV set, and suffer of little image definition (that's why I encode in 16/9 aspect, the keep the best quality possible).

BTW: I did some encodings without mbd=2, without trellis and without predia and dia=-2, and speed changed from 4-5 to 5-6. Not a big difference. What would really make a difference is that mencoder accepted avs files (or better, mencoder included avisynth built-in, and encode directly from vobs, with internal avisynth filtering... a dream?).

I'm with you digitall.doc.
I also encode in 16/9 AR and I dream on buying a TV projector or a big TV set.
I'm pretty sure I'll have to live with a flat square 100Hz 32" TV set and a bit of blurring won't
be so noticable.
But when I joined the community I always aimed for best quality / fastest encoding.
That's what makeAVIS/mencoder seem to deliver.
But I also live in doubt: what if mencoder could internally read avs scripts?
Maybe it would be a bit faster than it already is.
Other doubt: most of the arguments that both you and bilu are trying right now. Do they blur?
If so there's no point in using them and avsynth filtering at the same time, right?
If mencoder could read avs internally I think I would only ask for one thing more.
And that is avisynth 4 linux. I've been working all day on a Linux box that has mplayer/mencoder.
But it lacks Avisynth scripting!!!
Hey, sh0dan Can you hear me Guys from Linux can use avs scripts...
Think he heard me
Think he can do anything about it
Hope he can surprise me one of these days

__________________
Rui

@rds_correia,
did you try mplayer/mencoder linux versions?, what about speed?.
Yes, it would be nice to have avisynth built-in mencoder, or at least mencoder compatible with avs script.

@all,
I could encode directly from vobs with vmesquita compilation, but couldn't with bilu compilation, and I know bilu is using his own compilation to encode from vobs. Have anybody met the same problems I did?. How can I solve them?

Bigger quantizers lose detail hence they blur the image.
In terms of detail a resize to a lower resolution can also be considered a sort of blur. And when you aim at lower bitrates you end up attacking higher frequencies by denoising or increasing quantizers, hence you blur.

If you don't want any blur, don't expect lower bitrates
IMHO the most important is HOW you blur.

I think hqdn3d is good enough to allow me to abandon Avisynth

Avisynth is at the moment too dependent on Windows-specific assembly code, although the VFW part could be replace by the Linux AVIFile library.
This was my opinion the last time I checked, there are some threads on this subject in Doom9.

EDIT: The IVTC techniques from Avisynth are far superior to those from Mencoder. If you ever want to do NTSC to PAL conversions then you'll need Avisynth for sure. The only settings I'm using that lower bitrate are hqdn3d and scplx_mask=0.3, remove them for the best possible quality.

Bilu