We've noticed extremely poor performance of HLS in a Video-On-Demand iOS app under-development, on high-latency networks, and were hoping to perform some manual tuning of how the downloads occur.
The files (fully encoded, start-to-finish, TS/M3U8 files) are already being served off CloudFront, so there's only so much we can do on the server side to optimize this (I think).
The other hope was to run a localhost server in the iOS app, have this "server" manage downloads by prioritizing fewer, larger segment downloads over more frequent, smaller segment downloads. Thus hopefully circumventing the high latency of the network, while still being able to use the decent bandwidth available.
The idea here, was to keep the knowledge of the base "index.m3u8" and all the bitrates it describes, to ourselves, and expose only a naive "playlist" of TS files (without any bitrate information) to iOS.
However, where I'm stuck is in trying to figure out how iOS will actually request the TS files. That is, even when iOS tries to play a "straight" M3U8 file (one without multiple bitrates), I believe it will try to send range requests for the TS files. But without knowing the bitrate of these files, what byte-range would iOS request localhost? Even if it does request a specific byte-range, how could it POSSIBLY be correct? Since the previous file I had served from localhost to iOS, may have been say "5.ts" with a bitrate of 1 Mbps, and the next one could be "6.ts" with a bitrate of 500 Kbps. iOS cannot possibly estimate what the correct byte-range for the next file would be??
Can the approach I have outlined (switching bitrates for each TS file, transparent to iOS) even work? Or must all TS files specified in an M3U8 compulsorily have the same bitrate as per some part of the HLS spec that I haven't read?
I think I might be confusing a few things or have not properly understood how iOS works with basic streaming in general. Some real knowledge on this would be extremely helpful.
Thanks!
I just realized that my question is moot and result of late-night brain-ooze.
iOS need not pay any attention to the bitrates specified in the M3U8 when making range requests to download TS files. It will send a Range: bytes=0-1 request for the TS to start with, get the length of the file in the response, and then make future requests based on how far it needs to buffer or whatever other variables the MediaPlayer framework considers internally.
Just looking at the Range Request pattern for a standard MP4 (as at this link) with fresh eyes today settled this.
Sorry for the noise.
P.S: In other words, the scheme I have outlined in my original question will in fact work, barring any other issues.