Re: Revision of Scalable Video Coding Extension for WebRTC

Here is potential replacement text:


"

In response to a call to RTCRtpSender.getCapabilities(kind), conformant implementations of this specification MUST return a sequence of scalability modes supported by each codec of that kind. If a codec does not support encoding of any scalability modes, then the scalabilityModesmember is not provided.

In response to a call to RTCRtpReceiver.getCapabilities(kind), decoders that do not support decoding of scalability modes or that are required to decode any scalability mode (such as compliant VP8, VP9 and AV1 decoders) omit the scalabilityModes member. However, decoders that only support decoding of a subset of scalability modes MUST return a sequence of the scalability modes supported by that codec.

"

________________________________
From: Harald Alvestrand <harald@alvestrand.no>
Sent: Wednesday, October 10, 2018 2:43:42 AM
To: Bernard Aboba; public-webrtc@w3.org
Subject: Re: Revision of Scalable Video Coding Extension for WebRTC

Den 10. okt. 2018 00:49, skrev Bernard Aboba:
> The proposed SVC Extension for WebRTC has been revised in order to
> reduce the complexity for developers wishing to support Scalable Video
> Coding.
>
>
> The new proposal relies on the concept of "scalability modes" utilized
> in [AV1] as well as other SVC codecs.
>
>
> The revised proposal is here:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frawgit.com%2Faboba%2Fwebrtc-sim%2Fmaster%2Fsvc.html&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7C9f90bfd79c454cbd969d08d62e94e0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636747614309414143&amp;sdata=7TsspjI7nhYnUKSwpYjTjFPDcAZpcjATaOE5istZwlA%3D&amp;reserved=0
>
>
> Some slides describing the proposal and the logic behind it are
> available here:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F113UL2TpcXaYOmLw2GeDPjTqDeu2J5OWaqo_SYvzQvC4&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7C9f90bfd79c454cbd969d08d62e94e0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636747614309414143&amp;sdata=E9dPF9Am3H5rx07A%2FF%2F7XCWBNvhH3e9ObFWBsxA0Ifc%3D&amp;reserved=0
>
>
> [AV1]
>     AV1 Bitstream and Decoding Process Specification
>     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faomediacodec.github.io%2Fav1-spec%2Fav1-spec.pdf&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7C9f90bfd79c454cbd969d08d62e94e0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636747614309414143&amp;sdata=6BnPKtkc8O7PeJhWM2hr2dvugLz4HO4UBiC7VGHXAco%3D&amp;reserved=0>. Peter de
>     Rivaz; Jack Haughton. Alliance for Open Media. June 25, 2018. URL:
>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faomediacodec.github.io%2Fav1-spec%2Fav1-spec.pdf&amp;data=02%7C01%7CBernard.Aboba%40microsoft.com%7C9f90bfd79c454cbd969d08d62e94e0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636747614309414143&amp;sdata=6BnPKtkc8O7PeJhWM2hr2dvugLz4HO4UBiC7VGHXAco%3D&amp;reserved=0
>

Since the PR making this a document in the repo isn't yet merged, I
think it's appropriate to send mail rather than filing a bug:

Section 5.2:

- Conformant implementations of this specification MUST return a
sequence of supported scalability modes for each codec when calling
RTCRtpSender.getCapabilities('video'). Implementations MAY return
supported scalability modes for other values of kind.

- Conformant implementations of this specification SHOULD return a
scalabilityModes member for each codec supporting the decoding of
scalability modes when calling RTCRtpSender.getCapabilities('video).

I think the second one should say "when calling
RTCRtpReceiver.getcapabilities", otherwise there's a conflict in the spec.

I don't think it's appropriate to have a "MAY not" coupled with a
"SHOULD" for the receiver's decoding ability. Especially since the "*"
might not be a valid value to return for all codecs (what happens if you
want to use this API to nudge an H.264 encoder?).

We could make absence mean "no promises, I'll try", while '*' means "all
values in the specification are decodable"; I'd rather drop '*' altogether.