我们注意到在高延迟网络上开发中的视频点播iOS应用程序中HLS的性能极差，并且希望对下载的发生方式进行一些手动调整。
文件（完全编码，从头到尾，TS / M3U8文件）已经在CloudFront之外提供服务，所以我们可以在服务器端做很多事情来优化它（我认为）。
另一个希望是在iOS应用程序中运行本地主机服务器，让这个“服务器”通过优先考虑更频繁，更小的段下载更少，更大的段下载来管理下载。因此，希望能够绕过网络的高延迟，同时仍能够使用可用的合适带宽。
这里的想法是将基础知识“index.m3u8”及其描述的所有比特率保留给我们自己，并仅向iOS公开TS文件的天真“播放列表”（没有任何比特率信息）。
然而，我陷入困境的是试图弄清楚iOS将如何实际请求TS文件。也就是说，即使iOS尝试播放“直接”M3U8文件（没有多个比特率的文件），我相信它会尝试发送TS文件的范围请求。但是在不知道这些文件的比特率的情况下，iOS请求localhost的字节范围是多少？即使它确实请求了特定的字节范围，它怎么可能是正确的？从我从localhost到iOS提供的上一个文件，可能已经说出比特率为1 Mbps的“5.ts”，而下一个可能是“6.ts”，比特率为500 Kbps。 iOS无法估计下一个文件的正确字节范围是什么？
我所概述的方法（为每个TS文件切换比特率，对iOS透明）是否可行？或者，M3U8中指定的所有TS文件是否必须具有与我未读取的HLS规范的某些部分相同的比特率？
我想我可能会混淆一些事情或者没有正确理解iOS如何与基本流媒体一起工作。一些真正的知识将非常有用。
谢谢！
答案 0 :(得分：4)
我刚刚意识到我的问题没有实际意义，也是深夜脑渗出的结果。
在制作下载TS文件的范围请求时，iOS无需关注M3U8 中指定的比特率。它将为TS开始发送Range: bytes=0-1请求，在响应中获取文件的长度，然后根据缓冲需要的距离或MediaPlayer框架内部考虑的任何其他变量进行将来的请求。
只要看一眼标准MP4的范围请求模式（如this链接那样），新鲜的眼睛今天就解决了这个问题。
对不起噪音。
P.S：换句话说，我在原始问题中概述的方案实际上是有效的，除非有任何其他问题。答案 1 :(得分：0)
如果您没有在播放列表文件中指定字节范围，客户端将不会发出字节范围请求。