Re: Does addTrack require the streams argument?

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

Received on Thursday, 26 November 2015 07:37:41 UTC