One document matched: draft-xia-avt-mpeg2ts-preamble-00.txt
Network Working Group F. Xia
Internet-Draft X. Wu
Expires: April 22, 2010 Huawei
October 19, 2009
Preamble Acquisition of MPEG-TS Multicast Sessions
draft-xia-avt-mpeg2ts-preamble-00.txt
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 April 22, 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.
Xia & Wu Expires April 22, 2010 [Page 1]
Internet-Draft Preamble Acquisition October 2009
Abstract
MPEG2-TS is a container format that describes the schema of the
audio, video content and the in-band control information. The format
information called MPEG2-TS preamble must be acquired before a RTP
receiver processed any data received in MPEG2-TS. In this document,
a Retransmission Server is specified to deliver MPEG2-TS preamble
prior to unicast RTP packets. The Retransmission Server caches raw
RTP packets with MPEG2-TS preamble information, and sends them to the
RTP receiver which initiates rapid acquisition of MPEG2-TS multicast
sessions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of MPEG-2 Transport Streams . . . . . . . . . . . . . 3
4. Preamble Acquisition of MPEG2-TS Multicast Sessions . . . . . 4
4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Unicast PSI RTP Packet Format . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Xia & Wu Expires April 22, 2010 [Page 2]
Internet-Draft Preamble Acquisition October 2009
1. Introduction
Multimedia multicast flows usually carry streams of inter-related
data. Certain information must first be acquired by the receivers to
start processing multimedia data sent in the multicast session.
[I-D.ietf-avt-rapid-acquisition-for-rtp] refers to this information
as Reference Information. The Reference Information is
conventionally sent periodically in the multicast session and usually
consists of items such as a description of the schema for the rest of
the data, references to which data to process, encryption information
including keys, as well as any other information required to process
the data in the primary multicast stream.
When a multicast flow is used for carrying MPEG2 Transport Stream
(MPEG2-TS),the Reference Information is usually called MPEG2-TS
preamble. MPEG2-TS [ISO13818-1] is an encapsulation and transport
method that multiplexes video and audio content, together with
ancillary metadata, and produces a synchronized multiplexed stream.
A receiver must first acquire the metadata before demultiplexing and
decoding an incoming MPEG2-TS. However, MPEG2-TS preamble does often
not reside in MPEG2-TS contiguously and is usually dispersed over a
large period. Thus, the 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.
[I-D.begen-avt-rtp-mpeg2ts-preamble] details the problem, and defines
new messages to carry MPEG-TS preamble.
Comparing to [I-D.begen-avt-rtp-mpeg2ts-preamble], an alternative is
proposed here for carrying MPEG-TS preamble without defining any new
messages in this document. A retransmission server identifies MPEG-
TSes carrying preamble information, buffers these TSes, and sends
them out when a receiver join the multicast MPEG2-TS session.
2. Terminology
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].
3. Overview of MPEG-2 Transport Streams
MPEG-2 Transport Stream is a communications protocol for audio,
video, and data. It is a type of container format that encapsulates
Packetized Elementary Streams(PES) and other data. A transport
stream as illustrated in Figure 1 is specified in MPEG-2 Part 1,
Systems [ISO13818-1]. It is also known as ITU-T Rec. H.222.0. Its
Xia & Wu Expires April 22, 2010 [Page 3]
Internet-Draft Preamble Acquisition October 2009
design goal is to allow multiplexing of video and audio and to
synchronize the output.
video +-------------+ +----------+ Video PES +---------+
input--->|Video Encoder|--->|Packetizer|---------->| |
+-------------+ +----------+ | |
| |
Audio +-------------+ +----------+ Audio PES |MPEG-2 |
input--->|Audio Encoder|--->|Packetizer|---------->| | Network
+-------------+ +----------+ |Transport|---->
| |
Optional Application Data(e.g subtitle)---> |Stream |
| |
Program Specific Information---> |Mux |
| |
... ...---> | |
+---------+
Figure 1: MPEG-2 Transport Streams
As illustrated in Figure 1, Program Specific Information (PSI)
consists of metadata carried in the transport stream. PSI includes
Program Association Table (PAT), Conditional Access Table (CAT),
Program Map Table (PMT) and other information. 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. In this document, terminologies PSI and
MPEG2-TS preamble are interchangeable.
Media including video, audio and text 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 streams, private data and the
encryption information for a given program). This document specifies
a mechanism to acquire PSI rapidly when a receiver joins in a
MPEG2-TS multicast session.
4. Preamble Acquisition of MPEG2-TS Multicast Sessions
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
Xia & Wu Expires April 22, 2010 [Page 4]
Internet-Draft Preamble Acquisition October 2009
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 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.
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. to reduce the acquisition time when the RTP receiver joins
a multicast session at a random point in time,
[I-D.ietf-avt-rapid-acquisition-for-rtp] introduces the concept of
the Burst Source and new RTCP feedback messages as illustrated in
Figure 2. The Burst Source has a cache where the most recent packets
from the primary multicast session are continuously stored. The
feedback target is the entity to process RTP receiver's request for
rapidly acquiring the primary multicast stream.
[I-D.ietf-avt-rapid-acquisition-for-rtp] details the procedure of
rapid acquisition, at the same time, unicast PSI RTP transport is
highlighted in this document.
o The retransmission server contiguously parses the primary
multicast stream, and search for a MPEG2-TS with 0 Program Map ID
(PID). the Transport stream with PID 0 is Program Association
Table(PAT) which further lists all programs available in the
transport stream. Each of the programs listed in PAT has an
associated value of PID for its Program Map Table (PMT). The
retransmission server stores the TS with PAT information.
o The retransmission server then further search for TSes with PMT
information through the PIDs indicated in the PAT. The
retransmission server also stores these identified TSes.
o The retransmission server caches TS with PID 1 which includes
Conditional Access Table(CAT).
Some other preamble information included in different TSes is also
identified and stored in the retransmission server. These cached
TSes will be packed into unicast PSI RTP packets for preamble
acquisition, as is illustrated in the following sections.
Xia & Wu Expires April 22, 2010 [Page 5]
Internet-Draft Preamble Acquisition October 2009
+----------------------------------------------+
| Retransmission Server (RS) |
| +----------+ +---------------------------+ |
| | Feedback | | Burst/Retransmission | |
| | Target | | Source (including PSI) | |
| +----------+ +---------------------------+ |
+----------------------------------------------+
^ ^ :
| ' :
| ' v
+-----------+ +----------+ +----------+
| | | |'''''''''''>| |
| Multicast |------->| Router |...........>| RTP |
| Source | | |<~~~~~~~~~~~| Receiver |
| | | |----------->| (RR) |
+-----------+ +----------+ +----------+
'''> Unicast RTCP Messages
~~~> SFGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 2: Unicast-based Rapid Acquisition
4.1. Message Flow
Figure 3 depicts message flows for PSI acquisition. A RTP receiver
sends a rapid acquisition request for a new multicast RTP session to
the feedback target address of that session. This RTCP feedback
message is defined as the RAMS-Request (RAMS-R) message in
[I-D.ietf-avt-rapid-acquisition-for-rtp] and MAY also contain
parameters, such as the bandwidth limit, buffering capacity available
at the RTP receiver, and so on.
A retransmission server receives the RAMS-R message and sends an
RAMS-Information (RAMS-I) message to the RTP receiver. The first
RAMS-I message MAY precede the unicast burst or it MAY be sent during
the burst. The retransmission server then starts sending unicast PSI
RTP packets prior to delivering Unicast RTP Burst.
In this document, a "unicast PSI RTP" delivering process is added
here for transporting necessary MPEG2-TS preamble information.
Section 4.2 details the format of the unicast PSI RTP Packets. Other
details can be referred to in
[I-D.ietf-avt-rapid-acquisition-for-rtp].
Xia & Wu Expires April 22, 2010 [Page 6]
Internet-Draft Preamble Acquisition October 2009
+-----------+ +----------------+ +----------+ +------------+
| Multicast | | Retransmission | | | | RTP |
| Source | | Server | | Router | | Receiver |
| | | (RS) | | | | (RR) |
+-----------+ +----------------+ +----------+ +------------+
| | | |
|-- RTP Multicast ------------------->| |
| | | |
|-- RTP Multicast ->| | |
| | | |
| |<'''''''''''''''''' RTCP RAMS-R ''|
| | | |
| | | |
| |'' (RTCP RAMS-I) ''''''''''''''''>|
| | | |
| |....... Unicast PSI RTP .........>|
| | | |
| |....... Unicast RTP Burst .......>|
| | | |
| |<''''''''''''''''''(RTCP RAMS-R)''|
| | | |
| | | |
| |'' (RTCP RAMS-I) ''''''''''''''''>|
| | | |
| | |<~ SFGMP Join ~~|
| | | |
|-- RTP Multicast ------------------------------------>|
| | | |
~ ~ ~ ~
| | | |
'''> Unicast RTCP Messages
~~~> SFGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 3: Message flows for Preamble Acquisition
4.2. Unicast PSI RTP Packet Format
Unicast PSI RTP packets have the format of a retransmission packet
which is depicted in [RFC4588] as following:
Xia & Wu Expires April 22, 2010 [Page 7]
Internet-Draft Preamble Acquisition October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
of unicast RTP burst. It SHALL be set to zero for PSI RTP packets
if any unicast RTP packet followed, otherwise it SHOULD be set 0.
o Payload Type: The same payload type as unicast RTP Burst packets
is used in all unicast PSI RTP packets.
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.
o Timestamp (TS): The timestamp SHALL be set to a time corresponding
to the packet's transmission time.
o Synchronization Source (SSRC): the SSRC values MUST be the same as
unicast RTP burst packets.
OSN (original sequence number) field is used for the sequence number
of the associated original RTP packet in [RFC4588]. In this
document, PSI RTP packets are newly generated by the retransmission
server, and are treated by the receiver as the same session as
unicast RTP burst. The OSNs of PSI RTP packets are thus determined
by the OSN of the first unicast RTP burst packets. For example,
there are two unicast PSI RTP packets while the OSN of the first
unicast RTP burst packets is n, the OSN fields of the two PSI RTP
packets MUST be n-2, n-1 respectively.
"Original RTP Packet Payload" field is used to carry stored TSes with
MPEG2-TS preamble information.
5. Security Considerations
Comparing to [I-D.ietf-avt-rapid-acquisition-for-rtp], this document
specifies delivering PSI information to a RTP receiver prior to
unicast RTP burst packets. PSI is key information for a decoder to
parse MPEG2-TS streaming packets, and any tampered PSI results in
denial of service of the RTP receiver. Security considerations in
Xia & Wu Expires April 22, 2010 [Page 8]
Internet-Draft Preamble Acquisition October 2009
[I-D.ietf-avt-rapid-acquisition-for-rtp] also applies.
6. Acknowledgements
TBD.
7. References
7.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.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[ISO13818-1]
"Generic coding of moving pictures and associated audio
information: Systems", December 2000.
7.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-04 (work in
progress), October 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A. and E. Friedrich, "RTP Payload Format for
MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in
progress), August 2009.
Xia & Wu Expires April 22, 2010 [Page 9]
Internet-Draft Preamble Acquisition October 2009
Authors' Addresses
Frank Xia
Huawei
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Xinfen Wu
Huawei
Baixia Road No. 91
Nanjing, China 210001
Phone: +86 25 84565870
Email:
Xia & Wu Expires April 22, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 05:33:26 |