W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: Question: how should addTrack work in relation to createOffer et. al.?

From: Justin Uberti <juberti@google.com>
Date: Wed, 29 Apr 2015 21:52:38 -0700
Message-ID: <CAOJ7v-1FtOtk7G_krhruDn4BZGkbFBBStCzOX2gr=LBCL+Ktaw@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Obviously I prefer a deterministic outcome. But I think it would be better
to not include trackY in the createOffer output - it seems unintuitive.

On Fri, Apr 24, 2015 at 8:38 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

>  On 4/23/15 8:34 AM, Stefan HÃ¥kansson LK wrote:
>
> The current spec is pretty clear on how addTrack works in isolation:
>
> a RTPSender is synchronously returned.
>
> However, how addTrack relates to related (enqueued) operations is less
> clear.
>
> As an example, for the sequence
>
> var senderX = pc.addTrack(trackX);
> pc.createOffer();
> var senderY = pc.addTrack(trackY);
>
> 1. would track/senderY be represented in the offer in any case?
> 2. if so, would it be consistently represented in the offer or would it
> depend on e.g. queue status?
>
>
> Sadly, I think this is nondeterministic today because of how our
> operations array is defined [1]: "If the length of the operations array
> is exactly 1, execute the function from the front of the queue
> asynchronously."
>
>
> Meaning the outcome can vary from run to run.
>
>  One way to spec this would be to say that createOffer takes a snapshot
> of the current senders when called, and changes between that snapshot
> and the actual execution of createOffer are not taken into account.
>
>
> Since JavaScript is a run-to-completion language, another (common?)
> approach would be to queue a (micro) task to execute the asynchronous
> operation, as I've just proposed today here in another thread.
>
> Not only would this unify behavior between when something is on the queue
> vs. when nothing is on the queue, but it would make the following
> deterministic:
>
>   var senderX = pc.addTrack(trackX);
>   pc.createOffer();
>   var senderY = pc.addTrack(trackY);
>   // Both trackX and trackY will always be in the offer.
>
>
> No copying of state needed.
>
>  Is this the way we should go?
>
> (This relates to github Issue #156 for webrtc)
>
> Stefan
>
>
> .: Jan-Ivar :.
>
> [1] http://w3c.github.io/webrtc-pc/#operation
>
>
Received on Thursday, 30 April 2015 04:53:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC