Re: ACTION-62, Priority API

On 2013-01-09 11:33, Harald Alvestrand wrote:
> 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.

That is basically what I propose - priority and bitrate (though bitrate 
per track - something that can be of interest in certain scenarios).

That there - since I propose we use constraints - is an opening to add 
more things in the future is another story.

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

I don't thing this is any different in this respect from any other API 
where we use constraints (rather the other way around if we allow only 
two constraints initially - compare this to the long list we're 
discussing for getUserMedia). The usual rule applies: unless you're 
really sure of what you're doing, avoid mandatory constraints.

>
>
> 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 12:15:35 UTC