[转载]WebRTC
WebRTC 百度 百科
Dongdong Deng
&& 写的WebRTC
Sam Dutton(Google Chrome Developer Relations) 写的WebRTC介绍
Harald Alvestrand写的RTCWEB Architecture
Colin Perkins & University of Glasgow写的WebRTC PPT
WebRTC :Ericsson Review 1.2012
WebRTC简介
WebRTC（Web Real-Time
Communication，网络实时通信）项目的最终目的主要是让Web开发者能够基于浏览器（ChromeFireFox...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序即可实现，W3C等组织正在制定Javascript
标准API，目前是WebRTC
1.0版本，Draft状态；另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。
WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。
WebRTC是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购Global IP
Solutions公司而获得一项技术.
&&&&&&&&谷歌日宣布向开发人员开放WebRTC架构的源代码。这个源代码将根据没有专利费的BSD（伯克利软件发布）式的许可证向用户提供。目前，开发人员可访问并获取WebRTC的源代码、规格说明和工具等。
Google希望开源的WebRTC技术能够获得越来越多的浏览器厂商支持，WebRTC的网站已经宣布将在Chrome、Firefox和Opera上实现相应的API接口。Opera首席技术官H
Lie对媒体表示，Google能够把价值不菲的代码贡献出来非常了不起，Opera一直希望能够在浏览器中实现实时通信技术。
目前有关Web实时通信的技术标准正在制定当中，W3C的Web Real-Time Communication工作组在May
2011成立，
W3C的最新标准见
&& 最新版本是W3C Editor's Draft
16 January 2013
Adam Bergkvist, Ericsson
Daniel C. Burnett, Voxeo
Cullen Jennings, Cisco
Anant Narayanan, Mozilla (until November 2012)
&& 从作者所属公司及排序中可见 W3C
支持者的情况。
WebRTC实现了基于网页的视频会议，标准是WHATWG
协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-Time Communications
(RTC)）能力。
HTTP-&WebRTC演进路径
& HTTP(Pre
AJAX):原始web，一页里发送请求后才返回另一页，如Geocities
& AJAX(2004)：更新页面不需要刷新.如GMail.
Sockets(2008)：页面能建立双向通信（通过服务器中介)，如Trello。
& WebRTC(2012)：页面之间的通信。
WebRTC的IETF标准
A Registry for WebRTC statistics
identifiers
H.264 as Mandatory to Implement Video
Codec for WebRTC
H.264/AVC as Mandatory-to-Implement Video
Codec for RTCweb
WebRTC Audio Codec and Processing
Requirements
Web Real-Time Communication (WebRTC):
Media Transport and Use of RTP
WebRTC Data Channel Protocol
Video codec for WebRTC.
SDP for the WebRTC
Support of SDES in WebRTC
Problems with WebRTC in Mobile
WebRTC Realization in Desktop Cloud
WebRTC的W3C标准
W3C的最新标准见
WebRTC架构图
架构图颜色标识说明：
（1）紫色部分是Web开发者API层；
（2）蓝色实线部分是面向浏览器厂商的API层
（3）蓝色虚线部分浏览器厂商可以自定义实现
Web API&&第三方开发人员用来开发基于Web的应用，如视频聊天。
WebRTC Native C++ API&&浏览器厂商用于实现Web API的函数集。
Session Management&&抽象session层，支持调用构建和管理层，由应用开发者来决定如何实现协议。
VoiceEngine&&音频媒体链的框架，从声卡到网络。
iSAC&&一种用于VoIP和流音频的宽带和超宽带音频编解码器，iSAC采用16 kHz或32 kHz的采样频率和12&52
kbps的可变比特率。
iLBC&&用于VoIP和流音频的窄带语音编解码器，使用8 kHZ的采样频率，20毫秒帧比特率为15.2
kbps，30毫米帧的比特率为13.33 kbps，标准由IETF RFC 定义。
Voice&&动态抖动缓存和错误隐藏算法，用于缓解网络抖动和丢包引起的负面影响。在保持高音频质量的同时尽可能降低延迟。
VideoEngine&&视频媒体链的框架，从相机像头到网络，从网络到屏幕。
VP8&&来自于WebM项目的视频编解码器，非常适合RTC，因为它是为低延迟而设计开发的。
Image enhancements&&消除通过摄像头获取的图片的视频噪声等。
Architecture layers
● Data transport
○ Data path establishment: NAT traversal using ICE
○ Transmission: UDP (TCP backup)
○ Congestion management
● Data encapsulation
○ RTP
○ Some non-RTP method for non-media data
● Data formats
○ Codec choices go here
● Connection management / signaling
● Presentation and control
● Local system support functions
Security in context
● All components (except the RTCWEBimplementing browser) must
be assumed evil
● Browser that executes JS using RTCWEB is&
responsible for both its own security and that of
victims it can reach (such as other tabs in the same browser,
or other devices on the same LAN)
● Keep trust to a minimum
Data Transport
● Data path establishment: NAT traversal using ICE
○ Secures against "voice hammer" attacks
● Transmission: UDP (TCP backup)
○ Relays are sometimes needed
● Congestion management is necessary
○ Self-fair
○ Plays well with others
○ Would be nice not to invent one here
Data framing and securing
● RTP exists. We will reuse it.
● We have no need to carry unencrypted data.
○ SRTP for media
○ DTLS for non-media data
● DTLS-SRTP key negotiation
○ SDES key negotiation allows for retrospective decoding of wiretap
data, reveals key to Web browser
● Note: UI issues are important for security
○ Mostly not IETF specs, but IETF knowledge informs W3C
discussions
Data formats
● Data formats must be negotiated
○ Any consenting adults can agree on a data format
● A mandatory to implement codec prevents interoperability
● Need to focus on requirements for the baseline case (where
MTI would come into play)
Connection Management
● Needed for setup:
○ Negotiation of data formats, transport options and security
parameters (incl keys)
● Needed while connected:
○ Reaction to changed connectivity and needs (ex:
resolutions)
● Least controversial proposal: ROAP
○ Specify a format for JS-Browser exchange
○ Usable as browser-to-browser format
○ Possible to gateway to SIP and XMPP
● We expect innovation in what-connects-to-what
● Active area of discussion!
Other Local Functions
● User action needs to cause net communication
○ Local and remote media mute -& stop/start
○ Display window size change -& change
resolution
● Functions are needed to achieve usable applications
○ Automatic Gain Control -& consistent audio
○ Acoustic Echo Cancellation -& no feedback
○ Dynamic jitter buffers -& consistent (low) playout
WebRTC的各种应用场景
&&&&&&&&&&&&Jingle(XMPP)
这种媒体流连接如何混音？如果在终端上混音，如何支持多达几十方的会议?
Signalling: make me an offer
1. Caller sends offer.
2. Callee receives offer.
3. Callee sends answer.
4. Caller receives answer.
Signalling: find me a candidate
1. Caller creates RTCPeerConnection object.
2. If success, callback passed IceCandidate.
3. Callee sends IceCandidate to callee.
4. Callee creates a new remote IceCandidate, adds to remote
description.
PeerConnection位于WebRTC Native C++
API的最上层，它的代码实现来源于libjingle（一款p2p开发工具包），目前被应用于WebRTC中。其中关键的两个类定义是：
class& PeerConnectionObserver {
virtual void OnError();
virtual void OnSignalingMessage(const std::string&
virtual void OnAddStream(const std::string&
stream_id,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
int channel_id,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
bool video);
virtual void OnRemoveStream(const std::string&
stream_id,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
int channel_id,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
bool video);
该类定义了一个抽象的观察者。开发人员应该继承实现自己的观察者类。
class& PeerConnection {
explicit PeerConnection(const std::string&
bool Initialize();
void RegisterObserver(PeerConnectionObserver* observer);
bool SignalingMessage(const std::string&
bool AddStream(const std::string& stream_id, bool
bool RemoveStream(const std::string&
stream_id);
bool Connect();
void Close();
bool SetAudioDevice(const std::string&
wave_in_device,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&
const std::string& wave_out_device);
bool SetLocalVideoRenderer(cricket::VideoRenderer* renderer);
bool SetVideoRenderer(const std::string&
stream_id,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
cricket::VideoRenderer* renderer);
bool SetVideoCapture(const std::string&
cam_device);
具体的函数说明可以查看相应的API介绍。
正如Google所说的，它一直在参与制定和实现HTML
5标准中的视频会议和p2p通信部分，虽然还不是正式标准，但是我们可以从草案的示例中看到未来Web开发人员的使用情况：
// the first argument describes the STUN/TURN server
configuration
var local = new PeerConnection('TURNS example.net',
sendSignalingChannel);
local.signalingChannel(...); // if we have a message from the other
side, pass it along here
// (aLocalStream is some GeneratedStream object)
local.addStream(aLocalStream); // start sending video
function sendSignalingChannel(message) {
... // send message to the other side via the signaling
function receiveSignalingChannel (message) {
// call this whenever we get a message on the signaling
local.signalingChannel(message);
local.onaddstream = function (event) {
// (videoElement is some &video&
videoElement.src = URL.getObjectURL(event.stream);
WebRTC架构组件介绍
(1) Your Web
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用。
这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data
API三类,。
Network Stream API
MediaStream：MediaStream用来表示一个媒体数据流。
MediaStreamTrack在浏览器中表示一个媒体源。
RTCPeerConnection
RTCPeerConnection: 一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
RTCIceCandidate ：表示一个ICE协议的候选者。
RTCIceServer:表示一个ICE Server。
Peer-to-peer Data API
DataChannel:数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道 。
(3) WebRTC Native C++
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。
&(4) Transport
传输/会话层
会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议&&
a. RTP Stack协议栈
&&&&&&&&&&&&
&Real Time Protocol
b. STUN/ICE&&
&&&&&&&&&&&&
& 可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。
c. Session Management
一个抽象的会话层，提供会话建立和管理功能。该层协议留给应用开发者自定义实现。
VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。
VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先。
Internet Speech Audio Codec
针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认的编解码器
采样频率：16khz，24khz，32khz；（默认为16khz）
自适应速率为10kbit/s ~ 52kbit/；
自适应包大小：30~60ms；
算法延时：frame + 3ms
Internet Low Bitrate Codec
VoIP音频流的窄带语音编解码器
采样频率：8khz；
20ms帧比特率为15.2kbps
30ms帧比特率为13.33kbps
标准由IETF RFC3951和RFC3952定义
c. NetEQ for Voice
针对音频软件实现的语音信号处理元件
NetEQ算法：自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小。
是GIPS公司独步天下的技术，能够有效的处理由于网络抖动和语音包丢失时候对语音质量产生的影响。
也是WebRTC中一个极具价值的技术，对于提高VoIP质量有明显效果，加以AECNRAGC等模块集成使用，效果更好。
&d. Acoustic Echo
Canceler (AEC)
回声消除器是一个基于软件的信号处理元件，能实时的去除mic采集到的回声。
e. Noise Reduction (NR)
噪声抑制也是一个基于软件的信号处理元件，用于消除与相关VoIP的某些类型的背景噪声（嘶嘶声，风扇噪音等等& &）
VideoEngine
WebRTC视频处理引擎
VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。
&&&&&&&&a.
视频图像编解码器，是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。
PS:VPx编解码器是Google收购ON2公司后开源的，VPx现在是WebM项目的一部分，而WebM项目是Google致力于推动的HTML5标准之一
b. Video Jitter Buffer
视频抖动缓冲器，可以降低由于视频抖动和视频信息包丢失带来的不良影响。
c. Image enhancements
图像质量增强模块
对网络摄像头采集到的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。
Developers
&&& 提供JS
API来实现音视频采集，传输，显示的Web应用
navigator.getUserMedia
&&&&&&&&&&&&&&&
navigator.getUserMedia('audio,video', Stream);
MediaStream
&&&&&&&&&&&&&&&
MediaStreamRecorder record();
&&&&&&&&&&&&&&&
void stop();
PeerConnection
&&&&&&&&&&&&&&&
sendSignalingChannel()
&&&&&&&&&&&&&&&
receiveSignalingChannel()
&&&&&&&&&&&
Record a short audio message and upload it to the server.
example1.txt:
PeerConnection Using example2.txt:
Developers
WebRTC from source:
&&& Create
a working directory, enter it, and run:
gclient config /svn/trunk
gclient sync --force
will generate native build files for your environment using
&&& Sample
application:
simple video chat client and server using the PeerConnection C++
PeerConnection C++ API
PeerConnection.htm:
代码库分析
WebRTC的视频部分，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。
视频采集---video_capture
源代码在webrtcmodulesvideo_capturemain目录下，包含接口和各个平台的源代码。
在windows平台上，WebRTC采用的是dshow技术，来实现枚举视频的设备信息和视频数据的采集，这意味着可以支持大多数的视频采集设备；对那些需要单独驱动程序的视频采集卡（比如海康高清卡）就无能为力了。
视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。
视频编解码---video_coding
源代码在webrtcmodulesvideo_coding目录下。
WebRTC采用I420/VP8编解码技术。VP8是google收购ON2后的开源实现，并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。
视频加密--video_engine_encryption
视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。
视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。
视频加密的数据源可能是原始的数据流，也可能是编码后的数据流。估计是编码后的数据流，这样加密代价会小一些，需要进一步研究。
视频媒体文件--media_file
源代码在webrtcmodulesmedia_file目录下。
该功能是可以用本地文件作为视频源，有点类似虚拟摄像头的功能；支持的格式有Avi。
另外，WebRTC还可以录制音视频到本地文件，比较实用的功能。
视频图像处理--video_processing
源代码在webrtcmodulesvideo_processing目录下。
视频图像处理针对每一帧的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。
视频显示--video_render
源代码在webrtcmodulesvideo_render目录下。
在windows平台，WebRTC采用direct3d9和directdraw的方式来显示视频，只能这样，必须这样。
网络传输与流控
对于网络视频来讲，数据的传输与控制是核心价值。WebRTC采用的是成熟的RTP/RTCP技术。
WebRTC的音频部分，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。
音频设备---audio_device
源代码在webrtcmodulesaudio_devicemain目录下，包含接口和各个平台的源代码。
在windows平台上，WebRTC采用的是Windows Core Audio和Windows
Wave技术来管理音频设备，还提供了一个混音管理器。
利用音频设备，可以实现声音输出，音量控制等功能。
音频编解码---audio_coding
源代码在webrtcmodulesaudio_coding目录下。
WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。
WebRTC还提供NetEQ功能---抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。
另外一个核心功能是基于语音会议的混音处理。
声音加密--voice_engine_encryption
和视频一样，WebRTC也提供声音加密功能。
该功能是可以用本地文件作为音频源，支持的格式有Pcm和Wav。
同样，WebRTC也可以录制音频到本地文件。
声音处理--audio_processing
源代码在webrtcmodulesaudio_processing目录下。
声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM、自动增益(AGC)、降噪处理等功能，用来提升声音质量。
网络传输与流控
和视频一样，WebRTC采用的是成熟的RTP/RTCP技术。
Google WebRTC官网上列表了使用WebRTC技术的四个理由：
&&&&&&&&互联网成功的一个关键因素是一些核心技术如HTML、HTTP和TCP/IP是开放和免费实现的。目前，在浏览器通信领域还没有免费、高质量、完整的解决方案。WebRTC就是这样的技术。
&&&&&&&&该技术已经集成了最佳的音频、视频引擎，并被部署到数以百万级的终端中，经过超过8年的磨练。Google不会从该技术中收取费用。
&&&&&&&&包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿越技术，并支持代理。&
&&&&&&&&构建在浏览器中，WebRTC通过提供直接映射到PeerConnection的信号状态机来抽象信号处理。Web开发人员因此可以选择适合应用场景的协议（例如：SIP、XMPP/Jingle等等）。&&
思考：Session Management 即
会话控制协议，如SIP、H.323
不在WebRTC的API库中，那么WebRTC只是做了媒体面的功能，不可能支持QQ这样的Message业务、在线地址簿。
也许未来会集成SIP协议栈在内，需要为服务器提供XMPP协议库。
或者终端与服务器之间采用http或自定义协议，而服务器之间采用SIP、XMPP协议。
webRTC主要是提供了音、视频编解码的免费源代码、SRTP、集成STUNICE技术、安全技术、及一个WEB终端的API库架构，让应用开发人员能够通过HTML标签和JavaScript
API就实现Web音频、视频通信功能。将促进互联网创新的实现，大量减少开发者的繁重开发任务，降低 创业型公司
创新的成本，
如果它要做点到点的通信，需要P2P连接。但实际上这样的应用模式（按IP地址来通信）是没有意义的。
而且它无法支持多方通信。
&&&&&&&&可行的应用模式仍需要IMPresence服务器支持，提供
多方通信、用户标识注册、增强地址簿（不光是电话号码）、在线状态、地理位置信息、与社交网络互通 等功能。仍需要STUNICE
Server来做到跨越私网的通信。
WebRTC是一个支持网络浏览器进行实时语音对话或视频对话的软件架构。WebRTC实现了基于网页的视频会议，同时通过无缝通讯和P2P全方位改变人们生活和工作的方式。
WebRTC是Web Real-Time
Communication（网络实时通讯）的缩写，是一项在浏览器内部进行实时视频和音频数据通信的技术，有望成为HTML5标准之一。 WebRTC的这些特性可以使网络应用进入一个新的阶段。
&& 异步Javascript和XML使开发者能够无需重新加载即可更新网页内容，而WebRTC堪称近年来最大的一次技术革新，加入了很多交互特性，为网络带了很多革命性的新&天赋&，这些&天赋&定会使网络世界向前迈一大步。
&& 如果说HTML5
已经让世人眼前一亮的话，那WebRTC
就是创新的集大成者。直接连接到其他浏览器为网络开发者提供了另一种新的可能性，用户间的直接互动革新了通讯和游戏应用的工作方式。现在的浏览器间要想实现直接通讯，必须借助第三方插件和专属服务器。而
WebRTC 拥有开放标准，使浏览器间直通很容易在互联网架构中实现。WebRTC
带来了诸多改进：越来越多的图像应用和视频应用开始支持移动浏览器；一些重大新闻能够第一时间通过手机传送到新闻机构；仅通过一行代码即可实现网页实时支持和反馈；无需软件实现文件分享。
在线实现视频、图像和音频分享跟浏览网页一样容易。开发者可以很轻易地将这些特性加入到产品中去。
的兴起之路也不得不考虑政治因素，P2P传输很难监管而且不好关闭。我们已经在某些场合见识了社交网络的威力，你能想象当社交网络插上了实时音视频通信传输的翅膀会擦出怎样的火花吗
WebRTC也会使电视会议和互联网技术市场大幅缩水，今后我们或许不会再需要Skype和Webex。将来， Skype、Cisco、和
Polycom的电视会议技术都将实现商品化。
互联网正在经历着新一轮创新浪潮，此次浪潮使多平台无缝通讯和P2P直接通讯成为可能.
这个标准建立起来后，很多传统的VoIP服务供应商将会逐渐衰落和死亡。那些一成不变的移动运营商将会面临用户的大量流失，因为他们会往新的服务提供商&迁移&。传统的固话销售和移动语音的使用将会慢慢消失，现在所流行的电话网络将会一去不复还。
回答：WebRTC本身没有提供什么新技术，只是提供了一个Web浏览器支持语音、视频应用的框架性标准与媒体面处理的免费代码。
未来利用webRTC推出新应用将非常容易。在它之前，互联网上已经有许多VOIP免费应用、许多免费代码库
可得到，PLMN走向衰亡是已经注定的，甚至被运营商所认可（LTE网络中已经没有CS域，只有基于VOIP的语音通信，只有RCS+IMS），webRTC会加速这个过程，但它并不是一个革命性的技术，不是杀手锏，杀手锏是LTEWiFi，正因为带宽提升，才导致Voip质量可以满足通信要求。
WebRTC堪称近年来最大的一次技术革新，加入了很多交互特性，为网络带了很多革命性的新&天赋&，而这些&天赋&使网络世界向前迈一大步。
当开发者希望使用音频或者视频通话时，可以直接使用已有的代码，唯一需要做的只需在移动设备上创建一个独立的应用程序。该标准提出后，许多传统的VoIP服务供应商将逐渐衰落和死亡。传统的固定销售（电话销售）以及传统的语音设备将被淘汰，电话网络的形式已一去不复还了。这对于移动运营商来说将面临一种新的挑战。
回答：同上。webRTC不是革命，但它有可能成为一个催化剂，加速免费VOIP应用取代PLMN的步伐。
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。基于chrome的webrtc在web端能不能实现分辨率动态调整，回音消除等等？
1，还是必须要经过中转服务器对媒体流进行处理，能不能在web段进行处理呢？2，如果有中转服务器，可以对媒体流进行二次处理吗？比如二次编码，自适应编码？3.视频传输机制，chrome有没有做？还是传输方面，服务器端还要进行优化？谢谢各位大神！
按时间排序
谢谢邀请。我结合我最近几年对webrtc的追踪简要回到下你的问题。希望对你能有所启发分辨率调整，回音消除都是有的（最近google刚引入了一个新的AEC，叫DA-AEC, 具体优势我正着手研究）以下我只讨论使用webrtc进行P2P的实时音视频处理1，还是必须要经过中转服务器对媒体流进行处理，能不能在web段进行处理呢？
分辨率的动态调整在webrtc中（包括chrome中）是在网络出现抖动，经过预测，判断出网络状态不好而进行的自动调整。比如，一开始是720P的，经过一段时间的侦测，判断为网络状态不好了，就会按照算法，降低通信的分辨率（同时发生的，还会降低相应的framerate）。
分辨率的调整是应对网络情况的，这个在webrtc中是自适应的。如果是由于你的业务逻辑要考虑分辨率的调整，只从js层面去做，应该是要重新建立peerconnection，再升高或降低分辨率。
至于你说的中转服务器，应该就是一个MCU的例子，引入MCU是肯定做到任何你想做到得流媒体处理，但是如何做好，做的智能，并且与webrtc结合，会是一条艰难地路。2，如果有中转服务器，可以对媒体流进行二次处理吗？比如二次编码，自适应编码？
有MCU得情况，这些当然是可以做的，问题是你需要清楚，MCU的加入会打断普通P2P的webrtc的整个通路，如何更好地把webrtc用到有MCU得架构中，是一个很深得课题。解决client-&MCU-&client这样的问题之后，二次编码，自适应编码都是现成的东西。请先去了解目前行业内现有的MCU产品，再去考虑用webrtc+中转服务器的解决方案。后者目前都有一些尝试，请自行google。
这里做个广告，可以去看看我司所做的尝试, intel CS solution for webrtc3.视频传输机制，chrome有没有做？还是传输方面，服务器端还要进行优化？
请再仔细考虑你的问题，引入MCU之后，有两方面的传输，chrome -& MCU， MCU-&Chrome，你需要定义两者之间的传输通道，目前来说你既然用了webrtc，两端都要符合webrtc的传输约定（rtp, rtcp），是否要做更多传输控制及特殊的优化，要结合你们自己的产品形态来判断。大概就这么多，希望能对你有所帮助。
谢邀。但我首先得说抱歉，我最开始做WebRTC的时候，大概是2013年初的样子，虽然跟了那个案子两年多才放手，但后期我已经没有很仔细地研读相关的技术文档了。而WebRTC技术又是一个发展较快的新技术，所以我下面所说的内容可能已经是过时的了。1、还是必须要经过中转服务器对媒体流进行处理，能不能在web段进行处理呢？我假设你所说的对媒体流进行处理指的是“实现分辨率动态调整，回音消除”，那么我的答案是不能在web端进行处理，必须去中转服务器做。我原来在看WebRTC的API文档的时候，Chrome给的API还非常简单，真的是非常非常简单。基本上除了基本的媒体流捕获、链接建立、媒体流传输之外，就没什么别的接口了。
说客户端回声消除可以做，我不知道是怎么做的，起码我当时没有看到相关的API接口。我猜他说的是 Audio API吧，那套API确实有很强的音频处理能力，但是，WebRTC获取音频的API和Audio API完全没有任何关系，WebRTC并不能把Audio API的输出作为输入，所以我认为是不能做客户端回声消除的。2、如果有中转服务器，可以对媒体流进行二次处理吗？比如二次编码，自适应编码？可以。但是，你要注意Chrome本身支持哪些编码方式，显然并不是所有的编码方式他都支持。3、视频传输机制，chrome有没有做？还是传输方面，服务器端还要进行优化？从我之前做的案子的经验来看，Chrome在传输这块做得还是不错的，带宽的使用量并不是很大。当然，这个主要还是和视频的分辨率，质量，编码方式相关。传输需不需要优化，这个我建议你还是先自己搭个环境试试。我之前的案子的使用环境是高带宽（10M以上），低延迟的网络环境，如果你要把这个技术用在移动互联网上，可能还是会有些东西需要研究。最后，我要再强调一下以上观点都是基于我2013年所阅读的技术资料而得来的。很可能有已经过时的内容，仅供参考。
已有帐号？
无法登录？
社交帐号登录}