W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

Re: ACTION-62, Priority API

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Wed, 9 Jan 2013 03:11:08 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11336A555@xmb-aln-x02.cisco.com>

This seem far more flexible and complicated than needed. Lets just set a constraint on the track to integer value from 1 to 3, or 1 to 5

On Jan 8, 2013, at 2:15 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:

> ACTION-62, http://www.w3.org/2011/04/webrtc/track/actions/62, “Propose Priority API” was assigned to me at Lyon.
> 
> There are several way to do this, e.g.
> * Constraints at addStream time
> * Fortran style, e.g.
> ** pc.setPriority(track, priority);
> * Fortran style with constraints
> ** pc.applyConstraints(track, constraints); //constraint for priority included
> * Follow what we did for DTMF, allow the creation of a separate object
> ** pc.createTransportController(track);
> ** Operate on the “TransporController”.
> 
> After some thinking, I think I prefer the last solution (i.e. enable the creation of a separate object to handle transport related things) in combination with re-using constraints in the way Travis proposed in v6 [1].
> 
> There are a couple of reasons for this:
> * Constraints at addStream time can’t handle tracks added to a stream at a later time, nor does it allow for changes
> * I think we will not only want to change priority, but also things like bit-rate, video codec operation (CBR, VBR), DTX on/off, … - this means the Fortral style design would make the PeerConnection API grow a lot
> * Fortran style with Constraints is quite OK, but gives no natural place for reporting if during the session a constraint can (temporarily) not be met
> 
> So what I propose is basically:
> 
> * Add one new method to PeerConnection:
> ** createTransportHandler - takes a track (must be in a MediaStream in localStreams - otherwise there will be an error) as argument and returns a RTCTransportHandler object
> 
> * The RTCTransportHandler (and please propose better names!) uses constraints in the same way is outlined in section 6.2 of [1]
> ** Initial constraints are priority and bitrate - we can add later as we see need
> 
> This design is very similar to the one selected for DTMF, re-uses constraints and how they are proposed to be used with MediaStreamTracks.
> 
> I have attached a pdf with a more complete proposal.
> 
> Is this a reasonable approach?
> 
> Stefan
> 
> [1] http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
> <PrioAPI.pdf>
Received on Wednesday, 9 January 2013 03:11:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC