中國已在2016年進入直播+時代，這種成本低廉、互動性高、部署便捷、穩定可靠的娛樂方式，最初僅僅局限于游戲直播和在線聊天，而隨著互聯網的逐漸發展，泛生活類、娛樂類直播也開始逐漸流行。

　　親加通訊云CTO郝飛接受CSDN邀請繪制了直播技術知識圖譜，創建直播技術知識庫，幫助廣大開發者更加系統、全面的學習直播技術。

　　CSDN：請先簡單介紹一下自己

　　郝飛：有5年移動互聯網創業經歷，15年軟件開發經驗，在流媒體，音視頻編解碼，VOIP和視頻會議方面有豐富的產品和研發經驗。2011年作為聯合創始人成立了親加團隊，帶領團隊創建了國內首個即時通訊云平臺服務。

　　CSDN：請問你是如何與直播技術結緣的?

　　郝飛：我一直在從事音視頻相關的工作。最開始主要做音視頻編解碼器的優化，也涉及到Windows 平臺下的多媒體開發。當時公司開發的無線數字電視接收棒，在2008奧運期間很好的滿足了移動辦公者看奧運的需求。后來到百視通，也主要負責移動智能手機的點播直播業務。親加通訊云成立后，我們的服務首先覆蓋了文本，圖片，語音短信的即時通訊需求，隨著行業的繼續發展，很多應用迫切需要視頻的交互，因此親加盡快提升了平臺能力，目前支持包括實時音視頻，直播等視頻交互方案。

　　CSDN：分享一下直播相關的技術及架構

　　郝飛：直播涉及到很多環節，從音視頻采集，編碼，媒體流封裝，網絡轉發，再到播放端接收，解碼，播放，其中每個環節都涉及很多細節，其基本的結構圖如下：

　　直播技術結構圖

　　具體解釋如下：

　　音視頻數據分別進行采集和編碼;視頻數據的采集方式包括攝像頭，桌面，圖片，視頻文件，以及帶視頻采集的各類設備;

　　音視頻數據經過編碼后根據封裝格式進行復用處理，然后封包后發到流媒體服務器;目前通用的直播協議采用的是RTMP;

　　云端的數據分發使用CDN網絡，CDN的作用主要包括兩點：第一是保證用戶請求流媒體的網絡質量，CDN 會選擇離用戶最近的節點為其提供服務; 第二是通過流媒體服務器的級連方式保證大并發用戶的支持;

　　媒體流在云端除了進行轉發，還要進行轉碼，切片(HS)和錄制等處理;轉碼可以支持多種分辨率格式，從而滿足不同屏幕對不同分辨率碼流的要求;轉HS協議主要是為了支持手機H5 端觀看;同時，碼流會被錄制下來，供以后點播使用;

　　觀看直播的用戶根據接入運營商信息和位置信息會得到就近的CDN 節點，后續的流媒體數據就是通過此服務節點進行拉取的。

　　CSDN：請你談談有關直播技術架構的改進思考

　　郝飛：目前普遍使用的直播技術是一種單向的流媒體傳輸技術;因此，互動在直播的場景中就顯得格外重要，這也是聊天和連麥等互動技術淺淺成為直播標配的原因。其中，聊天是獨立于直播的單獨服務，對直播架構沒有影響;但連麥功能，其實會影響到直播本來的架構，支持了多人連麥后，其架構如下：

　　具體說明如下：

　　主播端加入視頻會議系統;此處注意，主播端不再直接推視頻給CDN;

　　視頻會議系統把主播的視頻流推向CDN，觀眾通過CDN觀看主播視頻;

　　參與連麥的觀眾登錄到與主播端同一個視頻會議頻道中，此時主播端和連麥者通過實時的視頻會議進行交互;主播與連麥者的視頻，經過服務端混合后輸出給CDN;

　　其他用戶通過CDN觀看主播與連麥者的交互。

　　大家可以看到，在流媒體服務器之外，整個架構中多了一個Conference Server，這個服務實現了連麥者之間實時音視頻交互的功能，同時，它還要把這個交互的畫面合成后分發給CDN; 這是對傳統直播流程的一個改進;

