AVT A. Begen
Internet-Draft E. Friedrich
Intended status: Standards Track Cisco Systems
Expires: February 13, 2010 August 12, 2009
RTP Payload Format for MPEG2-TS Preamble
draft-begen-avt-rtp-mpeg2ts-preamble-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 13, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Begen & Friedrich Expires February 13, 2010 [Page 1]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Abstract
Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS)
requires the knowledge of specific information about the transport
stream, which we refer to as the MPEG2-TS Preamble. While this
information is spread over different locations throughout the
transport stream and can be eventually assembled after some time a
receiver started receiving the MPEG2-TS, the time it takes to
retrieve all this information (especially in multicast environments)
may be long. Instead, having this information readily available as a
Preamble and sending the Preamble to a receiver that will shortly
start receiving the transport stream will virtually eliminate the
waiting time and let the receiver start processing/decoding the
MPEG2-TS sooner. In this document, we give an overview of the
MPEG2-TS and the delay components in video systems, and motivate the
need for constructing and using the MPEG2-TS Preamble for rapidly
acquiring the source stream in RTP multicast sessions. We also
define and register the RTP payload format for the MPEG2-TS Preamble.
Begen & Friedrich Expires February 13, 2010 [Page 2]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Video Systems . . . . . . . . . . . . . . 9
4.1. Overview of MPEG-2 Transport Streams . . . . . . . . . . . 9
4.2. Reference Information Latency in Video Applications . . . 10
4.2.1. PSI (PAT/CAT/PMT) Acquisition Delay . . . . . . . . . 10
4.2.2. Random Access Point Acquisition Delay . . . . . . . . 11
4.3. Buffering Delays in Video Applications . . . . . . . . . . 12
4.3.1. Network-Related Buffering Delays . . . . . . . . . . . 12
4.3.2. Application-Related Buffering Delays . . . . . . . . . 13
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 15
5.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 16
5.2. Vendor-Neutral Extensions . . . . . . . . . . . . . . . . 16
5.2.1. PAT TLOV . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2. PMT TLOV . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. PCR TLOV . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.4. PID_LIST TLOV . . . . . . . . . . . . . . . . . . . . 18
5.2.5. SEQ TLOV . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. SPS TLOV . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.7. PPS TLOV . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.8. SEI TLOV . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.9. ECM TLOV . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.10. EMM TLOV . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.11. CAT TLOV . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.12. PTS TLOV . . . . . . . . . . . . . . . . . . . . . . . 24
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 25
6.1. Media Type Registration . . . . . . . . . . . . . . . . . 25
6.1.1. Registration of audio/mpeg2-ts-preamble . . . . . . . 25
6.1.2. Registration of video/mpeg2-ts-preamble . . . . . . . 26
6.1.3. Registration of text/mpeg2-ts-preamble . . . . . . . . 26
6.1.4. Registration of application/mpeg2-ts-preamble . . . . 27
6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 28
6.2.1. Offer-Answer Model Considerations . . . . . . . . . . 29
6.2.2. Declarative Considerations . . . . . . . . . . . . . . 29
7. Post-Processing of the MPEG2-TS Preamble . . . . . . . . . . . 30
8. Session Description Protocol (SDP) Signaling . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
10.1. Payload Format . . . . . . . . . . . . . . . . . . . . . . 34
10.2. MPEG2-TS Preamble TLOV Space Registry . . . . . . . . . . 34
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Begen & Friedrich Expires February 13, 2010 [Page 3]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
13.1. Normative References . . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Begen & Friedrich Expires February 13, 2010 [Page 4]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
1. Introduction
MPEG2 Transport Stream (MPEG2-TS) [MPEG2TS] is an encapsulation
method and transport that multiplexes digital video and audio
content, together with ancillary metadata, and produces a
synchronized multiplexed stream that is tailored for transport over
packet or cell-oriented networks. MPEG2-TS is ubiquitous in
broadcast applications over both terrestrial and satellite networks.
Both Advanced Television Systems Committee (ATSC) in North America
and Digital Video Broadcasting (DVB) in Europe use MPEG2-TS in their
standards. MPEG2-TS has been standardized by both ISO and ITU
[MPEG2TS]. While MPEG2-TS was originally limited to carry MPEG-2
encoded content, the specification was later extended to cover MPEG-
4/AVC audio/video encoding standards as well.
Due to the inherent design of MPEG2-TS, a receiver must first acquire
certain information before demultiplexing and decoding an incoming
MPEG2-TS. As will be explained in Section 4.1, this information
resides in the transport stream. However, it is often not contiguous
and is usually dispersed over a large period. Thus, a receiver
starting to receive an MPEG2-TS at a random location will have to
wait until the whole required information shows up in the received
data. In multicast applications, since the joining receivers do not
have any control over what point in the flow is currently being
transmitted, their waiting times will vary. This problem has been
identified and examined in detail in
[I-D.ietf-avt-rapid-acquisition-for-rtp], where the time lag before a
receiver can usefully consume the multicast data is referred to as
the Acquisition Delay. Section 4 provides an overview of the delay
components in video systems that contribute to the acquisition delay.
[I-D.ietf-avt-rapid-acquisition-for-rtp] refers to the information
that must first be acquired before starting to process any data sent
in the multicast session as the Reference Information. In this
document, we refer to the subset of the Reference Information that is
related to the MPEG2-TS as the MPEG2-TS Preamble.
For multicast applications running over RTP,
[I-D.ietf-avt-rapid-acquisition-for-rtp] proposes an approach where
an auxiliary unicast RTP session is established between a
retransmission server and the joining RTP receiver. Over this
unicast RTP session, the retransmission server provides the Reference
Information the RTP receiver needs to rapidly acquire the multicast
session. If the source stream in the RTP multicast session is
carrying an MPEG2-TS, the Reference Information will comprise the
MPEG2-TS Preamble as well. For its proper transmission from the
retransmission server to the joining RTP receiver, a new RTP payload
format has to be defined for the MPEG2-TS Preamble. This document
Begen & Friedrich Expires February 13, 2010 [Page 5]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
defines and registers this payload format.
Since the RTP packet(s) carrying the MPEG2-TS Preamble will not be
able to fed to the decoder in the form they are received, a post-
processing is required at the RTP receiver. This document also
explaines this process in Section 7.
Begen & Friedrich Expires February 13, 2010 [Page 6]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Begen & Friedrich Expires February 13, 2010 [Page 7]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
3. Acronyms
This document uses the following acronyms frequently:
CAT: Conditional access table.
DTS: Decoding timestamp.
ECM: Entitlement control message.
EMM: Entitlement management message.
ES: Elementary stream.
GoP: Group of pictures.
IDR: Instantaneous decoding refresh.
MPEG2-TS: MPEG2 transport stream.
MPTS: Multi program transport stream.
PAT: Program association table.
PCR: Program clock reference.
PMT: Program map table.
PSI: Program specific information.
PTS: Presentation timestamp.
RAP: Random access point.
SPTS: Single program transport stream.
Begen & Friedrich Expires February 13, 2010 [Page 8]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
4. Elements of Delay in Video Systems
For typical multicast-based video delivery systems, the multicast
switching delay (time required to leave the previous multicast
session and join the new session) is not the primary contributor to
the overall acquisition delay. The multicast flows are typically
already present at the edge or deep in the network, the propagation
delays for join operations are modest, and the multicast routers can
typically process the Join and Leave messages quickly. Even if the
edge multicast router is not currently a member of the requested
multicast session, the multicast routing control messages propagate
through the network rapidly and trees are built without experiencing
large delays. Even in cases where a number of tree branches need to
be built to the edge multicast router, this cost is frequently
amortized over a large number of receivers such that only the first
receiver joining the group experiences the increased delay. Further,
this delay can be eliminated at the cost of extra bandwidth in the
network core by having the edge routers do static joins for the set
of sessions they expect receivers to be interested in. These
techniques usually provide a well-bounded multicast switching delay.
Once the join operation completes and a receiver starts receiving
media content for the first time in a multicast session, it often
experiences a considerable amount of Reference Information latency
and buffering delays. In the following subsections, we discuss the
details of these delay elements using MPEG2-TS as the motivating use
case.
4.1. Overview of MPEG-2 Transport Streams
MPEG2-TS is a container format that describes the schema of the audio
and video content and the in-band control information. Prior to
multiplexing, an audio and a video encoder output audio and video
Elementary Streams (ES), respectively. The ES streams are then
packetized to form the Packetized Elementary Streams (PES). The
resulting elements are called PES packets. A transport stream (TS)
encapsulates several PES streams and other data, and carries them in
TS packets. The RTP payload format for carrying TS packets in an RTP
stream is specified in [RFC2250]. In addition to the audio and video
ES streams, there are ES streams that carry control data.
Program Specific Information (PSI) consists of metadata carried in
the transport stream. PSI includes Program Association Table (PAT),
Conditional Access Table (CAT) and Program Map Table (PMT). A PAT
has information about all the programs carried in the transport
stream. It lists the 13-bit Program IDs (PID) for all the PMTs,
associating them with the individual programs. Each of the ES
streams of a particular program in the transport stream also has the
Begen & Friedrich Expires February 13, 2010 [Page 9]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
same PID values. This way, a decoder at the receiving side can
extract the desired TS packets from the transport stream by checking
their PID values. If the transport stream is not a Multi-Program
Transport Stream (MPTS), but rather it is a Single-Program Transport
Stream (SPTS), all the ES streams in the transport stream correspond
to a single program.
CAT defines the type of the scrambling used (either at the PES or TS
level), and identifies all the PID values of the TS packets that
contain the Entitlement Management Messages (EMM). In addition to
containing the PID values of each ES stream associated with a
particular program, the PMT table also includes private data
associated with the program such as the PID value of the packet
containing the Entitlement Control Messages (ECM). The data
contained in the EMM and ECM messages are vital in descrambling
encrypted content. Note that PSI is carried in clear and is never
scrambled so that a receiver which just started receiving the
transport stream can process the PSI. The PAT, CAT and PMT tables
must be parsed by the decoder in order to find the ES streams,
private data as well as the encryption information for a given
program.
MPEG2-TS produces output that is synchronized to a common clock
across all the ESs in the multiplex. To assist the audio and video
decoders, programs periodically provide a Program Clock Reference
(PCR) value in the transport stream. PCR values are embedded in the
TS adaptation field headers and are inserted by the encoder at least
every 100 ms. A PCR timestamp represents the value of the encoder's
system clock when it was sampled. The system clock is driven by a
local 27 MHz oscillator.
PCR is extremely important in native MPEG-2 transport to keep the
decoders synchronized. For example, the periodically sent Decoding
Timestamps (DTS) and Presentation Timestamps (PTS) are specified
relative to the PCR value and the decoders use the PCR value as the
basis for a master clock during decoding and playout.
4.2. Reference Information Latency in Video Applications
We classify the Reference Information latency into two categories.
4.2.1. PSI (PAT/CAT/PMT) Acquisition Delay
As we discussed in Section 4.1, the video (and the audio as well) in
an MPEG2-TS is self describing, and the receiver must parse certain
control information in the PAT, CAT and PMT tables (i.e., PSI)
contained in the transport stream in order to know how to parse the
rest of the stream (i.e., to find the audio and video elementary
Begen & Friedrich Expires February 13, 2010 [Page 10]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
streams, private data and the encryption information for a given
program).
Many video services employ content encryption and the encryption keys
must be parsed as well for decrypting the content. In order to
enable various system elements to process video effectively, certain
portions of the stream are left unencrypted. The PAT/PMT tables are
always in the clear. The structure of the ECMs is also in the clear,
although the ECM content which contains keying material is encrypted.
The PSI information is repeated periodically in the transport stream,
thus, when a receiver joins the multicast session, it needs to wait
until the next time PSI is sent in the transport stream.
4.2.2. Random Access Point Acquisition Delay
Conventional MPEG2 video encoders encode the video content in Groups
of Pictures (GoP). Each GoP is encoded independently from other GoPs
and starts with an intra-coded frame (I-frame) that does not have any
reference to other frames in the same GoP, i.e., an I-frame contains
the representation of an entire picture and can be decoded
independently. Thus, the start of an I-frame is said to be a Random
Access Point (RAP).
On the other hand, due to the temporal compression, rest of the
frames in the same GoP may have references to the I-frame or to other
frames in the same GoP. Due to this interdependency among the
frames, one generally has to receive certain elements of the GoP
prior to decoding or rendering any part of the GoP. For example, the
decoder can decode a frame that is dependent on two other frames only
after these two frames are decoded.
Usually, GoP durations are between 500 ms and one second. However,
more advanced codecs may use longer GoPs to gain from the encoding
efficiency. When a receiver joins the multicast session, it needs to
wait until the next RAP shows up in the multicast stream before it
can start decoding. Since the frame that is currently being
multicast does not depend on the join time, the average time a
receiver waits for RAP, i.e., the average RAP acquisition delay, is
approximately equal to half of the GoP duration. Hence, for longer
GoPs, the RAP acquisition delay is proportionally longer.
Advanced Video Coding (AVC) (also called MPEG4 part 10) compression
is very similar to MPEG2 compression. It has a few more compression
tools available, including Hierarchical GoPs. In a hierarchical GoP,
the dependent frames of a GoP may reference the key frame at the
start of this GoP or the key frame at the start of the next GoP.
This additional dependency causes a longer RAP acquisition delay, as
the decoder must receive two I-frames (spread between two logical
Begen & Friedrich Expires February 13, 2010 [Page 11]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
GoPs) before decoding can commence. In an Open GOP, a frame in one
GoP may refer to a frame in a previous GoP. AVC also has the ability
to insert Instantaneous Decoding Refresh (IDR) frames. Frames that
follow an IDR frame cannot reference frames that precede an IDR
frame. IDR frames are useful for editing AVC streams, but are
typically do not appear often enough in streaming video to be useful
in a stream synchronization context.
Note that in order for an intermediary network element such as a
retransmission server to find the random access points in the video
stream (e.g., I-frames), the necessary structural information must be
in the clear if the intermediary is not in possession of the
necessary keys.
4.3. Buffering Delays in Video Applications
We classify the buffering delays into two categories.
4.3.1. Network-Related Buffering Delays
In general, multicast-based video applications use an unreliable
underlying transport protocol such as UDP [RFC0768] to distribute the
content to a large number of receivers. This is largely due to the
fact that these applications are one way in nature and providing
closed-loop reliability does not scale well when the number of
receivers is large or the acceptable playout delay is small, or both.
Rather, if there is a need for reliability, the applications may
employ one or more loss-repair methods to recover the packets missing
at each receiver (The Reliable Multicast Transport Working Group has
several standardized solutions for this problem. Refer to
[I-D.ietf-rmt-pi-norm-revised] for details). For example, Forward
Error Correction (FEC) may be used proactively and/or on-demand to
provide reliable transmission to a potentially very large multicast
group in a scalable manner [I-D.ietf-fecframe-framework]. Similarly,
retransmissions may be used in RTP-based multicast sessions where the
retransmissions can be handled by local repair servers rather than
the source itself [I-D.ietf-avt-rtcpssm]. However, regardless of the
type of the loss-repair method(s) adopted by an application, loss-
recovery operations always require additional buffering at the
receiver side. The amount of buffering increases with the FEC block
size when FEC is used, and with the round-trip time between the
receiver and the local repair server when retransmission is used.
Audio and video decoders demand almost jitter-free content. If any
jitter is introduced during the transmission in the network or due to
the loss-repair methods, the jitter has to be smoothed out before the
content is fed to the decoder. This is called de-jittering and it
usually adds up to the buffering delay.
Begen & Friedrich Expires February 13, 2010 [Page 12]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
4.3.2. Application-Related Buffering Delays
The application buffering requirements for MPEG-encoded content are
quite rigorous, particularly for the MPEG-based video applications.
Video compression devices apply more bits to represent certain scenes
than they do for other scenes. A very complex scene (individual
picture) requires considerably more information than a simple scene.
Furthermore, pictures that are entirely intra-coded, e.g., I-frames,
consume more bits compared to pictures that make use of predictive
coding. Each scene is shown by the decoder at a certain fixed frame
rate (e.g., 24 fps or 30 fps). Since some scenes are comprised more
bits than other scenes, the output rate of the decoder buffer is
usually variable. However, the network flow is typically Constant
Bit Rate (CBR) or Capped Variable Bit Rate (Capped VBR). The net
effect is that the input rate to the decoder buffer is close to
constant, but the output rate is highly variable.
The video encoders keep track of the decoder buffer size, and use
this information to regulate the temporal compression. This forces
the decoder buffer to "breathe." In order to avoid underflow, the
decoder buffer must fill up to a certain level prior to starting to
decode and play the content. The decoder buffer size required to
avoid underflow is dependent on the encoder, and the encoder signals
the decoder buffering requirements in-band. Typical decoder buffer
requirements for MPEG2 content range from a few hundreds of
milliseconds to a few seconds. However, AVC/MPEG4 part 10 encoders
usually tend to use more temporal compression, and thus require a
larger buffer at the decoder side. This consequently increases the
buffering delays.
Begen & Friedrich Expires February 13, 2010 [Page 13]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
5. Packet Format
This section defines the MPEG2-TS Preamble packet format.
The RTP header is formatted according to [RFC3550] with some further
clarifications listed below:
o Marker (M) Bit: This bit SHALL be used to indicate the last
packet carrying the MPEG2-TS Preamble information. It SHALL be
set to zero in all RTP packets other than the last packet.
o Payload Type: The (dynamic) payload type for the MPEG2-TS
Preamble packets is determined through out-of-band means. Note
that this document registers a new payload format for the MPEG2-TS
Preamble packets (Refer to Section 6 for details). According to
[RFC3550], an RTP receiver that cannot recognize a payload type
must discard it. This provides backward compatibility.
o Sequence Number (SN): The sequence number has the standard
definition. It MUST be one higher than the sequence number in the
previously transmitted RTP packet in the same session. If this
RTP packet is the first packet in the session, its sequence number
SHOULD be random (unpredictable) [RFC3550].
o Timestamp (TS): The timestamp SHALL be set to a time
corresponding to the packet's transmission time.
Editor's note: This is TBD.
o Synchronization Source (SSRC): Per [RFC3550], the SSRC value
SHOULD be chosen randomly with collision detection. However, in
practice the MPEG2-TS Preamble packets can be (payload-type)
multiplexed with retransmission packets in a single RTP session.
In that case, the same SSRC value with the retransmission RTP
session MUST be used.
The payload consists of TLOV elements that are defined in
Section 5.2. Before defining them, we first introduce the TLOV
structure.
5.1. Extensions
The MPEG2-TS Preamble MUST be encoded as TLOV elements as described
below and sketched in Figure 1:
o Type: A single-octet identifier that defines the type of the
parameter represented in this TLOV element.
Begen & Friedrich Expires February 13, 2010 [Page 14]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
o Length: A two-octet field that indicates the length of the TLOV
element excluding the Type and Length fields in octets. Note that
this length does not include any padding that is required for
alignment.
o Order: A single-octet identifier that specifies the order in
which this TLOV element MUST be processed by the receiver when
forming a demux/decoder-friendly stream. As explained in
Section 7, the order information is crucial for majority of the
TLOV elements defined in this document. Yet, for some other TLOV
elements, the order may not matter. In that case, the Order value
MAY be set to 0.
Starting from 1, a lower Order value indicates an earlier order in
post-processing and the Order values MUST be consecutive. Note
that none of the TLOV elements that belong to the same Preamble
data MUST have the same Order value except 0.
o Value: Variable-size set of octets that contains the specific
value for the parameter. Note that the value field of an TLOV
element may contain other TLOVs.
If a TLOV element does not fall on a 32-bit boundary, the last word
must be padded to the boundary using further bits set to 0. The
support for extensions is OPTIONAL.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Structure of a TLOV element
5.1.1. Vendor-Neutral Extensions
If the goal in defining new TLOV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 10.2.
The current document defines several vendor-neutral extensions in
Section 5.2.
Begen & Friedrich Expires February 13, 2010 [Page 15]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
5.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLOV
format. For interoperability, such extensions MUST NOT collide with
each other.
A certain range of TLOV Types is reserved for private extensions
(Refer to Section 10.2). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is
depicted in Figure 2. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Structure of a private extension
5.2. Vendor-Neutral Extensions
The current document defines several vendor-neutral extensions. In
the following extensions, we use 'r' to indicate a reserved bit,
which SHALL be set to zero. The fields denoted by 'Reserved' SHALL
also be set to zero.
Editor's note: Which TLOVs are optional or mandatory will be decided
in a future version.
5.2.1. PAT TLOV
Optional TLOV element that is used to encode information associated
with a Program Association (PA) section as defined in Section 2.4.4.3
of [MPEG2TS]. It has the following structure:
Begen & Friedrich Expires February 13, 2010 [Page 16]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAT_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Structure of PAT TLOV
The PID is a 13-bit field used to identify the ES in an MPTS or SPTS.
This is the PID used in the associated TS to carry the PA section
data. Its value MUST be 0. The Section Length field is a 16-bit
field that specifies the length of the Section Data in octects. The
Section Data is a PA section as defined in Section 2.4.4.3 of
[MPEG2TS]. Note that the length of the PAT TLOV is variable.
Type: TBD
Length: Variable
5.2.2. PMT TLOV
Optional TLOV element that is used to encode information associated
with a Program Map (PM) section. It has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PMT_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of PMT TLOV
The PID is used in the associated TS to carry the PM section data.
The Section Length field is a 16-bit field that specifies the length
of the Section Data in octects. The Section Data is a PM section.
Note that the length of the PMT TLOV is variable.
Type: TBD
Begen & Friedrich Expires February 13, 2010 [Page 17]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Length: Variable
5.2.3. PCR TLOV
Optional TLOV element that contains a PCR value used to initalize the
decoder and system clocks. The PCR value corresponds to the first
byte of the first TS packet that will be transmitted. It has the
following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCR_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Reserved | PCR_EXT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCR_BASE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of PCR TLOV
The PID is used in the associated TS to carry the PCR data. PCR_BASE
is a 33-bit field that is part of the PCR timestamp. PCR_BASE
occupies the entire third 32-bit word along with the first bit of the
fourth word. The remainder of the fourth word (31 bits) is reserved.
PCR_EXT is a 9-bit field that is part of the PCR timestamp.
Type: TBD
Length: 12
5.2.4. PID_LIST TLOV
A PID is a packet identifier that is used to identify ESs of a
program in an SPTS or MPTS. The PID_LIST contains a PID Element for
each PID referenced in the MPEG2-TS Preamble. Each PID Element
contains the PID and associated continuity counter that corresponds
to the first packet that will be sent.
PID_LIST TLOV It has the following structure:
Begen & Friedrich Expires February 13, 2010 [Page 18]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PID_L_TLOV_Type| Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Structure of PID_LIST TLOV
And the PID Element has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r|r r r r| CC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of PID Element
Type: TBD
Length: Variable
5.2.5. SEQ TLOV
Optional TLOV element that is used to encode information from the
Video Sequence Header of an MPEG2 Video ES. The Video Sequence
Header contains information such as frame rate, aspect ratio and
picture size. It has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEQ_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begen & Friedrich Expires February 13, 2010 [Page 19]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Figure 8: Structure of SEQ TLOV
The PID is used in the associated TS to carry the SEQ section data.
The Section Length field is a 16-bit field that specifies the length
of the Section Data in octects. The Section Data is a SEQ section.
See Section 6.2.2 of [ISO13818-2] for a discussion of Video Sequence
Header and Sequence Extension.
Note that SEQ TLOV is only applicable to transport streams that carry
MPEG2 video.
Type: TBD
Length: Variable
5.2.6. SPS TLOV
Optional TLOV element that is used to encode information from the
Sequence Parameter Set Network Abstraction Layer (NAL) unit. It has
the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPS_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Structure of SPS TLOV
The PID is used in the associated TS to carry the SPS section data.
The Section Length field is a 16-bit field that specifies the length
of the Section Data in octects. The Section Data is a SPS section.
See Section 7.4.2.1 of [ISO13818-10] for a discussion of semantics of
the Sequence Parameter Set NAL.
Note that SPS TLOV is only applicable to transport streams that carry
AVC (H.264) video.
Type: TBD
Length: Variable
Begen & Friedrich Expires February 13, 2010 [Page 20]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
5.2.7. PPS TLOV
Optional TLOV element that is used to encode information from the
Picture Parameter Set NAL unit. It has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPS_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Structure of PPS TLOV
The PID is used in the associated TS to carry the PPS section data.
The Section Length field is a 16-bit field that specifies the length
of the Section Data in octects. The Section Data is a PPS section.
See Section 7.4.2.2 of [ISO13818-10] for a discussion of semantics of
the Picture Parameter Set NAL.
Note that PPS TLOV is only applicable to transport streams that carry
AVC (H.264) video.
Type: TBD
Length: Variable
5.2.8. SEI TLOV
Optional TLOV element that is used to encode information from the
Supplemental Enhanced Information NAL unit.. It has the following
structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEI_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begen & Friedrich Expires February 13, 2010 [Page 21]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Figure 11: Structure of SEI TLOV
The PID is used in the associated TS to carry the SEI section data.
The Section Length field is a 16-bit field that specifies the length
of the Section Data in octects. The Section Data is a SEI section.
See Annex D of [ISO13818-10] for details.
Note that SEI TLOV is only applicable to transport streams that carry
AVC (H.264) video.
Type: TBD
Length: Variable
5.2.9. ECM TLOV
Optional TLOV element that contains the ECM from the MPEG2-TS. This
applies only to transport streams that are encrypted. It has the
following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECM_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Structure of ECM TLOV
Section Data depends on type of encryption used. Details are TBD.
Type: TBD
Length: Variable
5.2.10. EMM TLOV
Optional TLOV element that contains the EMM from the MPEG2-TS. This
applies only to transport streams that are encrypted. It has the
following structure:
Begen & Friedrich Expires February 13, 2010 [Page 22]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMM_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Structure of EMM TLOV
Section Data depends on type of encryption used. Details are TBD.
Type: TBD
Length: Variable
5.2.11. CAT TLOV
Optional TLOV element that is used to encode information associated
with a Conditional Access (CA) section as defined in Section 2.4.4.6
of [MPEG2TS]. It has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAT_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Section Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Section Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Structure of CAT TLOV
The PID is a 13-bit field used to identify the ES in an MPTS or SPTS.
This is the PID used in the associated TS to carry the CA section
data. The Section Length field is a 16-bit field that specifies the
length of the Section Data in octects. The Section Data is a CA
section as defined in Section 2.4.4.6 of [MPEG2TS]. Details are TBD.
Type: TBD
Length: Variable
Begen & Friedrich Expires February 13, 2010 [Page 23]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
5.2.12. PTS TLOV
Optional TLOV element that is used to encode the PTS timestamp
corresponding to the first picture in the unicast repair burst. It
has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PTS_TLOV_Type | Length | Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID |r r r| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PTS_BASE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Structure of PTS TLOV
The PID is used to identify the associated TS to carry the PTS data.
PTS_BASE is a 33-bit field that is taken from the PES header of the
MPEG2-TS that will be sent. Note that this TLOV is purely
informational.
Type: TBD
Length: 12
Begen & Friedrich Expires February 13, 2010 [Page 24]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
6. Payload Format Parameters
This section provides the media subtype registration for the MPEG2-TS
Preamble.
6.1. Media Type Registration
This registration is done using the template defined in [RFC4288] and
following the guidance provided in [RFC3555].
6.1.1. Registration of audio/mpeg2-ts-preamble
Type name: audio
Subtype name: mpeg2-ts-preamble
Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: None.
Published specification: This document.
Applications that use this media type: Applications that transmit
MPEG2-TS content and want to provide the Preamble information for the
transport stream they are transmitting to the receiver(s).
Additional information: None.
Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON.
Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>.
Begen & Friedrich Expires February 13, 2010 [Page 25]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG.
6.1.2. Registration of video/mpeg2-ts-preamble
Type name: video
Subtype name: mpeg2-ts-preamble
Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: None.
Published specification: This document.
Applications that use this media type: Applications that transmit
MPEG2-TS content and want to provide the Preamble information for the
transport stream they are transmitting to the receiver(s).
Additional information: None.
Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON.
Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG.
6.1.3. Registration of text/mpeg2-ts-preamble
Type name: text
Begen & Friedrich Expires February 13, 2010 [Page 26]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Subtype name: mpeg2-ts-preamble
Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: None.
Published specification: This document.
Applications that use this media type: Applications that transmit
MPEG2-TS content and want to provide the Preamble information for the
transport stream they are transmitting to the receiver(s).
Additional information: None.
Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON.
Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG.
6.1.4. Registration of application/mpeg2-ts-preamble
Type name: application
Subtype name: mpeg2-ts-preamble
Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
Begen & Friedrich Expires February 13, 2010 [Page 27]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: None.
Published specification: This document.
Applications that use this media type: Applications that transmit
MPEG2-TS content and want to provide the Preamble information for the
transport stream they are transmitting to the receiver(s).
Additional information: None.
Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON.
Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG.
6.2. Mapping to SDP Parameters
Applications that are using RTP transport commonly use Session
Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
The information that is used to specify the media types in an RTP
session has specific mappings to the fields in an SDP description.
In this section, we provide these mappings for the media subtype
registered by this document ("mpeg2-ts-preamble"). Note that if an
application does not use SDP to describe the RTP sessions, an
appropriate mapping must be defined and used to specify the media
types and their parameters for the control/description protocol
employed by the application.
The mapping of the media type specification for "mpeg2-ts-preamble"
and its parameters in SDP is as follows:
Begen & Friedrich Expires February 13, 2010 [Page 28]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
o The media type (e.g., "application") goes into the "m=" line as
the media name.
o The media subtype ("mpeg2-ts-preamble") goes into the "a=rtpmap"
line as the encoding name. The RTP clock rate parameter ("rate")
also goes into the "a=rtpmap" line as the clock rate.
SDP examples are provided in Section 8.
6.2.1. Offer-Answer Model Considerations
TBC.
6.2.2. Declarative Considerations
TBC.
Begen & Friedrich Expires February 13, 2010 [Page 29]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
7. Post-Processing of the MPEG2-TS Preamble
Once received, the RTP packet(s) carrying the MPEG2-TS Preamble
cannot be fed directly to the MPEG transport demux and decoder since
the demux and decoder would not be able to recognize the TLOV
elements within the Preamble packets. Thus, the Preamble information
must be first processed and a demux/decoder-friendly stream must be
formed. The demux/decoder-friendly stream must conform to [MPEG2TS].
In this section, we briefly explain this process.
The Preamble TLOV elements contain several different types of
Transport Stream data. The first type is Program Specific
Information (PSI) Section Data. The second type is PCR Data, and the
third is Elementary Stream Data.
1. Section Data
This includes the PAT TLOV, PMT TLOV and CAT TLOV. This section
data also include ECMs or EMMs encapsulated in private sections
as per [DVB-ETR-289]. These packets are all processed similarly.
Each TS packet begins with a 4-byte TS header containing the PID
value given in the Preamble TLOV element. There is no adaptation
field present. The continuity counter value can be retrieved
from the PIDLIST TLOV element for the current PID. If the TS
packet contains the beginning of the Section, the Payload Unit
Start Indicator (PUSI) bit should be set in the TS header. Also,
a 1-byte pointer field follows the TS header, which should be set
to 0. The section data immediately follow the pointer field. If
the section data span multiple TS packets, they are recreated in
a similar manner, except without the PUSI bit set and the
pointer_field.
The continuity counter value of a packet must be one greater than
the previous packet on that PID. This applies to packets
reconstructed from the Preamble TLOV elements and packets from
the MPEG2-TS stream. The continuity counter value of the final
packet of Preamble data should be one less than the first packet
on the MPEG2-TS stream with that same PID.
The final TS packet may contain stuffing bytes of 0xFF as
necessary to pad the packet to 188 bytes.
2. PCR Data
A single TS packet is constructed from the PCR TLOV. This
contains a 4-byte TS header with correct PID and continuity
counter as retrieved from the PIDLIST. The Adaptation Field
Begen & Friedrich Expires February 13, 2010 [Page 30]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
control bits should indicate that only an adaptation_field and no
payload is present. The adaptation field should contain the PCR
value from the PCR TLOV followed by padding to fill the TS
packet. The discontinuity_indicator in the Adaptation Field
should be set to one.
3. Elementary Stream Data
The final type of Preamble data is that contained in an
elementary stream. This includes data from the SEQ, SPS, PPS and
SEI TLOVs. Each TS packet begins with a 4-byte TS header
containing the PID value given in the Preamble TLOV element. The
adaptation field padding can be used to pad the last TS packet to
188 bytes. The continuity counter value can be retrieved from
the PIDLIST TLOV element for the current PID. If the TS packet
contains the beginning of the TLOV element, the Payload Unit
Start Indicator (PUSI) bit should be set in the TS header. A PES
header must immediately follow the start of the first TS packet.
The stream_type of the PES packet should match the contents of
elementary stream data.
The TS packets constructed as above MUST be passed to the demux/
decoder in the following order: PAT, PMT, PCR, EMM, ECM, {Elementary
Stream Data}. The PAT and PMT MUST be the first two packets because
they contain required information to program the demux. The EMM and
ECM MUST occur before Elementary stream data because they contain
conditional access data that will be needed to descramble and decode
the elementary stream.
Begen & Friedrich Expires February 13, 2010 [Page 31]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
8. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example.
TBC.
Begen & Friedrich Expires February 13, 2010 [Page 32]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
9. Security Considerations
TBC.
Begen & Friedrich Expires February 13, 2010 [Page 33]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
10. IANA Considerations
10.1. Payload Format
New media subtypes are subject to IANA registration. For the
registration of the payload format and its parameters introduced in
this document, refer to Section 6.
10.2. MPEG2-TS Preamble TLOV Space Registry
This document creates a new IANA TLOV space registry for the
extensions. The registry is called the MPEG2-TS Preamble TLOV Space
Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226].
The length of the Type field in the TLOV elements is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Type Description Reference
---- -------------------------------------------------- -------------
TBD TBD This document
... ...
The registry entries are TBC.
The Type values 0 and 256 are reserved for future use. The Type
values between (and including) 128 and 255 are reserved for private
extensions.
Any registration for an unassigned Type value MUST contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new TLOV element represents and
how it shall be interpreted.
Begen & Friedrich Expires February 13, 2010 [Page 34]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
11. Open Issues
o Finalizing the TLOV structures.
o Security and SDP sections.
Begen & Friedrich Expires February 13, 2010 [Page 35]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
12. Acknowledgments
TBC.
Begen & Friedrich Expires February 13, 2010 [Page 36]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[MPEG2TS] ITU-T H.222.0, "Generic Coding of Moving Pictures and
Associated Audio Information: Systems", May 2006.
[ISO13818-2]
ITU-T H.262, "Generic Coding of Moving Pictures and
Associated Audio Information: Video", February 2000.
[ISO13818-10]
ITU-T H.264, "Advanced Video Coding for Generic
Audiovisual Services", March 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
13.2. Informative References
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-01 (work in
progress), June 2009.
[RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar,
"RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
January 1998.
[I-D.ietf-avt-rtcpssm]
Begen & Friedrich Expires February 13, 2010 [Page 37]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in
progress), March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker,
"NACK-Oriented Reliable Multicast Transport Protocol",
draft-ietf-rmt-pi-norm-revised-13 (work in progress),
June 2009.
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-05 (work in progress),
July 2009.
[DVB-ETR-289]
DVB ETR-289, "Digital Video Broadcasting (DVB); Support
for use of scrambling and Conditional Access (CA) within
digital broadcasting systems", October 1996.
Begen & Friedrich Expires February 13, 2010 [Page 38]
Internet-Draft RTP Payload Format for MPEG2-TS Preamble August 2009
Authors' Addresses
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Eric Friedrich
Cisco Systems
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Email: efriedri@cisco.com
Begen & Friedrich Expires February 13, 2010 [Page 39]