Chroma Problem - Color Stepping

[kilg0r3]

Hi all,

I need your help to proof that my eyes are not cheating me. If they are not, it seems that Avisynth 2.5 (and 2.0x?) has a problem with the chroma representation.

The best name for it might be 'color stepping'. It is most visible on sharp edges of pure colors or large planes of pure colors; especially with red and blue. It is easier to notice in slower motion situations, which is why the below provided vobs might not be an ideal choice. But there has been nothing else at hand. If anybody is interested, I can provide an Xvid compressed scene of 2001 which is in pure red and, due to the issue mentioned here, looks really ugly.

The Problem arises, when I load a vob into virtualdub with avisynth using either Mpeg2dec3 or MPEGDecoder. Some sample scripts are provided below.
The problem does not arise when I use DVD2AVI, or when I open the vob directly in VdubMod. SO, it might well be a problem of Avisynth
Furthermore this _not_ only a preview problem for it is visible in the encoded movie too no matter what codec i use. i tested this with Xvid, Divx and RV9.

I hope I have been able to avoid any stupid faults on my side, and, that the information provided below is useful for You to get on the right track. Still, I apologize in advance, in case I have overlooked anything, and, of course i apologize to neuron2 for having bugged him with this already without providing the necessary info.

Thanks for reading.


---------------------------
BitrateViewer Information
---------------------------

SPIDERMAN | PLANET OF THE APES
----------- | --------------------
Num. of picture read: 174370 | Num. of picture read: 174431
Stream type: MPEG-2 MP@ML VBR | Stream type: MPEG-2 MP@ML VBR
Resolution: 720*576 | Resolution: 720*576
Aspect ratio: 16:9 Generic | Aspect ratio: 16:9 Generic
Framerate: 25.00 | Framerate: 25.00
Nom. bitrate: 9800000 Bit/Sec | Nom. bitrate: 6000000 Bit/Sec
VBV buffer size: 112 | VBV buffer size: 112
Constrained param. flag: No | Constrained param. flag: No
Chroma format: 4:2:0 | Chroma format: 4:2:0
DCT precision: 10 | DCT precision: 10
Pic. structure: Frame | Pic. structure: Frame
Field topfirst: Yes | Field topfirst: Yes
DCT type: Field | DCT type: Frame
Quantscale: Nonlinear | Quantscale: Nonlinear
Scan type: Alternate | Scan type: ZigZag
Frame type: Interlaced | Frame type: Progressive



You can no longer download the material because i need the space sorry.
---------------------------
AVS SCRIPTS FOR 'SPIDERMAN'
---------------------------
-1-

LoadPlugin("c:\Programme\Avs\Mpeg2Dec3.dll")
Mpeg2Source("Z:\Rip\Rip1\Source.d2v")
crop(32,32,656,512)
BicubicResize(656,352,0,0.5)
---------------------------
-2-

LoadPlugin("C:\Programme\AVS\MPEGDecoder.dll")
MPEGSource("z:\rip\rip1\1.vob", 174367, "0xE0")
Crop(32,32,656,512)
BicubicResize(656,352,0,0.6)


--------------------------------
AVS SCRIPT FOR 'PLANET OF APES'
--------------------------------
LoadPlugin("c:\Programme\Avs\Mpeg2Dec3.dll")
Mpeg2Source("Z:\Rip\Rip1\Source.d2v")
crop(8,80,704,416)
BilinearResize(704,288)

[morsa]

Well, I've seen this problem before.
The same stepping appears in Vdub with DV source (YU12).
One way to minimize this is to resize the color components to half the vertical and horizontal resolution of the original, and resize with small increments to double the original resolution, then apply a blur and downsize to the original resolution.
Hope this works for you. (I know it is terribly slow, sorry)

[sh0dan]

The stepping occurs because of colorspace conversions.

When you are previewing an YV12 source in vdub it is converted to rgb by the codec used to decompress it (DivX or XviD). This conversion may not interpolate chroma properly.

