Roku Developer Program

[smlsr]

I will confirm we are seeing the same/like issues.

Whatever methodology has changed in 2.9 is seriously flawed in getting the network speed.

We compared to wired vs wireless, etc. Using a 1.5Mbit stream. It seems the ROKU hard locks on the bitrate of the stream of sorts, where it could actually be grabbing more but remains grabbing at 1.4/1.5Mbit.

We see this more when we introduce "off net", not local subnet routing. Local subnet routing performs much better. Is their a difference in the code ROKU is using in the TCP stack when the source of the stream is an IP which is local to the subnet the ROKU is on?

I as well can provide access to our server and private channel if you wish to test.

PM me.

Shawn

[smlsr]

Like to add some observations, as this is definitely an issue:

Seems the ROKU (as suggested above) sets the "network connection speed" to the speed of the received segment, plus maybe some small amount.

So for example, if you have a stream, that is a live stream, and on the fly transcode, the first segment, will be at a rate that is about the stream bitrate, but less because of the initial delay. Lets say 1Mbit on a 1.5mbit stream. It then proceeds to cap itself around that. Over time watching the network statistics, i see the ROKU, rising a little by little.. say to 1.2mbit, after rebuffering once... then slowly moving upwards to 1.5mbit, some rebuffering and so on. Now, the available data on our server has grown, but the ROKU fails to get it at any faster speed. Which causes excessive rebuffering.

If i do this with a stream which is 100% available, I can slam the ROKU with a chunk of data at 10mbit speed, and it NEVER rebuffers.

Now with bandwidth the way it is, one slow segment, should not cap the ROKU. or their needs to be a better "Recovery" model in the network computation.

Question for ROKU:

Will a DISCONTINUITY TAG in an HLS m3u8, cause the ROKU to abandon it current bandwidth computation, and retry at full speed?

Am I better off serving a 2.5Mbit Commercial Pre-roll from our CDN, to ensure the ROKU believes it has a lot of bandwidth to start?

While these are not solutions, these are questions for work arounds. Being a week or so away from releasing a bunch of stuff for ROKU, we have spent a considerable amount of time working to ensure quality is above and beyond, and with this latest issue, we will not release anything without ensuring we can play content at the best possible conditions and the ROKU needs to be able to access it in the same light..

Shawn

[smlsr]

Another note your engineering team should be aware of.

Bandwidth these days is not like having 1 PIPE, and you get whats available in it. More and more technologies in cable plant, wireless, etc utilize on demand channel bonding. Take for instance wireless 4G services (Sprint/Clear network), or Time Warner Cable (Brighthouse). Lets say you have the Turbo package from brighthouse. 40Mbit down, 5Mbit up. They dont have all that opened up to your modem. What they do is have a set portion available, call this the base. As you begin using the bandwidth, channels begin to bond and release as needed (and available). The same holds true for many ISP's. So your initial download speed (first 20 seconds) may be say 1mbit, increasing to 1.5mbit, then you see a jump to 2.5mbit, and more... Channels are bonding. Once you stop "demanding", channels release back down to the base.

This does not exists on a local lan, where all the bandwidth exists all the time. So when your dealing with remote content, you have a progressive increase in bandwidth many times, and each time you start up a new request, if some time has passed since the last request, the process is progressive again. Since the roku is locking in at the last segment, your defeating what is actually available.

As I stated above, would be more then happy to work with you directly, give you access to the content, etc whatever is needed to resolve the issue.

Shawn

[smlsr]

Ok, I have done some additional playing around.

I have preloaded my HLS stream with 2Mbit, 2 Minute long, HD trailer, served from our CDN, which is quite fast.

In doing this, the ROKU again locks onto the bitrate of the HD trailer which is served to it. So when it transitions to the real media, which is 1.7Mbit, again remotely served, it hovers at 1.8Mbit when downloading the streams.

When I play a local stream (same on being played remotely), it acts entirely different, it talk 10-12Mbit runs at each segment, disregarding the the above performance.

So, my assumption is when playing remote content, it locks onto the bitrate, when it plays local, it takes all it can get, or doesnt bother doing a bandwidth test computation.

So now, my bigger issue, if I am going to have run 2-3Mbit bitrate commercials, just so ROKU can play a 2Mbit stream, the cost becomes absurd.....

If I prepend the video with a 400Kbit Preroll, buffering issues...
If I dont prepend the video with any preroll, and just serve the stream @ 1.7Mbit, buffering...
If I prepend the video with a 2Mbit (slightly larger than the actual stream), I get no buffering....

So being all this is done using the SAME network... This is NOT a network issue, it is an issue in which the ROKU is computing the available bandwidth.

Additionally, one would think that when you are done playing a video, ROKU would RESET the bandwidth parameter back to 10Mbit. But it does not, so if I play a 800kbit stream, when I start the next video... It still thinks it only has 800Kbit of network bandwidth, and if the stream is biggerr... long time to load...


How we can we resolve?

Shawn

[smlsr]

Here is an important updating after playing around with the TCP and some options.

1. Disabled Nagle algorythm on the Server, allowing faster sends
2. Increased buffer size to allow for slow Acking on the ROKU for TCP Packets.

Enabling these has fixed the overall speed problem in sending. So I wanted to let the ROKU folks know this, so not chasing a ghost.

BUT - The bug of computed bandwidth lingering after playing a video still exists. Meaning, lets say from within my channel I play a video, and the bandwidth from the source is 1.2Mbit to me. Video finishes, or I exit, then go to play another video, and this other video starts off believing only 1.2Mbit is available. It should reset to 10Mbit after done playing. As this other video is coming from a site which delivers high speed 8mbit to me, but because the ROKU thinks it only has 1.2Mbit, it takles 60-90 seconds to load the 2 minute commercial which is at 2Mbit....

If I reset the ROKU, and start watching the 2nd video first, the commercial starts within seconds.


So point is to the user who posted this, look at the setting on your server serving the stream, as the ROKU controls it TCP Acking very strictly, and if your using that for buffer control as we were and such, you will get only the video stream bitrate, which is not quite actually what you can get if you increase your network buffers.

And, ROKU, can we fix the big so the computed bandwitdh resets before watching new media?

Shawn

[RokuKevin]

You may want to look into the Strategy content meta-data parameter. Our default stream switching strategy did change in v2.9, as we now take into account buffer fullness in addition to measured bandwidth. If you set it to "minimum-adaptation", your app may use the v2.7 and prior default switching strategy of just using bandwidth and not buffer fullness.

--Kevin

[dynamicmindset]

The SwitchingStrategy parameter wasn't set.
I tried using all the values (minimum-adaptation, full-adaptation, unaligned-segments) but it doesn't make any difference.

[smlsr]

If I may ask, what are you using to SERVE the streams? custom software? commercial web server?

Shawn

[krazy]

Damn!!!

we are having same exact issues and it is not the network

1. Cannot play 1.5mbps stream on a 0.8mbps network because at so and so time stream requires 1.1mbps and it buffers.

if the player thinks that it is playing 1.5mbps stream on a 2.1mbps network it shows video super fast under seconds.

The underlying network is 10mbps

How to get rid of this problem easy way ??

can some one please suggest required settings either in APP or where we need to make the changes, this is live telecast.

[krazy]

rebooted roku,

and it shows playing back 1.5mbps stream on 10.0Mbps network. Video shown very fast , almost instant

second step it reduces the bandwidth playing back 1.5mbps stream on a 0.7mbps network