利益交错-HTML5视频标准之争
一、基本概念
????? Google 宣布將在 Chrome 瀏覽器中移除對 H.264 視頻解碼的支持，此舉在業界引起了不小的騷動。借此機會我們回顧一下 HTML5 視頻格式之爭。
????? 首先需要理清一些基本概念。我們平常籠統說的「視頻格式」其實包含三個部分：視頻編碼、音頻編碼、容器格式。其中「編碼」這個概念其實又包含兩個方面：編碼和解碼。「視頻編碼」作為動詞指的是將動態的圖像信息轉化為二進制數據的過程；其逆過程稱為「視頻解碼」。「視頻編碼」作為名詞則通常指的是某種特定的編碼方式。同樣的概念也適用于「音頻編碼」，只不過它轉化的是聲音信息。大多數「視頻文件」都同時包含視頻和音頻，因此編碼后至少都有兩組二進制數據，并且兩組數據必須按照特定的方式同步起來，否則我們看到的畫面和聽到的聲音將不吻合。為了解決編碼后多組不同類型的的數據的存儲、傳輸問題，需要將他們按照一定的規律組織起來，這種組織方式即是「容器格式」。
????? 我們常見的視頻文件擴展名包括 .avi, .rmvb, .mp4, .mkv 等。其實擴展名都是指的某種容器格式。這些容器里面存放的數據可能采用了多種不同的編碼方式。例如，常見的 avi 文件里面存放的通常是 xvid 或 divx 編碼的視頻和 mp3 編碼的音頻。rmvb 文件里面存放的通常是 RV40 編碼的視頻和 cook 編碼的音頻。mp4 文件里面通常存放的是 H.264 編碼的視頻和 AAC 編碼的音頻。mkv 文件里面存放的則可能包含前面各種。
????? 限于篇幅我們不涉及所有常見的視頻格式。這次主要討論兩種：
????? 1、采用 H.264 視頻編碼和 AAC 音頻編碼的 MP4 文件（H.264/AAC/MP4 組合）
????? 2、采用 VP8 視頻編碼和 Vorbis 音頻編碼的 WebM 文件（VP8/Vorbis/WebM 組合）
????? H.264 是目前公認的效率最高的的視頻編碼。它是由國際電信聯盟通電信標準部 (ITU-T) 和國際標準化組織/國際電工委員會動態圖像專家組 (ISO/IEC MPEG) 共同開發的一種視頻壓縮技術。它的另外一個名稱是 MPEG-4 AVC。目前 H.264 被廣泛的運用在藍光電影、數字電視、衛星電視、網絡媒體等領域。可以說 H.264 是目前被運用得最為廣泛的視頻編碼。
????? AAC 是 ISO/IEC 標準化的音頻編碼。它是比 MP3 更先進的音頻壓縮技術，目的在于取代陳舊的 MP3。AAC 音頻編碼被廣泛的運用在數字廣播、數字電視等領域。目前網上最大的音樂零售商蘋果的 iTunes 音樂商店的所有數字音樂也全部采用的 AAC 音頻編碼。
????? MP4 則是 ISO/IEC 制定的容器格式標準，用以封裝編碼后的視頻和音頻數據。MP4 支持多種方式編碼后的數據，但最常見的是 H.264 編碼的視頻和 AAC 編碼的音頻。
????? VP8 是類似于 H.264 的另一種視頻編碼，由 On2 公司開發。后來 Google 收購了 On2，因此 VP8 現在歸 Google 所有。據稱為了避開 H.264 的專利問題，VP8 沒有采用一些特別的算法，使得其壓縮效率效率略低于 H.264。
????? Vorbis 是類似 AAC 的另一種免費、開源的音頻編碼，由非盈利組織 Xiph 開發。業界的普遍共識是 Vorbis 是和 AAC 一樣優秀、用以替代 MP3 的下一代音頻壓縮技術。由于 Vorbis 是免費、開源的，并且沒有 AAC 的專利問題，許多游戲廠商采用 Vorbis 編碼游戲中的音頻資料，例如著名的 Halo，Guitar Hero 等。最近流行的在線音樂網站 Spotify 也是使用的 Vorbis 音頻編碼。
????? WebM 是 Google 基于開源容器格式 Matroska（.mkv 很多朋友應該不陌生）而專門開發的一種新型容器格式。其目的是用來封裝 VP8 編碼的視頻和 Vorbis 編碼的音頻數據以供網絡媒體使用。
????? 在涉及 HTML5 視頻格式的討論中，通常「H.264」指代 H.264/AAC/MP4 這個組合，而「WebM」指代 VP8/Vorbis/WebM 這個組合。為了符合習慣、避免重復，我們也將采用同樣的簡稱，即 H.264 = H.264/AAC/MP4，WebM = VP8/Vorbis/WebM。
二、HTML5 視頻標準
???? HTML5 標準制定時曾經考慮過指定一種視頻格式（包括視頻編碼、音頻編碼、容器格式）作為標準的一部分，所有瀏覽器廠商都必須實現。理想的視頻格式應該具有如下特性：
高壓縮率，且畫質尚佳
解碼容易，且要有硬件解碼器以供處理能力不足的便攜設備使用
免費，且沒有潛在的專利糾紛
????? 當時考慮過的兩個組合是 Theora 視頻編碼、Vorbis 音頻編碼、Ogg 容器格式，或者 H.264/AAC/MP4（此時 Google 尚未收購 On2）。
????? Theora/Vorbis/Ogg 組合的三種技術都是由非營利組織 Xiph 開發并可以免費使用。其中 Theora 視頻編碼是基于 On2 的 VP3 視頻編碼發展起來的。但 Theora 在技術上落后于 H.264：為達到同樣的畫質 H.264 所需的文件尺寸比 Theora 更小。考慮到 HTML5 視頻主要通過網絡傳輸，在保留同等的畫質下文件尺寸要盡可能輕巧以節省網絡流量開支。參與 HTML5 標準制定的 Google 對此憂心忡忡：按照他們的估算，如果 YouTube 完全采用 Theora 且保持同樣的畫質的話，那么 YouTube 產生的網絡流量將消耗掉整個互聯網的帶寬資源。因此雖然 Google 宣稱將在其瀏覽器中同時支持 Theora 和 H.264，但 YouTube 的默認視頻編碼將使用 H.264。
????? 除了技術相對落后外，Theora 最終沒有被采納的另外一個重要原因則是尚不明朗的專利問題。蘋果認為雖然 Theora 可以免費使用，且沒有侵犯已知的專利，但這并不保證 Theora 采用的某些技術沒有侵犯到所謂的「潛艇專利」。所謂「潛艇專利」是指專利申請人故意推遲專利權的取得、公開，等到有大企業使用的技術侵犯到專利時再突然出現，對侵權企業進行訴訟索賠的做法。該做法類似于平時將潛艇藏起來，等到關鍵時刻出現發起攻擊，因此得名「潛艇專利」。這些尚未明確的潛在專利問題可能會在將來 Theora 流行起來后給采用 Theora 的大公司帶來不必要的專利訴訟。另外，很多人嘗試改進 Theora 以提高其編碼效率，但業內的共識是改進 Theora 的嘗試幾乎不可避免的會侵犯到某些專利。
????? 參與 HTML5 標準制定的各大廠商未能在是否 H.264 上達成一致。雖然 H.264 具有高壓縮比、高畫質、解碼容易、有成熟的硬件解碼器、專利問題相對明朗等優勢，但各方爭論的焦點主要在于 H.264 不是免費的。免費瀏覽器廠商如 Mozilla 和 Opera 強烈反對將 H.264 列為 HTML5 視頻標準。因為這意味著 Mozilla 和 Opera 如果要支持 HTML5 標準，那么他們必須支付相關的授權費。且不說這做法和其信條相去甚遠，Mozilla 沒有從其開發的瀏覽器上獲得直接收入，反而需要付出相應成本才能自由分發其瀏覽器產品；Opera 則抱怨說 H.264 的授權費太貴。因此兩者都認為不可接受。
????? 由于各方爭執不下，最后在 2007 年底的時候 HTML5 標準放棄了制定統一的視頻格式的努力，將選擇的自由留給了瀏覽器廠商。后來的結果是，Mozilla Firefox 和 Opera 只支持 Theora；蘋果全線產品（包括 Safari 瀏覽器和所有 iOS 設備）只支持 H.264；微軟承諾在 IE9 中原生支持 H.264；Google Chrome 同時支持 Theora 和 H.264。
三、WebM vs H.264
????? 2010年初 Google 收購了 On2 及其旗下的全部視頻壓縮技術。當時業界的普遍猜測是 Google 會不會將 On2 旗下最先進的 VP8 視頻編碼開放。果然，2010 年中的時候 Google 宣布將 VP8 永久免費。Google 又基于開源容器格式 Matroska 開發了 WebM 容器格式，用以封裝 VP8 編碼的視頻和 Vorbis 編碼的音頻。隨后 Google 連同 Mozilla 和 Opera，準備將 VP8/Vorbis/WebM （統稱為 WebM）推廣為網絡視頻的通用格式。Google Chrome 瀏覽器在 WebM 發布后迅速更新為同時支持 Theora、H.264、WebM 三種格式。Mozilla 和 Opera 也宣布將在其瀏覽器的后續版本（主要是 Firefox 4）中原生支持 WebM。
????? VP8 是一種遠好于 Theora 的視頻編碼。至于 VP8 和 H.264 比較起來效果怎樣，情況稍微有點復雜。VP8 不是一個標準。目前只有一個由 On2 開發的參照實現（reference implementation）。這個含糊不清的參照實現公開后遭到很多開發者的詬病。主要問題在于對于很多技術細節，On2 只有幾段代碼而沒有任何相關解釋。這給理解、改進 VP8 帶來了極大的困難。另一方面，雖然 Google 將 VP8 開源，但 VP8 整個設計過程是由 On2 秘密進行的，并且在 VP8 公開后不久，所有相關的數據規范隨即被凍結，隨之一起被凍結的還有這個參照實現的各種缺陷。因此嚴格上說 On2 并不是一個開放標準，所有的技術細節都掌握在 Google 手上。
????? 本文在此之前多次提到 H.264 都將其簡單描述成一種特定的視頻編碼格式。其實 H.264 只是一個工業標準，由眾多業內企業和專家共同開發制定，不受單一廠商控制。H.264 有多種不同的等級（profile），每個等級對應了不同的復雜程度以適應不同的需求。多個等級的存在使得 H.264 具有非常靈活的適應性：小到 iPod Nano，大到高清藍光播放器，都可以根據不同的計算能力和畫質要求選擇相應的等級。一般認為，VP8 和 H.264 的基礎等級（Baseline Profile）相當（H.264 有很多為高清視頻準備的等級）。
????? H.264 這個工業標準又有很多不同廠商開發的編碼器、解碼器實現（implementation）。即便遵循同一標準，不同的編碼器、解碼器產生的圖像質量又有略微的區別，這使得直接比較 VP8 和 H.264 變得相對困難。目前針對 VP8 和 H.264 效果的測試，一般都是采用 Google 的 VP8 參照編碼器實現和優秀的開源的 H.264 編碼器 x264 壓縮的視頻圖像進行對比。以現在的情況看，同等碼率下 VP8 的效果仍然略輸于 H.264。
????? 然而和 Theora 一樣 VP8 由于尚未經過市場檢驗，也存在潛在的專利問題。x264 的主要開發者之一曾對 VP8 的參照實現的源代碼進行過仔細分析，得出的結論是 VP8 和 H.264 過于相似，很難相信沒有任何專利侵權之處。Google 雖然宣布將 VP8 開源且永久免費，并且 Google 做過大量調查認為 VP8 應該不存在專利問題，但由于美國的專利制度的漏洞，誰也不能保證以后不會出現「潛艇專利」造成訴訟糾紛。一旦發生類似情況， Google 的 WebM 授權協議并不保護使用 WebM 的企業和個人。
????? 另外，由于 WebM 剛剛出現，尚不存在現成的 VP8 硬件解碼器，在處理能力弱小的便攜設備上無法使用。WebM 發布后多家硬件廠商如 AMD、ARM、Broadcom 均宣布支持該格式，但并沒有實際產品面世。另外的硬件廠商如 Intel、NVIDIA 則表示如果 WebM 廣泛流行起來他們會提供相應的硬件產品，尚持觀望態度。
????? 目前爭論 WebM 和 H.264 孰優孰劣的重點在于 WebM 雖然免費，但可能有潛在的專利問題，且由于沒有硬件解碼器無法在便攜設備上使用；H.264 專利問題明朗，技術相對先進，有硬件解碼器，且很多便攜設備已經在廣泛使用了，但需要付費。
????? H.264 涉及到很多專利技術，這些專利又由不同的組織和個人分別持有。如果有廠商要使用 H.264，顯然他不可能一個一個去和這些專利持有人談判。為了方便 H.264 的推廣，持有 H.264 相關專利的組織和個人將其專利授權給一個名為 MPEG LA 的組織，然后由該組織統一收取 H.264 相關專利的授權費。
????? MPEG LA 將 H.264 專利許可分為兩種：H.264 編碼器和解碼器（不論軟硬件）廠商需要購買一種 H.264 的專利許可協議，H.264 編碼的視頻的分發商（如電視臺等）需要購買另外一種 H.264 的專利許可協議。也就是說所有生產支持錄制 H.264 視頻的攝像設備、手機等的廠商都要向 MPEG LA 支付專利使用費。這個費用相對低廉：少于 10 萬個設備免費；10 萬個以上最多每個解碼器 20 美分，且支付上限為每年 650 萬美元。另外，MPEG LA 有規定，雖然每五年專利授權期過后它可以根據市場狀況調整授權費用，但每次漲價不會超過 10%。因此廠商使用 H.264 制造編碼器、解碼器在成本上是有可靠保證的。所有支持 H.264 視頻播放的硬件、軟件廠商也要向 MPEG LA 支付專利費。大部分企業如蘋果、微軟、索尼等都購買了相應的 H.264 專利許可協議，因此最終用戶在使用 H.264 技術制作和播放視頻的時候不用擔心費用問題。
????? 問題出在 MPEG LA 對網絡視頻（如 YouTube）的規定上。YouTube 這樣的站點屬于視頻的分發商。MPEG LA 對像電視臺這樣的傳統視頻分發商有完整的基于訂閱用戶數量的授權費用體系。但 MPEG LA 尚未對網絡視頻分發商收取專利費用。MPEG LA 每隔五年會更新其專利授權的相關規定。目前 MPEG LA 承諾在 2015 年底之前不會對分發 H.264 編碼的網絡視頻收取專利費用。2015 年后是否收取費用則尚不明確。許多人認為 MPEG LA 的這個并不明確的態度會成為未來網絡視頻的隱患，而使用開源、免費的 WebM 則沒有這個問題（注意這是假設 WebM 沒有潛在專利問題）。另外一種觀點則認為即便 WebM 沒有大規模流行，它的存在可以迫使 MPEG LA 繼續對分發 H.264 網絡視頻免費。【更新：評論中 cjsas 提到 MPEG LA 已經承諾永久免費了。我后來核對過確有此事。MPEG LA 于 2010 年 8 月宣布對通過互聯網免費分發給最終用戶的網絡視頻永久免費。收費的在線視頻業務如 iTunes 電影租賃、Netflix、Hulu 等還是要收費。】
四、現狀
????? Google 旗下和 H.264 有關的產品最重要的當然是 YouTube。作為互聯網上最大的視頻站點（雖然對國內用戶來說這已經沒什么意義了），YouTube 是否將繼續支持 H.264 至關重要。目前 YouTube 的所有視頻都采用 H.264 編碼。用戶上傳的視頻即便已經是 H.264 編碼的了，也通常需要在 YouTube 的服務器上重新編碼以統一分辨率、碼率等。YouTube 正在逐步將全部視頻采用 WebM 重新編碼。YouTube 的 HTML5 測試版的部分視頻用的 WebM、部分用的 H.264。
????? 在 Google 從 Chrome 中移除原生 H.264 支持之前，Chrome 被認為是播放網絡視頻的最佳瀏覽器，因為它同時原生支持 Theora、H.264、WebM（當然還有并不可愛的 Flash 插件）。Chrome 瀏覽器中使用到的 H.264 解碼器需要支付專利費。基于 Android 系統的便攜設備上目前采用的是 H.264 硬件解碼器。等 WebM 硬件解碼器成熟后，Android 系統應該會加入 WebM 的硬件支持。
Google 需要為其使用 H.264 的產品支付專利授權費。但這些費用對 Google 來說不過是九牛一毛。Google 認為免費、開源的視頻編碼對互聯網的長遠發展是有益處的。很多人也持同樣的觀點。我們姑且稱這一群人為 Google 派，典型代表的除了 Google 本身，還有 Mozilla 和 Opera 等。
????? 與Google 形成鮮明對比的
是蘋果。蘋果一直是 H.264 的堅定支持者。目前蘋果全線產品都對 H.264 有硬件支持。由于 CPU 處理能力不足，同時需要考慮節能，所有 iOS 設備都配備有專為移動設備開發的低功耗硬件解碼芯片。運行 OS X 的筆記本和臺式機則是通過 NVIDIA 和 ATI 的顯卡提供硬件解碼支持。OS X Snow Leopard 自帶的 QuickTime X 播放器播放 H.264/MP4 格式視頻時默認采用顯卡硬件加速，因此在播放期間 CPU 占用相當低。相比用 CPU 軟件解碼，硬件解碼的效率更高、功耗更低，在播放高碼率高清視頻時特別明顯。個人經驗是播放高清電影時，有硬件加速的情況下筆記本散熱風扇基本不轉，軟件解碼就轉個不停。
????? 在對 HTML5 視頻的支持上，蘋果自家的 Safari 瀏覽器是將視頻解碼部分交由 iOS 或者 OS X 處理的。在 iOS 和 OS X 已經為 H.264 支付過專利費的情況下，Safari 不用為使用 H.264 的支付額外成本。另外值得一提的是 ISO 標準的 MP4 容器格式是基于蘋果 QuicTime 容器格式開發的。蘋果也是 H.264 專利授權組織 MPEG LA 的成員之一，其花費在 H.264 授權費的支出和收入可以部分抵消。而且蘋果使用 H.264 的設備出貨量驚人，它為此支付的單位成本也是最低的。
????? 蘋果一貫認為用戶體驗更加重要。從 iPhone 首次面試到現在的幾年中，H.264 是可供移動設備高效節能的播放高質量視頻的唯一選擇。在桌面系統上，H.264 又能在 CPU 處理能力有限的情況下支持大分辨率高清視頻。可以說 H.264 是目前用戶體驗最好的視頻技術。蘋果樂意為使用這一技術付費。很多人（如鐵桿蘋果粉 John Gruber、Macro Arment 等人）也持同樣觀點。他們認為 H.264 是目前最先進的視頻技術，并且現在大規模流行已經成為事實標準（de facto standard）。工業界花費了好多年時間好不容易達到今天這樣統一標準的局面，此時多出來任何新的格式只會添亂。我們姑且稱這一群人為蘋果派。
????? HTML5 尚未普及。在桌面系統上，目前最主流的支持 H.264 視頻播放的方式仍然是使用 Adobe 的 Flash 插件。Flash 插件在除 Windows 外的所有系統上性能都非常糟糕，而 Adobe 在過去的幾年中對此毫無辦法（據說是因為 Flash 代碼實在太亂，積重難返），以至于喬布斯下決心要在蘋果平臺上干掉它。徹底不支持 Flash 的 iOS 設備廣泛流行和喬布斯的堅決態度讓 Adobe 感到了一定壓力。另一方面，Google 為了和蘋果競爭，不惜以用戶體驗為代價，在其 Android 系統上支持 Flash。Google 又在 Chrome 瀏覽器中綁定了 Flash 插件作為其推進網頁應用的支撐技術之一。也許是作為回報，Adobe 承諾將在下一個版本的 Flash 插件中加入 WebM 支持。
????? 部分蘋果派陰謀論者認為 Google 讓 Flash 茍延殘喘并努力推廣 WebM 取代 H.264 的另外一個重要原因是可以借此打壓蘋果，因為在 iOS 平臺上蘋果不支持 Flash，也很難相信作為 H.264 的堅定支持者蘋果會支持質量更差的 WebM。而 Google 在 Chrome 中移除 H.264 支持的最大贏家就是 Adobe。大部分視頻站點的內容都是 H.264 編碼的，Google 此舉這幾乎確保了 Flash 在未來幾年中不可替代的地位。
五、未來
????? 網絡視頻站若完全轉向使用 WebM 可以節省一筆專利費用。然而「完全轉用 WebM」 并不現實：有數量龐大的設備（特別是移動設備）只支持H.264，因此在相當長一段時間內至少需要同時支持 H.264 和WebM。但這意味著視頻站的存儲成本頓時要翻一番。視頻站點所使用的內容分發網絡（Content Distribution Network,CDN）也由于需要同時緩存兩種格式的視頻而導致成本翻番。對于同樣一段原始視頻，需要編碼成 H.264 和 WebM兩種格式，導致轉碼處理成本也要翻番。此外還要將現有的視頻資源全部重新編碼成為 WebM。為使用 H.264技術而支付的專利費和這些翻番的成本比起來簡直是小巫見大巫。Google 財大氣粗能負擔這個成本，其他的視頻站點就難說了。
????? 即便忽略視頻站的成本問題，在客戶端上 WebM 和 H.264 能和平共處么？在桌面系統上，Chrome 和 Firefox 都可以通過Flash 插件播放 H.264，和原生支持 WebM 沖突不大。然而移動設備需要硬件解碼芯片支持。受至于成本和空間限制，很難想象理性的移動設備廠商會同時包含兩塊解碼芯片以支持 WebM 和H.264。另外一種可能是將來出現一種硬件解碼芯片能同時處理 WebM 和 H.264，不過目前還沒有任何這方面的消息。
????? 更加現實的可能是，即便 Chrome、Firefox、Opera 等不原生支持 H.264，大多數視頻站只需維持現狀：即對于桌面系統通過Flash 插件播放 H.264 視頻，而對不支持 Flash 的移動設備則通過 HTML5 視頻標簽播放 H.264 視頻。WebM最終淪為 Theora 一樣的下場。普通用戶也不會覺察到任何區別。基于這個判斷，不少蘋果派因而指責 Google 的做法只會推遲 HTML5 視頻標簽的普及，讓大家繼續在 Flash 這棵樹上吊死。
????? 然而 WebM 就一無是處了嗎？當然不是。如果 VP8 最終被證明沒有專利問題，那 WebM 也許能夠成為 HTML5 標準的一部分。雖然現在 VP8 不是效率最高、畫質最好的，但它很多時候也能滿足要求。新一代的互聯網創業者們在需要付費的 H.264和完全免費的 WebM 之間就有了選擇的余地。而正是眾多開源、免費技術的存在造就了互聯網繁榮的今天。只是，專利問題始終是 WebM 頭上揮之不去的疑云。
附：主流操作系統和瀏覽器的視頻支持
Wndows XP：需要播放器解碼插件。
Windows 7：原生支持 H.264/MP4 （如果顯卡和播放器都支持，可以硬件加速）。
Mac OS X：原生支持 H.264/MP4 （自帶播放器 QuickTime X 支持顯卡硬件加速）。
iOS：原生支持 H.264/MP4；不能使用 Flash 插件。
Firefox 3：原生支持 Theora；通過 Flash 插件支持 H.264；不能使用操作系統的視頻支持。
Firefox 4：原生支持 WebM、Theora；通過 Flash 插件支持 H.264；不能使用操作系統的視頻支持。
Chrome 9：原生支持 Theora、WebM、H.264；通過 Flash 支持 H.264；不能使用操作系統的視頻支持；視頻解碼無硬件加速（高清視頻費 CPU）。
Chrome 10：原生支持 Theora、WebM；通過 Flash 支持 H.264；不能使用操作系統的視頻支持；視頻解碼無硬件加速（高清視頻費 CPU）。
Safari: 原生支持 H.264；也可以通過 Flash 插件支持 H.264；使用操作系統的視頻支持和硬件加速。
Mobile Safari: 原生支持 H.264；不支持 Flash 插件；使用操作系統的視頻支持和硬件加速。
IE 6~8：通過 Flash 支持 H.264。
IE 9：原生支持 H.264；也可通過 Flash 支持 H.264；可通過插件支持 WebM。
總結
以上是生活随笔為你收集整理的利益交错-HTML5视频标准之争的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： STM32 GPIOx_CRL/GPIO
- 下一篇： JQuery之Ajax方法