interlaced YV12 problem

[drcl]

a=BlankClip(length=500, width=720, height=288, pixel_type="YUY2", fps=25, fps_denominator=1, audio_rate=48000, stereo=false, sixteen_bit=true, color=$FF0000) 
b=BlankClip(length=500, width=720, height=288, pixel_type="YUY2", fps=25, fps_denominator=1, audio_rate=48000, stereo=false, sixteen_bit=true, color=$00fF00)
interleave(a,b)
assumefieldbased()
weave()

#1
converttoyv12(interlaced=true)

#2
#converttoyuy2(interlaced=true)

viewing the output alternately; with no colorspace conversion, with #1 and then with #1 and #2

both yuy2 outputs look the same

the yuy2 and yv12 outputs look different. they should look the exactly the same.

this would lead me to believe the YV12 codec is not working correctly. tried XVID and FFDshow-VFW.

Or is this correct behaviour?

[Guest]

Conversion to YV12 and back is lossy by definition. YUY2 is fully sampled vertically; YV12 is not. If you throw away information you cannot get it back.

There is also a phenomenon called Chroma Upsampling Error (CUE) that you may be seeing.

See here for technical details:

http://www.avisynth.org/Sampling

[Manao]

No, they should be the same, since both fields are uniform. So if they aren't, it's a bug.

[GodofaGap]

No it's not a bug. Assuming that YV12 supports interlacing is wrong. I'm pretty sure that the YV12 data will be upsampled to RGB for display assumed as progressive as there is no way of signalling if YV12 data is interlaced or not. Again the YV12 format as such does not support this. It consists of 1 Y plane, 1 U plane and 1 V plane and since both U and V planes are halfheight it can't possibly be interlaced. (Chroma is always shared between line 1 and 2, line 3 and 4, etc.)

Of course 4:2:0 can be interlaced, but not the format known as YV12.

[Guest]

Originally Posted by Manao

No, they should be the same, since both fields are uniform. So if they aren't, it's a bug.

Good point. I tried this serving both into VirtualDub (1.6.12) and they all look the same to me.

drcl, what difference do you see?

@GodofaGap

There are progressive and interlaced samplings for YV12.

[GodofaGap]

Neuron2: where can I find the interlaced YV12. The format description here makes no mention of it --> http://www.fourcc.org/yuv.php#YV12.

Also in VirtualDub 1.6.14 I can definately see a difference between YV12 and YUY2. Perhaps Avery Lee's comments can clarify this. http://forums.virtualdub.org/index.p...&f=15&t=11044&

[Guest]

I didn't say there was any flag to denote the different sampling *in AVI*. MPEG has such a flag. This is one reason why YV12 is a minefield and you have to know where you are stepping.

While Avery says that YV12 *shouldn't* be overloaded, in practice it often is.

[GodofaGap]

But AVS tries to simulate an AVI so this would be rather important.

[EDIT} OK but then its still not a bug. It's expected behaviour when displaying interlaced YV12.

[IanB]

For output, yes! But to provide maximum functionality from all and any input source we cater (clumsily) with interlaced YV12 layout. A lot of people like to reprocess clips to progressive form and like to do so with the minimum loss of data, we oblige.

Note also there are hacks within AVI to cope with interlaced 4:2:0 as bent YV12. A solution could be to have a different FourCC for interlaced 4:2:0 avi data, but until one is ratified we have nothing to implement against.

See the article, http://www.avisynth.org/Sampling for lots of good discussion and further links.

[GodofaGap]

Originally Posted by IanB

For output, yes! But to provide maximum functionality from all and any input source we cater (clumsily) with interlaced YV12 layout. A lot of people like to reprocess clips to progressive form and like to do so with the minimum loss of data, we oblige.

Of course, and as long as you stays within avisynth, juggling and messing around with formats can be done anyway you want. And this is fine.

For all clarity I do not think using/outputting interlaced YV12 is wrong, it is in fact very practical. I just wanted to explain where the problems as seen by drcl come from.

[foxyshadis]

Maybe 2.6 can add new hooks to handle progressive/interlace mixing, but dgdecode's upconv seems like a far cleaner solution (other than having to use yuy2, not yv16). In that case it wouldn't be hard to just make up a YI12 (YV12 interlaced) 4cc and use that when avisynth outputs it? I'm sure avery would agree to that. (ConvertToYI12 would by the same as ConvertToYV12(interlaced=true) except for setting the new 4cc, for backwards compatibility, if desired.)

A bit off topic: Ian, is YV12->RGB roughly equivalent to the page's explanations of YV12->YUY2->RGB, but one step? Or is it entirely differently weighted?

(Barring the addition of a 4:4:4 planar format, it'd be very nice to use something sharper than a very basic kernel to do the upsampling. Perhaps in the future it could be passed through resize filters, like lanczos or spline?)

[GodofaGap]

I don't think it is very practical to use new fourcc's if it is only supported by VirtualDub. It would be easier if an existing 4:2:0 format would be used that properly supports interlacing. (Although 4:2:0 can never really do this due to vertically shared chroma.)

[IanB]

Originally Posted by foxyshadis

A bit off topic: Ian, is YV12->RGB roughly equivalent to the page's explanations of YV12->YUY2->RGB, but one step? Or is it entirely differently weighted?

No, currently all YV12 <-> RGB goes via YUY2

Maybe 2.6 can add new hooks to handle progressive/interlace mixing, ...

Per frame properties are not on the adjenda for 2.6

Perhaps in the future it could be passed through resize filters, like lanczos or spline?)

In 2.6 the resizer is used to convert between planar formats. YUY2 converts with YV16 and RGB converts with YV24. The intention is to eventually make the resizer algorithm user selectable.

Originally Posted by GodofaGap

I don't think it is very practical to use new fourcc's if it is only supported by VirtualDub. It would be easier if an existing 4:2:0 format would be used that properly supports interlacing.

If someone ratifies an appropriate FourCC we will probably implement it.

(Although 4:2:0 can never really do this due to vertically shared chroma.)

There is no problem with representing interlaced data in a 4:2:0 format. The problems come from programmers incorectly coding for this.

[GodofaGap]

There is no problem with representing interlaced data in a 4:2:0 format.

What I meant to say is that if you share chroma between uneven lines and even lines (so chroma is shared between line 1 and 3, line 2 and 4, etc.) this is ok if the content really is interlaced. But it is suboptimal if you have static areas (which are therefor progressive), but it's not the end of the world of course. In the avisynth doc you linked to it is called ICP (interlaced chroma problem).

[foxyshadis]

It's doubtful such a format would ever be ratified by any body, as most commercial tools import DV/MPEG directly and don't need a lossless intermediary. If you and Avery Lee agree on a format that isn't in use now, to describe an encoding that you're the main producer of, others might follow. After all, almost every format out there were given fourccs by a company without any standard recognition.

[drcl]

@neuron2
they just look different in virtualdub when zoomed, i cant explain. the conversion to yv12 then back to yuy2 looks the same as the original yuy2

isn't CUE only applicable to horizontal errors?

its my understanding is, in respect to display representation, that yv12 and yuy2 are the same in luminance plane but chroma is vertically half in yv12.

in interlacing the vertical is sampled across odd/even couplets of lines.

so if i start with lines in yuy2.....

1: RED
2: BLUE
3: RED
4: BLUE

Then convertoyv12(interlaced=true)


i should still get red, blue ,red, blue; but in memory its represented differently as one piece of data for 2 lines as apposed to one for each line

if i convert back... converttoyuy2(interlaced=true)

i should be able to recover all the data losslessly, which it appears that i do.

of course this would not be true for an image where lines 1 and 3 originally had different chroma values

anyone else able to recreate this?

[scharfis_brain]

in fact interlaced vs progressive Sampling conversions between YUY2 and YV12 are the extremes. There also is a thing inbetween...

If you want to make absolutely sure, that nothing goes wrong with chroma motion, then do interlaced sampling. This will preserve the fields at every cost (the price is much lower accuracy in vertical).
If you want to achieve best possible resolution with progressive video, then stick for progressive sampling. This destroys the field structure, of course and also WILL show chroma combing on TV.

The best of both worlds can be achieved with motion adaptive YUY2 <-> YV12 conversion routines.
Such a function will sample everything static as progressive and everything that is combed as interlaced.
Also this kind of conversion routine is the most lossless on because it does the mode decision upone the image content rather than the users (mis-) choice.

Also not that interlaced subsampled YV12 can be upsampled the progressive way and progressive subsampled YV12 can be upsampled interlaced.
This is possible because the sampling points of interlaced ond progressive YV12 are in the SAME place.
This also is the reason, why there is NO interlacing flag for YV12. The interlaced signalling has to be made by the overlayed codec, like MPEG2 does.

[Wilbert]

If you and Avery Lee agree on a format that isn't in use now, to describe an encoding that you're the main producer of, others might follow.

A while ago i had a discussion with Avery about this. He told me, besides that YV12 interlaced doesn't exist[*], that he's willing to support a new fourCC for interlaced 4:2:0. I don't know if it's good to follow that route, since codecs (like XviD, x264) and players should support it too. At least, they should set the interlaced flag.

[*] The stuff on your dvd is technically not YV12. The part which is 4:2:0 progressive is the same format as YV12, but 4:2:0 interlaced is not. This should be reflected in the docs one day.

[drcl]

i just read the cue documentation again, it does explicitly state that yv12 codecs like XVID upsample interlaced yv12 incorrectly as they assume progressive, I guess virtual dub does the same, in fact all applications would assume it. Thats why CCE doesnt accept YV12 i guess.

I also realised that if i had used separatefields() then it would have been more obvious what was really going on.

Only encoders that "know" that they are getting input from AVS in YV12 interlaced will encode correctly, I assume. ie HC/QuEnc

Does XVID encoder sample correctly if the interlaced checkbox is set?

So yv12 interlaced will always look wrong when converted to rgb by anything other than avs.

It's not a bug. I'll read everything for that 5th time before i post again.

[Cheech]

Originally Posted by drcl

Does XVID encoder sample correctly if the interlaced checkbox is set?

I have been able to encode interlaced YV12 XviD if that's what your asking, but I've also been having my fair share of problems working with YV12, and playing that file back. See my other thread for all the problems I'm having. Also in that thread is a sample interlaced XviD that I made so you can test yourself how it plays back on your system.