從 Nic 的 03-30，到我編譯的 04-25，XviD 修改了：
================================================
25.4.2003 15:00:
U xvidcore/src/motion/motion_est.c (rev.1.67) syskin:
- b-frames look good in still motion, after all

14.4.2003 15:00:
U xvidcore/src/motion/motion_est.c (rev.1.66) syskin:
- "What bug could i invent today ?"

14.4.2003 13:40:
U xvidcore/src/motion/motion_est.c (rev.1.65) syskin:
- improved vhq (does not decrease psnr anymore - at least for low quants) and tweaked p/b/i decision again

9.4.2003 12:20:
U xvidcore/src/encoder.c (rev.1.99) syskin:
- bframe_threshold works again - I didn't know anyone uses it ;>
U vfw/src/codec.c (rev.1.28) syskin:
- bframe_threshold = 0;

8.4.2003 11:40:
U xvidcore/src/encoder.c (rev.1.98) syskin:
- bframe_threshold not supported -> disabled
U xvidcore/src/motion/motion_est.c (rev.1.64) syskin:
- faster; better vhq; bframe-decision changed again
U xvidcore/src/motion/motion_est.h (rev.1.6) syskin:
- faster; better vhq; bframe-decision changed again

5.4.2003 16:20:
U xvidcore/src/motion/motion_est.c (rev.1.63) syskin:
- a bit faster + a small bugfix
U xvidcore/src/motion/motion_est.h (rev.1.5) syskin:
- a bit faster + a small bugfix

5.4.2003 02:40:
U xvidcore/src/global.h (rev.1.22) edgomez:
- Fixes 32 bit misaligned reads on ARM (+ some sync work with old 0.9.x tree for cleanups)
U xvidcore/src/bitstream/bitstream.h (rev.1.18) edgomez:
- Fixes 32 bit misaligned reads on ARM (+ some sync work with old 0.9.x tree for cleanups)

4.4.2003 11:00:
U vfw/src/codec.c (rev.1.27) Isibaar:
- set bframe threshold to 255 by default

4.4.2003 03:40:
U xvidcore/src/encoder.c (rev.1.97) Isibaar:
- CBR + b-frames bugfix
U xvidcore/src/utils/ratecontrol.c (rev.1.20) Isibaar:
- CBR + b-frames bugfix
================================================

測試一： 固定品質 quantizer 2 壓縮，壓出來檔案越小，壓縮效率越高。
然而檔案小，可能是壓縮時捨棄較多係數換來的（會造成畫面模糊、細節損失、誤差增加、畫質下降），所以同時計算 PSNR，測量品質。
PSNR（Peak Signal to Noise Ratio）是和原始影片比較的結果，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...nment/psnr.html


DivX 5.0.5 的設定：
1-pass quality-based
Quantizer: 2
不使用 Psychovisual Enhancements
Max Keyframe interval: 132
Scene change threshold: 50%
Performance/quality: Slowest
Encode as Progressive


XviD 的設定：
1 Pass - quantizer: 2
Motion search precision: 6 - Ultra High
Quantization Type: H.263
VHQ mode: 1 - Mode Decision
Maximum I-frame interval: 132
Minimum I-frame interval: 1
不使用 Lumi masking
Use Chroma motion
Chroma Optimizer(pre-filter) <- 這個選項會降低 PSNR，但是可以減少紅色部分鋸齒的現象

壓出來檔案大小
DivX 5.0.5: 36,706,304 bytes ( 100%)
XviD Nic's: 33,916,928 bytes (92.4%)
XviD 04-25: 33,153,024 bytes (90.3%)

接下來測定 PSNR，這裡要說明一下：
為了公平起見，所有壓縮版本的原始檔案都是統一由 Avisynth 做 RGB -> YV12 的轉換，用 VirtualDubMod，直接送 YV12 的資料給 Codec 壓縮。Avisynth 的語法是
avisource("Kiddy Grade NCOP_aup_vfapi.avi").ConvertToYV12()

