本次演講由騰訊進階工程師陳映平為大家介紹基于WebAssembly的H.265播放器，以及在NOW直播中的應用。本次主要介紹采用WebAssembly制作音視訊H.265播放器的整體思路、播放器架構設計以及線上實踐。
演講嘉賓簡介：陳映平（程式猿小卡）， 騰訊進階工程師，IVWEB團隊負責人之一。
本次分享主要圍繞以下五個方面：
一、方案背景介紹
二、方案選型
三、播放器架構設計
四、線上實踐
五、未來展望
1.直播行業概況
下圖為互動直播行業從2003年至2016年的發展變化曆程。2003年至2008年，語音直播行業比較受歡迎，平台有YY語音直播、QT等。2008年至2011年PC聊天室場景逐漸火爆，廣受歡迎的有9158、六間房。2011年至2014年，秀場直播異軍突起。2014至2015年，垂類直播開始火爆。垂類直播主要指集中在某些特定領域和特定需求，以直播形式提供相關資訊與服務的直播，例如遊戲直播等。主要平台包括虎牙、龍珠等。2015年移動直播出現，2016年被稱為直播元年。2015年開始我國提倡大衆創業、萬衆創新，市場上湧現衆多資本。由于直播行業盈利強勁，資本紛紛湧入，出現千團混戰局面。代表廠家包括虎牙直播、企鵝電競、花椒直播、NOW直播等。
2.直播行業成本支援
内容：直播内容成本包括聘請優質主播等花費。
薪酬：企業員工薪酬成本。
帶寬：根據部分上市公司（例如虎牙）的統計材料，帶寬成本比重大約為10%~30%。對于部分小企業而言，内容成本比大企業低，帶寬成本可能占總成本40%甚至50%以上。目前國内帶寬計費方式通常有兩種。一是根據使用量計費。例如觀看一天視訊，則根據當天消耗流量的總量計費。二是峰值帶寬收費，即根據流量速度峰值計費，直播行業一般采用峰值帶寬收費。下圖所示為國内某知名雲服務廠商的帶寬流量計費方式，峰值帶寬計費。例如某天遊戲總決賽直播峰值帶寬為3.5T，按照下表收費即為3.5*1024*1024*0.58=212W元。即一場比賽當天帶寬成本就達到212萬元，帶寬成本高昂。
一些大公司會與雲服務廠商簽訂戰略合作協定，帶寬收費可能會比對外公開價格低。下圖為虎牙直播2018年Q3至2019年Q3的帶寬支出情況統計。2018年Q3虎牙直播帶寬支出為1.74億，2019年Q3支出為2.1億。同比增長率由66.8%降低至21%，這是虎牙直播帶寬成本優化的結果。
3.直播方案需求
直播行業在技術選型時需要考慮如下因素。
延遲：互動延遲會影響使用者體驗，解決直播互動延遲問題十分重要。
成本：内容、薪酬、帶寬等成本。
性能：關鍵名額包括音視訊播放時的CPU占用、記憶體占用、卡頓、幀率等。
擴充性：音視訊直播行業出現至今，音視訊編解碼領域飛速發展，經常釋出更新編解碼協定。如果播放器架構擴充性設計不好，一旦編解碼協定更新或替換，就可能需要重構播放器架構，于業務方而言是難以承受的。
1.常見直播協定
RTMP、HLS、HTTP-FLV都有各自的應用場景。
HLS：HLS在移動端使用非常多，是蘋果主導的一個規範。HLS的特點是可以自适應碼率以及帶寬狀況。例如可以根據手機的網絡情況自動切換到不同的碼率，可以使使用者在4G、3G等不同網絡條件下正常觀看直播。
RTMP：Adobe公司的私有協定，特點是延遲比較低。RTMP的缺點，首先作為私有協定，協定細節部分為黑盒，出現問題時難以排查。第二是RTMP使用的不是标準80端口，會導緻一些問題。例如一位直播觀衆需要在校園網環境觀看直播。衆所周知校園網絡有各種保護措施，如防火牆等會屏蔽一些非标準端口。此時不适合使用RTMP觀看。RTMP協定較适合做推流。例如主播需要在直播間裡進行直播，那麼可以采用RTMP進行推流。即将直播流采集後上傳到伺服器，然後給使用者觀看。
HTTP-FLV：協定棧與RTMP相似。HTTP-FLV與RTMP内部資料封裝都基于FLV Tag。HTTP-FLV的延遲介于RTMP與HLS之間。同時HTTP-FLV使用的是标準的HTTP協定，端口是80标準端口，網絡穿透性較好，是以一般在觀看端會采用HTTP-FLV。過去幾年，由于浏覽器不支援FLV的原生播放，許多時候需要借助Flash播放器進行播放。bilibili出品的flv.js，采用MSE解碼播放的方式達到對HTTP-FLV的支援。
2.視訊編碼簡述
由于流量的重要性，需要降低視訊對帶寬的占用。如下圖，視訊是由一個一個的視訊幀構成的。例如每秒播放20視訊幀，連續播放就形成視訊。視訊幀在編碼層面又是由一個一個的切片組成的。視訊編碼首先将視訊幀分塊為多個視訊切片，然後采取幀内預測等手段對視訊切片進行壓縮。實際壓縮效果較下圖圖示更加優秀。
視訊編碼技術的重要性：舉例說明直播視訊的資料流量消耗。下圖所示直播頁面寬高比為540 * 960，每秒15幀。每一個像素由三個通道組成，每一個通道占8bit。則一分鐘資料量為540 * 960 * 8 * 3 * 15 * 60bit。轉化為Mb為1334Mb，即一分鐘直播流量約1.33G。如果視訊的帶寬消耗的确為上述程度，多數人應該不會在資料流量環境下觀看視訊。是以通過視訊編碼來壓縮視訊尺寸十分重要。對視訊采用H264進行編碼，上述一分鐘時長1334Mb尺寸的視訊壓縮後尺寸僅為11Mb。視訊編碼壓縮的效果比前文圖示效果更為顯著，帶寬費用降低至不到原來的1%。
視訊編碼技術的發展：下圖為音視訊編碼技術發展曆程。1992年ISO/IEC（專家工作組）釋出MPEG-1标準。MPEG-1主要為VCD服務。1994年MPEG-2釋出，主要服務于DVD。MPEG-3釋出目的是為HDTV服務，後發現MPEG-2已經滿足該需求，是以廢棄MPEG-3，并将其優化部分并入了MPEG-2。1998年釋出MPEG-4标準。2003年ISO與ITU聯合釋出了一個非常重要的标準H.264。H.264與AVC是同一個東西，是在MPEG-4 Part 10中定義的。2012年由谷歌主導的VP9釋出，其被定位為下一代的視訊編碼解決方案。VP9在H.264基礎上進一步壓縮視訊帶寬的占用，目标是提升50%左右的帶寬。目前國内VP9的應用相對較少。2013年ISO與ITU聯合釋出H.265，相較于H.264進一步提升了帶寬。
3.選擇H.265
特點：首先在相同碼率條件下H.265視訊畫質更高。第二，壓縮效率更高：例如同時觀看同一份分别采用H.264和H.265标準編碼的視訊，H.265節省更多帶寬，平均能達到30%~ 50%。第三，由于H.265壓縮效率高，是以碼率要求更低。下圖為同一個視訊的流量對比，由于根據不同視訊優化帶寬能力不同，是以下圖沒有具體比重或數值。整體上H.265較H.264節省30%以上的帶寬。
原因：H.265壓縮比較H.264高很多是因為H.265優化了非常多的技術細節。如下圖，以對視訊分塊壓縮過程為例。H.264會将下圖分為若幹16*16的宏塊，然後對其進行編碼。采用例如計算殘差等一系列壓縮手段。H.265整體播放設計架構與H.264沒有太大差異，同樣采用混合編碼架構，同時采用的編碼壓縮的優化手段也差不多，可能會支援更多幀間預測的方式等。H.265支援了更大的宏塊，以及可變的宏塊。例如下圖左上角黑色區域，視覺效果烏黑一片。如果采用H.264編碼方式，雖然其像素RGB值完全相同，但是編碼為許多像素款。而使用H.265編碼方式，當該區域RGB值接近，可以直接采用64*64的宏塊提高壓縮效率。
浏覽器支援情況差問題：如下圖，諸多浏覽器不支援H.265。H.265是由多個廠商聯合釋出的标準，同時釋出廠商對于H.265涉及的專利如何進行收費沒有統一的标準。例如起初使用者使用H.265标準進行視訊編碼并不收費，産品上線一年規模擴大之後，可能突然收到律師函通知使用者專利費欠款上千萬。據不完全統計，H.265一年的專利授權費在1億美元以上，價格非常高昂。是以H.265沒有推廣開來并不主要是技術方面的原因，而是專利授權方面的原因。相比之下H.264收費公開透明，也較H.265低。
4.方案選型
如果需要在浏覽器中支援H.265編碼标準，應該做哪些準備。
業界方案參考：下表所示為業界支援H.264等标準的方案參考。flv.js基于HTTP-FLV協定，解碼方式為MSE軟解。支援音頻播放，支援H.264标準。不支援并且不打算支援H.265。libe265.js基于WASM H.265解碼方案，H.265 C庫基于libe265。現已支援視訊播放，但不打算支援音頻播放、流媒體等。
解碼方案對比：MSE複用現有能力方面，如果要支援H.264，需要自行實作解碼算法，擷取H.264的視訊資料，再重新編碼為浏覽器可支援的格式。如果要支援H.265也一樣。WASM複用現有能力比MSE好很多。WASM可以将采用C/C++編寫的一些庫轉化為浏覽器可支援的WASM子產品。是以隻需要做非常少量改動甚至無需改動就能在浏覽器中複用現有能力，例如FFMpeg。性能方面，MSE采用js對視訊進行軟解，是以性能一般。WASM性能中等，仍在優化。MSE可維護性非常差，每當新加一種編碼就需要重新實作解碼方式。WASM可維護性好。
最終方案：在業務場景中采用HTTP-FLV+WASM+FFMpeg+H.265解碼方案。WASM是可在浏覽器運作的高性能子產品，可以采用傳統強類型語言如C、C++等進行編寫，再編譯為浏覽器可識别的高性能子產品。FFMpeg為跨平台的音視訊錄制、轉碼解決方案。FFMpeg功能複雜，方案中主要利用其編解碼功能。WASM浏覽器支援情況如下圖。使用者可根據産品支援平台的需要等判斷WASM是否适用。
1.直播通用架構
傳統直播由主播到使用者的鍊路架構如下圖。主播開播、打開裝置進行音視訊采集、音視訊編碼、采用流媒體協定進行封裝以在網絡上傳輸、推向音視訊服務。
2.FFMpeg核心編解碼流程
3. H.265播放器解析、播放流程
解碼器初始化後，會在解碼線程中進行一定的流緩存，存儲到一定量的資料後再将資料發送給解碼器。否則解析過程可能出現問題。例如資料發送給解碼器後，解碼器首先需要确認資料的編碼，第二确認音視訊幀率，第三确認視訊的寬、高，若缺少以上初始化資訊，可能導緻解碼出錯。接下來進行解複用。然後進行視訊解碼以及音頻解碼擷取視訊幀與音頻幀資料。将音視訊資料發送至浏覽器播放之前，需要進行時間戳對齊，否則會導緻音畫不同步等問題。最後進行播放。
4.播放器整體架構
最底層：主線程，包括播放器執行個體、線程排程、資料中轉以及統一的控制邏輯。
上一層：兩個核心線程，包括IO線程以及解碼線程。
中間層：播放器的核心環節，借助WASM以及FFMpeg對音視訊資料進行解封裝以及解碼。
中上層：基于播放器的工具。例如在播放器中可能包括播放工具欄、用于展示流媒體資訊的媒體面闆。比如展示視訊地區、寬高、幀率、碼率等。
頂層：播放及渲染。
1.資料驗證
如下圖，實驗1為本地測試播放15分鐘視訊的平均CPU及記憶體占用分别為181.96MB以及34.98%。實驗二為H.265與H.264觀看同一直播間15分鐘的對比情況。H.265占用流量減少30%左右。
2.典型問題
FLV規範如何支援H.265：
在FLV Tag中存在一個關鍵的CodeID字段，辨別了FLV Tag中視訊資料的編碼。然而FLV規範中還未明确指出H.265應該采用哪個CodeID。目前騰訊雲等用于辨別H.265的CodeID為0x12。
音畫不同步：每一個音頻幀與視訊幀都包含PTS資訊，用于辨別音頻幀與視訊幀應在哪一個時間進行播放。由于視訊與音頻分開播放，如果二者PTS不同、出現明顯偏移，就會導緻音畫不同步。根據ITU的規範，設定Diff值為音頻與視訊PTS值差異。如下圖，當Diff值在不同範圍内，的音畫差異可分為無法感覺、可以感覺、無法忍受等程度。當Diff值在-125ms至45ms範圍内，可視為音畫同步。故解決音畫不同步問題由此着手。
第一種方案：音頻幀與視訊幀進行對齊，音頻幀根據視訊幀播放進度對齊播放。
第二種方案：視訊幀與音頻幀進行對齊，視訊幀根據音頻幀播放進度對齊播放。
人耳對流式音頻更敏感，容易察覺到不連貫。人眼對視訊幀重新整理相對不敏感，不易察覺。故采用方案二。設定diff值為PTS（視訊）-PTS（音頻），當diff值在正負min值内，允許播放。當diff值大于max值或小于min值，丢棄音視訊。當diff值處于min值與max值之間，說明視訊幀解碼速度較快，音頻幀還未跟上，暫時緩存在本地，當解碼完成後再進行播放。
1.完善的WEB音視訊播放能力
支援直播、錄播；支援多種流媒體協定，如FLV、HLS、WEBRTC等；支援多種編碼格式，如H.264、H.265、VP9、AV1等（AV1是VP9的更新版本，由包括谷歌、微軟、騰訊等大廠商主導的規範）；支援擴充選項，如截圖、濾鏡等。
2.定制化能力
可根據使用場景選擇、組合播放能力。抹平不同流媒體協定API之間的差異，開發者實作無縫切換播放方案。