Opus音频编解码器定义与应用

需积分: 1 53 浏览量更新于2024-06-22 收藏 727KB PDF 举报

"RFC-6716 定义了Opus音频编码器" Opus音频编码是一种由互联网工程任务组（IETF）定义的互动式语音和音频编码标准，主要作者包括 JM.Valin、K.Vos 和 T.Terriberry等，其中涉及到Mozilla Corporation和Skype Technologies S.A.的技术贡献。RFC-6716文档是这个标准的正式定义，它于2012年9月发布，并被归类为互联网标准轨道文档，意味着它在IETF社区中达成了共识，并经过了公开审查。 Opus编码器的设计目标是处理广泛的互动音频应用，如VoIP（Voice over IP）、视频会议、游戏内聊天以及分布式音乐表演。其适应性强，能在6kbps的低比特率窄带语音到510kbps的高质立体声音乐之间无缝切换，提供了良好的音质与带宽效率平衡。 Opus编码器的关键特性在于其结合了两种不同的压缩技术：线性预测（Linear Prediction, LP）和修改过的离散余弦变换（Modified Discrete Cosine Transform, MDCT）。线性预测常用于语音编码，能有效处理人类语音的频谱特性，而MDCT则更适用于音乐编码，因为它能更好地捕获音频中的瞬态和连续部分。通过这两种技术的融合，Opus能够对语音和音乐都实现高效压缩，同时保持高质量的回放效果。作为互联网标准，Opus编码的实现和使用遵循开放的协议，这意味着任何开发者或公司都可以免费实施并使用该编码器，这促进了其在各种网络通信和多媒体应用中的广泛采用。此外，由于Opus具有低延迟、高适应性和优秀的音质，它在实时通信领域，如WebRTC（Web Real-Time Communication）和现代流媒体服务中扮演着重要角色。 RFC文档详细阐述了Opus编码的各个方面，包括编码算法的细节、解码过程、参数设置、错误处理以及与其他音频编码格式的互操作性。这使得开发者能够理解和实现符合标准的Opus编码器，从而确保跨平台和跨应用的一致性。 RFC-6716定义的Opus音频编码是互联网音频传输和交互式通信中不可或缺的一部分，它的出现极大地推动了音频编码技术的发展，为用户提供了一种兼顾性能和兼容性的解决方案。

RFC 6716 Interactive Audio Codec September 2012

3.2. Frame Packing

This section describes how frames are packed according to each

possible value of "c" in the TOC byte.

3.2.1. Frame Length Coding

When a packet contains multiple VBR frames (i.e., code 2 or 3), the

compressed length of one or more of these frames is indicated with a

one- or two-byte sequence, with the meaning of the first byte as

follows:

o 0: No frame (Discontinuous Transmission (DTX) or lost packet)

o 1...251: Length of the frame in bytes

o 252...255: A second byte is needed. The total length is

(second_byte*4)+first_byte

The special length 0 indicates that no frame is available, either

because it was dropped during transmission by some intermediary or

because the encoder chose not to transmit it. Any Opus frame in any

mode MAY have a length of 0.

The maximum representable length is 255*4+255=1275 bytes. For 20 ms

frames, this represents a bitrate of 510 kbit/s, which is

approximately the highest useful rate for lossily compressed fullband

stereo music. Beyond this point, lossless codecs are more

appropriate. It is also roughly the maximum useful rate of the MDCT

layer as, shortly thereafter, quality no longer improves with

additional bits due to limitations on the codebook sizes.

No length is transmitted for the last frame in a VBR packet, or for

any of the frames in a CBR packet, as it can be inferred from the

total size of the packet and the size of all other data in the

packet. However, the length of any individual frame MUST NOT exceed

1275 bytes [R2] to allow for repacketization by gateways, conference

bridges, or other software.

3.2.2. Code 0: One Frame in the Packet

For code 0 packets, the TOC byte is immediately followed by N-1 bytes

of compressed data for a single frame (where N is the size of the

packet), as illustrated in Figure 2.

Valin, et al. Standards Track [Page 16]

RFC 6716 Interactive Audio Codec September 2012

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| config |s|0|0| |

+-+-+-+-+-+-+-+-+ |

| Compressed frame 1 (N-1 bytes)... :

: |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: A Code 0 Packet

3.2.3. Code 1: Two Frames in the Packet, Each with Equal Compressed

Size

For code 1 packets, the TOC byte is immediately followed by the

(N-1)/2 bytes of compressed data for the first frame, followed by

(N-1)/2 bytes of compressed data for the second frame, as illustrated

