Re: "onaddstream" and beyond

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