Streaming Wireless Video
Published: March 11, 2002
By Galan Bridgman, Windows XP Expert Zone Community Columnist
Editor's Note: Past articles by members of the online community are archived for your use. The information may become outdated as technology changes. For the most current information, please search the Web site or post a question in the newsgroups.
In Capturing Video from Analog Sources, I mentioned setting up a live video feed for a young friend who is housebound due to illness. In this column, I'll spell out the details of how I set up a wireless LAN and used Windows Media Encoder to stream live video to his computer.
I met Edward, 14, in March 2001. He's a member of my church who is currently fighting cancer for the second time in his life. His father is a missionary to Costa Rica, and Edward's two-year treatment schedule required some big family adjustments. They temporarily moved into a house close to the church. Edward's chemotherapy left his immune system susceptible to viruses, which means he has to restrict his contact with other people, including his friends at school and church.
When our pastor asked if there was some way Edward could view the church services from his home, I pondered the following technologies that could make that possible:
Closed circuit TV—This would be great, except for the fact that a street separates Edward's house and the church. I didn't think the city would appreciate us cutting a trough through the street, laying down a cable, and resurfacing the street ourselves. There are solutions that could broadcast the signal as radio frequency (RF), but they were expensive and lacked the flexibility of what could be done with computers.
Internet—Video at 56K over modems just wouldn't cut it in the quality department. DSL on both ends wouldn't be much better, with the 128K upstream limit common to the inexpensive DSL services available in our area. And T1s on both ends were out of the question for cost reasons. I've learned since that if bare copper pairs (such as the ones alarm companies use) were available from the phone company, we could have set up our own network. But they are in short supply in most cities.
Those wireless cameras you've seen ads for—I checked out this solution but found that the quality suffered severely with distance, or when passing through objects like walls or windows. In addition, the cameras had no zoom capability, so it would have been limited to a fixed view with no close-ups.
Digital video over wireless LAN—Would be a great solution...if it worked! Edward's house was about 200 feet away from the church, and a line-of-sight view was barely possible. This put it within the specs for 802.11b. I knew a lot could be done with 200-500 Kbps of bandwidth for digital video, and the flexibility of using computers on both ends was attractive. I was hooked on 802.11b at home, and wanted to find out first-hand if a Wi-Fi solution would work here. Mark Twain once said “A man who carries a cat by the tail learns something he can learn in no other way.” As challenging as this project might be, I couldn't go wrong by giving it a try.
I started by buying a computer for encoding the video. It needed a lot of horsepower, so I selected an HP Pavilion with a Pentium III processor at 933 MHz. (That was a lot in spring 2001. Pentium 4 had just come out. Not only were they expensive at the time, but I also knew that was more horsepower than I needed.)
To complete the broadcast station, I decided to use my own Sony Digital8 camcorder with a 20X optical zoom, using the S-Video output to get a high quality signal. I selected the Osprey 200 analog capture card with audio and S-Video inputs. I brought the audio signal to the Osprey directly from the sound board in the church's sound room.
Then I set up the computer with Windows 2000 (Windows XP was not available in spring 2001) and installed the free utility called Windows Media Encoder. I quickly discovered I had to trim four pixels from the top of the video input. Sometimes one or more edges of captured video has flickering pixels like static on TV screens because of underscan, a common condition in inexpensive capture solutions arising from slightly mismatched frequencies.
Setting up the Network
I set up a small network, connecting the broadcast machine in the church to Edward's laptop. I positioned a wireless access point (WAP) in a planter box in the church foyer that just barely had a line-of-sight view of Edward's house. It was the best I could do without going to extraordinary lengths. I also configured it for a maximum 2 Mbps of bandwidth instead of 11, because I'd read rumors that the signal strength would be higher if the bandwidth was set lower using my brand of equipment. I have not been able to confirm this.
I wanted some real data points indicating the strength and quality of the signal, so I inserted a wireless card in his laptop and walked around the neighborhood with Cisco's signal meter running. It confirmed that, had his house been one closer to the church, the chances of it working would be much better, but it wasn't out of the question. Bringing the laptop into his house where it had one extra window to go through did not help matters. But I set up the encoder to broadcast the signal, started the Windows Media Player on his laptop, and it worked!
With the wireless PC card, we experimented with different channels in the WAP and found that a lower channel worked better than some higher ones. There is one thing Edward can't do, and that is run the microwave during the service. It interrupts the signal too much. Luckily, their cordless phone is 900 MHz instead of 2.4 GHz, as those interfere with 802.11b as well.
However, it became clear over time that the signal strength inside his house using the PC card was too marginal. Edward was restricted to watching the service standing up, with his laptop on a bookshelf right in front of the window, and even then it didn't always work well. Not happy with this arrangement, I bought an external Instant Wireless USB Network Adapter from Linksys with a six foot cable. Now Edward puts the antenna on the outside of his living window between the window screen and the glass, and places his laptop on a couch a few feet away and watches in comfort. This setup continues to work spectacularly well.
Using Windows Media Encoder
Windows Media Encoder comes with preset profiles that have been optimized to provide good quality video and audio for various situations, maximizing bandwidth utilization and/or storage size. I experimented with many of them and found some that worked great when I was 20 feet away from the WAP and had a great connection, but did not work so well at 200 feet away. Ultimately, I decided to use the profile editor in Windows Media Encoder to create my own profile, optimized for my exact situation. I started by copying an existing, high-quality profile and modifying it downwards. Two factors I considered carefully were frame rate and frame size, because these values dramatically affect the data rate. With a marginal connection, you have to be careful how much data you try to pass through it. Space must remain in the useable bandwidth for the inevitable packet retransmits. My final values were 18 frames per second, at 280 x 206 pixels. I was careful to maintain the original 4:3 aspect ratio of the video, minus the four pixels I cropped from the top. The final stream rate was 262 Kbps, well within what I had been able to achieve when testing inside his house.
A lot of my testing had to take into account the capabilities of Edward's laptop. An older machine, the CPU wasn't powerful enough to decode a 320 x 240 video at 20 fps, for example. Nor could it display the video at full screen without dropping frames. For this reason, you should always try out your video stream on typical target machines.
I initially used the Windows Media 7 codec, but when Windows Media 8 came out the quality was noticeably improved, so I switched. But I also discovered that it took more CPU on both the encode and the decode side. My encoder machine was doing okay, but Edward's laptop started dropping frames. I felt I had compromised frame size enough already, so I reduced the frame rate from 18 to 15 fps, and all was fine.
Windows Media Encoder allows you to monitor the input source it is encoding, the resulting output, or both. You can also set up multiple input sources in case you have multiple cameras, prerecorded videos to show, or if you have title slides you want to present at various times.
Monitoring the Signal Quality
I use two techniques to monitor the signal quality. The first is a simple command window with ping performing a repeated ping of his IP address. The second is a PerfMon (a performance counter used to monitor local or remote system performance) window showing the byte count being transmitted by the network adapter of the broadcast machine. I can watch how much data his Windows Media Player is pulling and see if it's getting into trouble. Wireless LAN is less than perfect, so there are short dropouts from time to time. Luckily, they are usually only a few seconds, and Windows Media Player buffers about 30 seconds ahead, so it typically has a chance to recover the missed data before it's needed and Edward never notices a glitch.
Upgrading to Windows XP
Initially, this whole setup worked just fine on Windows 2000, but it has been even nicer when running Windows XP. Since Windows XP is the ideal digital media platform, I find greater flexibility in using it, and certain things “just work” better. For example, when running Windows 2000, Windows Media Encoder's audio mixer button often brought up the wrong mixer console, and you had to manually change it. Not so under Windows XP. Everything works great. Also, we are now preparing to convert Edward's laptop to Windows XP so we can take advantage of Remote Assistance.
It's useful to have a chat capability between Edward and the broadcast station. We currently use an intranet chat utility, because we've both been standalone machines so far. However, the church just dropped a line from the broadcast station and the WAP to their DSL. So now both computers will have Internet access, and we'll switch to using Windows Messenger as the chat client.
Windows Media Encoder also has the option of archiving the encoded live stream to a WMV file on the local disk, which I do on occasion. It then takes just a few minutes to burn the file onto a CD using the integrated CD burning feature in Windows XP, and give it to someone who missed the service.
Acknowledging the Team
All in all, this project has been a resounding success, and I'm very glad I picked this cat up by its tail. Running this setup every week has been lots of fun. Speaking of fun, I would like to thank Jared, Caleb, Michael, Matthew, and Carl—a great team that takes turns putting on these little productions with me. And of course, we give a special thank you to Edward. I know he's enjoyed seeing the services and getting to learn more about computers in the process, and we've counted it a real privilege to make it available to him, and in some small way, help in his recovery. Get well soon, Edward!
Galan Bridgman is a developer, architect, and enthusiast for digital media technologies. He co-developed QuickTime for Windows for Apple Computer. At Starlight Networks he developed innovative client and backend technologies using ActiveMovie® and NetShow® Server, the precursors to Windows Media Technology. He is a full-time consultant, and is currently developing a next-generation, fully-automated radio station using Microsoft Windows Media 9 Series technologies. After hours he enjoys showing others how to make the most of Microsoft's latest Windows Media applications. Check Galan's Web site for more information about him.
