Set of 4 Mencoder tests: mind loaning us some CPU cycles?
 

I have a PIII-500 laptop with performances between 5 and 7 fps using Mencoder.
So I'm asking for your help to make 4 tests with 30 minutes samples! :)

Your feedback we'll be valuable to all of those who will be making 1-pass encodes :)

Use my build: http://clientes.netvisao.pt/bilu/bru...r20040310a.zip

And follow instructions (if needed) here: http://www.kvcd.net/forum/viewtopic.php?t=9300

BATCH
====
SETTINGS.INI
========
Common framework:
Depending on source:
Settings to test:
The set of tests needs to be run over streams with at least 30 minutes duration.

VB ->vbitrate
SCP -> scplx_mask=0.3
NAQ -> naq

1) VB=1000
2) VB=1000:SCP
3) VB=9800:SCP
4) VB=1000:SCP:NAQ

1) See if it starts lowering the quantizers as the stream goes trying to fit into the avg bitrate;

2) and 3) See if the spatial mask helps fitting into the avg bitrate or if it doesn't even care and just lowers when it can;

4) See if naq helps fitting into the avg bitrate when you're using *_mask;

The results should be analised in Bitrate Viewer.

Thanks in advance,
Bilu

bilu,
...nice idea, hope more people will test and post with us 8) .
Some of these have been done... I'll look for my tests (all over my poor hard disk) and see if worth post them (since they were done on small tests about 3 min long :( ).
Come on, join us.

About the common framework, I would also include in tests vmax_b_frames=2 for progressive sources, if you agree. And for really fast PC (not mine :? , even is not bad at all) I would recommend to test trell=1:cbp=1:mv0=1. But you give the directions, not to complicate too much the tests.

Yeap,
Nice going bilu.
I wish I had a better CPU on my PC so I could help.
I even wish I had a better CPU for brains :lol:
The thing is my CPU is a PIII 550.

Off-topic:
I'm a communication technician and I work mainly with Avaya Systems.
Though, I have more than 10 years of experience working on the PC repairing business,
both hardware and software installation.
Not to mention that before I started "working" I had been kidding with PCs for more than a decade.
One thing I always recommended (and still recommend) to my customers is having everything
backed up on a weekly basis and always keep the Firewall and AntiVirus updated on a daily basis.
Now my windows box that has been intruded 3 times this week-end by some meat-head that has
nothing better to do...
On Friday I went to my Parent's and left the PC turned on.
When I came back home at night my PC had crashed and had to repair some files on startup.
I thought: ok they've found a way to break through BlackICE Defender.
No big deal, they had launched a patch on that evening.
On Saturday I left my PC working on some tests with mencoder and went to the movies.
When I got back BlackICE was stalled and this time I had to reinstall WinXP Pro.
I had just reinstalled XP + BlackICE (with the Patch) + PC Cillin 2004 (with the updates) when
I received a phone call from a customer, on a week-end :evil:
I came back home around 4AM and I thought: if the race in Malasia is starting at 7AM
there's no point in going to bed now.
Might as well run some tests with mencoder and update the newbie guide :idea:
Ok, this time they screwed up the NTFS 5.1 partitioning so bad I couldn't recover anything.
Know what? I had zillions of bytes on my second, just bought 2nd hand 40GB HardDrive.
Know what, again? Hadn't had time to back it up yet so now I'm empty :evil:
I don't even have the firewall, so if I try to download it the bad m*th*r fu***rs are going to
attack me before I can download it.
So I'm reduced to a Mandrake 9.2 that I had lying around on a couple of CDs.
No way sh0dan has ported Avisynth to Linux yet, right :wink:
This way I'll only be able to do anything next week-end... :(
Cheers guys

@digitall.doc
It's better not to overload other people PC's , even if they're fast :D

@all
If you want to test with B-frames, please make sure that your sources are progressive. Interlaced or telecined sources are not supported.


Bilu

They sure did 8O
Look at this: http://www.newsfactor.com/story.xhtml?story_id=2474024

