Does addTrack require the streams argument?

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

Received on Friday, 23 October 2015 09:18:13 UTC