PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   DVD 討論區 (https://www.pcdvd.com.tw/forumdisplay.php?f=5)
-   -   請問TMPGEnc的CCIR601這個濾鏡到底要不要開? (https://www.pcdvd.com.tw/showthread.php?t=456862)

xje489 2005-03-11 06:49 PM

請問TMPGEnc的CCIR601這個濾鏡到底要不要開?
 
這幾天爬了很多文,看了無數篇討論串
拜讀了Shade,Snic,Jackei 等諸位高手的大作
對於影像技術一竅不通的我,早已經被弄得一頭霧水
好像就是得不到一個簡單的答案
請問有哪位大大能幫忙歸納一下
1.DVD-->AVI
2.AVI-->MPG(DVD)
"Output YUV data as basic YCbCr, not CCIR601"這個選項到底應不應該勾??
謝謝!!

snic 2005-03-11 07:46 PM

引用:
作者xje489
這幾天爬了很多文,看了無數篇討論串
拜讀了Shade,Snic,Jackei 等諸位高手的大作
對於影像技術一竅不通的我,早已經被弄得一頭霧水
好像就是得不到一個簡單的答案
請問有哪位大大能幫忙歸納一下
1.DVD-->AVI
2.AVI-->MPG(DVD)
"Output YUV data as basic YCbCr, not CCIR601"這個選項到底應不應該勾??
謝謝!!

真不曉得你看到哪去了
http://forum.pcdvd.com.tw/showthrea...#post1076220652

xje489 2005-03-11 11:55 PM

引用:
作者snic

SNIC大大你好
這篇SNIC大與Shade大的精采對答我早已拜讀過了
剛剛又重新看了一遍
不過實在太多技術性的觀念,吸收不良啊
而最後Shade大提出的:
引用:
作者Shade
TMPGEnc 2.5 Plus 只接受 RGB 輸入,所以不管你是丟 YV12,還是 YUY2,最後都會轉成 RGB,所以不管什麼訊源輸入,他的 "Output YUV data as Basic YCbCr not CCIR601" 永遠都有作用。

是說勾不勾都一樣嗎??
可是我試過AVI(Xvid)-->MPG(DVD) 勾的話轉檔結果畫面對比較不明顯,顏色會偏暗
所以結論是不是:
DVD-->AVI 要勾
AVI-->MPG(DVD) 不勾

恕小弟不才,請SNIC大大指點一條明路

snic 2005-03-12 02:30 AM

引用:
作者xje489
而最後Shade大提出的:TMPGEnc 2.5 Plus 只接受 RGB 輸入,所以不管你是丟 YV12,還是 YUY2,最後都會轉成 RGB,所以不管什麼訊源輸入,他的 "Output YUV data as Basic YCbCr not CCIR601" 永遠都有作用

是說勾不勾都一樣嗎??
可是我試過AVI(Xvid)-->MPG(DVD) 勾的話轉檔結果畫面對比較不明顯,顏色會偏暗

你根本沒看懂前後文...也許是你看的順序不對的關係...

簡單講就是說...
影像資料都以 YUV 形式儲存...而 YUV 的資料範圍是 16~235
但是 RGB 資料範圍可能是 16~235 或 0~255...要看有沒有做過 YC 伸張
而 YC 伸張壓縮就是在做"16~235 伸張成 0~255"或"0~255 壓縮成 16~235"這兩件事情
所以只有在 RGB -> YUV,或者 YUV -> RGB 才需要考慮 YC 伸張壓縮

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

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

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

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

回過頭來討論 TMPGEnc,因為他只吃 RGB 的資料
引用:
作者Shade
所以如果你丟 YUY2/YV12 給它,它也一律都先轉成 RGB,這個也是在背後默默地做,表面上完全感覺不出來

也就是說
引用:
作者Shade
格式是什麼不重要,因為你用 TMPGEnc 讀,最後一定都會轉成 RGB 的格式。
即使輸入的是 YUY2,最後還是會轉成 RGB,TMPGEnc 的這個轉換是轉成伸張後的 RGB,也就是 0~255 的 RGB,也就是一般正常的 RGB。
如果不是用 TMPGEnc 執行壓縮也一樣,經過 TMPGEnc 讀取後,轉 VFAPI 輸出,格式都會是 RGB24。
TMPGEnc Plus 只支援 RGB 的輸出入格式。

TMPGEnc 3.0 XPress 才支援 YUY2 的輸入和處理

問題來了...
當 TMPGEnc 發現來源是 YUV(資料範圍 16~235)的時候二話不說轉 RGB 並且做 YC 伸張(16~235 伸張成 0~255)壓縮時沒問題
但要是來源本來就是 RGB 就會有兩種狀況...
一種是有伸張後(0~255)...一般軟體的 YUV -> RGB 都會做伸張(一般狀況)
一種是未伸張(16~235)...如 Canopus 自家的 DV Codec 預設輸出的是無伸張的(特殊裝況)
所以要是碰到需壓縮 Canopus 自家的 DV Codec 預設輸出的是無伸張的 16~235 RGB
引用:
作者Shade
壓縮這種未經過伸張的 RGB,TMPGEnc Plus 壓縮時要勾選 "Output YUV data as Basic YCbCr not CCIR601"

所以
引用:
作者Shade
TMPGEnc 2.5 Plus 只接受 RGB 輸入,所以不管你是丟 YV12,還是 YUY2,最後都會轉成 RGB,所以不管什麼訊源輸入,他的 "Output YUV data as Basic YCbCr not CCIR601" 永遠都有作用。

這裡 Shade 長輩所謂"有用"是指有時候要勾有時候不勾...必須根據情況而論...
因此這選項是必要的...等到遇到特殊情況的時候就真的會"有用"
所以你下的結論只能叫半對!
引用:
作者xje489
所以結論是不是:
DVD-->AVI 要勾
AVI-->MPG(DVD) 不勾

這要看你轉檔的來源跟過程中是否有做到 YC 伸張壓縮...沒那麼簡單...
所以 Shade 長輩才說
引用:
作者Shade
如果以上這些判斷方法都不好用,也不知道到哪裡下載這些程式,最簡單的方法,就是先用 ProCoder 快速的壓一小段,看看壓出來畫面的顏色正不正確,和原來的檔案一不一樣。
如果畫面色彩變淡,看起來灰濛濛的一片,表示需要加上 "601 Correction - Expand Color Space"。
如果畫面對比變強,色彩看起來超鮮豔,但是比較明亮的畫面會變成一片慘白,黑底也變得比原本更深更沈,就表示畫面已經削切失真了,要加上 "601 Correction - Shrink Color Space"。
ProCoder 的話只有可能會發生後者的情況。

以上是概述簡單的判斷法

以上都是 Shade 兄講過的話...我只是順序調來調去而已...

xje489 2005-03-12 09:48 PM

非常感謝SNIC大大
有了您的導讀,果然容易理解多了
更是令人佩服SNIC與Shade
謝謝你們在版上熱心的給大家指引


所有的時間均為GMT +8。 現在的時間是03:40 PM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。