　　另外，目前的直播普遍采用的是RTMP等協議，其系統延遲在3秒左右，但越來越多的直播業務期望更低的延遲，這樣就不會出現直播視頻與聊天信息不同步等尷尬的事情。如果用戶端與媒體服務器的傳輸協議修改成UDP協議，并且做好糾錯與丟包補償等處理，這樣就可以大大減少系統的延遲，能夠控制在一秒以內，同時，再通過負載分配支持大量級用戶的接入，相信這樣低延遲的CDN方案是很多用戶所期望的。

　　CSDN：直播過程中，如何防止丟幀和卡頓的發生，提高QoS?

　　郝飛：目前國內的直播大多使用RTMP和Http-FV協議，它們都是基于TCP的，因此不會出現丟幀的現象。但卡頓是很有可能出現的，卡頓產生的主要原因是播放端拉取的媒體流不足以滿足流暢播放所需要的數據量，這往往是網絡原因導致的�？赡艹霈F的環節包括：

　　主播端上傳的網絡：如果主播端上傳網絡出現問題，不能保證流媒體即時的發送，則所有觀看端都會出現卡頓的問題;

　　CDN分發：CDN節點之間需要轉發流媒體數據，如果某一個轉發節點的網絡出現問題，將會影響所有連接此節點用戶的播放質量;

　　播放端網絡：如果播放端自身網絡不夠好，那么即使CDN已經分配了就近節點，這個用戶依然會出現卡頓的情況。

　　因此，如果要避免卡頓，需要同時監測以上幾個環節。主播端和播放端都可以通過監測客戶端網絡，把實際網絡發送接收情況上報給服務器，從而在服務端快速定位到卡頓情況的發生。同時，以第三方CDN監控服務作為輔助，監測CDN節點的服務質量和穩定性，這樣就可以盡早發現和定位卡頓問題，提高QoS了。

　　CSDN:分享一下視頻直播秒開背后都運用到了哪些技術?

　　郝飛：所謂的秒開就是從點擊直播節目開始到出現第一幀圖像的時間控制在一秒以內，有了這種體驗，用戶使用起來才會感覺足夠順暢; 如何才能達到秒開的效果呢?首先我們來分析下第一幀視頻顯示前需要哪些步驟。

　　視頻顯示前的準備步驟：

　　1. 播放器首先通過DNS解析來獲取流媒體訪問節點;

　　2. 播放器與最近的流媒體節點建立連接，然后根據所使用的協議進行握手;

　　3. 從CDN節點接收流媒體數據后，Demux從流數據中區分出音頻和視頻的數據信息，分別交給音視頻解碼器;

　　音視頻解碼器進行解碼操作;對于視頻來說，由于B幀和P幀都要參考I 幀，因此解碼器解碼的第一幀必須是I 幀;第一個I 幀以前的視頻數據都稱為無效數據;

　　音視頻解碼后的數據發送給上層payer進行同步播放。

　　從以上流程中，大家可以了解到，通過以下方面的優化可以減少第一幀圖像顯示的時間：

　　(1)DNS解析優化

　　可以考慮在空閑的時候使用Ping 命令獲得域名對應的IP，從而減少域名解析時間。

　　(2)傳輸層使用UDP

　　使用UDP的優點是連接建立速度快，流傳輸效率高;缺點是應用層需要解決網絡丟包的問題;目前大部分CDN 不支持UDP 協議的直播。

　　(3)使用Http-FV協議替代RTMP協議

　　目前播放端直播協議主要包括HS，RTMP，HTTP-FV，其中HS延遲比較大，直播類App 更傾向于使用RTMP 和HTTP-FV協議，他們的延遲基本上在一個數量級;從滿足秒開的體驗來看，建議使用HTTP-FV 協議，相比于RTMP，FV的握手協議要簡單很多，下圖為兩種握手協議的對比：

　　RTMP和HTTP-FV對比圖

　　(4)服務端GOP數據緩存，減少播放端拿到無效流數據

　　由于播放端必須拿到I幀后才能夠開始解析，因此服務端緩存GOP 數據后，可以避免與播放端無效數據的傳遞;從而減少秒開的時間。

