Thanks! I was able to fix all the issues you reported:

1-I was compiling without win32 DLL support plus I haven't updated the internal codecs. conf to have the reference to understand MakeAVIs. I also fixed the external codecs.conf location because the way it was, mencoder would never find it unless you were running from cygwin enviroment.

2-My cygwin install defaults to build with shared libs, I have to force using static libs. I just did it.

3-Removing all libs besides cygwin1.dll (which can't be removed) gave me a 5 Mb executable. Maybe I am compiling with more stuff enabled... :?

A neat thing: I stripped mencoder.exe (removing debug symbols) and packed it using UPX, giving me a much smaller executable (2.2 Mb) and smaller ZIP file.

The new AtlhonXP build is here: http://www.jltoca.uaivip.com.br/file...2004-fixed.zip

The new Runtime detection build is here: http://www.jltoca.uaivip.com.br/file...2004-fixed.zip

I was trying to build using libdvdread, but I can't manage to compile it. This would enable to use mencoder straight from a encrypted DVD.

My configure:

Great Job :!:
Can you open a thread on how-to compile MPlayer/MEncoder4win32 under Cygwin?
That way you could give us explicit instructions on how to compile it step by step.
Meaning:
- What to download in terms of Mplayer project
- What to download for Cygwin Environment (just the basics)
- What to download for directx support/win32 codecs
- Where to put all the files
- What Configure/Make/Make install commands
That would be awsome.
Cheers

Great idea, rds_correa, I'll do that as soon as I can.
I don't know if you know this, but you can encode in mencoder straight from the DVD, no need for ripping first:

mencoderXP -include dvd1.ini dvd://2 -dvd-device f: -o teste.m2v

Just replace f: with your dvd drive and 2 with the corresponding VTS number in the disc. :wink:

I just don't know if encrypted discs will work, I don't have any right now to test. :D

thanx for the compilation, vinicius :wink:
I still didn't have time to test rds. Too busy now.
I'll test this two last compilation and see how they work.
I think, again, it would be better we all used the same compilation.
My preferences: any compilation capable of loading vobs in my system ( :? ), and maybe it would be advisable taht it was a recent ffmpeg compilation inside (in order to use the latest advances in ffmpeg, wehter good or not, as we'd better follow the developments)

My compilation can do VOBs (and can grab straight from DVD if you are a lazy) :D. And I used the latest ffmpeg, straight from CVS, using the cvs command. All developments in FFMEPG till yesterday night are in this compile! 8)

I'm willing to test it 8)
:arrow: just need some time at home :roll:

WOW :lol:

Just came back from Easter holidays, what a nice and big weekend it was (and still is :wink: ).

Some answers:

@rds_correia: the only filtering I'm doing is vf=yuvcsp to limit the encoding to the CCIR-601 color range, same as using Avisynth's Limiter().

@vmesquita: I agree with you 100% about 1-pass encodes and avg bitrate. The "time machine" IS the 2-pass encoding! :lol:

About lmin, 2.49 is the highest acceptable value for video or anime with gradients IMHO. Clean anime without gradients can go up to lmin=5 :!:

Setting a high vbitrate and using lmin as the average quantizer can really be the way to go for 1-pass encodes. The high vbitrate setting would "glue" the quantizing to lmin :)

@incredible: vqmin=1:mbqmin=1:lmin=2:lmax=4:vrc_maxrate=9800 seems to be what you're looking for, but for such low bitrates and dark scenes I'd aim for lmin=1 ;)

@all: Cygwin's build is indeed a bit faster (well, VMesquita's build is faster, I didn't compare two compiles of the same code :) ) in PAL (15 fps on my PIII-500 with my last settings, versus 14 fps with my build).

With NTSC things get worse for both builds: -vf softpulldown slows them to 7 fps :x

About 2-pass encodings: I believe vqmin=1:mbqmin=1:lmin=1:vrc_maxrate=9800 would make a terrific first pass ;)

It's good to be back :P


Bilu

