Re: "onaddstream" and beyond

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>

Received on Tuesday, 29 November 2011 05:05:30 UTC