in Figure 3. The number of payload bytes available for compressed

data, N-1, MUST be even for all code 1 packets [R3].

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| config |s|0|1| |

+-+-+-+-+-+-+-+-+ :

| Compressed frame 1 ((N-1)/2 bytes)... |

: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

| Compressed frame 2 ((N-1)/2 bytes)... |

: +-+-+-+-+-+-+-+-+

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: A Code 1 Packet

3.2.4. Code 2: Two Frames in the Packet, with Different Compressed

Sizes

For code 2 packets, the TOC byte is followed by a one- or two-byte

sequence indicating the length of the first frame (marked N1 in

Figure 4), followed by N1 bytes of compressed data for the first

frame. The remaining N-N1-2 or N-N1-3 bytes are the compressed data

for the second frame. This is illustrated in Figure 4. A code 2

packet MUST contain enough bytes to represent a valid length. For

example, a 1-byte code 2 packet is always invalid, and a 2-byte code

2 packet whose second byte is in the range 252...255 is also invalid.

Valin, et al. Standards Track [Page 17]

RFC 6716 Interactive Audio Codec September 2012

The length of the first frame, N1, MUST also be no larger than the

size of the payload remaining after decoding that length for all code

2 packets [R4]. This makes, for example, a 2-byte code 2 packet with

a second byte in the range 1...251 invalid as well (the only valid

2-byte code 2 packet is one where the length of both frames is zero).

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| config |s|1|0| N1 (1-2 bytes): |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :

| Compressed frame 1 (N1 bytes)... |

: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

| Compressed frame 2... :

: |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: A Code 2 Packet

3.2.5. Code 3: A Signaled Number of Frames in the Packet

Code 3 packets signal the number of frames, as well as additional

padding, called "Opus padding" to indicate that this padding is added

at the Opus layer rather than at the transport layer. Code 3 packets

MUST have at least 2 bytes [R6,R7]. The TOC byte is followed by a

byte encoding the number of frames in the packet in bits 2 to 7

(marked "M" in Figure 5), with bit 1 indicating whether or not Opus

padding is inserted (marked "p" in Figure 5), and bit 0 indicating

VBR (marked "v" in Figure 5). M MUST NOT be zero, and the audio

duration contained within a packet MUST NOT exceed 120 ms [R5]. This

limits the maximum frame count for any frame size to 48 (for 2.5 ms

frames), with lower limits for longer frame sizes. Figure 5

illustrates the layout of the frame count byte.

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|v|p| M |

+-+-+-+-+-+-+-+-+

Figure 5: The frame count byte

When Opus padding is used, the number of bytes of padding is encoded

in the bytes following the frame count byte. Values from 0...254

indicate that 0...254 bytes of padding are included, in addition to

Valin, et al. Standards Track [Page 18]

RFC 6716 Interactive Audio Codec September 2012

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| config |s|1|1|0|p| M | Padding length (Optional) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

: Compressed frame 1 (R/M bytes)... :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

: Compressed frame 2 (R/M bytes)... :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

: ... :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

: Compressed frame M (R/M bytes)... :

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

: Opus Padding (Optional)... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: A CBR Code 3 Packet

In the VBR case, the (optional) padding length is followed by M-1

frame lengths (indicated by "N1" to "N[M-1]" in Figure 7), each

encoded in a one- or two-byte sequence as described above. The

packet MUST contain enough data for the M-1 lengths after removing

the (optional) padding, and the sum of these lengths MUST be no

larger than the number of bytes remaining in the packet after

decoding them [R7]. The compressed data for all M frames follows,

each frame consisting of the indicated number of bytes, with the

final frame consuming any remaining bytes before the final padding,

as illustrated in Figure 6. The number of header bytes (TOC byte,

frame count byte, padding length bytes, and frame length bytes), plus

the signaled length of the first M-1 frames themselves, plus the

signaled length of the padding MUST be no larger than N, the total

size of the packet.

Valin, et al. Standards Track [Page 20]

剩余325页未读，继续阅读

毕加索解锁

粉丝: 2696
资源: 24

Opus音频编解码器定义与应用

"RFC-5404: G.719 RTP Payload Format

RFC-33A无线模块的STM32接收发送程序

RFC-30F硬件开发指南：无线通信模块详解

RFC-7845 Ogg Encapsulation for the Opus Audio Codec (Opus)

opus-codec-translate:opus-codec 的翻译

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

RFC-5104 Codec Control Messages in the RTP Audio-Visual Profile

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

RFC-33A.rar_rfc-33a

rfc-index.zip_RFC_index_rfc-all

最新资源