yep, we missed you these days.

But as you can see, little changes. A new encoder (QuEnc) that makes alse use of ffmpeg engine (but I think you already know it, since you said it encodes constant bitrate), but I tried it and with the same final size, gave me worst result...
So here I am with mencoder.
Don't know if you missed a post where I commented my test. But I wondered there if in mencoder news/forums they showed intention to make mencoder accept avs files,... well, and some other doubts.
I also have been too busy these days, but I think this weekend I'll be back to tests :wink:

@digitall.doc

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

The ratecontrol code is being rewritten. Michael Niedermayer is active on both the Mencoder and FFMpeg mailing lists, so libavcodec improvements will get both encoders at the same time :)


Bilu

bilu,
I followed your link, and read there a little...
Nic say that from the parameters we're using with Mencoder, we don't really understand the parameters...
Is he refering to our parameters?, do you know what he is refering to?. In what way he thinks it can be improved?. Since in my tests, I got better (to me) results.
Have he posted the parameters he uses in QuEnc, apart from that we can adjust in the GUI?.
I think we can learn a lot from each other :idea: .
Don't you think so?.

I think no one should take any sort of conclusions until Michael fixes the ratecontrol code.

So far the rate control stuff looks bad to everybody :lol:


Bilu

... smoooooth answer :D

You're prudent, man 8)

But,... are you thinking in change your last settings?

The only good settings to test right now are those who aren't quantizer-based, i.e. those that make a difference when testing with vqscale=2. Everything else is subject to change.

Even Nic would agree with this one ;)

Bilu

I see.... :roll:

Freezing tests right now :? . Since what now is giving me good results, maybe won't be so good in future mencoder (ffmpeg?) versions, with changed rate control.

And don't want to test other settings, that can be useless in near future.
Even don't see the point to keep testing QuEnc, as it also will have to change...

:arrow: :arrow: :arrow: :arrow: waiting news...

Screenshots:
http://clientes.netvisao.pt/bilu/bruno/bf_bug.zip

I've posted this in the mailing list now.
It's the B-frame bug I've been telling you guys, it happens whenever you switch between interlaced and progressive or vice-versa, specially in high-action.

Mailing list thread view:
http://sourceforge.net/mailarchive/m...msg_id=7642853

Bilu

bilu,
already downloaded. But I think that just happens on interlaced material, isn't it?.
I hope they'll fix it, since I will try to backup some home made films soon, and as it's DV source I guess it'll be interlaced.

What about rate control, new settings and so on... I know, I know, just 15 hours from my last post. But I have my PC warming up for tests :lol:

Is there any new in the mailing lists (advances, problems met,...)

Better relax dude ;)

You can check things happening in libavcodec from here:
http://www1.mplayerhq.hu/cgi-bin/cvs...eg&sortby=date

You'll see Michael has been busy lately :)

And most of the tests I could do with a fixed quantizer were already here:
http://www.kvcd.net/forum/viewtopic.php?p=65838#65838

Main difference being that I abandoned the denoiser here:
http://www.kvcd.net/forum/viewtopic.php?p=69038#69038


Bilu

:?:

bilu, believe me if tell you that I'm probably one of the most quiet people you know. I'm almost ever relaxed. It's better for heart health. 8)

In a thread like this, with about 300 posts, I just wanted to create a curiosity/expectancy/whatevercy ambient. Just that. :wink:

I thank you for the link, since I lost link to mailing list you posted some thillions of posts earlier. :D

I'll wait your news with increasing anxiety :lol: :lol:
... don't make us wait too long :wink:

From mailing list: http://mplayerhq.hu/pipermail/mplaye...ch/043280.html
It's a bit old (from March 1st) and maybe subject of change if ffmpeg ratecontrol is changed...
Nice to be used with trellis

Already advised by bilu, if I remember well

And they tested cmp=2 better than cmp=3

This is from mplayer-users. Maybe I will have a look at developers' to see what's hot now.

Hi guys,
This is my first attempt on MEncoder so please go easy on me. And so far I haven't had any luck with making any encodes with this supposedly great encoder. When I ran the bat file this is what I found in the DOS window:
What am I missing?

P.S. Never mind the last line. No there's nothing wrong with your screen - it's swedish! :wink:

I downloaded another build and now it works! :)
I'm very interested in seeing the output quality of this encoder. From what I've read it's something else, eh?

BTW Is MEncoder using the KVCD Notch Matrix :?:

