I hope to have time to start testing today on my company's PIII-500 laptop w/192 MB RAM and 2GB free HD space.

Just to fit into your testing standards, what tools do you use besides Bitrate Viewer? VirtualDubMod? Others?

I already downloaded BV and VDMod for install after work. Please tell if if there's something else to install.

@vhelp: I've already downloaded your sample, haven't seen it yet.
My version is PAL.

Bilu

ok, great.

"The Fifth Element" ...
But, just for your info, I ripped the dvd's chapter 6 and 7 for these tests. I
found it worth using in my tests, because of the bitrate spikes issues. I
recall jellygoose working w/ this issues of b-spiking too, and even did the
same scene, and got the same results (w/ respects to b-spiles) I think that
jellygoose is PAL too.

-vhelp

Hi friends,
I didn't want to, but at last I installed another tool in my PC: bitrate viewer.
Well bilu, I think you were waiting for the results in that explosion-blocking scene:
- when using vbitrate=vmax=5000, vqsquish=0, vrc=tex, max_b_frames=1, --> max bitrate 4574 (avg Q 2.15)
- with vbitrate=vmax=8000, vqsquish=1, vrc=tex, vqblur=0, max_b=2, --> max bitrate 4340 (avg Q 2.22)
- with vbitrate=vmax=8000, vqsquish=1, vrc=tex, vqblur=0, max_b=2, noise added, --> max bitrate 4408 (avg Q 2.66)
- and finally, I tried vb_qfactor=1 and vb_qoffset=0 (rest of parameters as last one), --> max bitrate 5414 (avg Q 2)
8O YES bilu, you knew that. After decreasing Q in B frames (through vb_qfactor/offset), average Q decreased and bitrate raised. Filesize grew from 6499 to 7745 kb. And visually got much less blocks, still noticeable on PC screen (hope we'll be able to get rid of them).
What I do next, what I do next, what I do next?. :lol: :lol:
Taking the mood this encoder :?: .
Mencoder didn't take profit of all the bitrate available (up 8000), maybe can't do that better and already completely compressed the image, but now there are less blocks (but still they are)

@vhelp
the scene I'm refering to is between frames 4854-4876. There's a scene some minutes later, when the jedis are following the person trying to kill queen Midala, that I believe is still more bitrate demanding. Maybe I'll ready tests with this new sample, to see if mencoder can raise bitrate to limits available, without going over.

Well, don't want to make it too long, but we have new parameters to play with.

@ all,
also PAL land here

Hi all,
Since J3lly is in Germany he is definitly in PAL Land as well as myself.
Sure would like to have the same movie you guys are trying.
That way we could do more in less time in terms of testing.
Have we given up on finding a good clip in the INet for testings?
That sure would be great.
Cheers

Talking about me behind my back huh :?: :!: :P

Yep, PAL sources only here. Well I'd just propose everybody should get that Fifth Element DVD, and encode exactly that explosion scene. It's perfect to test these spikes. And it's a great movie anyway so you won't regret you got that on DVD. :wink: 8)

vhelp's scene is from 5th Element, digitall.doc's scene is from Star Wars.

Just to avoid filling this thread with unrelated stuff, could someone give a hand here? ;)

http://www.kvcd.net/forum/viewtopic.php?t=9260

thanks,
Bilu

Hmmm... you already have tried the default matrix, which is h.263.

Why not try the other one? ;)
NOTE: No garantees of improvement, out of ideas for now :roll:

Bilu

Well bilu,
I already changed Notch matrix with standard matrix. I think I posted it, when I tried to improve image in my tests and raise bitrate. In fact, my last tests changing B frame quantizer where done with standard matrix.

Related to mpeg quantizers, I tried to use it. I just included in the command-line the function mpeg_quant, but mencoder gave error and didn't encode. I tried then giving it a value (mpeg_quant=0 or 1) and didn't work also, so I dropped it. How can I activate mpeg_quant.

Maybe you can't and this parameter is only used for MPEG-4 encodes :?

Bilu

I tried this under w98gold, and it just crashes mencoder :!:
If I put a 0 (or no) as param value, it works (cause 0 or no, mens disabled)
..which tells me that we are using this command param correctly.

Also, on last line of my error, it same:

-vhelp

Yes, vhelp, that was the error I got when tried to employ mpeg quantizers. Don't know if we're doing something wrong, because under ffvfw you can activate mpeg quantizers, so the codec can work with them. :arrow: :?:

Or ignore them ;)

I've seen no reference to H.263 quants in FFMPEG docs, just in Mencoder docs.

Bilu

Hi :) ,
as it seems that this became our "official" mencoder thread, I'll post here my last experiences:
you know from my previous posts I've been testing an scene in StarWars II where I was getting blocks...
I've been trying 2pass encoding... well, first of all it doubles encoding time, but maybe it worth.
Command-line:
As you can see I tried to make it simple, removing quality functions.
I get less bitrate peak in this scene (about 4700, in 1 pass with other settings got 5400), with Q about 2 (same as 1 pass) but visually almost the same blocks (or even less :?: ). And later comes a more bitrate-demanding scene, that with ffvfw got bitrate above 10000, and with mencoder 2pass I get bitrate 7700.
To sum up: very satisfied.
How can we speed up the proccess (if possible) or are we to stay in 1 pass and improve it?.
... suggestions :?: :arrow: :idea:

Hi digitall.doc :)
I am very impressed with this encoder's quality under 1 pass.
I sure will try 2-pass but not right now.
I think it would be better to understand a bit more about mencoder on single pass and then tweak arguments to shoot at 2-pass.
Don't know if others agree with me or not.
Everybody:please post your oppinions on this issue.
Cheers

EDIT: BTW you're using GOP=15. Encoding at (720/704)x576?

Hi guys.

I'm also w/ rds. 1 pass should be all. But, I'm not pushing 2p over the edge.
You guys make the decision - - either to encorporate or not to inc. :lol:

I prefer to stick to 1p just because its less steps. Maybe is quality is really
your main concirn, then by all means, push it to the limit, if you can. But,
then, I gotta think about TMPG for this maybe. No, not ME using TMPG under
2p. I would never cross that boarder - thus far.

OT 1: I've ben wondering :roll: just how many other video sources can we
open (or is limited under MEncoder) cause, so far, from my understanding,
we only have the ability to either:

* open from an true .avi source (no frameserving or vdub/avisynth)
* use makeAVIS (either by using .reg hack or XP)

So far, W98 can not open/process makeAVIS sources. It can only open true
.AVI sources. I've spent approx a week trying to figure this one out, and
then in the middle of this week, I really got into it, because for me, my sources
are always from frameserved references (ie, vdub/avisynth) and so far, I
can't open these, which pretty much makes my work in mencoder useless,
unless I don't mind double-duty work of re-writing a filtered new .AVI source,
which I'm not about to start doing :!:
Currently, I'm pretty disapointed at this limitation w/ mencoder not being
able to accept any form of frameservers (ie, vdub/avisynth) under W98 :!:
I can't see anybody actually wanting to continue testing mencoder, if they
have to rewrite true .AVI source files. I have two or three so far, and I'm
not about to make any more. Its just too inensive a job to have to do, let
alog having to do a whole movie, every day :roll: This is not what I'm going
to be doing.

OT 2:
On the other hand, through my trial and tribulations w/ mencoder's lack of
frameserving abilities ( W98, others ?? ) I've ben able to figure out how to
get mencoder to open my DV files.. and they actually encoded.. quite well
I must say. These DV source files were my ADVC-100 captures of my VHS
SW WS SE that I still have on my hd. I was pleased that the quality was
pretty good from vhs sources :lol: but still, even if I were able to open up
these DV files in mencoder to encode, at this given juncture, you can't do
any filtering (from frameservers) and I have plenty of good filtering processes
and methods that I use lots, under vdub :roll:

Well, that's ben my long and busy day's jeorney thus far 8)

