W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

Proposed Change to RTCRtpSender "doohickey" proposal

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Wed, 30 Apr 2014 20:53:48 +0000
To: Justin Uberti <juberti@google.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <8B6A3EAF-F1DE-4729-B5FB-9E3DD4330465@cisco.com>

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. 

Im 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC