Design Review #837

#837: WebRTC-SVC (Scalable Video Coding)

Opened Apr 25, 2023

I'm requesting a TAG re-review of WebRTC Scalable Video Coding.

WebRTC Scalable Video Coding allows to use the capabilities of modern video codecs to combine several video quality into a single encoded stream sent via WebRTC to an endpoint that can then dispatch the right substream to the different parties based on their receiving capabilities.

Explainer¹ (minimally containing user needs and example code): https://github.com/w3c/webrtc-svc/blob/master/explainer.md
Specification URL: https://www.w3.org/TR/2023/WD-webrtc-svc-20230417/
Tests: https://github.com/web-platform-tests/wpt/tree/master/webrtc-svc
User research: N/A
Security and Privacy self-review²: https://w3c.github.io/webrtc-svc/#privacy and https://w3c.github.io/webrtc-svc/#security
GitHub repo (if you prefer feedback filed there): https://github.com/w3c/webrtc-svc/
Primary contacts (and their relationship to the specification):
- Bernard Aboba @aboba (WG co-chair, spec editor)
Organization(s)/project(s) driving the specification: W3C WebRTC Working Group
Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/w3c/webrtc-svc/issues
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
- https://github.com/WebKit/standards-positions/issues/103
- https://chromestatus.com/feature/5769626174619648

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: [please provide]
The group where the work on this specification is currently being done: W3C WebRTC Working Group
Major unresolved issues with or opposition to this specification: N/A

You should also know that there was a previous review of this specification 4 years ago: https://github.com/w3ctag/design-reviews/issues/396

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Comment by @johnathan79717 Apr 26, 2023 (See Github)

The Security and Privacy self-review link is invalid. I think you mean https://w3c.github.io/webrtc-svc/#privacy and https://w3c.github.io/webrtc-svc/#security.

Comment by @Orphis Apr 26, 2023 (See Github)

We had a TAG review already done in #396 , is it not sufficient?

Comment by @aboba Apr 26, 2023 (See Github)

@Orphis I had the same question. The only major change in the API from the last TAG review was the use of Media Capabilities API instead of getCapabililties().

Comment by @dontcallmedom Apr 27, 2023 (See Github)

#396 is 4 years old; so this request is to check that the intervening changes (in this spec and in the platform in general) don't warrant new feedback

Comment by @dontcallmedom Jun 7, 2023 (See Github)

@torgo any ETA on this review? We're trying to assess when we might be ready to request CR

Discussed Jul 1, 2023 (See Github)

Dan: Dom was asking for a eta

Tess: only major change.. sounds like a good thing.

Dan: we reviwed media capabilities - satisfied with concerns. Concerns were that it was already shipping. Multistakeholder?

Tess: I think it has wider support

Dan: supported across all browsers according to MDN - data maintained by Open Web Docs - thank you Open Web Docs.

Tess: need to verify what they've said is the only substantive change.... doing a diff, looks like every word in the spec has changed. Could be editorial, but difficult to confirm the assertion that only one thing changed.

<blockquote> Hi folks -

Thanks for sending us this review. Given what @adoba wrote above concerning the changes and the fact that Media Capabilities API itself enjoys multi-stakeholder support, we'd like to close this review. However, it looks to us like a lot of additional changes were made to the spec. @dontcallmetom can you confirm that this is the only substantive change?

</blockquote>

Discussed Jul 1, 2023 (See Github)

Dan: dom got back to us.

Dan: I asked Dom about the dependency on the media capabilities API.. it looked like a lot of changes... Dom said it isn't the only substantive change, but probably the most impactful one. List of PRs seems fine. Good to close?

Tess: yes I'm not worried about anything in that list.

Rossen: close now?

Dan: Happy to close now.

closed

Comment by @hober Jul 13, 2023 (See Github)

@Orphis I had the same question. The only major change in the API from the last TAG review was the use of Media Capabilities API instead of getCapabililties().

It looks like almost everything in the spec has changed since our last review.

Comment by @torgo Jul 13, 2023 (See Github)

Hi folks -

Comment by @dontcallmedom Jul 13, 2023 (See Github)

This isn't the only substantive change, although it's probably the most platform-impacting one.

The list of non-editorial pull requests merged since the last TAG review can be classified as follows:

refinement to list of SVC modes: w3c/webrtc-svc#84 w3c/webrtc-svc#82 w3c/webrtc-svc#71 w3c/webrtc-svc#51 w3c/webrtc-svc#33 w3c/webrtc-svc#39
privacy impact of exposing capabilities (and its delegation to Media Capabilities): w3c/webrtc-svc#76 w3c/webrtc-svc#54 w3c/webrtc-svc#26
API clarification of behavior and error handling of reading and setting SVC modes: w3c/webrtc-svc#64 w3c/webrtc-svc#86 w3c/webrtc-svc#62 w3c/webrtc-svc#56 w3c/webrtc-svc#67 w3c/webrtc-svc#69 w3c/webrtc-svc#79
clarifications in Browser/SFU negotiation: w3c/webrtc-svc#53 w3c/webrtc-svc#35

Comment by @torgo Jul 17, 2023 (See Github)

Hi @dontcallmedom thanks for that clarification. On that basis we're happy to see this move forward. Thanks for bringing to us!