At the moment, I think we can safely ship: - RTCRtpEncodingParameters extension scalabilityMode ( https://w3c.github.io/webrtc-svc/#dom-rtcrtpencodingparameters-scalabilitymode )
We have an open discussion on whether or not to ship this part on senders (we've decided not to ship it on receivers): - RTCRtpCodecCapability extension scalabilityModes ( https://w3c.github.io/webrtc-svc/#dom-rtcrtpcodeccapability-scalabilitymodes ) There are no mandatory-to-implement scalability modes except for L1T1 (which we need to add support for). I think that as currently specified, feature detection can be done in the absence of the RTCRtpCodecCapability extension by setting the mode to L1T1, reading back the encoding parameters, and seeing if the mode is set. On Wed, Dec 15, 2021 at 6:01 PM Philip Jägenstedt <foo...@chromium.org> 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 <bernard.ab...@gmail.com> > 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 < >>> foo...@chromium.org>: >>> >>>> 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 < >>>> blin...@chromium.org> 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 <mk...@chromium.org> wrote: >>>>> >>>>>> Friendly ping on Yoav's question about timelines. >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss <yoav...@chromium.org> >>>>>> 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 < >>>>>>>> fs...@chromium.org> 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 blink-dev+...@chromium.org. >>>>>>> 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 blink-dev+...@chromium.org. >>>>> 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 blink-dev+...@chromium.org. >>>> >>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFHXy5%3DOtOMd9ariOw3-y9OtQ5YhdmDcNXbcExdK9ekOw%40mail.gmail.com.
