引用:
Originally posted by Shade
淡入淡出的場景，新版的 XviD 已經有改善。
XviD 的動作搜尋演算法目前的主要設計人員 sysKin，改寫了 i/p/b frame 的判斷決策，現在遇到淡入淡出的場景，XviD 已經不會把每一張都壓成 keyframe 了。
不過我不只一次聽到有網友反應 XviD 對淡入淡出的場景，看起來不如 DivX5，sysKin 新版的改善也有限，所以我想這也許仍然是 XviD 目前的弱點。
還有常聽到有人說 XviD 對很暗很暗的場景容易出現壓縮瑕疵，這點我倒是有親身經歷。
XviD 對那種光線不足，但是又不是完全黑的場景，很容易出現方塊、或者是其他一些奇怪的瑕疵（例如看起來好像有東西黏在上面，髒髒的那種雜訊）。
這個可以利用 MPEG2Dec3.dll 提供的 LumaFilter 功能來解決，Avisynth 的語法如下
# 載入 MPEG2Dec3.dll
LoadPlugin("c:\Program Files\AviSynth 2.5\plugins\MPEG2Dec3.dll")
# LumaFilter，使用預設參數，可以視情況調整
LumaFilter()
你會發現那些暗部瑕疵很神奇地都不見了 
|
首先真的非常感謝Shade大大提供這麼詳細的測試資料^^
最近剛好在研究如何提昇XVID的品質...
因為我覺得對一般人的眼睛來看
淡入淡出的場景壓出來的瑕疵遠比各實驗數據來的顯眼
所以我把主要目標放在解決這問題
這問題一天不解決我寧可繼續用DIVX5壓動畫(這瑕疵對動畫真是致命傷)
不過如果能讓我滿意到放棄DIVX5我倒很期待
畢竟DIVX5他有Multipass, nth pass這功能
就是很手賤的覺得不壓到3 pass會很浪費(笑
不過相對的花的時間也比較多(泣
如果XVID只要2 pass就能達到相同的效果我當然馬上換!
在此順便問幾個問題
引用:
Originally posted by Shade
播放 Quarter Pixel 的影片時，畫面顆粒像液體般流動的瑕疵，其產生的原因：
1) ISO 修改了 Quarter Pixel 的 rounding 方法，舊版的 FFMPEG 沒有跟著修改，所以解 XviD 的 Quarter Pixel 時，會發生 rounding 錯誤，最新版的 ffdshow 已經修正了這個錯誤。
2) 不同 MPEG-4 Encoder 壓縮時採用不同 iDCT 算式，會造成解壓縮時 iDCT mismatch 的問題（雖然設計上有防止誤差累積的機制）。
由於大家壓 MPEG-4 時 I-frame 的間距通常設得很長，誤差一直累積，所以 iDCT mismatch 的問題會變得更嚴重（連續 P-frame 之後畫面會逐漸劣化）。
而 Quarter Pixel 似乎更加重了這個問題，使得誤差累積的錯誤更明顯。
MPEG 在編碼的時候，要將前一個編碼過的畫面解碼出來當作參考畫面。
編碼的時候會用 Forward DCT，解碼的時候要用 Inverse DCT。
編碼器在編碼的時候，需要用到 iDCT，將編碼過的畫面解碼，做為參考畫面。
壓好的檔案可以用不同的解碼器來播放。不同的解碼器，其 iDCT 的算式不一定相同；iDCT 的演算法好幾種，只要解出來和 IEEE Reference Decoder 的誤差在一定範圍內，就算是符合標準的 Decoder。
如果 iDCT 算式不同，則解碼出來的畫面就會和編碼器編碼時，解出來的畫面有一點點不同。而這張不同的畫面會被下一張畫面拿來做為參考的對象，當然，這和編碼時所使用的參考畫面是有點不同的，所以編碼時算出來的動作補償（MC），用在這張畫面上就會產生一點點的誤差。接著，這張 MC 有誤差 加上 iDCT 也有誤差的畫面，又要在被下一張畫面拿來做為參考對象，誤差會逐漸累積，越滾越大。
MPEG-1/2/4 的標準中都有為了這個 iDCT 算式不相符的問題做設計，可以減少 iDCT mismatch 所帶來的問題。
並且，由於 MPEG-1/2 的 GOP 長度都長只有半秒鐘，每半秒鐘就會更新一次，有一個獨立壓縮不參考其他畫面的 I-frame，所以這個問題不嚴重。
但是到了 MPEG-4，這個就變成大問題，因為大家壓 MPEG-4 通常 I-frame 間距都設得很長，這樣誤差會一直累積，連續 P-frame 後畫質會逐漸劣化。
而 Qpel 似乎更加放大了這個問題，誤差會嚴重到形成明顯瑕疵。
要避免這個瑕疵，必須
1) 使用 Koepi、Nic 編譯的最新版 XviD 來編碼，他們兩人的版本有修改，使用 Simple iDCT 演算法。
uManiac 編譯的版本沒有修改。
2) 使用最新版的 ffdshow 來播放，或是使用 XviD 自己來播放。
|
上面的狀況我發生在DIVX5.03
不過有趣的是我是在只不勾Quarter Pixel的狀況下出現
反而B-frame、Quarter Pixel、GMC全勾就沒有發生
我記得DIVX5.03在使用時只要勾了GMC 就不能勾Quarter Pixel
可是不勾反而更慘呢真的很奇怪@@
而且我發現三個全勾了以後觀看時也並不會有任何瑕疵出現
引用:
Originally posted by Shade
然而 Avisynth 載入的 Kiddy Grade NCOP_aup_vfapi.avi 這個檔是 RGB24 的 VFAPI，
為什麼不乾脆用全程 Avisynth，做全程 YV12 的製程？
因為：
1. 我需要用到 TMPGEnc 做 IVTC。
2. 全程 YV12 製程有所限制，不是每種訊源都可以使用。
有什麼限制？
1. 原始訊源不用作 IVTC，不需要用到 TMPGEnc 或 AviUtl。
Avisynth 雖然也有 IVTC 的 plugin，例如 Decomb，
但是我覺得不完美，用 TMPGEnc 手動一張一張選比較完美（廢話.. ^^;）
如果 IVTC 簡單，不會用到單張去交錯或 copy frame，
可以利用 tprivtc.dll 這個 plugin，讀取 TMPGEnc 專案檔內的
IVTC 資訊（先用 TMPGEnc 做好 IVTC 存成專案檔），使用語法是
DoubleWeave().TPRIVTC(<string file.TPR>,<debug mode> )
這樣的話還是可以使用 Avisynth 做 YV12 製程。
2. 壓 MPEG-4 要用全程 YV12，必須要用 VirtualDubMod 這個軟體，
用這個軟體選 "Fast recompress" 壓縮模式，VirtualDubMod 才會傳送
原封不動的 YV12 資料給 Codec 壓縮。
其他如本家的 VirtualDub，即使選 "Fast recompress"，VD 也還是會先
轉為 RGB，再送給 Codec 壓縮。
|
我記得TMPGEnc只收RGB的資料
那就算用 VirtualDubMod 這個軟體
只要用TMPGENC做過IVTC就不算全程YV12嗎?
如果是這樣那這種機會對DVD轉AVI也太少了
有幾家DVD可以百分百FILM不用手動檢查IVTC的
