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

IMHO just setting number the temporalLayers and spatialLayers should be 
more than enough for webrtc 1.0 objects. Just a small nit, we should 
indicate that the degradation preferences of the send parameters will  
also affect how the browser drops top layers in order to save cpu/bandwidth.

For webrtc nv, if we decide to split the RTPSender into the rtp stuff 
and the encoder object, we would be able to provide a much better (and 
codec specific) API for SVC.

Best regards
Sergio


On 04/07/2018 2:22, Bernard Aboba wrote:
>
> 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>>