說到 YV12，順便提一下最近很熱門的 Avisynth 2.5 alpha。
Avisynth 2.5 alpha 最大的特色，就是支援 YV12 直接處理。我們知道原始 MPEG 資料是 YUV 4:2:0，也就是 YV12 的格式，以前我們在做 DivX/XviD 壓縮的時候，處理流程是：
DVD/VCD(YUV 4:2:0) -> DVD2AVI(YUV 4:2:0 -> YUV 4:2:2 -> YUV 4:4:4 -> RGB24) -> VFAPI(RGB24) -> TMPGEnc/AviUtl/VirtualDub(RGB24) -> DivX/XviD Codec(RGB24 -> YUV 4:2:0) -> MPEG-4(YUV 4:2:0)

ps. VFAPI 內部只能以 RGB24 傳遞資料，所以會轉成 RGB24 輸出

或是
DVD/VCD(YUV 4:2:0) -> MPG2DEC.DLL(YUV 4:2:0 -> YUV 4:2:2) -> Avisynth 2.0.x(只能用支援 YUV 4:2:2 的 filter，不能用 RGB24/32 的 filter) -> VirtualDub(YUV 4:2:2，不能使用 VD 的 filter，因為 VD 的 filetr 都是在 RGB32 上處理，壓縮時要選 Fast recompress，才會直接原封不動的送 YUV 4:2:2，也就是 YUY2 的資料給 Codec 壓縮) -> DivX/XviD Codec(YUV 4:2:2 -> YUV 4:2:0) -> MPEG-4(YUV 4:2:0)

所以以前的處理流程中間要經過好幾次 YUV <-> RGB 的轉換。這個轉換是有損的，做得越多次，原始的色彩資訊就損失的越嚴重。而且這個轉換的計算又耗時。那麼有人（Marc FD）就想到，反正最後轉成 MPEG 都要存成 YUV 4:2:0 的格式，那麼為什麼不乾脆一路到底，全程都以 YV12 處理，也就是所有的 filter 都改寫成 YV12 的版本，直接在 YV12 上做調整色彩、濾雜訊、IVTC 等工作，這樣
1. 處理的資料量少。（YV12 的資料，UV 比 YUY2 少一半，比 RGB 24/32 少更多）
2. 不用轉換計算

所以速度快。再加上又可以避免 YUV <-> RGB 轉換的損失，豈不是一舉兩得？
所以支援 YV12 的 Avisynth 2.5 就誕生了
但是目前 VirtualDub 還是不支援 YV12，所以要得到全程 YV12 處理的好處，必須使用 VirtualDubMod 這個軟體才行，這個改版才有支援 YV12（一樣要選 Fast recompress）。

不過因為我要用 TMPGEnc（只接受 RGB24/32），所以我還是沒使用全程 YV12 的方法