視訊相關知識收集

From: https://dream4ever.org/showthread.php?s=49841a470c8c86bcb84145db7b27090f&t=439

B 幀在 MPEG-4 中有四種參考模式，如果是同時參考前後的畫面壓縮，

則記錄的是 和 (前畫面 pixel 值 + 後畫面 pixel 值)/2 的內插補點，

也就是 和 「前後畫面的平均」的內插補點。

是以記錄的內插補點個數和 P 幀一樣，隻有一個，沒有增加。

而因為 B 幀位于前後畫面的中間，以「前後畫面的平均」，也就是「前後畫面的中間值」

來作為預測數值（預測 B 幀的 pixel 數值為多少？如果有誤差，再記錄內插補點），

這樣這個預測數值會比單獨使用前一個畫面來預測，更接近目前真正的 B 幀的數值，

可想而知，如此所需要記錄的內插補點就會很小甚至可以根本不用記錄，

是以便可以省下很多的 bits，提高壓縮率。

例如

亮度變化 ->

I B P

7 8 9

如果 B 隻參考前一個畫面壓縮，則需記錄內插補點 1。

如果以 (I + P)/2 壓縮，則內插補點為 0，不需記錄內插補點。

（雖然要記錄兩個矢量，不過矢量也可以再做進一步預測壓縮，總的來說，

還是會比單獨參考前一個畫面壓縮來得小很多）

如果畫面不是這樣變化怎麼辦？通常來講畫面都會是這樣變化，

如果不是這樣變化我們就不使用 B 幀

就算變化不是如此規則，換個方式想，B 幀可以參考的畫面還是比 P 幀多，

再怎麼找，也還是 B 幀可以找到誤差更小的方塊來使用的機率大

（因為可以選擇、參考的對象較多），是以 B 幀還是比 P 幀的壓縮率來得高。

（而且高很多，差距非常大）

除了壓縮率以外，B 幀對畫質的影響.....

是有的，因為 B 幀這種參考前後畫面的特性，等于有内插（interpolation）的效果，是以可以減少噪訊。

MPEG-4 中的 B 幀，也是非常具有威力的，除了以前的三種參考模式，

還有 Direct Mode，連矢量的紀錄都省了。

雖然 MPEG-4 之中有 4MV 的功能，可以記錄四個矢量，不過編碼器在壓縮的時候會判斷，

到底是使用 4MV 壓出來的結果小，還是使用傳統的方法壓出來的結果小？

如果使用傳統的方法壓出來的結果小，便使用傳統的方法記錄，

如果使用 4MV 壓出來的結果小，才使用 4MV 來記錄。

（ps. 4MV 不會用在 backward 預測）

您可以觀察 VirtualDub 壓縮時畫面上顯示的藍線，您會發現藍線和藍線之間通常會有很短的

藍線插在中間，造成空隙，而且差距很大，這個就是夾在 P 之間的 B 在發揮壓縮威力

如果是用 DivX 5 更明顯，因為 DivX 5 隻能夠使用 IBPBPBPB... 這種一個 B 接一個 P 的形式，

是以畫面上的藍線就是「一長一短、一長一短」這樣排列。

MPEG 儲存的 YU(Cb)V(Cr) 格式是遵循 CCIR601，也就是 ITU-R BT.601 的規範，Y 亮度的範圍是 16~235，UV(CbCr) 色度是以無色 =128 為中心，範圍是 16~240。

一般民生消費産品使用的 MPEG 壓縮，大都采用 YUV 4:2:0 的格式，也就是如果分辦率是 720x576，則每個 Frame，Y 有 720x576 個點，U 隻有 360x288 個點，V 也隻有 360x288 個點。色度的資訊隻有亮度的 1/4。那麼為什麼不寫 YUV 4:1:1（UV 和 Y 的比例是 1:4） 而要寫 YUV 4:2:0？這是因為要區分取樣的方式不同。YUV 4:1:1 是指水準 Y 取樣四個點，UV 各隻取樣一個點，水準的 Y 和 UV 的取樣比例是 4:1，也就是

Y Y Y Y 一個 U 一個 V ....

YUV 4:2:0 是指水準和垂直 Y 各取樣兩個點，UV 各隻取樣一個點，水準的取樣比例是 2:1，重直的取樣比例 2:1，也就是

Y Y

Y Y 一個 U 一個 V ....

和 YUV 4:1:1 一樣，色度和亮度差 1/2 * 1/2 = 1/4，隻是取樣的方式不同。

而 MPEG 最常采用的 YUV 4:2:0 格式，其 UV 的取樣位置，MPEG-1 和 MPEG-2 又不同（MPEG-4 是用和 MPEG-2 一樣的取樣位置）

MPEG-1

x 是 UV 的取樣位置

MPEG-2

x 是 UV 的取樣位置

了解了 YUV 4:2:0 以後，我們來看什麼是 YV12，什麼是 YUY2。

在個人計算機上，這些 YUV 讀出來以後會以一些格式包裝起來，送給軟體或硬體處理。包裝的方式分成兩種，一種是 packed format，把 Y 和相對應的 UV 包在一起。另一種是 planar format，把 Y 和 U 和 V 三種分别包裝，拆成三個 plane（平面）。

其中 YV12 和 YUY2 都是一種 YUV 的包裝格式，而且兩種都是 packed format。

YV12 和 YUY2 的不同，在于 YV12 是 YUV 4:2:0 格式，也就是 DVD/VCD 上原本儲存的格式。YUY2 則是 YUV 4:2:2 格式，也就是

Y Y 一個 UV Y Y 一個 UV ....

水準取樣比例是 1/2

重直取樣比例是 1/1，也就是垂直 UV 和 Y 的個數一樣多

以分辨率來講，就是 Y 720x576 U 360x576 V 360x576。

至于詳細的包裝格式，這裡就不畫圖了，請參考

http://www.fourcc.org/fccyuv.htm

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp

以 DVD/VCD 的播放來說，讀出來的 YUV 4:2:0 包成 YV12 的格式，如果顯示卡有支援 YV12 的 FourCC Codec，播放時就會直接走 DirectDraw YV12 Overlay，直接丢 YV12 的資料給顯示卡處理，由顯示卡去做 YUV 4:2:0 展開（内插補點）-> YUV 4:2:2 -> YUV 4:4:4 -> RGB32，也就是色彩空間轉換的的工作。如果你的螢幕分辨率大于影片原始分辦率，顯示卡還要做 scaling，也就是放大畫面的動作，将影片的分辦率放大到和你的螢幕的分辦率相同，例如 640x480 -> 1024x768。（内插補點，補出不足的點）

是以顯示卡的 YUV 4:2:0 -> 4:4:4 内插補點的好壞第一個就影響 MPEG 的播放品質，如果顯示卡的 interpolating filter 不好，色彩補得不夠平滑，紅色的部分（人眼對紅色較敏感，特别容易看出）就會出現一格一格的鋸齒狀。

再來就是顯示卡的 scaling filter，放大補點的好壞，放大補點不好，畫面就容易出現鋸齒或是變得模糊不夠清晰。

YV12 是最多顯示卡支援的格式，傳輸的資料隻有 YUV 4:2:0，比 RGB32 少很多，速度最快，是以大部分的軟體都用這種格式傳送資料。然而這種格式在遇到 interlaced 場線交錯的畫面的時候，會發生色度譯碼錯誤的問題。這個問題說起來很複雜，再講個這篇文章又會太長，有興趣的人可以參考 DVD2AVI 作者的網頁，他有詳細的說明，這個譯碼錯誤的問題也是他撰寫 DVD2AVI 這個軟體的原因:

The decoding problem with interlaced frame of most software MPEG-2 decoders

http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/

另一種錯誤，發生在 progressive frame 上

http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html

這個說起來太長，有機會我再解釋。

另一種常見的格式，就是 YUY2，也有許多顯示卡支援，PowerDVD 為了解決上述的交錯線彩色資訊譯碼錯誤的問題便是使用這種格式。YUY2 也就是 YUV 4:2:2 的一種包裝形式，播放時軟體會先自己做 YUV 4:2:0 -> YUV 4:2:2 的内插補點（upsampling），做好以後再将 YUV 4:2:2 包成 YUY2，走 DirectDraw YUY2 Overlay，直接丢資料給顯示卡，由顯示卡去做後續的 YUV 4:2:2 -> 4:4:4 -> RGB32 的工作。

我們再來看顯示卡的 DirectDraw Overlay 什麼時候會啟動，這個很重要，因為由以上可知，如果不使用 DirectDraw Overlay，而走傳統的 GDI（Graphic Display Interface）圖形顯示接口，顯示速度會很慢

1. 無法使用 DirectDraw 硬體加速，無法使用硬體的内插補點和色彩空間轉換，CPU 負擔非常重

2. 直接傳送 RGB32，資料量大。無法使用顯示卡的 scaling/interpolating filter，放大到全螢幕，會鋸齒方塊一格一格的非常難看。

是以 DirectDraw Overlay 有沒有啟動非常重要，現在大部分的顯示卡，即使在高分辦率的時候，DirectDraw Overlay 還是會啟動，尤其是 ATI 的顯示卡，即使在超高分辦率的時候還是可以啟動。

但是大部分的顯示卡都有一個限制，那就是影片的分辦率，水準的點數必須能被 32 整除，這樣才能使用 DirectDraw Overlay。是以 GKnot 的 resize 選項，水準部分會有一個 32 Mod（能被 32 整除）的限制，就是這個原因。由上述可知，720 的水準分辦率不能被 32 整除，是以會有無法啟動 DirectDraw Overlay 的危險，為了最大的相容性，制作的影片水準分辦率最好是能夠被 32 整除。

附帶一提，垂直高度最好是能夠被 16 整除，因為 MPEG 壓縮是以 16x16 的巨方塊為機關壓縮，不是 16 的倍數的高度會制造壓縮困難，壓縮後可能會出現壓縮瑕疵。

最好是先做好 resize 再壓縮，不要以原始的分辦率 720x576 壓縮，播放時才調整比例作實時 resize。

實時 resize 的效果無法和慢慢計算的高品質 resize 相比，畫質會比較差，本來是想保留較多的原始訊息，結果播放時的 resize 不好，反而得不償失。

提到 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，即使選 Fast recompress，VD 還是會将 YV12 的輸入轉為 YUY2，是以要得到全程 YV12 處理的好處，必須使用 VirtualDubMod 這個軟體才行，這個改版才有支援 YV12（一樣要選 Fast recompress）。

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

因為前面提到了 YUV 的數值範圍（Y: 16~235, UV: 16~240），之前 Doom9 上也有一篇 Lumi masking 的文章在讨論這個，不過.....，是以我順便轉貼以前寫的一篇文章給大家參考：

引用

DVD/VCD/DV 等使用的 MPEG/MJPEG 壓縮，記錄的 YCbCr 格式，是遵循 ITU-R BT.601 的 規範，其資料範圍（動态範圍）為 Y（亮度）16~235，C（色度）以 128 為中心代表無色 ，範圍 16~240。 做處理和顯示的時候，YCbCr 要轉為 RGB，其範圍為 16~235。 但是計算機螢幕上，純白的點，其 RGB 值為 (255,255,255)，純黑的點， 其 RGB 為 (0,0,0)。是以 MPEG/MJPEG 所記錄的純白 (235,235,235) 在計算機螢幕上看起 來就不是純白，純黑 (16,16,16) 在計算機螢幕上看起來也不會是純黑。 是以 DV 錄下來的東西，拿到計算機上看，會覺得顔色變淡，好像照上了一層白紗。 同時因為資料範圍（動态範圍）縮小為 16~235，而不是全範圍（Full Scale）0~255， 是以會覺得對比不足（最亮和最暗的差距縮小），不如在電視上看漂亮。 是以在計算機上看、編輯 DV AVI，必需要先做 Y/C 伸張，也就是将 Y/C 的動态由原來的 16~235 擴充到 0~255，然後轉為 RGB 0~255，這樣在計算機螢幕上看到的顔色才會是正确的 。以此為基準作顔色校正、各種濾鏡處理，出來的結果才會是正确的。 經過 Y/C 伸張以後，然後才作各種的編輯。 最後要壓成 DVD/VCD/DV 的時候，因為仍然是存成 MPEG/MJPEG 格式， 資料範圍還是 16~235，是以已經做過 Y/C 伸張的影像在壓縮之前，必須先做 Y/C 壓縮， 把目前 RGB 0~255 的資料壓縮為 16~235，然後轉為 YCbCr 16~235，這樣才會正确。 不然超過的資料在轉為 YCbCr 16~235 的時候會被削掉（clipping）， 對比、顔色會完全錯誤。 如果沒有編輯、修改畫面的必要，隻是要将 DV AVI 直接做成 DVD/VCD， 則可以不必做 Y/C 伸張，直接壓縮為 DVD/VCD。 此時資料沒有做過 Y/C 伸張，是以壓縮的時候，不可以再做一次 Y/C 壓縮然後壓 MPEG， 否則做好的 DVD/VCD 即使在電視上播放，對比、顔色也會是錯的。 總結： 原始資料以 MPEG/MJPEG 儲存，為 Y/C 壓縮過的資料， 修改編輯時需先做 Y/C 伸張之後再修改。 若做過 Y/C 伸張，壓縮時需做 Y/C 壓縮，出來的畫面才是正确的。 若沒做過 Y/C 伸張，壓縮時不可以做 Y/C 壓縮，出來的畫面才是正确的。 以 TMPGEnc 這個壓縮軟體為例，壓縮時預設是接收 0~255 的 RGB 資料， 先做 Y/C 壓縮，然後才壓 MPEG。 是以如果是 YCbCr 16~235 的資料要對畫面做修改，必須使用 Descale CCIR601 這個濾鏡 （CCIR601 就是 ITU-R BT.601，CCIR 是 ITU 以前的名字），把 Luminous, Chroma 兩個 選項都推到 255（也就是做 Y/C 伸張），然後才做其它的編輯動作。 Descale CCIR601 的順位要排第一位。 然後壓縮時直接壓縮便可以得到正确的結果。 如果沒有要對畫面做修改，則不必做 Y/C 伸張，但是壓縮的時候必需要勾選 進階設定--> 量子化行列（Quantize matrix）底下的 "Basic YCbCr ?出力" （Out YUV data as Basic YCbCr not CCIR601），這樣 TMPGEnc 壓縮時便不會 做 Y/C 壓縮，壓出來的顔色、對比才會正确。 總結： 如果原始資料是 YCbCr 16~235 有做 Y/C 伸張的話，壓縮時直接壓縮就好，不能勾選 "Basic YCbCr ?出力"。 沒有做 Y/C 伸張的話，壓縮時必須勾選 "Basic YCbCr ?出力"。 再以 Cinema Craft Encoder SP 這個壓縮軟體為例，設定選項的 "16 ??235" = TMPGEnc 不勾選 "Basic YCbCr ?出力" = 壓縮時先做 Y/C 壓縮 "0 ??255" = TMPGEnc 勾選 "Basic YCbCr ?出力" = 壓縮時不做 Y/C 壓縮 實際上 CCE SP 是用兩個不同的 YUV <--> RGB 轉換式，列在下面給有興趣的人參考： "16 ??235" "0 ??255" 而 YC 伸張的計算式是（簡略） Y' = (Y - 16) * 255 / (235 - 16) C' = C * 255 / (255 - (240-16)) 再來探讨兩個問題，第一個是 DV Codec 在輸出資料給壓縮軟體時，可能會輸出兩種格式 ，第一種是直接輸出 YUV 4:1:1，由壓縮軟體自己去做 YUV --> RGB 的轉換。 第二種是由 Codec 内部先做 YUV --> RGB 轉換，再輸出 RGB 給壓縮軟體。 如果 Codec 是輸出 YUV 4:1:1，則轉換後的 RGB 範圍是 0~255（有做 Y/C 伸張） 還是 16~235（沒做 Y/C 伸張），由執行轉換的壓縮軟體決定。 如 TMPGEnc 的環境設定的選項中，有針對 Canopus DV Codec 做設定，提供你選擇， YUV --> RGB 轉換時，要用哪一種轉換式。有三種，Basic YCbCr，CCIR601，YUV。 如果是由 Codec 做轉換，輸出 RGB，則是否做伸張由 Codec 決定。 不同 Codec 有不同作法，是否有做伸張必須要做實驗才能确定。 如果 YUV --> RGB 時已經做過伸張，則 RGB 資料已經是 0~255 的範圍， 就不可以再用 Descale CCIR601 濾鏡，否則會有許多資料破表被削掉，切記。 第二個問題，壓縮軟體壓縮時，是否會先做 Y/C 壓縮？ 如 MS MPEG-4 Codec，DivX Codec，XviD Codec 這幾個 Codec 都是假設收到的資料是 0~255，會先做 Y/C 壓縮的動作。那麼其它 Codec 和壓縮軟體呢？ 這個也必須要做實驗确認才能确定。 唯有解壓縮和壓縮的轉換式能正确搭配（做過 Y/C 伸張壓縮時就必須做 Y/C 壓縮， 沒做 Y/C 伸張壓縮時就不可以做 Y/C 壓縮）最後壓出來的成品才會是正确的。

補充一

DVD2AVI 的 Color Space 選 RGB/YUV 和 PC Scale/TV Scale 的差異

RGB 模式是輸出 RGB24，YV12 (YUV 4:2:0) --> YUY2 (YUV 4:2:2) --> RGB24，

由 dvd2avi 做内插展開（4:2:0 -> 4:2:2）和轉換的工作（YUV -> RGB）。

内插展開的算式作者的網站有寫，相當于 6-tap 的 FIR Filter。

YUV 模式是輸出 YUV 4:2:2（YUY2）。

輸出 RGB 時，preview 顯示會走傳統的 GDI 圖形顯示接口，送 RGB24 的資料給顯示卡，

此時計算機螢幕上看到的顔色正不正确，由 YUV -> RGB 這個選項決定。

（要選 PC Scale 看到的顔色才會正确）

輸出 YUV 時，preview 顯示會走 DirectDraw YUY2 Overlay，直接送 YUY2 的資料

給顯示卡，由顯示卡去做展開和色空間轉換。顯示卡用的都是 PC Scale

（會做 Y/C 伸張，擴充原來的 16~235 的資料為 0~255），是以您可以在螢幕上

看到正确的顔色。

（同理，DVD/VCD 播放時，播放軟體會走 DirectDraw Overlay 丢 YUY2 或 YV12

的資料給顯示卡，由顯示卡來做展開、色空間轉換、和放大（scaling filter）的工作。

由于顯示卡用的是 PC Scale，會做 Y/C 伸張，是以您才可以在計算機螢幕上看到正确的

DVD/VCD 的顔色）

（前提是，做好的 DVD/VCD，其 YUV 4:2:0 的資料範圍必須是 16~235，

經過顯示卡 PC Scale 16~235 -> 0~255 才會正确。

如果 DVD/VCD 做錯，壓縮前沒有先做 Y/C 壓縮，儲存的是 0~255 的 YUV 資料，

則顯示時再經過顯示卡的 Y/C 伸張，會發生 clipping（資料超過範圍被削掉））

（而 16~235 的資料拿到電視上放，電視本來就吃 16~235 的資料，

是以顯示也是正常的）

（是以結論，DVD/VCD 上的資料，必須遵照 CCIR601 的規範，維持 16~235 的範圍）

至于輸出，也是按照 YUV/RGB 的設定，分别輸出 YUY2 和 RGB24。

但是如果您有用 vfapi，因為 vfapi 内部完全以 RGB24 傳送資料，

是以如果你把 .d2v 轉成 vfapi-ref-avi，即使 color space 選 YUV，

dvd2avi 也會做展開轉換成 RGB24 輸出。如果要用 dvd2avi 直接做 Y/C 伸張，

dvd2avi 的 YUV -> RGB 選項勾選 PC Scale 即可。

另外，如果用 TMPGEnc/AviUtl 直接開啟 .d2v，因為這些軟體還是以 RGB24

讀取，是以 dvd2avi 也還是以 RGB24 輸出。

那.... 倒底什麼時候會用 YUY2 輸出？

直接存 AVI 的時候... ^^;

是以如果您是用 vfapi 或用 TMPGEnc/AviUtl 讀取，選 YUV 或 RGB 都沒有差異。

附帶一提 ^^; 如果 dvd2avi 輸出時已經選了 PC Scale（有做 Y/C 伸張），

就不可以再用 TMPGEnc 的 Descale CCIR601 這個濾鏡，也不可以用

AviUtl 的 "ITU-R BT.601 補正"，這兩個作的事情是一樣的，都是做 Y/C 伸張。

已經伸張過再做伸張，會有許多資料 clipping。

補充二

XviD 使用的 RGB -> YUV 算式

由 source code 可以得知，XviD 和大部分的軟體一樣是遵照這本書的标準轉換式作的

http://www.video-demystified.com/book1/index.htm

算式為

Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16

Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128

Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128

此算式等于上述 CCE SP 的第一個算式，也就是假設收到的是 0~255 的 RGB 資料，會先做 Y/C 壓縮，然後才壓 MPEG。

我自己本來也不懂，後來是因為 DVD2AVI 的作者教我，我才明白其中的來龍去脈。

（當然，如果有錯，也是我的了解有誤，和 DVD2AVI 的作者無關 ）

（DVD2AVI 的作者實在非常非常非常的厲害，有許多道理都是他研究出來再教給大家的。譬如說 NTSC 4:3 的 DVD，720x480 的分辦率，要先左右共削掉 16 個點，變成 704x480 再 resize 成 640x480/512x384 ... 才是正确的比例，這個道理便是他研究發現的，然後再教給 GKnot 的作者 TheWEF。GKnot 有個選項叫 "Follow ITU-R BT.601 Standard"，選了這個選項 GKnot 便可以遵照 ITU-R BT.601 的标準，做正确的 resize。唯有按照 ITU-R BT.601 的規範做 resize，resize 後的比例才是正确的，GKnot 變成唯一可以幫你計算正确 resize 方法的軟體，其它軟體的 resize 亂七八糟都是錯的。而 GKnot 之是以知道正确的作法，就是因為 DVD2AVI 的作者 jackei 教的）

（PAL 同樣要遵循 ITU-R BT.601 的規範，至于正确的作法我沒有研究，有需要的人可以利用 GKnot 幫忙計算正确的 resize 作法）

（關于 ITU-R BT.601 和正确的比例如何計算的原理，說起來很複雜，有機會我再解釋 有興趣的人可以參考 http://www.uwasa.fi/~f76998/video/conversion/。

.....簡單的說，因為 DVD 取樣記錄的時候，取樣的點之間的長寬比，Pixel Aspect Ratio，也就是 PAR 不是 1:1。而我們個人計算機的螢幕上 Pixel 和 Pixel 之間的長寬間距都一樣，也就是 PAR 是 1:1，也就是正方形的 Pixel，Square Pixel。是以 resize 的時候，不能直接從 DVD 的原始分辦率 resize 至目标的比例，如 4:3 or 16:9，而要做一些處理。通常來講，要左右削掉一些 Pixel，轉換後的比例才正确。例如 NTSC 720x480 16:9 squeeze 的影片要 resize，正确的作法要左右共削掉 16 個點，變成 704x480 再 resize 至 704x396(16:9) 才是正确的比例。然而 704x396 的高度 396 不能被 16 整除，不利于 MPEG 壓縮，是以我們再上下各補 2 個點，補上黑邊，補成 704x400 之後再送進去壓縮。因為 AVI 這種格式沒有紀錄 DAR，Display Aspect Ratio，播放時的比例的資訊，是以播放軟體播放時不知道正确的播放比例應該是多少，是以制作時就要先設計好正确的長寬比例，如上例中的 704x396(16:9)。您可能會疑惑可是最後我們為了壓縮需要又補了四個點上去，變成 704x400，這樣就不是 16:9 了啊。沒錯，704x400 不是 16:9，但是因為補上去的多餘的點是黑邊，是以即使放大到全螢幕，比例還是正确的 16:9，多出來的黑邊不影響畫面中央有影像部分的正确比例。有點抽象，要好好想一下才能明白其中的道理 ^^;）

糟糕，我又扯遠了

上述的那個網頁，最後有一段問答，我覺得很有意思，轉過來給大家看：

4.4 I have been doing digital video projects for the last 50 years. I know my stuff! If you were correct, everything I have done to process my precious video has always been wrong, aspect-ratio wise!

That may very well be the sad truth. Fortunately, even if you had used wrong methods for scaling/resampling the image, the difference between the correct aspect ratio and a wrong aspect ratio is often small enough to go unnoticed unless you really start looking for it.

4.9 This is really scary and nasty stuff. I thought digital video was simple! Now my head hurts!

But that's just the way video is. Fortunately, the conversions are not really that complicated once you practice them a little.

雖然道理很複雜，不過我覺得這很重要，是以才提出來和大家讨論。

譬如說當我看到 TMPGEnc vs. CCE SP 的壓縮測試，測試說 TMPGEnc 壓出來的顔色比較鮮豔，CCE SP 的顔色比較黯淡，我第一個就會想到，測試時 TMPGEnc 和 CCE SP 的 Y/C 伸張/壓縮 的設定是什麼？兩者的設定是否相同？如果兩者的設定不同，則出來的顔色表現不同是當然的。

或者說 TMPGEnc 的畫面較模糊，CCE SP 的畫面較清晰，我就會想到，TMPGEnc 的 resize 方法是用「平均像素法」，這種 resize 法的畫面本來就較模糊，但是對低碼率的 VCD 來說，這樣比較好壓。模糊是 resize 造成的結果，和壓縮無關，如果真的要比壓縮編碼的效果，應該用别的軟體先做好 resize，譬如說用 Avisynth 的 lanczos3 先做好 resize，再送進去給 TMPGEnc/CCE SP 壓縮，這樣比較才有意義。

是以知道這些原理還是有它的用處的。

至于采集卡，小弟使用的經驗不多，是以無法提供建議 ^^;;

采集卡應該要遵循 ITU-R BT.601 的規範，YUV 的範圍應該在 16~235 之間，是以必須做 Y/C 伸張。但是實際上各家的采集晶片不一定會完全依照 ITU-R BT.601，事實上 ITU-R BT.601 也沒有強制 Y/C 一定要在 16~235 之間，超出一點是可以的，這個設計本來有很大的一個原因是因為 MPEG 壓縮後資料不會和原來一樣，可能會超出一點，事先規範壓縮前的 YUV 在 16~235 之間可以預留一些空間（低于 16 和高于 235），給壓縮後超出的資料使用。

譬如說新出的 SAA7134HL 和 CX23881 晶片，SAA7134HL 的 scale（範圍）是 15~235，CX23881 則是 0~255，不用再作 Y/C 伸張。是以 CX23881 采集下來的畫面看起來比 SAA7134HL 鮮豔非常多，不知道的人還以為 SAA7134HL 很爛，顔色很黯淡。

請看這個網頁的比較圖檔

http://anipeg.yks.ne.jp/topic.html

一般來說要确認自己的采集卡的動态範圍，好知道後續要做什麼樣的色調補正處理，必須從外部生成一個标準的 ColorBar，色彩條，也就是上述那個網頁的第一個圖，作為輸入，看看采集後的顔色和原來相差多少，用 PhotoShop 或 AviUtl 之類的軟體看 RGB 的數值。ColorBar 的每個色條有固定的 RGB 值，用 Avisynth 的 colorbar 指令便可以生成一個 ColorBar。

同樣能量的光線人眼看起來 綠色亮度 > 紅色亮度 > 藍色亮度，

MPEG YUV 4:2:0 取樣，Y 的情報量是 UV 的四倍。

Y 定為 Y = 0.299*R + 0.587*G + 0.114*B

綠色占的比重大，Y 的情報量又最多，是以綠色的分辨率比其它兩種顔色好。

其次敏感的紅色情報量不如綠色，是以一旦 YUV 4:2:0 -> 4:4:4 内插展開不夠平滑，

人眼很容易就會看出瑕疵。

可以看繁體中文的話，參閱「紅色的地方有鋸齒」

http://bbs.irradiance.net/txtVersion/treasure/animation/M.935070924.A/1-15

Nandub 的 Anti shit，不是在增進畫質，相反的，它是在減低畫質。

我們知道，Quantizer 越高，畫質越差；Quantizer 越低，畫質越好。

Nandub 每壓完一個 Frame，就會計算這個 Frame 的品質（PSNR，Peak Signal to Noise Ratio，比較壓縮前的畫面和壓縮後的畫面，兩者之間的差異有多大，機關是 dB。PSNR 越高越好，代表差異越小），如果 PSNR 低于你設定的 Anti shit 的 dB 數，Nandub 就會提高 Quantizer 重新壓縮這個 Frame，直到畫質超過你設定的 PSNR 為止。（Nandub 把 Quantizer 稱為 Compression Level，簡稱為 CL）

等等，不是說 Quantizer 越低畫質越好嗎？怎麼 Nandub 反而是提高 Quantizer 重新壓縮呢？這是因為 Nandub 壓縮使用的 MS MPEG-4 V2/V3，也就是 DivX 3.11 Codec 有一個 bug，當 Quantizer = 2 or 3 的時候，畫面上高反差的區域（亮度對比強烈的地方，譬如說黑白的交界處），會出現一種灰白色方塊的壓縮瑕疵，英文叫做 luma-inverted block（亮度颠倒的方塊，原本黑色的部分變成白色，原本白色的部分變成黑色），看起來很明顯，而且很醜。這在壓縮一般的電影影片時可能還不太明顯，但 是遇到色彩鮮豔、對比強烈的動畫影片時，這個壓縮瑕疵可以說是滿天飛舞，讓人根本看不下去。

這個瑕疵，Nandub 的作者把它稱為 shit

Anti shit 的作用就是在 Anti（反）這個瑕疵。

為了解決這個 bug，日本和歐美各自發展出不同的方法。日本用的工具叫做 M4C，它的方法是壓縮的時候偵測畫面上是否出現灰色方塊，如果發現有灰色方塊，就把那張畫面重新壓縮為 keyframe，這樣就可以解決這個問題。（MPEG-4 V2/V3，DivX 3.11 的 keyframe 的預設值，最低隻能用 Quantizer 4x，除非你用 Nandub 修改這個設定。是以改成 keyframe 壓縮，等于提高 Quantizer，也就解決了這個灰色方塊的 bug。但是缺點是會插入太多 keyframe 花費碼率，而且 keyframe 的 Quantizer 隻有 4x，品質很差，一插 keyframe，畫面很容易都是晶格狀的方塊，看起來也很醜）

Nandub 用的方法則是，計算畫面上品質最差的方塊的 PSNR（不是整體的 PSNR，1st-pass 的時候 debug view 裡面會顯示 PSNR=43.38(30.46)，前面那個是整體的 PSNR，後面括号中的數字才是最差品質方塊的 PSNR），當這個數值低于 Anti shit 設定的 dB 數時，Nandub 會認為代表畫面出現 shit（灰色方塊），Anti shit 便會啟動，将這個 Frame 重新提高 Quantizer 壓縮。提高 Quantizer 壓縮，雖然畫質會變差，但是因為 Quantizer 高于 2 or 3，可以解決灰色方塊的問題。當提高 Quantizer 也無法解決問題時（最差品質方塊的 PSNR 沒有改善），Nandub 便會試着再将這個 Frame 重新壓縮為 keyframe，并且繼續提高 Quantizer 試試看。

您可以參考這個網頁，搜尋 luma-inverted block 這個字元串，看看那一段的說明

http://www.undercut.org/Nandub_OnePass/

或是看 Nandub 附的 readme 說明檔，搜尋 luma-inverted block 這個字元串，

裡面作者都有詳細解說這個選項是做什麼用的。

是以 Anti shit 這個選項不是了提高畫質，而是為了避免灰色方塊這個 bug，是以不得以設計出來的機制，其實它是提高 Quantizer，反而會破壞畫質。

至于 DivX5, XviD 都沒有這種 bug，是以當然不用這種設計。它們會很自然的根據碼率，決定這張畫面要給多少品質。

Nandub 的這個 Anti shit 有一個 bug，那就是如果畫面最差品質的方塊，其 PSNR 低于 Anti shit 的 dB 值，原因不是因為灰色方塊的關系，而是因為這個畫面本來就很難壓而壓不好，那麼 Nandub 即使提高 Quantizer 重新壓縮，也無法解決這個問題，反而會因為 Quantizer 更高，畫質更差，PSNR 更低，造成程式無窮循環，Nandub 反複不停地提高 Quantizer 重壓，直到最高的 31x 為止。接着 Nandub 又會試着再把這個 Frame 重新壓成 keyframe，但是這裡 Nandub 的程式寫錯，造成 keyframe 的 PSNR 計算錯誤，這個 keyframe 又會反複一直提高 Quantizer 壓縮，直到最高的 31x 為止才跳出循環，結果我們最後就會得到一張 Quantizer 31x 的 keyframe

畫面非常慘。

不是每個人都會遇到這種情況，如果你壓的是動畫，Anti shit 的值又設得很高（> 21dB），那麼就很容易發生這種現象。這個在國外讨論區以前常有人問，大家都不明白這是為什麼，不信您可以上 Doom9 讨論區搜尋 31x keyframe 等關鍵詞，相信一定可以找到類似讨論。

是以結論就是，Nandub 的 Anti shit，真的是 shit ...

電影原本是 24fps 的，在膠卷過帶（Telecine）的時候，NTSC 制會經過 3:2 pulldown 轉為 30fps。

也就是原本 1 2 3 4 四個 Frame，拆成 1o 1e 2o 2e 3o 3e 4o 4e，每個 Frame 拆成奇數掃瞄線組成的奇數圖場（Odd Field）和偶數掃瞄線組成的偶數圖場（Even Field）。重新組合如下（以 Odd Field First 的順序）

1o 1e - 2o 2e - 2o 3e - 3o 4e - 4o 4e

[ A ] - [ B ] - [ C ] - [ D ] - [ E ]

每兩個 Field 再重新組合成一個 Frame，就變成 [A][B][C][D][E] 五張 Frame。這樣由原本的 4 張變成 5 張，4*6 = 24 => 5*6 = 30，就能從 24fps 轉為 30fps。

在電視上看，電視因為是交錯顯示，是以看不到交錯線。但是在計算機上看，計算機螢幕是循序顯示，是以中間的 2o 3e -3o 4e 這兩張 Frame 中的 Field 分别來自不同的 Frame，一起顯示的話就會看到交錯的現象。

DVD 壓縮的時候，母帶是膠卷過帶（Telecine）後的 30fps，但是我們知道，其實原本的影片是 24fps 的，這 30fps 其實是從 24fps 轉出來的，中間有不必要重複的 Field。這些重複的 Field 會造成交錯，使得每 5 個 Frame 中就有 2 個 Frame 交錯（名言：每五張爛兩張），這些交錯的畫面要壓縮不但浪費空間，而且交錯畫面又難壓縮，會使得壓縮的效果很差。

是以先進的 DVD 壓縮制程，在壓縮時都會使用 IVTC（inverse telecine，反膠卷過帶），将 30fps 轉回 24fps，這樣壓縮的畫面張數由 30fps 減少為 24fps，少了 20%，等于 Bitrate 增加 20%，而且畫面無交錯容易壓縮，是以壓出來的畫質會好很多。

但是 IVTC 檢出不一定能做到 100%，遇到無法檢出、判斷的部分，Encoder 還是會以原本的 30fps 來壓縮。是以我們會看到有些 DVD，是 Film（24fps）和 NTSC（30fps）混合的 DVD，又叫做 Hybird（混合）的 DVD，這個意思就是說，這張 DVD 内的畫面，是 24fps 無交錯，和 30fps 有交錯兩種型态互相混合的。

通常 RC1 八大電影公司出的 DVD IVTC 率都很高，幾乎都高達 99% 以上，但是其它的公司出的 DVD 就不一定有這麼高的比例。IVTC 100% 的 DVD 代表這張 DVD 内完全以 24fps 壓縮，那麼在 30fps/60 field/s NTSC 制的電視機上要播放時，要怎麼播放呢？這些 DVD 在壓縮的時候，Encoder 會寫入一個 Flag（旗标）的資訊，叫做 Repeat First Field，簡寫為 RFF。根據這個 RFF，DVD 機播放的時候，就會知道哪些 Field 要重複輸出，利用重複輸出這些 Field，DVD 機就會再播放的時候，做上面提過的 3:2 pulldown 的動作，在播放的同時，将 24fps 轉為 30fps 輸出，這樣就能在電視上正常收看了。

PAL 制則不一樣，膠卷過帶時是采用 2:2 pulldown，也就是仍然輸出原本無交錯的 Frame，但始将播放速度加快 4%，聲音也一起加快 4%，提升為 25fps，是以理論上來說，PAL 很好處理，因為畫面根本無交錯，是以直接壓縮即可。不過我在這裡看到有朋友提到，PAL 的 DVD 還是有些是交錯的，這點我就不明白是為什麼了，可能是制作過程上有問題吧。（譬如說用 DV 去拍的影片，DV 大部分是交錯式拍攝，張張都交錯，是補不回來的）

DVD2AVI 的 Force Film，所作的處理，和 TMPGEnc 的 IVTC 不一樣。TMPGEnc 的 IVTC 是跑一遍分析畫面的資訊，計算每一張畫面的「奇數掃瞄線和偶數掃瞄線的差異」和「動态」這兩個資訊，藉由這些資料，推測出原本的 24fps 的順序，将畫面反轉回原本的 24fps。因為需要分析、計算這些資料，是以跑第一遍的時候花的時間要比較久。而 DVD2AVI 則完全不一樣，DVD2AVI 是根據上面提到的 RFF 這個旗标的資訊，将重複的 Field 删除掉，直接原封不動的輸出 DVD 内原本儲存的 24fps 的 Frame。因為隻是做這樣的判斷，是以速度很快，存 .d2v 檔時一下子就存好了。所如果這部 DVD 在壓縮時的 IVTC 率很高，Film 的比例高達 95% 以上，内部原本就是儲存 24fps 的形式，這樣才可勾選「Force Film」這個選項。如果該 DVD 的 IVTC 率很低，内部大部分是 30fps 的形式，選「Force Film」輸出，你會得到亂七八糟的結果。是以在使用「Force Film」這個選項之前，必須先用 Preview 預覽一次，讓 DVD2AVI 跑一小段試試看，這部 DVD 的 IVTC 率究竟有多高，如果 Film 的比例很低，那麼就不可以使用 Force Film 輸出。

另外如果是 PAL 制的 DVD，更不可以開 Force Film，否則 DVD2AVI 會每五張砍掉一張，原本 25fps 會變成 20fps，畫面會錯得離譜。PAL 的畫面就是原本電影無交錯的畫面，不需要做 IVTC，如果你的 PAL DVD 有怪異的交錯，那麼我猜測它的訊源一定是非""正規""的訊源（例如 DV），才會發生這種現象。遇到這種情況你應該作的是 Deinterlace，而不是 IVTC。

DVD2AVI 的 Force Film 和 TMPGEnc 的 IVTC，兩者的作法和使用的時機都不同，使用者要自己判斷該用哪一種方法。如果有人拿 Film 率很低的片子用「Force Film」輸出，得到慘不忍睹的結果，然後怪 DVD2AVI 的 "IVTC" 爛，那真是冤枉了 DVD2AVI 的作者。這些觀念在作者的網頁上都講得很清楚。

http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/doc/issue.html#videotype

節錄當中的一段：

Forced FILM is based on RFF detection and frame decimation/duplication.

NTSC or PAL + Forced FILM ON -> garbage

FILM + Forced FILM ON -> synchronous 23.976 fps flawless FILM (equals to IVTC)

作者說，Force Film 是根據 RFF 旗标偵測和删除重複的 Frame。

NTSC（30fps）或者是 PAL 的訊源，如果開了 Force Film，得到的東西會是 garbage，垃圾。

Film 的訊源開 Force Film，才會是同步的 23.976fps，無錯誤的 Film 影像（equals to IVTC，等于做 IVTC）。

作者已經說得這麼清楚了，就請大家要有正确的觀念，不要再冤枉他了

幫 DVD2AVI 的作者申申冤

DVD2AVI 顯示的 Frame Type = Interlaced 的資訊，不是表示這張畫面是否交錯，DVD2AVI 根本不會去分析、判斷畫面上是否有交錯。這個 Frame Type 的資訊是根據儲存在 DVD 内的一個旗标（Flag），叫做 progressive_frame 來顯示。當 progressive_frame = 1 的時候，DVD2AVI 就會顯示 Frame Type = Progressive。當 progressive_frame = 0 的時候，DVD2AVI 就會顯示 Interlaced。這個旗标的作用是什麼呢？這個旗标的作用是告訴 Decoder，目前的這張畫面，是一個 Progressive Frame，還是由兩個 Field 組合成的一個 Interlaced Frame。根據這個旗标，Decoder 才能知道要怎麼做 YUV 4:2:0 upsampling 到 YUV 4:4:4，組合正确的播放順序。

請參考下面附的圖

1. YUV 4:4:4

Chroma（圈圈的記号）= 彩色像素，Luminance（叉叉的記号）= 亮度像素

2. YUV 4:2:0

3. YUV 4:2:0 Progressive Frame 的取樣位置：chroma1 = (c1+c2)/2, chroma2 = (c3+c4)/2

4. Interlaced Frame 的取樣位置：chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4

5. 播放時根據 progressive_frame 旗标判斷畫面是一個 Frame 還是由兩個 Field 組成。

這張圖有 3:2 pulldown，根據 RFF（repeat first field）旗标重複輸出第一個 field，是以會看到重複的圖場。

注意看 progressive_frame = 0 或 1 時 Chroma 的位置

由上面的這幾張圖，我們可以看出，YUV 4:2:0，垂直方向的彩色像素隻有一半。當 progressive_frame = 1 的時候，彩色像素 Chroma 的位置是位在兩個 Luminance 亮度像素的中間。是以取樣的時候，chroma1 = (c1+c2)/2, chroma2 = (c3+c4)/2，用原本 YUV 4:4:4 的 c1 和 c2 求平均，得到位在中間的 chroma1 的值。

當 progressive_frame = 0 的時候，畫面拆成兩個 Field 取樣，Chroma 在每個 Field 不是位于正中間，而是位在 3:1 的位置上，是以取樣算式變成 chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4。注意交錯畫面是拿 c1 和 c3 取樣 chroma1，因為 c1 和 c3 才是屬于同一個 Field 畫面（奇數掃瞄線組成的奇數圖場），c2 和 c4 位在另一個 Field 上（偶數掃瞄線組成的偶數圖場）。而循序畫面則是拿 c1 和 c2 取樣 chroma1，兩者有很大的不同。

以前曾經有提過，現在有很多 DVD Player 有 chroma upsampling 的錯誤，那時說有機會再解釋，現在解釋。

Chroma Upsampling 錯誤就是，許多 DVD Player 不會判斷 progressive_frame 這個旗标，當遇到交錯畫面時，chroma upsampling，由 YUV 4:2:0 -> YUV 4:4:4，要用交錯畫面的 upsampling 計算式，chroma1 要分給 c1 位置和 c3 位置來使用，不可以給 c1 和 c2 使用，因為交錯畫面當初取樣時，是拿 c1, c3 算出 chroma1 的。

同理，當遇到循序畫面時，要用循序畫面的 chroma upsampling 計算式，chroma1 要分給 c1 和 c2 使用。

現在許多 DVD Player 不會分辦這個旗标，upsampling 時隻有一種計算法，譬如說軟體 DVD Player 因為使用 YV12 Overlay，是以造成隻能用循序畫面的計算式，遇到交錯畫面，色彩像素就會解錯，c2 會拿 chroma1 的像素來用。

這個軟體譯碼的問題也就是 DVD2AVI 的作者當初寫 DVD2AVI 這個軟體的原因，因為他受不了 Chroma 錯誤譯碼之後的畫面。想知道譯碼錯誤的畫面長什麼樣子，請看 DVD2AVI 作者網頁上的圖檔和說明

http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/

目前 PowerDVD 已經解決這個 Chroma 譯碼錯誤的問題，遇到交錯畫面先分别解出兩個 Field 的 Chroma（c1 and c3, c2 and c4），再合并成一個 Frame。由于這樣要自己先做 YUV 4:2:0 -> YUV 4:2:2，是以 PowerDVD 用的是 YUY2 Overlay。

另一個譯碼錯誤的問題，普遍發生在硬體的 DVD Player 上。硬體的 DVD player 一樣不會分辨 progressive_frame 旗标，它們隻有交錯畫面的 upsampling 計算式（剛好和軟體 DVD Player 相反），是以遇到循序畫面，就會解出錯誤的畫面。想知道硬體 DVD Player 譯碼錯誤的畫面長什麼樣子，請看 Home Theater HiFi 這本雜志做的測試，裡面有詳細的解說

http://www.hometheaterhifi.com/volu...bug-4-2001.html

還有列出目前市面上，有哪些 DVD Player 已經修正這個問題

http://www.hometheaterhifi.com/volu...-2001-list.html

多有趣對不對，原來我們看了這麼久的 DVD，解碼畫面竟然不正确!

回歸原題，DVD2AVI 顯示的 Frame Type 資訊，隻是根據 progressive_frame 這個旗标，代表的意義是這個 Frame 當初壓縮時，是用 Progressive Frame 取樣，還是 Interlaced Frame 取樣，和實際上畫面是否有交錯無關。

當然正确的情況下，無交錯的畫面應該用 Progressive Frame 取樣，有交錯的畫面應該用 Interlaced Frame 取樣。但是愚蠢的 DVD 制作廠商不一定會做對，譬如說 csr2000 兄提到的他那張二區日本 DVD 全部是 100% Interlaced，這個就是一個做錯的例子。這代表當初廠商在壓縮時就做錯，DVD2AVI 隻是忠實反應這個錯誤。

我手上也有很多片子明明是循序畫面卻用 100% Interlaced Frame（譬如說日本二區的 Full Metal Panic NCOP），真是讓人哭笑不得。

想想這些大廠都會犯錯，連硬體 DVD Player 都會做錯，那麼壓縮時搞錯設定也就不是什麼奇怪的事情了。

以上，一樣是幫 DVD2AVI 申申冤

我比較常用 M4C + AviUtl 手動指定 keyframe。

先說明一下，以免大家不知道我們在讨論什麼。

csr2000 兄說的「ベリノイズ」，英文叫做「luma-inverted block」指的是 MS MPEG-4/DivX 3.11 的一個 bug，當碼率很高，也就是畫質很好，quantizer 很低的時候，畫面上高反差（對比強烈）的地方，譬如說黑色與白色的交界處，會出現一種灰色的方塊，有時候看起來像黑水晶的色澤，油油亮亮的。這種瑕疵看起 來非常明顯而且很難看，壓色彩鮮豔、對比強烈的動畫時特别容易出現，是當初用 MS MPEG-4/DivX 3.11 壓動畫的人的頭号大敵。

解決這個問題的方法，一個是将出現方塊的畫面重新壓縮為 keyframe，這樣方塊就會消失。M4C 這個 plugin 就是在做這件事，壓縮的時候 1st pass 壓一次，然後檢查畫面上是否有灰色方塊，如果發現有灰色方塊，就自動作 2nd pass 把該畫面重新壓縮為 keyframe。

另一個方法，是将該畫面重新提高 quantizer 壓縮，直到灰色方塊消失為止。SBC 的 Antishit 就是在做這件事，Antishit 的 shit 指的是 luma-inverted block。如果提高 quantizer 壓縮灰色方塊還是沒有消失，SBC 才會将該畫面重新壓縮為 keyframe，并且繼續提高 quantizer 重試。

M4C 的缺點是會将畫面重新壓縮為 keyframe，而 MS MPEG-4/DivX 3.11 keyframe 的最小 quantizer 預設值是 4x，這是 codec 内定的。

quantizer 4x 的 keyframe 壓某些畫面時品質實在不太夠，很容易出現晶格狀，整個畫面都是一塊一塊方塊，看起來也很難看。

而 M4C 檢查的方法是比較壓縮後的畫面和原始畫面有多少 pixel 的亮度差異超過設定值，如果亮度相差超過一定程度，M4C 就會判斷畫面上出現了 luma-inverted block（亮度颠倒的方塊）。不過有的時候亮度的差異是因為 MPEG 破壞性壓縮後造成的差異，并不是因為畫面上真的出現了 luma-inverted block。如果 M4C 這個判斷的參數設得太低，M4C 會大量重新壓縮畫面為 keyframe，而剛剛說過，keyframe 的品質很差，最小 quantizer 也隻能用 4x 而已。連續很多畫面都是 keyframe 的話，畫面也會都是晶格狀，一塊一塊的方塊，看起來一樣難看。

是以為了避免 M4C 插入太多的 keyframe，我們會将檢查的參數設得比較寬松，隻有真正的 luma-inverted block 畫面我們才重壓為 keyframe。如果第一次壓縮以後發現有畫面有灰色方塊沒有檢查出來，我們再用 AviUtl 手動指定那一張畫面為 keyframe 重新壓縮一次就可以解決了。

總之原則是盡量減少不必要的 keyframe，keyframe 越少越好，越少品質越高。

甚至連 Scene Change 的 plugin 都不要用。AviUtl 有一個 Scene Change 的 plugin，因為 MS MPEG-4/DivX 3.11 codec 很笨，它的 Scene Change 偵測、自動插入 keyframe 的功能要在碼率低于 460kbps 以下時才會啟動，是以必須使用額外的 Scene Change plugin 來做偵測的工作。當然如果 hack 過的版本，如 VKI 的版本，譬如說 DivX 3.22，就可以在任何碼率下啟動 Scene Change，不過這種版本的 codec 不能和 Nandub 一起用，會造成 Nandub 的混亂。然而如果要最高畫質，則連 Scene Change 都不要用，就給它用 delta frame 壓下去，雖然這樣那個 delta frame 會很大，但是品質會比用 4x 的 keyframe 好。

以上是 M4C 的情況。用 M4C 壓的時候，目标是高畫質，是以一集二十多分鐘的動畫壓的容量大小都是 250~350MB，很大。

如果要做 1 CD 的 DVD-RIP，quantizer 本來就高，出現 luma-inverted block 的機會比較少，或者你壓縮的影片不是動畫，對比沒那麼好，出現 luma-inverted block 的機會比較少，那麼使用 SBC 我想是比較好的方法。

SBC 的缺點是，程式有 bug。SBC 檢查灰色方塊的方法是，壓好一個畫面以後和原來的畫面比較，計算畫面上品質最不好的方塊的 PSNR。PSNR 是一種計算畫面品質的方法，機關是 dB，越低代表和原來的畫面差異越大，品質越差。當計算出來的 PSNR 低于設定值的時候，例如說隻有 7dB，不到設定的 19dB，SBC 就會将該畫面重新提高 quantizer 壓縮。quantizer 越高畫質越差，但同時也可以解決灰色方塊的問題，當畫質差到一定程度以後，灰色方塊就會消失。

然而如果我們把設定值設得太高，例如設成 21dB，不到 21dB 的畫面都要提高 quantizer 壓縮，則可能會出現一種情況，那就是這個畫面其實沒有出現灰色方塊，但它的品質很差，不到 21dB，結果被 SBC 誤判為是 shit，重新提高 quantizer 壓縮。當然，這樣根本無濟于事，不但無法提高 PSNR，反而會使 PSNR 更低（quantizer 更高了，品質更差）。SBC 發現提高 quantizer 一次沒有辦法使 PSNR 超過 21dB，它就會繼續再提高 quantizer 重壓一次試試看，結果程式就會反複不同地提高 quantizer、重壓，直到最後最大的 quantizer 31x 才跳出執行的循環。而這時 PSNR 當然還是低于 21dB，是以 SBC 又把它重壓為 keyframe 2x，此時程式又發生了一個緻命的錯誤，計算出來的 PSNR 是錯誤的，是以 SBC 仍然誤判 PSNR 低于 21dB，繼續提高 quantizer 重壓這個 keyframe，直到 31x keyframe 才跳出循環。

多麼的愚蠢

結果我們最後就會得到一張 31x keyframe，慘不忍睹的破脆畫面。

不是很多人遇過這種情況，這是因為

1. Antishit 的設定值沒有設得太高，超過 21dB 通常會很危險，容易造成 SBC 誤判，但有些 luma-inverted block 又會在 21~22dB 左右的時候出現，設得太低又無法檢查出這些畫面，是以左右為難

2. 壓的影片對比沒那麼高，不容易出現 luma-inverted block。

3. 壓的碼率不高，quantizer 高，減少 luma-inverted block 出現的機會。

是以沒遇過這種情況。不過如果你到 Doom9 的論壇上去搜尋 31x keyframe 這個字，你會發現以前有人提過他們遇到這個現象。

是以 SBC 還是有這個缺點，我以前就為了這件事情傷透腦筋 ^^;

另外，我以前還瘋狂到要用 SBC 壓無敵畫質的動畫 ^^;

因為 SBC 可以控制 Compression Level，簡寫為 CL，其實也就是我們現在比較熟悉的 quantizer，指的是同樣的東西。我想到 M4C 的畫質很好，可是還是不夠好，因為它的 keyframe 隻能 4x，遇到某些畫面還是會有晶格狀，看了很不舒服。

我想利用 SBC 控制 quantizer 的功能，把 keyframe 的 quantizer 也設為 2x（SBC 會覆寫掉原本記憶體内 codec 的預設值），這樣就可以壓出比 M4C 畫質更高的東西了。

要達到這個目标，必須搭配 Nandub 的 .ecf 檔案。ecf 是 Encoding Control File 的縮寫，是純文字檔案，寫好設定以後存盤為 .ecf，Nandub 壓縮的時候可以讀取這個檔案，控制壓縮的參數。裡面可以設定每個 Frame 的型态，例如

@1-2000: K, CL=2

@2001: D, CL=2

的意思是控制 1 到 2000 個 Frame 全部都壓成 keyframe，而且 CL 為 2x，2001 則壓成 delta frame（P-frame）。

此外還可以設定每個 Frame 的 Motion 值，Gauge 值...等等。設定 Motion 值在這裡有個作用，前面提過 SBC 可能會誤判某些畫面有 luma-inverted block，實際上沒有，要如何解決這個問題呢？SBC 的 Antishit 還有一個參數叫做 Modulation，會随着 Motion 值的高低調整啟動 Antishit 的 dB 值。Motion 越高，啟動的 dB 會自動降低，例如從 21dB 降低為 19dB。這樣我們隻要在 .ecf 将那幾個會被誤判的畫面的 Motion 值手動指定得很高，SBC 遇上這幾個畫面時 Antishit 便不會啟動，這樣就可以避免 SBC 誤判了。

好複雜？确實很複雜，我以前手動調整反複壓了十幾遍，搞得累得半死，也仔細寫過詳細的做法教學，現在看起來真是沒有意義，改用 DivX 5 或 XviD 壓就不用那麼麻煩了 ^^;

以上說的是要壓超變态、超極限、超高畫質、不計檔案大小的情況，MS MPEG-4 因為先天有許多 bug，非常不适合。如果是壓 1 CD, 2CD 這種的，就不在此限，這種情況 MS MPEG-4/DivX 3.11 是有它的優點。

PAL 格式的 DVD 不可以 Forced FILM，DVD2AVI 的 Forced FILM 會每五個畫面删除掉一個畫面，PAL 25fps 的 DVD Forced FILM 之後會變成錯誤的 20fps，畫面會一頓一頓的，播放不流暢（因為中間的畫面被删除了）。

FILM 100% 的 DVD 直接用 Forced FILM 輸出即可。NTSC FILM 100% 的意思是，這張 NTSC 的 DVD，裡面儲存的是 24fps 的 progressive 畫面，播放的時候會利用 RFF/TFF 這兩個旗标（Flag）作 3:2 pulldown，将 24fps 轉為 30fps 輸出。轉換的原理以前說過，或是上面那篇翻譯文章中也有講（不過寫得好複雜 @[email protected]），此處便不再贅述。此時 DVD2AVI Forced FILM 輸出，會根據 RFF/TFF 旗标，每五張删除一張，30 -> 24fps 得到原本的 24fps progressive 畫面。

這個動作的效果，等于做 IVTC。

NTSC/FILM 混雜的 DVD，又叫做 Hybird 的 DVD，必須做 IVTC。NTSC/FILM 混雜的意思是，這張 DVD 裡面，有 NTSC（30fps）的 Frame，也有 FILM（24fps）的 Frame，兩種混合在一起，是以叫做 Hybird。為什麼會有這種 DVD 呢？這是因為原本的 24fps 電影膠卷，經過膠卷過帶（Telecine）以後，變成 30fps 的母帶，譬如說 D1，然後送進 MPEG-2 encoder 壓縮。這樣的 30fps 的畫面是有 interlaced 的（交錯、拉絲），而且是五張之中有兩張交錯。interlaced 的畫面不好壓縮，會使得壓縮率下降，而且影片本來就是 24fps，壓縮時壓 30fps 浪費空間，還要每 24 張多壓 6 張畫面，等于碼率多消耗 20%，十分浪費。

是以壓 DVD 的時候，好一點的 encoder 同時會做 IVTC，将 30fps 轉回 24fps 之後才壓縮，儲存 24fps progressive 畫面，這樣畫質會比較好。這個也就是上面說的 FILM 的 DVD。

然而，不是所有的影片都是先剪接編輯完才做 Telecine，也就是 3:2 pulldown 的順序不是單一的。剪接完才 Telelcine 的影片叫做 hard coded telecine，這種的做 IVTC 比較簡單。其它不是隻有單一順序的影片做 IVTC 會比較困難。還有 encoder 的 IVTC 也無法 100% 地判斷出還原的順序，會受到噪聲、「光學式 Telecine 造成的殘影」、畫面動态大小的影響，影響判斷的正确性。是以能夠判斷、還原的畫面 encoder 就會用 24fps（FILM）去壓，遇到不能判斷、還原的畫面 encoder 還是隻好用 30fps（NTSC）去壓，是以最後壓出來的 DVD 就會有 NTSC/FILM 兩種形式混合。

遇到這種 DVD，如果 FILM 的比例不高，譬如說低于 95%，就不可以讓 DVD2AVI 做 Forced FILM，會删除到錯誤的畫面，出來的結果某些地方會停頓。遇到這種情況，你就必須真的自己去做 IVTC，來還原 24fps，不能依賴 DVD2AVI 的簡單判斷。

如果是純 NTSC 30fps 的訊源，這個意思是這張 DVD 的畫面是 30fps 張張都無交錯，張張都是 progressive 的畫面，那當然根本不需要、也不應該要、也不能要做 IVTC。IVTC 的意思是 inverse telecine，反-膠卷過帶，當然是要有做過 telecine 的訊源，你才需要、才能夠做 IVTC。沒有經過 telecine 的訊源，做 IVTC 要幹什麼？

這種 30fps progressive 的訊源，例如計算機 CG 作畫的電影、卡通片，或 30fps 攝影機拍攝的特殊影片等等，會出現這種規格。

如果是純 NTSC 60 fields per second 的訊源，這個意思是 60 fields，30fps 張張都交錯的畫面，張張都是 interlaced 的，遇到這種訊源，當然也不能做 IVTC，要做的是 de-interlace 去交錯。這種訊源是交錯是攝影機，DV 等拍下來的影片。

總結以上，也就是說隻有當原本的訊号來源（訊源）是 FILM，原本就是 24fps 拍攝的影片，譬如說一般的電影，我們才需要做 IVTC。

DVD 壓縮的時候，一個 Frame 被視為是兩個場的組合，奇數的掃瞄線組合成奇數的圖場，偶數的掃瞄線組合成偶數的圖場。另外有一個旗标（Flag）會标示，這個 Frame 是 progressive 的，還是 interlaced 的。progressive frame 的意思是，這個 frame 當中的兩個場，是同一時間點拍攝下來的畫面，兩個場組合城一個完整的畫面。interlaced 的意思是，這個 Frame 當中的兩個場，是在不同時間點拍攝下來的畫面，兩個場各自獨立。

那麼Silky兄，如何判斷一張DVD是否是純NTSC 30fps的呢？

怎麼判斷？用眼睛看

例如 NTSC 30fps interlaced 的訊源張張都交錯，簡寫為 30i，也就是等于 60 fields per second。這種的用 preview 跑一遍看的話，會發現"每一張"畫面都交錯，沒有一張是完整的畫面。

NTSC 30fps progressive，簡寫 30p 的影片，你用 DVD2AVI 的 preview 跑一遍播放看看。用眼睛看畫面，不要管 DVD2AVI 的 Frame Type 顯示的訊息。你會發現畫面張張無交錯，每一張都是完整的畫面，這就是純 30fps progressive 的訊源。這種訊源通常出現在計算機 CG 作畫的動畫，或者是一些純 30p 的動畫，例如櫻花大戰 OVA2、BOYS BE 等等。有些動畫的 OP 是 30p，本篇是 24p，例如 Azumanga 大王。有些動畫是本篇 24p，但是遇到 CG 的畫面，則變成 30p。有些動畫是 30p/60p 混合，例如 SolBianca。有些動畫是 24p/30p 混合，例如 Lain 的 OP、Kurumi 的 OP。還有 48p 的情況..... 做動畫比較複雜 ^^;

電影的話就比較簡單，絕大多數的電影都是 24p 拍攝的，一般我們看到的都是，沒有例外。

如果是 24p 的訊源，telecine 的時候做 3:2 pulldown，例如原本是

A B C D

四個 Frame，拆成 [Ao Ae] [Bo Be] [Co Ce] [Do De]，每個 Frame 拆成奇（Odd，Ao Bo Co Do）偶（Even，Ae Be Ce De）兩個圖場，然後以 2-3-2-3 這樣形式重複排列，變成

代碼 (輕按兩下代碼複制到粘貼闆)

[Ao Ae] [Bo Be Bo] [Ce Co] [De Do De]







   2   -    3     -   2   -    3      

然後每兩個圖場重新組合為一個 Frame

[Ao Ae] [Bo Be] [Bo Ce] [Co De] [Do De]

就變成五張 Frame，原本四張變五張 4->5 => 4*6->5*6 => 24->30

24fps 就會變成 30fps。

因為是以 3:2 這樣的比例排列，是以稱為 3:2 pulldown。

我們觀察可以發現：

1. 3:2 pulldown 24->30fps 并沒有增加新的畫面，多出來的 Frame 是原本的畫面"重複"組合"出來的結果。

2. 3:2 pulldown 之後，原本張張 progressive 的畫面，變成有 interlaced 的畫面，而且是五張之中有兩張交錯，第三張的 [Bo Ce] 和第四張的 [Co De] 交錯，下一組的五張畫面也是第三和第四張的畫面會交錯，呈現一種周期性的現象。

是以遇到訊源是 24p，經過 telecine 3:2 pulldown 變成 30fps，encoder 壓縮時沒有做 IVTC，以 NTSC 30fps 壓縮 這樣的 DVD，DVD2AVI 就會顯示 NTSC 100%。然而我們 preview 觀察時，會發現 "每五張之中，隻有兩張是交錯的，另外三張沒有交錯"。呈現這種周期，我們就可以知道，這個訊源是 24p 的，隻是經過 3:2 pulldown 之後才變成 30fps 的，我們可以對它做 IVTC。

引用
如果用DVD2avi看到的資訊是NTSC，是否意味着這張盤是模拟轉錄的盤呢？

不太明白您的意思 ^^;

引用
因為我自己手頭有1區、3區、6區和全區的盤，似乎FILM的出現和是否是正版并無關系。 尤其是國内的正版DVD，包括6區和全區的，似乎都沒有出現FILM字樣，反而是幾張D5的盜版碟是FILM 98%左右的。

出現 FILM，代表 DVD 的 encoder 壓縮時有做 IVTC，先幫你轉回 24p 了，是以你不用辛苦做 IVTC，直接用 DVD2AVI 的 Forced FILM 輸出即可。

encoder 會不會做 IVTC 和是否正版無關。不過通常來講，正版的品質較佳，1 區通常 FILM 率都很高。

引用
那麼像這種情況，沒有出現FILM的（是完全沒有，而不是低于9x%），應該也不是Progressive的吧？我對這種盤一直是進行IVTC的，這種做 法是否正确？

沒有出現 FILM，和訊源本身是 24p 或 30i 無關，FILM 隻是 DVD 的 encoder 有做 IVTC，或者是數字訊源 24p 直入，如 StarWar II。完全 NTSC 的片子，還是有可能原本是 24p，經 3:2 pulldown 轉為 30fps，可以還原回 24p。這種片子交錯會呈現一規律周期，每五張爛兩張，不是張張都交錯。

其實，絕大部分的電影，都是 24p 的，不需要判斷。

請問sillky，能不能講講.ecf檔案對編碼是如何控制的？對于用ND做1CD或者2CD影片，應如何編寫ecf檔案？側重點有何不同？另外，哪裡能 找到關于這方面知識的詳細介紹？

這個寫起來很複雜 ^^;

用 ecf 去控制每個 Frame 的壓縮狀态是一件很繁複的工作，一般不會有人去這麼做，實在太辛苦了。我會用的原因是因為想壓超變态的畫質，而且我壓的是動畫的 OP/ED，隻有一分半鐘，是以可以這樣慢慢搞。一般長篇的影片用這樣手動設定調整的方式是非常耗費時間的。

我把簡單的參數說一下，詳細的原理（例如什麼是 Motion，什麼是 Gauge，調整之後會有什麼作用）就不仔細說明了，因為現在 DivX 5/XviD 可以更輕易地做到相同的品質。

Nandub 壓縮的時候可以讀入一個 ecf 檔來控制壓縮的參數，

ecf 是 encoding control file 的簡寫，内容是文字檔案，

指令的格式是 @: [=] [, [=] ]

可以控制的參數有五種：

K 強制某個 frame 為 keyframe

D 強制某個 frame 為 delta frame

R=nnnn 指定某個 frame 的 bitrate(0~6000)

CL=cc 指定某個 frame 的 Compression Level(=Quantizer, 2~31)

M=mmm 指定某個 frame 的 Motion(0~300)

G=gg 指定某個 frame 的 Gauge(%, 0~100)

譬如說我要指定從第 1 個 frmae 到 2000 個 frame 都用 keyframe 2x 壓縮（瘋了 ^^;

寫法是這樣：

@0-1999: K, CL=2

也可以分别指定不同的 frame：

@2000: R=1000, CL=31

@2001: R=3000, CL=3, M=300

@2002: R=6000, CL=2, G=70

Modulation % 設定會讓 Nandub 根據 動态（Motion）值調整 Antishit

例如 Antishit 設為 21dB, Modulation 6%, 遇到 Motion 是 289 的畫面，

Antishit 會自動降低變成

代碼 (輕按兩下代碼複制到粘貼闆)

21dB * ( 1 - (289/300) * (6/100) ) = 17.3586dB







^^^^          ^^^^^^^     ^^^^^







AntiShit      動态比例    modulation 6%      

Nandub 1st-pass 計算的動态（Motion）最大值是 300，我們可以故意指定

Motion 為 3000，這樣會讓這個 Frame 的 Antishit 啟動值降低到不會啟動。

關于這方面的介紹網站，我沒有看過，也很少有人會提到 Nandub 有一個 ecf 檔案可以做這種控制

有很多個 Frame 要控制的時候，GKnot 可以讓你設定以後存盤為 .ecf 檔案，用這個 ecf 再自行編輯修改會比較友善。

有個問題想問一下silky兄，因為我平時接觸的DVD都是4區25fps的film，是以一直可以跳過反交錯這個步驟不用理會，但是對于pal格式的 interlaced類型，是否也隻能是進行deinterlace?按理來說答案應該是“yes”，但 是decomb的telecide()有時卻又可以在不改變fps的情況下完美恢複progressive frame，不知道原理如何，還望賜教。。

net1999 兄

賜教實在是萬萬不敢當，小弟對 PAL 制可以說是完全沒有經驗，您這麼客氣實在是令小弟萬分慚愧。

PAL 25fps interlaced 的訊源（25fps 張張都交錯的訊源）和 NTSC 30fps interlaced 的訊源一樣，要做垂直分辨率 x576/x640 在計算機上播放的 AVI/RM/WMV... 隻好做 de-interlace，将畫面去交錯。或者是做成 VCD 的話，垂直分辨率隻有一半，PAL 是 x288，NTSC 是 x240，隻有原本的一半圖場，此時就可以不用去交錯，直接單取奇或單取偶的圖場即可。

這種訊源通常出現在電視節目上，或者是自行用攝影機拍攝下來的影片，他們是以 60 fields/50 fields per second 的速率拍攝，每一張 field 拍攝的時間點都不同，是以組合成 Frame 的時候張張都交錯。但是現在也有越來越多的電視節目是以 24p 拍攝，是以完全交錯的訊源比較少見。

而電影絕大部分是以 24p 拍攝，telecine 過帶成 PAL 的母帶時做的是 2:2 pulldown

代碼 (輕按兩下代碼複制到粘貼闆)

[Ao Ae] [Bo Be] [Co Ce] [Do De]







   2   -   2   -   2   -   2      

如上所見，組合以後還是原本無交錯的四張畫面，但是播放的速度加快 4%，提升為 25fps，同時聲音的部分也加快 4%，這樣才能跟上同步。

是以理論上 PAL 的電影 DVD 應該是很好處理的，畫面本來就沒有交錯，不像 NTSC 那麼麻煩。

然而我注意到論壇上有朋友提過 PAL 的電影 DVD 還是有的有交錯，我當時就覺得很奇怪，為什麼會這樣？我當時猜測可能這些 DVD 的母帶是自行用交錯式的攝影機去轉拍的關系。（因為我沒有實際碰過這種 PAL DVD 的經驗 ^^;）

現在聽您提起這種 DVD 可以用 decomb 的 telecine() 組合成無交錯的畫面，才讓我恍然大悟這是怎麼回事 ^_^

原來大家忘掉一件最重要的事情，叫做 Field Order。

Field Order 是指攝影機拍攝的時候拍攝的順序和顯示的時候顯示的圖場順序。

如果是奇先（Top Field First），那麼畫面順序就會是

代碼 (輕按兩下代碼複制到粘貼闆)

奇 1 2 3 4 5







偶  1 2 3 4 5      

第一張畫面奇數圖場先放，然後是第一張畫面的偶數圖場，接下來是第二張畫面的奇數圖場.... 依此類推。

如果是偶先（Bottom Field First）

代碼 (輕按兩下代碼複制到粘貼闆)

奇  1 2 3 4 5







偶 1 2 3 4 5      

NTSC 的訊源在做 IVTC 之前，開啟檔案讀取的時候一定要先判斷訊源是奇先還是偶先，例如大多數的訊源都是"奇數圖場優先"，大多數的采集卡是"偶數圖場優先"（日本的例外），大 多數的 DV 是奇先。

如果奇先偶先的順序設錯，則 IVTC 的時候怎麼補都補不回來，怎麼補畫面都還是會交錯。是以 DVD2AVI 的作者在他網頁上寫的 IVTC 的教學中強調，在做 IVTC 之前，一定要先判斷訊源是奇先還是偶先。

前一篇文章列的那個 3:2 pulldown 的順序叫做 Odd First 的 Telecine，我以前講的時候有注明，前一篇說明的時候怕麻煩省略，現在看來是非講不可了

[1o1e][2o2e][3o3e][4o4e] => Odd First Telecine => [1o1e][2o2e][2o3e][3o4e][4o4e]

如果是 Even First 的話

[1o1e][2o2e][3o3e][4o4e] => Even First Telecine => [1e1o][2e2o][2e3o][3e4o][4e4o]

一個奇先的畫面把它用偶先順序的組合（先取偶，後取奇）讀取，會得到

奇 2 3 4 5 6

偶 1 2 3 4 5

張張畫面都交錯，順序完全亂掉。

一個 Odd First 的 Telecine 把它用 Even First 的順序去 IVTC，畫面還是會交錯，順序完全亂掉。

是以在做 IVTC 之前，一定要先判斷奇先偶先。

判斷奇先偶先的方法，簡單的步驟如下：

用 TMPGEnc 加載影片（我用的是英文版，不知道相對應的選項中文是怎麼翻譯的），Setting -> Advanced -> Deinterlace -> Method 選 "Even-odd field (field)"，點一下畫面然後按左右方向鍵的右鍵，放看看畫面的情形怎麼樣。如果畫面中的物體移動不順暢，會突然往後倒退，代表目前 TMPGEnc 在 Advanced 設定底下的 Field order 設反了，本來設 Top field first 就改成 Bottom field first，本來設 Bottom field first 就改成 Top field first。

設好正确的 Field Order 之後，才能用 TMPGEnc 做 IVTC。

或是參考 DVD2AVI 的作者 jackei 的網頁，有詳細的圖文說明

http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/ivtc/

請一定要看一看，jackei 神樣寫的文章都是寶貝

如果可以看繁體中文，請看 jackei 神樣寫的其它文章

# DVD 是如何用 TFF/RFF 旗标作 24->30fps 輸出

http://bbs.irradiance.net/txtVersion/treasure/animation/

M.928082084.A/M.940069311.A/M.971722833.A.html

http://bbs.irradiance.net/txtVersion/treasure/animation/

M.928082084.A/M.940069311.A/M.971722833.B.html

# TMPGEnc 是如何利用畫面的「奇偶差異」和「動态」這兩個資料判斷，作 IVTC

http://bbs.irradiance.net/txtVersion/treasure/animation/

M.928082858.A/M.955422324.A/M.955422334.B.html

還有其它一大堆，精彩至極的文章，有興趣研究者千萬不可錯過

回過頭來講 PAL ^^;

那種交錯的 PAL 電影 DVD 是怎麼回事呢？我猜大概是 Field Order 設反了。遇到這種張張都交錯的 DVD，但是訊源是 24p，實在不可能有交錯，您用 DVD2AVI，勾選 Video -> Field Operation -> Swap Field Order 試試看，看畫面是不是就恢複正常了 ^_^

decomb 的 telecide() 會自動判斷畫面的奇先偶先順序，幫你轉回正确的 Field Order，是以經過 telecide() 之後畫面也會正常。但是這樣還要讓 decomb 去做判斷會拖慢速度，是以不如直接更改 .d2v 檔案裡的 Field Order 順序，這樣比較簡單，而且迅速。

試試看，看是不是因為這個原因。如果猜錯了.... ^^; 那我們再繼續研究

顯示 NTSC 百分之幾或 FILM 百分之幾，就是 Hybird 的 DVD（NTSC/FILM 混合），這種就是 24p -> telecine -> 30fps 的訊源。其中 NTSC 的部分就會是每五張爛兩張。FILM 的部分是 DVD 壓制的時候 encoder 有做 IVTC 還原。

如果顯示純 NTSC，但是 preview 時張張無交錯 => NTSC 30fps progressive。

如果顯示純 NTSC，但是有些交錯有些沒交錯 => 24p -> telecine -> 30fps 的訊源，encoder 壓縮時沒有做 IVTC。

如果顯示純 NTSC，但張張都交錯 => NTSC 30fps interlaced。

如果顯示太快分不清是 NTSC telecined 訊源還是 NTSC interlaced 訊源，可以用 VD/TMPGEnc/AviUtl 加載 .d2v 一張一張慢慢看。通常應該很容易辨認，電影的 DVD 隻有 PAL/FILM/NTSC/Hybird，PAL 直接輸出，FILM 選 Forced FILM 輸出，NTSC 要做 IVTC，Hybird DVD 的 FILM 比例不高的話也要做 IVTC。30fps progressive 隻出現在動畫、特殊影片，一般不容易遇到。30fps interlaced 出現在 DV、電視台節目，這種的要做之前應該就很清楚訊源的類型是什麼，例如是轉自己拍攝的 DV 帶。

判斷 IVTC 是否成功，我想隻能用眼睛看吧

如果眼睛看不出來，就當它是成功吧

我手動補正的時候也是這樣，眼睛看不出來或沒看到的部分，就算了 ^^;

是的，TMPGEnc 有 Interlace 壓縮模式（Encode mode: 選 Interlace）。MPEG-2 的 Interlace 壓縮會用 Field Picture 結構，Field/16x8 動作預測模式壓縮，或者是用 Frame Picture 壓縮，但是還是可以用 Field DCT，Field 動作預測模式。

Field Picture: 以 Field 為機關壓縮，将奇數場、偶數場視為兩個獨立的畫面分開壓縮

DCT Type: Frame DCT

動作預測模式:

1. Field 預測

2. 16x8 預測

3. Dual Prime 預測（隻有在沒有 B-frame 的時候才能使用）

Frame Picture: 以 Frame 為機關壓縮

DCT Type: Frame DCT，遇到交錯畫面時使用 Field DCT

動作預測模式:

1. Frame 預測

2. Field 預測

3. Dual Prime 預測（隻有在沒有 B-frame 的時候才能使用）

據研究，Frame Picture 的壓縮效率較高，是以 MPEG-4 已經不用 Field Picture 的壓縮結構。

TMPEGEnc 好像是以 Frame Picture 壓縮（以前研究過，結果我忘了 ^^;），交錯畫面會使用 Interlace 的壓縮工具（Field DCT... 等等），對交錯畫面直接壓縮的壓縮效率還是很好。

是以如果是要在電視上播放，不要去交錯以 Interlace 模式壓縮即可，TMPGEnc 對于場的畫面處理還是不錯。

