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

> ptime can be taken from a range, but it is itself a single value, so I don't think we can use that to determine the range of allowed adaptive values.

No. My point here is that the current spec has an issue that ptime (in opus) restricts valid values. When JS attempts to set an invalid value like 42 what should  happen? I might head over to the other issue.

> maxptime is an Opus-specific fmtp line, so I'm not sure it's useful for a codec-agnostic flag.

its not, its in RFC 4566. minptime is not defined anywhere but https://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03 which didn't make it to the RFC.
Apart from that, what codecs beside Opus do support this even? I doubt G711 does, G722 may.
We do have a range defined by SDP. The big question is whether it is safe to vary within that range *without* negotiating that in the SDP. 

> The web-app can only call getStats so often. The browser is at a better position to make quick decisions about the frame length.

How dynamic are the adaptions required in practice? Also it might be useful to discuss scenarios... my favorite one is "swiss 2g" with a maximum bitrate of 200kbps, 200ms latency and 2% packet loss. Note that one of the key drivers for this is "we just lost wifi  and are now on 2g", i.e. the selectedcandidatepairchange event.

> It could be argued that this would not be making the Web better.

It could be argued that allowing more differentiation will make the web better. See a certain krankygeek talk last year.

One thing to keep in mind: when the network conditions are bad there are other things to consider such as turning off video or reducing the frequency of stun ping/pong (yes chrome, please be spec-compliant, there is an RFC for consent). Those conditions might require a more holistic approach.
Adapting ptime is part of the solution for sure!

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-535666801 using your GitHub account

Received on Thursday, 26 September 2019 20:09:26 UTC