MPEG monitoring

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.

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

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).

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.

Are PCR measurements critical?

A program clock reference (PCR) enables the MPEG decoder to synchronize to the encoder. The system time clock is locked to the stream PCRs. A 42-bit sample of the sine-wave of the system time clock at the encoder indicates to the demultiplexer what the clock's time should be at the decoder when each clock reference is received. Synchronization errors arise if the PCR value generated by the multiplexer is inaccurate, or if it is received late because of network delays, such as jitter.

The STC is used to create color burst and syncs. It is the reference for audio and video decoding and presentation time stamps. Jitter and inaccuracy errors can lead to decoder errors.

PCR errors originate from faulty encoder PCR circuitry, faulty remultiplexer PCR circuitry or failure to seamlessly loop a transport file. PCR jitter can come from an unstable RF demodulator, unstable fiber demultiplexer, ATM network packet jitter or the way MPEG is packetized in IP networks. The buffers in set-top boxes should cope and smooth this, but there may be problems, particularly with large PCR spikes. Figure 3 shows evidence of a faulty encoder.

Modern H.264 systems (as in IPTV) may not strictly need PCR, but encoders allow it to be generated, as it is a good indicator of timing integrity (and jitter) of the IP pathway delivery system. Much test equipment has built-in alarms for limit violation to flag the errors, so operators are making sure that PCR is present in its output.

Ensuring that the contents of the transport stream are correct requires the monitoring equipment to have prior knowledge of what broadcasters plan to transmit. One method of achieving this is to enable the broadcaster to identify a small number of key parameters that can be used to verify the contents of the transport stream. These parameters form a service plan, or template, in which the operator enters the values that are expected to be present in the transport stream. The monitoring equipment extracts the actual values from the transport stream and compares them against the template, indicating when a discrepancy occurs.

Plans may vary according to the region and DTV standard. For example, service descriptor table is just one example for DVB, and there are other and similar service information tables for ATSC or Japanese ISDB services.

Figure 4 shows an example template screen. Note that a single simple alarm template error on the summary screen will guide operators to this display, where it is possible to drill down and trace the fault in the transmission. In this case, an incorrect stream type is easily found in the service.

Monitoring equipment also should have the ability to change templates automatically at scheduled times — for example, when service plans change over on regional news insertion. Broadcasters may be asked to verify that local content has been inserted correctly and on time. This can be dealt with by templates as shown here. Legal service level agreements may involve tracking delivery of packets over time to indicate bandwidth delivered.

Most test equipment has error logs. These can make tracking of intermittent errors easier because broadcasters can detect time, date and nature of errors. Error filtering can help because broadcasters can restrict the type of errors logged to just the critical ones, or broadcasters may want to know all the errors, but just highlight and color code the critical ones they are worried about. (See Figure 5.)


There are basic critical tests that are common across most DTV systems. These are graded into three priorities by ETSI TR 101 290. Monitoring equipment and analyzers should support all three of levels of prioritization and prominently display results in a summary screen.

There are additional tests that, for certain operators, may be most critical to their particular business. For example, cable operators may want to focus on modulation error ratio (MER), but once operators know it's within spec, they will exit the RF layer test menu. Thereafter, they may want to ensure their bit rates are maintained, and appropriate services are being delivered during a given time period. So the template and bit-rate alarms may be their prime concern.

Test equipment that provides alarms and a configurable user interface can contribute significantly to improved operational efficiency. (See Figure 6.) Polling can provide a cost-effective method to achieve broad MPEG, RF or IP measurements and deep MPEG protocol compliance testing across hundreds of channels.

Jon Hammarstrom is senior video marketing manager for Tektronix.