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/e9b3fada-a314-47d3-8a99-f337ea80c4efn%40chromium.org.
