Re: New issue: switching sources

On 19/05/14 22:54, Martin Thomson 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.

I think that the permission question is separate - the app needs 
permission to use both cams, and it can get that today.

Once the app has permission to use both cams, the local case is simple. 
Create a MediaStream with tracks representing both cameras, switch which 
one that is rendered with the "selected" attribute on the VideoTrackList 
in the media element.

The problem really comes when the consumer is on the other end of a 
PeerConnection. You can still do as for the local case: e.g. set up both 
tracks to be sent, toggle the enable at the sending side, and use 
mute/unmute events on the receiving side to toggle the "selected" 
attribute on the media element. But presumably enable/mute changes need 
signaling, so there would be SDPs exchanged.



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

Received on Tuesday, 20 May 2014 13:52:37 UTC