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

[Harald Alvestrand <[e-mail]>]

On 06/17/2012 08:48 AM, Sunyang (Eric) wrote:
> 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.
Alert.... a MediaStream doesn't contain a codec.

http://wiki.alvestrand.no/w/index.php/The_Byte_Stream_Fallacy

A MediaStream may be linked to a source that provides data in a given
codec format; it may be linked to a sink that accepts data in the given
codec format, and as a result the work that goes on to support the
moving of data from the source to the sink may be more or less complex.

But saying that a MediaStream "contains a codec" is (to my mind) not a
good idea.

> 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.
>
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Randell Jesup
> 发送时间: 2012年6月17日 8:39
> 收件人: [e-mail]
> 主题: 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).
>