RFC-5404RTPPayloadFormatforG.719(G.719)资源-CSDN文库

需积分: 1 77 浏览量 2023-08-07 10:42:18 上传评论收藏 40KB PDF 举报

资源推荐

资源详情

资源评论

Network Working Group M. Westerlund

Request for Comments: 5404 I. Johansson

Category: Standards Track Ericsson AB

January 2009

RTP Payload Format for G.719

Status of This Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

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.

Abstract

This document specifies the payload format for packetization of the

G.719 full-band codec encoded audio signals into the Real-time

Transport Protocol (RTP). The payload format supports transmission

of multiple channels, multiple frames per payload, and interleaving.

Westerlund & Johansson Standards Track [Page 1]

RFC 5404 RTP Payload Format for G.719 January 2009

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Definitions and Conventions . . . . . . . . . . . . . . . . . 3

3. G.719 Description . . . . . . . . . . . . . . . . . . . . . . 3

4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 4

4.1. Multi-Rate Encoding and Rate Adaptation . . . . . . . . . 4

4.2. Support for Multi-Channel Sessions . . . . . . . . . . . . 5

4.3. Robustness against Packet Loss . . . . . . . . . . . . . . 5

4.3.1. Use of Forward Error Correction (FEC) . . . . . . . . 5

4.3.2. Use of Frame Interleaving . . . . . . . . . . . . . . 6

5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 7

5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 8

5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 8

5.2.1. Basic ToC Element . . . . . . . . . . . . . . . . . . 9

5.3. Basic Mode . . . . . . . . . . . . . . . . . . . . . . . . 10

5.4. Interleaved Mode . . . . . . . . . . . . . . . . . . . . . 10

5.5. Audio Data . . . . . . . . . . . . . . . . . . . . . . . . 11

5.6. Implementation Considerations . . . . . . . . . . . . . . 12

5.6.1. Receiving Redundant Frames . . . . . . . . . . . . . . 12

5.6.2. Interleaving . . . . . . . . . . . . . . . . . . . . . 12

5.6.3. Decoding Validation . . . . . . . . . . . . . . . . . 13

6. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . 13

6.1. 3 Mono Frames with 2 Different Bitrates . . . . . . . . . 13

6.2. 2 Stereo Frame-Blocks of the Same Bitrate . . . . . . . . 14

6.3. 4 Mono Frames Interleaved . . . . . . . . . . . . . . . . 15

7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16

7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 16

7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 19

7.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 19

7.2.2. Declarative SDP Considerations . . . . . . . . . . . . 22

8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23

9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 23

10. Security Considerations . . . . . . . . . . . . . . . . . . . 24

11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25

12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25

12.1. Normative References . . . . . . . . . . . . . . . . . . . 25

12.2. Informative References . . . . . . . . . . . . . . . . . . 26

Westerlund & Johansson Standards Track [Page 2]

RFC 5404 RTP Payload Format for G.719 January 2009

1. Introduction

This document specifies the payload format for packetization of the

G.719 full-band (FB) codec encoded audio signals into the Real-time

Transport Protocol (RTP) [RFC3550]. The payload format supports

transmission of multiple channels, multiple frames per payload, and

packet loss robustness methods using redundancy or interleaving.

This document starts with conventions, a brief description of the

codec, and the payload format’s capabilities. The payload format is

specified in Section 5. Examples can be found in Section 6. The

media type and its mappings to the Session Description Protocol (SDP)

and usage in SDP offer/answer are then specified. The document ends

with considerations regarding congestion control and security.

2. Definitions and Conventions

The term "frame-block" is used in this document to describe the time-

synchronized set of audio frames in a multi-channel audio session.

In particular, in an N-channel session, a frame-block will contain N

audio frames, one from each of the channels, and all N speech frames

represent exactly the same time period.

This document contains depictions of bit fields. The most

significant bit is always leftmost in the figure on each row and has

the lowest enumeration. For fields that are depicted over multiple

rows, the upper row is more significant than the next.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 [RFC2119].

3. G.719 Description

The ITU-T G.719 full-band codec is a transform coder based on

Modulated Lapped Transform (MLT). G.719 is a low-complexity full-

bandwidth codec for conversational speech and audio coding. The

encoder input and decoder output are sampled at 48 kHz. The codec

enables full-bandwidth from 20 Hz to 20 kHz, encoding of speech,

music, and general audio content at rates from 32 kbit/s up to 128

kbit/s. The codec operates on 20-ms frames and has an algorithmic

delay of 40 ms.

The codec provides excellent quality for speech, music, and other

types of audio. Some of the applications for which this coder is

suitable are:

Westerlund & Johansson Standards Track [Page 3]

RFC 5404 RTP Payload Format for G.719 January 2009

o Real-time communications such as video conferencing and telephony

o Streaming audio

o Archival and messaging

The encoding and decoding algorithm can change the bitrate at any

20-ms frame boundary. The encoder receives the audio sampled at 48

kHz. The support of other sampling rates is possible by re-sampling

the input signal to the codec’s sampling rate, i.e., 48 kHz; however,

this functionality is not part of the standard.

The encoding is performed on equally sized frames. For each frame,

