- From: Aleksandr Avseyev <alexn74@gmail.com>
- Date: Tue, 29 Nov 2011 13:43:27 -0800
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
- Message-ID: <CALBppDjCZZAKDTushSpGQ2aLw+5+ikH4+kptBP1VOjjsO2mqfQ@mail.gmail.com>
Oops. Sorry, meant option #2 and 2 events. On Mon, Nov 28, 2011 at 9:04 PM, Harald Alvestrand <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> 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 > > > -- ------------------------------ Regards, Aleksandr Avseyev (Futurewei Research Lab) www.pictures2.com
Received on Tuesday, 29 November 2011 21:43:58 UTC