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]