the encoder decides between two encoding modes, a transient mode and

a stationary mode. The decision is based on statistics derived from

the input signal. The stationary mode uses a long MLT that leads to

a spectrum of 960 coefficients, while the transient encoding mode

uses a short MLT (higher time resolution transform) that results in 4

spectra (4 x 240 = 960 coefficients). The encoding of the spectrum

is done in two steps. First, the spectral envelope is computed,

quantized, and Huffman encoded. The envelope is computed on a non-

uniform frequency subdivision. From the coded spectral envelope, a

weighted spectral envelope is derived and is used for bit allocation;

this process is also repeated at the decoder. Thus, only the

spectral envelope is transmitted. The output of the bit allocation

is used in order to quantize the spectra. In addition, for

stationary frames, the encoder estimates the amount of noise level.

The decoder applies the reverse operation upon reception of the bit

stream. The non-coded coefficients (i.e., no bits allocated) are

replaced by entries of a noise codebook that is built based on the

decoded coefficients.

4. Payload Format Capabilities

This payload format has a number of capabilities, and this section

discusses them in some detail.

4.1. Multi-Rate Encoding and Rate Adaptation

G.719 supports a multi-rate encoding capability that enables on a

per-frame basis variation of the encoding rate. This enables support

for bitrate adaptation and congestion control. The possibility to

aggregate multiple audio frames into a single RTP payload is another

dimension of adaptation. The RTP and payload format overhead can

thus be reduced by the aggregation at the cost of increased delay and

reduced packet-loss robustness.

Westerlund & Johansson Standards Track [Page 4]

RFC 5404 RTP Payload Format for G.719 January 2009

4.2. Support for Multi-Channel Sessions

The RTP payload format defined in this document supports multi-

channel audio content (e.g., stereophonic or surround audio

sessions). Although the G.719 codec itself does not support encoding

of multi-channel audio content into a single bit stream, it can be

used to separately encode and decode each of the individual channels.

To transport (or store) the separately encoded multi-channel content,

the audio frames for all channels that are framed and encoded for the

same 20-ms period are logically collected in a "frame-block".

At the session setup, out-of-band signaling must be used to indicate

the number of channels in the payload type. The order of the audio

frames within the frame-block depends on the number of the channels

and follows the definition in Section 4.1 of the RTP/AVP profile

[RFC3551]. When using SDP for signaling, the number of channels is

specified in the rtpmap attribute.

4.3. Robustness against Packet Loss

The payload format supports several means, including forward error

correction (FEC) and frame interleaving, to increase robustness

against packet loss.

4.3.1. Use of Forward Error Correction (FEC)

Generic forward error correction within RTP is defined, for example,

in RFC 5109 [RFC5109]. Audio redundancy coding is defined in RFC

2198 [RFC2198]. Either scheme can be used to add redundant

information to the RTP packet stream and make it more resilient to

packet losses, at the expense of a higher bitrate. Please see either

of the RFCs for a discussion of the implications of the higher

bitrate to network congestion.

In addition to these media-unaware mechanisms, this memo specifies a

G.719-specific form of audio redundancy coding, which may be

beneficial in terms of packetization overhead. Conceptually,

previously transmitted transport frames are aggregated together with

new ones. A sliding window can be used to group the frames to be

sent in each payload. However, irregular or non-consecutive patterns

are also possible by inserting NO_DATA frames between primary and

redundant transmissions. Figure 1 below shows an example.

Westerlund & Johansson Standards Track [Page 5]

剩余26页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2140
资源: 24

RFC-5404 RTP Payload Format for G.719 (G.719)

最新资源

RFC-5404 RTP Payload Format for G.719 (G.719)

RTP Payload Format for Scalable Video Coding

RFC-2032 RTP Payload Format for H.261 Video Streams (FIR)

RFC-7587 RTP Payload Format for the Opus Speech and Audio Codec

RFC-6184 RTP Payload Format for H.264 Video (H.264)

RFC-7798 RTP Payload Format for High Efficiency Video Coding

RFC-7655 RTP Payload Format for G.711.0 (G.711)

RFC-4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)

RFC-3640 RTP Payload Format for Transport of MPEG-4 Elementary S

RFC-7741 RTP Payload Format for VP8 Video (VP8)

RFC 3984 - RTP Payload Format for H_264 Video

RFC3984 RTP Payload Format for H264 Video

RTP Payload Format for H.264 Video

H.264的RTP打包格式中文版

RTP发送H265(HEVC) RFC文档

H.264 over RTP(rfc3984)

rfc3984标准文档

H264 RTP负载格式中文说明 —— H264 RTP Payload Format

RTP Payload Format for H.264&amp;H.265 Video

RTP_Payload_Format_for_H.264_Video

SVC NAL相关文档 资料

rfc3640.pdf

rfc3640标准文档

RFC3550中文版 （RTP/RTCP）

落雪音乐-六音音源 sixyin-music-source-v1.1.0.js

markdown配套文件，使用前先解压

喜马拉雅xm文件解密工具

最新资源

RTP Payload Format for H.264&H.265 Video

SVC NAL相关文档资料

RFC3550中文版（RTP/RTCP）