-kwag

Yeah...
I just found out too late :( ...
I'm definitly going on a different direction now.
I've got an old PII233 with 64Mb and a 3Gb harddrive and I got my hands on two 3COM NICs.
I'm downloading smoothwall as per Karl's information on a different thread.
I'll make it my proxy/firewall.
The only prob seems to be the extra noise in the room 'cause of the power supply fans...
Oh well nothing's ever perfect for me any way :D
Untill I find a way (read time) to install I'll be online for very short periods of time :(
Hope I can revisit you guys on the weekend.
You know I found a tool called Easy Recover from Ontrack whish aided me to recover
some of my work but most of it has vanished.
And the tool is quite expensive, but so are the data recovery expert companies here in Portugal :wink:
Cheers

Bilu you know what:

I did encode a fieldblended capture of Independence Day (PAL) using mencoder but NOT set to interlaced encoding! (testing) Therefore that means an interlaced/fieldBased source encoded at crazy progressive setting defaults!
The resulted stream I did just treat using Restream (as always I do use on ready encoded ffvfw or mencoder encodings) resetting timestamps and did set the flags to "interlaced" but still ZigZag-scan! keeped and also set to TopFieldFirst flag.

The result was ...... NICE! 8O
(I did a test, thats why I did that totally unconventional way)

BitrateViewer ended up ok. right AVG, peaks where ok, a Q curve in a way how it has to be (almost, but not mention how FAR better then CCE,TmpgEnc)..... and GOP was normal set and outputted using 2 B-Frames.
(when CCE already produces a Q of 4-5, in the same part mencoder still uses about 3-4 at same endfile size)

Compared to CCE (alternateScan/interlaced settings) it resulted BETTER!
On Tv :arrow:... *love*

:arrow: We never will estimate the "behavior" of that mencoder or ffvfw :lol:

almost every Kdvd encoding I do now using mencoder and the slicer() function for prediction and afterwards "massage" using Restream :lol: Im really impressed.


PS: The quick and fast way using "settings.ini" I didn't knew before, .... where has to be that .ini placed?? In the same folder as mencoder.exe or where the .bat file exists?? :arrow: It can be used and shared like a Template :) (like you do it right now above)


I apologize that I didn't followed the mencoder "threads" that much, but once getting out, it needed a very concentrated reading to get in again :)

hi inc,
nice again to see you around here testing mencoder.
The *.ini files are usually in mplayer folder, where you put codecs.conf file that vmesquita found for us.
But I think the important thing is that you point at the ini file in mencoder command-line through -include setting:
Hope you will be with us more time, helping to understand this nice encoder. Since the output is really good. And, since is based in ffmpeg, it will take advantage of ffmpeg improvements (now they're working in rate control, as bilu informed us)

No need for alternate scan if you use ildct, zigzag is fine :) :
http://www.kvcd.net/forum/viewtopic.php?p=67365#67365

Seems that B-frames work nicely with interlaced encodes, just not when switching between interlaced and progressive:
http://neuron2.net/ipw-web/bulletin/...pic.php?p=3164

I've got to read more about that slicer().
But it's good to know that the AVG was OK :)

Can you post the command-line you used?


Bilu

Hi bilu,
nice to see you back to forums!.

I've been reading around but didn't see much changes in this mencoder thing. Also looked for advances in ffmpeg related to rate control, but didn't find anything. Do you have news?.

About ping-pong prediction, it's very interesting. The tests I did where done with slices I obtained with this slicer method. You can begin reading this thread: http://www.kvcd.net/forum/viewtopic....ight=ping+pong
It has almost all info about the method.

It's fine we can focus on prediction, since that means that mencodings are more tuned... isn't it?.
I saw a post in doom9, where they advised settings very similar to what we did here.

BTW, how were your tests with authoring?. Did you try DVDauthor?, did you use the GUI?.

Cheers :wink:

I won't post much until there are some real news.

Meanwhile I uploaded a sample stream to the FFMPEG guys so they can check the interlaced/progressive B-frame problem.

I posted this now at FFMPEG, maybe Michael speeds things up ;)

