Roku Developer Program

[bkgoodman]

A am in the process of developing a "channel" - and am creating some test content to test my streaming/encoding workflow, and am running into some issues. Due to the nature of what I am seeing, it doesn't seem like it is a problem in the encoding as so much as a problem with Roku...
I am following all Roku's guidelines on the encoding format, and am having minimal success as follows:

I create a video, and fragment it as required. (10 Second fragments, 380x360, 800k/bps, 23.98fps, etc. etc.)

When I go to play the video, the "Recieving" bar would start to fill up, then stop - without ever playing the video. As I susspected there might be a problem later in the video, I edited my m3u8 file to trim down the video (remove fragments from the end). When I got it down to about 5 fragments, the video played just fine.

So I figured there must be some problem with the 6th fragment, etc. I tried a lot with re-encoding, etc, never resolved the issue. Then I tried the following:

If I list the *same* fragment around 5 times - the video will play back properly. However, If I play the *same* fragment back more than 5 times, the playback gets stuck on "Recieving".

In experimenting further - I find that I can specify any 5 fragments and the playback will work. If I specify more than 5, playback will never properly start.

Any idea what the issue could be??

Brad Goodman
SeaChange International

[bkgoodman]

I tried to re-encode video using exact settings listed in Roku encoding guide, and had no luck. In fact - it may have even gotten a little worse. (It only appears to now play 4 fragments before failing).

My test videos are simply a series of PNG files which are being encoded to an H264/MPEGTS stream, using FFMPEG, as specified in the encoding guide.

[RokuKevin]

If you send me an url to a test stream, I'll take a look.

--Kevin

[bkgoodman]

Thanks a ton!

I put some abbreviated test samples on a public server which demonstrate the issue:

I have 4 .ts files (call them frag1-frag4 for the sake of converstaiton), and created 3 different manifests which all use these same files to demonstrate the issue.

The manifest at:
http://www.bradgoodman.com/HLSTest3/appleTest3.m3u8
Will play fragments 1-4. This should work, but doesn't. It will work from my iPhone.

The manifest at:
http://www.bradgoodman.com/HLSTest3/appleTest2.m3u8
Will play frament1 three times. (You'll be able to see the counter reset around 10 seconds, when the first fragment repeats - this will happen twice). This test will play correctly on the Roku box.

The manifest at:
http://www.bradgoodman.com/HLSTest3/appleTest.m3u8
Is just like appleTest2 (above), but repeats the first fragment four times, as opposed to three. This test will not play at all.

Thanks for all the help!

-BKG

[bkgoodman]

Have you gotten a chance to check these out? Any ideas? 😉

[bkgoodman]

One more "hint":

Although the video does not begin to play - if a longer video is actually specified - the Roku box will continue to attempt to read the rest of the fragments of the video.

This is done in somewhat quick succession - i.e. fragments are read about a half-second apart - like is done when initially prefetching the video - not every 10 seconds apart, as it was normally playing.

[RokuMarkn]

Each of these URLs contains a single fragment, at least when I just looked at them. Are these changing dynamically?

--Mark

[bkgoodman]

Each of these files contain a reference to a single program at a single bitrate. For example, the file:

http://www.bradgoodman.com/HLSTest3/appleTest2.m3u8

Contains the following:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=737777
prog_index2.m3u8

Which indicates the program "prog_index2.m3u8" (which is a relative reference to the file at http://www.bradgoodman.com/HLSTest3/prog_index2.m3u8.) This is the file which contains the actual fragment list, which (in this example) is:

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
HLStest3-1.ts
#EXTINF:10, no desc
HLStest3-1.ts
#EXTINF:10, no desc
HLStest3-1.ts
#EXT-X-ENDLIST

..which lists the actual three fragments. This example is from the video that actually works.

Thanks for your help!

-BKG

[bkgoodman]

Tested these videos with Boxee (both Boxee box and Windows client) - everything worked fine (as they also do with iPhone and iPad).

-BKG

[RokuKevin]

I'm getting different results than you did... If you haven't done so, Please update to v3.0.

http://www.bradgoodman.com/HLSTest3/appleTest3.m3u8
Plays fine. (Only plays for 10 seconds)

The manifest at:
http://www.bradgoodman.com/HLSTest3/appleTest2.m3u8
Plays fine. (Only plays for 10 seconds).

The manifest at:
http://www.bradgoodman.com/HLSTest3/appleTest.m3u8
Doesn't play at all, and I get warnings about:
"expecting start of section: discard 184 video bytes"

How were the transport stream files created?

--Kevin