audio - Shoutcast 服务器和客户端如何处理 mp3 帧头和帧依赖关系？

Question

短篇故事:

如果我自己打算接收然后发送由我的应用程序处理的 Shoutcast 兼容的音频流，那么如何使用 mp3(de/en)编码器库正确地做到这一点？伪代码或更好的 - 蹩脚的 mp3 特定代码将不胜感激。

很长的故事:

困扰我的更具体的问题是由 article about mp3 引起的。 ，其中说:

Generally, frames are independent items. Each frame has its own header and audio informations. There is no file header. Therefore, you can cut any part of MPEG file and play it correctly (this should be done on frame boundaries but most applications will handle incorrect headers). For Layer III, this is not 100% correct. Due to internal data organization in MPEG version 1 Layer III files, frames are often dependent of each other and they cannot be cut off just like that.

这让我想知道 Shoutcast 服务器和客户端如何处理帧头和帧依赖关系。

如果我想实现与大多数 Shoutcast 播放器的最大兼容性，我是否只需要编码为恒定比特率 (CBR)？

是完全使用 mp3 帧头还是从 Shoutcast 协议(protocol)特定的 HTTP 头推导出流格式？

Shoutcast 协议(protocol)是否保证(或者它是常见的良好做法)开始在帧边界上提供 mp3 流并继续响应在帧边界处被剪切的 block ？但是，用于流式传输实时音频的 mp3 帧的最小或推荐大小是多少？

Shoutcast 如何处理帧依赖关系 - 它是否对 mp3 编码做了一些特殊的事情以确保所服务的流没有依赖于先前帧的帧(如果这甚至可能的话)？或者它可能忽略了服务器端/客户端的这些依赖关系，从而降低了音频质量甚至是伪像？

Answer 1

SHOUTcast 服务器不知道也不关心通过它们传递的数据。他们按原样发送。您实际上可以通过 SHOUTcast 服务器发送任意数据并接收它。 SHOUTcast 将在缓冲区大小下降的任何地方对媒体数据进行分段。

由客户端重新同步数据。它通过定位帧头，然后进行解码来做到这一点。一旦编解码器有足够的帧来可靠地播放音频，它将开始输出原始 PCM。何时可以安全地开始播放取决于编解码器。由于编解码器知道它在解码媒体方面正在做什么，它知道它何时有足够的数据(包括比特储存器)开始没有伪影。还值得注意的是，位容器不能进行太远，因此处理它最多只需要几帧。

这是拥有一个相当大的缓冲区服务器端很重要的原因之一，以便在连接时尽快刷新到客户端。如果要快速开始播放，编解码器需要比当前帧更多的数据才能开始。