当我开始接收实时音频（无线电）流（例如 MP3 或 AAC）时，我认为接收到的数据不是原始比特流（即原始编码器输出），但它们总是被包装成某种容器格式。如果这个假设是正确的，那么我想我无法从流的任意位置开始流式传输，但我必须等待某个同步字节。那正确吗？通常有一些同步字节吗？同步字节后面是否有任何标题，我可以从中猜测使用的编解码器、通道数、采样率等？
当我连接到直播时，我会从最近的同步字节开始接收数据，还是从实际位置获取数据，我必须先检查同步字节？
像icecast这样的一些流在HTTP响应中使用标头，其中包含流相关信息，但我认为我可以跳过它们并直接处理steam格式。
对吗？
问候，
不锈钢
【问题讨论】：
标签： audio mp3 audio-streaming live-streaming icecast
Doom9 有关于 mpeg 和 aac 帧格式的很好的起始信息。 Shoutcast 会时不时地添加一些“元数据”，这真的很简单。我想和你分享的是这个；我有一个可以捕获各种流的应用程序，并且其中包括 aac 和 mp3 的广播。第一个版本根据时间在任意点剪切文件，例如每 5 分钟一次，无论 mp3/aac 帧如何。对 mp3 来说还可以（文件可以播放），但对 aacplus 来说就很糟糕了。
问题是 - aacplus 解码器不能容忍错误的数据，而且我拥有从访问违规到神秘的软件关闭的一切，没有任何错误。
无论如何，如果你想捕获流，打开到服务器的套接字，读取响应，你会有一些标题，然后使用该信息来剥离将不时注入的元数据。使用 aacplus 和 mp3 的标头信息来确定帧边界，并尝试尊重它们并在正确的位置拆分文件。
mp3帧头：
aacplus 帧头：
还有这个：
【讨论】：
我将通过回答自己来继续讨论（即使我们不鼓励这样做）：
我也在研究流数据，发现经常重复序列 ff f3 82 70 - 我建议这是 MPEG 帧头，所以我试着看看这意味着什么：
ff f3 82 70 (hex) = 11111111 11110011 10000010 01110000 (bin)
Analysis
11111111111 | SYNC
10 | MPEG version 2
01 | Layer III
1 | No CRC
1000 | 64 kbps
00 | 22050Hz
1 | Padding
0 | Private
01 | Joint stereo
11 | ...
有什么相关的吗？
当开始接收流数据时，我是否应该在将缓冲区提供给处理 DSP 的类之前丢弃此标头之前的所有数据？我知道这可能是特定于实现的，但我想知道这里的程序一般是什么......
BR 斯滕
【讨论】：
当您查看 SHOUTcast/Icecast 时，遇到的数据是纯 MPEG Layer III 音频数据，仅此而已。 （前提是您没有请求元数据。）
它可以在任意位置剪切，所以你需要同步到流。这通常是通过查找潜在的标头并使用该标头中的数据来查找顺序标头来完成的。找到一些帧头后，您可以放心地假设您已同步到流并开始解码以进行播放。
同样，这些没有“容器格式”。这只是原始数据。
现在，如果您需要元数据，您必须从服务器请求它。然后每隔x 个字节将数据注入到流中。见http://www.smackfu.com/stuff/programming/shoutcast.html。
【讨论】：
不幸的是，这并不总是那么容易，请在此处查看格式和注释： MPEG frame header format
【讨论】：