View Full Version : xvid / cce - which has better red?
cooper99
27th December 2003, 20:40
I've been a long-time user of xvid, and have begun using Cinemacraft due to the red/orange blocks situation. Has the pixelation in red/orange scenes been resolved, which I've read is a problem in mpeg-4 codecs compressions such as divx and xvid. I've viewed 2001:Space Odyssey after encoding with xvid, and there are many many scenes with red in them, apparently pixelized. Now, why does cinemacraft have no problem compressing red-orange areas of a movie? I know using CCE results in .mpg format, not mpeg-4.
Teegedeck
28th December 2003, 01:02
There have been lots of discussions on different colorspaces; perhaps interesting reading for you: http://forum.doom9.org/showthread.php?s=&threadid=38304
It ain't an MPEG4-problem, but mostly one of colorspaces and hardware.
Tommy Carrot
28th December 2003, 01:27
I think 'chroma optimizer' is supposed to solve this problem, but i didn't try it yet, so i cannot comment.
mikeX
28th December 2003, 04:15
i would say that chroma optimizer is definetely not the answer to this problem...
what seems to work for me at this time (and i just started dealing with this problem a few hours ago) is either the 'ConvertToRGB32()' thing discussed in the thread Teegedeck mentioned or the MediaPlayerClassic VMR9 renderless option also in that thread (even without the VMR9 MPC gives great results, how could i have missed out on this great piece of software all this time...)
i'm testing on "Wings Of Desire", Teegedeck might know the movie, it has some really bright reds (as many wim wenders movies do)!!!
(Just for the record: Before i found out about these threads (and the colorspace/mpeg-4 problem) i tried an avisynth aproach using 'Tweak(saturation, hue, brightness, contrast)', messing mostly with the saturation and the contrast. While that gave good results when i previewed the avs file, it failed miserably on the final encoded material which confirms the decoding orientated nature of the problem)
Soulhunter
29th December 2003, 20:35
http://forum.doom9.org/showthread.php?s=&threadid=38304
Ohw, I remember... (8th July 2003) It was my first post here !!! :D
Im still thinking the whole problem could be solved with better tweaked GC drivers...
I would write to the CG producers, if I would know a bit more about this stuff... ;)
Does someone know whats the difference between the display method for mpeg4/avi -> mplayer2 & ffdshow...
And VDub's preview or PowerDVD's MPEG2 decoder... ???
Because mpeg4 -> mplayer2 + ffdshow will result in blockfree-red's, because of hardware upsampling !!!
But VDub's preview mode and PowerDVD's MPEG2 decoder give me still blocky-red's !!!
I thought both methods are using DS (DirectShow) !?! :confused:
Is there a quick way to check what DS/Overlay method is used due de-compression and change/skip them while doing this ???
Should I get different results with disabled HW acceleration for my GC ???
Bye
mikeX
2nd January 2004, 17:36
i still get blocky reds even with mplayer2 & ffdshow, but they go away if i use "ConverttoRGB32()" in ffdshow, so i think it's more a matter of colorspace, not so much whether you use dshow or not
i get blocky reds even witn mplayer which doesn't use dshow
it's log file states that it transforms to 24bit RGB(http://forum.doom9.org/showthread.php?s=&threadid=67007&perpage=20&pagenumber=3), so i'll have to find how (if possible) i can make it convert to 32bit RGB and see if the blocks are still there
Soulhunter
3rd January 2004, 22:40
i still get blocky reds even with mplayer2 & ffdshow, but they go away if i use "ConverttoRGB32()" in ffdshow, so i think it's more a matter of colorspace, not so much whether you use dshow or not
Uhm... Have you read the thread Teegedeck linked too ??? :rolleyes:
Already know that its ONLY a colorspace problem !!!
Better said, a wrong chroma up-sampling problem !!!
But some GC'S like my Radeon9200 have a in-build colorspace conversation YV12 -> RGB32 !!!
This eliminates this red-blocking, but not every time...
As Ive posted... "it does not work in VDub's preview mode" !!!
So I guess it does only work when the application uses hardware acceraletion... :confused:
That some GC's eliminate this problem, and some not, is very confusing... :(
Also that this is not working with all applications gives some headache !!!
So, my conclusion... Its GC-driver related !!!
Bye
mikeX
4th January 2004, 04:22
ooops, sorry, i didn't fully understand your first post :rolleyes:
i'll be more careful next time :)
Soulhunter
4th January 2004, 20:26
Ooops, sorry, i didn't fully understand your first postNo problem... ;)
Bye
mf
4th January 2004, 22:38
It doesn't work in Vdub's preview because Vdub only uses YUY2 for hardware acceleration, instead of YV12. So somewhere is a software conversion for YV12->YUY2, and from your findings it would seem it's not upsampled :).
Soulhunter
5th January 2004, 18:18
It doesn't work in Vdub's preview because Vdub only uses YUY2 for hardware acceleration, instead of YV12. So somewhere is a software conversion for YV12->YUY2, and from your findings it would seem it's not upsampled
You have enlighten me again... ;)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.