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

Hi guys,
Sorry for repeating myself but it seems noone notice this question of mine yesterday.
Can someone be positive that using the latest set of arguments and ini file posted by bilu we're not filtering twice (once in the avisynth and once more in mencoder arguments)?
Thanks.
Cheers

Bilu youre right, as you wont see it that much on Tv :lol:
So many users would say "wow!" as the whole movie in average comes out totally clear an fine (well you can assume what Q avg 2 will output).

BUT .... as I personally assume there's potential to get that encoder behaving even better at low bitrate scenes! 8)

Sorry inc, friend, but in this point I don't completely agree with you. I think the better way to set predictions, or better, the better way to get final file size bigger or smaller should be through quality... and that may mean play with vbitrate, but also (else for me) playing with quantizers (of course, without going too far). And this last is the way we're used to with other encoder. You don't change bitrate (well, I do sometimes, but is not the ususal way) in TMPGenc or CCE to change filesize, you change CQ or Q value. And this was my proposal for mencoder, adjust quality through lmin, without raising it too much. I mean, begin with vqmin=1:lmin=1, raise lmin for instance until 2 (even 2.5 if looks well), and if not enough raise vqmin=2:lmin=1.5, and begin raising again lmin.
This of course means file size predictions, but we are used to it, isn't it?. I think (and my tests showed that to me) that limiting bitrate (through vbitrate) will make that we find blocks more often than with lmin...
Sorry my insistance, but I don't see the point of using vqmin=1:lmin=2.49 (I know bilu tested it well, but I also did, and still don't see the point), since quantizers keep always high... even higher than vqmin=2:lmin=1.5.
@rds,
Rui, I think that bilu was feeding mencoder with vobs, so no avs filtering. Anyway, why do you think that there will be double filtering?, is it because scplx_mask?.

Hi Digi.doc,
No, I don't just mean scplx_mask.
I mean all the arguments I don't quite know what they do since the man-pages are not so specifical.
But if you're sure that the arguments you've been using lately are not "touching" the
original movie, then I think we're ok to use avisynth as well.
Thanks for the info.
Cheers

@digitall.doc and incredible
I agree 100% with digitall.doc. Simply there's no way that a encoder can do the best bitrate distribution and still keep an specified average, because it doesn't know what lies ahead. Let's take and extreme example. Imagine the following: you have a movie that starts very calm. A good example is "Missing" (featuring Tommy Lee Jones). After an hour, it becomes full of action. How can the encoder "know" that the last hour has more action and save bitrate? There's no way this can work, you see? Yes, it may not look bad, but the bitrate distribution will not be optimal, never... Unless you have a time machine, like someone once said in a thread. :D

I know you are experienced users and probably know that, I just wanted to make it completelly clear.

I really think lmin in the way to go for 1 pass VBR... Or we can use two pass (but nobody tested yet). :wink:

Ahamm,
Inc. I tried that build and I see that that's 1.0pre3 a very old (last stable!) release of mplayer/mencoder.
With that one you still have to demux your video stream before muxing it with your encoded audio stream.
Don't get me wrong: I love it but it lacks support for other latest arguments.
I agree that later CVS builds also have lot's of other problems.
I think mplayer is still very young and we have to wait some more time until it really stabilises.
Cheers

Ok,
Enough of these mambo-jambo's like the ones I wrote in the newbie guide because of
the Avisynth compatibility.
I just compiled both mplayer and mencoder from 09/04/2004.
Just copy mencoder.exe (and optionally mplayer.exe) to a new and empty folder!
Now try to encode a fake avi built with makeAVIS.
It works doesn't it? At least I hope so...
No codecs.conf (thanks VMesquita) and no worries about dir structure at all.
Sorry for not having done the man pages. I'll do it later today.
Here are the links valid until next monday due to monthly traffic issues:
Mplayer CVS 20040409
Mencoder CVS 20040409
P.S.-I think that maybe 1.0pre3 is still smoother than this one on dark super low motion...

thanx rds, I'm going to give your compilation a try in a minute.
I think that inc, bilu and I are using three different compilations, and I think we have different output from each. Let's see if your compilation is the one we all begin to use. It'll be easier to share results and make improvements. I don't mind to use one or another, I "just" ask I can feed directly vobs to it (faster encoding) and I can use raw output. I hope yours will be the consensum (is this an english word?). BTW, what ffmpeg version did you put in?.
Well, I already tested 2pass (it was in the prehistory of this thread, and I posted then), and if I remember well, I used then vbitrate=maxrate=8000 (to test it), and obtained an almost constant Q value of 2. But it takes, of course, double of time. We could explore this way, but I don't see a way to make it faster, and not double time.

