Chroma shifting up/down slightly as a result of YUV colorspaces...

[Katie Boundary]

YUV colorspaces that measure chroma in 2-pixel-tall increments (like YV12) have a problem: if every pixel is treated as having the exact chroma values as the 2-pixel-tall block to which it belongs, then each field is shifting the chroma plane up or down slightly. Specifically, the top fields are moving the chroma plane 1/2 of a pixel up, and the bottom fields are moving it 1/2 of a pixel down. This has ramifications for everything from deinterlacing to YUV->RGB conversion. I think there was already a thread about this. If so, can anyone point me toward it? If not, what measures have been taken in either AVIsynth or its filters (or other software) to correct or compensate for this effect?

EDIT: Found it https://forum.doom9.org/showthread.php?t=140233

But since that thread was originally specifically about deinterlacing, and YUV-related chroma bob was a tangent that has implications beyond deinterlacing, I think this topic deserves its own thread.

[hello_hello]

But since that thread was originally specifically about deinterlacing, and YUV-related chroma bob was a tangent that has implications beyond deinterlacing, I think this topic deserves its own thread.

I thought the issue only applied to interlaced video, as progressive is subsampled differently. Assuming it's not encoded as interlaced instead of progressive.
Unless I'm misunderstanding what you mean.

444
BlankClip(Color=color_red)
Subtitle("Some Text", align=5, size=40, halo_color=color_red)
Crop(0,190,0,-210)

https://i.ibb.co/dmSnqYh/444.png (https://ibb.co/WVQSwJT)

420
ConvertToYV12()

https://i.ibb.co/WxT2JsM/420.png (https://ibb.co/8Kh7ZXf)

The edges blurred, but there's no shift is there?

[Sharc]

@Kathie
You could possibly try something like this:
separatefields()
e=selecteven().ChromaShiftSP(0,0.5) #whatever shift
o=selectodd().ChromaShiftSP(0,-0.5)
interleave(e,o).weave()

http://avisynth.nl/index.php/ChromaShiftSP

Edit:
One may collect some ideas about chroma handling of YV12() from the discussions here:
https://forum.doom9.org/showpost.php?p=1177125&postcount=124
https://forum.doom9.org/showthread.php?p=1185790#post1185790

Edit2:
Perhaps the paramater 'ChromaIn/OutPlacement=DV' in the converttoYV12() may help as it aligns the Cb, Cr samples with the luma samples? Just a thought .....
https://www.mir.com/DMG/chroma.html

[Sharc]

YUV colorspaces that measure chroma in 2-pixel-tall increments (like YV12) have a problem: if every pixel is treated as having the exact chroma values as the 2-pixel-tall block to which it belongs, then each field is shifting the chroma plane up or down slightly. Specifically, the top fields are moving the chroma plane 1/2 of a pixel up, and the bottom fields are moving it 1/2 of a pixel down. This has ramifications for everything from deinterlacing to YUV->RGB conversion. I think there was already a thread about this. If so, can anyone point me toward it? If not, what measures have been taken in either AVIsynth or its filters (or other software) to correct or compensate for this effect?

EDIT: Found it https://forum.doom9.org/showthread.php?t=140233

But since that thread was originally specifically about deinterlacing, and YUV-related chroma bob was a tangent that has implications beyond deinterlacing, I think this topic deserves its own thread.
Not sure whether your question has been addressed (and solved?) in this thread:
https://forum.doom9.org/showthread.php?t=147629