RTMP 直播流采集可以通过“获取合法流地址、使用 FFprobe 检查输入、用 FFmpeg 分段录制、配置重试机制、验证文件完整性”五个步骤完成。对于生产环境，还需要同时处理鉴权信息保护、磁盘容量、时间戳异常、断流恢复和运行监控。

一、RTMP 直播流采集是什么

RTMP 直播流采集是指采集程序连接到 RTMP 服务端，持续接收视频流和音频流，并将其录制为本地文件、转码后分发，或者送入后续的审核、分析与归档系统。

常见链路

一条完整链路通常由推流端、RTMP 服务端和采集端组成：

推流端：摄像机、OBS、编码器或业务系统。
RTMP 服务端：接收并转发直播流。
采集端：通过 FFmpeg、GStreamer 或媒体服务读取并保存直播流。

本文以 FFmpeg 为主要采集工具，因为它支持 RTMP 输入、封装转换、分段录制、转码和错误日志输出，适合快速部署和自动化运行。

二、准备采集环境与确认授权

步骤 1：确认采集权限

开始配置前，应确认直播源属于自有系统，或者已经获得内容方和平台的明确授权。不要绕过登录、付费、访问控制或数字版权保护机制获取直播内容。涉及人像、语音、会议和医疗场景时，还应明确告知采集目的、保存期限和访问范围。

步骤 2：安装 FFmpeg

Ubuntu 或 Debian 可执行：

sudo apt update
sudo apt install -y ffmpeg

macOS 可通过 Homebrew 安装：

brew install ffmpeg

安装完成后检查版本和协议支持：

ffmpeg -version
ffmpeg -protocols

协议列表中应包含 rtmp；如果使用加密连接，还应确认构建版本支持 rtmps。

步骤 3：准备 RTMP 地址

典型地址格式如下：

rtmp://host:1935/app/stream-key

host 是服务器地址，app 是应用名称，stream-key 是流名称或鉴权密钥。生产环境不要把完整地址写入代码仓库、工单截图或公开日志，建议通过环境变量或密钥管理服务注入。

三、搭建本地 RTMP 测试链路

如果暂时没有可用直播源，可以先在本机启动一个 RTMP 服务，验证推流和采集命令。安装 Docker 后运行：

docker run --rm -p 1935:1935 -p 8889:8889 bluenviron/mediamtx:latest

步骤 1：生成测试推流

准备一个名为 sample.mp4 的测试视频，然后执行：

ffmpeg -re -stream_loop -1 -i sample.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-g 50 -keyint_min 50 -sc_threshold 0 \
-c:a aac -ar 48000 -b:a 128k \
-f flv rtmp://127.0.0.1:1935/live/test

以上命令以循环方式读取视频，并向本机的 live/test 路径推流。示例按 25 fps 设置 50 帧 GOP，对应约 2 秒关键帧间隔；如果帧率不同，可将 GOP 调整为“帧率乘以 2”。

步骤 2：使用 OBS 推流

也可以在 OBS 的“设置－直播”中选择自定义服务，将服务器填写为 rtmp://127.0.0.1:1935/live，串流密钥填写为 test。建议将关键帧间隔设为 2 秒，编码器选择 H.264，音频使用 AAC。

四、采集前检查直播流参数

不要直接进入长时间录制。先使用 FFprobe 检查流是否可访问，以及音视频编码、分辨率、帧率和采样率是否符合预期：

export RTMP_URL='rtmp://127.0.0.1:1935/live/test'
ffprobe -v error \
-show_entries stream=index,codec_name,codec_type,width,height,r_frame_rate,sample_rate,channels \
-of json "$RTMP_URL"

重点检查以下内容：

是否同时存在 video 和 audio 流。
视频编码是否为 H.264、H.265 等预期格式。
分辨率和帧率是否稳定。
音频采样率是否为 44100 Hz 或 48000 Hz。
连接是否出现超时、拒绝访问或鉴权失败。

五、使用 FFmpeg 分段采集 RTMP 直播流

步骤 1：创建保存目录

mkdir -p records

步骤 2：无转码分段录制

