在整理线上音乐节、广播节这类活动的音频直播方案时很多人首先会想到“把视频推流出去”的常规做法。但音频类场景往往比视频更敏感用户对声音卡顿、延迟、音量忽大忽小的容忍度更低。以 Taka P.T.P - Voice BLARE FEST 2020 这类线上广播活动为背景如果要面向大量听众提供稳定、低延迟、高可听性的音频直播单纯套用视频直播模板往往不够。这篇文章会从一场“以声音为核心”的线上活动出发完整拆解音频直播的技术链路从音频采集、编码、推流到服务端接收、分发再到前端低延迟播放。内容会覆盖 FFmpeg、SRS、NGINX-RTMP、HLS、WebRTC 等常用组件并提供可复制的命令、配置和播放代码。适合正在做直播系统、音频社区、线上电台或远程音乐活动的开发者参考。1. 背景音频直播和视频直播的技术差异1.1 为什么音频直播不能照搬视频直播方案视频直播已经有非常成熟的方案推流端使用 OBS 或 FFmpeg服务端使用 SRS、NGINX-RTMP播放端使用 HLS、HTTP-FLV 或 WebRTC。但这套方案在纯音频场景中会遇到几个问题。第一视频直播默认会为画面分配大量码率而音频直播往往需要对音质做更精细的控制。如果直接沿用视频编码参数音频很容易被压成“能听但不清楚”的结果。第二视频直播允许 2 到 5 秒左右的缓冲用户不会觉得太明显。但音频直播一旦出现 1 秒以上延迟听众在互动环节就会明显感到“滞后”。尤其是广播节、电台直播、在线演唱会这类场景主持人说话和听众反馈之间的延迟会直接影响体验。第三视频直播对网络带宽的要求比较线性而音频直播对网络抖动、丢包更敏感。声音的连续性一旦被破坏听感会比画面卡顿更糟糕。所以音频直播的技术方案应该围绕“更低的延迟、更稳定的码率、更合理的音量处理”来设计而不是简单地把视频流程中的音频部分抽出来。1.2 线上广播节场景的整体技术链路以 Taka P.T.P - Voice BLARE FEST 2020 这样的线上广播活动为例典型的技术链路包含这几个部分音频采集端主持人或演出者的麦克风、调音台、声卡或者直接使用电脑/手机内置麦克风。编码推流端将采集到的音频编码为 AAC、Opus 或 MP3推送到流媒体服务器。服务端分发接收推流将音频流转成适合不同播放端的格式例如 RTMP、HLS、HTTP-FLV 或 WebRTC。播放端听众通过网页、小程序、App 或普通播放器收听。这里的核心不是“某一个组件”而是整条链路如何在延迟、音质、稳定性之间取得平衡。1.3 本文技术范围本文会重点演示一条可落地的音频直播链路采集端使用 FFmpeg 读取音频文件、麦克风或声卡输入。编码端输出适合网络传输的音频流。推流端使用 RTMP 或 SRT 协议将音频推送到服务端。服务端使用 SRS 或 NGINX-RTMP 接收并分发。播放端使用 hls.js 播放低延迟 HLS或使用 WebRTC 实现更低延迟播放。文中所有命令和配置都以“思路 示例”的方式呈现。不同工具版本差异较大复制到你的项目时需要根据实际环境做调整。2. 环境准备与方案选型2.1 操作系统和依赖工具音频直播并不挑操作系统但不同系统的音频采集设备名称、FFmpeg 参数会不一样。本文示例以常见的 Linux 服务器 本机测试环境为主但会同时标注 Windows 和 macOS 的采集方式。建议准备以下环境一台 Linux 服务器用于部署流媒体服务。CentOS 7、Ubuntu 20.04 及以上版本均可。一个本地电脑安装 FFmpeg用于推流测试。浏览器推荐 Chrome 或 Edge用于测试 WebRTC 播放。如果使用 Docker可以快速启动 SRS 或 NGINX-RTMP 容器。FFmpeg 的版本建议使用 4.4 以上版本。新版本对 Opus、SRT、WebRTC 相关协议的支持更好。不过我不建议盲目追求最新版本关键是当前发行版或 Docker 镜像里的版本能否满足你的编码需求。2.2 常见流媒体协议选型对比音频直播中最容易混淆的是协议选择。下面从延迟、适用场景、播放器兼容性三个维度做对比。协议延迟范围适用场景播放器兼容性RTMP2-5 秒推流端首选兼容性最好Flash 已淘汰但推流端仍在广泛使用HTTP-FLV1-3 秒网页播放支持较好需要通过 flv.js 等播放器HLS5-15 秒大规模分发兼容性极强iOS、Android、Web 均可播放LL-HLS1-3 秒低延迟 HLS 播放需要播放器支持参数较严格WebRTC0.2-1 秒实时互动、语音聊天、在线演出现代浏览器原生支持SRT0.5-2 秒推流和跨国传输抗丢包好主要用于推流端播放端需转封装对于推流端RTMP 依然是最稳妥的选择。对于播放端如果想要的是“即点即播”的大规模分发HLS 最通用如果要做强互动或者追求极低延迟WebRTC 更合适。2.3 本文最终选型为了让示例覆盖更多场景本文采用双链路方案推流端FFmpeg 将音频以 RTMP 协议推送到 SRS。分发端SRS 同时输出 HLS 和 HTTP-FLV。低延迟播放通过 SRS 的 WebRTC 能力输出 RTC 流。这种组合的好处是一套推流源可以服务多种播放端。普通听众走 HLS互动用户走 WebRTC互不影响。3. 音频采集与编码基础3.1 采样率、位深、声道的基本概念在配置 FFmpeg 之前需要先明确几个概念。采样率表示每秒采集声音样本的次数单位是 Hz。常见值有 44100 HzCD 音质、48000 Hz视频制作常用。音频直播建议使用 48000 Hz因为它和视频帧率更容易对齐而且在很多声卡上表现更稳定。位深表示每个采样点用多少 bit 来表示。常见值有 16 bit 和 24 bit。直播场景一般用 16 bit 足够了但如果是音乐现场24 bit 能保留更多动态范围。声道数则决定了是单声道、双声道还是多声道。线上语言类直播用单声道或双声道都可以。音乐演出建议保留双声道但不要盲目使用 5.1 声道因为绝大多数听众的终端设备无法还原。3.2 常见音频编码格式选择音频直播中编码格式直接决定了音质和码率。AAC兼容性最好iOS 和 Android 都支持。常见码率 128 kbps 到 256 kbps适合大多数网络环境。Opus延迟更低音质更好在相同码率下优于 AAC。但旧设备兼容性稍差。WebRTC 场景几乎都使用 Opus。MP3兼容性极强但编码效率相对较低。适合需要兼容老设备的场景。在 FFmpeg 推流时一般推荐 AAC 作为 RTMP/HLS 的音频编码格式Opus 作为 WebRTC / SRT 的音频编码格式。这样可以在兼容性和音质之间取得平衡。3.3 FFmpeg 采集本机音频的常见命令先看一个最简单的本地音频采集示例。下面的命令假设你在本地有一个音频文件并希望把它作为直播音频源。ffmpeg -re -i local_audio.mp3 -c:a aac -b:a 128k -ar 48000 -ac 2 -f flv rtmp://127.0.0.1:1935/live/audio解释一下参数-re按文件原始速度读取避免推流速度过快。-i local_audio.mp3输入音频文件。-c:a aac音频编码器设置为 AAC。-b:a 128k音频码率设置为 128 kbps。-ar 48000重置采样率为 48000 Hz。-ac 2设置为双声道。-f flv输出封装格式为 FLV用于 RTMP 推流。如果你是直接采集麦克风或声卡则需要处理系统设备名。不同系统差异很大这里给出三种常见写法。Windows 下使用 dshow 设备采集ffmpeg -f dshow -i audio麦克风 -c:a aac -b:a 128k -ar 48000 -ac 2 -f flv rtmp://127.0.0.1:1935/live/audioLinux 下使用 ALSA 设备采集ffmpeg -f alsa -i default -c:a aac -b:a 128k -ar 48000 -ac 2 -f flv rtmp://127.0.0.1:1935/live/audiomacOS 下使用 avfoundation 设备采集ffmpeg -f avfoundation -i :0 -c:a aac -b:a 128k -ar 48000 -ac 2 -f flv rtmp://127.0.0.1:1935/live/audio注意麦克风、:0这些设备名需要根据你的机器实际环境修改。可以先运行ffmpeg -devices查看可用设备。这里最重要的是理解FFmpeg 采集音频后会重新编码成直播流所需的格式。因此即使输入设备或文件格式不同推流端的参数都可以保持一致。4. 用 FFmpeg 实现音频推流4.1 准备测试音频内容在正式测试前建议准备一段 30 秒以上的音频文件。如果是一个线上广播活动的测试可以准备一段主持人口播、一首歌的剪辑或者直接生成一段正弦波用于链路连通性测试。生成测试音频可以用 FFmpeg 的 sine 源ffmpeg -f lavfi -i sinefrequency440:duration30 -c:a aac -b:a 128k test_audio.aac这条命令会生成一个 30 秒、频率为 440 Hz 的测试音频方便判断链路是否通。注意频率为 440 Hz 的声音听起来像持续的“嘟”声不要误以为系统出了问题。4.2 推流到 RTMP 服务RTMP 是当前推流端最常用的协议。它虽然老旧但兼容性极好几乎所有流媒体服务都支持接收 RTMP 推流。下面的命令将音频文件推送到 RTMP 地址ffmpeg -re -i test_audio.aac -c copy -f flv rtmp://127.0.0.1:1935/live/audio这里使用了-c copy意思是直接复制编码后的音频数据不再转码。因为test_audio.aac已经是 AAC 格式RTMP 可以直接封装。如果是外部文件则建议使用转码命令ffmpeg -re -i local_music.mp3 -c:a aac -b:a 128k -ar 44100 -ac 2 -f flv rtmp://127.0.0.1:1935/live/audio这里将码率设为 128 kbps采样率设为 44100 Hz。不同活动对音质要求不同。语言类节目 96 kbps 也够用音乐类节目建议 128 kbps 以上。4.3 推流到 SRT 服务SRT 协议适合网络不稳定的场景尤其是跨区域推流。它具备自动重传和丢包恢复能力比 RTMP 更抗抖动。FFmpeg 推流到 SRT 的命令如下ffmpeg -re -i local_music.mp3 -c:a aac -b:a 128k -ar 48000 -ac 2 -f mpegts srt://127.0.0.1:9000?modecallerlatency2000000参数解释-f mpegtsSRT 通常使用 MPEG-TS 封装。modecaller当前 FFmpeg 作为发起连接的一方。latency2000000设置最大延迟为 2000000 微秒也就是 2 秒。你可以根据网络情况调低或调高。SRT 适合作为“推流侧”的增强方案。如果活动有多地分会场主播和主会场之间网络不稳定SRT 往往比 RTMP 更可靠。4.4 生成低延迟 HLS 流如果服务端不负责转码你也可以用 FFmpeg 单独生成 HLS 分片。这种方法适合小规模活动或测试环境。ffmpeg -i local_music.mp3 -c:a aac -b:a 128k -hls_time 2 -hls_list_size 6 -hls_flags delete_segments output.m3u8解释关键参数-hls_time 2每个分片时长 2 秒。-hls_list_size 6播放列表最多保留 6 个分片。-hls_flags delete_segments删除已经过期的分片避免磁盘占用膨胀。这种方式的优点是简单缺点是扩展性差。如果同时有几千人观看建议还是使用 SRS 或 NGINX-RTMP 做服务端分发而不是让 FFmpeg 直接输出 HLS 文件。5. 服务端接收与分发5.1 使用 SRS 搭建基础流媒体服务SRS 是一个开源的流媒体服务器支持 RTMP、HLS、HTTP-FLV、WebRTC 等多种协议。在音频直播场景中SRS 可以做到“一路推流多路分发”。使用 Docker 启动 SRS 是最快的测试方式docker run --rm -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 8000:8000/udp -p 8000:8000/tcp \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 \ ./objs/srs -c conf/srs.conf这条命令会映射 RTMP 端口 1935、HTTP API 端口 1985、HTTP 服务端口 8080以及 WebRTC 使用的 8000 端口。不同镜像仓库和标签可能不同如果你无法访问指定镜像可以换成 Docker Hub 上的官方镜像。启动后SRS 默认会开启 RTMP 和 HLS。推流地址依然可以使用rtmp://127.0.0.1:1935/live/audio此时可以通过以下地址播放RTMP 播放rtmp://127.0.0.1:1935/live/audioHLS 播放http://127.0.0.1:8080/live/audio.m3u8HTTP-FLV 播放http://127.0.0.1:8080/live/audio.flv这些地址中的live是应用名audio是流名。实际项目中可以把流名改为频道 ID 或节目编号。5.2 SRS 的 WebRTC 低延迟播放配置如果希望使用 WebRTC 播放音频需要额外修改 SRS 配置。下面是一份简化的配置示例字段可能随 SRS 版本变化请以官方文档为准listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_api { enabled on; listen 1985; } http_server { enabled on; listen 8080; dir ./objs/nginx/html; } rtmp_server { enabled on; listen 1935; chunk_size 4096; } http_hooks { enabled on; on_play http://127.0.0.1:8080/api/v1/streams; } webrtc_server { enabled on; listen 8000; candidate $CANDIDATE; }这份配置说明以下几点candidate是 WebRTC 连接时告诉播放端“可以向哪个地址发送数据”的关键配置。如果是公网服务器需要设置为服务器公网 IP如果是本机测试可以设置为127.0.0.1。WebRTC 播放时拉流地址通常不是普通 HTTP 地址而是类似webrtc://127.0.0.1/live/audio这样的地址。由于 WebRTC 对 UDP 端口依赖较高服务器安全组或防火墙需要放行 UDP 8000 端口。SRS 的 WebRTC 配置在不同版本中差异较大。如果你使用的是 SRS 5.0 以上版本配置方式会和旧版不同。建议先用 Docker 跑通默认配置再根据日志调整参数。5.3 使用 NGINX-RTMP 作为备选方案如果你的服务器已经部署了 Nginx并且不希望引入额外服务可以考虑使用 NGINX-RTMP 模块。这里给出一个最简配置rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; } } } http { server { listen 8080; location /live { types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } alias /tmp/hls; } } }配置完成后需要创建 HLS 分片目录并给 Nginx 进程写入权限mkdir -p /tmp/hls chmod 755 /tmp/hlsNGINX-RTMP 的优势是配置简单和 Nginx 生态结合紧密。缺点是 WebRTC 支持较弱如果你想主打低延迟互动SRS 会更合适。6. 播放端接入与低延迟调优6.1 HLS 播放页面示例HLS 的兼容性最强适合大规模分发。下面是一个最简单的 HTML 播放器示例使用 hls.js 在浏览器中播放 HLS 音频流。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title音频直播 HLS 播放器/title script srchttps://cdn.jsdelivr.net/npm/hls.js1.5.7/script /head body h3音频直播测试/h3 audio idaudio controls autoplay/audio script const audio document.getElementById(audio); const streamUrl http://127.0.0.1:8080/live/audio.m3u8; if (Hls.isSupported()) { const hls new Hls({ lowLatencyMode: true, maxBufferLength: 5 }); hls.loadSource(streamUrl); hls.attachMedia(audio); hls.on(Hls.Events.MANIFEST_PARSED, function () { audio.play(); }); } else if (audio.canPlayType(application/vnd.apple.mpegurl)) { audio.src streamUrl; audio.addEventListener(loadedmetadata, function () { audio.play(); }); } /script /body /html这里的lowLatencyMode: true和maxBufferLength: 5是降低播放延迟的关键。前者让 hls.js 尽量使用低延迟模式后者限制最大缓冲长度为 5 秒避免播放器因为缓冲太多而越播越慢。6.2 WebRTC 音频播放思路WebRTC 的播放需要经过信令协商不能像 HLS 一样直接用一个audio标签播放。SRS 提供了 WebRTC 播放能力的 HTTP API 和 JavaScript SDK。实际项目中你可以按照如下流程实现从播放端向服务端请求 WebRTC 拉流地址。服务端返回 SDP 应答。播放端拿到 SDP 后通过 RTCPeerConnection 建立连接。将远端音频轨道绑定到audio标签。由于不同版本 SDK 差异较大这里不贴死一个版本的代码。建议参考 SRS 官方提供的 WebRTC 播放示例。整体思路是播放端不是直接请求流媒体地址而是先通过信令接口完成协商再建立对等连接。6.3 延迟优化参数参考音频直播的延迟来自采集、编码、推流、服务端分发、播放缓冲多个环节。下面是一个优化方向表优化点建议值或做法注意事项音频采样率48000 Hz避免多次采样率转换音频码率96-192 kbps根据场景和带宽调整GOP / 分片时长HLS 2 秒分片越短延迟越低但服务端压力越大播放端缓冲3-5 秒缓冲越大越稳定但延迟越高服务端队列根据并发调整不要设置过大的 GOP 缓存网络协议WebRTC 用于互动HLS 用于大规模广播需要注意的是低延迟和高稳定性是矛盾关系。不要为了追求 300ms 延迟而牺牲所有客户端的稳定性。建议在测试环境中做多组对比找出当前网络质量下的最优值。7. 常见问题与排查思路7.1 推流后播放端没有声音问题现象常见原因解决思路推流命令正常但播放端无声音音频设备静音或输入源为空检查播放器音量、系统音量确认 FFmpeg 日志中有音频流数据只有画面没有声音音频编码格式与播放器不兼容统一使用 AAC 音频编码检查播放器是否支持当前封装格式播放端延迟越来越大播放缓冲设置过大调小播放器缓冲检查服务端 GOP 缓存排查时先看 FFmpeg 推流日志里是否有类似Audio: aac的输出信息。如果没有说明输入源本身没有采集到声音。可以在 FFmpeg 命令中去掉推流地址先输出到本地文件验证输入源是否正常。ffmpeg -f alsa -i default -t 10 output.wav如果本地文件正常再排查推流和服务端配置。7.2 WebRTC 播放失败或连接超时问题现象常见原因解决思路浏览器无法播放 WebRTC 流服务器端口未放行检查 UDP/TCP 8000 端口是否开放连接超时candidate 地址配置错误将 candidate 设置为可访问的公网 IP能连接但无声音音频编解码器协商失败确认推流端编码格式支持 Opus 或请服务端转码WebRTC 问题大多和网络环境相关。建议先用官方 Demo 测试服务器是否正常再接入业务代码。7.3 HLS 播放列表 404 或持续加载HLS 出现 404通常是分片文件路径和播放列表路径不一致或者服务端没有写入权限。检查步骤确认 m3u8 文件是否生成。确认 ts 分片文件是否在同一个目录。确认 Nginx 或 SRS 的 HTTP 目录映射是否正确。如果磁盘满了也会出现分片无法写入的情况。8. 最佳实践与工程建议8.1 音频源质量和音量标准化音频直播最怕的是“源不好”。在实际广播活动中建议在采集端接入调音台或声卡避免直接使用电脑内置麦克风。推流前要统一响度避免节目之间声音忽大忽小。FFmpeg 可以使用 loudnorm 滤镜做响度标准化ffmpeg -i input.wav -af loudnormI-16:TP-1.5:LRA11 -c:a aac -b:a 128k output.aac这里的I-16表示目标响度为 -16 LUFS属于比较适合网络直播的值。实际参数可以根据活动风格调整。需要提醒的是响度处理会增加一定的转码延迟如果对低延迟要求极高可以在采集端或调音台先做好音量控制不在推流端做过重处理。8.2 推流安全与鉴权不要把推流地址和播放地址直接暴露在公网。实际项目中至少需要做两件事。第一推流鉴权。SRS 可以通过回调接口或 HTTP 回调校验推流密钥。也就是说推流端必须携带正确 token服务端才允许写入。第二播放防盗链。HLS 播放地址建议加上时间戳签名或者限制 Referer。对于 WebRTC 播放更推荐通过业务后端动态签发临时 SDP 请求权限而不是把固定流地址内置在客户端。8.3 断流自动重推与监控线上活动期间推流端可能因为网络抖动、电脑休眠、声卡掉线等原因中断。建议在推流端写一个简单的守护脚本检测 FFmpeg 进程是否存活如果退出则自动重启。以下是一个极简的 Shell 示例思路#!/bin/bash while true; do ffmpeg -re -i local_music.mp3 \ -c:a aac -b:a 128k -ar 48000 -ac 2 \ -f flv rtmp://127.0.0.1:1935/live/audio echo 推流进程退出5秒后重启... sleep 5 done这个脚本只适合测试。生产环境建议使用 systemd 或 supervisor 管理推流进程并加入日志和告警。8.4 生产环境配置建议在生产环境发布前建议按下面清单检查推流地址和播放地址是否做了鉴权。防火墙是否只放行必要端口。磁盘分片目录是否有独立空间并设置了过期清理。音频编码是否统一为 AAC 或 Opus避免播放端兼容问题。日志是否收集到统一平台方便排查推流中断。是否在低峰期做过压测确认服务器并发能力。音频直播的容错比视频直播更苛刻因为“听不清”比“看不清”更容易造成用户流失。上线前一定要用多个播放端、多种网络环境实测。8.5 安全边界提醒如果你是在业务系统中集成推流能力涉及用户上传音频、麦克风采集、直播发布等功能需要遵循最小权限原则。用户必须明确授权才能采集音频服务端要限制推流 IP、推流时长和并发路数不要允许任意用户推流到公共流名。另外涉及用户生成内容时建议先录制或转存到安全存储再决定是否公开分发。不要直接把用户原始音频流无限期暴露在公网。9. 总结与下一步学习这篇文章围绕线上广播活动的音频直播场景梳理了从 FFmpeg 采集推流、SRS/NGINX-RTMP 服务端分发到 HLS/WebRTC 播放的完整链路。你现在应该能理解音频直播和视频直播的核心差异也知道如何通过编码参数、分发协议和播放缓冲来控制延迟和稳定性。下一步可以分三个方向继续深入如果你侧重推流端可以重点学习 FFmpeg 的滤镜系统和 SRT 协议提升复杂网络下的推流稳定性。如果你侧重服务端可以深入学习 SRS 的 WebRTC 网关、鉴权回调、集群分发和监控指标。如果你侧重播放端可以研究 WebRTC 信令实现、低延迟 HLS 的播放器参数以及移动端的音频焦点处理。音频直播并不复杂但它需要开发者在细节上更有耐心。建议你先用 FFmpeg 推一段本地音频到 SRS再用浏览器分别通过 HLS 和 WebRTC 播放亲手感受延迟差异。搭好这条链路后再把鉴权、监控、响度处理等工程能力逐步加上去就能支撑一场真正面向听众的线上广播活动了。