在前面第一篇的時候有提過


YC 伸張壓縮，是在 RGB -> YUV，或者 YUV -> RGB 的時候做的，所以當你直接送 YUY2 的資料進去的時候，如果 Encoder 可以吃這種格式的輸入，Encoder 便會直接接受 YUY2 的資料，沒有再經過伸張或者壓縮（沒有再經過 RGB -> YUV 或者 YUV -> RGB 的轉換過程），所以此時 Encoder 控制 YC 伸張或壓縮的選項都是無作用的，因為這個選項只在 RGB 輸入的時候有作用，它控制的是 Encoder 壓縮時 RGB -> YUV 要用哪一個轉換式，有壓縮或者無壓縮的版本。

所以 MainConcept MPEG Encoder 的這個選項的名字就取得很好，簡潔易懂，不像其他 Encoder 這個控制選項寫了半天你也不知道他在說什麼
MainConcept MPEG Encoder 的這個選項是這麼寫的："Input video is RGB16~235"，意即，如果輸入的資料是 RGB，而且是有壓縮過的、無伸張的RGB，資料範圍只有 16~235 的 RGB，請勾選這個選項。
如果輸入的不是 RGB，而是 YUY2，自然，這個選項就不用去管他

當輸入是 YUY2 的時候，Encoder 只是單純的把 YUY2 的 YUV 4:2:2 的資料重新取樣成 MPEG 用的 YUV 4:2:0 的資料，然後便開始壓縮。
然而前面有提過，同樣是 YUV 的資料，YV12，如果 Encoder 不接受這種格式的輸入，它就會去找系統上的 YV12 Decoder 解碼成 RGB 再讀取，此時 Input 就不是 YUV 了，而是 RGB。
RGB 的輸入 Encoder 最後壓縮時一定要再轉成 YUV 4:2:0 的格式，會經過 RGB -> YUV 的轉換，所以此時 Encoder 的 YC 伸張壓縮的控制選項就會又有作用。

YV12 Decoder 例如 XviD/DivX 在做 YV12 -> RGB 的時候都會做伸張，所以轉換後的 RGB 是 0~255 的 RGB。
一般軟體的 YUV -> RGB 也都會做伸張，在電腦上這是一般正常的做法，例如 Avisynth 的 ConvertToRGB24(), ConvertToRGB32() 也是。
一般軟體的 RGB -> YUV 都會做壓縮，在電腦上這是一般正常的做法，例如 Avisynth 的 ConvertToYUY2(), CovertToYV12() 也是。

一般 MPEG 壓縮軟體遇到 RGB 輸入，都會假設是伸張後的 0~255 的 RGB 輸入，所以預設用的 RGB -> YUV 轉換都會經過壓縮的過程，剛好配合，所以一般正常的情況下，什麼設定都不用改，直接壓縮就對了。
但是只有 ProCoder 特殊，也許是因為 Canopus 自家的 DV Codec 預設輸出的是無伸張的 16~235RGB，所以他的 Encoder 的 RGB -> YUV 轉換式，預設也是無壓縮的轉換，配合 16~235 的 RGB 輸入。
然而一般我們輸入的其他 RGB 訊源，通常都是伸張過的 0~255RGB，這樣一來就會不能搭配，而發生錯誤。
這是很多用 ProCoder 而且訊源是 RGB 輸入的人，沒有注意到的現象，只覺得奇怪 ProCoder 壓出來的色彩超鮮豔，但是有些失衡，而且因為對比增強的緣故，比較難壓，所以會覺得奇怪 ProCoder 壓出來的壓縮瑕疵很多，怎麼大家還會推薦

所以用 ProCoder 一定要注意，0~255RGB 輸入時，要加上 "601 Correction - Shrink Color Space" 這個濾鏡。

其他 Encoder 雖然也有這個 YC 伸張控制的選項，不過大多數的時候，都是不用改的，除非遇到特例的情況，例如前面提過的，Elecard-Moonlight MPEG Decoder v.3611 輸出的 RGB 就是無伸張的 RGB，此時 Encoder 就要做相對應的更改設定。

會不會寫得太複雜 ^^;;
每次都覺得寫這些好像沒有太大的意義.....

還有兩點要再重提一次，以加深印象的：
1. TMPGEnc 2.5 Plus 只接受 RGB 輸入，所以不管你是丟 YV12，還是 YUY2，最後都會轉成 RGB，所以不管什麼訊源輸入，他的 "Output YUV data as Basic YCbCr not CCIR601" 永遠都有作用。

TMPGEnc 3.0 XPress 才接受 YUY2 的直接輸入。

2. 除了 CCE SP v2.66 版以後支援 YV12 的直接輸入以外，其他 Encoder 都不吃 YV12 的輸入，會再去找系統上的 YV12 Decoder 來解碼 RGB 輸出。