ConvertToYV12 weirdness.

[vkamicht]

Alright, still new to the color space business. I've got a rough idea how they all work now. My issue is with converting to YV12 to use MCBob. With some sources it works fine, with others it's being strange.

Here's the frame in question that is behaving oddly.

YUY2 (unedited, as captured) (http://img146.imageshack.us/img146/8871/frameyuy2py3.png)
YV12 (http://img101.imageshack.us/img101/7982/frameyv12fy4.png)
fields (http://img88.imageshack.us/img88/6571/fieldszw5.png)

And yes, I did it with (interlaced=true). The "broken" parts of the frame are obvious but i'm not sure why they are turning out this way.

Any ideas? Thanks

And one other question related to MCBob if someone happens to know the answer, any reason why the YV12 is necessary in the first place or if there is a way to use it without converting away from YUY2?

[Terranigma]

Alright, still new to the color space business. I've got a rough idea how they all work now. My issue is with converting to YV12 to use MCBob. With some sources it works fine, with others it's being strange.

Here's the frame in question that is behaving oddly.

YUY2 (unedited, as captured) (http://img146.imageshack.us/img146/8871/frameyuy2py3.png)
YV12 (http://img101.imageshack.us/img101/7982/frameyv12fy4.png)
fields (http://img88.imageshack.us/img88/6571/fieldszw5.png)

And yes, I did it with (interlaced=true). The "broken" parts of the frame are obvious but i'm not sure why they are turning out this way.

Any ideas? Thanks

And one other question related to MCBob if someone happens to know the answer, any reason why the YV12 is necessary in the first place or if there is a way to use it without converting away from YUY2?

It looks like somehow, mcbob separated the fields, and not wove them back together. Maybe you could upload part of the video, so I can see if I can dupe the result?

And to answer your question regarding YV12 (http://en.wikipedia.org/wiki/YV12)

[vkamicht]

It looks like somehow, mcbob separated the fields, and not wove them back together. Maybe you could upload part of the video, so I can see if I can dupe the result?

And to answer your question regarding YV12 (http://en.wikipedia.org/wiki/YV12)


This isn't with MCbob... that's simply converting to YV12 without deinterlacing. The frames are a regular interlaced frame.

The problem exists after deinterlacing, that's how I noticed it in the first place. But this is just showing that MCbob isn't the problem.

[Terranigma]

The fields are separated from one another. Tried weaving?

[vkamicht]

The fields are separated from one another. Tried weaving?

Wait, what?

The first image is just a regular interlaced frame (two fields) without editing or color conversion--just as it was captured.

The second image is the same frame, same fields, converted to YV12 with (interlaced=true). This one shows the errors.

The third is just the unedited, unconverted fields from the first image for reference.

[Terranigma]

Ahh, I got ya. You know, I could'nt really tell a difference 'til I examined them side by side. After the mcbob line, can you try changing the colorspace back to the original colorspace (converttoyuy2, if that's what it was), and see if the little subtlety's still there?

[vkamicht]

Ahh, I got ya. You know, I could'nt really tell a difference 'til I examined them side by side. After the mcbob line, can you try changing the colorspace back to the original colorspace (converttoyuy2, if that's what it was), and see if the little subtlety's still there?

Sorry about that. Well, like I said, this error occurs during the ConvertToYV12 process and not with MCbob. And converting back to YUY2 doesn't do much at all--still doesn't look as it should.

[Terranigma]

I was gonna suggesst using the colormatrix script which can be obtained Here (http://forum.doom9.org/showthread.php?t=82217), but I'm not sure if that'd help. Maybe foxyshadis might have an inkling on what to do.

[foxyshadis]

THe problem is you're looking at it in virtualdub, which does the equivalent of ConvertToRGB() on it. Notice the distinct lack of "interlaced=true" there. So really, all you have to do is convert it back to YUY2 or RGB in interlaced if you want to make vdub happy, then comment out that line and go on with the script when you're satisfied that it works.

(How'd you know I was reading the thread. >( )

[Terranigma]

(How'd you know I was reading the thread. >( )

I sensed your presence :p

[vkamicht]

THe problem is you're looking at it in virtualdub, which does the equivalent of ConvertToRGB() on it. Notice the distinct lack of "interlaced=true" there. So really, all you have to do is convert it back to YUY2 or RGB in interlaced if you want to make vdub happy, then comment out that line and go on with the script when you're satisfied that it works.

(How'd you know I was reading the thread. >( )

Hrm... well I'm encoding in xvid with Vdub so the "What I see is what I get" holds true. Just tested it without converting back to anything and the video had this problem too. This means I have to convert back to YUY2 or RGB in the script even before encoding... any way I can get around this?

[Terranigma]

This means I have to convert back to YUY2 or RGB in the script even before encoding... any way I can get around this?

Change vdub from full processing, to Fast Recompress, and encode from there.
Or alternatively in Full Processing mode, Choose "Color Depth...", and choose the appropriate colorspace for the output format.

edit: Not sure the output color thingy will affect your encode in any way.
It'd be safer to choose fast recompress and encode.

[vkamicht]

Change vdub from full processing, to Fast Recompress, and encode from there.
Or alternatively in Full Processing mode, Choose "Color Depth...", and choose the appropriate colorspace for the output format.

edit: Not sure the output color thingy will affect your encode in any way.
It'd be safer to choose fast recompress and encode.

Fast recompress doesn't help, still looks the same.

The really blocky looking areas at the bottom look better if I decompress as YUY2 and output as YV12. Does that sound right? Unfortunately the rest of the colors on the frame still don't look as correct as I hoped they would. I wonder if I'll just have to settle with it... I have a bit of a perfectionist attitude with this so I'm really upset that mcbob won't accept YUY2.

[foxyshadis]

Hrm... well I'm encoding in xvid with Vdub so the "What I see is what I get" holds true. Just tested it without converting back to anything and the video had this problem too. This means I have to convert back to YUY2 or RGB in the script even before encoding... any way I can get around this?

Conversion to YUY2 never hurts, though it shouldn't be necessary. Besides what Terranigma said, the xvid output will also be munged the same way if you just open that up in vdub. You'll have to deinterlace it on playback, or upconvert manually if the automatic conversion (usually in the video card) is incorrect. I have no idea if ffdshow's conversion to YUY2 would respect chroma interlacing.

(Btw, you asked why, earlier. It's because most newer avisynth filters either run only in YV12 or somewhat faster. And all common codecs use only YV12.)

[vkamicht]

Alright, thanks guys...

I've just never had all these weird issues until I started converting to YV12 in the avisynth script. I've always used xvid for compression, and apparently it converts to YV12 anyway? Yet all of my videos looked fine as far as the colors go. Now all of a sudden I'm finding problems that only exist on half of my videos, and when I find the appropriate settings to fix those, I find new problems with my other videos.

If I use the settings to fix the frame in question above, it creates a problem in another vid of mine where some thin lines on the image suddenly have ghosting above/below them. Same type of source too (YUY2). I'm just not sure where to go from here :P

[foxyshadis]

Well, like I said, it never hurts to convert everything back to YUY2 when you're done processing. That way the codec can take care of all the colorspace issues as it needs to.