idnits 2.17.1 draft-singer-mpeg4-ip-00.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '...f common characteristics that all MUST...' RFC 2119 keyword, line 79: '....2] RTP packets SHOULD have sequence ...' RFC 2119 keyword, line 82: '...nsmission scheme MUST respect decoding...' RFC 2119 keyword, line 86: '...ck ticks per second) SHOULD be used as...' RFC 2119 keyword, line 90: '...ried, all senders and receivers SHOULD...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 301 has weird spacing: '... C.Roux et al...' -- 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: '1' is defined on line 287, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 290, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 293, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 297, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '2') (Obsoleted by RFC 3551) -- Unexpected draft version: The latest known version of draft-ietf-mmusic-rtsp is -08, but you're referring to -09. == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sdp-05 == Outdated reference: A later version (-04) exists of draft-rgcc-avt-mpeg4flexmux-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-05) exists of draft-ietf-avt-rtp-mpeg4-es-01 == Outdated reference: A later version (-04) exists of draft-ietf-avt-mpeg4streams-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-03) exists of draft-ietf-avt-rtp-mpeg4-02 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-04) exists of draft-gc-avt-mpeg4visual-00 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtp-mp3-01 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio-Video Transport WG & Others 3 INTERNET-DRAFT D. Singer & P. Westerink 4 draft-singer-mpeg4-ip-00 Apple Computer & IBM 5 July 3 2000 6 Expires: January 3, 2001 7 MPEG Document number: M6150 9 A Framework for the delivery of MPEG-4 over IP-based Protocols 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 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 To learn the current status of any Internet-Draft, please check the 33 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Distribution of this document is unlimited. 40 Abstract 42 This document forms an umbrella specification for the carriage and 43 operation of MPEG-4 multimedia sessions over IP-based protocols, 44 including RTP, RTSP, and HTTP, among others. 46 It also serves to document the standard MIME types associated with 47 MPEG-4. 49 1 Introduction 51 MPEG-4 is a complex multimedia system designed for delivery over a 52 variety of transport protocols. It includes scene management, 53 interactivity, video, audio, and other streams. 55 This document provides a number of specifications for the detailed 56 mapping of MPEG-4 into several IP-based protocols. 58 Open issues: it might be desirable to signal to the terminal the 59 amount of buffering assumed by the encoding/transmission process (in 60 addition to any network jitter). 62 2 Use of RTP 64 There are a number of Internet Drafts describing RTP packetization 65 schemes for MPEG-4 data [5] [6] [7] [8] [9]. This draft does not 66 specify any new one. Media-aware packetization (e.g. video frames 67 split at recoverable sub-frame boundaries) is a principle in RTP, and 68 thus it is likely that several RTP schemes will be needed, to suit 69 both the different kinds of media - audio, video, etc. - and 70 different encodings (e.g. AAC and CELP audio codecs). 72 This specification requires that, no matter what packetization scheme 73 is used, there are a number of common characteristics that all MUST 74 have. 76 2.1] The RTP timestamp corresponds to the CTS of the earliest AU 77 within the packet. 79 2.2] RTP packets SHOULD have sequence numbers, and be sent, in 80 decoding order. Note that in the case where multiple, interleaved 81 access units are sent in one packet, this will not be adhered to 82 completely. However, any transmission scheme MUST respect decoding 83 dependencies in any re-ordering it does, so that dependent access 84 units do not arrive before the access units they depend on. 86 2.3] The MPEG-4 timescale (clock ticks per second) SHOULD be used as 87 the RTP timescale, e.g. as declared in RTP. 89 2.4] To achieve a base level of interoperability, and to ensure that 90 any MPEG-4 stream may be carried, all senders and receivers SHOULD 91 implement the simple scheme for the carriage of 1 elementary stream 92 over RTP [8]. It is not a requirement that any particular session 93 use this scheme for any particular scheme, merely that every terminal 94 be able to receive this scheme. 96 2.5] There is a single payload format for the carriage of Flexmux 97 over RTP [5]. Senders and receivers MAY implement this scheme. 99 2.6] Streams SHOULD be synchronized using RTP techniques (notable 100 RTCP sender reports); the MPEG-4 OCR is logically mapped to the NTP 101 time axis used in RTCP. 103 Other payload formats MAY be used. They are signalled as dynamic 104 payload IDs, defined by a suitable names (e.g. a payload name in an 105 SDP RTPMAP attribute). In particular, the development of specialized 106 RTP payloads for video (e.g. respecting video packets) and audio 107 (e.g. providing interleave [10]) is expected. It is possible that 108 these schemes can be compatible with the simple scheme required here 109 [8]. 111 For those streams requiring reliable delivery, the recommendation is 112 to investigate the leverage of existing work in the IETF in this area 113 (including, but not limited to FEC, re-transmission, or repetition), 114 rather than making it a characteristic of the packing scheme itself. 115 However, techniques in combined source/channel coding, or error- 116 correction which is dependent on the coding scheme, may make other 117 schemes attractive [9]. 119 3 SDP Information 121 This specification currently assumes that any session described by 122 SDP (e.g. in SAP, as a file download, as a DESCRIBE over RTSP) has at 123 most one MPEG-4 session. It is desirable that this restriction be 124 lifted. 126 3.1] Senders SHOULD alert receivers that an MPEG-4 session is 127 included, by means of an SDP attribute that is general (i.e. before 128 any "media" lines). This takes the form of an attribute line: 130 a=mpeg4-iod [] 132 In an RTSP session, the location is optional. If the location is not 133 supplied, the IOD is retrieved over the RTSP session by using 134 DESCRIBE with an accept of type application/mpeg4-iod. Where the SDP 135 information is supplied by some other means (e.g. as a file, in SAP), 136 the location is obligatory and should be a URL enclosed in double- 137 quotes, which will supply the IOD (e.g. small ones may be encoded 138 using DATA:, or otherwise HTTP: or other suitable file-access URL). 140 3.2] The mapping of RTP streams to elementary streams. This needs to 141 cover the Flexmux case as well as the single stream. Within the SDP 142 information, a stream-specific attribute SHOULD be present for each 143 MPEG-4 stream. It takes one of two forms, depending on whether a 144 single elementary stream, or a flexmux, is carried. 146 a=mpeg4-esid a.b.c or a=mpeg4-esids m.i:a.b.c,n.k:p.q 147 The first attribute is used for single streams; the second for 148 flexmux. In this, a is the ESID of the top-level OD stream (declared 149 within the IOD), b is the ESID within that scope of another OD 150 stream, and c is the ESID within that scope of the stream; similarly 151 for p and q. m and n are muxcodes (identifying the table used), and 152 i and k are flexmux channel numbers within the indicated muxcode. 154 3.3] The flexmux stream also needs a muxcode table supplied to the 155 receiver. These are indicated via a stream-level attribute. 157 a=mpeg4-muxcodetable 159 where is a URL enclosed in double quotes, that will supply 160 the table(s). If they are small, a DATA: URL will probably suffice 161 to carry them in-line. If not, the URL should use a file-retrieval 162 scheme (e.g. HTTP, FTP). The data at the indicated URL consists of 163 some number of concatenated muxcode tables, complete, in binary 164 format (but note that DATA URLs allow for base64 encoding of binary 165 data, which would be needed here). The mime type of a muxcode table 166 needs deciding (application/mpeg4-muxcodetable). These tables have an 167 intrinsic length, so simple concatenation suffices. 169 4 MIME Types 171 Amendment 1 of the MPEG-4 standard (also known as version 2) is 172 nearing completion, and includes a standard file type for 173 encapsulating MPEG-4 data. This file type can be used in a number of 174 ways: perhaps the most important are its use as an interchange 175 format for MPEG-4 data, its use as a content-download format, and as 176 the format read by streaming media servers. 178 These first two uses will be greatly facilitated if there is a 179 standard MIME type for serving these files (e.g. over HTTP). 181 The MPEG-4 standard is broad, and therefore the type of data which 182 may be in such a file can vary. In brief, simple compressed video 183 and audio (using a number of different compression algorithms) can be 184 included; interactive scene information; meta-data about the 185 presentation; references to MPEG-4 media streams outside the file; 186 and so on. 188 The historical approach for MPEG data is to declare it under "video". 189 Though MPEG-4 is considerably broader than MPEG-1 and MPEG-2, I 190 believe that we should follow this precedent, as "multipart" seems 191 inappropriate and "application" too diffuse. However, MPEG-4 may be 192 used for a purely audio environment, and in that case the type 193 audio/mpeg4 should be used. In either case, these indicate files 194 conforming to the "MP4" specification (ISO/IEC 14496 Amendment 1, 195 systems file format). 197 3.1] When an MP4 file is served (e.g. over HTTP) or otherwise must be 198 identified by a MIME type, the type "video/mpeg4" SHOULD be used. 199 The type "audio/mpeg4" MAY be used when the MPEG-4 presentation 200 contained within the MP4 file has no visual aspects and is entirely 201 auditory. 203 3.2] In some cases, the initial object descriptor needs to be 204 identified with a MIME type. In this case, the type 205 "application/mpeg4-iod" SHOULD be used. 207 3.3] In some cases, the muxcode table needed by a flexmux decoder 208 needs to be identified with a MIME type. In this case, the type 209 "application/mpeg4-muxcodetable" SHOULD be used. 211 3.4] The payload names used in an RTPMAP attribute within SDP, to 212 specify the mapping of payload number to its definition, also come 213 from the MIME namespace. Each of the RTP payload mappings defined 214 above has a distinct name. For those payloads carrying a variety of 215 MPEG stream types, the name SHOULD be drawn from the "video" 216 namespace. For those payloads specific to audio only, the name 217 SHOULD be drawn from the "audio" namespace. 219 Given the broad and general nature of MPEG-4, and the interactive 220 environment, it is hard to say that there are no security 221 considerations. However, none are known to the author at this time, 222 and the standard was developed with the intent that there be none. 224 MIME media type name: video, and audio 225 MIME subtype name: mpeg4 227 MIME media type name: application 228 MIME subtype name: mpeg4-iod, mpeg4-muxcodetable 229 Required parameters: none 230 Optional parameters: none 231 Encoding considerations: base64 generally preferred; files are 232 binary and should be transmitted 233 without CR/LF conversion, 7-bit 234 stripping etc. 235 Security considerations: None known at the time of writing 236 Interoperability considerations: A number of interoperating 237 implementations exist within the 238 MPEG-4 community; and that community 239 has reference software for reading 240 and writing the file format. 241 Published specification: Pending (ISO/IEC 14496, MPEG-4 242 Systems Amendment 1). 243 Applications: Multimedia 244 Additional information: 246 Magic number(s): none 247 File extension(s): mp4 and mpg4 are both declared at 248 249 Macintosh File Type Code(s): mpg4 is registered with Apple 251 Person to contact for info: David Singer, singer@apple.com 253 Intended usage: Common 255 Author/Change controller: David Singer, MPEG-4 file format 256 chair 258 5 RTSP usage 260 RTSP may be used as a session control protocol for sessions which 261 carry MPEG-4 information. When RTSP is used as a session-control 262 protocol: 264 5.1] RTP SHOULD be used as the transport protocol. 266 5.2] The initial DESCRIBE format SHOULD be SDP. If the SDP 267 information reveals that an IOD is needed, and the terminal does not 268 already have it, then a second DESCRIBE accepting an IOD SHOULD be 269 performed (see above). 271 5.3] Note that if all MPEG-4 streams are closed (TEARDOWN) then the 272 RTSP session ID will be lost. The next (re-)opened stream will 273 supply a new session ID. Care should be taken that the target of the 274 URL has not changed in the interval; new DESCRIBEs may be needed. 276 Acknowledgments 278 This draft has benefited greatly by contributions from many people, 279 including Mike Coleman, Jean-Claude Duford, Carsten Herpel, Olivier 280 Avaro, Paul Christ, and many others. Their insight, foresight, and 281 contribution is gratefully acknowledged. Little has been invented 282 here by the authors; this is mostly a collation of greatness that 283 has gone before. 285 References 287 [1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real- 288 Time Applications", IETF RFC 1889, January 1996. 290 [2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video 291 Conference with Minimal Control", IETF RFC 1890, January 1996. 293 [3] H. Schulzrinne, et. al., "Real Time Streaming Protocol", IETF 294 Draft, draft-ietf-mmusic-rtsp-09.txt, February 2 1998, Expires: 295 August 2 1998. 297 [4] M. Handley, "SDP: Session Description Protocol", IETF Draft, 298 draft-ietf-mmusic-sdp-05.txt, November 21 1997, Expires: November 21 299 1998. 301 [5] C.Roux et al., "RTP Payload Format for Flexmultiplexed MPEG-4 302 Streams", IETF Draft, draft-rgcc-avt-mpeg4flexmux-00, March, 09 2000 303 expires Sept 9 2000 305 [6] Yoshihiro Kikuchi et al., "RTP payload format for MPEG-4 306 Audio/Visual streams", IETF Draft, draft-ietf-avt-rtp-mpeg4-es-01, 307 Feb 1 2000, expires Aug 1 2000 309 [7] C.Guillemot et al., "RTP Payload Format for MPEG-4 with Flexible 310 Error Resiliency", IETF Draft, draft-ietf-avt-mpeg4streams-00, March 311 1 2000, expires Sept 1 2000 313 [8] R Civanlar et al., " RTP Payload Format for MPEG-4 Streams", IETF 314 Draft, draft-ietf-avt-rtp-mpeg4-02, ?? 2000, expires ?? 20000 316 [9] C.Guillemot et al., "RTP payload format for MPEG-4 Visual 317 Advanced Profiles", IETF Draft, draft-gc-avt-mpeg4visual-00.txt, 318 March 1 2000, expires Sept 1 2000 320 [10] R. Finlayson, "A More Loss-Tolerant RTP Payload Format for MP3 321 Audio", IETF Draft, draft-ietf-avt-rtp-mp3-01.txt, Mar 10 2000, 322 expires Sep 10 2000 324 Authors' Contact Information 325 David Singer 326 Email: singer@apple.com 327 Tel: +1 408 974 3162 329 Apple Computer, Inc. 330 One Infinite Loop, MS:302-3MT 331 Cupertino CA 95014 332 USA 333 Peter Westerink 334 Email: peterw@us.ibm.com 335 Tel: +1 914 784 7173 337 IBM 338 30 Saw Mill River Road 339 Hawthorne, NY 10532 340 USA