In the Program Stream both fixed and variable packet lengths are allowed subject to constraints as specified in 2.5.1
and 2.5.2. For Transport Streams the packet length is 188 bytes. Both fixed and variable PES packet lengths are allowed,
and will be relatively long in most applications.
On decoding, demultiplexing is required to reconstitute elementary streams from the multiplexed Program Stream or
Transport Stream. Stream_id codes in Program Stream packet headers, and Packet ID codes in the Transport Stream
make this possible.
Intro. 8.2 Synchronization
Synchronization among multiple elementary streams is accomplished with Presentation Time Stamps (PTS) in the
Program Stream and Transport streams. Time stamps are generally in units of 90 kHz, but the System Clock Reference
(SCR), the Program Clock Reference (PCR) and the optional Elementary Stream Clock Reference (ESCR) have
extensions with a resolution of 27 MHz. Decoding of N-elementary streams is synchronized by adjusting the decoding of
streams to a common master time base rather than by adjusting the decoding of one stream to match that of another. The
master time base may be one of the N-decoders’ clocks, the data source’s clock, or it may be some external clock.
Each program in a Transport Stream, which may contain multiple programs, may have its own time base. The time bases
of different programs within a Transport Stream may be different.
Because PTSs apply to the decoding of individual elementary streams, they reside in the PES packet layer of both the
Transport Streams and Program Streams. End-to-end synchronization occurs when encoders save time stamps at capture
time, when the time stamps propagate with associated coded data to decoders, and when decoders use those time stamps
to schedule presentations.
Synchronization of a decoding system with a channel is achieved through the use of the SCR in the Program Stream and
by its analogue, the PCR, in the Transport Stream. The SCR and PCR are time stamps encoding the timing of the bit
stream itself, and are derived from the same time base used for the audio and video PTS values from the same program.
Since each program may have its own time base, there are separate PCR fields for each program in a Transport Stream
containing multiple programs. In some cases it may be possible for programs to share PCR fields. Refer to 2.4.4,
Program Specific Information (PSI), for the method of identifying which PCR is associated with a program. A program
shall have one and only one PCR time base associated with it.
Intro. 8.3 Relation to compression layer
The PES packet layer is independent of the compression layer in some senses, but not in all. It is independent in the sense
that PES packet payloads need not start at compression layer start codes, as defined in Parts 2 and 3 of ISO/IEC 13818.
For example, video start codes may occur anywhere within the payload of a PES packet, and start codes may be split by a
PES packet header. However, time stamps encoded in PES packet headers apply to presentation times of compression
layer constructs (namely, presentation units). In addition, when the elementary stream data conforms to ITU-T
Rec. H.262 | ISO/IEC 13818-2 or ISO/IEC 13818-3, the PES_packet_data_bytes shall be byte aligned to the bytes of this
Recommendation | International Standard.
Intro. 9 System reference decoder
Part 1 of ISO/IEC 13818 employs a "System Target Decoder" (STD), one for Transport Streams (refer to 2.4.2) referred
to as "Transport System Target Decoder" (T-STD) and one for Program Streams (refer to 2.5.2) referred to as "Program
System Target Decoder" (P-STD), to provide a formalism for timing and buffering relationships. Because the STD is
parameterized in terms of ITU-T Rec. H.222.0 | ISO/IEC 13818-1 fields (for example, buffer sizes) each elementary
stream leads to its own parameterization of the STD. Encoders shall produce bit streams that meet the appropriate STD’s
constraints. Physical decoders may assume that a stream plays properly on its STD. The physical decoder must
compensate for ways in which its design differs from that of the STD.
Intro. 10 Applications
The streams defined in this Recommendation | International Standard are intended to be as useful as possible to a wide
variety of applications. Application developers should select the most appropriate stream.
Modern data communications networks may be capable of supporting ITU-T Rec. H.222.0 | ISO/IEC 13818-1 video and
ISO/IEC 13818 audio. A real time transport protocol is required. The Program Stream may be suitable for transmission
on such networks.
ISO/IEC 13818-1:2000(E)
xvi © ISO/IEC 2000 – All rights reserved