The realization that the 19.39Mb/s Grand Alliance transport stream (TS) could carry multiple SD programs was an afterthought, probably by business analysts. This did not please Congress or the FCC who had granted a second 6MHz channel to stimulate simulcast HD transmission.
When IBlast formed a distribution network to financially exploit unused spectrum by broadcasters who did not plan to convert to HD, everything went haywire. The business model called for charging viewers’ for the additional SD programming and data services.
Heated debate ensued. Should broadcasters be required to use their second channel for HDTV or should they be permitted to transmit four multiple SD programs?
This multiple SD program stream capability is being exploited today by US-DTV, who delivers services only available on cable, over the air. It is now safe to say that if a licensee went goes digital, the government would be happy.
From its conception, the ATSC transport mechanism was always intended to deliver more than 5.1 audio and HDTV video. Even the earliest TS specifications included a program guide methodology. Many of the ATSC standards are devoted to TS-delivered data services.
Building transport packets
Compression engines produce audio and video elementary streams (ES) that are then encapsulated into packetized elementary streams (PES packets). Each PES packet consists of a PES packet start code, PES header flags, PES packet header fields and a payload. A PES packet can be up to 65,536 bytes in length.
Each PES packet is assigned a packet ID (PID) common to the ES form. In the ATSC system, in order to facilitate channel acquisition in less than a half second, there is a defined relationship between video and audio PIDs for a given program. PES packets are divided into transport packets.
A transport packet consists of 188 bytes. The first byte of the four-byte packet header is the sync byte and has the hex value of 0x 47. The packet ID, a 13-bit value, is used to uniquely mark each ES of audio, video or data. A four-bit continuity counter field allows verification that packets have not been dropped. The remaining bits signal PES start, transport error and priority, scrambling and if an optional adaptation field is present.
Ultimately, transport packets are multiplexed into a constant 19.39Mb/s ATSC transport stream for over-the-air delivery of HDTV. The bit rate cannot be larger. Add something and something else must be removed.
Building a program: TS multiplex
Originally, the ATSC standard used the MPEG program and system information (PSI) methodology to describe to the receiver the contents of the TS and what elements to assemble into a program. A TS contains a program allocation table (PAT) with a PID 0f 0x0000 that describes the services available for decoding. Entries in the PAT point to the PIDs of program map table (PMT), where the PIDs of associated PES audio, video and data packets are identified. This provides sufficient information for an ATSC receiver to decode and present a program or service.
A single program (SPTS) or multiple programs (MPTS) may be carried in a transport stream. PID values are the key to assembling individual programs from an MPTS. Statistical multiplexing uses info about the complexity of a scene to determine how much bandwidth to allocate for a given stream. This leads to a feedback loop and variable bit rate encoding that dedicates bits based on scene complexity. This allows service providers to fit more programs into their limited bandwidth. Hence the quest for higher quality compression algorithms such as MPEG-4 and VC-1.
PSIP: TS metadata
Augmenting the original MPEG-based ATSC PSI specification, the program and system information protocol (PSIP), A/65B, standard defines tables that describe elements of a DTV service present in a TS.
Base tables, all with a PID of 0x1FFB, provide the necessary information to find and decode available channels. Base tables consist of the virtual channel table (VCT), regional rating table (RRT), master guide table (MGT) and system timetable (SST).
Parental control is enabled via the regional rating table (RRT). To apply these rating to content, the content advisory descriptor is used. RRT is optional and if omitted assumes the value of 0x01 for the U.S., U.S. possessions and Canada.
For an informative PSIP tutorial, visit the Interactive TV Web site at www.interactivetvweb.org/tutorial/dtv-intro/atsc-si/index.shtml.
Program Guide
Information that can be used by electronic program guides (EPG) is delivered in PSIP data. The event information table (EIT) is spilt into three-hour schedule blocks and is transmitted as separate sub-tables. UTC times are used in the EIT. A 14-bit event ID occurs when used in conjunction with the source ID.
The extended text table (ETT) contains the locations of extended text messages (ETM). An ETM location field points to additional text info about an event. These entries are multilingual.
By using EIT and ETT information, an EPG can be displayed on a receiver. Advanced EPG features can include automated program recording at the push of a dedicated remote control button.
Seamless splicing: commercial insertion
Even though most broadcasters have transitioned to digital infrastructures, not all programming, and particularly HD, originates locally. Regional commercials must be automatically and seamlessly inserted into primetime network feeds
Local ad insertion requires splicing compressed media into an ATSC transport stream. However, a TS is a collection of audio, video and data packets. Without an explicit blanking interval, switching from a program to commercial is difficult. Insuring that ATSC decoder buffers do not overflow or underflow is a complicated algorithmic challenge.
Digital program insertion (DPI) replaces traditional videotape and cue tones and activates programming sources using video servers and software-controlled switches. The Society of Cable Telecommunications Engineers has developed a set of DPI standards (SCTE 30 & 35) to facilitate ease of implementation and system integration. DPI enables targeted advertising, location specific public notifications, and other real-time applications to be placed automatically into a transport stream.
Wait. There’s more…
As we move into this multi-format, cross platform media methodology, transport streams will be the means to the enhanced HDTV experience. Data delivery standards and equipment are being developed for the requisite reliable, resilient and robust operation of a broadcast infrastructure.
Discussion of ATSC transport stream standards and functionality will continue in the next newsletter.
Standards
[1] ATSC Standard A/53C with Amendment No. 1 and Corrigendum No. 1: ATSC Digital Television Standard, Rev. C, 21 May 2004, (Amendment No. 1 dated 13 July 2004, Corrigendum No. 1, March 23, 2005) http://www.atsc.org/standards/a_53c_amend-1_corr-1.pdf
[2] ATSC Standard A/65B: Program and System Information Protocol for Terrestrial Broadcast and Cable, Rev. B, With Amendment No. 1 March 18, 2003; Amendment 1 dated April 28, 2005 www.atsc.org/standards/a_65b_with_amend_1.pdf
[3] ATSC Recommended Practice A/69:Program and System Information Protocol Implementation Guidelines for Broadcasters June 25, 2002 www.atsc.org/standards/a_69.pdf
[4] ANSI/SCTE 30, Digital Program Insertion Splicing APIwww.scte.org/documents/pdf/ANSISCTE302001DVS380.pdf
[5] ANSI/SCTE 35 2004, Digital Program Insertion Cueing Message for Cablewww.scte.org/documents/pdf/ANSISCTE352004.pdf
[6] ANSI/SCTE 67 2002, Applications Guidelines for SCTE 35 2001www.scte.org/documents/pdf/ANSISCTE672002DVS379.pdf