There's not much more I can do at the moment.
And life has other things too ;)

I need to look for my health: 27 yrs old, 1,76 mt, 110 kg :!:

I'm going to start making cardio-fitness today on a gym near home.
2 times a week for now, other days at a swimming pool right next to the gym.
I haven't made exercise for years :oops:

So instead of bringing the work laptop home ( my own desktop has a burned motherboard and it's time for a real upgrade, but money has other priorities) I'll post at work when possible and avoid computing at home, at least for a while.

So at least until ratecontrol is fixed, no predictions or authoring for me :wink:

Of course I'll allways help others with libavcodec, I can benefit from their experience too :)


Bilu

You've been always a prudent person, but we all lose without your comments :(
:( again
Of course, you're right. You have to take care of your health, we all should :? .

Can you point us where can we keep informed of ffmpeg advances? Where did you post the interest on ffmpeg at KVCD?

Hope you'll enjoy your new activities, and feel better friend!

I'll still be here a lot, just not as much at night :lol:

And I already posted about FFMPEG advances, but I'll do it again:

Mailing list archive (better would be to subscribe of course):
http://sourceforge.net/mailarchive/f...?forum_id=1506

libavcodec CVS, ordered by date descending:
http://www1.mplayerhq.hu/cgi-bin/cvs...eg&sortby=date


Bilu

Thanx pal, I missed your previous post.

I'll go there and see, and as you advise, maybe I'll also subscribe (I don't do this usually since I think I have very little to offer :oops: This is the only forum I'm subscribed, but here people is so charm and patient...)

Well its very simple:
(if I do choose the properties of my mencoder.exe it says buildet at 27. November 2003 and modified at 9. Dezember 2003. It seems to be the one when Vmesquita came up here with his makeAVIs for mencoder Guide)

The .bat file:
The .ini file:
(nope thats not Notch, its an own matrix composition which filters more on high frequencies and so I didnt applied DCTFilter() in my avs script,
BTW that of=rawvideo=1 doesn't work for me so I still have to do the demultiplex way)

So as you see I do not use Trellis etc. .....

I did just a test this evening on "Road to perdition" where I did set
vbitrate=1000:vrc_maxrate=2200:vqmin=1:vqmax=4

... and that came out:
(source was an already SHRINKED DVD! pics in jpeg 60% Quality)
Movie video Stream final size was 840MB! (just for testing)
Ok, that movie got much dark, but .... hell therefore that less MBs at 704x576 @ 25fps, therefore you can assume what comes out if I give an encoding more room to breath if I for example do encode finally to lets say 1900MBs so 2 Movies will fit on one DVD-R.

Fast motion:
Encoding:
http://www.digitalfaq.com/archives/error.gif

Source:
http://www.digitalfaq.com/archives/error.gif

No motion:
Encoding:
http://www.digitalfaq.com/archives/error.gif

Source:
http://www.digitalfaq.com/archives/error.gif

The avs script:
Also here just simple - no MA, just spatial and minimal Temporal filtering

Nice script incredible.
I'm curious about some things:
- Are you doing KDVD?. I guess not, from aspect 4:3, and from vrc_maxrate=2200. I suppose you're doing SKVCD (well, SVCD in this case, or better "SIncVCD" :wink: ). How is the output?. Wouldn't it be better to use MA script for SKVCD output?.
- I see you make use of vqmin=1 (that in man_page is not advised), and vqmax=4. Doesn't it force too high (but below 2200) bitrates, since Q can't be raised?. What are the figures you get in BitrateViewer?. Have you tried also vqmin=2?, what are the differences in file size and Q and bitrate values?. Wouldn't it be also advisable to use mbqmin=1 and lmin=1?. Just curious about the effects of a vqmin=1 value.
- Are you feeding mencoder with makeavis?
- Have you tried bilu compilation of mencoder?. It works fine, and you have the advantage that don't need to demux the output file.
- I also advise you (just try and see if you like more) to use mbd=2 (better quality) and vqblur=0 (Q changes sharply when needed)

Till now I didn't try to make a SKVCD with mencoder, but I had it in the to do list: to backup my DVD in a single CD, in MPEG2 format with mencoder. Through your test I see it maybe possible.

EDIT: I'm telling lies: I tried once to do a 1 CD SKVCD encoding (Spirit was the film) but didn't like the output. But I also was using other parameters then... I have to try and redo it.
EDIT2: I see you edited your post. rawvideo just works with bilu compilation.
EDIT3: I also see that you're using a vrc_buf_size=1835, so you intended a KDVD... Then maybe would be better to raise bitrates... Give it a try with vrc_maxrate=8000 and vbitrate between 5000 and 8000.

Well above you see my rugular KDVD script and below I did a test for a Xsvcd ;-) Well I didn't use any compex routines in here as the movie already gains from big darknes where already a good compression comes out so MA would even give more compression, but on the other hand it would be more blurred.Well you're right, I should change that but my Q curve is nice and keeps almost in avg at 2-3 (in that xsvcd sample) in DVD where I do give even more AVG bitrate the Q curve behaves at 2 in average :? As I told, I didnt read all the past mencoder postings so thats a bit new information to me *lol as I till now ended up very nice with that above :wink: Yep!
Nope till now not but I will do! :wink: Thanks for the hint! (gimme the link please)Ill test that ! :) Well I already did some KsVCDs even uisng ffvfw so its possible BUT that above is a nice compressable movie ... I just got the screenshots where you can assume what will come out if AVG is set much higher to end up with a DVD containing two Movies.
And thats in regular my way ... also to set mencoder to 16/9 .. that 4/3 was from another 3h movie where I had to decide and I did choose non-anamorph but therefore better Quality :wink:

I see now your edits:
The VBV Buffer is right in the bat above for DVD purposes ... in the Xsvcd encoding below I choosed the half and ended up with 112VBV in real ;-)