Hi audioslave,
you'll enjoy this encoder.
Mencoder doesn't use KVCD matrix by default. You have to give it through inter_matrix and intra_matrix, in the ini file or in the command line.
Take a look at the last command posted by bilu, and there you'll see the matrix.
If it doesn't work for you, make me know and I'll post the complete *.ini and *.bat that have worked for me.

Happy mencodings :lol:

@digitall.doc
Yes, please post the *.ini and *.bat :D .

@incredible
How do I use the Slicer routine with MEncoder - for prediction :?:

Well, these are my/our last settings. But as bilu stated, everything is susceptible of changing, since they're going to change the rate control in ffmpeg.
mencoder.bat
settings.ini
Some comments:
- In the directory tree, we have mencoder.exe and mencoder.bat in a folder, and the mplayer folder (where you have settings.ini) is a folder in the same mencoder.exe folder (don't know if I explained well :oops: )
- I left vbitrate=9800 and scplx_mask=0.22 in the bat file, since they are the parameters I tweak to adjust final file size (increasing scplx_mask value or lowering vbitrate, lowers file size) I now usually change scplx_mask (not above 0.3)
- I use vrc_eq=tex, but is the same as vqcomp=1
- I also used (and have seen some people using it) cmp=2:subcmp=2 (I think is SATD instead of SAD), and predia=-2:dia=-2 (faster as man_page says)
- I also use p_mask=1 but still don't really know how it works (advised by bilu), didn't make tests. If anyone is willing to test...
- These settings: trell=1:cbp=1:mv0=1 are for quality, but slow down... If you want you may try without them and see: 1 speed gain, 2 quality loss. And then choose...

There are some other settings I saw people using and didn't test:
- vratetol=1835 A setting Amenophis uses. It refers to rate control tolerance. Default is 8000, and lower values make bitrate changes more smooth (don't know if it is of interest; what do you think bilu?)
- I saw people using vqmin=1:mbqmin=1:lmin=1, in order to get higher bitrates. It isn't advised in man_page, and I didn't test. But I already tested vqmin=3:mbqmin=3:lmin=2.5, and helped to lower quantizers... If you want to do tests.

Hope this will be of a help, but I insist, is subjected to be change now, and in the near future :wink:

EDIT: the file 1 in the Temp folder, is a fake avi done from avs with makeavis
EDIT2: this settings are for PAL progressive sources. In interlaced sources, I recommend you to try bilu settings (ilme, ildct and so)

As usual, libavcodec documentation sucks :?
By crossing docs between FFMPEG and Mencoder I got to the conclusion that vratetol,much more than the vqcomp or vrc_eq settings, is the parameter that will let enforce the average bitrate behaviour.

Lowering vratetol will make the filesize much more predictable, but it will still be VBR encoding, not CBR as if vrc_minrate=vrc_maxrate.

About vratetol=vrc_buf_size, I'm not really sure it makes sense.
I think VBV specifies a maximum bitrate variation, it could be less than VBV and still be compliant. If someone knows this subject better, please provide feedback.

I'd like to see how a vratetol=0 behaves ;)

@digitall.doc
Thanks for bringing this parameter into our attention.
I was so obsessed with the rate control fixing that I forgot to look at it :)


Bilu

bilu,
nothing to thank. Almost all I've learnt from mencoding and parameters, and my interest with mencoder, is due to you and your advise and help. I'm the one to thank a lot :roll: .

Don't know if the vratetol value=1835 was intended to be equal vrc_buf_size, but is a value to begin testing with (and, of course, also 0)

Answer from Amenophis:
http://forum.doom9.org/showthread.ph...846#post467846

EDIT: The vratetol option must be >= 4


Bilu

bilu,
did you test with vratetol?. Is there any change in the output, related to file size, bitrate and Q values?.

Yesterday I was thinking (not too much, it's bad for health :twisted: ) that all mencoder parameters are like a grayscale, but we use them just black or white. I'll explain: we use vqblur=0, vbitrate=vrc_maxrate, vqcomp=1 (or vrc_eq=tex), p_mask=1,... I've seen people using vqblur=0.3, vbitrate<vrc_maxrate,...
It's not I'm not satisfied with our results, just opposite. It's just I don't really know the effect of not going to the extreme, but just close (like vqblur=0.1 instead 0). Did you test it?. I insist, that I like our actual results, it just a thinking I had.

@digitall.doc

New mode to be tuned :twisted: , let's call it "Wise CBR" ;)

It basically works like this: from tests done before we know that scplx_mask=0.3 gets avg bitrates almost allways under 3000 Kbps,
so we set vrc_minrate near 3000 Kbps to create a "protective area".
This way lower motion scenes will be better preserved.

We already know how well scplx_mask lowers the bitrate preserving detail :)

The main reason for setting vrc_minrate 100 Kbps lower than vbitrate is to let it have room to compensate the bitrate peaks, but if it was more than 100 Kbps difference the avg bitrate would get lower.

Then we increase lmin from 2 to 2.5 to decrease a bit on the high bitrate peaks. Lower peaks mean better avg bitrate and on higher action the increased quantizing isn't noticeable. Most high bitrate peaks are high action.

But we won't deny their existence by using vrc_minrate=vrc_maxrate like in normal CBR, that's the "wise" part :)
Just lower the peaks a little so they don't make so much damage on the avg bitrate.

I've just encoded chapter 15 of the Gladiator (first fight in the Coliseum) and it looks very good! :D

Avg 3114/5.54
Peak 3967/7.20
Duration 7m18s

I'd like you to test this since you're aiming at 3000 kbps to fit 2 movies into one DVD-R.


Bilu

Hey bilu,

Give me a link to the latest MEncoder Windows binaries.
Let's make it a sticky :!: :idea:

-kwag

@kwag

Here's the current situation:

I reported a bug with B-frames when changing between interlaced and progressive.

http://sourceforge.net/mailarchive/m...msg_id=7642853

Which seems to be fixed now but I haven't tried it.

http://sourceforge.net/mailarchive/m...msg_id=7689779

Meanwhile, there are problems in compiling Mencoder under MinGW.
Guess I'll have to do it in Cygwin, I've heard it's fine.

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

Could you do it yourself? You have Cygwin installed and all that ;)

EDIT: My last one was http://clientes.netvisao.pt/bilu/bru...r20040310a.zip

You can use the man2htm2 tool to generate an HTML man page, but you'll have to open mplayer.1 in a text editor and replace .IPs with .IP first.
This way the settings values will show up in the HTML.


Bilu

WOW 8O

Can you spell "lower bitrates without blocks even on anime or underwater scenes"? 8O 8O 8O 8O 8O

Very good quality, please have a try.
If you find it blurred just lower scplx_mask, but to me it looks very good. lmin=1 made all the difference, probably I can even try high scplx_mask values.


Bilu

Well bilu, what can I say, you're the best when you start thinking in a way to do things better.

I already answered you some things in the other thread. I said there that didn't think it was the way to use lmin bigger than vqmin (from man_page and from previous tests). It helped me a lot to use vqmin=2:lmin=1 (or 1.5), but of course Q never gets under 2 this way, but keeps close and raise when needed. I see you changed to vqmin=lmin=1. I think taht makes more sense.

I tried several times your vbitrate=vrc_minrate=300 way, but I'll have to redo tests. I remember I dropped it but don't remmeber why, I think it was that I got blocks, where didn't appear with vbitrate=vrc_maxrate=9800.

Anyway, you try this way to get a lower average bitrate, but I think, what for?. To lower file size?. Why don't we then use vrc_minrate=300:vrc_maxrate=98000:vbitrate=3000 (or 5000, or whatever needed)?.
And I found a way to adjust finalsize, playing with scplx_mask value (between 0.199 and 0.299).

I'll also try with minquantizers at 1, but I just did 1 test and filesize grew too much. Maybe with minquantizers at 1 we can use higher scplx_mask values, but at 2 I didn't like the blur effect of scplx greater than 0.3

Did you try vratetol?, I'm going to test now.

YOur "No blocks on underwaterscenes" do maybe come from VQmin=1 ... do you remeber when Digi.Doc gave me the caution that its not recommended.

This morning I encoded anamorph 704x576 the Movie "K19" where several underwaterscenes do happen. As I also use Vqmin=1 therefore NO blocks etc.

If you do a comparison in Bitrateviewer between Vqmin=2 and VQmin=1 you can see that this min=1 setting does give a real advantage on low bitratescenes drops as the Q curve also drops down to apprx. 1.5 which means less quantisation on dark scenes but beside this the endfilesize doesn't grow up.
That makes compressing more efficient as you see.

(Right now Im working on a new Matrix especially (as Notch) for TV purposes and which does Cut frequencies extremely on parts you wont notice on Tv but less frequent parts wont be quantized much = even less possibility of blocks on these mentioned dark scenes.)

