OSS livechannel 推流过程
录制 M3u8 缺失
默认录制成品的 m3u8 所以只有最后 3 片，遵循的是 hls 协议的默认规则，是正常想象，可以通过调用 PostVodPlaylist 接口将指定时间范围内的 ts 文件汇聚到一个 m3u8 索引内来解决；
tips
-
EndTime必须大于StartTime，且时间跨度不能大于1天。 - OSS会查询指定时间范围内的所有该
LiveChannel推流生成的ts文件，并将其拼装为一个播放列表。
录制 m3u8 文件 失败
- 先看下是否已经成功推流到来 OSS 才算成功，客户端抓包必须能看到有 publish succees 的标志后，和 OSS 有正常的音频包交互才算成功，所以发现客户端推流有记录，但是就是没有录制视频的情况，就需要自己抓包分析下；
录制 M3u8 文件卡顿
- 转储类型为 HLS 时，写入当前 ts 文件的音视频数据时长达到
FragDuration指定的时长后，OSS 会在收到下一个关键帧的时候切换到下一个 ts 文件；如果max(2*FragDuration, 60s)后仍未收到下一个关键帧，OSS 强制切换文件，此时可能引起播放时卡顿；
录制 M3u8 文件没有音频或视频
在此之前没有 hls 协议基础，或者对音视频不懂的同学很难理解，我们先恶补一些关键名词和包结构
RTMP 的音视频流的封装形式和 FLV 格式相似, 流媒体服务器向客户端发送包含 H264 和 AAC 的 RTMP 直播流，需要首先发送这两个 header，没有这些信息播放端是无法解码音视频流的，其中音频 tag 格式如下
-
AVCsequence header -
AACsequence header
从上面推论出 AAC sequence header 内容的前 2 个字节是 0xAF 0x00，我们来看一个示例：
ADIF：Audio Data Interchange Format 音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。故这种格式常用在磁盘文件中。
ADTS：Audio Data Transport Stream 音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于 mp3 数据流格式。
解码流程
经过知识补充后我们说下以下几种情况会出现音频或者视频没有录制的情况：
-
AVC header或者AAC header没有发送，抓包也能看出来。 -
RTMP message长度小于2，或者是sequence header非常小 - 音频
Message超过缓冲区大小。 -
codec_ ctx解码上下文的关键信息，如果携带的音视频数据异常，也会导致录制失败。