Re: Some ideas on SVC support in WebRTC 1.0 (Take 2)

Inaki said:


"Absolutely. The question is: is that enough? I hope it is."


[BA] I don't think there's much downside to the simple proposal with temporal scalability since I've only seen this deployed with framerates differing in "powers of 2" (e.g. full framerate, 50 percent, 25 percent, etc.). So in practice, specifying the number of temporal layers seems to be all the configuration information needed.


There might be a need for more flexibility in spatial scalability configurations (e.g. the same degree of control that we provide for spatial simulcast in WebRTC 1.0).  However, at the F2F the group made it clear that temporal scalability was the first (and perhaps only) priority.


If all that is needed is to support temporal scalability along with spatial simulcast, then a single "temporalLayers" attribute could suffice.

________________________________
From: Iñaki Baz Castillo <ibc@aliax.net>
Sent: Tuesday, July 3, 2018 5:05:33 PM
To: Bernard Aboba
Cc: WebRTC WG; Robin Raymond
Subject: Re: Some ideas on SVC support in WebRTC 1.0 (Take 2)

On Wed, 4 Jul 2018 at 01:59, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:


[BA] If the desire is to make things as simple as possible, could we do something like this?


var encodings = [
  {
    rid: "L0",
    temporalLayers: 2,

    spatialLayers: 3

 }


The advantage of this approach is that the developer can't choose a nonsensical value of scaleFramerateDownBy.

Absolutely. The question is: is that enough? I hope it is.

Basically the RtpSender is given a MediaStreamTrack ad the app can already request some constraints for that track (assuming video) such as frame rate and resolution. Having that and also `temporalLayers` and `spatialLayers` for generating layers of less quality is good enough IMHO.

--
Iñaki Baz Castillo
<ibc@aliax.net<mailto:ibc@aliax.net>>