如果照這樣來說...
是不是我應該在 AVS 交給 MainConcept MPEG Encoder 轉檔之前
就事先在 AVS 裡加入語法將 YV12 轉換成 RGB 比較好？
DivX/XviD Codec 充當 YV12 Decoder 出來的品質能夠信任嗎？
或是說還有其他更好的 YV12 Decoder？

不太能信任
我覺得 XviD/DivX 的 YUV -> RGB 品質很爛。

MainConcept MPEG Encoder 可以吃 YUY2，所以轉成 YUY2 就可以，也比較好，可以保持在 YUV 的色彩空間裡，不用經過 YUV -> RGB 的損失。
而且 RGB 的輸入，MainConcept MPEG Encoder 在壓縮時還是要轉換成 MPEG 記錄的 YUV 4:2:0 格式，所以還是要再轉換回 YUV，所以 AVS 將 YUV 轉成 RGB，最後 MainConcept 還是要再轉成 YUV，YUV > RGB -> YUV，這麼做實在多此一舉，而且會造成轉換的損失。
直接 YUY2 進去是最好的。

而且還有一點，如果是交錯的訊源，要保持 YUY2 的格式，色彩資訊才能保留完整正確的狀態，所以一般都只支援 YUY2 的格式。

真是太感謝 Shade 長輩了
以前以為只有轉 AVI 需要注意色空間
原來 TMPGEnc 以外的 MPEG Encoder 居然隱藏那麼多陷阱@@...

汗... 我是小輩.... @_@;;

這樣有超過十個字嗎？
多打一些灌水.... Avisynth 可以做一些有趣的處理..... 例如如果訊源太難壓，用 DVD 的流量限制怎麼壓都壓不好，可以故意把 Chroma 色彩的資訊弄模糊一點，但是比較重要的 Luma 亮度資訊則保留原來的解析度。這樣畫面清晰度不會損失太多，MPEG 壓縮又會比較好壓。例如 TMPGEnc 3.0 XPress 就有一個 Chroma Channel 的低通濾波（LPF）的功能，如果用 Avisynth 要如何做到只對 Chroma 做處理呢？

我們可以對 Chroma 做線性內插放大後再縮小，等於幫它做 LPF，Chroma 會模糊許多，但是會比較好壓。
例如原本畫面大小是 640x480 的話：
==
# 強迫 AVISource 吐出 YUY2
a=avisource("Baldr_Force_OP_A.avi",pixel_type="YUY2")
b=avisource("Baldr_Force_OP_B.avi",pixel_type="YUY2")

# 把兩段接起來
source=a+b

# 分別製作 U, V 的放大後再縮小的版本
u_chroma=source.UToY().BilinearResize(640,960).BilinearResize(320,480)
v_chroma=source.VToY().BilinearResize(640,960).BilinearResize(320,480)

# 把新的 U, V 覆蓋掉原本的 U, V
YtoUV(u_chroma, v_chroma)

# 合併 YUV 回原本的 source，令等於最後我們要輸出的 target
target=MergeLuma(source)

# 傳回 target
return target
==

以上的方法可以做其他的處理，例如 resize 的時候，我們想對 Luma 做 Lanczos3 Resize，保持銳利度，但是 Chroma 想用 Bilinear Resize，讓畫面好壓一點，或者單獨想對 Chroma Channel 做任何處理的時候，都可以用

剛剛正好要 AVI 轉 VCD...馬上測試此方法
結果開始壓之前居然有個問題想不透害我下不了手@@...

MainConcept MPEG Encoder 可以直接吃 AVS 輸出的 YUY2 沒問題...
可是這時候的 YUY2 有經過 Y/C 伸張過了嗎?
好像沒看到過程中有這個步驟?
但是 AVS 輸出 YV12 由系統上的 YV12 Decoder 來解碼，轉成它可以接受的 RGB 格式這過程中倒是有作
因為我嘗試有選 "Input video is RGB16~235"跟沒選顏色上差異很大(沒選是正確的)
但是直接吃 AVS 輸出的 YUY2 我試過選跟不選居然看不出來(汗

那到底該選還是不選呢?
同樣的狀況在 ProCoder 2.0 又是如何呢?

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


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 輸出。

先感謝一下！再吸收喔！
真可怕的人！說了一堆喔！
好棒喔！

不會不會...全部都懂:P
已經看習慣 Shade 長輩的文章...這次算最淺的XD
剛剛還跑去找以前您發的文章
http://forum.pcdvd.com.tw/showthrea...2&page=20&pp=10
突然發現全文都懂(驚)
記得當初第一次看才看懂一點點...認為很深奧(汗)
現在功力進步了看起來果然不一樣^^;

這個名字好像有點問題......
Y的範圍才是16~235，RGB要在Cb, Cr = 0的時候，範圍才是16~235。
如Y = 235, Cb(U) = 140 (+12), Cr(V) = 94 (-34)
跟據www.fourcc.org內的Basic YUV -> RGB的算式，
R = Y + 1.403 (V - 128)
G = Y - 0.34414 (U - 128) - 0.71414 (V - 128)
B = Y + 1.773 (U - 128)

R = 187.298
G = 255.15108
B = 256.276
轉成8-bit整數為
R = 187
G = 255
B = 255
已經超過235。


另外，XviD的YUV -> RGB的轉換式實在太爛了，Y是235的地方，也不是白色的，還有，內部應該是用8-bit/Channel的整數算式，運算的誤差很大，產生大量色塊。現在的CPU是32-bit的，用16-bit/Channel的算式比較好，因為速度沒有分別，但誤差降低。

近來看到的是關於YV12 -> YUV 4:4:4，nVidia的顯示卡是用n-Tap Resizer來進行這個步驟，所以一般的軟體的YV12 -> YUV 4:4:4的品質很難比得上硬體。