很好奇耶，裝了xvid可以看divX的檔案，裝了divx也可以看xvid的檔案?
是這樣嗎??

不行.

DivX 5.02 對目前新版的 XviD
XviD 的品質較好（PSNR 高，檔案較小）

DivX 5.03 對 XviD
沒比過不知道
我猜 XviD 贏

XviD 的 2-pass RC（Rate Control）較 DivX5 混亂，2-pass 可能較不利，不過使用 linear-scaling，中高流量應該還是可以贏過 DivX5，極低流量可能互有勝負。
XviD 新版的 RC 已經完成，現正合併進 dev-api-4 裡面，
敬請期待


不知道你問的是哪兩個。
如果是問 Ext. 和 Int. 的差別，Ext. 是 2nd-pass 的時候，使用指定的外部 stats 檔來進行壓縮，例如你用 StatsReader 修改過 stats 檔，便可以用這個選項來讀取修改後的 stats 檔進行壓縮。其最終的檔案大小，由修改後的 stats 檔內記錄大小決定，你不可以另行設定。
Int. 是使用 1st-pass 時產生的 stats 檔進行壓縮。
一般使用 Int. + 內建的 linear-scaling 即可，不需要用到 Ext.。

不是這樣。

Shade兄您好,在下可否冒昧請問一個問題，在最近新版的xvid裡(約20032月以後)，在Global的設定畫面裡，多了VHQ Mode，分別有0~4五種選擇，
0-Off
1-Wide decision
2-Limited search
3-Medium search
4-Wide Search
請問它們的功能是什麼，選項的說明只提到增加搜尋提昇品質，選用的話是否真有實質功用?
此選項當開到4時，我的AMD xp2400+一秒只能處理十張…

先謝謝您的回答...我了解了ext跟int的差別了..謝謝^^

另請問多少才算是中高流量呢
如果使用2 pass的xvid不好的話
請問要使用xvid的哪個呢

就以前我使用1pass時的divx
除了CBR外
比較難由quality來計算出檔案大小
我猜想xvid應該也沒辦法計算吧..?

請問關於看xvid的電腦配備cpu最低要多少
之前曾經下載過一個軟體,是讓電腦配備比較低的人可以看divx影音同步
http://tw.groups.yahoo.com/group/ci...ow-20021113.exe
自從下載後
我若讓檔案用縮圖方式顯示
本來是可以看到影片第一個畫面的
但裝了之後divx的影片縮圖都變成黑的
但xvid的還是可以看到第一個畫面
所以猜想也許xvid需要的配備跟divx的不同...
而那個軟體可能只是針對divx設計的....
不太確定~

目前是據說,有安裝那個軟體的電腦配備最低可支援到450

我也不知道如何定義 :P
這個要看畫面的大小，壓縮的難易程度，每秒的張數等等來決定。
不同影片適當的中高流量定義可能不同。
總之如果壓縮後畫面一直出現明顯瑕疵，代表流量不足，即可視為是流量過低。
在這種情況下，XviD 因為分配流量的方式和 DivX5 不同，可能有些畫面優於 DivX5，有些畫面劣於 DivX5，互有勝負。
這時就看哪種分配法剛好會讓人眼看起來覺得比較舒服，沒有一定。

也沒有別的能用了 :P
XviD 的 2-pass 設計有一些核心上的問題（例如無法整合 B-frame），會削弱 XviD 原本的優勢，使得和 DivX5 的差距拉近。
但是要在固定檔案大小的情況下用比較好的流量分配，不用 2-pass 是不行的，所以雖然目前 2-pass 有缺點，但是也只好用了。
等新的 dev-api-4 測試完畢，XviD 就會有新的 RC 和 2-pass 演算法，到時就可以真正發揮 XviD 全部的實力了。

沒有辦法，但是 XviD 的 2-pass 可以準確的指定檔案大小。

那個檔案是 ffdshow，使用 libavcodec 解碼，也就是 FFMPEG，在 Linux 上很有名。
最新版可以在這裡下載
http://sourceforge.net/project/show...?group_id=53761

ffdshow 有針對 CPU 的指令集做最佳化，解碼速度很快。
它有針對 DivX5/XviD 測試版壓出來的一些 bug 做修正，相容性很高。
FFMPEG 用的 DCT 算式是 simple dct/idct，和 DivX5/XviD 都不同。
ffdshow 設定裡面可以讓你選擇 iDCT 解碼的算式，如果播放的影片是 XviD 壓的，用 XviD 的 iDCT 算式解碼畫質會比較好。

LOCK.LAI 兄：

