rtc/webrtc 2017实时音视频大会分享

Share of RTC2017

Walker.Xu

RTC2017

RTC实时互联网大会在美国已成功举办8届，是全球范围影响最大最权威的实时通信行业技术会议。该会议吸引了来自全球数万名开发者和技术大咖参加，Google、Ericsson、Oracle、Intel、Agora.io、Mozilla、Avaya等公司均曾在大会上分享过各自在实时通信领域的技术、应用与经验。

RTC2017由声网Agora.io主办，CSDN和Allthingsrtc.org协办的在亚洲的第3届盛会，也是亚洲唯一最权威的RTC实时通信行业技术会议。
1.商业目的，生态链
2.技术，应用交流

参会目的

1.学习，了解RTC行业的先进水平
2.开阔思路，了解音视频技术，实时音视频技术的发展方向

实时音视频应用场景

社交

微信，QQ，陌陌，face u，holla，house party，facebook

直播，连麦

熊猫TV，YY，映客，花椒，荔枝FM(语音直播，万人连麦)，twitch

游戏

王者荣耀，狼人杀，饭局狼人杀，棋牌类游戏

在线教育

沪江CCtalk

其他：医疗，金融服务，工具类，会议类
远程助手，slack

实时音视频技术扮演的角色

1.创造应用场景，没有实时音视频技术就没有这个用户场景，社交视频语音聊天，直播连麦，各种狼人杀，在线课堂
2.增强应用体验，王者荣耀语音，棋牌类游戏
3.跨界，行业融合，直播连麦社交，狼人杀是游戏也是社交，twitch，熊猫是直播跟游戏密不可分

我们出不去，别人进不来

硬实力软实力

南亚，东南亚

北美，美国：3.23亿，加拿大：3628万
东亚，东南亚，南亚，非中国大陆，越南：9270万，泰国：6886万，马来西亚：3118万，印度尼西亚：2.611亿，菲律宾：1.03亿，巴基斯坦：1.93亿，孟加拉国：1.7亿，印度：13.24亿，日本：1.27亿，韩国：5125万，台湾：2349万，新加坡：560万，香港：737万
中国大陆：14亿
中亚：7000万

实时音视频技术，应用生态（组成）

1.标准组织
2.研究机构
3.技术框架联盟，一般大公司牵头发起，开源社区
4.技术实现，质量监测，数据分析等服务提供商
5.开源应用，技术框架
6.行业应用

实时音视频技术，应用生态(国内外差异)

1.国内RTC

腾讯，YY为代表的，从技术到服务到应用都自己干
Agora.io为代表的技术，服务提供商，服务了陌陌，face u，holla，熊猫TV，小米，cctalk等
技术体系私有，或webrtc变种
一个供应商解决所有问题，快速反应，提供保姆式服务，国情决定

2.国外WebRTC

IETF:国际互联网工程任务组（The Internet Engineering Task Force）
W3C
CoSMo Software Consulting: webrtc research and api test of browsers
Google: add GIPS to webrtc and open source
Callstates.io: webrtc a/v quality monitor service
Jitsi
Slack
Twitch
Facebook
生态比较多样，分工较明确

实时音视频与新技术的结合

实时音视频技术是一个技术平台可以将很多新的多媒体技术融合进来，进行组合，创造新的应用场景
1.AI：小米音箱
2.AR
3.VR+人脸识别
4.holographic projection:全息投影, art media直播+全息投影
5.全景声技术：dolby atoms

实时音视频技术

What？

RTC, real time communication, webrtc是RTC的一种

Why?

我们不是有http,https,hls,rtsp,rtmp吗，为什么还要开发实时音视频技术
简单来说就是不满足进行实时音视频通信的要求
1.延时低
2.双向／多向

Http, https,hls延时10s左右，pass
rtmp延时1~3s还不错，进行实时音视频通信还差点意思，pass
rtsp的延时可以做到0.5s，基本满足需求，但是它不是为双向设计的，实现起来很复杂，而且网络穿透能力差

RTC延时

webrtc为例实验室200ms以内，比较好的网络300ms以内，远程助手基于webrtc实现的，单向延时可以做到300～400ms在魅族网络
商业公司的延时基本做到在全网400ms

1.客户端

传输

传输质量测量，智能网络接入(就近接入)，流控(flow control)，带宽估计，拥塞控制(congestion control)，弱网对抗
Packet loss,RTT,丢包重传,jitter buffer

编解码

Opus,agora solo
H26x:H264,H265
VPX:VP8,VP9
编码的压缩率，抗丢包，丢包隐藏，FEC，动态码率(QP)，帧率设计，I帧间隔，动态分辨率，B帧
SVC: scalable video coding
可分级的视频编码(Scalable Video Coding)
出现的原因 主要解决网络传输视频信息的时候,带宽限制了数据的传输,而我们通过某种方法使得视频流拥有可分级性,当网络带宽较小的时候,只保持基本的视频信息被传输,并根据实际的网络环境决定是否传增强的视频信息以使得图像质量得到加强,以此得到自适应性.这样的方式可以保持拥有网络连接的大部分终端都可以以适当的码流来使用多媒体信息,而不考虑原码流的需求.

