WebM VP8視頻壓縮格式的前世今生
隨著消費者需求與多媒體娛樂的大幅提升，上一代互聯(lián)網標準與視頻解決方案，已經無法滿足高速增長的高清 視頻傳輸要求，在此背景下，面向未來需求的下一代互聯(lián)網解決方案——HTML 5網絡開發(fā)標準與WebM VP8視頻壓縮格式應運而生。目前，HTML 5標準已廣為人知，本文，筆者將邀你全面了解WebM VP8視頻壓縮格式的前世今生。
開源開放 WebM VP8何方神圣？
WebM是一個由Google資助的項目，目標是構建一個開放的、免版權使用費的視頻文件格式。該視頻文件格式應能提供高質量的視頻壓縮以配合 HTML 5使用。WebM項目是一個使用BSD許可證的開源項目，它采用了On2 Technologies開發(fā)的VP8視頻編解碼器和Xiph.Org基金會開發(fā)的Vorbis音頻編解碼器（一種開源且無專利限制的音頻壓縮格式），其 使用的封裝格式則以Matroska（MKV）開源格式為基礎。
VP8，是On2 Technologies于2008年9月13日推出的、旨在取代其前任VP7的視頻編解碼器。VP8能以更少的數(shù)據(jù)提供更高質量的視頻，而且只需較小的 處理能力即可播放視頻，為致力于實現(xiàn)產品及服務差異化的網絡電視、IPTV和視頻會議提供理想的解決方案。今年2月，Google收購On2 Technologies，在5月舉行的Google I/O開發(fā)者大會，Google正式宣布將VP8以BSD許可證的形式開源，揭開了新一輪互聯(lián)網多媒體之爭的序幕。
技術領先 WebM VP8潛力無限
相對于目前的VC-1、H.264等視頻壓縮格式，WebM VP8具有明顯的技術提升，其加入了40多項創(chuàng)新技術，包括：基于虛擬參考禎的高級預計編碼、基于宏塊級的多線程技術、改進的局域參考編碼、增加復雜度的 先進上下文熵編碼、稀疏目標區(qū)域的自適應回路濾波等，從而能以更少的數(shù)據(jù)提供更高質量的視頻，例如：主要的H.264實現(xiàn)方案需要兩倍的數(shù)據(jù)才能提供與 WebM VP8相同質量的視頻 (基于客觀峰值信噪比測試結果)。
不同于需要收取專利授權費用的H.264標準，WebM VP8實現(xiàn)了完全的免費開源與授權開放，并且，經過Google持續(xù)性的技術優(yōu)化，其解碼速度與開發(fā)工具顯著增強，在壓縮效率和性能方面的表現(xiàn)較發(fā)布初期 顯著提升。同時，WebM VP8比特流的解碼只需要極少的處理周期，故用戶無需擁有高端的PC或移動設備也能夠享受到WebM VP8的視頻質量，此外，WebM VP8在ARM架構兼容性與多核處理器適用性方面也具有后發(fā)優(yōu)勢。
全面擴張 WebM VP8引領未來
與目前主流的視頻壓縮格式相比，谷歌WebM VP8視頻壓縮格式更加適合下一代Web開發(fā)標準（HTML 5）與移動互聯(lián)網設備（MID）的應用需求，至今已在全球范圍獲得廣泛推廣。一方面，Google Chrome、Microsoft IE9、Mozilla Firefox、Opera、Apple Safari等各大主流瀏覽器均高調支持HTML 5標準，而WebM VP8作為HTML 5標準的重要組成部分，也同樣得到了WebM項目其它四十多家出版商和計算機軟硬件供應商（包括AMD、NVIDIA等）的積極支持，這一免費開源、公開 授權的編碼器，有助于在互聯(lián)網業(yè)內建立一個統(tǒng)一的標準視頻編碼格式。
另一方面，WebM VP8已經成為FFmpeg項目組的一部分，可以在X86、ARM和PowerPC平臺運行，并可在Windows、Mac OS X、Linux等系統(tǒng)良好支持，此外，WebM VP8亦支持DirectShow，Windows Media Foundation，QuickTime和Gstreamer等編碼器，由于WebM VP8能以更少的數(shù)據(jù)提供更高質量的視頻，超過80%的YouTube日常視頻均已采用WebM VP8視頻壓縮格式，這一系列成果，標志著WebM VP8在硬件、系統(tǒng)、編碼、資源方面取得了全面突破，更加適應新一代MID/平板的發(fā)展趨勢。
深入了解VP8
部分翻譯：http://x264dev.multimedia.cx/?p=377
原文轉自：http://www.deleak.com/blog/
譯者：delectate
問題一：vp8到底怎么樣？
難道他真的比x264擁有更高的壓縮比率，是個優(yōu)秀的編碼器嗎？他真的比h264優(yōu)秀嗎？似乎On2自己都羞于承認…拿vp7舉例，On2宣稱 vp7比h264快15%，但事實是編碼視頻速度既不快，視頻質量也不高。On2曾經把vp3開源，似乎想借助社區(qū)的力量debug，最終theora上 當……他們花了6年時間，結果做出來的還是個雞肋……
問題二：vp8真的沒有專利問題嗎？
這個東西，還是google說了算……微軟幾年前發(fā)布VC-1，然后說沒有專利問題……但是幾個月后，就有眾多公司認領了專利并成立了專利池（指幾 家公司把各自的專利放在一起，組成一個”池”。其他人如果要使用VC-1，就須向”池”的管理公司申請許可，一旦獲得了許可，就可以使用”池”中的所有專 利。）
問題三：vp8的代碼情況如何
首先你要知道：一個很好的編碼器，可能是基于一個很爛的標準（divx？xvid？lol）；而一個很好的標準，也可能會出現(xiàn)n多很爛的編碼程序 （h264 vs coreavc？不知道耶）。
vp8的文檔真的很爛，很多細節(jié)要不就是沒有文字說明，要不就是拿一大堆c代碼來填補空白。真的好痛苦……
我一直認為H.264的規(guī)格寫得太啰嗦，但和vp8相比，至少他是精確而詳細的，至少不會殺傷我這么多腦細胞。如果只靠vp8的這份文檔，我想我死 也寫不出來vp8的解碼器……（莫非他們就是一行一行讀h264的文檔然后寫的ffh264解碼器？牛?。?/p>
不吐槽了，把視線收回來，看vp8。一般處理視頻的步驟都是：
編碼：預測 -> 變換+量化處理 -> 熵編碼 -> 環(huán)路過濾器
解碼：熵編碼 -> 預測 -> 反量化處理+變幻 -> 環(huán)路過濾器
p幀
就是通過當前幀已有的部分預測其他區(qū)塊的內容?？梢允窃诋斍皫M行，也可以通過運動補償?shù)姆绞皆趲g進行。
幀內預測
幀內預測是用來編碼幀間不同，在空間域上進行的預測編碼算法，可以除去相鄰塊之間的空間冗余度，取得更為有效的壓縮。
vp8的幀內預測基本上都是照抄h(huán)264的。”subblock”幾乎和h264一樣（他們竟然用了同樣的名字），還有h264的4×4模 式……whole block預測也基本上一樣使用16×16模式。色度預測模式也幾乎沒有區(qū)別，所以不可能擁有比h264更出色的效果了。但是值得一提的是，他們用 TM_PRED替代了planar預測模式。在預測方式上看起來有些不同，但是實際上h264都提供了相似的實現(xiàn)方法。
所以我對vp8有點失望。雖然說h264的預測功能的確不錯，但是這也是7年的老物了……需要改進，所以我真的希望類似real這樣的公司趕緊滅亡 吧，一個存在了十幾年而從來沒有任何改進的格式（rm，rmvb）……我希望on2能做一些更有創(chuàng)造性的工作，而不是照搬h264的東西，因為h264的 專利問題就是一個定時炸彈。h264的幀內預測可是有專利的，真不知道on2怎么想的，我可不認為on2改個名字就能蒙混過關。
幀內預測對決：大部份照抄h(huán)264，甚至有的連名字都沒改……但是效果貌似還不如h264。
幀間預測：
幀內預測主要用在去除空間冗余上而幀間預測則主要用在去除時間冗余上。運動估計就是在參考幀中尋找與當前編碼宏塊最匹配的宏塊，而運動補償就是計算 二者的差值。幀間預測主要由兩個部分組成：參考幀和運動矢量。vp8支持3中參考幀：p幀，g幀（golden fream）和alt ref幀。運動矢量上，vp8支持比h264更多的可變大小區(qū)塊，次像素精度上，他支持四分之一像素和6-tap插值過濾。簡而言之就是：
vp8參考幀：3
h264：16
vp8支持區(qū)塊類型：6×16, 16×8, 8×16, 8×8, 4×4
h264：16×16, 16×8, 8×16, 但是還有更靈活的子區(qū)塊：例如 8×8 可以被分為 8×8, 8×4, 4×8, 或者 4×4
VP8 chroma MV derivation: 4×4 色度均值處理 (有點類似于 MPEG-4 ASP)
h264：直接使用，沒有什么處理（沒有均值處理，所以視覺效果比較好）
H.264 擁有b幀和加權預測，但是vp8卻沒有
h264擁有更為靈活的架構，所以8×8并不常用，所以vp8棄用也沒有太多影響。但是色度處理上，h264因為沒有均值，所以擁有比vp8更好地 效果，但是理論上它需要更多的時間來編碼。但是實際中差別并不是很明顯。
vp8的插值過濾器似乎優(yōu)秀一些，但是他是以犧牲性能為代價的。竟然還用高達6的色度，真搞清楚他們在干什么……這只是無謂的浪費。
vp8沒有使用b幀是個致命的缺陷。使用b幀可以提高10-20%壓縮率并加快編碼速度，但是on2在他們所有的視頻編碼格式中都沒有應用b幀，但 是即使如此也有可能引起專利問題。
幀間編碼對決：部分與h264相似，但是架構上不如h264，雖然使用了更為優(yōu)秀的過濾器，但是沒有使用b幀，所以會嚴重導致壓縮 率降低。
變換與量化編碼
總體來說，VP8肯定比H.264弱。一個8 × 8變換缺乏細節(jié)，特別是在高的分辨率。很多轉換也不是必要的，卻在進行。所以比較慢。由于專利，變換也有可能產生糾紛。一個良好的新思路是采用 分層直流轉換間塊。
轉換：類似H.264標準。慢一點，再稍微更準確的4 × 4變換。改進直流變換亮度（但色度不是）。沒有8 × 8變換?？傮w而言，更糟。
量化方面，核心過程基本上和所有的MPEG 視頻格式一樣，所以VP8也不例外。一個視頻格式，如果想體現(xiàn)自己與眾不同，那么他們主要的方式是通過改變量化尺度因子。方法有兩種，主要是：基礎幀的偏 移量，宏塊級的偏移，對于視頻來說整體適合或者部分適合。 VP8主要使用前者，但是遠遠低于H.264靈活的自定義量化矩陣，它允許調整亮度量化直流，交流亮度，色度直流，等等。后者（宏塊級量化選擇）可以在理 論實現(xiàn)“圖像分割”功能，雖然很hack，但是效果嘛……
vp8的致命錯誤是已經不使用宏塊級量化作為其核心功能。該算法利用宏塊級量化的優(yōu)勢被稱為“自適應量化”，是絕對至關重要的。x264使用執(zhí) 行方差的自適應量化（算法對比：使用前，使用后）后效果明顯，至今仍然是x264視覺質量收益提供支持。
對量化對決：在成為殺手級視頻格式前，缺少綜合自適應量化將是絕對錯誤的。總體而言，非常糟糕。
熵編碼
根據(jù)信息論的原理，可以找到最佳數(shù)據(jù)壓縮編碼的方法，數(shù)據(jù)壓縮的理論極限是信息熵。如果要求編碼過程中不丟失信息量，即要求保存信息熵，這種信 息保持編碼 叫熵編碼，是根據(jù)消息出現(xiàn)概率的分布特性而進行的，是無損數(shù)據(jù)壓縮編碼。
在視頻編碼中，熵編碼把一系列用來表示視頻序列的元素符號轉變?yōu)?一個用來傳輸或是存儲的壓縮碼流.輸入的符號可能包括量化的變換系數(shù)(像上面所說的運行級或零樹),運動向量(對于每個運動補償塊的向量值x和y),標記 (在序列中用來表示重同步位的點),頭(宏塊頭,圖象頭,序列的頭等)以及附加信息(對于正確解碼來說不重要的信息).
VP8使用的熵編碼器有點類似于H.264，但有幾個關鍵處又有所不同。首先，它忽略了范圍/概率乘法表。第二，它是完全非自適應的：與 H.264相比，它能夠解碼后的每一幀，概率值保持不變。
這種做法并不奇怪; VP5和VP6（也許是VP7）也用的非自適應算術編碼器。更重要的是，我之所以對這個問題感興趣，是因為它使自適應會增加單一的表查找來的算術解碼功能 ——對性能的影響很小。
vp8這個方案的缺點是，像VP3/Theora（雖然沒有那么嚴重），它偏向于以重新使用以前的運動矢量。這是相當危險的，因為正如開發(fā)員們最近 發(fā)現(xiàn)，一些情況下，即選取一個運動矢量編碼器是不是“真實”的運動矢量，以略去潛在的負面的視覺影響。在效率方面，我不知道是VP8比H.264的預測是 否能做到更好。
還有一點要注意的是VP8文件的結構。這個有點像VP3/Theora，涉及組件的每個碼流的語法元素。這個不幸的是，它是硬件加速的噩夢，需 要極大提高存儲效能以及帶寬。
熵編碼對決：它在某些方面出現(xiàn)好轉，在某些方面惡化， 實在怪異。我的直覺是，它對H.264非自適應算術編碼有一些輕微的優(yōu)勢，但是硬件加速方面，真是杯具。
環(huán)路濾波器
通常是在編碼/解碼幀后使用，通常是為了消除基于DCT的視頻格式的方塊現(xiàn)象。
VP8的環(huán)路濾波器與H.264依然相似，但有一些區(qū)別。首先，它有兩種模式（即可以由編碼器選擇）：快速模式和普通模式?？焖倌Ｊ奖?H.264 的簡單，而正常模式較為復雜。第二，宏塊之間的濾波，VP8的過濾器比h264的宏塊濾波器有更廣泛的作用范圍，h264的則僅限于邊緣。
環(huán)路濾波器對比：絕對比H.264的差，因缺乏自動適應性。雖然選擇快速模式可以加快速度，但是成像結果慘不忍睹，十分模糊。
附錄A：
總體而言，很明顯，VP8明顯比H.264差。上面提到的主要弱點是缺乏適當?shù)淖赃m應量化，沒有B幀，缺少8 × 8變換，以及非自適應性環(huán)路濾波器。其實我真的希望VP8能超越H.264，VC – 1或者H.264 Baseline Profile。當然，vp8現(xiàn)在性能明顯優(yōu)于theora和Dirac。
解碼的速度我不太清楚條件，目前大約是FFmpeg的H.264解碼器的16%（比自稱最先進的CoreAVC慢25%-35%） 。當然，全面優(yōu)化后能達到多少還難以預料，但是目前的確需要大幅優(yōu)化。
最后，還是專利問題。 VP8與H.264太相似了：一個精辟的，有些不太準確的描述說VP8將是基于H.264 Baseline Profile的最好的編碼器。雖然我不精通法律，但是我不相信他們能夠做到這點。即使VC – 1的不同于VP8和H.264，但是VC – 1也無法從軟件專利這個魔掌中逃脫。
如果google運氣夠好，專利之戰(zhàn)能夠勝利，也許能給theora帶來一絲曙光。
對比：
VP8 (On2 VP8 rc8) (source)
H.264 (Recent x264) (source)
H.264 Baseline Profile (Recent x264) (source)
Theora (Recent ptalabvorm nightly) (source)
Dirac (Schroedinger 1.0.9) (source)
VC-1 (Microsoft VC-1 SDK) (source)
MPEG-4 ASP (Xvid 1.2.2) (source)
附錄B：
谷歌之所以選擇Matroska作為封裝格式，這是不足為奇的：的Matroska是目前使用最廣泛使用的視頻封裝格式之一，也許MP4（又名 ISOmedia）可能是一個更好的設計格式，但不是很靈活，而且是一個封閉格式。
另一個優(yōu)點是Matroska可用于視頻流：雖然不常用，它的確可以。請注意，我不是說漸進式下載（a’la YouTube）的，而是實際的流，其中編碼器是實時工作的。這樣做的唯一方法是用MP4通過發(fā)送視頻的“片段”，非常hacky的方法。
真搞不懂為什么google非要給 Matroska 起 WebM 這么個愚蠢的名字
音頻選擇Vorbis格式，是明智之舉，沒有專利問題，而且性能優(yōu)秀。而且libvorbis是最好的開源通用音頻編碼器。雖然AAC是在低的比特率表現(xiàn)較好，但是沒有好的開源的AAC編碼器：FAAC的FFmpeg的AAC編碼器是更糟。此外，F(xiàn)AAC分部是不是免費軟件，它包含了非免費編碼器的 代碼。因為專利的問題，估計google也別無可選……
參考資料：
http://x264dev.multimedia.cx/?p=377
http://www.ruanyifeng.com/blog/2010/05/the_first_view_of_vp8.html
http://baike.baidu.com/view/587027.htm
http://hi.baidu.com/hnu_lina/blog/item/f13a59b1fd7eb9520823023e.html
http://zh.wikipedia.org/zh/%E7%86%B5%E7%BC%96%E7%A0%81