@ rds,
looks like mencoder for W98 is proving hart-ship for me (and others here,
I'll assume) And, if things don't get better, it looks like I might be heading
for a new direction (or hobby to toy with elsewheres)

-vhelp

Hi,
I wasn't really proposing you to move to 2pass: it means doubling the encoding time. Just posting my experience: it works, and works well. But I'm focused in improving 1pass. With your help. I've posted several settings for 1pass I don't know if you tried, and how can be improved.
@Rui
yep, encoding at 704x576

@vhelp and digitall.doc,
Hi guys,
I'm very concerned right now in finding out if vhelp is the only one having problems
under Win98 or if it's an OS specific problem.
I can't find anyone else with Win98 or WinME willing to give it a shot, right now.
Unfortunatly, at least here in Portugal, Win98 gave place to WinXP pretty fast.
So, the few guys I know with Win98 have no time right now to assist me on some trials...
If mencoder has an issue with Win98 and WinME it's an enormous step back and I'll start aiming
more at ffvfw instead because with the latest vbv buffer developments by Kwag it could be 100% working
in the next...few hours?
Ok, maybe days or weeks, but that would be in a short period and that wouldn't mean we have
to stop testing it because we'll be able to patch every movie we've been encoding since the begining.
So, right now, I'm working on a small guide for mencoder to see if we can catch some more guys attention.
Hopefully some of them are 98 or ME and we'll have more feedback besides vhelp's.
I hope I have it finished by tomorrow, but since I have so many "real life" things to do during
the weekend I really can't promise anything.
Keep up with the testing spirit and maybe we'll find a way to it under every Win32 OS.
I wonder if Jorel has tested it yet :idea: .
I remember he has a lot of Windows "images" created with Ghost or something like that.
I bet he could try it. Maybe he'll even like it if it works :wink:
So 1-pass or 2-pass right now is maybe not a so big issue.
But for those with Win2000 or WinXP I'm not saying they should stop testing it :wink:
I'll "see" you soon.
Cheers

Well, Rui, I begun testing ffvfw, and if I focused more on mencoder was due to its speed (faster than ffvfw), and that bilu (hi Bruno, how are your testings) managed to explain functions in a way I understood better mencoder than ffvfw and knew better what I was doing (and this is essential for me, to employ any encoder). I won't leave testings with ffvfw, but I'll keep mainly in mencoder (even I don't know right know how to improve it, need all your help).
And my main problem with ffvfw (apart from encoding speed) was with bitrate (not with vbv that we solved adjusting bitrate slide earlier. Now, with poerschr way of encoding, you're right we need to change vbv, but I guess is a question of time managing to ffvfw doing this without having to mess the m2v file) too high/too low. As I still didn't try poerschr (or was marcellus: sorry if I'm wrong) way to tweak ffvfw, I don't know if the bitrate issue is solved. But I still find we don't really know how to employ ffvfw (maybe Milan's help...)
So, here I'm back again to mencoder :wink:

Hi digitall.doc,
I also think that mencoder could really be the way to go.
It's got quality, it's got speed, it adapts to all our needs of encoding (KVCD and KDVD)
although it's a lot better for higher bitrates.
Most of all, it's still under development by a team.
This could come to be a very well succeeded encoder in the near future if one of the guys can
do a good package with it similar to dvd2svcd.
That would put mencoder in a very strong/top position.
But we must remember that the mentioned developer team is aiming almost 100% to Linux.
And we know how these guys forget about win32 guys like us. Not that they mean to, btw...
So I'll do the same as you, stick more with mencoder with an eye at ffvfw, if I can find
a way to keep vhelp and all the win98 users in the team.

:!: I must remind you all that, so far, I haven't seen any feedback from win98 or winme users,
that are testing mencoder.
This is somehow very important for us so if some of you could post us your experiences... :!:
Cheers every1

Morning everyone :lol:

I've got some gusto power under my belt this early morning :hammer:

@ rds,

I have some new ideas that I'd like to throw at this MEncoder problem some
of us (if not ALL w98/se/me) users' are experiencing. My guess or huntch
is that these users have given up on MC since it's very rebelious in its features.
Well, that's just another one of my assumptions. Anyways..

Here's what I am proposing that we (w/ yours and others help here) do.

I have a press pc sitting behind me that is pressing upon me to give him a
try. He keeps telling me that he is not tainted w/ drivers and various versions
of mencoder/ffdshow/ffvfw. In fact, he tells me he does not have any of them :!:
.
.
I'd like to take this 2nd pc (equipt w/ W98Gold) and install ONLY THE
NECESSARY MEncoder SOFTARE APPS/DRIVERS/CONFS etc. on it and
run some testings on it to see if it will encode my files from makeAVIS.
.
.
I need to be sure that I have ONLY the necessary software/apps for this pc.
It's an untouched pc.
.
.
I have a theory that maybe perhaps my other pc that's given me the trouble
is far too tainted w/ drivers and colorspace issues and so on, that the cause
for makeAVIS not working could be that very reason. But, I need to rule
this out by first trying on an untouched pc.
If we can do this, then I'll see about imaging it now and we (you) can
gather a listing of files (latest versions) for me to install on it. Should anything
go wrong, I can de-image it to it's fresh state I left :!:

I've ben toying w/ the codec.config file and have a better understanding of
it's params now. So, I'm ready for it too :!:

:idea: I also belieave that the codec.conf is the key (or partial) to getting
makeAVIS to work on w98. That's why I have ben messing with it since
yesterday, ALL DAY. Heck, I even developed a front-end tool to just it
alone, to help me find the right setting.

But, I still think we should try and figure out a way to get vdub to work with
mencoder to. And, also avisynth scripts to (w/out the need for makeAVIS)
But, as I was saying, codec.config is key because its the "driver" for MEncoder
to open .avi sources :lol: and, having the right driver on your pc and no issues
w/ colorspace and whatnot, might be key also :!: but only add'l testing will
tell.

But, I agree with you.. mencoder shows great promise. All it really needs
is a good pair of paints/shirt/tie (GUI) which I'm still developing, (others
can do the same, as they wish, too) and sky is the limit :mrgreen:

The 2nd PC to the test.. .. ..
@ all - - Please, ..do get me a list preapred for work :!:

Well, let me start by getting myself a fresh cup of coffee, and begin pulling
more of my hair out.

Chereo all,
-vhelp

Hi vhelp,
don't know if understood you well, but if you wanted a list of software to be installed in this 2nd PC, look at the nice sticky rds wrote, and is at the begining of thread list. And there you'll find also a mencoder command-list to begin testing with.
Sorry if I don't give any feedback with your W98 problems, but I don't have the way neither the knowledge to help you.
Hope you'll be able to solve it soon.

Well, this maybe something like double posting, but I wanted to share with people coming to this thread a test I did comparing ffvfw and mencoder two-pass encoding.
To sum up, mencoder was faster (about 10 fps in each pass, vs 7 fps max in ffvfw), with a Q value far stable around 2 (some people consider that a stable Q value is not as good, but I guess this is true when bitrate goes above maximum, and in my tests max bitrate was around 5700 in mencoder and 5600 in ffvfw). Ffvfw took around 2 seconds to change from an initial Q value of 4 down to 2, and Q also didn't change along the test.
My sample is as always 1000 frames of StarWars II.
Maybe the difference is due to different settings in both "encoders", but these are my results. And again fingers up for mencoder.
BTW, is there a new release of mencoder for windows. I don't know, just asking (and too lazy to look for mencoder homepage...) :?

Guys,

I didn't had time to test since my last post and won't have the time to test until at least the next Friday. :(

But I have an idea that can become a greater contribution if I or somebody else does it: the MPlayer team has been focused on porting MPlayer for Windows, with Mencoder being carried behind as part of the code.

I'm almost sure that, unlike MPlayer, there is little need for Windows-specific code for Mencoder to work.

So it may be possible to do a direct CVS compile of Mencoder that would bring a lot of neat features to the Windows port, namely the capability for interlaced encodes that would enable us to do direct NTSC KDVDs without need for IVTC and pulldown or deinterlacers.

From what I know so far the SVCD resolutions also have the same vertical lines as DVDs, the only exception being VCDs. So only VCDs would need treatment when working with NTSC Telecined sources - selecting one field would not be enough.

When the direct CVS compile is done, someone has also to convert the CVS man page to HTML.

If nobody does it during next week I'll do it on the week after ;)

Cheers,
Bilu

Good thinking Portuguese friend :wink: .
The problem is I don't have the needed knowledge/skills to do that.
Can someone give it a shot?
Cheers

Had a look at the current CVS man page. Here's a list of interesting stuff:

About CVS compile, I haven't looked yet to to process, but I've seen that I have to compile Mplayer also: theres a configure --disable-mencoder switch for the compile, but there is no --disable-mplayer switch :twisted:


Explanations for the parameters I posted will come later :)


Bilu

Hi bilu,
you always illustrate me :o
Sorry me if i don't give too much feedback on NTSC, inverse telecine, encoding interlaced, and so on, since I don't run into problems with this issues and don't have much experience. Cannot help much.
I hope that your next CVS compile will give us much improvements, and as I see by your last post, it seems it will do (I read new parameters to play with) :D
Here I am, waiting for your next post, explaining these new toys... :wink:

Hya,
It's good to have a guy on our team interested in ntsc picture treatment.
Even if he lives in PAL land 8)
Forgive me for my ignorance, but since I live in PAL land I don't think I need to do any deinterlacing, right?
At least all my movies look ok :lol:
But anyway, doesn't avisynth correct that issue too, bilu :?:
Or are you just thinking about using internal filtering to gain speed :?:
Ok, maybe one day we notice that with all the avisynth filters being imported by mencoder,
we don't need avisynth anymore :roll:
Anyway, I was wondering, how have the Linux guys dealt with such issues since they use Mencoder, anyway?
Has it been implemented in the Linux version for some time?
Keep up with the good work :)
Cheers

