![]() |
||
Senior Member
![]() ![]() ![]() 加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
XVID Codec - 23/10/02 的使用心得
不知道版上有沒有人用?(除了 lwb 大大之外 :P )
小弟提供一點心得給大家作參考。 http://nic.dnsalias.com/ XVID - 23/10/02 Changes: QPel turned on with Motion Search: 6 New Dev3 API build. (Development build, certain functionality may be unstable!) Minor fixes/quality/speed improvements to Q-Pel, B-Frames & ME code ICL 6 Compiled (although should work on lower end machines) (i.e. no fancy options, just /O3) |
|||||||
![]() |
![]() |
Senior Member
![]() ![]() ![]() 加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
試用心得:
1. Qpel 開啟在動態檢索設為 6 的時候。 2. Qpel 還是和以前一樣,開了會使檔案變大(畫質沒有明顯提升)。 Qpel 的 MV 需要雙倍精度紀錄(ex: 1.5 --> 1.25), 存成 bitstream 的時候會比較不好壓縮,如果沒有能夠找到差距更小的參考方塊, 檔案反而會更大。XviD 的 Qpel 目前還是沒有良好的實作出來,無法達到 理論上的壓縮助益。 3. Qpel 可以用 XviD 的 Filter 解碼。DivX 5.x 因為 Qpel 作錯,會解錯。 FFDSHOW 目前無法正確解碼 XviD 的 Qpel(不清楚誰作錯), 不過下一版應該會修正。 4. Nic's 10-23 的版本比 10-21 的版本好很多,10-21 壓出來的檔案超大, 而且 Qpel 有問題,畫質不佳。 5. 如果不想使用 Qpel,將動態檢索設為 5 即可。 6. uManiac 的 10-21 的版本沒有 Nic's 版本的問題,不過他的 Qpel 沒有打開, 即使動態檢索設為 6 也不會使用 Qpel。還有他編譯的時候沒有修改 TOO_SMALL_LIMIT 這個參數,壓出來的畫質較差。 TOO_SMALL_LIMIT 這個參數是判斷,當某個 block 的 DCT 係數總和少於 一定值的時候,便 skip 掉這個 block 不壓縮。 根據實驗,固定流量下忽略掉這些係數很小的 block 不壓縮,將流量分配給其他 block,可以提升 PSNR 數 dB。 不過實際目測壓縮後的結果,捨棄掉太多 block 不壓縮,會使畫質明顯變差, 少掉很多細節。 所以 sysKin 建議,這個值最好不要大於 1。然而 CVS 裡面的預設值是 2, 所以編譯的人需自行修正。 7. 開啟 B Frame 會自動關掉 Qpel。目前 B Frame 和 Qpel 無法同時使用。 8. 開啟 B Frame 會無法使用 MPEG Custom Quantization Matrix,只能用 H.263 的量化方法。 H.263 的量化方法,顧名思義,就是使用 H.263 這個壓縮規格的量化方法。 H.263 使用均勻的量化矩陣,高低頻係數都用同一個量化間距(除同一個數字) ,而且 MB 和 MB 之間的 Q_scale(量化間距的放大係數)不能相差超過 2。 MPEG 的量化方法使用非均勻量化矩陣,高低頻係數除不同的數字,MB 和 MB 之間的 Q_scale 可以自行視情況調整沒有限制,同時可以用使用者自行定義 的量化矩陣。 H.263 壓縮出來的畫面會較模糊,MPEG 壓縮出來的畫面會較清晰。 MS MPEG4 便是使用 MPEG 的量化方式,所以畫面較清晰。DivX 4 使用 H.263 的量化方式,所以畫面很糊。 DivX 5.x 也是使用 H.263 的量化方法,不過顯然有改進,不像 DivX 4 那麼糊。 (DivX 5.x 也可以藉由修改機碼的方法,改成使用 MPEG 壓縮,不過不要嘗試, 因為 bug 很多,壓出來的畫面慘不忍睹) 使用自行定義的量化矩陣可以視情況修改量化係數,在固定流量下找出較佳的品質。 同時用自行定義的量化矩陣也可以作出比 DivX 5.x 更清晰的 MPEG-4,或者是 變態品質的 MPEG-4。(不過 MPEG-4 的 DC 精度只有 8 bit,還是比不上高流量 10 bit, 11 bit 的 MPEG-2) 不過現在使用 B Frame 便無法使用 Custom Quantization Matrix,使得 XviD 的 優點少了一項。 9. 連續 B Frame 的最大值設得太高,會使壓縮率下降(後面的那張 P 距離參考 Frame 太遠,檔案大小會暴增)。 設為 2 檔案會比 1 小,設為 4 檔案反而會比 2 大。 不過檔案大小的差距不像我以前剛試 B Frame 的時候那麼大,可見新版的 XviD 的動態 I, P, B Frame 分配決策比以前優秀很多。 實際觀察壓出來的結果,連續靜態畫面 XviD 會使用較多的 B Frame, 達到設定的最大連續 B frame 的個數值。 ex: 動態越小 ---> IBPBBPBBPBBBPBBBBPBBBB.... 當畫面的動態變大,XviD 就會減少 B frame 的個數,縮短 P frame 的間距 ex: 動態越大 ---> IBBBBPBBBPBBBPBBPBPBPB.... 所以當壓縮的素材靜態畫面居多時,可以放心的加大連續 B Frame 的個數。 |
||
![]() |
![]() |
Senior Member
![]() ![]() ![]() 加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
10. 目前的 XviD 的 DirectShow Filter 解 B frame 會出錯,當 B frame 的下一張
參考畫面是 I Frame 的時候,B frame 會參照到錯誤的參考方塊,造成解出來 畫面出現一堆亂七八糟的方塊,如下圖: ![]() B-Frame(在 MPEG-4 裡面正確的名稱是 B-VOP)的預測模式有四種: a. Forward 順向預測,參考前一張畫面,記錄和前一張畫面的差距。 和 P-Frame 的預測方法一樣。 b. Backward 逆向預測,參考下一張畫面,記錄和下一張畫面的的差距。 c. Bi-Directionally 雙向預測,參考前面和後面兩張畫面,記錄的是 和「前後兩張畫面的平均值」的差距。也叫做內插預測,壓縮率最高。 d. Direct Mode,不搜尋、紀錄動作向量,直接由下一張的 P Frame 推導出動作向量。譬如說 IBP,我們可以預測 B 畫面的動作必然 是介於 I 和 P 兩個畫面之間,所以我們可以偷懶不計算 B 的 MV, 直接用 P 的 MV/2 作為 B 的動作向量,這樣可以省去記錄 MV 的空間。 壓縮 B-Frame 的時候會從上面幾種預測模式中選壓出來最小的一個模式來使用。 而現在 XviD 的 bug 就是,當 B-Frame 可以有 Backward MV 指向下一張畫面, 而那一張畫面是 I-Frame 的時候就會造成解碼錯誤。 我沒有分析 bitstream,不過從錯誤的畫面看來,這張 B-Frame 的下一張畫面是 Scene Change 的地方,照理說壓出來會最小的預測模式應該是 Forward 預測, 只參考前一張 P-Frame 壓縮。 但是解出來的畫面卻明顯的是參照下一張 I Frame 解出來結果。 請看上一張錯誤解碼畫面的下一張 I Frame: ![]() 可以看出上一張錯誤解碼的畫面是參照到這張 I Frame 來解碼的, 但是真正的 MV 應該是指向前一張 P Frame: ![]() 記錄的差距值也是和前一張 P Frame 的差距,拿 I Frame 的相對位置來解碼, 當然會解出錯誤的畫面。 比對錯誤的 B 畫面和前一張 P 畫面,可以發現 B 畫面上沒有亂掉的部分, 是因為: 1) 該區域和前一張畫面差不多相同,所以被 skip 掉沒有壓縮, 解壓縮時直接重送上一個方塊。 2) 該區域和前一張畫面差很多,所以是以 intra-block 壓縮(獨立壓縮, I-Frame 的壓縮方式),沒有 MV,沒有參照其他畫面,所以沒有解錯。 正確解碼出來的畫面應該是: ![]() 我猜想會造成這個錯誤解碼的原因是,如果允許 B-Frame 參照下一張 I, 解碼解到 畫面順序: PBI 壓縮順序: PIB decoder 會先解出 I,然後解碼 B,本來 B 應該參照前一個 P 解碼, 但是不知道為什麼現在 B 參照的是 I 來解碼,所以造成了這種錯誤。 嗚哇,越寫越長 ^^;; 總之目前解決的辦法是把「使用相容 DX50 的 B-VOP」的選項勾起來,禁止 B-Frame 能夠參照下一張 I-Frame,就樣就不會發生這個問題了。 這個 bug 已經回報,應該會在一下版的 XviD 修正。 11. DivX 5.x 的 解碼器可以解碼 XviD 壓出來的 B-Frame,即使連續 B-Frame 的個數超過 1。(不過 DivX 5.x 的 encoder 自己壓的 B-Frame,只能 1 個, 只能為 IBPBPBPBPB.... 這種型態) 12. DivX 5.x 的 解碼器可以解碼使用 MPEG 量化方式壓縮的 XviD 檔案, 同時也可以解碼使用者自行定義的 MPEG 量化矩陣。(雖然 DivX 5.x 自己的 encoder,只能壓縮 H.263 量化方法的檔案) 13. DivX 5.x 的解碼器畫面修飾得比較漂亮,同時 CPU 使用率比現在的 XviD decoder 少很多,現在的 XviD decoder 解碼負擔實在太重了。 (加上 Qpel,負擔更重,沒有 1G 以上恐怕跑不順) 繼續測試中... |
![]() |
![]() |
Major Member
![]() 加入日期: Nov 2001
文章: 100
|
真是寶貴的經驗,實在是非常感謝啊!
小弟剛從DIVX轉到XVID的領域,轉了�**穭痐k,但是檔案大小實在是難以控制。 希望有其他高手能夠多多討論XIVD的應用技術,小弟引頸期盼。 |
![]() |
![]() |
Advance Member
![]() ![]() 加入日期: Nov 2001 您的住址: 台中市
文章: 480
|
基本上我覺得Xvid比Divx容易控制容量,我多半是使用2pass時Desired Size來設定,只要再加上聲音資料,就可得出很接近的成品大小。相反的,我反到覺得Divx雖然手動設定流量,但成品流量多半偏差該值許多。
另外,Nic's 的10/21,10/23兩個版本我在使用上始終有點問題,安裝了之後,在播放以前的Xvid檔案時,開頭會出現一片綠色,而在壓縮時,如果不將Maximum B-Frames設成-1(也就是不使用B-Frame),使用Aviutl一開始壓馬上程式關閉,兩個版本都會這樣,而我又不喜歡使用VD…所以我現在還是使用koepi's 09/04的版本,而此版本我並不清楚Motion search prcision設成6有無Qpel的作用,不過在此設定下,畫質確實比5時略好一點。 |
![]() |
![]() |
Senior Member
![]() ![]() ![]() 加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
Koepi 10/04 的版本沒有 QPel 的功能。 QPel 是 Isibaar 10/05 加進去的。 您用的 AviUtl 的版本是? 我用 96b 版沒有問題,您試試看。 |
|
![]() |
![]() |
Senior Member
![]() ![]() ![]() 加入日期: Oct 2002 您的住址: El's room
文章: 1,046
|
引用:
抱歉打錯了,是 98b 版,不是 96b。 96 系列用太久,一時改不過來 :P |
|
![]() |
![]() |
Advance Member
![]() ![]() 加入日期: Nov 2001 您的住址: 台中市
文章: 480
|
98b,98d都試過了,程式還是會關閉,大概是我codec灌太多了,懶得花太多心思,kopei's的版本還是加減著用吧,不過還是感謝建議。
|
![]() |
![]() |
Elite Member
![]() ![]() ![]() ![]() ![]() 加入日期: Mar 2001 您的住址: Rivia
文章: 7,035
|
請問不同版的xivd可以同時存在電腦中嗎??
![]() ![]()
__________________
Folding@home with GPGPU集中討論串 Unix Review: ArchLinux●Sabayon●OpenSolaris 2008.5●Ubuntu 8.10 AVs Review: GDTC●AntiVir SS●ESS●KIS 09●NIS 09●Norton 360 V3 ![]() I Always Get What I Want. |
![]() |
![]() |
*停權中*
加入日期: Aug 2000 您的住址: North Taiwan
文章: 1,500
|
我是用Last developement(24062003-1)...
雖然是unstable version, 可是衝著Fixed P4 issues....只好衝了 ![]() 昨天用snic大簡易教學法壓了一片CIA追緝令, 看了一遍成品沒什麼問題 檔案大小的話我也是用2pass的desired size指定(兩片CD-R ![]() 目前還在摸索怎麼分割檔案跟轉成文字檔.sub Q_Q |
![]() |
![]() |