design-reviews#441: WebRTC playoutDelayHint

#441: WebRTC playoutDelayHint

Visit on Github.

Opened Nov 25, 2019

Hello TAG!

I'm requesting a TAG review of the proposed WebRTC 1.1 extension:

Name: PlayoutDelayHint
Specification URL: w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-playoutdelayhint
Explainer, Requirements Doc, or Example code: discourse.wicg.io/t/hint-attribute-in-webrtc-to-influence-underlying-audio-video-buffering/4038
Tests: Blink wpt test.
Primary contacts: kuddai@webrtc.org, minyue@webrtc.org, hbos@webrtc.org

Further details:

I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
I have reviewed the TAG's API Design Principles

You should also know that:

To have the context on the current state of WebRTC 1.0 please refer to the webrtc-pc spec.
webrtc-extensions spec describes multiple WebRTC 1.1 extensions. Here, we are requesting review only for the playoutDelayHint extension.
Chrome implemented it starting from M79.
It is designed similarly to the AudioContextOptions latencyHint option.

We'd prefer the TAG provide feedback as (please select one):

open issues in our GitHub repo for each point of feedback

Discussions

Comment by @hober Dec 3, 2019 (See Github)

The specification URL you've provided is broken.

Comment by @kuddai Dec 3, 2019 (See Github)

Thank you. We recently have moved it. I have updated links now. Please note that most reason discussion is concentrated in this PR.

Discussed Feb 24, 2020 (See Github)

bumped to face-to-face

(lots of unminuted discussion before we realized there was no scribe)

Discussion of whether booleans are sufficient (they are certainly sufficient in theory but that doesn't make a nice API) for pseudo classes.

Discussion of getting feedback from CSS working group

Discussed Feb 24, 2020 (See Github)

Bumped to

Comment by @atanassov Mar 4, 2020 (See Github)

Reviewing with @hober and @ylafon during Wellington F2F. In general we like the proposal and use cases it addresses. There's only one issue to be addressed.

It is recommended that time based values are in milliseconds. Is there a reason you're deviating from this design principle?

Comment by @henbos Mar 6, 2020 (See Github)

Using double seconds is consistent with WebRTC's getStats() API which returns jitterBufferDelay. Setting this API affects the jitterBufferDelay, so it could be confusing if you set one to 1000 and expect the other to be 1.0. This is also consistent with the rest of getStats(), where time is always in seconds.

I don't know the reason why getStats() uses seconds though, but it's been the standard unit of measurement in WebRTC's stats. A wild guess would be that its an SI unit.

Comment by @atanassov Sep 24, 2020 (See Github)

Reviewing with @hober one more time during our Cork virtual f2f. Keeping the consistency with WebRTC makes sense, thanks for the explanation. At this point we are happy to sign off and close the issue.

@hober and @ylafon we should update the design principles with guidance around favoring milliseconds unless there is preexisting domain expectations, such as WebRTC.