VHQ 是高品質模式，在固定檔案大小下，壓出來的品質較好；在固定品質下，壓出來的檔案較小。
有用，真有實質作用，而且非常有用。
你可以把它視為是 Motion search precision: 7。
根據測試，固定品質下，檔案大小可以縮減 6%~13% 以上，非常強。
缺點是壓縮速度會變慢，魚與熊掌無法兼得。
不過比起 DivX 5.03 的 n-th pass，VHQ 不但速度快很多，而且對畫質/檔案大小的幫助更顯著，更有實質作用。
我以前做過一點實驗
固定 quantizer 2 壓縮 - 檔案大小 - 相對大小
1) DixV 5.02 - 38,660,096 - 100%
2) XviD - 37,261,312 - 96%
3) XviD VHQ4 - 34,537,472 - 89%

固定品質下檔案大小 3 < 2 < 1

平均 PSNR（壓縮後和原本訊源的差異，PSNR 越高畫質越好）
1) DivX 5.02 - 46.29 dB
2) XviD - 46.37 db (+0.08dB)
3) XviD VHQ4 - 46.30 dB (+0.01dB)

PSNR 2 > 3 > 1

VHQ1 - Mode Decision 一定可以縮小檔案大小，並且提高品質
VHQ2~4 - 增加搜尋範圍，一定可以更進一步地縮小檔案大小，但是品質（PSNR）卻會下降，這點必須注意。
當中低流量時，使用 VHQ2~4 通常可以取得較好的檔案大小 - 品質比。
也就是當中低流量時，使用 VHQ2~4 品質會比較好。
高流量時，使用 VHQ1 就好。

新版的 XviD 還有一個功能，叫做 Chroma Optimizer，在 Debug 這一頁裡面可以勾選，用了以後檔案可能會變大，但是可以讓紅色部分的鋸齒減輕，畫面更漂亮，對動畫尤其有用。

呃... 有人對 VHQ 的原理有興趣嗎？ ^^;
以前寫過這麼一篇說明...
==
簡單的說，高品質模式，開了同流量下品質比較好，固定品質下檔案比較小。

複雜的說... 真的要複雜的說嗎？ :P
（有人要看嗎？ ^^;）

我們知道壓縮的時候會將畫面切成好多個 16x16 大小的小方塊作動作預測，每個方塊稱為 Macroblock。
每個 Macroblock 壓縮的時候要做好幾個選擇，首先我們要決定這個 Macroblock 是要獨立壓縮，壓成一個 intra-block，或者是要參考其他畫面壓縮，壓成一個 inter-block。
接下來如果是壓成 inter-block，要參考其他畫面作預測壓縮，那麼要使用哪種動作預測模式呢？
例如 MPEG-4 有 INTER4V（4MV）模式，一個 Macroblock 可以有 4 個 Motion Vector（動作向量），內部 4 個 8x8 的小方塊各自使用一個 MV，各自記錄最接近的參考對象。
使用 4MV 讓內部的小方塊各自參考誤差最小的對象，可以縮小所需記錄的誤差值，但是同時需要記錄的向量個數也會增加為 4 個，一來一往、此消彼長，到底能不能提高壓縮效率並不一定，要看情況。
那麼是要使用一般的 16x16 方塊共用一個 MV 的預測模式（INTER），還是要使用 8x8 方塊的 4MV 預測模式（INTER4V），這個 encoder 必須要作決定。

最後 encoder 還要決定找到的參考對象誤差是不是很小，如果小到一定程度，我們就可以視為沒有誤差，不用編碼、記錄這個 Macroblock 的誤差（not coded）。
此時如果 MV = (0,0)，也就是參考的對象和目前的方塊在畫面上的同一位置，那麼這個 Macroblock 就可以 skip 掉，完全不記錄任何資料，顯示的時候直接使用前一個畫面相同位置的方塊來顯示。

Macroblock 要用上面哪種模式壓縮，壓出來所需的 bit 會最少，encoder 必須要作判斷。
判斷的時候會根據理論上的算式作判斷，例如如果 四個SAD8x8的總和 < SAD16x16，我們就把這個方塊用 INTER4V 模式壓縮。
SAD 是 sum of absolute differences 的縮寫，誤差絕對值的總和，是一種計算誤差量的方法。
根據這些簡單的計算判斷，encoder 可以很快速的決定要用哪種模式壓縮。
但是這樣壓出來真的會最小，所需的 bit 真的會最少嗎？
答案是不一定。
可能這個 Macroblock 用 INTER 壓縮會比較有效率，壓出來所需的 bit 會比較少，但是卻被計算式判斷為要使用 INTER4V 壓縮，白白浪費了許多 bit。
所以 XviD 和 FFMPEG 的開發小組之前就發現，使用 4MV 模式的時候，壓縮效率反而不好，就是因為 encoder 的判斷太簡單，造成了 4MV 的使用沒有效率，使得壓出來的檔案反而更大。