如果要在計算機上觀看，我想還是做去交錯看起來舒服些

如果制作 VCD，垂直分辨率隻有一半 x288/x240，我想單取奇數場或偶數場即可，也不用去交錯。去交錯後再 resize -> x288/x240，觀看時會發現有重疊的畫面。不去交錯單取奇或偶，便看不到重疊的畫面，但是畫面會頓。

請Silky講講手動補正時，copy frame和ctrl+p的用法及其運用的條件，jackie講得太簡單，不太明白，尤其是如何判斷telecine序列的問題

手動 24fps 補正，修正自動補正判斷錯誤的畫面，我轉一段 jackei 在他的網頁上教學檔案裡面寫的說明：

「Misjudging frame correction is very tricky, so I suggest you forgetting it :-p

Actually, the accuracy of TMPGEnc/AviUtl IVTC is good enough.」

「If you understand Chinese, refer to http://bbs.irradiance.net/txtVersion/treasure/animation/M.928082858.A /M.955422324.A/」

手動補正錯誤的畫面是非常困難的，是以我建議你忘掉它吧 :-p

事實上 TMPGEnc/AviUtl 的 IVTC 正确度已經很好了。

如果你懂中文的話，請參考 http://bbs.irradiance.net/txtVersion/treasure/animation/M.928082858.A/M.955422324.A/

連他老人家都這麼說了...

要用文字說明手動補正的步驟是非常困難的 ^^;

我的建議是，先用 TMPGEnc 做自動補正，選「去交錯優先」（Flicker prioritized）。跑第一遍的時候要計算畫面的資料會比較慢，跑完以後資料會記錄在 TMPGEnc/Cache 底下。按 Ctrl + 左右方向鍵移動，檢查畫面是否有交錯。通常 TMPGEnc 會在場景切換的地方判斷錯誤，是以我們隻要移動到每個場景切換的地方，看看判斷有沒有出錯，是否在切換場景之後畫面就開始有交錯，判斷開始出錯。如果自動 補正判斷發生錯誤，我們便在開始交錯的前一張，按滑鼠右鍵，選「Enable automatic setting after this frame」，從這個 frame 之後再跑一次自動補正，注意自動補正是可以跑好幾次的。第二次補正的時候速度會非常快，因為資料第一次補正的時候都已經算好了，是以第二次補正速度會很 快，一下子就選好了。通常第二次補正以後，原本選錯的畫面就會正确了，然後再移到下一個場景切換的地方檢 查。

還有 TMPGEnc 經常在在交錯量小的畫面判斷錯誤，例如動畫人物開口說話的畫面，此時畫面上大部分區域都是靜止的，隻有嘴巴的部分是交錯的，TMPGEnc 會在這種地方判斷錯誤，此時可以手動一張一張選擇。

另外也可以用眼睛觀察畫面的 telecine 周期，TMPGEnc 會将原本的五張畫面拆成十張畫面

代碼 (輕按兩下代碼複制到粘貼闆)

0a  0b  1a  1b  2a  2b  3a  3b  4a  4b  ...







1奇 2奇 2奇 3奇 3奇 4奇 4奇 5奇 5奇 6奇 ...







1偶 1偶 2偶 2偶 3偶 3偶 4偶 4偶 5偶 5偶 ...      

你用眼睛看，這十張畫面哪幾張是交錯的，拿一張紙記錄打叉做記号。十張之中要挑選四張，兩張一樣的隻選其中一張。例如下面的例子，假設 0b 交錯 打叉。1a 和 1b 都無交錯，畫面相同，兩張挑一張看起來比較好的，選 1a。1b 也打叉。2a 交錯，2b 無交錯打圈。3a 交錯。3b 和 4a 都無交錯，兩張畫面相同，挑 3b 打圈。4a 打叉... 結果如下

代碼 (輕按兩下代碼複制到粘貼闆)

o   x   o   x   x   o   x   o   x   x   ...







0a  0b  1a  1b  2a  2b  3a  3b  4a  4b  ...







1奇 2奇 2奇 3奇 3奇 4奇 4奇 5奇 5奇 6奇 ...







1偶 1偶 2偶 2偶 3偶 3偶 4偶 4偶 5偶 5偶 ...      

然後按滑鼠右鍵，選「Deal after this frame according to selected pattern」（或者是按 Ctrl + P），手動輸入選擇的畫面，打圈的畫面是要選的填 1，打叉的畫面是不選的填 0，是以填入「10100」這樣就可以了。有時候用眼睛觀察很快，手動指定 pattern，注意切換場景的地方有沒有換周期，一下子就補好了。

有時候補完以後還是有幾張畫面選錯，這時手動挑選沒有交錯的畫面即可，視情況可以增減挑選的畫面。注意手動挑選或增減畫面的時候會造成影音不同 步，TMPGEnc 小視窗中底下有兩個數字，Estimated: xxxxx(24fps) 這個數字是估計 24fps 補正後這張畫面應該是第幾個 frame，Current: xxxxx(24fps) 這個數字是根據目前你補正的結果，這張畫面會是第幾個 frame。注意要讓 Estimated 和 Current 的數字不可以相差超過 1，否則會明顯的影音不同步。左邊有個 Check 的按鈕會幫你檢查是否有影音不同步的情形發生。有增減畫面時，例如有某張交錯畫面選了會交錯，去交錯又不好看，鄰近畫面又沒有無交錯的可以取代，幹脆就不 選。這樣就會少一張畫面。如果有減少畫面，後面就要想辦法多補一張畫面，例如挑一張靜态的畫面多補一張 ，以彌補前面少選一張畫面的損失，否則缺少畫面太多會造成影音不同步。補畫面的動作最好在同一場景内完成，在那個場景内減少一張畫面，就在那個場景内多補 一張畫面彌補，最好不要拖到下一個場景才補。

要多選重複的靜态畫面時，Copy Frame 這個功能就很有用。按滑鼠右鍵選 Copy Frame，目前的這個畫面就會以前面的畫面取代，變成和前面那張畫面一樣。有時候前後兩張畫面相同，但是後面那張有壓縮瑕疵，選了很難看，不選又不行， 這時就可以使用 Copy Frame 的功能，複制一個畫面。這樣不但可以避免有瑕疵的畫面，而且使用 Copy Frame 前後兩張畫面完全一樣，壓縮時壓縮效率會非常高。encoder 甚至可以完全 skip 掉第二張畫面不壓縮，對壓縮也非常有幫助。連續靜态畫面時，幹脆通通設定為 Copy Frame。

TMPGEnc 還有一個超強的功能，可以手動指定 P/B copy frame。在 GOP structure 裡面「Force picture type setting」，可以手動指定 Picture Type。按滑鼠右鍵有個「P copy」和「B copy」，會複制前一張畫面，TMPGEnc 壓縮時會直接 skip 掉這些 copy frame 不壓縮，顯示時是直接拿前一張相同的畫面來顯示，不但壓縮率高，而且靜止畫面會完全靜止，不會有騷動感，畫面非常漂亮，請看 jackei 寫的

[秘技](T)MPEG(Enc)靜止畫面絕對靜止法

http://bbs.irradiance.net/txtVersion/treasure/animation/M.928082858.A/M.959619674.A/

這個功能隻在用 TMPGEnc 壓 MPEG-1/MPEG-2 有用。

遇到畫面有交錯又不得不選的情況，隻好用「單張去交錯」，隻對這張畫面做去交錯。按滑鼠右鍵選「Deinterlace」就可以單張去交錯，指定這個畫面 去交錯的方法。選一個看起來傷畫面最小的方法。

寫得好亂，我都不知道接下要講什麼.....

其實，補正這種東西，做久了就熟練了，自然會有很多心得。如果硬要條列式的說明的話，反而不知道該從何講起

所謂動畫職人，補久了以後，經驗越多，補正的速度也就越快，靠直覺就知道哪裡會交錯

我看過朋友那種吓人的補正速度，你隻看到他 AviUtl ins/del 按按按，按個沒幾下，兩三分鐘之後就說「好了，補完了」 ^^;;

看一遍檢查一下，幾乎沒有補錯 ^^;;;

在沒練到那種超人的技巧之前，就偷懶吧

如同沈老大說的，要在 Encode mode 選 Interlace。

ProCoder 也有類似的選項。

有用 Interlace 的壓縮工具的話，壓縮交錯畫面的效率就不會太差。

先去交錯以後再以 Progressive 模式壓縮也可以，但是這樣有缺點

1. 畫面會模糊。

2. 動态差異大的畫面，去交錯以後會變成兩個 Field 的影像重疊的畫面，以 Frame 壓縮一樣不好壓縮（複雜度大）。

既然是要在電視上觀看，那麼以 Interlace 模式壓縮保留較多的原始訊息應該會比較好。

對了，

忘了說，XviD 的「Enable interlacing」選項就是啟動 Interlace 壓縮模式，會使用 MPEG-4 的 Interlace 壓縮工具。不過 -h（一個人，常上 Doom9 的人應該不陌生）隻有做到 Field DCT，沒有把 Field 動作預測模式也寫出來（因為他說太複雜了

），是以 XviD 的 Interlace 模式隻有部分的壓縮工具，壓縮效率不如 TMPGEnc。

TMPGEnc 的作者崛老實在太厲害了，他說想要寫 MPEG-4 的編碼器，我真是非常期待。

（MPEG-4 還有一堆工具 DivX/XviD/FFMPEG 目前都沒有作出來，例如任意形狀編碼等等）

我想崛老做的 MPEG-4 編碼器應該也會是最強的

Frame DCT 的意思是，做 DCT 轉換的時候，一個 16x16 的 "Macroblock" 切成四等分，四個 8x8 的 "block" 分别做 DCT 轉換。像下面這張圖（圖檔來自 ISO MPEG-2 Standard 檔案）

Figure 6-12 Luminance macroblock structure in frame DCT coding

Field DCT 的意思是，做 DCT 轉換的時候，将 Macroblock 中的奇偶順序重新排列，變成兩個 16x8 的方塊，一個方塊是由奇數的掃瞄線組成，另一方塊是由偶數的掃瞄線組成，然後再将這兩個 16x8 的方塊水準方向切成兩半，最後一樣變成四個 8x8 的方塊，分别做 DCT 轉換。

這樣這四個方塊中的系數，全部都來自同一個 Field，這樣叫做 Field DCT。像下面這張圖

Figure 6-13 Luminance macroblock structure in field DCT coding

以上是 Luminance 的作法。MPEG-2 規定，YUV 4:2:0 的時候，Chrominance 一律使用 Frame DCT，4:2:0 以上才可以使用不同的 DCT Type。

為什麼交錯畫面使用 Field DCT 壓縮效率較高呢？

這是因為在交錯畫面時，奇偶掃瞄線的像素分别來自兩個不同時間點拍攝的 Field，差異很大，譬如說一奇一偶這樣排列：

1

99

2

100

3

101

你可以看出奇數掃瞄線的像素彼此之間的的數值比較接近，而偶數掃瞄線的像素彼此之間的數值也較接近，一奇一偶交叉排列在一起的話，這個數值會有一個很快的 頻率起伏變化

小

大

小

大

小

大

這樣我們稱為，這個方塊有很高的空間頻率成分。如果直接拿這樣奇偶合并的方塊去做 DCT 轉換，DCT 這個轉換就是把空間上的像素轉換為以頻率域上的系數來表示，以消除空間上像素彼此之間的關聯性（備援性），這樣使用幾個比較少的頻率系數就可以代表本來的 訊号。當方塊中有這樣變化頻繁（奇偶差異大，關聯性小）的像素的時候，轉換後能量就不會集中在少數幾個 空間頻率的系數上，當然這樣就會造成壓縮困難。

是以我們才會設計 Field DCT，将奇偶拆開分别做 DCT，以增進交錯畫面的壓縮效率。

MPEG 壓縮的時候會做 DCT 轉換，這個轉換是以 8x8 像素大小的方塊（block）為機關，将方塊内的 8x8 像素值轉換為代表方塊内的 8x8 空間頻率的系數。因為自然影像通常不會在很小的區域範圍内有很大的變化，相鄰的像素點數值通常會很接近，也就是說不會有很複雜的空間頻率系數，經過 DCT 轉換以後，代表這張影像的能量會集中在幾個空間頻率的系數上，其它大部分的系數，尤其是高頻的系數都會變成 0。這樣我們就可以用比較少的，代表空間頻率的幾個數字，來描述原本的影像，而不用記錄原本複雜的 8x8 = 64 個影像像素的灰階值。這第一步就可以消除影像在空間上的備援性，或者叫關聯性，達到資料壓縮的第一個目的。備援性越高，也就是影像内像素的灰階值彼此之間 越接近，越平均，經過 DCT 轉換後的能量就越集中，非 0 的 DCT 系數就越少。資料的「備援」的意思是，譬如我說 q 你大概就可以猜出後面會接 u，因為英文單字中 q 後面接 u 的機率很高。出現機率越高，代表這筆資料所包含的資訊越少，備援越多。這樣我們要記錄這些備援實在很沒有效率，是以我們換個描述、表達的方式，把備援去除 掉，把資訊用更簡潔的方法表現出來。DCT 轉換差不多就在做這樣的事。（譬如說我講一個故事花了 600 字，廢話、贅字很多，你把它重新改寫，隻花了 300 字就講完了..... 差不多就是這個意思 :P）

是以這個轉換有沒有效率，能不能讓轉換後大部分的系數都變成 0，讓能量集中在少數幾個系數上，要看原本方塊内的像素彼此之間接不接近。如果關聯性越高，轉換的效率就越高。

是以前面舉的例子，如果是交錯的畫面，奇偶差異大，垂直方向的關聯性降低，這樣轉換效率就會下降。是以我們用 Field DCT，将奇偶拆開做 DCT 轉換，譬如說假設現在垂直方向四個像素的灰階值是

22

44

33

55

Field DCT 會把奇偶分開做 DCT 轉換

22

33

44

55

你可以看出垂直方向的差異縮小，關聯性提高，這樣的 DCT 效率就會比較高。

注意 Frame DCT/Field DCT 可以以 Macroblock 為機關做切換，在 Progressive Frame 裡面還是可以用 Field DCT，好的 Encoder 會自行判斷用哪一種 DCT Type 壓縮效率會比較高。

至于動作預測模式太複雜就不講了

可是又出了個新問題，為什麼同樣是用Flicker prioritized跑一遍，有的片子每5張畫面會有3張被紅框選中(說明有3張畫面被補過了)，而有的片子每5張畫面卻正好隻有2張被選中呢？我猜這 是不是跟訊源的類型有什麼關系？

TMPGEnc 會自動選擇沒有交錯而且又能保持影音同步的畫面，有些畫面如果選了會有交錯，TMPGEnc 就會自動選擇其它沒有交錯的畫面來取代，是以就可能會出現五張之中選了三張。

不過不用擔心，TMPGEnc 一定會選則能保持影音同步的畫面，不會不同步。

是以也有反過來的情況，有時候 TMPGEnc 很奇怪，明明畫面有交錯，但是不管自動補正重跑幾次，TMPGEnc 還是會選有交錯的那張畫面，而不會選旁邊沒有交錯的畫面。

這是因為如果選了其它畫面，就會影音不同步，非選那張有交錯的畫面不可，是以 TMPGEnc 才會執意要選那張有交錯的畫面。

其實有時候可以變通一下，如果在不是很注重影音同步的場合，例如不是在說話的畫面，不需要很精确地對準，讓說話的聲音符合嘴形，那麼我們可以手動選擇會讓 影音不同步但是沒交錯的畫面來取代，隻要播放時不會明顯察覺到影音不同步就好。

引用
另外，telecine周期的确定應該跟被標明應用pattern模式的起始畫面有關系吧，所選的起始畫面不同，周期也會不同吧？

是的。

引用
記得在很久以前，那時好像VCD都還沒有！應該是八十年代吧！ 看到過一篇關于電影膠片在電視上播放的知識性文章！ 那篇文章說的就是讓24幀每秒的電影膠片以25幀每秒的速度播放，就可以錄制成電視上可播放的節目了。是以那篇文章最後說在電視上觀看的電影總要比在電影 院裡觀看短那麼幾分鐘！ 那麼現在的PAL制式的電影節目還是這麼做的嗎？

是的，還是一樣的作法。

如同我前面說的，telecine 時做 2:2 pulldown，播放速度加快 4%，聲音也跟着一起加快 4%。

TMPGEnc 環境設定底下，VFAPI Plug-in 有将 DirectShow Multimedia File Reader 的優先權（Priority）調高嗎？

TMPGEnc 要藉由 DirectShow filter 來讀取檔案時，必須要将 DirectShow Reader 的優先權調高才能讀取。例如使用 AC3Filter，就是一個 DirectShow filter（字尾是 .ax），要使用 AC3Filter 來解碼，就必須要調高 DirectShow Reader 的優先權。

Windows Media Player 等播放軟體預設會以 DirectShow 解碼，是以能播放不代表 TMPGEnc 能解碼，如同光有 ffdshow 這個 MPEG-4 的 DirectShow filter，卻不能用 VirtualDub 等軟體開啟 MPEG-4 的檔案，因為 VirtualDub 隻能以 VFW Codec（Video for Windows Codec）來解碼（字尾是 .dll），不能用 DirectShow filter 解碼，是以系統上有 ffdshow 也沒用。

是以要用軟體開啟時，必須要注意該軟體是用哪種方式來讀取檔案，安裝相對應的解碼器，并且調整設定。

試試看，說不定問題就解決了

另外 Soft Encode 解碼的音質比較好，如果可以的話建議用 Soft Encode 解碼。

免費的 AC3 decoder 大部分是用 LibA52 來解碼，我聽過的幾個音質都很不好，甚至不如 DVD2AVI，是以建議用 iviaudio.ax（WinDVD）或 Soft Encode 解碼。

Soft Encode 解碼時，如果是音樂類型的片子，不要選 RF mode，最好用 Line out mode（在 Options -> Decoding setting），這樣子動态壓縮不會那麼厲害，音質會比較好。（我自己用甚至全部都選 Line out mode，不管哪一類型的影片。Line out mode 音量會比較小，再用 Normalize 放大即可）

原來試過老版本的普通的2:1濾鏡的效果是很差的, 幾乎與PR的RISIZE的數學方法是一樣的. 但這次用下來一看驚若天人似乎比那個LANCZOS3還要好了. 高性能2:1的那個還是與原來的差不多BLEND的成份很重.

您說的普通 2:1 濾鏡是指 2:1 reduction 嗎？

我做了一點實驗。

學術界在測試 filtering 效果時最常用的是 "circular zone plate" 這個圖形，

這個圖形是由好多個圓圈所組成，畫面最中間的水準和垂直空間頻率是 0，

越往外圍，水準和垂直空間頻率越高。

水準方向遠離中心，離中心越遠水準空間頻率越高；垂直方向遠離中心，

離中心越遠垂直空間頻率越高；四個角落是垂直和水準的空間頻率最大的地方。

空間頻率越高的意思，可以想象為畫面上有一黑一白，黑白相間的線條，

黑白條紋越密集，也就是灰階值由黑變白，再由白變黑的變化頻率越快，

我們說這樣這張圖形的空間頻率很高。

根據取樣定理，我們知道取樣頻率必須是原始訊号頻率的兩倍，我們才能正确地記錄原始訊号。

原本寬度 640 pixels 的圖形（取樣點是 640 個點），其所能記錄的黑白相間的變化次數是 320 次

（一黑一白，占掉兩個 pixel，我們所能見到的黑色線條是 320 條，白色線條是 320 條）。

當這個寬度 640 pixels 的圖形 resize 為一半 320 pixels 時，隻能表現出 160 條黑白相間的條紋

，無法表現出原本圖形所記錄的 320 條黑白相間這麼高的頻率，也就是這麼密集的線條。

根據取樣定理，我們必須把超過所能記錄的範圍的頻率濾掉，否則轉換後這些高頻的訊号會被當成

低頻的訊号，我們會得到錯誤的結果。

以聲音訊号來舉例，44.1KHz 轉為 22KHz，必須把原本訊号中 11KHz 以上到 22KHz 的頻率濾掉，

否則轉換後原本該是高頻的訊号，卻會變成低頻的訊号，變成低頻的聲音出現，你想這樣還能聽嗎 :P

為什麼降低取樣頻率之後，超出所能記錄範圍的高頻會被當成低頻訊号？請看下面這張圖

藍色的線是原本記錄的高頻訊号，線條成階梯狀，每一階都是一個取樣點，

圖形中的 sine 波形有 11 個周期（重複 11 次）。

降低取樣頻率之後，新的取樣點是紅色的點，取樣的點數變少。

我們注意到新的紅色取樣點連成一條線，得到的新訊号變成是一個低頻的 sine 波形（僅一個周期），

而不是原本的高頻訊号。這個低頻訊号在原本的訊号中是不存在的，是錯誤的訊号。

這種現象我們稱為 aliasing。

是以我們在轉換之前，必須先把這種會引起 aliasing，超過轉換後所能記錄的頻率範圍的高頻訊号

濾掉，以免發生 aliasing，得到錯誤的結果。

那麼在影像訊号的處理上，也是一樣，我們必須先把 resize 後不能正确記錄的高頻訊号濾掉，

不然一樣會得到錯誤的畫面，例如畫面上會出現鋸齒，波紋（moire）等等瑕疵。

這個事先濾掉高頻的 filter，叫做 pre-filter。

不同 filter 的設計，濾除的效果不同，也有不同的副作用，我們以前曾經提過，lanczos3 resize

是一個擁有最佳 filter 效果的 resize 法。

下面我們用 circular zone plate 這個圖形來測試 2:1 reduction 和 2:1 reduction (high quality)

的頻率濾除特性。circular zone plate 的圖形中央空間頻率是 0，越往外圍空間頻率越高，

良好的 filter 應該要盡力保持中央部分的圖形的線條清晰，而外圍的圖形則應該全部濾除，

外圍若有留下來的線條則是 aliasing 的訊号。

原始 640x640 的 circular zone plate 圖形

2:1 reduction resize 為 320x320

如何判斷一些MPG壓縮軟體所接受的資料皮是4:2:0的還是其它什麼的? 記得你說過TMPGENC接受的是RGB的

MPEG-4 都是以 YUV 4:2:0 儲存，如果輸入的影像格式不是 YUV 4:2:0，Codec 會自動轉換，

轉為 YUV 4:2:0 後再開始壓縮。

不同 Codec 的轉換式計算精确度、UV 取樣時的方法不同，出來的品質（除去壓縮的因素）

也大不相同。

大部分的 MPEG-4 Codec 都可以接受許多種格式的輸入，例如 YV12/YUY2/RGB24/RGB32 等等。

TMPGEnc 是以 VFAPI 讀取，VFAPI 以 RGB24 傳遞資料，是以...

同時 TMPGEnc 的濾鏡也是在 RGB24 的色彩空間下工作。

當 TMPGEnc 壓縮選項勾選 Highest quality 時，就是同時做 RGB 空間上的 MV 搜尋，

是以費時很久。

其它軟體接收什麼格式，試試看就知道了，不能吃的話檔案就開不了。

CCE 好像可以接受 YUY2 輸入，YV12 不行。

Helix 好像可以接受 YV12 輸入。

不管可以接收何種格式輸入，大部分最後都要轉為 YUV 4:2:0。

感謝小嘴巴兄的教學

我也喜歡 MPEG-2，MPEG-4 有一堆限制和令人吐血的 bug，要上到高畫質很困難。

ProCoder 對比顔色過強的問題是由于小弟以前提過的 YC 壓縮、伸張的問題。

MPEG 儲存的 YUV 範圍必須是 CCIR 601 的 YUV，也就是 Y: 16~235 UV: 16~240 的範圍。

當我們将 DVD 上的資料用 DVD2AVI 解碼出來，如果選 PC Scale，則 DVD2AVI 在做 YUV -> RGB 的時候，會做 YC 伸張，将 YUV 的範圍伸張為 16~255 的 RGB。

DVD(601 YUV) -> DVD2AVI(Basic YUV)

這樣子的 RGB，再次壓成 MPEG 的時候，不管是壓成 MPEG-1/2/4，都要先經過 YC 壓縮，将範圍壓為 16~235，然後才轉回 CCIR 601 的 YUV 儲存起來。

DVD2AVI(Basic YUV) -> MPEG(601 YUV)

TMPGEnc、CCE 都有控制這個要不要做 YC 壓縮的選項。

如果來源有做過伸張，是 Basic YUV(0~255)，則壓成 MPEG 前必須做 YC 壓縮；如果來源沒有做過伸張，是 CCIR 601 YUV(16~235)，則壓成 MPEG 前不需先做 YC 伸張。

至于這兩個軟體的設定選項小弟以前的文章中有寫。

而 ProCoder 的大問題就是，他沒有控制要不要做 YC 壓縮的選項，對任何輸入的訊源，他都一律不做 YC 壓縮。

這樣子當訊源是 CCIR 601 的時候沒有問題

訊源(601 YUV) -> MPEG(601 YUV)

但是遇到訊源是 Basic YUV(0~255) 時就發生大問題了，因為 ProCoder 沒有做 YC 壓縮，是以會變成

訊源(Basic YUV) -> MPEG(Basic YUV)

這樣子當播放時，播放器會做 601 YUV -> Basic YUV 伸張的動作，而 ProCoder 的 MPEG 原本就是 Basic YUV，再被重複伸張一次，許多 YUV 資料會超出範圍被削掉。不明白的人看了會以為，ProCoder 壓縮的色彩好豐富，對比好鮮明，畫質真好，但其實是已經損失了許多細節。

遇到原本對比不強烈、色彩較不飽和的影片，ProCoder 這麼做有補償的作用，會讓人看起來覺得還不錯。但是遇到原本色彩就很豐富、很飽和，對比很強烈的影片，用 ProCoder 壓縮就完蛋了，畫面色彩會整個崩潰，亮部會過份泛白，而暗部則是漆黑一遍，什麼層次都沒了，十分凄慘。

