idnits 2.17.1 draft-singer-mpeg4-ip-03.txt: -(101): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(150): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(203): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(309): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(412): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(465): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(514): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(568): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? == There are 10 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 66 lines 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7 Security Considerations' ) ** 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.) ** There are 314 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 99: '...f common characteristics that all MUST...' RFC 2119 keyword, line 116: '...case of ISO/IEC 14496 Systems, MUST be...' RFC 2119 keyword, line 121: '... MUST implement a defa...' RFC 2119 keyword, line 126: '... 2.5] Streams SHOULD be synchronize...' RFC 2119 keyword, line 144: '...ISO/IEC 14496 content MUST specify the...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 181 has weird spacing: '...tion in ticks...' == Line 529 has weird spacing: '...D.Curet et al...' == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- The document date (January 2002) is 8137 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) -- Missing reference section? '5' on line 529 looks like a reference -- Missing reference section? '6' on line 533 looks like a reference -- Missing reference section? '9' on line 544 looks like a reference -- Missing reference section? '8' on line 540 looks like a reference -- Missing reference section? '1' on line 517 looks like a reference -- Missing reference section? '2' on line 520 looks like a reference -- Missing reference section? '3' on line 523 looks like a reference -- Missing reference section? '4' on line 526 looks like a reference -- Missing reference section? '7' on line 536 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio-Video Transport WG D. Singer, Y Lim 3 Internet Draft Apple Computer, mp4cast 4 Document: draft-singer-mpeg4-ip-03 July 2001 5 Category: Expires January 2002 6 MPEG reference: N4282 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/1id-abstracts.html 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 Singer & Lim Informational - Expires Jan 2002 1 50 1 Introduction 52 ISO/IEC 14496 is a standard designed for the representation and 53 delivery of multimedia information over a variety of transport 54 protocols. It includes interactive scene management, visual and 55 audio representations as well as systems functionality like 56 multiplexing, synchronization, and an object descriptor framework. 58 This document provides a framework for the carriage of ISO/IEC14496 59 contents over IP networks and guidelines for designing payload format 60 specifications for the detailed mapping of ISO/IEC 14496 content into 61 several IP-based protocols 63 Glossary of terms and acronyms 65 AAC - MPEG-4 advanced audio codec 66 AU - access unit in an ES (the smallest media data unit to which 67 timing can be attributed). 68 BIFS - binary format for scenes; the MPEG-4 scene composition system 69 CELP - MPEG-4 speech codec 70 CTS - composition time stamp 71 DTS - decoding time stamp 72 ES - elementary stream 73 ESID - elementary stream ID 74 FCR - flexmux clock reference 75 FlexMux - a multiplex of several PDUs into a single unit; not used 76 for multiplexing in RTP 77 IOD - initial object descriptor; the 'hook' to the MPEG-4 streams 78 needed to start a session 79 OCR - object clock reference; an external clock reference for an 80 MEG-4 stream 81 OD - object descriptor; declares and defines an MPEG-4 stream 82 SL - synchronization layer 83 SL Packet - synchronization layer protocol data unit, in MPEG-4 84 systems 86 2 Use of RTP 88 There are a number of RTP packetization schemes for ISO/IEC 14496 89 data[5] [6] [9]. Media-aware packetization (e.g. video frames split 90 at recoverable sub-frame boundaries) is a principle in RTP, and thus 91 it is likely that several RTP schemes will be needed, to suit both 92 the different kinds of media - audio, video, etc. - and different 93 encodings (e.g. AAC and CELP audio codecs) [8].This specification 94 does not specify any payload format but do specify a general 95 framework to design and utilize the payload formats in appropriate 96 way. 98 This specification requires that, no matter what packetization scheme 99 is used, there are a number of common characteristics that all MUST 101 Singer & Lim Informational � Expires Jan. 2002 2 102 have: however, such characteristics depend on the fact that the RTP 103 Session contains a single elementary stream or a flexmux stream. 105 In case an RTP Session contains a single elementary stream the 106 following characteristics apply: 108 2.1] The RTP timestamp corresponds to the presentation time (e.g. 109 CTS) of the earliest AU within the packet. 111 2.2] RTP packets have sequence numbers in transmission order. The 112 payloads logically or physically have SL Sequence numbers, which are 113 in decoding order, for each elementary stream. 115 2.3] The ISO/IEC 14496 timescale (clock ticks per second), which is 116 timeStampResolution in the case of ISO/IEC 14496 Systems, MUST be 117 used as the RTP timescale, e.g. as declared in SDP for an RTP stream. 119 2.4] To achieve a base level of interoperability, and to ensure that 120 any ISO/IEC 14496 stream may be carried, all senders and receivers 121 MUST implement a default RTP payload mapping scheme. It is highly 122 desirable that this default scheme is common for both pure Audio and 123 Visual streams as well as for SL Packetized streams. This default 124 scheme is not yet identified. 126 2.5] Streams SHOULD be synchronized using RTP techniques (notable 127 RTCP sender reports). When the ISO/IEC 14496 OCR is used, it is 128 logically mapped to the NTP time axis used in RTCP. 130 2.6] The RTP packetization schemes may be used for ISO/IEC 14496 131 elementary streams 'standing alone' (e.g. without ISO/IEC 14496 132 systems, including BIFS); or they may be used within an overall 133 presentation using the object descriptor framework. In the latter 134 case, an SLConfigDescriptor is sent describing the stream. Logically, 135 each RTP stream is passed through a mapping function which is 136 specific to the payload format used; this mapping function yields an 137 SL packetized stream. The SLConfigDescriptor describes this logical 138 stream, not the actual bits in the RTP payload. For example, the RTP 139 sequence number may be used to make the SLPacketHeader sequence 140 number; other SL fields may be set in this way, dynamically, or from 141 static values in the payload specification. For example, as all RTP 142 packets carry a composition time-stamp, the flag in the SL header 143 indicating its presence can normally be statically defined as 'true'. 144 Each payload format for ISO/IEC 14496 content MUST specify the 145 mapping function for the formation of the SLConfigDescriptor and the 146 SLPacketHeader. 148 In the case of RFC 3016, the mapping will be defined in a new section. 150 Singer & Lim Informational � Expires Jan. 2002 3 151 +----------------+ +---------------+ +---------+ 152 | RTP Packet | | Normative | | | 153 | | -----> | mapping | ----->| | 154 |(visual, audio) | | function | | | 155 +----------------+ +---------------+ | | 156 | ISO/IEC | 157 +----------------+ +---------------+ | | 158 | RTP Packet | | Normative | | 14496 | 159 | | -----> | mapping | ----->| | 160 |(generic format)| | function | | SL | 161 +----------------+ +---------------+ | | 162 . . | packets | 163 . . | | 164 . . | | 165 +----------------+ +---------------+ | | 166 | RTP Packet | | Normative | | | 167 | | -----> | mapping | ----->| | 168 |(FlexMux format)| | function | | | 169 +----------------+ +---------------+ +---------+ 171 In case an RTP Session contains a flexmultiplexed stream the 172 following characteristics apply: 174 2.6] There is a single payload format for the carriage of Flexmux 175 Streams over RTP [5]. Senders and receivers MAY implement this 176 scheme. 178 2.7] The RTP timestamp corresponds to the FCR if present at the 179 Flexmux level. 181 2.8] The ISO/IEC 14496 Flexmux timescale (FCR resolution in ticks 182 per second) SHOULD be used as the RTP timescale (as can be declared 183 in SDP). 185 2.9] the ISO/IEC 14496 FCR is logically mapped to the NTP time axis 186 used in RTCP. 188 Other payload formats MAY be used. They are signalled as dynamic 189 payload IDs, defined by a suitable name (e.g. a payload name in an 190 SDP RTPMAP attribute). In particular, the development of specialized 191 RTP payloads for video (e.g. respecting video packets) and audio (e.g. 192 providing interleave) is expected. It is possible that these schemes 193 can be compatible with the default scheme required here. 195 There may be a choice of RTP payload formats for a given stream (e.g. 196 as an elementary stream, an SL-packetized stream, using FlexMux, and 197 so on). It is recommended that 198 * terminals implementing a given sub-system (e.g. video) accept at 199 least an ES and the default SL packings of that stream; for example, 200 this means accepting the draft by RFC 3016. and also the generic 201 payload format for ISO/IEC 14496 Visual; 203 Singer & Lim Informational � Expires Jan. 2002 4 204 * terminals implementing a given payload format accept any stream 205 over that format for which they have a decoder, even if that packing 206 is not normally the 'best' packing. 208 Future versions of this specification will identify the single 209 standard RTP packing format for each ISO/IEC 14496 stream type. 210 However, at the time of writing the RTP payload format specifications 211 are still being defined, and the set is incomplete. These 212 recommendations will form the basis for improved interoperability. 214 For those streams requiring a certain Quality of Service (specifiable 215 appropriately) , the recommendation is to further investigate 216 possible solutions such as the leverage of existing work in the IETF 217 in this area (including, but not limited to FEC, re-transmission, or 218 repetition). However, techniques in data-dependent error correction, 219 or combined source/channel coding solutions make other schemes 220 attractive. Also, it is recommended that requirement such as 221 efficient grouping mechanisms (i.e. the ability to send in a single 222 RTP packet multiple consecutive Aus, each with its own SL 223 information) and low overhead are also taken into account. 225 3 SDP Information 227 This specification considers only ISO/IEC 14496 Systems related 228 issues. Usage of SDP information for specific payload format shall be 229 specified in each RTP payload format RFCs. The usage of elementary 230 streams in other contexts is not addressed here: codepoints for this 231 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 ISO/IEC 14496 session. It is desirable that this 236 restriction be lifted. 238 3.1] Senders SHOULD alert receivers that an ISO/IEC 14496 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 Singer & Lim Informational � Expires Jan. 2002 5 255 or: 257 a=mpeg4-iod-xmt [] 259 location: In an RTSP session, this is an optional attribute. If not 260 supplied, the IOD is retrieved over the RTSP session by using 261 DESCRIBE with an accept of type application/mpeg4-iod-xmt. Where the 262 SDP information is supplied by some other means (e.g. as a file, in 263 SAP), the location is obligatory. The location shall be a URL 264 enclosed in double-quotes, which will supply the IOD in XMT format 265 (e.g. small ones may be encoded using "data:", otherwise "http:" or 266 other suitable file-access URL). The InitialObjectDescriptor is 267 defined in sub-clause 8.6.3.1 of ISO/IEC 14496-1, and its XMT format 268 is defined in ISO/IEC 14496-1 2001 PDAM 2. 270 Any receivers using IOD shall understand binary IOD and may 271 understand textual IOD. 273 3.2] New encoding names for the a = rtpmap attribute It is 274 recommended that, no matter what payload format is used, each media 275 stream be placed in a media section that is appropriate. For example, 276 a payload format which can carry both video and audio streams may be 277 used in sections of SDP starting both with "m=video" and "m=audio". 278 The MIME name for the payload format is thus registered under all 279 applicable branches. 281 a = rtpmap: /