Hi Digi.doc,
Yes, no problems loading both VOB and AVI, here.
I suppose we could even feed it many other formats besides these two :wink: .
I just did my own compiling because since we started using other versions besides
official 1.0pre3 I just haven't been able to use makeAVIS anymore...
Have someone experienced the same?
I did my compiling with MinGW and MSIS.
I would do it with Cygwin but I don't know which components to download...
Maybe Vinicius could give me some help on it :wink:
Cheers

rds,
already downloaded them. I'll take a look now. What about the version of ffmpeg you compiled in?.
It would be nice you also compiled a version with cygwim, as vinicius did, since in my test it's faster (1-2 fps :wink: ) than with MinGW.
Thanx again for the effort

Looks like I missed, this thread is bigger everyday... :D
You're right, 2-pass will double time, and there's no way to help it. But mencoder is very fast, so maybe it's worth using 2-pass if the quality is better. I actually tried 1-pass once (a lot of time ago, I just remembered now), and the quality was much better than 2pass but the command-lines were much different from the ones used today (I think I was using vbitrate), so it doesn't mean much.

Let's get back to testing. Since most of you are trying to find the best mencoder parameters, I decide to improve this AVI input thing, because mencoder is much faster without avisynth. I just wanted to let you know that I am working a good filtering for MPEG4 matherial, using internal filters. Because I want to test the filters and not the compression itself, I am using MJPEG with vqsacle=1, because looks like mencoder can't use Huffyuv YUY2, only huffyuv YV12 which doesn't have a codec in windows. I tried forcing colorsparce conversion using the internal filter yuy2, but it doesn't work. Anyone knows how to fix it? :wink:

Hi Digi.doc,
I just downloaded the CVS tarball.
Didn't make any changes on the libavcodec version that came with it.
I really wanted to know if I could do it.
Now I can refine it later today :D
Cheers

Just use the standard components. When you unpack mplayer package and run configure, it will tell you if something is missing. I could tell you the exact components I have but looks like my cygwin install is now broken, I have to reinstall it again... :(

@ Digi.doc

Sorry I expolained that a bit confusing.
I meant that I would like to use the PAREMETER Vbitrate for determining endfilesize .... as I saw/see that its possible.
Shure that this will affect the Q curve and therefore the quality.

I will go further with my tests....

(Im reallly mega pissed off as I try to get Knoppix on another partition running where I need to have an exchange possibility to write to NTFS Volumes..... means Encoding using mencoder in Linux and the encode will be safed on a NTFS Partition so I can author the dvd afterwards in Windows)
:cry:

The only way to write to a NTFS partition from linux right now is using the captive NTFS drivers. They actually load ntfskrnl.exe and ntfs.sys from Windows XP in linux and let you use for read and writing. The latest NTFS driver (the one that comes with most linux) does not allow writting, unfortunatelly. And if I remember correctly, captive-ntfs doesn't come with any version with knoppix, but you can add yourself if you want (I never tried).
Captive is free, get it here: http://www.jankratochvil.net/project/captive/

I did exactly try to install the captive already, ... but no luck ....

To get not offtopic in here I gonna open a new threat in the linux section, and I would apriciate it Vmesquita if you could help me there :D

And I'll meet you both there :wink:

Just an small update: Its possible to decode yv12 huffyuv in windows using ffdshow. Since it's a directshow filter, the only way to use it in aviynth is using directshowsource, but work perfectly. Another idea to test filters is use the lossless ffv1, but looks like it doesn't decode correctly via avisynth.

I just did a cygwin build of mencoder using the latest CVS (grabbed using CVS command) and the latest FFMPEG (also straight from cvs).

<edit>Removed links for old builds, get the new link below</edit>

Hi VM,
I tried your compilation of mencoder on cygwin and I noticed several issues:
1st - I can't use fake avis made with makeAVIS with it!
2nd - It's bundled with a lot of dlls instead of cygwin1.dll. I did my compilation on cygwin and it only requires cygwin1.dll...
3rd - Using so many dlls it makes the package bigger 6.44Mb instead of mine 5,00Mb. Though your mencoder.exe is 3.84Mb and mine is 3,93Mb.

I've compiled mencoder with MinGW and with Cygwin.
MinGW makes the whole package smaller for distribution.
Cygwin is a bit larger but IT IS faster encoding than MinGW version.
Could you explain these differences since you work with Cygwin for longer than I do (just 24h...).
Cheers