Proposed Change to RTCRtpSender "doohickey" proposal

So this is probably the most important email I am sending on this thread … A small change that would make me like this doohickey proposal much more …

First would be a way to add a new encoding to a Sender or tell the sender to create another encoding or something like that. 

On Apr 28, 2014, at 9:58 AM, Justin Uberti <juberti@google.com> wrote:

> // used with RTCRtpSender
> interface RTCRtpEncodingParams {
>     double               priority = 1.0;  // relative priority of this encoding
>     unsigned int       maxBitrate = null;  // maximum bits to use for this encoding
>     boolean             active;  // sending or "paused/onhold"
> };

The second would be a way to update constraints at the encoding level, this would allow us to set things like resolutions, aspect ratios, and frame rates at the encoding level.  That is one one of the use cases driving doohickeys. 

The third would be a have RTCRtpReceiver also have a set of RTCRtpEncodingParams. 

I think we will need something like this to make this proposal work because what is sent over the wire is not solely selected by the sender but is a negotiation between the sender and receiver. 

I’m fine with priority, maxBitrate, and active remains roughly as they are in this proposal because those are unilaterally set per sender and are not bilaterally impacted by the remote side or by other senders on the same side.

Received on Wednesday, 30 April 2014 20:54:16 UTC