Is HLS broken on Roku 2?

Archived
21

“renojim” wrote:

“SolveLLC” wrote:
Here is an example of a HLS stream that played on the Roku1 2.9 and does not play on the Roku2 (hangs at 33% forever).

http://77.67.108.150/213.254.245.162/4e … tream.m3u8
There should be commas at the end of your EXTINF lines if you don’t have the optional title. MarkN and I had a discussion about this when 3.0 came out and I agreed with him that according to the spec the title is optional, but the comma is not. That m3u8 won’t work on 3.0 either.

-JT

We don’t control the feed. However, the above does work on Apple devices and it did work on Roku 2.9 (without supporting the mp3 audio).

22

“renojim” wrote:

“SolveLLC” wrote:
Here is an example of a HLS stream that played on the Roku1 2.9 and does not play on the Roku2 (hangs at 33% forever).

http://77.67.108.150/213.254.245.162/4e … tream.m3u8
There should be commas at the end of your EXTINF lines if you don’t have the optional title. MarkN and I had a discussion about this when 3.0 came out and I agreed with him that according to the spec the title is optional, but the comma is not. That m3u8 won’t work on 3.0 either.

-JT

WOW thanks guys, this was a huge help! It would have taken awhile to find this.

23

How do we fix thise issue in wowza??? :oops:

24

A bit of data here (from Plex). We send back this variant playlist and the Roku 2 immediately fails, it never requests any of the specific playlists.

Any ideas? We have a bunch of irate users :disappointed_face:


#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=720000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/4/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1500000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/5/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2000000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/6/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3000000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/7/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=4000000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/8/index.m3u8
25

“elan” wrote:
A bit of data here (from Plex). We send back this variant playlist and the Roku 2 immediately fails, it never requests any of the specific playlists.

Any ideas? We have a bunch of irate users :disappointed_face:


#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=720000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/4/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1500000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/5/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2000000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/6/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3000000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/7/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=4000000
session/4488ade7ee98af05af2b3e1a5ee9c407daeb877e/8/index.m3u8

Elan… as a plex user I want as solution as well. I’m just shooting in the dark here, but the post a few above from renojim, states the following:
There should be commas at the end of your EXTINF lines if you don’t have the optional title. MarkN and I had a discussion about this when 3.0 came out and I agreed with him that according to the spec the title is optional, but the comma is not. That m3u8 won’t work on 3.0 either.

Should you have have a comma at the end of the #EXT lines? Keep in mind I speaking as someone who has a very small understanding of this type of code, so I may be very far off base.

26

Elan’s problem is different than the one I mentioned above. It’s only the #EXTINF lines in simple playlists that require a comma at the end. I suspect Elan’s problem has something to do with the relative URIs in the variant playlist, but that’s pretty much just a guess.

-JT

27

Basically it appears that the variant playlist parser only accepts full URLs, e.g.

http://x.x.x.x/foo/bar/baz.m3u8

It does not accept the relative URLs that Apple recommends here: http://developer.apple.com/library/ios/ … index.html

bar/baz.m3u8

Nor does it accept absolute URL paths

/foo/bar/baz.m3u8

Hope that helps others looking into this problem, and thanks to JT for the hint!

28

Glad to help!

-JT

29

I don’t understand how Apple would be able to find anything simply based on a relative URL? How does Apple know what server to go to?
“When possible, use relative path names in Variant Playlists and in the individual .m3u8 Playlist files”

Amazing how that Apple thingie works eh? Right…think different. :slightly_smiling_face:

30

“destruk” wrote:
I don’t understand how Apple would be able to find anything simply based on a relative URL? How does Apple know what server to go to?
“When possible, use relative path names in Variant Playlists and in the individual .m3u8 Playlist files”

Amazing how that Apple thingie works eh? Right…think different. :slightly_smiling_face:
Relative to the URL of the m3u8, not relative in general. The same as relative paths work in web pages. They’re assumed relative to the page that contains them.

31

I still don’t understand the recommendation. Is there some enormous speed increase in accessing a file by removing the leading host url name? It’s less typing and makes it easier for you to zip the entire server contents and stick it somewhere else (like that happens every day), but other than that I don’t see the benefit. And if your playlist file is on one server and your content is spread across multiple servers, I guess they just write that off as ‘not possible, so don’t’.
What real difference does it make in performance? :wink:

32

“destruk” wrote:
I still don’t understand the recommendation. Is there some enormous speed increase in accessing a file by removing the leading host url name? It’s less typing and makes it easier for you to zip the entire server contents and stick it somewhere else (like that happens every day), but other than that I don’t see the benefit. And if your playlist file is on one server and your content is spread across multiple servers, I guess they just write that off as ‘not possible, so don’t’.
What real difference does it make in performance? :wink:
It sounds like you’re confusing HLS playlist files with standard static playlist files. M3U8 files are generated on the fly during a live stream, and are constantly requested by the client during playback. I imagine shorter URLs reduce the amount of wasted bandwidth during requests. I’m also pretty sure, by design, the contents of an M3U8 should never exist across different servers (except maybe in the case of an inserted ad).

33

Thanks for that.

34

one could, perhaps distribute across multiple servers if the servers are aliased to the same domain, on an HA cluster or nfs mounted? I can imagine if you are a company like Netflix, you would probably want the next chunk to come from the nearest server with the lowest load…

35

I’ve discovered a setup that worked on Roku 1 (2.9) but not Roku 2 (4.1) with HLS.

Our setup uses a variant playlist (requested by https) with different bitrate streams, to then request the actual playlist (by https).

The actual playlist lists the .ts files, which are AES encrypted, and the key files are requested via https, but the media files are handled with straight http.

Our server is setup to perform mutual authentication, and our https server is set to trust the roku certificate authority.

The problem we are seeing is that the first variant playlist loads correctly, and gets past the mutual authentication phase. However on roku 2, the main playlist load will fail to get past the mutual authentication, and our server refuses to deliver the playlist to roku 2 (returns on error 403 - access forbidden). This worked fine on roku 1.

If I set the roku to play the second playlist via https directly, it authenticates fine, and plays the stream perfectly.

Here is the variant playlist (with only one stream to choose) - i’ve changed the ip of the server
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=1740800
https://8.8.8.8/hls/playlist/stream1.m3u8

Here is the contents of stream1.m3u8
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:398

#EXT-X-KEY:METHOD=AES-128,URI=“https://8.8.8.8/hls/keys/stream1_132.key”

#EXTINF:10,
http://8.8.8.8/hls/stream1_398.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_399.ts

#EXT-X-KEY:METHOD=AES-128,URI=“https://8.8.8.8/hls/keys/stream1_133.key”

#EXTINF:10,
http://8.8.8.8/hls/stream1_400.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_401.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_402.ts

#EXT-X-KEY:METHOD=AES-128,URI=“https://8.8.8.8/hls/keys/stream1_134.key”

#EXTINF:10,
http://8.8.8.8/hls/stream1_403.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_404.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_405.ts

#EXT-X-KEY:METHOD=AES-128,URI=“https://8.8.8.8/hls/keys/stream1_135.key”

#EXTINF:10,
http://8.8.8.8/hls/stream1_406.ts
#EXTINF:10,
http://8.8.8.8/hls/stream1_407.ts

36

Be cool if this was fixed sometime soon. We are really looking forward to sending Roku 2s out to our clients since it is a really cool little box.

37

Yeah, we have to remove adaptive feeds until this is fixed or we have to steer people away from Roku2. Right now we’re pulling the adaptive feeds and hoping this gets fixed quickly.

38

Hi Guys,

Just curious if there are any updates on a fix for HLS on Roku 2? We are starting to get emails from people having problems with our channels and we aren’t sure what to tell them. Is this an issue Roku is going to fix or do we need to change something on our end? We are using Wowza to deliver live HLS streams and they were working fine with 3.0 on the old boxes.

Sean

39

“sberner” wrote:
Hi Guys,

Just curious if there are any updates on a fix for HLS on Roku 2? We are starting to get emails from people having problems with our channels and we aren’t sure what to tell them. Is this an issue Roku is going to fix or do we need to change something on our end? We are using Wowza to deliver live HLS streams and they were working fine with 3.0 on the old boxes.

Sean
According to the release notes for the latest firmware 4.1b1265 (viewtopic.php?f=28&t=42571 :disappointed_face:
Improved playback compatibility with HLS streams provided by Wowza servers
That was just released on Friday, so it may not have rolled out to all players, yet.

40

We also has this problems with the last build 1265