javascript - 使用 Javascript 和 Web 音频 API 流式传输 Icecast 音频和元数据

Question

我一直在试图找出实现我已经有一段时间的想法的最佳方法。
目前，我有一个 radio 扫描仪的 icecast mp3 流，其中“正在播放”的元数据会根据扫描仪登陆的 channel 实时更新。当使用 VLC 等专用媒体播放器时，元数据与接收到的音频完美对齐，并且它的功能完全符合我的要求 - 本质上是一个远程 radio 扫描仪。我想通过网页实现类似的东西，表面上这似乎是一个简单的任务。
如果我只想流式传输音频，使用简单的 <audio>标签就足够了。然而，HTML5 音频播放器没有嵌入流内元数据的概念，icecast 与 mp3 音频数据一起编码。虽然我可以从 icecast 服务器状态 json 查询当前“正在播放”的元数据，但由于客户端和服务器端缓冲，以这种方式完成时，音频和元数据之间可能会有超过 20 秒的延迟。在某些情况下，当扫描仪每秒更改其“正在播放”的元数据时，这完全不适合我的应用程序。
有一个非常有趣的 Node.JS 解决方案，它的开发考虑了这个确切的目标 - radio 扫描仪应用程序中的实时元数据:icecast-metadata-js .这表明确实可以同时处理来自单个 icecast 流的音频和元数据。现场演示尤其令人印象深刻:https://eshaz.github.io/icecast-metadata-js/
但是，我正在寻找一种无需安装 Node.JS 即可完全在客户端运行的解决方案，而且这似乎应该是相对微不足道的。
今天搜索了一天的大部分时间后，似乎在本网站和其他地方提出了几个类似的问题，但没有任何连贯的、布局合理的答案或建议。从我目前收集到的信息来看，我相信我的解决方案是使用 Javascript 流式处理函数(例如 fetch )从 icecast 服务器中提取原始 mp3 和元数据，通过 Web Audio API 播放音频并在元数据 block 到达时处理它们。如下图所示:

我想知道是否有人有任何好的阅读和/或通过 Web Audio API 播放 mp3 流的示例。在大多数 JS 方面，我仍然是一个相对新手，但我了解了 API 的基本概念以及它如何处理音频数据。我正在努力实现的正确方法是:a)实时处理来自 mp3 流的数据，以及 b)检测流中嵌入的元数据 block 并相应地处理这些 block 。
抱歉，如果这是一个冗长的问题，但我想提供足够的背景故事来解释为什么我想以我的具体方式去做事情。
提前感谢您的建议和帮助!

Answer 1

很高兴你找到我的图书馆 icecast-metadata-js !这个库实际上可以在客户端和 NodeJS 中使用。完全在客户端运行的现场演示的所有源代码都在存储库中:https://github.com/eshaz/icecast-metadata-js/tree/master/src/demo .演示中的流没有改变，只是服务器端的普通 Icecast 流。
您在图表中的内容基本上是正确的。 ICY 元数据交织在实际的 MP3“流”数据中。 ICY 元数据更新发生的元数据间隔或频率可以在 Icecast 服务器配置 XML 中进行配置。此外，这可能取决于您的来源向 Icecast 发送元数据更新的频率/准确度。在我的演示页面上，警察扫​​描仪中使用的软件几乎与音频同步更新。
通常，默认元数据间隔为 16,000 字节，这意味着对于每 16,000 个流 (mp3) 字节，将从 Icecast 发送元数据更新。元数据更新总是包含一个长度字节。如果长度字节大于0，则元数据更新的长度为元数据长度字节*16。
ICY 元数据是一串由分号分隔的 key='value' 对。元数据更新中任何未使用的长度都是空填充的。
即"StreamTitle='The Stream Title';StreamUrl='https://example.com';\0\0\0\0\0\0"

read [metadataInterval bytes]        -> Stream data
read [1 byte]                        -> Metadata Length
if [Metadata Length > 0]
   read [Metadata Length * 16 bytes] -> Metadata

字节长度
响应数据
行动


ICY 元数据间隔
流数据
发送到您的音频解码器

1
元数据长度字节
用于确定元数据字符串的长度(不发送到音频解码器)

元数据长度 * 16
元数据字符串
解码并更新您的“正在播放”(不要发送到音频解码器)


首字母 GET对 Icecast 服务器的请求需要包含 Icy-MetaData: 1 header ，它告诉 Icecast 提供交错的元数据。响应 header 将包含 ICY 元数据间隔 Icy-MetaInt ，应被捕获(如果可能)并用于确定元数据间隔。
在演示中，我使用客户端获取 API 来发出 GET 请求，响应数据被提供到 IcecastReadableStream 的实例中。它将流和元数据分开，并通过回调使每个可用。我正在使用 Media Source API 播放流数据，并获取定时数据以正确同步元数据更新。
这是读取 ICY 元数据所需的最低 CORS 配置:

Access-Control-Allow-Origin: '*' // this can be scoped further down to your domain also
Access-Control-Allow-Methods: 'GET, OPTIONS'
Access-Control-Allow-Headers: 'Content-Type, Icy-Metadata'

icecast-metadata-js如果需要，可以检测 ICY 元数据间隔，但最好允许客户端使用此附加 CORS 配置从 header 中读取它:

Access-Control-Expose-Headers: 'Icy-MetaInt'

另外，我计划发布一个新功能(在我完成 Ogg 元数据之后)，它封装了 fetch api 逻辑，因此用户需要做的就是提供一个 Icecast 端点，并取回音频/元数据。