Does YV12 to YV12 deinterlacing lose chroma detail?

[in_awe]

If I have an interlaced YV12 clip and deinterlace it, is some of the chroma information lost due to YV12 also being the output color space? I'm assuming that part of the deinterlacing involves coming up with new chroma values for each pixel. If YV12 is the output color space then those new values would get subsampled down to one for every four pixels. Wouldn't it make more sense for the output of the deinterlacer to be YV16/YUY2 or even YV24? Alternately, should one convert to a higher color space before deinterlacing?

A related question - How do the AviSynth ConvertTo filters determine chroma when converting from YV12 to a higher format? Are the chroma values simply copied from the YV12 values or are they interpolated by taking into account neighboring values?

When upscaling YV12 clips, does it make sense to convert to a higher color space first so that the upscaler can output more detailed chroma planes instead of having to subsample them back down to YV12?

Finally, does any of this matter as far as what our eyes see? Are our eyes so insensitive to color that they won't notice the difference of going to a higher color space when deinterlacing or upscaling? Ultimately, if it takes a bunch of extra processing power for little to no gain then it's not worth it.

FYI, I'm using AviSynth for scaling and deinterlacing DVDs for real time display, not for re-encoding, so I'm not concerned about increased bit rates, just increased processor time.

Thanks in advance for any answers.

[scharfis_brain]

ideally, a deinterlacer brings back luma as well as chroma detail, regardless of the colourspace.

you can run your deinterlacing an resizing safely in YV12 without conversions, if the source is YV12 already.

do NOT attempt to convert the colourspace before deinterlacing. always do it afterwards.

[zambelli]

How about when trying to reconstruct the original YV12 source from a bobbed YV12 video? Wouldn't some of the chroma information get irretrievably lost?

[MfA]

Oops, I misunderstood ...

Why would you do bob deinterlacing first and then try to perform more advanced deinterlacing? Sure if you use linear filters the chroma will get blurred when you try to interpolate the chroma for a progressive bobbed frame ... but the solution is simple, don't go there :)

PS. interlacing is the spawn of satan and the people responsible for us being stuck with it for another generation of TV should be shot.

[Blue_MiSfit]

True, interlacing is an evil leftover of the analog years..

Still, you've basically got two options otherwise (assuming you keep the same bandwidth)

1) encode at 30fps and lose half the motion

2) encode at 60fps and lose half the resolution

Interlacing kind of gives you the best of both worlds, full spatial detail in low motion scenes, but full 60fps motion fluidity.

Of course, it's all moot since you can't display it properly on anything other than an interlaced CRT... But the fact remains that it's the largest install base.

I hate it too, but it's here to stay until most folks have progressive displays..

~MiSfit

[zambelli]

Why would you do bob deinterlacing first and then try to perform more advanced deinterlacing? Sure if you use linear filters the chroma will get blurred when you try to interpolate the chroma for a progressive bobbed frame ... but the solution is simple, don't go there :)
No, what I meant was: what if you bob an interlaced video, then later on for some reason decide to reconstruct the original interlaced video from the bobbed one? Does the chroma get lost in the process?

480i30 --> 480p60 --> 480i30

It might sound strange, but I've seen it done.

[in_awe]

OK, after some further reading, I think I understand why it would be a bad idea to convert YV12 to a new color space before deinterlacing. I'm still wondering, though, if it would make more sense for a deinterlacer that is receiving YV12 as input to output YV16/YUY2 or higher. I guess I should specify that I am talking about deinterlacers that combines fields (motion compensated), not ones that treat the fields separately (bob). Since the deinterlacer has to compute new chroma values anyways due to combining the chroma from separate fields, wouldn't going to a higher color space in the process allow for more detail in the final output? The chroma planes of the higher color spaces have 2 to 4 times as many sample points as YV12, so the deinterlacer could come up with a more detailed interpolation, and the resulting chroma planes should be smoother. I'm guessing that the difference would only be noticable when deinterlacing a YV12 clip due to the implications of 4:2:0 sampling when dealing with interlaced material.

[MfA]

full spatial detail in low motion scenes
The effective vertical resolution of interlaced frames is only something like 0.7 times the actual one due to deflicker filtering ... and that's best case. Worst case it's even below 0.5 times (deflicker filtering plus vertical movement at an integer multiple of pels per field).
Of course, it's all moot since you can't display it properly on anything other than an interlaced CRT... But the fact remains that it's the largest install base.
Over the lifetime of 1080i signals most sets displaying those signals will be progressive.

PS. whoever was responsible for using the double field vertical resolution as the number to describe interlaced resolutions should be shot twice ... it's plain disingenuous.

[scharfis_brain]

many downscales form 1080i or 720i resolutions to analogue 432i (576i with letterboxing) were nonfiltered so that you got full 432 lines vertical resolution after deinterlacing.

This is why HD to SD downconversions look so damn good even on good old analogue TVs. Of course they show a bit more flicker.

[Didée]

Edit: Some more thinking revealed that this post was mostly nonsense. ;)

Ah, interlaced YV12. MfA got it with his P.S. in post#4.

I see one more problem with interlaced YV12. Not sure if this was explicitely discussed already.

Say we have an interlaced source. Say we look at a static scene, without motion.
Usually it is assumed that when there's no motion, the fields "fit together" perfectly, so we get back "full spatial resolution" in this case.

