LGTM1 to ship scalabilityMode, but not the pluralized name or referenceScaling.
Please open a new intent if you wish to ship one of the others (otherwise this intent-to-ship would be too confusing). Thanks, and happy new year. On Mon, Dec 20, 2021 at 12:07 PM 'Chris Cunningham' via blink-dev < [email protected]> wrote: > Sorry I'm late. Lots of family stuff this month. I'm about to be OOO for > the holidays. > > > 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. > > I can confirm this agreement for MediaCapabilities. I expect +Johannes > Kron will send a PR to amend the MC spec. > > On Wednesday, December 15, 2021 at 3:14:42 PM UTC-8 Harald Alvestrand > wrote: > >> 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 <[email protected]> >> 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/f9e9006d-22be-4686-add7-1dcefe09a603n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f9e9006d-22be-4686-add7-1dcefe09a603n%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/CAOMQ%2Bw_AJUughhscpGnOQcnJBWQB0NrY-hsqd0Tag%2Bbhn0_9Cg%40mail.gmail.com.
