idnits 2.17.1 draft-singer-mpeg4-ip-04.txt: -(188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(192): 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? ** 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. == There are 2 instances of lines with non-ascii characters in the document. 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 307 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** 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 92: '...f common characteristics that all MUST...' RFC 2119 keyword, line 107: '...case of ISO/IEC 14496 Systems, MUST be...' RFC 2119 keyword, line 112: '... MUST implement a defa...' RFC 2119 keyword, line 117: '... 2.5] Streams SHOULD be synchronize...' RFC 2119 keyword, line 135: '...ISO/IEC 14496 content MUST specify the...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 171 has weird spacing: '...tion in ticks...' == Line 504 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 (July 2002) is 7949 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 504 looks like a reference -- Missing reference section? '6' on line 508 looks like a reference -- Missing reference section? '9' on line 519 looks like a reference -- Missing reference section? '8' on line 515 looks like a reference -- Missing reference section? '1' on line 492 looks like a reference -- Missing reference section? '2' on line 495 looks like a reference -- Missing reference section? '3' on line 498 looks like a reference -- Missing reference section? '4' on line 501 looks like a reference -- Missing reference section? '7' on line 511 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 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, net&tv 4 Document: draft-singer-mpeg4-ip-04 February 2001 5 Category: Expires July 2002 6 MPEG reference: N4427 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 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. 33 Abstract 35 This document forms an umbrella specification for the carriage and 36 operation of MPEG-4 multimedia sessions over IP-based protocols, 37 including RTP, RTSP, and HTTP, among others. It addresses IP 38 Multicast as well. 40 It also serves to document the standard MIME types associated with 41 MPEG-4 files. 43 1 Introduction 45 ISO/IEC 14496 is a standard designed for the representation and 46 delivery of multimedia information over a variety of transport 47 protocols. It includes interactive scene management, visual and 48 audio representations as well as systems functionality like 49 multiplexing, synchronization, and an object descriptor framework. 51 This document provides a framework for the carriage of ISO/IEC14496 52 contents over IP networks and guidelines for designing payload format 53 specifications for the detailed mapping of ISO/IEC 14496 content into 54 several IP-based protocols 56 Glossary of terms and acronyms 58 AAC - MPEG-4 advanced audio codec 59 AU - access unit in an ES (the smallest media data unit to which 60 timing can be attributed). 61 BIFS - binary format for scenes; the MPEG-4 scene composition system 62 CELP - MPEG-4 speech codec 63 CTS - composition time stamp 64 DTS - decoding time stamp 65 ES - elementary stream 66 ESID - elementary stream ID 67 FCR - flexmux clock reference 68 FlexMux - a multiplex of several PDUs into a single unit; not used 69 for multiplexing in RTP 70 IOD - initial object descriptor; the 'hook' to the MPEG-4 streams 71 needed to start a session 72 OCR - object clock reference; an external clock reference for an 73 MEG-4 stream 74 OD - object descriptor; declares and defines an MPEG-4 stream 75 SL - synchronization layer 76 SL Packet - synchronization layer protocol data unit, in MPEG-4 77 systems 79 2 Use of RTP 81 There are a number of RTP packetization schemes for ISO/IEC 14496 82 data[5] [6] [9]. Media-aware packetization (e.g. video frames split 83 at recoverable sub-frame boundaries) is a principle in RTP, and thus 84 it is likely that several RTP schemes will be needed, to suit both 85 the different kinds of media - audio, video, etc. - and different 86 encodings (e.g. AAC and CELP audio codecs) [8].This specification 87 does not specify any payload format but do specify a general 88 framework to design and utilize the payload formats in appropriate 89 way. 91 This specification requires that, no matter what packetization scheme 92 is used, there are a number of common characteristics that all MUST 93 have: however, such characteristics depend on the fact that the RTP 94 Session contains a single elementary stream or a flexmux stream. 96 In case an RTP Session contains a single elementary stream the 97 following characteristics apply: 99 2.1] The RTP timestamp corresponds to the presentation time (e.g. 100 CTS) of the earliest AU within the packet. 102 2.2] RTP packets have sequence numbers in transmission order. The 103 payloads logically or physically have SL Sequence numbers, which are 104 in decoding order, for each elementary stream. 106 2.3] The ISO/IEC 14496 timescale (clock ticks per second), which is 107 timeStampResolution in the case of ISO/IEC 14496 Systems, MUST be 108 used as the RTP timescale, e.g. as declared in SDP for an RTP stream. 110 2.4] To achieve a base level of interoperability, and to ensure that 111 any ISO/IEC 14496 stream may be carried, all senders and receivers 112 MUST implement a default RTP payload mapping scheme. It is highly 113 desirable that this default scheme is common for both pure Audio and 114 Visual streams as well as for SL Packetized streams. This default 115 scheme is not yet identified. 117 2.5] Streams SHOULD be synchronized using RTP techniques (notable 118 RTCP sender reports). When the ISO/IEC 14496 OCR is used, it is 119 logically mapped to the NTP time axis used in RTCP. 121 2.6] The RTP packetization schemes may be used for ISO/IEC 14496 122 elementary streams 'standing alone' (e.g. without ISO/IEC 14496 123 systems, including BIFS); or they may be used within an overall 124 presentation using the object descriptor framework. In the latter 125 case, an SLConfigDescriptor is sent describing the stream. Logically, 126 each RTP stream is passed through a mapping function which is 127 specific to the payload format used; this mapping function yields an 128 SL packetized stream. The SLConfigDescriptor describes this logical 129 stream, not the actual bits in the RTP payload. For example, the RTP 130 sequence number may be used to make the SLPacketHeader sequence 131 number; other SL fields may be set in this way, dynamically, or from 132 static values in the payload specification. For example, as all RTP 133 packets carry a composition time-stamp, the flag in the SL header 134 indicating its presence can normally be statically defined as 'true'. 135 Each payload format for ISO/IEC 14496 content MUST specify the 136 mapping function for the formation of the SLConfigDescriptor and the 137 SLPacketHeader. 139 In the case of RFC 3016, the mapping will be defined in a new section. 141 +----------------+ +---------------+ +---------+ 142 | RTP Packet | | Normative | | | 143 | | -----> | mapping | ----->| | 144 |(visual, audio) | | function | | | 145 +----------------+ +---------------+ | | 146 | ISO/IEC | 147 +----------------+ +---------------+ | | 148 | RTP Packet | | Normative | | 14496 | 149 | | -----> | mapping | ----->| | 150 |(generic format)| | function | | SL | 151 +----------------+ +---------------+ | | 152 . . | packets | 153 . . | | 154 . . | | 155 +----------------+ +---------------+ | | 156 | RTP Packet | | Normative | | | 157 | | -----> | mapping | ----->| | 158 |(FlexMux format)| | function | | | 159 +----------------+ +---------------+ +---------+ 161 In case an RTP Session contains a flexmultiplexed stream the 162 following characteristics apply: 164 2.7] There is a single payload format for the carriage of Flexmux 165 Streams over RTP [5]. Senders and receivers MAY implement this 166 scheme. 168 2.8] The RTP timestamp corresponds to the FCR if present at the 169 Flexmux level. 171 2.9] The ISO/IEC 14496 Flexmux timescale (FCR resolution in ticks 172 per second) SHOULD be used as the RTP timescale (as can be declared 173 in SDP). 175 2.10] the ISO/IEC 14496 FCR is logically mapped to the NTP time axis 176 used in RTCP. 178 Other payload formats MAY be used. They are signalled as dynamic 179 payload IDs, defined by a suitable name (e.g. a payload name in an 180 SDP RTPMAP attribute). In particular, the development of specialized 181 RTP payloads for video (e.g. respecting video packets) and audio (e.g. 182 providing interleave) is expected. It is possible that these schemes 183 can be compatible with the default scheme required here. 185 There may be a choice of RTP payload formats for a given stream (e.g. 186 as an elementary stream, an SL-packetized stream, using FlexMux, and 187 so on). It is recommended that 188 � terminals implementing a given sub-system (e.g. video) accept at 189 least an ES and the default SL packings of that stream; for example, 190 this means accepting the draft by RFC 3016. and also the generic 191 payload format for ISO/IEC 14496 Visual; 192 � terminals implementing a given payload format accept any stream 193 over that format for which they have a decoder, even if that packing 194 is not normally the 'best' packing. 196 Future versions of this specification will identify the single 197 standard RTP packing format for each ISO/IEC 14496 stream type. 198 However, at the time of writing the RTP payload format specifications 199 are still being defined, and the set is incomplete. These 200 recommendations will form the basis for improved interoperability. 202 For those streams requiring a certain Quality of Service (specifiable 203 appropriately) , the recommendation is to further investigate 204 possible solutions such as the leverage of existing work in the IETF 205 in this area (including, but not limited to FEC, re-transmission, or 206 repetition). However, techniques in data-dependent error correction, 207 or combined source/channel coding solutions make other schemes 208 attractive. Also, it is recommended that requirement such as 209 efficient grouping mechanisms (i.e. the ability to send in a single 210 RTP packet multiple consecutive Aus, each with its own SL 211 information) and low overhead are also taken into account. 213 3 SDP Information 215 This specification considers only ISO/IEC 14496 Systems related 216 issues. Usage of SDP information for specific payload format shall be 217 specified in each RTP payload format RFCs. The usage of elementary 218 streams in other contexts is not addressed here: codepoints for this 219 case are specified in [6], and in other places. 221 This specification currently assumes that any session described by 222 SDP (e.g. in SAP, as a file download, as a DESCRIBE over RTSP) has at 223 most one ISO/IEC 14496 session. It is desirable that this 224 restriction be lifted. 226 3.1] Senders SHOULD alert receivers that an ISO/IEC 14496 session is 227 included, by means of an SDP attribute that is general (i.e. before 228 any "media" lines). This takes the form of an attribute line: 230 a=mpeg4-iod:[] 232 location: In an RTSP session, this is an optional attribute. If not 233 supplied, the IOD is retrieved over the RTSP session by using 234 DESCRIBE with an accept of type application/mpeg4-iod. Where the SDP 235 information is supplied by some other means (e.g. as a file, in SAP), 236 the location is obligatory. The location should be a URL enclosed in 237 double-quotes, which will supply the IOD (e.g. small ones may be 238 encoded using "data:", otherwise "http:" or other suitable file- 239 access URL). The InitialObjectDescriptor is defined in sub-clause 240 8.6.3.1 of ISO/IEC 14496-1. 242 or: 244 a=mpeg4-iod-xmt:[] 246 location: In an RTSP session, this is an optional attribute. If not 247 supplied, the IOD is retrieved over the RTSP session by using 248 DESCRIBE with an accept of type application/mpeg4-iod-xmt. Where the 249 SDP information is supplied by some other means (e.g. as a file, in 250 SAP), the location is obligatory. The location shall be a URL 251 enclosed in double-quotes, which will supply the IOD in XMT format 252 (e.g. small ones may be encoded using "data:", otherwise "http:" or 253 other suitable file-access URL). The InitialObjectDescriptor is 254 defined in sub-clause 8.6.3.1 of ISO/IEC 14496-1, and its XMT format 255 is defined in ISO/IEC 14496-1 2001 PDAM 2. 257 Any receivers using IOD shall understand binary IOD and may 258 understand textual IOD. 260 3.2] New encoding names for the a = rtpmap attribute It is 261 recommended that, no matter what payload format is used, each media 262 stream be placed in a media section that is appropriate. For example, 263 a payload format which can carry both video and audio streams may be 264 used in sections of SDP starting both with "m=video" and "m=audio". 265 The MIME name for the payload format is thus registered under all 266 applicable branches. 268 a = rtpmap: /