Google 也發布了 VP8 編碼的實做庫：libvpx，以BSD授權條款的方式發布，隨後也附加了專利使用權。而在經過一些爭論之後，最終 VP8 的授權確認為一個開放原始碼授權。
基本介紹
- 外文名：VP8
- 類型：開放的圖像壓縮格式
- 開發公司：On2 Technologiesis
- 發布公司：Google
簡介,突破創新,技術分析,預測,幀內,幀間,變換量化,變換,量化,熵編碼,濾波器,總評,
簡介
視頻壓縮解決方案廠商On2 Technologies公司現已推出最新的視頻壓縮格式On2 VP8。On2 VP8是第八代的On2視頻，能以更少的數據提供更高質量的視頻，而且只需較小的處理能力即可播放視頻，為致力於實現產品及服務差異化的網路電視、IPTV和視頻會議公司提供理想的解決方案。
對更高效視頻壓縮格式的需求顯著
雖然數據傳輸速度在不斷提高，但頻寬的成本和可用性仍將是控制實施成本的主要障礙，因為視頻服務使用的頻寬比任何其它IP套用都要大。根據思科公司 (Cisco) 出版的白皮書顯示，2012年，IP流量將超過半個皆位元組 (zettabyte, ZB)，其中視頻占所有消費套用流量的近90%。2012年，單是網際網路視頻預計每月就產生10艾位元組(exabyte, EB) 的數據。
突破創新
On2 VP8加入了40多項的創新技術，在壓縮效率和性能方面超越了市面上的所有其他視頻格式。這些創新技術包括：
* 基於虛擬參考禎的高級預計編碼
* 改進的局域參考編碼
* 增加複雜度的先進上下文熵編碼
* 稀疏目標區域的自適應迴路濾波
隨著On2 VP8的推出，On2 視頻現已大幅超越所有其它商用格式的壓縮性能。例如，主要的H.264實現方案需要兩倍的數據才能提供與On2 VP8相同質量的視頻 (基於客觀峰值信噪比 (PSNR) 測試結果)。
此外，On2 VP8比特流的解碼只需要極少的處理周期，故用戶無需擁有最新、最高級的PC機或移動設備也能夠享受到On2 VP8的視頻質量。
技術分析
在這裡我嘗試回答的問題是這些：
1. VP8有多好？ 從壓縮的角度說這種檔案格式能比H.264更好嗎？以及一個優秀的VP8編碼器能擊敗x264嗎？On2聲稱VP8比H.264好50%，但是On2經常說出這種他們自己都無法提供有效證據的荒謬聲明，所以這樣一個數字幾乎可以斷定是不正確的。比如說VP7，曾被認為比H.264好15%並且快很多，但事實是它既沒有H.264質量好也沒有它快。
2. On2的VP8實現怎么樣？和標準本身多好無關，這是說具體實現是否優秀，或者說On2的VP8實現會和VP3一樣，發布了一個根本無法使用的糟糕實現，將希望寄託於開發者團體去修正他們。讓我們祈求VP8不要這樣吧，Theora的修補花了6年啊！
我們從VP8的核心特性展開分析。我們主要通過和現存視頻格式的比較來分析。謹記在心的是編碼器和標準是兩碼事，完全有可能一個優秀的編碼器是建立在一個糟糕的標準之上的，反之亦然。這就是為什麼一個非常優秀的MPEG-1編碼器能擊敗一個慘不忍睹的H.264編碼器。
編碼器：預測->變換+量化->熵編碼->除塊濾波
解碼器：熵解碼->預測->反量化+反變換->除塊濾波
預測
預測是指任何用於猜測幀內某一區域內容的嘗試。 這可能包括基於本幀已知像素預測而來（這種方法叫修復inpainting），或者通過前某幀運動補償（Motion compensation）而來。預測通常包含著一些附加信息，比如用於告知解碼器運動矢量（motion vector）的信號就在運動補償這種預測中使用。
幀內
幀內預測是當不需要其它幀參考時猜測某一塊使用的方法。VP8的幀內預測基本上是從H.264標準照搬過來的：子塊（subblock）預測模式基本上和H.264的i4×4模式完全一致；並且，整塊預測模式和i16×16模式一致。色度的預測模式從經驗上說也和H.264一樣。H.264 High profile中定義的i8×8模式沒有出現在VP8中。另一個區別在於H.264的平面預測模式在VP8中被替換成了TM_PRED，這是一個非常含糊的近似模擬。就特定的預測模式而言，VP8和H.264有細微的差別，但是他們都和H.264有著一樣的名字。
老實說，我對這點很失望。當然，H.264的幀內預測是優秀的，但顯而易見在過去的7年幀內預測這種技術也改進了不少，並且我認為粗俗的照抄是像Real（見RV40）這種公司守備範圍內的事。我曾熱切的期望On2能弄出些哪怕是只有一點創造性的東西出來。但另一個比這些都重要的問題的是，H.264的空域幀內預測是被專利保護的，而且我不認為On2能僅用一些預測模式上的捨入變化就能逃離專利的魔爪。我希望看到Google能對此正名，他們必須提供一個很好的解釋，說明他們為什麼不會被捲入專利糾紛。
幀內預測模式的評價：對H.264稍作修改的照搬，也許比H.264更差，因為缺乏i8×8模式。
幀間
幀間預測是藉助於其它過往幀為參考猜測某一塊內容的方法。幀間預測一般而言由兩個主要部分組成：參考幀和運動矢量。參考幀是一用於複製像素到預測幀，並根據複製塊與當前處理塊的偏差形成運動矢量的過往幀。VP8支持最多3個參考幀：時間軸上的前一幀，“alt ref”幀和“golden frame”。就運動矢量而言，VP8支持和H.264很相近的可變大小宏塊分割方式。就子像素精度而言，VP8支持1/4像素精度運動矢量，使用的是6階插值濾波器。簡而言之：
VP8參考幀：最多3個
H.264參考幀：最多16個
VP8分割類型：16×16,16×8,8×16,8×8,4×4
H.264分割類型：16×16,16×8,8×16，可變子分割（每個8×8的塊可再被分割成8×8,8×4,4×8或者4×4）。
VP8色度MV的推算：每個4×4的色度塊的MV使用相同位置亮度MV的均值得到（與MPEG4-ASP相同）。
H.264色度MV的推算：色度塊的MV直接使用亮度塊的MV。
VP8插值濾波器：1/4像素，6階亮度，混合4/6階色度。
H.264插值濾波器：1/4像素，6階亮度（分層濾波器），雙線性色度
H.264有但VP8無：B幀，權重預測
H.264有著明顯優於VP8並自由度更高的參考幀結構。8×8子塊的再分割基本無用，所以VP8在此處的省略基本不會造成影響。色度MV的推算比H.264更準確，但比H.264稍慢。從實際使用上說，這個區別從速度和壓縮率來說都是近似於0的，因為8×8的亮度分塊是很少用到的，（並且我在此假定在VP8中也一樣）。
VP8的插值濾波器可能會比H.264稍好，但是肯定實現起來更慢，從解碼器和編碼器兩方來說。一個分層的濾波器允許編碼器能預計算所有可能的半像素位置的值並且當需要的時候能快速的計算出1/4像素位置的值，而一個非分層的濾波器則無法做到，這就將導致非整數像素運動估計的速度非常慢。並不是所有的非分層濾波器都是糟糕的 – 分層濾波器在所有的H.265提案中都對拋棄了 – 對VP8而言這只是一個從性能角度來說相比於H.264的內在劣勢。另外，在色度上使用高達6階的濾波器，在我看來，是完全沒必要和沒用的。
VP8缺少的B幀是一個致命缺陷。B幀能在非常小的速度損失下提高10-20%甚至更多的壓縮率，他們在VP8中的缺席可能會比這篇文章中提到的其它所有問題影響的壓縮率之和還要嚴重。但這並不是完全出乎意料的，On2從沒有在之前的任何一種視頻格式中使用B幀。並且他們可能會因為使用B幀導致嚴重的專利問題，即使On2看上去似乎在照搬其它被專利重重保護下的H.264特性時沒有任何問題。對權重預測的不支持也將在一定程度上影響壓縮率，特別是對漸變場景。
變換量化
在預測之後，編碼器將預測幀和實際幀的差值（殘差）送入變換和量化。變換是用解相關的方式使數據更易於壓縮。量化是一個實際損失信息的步驟，所謂的壓縮也就在此處實現：變換的輸出值會經過捨入，大部分參數都將變成0，只留下少數整數參數。
變換
對於變換來說，VP8再一次的使用了一個類H.264方案。每個16×16的宏塊被分成16個4×4的DCT塊，每一個使用一個精確位數的DCT近似進行變換。之後，每個變換塊的DC分量被提出成另一個4×4的組，之後對這個4×4的組進行Hadamard變換。OK，到此這不是一個類H.264方案，這就是H.264。但是，VP8的變換方案和H.264有三點不同。
第三個不同之處在於Hadamard層級變換還作用於一些幀間預測塊中，而不僅僅是i16×16這一種幀內預測模式。具體來說，它也作用與p16×16塊中。這是一個非常好的想法，特別是考慮到較小的變換大小（以及對於小範圍變換時解相關DC值的需求）。我並不是非常確定我同意將層級變換隻限定在p16×16塊內，看上去似乎只要經過很少的修改，這樣的變換也會對其他運動分塊有用。另外，與H.264不同的是，層級變換隻作用於亮度塊而不作用於色度塊。
總體上，VP8的變換方案絕對比H.264弱。缺乏8×8的變換，特別在高解析度場合，會嚴重影響對細節的保持。變換本身也非常沒有必要的慢，雖然基於位移的變換方案可能會逃過專利問題。其中一個優秀的想法是將層級DC變換套用到幀間預測塊中。
對變換的評價：接近於H.264，更慢，略微準確的4×4變換，對亮度DC變換的改進（但是沒有對色度的支持）。沒有8×8變換。總之，劣於H.264。
量化
對於量化而言，核心的處理方式對於所有類MPEG視頻格式都是一樣的，VP8也不例外。量化上各種不同標準區分自己的方法就是改變數化階係數。這裡面主要的方法又有兩種：基於幀的偏移，其作用於所有或者一部分係數；以及基於宏塊的偏移。VP8主要使用的是前者，其方案相比於H.264的自定義量化矩陣而言可伸縮性差了很多。VP8的方案允許分別調整亮度DC分量，亮度AC分量，色度DC分量等諸如此類的對應量化器。後者（基於宏塊的量化器選擇）從理論上可以利用“分割圖”的功能實現，儘管這種實現方式需要相當的技巧並且不是非常高效。
VP8在這裡犯得一個致命錯誤在於沒有把基於宏塊級別的量化作為VP8的核心特性支持。利用基於宏塊級別量化的算法一般被稱為“自適應量化”，這種量化對視頻主觀質量的影響是絕對非常關鍵的。我在x264里的基於方差的自適應量化算法實現，補丁。編碼器的評價一次又一次的證明，沒有自適應量化的編碼器完全沒法與具備的編碼器相提並論。
因此，想讓自適應量化在VP8上成為可能，對每個有可能被用到自適應的量化器定義一個分割圖並對每個宏塊的分割圖索引進行編碼就成了華山一條路。顯然這是很沒效率且很笨拙的實現方法，哪怕不是最優的MPEG風格delta量化器系統都是一個更好的選擇。此外，對於每幀最多4個量化器而言，VP8最多只支持4張分割圖。
熵編碼
當然，算術編碼並不是熵編碼的唯一部分：一個算術編碼器僅僅是把0和1轉換成輸出的碼流。而生成這些0和1的過程和為編碼器選擇適合的機率值使用是同等有趣的問題。因為這是視頻標準中非常複雜的一個部分，我在此僅對我覺得特別值得提出的部分做一些評論。
運動矢量編碼包含兩部分：根據相鄰運動矢量來預測以及壓縮預測值與實際值之間的差值。VP8的預測方案顯得有點奇怪，更糟糕的是，標準中對這部分沒有任何英語解釋，只有寫的很讓人摸不著頭腦的C代碼。我只能根據我對它的理解來說明了：VP8根據相鄰運動矢量來選擇算術編碼語境（context），然後決定選擇哪個預測運動矢量，或者決定是否編碼矢量的差值。
此方案的問題在於，和VP3/Theora類似（雖然不是一樣糟糕），它嚴重傾向於重複使用過去的運動矢量。這是非常危險的因為，就像Theora的開發者發現的一樣（在最今的Theora 1.2得到了一部分解決），任何編碼器因為節省碼率而選擇了一個並不是“真正”的運動矢量的行為都有劣化主觀質量的可能後果。從最基本的效率來說，在這我不敢確定VP8和H.264何者更好。
壓縮差值的方法和H.264接近，除了當編碼非常大差值時VP8會稍優於H.264（類似於FFV1的類哥倫布算術編碼）。
幀間預測模式的編碼使用基於臨近塊的模式作為算術編碼的語境。這或許比H.264使用的過時的方法要好。在這點上，H.264的糟糕設計一直讓我很驚詫。
殘差編碼比運動矢量的編碼更難理解，因為只有一堆高度最佳化、高度模糊的C代碼作為參考。和H.264的CAVLC一樣，它基於當前塊的左側以及上部塊非零係數的個數作為語境。此外，它考慮了這些非零參數的數值，並且和H.264的CABAC一樣，會根據已解碼的係數更新語境。
另一件值得一提的事是VP8使用的數據分割方案。此方案與VP3/Theora的實現非常相近，包括將每個語法元素放入碼流中其自己的部分中。這個問題的不幸之處在於這種方式非常難在硬體上實現，它極大地增加了記憶體頻寬的需求。我已經從一個硬體開發者那聽到了關於VP8這部分特性的抱怨。
對熵編碼的評價：我對此不是特別確定，可能在某些方面更好，可能在其他方面更糟，在剩下的部分或許只是奇怪。根據我的預感，VP8或許在這方面會比H.264略微勝出；非自適應的算術編碼顯然會帶來一些嚴重的性能影響。VP8也可能同時會有硬體實現的問題。
濾波器
對環內除塊濾波的評價：從壓縮率的角度，因為缺少自適應強度機制而顯然的比H.264差，特別是使用“快速”模式時，雖然可能會大幅提高編解碼速度。我擔心的是這種濾波的結果是過度的模糊了畫面。
總評
總體來說，從壓縮效率的角度上，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搜尋，就有令人難以想像的一堆冗餘代碼（幾乎半數搜尋位置都重複了）。全範圍搜尋從效率來說就更差了，但是考慮到除了在非常極端慢的編碼設定下它都是無用的，我就不對它吐槽了。
量化：量化部分主要包含兩種模式，一個快速模式和一個稍微慢一些的模式。前者基本等同於x264里的deadzone quantization，後者在前者的基礎上加入了一個基於0遊程的偏置權重。（我不是很明確這個的作用有多大，但我很喜歡這種方法）。在這之後，他們進行了兩種“係數最佳化”。第一種僅僅是嘗試將每個非零係數向零移動；更慢的一個模式嘗試所有共2^16次種可能的DCT係數捨入組合。無論是誰寫的這些，他都需要好好拜讀下trellis量化（這個問題的動態規劃解法）是什麼，而且絕對不要在編碼器中寫入這種指數時間複雜度的算法了。
環內濾波器：編碼器的環內濾波器參數選擇是根據最大化PSNR來最佳化的。我不敢確定這種想法的是否優秀，但是我敢確定的是每個嘗試用這種方法最佳化H.264的人最後的結局都是產生了主觀質量特別糟糕（常常是非常模糊的）的輸出效果。
總體性能：即使是開啟了多執行緒並使用了絕對最快的設定，他們的編碼器還是速度低下。在我1.6G的Core i7平台下他們編碼1080p的速度在26fps左右，這個速度甚至都別提足夠實時壓縮了。與之相比x264在使用它最快的“ultrafast”預設參數時能跑到101fps。我基本可以確定的表示，On2的VP8編碼器從任何意義上來說都不會比x264更快，但是在一個現代四核的平台下無法生成高清流媒體，這在2010年實在是讓人無法理解。此外，編碼器中速度的選項極其腦殘並且不直觀，而且似乎永遠都無法正常的工作；比如，快速編碼模式（-rt）似乎在2-pass下被完全無視了。
總體壓縮性能：與之前提到的類似，從壓縮率的角度來衡量這個編碼器在給定的標準範圍內的確做的很出色。編碼器中最慢的算法設定很顯然是完全沒有經過最佳化的（特別是看看他們在運動搜尋和量化部分留下的注釋吧），但是至少他們還能工作。