比較的時候，是用這個原始檔案，和各個壓縮的版本比較。
各個壓縮版本的 AVI 開啟的時候，強制 Codec 輸出 YV12 的資料，所以我們計算的是 YUV 的 PSNR。
為什麼不比較 RGB 的 PSNR 呢？因為：
1. MPEG-4 本來存的就是 YUV 格式，要比較 RGB 的 PSNR，要經過 YUV -> RGB 轉換，轉換會有損失，應盡量避免。

2. MPEG-4 存的 YUV，是 YUV 4:2:0 格式，也就是 Y 的情報量是 UV 的四倍，取樣時四點共用一個 UV 值。
所以轉成 RGB 時，要經過 upsampling，YUV 4:2:0 -> 4:2:2 -> 4:4:4 -> RGB24。
upsampling 的工作，一般播放時是由顯示卡的硬體來做，所以每種 Codec upsample 的效果都一樣。
但是我們在做測試時，使用 Codec 自行解碼輸出做比較，不會用顯示卡硬體的 upsample，而是由各家的 Codec 自行 upsample，這時各家 Codec 的 upsample 好壞，就會影響測試成績。
然而我們不想比較各家 Codec 解碼時 upsample 的好壞，只想比較 Codec 壓縮時的功力，誰儲存的資料最接近原始檔案。
因為各家 Codec upsample 的好壞，不影響實際播放時畫面的結果；實際播放時，upsample 是由顯示卡來做的。
所以我們只比較 upsample 前，MPEG-4 檔內儲存的 YUV 4:2:0 資料。
如果考慮 Codec upsample 的話，XviD 大概會是最差的。
因為 XviD 的 YUV 4:2:0 -> 4:4:4，完全沒有做任何內插，而是直接將解出來的 UV copy 給四個點使用。

3. 因為 XviD 有 Chroma motion（動作搜尋同時考慮 UV）和 Chroma Optimizer（減少紅色鋸齒，會讓 PSNR 下降）等功能，所以分開計算 YUV，看看這些功能對 UV 造成的影響。

Avisynth 的語法是
# 原始檔 orig
orig=avisource("Kiddy Grade NCOP_aup_vfapi.avi").ConvertToYV12()
# 壓縮檔 encoded，強制 YV12 輸出
encoded=avisource("Kiddy Grade NCOP_XviD_H.263.avi", false, "YV12")
# 計算 Y PSNR，輸出 LOG 檔
compare(encoded, orig, "Y", "PSNR-XviD_Y.LOG", false)



人眼對 Y 較敏感，Y 的影響力較大，Chroma 比較不重要，分析數據時應以 Y 為主。

XviD 有開啟 Chroma Optimizer，這個 pre-filter 會改變 Chroma 的值，使得 Chroma 和原來的差距較大，因此 PSNR 會降低。
不過它可以減少紅色部分看起來的鋸齒現象，讓紅色部分看起來較平滑。

考慮檔案大小和 PSNR 比 (YUV PSNR/檔案大小%) 調整後的分數

DivX 5.0.5: 47.6851
XviD Nic's: 51.4499
XviD 04-25: 52.8295

XviD 大勝 :D

測試二：接下來測試開啟 B-frame 的效果

DivX 5.0.5 的設定：
和測試一相同，多加使用 B-frame
DivX 5 B-frame 的預設值，當 I/P Frame quantizer 為 2 時，B-frame quantizer 為 4

XviD 的設定：
和測試一相同，多加使用 B-frame
配合 DivX 5，將 B-frame ratio 設為 100，offset 設為 200，也就是同樣使用 quantizer 4
最大 B-frame 個數 4 個

壓出來檔案大小
DivX 5.0.5: 29,198,336 bytes (100%)
XviD Nic's: 29,896,704 bytes (102.4%)
XviD 04-25: 27,856,896 bytes (95.4%)

XviD Nic's 的 B-frame 壓縮率不如 DivX 5。
原因可能有：
1. XviD 的 VHQ 功能目前對 B-frame 沒作用。
B-frame 可供選擇的壓縮模式更多，從 VHQ 能得到的好處更多，不能用非常可惜。
B-frame 少了 VHQ 輔助，原本大勝的差距就被 DivX 5 追上。
由此可見 VHQ 很重要，一定要開。

