EasyLive实战：基于ffmpeg的流汇聚与转发全解析

简介：EasyLive是一款基于ffmpeg实现的流汇聚与转发工具，支持RTSP、RTMP及本地视频文件输入，输出RTSP、RTMP并可直接录制到本地，适合音视频开发者、流媒体运维人员以及相关项目集成场景使用。压缩包共74个文件，主要由可执行程序、动态链接库、配置文件、脚本及说明文档等构成，其中exe与dll提供核心运行能力，conf与xml用于参数与规则配置，bat和txt则方便快速部署与查阅，整体包体仅16.54MB，轻量易用。该资源已有664人学习，其核心代码沉淀了作者多年的音视频产品经验，功能稳定可靠。内含配套的流服务组件与常用配置模板，能帮助读者快速搭建汇聚转发环境，理解ffmpeg在流媒体工程中的实际应用方式，是一份兼具实用性与参考价值的工具型资源。

1. EasyLive 是什么：一个基于 ffmpeg 的流汇聚与转发入口

做流媒体的人几乎都碰过这种活：一堆摄像头走 RTSP，几路推流走 RTMP，总部要把这些源统一拉到一处，再转推给不同平台。单独拉一路容易，写个 ffmpeg 命令就行；几十路一起管，不再重启进程、不丢流、转发目标还能随时改，这就不是命令能扛住的事了。EasyLive 就是围绕这个场景做的 ffmpeg 流汇聚与转发工具，它把拉流、转封装、转码、多目标推流做成了一套可配置、可管理、可自动重连的流程。适合安防监控整合、多平台分发、直播信号汇聚这类诉求，也适合刚从「手敲 ffmpeg 命令」升级到「用工具管理流生命周期」的开发者，本文按实践路径拆透它的原理、配置与易踩的坑。

2. 流汇聚底层逻辑：为什么用 ffmpeg 而不是自研转发模块

2.1 拉流、转封装、转码、推流的完整生命周期

一条流从源头到达播放端，本质上是四个阶段：输入协议解析、解码或透传、编码或重封装、输出协议封装。EasyLive 基于 ffmpeg 来做这件事，意味着这四个阶段全部复用 ffmpeg 的成熟实现，而不是自己从零写 RTSP 客户端或 FLV 封装器。

输入阶段最常见的是 RTSP 拉流。ffmpeg 通过rtspdemuxer 与远程摄像头建立会话，默认走 UDP 传输，带宽占用小，但公网丢包容易花屏；换成 TCP 传输，数据可靠性明显提升，代价是延迟略增。输入阶段还有一层探测逻辑，ffmpeg 会先分析一段码流来识别编码格式、分辨率、帧率，再决定后续如何处理，这就是-probesize和-analyzeduration参数在控制的东西。

中间阶段是转封装或转码。转封装指的是-c copy直接搬运压缩后的数据包，不改变编码格式，只改变容器，开销极低，适合源编码和目标平台都接受 H.264/AAC 的场景。转码则是用-c:v libx264这类参数重新编码，能改变分辨率、码率、编码格式，但 CPU 开销随路数线性上涨。EasyLive 允许按输入源粒度选 remux 还是 transcode，这是它比「一个 ffmpeg 命令打天下」更灵活的关键点。

输出阶段决定数据以什么协议推出去。RTMP 推流封装为 FLV；RTSP 转推则复用 RTSP 协议；如果需要 HLS，ffmpeg 会做切片输出。输出时的缓冲参数、GOP 对齐、音视频时间戳修正都发生在这一层。把这条链路拆清楚，后面调延迟、查黑屏才有的放矢。

2.2 流汇聚的两种模式：转封装（remux）与转码（transcode）如何选

先看一段 EasyLive 内部常见的输入配置思路，假设有一路 RTSP 摄像头要汇聚后转推 RTMP：

inputs: - name: cam_01 url: rtsp://192.168.1.100:554/stream1 transport: tcp probe_size: 5000000 analyze_duration: 5000000 outputs: - name: rtmp_platform_a url: rtmp://192.168.1.20/live/cam01 format: flv video_codec: copy audio_codec: copy

