Compression of Red and Dark Orange

[Mango Madness]

I did a 2 and 3 CD encode of Attack of the Clones with Koepi's latest stable version, 6 motion estimation, Mod HQ, and rest were defaults. The movie looks spectacular other than whenever there are red or dark orange parts of a scene, they appear blocky as opposed to the other parts of the movie which are perfect. I don't know if this is due to something with human sensitivity of reds or if something else is to blame. The movie looks absolutely perfect other than those scenes with red walls (ie, the very beginning where the Jedi are meeting with Palpatine). I'm not done trying stuff; i just wanted to see if anyone else has witnessed this phenomenon.

[Dali Lama]

Of course, we have witnessed this phenomenon :)

Tell you the truth, it has something to do with the way video is compressed in MPEG-4 and other formats as well. I'm sure someone knows the technical info, but basically there isn't much we can do.

A similar issue was presented a while ago in the LumiMasking thread in this forum concerning blockiness in dark areas. Some filter tricks were proposed to correct the issue somewhat, but isn't perfect and has downsides.

Perhaps we could try out different settings of smoothers and color correctors to try to resolve the "Red Blocking" issue.

Its really something that has to be worked on,

Dali

[sysKin]

Could you try "Chroma ME" switch? Chroma motion estimation is especially designed to help with color artifacts - usable mostly with animation. It will also improve quality of the rest of the movie (very slightly).

Encoding will be about 10% slower with it :(

I'm really interested if it will help - it's a new thing and noone ever made a good visual comparsion.

Radek

[-h]

One thing I've always wondered about is that the colour block problems in YV12 "look like" they could be alleviated somewhat by altering the Y values of the current 2x2 block to better blend the apparent brightness change.

I will put it on my growing try-it-and-see list.

-h

[Soulhunter]

Hi, (and sorry for my bad english)!

I think this is not really a help for Mango Madness's problem but maybe it helps to get a rid of it.

I had the same problems like "Mango Madness" with all my encodes (In some more in some less).
Not only with XviD, also with every other Mpeg4 based codec.
I remember that I did a test encode of some bonus scenes of DVD
"The Mummy returns". I encode them with XviD and DivX5... both with all kind of different settings "for testing". Then I captured sample frames from the original DVD, and then the same frames from the encodes to see the difference between them. I saved the frames in 24bit Bitmap format. In all Mpeg4 (not the DVD) frames I saw blocks or some kint of lines in the red color parts. I thought its a problem with the codecs... but later I converted the Bitmap pictures to JPEG with 100% quality to save DiskSpace (yes it's lossy but lossles enough to see the quality of the picture). But later when I watched the pictures again all the "red blocking" where nearly gone. So I made some more test... And see... Every time I converted a Frame with
XnView from BMP to JPEG the blocks gone! I was not able to get a rid of this situation... What causes this? But later I found out a other thing. I do a lot work with pictures and so... So I work a lot with Picturework-programms like Photoshop, and I found out that the decompression filter (I think) of Adobe Photoshop 7 causes the same problem... Lot of "compressed" pictures with red colors in them have the same red blocking problem. But only if I open them with Adobe Photoshop, with the PicturePrewiev funktion of Windows there are no blocks in the pictures, but with PhotoShop there are. So I think it must be a problem with the decompression filter of Photoshop... And maybe it's the same thing with Mpeg4 Videos...!
Please someone who knows about decompression filters should read this and say what he think's about it.

In respect to all Doom9 members and thier work best ragardsfrom Soulhunter!

Bye!

[Selur]

like -h wrote, seems to be a colorspace (Yv12) problem, so maybe it's not visible if one would change the video output to another colorspace (e.g. RGB)

btw. does anyone know if -h did some more investigation,..

Cu Selur

[Koepi]

No, -h didn't do further investigations.

However, we have that "chroma optimizer" option which could help that problem.

Regards
Koepi

[kilg0r3]

@soulhunter
congrats for a very nice first post :D

[OBcecado]

Hi, I've done a 3 cd starwars ep2 encode with last koepi's build too (XviD-24062003-1) using the h.263 matrix chroma motion and chroma optimizer, and it looks good in the scene where palpatine meets the Jedi and in that kind of factory where the droids are being made, seems that chroma optimizer helps it, gonna test to encode the movie without that.

All the best.

[Prettz]

What about something like a reverse-lumimasking, where large areas that contain low luma values and high red chroma values get MORE bitrate (but not necessarily lower quants)? It seems like a nice idea but my guess is that it would be very hard to do in practice, and even harder to get it to work with xvid's existing bitrate allocation code.

[Soulhunter]

Hi again !

I just want to tell that I've redone my experiment "read my last message", and I was right...
I made a encode of "Equilibrium" (nice movie) and captured a picture where a red light was right in the middle of the picture...
I saved it in 24bit-RGB-Bitmap (BMP) format. The red light looked very blocky... But after converting it to JPEG they where gone...
Even after resizing the Bitmap to 200% (blocks where more than seeable) the converting to JPEG killed them...!!!!

For every one who dont belive this...

Here are all information you need to try it your self!

I used "XnView Version 1.31 (Feb 25 2002)" with the options "Quality = 100%" and "Optimized Huffman Tebell = ON". But It works also when "Optimized Huffman Tebell" was setted OFF...

So I go on to think its not the MPEG4 codec itself its only the decompression-filter...

Please someone that knows something about filters n' stuff should read this, because this "red blocking" thing is one of the biggest problems of MPEG4...

Maybe someone get a clue by reading this...

Bye!

[Mango Madness]

If you look at the date of the post, you'll realize that this problem was very old and has sinse been eliminated, even with 1 CD encodes. I'm not completely sure why this thread got a bump 8 monthes after it died. Anyways, yeah, I don't have this problem anymore I just have new problems ;)

[Prettz]

Originally posted by Mango Madness
If you look at the date of the post, you'll realize that this problem was very old and has sinse been eliminated, even with 1 CD encodes. I'm not completely sure why this thread got a bump 8 monthes after it died. Anyways, yeah, I don't have this problem anymore I just have new problems ;)
I decided to add a post to this thread because the problem has not truely "gone away", it's a general problem with how MPEG4 compresses it.

Even with the best codec and the best settings you still get not so great results in dark red scenes. My suggestion was "well, detect when it happens and throw more bits at it." Using up a few hundred KB more on one particularly dark, particularly red scene is preferable to the bad impression it leaves when the codec over compresses scenes like that.

[Soulhunter]

Hi, once again...

First I want to say that the red blocking broblem is not gone... Its still there with every MPEG4 based codec. All of them, (also newer ones > XviD-04102002-1, DivX 5.05 etc.) have still this problem! (I can see It right now on my screen !!!) I dont speak of the "Black-blocking" or "Luma-block" problem... I only mean this "red-blocks", you also have with HQ-encodes (3000 kBit/s or more...)!

But now the good new's !
I found out what causes the "red-blocking" termination in my JPEG-Files (Read my last two post's)!
I compressed the BMP-Files from "Equilibrium" again with HyperSnapDX, first I used JPEG compression by default "JFIF 4:4:4" and the blocks still remain in the resulting JPEG... Then I used the "JFIF 4:2:2" compession but the blocks where still there... Then I used the "JFIF 4:1:1" compression... And see the blocks where all gone! So it only works with the "4:1:1" compression? (I don't know much about this compression things) I ment the quality of the "4:1:1" picture must be lower than the "4:4:4" one, right? Ok, maybe you see the difference when you compress a HQ-Picture, but it doesent matter for an MPEG4 encoded picture... So could it help to tell the decoder-filter to recompress the picture with this "4:1:1" compression? Or would it need to much CPU power to decompress the picture, recompress it and then decompress it again? Or is there simply a other easier way for this?
Please everybody, post what you think about it...!

Bye

[Koepi]

a) 04102002-1 isn't an actual build, it's the latest so-called stable one. If you use a current unstable binary, choose chroma optimizer on the debug tab and no red-blocking/stairstep artefacts should appear.

b) 4:1:1 is comparable to YV12 which is the colour space in use. Maybe you should try a complete YV12 processing chain and see the wonders of no colour space conversions. Head over to the avisynth forum and read about the "YV12" sticky thread.

Koepi

[Soulhunter]

Hi everybody,and thanks to Koepi !

a) I will download the latest XviD build later this day try by my self...

b) Thanks for the Info "4:1:1 is comparable to YV12" I dont know very much about this things ...but I thought YV12 uses "4:2:0" and YUY2 uses "4:2:2", whats 4:1:1 now? (I dont want to blame me, or have I allready done it ?). And witch "sticky thread" you mean? Im sorry but there a lot of threads... So could you put a link in your message ?

