- From: Roman Shpount via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Oct 2019 18:27:47 +0000
- To: public-webrtc-logs@w3.org
>We are aware of the difficulties of testing this properly. A colleague of mine tested the happy-case, but a stressed version of it. The frame length was changed every 3s, cycling some select values between 20ms and 120ms (therefore "stressed"). Network conditions were kept constant, and favorable, throughout the test (therefore "happy-case"). My concern is that some jitter buffers are designed to track number of queued packets not their total duration. Because of this, changing packet sizes dynamically might cause jitter buffers to switch to spike more and introduce excessive delay or cause excessive playback speed adaptation. > What about changes due to side-traffic? These can appear without a network change. They can persist for several seconds/minutes, then disappear as unexpectedly as they had come. This can happen frequently, too; perhaps more so than network changes. Curiously when dealing with low bit rate situation you are dealing with 3 distinct scenarios: 1. QOS is properly implemented or user learned or force to behave and no other traffic is sent or received during the real time conversation. This is not unusual for VoIP software in dedicated hardware. In such cases all you need to make sure is that bandwidth is correctly estimated and then audio frame size / bitrate is selected to provide the best possible quality for this connection 2. QOS is not used and there is side traffic. Router before the low bandwidth link is configured with large buffers. In this case you get significant delay spikes when TCP stream fills up the router buffer. What you see on the receive side is no packets for a period of time and then lots of packets received quickly. Jitter buffers have a special mode to deal with this by introducing extra delay to allow packets to be delivered, but even this has its limits since packet gaps can be up to tens of seconds long. Best option when such gap is detected is to provide feed back to user that connection was disrupted and application is trying to recover it. In WebRTC case, this means pulling statistics and informing the user. 3. Same as 2 but Router before the low bandwidth link is configured with small buffers or modern qdisc. In this case, in case of side TCP traffic you start seeing RTP packet loss. In such cases it makes more sense to continue sending packet every 20 ms but include 60 ms worth of audio in it (FEC for more then one previous packet). Application in this case can recover from fairly high random packet loss without disrupting the communication experience for the client. > I am curious about your solution - how it chose how long after a network change to set a new ptime, how it chose to change the ptime when the bandwidth estimation stabilized, etc. But this is probably not the right place to discuss this. Maybe face-to-face one day, or by email. I would be happy to discuss off line. -- GitHub Notification of comment by rshpount Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-537621055 using your GitHub account
Received on Wednesday, 2 October 2019 18:27:48 UTC