Now that ATSC has released the A/153 Mobile DTV (MDTV) standard, many stations are considering broadcasting the service. One thing I learned while putting together the MDTV demo at CES in January is that MDTV, using IP transport, is quite different from A/53 "regular" ATSC DTV using PIDs. This month I'll provide an overview of the tables in A/153 and some audio and video coding parameters. When setting up a new MDTV facility, codec settings and the tables are likely to cause the most problems.
FAST INFORMATION CHANNEL
The first data a MDTV receiver will look for when switched on or tuned to a new channel is the "Fast Information Channel" or FIC. The FIC is separate from the data channel delivered through the Reed-Solomon error-corrected frames (RS Frames) and thus can be acquired much faster. The FIC transmits a data structure called an FIC-Chunk at least once within a single M/H Frame. The FIC-Chunk is broken up into as many as 16 FIC-Segments, which are interleaved across each M/H Subframe, which is 1/5 the size of each M/H Frame, or the size of 4 VSB data frames. Since each VSB data frame is 48.4 msec long, this means that the data in one FIC-Chunk can be decoded in about 194 msec.
The FIC-Chunks provide data on the M/H Ensembles available on the channel so the receiver has the information it needs to find the Ensemble's SMT-MH (Serv-ice Map Table) and start decoding the data streams. FIC-Chunk headers include the number of M/H Ensembles and the station's TSID, the same FCC assigned trans-port stream ID transmitted on the main ATSC channel. The FIC-Chunk payload data provides information on the Ensembles and the MH services inside each En-semble, including the MH_service_id and the SP_indicator (service protection).
The MH_service_id numbers must fall in a certain range as defined in Annex B of A/153 Part 3. ATSC has reserved a range for special uses, which could include EAS broadcasts, another range for local M/H services and finally a range for regional M/H services, where the service is broadcast in more than one local broadcast area. Annex B says MH_service_ids for regional services must be allocated via a registration authority so they are unique throughout the region. MH_service_ids in the local range only need to be unique in a local market. A local MH_service_id has a high-order byte in the range of 2-69 and matches the major channel number of the station as defined in Annex B of ATSC A/65. It should not be set to the RF channel unless it is the same number as the major channel, usually a station's former analog channel.
Additional data is provided by the tables transmitted in an IP multicast stream carried in each MH Ensemble—the M/H Service Signaling Channel, (Fig. 1). This channel contains the SMT-MH, the Guide Access Table (GAT-MH), the Cell Information Table (CIT-MH), the Service Labeling Table (SLT-MH) and the Re-gion Rating Table (RRT).
Fig. 1: ATSC-M/H hierarchical signaling architecture (A/153 Part 3, Figure 5.2) The RRT is used to send information about the content advisory system as detailed in ATSC A/65, except that when RTT is transmitted over MDTV the only con-straint on the interval between transmissions is that it shall not be greater than one hour. When transmitted it should be in the same ensemble as the one desig-nated for the Guide Access Table but there is no restriction on transmitting it in other ensembles as well.
The SLT-MH table is optional but can be useful if a service guide isn't available. The FIC only provides the MH_service_id (major, minor channel number for a local broadcast). The SLT-MH table can be used to provide a way to send more information on services without requiring the receiver to download the full service guide. It can contain the short_MH_service_name to better identify the service (call letters, channel name, etc.) and the MH_service_descriptor provid-ing additional information about the MH service.
The CEL-MH table is used to "hand off" the receiver to another transmitter carrying a similar service on a different channel. It contains information on the loca-tion of the transmitters, antenna patterns, power and the TSIDs of stations carrying the program stream. In addition to allowing regional networks (someone could watch the same network on a train traveling between cities without searching for a new station every time they lose the signal), it also permits the use of translators on different channels to fill in local coverage. It is not used in signal frequency networks (DTS).
The GAT-MH table tells the receiver where to find service guide data. This data can be transmitted on the same channel as the ATSC MDTV data or it can be pro-vided from another source—the Internet or another station, for example.
SERVICE MAP
I saved the SMT-MH table for last because it is the most complex table and the one likely to cause the most problems, (it could be compared to the PMT in conventional ATSC). The SMT-MH includes critical data such as the service and component source and destination IP addresses and UDP port numbers. Each service has an M/H Service Category. Only five categories are currently specified in Table 7.3 of A/153 Part 3: Three of these categories point to the compo-nent_level_descriptor to identify the specific service category: Basic TV (0x01), Basic Radio (0x02) and "not specified" (0x00). The other two refer to rights issuer (RI) services (0x03) and Service Guide (0x08).
In ATSC MDTV, real-time media is transmitted using RTP (Real-time Transport Protocol) encapsulated by UDP (User Datagram Protocol). In this regard, ATSC MDTV has much in common with Internet multimedia streaming. Technical parameters of an RTP stream are contained in an SDP (Session Description Protocol) file. ATSC MDTV transmits SDP for announcement of services, but the MH_component_descriptor in the SMT-MH table is used for signaling codec capabilities. In setting up the CES demo, I ran into receiver compatibility problems when attempting to transfer the encoder SDP data into the MH_component_descriptor data. The message and descriptor contain many of the same parameters and problems can occur if they don't match. A/153 says that the MH_component descriptor takes precedence over the SDP message and it advises use of the data fields in the MH_component descriptor to initialize the receiver decoders.
The M/H Component Descriptor uses a number between zero and 127 to define the RTP payload type. Key components are the H.264/AVC video stream (35), the HE AAC v2 audio stream (37), FLUTE file delivery (38), and the NTP timebase stream (42). Other components include keys to decrypt programming and OMA-RME (rich media environment) streams.
ATSC A/153 Part 7-AVC and SVC Video System Characteristics defines how video is transmitted in the MDTV stream. SVC provides a way to transmit data that can be added to the AVC base video stream to provide higher resolution pictures (832x480 or 624x360). As I'm not aware of any use of SVC now, I'll defer discussion of it. AVC video has size of 418x240 pixels and uses progressive scanning.
DECODING THE STREAMS
The only display aspect ratio in A/153 is 16:9. Several frame rates are supported, including still pictures and rates of 11.99, 12, 12.5, 14.98, 15, 23.98, 24, 25, 29.97 and 30 Hz. In order to maintain square pixels, before a 1920x1080i image is downconverted for MDTV transmission, 24 pixels on the left and right side of the image are cropped to give a 1872x1080 image. A/153 Part 7 describes how other formats are to be converted for MDTV.
The video and audio MH_component_descriptor data contain parameters specified in ISO/IEC standards that are used to tell the receiver how to decode the streams. My Internet searches did not find any free copies of the referenced tables in ISO/IEC 14496-10 (Baseline Profile syntax of AVC video) or ISO/IEC 14496-3 regarding AAC audio source coding. This is a problem because some parameters require the ISO/IEC tables to determine the profile_idc and associ-ated parameters for H.264 video and the profile_id for HE AAC v2 audio. If the fields aren't right, receivers won't work, as I found out.
Fortunately ATSC A/153 provides some guidance on setting these parameters. Annex A of A/153 Part 7 describes the relations between the MH_Component_Data Descriptor and the SDP for video and Annex A of A/153 Part 8 covers audio. Table A.1 of the Part 8 Annex A provides HE AAC v2 Audio-SpecificConfig strings for some common audio configurations.
You can learn much more about the tables in A/153 by downloading A/153 Parts 3, 7 and 8 from www.atsc.org/standards.
Unfortunately, as of now there is no inexpensive "TSReader" for the ATSC A/153 tables. I'm hoping that once ATSC MDTV USB tuners hit the market, some-one, perhaps TSReader Author Rod Hewitt will find a way to decode the IP stream from one or more of these tuners and display it in TSReader.
Until that happens, if you don't have an MDTV stream analyzer there is usually a way to view the multiplexer configuration file; in the Rohde and Schwarz AEM-100, it is an XML file that can be downloaded through the web GUI. The Envivio H.264 encoder's Web interface provides a way to download the encoder's SDP file. Using the information in Annex of A/153 Parts 7 and 8, compare the files and make sure the parameters match and are within A/153 specifi-cations.
Let me know if this information was useful. In future columns I'll explain how to calculate how much of the 19.39 Mbps bandwidth it takes to offer specific MDTV payload rates and how all of the MDTV streams and tables I described this month are assembled into the transmitted ATSC stream.
Your questions and comments area always welcome! E-mail me atdlung@transmitter.com.
