遠程助手

它是一個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，對優化策略參數進行決策

總結

以上是生活随笔為你收集整理的webrtc在远程助手应用的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。