JOHNSTON, IOWA At Iowa Public Television, we are committed to using digital technology to improve workflow as well as deal with the challenges of creating content that will be delivered to a variety of end users and devices through a multitude of mechanisms. We are just completing the conversion of our studio origination facilities from analog to high-definition digital. To that end, we are evaluating ways of making content that can span delivery systems. One that I have really just started investigating is video over IP.
What does video over IP really mean? In most applications of video over IP we are talking about streaming content to the end users. Internet Protocol (IP) is used for sending data over a packet-switched network like the Internet typically using the transmission control protocol (TCP), thus the term TCP/IP or TCP over IP. Video, on the other hand is the visual part of television—or the images on a visual display—and isn't really required to be digital; but anything sent over an IP network has to be digital. So when we're talking about video over IP we really mean sending extraordinarily large data files that contain video and audio content over IP and typically some variation of the real-time transport protocol (RTP) being used.
A DIFFERENT DYNAMIC
One of the basic challenges faced when sending video/audio data files over an IP network is overcoming some of the basic limitations of IP networks themselves. Even the best designed IP networks deal with packet loss, network delays, network latency and congestion. In the non-real time data delivery work that these networks were originally designed to enable, all of these problems impacted the network performance but the nature of the data being transported was more tolerant to delayed or missed deliveries. Files being transported were typically small and if packets arrived out of order or needed to be resent in order to recreate the total file, the problem was manageable. Who cares if it takes a half a second longer for the spreadsheet to open?
Video/audio data files create a very different dynamic. Even simple video files are huge when compared to the data files that the IP networks were originally designed to handle, so the time required to transport a complete file is extremely long. Add to the mix the desire to deliver higher resolution long-form content such as high-definition feature films and the files get even more enormous. Couple into this the expectation from the end user that the content will be available instantly and in real time and the challenges are even further exacerbated.
istockphoto/Olaf Loose As we transform the image and audio content into digital files we can take advantage of some of the tools to help alleviate the challenges. Compression technologies provide methods for reducing file size by eliminating repetitive data. IP networks work based on packetized data so that the files are broken into small packages and the packages are shipped independently and then reassembled at the other end into the complete file. Working with small parts of the file allows the use of techniques like forward error correction to help overcome problems like packet loss.
Other IP network limitations like latency and congestion require additional correction techniques like the use of RTP control protocol. RTCP is, in essence, a separate data connection between the content origination and reception points that provides both devices with a methodology for monitoring the quality of service on the path between the two devices. This provides near real-time feedback so that adjustments can be made to help dynamically improve the real-time delivery of the content. Most systems also employ some buffering of the data to also deal with limitations inherent in shared packet switched networks.
However, there is no free lunch in all of this. All of the technologies that are employed to force the packet switched network perform in ways that it was not originally designed have a corresponding cost. Compression, buffering and the like add delay and impact the quality of the content passing through the system and introducing them add another level of complexity that must be properly managed.
SET REALISTIC GOALS
So what's an engineer to do? Well the first thing that I suggest is to take a long hard look at what the end goal is and then evaluate the capabilities and appropriateness of the technologies that are vying for implementation. One of my largest frustrations with most things digital is that products tend to be oversold or under developed depending on your point of view. Regardless, what tend to be delivered are systems that need a significant amount of tweaking and adjustment just to perform the basic functions that were required. Don't get lost in the visionary future of the product at the expense of the present requirements. I have seen a number of systems that show great promise for video over IP applications that are still unstable at the base level functions.
My second suggestion is to never commit to a system without first seeing it in operation at several other independent facilities. Go to the facilities using the system and talk with the people actually working with it. I have passed on a number of applications after seeing them in operation at other facilities and realized that the technology may not be bad but it may not be the right technology for the job. Don't fall in to the thinking that any one tool is appropriate for every application. We all know that one size does not fit all.
My third recommendation—and this one comes from several very painful first-hand experiences—is to avoid implementing any new or cutting edge technology in mission-critical areas. Whereas this used to be very challenging in the good old days of non-digital proprietary hardware systems, it can rapidly become a nightmare in the software-driven digital systems of today. You discover that software manufacturers are as jealous in the protection of their intellectual property as any movie maker and the levels of communication that have to take place in order to track down and correct problems may never happen in the Moore's-law-driven product life cycle that vendors operate under.
Finally, count the costs associated with any system prior to commitment. Include the purchase price and ongoing maintenance contracts and don't forget to look at the underlying support systems. One of the downsides to digital systems is that they are manufactured and sold by companies with a commodity-driven economic plan. That means that the vendors' futures rely on the buyers' continued ongoing purchase of support and upgrades to the systems. Depending on your budget and the economic outlook for your organization, it is very easy to build an infrastructure that your revenue stream cannot support. Making good strategic decisions rather than employing the latest and coolest technology is probably the best way to ensure the future of your organization and yourself.
Bill Hayes is director of engineering for Iowa Public Television.
