微信小程序視頻通話的實(shí)現(xiàn)步驟
視頻通話,你也能開(kāi)發(fā)
01小程序 + 視頻通話有什么優(yōu)勢(shì)?
我們可以發(fā)現(xiàn)目前保險(xiǎn)行業(yè)會(huì)通過(guò)現(xiàn)場(chǎng)定損的方式處理車(chē)險(xiǎn)理賠,這種方式需要派定損員驅(qū)車(chē)前往事發(fā)地點(diǎn)進(jìn)行損傷判定,每次的出車(chē)成本非常高。
如果要采用遠(yuǎn)程電話解決,保險(xiǎn)公司無(wú)法簡(jiǎn)單通過(guò)語(yǔ)音溝通確認(rèn)損傷程度,而且照片采集很難規(guī)避定車(chē)騙保的可能,所以**實(shí)時(shí)的視頻通話**可以解決這種問(wèn)題。
小程序中 <live-pusher> 和 <live-player> 兩個(gè)組件 ,都有一個(gè)叫做 RTC 的模式,通過(guò)這種模式,可以在小程序?qū)崿F(xiàn)實(shí)時(shí)視頻通話。
02視頻通話的內(nèi)部原理是什么?
<live-pusher> 和 <live-player> 兩個(gè)組件的 RTC 模式,主要是實(shí)現(xiàn)端到端能夠以很低的時(shí)延傳輸音視頻數(shù)據(jù)。
這樣一來(lái),視頻通話的雙方 A 和 B 就可以各自拉通一路方向相反的音視頻鏈路,從而實(shí)現(xiàn) A 和 B 之間的雙向低延時(shí)的音視頻數(shù)據(jù)傳輸。與此同時(shí),RTC 模式還會(huì)開(kāi)啟內(nèi)置的 AEC (回聲抑制),避免通話的雙方會(huì)因?yàn)楸镜佧溈孙L(fēng)對(duì)播放器的聲音進(jìn)行二次采集而引起的回聲問(wèn)題。
03怎么用小程序?qū)崿F(xiàn)視頻通話?
- step1:開(kāi)通一個(gè)云直播服務(wù)(比如 騰訊云 ),或者自己搭建一個(gè)rtmp服務(wù)器(例如 nginx-rtmp 服務(wù))。
- step2:生成兩對(duì) rtmp 推拉流 url :一對(duì)是用于 A 端推流的 push_url_a 和 用于播放 A 端視頻的 play_url_a;另一對(duì)是用于 B 端推流的 push_url_b 和 用于播放 B 端視頻的 play_url_b;
- step3:A端添加一個(gè) <live-pusher> 標(biāo)簽,指定 mode 為 RTC,并將 url 輸定設(shè)定為 push_url_a。
- step4:A端添加一個(gè) <live-player> 標(biāo)簽,指定 mode 為 RTC,并將 src 輸定設(shè)定為 play_url_b。
- step5:B端添加一個(gè) <live-pusher> 標(biāo)簽,指定 mode 為 RTC,并將 url 輸定設(shè)定為 push_url_b。
- step6:B端添加一個(gè) <live-player> 標(biāo)簽,指定 mode 為 RTC,并將 src 輸定設(shè)定為 play_url_a。
關(guān)于視頻通話
你會(huì)有這樣的疑問(wèn)
01通話時(shí)延太高了怎么辦?
小程序的 RTC 模式解決了雙向或者多人實(shí)時(shí)音視頻通話在終端所需要的各項(xiàng)技術(shù)組件,但是通話線路本身可能也會(huì)引入很高的延時(shí),所以要確保視頻通話的 A 和 B 雙方所使用的 rtmp 線路要有很低的時(shí)延。
如果是自己搭建rtmp服務(wù)器(例如 nginx-rtmp 服務(wù)),請(qǐng)檢查 nginx-rtmp 的服務(wù)端參數(shù)設(shè)置,確保不要在服務(wù)器端引入太多音視頻數(shù)據(jù)緩存。
如果是使用騰訊云的超低延時(shí)線路,那么要注意給 RTC 模式下的 <live-player> 傳遞帶防盜鏈簽名的播放 url。
對(duì)比項(xiàng)目
示例
時(shí)延
普通直播URL
rtmp://3891.liveplay.myqcloud.com/live/3891_test_clock_for_rtmpacc
>2s
超低延時(shí) URL
rtmp://3891.liveplay.myqcloud.com/live/3891_test_clock_for_rtmpacc?bizid=bizid&txTime=5FD4431C&txSerect=20e6d865f462dff61ada209d53c71cf9
< 500ms
02感覺(jué)畫(huà)面很卡應(yīng)該如何處理?
小程序的 RTC 模式主要用于視頻通話,由于這類(lèi)場(chǎng)景以交流為重,所以小程序會(huì)有限保證聲音的流暢,相應(yīng)的,視頻數(shù)據(jù)的發(fā)送會(huì)被放在第二優(yōu)先級(jí)上。因此,如果網(wǎng)絡(luò)有波動(dòng),小程序會(huì)舍棄尚未發(fā)送出去的視頻數(shù)據(jù),優(yōu)先保障音頻數(shù)據(jù)的發(fā)送。
所以如果在 RTC 模式下,建議不要給 <live-pusher> 設(shè)置太高的畫(huà)質(zhì),也就是不要將 min-bitrate 和 max-bitrate 設(shè)置的太大,一般而言,推薦 min-bitrate 設(shè)置為 300kbps, max-bitrate 設(shè)置為 800kbps,即可滿(mǎn)足常規(guī)視頻通話的需求。
- 第 1 頁(yè)【小程序直播】小程序直播功能開(kāi)發(fā)過(guò)程詳解
- 第 2 頁(yè)【音視頻組件】 微信小程序怎么做直播
- 第 3 頁(yè)【音視頻組件】 微信小程序視頻通話的實(shí)現(xiàn)步驟