Re: "onaddstream" and beyond

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>wrote:

> 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
>