What method of color conversion is the most correct?

[aabxx]

1. Feed xvid yuy2-video after doing a converttoyv12(interlaced=true) through avisynth
2. Feed xvid yuy2 directly without converttoyv12(interlaced=true)?

The encode will be kept interlaced in xvid, if that matters.

[drcl]

you can feed it yv12 interlaced or yuy2. either will preserve chroma correctly but there will be a speed difference. Not sure which is faster.

Make sure you use a recent version of Virtual dub if you choose to use yv12 interlaced.

http://forum.doom9.org/showthread.php?p=834465#post834465

[aabxx]

Yes, but the thing is if you take same yuy2 clip, and encode
first directly with avisynth without converttoyv12, and then with converttoyv12, the output xvid does not look the same at all.

Which method is the most accurate of these two?

[henryho_hk]

The encode will be kept interlaced in xvid, if that matters.

If you feed in interlaced content to XVID, you must turn on the interlace encode option.

[aabxx]

If you feed in interlaced content to XVID, you must turn on the interlace encode option.

Yes, I realize that, but that's not the issue.

The issue is this.

1. Xvid stores in yv12.
2. File is yuy2 (like most tv captures are)
3. File has to be converted to yv12 somehow.
4. Question: Is it better to convert yuy2-file to yv12 in avisynth (or other method), or is it better to let xvid do the conversion itself?

[foxyshadis]

So basically the question is "Does xvid properly downconvert yuy2 to interlaced yv12", which I don't know, but I doubt they would make such a huge mistake. Since you know avisynth does, it'd be smart to use that.

It's not too difficult to test though. Try this:

green=Blankclip(pixel_type="yuy2",color=$800000)
violet=Blankclip(pixel_type="yuy2",color=$80FFFF)
interleave(green,violet).weave

If that produces the expected result, great! If it smears it all into a muddy brownish color, well, at least you know it doesn't.

[aabxx]

Interesting test. $800000 (the brownish color) does get smeared when decoding with ffdshow or xvid decoder with yv12, but everything displays correctly with xvid's decoder set to yuy2. I'm not certain why this is, but at least there's no problem on the encoding side, even if there obviously are some peculiarities somewhere in the decoding...

However, that still does not answer my original question... xvid is converting correctly, but how does its convertor compare to converttoyv12(interlaced=true)?

Ie. what is better to do, feed xvid converttoyv12(interlaced=true) source or just feed it the original yuy2 source?

I realize this might be a very difficult question to answer.

[foxyshadis]

There's a very good chance that they use the exact same algorithm for translation.

[aabxx]

1: Original losslessly compressed yuy2
http://x5.freeshare.us/117fs243690.jpg




2: Xvid encoded through avisynth with only converttoyv12(interlaced=true) parameter:
http://x5.freeshare.us/117fs243897.jpg

3: Xvid (same settings as above) encoded through avisynth without additional parameters
http://x5.freeshare.us/117fs243932.jpg

As you can see, 2 and 3 look very different from eachother, so they're obviously not using the same algorithm. Question is which method is better? 2 (converttoyv12) looks sort of smeared out, but maybe that is a more advanded type of interpolation or something?

I'm sort of surprised people haven't asked this question before? :D Of course, the difference cannot be noticed under regular watching and PSNR/SSIM is almost identical, but zooming 400% like these screenshots obvisouly show the differences.

[henryho_hk]

aabbxx, I think there are at least 2 functions of the "interlaced" encode option of XviD:

1) It toggles between field-based (i) or frame-based (p) IDCT. (If interlaced, the field order option specifies the temporal order of the fields.)

2) It specifies how XviD downsamples RGB, YUY2, etc. materials to YV12.

In foxy's test, if you gave XviD a YUY2 input but disabled the interlaced encode option, the video will appear all grey.

As for your screenshots, I think No.2 is suffering from chroma-upsample error. What XviD options were you using? And what is your source material exactly? And.... in what program did you make these screenshoots?

[aabxx]

aabbxx, I think there are at least 2 functions of the "interlaced" encode option of XviD:

1) It toggles between field-based (i) or frame-based (p) IDCT. (If interlaced, the field order option specifies the temporal order of the fields.)

2) It specifies how XviD downsamples RGB, YUY2, etc. materials to YV12.