Thanks n' Bye

[Assault]

@ Soulhunter

I think Koepi meant this thread (http://forum.doom9.org/showthread.php?s=&threadid=37276). ;)

Assault

[unmei]

If you use a current unstable binary, choose chroma optimizer on the debug tab and no red-blocking/stairstep artefacts should appear.

It might have improved a lot, but even with 2003-06-24 /chroma motion and chroma optimiser it's not completely gone.

The situation im thinking about is this: i encode anime DVDs and in the very end of the avisynth chain i add SSA subtitles with VSfilter (therfore no filtering on the subs). The normal subtitles in light yellow or light gray are cristal clear, but i have this "logo" indicating the series, episode number and title i add add the beginning and end. It uses a fantasy font and red #CF0000 - there the stair steps appear. They are not really bad but compared to the previous excellent subs it looks quite surprising.

I use huffYUV to temporarly store the avisynth output since my comp is not that powerful i would dare to do the filtering twice for 2pass, therefore a yv12->yuy2-yv12 conversion takes place. that could cause some errors but i dont think its the main issue with this as it also seems to appear in test encodes without the colorspace conversion.

i dont consider this a real problem, i just wanted to point out these artifacts have not completely vanished with using the chroma motion+optimiser . It could even ve a problem only remaining in subtitles as you usually don't have such clear borders of red areas as with a red font overlaid on black/whatever

[Koepi]

Store your intermediate movie with MarcFDs VBLE codec which uses YV12 and is lossless like huffYUV. I hope this will show better results.

Best ergards
Koepi

[Soulhunter]

Hi, again and thanks to Assault for the link...

I tried the new XviD build with "chroma optimizer" for and encode of "Batle Royale" encode. At the beginnig of the movie is a big red spinning logo...
When the red logo looks burry (also blurry on DVD) >" Frame 600 " everything looks ok, but when the logo gets detailed " Frame 1145 " its pixeled (pixolous?) like everytime before...!
This chroma optimizer improved the quality everywhere else (I think) but it helps not for this red-blocks. I encoded the first chapter with "XviD-24062003-1" and "DibX5.05" both at 2500 kBit/s and 512x384 Pixels, and the XviD encode generally looks better than the DivX one (more detailed) and its smaller too ;-)
It seems that "chroma optimizer" helps to save quality... (maybe I change my mind about "unstable builds") !
But "chroma optimizer" does def. not help against this red-blocks :-(
And again the compression from DivX/Xvid to "JPEG 4:1:1" pictures terminated this red-blocks !!!

--------------------------

In adition to this I think I have explain this thing with this "red-blocks".
The red areas not real look blocky (as it looks if you dont use enough bitrate... >16x16 >8x8 pix.) They look more somethig like "pixelous", more like 2x2 pix. (The red arears look if they would be resized with nearest neighbor, and the rest of the picture looks normal).

I read somewhere that the compressor uses something called "chrominance subsampling" that uses a lower resolution for chroma information than for the luma information. Maybe the decompressor does something wrong when it rize chroma back to default res. Thats why I thought its a problem with the decompress-filter (some parts of red-spectrum dont get blend together at the right way) or so... Is it not possible to tell the decoder to blend the red chroma stronger than the rest when it resizes the "chroma-map" (or whats it called)?

When my thoughts are wrong/impossible because you know it better then "sorry for my long posts" !

But I've again some more questions:

1.)
-h said "problems in YV12 "look like" could be alleviated somewhat by altering the Y values of the current 2x2 block to better blend the apparent brightness change"
So are the red-blocks in my 4:1:1-JPEG's gone because "4:1:1" uses other values for position/scale of pixels or because it uses an other bits per sample ratio (or Im just to "stupid" to get it) ???

