W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2017

Re: Temporal and spatial scalability support on RTCRtpEncodingParameters

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Thu, 21 Sep 2017 23:27:01 +0000
To: Iñaki Baz Castillo <ibc@aliax.net>
CC: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <8E2B3165-C9F6-4F67-A334-D81F0BAD9C7E@microsoft.com>
On Sep 21, 2017, at 1:46 PM, Iñaki Baz Castillo <ibc@aliax.net<mailto:ibc@aliax.net>> wrote:

On Thu, Sep 21, 2017 at 6:30 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:

The app needs to be able to have control of the encodings and browser needs to just enforce that the the boundaries placed by other envelopes such as SDP and congestion controls are not exceeded.

SDP? should I understand that there are plans to make SDP still more complex and error prune by (somehow) signaling SVC layers on it?

[BA] SDP does support SVC negotiation but I don’t think that is relevant to JSEP. While SVC may need to be negotiated in H.264 (because decoders cannot necessarily decode anything an encoder can send), H.264/SVC is only supported in Edge (only in ORTC, not WebRTC API) and SVC is not negotiated in SDP for either VP8 or VP9 (and hopefully, AV1).

So I do not believe RFC 5583 is relevant to those video codecs or to any existing (or future?) WebRTC implementation.

In other words, setting SVC encoding attributes in RTCRtpEncodingParameters should never cause the negotiation-needed flag to be set.
Received on Thursday, 21 September 2017 23:27:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC