Issue/Detection WIFI Strength/Max Limits

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.

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?

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

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.

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

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

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

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

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.

When handling a wifi connection, the CPU needs to do more work than when handling an Ethernet connection. So in situations where large amounts of CPU resources are also needed to handle the stream (high bitrates, small packet sizes in the container, etc), there may be videos whose playback consumes too much CPU resources on wifi but can still be played on a wired connection. This is independent of signal strength or network bandwidth. Unfortunately there's not much that can be done other than choosing a less CPU-intensive encoding.

--Mark