W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

Re: What happened to onaddstream?

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 23 Jun 2015 21:07:19 +1000
Message-ID: <CAHp8n2n4BK+kpWnNeLcy-ZHDYBzbjwWq4SShxRCqSJ3-vhCkvQ@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
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.

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.

Other than doing proper deprecation, it looks like this is probably ok.

Received on Tuesday, 23 June 2015 11:08:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC