System.NullReferenceException: Object reference not set to an instance of an object. at DotNetNuke.Framework.DefaultPage.OnLoad(EventArgs e) in e:\websites\\public_html\Default.aspx.cs:line 791 Maintaining ATSC compliance | TvTechnology

Maintaining ATSC compliance

Keeping up with the A/53, A/52 and A/65 standards will ensure proper signal reception. November 1, 2008

With the dawn of digital-only TV broadcasting just a few months away, full-service broadcasters and digital transmission plants are finally drawing the scrutiny and attention they deserve. Many are finding that encoders and PSIP generators that once were in compliance with all applicable ATSC standards and FCC regulations are now out of compliance, if for no other reason than the underlying standard(s) changed but the equipment did not.

Digital transmission will be your station's sole bread and butter within a few months. As a result, complying with all current ATSC standards and applicable FCC rules is the best, if not only, way to ensure that broadcast signals are usable by all receivers.

Transport stream multiplex

We need to first start with what a transport stream multiplex really is. Whether operating one or three TV stations, broadcasters use one or more transport stream multiplexes to send compressed (retail) signals to viewers in their homes and businesses.

Unlike the limited options permitted with analog broadcasting and its single service per broadcast channel, the multiplex offers a nice toolkit, with just a few rules on how to use it. The ability to place a content stream on any packet ID (PID) carries with it the responsibility to provide viewers with a way to find and process that content stream.

Standards and constraints

The ATSC has published three standards that build upon the MPEG-2 work to create the digital television system used in the United States, Canada, Mexico and other countries. These are the Digital Television, Digital Audio and PSIP standards, known respectively as A/53, A/52 and A/65, each of which the FCC has adopted into its regulations.

MPEG-2 transport streams can include one or more packetized video and audio data elementary streams, which can make up one or more MPEG-2 program services. For receivers to render the elementary streams into a usable TV channel, the transport stream multiplex must include metadata describing where to find elementary streams as well as simple combining directions. Broadcast metadata can generally be thought of as having two classes: signaling metadata (useful mostly to receivers) and announcement metadata (useful mostly to viewers).

Fundamentally, ATSC standards used in broadcasting impose constraints on MPEG-2 transport streams. The best-known constraint is “Table 3,” which attempted to limit ATSC broadcasters to a handful of video formats. While this is still an A/53 provision, the ATSC has no enforcement powers, and the FCC, which does, has pointedly chosen not to adopt Table 3. So broadcasters are free to use any screen dimension that is evenly divisible by 16.

One ATSC constraint is that each program element is the sole user of each PID. Another key constraint is the encapsulating of analog (CEA-608) and digital (CEA-708) closed-captioning into video elementary streams.

The MPEG-2 specification provides for a program association table (PAT), found in a specific location that signals where to find each of the program map table (PMT) sections that describe the individual virtual channels in the multiplex. While MPEG doesn't specify how often these should be transmitted, A/53 requires that a PAT appear in a transport stream at least once every 100ms, while each PMT section should appear at least once every 400ms. (See Figure 1 on page 58.)

PAT and PMT descriptors

It is important that all entries in the PAT and PMT sections be accurate; otherwise, some receivers may not render a virtual channel or even fail to tune in a multiplex. Each program_number value may be only used once.

Likewise, each PMT section must include the program_number value signaled in the PAT for that virtual channel. Each elementary stream in the transport stream must be listed in at least one PMT section or that stream is unusable.

ATSC A/53 imposes a few often overlooked requirements on the PMT. First, each must include a program smoothing buffer descriptor. There are two fields in the descriptor: sb_leak_rate, which is the maximum rate for bits leaving the buffer, and sb_size, which signals the size in bytes of the smoothing buffer. While A/53 seems to imply that a value of zero is permitted for both of these fields, such settings would specify a buffer with zero length and no purpose. Typical values for sb_leak_rate are 1000 (signaling 400,000b/s) up to the maximum bit rate for the program, and a typical value for sb_size is 512.

Additionally, when an MPEG-2 video stream is described in the PMT, there must be a data_stream_alignment_descriptor in the element's descriptor loop, with descriptor_length equal to one and alignment_type equal to two (for video_access_unit).


Now, we turn to making sure that the PSIP properly describes the MPEG-2 arrangement. PSIP has a broader context and scope than MPEG-2 PSI (including analog channels), extending up to 128 hours (16 days) into the future, whereas MPEG-2 PSI is about the “here and now.”

It is important to note that there is some overlap between MPEG-2 PATs and PMTs and ATSC PSIP, and compliance requires the overlapped data to be consistent. Perhaps most important here is that the MPEG-2 PAT and the PSIP terrestrial virtual channel table (TVCT) both have the same value for transport_stream_id. Otherwise, receiving equipment in homes and at cable TV headends will be fouled up. Of course, the transport_stream_id value must be the one assigned to your station by the FCC.

AC-3 descriptors

Sometimes, consistency even means technically inaccurate. The best example is the AC-3 descriptor, which contains a field that indicates the number of audio channels in an AC-3 stream. So, the thinking goes, that means the AC-3 descriptor must change when an interstitial message with only stereo audio airs within a TV program with 5.1 audio. This thinking is incorrect.

The AC-3 descriptor is bound to the concept of a TV program (event), and a message or spot within a program is still part of the program. A/65 provides for the AC-3 descriptor to also appear in the PMT, but that descriptor is still bound to the televised event, because it must have the same values as the AC-3 descriptor in the event information table (EIT).

TVCT descriptors

With some PMT section overlap, the TVCT lists all virtual channels that broadcasters want to inform viewers about. However, the TVCT entry for a channel includes a short name, such as “KGET-DT,” and can include information on analog channels. In the receiver, the program_number in a TVCT entry is used to match the entry with the appropriate PMT section, and the source_id is used to link to announced events. TVCT entries cannot have any duplicate source_ids, and the sections must be transmitted at least once every 400ms.

On the redundancy side, the TVCT entry for a digital channel must include the service location descriptor, which duplicates much of the functionality of the PMT for the same channel.

When transmitting a channel description, the channel extended text table (CETT) and its unique PID must be properly listed in the master guide table (MGT), and the ETM_location field must be set to one or two. Otherwise, the CETT won't be associated with the virtual channel in most receivers. Likewise, descriptions of televised events won't be matched up with the appropriate EIT entry unless the ETM_location for the EIT entry is set correctly.

All PSIP tables (except the system time table) must have their summary data listed in the MGT, which should be transmitted at least once every 150ms. And now with an ATSC-compliant transport stream, proudly assert the “GA94” (Grand Alliance '94 or ATSC) registration descriptor, located in PMT sections and the TVCT. Sadly, this registration descriptor is seen more often than true ATSC compliance.

John Willkie is the founder of EtherGuide Systems and is a member of the ATSC S1 and SMPTE S22-WG10 subcommittees.

Receive regular news and technology updates.
Sign up for our free newsletter here.