当原始音视频编码满足归档要求时，优先使用码流复制，避免重复编码造成画质损失和额外 CPU 消耗：

ffmpeg -hide_banner -loglevel info \
-rw_timeout 15000000 \
-i "$RTMP_URL" \
-map 0:v:0? -map 0:a:0? \
-c copy \
-f segment -segment_time 300 \
-reset_timestamps 1 -strftime 1 \
"records/%Y%m%d_%H%M%S.mkv"

该配置每 300 秒生成一个文件。? 表示对应音视频流不存在时不立即报错，-reset_timestamps 1 会重置每个分段的时间戳，MKV 封装则对异常中断和多种编码格式具有较好的兼容性。

步骤 3：转码为统一规格

如果下游系统只接受 H.264 和 AAC，可以在采集时转码：

ffmpeg -hide_banner -loglevel info \
-rw_timeout 15000000 \
-i "$RTMP_URL" \
-map 0:v:0? -map 0:a:0? \
-c:v libx264 -preset veryfast -crf 23 \
-c:a aac -b:a 128k -ar 48000 \
-f segment -segment_time 300 \
-reset_timestamps 1 -strftime 1 \
"records/%Y%m%d_%H%M%S.mkv"

转码能统一输出格式，但会提高 CPU 或 GPU 占用。并发采集前应进行压力测试，观察实时编码速度是否持续大于或等于 1.0x。

六、配置断线重连与后台运行

步骤 1：使用外层循环重启采集进程

RTMP 源中断后，FFmpeg 可能直接退出。可以通过 Shell 循环等待 3 秒后重新连接：

while true; do
  ffmpeg -hide_banner -loglevel info \
  -rw_timeout 15000000 \
  -i "$RTMP_URL" \
  -map 0:v:0? -map 0:a:0? -c copy \
  -f segment -segment_time 300 \
  -reset_timestamps 1 -strftime 1 \
  "records/%Y%m%d_%H%M%S.mkv"
  sleep 3
done

正式部署时，应限制连续重试频率，并记录退出码、断流时间和恢复时间，避免上游长期不可用时形成高频连接请求。

步骤 2：交给进程管理器托管

生产环境建议使用 systemd、Supervisor、Docker 或 Kubernetes 管理采集进程，至少配置以下能力：

进程异常退出后自动重启。
日志轮转和磁盘占用限制。
启动参数通过环境变量注入。
健康检查、告警和优雅停止。
限制运行用户和目录访问权限。

七、验证采集是否成功

方法 1：实时播放验证

使用 FFplay 连接直播源，检查是否存在黑屏、花屏、无声或明显卡顿：

ffplay -fflags nobuffer -flags low_delay "$RTMP_URL"

方法 2：检查录制文件参数

ffprobe -v error \
-show_entries format=duration,size \
-show_entries stream=codec_name,codec_type,width,height,avg_frame_rate,sample_rate \
-of json records/20250101_120000.mkv

需要确认文件时长接近设定的分段时长、文件大小合理、音视频轨道齐全，并且分辨率和采样率符合预期。

方法 3：执行完整解码测试

ffmpeg -v error -i records/20250101_120000.mkv -f null -

命令没有输出错误通常表示文件可以完成解码。验证时应选择已经关闭写入的分段；仍在写入的文件可能被误判为截断或损坏。

方法 4：检查连续性

连续运行至少 30 分钟，并检查相邻分段之间是否出现明显缺口。生产监控可以记录最新文件的更新时间、文件大小增量、采集帧率、错误日志数量以及重连次数。如果文件长时间不增长，应触发告警。

八、生产环境注意事项

磁盘容量估算

每小时存储量可按“总码率 Mbps × 450 MB”粗略计算。例如视频码率 6 Mbps、音频码率 0.128 Mbps，每小时约需 2.76 GB。计算保留周期时，还要预留文件系统开销、临时文件和至少 20% 的可用空间。

网络与安全

RTMP 默认不加密，公网传输应优先使用 RTMPS、VPN或专用网络。
限制采集服务器的入口和出口访问范围。
流密钥应定期轮换，不要记录到公开日志。
并发采集带宽应按所有直播流峰值码率之和估算。
跨地区采集要测试丢包、抖动和长连接稳定性。

时间戳与音画同步

如果日志出现非单调时间戳、音画不同步或帧顺序错误，应先检查推流端编码设置和服务器转发链路。不要仅通过提高缓存掩盖源端问题。确需修复时间戳时，应使用短时间样本验证后再部署，避免改变正常直播流的播放节奏。

文件生命周期

录制文件应配置自动归档和删除策略。建议按日期、频道和任务编号组织目录，并为文件写入完成、上传成功、校验通过和到期删除分别记录状态。

九、典型落地场景

场景 1：授权直播归档

会议、培训或自有直播间可采用无转码分段录制，以降低服务器资源消耗。录制完成后执行完整性校验，再上传对象存储并按保留周期清理本地文件。

场景 2：实时审核与分析

采集程序可以将 RTMP 输入转码为统一规格，再发送到语音识别、画面抽帧或内容审核流程。此类场景应重点关注端到端延迟、任务积压和敏感数据访问权限。

场景 3：多路直播监控

多路采集应为每个流建立独立任务，并设置频道级健康状态。单路断流不应导致其他任务退出；CPU、内存、出口带宽和磁盘写入性能也要分别设置告警阈值。

十、选型建议

如果目标是录制自有或已授权的 RTMP 地址，FFmpeg 配合进程管理器通常可以满足基础需求；如果项目还涉及公开网页、搜索结果或视频平台公开数据的批量获取，可以评估 Dataify 提供的视频数据、通用采集 API 和网络服务，将直播录制与公开数据采集拆分为不同链路。选型时应比较数据来源权限、接口返回格式、地区覆盖、并发能力、交付周期和按量成本，不能用公开视频数据接口替代自有 RTMP 流的实时录制。

常见问题

RTMP 直播流能直接保存为 MP4 吗？

可以，但直播录制过程中如果进程异常退出，MP4 文件可能因为索引信息未完成而无法正常播放。长期采集建议先保存为 MKV 或按较短周期分段，录制完成后再使用 ffmpeg -i input.mkv -c copy output.mp4 转封装。

为什么 FFmpeg 可以连接直播流，却一直没有生成文件？

先检查输出目录是否存在以及运行用户是否有写权限，再查看输入流是否真正包含音视频数据。如果使用分段输出，还要确认文件名格式、封装格式和编码是否兼容。磁盘空间不足、流长期无关键帧或地址已经过期也可能导致该问题。

出现 Server error、Connection refused 或鉴权失败怎么办？

依次确认主机、端口、应用名和流密钥是否正确，检查 RTMP 服务是否启动、防火墙是否放行端口，以及地址是否限制来源 IP。不要通过反复高速重试解决鉴权错误，应先更新有效凭据。

采集过程中频繁断流应该调整哪些参数？

先用持续 ping、链路监控和服务端日志判断是网络抖动、上游停止推流还是服务端主动断开。随后设置合理的读超时、外层重试间隔和进程告警。盲目增加缓冲只能改变延迟，不能解决丢包或上游断流。

什么时候适合使用第三方数据采集服务？

当需求从单路授权 RTMP 录制扩展到视频平台公开数据、网页或搜索结果的批量采集时，可以评估 Dataify 的视频数据 API、通用采集 API 及网络服务。评估前仍需确认目标数据的访问规则、使用授权、字段完整性和交付成本。

如何判断采集任务已经达到生产可用标准？

至少完成长时间稳定性测试、断流恢复测试、磁盘满载保护、文件解码校验、日志轮转和告警测试。同时验证凭据不会出现在日志中，并确认归档、访问控制和到期删除流程可以执行。

总结

RTMP 直播流采集的关键不是单次运行成功，而是建立可持续运行的闭环：先确认授权和流地址，再用 FFprobe 检查参数，通过 FFmpeg 分段录制，使用进程管理器处理异常退出，最后从播放、文件参数、完整解码和分段连续性四个方面验证结果。生产部署还应纳入容量估算、加密传输、凭据管理、监控告警和文件生命周期管理。

RTMP 直播流采集配置教程：从推流、录制到验证的完整实操