麼麼直播的音視頻技術實踐和優化

2018年3月31日,「ZEGO Meetup 視頻直播+的技術實踐之道」第三期在上海成功舉辦,現場吸引了滿堂的直播行業從業者到場聆聽。會上,如預期同樣,麼麼直播前端團隊負責人黃銘新、即構科技資深技術專家和架構師冼牛、滬江CCTalk 音視頻架構師武海濱和塗圖TuSDK 研發技術總監王勝,這4位直播行業大咖給你們作了精彩分享。其中,麼麼直播前端團隊負責人黃銘新老師主要給咱們分享了麼麼直播這4年來,在移動端和Web端兩大平臺上踩過的坑以及優化經驗。本文是對他演講內容的整理。前端

 

null

黃銘新,麼麼直播前端團隊負責人web

 

嘉賓簡介:曾就任於每天動聽、英語流利說,如今麼麼直播負責前端開發團隊的team leader相關工做。技術上主要偏向於JS、Node全棧式開發,主要負責公司內的主站、內部服務和部分微服務的開發和管理。算法

 

--------------------------------------------------------------------------正文-----------------------------------------------------------------------------------瀏覽器

 

麼麼直播團隊是在2012年末進入直播行業的,那時直播還處於混沌期,不像如今有這麼多第三方直播技術解決方案商。麼麼直播平臺一切從零開始,和不少C端廠商一塊兒,一點點地研究一步步地推演直播技術,走了不少彎路。緩存

 

近兩年直播火爆後,涌現出了很是多的第三方直播解決方案。有些廠商專一於作相似雲端的解決方案,提供一些比較好的服務器和算法,來提升流傳輸的速度;還有一些是隻作客戶端的SDK,幫助企業更快速地接入到直播業務中去;還有像即構科技這樣的廠商,把兩部分結合在一塊兒,推出一整套解決方案,讓想當即接入視頻直播這個行業的公司和項目能夠迅速啓動。服務器

 

會上,黃銘新重點與咱們分享了麼麼直播在移動端和Web端推拉流研發中踩過的坑和優化經驗。網絡

 

null

麼麼直播前端技術負責人 黃銘新架構

 

移動端平臺的實踐與優化

移動端推流step1 

早期安卓手機總體性能偏弱,麼麼直播在移動端採用的是硬件編碼+rtmp dump的推流方式。ide

 

硬件編碼啓用了GPU,解放了部分CPU的計算能力,可以支持業務上的計算,同時還下降了整個手機的發熱量,間接延長了整個APP的使用時長,當時效果不錯。但隨着深刻使用和測試,麼麼直播和其餘競品比較還存在如下問題:微服務

 

1)畫面比較模糊。

 

2)碼率偏大。

爲了解決這一問題也進行了不少嘗試,但效果不甚理想,後來發如今Android內部,Google強制使用baseline的編碼方式,調整效果很差。

 

3) 硬件的兼容性差。

Android上的MediaCodec編碼器在不一樣手機和芯片平臺上的表現略有差別,各個硬件廠商對它的支持也不盡相同,致使兼容很是費時費力,而iOS就相對沒有這樣的問題。

 

4) 網絡推流不穩定。

針對直播端推流常常斷和觀衆端出現卡頓等問題,麼麼直播也作了一些優化。例如,當推流網絡堵塞時,會把還未發送的隊列內數據進行丟棄,以保證總體的延遲不會太大,同時也對播放器的緩存大小進行調整,以減少網絡不穩定形成的影響。

 

當時麼麼直播沒有專門從事音視頻研究的研發人員,作的以上努力使得性能效率有所提高,但和其餘競品相比仍是存在差距。

 

在那段時間,直播行業開始爆發性增加,慢慢涌現了一批第三方解決方案,麼麼直播決定去嘗試一些第三方的方案,但願可以解決一些痛點。

 

移動端推流step2

在找尋第三方解決方案的過程當中,麼麼直播團隊發現第三方提供商的一個共通點是——他們大部分採用軟件編碼+硬件編碼的解決思路。麼麼直播內部也開始按照這樣的思路進行嘗試,嘗試了一段時間後,總體性能有所提高,同時也發現了兩個問題:

 

1)低端機器的總體性能偏弱,致使視頻下載幀率不太穩定,沒有辦法穩定在20、30幀,有時候直接跳到100或個位數;

 

2) 採用了軟件編碼後,低端機器的發熱量大。

 

「咱們嘗試了軟件編碼+硬件編碼的這個解決方案,但發現這個方案也不成熟,而後咱們遇到了即構科技的方案。咱們在直播行業的前一到兩年裏摸爬滾打了好久,也嘗試了不少方案,但是畢竟沒有專門的音視頻人員去深刻地研究音視頻技術的性能問題,市面上通常的解決方案也常是東補一塊牆、西補一塊牆,很難全面的解決問題。在接觸到即構科技後,咱們發現即構能夠完善地解決以前碰到的問題,不管是在畫質、兼容性、卡頓頻率,仍是在加載速度、視頻的穩定程度上,直播的性能都獲得了很是大的提高,的確作到了業界領先的水平。」麼麼直播前端技術負責人黃銘新如是說。

 

null

 

移動端拉流

移動端的拉流相對簡單。麼麼直播早期使用的是Ijkplayer進行視頻流的播放,基本穩定,不需折騰,使用起來也正常。但隨着各家直播平臺性能的提高,麼麼直播的首屏加載時間相比較長,體驗差。在一樣接入幾個機型對比後發現,麼麼直播發如今拉相同流的狀況下,即構的播放器加載速度更快一些。因此最後,不管是推流仍是拉流,麼麼直播平臺都替換成了即構的解決方案。

 

美顏

如今,美顏是直播平臺必備的功能。麼麼直播最先在開發美顏功能時,並無那麼順利。起初即構的SDK並無把視頻流的原始數據開放出來,而美顏的SDK須要使用視頻流原始數據,而後進行再加工,因此最初碰到了整合的問題。經過溝通,即構決定開放他們的視頻流原始數據,提供內存和textureID兩種形式暴露數據,而市面上大部分的美顏相關的SDK都支持這兩種方式,因此美顏問題也獲得了順利解決。

 

Web端平臺的實踐與優化

Web端推流

web上主要有兩種推流方式,直接使用flash開播或者使用OBS軟件開播。麼麼直播沒有對OBS進行二次開發,因此在有限帶寬內,會給主播提供幾個碼率、分辨率的配置,依據不一樣的網絡環境自行進行調整,但是主播相對來講不肯使用。

 

黃銘新表示,不少平臺已經不太使用flash這種開播方式,但flash的推流方案在麼麼直播平臺是不少主播的選擇。麼麼直播平臺的主要業務集中在美女直播,相對鬥魚和其餘遊戲平臺所需帶寬的量小一些。這種狀況下,flash有先天優點。它最主要的優勢是方便,主播不須要進行額外的學習,直接上手,瀏覽器支持flash打開頁面就能用。不過這也帶來了另外的幾個問題:

 

1)flash自身的缺陷——對系統資源的消耗較大

 

2)flash不支持AAC編碼,只有Nelly Moser 和Speex 兩種音頻編碼格式,因此在同等的音視頻質量下,推流所需的帶寬較高。

 

針對這些問題,麼麼直播作了以下一些嘗試:

 

一、開發桌面端插件。簡單地說,就是開發一個第三方插件,主播開播的時候不走flash的推流流程,而是直接經過插件進行推流。這在必定程度上能解決上面的問題,可是不一樣PC的兼容性問題、開發成本以及主播的主觀能動性都使這一方案沒有繼續使用。

 

二、開發單獨的推流軟件。這點不少平臺都有在作。獨立的推流軟件穩定性高、性能好,而且可定製化程度也比較好,可是須要的研發資源和人力比較高,受制於當時團隊內部沒有這麼多的人力開發,最終否掉了這個方案。

 

三、服務端轉碼。在服務端對現有的流進行轉碼,這個其實已經應用得比較普遍了。最多見的就是將一路高清或者大碼率的流進行轉碼,而後拆分出幾路低清的流,上來的是非AAC的流,經過轉碼最終下行拉流的時候拉取的是AAC流。目前咱們也是使用服務端轉碼的解決方案。

 

Web端拉流

H5上使用的是hls進行拉流,經過轉碼就可以作到。因爲hls的特性,須要切片,因此延遲相對高。

 

pc端主要是使用rtmp和flv兩種流格式,麼麼直播平臺rtmp使用flash進行播放,flv使用js進行播放。

 

使用flash播放rtmp的流時,涉及到視頻的秒開時間、flash加載速度兩大性能指標。麼麼直播首先經過精簡播放器的體積,使其從原來的600多K減少到如今的19K;而後在前端頁面上採起分塊加載的策略,優先加載和播放相關的代碼或者文件。進行了這兩方面的處理後,視頻的秒開時間從原先的3-4秒降到了2秒內。

 

flv使用的是純前端js播放,經過使用最新的Media Source ExtensionsAPI,能夠把flv的視頻流經過前端轉碼,直接在頁面上經過video標籤進行播放,使其無需flash。

 

rtmp跟flv流的性能至關,因爲flv捨棄了flash,總體CPU消耗比原先下降了5%—10%左右,因此使用flv總體性能提高是較大的。而且,相對小的性能消耗能夠獲得和flash同樣的直播播放體驗。

 

關於即構ZEGO 

即構科技於2015年由QQ前總經理林友堯創立,A輪得到IDG投資,核心團隊來自騰訊QQ,匯聚了來自YY和華爲等廠商的頂尖語音視頻人才。即構ZEGO致力於提供全球最清晰最穩定的實時語音視頻雲服務,助力企業業務創新,改變用戶線上溝通方式。即構ZEGO深耕視頻直播、視頻社交、遊戲語音、線上抓娃娃和在線教育等領域,贏得了映客、花椒直播、一直播、喜馬拉雅FM、陌陌遊戲、自由之戰二、和好將來等頂級廠商託付和信賴。