video_codec: copy和audio_codec: copy就是 remux 模式的开关。此时 ffmpeg 只做解封装再封装，CPU 占用极低，一台普通机器能汇聚很多路。但有两个前提：源编码必须是 H.264，音频必须是 AAC 或 G.711 这类 RTMP/FLV 支持的格式；源的分辨率和码率如果过高，下游平台又不接受，就必须转码。

转码模式下，ffmpeg 会解码、缩放、重新编码。比如把 4K 降为 1080P，或把 H.265 转成 H.264 以兼容某些播放器：

outputs: - name: rtmp_platform_b url: rtmp://192.168.1.30/live/cam01 format: flv video_codec: libx264 video_bitrate: 2500k video_preset: veryfast video_tune: zerolatency video_gop: 50 audio_codec: aac audio_bitrate: 128k

video_tune: zerolatency对实时流非常关键。libx264 默认会引入较高的编码延迟，zerolatency让编码器尽量即时输出，适合监控、直播这类不允许画面积压的场景。video_gop: 50控制关键帧间隔，GOP 越大压缩率越高，但播放器起播、切流时等待关键帧的时间也越长。究竟是 copy 还是转码，判断标准很简单：数据能被下游「原样接收」就 remux，接收不了或质量需要裁剪就 transcode。

2.3 选型边界：项目里什么时候用 EasyLive，什么时候必须上重型媒体服务器

任何工具都有适用边界。EasyLive 这类基于 ffmpeg 做进程编排的方案，强项在于「轻」：不依赖数据库、不需要集群、单机部署就能把几十路流管理起来，配置改完重启进程即可，非常适合边缘节点、项目现场、中小规模汇聚场景。

它和重型媒体服务器在架构上的差异主要体现在两点。其一是协议支持：现成的流媒体服务器通常原生支持 RTMP 接入、HLS 分发、WebRTC 低延迟播放，EasyLive 要支持这些协议时，依赖 ffmpeg 本身对协议的实现，比如推 HLS 就需要额外生成 m3u8 和 ts 切片。其二是并发能力：流媒体服务器有专门的连接管理、鉴权、负载均衡机制，单机能扛数千路会话；EasyLive 本质上是把多路流拆成多个 ffmpeg 子进程来管理，瓶颈在进程数、文件描述符和 ffmpeg 自身的稳定性上。

这个边界决定了你的选型思路。如果目的是把某地的多路 RTSP 汇聚后转推到两三个平台，EasyLive 足够，而且调试直观——每一路流的日志就是 ffmpeg 的 stderr 输出。如果要做大规模公网分发、需要多租户鉴权、需要切片存储回放，那就应该考虑流媒体服务器。另一个容易被忽略的点：EasyLive 对流的健康检查依赖 ffmpeg 进程状态和流量统计，它不会像商业 CDN 那样做内容级感知，所以关键业务上游出现「有流量但画面花屏」时，仍然要靠 ffprobe 这类工具辅助判断，下一章我会演示具体命令。

3. 拉通第一路流：部署配置与最小可用验证

3.1 前置环境准备：ffmpeg 版本、编译选项与运行目录

EasyLive 核心依赖 ffmpeg，环境里必须先有可用的 ffmpeg 命令行。不同发行版自带的 ffmpeg 编译选项差别很大，有的没有 RTSP 拉流所需的rtsp demuxer，有的没带libx264编码器，转发时直接报Unknown encoder。我一般会在部署前先跑一条命令确认能力集：

ffmpeg -version && ffmpeg -encoders 2>/dev/null | grep -E 'libx264|aac' && ffprobe -version

ffmpeg -version查看版本和编译配置，重点是看有没有--enable-libx264和--enable-gpl字样。ffmpeg -encoders列出全部编码器，grep过滤出 H.264 和 AAC，确认转码能力可用。ffprobe -version单独确认探测工具存在，后面做链路验证要靠它。