2.)
And, is it now possible to build a decomp-filter that does the same things like I've done by hands ? ( YV12 -> RGB -> YUV 4:1:1 -> Output ) ???

3.)
XviD/DivX = YV12 = "4:2:0" comp. not "4:1:1" comp. / and YUY2 also "right" ?

Please post back!

Bye

[Prettz]

Originally posted by Soulhunter
3.)
XviD/DivX = YV12 = "4:2:0" comp. not "4:1:1" comp. / and YUY2 also "right" ?

YV12 means that for each 2x2 block of luma pixels, there's a single U and a single V. So chroma is subsampled in both the horizontal and vertical directions (I forget how you express that in the correct "notation", in fact I still can't figure out what any of that "x:y:z" stuff means). YUY2 is only subsampled in the horizontal direction, so for each pair of 2 luma pixels there's a single U and V.
Also, are you saying that JPEG can compress in RGB, YUY2, and YV12? I didn't know it could do that.

But anyway, back to the red blocks, the YV12 isn't really even the big problem. It's just that MPEG4 compresses chroma information much more. Usually this is just fine, but it's with dark reds in particular that MPEG4's methods to compress in a way that the human eye can't easily notice are not exactly perfect.

[Soulhunter]

Hi again,


@Prettz:

Thanks for the info, But I found some Info about this X:Y:ZY stuff elsewhere (see links below):

Still dont know where the green value left... But I "think" this Info is right...!?!
> YUV = Y=Luma U=Blue V=Red
> 4Pixels in YUV = 4x Info for Y+U+V (4Y 4U 4V = YUV 4:4:4) ???
> YUV 4:1:1 means all Info for luma remains but Info for chroma gets reduced to 1 Pixel (both red and blue...) I think...???
> YUV 4:2:0 means all Info for luma remains but Info for blue Chroma gets reduced to 2 Pixel and red chroma gets reduced to 0 ???
> So 4:1:1 and 4:2:0 use same amout of bits but 4:1:1 uses more for red chroma...???

Here are the links:
German > http://www.weblearn.hs-bremen.de/risse/RST/SS98/compress/Kompression.htm <
German > http://home.t-online.de/home/ing.sed/DIGIT.HTM <
German > http://www.uni-kassel.de/~eckhardm/Frame8HQwip.htm <
English > http://www.studio1productions.com/Articles/411samp.htm <

-----------------
@All

> Uhm... Ok! Im not sure if I understand this right but does this mean YV12 (4:2:0) uses no Info for "RED" ???
> And whats with "GREEN"? Is there no Info for GREEN in YUV or does it mean its saved fully (without "down-sampling") ???

-----------------
@Prettz:

You wrote "Also, are you saying that JPEG can compress in RGB, YUY2, and YV12? I didn't know it could do that" -> Hmm? No! I nenver said something like that... I wrote that I compressed the "captured" Bitmap-files (RGB/24bit) to JPEG (JFIF 4:4:4, JFIF 4:2:2 and JFIF 4:1:1). -> ad."YV12 uses 4:2:0 and YUY2 uses 4:2:2 (I think...???)"

If you mean the 2nd question of my last post "( YV12 -> RGB -> YUV 4:1:1 -> Output )" This was just the explaintation for the things I did with the captured pic's (make a screenshot from the video "video is YV12" -> saved screenshot "24bit-RGB-Bitmap" -> then compress the BMP-file to JPEG "YUV 4:1:1" -> then decompress it in the regular way... (Hope this explains it) I dont want to compress the video this way, I want to have some kind of pre-processing step in the decompressor, because this kills the red-blocks !!!

-----------------
@Prettz:

You also wrote: "the YV12 isn't really even the big problem. It's just that MPEG4 compresses chroma information much more"
First: I know, its not this YV12 thing... As I wrote above the "recompressing" to JFIF-4:1:1 killed the red-blocks, but I had problems to understand why (1st question of my last post)
Second: "chroma is compressed more" Yes but this is true for all colors (not only red).
So why this problem is only noticeable in red arears?

-----------------
@All

When I wrote "this red blocking thing is one of the biggest problems of MPEG4" I mean Its one of the biggest problems for me... All my encodes look real like DVD-source (most 3 or4 CD's) and I'm very happy with XviD/DivX5...;-) The only thing that "disturbs" me, are this red-blocks!

-----------------
@Koepi:

Yap! I went to this "sticky thread" and saw the wonders of no colour space conversion...
The last day's I encoded some Movies with AviSynth v2.5 and it speeds up everything (NICE!!!) But also doesn't help me with my "red-block" problem :-(
Anyway... Chroma-optimizer helped me to save quality and AviSynth v2.5 (YV12) helped me to save time :-))) BIG THX !!!

-----------------
@All

By getting more Info about all this stuff i rethought my last posts...
-> ("its only the decompression-filter...") Now I think this thoughts where wrong! The "red-blocks" CAUSED by "MPEG4" but they could be SOLVED by a "Post-processing-step" in the decoder-filter...!
The normal decomp. process is; "YV12->Output (RGB)"
So there should be added this processing; " Output (RGB) -> YUV 4:1:1 -> Output (RGB)"
So it should look like this; [ "YV12 (DivX/XviD) -> RGB -> YUV 4:1:1 -> Output (RGB)" ]
I think this should solve the problem right?

If I'm still wrong tell it to me...!


Bye

[Acaila]

> YUV = Y=Luma U=Blue V=RedNot quite...

Y = R * .299 + G * .587 + B * .114
U = R * -.169 + G * -.332 + B * .500 + 128
V = R * .500 + G * -.419 + B * -.0813 + 128

