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
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.
If you send me an url to a test stream, I’ll take a look.
–Kevin
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
Have you gotten a chance to check these out? Any ideas? 
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.
Each of these URLs contains a single fragment, at least when I just looked at them. Are these changing dynamically?
–Mark
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
Tested these videos with Boxee (both Boxee box and Windows client) - everything worked fine (as they also do with iPhone and iPad).
-BKG
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
I retried my tests (with the same videos on the same servers) - and got the same results.
I upgraded to 3.0.2202 then tried the tests again, and got the same results. “appleTest” fails, “appleTest2” plays, and “appleTest3” fails.
Could you double-check your results?
- We both agree “appleTest” should fail
- You said “appleTest2” played for 10 second - I say it should play for 30 seconds. (Please see below)
- You said “appleTest3” played, whereas for me it failed.
RE: appleTest2:
When you say the video “only plays for ten seconds” - does it really?
The videos should play the first fragment three times. So if your just looking at the counter - and not paying attention - you might miss the fact that is has repeated.
Also - where do you see the error message you spoke of? I do not see any.
I encoded these videos from a series of still PNG files, using FFMPEG, exactly as specified in the “Roku Encoding Guide”.
Thanks for your help!
Any update on this?
I incidentally was able to obtain some output from a (very expensive) RGB encoder, which seemed to work properly.
Any help on getting the FFMPEG generated content working would get this project back on track. Right now, Boxee seems to be my only answer…
Thanks,
-BKG
Any help on this?
I’m finding the box unusable.
Any way to debug what’s going on?!?
