idea for upsampling interlaced YV12 in a progressive way....

[tritical]

So we agree YV12i <-> YV12p would result in a [1 2 1] vertical chroma blur (and is a really bad idea)
Your saying that using:

converttoyuy2(interlaced=true)
converttoyv12(interlaced=false)

is equivalent to a [1 2 1] vertical blur of the chroma? That seems impossible to me since if you use the above two functions it would be equivalent to doing a blur of 4 pixels (sorry didn't have time to calculate the actual coefficients for this one) not 3. Or are you saying that using a [1 2 1] vertical blur would be better then doing the above? Also, using:

converttoyuy2(interlaced=false)
converttoyv12(interlaced=true)

would be equivalent to doing a [3/16 10/16 3/16] vertical chroma blur, which is pretty close to a [1 2 1]. Finally, using:

converttoyuy2(interlaced=false)
converttoyv12(interlaced=false)

is equivalent to doing a [1/8 6/8 1/8] vertical blur of the chroma planes. Of course, all of this is assuming your starting with a yv12 source.

[scharfis_brain]

why converting interlaced yv12 (with progressive content!) to yuy2 and then to yv12?

just assuming it would be progressive. thats all.

http://home.arcor.de/scharfis_brain/samples/interlacedyv12.png



the source was a rgb bmp created with paint and then encoded using tmpegenc in interlaced mode (like DVB does)

this image, I upsampled to rgb32 (rgb, cause it needs to be displayed on a rgb device :) ) using four ways (goal: best quality for progressive)

upper left: converttorgb32(interlaced=false) -> best result
bottom left: converttoyuy2(interlaced=false).converttoyv12(interlaced=false).converttorgb32() -> little bit smoothed
upper right: convertorgb32(interlaced=true) -> bad bad result, as we know it. typical for interlaced upsampling
bottom right: converttoyuy2(interlaced=true).converttoyv12().converttorgb32() -> bad result too! only the chroma combs are gone, which is causing even mor blurryness...

this leads me to the assumetion, that we can ALWAYS treat yv12 as progressive, if the image content is progressive. no need for cracking our brains, if the source is progressive.

for sure, we should go for a motion/comb adaptive upsampling to yuy2 for interlaced video, if major modification on the image is wished...

[MfA]

Originally posted by IanB
So we agree YV12i <-> YV12p would result in a [1 2 1] vertical chroma blur (and is a really bad idea) :p

@MarcoWould you like to propose some "warning text" to put in the doco.:D

IanB

"Color conversion routines will produce incorrect result when used on fieldbased clips, except for RGB<->yuy2."

[Wilbert]

I will add some stuff to the docs :) But, I don't have time before the end of the week.

[IanB]

Dear all,

This YV12i <-> YV12p issue is about a RFE request (http://sourceforge.net/tracker/index.php?func=detail&aid=740165&group_id=57023&atid=482676) I suspect is ill conceived but can't quite convince myself. Here is the text of the requestI have problem that i allways need to use
ConvertToYUY2( interlaced=true )
ConvertToYV12()

in after mpeg2souce since it outputs interlace YV12 and basicly YV12 is really an progressive format and only internaly interlaced support in Avisynth. So what would be needed is to make ConvertToYV12 to work even if video is in YV12 allready to convert interlaced YV12 to progressive and vise versa...since i think decomb and some ivtc:r's need interlaced YV12 to work. So this would be little speed up so that there wouldn't be need to go through YUY2.

Example:

if AVI is loaded and it's in YV12 normal progressive YV12.

Avisource( &quot;xvid.avi&quot; )
ConvertToYV12( interlace=true )
Decomb()
ConvertToYV12( interlace=false )

Ofcourse it would be better to have interlaced flag for YV12 in general so filters could use that.

But anyway since YV12 is really an progressive format atleast in AVI files you will need to convert video to progressive YV12 in the end so it looks ok when compressed to example XVID since otherwise chroma is in wrong place every second row. And you won't see that very easily if you loaded .d2v with mpeg2source and it had force film option on and video is progressive but chroma is still sampled interlace and that conversion to progressive YV12 is still needed.

I think now that YV12 came along people have encoded millions of avis with missaligned chroma because no one seems to talk about this problem.
So how would you all answer this.

IanB:)

