简介这份资源面向在 iOS 平台进行音视频开发的工程师聚焦 FFmpeg 多实例播放 HLS 流并叠加马赛克效果这一具体场景适合已具备一定 FFmpeg 与流媒体基础、希望深入自定义播放逻辑的中高级开发者参考。压缩包共 8 个文件由 4 个 .m 实现文件与 4 个 .h 头文件组成整体约 11KB涵盖视图控制器、视频帧提取器、工具类及应用代理等模块结构紧凑便于直接嵌入工程对照阅读。内容围绕 HLS 切片与 M3U8 索引机制、多解码上下文与播放线程的隔离管理、avformat_network_init 网络模块初始化及失败处理、YUV 帧上的马赛克滤镜链配置以及多实例时间同步与内存性能优化等关键环节展开可帮助读者理解多路流并行播放的完整实现思路与常见排错方向。目前已有 324 人学习下载。1. 多实例 ffmpeg 拼 HLS 马赛克一个被低估的监控画面合成方案手上有几路 HLS 直播流想把它们拼成一块马赛克画面第一反应往往是去找某个带界面的合成软件。但如果你已经有一台常年开机的 Linux 服务器最省事的做法其实是让多个 ffmpeg 实例各管一路流把解码后的原始帧吐到本地再用一个合成实例把画面拼起来。这套方案不依赖任何图形界面纯命令行就能跑适合做监控墙、多机位预览、直播导播的预览层。标题里的三个关键词——多实例、HLS 流、马赛克——分别对应三个独立的技术决策进程怎么拆、流怎么拉、画面怎么拼。这三件事拆开都不难难的是它们凑在一起时的时序和资源问题后面几章会把每一步的参数和坑讲透。2. 为什么用多实例而不是单进程多输入拆进程的取舍2.1 单进程多输入的真实瓶颈ffmpeg 本身支持一次吃多路输入用-i重复指定即可理论上一个进程就能拉四路 HLS 再拼成 2x2。小规模测试时这么写确实能跑但一旦路数上去、或者某一路网络抖动问题就来了。HLS 是分片拉取每路流的缓冲、重连、时间戳对齐都在同一个进程里竞争任何一路卡住都会拖慢整个 filter graph 的推进。更麻烦的是单进程里某一路解码报错往往直接让整个进程退出四路画面一起黑。多实例的思路是把「拉流解码」和「拼接编码」拆成两类进程。每路 HLS 由一个独立的 ffmpeg 实例负责它只做一件事把远端流解码成固定分辨率的原始帧通过本地管道或本地 socket 吐出去。合成实例只负责接收这些原始帧、拼图、再编码输出。这样某一路挂了只影响它自己合成实例那边表现为某块区域短暂静止或变黑其余画面不受影响。2.2 进程间怎么传帧三种通道对比拆进程之后帧数据怎么从解码实例传到合成实例是第一个要定的事。常见做法有三种各有适用场景。通道方式典型写法延迟稳定性适用场景标准输出管道-f rawvideo -配合 shell 管道低一般两三个实例调试阶段本地 TCP socket-f mpegts tcp://127.0.0.1:port中好多实例跨进程解耦命名管道 FIFOmkfifo后读写低一般同机、路数固定我一般会选本地 TCP。原因是管道和 FIFO 在某一端异常退出时容易留下半开状态排查起来费劲TCP 有明确的连接建立和断开配合-listen 1或客户端重连参数恢复逻辑清晰。代价是多一层网络栈开销但在本机回环上这点开销可以忽略。2.3 解码实例的最小命令先看单路解码实例怎么写。目标是把它拉到的 HLS 流解码成固定尺寸的 rawvideo通过 TCP 吐给合成实例。# 单路 HLS 解码实例拉流 - 解码 - 缩放 - rawvideo over TCP ffmpeg -hide_banner -loglevel warning \ -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 5 \ -i http://example.com/live/stream1.m3u8 \ -vf scale640:360,fps15 \ -pix_fmt yuv420p \ -f rawvideo tcp://127.0.0.1:5001逐项说明。-reconnect系列参数是 HLS 拉流的关键网络抖动时 ffmpeg 会自动重连而不是直接退出-reconnect_delay_max 5限制最大重连间隔避免长时间空等。-vf scale640:360,fps15把每路统一到相同分辨率和帧率这是后面能拼图的前提——尺寸不一致的帧没法直接拼。fps15是主动降帧监控预览场景没必要每路都跑 25 或 30 帧降帧能显著降低后面合成实例的压力。-pix_fmt yuv420p固定像素格式避免不同源格式不一致导致合成时色彩错乱。最后-f rawvideo tcp://...把裸帧推到本地端口。注意rawvideo 没有帧边界标记合成实例必须提前知道每帧的字节数也就是宽×高×1.5yuv420p 每像素 1.5 字节。640×360 一帧就是 345600 字节这个数字后面要用到。3. 合成实例怎么拼filter graph 与帧对齐3.1 用 xstack 还是 hstack/vstack 组合合成实例的核心是 filter graph。ffmpeg 提供两种拼图思路xstack一次布局多路hstack/vstack两两组合。四路 2x2 用xstack最直接它接受一个 layout 参数描述每路的位置。# 合成实例接收 4 路 rawvideo拼成 2x2编码输出 ffmpeg -hide_banner -loglevel warning \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5001 \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5002 \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5003 \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5004 \ -filter_complex \ [0:v][1:v][2:v][3:v]xstackinputs4:layout0_0|w0_0|0_h0|w0_h0[v] \ -map [v] \ -c:v libx264 -preset veryfast -tune zerolatency -g 30 \ -f flv rtmp://127.0.0.1/live/mosaicxstack的layout参数用|分隔每路位置0_0是左上w0_0是右上w0 表示第一路宽度0_h0是左下w0_h0是右下。这种写法比手动算坐标清晰路数变化时改 layout 即可。输出用libx264加-tune zerolatency-g 30把关键帧间隔压到 30 帧方便下游播放器快速起播。3.2 帧对齐为什么画面会「错位」多路 rawvideo 输入到同一个 filter graphffmpeg 默认按时间戳对齐。但 rawvideo 本身不带时间戳靠的是-r 15声明的帧率来推算。如果四路解码实例的实际出帧节奏不一致——比如某一路因为网络慢实际只有 12 帧每秒——合成实例会按 15 帧的节奏去取取不到就重复上一帧或直接卡住。表现就是某块画面比别的慢半拍或者整体出现周期性抖动。解决办法有两个方向。一是让解码实例严格按声明帧率输出用fps15滤镜强制补帧/丢帧保证出帧节奏稳定。二是在合成实例里加setpts或fifo缓冲但更简单的是接受轻微不同步因为监控预览场景对帧级同步要求不高。如果确实需要严格同步可以在解码实例输出前加-vsync cfr强制恒定帧率。3.3 路数不是 4 的整数倍怎么办实际项目里经常是 3 路、5 路、6 路。xstack的 layout 支持任意布局3 路可以排成 1x3 或 2x2 留空。留空的做法是给空位填一个纯色源用color滤镜生成。# 3 路输入排成 2x2右下角用纯黑填充 ffmpeg -hide_banner -loglevel warning \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5001 \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5002 \ -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:5003 \ -f lavfi -i colorcblack:s640x360:r15 \ -filter_complex \ [0:v][1:v][2:v][3:v]xstackinputs4:layout0_0|w0_0|0_h0|w0_h0[v] \ -map [v] -c:v libx264 -preset veryfast -tune zerolatency \ -f flv rtmp://127.0.0.1/live/mosaic-f lavfi -i color...生成一个纯黑视频源参数和真实路保持一致这样 xstack 不用改 layout。路数更多时同理缺几个补几个 color 源。4. 避坑与排查多实例马赛克最常见的五个翻车点4.1 合成实例启动时连不上解码实例现象是合成实例报Connection refused或一直卡在打开输入。原因是 TCP 连接有先后顺序如果合成实例先启动它去连 5001 端口时解码实例还没监听。解决方式是先启动所有解码实例确认端口在监听ss -ltn | grep 500再启动合成实例。或者反过来让解码实例用-listen 1做服务端合成实例做客户端这样解码实例先起就能等连接。4.2 某一路断流后整块画面冻结不恢复现象是某路 HLS 源中断几分钟后恢复但马赛克里那一块一直是最后一帧。原因是解码实例的 TCP 连接断了之后没有重连合成实例那边连接还在但收不到新数据。解决方式是在解码实例加-reconnect系列参数的同时给 TCP 输出加-f rawvideo tcp://...?listen0并配合外层脚本监控进程存活进程退出就重启。更稳的做法是用-f mpegts替代 rawvideompegts 有流同步信息断流恢复后合成实例能重新同步。4.3 CPU 占用随路数线性上涨现象是 4 路时 CPU 还能接受加到 8 路直接跑满。原因是每路解码实例都在做完整解码合成实例还要再编码一次。优化方向有三个一是解码实例用-vf scale把分辨率降到 320x180合成时再放大解码和传输压力都小二是合成实例的-preset从 veryfast 换到 ultrafast画质换 CPU三是如果源本身就是 H.264考虑用-c:v copy做流拷贝而不是解码但这样就没法拼图了只适合单路转发场景。4.4 画面颜色发灰或偏色现象是拼出来的画面比原始流暗一截或者颜色不对。原因是像素格式转换时色彩空间没对齐。HLS 源常见是 yuv420p但有些源是 yuvj420p全范围或带 BT.709 色彩标记。解码实例加-pix_fmt yuv420p只保证格式不保证色彩范围。稳妥做法是在解码实例加-vf scale640:360:in_rangeauto:out_rangetv,fps15显式指定输出为 TV 范围避免全范围转有限范围时的灰阶压缩。4.5 输出流播放器起播慢现象是合成后的 RTMP 流在播放器里要等好几秒才出画面。原因是编码器默认关键帧间隔太大播放器要等下一个关键帧才能解码。解决方式是合成实例加-g 30按 15 帧算就是 2 秒一个关键帧再加-tune zerolatency关掉编码器的帧缓冲。如果下游是 HLS 播放还要注意切片时长-hls_time 2配合-g 30能让切片边界和关键帧对齐。5. 进阶用脚本管理多实例与动态布局5.1 用配置文件驱动实例数量路数固定时手写命令还行路数经常变就得用脚本生成。我一般会写一个简单的配置文件每行一路包含流地址和端口然后用 shell 或 Python 读配置拼出启动命令。#!/bin/bash # start_mosaic.sh按 streams.conf 启动解码实例和合成实例 CONFstreams.conf PORT_BASE5001 INDEX0 INPUTS FILTER while read -r url; do [ -z $url ] continue port$((PORT_BASE INDEX)) # 启动解码实例后台运行 ffmpeg -hide_banner -loglevel warning \ -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 5 \ -i $url \ -vf scale640:360,fps15 -pix_fmt yuv420p \ -f rawvideo tcp://127.0.0.1:${port} echo decoder $INDEX - port $port pid $! INPUTS${INPUTS} -f rawvideo -pix_fmt yuv420p -s 640x360 -r 15 -i tcp://127.0.0.1:${port} INDEX$((INDEX 1)) done $CONF # 等待解码实例监听端口 sleep 3 # 根据路数生成 layout这里简单按每行 2 路排布 LAYOUT for ((i0; iINDEX; i)); do row$((i / 2)) col$((i % 2)) if [ $col -eq 0 ]; then LAYOUT${LAYOUT}0_${row}h0 else LAYOUT${LAYOUT}w0_${row}h0 fi [ $i -lt $((INDEX - 1)) ] LAYOUT${LAYOUT}| done # 启动合成实例 ffmpeg -hide_banner -loglevel warning \ $INPUTS \ -filter_complex [0:v][1:v]xstackinputs${INDEX}:layout${LAYOUT}[v] \ -map [v] -c:v libx264 -preset veryfast -tune zerolatency -g 30 \ -f flv rtmp://127.0.0.1/live/mosaic脚本逻辑说明。streams.conf每行一个 HLS 地址循环里为每路分配一个递增端口启动解码实例后把对应的-i参数拼进INPUTS变量。sleep 3是给解码实例留出监听时间实际部署时可以改成轮询端口。layout 生成部分按每行 2 路计算坐标0_${row}h0和w0_${row}h0分别表示该行左右两列。最后合成实例用拼好的参数启动。注意这个脚本里xstack的 inputs 数量是动态的但 filter graph 里只写了[0:v][1:v]实际路数超过 2 时需要把标签补全。更稳妥的做法是用 Python 生成完整的 filter_complex 字符串避免 shell 拼接出错。5.2 动态布局按路数自动选 2x2 还是 3x3路数在 4 以内用 2x25 到 9 用 3x3这是监控墙的常见排法。可以在脚本里根据 INDEX 判断选不同的 layout 模板。3x3 的 layout 写起来长一些但规律一样每行 y 坐标递增每列 x 坐标递增。关键是每路的分辨率要相应缩小2x2 时每路 640x3603x3 时每路 480x270这样总输出尺寸控制在 1920x1080 以内编码压力可控。5.3 验证合成结果是否正常跑起来之后怎么确认没问题。最直接的是用 ffplay 拉一下输出流看画面但服务器上没图形界面时可以用 ffmpeg 抽一帧存成图片检查。# 从合成输出流抽一帧存成 PNG 检查布局 ffmpeg -hide_banner -loglevel error \ -i rtmp://127.0.0.1/live/mosaic \ -frames:v 1 -y /tmp/mosaic_check.png抽帧之后看图片确认四块画面都在、没有黑块、没有明显错位。如果某块是黑的回去查对应解码实例的日志。如果整体颜色不对检查像素格式和色彩范围参数。这个抽帧命令也可以放进定时任务每隔几分钟抽一帧做健康检查比盯着日志省事。我自己的习惯是先把两路跑通确认画面和延迟都正常再往上加路数。每加一路都重新抽帧看一眼别等八路全起来才发现布局算错了。这套方案的价值在于它足够简单没有额外依赖一台普通服务器就能撑起十几路的预览合成。希望帮到你。本文还有配套的精品资源点击获取