bilu,
and it's good to see you back :wink:

This is the main reason why I abandoned vrc_eq=avgTex and use only vrc_eq=tex. On bitrate peaks it overquantized.


Bilu

It has an in-built KernelDeint, that may be good.
But Mencoder's IVTC filters suck, tried them when I started this thread.


Bilu

Just reported to the mailing list:

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

Bilu

Good thinking :)
So you would do something like :vbitrate=7000:lmin=2.50: ?
Cheers

On my tests I found 2.50 too much :?
But 2.49 had a different behaviour :lol:

I'd do vbitrate=9800:vrc_maxrate=9800:lmin=2.49:vqmin=1:m bqmin=1


Bilu

Well, this is what I've been proposing, I think, based on your previous advises. But I've got a doubt: still don't know clearly if with this approach (vbitrate=vrc_maxrate and lmin showing quantizers the way) lmin will work as an average quantizer (when lmin>vqmin), or as a guide to make quantizers tend to vqmin (when lmin <= vqmin).
In my tests, with vqmin=1:lmin=1 or vqmin=2:lmin=1.5, lmin acts lowering quantizers and making them go closer to vqmin, but maybe (don't remember well, I've to see again) with less oscillations.
But with your approach with vqmin=1:lmin=2.49, I see quantizers oscillating, but far from 1, and I don't remember that average was 2.49 (maybe because you didn't use high vbitrate).
I can't say what's the best way. Maybe high vbitrate and lmin about 2 (to have quantizers between 1 and 3?).

Both the ways you specified :lol:
If lmin < vqmin, quantizer will glue itself to vqmin "trying to reach" lmin.
If lmin > vqmin, quantizers will tend to lmin and not to vqmin, BUT they will use lower quantizer if the motion estimation tells them to. That's why lmin=2.49:vqmin=1 is slightly better than lmin=2.49:vqmin=2 (tested on a underwater dark scene).
That's what I've suggested to Incredible, yes :)

Bilu

But, from the results that you posted, with vqmin=1 and lmin=2.49, average Q was about 5.6, so lmin didn't work like an average quantizer...
Was it because you used a low vbitrate value?. Do you think that with a bigger sample and high vbitrate, lmin will really be the avg Q?.

My shots were from Neo Genesis Evangelion with vbitrate=3000 and it allways got results more than 4000 kpbs, so that's probably it.

With my The Abyss encodes it got around 2 and 3, bitrate was allways lower than 3000 and vqmin=1. So I would expect it to work like that, yes.


Bilu

I know that veery well VMesquita ;-)
BUT maybe then its luck as 94% of all my encodes using my script do almost match the given Vbitrate 8O
And as I said to digi Doc .... I don't know how this can happen! Cause this would mean prediction would be nonsens but the movie won't be linear in its treatment, .... so thats why Im that wondering about "my" Vbitrate = almost avg encoded bitrate.
(but for shure I still do a prediction ;-) )

And as said above this Vbitrate factor in my case is just used the "other way" to affect the quantizer during encoding as I saw that just another way like lmin etc. and changing them also does affect other - not wnated - Quantization bahaviours.

Guys, have a look.

Extensive tests without vrc_minrate
http://www.kvcd.net/forum/viewtopic.php?t=10229


Bilu

:D GREAT Easter Season findings :D
Hya
Now I just wonder.
Is this the way it was meant to be?
Or is it just temporary until they fix ratecontrol?
Sahre your thoughts with us bilu :)
Cheers

Seems it's not temporary. So let's forget about minrate.

http://sourceforge.net/mailarchive/m...msg_id=6860343


Bilu

I tried without minrate (already posted in your other thread). But I'm concerned about the minimum bitrate valleys we will get without a minrate limit...
I suppose you already tested with several minrate values, and always bad, isn't it?
BTW bilu, your last link to sourceforge maillist is not working. Could you sum up what was said there?

Bilu

