"EnTerr" wrote:
"belltown" wrote:
I wouldn't bother. It won't work, due to the way HLS operates. The m3u8 playlist file is updated every few seconds as new media segment files are added. It's not a "static" playlist file. Even if you could download it from the server every few seconds, create a new version of the file and write it out to a "tmp" file, I don't know whether the roVideoPlayer would be able to handle a local file as a stream Url, and even if it did, you'd have to do something about the fact that the segment files it references aren't local, but served from a remote url. I think you're out of luck, unfortunately.
Hmm. Why are you so sure?
Video segments can be local, relative or full URLs:
"https://en.wikipedia.org/wiki/M3U#File_format" wrote:
Each entry ... can be any one of the following:
- an absolute local pathname; e.g., C:\My Music\Heavysets.mp3
- a local pathname relative to the M3U file location; e.g. Heavysets.mp3
- a URL.
Sorry. I missed the part in your code where you were changing the relative urls to absolute urls; I thought you were just changing the cache header.
"EnTerr" wrote:
I have doubts about your previous paragraph too, where you say a player should start at the end of the m3u - rather seem to me that since a sliding window is used for live streaming, it is server's job to update the m3u promptly so that new clients hopping in are on the current segment. But that doesn't even matter in this case - as long as player keeps playing the 6 segments (each ~10sec) without caching - even if it started at the wrong # segment, the worst that can happen is delay from live of 5x10 = 50sec
No. It just won't work unless you start reading within 6 segments from the end of the file.
Each segment has a unique integer sequence number, the first segment in the playlist file being EXT-X-MEDIA-SEQUENCE, each succeeding segment incrementing by 1. In this case, EXT-X-MEDIA-SEQUENCE is always zero, and each new segment is added to the end of the file without deleting any of the earlier segments. Furthermore, the same 6 filenames are used over and over again. So if there are 1000 segments in the file, for example, they will be segments number zero through 999. To work properly in this case the client can "hop in" anywhere -- but only if it's hopping in at one of the last 6 segments (but not less than three target durations from the end of the playlist file, which would be 30 seconds in this case, per the spec), so basically it would need to start with a segment that was 30-60 seconds from the end, roughly. If the client were to start reading the file any earlier than 6 segments from the end, an error would most likely result since the segment file corresponding to that sequence number no longer exists, having been over-written by a later segment. The earlier segments having the same names as the later segments also have different EXTINF tag values, so when the player reads an earlier segment with a 4 second duration, for example, but the file that overwrote that segment file has a 9 second duration, it ends up trying to play 9 seconds of video when the file only contains 4 seconds' worth, which can really mess things up. Another example - let's say there are 7 segments in the file, sequence numbers 0 to 6, the first six having filenames ending in 0 through 5, the last one having a filename ending in 0. If the client started reading from the start of the file, it could potentially read the first couple of segments (seq. no. 0 and 1), but when it goes to read the next segment, which should be the data from seq. no. 2, the file it reads could by then have been overwritten by the data for seq. no. 7. That could mess things up too.
I don't believe that the caching you keep referring to has anything to do with anything. It just tells the client it can keep segments that it's already read in its local memory once it's read them so it can replay them later giving the client the ability to rewind and fast-forward through the stream, etc
My guess is that the stream plays fine on VLC because VLC is smart enough to start reading from close to the end of the playlist file, but the Roku is perhaps starting from the beginning.
Another problem with the playlist file is that it specifies EXT-X-TARGETDURATION:10, yet the EXTINF tag values vary between 1 and 20 seconds. The spec says, "The EXT-X-TARGETDURATION tag specifies the maximum media segment duration. The EXTINF duration of each media segment in the Playlist file, when rounded to the nearest integer, MUST be less than or equal to the target duration."