版本建议用 4.x 以上的主线版本，太老的版本在 RTSP 重连参数、-rw_timeout这些选项上行为差异很大。如果系统自带版本过旧，不要纠结，直接编译一个静态版本或使用第三方构建版，放到/usr/local/bin下，并把该目录放到 PATH 最前面，避免和系统自带版本相互干扰。目录方面，EasyLive 通常需要一个独立的运行目录，我习惯建/opt/easylive，里面再分conf、logs、pid三个子目录，配置、日志、运行 PID 分开管理，排查问题时效率高很多。

注意运行时依赖的动态库也要检查。用ldd $(which ffmpeg)能看到它链接了哪些共享库，缺库时拉流行为会变得很诡异——有时能跑但突然崩溃，有时直接报找不到文件。这些前置问题不解决，后面所有配置都是空中楼阁。我自己吃过一次亏：某次部署在最小化系统上，ffmpeg 能启动但一拉流就段错误，查了半天才发现缺了libz.so。

3.2 拉通第一路 RTSP：最小配置怎么写、参数怎么选

前置环境弄好后，先不要急着配几十路。拉通一路，验证链路是通的，再往上叠加。以下是一个能跑通的最小配置示例（YAML 形式，EasyLive 常见做法是把配置放在conf/input.yaml里）：

inputs: - name: cam_01 url: rtsp://user:password@192.168.1.100:554/Streaming/Channels/101 transport: tcp rw_timeout: 5000000 outputs: - name: local_output url: rtmp://192.168.1.20/live/cam01 format: flv video_codec: copy audio_codec: copy

把这段配置提交给 EasyLive 后，工具会为cam_01启动一个 ffmpeg 进程，实际执行的命令等价于：

ffmpeg \ -rtsp_transport tcp \ -rw_timeout 5000000 \ -i "rtsp://user:password@192.168.1.100:554/Streaming/Channels/101" \ -c:v copy -c:a copy \ -f flv "rtmp://192.168.1.20/live/cam01"

-rtsp_transport tcp强制 RTSP 用 TCP 传输，公网拉流时能避免 UDP 丢包导致的花屏和花音，代价是延迟略增，内网无所谓，公网建议强制开启。-rw_timeout 5000000单位是微秒，即 5 秒，控制单次读写超时，超时后 ffmpeg 会尝试重连或退出，由 EasyLive 的守护逻辑接管重启。URL 里包含用户名密码的写法是摄像头最常见的鉴权方式，注意密码里如果包含特殊字符需要做 URL 编码，比如@要写成%40，否则解析会错位。

启动后，EasyLive 的日志目录下会生成cam_01.log，里面是这条 ffmpeg 管线的实时 stderr 输出。正常情况能看到Stream #0:0和Stream #0:1的流信息，说明输入解析成功；随后出现Output #0, flv代表输出封装成功。如果报Connection timed out，多半是网络不通或rw_timeout太短；如果报Method DESCRIBE failed: 401 Unauthorized，则是鉴权信息错误，去看 URL 里的用户名密码。

3.3 启动、验证、日志出口：怎么确认第一路流真的通了

配置没问题，接下来做三件事：启动服务、验证进程、验证画面。先启动 EasyLive，命令因部署方式而异，源码编译版通常长这样：

cd /opt/easylive && ./easylive start --config conf/input.yaml

启动后第一件事是确认进程树是否正常。EasyLive 是主进程管理 ffmpeg 子进程的模型，所以至少要看到两个进程：easylive本身和它拉起的ffmpeg。ps -ef | grep -E 'easylive|ffmpeg'能一眼看到父子关系。如果只有主进程没有 ffmpeg 子进程，说明配置解析或启动参数出了问题，去logs/下看主日志。

第二件事是确认流数据在流动。用 ffprobe 去探测转发端的地址，看能不能拉回信息：

ffprobe -v error \ -show_entries stream=codec_type,codec_name,width,height,r_frame_rate \ -of default=noprint_wrappers=1 \ -rtsp_transport tcp \ "rtmp://192.168.1.20/live/cam01"

这里-show_entries stream=codec_type,codec_name,width,height,r_frame_rate指定只输出需要的流字段，避免刷屏；-of default=noprint_wrappers=1去掉多余的包装，输出干净。如果返回了codec_type=video、codec_name=h264、具体的宽高和帧率，说明转发目标已经能正常拉流。

第三件事才是看画面。ffplay 直接拉流播放是最直观的验证方式，但有图形界面的测试机才能用：

ffplay -rtsp_transport tcp -fflags nobuffer -flags low_delay "rtmp://192.168.1.20/live/cam01"

-fflags nobuffer关掉输入缓冲，-flags low_delay降低播放延迟，这两个参数让画面尽快出来，验证的是端到端延迟感。看到画面后，第一路流就算真正打通了。这时再回头检查logs/cam_01.log里的报错级别，看有没有非致命的警告——比如timestamp discontinuity这类提示，虽然不影响播放，但对后面排查延迟和音画同步问题有预判价值。

4. 多路汇聚与转发规则：从一处拉流到多处推送

4.1 多路输入的 YAML 结构：公共参数与独立参数怎么分层

单路通了，接下来就是让 EasyLive 发挥真正价值的场景：几十路源汇聚到一处，再按规则分发。多路输入配置比单路多了两个关键设计：公共默认值与会话级覆盖。

以一套「8 路内网摄像头 + 2 路公网 RTMP 源 + 2 路第三方拉流」的混合源配置为例：

global: transport: tcp rw_timeout: 5000000 reconnect: 1 reconnect_streamed: 1 reconnect_delay_max: 5 inputs: - name: cam_group_a_01 url: rtsp://admin:pass@192.168.1.101:554/Streaming/Channels/101 probe_size: 5000000 analyze_duration: 5000000 - name: cam_group_b_01 url: rtsp://admin:pass@10.0.2.15:554/Streaming/Channels/101 transport: udp rw_timeout: 10000000 - name: rtmp_source_01 url: rtmp://192.168.1.200/live/feed1 format: flv

global段的参数属于「所有输入源没单独声明时都生效」的默认值。reconnect: 1、reconnect_streamed: 1、reconnect_delay_max: 5三件套是 RTSP 拉流断线重连的常见组合：允许重连，只对流式输入生效，重连最大间隔 5 秒。把这些放到global，内网的摄像头、公网的推流方全都适用。

单独在inputs里写的参数会覆盖全局值。cam_group_b_01把transport覆盖成udp，把rw_timeout加长到 10 秒，是因为这路源在专网内、丢包率低，UDP 能省带宽且延迟更小；而rw_timeout加长是为了容忍该源偶发的响应慢。probe_size和analyze_duration放在内网摄像头上，是因为部分摄像头 RTSP 响应慢，缩短探测规模可以加快起播速度，避免启动阶段就超时。

这个「公共兜底 + 单路覆盖」的设计思路，价值在于线上维护。现场加了 20 路摄像头，只需要把 IP 和通道号按模板填进inputs列表，公共参数全继承，不用每行都重复写一长串参数。我见过有人把每路流的 RTSP 地址、rw_timeout、transport全部逐字写一遍，一旦发现某组参数需要整体调整，就要改 20 个地方，容易漏也容易错。分层配置是 EasyLive 这类工具减少重复、提升维护效率的关键点，值得从一开始就养成习惯。

4.2 转发目标与实时参数：秒开、缓冲、断流重启

汇聚进来的流往外推，需要为每个转发目标单独定义输出参数。原因在于不同平台对实时性的要求差异很大：监控大屏希望秒开、低延迟；录播平台更看重连续性和码率平滑；公网转发往往还要做转码压缩。看下面这组分发配置：

outputs: - name: monitor_wall url: rtmp://192.168.1.20/live/monitor format: flv video_codec: copy audio_codec: copy fflags: nobuffer flush_packets: 1 - name: recording_storage url: rtmp://192.168.1.50/record/cam01 format: flv video_codec: libx264 video_bitrate: 2000k video_preset: medium video_gop: 100 - name: public_cdn url: rtmp://192.168.1.80/live/cam01 format: flv video_codec: libx264 video_bitrate: 1500k video_preset: veryfast video_tune: zerolatency audio_codec: aac audio_bitrate: 64k video_bufsize: 3000k

