1、前言
從直播在線上抓娃娃，不斷變化的是玩法的創新，始終不變的是對超低延遲的苛求。實時架構是超低延遲的基石，如何在信源編碼、信道編碼和實時傳輸整個鏈條來構建實時架構？在實時架構的基礎之上，如果通過優化采集、編碼、傳輸、解碼和渲染中的關鍵環節來降低延遲？本文將會介紹即構在這方面的思考與實踐。
學習交流：
- 即時通訊開發交流群：320837163 [推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-1465-1-1.html）
2、關于作者
關旭：即構科技音視頻引擎核心專家，碩士畢業于南開大學數學系，先后就職于中興通訊、騰訊等公司負責音視頻相關的研發工作，在實時音視頻技術上有多年積累，當前在即構科技主要負責音視頻引擎核心開發。
3、相關文章
《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《如何優化傳輸機制來實現實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
4、從直播到線上抓娃娃
圖 1 展示了實時音視頻兩種不同的應用場景——連麥互動直播和線上娃娃機。雖然這兩種都是互動，但是對于實時音視頻的要求卻不同。第一個實時連麥是語音視頻流的互動，例如其中一個說了一句話，另外一個人聽到了，再回復一句話，這個實時性只是對語音視頻流的實時性要求很高。而第二種線上抓娃娃則對信令的延遲提出了更高的要求，操縱者無需說話，看到的是娃娃機傳回來的視頻流結果。
如果考量互動直播是用實時音視頻的延遲，那么線上抓娃娃則是用信令和視頻流的延時。隨著時代的發展，我們對實時語音視頻的定義會慢慢有一些不同，將來可能還有更多的因素需要考慮。
圖 2 是我們互動直播的實時架構圖，我們把互動直播分為兩部分，一個是主播側，需要更低的延遲，另一側是普通觀眾，對延時不太敏感，但對流暢性敏感，中間通過一些旁路的服務把這兩個集群（一個集群叫超低延遲集群，另外一個集群叫圍觀集群）連接起來。
在超低延時部分，我們提供的服務包括流狀態更新、房間管理等，以及一些流媒體服務，主要起到分發的作用。我們通過超低延遲服務器集群（和觀眾側不太一樣），提供實時分發的功能。
此外還提供了動態調度的服務，幫助我們在現有的資源網絡上找到更好的鏈路。后面的觀眾集群是另外一個集群，把它們分開是出于一些業務方和我們自己成本上的考慮，另外會提供存儲、PCB 加速、分發的功能。
中間的旁路服務包括混流、轉格式（主要是轉碼）、轉協議等。為什么要混流？舉一個比較簡單的例子：當主播一側有 9 個人連麥，如果沒有混流服務，觀眾端就會同時拉 9 路音視頻，這樣對帶寬壓力很大。
普通觀眾是通過圍觀服務器集群（延遲相對大的集群）去拉這些流的，這個集群的延遲可控性相對比較弱，有可能會出現這 9 路畫面之間的不同步現象，通過混流服務，觀眾拉的都是合成好的音視頻流，就不會出現各路流之間的不同步問題。
還有轉格式轉碼的服務，前面集群提供的是很低延遲的服務，里面一些，比如說編碼碼流，不能夠在傳統的 CDN 網絡分發，如果想在傳統的 CDN 網絡上分發，就要服務端的轉碼。還有就是轉協議，因為前面提供一個更低延時的服務，后面要在 CDN 網絡上分發，所以協議也需要轉。
圖 3 是線上娃娃機的 APP 版本的架構圖，這里的是特色是線上娃娃機可以實時推兩路視頻流，上機玩家可以隨時任意去切其中一路畫面去看。這兩路視頻流首先通過我們超低延時服務器集群，同時上機玩家也可以推一路流上去，可以給圍觀觀眾方看到這個人在抓娃娃時候的一些表情、反應、語言，增加一種互動性。此外，玩家需要通過手機遠程操控娃娃機，因此還需要實時信令的分發。
接下來是娃娃機的 H5 架構圖（圖4）。在推流方面和 APP 版本沒有太大的區別，娃娃機一側還是走的私有協議。不同的地方是因為私有協議沒有辦法直接讓 H5 拉到流，所以中間會加入一個媒體網關，作用是把我們的私有協議翻譯成 H5 可以識別的碼流格式，然后 H5 端通過 websocket 方式把這路流拉下來，這里需要媒體網關做到超低延時的轉換。
簡單來看，這里的網關服務器只是做了一個分發服務，好像不會引入延時，實際上不然。
因為 websocket 拉的是 TCP 的流，但是我們推的是 UDP 的，當視頻幀很大的時候，一個幀數據就要切割成很多 UDP 包上行，服務器需要將這些 UDP 包攢起來，湊成一個完整的幀后才下發給 H5，這樣才能保證不花屏，才能跑得通，所以這個攢包組幀的過程是會有延遲的。信令部分和 APP 部分基本是相似的。
5、實時架構的若干點思考
剛才介紹了實時音視頻的兩種場景，下面提出一點思考：
1）實時音視頻有什么樣的特征？
2）怎么樣去架構一個實時音視頻系統？
這是仁者見仁，智者見智的問題。你可以通過很多方式把這個系統架構起來，都會達到相對不錯的效果。但是我認為，無論怎樣，實時音視頻都有繞不過如下幾個點，只有把它們做好了，才能夠在業界有更高的知名度、更好的技術儲備。
第一是實時音視頻是不能等的：
因為等了就不是實時音視頻了。 不能等，這里會引入一個矛盾。既然不能等，例如你把實時音視頻也看作一個消費模型來看，那是提前生產還是按需生產？字面上理解很簡單，肯定是按需生產，需要的時候才生產，如果提前生產就是延時了。但是并不是每一個點都做成按需生產是合理的。
舉一個例子，比如你要去播放一段音頻，最好的做法是系統或者驅動告訴你，它需要數據了，然后去解一幀塞給它，這就是按需生產。但是為什么還有提前生產一說呢？就是系統告訴你它要數據的時候，實際上它有一個對響應周期的要求。
你現去生產可能就要等去解完一幀，但是這個時候來得及嗎？如果你只有一路下行，可能就來得及。但是現在要求很多路下行，在很短的時間周期內解很多幀，對硬件性能有很高的要求。通常來講，并不可取。這只是實時音視頻中一個簡單的例子。提前生產會引入延遲的，那么到底要提前多久生產，怎么樣動態估計我們什么時候應該生產？這是一個開放性的問題，也是一個大家在設計系統時要重點考慮的。
第二是實時音視頻不能久等：
實時音視頻中有些等待是避免不了的，例如你要做音頻編碼，它本來一定要 20 毫秒一幀或者 40 毫秒一幀去做，給一個采樣點點是編不了的。這里既然有些延遲和等待避免不了，我們當然希望系統處理的粒度越低越好，這樣可能會帶來更低的延時。但是處理的粒度越低，整個系統在頻繁跑的時候，你可以認為它是一套循環，當循環的東西很少，這個循環就會跑很多次，對系統來說就是一個很大的開銷和負擔。
所以不能久等的時候，我們當然希望它處理粒度小。另外處理粒度小還有一個優勢，在整個系統中并不能保證每一個環節的處理粒度是一致的。例如這個節點可能要求是 10 毫秒，下一個結點要求 15 毫秒，這是由于算法的限制，可能沒有辦法避免。如果在整個系統內選一個相對小的粒度，在粒度拼接的時候，例如 10-15 毫秒，要兩個 10 毫秒才能夠 15 毫秒，還剩下 5 毫秒，剩的就比較少。
如果粒度很粗，可能剩下的東西就很多。在粒度拼接的時候，這個剩余的量代表了整個鏈路中的延遲。所以我們希望處理粒度盡量小，但是又不能小到整個系統沒有辦法接受的粒度。
第三是實時音視頻不能死等：
例如你需要接收一個網絡包的時候，這個包遲遲不到，這個時候你不能完全不等，完全不等就會卡。但是在等的時候有一個超時的機制，例如這個音頻包就是很久不到，就把它跳過去做一個糾幀補償，當包最終還是到了的時候，我也只能把它扔掉，而不應該把它利用起來。
此外，實時音視頻在服務器端還需要深入考慮這樣幾個問題：
第一是負載均衡；
第二是就近接入；
第三是質量評估；
第四是動態路由；
第五是算法流控。
負載均衡：是說讓整個服務器的每一個節點都承擔相對均勻的服務，不至于使得某一個節點負載過高造成一些丟包，造成網絡往返時的增大，這樣對任何的網絡損傷來講，對實時音視頻都會造成比較大的延遲增加。
就近接入：這里的“近”并不是指地域上的近，而是“網絡上的近”。很簡單的例子，我們在深圳做推流，香港離得很近，可以推到香港的服務器，但實際上這畢竟是一個跨域的網絡，有不穩定的因素在里面，所以我們寧愿推遠一點。這個近指的應該是在網絡質量評估意義上的近，例如網絡往返時很小、往返時很平穩、分布在延遲比較大的時刻不會還具有很大的概率，丟包率很低等。
要做到就近接入，這個近要有一個很好的質量評估體系，質量評估方法有兩種：
事后質量評估：在復盤的時候，例如這個網絡平穩的運行了一個月，復盤看一下整個月中的質量怎么樣，這樣的質量評估可以認為是一個相對離線的評估，它能夠給我們提供一個指標，最近一個月的網絡和上個月相比是否有所改善。我們可以從中學習到一些經驗，例如這個月和上個月的調度上有些策略上的不同。這是一個系統化的經驗總結和優化的方法。
實時質量評估：更重要的應該是一個實時上的評估，例如我現在推流，能夠實時監控到當前的質量是怎么樣的，就可以做到實時動態路由。實時動態路由是說某個人推流從北京推到迪拜，有很多鏈路可以選，他可能根據之前的一些經驗，假如他之前經驗告訴你，直接推到迪拜，這個鏈路是很好的，但是畢竟有個例。有動態實時的質量評估，就知道這個時候推迪拜是否好，如果不好，可以在用戶無感知的情況下更換，隨時增減整個鏈路中一些路由的節點。這就是動態路由的思路。
實時動態路由：是說某個人推流從北京推到迪拜，有很多鏈路可以選，他可能根據之前的一些經驗，假如他之前經驗告訴你，直接推到迪拜，這個鏈路是很好的，但是畢竟有個例。有動態實時的質量評估，就知道這個時候推迪拜是否好，如果不好，可以在用戶無感知的情況下更換，隨時增減整個鏈路中一些路由的節點。這就是動態路由的思路。
實際情況中是結合前面這 4 個點，在我們的網絡和服務器資源集中，去選出質量最優或者近似最優的鏈路來保證實時音視頻的服務的。但是資源集是有限的，沒有人可以保證你的資源集中一定可以選出的這個最優具有很好的鏈路特征。保證不了就要考慮第五點，我即使選出了一個認為是整個資源集中最優的鏈路，但是它的質量還達不到很好的標準，就要通過一些算法才能彌補。這些算法包括在一個不可靠的網絡中怎么樣進行可靠的音視頻傳輸的技術，這些技術在接下來我們會和大家稍微分享一下，也包括整個鏈路的一些擁塞控制。
6、關于信源編碼的思考
信源編碼是為了減少網絡中的負擔，把大量的數據壓縮成比較小的網絡數據，來減少網絡負擔的方式。壓縮方式有很多種，我們先以音頻來看，上面畫了一些圖（圖 6）。
我們重點看 Opus 編碼器，它有幾種模式在里面：
一種是線性預測模式；
還有一種是混合模式；
另一種是頻域編碼模式。
混合模式是把兩種編碼模式混合在一起，根據不同的情況進行選擇。
圖 6 是一個編碼器，橫軸是碼率，縱軸是它的質量，中間是各種音頻編解碼器的表現。你會發現線性預測的方式能夠在低碼率上提供比較好的質量，但是在 20K 左右的時候就沒有曲線了，因為它不支持那么高的碼率。然后看 MDCT 編碼，它可以在比較高的碼率上達到近似透明的音質。音頻編碼器是有不同的編碼原理在里面的，像這種 LP Mode 是模擬人的發聲模型，既然有了數學建模，它的特征是能夠在一個比較低的碼率上提供一個比較可靠的質量。
但是它的特點是容易達到一種質量上的飽和，也就是說當你碼率給它很高的時候，實際上它也就編的效果還是那樣，因為它畢竟是一種參數化的編碼。所以根據業務場景，當你需要一個很高的音質，又需要音樂場景的時候，選擇它明顯不合適。MDCT MODE 沒有任何的模型在里面，實際上就是把信號轉換成頻域，直接去量化。既然沒有模型化，它是比較消耗碼率的，但是它可以在一個較高的碼率上提供很好的質量，可是低碼率的表現遠遠不如模型化的方法。
整體總結起來，音頻包括語音和音樂兩種，因此有適合語音的 codec 和適合音樂的 codec：
第一種 codec 適合語音，語音可以模型化，適用于語音的 codec 能夠在低碼率上提供很好的質量，提供一個相對高的壓縮比, 但是它容易達到飽和，不能夠提供一個近似于透明的音質；
另外一種 codec 的編碼原理不一樣，能夠把音樂、語音都編得很好，但是特點是不能夠提供太高的壓縮比，指望它能夠在低碼率下提供很高的編碼質量是做不到的。
關于視頻編碼，最簡單的幾個點有 I 幀、P 幀、B 幀。I 幀是自參考，P 幀是向前參考，它會參考歷史幀的特性進行編碼。B 幀是雙向參考，它可以參考前面的幀，也可以參考后面的幀。B 幀可以帶來更高的壓縮比，提供更好的質量。但是因為它會參考將來的幀，所以會引入延遲，因此我們在實時音視頻系統中是很少用到 B 幀的。
想要做好實時的音視頻系統，流控是一定要做的，流控對視頻的編解碼有什么要求？至少有一點，編解碼器的碼控一定要很穩定。為什么？舉例說，我現在有一個很好的擁塞控制策略，帶寬估計做得很好，一點差錯都沒有，估計出某一個時刻可分配視頻的帶寬就是 500kbps，就可以讓視頻編碼器設置成 500kbps。但是，如果碼控不是很穩定，你設置 500kbps 的時候，視頻編碼器可能就跑到 600kbps 了，這樣就會帶來一些阻塞和延遲。因此，我們希望選擇的 codec 具有很好的碼控策略。
實際上一些開源代碼都是有做碼控的，但是直接拿來用并不是適合你的場景，因為這些開源代碼做起來，可能或多或少的考慮其他的場景，并不只是實時音視頻場景。比如說某個 codec 是用來壓片的，希望半個小時或者一個小時之內達到預定的碼率就可以，不會管這一秒鐘或者下一秒是什么樣子的，但是實時音視頻就是要求要把時間窗做得很小。
另外我們希望 codec 有分層編碼的能力。什么是分層編碼？為什么要有分層編碼？分層編碼也分兩種，一種是時域上的分層，一種是空域上的分層。前者是編碼的時候是當前幀不參考上一幀，而是有隔幀參考的策略；后者可以認為使用較低的碼率先編碼一個小的畫面，然后使用剩余的碼率編碼增量的部分，得到更高分辨率的畫面。
為什么要這樣做？實時音視頻中并不是很多場景都是一對一的，當不是一對一，要做流控的時候，不可能因為某一路觀眾的下行不好，就把主播上行推流的碼率降下來，因為可能還有一千個觀眾的網絡很好，這些網絡好的觀眾也會因為個別觀眾網絡不好，而只能看到不那么清晰的畫面。所以要分層，可以在服務器端選擇給用戶到底下發哪一層的，因為有分層策略，如果這個人線路不好，只要選擇其中一個比較小的層次發給他就可以了，例如核心層，這樣可以緊緊利用核心層把整個視頻還原，可能會損傷一些細節或者幀率偏低，但是至少整體可用。
最后，我想說一下，很多人認為，視頻的數據量很大，視頻的延時比音頻應該更高才對，實際上不是。因為很多的延遲實際上是編解碼自有的延遲，如果編解碼中沒有 B 幀的話，你可以理解為視頻編碼是沒有任何延遲的。但是音頻編碼或多或少都會參考一些將來的數據，也就是說音頻編碼器的延時一定是存在的。因此，通常來講，音頻的延時比視頻的延時更高才對。
7、關于信道編碼技術的思考
信道編碼分幾個部分：一種是根據先驗知識的網絡冗余編碼技術——前向糾錯技術。以 RS（4，6）編碼為例，我要發一個分組，這個分組有六個包，其中有四個包是實際媒體數據，有兩個包是冗余包。那么在解碼端收到六個包中任意的四個，就可以完全恢復所有攜帶媒體內容的包。
例如這里 2、3 都丟了，收到了 1、4、r1、r2，也能夠完全恢復 2 和 3。這樣看來很好，任意兩個丟掉都可以完全恢復。但是這樣的算法也有它的弱點，不太適合突發性的丟包。因為這個分組不宜太大，如果分組很大，分組就有很大的延時。分組如果很小，很可能整個分組都丟掉了。
實際上這種做法就沒有任何意義。所以它不太適合突發性丟包，而且它畢竟是根據先驗知識去做的一種冗余，也就是說它永遠是根據上一時刻網絡的狀態作出的判斷，下一時刻網絡是什么樣的，是預測的東西。網絡是實時發生變化的，這種預測的東西并不完全可靠。
所以它恢復的效率在實際網絡中相對比較低，而且這樣的算法復雜度相對比較高。當然它也有優勢，例如我們是提前算好的，一次性發過去，不需要等到你發現丟包時我再做怎樣的冗余傳輸，所以不受網絡往返的影響。而且這種分組可以任意、隨機調整大小冗余度，比較適合均勻丟包的場景。
另外一項技術是丟包重傳技術：相對來說，丟包重傳相對 RS 來講，更有針對性，所以恢復效率比較高。第一個 Go Back N 技術是類似于 TCP 的傳輸技術，發送端在不斷的發包，接收端要負責告訴發送端我現在收到包的情況是怎么樣，收到的連續的幀的是序列號什么樣的。發送端發現發了 10 個幀，接收端只正確收到 8，不管 9 號包或者 10 號包是否收到，都會丟包重傳。所以 Go Back N 技術有一定的目的性，維護的是丟包狀態，它知道哪些包是沒有收到的，但是并不精準。
接下來是自動選擇重傳技術（Selective ARQ）：選擇性的重傳，是在接收端發現了哪個包丟了，然后才會讓發送端重新發送這個包。聽起來是非常好的一個技術，效率很高，丟了哪個包就重傳哪個包。但是它的弱點在于，你必須要假定這個包是頻密的發送才可以。例如發送端發出 1、2、3、4 這樣的包，但是一秒鐘才發一個包，什么時候發現 2 丟了呢？收到 3 的時候。如果 2 作為最后一包，永遠發現不了丟掉了。也就是如果發包不頻密，至少需要 1 秒鐘才發現它丟。這個時候再讓它重傳，就很晚了。
所以在一個真實的系統中，選擇性重傳是首選，因為音視頻的大部分場景是頻密的，但是可能也要結合一些 Go-Back -N 的做法。發一些確認機制，這樣才能把重傳做得更加完備。另外所有的重傳都要至少等一個網絡往還時，因為無論是確認丟包還是反饋收包情況，都需要一個網絡往返時，所以它的弱點是，它受網絡往返時影響比較大，如果控制不好，有可能造成重傳風暴。優勢是算法計算復雜比較低，且容易實現。另外，因為它有很大的針對性，無效的重傳包會比較少，針對突發性的丟包會有比較好的效果。
剛才講了針對不可靠網絡的兩種傳輸技術，前向糾錯和丟包重傳，它們都有各自的優點和缺點。實際上一個好的網絡分發技術應該是將這兩種結合在一起的，根據不同的信道情況把這兩種技術結合在一起。
圖 11 來自于網絡，首先從左下角藍色部分看起，當網絡往返時很小，丟包率不高的時候就用重傳。但是當網絡 RTT 很高的時候，在這個圖里面去看，就沒有選用重傳策略。從我個人的角度來看，我認為這并不是一個非常合理的做法。因為剛才提到了，FEC 是一個無目的性的、根據先驗知識去做的一種冗余技術，雖然當 RTT 很高，重傳很耗時，但如果沒有重傳，要加很多冗余包，才能把丟掉的包完全恢復，實際就會帶來很大的資源浪費。而且當你丟包率很高的時候，可能還并不能夠完全恢復所有包。視頻只要丟幀就會很卡，視頻丟包率應該控制在千分之幾以下，才可以達到順暢的可以觀看的水平。
關于信道編碼的思考：信道編碼和網絡吞吐呈反比關系。無論是重傳性編碼還是冗余性編碼，都會占用帶寬，從而減低實際媒體信息的吞吐量。現實的生活中，信道都有限制。當你傳輸的時候，就要根據信道的特征去做一些策略。信道如果有擁塞，我們就需要有一個擁塞控制的算法，去估計應該把整個信道怎么樣做合理分配。
另外，在做一個系統的時候，想清楚如何去評價一個系統的效果是很重要的一個點：在信道編碼的時候，一個很重要的指標是，信道編碼的有效性是什么樣子的。有效性分為兩種，一種是重傳或者冗余能否真的把丟掉的包補回來，這是一個有效性。即使這個包補回來了，但是如果經過一個信道編碼策略之后，還有一些丟包。
例如原來的丟包是 20%，補回來變成 1%，那么這個重傳在我們的評價當中實際上是沒有效果的，因為 1% 的丟包對音頻來講是無所謂的，但是對視頻來講是很卡的。在這樣的評價系統中，補回來還有 1% 的丟包，那么所有的編碼都是沒有太大意義的。舉這個例子，如果在這時信道也發生擁塞，再進行這樣的信道編碼，就不會達到很好的效果。這個時候是否應該停止所有的信道編碼呢？
還有信道編碼有效性的判斷：衡量它是否好，就是加了多少冗余，冗余中有多少沒有被利用好，如果這些冗余像剛才那個例子那樣，6 包帶 2 包的冗余，剛好丟掉 2 包，整個包都恢復出來了都使用到了，那就是百分之百的冗余都有效。如果 4 包信息丟了 1 包，卻帶了 2 包榮譽，其中 1 包就沒有效果。所以想要做一個好的系統，應該先想到如何評價這個系統的好壞。
8、引入延遲的環節和降低延遲的思路
延遲的引入主要分三部分。
1）一個是采集 / 渲染：這好像是很簡單一個部分，但是它引入延遲可能是最大的，可能是整個分發過程中最大的環節。
有很多人不是特別理解，但實際上在我們現有的網絡結構中，網絡往返時的延遲都控制在 50 毫秒以內，但是渲染和采集，尤其是渲染，幾乎沒有任何移動端系統可以保證它百分之百的 50 毫秒，這是一些硬件上的限制。如何去降低這些延遲？剛才我已經舉了一個生產消費模型的思路，到底是按需生產還是提前生產，這些都是可以仔細去考慮的。
2）還有編解碼會帶來一些延遲，尤其是音頻會帶來一些延遲：這些延遲中有些是避免不了的，我們就要根據實際的使用場景去減少這些延遲，這些都是要在具體形態上做一些權衡的東西。還有處理粒度上的考慮，也會影響整個系統的延遲。
3）還有一個延遲，大家都能看到的，就是網絡分發延遲：如何去減小？除了在資源集中找到一個最優子集之外，還有信道編碼的東西，要做一個很好的信道編碼系統，我們如何評價信道編碼系統的好壞。有了這些思路之后，可以指導我們去做更好的下一步的開發工作。
附錄：更多實時音視頻技術文章
[1] 開源實時音視頻技術WebRTC的文章：
《開源實時音視頻技術WebRTC的現狀》
《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議棧》
《淺談開發實時視頻直播平臺的技術要點》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基于開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《實時通信RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
>> 更多同類文章 ……
[2] 實時音視頻開發的其它精華資料：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網易視頻云技術分享：音頻處理與壓縮技術快速入門》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基于RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《聲網架構師談實時音視頻云的實現難點(視頻采訪)》
《淺談開發實時視頻直播平臺的技術要點》
《還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》
《如何用最簡單的方法測試你的實時音視頻方案》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：采集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯系實際：實現一個簡單地基于HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《如何優化傳輸機制來實現實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《網易云信實時視頻直播在TCP數據傳輸層的一些優化思路》
《實時音視頻聊天技術分享：面向不可靠網絡的抗丟包編解碼器》
《P2P技術如何將實時視頻直播帶寬降低75%？》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《近期大熱的實時直播答題系統的實現思路與技術難點分享》
《福利貼：最全實時音視頻開發要用到的開源工程匯總》
《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-1465-1-1.html）