LGTM3 On Wed, Jan 5, 2022 at 5:52 PM Daniel Bratell <[email protected]> wrote:
> LGTM2 > > /Daniel > On 2022-01-05 17:51, Chris Harrelson wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_AJUughhscpGnOQcnJBWQB0NrY-hsqd0Tag%2Bbhn0_9Cg%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/CAL5BFfWa2192FUDbR62FkeKEYmeUqrQm97xyBwcaOgWgsZBMog%40mail.gmail.com.
