了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
本文原文由声网WebRTC技术专家毛玉杰分享。
1、前言
有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,或许门槛如此之高的实时音视频技术终有白菜化的那一天。
补充:WebRTC标准草案的版本演进历史,请点击进入。
学习交流:
- 即时通讯开发交流3群:185926912[推荐]
- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》
(本文同步发布于:http://www.52im.net/thread-1631-1-1.html)
2、相关文章
《访谈WebRTC标准之父:WebRTC的过去、现在和未来》
《良心分享:WebRTC 零基础开发者教程(中文)[附件下载]》
《新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
3、实时通信技术的广阔前景
根据腾讯全球合作伙伴大会上发布的《2017 年微信数据报告》显示,截止到 2017 年 9 月,微信日成功通话次数 2.05 次,月人均通话时长 139 分钟,月人均通话次数 19 次。通过这些数据我们可以看到,微信视频通话的出现,已潜移默化地改变了人与人通信的方式。
而回望三大运营商的数据,语音通话量在 2015 年首次出现了负增长,可以看到互联网 OTT 应用对传统语音通话业务的冲击有多强烈。正是由于这些日益完善的基础设施,更快的智能手机,更快的网络,更丰富的使用场景,实时通信的需求越来越强烈。
从 2015 开始不断涌现出的互动直播、狼人杀、抓娃娃、直播答题、线上 KTV 等创新,将常见的线下场景转至线上,也足以作为实时音视频通信风头正劲的有力佐证。
越来越多的创业者都在思考如何将线下互动的场景搬到线上,从而打造下一个风靡全民爆款的应用。
说到实时通信,不得不提到 WebRTC,WebRTC 全名为 Web Real Time Communication,从 Web 这个词就可以看出,最初这项技术是为浏览器量身打造用以实时音视频能力而准备的。
但其实 WebRTC 在不同场景下包含不同的含义,它既可以代表 Google 开源的 WebRTC 项目,又可以代表 W3C 工作组制定的 WebRTC 标准,也可以代表浏览器中的 WebRTC 接口,我们将他们统称为 WebRTC 技术。当前具有实时音视频能力的应用或者服务,或多或少都使用了 WebRTC 技术,当然所有的这些背后都离不开 Google 开源的 WebRTC 项目,下面我们扒一扒 WebRTC 背后的故事。
4、WebRTC是什么来头?
说到 WebRTC,我们不得不提到 Gobal IP Solutions,简称 GIPS。这是一家 1990 年成立于瑞典斯德哥尔摩的 VoIP 软件开发商,提供了可以说是世界上最好的语音引擎。相关介绍详见《访谈WebRTC标准之父:WebRTC的过去、现在和未来》。
Skype、腾讯 QQ、WebEx、Vidyo 等都使用了它的音频处理引擎,包含了受专利保护的回声消除算法,适应网络抖动和丢包的低延迟算法,以及先进的音频编解码器。
Google 在 Gtalk 中也使用了 GIPS 的授权。Google 在 2011 年收购了 GIPS,并将其源代码开源,加上在 2010 年收购的 On2 获取到的 VPx 系列视频编解码器(详见《即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生》),WebRTC 开源项目应运而生,即 GIPS 音视频引擎 + 替换掉 H.264 的 VPx 视频编解码器。
在此之后,Google 又将在 Gtalk 中用于 P2P 打洞的开源项目 libjingle 融合进了 WebRTC。所以目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在内的所有平台的 API,保证了 API 在所有平台的一致性。
基于这些先进技术,使用 WebRTC 的为我们带来的好处主要有以下几个方面:
免费的使用 GIPS 先进的音视频引擎,在此之前都需要付费授权;
由于音视频传输是基于点对点传输的,所以实现简单的 1 对 1 通话场景,需要较少的服务器资源,借助免费的 STUN/TURN 服务器可以大大节约成本开销;
开发 Web 版本的应用非常方便,使用简单的 JS 接口,无需安装任何插件,即可实现音视频互通。
5、WebRTC 标准掀起的影响
2017 年 11 月 2 日,在经历了 6 年的时间之后,W3C WebRTC 1.0 草案正式定稿。同样也是在 2017 年,Microsoft Edge 与 Apple Safari 也纷纷宣称了在其最新的版本里支持 WebRTC 1.0 标准 API。
虽然不同浏览器厂商在某些实现细节方面有所差别,比如 Safari 只支持 H.264,不同的 SDP 描述格式等等,但除了 IE 之外,所有主流浏览器 Google Chrome、Mozilla Firefox、Apple Safari、Microsoft Edge 都已经支持 WebRTC 1.0,所有浏览器之间无插件化的音视频互通已经成为一种可能。
即时通讯网注:为什么苹果等商业公司坚持H.264标准?这其实是以苹果为代表的商业公司或联盟和谷歌之间的音视频编码标准之争,详见《即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生》,但业界普遍认为至少目前看来H.264标准(下一代被称为H.265)各方面要优于VP8(下一代是VP9),具体请见《即时通讯音视频开发(十三):实时视频编码H.264的特点与优势》。
越来越多的终端设备上,无需借助任何插件或者 native 应用,通过打开网页链接,即可进行高质量的音视频通话,应用开发者也无需关注音视频引擎实现细节,大大节约了开发成本。
6、WebRTC广泛的适用场景
WebRTC 适用的场景可以说是非常广泛,很多行业结合实时通信都可以创造出非常有意思的场景,传统的实时通信应用场景主要是在视频会议、视频面试、VoIP 通话、呼叫中心,产品如 WebEx、Skype 等。
当下比较火的场景主要集中在社交、游戏、体育、电视、相亲类的直播,以及互动连麦、在线教育、在线医疗、金融证券在线开户、智能硬件(如无人机)、智能家居设备如摄像头监控以及智能语音设备。
当然 WebRTC 除了提供音视频传输功能,还有一个容易被忽略的功能就是数据传输。利用点对点的传输机制,一些开发者创造出了诸如 Webtorrent 以及 PeerCDN 这样的不经过服务器的数据传输网络服务。所以 WebRTC 非常适合用来打造实时通信的应用。
而直播作为当下的热点应用,肯定少不了对于 WebRTC 的使用,而这又要提到 rtmp。
7、从 RTMP 到 WebRTC
从应用角度来讲,受到用户使用习惯的改变,越来越多的直播产品都开始加入视频互通的功能。同时,像视频会议、视频核保一类的应用方式也在不断增加。这影响着技术选型的变迁。
RTMP(Real Time Messaging Protocol) 实时消息传送协议是 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。随着直播兴起,很多人都将它用在直播上。
在协议方面,rtmp 完全可以满足直播产品的需求,但由于其相对延时较高,不能满足视频互通的产品需求。于是大家很自然地将目光投向 UDP、QUIC(基于 UDP)一类延时更低的网络协议。
在技术框架方面,由于自研一套符合视频互通要求的通信系统相对复杂,不仅涉及网络传输、前端开发、移动端开发,还要解决音视频编解码中复杂的算法优化,对开发者的技术栈要求很高,所以越来越多的人选择 WebRTC。
目前来看,WebRTC 已经获得了越来越多浏览器厂商及相关技术厂商的支持,应用的前景将会更加广阔。
但是受限于 WebRTC 自身的一些缺憾,一般开发者都不是直接完全使用 WebRTC,而是根据实际场景基于 WebRTC 进行二次开发。WebRTC 本身并不是万能钥匙,不可能一套代码以及接口可以解决所有问题。
更多关于RTMP的知识,请见《基于RTMP数据传输协议的实时流媒体技术研究(论文全文)》、《基于RTMP协议的流媒体技术的原理与应用(技术论文)[附件下载]》。
8、WebRTC很优秀,但当前并非完美
WebRTC 是一个非常优秀的项目,直接拿来使用也存在以下问题,我们简单总结一下:
第一:WebRTC 使用的是对点对传输,虽然节约了服务器资源的开销,但实际使用时也带来了传输质量的问题,比如跨国以及跨运营商网络之间的传输质量往往很难保证,虽然 webRTC 有优秀的端对端质量控制算法,但在错综复杂的网络条件下,表现也很难让人满意;
第二:WebRTC 在移动端的表现也很难让人满意。早期由于缺少对于 H.264 编解码器的支持,使得移动端很长一段时间只能使用 VP8 软件编解码,导致在中低端手机上的表现较差,加上安卓自身碎片化的属性,如果不针对不同机型做适配,很难有统一的用户体验;
第三:WebRTC 是为 1 对 1 通信场景设计的,如果要实现多人的场景,还是需要借助服务端方案。即使当前有很多开源的 webRTC 服务器实现,一个流媒体中转服务器或者混流服务器的部署以及维护也是非常复杂的;
第四:在 Web 端需要面临不同浏览器之间的兼容性问题。虽然使用 AdapterJS 可以解决不同浏览器之间的接口适配问题,但除此之外依然要面临不同浏览器行为不一致的问题。可以说如果 WebRTC 如果直接拿过来商用的话,几乎是不太可能的,当下普遍的解决方案是自研,根据自身的业务场景进行二次定制开发,或者更简单一点使用第三方 SDK。
不可否认,WebRTC确实很优秀,但目前来说也并非完美,更多这方面的分析和总结请参见《网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?》、《简述开源实时音视频技术WebRTC的优缺点》。
9、展望WebRTC
未来在实时通信领域,WebRTC 依然是非常重要的一块拼图。
无论是 Web 还是 Native,都非常依赖 WebRTC 提供的音视频引擎,尤其是在 Web 端,几乎所有浏览器厂商的实现都是基于 Google WebRTC 项目。随着 WebRTC 1.0 标准的定稿,各大浏览器的 WebRTC 接口已经基本得到统一。
一直以来,WebRTC 都缺少测试工具。在去年年底,Google 推出了 KITE 开源项目,用于帮助开发者检测 WebRTC 应用在不同浏览器的互通性。对于标准化社区来讲,下一步工作主要会围绕提供一组更完备的测试套件,不仅可以帮助开发者测试 WebRTC 应用在 Web 端、Native 端的互通性与体验,还有助于保证各厂商浏览器 WebRTC 接口功能的一致性,并逐步完善 WebRTC 缺失的功能。
在相关技术方面,QUIC 也进入更多人的视野。对于 WebRTC 来讲,QUIC 可以加速数据通道的连接(至少原理上可行),还可以完全替代 SCTP。但问题是,目前支持 QUIC 的浏览器只有 Chrome 和 Opera。(有关QUIC协议的基本介绍和应用案例,请见《技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解》、《让互联网更快:新一代QUIC协议在腾讯的技术实践分享》)
另一方面,各浏览器也在持续不断地修复问题,对不同硬件设备以及系统平台进行适配,保证 WebRTC 能稳定运行于除主流机型、系统版本以外,更多的设备上。
附录:更多实时音视频技术资料
《即时通讯音视频开发(五):认识主流视频编码技术H.264》
《即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发(十):实时语音通讯的回音消除技术详解》
《即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发(十三):实时视频编码H.264的特点与优势》
《即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发(十六):移动端实时音视频开发的几个建议》
《即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生》
《学习RFC3550:RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究(论文全文)》
《还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘:支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际:实现一个简单地基于HTML5的实时视频直播》
《首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?》
《腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天》
《七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!》
《实时视频直播客户端技术盘点:Native、HTML5、WebRTC、微信小程序》
>> 更多同类文章 ……
(本文同步发布于:http://www.52im.net/thread-1631-1-1.html)
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
浅谈GPU虚拟化技术(四)- GPU分片虚拟化
作者:郑晓,龙欣,弹性计算异构计算项目组 让各位久等了,阿里小二这就开始上新菜:“GPU分片虚拟化”。 对于“分片”的理解,相信大家已经不陌生了。此处的分片从两个维度上来定义:其一,是对GPU在时间片段上的划分,与CPU的进程调度类似,一个物理GPU的计算engine在几个vGPU之间共享,而调度时间片一般都在1ms-10ms左右,其二,是对GPU资源的划分,主要是指对GPU显存的划分,以NVIDIA为例,一个物理GPU带有16GB的显存,那么按照16个vGPU来划分,每个vGPU得到1GB的显存。由于安全隔离的要求,每个vGPU独享分配给它的显存,不会与其他vGPU共享。 技术上讲GPU分片虚拟化,就是指基于VFIO mediated passthrough framework的GPU虚拟化方案。该方案由NVIDIA提出,并联合Int
- 下一篇
DRDS 柔性事务漫谈
DRDS 是阿里云提供的一款分布式数据库产品,它的原型是在阿里内部使用了 10 年的数据库中间件 TDDL。DRDS 在 TDDL 提供的数据切分和 SQL 路由能力上,强化了分布式查询,事务和水平扩容能力。 什么是柔性事务? 在分布式数据库中,数据存储在多个节点将引入两个问题: 分布式事务 - 业务需要更新多个节点的数据。 全局二级索引 - 查询无法准确的定位数据位于哪个节点。 由于全局二级索引的同步依赖于事务,因此 分布式事务 是所有分布式数据库产品都需要解决的核心问题。这一问题的关键是 —— 数据存储在多个节点,原本在单机数据库上不难实现的 ACID 特性在分布式环境下变得困难: 因为网络通信的不可靠,事务的原子性需要用多次日志和网络通信来保证。 存储节点的增加,放大了单个存储节点在事务过程中出现故障的风险。 用锁实现的事务隔离性,在故
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8编译安装MySQL8.0.19
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境