video-streaming - HTTP Live Streaming 播放器行为

Question

我正在开发播放 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。或者它是如何决定的。

有人可以提出建议吗？

score 0 · Accepted Answer

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

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

或者

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

score 0 · Accepted Answer

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

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

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

2 回答 2