Re: New issue: switching sources

If we just allow RtpSender.track to be settable, and that causes the
RtpSender to send media from track B instead of the previous track A, but
in the SDP it's still the MSID of track A, is that really so bad?  Why does
it matter?  Can't we just put a comment that says "setting RtpSender.track
does not cause renegotiation and does not change the ID of the track on the
remote side"?  That way, the application developers knows what they are
getting.

If we really need something that stays immutable and equal on both sides,
we could add an RtpSender.msid and RtpReceiver.msid.  But I don't see what
anyone would use that for.




On Mon, May 19, 2014 at 1:34 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> The scenario is simple: a user acquires a front-facing camera and wish
> to switch to a rear-facing camera.
>
> This currently requires all sorts of work: gUM, futzing with
> RTCPeerConnection, signaling/negotiation, manual switching of what is
> displayed at the receiver.
>
> The only method we have that would allow for seamless switching of
> sources is to use webaudio to switch between sources.  The identifier
> of the stream produced by the webaudio graph would be stable as a
> result.
>
> One reason that we don't have an elegant way to switch sources is that
> we have a very old decision to copy the identifier used at the sender
> through to the receiving end.  That decision constrains us.
>
> It's also possible that two tracks are incompatible, so we have to be
> prepared to deal with that possibility and have a way to signal errors
> (we couldn't switch out an audio track for a video track, same goes
> for tracks from cameras with incompatible hardware encoders).
>
> Potential solutions would be to:
>  - make the track id mutable so that you can change tracks; that makes
> MST.id basically useless, but then that was already the case when we
> allowed id to be duplicated.
>
>  - decouple the track identifiers and make a new API for switching
> tracks out; that makes it hard for us to manage the whole morass of
> msid and SDP mappings
>
> I think that's all there was.  The discussion was moving pretty fast.
>
>