Now you can quickly see how mencoders internal filters mess up the colours of your source :P



EDIT by Inc.
This "color" subject was separated from this thread:
http://www.kvcd.net/forum/viewtopic....11515&start=48

What do you mean Koekies?
I haven't noticed any color-changing effect when using mencoder internal filters.
Have you?
C ya

__________________
Rui

I haven't either
It can be clearly seen on the Back to the Future original VOB captured screenshot I posted (crappy source, I know), that the colors are identical on both the VOB and the one I encoded with mencoder.
So I don't see why people are seeing a color mismatch
However, I'm not sure is this is because people are doing AVI conversions, and then, it could possibly be a color space issue.

-kwag

The colors are screwed up at least by the scalers. You all use lanczos (sws 9) ? It's one of the worst

I suggest you to use sws 10.

See there :
http://www.wieser-web.de/MPlayer/sws1

Sorry folks but I cant duplicate these color probs as seen in the link!

a) Maybe these tests are old and therefore an old build was used where a colorpsace conversion was forced before when scaling!! Remember?

b) When I did that mega mencalc-checking workout using standard "tv-geometric & color patterns" there I also didnt had any color probs.

Do you think I would waste my whole time in doing GUIs for a "thing" which would result in such worse qualities??

Sorry but I did

BTW, the first one that duplicate my semi-permanent problem with vobs source encoded with the double of the real number of frames wins a teddy bear.

I'm not ready to stop telling that this encoder is not stable...

I don't use scaling because I do not need to scale. Remember ?

I don't see why you mention that. WHy should you have more problem during these tests that during all your other encodes ?

I don't know for you but I stopped using it... Do the conclusion you want

BTW, what does this sentence means ? I am the king of the color screwage and if I tell you there is not, THEN there is not ?

Tsssss.....

We all have to give you credit for being very persistant Phil
I know that if you say you had color problems is because you really did
Did you try to replicate that lately?
Did it happen with all the sources you feeded mencoder with?
There's gotta be a pattern there
Can you try and help us find it?
Cheers m8

__________________
Rui

Sorry guys, but I gotta agree with him in some respects.

I also found colour wandering in mencoder, but I fount it mainly noticable on the 6 luma bicubic / chroma bilinear filter.

I have to admit I didn't see it on the lanzcos filter.

(Hey, can I still have the teddy? My wife collects them... )

v-- I'm with kwag, use sws 2 mostly --v

__________________
|
Meeow!

Nope. sws=2

-kwag

I mentioned it cause of these Test patterns I used.
Ok, mainly I used them cause of their Geometric graphics content.
BUT they also do got color bars (some of them a lot color bars) and that was the case i.E. where I would see clearly what colors do come out.

Here's for example the "Philips PM5544 Electronic TestCard".
(Its an orig state out of a very nice test pattern maker program.)



Everybody could take that (well its 768x576 but the resol. conversions I posted below) and do an avisynth imagereader line where that avs will via Makeavis be inputted in mencoder. And do some tests

For PAL:
ImageReader("Philips PM5544 Electronic TestCard.tif", 0, 100, 25, true)
ConverttoYV12()
Bicubicresize(704x576)

For NTSC:
ImageReader("Philips PM5544 Electronic TestCard.tif", 0, 100, 23.976, true)
ConverttoYV12()
BicubicResize(704,480,0,0.6,0,1,768,574)

These scripts do give a PAL or NTSC size/PAR compilant 100frames long stream of 704x576(480)px to the encoder.
And THATs a way to find out WHAT will be done to colors. It makes no sense that many people do use diff movie inputs but do all try to see mencoders behavior related to colors.

so:

- which build is used of mencoder?
- what colorspace goes in?
- Does mencoder log report a colorspace converson (mine i.E. not if I go in with a VOB!)
- Which decoder type is used "within!!" mencoder
- Whats the source? Xvid, VOB, .... so: what input codec?
- Use the testpattern above as reference to see what results.

.... because that would be interesting why I dont have a problem but some other users DO have.

Maybe its just a little "thing" which is done wrong by some users which we could find out and for suhre solving that.




PS: I just made a fast test:
A Mencoder output at 704x576 out of that testpattern above:
(scaling via Avisynth)




(scaling via ":scale:" in mencoder -sws 9)




