Last month I fielded x_xy_y2 the possibility of fixing yet another VSFilter legacy limitation which hurt quality. Incorrect chroma placement.
As some of you may remember, VSFilter has always used MPEG-1 centered chroma placement. This is a problem since nowadays MPEG-2 & H.264 default to left chroma placement. YCbCr->RGB conversion by the video renderer, which assumes incorrect YCbCr chroma placement, results in misaligned chroma with significant bleeding outside the luma.
It's looking positive that the next xy-VSFilter build will have MPEG-2/H.264/HEVC compatible left chroma placement implemented, which should hopefully hold us over into the foreseeable future. x_xy_y2's initial implementation appears to be working correctly, from my testing so far.
F.Y.I: Libav|FFMPEG (swscale) appears to default to outputting RGB->YCbCr outputs MPEG-1 chroma placement, while it's YCbCr->RGB assumes MPEG-2 chroma placement which ironically is the same problem VSFilter had. Word to the wise, don't use swscale (ffdshow|lav filters|mplayer2) to sub-sample RGB -> YCbCr. VirtualDub offers the highest quality 'correct' RGB->YCbCr chroma placement if you value detail and artifact-free chroma sharpness. AviSynth 2.6 is also 'correct' but the quality is mush, with it significantly blurring the chroma by default, and creating artifacts with sharper chroma resampling kernels. Only really relevant to people who do YCbCr->RGB->YCbCr or some such for filtering before encoding. Most people should never encounter this swscale limitation under normal circumstances, since all renderers accept RGB input. Likely the reason they never fixed it?