在UDP上使用RTP和設備的專用路由器/網絡時，預計會發生什麼延遲？

我一直在嘗試幾種方法，用Java和C++接收和發送音頻流，而且它們工作正常，但延遲開始排隊。我在理解我做錯了什麼或者我最初需要什麼時遇到了一些問題，經過一些閱讀後，我發現我需要有一個jitterbuffer，所以沒有什麼信息，我開始使用庫來代替它，因爲它包含了一個jitterbuffer。在UDP上使用RTP和設備的專用路由器/網絡時，預計會發生什麼延遲？

它增加了很多性能，因爲它延遲了數據包，所以網絡緩衝區等不像以前那樣排隊。

所以我想知道，作爲具有RTP over UDP和專用路由器/網絡設備的延遲，我可以期待什麼？我有大約300-1000毫秒的延遲，這是一個好的平均值？

0-3-1s的延遲是從一個電話到另一個，當從手機流到PC我認爲我有低至0.1-0.3s，這可能與手機正在低價手機與「低」音頻，網絡和一般處理能力？

來源

2017-04-21 Kristian Martinsen

嘗試使用GStreamer進行測試，例如：'gst-launch-1.0 uridecodebin uri = rtsp：//192.168.2.1/live1.sdp latency = 0！ autovideosink'這個流水線提供了延遲參數，雖然實際上並不是零但是延遲很小，流非常穩定。當然，您將需要特定的音頻管道。關於增長延遲，我會說需要在管道中進行反饋，以便在增長時發送組件會跳過「延遲」的數據包。 – AlexanderVX

謝謝，是的，我會研究GStreamer，今天已經下載了它，但還沒有進入它，將立即開始:) –

我能想到的延遲有過UDP

那包端點之間的旅遊措施RTT (round trip time) RTP，這是最好的時候，你可以得到的。然後在RTT時間上有差異，並且抖動緩衝器可以處理這種類型的網絡延遲。通常在VoIP應用程序中，抖動緩衝區動態適應從網絡排隊的數據包的速率。因此，如果您的RTT在50ms-250ms的範圍內，並且您發送的每個RTP數據包發出40ms的聲音，那麼您將獲得大約200ms的延遲。在測試中，我發現200毫秒並沒有那麼糟糕。下面是我如何估計延遲：如果RTT在50到250ms之間，那麼抖動緩衝器將不得不適應最壞的情況，並且假定RTT大約爲250ms，或者單程爲125ms。然後在發送方有額外延遲的buffereing。如果每個數據包發送40毫秒的音頻，則需要增加40毫秒的額外延遲時間，這會增加到165毫秒，並且在這裏和那裏進行處理，在這種情況下200毫秒也不會有問題。如果你使用Android手機，預計Android手機上的音頻播放可能會增加一些額外的200毫秒延遲左右（完全取決於Android版本和手機型號）。是的，這是正確的：當你排隊播放聲音的時候，你可能會在200ms後聽到聲音！回放語音時，iPhone的延遲要小得多（我希望在20-40毫秒的範圍內）。當你的語音對話超過300-400ms時，你真的開始注意到延遲。如果您使用WebRTC庫，我可能會在voip中獲得最佳質量。

來源

2017-04-21 15:18:08 Pavel

好吧，非常好！好吧，那麼我猜這是300-1000毫秒沒有那麼糟糕。我會把我的手放在一個普通的頂尖設備上並對它們進行測試。謝謝 –

在UDP上使用RTP和設備的專用路由器/網絡時，預計會發生什麼延遲？

回答

相關問題