通过基于 Web 的实时音频捕获和广播,最大限度地减少延迟

Posted

技术标签:

【中文标题】通过基于 Web 的实时音频捕获和广播,最大限度地减少延迟【英文标题】:Minimizing latency w/ web-based, live audio capture and broadcast 【发布时间】:2012-04-05 11:57:58 【问题描述】:

在对用户音频(来自麦克风、线路输入)进行基于网络的捕获/录制,然后将该音频实时广播给我们的听众时,我无法实现低延迟。本质上是一个基于网络的音频广播平台,但从广播者说话到听众听到它的延迟低于 2 秒,这是必不可少的。

我从 Icecast 开始,但即使在本地,我似乎也不会在几秒钟内出现延迟。这甚至不包括必须捕获用户的音频,然后将其发送回服务器进行流式传输。

我真的看到了 3 个主要部分:

    基于 Web 的音频捕获(可能带有 Flash?),将用户音频发送到: 媒体服务器(类似于 Icecast 或 Wowza) 用于实际收听的播放器(html5 w/Flash 后备)

所以我的问题是如何优化此过程以实现低延迟并仍然可以灵活地流式传输到任何设备?是否有关于使用什么服务器、编解码器等的最佳实践?

【问题讨论】:

您只是在编码语音吗?还是你也需要做音乐?您需要达到什么级别的音频质量? 主要是演讲,一些音乐,但如果这意味着更少的延迟,我可以牺牲质量。 48kbps 就可以了 我可以保证你不想使用 HLS。它只是对低延迟没有用。 【参考方案1】:

Icecast 应该是一个流媒体服务器,它的目标不是实现低延迟。使用 Iecast 时会有大约 5 秒的延迟是完全正常的,而且您对此无能为力。 HLS 更适合您的需求,因为它包含小段,每个段的持续时间不应低于 3 秒,这意味着您的延迟肯定会高于 3 秒。

如果您真的需要低延迟,请查看Mumble,它使用Opus 编解码器。

【讨论】:

以上是关于通过基于 Web 的实时音频捕获和广播,最大限度地减少延迟的主要内容,如果未能解决你的问题,请参考以下文章

WebRTC 实时音频流/广播 [关闭]

使用 Google Speech to Text API 从 Web 应用程序中的麦克风捕获实时音频 [关闭]

在 node.js 中使用 socket.io 通过 webrtc 广播实时音频

节点(套接字)实时音频流/广播

流式传输实时音频

Java Web 开发环境可以最大限度地缩短构建-部署-测试周期?