Roku Developer Program

[TheEndless]

"RokuJoel" wrote:
If you have to have a backup stream, you'll need to build a mechanism to launch video playback of the backup if the initial playback fails. The backup stream should not be in the same playlist file as the primary stream. Instead, you would listen for a playback failure event and then trigger a new video playback function with the backup stream instead of the primary. You probably would want to exit playback altogether if the backup fails.

- Joel

Joel, while I couldn't find specific reference to it in the official IETF HLS spec, here's Apple's documentation on how backup streams are meant to be presented in the playlist files for use with iOS. It'd be helpful if Roku supported this as well, as I'm running across more and more providers that are using this standard:

"http wrote:


Failover Protection
If your playlist contains alternate streams, they can not only operate as bandwidth or device alternates, but as failure fallbacks. Starting with iOS 3.1, if the client is unable to reload the index file for a stream (due to a 404 error, for example), the client attempts to switch to an alternate stream.

In the event of an index load failure on one stream, the client chooses the highest bandwidth alternate stream that the network connection supports. If there are multiple alternates at the same bandwidth, the client chooses among them in the order listed in the playlist.

You can use this feature to provide redundant streams that will allow media to reach clients even in the event of severe local failures, such as a server crashing or a content distributor node going down.

To implement failover protection, create a stream—or multiple alternate bandwidth streams—and generate a playlist file as you normally would. Then create a parallel stream, or set of streams, on a separate server or content distribution service. Add the list of backup streams to the playlist file, so that the backup stream at each bandwidth is listed after the primary stream. For example, if the primary stream comes from server ALPHA, and the backup stream is on server BETA, your playlist file might look something like this:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
http://ALPHA.mycompany.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
http://BETA.mycompany.com/lo/prog_index.m3u8
 
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000
http://ALPHA.mycompany.com/md/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000
http://BETA.mycompany.com/md/prog_index.m3u8

Note that the backup streams are intermixed with the primary streams in the playlist, with the backup at each bandwidth listed after the primary for that bandwidth.

You are not limited to a single backup stream set. In the example above, ALPHA and BETA could be followed by GAMMA, for instance. Similarly, you need not provide a complete parallel set of streams. You could provide a single low-bandwidth stream on a backup server, for example.

[RokuJoel]

I'll pass on your feedback.

- Joel

[JasonH]

Joel, while I couldn't find specific reference to it in the official IETF HLS spec, here's Apple's documentation on how backup streams are meant to be presented in the playlist files for use with iOS. It'd be helpful if Roku supported this as well, as I'm running across more and more providers that are using this standard.

Thanks for the fast reply Joel and TheEndless. The streams we are working with follow Apple's documentation. So it sounds like that is part of the issue we are experiencing. I'll post back when we figure out how we end up handling this issue.

I second the request for following Apple's documentation as we are also seeing lots of movement toward following Apple's implementation.

[RokuJoel]

Hi folks, here is the official word from Engineering on Backup Streams:

Roku2 models do support HLS failover protection and will fallback to a backup stream with the same bitrate or, if no backup is available a lower bitrate variant.

Primary and backup streams should always be in sync, otherwise the failover protection does not work properly.

The Roku player should only access a backup stream if the primary stream failed to load.

If developers see different behavior they need to give us the steps to reproduce their issue and fix it (including a stream url we can test)

- Joel

[deltau2012]

Hello

I've been trying to find any information on this but we are using the nDVR addon with Wowza and streaming to the Roku with HLS. The DVR functionality works great, however when we start the stream, the Roku starts at the beginning. Is there any such code that is already made to work around this and start at the live point of the stream?

Thanks,
Trey

[RokuMarkn]

You can use the PlayStart metadata attribute to specify the start time. But see the discussion of HLS seeking near the end of http://sdkdocs.roku.com/display/RokuSDK ... ideoScreen

--Mark

[deltau2012]

Hey,

I am currently facing an issue between Wowza nDVR and Roku where a timeout occurs on Wowza when Roku is viewing a dvr portion of a currently live stream. It seams as though Roku buffers to a certain point and then stops or discontinues something that makes wowza think that a timeout with the roku has occured. At this point wowza then just closes the session and the roku plays the rest of what it has buffered. I've tested the wowza ndvr with my iphone and there are no issues with this. So I am narrowing it down to the roku side. Is there anywhere to see this communication between the roku and the server? All I can get so far is current segment data, but i'd like to see what and how much the Roku is buffering. There are sweat spots during the stream where roku will get into a good spot where the stream will never timeout but I cannot find this pattern.

Also Roku seems to loose the stream when I seek all the way to live. (it will play for about 5 seconds and then drop to the Loading Screen forever). This also does not occur on the iPhone. Is there anything on this?

I've look through everything under SDK and Forums today and still can't find anything.

Thanks,
-Trey

[djextrarice]

Currently publishing a multi bitrate HLS stream to Akamai with an Cisco Media Processor 7000 (aka Inlet Spinnaker 7000).

I used the default Inlet settings profile provided in the Roku Encoding guide. The stream looks good. I do see some macroblocking (?) on bit rate switching.

See photo

https://www.dropbox.com/s/sp007uulld8b8fk/roku-macroblock.PNG

Any idea on what I need to make sure I have setup to prevent this?

[bosborne]

We use an live stream encoder that publishes HLS to a CDN. For streams with variant playlists, sometimes the #EXT-X-MEDIA-SEQUENCE number in each of the variants get out of sync with one another. I'm working on this with the encoder developers, but they've told me that it is not part of the HLS spec that the player should use #EXT-X-MEDIA-SEQUENCE to keep variant switches in sync. I read over version 3 of the HLS spec and indeed could not find a requirement that these must be lined up.

If you read this section:
http://tools.ietf.org/html/draft-pantos ... tion-6.2.4

It reads:

Matching content in variant streams MUST have matching timestamps.
This allows clients to synchronize the streams.

The encoder meets these requirements. The segments in the playlists match up accordingly. Quicktime has no problem switching bit rates without any issue, and keeps the video in sync. However, when Roku does the switch, the video jumps all over the place because it must be doing some sort of calculation on #EXT-X-MEDIA-SEQUENCE

Can you pass this along to engineering to get some feedback?

[ooshwa]

It appears that if the first stream the Roku selects returns a 404, that the player aborts, rather than trying another. Can somebody confirm?