draft-ietf-avt-mpeg4-simple-07.txt   draft-ietf-avt-mpeg4-simple-08.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Draft Philips Electronics Internet Draft Philips Electronics
D. Mackie D. Mackie
Apple Computer Apple Computer
V. Swaminathan V. Swaminathan
Sun Microsystems Inc. Sun Microsystems Inc.
D. Singer D. Singer
Apple Computer Apple Computer
P. Gentric P. Gentric
Philips Electronics Philips Electronics
February 2003 August 2003
Expires August 2003 Expires February 2004
Document: draft-ietf-avt-mpeg4-simple-07.txt Document: draft-ietf-avt-mpeg4-simple-08.txt
RTP Payload Format for Transport of MPEG-4 Elementary Streams RTP Payload Format for Transport of MPEG-4 Elementary Streams
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC 2026. all provisions of section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 9 skipping to change at page 2, line 9
ISO that produced the MPEG-4 standard. MPEG defines tools to ISO that produced the MPEG-4 standard. MPEG defines tools to
compress content such as audio-visual information into elementary compress content such as audio-visual information into elementary
streams. This specification defines a simple, but generic RTP streams. This specification defines a simple, but generic RTP
payload format for transport of any non-multiplexed MPEG-4 payload format for transport of any non-multiplexed MPEG-4
elementary stream. elementary stream.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Carriage of MPEG-4 elementary streams over RTP . . . . . . . 6 2. Carriage of MPEG-4 elementary streams over RTP . . . . . . . 6
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Signaling by MIME format parameters . . . . . . . . . . . 6
2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . . 6 2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . . 6
2.3. Concatenation of Access Units . . . . . . . . . . . . . . 6 2.3. Concatenation of Access Units . . . . . . . . . . . . . . 6
2.4. Fragmentation of Access Units . . . . . . . . . . . . . . 7 2.4. Fragmentation of Access Units . . . . . . . . . . . . . . 7
2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . . 7
2.6. Time stamp information . . . . . . . . . . . . . . . . . . 8 2.6. Time stamp information . . . . . . . . . . . . . . . . . . 8
2.7. State indication of MPEG-4 system streams . . . . . . . . 8 2.7. State indication of MPEG-4 system streams . . . . . . . . 8
2.8. Random Access Indication . . . . . . . . . . . . . . . . . 8 2.8. Random Access Indication . . . . . . . . . . . . . . . . . 8
2.9. Carriage of auxiliary information . . . . . . . . . . . . 9 2.9. Carriage of auxiliary information . . . . . . . . . . . . 9
2.10. MIME format parameters and configuring conditional field . 9 2.10. MIME format parameters and configuring conditional field . 9
2.11. Global structure of payload format . . . . . . . . . . . . 9 2.11. Global structure of payload format . . . . . . . . . . . . 9
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4. IANA considerations . . . . . . . . . . . . . . . . . . . . 27 4. IANA considerations . . . . . . . . . . . . . . . . . . . . 27
4.1. MIME type registration . . . . . . . . . . . . . . . . . . 27 4.1. MIME type registration . . . . . . . . . . . . . . . . . . 27
4.2. Registration of mode definitions with IANA . . . . . . . . 32 4.2. Registration of mode definitions with IANA . . . . . . . . 32
4.3. Concatenation of parameters . . . . . . . . . . . . . . . 32 4.3. Concatenation of parameters . . . . . . . . . . . . . . . 32
4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 33 4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1. The a=fmtp keyword . . . . . . . . . . . . . . . . . . . 33 4.4.1. The a=fmtp keyword . . . . . . . . . . . . . . . . . . . 33
5. Security considerations . . . . . . . . . . . . . . . . . . 33 5. Security considerations . . . . . . . . . . . . . . . . . . 33
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1 Normative references . . . . . . . . . . . . . . . . . . . . 34 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 34
7.2 Informative references . . . . . . . . . . . . . . . . . . . 34 7.2 Informative references . . . . . . . . . . . . . . . . . . . 35
8. Author addresses . . . . . . . . . . . . . . . . . . . . . . 35 8. Author addresses . . . . . . . . . . . . . . . . . . . . . . 35
APPENDIX: Usage of this payload format . . . . . . . . . . . 37 APPENDIX: Usage of this payload format . . . . . . . . . . . 37
A. Examples of delay analysis with interleave . . . . . . . 37 A. Examples of delay analysis with interleave . . . . . . . 37
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 37 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 37
A.2 De-interleaving and error concealment . . . . . . . . . 37 A.2 De-interleaving and error concealment . . . . . . . . . 37
A.3 Simple Group interleave . . . . . . . . . . . . . . . . 37 A.3 Simple Group interleave . . . . . . . . . . . . . . . . 37
A.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 37 A.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 37
A.3.2 Determining the de-interleave buffer size . . . . . . 38 A.3.2 Determining the de-interleave buffer size . . . . . . 38
A.3.3 Determining the maximum displacement . . . . . . . . . 38 A.3.3 Determining the maximum displacement . . . . . . . . . 38
A.4 More subtle group interleave . . . . . . . . . . . . . . 38 A.4 More subtle group interleave . . . . . . . . . . . . . . 38
skipping to change at page 6, line 7 skipping to change at page 6, line 7
discretion of the application. However, to anticipate the need for discretion of the application. However, to anticipate the need for
transport of any additional system-related information in future, transport of any additional system-related information in future,
an auxiliary field can be configured that may carry any such data. an auxiliary field can be configured that may carry any such data.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [4]. this document are to be interpreted as described in RFC 2119 [4].
2. Carriage of MPEG-4 elementary streams over RTP 2. Carriage of MPEG-4 elementary streams over RTP
2.1 Introduction 2.1 Signaling by MIME format parameters
With this payload format a single MPEG-4 elementary stream can be With this payload format a single MPEG-4 elementary stream can be
transported. Information on the type of MPEG-4 stream carried in transported. Information on the type of MPEG-4 stream carried in
the payload is conveyed by MIME format parameters, for example in the payload is conveyed by MIME format parameters, for example in
an SDP [5] message or by other means (see section 4). These MIME an SDP [5] message or by other means (see section 4). These MIME
format parameters specify the configuration of the payload. To format parameters specify the configuration of the payload. To
allow for simplified and dedicated receivers, a MIME format allow for simplified and dedicated receivers, a MIME format
parameter is available to signal a specific mode of using this parameter is available to signal a specific mode of using this
payload. A mode definition MAY include the type of MPEG-4 payload. A mode definition MAY include the type of MPEG-4
elementary stream as well as the applied configuration, so as to elementary stream as well as the applied configuration, so as to
skipping to change at page 7, line 20 skipping to change at page 7, line 20
that when multiple AUs are carried in an RTP packet, each AU MUST that when multiple AUs are carried in an RTP packet, each AU MUST
be complete, i.e. the number of AUs in an RTP packet MUST be be complete, i.e. the number of AUs in an RTP packet MUST be
integral. In addition, an AU MUST NOT be repeated in other RTP integral. In addition, an AU MUST NOT be repeated in other RTP
packets; hence repetition of an AU is only possible by using a packets; hence repetition of an AU is only possible by using a
duplicate RTP packet. duplicate RTP packet.
2.4 Fragmentation of Access Units 2.4 Fragmentation of Access Units
MPEG allows for very large Access Units. Since most IP networks MPEG allows for very large Access Units. Since most IP networks
have significantly smaller MTU sizes, this payload format allows have significantly smaller MTU sizes, this payload format allows
for the fragmentation of an Access Unit over multiple RTP packets for the fragmentation of an Access Unit over multiple RTP packets.
so as to avoid IP layer fragmentation. To simplify the Hence when an IP packet is lost after IP-level fragmentation, only an
AU fragment may get lost instead of the entire AU. To simplify the
implementation of RTP receivers, an RTP packet SHALL either carry implementation of RTP receivers, an RTP packet SHALL either carry
one or more complete Access Units or a single fragment of one one or more complete Access Units or a single fragment of one AU,
Access Unit (i.e. packets MUST NOT contain fragments of multiple i.e. packets MUST NOT contain fragments of multiple Access Units.
Access Units).
2.5 Interleaving 2.5 Interleaving
When an RTP packet carries a contiguous sequence of Access Units, When an RTP packet carries a contiguous sequence of Access Units,
the loss of such a packet can result in a "decoding gap" for the the loss of such a packet can result in a "decoding gap" for the
user. One method to alleviate this problem is to allow for the user. One method to alleviate this problem is to allow for the
Access Units to be interleaved in the RTP packets. For a modest Access Units to be interleaved in the RTP packets. For a modest
cost in latency and implementation complexity, significant error cost in latency and implementation complexity, significant error
resiliency to packet loss can be achieved. resiliency to packet loss can be achieved.
skipping to change at page 33, line 39 skipping to change at page 33, line 39
of-service threat. of-service threat.
However, it is possible to inject non-compliant MPEG streams (Audio, However, it is possible to inject non-compliant MPEG streams (Audio,
Video, and Systems) to overload the receiver/decoder's buffers, Video, and Systems) to overload the receiver/decoder's buffers,
which might compromise the functionality of the receiver or even which might compromise the functionality of the receiver or even
crash it. This is especially true for end-to-end systems like MPEG crash it. This is especially true for end-to-end systems like MPEG
where the buffer models are precisely defined. where the buffer models are precisely defined.
MPEG-4 Systems supports stream types including commands that are MPEG-4 Systems supports stream types including commands that are
executed on the terminal like OD commands, BIFS commands, etc. and executed on the terminal like OD commands, BIFS commands, etc. and
programmatic content like MPEG-J (Java(TM) Byte Code) and programmatic content like MPEG-J (Java(TM) Byte Code) and MPEG-4
ECMAScript. It is possible to use one or more of the above in a scripts. It is possible to use one or more of the above in a
manner non-compliant to MPEG to crash the receiver or make it manner non-compliant to MPEG to crash the receiver or make it
temporarily unavailable. Senders that transport MPEG-4 content temporarily unavailable. Senders that transport MPEG-4 content
SHOULD ensure that such content is MPEG compliant, as defined in the SHOULD ensure that such content is MPEG compliant, as defined in the
compliance part of IEC/ISO 14496 [1]. Receivers that support MPEG-4 compliance part of IEC/ISO 14496 [1]. Receivers that support MPEG-4
content should prevent malfunctioning of the receiver in case of content should prevent malfunctioning of the receiver in case of
non MPEG compliant content. non MPEG compliant content.
Authentication mechanisms can be used to validate the sender and Authentication mechanisms can be used to validate the sender and
the data to prevent security problems due to non-compliant malignant the data to prevent security problems due to non-compliant malignant
MPEG-4 streams. MPEG-4 streams.
skipping to change at page 34, line 11 skipping to change at page 34, line 10
streams carrying MPEG-J access units which comprise Java(TM) classes streams carrying MPEG-J access units which comprise Java(TM) classes
and objects. MPEG-J defines a set of Java APIs and a secure and objects. MPEG-J defines a set of Java APIs and a secure
execution model. MPEG-J content can call this set of APIs and execution model. MPEG-J content can call this set of APIs and
Java(TM) methods from a set of Java packages supported in the Java(TM) methods from a set of Java packages supported in the
receiver within the defined security model. According to this receiver within the defined security model. According to this
security model, downloaded byte code is forbidden to load libraries, security model, downloaded byte code is forbidden to load libraries,
define native methods, start programs, read or write files, or read define native methods, start programs, read or write files, or read
system properties. system properties.
Receivers can implement intelligent filters to validate the buffer Receivers can implement intelligent filters to validate the buffer
requirements or parametric (OD, BIFS, etc.) or programmatic (MPEG-J, requirements or parametric (OD, BIFS, etc.) or programmatic (MPEG-J,
ECMAScript) commands in the streams. However, this can increase the MPEG-4 scripts) commands in the streams. However, this can increase
complexity significantly. the complexity significantly.
Implementors of MPEG-4 streaming over RTP who also implement MPEG-4
scripts (subset of ECMAScript) MUST ensure that the action of such
scripts is limited solely to the domain of the single presentation
in which they reside (thus disallowing session to session
communication, access to local resources and storage, etc). Though
loading static network-located resources (such as media) into the
presentation should be permitted, network access by scripts MUST be
restricted to such (media) download.
6. Acknowledgements 6. Acknowledgements
This document evolved through several revisions thanks to This document evolved through several revisions thanks to
contributions by people from the ISMA forum, from the IETF AVT contributions by people from the ISMA forum, from the IETF AVT
Working Group and from the 4-on-IP ad-hoc group within MPEG. The Working Group and from the 4-on-IP ad-hoc group within MPEG. The
authors wish to thank all involved people, and in particular Andrea authors wish to thank all involved people, and in particular Andrea
Basso, Stephen Casner, M. Reha Civanlar, Carsten Herpel, John Basso, Stephen Casner, M. Reha Civanlar, Carsten Herpel, John
Lazaro, Zvi Lifshitz, Young-kwon Lim, Alex MacAulay, Bill May, Lazaro, Zvi Lifshitz, Young-kwon Lim, Alex MacAulay, Bill May,
Colin Perkins, Dorairaj V and Stephan Wenger for their valuable Colin Perkins, Dorairaj V and Stephan Wenger for their valuable
skipping to change at page 35, line 49 skipping to change at page 36, line 4
Sun Microsystems Inc. Sun Microsystems Inc.
901 San Antonio Road, M/S UMPK15-214 901 San Antonio Road, M/S UMPK15-214
Palo Alto, CA 94303 Palo Alto, CA 94303
Email: viswanathan.swaminathan@sun.com Email: viswanathan.swaminathan@sun.com
David Singer David Singer
Apple Computer, Inc. Apple Computer, Inc.
One Infinite Loop, MS:302-3MT One Infinite Loop, MS:302-3MT
Cupertino CA 95014 Cupertino CA 95014
Email: singer@apple.com Email: singer@apple.com
Philippe Gentric Philippe Gentric
Philips Electronics, MP4Net Philips Electronics, MP4Net
51 rue Carnot 51 rue Carnot
92156 Suresnes 92156 Suresnes
France France
e-mail: philippe.gentric@philips.com e-mail: philippe.gentric@philips.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (February 2003). All Rights Copyright (C) The Internet Society (August 2003). All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/