Morning guys.

Yes, I could see avisynth "moving" towards (or shall I say, into) MEncoder
artchitecture world :lol: but actually, MEn already has many powerful filter
rich features. And most are optimized for MEn. The only thing we need to
do at this stage (after working out the other kinks) is to figure them out in
our daily MEncoding projects. ** note, don't get me wrong.. I'm not about
to drop TMPG, but for the moment, I'm :hammer: 'ing away at MEn for now :lol:
Also, I'm undoubtlely run comparison test between the two :!:

My next encounter w/ MEn will be the IVTC stage. As we speak, I use the
following procedure to do a perfect IVTC (when source is TRUE film) This is
specific to TMPG projects of mine:

* dvd rip (if from dvd - these are only test, I have no need t rip my dvds)
...But, for captures.. if source is TRUE film ... skip over these items..
* smartripper
* dvd2avi v1.85 using 29.970 fps
* VFAPI to suedo .AVI
* open inside vdub
* do my "special" vdub filtering :mrgreen:
* now, import into my "special" IVTC script in avisynth
* next, frameserve to TMPG and encode to perfect IVTC.
...I have other IVTC methods that I debug, but the one I'm using
...seems to yield the best results. You'r mileage will vary w/ your method :wink:

Of course, if your source is based off a "capture" project, then you could
skip the DVD stuff and move on to "open inside vdub.."

