Internet Engineering Task Force Yoshihiro Kikuchi - Toshiba
Internet Draft Toshiyuki Nomura - NEC
Document: draft-ietf-avt-rtp-mpeg4-es-00.txt Shigeru Fukunaga - Oki
Yoshinori Matsui - Matsushita
Hideaki Kimata - NTT
February 1, 2000
RTP payload format for MPEG-4 Audio/Visual streams
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. Internet-Drafts
are draft documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet- Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes RTP payload formats for the carriage of MPEG-4
Audio and Visual streams[2][3], and an RTCP format for MPEG-4 upstream
messages functionalities[4]. In this specification, MPEG-4 Audio/Visual
bitstreams are directly mapped into RTP packets without using MPEG-4
Systems[6]. The RTP header fields usage and the fragmentation rule for
MPEG-4 Visual and Audio bitstreams are specified. It also specifies an
RTCP packet usage to carry the MPEG-4 upstream messages.
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 1]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
1. Introduction
1.1 Why MPEG-4 Audio/Visual RTP format needed?
The RTP payload formats described in this Internet-Draft specify the
normative way on how MPEG-4 Audio/Visual streams are fragmented and
mapped directly onto RTP packets. No extra header field is used for such
functionality as error protection or grouping of streams.
H.323 terminals could be the case. MPEG-4 Audio/Visual streams are not
managed by Object Descriptors[6] but H.245, and directly mapped into RTP
packets without Sync Layer[6]. The semantics of RTP headers in this case
need to be clearly defined including the association with the MPEG-4
Audio/Visual data elements. In addition, it would be beneficial to
define the fragmentation rule of RTP packets for MPEG-4 Video streams to
enhance error resiliency by utilizing the error resilience tools provided
inside the MPEG-4 Video stream. However, they have not been studied
until now.
1.2 Consideration on the MPEG-4 Visual RTP payload format
MPEG-4 Visual is a visual coding standard with many new functionalities:
high coding efficiency, high error resiliency, multiple arbitrary shaped
object based coding, etc. [2]. It covers a wide range of bitrate from
several Kbps to many Mbps. It also covers a wide variety of networks from
guarantied with almost error-free to mobile with high error rate by its
error resilience functionalities.
A normative way of fragmentation of an MPEG-4 visual bitstream into RTP
packets is defined in this Internet draft. Since MPEG-4 Visual is used
for a wide variety of networks, it is not desired to apply too much
restriction on the fragmentation like a single video packet shall always
be mapped on a single RTP packet. On the other hand, a careless media
unaware fragmentation may cause degradation of the error resiliency and
the bandwidth efficiency. The fragmentation rule described in this
Internet draft is flexible but to define the minimum rules to prevent the
meaningless fragmentation of e.g. splitting a header into packets.
For video coding media such as H.261 or MPEG-1/2, the additional media
specific RTP header works effectively for recovering e.g. a picture
header corrupt by packet losses. However, there are error resilience
functionalities inside MPEG-4 Visual to recover corrupt headers. These
functionalities can commonly be used on RTP/IP network as well as other
networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, no extra RTP header
fields are defined in the MPEG-4 Visual RTP payload format.
1.3 Consideration on the MPEG-4 Audio RTP payload format
MPEG-4 Audio is a new kind of audio standard that integrates many
different types of audio coding tools. It also supports a mechanism
representing synthesized sounds. Low-overhead MPEG-4 Audio Transport
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
Multiplex (LATM) manages the sequence of the compressed or the
represented audio data by MPEG-4 Audio tools with relatively small
overhead. In audio-only applications, the LATM-based MPEG-4 Audio
bitstreams, therefore, are desirable to be directly mapped into the RTP
packets without using MPEG-4 Systems.
Furthermore, if the payload of a packet is a single audio frame, a packet
loss does not impair the decodability of adjacent packets. Therefore, a
payload specific header for MPEG-4 Audio is not required as same as one
for the other audio coders.
1.4 MPEG-4 Audio/Visual upstream messaging on RTCP packets
In some cases, MPEG-4 Audio/Visual has upstream messaging
functionalities. These messages are extremely Audio/Visual specific,
since coders directly use these messages for controlling coding
parameters. From the point of view of controlling parameters, these
messages should be transmitted without delay. Therefore these messages
are directly mapped onto some kind of low delay RTCP packets.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [7].
3. RTP Packetization of MPEG-4 Visual bitstream
This section specifies the RTP packetization rule for MPEG-4 Visual
content. An MPEG-4 Visual bitstream is mapped directly onto the RTP
payload without any addition of extra header fields or removal of any
Visual syntax elements. The Combined Configuration/Elementary streams
mode is used so that the configuration information is carried in the same
RTP port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC
14496-2 [2][9][4])
When the short video header mode is used, RTP payload format for H.263
specified in the relevant RFCs or other standards MAY be used.
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | RTP
| MPEG-4 Visual stream (byte aligned) | Payload
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - An RTP packet for MPEG-4 Visual stream
3.1 RTP header fields usage for MPEG-4 Visual
Payload Type (PT): Distinct payload type should be assigned to specify
MPEG-4 Visual RTP payload format. If the dynamic payload type assignment
is used, it is specified by some out-of-band means (e.g. H.245, SDP,
etc.) that the MPEG-4 Visual payload format is used for the corresponding
RTP packet.
Extension (X) bit: Defined by the RTP profile used.
Sequence Number: Increment by one for each RTP data packet sent. It
starts with a random initial value for security reasons.
Marker (M) bit: The marker bit is set to one to indicate the last RTP
packet (or only RTP packet) of a VOP.
Timestamp: The timestamp indicates the composition time, or the
presentation time in a no-compositor decoder by adding a constant random
offset for security reasons. For a video object plane, it is defined by
vop_time_increment (in units of 1/vop_time_increment_resolution seconds)
plus the cumulative number of whole seconds specified by module_time_base
and time_code of Group_of_VideoObjectPlane() if present. In the case of
interlaced video, a VOP consists of lines from two fields and the
timestamp indicates the composition time of the first field. If the RTP
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
packet contains only configuration information and/or
Group_of_VideoObjectPlane(), the composition time of the subsequent VOP
in the coding order is used. If the RTP packet contains only
visual_object_sequence_end_code, the composition time of the immediately
preceding VOP in the coding order is used.
Unless specified by an out-of-band means, the resolution of the timestamp
is set to its default (90KHz).
SSRC, CC and CSRC fields are used as described in RFC 1889 [8].
3.2 Fragmentation of MPEG-4 Visual bitstream
A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP
payload without any addition of extra header fields or removal of any
Visual syntax elements. The Combined Configuration/Elementary streams
mode is used. The following rules apply for the fragmentation.
(1) The configuration information and Group_of_VideoObjectPlane() SHALL
be placed at the beginning of the RTP payload (just after the RTP header)
or just after the header of the syntactically upper layer function.
(2) If one or more headers exist in the RTP payload, the RTP payload
SHALL begin with the header of the syntactically highest function.
Note: The visual_object_sequence_end_code is regarded as the lowest
function.
(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
that one RTP packet consists of the data bytes associated with an unique
presentation time (that indicated to the timestamp field in the RTP
packet header).
(5) A single video packet SHOULD NOT be split into a plurality of RTP
packets. The size of a video packet SHOULD be adjusted such that the
resulting RTP packet is not larger than the path-MTU.
Hear, header means:
- Configuration information (Visual Object Sequence Header, Visual Object
Header and Visual Object Layer Header)
- visual_object_sequence_end_code
- The header of the entry point function for an elementary stream
(Group_of_VideoObjectPlane() or the header of VideoObjectPlane(),
video_plane_with_short_header(), MeshObject() or FaceObject())
- The video packet header (video_packet_header() excluding
next_resync_marker())
- The header of gob_layer()
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the definition of
the configuration information and the entry point functions.
The video packet starts with the VOP header or the video packet header,
followed by motion_shape_texture(), and ends with next_resync_marker() or
next_start_code).
3.3 Examples of packetized MPEG-4 Visual bitstream
Considering that MPEG-4 Visual is used on a wide variety of networks from
several Kbps to many Mbps, from guarantied networks with almost error-
free to mobile networks with high error rate, it is not desired to apply
too much restriction on the fragmentation like a single video packet
shall always be mapped on a single RTP packet. On the other hand, a
careless media unaware fragmentation will cause degradation of the error
resiliency and the bandwidth efficiency. The fragmentation criteria
described in 3.2 are flexible but to define the minimum rules to prevent
the meaningless fragmentation of e.g. splitting a header into packets.
For video coding media such as H.261 or MPEG-1/2, the additional media
specific RTP header works effectively for recovering e.g. a picture
header corrupt by packet losses. However, there is an error resilience
functionality inside MPEG-4 Visual to recover corrupt headers. This
functionality can commonly be used on RTP/IP network as well as other
networks. (H.223/mobile, MPEG-2/TS, etc.) Therefore, there is no strong
reason to define MPEG-4 Visual specific extra RTP header fields.
Figure 2 shows examples of RTP packets generated based on the criteria
described in 3.2
(a) is an example of the first RTP packet or the random access point of
an MPEG-4 visual bitstream. This RTP packet contains the configuration
information. According to the criterion (1), the Visual Object Sequence
Header(VS header) is placed at the beginning of the RTP payload, and the
Visual Object Header and the Visual Object Layer Header(VO header, VOL
header) follow it. Since the fragmentation rule defined in 3.2 guaranties
that the configuration information, starting with
visual_object_sequence_start_code, is always placed at the beginning of
the RTP payload, RTP receivers can detect the random access point by
checking if the first 32-bit field of the RTP payload is
visual_object_sequence_start_code.
(b) is an example the RTP packet that contains
Group_of_VideoObjectPlane(GOV). Following the criterion (1), the GOV is
placed at the beginning of the RTP payload. It is a waste of RTP/IP
header overhead to generate a RTP packet containing only a GOV whose
length is 7 bytes. Therefore, (a part of) the following VOP can be placed
in the same RTP packet as shown in (b).
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
(c) is an example that one video packet is packetized into one RTP
packet. When the packet-loss rate of the underlying network is high, this
kind of packetization is recommended. It is strongly recommended to set
resync_marker_disable to 0 in the VOL header to enable adjustment of the
video packet size. Even when the RTP packet containing the VOP header is
discarded by a packet loss, the other RTP packets can be decoded by using
the HEC(Header Extension Code) information in the video packet header. No
extra RTP header field is necessary.
(d) is an example that more than one video packets are packetized into
one RTP packet. This kind of packetization is effective to save the
overhead of RTP/IP headers if the bit-rate of the underlying network is
low. However, it will decrease the packet-loss resiliency because
multiple video packets are discarded by a single RTP packet loss. The
adequate number of video packets in a RTP packet and the RTP packet
length depend the packet-loss rate and the bit-rate of the underlying
network.
Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.
Fragmentation of a header into multiple RTP packets, like (a), will not
only increase the overhead of RTP/IP headers but also decrease the error
resiliency. Therefore, it is prohibited by the criterion (3).
When concatenating more than one video packets into a RTP packet, VOP
header or video_packet_header() shall not be placed in the middle of the
RTP payload. The packetization like (b) is not allowed by the criterion
(2). This is because of the error resiliency. Comparing this example with
Figure 2(c), two video packets are mapped onto two RTP packets in both
cases. However, there is a difference between the packet-loss resiliency.
When 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 Figure 2(c).
A RTP packet containing more than one VOPs, like (c), is not allowed.
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
+------+------+------+------+
(a) | RTP | VS | VO | VOL |
|header|header|header|header|
+------+------+------+------+
+------+-----+------------------+
(b) | RTP | GOV |Video Object Plane|
|header| | |
+------+-----+------------------+
+------+------+------------+ +------+------+------------+
(c) | RTP | VOP |Video Packet| | RTP | VP |Video Packet|
|header|header| (1) | |header|header| (2) |
+------+------+------------+ +------+------+------------+
+------+------+------------+------+------------+------+------------+
(d) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet|
|header|header| (1) |header| (2) |header| (3) |
+------+------+------------+------+------------+------+------------+
Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream
+------+-------------+ +------+------------+------------+
(a) | RTP |First half of| | RTP |Last half of|Video Packet|
|header| VP header | |header| VP header | |
+------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+
(b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet|
|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
bitstream
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
4. RTP Packetization of MPEG-4 Audio bitstream
When tools defined in MPEG-4 Systems are not used MPEG-4 Audio stream is
formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex)
format[5], and then mapped onto RTP packets as described the subsequent
section.
4.1 RTP Packet Format
The LATM consists of the sequence of audioMuxElements that include one or
more audio frames. A complete audioMuxElement or the part of
audioMuxElements SHALL be mapped directly onto the RTP payload without
removal of any audioMuxElement syntax elements as shown in Figure 4. The
first byte of each audioMuxElement SHALL be located at the first payload
location of an RTP packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |RTP
: audioMuxElement (byte aligned) :Payload
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - An RTP packet for MPEG-4 Audio
It is required for the audioMuxElement to indicate the following
muxConfigPresent information by an out-of-band means.
muxConfigPresent: If this information is set to 1, the audioMuxElement
SHALL include an indication bit "useSameStreamMux" and MAY include the
configuration information for audio compression "StreamMuxConfig". The
useSameStreamMux bit indicates whether the StreamMuxConfig element in the
previous frame is applied in the current frame.
4.2 RTP Header Fields Usage
Payload Type (PT): Distinct payload type should be assigned to specify
MPEG-4 Audio RTP payload format. If the dynamic payload type assignment
is used, it is specified by some out-of-band means (e.g. H.245, SDP,
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
etc.) that the MPEG-4 Audio payload format is used for the corresponding
RTP packet.
Marker (M) bit: The marker bit indicates audioMuxElement boundaries. This
bit is set to one to mark the RTP packet contains a complete
audioMuxElement or the last fragment of an audioMuxElement.
Timestamp: The timestamp indicates the composition time, or the
presentation time in a no-compositor decoder. Timestamps are recommended
to start at a random value for security reasons.
Unless specified by an out-of-band means, the resolution of the timestamp
is set to its default (90 kHz).
Sequence Number: Increment by one for each RTP packet sent. It starts
with a random value for security reasons.
SSRC, CC and CSRC fields are used as described in RFC 1889 [8].
4.3 Fragmentation of MPEG-4 Audio bitstream
It is desirable to put one audioMuxElement per RTP packet. The size of an
audioMuxElement is tried to be adjusted such that the resulting RTP
packet is not larger than the path-MTU. If this is not possible, the
audioMuxElement MAY be fragmented across several packets based on the
following rules.
(1) "payloadMux" which consists of payload elements MAY be fragmented
into several RTP packets so that one RTP packet consists of one or more
payload elements. A payload element SHOULD NOT be fragmented.
(2) If the audioMuxElement includes StreamMuxConfig, StreamMuxConfig
SHALL be included into the RTP packet containing the first payload
element.
5. RTCP Packetization of MPEG-4 upstream messages
This section specifies the usage of particular RTCP packets to carry the
upstream messages generated using the MPEG-4 Audio/Visual upstream
messaging functionalities, e.g. NEWPRED[4]. RTCP packets specified in
this section SHALL ONLY be used when it is indicated by the profile and
level indication of MPEG-4 the codecs have such functionalities. (e.g.
Advanced Real Time Simple Visual Profile[4])
The MPEG-4 upstream messages are transmitted on particular RTCP packets,
like H.261 RTCP control packets [10].
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
In the case that the RTP session uses a multicast address, the MPEG-4
upstream message packets are not transmitted to the normal RTCP
destination transport address. Instead, these upstream message packets
are sent directly via unicast from the decoder to the coder. The
destination port number of these upstream message packets is always same
to the port number of the normal RTCP address.
As a consequence, these upstream message packets may only be used when no
RTP mixers or translators intervene in the path from the coder to the
decoder. If such intermediate systems do intervene, the address of the
coder would no longer be present as the network-level source address in
packets received by the decoder, and in fact, it might not be possible
for the decoder to send packets directly to the coder.
Some reliable multicast protocols use similar NACK control packets
transmitted over the normal multicast distribution channel, however they
typically use random delays to prevent a NACK implosion problem. The goal
of such protocols is to provide reliable multicast packet delivery at the
expense of delay, which is appropriate for applications such as a shared
whiteboard.
On the other hand, real-time Audio/Visual transmission is more sensitive
to delay and does not require full reliability. For Audio/Visual
applications it is more effective to send the MPEG-4 upstream message
packets as soon as possible, i.e. as soon as a loss is detected, without
adding any random delays.
5.1. MPEG-4 Visual upstream message packets definition
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| UMT | PT=RTCP_MP4UM | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| MPEG-4 Upstream Messages Payload (byte aligned) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP packets as
in RTP data packets.
padding (P): 1 bit
If the padding bit is set, this RTCP packet contains some additional
padding octets at the end which are not part of the control
information. The last octet of the padding is a count of how many
padding octets should be ignored. In the case several upstream
messages are mapped onto one RTCP packet, padding should only be
required on the last individual message.
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
upstream message type (UMT): 5 bits
Identifies the type of the MPEG-4 upstream messages.
0: forbidden
1: MPEG-4 Visual NEWPRED
2-63: reserved
In this internet-draft, only NEWPRED is assigned as the candidate of
the UMT for the moment. Some other MPEG-4 Audio/Visual applications
using the upstream messages may be assigned in the future.
packet type (PT): 8 bits
The value of the packet type (PT) identifier is the constant
RTCP_MP4UM (TBD).
SSRC: 32 bits
SSRC is the synchronization source identifier for the sender of this
packet.
MPEG-4 Upstream Message Payload: variable
The syntax and semantics of the MPEG-4 upstream messages are defined
in the ISO/IEC 14496-2/3[4][5]. All messages are byte aligned.
Normally one message is mapped onto one RTCP packet, and several
messages with same UMT could be continuously mapped onto one RTCP
packet. One message SHALL NOT be fragmented into different RTCP
packets.
6. Security Considerations
RTP packets using the payload format defined in this specification are
subject to the security considerations discussed in the RTP specification
[8]. This implies that confidentiality of the media streams is achieved
by encryption. Because the data compression used with this payload format
is applied end-to-end, encryption may be performed on the compressed data
so there is no conflict between the two operations.
This payload type does not exhibit any significant non-uniformity in the
receiver side computational complexity for packet processing to cause a
potential denial-of-service threat.
7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-visual
objects - Part2: Visual", December 1999.
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-visual
objects - Part3: Audio", December 1999.
4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999.
5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999.
6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-visual
objects - Part1: Systems", December 1999.
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A Transport
Protocol for Real Time Applications", RFC 1889, Internet Engineering
Task Force, January 1996.
9 ISO/IEC 14496-2/DCOR1, October 1999.
10 T. Turletti, C. Hitema, "RTP Payload Format for H.261 Video Streams",
RFC 2032, Octover 1996.
8. Author's Addresses
Yoshihiro Kikuchi
Toshiba corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
Email: kiku@eel.rdc.toshiba.co.jp
Yoshinori Matsui
Matsushita Electric Industrial Co., LTD.
1006, Kadoma, Kadoma-shi, Osaka, Japan
Email: matsui@drl.mei.co.jp
Toshiyuki Nomura
NEC Corporation
4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
Email: t-nomura@ccm.cl.nec.co.jp
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13]
RTP payload format for MPEG-4 Audio/Visual streams February 2000
Email: fukunaga444@oki.co.jp
Hideaki Kimata
Nippon Telegraph and Telephone Corporation
1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
Email: kimata@nttvdt.hil.ntt.co.jp
RTP payload format for MPEG-4 Audio/Visual streams February 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