So what you are seeing it not something that will be present in your final encoding, when the material is passed directly to the codec using fast recompress.

Encoding YV12 -> YV12 (vdubmod/Xvid,DivX). Chroma isn't touched. Problem will not arise.
Encoding YV12 -> YUY2 (CCE, huffyuv). Convert internally, using converttoyuy2(). Be sure to use the latest CVS binary.
If your source is interlaced, when it is converted, use YV12toYUY2(interlaced=true) - for now the internal routines has bugs which I'm looking at ATM. ConvertToYUY2() provides better quality than YV12toYUY2(interlaced=false) on chroma in my tests.

Encoding YV12 -> RGB (TMPGEnc, Vdub with full processing). Use internal conversion. First converting to yuy2 first might provide even better quality.

So in general, ALWAYS convert internally to the destination format you are using. It's often faster, and provides better quality.

Great work on the report!

[neuron2]

That's what I told him in PM before he started this thread, but he's not buying it. Let's see the response.

[kilg0r3]

come on neuron2, be nice!

i see the problem also when playing encoded clips. that's why i didn't contend myself with your response.

btw, i only accidentally posted the thread in the developer forum. sorry for that.

have a nice day everybody.

kilg0r3
slightly annoyed because taken to be dumb

[neuron2]

Sorry, I was only stating the facts as I saw them.

When I did everything you asked with the VOB you sent me I could never see the problem in an encoded final product.

I think I moved this silently to the Development forum because it is an advanced subject that implies possible core problems. sh0dan likes to leave redirects while I don't. :)

[kilg0r3]

I will continue testing which will take some time though, because there seem to be a lot of varibles, and, since it might be that vdm makes errors when converting the chroma, I do not even have reliable testing basis. Are there any resons to believe that vdm is unreliable in this task?

Is there another, more reliable, app with which I could grab the frames of video streams in an equivalent easy way. It should however also show frame numbers and support frame-by-frame seeking.

If I load an xvid avi into vdm via an avs script containing a ConvertToRGB() statement, I take care of a possible chroma conversion bug in vdm. Right?

It might be worth moving the thread back to the Usage forum. Since more users read that forum, there might be more feedback on if other people have the same probs with the provided material.

Any further suggestions on how I should go about carrying out this investigation?

[Belgabor]

Originally posted by kilg0r3
Is there another, more reliable, app with which I could grab the frames of video streams in an equivalent easy way. It should however also show frame numbers and support frame-by-frame seeking.


Doesnt the new avisynth core have an ImageWrite (dunno the exact name) function?

[Wilbert]

Yes, usage:

