WebRTC儘可能低的能力

我有一個簡單的UDP流媒體協議，需要原始H264視頻幀，並立即從服務器端發送到客戶端，使用此協議我可以得到接近網絡RTT延遲（沒有數據包重新發送和不要關心數據包丟失），所以如果我有從服務器到客戶端20毫秒的延遲，我可以讓一個視頻幀從編碼器輸出到客戶端（準備好解碼）準備好，可以說是30ms。WebRTC儘可能低的能力

我的問題是： - WebRTC（通過UDP）能夠降低到這種延遲？不考慮編碼和解碼時間，我可以通過WebRTC獲得協議層的最低延遲時間。

我不知道這種延遲是否需要我自己的協議才能更深入的開發，或者我可以爲WebRTC開發更通用的視頻服務器，以便立即得到每個網頁瀏覽器的支持。

此致

來源

2017-02-12 user1428926

WebRTC可以具有與常規SIP/RTP堆棧相同的低延遲。 WebRTC堆棧供應商盡其所能減少延遲。

對於錄音和發送沒有任何延遲。堆棧會立即發送數據包，一旦從記錄器設備收到並使用選定的編解碼器進行壓縮。某些編解碼器（和一些編解碼器設置）可能會在此引入一些延遲來啓用某些功能，例如FEC。

關於接收端：在最佳情況下，堆棧不應該延遲數據包的播放，所以它們可以在它們到達時立即顯示。但是，在次優環境下（網絡延遲或數據包丟失），堆棧將引入jitter buffer。網絡質量越低，抖動緩衝區的長度就越高。

因此，要實現最低的延遲，你可能需要做如下：

選擇具有最小處理時間
刪除FEC和禁用任何其他設置這可能會導致額外的延遲編解碼器
刪除抖動緩衝區（大多數WebRTC堆棧沒有此設置，因此您可能必須自己修改代碼，但這是一個簡單的修改，因爲您只需要停用部分代碼）

來源

2017-02-24 08:27:21 Istvan

非常感謝您，並且您是否知道此抖動緩衝區代碼imay位於何處？ – user1428926

它應該與音頻播放模塊緊密結合：通常網絡抖動緩衝區和音頻緩衝區可以混合在一起（因爲音頻驅動程序也有/需要一些預緩衝） – Istvan

的WebRTC使用RTP爲具有僅在負載的開始相比純UDP小附加頭部底層媒體傳輸。這意味着它應該與您使用普通UDP實現的一致。 RTP主要用於實時音頻和視頻（SIP，H.323，XMPP中的媒體傳輸）等延遲關鍵環境，因此您可以預期延遲足以實現此目的。

來源

2017-02-13 06:47:02

但這個小的額外頭可能與延遲無關，我的意思是如果有任何緩衝區，可能使最小延遲...讓我們說500毫秒，所以看來，這種運輸協議不應該放任何延遲transmision。 – user1428926

@ user1428926：這正是我所說的，它不會影響延遲。引用自己：*這意味着它應該與您使用普通UDP實現的功能相媲美。* –

WebRTC儘可能低的能力

回答

相關問題