W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > September 2019

Re: [webrtc-pc] Add adaptivePtime to RTCConfiguration (#2309)

From: Roman Shpount via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Sep 2019 21:37:49 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-535695881-1569533867-sysbot+gh@w3.org>
First of all, audio frame size generally is done by the sender based on something that happens on the stream receiver. It can be triggered by RTCP statistics received by the sender, but doing this through signaling is generally not much slower. In other words, stream receiver can send an RTCP report which shows packet loss (or higher delay) or it can initiate another signaling exchange which will cause ptime to change. Time-wiser this is almost the same.

Codecs like Opus support a finite set of audio frame lengths. Codecs like G.711 can theoretically support any audio frame length dividable by 1/8 ms increment. For instance 27.5 ms frame is technically legal. This being said, jitter buffers often assume specific audio frame size and will not adapt to variable audio frame size. Because of this, when variable audio frame size is used, both sides should negotiate what frame sizes are supported in advance (i.e. specify that 5 ms, 10 ms, 20 ms, 30 ms, and 60 ms frames are supported and others are not). One added benefit of having a negotiated set, is that it makes interop testing easier. Properly testing that all possible frame sizes are supported (3 to 120 ms with 1/8 ms interval in any order), is a nightmare. Not testing this properly would likely lead to buffer overflow bugs due to extremely large frames or large number of packets in jitter buffer, that can result in serious security issues.

For me, ideal interface for this would be some sort of event on the receiver side signaling that ideal audio frame size should be X ms and a method on the sender side to set the audio frame size to X ms. Connecting the two, would be something application specific and can be done via signaling or data channel. Doing something automatic and implementation specific is tempting and makes initial feature adoption faster but will make it less usable in the long run.

-- 
GitHub Notification of comment by rshpount
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-535695881 using your GitHub account
Received on Thursday, 26 September 2019 21:37:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:29 UTC