idnits 2.17.1 draft-singer-mpeg4-ip-02.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 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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. ** There are 44 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 104: '...f common characteristics that all MUST...' RFC 2119 keyword, line 119: '...ase of MPEG-4 Systems, MUST be used as...' RFC 2119 keyword, line 123: '...arried, all senders and receivers MUST...' RFC 2119 keyword, line 129: '... 2.5] Streams SHOULD be synchronize...' RFC 2119 keyword, line 147: '...r MPEG-4 content MUST specify the mapp...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 184 has weird spacing: '...tion in ticks...' == Line 532 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 518, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 521, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 524, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 528, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 552, 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 (-04) exists of draft-ietf-avt-mpeg4streams-00 -- Possible downref: Normative reference to a draft: ref. '7' -- 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-03 == Outdated reference: A later version (-02) exists of draft-ietf-avt-rtp-mpeg2aac-00 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio-Video Transport WG & Others 2 INTERNET-DRAFT D. Singer, Y Lim 3 draft-singer-mpeg4-ip-02 Apple Computer, mp4cast 4 Nov 16 2000 5 Expires: May 16 2001 6 MPEG Document number: N3718 8 A Framework for the delivery of MPEG-4 over IP-based Protocols 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 To learn the current status of any Internet-Draft, please check the 32 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Distribution of this document is unlimited. 39 Abstract 41 This document forms an umbrella specification for the carriage and 42 operation of MPEG-4 multimedia sessions over IP-based protocols, 43 including RTP, RTSP, and HTTP, among others. It addresses IP 44 Multicast as well. 46 It also serves to document the standard MIME types associated with 47 MPEG-4 files. 49 1 Introduction 51 MPEG-4 is a standard designed for the representation and delivery of 52 multimedia information over a variety of transport protocols. It 53 includes interactive scene management, visual and audio 54 representations as well as systems functionality like multiplexing, 55 synchronization, and an object descriptor framework. 57 This document provides a number of specifications for the detailed 58 mapping of MPEG-4 into several IP-based protocols, as well as 59 references to other specifications. 61 Open issues: it might be desirable to signal to the terminal the 62 amount of buffering assumed by the encoding/transmission process (in 63 addition to any network jitter). 65 Editor's note: the sections that apply to FlexMux have not yet been 66 harmonized with the proposed FlexMux format. Some of the information 67 related to FlexMux (e.g. MIME names, FlexMux structures) should 68 probably be in that draft and removed from here. 70 Glossary of terms and acronyms 72 AAC - MPEG-4 advanced audio codec 73 AU - access unit in an ES (the smallest media data unit to which 74 timing can be attributed). 75 BIFS - binary format for scenes; the MPEG-4 scene composition system 76 CELP - MPEG-4 speech codec 77 CTS - composition time stamp 78 DTS - decoding time stamp 79 ES - elementary stream 80 ESID - elementary stream ID 81 FCR - flexmux clock reference 82 FlexMux - a multiplex of several PDUs into a single unit; not used 83 for multiplexing in RTP 84 IOD - initial object descriptor; the 'hook' to the MPEG-4 streams 85 needed to start a session 86 OCR - object clock reference; an external clock reference for an 87 MEG-4 stream 88 OD - object descriptor; declares and defines an MPEG-4 stream 89 SL - synchronization layer 90 SL Packet - synchronization layer protocol data unit, in MPEG-4 91 systems 93 2 Use of RTP 95 There are a number of Internet Drafts describing RTP packetization 96 schemes for MPEG-4 data [5] [6] [7] [8] [9]. This draft does not 97 specify any new one. Media-aware packetization (e.g. video frames 98 split at recoverable sub-frame boundaries) is a principle in RTP, and 99 thus it is likely that several RTP schemes will be needed, to suit 100 both the different kinds of media - audio, video, etc. - and 101 different encodings (e.g. AAC and CELP audio codecs) [11]. 103 This specification requires that, no matter what packetization scheme 104 is used, there are a number of common characteristics that all MUST 105 have: however, such characteristics depend on the fact that the RTP 106 Session contains a single elementary stream or a flexmux stream. 108 In case an RTP Session contains a single elementary stream the 109 following characteristics apply: 111 2.1] The RTP timestamp corresponds to the presentation time (e.g. 112 CTS) of the earliest AU within the packet. 114 2.2] RTP packets have sequence numbers in transmission order. The 115 payloads logically or physically have SL Sequence numbers, which are 116 in decoding order, for each elementary stream. 118 2.3] The MPEG-4 timescale (clock ticks per second), which is 119 timeStampResolution in the case of MPEG-4 Systems, MUST be used as 120 the RTP timescale, e.g. as declared in SDP for an RTP stream. 122 2.4] To achieve a base level of interoperability, and to ensure that 123 any MPEG-4 stream may be carried, all senders and receivers MUST 124 implement a default RTP payload mapping scheme. It is highly 125 desirable that this default scheme is common for both pure Audio and 126 Visual streams as well as for SL Packetized streams. This default 127 scheme is not yet identified. 129 2.5] Streams SHOULD be synchronized using RTP techniques (notable 130 RTCP sender reports). When the MPEG-4 OCR is used, it is logically 131 mapped to the NTP time axis used in RTCP. 133 2.6] The RTP packetization schemes may be used for MPEG-4 elementary 134 streams 'standing alone' (e.g. without MPEG-4 systems, including 135 BIFS); or they may be used within an overall presentation using the 136 object descriptor framework. In the latter case, an 137 SLConfigDescriptor is sent describing the stream. Logically, each 138 RTP stream is passed through a mapping function which is specific to 139 the payload format used; this mapping function yields an SL 140 packetized stream. The SLConfigDescriptor describes this logical 141 stream, not the actual bits in the RTP payload. For example, the RTP 142 sequence number may be used to make the SLPacketHeader sequence 143 number; other SL fields may be set in this way, dynamically, or from 144 static values in the payload specification. For example, as all RTP 145 packets carry a composition time-stamp, the flag in the SL header 146 indicating its presence can normally be statically defined as 'true'. 147 Each payload format for MPEG-4 content MUST specify the mapping 148 function for the formation of the SLConfigDescriptor and the 149 SLPacketHeader. 151 In the case of the draft by Kikuchi-san et al., the mapping will be 152 defined in a new section. 154 +----------------+ +---------------+ +---------+ 155 | RTP Packet | | Normative | | | 156 | | -----> | mapping | ----->| | 157 |(visual, audio) | | function | | | 158 +----------------+ +---------------+ | | 159 | | 160 +----------------+ +---------------+ | | 161 | RTP Packet | | Normative | | MPEG-4 | 162 | | -----> | mapping | ----->| | 163 |(generic format)| | function | | SL | 164 +----------------+ +---------------+ | | 165 . . | packets | 166 . . | | 167 . . | | 168 +----------------+ +---------------+ | | 169 | RTP Packet | | Normative | | | 170 | | -----> | mapping | ----->| | 171 |(FlexMux format)| | function | | | 172 +----------------+ +---------------+ +---------+ 174 In case an RTP Session contains a flexmultiplexed stream the 175 following characteristics apply: 177 2.6] There is a single payload format for the carriage of Flexmux 178 Streams over RTP [5]. Senders and receivers MAY implement this 179 scheme. 181 2.7] The RTP timestamp corresponds to the FCR if present at the 182 Flexmux level. 184 2.8] The MPEG-4 Flexmux timescale (FCR resolution in ticks per 185 second) SHOULD be used as the RTP timescale (as can be declared in 186 SDP). 188 2.9] the MPEG-4 FCR is logically mapped to the NTP time axis used in 189 RTCP. 191 Other payload formats MAY be used. They are signalled as dynamic 192 payload IDs, defined by a suitable name (e.g. a payload name in an 193 SDP RTPMAP attribute). In particular, the development of specialized 194 RTP payloads for video (e.g. respecting video packets) and audio 195 (e.g. providing interleave) is expected. It is possible that these 196 schemes can be compatible with the default scheme required here. 198 There may be a choice of RTP payload formats for a given stream (e.g. 199 as an elementary stream, an SL-packetized stream, using FlexMux, and 200 so on). It is recommended that 201 * terminals implementing a given sub-system (e.g. video) accept at 202 least an ES and the default SL packings [8] of that stream, if 203 they exist; for example, this means accepting the draft by 204 Kikuchi et al. and also the SL draft by Civanlar et al. for 205 MPEG-4 video; 206 * terminals implementing a given payload format accept any stream 207 over that format for which they have a decoder, even if that 208 packing is not normally the 'best' packing. 210 Future versions of this specification will identify the single 211 standard RTP packing format for each MPEG-4 stream type. However, at 212 the time of writing the RTP payload format specifications are still 213 being defined, and the set is incomplete. These recommendations will 214 form the basis for improved interoperability. 216 For those streams requiring a certain Quality of Service (specifiable 217 appropriately) , the recommendation is to further investigate 218 possible solutions such as the leverage of existing work in the IETF 219 in this area (including, but not limited to FEC, re-transmission, or 220 repetition). However, techniques in data-dependent error correction, 221 or combined source/channel coding solutions make other schemes 222 attractive [7]. Also, it is recommended that requirement such as 223 efficient grouping mechanisms (i.e. the ability to send in a single 224 RTP packet multiple consecutive Aus, each with its own SL 225 information) and low overhead are also taken into account. 227 3 SDP Information 229 This specification considers only MPEG-4 Systems related issues. The 230 usage of elementary streams in other contexts is not addressed here: 231 codepoints for this case are specified in [6], and in other places. 233 This specification currently assumes that any session described by 234 SDP (e.g. in SAP, as a file download, as a DESCRIBE over RTSP) has at 235 most one MPEG-4 session. It is desirable that this restriction be 236 lifted. 238 3.1] Senders SHOULD alert receivers that an MPEG-4 session is 239 included, by means of an SDP attribute that is general (i.e. before 240 any "media" lines). This takes the form of an attribute line: 242 a=mpeg4-iod [] 244 location: In an RTSP session, this is an optional attribute. If not 245 supplied, the IOD is retrieved over the RTSP session by using 246 DESCRIBE with an accept of type application/mpeg4-iod. Where the SDP 247 information is supplied by some other means (e.g. as a file, in SAP), 248 the location is obligatory. The location should be a URL enclosed in 249 double-quotes, which will supply the IOD (e.g. small ones may be 250 encoded using "data:", otherwise "http:" or other suitable file- 251 access URL). The InitialObjectDescriptor is defined in sub-clause 252 8.6.3.1 of ISO/IEC 14496-1. 254 3.3] New encoding names for the a = rtpmap attribute It is 255 recommended that, no matter what payload format is used, each media 256 stream be placed in a media section that is appropriate. For 257 example, a payload format which can carry both video and audio 258 streams may be used in sections of SDP starting both with "m=video" 259 and "m=audio". The MIME name for the payload format is thus 260 registered under all applicable branches. 262 a = rtpmap: /