WebM 影片格式，其實是以 Matroska（就是我們熟知的 MKV）容器格式為基礎開發(fā)的新容器格式，里面包括了 VP8 影片軌和 Ogg Vorbis 音軌。Ogg Vorbis 本來就是開放格式，大家應該都知道，至于 VP8 則是 Google 當年買下一間叫 On2 的公司的時候，取得的 Video Codec，現(xiàn)在 Google 也把這個 Codec 以類似 BSD 授權放出來，因此 WebM 應該是不會有 H.264 的那些潛在的專利問題。
Google 說 WebM 的格式相當有效率，應該可以在 netbook、tablet、手持式裝置等上面順暢地使用，當然自家的 Youtube 也會支持 WebM 的播放。來自產(chǎn)業(yè)界的奧援有 Adobe -- Flash Player 將會支持 WebM 格式的播放 -- AMD、ARM、Broadcom、Freescale、NVIDIA、Qualcomm、TI 等。誰不在上頭？Intel。在 Browser 方面，Chrome 不要說，F(xiàn)irefox、Opera 都已經(jīng)表態(tài)將會支持這個新格式。微軟 IE9 的支持就沒這么直接，出廠時僅會支持 H.264 影片的播放，但如果你另外下載并安裝了 VP8，那當然你也可以播放 HTML / VP8 的影片。
要推動一個新格式進入主流，甚至成為龍頭老大，是非常不容易的。但 WebM 和 VP8 的推動者是 Google，而且是在 H.264 正因為其非開放性而備受質(zhì)疑的時候，或許 WebM 真有機會迅速地站穩(wěn)腳跟，一舉成為新一代的影片通用格式呢！
手握H.264視頻編碼標準的專利公司MPEG-LA集團的CEO Larry Horn本周四表示，由谷歌公司主導的VP8網(wǎng)頁開源視頻編碼器組織WebM組織的成員仍然需要支付專利授權費用。他表示盡管谷歌堅稱 加入WebM組織的 成員完全不需要為使用Web視頻編碼器而付任何費用，但MPEG-LA目前正在籌劃向WebM發(fā)起專利訴訟，要求加 入WebM的成員為使用VP8開源編碼 器而支付專利費用。假如MPEG-LA在官司中得勝，那么不僅WebM組織自然會分崩離析，而 且組織的主要成員如谷歌，Mozilla，Opera等拒絕支付專利費的公司將惹上官司麻煩。
MPEG-LA集團的這項聲明可謂與蘋果喬布斯不久前的聲明相互呼應，最近喬布斯曾宣稱WebM組織的VP8編碼器觸犯了蘋果公司的技術專利。
谷歌產(chǎn)品經(jīng)理Mike Jazayeri則堅決反對這種說法，并宣稱谷歌“有備而來，已經(jīng)對有關的專利進行過詳細的分析”。
原文：electronista
問題一：vp8到底怎么樣？
難道他真的比x264擁有更高的壓縮比率，是個優(yōu)秀的編碼器嗎？他真的比h264優(yōu)秀嗎？似乎On2自己都羞于承認…拿vp7舉例，On2宣稱 vp7比h264快15%，但事實是編碼視頻速度既不快，視頻質(zhì)量也不高。On2曾經(jīng)把vp3開源，似乎想借助社區(qū)的力量debug，最終theora上當……他們花了6年時間，結(jié)果做出來的還是個雞肋……
這個東西，還是google說了算……微軟幾年前發(fā)布VC-1，然后說沒有專利問題……但是幾個月后，就有眾多公司認領了專利并成立了專利池（指幾家公司把各自的專利放在一起，組成一個”池”。其他人如果要使用VC-1，就須向”池”的管理公司申請許可，一旦獲得了許可，就可以使用”池”中的所有專利。）
首先你要知道：一個很好的編碼器，可能是基于一個很爛的標準（divx？xvid？lol）；而一個很好的標準，也可能會出現(xiàn)n多很爛的編碼程序（h264 vs coreavc？不知道耶）。
vp8的文檔真的很爛，很多細節(jié)要不就是沒有文字說明，要不就是拿一大堆c代碼來填補空白。真的好痛苦……
我一直認為H.264的規(guī)格寫得太啰嗦，但和vp8相比，至少他是精確而詳細的，至少不會殺傷我這么多腦細胞。如果只靠vp8的這份文檔，我想我死也寫不出來vp8的解碼器……（莫非他們就是一行一行讀h264的文檔然后寫的ffh264解碼器？牛！）
不吐槽了，把視線收回來，看vp8。一般處理視頻的步驟都是：
編碼：預測 -> 變換+量化處理 -> 熵編碼 -> 環(huán)路過濾器
解碼：熵編碼 -> 預測 -> 反量化處理+變幻 -> 環(huán)路過濾器
就是通過當前幀已有的部分預測其他區(qū)塊的內(nèi)容。可以是在當前幀進行，也可以通過運動補償?shù)姆绞皆趲g進行。
幀內(nèi)預測是用來編碼幀間不同，在空間域上進行的預測編碼算法，可以除去相鄰塊之間的空間冗余度，取得更為有效的壓縮。
vp8的幀內(nèi)預測基本上都是照抄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的幀內(nèi)預測可是有專利的，真不知道on2怎么想的，我可不認為on2改個名字就能蒙混過關。
幀內(nèi)預測對決：大部份照抄h(huán)264，甚至有的連名字都沒改……但是效果貌似還不如h264。幀內(nèi)預測主要用在去除空間冗余上而幀間預測則主要用在去除時間冗余上。運動估計就是在參考幀中尋找與當前編碼宏塊最匹配的宏塊，而運動補償就是計算二者的差值。幀間預測主要由兩個部分組成：參考幀和運動矢量。vp8支持3中參考幀：p幀，g幀（golden fream）和alt ref幀。運動矢量上，vp8支持比h264更多的可變大小區(qū)塊，次像素精度上，他支持四分之一像素和6-tap插值過濾。簡而言之就是：
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é)，特別是在高的分辨率。很多轉(zhuǎn)換也不是必要的，卻在進行。所以比較慢。由于專利，變換也有可能產(chǎn)生糾紛。一個良好的新思路是采用分層直流轉(zhuǎn)換間塊。
vp8這個方案的缺點是，像VP3/Theora（雖然沒有那么嚴重），它偏向于以重新使用以前的運動矢量。這是相當危險的，因為正如開發(fā)員們最近發(fā)現(xiàn)，一些情況下，即選取一個運動矢量編碼器是不是“真實”的運動矢量，以略去潛在的負面的視覺影響。在效率方面，我不知道是VP8比H.264的預測是否能做到更好。
對比：
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)
谷歌之所以選擇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（純 屬業(yè)余翻譯，不足之處，懇請指出，謝謝！）
