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

CONCLUSION on "onaddstream" and beyond

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 30 Nov 2011 10:51:20 +0100
Message-ID: <4ED5FC98.1040802@ericsson.com>
To: public-webrtc@w3.org
The conclusion of this discussion seems to be:

1. MediaStream objects should be created more or less immediately as 
result of "getUserMedia" or "addStream" operations (in the later case a 
MediaStream object on the remote side should be created as a result of 
the signaling).

2. There is a need to, on a MediaStreamTrack level, notify the 
application when live data is available (which can be a bit later than 
the creation of the MediaStream object).

The task is now on the Editors to change the drafts along these lines.

Stefan for the chairs

On 11/30/2011 05:27 AM, Justin Uberti wrote:
> That's the proposal for option #2. However, I think the second event
> would be broadcast when media is ready for playout, which may be
> slightly later than the instant when data arrives. This would allow the
> application to delay display of a video element until the first frame
> can be rendered.
> On Tue, Nov 29, 2011 at 4:43 PM, Aleksandr Avseyev <alexn74@gmail.com
> <mailto:alexn74@gmail.com>> wrote:
>     Oops. Sorry, meant option #2 and 2 events.
>     On Mon, Nov 28, 2011 at 9:04 PM, Harald Alvestrand
>     <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>         __
>         On 11/28/2011 07:30 PM, Aleksandr Avseyev wrote:
>>         Just a thought. Why we can't stay with #1 option but also add
>>         an extra event OnDataReceived() as well? As some people in the
>>         original discussion thread, I see use cases where it may be
>>         useful.
>         I'm not sure I count the options the way you do.... #1 option is
>         to only signal addstream() when the data arrives, which would be
>         the same time as a new ondatareceived() event.
>         I agree that ondatareceived() (probably a track-level, not
>         stream-level event) would be a nice complement in the #2 case
>         (where we signal addstream() when the stream's negotiated).
>>         On Fri, Nov 18, 2011 at 1: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.
>>             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 :-) ).
>>             Stefan
>>         --
>>         ------------------------------
>>         Regards, Aleksandr Avseyev (Futurewei Research Lab)
>>         www.pictures2.com <http://www.pictures2.com>
>     --
>     ------------------------------
>     Regards, Aleksandr Avseyev (Futurewei Research Lab)
>     www.pictures2.com <http://www.pictures2.com>
Received on Wednesday, 30 November 2011 09:51:45 UTC

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