Re: Does addTrack require the streams argument?

Yeah, it looks like I switch #1 and #2.  Sorry for the confusion.

Obligatory video for this situation:

https://www.youtube.com/watch?v=ZWJo2EZW8yU

On Wed, Nov 25, 2015 at 11:37 PM, Adam Bergkvist <
adam.bergkvist@ericsson.com> wrote:

> I think the numbers got flipped in your descriptions below, but I think
> I got it. Regarding the default stream, I agree with you and it's pretty
> easy for the script to create a default stream if needed. Not checking
> if the track is in the supplied streams works for me.
>
> /Adam
>
> On 2015-11-25 23:55, Peter Thatcher wrote:
> > About #1:  I like the idea that .ontrack on the remote side doesn't have
> > any streams if none were in the call to addTrack.    That seems
> consistent.
> >
> > About #2: Why does it matter if the track in addTrack is a stream of the
> > given stream or not?  This is just the local side's way of saying what
> > should pop out on the remote .ontrack. If that's what the local side
> > *wants* to do, why not?  It's weird, but I don't see any benefit of
> > guarding against it.
> >
> > I'm in favor of filing #2 but not #1.
> >
> > On Wed, Nov 25, 2015 at 6:51 AM, Adam Bergkvist
> > <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>>
> wrote:
> >
> >       From this discussion I see two issues that could be filed.
> >
> >     #1 RTCPeerConnection.addTrack() should check if track is member of
> >     supplied streams
> >
> >     #2 Don't create a default stream in 'dispatch a receiver' steps
> >
> >     File?
> >
> >     /Adam
> >
> >     On 2015-10-23 19:44, Peter Thatcher wrote:
> >     > I think it should be optional.  I see it as perfectly valid for
> the JS
> >     > to want to addTrack on one side and see ontrack on the other and
> not
> >     > care about MediaStreams in between.  Requiring a MediaStream is
> just
> >     > extra burden for no benefit.
> >     >
> >     > On Fri, Oct 23, 2015 at 2:17 AM, Stefan Håkansson LK
> >     > <stefan.lk.hakansson@ericsson.com
> >     <mailto:stefan.lk.hakansson@ericsson.com>
> >      > <mailto:stefan.lk.hakansson@ericsson.com
> >     <mailto:stefan.lk.hakansson@ericsson.com>>> wrote:
> >      >
> >      >     Trying to resolve Issue #288 [1].
> >      >
> >      >     As Jan-Ivar points out, the addTrack method does not mandate
> the
> >      >     application to supply MediaStream(s). The question is if this
> >     is a
> >      >     mistake or not, i.e. that it should not be allowed to send a
> >     track
> >      >     without telling what MediaStream it should belong to at the
> >     remote
> >      >     (receiving) end.
> >      >
> >      >     I would argue that it should be OK to do so, mainly because I
> >     see no
> >      >     reason for mandating it, but also because it would not let us
> >     get rid of
> >      >     the default processing (creating a new MediaStream) at the
> >     receiving end
> >      >     if a track with no stream info is added since (?) this would
> >     be the
> >      >     situation in many cases when the sending device is not a
> >     browser, but
> >      >     some other kind of (legacy-ish) device.
> >      >
> >      >     Also, note that there is no check on whether or not the track
> >     is member
> >      >     of the MediaStream(s) given to addTrack at the sending end -
> >     the API
> >      >     allows for making the track member of a MediaStream on the
> >     remote end
> >      >     even if it is locally not member of the corresponding
> >     MediaStream.
> >      >
> >      >     As for the larger question: 'Can a live track be consumed
> >     outside of a
> >      >     stream (assuming PeerConnection is a consumer)?' my take on
> >     that is
> >      >     "yes" and PeerConnection is the example. The gUM defines out
> >      >     _MediaStream_ consumers, but I don't see it prohibiting
> >     MediaStreamTrack
> >      >     consumers to be defined.
> >      >
> >      >     Views, comments?
> >      >
> >      >     Stefan (not having strong views, just wanting this to be
> settled)
> >      >
> >      >
> >      >
> >      >     [1] https://github.com/w3c/webrtc-pc/issues/288
> >      >     [2]
> >      >
> http://w3c.github.io/mediacapture-main/getusermedia.html#dfn-consumer
> >      >
> >      >
> >
> >
>
>