看divx網站上的fixed資料
修正將每一frame當成i-frame來編碼的問題=>檔案數G的問題似乎已解決
但5.05仍然不能用mvinfo.bin
總而言之仍是有問題，暫時用5.03版或xvid先

節錄自doom9教學文章：
-----------------------------------
1 Pass - quality 是一個固定品質的模式，你可以設定品質為 0 到 100 ，100為最高品質
1 Pass - quantizer 跟 quality 差不多，不過在這裡每個frame的壓縮比是相同的，而上個模式則是會變動的壓縮比。
-----------------------------------
看了這一頁教學，相信您應該可以得到一點東西
http://big5.doom9.org/xvid-vdub.htm

謝謝!珊珊
那篇文章對我幫助很大,努力研讀中

你用的是哪個版本的xvid??
如果有vhq選項的話,把他選到1(mode decision),可以稍微減少檔案大小,而切增進畫質....
我自己test的結果是,畫質增進基本上肉眼無法辨識,但不會變差就是了,但檔案卻會變小,基本上我認為是可以用的,至少我用vhq還沒遇到什麼錯誤...

XviD-04102002-1.exe
about上是2.1
沒看到vhq選項

淡入淡出的場景，新版的 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()

你會發現那些暗部瑕疵很神奇地都不見了

您用的版本太舊了，請更換新的版本
http://roeder.goe.net/%7Ekoepi/

其實沒有什麼研究 :P
而且我壓縮的次數很少，沒什麼實戰經驗。

小弟個人建議的設定
1. 使用最新版的 XviD
2. 用最新版請打開 VHQ 的功能，選 mode: 1
3. 不要用 Alt. Curve，請把它關掉
4. 請把 I-frame Boost %, High bitrate scenes%, Low bitrate scenes% 都設為 0（這種調整法稱為 linear-scaling）
5. Minimum I-frame interval 設為 1
6. 當流量足夠時，也就是 1st-pass 壓出來的檔案大小和你設定 2nd-pass 目標大小的差距不大，例如只壓縮了 70~80%，那麼流量是足夠的，此時使用 linear-scaling 的效果是最好的，不要用限制 quantizer。
7. 流量很低的時候，B-frame 的 quantizer 不要設得太高
8. 不要用 Lumi masking
9. 不要用 Modulated quant
10. 壓動畫不要用 MPEG quant

關於 XviD 和 DivX5 的比較，我這幾天又做了一點實驗。
我以前壓 XviD 都不用 B-frame，當然也不開 Quarter Pixel 和 GMC，所以和 DivX5 比較的時候，我也不使用 DivX5 的 B-frame 和 Quarter Pixel、GMC 等功能。
今天用新版的 DivX 5.0.5 和 XviD 再做一次比較，同時測試了開啟 B-frame 的效果。
結果發現 DivX 5.0.5 蠻強的，比 5.0.2 進步。
（不過產品上市時間相隔了一年，沒有進步的話就真該打屁股了 :P ）
我只測試了一個 sample，動畫 Kiddy Grade 的片頭，時間長度一分半鐘。
這個影片的色彩很鮮豔，對比強烈，雜訊不多，有很多平移畫面，淡入淡出的畫面，鏡頭慢慢拉近慢慢拉遠的畫面，還有一些動態非常激烈的畫面，不太好壓。
當然，還有動畫的銳利線條、無殘影等特性。

DivX 使用版本
DivX Pro v5.0.5

XviD 使用版本
1. Nic 編譯的版本 30-03-03
Nic 的這一版，有修改 iDCT 的演算法，使用的是 Simple iDCT。
XviD 原本用的 MMX iDCT 演算法是 Intel 的 AP-922，精度似乎不夠。
Simple iDCT 是 FFMPEG 用的 iDCT 演算法，據實驗有很好的效果。
為了解決 Quarter Pixel 解碼，使用不同 iDCT 算式會造成畫面顆粒像液體般流動的瑕疵，XviD 打算將 iDCT 的算式改成和 FFMPEG 一樣。
這樣以後用 ffdshow 來解碼有使用 Quarter Pixel 的 XviD 影片，就不會發生水波紋流動的這種瑕疵了。

============== 無關主題，順便一提 開始 ==============>

播放 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 自己來播放。

<============== 無關主題，順便一提 結束 ==============


2. 自己編譯的版本，25-04-03 的 CVS Fresh Check，手動修改了 iDCT 的演算法，使用 fdct_mmx + simple_idct_mmx2 的組合（按照我使用的 CPU 旗標設置。我的 CPU 沒有 SSE/SSE2/3DNow!2 指令集，Debug 設定底下還是用自動偵測），根據網友測試，這個組合是 XviD 的 PSNR 品質算出來最高的。