The days of dedicated video contribution circuits, compressed or not, appear numbered, and Internet Protocol (IP) networks seem destined to take their place. IP boosters have always been a confident lot. With a provocative, Cartesian cry of "IP, therefore I am," they see theirs as the only way to carry everything--voice, data, video--anything short of pizza and Diet Coke. They may be right. But if you set out to build a network for video, you certainly wouldn't pick IP as your first choice.
Cisco Systems is a strong proponent of video-over-IP, and even it acknowledges the challenges the technology faces when it comes to reliable video transport. In a paper presented at IBC2001, the company's Guenter Roeck, Humphrey Liu, and John Horrobin noted that, for such demanding traffic, IP must overcome hurdles in jitter management, packet loss, excessive latency, and the ability to guarantee adequate bandwidth. Add the overhead on an IP network which could eat up 20 to 30 percent of the underlying channel's native bandwidth and IP doesn't sound like an engineer's first pick for the job.
Why then, is IP assuming such an important role in high quality video networking? The short answer is that it's ubiquitous. IP, like VISA, is "everywhere you want to be." It enjoys an economy of scale that dedicated broadcast systems can only dream of, and, therefore, its gear is relatively cheap. It's also an open standard with wide manufacturer support.
Not only can IP networks carry your video, but all your other data (e-mail, accounting, payroll) as well, and most networking engineers, including the ones you probably have in-house, readily speak IP.
Equally important are changes in the way we work. Anything that doesn't absolutely have to be live can now be moved as a file transfer. It's what Jason Mancebo, SGI's manager of Applied Engineering and Technical Marketing for the Telecommunications and Media Division, calls "Distribute Data, View Video." If you don't need to view it while it's being transferred, then you're better off moving it as a data file. And, since file transfer is one of the things IP was originally designed for, most of those drawbacks don't apply.
Mancebo said that video file transfers also avoid multiple code/decode cycles and they're not bound by time. They can be slower than realtime, or faster, and the quality remains the same. File transfers were designed for financial data, among other things, and they insure that every bit gets to the other end unaltered. Since speed has no effect on quality, network choices now hinge on cost and how soon the file needs to arrive. Lower bandwidth equals lower cost and longer transfer time, but it doesn't mean lower quality. You can even use the public Internet, though a private network is usually a better choice.
But what about those occasions when video needs to move in realtime--the remote guest in a live show or a sports backhaul? It would be nice to use the same network for those, too. How do we overcome the challenges noted earlier? To understand what's involved, let's look at what IP and its cousins are and how they work.
How It All Began
Back at the dawn of data networking, circa 1977, it became obvious that something was needed to cope with the computer industry's love of standards (every time you turn around, it's given birth to another one). The International Organization for Standardization came up with a pretty elegant solution that we see reflected in many of today's digital video standards. It's OSI, or Open Systems Interconnection. The original OSI model consisted of a seven-layer stack of protocols. The exact number isn't crucial. What's important is the idea that each layer takes on a small portion of the tasks that must be accomplished for an application on one computer to talk to its equivalent on another. Each layer need only communicate with the layers above and below, and when something new comes along, we only have to replace one or two layers and not reinvent the whole thing.
To use a simple-minded analogy, an upper layer might know how to wrap your glassware for shipment. The next layer down knows how to label it for FedEx and track its progress, and the bottom layer knows how to fly it in and out of Atlanta. At the other end, the process reverses and your package is passed up the stack until it gets to the layer that knows how to unwrap glassware. If your shipment changes from glassware to milking machines, you only need to change the top layer. If FedEx decides to drive your package to Poughkeepsie, only the bottom layer changes.
What Is It? IP is a middle level protocol that knows how to move your stuff through private networks and the Internet. It doesn't care what's in the package it has been handed from above. It only wants to know the destination Internet address. Its only job is to find a route for your stuff and get it to the other end. To do that, it slaps a new label on the package with both send and receive addresses, a checksum to make sure an address doesn't get scrambled in transit, and some information to tell the receiving computer how to respond. It's a common layer that can talk to a variety of different lower layer carriers from the office favorite Ethernet to FireWire and the telco standbys ATM and SONET.
To improve video quality of service (QOS) over IP, system integrators can call on a set of standardized protocols inserted between the upper video layer and IP. The Forward Error Correction protocol (FEC) defines a way of adding error correction bits. A Real-Time Protocol (RTP) provides payload identification, sequence numbering, time-stamping, and delivery monitoring information which can help improve synchronization, jitter performance, and error correction and concealment. The Resource Reservation, Integrated Services, and Differentiated Services protocols (RSVP, IntServ, and DiffServ) provide means of dedicating bandwidth in a mixed traffic network for particular IP streams, such as video.
The list of problem-solving protocols is quite long. Each adds bits to the overhead. At the IBC IP session, Michael Firth of BTexact Technologies explained that a 3:1 ratio of useful data to overhead was typical for large IP networks, which sounds pretty bad. But, he said, "if it's cheap enough, overhead doesn't really matter."
There are times, however, when it does. If the added bits increase latency by boosting processing time, they could interfere with realtime interaction between the studio and remote. Lowell Moulton, engineering manager for Sony BPC's Systems Integration Center, said that a two- or three-second delay is reasonable for applications such as program distribution and centralcasting, but for interactive news and interviews, end-to-end latency needs to be kept well under one second. The IP network may not be the major contributor to latency (MPEG codecs add significant delay), but every millisecond adds up.
Overhead also matters when network capacity is tight. Reed Majors, Minerva Networks' vice president of Marketing and Business Development, said you often "don't have room for QOS when video takes up 99 percent of the pipe." He favors paying careful attention to the network architecture. According to him, Minerva has had good results adding only the FEC layer to IP over private networks with newer routers, guaranteed bandwidth, and low packet loss. In particular, he cites the company's experience with an 80-channel backhaul designed for Hargray Communications in South Carolina.
There are many successful video-over-TV networks, but each case is different and it takes people with an understanding of the demands of both video and data networking to build them.
>For More...
Leitch
www.leitch.com
Minerva Networks
www.minervanetworks.com
Optibase
www.optibase.com
Pinnacle Systems
www.pinnaclesys.com
Sony Broadcast & Professional
www.sony.com/broadcast
Streamrider (2netFX)
www.streamriderinc.com
Telestream
www.telestream.net
VBrick Systems
www.vbrick.com
