音視頻技術學習

　轉自http://www.javashuo.com/article/p-fepvsiif-eo.html

音視頻SDK開發包涉及的技術要求
音視頻軟件開發，也叫音視頻即時通訊開發。隨着互聯網的發展，天天都有至關多的人在使用各類網絡交流工具，如MSN，騰訊QQ，ICQ，新浪微博。
然而目前大部分網絡交流工具都仍是以文字爲主，語音視頻功能大部分仍是不夠成熟，徹底經過網絡實現語音視頻須要考慮到不少方面，如：硬件、軟件、技術、網絡;等等。所以，即時通信軟件開發誕生了。
簡而言之，即時通信軟件開發就是經過開發一套跨平臺的即時通信音視頻解決方案，也就是雲智真音視頻SDK開發包，它是基於先進的H.264視頻編碼標準、AAC音頻編碼標準與P2P技術，整合音視頻編碼、多媒體通信開發技術而設計的高質量、寬適應性、分佈式、模塊化的網絡音視頻互動平臺來知足人們的即時通信需求。跨平臺實時雲通信音視頻解決方案詳解

即時通信開發涉及到的技術領域十分普遍，主要涉及如下幾個領域：
一、網絡技術：
即時通信講究的是點對點，或者一對多的通信。所以，P2P(點對點技術)做爲一種網絡新技術進入即時通信開發人員的視野。針對可不通過服務器中轉的音視頻應用，採用了P2P通訊技術，該技術的核心在於防火牆的穿越。使用P2P通訊技術，能夠大大的減輕系統服務器的負荷，併成幾何倍數的擴大系統的容量，且並不會由於在線用戶數太多而致使服務器的網絡阻塞。支持UPNP協議，自動搜索網絡中的UPNP設備，主動打開端口映射，提升P2P通訊效率。
二、視頻技術：
目前最早進的視頻技術非H.264莫屬，H.264最大的優點是具備很高的數據壓縮比率，在同等圖像質量的條件下，H.264的壓縮比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。H.264具備許多與舊標準不一樣的新功能，它們一塊兒實現了編碼效率的提升。特別是在幀內預測與編碼、幀間預測與編碼、可變矢量塊大小、四分之一像素運動估計、多參考幀預測、自適應環路去塊濾波器、整數變換、量化與變換系數掃描、熵編碼、加權預測等實現上都有其獨特的考慮。
三、 音頻技術：
選擇AAC是最好的即時通信音頻編碼標準之一。
AAC於1997年造成國際標準ISO 13818-7。先進音頻編碼AAC開發成功，成爲繼MPEG-2音頻標準(ISO/IEC13818-3)以後的新一代音頻壓縮標準。
AAC主要可能的應用範圍集中在因特網網絡傳播、數字音頻廣播，包括衛星直播和數字AM、以及數字電視及影院系統等方面。AAC使用了一種很是靈活的熵編碼核心去傳輸編碼頻譜數據。具備48 個主要音頻通道，16 個低頻加強通道，16 個集成數據流, 16 個配音，16 種編排。​
四、API接口技術：
即時通信開發必須採用動態緩衝技術來適應不一樣網絡環境(局域網、企業專網、互聯網、3G網絡)，根據不一樣的網絡狀態動態調節相關參數，使得即時通信平臺在多種網絡環境下均有良好的表現，並特別針對互聯網、3G網絡等應用場合進行優化，爲上層應用提供視頻質量的動態調節接口、音頻質量的動態調節接口。
五、保密技術：
即時通信平臺比較通用的保密技術有：
a、自定義服務器端口。服務器所使用的TCP、UDP服務端口都可自定義(在服務器的.ini文件中配置)，實現服務的隱藏;
b、加密傳輸服務器與客戶端之間的底層通訊協議。
c、服務器設置鏈接認證密碼。
d、服務器內部設置安全檢測機制，一旦檢測到當前鏈接的客戶端有非法操做嫌疑(如內部通訊協議沒有按既定的步驟進行)時，主動斷開該客戶端的鏈接，並記錄該鏈接的IP地址，在一段時間內不容許從新鏈接。
---------------------
做者：可愛小布
來源：CSDN
原文：https://blog.csdn.net/ucvive/article/details/78220734
版權聲明：本文爲博主原創文章，轉載請附上博文連接！

 

對於一個實時互動的音視頻系統而言，存在不少技術難點，有幾個比較重要的點：

首先是低延遲，若是要知足比較流暢地進行實時互動，那麼單向的端到端的遲延大概要在400毫秒如下才能保證流暢溝通;

第二點就是流暢性，你也很難想象在視頻過程當中頻繁卡頓會有良好的互動;

第三點是回聲消除，回聲的產生是揚聲器播放的聲音通過環境反射被麥克風從新採集並傳輸給對方，這樣對方就會一直聽到本身的回聲，整個互動過程會很是難受;

第四點是國內外互通，隨着如今國內同質化產品愈來愈多，國內的競爭也異常激烈，不少廠商紛紛選擇出海，這時就須要作好海內外的互通;

第五點是海量併發，固然這不只僅指實時音視頻了，基本對於任何一款互聯網產品而言都是必需要考慮的難點。

技術難點解決方案

關於這幾個技術難點，在這裏跟你們分享一下ZEGO即構科技的解決思路和實踐經驗。

一、低延遲 
 
首先，若是實時音視頻要保證低延遲，那麼前端和後端的整個鏈條必定要作到極致的，好比前端的一些編碼算法、流控，甚至丟幀、追幀策略等等都要作到足夠好。另外，不一樣的業務場景下，編碼器的選擇也會有所區別，從而會帶來不一樣的編碼延遲，所以不一樣的業務場景能達到的延遲程度也是不同的。

其次，就是對推拉流網絡的選擇，一般的方案是讓須要實時互動的用戶經過核心語音視頻網絡——像BGP這樣的優質節點來作語音視頻傳輸，而對於一些特定場景來講，好比互動遊戲會直播給一些圍觀用戶看，那麼這裏就須要作轉碼、轉協議、甚至混流，再經過內容分發網絡去分發。像 內容分發網絡自己自然就有作就近接入，但對於接入核心語音視頻網絡就須要有智能的調度策略來完成就近接入，以及跨運營商、跨區域的接入，好比能夠採用上次登陸IP、經常使用IP和區域調度，甚至能夠測速再去鏈接，固然網絡調度的策略也須要根據業務羣的分佈仔細規劃，甚至採用多個策略配置權重的方式。

二、流暢性

要實現流暢性也會有不少的技術難點和策略，我主要會介紹其中幾種。第一個是能夠作動態伸縮的JitterBuffer（Jitterbuffer :抖動緩衝器在voice over IP(VoIP)中，抖動緩衝器是一個共享的數據區域，在這個數據區域中，每隔一段均勻的間隔，語音包會被收集，存儲併發到語音處理器。包到達時間的變化，稱做抖動，將會因爲網絡擁塞，定時漂移或路由變動而產生。抖動緩衝器放於語音鏈接的接收端，它有意地延遲到達的包，如此一來，終端用戶就會感覺到一個清晰的，沒有什麼聲音失真的鏈接。抖動緩衝器有兩種，靜態的和動態的。靜態抖動緩衝器是基於硬件的，它是由廠家來配置的。而動態抖動緩衝器是基於軟件的，它由網管配置以適應網絡延遲的改變。），在網絡較差或者網絡抖動比較劇烈的狀況下，能夠適當增大JitterBuffer，從而下降一點點延遲來對抗抖動。

第二個是快播和慢播技術，在網絡較差的環境，能夠在用戶無感知的條件下稍微下降播放速度，來應對短暫網絡抖動引發的當即卡頓，當網絡恢復能夠加快速度追回來，但這種方式並不是適合全部場景，好比對於節奏要求很是準確的唱歌場景，當播放速度稍微放慢就能夠被感知。

第三個是碼率自適應，也就是以比較合適的碼率作動態傳輸，爲了保證流暢度甚至能夠調整幀率和分辨率。語音視頻引擎會根據當前網絡測速的結果和應用所指望的碼率，動態地調整碼率、幀率和分辨率，最終達到流暢觀看的用戶體驗。

第四個是分層編碼、傳輸控制，在推流端作一些分層的編碼，這樣在拉流端能夠動態根據偵測到的網絡帶寬狀況來拉取不一樣的數據去作渲染。分層編碼容許拉流端取選擇不一樣層次的視頻編碼數據，網絡狀況好的時候，就拉取較多層次的數據;網絡狀況差的狀況下，就拉取基礎層次的數據。

第五個是動態調度，當在推拉流端監測當前推拉流質量比較差，並且即便經過下降碼率、幀率和分辨率等策略已經沒法保證質量，這時就能夠選擇放棄這條鏈路，直接從新作選入、創建鏈接，固然在這個過程當中可能會出現短暫的停頓。

三、回聲消除 
 
首先介紹下回聲消除的原理：對端發送的信號會先給到回聲消除的模塊，做爲未來消除的參考信號，再把信號給到揚聲器播放，揚聲器播放後因爲周圍環境反射造成回聲，與真實的音頻輸入一同被麥克風採集，這時採集到的輸入信號是帶有回聲的，回聲消除模塊會根據前面的參考信號生成濾波抵消掉回聲消後再發送出去。

原理聽起來會比較簡單，但在實際過程當中卻蘊藏着不少的難點，好比回聲消除模塊接收的參考信號與最終被環境反射後的回聲自己就是存在差別的，此外設備也會極大的影響回聲消除，尤爲是國內的安卓機型特別多，好比國內某手機廠商，從麥克風採集音頻數據到提交中間有將近一百毫秒的延遲，這時回聲消除算法如何適應這麼長回聲延遲的手機就很關鍵;再好比不少用戶在直播中都會用外置聲卡，甚至是模擬器，這無形中也會帶來回聲的延遲。除了設備，場地一樣存在很大的相關性，對於普通會議室，設置 40米的回聲延遲可能已經足夠了，但一些大會場這種回聲延遲能達到將近上百米，這也是一種挑戰。

關於回聲消除，其實谷歌開源的WebRTC提供了回聲消除模塊，但WebRTC的設計自己是爲了在PC端實時音視頻互動的場景，在移動端的適應性上就會差一些，尤爲體如今安卓的一些低端機上。而相對來講，蘋果由於總體硬件、軟件全是本身實現的，麥克風、揚聲器也都有聲學模型設計，所以回聲消除的效果會比安卓好不少。即構科技的音視頻引擎都是採用自研，在真機和模擬器等1000多的機型上測試過，均可以作到很好的回聲消除。

四、 國內外互通 
 
前面提到不少產品都會選擇出海，包括主打國內市場的產品也會有一些海外用戶，所以流媒體數據和控制信令就要作好跨國的互通，這就須要考慮在全球合理佈置一些中繼節點。

這張圖就是一個典型的中繼續傳，北京用戶和迪拜用戶之間要作視頻溝通，根據就近接入原則他們會分別鏈接當地的節點，而這兩個節點間若是互拉，效果會很是差，這時就須要佈置適合的中繼節點，好比香港、新加坡、日本等等，數據路徑的選擇是須要根據業務側決定的，也就是說在物理鏈路路由之上還要再有一條業務的路由表，須要根據用戶場景制定，包括用戶分佈、用戶訪問頻率、高頻段峯值等等，可能每次的路由都會有所不一樣。

五、海量併發

海量併發是全部互聯網產品都會遇到的問題，這裏就再也不展開，主要要考慮負載均衡，如何平滑擴容，對於沒法覆蓋的地方要作代理調度，甚至須要考慮容災、接入層的設計等等。

實時語音視頻的技術門檻相對比較高，若是依靠本身研發，可能即便會投入不少開發成本也沒法與匹配市場快速發展的節奏。如今實時音視頻雲服務已經十分紅熟，其實不妨「讓專業的人去作專業的事」。