Thanx.
I see that it won't be just a problem in low bitrate encoded films with low maxrate. Any film, encoded with any vbitrate and maxrate value, can have an scene where bitrate can drop to virtually 0.
Don't know if it will be a problem... :?

What's strange is that if Michael is right, then there is no such thing as minrate in any DVD-compliant encoder. So how does CCE work? And TMPGEnc?

Could it be a muxing problem you had? :?


Bilu

No way bilu.
Either my players is a very crapy one or there really should exist a thing such as minrate.
Mine don't go below 200 and 100 respectively.
They are cheap things bought in the supermarket (out of $bucks$).
One (200Kbit) I don't even know the brand cause the brand-plate unglued and was probably swalowed by the
vacum cleaner and the other one is a Mustek V520 (100kbit).
I know I posted the nameless one's name in the past here at the forum.
I'm just not sure where...
Cheers

And can you set minrates in CCE and TMPGEnc ? 8O

Bilu

bilu,
I don't know if I understand your question, but I think you already know the answer.
Yes, in both encoders, TMPGEnc and CCE, you can set a minimum bitrate value.
Anyway, Michael's question was:
and that's not the case of either encoders.

Okay,
I don't know what's on his mind when he (Michael) wrote that.
I'm assuming he's been FFmpeg's developer since the begining.
If so he must know why he created vrc_minrate flag, for sure :evil:
Unless it does come from libavcodec source code and so it comes with the "package".
Otherwise I'm stumped with what he wrote.
Anyway we've seen similar problems with FFvfw disregarding the maxrate flag...
I think libavcodec is great business but it's still a long way from becoming usable in our encodings.
Or maybe I'm just wrong, here.
Cheers

libavcodec has gained MPEG-2 encoding only in the latest versions, it has been mainly used for MPEG-4 encoding.

They probably don't know enough about VBV to implement minrate properly :?

Proposal: let's find out what TMPGEnc and mpeg2enc use and tell them ;)


Bilu

IF you check here:

There's nothing about a Min Rate... In fact I never heard of a min rate for DVD specs. :roll:

Here: :?: Here :!: Where :?: :lol:
I think you forgot the link vmesquita :hihi:
You were probably refering to here: ;)
http://www.dvddemystified.com/dvdfaq.html

-kwag

I found a way to lower the quantizers on high-bitrates:

vfdct=1:ibias=-256:pbias=-256

you can replace vfdct=1 with 2 or 6, just not 3 (mmx) because it can't handle negative *bias values.

But then you have another problem: it doesn't work in high-contrast areas (anime and film) with the Notch matrix.

I found out that only vfdct=3 (mmx) works well with the notch matrix.
Tested both progressive and interlaced encodes.

And vfdct=3:ibias=0:pbias=0 is nowhere near as good as *bias=-256.
Quantizers lower a lot while it still keeps the average bitrate.

EDIT: Seems it only happens if lmin < 1.75 :)

EDIT2: Confirmed. And if you set lmin=1.75 the quantizer will never go below 2. But instead of getting max quant 28 in that stream I get max quant 7.28 without using lmax at all :)

EDIT3: lmin is not the problem, but vqmin. lmin=1:mbqmin=1:vqmin=2 works fine.

Bilu

Yes... I copied the link but never pasted. :lol: :lol: :lol: :lol:

bilu,
Ok, quantizers go down, but how does it look?. Does it improve visually?.
And you say that "the problem" is solved when setting vqmin=2. Are you referring to the problem of mmx not handling negative *bias values, the problem of high-contrast areas with notch-matrix, or the problem of notch-matrix just working well with mmx?.

It didn't improve, I was doing crap :?

But using vfdct=1:pbias=-256:ibias=144 I get similar size and quality to the notch matrix, without using the Notch matrix. :!:

And I could lower ibias down to 96 and quality still looked quite good at my eyes while filesize decreased from 10701 KB to 8825 KB while keeping the frame quantizer at 1 :!:

(means all happened at the MB quantizing level, not frame quantizing level)

My favorite is vfdct=1:pbias=-256:ibias=128, about 9873 KB.