2. XviD 的 B-frame 是動態地插入，會視畫面做判斷要不要使用 B-frame。
而 DivX 5 的 B-frame 則是固定的，一定要維持 IBPBPB... 的形式。
所以遇到不適合使用 B-frame 的畫面，DivX 5 還是要使用 B-frame，並且以高 quantizer 壓縮，畫質會較差。
而 XviD 的動態判斷還在改良，插入的判斷較保守，遇到這種高動態、無殘影的動畫訊源，插入的 B-frame 個數較少，以高 quantizer 壓縮的 B-frame 個數減少，壓縮率自然下降。
Koepi 編譯的版本有加入一個設定，可以讓你控制插入 B-frame 的判斷，將 threshold 設得越高，B-frame 插得越多。
Nic 的版本沒有開放這個選項，用的是內定的預設值 0。

然而經過 sysKin 這一個月來的改進，04-25 的 XviD B-frame 壓縮效率大增，檔案小了快 2MB !!
那麼畫質有沒有下降呢？
測定 PSNR。
這裡要說明一下，由於加入 B-frame，解碼時會產生 delayed frame，XviD 開頭多一張 frame，DivX 結尾多一張 frame，要把這些多出來的 frame 切掉，才能對齊比對，算出來的 PSNR 才會正確。
例如 XviD 開頭多一張，Avisynth 處理的語法
encoded=avisource("Kiddy Grade NCOP_XviD_H.263-B4.avi", false, "YV12").Trim(1,0)

算出來的結果：

贏得比不用 B-frame 的時候更多。

考慮檔案大小和 PSNR 比 (YUV PSNR/檔案大小%) 調整後的分數

DivX 5.0.5: 46.5382
XviD 04-25: 49.1835

還是大勝 :D

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

用了 B-frame、Quarter Pixel、GMC 等進階功能壓縮率和畫質就會變得比較好嗎？
不一定。
B-frame 因為提高 quantizer 壓縮，通常來說使用 B-frame 後檔案都會縮小，但是品質確有可能降得非常快。
使用 B-frame PSNR 會下降可以理解（因為 B-frame quantizer 較高），但是如果降得太離譜，視覺品質也會很明顯的跟著下降。
XviD 的三位大神之一 gruel 曾做過測試，VQEG 的測試 sample 中，有一個影片只要一開 B-frame，PSNR 會整整掉 12.5dB !!
（根據經驗，CG 動畫類的通常不太適合開 B-frame，不過也有反例，要看素材的內容）
所以哪些影片適合使用 B-frame，哪些不適合用，這正是 XviD 正在努力研究的方向。
Quarter Pixel 也是，根據理論 Quarter Pixel 可以提高壓縮率，但是據許多人的測試，開了 Quarter Pixel 後檔案有時反而會變大。這也是 XviD 的開發人員正在研究的課題。
同理 GMC 也是，用了不一定會提高壓縮率、促進品質。
XviD 希望能夠歸納出各種功能適當的使用時機，在適當的時候才使用這些功能，讓這些工具能發揮最大的效率。
所以在此之前，如果你的流量夠，不計壓出來的大小，或是檔案很好壓縮，可以試著不用 B-frame。
然而 B-frame、Quarter Pixel 使用後都有一些視覺上的作用，例如 B-frame 具有減少雜訊的作用，Quarter Pixel 會讓顏色變深。
如果希望具有這些視覺效果，那麼就開啟這些功能吧。

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

測試三： 比較 Multi-pass 的結果，目標將檔案壓縮至 14,000,000 bytes
DivX 5.0.5 使用 B-frame，quantizer 2。
XviD 04-25 使用 B-frame 個數 2，ratio 200，offset 0，quantizer 2。
XviD 另外再壓一個 VHQ mode: 4 - Wide Search 的版本。
固定 quantizer 模式下，提升 VHQ mode 會減小壓出來的檔案大小，不過 PSNR 會下降。
在極低流量時使用 VHQ mode: 2~4 可以提升整體品質。

