目前有三個團體在編譯 XviD
http://nic.dnsalias.com/
這個個人認為最優

http://www.roeder.goe.net/~koepi/index.shtml
個人認為這個最穩

http://xvid.hopto.org/
這個.............. 7月以後的版本似乎已經脫離的規範，個人曾拿到用這
版本所壓的 AVI 在以上兩個團體所編譯的 XVID 無法正確解碼，僅能用
此團體編譯的方能正確解碼成功~~

以上僅供參考，還望有高手能再指教~~

經過個人實際去比較的結果, DivX 5 的 B-VOP + QPel 是錯誤的, 跟 standard 上的不依樣, 他的 B-VOP 的押法也很奇怪, 解出來的 frame 數不太對. XviD 現在還是卡在 B-VOP 跟 Qpel, 先前 CODE 裡的 Q-pel 的壓縮跟解壓縮的做法都是錯的, B-VOP 的話 memory buffer 的處理有問題, 常會掛點...

若想轉換其實可以去抓那個 ffdshow, 他裡面用的 library 可以解 Divx 3, 4, 5 跟 Xvid 押出來的東西, 裡面有個 directshow wrapper 可以把 Divx 4,5的東西丟給 XviD VfW DLL 來解, 也就是用 XviD 來解碼... 不過有些個東西還是會解錯 (B-VOP 跟 Q-pel XviD 還沒正確 implement... )

所以基本上還是用 XviD 好了. :p DivX 的東西是偷來的, 押起來效果也沒有比 XviD 好... 而且還寫錯 CODE, 像我們這種作 chip 的就搞不清楚該跟哪邊走... -_- 作 standard 的沒有人完全做對 (MPEG-4 ASP), 做 DivX 的又跟 standard 的不依樣... 傷腦筋... 只能期待 M4IF 提出的規範大家能遵守了... M$ 還是走他的 H.264/JVT 的路就是了... :(

因為 standard 太複雜，所以似乎沒人搞得清楚 :P
那麼 FFMPEG 的 Qpel 的作法是對的囉？（之前搞不清楚到底是 XviD 做錯還是 FFMPEG 做錯）
再請問 xcape 兄，H.264 不是明年二月（還是五月）就要被 ISO 標準化成為 MPEG-4 part.10？
到時候市場上會不會一片混亂 :P
其實我覺得如果 H.264 真的有那麼強（目前的 test model 看起來不錯，的確有到它所宣稱的比 MPEG-4 part.2 多 50% 的壓縮率），那麼大家改用 H.264 也不錯啊 :)

Qpel 在 B-VOP 裡的做法有分兩種, 一種是 8x8 padding, 一種是 16x16 padding. 上週在 XviD developer mailing list 我有提出這個問題, 因為Ｄｉｖｘ兩種都用 8x8 做 padding 所以若真兆 standard 來做, Divx 押的東西解出來是錯的, 一格一格的相當難看... Mumosys 跟 MS 的 reference code 裡明明兩個是不依樣的, 但是到了Divx 卻變成兩個都依樣的, 這就很奇怪了... XviD 的人也發覺了這個問題, 所以應該有想要解決吧, 要不要提醒 Divx 的人改? 這我就不清楚了... :p 此外, XviD 的 CODE 裡 Qpel 的解法很多地方都有 typing error, 雖然後來的 CVS 版本有更改過, 不過也是錯的 -_- bug report 我也有 MAIL 給他們, 應該這陣子出來的會改掉這些問題吧...

ISO/IEC 跟 ITU-T 這個結合是因為兩邊的 chairman 是 M$ 的同一個人, 變成了 JVT (Joint Video T???, 忘了:p), 複雜度增加許多, 8-pel, 很多種 block size, fixed-point DCT/iDCT 等等, 可能的因應方式大概也只能用 RISC 或 DSP 硬幹, 做成 H/W core 可能相當複雜. 這還在觀望... 目前大家都推 MPEG4 ASP, 但是 GMC 好像沒人 implement, Divx 的算最完整但是有錯, XviD 的少 GMC, Q-pel 跟 B-vop, interlaced, 基本上只能算是 SP; sigma design 不老實沒放出 interlaced 的 code, 也少 GMC, B, Q-pel; Philips 的傳說是完整的, 但沒有 source code 可以看, 這個還要確定... 還有幾間比較小間的, 傷腦筋... 不過 M4IF 前幾週開始交換 bitstream 測試, 台灣這邊有單位參加, 希望再過一兩週情勢會明朗下來... :)

