HTTP Live Streaming 播放器行为答案

【问题标题】：HTTP Live Streaming player behaviorHTTP Live Streaming 播放器行为
【发布时间】：2012-09-14 12:28:02
【问题描述】：

我正在开发播放 HLS Live 内容的播放器。因此，它会定期重新加载测试链接的 .m3u8 索引文件。

例如播放器重新加载了 01.m3u8 索引文件。

(01.m3u8 - #1)

       0.ts---the player tried to download this 100.ts file first.
       1.ts---
       2.ts
       3.ts

然后，它尝试下载 0.ts 文件。

但是，网络带宽不足以快速下载这个 0.ts 文件。

下载一个 TS 大约需要 24 秒。所以，它又重新加载了 02.m3u8 索引文件。

(01.m3u8 - #2)
       2.ts---the player tried to download 102.ts file first.
       3.ts
       4.ts
       5.ts

但是，播放器在索引文件中找不到 1.ts 文件。因为，在播放器下载 1.ts 文件之前，服务器已经更新了索引文件。因此，播放器尝试下载 2.ts 文件而不是 1.ts 文件。

这意味着播放器丢失了 20 秒的流数据。那么，这种行为是否符合规范，因为它看起来令人困惑？

我认为它应该从 1.ts 而不是 2.ts 开始更新 m3u8。或者它是如何决定的。

谁能给点建议？

【问题讨论】：

【解决方案1】：

只要播放列表仍然是目标持续时间的至少三倍，规范就允许服务器从播放列表的开头删除 URI。（draft-pantos-http-livestreaming-08 第 6.2.2 节）

如果播放列表文件的持续时间减去片段的持续时间小于目标持续时间的三倍，则服务器不得从播放列表文件中删除指定片段的媒体 URL。

只要播放列表包含 4 个片段，长度只有微小的变化，这似乎是一种有效的行为。对于实时流，我希望服务器以与添加片段相同的速度从流中删除片段。因此，对于 10 秒的片段，我认为删除 2 个片段而您花费 24 秒下载单个片段是合理的。

【讨论】：

【解决方案2】：

它做了正确的事。解决您面临的问题

如果您只需要 1 个比特率，您应该知道您的网络带宽并进行相应的编码 [适用于封闭和受控环境]

或

在多个带宽中编码并使用多个比特率设置您的 m3u8，并确保您将最低的作为第一个条目，HLS 将相应地进行调整。在几个段内，它将达到目标带宽。这实际上是 HLS 的重点。

【讨论】：