[Wilbert]

AFAIU:

1) mpeg2source doesn't always output interlaced YV12. It's framedependent, and the info can be found/extracted in the dvd2avi code. Howover, this info seems not always to be correct. I recall someone gave an example in the dvd2avi forum (but can't find the thread atm).

2) interlaced YV12 with progressive content should be treated as progressive YV12, because of the reasons scharfis_brain, tritical and others mentioned in this thread.

3) If you have interlaced YV12 (with interlaced content), and your target is progressive, you need to deinterlace it obviously.

4) If you have interlaced YV12 (with interlaced content), and your target is interlaced. There are several subsituations:

4a) What happens if you want to do interlaced XviD encoding (VDubMod)? Does it need progressive/interlaced YV12?

4b) What happens if you want to do interlaced XviD encoding (VDub)? Avery removed the YV12 support from the last version. So, you need to convert it to interlaced YUY2 in AviSynth. I quess ...

4c) mpeg2 encoder needs YUY2/RGB. So, you need to convert it to interlaced YUY2/RGB in AviSynth.

4d) mpeg2 encoder needs YV12 (like Mencoder/QuEnc). I'm not sure. It has an interlaced option, so you can feed it with interlaced YV12. I guess.

To come back to (1). interlaced YV12 with progressive content is also marked with an interlaced tag (in dvd2avi). So, even if we are able to use 'by frame properties' (in mpeg2dec3 itself, of avs 3.0), we are not able to differentiate between interlaced YV12 with progressive or interlaced content by looking at the flag. Assuming the flag is always correct, which seems not to be the case.

I'm a bit puzzled by this remark
in after mpeg2souce since it outputs interlace YV12 and basicly YV12 is really a progressive format and only internaly interlaced support in Avisynth.
I have to admit, the dvd's I have (pal) all have progressive content. But, I thought there are dvds with interlaced content? So, is this remark false?

[IanB]

@tritical,

Thank you for giving me a nudge out of my stupid mind lock.:cool:

In sumary, vertical blur matrices, expressed centred on current sample. YV12 input clip.

YV12.converttoyuy2(interlaced=true).converttoyv12(interlaced=true)
[3 26 3]/32

YV12.converttoyuy2(interlaced=true).converttoyv12(interlaced=false)
[1 3 7 5 0]/16 top field
[0 5 7 3 1]/16 bottom field

YV12.converttoyuy2(interlaced=false).converttoyv12(interlaced=true)
[3 10 3]/16

YV12.converttoyuy2(interlaced=false).converttoyv12(interlaced=false)
[1 6 1]/8

IanB:D

[Wilbert]

PS. I would like to reiterate that the fact that yuy2<->yv12 use the standard colorspace conversion routines when working in fieldbased mode should be considered a bug :) If the bug is going to remain in place I think it should be mentioned in the docs, for those few sane people who do like to process interlaced video fieldbased.
There's a bit about it in http://www.avisynth.org/Convert. However it's not clear enough, and perhaps even a bit false:

Question. Suppose you got interlaced YUY2 video (you capped something). Likely, there are frames in it with no movement (thus no combing), which can be considered progressive.

What would you do if you need to convert it to YV12. Would you use
ConvertToYV12(interlaced=true) on the whole clip, or only one the combed frames?

[MfA]

The yv12<->RGB conversions are just as buggered for fieldbased clips, all yv12 related conversions are buggered for fieldbased clips period. For no other reason than that noone wants to fix it correctly :) (Including me.)

Yes if there is no motion then doing conversion with interlaced=false will give more chroma detail than with interlaced=true without introducing artifacts, I have no idea how soon the results become noticeably worse as soon as things start moving though.