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

You said:  "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)."

But if the MediaStream  you choose to replace the existing one contain codecs that not supported by remote end, I think we still need renegotiation.
Or you can make sure that the browser can choose the same codecs as default with the replaced one, I think browser can not do this.

-----邮件原件-----
发件人: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 代表 Randell Jesup
发送时间: 2012年6月17日 8:39
收件人: rtcweb@ietf.org
主题: Re: [rtcweb] Mute implementations (Re: More Comments ondraft-ietf-rtcweb-use-cases-and-requirements-07)

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
randell-ietf@jesup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb