總體來說，從壓縮效率的角度上，VP8比H.264差很多。在上面提到的主要弱點在於缺乏合適的自適應量化算法，缺乏B幀，缺乏8×8變換以及非自適應的環內濾波器。從這點上考慮，我預計VP8應該和VC-1或者H.264的basline profile有的壹拼，而不是H.264。當然，VP8比起Theora來還是好了不少，並且在我的測試中它也能輕松擊敗Dirac。
假如Google能開放改善碼流格式的許可 – 即是這個與如此多的公司宣布支持VP8這個事實相悖。越多的軟件支持某壹種文件格式，這種文件格式能改變的難度就越大，所以我比較懷疑任何生成我們將再花6-12個月的時間來修正VP8的聲明。簡而言之，VP8的發布太早了：合理的安排應該是先有壹個測試階段，在這個過程中對測試版進行修正，當其完成後，再正式發布。
更新：看上去Google是開放任何修改標準的可能性：這顯然說明標準是最終版本了，壹個充滿著各種漏洞的完成品。
從解碼速度的角度來說我不是非常確定，現在的實現看上去比ffmpeg的H.264解碼器慢大約16%（也就是說可能比現在最先進的解碼器比如CoreAVC慢25-35%）。當然，這並不能構成對完全優化的實現的速度如何的決定證據，但是這個實現看上去已經做了非常好的優化並且還有對幾乎所有主要數字信號處理函數的SIMD匯編代碼，所以我實在懷疑它還能再有很大的進步。
可以預料的是，在同等優化程度的實現下，VP8和H.264應該有大約壹樣的解碼速度。這對於VP8來說著實不是壹個優勢：因為H.264已經有了非常多的硬件支持，但反觀VP8，卻基本需要依靠軟件解碼，所以這種“大約壹樣的速度”在很多情況下並不夠。相比之下，Theora比ffmpeg的H.264解碼器快接近35%。
最後，專利的問題看上去再壹次的會成為壹個令人頭疼的問題。VP8實在是太像H.264了：壹個對VP8精辟，但有些許不準確的形容就是“H.264的baseline加上更好的熵編碼算法”。雖然我不是壹名律師，但我很自然的沒法想象他們能避開這點，特別是在當前這種過度偏好專利訴訟的環境下。甚至是VC-1這種相比於VP8和H.264還有更多不同的標準，也沒法逃脫軟件專利的陰雲。
在我們得到確鑿證據表明VP8是（專利）安全的之前，我會特別謹慎的。因為Google自己都沒有給VP8的用戶任何免於被專利訴訟的保護和相應的賠償機制，這就會是壹個更嚴重的暗礁了。最重要的是，Google自己也沒用發布任何關於為什麽VP8的各個部分沒有破壞其它專利的正當理由，就像Sun曾經為他的OMS標準所做的壹樣：這樣的信息能確實地減少使用者的顧慮，並且更明確地說明他們所處的位置。
但無論怎麽說，如果Google足夠幸運的讓VP8免於了所有可能的專利挑戰，VP8相比於Theora，毫無疑問顯然是壹次重大的升級。
補篇A：On2的VP8編碼器和解碼器
雖然這篇文章的重點在與討論VP8這種視頻格式的相關問題，但從實際使用的角度，軟件的重寫和改進，以及對那些在準備嘗試VP8的人來說，正式發布的VP8編碼器和解碼器的質量（從代碼角度、壓縮率角度和速度角度）比我上面說的那些都更重要。因此，在閱讀完VP8的大部分代碼之後，以下是我對軟件的壹點感想。
最開始我本打算在這點上放過On2，我認為這個編碼器對於VP8從道理上說是新事物所以呢他們也許沒有必要將它寫的特別高質量或者改善其中的算法。但是，當我開始讀這個編碼器時，以上的善意完全站不住腳跟了：有壹些註釋表明某些bug的修復時間可以追溯到2004年早期。好吧，這個編碼器甚至比x264還老！我猜測現階段VP8的軟件只是簡單的從原VP7的軟件中進化而來。無論怎麽說，這就意味著我不能饒恕On2了，他們至少有6年的時間研發VP8，並且投入了比x264大得多的研發團隊。
在我把編碼器分解說明之前，需要銘記在心的是VP8的這個標準軟件並不糟糕。實際上，從壓縮率的角度來說，我不認為使用標準方法還能讓它更進壹步。我猜測他們的編碼器，在最慢的參數下，能跑出他們能獲得的最大PSNR偏差5%-10%範圍內的成績。顯然的是如果用類似MB-tree這樣的古怪算法，改善的余地還有不少，更不要說它根本沒有任何的視覺心理優化了。但是這份標準編碼器確實盡職盡責的做好了自己的分內。這和VP3的那個猶如垃圾堆般的標準編碼器（去問問任何壹個Theora的開發者吧）有著鮮明反差。
在我進入具體的技術細節前（ds妳就屁話多），我來對代碼質量做壹點評價。雖然在註釋裏有數以噸計的書寫錯誤，相比於VP3來說這份軟件的代碼質量要好了很多。他們也看上去開始用註釋的方式來實現版本控制系統，這確實很奇怪。匯編代碼則要糟糕很多，令人難以想象的大量復制粘貼式編程，壹些完全無用沒有做任何事的指令，沒有對齊的load/store操作理應對齊的數據結構，和些許用無論如何就是看不懂的繁復的並且更慢的方法寫出來的函數。如果說C代碼還只是毀譽參半的話，匯編的書寫質量就很明確地是個腦殘紗布了。
ME：Diamond，hex和全範圍搜索。所有的方式都是很簡單的實現：比如hexagon搜索，就有令人難以想象的壹堆冗余代碼（幾乎半數搜索位置都重復了）。全範圍搜索從效率來說就更差了，但是考慮到除了在非常極端慢的編碼設置下它都是無用的，我就不對它吐槽了。
小數精度的子像素ME：簡單明了的叠代diamond和square搜索算法。此處沒有任何特別感興趣的地方。
量化：量化部分主要包含兩種模式，壹個快速模式和壹個稍微慢壹些的模式。前者基本等同於x264裏的deadzone quantization，後者在前者的基礎上加入了壹個基於0遊程的偏置權重。（我不是很明確這個的作用有多大，但我很喜歡這種方法）。在這之後，他們進行了兩種“系數優化”。第壹種僅僅是嘗試將每個非零系數向零移動；更慢的壹個模式嘗試所有***2^16次種可能的DCT系數舍入組合。無論是誰寫的這些，他都需要好好拜讀下trellis量化（這個問題的動態規劃解法）是什麽，而且絕對不要在編碼器中寫入這種指數時間復雜度的算法了。
RC（幀類型處理）：為了提升（boosting）質量，VP8引入了“golden frames”和“altref frames” – 這是兩個我抱有很大疑問的理念，因為這意味著視頻有可能周期性的跳到壹個更高的質量水平，而這種現象的出現在實際場合是非常糟糕的。從PSNR圖中（請參照原文鏈接）妳也能看到這個理念帶來的影響：約每12幀左右，質量就會有壹次跳動。將這種跳動結合在連續觀看的視頻中不可能帶來很好的主觀質量評價的。
RC（總論）：碼率控制完全依賴於反饋式的算法，在某些嚴格恒定碼率和嚴格的緩沖限制場合這種算法也許得不到很好的性能。此外，在幀內RC算法沒有任何關於量化器的自適應機制（比如當本幀超過了容量限制時RC如何控制它）。取而代之的是，RC依賴於重復編碼某壹幀來使它達到目標大小，這就導致了在實際使用場合這種控制方式使毫無作用的。原因有二。在低延遲場合，也就是當平臺無法接受高延遲的場合，重復編碼多次可能會使編碼器接收到的幀在時間上無法同步。在其他的任何場合，只要平臺能接受使用基於幀的多線程處理（帶來的延遲），這種比傳統基於slice的多線程處理快的多的多線程編碼算法就會讓重復編碼變得無法實現。
環內濾波器：編碼器的環內濾波器參數選擇是根據最大化PSNR來優化的。我不敢確定這種想法的是否優秀，但是我敢確定的是每個嘗試用這種方法優化H.264的人最後的結局都是產生了主觀質量特別糟糕（常常是非常模糊的）的輸出效果。
總體性能：即使是開啟了多線程並使用了絕對最快的設置，他們的編碼器還是速度低下。在我1.6G的Core i7平臺下他們編碼1080p的速度在26fps左右，這個速度甚至都別提足夠實時壓縮了。與之相比x264在使用它最快的“ultrafast”預設參數時能跑到101fps。我基本可以確定的表示，On2的VP8編碼器從任何意義上來說都不會比x264更快，但是在壹個現代四核的平臺下無法生成高清流媒體，這在2010年實在是讓人無法理解。此外，編碼器中速度的選項極其腦殘並且不直觀，而且似乎永遠都無法正常的工作；比如，快速編碼模式（-rt）似乎在2-pass下被完全無視了。
總體壓縮性能：與之前提到的類似，從壓縮率的角度來衡量這個編碼器在給定的標準範圍內的確做的很出色。編碼器中最慢的算法設置很顯然是完全沒有經過優化的（特別是看看他們在運動搜索和量化部分留下的註釋吧），但是至少他們還能工作。