　　CSDN：談談WebRTC在音頻通話開發中的使用?

　　郝飛：以下為音頻通話的基本原理圖：

　　CSDN：直播的美顏和水印等預處理都有哪些方案?

　　郝飛：目前的美顏效果主要就是磨皮和美白。磨皮的本質就是模糊，常使用的算法包括高斯模糊和雙邊濾波，后者在邊緣上的處理效果會更好些。這些算法的實現在GPUImage這個開源項目中都有，可以很容易的集成到應用中，但是簡單的濾波算法還不足以滿足大家對美顏的要求。親加的美顏經過了三個版本：

　　第一個版本的實現就是使用雙邊濾波，其特點是運行速度很快，但是效果一般;

　　第二個版本使用了雙邊濾波+膚色檢測+輪廓識別+亮度調節的濾波組合; 其美顏效果很不錯，但問題是性能開銷太大了，中檔以下機型會有些卡頓，并且發熱量大;

　　最后的版本采用的單濾鏡+亮度膚色調節，此版本兼顧了性能與效果，性能上與第一個版本類似，效果上與第二個版本類似。

　　以下是三個版本的美顏效果對比：

　　水印是直播中常見的功能之一，它可以用于簡單的版權保護和廣告設置。目前，國家出于監管的需要，也規定視頻直播必須打上水印。其實現一般是在主播端或者服務端實現，很少在觀看端實現。因為如果放在觀看端，可能會有些惡意競爭者直接拿到未加水印的視頻流，這樣就起不到數字保護的作用了;視頻內嵌水印的實現比較簡單，就是水印圖片與視頻圖片的合成，大部分圖像處理的庫中都包含這個功能。

　　CSDN:在直播中如何做到完美的交互體驗?

　　郝飛：直播是數據的單向流動，而在很多應用場景中，只有讓用戶參與起來，形成主播與用戶，用戶與用戶之間的交互，這樣才更能體現直播的價值; 在實際應用中，不同場景對交互有不同的需求，以下幾種交互滿足了大部分場景的交互需求;

　　1，支持超大用戶群的，內容可監管的互動聊天室

　　聊天室目前已經成為了直播的標配功能，簡單的實現一個聊天室并不難，但如果要支持幾十萬人同時在線的低延遲聊天場景就會比較困難了。同時，對于很多場景來說，聊天內容是一定需要監管的，傳統的監管手段包括關鍵詞過濾，踢人，禁言等，其中關鍵詞過濾屬于事前監管，踢人和禁言屬于事后處理。而事前監管中，還有一種稱為“審核”的功能，也是非常有用的。在審核的流程中，用戶的發言必須通過審核員的檢查，通過審核的其它用戶才能看到。

　　2，連麥功能

　　在一對多直播中，用戶只能觀看，無法參與，而連麥功能使視頻不再只是單向的輸出，而變成了雙向交互的升級形態，從而給用戶帶來更多的參與感，其流程如下：

　　正在直播中的節目進入到了互動的環節，節目需要選出在線觀看的一位觀眾參與到互動中;在線觀看直播的用戶申請參與互動;主持人同意用戶的申請，這時用戶與主持人實時進行音視頻交互，交互過程直播給所有其他觀眾。

　　3.基于視頻內容的互動

　　之前提到的互動方式都是獨立于視頻的單獨的交互系統，基于內容本身的交互更能吸引用戶的參與。例如在直播美妝的過程中，當某一個品牌的化妝品出現后，同時彈出此化妝品相關的介紹和購買鏈接，對此化妝品感興趣的用戶可以立刻進行購買。這種交互的實現原理就是在流媒體中嵌入附加信息，

　　為了保證用戶觀看時附加信息能夠與畫面進行嚴格的同步，這種附加信息最好嵌入在流媒體中(可以在視頻編碼或者流媒體協議封裝環節)，而不是通過消息通道通知到觀看端，因為每個觀看端的進度不一樣，很容易出現不同步的情況。

　　用戶可以根據直播場景的不同，選擇以上幾種交互方式，從而讓直播體驗更加完美。

　　CSDN：在移動直播過程中遇到過哪些坑及如何優化?

　　郝飛：移動直播開發中，經常會碰到以下幾類問題：

　　1.系統延遲大，特別是累積延遲高，播放時間越長，延遲越大

　　影響延遲的環節包括音視頻預處理，編碼，CDN分發，拉流，解碼等;其中預處理，編碼和解碼引入的延遲與設備硬件相關，可以通過提升設備性能優化。而CDN分發和拉流所引入的延遲則是網絡環境決定的，CDN轉發的節點越多，則延遲越大;播放端與CDN節點之間的出現丟包，網絡抖動等，也會導致延遲增加。針對于累積延遲，播放端可以采用動態追幀的方法，在盡量不影響視頻質量的前提下進行丟幀處理;同理，主播端如果發現也有視頻幀累積的現象，也可以考慮丟幀處理，前提也是盡量不要影響視頻質量。

　　2.播放出現卡頓情況，影響用戶體驗

　　視頻的卡頓主要是客戶端和CDN之間的網絡環境導致的。如果主播端上行網絡環境不好，則所有觀看端都會受影響，可以考慮通過減少幀率或者動態調節碼率的方式保證主播端推流穩定;如果CDN的某個分發節點出現問題，則路由到此節點下的所有客戶端都會觀看都會受到影響;這種情況可以通過采用第三方監控，或者收集客戶端卡頓報告的方式盡早發現并修復;如果某個客戶端的網絡環境不好，則主要影響此用戶觀看體驗，一般的視頻流在服務端都會轉成不同碼率的幾路視頻，播放端可以動態的切換到低碼率，從而保證觀看的流暢性。

　　3.視頻啟動慢，用戶體驗差

　　播放啟動慢會嚴重影響用戶體驗;解決辦法可以參考以上提到的秒開的實現。

　　4.Android機器適配不夠，出現崩潰，閃退等現象

　　Android 機型比較多，各種品牌機器的硬件參差不齊，同時，直播還會使用到硬件編解碼，而這些硬件特性也依據Android的版本和機器的不同而各有差異。 因此，建議大家在選擇直播SDK的時候，盡量選用被廣泛使用的，能夠提供現有手機適配列表的版本，這類SDK已經經過市場證明，出現崩潰和閃退的概率會低很多。

　　5.主播手機發燙，畫面卡頓，特別是增加美顏特性后

　　直播涉及到音視頻預處理，編碼，特別是美顏功能等耗CPU資源的操作，因此會出現手機發燙等情況，特別是低端的手機。 建議主播端盡量采用高端些的手機，這些手機不僅僅是CPU能力強，同時還支持硬件的編解碼功能，可以大大降低手機的功耗。同時，美顏實現的不同對于發熱的減少也很有幫助，具體可以參考上面的美顏介紹。

　　CSDN:您覺得直播技術的入門門檻高嗎?

　　郝飛：如果是在應用中嵌入直播功能，僅從應用的角度理解直播的流程，這個技術門檻并不高，一般的應用開發者，通過調用直播平臺的接口就可以很快速的把直播功能嵌入到系統中了。

　　CSDN:關于技術學習您有什么心得?我們上線了知識庫系統化學習的方法，您會怎么應用呢?

　　郝飛：總的來說，技術學習應該從深度和廣度兩方面來不斷加強。技術的細分領域很多，任何人都不可能精通所有技術，所以首先要根據自己的實際情況確定一個技術方向，然后通過看書，網上找資料，實際工作中的項目等方式來建立起自己在這個領域的知識結構圖。在這個過程中，你會發現有些學到的知識在實際工作中使用不到，那這部分就僅僅停留在理論層面，沒有充分了解和吸收，這時候可以考慮參與相關的開源項目并進行知識總結分享。通過這樣的方式與更多的開發者互動起來，對自己的知識結構可以起到重構和完善的作用，到了一定程度后，對于如何學習，學習什么這些問題你就有自己的答案了。當某一個領域研究的比較深入后，可以橫向擴展一下，把與這個領域相關的其他知識也涉獵一下，這樣你會對整體流程的把握更加清晰，會從更全面的視角審視你開發的系統。

　　親加視頻直播交流群：114834361，致力于幫助企業開發者快速進入“直播+”大時代。