Monitoring technology
The TV industry has made a major transition from analog to digital. Systems monitoring has undergone a similar transition and has become significantly more important for successful operations. In the analog monitoring model, simply watching video and audio on a monitor qualified as a sufficient monitoring strategy. If problems were evident on-screen, it was easy for the engineer to correlate the symptom with a cause. With DTV, however, that clear understanding of cause and effect has vanished.
Now, as broadcasters send data through computers and use software programs to calculate TV signals, they face a much more complex challenge in ensuring the quality of their output. Because different receivers rely on different versions of software to process the DTV signal, a single issue in the stream may result in a variety of behaviors. In other words, the receiver doesn't work as a monitoring tool; more sophisticated monitoring technologies are required.
In the digital realm, any given symptom can come about through any number of sources. Tiling, packet loss, continuity errors, program clock reference (PCR) issues, problems with the timeline and buffer issues are among the many symptoms that might arise, and none of these form one particular problem. Given the new complexity of managing DTV signals, it is imperative that broadcasters have the tools and technology to understand what's going on in transport streams, be able to locate the problem and then isolate the system that caused it.
Monitoring compressed media content
Only by looking at all aspects of the MPEG transport stream, or compressed media content, can broadcasters ensure that they are both meeting industry standards for DTV delivery and providing their customers with a high QoS. A comparison of transport stream elements and parameters against industry standards can enable identification of noncompliance or other issues; however, without a sophisticated means of applying industry standards, broadcasters can be overwhelmed by the volume of stream errors identified.
It is the nature of DTV that there is virtually always something technically wrong with the transport stream. While broadcast devices can introduce error, the standards themselves often come into conflict and cause errors, or “collisions.” A classic example of this phenomenon occurs when the program association table (PAT) must appear at set time intervals and the PCR must appear in every video frame. The multiplexer combining these different streams of packets into one continuous stream is often forced to choose which rule to follow. Because the PCR is more important, the multiplexer will always choose to delay the PAT. While this situation technically creates an error and a change to the PAT that may alter channel tuning time, the overall impact is imperceptible to the viewer. The engineer doesn't need to be alerted each time this issue occurs.
Sophisticated monitoring technologies leverage the A/78 and SCTE-142 recommended practices to identify and prioritize transport stream errors and, by placing the focus of monitoring on nontrivial errors, simplify the work of engineers in managing DTV service quality. With the ability to recognize noncompliance in real time and filter specific errors, broadcasters can be sure that they are informed immediately of serious problems, while less serious issues are logged for later investigation.
Get the TV Tech Newsletter
The professional video industry's #1 source for news, trends and product and tech information. Sign up below.
A/78 and SCTE-142 outline seven categories of transport stream error types: PSI errors, out-of-band table errors, in-band table errors, PSIP errors, timing and buffer errors, consistency errors, and general errors. To each of these, the standards apply five levels of severity: transport stream off-air (TOA), program off-air (POA), component missing (CM), QoS and technically nonconformant (TNC). With errors differentiated first by their impact on the viewer experience, engineers can be proactive in addressing transport stream issues — and the root causes — that most directly threaten customer satisfaction. These filtering concepts allow rules-based monitoring systems to be particularly effective in allowing operators to maintain their quality objectives. (See Table 1.)
Measuring internal and external streams
While monitoring within the broadcast plant tends to be more straightforward than across a cable operation, there are several different points in the transmission chain to which broadcasters should pay attention. The proper location of monitoring systems helps engineers localize impairments and quickly move on to troubleshooting and resolution of the underlying problem.
Though the ideal solution would involve the placement of monitoring systems “behind” every device that manipulates, modifies or otherwise processes the transport stream, in reality, the installation of monitoring systems at all points that impact the digital signal is not a feasible option for most broadcasters. Instead, they can position monitoring equipment strategically, and even implement portable systems, to uncover stream impairments at critical points in the broadcast plant. Real-time monitoring of the MPEG layer across these points offers the engineer a means of identifying suspect transport streams and narrowing the problem area. A comparison of streams from locations across the facility thus helps to isolate the device that introduced the error. Monitoring systems with integrated logging and trend analysis tools provide a broader and deeper look at transport stream issues, and this capability can be critical in identifying and resolving recurring problems.
The internal monitoring of transport streams ensures that over-the-air broadcast viewers are receiving compliant DTV signals, but effective monitoring of streams carried by a cable provider or other downstream infrastructure also is critical to successful carriage agreements. Regardless of how they receive a particular channel, audiences often associate video and audio quality with the program, channel or network they're watching rather than with the service provider.
The ability to automatically compare transport streams at different locations (DTV carriage auditing) allows a broadcaster to determine if impairments are introduced by a downstream system. (See Figure 1 on page 6.) Broadcasters invest heavily to produce high-quality programming, increasingly in HD. When that content leaves the broadcast plant, it is subject to the decisions made and devices used by the downstream operator. Placement of a stream monitoring system on the multiplexer output can enable comparison with the QAM output from the cable headend, for example, and in turn allow measurement of the QoS being provided. From the cable operator's perspective, the ability to validate MPEG transport characteristics and the presence of accurate PSIP metadata within the incoming stream also ensures that it can be carried successfully through the cable plant.
Maintaining quality and competitiveness
Effective monitoring of DTV streams according to current industry standards is vital to the broadcaster's ability to provide continuous, consistent QoS. With properly positioned monitoring solutions that are sufficiently sophisticated to identify and report transport stream issues according to these standards, engineers in the broadcast plant can be efficient and effective in maintaining stream quality and, in turn, preventing viewer complaints.
A/78 and SCTE-142 provide a framework that advanced monitoring systems can use to ensure this quality. Broadcasters who implement these technologies stand to gain both a competitive edge and peace of mind.
Rich Chernock is chief technology officer at Triveni Digital.
Error condition Error qualifier TOA POA CM QoS TNC PAT repetition error PAT repetition interval error (found between the last 101ms and 200ms) X PAT repetition error PAT repetition interval error (found between the last 201ms and 500ms) X X PAT absence error PAT not found for 501ms (or longer) X X X X X PAT syntax error Packet with PID 0×0000 doesn't have table_id 0×00 X X X X X
Table 1. Examples of A/78 PAT error conditions