Opus音频编码在Ogg封装的标准定义

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

"RFC-7845 是一个定义了Ogg封装格式的文档，用于Opus音频编解码器，使得Opus编码的数据能够存储在Ogg逻辑比特流中。此文档是互联网标准轨道文档，由IETF发布并经过公众审查。" RFC-7845是互联网工程任务组（IETF）发布的一份标准跟踪文档，由Mozilla Corporation的T. Terriberry编写，并更新了RFC 5334的相关内容。这个文档的主要目的是定义一种将Opus音频编解码器的数据封装到Ogg容器格式中的方法。Opus是一种高效且适应性强的音频编码格式，特别适合于语音和音乐的传输，尤其是在网络带宽有限的情况下。 Ogg是一种开放源代码的多媒体容器格式，它允许将不同类型的媒体数据（如音频、视频等）封装在一起，形成一个单一的逻辑比特流。RFC-7845详细描述了如何将Opus编码的音频数据有效地封装进Ogg容器，以便于存储和传输。这包括了数据包的组织结构、同步机制、页和段的创建，以及错误检测和恢复策略。文档指出，此标准已经过广泛的公开审查，并获得了IESG（互联网工程指导小组）的批准。根据RFC 5741的互联网标准流程，该文档代表了IETF社区的共识。此外，用户可以访问 RFC 编辑器的网站获取关于文档当前状态、任何已知错误（errata）以及提供反馈的信息。 RFC-7845的发布意味着Opus音频编码在互联网上的应用得到了进一步的标准化，有助于提升兼容性和互操作性。这对于开发者来说是非常重要的，因为他们可以利用这个标准来开发支持Opus音频的播放器、流媒体服务和其他相关应用，确保在不同平台和设备上都能正确处理Opus编码的音频。 RFC-7845是关于Opus音频编解码器在Ogg容器中封装规范的重要文档，它促进了Opus格式在互联网音频领域的广泛使用和标准化。通过遵循这个标准，开发者可以确保他们的应用程序能够无缝地处理和传输Opus编码的高质量音频数据。

RFC 7845 Ogg Opus April 2016

fed to a decoder running at 48 kHz will always return 960 samples. A

demuxer can parse the TOC sequence at the beginning of each Ogg

packet to work backwards or forwards from a packet with a known

granule position (i.e., the last packet completed on some page) in

order to assign granule positions to every packet, or even every

individual sample. The one exception is the last page in the stream,

as described below.

All other pages with completed packets after the first MUST have a

granule position equal to the number of samples contained in packets

that complete on that page plus the granule position of the most

recent page with completed packets. This guarantees that a demuxer

can assign individual packets the same granule position when working

forwards as when working backwards. For this to work, there cannot

be any gaps.

4.1. Repairing Gaps in Real-Time Streams

In order to support capturing a real-time stream that has lost or not

transmitted packets, a multiplexer (muxer) SHOULD emit packets that

explicitly request the use of Packet Loss Concealment (PLC) in place

of the missing packets. Implementations that fail to do so still

MUST NOT increment the granule position for a page by anything other

than the number of samples contained in packets that actually

complete on that page.

Only gaps that are a multiple of 2.5 ms are repairable, as these are

the only durations that can be created by packet loss or

discontinuous transmission. Muxers need not handle other gap sizes.

Creating the necessary packets involves synthesizing a TOC byte

(defined in Section 3.1 of [RFC6716]) -- and whatever additional

internal framing is needed -- to indicate the packet duration for

each stream. The actual length of each missing Opus frame inside the

packet is zero bytes, as defined in Section 3.2.1 of [RFC6716].

Zero-byte frames MAY be packed into packets using any of codes 0, 1,

2, or 3. When successive frames have the same configuration, the

higher code packings reduce overhead. Likewise, if the TOC

configuration matches, the muxer MAY further combine the empty frames

with previous or subsequent nonzero-length frames (using code 2 or

variable bitrate (VBR) code 3).

[RFC6716] does not impose any requirements on the PLC, but this

section outlines choices that are expected to have a positive

influence on most PLC implementations, including the reference

implementation. Synthesized TOC sequences SHOULD maintain the same

mode, audio bandwidth, channel count, and frame size as the previous

packet (if any). This is the simplest and usually the most well-

Terriberry, et al. Standards Track [Page 7]

剩余34页未读，继续阅读

毕加索解锁

粉丝: 2610
资源: 24

Opus音频编码在Ogg封装的标准定义

Opus音频编解码源码

ogg格式音频文件

ogg 音频规范

RFC-6716 Definition of the Opus Audio Codec (Opus)

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

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

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

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

RFC-5340 OSPFv3 for IPv6 的中文翻译

rfc-brand-indicators-for-message-identification

最新资源