W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: "onaddstream" and beyond

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 21 Nov 2011 10:10:17 +0100
Message-ID: <4ECA1579.2000101@alvestrand.no>
To: public-webrtc@w3.org
On 11/20/2011 08:55 PM, Justin Uberti wrote:
> On Fri, Nov 18, 2011 at 4:40 AM, Stefan HÃ¥kansson LK 
> <stefan.lk.hakansson@ericsson.com 
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>     Group,
>     recently there has been some discussion (the starting point was
>     <http://lists.w3.org/Archives/Public/public-webrtc/2011Nov/0015.html>)
>     on when the "addstream" event should fire (and a MediaStream
>     object should be handed over to the application):
>     a) Should it be when the signaling setting up the associated
>     RTP-streams over the PeerConnection happens?
>     or
>     b) Should it be when there is some data arriving (in at least one
>     track) for the MediaStream?
>     I think we've have concluded that there is a need for the
>     application to know when an incoming MediaStream has any activity
>     in it. This is automatic in the b) solution as the MediaStream
>     object will not be available before there is any content. But with
>     the a) model, there could be an attribute, or event fired
>     (possibly on the track level), in the MediaStream object that
>     informs the application on when there is any media actually streaming.
>     So basically there are two options:
>     1) Only create MediaStream objects when there is any media streaming
>     2) Create MediaStream objects immediately, and have properties of
>     the MediaStream tell the application whether or not any media is
>     streaming
>     Currently in the spec, model 1) is used. This is valid both for
>     getUserMedia (which operates asynchronously) and when an incoming
>     stream is being set up in the PeerConnection.
I would prefer model #2 (and augument it with callbacks that can tell 
you when tracks get added to the MediaStream, which is an event that 
happens per track).

I do think the right model is still to have all creation of streams go 
via async callbacks; the stream being ready doesn't have to happen 
"immediately" as in "synchronously".
Received on Monday, 21 November 2011 09:10:56 UTC

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