Re: ACTION-62, Priority API

I'm not happy with this proposal.

The need I see is for the Javascript to tell the media engine "this 
track is more important than that one". In some cases, the JS also knows 
things (like the maximum bandwidth available at the switching center) 
that the media engine cannot learn by itself, and it needs some means to 
inform the underlying system about that.

The complex API with the option of multiple settable properties for each 
track... I am not so happy with. It offers too much opportunity for the 
JS to specify constraints that can't be satisfied together.


On 01/08/2013 10:15 AM, Stefan Håkansson LK 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 10:34:25 UTC