DivX 5.0.5 0-pass: 29,198,336 bytes -> 14,000,000 (47.9%)
XviD VHQ-1 1-pass: 27,917,414 bytes -> 14,000,000 (50.1%)
XviD VHQ-4 1-pass: 26,745,202 bytes -> 14,000,000 (52.3%)

影片的解析度 640x480，23.976fps，長度一分半鐘，最終檔案大小定為 14000 KB，每個 Pixel 平均分到 0.172 個 bits，已經在 Gordian Knot 這個軟體建議的品質以下。
而且這部影片並不好壓縮，當流量低於一定水準以下，畫面會劣化非常快。
很想看看壓出來會是什麼樣子 :P


DivX 5.0.5 的設定：
Multipass, nth pass
Max bitrate: 12800kbps
Encoding bitrate: 1280kbps
Bitrate modulation: 0 (Constant quality)
其他設定同測試二

DivX 5 的 B-frame 預設值 quantizer 是 I/P Frame 的兩倍，這個檔案壓出來 P-frame 大都接近 4，B-frame 的 quantizer 則大都為 8。

XviD 的設定：
============== 無關主題，順便一提 開始 ==============>

我們知道 XviD 的 2-pass 是它的最大弱點。目前 2-pass 的演算法很混亂，而且當初設計時也沒有考慮到後來加入的新功能 B-frame，同時：
1. XviD 的 2-pass 演算法 1st-pass 的時候用 quantizer 2 壓一遍，2nd-pass 根據 1st-pass 壓出來的 frame size 做調整。
以 linear-scaling 為例，假如目標檔案大小是 1st-pass 壓出來的檔案大小的一半，則每個新的 frame size 就是原 size 的一半。
假設 frame size 和 quantizer 之間有一線性關係，2nd-pass 提高每個 frame 的 quantizer 壓縮，使壓出來的 frame size 接近我們所預期的目標大小。
我們設定一個位元儲存槽的大小，如果壓出來的 frame 超過預期大小（overflow），可以先借用位元儲存槽內的位元來用。
如果壓出來的 frame 小於預期大小（underflow），則多的位元就可以還給位元儲存槽。
位元儲存槽會在一段時間內調節（payback），最後壓出來的檔案大小會接近設定的目標大小。

然而這樣的假設是錯的，
1) frame size 和 quantizer 之間沒有一線性關係
2) 2nd-pass 的參考畫面和 1st-pass 不同，1st-pass 的參考畫面是前一張用 quantizer 2 壓縮的畫面，畫質很好。
而 2nd-pass 的參考畫面是前一張提高 quantizer 壓縮的畫面，畫質不像 1st-pass 時那麼好。
2nd-pass 參考這張畫面壓縮，壓縮的困難程度比 1st-pass 高，要符合預期的檔案大小，quantizer 可能必須非常高。
這種 scaling 方法沒有考慮到實際壓縮時，畫面的複雜程度，而僅以第一次壓縮時 quantizer 2 的狀況
來做調整，可能會發生落差太大的情況，會造成某些非預期的壓縮瑕疵。

2. linear-scaling，將所有 frame size 依相同比例下降，卻沒有考慮到各個畫面的複雜程度不同，有的畫面減小太多流量，會造成 distortion 太嚴重，壓縮瑕疵會非常明顯。
用 linear-scaling quantizer 的震盪幅度太大，無法維持一恆定品質。

3. B-frame 的 quantizer 根據前後 I/P Frame 的 quantizer 調整，如果前後 I/P Frame 的 quantizer 太高（例如壓縮的困難程度超過預期，但是 Encoder 為了要符合設定的 frame size，會突然用很高的 quantizer 壓縮），這時 B-frame 的 quantizer 會拉得更高，畫面會出現非常明顯的壓縮瑕疵。

4. 連續太多個 B-frame，如果 B-frame 的 quantizer 又很高的話，會出現很明顯的壓縮瑕疵。

5. 為了避免上述的瑕疵，將 B-frame 的 quantizer 調低的話，B-frame 的壓縮率會下降，整體的品質也會下降。

所以.....

XviD 開發中的 dev-api-4 有新的 RC 演算法，比以前的演算法好很多，沒有上述的問題，也不會再出現一堆莫名其妙的瑕疵，據測試，PSNR 比現在的版本提高 2dB，非常恐怖。
在 dev-api-4 完成之前，現階段用 XviD 的 2-pass 要得到好的結果，沒有辦法，必須視情況自己手動調整。
1. 如果 1st-pass 壓出來的檔案大小 對 目標的檔案大小 的差距不大，則用 linear-scaling 可以得到很好的效果。

2. 如果差距接近一半，可能需視情況手動調整、限制 I/P Frame 的 quantizer。

3. 如果差距極大，可能需視情況使用 Curve Compression。

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

B-frame 的 ratio 設為 200，offset 設為 0，這樣 B-frame 的 quantizer 會是前後畫面 quantizer 平均的兩倍，如果前後都是 quantizer 4，B-frame 的 quantizer 就是 8。
靜態場景 XviD 會連續插入 B-frame，連續多個 B-frame 如果又是高 quantizer，視覺上會有明顯瑕疵（例如畫面好像在浮動或是流動的現象）。
為了避免這個問題，減少 B-frame 個數為 2 個。
為了提高 B-frame 的壓縮率，有效利用 B-frame，我們將 B-frame 的 quantizer 設為兩倍，但是如果遇到前後 I/P Frame 的 quantizer 很高的話，B-frame 的 quantizer 會更高，而且以倍數成長，畫質會慘不忍睹。
考慮我們所壓的檔案大小和 1st-pass 比，壓縮比是 50.1%，I/P Frame 的 quantizer 應該可以維持在 6 以下，所以我強制限制 I/P Frame 的 quantizer 範圍為 2~4，這樣 B-frame 的 quantizer 最高只能到 8，避免 B-frame 壓出瑕疵。

其他設定皆使用 linear-scaling 的設置
I-frame Boost %, High bitrate scenes%, Low bitrate scenes% 都設為 0
below i-frame distance...: 10
I-frame bitrate reduction %: 20
Bitrate payback delay: 240
Payback proportionally
其他同測試二

這樣設定壓出來，XviD 的 quantizer 分佈
VHQ-1


絕大部分的 P-frame 都是以 quantizer 4 壓縮，相對應地，B-frame 幾乎都是以 quantizer 8 壓縮。
由於限制的 quantizer 範圍太小的關係，上下震盪的幅度很小，幾乎快變成和用 quantizer 4 固定壓縮沒兩樣了 ^^;

VHQ-4 的 目標檔案大小設為 14110 Kbytes，quantizer 分佈

平均 quantizer 較 VHQ-1 下降 0.134。

壓出來檔案大小

DivX 5.0.5 2-pass: 14,501,888 bytes ( 100%)
DivX 5.0.5 3-pass: 14,508,032 bytes ( 100%) <- 檔案偷偷變大一點
DivX 5.0.5 4-pass: 14,510,080 bytes ( 100%) <- 再變大一點
XviD VHQ-1 2-pass: 14,489,600 bytes (99.9%)
XviD VHQ-4 2-pass: 14,485,504 bytes (99.9%)





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

也許有人有疑問。
這個測試裡的原始檔案大家都一樣，都是由 Avisynth 做的 YV12 原始檔。
avisource("Kiddy Grade NCOP_aup_vfapi.avi").ConvertToYV12()

所以測試保證公平。

然而 Avisynth 載入的 Kiddy Grade NCOP_aup_vfapi.avi 這個檔是 RGB24 的 VFAPI，
為什麼不乾脆用全程 Avisynth，做全程 YV12 的製程？
因為：
1. 我需要用到 TMPGEnc 做 IVTC。
2. 全程 YV12 製程有所限制，不是每種訊源都可以使用。

有什麼限制？

對了 Nic 寫的 MPEGDecoder.dll 的 Chroma upsampling 是錯的，不要用。

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


雖然平均 PSNR 大家都有 43dB，但是最低 PSNR 則在 35dB 上下，因為是動畫，銳利線條周圍的 ringing effect 瑕疵看起來已經非常明顯，已經在我忍耐的極限邊緣 :P
下面是幾張抓圖

首先真的非常感謝Shade大大提供這麼詳細的測試資料^^
最近剛好在研究如何提昇XVID的品質...
因為我覺得對一般人的眼睛來看
淡入淡出的場景壓出來的瑕疵遠比各實驗數據來的顯眼:p
所以我把主要目標放在解決這問題
這問題一天不解決我寧可繼續用DIVX5壓動畫(這瑕疵對動畫真是致命傷)
不過如果能讓我滿意到放棄DIVX5我倒很期待
畢竟DIVX5他有Multipass, nth pass這功能
就是很手賤的覺得不壓到3 pass會很浪費(笑
不過相對的花的時間也比較多(泣
如果XVID只要2 pass就能達到相同的效果我當然馬上換!

在此順便問幾個問題

上面的狀況我發生在DIVX5.03
不過有趣的是我是在只不勾Quarter Pixel的狀況下出現
反而B-frame、Quarter Pixel、GMC全勾就沒有發生
我記得DIVX5.03在使用時只要勾了GMC 就不能勾Quarter Pixel
可是不勾反而更慘呢真的很奇怪@@
而且我發現三個全勾了以後觀看時也並不會有任何瑕疵出現

我記得TMPGEnc只收RGB的資料
那就算用 VirtualDubMod 這個軟體
只要用TMPGENC做過IVTC就不算全程YV12嗎?
如果是這樣那這種機會對DVD轉AVI也太少了
有幾家DVD可以百分百FILM不用手動檢查IVTC的:(

多按的@@請砍

我壓了幾部有快速淡入淡出、慢慢淡入淡出的動畫影片，沒有發生這個問題 :)
所以您可以換用最新版的 XviD 試試看。

DivX 5 會發生液體流動狀的瑕疵是因為量化的問題，即使用 DivX 5 自己的解碼器解碼也會出現這種瑕疵，這和上面說的 XviD 影片用 ffdshow 解碼會因為 iDCT 算式不同而產生的問題不一樣，這是 DivX 5 本身設計的瑕疵。新版的 5.0.5 有改善這個情況，我壓了幾部都沒有看到這個問題（或者說比較輕微）。
前面有提過，用 DivX 5.02 不要勾 Qpel，有 Bug。用 DivX 5.03 以降不要用 Qpel + B-frame，有 Bug。DivX 5 的 GMC 不必用，因為用了也無法提升多少壓縮效率，有些影片用了反而會有反效果，檔案越壓越大。
DivX Pro 提供的那幾個進階功能，真正能用的只有 B-frame。

動畫類的很少百分之百 FILM。
所以我自己也很少用。
全程 YV12 在色彩的傳真度上是有它的優點，而且處理速度很快。
不能全程 YV12，可以退而求其次，部分 filter 處理用 YV12，至少可以加快速度。

在其他地方的一些後續討論
==
........
抓圖得等一會兒，現在要先吃飯 :P
PSNR 越高，質量越好，代表和原檔案的誤差越小。
所以我也覺得很奇怪，怎麼我壓出來的 PSNR 那麼高，可是我看起來已經覺得很爛，爛的快受不了 :P
最主要動畫銳利線條周圍很容易出現斑斑點點的壓縮瑕疵，很難看。
讓我驚訝的是，這部影片開了 B-frame 之後，PSNR 竟然只下降 1dB，我之前的經驗，動畫類的影片一用 B-frame，PSNR 通常會狂跌。

等吃完飯再把測試四的結果貼上來，測試四是用接近人眼主觀測試的評鑑方法做的，用的是 ITS 的演算法，也就是 ANSI Rec. 使用的視覺品質評鑑法，用來做視訊廣播品質的測試，計算的是畫面的模糊程度、馬賽克（方塊）的程度、邊緣雜訊的程度... 等等接近人眼視覺品質的測試法。
使用這個測試，可以推知影片看起來的視覺品質，同時也可以看看測試結果是否符合一般的印象，以及和 PSNR 的相關程度，蠻有趣的 :)
==
........
其實我已經把 XviD 的相關設置選項的選擇方法都寫在上面的測試報告裡面了，您沒有注意到嗎？ ;)
上面的測試報告與其說是測試報告，倒不如說是心得報告 :P
因為 XviD 壓出來的結果會贏已經是這些日子以來大家都知道的事實，所以如果只是做單純的測試數據報告，似乎有點無聊，所以小弟把製作時的想法，為什麼這麼選擇，這麼選擇有哪些缺點，改進調整的方向和方法都寫在上面的說明裡面了。
例如為什麼要提高 B-frame 的壓縮率？ 促進整體品質。
提高 B-frame 的壓縮率將流量分給 I/P Frame 有什麼好處？ 參考的 I/P Frame 畫質好，B-frame 的瑕疵會看不出來，整體品質提高。
B-frame quantizer 設得太高會有什麼缺點？ B-frame 會出現一堆瑕疵。
B-frame quantizer 設得太低會有什麼缺點？ 壓縮率下降，連帶整體品質下降。
B-frame 連續個數設得太多會有什麼缺點？ 靜態畫面會出現瑕疵。
什麼時候判斷考慮限制 quantizer？ 視 1st pass 壓出的檔案大小和目標大小判斷。
限制 quantizer 的範圍要設多少才好？ 視預測的 quantizer 使用情況判斷。
限制 quantizer 太極端會有什麼缺點？ 會變成都用同樣的 quantizer 壓縮，變成固定品質壓縮，那麼用 1-pass quantizer 壓縮即可，還做 2-pass 幹嘛。
......
等等。
這些都是小弟的使用心得，其實都寫在裡面了 :)

