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

Most pad and smarthphone, front and back camera has different quality.
Not to metion the high resolution local video file (720p?)
If we switch mediastream between them, and like what you said, you decoded-encoded-control-frame-by-frame,
the system may be slow down, if you use codecs in browser, it will be more slower.

The point is that we accept the renegoation rather then decode-encode operation to fit for previous SDP.
Renegoation is not serious, we can accept it, but we can not accept the performance degradation.

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

On 6/17/2012 2: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.
> 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.

It's possible that renegotiation might be required in *some* cases with
pre-encoded data from the camera, but not many (if any), since we need
to rate-control the data. We would need to decode the camera stream
(H.264 typically), then re-encode at the correct bitrate. Or we'll need
to change the camera bitrate targets on a frame-by-frame basis (unlikely).

-- 
Randell Jesup
randell-ietf@jesup.org

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