微信小程序视频通话的实现步骤

视频通话，你也能开发

我们可以发现目前保险行业会通过现场定损的方式处理车险理赔，这种方式需要派定损员驱车前往事发地点进行损伤判定，每次的出车成本非常高。

如果要采用远程电话解决，保险公司无法简单通过语音沟通确认损伤程度，而且照片采集很难规避定车骗保的可能，所以**实时的视频通话**可以解决这种问题。

小程序中 <live-pusher> 和 <live-player> 两个组件 ，都有一个叫做 RTC 的模式，通过这种模式，可以在小程序实现实时视频通话。

 <live-pusher> 和 <live-player> 两个组件的 RTC 模式，主要是实现端到端能够以很低的时延传输音视频数据。

这样一来，视频通话的双方 A 和 B 就可以各自拉通一路方向相反的音视频链路，从而实现 A 和 B 之间的双向低延时的音视频数据传输。与此同时，RTC 模式还会开启内置的 AEC (回声抑制)，避免通话的双方会因为本地麦克风对播放器的声音进行二次采集而引起的回声问题。

小程序的 RTC 模式解决了双向或者多人实时音视频通话在终端所需要的各项技术组件，但是通话线路本身可能也会引入很高的延时，所以要确保视频通话的 A 和 B 双方所使用的 rtmp 线路要有很低的时延。

如果是自己搭建rtmp服务器（例如 nginx-rtmp 服务），请检查 nginx-rtmp 的服务端参数设置，确保不要在服务器端引入太多音视频数据缓存。

如果是使用腾讯云的超低延时线路，那么要注意给 RTC 模式下的 <live-player> 传递带防盗链签名的播放 url。

小程序的 RTC 模式主要用于视频通话，由于这类场景以交流为重，所以小程序会有限保证声音的流畅，相应的，视频数据的发送会被放在第二优先级上。因此，如果网络有波动，小程序会舍弃尚未发送出去的视频数据，优先保障音频数据的发送。

所以如果在 RTC 模式下，建议不要给  <live-pusher> 设置太高的画质，也就是不要将 min-bitrate 和 max-bitrate 设置的太大，一般而言，推荐 min-bitrate 设置为 300kbps， max-bitrate 设置为 800kbps，即可满足常规视频通话的需求。