i need to know what the limits are to the resolutions, for example netflix claims up to 1080p, but im unable to get a non-scrambled hls stream above 704x400, i can raise the bitrate nice and high, but i would like to be able to do live streaming up to 720p and 1080p myself i have the equipment for that already, its just a matter of the profile settings and so on now being accepted, and i dont see these settings listed any where, so im simply basing my highest available settings 704x400 @ 3000kbps (again bitrate im sure isnt the limiter here)

So please devs shed some light on the specs allowed, and perhaps why 720p live streaming isnt possible when on demand functions perfectly fine up to 1080p with my current setup. I would like to be able to provide a 1024x576 @ 3000 kbps which is seriously nice quality for a live stream.

** Also i would like to add for those of you who tried 10 seconds x 8 segments rolling window, let me further recommend 25 seconds x 8 segments, in my experience the cheapest dedicated server hosting is in europe. and the latency and routing are generally a problem for some people in usa that might want to save some money but at the same time cover europe and asia with there services, and that lower setting, is generally going to be the cause of it, im sure some will argue but i tested vigorously for a very long time here now, and 25000 miliseconds x 8 , has sincerely not buffered coming from Gbit in .NL to East Coast USA here to my Roku, so this does indeed mean international solutions are possible for HLS without the use of an expensive CDN, i was able to get Adobe Interactive Media Server 4.5.x working very well the built in apache 2.2 hosts the mp4 / xml files for my on demand perfectly even up to 1080p from webroot folder, and otherwise that setup will host HLS you dont need to pay insane prices for a CDN company to do something you can do yourself. **

claudioc, our setup is similar where our stream is coming from Asia with high latency. Are you using Wowza for your live streaming?

HLS Backup Stream Loading Prior to Primary Stream: I have a question about the HLS backups streams and how Roku handles the playback of the primary and backup streams. With our configuration we are seeing Roku loading the backup stream first and then pretty quickly adapting and in the process switching to the primary stream. But our backup stream is not in sync with the primary stream so the switch between primary and backup is pretty disorientating.

Couple of questions:

1. Why does Roku load and playback the backup stream at all, as opposed to working with the primary streams unless it encounters a problem?2. Is it uncommon or common to have the primary and backup streams out of sync (as we do in our configuration)?

HLS Backup Stream Loading Prior to Primary Stream: I have a question about the HLS backups streams and how Roku handles the playback of the primary and backup streams. With our configuration we are seeing Roku loading the backup stream first and then pretty quickly adapting and in the process switching to the primary stream. But our backup stream is not in sync with the primary stream so the switch between primary and backup is pretty disorientating.

Couple of questions:

1. Why does Roku load and playback the backup stream at all, as opposed to working with the primary streams unless it encounters a problem?2. Is it uncommon or common to have the primary and backup streams out of sync (as we do in our configuration)?

Thank you,JasonH

Someone at Roku will need to confirm, but I don't think the Roku supports backup streams. In my (limited) experience with those playlists that have backup streams (two or more streams with the same bitrate), the Roku tends to either pick one randomly, or uses the first in the list. I'm not sure which, but it seemed like the former, as you'd expect it to stick with the first for every bitrate otherwise.

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.

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:

Failover ProtectionIf 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:

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.

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.

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?

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.

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.

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