Other sources usually explain this with:
Y is calculated by taking the R G B channels with certain weights
U is calculated by taking the Red channel and subtracting Y
V is calculated by taking the Blue channel and subtracting Y

As you see Green isn't mentioned there, this is why YUV is called a compressed colorspace. Green doesn't need to be stored because you have Red and Blue already, from which you can calculate Green perfectly, so that it takes less storage space than full RGB 4:4:4.

> 4Pixels in YUV = 4x Info for Y+U+V (4Y 4U 4V = YUV 4:4:4) ???
> YUV 4:1:1 means all Info for luma remains but Info for chroma gets reduced to 1 Pixel (both red and blue...) I think...???

> YUV 4:2:0 means all Info for luma remains but Info for blue Chroma gets reduced to 2 Pixel and red chroma gets reduced to 0 ???
> So 4:1:1 and 4:2:0 use same amout of bits but 4:1:1 uses more for red chroma...???
Quote from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp (you should read it entirely it's very informative, but technical):

-----
4:4:4 means no downsampling of the chroma channels.
4:2:2 means 2:1 horizontal downsampling, with no vertical downsampling. Every scan line contains four Y samples for every two U or V samples.
4:2:0 means 2:1 horizontal downsampling, with 2:1 vertical downsampling.
4:1:1 means 4:1 horizontal downsampling, with no vertical downsampling. Every scan line contains four Y samples for every U or V sample. 4:1:1 sampling is less common than other formats, and is not discussed in detail in this article.
-----
> And whats with "GREEN"? Is there no Info for GREEN in YUV or does it mean its saved fully (without "down-sampling") ???See the top of my post.

So why this problem is only noticeable in red arears?
It shouldn't be a problem of only reds, but I know we do usually experience it that way. I've always belived the human eye is more sensitive to red, however this figure (http://www.amastro.org/at/ot/othcs.html) seems to contradict that. I suggest you take a look at this page (http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html) too, it's a very good read.

[unmei]

hmm i tried VBLE as intermediate codec now and i'm quite happy, only thing is it doesn't resolve the red problem at all, it just gives me better overall xvid quality (beside the smaller intermediate file and faster processing).
i did test VBLE before but for some reason (i dont remember) i decided back then i would stick with huff, now i will stick with VBLE :)

btw tnx all for the colorspace repetition course :D

[mf]

I'm finally back =.=

I've been wanting to reply to this.

About the JPEG compression. The JPEG option you're talking about, simply stores in the same format as your MPEG4, the only difference is that at DEcoding, your JPEG decoder converts to RGB 4:4:4, while interpolating U and V. AVISynth 2.5.>0 ConvertToRGB() does the same. A simple convert to rgb (like most video overlays use) simply doubles the pixels, resulting in The Blocks That Are Not Noticable in Low Saturation Areas but Only in High Saturation™. (FYI: Pure red, green or blue are 100% saturated)
It should by now (used to give crap but sysKin reported that it worked) be possible to throw in a ConvertToRGB32() line in ffdshow's AVISynth field, which would get rid of your blocks by interpolation. So no, conversion to JPEG will not be necessary.

[Soulhunter]

Hello again

@Acaila
Big THX !!! As I wrote before, I dont know much about this things...

Most info I found really confuses me...
But this links helped a lot to understand this.
At least the "Chroma Bug" link is easyer to to read/understand than others I read before.

@All
Im still not sure that this "Chroma Bug" is the SAME or just SIMILAR to the "red-blocking"!

- The sample pics on this site showing more some kind of lines, but as I wrote before this "red-blocking" looks like this: "special" red-arears (not all) are shown in 2x2 pixel blocks... Not as Lines !
- "red-blocking" happens also when the source (DVD) showing nothing like this "bug" (no chroma bugs)
- This bug happens with Interlaced and non Interlaced material also with 4:3 and 16:9
- It happens also when the source is a uncompressed image (no matter wich input format BMP, PNG, JPG... etc.)

So I think this "Chroma Bug" is not the same like the "red-blocking" , but maybe similar cause !?!

But when I'm wrong... It must be possible to solve this problem the same way Denon/ESS did it... Right ??? (Read below)

Copy's from the link:

>http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html<

>Shortly after the first article was published, Dale Adams at Silicon Image wrote an algorithm to detect the chroma bug and remove it. Silicon Image has finally added a chroma filter to their latest box, the iScan Ultra. We had hoped this filter would have made it into the SiI504, but it did not. We hope that when Silicon Image produces the SiI505, they'll integrate the chroma filter.<

>we'll give specific examples of how to properly interpret the flag to determine the right upsampling mode to use, and how to write a filter that fixes both the chroma bug and the fundamental chroma flaw built into 4:2:0 encoding.<


@mf
> "It should by now (used to give crap but sysKin reported that it worked) be possible to throw in a ConvertToRGB32() line in ffdshow's AVISynth field, which would get rid of your blocks by interpolation. So no, conversion to JPEG will not be necessary." <

Sounds good...!
But when I save the captures directly to BMP-Format it happens also... Or not?
As I wrote before in the BMP-Files the red-blocks where still there... And also in the 4:4:4 JPEG's ! :-(
Or is it because I saved it in 24bit not 32 ???

No matter... If I'm wrong:

Is it complicate to write this "ConvertToRGB32" thing into ffdshow ?

So is there a chance that this will be in the next ffdshow ?

And when it doesnt help, Is now possible to build an [ "YV12 (DivX/XviD) -> RGB -> YUV 4:1:1 -> Output (RGB)" ]
postprocessing-step ??? Or would this need to much CPU-Power ???

@All
Keep posting back

Bye

[Hello]

Well, I just encoded with Xvid on a film and throughout on the TV it had DVD quality - I mean just gorgeous video with no pixelation and such little noise (in some areas only also and in so tiny you'd have to focus your eyes on it and stare) but when there was a fire scene, orange came up and some blocks were shown and the same thing happened in one misty smoky scene.

[kilg0r3]

@soulhunter

Is it complicate to write this "ConvertToRGB32" thing into ffdshow ?

just open config dialog of ffdshow, click on avisynth, enter ConvertToRGB32() in the text box, check if the box near avisynth entry in the left column is checked.

actually i think we would have to convert thingx to yuy2 or rgb and then do a blur on the chroma planes (if there are any in rgb). but i don't know hoe to do that in ffdshow, and, i think it would kill your cpu.

anyway this is basically, what we need. increase the chroma resolution and blur the chroma plane.

[mf]

Originally posted by kilg0r3
actually i think we would have to convert thingx to yuy2 or rgb and then do a blur on the chroma planes (if there are any in rgb). but i don't know hoe to do that in ffdshow, and, i think it would kill your cpu.

anyway this is basically, what we need. increase the chroma resolution and blur the chroma plane.
No need, no need. Interpolating is all you need, no blurring necessary. Wait, I'll come up with some screenshots in the next edit.

[kilg0r3]

standing by ... :D

[mf]

Err sorry :o. ffdshow was crashing on me and I went about doing other stuff. Anyway, here's a nice comparison of images: http://nabeshin.ddo.jp/avisynth/images/. rgb.png is the original, yv12.png is how most rgb conversions treat subsampling, and converttorgb32().png is of course AVISynth's chroma interpolation. As you can see there is no blurring necessary, the interpolation already makes it fuzzy enough.

[kilg0r3]

now lets hope this works with my tv-out :/

[Soulhunter]

@ mf

"About the JPEG compression. The JPEG option you're talking about, simply stores in the same format as your MPEG4"

No! MPEG4 stores in 4:2:0 and the JPG-compression that killed the red-blocks compresses in 4:1:1... A JPG-compression in any other form (4:4:4, 4:2:2) does no effekt to the red-blocks...!

But "converttorgb32()" looks like it would work... But for me the "JPG 4:1:1" workaround looks better... But this solves not the "DVD-chroma-bug" Acaila talked about...
> http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html <

No matter... THX mf !


@Acaila

Rethougt;
When this "chroma-bug" is a problem that could be solved by the MPEG-Decoder-Chip in standalones, could it also be solved with a new version of "MPEG2Dec3.dll" for AviSynth ???

Just adding the same code to the MPEG2Dec3.dll should work... Or not ???

Maybe its time to open a new thread in the AviSynth-Forum ?!?

Bye

[mf]

Originally posted by Soulhunter
@ mf
No! MPEG4 stores in 4:2:0 and the JPG-compression that killed the red-blocks compresses in 4:1:1... A JPG-compression in any other form (4:4:4, 4:2:2) does no effekt to the red-blocks...!

I suspect 4:1:1 is simply another way to describe 4:2:0, but I could be wrong. Anyway, 4:4:4 and 4:2:2 don't kill the blocks because they don't downsample fully! If it's not downsampled, it can't be upsampled correctly, now can it ? (losing patience..)
Compressing to JPEG is not the solution. It could also be that the upsampling algo of your JPEG decoder is still better than AVISynth's (I think AVISynth uses bilinear).

But "converttorgb32()" looks like it would work... But for me the "JPG 4:1:1" workaround looks better... But this solves not the "DVD-chroma-bug" Acaila talked about...
> http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html <

The DVD chroma bug is inherent to interlaced coding and can only be solved by a very smart deinterlacer. Interlaced coding is meant to be displayed on an interlaced screen, and these reviewers are looking at progressive screenshots. Well what a surprise. But it is an interesting thing though, maybe someone could write a smart chroma deinterlacer, that would upsample still parts in progressive mode, and moving parts in interlaced mode. OR go motion-compensated from the start (Tom?! :D).

No matter... THX mf !

No problem. Just try to read up a bit more before shouting things, ok? :)

[trbarry]

The DVD chroma bug is inherent to interlaced coding and can only be solved by a very smart deinterlacer. Interlaced coding is meant to be displayed on an interlaced screen, and these reviewers are looking at progressive screenshots. Well what a surprise. But it is an interesting thing though, maybe someone could write a smart chroma deinterlacer, that would upsample still parts in progressive mode, and moving parts in interlaced mode. OR go motion- compensated from the start (Tom?! ).


There are really a bunch of different chroma bugs and ways to screw it up. I suspect that 4:1:1 conversion just softens in the color conversion, since 4:1:1 is subsampled 4:1 horizontally instead of 4:2:0 way of 4:1 subsampling in 2x2 squares. Note that only 4:2:0 creates extra problems for interlacing because of the screwy way it's stored. DV cam interlaced 4:1:1 doesn't have this problem since the chroma does not have to be vertically interpolated across fields or worry about avoiding that.

And TomsMoComp already will already deinterlace YV12 (4:2:0) chroma planes separately, hopefully adding back some of the extra chroma resolution lost in interlaced 4:2:0, at least on good days. Turning on the vertical filter option may or not help the red blocks though.

- Tom

[Soulhunter]

@mf
"Compressing to JPEG is not the solution"
- Ok! I belive you... And I saw it on your pics that "converttorgb32()" works !
Just found that the 4:1:1 way still looks better ! ;)

