Re: Does addTrack require the streams argument?

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

Received on Wednesday, 25 November 2015 15:08:59 UTC