clip.ImageWriter("c:\","BMP") # outputs to RGB24

clip is RGB24/32.

[scmccarthy]

@kilg0r3

I your last post, you said some things that indicate to me you did not heed sh0dan's post. sh0dan said:So what you are seeing it not something that will be present in your final encoding, when the material is passed directly to the codec using fast recompress. Then you said:and, since it might be that vdm makes errors when converting the chroma, I do not even have reliable testing basis. Are there any resons to believe that vdm is unreliable in this task? I can answer that two ways:

vdm is reliable as long as you use fast recompress.

Or, vdm is unreliable unless you use fast recompress.

It's the same thing either way.

And sh0dan said:Encoding YV12 -> YV12 (vdubmod/Xvid,DivX). Chroma isn't touched. Problem will not arise. Then you said:If I load an xvid avi into vdm via an avs script containing a ConvertToRGB() statement, I take care of a possible chroma conversion bug in vdm. Right? Wrong. Using fast recompress effectively bypasses vdm and you do not need to worry where exactly the bug is coming from in the preview window.

There are problems with the codecs vdm uses in the preview that won't affect the encode when you use fast recompress. Although I agree it will be nice when we finally shake out all the YV12 related bugs everywhere. Meanwhile you can bypass YV12 in avs2.5 by using dividee's mpeg2dec.dll. Don't forget that option.

It is clear I am pathetically long winded when you consider that this post only asks you one simple question: You are using fast recompress, right?

Stephen

[kilg0r3]

Ok, I think I will have to be bit clearer in my statements. Just one note in advance. I use vdm for two purposes (a) encoding, (b) previewing and frame grabbing. ok, let's start.

1. When i encode a movie, I always use fast recompress.

2. The issue I am talking about first occurred to me when I encoded "2001 -A space Odyssey", and, I first realized it when I watched the compressed movie in some media player. Since then I encoded three more movies "Bad Company", "Spiderman", "Planet of Apes". The problem has been present in all the encodes of the three movies. Despite my using fast repack, i.e. for me, the problem is present in the encoded material

3. When i started to investigate the problem i realized that a vob loaded into vdm via avisynth showed the same artifacts in the preview window of vdm as the encodes mentioned above. However, when I load the vob directly into vdm and when i load them into dvd2avi, the artefacts do _not_ appear in the preview. So i concluded that this might be an issue within avisynth 2.5/2.0x or mpeg2dec(3).

4. In order to investigate the problem i need to make frame grabs and compare them. I did that using the vdm's preview function. Consequentially, I rely on the fact or non-fact, that vdm correctly converts YV12 input to RGB because it uses RGB for its preview

shodan said:When you are previewing an YV12 source in vdub it is converted to rgb by the codec used to decompress it (DivX or XviD). This conversion may not interpolate chroma properly.

This statement suggests that the screen shots I make with vdm might contain errors introduced by vdm's YV12 -> RGB conversion. If this were the case they are obviously useless for diagnostic purposes.

For this reason, I proposed a work around which would feed vdm with RGB input, so that vdm would not have to convert the inout data for the preview.


BTW, in my limited contiued testing, one further oddness occurred to me. It seems that the problem is not visible when i encode the credits clip of Spiderman to xvid, no matter if the source vob has been loaded through an avs-script or directly. For testing, I played it in vdm and some media players.

[sh0dan]

You very detailed investigation is very much appreciated!

It sounds like an issue that should be adressed. I am however not sure, if DVD2AVI delivers YUY2 or YV12 to the codec. If the latter is the case then your test results are 100% valid - if not - chroma has been interpolated once by the DVD2AVI YV12 -> YUY2 conversion. Therefore it can only be compared to an avisynth script that contains converttoyuy2() at the end.

I'll see if I can get some time to look at the vobs you provided!

[trbarry]

I'm pretty sure that DVD2AVI display's its preview in the mode (YUY2/RGB) that you select as long as it is sopported by your video card. And also that it will pass that mode to the compression codec if you encode directly to Xvid from DVD2AVI.

It might be an interesting experiment to try that and encode a short section straight from DVD2AVI to Xvid or Huffy and see if the results were different when played.

- Tom

[kilg0r3]

Ok, since i started this thread i feel obliged to 'close' it too.

Here is what I have done so far. I have encoded the clips to Xvid, Divx, Huffyuv(yuy2), Huffyuv(rgb), RGB(uncompressed). As decoder I used VDM, Mpeg2Dec, and, occasionally Nic's MPEGDecoder. The source has also been converted to Yuy2 format and RGB. For encoding I have used VDM (fast repack and full processing mode), and, DVD2AVI.

I also created a clip from an image consisting of a solid blue background with a red triangle in the center. This one has also been encoded in the different formats.

As far as i understand the results, so far, - I have not had the time to systematically analyse all encodes nor to create the relevant frame grabs - the stepping visible in the preview in vdub, is _not related to the stepping in the final encode. For, no matter which input source/format I have used for the Xvid and Divx encodes, the stepping has been present in all compressed versions of all clips. The only ecception here is the Spiderman credits clip. It might be, however, that I confused one or two frame grabs here. I will double check that later.

The stepping in the encodes is probabely due to the low chroma resolution of YV12 format and a not too smart upsampling. I wonder if this could be corrected by a different way of interpolation. Yet, this is going off topic because it is an issue of the mpeg4 en/decoder.

Still, I dont understand why neither DVD2AVI nor VDM when loading the vob straight do not show the stepping. If the stepping is due to low chroma resolution of YV12 it should be visible also when playing the vob no matter which player I use.

Hm, I think I'll shut up now.

[sh0dan]

Don't give up - I think you are on to something here.

(And testing it just helped me discover that converttoyuy2() is broken on non-mod16 width images :( - easily fixed though).

Edit: It DOES however seem like there is an error somewhere. Chroma is definately placed wrong. It does however mostly seem like a decoding error. The strange thing however is, that both MPEGDecoder and MPEG2DEC seem to share this.

Edit 2: Could it be resizing! When a VOB is loaded into VDubMod it by default resized to 4:3 aspect. (720x432) This softens the chroma.

My test:
- Load VOB into VdubMod
- Select free aspect
- set size to full.
- Save as uncompressed AVI. (full processing)

Compare with this script:
MPEG2Source("C:\temp\stepping\ape.d2v")
crop(128+8,180,256,80)
converttoyuy2(interlaced=false).converttorgb24()
stackvertical(avisource("C:\temp\stepping\testout.avi").crop(128+8,180,256,80))

The amount of stepping is approx. the same.

HuffYUV file (http://cultact-server.novi.dk/kpo/avisynth/step_result.avi) of the endresult (RGB24 - not converted)

[kilg0r3]

Originally posted by sh0dan
[B]Don't give up - I think you are on to something here.


Unfortunately I am supposed to write an examination paper of 60 pages about the semantics of German and English prepositions. So i won't have much time in the following weeks.

Another prob is, that I no longer know what to look for and try out. I got a little overwhelmed by this whole enterprise. The number of possible sources of error(???) seems to be increasing. Unfortunately I am not even a very expereinced avisynth user. I don't even know how to properly deinterlace a film :(. So that it seems more probable for me, that i might introduce errors by wrong usage than to discover the technical ones.

I hate to do this because I started this whole discussion but I feel I have to hand the issue over to more experienced people than me.

Edit 2: Could it be resizing! [...]

All of my sources were resized either by vdm or avisynth. This never prevented the emergence of the stepping ind the avs-previews.

But, you are right the stepping is the 'same' in both clips.

[sh0dan]

Then it's probably more a matter of the colorspace in which the resize is done. DVD2AVI performs the resize in YUY2, IIRC - whereas AviSynth maintains YV12.

[kilg0r3]

Hi Everybody,

I have attached some of the screen shots i took the other day. I might be bringing owls to Athens here :cool:. anyway the images suggest that the stepping, at least in the encodes is a property of the YV12 and YUY2 color spaces.

The Sources[b]
two clips generated by the following scripts:

[b]RGB
LoadPlugin("C:\Programme\AvS\ImageSequence.dll")
ImageSequence("dreieck.bmp",1,10,1)

YV12
LoadPlugin("C:\Programme\AvS\ImageSequence.dll")
ImageSequence("dreieck.bmp",1,10,1)
ConvertToYV12(interlaced=false)

Destination
RGB(uncompressed)
Huffy(RGB),(Yuy2)
Xvid(Quant1)

Tonight i will do a 'crazy' :D thing. I will watch the vobs in PowerDVD. What if i find the same stepping there?

Whoops! I am not allowed to post attachments? :confused: Erm .. Ok. Here (http://www.mynetcologne.de/~nc-allgeife8/img/triangle.rar) is the link

[trbarry]

I've posted this link before, but anyone following this might like to review the this article on The Croma Upsampling Problem (http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html).

But I still don't know what's happening here. Something is.

- Tom

[sh0dan]

I think the conclusion is "there is no better quality in YV12". Chroma is subsampled and in extreme cases like this it shows. The only thing that will help is smoothing chroma - even though what also has sideeffects.

[trbarry]

Somewhere in my Video Essentials disc there is a test pattern that shows when you have chroma delays of various sorts. I'll have to go dig that out again if I can find it.

I'm still not comfortable with all this but haven't had the time to really dig.

- Tom

[kilg0r3]

Originally posted by sh0dan
I think the conclusion is "there is no better quality in YV12". Chroma is subsampled and in extreme cases like this it shows. The only thing that will help is smoothing chroma - even though what also has sideeffects.

That is also MHO, and, that also means that developers of _decoders_ will have to take that into account. For me, as Xvid user, the whole thing has turned from an Avisynth/Mpeg2Dec Issue into an Xvid issue. I would be glad however, if somebody with a little more authority than would be so kind as to bring it up in the relevant places. I faintly remeber having been bashed/ignored for talking about chroma stepping in the Xvid forum.

[sh0dan]

Originally posted by trbarry
Somewhere in my Video Essentials disc there is a test pattern that shows when you have chroma delays of various sorts. I'll have to go dig that out again if I can find it.


If you could find this, it would be really helpfull.

For now my testmaterial has mostly been artificially created sequences. A small vob-sample with INTERLACED material would also be nice. The vobs above are very good for testing accuracy of progressive conversions, but some chroma intensive _interlaced_ material would be nice.

[trbarry]

Sh0dan -

I'll go look for the VE section that has that. I remember it's in the Video Essentials sample patterns somewhere but doesn't appear in the menum.

I played with it in DScaler once but didn't really know how to interpret it anyway. But maybe it is time to find out.

And I agree that YV12 is a sparsely sampled color space but I also still believe that it is the confusion of the color conversion and not the lack of color information that causes most of the problems.

- Tom

[DvdKhl]

So let me get this staight.
The fault of this color stepping is the Yv12 color space

YUY2: The picture is stored as a luma value Y and two color
values U, V.
For two horizontal pixels there is only one chroma value and two
luma values (two Y's, one U, one V).
Therefore the width has to be a multiple of two.

YV12: The same as YUY2 but there is only one chroma value for 4
pixels (a 2x2 square).
Both image dimensions have to be a multiple of two,
if the video is interlaced the height has to be a multiple
of four because the 2x2 square is taken from a field, not from a
frame.

so if you put "ConvertToYuY2()" before resizing in the script all
problems should be gone!
But as usual nothing works at the first time.
I have still the same problems with the colorstepping.

My script:

LoadPlugin("C:\Programme\AviSynth\plugins\MPEG2Dec3.dll")
LoadPlugin("C:\Programme\AviSynth\plugins\Decomb.dll")
LoadPlugin("C:\Programme\AviSynth\plugins\FluxSmooth-2.5.dll")

LoadPlugin("C:\Programme\AviSynth\plugins\Convolution3DYV12.dll")


Mpeg2Source("c:\*.d2v",CPU=2,iPP=true,iDCT=5)

Telecide(guide=2)

Crop(10,8,704,560)

Convolution3D (0,3,4,3,4,2.8,0)
FluxSmooth(6,6)

ConvertToYUY2()

LanczosResize(448,248)

After that I tried ConvertToRGB32()
All colorsteppings gone... but it's SLOW and
can I use fast recompress in VDub when I use DivX?
OK I could but has it any disadvantages beside that it is slow?

so why do I have to convert to RGB to get rid of this colorstepping?
and not YUY2?

[kilg0r3]

@ DvdKhl
just a side note. I don't know about divx, but I am relatively sure that there is a problem when encoding an RGB source to xvid because there is a bug in the color conversion rutines of xvid. So, in this case, you should reconvert to YV12 to YUY2 in avisynth. --- cheers.

[DvdKhl]

sorry about the off-topic with divx
I forgot what forum it was
since I found the topic by search
please don't bother

[scmccarthy]

So let me get this staight.
The fault of this color stepping is the Yv12 color space Nope, trbarry just said the problem is with the conversion, not the color space.so if you put "ConvertToYuY2()" before resizing in the script all
problems should be gone! No, this is where the trouble starts.

The way to avoid the trouble is to convert to progressive frames before resizing. Well, either that or resize the fields separately and then reinterleave. Which one you choose depends on whether you want to preserve the interleaving or not.

Stephen

[morsa]

I´ve seen the chroma problem too many times.I agree with Tom that it is a decoding problem.Up today the only solution I've found is to deliberately destroy the chroma layers applying chroma softening and interpolation (supersampling included)to get rid of those ugly stepped borders.I know it is terribly slow but I can't get any better solution.

[scmccarthy]

@morsa

For now the solution is to determine if your source is progressive, interlaced, or fieldbased and manually act accordingly depending on whether you destination file will be interlaced or progressive.

Altogether, I just mentioned six possibilities, so I cannot be more specific than that.

Stephen

[kilg0r3]

Well, I am not so sure if all this would work if the destination codec still uses YV12 like Xvid. After all, as i said above, xvid shows the stepping even in a clip that was created with ImageSequence no matter which colorspace Avisynth outputs.

@ smccarthy, morsa
Which destination codecs do You use?

[scmccarthy]

Well, of course, because xvid itself may use the wrong conversion when decoding.

You still have to be careful how you convert to YUY2 or RGB. The point is that you have to convert differently for an interlaced source than a progressive one.

I always use force film with DVD2AVI. I am guessing the problem only occurs with interlaced sources.

Stephen

[sh0dan]

Xvid color conversions:

RGB -> YV12: Chroma is an equally weighed average of all four RGB pixels. This is slightly wrong, as it implies MPEG1 (center placed chroma) scheme instead of MPEG 2 (left pixel placed chroma). So in every RGB -> YV12 conversion chroma is moved slightly to the right.
(Note: this is also used in direct RGB -> YV12 conversions in AviSynth.)
It is however by far the fastest way to do the conversion.

YUY2 -> YV12: Chroma is averaged between upper and lower line - this is correct, and is also done by the rewritten AviSynth routines.
The XviD routines does have a "green tint" tendency, because of improper rounding. I have written to the XviD mailing list, but got no response :(
This is of course not the case with the AviSynth conversion.

[kilg0r3]

Originally posted by scmccarthy
You still have to be careful how you convert to YUY2 or RGB. The point is that you have to convert differently for an interlaced source than a progressive one.
Sorry, if I am a bit slow but could you please post a some sample scripts for two or three situations

I always use force film with DVD2AVI. I am guessing the problem only occurs with interlaced sources.

According to the Bitrateviewer statistics, I would say, that at least one of the clips - Planet of Apes PAL RC2 was entirely progressive. I am not so sure regardingthe Spiderman clip.

@ sh0dan, neuron2
how do you determine if a vob is interlaced/progressive on the chroma/luma plane?

Thanks for your efforts everybody!

[neuron2]

Originally posted by kilg0r3
@ sh0dan, neuron2
how do you determine if a vob is interlaced/progressive on the chroma/luma plane? It's difficult. The only way I know is to look for presence or absence of theoretically expected artifacts from defined processing chains. To tell you more would require a minor thesis.

[^^-+I4004+-^^]

all this talk just to establish
YV12 is 4:2:0?
nice one!
the more you downsize the more it gets visible...
don't see your screenshots no more,but
let me guess;color red is sqaurish?
then,downsize the least you can,watch
from proper distance (don't watch it
on 2 or 4x zoom..)
someone mentioned supersampling of
chroma etc.
YV12 will still stay here even if
you (or me or him) have funny red from time
to time....
no big panic......

[trbarry]

how do you determine if a vob is interlaced/progressive on the chroma/luma plane?

I guess if you have problem material and you don't know if it is coded progressive/interlaced (or it's mixed) then you could always use MPEG2DEC2. There is a version around somewhere here that even works with Avisynth 2.5.

But MPEG2DEC2 will return YUY2 that has been converted on a frame by frame basis looking at the MPEG-2 flags and deciding which type of conversion to do.

- Tom

[morsa]

My source is interlaced DV PAL, so it is 4:2:0.
When I decode it shows big stepping artifacts.
My destination is Progressive uncompressed RGB.
When I take the two chroma layers, apply a soften filter, upsize, apply warpsharp and downsize to luma resolution the stepping is almost gone.

[scmccarthy]

According to the Bitrateviewer statistics, I would say, that at least one of the clips - Planet of Apes PAL RC2 was entirely progressive. I am not so sure regardingthe Spiderman clip. Let's make sure we are absolutely clear. Telecined is still interlaced or maybe field based, depending. Unless IVTC is applied, socalled progressive on DVD is still not progressive.RGB -> YV12: Chroma is an equally weighed average of all four RGB pixels. This is slightly wrong, as it implies MPEG1 (center placed chroma) scheme instead of MPEG 2 (left pixel placed chroma). So in every RGB -> YV12 conversion chroma is moved slightly to the right. Therefore, the best way to encode using xvid is to stay in the YV12 color space progressive. As long as you convert YV12 interlaced to progressive properly, all problems that we understand can be avoided. I hope that's not overstating it.

Stephen

[sh0dan]

I'll see if I can find the time to do an YV12 interlaced -> progressive resampling filter.

@morsa: Try doing YV12 -> YUY2 -> RGB conversion. There doesn't seem to be any chroma interpolating in the XviD YV12 -> RGB routines. YV12ToRGB24() may also be a valid option (though I haven't seen the sourcecode).

[scmccarthy]

@morsaMy destination is Progressive uncompressed RGB. I don't believe it. Destination is the file you store on your harddrive, CD, or DVD, not how you display it on your computer screen or TV.

Stephen

[kilg0r3]

Originally posted by scmccarthy
Let's make sure we are absolutely clear. Telecined is still interlaced or maybe field based, depending. Unless IVTC is applied, socalled progressive on DVD is still not progressive.


I have been using almost exclusively PAL (25fps) DVDs which are mostly progressive. I have never heard anything about anybody aplying IVTC or deinterlacing on these sources.

[morsa]

Believe me guys, I'm not stupid.Uncompressed RGB.I have a four disc raid.Maxtor 200 gb so, 800 GB.
And uncompressed video plays perfectly!
Finally I will record on Beta SP.Clear?
And please we aren't talking about what format is my destination.We talk about color stepping.

[scmccarthy]

@morsa

Sorry, so you really are storing uncompressed RGB on your hard drive.And please we aren't talking about what format is my destination. We talk about color stepping. I am assuming that color stepping, most noticeable on red and blue solids, is caused by converting interlaced frames in YV12 to YUY2 or RGB using the conversion method for progressive frames and field based material.

The reason I asked is that just not doing the conversion would solve the problem.

The best way around it is to separate the fields before doing the conversion. I think that is better than trying to switch the conversion method.

@kilg0r3

You are right that telecine is used for NTSC only. I keep on forgetting since that is all I use. All analog TVs take an interlaced signal only however, and both NTSC and PAL are interlaced. I mean that both standards are for analog TVs whether each frame is really interlaced or not. Hybrid DVDs probably only exist because DVD makers intend them to be shown on a TV only, at least I find it helpful to look at it that way.

Stephen

[DvdKhl]

ok something is wrong so wrong that I'm going to reinstall WinXP.

At first I thought it was the DVD that was giving the problems.
But then I thought when did the problem start?
(since I installed xvid don't know if this is the cause but after that I had the probs)
I remembered that I took pictures VDubMod without colorstepping,
I loaded them into a photoeditor... the colorstepping were there.
(but there shouldn't be some!)
Then I loaded the pic on another PC (without divx or xvid codec) into the same photo editor and they were gone.
So it could be possible that the encodes are correct
but the decoders to view the movies (not the mpeg2dec to decode the vob to aviod missunderstandings) are making the probs.

I hope I'm not to wrong with my statement :)

I'll let you know if the reinstall helped!

[trbarry]

but the decoders to view the movies (not the mpeg2dec to decode the vob to aviod

Maybe it's the "MSYUV.dll" problem. Try doing a search on that in the Xvid and developement forums.

- Tom