high-contrast and other vfdct's than mmx.


Tested with dark underwater scene.

Bilu

Sorry friends that I was a time out of here but I was in Linux-newbie-configuration/installing tests-trouble :lol:

And I wanted to know How we can really trust on bitrateviewer!
So I did many many tests to see if the purpose how we do use Bitrateviewer to see/assume how the encoder does its Job.

I am totally confused, means I do not trust on the Q curve according to determine the encoders quality anymore!
As we didn saw the C curve logic in Bitrateviewer right. Its a diff. approach from WHERE the Bitrateviewer does take the Q informations and what they really do mean.

As you remember I already said a time ago "don't trust bitrateviewer" ... but I thought, well ... If Q peaks in my mencoder encodings also in theses frames blocks do occur.

The last days I took TmpgEnc, CCE 2.50 and CCE 2.6x and shurely mencoder .... to see how does the Q curve copy the "real" present quality of the encoding.

Conclusion :arrow: 8O

I used CCE 2.50 - "Notch" applied and for example two encodings done - one using "linear Quantizer Scale" and the other encoding "non linear Quantizer Scale" means checked off.

In both encodings when using CCE 2.50 the q-curve behaviour was a "dream" ... the result at linear quantizer scale was q=1 - in the whole stream, even when a AVG bitrate 2000kbit was choosen 8O
The other stream where non-linear quantizer was used a nice dynamical q curve using low q values 1-2.
(both CCE 2.50 encodings got the Notch .matrix values also afterwards applied using restream as this is needed! as CCE 2.50 does NOT apply matrixes to the encoded mpv (even you do encode using a diff. one) as default but the std. mpeg. matrix)

CCE 2.6x gave me an encode where the Q curve was much higher! approx. 3-4 and so I "though" ahhhh .... thats why they say CCE 2.50 even gives better output. ...... :arrow: wrong thought as by comparing these 3 encodings .... CCE 2.6x resultet even in less blocks! Although the Q values where much higher.
And that's what KIka from doom9.de/gleitz meant by saying this:
(Just translated by google.)

And mencoder .... ok as we know output was better.
I got many Buffer underflows in Mencoder BUT the bitratecurve on these parts didn't even went below 1000kbit 8O :evil:


Now .. I hope I get again into the mencoder settings as in here a lot is postet the last days and Vmesquitas Thread where mencoders internal filters are used looks VERY promising :)

Your favorite with or without notch-matrix?. Because if you get similar results than without notch-matrix, why use it and drop notch-matrix?, is it faster?. And what's the result with *bias and notch-matrix altogether?.
I'll give it a look if I have the time (you'll see I've been very busy lately :roll: )

@inc,
what do you think we can use then (apart from everybody's eyes, but the "eye" method is very subjective, and difficult to compare through the net) to compare encoders?

vfdct=3 (mmx) is the only one that works with the notch matrix.
And vfdct doesn't work with *bias negative values.

*bias negative values lower frame quantizers.
Reducing ibias decreases quality, but reducing pbias doesn't seem to.

Negative *bias values with Notch matrix do strange negative blocks in high-contrast areas, but only if vqmin < 2.

My current command-line:

As you can see I've limited maximum bitrate.
Since we can't control rc_buffer_aggressivity yet it currently overquantizes after the bitrate peaks. Using pbias=-256 and lowering max bitrate are the only way to fight it.


Bilu

bilu,
as always, good job. I'm more dedicated now to 2 pass (did you try it?), but I keep an eye on your developments, always profitable for everybody :wink: .
I still don't know why do you prefer vfdct=1:pbias=-256 instead of keeping notch-matrix (if I understood well you get similar results).
And what about using vfdct=3:pbias=-256:vqmin=2 with notch-matrix?, how where the results?.
You say that it lower quantizers, in BitrateViewer I guess, but how does it look?, better?.

And finally, what is rc_buffer_aggressivity supposed to be doing (when it wrks properly :roll: )?.