monitor_wall走纯 copy 模式，并加了fflags: nobuffer、flush_packets: 1，这两个参数让 ffmpeg 尽量把数据包立刻吐给输出端，减少本地缓冲，对监控上墙的秒开体验影响很大。代价是网络抖动时容易出现短时断流，但内网大屏场景通常能接受。

recording_storage走向录播平台，这里没有加zerolatency，反而把video_gop拉到 100，因为存储场景多花零点几秒延迟无所谓，更大的 GOP 间隔意味着更小的码流体积，存储成本能压下来。video_preset: medium是编码速度和压缩率的平衡点，存储服务器通常 CPU 充裕，可以稍微牺牲速度换码率。

public_cdn走公网，强调实时性和带宽控制：veryfast降低编码延迟，zerolatency去掉编码器缓冲，bufsize设为码率的 2 倍，平滑输出。这类面向公网的输出，如果接入平台要求 RTMP 必须带flv格式的 timestamp 修正，EasyLive 内部一般会自动追加-flvflags no_duration_filesize，不需要手动配。理解这三类目标的差异后，再遇到「同一路流推不同平台」的转发需求，就能按各自平台的要求拆分输出，而不是所有目标共用一组参数。

5. 高频踩坑与排查：断流、延迟、CPU 飙高的修正

5.1 现象：摄像头 RTSP 偶发断流，转发端黑屏，但进程还活着

某次现场维护，监控大屏上的画面每隔十几分钟黑一次，几秒后自己恢复。看easylive主日志没有任何异常，ffmpeg子进程也没退出，黑屏期间只有logs/cam_01.log里反复出现RTP: missed 100 packets和max delay reached。

原因排查下来，是 RTSP 默认用了 UDP 传输，现场 Wi-Fi 和 4G 网关干扰导致 RTP 包丢失，ffmpeg 丢包后追不上时间戳就报max delay reached，表现为黑屏卡顿。它不致命，进程不会退出，但画面体验极差。

解决方法是强制切 TCP 传输：在对应输入源的配置里加transport: tcp，同时把rw_timeout调大到 10000000（10 秒），给重连留足时间。改完一路后验证 24 小时没再黑屏，再把其余有同样 PIN 的摄像头按批次切过去。从那以后我在现场默认就写transport: tcp，公网环境绝不使用默认的 UDP，这是排掉「偶发花屏黑屏」类问题最高频的一刀。

5.2 现象：延迟越拉越大，推到平台后比源端落后十几秒

客户反映推流到平台后，和源端画面对比延迟有十几秒，而且是持续累积的那种。logs里 ffmpeg 没有任何 error，CPU 也没有异常波动。

原因是编码链路上出现了缓冲堆积。当输出采取-c copy时，ffmpeg 会把输入源的 B 帧、GOP 结构原样搬运，如果源摄像头 GOP 设置过大且伴随后台小幅网络抖动，播放端等待关键帧的时间就会无情叠加。另一处隐患是转码场景下preset设置过于偏重质量，比如medium甚至slow，机器性能不够时编码队列积压。

解决分两步。第一步，排查输入源的 GOP 和编码参数，用 ffprobe 看关键帧间隔和帧结构，必要时到摄像头后台把 GOP 调到 50 以内；第二步，在转发参数里为所有实时场景同时追加-fflags nobuffer、-flags low_delay、-tune zerolatency（转码时），使画面输出偏向低延迟而非低码率。需要注意的是，单纯调 ffmpeg 参数只能改善 ffmpeg 自身的缓冲，源端 GOP 过大造成的拉流起播延迟，只能通过调整源设备参数根治。调完后重新 ffprobe 转发端，实测延迟降到 2 秒内才算合格。

5.3 现象：ffmpeg 进程 CPU 飙高，整机负载被拖垮

某次加了 10 路转发后，机器负载直线上升，top 里看到多个 ffmpeg 进程 CPU 跑到接近 200%。第一反应是「转码太多路」，但检查配置发现大部分输出都是video_codec: copy，理论 CPU 占用应该很低。

进一步排查，才发现问题不在编码器，而在输入源的分辨率过高。摄像头的默认主码流是 4K，虽然转推时是-c copy不转码，但 ffmpeg 在拉流阶段依然要解封装、解析每一帧的 SPS/PPS、维护解码时间戳，4K 高帧率流的 CPU 开销远高于 1080P。而且copy模式并不代表完全不解析编码数据，某些封装格式还要求 ffmpeg 提取帧信息写入 FLV 的 tag header。