I think it was a bit confusing, to show my kDVD settings ABOVE and below showing the tweaking(incl. parameters switched) to obtain a Xsvcd encoding! Shame on me :oops:

And ... when used that simpel avs a FPS of 35! encoding speed came out 8O (Athlon XP overclocked)

Pheeeeewwww 8O 8O 8O 8O
With my settings, with trell and mbd=2 and so, with MA script, and a P4 1400 I just get 6-7 fps :roll:

You can download from here (don't know if it still works. If not, ask bilu):
http://clientes.netvisao.pt/bilu/bru...r20040310a.zip

No, don't worry, I understood perfectly your post. My comments were just to make sure I understood your method, and to suggest you some things that maybe can improve your output. The vbitrate=vrc_maxrate approach suggested by bilu gives a nice output (I compared with vbitrate=5000 and vrc_maxrate=8000 vs vbitrate=vrc_maxrate=8000, and where quite similar, with higher bitrates in the second test, and maybe slightly beter, no blocks at all)

Thats cause Im runnin actually my Athlon at ca. 2320mhz ...
Link works perfect! :wink:
Well if the output can even be improved, ... well .. lets see :lol:

I didn't followed that "vbitrate=vrc_maxrate" thing ... whats that about?
I know what it means, but what are the resumeés in your testings?

Maybe we should do a new Thread ONLY containing well successfull mencoder parameters .... maybe something like different .bat quotings using names like xxx1.ba, xxx2.bat so we can refer to them in that thread like phil doses with his optimal scripts, means if someone gots a very useful new .bat change, we can post it there incl. ecplanation and give it the next number.

BTW:
How can I put a fake-line break in the .bat command like in Avisynth where you can put a "\" so the engine doesnt read the linebreak.

Uops, I think bilu's subject of this threat went totally out of topic! :oops:

Digi.doc ....

maybe you already discussed this but as I didn't read every posting in the mencoder thread there ... here a little point of view of mine according to aggressive bitrate peaks (still theoretic but should be testet) :

As we know that mencoder very much keeps the encoding within the settet Vqmin and Vqmax this means for example on a mega complex input scene even a Vqmax of 3 would result in a peak blow up in the bitrate.
Example ... I did recognise when I was encoding "the sixth sense" that there was ONE scene where the picture focussed on a running TV where no program was running (you remember that from "Poltergeist" .... that TV full of snow night-picture after the national anthem?) ok, .... so the Q wasn't getting over 3 BUT therefore the Bitrate startet like a rocket up to 12000! kbit ... my player plays it so that was luck or cause its just a 2sec scene where you dont recognise a stuttering at that TV-snow-only passage.
So Vqblur in mencoder seems to me like a flatpriority in CCE or elsewhere.
Means IF you set a higher Q dynamic even at Vqmax=4 thia would mean you will have a more dynamic Q curve which makes sense as on such mentioned mega high complex scenes you wont recognise worse quality if just a Q level one step above is used.

So best would be to make tests on a special sliced Source, where a wide range of dynamics is included which would cause extreme bitrate falls (credits etc.) and also which do cause extreme bitrate risings (TV-Snow, waterfall, sunreflectios on auneasy watersurface, flashing diamond sparcles). If using such a source input of approx. 10minutes we could find the right average out of Vqmin/VQmax and especially the VQblur.

:?:

For the moment I've been more focused in bitrates than quantizers. vrc_minrate and vrc_maxrate work well.

I use vqblur=0 because I don't want quantizer delay. IMHO it would be better to have bitrate delay than quantizer delay, because if you keep the quantizer instead of increase it when the bitrates go up then the bitrate peaks will be bigger.


Bilu

Yeah...
It must be a problem with Portuguese people.
I should also look for mine: almost 30yrs old, 1.72mt, 94Kg :!:
Again I would say that it's almost the same with me.
At the age of 20 I was 1.72mt and 72Kg.
Around 25 I weighted 80Kg.
Soon I'll be breaking the 100Kg barrier...
I need to take my bike and go out on it like when I was 15 yrs :twisted:
I fully understand that. I've been doing the same myself. It's not easy working for ~12 hours a day and still get in front of the PC for 5 or 6 hours at home at night.
That's why I think you're fundamental to our forum :wink: .
Of course you don't need to be so dedicated as you've shown us lately.
Just go with the flow and drop by when you can or you feel like doing so.
Cheers mate.

@Inc,
I would just like to express that I think it's damn good to see you here at mencoder forum buddy.
I've been testing it with Slicer since the begining but I'm still in doubt on the arguments to make mencoder drop or raise the filesize.
Anyway I've always used the vbitrate=vrc_maxrate "way" as digi.doc, bilu and others here.
Have you tried to author yet?
Are you using DVDLab? If not which auth. tool do you use?
I'm targetting KDVD with 2 movies using mencoder, headac3he and ifoedit for auth. since I don't keep menus and extras.
I've been doing tests on MA vs FuPP too with mencoder and I still haven't made up my mind on which one to use...
Nice to have you with us.
Cheers

incredible,
I did all my tests with StarWars II, and I found several complex scenes (at least as I see them), for instance that of the battle of Jedi... And in my tests I didn't notice that too high bitrate prob. Maybe because I didn't try a really complex scene.
I think that the explanation that gave bilu is the reason why we use vqblur=0. If you take a look at BitrateViewer, you'll see that just when bitrate is begining to raise, Q raises and this way bitrates stop or slowers the raising... (don't know if I explained well :oops: ).
But, answering to your question about creating a thread with "standard" command/settings, I don't think we have a well stablished settings. For instance, you could test with vqblur and see what happens. I don't remember well the range of values now, but if 1 is maximum, you could test with vqblur=1 in that same scene, and see what happens to the file when you see it on TV, and what happens to bitrate and Q in BitrateViewer. That's the way I/we tested several settings (for instance, vbitrate values, or vqcomp,...).
Make me know what happens taking vqblur just opposite (that is: "static" quantizer value), but I'm afraid that if you're at q=2 and comes a bitrate demanding scene, as encoder will tend to keep q=2, bitrate will increase further (...hmmm, isn't this the same explanation bilu gave, but using far more words and far more complicated my explanation... :roll: )

Till now I did author many DVD-Rs using Mencode'd captured streams with success ("massage" afterwards using Restream to fix timestaps).
I that case I used TmpgEnc DVD Author as my captures do come with one Audiotrack only.

I use Vbitrate and Vmaxbitrate setted only, no VminBitrate!
And thats the point what I again saw yesterday when rising Vqmin again to 2! That resulted in blocks on underwaterscenes so I switched again to Vqmin 1 ... and there's no filesize rise that much (maybe 1%) BUT better Q curve and so Q factor allocation where it makes sense. In these Underwater Scenes, Bitrate dropped till 500kbit but the Q also lowered to approx. 1.5 = no Blocks = fantastic.
The average Q factor by this (in my case) does depend on the settet Vbitrate, if Vbitrate is lower, therefore the average Q also rises.
I defenitely try to avoid almost linear Quantizer Curves as it makes no sense, means its not that economically.
BUT if Im using VminBitrate bitrate that always causes "underrun" errors :?
If I kick out that VminBitrate parameter everything encodes fine and Bitrate lows do only lower till 500kbit ... no playback problems.

I testet also "trells" and "MBD=2" ... but no recognisable quality rise but it lowers the speed about of 20%!

Im very happy with my settings and you know my quality-ponit-of-view ;-)
Yesterday I did encode "The Core" from a DVD and the average Quantizer was 2,4!! CCE only can dream of this if a wanted endfilesize should fit a half DVD incl sound :lol:

I've fond here on the www a nice comparison of mencoder and CCE, ok there's not the commandline posted but the behaviour in my cases is almost the same: http://mitglied.lycos.de/sem12022004...pics_indy.html

BTW::D Thanks for the "welcome"

PS: How do you get IfoEdit to author more than 1 stream to a DVD-R?
:?

I'll have to try quantizer 1 :)

Meanwhile I tried to compile both Mencoder and FFMPEG.
Compiled both under MinGW, no problems, but Mencoder crashes.
Already reported at the mailing list.

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

FFMPEG online documentation is Reeaaaallly outdated, just run ffmpeg with no options piping to a text file and see the difference :roll:

About the interface and docs, Mencoder is friendlier and able to support Windows codecs, that's the reason why we can handle AVS files :)

Idea: If one player could pipe the AVS to standard output, maybe Mencoder could grab standard input, hence no need for MakeAVIS.
I'll have to check this out ;)


Bilu

From my tests so far the best way to flat the bitrates is to use vrc_minrate almost as big as vbitrate and increase lmin.

lmin/lmax are the most flatpriority related parameters in Mencoder IMHO.
Search for Lagrange Multiplier and you'll see why.

Example: vqcomp=1:scplx_mask=0.3:vbitrate=3000:vrc_minrate= 2900:
vrc_maxrate=9800:vqblur=0:vqmin=1:mbqmin=1:lmin=2. 5

