我们注意到 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 是如何与基本流媒体一起工作的。这方面的一些实际知识将非常有帮助。
谢谢!
我刚刚意识到我的问题没有实际意义，是深夜脑溢血的结果。
iOS 在发出范围请求以下载 TS 文件时，无需注意 M3U8 中指定的比特率。它将发送一个 Range: bytes=0-1 请求让 TS 开始，在响应中获取文件的长度，然后根据需要缓冲的距离或MediaPlayer 框架内部考虑的任何其他变量。
今天以新鲜的眼光看标准 MP4 的范围请求模式(如 this 链接)解决了这个问题。
抱歉打扰了。
P.S:换句话说，我在原始问题中概述的方案实际上会起作用，除非有任何其他问题。
关于iOS HTTP Live Streaming - 比特率未知时请求的字节范围？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15728185/
| 欢迎光临 OStack程序员社区-中国程序员成长平台 (https://ostack.cn/) | Powered by Discuz! X3.4 |