Re: Update of RTCRtpSender "doohickey" proposal

On Mon, Apr 28, 2014 at 9:26 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> I like this.  I think that this makes for a good starting point for
> building the sorts of features Suhas was talking about enabling.
>
> Two comments:
>
> >   double               priority = 1.0;  // relative priority of this
> encoding
>
> This concerns me.  I'm not sure how I would convert a double-precision
> number into any of the primitive we've discussed thus far.
>

The intent was to indicate how bandwidth should be allocated between RTP
flows. Weighted fair queuing, or a similar algorithm, could be used to
determine the share of bandwidth that would be granted to a given
RTCRtpSender.

However, this particular knob is not critical to the overall proposal and I
can just strike it if controversial.


> > partial interface RTCPeerConnection {
>
> Does this need a lookup (track -> sender/receiver) ?
>

As Peter says, I'm inclined to leave this to a JS operation.

function findSender(track) {
  var senders = pc.getSenders();
  for (var i = 0; i < senders.length; ++i) {
    if (sender[i].track === track) { return sender[i]; }
  }
  return null;
}