In Part 1, I was surprised at how little packet loss it took to affect video streaming, but was just as surprised at how hard it was to disturb files played using TCP/IP based protocols. Armed with this knowledge, I set out to see whether success in wireless video streaming was really as hard as I have been making it out to be.
We found in Part 1 that video streams can vary widely in their bandwidth needs and that there are two methods for playing video files across a network. Since I mainly wanted to explore the largest uncontrollable factor in wireless streaming - neighboring WLANs - I decided to use one test file and one play method. I chose an uncompressed VOB (MPEG2) test file with a bandwidth profile shown in Figure 1. The bandwidth was measured using Hoo Technologies' Net Meter.
Figure 1: Test file bandwidth profile
The four-minute test file has plenty of action in it, which accounts for the fairly high average bandwidth. These figures are above the 5 Mbps or so bandwidth number that I've heard thrown around in IPTV-related discussions with equipment vendors, but aren't out of the question for downloaded or ripped content. For comparison, Figure 2 shows the bandwidth profile of a short HD movie trailer.
Figure 2: Quicktime HD 720p file bandwidth profile
Note that this is a 720p file in Quicktime HD, which uses the very bandwidth-efficient H.264 codec. While the average bandwidth (the one that most vendors will quote, of course) of the HD file is lower than the test file's, the peaks are more than 3 times higher.
I chose UDP streaming as the play method because it is the most likely to be used by both network-based content providers and for in-home network play of downloaded and stored content by devices using UPnP AV and DLNA protocols.
I started out with a simple test two-WLAN setup, figuring that I could always make it more complicated if I needed to (Figure 3). I used two Linksys WRT54G routers configured as access points (see this link for a quick how-to). Using them as access points ensured that I wouldn't encounter any of the routing problems that the v5 router has. Plus, the lack of NAT firewalls made it easy for the IxChariot console to control everything.
Figure 3: Test setup configuration
I mixed things up a bit on the client side because I didn't have two WPC54G notebook cards. So the "Neighbor" client used the Gigabyte GN-WPEAG mini-PCI card that I had added to my Fujitsu S2020 Lifebook awhile back. The Gigabyte card uses an Atheros Super-G chipset, which had no problem working with the Broadcom-based radios in the Linksys routers. The "Home" client is my trusty Dell 4100 Inspiron with 1GHz Celeron and 576MB of RAM, running Windows XP Home SP2.
To simulate the worst case of two WLANs on the same channel, both routers were set to Channel 6. I left all the other settings at their defaults (Figure 4) and no encryption was used.
Figure 4: Wireless settings for Linksys WRT54G's
To put a little distance between me and my potentially interfering WLAN, I set up the "Neighbor" WLAN as shown in Figure 5. The walls are 2x4 sheetrock with no ducting or metallized insulation in them. This setup attenuated the "Neighbor" WLAN's signal somewhat, but the "Home" client still reported an "excellent" signal when I temporarily connected it to the "Neighbor" WLAN AP.
Figure 5: Test area floor plan
It may be obvious - however judging from some of the mail I get on the subject it may not be - but the key rule for successful wireless streaming is:
The available bandwidth of the connection must be sufficient to support the bandwidth required by the content.
Figures 6 and 7 illustrate the rule, showing IxChariot plots of a single wireless connection between the "Home" WRT54G and WPC54G client card. Figure 6 starts out with an IxChariot throughput.scr script running TCP with a file size of 100,000 Bytes. You can think of this as simulating a long file download. After about 45 seconds, I started streaming the test video over the same connection to the same client.
Figure 6: Shared data and video stream - 11g WLAN
While it's not a one-to-one match, if you take the bandwidth profile of the test file in Figure 1 and flip it upside down, it corresponds reasonably well to the "bite" taken out of what would otherwise be a straight 21 Mbps throughput line. Another check is that the throughput drops by about 9 Mbps - the average throughput of our test video file.
What was surprising here is that the video stream takes all the bandwidth it needs, dropping the speed of the IxChariot throughput script, i.e. our file download. This happened with the Wireless Quality of Service (QoS) / WMM mechanism in both routers disabled and with no sign or QoS or WMM in the client card properties or settings. So it appears that the available bandwidth for streaming in this particular WLAN is the total bandwidth. This polite behavior isn't guaranteed to occur, however, especially in WLANs that use a mix of clients and APs.
Because there is enough bandwidth to support the video stream, the video plays with no problems - as if there were nothing else happening on the WLAN. But if you were little Susie, running your nightly BitTorrent session, you would notice the drop in Torrent download speed.
Of course, if there isn't enough bandwidth to go around, miracles don't occur. Figure 7 shows what happens when the Linksys router is forced to run in 802.11b mode.
Figure 7: Shared data and video stream - 11b WLAN
This time, the IxChariot script gets only about 5 Mbps of bandwidth, typical of an 11b connection. So when I start streaming the video - which needs an average of 9 Mbps or bandwidth - at about the 15 second mark, the result is not surprising. The stream tries take as much bandwidth as it needs, but comes up short and an unwatchable video results (Figure 8).