Re: ACTION-62, Priority API

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
>>
>>
<PrioAPI.pdf>
>

Received on Wednesday, 9 January 2013 08:39:55 UTC