Roku Developer Program

[retrotom]

Hey,

We're trying to start an HTTP live stream with one .TS segment in it. What we're seeing, is that it appears that the Roku is attempting to download the entire segment before it begins playback. Is this normal? What kind of behavior/logic does/should the roku use when attempting to play a transport stream? Our issue here is that we'd like to dynamically build the stream -- but the screen is stuck on "buffering" while it continually loads the stream. If we chop the same segment up, we get playback -- but audio/video sync goes out the window sometimes. The shorter the clip, the greater the potential for the issue -- and the worse the impact. Is there any specific guide for HLS encoding? I've noticed a mention of Video Encoding Guide in the documentation -- but have not been able to locate that. Does such a document exist? And if so, where can it be found?

Thanks,
RT

[RokuMarkn]

The HLS spec (http://tools.ietf.org/html/draft-pantos ... reaming-03) requires that there always be at least three segments in the playlist at all times. The spec recommends that each segment be 10 seconds long, but some providers have chosen to use shorter segments, down to 5 seconds. We'd recommend careful testing if you choose a segment size less than the recommended 10 seconds. The Roku player does download and buffer a certain amount of data before playback begins. The exact amount downloaded depends on the measured network bandwidth, but it's shorter for HLS than for any other media format.

--Mark

[retrotom]

"RokuMarkn" wrote:
The HLS spec (http://tools.ietf.org/html/draft-pantos ... reaming-03) requires that there always be at least three segments in the playlist at all times. The spec recommends that each segment be 10 seconds long, but some providers have chosen to use shorter segments, down to 5 seconds. We'd recommend careful testing if you choose a segment size less than the recommended 10 seconds. The Roku player does download and buffer a certain amount of data before playback begins. The exact amount downloaded depends on the measured network bandwidth, but it's shorter for HLS than for any other media format.

--Mark

Thanks for the update Mark. However, example 7.1 shows a single entry playlist. Is that not supported?

EDIT: That's 8.2 in the link you provided. I was looking at v2 of the spec.
EDIT2: We've been using 15 second segments and seeing weird audio/video sync issues. When we play the segments individually, they don't exhibit that same behavior. Not sure what to do about that one, but it's less of a concern if we can get the box to start playing a file we stream to it. I will be investigating using three segments -- something like (itty bitty segment)-->(itty bitty segment)-->(rest of stream).

[RokuMarkn]

The requirement is only for live streams, that is, streams that do not include the endlist tag. The example in 8.2 is a non-live (vod) stream. Are your streams live or vod? Also, I see that they changed the requirement slightly in the latest spec. The requirement is the last sentence in 6.2.2. Earlier versions of the spec said the playlist must include at least three segments; the latest spec just says that the duration of the playlist must be at least three times the target duration. Nevertheless, I'd recommend that you always keep at least three (preferably more) segments in a live stream.

I don't know what is causing your a/v sync issue. The first thing to check is you should make sure that the PTS values in both the audio and video streams increment seamlessly across the segment boundaries.

--Mark

[retrotom]

Thanks (once again) for your insights here. We are probably going about this the wrong way. We are including the ENDLIST tag. The stream is basically "live", so we may have the wrong format here. It would be awesome if these two/three changes gets this to work. It was my assumption that it would still "stream" a vod file. As far as the a/v sync -- I'll need to check on the PTS in the segments. My hunch is that they're not being copied from the original input file -- but start from 0. I didn't think to check that. Anyways...

Thanks again!

[RokuMarkn]

From your comments I'm not sure if you're doing this or not, but I just want to make clear that you should never have an m3u8 file point to a TS file which is still being written to. The m3u8 must point to static, unchanging TS files. The correct way to append to a live stream is to update the m3u8 to point to new (but still static) TS files.

--Mark

[retrotom]

"RokuMarkn" wrote:
From your comments I'm not sure if you're doing this or not, but I just want to make clear that you should never have an m3u8 file point to a TS file which is still being written to. The m3u8 must point to static, unchanging TS files. The correct way to append to a live stream is to update the m3u8 to point to new (but still static) TS files.

--Mark

Mark, thanks for your help on this one. I finally got it working correctly. Something that wasn't obvious (at least to me), is that you need to explicitly set the MEDIASEQUENCE each time the playlist is retrieved. I wasn't doing this and the Roku would "load" whenever it went to download the new version of the playlist. As soon as I added that bit -- it started working correctly.

Thanks again,
RT

[RokuMarkn]

You need to set the media sequence number if the first TS URL in the file is NOT sequence number 1. Having correct sequence numbers is very important (as you've found) because that's how the player knows in what order the TS files are to be played.

--Mark