idnits 2.17.1 draft-singer-mpeg4-ip-01.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 12 longer pages, the longest (page 1) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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 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 105: '...f common characteristics that all MUST...' RFC 2119 keyword, line 120: '...ase of MPEG-4 Systems, MUST be used as...' RFC 2119 keyword, line 124: '...arried, all senders and receivers MUST...' RFC 2119 keyword, line 130: '... 2.5] Streams SHOULD be synchronize...' RFC 2119 keyword, line 148: '...r MPEG-4 content MUST specify the mapp...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 165 has weird spacing: '...tion in ticks...' == Line 474 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 460, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 463, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 466, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 470, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 494, 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: 8 errors (**), 0 flaws (~~), 17 warnings (==), 8 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, Y Lim 4 draft-singer-mpeg4-ip-01 Apple Computer, mp4cast 5 October 23 2000 6 Expires: April 23, 2001 7 MPEG Document number: N3718 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. It addresses IP 45 Multicast as well. 47 It also serves to document the standard MIME types associated with 48 MPEG-4 files. 50 1 Introduction 52 MPEG-4 is a standard designed for the representation and delivery of 53 multimedia information over a variety of transport protocols. It 54 includes interactive scene management, visual and audio 55 representations as well as systems functionality like multiplexing, 56 synchronization, and an object descriptor framework. 58 This document provides a number of specifications for the detailed 59 mapping of MPEG-4 into several IP-based protocols, as well as 60 references to other specifications. 62 Open issues: it might be desirable to signal to the terminal the 63 amount of buffering assumed by the encoding/transmission process (in 64 addition to any network jitter). 66 Editor's note: the sections that apply to FlexMux have not yet been 67 harmonized with the proposed FlexMux format. Some of the information 68 related to FlexMux (e.g. MIME names, FlexMux structures) should 69 probably be in that draft and removed from here. 71 Glossary of terms and acronyms 73 AAC - MPEG-4 advanced audio codec 74 AU - access unit in an ES (the smallest media data unit to which 75 timing can be attributed). 76 BIFS - binary format for scenes; the MPEG-4 scene composition system 77 CELP - MPEG-4 speech codec 78 CTS - composition time stamp 79 DTS - decoding time stamp 80 ES - elementary stream 81 ESID - elementary stream ID 82 FCR - flexmux clock reference 83 FlexMux - a multiplex of several PDUs into a single unit; not used 84 for multiplexing in RTP 85 IOD - initial object descriptor; the 'hook' to the MPEG-4 streams 86 needed to start a session 87 OCR - object clock reference; an external clock reference for an 88 MEG-4 stream 89 OD - object descriptor; declares and defines an MPEG-4 stream 90 SL - synchronization layer 91 SL Packet - synchronization layer protocol data unit, in MPEG-4 92 systems 94 2 Use of RTP 96 There are a number of Internet Drafts describing RTP packetization 97 schemes for MPEG-4 data [5] [6] [7] [8] [9]. This draft does not 98 specify any new one. Media-aware packetization (e.g. video frames 99 split at recoverable sub-frame boundaries) is a principle in RTP, and 100 thus it is likely that several RTP schemes will be needed, to suit 101 both the different kinds of media - audio, video, etc. - and 102 different encodings (e.g. AAC and CELP audio codecs) [11]. 104 This specification requires that, no matter what packetization scheme 105 is used, there are a number of common characteristics that all MUST 106 have: however, such characteristics depend on the fact that the RTP 107 Session contains a single elementary stream or a flexmux stream. 109 In case an RTP Session contains a single elementary stream the 110 following characteristics apply: 112 2.1] The RTP timestamp corresponds to the presentation time (e.g. 113 CTS) of the earliest AU within the packet. 115 2.2] RTP packets have sequence numbers in transmission order. The 116 payloads logically or physically have SL Sequence numbers, which are 117 in decoding order, for each elementary stream. 119 2.3] The MPEG-4 timescale (clock ticks per second), which is 120 timeStampResolution in the case of MPEG-4 Systems, MUST be used as 121 the RTP timescale, e.g. as declared in SDP for an RTP stream. 123 2.4] To achieve a base level of interoperability, and to ensure that 124 any MPEG-4 stream may be carried, all senders and receivers MUST 125 implement a default RTP payload mapping scheme. It is highly 126 desirable that this default scheme is common for both pure Audio and 127 Visual streams as well as for SL Packetized streams. This default 128 scheme is not yet identified. 130 2.5] Streams SHOULD be synchronized using RTP techniques (notable 131 RTCP sender reports). When the MPEG-4 OCR is used, it is logically 132 mapped to the NTP time axis used in RTCP. 134 2.6] The RTP packetization schemes may be used for MPEG-4 elementary 135 streams 'standing alone' (e.g. without MPEG-4 systems, including 136 BIFS); or they may be used within an overall presentation using the 137 object descriptor framework. In the latter case, an 138 SLConfigDescriptor is sent describing the stream. Logically, each 139 RTP stream is passed through a mapping function which is specific to 140 the payload format used; this mapping function yields an SL 141 packetized stream. The SLConfigDescriptor describes this logical 142 stream, not the actual bits in the RTP payload. For example, the RTP 143 sequence number may be used to make the SLPacketHeader sequence 144 number; other SL fields may be set in this way, dynamically, or from 145 static values in the payload specification. For example, as all RTP 146 packets carry a composition time-stamp, the flag in the SL header 147 indicating its presence can normally be statically defined as 'true'. 148 Each payload format for MPEG-4 content MUST specify the mapping 149 function for the formation of the SLConfigDescriptor and the 150 SLPacketHeader. 152 In the case of the draft by Kikuchi-san et al., the mapping will be 153 defined in a new section. 155 In case an RTP Session contains a flexmultiplexed stream the 156 following characteristics apply: 158 2.6] There is a single payload format for the carriage of Flexmux 159 Streams over RTP [5]. Senders and receivers MAY implement this 160 scheme. 162 2.7] The RTP timestamp corresponds to the FCR if present at the 163 Flexmux level. 165 2.8] The MPEG-4 Flexmux timescale (FCR resolution in ticks per 166 second) SHOULD be used as the RTP timescale (as can be declared in 167 SDP). 169 2.9] the MPEG-4 FCR is logically mapped to the NTP time axis used in 170 RTCP. 172 Other payload formats MAY be used. They are signalled as dynamic 173 payload IDs, defined by a suitable name (e.g. a payload name in an 174 SDP RTPMAP attribute). In particular, the development of specialized 175 RTP payloads for video (e.g. respecting video packets) and audio 176 (e.g. providing interleave) is expected. It is possible that these 177 schemes can be compatible with the default scheme required here. 179 There may be a choice of RTP payload formats for a given stream (e.g. 180 as an elementary stream, an SL-packetized stream, using FlexMux, and 181 so on). It is recommended that 182 * terminals implementing a given sub-system (e.g. video) accept at 183 least an ES and the default SL packings [8] of that stream, if 184 they exist; for example, this means accepting the draft by 185 Kikuchi et al. and also the SL draft by Civanlar et al. for 186 MPEG-4 video; 187 * terminals implementing a given payload format accept any stream 188 over that format for which they have a decoder, even if that 189 packing is not normally the 'best' packing. 191 Future versions of this specification will identify the single 192 standard RTP packing format for each MPEG-4 stream type. However, at 193 the time of writing the RTP payload format specifications are still 194 being defined, and the set is incomplete. These recommendations will 195 form the basis for improved interoperability. 197 For those streams requiring a certain Quality of Service (specifiable 198 appropriately) , the recommendation is to further investigate 199 possible solutions such as the leverage of existing work in the IETF 200 in this area (including, but not limited to FEC, re-transmission, or 201 repetition). However, techniques in data-dependent error correction, 202 or combined source/channel coding solutions make other schemes 203 attractive [7]. Also, it is recommended that requirement such as 204 efficient grouping mechanisms (i.e. the ability to send in a single 205 RTP packet multiple consecutive Aus, each with its own SL 206 information) and low overhead are also taken into account. 208 3 SDP Information 210 This specification considers only MPEG-4 Systems related issues. The 211 usage of elementary streams in other contexts is not addressed here: 212 codepoints for this case are specified in [6], and in other places. 214 This specification currently assumes that any session described by 215 SDP (e.g. in SAP, as a file download, as a DESCRIBE over RTSP) has at 216 most one MPEG-4 session. It is desirable that this restriction be 217 lifted. 219 3.1] Senders SHOULD alert receivers that an MPEG-4 session is 220 included, by means of an SDP attribute that is general (i.e. before 221 any "media" lines). This takes the form of an attribute line: 223 a=mpeg4-iod [] 225 location: In an RTSP session, this is an optional attribute. If not 226 supplied, the IOD is retrieved over the RTSP session by using 227 DESCRIBE with an accept of type application/mpeg4-iod. Where the SDP 228 information is supplied by some other means (e.g. as a file, in SAP), 229 the location is obligatory. The location should be a URL enclosed in 230 double-quotes, which will supply the IOD (e.g. small ones may be 231 encoded using "data:", otherwise "http:" or other suitable file- 232 access URL). The InitialObjectDescriptor is defined in sub-clause 233 8.6.3.1 of ISO/IEC 14496-1. 235 3.3] New encoding names for the a = rtpmap attribute It is 236 recommended that, no matter what payload format is used, each media 237 stream be placed in a media section that is appropriate. For 238 example, a payload format which can carry both video and audio 239 streams may be used in sections of SDP starting both with "m=video" 240 and "m=audio". The MIME name for the payload format is thus 241 registered under all applicable branches. 243 a = rtpmap: /