解决思路：第一，在摄像头后台把输入源切换成子码流（通常 720P 或 1080P），弱化汇聚端的解析压力；第二，转发端确实需要高分辨率输出时，才单独为那一路配置转码，并把分辨率限制在 1080P 内、码率限制在 2Mbps 内，比如 4.2 节里的video_bitrate: 2000k。从那以后我每次部署前先统计各路源的分辨率规格，而不是只看输出配置，CPU 飙高这类「看着是转码问题、其实是源头分辨率问题」的坑就能提前避开。

5.4 现象：推到平台后画面正常，声音断断续续或完全没有

这种问题隐蔽性在于 ffmpeg 日志全程干净，画面也正常，只有音频链路是坏的。常见原因有两个：一是源摄像头音频编码是 G.711，而目标平台只接受 AAC，-c:a copy直接把 G.711 塞进 FLV，平台解析失败就静音或断续；二是源本身没有音频轨，但输出配置强制为audio_codec: aac，ffmpeg 会因找不到音频流而报Stream map error或者静默填充。

解决方法是先明确源端到底有哪些流：

ffprobe -v error \ -show_entries stream=index,codec_type,codec_name \ -of csv=p=0 \ -rtsp_transport tcp \ "rtsp://user:password@192.168.1.100:554/Streaming/Channels/101"

输出形如0,video,h264和1,audio,pcm_alaw，一眼看到音频编码。若是 G.711 且平台不支持，就把该输出的audio_codec改成aac，让 ffmpeg 做音频重编码而不是 copy。若是无音频轨，在输出配置里显式设置audio_codec: none，避免 ffmpeg 强行映射不存在的流。处理完音频问题后，平台拉流的声音恢复。音频这类问题光看日志查不出来，用 ffprobe 先摸清源端实际的流结构，是性价比最高的排查路径。

6. 用 ffprobe 做链路验证：转发前先测一测再说

6.1 一条命令验证源端与转发端的时间戳连续性

链路通不通，眼睛看不出来。我习惯在配置改动后、正式上线前，用 ffprobe 对源端和转发端分别做一次流探测，再对比二者的帧率、分辨率、编码信息是否一致，快速定位配置错误。

ffprobe -v error \ -show_entries stream=index,codec_name,width,height,r_frame_rate,avg_frame_rate \ -of default=noprint_wrappers=1 \ -select_streams v:0 \ -rtsp_transport tcp \ "rtsp://user:password@192.168.1.100:554/Streaming/Channels/101"

-select_streams v:0只取第一条视频流，把输出集中在需要的字段上。r_frame_rate是容器记录的帧率，avg_frame_rate是按帧时间戳计算出的实际平均帧率，二者偏差大，说明源端帧率不稳定，需要检查源设备或网络。对转发端地址执行同样的命令，和源端结果对比，就能知道转推过程中有没有发生帧率异常、分辨率变化、编码变化。

6.2 转发前的压测清单：必查项与参数速查

以下是我每次上线必查的一组压测项：用 ffplay 拉流观察画面是否流畅，确认黑屏时长；用 ffprobe 检查分离传输的流结构是否与源端一致，确认编码格式、分辨率、帧率没有意外变化；用top观察 ffmpeg 子进程 CPU 和内存是否平稳，确认转码路数没超过机器承载能力；用ls -l logs/*.log确认每个子进程日志持续写入且没有新增 error，确认断流重连是否在按预期工作。

每次上线前我都强制走一遍这套验证清单。早先吃过一次大亏：当时赶工期，源端与转发端的信息没核对就直接上了生产，结果转发端解出来是 H.265，下游平台只认 H.264，全链路黑屏，现场排查到半夜才发现是源端切换了编码。从那以后我每次配置完都先跑一次 ffprobe，把两端的流信息贴在笔记里对比，确认一致再动服务。这个习惯救了好多次，希望帮到你。

本文还有配套的精品资源，点击获取