云端录制集成最佳实践

最近更新时间:2022-09-20 05:17:40

本文档介绍集成云端录制 RESTful API 时的几个注意事项,最大程度的保证服务的可靠性。

获取服务状态

消息通知服务只能作为辅助手段来获取服务录制状态。不建议你的核心业务逻辑依赖消息通知服务。

每个 App ID 每秒钟的请求数(QPS)限制默认为 10 次。请根据你的同时最大并发频道量(PCU)和查询间隔,预估所需的 QPS,并联系客服申请调整 QPS 限制。

确认录制服务已成功启动

  1. start 请求成功,即成功获得 sid (录制 ID)。如果 start 请求失败,需要根据状态码采取相应措施:

    • 如果返回的 HTTP 状态码为 40x,则表示请求参数错误,排查错误信息。
    • 如果返回的 HTTP 状态码为 50x,可多次调用该请求,直到成功返回 sid 为止。建议使用间歇策略,如第一次等待 3 秒后重试、第二次等待 6 秒后重试、第三次等待 9 秒后重试,以免超过 QPS 限制导致失败。如果三次重试均失败,建议更换 UID 再次调用 acquire, 获得一个新的 resource ID,并用该 resource ID 再次调用 start 方法。
  2. 获得 sid 之后的 5 秒后,使用退避策略调用 query 方法,退避间隔建议小于 start 请求中的 maxIdleTime (最长空闲频道时间)。如果 query 请求成功,且 serverResponse 中的 status 参数值为 45,则表示录制服务已成功启动。如果在获得 sid 之后的 90 秒后 status 仍非 45, 则可以认为录制未启动或成功后超时退出。

建议你准备一个备份 UID,在重新启动录制时使用,以避免频道内两个相同 UID 互踢。主备 UID 可以交替使用。

回调通知的数据是 start 调用成功后根据 sid 为标识的。

录制过程中的服务状态监控

  • 周期性调用 query 来确认录制服务正在进行中且状态正常
  • 通过消息通知服务

息通知服务可以作为辅助手段,详见消息通知服务和 query 方法的对比

周期性频道查询

anyRTC 建议你使用 query 方法周期性查询频道内的录制状态,例如每隔 2 分钟调用一次 query,并根据返回的 HTTP 状态码采取相应措施。

  • 如果返回的 HTTP 状态码一直为 40x,则表示请求参数错误,排查错误信息。
  • 如果返回的 HTTP 状态码为 404,且已经确认请求参数无误,则表示录制并未成功启动、或启动后中途退出。建议采用退避策略多次调用 query (例如间隔 5 秒、10 秒、15 秒)进行确认。
  • 如果返回的 HTTP 状态码为 50x,则表示 query 请求失败,但尚不明确录制是否已退出。出现 50x 错误的概率极小,建议使用退避策略 (5 秒, 10 秒, 15 秒) 继续调用 query

获取 M3U8 文件名

获取 M3U8 文件名有两种方式,一种是按照文件命名规则拼接,另一种是通过 query 来查询。anyRTC 推荐通过拼接的方式获取文件名。

按照文件命名规则拼接

根据录制的类型,录制的文件名进行相对应的规则拼接而成。

通过 query 请求获得 M3U8 文件的文件名

M3U8 文件名是第一份切片文件生成后产生的,所以需要在第一次切片完成后查询。详见切片规则

合流录制模式下,建议在成功开启云端录制 15 秒后调用 query 查询 M3U8 文件名;单流录制模式下,建议在成功开启云端录制 1 分钟后调用 query 查询 M3U8 文件名。如果第一次查询失败,建议采用退避策略多次调用(比如 1分钟后重试)。

有中间休息的录制场景

录制中可能会出现业务上会场休息的场景或者频道内有一段时间内没有发流端发流的情况,针对这种情况anyRTC给出的策略如下:

start 方法中的 maxIdleTime 参数默认值为 30 秒。根据实际的通信场景设定该参数的值。

比如,大班课上课过程中,没有中间休息 2 分钟的情况,则可以将 maxIdleTime 设置为5分钟,能避免整堂课的录制不中断。

遇到有中断的情况,使用 maxIdleTime 字段来保证录制不中断