This post will attempt to gather the common HLS issues and solutions that people are running into when rolling out solutions. The Encoding guide in the SDK will include much more detail, but this post and follow on comments should gather community knowledge as we are all working out our solutions…
When using an HLS Live Sliding Segment Window, Roku recommends 8x 10 second segments. The HLS spec minimum of 3 segments does not allow for any variance in bandwidth or latency. Roku’s 8x10sec segment window drastically reduces rebuffers.
HLS Live is particularly sensitive to uploading the .m3u8 and .ts segments in a timely manner to the CDN. Timestamps and sequence numbers for all variant streams must be aligned and present on the CDN when they are included in an .m3u8. Please see the encoding guide for a script that can help you monitor your live streams for these problems.
The default MinBandwidth is set to 250 (250k) so that audio only streams are excluded from the playlist as Roku can’t play them. Video on a TV really should be 800k or higher.
Earlier versions of Wowza specified the bandwidth at 64k by default. So these Wowza streams were excluded by Roku by default. When streaming from wowza, be sure to set the minBandwidth meta-data parameter correctly. You need to set it low enough so that your video streams are all included and high enough so that the audio only streams are excluded. Or set the bandwidth of your streams correctly on the wowza server.
If your HLS streams are less than 1.5 Mb/s, they may take very long in the preloading phase. Roku considers this a bug in the current firmware, but there is a workaround. Instead of setting content metadata StreamBitrates = [0] for your HLS stream, set it to the actual bandwidth of your stream when it is less than 1.5 Mb/s. Example for 900kbps stream: StreamBitrates = [900]
When there are discontinuities in your HLS stream, be sure that the PIDs of the audio and video do not change. The Roku firmware currently has a bug where we do not search for new audio and video PIDs on these discontinuities. So the workaround is to make sure you use the same audio and video PIDs for the entire length of the stream.
“DawtComm” wrote:
So with #3 Is this why the 5.1 channels are not passed through on the roku 2?
I’m not sure that Roku’s HLS implementation supports 5.1, but regardless #3 is unrelated, as it’s referring to low bitrate standalone audio only streams, not audio/video streams.
In a Multi-bitrate scenario, does setting the stream bitrate to a fixed number to speed up buffering prevent the roku from adjusting if the bandwidth changes, or does continue to auto adjust?
Does anyone know if there is a way to get the Roku to request m3u8 files using (byte) range requests?
It currently is requesting the entire m3u8 every 5-10s for live HLS streams, and for a long video (with a large m3u8 as it approaches the end) , that can really take up a lot of unnecessary bandwidth (100-200kbps).
Our media server is indicating it supports (byte) range requests (using the HTTP response header of “Accept-Ranges: bytes”), but the Roku refuses to request only the incremental range of bytes with each new request.
Any ideas how to convince the Roku to request only what it actually needs? Sample HTTP request and response headers of how it is currently behaving are below:
GET /testvideo/2000000/main_2000000.m3u8 HTTP/1.1
Connection: close
Host: http://www.mydomain.com
User-Agent: Roku/DVP-4.2 (024.02F01006B)
Accept-Encoding: deflate, gzip
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/x-mpegURL
Accept-Ranges: bytes
Content-Length: 67212
Date: Wed, 04 Jan 2012 04:39:32 GMT
I don’t think you can make the Roku request byte ranges, particularly since M3U8s are dynamic by nature, but is it possible to tell your server to respect the “Accept-Encoding: deflate, gzip” header? That should significantly reduce the excess bandwidth.
Unfortunately gzip on the server is not an option (at least not for the foreseeable future).
Why would dynamic content preclude range requests? The HTTP specification defines how to request range requests for content with a dynamic endpoint (Range: bytes=10-). In fact, iOS makes range requests (sample request headers below from an iPhone) so it is definitely possible (and advisable, IMO).
GET /testvideo/main.m3u8 HTTP/1.1
Host: www.mydomain.com
User-Agent: AppleCoreMedia/1.0.0.9A405 (iPhone; U; CPU OS 5_0_1 like Mac OS X; en_us)
Accept: /
Range: bytes=0-1
Accept-Encoding: identity
X-Playback-Session-Id: BA0654E2-75C7-4FD2-AFF8-28FEB3F69244
Connection: keep-alive
“roquoonewbie” wrote:
Why would dynamic content preclude range requests? The HTTP specification defines how to request range requests for content with a dynamic endpoint (Range: bytes=10-). In fact, iOS makes range requests (sample request headers below from an iPhone) so it is definitely possible (and advisable, IMO).
GET /testvideo/main.m3u8 HTTP/1.1
Host: http://www.mydomain.com
User-Agent: AppleCoreMedia/1.0.0.9A405 (iPhone; U; CPU OS 5_0_1 like Mac OS X; en_us)
Accept: /
Range: bytes=0-1
Accept-Encoding: identity
X-Playback-Session-Id: BA0654E2-75C7-4FD2-AFF8-28FEB3F69244
Connection: keep-alive
Because it’s the content of the M3U8 that is dynamic, not just the endpoint. It’s usually only in the case of VOD (or live streams with a “play from beginning” option) that the start point is static. They are typically rolling windows with only the initial playlist header information being static. Your “Range: bytes=0-1” example is the initial request from iOS that is essentially a HEAD request that verifies the first byte is the “#” character, and is only made at the very beginning of playback. If I’m not mistaken, Roku does the same thing.
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. **
how is it possible no engineers answered me on the FIRST post on the forum after this much time ? just seems like a while to pass for the first post on the forum not to be noticed. please take the effort engineers, because i have tried all variations of HD footage, and it just does not work over HLS, nothing higher than DVD Resolution will work properly, its just scrambled, and im 100% sure it works otherwise in flash situation BEFORE the HLS packaging in adobe, and like i said lower resolution works in HLS so there’s no argument the HLS streaming works in general.
are you setting streamqualities to [“HD”]? What kind of encoder are you using? Can you PM me an example of your streaming URL? I have not seen a problem like this streaming HD content over HLS.
You might want to try with a bitrate lower than 3000kbps for initial testing.
We are using Adobe FLME and Wowza. What would be the recommended settings for those that are familiar with FLME and Wowza.
Here is what I have in our Wowza Origin application:
cupertinoChunkDurationTarget
10000
Integer
cupertinoMaxChunkCount
10
Integer
cupertinoPlaylistChunkCount
8
Integer
cupertinoRepeaterChunkCount
8
Integer
For FMLE, our advanced encoding settings is set to:
Profile: Main
Level: 4.0
Keyframe Frequency: 10 seconds.
What needs to be adjusted to improve the “loading please wait” issue. Some of our source is coming from Asia with latency. Anyone getting it to work successfully in a similar scenario?
When using 25 second segments, you are trading off startup time and quick bitrate switches for more tolerance to variance in network bitrate and longer round trip times.
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:
Why does Roku load and playback the backup stream at all, as opposed to working with the primary streams unless it encounters a problem?
Is it uncommon or common to have the primary and backup streams out of sync (as we do in our configuration)?
“JasonH” wrote: 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:
Why does Roku load and playback the backup stream at all, as opposed to working with the primary streams unless it encounters a problem?
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.
“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:
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.
? just seems like a while to pass for the first post on the forum not to be noticed. please take the effort engineers, because i have tried all variations of HD footage, and it just does not work over HLS, nothing higher than DVD Resolution will work properly, its just scrambled, and im 100% sure it works otherwise in flash situation BEFORE the HLS packaging in adobe, and like i said lower resolution works in HLS so there’s no argument the HLS streaming works in general.