在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和设备的专用路由器/网络时，预计会发生什么延迟？

回答

相关问题