音视频请求的生命周期

一个典型的音视频请求经历从 创建 到 播放 再到 关闭 的三个阶段，以下分述音视频请求生命周期中的这三个阶段以及这些阶段中的相关活动。

音视频请求的创建

音视频请求的创建由调用者通过 POST /strm/live/open（实时音视频播放）或 POST /strm/replay/open （远程回放）接口向服务端提出请求。

实时音视频播放请求

服务端作以下判断：

远程录像回放请求

服务端作以下判断：

异步模式打开与同步模式打开的区别

打开实时音视频接口(POST /strm/live/open)和打开远程录像回放接口(POST /strm/replay/open)的请求体都有一个async属性（不指定时为false）。 调用者通过这个属性选择使用的模式。将async设为true则使用异步模式，而将async设为false或不指定该属性则使用同步模式。

• 异步模式是服务端在分配请求ID时完成了初步的判断以后立即返回给调用者，然后再进行终端交互。当终端开始推流时，或终端在特定时间内未能成功推流时，服务端通过WebSocket通知调用者（注意：当请求打开通道进行播放时，如果通道已经有其他请求打开了，则打开接口返回的数据中）。
  • 优点：
    • 可同时打开更多的播放而不需要使用一些变通方案
    • 接口立即返回，可随时关闭请求
    • 相对更好的传输效率
  • 缺点：
    • 必需订阅WebSocket通知，这样才能感知进而处理在终端不在线时、或终端返回发生错误应答等情况，代码逻辑相对复杂
• 而同步模式则在完成终端交互并检测到终端推流时返回成功码和请求ID(reqId)，如果判定终端不在线，或终端在特定时间内未能成功推流时，返回错误码。
  • 优点：
    • 可选订阅WebSocket通知，代码逻辑相对简单
  • 缺点：
    • 需要使用多域名变通方案才能同时打开较多的播放
    • 在服务端与终端建立媒体连接或确定终端不在线之前无法关闭请求（因请求尚未返回）
    • 传输效率相对略低

从使用和效果上来说，异步模式打开与同步模式打开有以下区别：

模式	接口参数	返回后码流是否已可用	返回时可确认终端不在线	需要订阅WebSocket通知
同步	async: false	是	可确认	可选
异步	async: true	不一定	不可确认	必需

建议尽可能使用异步模式。

音视频请求的几种状态

音视频请求内部有多种状态，以下为客户端主要关心的状态：

• 下发指令(sent)。服务端刚下发了指令。
• 终端指令失败(failed)。下发终端指令后，终端响应失败代码。
• 终端开始推流(id)。服务端已经检测到终端的码流。
• 流已经准备好(ready)。服务端已经为客户端打开流做好了准备。
• 请求已经关闭(closed)。当前请求因为客户端请求关闭或因终端不在线、码流断开等原因关闭。 注意：实时音视频播放中，流关闭并不意味着终端已经关闭码流，如果有其他请求仍在使用码流，则终端码流将仍然保持推流，只是当前的请求ID(reqId)已经关闭、失效。

客户端订阅WebSocket的StrmNotif通知后，打开通道时可获得以上这几种状态的通知。但如果是异步模式的实时音视频播放，且请求时同一通道已经有已打开的其他请求，则客户端的WebSocket订阅不会得到该请求的sent, failed, id, ready这几种状态的通知。

以下是这几个主要状态的状态机图：

实时音视频的共享打开

对于一个特定的实时音视频通道，当只有一个请求打开时，该请求具有对媒体流的控制权，可执行切换码流、暂停流、恢复流的操作。

如果后续有请求打开同此音视频通道时，即在特定实时音视频通道上有多于一个的活动流请求时，所有的请求均失去对媒体流的控制权， 不能对流执行切换码流、暂停流、恢复流等操作，此时执行这些操作将返回-25: 无控制权。但对于关闭请求(ctrl为0)，虽然返回-25，但错误返回后，传入的请求ID(reqId)将失效。

当流请求接连关闭，最后剩下一个请求时，剩下那个请求重新获得对媒体流的控制权，可执行切换码流、暂停流、恢复流的操作。

注意：数据类型为对讲实时音视频播放（dataType为2，参见POST /strm/live/open）不支持共享打开。对于同一通道，当已有数据类型为对讲的实时音视频播放请求打开了，该通道后续打开所有数据类型的实时音视频播放请求将返回-21: 资源已被占用，直到先前的对讲请求关闭。 同时，对于同一通道，当已经有任何类型的实时音视频播放请求打开了，后续的数据类型为对讲实时音视频播放请求将返回-21: 资源已被占用，直到先前打开的请求关闭。

远程录像回放不支持共享打开

远程录像回放不支持共享打开。对于同一通道，当已有远程录像回放请求打开了，后续打开远程录像回放的请求将返回-21: 资源已被占用，直到先前打开的请求关闭。

音视频请求的保持

因客户端可能因错漏出现未关闭播放器的情况，以及HLS协议下由于无连接方式使得服务端无法判断客户端的请求是否仍然活跃，为避免终端不必要的推流，流媒体服务为实时音视频请求和远程录像回放请求设置客户端心跳和超时机制。

在POST /strm/live/open接口或POST /strm/replay/open接口请求返回成功后，客户端应设置特定周期(15秒)的定时器，周期性地通过调用POST /strm/keep_alive接口，直到请求关闭或流关闭。 如果在约定的时间内没有收到这个保持调用，则流媒体服务将主动关闭请求，如果请求的通道上的所有请求都已经关闭，流媒体服务关闭终端连接。

音视频的播放

不论同步或异步打开，当打开成功时，服务端会预先分配一个playUrl播放地址并返回给调用者，调用者后续用这个地址来加载媒体。

• 如果使用同步模式，则返回对象的ready属性总是为true，这种情况下，可以直接创建播放器并加载媒体。
• 如果使用异步模式，则要看当前是否已有其他已打开的请求：
  • 如果已有其他已打开的请求，则返回对象的ready属性为true，这种情况下，可以创建播放器并加载媒体。
  • 否则，返回对象的ready属性为false，这种情况下，需要视乎请求的客户端协议来决定是否马上创建播放器并加载媒体：
    • 采用HTTP FLV协议的，可以马上创建播放器并加载媒体，此时播放器将等待码流。也可等到收到act为ready的流媒体状态通知时再创建播放器并加载媒体。
    • 采用HLS协议的，需要等到act为ready的流媒体状态通知时，才创建播放器并加载媒体。

音视频通道的控制

• 在实时音视频播放过程中，可以调用POST /strm/live/ctrl接口来进行切花码流、暂停、恢复等控制。
• 在远程录像回放过程中，可以调用POST /strm/replay/ctrl接口来进行暂停、恢复、快进、快退、拖动、关键帧播放等控制。

音视频请求的关闭

在以下情况下，音视频请求会关闭：

• 客户端调用接口关闭请求
  • 对于实时音视频播放：调用 POST /strm/live/ctrl 接口, ctrl为0，closeAction为0
  • 对于远程录像回放：调用POST /strm/replay/ctrl 接口, ctrl为2
• 客户端未能在约定的时间内调用 POST /strm/keep_alive 保持接口
• 终端不在线
• 终端未能成功推流
• 终端码流断开
• 终端码流格式错误
• 服务端发生未处理的异常

当音视频请求关闭时，对应的reqId不可再使用，同时服务端会通过WebSocket向相关客户端推送流媒体状态通知（act为closed）。 当同一通道上的所有请求都已经关闭，则终端通道也将被服务端关闭。