I do not have such probs!
Is the "divx2pass.log" ok??

Me too. And that is what made me decide to stop using mencoder : either I use a "old" release (he one from Inc) that, by definition, don't have all the last improvements included, or I use the last one and it fails randomly with the slightest warning and make me lose hours of work.

Phil as I do know, you got a P4 cpu?

Could you try (on a little - maybe 10mins- sample) a test using the "generic" build I did? Because IF that works, then the problem is due that I tried to compile a P4 build on an ATHLON, even I did set the correct P4 related params at ./configure.
I cant test that as I do not have a P4 to test.

BTW: I used my "old" build I offered and: No crashes AND no color probs!
Tested on that "old" XP and Generic build.

EDIT: PEEEEEEEEEEEEEEEEEEEEEEEEEEP! I did understand you wrong!
So a new latest build configured by me "could" solve the problem???
That would mean I will compile a new CVS Snapshot right away as "I did understand" that you & DigiDoc got probs when using the MinGW builds from MplayerTeam???


PS: What do you mean by "don't have all the last improvements included" ?
Do you refer to the newest developings based on Mplayer team and therefore new CVS Snapshots or do you refer to a incomplete ./configure Line?
EDIT: Shure you mean that as I did understand your lines above now finally

The mplayerHq builds don't support makeavis files and give the same results using internal filters. I'll check what mencoder uses to decode xvid.

Which version do you mean ? You did some after the "mencoderP4sse2-20040506.rar" I'm currently using ? Else I don't see any gain to test a generic build.

You don't understand : the one that crash is not yours, it's the generic build issued from the last CVS on the home site of mencoder.

Sorry to disappoint you but as you can see above : I used your version and it HAS colors problems

Perhaps. I don't know...

I guess taht is new sources come out that is to solve to problem in previosu ones. That was I refer, but I didn't study the changelog to see which are these improvement and if they are interresting or not.

Phil, do read my Post completely as I did edit some passages where I added that I understood you.

SO: It could be that theres a codec issue! Means a) Ill check my codecs.conf as mybe it gots a pointer to the xvid.dll of my system, means not the mencoder internal xvidlibcore is used??? Ill check that as I experimented a lot with that the last week.

EDIT!!: I checked it very easy when watching the log:

WHAT DECODER FOR XVID is used in your's cases (Phil and Koekies) ???

Mine got that log output:

So the internal ffmpeg MPEG-4 codec is used in case of XVID and I did again the Photoshop Layer based comparison using the Test Pattern:
SAME Colors compared with TmpgEnc!! Sorry but I dont know how to say it in an other way.

Try the new "mencoder.exe" builds (Btw: I still did the tests above using the old one):

- 06/13/2004

Generic CPU:
http://home.arcor.de/ffvfw/Generic-20040613.zip

AthlonXP CPU:
http://home.arcor.de/ffvfw/AthlonXP-20040613.zip

IntelP4 CPU:
http://home.arcor.de/ffvfw/P4-20040613.zip