那麼這位 xcape 就真的是那位 xcape 了（好奇怪的說法）:P
CS 的 ME 演算法 ;)
小弟再請問一個問題，為什麼 Direct mode 的內插補點（8x8）和其他預測模式的內插補點（16x16）要設計成不一樣？有什麼特別的原因嗎？
話說回來，貴公司要做 MPEG-4 ASP 的 chip？！

引用:

ISO/IEC 跟 ITU-T 這個結合是因為兩邊的 chairman 是 M$ 的同一個人, 變成了 JVT (Joint Video T???, 忘了:p), 複雜度增加許多, 8-pel, 很多種 block size, fixed-point DCT/iDCT 等等, 可能的因應方式大概也只能用 RISC 或 DSP 硬幹, 做成 H/W core 可能相當複雜. 這還在觀望... 目前大家都推 MPEG4 ASP, 但是 GMC 好像沒人 implement, Divx 的算最完整但是有錯, XviD 的少 GMC, Q-pel 跟 B-vop, interlaced, 基本上只能算是 SP; sigma design 不老實沒放出 interlaced 的 code, 也少 GMC, B, Q-pel; Philips 的傳說是完整的, 但沒有 source code 可以看, 這個還要確定... 還有幾間比較小間的, 傷腦筋... 不過 M4IF 前幾週開始交換 bitstream 測試, 台灣這邊有單位參加, 希望再過一兩週情勢會明朗下來... :)

XviD 已經支援了 interlaced 不是嗎？記得那時 XviD 的開發人員還在問什麼是 alternate scan... ^^;;
H.264 複雜度實在太高了，我用 JM 4.2 壓縮，沒用 1/8 pel，壓一部影片大概要花一個月 -_-;;
將來程式碼最佳化以後應該會快一點 ^^;;

:) 在這裡討論這些好像不是很適合, 不過國內好像也沒有其他地方可以討論這些... :p 看來您也有 K 過 standard... :)
為啥會用 8x8 & 16x16 老實說我也不清楚, 但是基本上我們是認為 standard 寫錯了, 通通用 8x8 才比較 make sense. 單獨拉出幾個用 16x16 的實在不太適合, 但又因為 B-VOP 除了 direct mode 以外, MV 是以 MB 為單位, 所以用 16x16 好像又有點道理... so... 這也只是我們的假設而已... :p
"傳說"要做 MPEG-4 Chip 的台灣廠商很多了, 大家都還在努力當中就是了... 希望可以早點把這市場打下來... 不過越做會越發覺很無奈, 台灣沒辦法參加國際組織, 一切都必須走別人的路... 這已經不是單純幾個努力工作的工程師可以扭轉的來的... :p


XviD 已經支援了 interlaced 不是嗎？記得那時 XviD 的開發人員還在問什麼是 alternate scan... ^^;;
H.264 複雜度實在太高了，我用 JM 4.2 壓縮，沒用 1/8 pel，壓一部影片大概要花一個月 -_-;;
將來程式碼最佳化以後應該會快一點 ^^;; [/QUOTE]

interlace 也沒有想像中的複雜, 但是目前大家都是 progressive 的了, 還有誰會享用 interlaced?? 當初好像是因為 RCA 那些電視廠商的堅持才把他加進去了, 要不然 MPEG-4 本身要到很高的 Profile 才會 support interlaced 的...

