Roku Developer Program

[RokuKevin]

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...

1) 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.
2) 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.
3) 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.
4) 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.
5) 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]
6) 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.

--Kevin

[DawtComm]

So with #3 Is this why the 5.1 channels are not passed through on the roku 2?

[TheEndless]

"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.

[DawtComm]

Oh yeah sorry, I read it a bit to fast. Sorry to confuse.

[jbrave]

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?

- Joel

[roquoonewbie]

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

[TheEndless]

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.

[roquoonewbie]

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

[TheEndless]

"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.

[claudioc]

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. **