Re: What happened to onaddstream?

On 23/06/15 13:35, Harald Alvestrand wrote:
> On 06/23/2015 01:07 PM, Silvia Pfeiffer wrote:
>> On Tue, Jun 23, 2015 at 8:18 PM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> On 23/06/15 12:05, Silvia Pfeiffer wrote:
>>>> On Tue, Jun 23, 2015 at 7:48 PM, Stefan Håkansson LK
>>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>>> On 22/06/15 21:38, Harald Alvestrand wrote:
>>>>>> On 06/22/2015 06:20 PM, Martin Thomson wrote:
>>>>>>> It's gone from the spec.  Everyone implements it.  It would seem to be
>>>>>>> necessary to document it, even if it is only under a "legacy" heading.
>>>>>>>
>>>>>> It went away when addStream() went away.
>>>>>>
>>>>>> Instead we have a "track" event that carries an RTCTrackEventInit,
>>>>>> containing a receiver, a track and an array of streams (section 5.4).
>>>>>>
>>>>>> It might be nice to have a separate "stream" event that fires only when
>>>>>> a new stream has been created; I don't think it's trivial to shim the
>>>>>> "stream" event based on only the information in "track" events.
>>>>> I agree that it is not trivial for the more advanced use cases. But for
>>>>> the simple ones that use only one MediaStream (with one audio and one
>>>>> video track) throughout the session it seems trivial. My question would
>>>>> be if there are many apps being more advanced around that motivate this
>>>>> addition when we're moving to a more track-based approach.
>>>>>
>>>> We have several applications that run 2 or 3 video tracks over one
>>>> connection. We particularly use it to get a face camera, a document
>>>> camera and a room overview camera together in one stream.
>>> But, as long as they are all in the same stream it is also trivial to
>>> emulate "onaddstream", right?
>> I did some more digging.
>>
>> Reading the spec, I stumble over both an ontrack and an onaddtrack
>> event. The ontrack event is used in Example 4 to replace the
>> onaddstream event from earlier on the RTCPeerConnection. The
>> onaddtrack fires on MediaStream directly.
>> So, we're really talking about the ontrack event here.
>>
>> It seems to me that ontrack has the exact same definition as
>> onaddstream, except it is a RTCTrackEvent (and not a MediaStreamEvent)
>> and can report the addition of multiple MediaStream objects in one go.
>>
>> http://w3c.github.io/webrtc-pc/#idl-def-RTCTrackEvent
>> I'm actually a bit confused about this description: it seems that a
>> track can be part of multiple streams there. That's not how I
>> understand MediaStreams to work - rather, a track would always be part
>> of one stream, but a stream could have multiple tracks.
>>
>> In any case, it seems that ontrack has replaced onaddstream with
>> almost identical functionality.
>> http://w3c.github.io/webrtc-pc/archives/20150202/webrtc.html#event-mediastream-addstream
>> http://w3c.github.io/webrtc-pc/#event-track
>>
>> Other than doing proper deprecation, it looks like this is probably ok.
>
>
> Not quite.... if I have track 1, 2 and 3, and 1 and 2 are part of stream
> A, and 3 is part of stream B, I'll get the events:
>
> track(1, A) (stream is new)
> track(2, A) (stream is old)
> track(3, B) (stream is new)
>
> The last one signals that a new stream has been created (B), but only
> because it's a stream I haven't seen before - so detecting new streams
> requires keeping a list of every stream you've previously seen and
> checking if the new stream is in the list or not.
>
> Doable, but not trivial.

I agree to this. But my previous comment come from that my impression 
was that we're deprecating MediaStream in the PeerConnection in favor of 
MediaStreamTrack. The stream info is there for legacy reasons, but you 
don't need to use it. You could just as well have just tracks 
("ontrack") coming out at the remote and, and signal by any means how 
they should be assembled into streams.

But if people think differently we should add "onaddstream" to simplify 
for app developers.

>
> (Note: In the old model you would get:
>
> stream(A)
> addtrack(1) (fired at A)
> addtrack(2) (fired at A)
> stream(B)
> addtrack(3) (fired at B)
>
> Easy to figure out which streams you get, need to add handlers inside
> the handler for the stream event to figure out which tracks you get.)
>
>
>
>
>
>

Received on Tuesday, 23 June 2015 12:56:16 UTC