至於 DivX 5.0.5 的設置，其實沒什麼好設的，大部分的選項 DivX Networks 都已經從使用者介面中拿掉了，如果你還是要控制，可以從 CLI 命令列中下指令控制，不過我找不到需要特別這麼做的理由，DivX 5.0.5 預設的 RC 演算法已經工作得相當好，幾乎可以說只要 bitrate 指定好，開始壓就可以去睡了，商業軟體就是要做得這麼好用才行 :D

以上小弟使用的方法，並不是最好的設置，例如 XviD B-frame 的 quantizer 一定要和 DivX 5 一樣設為兩倍才可以嗎？用 ratio 150, offset 100 會不會更好一點？這個可以再實驗研究。B-frame 的 quantizer 下降，那麼 I/P Frame 的限制範圍可以放得寬鬆一點嗎？這個也可以再實驗研究。
同理，DivX 5.0.5 的設定這樣是最好的嗎？如果把 Bitrate modulation 不要設在固定品質，還是設給低動態的畫面多一點 bitrate，或是設給高動態畫面多一點 bitrate，看起來會不會比較好？
這些，都要再實驗研究、歸納、整理，找出不同類型的訊源、不同的流量，適合的使用方法 ^^;
而這些就需要常常壓製影片的人，才能作這樣的整理與報告了。
小弟只能從原理上，提供一些思考的方向 :)
==
好恐怖，gruel 完成了 Trellis Quant（天啊，我盼了好久了），現在已經加到 dev-api-4 裡面，而 dev-api-4 也已經完成得差不多了，看起來很穩定，XviD 的首頁發佈了以下的新聞

3 warp points 的 GMC（Global Motion Compensation）也已經完成（DivX 只有 1 warp point，等於沒用，1 warp point 做得到的事情，用一般的 Local MC 也可以做得到，用 GMC 不一定會比較省 bit），另外 gruel 用 skal 寫的 GME（Global Motion Estimation，GMC 的前置作業，就像一般的動作搜尋 (L)ME，ME 的結果做補償補上誤差叫做 (L)MC）程式碼做參考，改寫了原本的 GME 的演算法，現在的 GME 更有效率，開啟 GMC 功能檔案不會變大。（還在測試中，gruel 在找什麼情況下使用 GMC 會最有效率，encoder 會判斷，只有當 GMC 可以省 bit 時才使用 GMC）

Trellis Quant 初步測試可以提高 PSNR 大約 0.1~0.3dB 左右。

XviD 1.0 差不多快出來了 :D
Things are moving fast!! ;)
==

測試四和五（？）六....（還有嗎 ^^;），以及抓圖，晚點才能放上來，大概會是明天吧....