# VoIP 视频流指南
小程序 Voip 的视频流默认为 H264 编码流，从设备端看，分为设备上行流与微信下行流，分辨率目前最大为 640x480。
对于上行流，是设备采集 -> 设备编码 -> 网络传输 -> 微信接收 -> 微信解码 -> 小程序渲染。 对于下行流，是微信采集 -> 微信编码 -> 网络传输 -> 设备接收 -> 设备解码 -> 设备渲染。
需要注意的是，微信客户端使用摄像头采集视频流的原始分辨率为 640x480，并且它的方向与物理方向并不一致，所以针对 RTOS 和 Linux 设备，它们收到流后，需要进行后处理才能渲染正确。
# 1. Android 设备
Android 设备的开发者无需关心视频流的方向问题。WMPF 会对接收的视频流进行旋转，小程序渲染输出即可（objectFit 为 fill)。
# 2. Linux/RTOS 设备
此类型设备无法运行 WMPF，直接使用 SDK 进行视频流的接收和发送。
# 2.1 设备发送视频流
手机摄像头的本地采集为上图所示的逆时针旋转 90 度方向，但嵌入式设备一般不会有这种情况，所以当嵌入式设备上的摄像头采集流直接使用 SDK 发送出去后，微信端小程序 Voip 插件在不使用 setUIConfig 配置旋转时，反而会渲染出旋转的画面。
有两种方案解决：
- 配置嵌入式设备摄像头的视频流为逆时针旋转 90 的视频流。
- 微信小程序上使用插件的 setUIConfig 配置对方的旋转方向为 270。
SDK 端如何发送视频流才能使小程序端尽早的展示图像
需要在开发者实现的 camera_device->open_stream 调用完成后，才能发送 H264/H265 流。
保证前几桢发送的为信息桢及关键桢，顺序应该如下：
sps -> pps -> i-frame -> p-frame -> p-frame -> ......
需要在状态为 TALKING 时再开始发送，不然前面的信息桢可能会被抛弃导致 p-frame 发送失败，只有等下一个周期的信息桢才能成功。
# 2.2 设备接收视频流
设备接收到的是微信客户端利用摄像头采集并编码的视频流，Android 和 IOS 的摄像头采集时，原始流都是逆时针旋转 90 的流，设备接收到的正是如此。
有两种方案解决：
- 推荐: 嵌入式设备在收到流后，在输出时顺时针旋转 90 即可。
- 提供小程序 appid 给微信 Voip 团队，开通发送非旋转流能力，开通后微信客户端会对采集的视频流先进行旋转纠正，再发出去。 需要注意的是，此功能会对 appid 下的所有设备 （包括 WMPF 设备) 造成影响
# 2.3 视频流分辨率
微信小程序 Voip 视频的分辨率不是固定的，它会随着网络质量的变化而变化。
- 设备上行视频流：分辨率不应该超过 1080p。通话过程中允许分辨率发生变化，但需要及时的发送 SPS 、I 桢等。典型的分辨率是 320x240、640x480。
- 微信下行视频流：微信下行视频流都是从 320x240/240x320 分辨率开始的，然后根据网络情况，会提升至 640x480/480x640。
针对微信下行视频流，有些 RTOS 设备不支持处理分辨率变化流的能力。开发者可以提供 appid 给微信 Voip 团队，开通固定分辨率的能力（320x240/240x320)。 需要注意的是，此功能会对 appid 下的所有设备 （包括 WMPF 设备) 造成影响 。
# 2.4 性能参考
# 2.4.1 微信响铃延时
- wx_cloudvoip_client_call 接口正常需要 600ms 左右。如果在 RTOS 设备上运行，根据不同的网络侧实现，接口的返回时间会有所不同。
- wx_cloudvoip_client_call 接口返回成功后，微信侧即响铃。当然，对于不同的手机，延时情况会不一样。对于 iphone，还依赖于 apple 的消息推送，对于 android，各种系统设置还可能导致手机消息异常，可参考通话提醒异常排查指南
# 2.4.2 视频流延时
以下几种场景下的延时与网络质量有很大关系，以下数据都基于网络正常的情况。
接听成功后，设备端首次收到视频流的时延约 1s ~ 2s 左右，对端不同性能的手机、不同的微信版本，时间会有少许差异。
接听成功后，手机端首次收到视频流的时延约 1s ~ 2s 左右。需要注意的是，手机端如果从悬浮通知直接接听，会经历（1）打开小程序与（2）加入通话 两个过程，这里的 1s ~ 2s 指的是（2）加入通话这个过程。打开小程序的耗时与手机性能强相关。
典型的场景，设备采集视频 -> 传送到云端 -> 送入云端 SDK 接口 -> 微信小程序端出图:
整个过程的延时大约在 200 ~ 300ms。