Roku Developer Program

[smlsr]

Ok Ive kind of run into an issue of sorts, and its really not an issue for me, but in giving the best experience to the user.

Ive been able to stream 9Mbit video to the ROKU on wired..... Now sometimes it does hiccup, but this is true HD 1080 video..

Now, the issue comes into play with WIRELESS. We all know their are 1000 flavors of wireless, and each one truly has an impact on video. (I understand this part thoroughly). No what is different between every user is the quality of the bandwidth they are able to receive, the type of network they are on (B,G,N,N+, etc), the amount of retransmissions occuring, etc.

Now streaming over wireless at 4500mbit, sometimes works, sometimes doesnt.

So I guess what I am asking, is their a way to retrieve the ROKU, the quality of the connection? Using this, i can limit the allowed type of streams in the channel and so on.

Does ROKU have any hard limits/practical limits on their hardware interfaces. The hardwire Ethernet seems to be ok, but will still like to know on both WIRED and WIRELESS.

Thanks
Shawn

[destruk]

About the only way I could see of doing this - is to stream a test file first, and time how long it takes to complete. Provided the connection isn't using any kind of burst transfer cheats from the ISP, and the wireless is stable, you should get a good baseline that way.

[kbenson]

Isn't that the purpose of specifying multiple bitrates for the video, so Roku can automatically determine the best one based on the available bandwidth?

[TheEndless]

"kbenson" wrote:
Isn't that the purpose of specifying multiple bitrates for the video, so Roku can automatically determine the best one based on the available bandwidth?

In this particular case, we're talking about transfer rates on a closed local network where live transcoding of multiple streams is not realistic. In our testing, we've seen mixed results on both wired and wireless interfaces , but the results over wireless have been the most inconsistent across devices. By all rights, a 4.5-5 mbit/s stream shouldn't struggle over a healthy wireless G network, but in most cases we're seeing excessive buffering that isn't present over wired. The same stream plays fine over wireless from one computer to another (with high enough transfer rates to eliminate buffer size as an issue), so the bottleneck does not appear to be the network itself. Our goal is to eliminate (or at least mitigate) any end user confusion that may be caused by offering higher bitrates than the network interface can support. If Roku can provide some hard numbers on that, then that will give us a solid reference point to work from.

[rilex]

With wireless, there are many more factors than a wired connection on a switch, especially if that switch can operate at line speed. For instance, wireless architecture is much like a hub. Then you have the interference factor as well as software that may not be all that great in the WAP.

[kbenson]

"TheEndless" wrote:

"kbenson" wrote:
Isn't that the purpose of specifying multiple bitrates for the video, so Roku can automatically determine the best one based on the available bandwidth?

In this particular case, we're talking about transfer rates on a closed local network where live transcoding of multiple streams is not realistic. In our testing, we've seen mixed results on both wired and wireless interfaces , but the results over wireless have been the most inconsistent across devices. By all rights, a 4.5-5 mbit/s stream shouldn't struggle over a healthy wireless G network, but in most cases we're seeing excessive buffering that isn't present over wired. The same stream plays fine over wireless from one computer to another (with high enough transfer rates to eliminate buffer size as an issue), so the bottleneck does not appear to be the network itself. Our goal is to eliminate (or at least mitigate) any end user confusion that may be caused by offering higher bitrates than the network interface can support. If Roku can provide some hard numbers on that, then that will give us a solid reference point to work from.

Ah. I hadn't been paying enough attention enough to the original question.

Since this is in a local network, I assume there's some server side software helping. If that's the case, does generating some files of known size for download and timing the download not provide sufficient information on the connection to adequately benchmark the network? I think generating a files out of random data of both 100k and 1000k for testing (attempt 100k first, if it's fast enough then attempt 1000k) would allow for quite accurate bandwidth measurements.

[TheEndless]

"kbenson" wrote:
I think generating a files out of random data of both 100k and 1000k for testing (attempt 100k first, if it's fast enough then attempt 1000k) would allow for quite accurate bandwidth measurements.

I can tell you've never worked with video on the Roku... 😛

More to the point, yes, we can do benchmarking ourselves (even dynamic), and obviously have done some, but we're hoping that Roku, who has an infinitely larger test bed than us, could give us some numbers based on their own benchmarks.

[kbenson]

"TheEndless" wrote:

"kbenson" wrote:
I think generating a files out of random data of both 100k and 1000k for testing (attempt 100k first, if it's fast enough then attempt 1000k) would allow for quite accurate bandwidth measurements.

I can tell you've never worked with video on the Roku... 😛

Hehe, got me there.

More to the point, yes, we can do benchmarking ourselves (even dynamic), and obviously have done some, but we're hoping that Roku, who has an infinitely larger test bed than us, could give us some numbers based on their own benchmarks.

Okay, so if I get this right, the question is whether the hardware interfaces can support throughput of a specific rate when connected using different technologies, correct? If you are looking for the device to report it's connection info, such as it's media state, I think you may be better off doing manual testing. Regardless of what the unit negotiates, you'll never know what actual throughput you get without testing. For example, wikipedia lists the practical maximum for 802.11b as 5.9Mbit/s for TCP, even through the media will happily link at 11Mbit/s. As you've both alluded to, the network conditions for the end user are specific to that network, and it's not as simple as simply knowing what the unit states it's connection is. Important also is the existing traffic on that network. Regardless of what rate you've connected at, if something else on the network is hogging most the bandwidth, you'll never see the performance you expect.

Now, if I misinterpreted the question/request (likely), and you are looking to have Roku expose a bit more of the specifics of it's automatic bandwidth testing for bitrate determination, well, I'm all for that. 😉

[smlsr]

This post is somewhat concerning....

viewtopic.php?f=34&t=37151

TS (HLS) over wireless, is a beast, small packets (188 bytes), and a fat stream. So lots of decoding on the ROKU side as well, add in the TCP acking, then add in the actual wireless cell acking, and repeating/buffering, its a mesh of unknowns....

I think the overall bigger question is what CAN ROKU support in a combined wireless/hls environment, and a wired/HLS environemnt. The actual wireless stack on the ROKU seems easy enough to blow up, so I would prefer not keep doing that.

As for metrics, a lot of interfaces inherently provide a quality level, signal strength etc directly from the radio itself. The dropoff in wireless is excessive but also unpredictve unfortunately. Really at this point, just looking for some sort of feedback from the ROKU engineering folks as to what their findings are.

Would seem a shame to disallow HD HLS streaming on our application entirely if the ROKU is on a wireless network, but may have to do that, as Im not into creating myself a support nightmare.

Shawn

[rilex]

The Roku uses the standard Linux Wireless Tools 2.8 package (although they may have modified it in some way, we won't know). They're a revision behind, at least according to what they're using on the Open Source page.