Internet Engineering Task Force (IETF) M. Schmidt Request for Comments: 6416 Dolby Laboratories Obsoletes: 3016 F. de Bont Category: Standards Track Philips Electronics ISSN: 2070-1721 S. Doehla Fraunhofer IIS J. Kim LG Electronics Inc. October 2011 Internet Engineering Task Force (IETF) M. Schmidt Request for Comments: 6416 Dolby Laboratories Obsoletes: 3016 F. de Bont Category: Standards Track Philips Electronics ISSN: 2070-1721 S. Doehla Fraunhofer IIS J. Kim LG Electronics Inc. October 2011 This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet-switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. MPEG-4 Visual RTP Payload Format . . . . . . . . . . . . . 4 1.2. MPEG-4 Audio RTP Payload Format . . . . . . . . . . . . . 5 1.3. Interoperability with RFC 3016 . . . . . . . . . . . . . . 6 1.4. Relation with RFC 3640 . . . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 3. Clarifications on Specifying Codec Configurations for MPEG-4 Audio . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. LATM Restrictions for RTP Packetization of MPEG-4 Audio Bitstreams . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. RTP Packetization of MPEG-4 Visual Bitstreams . . . . . . . . 8 5.1. Use of RTP Header Fields for MPEG-4 Visual . . . . . . . . 9 5.2. Fragmentation of MPEG-4 Visual Bitstream . . . . . . . . . 10 5.3. Examples of Packetized MPEG-4 Visual Bitstream . . . . . . 11 6. RTP Packetization of MPEG-4 Audio Bitstreams . . . . . . . . . 15 6.1. RTP Packet Format . . . . . . . . . . . . . . . . . . . . 15 6.2. Use of RTP Header Fields for MPEG-4 Audio . . . . . . . . 16 6.3. Fragmentation of MPEG-4 Audio Bitstream . . . . . . . . . 17 7. Media Type Registration for MPEG-4 Audio/Visual Streams . . . 17 7.1. Media Type Registration for MPEG-4 Visual . . . . . . . . 17 7.2. Mapping to SDP for MPEG-4 Visual . . . . . . . . . . . . . 20 7.2.1. Declarative SDP Usage for MPEG-4 Visual . . . . . . . 20 7.3. Media Type Registration for MPEG-4 Audio . . . . . . . . . 21 7.4. Mapping to SDP for MPEG-4 Audio . . . . . . . . . . . . . 24 7.4.1. Declarative SDP Usage for MPEG-4 Audio . . . . . . . . 25 7.4.1.1. Example: In-Band Configuration . . . . . . . . . . 25 7.4.1.2. Example: 6 kbit/s CELP . . . . . . . . . . . . . . 25 7.4.1.3. Example: 64 kbit/s AAC LC Stereo . . . . . . . . . 26 7.4.1.4. Example: Use of the "SBR-enabled" Parameter . . . 26 7.4.1.5. Example: Hierarchical Signaling of SBR . . . . . . 27 7.4.1.6. Example: HE AAC v2 Signaling . . . . . . . . . . . 27 7.4.1.7. Example: Hierarchical Signaling of PS . . . . . . 28 7.4.1.8. Example: MPEG Surround . . . . . . . . . . . . . . 28 7.4.1.9. Example: MPEG Surround with Extended SDP Parameters . . . . . . . . . . . . . . . . . . . . 28 7.4.1.10. Example: MPEG Surround with Single-Layer Configuration . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Differences to RFC 3016 . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. MPEG-4 Visual RTP Payload Format . . . . . . . . . . . . . 4 1.2. MPEG-4 Audio RTP Payload Format . . . . . . . . . . . . . 5 1.3. Interoperability with RFC 3016 . . . . . . . . . . . . . . 6 1.4. Relation with RFC 3640 . . . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 3. Clarifications on Specifying Codec Configurations for MPEG-4 Audio . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. LATM Restrictions for RTP Packetization of MPEG-4 Audio Bitstreams . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. RTP Packetization of MPEG-4 Visual Bitstreams . . . . . . . . 8 5.1. Use of RTP Header Fields for MPEG-4 Visual . . . . . . . . 9 5.2. Fragmentation of MPEG-4 Visual Bitstream . . . . . . . . . 10 5.3. Examples of Packetized MPEG-4 Visual Bitstream . . . . . . 11 6. RTP Packetization of MPEG-4 Audio Bitstreams . . . . . . . . . 15 6.1. RTP Packet Format . . . . . . . . . . . . . . . . . . . . 15 6.2. Use of RTP Header Fields for MPEG-4 Audio . . . . . . . . 16 6.3. Fragmentation of MPEG-4 Audio Bitstream . . . . . . . . . 17 7. Media Type Registration for MPEG-4 Audio/Visual Streams . . . 17 7.1. Media Type Registration for MPEG-4 Visual . . . . . . . . 17 7.2. Mapping to SDP for MPEG-4 Visual . . . . . . . . . . . . . 20 7.2.1. Declarative SDP Usage for MPEG-4 Visual . . . . . . . 20 7.3. Media Type Registration for MPEG-4 Audio . . . . . . . . . 21 7.4. Mapping to SDP for MPEG-4 Audio . . . . . . . . . . . . . 24 7.4.1. Declarative SDP Usage for MPEG-4 Audio . . . . . . . . 25 7.4.1.1. Example: In-Band Configuration . . . . . . . . . . 25 7.4.1.2. Example: 6 kbit/s CELP . . . . . . . . . . . . . . 25 7.4.1.3. Example: 64 kbit/s AAC LC Stereo . . . . . . . . . 26 7.4.1.4. Example: Use of the "SBR-enabled" Parameter . . . 26 7.4.1.5. Example: Hierarchical Signaling of SBR . . . . . . 27 7.4.1.6. Example: HE AAC v2 Signaling . . . . . . . . . . . 27 7.4.1.7. Example: Hierarchical Signaling of PS . . . . . . 28 7.4.1.8. Example: MPEG Surround . . . . . . . . . . . . . . 28 7.4.1.9. Example: MPEG Surround with Extended SDP Parameters . . . . . . . . . . . . . . . . . . . . 28 7.4.1.10. Example: MPEG Surround with Single-Layer Configuration . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Differences to RFC 3016 . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 These RTP payload formats enable transport of MPEG-4 Audio/Visual streams without using the synchronization and stream management functionality of MPEG-4 Systems [14496-1]. Such RTP payload formats will be used in systems that have intrinsic stream management functionality and thus require no such functionality from MPEG-4 Systems. H.323 [H323] terminals are an example of such systems, where MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors but by H.245 [H245]. The streams are directly mapped onto RTP packets without using the MPEG-4 Systems Sync Layer. Other examples are the Session Initiation Protocol (SIP) [RFC3261] and Real Time Streaming Protocol (RTSP) where media type and SDP are used. Media type and SDP usages of the RTP payload formats described in this document are defined to directly specify the attribute of Audio/Visual streams (e.g., media type, packetization format, and codec configuration) without using MPEG-4 Systems. The obvious benefit is that these MPEG-4 Audio/Visual RTP payload formats can be handled in a unified way together with those formats defined for non-MPEG-4 codecs. The disadvantage is that interoperability with environments using MPEG-4 Systems may be difficult; hence, other payload formats may be better suited to those applications. 这些RTP有效载荷格式能够在不使用MPEG-4系统的同步和流管理功能的情况下传输MPEG-4音频/视频流[14496-1]。此类RTP有效载荷格式将用于具有内在流管理功能的系统中，因此不需要来自MPEG-4系统的此类功能。H.323[H323]终端是此类系统的一个示例，其中MPEG-4音频/视频流不是由MPEG-4系统对象描述符管理的，而是由H.245[H245]管理的。流直接映射到RTP数据包，而不使用MPEG-4系统同步层。其他示例包括会话启动协议（SIP）[RFC3261]和实时流协议（RTSP），其中使用了媒体类型和SDP。本文档中描述的RTP有效负载格式的媒体类型和SDP使用被定义为直接指定音频/视频流的属性（例如，媒体类型、打包格式和编解码器配置），而不使用MPEG-4系统。明显的好处是，这些MPEG-4音频/视频RTP有效负载格式可以与为非MPEG-4编解码器定义的格式一起以统一的方式处理。缺点是与使用MPEG-4系统的环境的互操作性可能很困难；因此，其他有效载荷格式可能更适合这些应用。 The semantics of RTP headers in such cases need to be clearly defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it is beneficial to define the fragmentation rules of RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resiliency tools provided inside the MPEG-4 Video stream. MPEG-4 Visual is a visual coding standard with many features, including: high coding efficiency; high error resiliency; and multiple, arbitrary shape object-based coding [14496-2]. It covers a wide range of bitrates from scores of kbit/s to several Mbit/s. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to mobile networks with high error rates. With respect to the fragmentation rules for an MPEG-4 Visual bitstream defined in this document, since MPEG-4 Visual is used for a wide variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video packet shall always be mapped on a single RTP packet" may be inappropriate. On the other hand, careless, media-unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but manage to define the minimum rules for preventing meaningless fragmentation while utilizing the error resiliency functionalities of MPEG-4 Visual. The fragmentation rule "Different Video Object Planes (VOPs) SHOULD be fragmented into different RTP packets" is made so that the RTP timestamp uniquely indicates the VOP time framing. On the other hand, MPEG-4 video may generate VOPs of very small size, in cases with an empty VOP (vop_coded=0) containing only VOP header or an arbitrary shaped VOP with a small number of coding blocks. To reduce the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet. (See fragmentation rule (4) in Section 5.2 and the descriptions of marker bit and timestamp in Section 5.1.) While the additional media-specific RTP header defined for such video coding tools as H.261 [H261] or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, MPEG-4 Visual already has error resiliency functionalities for recovering corrupt headers, and these can be used on RTP/IP networks as well as on other networks (H.223/mobile, MPEG-2 Transport Stream, etc.). Therefore, no extra RTP header fields are defined in this MPEG-4 Visual RTP payload format. MPEG-4 Audio is an audio standard that integrates many different types of audio coding tools. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto RTP packets without using MPEG-4 Systems. 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 decodability of adjacent packets. Therefore, the additional media-specific header for recovering errors will not be required for MPEG-4 Audio. Existing RTP protection mechanisms, such as Generic Forward Error Correction [RFC5109] and Redundant Audio Data [RFC2198], MAY be applied to improve error resiliency. This specification is not backwards compatible with [RFC3016], as a binary incompatible LATM version is mandated. Existing implementations of RFC 3016 that use a recent LATM version may already comply to this specification and must be considered as not compliant with RFC 3016. The 3GPP PSS service [3GPP] is such an example, as a more recent LATM version is mandated in the 3GPP PSS specification. Existing implementations that use the LATM version as specified in RFC 3016 MUST be updated to comply with this specification. In this document a payload format for the transport of MPEG-4 Elementary Streams is specified. For MPEG-4 Audio streams "out-of-band" signaling is defined such that a receiver is not obliged to decode the payload data to determine the audio codec and its configuration. The signaling capabilities specified in this document are less explicit than those defined in [RFC3640]. But, the use of the MPEG-4 LATM in various transmission standards justifies its right to exist; see also Section 1.2. The core codec channel configuration is the default audio codec channel configuration. When PS is used, the core codec channel configuration indicates one channel (i.e., mono) whereas the definitive channel configuration is two channels (i.e. stereo). When MPEG Surround is used, the definitive channel configuration depends on the output of the MPEG Surround decoder. However, 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 6.2). This section specifies RTP packetization rules for MPEG-4 Visual content. An MPEG-4 Visual bitstream is mapped directly onto RTP packets without the addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode MUST be used so that configuration information will be carried to the same RTP port as the elementary stream. (See Subclause 6.2.1, "Start codes", of [14496-2].) The configuration information MAY additionally be specified by some out-of-band means. If needed by systems using media type parameters and SDP parameters, e.g., SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information (see Sections 7.1 and 7.2). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | RTP | MPEG-4 Visual stream (byte aligned) | Pay- | | load | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | RTP | MPEG-4 Visual stream (byte aligned) | Pay- | | load | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 specified here. It is expected that the RTP profile for a particular 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 be chosen by means of an out-of-band signaling protocol (e.g., H.245, SIP). (4) Different VOPs SHOULD be fragmented into different RTP packets so that one RTP packet consists of the data bytes associated with a unique VOP time instance (that is indicated in the timestamp field in the RTP packet header), with the exception that multiple consecutive VOPs MAY be carried within one RTP packet in the decoding order if the size of the VOPs is small. Note: When multiple VOPs are carried in one RTP payload, 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 the marker bit equals to 1 and the beginning of the RTP payload corresponds to a start code. (See the descriptions of timestamp and marker bit in Section 5.1.) (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 way that the resulting RTP packet is not larger than the Path MTU. If the video packet is disabled by the coder configuration (by setting resync_marker_disable in the VOL header to 1), or in coding tools where the video packet is not supported, a VOP MAY be split at arbitrary byte positions. (a) is an example of the first RTP packet or the random access point of an MPEG-4 Visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header (VS header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header (VO header, VOL header). Since the fragmentation rule defined in Section 5.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code. (b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a VOP header and a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet containing only the configuration information may thus increase the overhead, the configuration information and the subsequent VOP can be packetized into a single RTP packet. (c) is an example of an RTP packet that contains Group_of_VideoObjectPlane (GOV). Following criterion (1), the GOV is 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 GOV whose length is 7 bytes. Therefore, the following VOP (or a part of it) 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 into one RTP packet. When the packet-loss rate of the underlying network is high, this kind of packetization is recommended. Even when the RTP packet containing the VOP header is discarded by a packet loss, the other RTP packets can be decoded by using the HEC (Header Extension Code) information in the video packet header. No extra RTP header field is necessary. (e) is an example of the case where more than one video packet is packetized into one RTP packet. This kind of packetization is effective to save the overhead of RTP/IP headers when the bitrate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single RTP packet loss. The optimal number of video packets in an RTP packet and the length of the RTP packet can be determined by considering the packet-loss rate and the bitrate of the underlying network. (f) is an example of the case when the video packet is disabled by setting resync_marker_disable in the VOL header to 1. In this case, a VOP may be split into a plurality of RTP packets at arbitrary byte positions. For example, it is possible to split a VOP into fixed-length packets. This kind of coder configuration and RTP packet fragmentation may be used when the underlying network is guaranteed to be error-free. When concatenating more than one video packet into an RTP packet, the VOP header or video_packet_header() is not allowed to be placed in the middle of the RTP payload. The packetization as in Figure 2(b) is not allowed by criterion (2) due to the aspect of the error resiliency. Comparing this example with Figure 2(d), although two video packets are mapped onto two RTP packets in both cases, the packet-loss resiliency is not identical. Namely, if the second RTP packet is lost, both video packets 1 and 2 are lost in the case of Figure 3(b), whereas only video packet 2 is lost in the case of Figure 2(d). +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+------+------+------+------+------------+ (b) | RTP | VS | VO | VOL | VOP |Video Packet| |header|header|header|header|header| | +------+------+------+------+------+------------+ +------+------+------+------+------+------------+ (b) | RTP | VS | VO | VOL | VOP |Video Packet| |header|header|header|header|header| | +------+------+------+------+------+------------+ +------+-----+------------------+ (c) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+-----+------------------+ (c) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ +------+------+------------+ +------+------+------------+ (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ +------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet| |header|header| (1) |header| (2) |header| (3) | +------+------+------------+------+------------+------+------------+ +------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet| |header|header| (1) |header| (2) |header| (3) | +------+------+------------+------+------------+------+------------+ +------+------+------------+ +------+------------+ (f) | RTP | VOP |VOP fragment| | RTP |VOP fragment| |header|header| (1) | |header| (2) | . . . +------+------+------------+ +------+------------+ +------+------+------------+ +------+------------+ (f) | RTP | VOP |VOP fragment| | RTP |VOP fragment| |header|header| (1) | |header| (2) | . . . +------+------+------------+ +------+------------+ +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+------+----------+ +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) | +------+------+----------+ +------+---------+------+------------+ +------+------+----------+ +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) | +------+------+----------+ +------+---------+------+------------+ LATM-based streams consist of a sequence of audioMuxElements that include one or more PayloadMux elements that carry the audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of each audioMuxElement SHALL be located at the first payload location in an RTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |RTP : audioMuxElement (byte aligned) :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |RTP : audioMuxElement (byte aligned) :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In order to decode the audioMuxElement, the following muxConfigPresent information is required to be indicated by out-of-band means. When SDP is utilized for this indication, the media type parameter "cpresent" corresponds to the muxConfigPresent information (see Section 7.3). The following restrictions apply: o To construct the audioMuxElement in the in-band configuration case, non-octet-aligned configuration data is inserted immediately before the one or 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 audioMuxElement SHALL include an indication bit "useSameStreamMux" and MAY include the configuration information for audio compression "StreamMuxConfig". The useSameStreamMux bit indicates whether the StreamMuxConfig element in the previous frame is applied in the current frame. If the useSameStreamMux bit indicates to use the StreamMuxConfig from the previous frame, but if the previous frame has been lost, the current frame may not be decodable. Therefore, in case of in-band mode, the StreamMuxConfig element SHOULD be transmitted repeatedly depending on the network condition. On the other hand, if muxConfigPresent is set to 0 (out-of-band mode), the StreamMuxConfig element is required to be transmitted by an out-of-band means. In case of SDP, the media type parameter "config" is utilized (see Section 7.3). muxConfigPresent：如果该值设置为1（带内模式），则AudioMuxement应包括一个指示位“useSameStreamMux”，并可能包括音频压缩的配置信息“StreamMuxConfig”。useSameStreamMux位指示前一帧中的StreamMuxConfig元素是否应用于当前帧。如果useSameStreamMux位指示使用前一帧的StreamMuxConfig，但如果前一帧已丢失，则当前帧可能无法解码。因此，在带内模式下，应根据网络条件重复传输StreamMuxConfig元素。另一方面，如果muxConfigPresent设置为0（带外模式），则需要通过带外方式传输StreamMuxConfig元素。对于SDP，使用媒体类型参数“config”（见第7.3节）。 Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document and will only be restricted here. It is expected that the RTP profile for a particular 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 be chosen by means of an out-of-band signaling protocol (e.g., H.245, SIP). In the dynamic assignment of RTP payload types for scalable streams, the server SHALL assign a different value to each layer. The dependency relationships between the enhanced layer and the base layer MUST be signaled as specified in [RFC5583]. An example of the use of such signaling for scalable audio streams can be found in [RFC5691]. 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 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 SHALL be fragmented and spread across multiple packets. The following sections describe the media type registrations for MPEG-4 Audio/Visual streams, which are registered in accordance with [RFC4855] and use the template of [RFC4288]. Media type registration and SDP usage for the MPEG-4 Visual stream are described in Sections 7.1 and 7.2, respectively, while media type registration and SDP usage for MPEG-4 Audio stream are described in Sections 7.3 and 7.4, respectively. "profile-level-id": A decimal representation of MPEG-4 Visual Profile and Level indication value (profile_and_level_indication) defined in Table G-1 of [14496-2]. This parameter MAY be used in the capability exchange or session setup procedure to indicate the MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual codec is capable. If this parameter is not specified by the procedure, its default value of 1 (Simple Profile/Level 1) is used. "config": This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. It is a hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as defined in Subclause 6.2.1 ("Start codes") of [14496-2]. The configuration information is mapped onto the octet string most significant bit (MSB) first. The first bit of the configuration information SHALL be located at the MSB of the first octet. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and latter_half_vbv_occupancy (if they exist), which may vary in the repeated configuration information inside an MPEG-4 Visual stream. (See Subclause 6.2.1, "Start codes", of [14496-2].) Video bitstreams MUST be generated according to MPEG-4 Visual specifications [14496-2]. A video bitstream is binary data and MUST be encoded for non-binary transport (for email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets MUST be packetized according to the MPEG-4 Visual RTP payload format defined in [RFC6416]. MPEG-4 Visual provides a large and rich set of tools for the coding of visual objects. For effective implementation of the standard, subsets of the MPEG-4 Visual tool sets have been provided for use in specific applications. These subsets, called 'Profiles', limit the size of the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each Profile. A Profile@Level combination allows: The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" or by arranging a capability exchange/announcement procedure for this parameter. Example usages for the "profile-level-id" parameter are: 1 : MPEG-4 Visual Simple Profile/Level 1 34 : MPEG-4 Visual Core Profile/Level 2 145: MPEG-4 Visual Advanced Real Time Simple Profile/Level 1 Example usages for the "profile-level-id" parameter are: 1 : MPEG-4 Visual Simple Profile/Level 1 34 : MPEG-4 Visual Core Profile/Level 2 145: MPEG-4 Visual Advanced Real Time Simple Profile/Level 1 Simple Profile/Level 1, rate=90000(90 kHz), "profile-level-id" and "config" are present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=1;config=000001B001000001B50900000100000 00120008440FA282C2090A21F Simple Profile/Level 1, rate=90000(90 kHz), "profile-level-id" and "config" are present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=1;config=000001B001000001B50900000100000 00120008440FA282C2090A21F Core Profile/Level 2, rate=90000(90 kHz), "profile-level-id" is present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=34 Core Profile/Level 2, rate=90000(90 kHz), "profile-level-id" is present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=34 Advance Real Time Simple Profile/Level 1, rate=90000(90 kHz), "profile-level-id" is present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=145 Advance Real Time Simple Profile/Level 1, rate=90000(90 kHz), "profile-level-id" is present in "a=fmtp" line: m=video 49170/2 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=fmtp:98 profile-level-id=145 NOTE: The optional parameter "SBR-enabled" in SDP "a=fmtp" is useful 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 v2 signaling. Therefore, its existence (in itself) is not the criteria to determine whether or HE AAC / HE AAC v2 signaling is explicit. "profile-level-id": a decimal representation of MPEG-4 Audio Profile Level indication value defined in [14496-3]. This parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used. "cpresent": a boolean parameter that indicates whether audio payload configuration data has been multiplexed into an RTP payload (see Section 6.1). A 0 indicates the configuration data has not been multiplexed into an RTP payload, and in that case, the "config" parameter MUST be present; a 1 indicates that it has been multiplexed. 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 expresses the audio payload configuration data "StreamMuxConfig", as defined in [14496-3]. Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, SHALL follow the configuration data. Senders MUST set the StreamMuxConfig elements taraBufferFullness and latmBufferFullness to their largest respective value, indicating that buffer fullness measures are not used in SDP. Receivers MUST ignore the value of these two elements contained in the "config" parameter. If the presence of SBR cannot be detected from out-of-band configuration and the "SBR-enabled" parameter is not present, the parameter defaults to 1 for an SBR-capable decoder. If the resulting output sampling rate or the computational complexity is not supported, the SBR tool can be disabled or run in down-sampled mode. The audio stream SHALL be compliant with the MPEG-4 Audio Profile@ Level specified by the parameters "profile-level-id" and "MPS-profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameters "profile-level-id" and "MPS-profile-level-id" or by arranging in the capability exchange procedure to set this parameter mutually The following are some examples of the "profile-level-id" value: 1 : Main Audio Profile Level 1 9 : Speech Audio Profile Level 1 15: High Quality Audio Profile Level 2 30: Natural Audio Profile Level 1 44: High Efficiency AAC Profile Level 2 48: High Efficiency AAC v2 Profile Level 2 55: Baseline MPEG Surround Profile (see ISO/IEC 23003-1) Level 3 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/8000 a=fmtp:96 profile-level-id=9; object=8; cpresent=0; config=40008B18388380 a=ptime:20 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/8000 a=fmtp:96 profile-level-id=9; object=8; cpresent=0; config=40008B18388380 a=ptime:20 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000/2 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; object=2; config=400026203fc0 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000/2 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; object=2; config=400026203fc0 These two examples are identical to the example above with the exception of the "SBR-enabled" parameter. The presence of SBR is not signaled by the SDP parameters "object", "profile-level-id", and "config", but instead the "SBR-enabled" parameter is present. The "rate" parameter and the StreamMuxConfig contain the core codec sampling rate. m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000/2 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; SBR-enabled=0; config=400026203fc0 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000/2 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; SBR-enabled=0; config=400026203fc0 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000/2 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; SBR-enabled=1; config=400026203fc0 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/24000/2 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; SBR-enabled=1; config=400026203fc0 In this example, the "clock rate" is still 24000, and this information is used for RTP timestamp calculation. The value of 24000 is used to support old AAC decoders. This makes the decoder supporting only AAC understand the HE AAC coded data, although only plain AAC is supported. A HE AAC decoder is able to generate output data with the SBR sampling rate. m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/48000/2 a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; config=40005623101fe0; SBR-enabled=1 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/48000/2 a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; config=40005623101fe0; SBR-enabled=1 This "config" string uses the explicit signaling mode 2.A (hierarchical signaling; see [14496-3]. This means that the AOT (Audio Object Type) is SBR (5) and SFI (Sampling Frequency Index) is 6 (24000 Hz), which refers to the underlying core codec sampling frequency. CC (Channel Configuration) is stereo (2), and the ESFI (Extension Sampling Frequency Index)=3 (48000) is referring to the sampling frequency of the extension tool (SBR). m=audio 49230 RTP/AVP 110 a=rtpmap:110 MP4A-LATM/24000/1 a=fmtp:110 profile-level-id=15; object=2; cpresent=0; config=400026103fc0; SBR-enabled=1 m=audio 49230 RTP/AVP 110 a=rtpmap:110 MP4A-LATM/24000/1 a=fmtp:110 profile-level-id=15; object=2; cpresent=0; config=400026103fc0; SBR-enabled=1 The following examples show how MPEG Surround configuration data can be signaled using SDP. The configuration is carried within the "config" string in the first example by using two different layers. The general parameters in this example are: AudioMuxVersion=1; allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0; numLayer=1. The first layer describes the HE AAC payload and signals the following parameters: ascLen=25; audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=6 (24 kHz); extensionSamplingFrequencyIndex=3 (48 kHz); channelConfiguration=2 (2.0 channels). The second layer describes the MPEG Surround payload and specifies the following parameters: ascLen=110; AudioObjectType=30 (MPEG Surround); samplingFrequencyIndex=3 (48 kHz); channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1; SpatialSpecificConfig=(48 kHz; 32 slots; 525 tree; ResCoding=1; ResBands=[7,7,7,7]). The following examples show how MPEG Surround configuration data can be signaled using SDP. The configuration is carried within the "config" string in the first example by using two different layers. The general parameters in this example are: AudioMuxVersion=1; allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0; numLayer=1. The first layer describes the HE AAC payload and signals the following parameters: ascLen=25; audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=6 (24 kHz); extensionSamplingFrequencyIndex=3 (48 kHz); channelConfiguration=2 (2.0 channels). The second layer describes the MPEG Surround payload and specifies the following parameters: ascLen=110; AudioObjectType=30 (MPEG Surround); samplingFrequencyIndex=3 (48 kHz); channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1; SpatialSpecificConfig=(48 kHz; 32 slots; 525 tree; ResCoding=1; ResBands=[7,7,7,7]). m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/48000 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; SBR-enabled=1; config=8FF8004192B11880FF0DDE3699F2408C00536C02313CF3CE0FF0 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/48000 a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0; SBR-enabled=1; config=8FF8004192B11880FF0DDE3699F2408C00536C02313CF3CE0FF0 representation of the MPEG Surround ASC [audioObjectType=30 (MPEG Surround); samplingFrequencyIndex=0x3 (48 kHz); channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1; SpatialSpecificConfig=(48 kHz; 32 slots; 525 tree; ResCoding=1; ResBands=[0,13,13,13])]. representation of the MPEG Surround ASC [audioObjectType=30 (MPEG Surround); samplingFrequencyIndex=0x3 (48 kHz); channelConfiguration=6 (5.1 channels); sacPayloadEmbedding=1; SpatialSpecificConfig=(48 kHz; 32 slots; 525 tree; ResCoding=1; ResBands=[0,13,13,13])]. m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/48000 a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; config=40005623101fe0; MPS-profile-level-id=55; MPS-asc=F1B4CF920442029B501185B6DA00; m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/48000 a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; config=40005623101fe0; MPS-profile-level-id=55; MPS-asc=F1B4CF920442029B501185B6DA00; The following example shows how MPEG Surround configuration data can be signaled using the SDP "config" parameter. The configuration is carried within the "config" string using a single layer. The general parameters in this example are: AudioMuxVersion=1; allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0; numLayer=0. The single layer describes the combination of HE AAC and MPEG Surround payload and signals the following parameters: ascLen=101; audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=7 (22.05 kHz); extensionSamplingFrequencyIndex=7 (44.1 kHz); channelConfiguration=2 (2.0 channels). A backward-compatible extension according to [14496-3/Amd.1] signals the presence of MPEG Surround payload data and specifies the following parameters: SpatialSpecificConfig=(44.1 kHz; 32 slots; 525 tree; ResCoding=0). The following example shows how MPEG Surround configuration data can be signaled using the SDP "config" parameter. The configuration is carried within the "config" string using a single layer. The general parameters in this example are: AudioMuxVersion=1; allStreamsSameTimeFraming=1; numSubFrames=0; numProgram=0; numLayer=0. The single layer describes the combination of HE AAC and MPEG Surround payload and signals the following parameters: ascLen=101; audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=7 (22.05 kHz); extensionSamplingFrequencyIndex=7 (44.1 kHz); channelConfiguration=2 (2.0 channels). A backward-compatible extension according to [14496-3/Amd.1] signals the presence of MPEG Surround payload data and specifies the following parameters: SpatialSpecificConfig=(44.1 kHz; 32 slots; 525 tree; ResCoding=0). m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/44100 a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; SBR-enabled=1; config=8FF8000652B920876A83A1F440884053620FF0; MPS-profile-level-id=55 m=audio 49230 RTP/AVP 96 a=rtpmap:96 MP4A-LATM/44100 a=fmtp:96 profile-level-id=44; bitrate=64000; cpresent=0; SBR-enabled=1; config=8FF8000652B920876A83A1F440884053620FF0; MPS-profile-level-id=55 RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this document are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload, and integrity of the RTP packets is achieved 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. 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 content, including Java applets (MPEG-J) and scripts. Since this payload format is restricted to audio and video streams, it is not possible to transport such active content in this format.