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

Re: ACTION-62, Priority API

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 9 Jan 2013 09:39:31 +0100
Message-ID: <50ED2CC3.3090103@ericsson.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2013-01-09 04:11, Cullen Jennings (fluffy) wrote:
> 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

That is definitely the simplest approach.

pc.setPriority(track, value);

What I fear is that we will see the need for more and more settings down 
the road (setBitrate, setDTXOperation, ...), so if we use this approach 
I would prefer using constraints:

pc.applyConstraints(track, constraints);

But, one of the discussions we need to have is the rejection of tracks 
and streams. Having an object that represents the transport of a track 
would be one good place to inform the sending app if a track was 
rejected (I called it "removed" in the proposal). If we have nothing 
like that I don't know how to inform the app.

> 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
Received on Wednesday, 9 January 2013 08:39:55 UTC

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