Roku Developer Program

[TimB_Kulabyte]

At Kulabyte we have an encoder that delivers both RTMP Flash and iOS HTTP streams with H.264/AAC codec. I am able to send RTMP to a Wowza server to produce iOS HTTP and then play that back on the Roku box - both as a single stream or as adaptive streaming with a .smil file. If I try to play the exact same stream (i.e. same H.264/AAC stream data) on the Roku using our native HTTP served by an Apache server or Akamai, the streams do not play at all - sometimes the debug message will pop up saying "Playing 1.5Mb stream on your 5Mb connection" and then it goes right back to the menu. I've tested this with a 2.6 firmware as well as 2.8b1158. Also, it is worth noting that iPad and iPhone and Quicktime on the Mac play both the Wowza stream and Kulabyte stream just fine.

I'm wondering if the Roku box is not liking something in the .m3u8 file from the Kulabyte encoder. Below are examples:

Wowza
#EXTM3U
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:52
#EXTINF:12,
media_52.ts?wowzasessionid=1498761846
#EXTINF:12,
media_53.ts?wowzasessionid=1498761846
#EXTINF:10,
media_54.ts?wowzasessionid=1498761846

Kulabyte
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:2516
#EXTINF:10,
/http/480p_6384_segment_2516.ts
#EXTINF:10,
/http/480p_6384_segment_2517.ts
#EXTINF:10,
/http/480p_6384_segment_2518.ts
#EXTINF:10,
/http/480p_6384_segment_2519.ts

The only differences I see are EXT-X-ALLOW-CACHE and the fact that Kulabyte is putting the relative path on the .ts file whereas Wowza is putting no path on the .ts file. Again, the Apple devices play both Wowza and Kulabyte streams fine and we've run our streams through Apple's media stream validator and they are pretty clean.

What's the best way debug this further? Is there a super secret logging capability that will tell me more about what the player does not like?

Regards,

Tim

[RokuMarkn]

Currently the Roku player does not support absolute pathnames in the m3u8 (paths that start with a slash). The path should be either a full URL, or a relative path, relative to the location of the m3u8 itself. It's an arguable point whether absolute paths are allowed by the HLS spec. They will probably be supported in a later release even though they are (probably) not strictly allowed by the spec. But for now, use relative paths.

--Mark

[RokuKevin]

Have you tried removing the leading '/' on your segment urls ?

EXT-X-ALLOW-CACHE:NO just controls when we will throw used buffers away on the Roku box, so that would not seem to be the culprit.

--Kevin

[TimB_Kulabyte]

Thanks guys for the quick answer. Let me have my developers remove the leading / and hopefully that will take care of the issue.

Regards,

Tim

[TimB_Kulabyte]

We updated our segment URLS and streaming from our encoder to the Roku box is basically working now. I've discovered some other issues, but will start new threads for them.