Yes, there are too many steps in between. MEn could quite possibly solve
that problem in one shot. But, it requires a little learning curve. I'm on
to it now.. and I don't know a thing about my first step in MEn's IVTC process.

I'm not sure what bilu means by Interlace (if someone were to port or comiple
thew new CVS under windows) I know that MEn has Interlace features. There is
even a param string for it: xvidencopts=interlacing (yes/no) but I did
do a few Interlaced source, and I felt that MEn did them very well. But, even
if you can't work out interlacing w/ MEn, at least you can now use your favorite
.AVS Interlace/deInterlace script inside MEn :P

For now, MEncoder is very interesting to me, and I'm having some fun working
with it (though I've had lots of upsets) but for now, I'll continue messing
around with it.

Cheers guys,
-vhelp

Ok, I am compiling this beast... :D Now it's just a matter of finding the right configure options. Till now I found out this ones are needed:
I am using cygwin, looks like the guy who did the previous compile used MinGW (probably with MSYS), but I am more familiarized with cygwin. :D
I'll post a download link as soon as everything is ready.

:hopline: hey vinicius, here we are all waiting like :angel: ,



and when you get it we'll :jawdrop: ,
and :ole: for you.
:lol: :lol:
BTW, is there any mencoder forum where we could keep informed of latest improvements in new mencoder versions. Or we could ask our doubts (for instance, I would like to activate mpeg_quant since, AFAIK, we are encoding with H.263 quantization, and everytime I tried to activate it, mencoder crashes). I would also like to know how to improve speed (if possible tweaking settings), take advantage of internal filters,... well, questions, questions, questions.
I browsed the page from I downloaded mencoder, but didn't find where to investigate this.

EDIT: I would also ask about those f**king PTS SCR errors, and how to sort them out :evil:

Here it goes:

http://www.jltoca.uaivip.com.br/file...-29-2-2004.zip

This is the compiled from today's CVS and libavcodec has also been updated from today's FFMPEG CVS. I also updated the manpage and included in docs folder, along with some extra documentation. The package also included the correct codecs.conf file. I hope you enjoy.

:ole:
GREAT stuff VM :!:
Got only three words for you buddy: Good, Damn, Job :!: :wink:
I'm gonna try it ASAP.
Cheers

Hi vmesquita:
:jawdrop: :ole:
(I promised :wink: )
Already downloading...
I should take it a look before asking, but I can't wait:
- first I see the filesize is smaller than version we use, did you manage to make it smaller (you see, I don't know a word on compiling :oops: )?, is it also faster (I know, I know: test it)?
- in man_page, do they specify what are the changes, bugfixes,... from previous version?
Well, I'll take a look.
Thanx a lot, very helpful indeed.

EDIT: I knew i should have taken a look first. Since there's no mplayer, the file is smaller. But mencoder still got smaller, does this mean anything?. There's also a cygwin1.dll, I suppose that needed to make work the compilation, that wasn't in the previous release. Won't it also slow down performance?. Just curiosity, I'm, We're all very grateful to your job and effort helping us. :wink:

The package is smaller because it doesn't include mplayer... Nobody is using it here, so I thought people would enjoy better a smaller download. :D I don't know if it's faster, I did using cygwin, the previous compilation was done with MinGW. But it can be faster by optimizing for each CPU. But you would need many compiles this way. A fast test showed that compiling specific for atlhonXP makes it 10% faster.
I just converted the man page to HTML, but didn't take a deep look...

Hi vmes..

Great :mrgreen:

I'm D/L'ing it as we speak. And, I will test it out. But, my question to you
is this..

* all you did was re-compile it ??
* and, as such, we are just testing it to see if it works in command-line mode,
....aren't we ??

Please let me (us drones) know what else is in store, but I'd like to know
what exactly it is that I'm am about to tinker with :mrgreen:

Great, Cheers, and thanks again pal,
-vhelp

@digitall.doc
Like I said, the previous compilation was done using MinGW. I compiled using cygwin, and cygwin-compiled stuff need this dll cygwin1.dll. About performance, I have no idea, I did a fast test and it seems to perform about the same as the old executable.

@vhelp
I just got the latest source from CVS and recompiled. The latest source has the features bilu described. I also included the updated manual with that features. Mencoder uses libavcodec from FFMPEG (you have to grab it separatelly when downloading from CVS), so I decided to use the latest libavcodec.
I didn't took the time to do extensive tests (playing with it right now). :D

Hi VM,
In fact I've been using it for a while already.
I just drop the avi/m2v/vob over the mplayer.exe and watch mencoder's results with mplayer.
Not a big issue though.
I'll keep using powerdvd that came with my DVD.
Thanks anyway

Hi vmesquita and all around here,
I already tested your new mencoder compilation (just two samples, to "taste" it).
Related to speed I think is faster: this samples I made earlier with previous version, run at 6 fps. With your compilation it varies between 6 and 7 fps (I know, slow, but encoding at 16:9, 704x576, maxrate 8000 and high quality functions,... and my PC is not a Ferrari :( )
Related to error messages: I was already getting this message, always at the begining of the encoding, with previous compilation:
But doesn't stop encoding and later I don't see errors in stream. I thought it might be due to makeAVIS, but I fed mencoder directly with a vob file, and got the same message. I get it also with new compilation. Any idea about how to sole this?.
And I get two new erros. The first one appears before starting encoding:
Doesn't seem dangerous, just a warning, since I used minrate=300 and maxrate=8000.
The second error worries me more:
Also appears at the begining of the encoding (after Unknown block type error), doesn't stop encoding, and I don't see any errors later in the stream. But I'n afraid it will give me later errors when muxing. What do you think?.

@ digitall,

try doing TWO types of encodes, using the same distance (time/length)

* one for clip w/ high action, and
* another, for low to no action.

I have a fealing that the reason we (I know I do) get errors in my MEn encodes
is because when we reach a certain point in high action in our frames to
encode, the encoder goes kookoo, and the "threshhold" is over-bearing to
the encoding process. I know I get various kinds of error, but if I feed in a
quite scenes, so far, I get no errors or warnings, and encodes go smoothely.

What puzzles me is the fact that dispite the many errors that can poor down
one's pc screen, when the final encode is played, all looks well. It makes me
go :roll: hmmm....

Other times, when I'm encoding small clips, the encode will go smooth, and
then all the sudden, screen poors with errors, then things go smooth again,
(no errors) and then more errors poor out. This is dependant on the scenes
and sources that I encode in my various stages. I'm trying to narrow it down
to certain scene "threshold" quite vs. high, quiet-to-high vs. quiet-semi-high
etc etc. :roll:

OT: by the way, does anybody KNOW HOW TO crop "manually", instead of
having MEn do it automacally ??
I need to crop manaully, and the auto is not for me. Please, help anybody !! Thanks..
-vhelp

Hi vhelp,
Imagine you have a DVD 720x576.
Also imagine that the black bands on that DVD are 12 on top and 12 on bottom.
Open up FitCD or MStacker and get the resizing figures.
It would give you for a non-anamorphic 704x576 XVCD:
Crop 712x552
Resize 688x400
Note: values taken from FitCD 1.1.3pre1!
As far as I know from "shh" the developer of FitCD on which MSatcker is based, MStaker needs
to be updated on some of the calculations.
Now put these arguments in mencoder:
:crop=720,552:size=688,400:expand=704,576:
These would go on the -lavcopts arguments.
Worked for me.
Anyway bilu may give you better advise.
Cheers