微信小程序視頻通話的實(shí)現(xiàn)步驟

視頻通話，你也能開發(fā)

我們可以發(fā)現(xiàn)目前保險(xiǎn)行業(yè)會(huì)通過現(xiàn)場定損的方式處理車險(xiǎn)理賠，這種方式需要派定損員驅(qū)車前往事發(fā)地點(diǎn)進(jìn)行損傷判定，每次的出車成本非常高。

如果要采用遠(yuǎn)程電話解決，保險(xiǎn)公司無法簡單通過語音溝通確認(rèn)損傷程度，而且照片采集很難規(guī)避定車騙保的可能，所以**實(shí)時(shí)的視頻通話**可以解決這種問題。

小程序中 <live-pusher> 和 <live-player> 兩個(gè)組件 ，都有一個(gè)叫做 RTC 的模式，通過這種模式，可以在小程序?qū)崿F(xiàn)實(shí)時(shí)視頻通話。

 <live-pusher> 和 <live-player> 兩個(gè)組件的 RTC 模式，主要是實(shí)現(xiàn)端到端能夠以很低的時(shí)延傳輸音視頻數(shù)據(jù)。

這樣一來，視頻通話的雙方 A 和 B 就可以各自拉通一路方向相反的音視頻鏈路，從而實(shí)現(xiàn) A 和 B 之間的雙向低延時(shí)的音視頻數(shù)據(jù)傳輸。與此同時(shí)，RTC 模式還會(huì)開啟內(nèi)置的 AEC (回聲抑制)，避免通話的雙方會(huì)因?yàn)楸镜佧溈孙L(fēng)對播放器的聲音進(jìn)行二次采集而引起的回聲問題。

小程序的 RTC 模式解決了雙向或者多人實(shí)時(shí)音視頻通話在終端所需要的各項(xiàng)技術(shù)組件，但是通話線路本身可能也會(huì)引入很高的延時(shí)，所以要確保視頻通話的 A 和 B 雙方所使用的 rtmp 線路要有很低的時(shí)延。

如果是自己搭建rtmp服務(wù)器（例如 nginx-rtmp 服務(wù)），請檢查 nginx-rtmp 的服務(wù)端參數(shù)設(shè)置，確保不要在服務(wù)器端引入太多音視頻數(shù)據(jù)緩存。

如果是使用騰訊云的超低延時(shí)線路，那么要注意給 RTC 模式下的 <live-player> 傳遞帶防盜鏈簽名的播放 url。

小程序的 RTC 模式主要用于視頻通話，由于這類場景以交流為重，所以小程序會(huì)有限保證聲音的流暢，相應(yīng)的，視頻數(shù)據(jù)的發(fā)送會(huì)被放在第二優(yōu)先級上。因此，如果網(wǎng)絡(luò)有波動(dòng)，小程序會(huì)舍棄尚未發(fā)送出去的視頻數(shù)據(jù)，優(yōu)先保障音頻數(shù)據(jù)的發(fā)送。

所以如果在 RTC 模式下，建議不要給  <live-pusher> 設(shè)置太高的畫質(zhì)，也就是不要將 min-bitrate 和 max-bitrate 設(shè)置的太大，一般而言，推薦 min-bitrate 設(shè)置為 300kbps， max-bitrate 設(shè)置為 800kbps，即可滿足常規(guī)視頻通話的需求。