idnits 2.17.1 draft-begen-avt-rtp-mpeg2ts-preamble-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 27, 2010) is 4959 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEG2TS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO13818-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO13818-10' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-15 == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-10 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft E. Friedrich 4 Intended status: Standards Track Cisco 5 Expires: March 31, 2011 September 27, 2010 7 RTP Payload Format for MPEG2-TS Preamble 8 draft-begen-avt-rtp-mpeg2ts-preamble-06 10 Abstract 12 Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS) 13 requires the knowledge of specific information about the transport 14 stream, which we refer to as the MPEG2-TS Preamble. While this 15 information is spread over different locations throughout the 16 transport stream and can be eventually assembled after some time a 17 receiver started receiving the MPEG2-TS, the time it takes to 18 retrieve all this information (especially in multicast environments) 19 may be long. Instead, having this information readily available as a 20 Preamble and sending the Preamble to a receiver that will shortly 21 start receiving the transport stream will virtually eliminate the 22 waiting time and let the receiver start processing/decoding the 23 MPEG2-TS sooner. In this document, we give an overview of the 24 MPEG2-TS and the delay components in video systems, and motivate the 25 need for constructing and using the MPEG2-TS Preamble for rapidly 26 acquiring the source stream in RTP multicast sessions. We also 27 define and register the RTP payload format for the MPEG2-TS Preamble. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 31, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 65 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Elements of Delay in Video Systems . . . . . . . . . . . . . . 8 67 4.1. Overview of MPEG-2 Transport Streams . . . . . . . . . . . 8 68 4.2. Reference Information Latency in Video Applications . . . 9 69 4.2.1. PSI (PAT/CAT/PMT) Acquisition Delay . . . . . . . . . 9 70 4.2.2. Random Access Point Acquisition Delay . . . . . . . . 10 71 4.3. Buffering Delays in Video Applications . . . . . . . . . . 11 72 4.3.1. Network-Related Buffering Delays . . . . . . . . . . . 11 73 4.3.2. Application-Related Buffering Delays . . . . . . . . . 12 74 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 15 77 5.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 15 78 5.2. Vendor-Neutral Extensions . . . . . . . . . . . . . . . . 15 79 5.2.1. PAT TOLV . . . . . . . . . . . . . . . . . . . . . . . 15 80 5.2.2. PMT TOLV . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.2.3. PCR TOLV . . . . . . . . . . . . . . . . . . . . . . . 17 82 5.2.4. PID_LIST TOLV . . . . . . . . . . . . . . . . . . . . 17 83 5.2.5. SEQ TOLV . . . . . . . . . . . . . . . . . . . . . . . 18 84 5.2.6. SPS TOLV . . . . . . . . . . . . . . . . . . . . . . . 19 85 5.2.7. PPS TOLV . . . . . . . . . . . . . . . . . . . . . . . 20 86 5.2.8. SEI TOLV . . . . . . . . . . . . . . . . . . . . . . . 20 87 5.2.9. ECM TOLV . . . . . . . . . . . . . . . . . . . . . . . 21 88 5.2.10. EMM TOLV . . . . . . . . . . . . . . . . . . . . . . . 22 89 5.2.11. CAT TOLV . . . . . . . . . . . . . . . . . . . . . . . 22 90 5.2.12. PTS TOLV . . . . . . . . . . . . . . . . . . . . . . . 23 91 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 25 92 6.1. Media Type Registration . . . . . . . . . . . . . . . . . 25 93 6.1.1. Registration of audio/mpeg2-ts-preamble . . . . . . . 25 94 6.1.2. Registration of video/mpeg2-ts-preamble . . . . . . . 26 95 6.1.3. Registration of text/mpeg2-ts-preamble . . . . . . . . 26 96 6.1.4. Registration of application/mpeg2-ts-preamble . . . . 27 97 6.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 28 98 6.2.1. Offer-Answer Model and Declarative Considerations . . 29 99 7. Post-Processing of the MPEG2-TS Preamble . . . . . . . . . . . 30 100 8. Session Description Protocol (SDP) Signaling . . . . . . . . . 33 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 103 10.1. Payload Format . . . . . . . . . . . . . . . . . . . . . . 35 104 10.2. MPEG2-TS Preamble TOLV Space Registry . . . . . . . . . . 35 105 11. Open-Source Implementation . . . . . . . . . . . . . . . . . . 36 106 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 108 13.1. Normative References . . . . . . . . . . . . . . . . . . . 38 109 13.2. Informative References . . . . . . . . . . . . . . . . . . 38 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 112 1. Introduction 114 MPEG2 Transport Stream (MPEG2-TS) [MPEG2TS] is an encapsulation 115 method and transport that multiplexes digital video and audio 116 content, together with ancillary metadata, and produces a 117 synchronized multiplexed stream that is tailored for transport over 118 packet or cell-oriented networks. MPEG2-TS is ubiquitous in 119 broadcast applications over both terrestrial and satellite networks. 120 Both Advanced Television Systems Committee (ATSC) in North America 121 and Digital Video Broadcasting (DVB) in Europe use MPEG2-TS in their 122 standards. MPEG2-TS has been standardized by both ISO and ITU 123 [MPEG2TS]. While MPEG2-TS was originally limited to carry MPEG-2 124 encoded content, the specification was later extended to cover MPEG- 125 4/AVC audio/video encoding standards as well. 127 Due to the inherent design of MPEG2-TS, a receiver must first acquire 128 certain information before demultiplexing and decoding an incoming 129 MPEG2-TS. As will be explained in Section 4.1, this information 130 resides in the transport stream. However, it is often not contiguous 131 and is usually dispersed over a large period. Thus, a receiver 132 starting to receive an MPEG2-TS at a random location will have to 133 wait until the whole required information shows up in the received 134 data. In multicast applications, since the joining receivers do not 135 have any control over what point in the flow is currently being 136 transmitted, their waiting times will vary. This problem has been 137 identified and examined in detail in RAMS 138 [I-D.ietf-avt-rapid-acquisition-for-rtp], where the time lag before a 139 receiver can usefully consume the multicast data is referred to as 140 the Acquisition Delay. Section 4 provides an overview of the delay 141 components in video systems that contribute to the acquisition delay. 143 [I-D.ietf-avt-rapid-acquisition-for-rtp] refers to the information 144 that must first be acquired before starting to process any data sent 145 in the multicast session as the Reference Information. In this 146 document, we refer to the subset of the Reference Information that is 147 related to the MPEG2-TS as the MPEG2-TS Preamble. 149 For multicast applications running over RTP, 150 [I-D.ietf-avt-rapid-acquisition-for-rtp] proposes an approach where 151 an auxiliary unicast RTP session is established between a 152 retransmission server and the joining RTP receiver. Over this 153 unicast RTP session, the retransmission server provides the Reference 154 Information the RTP receiver needs to rapidly acquire the multicast 155 session. If the source stream in the RTP multicast session is 156 carrying an MPEG2-TS, the Reference Information will comprise the 157 MPEG2-TS Preamble as well. For its proper transmission from the 158 retransmission server to the joining RTP receiver, a new RTP payload 159 format has to be defined for the MPEG2-TS Preamble. This document 160 defines and registers this payload format. 162 Since the RTP packet(s) carrying the MPEG2-TS Preamble will not be 163 able to fed to the decoder in the form they are received, a post- 164 processing is required at the RTP receiver. This document also 165 explains this process in Section 7. 167 2. Requirements Notation 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Acronyms 175 This document uses the following acronyms frequently: 177 CAT: Conditional access table. 179 DTS: Decoding timestamp. 181 ECM: Entitlement control message. 183 EMM: Entitlement management message. 185 ES: Elementary stream. 187 GoP: Group of pictures. 189 IDR: Instantaneous decoding refresh. 191 MPEG2-TS: MPEG2 transport stream. 193 MPTS: Multi program transport stream. 195 PAT: Program association table. 197 PCR: Program clock reference. 199 PMT: Program map table. 201 PSI: Program specific information. 203 PTS: Presentation timestamp. 205 RAP: Random access point. 207 SPTS: Single program transport stream. 209 4. Elements of Delay in Video Systems 211 For typical multicast-based video delivery systems, the multicast 212 switching delay (time required to leave the previous multicast 213 session and join the new session) is not the primary contributor to 214 the overall acquisition delay. The multicast flows are typically 215 already present at the edge or deep in the network, the propagation 216 delays for join operations are modest, and the multicast routers can 217 typically process the Join and Leave messages quickly. Even if the 218 edge multicast router is not currently a member of the requested 219 multicast session, the multicast routing control messages propagate 220 through the network rapidly and trees are built without experiencing 221 large delays. Even in cases where a number of tree branches need to 222 be built to the edge multicast router, this cost is frequently 223 amortized over a large number of receivers such that only the first 224 receiver joining the group experiences the increased delay. Further, 225 this delay can be eliminated at the cost of extra bandwidth in the 226 network core by having the edge routers do static joins for the set 227 of sessions they expect receivers to be interested in. These 228 techniques usually provide a well-bounded multicast switching delay. 230 Once the join operation completes and a receiver starts receiving 231 media content for the first time in a multicast session, it often 232 experiences a considerable amount of Reference Information latency 233 and buffering delays. In the following subsections, we discuss the 234 details of these delay elements using MPEG2-TS as the motivating use 235 case. 237 4.1. Overview of MPEG-2 Transport Streams 239 MPEG2-TS is a container format that describes the schema of the audio 240 and video content and the in-band control information. Prior to 241 multiplexing, an audio and a video encoder output audio and video 242 Elementary Streams (ES), respectively. The ES streams are then 243 packetized to form the Packetized Elementary Streams (PES). The 244 resulting elements are called PES packets. A transport stream (TS) 245 encapsulates several PES streams and other data, and carries them in 246 TS packets. The RTP payload format for carrying TS packets in an RTP 247 stream is specified in [RFC2250]. In addition to the audio and video 248 ES streams, there are ES streams that carry control data. 250 Program Specific Information (PSI) consists of metadata carried in 251 the transport stream (See Table 2-28 in [MPEG2TS] for details). PSI 252 includes Program Association Table (PAT), Conditional Access Table 253 (CAT) and Program Map Table (PMT). A PAT has information about all 254 the programs carried in the transport stream. It lists the 13-bit 255 Program IDs (PID) for all the PMTs, associating them with the 256 individual programs. Each of the ES streams of a particular program 257 in the transport stream also has the same PID values. This way, a 258 decoder at the receiving side can extract the desired TS packets from 259 the transport stream by checking their PID values. If the transport 260 stream is not a Multi-Program Transport Stream (MPTS), but rather it 261 is a Single-Program Transport Stream (SPTS), all the ES streams in 262 the transport stream correspond to a single program. 264 CAT defines the type of the scrambling used (either at the PES or TS 265 level), and identifies all the PID values of the TS packets that 266 contain the Entitlement Management Messages (EMM). In addition to 267 containing the PID values of each ES stream associated with a 268 particular program, the PMT table also includes private data 269 associated with the program such as the PID value of the packet 270 containing the Entitlement Control Messages (ECM). The data 271 contained in the EMM and ECM messages are vital in descrambling 272 encrypted content. Note that PSI is carried in clear and is never 273 scrambled so that a receiver which just started receiving the 274 transport stream can process the PSI. The PAT, CAT and PMT tables 275 must be parsed by the decoder in order to find the ES streams, 276 private data as well as the encryption information for a given 277 program. 279 MPEG2-TS produces output that is synchronized to a common clock 280 across all the ESs in the multiplex. To assist the audio and video 281 decoders, programs periodically provide a Program Clock Reference 282 (PCR) value in the transport stream. PCR values are embedded in the 283 TS adaptation field headers and are inserted by the encoder at least 284 every 100 ms. A PCR timestamp represents the value of the encoder's 285 system clock when it was sampled. The system clock is driven by a 286 local 27 MHz oscillator. 288 PCR is extremely important in native MPEG-2 transport to keep the 289 decoders synchronized. For example, the periodically sent Decoding 290 Timestamps (DTS) and Presentation Timestamps (PTS) are specified 291 relative to the PCR value and the decoders use the PCR value as the 292 basis for a master clock during decoding and playout. 294 4.2. Reference Information Latency in Video Applications 296 We classify the Reference Information latency into two categories. 298 4.2.1. PSI (PAT/CAT/PMT) Acquisition Delay 300 As we discussed in Section 4.1, the video (and the audio as well) in 301 an MPEG2-TS is self describing, and the receiver must parse certain 302 control information in the PAT, CAT and PMT tables (i.e., PSI) 303 contained in the transport stream in order to know how to parse the 304 rest of the stream (i.e., to find the audio and video elementary 305 streams, private data and the encryption information for a given 306 program). 308 Many video services employ content encryption and the encryption keys 309 must be parsed as well for decrypting the content. In order to 310 enable various system elements to process video effectively, certain 311 portions of the stream are left unencrypted. The PAT/PMT tables are 312 always in the clear. The structure of the ECMs is also in the clear, 313 although the ECM content which contains keying material is encrypted. 314 The PSI information is repeated periodically in the transport stream, 315 thus, when a receiver joins the multicast session, it needs to wait 316 until the next time PSI is sent in the transport stream. 318 4.2.2. Random Access Point Acquisition Delay 320 Conventional MPEG2 video encoders encode the video content in Groups 321 of Pictures (GoP). Each GoP is encoded independently from other GoPs 322 and starts with an intra-coded frame (I-frame) that does not have any 323 reference to other frames in the same GoP, i.e., an I-frame contains 324 the representation of an entire picture and can be decoded 325 independently. Thus, the start of an I-frame is said to be a Random 326 Access Point (RAP). 328 On the other hand, due to the temporal compression, rest of the 329 frames in the same GoP may have references to the I-frame or to other 330 frames in the same GoP. Due to this interdependency among the 331 frames, one generally has to receive certain elements of the GoP 332 prior to decoding or rendering any part of the GoP. For example, the 333 decoder can decode a frame that is dependent on two other frames only 334 after these two frames are decoded. 336 Usually, GoP durations are between 500 ms and one second. However, 337 more advanced codecs may use longer GoPs to gain from the encoding 338 efficiency. When a receiver joins the multicast session, it needs to 339 wait until the next RAP shows up in the multicast stream before it 340 can start decoding. Since the frame that is currently being 341 multicast does not depend on the join time, the average time a 342 receiver waits for RAP, i.e., the average RAP acquisition delay, is 343 approximately equal to half of the GoP duration. Hence, for longer 344 GoPs, the RAP acquisition delay is proportionally longer. 346 Advanced Video Coding (AVC) (also called MPEG4 part 10) compression 347 is very similar to MPEG2 compression. It has a few more compression 348 tools available, including Hierarchical GoPs. In a hierarchical GoP, 349 the dependent frames of a GoP may reference the I-frame at the start 350 of this GoP and the I-frame at the start of the next GoP. This 351 additional dependency causes a longer RAP acquisition delay, as the 352 decoder must receive two I-frames (spread between two logical GoPs) 353 before decoding can commence. In an Open GoP, a frame in one GoP may 354 refer to a frame in a previous GoP. AVC also has the ability to 355 insert Instantaneous Decoding Refresh (IDR) frames. Frames that 356 follow an IDR frame cannot reference frames that precede an IDR 357 frame. IDR frames are useful for editing AVC streams, but are 358 typically do not appear often enough in streaming video to be useful 359 in a stream acquisition context. 361 Note that in order for an intermediary network element such as a 362 retransmission server to find the random access points in the video 363 stream (e.g., I-frames), the necessary structural information must be 364 in the clear if the intermediary is not in possession of the 365 necessary keys. 367 4.3. Buffering Delays in Video Applications 369 We classify the buffering delays into two categories. 371 4.3.1. Network-Related Buffering Delays 373 In general, multicast-based video applications use an unreliable 374 underlying transport protocol such as UDP [RFC0768] to distribute the 375 content to a large number of receivers. This is largely due to the 376 fact that these applications are one way in nature and providing 377 closed-loop reliability does not scale well when the number of 378 receivers is large or the acceptable playout delay is small, or both. 379 Rather, if there is a need for reliability, the applications may 380 employ one or more loss-repair methods to recover the packets missing 381 at each receiver (The Reliable Multicast Transport Working Group has 382 several standardized solutions for this problem. Refer to [RFC5740] 383 for details). For example, Forward Error Correction (FEC) may be 384 used proactively and/or on-demand to provide reliable transmission to 385 a potentially very large multicast group in a scalable manner 386 [I-D.ietf-fecframe-framework]. Similarly, retransmissions may be 387 used in RTP-based multicast sessions where the retransmissions can be 388 handled by local repair servers rather than the source itself 389 [RFC5760]. However, regardless of the type of the loss-repair 390 method(s) adopted by an application, loss-recovery operations always 391 require additional buffering at the receiver side. The amount of 392 buffering increases with the FEC block size when FEC is used, and 393 with the round-trip time between the receiver and the local repair 394 server when retransmission is used. 396 Audio and video decoders demand almost jitter-free content. If any 397 jitter is introduced during the transmission in the network or due to 398 the loss-repair methods, the jitter has to be smoothed out before the 399 content is fed to the decoder. This is called de-jittering and it 400 usually adds up to the buffering delay. 402 4.3.2. Application-Related Buffering Delays 404 The application buffering requirements for MPEG-encoded content are 405 quite rigorous, particularly for the MPEG-based video applications. 406 Video compression devices apply more bits to represent certain scenes 407 than they do for other scenes. A very complex scene (individual 408 picture) requires considerably more information than a simple scene. 409 Furthermore, pictures that are entirely intra-coded, e.g., I-frames, 410 consume more bits compared to pictures that make use of predictive 411 coding. Each scene is shown by the decoder at a certain fixed frame 412 rate (e.g., 24 fps or 30 fps). Since some scenes are comprised more 413 bits than other scenes, the output rate of the decoder buffer is 414 usually variable. However, the network flow is typically Constant 415 Bit Rate (CBR) or Capped Variable Bit Rate (Capped VBR). The net 416 effect is that the input rate to the decoder buffer is close to 417 constant, but the output rate is highly variable. 419 The video encoders keep track of the decoder buffer size, and use 420 this information to regulate the temporal compression. This forces 421 the decoder buffer to "breathe." In order to avoid underflow, the 422 decoder buffer must fill up to a certain level prior to starting to 423 decode and play the content. The decoder buffer size required to 424 avoid underflow is dependent on the encoder, and the encoder signals 425 the decoder buffering requirements in-band. Typical decoder buffer 426 requirements for MPEG2 content range from a few hundreds of 427 milliseconds to a few seconds. However, AVC/MPEG4 part 10 encoders 428 usually tend to use more temporal compression, and thus require a 429 larger buffer at the decoder side. This consequently increases the 430 buffering delays. 432 5. Packet Format 434 This section defines the MPEG2-TS Preamble packet format. 436 The RTP header is formatted according to [RFC3550] with some further 437 clarifications listed below: 439 o Marker (M) Bit: This bit SHALL be used to indicate the last 440 packet carrying the MPEG2-TS Preamble information. It SHALL be 441 set to zero in all RTP packets other than the last packet, where 442 it SHALL be set to one. 444 o Payload Type: The (dynamic) payload type for the MPEG2-TS 445 Preamble packets is determined through out-of-band means. Note 446 that this document registers a new payload format for the MPEG2-TS 447 Preamble packets (Refer to Section 6 for details). According to 448 [RFC3550], an RTP receiver that cannot recognize a payload type 449 must discard it. This provides backward compatibility. 451 o Sequence Number (SN): The sequence number has the standard 452 definition. It MUST be one higher than the sequence number in the 453 previously transmitted RTP packet. If this RTP packet is the 454 first packet in the session, its sequence number SHOULD be random 455 (unpredictable) [RFC3550]. 457 o Timestamp (TS): The timestamp SHALL be set to a time 458 corresponding to the packet's transmission time. 460 o Synchronization Source (SSRC): Per [RFC3550], the SSRC value 461 SHOULD be chosen randomly with collision detection. 463 However, in RAMS applications 464 [I-D.ietf-avt-rapid-acquisition-for-rtp] where the MPEG2-TS Preamble 465 packets are payload-type multiplexed with the burst packets in the 466 same RTP session, the following rules apply: 468 o The SSRC of the Preamble packets MUST be set to the SSRC of the 469 retransmission packets. 471 o The Preamble and retransmission packets share the same sequence 472 number and timestamp space. Thus, the sequence numbers and 473 timestamps MUST be set consistently. 475 The payload consists of TOLV elements that are defined in 476 Section 5.2. Before defining them, we first introduce the TOLV 477 structure. 479 5.1. Extensions 481 The MPEG2-TS Preamble MUST be encoded as TOLV elements as described 482 below and sketched in Figure 1: 484 o Type: A single-octet identifier that defines the type of the 485 parameter represented in this TOLV element. 487 o Order: A single-octet identifier that specifies the order in 488 which this TOLV element MUST be processed by the receiver when 489 forming a demux/decoder-friendly stream. As explained in 490 Section 7, the order information is crucial for majority of the 491 TOLV elements defined in this document. Yet, for some other TOLV 492 elements, the order may not matter. In that case, the Order value 493 MAY be set to 0. 495 Starting from 1, a lower Order value indicates an earlier order in 496 post-processing and the Order values MUST be consecutive. Note 497 that none of the TOLV elements that belong to the same Preamble 498 data MUST have the same Order value except 0. 500 o Length: A two-octet field that indicates the length of the TOLV 501 element excluding the Type, Order and Length fields in octets. 502 Note that this length does not include any padding that is 503 required for alignment. 505 o Value: Variable-size set of octets that contains the specific 506 value for the parameter. Note that the value field of an TOLV 507 element may contain other TOLVs. 509 If a TOLV element does not fall on a 32-bit boundary, the last word 510 must be padded to the boundary using further bits set to 0. The 511 support for extensions is OPTIONAL. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type | Order | Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Value / 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 1: Structure of a TOLV element 523 The TOLV encoding/decoding is similar to the TLV encoding/decoding 524 used by the RAMS applications 525 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 527 5.1.1. Vendor-Neutral Extensions 529 If the goal in defining new TOLV elements is to extend the 530 functionality in a vendor-neutral manner, they MUST be registered 531 with IANA through the guidelines provided in Section 10.2. 533 The current document defines several vendor-neutral extensions in 534 Section 5.2. 536 5.1.2. Private Extensions 538 It is desirable to allow vendors to use private extensions in TOLV 539 format. For interoperability, such extensions MUST NOT collide with 540 each other. 542 A certain range of TOLV Types is reserved for private extensions 543 (Refer to Section 10.2). IANA management for these extensions is 544 unnecessary and they are the responsibility of individual vendors. 546 The structure that MUST be used for the private extensions is 547 depicted in Figure 2. Here, the enterprise numbers are used from 548 http://www.iana.org/assignments/enterprise-numbers. This will ensure 549 the uniqueness of the private extensions and avoid any collision. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Order | Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Ent. Number | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Value / 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 2: Structure of a private extension 563 5.2. Vendor-Neutral Extensions 565 The current document defines several vendor-neutral extensions. In 566 the following extensions, we use 'r' to indicate a reserved bit, 567 which SHALL be set to zero. The fields denoted by 'Reserved' SHALL 568 also be set to zero. 570 5.2.1. PAT TOLV 572 Optional TOLV element that is used to encode information associated 573 with a Program Association (PA) section as defined in Section 2.4.4.3 574 of [MPEG2TS]. It has the following structure: 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | PAT_TOLV_Type | Order | Length | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | PID |r r r| Section Length | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Section Data / 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 3: Structure of PAT TOLV 588 The PID is a 13-bit field used to identify the ES in an MPTS or SPTS. 589 This is the PID used in the associated TS to carry the PA Section 590 Data. Its value MUST be 0. The Section Length field is a 16-bit 591 field that specifies the length of the Section Data in octets. The 592 Section Data is a PA section as defined in Section 2.4.4.3 of 593 [MPEG2TS]. Note that the length of the PAT TOLV is variable. 595 Type: 1 597 Length: Variable 599 5.2.2. PMT TOLV 601 Optional TOLV element that is used to encode information associated 602 with a Program Map (PM) section. It has the following structure: 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | PMT_TOLV_Type | Order | Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | PID |r r r| Section Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Section Data / 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 4: Structure of PMT TOLV 616 The PID is used in the associated TS to carry the PM Section Data. 617 The Section Length field is a 16-bit field that specifies the length 618 of the Section Data in octets. The Section Data is a PM section. 619 Note that the length of the PMT TOLV is variable. 621 Type: 2 623 Length: Variable 625 5.2.3. PCR TOLV 627 Optional TOLV element that contains a PCR value used to initialize 628 the decoder and system clocks. The PCR value corresponds to the 629 first byte of the first TS packet that will be transmitted as part of 630 the unicast burst. It has the following structure: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | PCR_TOLV_Type | Order | Length | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | PID |r r r| Reserved | PCR_EXT | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | PCR_BASE | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |b| Reserved | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 5: Structure of PCR TOLV 646 The PID is used in the associated TS to carry the PCR data. PCR_BASE 647 is a 33-bit field that is part of the PCR timestamp. PCR_BASE 648 occupies the entire third 32-bit word along with the first bit of the 649 fourth word. The remainder of the fourth word (31 bits) is reserved. 650 PCR_EXT is a 9-bit field that is part of the PCR timestamp. 652 Type: 3 654 Length: 13 656 5.2.4. PID_LIST TOLV 658 A PID is a packet identifier that is used to identify ESs of a 659 program in an SPTS or MPTS. The PID_LIST contains a PID Element for 660 each PID referenced in the MPEG2-TS Preamble. Each PID Element 661 contains the PID and associated continuity counter that corresponds 662 to the first packet that will be sent. 664 PID_LIST TOLV It has the following structure: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |PID_L_TOLV_Type| Order | Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | PID Element 1 | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 : : 674 : : 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | PID Element n | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 6: Structure of PID_LIST TOLV 681 And the PID Element has the following structure: 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | PID |r r r|r r r r| CC | Reserved | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 Figure 7: Structure of PID Element 691 Here, CC is a 4-bit field that carries the Continuity Counter. 693 Type: 4 695 Length: Variable 697 5.2.5. SEQ TOLV 699 Optional TOLV element that is used to encode information from the 700 Video Sequence Header of an MPEG2 Video ES. The Video Sequence 701 Header contains information such as frame rate, aspect ratio and 702 picture size. It has the following structure: 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | SEQ_TOLV_Type | Order | Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | PID |r r r| Section Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Section Data / 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 8: Structure of SEQ TOLV 716 The PID is used in the associated TS to carry the SEQ Section Data. 717 The Section Length field is a 16-bit field that specifies the length 718 of the Section Data in octets. The Section Data is a SEQ section. 719 See Section 6.2.2 of [ISO13818-2] for a discussion of Video Sequence 720 Header and Sequence Extension. 722 Note that SEQ TOLV is only applicable to transport streams that carry 723 MPEG2 video. 725 Type: 5 727 Length: Variable 729 5.2.6. SPS TOLV 731 Optional TOLV element that is used to encode information from the 732 Sequence Parameter Set Network Abstraction Layer (NAL) unit. It has 733 the following structure: 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | SPS_TOLV_Type | Order | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | PID |r r r| Section Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Section Data / 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Figure 9: Structure of SPS TOLV 747 The PID is used in the associated TS to carry the SPS Section Data. 748 The Section Length field is a 16-bit field that specifies the length 749 of the Section Data in octets. The Section Data is a SPS section. 750 See Section 7.4.2.1 of [ISO13818-10] for a discussion of semantics of 751 the Sequence Parameter Set NAL. 753 Note that SPS TOLV is only applicable to transport streams that carry 754 AVC (H.264) video. 756 Type: 6 758 Length: Variable 760 5.2.7. PPS TOLV 762 Optional TOLV element that is used to encode information from the 763 Picture Parameter Set NAL unit. It has the following structure: 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | PPS_TOLV_Type | Order | Length | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | PID |r r r| Section Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Section Data / 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Figure 10: Structure of PPS TOLV 777 The PID is used in the associated TS to carry the PPS Section Data. 778 The Section Length field is a 16-bit field that specifies the length 779 of the Section Data in octets. The Section Data is a PPS section. 780 See Section 7.4.2.2 of [ISO13818-10] for a discussion of semantics of 781 the Picture Parameter Set NAL. 783 Note that PPS TOLV is only applicable to transport streams that carry 784 AVC (H.264) video. 786 Type: 7 788 Length: Variable 790 5.2.8. SEI TOLV 792 Optional TOLV element that is used to encode information from the 793 Supplemental Enhanced Information NAL unit. It has the following 794 structure: 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | SEI_TOLV_Type | Order | Length | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | PID |r r r| Section Length | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Section Data / 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Figure 11: Structure of SEI TOLV 808 The PID is used in the associated TS to carry the SEI Section Data. 809 The Section Length field is a 16-bit field that specifies the length 810 of the Section Data in octets. The Section Data is a SEI section. 811 See Annex D of [ISO13818-10] for details. 813 Note that SEI TOLV is only applicable to transport streams that carry 814 AVC (H.264) video. 816 Type: 8 818 Length: Variable 820 5.2.9. ECM TOLV 822 Optional TOLV element that contains the ECM from the MPEG2-TS. This 823 applies only to transport streams that are encrypted. It has the 824 following structure: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | ECM_TOLV_Type | Order | Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | PID |r r r| Section Length | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Section Data / 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 12: Structure of ECM TOLV 838 Section Data depends on type of encryption used. It contains a 839 Private Section as defined in Section 2.4.4.10 of [MPEG2TS]. The 840 MPEG2-TS PMT provides a list of PIDs in conditional access 841 descriptors. Private Sections from these PIDs are placed into ECM 842 TOLVs. There may be multiple ECM TOLV elements corresponding to 843 different PID or table_id values. The contents and use of such a 844 Private Section are vendor specific. It is treated here as opaque 845 data. Conditional access vendors will often use table_id = 0x80 and 846 table_id = 0x81 in accordance with [DVB-ETR-289]. 848 Type: 9 850 Length: Variable 852 5.2.10. EMM TOLV 854 Optional TOLV element that contains the EMM from the MPEG2-TS. This 855 applies only to transport streams that are encrypted. It has the 856 following structure: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | EMM_TOLV_Type | Order | Length | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | PID |r r r| Section Length | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Section Data / 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 Figure 13: Structure of EMM TOLV 870 Section Data depends on type of encryption used. It contains a 871 Private Section as defined in Section 2.4.4.10 of [MPEG2TS]. The 872 MPEG2-TS CAT provides a list of PIDs in conditional access 873 descriptors. Private Sections from these PIDs are placed into EMM 874 TOLVs. There may be multiple EMM TOLV elements corresponding to 875 different PID or table_id values. The contents and use of such a 876 Private Section are vendor specific. It is treated here as opaque 877 data. 879 Type: 10 881 Length: Variable 883 5.2.11. CAT TOLV 885 Optional TOLV element that is used to encode information associated 886 with a Conditional Access (CA) section as defined in Section 2.4.4.6 887 of [MPEG2TS]. It has the following structure: 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | CAT_TOLV_Type | Order | Length | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | PID |r r r| Section Length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Section Data / 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Figure 14: Structure of CAT TOLV 901 The PID is a 13-bit field used to identify the ES in an MPTS or SPTS. 902 This is the PID used in the associated TS to carry the CA Section 903 Data. The Section Length field is a 16-bit field that specifies the 904 length of the Section Data in octets. The Section Data is a CA 905 section as defined in Section 2.4.4.6 of [MPEG2TS]. 907 Type: 11 909 Length: Variable 911 5.2.12. PTS TOLV 913 Optional TOLV element that is used to encode the PTS timestamp 914 corresponding to the first picture in the unicast burst. It has the 915 following structure: 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | PTS_TOLV_Type | Order | Length | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | PID |r r r| Reserved | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | PTS_BASE | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 |b| Reserved | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Figure 15: Structure of PTS TOLV 931 The PID is used to identify the associated TS to carry the PTS data. 932 PTS_BASE is a 33-bit field that is taken from the PES header of the 933 MPEG2-TS that will be sent. Note that this TOLV is purely 934 informational. 936 Type: 12 938 Length: 13 940 6. Payload Format Parameters 942 This section provides the media subtype registration for the MPEG2-TS 943 Preamble. 945 6.1. Media Type Registration 947 This registration is done using the template defined in [RFC4288] and 948 following the guidance provided in [RFC4855]. 950 6.1.1. Registration of audio/mpeg2-ts-preamble 952 Type name: audio 954 Subtype name: mpeg2-ts-preamble 956 Required parameters: 958 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 959 than 1000 Hz to provide sufficient resolution to RTCP operations. 961 Optional parameters: None. 963 Encoding considerations: This media type is framed (See Section 4.8 964 in the template document [RFC4288]) and contains binary data. 966 Security considerations: See Section 9 of this document. 968 Interoperability considerations: None. 970 Published specification: This document. 972 Applications that use this media type: Applications that transmit 973 MPEG2-TS content and want to provide the Preamble information for the 974 transport stream they are transmitting to the receiver(s). 976 Additional information: None. 978 Person & email address to contact for further information: Ali Begen 979 and IETF Audio/Video Transport Working Group. 981 Intended usage: COMMON. 983 Restriction on usage: This media type depends on RTP framing, and 984 hence, is only defined for transport via RTP [RFC3550]. 986 Author: Ali Begen . 988 Change controller: IETF Audio/Video Transport Working Group 989 delegated from the IESG. 991 6.1.2. Registration of video/mpeg2-ts-preamble 993 Type name: video 995 Subtype name: mpeg2-ts-preamble 997 Required parameters: 999 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 1000 than 1000 Hz to provide sufficient resolution to RTCP operations. 1002 Optional parameters: None. 1004 Encoding considerations: This media type is framed (See Section 4.8 1005 in the template document [RFC4288]) and contains binary data. 1007 Security considerations: See Section 9 of this document. 1009 Interoperability considerations: None. 1011 Published specification: This document. 1013 Applications that use this media type: Applications that transmit 1014 MPEG2-TS content and want to provide the Preamble information for the 1015 transport stream they are transmitting to the receiver(s). 1017 Additional information: None. 1019 Person & email address to contact for further information: Ali Begen 1020 and IETF Audio/Video Transport Working Group. 1022 Intended usage: COMMON. 1024 Restriction on usage: This media type depends on RTP framing, and 1025 hence, is only defined for transport via RTP [RFC3550]. 1027 Author: Ali Begen . 1029 Change controller: IETF Audio/Video Transport Working Group 1030 delegated from the IESG. 1032 6.1.3. Registration of text/mpeg2-ts-preamble 1034 Type name: text 1035 Subtype name: mpeg2-ts-preamble 1037 Required parameters: 1039 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 1040 than 1000 Hz to provide sufficient resolution to RTCP operations. 1042 Optional parameters: None. 1044 Encoding considerations: This media type is framed (See Section 4.8 1045 in the template document [RFC4288]) and contains binary data. 1047 Security considerations: See Section 9 of this document. 1049 Interoperability considerations: None. 1051 Published specification: This document. 1053 Applications that use this media type: Applications that transmit 1054 MPEG2-TS content and want to provide the Preamble information for the 1055 transport stream they are transmitting to the receiver(s). 1057 Additional information: None. 1059 Person & email address to contact for further information: Ali Begen 1060 and IETF Audio/Video Transport Working Group. 1062 Intended usage: COMMON. 1064 Restriction on usage: This media type depends on RTP framing, and 1065 hence, is only defined for transport via RTP [RFC3550]. 1067 Author: Ali Begen . 1069 Change controller: IETF Audio/Video Transport Working Group 1070 delegated from the IESG. 1072 6.1.4. Registration of application/mpeg2-ts-preamble 1074 Type name: application 1076 Subtype name: mpeg2-ts-preamble 1078 Required parameters: 1080 o rate: The RTP timestamp (clock) rate. The rate SHALL be larger 1081 than 1000 Hz to provide sufficient resolution to RTCP operations. 1083 Optional parameters: None. 1085 Encoding considerations: This media type is framed (See Section 4.8 1086 in the template document [RFC4288]) and contains binary data. 1088 Security considerations: See Section 9 of this document. 1090 Interoperability considerations: None. 1092 Published specification: This document. 1094 Applications that use this media type: Applications that transmit 1095 MPEG2-TS content and want to provide the Preamble information for the 1096 transport stream they are transmitting to the receiver(s). 1098 Additional information: None. 1100 Person & email address to contact for further information: Ali Begen 1101 and IETF Audio/Video Transport Working Group. 1103 Intended usage: COMMON. 1105 Restriction on usage: This media type depends on RTP framing, and 1106 hence, is only defined for transport via RTP [RFC3550]. 1108 Author: Ali Begen . 1110 Change controller: IETF Audio/Video Transport Working Group 1111 delegated from the IESG. 1113 6.2. Mapping to SDP Parameters 1115 Applications that are using RTP transport commonly use Session 1116 Description Protocol (SDP) [RFC4566] to describe their RTP sessions. 1117 The information that is used to specify the media types in an RTP 1118 session has specific mappings to the fields in an SDP description. 1119 In this section, we provide these mappings for the media subtype 1120 registered by this document ("mpeg2-ts-preamble"). Note that if an 1121 application does not use SDP to describe the RTP sessions, an 1122 appropriate mapping must be defined and used to specify the media 1123 types and their parameters for the control/description protocol 1124 employed by the application. 1126 The mapping of the media type specification for "mpeg2-ts-preamble" 1127 and its parameters in SDP is as follows: 1129 o The media type (e.g., "application") goes into the "m=" line as 1130 the media name. 1132 o The media subtype ("mpeg2-ts-preamble") goes into the "a=rtpmap" 1133 line as the encoding name. The RTP clock rate parameter ("rate") 1134 also goes into the "a=rtpmap" line as the clock rate. 1136 An SDP example is provided in Section 8. 1138 6.2.1. Offer-Answer Model and Declarative Considerations 1140 There no configuration parameters or optional format parameters for 1141 the MPEG2-TS Preamble payload format. Thus, when offering MPEG2-TS 1142 Preamble over RTP using SDP in an Offer/Answer model [RFC3264] or in 1143 a declarative manner (e.g., SDP in the Real-time Streaming Protocol 1144 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 1145 [RFC2974]), there are no specific considerations. 1147 7. Post-Processing of the MPEG2-TS Preamble 1149 Once received, the RTP packet(s) carrying the MPEG2-TS Preamble 1150 cannot be fed directly to the MPEG transport demux/decoder since the 1151 demux/decoder would not be able to recognize the TOLV elements within 1152 the Preamble packets. Thus, the Preamble information MUST be first 1153 processed, and a demux/decoder-friendly stream MUST be formed. The 1154 demux/decoder-friendly stream MUST conform to [MPEG2TS]. In this 1155 section, we briefly explain this process. 1157 The Preamble TOLV elements contain several different types of 1158 Transport Stream data. The first type is Program Specific 1159 Information (PSI) Section Data. The second type is PCR Data, and the 1160 third is Elementary Stream Data. 1162 1. Section Data 1164 This includes the PAT TOLV, PMT TOLV and CAT TOLV. Section Data 1165 also include ECMs or EMMs encapsulated in private sections as per 1166 [DVB-ETR-289]. These packets are all processed similarly. 1168 Each TS packet begins with a 4-byte TS header containing the PID 1169 value given in the Preamble TOLV element. There is no adaptation 1170 field present. The continuity counter value can be retrieved 1171 from the PIDLIST TOLV element for the current PID. If the TS 1172 packet contains the beginning of the Section, the Payload Unit 1173 Start Indicator (PUSI) bit should be set in the TS header. Also, 1174 a 1-byte pointer field follows the TS header, which should be set 1175 to 0. The Section Data immediately follow the pointer field. If 1176 the Section Data span multiple TS packets, they are recreated in 1177 a similar manner, except without the PUSI bit set and the pointer 1178 field. 1180 The continuity counter value of a packet must be one greater than 1181 the previous packet on that PID. This applies to packets 1182 reconstructed from the Preamble TOLV elements and packets from 1183 the MPEG2-TS stream. The continuity counter value of the final 1184 packet of Preamble data should be one less than the first packet 1185 on the MPEG2-TS stream with that same PID. 1187 The final TS packet may contain stuffing bytes of 0xFF as 1188 necessary to pad the packet to 188 bytes. 1190 The Section Data may optionally be programmed automatically into 1191 decoder hardware registers. This allows the decoder to rapidly 1192 learn the PSI data without having to parse the MPEG2-TS preamble 1193 output. This technique decreases presentation times by 1194 decreasing the amount of time needed to acquire the relevant PSI 1195 data in the decoder. It also provides an opportunity to learn 1196 when the demux/decoder is ready to accept the unicast (RAMS) 1197 burst [I-D.ietf-avt-rapid-acquisition-for-rtp]. If the unicast 1198 burst is given to the decoder before it is fully programmed with 1199 the PSI data, the decoder may discard part of the unicast burst, 1200 which delays the presentation time significantly. 1202 2. PCR Data 1204 A single TS packet is constructed from the PCR TOLV. This 1205 contains a 4-byte TS header with correct PID and continuity 1206 counter as retrieved from the PIDLIST. The Adaptation Field 1207 control bits should indicate that only an adaptation_field and no 1208 payload is present. The adaptation field should contain the PCR 1209 value from the PCR TOLV followed by padding to fill the TS 1210 packet. The discontinuity_indicator in the Adaptation Field 1211 should be set to one. 1213 The PCR value MUST be constructed to be continuous with the 1214 MPEG2-TS timebase. The PCR TOLV packet contains the PCR value of 1215 the first packet in the unicast burst and this value MUST be 1216 adjusted by an amount equal to the time needed to the write the 1217 preamble into the decoder. 1219 3. Elementary Stream Data 1221 The final type of Preamble data is that contained in an 1222 elementary stream. This includes data from the SEQ, SPS, PPS and 1223 SEI TOLVs. Each TS packet begins with a 4-byte TS header 1224 containing the PID value given in the Preamble TOLV element. The 1225 adaptation field padding can be used to pad the last TS packet to 1226 188 bytes. The continuity counter value can be retrieved from 1227 the PIDLIST TOLV element for the current PID. If the TS packet 1228 contains the beginning of the TOLV element, the Payload Unit 1229 Start Indicator (PUSI) bit should be set in the TS header. A PES 1230 header must immediately follow the start of the first TS packet. 1231 The stream_type of the PES packet should match the contents of 1232 elementary stream data. 1234 The TS packets constructed as above should be passed to the demux/ 1235 decoder in the following order: PAT, PMT, PCR, EMM, ECM, {Elementary 1236 Stream Data}. The PAT and PMT MUST be the first two packets because 1237 they contain required information to program the demux. The EMM and 1238 ECM MUST occur before Elementary stream data because they contain 1239 conditional access data that will be needed to descramble and decode 1240 the elementary stream. 1242 For all PIDs, the continuity counter values MUST be reconstructed to 1243 the continuous with the RAMS session continuity counter values. The 1244 PIDLIST TOLV contains the continuity counter value of the first TS 1245 packet for each PID present in the preamble. For every TS packet 1246 generated in the preamble output, the continuity counter value SHOULD 1247 be decremented by 1. For example, the PIDLIST TOLV indicates the 1248 continuity counter of the first burst packet on PID 0x0024 is 0xe and 1249 the preamble contains two packets on PID 0x0024. The first packet on 1250 PID 0x0024 from the preamble sent into the decoder should have 1251 continuity counter 0xc and the second preamble packet should have 1252 continuity counter 0xd. 1254 8. Session Description Protocol (SDP) Signaling 1256 This section shows how the MPEG2-TS Preamble packets can be used in a 1257 RAMS session [I-D.ietf-avt-rapid-acquisition-for-rtp]. The example 1258 SDP [RFC4566] description is taken from 1259 [I-D.ietf-avt-rapid-acquisition-for-rtp], where additional 1260 information about this description is available. 1262 v=0 1263 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1264 s=Rapid Acquisition Example with MPEG2-TS Preamble Data 1265 t=0 0 1266 a=group:FID 1 2 1267 a=rtcp-unicast:rsi 1268 m=video 41000 RTP/AVPF 98 1269 i=Primary Multicast Stream 1270 c=IN IP4 233.252.0.2/255 1271 a=source-filter:incl IN IP4 233.252.0.2 192.0.2.2 1272 a=rtpmap:98 MP2T/90000 1273 a=rtcp:42000 IN IP4 192.0.2.1 1274 a=rtcp-fb:98 nack 1275 a=rtcp-fb:98 nack rai 1276 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1277 a=mid:1 1278 m=video 51000 RTP/AVPF 99 100 1279 i=Unicast Retransmission Stream + Preamble Data 1280 c=IN IP4 192.0.2.1 1281 a=sendonly 1282 a=rtpmap:99 rtx/90000 1283 a=rtcp-mux 1284 a=fmtp:99 apt=98;rtx-time=5000 1285 a=rtpmap:100 mpeg2-ts-preamble/90000 1286 a=mid:2 1288 Figure 16: SDP description showing the payload-type multiplexed 1289 Preamble and retransmission packets in a RAMS session 1291 9. Security Considerations 1293 RTP packets using the payload format defined in this specification 1294 are subject to the security considerations discussed in the RTP 1295 specification [RFC3550] and in any applicable RTP profile. The main 1296 security considerations for the RTP packet carrying the RTP payload 1297 format defined within this memo are confidentiality, integrity and 1298 source authenticity. Confidentiality is achieved by encrypting the 1299 RTP payload. Integrity of the RTP packets is achieved through a 1300 suitable cryptographic integrity protection mechanism. Such a 1301 cryptographic system may also allow the authentication of the source 1302 of the payload. A suitable security mechanism for this RTP payload 1303 format should provide confidentiality, integrity protection, and at 1304 least source authentication capable of determining if an RTP packet 1305 is from a member of the RTP session. 1307 Note that the appropriate mechanism to provide security to RTP and 1308 payloads following this memo may vary. It is dependent on the 1309 application, transport and signaling protocol employed. Therefore, a 1310 single mechanism is not sufficient, although if suitable, using the 1311 Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. 1312 Other mechanisms that may be used are IPsec [RFC4301] and Transport 1313 Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may 1314 exist. 1316 The primary application area for the Preamble packets is to provide 1317 accelerated acquisition and presentation of multicast sessions 1318 carrying MPEG2-TS content [I-D.ietf-avt-rapid-acquisition-for-rtp]. 1319 During the creation of the Preamble packets, no new stream data are 1320 created. That is, the only data present in the Preamble are gathered 1321 from the recent packets sent in the corresponding primary multicast 1322 stream. Thus, there are no additional security risks for an attacker 1323 which may capture both the Preamble packets and the primary multicast 1324 stream. The Preamble data can contain EMM or ECM packets, but they 1325 are also drawn from the multicast stream. No personalized data is 1326 included in the Preamble packets, so the Preamble data may not be 1327 used to decrypt the stream data. Modifying the Preamble data or 1328 preventing the Preamble data from reaching the RTP receiver could 1329 lead to increased acquisition delays or presentation artifacts. 1331 10. IANA Considerations 1333 10.1. Payload Format 1335 New media subtypes are subject to IANA registration. For the 1336 registration of the payload format and its parameters introduced in 1337 this document, refer to Section 6. 1339 10.2. MPEG2-TS Preamble TOLV Space Registry 1341 This document creates a new IANA TOLV space registry for the 1342 extensions. The registry is called the MPEG2-TS Preamble TOLV Space 1343 Registry. This registry is to be managed by the IANA according to 1344 the Specification Required policy of [RFC5226]. 1346 The length of the Type field in the TOLV elements is a single octet, 1347 allowing 256 values. The registry is initialized with the following 1348 entries: 1350 Type Description Reference 1351 ---- -------------------------------------------------- ------------- 1352 1 PAT (Program Association Table) Data This document 1353 2 PMT (Program Map Table) Data This document 1354 3 PCR (Program Clock Reference) Data This document 1355 4 PID List This document 1356 5 SEQ (Video Sequence Header) Data This document 1357 6 SPS (Sequence Parameter Set) Data This document 1358 7 PPS (Picture Parameter Set) Data This document 1359 8 SEI (Supplemental Enhanced Information) Data This document 1360 9 ECM (Entitlement Control Message) Data This document 1361 10 EMM (Entitlement Management Message) Data This document 1362 11 CAT (Conditional Access Table) Data This document 1363 12 PTS (Presentation Timestamp) This document 1365 The Type values 0 and 255 are reserved for future use. The Type 1366 values between (and including) 128 and 254 are reserved for private 1367 extensions. 1369 Any registration for an unassigned Type value needs to contain the 1370 following information: 1372 o Contact information of the one doing the registration, including 1373 at least name, address, and email. 1375 o A detailed description of what the new TOLV element represents and 1376 how it shall be interpreted. 1378 11. Open-Source Implementation 1380 An open-source RTP receiver code that implements the functionalities 1381 introduced in [I-D.ietf-avt-rapid-acquisition-for-rtp] and this 1382 document is available. For documentation, visit the following URL: 1384 http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_5/user/guide/ 1385 vqe_guide3_5.html 1387 The code is available at: 1389 ftp://ftpeng.cisco.com/ftp/vqec/ 1391 Note that this code is under development and may be based on an 1392 earlier versions of [I-D.ietf-avt-rapid-acquisition-for-rtp] and this 1393 document. As progress is made in the specifications, the source code 1394 will be updated to reflect the changes. Also note that the current 1395 version of the source code packages the Preamble information in RTCP 1396 APP packet(s) rather than RTP packet(s). 1398 12. Acknowledgments 1400 The authors would like to thank Dave Oran, Bill Ver Steeg, Art 1401 Allison, Sandy MacInnis, Roni Even and Ross Finlayson for their 1402 reviews and feedback. 1404 13. References 1406 13.1. Normative References 1408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1409 Requirement Levels", BCP 14, RFC 2119, March 1997. 1411 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1412 Jacobson, "RTP: A Transport Protocol for Real-Time 1413 Applications", STD 64, RFC 3550, July 2003. 1415 [MPEG2TS] ITU-T H.222.0, "Generic Coding of Moving Pictures and 1416 Associated Audio Information: Systems", May 2006. 1418 [ISO13818-2] 1419 ITU-T H.262, "Generic Coding of Moving Pictures and 1420 Associated Audio Information: Video", February 2000. 1422 [ISO13818-10] 1423 ITU-T H.264, "Advanced Video Coding for Generic 1424 Audiovisual Services", March 2005. 1426 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1427 Description Protocol", RFC 4566, July 2006. 1429 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1430 Registration Procedures", BCP 13, RFC 4288, December 2005. 1432 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1433 Formats", RFC 4855, February 2007. 1435 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1436 with Session Description Protocol (SDP)", RFC 3264, 1437 June 2002. 1439 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1440 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1441 May 2008. 1443 13.2. Informative References 1445 [I-D.ietf-avt-rapid-acquisition-for-rtp] 1446 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 1447 Based Rapid Acquisition of Multicast RTP Sessions", 1448 draft-ietf-avt-rapid-acquisition-for-rtp-15 (work in 1449 progress), September 2010. 1451 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 1452 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 1453 January 1998. 1455 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1456 Protocol (RTCP) Extensions for Single-Source Multicast 1457 Sessions with Unicast Feedback", RFC 5760, February 2010. 1459 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1460 August 1980. 1462 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 1463 "NACK-Oriented Reliable Multicast (NORM) Transport 1464 Protocol", RFC 5740, November 2009. 1466 [I-D.ietf-fecframe-framework] 1467 Watson, M., "Forward Error Correction (FEC) Framework", 1468 draft-ietf-fecframe-framework-10 (work in progress), 1469 September 2010. 1471 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1472 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1474 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1475 Announcement Protocol", RFC 2974, October 2000. 1477 [DVB-ETR-289] 1478 DVB ETR-289, "Digital Video Broadcasting (DVB); Support 1479 for use of scrambling and Conditional Access (CA) within 1480 digital broadcasting systems", October 1996. 1482 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1483 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1484 RFC 3711, March 2004. 1486 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1487 Internet Protocol", RFC 4301, December 2005. 1489 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1490 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1492 Authors' Addresses 1494 Ali Begen 1495 Cisco 1496 181 Bay Street 1497 Toronto, ON M5J 2T3 1498 Canada 1500 Email: abegen@cisco.com 1502 Eric Friedrich 1503 Cisco 1504 1414 Massachusetts Ave. 1505 Boxborough, MA 01719 1506 USA 1508 Email: efriedri@cisco.com