Doc. A/53B
7 August 2001
ATSC Digital Television Standard
(Revision B)
AdvancedTelevision Systems Committee
1750K Street, N.W.
Suite1200
Washington,D.C. 20006
The Advanced Television SystemsCommittee (ATSC), is an international, non-profit membership organizationdeveloping voluntary standards for the entire spectrum of advanced televisionsystems.
Specifically, ATSC is working tocoordinate television standards among different communications media focusingon digital television, interactive systems, and broadband multimediacommunications. ATSC is also developing digital television implementationstrategies and presenting educational seminars on the ATSC standards.
ATSC was formed in 1982 by the memberorganizations of the Joint Committee on InterSociety Coordination (JCIC): theElectronic Industries Association (EIA), the Institute of Electrical andElectronic Engineers (IEEE), the National Association of Broadcasters (NAB),the National Cable Television Association (NCTA), and the Society of MotionPicture and Television Engineers (SMPTE). Currently, there are approximately190 members representing the broadcast, broadcast equipment, motion picture,consumer electronics, computer, cable, satellite, and semiconductor industries.
ATSC Digital TV Standards include digitalhigh definition television (HDTV), standard definition television (SDTV), databroadcasting, multichannel surround-sound audio, and satellite direct-to-homebroadcasting.
1. Scope and documentationstructure.. 9
3.2 Treatment of Syntactic Elements 10
3.4 Symbols, Abbreviations, andMathematical Operators 16
3.4.8 Method of Describing Bit StreamSyntax 18
3.4.8.1 Definition of bytealigned function 19
3.4.8.2 Definition of nextbits function 19
3.4.8.3 Definition of next_start_codefunction 19
4.1 Advisory Committee on AdvancedTelevision Service (ACATS) 20
4.2 Digital HDTV Grand Alliance (GrandAlliance) 21
4.3 Organization for Documenting theDigital Television Standard 21
4.4 Principles for Documenting theDigital Television Standard 22
Annex A: Video SystemCharacteristics (Normative)
5. Sourcecoding specification.. 28
5.1 Constraints with Respect to ISO/IEC13818-2 Main Profile 28
5.1.1 Sequence Header Constraints 28
5.1.2 Compression Format Constraints 29
5.1.3 Sequence Extension Constraints 29
5.1.4 SequenceDisplay Extension Constraints 30
5.1.5 Picture Header Constraints 30
5.1.6 Picture Coding Constraints 30
5.2 Bit Stream Specifications BeyondMPEG-2 30
5.2.1 Picture Extension and User DataSyntax 30
5.2.2 Picture User Data Syntax 31
5.2.3 Picture User Data Semantics 32
AnnexB: Audio System Characteristics (Normative)
5.1 Constraints With Respect to ATSCStandard A/52A 35
5.6 Dynamic Range Compression 36
6. Main andassociated services.. 36
6.1 Summary of Service Types 37
6.2 Complete Main Audio Service (CM) 37
6.3 Main Audio Service, Music and Effects(ME) 37
7. Audioencoder interfaces.. 40
7.1 Audio Encoder Input Characteristics 40
7.2 Audio Encoder Output Characteristics 40
AnnexC: Service Multiplex & Transport System Characteristics (Normative)
5.1 MPEG-2 Systems Standard 43
5.2 Registration Descriptor 43
5.2.2 Audio Elementary Stream Identifier 43
5.5.1 Video PES Constraints 44
5.5.2 Audio PES Constraints 45
5.6.1 System Information and Program Guide 45
5.6.1.1 System information and programguide PID 45
5.6.1.2 System information and programguide STD model45
5.6.2 Specification of Private DataServices 46
5.6.2.1.1 Syntax and semantics 46
5.6.2.1.2 Ancillary service target decoder(ASTD) 46
5.6.2.2 Stream type and PMT descriptors 47
5.7 Assignment of Identifiers 47
5.7.2.1 AC-3 audio descriptor 48
5.7.2.2 Program smoothing buffer descriptor 48
5.8 Extensions to the MPEG-2 SystemsSpecification 48
6. Features of13818-1 not supported by this Standard.. 49
7. Transportencoder interfaces and bit rates.. 49
7.1 Transport Encoder InputCharacteristics 49
7.2 Transport Output Characteristics 49
AnnexD: RF/Transmission System Characteristics (Normative)
4. Transmissioncharacteristics for terrestrial broadcast.. 50
4.1 Channel Error Protection andSynchronization 53
4.2.1 Bit-to-Symbol Mapping 63
4.2.3 8 VSB Modulation Method 63
5. Transmissioncharacteristics for high data rate mode.. 64
5.1 Channel Error Protection and Synchronization 66
5.2.1 Bit-to-Symbol Mapping 67
5.2.3 16 VSB Modulation Method 67
AnnexE: Receiver Characteristics (Informative)
2. Referencesto existing or emerging standards.. 68
4. Status ofreceiver standardization activities.. 68
4.1.2 Channelization Plan for Broadcastand Cable 69
4.5 Conditional Access Interface 69
Index of Tables and Figures
Table A1 Standardized Video Input Formats 28
Table A2 Sequence Header Constraints 28
Table A3 Compression Format Constraints 29
Table A4 Sequence Extension Constraints 29
Table A5 Sequence Display Extension Constraints 30
Table A6 Picture Extension and User Data Syntax 31
Table A7 Picture User Data Syntax 32
Table B2 Audio Service Types 37
Table C1 Transport Scrambling Control Field 48
Table D1 Interleaving Sequence 58
Table D2 Byte to Symbol Conversion, Multiplexingof Trellis Encoders 59
Figure 5.1 ITU-R digital terrestrialtelevision broadcasting model.24
Figure 5.2 High level view of encoding equipment.25
Figure B1 Audio subsystem in the digitaltelevision system.35
Figure C1 Sample organization of functionality ina transmitter-receiver pair for a single program.42
Figure C2 Ancillary service target decoder.47
Figure D3 VSB channel occupancy (nominal).53
Figure D4 Randomizer polynomial.54
Figure D5 Reed-Solomon (207,187) t=10 paritygenerator polynomial.55
Figure D6 Convolutional interleaver (byte shiftregister illustration).56
Figure D7 8 VSB trellis encoder, precoder, andsymbol mapper.57
Figure D8 Trellis code interleaver.57
Figure D9 8 VSB data segment.60
Figure D10 VSB data field sync.61
Figure D11 Field sync PN sequence generators.62
Figure D12 Nominal VSB system channel response(linear phase raised cosine Nyquist
filter).64
Figure D13 16 VSB data segment.65
Figure D14 16 VSB transmitter.65
ATSC Digital Television Standard
1. Scope and documentation structure
The Digital Television Standarddescribes the system characteristics of the U. S. advanced television (ATV)system. The document and its normative annexes provide detailed specificationof the parameters of the system including the video encoder input scanningformats and the pre-processing and compression parameters of the video encoder,the audio encoder input signal format and the pre-processing and compressionparameters of the audio encoder, the service multiplex and transport layercharacteristics and normative specifications, and the VSB RF/Transmissionsubsystem.
2. Documentation Structure
The documentation of the DigitalTelevision Standard consists of this document which provides a general systemoverview, a list of reference documents, and sections relating to the system asa whole. The system is modular in concept and the specifications for each ofthe modules are provided in the appropriate annex.
3. References
Normative references may be foundin each normative Annex. The Digital Television Standard is based on theISO/IEC MPEG-2 Video Standard, the Digital Audio Compression (AC-3) Standard,and the ISO/IEC MPEG-2 Systems Standard. Those references are listed here forthe convenience of the reader. In addition, a guide to the use of the DigitalTelevision Standard is listed.
ATSC Standard A/52 (1995), DigitalAudio Compression (AC-3).
ATSC Document A/54 (1995), Guideto the Use of the ATSC Digital Television Standard.
ISO/IEC IS 13818-1, InternationalStandard (1996), MPEG-2 Systems.
ISO/IEC 13818-1: 1996/Cor. 1: 1997(E) Technical Corrigendum 1.
ISO/IEC 13818-1: 1996/Amd. 1: 1997(E) Amendment 1.
ISO/IEC 13818-1: 1996/Amd. 2: 1997(E) Amendment 2.
ISO/IEC 13818-1: 1996/Amd. 3: 1997(E) Amendment 3.
ISO/IEC13818-1: 1996/Amd. 4: 1997 (E) Amendment 4.
ISO/IEC IS 13818-2, International Standard (1996), MPEG-2 Video.
ISO/IEC 13818-2: 1996/Cor. 1: 1997 (E)MPEG-2 Video Technical Corrigendum 1.
ISO/IEC 13818-2: 1996/Cor. 2: 1997 (E)MPEG-2 Video Technical Corrigendum 2.
4. Definitions
With respect to definition ofterms, abbreviations, and units, the practice of the Institute of Electricaland Electronics Engineers (IEEE) as outlined in the Institute’s publishedstandards shall be used. Where an abbreviation is not covered by IEEE practice,or industry practice differs from IEEE practice, then the abbreviation in questionwill be described in Section 3.4ofthis document. Many of the definitions included therein are derived fromdefinitions adopted by MPEG.
5. Compliance Notation
As used in this document, “shall”or “will” denotes a mandatory provision of the standard. “Should” denotes aprovision that is recommended but not mandatory. “May” denotes a feature whosepresence does not preclude compliance, that may or may not be present at theoption of the implementor.
6. Treatment of Syntactic Elements
This document contains symbolicreferences to syntactic elements used in the audio, video, and transport codingsubsystems. These references are typographically distinguished by the use of adifferent font (e.g., restricted), may contain the underscore character (e.g., sequence_end_code) and may consist of character strings that are not English words(e.g., dynrng).
7. Terms Employed
For the purposes of the DigitalTelevision Standard, the following definition of terms apply:
ACATS: Advisory Committee on AdvancedTelevision Service.
access unit: A coded representation of apresentation unit. In the case of audio, an access unit is the codedrepresentation of an audio frame. In the case of video, an access unit includesall the coded data for a picture, and any stuffing that follows it, up to butnot including the start of the next access unit. If a picture is not precededby a group_start_code or a sequence_header_code, the access unit begins with a the picture start code. If a pictureis preceded by a group_start_code and/or a sequence_header_code, the access unit begins with the first byte of the first of thesestart codes. If it is the last picture preceding a sequence_end_code in the bitstream all bytes between the last byte of the coded picture and the sequence_end_code (including the sequence_end_code) belong to the access unit.
A/D: Analog to digital converter.
AES: Audio Engineering Society.
anchor frame: A video frame that is usedfor prediction. I-frames and P-frames are generally used as anchor frames, butB-frames are never anchor frames.
ANSI: American National StandardsInstitute.
Asynchronous Transfer Mode (ATM): Adigital signal protocol for efficient transport of both constant-rate andbursty information in broadband digital networks. The ATM digital streamconsists of fixed-length packets called “cells,” each containing 53 8-bitbytes—a 5-byte header and a 48-byte information payload.
ATEL: Advanced Television EvaluationLaboratory.
ATM: See asynchronous transfer mode.
ATTC: Advanced Television Test Center.
ATV: The U. S. advanced televisionsystem.
bidirectional pictures or B-pictures or B-frames: Pictures that use both future and past pictures as areference. This technique is termed bidirectionalprediction. B-pictures provide the most compression. B-pictures do not propagatecoding errors as they are never used as a reference.
bit rate: The rate at which thecompressed bit stream is delivered from the channel to the input of a decoder.
block: A block is an 8-by-8 array of pelvalues or DCT coefficients representing luminance or chrominance information.
bps: Bits per second.
byte-aligned: A bit in a coded bitstream is byte-aligned if its position is a multiple of 8-bits from the firstbit in the stream.
CDTV: See conventional definition television.
channel: A digital medium that stores ortransports a digital television stream.
coded representation: A data element asrepresented in its encoded form.
compression: Reduction in the number ofbits used to represent an item of data.
constant bit rate: Operation where thebit rate is constant from start to finish of the compressed bit stream.
conventional definition television (CDTV): This term is used to signify the analog NTSC television system as defined in ITU-R Recommendation470. See also standard definitiontelevision and ITU-R Recommendation 1125.
CRC: The cyclic redundancy check toverify the correctness of the data.
D-frame: Frame coded according to anMPEG-1 mode which uses DC coefficients only.
data element: An item of data asrepresented before encoding and after decoding.
DCT: See discrete cosine transform.
decoded stream: The decodedreconstruction of a compressed bit stream.
decoder: An embodiment of a decodingprocess.
decoding (process): The process definedin the Digital Television Standard that reads an input coded bit stream andoutputs decoded pictures or audio samples.
decoding time-stamp (DTS): A field thatmay be present in a PES packet header that indicates the time that an access unit isdecoded in the system target decoder.
digital storage media (DSM): A digitalstorage or transmission device or system.
discrete cosine transform: Amathematical transform that can be perfectly undone and which is useful inimage compression.
DSM-CC: Digital storage media commandand control.
DSM: Digital storage media.
DTS: See decoding time-stamp.
DVCR: Digital video cassette recorder
ECM: See entitlement control message.
editing: A process by which one or morecompressed bit streams are manipulated to produce a new compressed bit stream.Conforming edited bit streams are understood to meet the requirements definedin the Digital Television Standard.
elementary stream (ES): A generic termfor one of the coded video, coded audio, or other coded bit streams. Oneelementary stream is carried in a sequence of PES packets with one and only onestream_id.
elementary stream clock reference (ESCR): A time stamp in the PES stream from which decoders of PES streams may derivetiming.
EMM: See entitlement management message.
encoder: An embodiment of an encodingprocess.
encoding (process): A process that readsa stream of input pictures or audio samples and produces a valid coded bitstream as defined in the Digital Television Standard.
entitlement control message (ECM):Entitlement control messages are private conditional access information whichspecify control words and possibly other stream-specific, scrambling, and/orcontrol parameters.
entitlement management message (EMM):Entitlement management messages are private conditional access informationwhich specify the authorization level or the services of specific decoders.They may be addressed to single decoders or groups of decoders.
entropy coding: Variable length losslesscoding of the digital representation of a signal to reduce redundancy.
entry point: Refers to a point in acoded bit stream after which a decoder can become properly initialized andcommence syntactically correct decoding. The first transmitted picture after anentry point is either an I-picture or a P-picture. If the first transmittedpicture is not an I-picture, the decoder may produce one or more picturesduring acquisition.
ES: See elementary stream.
ESCR: See elementary stream clock reference.
event: An event is defined as acollection of elementary streams with a common time base, an associated starttime, and an associated end time.
field: For an interlaced video signal, a“field” is the assembly of alternate lines of a frame. Therefore, an interlacedframe is composed of two fields, a top field and a bottom field.
forbidden: This term, when used in clausesdefining the coded bit stream, indicates that the value shall never be used.This is usually to avoid emulation of start codes.
FPLL: Frequency and phase locked loop.
frame: A frame contains lines of spatialinformation of a video signal. For progressive video, these lines containsamples starting from one time instant and continuing through successive linesto the bottom of the frame. For interlaced video a frame consists of twofields, a top field and a bottom field. One of these fields will commence onefield later than the other.
GOP: See group of pictures.
Group of pictures (GOP): A group ofpictures consists of one or more pictures in sequence.
HDTV: See high definition television.
high definition television (HDTV): Highdefinition television has a resolution of approximately twice that ofconventional television in both the horizontal (H) and vertical (V) dimensionsand a picture aspect ratio (H ´ V) of16:9. ITU-R Recommendation 1125 further defines “HDTV quality” as the deliveryof a television picture which is subjectively identical with the interlacedHDTV studio standard.
high level: A range of allowed pictureparameters defined by the MPEG-2 video coding specification which correspondsto high definition television.
Huffman coding: A type of source codingthat uses codes of different lengths to represent symbols which have unequallikelihood of occurrence.
IEC: International ElectrotechnicalCommission.
intra-coded pictures or I-pictures or I-frames: Pictures that are coded using information present only inthe picture itself and not depending on information from other pictures. I‑picturesprovide a mechanism for random access into the compressed video data. I‑picturesemploy transform coding of the pel blocks and provide only moderate compression.
ISO: International Organization forStandardization.
ITU: International TelecommunicationUnion.
JEC: Joint Engineering Committee of EIAand NCTA.
layer: One of the levels in the datahierarchy of the video and system specification.
level: A range of allowed pictureparameters and combinations of picture parameters.
macroblock: In the advanced televisionsystem, a macroblock consists of four blocks of luminance and one each Crand Cb block.
main level: A range of allowed pictureparameters defined by the MPEG-2 video coding specification with maximumresolution equivalent to ITU-R Recommendation 601.
main profile: A subset of the syntax ofthe MPEG-2 video coding specification that is expected to be supported over alarge range of applications.
Mbps: 1,000,000 bits per second.
motion vector: A pair of numbers whichrepresent the vertical and horizontal displacement of a region of a referencepicture for prediction.
MP@HL: Main profile at high level.
MP@ML: Main profile at main level.
MPEG: Refers to standards developed bythe ISO/IEC JTC1/SC29 WG11, MovingPicture Experts Group. MPEG may also refer to the Group.
MPEG-1: Refers to ISO/IEC standards11172-1 (Systems), 11172-2 (Video), 11172-3 (Audio), 11172-4 (ComplianceTesting), and 11172-5 (Technical Report).
MPEG-2: Refers to ISO/IEC standards13818-1 (Systems), 13818-2 (Video), 13818-3 (Audio), 13818-4 (Compliance).
pack: A pack consists of a pack headerfollowed by zero or more packets. It is a layer in the system coding syntax.
packet data: Contiguous bytes of datafrom an elementary data stream present in the packet.
packet identifier (PID): A uniqueinteger value used to associate elementary streams of a program in a single ormulti-program transport stream.
packet: A packet consists of a headerfollowed by a number of contiguous bytes from an elementary data stream. It isa layer in the system coding syntax.
padding: A method to adjust the averagelength of an audio frame in time to the duration of the corresponding PCMsamples, by continuously adding a slot to the audio frame.
payload: Payload refers to the byteswhich follow the header byte in a packet. For example, the payload of atransport stream packet includes the PES_packet_header and its PES_packet_data_bytes or pointer_field and PSI sections, or private data. A PES_packet_payload, however,consists only of PES_packet_data_bytes. The transport stream packet header and adaptation fields are notpayload.
PCR: See program clock reference.
pel: See pixel.
PES packet header: The leading fields ina PES packet up to but not including the PES_packet_data_byte fieldswhere the stream is not a padding stream. In the case of a padding stream, the PESpacket header is defined as the leading fields in a PESpacket up to but not including the padding_byte fields.
PES packet: The data structure used tocarry elementary stream data. It consists of a packet header followed by PESpacket payload.
PES Stream: A PESstream consists of PES packets, all of whose payloads consist of data from a singleelementary stream, and all of which have the same stream_id.
PES: An abbreviation for packetizedelementary stream.
picture: Source, coded, or reconstructedimage data. A source or reconstructed picture consists of three rectangularmatrices representing the luminance and two chrominance signals.
PID: See packet identifier.
pixel: “Picture element” or “pel.” Apixel is a digital sample of the color intensity values of a picture at asingle point.
predicted pictures or P-pictures or P-frames: Pictures that are coded with respect to the nearest previous I or P-picture. This techniqueis termed forward prediction. P‑picturesprovide more compression than I-pictures and serve as a reference for future P‑picturesor B-pictures. P-pictures can propagate coding errors when P-pictures (or B‑pictures)are predicted from prior P-pictures where the prediction is flawed.
presentation time-stamp (PTS): A fieldthat may be present in a PES packet header that indicates the time that a presentation unit ispresented in the system target decoder.
presentation unit (PU): A decoded audioaccess unit or a decoded picture.
profile: A defined subset of the syntaxspecified in the MPEG-2 video coding specification
program clock reference (PCR): A timestamp in the transport stream from which decoder timing is derived.
program element: A generic term for oneof the elementary streams or other data streams that may be included in theprogram.
program specific information (PSI): PSIconsists of normative data which is necessary for the demultiplexing oftransport streams and the successful regeneration of programs.
program: A program is a collection ofprogram elements. Program elements may be elementary streams. Program elementsneed not have any defined time base; those that do have a common time base andare intended for synchronized presentation.
PSI: See program specific information.
PTS: See presentation time-stamp.
PU: See presentation unit.
quantizer: A processing step whichintentionally reduces the precision of DCT coefficients.
random access: The process ofbeginning to read and decode the coded bit stream at an arbitrary point.
reserved: This term, when used inclauses defining the coded bit stream, indicates that the value may be used inthe future for Digital Television Standard extensions. Unless otherwisespecified within this Standard, all reserved bits shall be set to “1”.
SCR: See system clock reference.
scrambling: The alteration of thecharacteristics of a video, audio, or coded data stream in order to preventunauthorized reception of the information in a clear form. This alteration is aspecified process under the control of a conditional access system.
SDTV: See standard definition television.
slice: A series of consecutivemacroblocks.
SMPTE: Society of Motion Picture andTelevision Engineers.
source stream: A single, non-multiplexedstream of samples before compression coding.
splicing: The concatenation performed onthe system level or two different elementary streams. It is understood that theresulting stream must conform totally to the Digital Television Standard.
standard definition television (SDTV):This term is used to signify a digital televisionsystem in which the quality is approximately equivalent to that of NTSC. Thisequivalent quality may be achieved from pictures sourced at the 4:2:2 level ofITU-R Recommendation 601 and subjected to processing as part of the bit ratecompression. The results should be such that when judged across arepresentative sample of program material, subjective equivalence with NTSC isachieved. Also called standard digital television. See also conventional definition television andITU-R Recommendation 1125.
start codes: 32-bit codes embedded inthe coded bit stream that are unique. They are used for several purposesincluding identifying some of the layers in the coding syntax. Start codesconsist of a 24 bit prefix (0x000001) and an 8 bit stream_id.
STD input buffer: A first-in, first-outbuffer at the input of a system target decoder for storage of compressed datafrom elementary streams before decoding.
STD: See system target decoder.
still picture: A coded still pictureconsists of a video sequence containing exactly one coded picture which isintra-coded. This picture has an associated PTS and the presentation time ofsucceeding pictures, if any, is later than that of the still picture by atleast two picture periods.
system clock reference (SCR): A timestamp in the program stream from which decoder timing is derived.
system header: The system header is adata structure that carries information summarizing the system characteristicsof the Digital Television Standard multiplexed bit stream.
system target decoder (STD): Ahypothetical reference model of a decoding process used to describe thesemantics of the Digital Television Standard multiplexed bit stream.
time-stamp: A term that indicates thetime of a specific action such as the arrival of a byte or the presentation ofa presentation unit.
TOV: Threshold of visibility.
Transport Stream packet header: Theleading fields in a Transport Stream packet up to and including the continuity_counter field.
variable bit rate: Operation where thebit rate varies with time during the decoding of a compressed bit stream.
VBV: See video buffering verifier.
Video buffering verifier (VBV): Ahypothetical decoder that is conceptually connected to the output of anencoder. Its purpose is to provide a constraint on the variability of the datarate that an encoder can produce.
video sequence: A video sequence isrepresented by a sequence header, one or more groups of pictures, and an end_of_sequence code in the data stream.
8 VSB: Vestigial sideband modulationwith 8 discrete amplitude levels.
16 VSB: Vestigial sideband modulationwith 16 discrete amplitude levels.
8. Symbols, Abbreviations, and Mathematical Operators
The symbols, abbreviations, andmathematical operators used to describe the Digital Television Standard arethose adopted for use in describing MPEG-2 and are similar to those used in the“C” programming language. However, integer division with truncation androunding are specifically defined. The bitwise operators are defined assumingtwo’s-complement representation of integers. Numbering and counting loopsgenerally begin from 0.
9. Arithmetic Operators
+ Addition.
– Subtraction(as a binary operator) or negation (as a unary operator).
++ Increment.
- - Decrement.
* or ´ Multiplication.
^ Power.
/ Integerdivision with truncation of the result toward 0. For example, 7/4 and –7/–4 aretruncated to 1 and –7/4 and 7/–4 are truncated to –1.
// Integerdivision with rounding to the nearest integer. Half-integer values are roundedaway from 0 unless otherwise specified. For example 3//2 is rounded to 2, and–3//2 is rounded to –2.
DIV Integerdivision with truncation of the result towards –¥.
% Modulusoperator. Defined only for positive numbers.
Sign( ) Sign(x) =1 x> 0
=0 x== 0
=–1 x < 0
NINT ( ) Nearestinteger operator. Returns the nearest integer value to the real-valuedargument. Half-integer values are rounded away from 0.
sin Sine.
cos Cosine.
exp Exponential.
Ö Squareroot.
log10 Logarithm to base ten.
loge Logarithm to base e.
10. Logical Operators
|| LogicalOR.
&& LogicalAND.
! LogicalNOT.
11. Relational Operators
> Greater than.
³ Greater than orequal to.
< Less than.
£ Less than orequal to.
== Equal to.
!= Not equal to.
max[,...,] The maximum value in the argumentlist.
min[,...,] The minimum value in theargument list.
12. Bitwise Operators
& AND.
| OR.
>> Shift right withsign extension.
<< Shift left with 0fill.
13. Assignment
= Assignment operator.
14. Mnemonics
Thefollowing mnemonics are defined to describe the different data types used inthe coded bit stream.
| bslbf | Bit string, left bit first, where “left” is the order in which bit strings are written in the Standard. Bit strings are written as a string of 1s and 0s within single quote marks, e.g. ‘1000 0001’. Blanks within a bit string are for ease of reading and have no significance. |
| uimsbf | Unsigned integer, most significant bit first. |
The byte orderof multi-byte words is most significant byte first.
15. Constants
p 3.14159265359...
e 2.71828182845...
16. Method of Describing Bit Stream Syntax
Each data item in the coded bitstream described below is in bold type. It is described by its name, its lengthin bits, and a mnemonic for its type and order of transmission.
The action caused by a decoded dataelement in a bit stream depends on the value of that data element and on dataelements previously decoded. The decoding of the data elements and definitionof the state variables used in their decoding are described in the clausescontaining the semantic description of the syntax. The following constructs areused to express the conditions when data elements are present, and are innormal type.
Note thissyntax uses the “C” code convention that a variable or expression evaluating toa non-zero value is equivalent to a condition that is true.
| while ( condition ) { | If the condition is true, then the group of data elements occurs next in the data stream. This repeats until the condition is not true. |
| do { | The data element always occurs at least once. The data element is repeated until the condition is not true. |
| if ( condition) { | If the condition is true, then the first group of data elements occurs next in the data stream. |
| else { | If the condition is not true, then the second group of data elements occurs next in the data stream. |
| for (i = 0;i<n;i++) { | The group of data elements occurs n times. Conditional constructs within the group of data elements may depend on the value of the loop control variable i, which is set to zero for the first occurrence, incremented to 1 for the second occurrence, and so forth. |
As noted, the group of data elementsmay contain nested conditional constructs. For compactness, the {} are omittedwhen only one data element follows.
| data_element [ ] | data_element [ ] is an array of data. The number of data elements is indicated by the context. |
| data_element [n] | data_element [n] is the n+1th element of an array of data. |
| data_element [m] [n] | data_element [m] [n] is the m+1,n+1 th element of a two-dimensional array of data. |
| data_element [l] [m] [n] | data_element [l] [m] [n] is the l+1,m+1,n+1 th element of a three-dimensional array of data. |
| data_element [m..n] | data_element [m..n] is the inclusive range of bits between bit m and bit n in the data_element. |
Decoders mustinclude a means to look for start codes and sync bytes (transport stream) inorder to begin decoding correctly, and to identify errors, erasures orinsertions while decoding. The methods to identify these situations, and theactions to be taken, are not standardized.
17. Definition of bytealignedfunction
The function bytealigned( ) returns 1 if the current position is on a byte boundary; that is,the next bit in the bit stream is the first bit in a byte. Otherwise it returns0.
18. Definition of nextbits function
The function nextbits( ) permits comparison of a bit string with the next bits to be decodedin the bit stream.
19. Definition of next_start_codefunction
The next_start_code( ) functionremoves any zero bit and zero byte stuffing and locates the next start code.
Thisfunction checks whether the current position is byte-aligned. If it is not, 0stuffing bits are present. After that any number of 0 bytes may be presentbefore the start-code. Therefore start-codes are always byte-aligned and may bepreceded by any number of 0 stuffing bits.
| Syntax | No. of bits | Mnemonic |
| next_start_code( ) { |
|
|
| while ( !bytealigned( ) ) |
|
|
| zero_bit | 1 | ‘0’ |
| while (nextbits( )!=‘0000 0000 0000 0000 0000 0001’) |
|
|
| zero_byte | 8 | ‘00000000’ |
| } |
|
|
20. Background
The Advanced Television SystemsCommittee, chaired by James C. McKinney, was formed by the member organizationsof the Joint Committee on InterSociety Coordination (JCIC)[1]for the purpose of exploring the need for and, where appropriate, to coordinatedevelopment of the documentation of Advanced Television Systems. Documentationis understood to include voluntary technical standards, recommended practices,and engineering guidelines.
Proposed documentation may be developedby the ATSC, by member organizations of the JCIC, or by existing standardscommittees. The ATSC was established recognizing that the prompt, efficient andeffective development of a coordinated set of national standards is essentialto the future development of domestic television services.
On June 5, 1992, ATSC providedinformation to the Federal Communications Commission (FCC) outlining proposedindustry actions to fully document the advanced television system standard. TheFCC has recognized the importance of prompt disclosure of the system technicalspecifications to the mass production of advanced television system professionaland consumer equipment in a timely fashion. The FCC has further noted itsappreciation of the diligence with which the ATSC and the other groupsparticipating in the standardization are pursuing these matters.[2]
Supporting this activity, the ATSC ExecutiveCommittee requested that the T3/S1 Specialist Group on Macro Systems Approachmeet and suggest which portions of an advanced television system broadcastingstandard might require action by the FCC and which portions should bevoluntary.
Subsequently, T3/S1 held meetings anddeveloped recommendations in two areas:
0Principles upon which documentation of the advanced televisionsystem should be based
1A list of characteristics of an advanced television system thatshould be documented
The list tentatively identifiedthe industry group(s) that would provide the documentation information and thedocument where the information would likely appear.
The recommendations developed by theT3/S1 Specialist Group were modified by T3 to accommodate information and knowledgeabout advanced television systems developed in the period since June 1992. Someof the modifications to the recommendations ensued from the formation of theGrand Alliance. The modified guidelines were approved at the March 31, 1994,meeting of the T3 Technology Group on Distribution and are described in Section4.4.
21. Advisory Committee on Advanced Television Service (ACATS)
A “Petition for Notice of Inquiry”was filed with the FCC on February 21, 1987, by 58 broadcasting organizationsand companies requesting that the Commission initiate a proceeding to explorethe issues arising from the introduction of advanced television technologiesand their possible impact on the television broadcasting service. At that time,it was generally believed that high-definition television (HDTV) could not bebroadcast using 6 MHz terrestrial broadcasting channels. The broadcastingorganizations were concerned that alternative media would be able to deliverHDTV to the viewing public, placing terrestrial broadcasting at a severedisadvantage.
The FCC agreed that this was a subject ofutmost importance and initiated a proceeding (MM Docket No. 87-268) to considerthe technical and public policy issues of advanced television systems. TheAdvisory Committee on Advanced Television Service was empaneled by the FederalCommunications Commission in 1987, with Richard E. Wiley as chairman, todevelop information that would assist the FCC in establishing an advancedtelevision standard for the United States. The objective given to the AdvisoryCommittee in its Charter by the FCC was:
“The Committee will advise the FederalCommunications Commission on the facts and circumstances regarding advancedtelevision systems for Commission consideration of technical and public policyissues. In the event that the Commission decides that adoption of some form ofadvanced broadcast television is in the public interest, the Committee wouldalso recommend policies, standards, and regulations that would facilitate theorderly and timely introduction of advanced television services in the UnitedStates.”
The Advisory Committee established aseries of subgroups to study the various issues concerning services, technicalparameters, and testing mechanisms required to establish an advanced televisionsystem standard. The Advisory Committee also established a system evaluation,test, and analysis process that began with over twenty proposed systems,reducing them to four final systems for consideration.
22. Digital HDTV Grand Alliance (Grand Alliance)
On May 24, 1993, the three groupsthat had developed the four final digital systems agreed to produce a single,best-of-the best system to propose as the standard. The three groups (AT&Tand Zenith Electronics Corporation; General Instrument Corporation and the MassachusettsInstitute of Technology; and Philips Consumer Electronics, Thomson ConsumerElectronics, and the David Sarnoff Research Center) have been working togetheras the “Digital HDTV Grand Alliance.” The system described in this Standard isbased on the Digital HDTV Grand Alliance proposal to the Advisory Committee.
23. Organization for Documenting the Digital TelevisionStandard
The ATSC Executive Committeeassigned the work of documenting the advanced television system standards to T3specialist groups, dividing the work into five areas of interest:
0Video, including input signal format and source coding
1Audio, including input signal format and source coding
2Transport,including data multiplex and channel coding
3RF/Transmission, includingthe modulation subsystem
4Receiver characteristics
A steering committee consisting ofthe chairs of the five specialist groups, the chair and vice-chairs of T3, andliaison among the ATSC, the FCC, and ACATS was established to coordinate thedevelopment of the documents. The members of the steering committee and areasof interest were as follows:
Stanley Baron T3 chair
Jules Cohen T3vice-chair
Brian James T3 vice-chair
Larry Pearlstein T3/S6 (video systems characteristics),chair
Graham S. Stubbs T3/S7 (audio systems characteristics),chair
Bernard J. Lechner T3/S8 (service multiplex and transportsystems characteristics), chair
Lynn D. Claudy T3/S9 (RF/transmission systemscharacteristics), chair
Werner F. Wedam T3/S10 (receiver characteristics), chair
Robert M. Rast Grand Alliance facilitator
Robert Hopkins ATSC
Robert M. Bromery FCC Office of Engineering and Technology
Gordon Godfrey FCC Mass Media Bureau
Paul E. Misener ACATS
24. Principles for Documenting the Digital Television Standard
T3 adopted the followingprinciples for documenting the advanced television system standard:
0The Grand Alliance was recognized as the principal supplier ofinformation for documenting the advanced television system, supported by theATSC and others. Other organizations seen as suppliers of information were EIA,FCC, IEEE, MPEG, NCTA, and SMPTE.
1The Grand Alliance was encouraged to begin drafting the essentialelements of system details as soon as possible to avoid delays in producing theadvanced television system documentation.
2FCC requirements for the advanced television system standard were tobe obtained as soon as possible.
3Complete functional system details (permitting those skilled in theart to construct a working system) were to be made publicly available.
4Protection of any intellectual property made public must be bypatent or copyright as appropriate.
5The advanced television system documentation shall include thenecessary system information such that audio and video encoders may bemanufactured to deliver the system’s full demonstrated performance quality.
6The advanced television system documentation shall point to existingstandards, recommended practices, or guideline documents. These documents shallbe referenced in one of two ways as deemed appropriate for the application. Inthe first instance, a specific revision shall be specified where review ofchanges to the referenced document is required before changes might beincorporated into the advanced television system document. The second instancereferences the document without specificity to revision and allows any changesto the referenced documents to be automatically incorporated.
7System specifications shall explain how future, compatibleimprovements may be achieved.
8As ongoing improvements take place in the advanced television system,manufacturers of encoders and decoders should coordinate their efforts toinsure compatibility.
9The advanced television system standard must support backwardcompatibility of future improvements with all generations of advancedtelevision system receivers and inherently support production of low costreceivers (not withstanding that cost reduction through reduced performancequality may also be used to achieve inexpensive products).
10The advanced television system standard should not foreclose flexibilityin implementing advanced television system receivers at different price andperformance levels.
11The advanced television system standard should not forecloseflexibility in implementing program services or in data stream modification orinsertion of data packets by down-stream (local) service providers.
12The advanced television system documentation shall addressinteroperability with non-broadcast delivery systems including cable.
13The advanced television system standard shall identify criticalsystem parameters and shall provide information as to the range of acceptablevalues, the method of measurement, and the location in the system wheremeasurement takes place.
25. System overview
The Digital Television Standard describes a system designed totransmit high quality video and audio and ancillary data over a single 6 MHzchannel. The system can deliver reliably about 19 Mbps of throughput in a 6 MHzterrestrial broadcasting channel and about 38 Mbps of throughput in a 6 MHzcable television channel. This means that encoding a video source whoseresolution can be as high as five times that of conventional television (NTSC)resolution requires a bit rate reduction by a factor of 50 or higher. Toachieve this bit rate reduction, the system is designed to be efficient inutilizing available channel capacity by exploiting complex video and audiocompression technology.
The objective is to maximize the information passed through the datachannel by minimizing the amount of data required to represent the video image sequenceand its associated audio. The objective is to represent the video, audio, anddata sources with as few bits as possible while preserving the level of qualityrequired for the given application.
Although the RF/transmission subsystems described in this Standardare designed specifically for terrestrial and cable applications, the objectiveis that the video, audio, and service multiplex/transport subsystems be usefulin other applications.
26. System Block Diagram
A basic block diagramrepresentation of the system is shown in Figure 5.1. This representation isbased on one adopted by the International Telecommunication Union,Radiocommunication Sector (ITU-R), Task Group 11/3 (Digital TerrestrialTelevision Broadcasting). According to this model, the digital televisionsystem can be seen to consist of three subsystems.[3]
5Source coding and compression
6Service multiplex and transport
7RF/transmission
Figure5.1 ITU-R digital terrestrial television broadcasting model.
“Source coding and compression”refers to the bit rate reduction methods, also known as data compression,appropriate for application to the video, audio, and ancillary digital datastreams. The term “ancillary data” includes control data, conditional accesscontrol data, and data associated with the program audio and video services,such as closed captioning. “Ancillary data” can also refer to independentprogram services. The purpose of the coder is to minimize the number of bitsneeded to represent the audio and video information. The digital televisionsystem employs the MPEG-2 video stream syntax for the coding of video and theDigital Audio Compression (AC-3) Standard for the coding of audio.
“Service multiplex and transport” refersto the means of dividing the digital data stream into “packets” of information,the means of uniquely identifying each packet or packet type, and theappropriate methods of multiplexing video data stream packets, audio datastream packets, and ancillary data stream packets into a single data stream. Indeveloping the transport mechanism, interoperability among digital media, suchas terrestrial broadcasting, cable distribution, satellite distribution,recording media, and computer interfaces, was a prime consideration. Thedigital television system employs the MPEG-2 transport stream syntax for thepacketization and multiplexing of video, audio, and data signals for digitalbroadcasting systems.[4]The MPEG-2 transport stream syntax was developed for applications where channelbandwidth or recording media capacity is limited and the requirement for anefficient transport mechanism is paramount. It was designed also to facilitateinteroperability with the ATM transport mechanism.
“RF/transmission” refers to channelcoding and modulation. The channel coder takes the data bit stream and addsadditional information that can be used by the receiver to reconstruct the datafrom the received signal which, due to transmission impairments, may notaccurately represent the transmitted signal. The modulation (or physical layer)uses the digital data stream information to modulate the transmitted signal.The modulation subsystem offers two modes: a terrestrial broadcast mode (8VSB), and a high data rate mode (16 VSB).
Figure 5.2illustrates a high level view of encoding equipment. This view is not intendedto be complete, but is used to illustrate the relationship of various clockfrequencies within the encoder. There are two domains within the encoder wherea set of frequencies are related, the source coding domain and the channel codingdomain.
Figure 5.2 Highlevel view of encoding equipment.
The source coding domain, representedschematically by thevideo, audio, and transport encoders, uses a family of frequencies which arebased on a 27 MHz clock (f27MHz). This clock is used to generate a 42-bit sample of the frequencywhich is partitioned into two parts defined by the MPEG-2 specification. Theseare the 33-bit program_clock_reference_base and the 9-bit program_clock_reference_extension. The former is equivalent to a sample of a 90 kHz clock which islocked in frequency to the 27 MHz clock, and is used by the audio and videosource encoders when encoding the presentation time stamp (PTS) andthe decode time stamp (DTS). The audio and video sampling clocks, fa and fvrespectively, must be frequency-locked to the 27 MHz clock. This can beexpressed as the requirement that there exist two pairs of integers, (na, ma) and (nv,mv), such that:
and
The channel coding domain is representedby the FEC/Sync Insertion subsystem and the VSB modulator. The relevantfrequencies in this domain are the VSB symbol frequency (fsym)and the frequency of the transport stream (fTP) which is the frequencyof transmission of the encoded transport stream. These two frequencies must belocked, having the relation:
The signals in the two domains are notrequired to be frequency-locked to each other, and in many implementations willoperate asynchronously. In such systems, the frequency drift can necessitatethe occasional insertion or deletion of a null packet from within the transportstream, thereby accommodating the frequency disparity.
The annexes that follow consider thecharacteristics of the subsystems necessary to accommodate the servicesenvisioned.
Annex A:
Video System Characteristics (Normative)
1. Scope
27. References
28. Normative References
The following documents contain provisions which, through referencein this text, constitute provisions of this standard. At the time ofpublication, the editions indicated were valid. All standards are subject torevision, and parties to agreement based on this standard are encouraged toinvestigate the possibility of applying the most recent editions of thedocuments listed below.
ISO/IEC IS 13818-1, International Standard(1996), MPEG-2 Systems.
ISO/IEC 13818-1: 1996/Cor. 1: 1997 (E) Technical Corrigendum 1.
ISO/IEC 13818-1: 1996/Amd. 1: 1997 (E) Amendment 1.
ISO/IEC 13818-1: 1996/Amd. 2: 1997 (E) Amendment 2.
ISO/IEC 13818-1: 1996/Amd. 3: 1997 (E) Amendment 3.
ISO/IEC 13818-1: 1996/Amd. 4: 1997 (E) Amendment 4.
ISO/IEC IS 13818-2, International Standard (1996), MPEG-2 Video.
ISO/IEC 13818-2: 1996/Cor. 1: 1997 (E) MPEG-2 Video Technical Corrigendum 1.
ISO/IEC 13818-2: 1996/Cor. 2: 1997 (E) MPEG-2 Video Technical Corrigendum 2.
29. Informative References
SMPTE 274M (1995), Standard for Television, 1920 ´ 1080Scanning and Interface, Society of Motion Picture and Television Engineers,White Plains, N.Y.
SMPTE 296M (1997), Standard for Television, 1280 ´ 720Scanning, Analog and Digital Representation, and Analog Interface, Society ofMotion Picture and Television Engineers, White Plains, N.Y.
ITU-R BT.601-4 (1994), Encoding parameters of digital television forstudios.
30. Compliance notation
As used in this document, “shall” or “will” denotes a mandatoryprovision of the standard. “Should” denotes a provision that is recommended butnot mandatory. “May” denotes a feature whose presence does not precludecompliance, that may or may not be present at the option of the implementor.
31. Possible video inputs
While not required by this standard, there are certain televisionproduction standards, shown in Table A1, that define video formats that relateto compression formats specified by this standard.
TableA1 Standardized Video Input Formats
| Video Standard | Active Lines | Active Samples/ Line |
| SMPTE 274M | 1080 | 1920 |
| SMPTE 296M | 720 | 1280 |
| ITU-R BT.601-4 | 483 | 720 |
The compression formats may be derived from one or more appropriatevideo input formats. It may be anticipated that additional video productionstandards will be developed in the future that extend the number of possibleinput formats.
32. Source coding specification
The ATV video compressionalgorithm shall conform to the Main Profile syntax of ISO/IEC 13818-2,including Technical Corrigendum 1 and Technical Corrigendum 2. The allowableparameters shall be bounded by the upper limits specified for the Main Profileat High Level.[5] Additionally, ATV bit streams shallmeet the constraints and specifications described in Sections 5.1 and 5.2.
33. Constraints with Respect to ISO/IEC 13818-2 Main Profile
The following tables list theallowed values for each of the ISO/IEC 13818-2 syntactic elements which arerestricted beyond the limits imposed by MP@HL.
In these tables conventional numbersdenote decimal values, numbers preceded by 0xare to be interpreted as hexadecimal values and numbers within single quotes(e.g., ‘10010100’) are to be interpreted as a string of binary digits.
34. Sequence Header Constraints
Table A2 identifies parameters inthe sequence header of a bit stream that shall be constrained by the videosubsystem and lists the allowed values for each.
Table A2 Sequence HeaderConstraints
| Sequence Header Syntactic Element | Allowed Value |
| horizontal_size_value | see Table A3 |
| vertical_size_value | see Table A3 |
| aspect_ratio_information | see Table A3 |
| frame_rate_code | see Table A3 |
| bit_rate_value (£ 19.4 Mbps) | £ 48500 |
| bit_rate_value (£ 38.8 Mbps) | £ 97000 |
| vbv_buffer_size_value | £ 488 |
The allowablevalues for the field bit_rate_value are application-dependent. In the primary application of terrestrialbroadcast, this field shall correspond to a bit rate which is less than orequal to 19.4 Mbps. In the high data rate mode, the corresponding bit rate isless than or equal to 38.8 Mbps.
35. Compression Format Constraints
Table A3 lists the allowed compressionformats.
Table A3 CompressionFormat Constraints
| vertical_size_value | horizontal_size_value | aspect_ratio_information | frame_rate_code | progressive_sequence |
| 1080[6] | 1920 | 1,3 | 1,2,4,5 | 1 |
| 4,5 | 0 | |||
| 720 | 1280 | 1,3 | 1,2,4,5,7,8 | 1 |
| 1,2,4,5,7,8 | 1 | |||
| 480 | 704 | 2,3 | 4,5 | 0 |
| 640 | 1,2 | 1,2,4,5,7,8 | 1 | |
| 4,5 | 0 | |||
| Legend for MPEG-2 coded values: aspect_ratio_information: 1 = square samples, 2 = 4:3 display aspect ratio, 3 = 16:9 display aspect ratio frame_rate_code: 1 = 23.976 Hz, 2 = 24 Hz, 4 = 29.97 Hz, 5 = 30 Hz, 7 = 59.94 Hz, 8 = 60 Hz progressive_sequence: 0 = interlaced scan, 1 = progressive scan | ||||
36. Sequence Extension Constraints
Table A4 identifies parameters inthe sequence extension part of a bit stream that shall be constrained by thevideo subsystem and lists the allowed values for each. A sequence_extension structure is required to be present after every sequence_header structure.
Table A4 Sequence ExtensionConstraints
| Sequence Extension Syntactic Element | Allowed Values |
| progressive_sequence | see Table A3 |
| profile_and_level_indication | see Note |
| chroma_format | ‘01’ |
| horizontal_size_extension | ‘00’ |
| vertical_size_extension | ‘00’ |
| bit_rate_extension | ‘0000 0000 0000’ |
| vbv_buffer_size_extension | ‘0000 0000’ |
| frame_rate_extension_n | ‘00’ |
| frame_rate_extension_d | ‘0000 0’ |
Note:The profile_and_level_indication field shall indicate the lowest profile and level defined inISO/IEC 13818-2, Section 8, that is consistent with the parameters of the videoelementary stream.
37. Sequence Display Extension Constraints
Table A5 identifies parametersin the sequence display extension part of a bit stream that shall beconstrained by the video subsystem and lists the allowed values for each.
Table A5 Sequence Display Extension Constraints
| Sequence display extension syntactic element | Allowed values |
| video_format | ‘000’ |
The values for color_primaries, transfer_characteristics, and matrix_coefficients shall be explicitly indicated in the sequence_display_extension. Whileall values for color_primaries, transfer_characteristics, and matrix_coefficients defined in Tables 6-7, 6-8, and 6-9 of ISO/IEC 13818-2 are allowedin the transmitted bit stream, it is noted that ITU-R BT.709 and SMPTE 170M arethe most likely to be in common use.
Note: Somepreviously-encoded legacy material may not have the colorimetry (i.e., color_primaries, transfer_characteristics, and matrix_coefficients) explicitly indicated in the sequence_display_extension, in which case the colorimetry is most likely ITU-R BT.709 for allformats except those formats with vertical_size_value = 480,which are most likely to have colorimetry according to SMPTE 170M.
38. Picture Header Constraints
In all cases other than when vbv_delay has the value 0xFFFF, the value of vbv_delay shall beconstrained as follows:
vbv_delay = 45000
39. Picture Coding Constraints
frame_pred_frame_dct shall be '1' if progressive_frame is '1'
40. Bit Stream Specifications Beyond MPEG-2
This section covers the extensionand user data part of the video syntax. These data are inserted at thesequence, GOP, and picture level. The syntax used for the insertion of closedcaptioning in picture user data is described.[7]
41. Picture Extension and User DataSyntax
Table A6 describes the syntax usedfor picture extension and user data.
Table A6 Picture Extension and User Data Syntax
| Value | No. of Bits | Mnemonic |
| extension_and_user_data( 2 ) { |
|
|
| while ( ( nextbits( ) == extension_start_code ) || |
|
|
| if ( nextbits()== extension_start_code ) |
|
|
| extension_data( 2 ) |
|
|
| if (nextbits() == user_data_start_code) |
|
|
| user_data(2) |
|
|
| } |
|
|
| } |
|
|
42. Picture User Data Syntax
Table A7 describes the pictureuser data syntax. (See next page.)
Table A7 Picture User Data Syntax[8]
| Value | No. of Bits | Mnemonic |
| user_data( ) { |
|
|
| user_data_start_code | 32 | bslbf |
| ATSC_identifier | 32 | bslbf |
| user_data_type_code | 8 | uimsbf |
| if (user_data_type_code == ‘0x03’) { |
|
|
| process_em_data_flag | 1 | bslbf |
| process_cc_data_flag | 1 | bslbf |
| additional_data_flag | 1 | bslbf |
| cc_count | 5 | uimsbf |
| em_data | 8 | bslbf |
| for ( i=0 ; i < cc_count ; i++ ) { |
|
|
| marker_bits | 5 | ‘1111 1’ |
| cc_valid | 1 | bslbf |
| cc_type | 2 | bslbf |
| cc_data_1 | 8 | bslbf |
| cc_data_2 | 8 | bslbf |
| } |
|
|
| marker_bits | 8 | ‘1111 1111’ |
| if (additional_data_flag) { |
|
|
| while( nextbits() != ‘0000 0000 0000 0000 0000 0001’ ) { |
|
|
| additional_user_data | 8 |
|
| } |
|
|
| } |
|
|
| } else { |
|
|
| while ( nextbits() != ‘0000 0000 0000 0000 0000 0001’ ) { |
|
|
| ATSC_reserved_user_data | 8 |
|
| } |
|
|
| } |
|
|
| next_start_code() |
|
|
| } |
|
|
43. Picture User Data Semantics
user_data_start_code: This is set to 0x0000 01B2.
ATSC_identifier: This is a 32 bit code that indicates that the video user dataconforms to this specification. The value ATSC_identifier shall be0x4741 3934.
user_data_type_code: The 8-bit code is set to 0x03 for EIA advanced television closed captioning.All other values are reserved for use by ATSC.
process_em_data_flag: This flag is set to indicate whether it is necessary to process theem_data. If it is set to 1, the em_data has to be parsed andits meaning has to be processed. When it is set to 0, the em_datacan be discarded.
process_cc_data_flag: This flag is set to indicate whether it is necessary to process thecc_data. If it is set to 1, the cc_data has to be parsed andits meaning has to be processed. When it is set to 0, the cc_datacan be discarded.
additional_data_flag: This flag is set to 1 to indicate the presence of additional userdata.
cc_count: This 5-bit integer indicates the number of closed captionconstructs following this field. It can have values 0 through 31. The value of cc_countshall be set according to the frame rate and coded picture structure (field orframe) such that a fixed bandwidth of 9600 bits per second is maintained forthe closed caption payload data. Sixteen (16) bits of closed caption payloaddata are carried in each pair of the fields cc_data_1 and cc_data_2.
em_data: Eight bits for representing emergency message.[9]
cc_valid: This flag is set to ‘1’ to indicate that the two closed captiondata bytes that follow are valid. If set to ‘0’ the two data bytes are invalid.
cc_type: Denotes the type of the two closed caption data bytes that follow.[10]
cc_data_1: The first byte of a closed caption data pair.
cc_data_2: The second byte of a closed caption data pair.
additional_user_data: Any further demand for picture user data could be met by definingthis part of the bit stream.
ATSC_reserved_user_data: Reserved for future use by ATSC.
Annex B:
Audio System Characteristics (Normative)
2. Scope
This Annex describes the audiosystem characteristics and normative specifications of the Digital TelevisionStandard.
44. Normative references
The following documents containprovisions which in whole or part, through reference in this text, constituteprovisions of this standard. At the time of publication, the editions indicatedwere valid. All standards are subject to revision and amendment, and parties toagreement based on this standard are encouraged to investigate the possibilityof applying the most recent editions of the documents listed below.
ATSC Standard A/52A (2001), DigitalAudio Compression (AC-3).
AES 3-1992 (ANSI S4.40-1992), AESRecommended Practice for digital audio engineering—Serial transmission formatfor two-channel linearly represented digital audio data.
ANSI S1.4-1983, Specification forSound Level Meters.
IEC 651 (1979), Sound LevelMeters.
IEC 804 (1985), Amendment 1 (1989)Integrating/Averaging Sound Level Meters.
45. Compliance notation
As used in this document, “shall”or “will” denotes a mandatory provision of the standard. “Should” denotes aprovision that is recommended but not mandatory. “May” denotes a feature whosepresence does not preclude compliance, that may or may not be present at theoption of the implementor.
46. System overview
Asillustrated in Figure B1, the audio subsystem comprises the audio encoding/decodingfunction and resides between the audio inputs/outputs and the transportsubsystem. The audio encoder(s) is (are) responsible for generating the audioelementary stream(s) which are encoded representations of the baseband audioinput signals. At the receiver, the audio subsystem is responsible for decodingthe audio elementary stream(s) back into baseband audio.
Figure B1 Audiosubsystem in the digital television system.
47. Specification
This Section forms the normativespecification of the audio system. The audio compression system conforms withthe Digital Audio Compression (AC-3) Standard, subject to the constraintsoutlined in this Section.
48. Constraints With Respect to ATSC Standard A/52A
The digital television audiocoding system is based on the Digital Audio Compression (AC-3) Standardspecified in the body of ATSC Doc. A/52A (the non-normative annexes are notincluded). Constraints on the system are shown in Table B1, which showspermitted values of certain syntactical elements. These constraints aredescribed in Sections 5.2–5.4. The receive audio buffer is specified in Section5.7.
| AC-3 Syntactical Element | Comment | Allowed value |
| fscod | Indicates sampling rate | ‘00’ (indicates 48 kHz) |
| frmsizecod | Main audio service or associated audio service containing all necessary program elements | £ ’011110’ (indicates £ 448 kb/s) |
| frmsizecod | Single channel associated service containing a single program element | £ ‘010000’ (indicates £ 128 kbps) |
| frmsizecod | Two channel dialogue associated service | £ ‘010100’ (indicates £ 192 kbps) |
| (frmsizecod) | Combined bit rate of a main and an associated service intended to be simultaneously decoded | (total £ 576 kbps) |
| acmod | Indicates number of channels | ³ ‘001’ |
49. Sampling Frequency
The system conveys digital audiosampled at a frequency of 48 kHz, locked to the 27 MHz system clock. The 48 kHzaudio sampling clock is defined as:
48 kHz audio sample rate = ( 2 ¸1125 ) ´ ( 27 MHz system clock )
If analog signal inputs are employed, theA/D converters should sample at 48 kHz. If digital inputs are employed, theinput sampling rate shall be 48 kHz, or the audio encoder shall containsampling rate converters which convert the sampling rate to 48 kHz.
50. Bit Rate
A main audio service, or anassociated audio service which is a complete service (containing all necessaryprogram elements) shall be encoded at a bit rate less than or equal to 448kbps. A single channel associated service containing a single program elementshall be encoded at a bit rate less than or equal to 128 kbps. A two channelassociated service containing only dialogue shall be encoded at a bit rate lessthan or equal to 192 kbps. The combined bit rate of a main service and anassociated service which are intended to be decoded simultaneously shall beless than or equal to 576 kbps.
51. Audio Coding Modes
Audio services shall be encodedusing any of the audio coding modes specified in A/52, with the exception ofthe 1+1 mode. The value of acmod in the AC-3 bit stream shall have a value in the range of 1–7, withthe value 0 prohibited.
52. Dialogue Level
The value of the dialnormparameter in the AC-3 elementary bit stream shall indicate the level of averagespoken dialogue within the encoded audio program. Dialogue level may bemeasured by means of an “A” weighted integrated measurement (LAeq).(Receivers use the value of dialnorm to adjust the reproduced audio level so as to normalize thedialogue level.)
53. Dynamic Range Compression
Each encoded audio block maycontain a dynamic range control word (dynrng) that is used bydecoders (by default) to alter the level of the reproduced audio. The controlwords allow the decoded signal level to be increased or decreased by up to 24dB. In general, elementary streams may have dynamic range control wordsinserted or modified without affecting the encoded audio. When it is necessaryto alter the dynamic range of audio programs which are broadcast, the dynamicrange control word should be used.
54. STD Audio Buffer Size
The main audio buffer (BSn, seeA/52 Annex A) shall be 2592 bytes.
55. Main and associated services
An AC-3 elementary stream containsthe encoded representation of a single audio service. Multiple audio servicesare provided by multiple elementary streams. Each elementary stream is conveyedby the transport multiplex with a unique PID. There are a number ofaudio service types which may (individually) be coded into each elementarystream. Each AC-3 elementary stream is tagged as to its service type using the bsmodbit field. There are two types of mainservice and six types of associated service. Each associated service may be tagged (in the AC-3 audiodescriptor in the transport PSI data) as being associated with one or more main audio services.Each AC-3 elementary stream may also be tagged with a language code.
Associated services may contain completeprogram mixes, or may contain only a single program element. Associatedservices which are complete mixes may be decoded and used as is. They areidentified by the full_svc bit in the AC-3 descriptor (see A/52A, Annex A). Associatedservices which contain only a single program element are intended to becombined with the program elements from a main audio service.
This section specifies the meaning anduse of each type of service. In general, a complete audio program (what ispresented to the listener over the set of loudspeakers) may consist of a mainaudio service, an associated audio service that is a complete mix, or a mainaudio service combined with an associated audio service. The capability tosimultaneously decode one main service and one associated service is requiredin order to form a complete audio program in certain service combinationsdescribed in this section. This capability may not exist in some receivers.
56. Summary of Service Types
The audio service types are listedin Table B2.
Table B2 Audio Service Types
| bsmod | Type of Service |
| 000 (0) | Main audio service: complete main (CM) |
| 001 (1) | Main audio service: music and effects (ME) |
| 010 (2) | Associated service: visually impaired (VI) |
| 011 (3) | Associated service: hearing impaired (HI) |
| 100 (4) | Associated service: dialogue (D) |
| 101 (5) | Associated service: commentary (C) |
| 110 (6) | Associated service: emergency (E) |
| 111 (7) | Associated service: voice-over (VO) |
57. Complete Main Audio Service (CM)
The CM type of main audio servicecontains a complete audio program (complete with dialogue, music, and effects).This is the type of audio service normally provided. The CM service may containfrom 1 to 5.1 audio channels. The CM service may be further enhanced by means ofthe VI, HI, C, E, or VO associated services described below. Audio in multiplelanguages may be provided by supplying multiple CM services, each in adifferent language.
58. Main Audio Service, Music and Effects (ME)
The ME type of main audio servicecontains the music and effects of an audio program, but not the dialogue forthe program. The ME service may contain from 1 to 5.1 audio channels. Theprimary program dialogue is missing and (if any exists) is supplied bysimultaneously encoding a D associated service. Multiple D associated servicesin different languages may be associated with a single ME service.
59. Visually Impaired (VI)
The VI associated servicetypically contains a narrative description of the visual program content. Inthis case, the VI service shall be a single audio channel. The simultaneousreproduction of both the VI associated service and the CM main audio serviceallows the visually impaired user to enjoy the main multi-channel audioprogram, as well as to follow (by ear) the on-screen activity.
The dynamic range control signal in thistype of VI service is intended to be used by the audio decoder to modify thelevel of the main audio program. Thus the level of the main audio service willbe under the control of the VI service provider, and the provider may signalthe decoder (by altering the dynamic range control words embedded in the VIaudio elementary stream) to reduce the level of the main audio service by up to24 dB in order to assure that the narrative description is intelligible.
Besides providing the VI service as asingle narrative channel, the VI service may be provided as a complete programmix containing music, effects, dialogue, and the narration. In this case, theservice may be coded using any number of channels (up to 5.1), and the dynamicrange control signal applies only to this service. The fact that the service isa complete mix shall be indicated in the AC-3 descriptor (see A/52A, Annex A).
60. Hearing Impaired (HI)
The HI associated servicetypically contains only dialogue which is intended to be reproducedsimultaneously with the CM service. In this case, the HI service shall be asingle audio channel. This dialogue may have been processed for improvedintelligibility by hearing impaired listeners. Simultaneous reproduction ofboth the CM and HI services allows the hearing impaired listener to hear a mixof the CM and HI services in order to emphasize the dialogue while stillproviding some music and effects.
Besides providing the HI service as asingle dialogue channel, the HI service may be provided as a complete programmix containing music, effects, and dialogue with enhanced intelligibility. Inthis case, the service may be coded using any number of channels (up to 5.1).The fact that the service is a complete mix shall be indicated in the AC-3descriptor (see A/52A, Annex A).
61. Dialogue (D)
The D associated service containsprogram dialogue intended for use with an ME main audio service. The languageof the D service is indicated in the AC-3 bit stream, and in the audio descriptor.A complete audio program is formed by simultaneously decoding the D service andthe ME service and mixing the D service into the center channel of the ME mainservice (with which it is associated).
If the ME main audio service containsmore than two audio channels, the D service shall be monophonic (1/0 mode). Ifthe main audio service contains two channels, the D service may also containtwo channels (2/0 mode). In this case, a complete audio program is formed bysimultaneously decoding the D service and the ME service, mixing the leftchannel of the ME service with the left channel of the D service, and mixingthe right channel of the ME service with the right channel of the D service.The result will be a two channel stereo signal containing music, effects, anddialogue.
Audio in multiple languages may beprovided by supplying multiple D services (each in a different language) alongwith a single ME service. This is more efficient than providing multiple CMservices, but, in the case of more than two audio channels in the ME service,requires that dialogue be restricted to the center channel.
Some receivers may not have thecapability to simultaneously decode an ME and a D service.
62. Commentary (C)
The commentary associated serviceis similar to the D service, except that instead of conveying essential programdialogue, the C service conveys optional program commentary. The C service maybe a single audio channel containing only the commentary content. In this case,simultaneous reproduction of a C service and a CM service will allow thelistener to hear the added program commentary.
The dynamic range control signal in thesingle channel C service is intended to be used by the audio decoder to modifythe level of the main audio program. Thus the level of the main audio servicewill be under the control of the C service provider, and the provider maysignal the decoder (by altering the dynamic range control words embedded in theC audio elementary stream) to reduce the level of the main audio service by upto 24 dB in order to assure that the commentary is intelligible.
Besides providing the C service as asingle commentary channel, the C service may be provided as a complete programmix containing music, effects, dialogue, and the commentary. In this case theservice may be provided using any number of channels (up to 5.1). The fact thatthe service is a complete mix shall be indicated in the AC-3 descriptor (seeA/52A, Annex A).
63. Emergency (E)
The E associated service isintended to allow the insertion of emergency or high priority announcements.The E service is always a single audio channel. An E service is given priorityin transport and in audio decoding. Whenever the E service is present, it willbe delivered to the audio decoder. Whenever the audio decoder receives an Etype associated service, it will stop reproducing any main service beingreceived and only reproduce the E service out of the center channel (or leftand right channels if a center loudspeaker does not exits). The E service mayalso be used for non-emergency applications. It may be used whenever thebroadcaster wishes to force all decoders to quit reproducing the main audioprogram and reproduce a higher priority single audio channel.
64. Voice-Over (V0)
The VO associated service is asingle channel service intended to be reproduced along with the main audioservice in the receiver. It allows typical voice-overs to be added to analready encoded audio elementary stream without requiring the audio to bedecoded back to baseband and then re-encoded. It is always a single audiochannel. It has second priority (only the E service has higher priority). It isintended to be simultaneously decoded and mixed into the center channel of themain audio service. The dynamic range control signal in the VO service isintended to be used by the audio decoder to modify the level of the main audioprogram. Thus the level of the main audio service may be controlled by thebroadcaster, and the broadcaster may signal the decoder (by altering thedynamic range control words embedded in the VO audio elementary stream) toreduce the level of the main audio service by up to 24 dB during thevoice-over.
Some receivers may not have thecapability to simultaneously decode and reproduce a voice-over service alongwith a program audio service.
65. Audio encoder interfaces
66. Audio Encoder Input Characteristics
Audio signals which are input tothe digital television system may be in analog or digital form. Audio signalsshould have any dc offset removed before being encoded. If the audio encoderdoes not include a dc blocking high-pass filter, the audio signals should behigh-pass-filtered before being applied to the encoder. In general, inputsignals should be quantized to at least 16-bit resolution. The audiocompression system can convey audio signals with up to 24-bit resolution.Physical interfaces for the audio inputs to the encoder may be defined asvoluntary industry standards by the AES, SMPTE, or other standardsorganizations.
67. Audio Encoder Output Characteristics
Conceptually, the output of theaudio encoder is an elementary stream which is formed into PESpackets within the transport subsystem. It is possible that systems will beimplemented wherein the formation of audio PES packets takes placewithin the audio encoder. In this case, the output(s) of the audio encoder(s)would be PES packets. Physical interfaces for these outputs (elementary streamsand/or PES packets) may be defined as voluntary industry standards by SMPTE orother standards organizations.
Annex C:
Service Multiplex and Transport System Characteristics (Normative)
3. Scope
This Annex describes the transportlayer characteristics and normative specifications of the Digital TelevisionStandard.
68. Normative references
The following documents containprovisions which in whole or in part, through reference in this text,constitute provisions of this Standard. At the time of publication, theeditions indicated were valid. All standards are subject to revision andamendment, and parties to agreements based on this Standard are encouraged toinvestigate the possibility of applying the most recent editions of thedocuments listed below.
ATSC Standard A/52 (1995), DigitalAudio Compression (AC-3).
ATSC Standard A/65 (1997), Programand System Information Protocol for Terrestrial Broadcast and Cable.
ISO/IEC IS 13818-1, InternationalStandard (1996), MPEG-2 Systems.
ISO/IEC 13818-1: 1996/Cor. 1: 1997(E) Technical Corrigendum 1.
ISO/IEC 13818-1: 1996/Amd. 1: 1997(E) Amendment 1.
ISO/IEC 13818-1: 1996/Amd. 2: 1997(E) Amendment 2.
ISO/IEC 13818-1: 1996/Amd. 3: 1997(E) Amendment 3.
ISO/IEC13818-1: 1996/Amd. 4: 1997 (E) Amendment 4.
ISO/IEC IS 13818-2, InternationalStandard (1996), MPEG-2 Video.
ISO/IEC13818-2: 1996/Cor. 1: 1997 (E) MPEG-2 Video Technical Corrigendum 1.
ISO/IEC13818-2: 1996/Cor. 2: 1997 (E) MPEG-2 Video Technical Corrigendum 2.
ISO/IEC CD 13818-4, MPEG CommitteeDraft (1994), MPEG-2 Compliance.
69. Compliance notation
As used in this document, “shall”or “will” denotes a mandatory provision of the standard. “Should” denotes aprovision that is recommended but not mandatory. “May” denotes a feature whosepresence does not preclude compliance, that may or may not be present at theoption of the implementor.
70. System overview
The transport format and protocolfor the Digital Television Standard is a compatible subset of the MPEG-2Systems specification defined in ISO/IEC 13818-1. It is based on a fixed-lengthpacket transport stream approach which has been defined and optimized fordigital television delivery applications.
Asillustrated in Figure C1, the transport function resides between theapplication (e.g., audio or video) encoding and decoding functions and thetransmission subsystem. The encoder’s transport subsystem is responsible forformatting the coded elementary streams and multiplexing the differentcomponents of the program for transmission. At the receiver, it is responsiblefor recovering the elementary streams for the individual application decodersand for the corresponding error signaling. The transport subsystem alsoincorporates other higher protocol layer functionality related tosynchronization of the receiver.
Figure C1Sample organization of functionality in a transmitter-receiver pair for asingle program.
The overall system multiplexing approachcan be thought of as a combination of multiplexing at two different layers. Inthe first layer, single program transport bit streams are formed bymultiplexing transport packets from one or more Packetized Elementary Stream (PES)sources. In the second layer, many single program transport bit streams arecombined to form a system of programs. The Program Specific Information (PSI)streams contain the information relating to the identification of programs andthe components of each program.
Not shown explicitly in Figure C1, butessential to the practical implementation of this Standard, is a control systemthat manages the transfer and processing of the elementary streams from theapplication encoders. The rules followed by this control system are not a partof this Standard but must be established as recommended practices by the usersof the Standard. The control system implementation shall adhere to therequirements of the MPEG-2 transport system as specified in ISO/IEC 13818-1with the additional constraints specified in this Standard. These constraintsmay go beyond the constraints imposed by the application encoders.
71. Specification
This section constitutes thenormative specification for the transport system of the Digital TelevisionStandard. The syntax and semantics of the specification conform to ISO/IEC13818-1 subject to the constraints and conditions specified in this Standard.This section of the Standard describes the coding constraints that apply to theuse of the MPEG-2 systems specification in the digital television system.
72. MPEG-2 Systems Standard
The transport system is based onthe transport stream definition of the MPEG-2 Systems standard as specified inISO/IEC 13818-1.
73. Video T-STD
The video T-STD is specified inSection 2.4.2.3 of ISO/IEC 13818-1 and follows the constraints for the levelencoded in the video elementary stream.
74. Audio T-STD
The audio T-STD is specified inSection 3.6 of Annex A of ATSC Standard A/52.
75. Registration Descriptor
This Standard uses theregistration descriptor described in Section 2.6.8 of ISO/IEC 13818-1 toidentify the contents of programs and elementary streams to decoding equipment.
76. Program Identifier
Programs which conform to thisspecification will be identified by the 32-bit identifier in the section of theProgram Map Table (PMT) detailed in Section 2.4.4.8 of ISO/IEC 13818-1. The identifierwill be coded according to Section 2.6.8, and shall have a value of 0x47413934.
77. Audio Elementary StreamIdentifier
Audio elementary streams whichconform to this specification will be identified by the 32-bit identifier inthe section of the Program Map Table (PMT) detailed in Section2.4.4.8 of ISO/IEC 13818-1. The identifier will be coded according to Section2.6.8, and shall have a value of 0x4143 2D33.
78. Audio Constraints
If a program contains an audiocomponent, the primary audio shall be a complete main audio service (CM) asdefined by ATSC Standard A/52 and shall contain the complete primary audio ofthe program including all required voice-overs and emergency messages.
79. Constraints on PSI
The program constituents for allprograms are described in the PSI. There are the following constraints on the PSIinformation:
8Only one program is described in a PSI transport bit streamcorresponding to a particular PMT_PID value. For terrestrial broadcast applications, a transport bitstream containing a program_map_table shall not be used to transmit any other kind of PSItable (identified by a different table_id).
9The maximum spacing between occurrences of a program_map_table containing television program information shall be 400 ms.
10The program numbers are associated with the corresponding PMT_PIDsin the PID0 Program Association Table. The maximum spacing between occurrencesof section 0 of the program_association_table is 100 ms.
11The video elementary stream section shall contain the Data streamalignment descriptor described in Section 2.6.10 of ISO/IEC 13818-1. The alignment_type field shown in Table 2-47 of ISO/IEC 13818-1 shall be 0x02.
12Adaptation headers shall not occur in transport packets of the PMT_PIDfor purposes other than for signaling with the discontinuity_indictor thatthe version_number (Section 2.4.4.5 of ISO/IEC 13818-1) may be discontinuous.
13Adaptation headers shall not occur in transport packets of the PAT_PID forpurposes other than for signaling with the discontinuity_indicator thatthe version_number (Section 2.4.4.5 of ISO/IEC 13818-1) may be discontinuous.
80. PES Constraints
Packetized Elementary Streamsyntax and semantics shall be used to encapsulate the audio and videoelementary stream information. The Packetized Elementary Stream syntax is usedto convey the Presentation Time-Stamp (PTS) and Decoding Time-Stamp(DTS) information required for decoding audio and video information withsynchronism. This section describes the coding constraints for this systemlayer.
Within the PES packet header, thefollowing restrictions apply:
14PES_scrambling_control shall be coded as ‘00’.
15ESCR_flag shall be coded as ‘0’.
16ES_rate_flag shall be coded as ‘0’.
17PES_CRC_flag shall be coded as ‘0’.
Within the PES packet extension, thefollowing restrictions apply.
18PES_private_data_flag shall be coded as ‘0’.
19pack_header_field_flag shall be coded as ‘0’.
20program_packet_sequence_counter_flag shall be coded as ‘0’.
21P-STD_buffer_flag shall be coded as ‘0’.
81. Video PES Constraints
Each PES packet shall begin with avideo access unit, as defined in Section 2.1.1 of ISO/IEC 13818-1, which isaligned with the PES packet header. The first byte of a PES packet payload shall bethe first byte of a video access unit. Each PES header shall contain a PTS.Additionally, it shall contain a DTS as appropriate. For terrestrial broadcast, the PESpacket shall not contain more than one coded video frame, and shall be void ofvideo picture data only when transmitted in conjunction with the discontinuity_indicator to signal that the continuity_counter may be discontinuous.
Within the PES packet header, thefollowing restrictions apply:
22The PES_packet_length shall be coded as ‘0x0000’
23data_alignment_indicator shall be coded as ‘1’
82. Audio PES Constraints
The audio decoder may becapable of simultaneously decoding more than one elementary stream containingdifferent program elements, and then combining the program elements into acomplete program. In this case, the audio decoder may sequentially decode audioframes (or audio blocks) from each elementary stream and do the combining(mixing together) on a frame or (block) basis. In order to have the audio fromthe two elementary streams reproduced in exact sample synchronism, it isnecessary for the original audio elementary stream encoders to have encoded thetwo audio program elements frame synchronously; i.e., if audio program 1 hassample 0 of frame n at time t0, then audio program 2 should alsohave frame n beginning with itssample 0 at the identical time t0. Ifthe encoding is done frame synchronously, then matching audio frames shouldhave identical values of PTS.
If PESpackets from two audio services that are to be decoded simultaneously containidentical values of PTS then the corresponding encoded audio frames contained in the PESpackets should be presented to the audio decoder for simultaneous synchronousdecoding. If the PTS values do not match (indicating that the audio encoding was notframe synchronous) then the audio frames which are closest in time may bepresented to the audio decoder for simultaneous decoding. In this case, the twoservices may be reproduced out of sync by as much as 1/2 of a frame time (whichis often satisfactory, e.g., a voice-over does not require precise timing).
The value of stream_id for AC-3 shall be 1011 1101 (private_stream_1).
83. Services and Features
84. System Information and ProgramGuide
85. System information and programguide PID
Compliant Transport Streams shallinclude system information and program guide data formatted according to thestructure and syntax described in ATSC Standard A/65, “Program and SystemInformation Protocol for Terrestrial Broadcast and Cable.” System informationand program guide data shall be conveyed in Transport Stream packets of PID0x1FFB, which shall be reserved exclusively for this purpose. Systeminformation provides data necessary for navigation among digital serviceofferings. The program guide database allows a receiver to build an on-screen gridof program information for the various services that may be available.
86. System information and programguide STD model
The STD model for program guideand system information is specified in ATSC Standard A/65A.
87. Specification of Private DataServices
Private data provides a means toadd new ancillary services to the basic digital television service specified inthis standard. Private data is supported in two bit stream locations.
1) Private data can be transmittedwithin the adaptation header of transport packets (Sections 2.4.3.4 and 2.4.3.5of ISO/IEC 13818-1).
2Private data can be transmitted as a separate transport stream withits own PID. The contents can be identified as being ATSC private by using the private_data_indicator_descriptor (Section 2.6.29 of ISO/IEC 13818-1) within the PMT.
In either case, it is necessary that thestandards which specify the characteristics of such private_streams be consistent with the Digital Television Standard. Standards for private_streams shall precisely specify the semantics of the transmitted syntax asdescribed in Sections 5.6.2.1 and 5.6.2.1.1.
88. Verification model
The standard shall be specified interms of a verification model by defining the characteristics of thetransmitted syntax and an idealized decoder. In ISO/IEC 13818-1 and 13818-2,this is accomplished by using the T-STD and VBV models, respectively. Theelements required for specification by this Standard are described in thefollowing Sections.
89. Syntax and semantics
The syntax and semantics of thetransmitted bit stream that implements the ancillary service shall becompletely and unambiguously specified. The decoding process shall also becompletely and unambiguously specified.
90. Ancillary service targetdecoder (ASTD)
An idealized decoder model must beprecisely defined for the service. Figure C2 introduces a concrete model forpedagogic purposes. It is modeled after the T-STD.
The salientfeatures of the model are the size of the transport demultiplexing buffer (TB),the minimum transfer rate out of the transport demultiplex buffer (Rleak),the required System buffering (BSsys), and optionally thepartitioning of BSsys between the smoothing portion and the decoderportion. The decoding process, represented as the decoding times T_decode(i), must be completely specified. The behavior of the BSsysbuffer must be completely modeled with respect to its input process and itsoutput process. Certain parameters of the service such as bit rate, etc.,should also be specified.
Figure C2 Ancillary service target decoder.
91. Stream type and PMT descriptors
A new ancillary service shall be described as a program orelementary stream through documented Program Specific Information.
92. Stream type
Several identifiers that are partof the transport section of the Digital Television Standard may be used toidentify either the signal or constituent parts thereof; however, thefundamental identifier is the User Private stream type. The stream_type codes shall be unambiguously assigned within the range 0x80 to0xAF. 0x81 has already been assigned within the Digital Television Standard(see Section 5.7.1).
93. PMT descriptors
The Ancillary Servicespecification shall include all pertinent descriptors that are found within theProgram Map Table. Specifically, it is recommended that either the private_data_indicator_descriptor or the registration_descriptor, or both, be included. Although this is not required for a streamwith a uniquestream_type code within this Standard, it willenhance interoperability in the case where the stream is stored outside thisStandard, or transmitted in some other network that has its own set of stream_type codes.
94. Assignment of Identifiers
In this section, those Identifiersand codes that shall have a fixed value are summarized. These include PESStream IDs and Descriptors. Stream_type codes from 0x80 to 0xAF shall be reserved for assignment as neededwithin the Digital Television Standard. Descriptor_tag codes from0x40 to 0xAF shall be reserved for assignment as needed within the DigitalTelevision Standard.
95. Stream Type
The AC-3 audio stream_type shall have the value 0x81.
96. Descriptors
97. AC-3 audio descriptor
In the digital television systemthe AC-3 audio descriptor shall be included in the TS_program_map_section. Thesyntax is given in Table C2 of Annex A of ATSC Standard A/52. There are thefollowing constraints on the AC-3 audio descriptor:
24The value of the descriptor_tag shall be 0x81.
25If textlen exists, it shall have a value of ‘0x00’.
98. Program smoothing bufferdescriptor
The Program Map Table of eachprogram shall contain a smoothing buffer descriptor pertaining to that programin accordance with Section 2.6.30 of ISO/IEC 13818-1. During the continuousexistence of a program, the value of the elements of the smoothing bufferdescriptor shall not change.
The fields of the smoothing bufferdescriptor shall meet the following constraints:
26The field sb_leak_rate shall be allowed to range up to the maximum transport ratesspecified in Section 7.2.
27The field sb_size shall have a value less than or equal to 2048. The size of thesmoothing buffer is thus £ 2048bytes.
99. Extensions to the MPEG-2 Systems Specification
This Section covers extensions tothe MPEG-2 Systems specification.
100.ScramblingControl
The scrambling control fieldwithin the packet header allows all states to exist in the digital televisionsystem as defined in Table C1.
Table C1 Transport ScramblingControl Field
| transport_scrambling_ | Function |
| 00 | packet payload not scrambled |
| 01 | not scrambled, state may be used as a flag for private use defined by the service provider. |
| 10 | packet payload scrambled with “even” key |
| 11 | packet payload scrambled with “odd” key |
ElementaryStreams for which the transport_scrambling_control field does not exclusively have the value of ‘00’ for the durationof the program, must carry a CA_descriptor in accordance with Section 2.6.16 of ISO/IEC 13818-1.
The implementation of a digitaltelevision delivery system that employs conditional access will require thespecification of additional data streams and system constraints.
101.Featuresof 13818-1 not supported by this Standard
The transport definition is basedon the MPEG-2 Systems standard, ISO/IEC 13818-1; however, it does not implementall parts of the standard. This section describes those elements which areomitted from this Standard.
102.ProgramStreams
This Standard does not includethose portions of ISO/IEC 13818-1 and Annex A of ATSC Standard A/52 whichpertain exclusively to Program Stream specifications.
103.StillPictures
This Standard does not includethose portions of ISO/IEC 13818-1 Transport Stream specification which pertainto the Still Picture model.
104.Transportencoder interfaces and bit rates
105.TransportEncoder Input Characteristics
The MPEG-2 Systems standardspecifies the inputs to the transport system as MPEG-2 elementary streams. Itis also possible that systems will be implemented wherein the process offorming PES packets takes place within the video, audio, or other dataencoders. In such cases, the inputs to the Transport system would be PESpackets. Physical interfaces for these inputs (elementary streams and/or PESpackets) may be defined as voluntary industry standards by SMPTE or otherstandardizing organizations.
106.TransportOutput Characteristics
Conceptually, the output from thetransport system is a continuous MPEG-2 transport stream as defined in thisAnnex at a constant rate of TrMbps when transmitted in an 8 VSB system and 2Tr when transmitted in a 16 VSB system where:
and
is the symbol rate Sr in Msymbols per second forthe transmission subsystem (see Section 4 of Annex D). Tr and Srshall be locked to each other in frequency.
All transport streams conforming to thisStandard shall conform to the ISO/IEC 13818-1 model.
Details of the interface for this output,including its physical characteristics, may be defined as a voluntary industrystandard by SMPTE , or other standardizing organizations.
Annex D:
RF/Transmission System Characteristics (Normative)
4. Scope
This Annex describes thecharacteristics of the RF/transmission subsystem, which is referred to as theVSB subsystem, of the Digital Television Standard. The VSB subsystem offers twomodes: a terrestrial broadcast mode (8 VSB), and a high data rate mode (16VSB). These are described in separate sections of this document.
107.NormativereferencesE
There are no normative references.
108.Compliancenotation
As used in this document, “shall”or “will” denotes a mandatory provision of the standard. “Should” denotes aprovision that is recommended but not mandatory. “May” denotes a feature whosepresence does not preclude compliance, that may or may not be present at theoption of the implementor.
109.Transmissioncharacteristics for terrestrial broadcast
The terrestrial broadcast mode(known as 8 VSB) will support a payload data rate of 19.28... Mbps in a 6 MHzchannel. A functional block diagram of a representative 8 VSB terrestrialbroadcast transmitter is shown in Figure D1. The input to the transmissionsubsystem from the transport subsystem is a 19.39... Mbps serial data streamcomprised of 188-byte MPEG-compatible data packets (including a sync byte and187 bytes of data which represent a payload data rate of 19.28... Mbps).
The incomingdata is randomized and then processed for forwarderror correction (FEC) in the form of Reed-Solomon (RS) coding (20 RSparity bytes are added to each packet), 1/6 data field interleaving and 2/3rate trellis coding. The randomization and FEC processes are not applied to thesync byte of the transport packet, which is represented in transmission by aData Segment Sync signal as described below. Following randomization andforward error correction processing, the data packets are formatted into DataFrames for transmission and Data Segment Sync and Data Field Sync are added.
Figure D1 VSB transmitter.
Figure D2 shows how the data areorganized for transmission. Each Data Frame consists of two Data Fields, eachcontaining 313 Data Segments. The first Data Segment of each Data Field is aunique synchronizing signal (Data Field Sync) and includes the trainingsequence used by the equalizer in the receiver. The remaining 312 Data Segmentseach carry the equivalent of the data from one 188-byte transport packet plusits associated FEC overhead. The actual data in each Data Segment comes fromseveral transport packets because of data interleaving. Each Data Segmentconsists of 832 symbols. The first 4 symbols are transmitted in binary form andprovide segment synchronization. This Data Segment Sync signal also representsthe sync byte of the 188-byte MPEG-compatible transport packet. The remaining828 symbols of each Data Segment carry data equivalent to the remaining 187bytes of a transport packet and its associated FEC overhead. These 828 symbolsare transmitted as 8-level signals and therefore carry three bits per symbol.Thus, 828 ´ 3 = 2484 bits of data are carried ineach Data Segment, which exactly matches the requirement to send a protectedtransport packet:
187 data bytes + 20 RS parity bytes =207 bytes
207 bytes ´ 8 bits/byte = 1656 bits
2/3 rate trellis coding requires 3/2 ´ 1656 bits = 2484 bits
FigureD2 VSB data frame.
The exact symbol rate is given by
The frequency of a Data Segment is givenby
The Data Frame rate is given by
The symbol rate Sr and the transport rate Tr (see Section 7.2 of Annex C) shall be locked to eachother in frequency.
The 8-level symbols combined with thebinary Data Segment Sync and Data Field Sync signals shall be used tosuppressed-carrier modulate a single carrier. Before transmission, however,most of the lower sideband shall be removed. The resulting spectrum is flat,except for the band edges where a nominal square root raised cosine responseresults in 620 kHz transition regions. The nominal VSB transmission spectrum isshown in Figure D3.
At the suppressed-carrier frequency, 310kHz from the lower band edge, a small pilot shall be added to the signal.
FigureD3 VSB channel occupancy (nominal).
110.ChannelError Protection and Synchronization
111.Prioritization
All payload data shall be carriedwith the same priority.
112.DataRandomizer
A data randomizer shall be used onall input data to randomize the data payload (not including Data Field Sync orData Segment Sync, or RS parity bytes). The data randomizer XORs all theincoming data bytes with a 16-bit maximum length pseudo random binary sequence(PRBS) which is initialized at the beginning of the Data Field. The PRBS isgenerated in a 16-bit shift register that has 9 feedback taps. Eight of theshift register outputs are selected as the fixed randomizing byte, where eachbit from this byte is used to individually XOR the corresponding input databit. The data bits are XORed MSB to MSB ... LSB to LSB.
The randomizer generator polynomial is asfollows:
The initialization (pre-load) to F180 hex(load to 1) occurs during the Data Segment Sync interval prior to the firstData Segment.
Therandomizer generator polynomial and initialization is shown in Figure D4.
FigureD4 Randomizer polynomial.
113.Reed-SolomonEncoder
The RS code used in the VSBtransmission subsystem shall be a t =l0 (207,187) code. The RS data block size is 187 bytes, with 20 RS parity bytesadded for error correction. A total RS block size of 207 bytes is transmittedper Data Segment.
In creatingbytes from the serial bit stream, the MSB shall be the first serial bit. The 20RS parity bytes shall be sent at the end of the Data Segment. The paritygenerator polynomial and the primitive field generator polynomial are shown inFigure D5.
FigureD5 Reed-Solomon (207,187) t=10 parity generator polynomial.
114.Interleaving
The interleaver employed in theVSB transmission system shall be a 52 data segment (intersegment) convolutionalbyte interleaver. Interleaving is provided to a depth of about 1/6 of a datafield (4 ms deep). Only data bytes shall be interleaved. The interleaver shallbe synchronized to the first data byte of the data field. Intrasegmentinterleaving is also performed for the benefit of the trellis coding process.
Theconvolutional interleaver is shown in Figure D6.
FigureD6 Convolutional interleaver (byte shift register illustration).
115.TrellisCoding
The 8 VSB transmission sub-systemshall employ a 2/3 rate (R = 2/3)trellis code (with one unencoded bit which is precoded). That is, one input bitis encoded into two output bits using a l/2 rate convolutional code while theother input bit is precoded. The signaling waveform used with the trellis codeis an 8-level (3 bit) one-dimensional constellation. The transmitted signal isreferred to as 8 VSB. A 4-state trellis encoder shall be used.
Trellis code intrasegment interleavingshall be used. This uses twelve identical trellis encoders and precodersoperating on interleaved data symbols. The code interleaving is accomplished byencoding symbols (0, 12, 24, 36 ...) as one group, symbols (1, 13, 25, 37, ...)as a second group, symbols (2, 14, 26, 38, ...) as a third group, and so on fora total of 12 groups.
In creatingserial bits from parallel bytes, the MSB shall be sent out first: (7, 6, 5, 4,3, 2, 1, 0). The MSB is precoded (7, 5, 3, 1) and the LSB is feedbackconvolutional encoded (6, 4, 2, 0). Standard 4-state optimal Ungerboeck codesshall be used for the encoding. The trellis code utilizes the 4-state feedbackencoder shown in Figure D7. Also shown is the precoder and the symbol mapper.The trellis code and precoder intrasegment interleaver is shown in Figure D8which feeds the mapper shown in Figure D7. Referring to Figure D8, data bytesare fed from the byte interleaver to the trellis coder and precoder, and theyare processed as whole bytes by each of the twelve encoders. Each byte producesfour symbols from a single encoder.
FigureD7 8 VSB trellis encoder, precoder, and symbol mapper.
Figure D8 Trellis code interleaver.
The output multiplexer shown in Figure D8shall advance by four symbols on each segment boundary. However, the state ofthe trellis encoder shall not be advanced. The data coming out of themultiplexer shall follow normal ordering from encoder 0 through 11 for thefirst segment of the frame, but on the second segment the order changes andsymbols are read from encoders 4 through 11, and then 0 through 3. The thirdsegment reads from encoder 8 through 11 and then 0 through 7. Thisthree-segment pattern shall repeat through the 312 Data Segments of the frame.Table D1 shows the interleaving sequence for the first three Data Segments ofthe frame.
After the Data Segment Sync is inserted,the ordering of the data symbols is such that symbols from each encoder occurat a spacing of twelve symbols.
Table D1 Interleaving Sequence
| Segment | Block 0 | Block 1 | ... | Block 68 |
| 0 1 2 | D0 D1 D2 ... D11 D4 D5 D6 ... D3 D8 D9 D10 ... D7 | D0 D1 D2 ... D11 D4 D5 D6 ... D3 D8 D9 D10 ... D7 | ... ... ... | D0 D1 D2 ... D11 D4 D5 D6 ... D3 D8 D9 D10 ... D7 |
A completeconversion of parallel bytes to serial bits needs 828 bytes to produce 6624bits. Data symbols are created from 2 bits sent in MSB order, so a completeconversion operation yields 3312 data symbols, which corresponds to 4 segmentsof 828 data symbols. 3312 data symbols divided by 12 trellis encoders gives 276symbols per trellis encoder. 276 symbols divided by 4 symbols per byte gives 69bytes per trellis encoder.
The conversion starts with the firstsegment of the field and proceeds with groups of 4 segments until the end ofthe field. 312 segments per field divided by 4 gives 78 conversion operationsper field.
During segment sync the input to 4encoders is skipped and the encoders cycle with no input. The input is helduntil the next multiplex cycle and then fed to the correct encoder.
Table D2 details the byte-to-symbolconversion and the associated multiplexing of the trellis encoders. Segment 0is the first segment of the field. The pattern repeats every 12 segments;segments 5 through 11 are not shown.
Table D2 Byte to Symbol Conversion, Multiplexing of Trellis Encoders
| Symbol | Segment 0 | Segment 1 | Segment 2 | Segment 3 | Segment 4 | ||||||||||
| Trellis | Byte | Bits | Trellis | Byte | Bits | Trellis | Byte | Bits | Trellis | Byte | Bits | Trellis | Byte | Bits | |
| 0 | 0 | 0 | 7,6 | 4 | 208 | 5,4 | 8 | 412 | 3,2 | 0 | 616 | 1,0 | 4 | 828 | 7,6 |
| 1 | 1 | 1 | 7,6 | 5 | 209 | 5,4 | 9 | 413 | 3,2 | 1 | 617 | 1,0 | 5 | 829 | 7,6 |
| 2 | 2 | 2 | 7,6 | 6 | 210 | 5,4 | 10 | 414 | 3,2 | 2 | 618 | 1,0 | 6 | 830 | 7,6 |
| 3 | 3 | 3 | 7,6 | 7 | 211 | 5,4 | 11 | 415 | 3,2 | 3 | 619 | 1,0 | ... | ... | ... |
| 4 | 4 | 4 | 7,6 | 8 | 212 | 5,4 | 0 | 416 | 3,2 | 4 | 620 | 1,0 | ... | ... | ... |
| 5 | 5 | 5 | 7,6 | 9 | 213 | 5,4 | 1 | 417 | 3,2 | 5 | 621 | 1,0 | ... | ... | ... |
| 6 | 6 | 6 | 7,6 | 10 | 214 | 5,4 | 2 | 418 | 3,2 | 6 | 622 | 1,0 | ... | ... | ... |
| 7 | 7 | 7 | 7,6 | 11 | 215 | 5,4 | 3 | 419 | 3,2 | 7 | 623 | 1,0 | ... | ... | ... |
| 8 | 8 | 8 | 7,6 | 0 | 204 | 5,4 | 4 | 408 | 3,2 | 8 | 612 | 1,0 | ... | ... | ... |
| 9 | 9 | 9 | 7,6 | 1 | 205 | 5,4 | 5 | 409 | 3,2 | 9 | 613 | 1,0 | ... | ... | ... |
| 10 | 10 | 10 | 7,6 | 2 | 206 | 5,4 | 6 | 410 | 3,2 | 10 | 614 | 1,0 | ... | ... | ... |
| 11 | 11 | 11 | 7,6 | 3 | 207 | 5,4 | 7 | 411 | 3,2 | 11 | 615 | 1,0 | ... | ... | ... |
| 12 | 0 | 0 | 5,4 | 4 | 208 | 3,2 | 8 | 412 | 1,0 | 0 | 624 | 7,6 | ... | ... | ... |
| 13 | 1 | 1 | 5,4 | 5 | 209 | 3,2 | 9 | 413 | 1,0 | 1 | 625 | 7,6 | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 19 | 7 | 7 | 5,4 | 11 | 215 | 3,2 | 3 | 419 | 1,0 | 7 | 631 | 7,6 | ... | ... | ... |
| 20 | 8 | 8 | 5,4 | 0 | 204 | 3,2 | 4 | 408 | 1,0 | 8 | 632 | 7,6 | ... | ... | ... |
| 21 | 9 | 9 | 5,4 | 1 | 205 | 3,2 | 5 | 409 | 1,0 | 9 | 633 | 7,6 | ... | ... | ... |
| 22 | 10 | 10 | 5,4 | 2 | 206 | 3,2 | 6 | 410 | 1,0 | 10 | 634 | 7,6 | ... | ... | ... |
| 23 | 11 | 11 | 5,4 | 3 | 207 | 3,2 | 7 | 411 | 1,0 | 11 | 635 | 7,6 | ... | ... | ... |
| 24 | 0 | 0 | 3,2 | 4 | 208 | 1,0 | 8 | 420 | 7,6 | 0 | 624 | 5,4 | ... | ... | ... |
| 25 | 1 | 1 | 3,2 | 5 | 209 | 1,0 | 9 | 421 | 7,6 | 1 | 625 | 5,4 | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 31 | 7 | 7 | 3,2 | 11 | 215 | 1,0 | 3 | 427 | 7,6 | ... | ... | ... | ... | ... | ... |
| 32 | 8 | 8 | 3,2 | 0 | 204 | 1,0 | 4 | 428 | 7,6 | ... | ... | ... | ... | ... | ... |
| 33 | 9 | 9 | 3,2 | 1 | 205 | 1,0 | 5 | 429 | 7,6 | ... | ... | ... | ... | ... | ... |
| 34 | 10 | 10 | 3,2 | 2 | 206 | 1,0 | 6 | 430 | 7,6 | ... | ... | ... | ... | ... | ... |
| 35 | 11 | 11 | 3,2 | 3 | 207 | 1,0 | 7 | 431 | 7,6 | ... | ... | ... | ... | ... | ... |
| 36 | 0 | 0 | 1,0 | 4 | 216 | 7,6 | 8 | 420 | 5,4 | ... | ... | ... | ... | ... | ... |
| 37 | 1 | 1 | 1,0 | 5 | 217 | 7,6 | 9 | 421 | 5,4 | ... | ... | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 47 | 11 | 11 | 1,0 | 3 | 227 | 7,6 | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 48 | 0 | 12 | 7,6 | 4 | 216 | 5,4 | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 49 | 1 | 13 | 7,6 | 5 | 217 | 5,4 | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 95 | 11 | 23 | 1,0 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 96 | 0 | 24 | 7,6 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 97 | 1 | 25 | 7,6 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 767 | 11 | 191 | 1,0 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 768 | 0 | 192 | 7,6 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 769 | 1 | 193 | 7,6 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 815 | 11 | 203 | 1,0 | 3 | 419 | 7,6 | 7 | 623 | 5,4 | 11 | 827 | 3,2 | ... | ... | ... |
| 816 | 0 | 204 | 7,6 | 4 | 408 | 5,4 | 8 | 612 | 3,2 | 0 | 816 | 1,0 | ... | ... | ... |
| 817 | 1 | 205 | 7,6 | 5 | 409 | 5,4 | 9 | 613 | 3,2 | 1 | 817 | 1,0 | ... | ... | ... |
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
| 827 | 11 | 215 | 7,6 | 3 | 419 | 5,4 | 7 | 623 | 3,2 | 11 | 827 | 1,0 | ... | ... | ... |
116.DataSegment Sync
The encoded trellis data shall bepassed through a multiplexer that inserts the various synchronization signals(Data Segment Sync and Data Field Sync).
A two-level (binary) 4-symbol DataSegment Sync shall be inserted into the 8-level digital data stream at thebeginning of each Data Segment. (The MPEG sync byte shall be replaced by DataSegment Sync.) The Data Segment Sync embedded in random data is illustrated inFigure D9.
A completesegment shall consist of 832 symbols: 4 symbols for Data Segment Sync, and 828data plus parity symbols. The Data Segment Sync is binary (2-level). The samesync pattern occurs regularly at 77.3 µs intervals, and is theonly signal repeating at this rate. Unlike the data, the four symbols for DataSegment Sync are not Reed-Solomon or trellis encoded, nor are they interleaved.The Data Segment Sync pattern shall be a 1001 pattern, as shown in Figure D9.
FigureD9 8 VSB data segment.
117.Data FieldSync
Thedata are not only divided into Data Segments, but also into Data Fields, eachconsisting of 313 segments. Each Data Field (24.2 ms) shall start with onecomplete Data Segment of Data Field Sync, as shown in Figure D10. Each symbolrepresents one bit of data (2-level). The 832 symbols in this segment aredefined below. Refer to Figure D10.
FigureD10 VSB data field sync.
118.Sync
This corresponds to Data SegmentSync and is defined as 1001.
119.PN511
Thispseudo-random sequence is defined as
witha pre-load value of 010000000. The sequence is:
| 0000 | 0001 | 0111 | 1111 | 1100 | 1010 | 1010 | 1110 | 0110 | 0110 | 1000 | 1000 | 1001 | 1110 | 0001 | 1101 |
| 0111 | 1101 | 0011 | 0101 | 0011 | 1011 | 0011 | 1010 | 0100 | 0101 | 1000 | 1111 | 0010 | 0001 | 0100 | 0111 |
| 1100 | 1111 | 0101 | 0001 | 0100 | 1100 | 0011 | 0001 | 0000 | 0100 | 0011 | 1111 | 0000 | 0101 | 0100 | 0000 |
| 1100 | 1111 | 1110 | 1110 | 1010 | 1001 | 0110 | 0110 | 0011 | 0111 | 0111 | 1011 | 0100 | 1010 | 0100 | 1110 |
| 0111 | 0001 | 0111 | 0100 | 0011 | 0100 | 1111 | 1011 | 0001 | 0101 | 1011 | 1100 | 1101 | 1010 | 1110 | 1101 |
| 1001 | 0110 | 1101 | 1100 | 1001 | 0010 | 1110 | 0011 | 1001 | 0111 | 1010 | 0011 | 0101 | 1000 | 0100 | 1101 |
| 1111 | 0001 | 0010 | 1011 | 1100 | 0110 | 0101 | 0000 | 1000 | 1100 | 0001 | 1110 | 1111 | 1101 | 0110 | 1010 |
| 1100 | 1001 | 1001 | 0001 | 1101 | 1100 | 0010 | 1101 | 0000 | 0110 | 1100 | 0000 | 1001 | 0000 | 0001 | 110 |
120.PN63
Thispseudo-random sequence is repeated three times. It is defined as
witha pre-load value of 100111. The middle PN63 is inverted on every other DataField Sync. The sequence is:
| 1110 | 0100 | 1011 | 0111 | 0110 | 0110 | 1010 | 1111 | 1100 | 0001 | 0000 | 1100 | 0101 | 0011 | 1101 | 000 |
The generators for the PN63 and PN511sequences are shown in Figure D11.
FigureD11 Field sync PN sequence generators.
121.VSB mode
These24 bits determine the VSB mode for the data in the frame. The first two bytesare reserved. The suggested fill pattern is 0000 1111 0000 1111. The next byteis defined as:
| P | A | B | C | P | A | B | C |
where P is the evenparity bit, the MSB of the byte, and A,B, C are the actual mode bits.
| P | A | B | C |
|
|
| 0 | 0 | 0 | 0 |
| Reserved |
| 1 | 0 | 0 | 1 |
| Reserved |
| 1 | 0 | 1 | 0 |
| Reserved |
| 0 | 0 | 1 | 1 |
| Reserved |
| 1 | 1 | 0 | 0 |
| 16 VSB |
| 0 | 1 | 0 | 1 |
| 8 VSB* |
| 0 | 1 | 1 | 0 |
| Reserved |
| 1 | 1 | 1 | 1 |
| Reserved |
* In the 8 VSB mode, the precedingbits are defined as :
| 0 | 0 | 0 | 0 | P | A | B | C | P | A | B | C | 1 | 1 | 1 | 1 |
122.Reserved
The last 104 bits shall bereserved space. It is suggested that this be filled with a continuation of thePN63 sequence. In the 8 VSB mode, 92 bits are reserved followed by the 12symbol definition below.
123.Precode
In the 8 VSB mode, the last 12symbols of the segment shall correspond to the last 12 symbols of the previoussegment. All sequences are pre-loaded before the beginning of the Data FieldSync.
Like the Data Segment Sync, the DataField Sync is not Reed-Solomon or trellis encoded, nor is it interleaved.
124.Modulation
125.Bit-to-SymbolMapping
Figure D7 shows the mapping of theoutputs of the trellis decoder to the nominal signal levels of (–7, –5, –3, –1,1, 3, 5, 7). As shown in Figure D9, the nominal levels of Data Segment Sync andData Field Sync are –5 and +5. The value of 1.25 is added to all these nominallevels after the bit-to-symbol mapping function for the purpose of creating asmall pilot carrier.
126.PilotAddition
A small in-phase pilot shall beadded to the data signal. The frequency of the pilot shall be the same as thesuppressed-carrier frequency as shown in Figure D3. This may be generated inthe following manner. A small (digital) dc level (1.25) shall be added to everysymbol (data and sync) of the digital baseband data plus sync signal (+l,+3, +5, +7). The power of the pilot shall be 11.3 dB belowthe average data signal power.
127.8 VSBModulation Method
TheVSB modulator receives the 10.76 Msymbols/s, 8-level trellis encoded compositedata signal (pilot and sync added). The ATV system performance is based on alinear phase raised cosine Nyquist filter response in the concatenatedtransmitter and receiver, as shown in Figure D12. The system filter response isessentially flat across the entire band, except for the transition regions ateach end of the band. Nominally, the roll-off in the transmitter shall have theresponse of a linear phase root raised cosine filter.
FigureD12 Nominal VSB system channel response (linear phase raised cosineNyquist filter).
128.Transmissioncharacteristics for high data rate mode
The high data rate mode trades offtransmission robustness (28.3 dB signal-to-noise threshold) for payload datarate (38.57 Mbps). Most parts of the high data rate mode VSB system areidentical or similar to the terrestrial system. A pilot, Data Segment Sync, andData Field Sync are all used to provide robust operation. The pilot in the highdata rate mode also is 11.3 dB below the data signal power. The symbol,segment, and field signals and rates are all the same, allowing either receiverto lock up on the other’s transmitted signal. Also, the data frame definitionsare identical. The primary difference is the number of transmitted levels (8versus 16) and the use of trellis coding and NTSC interference rejectionfiltering in the terrestrial system.
The RFspectrum of the high data rate modem transmitter looks identical to theterrestrial system, as illustrated in Figure D3. Figure D13 illustrates atypical data segment, where the number of data levels is seen to be 16 due tothe doubled data rate. Each portion of 828 data symbols represents 187 databytes and 20 Reed-Solomon bytes followed by a second group of 187 data bytesand 20 Reed-Solomon bytes (before convolutional interleaving).
FigureD13 16 VSB data segment.
Figure D14shows the block diagram of the transmitter. It is identical to the terrestrialVSB system except the trellis coding shall be replaced with a mapper whichconverts data to multi-level symbols. See Figure D15.
Figure D14 16 VSB transmitter.
Figure D15 16 VSB mapper.
129.ChannelError Protection and Synchronization
130.Prioritization
See Section 4.1.1.
131.DataRandomizer
See Section 4.1.2.
132.Reed-SolomonEncoder
See Section 4.1.3.
133.Interleaving
The interleaver shall be a 26 datasegment inter-segment convolutional byte interleaver. Interleaving is providedto a depth of about 1/12 of a data field (2 ms deep). Only data bytes shall beinterleaved.
134.DataSegment Sync
See Section 4.1.6.
135.Data FieldSync
See Section 4.1.7.
136.Modulation
137.Bit-to-SymbolMapping
Figure D15 shows the mapping ofthe outputs of the interleaver to the nominal signal levels (–15, –13, –11,..., 11, 13, 15). As shown in Figure D13, the nominal levels of Data SegmentSync and Data Field Sync are –9 and +9. The value of 2.5 is added to all thesenominal levels after the bit-to-symbol mapping for the purpose of creating asmall pilot carrier.
138.Pilot Addition
A small in-phase pilot shall beadded to the data signal. The frequency of the pilot shall be the same as thesuppressed-carrier frequency as shown in Figure D3. This may be generated inthe following manner. A small (digital) dc level (2.5) shall be added to everysymbol (data and sync) of the digital baseband data plus sync signal (+l,+3, +5, +7, +9, +11, +13, +15).The power of the pilot shall be 11.3 dB below the average data signal power.
139.16 VSBModulation Method
The modulation method shall beidentical to that in Section 4, except the number of transmitted levels shallbe 16 instead of 8.
Annex E:
Receiver Characteristics (Informative)
5. Scope
This informative Annex providesmaterial to help readers understand and implement the normative portions of theDigital Television Standard. The normative clauses of the Standard do notspecify the design of a receiver. Instead, they specify the transmitted bitstream and RF signal with a thoroughness sufficient to permit the design of areceiver.
Although the normative portions of theStandard are written in the traditional way—by specifying the signal format,not the receiver—the ATSC believes that the introductory phase of this newStandard can be made more orderly by listing some receiver design considerationsin this informative Annex. Service providers need assurance that their programswill be correctly processed in all receivers, and receiver manufacturers needassurance that their receivers will function properly with all broadcasts.
This Annex also contains references toexisting (both voluntary and mandatory) standards for television receivers andnotes work in progress on voluntary industry standards being developed at thistime.
140.Referencesto existing or emerging standards
47 CFR Part 15, FCC Rules.
EIA IS-132, EIA Interim Standardfor Channelization of Cable Television.
EIA IS-23, EIA Interim Standardfor RF Interface Specification for Television Receiving Devices and CableTelevision Systems.
EIA IS-105, EIA Interim Standardfor a Decoder Interface Specification for Television Receiving Devices andCable Television Decoders.
141.Compliancenotation
Compliance with mandatory orvoluntary standards and recommended practices for digital television receiverscan be inferred only from previous experience with NTSC. Actual standards fordigital television receivers have not been developed at this time. As used inthis document “appropriate” means that the existing rules for NTSC which arereferenced contain most elements of future rules for digital television.Furthermore, the rules may be expanded to cover digital television.
142.Status ofreceiver standardization activities
143.TunerPerformance
The FCC Rules under 47 CFR Part 15which are applicable to conventional television receivers are expected to beappropriate for digital television receivers.
144.NoiseFigure
The 10 dB noise figure used as aplanning factor has been reviewed considering the needs of digital televisionreception and has been found appropriate.
145.ChannelizationPlan for Broadcast and Cable
The cable channelization planspecified in the FCC Rules under 47 CFR Part 15 which are applicable toconventional television receivers are expected to be appropriate for digitaltelevision receivers. Broadcast channelization is specified in the FCC Rulesunder 47 CFR Part 73.
146.DirectPickup
The FCC Rules under 47 CFR Part 15which are applicable to conventional television receivers may be appropriatefor digital television receivers as well. Performance characteristics forreception of digital signals, whether standard- or high-definition, have notbeen developed by the industry. It is expected that direct pickup of a givenlevel will have less effect on digital signals than on NTSC.
147.Transport
Significant work foridentification of multiple programs within a single digital television channelhas not taken place in the industry. It is recommended that a digitaltelevision receiver provide appropriate features to assist users in theselection of the desired video program service, if multiple video programswithin one channel are offered.
148.DecoderInterface
The FCC Rules which are to beadopted for a decoder interface on NTSC receiver advertised as “cable-ready” or“cable-compatible” are expected to be appropriate for digital televisionreceivers. Much work has been done on this interface standard (IS-105) by theJoint Engineering Committee of EIA and NCTA. Although that interface standardis not intended to apply to digital television receivers, it will almostcertainly provide a basis for a decoder interface standard applicable to them.
149.DigitalData Interface
Work on a digital data interfaceis being performed by the EIA’s R-4.1 subcommittee on ATV Receiver Interfaces.R-4.1 intends to define a baseband serial digital interface so that devices mayexchange packetized data, for example, when a digital VCR is connected to adigital television receiver.
It is recommended that manufacturers ofdigital television receivers wishing to include a digital data interface giveconsideration to the interface developed by R4.1.
150.ConditionalAccess Interface
The National Renewable SecuritySystem (NRSS) Subcommittee of the Joint Engineering Committee of EIA and NCTAhas the responsibility to develop a standard for a plug-in security module. TheNRSS standard may be applied in either a standard definition or high definitionenvironment.
It is recommended that manufacturers ofdigital television receivers wishing to include a conditional access interfacegive consideration to the NRSS standard developed by the JEC.
151.ClosedCaptioning
Closed captioning for televisionis covered by the FCC Rules under 47 CFR Part 15 which are presently applied toconventional television receivers. These rules are expected to be appropriatefor digital television receivers.
Work on defining the technical standardfor closed captioning for the digital television system is being performed bythe EIA’s R-4.3 subcommittee.
152.Receiverfunctionality
153.Video
It is recommended that a digitaltelevision receiver be capable of appropriately decoding and displaying thevideo scanning formats defined in the Digital Television Standard and describedin Table A3 “Compression Format Constraints” in Annex A of this Standard.
154.Audio
It is recommended that a digitaltelevision receiver be capable of selecting and decoding any audio servicedescribed in Section 6 of Annex B of this Standard, subject to the bit rateconstraints in Section 5.3 of Annex B of this Standard.
It is recommended that a digitaltelevision receiver be capable of normalizing audio levels based on the valueof the syntactical element dialnorm which is contained in the audio elementary stream.
It is recommended that a digitaltelevision receiver be capable of altering reproduced audio levels based on thevalue of the syntactical element dynrng which is contained in the audio elementary stream.
It is recommended that a digitaltelevision receiver provide appropriate features to assist users in theselection of program related audio services
[1] The JCIC is presently composed of: the Electronic IndustriesAlliance (EIA), the Institute of Electrical and Electronics Engineers (IEEE),the National Association of Broadcasters (NAB), the National Cable TelevisionAssociation (NCTA), and the Society of Motion Picture and Television Engineers(SMPTE).
[2] FCC 92-438, MM Docket No. 87-268, “Memorandum Opinion andOrder/Third Report and Order/Third Further Notice of Proposed Rule Making,”Adopted: September 17, 1992, pp. 59–60.
[3] ITU-R Document TG11/3-2, “Outline of Work for Task Group 11/3,Digital Terrestrial Television Broadcasting,” June 30, 1992.
[4] Chairman, ITU-R Task Group 11/3, “Report of the Second Meeting ofITU-R Task Group 11/3, Geneva, October 13–19, 1993,” p. 40, January 5, 1994.
[5] See ISO/IEC 13818-2, Section 8 for more information regardingprofiles and levels.
[6] Note that 1088 lines are actually coded in order to satisfy theMPEG-2 requirement that the coded vertical size be a multiple of 16(progressive scan) or 32 (interlaced scan). The 1080 lines are required tostart at the first line of the field; i.e., top-aligned.
[7] In order to decode the user data, the decoder should properlyrecognize the 32-bit ATSC registration identifier at the PSI stream level (seeISO/IEC 13818-1).
[8] Shaded cells in this table indicate syntactic and semanticadditions to the ISO/IEC 13818-2 standard.
[9] There is currently no activityunderway to define the interpretation of this field.
[10] EIA, Recommended Practice forAdvanced Television Closed Captioning, draft, July 1, 1994.
2988
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
