本文档介绍集成云端录制 RESTful API 时的几个注意事项,最大程度的保证服务的可靠性。
获取服务状态
- 使用 RESTful API 获取服务的状态
- 消息通知服务 获取服务的状态
消息通知服务只能作为辅助手段来获取服务录制状态。不建议你的核心业务逻辑依赖消息通知服务。
每个 App ID 每秒钟的请求数(QPS)限制默认为 10 次。请根据你的同时最大并发频道量(PCU)和查询间隔,预估所需的 QPS,并联系客服申请调整 QPS 限制。
确认录制服务已成功启动
-
start
请求成功,即成功获得sid
(录制 ID)。如果start
请求失败,需要根据状态码采取相应措施:- 如果返回的 HTTP 状态码为
40x
,则表示请求参数错误,排查错误信息。 - 如果返回的 HTTP 状态码为
50x
,可多次调用该请求,直到成功返回sid
为止。建议使用间歇策略,如第一次等待 3 秒后重试、第二次等待 6 秒后重试、第三次等待 9 秒后重试,以免超过 QPS 限制导致失败。如果三次重试均失败,建议更换 UID 再次调用acquire
, 获得一个新的 resource ID,并用该 resource ID 再次调用start
方法。
- 如果返回的 HTTP 状态码为
-
获得
sid
之后的 5 秒后,使用退避策略调用query
方法,退避间隔建议小于start
请求中的maxIdleTime
(最长空闲频道时间)。如果query
请求成功,且serverResponse
中的status
参数值为4
或5
,则表示录制服务已成功启动。如果在获得sid
之后的 90 秒后status
仍非4
或5
, 则可以认为录制未启动或成功后超时退出。
建议你准备一个备份 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 推荐通过拼接的方式获取文件名。
按照文件命名规则拼接
-
单流录制下,M3U8 文件名的格式为
<sid>_<cname>__uid_s_<uid>__uid_e_<type>.m3u8
。详见录制文件命名规则。 -
合流录制模式下,M3U8 文件名的格式为
<sid>_<cname>.m3u8
。详见录制文件命名规则。
根据录制的类型,录制的文件名进行相对应的规则拼接而成。
query
请求获得 M3U8 文件的文件名
通过 M3U8 文件名是第一份切片文件生成后产生的,所以需要在第一次切片完成后查询。详见切片规则。
合流录制模式下,建议在成功开启云端录制 15 秒后调用 query
查询 M3U8 文件名;单流录制模式下,建议在成功开启云端录制 1 分钟后调用 query
查询 M3U8 文件名。如果第一次查询失败,建议采用退避策略多次调用(比如 1分钟后重试)。
有中间休息的录制场景
录制中可能会出现业务上会场休息的场景或者频道内有一段时间内没有发流端发流的情况,针对这种情况anyRTC给出的策略如下:
start
方法中的 maxIdleTime
参数默认值为 30 秒。根据实际的通信场景设定该参数的值。
比如,大班课上课过程中,没有中间休息 2 分钟的情况,则可以将 maxIdleTime
设置为5分钟,能避免整堂课的录制不中断。
遇到有中断的情况,使用 maxIdleTime
字段来保证录制不中断