前后处理

回声消除，噪声抑制，增益控制，可懂度增强，声音美化／变声，空间音频，盲源分离
美颜，滤镜，降噪，平滑，锐化，error concealment，人脸识别

兼容性处理（Android platform mainly）

市面上几百款手机，魅族支持远程协助的有20多款

流控flow control

是用于控制发送方的速度，防止接收方缓存溢出，它的局限性显而易见，只有在特定限制条件下才有意义，如图1
拥塞控制是在拥塞发生时控制进入网络的数据量，相对复杂，GCC同时使用基于时延(delay-based)和基于丢包(lost-based)的两种算法应对带宽网络的拥塞控制，这两个预测控制组成了速率预测控制器如图2
delay-based算法由数据的接收方实现，接收方需要记录每个数据包到达的时间和大小，并计算每个数据分组之间（inter-group）的延迟的变化，由此判断当前网络的拥塞情况，并最终输出码率估计值由RTCP feedback（TMMBR或 REMB）反馈给发送方；loss-based算法则由数据的发送方来实现，发送方通过从接收方周期性发来的RTCP RR（Receiver Report）中获取丢包信息以及计算RTT，并结合TMMBR或REMB中携带的码率信息算得最终的码率值，然后由媒体引擎根据码率来配置编码器，从而实现码率的自适应调整。如图3。可以看出，这两个算法在系统中并不是孤立存在的。

QP

降噪 & 自动增益

SVC

Agora solo

2.后台

传输，骨干网络，时髦叫法云

全球网络覆盖(跨洲，跨国，夸网，夸运行商)，CDN ，高并发，高可用(可用度，容灾性)，应用专网(路由选择)

SFU/MCU

NAT(network address translation)，STUN/TURN，ICE

SFU/MCU

Bandwidth & CPU are limited in a device

smart way

NAT

STUN/TURN

3.信令

信息数据交换，sdp，ice options
呼叫和消息系统，Websocket，SIP
信令通道在数据通道之前建立
其他作用，比如传递一些设备，状态信息

4.评价体系

指标，perfect/good/acceptable/bad/mess
测试环境／工具／资料／应用场景／人
大数据，监测统计，在实际使用环境中评估
高大上的音视频实验环境

评价体系 实践

用其他手段代替昂贵的器材
指标 测试环境 大数据，实际使用环境

实时音视频技术，挑战

重要或紧急的事情，第一选择，打电话

质量，质量，质量

1.接通率 （业内先进水平失败率<=2%）
2.音视频体验 （做的不错）
卡顿，模糊，马赛克，数据丢失

实时音视频技术，大规模直播+连麦的解决方案

1.普通的直播RTMP可以实现
2.需要连麦，需要实时音视频技术的介入，主播和其他连麦用户通过　RTC技术实现实时音视频互动，再通过RTMP把连麦现场直播出去

Leningrad

1.适配了20多款机型

M。。。

2.系统版本

Android5.0~Android7.1
flyme5~flyme7
【应对了Android跨版本,flyme框架,不同屏幕分辨率等兼容性问题的挑战】

3.服务业务

用户帮助
安全家庭
远程监控

4.打通了浏览器端

chrome and firefox

5.欠缺

迭代不持续，不够专注；后台能力.

Normandie(音视频sdk)

1.适配了meizu全部几十款机型

2.系统版本

Android4.2~Android7.1
yunos
flyme4.5~flyme7
【应对了Android跨版本,flyme框架,不同屏幕分辨率等兼容性问题的挑战】

3.服务业务

Music音乐，主题功能+定制需求比如drm，代理，副歌等，日活100万，月活千万
News咨讯，在线短视频播放，cp重要有360(640x360),UC(852x480),快手(960x720)，360,UC可以做到秒播，快手在1～2s内起播，千万用户
趣视频，在线短视频播放

4.欠缺

迭代不持续，不够专注；部分业务没有推广成功.

总结，三个阶段

1.从0到1，实现我们的基本设想，满足最初的需求

【做不出来，die】

2.生存，在具体产品上应用，达到一定要求，上线运行，实现更多需求

在更多机型上落地，在稳定性,功能,性能方面达到一定的要求，满足现阶段业务需求，并且部分指标不落后或不大幅落后市面上比较先进的产品
【做出来没人用，die】

3.发展，持续迭代，升级，优化，技术上看着业内第一梯队向业内第二梯队靠拢

多看多想，扩展更多产品形态和场景
从业务上也对我们提出了更高的要求，业务上会直接和竞品对比，业务或用户不会关心你的团队或资源，只关心体验结果，能不能有好的体验
【用户用起来不爽，不能与竟品竞争，die】
从目前看，我们基本满足生存的第二个阶段，努力向发展的第三阶段靠拢，这个阶段对我们自身提出了更高的要求需要更深入的学习和积累，创造机会抓住机会不停的学习

上策中策下策

平台

产品

需求／功能

生命越长越专注价值越大

Thanks

声明：借鉴了很多大会上大神的ppt