CONCLUSION! (for me as i did tests)

- mencoder20040403 gots a BUG in vbitrate! As vbitrate isnt respected! Which could be easely used for filesize determination!

- mencoder20040405 gots also a BUG as in my case it also says that there the makeavis codec is missed although its placed where it has to be.

- mencoder (? my version I do have) respects the vbitrate!! Means if I do say vbitrate=2000 ... almost a avg bitrate of 2000 comes out ... EVEN if used with bilus script posted above (the posting where he added the mercedes cabrio pic)

So friends watch out as some issues do base on diff. mencoder builds we do use 8O

@Incredible
Thank you for clearing that out for me! :D So which version should I use - and where can I download it :?: I didn't keep my previous version and I don't remember where I downloaded it :oops: .

EDIT:
mencoder20031126 would be nice since I saw the great results you got with that version :!: :wink:

Get the version I do use here.
(this link will expire tomorrow evening! as I want to avoid traffic overload!)

bilu with that build I was able to use your last script (mercedes cabrio posting) incl. an very near approach to the desired avg bitrate by just using Vbitrate as factor!

But anyway if used my build or yours .... The quantizer curve does behave by beeing kept at ca. 2 means still blocks on dark blue underwaterscenes ... but at other scenes so it does not play that abitary crazy.

Here from your script:
http://www.digitalfaq.com/archives/i.../2004/04/3.jpg

But that could maybe tweaked by some parameters as I want the Q curve to be more adaptive (but on the other hand NOT! abitary), means a bit more quantisation up to 3 on high bitrate scenes, which also avoids peaks and less quantisation down to 1 on low bitrate scenes.

... I was afraid of that. In fact, I think I already advised about this issue. More data: with last bilu compilation, I cannot encode directly from vob (neither with official compilation), while with the compilation I'm using I can.

Inc, sorry me for being a pain, but how can mencoder in 1pass respect vbitrate? I don't say you're wrong, for sure not, but if there's a way a encoder can do this, it can't be keeping constant quality, isn't it?.

Every time I'm understanding less things (Socrates?) :roll:

Ask the Lord! :lol:

I dont know but as I do use mencoder with my suggested script already some time (on captures with no problems!!! First problems with that clean K19 DVD source) I was at almost every prediction very very near, Means if I did set for example Vbitrate 2000 then once a 1920 or a 2087 (just for explaing) was the result.

:D
I will download it right away. Nice to get a version that works instead of trying to use a non-working one :wink: . Will be fun to finally be able to start experimenting with MEncoder.
Once again - thank you very much :!:

@Incredible
How do you use Slicer() with this encoder? I'm guessing you make 2 fake avi's, 1 for each offset, but how do you change the "CQ" value (or what it's called in MEncoder) :?:

With my mencoder build i just do change vbitrate, thats all :lol:

According to slicer .. you are correct!

As that encoder is very correct I just use a pong, means no 2 diff. offset turns. And I do one MakeAvis File for prediction and another for the whole encoding ... where I everytime do place the avsscript within the avi-fake! (option of makeavis).

Slicer(2,15,05,2,0) .... thats all.

2%ofMovie, Goplength15, Offset05, 2GopsSlicelenghtMeans30framesPerSlice, NoSubtitels

I do use an Offset of 05 as I dont want the dark intro at the movies beginning to be predictionned = more accuracy ... but mencoder so or so is very acurate. 8)

Great! :) Nice and easy.

Hi guys,
Hey Inc., thanks for the info on the non-working mencoder release.
Also to Audioslave for advising me of that :D

@bilu, Digi.doc,etc...
I've been wondering. Mencoder has it's own set of filters that do more or less what we do with avisynth scripts, right?
I'm not quite sure if the arguments we're using with mencoder are not "overridding" our scripts, then.
I only thought about saying this because I remembered that I once saw bilu saying that he didn't feel so bad about not using avs since he was going to use mencoder under BSD/Linux.
So can someone be positive that using the latest set of arguments and ini file posted by bilu we're not double timing filterings?
Thanks.
Cheers

@Incredible
Would you mind posting your *.bat and *.ini settings?
I'm aiming at trying to make a KSVCD as my first project so if anyone have any suggestions about settings I would be grateful! :D

First try to go to KDVD! Then you can try to approach to the birate control which is needed ror KsVCD. As KsVCD needs EVEN a smaller room for bitrate dynmics for breathing!

Inc, sorry, but your answer didn't clarify my ideas that much :?

I took a look at your BitrateViewer graphic, and as you state it's almost constant quantizer around 2. And, also as you posted, we should better go for constant quality than for constant quantizer. Where your settings vqmin=1:lmin=2.49?.
In my tests I get more dynamic quantizer values, I think that lmin so bigger than vqmin maybe fixes quantizer too much. Or maybe it's related to vbitrate setting (I see you get a bitrate peak around 4500 and min around 300), but the blocks appear in a low bitrate zone, where quantizer should go down close to 1 (if vqmin=1), and it doesn't. Which rate control mode do you use?.

Sometimes I think we're still too far to understand this ffmpeg thing... :(

Well it does not clearify that much as I really don't know why its that exact (with my script) .... yesterday night I did an encode using biuls script, but interlaced settings deleted and set vrc_eq=tex as he recommended it afterwards.

Im at work now and getting home very late, so I can only post you ad midnight the exact settings. BTW with bilus settings when set vbitrate to 2050 a avg Bitrate of 1834 came out! So my script is in there more exact BUT bilus script does deliver beside a almost constant Q at 2 a veeeery good!!! average picture above 800kbit parts and the bitrate peak was solved when encoding K19 .... but still I got some bitrate lows at almost 150kbit! And thats the only problem, that at theses scenes some blocks (well, for my eyes) do occur as Q is still at approx. 2.

So wait for tonight .. Ill give you my settings.

BTW: The pic above is JUST FOR EXPLANATION! Means its from asliced sample, so min and max are not "realworld" as they do peak a bit more. But the "look" of Q is the same when encoding FULL.

@inc

Have a look
http://www.kvcd.net/forum/viewtopic.php?t=10132

and compare results.


Bilu

inc,
:idea: you're not using vrc_minrate, isn't it?. Why don't you try again with minrate set at 300?. Maybe, just maybe, if mencoder doesn't go down to 150... no blocks... well, just an idea.

Im right testing Knoppix Linux as where Im actualy wrting from (Konqueror) .... I couldn't resist it :D
Yep was using Vrc_minrate! It was set to 500 and even then it goes down till 150kbit ... wait until I switched to windows again and Ill inform you better.

inc,
OK, not minrate. What about vbitrate?. Try a crazy value, that mencoder won't keep as average bitrate, and see if still appear those blocks. Try the same value you used for maxrate.

I tried (on MY Build)that vrc_maxrate set very high BUT that didnt solve the problem and on the other hand prediction wasnt possible anymore! And thats the way: to set predictions by using vbitrate and not the quantizer etc.

Here my last settings .... Vbitrate was set to 2100 but resulted in 1700, anyway I could just change the avg bitrate using "that" parameter.

As said, the resulted Video (full encode) is SUPERB for a avg bitrate at approx. 1700kbit! ---- a avg Quantizer of 2! (CCE or TmpgEnc can only dream of it) --- just the little issues of still bitrate drops at lower scenes and also to high quantizer of 2 at low bitrate scenes (as seen in my last BV pic which was from a sliced stream)... thats all.

It shouldn't happen with lmin=1.

But is it noticeable on TV? And how does lmin=2.49 + Notch compare to lmin=1 + your last matrices when watching on TV?

Bilu