webrtc在远程助手应用的实践

远程助手

它是一个1对1的提供远程协助的一个解决方案，具有一下特点：
1)实时远程桌面
2)实时语音交互
3)实时远程控制

发展历程

站在WebRTC的肩膀上

WebRTC是由W3C,IETF等组织定义的一套实时音视频通信标准和技术规范。也是google的一个开源项目，提供了实时音视频通信的核心技术，包括音视频采集，编解码，网络传输，显示等，支持跨平台提供了多个平台的版本，有很多极具价值的技术，解决了很多实际问题。基于这些，构建了我们的产品和服务。

主要浏览器对webrtc的支持情况和market share

WebRTC优缺点

SFU&MCU

从理论到实践，从Demo到产品

1.服务框架
2.端框架Android,Browser
3.挑战
4.质量保证
5.运维

1.服务框架

webserver：账号服务器，房间服务器，后台监控服务
信令服务器：信令通道采用websocket，用来交换sdp/ice options
房间服务器，信令服务器采用go语言实现，基于beego构建，它简化了数据库操作，同源策略等的处理
STUN/Turn服务器：coturn + TURN RESET API + bandwidth monitor
Nginx：load balance
昂贵的backbone
1对1不需要SFU／MCU
资源限制，优化手段有限

2.端框架Android,Browser

android端使用的java api，Browser端使用javascript api
RoomManager：与房间服务器通信，管理房间信息等
Websocket：信令通道，与信令服务器通信的，主要交换SDP／ICE options，在peerconnection建立之前可以用于传递一些辅助信息（夹带私货）
EventManager：按键，屏幕触控，鼠标等信息的获取，坐标转换，封装，以及注入等管理，事件通过datachannel传输
PeerConnection：webrtc的入口，负责p2p连接的建立，成功后，video channel, voice channel, data channel可用
AudioRecord/AudioTrack：android平台音频的输入和输出
MediaProjection+virtualdisplay：屏幕数据的抓取

3.挑战

3.1.实时音视频通信的调优，端到端的优化
3.2.webrtc代码的坑
3.3.客户端的适配

3.1.实时音视频通信的调优，端到端的优化

什么是好的实时音视频通信？主观上
1）视频，画面清晰正确，延迟低，无卡顿，带宽占用低
2）音频，声音清晰正确，无丢失，无噪音，无回声，延迟低，无卡顿，带宽占用低
主观上，音视频的评价标准很相似，但是涉及到的技术手段有共同点也有不同的地方，要分开来看

影响实时音视频质量的因素：
1）码率
视频，受编码压缩率，I帧频率，分辨率，帧率，编码码率等影响，编码码率影响QP
音频，受编码压缩率，采样率和位宽的影响，采样率和位宽会影响音质
2）编码算法
3）丢包，一般发生在网络很差的情况下，会采用丢包重传做补偿，音频对丢包更敏感
4）抖动，丢包重传会造成抖动问题，引入了jitter buffer解决这个问题
5）带宽，实际可用带宽取决于网络拥塞情况
6）延时，带宽一定的情况下，高码率会带来高延时，丢包重传也会带来延时，编码时使用B帧也会引入延时，jitter buffer设置不合理同样引入延时
7）回声消除，AEC
8）自动增益，AGC
9）噪音抑制，NS

解决这个问题，需要一套组合拳

设置最大上行带宽：
1）合理利用上行带宽
2）移动流量可控
3）转发服务器流量可控

H264 vs VP8：
1）在编码压缩率和编码质量上H264均优于VP8
2）色彩复杂度高界面VP8发生了失真
3）支持VP9，H265的平台较少

Video engine初始设置：
1）Codec
2）设置合适的I帧频率
(1).太大，码率变大，带宽负担增加
(2).太小，参考帧离的太远容易出现花屏且不能很快恢复
3）设置最佳分辨率，兼顾清晰度和带宽使用，450x800
4）编码使用Baseline profile避免B帧
5）设置帧率为15fps
6）调整jitter buffer
7）指定对应分辨率最佳编码码率／QP

H264各分辨率对应编码码率：

拥塞控制GCC：

1）带宽利用上不去？check delay based bitrate bps
2）设置最大编码码率
(1).降低不必要的带宽流消耗
(2).码率达到一定值后，继续增加作用不明显
3）设置最小码率，保证用户体验

too low bitrate, mess

远程助手用户场景下视频特点：
一动：用户在操作，滑动桌面或列表，在寻找目标
一不动：用户基本找到目标，不需要或很少需要滑动，画面变化很慢，主要是讲解观察
针对这两个特点引入了两个技术qulaity scaler和动态帧率，来根据实际需求平衡带宽占用

