Re: [rtcweb] Mute implementations (Re: More Comments ondraft-ietf-rtcweb-use-cases-and-requirements-07)

[Randell Jesup <[e-mail]>]

On 6/16/2012 5:58 PM, Jim Barnett wrote:
> It's capturing the requirement accurately that I'm concerned with.  I
> think "To be able to change the source of a video stream after its
> creation" is too broad, in the sense that someone might interpret it to
> mean that the system could shift from the front to the rear camera
> without asking permission.  For mute and hold, we want something like
> "switch to a dummy source and back".  The source that we switch to in
> cases like this is not a 'first-class' video source, but rather a
> place-holder.  That's very different from switching to another live
> source.

Which, by the way, we should be able to do.

MediaStreams need to be able to be repointed, switched, processed, etc, 
OR you need to be able to replace a MediaStream in the inputs to 
PeerConnection with another one transparently without renegotiation (and 
that misses a bunch of uses).

The MediaStream Processing provides a mechanism to do this for both 
audio and video, plus the ability to do more complex operations 
(cross-fades audio-and-video, frame-accurate source switches, etc).

If you don't have or use that, you need the ability to replace a track 
in a MediaStream with another track.

All we're talking about are mechanisms to shuffle existing or creatable 
tracks/streams; a new camera source would require a call to 
getUserMedia() and a dialog.  Once you had front and back, you could 
switch sources without effectively shutting down all media and restarting.

Simple one camera -> one video stream mechanisms are insufficient for 
application using these features.  If you force people, they'll roll 
their own using canvases, etc.

I want something generic and usable in lots of interesting ways, not a 
few special-purpose pre-coded mechanisms (for example, a 
track.setMuteImage() method).

-- 
Randell Jesup
[e-mail]