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）AR5）AI，對優化策略參數進行決策