seems to me like one of the best ways to achieve 3000 Kbps with nice quality.

In my former tests with scplx_mask=0.3 it seemed perfectly capable of achieve avg bitrates under 3000 Kbps (even with peaks greater than 8000 Kbps) with complex streams.

By limiting minrate but still giving space for the ratecontrol to aim at the average ( 100kbps only, because scplx_mask=0.3 + lmin=2.5 are a pretty strong combo to lower bitrate) you'll get you a pretty good result for such a bitrate.

High bitrate peaks will still exist but will be flattened a bit.
IMHO high peaks are normally high motion and don't get as much noticed as the other scenes.

EDIT: Don't care about this post, bad quality on underwater scenes. Read my last post in the other thread.

Bilu

Well, inc was right, this became the second mencoder thread, and lost its initial purpose. Hope bilu won't mind.

incredible, lot of information in your post. I'll learn a lot.
When do you get underrun errors? During encoding or when muxing?. Because during encoding mencoder advise from underrun errors, but already bilu explained that we don't have to take too seriously if they are reported just at the begining. And I never got underrun errors when muxing.
Related to your vrc_minrate problem, I didn't understand where is it. Is it in the underrun problem?. Since I encoded everything at vrc_minrate=300 (taken from CCE settings we use) and didn't have a single error. What are the problems you find setting a vrc_minrate?. And if you don't set a minrate, as there's no minrate default setting, it is supposed that encoder can go down to 0, isn't it?
I tried a encoding with vqmin=1 mbqmin=1 and lmin=1. For a 2 min sample (not good, a noisy capture), file size grew from 80 to 110 Mb, and avg Q dropped almost 1 point. It's nice since, in certain circunstances, we can make use o quantizer 1. But it may make grow too much filesize. I think we can play with lmin value (it's advised in man_page to use lmin equal or little smaller than vqmin. In tests I did vqmin=2 and lmin=1.5 helped to keep Q value closer to 2 than just vqmin=2).
In that blocky underwater scene, what was your bitrate, what vbitrate value did you use?. Since in my tests, with complex scenes (smoke, dust,...), and vbitrate=maxrate=9800, bitrate just raised a lot, and if needed Q raised also and then bitrate lowered. Don't know how vqmin=1 can help more than vqmin=2 in these scenes.
Yes, it's better avoiding linear Q values (we dropped vqscale for that reason): it has no sense, and makes bitrates go up crazily.
Related to trellis (cannot remember if also mbd=2, but >I clearly remember that in "other"forum they stated that it really does a difference) I did get different results. But, of course, it's a matter of taste...
Again, I'm very happy you came to play with us :wink:
Ah!, in IfoEdit, the way to add two audio streams is the same for the second as for the first: hit in the "point" button againg after loading the first stream, and load the second one.

Nice mencodings :D

bilu, I read somewhere else that compiling with Cygwin is more "stable". :?:

I hope you'll be able to solve this avs prob (I don't like at all having to use makeavis, I have the idea that it lowers encoding speed), as Nic already did for QuEnc.

That's a nice idea, and this way you can "force" a kind of average bitrate in mencoder. But, what will happen when the scene doesn't need even those minimum 2900 Kb?, mencoder won't be able to go under, isn't it?.
And I don't say it's wrong, but the way you use lmin is different from taht advised in man page (equal or less than vqmin). But if it works... nevermind. Did you try to compare with vqmin=2:lmin=1?.
A doubt bilu, is there any problem with high bitrate peaks, but within DVD bitrate specifications?. In a bitrate peak, does visual quality degrade?. I ask since I don't know the answer.
Happy to see you back to posts friend :D

Tried it now, it works as fine as vqmin=1:lmin=1.
Even on anime or underwater scenes I couldn't tell the difference :)

EDIT: LOL :lol: Just encoded a file where it got a bit bigger using vqmin=2:lmin=1 than vqmin=1:lmin=1.

Bilu

8O 8O 8O 8O 8O 8O 8O
I don't understand a single word of this mencoder thing
8O :D 8O :D 8O :D 8O

i can really talk the same and in deep sadness !
:(

...but, the stimulus from you all give me high confidence :!:
great guys !!!
:D

Amazing... 8O 8O 8O 8O 8O 8O 8O 8O

The pictures look great, but I wonder whoever did the tests, if the file sizes are equal for both comparisons :roll:
It could be that CCEs samples are way smaller in file size, which would render the comparisons useless.

-kwag

Look at the top of the page:
Same bitrate -> Same size (the guy probably used 2pass VBR) :wink:

yes, ...really cool !
!
8O 8O 8)

Yes, but where are the samples :?: :!:
I would like to see the actual MPEG files :cool:

-kwag

I think I see your poit now: they guy may have got the pictures from the parts mencoder did a better job, but there could be other parts where CCE did a better job that he did not choose. :wink:

:evil: yeah!
we need to see that samples !
:wink: