UDP를 통한 RTP 및 해당 장치의 전용 라우터/네트워크를 사용할 때 예상되는 지연 시간은 무엇입니까?

Question

저는 자바와 C++로 오디오 스트림을주고받는 여러 가지 방법을 시도해 왔습니다. 그리고 그들은 괜찮 았지만 지연은 시작되었습니다. 내가 잘못하고있는 부분이나 처음에 필요한 부분을 이해하는 데 몇 가지 문제가있었습니다. 일부 읽기 후에 jitterbuffer가 필요하다는 정보를 얻었으므로 정보가 거의 필요하지 않기 때문에 jitterbuffer가 포함되어 있으므로 라이브러리로 작업하기 시작했습니다.

그리고 성능이 많이 향상되었습니다. 패킷 지연으로 인해 네트워크 버퍼 등이 이전과 같이 큐에 저장되지 않습니다.

내가 궁금한 점은 UDP를 통한 RTP 및 해당 장치의 전용 라우터/네트워크를 사용하는 대기 시간이 어떻게 될 것으로 예상 할 수 있습니까? 약 300-1000ms의 지연이 있습니다. 괜찮습니까?

0,3-1 지연은 전화에서 다른 전화로 스트리밍 할 때 휴대 전화에서 스트리밍 할 때 0,1-0,3으로 낮을 것으로 생각됩니다.이 전화는 아마도 저렴한 전화가 될 가능성이 있습니다. "낮은"오디오, 네트워크 및 일반적인 프로세싱 파워?

Answer 1

나는 대기 시간이 엔드 포인트 사이의 여행을 패킷 측정 RTT (round trip time)

UDP

을 통해 RTP를 가진 것으로, 즉 당신이 얻을 수있는 최고의 시간을 무엇을 기대할 수 있습니다. 그런 다음 RTT 시간에 변동이 있으며 이러한 종류의 네트워크 지연을 처리 할 수있는 지터 버퍼가 있습니다. 대개 VoIP 응용 프로그램의 지터 버퍼는 네트워크에서 대기중인 패킷의 속도에 동적으로 적응합니다. 따라서 RTT가 50ms ~ 250ms 범위에 있고 RTP 패킷 당 40ms의 소리를 보내면 대기 시간이 약 200ms가됩니다. 테스트에서 200ms가 그렇게 나쁘지는 않다는 것을 알았습니다. 다음은 지연을 예측하는 방법입니다. RTT가 50 ~ 250ms 인 경우 지터 버퍼가 최악의 시나리오에 적응하고 RTT가 약 250ms 또는 편도 125ms라고 가정해야합니다. 그런 다음 송신자 측에서 버퍼링 지연이 추가로 발생합니다. 패킷 당 40ms의 오디오를 보내면 여분의 지연이 40ms 가산됩니다. 165ms가 더해지며 여기 저기에 처리가 이루어 지므로이 경우 200ms가 좋지 않을 것입니다. 안드로이드 폰을 사용한다면 안드로이드 폰의 오디오 재생이 200ms 정도 지연 될 수 있습니다 (안드로이드 버전과 폰 모델에 따라 다릅니다). 예, 맞습니다. os에 사운드를 재생하기 위해 큐에 대기하면 200ms 후에 실제로 소리가 들릴 수 있습니다! 아이폰은 연설을 재생할 때 훨씬 적은 지연이 있습니다 (20-40ms의 범위에서 뭔가를 기대합니다). 300-400ms가 넘으면 음성 대화에 지연이 있음을 알게됩니다. WebRTC 라이브러리를 사용하면 최상의 음질을 얻을 수 있습니다.