Last month's column covered some of the fundamentals of sending real-time video over packetized networks. This month, I will discuss the challenges designers overcame in building video-over-IP transport systems.
Private network vs. public Internet
To better understand the challenges faced in video-over-IP transmission, it's important to know the nature of the network over which the video will be transmitted. One of the most critical questions is whether the video is being sent over a private network or a public network. (See Figure 1.)
Private network
In a private network, traffic is controlled by the user. Traffic is not mixed with traffic from other users, and the user knows how bandwidth is allocated in that network. In some cases, the private network is built from dark fiber, and the only traffic that flows on the network is the user's video. This is an ideal case. More frequently, video traffic is combined with data and voice traffic, even if this is the user's own network built on dark fiber, usually added by your company's IT department.
From a practical standpoint, the IT and telecom guys will want to transport their signals to your dark fiber link. This can help justify the cost of the circuit. If the user mixes different types of traffic over the same fiber, however, adequate traffic engineering must be done on the network to ensure that the video gets through undisturbed.
Local area network vs. wide area network
When considering private networks, it is helpful to understand that in the video transport community, the concept of a private network does not extend into a facility. In other words, someone in the video transport business will probably not think of your internal local area network (LAN) as a private network. This does not mean that you cannot transport video on the LAN within your facility — quite the contrary. In the interest of having good communications with your vendors, you should be aware that the term private network almost always refers to a network outside of your facility.
A wide area network (WAN) covers a large geographical area. It may connect two locations or hundreds of thousands of locations. So a private network is a type of WAN, but not all WANs are private networks.
While we are getting some terminology straight, I should point out that if you start talking to a networking person about your private network, he might think you are referring to a special kind of LAN that uses the private IP address space. (Examples of private IP addresses are 192.168.1.12 and 10.0.0.20.) This has nothing to do with private WAN networks built to carry video over IP.
Public Internet
The public Internet is a type of WAN, and it has become the ubiquitous communications medium of our time. While video over the Internet has improved, it is unlikely that any major broadcaster is going to rely on it alone to carry the backhaul of a major sporting event. The buffer requirements for Internet video transmission are large, resulting in unacceptable delay. Even with these large buffers, disturbances still occur.
Given these issues, that means that the Internet is out for broadcast use except in the most drastic situations where other transmission options are not available, right? Yes and no. The Internet by itself would be a challenging transmission medium for professional video-over-IP applications, but in many cases, the Internet does allow for the transport of video over IP using virtual LAN (VLAN) technology.
In carefully controlled environments where all the routing components are known, VLANs can be configured to provide private transport of data over a public network. If dark fiber is not an option, then your next best bet may be VLAN.
Loss profile
Sometimes it can be confusing talking with service providers and manufacturers. There are a lot of options out there, including whether to have a private or public network, and whether or not to use the Internet with or without VLANs. But in many cases, the discussion boils down to the loss profile of the network and the ability of the user or network provider to control that loss. In short, the IP loss ratio (IPLR), or the ratio of delivered packets to lost packets, differs greatly depending on the transmission technology employed. For example, a typical Internet connection may experience an IPLR of 1×10-3, while the loss ratio on a private network on dark fiber can approach 1x10-14 or more (smaller numbers indicate less loss on the network).
It's important to know how prone your networks are to error, but more information is needed if you want to prevent those errors. It is one thing to design a system to recover for random errors that happen occasionally and in no particular order. It is another thing to design for errors that occur infrequently and last for several seconds at a time.
Transport providers and equipment manufacturers have invested a lot of time collecting data so that they can create loss profiles. These loss profiles are mathematical descriptions of the likelihood of any particular kind of losses and the distribution of those losses. Once engineers understand the nature of the errors, they can design systems to correct for those errors. Clearly the loss profile of the Internet is vastly different from the loss profile of a dark fiber point-to-point circuit.
Challenges in video-over-IP transmission
As you can imagine, there are challenges in delivering streaming video over IP networks. One challenge is interoperability.
If you're designing a system that transports video over IP within a single company from one point to another, then interoperability is a nonissue. You decide on the video standards, compression standards, forward error correction (FEC) method and Internet standards.
On the other hand, if you are working with a system that transports video between different entities, or even within different branches of the same entity that use different corporate standards, then you may face some challenges. Of course, the issue of interoperability is not new for broadcast engineers, but video over IP adds a few new parameters:
- Video standards If you are sending a type of video that is not supported by the receiving equipment, then obviously the system will not work.
- Compression standards As with video standards, it's not a good idea to use incompatible compression standards between the sender and the receiver. Feeding MPEG4 into an MPEG-2 decoder will not achieve acceptable results. Achieving interoperability across different MPEG2 systems — while much better than in the past — may occasionally cause problems. If you are building one of these systems, be sure to test compatibility between differing encoder and decoder combinations.
- FEC standards Recently, SMPTE produced a standard (SMPTE 2022) for the use of FEC over packetized networks. The DVB has also done some work in describing FEC methods. It is important to use standardized FEC if you want to ensure that error correction capabilities function correctly when interoperating between different equipment manufacturers.
- Internet standards SMPTE 2022 describes a standardized way of mapping MPEG-2 transport streams onto IP. Of course, if the sender and receiver use different IP transmission schemes, then interoperability issues will result.
Overall, the good news is that standards exist to resolve these interoperability issues. Manufacturers and service providers are working together to ensure that video-over-IP installations go smoothly. Many events you watch on television today have been transported over packetized networks, so if someone approaches you about transporting video using packetized networks, you should know that it can be done with high-quality results.
Brad Gilmer is president of Gilmer & Associates, executive director of the Advanced Media Workflow Association and executive director of the Video Services Forum.
Send questions and comments to: brad.gilmer@penton.com
