Re: What happened to onaddstream?

On 23 Jun 2015 10:58 pm, "Stefan Håkansson LK" <
stefan.lk.hakansson@ericsson.com> wrote:
>
> 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.)
> >
> >

At the very least were should keep a section of deprecated objects and
events around with an indication of what replaced them.

Regards,
Silvia.