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:
> Some slides describing the proposal and the logic behind it are
> available here: 
> [AV1]
>     AV1 Bitstream and Decoding Process Specification
>     <>. Peter de
>     Rivaz; Jack Haughton. Alliance for Open Media. June 25, 2018. URL:

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.

Received on Wednesday, 10 October 2018 09:44:11 UTC