And ..... TmpgEnc
(scaling via Avisynth)




And that happens in case of direct VOBs inputs in ALL my cases also!


So the conclusion for me is clear

And tmpegenc with v4 script at cq 70



And mencoder with v4 script bitrate 1160

Is an example of what the internal filters do to my avi sources (its also avs filters and mencoder as you can see in bottom pic). It's very clear in avi in dvd you have to look better bent when you use avisynth the colours are correct.

Hi Koekies!

I didnt understand your workflow ?

You did enter in tmpgenc using an avs where a XVID is inputted???

and on the other hand you did enter in mencoder by importing that XVID source directly and used the mencoder internal filters instead of avisynth??

So .... in here also a "codec issue" could be the problem, means how the "decoder" which is used to render the colors of the source codec input.

So tell me your EXACT input codec (I see you use XVID)
AND what is used as decoding dll in Mencoder AND in the Winsystem.

From top to bottom

-The source an xvid (5 min sample)
- tmpgenc3xp without filters mpeg2 cq70
- Mencoder with internal filters bitrate 1160 2 pass (different colours)
- Tmpgenc 2,5 with v4 script and cq 70
- Mencoder with v4 script and bitrate 1160 2 pass (different colours)

Your mencoder output is more "orange" then "red" in the face of the actor.
So I think theres something going on strange in "your" mencoder build and its used internal xvid decoder??

Theres something strange happen, cause as you see I dont got these probs like you can see above.

I encoded them with the build included in MencodeMe

@rds
When you asked "Did you try to replicate that lately?" I thinl you want to say "Did it happens with lastest mencoder releaser" ?
In fact I used only one release, the only one (I know) Inc does specially for P4. I can't tell you if there is a better one since then.

Which kind of sources ? All !
Now I can't remember if the things where better or worst with a vob or with something read with a makeAVis file. I think there was with makeAvis.

@Inc
Color screwing is due to rounding in time with color compenent fluctuation between frames. For sure, with a static picture, you can't have that

But your snap are interesting to see how mencoder picture is worse than tmpgenc ones (i'm just ki!dding here, but it's true, look at the borders of the external circle)

@koekies
Thanks for you snaps.

This was made with inc's latest build as you can see the same problem occurs

As you know me, IF I do place static picts then I do it as seen as an average which stands for the whole encoding , and for shure I checked a count of frames (IBP) otherwise I wouldnt make an opinion on that, cause I for myself want to come to a conclusion.


Could be that the first one (Avisynth resizing & Mencoder) is a Bframe as I did encode at AVG 1800.

But you clearly see at the last two that there the mencoder picture does also have a clear non-ringed circle. ... cause I used the Mencoder internal filter sws9 and :scale.....9:.
Tmpgenc was used at CQ 75 (if I do remember)

Well In here we where talking about a color problem. But We already did found out that in case of 2pass even when using less filters in mencoder the pic is less blockier then when using CCE.
But we already had so many discussions about that, so the pics here are for COLOR comparison



@ Koekies

WHAT does include your codecs.conf ???

Maybe the pointer to XVID forCC based inputs do point on a system dll in your system32 folder which gots a bad decoding behaviour (just assuming) ... hummmmm

SO do look in the console log whats used to decode your XVID input!!
Is a winSystem32 dll used or the mencoder internal XVIDlibcore ???

Well that latest build provided by me is an OLD build! Since that time many new CVS snapshots where offered at the mplayerHQ server.

I didnt keep providing newest builds as my free account limit is reached very fast ... and nobody wanted (Maurus was the only one!) to share that providing of those builds as asked there in the thread. But users where downloading and downloading and downloading.

So sorry for that.
Best would be to get the latest MINGW compiled snapshot from the mplayer win32beta page:

http://www.mplayerhq.hu/MPlayer/releases/win32-beta/

These are newer than my latest builds and maybe they do have a fix related to colorprobs??? Cause that "could" be now proofed in our workout in here

Inc,
I already downloaded the CVS version from the url you point at, trying to see if a different mencoder version helped
in the hugh problems I'm having lately...
Well, I'm just posting to say that it crashes on second pass. I'm using a avs source through makeavis, did first pass
without a problem, but when begining second it crashes.
Anybody else with the same problem, or is my PC asking formatting?.
I'll retry with a vob source