Now, from what I understand this is not the case for interlaced YV12. Problem is that in a source coded as interlaced YV12, alternating scanlines are sharing the same chroma sample. This means that even in a fully static scene, the chroma samples are entangled, and can not provide the full spatial chroma resolution.


Some simple tables as example. Lets assume an original RGB source with a soft vertical color gradient. How is it sampled as progressive vs. interlaced YV12?


Numbers:

li pix prog int
ne el ress erla
ive ced

1 10 s1=11 s1=12
2 12 s1=11 s2=13
3 14 s2=15 s1=12
4 16 s2=15 s2=13
5 18 s3=19 s3=20
6 20 s3=19 s4=21
7 22 s4=23 s3=20
8 24 s4=23 s4=21


Shape:

RGB YV12 pr. YV12 int.

.......x .......x ......x.
......x. .......x .....x..
.....x.. .....x.. ......x.
....x... .....x.. .....x..
...x.... ...x.... ..x.....
..x..... ...x.... .x......
.x...... .x...... ..x.....
x....... .x...... .x......

Now, I don't claim to be correct here. Very well possible that there's an error somewhere in my thinking.

If so, someone please point it out. From my current understanding, interlaced YV12 can not provide full chroma resolution in static areas, compared to progressive YV12.

If this is somehow true, then think again about e.g. hard-telecined NTSC: One would not be able to get "perfect" progressive film again by IVTC.


For freshing up, the thread YV12 chroma placement (http://forum.doom9.org/showthread.php?t=52151) is a good one.

[Didée]

Oh, stupid me stepped in the old pitfall.:o Thinking "a pixel does 'have' a color" is no-go in YV12. There are chroma samples. Period. When doing the transition from interlaced to progressive, then the mapping of samples->pixels/scanlines simply changes, and there we are.

Every now and then, you have to make an idiot out of yourself. :D

[Wilbert]

If so, someone please point it out. From my current understanding, interlaced YV12 can not provide full chroma resolution in static areas, compared to progressive YV12.

I don't understand the point in your last post very well. But when encoding progressive YUY2 to interlaced YV12 instead of progressive YV12, you will loose more chroma resolution.

Thinking "a pixel does 'have' a color" is no-go in YV12.
Huh? Of course a pixel has a color.

[Leak]

Huh? Of course a pixel has a color.
I guess he meant "each pixel has it's own color, independent of the surrounding pixels" - in YV12, 4 pixels share the same chroma value.

np: Phantom Ghost - Nothing Is Written (To Damascus)

[Didée]

Well, interlaced YV12 is tricky, and I've been struggling with [truly, fully] understanding it ever since. :)

Huh? Of course a pixel has a color.
In a sense, yes. Sure it has. And in a sense, no. It has not.

Thinking of pixels "having" a color was how I came to the misconception 2 posts above. Now, for means of understanding the matter, I prefer to look at it like this: a pixels gets a color.

What's stored in the stream are values of chroma samples. These chroma samples do have a "color", i.e. their value. Pixels do not have a color per se. Pixels get their color from those chroma samples to which they are assigned to.

http://img214.imageshack.us/img214/8703/yv12ijy2.png (http://imageshack.us) http://img339.imageshack.us/img339/8617/yv12pgf9.png (http://imageshack.us)

And when going from interlaced to progressive (deinterlacing, IVTC), then it's the assignment that changes, but not the chroma samples. (Well, basically. Chroma sampling position changes too & needs to be taken into account, but lets keep it simple right now.)

This clears (hopefully:p) the confusion that I initiated in my first post above. There, in a weak moment I was assuming that pairs of even/even pixels, sharing "the same color", would get weaved with odd/odd pairs of pixels, also sharing (another) same color. If it were so, static chroma would appear combed, or stairsteppy like 4:0:0.

But it's not pairs-of-pixels that get weaved. Its single chroma samples that get weaved. And when the weave is considered progressive, then the assignment sample->pixels changes (i.e. the crossed arrows in my poor left diagram change their direction to that in my poor right diagram), and everything is in order.


You already knew that all. I had hoped my former phrasing with "changed mapping" would suffice, instead of getting this lengthy because of some mere basics. :D

Hope I served my sentence. ;)

[scharfis_brain]

@Didée: I hope, that it is now fully understandable, why I dislike converttoxxx(interlaced=true) and prefer my motion adapted color space conversion functions ;)

[Wilbert]

Perhaps superfluous, so sorry if this is nothing new to you :) Some remarks, at least not to confuse other readers ...
And when going from interlaced to progressive (deinterlacing, IVTC), then it's the assignment that changes, but not the chroma samples. (Well, basically. Chroma sampling position changes too & needs to be taken into account, but lets keep it simple right now.)
This assignment is only there when converting to YUY2/RGB and it is imposed by the user (i.e. by using either the interlaced=true or false parameter).

Assuming you deinterlace YV12 stuff (while staying in YV12), the values of the chroma samples in static scenes don't change, but in dynamic scenes they are blended together (of course, that depends on the deinterlacer). The assignment changes in the sense that you know that you should use the interlaced=false parameter to convert to YUY2/RGB to get correct video.

[IanB]

Perhaps this thread about the birth of Neuron2's AutoYUY2, Adaptive chroma upsampling (http://forum.doom9.org/showthread.php?t=97987&highlight=AutoYUY2), could serve to clarify some issues.

In a nut shell YV12 chroma does not change position with progressive versus interlaced. Only if there is motion do you see a variation.