- From: chcunningham via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Oct 2021 00:16:21 +0000
- To: public-webrtc-logs@w3.org
For my part, I'm not opposed conceptually two having 2 ways. Maybe some developers will like MC for power info while others will like getCapabilities for the convenient single call. But, I do have some comments. > Since SVC is rarely supported in hardware (WebCodecs is shipping with no SVC support in hardware currently), WebRTC-SVC doesn't have the same level of privacy concerns. HW SVC support [is coming](https://bugs.chromium.org/p/chromium/issues/detail?id=1203743). Having said that, I don't think it will be particularly privacy sensitive. > getCapabilities is synchronous while codec enumeration is usually asynchronous, see discussion about getCapabilities results changing after the first createOffer/createAnswer call Worth highlighting. As we initially implemented SVC hw encode for WebCodecs, we (@Djuffin) were reminded that querying the platform encoder capabilities at browser startup is too slow. Async solves the issue. WebRTC may not feel this pain as long as it always has software fallback w/ capabilities matching/exceeding that of the hardware path. Maybe that's a safe assumption? > Applications might want to know about SVC referenceScaling support, which is only in MC. Still under discussion. [Might be abandoned](https://github.com/w3c/media-capabilities/issues/182#issuecomment-953386704). > One possibility is for MediaCapabilitiesInfo to directly provide a RTCRtpCodecCapability field when 'webrtc' is the provided MC type. From the MC side I'm open to adding this. We did a similar thing for MediaKeySystemAccess. I'm not very familiar with setCodecPreferences. Some sample code would help me evaluate effectiveness. > scalability mode info was added to MC for use by WebCodecs, not WebRTC. I think we crossed wires here. MC doesn't talk about WebCodecs at all. It really is intended for RTC use when type='webrtc'. But you're definitely right that no one is using it for this yet... Chrome hasn't shipped [this part of MC](https://chromestatus.com/feature/6242376685191168). Hoping to do that soon. > Similarly, "power efficiency" is more actionable in WebCodecs than WebRTC. WebRTC doesn't have the equivalent of WebCodecs HardwareAcceleration enum. I imagine this being used is as an input for codec selection. For instance, if your app's differentiating feature is battery-saving, maybe you use this to prioritize accelerated codecs during negotiation? Or, if your a cloud gaming service concerns about power, maybe you use this to determine what stream type to send down. I'm not an RTC expert though - lmk if I've overlooked something. -- GitHub Notification of comment by chcunningham Please view or discuss this issue at https://github.com/w3c/webrtc-svc/issues/49#issuecomment-953401087 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 October 2021 00:16:23 UTC