draft-ietf-avt-mpeg4-simple-02.txt   draft-ietf-avt-mpeg4-simple-03.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
Cisco Systems Inc. Cisco Systems Inc.
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
April 2002 June 2002
Expires October 2002 Expires December 2002
Document: draft-ietf-avt-mpeg4-simple-02.txt Document: draft-ietf-avt-mpeg4-simple-03.txt
Transport of MPEG-4 Elementary Streams 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 RFC2026. all provisions of Section 10 of RFC2026.
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 7 skipping to change at page 2, line 7
The MPEG Committee (ISO/IEC JTC1/SC29 WG11) is a working group in The MPEG Committee (ISO/IEC JTC1/SC29 WG11) is a working group in
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Carriage of MPEG-4 elementary streams over RTP . . . . . . . . 4 2. Carriage of MPEG-4 elementary streams over RTP . . . . . . . 4
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . . . 4 2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . . 4
2.3. Concatenation of Access Units . . . . . . . . . . . . . . . 4 2.3. Concatenation of Access Units . . . . . . . . . . . . . . 4
2.4. Fragmentation of Access Units . . . . . . . . . . . . . . . 5 2.4. Fragmentation of Access Units . . . . . . . . . . . . . . 5
2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. Time stamp information . . . . . . . . . . . . . . . . . . . 6 2.6. Time stamp information . . . . . . . . . . . . . . . . . . 6
2.7. Carriage of auxiliary information . . . . . . . . . . . . . 6 2.7. Random Access Indication . . . . . . . . . . . . . . . . . 6
2.8. MIME format parameters and configuring conditional field . . 6 2.8. State indication of MPEG-4 system streams . . . . . . . . 6
2.9. Global structure of payload format . . . . . . . . . . . . . 7 2.9. Carriage of auxiliary information . . . . . . . . . . . . 7
2.10. Modes to transport MPEG-4 streams . . . . . . . . . . . . . 7 2.10. MIME format parameters and configuring conditional field . 7
2.11. Alignment with RFC 3016 . . . . . . . . . . . . . . . . . . 8 2.11. Global structure of payload format . . . . . . . . . . . . 7
3. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8 2.12. Modes to transport MPEG-4 streams . . . . . . . . . . . . 8
3.1. RTP header field usage . . . . . . . . . . . . . . . . . . . 8 2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . . 8
3.2. RTP payload structure . . . . . . . . . . . . . . . . . . . 10 3. Payload format . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. The AU Header Section . . . . . . . . . . . . . . . . . . 10 3.1. Usage of RTP header fields and RTCP . . . . . . . . . . . 9
3.2.1.1. The AU-header . . . . . . . . . . . . . . . . . . . . . 10 3.2. RTP payload structure . . . . . . . . . . . . . . . . . . 10
3.2.2. The Auxiliary Section . . . . . . . . . . . . . . . . . . 12 3.2.1. The AU Header Section . . . . . . . . . . . . . . . . . 10
3.2.3. The Access Unit Data Section . . . . . . . . . . . . . . . 13 3.2.1.1. The AU-header . . . . . . . . . . . . . . . . . . . . 10
3.2.3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. The Auxiliary Section . . . . . . . . . . . . . . . . . 13
3.2.3.2. Interleaving . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3. The Access Unit Data Section . . . . . . . . . . . . . . 13
3.2.3.3. Constraints for interleaving . . . . . . . . . . . . . . 15 3.2.3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 14
3.3. Usage of this specification . . . . . . . . . . . . . . . . 15 3.2.3.2. Interleaving . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.3.3. Constraints for interleaving . . . . . . . . . . . . . 15
3.3.2. The generic mode . . . . . . . . . . . . . . . . . . . . . 16 3.3. Usage of this specification . . . . . . . . . . . . . . . 16
3.3.3. Constant bit rate CELP . . . . . . . . . . . . . . . . . . 16 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.4. Variable bit rate CELP . . . . . . . . . . . . . . . . . . 17 3.3.2. The generic mode . . . . . . . . . . . . . . . . . . . . 16
3.3.5. Low bit rate AAC . . . . . . . . . . . . . . . . . . . . . 18 3.3.3. Constant bit rate CELP . . . . . . . . . . . . . . . . . 17
3.3.6. High bit rate AAC . . . . . . . . . . . . . . . . . . . . 18 3.3.4. Variable bit rate CELP . . . . . . . . . . . . . . . . . 18
3.3.7. Additional modes . . . . . . . . . . . . . . . . . . . . . 19 3.3.5. Low bit rate AAC . . . . . . . . . . . . . . . . . . . . 19
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 3.3.6. High bit rate AAC . . . . . . . . . . . . . . . . . . . 19
4.1. MIME type registration . . . . . . . . . . . . . . . . . . . 20 3.3.7. Additional modes . . . . . . . . . . . . . . . . . . . . 20
4.2. Concatenation of parameters . . . . . . . . . . . . . . . . 24 4. IANA considerations . . . . . . . . . . . . . . . . . . . . 21
4.3. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. MIME type registration . . . . . . . . . . . . . . . . . . 21
4.3.1. The a=fmtp keyword . . . . . . . . . . . . . . . . . . . . 24 4.2. Concatenation of parameters . . . . . . . . . . . . . . . 26
5. Security considerations . . . . . . . . . . . . . . . . . . . 25 4.3. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 26
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. The a=fmtp keyword . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Security considerations . . . . . . . . . . . . . . . . . . 27
8. Author addresses . . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
APPENDIX: Usage of this payload format . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.1. Examples of delay analysis with interleave . . . . . . . 27 8. Author addresses . . . . . . . . . . . . . . . . . . . . . . 29
A.1.1 Group interleave . . . . . . . . . . . . . . . . . . . . 27 APPENDIX: Usage of this payload format . . . . . . . . . . . 30
A.1.2 Continuous interleave . . . . . . . . . . . . . . . . . 28 A. Examples of delay analysis with interleave . . . . . . . 30
A.1 Group interleave . . . . . . . . . . . . . . . . . . . . 30
A.2 Continuous interleave . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29 The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29
that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4 that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4
standards [1]. The MPEG-4 standard specifies compression of standards [1]. The MPEG-4 standard specifies compression of
audio-visual data into for example an audio or video elementary audio-visual data into for example an audio or video elementary
stream. In the MPEG-4 standard, these streams take the form of stream. In the MPEG-4 standard, these streams take the form of
audiovisual objects that may be arranged into an audio-visual scene audiovisual objects that may be arranged into an audio-visual scene
by means of a scene description. Each MPEG-4 elementary stream by means of a scene description. Each MPEG-4 elementary stream
consists of a sequence of Access Units; examples of an Access Unit consists of a sequence of Access Units; examples of an Access Unit
(AU) are an audio frame and a video picture. (AU) are an audio frame and a video picture.
The MPEG-4 system specification is a rather abstract specification
in the sense that no transport format for MPEG-4 elementary streams
is defined. Instead, a conceptual synchronization layer (SL) has
been specified to store transport specific information such as time
stamps and random access point information. When transporting an
MPEG-4 elementary stream, transport information from the SL is
typically mapped to the actual transport layer. Note that the SL is
conceptual and may not exist in practice.
This specification defines a general and configurable payload This specification defines a general and configurable payload
structure to transport MPEG-4 elementary streams such as audio, structure to transport MPEG-4 elementary streams, in particular
speech, video and BIFS streams. The RTP payload defined in this MPEG-4 audio (including speech) streams, MPEG-4 video streams and
document is simple to implement and reasonably efficient. It allows also MPEG-4 systems streams, such as BIFS (BInary Format for
for optional interleaving of Access Units (such as audio frames) to Scenes), OCI (Object Content Information), OD (Object Descriptor)
increase error resiliency in packet loss. and IPMP (Intellectual Property Management and Protection) streams.
The RTP payload defined in this document is simple to implement and
reasonably efficient. It allows for optional interleaving of Access
Units (such as audio frames) to increase error resiliency in packet
loss.
Though the RTP payload format defined in this document is capable
to transport any MPEG-4 stream, more dedicated formats may exist,
such as RFC 3016 for transport of MPEG-4 video (part 2).
Configuration of the payload is provided to accommodate transport Configuration of the payload is provided to accommodate transport
of any MPEG-4 stream at any possible bit rate. However, for a of any MPEG-4 stream at any possible bit rate. However, for a
specific MPEG-4 elementary stream typically only very few specific MPEG-4 elementary stream typically only very few
configurations are needed. So as to allow for the design of configurations are needed. So as to allow for the design of
simplified, but dedicated receivers, this specification requires simplified, but dedicated receivers, this specification requires
that specific modes are defined for transport of MPEG-4 streams. that specific modes are defined for transport of MPEG-4 streams.
This document defines modes for MPEG-4 CELP and AAC streams, as This document defines modes for MPEG-4 CELP and AAC streams, as
well as a generic mode that can be used to transport any MPEG-4 well as a generic mode that can be used to transport any MPEG-4
stream. In the future new RFCs are expected to specify additional stream. In the future new RFCs are expected to specify additional
skipping to change at page 6, line 37 skipping to change at page 6, line 37
picture in the past, or a reference picture in the future. The DTS picture in the past, or a reference picture in the future. The DTS
cannot be carried in the RTP header. In some cases the DTS can be cannot be carried in the RTP header. In some cases the DTS can be
derived from the RTP time stamp using frame rate information; this derived from the RTP time stamp using frame rate information; this
requires deep parsing in the video stream, which may be considered requires deep parsing in the video stream, which may be considered
objectionable. But if the video frame rate is variable, the required objectionable. But if the video frame rate is variable, the required
information may not even be present in the video stream. For both information may not even be present in the video stream. For both
reasons, the capability has been defined to optionally carry the reasons, the capability has been defined to optionally carry the
DTS in the RTP payload for each contained Access Unit. DTS in the RTP payload for each contained Access Unit.
Since RTP time stamps may be re-stamped by RTP devices, each time Since RTP time stamps may be re-stamped by RTP devices, each time
stamp contained in the RTP payload is coded differentially from the stamp contained in the RTP payload is coded differentially, the CTS
RTP time stamp, so as to avoid extensive parsing by re-stamping from the RTP time stamp, and the DTS from the CTS, so as to avoid
devices. extensive parsing by re-stamping devices.
2.7 Carriage of auxiliary information. 2.7 Random access indication
Random access to the content of MPEG-4 elementary streams may be
possible at some but not all Access Units. To signal Access Units
where random access is possible, a random access point flag can
optionally be carried in the RTP payload for each contained Access
Unit.
2.8 State indication of MPEG-4 system streams
ISO/IEC 14496-1 defines states for MPEG-4 system streams. So as to
convey state information when transporting MPEG-4 system streams,
this payload format allows for the optional carriage in the RTP
payload of the stream state for each contained Access Unit. The
indication of stream states is particularly useful when repeating
AUs according to the carousel mechanism defined in ISO/IEC 14496-1.
2.9 Carriage of auxiliary information.
This payload format defines a specific field to carry auxiliary This payload format defines a specific field to carry auxiliary
data. The auxiliary data field is preceded by a field that specifies data. The auxiliary data field is preceded by a field that specifies
the length of the auxiliary data, so as to facilitate skipping of the length of the auxiliary data, so as to facilitate skipping of
the data without parsing it. The coding of the auxiliary data is not the data without parsing it. The coding of the auxiliary data is not
defined in this document, but is left to the discretion of defined in this document, but is left to the discretion of
applications. Receivers that have knowledge of the auxiliary data applications. Receivers that have knowledge of the auxiliary data
MAY decode the auxiliary data, but receivers without knowledge of MAY decode the auxiliary data, but receivers without knowledge of
such data MUST skip the auxiliary data field. such data MUST skip the auxiliary data field.
2.8 MIME format parameters and configuring conditional fields 2.10 MIME format parameters and configuring conditional fields
To support the features described in the previous sections several To support the features described in the previous sections several
fields are defined for carriage in the RTP payload. However, their fields are defined for carriage in the RTP payload. However, their
use strongly depends on the type of MPEG-4 elementary stream that use strongly depends on the type of MPEG-4 elementary stream that
is carried. Sometimes a specific field is needed with a certain is carried. Sometimes a specific field is needed with a certain
length, while in other cases such field is not needed at all. To be length, while in other cases such field is not needed at all. To be
efficient in either case, the fields to support these features are efficient in either case, the fields to support these features are
configurable by means of MIME format parameters. In general, a MIME configurable by means of MIME format parameters. In general, a MIME
format parameter defines the presence and length of the associated format parameter defines the presence and length of the associated
field. A length of zero indicates absence of the field. As a field. A length of zero indicates absence of the field. As a
consequence, parsing of the payload requires knowledge of MIME consequence, parsing of the payload requires knowledge of MIME
format parameters. The MIME format parameters are conveyed to the format parameters. The MIME format parameters are conveyed to the
receiver via SDP [6] messages or through other means. receiver via SDP [6] messages or through other means.
2.9 Global structure of payload format 2.11 Global structure of payload format
The RTP payload following the RTP header, contains three byte The RTP payload following the RTP header, contains three byte
aligned data sections, of which the first two MAY be empty. See aligned data sections, of which the first two MAY be empty. See
figure 1. figure 1.
+---------+-----------+-----------+---------------+ +---------+-----------+-----------+---------------+
| RTP | AU Header | Auxiliary | Access Unit | | RTP | AU Header | Auxiliary | Access Unit |
| Header | Section | Section | Data Section | | Header | Section | Section | Data Section |
+---------+-----------+-----------+---------------+ +---------+-----------+-----------+---------------+
skipping to change at page 7, line 38 skipping to change at page 8, line 5
The first data section is the AU (Access Unit) Header Section, that The first data section is the AU (Access Unit) Header Section, that
contains one or more AU-headers; however, each AU-header MAY be contains one or more AU-headers; however, each AU-header MAY be
empty, in which case the entire AU Header Section is empty. The empty, in which case the entire AU Header Section is empty. The
second section is the Auxiliary Section, containing auxiliary data; second section is the Auxiliary Section, containing auxiliary data;
this section MAY also be configured empty. The third section is the this section MAY also be configured empty. The third section is the
Access Unit Data Section, containing either a single fragment of Access Unit Data Section, containing either a single fragment of
one Access Unit or one or more complete Access Units. The Access one Access Unit or one or more complete Access Units. The Access
Unit Data Section is never empty. Unit Data Section is never empty.
2.10 Modes to transport MPEG-4 streams 2.12 Modes to transport MPEG-4 streams
While it is possible to build fully configurable receivers capable While it is possible to build fully configurable receivers capable
of receiving any MPEG-4 stream, this specification also allows for of receiving any MPEG-4 stream, this specification also allows for
the design of simplified, but dedicated receivers, that are capable the design of simplified, but dedicated receivers, that are capable
for example of receiving only one type of MPEG-4 stream. This for example of receiving only one type of MPEG-4 stream. This
is achieved by requiring that specific modes be defined for using is achieved by requiring that specific modes be defined for using
this specification. Each mode may define constraints for transport this specification. Each mode may define constraints for transport
of one or more type of MPEG-4 streams, for instance on the payload of one or more type of MPEG-4 streams, for instance on the payload
configuration. configuration.
skipping to change at page 8, line 13 skipping to change at page 8, line 31
capabilities of the receiver. capabilities of the receiver.
In this document several modes are defined for transport of MPEG-4 In this document several modes are defined for transport of MPEG-4
CELP and AAC streams, as well as a generic mode that can be used CELP and AAC streams, as well as a generic mode that can be used
for any MPEG-4 stream. In future, new RFCs are expected to specify for any MPEG-4 stream. In future, new RFCs are expected to specify
additional modes of using this specification. New modes can be additional modes of using this specification. New modes can be
defined as deemed appropriate, typically by specifications that are defined as deemed appropriate, typically by specifications that are
hierarchically higher than this payload format. However, each mode hierarchically higher than this payload format. However, each mode
MUST be in full compliance with this specification. MUST be in full compliance with this specification.
2.11 Alignment with RFC 3016 2.13 Alignment with RFC 3016
This payload can be configured to be nearly identical to the This payload can be configured to be nearly identical to the
payload format defined in RFC 3016 [5] for the MPEG-4 video payload format defined in RFC 3016 [5] for the MPEG-4 video
configurations recommended in RFC 3016. Hence, receivers that configurations recommended in RFC 3016. Hence, receivers that
comply with RFC 3016 can decode such RTP payload, providing that comply with RFC 3016 can decode such RTP payload, providing that
additional packets containing video decoder configuration (VO, additional packets containing video decoder configuration (VO,
VOL, VOSH) are inserted in the stream, as required by RFC 3016. VOL, VOSH) are inserted in the stream, as required by RFC 3016.
Conversely, receivers that comply with the specification in this Conversely, receivers that comply with the specification in this
document SHOULD be able to decode payloads, names and parameters document SHOULD be able to decode payloads, names and parameters
defined for MPEG-4 video in RFC 3016. In this respect it is defined for MPEG-4 video in RFC 3016. In this respect it is
strongly recommended to implement the ability to ignore "in band" strongly recommended to implement the ability to ignore "in band"
video decoder configuration packets in the RFC 3016 payload. video decoder configuration packets in the RFC 3016 payload.
For interoperability reasons, applications that transport MPEG-4 Note the "out of band" availability of the video decoder
video part 2 over RTP SHOULD use the payload format and associated configuration is optional in RFC 3016. To achieve maximum
names and parameters defined in RFC 3016 if the functionality interoperability with the RTP payload format defined in this
provided by RFC 3016 can meet the requirements of that application. document, applications that use RFC 3016 to transport MPEG-4 video
On the other hand, if applications wish to use a single RTP payload (part 2) are recommended to make the video decoder configuration
format for transport of all type of MPEG-4 streams, then the RTP available as a MIME parameter.
payload defined in this document provides a suitable solution, also
for transport of MPEG-4 video part 2 streams.
Note that since the "out of band" availability of the video decoder
configuration as a MIME parameter is optional in RFC 3016, for
obvious interoperability reasons with this specification it is
recommended to systematically implement this optional feature.
3 Payload Format 3. Payload Format
3.1 RTP Header Fields Usage 3.1 Usage of RTP Header Fields and RTCP
Payload Type (PT): The assignment of an RTP payload type for this Payload Type (PT): The assignment of an RTP payload type for this
RTP packet format is outside the scope of this document, and will RTP packet format is outside the scope of this document, and will
not be specified here. It is expected that the RTP profile for a not be specified here. It is expected that the RTP profile for a
particular class of applications will assign a payload type for particular class of applications will assign a payload type for
this encoding, or if that is not done, then a payload type in the this encoding, or if that is not done, then a payload type in the
dynamic range shall be chosen. dynamic range shall be chosen.
Marker (M) bit: The M bit is set to 1 to indicate that the RTP Marker (M) bit: The M bit is set to 1 to indicate that the RTP
packet payload includes the end of each Access Unit of which data packet payload includes the end of each Access Unit of which data
skipping to change at page 10, line 41 skipping to change at page 10, line 41
bit-wise concatenated in the order in which the Access Units are bit-wise concatenated in the order in which the Access Units are
contained in the Access Unit Data Section. Hence, the n-th contained in the Access Unit Data Section. Hence, the n-th
AU-header refers to the n-th AU (fragment). If the concatenated AU-header refers to the n-th AU (fragment). If the concatenated
AU-headers consume a non-integer number of octets, up to 7 AU-headers consume a non-integer number of octets, up to 7
zero-padding bits MUST be inserted at the end in order to achieve zero-padding bits MUST be inserted at the end in order to achieve
byte-alignment of the AU Header Section. byte-alignment of the AU Header Section.
3.2.1.1 The AU-header 3.2.1.1 The AU-header
The AU-header contains the fields given in figure 3. The length in The AU-header contains the fields given in figure 3. The length in
bits of the above fields with the exception of the CTS-flag and bits of the above fields with the exception of the CTS-flag, the
the DTS-flag fields is defined by MIME format parameters; see DTS-flag and the RAP-flag fields is defined by MIME format
section 4.1. If a MIME format parameter has the default value of parameters; see section 4.1. If a MIME format parameter has the
zero, then the associated field is not present. default value of zero, then the associated field is not present.
+---------------------------------------+ +---------------------------------------+
| AU-size | | AU-size |
+---------------------------------------+ +---------------------------------------+
| AU-Index / AU-Index-delta | | AU-Index / AU-Index-delta |
+---------------------------------------+ +---------------------------------------+
| CTS-flag | | CTS-flag |
+---------------------------------------+ +---------------------------------------+
| CTS-delta | | CTS-delta |
+---------------------------------------+ +---------------------------------------+
| DTS-flag | | DTS-flag |
+---------------------------------------+ +---------------------------------------+
| DTS-delta | | DTS-delta |
+---------------------------------------+ +---------------------------------------+
| RAP-flag |
+---------------------------------------+
| Stream-state |
+---------------------------------------+
Figure 3: The fields in the AU-header. If used, the AU-Index field Figure 3: The fields in the AU-header. If used, the AU-Index field
only occurs in the first AU-header within an AU Header only occurs in the first AU-header within an AU Header
Section; in any other AU-header the AU-Index-delta field Section; in any other AU-header the AU-Index-delta field
occurs instead. occurs instead.
AU-size: indicates the size in octets of the associated Access Unit AU-size: Indicates the size in octets of the associated Access Unit
in the Access Unit Data Section in the same RTP packet. When in the Access Unit Data Section in the same RTP packet. When
the AU-size is associated with an AU fragment, the AU size the AU-size is associated with an AU fragment, the AU size
indicates the size of the entire AU and not the size of the indicates the size of the entire AU and not the size of the
fragment. This can be exploited to determine whether a packet fragment. This can be exploited to determine whether a packet
contains an entire AU or a fragment, which is particularly contains an entire AU or a fragment, which is particularly
useful after losing a packet carrying the last fragment of an useful after losing a packet carrying the last fragment of an
AU. AU.
AU-Index: indicates the serial number of the associated Access Unit AU-Index: Indicates the serial number of the associated Access Unit
(fragment). For each (in decoding order) consecutive AU or AU (fragment). For each (in decoding order) consecutive AU or AU
fragment, the serial number is incremented with 1. When fragment, the serial number is incremented with 1. When
present, the AU-Index field occurs in the first AU-header in present, the AU-Index field occurs in the first AU-header in
the AU Header Section, but MUST NOT occur in any subsequent the AU Header Section, but MUST NOT occur in any subsequent
(non-first) AU-header in that Section. To encode the serial (non-first) AU-header in that Section. To encode the serial
number in any such non-first AU-header, the AU-Index-delta number in any such non-first AU-header, the AU-Index-delta
field is used. If each AU-Index field is coded with the value field is used. If each AU-Index field is coded with the value
0, the serial number of the AU (fragment) is not specified, 0, the serial number of the AU (fragment) is not specified,
and in that case receivers MAY ignore the AU-Index field. and in that case receivers MAY ignore the AU-Index field.
skipping to change at page 12, line 28 skipping to change at page 12, line 33
rate as the time stamp in the RTP header. rate as the time stamp in the RTP header.
DTS-flag: Indicates whether the DTS-delta field is present. A value DTS-flag: Indicates whether the DTS-delta field is present. A value
of 1 indicates that DTS-delta is present, a value of 0 that of 1 indicates that DTS-delta is present, a value of 0 that
it is not present. it is not present.
The DTS-flag field MUST be present in each AU-header if the The DTS-flag field MUST be present in each AU-header if the
length of the DTS-delta field is signalled to be larger than length of the DTS-delta field is signalled to be larger than
zero. The DTS-flag field SHOULD be 0 for any non-first zero. The DTS-flag field SHOULD be 0 for any non-first
fragment of an Access Unit. fragment of an Access Unit.
DTS-delta: specifies the value of the DTS as a 2's complement DTS-delta: Specifies the value of the DTS as a 2's complement
offset (delta) from the CTS. The DTS MUST use the offset (delta) from the CTS. The DTS MUST use the
same clock rate as the time stamp in the RTP header. same clock rate as the time stamp in the RTP header.
RAP-flag: Indicates when set to 1 that the associated Access Unit
provides a random access point to the content of the stream.
If an Access Unit is fragmented, the RAP flag, if present,
MUST be set to 0 for each non-first fragment of the AU.
Stream-state: Specifies the state of the stream for the AU of an
MPEG-4 system stream. For states of MPEG-4 system streams see
ISO/IEC 14496-1. The stream state is set either to 0 or to 1.
A change of the stream state value (either from 1 to 0 or from
0 to 1) indicates another state of the stream. At an AU that
provides a random access point, as signalled by the RAP-flag,
a change in the stream state MUST occur, unless the AU is a
repeated random access point. Hence, receivers MAY ignore AUs
with the RAP-flag set to 1 if the stream state does not
change. Receivers that don't ignore a repeated random access
point SHOULD take care that such processing does not disrupt
the decoding process.
Note: no relation is required between stream-states of
different streams.
If present, the fields MUST occur in the mutual order given in If present, the fields MUST occur in the mutual order given in
figure 3. In the general case a receiver can only discover the size figure 3. In the general case a receiver can only discover the size
of an AU-header by parsing it since the presence of the CTS-delta of an AU-header by parsing it since the presence of the CTS-delta
and DTS-delta fields is signalled by the value of the CTS-flag and and DTS-delta fields is signalled by the value of the CTS-flag and
DTS-flag, respectively. DTS-flag, respectively.
3.2.2 The Auxiliary Section 3.2.2 The Auxiliary Section
The Auxiliary Section consists of the auxiliary-data-size field The Auxiliary Section consists of the auxiliary-data-size field
followed by the auxiliary-data field. Receivers MAY (but are not followed by the auxiliary-data field. Receivers MAY (but are not
skipping to change at page 13, line 28 skipping to change at page 14, line 5
Section is never empty. If data of more than one Access Unit is Section is never empty. If data of more than one Access Unit is
present, then the AUs are concatenated into a contiguous string present, then the AUs are concatenated into a contiguous string
of octets. See figure 5. The AUs inside the Access Unit Data of octets. See figure 5. The AUs inside the Access Unit Data
Section MUST be in decoding order. Section MUST be in decoding order.
The size and number of Access Units SHOULD be adjusted such that The size and number of Access Units SHOULD be adjusted such that
the resulting RTP packet is not larger than the path MTU. To handle the resulting RTP packet is not larger than the path MTU. To handle
larger packets, this payload format relies on lower layers for larger packets, this payload format relies on lower layers for
fragmentation, which may not be desirable. fragmentation, which may not be desirable.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU(1) | |AU(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AU(2) | | |AU(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AU(n) | | | AU(n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
|-+-+-+-+-+-+-+-+ |-+-+-+-+-+-+-+-+
Figure 5: Access Unit Data Section; each AU is byte aligned. Figure 5: Access Unit Data Section; each AU is byte aligned.
When multiple Access Units are carried, the size of each AU MUST be When multiple Access Units are carried, the size of each AU MUST be
made available to the receiver. If the AU size is variable then the made available to the receiver. If the AU size is variable then the
size of each AU MUST be indicated in the AU-size field of the size of each AU MUST be indicated in the AU-size field of the
corresponding AU-header. However, if the AU size is constant for a corresponding AU-header. However, if the AU size is constant for a
stream, this mechanism SHOULD NOT be used, but instead the fixed stream, this mechanism SHOULD NOT be used, but instead the fixed
skipping to change at page 15, line 28 skipping to change at page 16, line 5
loss, there are profile-based limits on the size of the packet. loss, there are profile-based limits on the size of the packet.
This is expressed as a duration: it is calculated from the duration This is expressed as a duration: it is calculated from the duration
of the Access Units contained within a packet. Note that this of the Access Units contained within a packet. Note that this
duration is NOT the difference between the time stamps of the first duration is NOT the difference between the time stamps of the first
and last Access Unit in a packet. and last Access Unit in a packet.
No matter what interleaving scheme is used, the scheme must be No matter what interleaving scheme is used, the scheme must be
analyzed to calculate the minimum number of frames a receiver has analyzed to calculate the minimum number of frames a receiver has
to buffer in order to de-interleave. to buffer in order to de-interleave.
Three profiles are defined to constrain the latency when interlea- Three profiles are defined to constrain the latency when
ving. The applied profile is signalled by the MIME format parameter interleaving. The applied profile is signalled by the MIME format
"Profile", indicating the decimal number of the profile. The maximum parameter "Profile", indicating the decimal number of the profile.
de-interleave buffer required at the receiver can be determined if The maximum de-interleave buffer required at the receiver can be
the maximum packet duration is known. The maximum packet duration determined if the maximum packet duration is known. The maximum
in milliseconds for the three profiles, shall not exceed: packet duration in milliseconds for the three profiles, shall not
exceed:
Profile 0 -- 200 milliseconds Profile 0 -- 200 milliseconds
Profile 1 -- 500 milliseconds Profile 1 -- 500 milliseconds
Profile 2 -- 1500 milliseconds Profile 2 -- 1500 milliseconds
When interleaving is applied, the applied RTP transport profile When interleaving is applied, the applied profile MUST be signalled
MUST be signalled by the MIME format parameter "Profile"; see by the MIME format parameter "Profile"; see section 4.1.
section 4.1.
Note that for low bit-rate material, this duration limit may make Note that for low bit-rate material, this duration limit may make
packets shorter than the MTU size. packets shorter than the MTU size.
3.3 Usage of this specification 3.3 Usage of this specification
3.3.1 General 3.3.1 General
Usage of this specification requires definition of a mode. A mode Usage of this specification requires definition of a mode. A mode
defines how to use this specification, as deemed appropriate. defines how to use this specification, as deemed appropriate.
Senders MUST signal the applied mode via the MIME format parameter Senders MUST signal the applied mode via the MIME format parameter
"Mode". This specification defines a generic mode that can be used "Mode". This specification defines a generic mode that can be used
for any MPEG-4 stream, as well as specific modes for transport of for any MPEG-4 stream, as well as specific modes for transport of
MPEG-4 CELP and MPEG-4 AAC streams. MPEG-4 CELP and MPEG-4 AAC streams, defined in ISO/IEC 14496-3.
In any mode compliant to this specification the same requirements In any mode compliant to this specification the same requirements
apply for the rtpmap attributes. The general form of an rtpmap apply for the rtpmap attributes. The general form of an rtpmap
attribute is: attribute is:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>] parameters>]
For audio streams, <encoding parameters> specifies the number of For audio streams, <encoding parameters> specifies the number of
audio channels. This parameter may be omitted if the number of audio channels: 2 for stereo material (see RFC 2327) and 1 for
channels is one, provided no additional parameters are needed. mono. Provided no additional parameters are needed, this parameter
In any mode, the following attributes are REQUIRED: may be omitted for mono material, hence its default value is 1.
a) The encoding name
b) The RTP clock rate MUST be expressed.
c) The number of audio channels MUST be specified, for example as
2 for stereo material (see RFC 2327) and MAY be specified as 1
for mono material; 1 is the default.
3.3.2 The generic mode 3.3.2 The generic mode
The generic mode can be used for any MPEG-4 stream. In this mode The generic mode can be used for any MPEG-4 stream. In this mode
no mode-specific constraints are applied; hence, the generic mode no mode-specific constraints are applied; hence, in the generic
exploits the full flexibility of this specification. The generic mode the full flexibility of this specification can be exploited.
mode is signalled by mode=generic. The generic mode is signalled by mode=generic.
An example is given below for transport of a BIFS stream. In this An example is given below for transport of a BIFS stream. In this
example carriage of multiple BIFS Access Units is allowed in one example carriage of multiple BIFS Access Units is allowed in one
RTP packet. The AU-header section contains the AU-size field, the RTP packet. The AU-header contains the AU-size field, the CTS-flag
CTS-flag and, if the CTS flag is set to 1, the CTS-delta field. and, if the CTS flag is set to 1, the CTS-delta field. The number
The number of bits of the AU-size and the CTS-delta fields is 15 of bits of the AU-size and the CTS-delta fields is 14 and 15,
and 16 respectively, which results in an AU-header of two or four respectively. The AU-header also contains the RAP-flag and the
octets per BIFS AU. The RTP time stamp uses a 1 kHz clock. Stream-state, both of 1 bits. This results in an AU-header with a
Total size of two or four octets per BIFS AU. The RTP time stamp
uses a 1 kHz clock. Note that the media type name is video,
because the BIFS stream is part of an audiovisual presentation. For
conventions on media type names see section 4.1.
In detail: In detail:
m=video 49230 RTP/AVP 96 m=video 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/1000 a=rtpmap:96 mpeg4-generic/1000
a=fmtp:96 streamtype=3; profile-level-id=257; mode=generic; a=fmtp:96 streamtype=3; profile-level-id=257; mode=generic;
ObjectType=2; config=BIFSConfiguration(); SizeLength=15; ObjectType=2; config=BIFSConfiguration(); SizeLength=15;
CTSDeltaLength=16 CTSDeltaLength=16; RandomAccessIndication=1;
StreamStateIndication=1
Note that BIFSConfiguration() is defined in ISO/IEC 14496-1; for
the description of MIME parameters see section 4.1.
3.3.3 Constant bit-rate CELP 3.3.3 Constant bit-rate CELP
This mode is signalled by mode=CELP-cbr. In this mode one or more This mode is signalled by mode=CELP-cbr. In this mode one or more
fixed size CELP frames can be transported in one RTP packet; there fixed size CELP frames can be transported in one RTP packet; there
is no support for interleaving. The RTP payload consist of one or is no support for interleaving. The RTP payload consist of one or
more concatenated CELP frames, each of the same size. Both the AU more concatenated CELP frames, each of the same size. Both the AU
Header Section and the Auxiliary Section are empty. Header Section and the Auxiliary Section are empty.
The MIME format parameter ConstantSize MUST be provided to specify The MIME format parameter ConstantSize MUST be provided to specify
the length of each CELP frame. the length of each CELP frame.
For example: For example:
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/2 a=rtpmap:96 mpeg4-generic/44100/2
a=fmtp:96 streamtype=5; profile-level-id=15; mode=CELP-cbr; config= a=fmtp:96 streamtype=5; profile-level-id=15; mode=CELP-cbr; config=
AudioSpecificConfig(); ConstantSize=xxx; AudioSpecificConfig(); ConstantSize=xxx;
The AudioSpecificConfig() specifies that the audio stream type is The AudioSpecificConfig(), defined in ISO/IEC 14496-3, specifies
CELP. that the audio stream type is CELP. For the description of MIME
parameters see section 4.1.
3.3.4 Variable bit-rate CELP 3.3.4 Variable bit-rate CELP
This mode is signalled by mode=CELP-vbr. With this mode one or This mode is signalled by mode=CELP-vbr. With this mode one or
more variable size CELP frames can be transported in one RTP packet more variable size CELP frames can be transported in one RTP packet
with optional interleaving. As the largest possible frame size in with optional interleaving. As the largest possible frame size in
this mode is greater than the maximum CELP frame size, there is no this mode is greater than the maximum CELP frame size, there is no
support for fragmentation of CELP frames. support for fragmentation of CELP frames.
In this mode the RTP payload consists of the AU Header Section, In this mode the RTP payload consists of the AU Header Section,
skipping to change at page 17, line 52 skipping to change at page 18, line 42
larger than 0), the parameter Profile MUST also be present. larger than 0), the parameter Profile MUST also be present.
For example: For example:
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/2 a=rtpmap:96 mpeg4-generic/44100/2
a=fmtp:96 streamtype=5; profile-level-id=15; mode=CELP-vbr; config= a=fmtp:96 streamtype=5; profile-level-id=15; mode=CELP-vbr; config=
AudioSpecificConfig(); SizeLength=6; IndexLength=2; AudioSpecificConfig(); SizeLength=6; IndexLength=2;
IndexDeltaLength=2; Profile=1 IndexDeltaLength=2; Profile=1
The AudioSpecificConfig() specifies that the audio stream type is The AudioSpecificConfig(), defined in ISO/IEC 14496-3, specifies
CELP. that the audio stream type is CELP. For the description of MIME
parameters see section 4.1.
3.3.5 Low bit-rate AAC 3.3.5 Low bit-rate AAC
This mode is signalled by mode=AAC-lbr. This mode supports transport This mode is signalled by mode=AAC-lbr. This mode supports transport
of one or more variable size AAC frames with optional support for of one or more variable size AAC frames with optional support for
interleaving and fragmenting. The maximum size of an AAC frame interleaving and fragmenting. The maximum size of an AAC frame
(fragment) in this mode is 63 octets. (fragment) in this mode is 63 octets.
The payload configuration in this mode is the same as in the The payload configuration in this mode is the same as in the
variable bit-rate CELP mode as defined in 3.3.4. The RTP payload variable bit-rate CELP mode as defined in 3.3.4. The RTP payload
skipping to change at page 18, line 40 skipping to change at page 19, line 40
larger than 0), also the parameter Profile MUST be present. larger than 0), also the parameter Profile MUST be present.
For example: For example:
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/2 a=rtpmap:96 mpeg4-generic/44100/2
a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-lbr; config= a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-lbr; config=
AudioSpecificConfig(); SizeLength=6; IndexLength=2; AudioSpecificConfig(); SizeLength=6; IndexLength=2;
IndexDeltaLength=2; Profile=1 IndexDeltaLength=2; Profile=1
The AudioSpecificConfig() specifies that the audio stream type is The AudioSpecificConfig(), defined in ISO/IEC 14496-3, specifies
AAC. that the audio stream type is AAC. For the description of MIME
parameters see section 4.1.
3.3.6 High bit-rate AAC 3.3.6 High bit-rate AAC
This mode is signalled by mode=AAC-hbr. This mode supports transport This mode is signalled by mode=AAC-hbr. This mode supports transport
of one or more large variable size AAC frames in one RTP packet with of one or more large variable size AAC frames in one RTP packet with
optional support for interleaving and fragmenting. The maximum size optional support for interleaving and fragmenting. The maximum size
of an AAC frame (fragment) in this mode is 8191 octets. of an AAC frame (fragment) in this mode is 8191 octets.
In this mode the RTP payload consists of the AU Header Section, In this mode the RTP payload consists of the AU Header Section,
followed by one or more concatenated AAC frames. The Auxiliary followed by one or more concatenated AAC frames. The Auxiliary
skipping to change at page 19, line 26 skipping to change at page 20, line 34
larger than 0), also the parameter Profile MUST be present. larger than 0), also the parameter Profile MUST be present.
For example: For example:
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/2 a=rtpmap:96 mpeg4-generic/44100/2
a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr;
config=AudioSpecificConfig(); SizeLength=13; IndexLength=3; config=AudioSpecificConfig(); SizeLength=13; IndexLength=3;
IndexDeltaLength=3; Profile=1 IndexDeltaLength=3; Profile=1
The AudioSpecificConfig() specifies that the audio stream type is The AudioSpecificConfig(), defined in ISO/IEC 14496-3, specifies
AAC. that the audio stream type is AAC. For the description of MIME
parameters see section 4.1.
3.3.7 Additional modes 3.3.7 Additional modes
This specification only defines the modes specified in sections This specification only defines the modes specified in sections
3.3.2 up to 3.3.6. Additional modes are expected to be defined in 3.3.2 up to 3.3.6. Additional modes are expected to be defined in
future RFCs. Each additional mode MUST be in full compliance with future RFCs. Each additional mode MUST be in full compliance with
this specification. this specification.
When defining a new mode care MUST be taken that an implementation When defining a new mode care MUST be taken that an implementation
of all features of this specification can decode the payload format of all features of this specification can decode the payload format
skipping to change at page 20, line 36 skipping to change at page 22, line 4
Optional parameters are of two types: general parameters and Optional parameters are of two types: general parameters and
configuration parameters. The configuration parameters are used to configuration parameters. The configuration parameters are used to
configure the fields in the AU Header section and in the auxiliary configure the fields in the AU Header section and in the auxiliary
section. The absence of any configuration parameter is equivalent to section. The absence of any configuration parameter is equivalent to
the associated field set to its default value, which is always zero. the associated field set to its default value, which is always zero.
The absence of all configuration parameters resolves into a default The absence of all configuration parameters resolves into a default
"basic" configuration with an empty AU-header section and an empty "basic" configuration with an empty AU-header section and an empty
auxiliary section in each RTP packet. auxiliary section in each RTP packet.
MIME subtype name: mpeg4-generic MIME subtype name: mpeg4-generic
Required parameters: Required parameters:
MIME format parameters are not case dependent; however for clarity MIME format parameters are not case dependent; however for clarity
both upper and lower case are used in the names of the parameters both upper and lower case are used in the names of the parameters
described in this specification. described in this specification.
StreamType: StreamType:
The integer value that indicates the type of MPEG-4 stream that The integer value that indicates the type of MPEG-4 stream that
is carried; its coding corresponds to the values of the is carried; its coding corresponds to the values of the
streamType as defined for the DecoderConfigDescriptor in streamType as defined in Table 9 (objectTypeIndication Values)
ISO/IEC 14496-1. The value 6, indicating an MPEG-7 stream, MUST in ISO/IEC 14496-1. Note that the StreamType allows signalling of
NOT be used, as this payload format is not intended for transport an MPEG-7 stream; this RTP payload format is not designed to
of MPEG-7 streams. carry an MPEG-7 stream, and may not be suitable for transport of
MPEG-7 streams.
Profile-level-id: Profile-level-id:
A decimal representation of the MPEG-4 Profile Level indication. A decimal representation of the MPEG-4 Profile Level indication.
This parameter MUST be used in the capability exchange or This parameter MUST be used in the capability exchange or
session set-up procedure to indicate the MPEG-4 Profile and Level session set-up procedure to indicate the MPEG-4 Profile and Level
combination of which the relevant MPEG-4 media codec is capable combination of which the relevant MPEG-4 media codec is capable
of. of.
For MPEG-4 Audio streams, this parameter is the decimal value For MPEG-4 Audio streams, this parameter is the decimal value
from Table 5 (audioProfileLevelIndication Values) in ISO/IEC from Table 5 (audioProfileLevelIndication Values) in ISO/IEC
14496-1, indicating which MPEG-4 Audio tool subsets are 14496-1, indicating which MPEG-4 Audio tool subsets are
required to decode the audio stream. required to decode the audio stream.
For MPEG-4 Visual streams, this parameter is the decimal value For MPEG-4 Visual streams, this parameter is the decimal value
from Table G-1 (FLC table for profile and level indication of from Table G-1 (FLC table for profile and level indication of
ISO/IEC 14496-2), indicating which MPEG-4 Visual tool subsets ISO/IEC 14496-2), indicating which MPEG-4 Visual tool subsets
are required to decode the visual stream. are required to decode the visual stream.
For BIFS streams, this parameter is the decimal value that is For BIFS streams, this parameter is the decimal value that is
obtained from (SPLI + 256*GPLI), where: obtained from (SPLI + 256*GPLI), where:
skipping to change at page 21, line 21 skipping to change at page 22, line 41
ISO/IEC 14496-2), indicating which MPEG-4 Visual tool subsets ISO/IEC 14496-2), indicating which MPEG-4 Visual tool subsets
are required to decode the visual stream. are required to decode the visual stream.
For BIFS streams, this parameter is the decimal value that is For BIFS streams, this parameter is the decimal value that is
obtained from (SPLI + 256*GPLI), where: obtained from (SPLI + 256*GPLI), where:
SPLI is the decimal value from Table 4 in ISO/IEC 14496-1 with SPLI is the decimal value from Table 4 in ISO/IEC 14496-1 with
the applied sceneProfileLevelIndication; the applied sceneProfileLevelIndication;
GPLI is the decimal value from Table 7 in ISO/IEC 14496-1 with GPLI is the decimal value from Table 7 in ISO/IEC 14496-1 with
the applied graphicsProfileLevelIndication. the applied graphicsProfileLevelIndication.
For MPEG-J streams, this parameter is the decimal value from For MPEG-J streams, this parameter is the decimal value from
table 13 (MPEGJProfileLevelIndication) in ISO/IEC 14496-1, table 13 (MPEGJProfileLevelIndication) in ISO/IEC 14496-1,
indicating the profile and level of the MPERG-J stream. indicating the profile and level of the MPEG-J stream.
For OD streams, this parameter is the decimal value from table 3 For OD streams, this parameter is the decimal value from table 3
(ODProfileLevelIndication) in ISO/IEC 14496-1, indicating the (ODProfileLevelIndication) in ISO/IEC 14496-1, indicating the
profile and level of the OD stream. profile and level of the OD stream.
For IPMP streams, this parameter has either the decimal value 0, For IPMP streams, this parameter has either the decimal value 0,
indicating an unspecified profile and level, or a value larger indicating an unspecified profile and level, or a value larger
than zero, indicating an MPEG-4 IPMP profile and level as than zero, indicating an MPEG-4 IPMP profile and level as
defined in a future MPEG-4 specification. defined in a future MPEG-4 specification.
For Clock Reference streams and Object Content Info streams, this For Clock Reference streams and Object Content Info streams, this
parameter has the decimal value zero, indicating that profile parameter has the decimal value zero, indicating that profile
and level information is conveyed through the OD framework. and level information is conveyed through the OD framework.
Config: Config:
A hexadecimal representation of an octet string that expresses A hexadecimal representation of an octet string that expresses
the media payload configuration. Configuration data is mapped the media payload configuration. Configuration data is mapped
onto the octet string in an MSB-first basis. The first bit of onto the hexadecimal octet string in an MSB-first basis. The
the configuration data SHALL be located at the MSB of the first first bit of the configuration data SHALL be located at the MSB
octet. In the last octet, if necessary to achieve byte alignment, of the first octet. In the last octet, if necessary to achieve
up to 7 zero-valued padding bits shall follow the configuration byte alignment, up to 7 zero-valued padding bits shall follow
data. the configuration data.
For MPEG-4 Audio streams, config is the audio object type For MPEG-4 Audio streams, config is the audio object type
specific decoder configuration data AudioSpecificConfig() as specific decoder configuration data AudioSpecificConfig() as
defined in ISO/IEC 14496-3. defined in ISO/IEC 14496-3. For Stuctured Audio, the
AudioSpecificConfig()may be conveyed by other means, not
defined by this specification. If the AudioSpecificConfig()
is conveyed by other means for Stuctured Audio, then the
config MUST be a quoted empty hexadecimal octet string, as
follows: config="".
Note that a future mode of using this RTP payload format for
Structured Audio may define such other means.
For MPEG-4 Visual streams, config is the MPEG-4 Visual For MPEG-4 Visual streams, config is the MPEG-4 Visual
configuration information as defined in subclause 6.2.1 Start configuration information as defined in subclause 6.2.1 Start
codes of ISO/IEC 14496-2. The configuration information codes of ISO/IEC 14496-2. The configuration information
indicated by this parameter SHALL be the same as the indicated by this parameter SHALL be the same as the
configuration information in the corresponding MPEG-4 Visual configuration information in the corresponding MPEG-4 Visual
stream, except for first-half-vbv-occupancy and stream, except for first-half-vbv-occupancy and
latter-half-vbv-occupancy, if it exists, which may vary in latter-half-vbv-occupancy, if it exists, which may vary in
the repeated configuration information inside an MPEG-4 the repeated configuration information inside an MPEG-4
Visual stream (See 6.2.1 Start codes of ISO/IEC 14496-2). Visual stream (See 6.2.1 Start codes of ISO/IEC 14496-2).
For BIFS streams, this the BIFSConfig() information as defined For BIFS streams, this is the BIFSConfig() information as defined
in ISO/IEC 14496-1. For version 1, BIFSConfig is defined in in ISO/IEC 14496-1. For version 1, BIFSConfig is defined in
section 9.3.2.4, and for version 2 in section 9.3.5. The MIME section 9.3.5.2, and for version 2 in section 9.3.5.3. The
format parameter ObjectType signals the version of BIFSConfig. MIME format parameter ObjectType signals the version of
BIFSConfig.
For IPMP streams, this is either the decimal value 0, indicating For IPMP streams, this is either a quoted empty hexadecimal octet
the absence of any decoder configuration information, or the string, indicating the absence of any decoder configuration
decimal value 1, followed by IPMPConfiguration() as defined information (config=""), or the IPMPConfiguration() as
in a future MPEG-4 IPMP specification. defined in a future MPEG-4 IPMP specification.
For Object Content Info (OCI) streams, this is the For Object Content Info (OCI) streams, this is the
OCIDecoderConfiguration() information of the OCI stream, as OCIDecoderConfiguration() information of the OCI stream, as
defined in section 8.4.2.4 in ISO/IEC 14496-1. defined in section 8.4.2.4 in ISO/IEC 14496-1.
For OD streams, Clock Reference streams and MPEG-J streams, this For OD streams, Clock Reference streams and MPEG-J streams, this
is the decimal value 0, indicating that no information on the is a quoted empty hexadecimal octet string (config=""), as
decoder configuration is required. no information on the decoder configuration is required.
Mode: Mode:
The mode in which this specification is used. The following modes The mode in which this specification is used. The following modes
can be signalled: can be signalled:
mode=generic, mode=generic,
mode=CELP-cbr, mode=CELP-cbr,
mode=CELP-vbr, mode=CELP-vbr,
mode=AAC-lbr and mode=AAC-lbr and
mode=AAC-hbr. mode=AAC-hbr.
Other modes are expected to be defined in future RFCs. See also Other modes are expected to be defined in future RFCs. See also
section 3.3.7. section 3.3.7.
Optional general parameters: Optional general parameters:
ObjectType: ObjectType:
The decimal value from Table 8 in ISO/IEC 14496-1, indicating The decimal value from Table 8 in ISO/IEC 14496-1, indicating
the value of the objectTypeIndication of the transported stream. the value of the objectTypeIndication of the transported stream.
For BIFS streams this parameter MUST be present to signal the For BIFS streams this parameter MUST be present to signal the
type of BIFSConfiguration(). The ObjectType SHALL not signal a version of BIFSConfiguration(). Note that the ObjectType MAY
non-MPEG-4 stream. signal a non-MPEG-4 stream, and that the RTP payload format
defined in this document may not be suitable to carry a stream
that is not defined by MPEG-4.
ConstantSize: ConstantSize:
The constant size in octets of each Access Unit for this stream. The constant size in octets of each Access Unit for this stream.
Simultaneous presence of ConstantSize and the SizeLength Simultaneous presence of ConstantSize and the SizeLength
parameters is not permitted. parameters is not permitted.
Profile: Profile:
The decimal representation of the applied profile to constrain The decimal representation of the applied profile to constrain
the latency when interleaving; see section 3.2.3.3. Absence of the latency when interleaving; see section 3.2.3.3. Absence of
this parameter signals that the profile is not specified. this parameter signals that the profile is not specified.
skipping to change at page 23, line 22 skipping to change at page 24, line 50
in any non-first AU-header. in any non-first AU-header.
CTSDeltaLength: CTSDeltaLength:
The number of bits on which the CTS-delta field is encoded in The number of bits on which the CTS-delta field is encoded in
the AU-header. the AU-header.
DTSDeltaLength: DTSDeltaLength:
The number of bits on which the DTS-delta field is encoded in The number of bits on which the DTS-delta field is encoded in
the AU-header. the AU-header.
RandomAccessIndication:
A decimal value of zero or one, indicating whether the RAP-flag
is present in the AU-header. The decimal value of one indicates
presence of the RAP-flag, the default value zero its absence.
StreamStateIndication:
A decimal value of zero or one, indicating whether the
Stream-state field is present in the AU-header. The decimal
value of one indicates presence of the Stream-state field, the
default value zero its absence.
AuxiliaryDataSizeLength: AuxiliaryDataSizeLength:
The number of bits that is used to encode the auxiliary-data-size The number of bits that is used to encode the auxiliary-data-size
field. field.
Applications MAY use more parameters, in addition to those defined Applications MAY use more parameters, in addition to those defined
above. Receivers MUST tolerate the presence of such additional above. Receivers MUST tolerate the presence of such additional
parameters, but these parameters SHALL not impact the decoding of parameters, but these parameters SHALL not impact the decoding of
receivers that comply to this specification. receivers that comply to this specification.
Encoding considerations: Encoding considerations:
System bitstreams MUST be generated according to MPEG-4 Systems System bitstreams MUST be generated according to MPEG-4 Systems
specifications (ISO/IEC 14496-1). Video bitstreams MUST be generated specifications (ISO/IEC 14496-1). Video bitstreams MUST be generated
according to MPEG-4 Visual specifications (ISO/IEC 14496-2). Audio according to MPEG-4 Visual specifications (ISO/IEC 14496-2). Audio
bitstreams MUST be generated according to MPEG-4 Visual bitstreams MUST be generated according to MPEG-4 Audio
specifications (ISO/IEC 14496-3). The RTP packets MUST be packetized specifications (ISO/IEC 14496-3). The RTP packets MUST be packetized
according to the RTP payload format defined in RFC xxxx. according to the RTP payload format defined in RFC xxxx.
Security considerations: Security considerations:
As defined in section 5 of RFC xxxx. As defined in section 5 of RFC xxxx.
Interoperability considerations: Interoperability considerations:
MPEG-4 provides a large and rich set of tools for the coding of MPEG-4 provides a large and rich set of tools for the coding of
visual objects. For effective implementation of the standard, visual objects. For effective implementation of the standard,
subsets of the MPEG-4 tool sets have been provided for use in subsets of the MPEG-4 tool sets have been provided for use in
skipping to change at page 24, line 14 skipping to change at page 25, line 54
A stream SHALL be compliant with the MPEG-4 Profile@Level specified A stream SHALL be compliant with the MPEG-4 Profile@Level specified
by the parameter "profile-level-id". Interoperability between a by the parameter "profile-level-id". Interoperability between a
sender and a receiver is achieved by specifying the parameter sender and a receiver is achieved by specifying the parameter
"profile-level-id" in MIME content. In the capability exchange / "profile-level-id" in MIME content. In the capability exchange /
announcement procedure this parameter may mutually be set to the announcement procedure this parameter may mutually be set to the
same value. same value.
Published specification: Published specification:
The specifications for MPEG-4 streams are presented in ISO/IEC The specifications for MPEG-4 streams are presented in ISO/IEC
14469-1, 14469-2, and 14469-3. The RTP payload format is described 14496-1, 14496-2, and 14496-3. The RTP payload format is described
in RFC xxxx. in RFC xxxx.
Applications which use this media type: Applications which use this media type:
Multimedia streaming and conferencing tools, Internet messaging and Multimedia streaming and conferencing tools, Internet messaging and
Email applications. Email applications.
Additional information: none Additional information: none
Magic number(s): none Magic number(s): none
skipping to change at page 24, line 54 skipping to change at page 26, line 42
(for parameter usage examples see sections 3.3.2 up to 3.3.6). (for parameter usage examples see sections 3.3.2 up to 3.3.6).
4.3 Usage of SDP 4.3 Usage of SDP
4.3.1 The a=fmtp keyword 4.3.1 The a=fmtp keyword
It is assumed that one typical way to transport the above-described It is assumed that one typical way to transport the above-described
parameters associated with this payload format is via a SDP message parameters associated with this payload format is via a SDP message
[6] for example transported to the client in reply to a RTSP [6] for example transported to the client in reply to a RTSP
DESCRIBE or via SAP. In that case the (a=fmtp) keyword MUST be used DESCRIBE or via SAP. In that case the (a=fmtp) keyword MUST be used
as described in RFC 2327 [7], section 6, the syntax being then: as described in RFC 2327 [6], section 6, the syntax being then:
a=fmtp:<format> <parameter name>=<value>[; <parameter name>=<value>] a=fmtp:<format> <parameter name>=<value>[; <parameter name>=<value>]
5. Security Considerations 5. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [5]. This implies that confidentiality of the media specification [2]. This implies that confidentiality of the media
streams is achieved by encryption. Because the data compression used streams is achieved by encryption. Because the data compression used
with this payload format is applied end-to-end, encryption may be with this payload format is applied end-to-end, encryption may be
performed on the compressed data so there is no conflict between the performed on the compressed data so there is no conflict between the
two operations. The packet processing complexity of this payload two operations. The packet processing complexity of this payload
type (i.e. excluding media data processing) does not exhibit any type (i.e. excluding media data processing) does not exhibit any
significant non-uniformity in the receiver side to cause a denial- significant non-uniformity in the receiver side to cause a denial-
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,
skipping to change at page 25, line 34 skipping to change at page 27, line 34
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
ECMAScript. It is possible to use one or more of the above in a ECMAScript. It is possible to use one or more of the above in a
manner non-compliant to MPEG to crash or temporarily make the manner non-compliant to MPEG to crash or temporarily make the
receiver unavailable. receiver unavailable.
Senders SHOULD ensure that packet loss does not cause severe Senders SHOULD ensure that packet loss does not cause severe
problems in application execution when the packet carries OD problems in application execution when the packet carries OD
commands, BIFS commands, or programmatic content such as MPEG-J and commands, BIFS commands, or programmatic content such as MPEG-J and
ECMAScript. When such measures cannot be taken, instead of this ECMAScript. For example, the reliability can be improved by
payload format applications SHOULD use more reliable means to re-transmission, or by using the carousel mechanism as defined by
transport the information. MPEG in ISO/IEC 14496-1, while observing the general congestion
control principles. When such measures are deemed unsufficiently
adequate, instead of this payload format applications SHOULD use
more reliable means to transport the information, for example by
applying an FEC scheme for RTP (such as in RFC 2733), or by using
RTP over TCP (such as in RFC 2326, section 10.12), while giving due
consideration to congestion control. For a general description of
methods to repair streaming media see RFC 2354.
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.
In ISO/IEC 14469-1 a security model is defined for MPEG-4 Systems In ISO/IEC 14496-1 a security model is defined for MPEG-4 Systems
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 ECMAScript) commands in the streams. However, this can increase the
complexity significantly. complexity significantly.
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 Colin authors wish to thank all involved people, and in particular John
Perkins, Stephan Wenger and Dorairaj V for their valuable comments Lazarro, Alex MacAulay, Bill May, Colin Perkins, Dorairaj V and
and support. Stephan Wenger for their valuable comments and support.
7. References 7. References
[1] ISO/IEC International Standard 14496 (MPEG-4); "Information [1] ISO/IEC International Standard 14496 (MPEG-4); "Information
technology - Coding of audio-visual objects", January 2000 technology - Coding of audio-visual objects", January 2000
[2] Schulzrinne, Casner, Frederick, Jacobson RTP: A Transport [2] Schulzrinne, Casner, Frederick, Jacobson RTP, "A Transport
Protocol for Real Time Applications RFC 1889, Internet Engineering Protocol for Real Time Applications", RFC 1889, Internet
Task Force, January 1996. Engineering Task Force, January 1996.
[3] S. Bradner, Key words for use in RFCs to Indicate Requirement [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels, RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[4] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar, RTP payload [4] D. Hoffman, G. Fernando, V. Goyal, M. Civanlar, "RTP payload
format for MPEG1/MPEG2 Video, RFC 2250, January 1998. format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[5] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata, RTP [5] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata, "RTP
payload format for MPEG-4 Audio/Visual streams, RFC 3016. payload format for MPEG-4 Audio/Visual streams", RFC 3016.
[6] Handley, Jacobson, SDP: Session Description Protocol, RFC 2327, [6] Handley, Jacobson, "SDP: Session Description Protocol",
Internet Engineering Task Force, April 1998. RFC 2327, Internet Engineering Task Force, April 1998.
7. Author Adresses 8. Author Adresses
Jan van der Meer Jan van der Meer
Philips Digital Networks Philips Digital Networks
Cederlaan 4 Cederlaan 4
5600 JB Eindhoven 5600 JB Eindhoven
Netherlands Netherlands
Email : jan.vandermeer@philips.com Email : jan.vandermeer@philips.com
David Mackie David Mackie
Cisco Systems Inc. Cisco Systems Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95034 San Jose, CA 95134
Email: dmackie@cisco.com Email: dmackie@cisco.com
Viswanathan Swaminathan Viswanathan Swaminathan
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 Digital Networks, MP4Net Philips Digital Networks, MP4Net
51 rue Carnot 51 rue Carnot
92156 Suresnes 92156 Suresnes
skipping to change at page 27, line 35 skipping to change at page 30, line 7
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
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process procedures for copyrights defined in the Internet Standards process
MUST be followed, or as required to translate it into. MUST be followed, or as required to translate it into.
APPENDIX: Usage of this payload format APPENDIX: Usage of this payload format
Appendix A. Examples Appendix A. Examples of delay analysis with interleave
A.1 Examples of delay analysis with interleave
A.1.1 Group interleave A.1 Group interleave
An example of regular interleave is when packets are formed into An example of regular interleave is when packets are formed into
groups. If the number of packets in a group is N, packet 0 contains groups. If the number of packets in a group is N, for example
frame 0, frame N, frame 2N, and so on; packet 1 contains frame 1, packet 0 could contain frame 0, frame N, frame 2N, and so on;
frame 1+N, 1+2N, and so on. The AU-Index field is used to document packet 1 could contain frame 1, frame 1+N, 1+2N, and so on. The
the sequence of the packet within the group (or the first frame in AU-Index field is used to document the sequence of the packet
the packet, which is the same thing in this scheme), and all the within the group (or the first frame in the packet, which is the
AU-Index-delta fields contain N-1. same thing in this scheme), and all the AU-Index-delta fields
contain N-1.
Receivers can tell when a new interleave group is starting, by Because each subsequent frame in the packet has a higher time stamp
noting that the computed time stamp of the first frame in a packet than the preceding frame, receivers can tell when a new interleave
is later than any previously computed time stamp. This is because no group is starting, by noting that the computed time stamp of the
following packet can contain an earlier RTP time stamp (RTP rules), first frame in a packet is later than any previously computed time
and the second and subsequent frames in a packet have larger stamp. In that case the time stamps of all frames contained in the
time stamps (the frames in a packet are also in time-order). packet are higher than any previously computed time stamp, and
hence interleaving with any previously received frame is not
possible. In conclusion, a new group has been started.
If the group size is 3, then packets are formed as follows: If the group size is 3, then packets can be formed as follows:
Packet Time stamp Frame Numbers AU-Index, AU-Index-delta Packet Time stamp Frame Numbers AU-Index, AU-Index-delta
0 T[0] 0, 3, 6 0, 2, 2 0 T[0] 0, 3, 6 0, 2, 2
1 T[1] 1, 4, 7 0, 2, 2 1 T[1] 1, 4, 7 0, 2, 2
2 T[2] 2, 5, 8 0, 2, 2 2 T[2] 2, 5, 8 0, 2, 2
3 T[9] 9,12,15 0, 2, 2 3 T[9] 9,12,15 0, 2, 2
In this case, the receiver would have to buffer 4 frames at least In this case, the receiver would have to buffer 4 frames at least
from packets 0 and 1, and can flush all frames when packet 2 from packets 0 and 1, and can flush all frames when packet 2
arrives. (Frame 0 can be flushed as packet 0 arrives, since it is arrives. (Frame 0 can be flushed as packet 0 arrives, since it is
skipping to change at page 28, line 43 skipping to change at page 31, line 14
first group has, in fact, ended. (This is in contrast to schemes first group has, in fact, ended. (This is in contrast to schemes
which signal the group size explicitly; if the receiver knows that which signal the group size explicitly; if the receiver knows that
this is packet 3 of 3, then even if 2 of 3 is missing, it can this is packet 3 of 3, then even if 2 of 3 is missing, it can
de-interleave this group without waiting for the next one to start). de-interleave this group without waiting for the next one to start).
In the above example the AU-Index is coded with the value 0, as In the above example the AU-Index is coded with the value 0, as
required for the modes defined in this document. To reconstruct the required for the modes defined in this document. To reconstruct the
original order, the RTP time stamp and the AU-Index-delta are used. original order, the RTP time stamp and the AU-Index-delta are used.
See also 3.2.3.2. See also 3.2.3.2.
A.1.2 Continuous interleave Another example of forming packets with group interleave is given
below. In this example the packets are formed such that the loss of
two subsequent RPT packets does not cause the loss of two subsequent
audio frames. Note that in this example the RTP time stamps of
packets 3 and 4 are earlier than the RTP time stamps of packets 1
and 2.
Packet Time stamp Frame Numbers AU-Index, AU-Index-delta
0 T[0] 0, 5, 10, 15 0, 5, 5, 5
1 T[2] 2, 7, 12, 17 0, 5, 5, 5
2 T[4] 4, 9, 14, 19 0, 5, 5, 5
3 T[1] 1, 6, 11, 16 0, 5, 5, 5
4 T[3] 3, 8, 13, 18 0, 5, 5, 5
5 T[20] 20, 25, 30, 35 0, 5, 5, 5
and so on ..
A.2 Continuous interleave
In continuous interleave, once the scheme is 'primed', the number of In continuous interleave, once the scheme is 'primed', the number of
frames in a packet exceeds the 'stride' (the distance between them). frames in a packet exceeds the 'stride' (the distance between them).
This shortens the buffering needed, smooths the data-flow, and gives This shortens the buffering needed, smooths the data-flow, and gives
slightly larger packets -- and thus lower overhead -- for the same slightly larger packets -- and thus lower overhead -- for the same
interleave. For example, here is a continuous interleave also over interleave. For example, here is a continuous interleave also over
a stride of 3 frames, but with 4 frames per packet, for a run of 20 a stride of 3 frames, but with 4 frames per packet, for a run of 20
frames. This shows both how the scheme 'starts up' and how it frames. This shows both how the scheme 'starts up' and how it
finishes. finishes.
 End of changes. 

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