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