"It could also be that the upsampling algo of your JPEG decoder is still better than AVISynth's"
- Yap! Thats why I want this algo as an post-processing in a decoder/filter !
I tried chroma blur of ddfshow but it doesnt help much !

"Just try to read up a bit more before shouting things, ok?"
- I will try... I will try... :D :D :D


@trbarry
"Turning on the vertical filter option may or not help the red blocks though"
Tried it... But still now I were not able to kill this "chroma-bug" perfectly ! :(
Maybe you know a combi with other filters that could be usefull ?


@kilg0r3
"just open config dialog of ffdshow, click on avisynth, enter ConvertToRGB32() in the text box, check if the box near avisynth entry in the left column is checked."

Uhmm? You mean there should be some kind of "avisynth-option-tab" in the ffdshow-options ??? Ther's nothing like that in mine ffdshow-options (I use ffdshow v.2003.05.23)...!

Is playing an AVS with the lines "DirectShowSource" and "ConvertToRGB32" the same ???

Bye

[kilg0r3]

In my ffdshow-20030523 the left column reads like this:

Codecs
Info
- OSD
Tray & Dialog
Image Settings
- Crop
- Deinterlacer
-- DScaler
- Postprocessing
- Picture properties
- Levels
- Offset
- Blur & NR
- Sharpen
- Warpsharp
- DScaler filter
- Noise
- Resize & Aspect
-- Settings
- Perspective Correction
- Subtitles
-- Font
- AVISYNTH
- Visualizations
...

[Soulhunter]

@kilg0r3
About "avisynth-option-tab" ....
Ooooops! Sorry, my vault! :eek:
I thougt I use v.2003.05.23, but forgot that I installed a older version the last week...:D
[Install the new] -> Ok I see the AviSynth-Tab now ! :D
Sorry for my nonsense question !!!

But I seems that it's not working...
As mf wrote ddfshow crash's when I try to open the file...:confused:

But playing via AVS->Directshowsource->convettorgb32() works! (but without sound) :(
AVS->Avisource->convettorgb32() works also! (but the fullscreen resizing looks jeky! "nn") :(
AVS->Directshowsource->Wavsource->Muxing->convettorgb32 works... (but with bad A/V desync. "to slow CPU") :(
AVS->Avisource->Resize->convettorgb32() works also! (but the fullscreen resizing from AviSynth is to slow) :(

So... Is there any chanche that this crash of ffdshow will be fixed ??? :confused:

PS: mf, after some more tests I think your Idear works better than I thought... THX :D :D :D

Bye

[kilg0r3]

Originally posted by Soulhunter
As mf wrote ddfshow crash's when I try to open the file..
Hm, 'ConverToRGB32()' works fine for me. What system are you on?

[mf]

Originally posted by kilg0r3
Hm, 'ConverToRGB32()' works fine for me. What system are you on?
It works in most cases, but there's certain problems with DivX3 encoded stuff that suddenly doesn't work anymore and weird stuff. Can't really explain it since the symptoms are so vague and don't seem to relate.

[Soulhunter]

@kilg0r3
"Hm, 'ConverToRGB32()' works fine for me. What system are you on?"

I used:
- WinME (Yes, I know...I know ! ;))
- ffdshow 23.05.03 (Now I'm sure :D)
- video was DivX5.05 (with n' without B-Frames)
- Avisynth is 2.5.2
- Newest DirectX and Detonator Drivers Installed


This was the error code:

MPLAYER2 verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 018f:bff8e1ad.
Register:
EAX=c002fa54 CS=018f EIP=bff8e1ad EFLGS=00210212
EBX=0177ffbc SS=0197 ESP=0173feec EBP=01740188
ECX=00000000 DS=0197 ESI=00000000 FS=2acf
EDX=bff6682d ES=0197 EDI=bff69050 GS=0000
Bytes bei CS:EIP:
53 8b 15 f4 bc fb bf 56 89 4d e4 57 89 4d dc 89

Bye

[kilg0r3]

You could try if converttorgb24 or converttorgb32 followed by converttoyuy2 changes anything. Else, I don't have any ideas left.

[Soulhunter]

@kilg0r3
- Now I tesdted it also with XviD and WM9... "ConverToRGB32()" does also not work :confused:
ConverToRGB32 followed by converttoyuy2 runs... But colors are not right (Actors blue/green faces) :D :confused:
converttoRGB24 plays only the sound with a black screen...! :( :confused:

I also posted to the "ffdshow development" thread... Maybe someone there has suggestions.


@All
[edit] Is deleted because unless yet... :D

Bye

[Soulhunter]

@mf
Sorry mf,
I was wrong... You were right ! :D
It's def. the RGB32 process that terminates this red-blocks... I find this out the last days.
I did a compression of a GTA3-Clip with LEAD-MCMP/MJPEG and PIC-Video-MJPEG codec, and this is what happens:

-LEAD MCMP/MJPEG with 4:1:1 comp. causes even bigger chroma bug's... (Red-blocks are even bigger than with 4:2:0)

-PIC Video MJPEG with 4:1:1 comp. looks same as 4:2:0... (same red-pixilisation) But I dont know why its better than the LEAD-MCMP/MJPEG encode... No matter!

Converting the original GTA3-clip to RGB32 removed the red-blocks... You where right mf!

So, the Idear of an 4:1:1 way, is out of my mind... forever.

I will use your "ConverttoRGB32" way ...when it works ...hopefully in the future ...some time ! :D


@kilg0r3
Some more questions:
You say 'ConverToRGB32()' works fine for you...
What system are YOU on ? Maybe WinXP...???
And maybe could you tell me how much is the slow-down when you use ConverToRGB32...?
CPU load with n' without ConverToRGB32() would be nice to know...!
Just for interest while waiting for response in the ffdshow-development thread...! ;)

Bye

[kilg0r3]

yep I am on xp
and the slowdown is about 15% IIRC

[Soulhunter]

@kilg0r3
>
XP...
<
I thought so :D (Maybe its time for me to upgrade the OS)

>
-Slowdown is about 15%...
<
Sounds ok... But would a integrated function (without going trough AviSynth) be faster ???

[soujir0u]

I tried the RGB32 trick, but my system slowed down to a crawl... It's using 100% CPU on my Athlon 1GHZ!

[CruNcher]

@ all you dont need to use that trick just set in MPC the renderer to VMR 9 Renderles and no problems anymore happy watching :)

[Soulhunter]

Seems not to work with ZoomPlayer...
I have MPC still not installed, but I'll do n' check it ! ;)
THX CruNcher !!! :)

Bye

[Soulhunter]

Ok, downloaded MPC and tryed VMR9 renderles,
but it seems not to work for me... !
The "pixelisation" in the red arears is still visible,
with ffdshow its smoothed out :) !

[PS: Still waiting till it works in fullscreen mode... ;)]
[PS: Or is this VMR9 renderer only in XP working in the right way...?]

Bye

[CruNcher]

@Soulhunter

i think it has todo with more factors like graphic card driver and directx version so i will show you what i use :)

Directx: 9.0b (4.09.0000.0902)
Nvidia: Detonator 45.24
OS: XP

[Soulhunter]

@CruNcher

Ive the same stuff... (DX9b and Detonator 45.xx)

But my OS is WinME so I thought its possible that this only works with WinXP... !?!

When I get a friend's PC with XP in my hands next time, I'll test it...

Bye

[Markust]

i have the same problems with red and orange colors...
Movies like The Shining or 2001: A Space Oddysey are a truble for me.
Stanley Kubrick is a Big fan of the RED colour :P
In 1 CD there´s no way make it look good. I wish have time todo test with some scenes (like "the Bathroom" in the shining).
Any way, i will try some advices from this thread...

Best Regards.

[Soulhunter]

All you wanna know something real interesting... ???

This red-chroma-bug is solved "for me" !!!

Today Ive upgraded my old Nvidia-GF card, to an ATIRadeon one...

And now, all this small blocks in high intense red are gone !!!

Damn !!! Now I can imagine why some PPL dont agreed what I mean when I talked about this bug...
Cause I think only Nvidia users where able to see them... :D :D :D

My comment: F#C$ Nvidia ! Hail to Radeon !!!

PS:
Are the PPL with both cards out there to check this ???
Would be interesting to know if its really a Nvidia related bug !

Bye

[crOOk]

I'm using a Radeon9700Pro with the newest Catalyst driver, Win XP, newest AVS2.5 version, newest ffdshow build and am experiencing the same red pixeliation problem...
Converttorgb32() doesn't work for me in ffdshow's avisynth dialogue, but I'm not worried about it. I just hope the problem will be solved one day...
Just wanted to tell you all, that the problem is not related to NVidia cards (which I wouldn't recommend to buy anyway...)

[Soulhunter]

Not NVidia related ??? :confused:

The graphic-card was all Ive changed... (and drivers of course ! ;))

Converttorgb32() doesn't work for you ?

Does it crash the player ??? (C++ error ?)

When yes, try one version before...

Hmm... Thought the Radeon cards use some sort of other output-processing, that would solve this problem...
So, what is it then... ??? Maybe because its a VIVO ??? :confused:

No matter, I'm happy now !

Bye

[Prettz]

My Geforce3 classic produces some color smeering when playing videos in full screen (you have to have it enlarged to full screen to be able to notice it, but once in full screen it's extremely noticeable and ugly). This happens in all media players EXCEPT bsplayer, which produces no color smeering at all, leading me to believe that the problem is the drivers (but I have a Hercules 3D Prophet III, which is the only Geforce3 card that uses drivers from the card manufacturer and not Nvidia's reference drivers).

[drebel]

Nvidia graphic cards, at least the old Geforce2 serie, had problems with intense colors (red, violet...).The problem was that the tv-out chip (especially the chrontel one) had a difficulty keeping the right voltage all the time , thing which made a lot of people hard mod their cards to avoid the ennoying effect.Also , TV tool seems to help a lot ,by fine tunning the "color carrier" tab.One can find helpful info at their site
It's well known that ATI keeps filtering the video output to avoid these nasty situations and I think better EMI protection (especially some silver pcb models ...).But some might find its image kinda blurry.It's intirely up to us to decide.All I can say is that the "Nvidia+TVtool" combo may easily compare the "Catalyst+ a radeon tweaker " one

[crOOk]

@Soulhunter
Converttorgb32() doesn't work as well as any other avs command in ffdshow's avs dialogue (using mplayerc). The output just turns all green, well not all green, actually there's lots of horizontal green lines. I've got to admit: I haven't tried much yet, haven't even changed the player... and really, I'm not worried about it since I know everything's gonna be back to normal as soon as I manage to convert the output to rgb32.
But thanks for your advice, maybe I'll try some older versions of ffdshow.

[Soulhunter]

Posted by Prettz
My Geforce3 classic produces some color smearing when playing videos in full screen (you have to have it enlarged to full screen to be able to notice it, but once in full screen it's extremely noticeable and ugly). This happens in all media players EXCEPT bsplayer, which produces no color smearing at all, leading me to believe that the problem is the drivers (but I have a Hercules 3D Prophet III, which is the only Geforce3 card that uses drivers from the card manufacturer and not Nvidia's reference drivers).
This small 2x2 pixel blocks that can be seen in high-intense red chroma, are also visible when the player is in window mode... ;)

Maybe this "smearing" is a other problem... :confused:

It was discovered here, that this blocks aper, because the YV12 colorspace, and the wrong chroma-upsampling !

Upsampling the colorspace to RGB32 corrected this bad looking red blocks... :)

So I thought the Radeon cards/drivers using some sort of internal color upsamling, while the NVidia is keeping it... :confused:



Posted by drebel
NVidia graphic cards, at least the old Geforce2 serie, had problems with intense colors (red, violet...).The problem was that the tv-out chip (especially the chrontel one) had a difficulty keeping the right voltage all the time , thing which made a lot of people hard mod their cards to avoid the ennoying effect.Also , TV tool seems to help a lot ,by fine tunning the "color carrier" tab.One can find helpful info at their site
It's well known that ATI keeps filtering the video output to avoid these nasty situations and I think better EMI protection (especially some silver pcb models ...).But some might find its image kinda blurry.It's intirely up to us to decide.All I can say is that the "Nvidia+TVtool" combo may easily compare the "Catalyst+ a radeon tweaker " one
Not sure about this...
Because converting the bad looking frames into RGB32 removed this red-blocks ! So when its a problem with the GF2 tv-out voltage thing, this would also apear in the converted frames... But they looked OK !
Also changing stuff into color-tab does nothing to this problem...
Be sure, thanks to ALL THE NICE PPL here, now I know that it is just a problem with the wrong color-upsampling... ;)

