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
人声频率没有损失