idnits 2.17.1 draft-curet-avt-rtp-mpeg4-flexmux-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Missing revision: the document name given in the document, 'draft-curet-avt-rtp-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-curet-avt-rtp-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-curet-avt-rtp-', but the file name used is 'draft-curet-avt-rtp-mpeg4-flexmux-03' ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 1 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [15], [3], [4], [5], [6], [7], [8], [9], [1], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 75 has weird spacing: '... media unawa...' == Line 80 has weird spacing: '...mpasses multi...' == Line 131 has weird spacing: '...packets that ...' == Line 226 has weird spacing: '...FlexMux in-ba...' == Line 305 has weird spacing: '...ould be suita...' == (5 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date () is 739377 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. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1889 (ref. '5') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 3016 (ref. '7') (Obsoleted by RFC 6416) == Outdated reference: A later version (-08) exists of draft-ietf-avt-tcrtp-04 -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2327 (ref. '10') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2326 (ref. '11') (Obsoleted by RFC 7826) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '12') ** Obsolete normative reference: RFC 2048 (ref. '13') (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-08) exists of draft-ietf-avt-mpeg4-simple-03 Summary: 17 errors (**), 1 flaw (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio Visual Transport WG 3 Internet-Draft D.Curet,E.Gouleau, 4 S.Relier,C.Roux/ 5 P.Clement/G.Cherry 7 Document: draft-curet-avt-rtp- FT R&D /Thales BM/nCube 8 mpeg4-flexmux-03.txt 9 July, 1st 2002 10 Expires: January, 1 2003 12 RTP Payload Format for MPEG-4 FlexMultiplexed Streams 13 draft-curet-avt-rtp-mpeg4-flexmux-03.txt 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet- Drafts as refer- 26 ence material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This specification is a product of the Audio/Video Transport 33 working group within the Internet Engineering Task Force and 34 ISO/IEC MPEG-4 ad hoc group on MPEG-4 over Internet. Comments 35 are solicited and should be addressed to the working group's 36 mailing list at rem-conf@es.net and/or the authors. 38 Section 9 of this document is intended for registering SDP names 39 with IANA as in RFC 2048. 41 Abstract 43 MPEG-4 is a recent standard from ISO/IEC for the coding of natural 44 and synthetic audio-visual data.This document describes a payload 45 format for transporting MPEG-4 synchronised and multiplexed data 46 using RTP. 47 Several services provided by RTP are beneficial for MPEG-4 48 encoded and multiplexed data transport over the Internet. 49 Additionally, the use of RTP makes it possible to synchronize 50 MPEG-4 data with other real-time data types. 52 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 54 1. Introduction 56 The MPEG-4 standard (ISO/IEC 14496) can be represented in a 57 layered architecture, where three layers can be identified as 58 follows: 59 +---------------------------------------+ 60 media aware, | COMPRESSION LAYER: | 61 | Elementary Streams (ES) encoding | 62 delivery unaware| MPEG-4 part 2 Visual | 63 layer | MPEG-4 part 3 Audio | 64 | MPEG-4 part 1 Bifs,OD,IPMP,OCI | 65 +---------------------------------------+ 66 ================================================ ESI Interface 67 +---------------------------------------+ 68 media and | SYNC LAYER (SL) | 69 delivery unaware| Elementary streams management | 70 layer | and synchronisation | 71 +---------------------------------------+ 72 ================================================DAI Interface 73 +---------------------------------------+ 74 delivery aware, | DELIVERY LAYER (DMIF) | 75 media unaware |provides FLEXMULTIPLEXING of SL streams| 76 layer | and transparent access | 77 | to the delivery technology | 78 +---------------------------------------+ 79 Although the Delivery Layer mostly focuses on the control plane 80 it also encompasses multiplexing tools, called the Flexmux 81 tools, to multiplex MPEG-4 SL streams. MPEG makes a "constant 82 delivery delay" assumption: each MPEG-4 packet transmitted over 83 the network should have a nearly constant transmission delay. 84 Under this assumption, the reconstruction of the correct timing 85 of MPEG-4 bitstreams is supported similarly both by the MPEG-4 86 SL stream and by the MPEG-4 FlexMux stream syntaxes. 88 Different payload formats have been defined or are under 89 definition to carry some (or all) types of MPEG-4 Elementary 90 streams, to carry MPEG-4 SL streams, see [7], [14] & [15]. 91 This document will specify a RTP payload format to enable the 92 carriage of Flexmux streams. 93 2. MPEG-4 overview 94 2.1. Compresion layer: 96 The compressed content produced by this layer are the Elementary 97 Streams (ESs)that are organised in Access Units (AUs). An AU is 98 the smallest element to which timestamps can be assigned. 100 AUs are passed to the Synchronisation Layer (SL) together with 101 timestamps, RandomAccess, and other information through the ESI 102 interface. 104 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 105 The Compression Layer processes the traditional individual 106 audio/visual elementary streams (ES) and some associated 107 'systems' elementary streams (ES) such as Bifs, OD, IPMP and 108 OCI elementary streams. 110 The MPEG-4 audio/visual ES syntaxes are defined in[3] and[2]. 111 The 'systems' ES syntaxes are described in [1]: the Bifs ES 112 syntax allows a dynamic scene description. The OD ES syntax 113 allows the description of the hierarchical relations, location 114 and properties of different ESs through a dynamic set of Object 115 Descriptors. The 'system' ES may require to be carried with a 116 better protection than the traditional audio/visual ESs. 118 The compression layer is unaware of a specific delivery 119 technology, but it can react to the characteristics of a 120 particular delivery layer such as the path-MTU or packet loss or 121 bit error characteristics. 123 2.2. Synchronisation Layer: 125 The MPEG-4 SL stream syntax is defined in [1]. It provides a 126 unique and homogeneous encapsulation of any ES which is 127 organised in AUs. This the case of all the MPEG-4 ESs, but it can 128 also be the case of non MPEG-4 ESs. 129 That layer primarily provides the synchronisation between ESs. 130 Integer or fractional AUs, from the same ES, are encapsulated in 131 SL packets that build an SL stream. 133 SL packets are passed to the Delivery Layer (DMIF) through the 134 DMIF Application Interface (DAI interface), which can allows 135 assigning QoS requirements to the delivery of SL streams. 137 The synchronisation layer is unaware of a specific delivery 138 technology, but it can react to the characteristics of a 139 particular delivery layer such as the path-MTU or packet loss. 141 2.3. The Delivery Layer & the Flexmultiplexing: 143 The MPEG-4 Delivery Layer consists of the Delivery Multimedia 144 Integration Framework defined in [4]. This layer is media 145 unaware but delivery technology aware. It provides transparent 146 access to and delivery of content irrespective of the 147 technologies used. 149 This interface supports content location independent protocols 150 firstly for establishing the MPEG-4 session and secondly for 151 accessing to transport channels. DMIF monitors transport 152 channels on the QoS requirements assigned to the SL streams, 153 and supports the Flexmultiplexing of the SL streams, by the means 154 of the MPEG-4 FlexMux tools. There are different possible FlexMux 155 tools. FlexMux streams delivery is defined in [4], while the 157 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 158 FlexMux stream syntax is defined within [1]. 160 This draft specifies an RTP [5] payload format for transporting 161 multiplexed MPEG-4 encoded data streams. It can be presented as 162 an instance of the MPEG-4 Delivery layer. 164 The SL streams can be FlexMultiplexed into FlexMux streams. A 165 FlexMux stream is a succession of FlexMux packets. Each FlexMux 166 packet is built from a FlexMux packet header followed by a FlexMux 167 packet payload. The FlexMux packet payload consists in one or 168 several complete SL packets 169 The FlexMux packet header is composed of a one byte index 170 followed by a length field. The index gives the FlexMux Channel 171 number. 173 A particular FlexMux Channel number (index=238) is reserved to 174 identify a particular "signalling" FlexMux channel. The �238� 175 packets are dedicated to carry a FlexMux Clock Reference time 176 stamp (FCR) indicating its arrival time and the bitrate of the 177 FlexMux stream. FlexMux streams are piecewise constant 178 bit-streams. 179 A "238" packet can also carry, "in-band", the different FlexMux 180 descriptors: FlexMuxChannel, FlexMuxBufferSize, FlexMuxTiming, 181 FlexMuxCodeTable and FlexMuxIdent descriptors. 183 The FlexMux descriptors can also be provided by out-of-band means 184 (e.g. SDP). 185 2.3.1. Some of the advantages of FlexMultiplexing: 187 1. Since a typical MPEG-4 session may involve a large number of 188 objects, that may be as many as a few hundred, transporting 189 each ES as an individual RTP session may not always be 190 practical. The use of one session per elementary stream cannot 191 be much cost effective, both on the server side and on the 192 client side in terms of performance, when the number of 193 elementary streams will increase within a scene. 195 2. The use of one single session for a multiplexed bitstream 196 enables to send a bunch of ESs that are tightly synchronized 197 together. Some of these ESs can themselves be Bifs and OD 198 ESs when a scene description is used with Audio-Visual ES, 199 and some other ESs can be OCI ES, and even IPMP (or DRM) ES when 200 such systems are involved. 202 3. The FlexMultiplexing management supports concatenation of 203 multiple SL packets into one FlexMux packet, by the use of 204 FlexMuxCode table entries. 206 4. If the applied multiplexing policy is smoothing at the maximum 207 the multiplexed SL streams, mutual synchronization between these 208 SL streams can be easily preserved when packet losses occur. 210 5. The use of the FlexMux technology enables possible 212 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 213 interconnection between Internet network and digital television 214 network, as MPEG normatively defines the use the MPEG-4 FlexMux 215 syntax to carry MPEG-4 over MPEG-2 transport channels[9]. 217 6. The reconstruction of the correct timing of the FlexMux 218 stream is possible, using timing samples (FCRs) carried within 219 the FlexMux signalling channel, if the "constant delivery delay" 220 assumption can be assumed. 222 7. The overall MPEG-4 receiver buffer size is reduced, as 223 MPEG-4 compliant Flexmultiplexed streams, by the use of the 224 MPEG-4 timestamps, respect the MPEG-4 system decoder model 226 8. The FlexMux in-band signalling mechanism that allows to 227 signal dynamically, at anytime, within the stream itself, the 228 bit-rate of the stream (FlexMux streams have a piecewise constant 229 bit-rate), allowing to have an easy bandwidth management. FlexMux 230 descriptors and Ad Hoc descriptors are carried within this in- 231 band signalling mechanism. 233 9. Protection can be enhanced by means of repetition of vital SL 234 packets. 236 10. Content providers are able to bundle together a single 237 stream with assurance that associated streams will be kept 238 together and synchronized. 240 2.3.2. Some of the disadvantages of FlexMultiplexing: 242 One disadvantage that can be seen with FlexMultiplexing is the 243 Flexmultiplexing policy itself, that brings more complexity to 244 the server side. 246 The major disadvantage with the packetization of the MPEG-4 247 Flexmultiplexed streams is the added packet header overhead. 248 In order to minimize the overhead, two FlexMux tools, with two 249 different FlexMux packet length fields are supported. 251 MPEG-4 does not support a reduction mechanism of the carried 252 MPEG-4 Flexmultiplexed streams packet headers. This issue needs 253 certainly be resolved using a mechanism similar to what was 254 proposed with [8]. 256 3. applicability statement 258 3.1. Environment of the payload format: 260 This payload format is dedicated to applications relying on an 261 MPEG-4 scene. The contents of a scene may vary completely from one 262 application to another application. A scene may be either quite 263 simple (description of a 2D layout, in the streaming case), or 265 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 266 more complex (with 3D objects). A scene can be considered, on one 267 hand, as a monolithic and static declaration, as on the other 268 hand, it may be considered dynamicaly changing along with time. 270 3.2. Restrictions REQUIRED on the contents: 272 Which Elementary streams to FlexMultiplex together?: 273 According to the DMIF principle of MPEG-4, Elementary streams 274 are FlexMuliplexed together when they require the same Quality 275 of Service over the network. As in general, the System 276 Elementary streams require a better protection (see next 277 paragraph on the handling of System Elementary streams), the 278 application may take advantage in FlexMultiplexing system 279 streams in a first FlexMux stream provided with a good 280 protection, while other "non system" streams will be 281 Flexmultiplexed within a second FlexMux stream provided with 282 less achieved protection. 283 Which time base? 284 When all the Elementary streams that build a scene are 285 associated with a common time base, the FlexMux clock reference 286 stream constitutes this common time base. When the network 287 jitter can be handled (the "constant delivery delay" assumption 288 verified), reconstruction of this common clock can be achieved, 289 on the receiving side. 291 3.3. Handling of System Elementary streams: 293 Senders SHOULD ensure that packet loss does not cause severe 294 problems in application execution when the Elementary Streams carry 295 System Elementary streams such as programmatic content, DRM (or 296 IPMP), metadata information and "scene description" streams (OD 297 commands, BIFS commands). 299 MPEG-4 has introduced the "scene carousel mechanism" which supports 300 the possibility to dynamically change the "scene description" by 301 sending animation information (changes in parameters) and structural 302 change information (updates). This mechanism provides "scene 303 description" ESs with Random Access Points (RAPs). Like for key 304 frames for video, the periodicity of transmission of these RAPs 305 should be suitabily adjusted depending on the application and the 306 network it is deployed on. 308 Reliability can be improved by re-transmission, SL packet 309 duplication or by using the "scene description carousel" mechanism, 310 while observing the general congestion control principles. 312 The application has to take into account the delays introduced by 313 these two methods. Contents have to be send sufficiently in advance. 314 The application can achieve synchronisation, at the receiver side, 315 by the means of the different timestamps (FCRs, DTSs, and CTSs). 317 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 318 When such measures are deemed insufficiently adequate, instead of 319 this payload format applications SHOULD use more reliable means to 320 transport the information, for example by applying an FEC scheme for 321 RTP (such as in RFC 2733), or by using RTP over TCP (such as in RFC 322 2326), while still giving due consideration to congestion control. 323 For a general description of methods to repair streaming media see 324 RFC 2354. 325 4. Benefits of using RTP for transport: 327 i. Ability to synchronize MPEG-4 streams with other RTP 328 payloads 330 ii. Monitoring MPEG-4 delivery performance through RTCP 332 iii. Combining MPEG-4 and other real-time data streams 333 received from multiple end-systems into a set of 334 consolidated streams through RTP mixers 336 iv. Converting data types, etc. through the use of RTP 337 translators 338 5. Conventions used in this document 339 5.1. general: 340 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 341 NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 342 'OPTIONAL' in this document are to be interpreted as described 343 in RFC-2119 [6]. 344 5.2. MPEG-4 glossary: 345 AU :Access Unit, Bifs: Binary format for scene, 346 CTS:Composition Timestamp, DAI: DMIF Application Interface 347 DMIF: Delivery Multimedia Integration Framework, 348 DTS: Decoding Timestamp, DRM: Digital Right Management 349 ES: Elementary stream, ESI: Elementary stream Interface, 350 FlexMux: Flexible Multiplex, 351 FCR: FlexMux Clock reference, 352 IPMP: Intellectual Property Management and Protection, 353 OCI: Object Content Information OCR: Object Clock Reference 354 OD: Object descriptor, 355 QoS: Quality of service, SL: Synchronization layer 357 6. The RTP packet 359 6.1. The RTP packet header 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |V=2|P|X| CC |M| PT | sequence number | 366 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | timestamp | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | synchronization source (SSRC) identifier | 371 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 372 : contributing source (CSRC) identifiers | 373 |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 374 | | 375 | | 376 | RTP Packet Payload | 377 | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 1 - An RTP packet for MPEG-4 FlexMux stream 381 6.2. RTP header fields usage streams: 383 Payload Type (PT): The assignment of a particular RTP payload 384 type to this new packet format, is outside the scope of this 385 document, and is not specified here. If the dynamic payload 386 type assignment is used, it can be specified by some out of 387 band means (e.g. SDP, according to the syntax proposed in the 388 paragraph 9) that the MPEG-4 FlexMux payload format 389 is used for the corresponding RTP packets. 391 Marker (M) bit: The M bit is set to 1 to indicate that the RTP 392 packet payload includes the end of each Access Unit of which data 393 is contained in this RTP packet. 394 The M bit is set to 0 when the RTP packet contains one or more 395 Access Unit fragments that are not Access Unit ends. 397 Extension (X) bit: Defined by the RTP profile used. 399 Sequence Number: Increment by one for each RTP data packet sent. 400 It starts with a random initial value for security reasons. 402 Timestamp: 32 bits: it reflects the sampling instant of the 403 FlexMux packet corresponding to the RTP packet. The sampling 404 instant is given by the same clock that increments monotonically 405 and linearly as the one which is used to validate the FCR field 406 in the "238" specific FlexMux channel. Unless specified by an out 407 Of band means (e.g. SDP), the resolution of the timestamp is set 408 to its default value(90KHz). 410 SSRC, CC and CSRC fields are used as described in RFC 1889 [5]. 412 RTCP SHOULD be used as defined in RFC 1889 [5]. 414 Timestamps in RTCP SR packets: 415 The RTP timestamp value is the RTP timestamp that would be 417 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 418 applied to an RTP packet for data that would be sent at the 419 instant the SR packet is being generated and sent. 420 The NTP timestamp value is the NPT time at which that SR packet 421 is sent. 423 6.3. The RTP packet payload 425 The RTP packet payload is built from an integer number of 426 complete FlexMux packets, defined in [1]. 427 Each FlexMux packet is built from a FlexMux packet header 428 followed by a FlexMux packet payload. The FlexMux packet header 429 is composed of a one byte index followed by a length field. The 430 length field can be on one byte (when the"first" FlexMux tool is 431 used) or on several bytes (when the "second" FlexMux tool is 432 used). The index identifies the FlexMux packet in the FlexMux 433 stream. 435 7. Fragmentation rules 437 MPEG-4 Access Units (AUs) are the smallest entity to which MPEG-4 438 is assigning temporal references. AUs are embedded within SL 439 packets, and the SL packets embedded within FlexMux packets. 441 Some MPEG-4 codecs define optional syntax for Access Units sub- 442 entities (AU parts) that are independently decodable for error 443 resilience purposes. In that mode the maximum size of the AU 444 parts depends on the path-MTU size, taking care of the SL and 445 FlexMux packet headers'overhead. 447 As no fragmentation occur at the FlexMux level, this section on 448 fragmentation rules is only a concern for the compression Layer 449 (when producing the AUs or the AU sub_entities that are 450 independantly decodable -the AU parts) and the SL layer (when 451 performing Access Unit -or AU part- fragmentation into SL 452 packets), in order to prevent media decoding difficulties at the 453 receiver side. 455 A FlexMux packet contains one or several SL packets. If the first 456 FlexMux tool is used, SL packets MUST be less than 255 bytes long. 457 If the second FlexMux tool is used, this length is limited to 268 458 Mbytes. 460 The size of the FlexMux packets should be adjusted such that 461 the resulting RTP packet (embedding one or several FlexMux 462 packets) is not larger than the path-MTU. 464 8. Transport of MPEG-4 FlexMux streams 466 An MPEG-4 FlexMux packet is mapped directly onto the RTP 468 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 469 payload without any addition of extra header fields or removal 470 of any FlexMux packet header syntactic elements. 472 There are packetization restrictions due to the fact that no 473 synchronization pattern is part of the FlexMux packet header: 474 An RTP packet should contain an integer number of complete 475 FlexMux packets. 476 An RTP packet payload should start with the start of a FlexMux 477 packet. An RTP packet payload should end with the end of a 478 FlexMux packet. 480 Each RTP packet will contain a timestamp derived from the 481 sender's clock reference, synchronized to the FlexMux Clock. 482 That timestamp represents the sampling instant of the 483 first byte of the RTP packet. The sampling instant is given by 484 the same clock as the one used to validate the FCR field in the 485 FlexMux stream. 487 Special consideration is to be given to the transport of FlexMux 488 packets that carry the FCR samples. Such FlexMx packets have an 489 index ==238. When such a "238" FlexMux packet is transported 490 within a RTP packet, it is always the first FlexMux packet of 491 that RTP packet. The direct comparison between the FCR sample and 492 the RTP time stamp allows the receiver to know the exact 493 relationship between these two time stamps, when the RTP 494 timestamp is randomly chosen. 496 The FCRs, as well as the CTSs and the DTSs embedded within a 497 FlexMux stream are samples of the same common clock. The 498 relationship between the different CTSs and DTSs and the FCRs are 499 defined according to the constraints of the MPEG-4 system decoder 500 model). 501 As the DTSs and CTSs embedded within a FlexMux stream are avail 502 able at the application level (through the ESI interface, above 503 the SL layer), synchronisation with other media can be achieved at 504 the application level. 506 When the "constant delivery delay" assumption can be assumed 507 (handling, after estimation, of the network jitter) the FCR 508 samples may be used, on the receiver side to accurately 509 reconstruct the original sender�s FlexMux clock. 511 On the receiving side, the RTP packet timestamp will not be passed 512 to the MPEG-4 Flexdemultiplexor. 514 The FlexMux descriptors (declaration descriptor, timing 515 descriptor, Channel Table descriptor, codetable entry 516 descriptor, buffersize descriptor,etc..) describing the 517 characteristics of the FlexMux stream may be provided by out 518 of band means (e.g. SDP), and (or) by the inband signalling 519 mechanism supported by the FlexMux stream syntax [1]. 520 Ad Hoc (non MPEG) descriptors are also supported. 522 When the IP packet marking facility is needed, as it is based on 523 the 'degradationPriority' field present in each SL packet, all 525 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 526 the FlexMux packets grouped in the same RTP packet should contain 527 SL packets where the 'degradationPriority' field should be filled 528 with the same value. 530 Protection mechanisms for FlexMux streams within RTP packets 531 are outside of the scope of this specification. 533 9. SDP syntax 535 It is assumed that one typical way to signal the FlexMux streams 536 characteristics of this payload format is via a SDP message that 537 may be transported to the client in reply to a RTSP [11] DESCRIBE 538 command, or via SAP [12]. 539 The SDP protocol is decribed in [10]. 541 9.1. Types and Names 543 This section describes the MIME types and names associated with 544 this payload format. This section is intended for registration 545 with IANA [13]. 547 9.1.1. MIME type registration 549 MIME media type name: "video" or "audio" or "application" 551 "video" SHOULD be used for MPEG-4 Visual streams (i.e. video as 552 defined in ISO/IEC 14496-2 [2] and/or graphics as defined in 553 ISO/IEC 14496-1 [1]) or MPEG-4 Systems streams that convey 554 information needed for an audio/visual presentation. 556 "audio" SHOULD be used for MPEG-4 Audio streams (ISO/IEC 14496-3) 557 or MPEG-4 Systems streams that convey information needed for an 558 audio only presentation. 560 "application" SHOULD be used for MPEG-4 Systems streams 561 (ISO/IEC14496-1) like MPEG-4 FlexMux streams that serve other 562 purposes than only an audio/visual presentation. 564 The payload names used in an RTPMAP attribute within SDP, to 565 specify the mapping of payload number to its definition, also 566 come from the MIME namespace. Each of the RTP payload mappings 567 defined above has a distinct name. It is recommended that 568 visual streams be identified under 'video', and audio streams 569 be identified under 'audio', and otherwise 'application' be 570 used. 572 When a FLexMux stream is served (e.g. over HTTP) or otherwise 573 must be identified by a MIME type, the type 'application/mpeg4- 574 flexmux' SHALL be used. These files consist of concatenated 575 FLexMux packets in transmission order. 576 Internet Draft RTP payload for MPEG-4 FlexMux streams July 02 578 MIME media type name:application 579 MIME subtype name:mpeg4-flexmux 581 Required parameters: none 582 Optional parameters: none 583 Encoding considerations:base64 generally preferred; 584 files are binary and should be transmitted without CR/LF 585 conversion, 7-bit stripping etc. 587 9.1.2. attributes 589 A new encoding name is defined for the a = rtpmap attribute, the 590 new registred mpeg4-flexmux MIME subtype 592 a = rtpmap: mpeg4-flexmux/