Bye

[Soulhunter]

Hi again,

I found this (http://www.xlr8yourmac.com/Graphics/Radeon7500_vs_geforce4mx/index2.html) info about Radeon7500...


Heres a quote from the link:
In terms of hardware acceleration support, it's the same as we had under OS9 for the Radeon product. We take over the chain once the macroblocks have been parsed and use the hardware to perform the inverse discrete cosine transform (iDCT), motion compensation, subpicture overlay, YUV to RGB conversion and scaling to the screen.
Ok ! Its about the Radeon7500's hardware acceleration for DVD playback...

But this "YUV to RGB conversation" stuff, seems to be exactly what I thought ! ;)

Bye

[nuked]

OK I've been curious for awhile. Those yuv equations shown a ways back have offset values... like 128 for U and V as I recall. If not accounted for this could really mess up quantizing preciscion as I understand it and diferently for diferent colors and shades. I could explain my idea in detail but I won't yet at least. For now I'll just ask.... is this accounted for somehow in the compression schemes?

[cult]

All I can say is that the "Nvidia+TVtool" combo may easily compare the "Catalyst+ a radeon tweaker " one
Not true.For example my ati's tvout is 1024@60hz while a geforce2 800x600

[Didée]

All I can say is that the "Nvidia+TVtool" combo may easily compare the "Catalyst+ a radeon tweaker " oneNot true.For example my ati's tvout is 1024@60hz while a geforce2 800x600
... and still unbeaten by anything is Matrox' 720x576 true-overscan TV-out. :)
At least in PAL land, I can't speak for NTSC.

- Didée

[Soulhunter]

Have read the feature-list of my Radeon... :D
VIDEO FEATURES:

- FULLSTREAM™ hardware accelerated de-blocking of Internet video streams

- Hardware accelerated de-blocking of RealVideo video streams

- Integrated MPEG-2 decode including iDCT and motion compensation

- All format DTV/HDTV decode

- Top quality DVD with lowest CPU usage

- YUV to RGB color space conversion

- Back-end scaler delivers top quality playback

- 4-tap horizontal and vertical filtering

- Upscaling and downscaling

- Filtered display of images up to 1920 pixels wide

- Unique adaptive per-pixel deinterlacing feature combines the best elements of the "bob" and "add-field" (weave) techniques

- Hardware mirroring for flipping video images in video conferencing systems

- Supports 8-bit alpha blending and video keying for effective overlay of video and graphics
Don't known that it does all thus stuff... !!! :confused:

"Hardware accelerated de-blocking of RealVideo video streams" Uhm... What ???

Does it mean, it should play my RV9 encodes faster now... ? :D :D :D

Bye

[drebel]

Not true.For example my ati's tvout is 1024@60hz while a geforce2 800x600

Sorry for the misunderstanding, guys.I wasn't talking about my Geforce (2MX) .Newer models have different tv-out chips than my crappy chrontel one,and of course ,they support higher resolutions ,just like the ATIs do

Fullstream technology doesn'y necesserely add quality to mpeg2-4 videos (by deblocking).But that 's according to a review about 3 months old...

[Soulhunter]

@drebel
But that 's according to a review about 3 months old...
Ive forgotten to ask... :D

Could you please give me a link to this review... ???

Bye

[drebel]

Oooups ! It's 3 months and a year old...
It's a link at Tom's about fullstream.But I doupht there's any advance in that area since then

http://www17.tomshardware.com/graphic/20020819/radeon9700-27.html

[mf]

Btw, I have to note that contrary to my GF2Pro, ATI's Radeon 9800 Pro has chroma upsampling on VMR9 (not overlay) YV12 rendering. Very nice, now I won't need ConvertToRGB32() anymore.

[Sharktooth]

Uhm. I own a GF3 and i fixed the problem using software overlay instead.
It seems to me there is something in hardware thats causing all the mess.

PS. I experience the same problem with DVDs (i use powerdvd) when enabling HW acceleration.

[Soulhunter]

Thanks for the link... :D

Would be cool to have a list of cards that show this problem, or not... !

If anybody find such a list, or more info about this stuff... Post it here ! ;)

Bye

[drebel]

Btw, I have to note that contrary to my GF2Pro, ATI's Radeon 9800 Pro has chroma upsampling on VMR9 (not overlay) YV12 rendering. Very nice, now I won't need ConvertToRGB32() anymore.

You mean hardware support on VMR9 ? I'm asking this because with my Gforce2MX, I never had to use that line to have VMR9 output directly after the codec's (XviD in YV12 to be exact) dshow decoder filter

[mf]

Originally posted by drebel
You mean hardware support on VMR9 ? I'm asking this because with my Gforce2MX, I never had to use that line to have VMR9 output directly after the codec's (XviD in YV12 to be exact) dshow decoder filter
I don't understand what you mean. Please clarify.

[drebel]

All I meant was this:

why did you need to ConvertToRGB32() with your old card in the first place? Did your Gforce2pro have a rendering problem with YV12 movies and VMR9?
I know that older cards like mine are using software mode to perform VMR9 output , unlike your new ATI which uses hardware support on Directx9 (and VMR)

I never had to use that line to have VMR9 output directly after the codec's (XviD in YV12 to be exact) dshow decoder filter

That was an attempt to describe the filter chain in graphedit.

Avi->Xvid decoder->VMR9 , without unnecessary colorspace conversions in between

[Soulhunter]

Compare between Avisynth's and Radeons upsampling...


Original
http://img31.photobucket.com/albums/v94/Soulhunter-No.1/Original2.jpg


Bad upsampling
http://img31.photobucket.com/albums/v94/Soulhunter-No.1/Wrong_Upsample.jpg


AviSynth's upsampling
http://img31.photobucket.com/albums/v94/Soulhunter-No.1/AviSynth_Upsample.jpg


Radeon's upsampling (VMR9)
http://img31.photobucket.com/albums/v94/Soulhunter-No.1/Radeon_Upsample.jpg


Bye