And digitall.doc calls me an expert :lol:

Bilu

I may be wrong here since the ratecontrol gets more agressive as the stream gets larger, and I've only tested small samples.

Better play it safe and set vbitrate to whatever you expect.
And then maybe naq will help you achieve filesize predictability too.
Although it raises bitrate like hell :lol:

vratetol is really just filesize tolerance, think of it as a more agressive ratecontrol when using smaller values, but still more effective on large streams, never less than 30 minutes.

About scplx_mask settings, I can go up to 0.4 even on anime, 0.5 is too much.


Bilu

Hi Bilu,

Download this, and tell me if it works.
I compiled it with Mingw, and it's from the latest CVS sources: http://www.kvcd.net/mencoder.exe
It's only the executable file, so save yours, and then copy this one in place.

Let me know if it works :!:
-kwag

It crashes the same way, and it was very small.
You need to use --enable-static to compile with libavcodec built in.

I had tried just this morning. Can you do it with Cygwin instead of MinGW?


Bilu

It's small because it's a compressed executable It's in there.I'll try to see why it crashes. I think it's related to some file/path missing issue.

-kwag

My last settings:
The bold settings may vary.
scplx_mask=0.4 is fine by me if using lmin=1, but you may need to lower it to fit your taste.
vbitrate and vqcomp=1 need to be tested on streams with 30 minutes at least, and I have only a PIII-500 :roll:

I got the feeling that the default vqcomp=0.5 or even vqcomp=0 may be needed to fit a certain filesize. vratetol is just filesize tolerance, not that relevant.


Bilu

Changed again :roll:

Underwater scenes and clean anime are really good for testing parameters. You can test both low and high frequencies.

I've been fighting with the lmin and scplx_mask parameters.
Without scplx_mask I could go as far as lmin=5 :!: with anime with better quality than the one provided by scplx_mask=0.25:lmin=2 .
But in underwater scenes lmin=5 completely screws up.

Best generic values I found so far:
vqmin=2:mbqmin=2:lmin=2.2:scplx_mask=0.15

If you want to test lmin better (you may need to lower it to fit your taste) do it without using scplx_mask.


Bilu

To let you have an idea about how lmin=5 and no scplx_mask is good for anime (clean anime with little gradients):

lmin=2.2:scplx_mask=0.15
37547 KB
avg 3669/5.06
peak 9758/8.60

lmin=5
30662 KB
avg 2989/4.99
peak 9517/6.01

Quality is quite good with lmin=5 except the gradient parts (if they exist) that look agressively quantized. The overall stream looks cleaner, not blocky. And looks much better than using scplx_mask settings as we've tried before.

Again, lmin=5 should be used just for anime.


Bilu

Last settings, mostly tested with underwater scenes but also with anime:

lmin=2.49 was the highest value the underwater scene could handle decently. Using vqmin=1:mbqmin=1 it even got better without growing in filesize.

EDIT: There's residual ringing sometimes, even on monitor it's almost unnoticeable most of the time. I don't think it's noticeable on TV at all, it's pretty acceptable IMHO. If you want to increase quality decrease scplx_mask. IMHO you don't need to mess with the lmin=2.49 value.

Bilu

Guess what: tested the new settings on the same anime where I tested lmin=5 before. Got the same filesize and better gradients :D

30386KB
avg 2963/4.66
peak 8780/6.34

So I guess that if this isn't final, it's very close :)


Bilu

Bilu, could you try this matrix on your encoding and do a comparison of Filesize/Quality.

Its a very simple linear one, but the result would be interesting (cause Im in a hurry and out of home now).

intra_matrix=8,13,18,23,28,33,38,43,13,18,23,28,33 ,38,43,48,18,23,28,33,38,43,48,53,
23,28,33,38,43,48,53,58,28,33,38,43,48,53,58,63,33 ,38,43,48,53,58,63,68,
38,43,48,53,58,63,68,73,43,48,53,58,63,68,73,79

inter_matrix=16,18,20,22,24,26,28,30,18,20,22,24,2 6,28,30,32,20,22,24,26,28,30,32,34,
22,24,26,28,30,32,34,36,24,26,28,30,32,34,36,38,26 ,28,30,32,34,36,38,40,
28,30,32,34,36,38,40,42,30,32,34,36,38,40,42,44

Going to lunch now, will try your matrix as soon as possible :)

Bilu