QQ視頻直播架構及原理 流暢與低延遲之間作平衡 音畫如何作同步？

QQ視頻直播架構及原理 - tianyu的專欄 - CSDN博客 https://blog.csdn.net/wishfly/article/details/53035342

做者：王宇（騰訊音視頻高級架構師）

 

 

 自我介紹下，畢業以來加入騰訊，一直從事客戶端研發，身處互聯網公司，踏着互聯網的浪潮，一直在浪尖行走，從最先的PC QQ，到移動時代的手Q，再到騰訊物聯的嵌入式，以及最近這兩年直播領域風起雲涌，接下來主要給你們介紹下QQ視頻直播的架構及原理。

 

 

今天主要給你們介紹三個方面的內容，視頻直播的框架及基礎介紹；

直播中的一些關鍵技術：主要包括播放控制問題，性能與質量等；直播APP的總體解決方案

 

首先來看下直播先後臺的大體框架，經過推流App或者第三方推流器將數據推送給後臺服務器；

服務器將收到的數據進行轉碼發送給DC；

觀看者從OC上拉取對應的直播流進行觀看；

目前主要採用RMTP、HLS、FLV三種直播格式。接下來咱們重點看下直播過程當中客戶端架構。

 

 

這是直播客戶端的大致框。

左側是推流端：音視頻採集；預處理；音視頻編解碼；數據封裝網絡發送；

右側是播放端：網絡收數據；音視頻解碼；視頻渲染與音頻播放。

整個過程就是一個線性的流水化過程，流程看起來仍是比較簡潔的。

 

 

視頻編碼，就是一個壓縮的過程，如何將視頻數據壓縮後便於網絡傳輸，這裏有幾個緯度：

1.每一幀數據的幀內壓縮，也就是這裏的I幀，可以獨立還原出圖像數據，通常比較大；

2.連續的兩幀畫面之間存在類似性，參考前面一幀數據，只記錄差別部分，這樣數據量就比較小，也就是這裏的P幀，採用的是前向預測編碼；

3.更進一步，若是參考先後兩幀數據記錄差別部分，這樣數據量會更小壓縮率最高，也就是這裏的B幀，採用雙向預測內插編碼。

麥克風採集到的原始PCM數據通常比較大，以44.1k，雙聲道爲例，碼率大概有1M多，不作壓縮的話很難傳輸，音頻編碼，就是將採集到的PCM數據，根據不一樣的音頻格式進行壓縮，固然目的也是爲了在保證音質的前提下儘可能壓縮音頻數據，目前採用的是AAC來壓縮。

流媒體音視頻數據封裝格式，原始的編碼以後的音視頻數據不太利於網絡傳輸，目前有多種封裝格式：

1.RTMP協議，須要作拆包與組包，將每一個數據幀拆成小分片加上協議頭髮送，通常用於推流；

2.FLV格式，比較簡單每一個數據幀加協議頭，通常用於播放；

3.HLS格式，將一組音視頻數據組合在一塊兒，經過m3u8文體來關聯，至關於一個個的小文件，適用於網頁播放。

 

首屏秒開

流暢與延遲控制

實時音質同步

高分辨率性能

問題與質量監控

開放架構

 

直播的框架及基本原理就這麼簡潔，可是要作到好的體驗卻不是一件很簡單的事情，基本上幾我的花一兩個月就能作出來，可是要優化出一個好的效果須要長期的積累與打磨。

接下來主要看下直播過程當中的一些關鍵問題，主要包括：首屏秒開、流暢與延遲控制、實時音畫同步等等。

當咱們觀看一個直播的時候不能等半天才出畫面，體驗顯然不好，咱們指望的是可以立馬看到畫面，即首屏秒開。

首先來看下解碼過程：推流端上傳P幀，播放端拉到一個P幀，若是幀連續，能立馬解出來正常顯示；若是沒有以前的參考幀，而僅僅只收到了一個P幀，解析不出來不能顯示，直到遇到一個關鍵幀；若是要作到數據來了就能立馬顯示，對於首次打開就必需要能收到一個I幀，那麼問題來了，服務端如何保證返回給播放端的第一幀爲I幀？

假設有一我的正在觀看，推流端上傳一個P幀，服務器將其發送給播放端，播放端正常播放，同時服務器將其放到一個緩存隊列裏面；有了這樣一個臨近數據的緩存隊列，當有一個新的觀看者來播放的時候，就能夠直接從緩存隊列裏面取最新的一個GOP一次性返回給觀看端，此時播放端就能夠立馬解析出I幀渲染，這樣就能作到秒開。

 

 

 流暢與時延控制，對播放而言，來數據就播放，這個問題應該就這麼簡單，可是..

smoth

delay control

播放有兩類需求：

1.遊戲場景下更關注流暢性；

2.主播場景下更關注低延遲；

因而就有了流暢與極速兩種模式，流暢就是緩衝播放，極速就是來數據就播放，緩存大的時候就作速播；看起來還不錯，可是..

 

 實際使用發現流暢模式會帶來延遲大的問題，而極速模式卡頓的機率又比較高；有沒有一種更好的方案？這裏問題的根源在於網絡是抖動的，要保證低延遲的同時又能流暢播放，其實就是在流暢與低延遲之間作平衡；應該怎麼設計？

對於播放端而言，網絡來數據，本身播放，這就是一個生產消費模型，正常狀況是生產多少，消費多少，但網絡抖動引起卡頓與數據堆積從而形成時延。

這裏統計過去一段時間內的數據，有兩個指標：

1.待播放數據的大小反應時延，即這裏的過去一段時間內的AvgCache；

2.過去一段時間內的網絡抖動大小決定了待播放數據抖動的大小，也即決定了卡頓，即這裏的Jitter，Jitter隨時間推移而修正。

平均cache太大即延遲大，爲了消除延遲就須要快速消耗掉一部分數據，這裏要消耗掉多少數據呢？

理想狀況下是要調整到紅色曲線所示的，加速MinCache的數據，這樣既能保證不觸發卡頓又能作到最小延遲，可是這太理想化了，這裏須要更謹慎一些，因而作了如下調整：

1.引入最小閾值，如圖所示最多加速到這個程度；

2.不是一次加速到最佳狀態，設定最大加速時長。

總結下，統計數據決策加速；計算調整時長，恆定加速；如此循環，就能調整到一個最佳狀態，這就是自適應播放控制策略。

這裏加速有三種策略：

1.直接丟棄部分數據；

2.短時的快速播放；

3.長時的較快速的播放，讓人察覺不到在速播。

這裏問題的根本就是要多消耗一部分數據，毫無疑問不管是丟棄、快速加速、慢速加速都是有損的，三種方案各有優劣，瞬時的大損傷好，仍是長時的低損傷好？這裏仍是看我的喜愛，蘿蔔白菜各有所愛，最終仍是要看用戶反饋來選擇。既然作了速播，那不可避免會遇到音畫不一樣步的問題，如何解決？

音畫如何作同步？

經典的音畫同步有三種方案：音頻同步到視頻；音視頻同步到外部時鐘；視頻同步到音頻；

方案一音頻很難去頻繁的作調速，因此直接pass了；

方案二在卡頓的時候須要作時間修正，作加減速的時候保持步調一致不是很好處理；

方案三視頻同步到音頻比較天然，視頻可以很方便作調速處理，目前大多推薦的也是方案三，實現起來也比較簡單，接下來看下整個播放控制方案。

音視頻jitter隊列分開方便取數據，控制器根據jitter大小及當前策略來決定加速仍是正常播放；

音頻按需播放，在最末端，音頻將PTS同步給視頻，視頻據此修正當前幀的播放時機，解決音畫不一樣步問題；

引入一個負反饋機制來保證解碼後的數據不會太大；

聲音如何加速，聲音處理有變調變速，變調不變速，變速不變調，這裏採用了變速不變調算法來對聲音進行加速。

來看下實際效果，這分別是兩種損傷模型下的效果，左邊的是瞬時高損傷，右邊的是長時低損傷；能夠感覺下兩種的不一樣效果。

高分辨率下性能如何保證，360p通常都能達到比較好的性能，那麼問題來了，720P推流與播放、1080P播放性能如何保證？主要包括如下幾個方面：

1.整個系統採用多線程處理，推流與播放都是流水化的過程，每一個處理流程都採用獨立線程，每秒幀率徹底由單一處理過程的最大耗時決定，而不是整個流程的處理時間。

2.多核手機已經普及，採用軟編軟解可以在手機性能達標的狀況下完成高幀率編解碼。

3.目前手機基本都支持硬編硬解，對於高分辨率採用硬件編解碼，能夠顯著下降CPU佔用，提高性能。

4.能用GPU處理的儘可能用GPU來作，如本地渲染與鏡像處理、格式轉換等。

5.採用ARM指令集優化來提高性能，好比視頻裁剪、旋轉等算法。

既然作直播SDK，那麼有問題如何定位？直播質量如何監控？

這裏問題主要包括兩大類：

1.開發測試過程當中遇到的問題；

2.用戶現網問題；這裏直播質量主要包括CPU佔用率、卡頓率、播放延遲、上下行帶寬等等。

 

用戶遇到的問題如何怎麼定位，LOG確定是第一手資料，如何方便快捷的獲取到LOG？

這裏有一套LOG提取系統，三個步驟：獲取地址軟色、問題重現、提取log分析；這個就是咱們的LOG提取系統。

 

 

 

 

 

 

爲了監控直播質量，這裏作了完備的數據上報及分析系統，基本上涵蓋了各類關鍵性指標，既能反應直播的各類性能方便優化，同時也能輔助定位各類問題；這個是播放端的總體統計數據，下行帶寬、卡頓率、緩衝大小、CPU佔用率，這是一個宏觀統計數據，反應了當前直播觀看端的一個質量。

 

 有了直播質量監控，更精細一些咱們能夠作一些運營分析，好比說，最近咱們內部對一個遊戲直播的流暢性作了一個運營統計分析，把外網用戶分紅了三組，經過配置不一樣的播放端參數來統計質量，最後咱們得出了幾個比較有意思的結論：

 

這是對直播推流端作的一個質量評估，根據一些指標對每項進行打分，而後給出一個綜合得分來評估當前直播推流端的質量。

 

 

這個是直播後臺的整套大致框架。

上面主要是完成視頻的推流與播放，包含了接入集羣，計算集羣及CDN加速網絡；

下面主要是賬號、消息等基礎服務，及社交互動系統,咱們使用這些後臺服務構建了小直播的App。

 

小直播客戶端App及業務後臺源碼對客戶開放，提供了直播App的整套集成解決方案，基於此能夠很方便的完成一款直播App的開發。

 

 

這個就是咱們作的小直播App，能夠在官網下載體驗。

 

QQ視頻直播架構及原理 https://www.toutiao.com/i6348560415894536705/

直播 | 編風網 http://www.befoio.com/category/live