FFMPEG 首先設計了一個 VHQ 模式，也就是高品質模式，也叫做 brute force mode。
在這個模式底下，encoder 會把 Macroblock 各種可能的壓縮模式都壓一遍，INTRA/INTER/INTER4V... 都壓一次，然後從裡面選壓出來最小，所需花費的 bit 數最少的一種模式來使用。
這樣就可以確定，我們選擇的壓縮模式是最有效率的壓縮模式。
實驗結果證明，使用 4MV 的時候一定要搭配 VHQ 模式，壓出來的品質才會最好，檔案也會是最小的。
不過當然，使用 VHQ 模式壓縮的時間也需要比較久。

XviD 現在也設計了這個 VHQ 模式，第一件做的事情（VHQ 設定選項選 "1 - Mode Decision"）就是上面說的 brute force，每種模式都壓一次，選最好的。

XviD 的 VHQ 模式做的第二件事情，是 FFMPEG 裡面沒有的，但是這個功能還是要從 FFMPEG 談起。
FFMPEG 可以讓你自行選擇動作估計（ME）的時候使用的「比對最小誤差」的計算方法。
當我們尋找誤差最小的參考對象時，要怎麼比較哪個參考位置的誤差是最小的呢？
一般我們是使用上面提到的 SAD，將兩個方塊的像素值相減，取絕對值，然後把 16x16 所有的點相減的結果加起來，作為總和的誤差。
這個計算的方法比較簡單，速度很快，效果也很不錯。
但是 FFMPEG 還提供了其他各種的比較方法讓你作測試，有：
0. SAD: sum of absolute differences，計算法如上所述
1. SSE: sum of squared errors，和 SAD 差不多，但是不是取絕對值，而是平方，計算複雜度高一點
2. SATD: sum of absolute hadamard transformed differences，將像素值先作 hadamard 轉換，然後再比較兩個方塊 hadamard 轉換後係數的絕對值差值。這是 H.264 建議使用的做法，計算複雜度又比 SSE 高
3. DCT: sum of absolute dct transformed differences，先作 DCT 轉換，然後比較 DCT 係數的絕對值差值，理論上是最精確的比較法，但是計算複雜度最高
4. PSNR: sum of the squared quantization errors，計算量化誤差的平方總和
5. BIT: number of bits needed for the block，計算此方塊實際所需的 bit 數
6. RD: rate distoration optimal，利用 Lagrangian 算式找出 rate-distortion 的最佳平衡點

實驗證明，次像素的動作檢索如果使用比較精確的比對方法，例如 SATD/DCT，品質會提高（這個同時是 H.264 建議的方法）。
同時固定碼率下，BIT/RD 的比對法也會提升品質。
另外 SSE 似乎對動畫類型的影片有最好的效果。

XviD 的開發人員看到 FFMPEG 不錯的實驗結果，也開始著手開發類似的高品質模式。
sisKin 一開始是打算使用 DCT 比對法（因為他說雖然 DCT 比 SATD 複雜，但是他發現實際上壓縮的時候最耗時的動作不是在 CPU 的計算上，而是在等待記憶體的存取上，所以使用 SATD/DCT 的速度應該不會差太多），結果後來是使用 BIT 比對法，比較實際上所需的 bit 數最小的。
以前曾說過 ME 的時候做次像素的動作檢索，例如 Quarter Pixel，可以提高壓縮率，但是那時沒仔細說 Quarter Pixel 是怎麼做的。
如果我們一開始的時候就把整個畫面內插，補出 1/4 的像素，然後在這個畫面上作檢索，這樣一定會很慢很慢，因為要搜尋、比對的位置變得很多，範圍很大，而且也很沒有效率。
所以實際上做的時候，我們是先做整數像素的搜尋，找出整數像素上誤差最小的位置，然後再內插補出這個位置周圍的 1/2 像素，訂出八個新的搜尋位置，如下圖

這樣我們就只要比對這八個新位置和原來的整數像素位置哪個誤差最小，就可以找出 1/2 像素精度誤差最小的位置。
這麼一來就不用內插計算那麼多的點，也不用比對那麼多的次數，是不是比較有效率呢？
做完 1/2 Pixel 之後，我們可以繼續再做 1/4 Pixel 精度的新位置比對，依此類推。