Re: Does addTrack require the streams argument?

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