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

"onaddstream" and beyond

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 18 Nov 2011 10:40:03 +0100
Message-ID: <4EC627F3.1050701@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>

recently there has been some discussion (the starting point was 
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?


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.

The question to this group is: should we stay with this model, or should 
we move to model 2)? I think regardless of model selected, it should be 
applied to both getUserMedia (i.e., if model 2 is selected, a 
MediaStream object is delivered immediately, and the application can 
detect when there is any media streaming in it) and PeerConnection 
creating MediaStreams.

I think we need to select one model! What are your preferences?
(Personally my preference would be to stay with 1) as it is to me 
conceptually simpler and that there are fewer things to add/change in 
the spec -  I worry about our schedule :-) ).

Received on Friday, 18 November 2011 09:40:47 UTC

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