There seems to be agreement to add support for referenceScaling in Media Capabilities (https://github.com/w3c/media-capabilities/issues/182) so I'm assuming that a PR will follow.
Chris - please jump in if I'm misunderstanding the consensus on Issue 182. RTCRtpEncodingParameters.scalabilityMode <https://www.w3.org/TR/webrtc-svc/#rtcrtpencodingparameters> (Section 5.1) is required in order to set the scalability mode in RTCRtpSender.setParameters() as well as addTransceiver(). There has been no discussion of removing it. On Wednesday, December 15, 2021 at 12:01:32 PM UTC-5 Philip Jägenstedt wrote: > Hi Bernard, > > Can you clarify what the consensus is on RTCRtpEncodingParameters's > scalabilityMode member? That remains in https://w3c.github.io/webrtc-svc/, > but will it be removed? Meanwhile, referenceScaling is only partly spec'd, > there's no IDL for it but a link to > https://github.com/w3c/media-capabilities/issues/182. > > Harald, if you could confirm the precise API surface that you'd like to > ship, that would be great. > > Best regards, > Philip > > On Thu, Dec 9, 2021 at 3:21 AM Bernard Aboba <[email protected]> wrote: > >> Harald said: >> >> "It seems like we don't have a strong push towards either the >> MediaCapabilities or the Codec Capabilities solution in the issue on the >> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is bad >> for quick resolution." >> >> [BA] On the receiver/decoder side (for WebRTC-SVC, Media Capabilities and >> WebCodecs), we have a path forward which involves using a referenceScaling >> boolean and removing scalabiltyMode advertisement and configuration. The >> consensus is reflected in the current editor's draft of WebRTC-SVC (see: >> https://w3c.github.io/webrtc-svc/ ) and compatible PRs are under >> development for MediaCapabilities and WebCodecs. >> >> On the sender/encoder side, we have added the "L1T1" scalability mode and >> specified its use in both advertisement and encoder configuration. >> >> Chris can provide more details with respect to the moving parts in Media >> Capabilities and WebCodecs. >> >> Here are links to the (now resolved) WebRTC-SVC issues: >> https://github.com/w3c/webrtc-svc/issues/48 >> https://github.com/w3c/webrtc-svc/issues/52 >> >> Here are links to related WebCodecs issues: >> https://github.com/w3c/webcodecs/issues/399 >> >> Here are links to the related Media Capabilities issues: >> https://github.com/w3c/media-capabilities/issues/182 >> https://github.com/w3c/media-capabilities/issues/183 >> https://github.com/w3c/media-capabilities/issues/185 >> >> >> >> >> On Wednesday, December 8, 2021 at 9:37:57 AM UTC-8 Philipp Hancke wrote: >> >>> Am Mi., 8. Dez. 2021 um 17:52 Uhr schrieb Philip Jägenstedt < >>> [email protected]>: >>> >>>> Hi Harald, >>>> >>>> Can you spell out what the uncontroversial parts of this would be? >>>> Looking at the IDL in https://w3c.github.io/webrtc-svc/ it looks like >>>> it's all about modes. >>>> >>>> My guess is that it's RTCRtpEncodingParameters's scalabilityMode, but >>>> is that right? >>>> >>> >>> yeah >>> >>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24 >>> which is currently behind a flag. >>> >>> Best regards, >>>> Philip >>>> >>>> On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> It seems like we don't have a strong push towards either the >>>>> MediaCapabilities or the Codec Capabilities solution in the issue on the >>>>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is >>>>> bad for quick resolution. >>>>> >>>>> In the interest of getting the uncontroversial parts shipped - what >>>>> would people think of letting the Codec Capabilities list of modes remain >>>>> behind the flag, and push the rest of the API to public? >>>>> Many usages of the function would work quite well with only probing >>>>> for supported modes by trying to set the ones they want; we could then >>>>> let >>>>> the issue sort itself out in peace. >>>>> >>>>> (On the receiver side, there seems to be consensus on abandoning the >>>>> mode list for other reasons.) >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 24, 2021 at 3:21 PM Mike West <[email protected]> wrote: >>>>> >>>>>> Friendly ping on Yoav's question about timelines. >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> How long of a delay are we talking about here? Weeks? Months? Years? >>>>>>> >>>>>>> On Monday, October 25, 2021 at 11:00:46 PM UTC+2 Harald Alvestrand >>>>>>> wrote: >>>>>>> >>>>>>>> The scalability modes (being able to set them) are the point of the >>>>>>>> launch. >>>>>>>> Figuring out which of the desired ones are available seems like it >>>>>>>> would be a requirement. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Oct 25, 2021 at 9:32 PM Fernando Serboncini < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> It seems they are asking for a delay on Chrome launching this >>>>>>>>> until the WebRTC WG makes a decision on it. >>>>>>>>> It's not clear from the issue that there's a consensus on the >>>>>>>>> right approach there. >>>>>>>>> >>>>>>>>> Did you consider launching things separately and delaying the >>>>>>>>> scalability modes? Or does the whole launch make no sense without it? >>>>>>>>> >>>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1197505b-23e6-491a-8fc6-4b386cce0bcen%40chromium.org >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1197505b-23e6-491a-8fc6-4b386cce0bcen%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVHmEvq6MANGA078Fa9TqQe63b3QS5icAFaLbjH34ETfmw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVHmEvq6MANGA078Fa9TqQe63b3QS5icAFaLbjH34ETfmw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdU%2BkKr%3DqETzu8fBD6VmqGDQJwEuiXtn%2BKO-EtbDnquvg%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdU%2BkKr%3DqETzu8fBD6VmqGDQJwEuiXtn%2BKO-EtbDnquvg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb92597a-f71a-4280-825c-5ddfadc45b62n%40chromium.org.
