Networking video
Mar 1, 2009 12:00 PM, By Brad Gilmer
When moving professional video over networks, consider these defining characteristics: large amounts of data; sensitivity to errors and loss; sensitivity to delay; the efficiency multicast issue; and maintenance personnel mind-set.
Large amounts of data
One of the defining issues concerning the use of networking technology for professional video is that it involves moving huge amounts of data. How much data? (See Table 1, bottom of next page.)
Of course, these are uncompressed rates; modern compression techniques can dramatically reduce the required bandwidth. But even at 100:1 compression, a two-hour movie at 525/29 represents a file size of about 2.4GB. If you transfer this file over a single 100Base-T network that has a policy to use only 70 percent of network capacity, it will take more than 30 seconds to transfer one file. And this one transfer takes up virtually all of the available space on the network for that entire time.
There are ways to reduce the impact of video on the network, but they all amount to the same thing — an increase in network capacity. Gigabit Ethernet (GigE) is becoming ubiquitous, so the transfer that took more than 30 seconds on your old 100Base-T network will only take three seconds on a GigE network; and 10GigE is on the horizon. Also, it is possible to bond multiple Ethernet connections into a single virtual connection. This allows you to combine several GigE connections together, which is not practical for workstation connections, but it is a reasonable option for connections between backbone switches or between a switch and a large server.
Sensitivity to errors and loss
Professional video users are sensitive to errors and loss during file transfer. If you use conventional FTP to move video files and the transfer fails somewhere in the middle, you will have to start over. Some FTP clients can resume a file transfer at the point where the transfer failed. But if you are moving files larger than 2GB, or if you move large files on a regular basis, investigate special software packages and protocols that will accelerate these transfers far beyond what conventional FTP can deliver.
Broadcasters are sensitive to problems during the file transfer, but go ballistic when errors are incurred during live transmission. There are several reasons for this.
First, assuming that the transmission is going out on the air, errors are visible to end viewers, and there is no opportunity to fix the problem in post. Second, depending on where the error hits and on the technology in the encoder/decoder chain, loss of a single packet can produce a series of errors that could last for more than one second. Things do not look any better when considering that IP networks were designed to lose packets when the going gets rough.
You can do things to help with live transmission of professional video over IP. Generally, these fall into two categories. First, try to prevent errors before they occur. Second, protect against errors after the fact.
To do the first, ensure that the internal plant is configured properly so networks that move video prioritize that traffic above other services. Or build separate networks dedicated to only moving video traffic. When working with wide area networks (WANs), make sure quality of service (QoS) agreements are in place so video arrives intact.
To protect against errors after the fact, add forward error correction (FEC), which allows users (up to a limit) to reconstruct missing information using extra bits sent as part of the transmission. Of course, nothing is free, and FEC will deduct from the total bandwidth available for video transmission. Furthermore, typically, the more FEC introduced in a circuit, the longer the latency — the time between when video enters one end of the link and when it exits the transmission system at the far end. In live interview situations, large amounts of latency are unacceptable.
Sensitivity to delay
In some cases, such as a live interview, delay can be a bad thing. Fortunately, most on-air talent and home viewers are used to dealing with satellite delay. As long as broadcasters stay within the limits of what someone would normally encounter in this environment, it's okay.
But long-distance IP networks have another interesting characteristic that could prove extremely disturbing. Unless a large IP network has been engineered to control this problem, the delay can change from one moment to the next depending on which route packets take from a sender to a receiver. If the route is constantly changing over the network, a problem known as route flap, the delay experienced over the network will constantly change. Proper engineering of the network will help avoid this situation, but note that human beings hate nonconstant delay when trying to communicate.
| Want to use this article? Click here for options! |  |
