- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 30 Nov 2011 10:51:20 +0100
- 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