MPEG monitoring
May 1, 2007 12:00 PM, BY JON HAMMARSTROM
MONITORING MPEG monitoring BY JON HAMMARSTROM Broadcasters are increasingly having to monitor not video but data streams. They can accomplish this with the Tektronix MTM400, for example, which provides real-time monitoring of an MPEG transport stream at data rates up to 155Mb/s.
The secret of maintaining reliable, high-quality services over the different digital television transmission systems is to focus on those critical factors that may compromise the integrity of the system. The key is to monitor the right critical parameters with cost-effective test equipment at the right place.
Operators should also strive to detect problems ahead of critical times in order to allow a cost-effective resolution before it becomes an urgent issue to the engineering staff or the viewer. This may mean real-time monitoring with alarms, but it also could involve recording an offending MPEG stream at critical points and analyzing it offline — perhaps many miles away — to get to the root of the problem.
Today a compressed video distribution system may include digital servers for video on demand, carousel and interactive services, and a degree of IP infrastructure. All of these outputs end up on GigE or ATM networks, from which the transmitters draw their stream feed for broadcast. There may also be backhaul and backchannel systems, with some signals and controls even feeding back to the original source servers.
Monitoring equipment, therefore, can be positioned anywhere, even in RF paths. And it must be capable of returning analysis data — and even stream samples themselves — over these intranet/network-type return paths.
Figure 1. Broad and deep testing
scenarios
Click image to enlarge.
In large multichannel environments, operators may require a cost-effective RF and IP monitoring solution with wide monitoring of critical MPEG parameters and deep MPEG analysis of a single program or channel. This supports rapid fault resolution by expanding the monitoring coverage of time-sampled RF channels or IP streams, with the ability to drill down through the RF/IP layer to analyze the MPEG layer in depth.
An MPEG monitor capable of sequential sampling of multiple streams can provide simultaneous monitoring of up to 500 IP sessions for critical MPEG transport stream errors (e.g. sync and continuity count), IP errors (e.g. lost and out-of-order Real-time Transfer Protocol, or RTP, packets and packet CRC errors) and packet arrival interval limit testing. Transport stream error testing should be undertaken at the packet ID (PID) level and support both multi-program transport streams (MPTS) and single-program transport streams (SPTS). (See Figure 1.)
A seamless linkage can exist between IP, RF and MPEG layers when a consistent error log with common time stamps is provided. It must also allow network operators to quickly isolate faults to the RF, IP or MPEG layer.
Critical measurements and strategy
Figure 2. MPEG layer summary
screen
Click image to enlarge.
On the MPEG side, there is a vast range of measurements available from monitoring equipment and analyzers. It is important that the test equipment provides a summary screen that can give an at-a-glance view of the most critical and important measurements to focus on. Figure 2 on page 83 shows a moving pie chart of the multiplex occupancy. This enables users to quickly see if a stream is live and decoding. The bit rates and program and service names are important but not critical.
Some monitors and analyzers can be configured to trigger a stream recording to pin down difficult problems. Recording triggers can be assigned to any of the tests, with a pre-trigger buffer to see what led up to the problem. Error logs can help track the frequency and occurrence of the fault condition.
Note the alarm indicators at the base of the summary screen also show the seriousness of the error. ETSI's DVB standard TR 101 290 assists here, grading the stream errors into three priorities:
- Priority 1
These errors prevent decodability. They are either packet header errors, such as sync byte or continuity count (which indicate dropped packets), or program mapping errors, such as program allocation table (PAT), program map table (PMT) or missing stream PIDs. - Priority 2
These errors impair decodability and might cause artifacts in the decoded picture or intermittent decoding - Priority 3
These errors indicate a problem at the encoder or multiplexer but do not affect decodability (e.g. table errors that affect the electronic program guide).
Figure 3. PCR inaccuracy created
by faulty encoder
Click image to enlarge.
Summary screens that can be configured for custom error classification allow users to select particular tests that may be especially critical to their facility. These might be special PIDs involved in conditional access, without which viewers can see nothing. Summary screens can add significantly to efficiencies of both the technical and operations teams.
blog comments powered by Disqus
| Want to use this article? Click here for options! |  |
