部分翻譯：http://x264dev.multimedia.cx/?p=377

譯者：delectate

• 問題一：vp8到底怎么樣？

難道他真的比x264擁有更高的壓縮比率，是個優秀的編碼器嗎？他真的比h264優秀嗎？似乎On2自己都羞于承認…拿vp7舉例，On2宣稱vp7比h264快15%，但事實是編碼視頻速度既不快，視頻質量也不高。On2曾經把vp3開源，似乎想借助社區的力量debug，最終theora上當……他們花了6年時間，結果做出來的還是個雞肋……

• 問題二：vp8真的沒有專利問題嗎？

這個東西，還是google說了算……微軟幾年前發布VC-1，然后說沒有專利問題……但是幾個月后，就有眾多公司認領了專利并成立了專利池（指幾家公司把各自的專利放在一起，組成一個”池”。其他人如果要使用VC-1，就須向”池”的管理公司申請許可，一旦獲得了許可，就可以使用”池”中的所有專利。）

• 問題三：vp8的代碼情況如何

首先你要知道：一個很好的編碼器，可能是基于一個很爛的標準（divx？xvid？lol）；而一個很好的標準，也可能會出現n多很爛的編碼程序（h264 vs coreavc？不知道耶）。

vp8的文檔真的很爛，很多細節要不就是沒有文字說明，要不就是拿一大堆c代碼來填補空白。真的好痛苦……

我一直認為H.264的規格寫得太啰嗦，但和vp8相比，至少他是精確而詳細的，至少不會殺傷我這么多腦細胞。如果只靠vp8的這份文檔，我想我死也寫不出來vp8的解碼器……（莫非他們就是一行一行讀h264的文檔然后寫的ffh264解碼器？牛！）

不吐槽了，把視線收回來，看vp8。一般處理視頻的步驟都是：

編碼：預測 -> 變換+量化處理 -> 熵編碼 -> 環路過濾器

解碼：熵編碼 -> 預測 -> 反量化處理+變幻 -> 環路過濾器

• p幀

就是通過當前幀已有的部分預測其他區塊的內容。可以是在當前幀進行，也可以通過運動補償的方式在幀間進行。

• 幀內預測

幀內預測是用來編碼幀間不同，在空間域上進行的預測編碼算法，可以除去相鄰塊之間的空間冗余度，取得更為有效的壓縮。

vp8的幀內預測基本上都是照抄h264的?！眘ubblock”幾乎和h264一樣（他們竟然用了同樣的名字），還有h264的4×4模式……whole block預測也基本上一樣使用16×16模式。色度預測模式也幾乎沒有區別，所以不可能擁有比h264更出色的效果了。但是值得一提的是，他們用TM_PRED替代了planar預測模式。在預測方式上看起來有些不同，但是實際上h264都提供了相似的實現方法。

所以我對vp8有點失望。雖然說h264的預測功能的確不錯，但是這也是7年的老物了……需要改進，所以我真的希望類似real這樣的公司趕緊滅亡吧，一個存在了十幾年而從來沒有任何改進的格式（rm，rmvb）……我希望on2能做一些更有創造性的工作，而不是照搬h264的東西，因為h264的專利問題就是一個定時炸彈。h264的幀內預測可是有專利的，真不知道on2怎么想的，我可不認為on2改個名字就能蒙混過關。

幀內預測對決：大部份照抄h264，甚至有的連名字都沒改……但是效果貌似還不如h264。

• 幀間預測：

幀內預測主要用在去除空間冗余上而幀間預測則主要用在去除時間冗余上。運動估計就是在參考幀中尋找與當前編碼宏塊最匹配的宏塊，而運動補償就是計算二者的差值。幀間預測主要由兩個部分組成：參考幀和運動矢量。vp8支持3中參考幀：p幀，g幀（golden fream）和alt ref幀。運動矢量上，vp8支持比h264更多的可變大小區塊，次像素精度上，他支持四分之一像素和6-tap插值過濾。簡而言之就是：

• vp8參考幀：3
• h264：16
• vp8支持區塊類型：6×16, 16×8, 8×16, 8×8, 4×4
• h264：16×16, 16×8, 8×16, 但是還有更靈活的子區塊：例如 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的插值過濾器似乎優秀一些，但是他是以犧牲性能為代價的。竟然還用高達6的色度，真搞清楚他們在干什么……這只是無謂的浪費。

vp8沒有使用b幀是個致命的缺陷。使用b幀可以提高10-20%壓縮率并加快編碼速度，但是on2在他們所有的視頻編碼格式中都沒有應用b幀，但是即使如此也有可能引起專利問題。

幀間編碼對決：部分與h264相似，但是架構上不如h264，雖然使用了更為優秀的過濾器，但是沒有使用b幀，所以會嚴重導致壓縮率降低。

• 變換與量化編碼

總體來說，VP8肯定比H.264弱。一個8 × 8變換缺乏細節，特別是在高的分辨率。很多轉換也不是必要的，卻在進行。所以比較慢。由于專利，變換也有可能產生糾紛。一個良好的新思路是采用 分層直流轉換間塊。

轉換：類似H.264標準。慢一點，再稍微更準確的4 × 4變換。改進直流變換亮度（但色度不是）。沒有8 × 8變換?？傮w而言，更糟。 量化方面，核心過程基本上和所有的MPEG 視頻格式一樣，所以VP8也不例外。一個視頻格式，如果想體現自己與眾不同，那么他們主要的方式是通過改變量化尺度因子。方法有兩種，主要是：基礎幀的偏移量，宏塊級的偏移，對于視頻來說整體適合或者部分適合。 VP8主要使用前者，但是遠遠低于H.264靈活的自定義量化矩陣，它允許調整亮度量化直流，交流亮度，色度直流，等等。后者（宏塊級量化選擇）可以在理論實現“圖像分割”功能，雖然很hack，但是效果嘛…… vp8的致命錯誤是已經不使用宏塊級量化作為其核心功能。該算法利用宏塊級量化的優勢被稱為“自適應量化”，是絕對至關重要的。x264使用執行方差的自適應量化（算法對比：使用前，使用后）后效果明顯，至今仍然是x264視覺質量收益提供支持。 對量化對決：在成為殺手級視頻格式前，缺少綜合自適應量化將是絕對錯誤的。總體而言，非常糟糕。

• 熵編碼

根據信息論的原理，可以找到最佳數據壓縮編碼的方法，數據壓縮的理論極限是信息熵。如果要求編碼過程中不丟失信息量，即要求保存信息熵，這種信息保持編碼 叫熵編碼，是根據消息出現概率的分布特性而進行的，是無損數據壓縮編碼。
在視頻編碼中，熵編碼把一系列用來表示視頻序列的元素符號轉變為 一個用來傳輸或是存儲的壓縮碼流.輸入的符號可能包括量化的變換系數(像上面所說的運行級或零樹),運動向量(對于每個運動補償塊的向量值x和y),標記 (在序列中用來表示重同步位的點),頭(宏塊頭,圖象頭,序列的頭等)以及附加信息(對于正確解碼來說不重要的信息). VP8使用的熵編碼器有點類似于H.264，但有幾個關鍵處又有所不同。首先，它忽略了范圍/概率乘法表。第二，它是完全非自適應的：與H.264相比，它能夠解碼后的每一幀，概率值保持不變。 這種做法并不奇怪; VP5和VP6（也許是VP7）也用的非自適應算術編碼器。更重要的是，我之所以對這個問題感興趣，是因為它使自適應會增加單一的表查找來的算術解碼功能 ——對性能的影響很小。

vp8這個方案的缺點是，像VP3/Theora（雖然沒有那么嚴重），它偏向于以重新使用以前的運動矢量。這是相當危險的，因為正如開發員們最近發現，一些情況下，即選取一個運動矢量編碼器是不是“真實”的運動矢量，以略去潛在的負面的視覺影響。在效率方面，我不知道是VP8比H.264的預測是否能做到更好。

還有一點要注意的是VP8文件的結構。這個有點像VP3/Theora，涉及組件的每個碼流的語法元素。這個不幸的是，它是硬件加速的噩夢，需要極大提高存儲效能以及帶寬。 熵編碼對決：它在某些方面出現好轉，在某些方面惡化，實在怪異。我的直覺是，它對H.264非自適應算術編碼有一些輕微的優勢，但是硬件加速方面，真是杯具。

• 環路濾波器

通常是在編碼/解碼幀后使用，通常是為了消除基于DCT的視頻格式的方塊現象。 VP8的環路濾波器與H.264依然相似，但有一些區別。首先，它有兩種模式（即可以由編碼器選擇）：快速模式和普通模式。快速模式比H.264 的簡單，而正常模式較為復雜。第二，宏塊之間的濾波，VP8的過濾器比h264的宏塊濾波器有更廣泛的作用范圍，h264的則僅限于邊緣。 環路濾波器對比：絕對比H.264的差，因缺乏自動適應性。雖然選擇快速模式可以加快速度，但是成像結果慘不忍睹，十分模糊。

• 附錄A：

總體而言，很明顯，VP8明顯比H.264差。上面提到的主要弱點是缺乏適當的自適應量化，沒有B幀，缺少8 × 8變換，以及非自適應性環路濾波器。其實我真的希望VP8能超越H.264，VC – 1或者H.264 Baseline Profile。當然，vp8現在性能明顯優于theora和Dirac。 解碼的速度我不太清楚條件，目前大約是FFmpeg的H.264解碼器的16%（比自稱最先進的CoreAVC慢25%-35%） 。當然，全面優化后能達到多少還難以預料，但是目前的確需要大幅優化。 最后，還是專利問題。 VP8與H.264太相似了：一個精辟的，有些不太準確的描述說VP8將是基于H.264 Baseline Profile的最好的編碼器。雖然我不精通法律，但是我不相信他們能夠做到這點。即使VC – 1的不同于VP8和H.264，但是VC – 1也無法從軟件專利這個魔掌中逃脫。 如果google運氣夠好，專利之戰能夠勝利，也許能給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）可能是一個更好的設計格式，但不是很靈活，而且是一個封閉格式。

另一個優點是Matroska可用于視頻流：雖然不常用，它的確可以。請注意，我不是說漸進式下載（a’la? YouTube）的，而是實際的流，其中編碼器是實時工作的。這樣做的唯一方法是用MP4通過發送視頻的“片段”，非常hacky的方法。

真搞不懂為什么google非要給 Matroska 起 WebM 這么個愚蠢的名字

音頻選擇Vorbis格式，是明智之舉，沒有專利問題，而且性能優秀。而且libvorbis是最好的開源通用音頻編碼器。雖然AAC是在低的比特率表現較好，但是沒有好的開源的AAC編碼器：FAAC的FFmpeg的AAC編碼器是更糟。此外，FAAC分部是不是免費軟件，它包含了非免費編碼器的代碼。因為專利的問題，估計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

原文地址：https://www.deleak.com/blog/2010/05/22/the-first-in-depth-technical-analysis-of-vp8/

轉載于:https://www.cnblogs.com/leixiaohua1020/p/3902066.html

總結

以上是生活随笔為你收集整理的深入了解 VP8的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。