Re: Some questions about RTCRtpEncodingParameters...

On Mon, May 5, 2014 at 4:36 PM, Bernard Aboba
<Bernard.Aboba@microsoft.com>wrote:

>  Another set of questions I had about the Editor’s draft relates to
> RTCRtpEncodingParameters, which is defined as follows:
>
>
>
> dictionary RTCRtpEncodingParameters {
>
>     unsigned int?        ssrc = null;
>
>     DOMString?           codecName = "";
>
>     RTCRtpFecParameters? fec;
>
>     RTCRtpRtxParameters? rtx;
>
>     double               priority = 1.0;
>
>     double               maxBitrate = null;
>
>     double               minQuality = null;
>
>     double               frameratebias = 0.5;
>
>     double               scale = null;
>
>     boolean              active = true;
>
>     DOMString?           encodingId;
>
>     sequence<DOMString>  dependencyEncodingIds;
>
> };
>
>
>
> To take this for a spin, I looked at how it might be used to handle a few
> use cases:
>
>
>
> a.       Temporal scalability;
>
> b.      Spatial simulcast combined with temporal scalability.
>
>
>
> Maybe it’s just me, but it seemed that there was some missing
> functionality.
>
>
>
> For example, while the encodingId and dependencyEncodingIds can be used to
> set up layering, to do layering and simulcast together requires setting up
> multiple sender objects.
>

​Why?  Can't you express a mix here?​



> This leaves the application having to deal with tradeoffs between
> simulcast and layering, which could be challenging.  Also, the above
> RTCRtpEncodingParameters object doesn’t seem to be able to handle temporal
> scalabiltiy, only spatial (via the scale attribute).  This is because there
> is no “framescale” attribute to provide instruction on how to divide the
> framerate between the various layers.
>

​"framescale" sounds like an interesting knob to add.  Are you proposing
it?  ​



>
>
> Also, it occurred to me that a developer attempting to set up the
> RTCRtpEncodiingParameters object correctly might encounter quite a few
> challenges.    This object seems like it would be best set up automatically
> under the covers based on some general developer-provided preferences --
> something very high level like “I want SVC if it is available, figure out
> what will work best”.   The browser should be able to figure this out based
> on the “capabilities” of each peer, such as the number of layers that the
> encoder/decoder can handle of each layering type  (e.g. temporal, spatial,
> quality), or information about simulcast capabilities (e.g. the maximum
> number of simulcast streams that the encoder can handle).
>
>
>

​I think putting to much into the browser would be a mistake.  I think JS
and libraries would be better suited to handle these more advanced use
cases.

That said, we do need to make sure that our RtpCapabilties object provides
enough information to be able to do this.  Do you think it's lacking
something in particular?​





>  Some other questions relating to whether these attributes make sense for
> SVC at all.
>
>  For example, priority makes sense for specifying the priority between
> audio and video – but what does it mean when it is specified in individual
> SVC layers?
>

​Maybe it wouldn't.  But it does for simulcast, doesn't it?
​

>
>
> Similarly, minQuality might make some sense for a base layer (as might
> minFrameRate or minResolution), but what does it mean to specify this at
> each SVC layer?
>

​Maybe for SVC it doesn't.  But it does for simulcast, doesn't it?
​

>
>
> Also, is it necessary to provide a maxBitrate knob for each layer in SVC?
>

​Again, maybe not all knobs make sense for SVC.  So if you're doing SVC,
don't use the knobs that don't make sense.​



>
>
>
>
>
>
>
>
>
>