2

我们注意到 HLS 在一个正在开发的视频点播 iOS 应用程序中、在高延迟网络上的性能极差，并希望对下载的发生方式进行一些手动调整。

这些文件（完全编码的、从头到尾的 TS/M3U8 文件）已经在 CloudFront 上提供，所以我们在服务器端可以做的只有这么多来优化它（我认为）。

另一个希望是在 iOS 应用程序中运行一个本地主机服务器，让这个“服务器”通过优先于更频繁、更小段的下载来管理下载。因此，希望能够规避网络的高延迟，同时仍然能够使用可用的体面带宽。

这里的想法是让我们自己了解基础“index.m3u8”及其描述的所有比特率，并且只向 iOS 公开一个简单的 TS 文件“播放列表”（没有任何比特率信息）。

但是，我陷入困境的是试图弄清楚 iOS 将如何实际请求 TS 文件。也就是说，即使 iOS 尝试播放“直接”的 M3U8 文件（一个没有多个比特率的文件），我相信它也会尝试发送 TS 文件的范围请求。但是在不知道这些文件的比特率的情况下，iOS 会请求 localhost 的字节范围是多少？即使它确实请求特定的字节范围，它怎么可能是正确的？由于我之前从 localhost 向 iOS 提供的文件，可能是比特率为 1 Mbps 的“5.ts”，而下一个文件可能是比特率为 500 Kbps 的“6.ts”。iOS 无法估计下一个文件的正确字节范围是多少？

我概述的方法（为每个 TS 文件切换比特率，对 iOS 透明）甚至可以工作吗？或者，M3U8 中指定的所有 TS 文件是否必须强制具有与我尚未阅读的 HLS 规范的某些部分相同的比特率？


我想我可能会混淆一些事情，或者没有正确理解 iOS 是如何与基本流媒体一起工作的。一些关于这方面的真正知识将非常有帮助。

谢谢！

4

2 回答 2

4

我刚刚意识到我的问题是没有实际意义的，是深夜脑溢血的结果。

iOS在发出范围请求以下载 TS 文件时，无需注意M3U8 中指定的比特率。它将向Range: bytes=0-1TS 发送一个请求以开始，在响应中获取文件的长度，然后根据需要缓冲的距离或 MediaPlayer 框架内部考虑的任何其他变量来发出未来的请求。

今天只需用新鲜的眼光查看标准 MP4 的范围请求模式（如在此链接中）就解决了这个问题。

对不起，噪音。

PS：换句话说，我在原始问题中概述的方案实际上会起作用，除非有任何其他问题。

于 2013-04-09T14:35:27.280 回答
0

如果您没有在播放列表文件中指定字节范围，客户端将不会发出字节范围请求。

于 2013-04-08T10:41:33.883 回答