http://www.ox-holdings.com

随着直播的发展,实时音视频的开发学习有很多可以参考的开源项目

摘要2016年6月9日是开源实时音视频工程WebRTC开源5周年的日子,Google WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。前言2016年6月9日是WebRTC开源5周年的日子,Google WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。为了便于大家更好理解过去5年在WebRTC上都发生了什么,我将这两篇给翻译过来了。友情提醒:整个翻译并不是逐字逐句进行的,而是在理解了作者的意思后用自己的语言表达出来的,因为如果逐字逐句可能很多意思我们都无法正确理解。这就是为什么有些英文资料被翻译成中文后晦涩难懂。当然如果英语够好建议直接看原文。5年前的感慨今天谷歌开源了WebRTC技术,一个用于实时语音和视频通话的软件包,她即将被整合到Chrome。这是我们的第一波贡献,一切都是为了一个伟大的使命——在统一的标准的API下实现所有浏览器间的音视频通话。这个初始版本将提供我们设想的一些功能,具体详见: Harald)今天的总结今天,回首往事,我们可以很自豪地说:“我们实现了我们所有的目标。”现在音视频交互变得越来越重要,许多产品和服务都支持Web和Native之间的无缝交换,而他们之中绝大部分都是基于我们现在开放出的标准API——这些API的底层实现基本上都是基于WebRTC 。一套通用标准促进了整个行业的发展,Firefox、Opera和微软都已经在支持WebRTC技术了。这已经导致超过20多亿浏览器用户使用了WebRTC技术,仅仅Chrome上每周就有超过10亿分钟的音视频通话,以及超过500T的数据传输(通过WebRTC的数据通道)。WebRTC从一开始就秉持一种很开放的态度,向视频编解码免版税方向迈进。在WebRTC中80%音频通信采用Opus,而最近推出的VP9比VP8节省70%的带宽。由于VP9的努力发展,媒体开放联盟在视频编解码免版税道路上又多了一种选择,以及增加了更多的合作空间。今天,WebRTC技术在音视频领域已经证明了自己的强大,在接下来的几年里,我们期望看到一个更加强大的WebRTC。接下来我们会持续改进音视频质量。我们在WebRTC中愿意采用一些通用的编解码来实现交互通讯,但有一些互操作的问题要去解决。另外作为未来编解码的VP9,他后面在压缩率方面会持续改进,以便更好支持低带宽下的通讯。今天的通信都发生在许多不同网络条件下,从EDGE到LTE。WebRTC面临多样化的网络条件,所以必须能够做出相应的调整。所以我们一直在努力改善拥塞控制算法和优化媒体传输配置来适应各种状况,这里面也有很多机会和方法来改善和简化媒体协议以适应当今网络需求。五年前,大多数通信发生在桌面上。但现在一切都变了,WebRTC技术已经发展到要满足各种移动通信应用的需求。展望未来,还有很多机会,如VR。WebRTC这个平台只会随着时间推移而价值愈加明显,现在仅仅是开始。我们要做的就是:努力做好WebRTC这个平台。(作者:Google Harald)(原文链接:

摘要作为Google开源的技术,WebRTC实时音视频技术并不是一个可以拿来就用、并且性能很好的产品。本文主要来谈一谈WebRTC的优缺点。  2011年Google将WebRTC项目开源,让许多开发者眼前一亮,忍不住的加入了研究WebRTC的队伍中。作为Google开源的技术,WebRTC并不是一个可以拿来就用,并且性能很好的产品。本文主要来谈一谈WebRTC的优缺点。  一、发展及现状  WebRTC在被Google开源之前,其价值就已经得到了充分的认可。比如QQ就使用了WebRTC的部分技术。WebRTC的发展情况可以从标准规范和浏览器支持这两个方面看。WebRTC标准是由W3C和IETF所联合制定的,在2016年1月28日,W3C公布了最新的WebRTC标准,标准中定义了WebIDL中一系列的ECMA Script API来允许使用合适的RTP的浏览器或设备来接收/发送媒体,详细内容可以访问  二、优点  1.方便。对于用户来说,在WebRTC出现之前想要进行实时通信就需要安装插件和客户端,这是一个复杂的过程。现在,WebRTC技术内置于浏览器中,用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说,在Google将WebRTC开源之前,浏览器之间实现通信的技术是掌握在大企业手中,这项技术的开发是一个很困难的任务,现在开发者使用简单的HTML标签和JavaScriptAPI就能够实现Web音/视频通信的功能。  2.免费。虽然WebRTC技术已经较为成熟,其集成了最佳的音/视频引擎,十分先进的codec,但是Google对于这些技术不收取任何费用。  3.强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术,并支持代理。  三、缺点  1.编译WebRTC的源码就是一个比较大的挑战,搭建其复杂的编译环境往往会遇到很多意想不到的问题,导致当初计划用几个星期的时间来搞定项目,却发现这几个星期连编译都没搞定。  2.WebRTC中很多的参数都是由GIPS公司的工程师们依靠经验所设定的值,这就会出现卡顿、延时、回声、丢包、多人视频不稳定等问题。  3.WebRTC缺乏服务器方案的设计和部署。  4.传输质量难以保证。WebRTC的传输设计基于P2P,难以保障传输质量,优化手段也有限,只能做一些端到端的优化,难以应对复杂的互联网环境。比如对跨地区、跨运营商、低带宽、高丢包等场景下的传输质量基本是靠天吃饭,而这恰恰是国内互联网应用的典型场景。  5.WebRTC比较适合一对一的单聊,虽然功能上可以扩展实现群聊,但是没有针对群聊,特别是超大群聊进行任何优化。  6.设备端适配,如回声、录音失败等问题层出不穷。这一点在安卓设备上尤为突出。由于安卓设备厂商众多,每个厂商都会在标准的安卓框架上进行定制化,导致很多可用性问题(访问麦克风失败)和质量问题(如回声、啸叫)。  7.对Native开发支持不够。WebRTC顾名思义,主要面向Web应用,虽然也可以用于Native开发,但是由于涉及到的领域知识(音视频采集、处理、编解码、实时传输等)较多,整个框架设计比较复杂,API粒度也比较细,导致连工程项目的编译都不是一件容易的事。  总而言之,WebRTC虽然提供了一套音视频实时通讯的解决方案,但是在实际应用中,由于网络传输、设备适配以及多方通话上都存在很多问题,效果并不理想。(WebRTC开源工程官方网站:

WebRTC 的核心组件

  • 音视频引擎:OPUS、VP8 / VP9、H264
  • 传输层协议:底层传输协议为 UDP
  • 媒体协议:SRTP / SRTCP
  • 数据协议:DTLS / SCTP
  • P2P 内网穿透:STUN / TURN / ICE / Trickle ICE
  • 信令与 SDP 协商:HTTP / WebSocket / SIP、 Offer Answer 模型

 

图1为 WebRTC 内部结构简化图,最底层是硬件设备,上面是音频捕获模块和视频捕获模块。

中间部分为音视频引擎。音频引擎负责音频采集和传输,具有降噪、回声消除等功能。视频引擎负责网络抖动优化,互联网传输编解码优化。

在音视频引擎之上是 一套 C++ API,在 C++ 的 API 之上是提供给浏览器的Javascript API。

图片 1

△ 图1:WebRTC内部结构

 

图2是 WebRTC 涉及到的协议栈,WebRTC 核心的协议都是在右侧基于 UDP 基础上搭建起来的。

其中,ICE、STUN、TURN 用于内网穿透, 解决了获取与绑定外网映射地址,以及 keep alive 机制。

DTLS 用于对传输内容进行加密,可以看做是 UDP 版的 TLS。由于 WebRTC 对安全比较重视,这一层是必须的。

SRTP 与 SRTCP 是对媒体数据的封装与传输控制协议。

SCTP 是流控制传输协议,提供类似 TCP 的特性,SCTP 可以基于 UDP 上构建,在 WebRTC 里是在 DTLS 协议之上。

RTCPeerConnection 用来建立和维护端到端连接,并提供高效的音视频流传输。

RTCDataChannel 用来支持端到端的任意二进制数据传输。

图片 2

△ 图2:WebRTC 协议栈

视频编解码的探索方向:


1.VR视频

VR视频标准是当前不论是学术界,还是商业应用的热门探索方向之一。在2016年的RTC大会上,我们曾邀请到王荣刚教授分享过《VR视频内容生成技术与编码标准》,王荣刚教授目前担任国际MPEG互联网视频压缩标准专题组联合组长和IEEE虚拟现实视频内容编码标准专题组组长。

据王荣刚教授分享,VR视频的编码目前继续解决的技术问题有:图像的显示质量、合成质量和传输带宽,

VR视频编码先前的做法是,将已有的视频压缩标准,应用到VR场景中。但是,由于VR视频内容的特殊性和网络带宽的限制,目前的标准无法满足VR视频的压缩需求。业界对VR视频压缩标准呼声极高。将来高级的VR视频形态应该是自由沉浸立体视频:在一定空间范围内提供Anywhere

  • Anytime + Anyview +Stereo的沉浸体验。

2. 高分辨率的需求

在H.264时代,编码器主要应用于低于HD的中小分辨率,稍微兼顾1080P高分辨率。

但H.265时代,随着硬件设备更好、带宽更高,用户开始对视频分辨率的要求更高,人们开始发现,用户对视频质量要求是没有止境。因此,新一代编码器,更倾向于支持高分辨率,比如4K高清分辨率。新一代编码器对高分辨率的压缩效率可提高50%以上。

RTC 2017 第三届实时互联网大会上,有来自华为、Google、AVS视频组、AVS音频组、AVS测试组、Slack、Houseparty、atlassian(Jira)的技术专家到会分享下一代编码标准的探索及应用,这基本上是国内最全的编解码的技术分享聚会,当然还有RTC技术栈其他模块的技术分享,致力于入行RTC的开发者不可错过。

免费报名RTC大会>>

图片 3

基于 WebRTC 的 UPRTC

为了使 WebRTC 协议更适用于实时互动直播,又拍云在 WebRTC 协议的基础上进行改造优化,搭建了又拍云 UPRTC 。支持多种应用场景,包括一对一、一对多和多对多等应用场景。

  • 传统的 WebRTC 应用模式是 P2P 的, UPRTC 则是服务器中转模式。

因为又拍云拥有性能优异的 CDN 资源,将 WebRTC 改造成服务器中转模式之后,采用完全分布式系统,部署到全国所有边缘节点,通过内部加速网络 UTUN 加速,将转发、并发压力转移到服务端,保证 UPRTC 终端可以承受更多路并发。

  • 加入网络拥塞自适应控制,较强的弱网适应能力。

以移动设备从 WIFI 网络切换到 4G 网络为例,又拍云服务器可以察觉到带宽变化,统计丢包和延时,进行动态码率调整,保证在弱网环境下也能进行正常通话。

  • 对底层开源组件优化改造,支持高并发业务场景。

又拍云设计了一套灵活高效的业务信令,用于敏感信令鉴权。

 

图3为 UPRTC 技术组成:

  1. 媒体通道、数据通道,信令通道;
  2. 数据加密模块;
  3. 码率自适应控制模块;
  4. 又拍云加速网络;
  5. P2P打洞服务;
  6. 房间应用业务;
  7. 机器人(自动管理功能和互动功能)。

图片 4

△ 图3:UPRTC技术组成

RTC(Real-time Communications),实时通信,是一个正在兴起的风口行业,经过短短一年的时间,已经有很多玩家进入了这个行业,最典型的应用就是直播连麦和实时音视频通信。但是,很多开发者对一些概念还是有混淆的,比如RTC与WebRTC,RTC与直播,RTC与IM。

live555是一个C++流媒体开源项目,其中不仅包括了传输协议、音视频编码器(H.264、MPEG4)等,还包括流媒体服务器的例子,是流媒体项目的首选,里面的传输模块是非常值得视频会议开发作为参考的。

随着直播的发展,直播实时互动性变得日益重要。又拍云在 WebRTC 的基础上,凭借多年的开发经验,结合当下实际情况,开发 UPRTC 系统,解决了网络延时、并发量大、客户端解码能力差等问题。

视频编解码的现状:

视频编解码的作用,就是在设备的摄像头采集画面和前处理后,将图像进行压缩,进行数字编码,用于传输。编解码器的优劣基本在于:压缩效率的高低,速度和功耗。

目前,主流的视频编码器分为3个系列:VPx(VP8,VP9),H.26x(H.264,H.265),AVS(AVS1.0,AVS2.0)

VP8,是视频压缩解决方案厂商On2 Technologies的第八代视频编解码标准,Google收购On2后,就将VP8开源了,并且将其应用到WebRTC中。目前,Google也在主推新一代的编解码标准——VP9。

H.264,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器国际标准。 WebRTC也同时支持H.264。

VP8和H.264是十几年前发明的标准,属于同一代技术。这两个标准处于发展成熟的阶段,编码效率、运算复杂度和功耗上都达到了比较好的均衡。技术和应用程度上,二者也略有区别,比如,硬件厂商对H.264的支持较广泛,而对VP8的支持就比较有限。

VP9,开发始于2011年。VP9的目标之一是在保证相同质量的情况下相对于VP8可以减少50%左右的码率,换句话说,相同的码率,VP9能比VP8画质有非常明显的提高。VP9的一大的优势是专利费用,Google声明可以免费进行使用。这和H.264和H.265不同有较大的差异(虽然,2013年cisco已将open264开源,并声称在不修改open264代码的情况下,能保证由cisco覆盖相关的专利费用)。

H.265旨在在有限带宽下传输更高质量的网络视频,仅需原先的一半带宽即可播放相同质量的视频。它与H.264有着相类似的算法架构,并同时对一些相关技术加以改进而大幅提高视频质量。举例来说,H.264编码器可以以1Mbps码率实现标清数字视频压缩;而H.265编码器则可以利用相同的码率编码720P甚至更高的分辨率的高清视频。这也意味着,在现有的家庭网络情况下,我们的智能手机、平板机等移动设备将能够直接在线播放1080p的全高清视频。同时,H.265标准也同时支持4K和8K超高清视频。

VP9和H.265,是最近5年制定的标准,是当前已经完成标准中压缩效率最高的。同样的,H.265是国际标准,VP9是Google目前主推的标准。H.265在硬件支持上比较广泛,Apple、高通、intel等的芯片都支持H.265的硬件编解码器。VP9的硬件支持依然十分有限。总体来说,新一代编码器,编码效率能比上一代提高了30-50%,但是复杂度和功耗会比上一代大很多,所以纯软件编码实现的话有一定瓶颈,现有的技术下,还是需要依靠硬件编解码为主。

AVS是我国具备自主知识产权的第二代信源编码标准。目前,AVS1.0在第三世界国家中已有广泛应用。AVS2.0,属于与H.265和VP9同级的新一代标准。

编码器只是标准和语法,并没有限定应用场景。因此,在实际应用中,还要结合场景特点,来进行改进和深度优化。声网的视频编码器,针对实时音视频通信做了深度改进,更适应公共互联网的特点,实时性和质量上有很大提升。尤其是与网络的深度结合,同时兼顾对抗丢包和网络带宽的波动。

官网地址:

什么是 WebRTC

2010年5月,Google 花费6820万美元收购拥有编解码、回声消除等技术的 GIPS 公司。之后谷歌开源了 GIPS 的技术,与相关机构 IETF 和 W3C 制定行业标准,组成了现有的 WebRTC 项目。

WebRTC 全称 Web Real-Time Communication。它并不是单一的协议, 包含了媒体、加密、传输层等在内的多个协议标准以及一套基于 JavaScript 的 API。通过简单易用的 JavaScript API ,在不安装任何插件的情况下,让浏览器拥有了 P2P音视频和数据分享的能力。

同时WebRTC 并不是一个孤立的协议,它拥有灵活的信令,可以便捷的对接现有的SIP 和电话网络的系统。

二、RTC和直播有什么区别?


图片 5

RTC与直播的关系

上图展现的就是RTC与直播的关系,RTC的一个具体应用是直播场景中的直播连麦,也就是低延时直播。普通直播,一般采用TCP协议,使用CDN进行内容分发,会有几秒甚至十几秒的延时,主播和观众的互动只能通过文字短消息或送礼来进行。而直播连麦,使用UDP协议,内容实时传输,主播和观众可以进行音视频连麦互动,实时沟通,延时一般低至几百毫秒。

那么RTC技术栈究竟包含哪些技术,我们会提供一系列文章,来解读RTC技术栈。

RTC技术栈之视频编解码

RTC技术栈之音频编解码

RTC技术栈之音视频前后处理

RTC技术栈之实时传输

RTC技术栈之QoE质量保障

本文是系列文章的第一篇——视频编解码

图片 6

总结

虽然 WebRTC 源代码相对成熟,但是在实际应用中依旧需要解决以下问题:

1.音频处理过程中消耗 CPU 过高;

2.音视频不同步的BUG;

3.安卓端 WebRTC 源码对H.264支持并不全面,仅默认支持高通的芯片;

4.服务端架构过程中需要加入码率自适应算法,动态控制总码率带宽在 2M 以内。

 

推荐参考文档:

W3C API 相关文档: https://github.com/w3c

IETF 协议相关文档: https://datatracker.ietf.org

 

相关阅读:

实时音视频互动系列(下):基于 WebRTC 技术的实战解析

WebSocket+MSE——HTML5 直播技术解析

从Html5直播到互动直播,看直播协议的选择

一、RTCWebRTC有什么区别?

实时通信(RTC)最容易和WebRTC混淆,实际上,二者不能划等号。

图片 7

RTC通信流程

RTC从功能流程上来说,包含采集、编码、前后处理、传输、解码、缓冲、渲染等很多环节,上图展现了一次RTC通信的简要流程。每一个细分环节,还有更细分的技术模块。比如,前后处理环节有美颜、滤镜、回声消除、噪声抑制等,采集有麦克风阵列等,编解码有VP8、VP9、H.264、H.265等等。

图片 8

RTC与WebRTC的关系

上图展现了RTC与WebRTC的关系,WebRTC是RTC的一部分。WebRTC,是Google的一个专门针对网页实时通信的标准及开源项目。只提供了基础的前端功能实现,包括编码解码和抖动缓冲等,开发者若要基于WebRTC开发商用项目,那么需要自行做服务端实现和部署,信令前后端选型实现部署,以及手机适配等一系列具体工作;在此之外还要在可用性和高质量方面,进行大量的改进和打磨,对自身开发能力的门槛要求非常高。一个专业的RTC技术服务系统,需要除了涵盖上述的通信环节外,实际上还需要有解决互联网不稳定性的专用通信网络,以及针对互联网信道的高容忍度的音视频信号处理算法。当然常规云服务的高可用、服务质量的保障和监控维护工具等都只能算是一个专业服务商的基本模块。所以,WebRTC仅是RTC技术栈中的几个小细分的技术组合,并不是一个全栈解决方案。

Soundtouch是一个开源的音频处理框架,主要功能对音频变速、变调,实现变声的效果。同时,它也能对媒体流实时处理。采用32位浮点或者16位定点,支持单声道或者双声道,采样率范围为8k

WebRTC 具有的优势

成立UPRTC项目前,又拍云经过多重调研和考虑,选择了 WebRTC,主要有三个原因:

  1. WebRTC 是开源、 免专利费的项目, 大大节省了开发时间和成本;

  2. WebRTC 由 Google 主导, 技术非常先进;

  3. Safari 等浏览器以及其他终端逐渐加强对 WebRTC 技术的支持。

图片 9

WebRTC 的前世今生

图片 10

JsSIP是基于WebRTC的JavaScript SIP协议实现的库,可以在浏览器和Node.js中运行。它可以与 OverSIP、Kamailio、Asterisk、OfficeSIP等SIP Server一起运行。

Github地址:

官方地址:

Github地址:

官网地址:

下面这张图可能更具体一点:

代码地址:

更多WebRTC的技术文章请见:

图片 11

郑重声明:本文版权归新匍京a奥门-最全网站手机版app官方下载所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。