draft-ietf-avt-rfc3016bis-01.txt   draft-ietf-avt-rfc3016bis-02.txt 
AVT M. Schmidt AVT M. Schmidt
Internet-Draft Dolby Laboratories Internet-Draft Dolby Laboratories
Obsoletes: 3016 (if approved) F. de Bont Obsoletes: 3016 (if approved) F. de Bont
Intended status: Standards Track Philips Electronics Intended status: Standards Track Philips Electronics
Expires: April 4, 2011 S. Doehla Expires: July 15, 2011 S. Doehla
Fraunhofer IIS Fraunhofer IIS
Jaehwan. Kim Jaehwan. Kim
LG Electronics Inc. LG Electronics Inc.
October 1, 2010 January 11, 2011
RTP Payload Format for MPEG-4 Audio/Visual Streams RTP Payload Format for MPEG-4 Audio/Visual Streams
draft-ietf-avt-rfc3016bis-01.txt draft-ietf-avt-rfc3016bis-02.txt
Abstract Abstract
This document describes Real-Time Transport Protocol (RTP) payload This document describes Real-Time Transport Protocol (RTP) payload
formats for carrying each of MPEG-4 Audio and MPEG-4 Visual formats for carrying each of MPEG-4 Audio and MPEG-4 Visual
bitstreams without using MPEG-4 Systems. For the purpose of directly bitstreams without using MPEG-4 Systems. For the purpose of directly
mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides
specifications for the use of RTP header fields and also specifies specifications for the use of RTP header fields and also specifies
fragmentation rules. It also provides specifications for Media Type fragmentation rules. It also provides specifications for Media Type
registration and the use of Session Description Protocol (SDP). registration and the use of Session Description Protocol (SDP). The
audio payload format described in this document has some limitations.
Comments are solicited and should be addressed to the working group's for new system designs [RFC3640] is preferred.
mailing list at avt@ietf.org and/or the author(s).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2011. This Internet-Draft will expire on July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. MPEG-4 Visual RTP payload format . . . . . . . . . . . . . 4 1.1. MPEG-4 Visual RTP Payload Format . . . . . . . . . . . . . 4
1.2. MPEG-4 Audio RTP payload format . . . . . . . . . . . . . 5 1.2. MPEG-4 Audio RTP Payload Format . . . . . . . . . . . . . 5
1.3. Differences to RFC 3016 . . . . . . . . . . . . . . . . . 6 1.3. Interoperability with RFC 3016 . . . . . . . . . . . . . . 5
1.4. Interoperability with RFC 3016 . . . . . . . . . . . . . . 7 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 3. LATM Restrictions for RTP Packetization of MPEG-4 Audio
3. RTP Packetization of MPEG-4 Visual bitstream . . . . . . . . . 8 Bitstreams . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Use of RTP header fields for MPEG-4 Visual . . . . . . . . 9 4. RTP Packetization of MPEG-4 Visual Bitstreams . . . . . . . . 7
3.2. Fragmentation of MPEG-4 Visual bitstream . . . . . . . . . 10 4.1. Use of RTP Header Fields for MPEG-4 Visual . . . . . . . . 8
3.3. Examples of packetized MPEG-4 Visual bitstream . . . . . . 11 4.2. Fragmentation of MPEG-4 Visual Bitstream . . . . . . . . . 9
4. RTP Packetization of MPEG-4 Audio bitstream . . . . . . . . . 14 4.3. Examples of Packetized MPEG-4 Visual Bitstream . . . . . . 11
4.1. RTP Packet Format . . . . . . . . . . . . . . . . . . . . 14 5. RTP Packetization of MPEG-4 Audio Bitstreams . . . . . . . . . 14
4.2. Use of RTP Header Fields for MPEG-4 Audio . . . . . . . . 16 5.1. RTP Packet Format . . . . . . . . . . . . . . . . . . . . 14
4.3. Fragmentation of MPEG-4 Audio bitstream . . . . . . . . . 16 5.2. Use of RTP Header Fields for MPEG-4 Audio . . . . . . . . 15
5. Media Type registration for MPEG-4 Audio/Visual streams . . . 16 5.3. Fragmentation of MPEG-4 Audio Bitstream . . . . . . . . . 16
5.1. Media Type registration for MPEG-4 Visual . . . . . . . . 17 6. Media Type Registration for MPEG-4 Audio/Visual Streams . . . 16
5.2. Mapping to SDP for MPEG-4 Visual . . . . . . . . . . . . . 19 6.1. Media Type Registration for MPEG-4 Visual . . . . . . . . 16
5.2.1. Declarative SDP usage for MPEG-4 Visual . . . . . . . 19 6.2. Mapping to SDP for MPEG-4 Visual . . . . . . . . . . . . . 18
5.3. Media Type registration for MPEG-4 Audio . . . . . . . . . 20 6.2.1. Declarative SDP Usage for MPEG-4 Visual . . . . . . . 19
5.4. Mapping to SDP for MPEG-4 Audio . . . . . . . . . . . . . 23 6.3. Media Type Registration for MPEG-4 Audio . . . . . . . . . 19
5.4.1. Declarative SDP usage for MPEG-4 Audio . . . . . . . . 24 6.4. Mapping to SDP for MPEG-4 Audio . . . . . . . . . . . . . 23
5.4.1.1. Example: In-band configuration . . . . . . . . . . 24 6.4.1. Declarative SDP Usage for MPEG-4 Audio . . . . . . . . 23
5.4.1.2. Example: 6kb/s CELP . . . . . . . . . . . . . . . 25 6.4.1.1. Example: In-band Configuration . . . . . . . . . . 24
5.4.1.3. Example: 64 kb/s AAC LC stereo . . . . . . . . . . 25 6.4.1.2. Example: 6kb/s CELP . . . . . . . . . . . . . . . 24
5.4.1.4. Example: Use of the SBR-enabled parameter . . . . 25 6.4.1.3. Example: 64 kb/s AAC LC Stereo . . . . . . . . . . 24
5.4.1.5. Example: Hierarchical Signaling of SBR . . . . . . 26 6.4.1.4. Example: Use of the SBR-enabled Parameter . . . . 25
5.4.1.6. Example: HE AAC v2 Signaling . . . . . . . . . . . 26 6.4.1.5. Example: Hierarchical Signaling of SBR . . . . . . 25
5.4.1.7. Example: Hierarchical Signaling of PS . . . . . . 27 6.4.1.6. Example: HE AAC v2 Signaling . . . . . . . . . . . 26
5.4.1.8. Example: MPEG Surround . . . . . . . . . . . . . . 27 6.4.1.7. Example: Hierarchical Signaling of PS . . . . . . 26
5.4.1.9. Example: MPEG Surround with extended SDP 6.4.1.8. Example: MPEG Surround . . . . . . . . . . . . . . 26
parameters . . . . . . . . . . . . . . . . . . . . 28 6.4.1.9. Example: MPEG Surround with Extended SDP
5.4.1.10. Example: MPEG Surround with single layer Parameters . . . . . . . . . . . . . . . . . . . . 27
configuration . . . . . . . . . . . . . . . . . . 28 6.4.1.10. Example: MPEG Surround with Single Layer
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 Configuration . . . . . . . . . . . . . . . . . . 27
6.1. Media Type Registration . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.2. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Differences to RFC 3016 . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The RTP payload formats described in this document specify how MPEG-4 The RTP payload formats described in this document specify how MPEG-4
Audio [14496-3] and MPEG-4 Visual streams [14496-2] are to be Audio [14496-3] and MPEG-4 Visual streams [14496-2] are to be
fragmented and mapped directly onto RTP packets. fragmented and mapped directly onto RTP packets.
These RTP payload formats enable transport of MPEG-4 Audio/Visual These RTP payload formats enable transport of MPEG-4 Audio/Visual
streams without using the synchronization and stream management streams without using the synchronization and stream management
functionality of MPEG-4 Systems [14496-1]. Such RTP payload formats functionality of MPEG-4 Systems [14496-1]. Such RTP payload formats
skipping to change at page 4, line 35 skipping to change at page 4, line 35
MPEG-4 Audio/Visual RTP payload formats can be handled in an unified MPEG-4 Audio/Visual RTP payload formats can be handled in an unified
way together with those formats defined for non-MPEG-4 codecs. The way together with those formats defined for non-MPEG-4 codecs. The
disadvantage is that interoperability with environments using MPEG-4 disadvantage is that interoperability with environments using MPEG-4
Systems may be difficult, hence, other payload formats may be better Systems may be difficult, hence, other payload formats may be better
suited to those applications. suited to those applications.
The semantics of RTP headers in such cases need to be clearly The semantics of RTP headers in such cases need to be clearly
defined, including the association with MPEG-4 Audio/Visual data defined, including the association with MPEG-4 Audio/Visual data
elements. In addition, it is beneficial to define the fragmentation elements. In addition, it is beneficial to define the fragmentation
rules of RTP packets for MPEG-4 Video streams so as to enhance error rules of RTP packets for MPEG-4 Video streams so as to enhance error
resiliency by utilizing the error resilience tools provided inside resiliency by utilizing the error resiliency tools provided inside
the MPEG-4 Video stream. the MPEG-4 Video stream.
1.1. MPEG-4 Visual RTP payload format 1.1. MPEG-4 Visual RTP Payload Format
MPEG-4 Visual is a visual coding standard with many new features: MPEG-4 Visual is a visual coding standard with many new features:
high coding efficiency; high error resiliency; multiple, arbitrary high coding efficiency; high error resiliency; multiple, arbitrary
shape object-based coding; etc. [14496-2]. It covers a wide range of shape object-based coding; etc. [14496-2]. It covers a wide range of
bitrate from scores of Kbps to several Mbps. It also covers a wide bitrate from scores of Kbps to several Mbps. It also covers a wide
variety of networks, ranging from those guaranteed to be almost variety of networks, ranging from those guaranteed to be almost
error-free to mobile networks with high error rates. error-free to mobile networks with high error rates.
With respect to the fragmentation rules for an MPEG-4 Visual With respect to the fragmentation rules for an MPEG-4 Visual
bitstream defined in this document, since MPEG-4 Visual is used for a bitstream defined in this document, since MPEG-4 Visual is used for a
wide variety of networks, it is desirable not to apply too much wide variety of networks, it is desirable not to apply too much
restriction on fragmentation, and a fragmentation rule such as "a restriction on fragmentation, and a fragmentation rule such as "a
single video packet shall always be mapped on a single RTP packet" single video packet shall always be mapped on a single RTP packet"
may be inappropriate. On the other hand, careless, media unaware may be inappropriate. On the other hand, careless, media unaware
fragmentation may cause degradation in error resiliency and bandwidth fragmentation may cause degradation in error resiliency and bandwidth
efficiency. The fragmentation rules described in this document are efficiency. The fragmentation rules described in this document are
flexible but manage to define the minimum rules for preventing flexible but manage to define the minimum rules for preventing
meaningless fragmentation while utilizing the error resilience meaningless fragmentation while utilizing the error resiliency
functionalities of MPEG-4 Visual. functionalities of MPEG-4 Visual.
The fragmentation rule recommends not to map more than one VOP in an The fragmentation rule "Different VOPs SHOULD be fragmented into
RTP packet so that the RTP timestamp uniquely indicates the VOP time different RTP packets" is made so that the RTP timestamp uniquely
framing. On the other hand, MPEG-4 video may generate VOPs of very indicates the VOP time framing. On the other hand, MPEG-4 video may
small size, in cases with an empty VOP (vop_coded=0) containing only generate VOPs of very small size, in cases with an empty VOP
VOP header or an arbitrary shaped VOP with a small number of coding (vop_coded=0) containing only VOP header or an arbitrary shaped VOP
blocks. To reduce the overhead for such cases, the fragmentation with a small number of coding blocks. To reduce the overhead for
rule permits concatenating multiple VOPs in an RTP packet. (See such cases, the fragmentation rule permits concatenating multiple
fragmentation rule (4) in section 3.2 and marker bit and timestamp in VOPs in an RTP packet. (See fragmentation rule (4) in Section 4.2
section 3.1.) and marker bit and timestamp in Section 4.1.)
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, MPEG-4 Visual has already picture headers corrupted by packet losses, MPEG-4 Visual has already
error resilience functionalities for recovering corrupt headers, and error resiliency functionalities for recovering corrupt headers, and
these can be used on RTP/IP networks as well as on other networks these can be used on RTP/IP networks as well as on other networks
(H.223/mobile, MPEG-2/TS, etc.). Therefore, no extra RTP header (H.223/mobile, MPEG-2/TS, etc.). Therefore, no extra RTP header
fields are defined in this MPEG-4 Visual RTP payload format. fields are defined in this MPEG-4 Visual RTP payload format.
1.2. MPEG-4 Audio RTP payload format 1.2. MPEG-4 Audio RTP Payload Format
MPEG-4 Audio is an audio standard that integrates many different MPEG-4 Audio is an audio standard that integrates many different
types of audio coding tools. Low-overhead MPEG-4 Audio Transport types of audio coding tools. 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 small overhead. In audio-only applications, then, it is desirable
for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto RTP for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto RTP
packets without using MPEG-4 Systems. packets without using MPEG-4 Systems.
While LATM has several multiplexing features as follows;
o Carrying configuration information with audio data,
o Concatenation of multiple audio frames in one audio stream,
o Multiplexing multiple objects (programs),
o Multiplexing scalable layers,
in RTP transmission there is no need for the last two features.
Therefore, these two features MUST NOT be used in applications based
on RTP packetization specified by this document. Since LATM has been
developed for only natural audio coding tools, i.e., not for
synthesis tools, it seems difficult to transmit Structured Audio (SA)
data and Text to Speech Interface (TTSI) data by LATM. Therefore, SA
data and TTSI data MUST NOT be transported by the RTP packetization
in this document.
For transmission of scalable streams, audio data of each layer SHOULD
be packetized onto different RTP streams allowing for the different
layers to be treated differently at the IP level, for example via
some means of differentiated service. On the other hand, all
configuration data of the scalable streams are contained in one LATM
configuration data "StreamMuxConfig" and every scalable layer shares
the StreamMuxConfig. The mapping between each layer and its
configuration data is achieved by LATM header information attached to
the audio data. In order to indicate the dependency information of
the scalable streams, the signaling mechanism as specified in
[RFC5583] SHOULD be used (see section 4.2).
For MPEG-4 Audio coding tools, as is true for other audio coders, if For MPEG-4 Audio coding tools, as is true for other audio coders, if
the payload is a single audio frame, packet loss will not impair the the payload is a single audio frame, packet loss will not impair the
decodability of adjacent packets. Therefore, the additional media decodability of adjacent packets. Therefore, the additional media
specific header for recovering errors will not be required for MPEG-4 specific header for recovering errors will not be required for MPEG-4
Audio. Existing RTP protection mechanisms, such as Generic Forward Audio. Existing RTP protection mechanisms, such as Generic Forward
Error Correction (RFC 5109 [RFC5109]) and Redundant Audio Data (RFC Error Correction [RFC5109] and Redundant Audio Data [RFC2198], MAY be
2198 [RFC2198]), MAY be applied to improve error resiliency. applied to improve error resiliency.
1.3. Differences to RFC 3016
The RTP payload format for MPEG-4 Audio as specified in RFC 3016 is
used by the 3GPP PSS service [3GPP]. However, there are some
misalignments between RFC 3016 and the 3GPP PSS specification that
are addressed by this update:
o The audio payload format (LATM) referenced in RFC 3016 is binary
incompatible to the format used in 3GPP.
o The audio signaling format (StreamMuxConfig) referenced in RFC
3016 is binary incompatible to the format used in 3GPP.
o The audio parameter "SBR-enabled" is not defined within RFC 3016
but used by 3GPP
o The rate parameter specification is ambiguous in the presence of
SBR (Spectral Band Replication)
o The number of audio channel parameter specification is ambiguous
in the presence of PS (Parametric Stereo)
Furthermore some comments have been addressed and signaling support
for MPEG surround [23003-1] was added. It should be noted that the
audio payload format described here has some known limitations. For
new system designs RFC 3640 [RFC3640] is recommended.
1.4. Interoperability with RFC 3016 1.3. Interoperability with RFC 3016
Although strictly speaking systems that support MPEG-4 Audio as Although strictly speaking systems that support MPEG-4 Audio as
specified in RFC 3016 [RFC3016] will be incompatible with systems specified in [RFC3016] will be incompatible with systems supporting
supporting this document, existing systems already comply with the this document, existing systems already comply with the specification
specification in 3GPP PSS service [3GPP] and therefore no in 3GPP PSS service [3GPP] and therefore no incompatibility issues
incompatibility issues are foreseen. are foreseen.
2. Definitions and Abbreviations 2. Definitions and Abbreviations
This memo makes use of terms, specified in [14496-2], [14496-3], and This document makes use of terms, specified in [14496-2], [14496-3],
[23003-1]. In addition, the following terms are used in this and [23003-1]. In addition, the following terms are used in this
document and have specific meaning within the context of this document and have specific meaning within the context of this
document. document.
Core codec sampling rate: Core codec sampling rate:
Audio codec sampling rate. When SBR (Spectral Band Replication) Audio codec sampling rate. When SBR (Spectral Band Replication)
is used, typically the double value of this will be regarded as is used, typically the double value of this will be regarded as
the definitive sampling rate (i.e., the decoder's output sampling the definitive sampling rate (i.e., the decoder's output sampling
rate) rate)
skipping to change at page 8, line 16 skipping to change at page 7, line 4
ASC: AudioSpecificConfig ASC: AudioSpecificConfig
HE AAC: High Efficiency AAC HE AAC: High Efficiency AAC
LATM: Low-overhead MPEG-4 Audio Transport Multiplex LATM: Low-overhead MPEG-4 Audio Transport Multiplex
PS: Parametric Stereo PS: Parametric Stereo
SBR: Spectral Band Replication SBR: Spectral Band Replication
VOP: Video Object Plane VOP: Video Object Plane
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. RTP Packetization of MPEG-4 Visual bitstream 3. LATM Restrictions for RTP Packetization of MPEG-4 Audio Bitstreams
While LATM has several multiplexing features as follows;
o Carrying configuration information with audio data,
o Concatenation of multiple audio frames in one audio stream,
o Multiplexing multiple objects (programs),
o Multiplexing scalable layers,
in RTP transmission there is no need for the last two features.
Therefore, these two features MUST NOT be used in applications based
on RTP packetization specified by this document. Since LATM has been
developed for only natural audio coding tools, i.e., not for
synthesis tools, it seems difficult to transmit Structured Audio (SA)
data and Text to Speech Interface (TTSI) data by LATM. Therefore, SA
data and TTSI data MUST NOT be transported by the RTP packetization
in this document.
For transmission of scalable streams, audio data of each layer SHOULD
be packetized onto different RTP streams allowing for the different
layers to be treated differently at the IP level, for example via
some means of differentiated service. On the other hand, all
configuration data of the scalable streams are contained in one LATM
configuration data "StreamMuxConfig" and every scalable layer shares
the StreamMuxConfig. The mapping between each layer and its
configuration data is achieved by LATM header information attached to
the audio data. In order to indicate the dependency information of
the scalable streams, the signaling mechanism as specified in
[RFC5583] SHOULD be used (see Section 5.2).
4. RTP Packetization of MPEG-4 Visual Bitstreams
This section specifies RTP packetization rules for MPEG-4 Visual This section specifies RTP packetization rules for MPEG-4 Visual
content. An MPEG-4 Visual bitstream is mapped directly onto RTP content. An MPEG-4 Visual bitstream is mapped directly onto RTP
packets without the addition of extra header fields or any removal of packets without the addition of extra header fields or any removal of
Visual syntax elements. The Combined Configuration/Elementary stream Visual syntax elements. The Combined Configuration/Elementary stream
mode MUST be used so that configuration information will be carried mode MUST be used so that configuration information will be carried
to the same RTP port as the elementary stream. (see 6.2.1 "Start to the same RTP port as the elementary stream. (see 6.2.1 "Start
codes" of ISO/IEC 14496-2 [14496-2]) The configuration information codes" of [14496-2]) The configuration information MAY additionally
MAY additionally be specified by some out-of-band means. If needed be specified by some out-of-band means. If needed by systems using
for an H.323 terminal, H.245 codepoint Media Type parameters and SDP parameters, "e.g., SIP and RTSP", the
"decoderConfigurationInformation" MUST be used for this purpose. If optional parameter "config" MUST be used to specify the configuration
needed by systems using Media Type parameters and SDP parameters, information (see Section 6.1 and Section 6.2).
e.g., SIP and RTSP, the optional parameter "config" MUST be used to
specify the configuration information (see 5.1 and 5.2).
When the short video header mode is used, the RTP payload format for When the short video header mode is used, the RTP payload format for
H.263 SHOULD be used (the format defined in RFC 4629 [RFC4629] is H.263 SHOULD be used (the format defined in [RFC4629] is RECOMMENDED,
RECOMMENDED, but the RFC 4628 [RFC4628] format MAY be used for but the [RFC4628] format MAY be used for compatibility with older
compatibility with older implementations). implementations).
0 1 2 3 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 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 |V=2|P|X| CC |M| PT | sequence number | RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | Header | timestamp | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
skipping to change at page 9, line 26 skipping to change at page 8, line 37
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | RTP | | RTP
| MPEG-4 Visual stream (byte aligned) | Pay- | MPEG-4 Visual stream (byte aligned) | Pay-
| | load | | load
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - An RTP packet for MPEG-4 Visual stream Figure 1 - An RTP packet for MPEG-4 Visual stream
3.1. Use of RTP header fields for MPEG-4 Visual 4.1. Use of RTP Header Fields for MPEG-4 Visual
Payload Type (PT): The assignment of an RTP payload type for this Payload Type (PT): The assignment of an RTP payload type for this
packet format is outside the scope of this document, and will not be packet format is outside the scope of this document, and will not be
specified here. It is expected that the RTP profile for a particular specified here. It is expected that the RTP profile for a particular
class of applications will assign a payload type for this encoding, class of applications will assign a payload type for this encoding,
or if that is not done then a payload type in the dynamic range SHALL or if that is not done then a payload type in the dynamic range SHALL
be chosen by means of an out-of-band signaling protocol (e.g., H.245, be chosen by means of an out-of-band signaling protocol (e.g., H.245,
SIP, etc). SIP, etc).
Extension (X) bit: Defined by the RTP profile used. Extension (X) bit: Defined by the RTP profile used.
skipping to change at page 10, line 16 skipping to change at page 9, line 29
o If the RTP packet contains only configuration information and/or o If the RTP packet contains only configuration information and/or
Group_of_VideoObjectPlane() fields, the timestamp of the next VOP Group_of_VideoObjectPlane() fields, the timestamp of the next VOP
in the coding order is used. in the coding order is used.
o If the RTP packet contains only visual_object_sequence_end_code o If the RTP packet contains only visual_object_sequence_end_code
information, the timestamp of the immediately preceding VOP in the information, the timestamp of the immediately preceding VOP in the
coding order is used. 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 unless specified by an out-of-band means (e.g., SDP parameter or
Media Type parameter as defined in section 5). Media Type parameter as defined in Section 6).
Other header fields are used as described in RFC 3550 [RFC3550]. Other header fields are used as described in [RFC3550].
3.2. Fragmentation of MPEG-4 Visual bitstream 4.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
payload without any addition of extra header fields or any removal of payload without any addition of extra header fields or any removal of
Visual syntax elements. The Combined Configuration/Elementary Visual syntax elements. The Combined Configuration/Elementary
streams mode is used. The following rules apply for the streams mode is used. The following rules apply for the
fragmentation. fragmentation.
In the following, header means one of the following: In the following, header means one of the following:
o Configuration information (Visual Object Sequence Header, Visual o Configuration information (Visual Object Sequence Header, Visual
skipping to change at page 10, line 44 skipping to change at page 10, line 10
o The header of the entry point function for an elementary stream o 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())
o The video packet header (video_packet_header() excluding o The video packet header (video_packet_header() excluding
next_resync_marker()) next_resync_marker())
o The header of gob_layer() o The header of gob_layer()
o See 6.2.1 "Start codes" of ISO/IEC 14496-2 [14496-2] for the o See 6.2.1 "Start codes" of [14496-2] for the definition of the
definition of the configuration information and the entry point configuration information and the entry point functions.
functions.
(1) Configuration information and Group_of_VideoObjectPlane() fields (1) Configuration information and Group_of_VideoObjectPlane() fields
SHALL be placed at the beginning of the RTP payload (just after the 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 RTP 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.
skipping to change at page 11, line 24 skipping to change at page 10, line 37
unique VOP time instance (that is indicated in the timestamp field in unique VOP time instance (that is indicated in the timestamp field in
the RTP packet header), with the exception that multiple consecutive the RTP packet header), with the exception that multiple consecutive
VOPs MAY be carried within one RTP packet in the decoding order if VOPs MAY be carried within one RTP packet in the decoding order if
the size of the VOPs is small. the size of the VOPs is small.
Note: When multiple VOPs are carried in one RTP payload, the Note: When multiple VOPs are carried in one RTP payload, the
timestamp of the VOPs after the first one may be calculated by the timestamp of the VOPs after the first one may be calculated by the
decoder. This operation is necessary only for RTP packets in which decoder. This operation is necessary only for RTP packets in which
the marker bit equals to one and the beginning of RTP payload the marker bit equals to one and the beginning of RTP payload
corresponds to a start code. (See timestamp and marker bit in corresponds to a start code. (See timestamp and marker bit in
section 3.1.) Section 4.1.)
(5) It is RECOMMENDED that a single video packet is sent as a single (5) It is RECOMMENDED that a single video packet is sent as a single
RTP packet. The size of a video packet SHOULD be adjusted in such a RTP packet. 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. way that the resulting RTP packet is not larger than the path-MTU.
Note: Rule (5) does not apply when the video packet is disabled by If the video packet is disabled by the coder configuration (by
the coder configuration (by setting resync_marker_disable in the VOL setting resync_marker_disable in the VOL header to 1), or in coding
header to 1), or in coding tools where the video packet is not tools where the video packet is not supported, a VOP MAY be split at
supported. In this case, a VOP MAY be split at arbitrary byte- arbitrary byte-positions.
positions.
The video packet starts with the VOP header or the video packet The video packet starts with the VOP header or the video packet
header, followed by motion_shape_texture(), and ends with header, followed by motion_shape_texture(), and ends with
next_resync_marker() or next_start_code(). next_resync_marker() or next_start_code().
3.3. Examples of packetized MPEG-4 Visual bitstream 4.3. Examples of Packetized MPEG-4 Visual Bitstream
Figure 2 shows examples of RTP packets generated based on the Figure 2 shows examples of RTP packets generated based on the
criteria described in 3.2 criteria described in Section 4.2
(a) is an example of the first RTP packet or the random access point (a) is an example of the first RTP packet or the random access point
of an MPEG-4 Visual bitstream containing the configuration of an MPEG-4 Visual bitstream containing the configuration
information. According to criterion (1), the Visual Object Sequence information. According to criterion (1), the Visual Object Sequence
Header(VS header) is placed at the beginning of the RTP payload, Header(VS header) is placed at the beginning of the RTP payload,
preceding the Visual Object Header and the Video Object Layer preceding the Visual Object Header and the Video Object Layer
Header(VO header, VOL header). Since the fragmentation rule defined Header(VO header, VOL header). Since the fragmentation rule defined
in 3.2 guarantees that the configuration information, starting with in Section 4.2 guarantees that the configuration information,
visual_object_sequence_start_code, is always placed at the beginning starting with visual_object_sequence_start_code, is always placed at
of the RTP payload, RTP receivers can detect the random access point the beginning of the RTP payload, RTP receivers can detect the random
by checking if the first 32-bit field of the RTP payload is access point by checking if the first 32-bit field of the RTP payload
visual_object_sequence_start_code. is visual_object_sequence_start_code.
(b) is another example of the RTP packet containing the configuration (b) is another example of the RTP packet containing the configuration
information. It differs from example (a) in that the RTP packet also information. It differs from example (a) in that the RTP packet also
contains a video packet in the VOP following the configuration contains a VOP header and a Video Packet in the VOP following the
information. Since the length of the configuration information is configuration information. Since the length of the configuration
relatively short (typically scores of bytes) and an RTP packet information is relatively short (typically scores of bytes) and an
containing only the configuration information may thus increase the RTP packet containing only the configuration information may thus
overhead, the configuration information and the immediately following increase the overhead, the configuration information and the
GOV and/or (a part of) VOP can be packetized into a single RTP packet immediately following VOP can be packetized into a single RTP packet.
as in this example.
(c) is an example of an RTP packet that contains (c) is an example of an RTP packet that contains
Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is
placed at the beginning of the RTP payload. It would be a waste of placed at the beginning of the RTP payload. It would be a waste of
RTP/IP header overhead to generate an RTP packet containing only a RTP/IP header overhead to generate an RTP packet containing only a
GOV whose length is 7 bytes. Therefore, (a part of) the following GOV whose length is 7 bytes. Therefore, (a part of) the following
VOP can be placed in the same RTP packet as shown in (c). VOP can be placed in the same RTP packet as shown in (c).
(d) is an example of the case where one video packet is packetized (d) is an example of the case where one video packet is packetized
into one RTP packet. When the packet-loss rate of the underlying into one RTP packet. When the packet-loss rate of the underlying
skipping to change at page 12, line 51 skipping to change at page 12, line 16
(f) is an example of the case when the video packet is disabled by (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, 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- 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- positions. For example, it is possible to split a VOP into fixed-
length packets. This kind of coder configuration and RTP packet length packets. This kind of coder configuration and RTP packet
fragmentation may be used when the underlying network is guaranteed fragmentation may be used when the underlying network is guaranteed
to be error-free. to be error-free.
Figure 3 shows examples of RTP packets prohibited by the criteria of Figure 3 shows examples of RTP packets prohibited by the criteria of
3.2. Section 4.2.
Fragmentation of a header into multiple RTP packets, as in (a), will Fragmentation of a header into multiple RTP packets, as in (a), will
not only increase the overhead of RTP/IP headers but also decrease not only increase the overhead of RTP/IP headers but also decrease
the error resiliency. Therefore, it is prohibited by the criterion the error resiliency. Therefore, it is prohibited by the criterion
(3). (3).
When concatenating more than one video packets into an RTP packet, When concatenating more than one video packets into an RTP packet,
VOP header or video_packet_header() shall not be placed in the middle VOP header or video_packet_header() are not allowed to be placed in
of the RTP payload. The packetization as in (b) is not allowed by the middle of the RTP payload. The packetization as in (b) is not
criterion (2) due to the aspect of the error resiliency. Comparing allowed by criterion (2) due to the aspect of the error resiliency.
this example with Figure 2(d), although two video packets are mapped Comparing this example with Figure 2(d), although two video packets
onto two RTP packets in both cases, the packet-loss resiliency is not are mapped onto two RTP packets in both cases, the packet-loss
identical. Namely, if the second RTP packet is lost, both video resiliency is not identical. Namely, if the second RTP packet is
packets 1 and 2 are lost in the case of Figure 3(b) whereas only lost, both video packets 1 and 2 are lost in the case of Figure 3(b)
video packet 2 is lost in the case of Figure 2(d). whereas only video packet 2 is lost in the case of Figure 2(d).
+------+------+------+------+ +------+------+------+------+
(a) | RTP | VS | VO | VOL | (a) | RTP | VS | VO | VOL |
|header|header|header|header| |header|header|header|header|
+------+------+------+------+ +------+------+------+------+
+------+------+------+------+------+------------+ +------+------+------+------+------+------------+
(b) | RTP | VS | VO | VOL | VOP |Video Packet| (b) | RTP | VS | VO | VOL | VOP |Video Packet|
|header|header|header|header|header| | |header|header|header|header|header| |
+------+------+------+------+------+------------+ +------+------+------+------+------+------------+
skipping to change at page 14, line 18 skipping to change at page 14, line 5
+------+-------------+ +------+------------+------------+ +------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+ +------+------+----------+ +------+---------+------+------------+
(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) |
+------+------+----------+ +------+---------+------+------------+ +------+------+----------+ +------+---------+------+------------+
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 5. RTP Packetization of MPEG-4 Audio Bitstreams
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 MUST be formatted LATM (Low- bitstreams. MPEG-4 Audio streams MUST be formatted LATM (Low-
overhead MPEG-4 Audio Transport Multiplex) [14496-3] streams, and the overhead MPEG-4 Audio Transport Multiplex) [14496-3] streams, and the
LATM-based streams are then mapped onto RTP packets as described in LATM-based streams are then mapped onto RTP packets as described in
the sections below. the sections below.
4.1. RTP Packet Format 5.1. RTP Packet Format
LATM-based streams consist of a sequence of audioMuxElements that LATM-based streams consist of a sequence of audioMuxElements that
include one or more PayloadMux elements which carry the audio frames. include one or more PayloadMux elements which carry the audio frames.
A complete audioMuxElement or a part of one SHALL be mapped directly A complete audioMuxElement or a part of one SHALL be mapped directly
onto an RTP payload without any removal of audioMuxElement syntax onto an RTP payload without any removal of audioMuxElement syntax
elements (see Figure 4). The first byte of each audioMuxElement elements (see Figure 4). The first byte of each audioMuxElement
SHALL be located at the first payload location in an RTP packet. SHALL be located at the first payload location in an RTP packet.
0 1 2 3 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 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
skipping to change at page 15, line 30 skipping to change at page 14, line 47
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - An RTP packet for MPEG-4 Audio Figure 4 - An RTP packet for MPEG-4 Audio
In order to decode the audioMuxElement, the following In order to decode the audioMuxElement, the following
muxConfigPresent information is required to be indicated by out-of- muxConfigPresent information is required to be indicated by out-of-
band means. When SDP is utilized for this indication, the Media Type band means. When SDP is utilized for this indication, the Media Type
parameter "cpresent" corresponds to the muxConfigPresent information parameter "cpresent" corresponds to the muxConfigPresent information
(see section 5.3). The following restrictions apply: (see Section 6.3). The following restrictions apply:
o In the out-of-band configuration case the number of PayloadMux o In the out-of-band configuration case the number of PayloadMux
elements contained in each audioMuxElement can only be set once. elements contained in each audioMuxElement can only be set once.
If values greater than one PayloadMux Element are used, special If more than one PayloadMux elements are contained in each
care is required to ensure that the last RTP packet remains AudioMuxElement, special care is required to ensure that the last
decodable. RTP packet remains decodable.
o In the in-band configuration case the audio frames are in general o To construct the audioMuxElement in the in-band configuration
not byte aligned. Hinting RTP payload from MP4 file format case, non octet aligned configuration data is preceding the one or
[14496-12] [14496-14] is therefore not possible. more PayloadMux elements. Since the generation of RTP payloads
with non octet aligned data is not possible with RTP hint tracks,
as defined by the MP4 file format [14496-12] [14496-14], this
document does not support RTP hint tracks for the in-band
configuration case.
muxConfigPresent: If this value is set to 1 (in-band mode), the muxConfigPresent: If this value is set to 1 (in-band mode), the
audioMuxElement SHALL include an indication bit "useSameStreamMux" audioMuxElement SHALL include an indication bit "useSameStreamMux"
and MAY include the configuration information for audio compression and MAY include the configuration information for audio compression
"StreamMuxConfig". The useSameStreamMux bit indicates whether the "StreamMuxConfig". The useSameStreamMux bit indicates whether the
StreamMuxConfig element in the previous frame is applied in the StreamMuxConfig element in the previous frame is applied in the
current frame. If the useSameStreamMux bit indicates to use the current frame. If the useSameStreamMux bit indicates to use the
StreamMuxConfig from the previous frame, but if the previous frame StreamMuxConfig from the previous frame, but if the previous frame
has been lost, the current frame may not be decodable. Therefore, in has been lost, the current frame may not be decodable. Therefore, in
case of in-band mode, the StreamMuxConfig element SHOULD be case of in-band mode, the StreamMuxConfig element SHOULD be
transmitted repeatedly depending on the network condition. On the transmitted repeatedly depending on the network condition. On the
other hand, if muxConfigPresent is set to 0 (out-band mode), the other hand, if muxConfigPresent is set to 0 (out-band mode), the
StreamMuxConfig element is required to be transmitted by an out-of- StreamMuxConfig element is required to be transmitted by an out-of-
band means. In case of SDP, Media Type parameter "config" is band means. In case of SDP, Media Type parameter "config" is
utilized (see section 5.3). utilized (see Section 6.3).
4.2. Use of RTP Header Fields for MPEG-4 Audio 5.2. Use of RTP Header Fields for MPEG-4 Audio
Payload Type (PT): The assignment of an RTP payload type for this new Payload Type (PT): The assignment of an RTP payload type for this new
packet format is outside the scope of this document, and will not be packet format is outside the scope of this document, and will only be
specified here. It is expected that the RTP profile for a particular restricted here. It is expected that the RTP profile for a
class of applications will assign a payload type for this encoding, particular class of applications will assign a payload type for this
or if that is not done then a payload type in the dynamic range shall encoding, or if that is not done then a payload type in the dynamic
be chosen by means of an out-of-band signaling protocol (e.g., H.245, range shall be chosen by means of an out-of-band signaling protocol
SIP, etc). In the dynamic assignment of RTP payload types for (e.g., H.245, SIP, etc). In the dynamic assignment of RTP payload
scalable streams, a different value SHOULD be assigned to each layer. types for scalable streams, the server SHALL assign a different value
The dependency relationships between the enhance layer and the base to each layer. The dependency relationships between the enhance
layer SHOULD be signaled as specified in [RFC5583]. An example of layer and the base layer MUST be signaled as specified in [RFC5583].
the use of such signaling for scalable audio streams can be found in An example of the use of such signaling for scalable audio streams
[RFC5691]. can be found in [RFC5691].
Marker (M) bit: The marker bit indicates audioMuxElement boundaries. Marker (M) bit: The marker bit indicates audioMuxElement boundaries.
It is set to one to indicate that the RTP packet contains a complete It is set to one to indicate that the RTP packet contains a complete
audioMuxElement or the last fragment of an audioMuxElement. audioMuxElement or the last fragment of an audioMuxElement.
Timestamp: The timestamp indicates the sampling instance of the first Timestamp: The timestamp indicates the sampling instance of the first
audio frame contained in the RTP packet. Timestamps are recommended audio frame contained in the RTP packet. Timestamps are RECOMMENDED
to start at a random value for security reasons. to start at a random value for security reasons.
Unless specified by an out-of-band means, the resolution of the Unless specified by an out-of-band means, the resolution of the
timestamp is set to its default value of 90 kHz. timestamp is set to its default value of 90 kHz.
Sequence Number: Incremented by one for each RTP packet sent, Sequence Number: Incremented by one for each RTP packet sent,
starting, for security reasons, with a random value. starting, for security reasons, with a random value.
Other header fields are used as described in RFC 3550 [RFC3550]. Other header fields are used as described in [RFC3550].
4.3. Fragmentation of MPEG-4 Audio bitstream 5.3. Fragmentation of MPEG-4 Audio Bitstream
It is RECOMMENDED to put one audioMuxElement in each RTP packet. If It is RECOMMENDED to put one audioMuxElement in each RTP packet. If
the size of an audioMuxElement can be kept small enough that the size the size of an audioMuxElement can be kept small enough that the size
of the RTP packet containing it does not exceed the size of the path- of the RTP packet containing it does not exceed the size of the path-
MTU, this will be no problem. If it cannot, the audioMuxElement MAY MTU, this will be no problem. If it cannot, the audioMuxElement
be fragmented and spread across multiple packets. SHALL be fragmented and spread across multiple packets.
5. Media Type registration for MPEG-4 Audio/Visual streams 6. Media Type Registration for MPEG-4 Audio/Visual Streams
The following sections describe the Media Type registrations for The following sections describe the Media Type registrations for
MPEG-4 Audio/Visual streams, which are registered in accordance with MPEG-4 Audio/Visual streams, which are registered in accordance with
[RFC4855] and uses the template of [RFC4288]. Media Type [RFC4855] and uses the template of [RFC4288]. Media Type
registration and SDP usage for the MPEG-4 Visual stream are described registration and SDP usage for the MPEG-4 Visual stream are described
in Sections 5.1 and 5.2, respectively, while Media Type registration in Section 6.1 and Section 6.2, respectively, while Media Type
and SDP usage for MPEG-4 Audio stream are described in Sections 5.3 registration and SDP usage for MPEG-4 Audio stream are described in
and 5.4, respectively. Section 6.3 and Section 6.4, respectively.
5.1. Media Type registration for MPEG-4 Visual 6.1. Media Type Registration for MPEG-4 Visual
Note, any unspecified parameter MUST be ignored by the receiver to The receiver MUST ignore any unspecified parameter, to ensure that
ensure that additional parameters can be added in any future revision additional parameters can be added in any future revision of this
of this specification. specification.
Type name: video Type name: video
Subtype name: MP4V-ES Subtype name: MP4V-ES
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
rate: This parameter is used only for RTP transport. It indicates rate: This parameter is used only for RTP transport. It indicates
the resolution of the timestamp field in the RTP header. If this the resolution of the timestamp field in the RTP header. If this
parameter is not specified, its default value of 90000 (90kHz) is parameter is not specified, its default value of 90000 (90kHz) is
used. used.
profile-level-id: A decimal representation of MPEG-4 Visual profile-level-id: A decimal representation of MPEG-4 Visual
Profile and Level indication value (profile_and_level_indication) Profile and Level indication value (profile_and_level_indication)
defined in Table G-1 of ISO/IEC 14496-2 [14496-2]. This parameter defined in Table G-1 of [14496-2]. This parameter MAY be used in
MAY be used in the capability exchange or session setup procedure the capability exchange or session setup procedure to indicate
to indicate MPEG-4 Visual Profile and Level combination of which MPEG-4 Visual Profile and Level combination of which the MPEG-4
the MPEG-4 Visual codec is capable. If this parameter is not Visual codec is capable. If this parameter is not specified by
specified by the procedure, its default value of 1 (Simple the procedure, its default value of 1 (Simple Profile/Level 1) is
Profile/Level 1) is used. used.
config: This parameter SHALL be used to indicate the configuration config: This parameter SHALL be used to indicate the configuration
of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be
used to indicate the codec capability in the capability exchange used to indicate the codec capability in the capability exchange
procedure. It is a hexadecimal representation of an octet string procedure. It is a hexadecimal representation of an octet string
that expresses the MPEG-4 Visual configuration information, as that expresses the MPEG-4 Visual configuration information, as
defined in subclause 6.2.1 Start codes of ISO/IEC14496-2 defined in subclause 6.2.1 Start codes of [14496-2]. The
[14496-2]. The configuration information is mapped onto the octet configuration information is mapped onto the octet string in an
string in an MSB-first basis. The first bit of the configuration MSB-first basis. The first bit of the configuration information
information SHALL be located at the MSB of the first octet. The SHALL be located at the MSB of the first octet. The configuration
configuration information indicated by this parameter SHALL be the information indicated by this parameter SHALL be the same as the
same as the configuration information in the corresponding MPEG-4 configuration information in the corresponding MPEG-4 Visual
Visual stream, except for first_half_vbv_occupancy and stream, except for first_half_vbv_occupancy and
latter_half_vbv_occupancy, if exist, which may vary in the latter_half_vbv_occupancy, if exist, which may vary in the
repeated configuration information inside an MPEG-4 Visual stream repeated configuration information inside an MPEG-4 Visual stream
(See 6.2.1 Start codes of ISO/IEC14496-2). (See 6.2.1 Start codes of [14496-2]).
Published specification: Published specification:
The specifications for MPEG-4 Visual streams are presented in ISO/ The specifications for MPEG-4 Visual streams are presented in
IEC 14469-2 [14496-2]. The RTP payload format is described in RFC [14496-2]. The RTP payload format is described in this document.
XXXX.
Encoding considerations: Encoding considerations:
Video bitstreams MUST be generated according to MPEG-4 Visual Video bitstreams MUST be generated according to MPEG-4 Visual
specifications (ISO/IEC 14496-2). A video bitstream is binary specifications [14496-2]. A video bitstream is binary data and
data and MUST be encoded for non-binary transport (for Email, the MUST be encoded for non-binary transport (for Email, the Base64
Base64 encoding is sufficient). This type is also defined for encoding is sufficient). This type is also defined for transfer
transfer via RTP. The RTP packets MUST be packetized according to via RTP. The RTP packets MUST be packetized according to the
the MPEG-4 Visual RTP payload format defined in RFC XXXX. MPEG-4 Visual RTP payload format defined in this document.
Security considerations: Security considerations:
See section 7 of RFC XXXX. See Section 9 of this document.
Interoperability considerations: Interoperability considerations:
MPEG-4 Visual provides a large and rich set of tools for the MPEG-4 Visual provides a large and rich set of tools for the
coding of visual objects. For effective implementation of the coding of visual objects. For effective implementation of the
standard, subsets of the MPEG-4 Visual tool sets have been standard, subsets of the MPEG-4 Visual tool sets have been
provided for use in specific applications. These subsets, called provided for use in specific applications. These subsets, called
'Profiles', limit the size of the tool set a decoder is required 'Profiles', limit the size of the tool set a decoder is required
to implement. In order to restrict computational complexity, one to implement. In order to restrict computational complexity, one
or more Levels are set for each Profile. A Profile@Level or more Levels are set for each Profile. A Profile@Level
skipping to change at page 18, line 46 skipping to change at page 18, line 18
* a codec builder to implement only the subset of the standard he * 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
* checking whether MPEG-4 devices comply with the standard * 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 Interoperability between a sender and a receiver may be achieved
by specifying the parameter "profile-level-id", or by arranging in by specifying the parameter "profile-level-id", or by arranging a
the capability exchange/announcement procedure to set this capability exchange/announcement procedure for this parameter.
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 Audio and visual streaming and conferencing tools
Additional information: none Additional information: none
Person and email address to contact for further information: Person and email address to contact for further information:
See Authors' Address section at the end of this document. See Authors' Address section at the end of this document.
skipping to change at page 19, line 23 skipping to change at page 18, line 41
Intended usage: COMMON Intended usage: COMMON
Author: Author:
See Authors' Address section at the end of this document. See Authors' Address section at the end of this document.
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group delegated from the IESG.
5.2. Mapping to SDP for MPEG-4 Visual 6.2. Mapping to SDP for MPEG-4 Visual
The Media Type video/MP4V-ES string is mapped to fields in the The Media Type video/MP4V-ES string is mapped to fields in the
Session Description Protocol (SDP) [RFC4566], as follows: Session Description Protocol (SDP) [RFC4566], as follows:
o The Media Type (video) goes in SDP "m=" as the media name. o The Media Type (video) goes in SDP "m=" as the media name.
o The Media subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding o The Media subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding
name. name.
o The optional parameter "rate" goes in "a=rtpmap" as the clock o The optional parameter "rate" goes in "a=rtpmap" as the clock
skipping to change at page 19, line 46 skipping to change at page 19, line 18
o The optional parameter "profile-level-id" and "config" go in the o The optional parameter "profile-level-id" and "config" go in the
"a=fmtp" line to indicate the coder capability and configuration, "a=fmtp" line to indicate the coder capability and configuration,
respectively. These parameters are expressed as a string, in the respectively. These parameters are expressed as a string, in the
form of as a semicolon separated list of parameter=value pairs. form of as a semicolon separated list of parameter=value pairs.
Example usages for the profile-level-id parameter are: Example usages for the profile-level-id parameter are:
1 : MPEG-4 Visual Simple Profile/Level 1 1 : MPEG-4 Visual Simple Profile/Level 1
34 : MPEG-4 Visual Core Profile/Level 2 34 : MPEG-4 Visual Core Profile/Level 2
145: MPEG-4 Visual Advanced Real Time Simple Profile/Level 1 145: MPEG-4 Visual Advanced Real Time Simple Profile/Level 1
5.2.1. Declarative SDP usage for MPEG-4 Visual 6.2.1. Declarative SDP Usage for MPEG-4 Visual
The following are some examples of media representation in SDP: The following are some examples of media representation in SDP:
Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" and Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" and
"config" are present in "a=fmtp" line: "config" are present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98 m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=1;config=000001B001000001B50900000100000001 a=fmtp:98 profile-level-id=1;config=000001B001000001B50900000100000001
20008440FA282C2090A21F 20008440FA282C2090A21F
skipping to change at page 20, line 24 skipping to change at page 19, line 41
m=video 49170/2 RTP/AVP 98 m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=34 a=fmtp:98 profile-level-id=34
Advance Real Time Simple Profile/Level 1, rate=90000(90kHz), Advance Real Time Simple Profile/Level 1, rate=90000(90kHz),
"profile-level-id" is present in "a=fmtp" line: "profile-level-id" is present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98 m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=145 a=fmtp:98 profile-level-id=145
5.3. Media Type registration for MPEG-4 Audio 6.3. Media Type Registration for MPEG-4 Audio
Note, any unspecified parameter MUST be ignored by the receiver to The receiver MUST ignore any unspecified parameter, to ensure that
ensure that additional parameters can be added in any future revision additional parameters can be added in any future revision of this
of this specification. specification.
Type name: audio Type name: audio
Subtype name: MP4A-LATM Subtype name: MP4A-LATM
Required parameters: Required parameters:
rate: the rate parameter indicates the RTP time stamp clock rate. rate: the rate parameter indicates the RTP time stamp clock rate.
The default value is 90000. Other rates MAY be specified only if The default value is 90000. Other rates MAY be indicated only if
they are set to the same value as the audio sampling rate (number they are set to the same value as the audio sampling rate (number
of samples per second). of samples per second).
In the presence of SBR, the sampling rates for the core en-/ In the presence of SBR, the sampling rates for the core en-/
decoder and the SBR tool are different in most cases. This decoder and the SBR tool are different in most cases. This
parameter shall therefore not be considered as the definitive parameter SHALL therefore NOT be considered as the definitive
sampling rate. If this parameter is used, the server must sampling rate. If this parameter is used, the server must
following the rules below: following the rules below:
* When the presence of SBR is not explicitly signaled by the * When the presence of SBR is not explicitly signaled by the
optional SDP parameters such as object parameter, profile- optional SDP parameters such as object parameter, profile-
level-id or config string, this parameter shall be set to the level-id or config string, this parameter SHALL be set to the
core codec sampling rate. core codec sampling rate.
* When the presence of SBR is explicitly signaled by the optional * When the presence of SBR is explicitly signaled by the optional
SDP parameters such as object parameter, profile-level-id or SDP parameters such as object parameter, profile-level-id or
config string this parameter shall be set to the SBR sampling config string this parameter SHALL be set to the SBR sampling
rate. rate.
NOTE: The optional parameter SBR-enabled in SDP a=fmtp is useful NOTE: The optional parameter SBR-enabled in SDP a=fmtp is useful
for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled for implicit HE AAC / HE AAC v2 signaling. But the SBR-enabled
parameter can also be used in the case of explicit HE AAC / HE AAC parameter can also be used in the case of explicit HE AAC / HE AAC
v2 signaling. Therefore, its existence itself is not the criteria v2 signaling. Therefore, its existence itself is not the criteria
to determine whether HE AAC / HE AAC v2 signaling is explicit or to determine whether HE AAC / HE AAC v2 signaling is explicit or
not. not.
Optional parameters: Optional parameters:
profile-level-id: a decimal representation of MPEG-4 Audio Profile profile-level-id: a decimal representation of MPEG-4 Audio Profile
Level indication value defined in ISO/IEC 14496-3 [14496-3]. This Level indication value defined in [14496-3]. This parameter
parameter indicates which MPEG-4 Audio tool subsets the decoder is indicates which MPEG-4 Audio tool subsets the decoder is capable
capable of using. If this parameter is not specified in the of using. If this parameter is not specified in the capability
capability exchange or session setup procedure, its default value exchange or session setup procedure, its default value of 30
of 30 (Natural Audio Profile/Level 1) is used. (Natural Audio Profile/Level 1) is used.
MPS-profile-level-id: a decimal representation of the MPEG MPS-profile-level-id: a decimal representation of the MPEG
Surround Profile Level indication as defined in ISO/IEC 14496-3 Surround Profile Level indication as defined in [14496-3]. This
[14496-3]. This parameter indicates the MPEG Surround profile and parameter indicates the support of the MPEG Surround profile and
level that the decoder must be capable in order to decode the level by the decoder to be capable to decode the stream.
stream.
object: a decimal representation of the MPEG-4 Audio Object Type object: a decimal representation of the MPEG-4 Audio Object Type
value defined in ISO/IEC 14496-3 [14496-3]. This parameter value defined in [14496-3]. This parameter specifies the tool to
specifies the tool to be used by the coder. It CAN be used to be used by the decoder. It CAN be used to limit the capability
limit the capability within the specified "profile-level-id". within the specified "profile-level-id".
bitrate: the data rate for the audio bit stream. bitrate: the data rate for the audio bit stream.
cpresent: a boolean parameter indicates whether audio payload cpresent: a boolean parameter indicates whether audio payload
configuration data has been multiplexed into an RTP payload (see configuration data has been multiplexed into an RTP payload (see
section 4.1). A 0 indicates the configuration data has not been Section 5.1). A 0 indicates the configuration data has not been
multiplexed into an RTP payload, a 1 indicates that it has. The multiplexed into an RTP payload and in this case the "config"
default if the parameter is omitted is 1. parameter MUST be present, a 1 indicates that it has. The default
if the parameter is omitted is 1. If this parameter is set to 1
and the "config" parameter is present, the multiplexed
configuration data and the value of the "config" parameter SHALL
be consistent.
config: a hexadecimal representation of an octet string that config: a hexadecimal representation of an octet string that
expresses the audio payload configuration data "StreamMuxConfig", expresses the audio payload configuration data "StreamMuxConfig",
as defined in ISO/IEC 14496-3 [14496-3]. Configuration data is as defined in [14496-3]. Configuration data is mapped onto the
mapped onto the octet string in an MSB-first basis. The first bit octet string in an MSB-first basis. The first bit of the
of the configuration data SHALL be located at the MSB of the first configuration data SHALL be located at the MSB of the first octet.
octet. In the last octet, zero-padding bits, if necessary, SHALL In the last octet, zero-padding bits, if necessary, SHALL follow
follow the configuration data. Senders MUST set the the configuration data. Senders MUST set the StreamMuxConfig
StreamMuxConfig elements taraBufferFullness and latmBufferFullness elements taraBufferFullness and latmBufferFullness to their
to their largest respective value, indicating that buffer fullness largest respective value, indicating that buffer fullness measures
measures are not used in SDP. Receivers MUST ignore the value of are not used in SDP. Receivers MUST ignore the value of these two
these two elements contained in the config parameter. elements contained in the config parameter.
MPS-asc: a hexadecimal representation of an octet string that MPS-asc: a hexadecimal representation of an octet string that
expresses audio payload configuration data "AudioSpecificConfig", expresses audio payload configuration data "AudioSpecificConfig",
as defined in ISO/IEC 14496-3 [14496-3]. If this parameter is not as defined in [14496-3]. If this parameter is not present the
present the relevant signaling is performed by other means (e.g. relevant signaling is performed by other means (e.g. in-band or
in-band or contained in the config string). contained in the config string).
The same mapping rules as for the config parameter apply. The same mapping rules as for the config parameter apply.
ptime: RECOMMENDED duration of each packet in milliseconds. ptime: duration of each packet in milliseconds.
SBR-enabled: a boolean parameter which indicates whether SBR-data SBR-enabled: a boolean parameter which indicates whether SBR-data
can be expected in the RTP-payload of a stream. This parameter is can be expected in the RTP-payload of a stream. This parameter is
relevant for an SBR-capable decoder if the presence of SBR can not relevant for an SBR-capable decoder if the presence of SBR can not
be detected from an out-of-band decoder configuration (e.g. be detected from an out-of-band decoder configuration (e.g.
contained in the config string). contained in the config string).
If this parameter is set to 0, a decoder SHALL expect that SBR is If this parameter is set to 0, a decoder MAY expect that SBR is
not used. If this parameter is set to 1, a decoder SHOULD not used. If this parameter is set to 1, a decoder CAN upsample
upsample the audio data with the SBR tool, regardless whether SBR the audio data with the SBR tool, regardless whether SBR data is
data is present in the stream or not. present in the stream or not.
If the presence of SBR can not be detected from out-of-band If the presence of SBR can not be detected from out-of-band
configuration and the SBR-enabled parameter is not present, the configuration and the SBR-enabled parameter is not present, the
parameter defaults to 1 for an SBR-capable decoder. If the parameter defaults to 1 for an SBR-capable decoder. If the
resulting output sampling rate or the computational complexity is resulting output sampling rate or the computational complexity is
not supported, the SBR tool may be disabled or run in downsampled not supported, the SBR tool can be disabled or run in downsampled
mode. mode.
The timestamp resolution at RTP layer is determined by the rate The timestamp resolution at RTP layer is determined by the rate
parameter. parameter.
Published specification: Published specification:
Encoding specifications are provided in ISO/IEC 14496-3 [14496-3]. Encoding specifications are provided in [14496-3]. The RTP
The RTP payload format specification is described in RFC XXXX. payload format specification is described in this document.
Encoding considerations: Encoding considerations:
This type is only defined for transfer via RTP. This type is only defined for transfer via RTP.
Security considerations: Security considerations:
See Section 7 of RFC XXXX. See Section 9 of this document.
Interoperability considerations: Interoperability considerations:
MPEG-4 Audio provides a large and rich set of tools for the coding MPEG-4 Audio provides a large and rich set of tools for the coding
of audio objects. For effective implementation of the standard, of audio objects. For effective implementation of the standard,
subsets of the MPEG-4 Audio tool sets similar to those used in subsets of the MPEG-4 Audio tool sets similar to those used in
MPEG-4 Visual have been provided (see section 5.1). MPEG-4 Visual have been provided (see Section 6.1).
The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ The audio stream SHALL be compliant with the MPEG-4 Audio Profile@
Level specified by the parameters "profile-level-id" and "MPS- Level specified by the parameters "profile-level-id" and "MPS-
profile-level-id". Interoperability between a sender and a profile-level-id". Interoperability between a sender and a
receiver may be achieved by specifying the parameters "profile- receiver may be achieved by specifying the parameters "profile-
level-id" and "MPS-profile-level-id", or by arranging in the level-id" and "MPS-profile-level-id", or by arranging in the
capability exchange procedure to set this parameter mutually to capability exchange procedure to set this parameter mutually to
the same value. Furthermore, the "object" parameter can be used the same value. Furthermore, the "object" parameter can be used
to limit the capability within the specified Profile@Level in to limit the capability within the specified Profile@Level in
capability exchange. capability exchange.
skipping to change at page 23, line 33 skipping to change at page 23, line 4
Audio and video streaming and conferencing tools. Audio and video streaming and conferencing tools.
Additional information: none Additional information: none
Personal and email address to contact for further information: Personal and email address to contact for further information:
See Authors' Address section at the end of this document. See Authors' Address section at the end of this document.
Intended usage: COMMON Intended usage: COMMON
Author: Author:
See Authors' Address section at the end of this document. See Authors' Address section at the end of this document.
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group delegated from the IESG.
5.4. Mapping to SDP for MPEG-4 Audio 6.4. Mapping to SDP for MPEG-4 Audio
The Media Type audio/MP4A-LATM string is mapped to fields in the The Media Type audio/MP4A-LATM string is mapped to fields in the
Session Description Protocol (SDP) [RFC4566], as follows: Session Description Protocol (SDP) [RFC4566], as follows:
o The Media Type (audio) goes in SDP "m=" as the media name. o The Media Type (audio) goes in SDP "m=" as the media name.
o The Media subtype (MP4A-LATM) goes in SDP "a=rtpmap" as the o The Media subtype (MP4A-LATM) goes in SDP "a=rtpmap" as the
encoding name. encoding name.
o The required parameter "rate" goes in "a=rtpmap" as the clock o The required parameter "rate" goes in "a=rtpmap" as the clock
skipping to change at page 24, line 28 skipping to change at page 23, line 45
30: Natural Audio Profile Level 1 30: Natural Audio Profile Level 1
44: High Efficiency AAC Profile Level 2 44: High Efficiency AAC Profile Level 2
48: High Efficiency AAC v2 Profile Level 2 48: High Efficiency AAC v2 Profile Level 2
55: Baseline MPEG Surround Profile (see ISO/IEC 23003-1) Level 3 55: Baseline MPEG Surround Profile (see ISO/IEC 23003-1) Level 3
The optional payload-format-specific parameters "bitrate", The optional payload-format-specific parameters "bitrate",
"cpresent", "config", "MPS-asc" and "SBR-enabled" go also in the "cpresent", "config", "MPS-asc" and "SBR-enabled" go also in the
"a=fmtp" line. These parameters are expressed as a string, in the "a=fmtp" line. These parameters are expressed as a string, in the
form of as a semicolon separated list of parameter=value pairs. form of as a semicolon separated list of parameter=value pairs.
5.4.1. Declarative SDP usage for MPEG-4 Audio 6.4.1. Declarative SDP Usage for MPEG-4 Audio
The following sections contain some examples of the media The following sections contain some examples of the media
representation in SDP. representation in SDP.
Note that the a=fmtp line in some of the examples has been wrapped to Note that the a=fmtp line in some of the examples has been wrapped to
fit the page; they would comprise a single line in the SDP file. fit the page; they would comprise a single line in the SDP file.
5.4.1.1. Example: In-band configuration 6.4.1.1. Example: In-band Configuration
In this example the audio configuration data appears in the RTP In this example the audio configuration data appears in the RTP
payload exclusively (i.e., the MPEG-4 audio configuration is known payload exclusively (i.e., the MPEG-4 audio configuration is known
when a StreamMuxConfig element appears within the RTP payload). when a StreamMuxConfig element appears within the RTP payload).
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/90000 a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 object=2; cpresent=1 a=fmtp:96 object=2; cpresent=1
The "clock rate" is set to 90kHz. This is the default value and the The "clock rate" is set to 90kHz. This is the default value and the
real audio sampling rate is known when the audio configuration data real audio sampling rate is known when the audio configuration data
is received. is received.
5.4.1.2. Example: 6kb/s CELP 6.4.1.2. Example: 6kb/s CELP
6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz) 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-LATM/8000 a=rtpmap:96 MP4A-LATM/8000
a=fmtp:96 profile-level-id=9; object=8; cpresent=0; a=fmtp:96 profile-level-id=9; object=8; cpresent=0;
config=40008B18388380 config=40008B18388380
a=ptime:20 a=ptime:20
In this example audio configuration data is not multiplexed into the In this example audio configuration data is not multiplexed into the
RTP payload and is described only in SDP. Furthermore, the "clock RTP payload and is described only in SDP. Furthermore, the "clock
rate" is set to the audio sampling rate. rate" is set to the audio sampling rate.
5.4.1.3. Example: 64 kb/s AAC LC stereo 6.4.1.3. Example: 64 kb/s AAC LC Stereo
64 kb/s AAC LC stereo bitstream (with an audio sampling rate of 24 64 kb/s AAC LC stereo bitstream (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-LATM/24000/2 a=rtpmap:96 MP4A-LATM/24000/2
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
object=2; config=400026203fc0 object=2; config=400026203fc0
In this example audio configuration data is not multiplexed into the In this example audio configuration data is not multiplexed into the
RTP payload and is described only in SDP. Furthermore, the "clock RTP payload and is described only in SDP. Furthermore, the "clock
rate" is set to the audio sampling rate. rate" is set to the audio sampling rate.
In this example, the presence of SBR can not be determined by the SDP In this example, the presence of SBR can not be determined by the SDP
parameter set. The clock rate represents the core codec sampling parameter set. The clock rate represents the core codec sampling
rate. An SBR enabled decoder SHOULD use the SBR tool to upsample the rate. An SBR enabled decoder can use the SBR tool to upsample the
audio data if complexity and resulting output sampling rate permits. audio data if complexity and resulting output sampling rate permits.
5.4.1.4. Example: Use of the SBR-enabled parameter 6.4.1.4. Example: Use of the SBR-enabled Parameter
These two examples are identical to the example above with the These two examples are identical to the example above with the
exception of the SBR-enabled parameter. The presence of SBR is not exception of the SBR-enabled parameter. The presence of SBR is not
signaled by the SDP parameters object, profile-level-id and config, signaled by the SDP parameters object, profile-level-id and config,
but instead the SBR-enabled parameter is present. The rate parameter but instead the SBR-enabled parameter is present. The rate parameter
and the StreamMuxConfig contain the core codec sampling rate. and the StreamMuxConfig contain the core codec sampling rate.
Example with "SBR-enabled=0", definitive and core codec sampling rate Example with "SBR-enabled=0", definitive and core codec sampling rate
24kHz: 24kHz:
skipping to change at page 26, line 14 skipping to change at page 25, line 30
Example with "SBR-enabled=1", core codec sampling rate 24kHz, Example with "SBR-enabled=1", core codec sampling rate 24kHz,
definitive and SBR sampling rate 48kHz: definitive and SBR sampling rate 48kHz:
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000/2 a=rtpmap:96 MP4A-LATM/24000/2
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
SBR-enabled=1; config=400026203fc0 SBR-enabled=1; config=400026203fc0
In this example, the clock rate is still 24000 and this information In this example, the clock rate is still 24000 and this information
should be used for RTP timestamp calculation. The value of 24000 is is used for RTP timestamp calculation. The value of 24000 is used to
used to support old AAC decoders. This makes the decoder supporting support old AAC decoders. This makes the decoder supporting only AAC
only AAC understand the HE AAC coded data, although only plain AAC is understand the HE AAC coded data, although only plain AAC is
supported. A HE AAC decoder is able to generate output data with the supported. A HE AAC decoder is able to generate output data with the
SBR sampling rate. SBR sampling rate.
5.4.1.5. Example: Hierarchical Signaling of SBR 6.4.1.5. Example: Hierarchical Signaling of SBR
When the presence of SBR is explicitly signaled by the SDP parameters When the presence of SBR is explicitly signaled by the SDP parameters
object, profile-level-id or the config string as in the example object, profile-level-id or the config string as in the example
below, the StreamMuxConfig contains both the core codec sampling rate below, the StreamMuxConfig contains both the core codec sampling rate
and the SBR sampling rate. and the SBR sampling rate.
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000/2 a=rtpmap:96 MP4A-LATM/48000/2
a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0;
config=40005623101fe0; SBR-enabled=1 config=40005623101fe0; SBR-enabled=1
This config string uses the explicit signaling mode 2.A (hierarchical This config string uses the explicit signaling mode 2.A (hierarchical
signaling; See ISO/IEC 14496-3 [14496-3]). This means that the signaling; See [14496-3]. This means that the AOT(Audio Object Type)
AOT(Audio Object Type) is SBR(5) and SFI(Sampling Frequency Index) is is SBR(5) and SFI(Sampling Frequency Index) is 6(24000 Hz) which
6(24000 Hz) which refers to the underlying core codec sampling refers to the underlying core codec sampling frequency. CC(Channel
frequency. CC(Channel Configuration) is stereo(2), and the Configuration) is stereo(2), and the ESFI(Extension Sampling
ESFI(Extension Sampling Frequency Index)=3 (48000) is referring to Frequency Index)=3 (48000) is referring to the sampling frequency of
the sampling frequency of the extension tool(SBR). the extension tool(SBR).
5.4.1.6. Example: HE AAC v2 Signaling 6.4.1.6. Example: HE AAC v2 Signaling
HE AAC v2 decoders are required to always produce a stereo signal HE AAC v2 decoders are required to always produce a stereo signal
from a mono signal. Hence, there is no parameter necessary to signal from a mono signal. Hence, there is no parameter necessary to signal
the presence of PS. the presence of PS.
Example with "SBR-enabled=1" and 1 channel signaled in the a=rtpmap Example with "SBR-enabled=1" and 1 channel signaled in the a=rtpmap
line and within the config parameter. Core codec sampling rate is line and within the config parameter. Core codec sampling rate is
24kHz, definitive and SBR sampling rate is 48kHz. Core codec channel 24kHz, definitive and SBR sampling rate is 48kHz. Core codec channel
configuration is mono, PS channel configuration is stereo. configuration is mono, PS channel configuration is stereo.
m=audio 49230 RTP/AVP 110 m=audio 49230 RTP/AVP 110
a=rtpmap:110 MP4A-LATM/24000/1 a=rtpmap:110 MP4A-LATM/24000/1
a=fmtp:110 profile-level-id=15; object=2; cpresent=0; a=fmtp:110 profile-level-id=15; object=2; cpresent=0;
config=400026103fc0; SBR-enabled=1 config=400026103fc0; SBR-enabled=1
5.4.1.7. Example: Hierarchical Signaling of PS 6.4.1.7. Example: Hierarchical Signaling of PS
Example: 48khz stereo audio input: Example: 48khz stereo audio input:
m=audio 49230 RTP/AVP 110 m=audio 49230 RTP/AVP 110
a=rtpmap:110 MP4A-LATM/48000/2 a=rtpmap:110 MP4A-LATM/48000/2
a=fmtp:110 profile-level-id=48; cpresent=0; config=4001d613101fe0 a=fmtp:110 profile-level-id=48; cpresent=0; config=4001d613101fe0
The config parameter indicates explicit hierarchical signaling of PS The config parameter indicates explicit hierarchical signaling of PS
and SBR. This configuration method is not supported by legacy AAC an and SBR. This configuration method is not supported by legacy AAC an
HE AAC decoders and these are therefore unable to decode the the HE AAC decoders and these are therefore unable to decode the the
coded data. coded data.
5.4.1.8. Example: MPEG Surround 6.4.1.8. Example: MPEG Surround
The following examples show how MPEG Surround configuration data can The following examples show how MPEG Surround configuration data can
be signaled using SDP. The configuration is carried within the be signaled using SDP. The configuration is carried within the
config string in the first example by using two different layers. config string in the first example by using two different layers.
The general parameters in this example are: AudioMuxVersion=1; The general parameters in this example are: AudioMuxVersion=1;
allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0; allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0;
numLayer=1. The first layer describes the HE AAC payload and signals numLayer=1. The first layer describes the HE AAC payload and signals
the following parameters: ascLen=25; audioObjectType=2 (AAC LC); the following parameters: ascLen=25; audioObjectType=2 (AAC LC);
extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=6 (24kHz); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=6 (24kHz);
extensionSamplingFrequencyIndex=3 (48kHz); channelConfiguration=2 extensionSamplingFrequencyIndex=3 (48kHz); channelConfiguration=2
skipping to change at page 28, line 5 skipping to change at page 27, line 17
layers. The MPEG surround payload is carried together with the AAC layers. The MPEG surround payload is carried together with the AAC
payload in a single layer as indicated by the sacPayloadEmbedding payload in a single layer as indicated by the sacPayloadEmbedding
Flag. Flag.
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000 a=rtpmap:96 MP4A-LATM/48000
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
SBR-enabled=1; SBR-enabled=1;
config=8FF8004192B11880FF0DDE3699F2408C00536C02313CF3CE0FF0 config=8FF8004192B11880FF0DDE3699F2408C00536C02313CF3CE0FF0
5.4.1.9. Example: MPEG Surround with extended SDP parameters 6.4.1.9. Example: MPEG Surround with Extended SDP Parameters
The following example is an extension of the configuration given The following example is an extension of the configuration given
above by the MPEG Surround specific parameters. The MPS-asc above by the MPEG Surround specific parameters. The MPS-asc
parameter specifies the MPEG Surround Baseline Profile at Level 3 parameter specifies the MPEG Surround Baseline Profile at Level 3
(PLI55) and the MPS-asc string contains the hexadecimal (PLI55) and the MPS-asc string contains the hexadecimal
representation of the MPEG Surround ASC [audioObjectType=30 (MPEG representation of the MPEG Surround ASC [audioObjectType=30 (MPEG
Surround); samplingFrequencyIndex=0x3 (48kHz); channelConfiguration=6 Surround); samplingFrequencyIndex=0x3 (48kHz); channelConfiguration=6
(5.1 channels); sacPayloadEmbedding=1; SpatialSpecificConfig=(48 kHz; (5.1 channels); sacPayloadEmbedding=1; SpatialSpecificConfig=(48 kHz;
32 slots; 525 tree; ResCoding=1; ResBands=[0,13,13,13])]. 32 slots; 525 tree; ResCoding=1; ResBands=[0,13,13,13])].
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/48000 a=rtpmap:96 MP4A-LATM/48000
a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0;
config=40005623101fe0; MPS-profile-level-id=55; config=40005623101fe0; MPS-profile-level-id=55;
MPS-asc=F1B4CF920442029B501185B6DA00; MPS-asc=F1B4CF920442029B501185B6DA00;
5.4.1.10. Example: MPEG Surround with single layer configuration 6.4.1.10. Example: MPEG Surround with Single Layer Configuration
The following example shows how MPEG Surround configuration data can The following example shows how MPEG Surround configuration data can
be signaled using the SDP config parameter. The configuration is be signaled using the SDP config parameter. The configuration is
carried within the config string using a single layer. The general carried within the config string using a single layer. The general
parameters in this example are: AudioMuxVersion=1; parameters in this example are: AudioMuxVersion=1;
allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0; allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0;
numLayer=0. The single layer describes the combination of HE AAC and numLayer=0. The single layer describes the combination of HE AAC and
MPEG Surround payload and signals the following parameters: MPEG Surround payload and signals the following parameters:
ascLen=101; audioObjectType=2 (AAC LC); extensionAudioObjectType=5 ascLen=101; audioObjectType=2 (AAC LC); extensionAudioObjectType=5
(SBR); samplingFrequencyIndex=7 (22.05kHz); (SBR); samplingFrequencyIndex=7 (22.05kHz);
skipping to change at page 29, line 5 skipping to change at page 28, line 13
In this example the signaling is carried by using a single LATM In this example the signaling is carried by using a single LATM
layer. The MPEG surround payload is carried together with the HE AAC layer. The MPEG surround payload is carried together with the HE AAC
payload in a single layer. payload in a single layer.
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/44100 a=rtpmap:96 MP4A-LATM/44100
a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0;
SBR-enabled=1; config=8FF8000652B920876A83A1F440884053620FF0; SBR-enabled=1; config=8FF8000652B920876A83A1F440884053620FF0;
MPS-profile-level-id=55 MPS-profile-level-id=55
6. IANA Considerations 7. IANA Considerations
This memo defines additional optional format parameters to the Media
Type "audio" and its subtype "MP4A-LATM", as defined in RFC XXXX.
The Media Type parameters are defined in sections 5.1 and 5.3 of RFC
XXXX.
6.1. Media Type Registration
This memo defines the following additional optional parameters which
SHOULD be used if SBR or MPEG Surround data is present inside the
payload of an AAC elementary stream.
MPS-profile-level-id: a decimal representation of the MPEG
Surround Profile Level indication as defined in ISO/IEC 14496-3
[14496-3]. This parameter indicates the MPEG Surround profile and
level that the decoder must be capable in order to decode the
stream.
MPS-asc: a hexadecimal representation of an octet string that
expresses audio payload configuration data "AudioSpecificConfig",
as defined in ISO/IEC 14496-3 [14496-3]. If this parameter is not
present the relevant signaling is performed by other means (e.g.
in-band or contained in the config string).
SBR-enabled: a boolean parameter which indicates whether SBR-data This document updates the media subtypes "MP4A-LATM" and "MP4V-ES"
can be expected in the RTP-payload of a stream. This parameter is from RFC 3016. The new registrations are in Section 6.1 and
relevant for an SBR-capable decoder if the presence of SBR can not Section 6.3 of this document.
be detected from an out-of-band decoder configuration (e.g.
contained in the config string).
6.2. Usage of SDP 8. Acknowledgements
It is assumed that the Media Type parameters are conveyed via an SDP The authors would like to thank Yoshihiro Kikuchi, Yoshinori Matsui,
message as specified in sections 5.2 and 5.4. Toshiyuki Nomura, Shigeru Fukunaga and Hideaki Kimata for their work
on RFC 3016, and Ali Begen, Keith Drage, Roni Even and Qin Wu for
their valuable input and comments on this document.
7. Security Considerations 9. 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 [RFC3550]. This implies that confidentiality of the specification [RFC3550], and in any applicable RTP profile. The main
media streams is achieved by encryption. Because the data security considerations for the RTP packet carrying the RTP payload
compression used with this payload format is applied end-to-end, format defined within this document are confidentiality, integrity,
encryption may be performed on the compressed data so there is no and source authenticity. Confidentiality is achieved by encryption
conflict between the two operations. of the RTP payload, and integrity of the RTP packets through a
suitable cryptographic integrity protection mechanism. A
cryptographic system may also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at
least source authentication capable of determining whether or not an
RTP packet is from a member of the RTP session.
Note that most MPEG-4 codecs define an extension mechanism to
transmit extra data within a stream that is gracefully skipped by
decoders that do not support this extra data. This covert channel
may be used to transmit unwanted data in an otherwise valid stream.
The appropriate mechanism to provide security to RTP and payloads
following this may vary. It is dependent on the application, the
transport, and the signaling protocol employed. Therefore, a single
mechanism is not sufficient, although if suitable, the usage of the
Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended.
Other mechanisms that may be used are IPsec [RFC4301] and Transport
Layer Security (TLS) [RFC5246] (e.g., for RTP over TCP), but other
alternatives may also exist.
This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data.
The complete MPEG-4 system allows for transport of a wide range of The complete MPEG-4 system allows for transport of a wide range of
content, including Java applets (MPEG-J) and scripts. Since this content, including Java applets (MPEG-J) and scripts. Since this
payload format is restricted to audio and video streams, it is not payload format is restricted to audio and video streams, it is not
possible to transport such active content in this format. possible to transport such active content in this format.
Most MPEG-4 codecs define an extension mechanism to transmit extra 10. Differences to RFC 3016
data within a stream that is gracefully skipped by decoders that do
not support this extra data. This covert channel may be used to
transmit unwanted data in an otherwise valid stream and it is hence
recommended to use SRTP [RFC3711] for stream encryption,
authentication, and integrity check.
8. References The RTP payload format for MPEG-4 Audio as specified in RFC 3016 is
used by the 3GPP PSS service [3GPP]. However, there are some
misalignments between RFC 3016 and the 3GPP PSS specification that
are addressed by this update:
8.1. Normative References o The audio payload format (LATM) referenced in this document is
binary compatible to the format used in [3GPP].
o The audio signaling format (StreamMuxConfig) referenced in this
document is binary compatible to the format used in [3GPP].
o The use of an audio parameter "SBR-enabled" is now defined in this
document, which is used by 3GPP implementations [3GPP].
o The rate parameter is defined unambiguously in this document for
the case of presence of SBR (Spectral Band Replication)
o The number of audio channels parameter is defined unambiguously in
this document for the case of presence of PS (Parametric Stereo)
Furthermore some comments have been addressed and signaling support
for MPEG surround [23003-1] was added.
11. References
11.1. Normative References
[14496-2] MPEG, "ISO/IEC International Standard 14496-2 - Coding of [14496-2] MPEG, "ISO/IEC International Standard 14496-2 - Coding of
audio-visual objects, Part 2: Visual", 2003. audio-visual objects, Part 2: Visual", 2003.
[14496-3] MPEG, "ISO/IEC International Standard 14496-3 - Coding of [14496-3] MPEG, "ISO/IEC International Standard 14496-3 - Coding of
audio-visual objects, Part 3 Audio", 2009. audio-visual objects, Part 3 Audio", 2009.
[14496-3/Amd.1] [14496-3/Amd.1]
MPEG, "ISO/IEC International Standard 14496-3 - Coding of MPEG, "ISO/IEC International Standard 14496-3 - Coding of
audio-visual objects, Part 3: Audio, Amendment 1: HD-AAC audio-visual objects, Part 3: Audio, Amendment 1: HD-AAC
skipping to change at page 31, line 15 skipping to change at page 30, line 44
Even, "RTP Payload Format for ITU-T Rec", RFC 4629, Even, "RTP Payload Format for ITU-T Rec", RFC 4629,
January 2007. January 2007.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009. RFC 5583, July 2009.
8.2. Informative References 11.2. Informative References
[14496-1] MPEG, "ISO/IEC International Standard 14496-1 - Coding of [14496-1] MPEG, "ISO/IEC International Standard 14496-1 - Coding of
audio-visual objects, Part 1 Systems", 2004. audio-visual objects, Part 1 Systems", 2004.
[14496-12] [14496-12]
MPEG, "ISO/IEC International Standard 14496-12 - Coding of MPEG, "ISO/IEC International Standard 14496-12 - Coding of
audio-visual objects, Part 12 ISO base media file format". audio-visual objects, Part 12 ISO base media file format".
[14496-14] [14496-14]
MPEG, "ISO/IEC International Standard 14496-14 - Coding of MPEG, "ISO/IEC International Standard 14496-14 - Coding of
audio-visual objects, Part 12 MP4 file format". audio-visual objects, Part 12 MP4 file format".
[3GPP] 3GPP, "3rd Generation Partnership Project; Technical [3GPP] 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; Specification Group Services and System Aspects;
Transparent end-to-end Packet-switched Streaming Service Transparent end-to-end Packet-switched Streaming Service
(PSS); Protocols and codecs (Release 8)", 3GPP TS 24.234 (PSS); Protocols and codecs (Release 9)", 3GPP TS 26.234
V8.0.0, September 2008. V9.5.0, December 2010.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
and P. Gentric, "RTP Payload Format for Transport of and P. Gentric, "RTP Payload Format for Transport of
MPEG-4 Elementary Streams", RFC 3640, November 2003. MPEG-4 Elementary Streams", RFC 3640, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to [RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to
Historic Status", RFC 4628, January 2007. Historic Status", RFC 4628, January 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5691] de Bont, F., Doehla, S., Schmidt, M., and R. [RFC5691] de Bont, F., Doehla, S., Schmidt, M., and R.
Sperschneider, "RTP Payload Format for Elementary Streams Sperschneider, "RTP Payload Format for Elementary Streams
with MPEG Surround Multi-Channel Audio", RFC 5691, with MPEG Surround Multi-Channel Audio", RFC 5691,
October 2009. October 2009.
Authors' Addresses Authors' Addresses
Malte Schmidt Malte Schmidt
Dolby Laboratories Dolby Laboratories
Deutschherrnstr. 15-19 Deutschherrnstr. 15-19
 End of changes. 109 change blocks. 
359 lines changed or deleted 355 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/