Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
belltown
Roku Guru

Re: How to stream http stream?

"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."
0 Kudos
EnTerr
Roku Guru

Re: How to stream http stream?

"belltown" wrote:
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.
Segment does not exist in the logical sense - but there is a new file under the same name - that gets played. Nobody has seen an error. I'll take a guess they use file rename for switching file contents transactionally.

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.
That's true, i noticed values go over EXT-X-TARGETDURATION:10, i don't like it but apparently it was not a practical issue. And both Roku and VLC played without messing things up. But i suppose trouble may surface if trying to rewind.

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.
Yes. But all that means is there will be a jerk in playback within the first segment loop (or 60 seconds) - then it will auto-synchronize and should play smooth. Don't get me wrong, i am not saying everything is fine with that m3u - like i said, chock full of problems. But the issues you point out don't seem related to the looping.

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
And i believe caching explains all of the behavior here - how Roku plays the same video loop, repeatedly - and VLC plays linearly. None of your arguments explain that, do they?
0 Kudos
RokuMarkn
Visitor

Re: How to stream http stream?

I can't tell you exactly why that stream is failing, although I'm sure it has something to do with the peculiar reuse of sequence numbers. I can tell you however that the Roku player ignores the EXT-X-ALLOW-CACHE header, so that's not related.

--Mark
0 Kudos
belltown
Roku Guru

Re: How to stream http stream?

"EnTerr" wrote:
i believe caching explains all of the behavior here - how Roku plays the same video loop, repeatedly - and VLC plays linearly. None of your arguments explain that, do they?


I've seen many examples of the Roku looping when trying to play a non-compliant HLS stream, or even a spec-conformant stream that just doesn't adhere to what Roku "recommends" for HLS playback in terms of numbers of segments and segment durations. For example, I've seen it go into a loop when trying to play a sequence of segments with a short duration followed by a segment with a much relatively larger duration, eg. 4s, 3s, 5s, 15s. Normally there are enough upcoming segments to prevent problems, but in a case like this, for instance after it gets done playing the 3 short segments (12s total duration), the longer (15s) segment hasn't been written yet, and the Roku goes into a loop. Having more segments and having their durations be more consistent helps alleviate these kinds of problems, as long as you don't start trying to read from too close to the end of the file. I could cite other cases too, the point being that the Roku's looping behavior can easily occur (based on my personal experience) in a number of different situations. I disagree with your statement that none of my arguments explain the looping behavior. As RokuMarkn says, it's most likely a sequence number issue.
0 Kudos
EnTerr
Roku Guru

Re: How to stream http stream?

"RokuMarkn" wrote:
I can't tell you exactly why that stream is failing, although I'm sure it has something to do with the peculiar reuse of sequence numbers. I can tell you however that the Roku player ignores the EXT-X-ALLOW-CACHE header, so that's not related.

That's good to know (that Roku does not follow the HLS spec in the case of EXT-X-ALLOW-CACHE) - then there is no point of putzing around with it.
Will "salting" the URLs help instead to prevent caching?
I.e. adding a unique query-strings behind, so no two URLs are textually equal.
0 Kudos
RokuMarkn
Visitor

Re: How to stream http stream?

"EnTerr" wrote:

That's good to know (that Roku does not follow the HLS spec in the case of EXT-X-ALLOW-CACHE) -


Roku follows the spec by never caching content. That is correct behavior regardless of the EXT-X-ALLOW-CACHE setting.

--Mark
0 Kudos
EnTerr
Roku Guru

Re: How to stream http stream?

"RokuMarkn" wrote:
Roku follows the spec by never caching content. That is correct behavior regardless of the EXT-X-ALLOW-CACHE setting.

OIC. Agreed, not caching content and ignoring EXT-X-ALLOW-CACHE would be kosher with the spec.
This new info i think sinks my caching theory; probably not worth trying salted URLs.
0 Kudos
belltown
Roku Guru

Re: How to stream http stream?

Ok, I think I've solved the mystery.

I went back and tried to play the first link from the first post for myself this time, using VLC. It only played for 41 seconds then stopped.

I then tried playing the stream using the link from the web site, http://www.latvdefrance.com/stream/live/name/tf1. It played from 01:44:38 to 01:45:19 (the last 41 seconds) then stopped.

When I first visited the web site it said, "Vous n’êtes pas connecté, votre accès est limité à une minute! Créez un compte pour accéder à 12h d’essai gratuit".(Translation: You are not logged in, your access is limited to one minute! Create an account to access 12 hours of free trial). Even after I created an account and logged in, it still wouldn't play more than the last 41 seconds of the stream. There were also messages about requiring a paid subscription to view the live streams.

I tried playing their streams from previous days' TV on my Roku. They played just fine.

Conclusion: The live streams won't play more than a minute's worth of content unless you supply the appropriate credentials for a valid paid-up subscriber account.
---------------------------
It still seems a little odd that the server would generate a playlist file reusing the same 6 segment files over and over again. I'm not surprised though that VLC and my browser's media player only played the last 41 seconds, whereas the Roku kept looping, It's been my observation that the looping is normal behavior for the Roku when it gets confused playing an HLS stream.
0 Kudos
httpslash
Visitor

Re: How to stream http stream?

That's odd. Even with a trial subscription, I was able to play the stream without any repeats/stops, I know this because I was able to watch a soccer game. What I do know however is that if you're not a subscriber or trial subscriber in this case, the stream link which is in page source(not hidden at all) is different. The stream link( which is http) is named to indicate it is a demo. I'm guessing that by playing the non http stream link, vlc connects to the demo link which is why it stops after 41 seconds as non subscribers only get 1 minute. So I think it must be something else
0 Kudos
belltown
Roku Guru

Re: How to stream http stream?

Where were you watching the soccer game with your trial subscription -- on your Roku??
0 Kudos