Quality scaler：

1）Quality scaler—scaled resolution—>Encoder
2）丢帧率高于阀值30%，降低分辨率，说明带宽紧张
3）隐含意思，丢帧率低于阀值，说明带宽还可以
4）QP高于高阀值37(h264)，降低分辨率
5）QP低于低阀值24(h264)，升高分辨率
6）隐含意思，QP介于高QP和低QP之间时，分辨率保持不变
7）隐含意思，QP升高是由于编码需要，比如运动画面，QP降低也是由于编码需要，比如静态画面
8）增强：
(1).设置分辨率scale上限
(2).设置分辨率scale下限
(3).平滑的scale梯度
带宽低时，继续降低带宽使用，带宽还可以时，保证运动画面的流畅度，保证静态画面的清晰度

动态帧率：

1）屏幕刷新率从1～60fps波动
2）0 < frame rate <15fps
3）界面变化快，刷新率高时，流畅度优先，增加帧率提升流畅度体验，带宽占比增大
4）界面变化慢，刷新率低时，清晰度优先，降低帧率，释放带宽占比

opus，高音质，低延迟：

1）6 kb /秒到510 kb / s的比特率
2）采样率从8 kHz(窄带)到48 kHz(全频)
3）帧大小从2.5毫秒到60毫秒
4）支持恒定比特率(CBR)和可变比特率(VBR)
5）从窄带到全频段的音频带宽
6）支持语音和音乐稳定性，内存使用，功耗等
7）支持单声道和立体声
8）可动态调节比特率，音频带宽和帧大小
9）良好的鲁棒性丢失率和数据包丢失隐藏(PLC)

采用16k采样率，保证音质，降低带宽使用：
1）原来采用48k或44.1k，android音频框架mix输出的采样率
2）low latency audio sample rate 真的low latency吗？
3）经测试，延时不在重新采样，在于码率，尤其是在低带宽的情况下
4）应用场景主要是通话交流，人声频率100hz~10kHz，人耳20hz~20khz

48khz vs 16khz
人声频率没有损失

回声消除：
1）回声是如何产生的

2）回声造成的声音问题

自动增益：
1）手机通话的正确姿势？

2）距离产生的不是美，是听不清你说啥

3.2.webrtc代码的坑

3.3.客户端的适配

Android
1）不同平台硬件编解码器
MTK，Samsung，Hisilicon，Qualcom
2）低端平台带来的性能问题
3）分辨率720p～2k
4）特殊场景动画需求导致的屏幕刷新不均匀引发的卡顿问题(视觉上)

浏览器：
1）用adapter.js不同浏览器版本webrtc接口实现不一样
2）getUserMedia权限问题
3）同源策略
4）https和http共存

4.质量保证

4.1.开发测试环境，线上环境，隔离
4.2.服务端压力测试，jmeter
4.3.实时音视频通信评估标准和实验环境
4.4.端测试用例
4.5场测，跨地区，跨运营商
4.6Android APP质量体系

4.3.实时音视频通信评估标准和实验环境

主观客观相结合的方法，制定了一套标准文档和配套方法：

实时音视频硬件实验环境的搭建是非常昂贵的，利用现有的一切资源
网损模拟，facebook ATC：

视频延时测量，双向延时：
1）60fps 录屏
2）ms=(n-m)/frame_rate*1000
屏幕快照 2018-08-09 下午2.57.36

视频延时测量，单向延时：
1）高速摄像机
2）精确到毫秒秒表
3）ms=00:01:19:155-00:01:18:938

音频延时测量：
音频半回路

其他测量方法：
1）视频平滑度，匀速自转的地球仪
2）帧率，帧间隔计算工具
3）video dump工具
4）audio dump工具

主要技术指标项：
横向和自身对比，纵向和竟品对比，客观评价优化效果

5.运维

5.1.日志系统

1).优化log系统
2).统一各服务器log时间到毫秒

5.2.后台管理，大数据

1).连接成功率
2).p2p打通率
3).连接时长分布
4).通话的体验，综合延迟，丢包率，带宽，码率等情况

5.3.用户反馈

1).增加反馈入口
2).周统计

WebRTC走向展望

1）WebRTC已经定版，后续主要发力优化，应用场景支持
2）新一代编码技术H265，AVS2，AV1，VP9等得到广泛支持
3）视频，图像增强技术，降低带宽
4）AR
5）AI，对优化策略参数进行决策