Broadcasters, MPEG Troubleshooting and the 2009 Switchover

Broadcasters, MPEG Troubleshooting and the 2009 Switchover

Broadcasters, MPEG Troubleshooting and the 2009 Switchover Broadcasters, MPEG Troubleshooting And the 2009 Switchover 1 Broadcasters, MPEG Troubleshooting and the 2009 Switchover Scope............................................................................................................................... 3 MPEG Monitoring and Analysis .................................................................................... 4 Monitoring Points in the Broadcast Chain.................................................................. 4 Monitoring Rules ........................................................................................................ 5 MPEG Analyzers ........................................................................................................ 8 Using an MPEG Monitor as an input to an Analyzer ................................................. 9 Conclusion ................................................................................................................ 10 2 Broadcasters, MPEG Troubleshooting and the 2009 Switchover Scope Until now, the digital broadcast signal has been a second priority for many broadcasters. This is about to change. On February 17th, 2009 the FCC will require that broadcasters switch off their analog signal, and rely solely on their digital signal. It is important for broadcasters to prepare their studios for February 17th. After this date, a drop in the digital signal means that a station is off the air. One good way to avoid outages is to plan for such contingencies now, while there is still time to budget changes to the digital transmission chain that will ensure it is as reliable and easy to troubleshoot as possible. Audio/Video Station to Encode Transmitter Multiplexer PSIP/ Metadata insertion Figure 1 A Simplified digital Broadcast Chain One of the significant differences between analog television and digital television is quality assurance. Analog networks require a completely different toolset for isolating and resolving network faults. In many cases, the best tool for diagnosing an analog video problem is a video monitor and a test pattern. For analog video, it is usually safe to assume that an underlying signal issue will have similar impact on different television sets. Television sets are not appropriate tools for monitoring digital video because devices that convert digital, compressed, video into pictures rely heavily on software. The specific implementation of the software running on a TV or a set top box directly affects how it reacts to an underlying standards violation in the incoming digital transport stream. If the incoming signal is not compliant, the viewer experience will vary depending on what kind of set top box they are using and the software/firmware built into that box. Therefore, broadcasters who use a specific brand of set top box to monitor their on air signal may not see the same set of problems that their viewers see. However, set top box and television manufactures build their products to obey standards set by the ATSC (American Television Systems Committee) and MPEG (Motion Pictures Experts Group). If the signal leaving the transmitter is compliant with all of these standards, all properly functioning set top boxes will be able to decode that signal. The tools of choice for standards conformance testing are MPEG analyzers and MPEG monitors. When deployed in the broadcast network they can greatly reduce fault detection and isolation times. However, properly configured, they can do more. Broadcast streams can be compliant with standards but still not meet the intent of the studio generating them. For example, suppose a broadcaster has three virtual channels in his digital stream. Suppose one of these virtual channels gets blocked in the multiplexer. An MPEG monitor can validate the transport stream 3 Broadcasters, MPEG Troubleshooting and the 2009 Switchover according to a baseline, or according to the configuration settings of other devices in the system. Such a monitor would notice the absence of a missing stream and alert station personnel. MPEG Monitoring and Analysis Broadcast engineers are responsible for restoring service in the case of an outage on a broadcast network. The effectiveness of this effort can be measured by two metrics. First is fault detection time, or the length of time between when the fault occurs, and the time when engineers notice that something is wrong. Second is fault isolation time. Fault isolation time is the time required to identify the root cause of a fault and fix it. The roll of the MPEG monitor is to reduce fault detection time. It is designed to examine an MPEG Transport Stream and take certain actions when faults are detected. These actions vary based on the particular application. Some examples of actions taken by monitors include generating SNMP traps, sending E-mail, sending SMS messages (to a pager or cell phone), recording the transport stream, or generating a report for later trend analysis. Typically, MPEG monitors do not have extensive user interfaces to help with troubleshooting. Such user interfaces are the domain of the MPEG Analyzer (see below). There are two main concerns when evaluating an MPEG monitor: 1) What are the best monitor points in the system? 2) What rules will it use to identify system faults? Monitoring Points in the Broadcast Chain The most important point to monitor in a broadcast network are the last step in the chain. Usually this means taking 8VSB input from off air. The monitor sees exactly the same signal as the viewer, and will react to changes in the signal which might prevent decode by the viewer. If the broadcaster in question is sending digital feeds to cable companies (for retransmissions on their network) they should consider monitoring these links too. Cable companies will groom the stream prior to transmitting it over their network. One of the best ways to assure that the broadcaster’s stream survives this integration into the cable network is to assure that the stream is fully standards compliant as it leaves the studio. 4 Broadcasters, MPEG Troubleshooting and the 2009 Switchover Station to Transmitter Audio/Video Encode Multiplexer PSIP/ Metadata insertion To Cable Companies And Telecom Companies 8VSB Reception MPEG Monitor Figure 2 Monitoring points in Broadcast Chain Each monitor point in the chain will require an appropriate input interface on the monitor. For example, 8VSB monitoring requires an RF interface. Typical monitors can accommodate multiple simultaneous inputs. Monitoring Rules There are two kinds of rules that MPEG Monitoring devices use to determine the health of an incoming transport streams. The first is standards based monitoring, and the second is monitoring for Business Intent Assurance ™. Standards based rules come out of standards bodies such as the ATSC (Advanced Television Systems Committee) and DVB (Digital Video Broadcast project). Business Intent Assurance ™ rules check the transport stream for missing components based on a template of what the stream “should” look like. Standards based monitoring In order for a transport stream to be fully compliant with MPEG and ATSC standards, many different rules must be validated. MPEG monitoring equipment should be able to trigger some action based on all of these rules. However, with so many standards based rules, it is often difficult to tell when an alarm on a monitoring system indicates serious system degradation, or a problem of much lower priority. 5 Broadcasters, MPEG Troubleshooting and the 2009 Switchover The problem of error classification goes right to the root of transport stream monitoring. It is not enough to tell an engineer that there is a problem in the transport stream; a monitor must indicate the severity of that error as well. Assuming that the broadcast system is relatively stable, then the vast majority of errors detected by the monitor will not be service affecting. If engineers are constantly confronted with ‘false alarms,’ errors which are not service affecting, they will learn to ignore the monitor, and the monitor’s function will be compromised. There are two widely accepted standards for classifying transport stream errors by severity. The first is a DVB (Digital Video Broadcasting Project) standard, ETR 101-290. The second is The Recommended Practice for Transport Stream Monitoring, A/78, by the ATSC. ETR 101-290 is the standard used by DVB for transport stream error monitoring. It identifies transport stream error conditions, and classifies them by severity. ETR101-290 uses three priority levels: Priority-one errors include those errors that affect the integrity of the transport stream and decodability of the MPEG-2 programs 5, such as sync errors, continuity counter error, missing PIDs, and, and PAT/PMT errors. Priority-two errors contain are those that affect individual programs, such as PCR errors, table CRC errors and encryption related errors. ETR 101-290 recommends continuous or periodic monitoring of these errors. Priority-three errors are application level errors related to individual elementary streams or DVB SI tables, such as audio and video buffer overflow/underflow errors. 1 ETR 101-290 provides a good framework for monitoring and classifying stream errors for DVB streams. It should be noted, however, that there are important differences between the ATSC and DVB digital television standards. One major difference in is the metadata: ATSC streams use PSIP for carrying tuning, EPG and other information, while DVB streams rely on PSI

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    10 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us