In foxy's test, if you gave XviD a YUY2 input but disabled the interlaced encode option, the video will appear all grey.

As for your screenshots, I think No.2 is suffering from chroma-upsample error. What XviD options were you using? And what is your source material exactly? And.... in what program did you make these screenshoots?

Source is family-vhs cap. I used AQ, interlaced, cromaopt, vhq/MSP on max, trellis, mpeg quant, default b-vop except no packed bitstream... caps are printscreen from virtualdub and regular paint.

Here's the thing I've discovered though.. when feeding xvid with yuy2 input, the output is marked yuy2 under file information in virtualdub. When feeding xvid yuy2 converted to yv12 through avisynth, virtualdub info says yv12 under decompressor. I suspected there is bug/non-optimal upsampling on decode, so I converted both 2 and 3 to rgb through avisynth, and what do you know, the smearing on number 2 is gone, so it must be some decoding issues I don't fully understand. The differences between 2 and 3 became very very small then, but there was still a very tiny different, although it now becomes impossible for me to say which one is closer to the original. So I either choose one based on "gut instinct", or someone has any advice to which method is actually better? :D

[GodofaGap]

The problem is that in reality there is no such thing as interlaced YV12 (it is a pure progressive format). So if you let the decoder output YV12 it is very likely that an upsampler does not take into account that the data is actually interlaced.

[squid_80]

Are you using virtualdub for these comparisons? Virtualdub doesn't know anything about interlaced yv12 and always treats it as progressive. This would explain what you see here: Interesting test. $800000 (the brownish color) does get smeared when decoding with ffdshow or xvid decoder with yv12, but everything displays correctly with xvid's decoder set to yuy2. I'm not certain why this is, but at least there's no problem on the encoding side, even if there obviously are some peculiarities somewhere in the decoding...

When xvid decodes an interlaced stream, it ouputs interlaced yv12. Virtualdub treats it as progressive and messes up the chroma.

[henryho_hk]

Source is family-vhs cap.

If you are encoding family footage and you want to play them in standalones, I suggest you either (1) encode to DVD as interlaced or (2) encode to XviD as non-interlaced, H.263/MPEG matrices, no AQ, no lumimasking, no GMC, no QPEL, 640 width and max 1 consecutive B-frame (maybe some VBV related settings as well).

[aabxx]

"I suggest you either (1) encode to DVD as interlaced or (2) encode to XviD as non-interlaced, H.263/MPEG matrices, no AQ, no lumimasking, no GMC, no QPEL, 640 width and max 1 consecutive B-frame (maybe some VBV related settings as well)."

Thanks but I've already thought it through... we have a PC as a standalone player in the living room, so it makes no sense not to go with the most effective compression options. Like say AQ... it is REALLY effective with vhs caps, and just barely degrades quality (which I can't really notice unless under heavy inspection). And the "dancing blocking" problem in dark area does not exist because on low quantizers there's so much noise encoded as well that there's not much room left for to produce block artifacts (this is not like transcoding some DVD with pre-existing blocking). A maximum of 2 b-frames and interlaced mode saves a lot of space as well, and since I'm encoding at quant 3 with average file size of 4000 kbps, you need to save all the space you can.

I've already tried mpeg-2, in particular CCE and HC, but the xvid's looked clearly better at ~4000 kbps. With noisy interlaced clips, 4000 kbps is quite an acceptable bitrate when neither ateme nor HC or CCE could do a similar job at that bitrate.

[henryho_hk]

aabxx, if you are using filters in AVISynth, you should convert the clip to YV12 interlaced with AVISynth right after AVISource(). Then you will have a much wider choice of filter as many of them are YV12 only.

If your computer is powerful enough (the player), I suggest to try MVbob() which converts your clips to 60p. You will be amazed of the quality.

[drcl]

I asked a very similar question to this, and did post the link to it earlier. The conclusion was that it makes no difference if you use YUY2 or interlaced yv12(avisynth). If you tell exid to encode interlaced it will do so. If you want to play it back correctly you also need to use a bob deintelacer. Personally i use the h/w deinterlace in FFDshow.

Also, you MUST use virtual dub mod or a recent virtual dub. other versions do not respect yv12 interlaced!!!!

http://forum.doom9.org/showthread.php?t=111747