RE: Proposed Change to RTCRtpSender "doohickey" proposal

Few cents ...

[Cullen]
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.

[Suhas]

I tend to agree with Cullen here. 
The encoding parameters are negotiated based on the receiver's decoding capabilities. Thus it is the shared state between the sender and receiver we are trying to work with. OTOH, things like relative Priority, for example, can be scoped as local decisions  and thus need not be part of negotiation. 
Things like aspect ratios, frame-rates, parameters configuring encoding state of the video codec are co-dependent since they update the underlying shared resource and thus have to be configured so or such a guarantee be provided by the API.
 

Cheers
Suhas

________________________________________
From: Cullen Jennings (fluffy)
Sent: Wednesday, April 30, 2014 1:53 PM
To: Justin Uberti; Martin Thomson
Cc: public-webrtc@w3.org
Subject: 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 23:26:12 UTC