idnits 2.17.1 draft-curet-avt-rtp-mpeg4-flexmux-00.txt: ** The Abstract section seems to be numbered 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 842 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 108 has weird spacing: '... media unawa...' == Line 113 has weird spacing: '...mpasses multi...' == Line 428 has weird spacing: '... of the fmxCl...' == Line 615 has weird spacing: '...display time-...' == Line 616 has weird spacing: '...network jitte...' == (4 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). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 802, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 805, but no explicit reference was found in the text -- 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) == Outdated reference: A later version (-08) exists of draft-ietf-avt-tcrtp-01 == Outdated reference: A later version (-04) exists of draft-singer-mpeg4-ip-01 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2327 (ref. '10') (Obsoleted by RFC 4566) Summary: 10 errors (**), 0 flaws (~~), 14 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 J.Van der Meer/ 4 C.Roux,E.Gouleau, 5 D.Curet,S.Relier/ 6 P.Clement/ 7 G.Cherry 8 Philips/FT R&D /Thomcast/ 9 nCube 10 February, 2001 11 Expires: August, 2001 13 RTP Payload Format for MPEG-4 FlexMultiplexed Streams 14 draft-curet-avt-rtp-mpeg4-flexmux-00.txt 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance 19 with all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as 29 'work in progress.' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed 33 at http://www.ietf.org/shadow.html. 35 2. Abstract 37 This document describes a payload format for transporting 38 MPEG-4 encoded and multiplexed data using RTP. MPEG-4 is a 39 recent standard from ISO/IEC for the coding of natural and 40 synthetic audio-visual data. 41 Several services provided by RTP are beneficial for MPEG-4 42 encoded and multiplexed data transport over the Internet. 43 Additionally, the use of RTP makes it possible to synchronize 44 MPEG-4 data with other real-time data types. 45 This specification is a product of the Audio/Video Transport 47 C.Roux & al. Page 1 23/02/01 49 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 51 working group within the Internet Engineering Task Force and 52 ISO/IEC MPEG-4 ad hoc group on MPEG-4 over Internet. Comments 53 are solicited and should be addressed to the working group's 54 mailing list at rem-conf@es.net and/or the authors. 56 RTP PAYLOAD FORMAT FOR MPEG-4 FLEXMULTIPLEXED STREAMS 1 57 1. STATUS OF THIS MEMO 1 58 2. ABSTRACT 1 59 3. INTRODUCTION TO THE MPEG-4 STANDARD 3 60 4. OVERVIEW OF MPEG-4 END-SYSTEM ARCHITECTURE 4 61 5. BENEFITS OF USING RTP FOR TRANSPORT:5 62 6. CONVENTIONS USED IN THIS DOCUMENT 5 63 6.1 GENERAL: 5 64 6.2 MPEG-4 GLOSSARY: 5 65 7. THE RTP PACKET 6 66 7.1 THE RTP PACKET HEADER 6 67 7.2 RTP HEADER FIELDS USAGE STREAMS: 6 68 7.3 THE TWO RTP PACKET PAYLOADS 7 69 7.4 MPEG-4 FLEXMUX SIGNALING DESCRIPTORS 8 70 8. FLEX MULTIPLEXING 12 71 8.1 SOME OF THE ADVANTAGES : 12 72 8.2 DISADVANTAGES: 13 73 8.3. TRANSPORT OF MPEG-4 FLEXMUX STREAMS 13 74 9. SDP SYNTAX 15 75 9.1 ATTRIBUTES15 76 9.2 MIME TYPES16 78 C.Roux & al. expires 14/08/01 2 80 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 82 10. RTSP USAGE: 16 83 11. SECURITY CONSIDERATIONS 17 84 12. REFERENCES17 85 13. AUTHORS' ADDRESSES 18 87 3. Introduction to the MPEG-4 standard 89 The MPEG-4 standard (ISO/IEC 14496) can be represented in a 90 layered architecture, where three layers can be identified as 91 follows: 92 +---------------------------------------+ 93 media aware | COMPRESSION LAYER: | 94 and | Elementary Streams (ES) encoding | 95 delivery unaware| MPEG-4 part 2 Visual | 96 layer | MPEG-4 part 3 Audio | 97 | MPEG-4 part 1 Bifs,OD,IPMP,OCI | 98 +---------------------------------------+ 99 ================================================ ESI Interface 100 +---------------------------------------+ 101 media and | SYNC LAYER (SL) | 102 delivery unaware| Elementary streams management | 103 layer | and synchronisation | 104 +---------------------------------------+ 105 ================================================DAI Interface 106 +---------------------------------------+ 107 delivery aware | DELIVERY LAYER (DMIF) | 108 media unaware |provides Flexmultiplexing of SL streams| 109 layer | and transparent access | 110 | to the delivery technology | 111 +---------------------------------------+ 112 Although the Delivery Layer mostly focuses on the control plane 113 it also encompasses multiplexing tools and defines a bitstream 114 syntax, called the Flexmux, to multiplex MPEG-4 SL streams. The 115 reconstruction of the correct timing of MPEG-4 bitstreams is 116 supported both by the MPEG-4 SL stream syntax and by the MPEG-4 117 FlexMux stream syntax. The reconstruction of the correct timing 119 C.Roux & al. expires 14/08/01 3 121 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 123 of an MPEG-4 Flexmux stream is possible under various QoS 124 constraints related to the reduction of network jitter. MPEG 125 makes the assumption that all Flexmux packets transmitted over 126 the network should have a nearly constant transmission delay. 127 The reconstruction of the correct timing of the MPEG-4 Flexmux 128 streams is based on the fact that this assumption can be 129 verified, in accordance with the required accuracy of the 130 reconstructed timing of the MPEG-4 FlexMux stream. This 131 document will specify a RTP payload format to enable the 132 carriage of Flexmux streams. 134 4. Overview of MPEG-4 End-System Architecture 136 The Compression Layer processes the traditional individual 137 audio/visual elementary streams (ES) and some associated 138 'systems' elementary streams (ES) such as Bifs, OD, IPMP and 139 OCI elementary streams. 140 The MPEG-4 audio/visual ES syntaxes are defined in[2] and[3]. 141 The �systems� ES syntaxes are described in [1]: the Bifs ES 142 syntax allows a dynamic scene description. The OD ES syntax 143 allows the description of the hierarchical relations, location 144 and properties of different ESs through a dynamic set of Object 145 Descriptors. The �system� ES may require to be carried with a 146 better protection than the traditional audio/visual ESs. 147 The compressed content produced by this layer are organised 148 into Elementary Streams (ESs). The compression layer is unaware 149 of a specific delivery technology, but it can react to the 150 characteristics of a particular delivery layer such as the 151 path-MTU or packet loss or bit error characteristics. 152 The MPEG-4 SL stream syntax is defined in [1]. It provides a 153 unique and homogeneous encapsulation of any of the MPEG-4 ESs. 154 That layer primarily provides the synchronisation between ESs. 155 ESs are organised in Access Units (AU). An AU is the smallest 156 element to which timestamps can be assigned. Integer or 157 fractional AUs are then encapsulated in SL packets. 158 The MPEG-4 Delivery Layer consists of the Delivery Multimedia 159 Integration Framework defined in [4]. This layer is media 160 unaware but delivery technology aware. It provides transparent 161 access to and delivery of content irrespective of the 162 technologies used. The DAI interface between the SL layer and 163 the DMIF layer is called the DMIF Application Interface. This 164 interface supports content location independent protocols 165 firstly for establishing the MPEG-4 session and secondly for 166 accessing to transport channels. DMIF monitors transport 167 channels on the QoS requirements assigned to the SL streams, 168 and supports the multiplexing of the SL streams, by the means 170 C.Roux & al. expires 14/08/01 4 172 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 174 of the MPEG-4 FlexMux tools. There are two possible FlexMux 175 tools. FlexMux streams delivery is defined in [4], FlexMux 176 tools are defined within [1]. 177 MPEG makes the assumption that the carriage of MPEG-4 Flexmux 178 streams over the network should affect packets with an �ideal� 179 constant transmission delay; the reconstruction of the correct 180 timing of a MPEG-4 Flexmux streams is based on that assumption. 181 This draft specifies an RTP [5] payload format for transporting 182 multiplexed MPEG-4 encoded data streams. It can be presented as 183 an instance of the MPEG-4 Delivery layer. 185 5. Benefits of using RTP for transport: 187 i. Ability to synchronize MPEG-4 streams with other RTP 188 payloads 190 ii. Monitoring MPEG-4 delivery performance through RTCP 192 iii. Combining MPEG-4 and other real-time data streams 193 received from multiple end-systems into a set of 194 consolidated streams through RTP mixers 196 iv. Converting data types, etc. through the use of RTP 197 translators 199 6. Conventions used in this document 201 6.1 general: 203 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 204 NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 205 'OPTIONAL' in this document are to be interpreted as described 206 in RFC-2119 [6]. 208 6.2 MPEG-4 glossary: 210 AU :Access Unit Bifs: Binary format for scene 211 DMIF: Delivery Multimedia Integration Framework, 212 DAI: DMIF Application Interface, ES: Elementary stream, 213 ESI: Elementary stream Interface, FlexMux: Flexible Multiplex. 214 IPMP: Intellectual Property Management and Protection, 215 OCI: Object Content Information, OD: Object descriptor, 216 SL: Synchronization layer 218 C.Roux & al. expires 14/08/01 5 220 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 222 7. The RTP packet 224 7.1 The RTP packet header 226 0 1 2 3 227 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 2 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |V=2|P|X| CC |M| PT | sequence number | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | timestamp | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | synchronization source (SSRC) identifier | 234 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 235 : contributing source (CSRC) identifiers | 236 |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 237 | | 238 | | 239 | RTP Packet Payload | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 1 - An RTP packet for MPEG-4 FlexMux stream 244 7.2 RTP header fields usage streams: 246 Payload Type (PT): The assignment of a particular RTP payload 247 type to this new packet format, is outside the scope of this 248 document, and is not specified here. If the dynamic payload 249 type assignment is used, it can be specified by some out of 250 band means (e.g. SDP, according to the syntax proposed in the 251 paragraph 9) that the MPEG-4 FlexMux payload format 252 is used for the corresponding RTP packets. The specification 253 of the usage of MPEG-4 FlexMux payload format can also include, 254 if needed, the specification of the usage of the MPEG-4 FlexMux 255 signaling format. 257 Marker (M) bit: set to zero. 259 Extension (X) bit: Defined by the RTP profile used. 261 Sequence Number:Increment by one for each RTP data packet sent. 262 It starts with a random initial value for security reasons. 264 Timestamp: it represents the target transmission time for the 266 C.Roux & al. expires 14/08/01 6 268 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 270 first byte of the RTP packet. Unless specified by an out of 271 band means (e.g. SDP), the resolution of the timestamp is set 272 to its default (90KHz). 274 SSRC, CC and CSRC fields are used as described in RFC 1889 [5]. 276 7.3 The two RTP packet payloads 278 The MPEG-4 FlexMux payload format encompasses two payload 279 types: 280 the first one for MPEG-4 FlexMux packets and the second one for 281 MPEG-4 FlexMux signaling. 283 When the Payload type specifies the usage of the MPEG-4 284 FlexMux payload format, the RTP packet payload is built from 285 an integer number of complete, defined in [1]. 287 When the Payload type specifies the usage of the MPEG-4 288 FlexMux signaling payload format, the RTP packet payload is 289 built from an integer number of descriptors, defined in the 290 following 7.4. paragraph. 292 7.3.1 payload for the MPEG-4 FlexMux payload format 294 0 1 2 3 295 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 2 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | FlexMux Packet Header | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 299 | FlexMux Packet Payload (byte aligned) | 300 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | FlexMux Packet Header | FlexMux | 302 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 303 | Packet | 304 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Payload :...optional RTP padding | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 3 - An RTP Payload carrying MPEG-4 FlexMux packets 309 C.Roux & al. expires 14/08/01 7 311 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 313 7.3.2 payload for the MPEG-4 FlexMux signaling payload format 315 0 1 2 3 316 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 2 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | MPEG-4 FlexMux signaling descriptor | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 320 | | MPEG-4 FlexMux signaling descriptor | 321 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | signaling descriptor |...optional RTP padding | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 4 - An RTP Payload carrying MPEG-4 FlexMux signaling 325 descriptors 327 7.4 MPEG-4 FlexMux signaling descriptors 329 7.4.1 signaling descriptor usage: 331 They are used to describe in-band a FlexMux stream 332 characteristics. Their use is mostly static . Only one of these 333 descriptors (the FlexMux codetable entry descriptor) may have a 334 dynamic use, when the FlexMux stream characteristic is to be 335 dynamic. 337 They are built from a signaling descriptor header followed by a 338 signaling descriptor content. 339 The signaling descriptor header structure is identical for all 340 the signaling descriptors. 341 Their overall length is an integer number of bytes. 343 0 1 2 3 344 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 2 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | HEADER | CONTENT | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 5 - A signaling descriptor scheme 350 7.4.1 the signaling descriptor header 352 The signaling descriptor header is built from a tag field on 353 one byte, followed by a length field on one byte 355 C.Roux & al. expires 14/08/01 8 357 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 359 0 1 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | TAG | LENGTH | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 6 - A signaling descriptor header 366 TAG gives the type of the descriptor: 368 0x60 for FlexMux Channel Table descriptor 369 0x61 for FlexMux buffersize descriptor 370 0x62 for FlexMux timing descriptor 371 0x63 for FlexMux codetable entry descriptor 372 0x64 for FlexMux declaration descriptor 374 values from 0x00 to 0x5F, & value 0xFF are forbidden 375 values from 0x65 to 0xBF are ISO reserved 376 values from 0xC0 to 0xDF are IETF reserved 377 values from 0xE0 to 0xFE are Ad Hoc values 379 LENGTH - is the byte length of the descriptor's content that 380 follows. 382 7.4.2 FlexMux declaration descriptor 384 This descriptor is used to allow identification of some 385 different FlexMux streams within an MPEG-4 scene. This can 386 be the case when scalable coding is used. 387 When no FlexMux descriptor is used, the default TYPE is the 388 first FlexMux tool, and the default MODE is static. 389 0 1 390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | MUXID | TYPE| MODE | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 7 - declaration descriptor content 396 MUXID - is the identifier of the FlexMux stream 397 TYPE - is the type of the Multiplexing tool used to generate 398 the FlexMux stream. AS they are two FlexMux tools defined, 399 indicated type values shall be either 0 (for the first FlexMux 400 tool), 1 (for the second FlexMux tool). 402 C.Roux & al. expires 14/08/01 9 404 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 406 Values from 2 to 7 are IETF reserved, values 8 to 15 are Ad Hoc 407 values. 408 MODE � is the mode of management used by the Multiplexing tool, 409 to generate the FlexMux stream. Indicated mode values shall be 410 either 0 (static), 1 (dynamic). Values from 2 to 7 are IETF 411 reserved, values 8 to 15 are Ad Hoc values. 413 7.4.3 FlexMux timing descriptor 415 0 1 2 3 416 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 2 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | FCR-ES-ID | FCRRESOLUTION | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | FCRRESOLUTION (end) | FCRLENGTH | FMXRATELENGTH | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 422 Figure 8 - timing descriptor content 424 FCR-ES-ID � (16 bits)is the ES_ID associated to this clock 425 reference stream. 426 FCRRESOLUTION �(32 bits) is the resolution of the object time 427 base in cycles per second. 428 FCRLENGTH -(8 bits) is the length of the fmxClockReference 429 field in FlexMux packets with index = 238. A length of zero 430 shall indicate that no FlexMux packets with index = 238 are 431 present in this FlexMux stream. FCRLENGTH shall take values 432 between zero and 64. 433 FMXRATELENGTH � (8 bits)is the length of the fmxRate field 434 in FlexMux packets with index = 238. FMXRATELENGTH shall take 435 values between 1 and 32. 437 7.4.4 FlexMux Channel Table descriptor 439 0 1 2 3 440 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 2 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | ES1 | M1 | ES2(start) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | ES2 (end) | M2 | ...... | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | ........ | ESn | Mn | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Figure 9 - FLexMuxChannel Table descriptor content 450 C.Roux & al. expires 14/08/01 10 452 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 454 ,.., - these 16-bit fields specify the identifiers of 455 ISO/IEC 14496-1 SL-packetized streams defined in [1]. 457 ,..,,� This 8-bit fields specify the number of the 458 FlexMux channels used for these SL-packetized streams. 460 7.4.5 FlexMux codetable entry descriptor 462 0 1 2 3 463 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 2 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |MUXCODE|VERSION| SUBSTRUCTCNT | SLOTCNT |RCNT | M1 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | NB1 | M2 | NB2 |.............. | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | ..............| SlotCNT |RCNT | Mi | NBi | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Mi+1 | NBi+1 | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 10 � FLexMuxcode table descriptor content 475 MUXCODE - the number through which this FlexMux codetable entry 476 is referenced 478 VERSION - the version of the FlexMux codetable entry. 479 Only the latest received version of a FlexMux codetable entry 480 is valid. 482 SUBSTRUCTCNT is the number of substructures of this FlexMux 483 codetable entry. 485 SLOTCNT - the number of slots with data from different FlexMux 486 channels that are described by this substructure 488 RCNT - indicates how often this substructure is to be repeated. 489 A zero indicates that this substructure is to be repeated 490 infinitely. Zero is only permitted in the last substructure 491 of a FlexMux codetable entry. 493 M1,..,Mi - the FlexMux channels to which the data in this slot 494 belongs. 496 NB1,..,NBi - the number of data bytes in this slot associated 497 to the FlexMux channel M1, Mi. This number of bytes corresponds 498 to one SL packet. SL packets are defined in [1]. 500 C.Roux & al. expires 14/08/01 11 502 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 504 7.4.5 FlexMux buffersize descriptor 506 0 1 2 3 507 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 2 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | DEFAULTSIZE | M1 | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | SIZE1 | M2 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | SIZE2 | M3 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | SIZE3 |.............. | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | ............................................................. | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 11 - FlexMux buffersize descriptor content 521 DEFAULTSIZE - the default size of multiplex buffers for each 522 individual channel in a FlexMux stream. FlexMux channels that 523 use a different buffer size may signal this using the following 524 Mi,SIZEi assignments 526 M1,M2,M3 - the FlexMux channels 528 SIZE1, SIZE2, SIZE3 - the exact sizes of FlexMux buffers, for 529 FlexMux channels M1,M2 and M3 of this FlexMux stream. Sizes are 530 expressed in bytes. 532 8. Flex Multiplexing 534 8.1 Some of the advantages : 536 1. Since a typical MPEG-4 session may involve a large number of 537 objects, that may be as many as a few hundred, transporting 538 each ES as an individual RTP session may not always be 539 practical. The use of one session per elementary stream cannot 540 be much cost effective, both on the server side and on the 541 client side in terms of performance, when the number of 542 elementary treams will increase within a scene. 544 2. The use of one single session for a multiplexed bitstream 545 enables to send a bunch of ESs that are tightly synchronized 546 together. Some of these ESs can themselves be Bifs and OD 547 ESs when a scene description is used with Audio-Visual ES, 548 and some other ESs can be OCI ES, and even IPMP ES when such 549 systems are involved. 551 C.Roux & al. expires 14/08/01 12 553 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 555 3. The FlexMultiplexing management supports embedding multiple 556 SL packets into one FlexMux packet, by the use of FlexMux 557 codetable entries. 559 4. If the multiplexing policy used is smoothing at most the 560 multiplexed SL streams, mutual synchronization between these 561 SL streams can be easily preserved when packet losses occur. 563 5. The use of the FlexMux technology enables possible 564 interconnection between Internet network and digital television 565 network, as MPEG normatively defines the use the MPEG-4 FlexMux 566 syntax to carry MPEG-4 over MPEG-2 transport channels[8]. 568 6. The reconstruction of the correct timing of the FlexMux 569 stream is possible, if some QoS requirements are supported. 571 7. The overall MPEG-4 receiver buffer size is reduced, as 572 MPEG-4 compliant Flexmultiplexed streams, by the use of the 573 MPEG-4 timestamps, respect the MPEG-4 system decoder model. 575 8. The overall bandwidth management is easier. The FlexMux 576 syntax allows having piecewise constant bitrate FlexMux 577 bitstream, with an inband signaling mechanism. 579 9. Protection can be enhanced by means of repetitions of 580 vital SL packets. 582 10. Content providers are able to bundle together a single 583 stream with assurance that associated streams will be kept 584 together and synchronized. 586 8.2 Disadvantages: 588 The major disadvantage with the packetization of the MPEG-4 589 Flexmultiplexed streams is the added packet header overhead. 590 MPEG-4 does not support a reduction mechanism of the carried 591 MPEG-4 Flexmultiplexed streams packet headers. This issue needs 592 certainly be resolved using a mechanism similar to what was 593 proposed with [7]. During their transport, FlexMux packets 594 need not be compliant to the MPEG-4 standard, it is only when 595 they are delivered to the Flexdemultiplexer that the MPEG-4 596 compliance point is defined. 598 8.3. Transport of MPEG-4 FlexMux streams 600 C.Roux & al. expires 14/08/01 13 602 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 604 An MPEG-4 FlexMux stream is mapped directly onto the RTP 605 payload without any addition of extra header fields or removal 606 of any FlexMux packet header syntactic elements. 607 Each RTP packet will contain a timestamp derived from the 608 sender's clock reference. This clock is synchronized to the 609 FlexMux Clock Reference (FCR) and represents the target 610 transmission time of the first byte of the RTP packet payload. 611 On the receiving side, the RTP packet timestamp will not be 612 passed to the MPEG-4 Flexdemultiplexor. 613 This use of the timestamp is slightly different from the normal 614 use in RTP, in that it is not considered to be the media 615 display time-stamp. The first purpose of this RTP timestamp 616 will then be to reduce (after estimation) the network jitter, 617 and the relative time drift between the transmitter and the 618 receiver. 620 There are packetization restrictions due to the fact that no 621 synchronization pattern is part of the FlexMux packet header: 622 An RTP packet payload should start with the start of a FlexMux 623 packet. An RTP packet will contain an integer number of FlexMux 624 packets. 626 The FlexMux characteristics (declaration descriptor, timing 627 descriptor, Channel Table descriptor, codetable entry 628 descriptor, buffersize descriptor) may be provided by out of 629 band means (e.g. SDP), or by the inband signaling mechanism 630 supported by the use of the FLexMuxChannel signalling 631 descriptors. 633 The FlexMux declaration descriptor, FlexMux timing descriptor, 634 FlexMux Channel Table descriptor, FlexMux buffersize 635 descriptor, may only be used to define statically the FlexMux 636 stream characteristics. 638 The FlexMux codetable entry descriptor may change dynamically. 640 The IP packet marking facility may be needed. If this is the 641 case, as it is based on the 'degradationPriority' field 642 present in each FlexMux packet, all the FlexMux packets 643 grouped in the same RTP packet should have the 644 'degradationPriority' field filled with the same value. 646 The size of the FlexMux packets should be adjusted such that 647 the resulting RTP packet (embedding one or several FlexMux 648 packets) is not larger than the path-MTU. 650 Protection mechanisms for FlexMux streams within RTP packets 651 are outside of the scope of this specification. 653 C.Roux & al. expires 14/08/01 14 655 RTP payload format for MPEG-4 FlexMultiplexed streams 23/02/01 657 9. SDP syntax 659 9.1 attributes 661 New encoding names for the a = rtpmap attribute It is 662 recommended that, no matter what payload format is used, 663 each media stream be placed in a media section that is 664 appropriate. For example, a payload format which can carry 665 both video and audio streams may be used in sections of SDP 666 starting both with 'm=video' and 'm=audio'. The MIME name 667 for the payload format is thus registered under all applicable 668 branches. 670 a = rtpmap: /