draft-ietf-avt-rtp-mpeg4-es-02.txt   draft-ietf-avt-rtp-mpeg4-es-03.txt 
Internet Engineering Task Force Yoshihiro Kikuchi - Toshiba Internet Engineering Task Force Yoshihiro Kikuchi - Toshiba
Internet Draft Toshiyuki Nomura - NEC Internet Draft Toshiyuki Nomura - NEC
Document: draft-ietf-avt-rtp-mpeg4-es-02.txt Shigeru Fukunaga - Oki Document: draft-ietf-avt-rtp-mpeg4-es-03.txt Shigeru Fukunaga - Oki
Yoshinori Matsui - Matsushita Yoshinori Matsui - Matsushita
Hideaki Kimata - NTT Hideaki Kimata - NTT
July 6, 2000 Aug 21, 2000
RTP payload format for MPEG-4 Audio/Visual streams RTP payload format for MPEG-4 Audio/Visual streams
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [1]. provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 1, line 32 skipping to change at page 1, line 32
inappropriate to use Internet- Drafts as reference material or to cite inappropriate to use Internet- Drafts as reference material or to cite
them other than as "work in progress." them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes RTP payload formats for carrying of MPEG-4 Audio This document describes RTP payload formats for carrying of MPEG-4 Audio
and Visual bitstreams[2][3]. For the purpose of directly mapping MPEG-4 and Visual bitstreams without using MPEG-4 Systems. For the purpose of
Audio/Visual bitstreams onto RTP packets, it provides specifications for directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it
the use of RTP header fields and also specifies fragmentation rules. It provides specifications for the use of RTP header fields and also
also provides specifications for MIME type registrations and the use of specifies fragmentation rules. It also provides specifications for MIME
SDP. type registrations and the use of SDP.
1. Introduction 1. Introduction
The RTP payload formats described in this Internet-Draft specify a way of The RTP payload formats described in this document specify a way of how
how MPEG-4 Audio and Visual streams are to be fragmented and mapped MPEG-4 Audio and Visual streams [2][3][4][5] are to be fragmented and
directly onto RTP packets. mapped directly onto RTP packets.
These RTP payload formats enable to carry MPEG-4 Audio/Visual streams These RTP payload formats enable to carry MPEG-4 Audio/Visual streams
without using the synchronization and stream management functionality of without using the synchronization and stream management functionality of
MPEG-4 Systems [6]. Such RTP payload format would be used within systems MPEG-4 Systems [6]. Such RTP payload format would be used within systems
where their own stream management functionality is provided and thus such where their own stream management functionality is provided and thus such
functionality in MPEG-4 Systems is not necessary. H.323 terminals are an functionality in MPEG-4 Systems is not necessary. H.323 terminals are an
example of such systems. MPEG-4 Audio/Visual streams are not managed by example of such systems. MPEG-4 Audio/Visual streams are not managed by
MPEG-4 Systems Object Descriptors but by H.245. The streams are directly MPEG-4 Systems Object Descriptors but by H.245. The streams are directly
mapped onto RTP packets without using the synchronization functionality mapped onto RTP packets without using the synchronization functionality
of MPEG-4 Systems. Other examples are SIP and RTSP where attribute of the of MPEG-4 Systems. Other examples are SIP and RTSP where MIME and SDP are
video stream (e.g. media type, packetization format and configuration) is used. MIME types and SDP usages of the RTP payload formats described in
specified in MIME and SDP parameters. this document are defined to specify the attribute of Audio/Visual
streams (e.g. media type, packetization format and codec configuration)
directly without using MPEG-4 Systems.
The semantics of RTP headers in such cases need to be clearly defined, The semantics of RTP headers in such cases need to be clearly defined,
including the association with MPEG-4 Audio/Visual data elements. In including the association with MPEG-4 Audio/Visual data elements. In
addition, it would be beneficial to define the fragmentation rules of RTP addition, it would be beneficial to define the fragmentation rules of RTP
packets for MPEG-4 Video streams so as to enhance error resiliency by packets for MPEG-4 Video streams so as to enhance error resiliency by
utilizing the error resilience tools provided inside the MPEG-4 Video utilizing the error resilience tools provided inside the MPEG-4 Video
stream. These issues, however, have yet to be addressed by other RTP stream. These issues, however, have yet to be addressed by other RTP
payload format specifications. payload format specifications.
1.1 MPEG-4 Visual RTP payload format 1.1 MPEG-4 Visual RTP payload format
skipping to change at page 2, line 49 skipping to change at page 2, line 50
With respect to the fragmentation rules for an MPEG-4 visual bitstream With respect to the fragmentation rules for an MPEG-4 visual bitstream
defined in this document, since MPEG-4 Visual is used for a wide variety defined in this document, since MPEG-4 Visual is used for a wide variety
of networks, it is desirable not to apply too much restriction on of networks, it is desirable not to apply too much restriction on
fragmentation, and a fragmentation rule such as "a single video packet fragmentation, and a fragmentation rule such as "a single video packet
shall always be mapped on a single RTP packet" may be inappropriate. On shall always be mapped on a single RTP packet" may be inappropriate. On
the other hand, careless, media unaware fragmentation may cause the other hand, careless, media unaware fragmentation may cause
degradation in error resiliency and bandwidth efficiency. The degradation in error resiliency and bandwidth efficiency. The
fragmentation rules described in this document are flexible but manage to fragmentation rules described in this document are flexible but manage to
define the minimum rules for preventing meaningless fragmentation and for define the minimum rules for preventing meaningless fragmentation and for
utilizing the error resilience of MPEG-4 visual. utilizing the error resilience of MPEG-4 Visual.
While the additional media specific RTP header defined for such video While the additional media specific RTP header defined for such video
coding tools as H.261 or MPEG-1/2 is effective in helping to recover coding tools as H.261 or MPEG-1/2 is effective in helping to recover
picture headers corrupted by packet losses, in MPEG-4 Visual there are picture headers corrupted by packet losses, in MPEG-4 Visual there are
already error resilience functionalities for recovering corrupt headers, already error resilience functionalities for recovering corrupt headers,
and these can be used on RTP/IP networks, as well as on other networks. and these can be used on RTP/IP networks, as well as on other networks.
(H.223/mobile, MPEG-2/TS, etc.) That is why no extra RTP header fields (H.223/mobile, MPEG-2/TS, etc.) That is why no extra RTP header fields
are defined in the MPEG-4 Visual RTP payload format proposed here. are defined in the MPEG-4 Visual RTP payload format proposed here.
1.2 MPEG-4 Audio RTP payload format 1.2 MPEG-4 Audio RTP payload format
MPEG-4 Audio is a new kind of audio standard that integrates many MPEG-4 Audio is a new kind of audio standard that integrates many
different types of audio coding tools. It also supports a mechanism for different types of audio coding tools. It also supports a mechanism for
representing synthesized sounds. Low-overhead MPEG-4 Audio Transport representing synthesized sounds. Low-overhead MPEG-4 Audio Transport
Multiplex (LATM) manages the sequences of audio data with relatively Multiplex (LATM) manages the sequences of audio data with relatively
small overhead. In audio-only applications, then, it is desirable for small overhead. In audio-only applications, then, it is desirable for
skipping to change at page 5, line 39 skipping to change at page 5, line 39
MPEG-4 Visual RTP payload format. If this assignment is to be carried out MPEG-4 Visual RTP payload format. If this assignment is to be carried out
dynamically, it can be performed by such out-of-band means as H.245, SDP, dynamically, it can be performed by such out-of-band means as H.245, SDP,
etc. etc.
Extension (X) bit: Defined by the RTP profile used. Extension (X) bit: Defined by the RTP profile used.
Sequence Number: Incremented by one for each RTP data packet sent, Sequence Number: Incremented by one for each RTP data packet sent,
starting, for security reasons, with a random initial value. starting, for security reasons, with a random initial value.
Marker (M) bit: The marker bit is set to one to indicate the last RTP Marker (M) bit: The marker bit is set to one to indicate the last RTP
packet (or only RTP packet) of a VOP. packet (or only RTP packet) of a VOP. When multiple VOPs are carried in
the same RTP packet, the marker bit is set to 1.
Timestamp: The timestamp indicates the composition time, or the Timestamp: The timestamp indicates the composition time, or the
presentation time in a no-compositor decoder. A constant offset, which is presentation time in a no-compositor decoder. A constant offset, which is
random, is added for security reasons. For a video object plane, it is random, is added for security reasons. The detailed definition of the
defined as vop_time_increment (in units of timestamp is as follows:
1/vop_time_increment_resolution seconds) plus the cumulative number of - For a video object plane, it is defined as vop_time_increment (in units
whole seconds specified by module_time_base and, if present, time_code of of 1/vop_time_increment_resolution seconds) plus the cumulative number
Group_of_VideoObjectPlane() fields. In the case of interlaced video, a of whole seconds specified by modulo_time_base and, if present,
VOP will consist of lines from two fields, and the timestamp will time_code of Group_of_VideoObjectPlane() fields.
indicate the composition time of the first field. If the RTP packet
contains only configuration information and/or - In the case of interlaced video, a VOP will consist of lines from two
Group_of_VideoObjectPlane() fields, the composition time of the next VOP fields, and the timestamp will indicate the composition time of the
in the coding order is used. If the RTP packet contains only first field.
visual_object_sequence_end_code information, the composition time of the - When multiple VOPs are carried in the same RTP packet, the timestamp
immediately preceding VOP in the coding order is used. indicates the earliest of the composition time within the VOPs carried
in the RTP packet.
- If the RTP packet contains only configuration information and/or
Group_of_VideoObjectPlane() fields, the composition time of the next
VOP in the coding order is used.
- If the RTP packet contains only visual_object_sequence_end_code
information, the composition time of the immediately preceding VOP in
the coding order is used.
The resolution of the timestamp is set to its default value of 90KHz, The resolution of the timestamp is set to its default value of 90KHz,
unless specified by an out-of-band means (e.g. SDP parameter or MIME unless specified by an out-of-band means (e.g. SDP parameter or MIME
parameter as defined in section 5). parameter as defined in section 5).
SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. SSRC, CC and CSRC fields are used as described in RFC 1889 [8].
3.2 Fragmentation of MPEG-4 Visual bitstream 3.2 Fragmentation of MPEG-4 Visual bitstream
A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP
skipping to change at page 6, line 35 skipping to change at page 6, line 43
header) or just after the header of the syntactically upper layer header) or just after the header of the syntactically upper layer
function. function.
(2) If one or more headers exist in the RTP payload, the RTP payload (2) If one or more headers exist in the RTP payload, the RTP payload
SHALL begin with the header of the syntactically highest function. SHALL begin with the header of the syntactically highest function.
Note: The visual_object_sequence_end_code is regarded as the lowest Note: The visual_object_sequence_end_code is regarded as the lowest
function. function.
(3) A header SHALL NOT be split into a plurality of RTP packets. (3) A header SHALL NOT be split into a plurality of RTP packets.
(4) Two or more VOPs SHALL be fragmented into different RTP packets so (4) Two or more VOPs SHOULD be fragmented into different RTP packets so
that one RTP packet consists of the data bytes associated with a unique that one RTP packet consists of the data bytes associated with a unique
presentation time (that is indicated in the timestamp field in the RTP presentation time (that is indicated in the timestamp field in the RTP
packet header). packet header), with the exception that multiple VOPs MAY be carried
within one RTP packet if the size of the VOPs is small.
(5) A single video packet SHOULD NOT be split into a plurality of RTP (5) A single video packet SHOULD NOT be split into a plurality of RTP
packets. The size of a video packet SHOULD be adjusted in such a way that packets. The size of a video packet SHOULD be adjusted in such a way that
the resulting RTP packet is not larger than the path-MTU. A video packet the resulting RTP packet is not larger than the path-MTU. A video packet
MAY be split into a plurality of RTP packets when the size of the video MAY be split into a plurality of RTP packets when the size of the video
packet is large. packet is large.
(Rule (5) does not apply to the enhancement layer of the scalable streams
where the video packet is not supported.)
Note: Rule (5) does not apply when the video packet is disabled by the
coder configuration (by setting resync_marker_disable in the VOL header
to 1), or in coding tools where the video packet is not supported. In
this case, a VOP MAY be split at arbitrary byte-positions.
Here, header means: Here, header means:
- Configuration information (Visual Object Sequence Header, Visual Object - Configuration information (Visual Object Sequence Header, Visual Object
Header and Video Object Layer Header) Header and Video Object Layer Header)
- visual_object_sequence_end_code - visual_object_sequence_end_code
- The header of the entry point function for an elementary stream - The header of the entry point function for an elementary stream
(Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(),
video_plane_with_short_header(), MeshObject() or FaceObject()) video_plane_with_short_header(), MeshObject() or FaceObject())
- The video packet header (video_packet_header() excluding - The video packet header (video_packet_header() excluding
next_resync_marker()) next_resync_marker())
- The header of gob_layer() - The header of gob_layer()
skipping to change at page 7, line 25 skipping to change at page 7, line 34
next_start_code(). next_start_code().
3.3 Examples of packetized MPEG-4 Visual bitstream 3.3 Examples of packetized MPEG-4 Visual bitstream
Considering the fact that MPEG-4 Visual covers a wide variety of networks Considering the fact that MPEG-4 Visual covers a wide variety of networks
ranging from scores of Kbps to several Mbps, and from those guaranteed to ranging from scores of Kbps to several Mbps, and from those guaranteed to
be almost error-free to mobile networks with high error rates, it is be almost error-free to mobile networks with high error rates, it is
desirable not to apply too much restriction on fragmentation. On the desirable not to apply too much restriction on fragmentation. On the
other hand, careless, media unaware fragmentation will cause degradation other hand, careless, media unaware fragmentation will cause degradation
in error resiliency and bandwidth efficiency. The fragmentation criteria in error resiliency and bandwidth efficiency. The fragmentation criteria
described in 3.2 are flexible but to define the minimum rules to prevent described in 3.2 are flexible but serve to define the minimum rules to
meaningless fragmentation. prevent meaningless fragmentation.
Figure 2 shows examples of RTP packets generated based on the criteria Figure 2 shows examples of RTP packets generated based on the criteria
described in 3.2 described in 3.2
(a) is an example of the first RTP packet or the random access point of (a) is an example of the first RTP packet or the random access point of
an MPEG-4 visual bitstream containing the configuration information. an MPEG-4 visual bitstream containing the configuration information.
According to criterion (1), the Visual Object Sequence Header(VS header) According to criterion (1), the Visual Object Sequence Header(VS header)
is placed at the beginning of the RTP payload, preceding the Visual is placed at the beginning of the RTP payload, preceding the Visual
Object Header and the Video Object Layer Header(VO header, VOL header). Object Header and the Video Object Layer Header(VO header, VOL header).
Since the fragmentation rule defined in 3.2 guarantees that the Since the fragmentation rule defined in 3.2 guarantees that the
skipping to change at page 8, line 30 skipping to change at page 8, line 37
(e) is an example of the case where more than one video packets are (e) is an example of the case where more than one video packets are
packetized into one RTP packet. This kind of packetization is effective packetized into one RTP packet. This kind of packetization is effective
to save the overhead of RTP/IP headers when the bit-rate of the to save the overhead of RTP/IP headers when the bit-rate of the
underlying network is low. However, it will decrease the packet-loss underlying network is low. However, it will decrease the packet-loss
resiliency because multiple video packets are discarded by a single RTP resiliency because multiple video packets are discarded by a single RTP
packet loss. The optimal number of video packets in an RTP packet and the packet loss. The optimal number of video packets in an RTP packet and the
length of the RTP packet can be determined considering the packet-loss length of the RTP packet can be determined considering the packet-loss
rate and the bit-rate of the underlying network. rate and the bit-rate of the underlying network.
(f) is an example of the case when the video packet is disabled by
setting resync_marker_disable in the VOL header to 1. In this case, a VOP
may be split into a plurality of RTP packets at arbitrary byte-positions.
For example, it is possible to split a VOP into fixed-length packets.
This kind of coder configuration and RTP packet fragmentation may be used
when the underlying network is guaranteed to be error-free. On the other
hand, it is not recommended to use it in error-prone environment since it
provides only poor packet loss resiliency.
Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2. Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.
Fragmentation of a header into multiple RTP packets, as in (a), will not Fragmentation of a header into multiple RTP packets, as in (a), will not
only increase the overhead of RTP/IP headers but also decrease the error only increase the overhead of RTP/IP headers but also decrease the error
resiliency. Therefore, it is prohibited by the criterion (3). resiliency. Therefore, it is prohibited by the criterion (3).
When concatenating more than one video packets into an RTP packet, VOP When concatenating more than one video packets into an RTP packet, VOP
header or video_packet_header() shall not be placed in the middle of the header or video_packet_header() shall not be placed in the middle of the
RTP payload. The packetization as in (b) is not allowed by criterion (2) RTP payload. The packetization as in (b) is not allowed by criterion (2)
due to the aspect of the error resiliency. Comparing this example with due to the aspect of the error resiliency. Comparing this example with
Figure 2(d), although two video packets are mapped onto two RTP packets Figure 2(d), although two video packets are mapped onto two RTP packets
in both cases, the packet-loss resiliency is not identical. Namely, if in both cases, the packet-loss resiliency is not identical. Namely, if
the second RTP packet is lost, both video packets 1 and 2 are lost in the the second RTP packet is lost, both video packets 1 and 2 are lost in the
case of Figure 3(b) whereas only video packet 2 is lost in the case of case of Figure 3(b) whereas only video packet 2 is lost in the case of
Figure 2(d). Figure 2(d).
An RTP packet containing more than one VOPs, as in (c), is not allowed.
+------+------+------+------+ +------+------+------+------+
(a) | RTP | VS | VO | VOL | (a) | RTP | VS | VO | VOL |
|header|header|header|header| |header|header|header|header|
+------+------+------+------+ +------+------+------+------+
+------+------+------+------+------------+ +------+------+------+------+------------+
(b) | RTP | VS | VO | VOL |Video Packet| (b) | RTP | VS | VO | VOL |Video Packet|
|header|header|header|header| | |header|header|header|header| |
+------+------+------+------+------------+ +------+------+------+------+------------+
skipping to change at page 9, line 30 skipping to change at page 10, line 30
+------+------+------------+ +------+------+------------+ +------+------+------------+ +------+------+------------+
(d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet|
|header|header| (1) | |header|header| (2) | |header|header| (1) | |header|header| (2) |
+------+------+------------+ +------+------+------------+ +------+------+------------+ +------+------+------------+
+------+------+------------+------+------------+------+------------+ +------+------+------------+------+------------+------+------------+
(e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet| (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet|
|header|header| (1) |header| (2) |header| (3) | |header|header| (1) |header| (2) |header| (3) |
+------+------+------------+------+------------+------+------------+ +------+------+------------+------+------------+------+------------+
+------+------+------------+ +------+------------+
(f) | RTP | VOP |VOP fragment| | RTP |VOP fragment|
|header|header| (1) | |header| (2) | ___
+------+------+------------+ +------+------------+
Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream
+------+-------------+ +------+------------+------------+ +------+-------------+ +------+------------+------------+
(a) | RTP |First half of| | RTP |Last half of|Video Packet| (a) | RTP |First half of| | RTP |Last half of|Video Packet|
|header| VP header | |header| VP header | | |header| VP header | |header| VP header | |
+------+-------------+ +------+------------+------------+ +------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+ +------+------+----------+ +------+---------+------+------------+
(b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet| (b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet|
|header|header| of VP(1) | |header| of VP(1)|header| (2) | |header|header| of VP(1) | |header| of VP(1)|header| (2) |
+------+------+----------+ +------+---------+------+------------+ +------+------+----------+ +------+---------+------+------------+
+------+------+------------------+------+------------------+
(c) | RTP | VOP |Video Object Plane| VOP |Video Object Plane|
|header|header| (1) |header| (2) |
+------+------+------------------+------+------------------+
Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual
bitstream bitstream
4. RTP Packetization of MPEG-4 Audio bitstream 4. RTP Packetization of MPEG-4 Audio bitstream
This section specifies RTP packetization rules for MPEG-4 Audio This section specifies RTP packetization rules for MPEG-4 Audio
bitstreams. MPEG-4 Audio streams are formatted by LATM (Low-overhead bitstreams. MPEG-4 Audio streams are formatted by LATM (Low-overhead
MPEG-4 Audio Transport Multiplex) tool[5], and the LATM-based streams are MPEG-4 Audio Transport Multiplex) tool[5], and the LATM-based streams are
then mapped onto RTP packets as described the three sections below. then mapped onto RTP packets as described the three sections below.
skipping to change at page 11, line 47 skipping to change at page 12, line 47
5. MIME type registration for MPEG-4 Audio/Visual streams 5. MIME type registration for MPEG-4 Audio/Visual streams
The following sections describe the MIME type registrations for MPEG-4 The following sections describe the MIME type registrations for MPEG-4
Audio/Visual streams. MIME type registration and SDP usage for the MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the MPEG-4
Visual stream are described in Sections 5.1 and 5.2, respectively, while Visual stream are described in Sections 5.1 and 5.2, respectively, while
MIME type registration and SDP usage for MPEG-4 Audio stream are MIME type registration and SDP usage for MPEG-4 Audio stream are
described in Sections 5.3 and 5.4, respectively. described in Sections 5.3 and 5.4, respectively.
(In the following sections, the RFC number "XXXX" represents the RFC (In the following sections, the RFC number "XXXX" represents the RFC
number, which should be assigned for this Internet Draft.) number, which should be assigned for this document.)
5.1 MIME type registration for MPEG-4 Visual 5.1 MIME type registration for MPEG-4 Visual
MIME media type name: video MIME media type name: video
MIME subtype name: MP4V MIME subtype name: MP4V
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
rate: This parameter is used only for RTP transport. It indicates the rate: This parameter is used only for RTP transport. It indicates the
skipping to change at page 12, line 30 skipping to change at page 13, line 30
information is mapped onto the octet string in an MSB-first basis. The information is mapped onto the octet string in an MSB-first basis. The
first bit of the configuration information SHALL be located at the MSB first bit of the configuration information SHALL be located at the MSB
of the first octet. The configuration information indicated by this of the first octet. The configuration information indicated by this
parameter SHALL be the same as the configuration information in the parameter SHALL be the same as the configuration information in the
corresponding MPEG-4 Visual stream, except for corresponding MPEG-4 Visual stream, except for
first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist, first_half_vbv_occupancy and latter_half_vbv_occupancy, if exist,
which may vary in the repeated configuration information inside an which may vary in the repeated configuration information inside an
MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2). MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2).
The parameter "profile-level-id" MAY be used in the capability The parameter "profile-level-id" MAY be used in the capability
exchange procedure to indicate MPEG-4 Visual Profile and Level exchange/announcement procedure to indicate MPEG-4 Visual Profile and
combination of which the MPEG-4 Visual codec is capable. The parameter Level combination of which the MPEG-4 Visual codec is capable. The
"config" MAY be used to indicate the configuration of the parameter "config" MAY be used to indicate the configuration of the
corresponding MPEG-4 visual bitstream, but SHALL NOT be used to corresponding MPEG-4 visual bitstream, but SHALL NOT be used to
indicate the codec capability in the capability exchange procedure. indicate the codec capability in the capability exchange procedure.
Example usages for these parameters are: Example usages for these parameters are:
- MPEG-4 Visual Simple Profile/Level 1: - MPEG-4 Visual Simple Profile/Level 1:
Content-type: video/mp4v; profile-level-id=1 Content-type: video/mp4v; profile-level-id=1
- MPEG-4 Visual Core Profile/Level 2: - MPEG-4 Visual Core Profile/Level 2:
Content-type: video/mp4v; profile-level-id=34 Content-type: video/mp4v; profile-level-id=34
skipping to change at page 13, line 17 skipping to change at page 14, line 17
Security considerations: Security considerations:
See section 6 of RFCXXXX. See section 6 of RFCXXXX.
Interoperability considerations: Interoperability considerations:
MPEG-4 Visual provides a large and rich set of tools for the coding of MPEG-4 Visual provides a large and rich set of tools for the coding of
visual objects. For effective implementation of the standard, subsets visual objects. For effective implementation of the standard, subsets
of the MPEG-4 Visual tool sets have been provided for use in specific of the MPEG-4 Visual tool sets have been provided for use in specific
applications. These subsets, called 'Profiles', limit the size of the applications. These subsets, called 'Profiles', limit the size of the
tool set a decoder is required to implement. In order to restrict tool set a decoder is required to implement. In order to restrict
computational complexity, one or more Levels are set for each Profiles. computational complexity, one or more Levels are set for each Profile.
A Profile@Level combination allows: A Profile@Level combination allows:
o a codec builder to implement only the subset of the standard he o a codec builder to implement only the subset of the standard he
needs, while maintaining interworking with other MPEG-4 devices needs, while maintaining interworking with other MPEG-4 devices
included in the same combination, and included in the same combination, and
o checking whether MPEG-4 devices comply with the standard o checking whether MPEG-4 devices comply with the standard
('conformance testing'). ('conformance testing').
The visual stream SHALL be compliant with the MPEG-4 Visual The visual stream SHALL be compliant with the MPEG-4 Visual
Profile@Level specified by the parameter "profile-level-id". Profile@Level specified by the parameter "profile-level-id".
Interoperability between a sender and a receiver may be achieved by Interoperability between a sender and a receiver may be achieved by
specifying the parameter "profile-level-id" in MIME content, or by specifying the parameter "profile-level-id" in MIME content, or by
arranging in the capability exchange procedure to set this parameter arranging in the capability exchange/announcement procedure to set this
mutually to the same value. parameter mutually to the same value.
Applications which use this media type: Applications which use this media type:
Audio and visual streaming and conferencing tools, Internet messaging Audio and visual streaming and conferencing tools, Internet messaging
and Email applications. and Email applications.
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
The authors of RFCXXXX. (See section 8) The authors of RFCXXXX. (See section 8)
skipping to change at page 16, line 45 skipping to change at page 17, line 45
semicolon separated list of parameter=value pairs. semicolon separated list of parameter=value pairs.
The following are some examples of the media representation in SDP: The following are some examples of the media representation in SDP:
For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz), For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz),
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A/8000 a=rtpmap:96 MP4A/8000
a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070 a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
a=ptime:20 a=ptime:20
For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of 24 For 64 kb/s AAC LC stereo bitstreams with
( an audio sampling rate of 24
kHz), kHz),
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A/24000 a=rtpmap:96 MP4A/24000
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
config=9122620000 config=9122620000
In the above two examples, audio configuration data is not multiplexed In the above two examples, audio configuration data is not multiplexed
into the RTP payload and is described only in SDP. Furthermore, the into the RTP payload and is described only in SDP. Furthermore, the
"clock rate" is set to the audio sampling rate. "clock rate" is set to the audio sampling rate.
skipping to change at page 17, line 29 skipping to change at page 18, line 29
6. Security Considerations 6. Security Considerations
RTP packets using the payload format defined in this specification are RTP packets using the payload format defined in this specification are
subject to the security considerations discussed in the RTP specification subject to the security considerations discussed in the RTP specification
[8]. This implies that confidentiality of the media streams is achieved [8]. This implies that confidentiality of the media streams is achieved
by encryption. Because the data compression used with this payload format by encryption. Because the data compression used with this payload format
is applied end-to-end, encryption may be performed on the compressed data is applied end-to-end, encryption may be performed on the compressed data
so there is no conflict between the two operations. so there is no conflict between the two operations.
This payload type does not exhibit any significant non-uniformity in the The complete MPEG-4 system allows for transport of a wide range of
receiver side computational complexity for packet processing to cause a content, including Java applets (MPEG-J) and scripts. Since this payload
potential denial-of-service threat. format is restricted to audio and video streams, it is not possible to
transport such active content in this format.
7. References 7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996. RFC 2026, October 1996.
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual 2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual
objects - Part2: Visual", December 1999. objects - Part2: Visual", December 1999.
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual 3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual
 End of changes. 

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