現今大部份的直播咱們要可以與漂亮的直播主姐姐或硬漢大叔進行互動，基本上咱們只能使用文字，也就是所謂的聊天室，而這篇文章咱們將要介紹另一種互動方式，那就是直播連麥，也就是直播主與聽眾可以進行語音溝通，更白話文的是說可以和漂亮姐姐進行語音聊天。這也就是本篇文章的主題。
可以和漂亮姐姐進行語音聊天的難題與方案。
本篇文章將分成兩個章節：
直播連麥最大的難題就是
延遲問題。
假設我們在一般直播時，以比較低的延遲 2 秒來計算的話 ( 就是主播說話聽眾 2 秒鐘後才能聽到 )，那這樣在直播連麥時會發生什麼事情呢 ?
如下圖所示，直播主說話以後，要經過 4 秒以後才會聽到連麥者的回復，而連麥者也相同的要等 4 秒後才能聽到直播主的回應，你覺得這樣還可以對話嗎 ?
這裡來問個問題。
基本上可以分四個部份，如下圖。呃下面兩個箭頭算一部份，所以分別為直播主處理、網路傳輸、CDN 與 Media Server 處理、聽眾端處理。
它需要花時間來進行聲音與影像的採集，接下來進行編碼，最後就準備封裝然後準備送貨。
這部份有沒有可以優化的地方呢 ?
基本上可以在編碼上加速，網路上有提到說硬編碼與軟編碼這兩個聽起來很硬東西，其中軟編碼就是使用 CPU 來編碼，而硬編碼就是使用非 CPU 來進行編碼，例如使用 GPU。
而硬編碼效能優於軟編碼，不過需要硬體支援，這方面我沒很熟，請當參考。
只要實用網路進行傳輸，基本上都一定會發生延遲問題，而最主要產生的原因有兩個：
首先距離是不用說的，直播主離你越遠，它的聲音要傳到你的小耳朵裡，一定比較花時間。
然後第二點是傳輸時的封包維護，在網路傳輸時基本上會發生兩件事情網路抖動與網路掉包。
網路抖動就是你傳送 A、B、C 封包給某個人，但某個人收到的封包為 C、B、A，那這時就要針對這狀態做一些處理，方法可能是緩存等到某段時間後，在根據封包裡面的時間來依順序播放，但緩存那邊就會產生延遲時間囉。
而網路掉包就是你傳送 A、B、C 但實際上對方只收到 A、B，而這時如果是 TCP 的話，它就會一段時間後，會在發送一次封包 C，然後這段時間也就產生延遲囉。
那這部份有沒有啥解法 ?
就是使用 CDN 只要離的越近，當然越快，而且發生網路網路抖動與網路掉包機率更低，當然如果你們公司夠強，那就自已開發一個基於 UDP 的協議吧。
在這一部份，它們可能會需要將 RTMP 推流轉成相對應其它協議的東西，例如 HLS 就需要產生 .m3u8 而 HTTP-FLV 就需要產生 .flv。
那這部份有沒有啥解法 ?
我不知道。
當聽眾的設備收到直播主傳送來的聲音後，會開始進行解碼，然後進行播放，這裡也會需要花費時間。
然後有一些播放器會有緩存的機制，為了防止看片卡頓的問題，所以它可能會在本地端，先緩存個 1 秒鐘的影像，然後在播出，因此這部份也會產生延遲囉。
那這部份有沒有啥解法 ?
基本上就看解碼器的能力吧……
請看下圖，基本上就是直播主與連麥者發送一條 RTMP 到 CDN，然後雙方同時會去最近的 CDN 拉取對對方的 RTMP，最後聽眾端就同時去 CDN 抓兩條流回來。
如下所列，雖然它實現的方式比較簡單，但是有很多問題，基本上應該是沒啥商業價值。
請看下圖，基本就是主播主與連麥者進行 P2P 的連線，然後通常會在主播端那將兩條聲音進行合流，然後在用 RTMP 推流將到丟到 CDN 那，然後聽眾在去用拉流去將這它抓下來。
這種架構有以下特點:
雖然使用 P2P 的連麥架構還是有缺點，但是相比之下，連麥互動的根本，低延遲至少有解。這個版本基本上 P2P 這方面應該是有辦法使用 WebRTC 來方便實作，但如果 mobile 端要建立這個架構，如果無法使用 WebRTC 的話，那難度就比較高點兒，這就還要在調查了。
本篇文章中，咱們探討了直播連麥的一些挑戰，基本上最主要是延遲的問題，如果這個能解，那基本上直播連麥應該就可以做到用戶不會冒火的水準，不過這裡說一下，寫到這邊以後發覺，某些方面這產業真的非常的燒錢，因為 CDN 真的很重要，好的 CDN 帶你上天堂，爛的 CDN 帶你下地獄。
接下來下一篇文章，咱們將要來理解一下 WebRTC 是如何處理 P2P 連線的，這也有助於未來在想開發 Mobile 端 P2P 連線的幫助。
iThome鐵人賽
看影片追技術