webrtc支持单方分享么：WebRTC现状以及多人通话分析

webrtc支持单方分享么：WebRTC现状以及多人通话分析WebRTC的开发现状其实并不像大多数人所想象的那么简单，人们普遍的认为WebRTC的代码是开源的所以花很少的时间就能将其集成到项目中去，并且Google这么大的公司的产品质量一定没问题。但是在项目进行中，大家都会发现，WebRTC并不是一块Google白送到面前的肉。首先，编译WebRTC的源码就是一个比较大的挑战，搭建其复杂的编译环境往往会遇到很多意想不到的问题，导致当初计划用几个星期的时间来搞定项目，却发现这几个星期连编译都没搞定。还有，WebRTC中很多的参数都是由GIPS公司的工程师们依靠经验所设定的值，这就会出现卡顿、延时、回声、丢包、多人视频不稳定等问题，并且由于公网的稳定性或机型适配等外在因素，以上问题在项目上线后会更加严重。总而言之，WebRTC虽然提供了一套音视频实时通讯的解决方案，但是在实际应用中，由于网络传输、设备适配以及多方通话上都存在很多问题，效果并不理想。We

WebRTC 概述

WebRTC（网页实时通信技术）是一系列为了建立端到端文本或者随机数据的规范，标准，API和概念的统称。这些对等端通常是由两个浏览器组成，但是WebRTC也可以被用于在客户端和服务器之间建立通信连接，或者在任何其他可以实施WebRTC标准的设备之间进行通信建立。

WebRTC是一个开源项目，可在浏览器中实现无插件的实时通信（RTC）。它包括用于高质量通信的基本构建模块，例如用于语音和视频聊天应用的网络，音频和视频组件。这些组件在浏览器中实现时，可以通过JavaScript API访问，使开发人员能够轻松实现自己的RTC Web应用程序。

WebRTC由三个API组成：

• GetUserMedia（摄像头和麦克风访问）
• PeerConnection（发送和接收媒体）
• DataChannels（在浏览器之间直接发送非媒体）

WebRTC的目标是什么？

WebRTC旨在为开发社区提供开放，高质量的实时通信技术。在WebRTC之前，这种类型的RTC技术仅适用于能够负担昂贵的许可费用或通过AdobeFlash等专有插件的大型公司。WebRTC将为新一波视频，语音和数据Web应用程序打开大门。

WebRTC在哪里工作？

WebRTC目前支持Opera，谷歌Chrome版本23 和Mozilla Firefox版本22 Safari11 ，以及国内的QQ浏览器和360安全浏览器，WebRTC的开发得到了W3C，Google，Mozilla和Opera的支持。其他拥有该标准的包括苹果，微软，爱立信，思科和无数小型实时通信公司。

WebRTC重要性

WebRTC项目非常重要，因为它标志着强大的实时通信（RTC）标准首次开源供公众使用。它为新一波RTC Web应用程序打开了大门，这将改变我们今天的沟通方式。 显着更好的视频质量WebRTC视频质量明显优于Flash。 连接时间快6倍使用JavaScript WebSockets（也是HTML5标准）可以缩短会话连接时间并加速其他OpenTok事件的交付。 减少音频/视频延迟WebRTC通过WebRTC显着改善延迟，实现更自然，更轻松的对话。 免于Flash使用WebRTC和JavaScript WebSockets，您不再需要依赖Flash来实现基于浏览器的RTC。 原生HTML5元素自定义外观和使用视频，就像在HTML5中使用新视频标记的网页上的任何其他元素一样。

WebRTC实现了实时，无插件视频，音频和数据通信的开放标准。许多Web服务使用RTC，但需要下载，本机应用程序或插件。其中包括Skype，Facebook和Google Hangouts。下载，安装和更新插件很复杂，容易出错并且很烦人。插件很难部署，调试，故障排除，测试和维护，并且可能需要许可并与复杂，昂贵的技术集成。通常很难说服人们首先安装插件！WebRTC项目的指导原则是其API应该是开源的，免费的，标准化的，内置于Web浏览器中并且比现有技术更有效。WebRTC的API和标准可以使内容创建和通信工具民主化和分散化 - 用于电话，游戏，视频制作，音乐制作，新闻采集和许多其他应用。

WebRTC开发现状

WebRTC的开发现状其实并不像大多数人所想象的那么简单，人们普遍的认为WebRTC的代码是开源的所以花很少的时间就能将其集成到项目中去，并且Google这么大的公司的产品质量一定没问题。但是在项目进行中，大家都会发现，WebRTC并不是一块Google白送到面前的肉。首先，编译WebRTC的源码就是一个比较大的挑战，搭建其复杂的编译环境往往会遇到很多意想不到的问题，导致当初计划用几个星期的时间来搞定项目，却发现这几个星期连编译都没搞定。还有，WebRTC中很多的参数都是由GIPS公司的工程师们依靠经验所设定的值，这就会出现卡顿、延时、回声、丢包、多人视频不稳定等问题，并且由于公网的稳定性或机型适配等外在因素，以上问题在项目上线后会更加严重。总而言之，WebRTC虽然提供了一套音视频实时通讯的解决方案，但是在实际应用中，由于网络传输、设备适配以及多方通话上都存在很多问题，效果并不理想。

WebRTC多方方案Mesh架构

这是最简单的多人视频通话架构模式，所有媒体流都不需要经过服务端，客户端直接P2P，可通过WebRTC建立多个PeerConnection，结构图如下:

优点:

• 服务端压力最小，大多数情况下不需要用到流媒体服务。

缺点:

• 客户端负载太大，不事宜扩展，特别是移动端，编解码压力会非常大.

Mixer架构

视频会议基本上就是种结构，他的最大特点就是服务端做了很多事情，包括转码，混音，合屏，所以服务端负载非常大，结构图如下:

优点:

• 客户端负载最小，与一对一负载一样，所以理论上可以支持很多人同时视频。

缺点:

• 服务端负载很大，建设成本很高。
• 延迟问题，因为服务端做了很多动作（解码，合屏，混音，编码），所以会带来延迟。

C 音视频开发学习资料：点击领取→音视频开发（资料文档 视频教程 面试题）（FFmpeg WebRTC RTMP RTSP HLS RTP）

Router架构

该方案最大特点就是服务端只负责包转发，不负责转码，结构图如下：

优点:

• 与Mixer相比服务端压力比较小，而且容易扩展。
• 低延迟

缺点:

• 不同客户端能够接收的媒体流不尽相同，服务器端需要适配

开发者可以根据自身需求来定自己的方案，觉得哪个方案更贴近现实呢？