是以用 ProCoder 壓 MPEG，訊源在送給 ProCoder 之前，必須先确認 YUV 範圍必須保持為 CCIR 601 YUV。

MPEG2Dec.dll 解碼時會按照 .d2v 檔案的 PC/TV Scale 設定，決定要不要做伸張。Avisynth 2.5 也有一個 ColorYUV 的 filter，可以做 TV->PC（伸張）or PC->TV（壓縮）的轉換。Avisynth 2.0x 系列也有外挂的 plugin 可以做這種轉換。在送給 ProCoder 壓縮前，要先将輸出調整為 TV Scale/CCIR 601 YUV 才可以。

如果 YUV 範圍設定正确，則 ProCoder/CCE/TMPGEnc 三套軟體壓出來的顔色、對比都是差不多一樣的。

MainConcept MPEG Encoder 也是沒有選擇伸張壓縮的選項，它是一律都會做壓縮，是以必須接收 Basic YUV 的資料。

我想知道PSNR的值是怎樣算出來...

将壓縮前和壓縮後的畫面，每個 Pixel 的值相減，将誤差平方，加總，求平均。

這個算出來的值叫做 MSE。

然後和最大訊号值的平方相比，例如 Pixel 的值範圍是 0~255，最大訊号值就是 255，

那麼就是和 255 的平方相比。

求出來的值取 20*log，算出來就是 PSNR，機關是 dB。

PSNR = 20*log (255^2/MSE)

是以 PSNR 算的是「和原始畫面的差距」。

MSE 算式可以看 berkeley 的網頁

http://bmrc.berkeley.edu/courseware/cs294/fall97/assignment/psnr.html

～～我裝了VobSub後怎麼圖象倒過來了啊～！救救我啊～！！

畫面會颠倒是因為 YUV 和 RGB 格式，一個是由上到下的放置順序，另一個則是由下到上的放置順序。

做 YUV -> RGB 的轉換後，必須要做 flip，上下反轉，畫面才會恢複正常。

不同程式可能會有不同的放置順序，例如用 Avisynth 的 VFAPISource 讀進 VFAPI 的 RGB 檔案後，

畫面會反轉，後面必須接 flip() 才會恢複正常。

然而有些程式輸出的放置順序是錯誤的，例如 MS MPEG-4/DivX 3.x 的 mpg4ds32.ax 就有這樣的 bug，

輸出 RGB 畫面會颠倒，是以接在它後面的 DirectVobSub 必須反轉一次，畫面才會恢複正常。

如果你用的是新版的 mpg4ds32.ax，新版的 mpg4ds32.ax 已經修正這個 bug，輸出畫面不會颠倒，

然而 VobSub 的程式代碼無法區分判斷，會以為這仍然是舊的 mpg4ds32.ax，是以還是隻反轉一次，

這樣畫面就會颠倒了。

還有不同的顯示卡驅動程式，不同的解碼 Codec，中間插入的不同的 DirectShow Filter，

輸出的情況千奇百怪，各種可能都有，有的要反轉有的不要反轉，是以為了應付各種情況，

VobSub 設計了 flip 的選項讓使用者來自行調整，以應付各種可能的情況。

如果您要問的是這個，這就是為什麼圖像會倒過來的原因

詳細可以參考 MSDN

http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/biheight.mspx

也就是說，你的avi的在avisynth中的設定要跟計算psnr時mpeg2source的一樣--包括所有的filters,plugins--所 留下的不同就完全是codecs所造成的，對不對？

我在寫計算psnr的script時遇到了問題，能不能幫我看一下

編碼時的script比如是

LoadPlugin("MPEG2Dec3.dll")

LoadPlugin("Decomb.dll")

LoadPlugin("Convolution3DYV12.dll")

mpeg2source("01.d2v")

Telecide()

Decimate()

vd1=trim(1000,2000).Crop(8,0,-8,0).LanczosResize(640,360).Crop(16,16,-16,-16).Convolution3d()

vd2=trim(51000,52000).Crop(8,0,-8,0).LanczosResize(640,360).Crop(16,16,-16,-16).Convolution3d()

return vd1+vd2

那麼當計算psnr時，關于mpeg2source那段時怎麼把上面那一串寫在一起啊？

orig=vd1+vd2

PSNR 比較的時候，是比較「和原始影片的差距」，是以您用來比較的 orig，

必須和壓縮時的原始影片相同才行，如果您壓縮時原始影片是

MPEG2source("sample.d2v")

crop(8,54,704,368)

LanczosResize(640,368)

比較時的 orig 就必須是

orig=MPEG2source("sample.d2v").crop(8,54,704,368).LanczosResize(640,368)

至于為什麼 MPEG2Dec3 輸出需轉為 YUY2，那是因為目前 compare function 的問題，

您可以先轉為 YUY2 再轉回 YV12，不會有誤差，或者是直接在 YUY2 色空間比較。

比較時建議以 Y-PSNR 為主。

我自己計算 PSNR，因為我壓的片子都需要經過 TMPGEnc 的 IVTC 處理，

是以最後都是轉為 VFAPI，為了不同 Codec 比較時有相同基準點，

再用 Avisynth 加載這個 VFAPI AVI，統一由 Avisynth 轉成 YV12 的原始影片

avisource("GateKeepers21_OP_aup_vfapi.avi").ConvertToYV12()

比較的時候

orig=avisource("GateKeepers21_OP_aup_vfapi.avi").ConvertToYV12()

encoded=avisource("GateKeepers21_OP_XviD.avi", false, "YV12")

compare(encoded, orig, "Y", "PSNR-XviD.LOG")

比較含有 B-frame 的 AVI，XviD 的 vfw Codec 開頭會固定有一張延遲的 delayed frame，

要将它删除，删除以後就可以對齊比較了

encoded1=avisource("XviD.avi", false, "YV12").Trim(1,0)

删除以後，XviD 的末尾會少一張 Frame，是以若是要和其它 Codec 比較，例如 DivX 5.05，

DivX 5.05 就必須要删除最後一張 Frame，這樣比較才會公平。

假設總共是 2001 張 Frame，0~2000

encoded2=avisource("DivX.avi", false, "YV12").Trim(0,1999)

PSNR4AVI 算出來的結果，我以前用，有一些怪怪的，可能是 RGB 轉 YUV 的問題。

有 B-frame 的 AVI 一定要用 Avisynth 算，結果才會正确。

TMPGEnc 本身不能 decode MPEG-2 file，必須透過 DirectShow filter，使用系統上的 MPEG-2 decoder 來解碼。

在 2.57 版以前，隻要在環境設定中，VFAPI plug-in 設定底下，把 DirectShow Multimedia Filter Reader 的優先順序調高，同時系統上有裝 WinDVD, PowerDVD 等 MPEG-2 解碼軟體，就可以加載讀取 MPEG-2 file。

2.57 版和 2.57 版以後，為了安定性，TMPGEnc 不再使用 DirectShow Multimedia Filter Reader 讀取 MPEG-2 檔案，即使把優先權調高也沒用。

2.57 版以後，TMPGEnc 本身内建了三個 MPEG-2 decoder 的 VFAPI plug-in，優先順序分别是 1.Sony 2.Ligos 3.CyberLink。

Sony 的 MPEG-2 decoder 在 Sony VAIO RX 系列的計算機上有裝，Ligos 的 decoder 裝 Ligos 的軟體便可以取得，ProCoder 好像也是裝 Ligos 的 MPEG-2 decoder，而 CyberLink 隻要裝 PowerDVD 即可。

裝這三個 decoder 的任何一個，TMPGEnc 就可以使用内建的 VFAPI plug-in 讀取 MPEG-2。

==

然而，PowerDVD 從 4.0 版的 1811 patch 以後，改成一定要強制使用 Overlay 輸出，是以 TMPGEnc 便無法再使用 PowerDVD 的 DirectShow filter 來解碼。

解決的辦法

1. 安裝 Ligos 的解碼器

2. 使用舊版的 TMPGEnc，将 PowerDVD 的 DirectShow filter 優先權調低，将系統上的其它 MPEG-2 decoder 的優先權調高，例如将 WinDVD 的 DirectShow filter 優先權調高，就會使用 WinDVD 的 DirectShow filter 來解碼。

調整 DirectShow filter 的優先權，例如你系統上裝了很多個 MPEG-2 decoder，要選擇要用哪一個 filter 來解碼，這時候就會需要手動調整優先權的設定，有軟體可以做這樣的設定，請自行搜尋。

3. 以上的方法都不建議使用。事實上這些方法解碼的品質都很差，而且有錯誤，比較好的作法：

a. 用 DVD2AVI 這個軟體讀取 MPEG-2 file，存成 .d2v，再用 TMPGEnc 開啟這個 .d2v 檔案。

b. 安裝 MPEG-2 VIDEO VFAPI Plug-In，就可以直接用 TMPGEnc 開啟 MPEG-1, MPEG-2, .vob檔案了。而且 MPEG-2 VIDEO VFAPI Plug-In 解碼的畫質非常好。

建議使用 3 的做法，不要再用 PowerDVD 來做 MPEG-2 解碼的工作了。

PowerDVD 的 DirectShow Filter 會做 Bob，也就是 blend，畫面會較模糊。

m2v，也就是上面說的 MPEG-2 VIDEO VFAPI Plug-In，畫質是最好的，它的 upsampling 比 DVD2AVI 還高階，而且

1. 它的 chroma upsampling 和 DVD2AVI 一樣是正确的，其它的 MPEG-2 DirectShow Filter，除了 PowerDVD 以外，WinDVD, Ligos 等我試過的都是錯的

2. 它是目前唯一能正确解碼 HDTV 的 MPEG-2 TS 的程式，解 HDTV 的 MPEG-2 TS，隻有它解出來的顔色才是正确的，連 DVD2AVI 解的顔色都無法正确，這個說起起來又是一番長篇大論，我現在沒時間慢慢寫，有人知道 Doom9 上的 trbarry 寫了一個 Avisynth 的 filter，叫做 BT709ToBT601 嗎？那個 filter 處理的就是這個問題。等晚點我忙完了以後再上來詳細說明，因為處理 HDTV 的人還很少，是以我從來沒有公開地講過這個問題。

DirectShow Filter，是播放的時候使用的，講求的是實時解碼，解碼速度要快，畫質很難講究。

用 DVD2AVI，m2v 這種外挂解碼，才能得到好的畫質。

至于 DVD2AVI 解出來顔色顔色失真，偏淡，或者是 m2v 解出來顔色失真，偏淡，那是我從前提過的一個老問題，叫做 YC 伸張壓縮的問題，我為了這個問題寫過數萬字，差不多和我寫 resize 的問題差不多多次，我已經寫到快無力了 :P

這是設定的問題，設定正确，就不會有顔色失真、偏淡的現象。

DVD2AVI 和 m2v 是是上兩個最強的神人寫出來的軟體，怎麼可能會比一個 DirectShow Filter 還要差？

詳細的設定，我晚點在慢慢從頭把來龍去脈重寫一次。

我沒有用power dvd codec

我知道

我前面貼的，第一篇是以前回答有人問「為什麼安裝新版的 PowerDVD 後 TMPGEnc 就開啟不了 MPEG-2 檔案」這個問題時寫的文章。因為我回第一篇的時候很急，沒有時間修改，是以是直接轉貼以前寫的文章，回答有點前言不對後語 ^^;

第二篇回答再提到 PowerDVD，是因為看到前面 net1999 兄提到，PowerDVD 解出來似乎較模糊，好像是因為 blend 的關系，是以我就順便回答：「PowerDVD 的 DirectShow Filter 會做 Bob，也就是 blend，畫面會較模糊。」

不過因為我回複第二篇的時候，還是很急，沒有時間慢慢寫，是以這裡并沒有講得很詳盡完善。

根據 MS 的檔案，當初 MS 提 Bob 的時候，原意是指，遇到交錯（Interlaced）訊源，例如 30fps 的交錯訊源，将顯示速率加倍，變成 60fps，一次隻顯示一個圖場（Field），也就是一半的掃瞄線，剩下的一半掃瞄線，用内插補點補出來，這樣叫做 Bob。

但是因為當時的硬體顯然無法做到，能夠實時運算補出另一半的掃瞄線，是以軟體在實作 Bob 的時候，例如 WinDVD, PowerDVD 的 Bob 模式，其實是用 Blend 的方式，這和 Bob 的原意并不相同。

以我說話啰哩八嗦，喜歡長篇大論的習慣，我當時并沒有對 Bob = Blend 多作解釋，可見真的有多匆忙了

是以我當下面寫到關于 m2v：「它是目前唯一能正确解碼 HDTV 的 MPEG-2 TS 的程式，解 HDTV 的 MPEG-2 TS，隻有它解出來的顔色才是正确的，連 DVD2AVI 解的顔色都無法正确」，我也沒有時間對這句話多作解釋。我說隻有 m2v 能正确解碼 HDTV 的 MPEG-2 TS，并不是說其它 Decoder 不能解 HDTV MPEG-2 TS。其它 Decoder 也能解 HDTV MPEG-2 TS，但是重點是後面那句「隻有 m2v 解出來的顔色才是正确的」，是以我說的解碼正确，指的是顔色是否解正确。

那麼為什麼我要一直強調 "HDTV" 的 MPEG-2 TS，會什麼不簡單地說 MPEG-2 TS 就好呢？因為是 "HDTV" 的 MPEG-2 TS 才有這個問題，一般的 MPEG-2 TS 也沒有這個問題，是以我才會一直強調 "HDTV" 的 MPEG-2 TS。是以我後面才會說「等晚點我忙完了以後再上來詳細說明，因為處理 HDTV 的人還很少，是以我從來沒有公開地講過這個問題。」

由此可知，我說的解碼問題，并不在 MPEG-2 TS 上，和 MPEG-2 TS 的格式無關，問題是出在 HDTV 身上。

好了，推理分析完了，那麼 HDTV 到底有什麼問題？下面小弟會慢慢回答

引用
2 MPEG-2 VIDEO VFAPI Plug-In + elecard 測試出來色彩失真

關于這點，MPEG-2 VIDEO VFAPI Plug-In 是一個日本人，叫做 marumo，我都稱他為「神樣」，因為他太偉大了 :P 寫的一個 MPEG Decoder。這個 Decoder 是一個獨立運作的 Decoder，它自己就可以解碼，就像 DVD2AVI 解碼一樣，不需要依附其它的 MPEG-2 Decoder。是以當你使用 m2v 解碼，就是使用 m2v 自己本身在作解碼，而不是連到其它 DirectShow Filter 來作解碼，這是第一點要厘清的。

m2v 的解碼畫質，比 DVD2AVI 還要好。它用的 upsampling filter，比 DVD2AVI 品質還要好。

附帶一提，當初 marumo 神樣在開發 m2v 的時候，曾經收到 DVD2AVI 的作者 jackei 神樣寫給他的信，告訴他 m2v 有一個 bug，marumo 神樣非常感激，但是也大傷腦筋，因為他的英文很破，不知道該怎麼樣用英文回感謝信 :P

以上是趣談。

那麼為什麼您用 m2v 和 DVD2AVI 解出來，色彩都失真呢？

看了您下面貼的設定圖，我猜測的沒錯，因為您剛好把兩個軟體的色彩轉換設定都設錯了 :P

是以看起來才會兩個軟體都失真。

那麼正确的設定該怎麼設？下面小弟會長篇大論地回答

我把以前寫過的東西做一個整理，因為時間的關系，我沒有辦法把每一個細節都講得非常的詳細，不過我會把大概的原因，和處理的方法，盡量用很精簡的方式，條 列整理出來。

如果對更深入的原理有興趣，請搜尋過去零散的讨論。

一切都要從 ITU-R BT.601 這個"建議"開始說起。

現今的 DVD/VCD/DV 都是遵循 ITU-R BT.601 這個規格，這個規格規定了，模拟影像轉數字時，取樣的方式，儲存的資料格式、資料範圍等等。

當影像轉為 MPEG 的時候，RGB 資料要轉成 MPEG 使用的 YUV 格式。ITU-R BT.601 裡面規定了這個 RGB <-> YUV 的轉換式，資料範圍 0~255 的 RGB 要轉為 YUV 的時候，要先做資料範圍的壓縮，把範圍壓縮成 16~235，然後才轉成 YUV 儲存起來。然後 MPEG 解壓縮的時候，解出來的 YUV，要做資料範圍的擴張，将 Y: 16~235, UV: 16~240 的資料擴充為 0~255 的 RGB，也就是還原回原來的 RGB 數值，然後才能顯示在顯示器的螢幕上。

這個 0~255 RGB -> 16~235 YUV 的過程，就叫做 YC 壓縮。

反過來 16~235 YUV -> 0~255 RGB 的過程就叫做 YC 伸張。

我們可以很清楚地看到，YC 伸張和壓縮要互相搭配，最終顯示出來的結果才正确。

如果：

A. 播放時

1. 轉 MPEG 的時候沒有做 YC 壓縮，儲存的是 0~255 的 YUV，播放時就不可以做 YC 伸張，否則 0~255 的資料再伸張一次，會變成 -19~278。

當然，8 bits 的資料儲存範圍隻能是 0~255，資料超出的範圍會被削掉（clipping），整個畫面對比會過強，色彩會崩潰。

2. 轉 MPEG 的時候有做 YC 壓縮，儲存的是 16~235 的 YUV，播放時就一定要做 YC 伸張，如果不做 YC 伸張，顯示的是 16~235 YUV -> 16~235 RGB。

RGB [235,235,235] 在顯示器上看起來不是純白，而會有點灰灰的，[255,255,255] 才是純白。

相同的，[16,16,16] 看起來也不會是純黑，[0,0,0] 才是純黑。

16~235 的 RGB，資料範圍（動态範圍）縮小，對比會變差，色彩黯淡，看上去好像蒙上了一層白紗。

顯示卡的 DirectDraw Overlay，使用硬體的 YUV -> RGB 色彩空間轉換，都會遵守 ITU-R BT.601 的建議，認為 MPEG 的 YUV 資料範圍應該是 16~235，是以都會做 YC 伸張。

是以我們可以得到結論，當轉成 MPEG 的時候，一定要確定 YUV 的資料範圍是 16~235，這樣在計算機上看、在電視上看，才會看到正确的色彩、對比表現。

是以

B. 壓縮時

1. 如果輸入的 RGB 資料範圍是 0~255，轉 MPEG-2 時就要先做 YC 壓縮，轉成 16~235 的 YUV，這樣将來播放時顯示才會正确。

2. 如果輸入的 RGB 資料範圍是 16~235，轉 MPEG-2 時就不能做 YC 壓縮，要直接轉成 16~235 的 YUV，這樣将來播放時顯示才會正确。

如果輸入的是 16~235 RGB，轉 MPEG 時又再做一次 YC 壓縮，資料範圍會變成 30~218 YUV，這樣即使将來播放時做 YC 伸張，還是隻能伸張到 16~235 的 RGB，結果還是不對。

那麼，重點就是

1. 怎麼知道輸入的訊源是 16~235 RGB，還是 0~255 RGB？

2. 怎麼知道壓縮的 MPEG 軟體在轉 RGB -> YUV 的時候會做 YC 壓縮，還是不做 YC 壓縮？

我們先看第一點，假設你的訊源是：

1. DivX/XviD 的 AVI，要轉 DVD/SVCD/VCD

DivX 和 XviD 都遵循 ITU-R BT.601 規範，解碼輸出 RGB 時都會做 YC 伸張，是以以 DivX/XviD 的 AVI 作為訊源，都是 0~255 範圍的 RGB。

2. 訊源是 DVD，或 HDTV 的 MPEG-2 TS，或其它 MPEG 檔案

看你用來解碼 MPEG，輸出 RGB 的軟體是哪一個，這個軟體解碼輸出的設定為何。

例如：

2a. 解碼軟體是 DVD2AVI，在 RGB -> YUV 的設定底下有兩個選項，一個叫做 PC Scale，另一個叫做 TV Scale。選 PC Scale，解碼就會使用 PC Scale 的轉換式，輸出 0~255 的 RGB；選 TV Scale，解碼就會輸出 16~235 的 RGB。

由上述的說明，我們可以知道 DVD2AVI 的一個運用：

當我們不勾選 DVD2AVI -> Help -> DirectDraw Overlay 時，DVD2AVI 不會啟動 DirectDraw Overlay，而是走傳統的 GDI 顯示方式，輸出 RGB 給顯示卡顯示。此時畫面上看到的色彩，會受 YUV -> RGB 選項底下設定的 PC/TV Scale 影響；選 TV Sclae，顔色黯淡；選 PC Scale，顔色正确。

當我們啟動 DirectDraw Overlay，此時畫面的顯示，是由 DVD2AVI 直接輸出 YUV，走 DirectDraw Overlay，丢給顯示卡去做 YUV -> RGB 的色彩空間轉換。此時畫面上顯示的顔色，由顯示卡決定，PC/TV Scale 的設定完全不影響看到的畫面。

而顯示卡的色空間轉換，如前所述，不亂搞的話，都是遵循 ITU-R BT.601，用 PC Scale。

在接下去說明之前，要先介紹兩個名詞：

0~255 的 RGB，又叫做 full-range RGB

16~235 的 RGB，又叫做 compressed-range RGB

更深入的介紹，有興趣的人可以參考 SGI 網站上的這一篇好文章

Digital Media Programming Guide Chapter 2. Digital Media Essentials

知道這兩個新名詞後，接着往下看

2b. 解碼軟體是 m2v，在 m2v 的設定畫面裡，YUV Range 底下有兩個選項讓你選擇，一個是 Full Range，另一個是 ITU-R BT.601 Range。怎麼樣，是不是覺得這兩個名詞很熟悉

相信看過上面的解釋，您應該可以猜到，選 Full Range 的意思是代表告訴 m2v，我的 YUV 資料範圍已經是 0~255 的 YUV 了，不要再做伸張了唷。是以選 Full Range，m2v 就不會做伸張，而是直接轉換。

相反的選 ITU-R BT.601 Range，就是告訴 m2v，我的 YUV 資料範圍是 16~235，輸出時請做 YC 伸張。

是以：

1) m2v 選 Full Range，等于 DVD2AVI 的 TV Scale，輸出時不做 YC 伸張，16~235 YUV 輸出的是 16~235 RGB。

2) m2v 選 ITU-R BT.601 Range，等于 DVD2AVI 的 PC Scale，輸出時會做 YC 伸張，16~235 YUV 輸出的是 0~255 的 RGB。

其它 MPEG Decoder，請自行實驗其輸出結果。

3. 如果訊源是 DV-AVI

看用來解碼的 DV Codec 是哪一個。

如果是 Canopus DV Codec，不會伸張，16~235。

如果是 MS DV Codec, Panasonic DV Codec，會伸張，0~255。

4. 訊源是用 PhotoShop 等繪圖軟體，自制的計算機動畫

無庸置疑，是 0~255 RGB。

OK，這樣我們就知道訊源是 0~255 還是 16~235 了，接下來，第二點，MPEG 壓縮軟體會不會做 YC 壓縮？

答案是，不同軟體有不同做法。我試驗過的幾個：

1. 可以自由切換選擇要不要做 YC 壓縮

TMPGEnc, CCE SP

2. 一律做 YC 壓縮，當成輸入的都是 0~255 RGB

MainConcept MPEG Enocder, Panansonic MPEG2&1 Encoder

DivX, XviD

3. 一律不做 YC 壓縮，當成輸入的都是 16~235 RGB

MPEG Conversion Studio, ProCoder。

我們以 TMPGEnc 為例

TMGEnc 選擇切換要不要做 YC 壓縮的選項，叫做 "Output YUV data as Basic YCbCr ont CCIR601"。

名詞解釋時間

0~255 YUV = full-range YUV，TMPGEnc 叫做 Basic YUV (YCbCr)。

16~235 YUV = compressed-range YUV = ITU-R BT.601 YUV，TMPGEnc 叫做 CCIR601 YUV。

勾選 "Output YUV data as Basic YCbCr ont CCIR601" 這個選項，TMPGEnc 就會認為要輸出的是 Basic YUV = 0~255 YUV，是以不做 YC 壓縮 ，直接轉換。

不勾選這個選項，TMPGEnc 會認為要輸出的是 CCIR601 YUV = 16~235 YUV，是以會做 YC 壓縮 ，轉成 16~235 YUV。

會不會很複雜，開始頭暈了？ ^^;

沒關系，我最後會總結整理成一個很簡單的清單，但是在此之前我必須先說明完原理，因為組合的情況有很多種，不同 Decoder 輸出不一樣，不同 MPEG 壓縮軟體的處理不一樣，我不可能有時間一一去測試所有的組合情況，是以唯有您自行了解原理，了解吸收了以後，遇到不同的組合，您才能知道要怎麼設定，而不 是隻死記一種做法，這也是為什麼我會不厭其煩地，再三地解釋、說明這些令人頭暈的道理 ^^;

那麼會有哪些組合的情況呢？

在 TMPGEnc 的網站上曾經出現過一篇很精彩的讨論，參與讨論的有 TMPGEnc 的作者崛老，還有 m2v 的作者 marumo（那位署名 "茂木" 的即是 marumo）。

在這篇讨論中崛老提到，"Output YUV data as Basic YCbCr ont CCIR601" 選項做的事情，是當 RGB -> YUV 的時候，使用不同的轉換式，不勾會做 YC 壓縮，勾了就不做 YC 壓縮。崛老還舉出了所有可能的情況，我把他翻譯過來給大家看：

http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc&cmd=topic&wparam=182

1. 當訊源不是 CCIR601 标準，也就是 (0~255) 時

不勾 ==> RGB(0~255) -> YUV(16~235) 正确 ^_^

勾 ==> RGB(0~255) -> YUV(0~255)

播放時會做伸張 YUV(0~255) -> RGB(-19~278) 超過 0 和 255 的資料都會被削掉，

畫面色彩崩潰，錯誤 >_<

2. 當訊源是 CCIR601 标準，也就是 (16~235) 時

不勾 ==> RGB(16~235) -> YUV(30~218) 顔色變淡、對比變差，畫面好像罩上了一層白霧 >_<

勾 ==> RGB(16~235) -> YUV(16~235) 正确 ^_^

然後崛老說像 Canopus DV Codec 這種 CCIR601 标準（不做伸張）的訊源，

要勾選才正确；反過來說，非 CCIR601 标準的訊源（做過伸張），不勾選才正确。

是以總結起來，如果訊源是 MPEG，用 DVD2AVI 解碼，則正确的做法

代碼 (輕按兩下代碼複制到粘貼闆)

DVD2AVI PC Scale -> 0~255 RGB -> TMPGEnc 不勾 "Output YUV data as Basic YCbCr ont CCIR601"















DVD2AVI TV Scale -> 16~235 RGB -> TMPGEnc 要勾 "Output YUV data as Basic YCbCr ont CCIR601"






      

同理，如果是 m2v 解碼

代碼 (輕按兩下代碼複制到粘貼闆)

m2v ITU-R BT.601 Range -> 0~255 RGB -> TMPGEnc 不勾















m2v Full Range -> 16~235 RGB -> TMPGEnc 要勾






      

如果用的是 CCE SP 來壓 MPEG，CCE SP 切換的選項在 Video 裡面，叫做 Luminance level，有兩個選項

16-235 = 做 YC 壓縮 = TMPGEnc 不勾 "Output YUV data as Basic YCbCr ont CCIR601"

0-255 = 不做 YC 壓縮 = TMPGEnc 勾 "Output YUV data as Basic YCbCr ont CCIR601"

是以

代碼 (輕按兩下代碼複制到粘貼闆)

DVD2AVI PC Scale -> 0~255 RGB -> CCE SP 選 "16-235"















DVD2AVI TV Scale -> 16~235 RGB -> CCE SP 選 "0-255"






      

m2v 的情況依此類推。

如果 MPEG 壓縮軟體不能切換 YC 壓縮的選項，例如 ProCoder，那怎麼辦？

我以前寫過一篇，轉貼過來，省打字時間

==

ProCoder 1.5 版有個重要的更新，ITU-R BT.601 color correction 設定，

可以讓你選擇要不要做 YC 壓縮，這是一個很重要的設定。

TMPGEnc 有這個設定，"Output YUV data as Basic YCbCr ont CCIR601"，

這個設定不是"改善"色深，而是做"正确"的選擇，保持本來的顔色。

本來就應該要根據輸入的訊源，正确的選擇切換這個選項，才能得到正确的結果。

這個選項不是用來"改善"或者是"補強"用的，不要弄錯了原本的意圖。

其它 MPEG 壓縮程式例如 CCE SP 也有相同的設定。

而 ProCoder v1.01.35 版沒有這個設定，一律将 input 視為是 CCIR601 YUV

（顔色範圍是 Y:16~235, UV:16~240），是以使用者無法根據使用的訊源做切換。

Canopus 本身的 DV Codec 便是輸出 CCIR601 YUV，其 RGB 範圍是 16~235，

剛好和 ProCoder 互相搭配。但是其它 DV Codec，例如 MS 的 DV Codec

Panasonic 的 DV Codec，輸出的則是 Basic YUV。

這樣壓縮 CCIR601 訊源時沒有問題，但是遇到 Basic YUV（顔色範圍是 YUV:0~255，

例如自行用計算機繪圖制作的 CG 動畫，做過 YC 伸張的 DVD/VCD/DV 訊源... 等等），

ProCoder 就慘了，壓出來的對比會過強，色彩會完全崩潰。

有時候 Basic YUV 的影片本身的對比、色彩并不是很強烈，經過 ProCoder 錯誤的壓縮後，

反而會讓人有"色彩變鮮豔了"的感覺，不過其實那反而不是原本的顔色。

如果影片本身的對比、色彩本來就很強烈，再經過錯誤壓縮，就會發生凄慘的"色崩"現象。

由于這個後果不是我們能預期、控制的，是以如果真要調整顔色，還不如用正确的色彩壓縮設定，

讓所見即所得，然後另外用調整顔色的濾鏡自行修改顔色，調整到我們需要的樣子。

由于 ProCoder v1.01.35 沒有提供切換 YC 壓縮的設定，是以遇到 Basic YUV 訊源，

在送給 ProCoder 壓縮之前，你需要先自行用其它軟體，将 Basic YUV 轉為 CCIR601 YUV，

再送給 ProCoder 壓縮，色彩才會正确。

Avisynth, AviUtl 都有這個轉換的功能。

==

也就是說如果要給 ProCoder 壓縮，DVD2AVI 一定要選 TV Scale 輸出，m2v 一定要選 Full Range 輸出，如果是使用其它不能選擇輸出模式的 MPEG Decoder，隻好用 AviUtl/Avisynth 的 filter 做後制處理。

OK，基本的講完了 ^^;

接下來進階讨論（我的手好酸 ><）...

1. 以上講的是訊源都是 RGB，壓 MPEG 時要做 RGB -> YUV，如果訊源是 YUV，則如何設定？

當訊源已經是 YUV 時，就不用去管 YC 伸張壓縮的設定。

例如用 MainConcept MPEG Encoder 壓 DV-AVI，用 Canopus DV Codec 解碼，MainConcept MPEG Encoder RGB -> YUV 一律做 YC 壓縮，照理說顔色會變淡。但是由于 MainConcept MPEG Encoder 可以接收 YUY2 輸入，是以 Canopus DV Codec 會直接輸出 16~235 YUY2 給 MainConcept MPEG Encoder，這樣一來，就跳過了 RGB -> YUV 的步驟，當然也就沒有 YC 壓縮的問題，是以也就不會出現顔色不正确的情況。

然而如果是 TMPGEnc，以及有用到 VFAPI，因為 VFAPI 都要轉成 RGB 處理，是以仍需注意 YC 伸張壓縮的設定。

例如如果用 TMPGEnc 壓 DV-AVI，一樣用 Canopus DV Codec 解碼，用預設值轉換式，輸出的是 16~235 RGB，是以便要勾 "Output YUV data as Basic YCbCr ont CCIR601"。

2. 解碼時做 YC 伸張的優缺點？

a. 優點

1) 所見即所得，螢幕上見到的樣子，就是将來壓好 MPEG 解碼輸出的樣子，這樣做後制處理時，比較容易調整。

2) 大部分 MPEG Encoder 都是認為會接收 0~255 RGB 的輸入，是以 RGB -> YUV 時都會作 YC 壓縮，是以訊源在作解碼時一定要作 YC 伸張，才會正确。

b. 缺點

1) 0~255，8 bits 的範圍全用光了，沒有留下運算時需要的 headroom。

2) Source (16~235 YUV) -> 0~255 RGB -> MPEG (16~235 YUV)

YC 伸張後再壓縮，會有一點損失

YC 伸張計算式

Y' = (Y - 16) * 255 / (235 - 16)

C' = C * 255 / (255 - (240-16))

CCE SP 的說明書中，解釋 16-235 和 0-255 選項的作用時，有列直接轉換，和 YC 壓縮轉換所使用的不同的計算式

"16-235" --> YC 壓縮轉換

Rd = 219*R + 16*256

Gd = 219*G + 16*256

Bd = 219*B + 16*256

"0-255" --> 直接轉換

如上列所見，這個轉換式有小數點，需要舍棄進位，是以反複多次 YC 壓縮伸張 RGB <-> YUV 變換，畫質會有一點損失。

3. 其它 Codec 輸出的情形怎麼樣？我用 PICVideo MJPEG Codec 采集電視節目，PICVideo MJPEG Codec 是用什麼轉換式？

PICVideo MJPEG Codec 用直接轉換式

遇到其它 Codec，請自行實驗，因為不同版本的 Codec 會有不同作法，例如 Panasonic DV Codec 不同版本輸出的情形都不一樣，作者不可能一一位大家測試完所有的軟硬體組合。

可以用 PhotoShop 生成一張 RGB [235,235,235] 的 BMP，送給 Codec 壓縮，看壓縮後輸出的畫面，是純白的 [255,255,255]，還是更灰的 [218,218,218]，以此判斷。

還有不同采集卡、不同版本的 driver，采集下來的色域範圍都不一樣。例如 CONEXANT CX23881 晶片采集下來的色域範圍是 0~255，不用再做伸張；Philips SAA7134HL 采集下來的範圍則是 16~235，要再做 YC 伸張。請看這個網頁的比較圖

http://anipeg.yks.ne.jp/topic.html

是以 SAA7134HL 卡采集下來的顔色很黯淡，不如 CX23881 鮮豔，但是我們不可以說 SAA7134HL 就比 CX23881 爛，不是這樣的。SAA7134HL 做完 YC 伸張後不見得比 CX23881 差，這是設定的問題 ， 不是硬體的問題。使用的人要明白原理，要知道根據訊源，自己切換調整設定。

拿到一張采集卡，拿到新的軟體，首先要作的就是色彩校正，專業的 studio 會用 Vector Scope 來校正顔色。關于色彩校正，以前也寫過很多，我轉一點過來貼在下面，不過為了集中讨論主題，我隻轉貼部分，輕輕帶過

==

色域範圍是看 chip 的 ADC 設計，例如 Philips SAA7111A 8bit ADC，取樣的時候 0 是同步訊号，而黑色 level 則是 60，白色 210。然後 chip 會利用 Brightness 和 Contrast 這兩個參數調整（scaling）到 16~235 的标準 CCIR601 範圍輸出。

算式是

Y(out) = int[CONT/71 * (Y-128)] + BRIG

CbCr(out) = int[SATN/64 *(Cb, Cr -128)] + 128

是以 Philips SAA7111A 的解析能力隻有 60~210。

[中略]

AviUtl 的 波形表示 Plugin 的用法，可以看 GNB神樣 的說明

http://homepage2.nifty.com/GNB/tutorial/s_scope/s_scope.htm

他測試的是 I/O DATA GV-MPEG2/PCI 這張卡，用 VIDEO ESSENTIALS 這張測試用的 DVD 裡面的 Colorbar 作測試，以 S6D 播放輸入，GV-MPEG2 用 MPEG2 Max8Mbps VBR 的模闆，預設值「Brightness: 121, Contrast: 65, Saturation: 65, Hue: 0」撷取壓成 MPEG-2，然後用 marumo神樣 的「MPEG-2 VIDEO VFAPI Plug-In」解碼。MPEG-2 VIDEO VFAPI Plug-In 可以設定解碼輸出時要不要作 YC 伸張，選「換」（直接變換，英文版的選項是寫 Full Range），也就是不作 YC 伸張，然後作測試調整。

首先先利用 Colorbar 下方的黑白 pattern 來測亮度範圍，看波形顯示

調整 Brightness 和 Contrast 把亮度（白色線）調整到對齊「100%輝度」（Y: 235）和「0%輝度」（Y: 16）那兩條線

「Brightness: 131, Contrast: 63, Saturation: 65, Hue: 0」

參考上面列的 chip scaling 的算式。

接下看 Vector Scope，利用 Colorbar 上方那一排 Yl(黃)/Cy(藍綠)/G(綠)/Mg(紫紅)/R(紅)/B(藍) 的 pattern 調整顔色

頂點要落在十字的中心點上，距離代表 Saturation（飽和度），角度代表 Hue（色相）

調高 Saturation + 15

調低 Saturation - 15

調高 Hue + 10

調低 Hue - 10

最後調整結果「Brightness: 131, Contrast: 63, Saturation: 61, Hue: +2」

完畢。

以上圖檔均來自上面貼的 GNB神樣 的網站，我隻是轉一點過來做簡單的說明，網站上有更豐富更完整的使用步驟，請大家一定要去看一看。看完以後再看最前面提供的那幾個網址應該就沒有問題了。

專業的 Scope Vector 向量分析儀和測試 pattern 産生器非常貴，一般人隻好用這種簡陋的方法作調整。調整不良的結果就像黃疸少女一樣，是個活生生血淋淋的教訓 :P

關于黃疸少女、專業校色、Vector Scope Monitor，請看 jackei神樣 的解說

http://www.myav.com.tw/vbb221/upload/showthread.php?s=&threadid=38766&perpage=12&pagenumber=17

==

以上是簡略地介紹

更多采集卡校正的說明，請看下面的網頁，小弟這裡就不詳述了 ^^;

http://cwaweb.bai.ne.jp/~icchan/Data/color/colorbar.htm

http://cwaweb.bai.ne.jp/~icchan/Data/color/CCIR601.htm

http://cwaweb.bai.ne.jp/~icchan/Data/color/SMPTE.htm

http://cwaweb.bai.ne.jp/~icchan/Data/iro.htm

4. 怎麼講到采集卡去了？前面提到 m2v/DVD2AVI 的 chroma upsampling 才是對的，其它 MPEG-2 Decoder 大部分都是錯的，什麼是 chroma upsampling error？

以前有很詳細地說明。

chroma upsampling error 看起來像下面那樣

正确應該是這樣

簡單的說

1. YUV 4:2:0（YV12）上下兩行掃瞄線要共享一個 UV 取樣，是以 720x576 的 DVD，Y 的像素點是 720x576 個，UV 各是 360x288 個，垂直少了一半的 UV。4:2:0 upsample 到 YUV 4:2:2（YUY2），上下兩行就不共享一個，而是使用各自的 UV，是以 UV 就變成 360x576。當然 YUV 4:4:4 就是 720x576。

2. 循序（Progressive）畫面，相鄰的上下兩行屬于同一個畫面，是以取樣的時候會拿相鄰的兩行來取樣一個 UV，也就是 chroma = (chroma1 + chroma2)/2

解壓縮的時候，解出來的 chroma 要分給 line1 和 line2。

交錯（Interlaced）畫面，由奇、偶兩個 Field 組成，相鄰的兩行不屬于同一個 Field，要隔一行的掃瞄線，才是屬于同一個 Field。是以取樣的時候，要拿隔行的兩條掃瞄線來取樣

chroma = 0.75*chroma1 + 0.25*chroma3

解壓縮的時候，解出來的 chroma 要分給 line1 和隔行的 line3。

3. 由上可知，MPEG-2 Decoder，必須要準備兩種 upsampling 的計算式，循序畫面用 chroma = (chroma1 + chroma2)/2，交錯畫面用 chroma = 0.75*chroma1 + 0.25*chroma3，如果隻用一種轉換式通吃所有情況，就會發生 chroma upsampling 錯誤。

我舉 Doom9 過去的一個讨論做為例子

http://forum.doom9.org/showthread.php?s=&threadid=48163&perpage=20

首先是 kilg0r3 發現他做的 encoded 會發生"色階"的現象，顔色會有很明顯的階梯狀，尤其是紅色特别明顯。他反複實驗了許多次，發現這個現象不論是 MPEGDecoder, MPEG2Dec3 做 YV12 輸出的時候都有，但是用 DVD2AVI 卻沒有這個問題。

Avisynth 目前的開發者 sh0dan 對這個問題很感興趣，他提供了一些解決的辦法，不過都沒有奏效。kilg0r3 繼續尋找問題的根源..... 這時大家的結論是這是 YV12 格式的缺陷，因為 YV12 格式兩行共享一個 chroma，很容易造成顔色呈階梯狀的現象。解決的辦法是用比較好的 FIR filter 做 upsampling 到 YUY2/RGB，例如 DVD2AVI 用了 6-tap FIR filter，這樣會使 chroma 變得模糊，但是可以解決明顯的色階現象。

OK, 事情至此似乎告一段落，不過寫 MPEG3DEC 的 trbarry 大俠突然插進來，提供了一個連結

The Croma Upsampling Problem

相信這個連結大家應該看過很多次

這個連結裡面說明了，部分硬體的 DVD Player 隻有 Interlaced chroma upsampling 的方法，是以遇到 Progressive 的訊源，就會發生明顯的色階現象。這裡面提到了兩個重要的觀念：

1. DVD 存的 Frame，有 Interlaced 和 Progressive 兩種，由一個旗标叫做 progressive_frame 來訓示

2. decoder 要根據這個旗标，切換 YV12 -> YUY2 的 upsampling 方法，upsampling 的結果才會正确

是以 DVD2AVI 能解決色階現象，不隻是因為它用了比較好的 FIR filter，更是因為它能根據 progressive_frame 旗标，做正确的 upsampling 解碼。

The Croma Upsampling Problem 的網頁上，往下拉，搜尋 "Toy Story" Menu 這一段，有提供範例圖檔。上下左右四張圖，左邊的那兩張是有用正确 upsampling 解碼的結果，上面是沒有 filtering，下面是使用 6-tap FIR filter，畫質最好。右邊的那兩張是錯誤的 upsampling 解碼的結果，上面沒有 filtering 的，色階很明顯，而下面用 6-tap FIR filter 處理的，色階就比較沒有那麼明顯，但是畫質還是不如正确解碼的結果。

看了這個連結之後，sh0dan 的結論是「I think the conclusion is "there is no better quality in YV12". Chroma is subsampled and in extreme cases like this it shows. The only thing that will help is smoothing chroma - even though what also has sideeffects.」。

smoothing chroma 的意思就是使用高 tap 數的 FIR filter 做 upsampling，能讓 chroma 比較平滑，不會有那麼明顯的色階。

于是最後 kilg0r3 就提了一個問題「how do you determine if a vob is interlaced/progressive on the chroma/luma plane?」。

這個問題問得不太對，luma 沒有 Interlaced 的問題，隻有 chroma 才有 Interlaced 的問題，不過就不管他了

trbarry 大俠的回答是「I guess if you have problem material and you don't know if it is coded progressive/interlaced (or it's mixed) then you could always use MPEG2DEC2. There is a version around somewhere here that even works with Avisynth 2.5.

But MPEG2DEC2 will return YUY2 that has been converted on a frame by frame basis looking at the MPEG-2 flags and deciding which type of conversion to do.」

由上可知，MPEG2DEC2 會一個 frame 一個 frame 地，根據 progressive_frame 這個 MPEG-2 旗标（flag），正确的切換 upsampling 計算式，輸出 YUY2。

而大部分的軟體 MPEG-2 Decoder，例如 WinDVD，隻使用 Progressive 的 upsampling 計算式，是以遇到交錯畫面，凄凄慘慘，完全錯誤。

要用 m2v/DVD2AVI/MPEG2DEC2 等能正确解碼交錯畫面的 Decoder，才能得到正确的結果。

下面是題外話，每次講到這個我就要為 DVD2AVI 申冤

==

DVD 有兩種儲存的畫面結構，一種是 Interlaced，一種是 Progressive，由 progressive_frame 這個旗标訓示。

Interlaced 和 Progressive 隻是表示這個畫面當初在取樣的時候，是以 Interlaced 的方式取樣，還是以 Progressive 的方式取樣。是将畫面視為一個完整的 Frame，以 Progressive 取樣，chroma = (c1+c2)/2，取樣成 progressive chroma，還是将畫面視為是由奇偶兩個 Field 所組成，以 Interlaced 取樣，chroma = 0.75*c1 + 0.25*c3，取樣為 interlaced chroma。

是以這隻是一個取樣的方式，和畫面上是否真的有交錯的瑕疵無關，和這個畫面是否真的是一個交錯的畫面無關。笨蛋的 encoder，即使是畫面明明都無交錯，每一張都是 Progressive Frame，encoder 還是可以以 Interlaced 的方式取樣。

這時候 DVD2AVI 的 Frame Type 會顯示這是 Interlaced Frame，但是畫面上明明沒有交錯。

DVD2AVI 的 Frame Type，是根據 progressive_frame 這個旗标來顯示，是以它顯示的是這個 Frame 的原始取樣方式。

不知道這個道理的人，就會說 DVD2AVI 的 Frame Type 顯示是錯的，明明畫面沒有交錯，但是 DVD2AVI 會顯示 Interlaced，是以許多人說 DVD2AVI 的顯示是錯的，不要相信。

例如 Doom9 讨論區，這種錯誤的說法一堆。

其實這是因為他們不懂真正的道理，DVD2AVI 并沒有顯示錯誤，Frame Type 顯示的是取樣方式，和畫面是否真的有交錯無關。DVD2AVI 從來沒有去分析畫面，去比較畫面的奇偶差異，判斷這個畫面是否有交錯。它隻是很簡單地讀取 MPEG-2 stream 裡面的 progressive_frame 旗标，按照旗标顯示，訓示這個 Frame 當初壓縮時是用哪種取樣方式，解壓縮時要用哪種 upsampling 方法才會正确。

分析畫面、比較畫面奇偶、判斷是否交錯，那是 IVTC plugin 做的事情。

==

如果是這樣的話，那麼直接的用預設的limiter還錯了，因為它已經将range clip到16~235, 交給XviD, XviD又會作一次yc壓縮, busted....

而應該Limiter(clip, 0, 255, 0, 255)?

edit:

或者 limiter() 隻是做 clipping, 并不是做yc壓縮, 是以

limiter()和

Limiter(0, 255, 0, 255)

都是可以的. 因為到此還沒有作yc壓縮, 後面XviD會yc壓縮一次, 播放解碼時伸張一次.

Limiter()隻是Limiter(0, 255, 0, 255)的子區間而已, 主要用于那些不做yc壓縮的codec...

這樣的話若做過一些色彩上的處理後打算交給XviD/DivX, 在avs最後要用Limiter(0, 255, 0, 255), 而且必須用.

或者哪個人直接對我說:" 你已經瘋了!"

喔喔，您已經混亂了

如果是直接 YUV 的做法，也就是隻用 avisynth，在 avisynth 内部做處理，輸出 YUV 給 XviD/DivX 壓縮，不用擔心 YUV 範圍的問題。

前面有提到，YC 伸張壓縮的問題，隻在有經過 YUV -> RGB, RGB-> YUV 轉換的時候才會發生，如果是原始 YUV 資料，不用去動它，直接送給 XviD 即可，XviD 不會對 YUV 的輸入做任何伸張或壓縮的動作。

XviD 隻有在輸入是 RGB 的時候，RGB -> YUV 轉換時才會順便做 YC 壓縮。

是以前面說，如果你沒有用到 VFAPI(RGB24)，不經過 VFAPI 做中介，而是直接 YUV -> YUV，也就是一般人用 avisynth 的做法，不用考慮 YC 伸張壓縮的問題。

而您提到的要不要用 limiter 做 clip，把 YUV 的 data 切到符合 BT.601 的标準，可以這麼做。

有些 DVD 上的資料，YUV 的資料範圍會超過 BT.601 的标準一點點，這是因為 MPEG 壓縮造成誤差的關系，原本 BT.601 保留 0~15/236~255 的設計就是多留一點空間作為緩沖，是以 DVD 上的 YUV 超出範圍一點是正常的。

那我們需不需要把這些超出的資料切到 16/235 呢？是可以的，但是有沒有必要，我就不清楚了

用 VFAPI 的方式加載，m2v 會輸出 RGB。

但是用 Avisynth 的優點，就是不用經過 YUV -> RGB 的轉換。

其實 m2v 除了是一個 VFAPI 的 plugin 以外，它同時也是一個 AviUtl 的 plugin，而 AviUtl 可以接收 YUY2 的輸入，其内部工作以 YUV 處理，是以 m2v 當然也可以直接輸出 YUY2。

把 m2v.vfp 更名為 m2v.aui，丢到 AviUtl 的目錄下，開啟 AviUtl，你會發現 AviUtl 多了一個 Input Plugin 叫做 m2v，用這個 m2v 解碼，輸入的就會是 YUY2，而不像以前用 m2v.vfp 輸入的是 RGB。

而我們可以在 Avisynth 裡面直接調用 AviUtl 的 Input Plugin，Avisynth 有一個外挂叫做 loadaui，就是專門在做加載 aui 的工作

# 加載 LoadPluginEx，這樣下面才能加載 2.0.x 版的 loadaui plugin

LoadPlugin("c:/Program Files/AviSynth2/plugins/LoadPluginEx.dll")

# 加載 loadaui，讓 Avisynth 可以加載任何 AviUtl 的 input plugin

LoadPlugin("c:/Program Files/AviSynth2/plugins/loadaui.dll")

# 載入 m2v.aui，并将這個 plugin 的 function 命名為 "MPEG2VIDEO"

LoadAviUtlInputPlugin("c:/AviUtl/98d/m2v.aui", "MPEG2VIDEO")

# 用 MPEG2VIDEO 解碼

MPEG2VIDEO("source.m2v")

這樣輸出的就會是 YUY2。

另外 AviUtl 也可以直接開啟 avs 檔案，接收 YUY2 的輸入。

是以許多軟體都可以來個友情大合體

大家互相幫忙，截長補短

感謝 csr2000 兄幫忙補充，我太久沒用了，還活在舊時代

剛好 winsen 兄貼出 m2v 的設定，小弟前曾提過，HDTV 的訊源要用 m2v 解碼顔色才正确，那時沒力繼續解釋下去，現在趁這個機會做個簡短的補充

==

Aspect Ratio

要不要做 resize 成最接近的顯示比例。

建議 Ignore，不要用 m2v 做 resize。

因為 m2v 做 resize 比例不正确，

且 resize 的大小不一定符合我們需要的大小，

例如 720x480 顯示比例 4:3，m2v 會 resize -> 640x480，但是我們不一定要 640x480，說不定我們想做 512x384，這樣還是要再自己 resize 一次，不如從頭就 720x480 -> 704x480 -> 512x384。

Field Order

Field 奇先偶先順序

iDCT Algorithm

iDCT 轉換的算法

SIMD

支援的 SIMD

GOP List

.gl 的設定

Consecutive Numbered Files

連号檔案讀取設定

YUV Range

Full Range: YUV -> RGB 時，不要做 YC 伸張

ITU-R BT.601 Range: 做 YC 伸張

Default Matrix Coefficient

YUV -> RGB 轉換時，要使用哪一種規格的轉換式。

選 Auto(From Video Resolution)，如果 MPEG 檔有 sequence_display_extension header，裡面有紀錄 Matrix Coefficient，就用記錄的 Matrix Coefficient 的轉換式來做轉換。如果 MPEG 檔案沒有紀錄 Matrix Coefficient，m2v 自動利用 Video 的分辨率大小做判斷，如果分辨率超過 720x576，自動用 HDTV 的 ITU-R BT.709 轉換式轉換；如果分辨率等于或小于 720x576，使用原本的 ITU-R BT.601 轉換式轉換。

兩個轉換式轉出來色調會有一點差異，HDTV 是采用 709 規格，要用 709 轉換式轉出來色彩才會正确。

遇到 MPEG 檔内的 Matrix Coefficient 不能信用時，例如明明是 SDTV 的訊源，卻用 709 轉換式，可能是電視台制作時旗标設錯了，這時可以手動指定正确的轉換式。

YUY2 Matrix(for m2v.aui)

m2v.vfp 同時是一個 AviUtl 的 plugin。

将 m2v.vfp 更名為 m2v.aui 即可當成一個 AviUtl 的 Input Plugin 來使用。

此時 m2v.aui 輸出的是 YUY2，而不像原本的 VFAPI Plugin，輸出的是 RGB，需要做 YUV -> RGB 轉換。

如果現在訊源是 HDTV 的 709YC，直接輸出 709YC 給 AviUtl 之後，就算中間的處理過程都不需要轉成 RGB，最後壓成 MPEG-4 時，儲存的還是 709YC。

這樣播放時，如果由 MPEG-4 decoder 輸出 RGB，MPEG-4 decoder 都是用 601 轉換式做 YUV -> RGB 的工作，是以 709YC ->(601 轉換式) 錯誤的RGB

如果用 DirectDraw Overlay，走 YV12 或 YUY2 丢資料給顯示卡去做 YUV -> RGB 的轉換工作，顯示卡的 YUV -> RGB 轉換式還是一樣使用 601 标準轉，709YC ->(601 轉換式) 錯誤的RGB

是以 m2v 設計了這個選項，當 m2v 直接輸出 YUY2 的時候，如果訊源本身是 709YC，可以先将 709YC 轉換為 601YC，這樣以後處理或顯示，都不會有問題。

YUY2 Matrix 選項就是在做這個設定，輸出時要保留原本 YUV 的資料，還是轉成其它規格的 YUV。

Avisynth 有個 BT709ToBT601 的 filter 就是在做同樣的事情。

引用
引用 rain009 發表的貼子: 根據Silky的解釋， S-Frame 是表示 sprite coding frame. 根據我的了解，主要用在背景相對不變，畫面中主體移動的視訊中。比如網球比賽。把臨近的幾幀結合起來得到一個整個場景的sprite frame, 而每一個幀都用這個sprite frame 來作參照壓縮。

是的，您說的沒錯。

引用
這是我的了解，似乎和兄台解釋的有出入。

沒有啊，我上面也是這麼解釋的：

引用
S-VOP 代表 Sprite VOP，MPEG-4 可以将靜态的背景畫面單獨切割出來，同一個場景， 好幾個畫面會用同一個背景，将背景切割出來，把好幾個畫面的背景連接配接起來，做一次壓縮。

不過 XviD 和 DivX 都沒有實作 sprite coding，這裡說的 S-Frame，指的是 S(GMC)-VOP，是以我上面說：

引用
當動态旗标和 GMC 旗标都 == 1 時，這個 VOP 叫做 S(GMC)-VOP， 也就是利用 GMC 做壓縮的 VOP。由于它和靜态的 Sprite VOP 不同，是以我們特别在 S 後面 加上 (GMC) 來标示，這是一個有用到動态 GMC 的 VOP。

雖然都叫 S-VOP，但是當 GMC flag == 1 的時候，代表這個 VOP 是 S(GMC)-VOP，用的壓縮方法是 GMC，這和原本靜态的 Sprite VOP 不同喔。是以我們把這種 VOP 特别表記為 S(GMC)- VOP 以示差別。

GMC 的壓縮原理在别的文章裡有簡單的說明。

引用
雖然在MPEG4 中有video object plane 這樣的定義，但是現在的MPEG4已經做到成熟的object encode 麼？其中的object 是怎麼分出來的？:rolleyes: 是用給出的mask麼？

規格上隻有告訴我們要切割，把每個 object 切出來，但是它沒跟我們說要怎麼切，反正不管怎麼做，能切出來就對了，切割的 algorithm 沒有規定，請我們自行研究

目前 DivX 和 XviD 都沒有這個功能，其它 MPEG-4 軟體，有些有做，例如 MS 的那個範例程式就有這個功能。不過範例程式當然是很陽春，并沒有最佳化，隻是示範，大緻上是這樣做.... 給我們做參考

引用
另外H.264也會用于視訊壓縮麼？這個系列的目标是video conferencing 吧？

因為畫質很好，是以有考慮用在一般多媒體媒體的視訊壓縮上使用。

rrv 的部分是偉大的 skal 寫的（

）（skal 應該算是 XviD 之神了

），我不太清楚他有沒有做這樣的判斷，應該是有，不過可能沒有仔細調整修改過，是以判斷不一定是最佳的情況。

因為 rrv 隻能用在 ARTS Profile，而 ARTS 不能合并使用 B-frame/Qpel/GMC 等功能，主要目的是網絡實時視訊傳輸、低解碼延遲使用，運用範圍比較小，而當時 XviD 的主要目标是把 AS Profile 的功能實作完善完成，是以 skal 提出來沒多久把程式碼合并進去，就沒有人再繼續發展改良。

事實上這個功能很早就有了，去年就有了，但是 vfw 接口中一直沒有把這個選項開啟，第一個開啟并且公開放出來的人，應該就是 cynix 大神

XviD 1.0 以後，接下來的目标是 Main Profile 和最高階的 Studio Profile，是以大概也不會回頭去改良 rrv。Studio Profile 支援超高分辨率，超高碼率，取樣由 4:2:0 擴充到 4:2:2~4:4:4，量化由 8bit 擴充到 10~12bit，是專業廣播級、品質最高的 MPEG-4 壓縮。

SONY 在今年 NAB 上發表的業務用新規格"HDCAM SR"，用的就是 Studio Profile 的 MPEG-4 壓縮。

●HDCAM SRフォーマットの概要 (HDCAM SR 格式簡介)

圧縮方式； MPEG-4 studio profile

イメージフォーマット (圖像格式)； 1,920×1,080（CIF規格に準拠）または1,280×720

サンプリングレート (採樣率)/量子化bit數(映像)； RGB 4:4:4 またはYPbPr 4:2:2／10bit

サンプリングレート (採樣率)/量子化bit數(音聲)； 48kHz／24bit（音聲トラック (聲道數)；12ch）

対応フィールド/フレームレート (field/framerate)； 1,920×1,080…23.98P,24P,25P,29.97P,30P,50i,59.94i

1,280×720…59.94P

データレート（映像） (datarate)； 約440Mbps

http://www.sony.jp/CorporateCruise/Press/200303/03-0305B/

對了 alexheart 兄提到 rrv 讓他想到 MipSmooth，MipSmooth 的 Mip 是從 3D 繪圖的術語 MipMap 來的，那麼什麼是 MipMap 呢？

有一位非常非常了不起的 Hotball 大大曾寫過有關 MipMap 的文章，我不會解釋得比他更好（

），有興趣的人，可以看這篇非常值得一看的 MipMap 說明

http://www.csie.ntu.edu.tw/~r89004/hive/mipmap/page_1.html

網站上還有其它 Hotball 大大寫精彩文章，例如 FSAA, Anti-aliasing 的理論，還有 CPU 的 cache 和 latency 等等，非常好看，推薦給大家

http://hotball.webhop.net/

LCD 有點和 CRT 螢幕不一樣，LCD 是數字的，它上面的液晶分子的個數是有限個，也就是它能表現的分辨率受限于先天的實體限制，是有限的，我們叫做 LCD 的"原生"分辨率。譬如說現在 17" 的 LCD 的原生分辨率通常是 1280x1024 個 pixels。

當然 CRT 受限于熒光塗布的技術和模拟頻寬，也有它的分辨率上限，但是和 LCD 不同的是，LCD 的每個分子都要對應到一個 pixel，譬如說現在桌面分辨率設為 1280x1024，直接每個 pixel 的數字資料送到 LCD 上，就直接對應它要顯示的分子。是以如果今天我桌面分辨率設為 640x480，隻有 640x480 個 pixels 的數字資料，送到 LCD 上要怎麼顯示呢？LCD 都有内建 scaler，做數字縮放的動作，640x480 的資料送進來，都要經過 scaler upsampling 到原生分辨率 1280x1024，然後才能顯示。

是以注意到了沒，這和 CRT 的模拟掃瞄顯示方式是不一樣的，CRT 接受 640x480 轉成的模拟訊号，頻寬多少就掃瞄多少，CRT 螢幕不需要内建 scaler。

而在 LCD 上，我們可以調整為 640x480 輸出，這時顯示的流程是這樣：

系統記憶體 原始 640x480 -> 顯示卡 frame buffer 640x480 數字輸出 -> LCD scaling -> 1280x1024 顯示

或者用 1280x1204 輸出：

系統記憶體 原始 640x480 overlay -> 顯示卡 scaling 1280x1024 數字輸出 -> LCD 1280x1024 顯示

是以在 LCD 螢幕上看影片，切換到 640x480 顯示，可能有兩種情況：

1. 畫質變好。因為 LCD 内建的 scaler 比顯示卡的 scaler 好。

2. 畫質變差。因為 LCD 内建的 scaler 比顯示卡的 scaler 差。

絕大部分的情況，都是 2.。

是以用 LCD 看影片反而建議用原生分辨率。

問題又來了，1280x1024 不是标準 4:3 呀，scaling 之後會變形。

這也是長久以來 LCD 一直為人所诟病的地方，我們一直搞不懂當初為什麼要設計 1280x1024 這種詭異的比例。

有些 LCD 的設計比較優良，當桌面分辨率為 4:3 輸入時，例如 1280x968，它不會 scaling 到全滿造成畫面變形，而會上下留黑邊，維持 4:3 的顯示比例。

買 LCD 時要留意有沒有這個功能設計。

關于 LCD 和 CRT 螢幕孰優孰劣，我想各大顯示器論壇已經讨論過許多次，兩者各有優缺點，我不是這方面的專家，不過大家可以上網絡找資料，什麼 Plasma, LCD, CRT, DLP, ... 等等一堆顯示技術，各自優缺點，以及怎麼克服缺點所研發的新技術等等，很有趣，可以看一看

小弟做個補充，其實并不是 MPEG2Dec3 的 chroma upsampling 錯誤，而是隻輸出 yv12(YUV 4:2:0) 的話，要顯示在螢幕上讓我們看到，後續必須做 YUV 4:2:0 -> YUV 4:2:2 -> YUV 4:4:4 -> RGB 的轉換才行。

而 MPEG2Dec3 隻輸出 yv12 的話，後續的工作是由系統上的 yv12 decoder 來做的，例如有裝 DivX 5，便會由 DivX 5 來解碼 yv12。

而 DivX 5 解碼 yv12，他無法從原始的 MPEG-2 stream 中得知哪些畫面是 interlaced 哪些畫面是 progressive 的，avisynth 交給它的時候就已經是解碼完畢的 yv12 資料了。是以 DivX 5 隻好「盲目的」做 upsampling，DivX 會假設所有的畫面都是已經經過去交錯處理之後的 progressive 畫面，一律用 progressive 的方法做 upsampling，這樣交錯畫面就會發生 upsampling 的錯誤。

是以問題不在 MPEG2Dec3 上面，而是隻要輸出的是 yv12，就會有這個問題。

yv12 格式，上下兩行會共享一組 UV

Y Y

Y Y + UV

如果我們讓 MPEG2Dec3 輸出 YUY2(YUV 4:2:2)，讓 MPEG2Dec3 先自己 upsampling 到 4:2:2 格式，

YUY2 格式，上下兩行不共享 UV，而是分别有自己的 UV

Y Y + UV

Y Y + UV

這樣就不會有隔行、交錯 UV 的問題，後面不管用什麼 decoder 解輸出的 YUY2，都不會有問題。

MPEG2Dec3 本身有一個指令叫做

YV12ToYUY2()

用這個指令就可以将 MPEG2Dec3 輸出的 yv12 轉為 yuy2，而且這個 yv12->yuy2 是根據 MPEG-2 stream 的旗标訓示，做正确的 upsampling，這樣就可以輸出正确的結果。

是以其實 MPEG2Dec3 解碼 chroma 是正确的，隻是一定要用 yuy2 輸出。

那麼又有一個問題了，也就是說如果要 chroma 正确，一定要轉為 yuy2 格式，那麼就不能用全程 yv12 制程了？

是的，确實是如此。但是大部分的人在制作影片的時候不會直接就這樣壓縮交錯的畫面，他們會先做 IVTC 或去交錯，把畫面轉為 progressive 之後再壓縮，例如

1. MPEG2Dec3 輸出 yv12 --> 經過 decomb IVTC --> decomb 會組合交錯最小的畫面，輸出正确的 progressive 畫面 --> 這樣的 progressive 畫面就不會有 chroma upsampling 的問題，至少在 progressive 畫面中造成的影響不明顯。

搭配 decomb 的時候建議喂給它 yv12 格式，decomb 在 yv12 格式下運作的效果比較好，如果要轉為 yuy2，經過 decomb IVTC 之後再轉為 yuy2

Mpeg2Source("source.d2v")

Telecide()

YV12ToYUY2()

2. 如果 decomb 組合失敗，輸出交錯的 frame，這個 frame 一般我們也不會把它擺着，而會對它再做去交錯，去交錯之後，chroma upsampling 的影響也會減小。

是以如果不是很講究，用 yv12 輸出搭配 decomb，結果還是可以令人接受的，全程 yv12 制程還是有它的好處，速度快

是以不一定強求一定要用 M2V 做解碼。

有些 DVD 做得很好，整片 Film 率 99%，而且所有畫面都是 progressive picture（DVD2AVI 從頭到尾都顯示 "Progressive"），這種 DVD 用 MPEG2Dec3 解碼也不會有任何問題。

總結以上，我們知道輸出 yv12 遇到交錯畫面就一定會有問題，不管用什麼解碼器解碼都一樣，是以過去 WinDVD 解碼是錯誤的，經過衆人反應之後，WinDVD 5 的 chroma 解碼已經變成正确的 ^_^，你注意觀察它的輸出格式會發現，過去 WinDVD 用的是 YV12 Overlay 輸出，現在用的是 YUY2 Overlay 輸出，就是以上這個原因。

以前 csr2000 兄有寫過一個教程，和那個網頁上差不多，大緻上是

1. 用 FPSCHK 載入 .d2v 檔案，掃瞄影片哪些部分是 24p，哪些部分是 30p，将結果存成一個 .idx 檔案。

FPSCHK, Dec60, AVI60 在這裡下載下傳

http://www.geocities.co.jp/SiliconValley-Sunnyvale/3109/

FPSCHK 和 Dec60 在「過去的遺物」裡面。

2. avisynth 的 script

LoadPlugin("MPEG2Dec3dg.dll")

LoadPlugin("decomb510.dll")

LoadPlugin("loadpluginex.dll")

LoadPluginEx("dec60.dll")

Mpeg2Source("120fps.d2v")

Telecide()

Dec60(idxfile="120fps.idx",deint=false)

由于 Dec60 是 Avisynth 2.0x 的 plugin，必須用 LoadPluginEx 才能在 2.5x 版加載。

loadpluginex.dll 在 warpsharp 的壓縮包裡面有附

http://www.geocities.co.jp/SiliconValley-PaloAlto/2382/

Telecide 是 Decomb 的指令，經過 Telecide 後，畫面會還原回 30fps progressive 的畫面，

其中 24p 的部分每五張會有一張重複的，30p 的部分則是每一張都是不同的畫面。

本來 Telecide 之後我們會用 Decomb 的另外一個指令 Decimate(cycle=5)，把每五張重複的那一張删除，但是 24p/30p 混合的情況，我們要保留所有 30p 的畫面，隻有 24p 的部分才要删除重複畫面，是以不能用 Decimate 删除，要改用 Dec60。

Dec60 會根據 FPSCHK 分析 .d2v 檔案得到的 .idx 索引，删除 24p 部分重複的那一張，保留 30p 全部的畫面。

3. 然後依照一般的程式送進去壓縮。

4. 壓好的 AVI 再送給 AVI60 去插 null frame，AVI60 會依照索引檔案，24p 的部分每一張後面插入四張 null frame，30p 的部分每一張後面插入三張 null frame。

代碼 (輕按兩下代碼複制到粘貼闆)

[A B C D] [E F G H I]







   24p        30p















[A A A A A B B B B B C C C C C D D D D D







 E E E E F F F F G G G G H H H H I I I I]







                 120p















重複的 Frame 标記為 Drop Frame，不必壓縮







[A d d d d B d d d d C d d d d D d d d d







 E d d d F d d d G d d d H d d d I d d d]      

5. 大功告成。

進一步研究

1. FPSCHK 分析 .d2v 檔案，判斷的結果不十分正确，通常是不正确的。

因為 .d2v 的内容是原始 MPEG-2，交錯的情況很複雜，MPEG-2 本身也許也有用到 IVTC，讓判斷更困難，是以很容易出錯。

我們可以改成不要用 .d2v 來分析，改成分析 Telecide 之後的檔案。

LoadPlugin("MPEG2Dec3dg.dll")

LoadPlugin("decomb510.dll")

LoadPlugin("loadpluginex.dll")

LoadPluginEx("dec60.dll")

Mpeg2Source("120fps.d2v")

Telecide()

把這個 .avs 用 ffvfw 的 makeAVIS 轉成索引的 .avi 檔案。

用 FPSCHK 加載這個 avi 檔案，分析這個 avi 檔案。

這樣的正确率會提高非常多。

2. Dec60 删除 24p 的部分，有時會删除到不該删除的 frame，想要改正，但是在視窗中又無法修改。

可以直接從 .idx 檔案中修改。

代碼 (輕按兩下代碼複制到粘貼闆)

Field=0







NumFrames=42738







Total=42738







AvailFrames=34272







TargetFile=F:/STRATOS 4/stratos 4-109.avi







#     0 (00:00:00) -  2213 (00:01:13)  24fps  ?   2214 (00:01:13)







#  2214 (00:01:13) -  2506 (00:01:23)  30fps  ?    293 (00:00:09)







#  2507 (00:01:23) -  2598 (00:01:26)  24fps  ?     92 (00:00:03)







#  2599 (00:01:26) -  2660 (00:01:28)  30fps  ?     62 (00:00:02)







#  2661 (00:01:28) - 42738 (00:23:46)  24fps  ?  40078 (00:22:17)















     0,1







     1,9







     2,1







     3,1







     4,1







     5,9







     6,1







     7,1







     8,1







     9,1







.....      

第一個數字是 frame number，"," 後面 9 代表删除，1 代表保留。

将你想要删除的 frame 手動改成 9，将你想要保留的 frame 改成 1。

注意 24p 的部分每五張要删除一張，如上面所示。

3. 隻能用 Decomb 做 IVTC，而 Decomb 做 IVTC，結果并不完美。

Decomb 5.10 版，很強，IVTC 很強，改用 Decomb 5.10 版，效果好很多。

Decomb 的 IVTC 不完美，可以手動指定 override 檔案，覆寫 Decomb 的設定。

用 override，可以做出超完美的 IVTC。

像下面這樣

LoadPlugin("MPEG2Dec3dg.dll")

LoadPlugin("decomb510.dll")

LoadPlugin("loadpluginex.dll")

LoadPluginEx("dec60.dll")

Mpeg2Source("120fps.d2v")

Telecide(order=1,post=3,vthresh=83,dthresh=7,blend=true,ovr="ovr.tel.avs")

ovr.tel.avs 的檔案内容像下面這樣

584 p

1410 p

1843,1845 -

1845 p

1846,1853 +

2515 +

2520 +

2525,2527 +

2530,2534 +

.....

28003,28010 ccnnc

28011,28025 pccnp

28105 p

28405,28449 cccnn

28450,28479 ccnnp

28628 p

.....

要知道 ovr.tel.avs 裡面在做什麼，必須先了解 Decomb 去交錯的原理。

我把以前寫的一篇文章轉過來

==

1. progressive 和 interlaced 的分别

progressive: 奇數、偶數的掃瞄線是在同一個時間點拍攝的，奇數掃瞄線組成的奇數場（odd field）和偶數掃瞄線組成的偶數場（even field），兩個圖場合并起來是一個完整個畫面，用眼睛看，畫面上沒有交錯的線條。

interlaced: 奇數、偶數的掃瞄線是在不同時間點拍攝的，拍完一個圖場接下去拍另一個，奇數掃瞄線組成的奇數場和偶數掃瞄線組成的偶數場，兩個圖場各自是一個獨立的畫 面，組合在一起，畫面上會有交錯的線條瑕疵。

有交錯線條的畫面是 interlaced，沒有交錯線條的畫面是 progressive。

30p x480 progressive: 一個時間點的垂直分辨率是 480，清晰度佳，每秒 30 張畫面

30i x480 interlaced = 60p x240 progressive: 一個時間點的分辨率 240，清晰度差，每秒 60 張畫面，動感佳

2. 訊源的類型

a) 24fps, 23.976fps progressive, Film, 24p

有些影片，訊源是 24fps，拍攝的時候是以 24fps progressive 的方式拍攝的，每一張都沒有交錯，例如大部分的電影。為了要能在 NTSC 的電視上播放，電影膠卷過帶（telecine）的時候必須轉成 30fps，這個 24 -> 30fps 的過程叫做 3:2 pulldown。

1, 2, 3, 4 四張原始畫面，1o 代表 1 的 odd field，1e 代表 1 的 even field

代碼 (輕按兩下代碼複制到粘貼闆)

1       2       3       4







[1o 1e] [2o 2e] [3o 3e] [4o 4e]







3:2 pulldown (2:3 pulldown) ---->















[1o 1e] [2o 2e 2o] [3e 3o] [4e 4o 4e]







   2   -    3     -   2   -    3    <-- 呈現這樣的排列，是以叫做 2:3 pulldown















   1       2       3       4       5







[1o 1e] [2o 2e] [2o 3e] [3o 4e] [4o 4e]      

上面 4 張 -> 5 張

4 * 6 = 24 張 -> 5 * 6 = 30 張

這樣就可以把原本 24 張轉成 30 張，在 NTSC 的電視上播放。

但是其中第三和第四張畫面 [2o 3e] 和 [3o 4e]，是由兩個不同畫面的 field 組成，畫面變成交錯的。

每五張之中，有兩張是交錯的。

有這種型式的影片，我們知道，其原始畫面其實是 24fps progressive 的，可以作 inverse telecine（IVTC），删除多餘的畫面，還原回原本的 24fps。

大部分的電影，無庸置疑，其訊源一定是 24fps progressive，可以作 IVTC。

電影（Film, 24fps progressive）轉成 PAL（25fps）的時候，用的是 2:2 pulldown，畫面還是 progressive，隻是加快播放速度，變成每秒播放 25 張。不過有些 PAL 的 DVD 會 shift 一個 field，造成畫面每一張都交錯，這時隻要 swap field order，就可以還原回無交錯的畫面。

還有一些 PAL DVD 非常奇怪，25 張之中會有重複的一張畫面，這時就必須删除重複的那一張畫面才能還原回 24p。

b) 30fps, 29.97fps interlaced, Video, 30i

拍攝的時候，是以 30fps interlaced 的方式拍攝的，每一張都是交錯的 。大部分的 NTSC 電視節目（連續劇、綜藝節目、新聞報導...），交錯式的 DV 都是這種訊源。

這種訊源要在計算機上看

1) 以 x480 30fps 播放，不做去交錯 = x480 30i，這樣靜态畫面的清晰度最好，但動态畫面會有交錯線

2) 以 x480 30fps 播放，做去交錯 = x480 30p，畫面會模糊

3) 以 x240 30fps 播放，這又有兩種情況

a. x480 先做去交錯之後再縮小畫面

b. 直接舍棄一半的圖場，隻留下其中一個圖場的 x240 掃瞄線

狀況 a 等于 2) 的低分辨率版

狀況 b 也是少掉一半的 field

4) 以 x240 60fps 播放，也就是抓 x480 30i，然後轉成 x240 60p，這樣就跟在電視上播放一樣，是最順暢的，沒有丢掉任何一個 field

但是這樣播放，畫面會上下跳動。

是以有那種在做 30i->60p 的 filter，減少這種上下跳動的現象。

c) 30fps progressive, 30p

30fps 每一張都沒有交錯，例如計算機動畫

這種訊源，當然什麼處理都不用作。

d) Hybrid, Mixed 混合 24p/30p

在動畫 DVD 上面常見，例如片頭是 30fps progressive，每一張都沒有交錯，本篇卻是 24fps progressive，五張之中有兩張交錯；或者是 CG 的部分 30p，其它部分 24p。

做成 AVI，AVI 隻能用一種固定的 fps，是以可以分開做的話分開做，把 24p 和 30p 的部分分成兩個 AVI，例如片頭 30p 一個 AVI，本篇 24p 一個 AVI。如果不好分開，例如幾乎都是 24p，隻有中間 CG 的部分 30p，隻好強制 24fps 做下去，這樣 30p 的部分會頓，不過也沒辦法了。

如果做成 30fps，24p 的部分每四張要重複一張，也是會頓。

最好的做法是轉成 120fps

120 是 24 和 30 的最小公倍數，做成 120fps，可以兼顧 24p 和 30p，不會頓，又不用犧牲畫面。

或者放棄 AVI，改用 .mkv 等可以支援 變動 frame rate/VFR 的檔案格式。

e) Hybrid clip, Mixed, 混合 24p/30i, 混合 24p/48i, 混合 xxx/xxx .....

例如部分 24fps progressive，五張之中有兩張交錯，部分 30fps interlaced，每一張都交錯。

很難處理，大家各憑本事

f) Hybrid Frame

一個 Frame 之中，部分交錯，部分沒交錯。

例如有些影片的字幕、從業人員名單是 telecine 之後才 overlay 上去的，造成背景畫面沒交錯，前景字幕卻是交錯的。

做自适應去交錯。

g) 其它亂七八糟的型式

例如錯誤的 DVD mastering，剪接的時候少掉一張，圖場颠倒，enocder 的 IVTC 錯誤，造成 frame 畫面補不回無交錯的狀态..... 等等。

八仙過海，各顯神通

3. 什麼是 blended field

blended，混合，當畫面上有交錯的時候，用奇偶平均的方法，混合奇偶兩個圖場，可以減少突兀的交錯現象，是去交錯的方法之一。副作用，一是畫面變模 糊，清晰度下降，二是兩張不同的畫面混合在一起，看起來像是兩個影像重疊在一起，會有殘影，或者叫「鬼 影」的現象。

blended field，一個 field，是取自經過 blended 的 Frame，是以畫面會有殘影，包含了兩個畫面的影像。

例如對 x480 的交錯訊源使用 TMPGEnc 的 Double 去交錯，然後縮小至 x240 的 VCD 輸出，畫面上會有殘影，包含了原本 x480 兩個 field 的影像。

有些 PAL <-> NTSC 轉換的機器會造成這種 blended field，部分或全部的 field 是 blended field，這種 field 會造成 IVTC 的判斷非常困難。

或者，有些動畫，為了要造成高速移動的假象，或者營造動作的流暢感，會故意使用 blended field。

怎麼判斷是否有 blended field

用 Avisynth 的 SeparateFields()，畫面會顯示單一個 field，看有沒有 field 是混合了兩個畫面，有兩個影像在上面。

TMPGEnc 的 Deinterlace --> Even-Odd field (field) 也可以看。

遇到這種現象，有時你會發現 blended field 主要出現在一個 Frame 的第二個 field（Bottom field），是以使用 Decomb 的時候，讓 Decomb 使用 Top field 來做 matching 的動作（比對兩個 field，看哪一種組合交錯最少，也就是 奇偶的差異最小），可以幫助 Decomb 正确的判斷。

4. Decomb 的比對方式

Decomb 預設的比對方法

1) 暫存三個 Frame，分别是現在的 Frame C，過去的 Frame P，和下一個 Frame N。

2) t 代表 Top field，b 代表 Bottom field，Decomb 會做三種 field 的組合，看哪一種交錯的情形最少

代碼 (輕按兩下代碼複制到粘貼闆)

Pt







Cb  <- 以 Cb 為基準不變，去和前（P）、後（N）、目前（C）的 Top field 做組合















Ct







Cb















Nt







Cb      

以 3:2 pulldown 的訊源為例

代碼 (輕按兩下代碼複制到粘貼闆)

1  2  3  4  5







At Bt Bt Ct Dt







Ab Bb Cb Db Db      

第 3 個 Frame 經過 Decomb 重新組合，會變成

代碼 (輕按兩下代碼複制到粘貼闆)

Bt







Cb















Bt







Cb















Ct







Cb  <- 中獎，這個組合奇偶差異最小      

3) 輸出差異最小的組合

如果用 reverse 參數，Decomb 會改成以 Ct 為基準不變，去和前、後、目前的 Bottom field 做組合

代碼 (輕按兩下代碼複制到粘貼闆)

Ct  <- 以 Ct 為基準不變，去和前（P）、後（N）、目前（C）的 Bottom field 做組合







Pb















Ct







Cb















Ct







Nb      

是以 Doom9 的讨論中，neuron2 大大建議的作法

Telecide(post=false)

Telecide(reverse=true ,post=true)

讓 Telecide 正、反各跑一次，去 match 最适合的 field。

**附注**

上面的參數是 Decomb 4.xx 版的參數，這篇文章是以前寫的，現在 5.10 版已經換了參數名稱。

********

如果每一個 field 都是 blended field，那麼無可能 IVTC，隻有做去交錯，把訊源當成是完全的 interlaced

FieldDeinterlace(full=true)

5. Deinterlacing -> Progressive 的方法

1. Intrafield Processing: Field 内的處理 (Bob)

a. Scan Line Duplication or Single-Field Duplication

在計算機上可以，舍棄其中一個圖場，不足的一半掃瞄線用重複上一條掃瞄線的方式補上去，仍然維持 29.97fps x480。

或是

不舍棄圖場，加倍顯示速率，29.97fps x480 -> 59.94fps x480，每次顯示原來的一個圖場，不足的一半掃瞄線用重複上一條掃瞄線的方式補上去。

line1 = 1

line2 = line 1 = 1

line3 = 3

line4 = line 3 = 3

沒有殘影。

線條不平滑，鋸齒感很嚴重。

b. Scan Line Interpolation or Single-Field Interpolation

在計算機上可以，舍棄其中一個圖場，剩下的一半掃瞄線用内插補點（Interpolation）的方法補出來。

如 TMPGEnc 的 Even field/Odd field 去交錯法。

或是

不舍棄圖場，加倍顯示速率，29.97fps x480 -> 59.94fps x480，每次顯示原來的一個圖場，剩下的一半掃瞄線用内插補點補出來。

如 TMPGEnc 的 Even-Odd field 去交錯法。

line 1 = 1

line 2 = (line 1 + line 3)/2

line 3 = 3

line 4 = (line 3 + line 5)/2

上面舉例的 linear interpolation 品質很差，實作會用品質較好的補點方法，例如 (sin x)/x ie. sinc interpolation

line n = 0.114*line(n-5) - 0.188*line(n-3) + 0.574*line(n-1) + 0.574*line(n+1) - 0.188*line(n+3) + 0.114*line(n+5)

這是微軟當初提 Bob 的原意，但是當時的硬體沒有辦法做到及時補出另一半的掃瞄線，是以軟體 DVD Player 實作 Bob 的時候，是用 Blend 取代 Bob。

是以現今 WinDVD, PowerDVD 的 Bob 選項，指的都是 Blend。

WinDVD 5 新增一個消除鋸齒的方法 "Progressive"，便是加倍顯示速率，内插補點的 Bob。

2. Interfield Processing: Field 和 Field 之間的處理

a. Field Merging

a-1. Field Combining (Weave)

合并兩個 Field 一起顯示。

如果畫面動态不大，交錯不會很明顯。

好處是清晰度最高，壞處是動态大就會破功（會出現明顯交錯）。

在電視上是合并兩兩的 Field

代碼 (輕按兩下代碼複制到粘貼闆)

[ 2 ] [ 4 ] [ 6 ] [ 8 ]







1o 1e 2o 2e 3o 3e 4o 4e 5o 5e  <-- 輸入 Field







[ 1 ] [ 3 ] [ 5 ] [ 7 ] [ 9 ]  <-- 輸出 Frame      

維持 59.94 的顯示速率。

在計算機上沒有這個限制，Weave 就是

代碼 (輕按兩下代碼複制到粘貼闆)

1o 1e 2o 2e 3o 3e 4o 4e 5o 5e  <-- 輸入 Field







[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]  <-- 輸出 Frame      

29.97fps 輸出。

那不是和原來一樣？

是以計算機上的 Weave，還表示如果是 Film 訊源，可以 skip 3:2 pulldown 的旗标，還原、重組正确的 Progressive Frame，有這一層意思在。

代碼 (輕按兩下代碼複制到粘貼闆)

[1o 1e] [2o 2e] [2o 3e] [3o 4e] [4o 4e]







                 x           x          <-- 删除重複的 Field







---->







[1o 1e] [2o 2e] [3o 3e] [4o 4e]      

a-2. Vertical Filtering (Blend)

奇偶平均，混合兩個 Field。

例如 TMPGEnc 的 Double 去交錯法。

因為 Blend 之後，畫面會出現兩個重疊的影像（double image），是以叫做 Double 去交錯法。

b. Motion Adaptive Deinterlacing

動态自适應去交錯。

畫面上靜态沒有物體移動的區域，用 Weave；畫面上動态有移動的區域，用 interpolation。

這樣人眼比較敏銳的靜态區域可以維持高清晰度，人眼看不清楚細節的高動态區域可以減少明顯的交錯瑕疵。

c. Motion Compensated (Motion Vector Steered) Deinterlacing

做動作搜尋，計算每個 pixel 在 Field 間的移動量，内插計算新的 pixel 值。

這是非常複雜的去交錯方法，隻有在專業的 conversion 機器上才看得到。

Avisynth 有這種 deinterlacing 的 plugin，叫做 TomsMoComp，不過這個 plugin 對字型的 tracking 常常會産生雜點，必須要降低搜尋的精度，才能減少這種現象。

Inverse Telecine or IVTC or Inverse 3:2 Pulldown

例如

1. Decomb

做法上面已經說過

2. TMPGEnc

TMPGENc IVTC 的小視窗，按下面的 Field 組合

代碼 (輕按兩下代碼複制到粘貼闆)

1  2  3  4  5   6  7  8  9  10 ...







1t 2t 2t 3t 3t  4t 4t 5t 5t 6t ...







1b 1b 2b 2b 3b  3b 4b 4b 5b 5b ...      

以 Bottom Field 為基準，去和現在以及下一張 Frame 的 Top Field 組合

一張變兩張

是以五張輸入變十張

1 2 3 4 四張 Frame，3:2 pulldown 之後得到五張 Frame

1t 2t 2t 3t 4t

1b 2b 3b 4b 4b

代入 TMPGEnc 的小視窗

代碼 (輕按兩下代碼複制到粘貼闆)

1  2  3  4  5   6  7  8  9  10







1t 2t 2t 2t 2t  3t 3t 4t 4t 5t







1b 1b 2b 2b 3b  3b 4b 4b 4b 4b







^^    ^^ ^^     ^^    ^^ ^^      

有 ^^ 記号的代表無交錯的畫面，奇偶差異小

相同的畫面挑一個就可以了

手動指定 pattern 的話，0 代表不選，1 代表選

上面輸入 "10100" 或 "10010" 或 "1001010010" 都可以

3. AviUtl

代碼 (輕按兩下代碼複制到粘貼闆)

1t 2t 2t 3t 4t







1b 2b 3b 4b 4b







      ^^ <-- 将第三張 Frame 的 Top Field 和前一張 Frame 的 Bottom Field 結合







         ^^ <-- 将第四張 Frame 的 Top Field 和前一張 Frame 的 Bottom Field 結合







-->







1t 2t 2t 3t 4t







1b 2b 2b 3b 4b















删除重複的第三張 Frame







-->







1t 2t 3t 4t







1b 2b 3b 4b      

在電視上，還原出來的 24fps 要做 "3:2 pulldown progressive scan" 轉成 60fps 顯示

代碼 (輕按兩下代碼複制到粘貼闆)

1 1 1 2 2 3 3 3 4 4







  3    2    3    2      

事實上後面的部分我已經寫好了，而且也在别的地方貼過，不過我忘了上來 CCF 補充 ^^;;

我回家後會把後面的部分再貼上來。

我的做法其實是非常麻煩的，必須要很有耐心。

sswroom 兄的做法比較快速，如果你用 TMPGEnc 手動 IVTC 的功力很高的話，用 sswroom 兄的做法會如魚得水，好用得不得了

再加上 sswroom 兄的做法可以很友善的手動 drop frame，提高畫質和壓縮率，是以我建議最好是學會如何用 TMPGEnc 手動 IVTC，然後搭配 TPRRead 和 AVIRead，這樣會比 Decomb 手動指定 override 友善。

由于事忙，先寫到這。

這個訊源是 29.97 1920x1080i，每一張都是交錯的畫面。

原始分辨率是 1920x1088，畫面下方多出來的 8 條掃瞄線是沒有用的，可以把它切掉。

為什麼要多加這無用的 8 條掃瞄線？

因為 1088 才可以被 16 整除，訊源是用 MPEG-2 壓縮，是以要補成可以被 16 整除的分辨率。

HDTV 是遵照 ITU-R BT.709 的标準制作，BT.709 和我們一般習慣的，DVD 在用的 BT.601 不同，首先是色空間轉換式不同，這個以前在說明 M2V 解碼 HDTV 的色彩才會正确時已經有提過了，此處不再贅述；另一個不同是 PAR 不同，BT.709 取樣的形狀是正方形，PAR 是 1:1，就是說 BT.709 不像 601 那麼麻煩，resize 之前還要左右切邊，不用，BT.709 直接 resize 成你想要的 16:9 比例就可以了，是以處理很簡單

因為這個原始 tp 檔案切成兩段，用 DVD2AVIT3 連接配接加載好像會出問題，最好先用 HDTVtoMPEG2 把兩段先接起來，然後再用 DVD2AVIdg 開啟。

訊源是 30i 的訊源，張張都交錯，是以我們就很簡單的舍棄一半的圖場，這樣就可以了

LoadPlugin("c:/Program Files/AviSynth 2.5/plugins/MPEG2Dec3dg.dll")

Mpeg2Source("c:/jewelry.d2v")

# 舍棄 Odd Field

SeparateFields()

SelectEven()

# 這時畫面剩下 1920x544p

LanczosResize(960,544)

BT709ToBT601()

因為我沒有把底部的 8 條掃瞄線切掉，是以垂直分辨率是 544，如果切掉，就是 540。

因為交錯畫面 Chroma 取樣的位置關系（以前提過，喚醒記憶

），上面的做法會令 Chroma 有半個 pixel 的 delay，trbarry 有寫一個專門在做長寬減半的 interlaced resize，叫做 InterlacedReduceBy2，如果用這個 resize，就隻要一行

LoadPlugin("c:/Program Files/AviSynth 2.5/plugins/MPEG2Dec3dg.dll")

Mpeg2Source("c:/jewelry.d2v")

YV12InterlacedReduceBy2()

BT709ToBT601()

就可以了，但是這個 resizer 水準 resize 太簡單，filter 太少，線條邊緣會有鋸齒，不好看，是以我還是習慣用 LanczosResize。

最後，BT709ToBT601() 也是 trbarry 寫的一個 filter，這個是做什麼用的呢？因為 Avisynth 都是在 YUV 色空間上處理，而 HDTV 解碼出來的 709YC 在一般以 601YC 為标準的 Codec/顯示卡 上會顯示錯誤的顔色，是以在壓成 AVI 之前，要先将原始的 709YC 轉成 601YC，這樣後續的顯示色彩才會正常。詳細以前說過，就不再重述。

trbarry 舉了一個圖檔做為範例

http://mywebpages.comcast.net/trbarry/BT709ToBT601.2.jpg

左邊是 709YC 不做處理，以 601YC 的轉換式解碼之後的結果，人臉變成粉紅色，右邊是經過 709YC->601YC 處理，以 601 轉換式解碼之後的結果，這樣就正确了。

trbarry 是誰應該不用介紹？

而 M2V 這個解碼軟體會根據 MPEG-2 stream 裡面的一個旗标，叫做 matrix_coefficient，如果有在用 MainConcept MPEG Encoder 的人應該會覺得這個字很眼熟

M2V 會根據這個旗标的資訊，知道該 MPEG-2 使用的色空間是什麼，而做正确的轉換，是以我以前說解碼 HDTV 隻有 M2V 會正确。

但是有例外的情況。

譬如說日本 BSD 的 WOWOW 台，有時候它播放 SDTV 的節目，例如 Onegai Twins 這部我想很多人知道的動畫，如果你去分析它的 bitstream，會很驚訝地發現，它的 bitstream 竟然說它使用的是 709YC。然而 Onegai Twins 隻有 480i，并不是 HDTV 的節目。是以我們懷疑，他很有可能是标錯了，因為 WOWOW 台内的同一台 MPEG-2 壓縮機器，同時要壓 HDTV 和 SDTV 的節目，在壓縮時制作人員沒有記得切換壓縮的設定，改變旗标，是以 SDTV 的節目也沿用了 HDTV 的旗标。

然而實際上，這個節目是 601YC，要以 601YC 來解才正确。

我們将當初播放時的 MPEG-2 TS 和後來出的 RC2 DVD 的顔色作比對，果然要用 601 解碼才正确，用 MPEG-2 TS 用 601 解碼，才會得到和 DVD 一樣的色彩。

是以當初在 BSD 上直接看播放時，大家看到的色彩都是錯誤的

（BSD 的 tuner 會根據旗标，切換轉換式解碼，旗标說是 709，tuner 就乖乖的用 709 解碼，結果反而錯誤 :-.-: ）

這個時候，我們如果用 M2V 解碼這種訊息不正确的 MPEG-2 TS，反而會得到錯誤的結果，用 DVD2AVI 這種不管三七二十一，一律用 601 解碼的 decoder，反而正确 ^^;

幸好 M2V 可以強制 override 原先的設定，可以強制使用你設定的色彩轉換式解碼，是以如果你知道有這種問題，便會自己做判斷，做正确的切換，得到正确的結果。

以上是當初要講結果沒時間詳細講完的内容

南韓的 SBS HD HDTV，畫質不如日本的 BSD HDTV。日本的 BSD HDTV 碼率可到 28Mbps，比 ITU-R BT.1211-1 所建議的 22Mbps 還要大 8M，而南韓的 SBS HD，例如上面舉例的 jewelry.tp，碼率隻有 18.03M，是以方塊滿天飛舞.... >_<;

看 BSD 上播放的 1080i 的動畫，幾乎沒有壓縮瑕疵，看久了大概其它什麼東西都看不下去

TMPGEnc 3 beta 已經出現啰

崛老，作者崛浩行，其實一點都不老，他寫出 TMPGEnc 的時候還不到 19 歲，不過因為我們對他的尊敬，還是稱他為崛老 ^^;

崛老把 filter 改成 YUV 處理，不像以前用 RGB，我朋友知道一定高興死了，他以前最頭疼的就是這個問題。改成 YUV 處理（有部分 filter 仍然是 RGB），還有新的動作搜尋，現在據說速度有提升，而且畫質更好啰，大家可以期待等正式版推出

說到年輕有為，Nero Digital 的 AAC 編碼的部分，作者我們大家知道是 Ivan，Ivan 之前是在 PsyTel 工作，Nero AAC 的前身就是 PsyTel AAC。Ivan 寫 AAC 的時候是幾歲大家知道嗎？19 歲。他現在應該還是二十出頭。

還有 MarcFD，寫出 deen, edeen, MPEG2Dec3 的時候，他中學還沒畢業....

VMOD直接讀入DS源顯示是4:2:2的?

HDTV 是 YUV 4:2:0，您會看到 dshow 輸入顯示 4:2:2，是因為您用 Elecard 的 MPEG2 Decoder 解碼，Elecard MPEG2 Decoder 解碼會輸出 YUV 4:2:2，就如同用 MPEG2DEC 解碼會輸出 YUV 4:2:2 一樣。

原始訊源和一般的 DVD 一樣，都是 YUV 4:2:0。

引用
我看到這段SBS的HTDV 已是我見過的最好的HDTV了 沒見到什麼方塊滿天飛呀

可能是因為您的螢幕分辨率沒有切換到 1920x1440 的關系，沒有切換到 1920x1440，必需縮小畫面顯示，這些瑕疵經過縮小以後會比較不明顯。

我把原圖的畫面撷取部分出來給您看

這些都是原始大小，1:1，沒有放大或縮小，您可以看到畫面上都是方塊。

靜态的畫面還可以，但是一到有動作的畫面，不用是很大的動态，隻要是有動态，畫面就出現這些方塊。

這是因為交錯畫面非常難壓縮，而這部的碼率又不夠的關系。

和 BSD 相比，BSD 幾乎沒有這種瑕疵。

1080i 的分辦率，根據 ITU-R BT.1211-1 的實驗，MPEG-2 碼率必須到 22Mbps 以上，才符合 1211-1 要求的視覺水準，而這部顯然不及格。

其實就算是 BSD，在魔人等級的眼中來看，也還是有許多是不及格的。雖然規格上 BSD 的 video 的碼率可以到 24.6Mbps，但是 BSD 也是有許多 HD 節目用不到 21Mbps。例如大家知道 DVD2AVI 的作者是 jackei，jackei 很早就在他的網頁中提出「BSD 真的是高畫質、高音質嗎？」這樣的疑問。他把 BSD 放送的 MPEG-2 TS + AAC 抓下來解剖分析

請看

http://arbor.ee.ntu.edu.tw/~jackei/projectbsd/

連 BSD 都有人嫌了 ^^;

引用
如果直接讀入DS源. 是不是不要做 709--->601的轉換?

我沒有實驗過用 Elecard MPEG2 Decoder 解碼，是以不知道它有沒有幫我們做 709->601 的轉換，不過先不說轉換這點，新版的 Elecard MPEG2 Decoder 的 Chroma upsampling 是錯的，這個很嚴重，因為你解碼的完全是 1080i 的交錯畫面，Chroma upsampling 不可以錯的。而且 Elecard MPEG2 Decoder 輸出的是 4:2:2，不是 YV12(4:2:0)，是以你事後根本補救不回來。

舊版的 Elecard MPEG2 Decoder 解碼 Chroma upsampling 是對的不知道為什麼新版的反而做錯了。

建議用 DVD2AVIT 3 這個可以直接讀取 .ts/.tp 這種 MPEG-2 TS(Transport Stream) 的版本來處理 MPEG-2 TS，後面再加上 BT709ToBT601()。

您問的第一個問題我不知道該怎麼回答

第二問題算式不同的原因是您寫的算式是模拟 YCbCr 和模拟 RGB 的轉換式，這是很多人會被弄迷糊的地方。

ITU-R BT.601 建議書裡面記載了五種色彩變換式，分别是：

1. 模拟 RGB 訊号轉為模拟 Y, (B-Y), (R-Y)

2. 模拟 (B-Y), (R-Y) 轉為模拟 Cb, Cr

3. 模拟 YCbCr 數字化（取樣、量化）成為數字 YCbCr

4. 模拟 RGB 數字化（取樣、量化）成為數字 RGB

5. 數字 RGB 轉為數字 YCbCr

1. 的變換式是

代碼 (輕按兩下代碼複制到粘貼闆)

Y = 0.299 * R + 0.587 * G + 0.114 * B 







  







(R - Y) = R - 0.299 * R - 0.587 * G - 0.114 * B 







  = 0.701 * R - 0.587 * G - 0.114 * B 







  







(B - Y) = B - 0.299 * R - 0.587 * G - 0.114 * B 







　 = - 0.299 * R - 0.587 * G + 886 * B       

2. 的變換式是

代碼 (輕按兩下代碼複制到粘貼闆)

Cr = 0.713 * (R - Y) 







　 = 0.500 * R - 0.419 * G - 0.081 * B 







  







Cb = 0.564 * (B - Y) 







　 = - 0.169 * R - 0.331 * G + 0.500 * B       

就是你寫的那個變換式。

上式 Y, R, G, B 的範圍是 0.0~1.0，Cb, Cr 的範圍是 0.5~-0.5。

模拟的 CbCr 通常表記為 PbPr。

由于這些表記的方法很亂，常有人會混合着用，是以寫的時候最好注明是模拟還是數字，例如

3. 的模拟 YCbCr 數字化轉換式

Y(d) = 219 * Y(a) + 16

Cb(d) = 224 * Cb(a) + 128

Cr(d) = 224 * Cr(a) + 128

Y(a) 代表 analog，Y(d) 代表 digital。

4. 的模拟 RGB 數字化轉換式

R(d) = 219 * R(a) + 16

G(d) = 219 * G(a) + 16

B(d) = 219 * B(a) + 16

R(a), G(a), B(a) 的範圍是 0.0~1.0，R(d), G(d), B(d) 的範圍是 16~235。

加上 (a), (d)，這樣表記就清楚多了。

5. 的數字 RGB 轉為數字 YCbCr

Y = (77 * R(d) / 256) + (150 * G(d) / 256) + (29 * B(d) / 256)

Cb = - (44 * R(d) / 256) - (87 * G(d) / 256) + (131 * B(d) / 256) + 128

Cr = (131 * R(d) / 256) - (110 * G(d) / 256) - (21 * B(d) / 256) + 128

YCbCr: 16~235, RGB: 16~235

這個轉換式是 straight 變換，沒有 YC 伸張（Full-range，擴充 RGB: 0~255），有 YC 伸張的算式就是你提出的我以前寫的那個算式。

這個表記法有點複雜，有的教科書在介紹亮度和色差的時候前面就先花了很多篇幅在定義表記的用法，例如我上面寫的還是不及格，因為 BT.601 的 RGB 都要先經過 gamma correction，是 gamma 校正後的 RGB，要表記為 R'G'B' ^^;

還有那個 Y，是 BT.601 的 Y，是以 Y 的右下角要加上一個底字寫 601，或者左上角要寫 601，這樣人家才知道你是 BT.601 定義的 Y，不是 BT.709 定義的 Y ^^;;

由于名詞太多有點亂，許多人會混合着用，同樣一個 YUV，有時候我們搞不清楚作者指的到底是數字的 YCbCr，還是模拟的 YPbPr，是 NTSC 的 YIQ，還是 PAL 的 YUV，是 601 的 YUV，還是 709 的 YUV，或者是 SMPTE 240M 的 YUV .... XD

有的時候作者在表記上沒有明寫，不過根據上下文意，我們可以猜出他說的是哪一個。

您看的那本書

有注明列的是 ITU-R recommendation BT.601 [1] 的 YCbCr 轉換式，是以是模拟轉換式，不是 BT.601-5。

當然用比較通用的 PbPr 來表示模拟色差是比較清楚的寫法。

ITU 的建議書（recommendation）隻要登記成為會員，每年都可以免費下載下傳三本，601, 709, H.263 ..等等都可以免費下載下傳

http://www.itu.int/publications/bookshop/index.html

大緻回複如上 ^^;;