Re: WebRTC 1.0 Issue 412: Framerate knob for simulcast

At TPAC, there was consensus in the WEBRTC WG to add a knob to control framerate per stream when simulcast is used.

This especially makes sense in Screen Sharing scenarios, such as when it is desirable to create a simulcast stream for a mobile device (with a lower resolution and maximum framerate capability) and for a Tablet/PC which can handle a larger resolution and greater framerate.

If a maxFramerate attribute is added to RTCRtpEncodingParameters, it would then look like this:


dictionary RTCRtpEncodingParameters {

             unsigned long       ssrc<http://internaut.com:8080/~baboba/ortc/github/ortc.html#widl-RTCRtpEncodingParameters-ssrc>;

             payloadtype         codecPayloadType;

             RTCRtpFecParameters fec;

             RTCRtpRtxParameters rtx;

             RTCPriorityType     priority<http://internaut.com:8080/~baboba/ortc/github/ortc.html#widl-RTCRtpEncodingParameters-priority>;

             unsigned long       maxBitrate;

             double              minQuality = 0;

             double              resolutionScale;

             double              framerateScale;

             unsigned long       maxFramerate;

             boolean             active<http://internaut.com:8080/~baboba/ortc/github/ortc.html#widl-RTCRtpEncodingParameters-active> = true;

             DOMString           encodingId;

             sequence<DOMString> dependencyEncodingIds;

};

However, this raises some questions, including:


a.       What if framerateScale and maxFramerate are both set?

b.       What if maxBitrate and maxFramerate are both set?

c.       What is the meaning of minQuality, exactly?

d.       How do we determine the "RID" to be used with each simulcast stream?

e.       How is the receiver's maximum framerate capability determined?

Some thoughts:

a.       If framerateScale is set, then maxFramerate is ignored.

b.       The encoder attempts to take both the maxBitrate and maxFramerate constraints into account,  with the balance between them determined by RTCRtpParameters.degradationPreference.

c.       Not sure this really makes sense as a per-encoding parameter, given that we have degradationPreference as well as the other encoding parameters.

d.       The encodingId is placed into the RID.

e.       Not clear.  max-fr is a parameter for some codecs (e.g. VP8) but not for others (H.264).  It wouldn't necessarily have the same value for all codecs, since some codecs might support hardware decode (and therefore might be able to decode a higher framerate).  So it seems like we might need a maxFramerate attribute in RTCRtpCodecCapability.