(Cygwin1.dll is here: http://home.arcor.de/ffvfw/cygwin1.dll.exe )

I do but I also type my answer as i'm reading and I didn't wnat to erase what I have typed

This can be a possibility.

For sure I never had this line. I can't tell you what I had, but nothing indicating "XVID".

It seems to me ethat this codec is always used as I saw it on all my sources, whatever the kind.

It seems you didn't understood that a test issued from a PICTURE can't lead to a color problem. I didn't catch a word of the explanation you gave for taht but I clearly see that you used Imagereader. It's exactly as if you took a frame and duplicate it (there is a command in avisynth for that, I don't remember the name).

Testing it is somewhere in the zillion things I have to do that are prior so I hope someone else will test for you.

- The supprt of "makeavis" is NOT build related, its related to the right codecs.conf file where a pointer to the ffvfw.dll (in your system32 folder or mencoder folder) has to be present which will be used in case of the FourCC "AVIS" input recognision by mencoder and "AVIS" stand for the Makeavis generated avi

But as said, I checked several ways:

- Xvid via Makeavis AVI + resizing in mencoder (means "scale:" is used)
- Xvid directly into mencoder + resizing in mencoder (means "scale:" is used)
- Xvid via Makeavis AVI + resizing via avs (means NO "scale:" is used)
- Xvid directly into mencoder + resizing via avs (means NO "scale:" is used)

All do come out including same colors as given when encoded using TmpgEnc ....


So:
Do get the latest Packshot beta (packshot thread) after unstuffing you get a Packshot folder where also the right codecs.conf is contained (in a separate "mplayer" folder) THEN do download the latest mencoder.exe build above related to your CPU and copy that mencoder.exe into the packshot folder.
So mencoder.exe gots the right codecs.conf for working.
Then do read the "For Avisynth support read this.txt" document where a link to the "standalone" version of FFVFW makeavis is given.
Do install it and generate a textdocument using these lines:

That one you safe as "makeavis.reg" and after that do register that vidc.AVIS via this reg file by double clicking it.

In case of direct true FourCC XVID input this would be the right way ( just IMHO!).

I told you that these pics do stand for an average.
But I just did a fast chunk ( via slicer() ) XVID encoding out of a DVD where I used that XVID afterwards as input and for shure the colors are ok as the pattern also comes out correctly.

If a pic stands "still" or not, the whole range of IBP is used when encoding and "technical" seen the encoder does a YV12 based encoding refering to the reference of predictied and bidirectional frames.
And I do think in the sample of "Koekies" the actor "lays" on the floor, so there also will be no movement. But as I do take your knowledge seriously I did the test using the sliced encoding as said above and ... output also there is ok ........ hummmmm

I hope "others" dont see that this workout in here is based on a feeling "I want to be right" as I WANT to find out WHY there are some color probs in case of some users. And as I cant duplicate them (and Kwag neither) we should find a solution

I spoke about fluctuation in the signal level, not about movement.

Take a white piece of paper, shoot it with a camera, capture the video and use it into avisynth : the signal is fluctuant.
Take a photoshop picture of a white square, use it into avisynth with imagereader : the signal is constant.

I think you can easily undersand that the first source will lead to problems that the second one will never have.

Do scale recursively on the picture to enhance the default, just to consider the result as concluant (even if I noticed the problem with no scaling at all but you don't use MY sources).

Because mencoder is in an alpha stage of devopment. Period.
For me the discussion ends here . There are other problems I had and not you (crash with last build, twice the number of frames encoded than the real ones* in the video, grainy picture even with no noise added...).
And in this big bag you can addd the one of underflows : Kwag says he has none, I use to have DOZENS for each encode I did (with ans without noise added).

Mencoder ? Out... bye bye.

Do loose you time with this, I will live without.

* I insist of this one because nobody even try to investigate on that. For me that is related to a mislead in the progressive/interlaced detection and if it is really related to that, you can imagine how bad is the output

The colorproblem has NOTHING to do with alpha stage! As you can see using your eyes above and if you would beleive on my results I did, even using regular sequences! (period), but I dont want to force this argument more and more ....

Well phil, ... till now we both did "discussions" like this to find out finally conclusions but I do accept your way if you drop things like now.
(Btw: why then you get into it again like in here?)
If everybody would end up in such a mess THAN it makes NO sense and we would loose time in such a case i would agree.
You take your decision I do respect that, I DONT want to insist on mencoder BUT if I do see that a colorproblem "could" result of a simple mistake, then I think its nice to figure THAT out. And THATS the purpose of my whole latest posting count.

But if dvd's also turn out different sometimes it wouldn't really be an xvid issue.
And Tmpgenc's quality isn't worse and the colours are correct. Mencoder is still in an early stage so it's not really fair to compare them.
Maybe the issues will go away in a later build.

So Avis via makeavis does work?? As I do see in your log!

Btw ... thats not XVID direct input as the xvid decoding by this will be done via avisynth and therefore by the Codec dll in your system32 folder.

Hi all,
sorry if I wrong you with my last post some posts earlier. The problem I was getting wasn't related to bad colors (I wish I could focus on looking if colours are OK), but that latest MinGW mencoder versions (CVS and pre) were crashing on second pass when loading a video via makeavis (with correct codecs.conf in mplayer).
Well, I solved this problem when instead of using lmin=0.01 I used lmin=0.1 But I prefer to use latest Inc version (downloaded ), willing that it will solve my other problems (and because it loads the fake avi without needing a codecs.conf, did you add the support to ffvfw Inc?).
My other problems are:
- when encoding mpeg2 with maxrate=2500, I get bitrate peaks around 4000 (and when maxrate=7000, peaks 8300 ).
- the worst problem (because it also affects KDVD) is that my player doesn't play well the video stream, and in sudden action it plays in a step-by-step way, even desynchronizing audio. And it doesn't need to be a too high bitrate peak: in my last test (Harry Potter Chamber of Secrets 352x28, at the begining when the camera flies between clouds, the player slows a little, but in bitrate viewer I just see a raise fron 300 to 1300 KB... still don't know why is happening this.

BTW, how long have we gone OT?

Makeavis works with your version and the one included with MencodeMe but not with the one on MplayerHq

This is from the avi I was using in in the fake avi. I could be wrong but it looks pretty much the same to me

Now, wait a minute.
MakeAVIS that comes with FFvfw works with any mencoder build, period.
I've tested that with many home made CVS builds and with the ones posted at mplayerhq, and I have their latests.
That's only a matter of having the right codecs.conf file in a folder named mplayer inside the folder where you have mencoder.
What I haven't been able to use is makeAVIS that comes with latest FFdshow and that was working with early mencoder builds.
So let's not twist the discussian here
We've been talking about color issue
Who has seen this issue and in which cases?
VOB source/AVI source/fake AVI by makeAVIS/PAL/NTSC/KDVD target/KVCD target/long 24-25GOP/short 15-18GOP, etc.
Please post as much info as you can because I'm :banghead: here trying to replicate that and I simply can't
TIA
Cheers

__________________
Rui

Unpredictable result according to the PC on wich you are working IS !

As I said, the discussion is already stopped for me. I really don't have more time to play with mencoder.

I never said I don't believe you, I just suggested to push the test a further more to be sure off the result. That's not exactly the same thing.

Because someone asked a question for which I had a answer.
Because this is not because I don't want to lose my time to do more tests that I consider my former experiences as inexistant.
Because as I told (in other thread may be ?), if nobody explains to Kwag why and how mencoder is NOT a such good encoder, anyone (I mean the majority here, not people like you or some othr heavy testers) will just drink what he has to serve like if it was god words.

I'm deeply sorry but the extract he provided about Back To The Future is awfull. I don't care about the source quality ! And I don't care if the result took 1.6GB or 3 complete DVD ! If anyone would have produced that with other thing than mencoder there will be noone to qualify that as good. We all know that there is lot of ways to have far better results whatever the quality of the source.

Just to return back to this color problem : I'm not the one who mentioned it. I just been happy to see someone mentioning it.

Did I say "stop using mencoder" ? No ! I just said "dont loose your time on this problem (the color problem I meant), I will survive without it (mencoder)".

I don't see which mistake I can do by simply opening a source and asking to have a decent result.
I do not have any codec.conf file (nor any conf file at all).
I have the same xvid codec realease than anybody (and surely you)
I use winXP and a correct installation that works anytime, whatever the job I do.
I use a mencoder release that you used to try also (I guess you try the builds you provide )

The only real diff is that you are using an Athlon and I have a P4. IF that is the source of the problem THEN that really confirm that mencoder is not a stable encoder !
We all agree that there are big diff between the processors, but a well coded software should give the same results on both architecture.

FYI I tried to use the generic build (the one that crashed on my PC) because I started to have suspicion about a problem with the P4 specific one.

That's also why I will try the build you did today but as I said, I have a lot of things to do so I wish koekies tries it also.

As said just above, I don't have ANY conf file, nor ANY mplayer folder anywhere on my PC and makeAvis file work like a charm with mencoder.

What a really stable and predictable encoder we have here...

Oke Inc I downloaded your new build should I change some things in the codecs.conf you get with the mplayer source (in the etc directory)
to the things you say in the Latest CVS Snapshot Mencoder Builds topic?


EDIT: there are 2 codecs.conf in your the pack shot I downloaded both in the mplayer sub dir should I just copy mencoder there?

I found both these xvid settings in your codecs.conf wil mencoder choose ffmpeg.dll? Could I delete the bottom one?

[/code]