Color Noise

[Soshen]

I know...

* If source format is not YV12 (analog capture, DV) or final encoding format is not YV12, then color format conversion will results in chroma interpolation with some quality decreasing.
* Filtering of subsampled chroma can result in some chroma broadening relatively luminocity pixels, especially for interlaced video.
* Because the chroma in interlaced YV12 video occurs on alternating lines, it is necessary to use a different upsampling/downsampling method when converting between YV12 and YUV 4:2:2 or RGB. This can lead to chroma upsampling/downsampling errors if the wrong color space conversion method is used on the video.
* If YV12 video is stored in an AVI container, there is no metadata to indicate whether the video is interlaced or progressive. This means that an application or component doing color space conversion has no easy way of choosing the correct conversion method (interlaced or progressive). Most color space converters assume progressive which can lead to chroma upsampling/downsampling errors when interlaced video is processed in such an environment.

http://xs119.xs.to/xs119/07394/onlycolorswap.png
this is a test with no compression; i've only changed the color matrix. Png are lossless

but my video dont are interlaced and the source are yv12 too.

generally the usage of avs with convertToyv12() dont add a lot of noise, color problem with line and gradient, but with some anime (like baccano!), especially those have a lot of dark areas and fog/shadow effects, using yv12 seem a bad choise ^^

Anyone has noticed it?

[foxyshadis]

There's no choice about it - everything you can obtain from digital video comes from YV12 and will return to YV12, codecs like divx, xvid, and x264 can't encode to anything else. By working in it, at least you won't be surprised by the end result when the codecs do their conversion.

YV12 does have a significant quality penalty compared to RGB - the colorspace is much smaller, especially in bright and dark areas. It's annoying, but until we have 10-bit or more it's what you have to live with; you can compensate by adding noise or debanding, both are far more effective on playback than before encoding. Commercial movies with the same sort of scenes look good because they use such a high bitrate that all the noise can be kept.

[Soshen]

well the image are only with avs color conversion... isn't compressed but it's the same...

[hartford]

well the image are only with avs color conversion... isn't compressed but it's the same...

Off-the-wall suggestion (worked for me once): try adding noise to the RGB converted video, such as Blockbuster, then convert to YV12.

Or add even more noise with something like AddGrain.dll, and smooth it. I've done this with results that I didn't like, but it got rid of "banding."

Good luck.

[foxyshadis]

More practical than theoretical advice then: Try the filter gradfun2db, a debanding filter made specifically to minimize the lousy YV12 problems by dithering. Blockbuster and addgrain will kind of help, but the result stands out more, which is undesirable. (FFdshow's deband filter is just a port of gradfun2db.) ffdshow is actually preferred; as I said, it's better to use it on playback, since encoding will usually eat it.

btw, you actually have the same problems in YV24. It's not the chroma subsampling (though that necessarily makes resolution a bit worse), it's the limited YUV colorspace. The normal YUV can represent more color than RGB in the middling luminosity and much less at the extremes (as opposed to something like YCoCg, which is a 1-to-1 reversible mapping to RGB), but since everything comes from and goes to RGB in the end anyway, it's kind of a waste. 10-bit YUV can accurately represent all the important colors that 8-bit RGB can, though, but avisynth doesn't support that yet.