Re: ACTION-62, Priority API

On 2013-01-09 02:03, Justin Uberti wrote:
> This is an interesting proposal. However, given that the relationship
> between MediaStreamTracks and transports is can be fairly arbitrary (a
> track could be split onto multiple transports, or multiple tracks could
> be muxed on a single transport), I think this should have some other
> name, like EncodingController (since it really is controlling how the
> media is being encoded).

That is probably a much better name.

>
> The problem then becomes that encoding options are currently controlled
> by the SessionDescription, which indicates which codec to use, the max
> bitrate to send with, the SSRCs to use; as such adding a different
> control surface to control other encoding options like minimum bitrate
> makes things very complicated.

My idea was to avoid dealing with the session description as much as 
possible. If we use it the sequence would be something like:

1. Add stream
2. create offer
3. add min and max bitrate to offer
4. setLocal(offer).

But priority, DTX used or not need not be signalled, so they would need 
their own APIs, meaning:

1. Add stream
2. set DTX, prio (and other things not in the SDP)
3. create offer
4. modify offer
5. setLocal

I would prefer that we had an API that allowed the app to set (using 
constraints) the things it wants to, and have the settings that are part 
of the SDP being reflected in the offer created by createOffer.

>
> So I would suggest a fourth option, extending the RTCSessionDescription
> object with new methods to allow these additional encoding properties to
> be specified.

That is definitely an option (we add methods to the 
RTCSessionDescription for the things that are reflected in the SDP, and 
have separate APIs for the stuff that is not). But as said above, I 
prefer one API for all of this, and have what is set in that API 
propagate to the SDP.

>
>
> On Tue, Jan 8, 2013 at 9:17 AM, DRUTA, DAN <dd5826@att.com
> <mailto:dd5826@att.com>> wrote:
>
>     Hi Stefan,
>
>     I think your proposal makes sense and it has flexibility besides the
>     fact that it reuses some existing patterns.
>     There are two additional things we should consider and I'm not sure
>     how they would be reflected in the API yet:
>     1. When updating the priority on the track, if that track is part of
>     a bundle the browser should either throw an error or unbundle
>     automatically if the bundle contains tracks that have different
>     priorities. In any case, bundling will have a role in the
>     fulfillment of the priority request.
>     2. I think that RTCTransportHandler would need a convenience method
>     to return the 5 tuple to the developer. This will be used when
>     negotiating QoS with the network (if necessary).
>
>     Thanks,
>     Dan
>
>
>     -----Original Message-----
>     From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com
>     <mailto:stefan.lk.hakansson@ericsson.com>]
>     Sent: Tuesday, January 08, 2013 1:15 AM
>     To: public-webrtc@w3.org <mailto:public-webrtc@w3.org>
>     Subject: ACTION-62, Priority API
>
>     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:26:48 UTC