Latency deviation is the single largest problem with transmitting video. Latency in itself is not an issue; most decoders don't care if the packets are taking 5 or 500 milliseconds to reach their destination, since the actual transport is usually UDP (User Datagram Protocol). Decoders do care about a deviation in this value. If your video traffic has to compete with other data traffic and has even as much as a 5 ms difference between the fastest and slowest responses, the decoder will begin to drop frames or blocks of pixels. A large decoder buffer can hold more data and therefore can wait a little longer for packets. A smaller buffer can't wait as long, since the packet is being decoded and thrown up to the screen almost as fast as it comes in.
The size of the decoder buffer can also determine video quality if packets become reordered on your network. Data systems can deal with out-of-order packets most of the time; they simply wait until they have all the pieces before reassembly. Video decoders don't have this luxury. The video data needs all the pieces to be there on time if they are to be reassembled and displayed at the correct time. If all the parts aren't there, there will be missing pixels or missing frames until the decoder can get caught up and begin displaying again. A larger buffer again allows a longer wait time for all the packets to arrive before decoding and displaying them.
And Don't Even Think About Using Ethernet Hubs
Both these problems are seen most often in Ethernet networks where one stream of traffic can interfere with another, so special care needs to be taken in these instances. If you are planning to run high-quality video over a hub-based Ethernet network, we have one word of advice: Don't.
Use your Ethernet hubs as doorstops, booster chairs or coffee tables, but don't use them in your video network. Instead, replace all your hubs with Ethernet switches that support VLANs to separate traffic between groups of computers. This will help to contain the traffic between the origin and destinations only, without flooding the network with traffic intended for just a few.
If you run a routed Ethernet network and intend to multicast your video, all the routers in the video's path should support IGMP (Internet Group Management Protocol). If you are performing a point-to-point transmission, IGMP is not needed. Your multicast transmissions will need IGMP to distribute the video to the intended destinations on the least-cost routes without duplication. (For more on multicast and IGMP, see "The Wizardry of Multicast", February 19, 2001.)
If you are traversing a frame relay and ATM network, your video should suffer less if the network is configured properly. Since both frame relay and ATM are circuit-switched networks, which build PVCs (permanent virtual circuits) or SVCs (switched virtual circuits) between endpoints, your video stream should have its own circuit. Mixing video with other data on the same PVC or SVC is a bad idea and is really no better than running over a hub-based Ethernet network.
On an ATM network, the CoS (class of service) can be important to the quality of your video. To do it right, CBR (constant bit rate) is the way to go. This guarantees your video a constant bandwidth. A less expensive option would be to use VBR (variable bit rate) to carry your video data. If your ATM network is well-behaved and not overburdened with traffic, a VBR connection can work as well as CBR connection.
SVCs make the most sense if your network switches support them and your video use will be intermittent. The bandwidth is used only when it is needed and torn down when not. If SVCs are not supported on your frame relay or ATM network and you have to place the video on a PVC, a separate PVC is the way go.
Regardless of the network type--ATM, Ethernet or frame relay--the bandwidth given to the broadcast is important. No matter how well tuned and behaved your network is, without the bandwidth, your video will break up into little digital chunks. The only way to guarantee your audience the best possible image is to purchase more bandwidth than you will ever need.
Digitized and encoded video can be transmitted at a range of bandwidths. Low quality can get by at 1 Mbps, while best video quality can run as high as 6 Mbps. Uncompressed video can cost your network a hefty 13 to 15 Mbps. A good center is 3.5 Mbps: The quality is good enough for most uses outside of television broadcasts. Three Mbps seems low enough to work over 10-Mbps Ethernet connections, but with all the other traffic on your network this probably won't work. If you're delivering full-screen, full-motion video to the desktop, 100-Mbps links are a must.
When transmitting video over a WAN, you need to create a PVC with proper sustained and burst rates. If you have the time, you should conduct network tests by broadcasting video as close to your needs as possible. By monitoring the bandwidth usage during transmission, you can find out just what your PVC sustained rate will be. You can also find out how much burst bandwidth you'll need. If you are broadcasting MPEG-1 video this is immaterial, since it is encoded at a constant rate.
Darrin Woods is a technology editor of Network Computing. Prior to joining the magazine, Darrin worked as a WAN engineer for a telecom carrier. Send your comments on this article to him at dwoods@nwc.com.
RSS
