Digital video testing can be a tricky business
Finding problems in video before viewers do has always been the testing and monitoring challenge. If viewers see a problem in the video you’ve sent them, it’s too late; you’ve lost.
Testing and monitoring became immediately more complicated when video began being translated into the digital domain, in good part because digital video is almost always compressed.
It is possible to make sure that MPEG-2 packets are coded correctly, and companies such as JDSU and Tektronix sell testers and analyzers that can check MPEG-2 packets for compliance to standards, as well as analyze streams of MPEG-2 data. Companies like Ixia make monitoring software. Companies like JDSU, Tek and Symmetricom make probes that can be used to monitor MPEG-2 traffic.
MPEG-2 compression has been used for years and is entirely familiar, but for all of the industry’s cumulative experience with it, it’s still a complex technology, and things can still go wrong, which is why companies still have to test and monitor their MPEG-2 video streams.
Andrew Sachs is director of IPTV strategy for service assurance solutions at JDSU. He recalled looking at one MPEG-2 based system where the timing measurements were off. “It had 192 nanoseconds of jitter on it, which was fine from the specifications’ standpoint. But working with that particular set-top box? It would glitch the screen. Those are the kind of anomalies you have to look for,” he said.
Compounding the problem is that the network operator is not always the source of the video. The content a network operator’s customer is viewing might come from any one of the growing number of Internet-based sources, legal and illicit.
In an MPLS (multiprotocol label switching) network – a packet-based network made to behave in many ways like a circuit-switched network – a packet may go through five, eight, 10 hops or more through various pieces of network equipment. And every one of those hops is an opportunity for something to go wrong with a packet, or for a packet to be lost outright.
It simply isn’t practical to evaluate every individual MPEG packet at all points in a network. So the idea is to set probes – some that are capable of doing analysis – at only a few key points in the network.
If something goes wrong, you know the problem is somewhere between the point where the error was identified, and the last point where the data was known to have been still good. Then you go in with more probes and analyzers to pinpoint the problem.
The difficulty of testing digital video is exacerbated, however, when the content is being shipped using transport protocols that weren’t formulated for video. Did someone mention Internet Protocol?
In the communications industry, IP is now entirely common, for decades as the basis for data services, and more recently for voice-over-IP telephony. That familiarity may be lulling some into a false sense of security when they go to add video to the mix, however.
“The inclination is to look at video as just another packet,” said Jon Hammarstrom, senior manager, video field marketing at Tektronix. “It’s not the same, though. Service providers have to come to terms with that issue. Sufficient bandwidth is required.”
Hammarstrom’s point of reference is IPTV delivered on what are essentially telephone networks, but it could apply to transporting IP video over the DOCSIS channel in a cable network as well.
A problem with IP for video is that there was never any expectation that an IP network would deliver every single packet of information reliably; IP networks are well-known to be best-effort networks.
If the device that is receiving data is missing packets, it might be able to compensate, and if not, it just sends back a request for duplicates of the missing packets and waits for those packets to show up. That might take milliseconds.
That’s okay for a PC downloading a Web page. It’s even okay for a phone call. It really, really doesn’t work for video, though. For video, the packets have to be there, all together, on time. A single missing or delayed packet will have an effect that ranges from noticeable to disastrous, depending on the nature of the payload.
“Video does not survive on a best-effort network,” Hammarstrom said.
There are any number of things that can affect the quality of video in an IP network. Sachs said, “I have a product that tests over 165 parameters, but it all comes down to packet loss, jitter and bandwidth.”
That is to say, the packets have to be there, and they have to be there on time, and that’s all predicated on having a big enough pipe…that doesn’t have a lot of jitter…or lose packets.
The point is, those three factors affect each other. The lack of adequate bandwidth is a factor in losing packets. Standard definition MPEG-2 video might require about 3.75 Mbps. HD MPEG-2 might require as much as 12 to 15 Mbps.
Unless a network is carefully set to deliver packetized video in a steady stream, at a constant bit rate, problems can ensue. Set-top boxes have no tolerance for groups of packets arriving erratically, in bursts. “Bursty” delivery just doesn’t cut it for video.
Thus, having quality of service (QoS) controls, including clear network policy and mechanisms to enforce it, in a sense becomes part of the monitoring function – the operator has to monitor to make sure adequate bandwidth is allocated and video traffic flows smoothly. QoS is especially important in networks marked by bandwidth limits.
Jitter is a catch-all term for timing variations in the network. A network with enough inherent jitter will end up dropping and delaying packets. A network with low jitter might still have problems, as evidenced by Sachs’ anecdote above.
In an IPTV network, the operator has to assure that the path is good, that the appropriate amount of bandwidth is available.
Then the operator has to assure the integrity of the video itself, all the way through the network. There are a growing number of points along the network where some piece of equipment or another handles the video stream.
There are the obvious places within the network: encoders, multiplexers and at the headend. But other places to watch include RF downlinks, from satellite or terrestrial sources, and storage areas, notably VOD servers.
Probes can profitably be placed at many of these locations, typically at the output points from the headend, encoder and multiplexer, and perhaps at ingress points with satellite downlinks and terrestrial inputs.
With IPTV, “the complexity of the system is an issue. There are so many moving parts to deliver it effectively. If you look at a cable plant, it’s pretty darn simple; it works,” Sachs said. The complexity of a strict-definition IPTV system (such as AT&T’s), on the other hand, “is a big deal. It really is.”