W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2021

[webrtc-extensions] adaptivePtime prose unclear; concerns over lack of signaling (#74)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Apr 2021 19:47:25 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-865408559-1619120844-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-extensions:

== adaptivePtime prose unclear; concerns over lack of signaling ==
From @nils-ohlmeier in https://github.com/mozilla/standards-positions/issues/508:

> ...  I have a couple of concerns:
>   * https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-adaptiveptime says that `adaptivePtime` is a read-only parameter. That doesn't make much sense to me.
>    * From https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-adaptiveptime `If adaptivePtime is set to true, ptime MUST NOT be set...` which `ptime` does this refer to? I assume `ptime` in SDP, but that should be clarified.
>   * From https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-adaptiveptime `otherwise, InvalidModificationError MUST be thrown.` what means `otherwise`? If an application tries to set this to `false`? Or if the browser doesn't support this feature?
>   * From looking at [w3c/webrtc-pc#2309](https://github.com/w3c/webrtc-pc/pull/2309) it appears that the agreement is to not signal this. If that is the agreement I think the spec needs stronger wording around this feature that the app is only suppose to use this if it knows that the receiver supports it. So basically we assume knowledge in the app again about supported features on the receiver side. Which is highly problematic if we consider use cases where different audio goes to different endpoints. I'm concerned that in worst case a call can start and the person on the receiver hears the audio. But when the browser decides to switch the frame rate suddenly the user won't hear anything any more. Until the browser decides to switch to something which the receiver can handle. I'm not convinced the easier and faster deployment arguments raised in the GitHub issue warrant bypassing signaling.

See also https://github.com/w3c/webrtc-extensions/issues/69 for where `ptime` went.

Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/74 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 April 2021 19:47:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 22 April 2021 19:47:30 UTC