沒試過 H.264, 但對 H.263++ 的效果相當滿意. 還在唸書時出國開會遇到幾個老中, 就是在搞 standard 的. 當時看他們的 demo 看的目瞪口呆... 昨天到一個 MIT 的朋友實驗室拜訪 (我現人在美國麻州), 他們老早就把 H.264 的東西 implement 出來了, 但是 computation load 真的相當高, 畫質的確不錯. 不過要真正出來可能還得等一段日子... 出來該跟誰隊打?? MPEG4?? H.263?? 這個還有很多疑問...

或許有些事可以私下討論, my email: :)

請問XviD可以用MEDIA PLAYER播放嗎？

最近XviD好像怪怪的

哇∼！
變成工程師研討大會了，完全霧煞煞...:p

因為功課的關係，之前有唸過一點，剛好又看到您 post 的問題，沒想到會在這裡遇到本尊，所以趕快把握機會問一下 :P

引用:

為啥會用 8x8 & 16x16 老實說我也不清楚, 但是基本上我們是認為 standard 寫錯了, 通通用 8x8 才比較 make sense. 單獨拉出幾個用 16x16 的實在不太適合, 但又因為 B-VOP 除了 direct mode 以外, MV 是以 MB 為單位, 所以用 16x16 好像又有點道理... so... 這也只是我們的假設而已... :p

喔喔，原來如此，之前一直覺得很怪為什麼要分成兩種，原來是 standard 寫錯了 -_-;;
既然 standard 這麼寫，雖然很怪還是得繼續 follow 下去 :(
謝謝您的回答 :)

引用:

"傳說"要做 MPEG-4 Chip 的台灣廠商很多了, 大家都還在努力當中就是了... 希望可以早點把這市場打下來... 不過越做會越發覺很無奈, 台灣沒辦法參加國際組織, 一切都必須走別人的路... 這已經不是單純幾個努力工作的工程師可以扭轉的來的... :p interlace 也沒有想像中的複雜, 但是目前大家都是 progressive 的了, 還有誰會享用 interlaced?? 當初好像是因為 RCA 那些電視廠商的堅持才把他加進去了, 要不然 MPEG-4 本身要到很高的 Profile 才會 support interlaced 的... 沒試過 H.264, 但對 H.263++ 的效果相當滿意. 還在唸書時出國開會遇到幾個老中, 就是在搞 standard 的. 當時看他們的 demo 看的目瞪口呆... 昨天到一個 MIT 的朋友實驗室拜訪 (我現人在美國麻州), 他們老早就把 H.264 的東西 implement 出來了, 但是 computation load 真的相當高, 畫質的確不錯. 不過要真正出來可能還得等一段日子... 出來該跟誰隊打?? MPEG4?? H.263?? 這個還有很多疑問... 或許有些事可以私下討論, my email: :)

根據測試 H.264 比 H.263++ 強很多（好像是廢話 ^^;），同流量下 Y-PSNR 平均高差不多 2.5dB（32kbps QCIF 10fps），H.264 只需要 H.263++ 的 60% 的檔案大小，就可以達到同品質。
不過 H.263++ 的 Annex U 可以使用多個參考畫面來做預測，如果把記憶體加大，參考畫面加多，差距可以再拉近一點。
我猜這個功能對動畫壓縮應該特別有用，因為動畫重複相同的畫面特別多，儲存越多的參考畫面越有利。不過我沒真的試過 :P
謝謝您提供郵件位址，以後有問題就要麻煩您了 ^^;;

可以，如果你是下載 Koepi 編譯的版本，DirectShow Filter 需要另行下載，網頁上有，安裝以後就可以用 WMP 播放了。
最近的 XviD 提供的編譯版本是 CVS 的 dev3-api 這個 tree 底下的程式碼，這個 tree 的檔案是屬於「開發中」的版本，有許多新功能，但是也相對的不太穩定。
例如 Qpel（1/4 pixel MC），一開始程式碼有些地方打字打錯，內插補 1/2 pixel 的 6-tap low-pass filter 程式碼會造成記憶體違反錯誤...等等，不過現在已經改正了，你可以下載最新的版本回來試試，效果很不錯喔 :)