1. 从一次现场交付说起为什么我重新捡起了 FFmpeg去年冬天一个做智慧工地监控的朋友找到我说他们有个项目卡了壳。需求听起来不复杂在一个巴掌大的嵌入式盒子上同时把 5 路摄像头的画面推到流媒体服务器盒子重量要控制在 120 克以内供电只有 5V2A还得在户外弱网环境下稳定跑。他之前找的方案要么是软件编码把 CPU 吃满直接卡死要么是盒子太重装不进设备舱要么是推流延迟高到没法看。我拿到需求的第一反应是这事儿绕不开 FFmpeg。不是因为它时髦恰恰相反是因为它太老了、太稳了、太底层了。市面上所有花哨的音视频工具剥开外壳十有八九内核还是它。而真正能把 5 路 RTMP 推流塞进一个 118 克盒子的关键不在于你用了多新的框架而在于你是否真的理解 FFmpeg 的每一层在干什么以及硬件编码器到底该怎么喂。这篇文章我想把两件事讲透一是 FFmpeg 从原理到实战的完整脉络让你不再只是复制粘贴命令行二是怎么用 MEDAI V2 这类低功耗 AI 盒子把 5 路 RTMP 推流真正落地。中间会穿插大量我踩过的坑、参数计算过程和现场调试记录。如果你正在做边缘视频、多路推流、嵌入式音视频或者只是想把 FFmpeg 从会用变成懂这篇应该能帮你省下不少通宵的时间。先说清楚适合谁看有基本 Linux 操作经验、知道 RTMP 是什么、能看懂简单命令行的朋友读起来会最顺。完全零基础也能看但建议先把 FFmpeg 装起来跟着敲一遍光看是学不会的。2. FFmpeg 到底是什么拆开这把瑞士军刀看内部2.1 它不是软件是一整套音视频基础设施很多人对 FFmpeg 的理解停留在一个转码命令。这就像把瑞士军刀理解成一把小刀完全低估了它。FFmpeg 实际上是一组库加一组命令行工具的集合核心库包括libavformat负责封装和解封装也就是处理 mp4、flv、mkv、rtmp 这些容器格式管的是怎么把音视频数据打包和拆包。libavcodec负责编解码管的是怎么把原始画面压成 H.264怎么把 H.264 还原成画面。libavfilter负责滤镜处理缩放、裁剪、叠加、水印、格式转换都在这里。libswscale专门做图像像素格式转换和缩放比如 YUV420P 转 RGB。libswresample专门做音频重采样和格式转换。libavutil公共工具库内存、数学、时间等基础功能。命令行工具ffmpeg、ffprobe、ffplay只是这些库的外壳。理解这一点非常重要因为当你在嵌入式盒子上做优化时你调的每一个参数最终都会落到这几个库的某一条路径上。知道数据在哪一层被处理才知道瓶颈在哪。打个生活化的比方FFmpeg 就像一家全流程的快递公司。libavformat 是收件和派件网点负责把包裹音视频流装进标准箱子容器libavcodec 是压缩打包机负责把大件压小libavfilter 是分拣中心负责改地址、贴标签libswscale 和 libswresample 是专门处理特殊尺寸和特殊规格包裹的工位。你要发 5 路快递还要求又快又省就得知道哪个工位会堵。2.2 一条命令背后的完整数据流我们拿最常见的推流命令来拆ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 2000k -c:a aac -f flv rtmp://server/live/stream这条命令看起来简单实际内部走了这么一条链路-i input.mp4触发 libavformat 打开文件识别出 mp4 容器读出里面的视频流和音频流。读出的视频是压缩的 H.264 数据音频是压缩的 AAC 数据进入解码环节如果只是转封装则不解码。解码后的原始帧进入 libavfilter做必要的格式转换。再交给 libavcodec 用 libx264 重新编码。编码后的数据回到 libavformat按 flv 格式封装。通过 rtmp 协议推送到服务器。-re这个参数特别值得说它的作用是按真实时间戳读取输入也就是模拟实时流。如果你不加-reFFmpeg 会用最快速度把文件读完推完服务器那边瞬间收到一堆数据播放端直接崩。这个参数在推流场景几乎是必加的但很多新手会漏掉然后纳闷为什么推流一下就结束了。2.3 为什么嵌入式场景必须懂原理在 PC 上你随便怎么折腾CPU 都扛得住。但在一个 118 克的盒子上CPU 可能是四核 A53 甚至更低内存可能只有 1GB 到 2GB还没有主动散热。这时候每一个环节的开销都被放大软编码 1080P 一路就能吃掉一整个核心5 路直接没戏。内存拷贝多一次可能就多几十毫秒延迟。像素格式转换没走对路径CPU 占用翻倍。所以嵌入式推流的核心思路只有一条能硬件做的绝不软件做能零拷贝的绝不多拷贝能不解码的绝不解码。后面讲 MEDAI V2 实战时这条思路会贯穿始终。3. 编解码与封装决定性能的两个关键战场3.1 编码器选型软编、硬编、还是直接转封装推流场景下编码器的选择直接决定盒子能不能扛住 5 路。我把常见选项列个表对比方案代表CPU 占用画质延迟适用场景软编码libx264极高好中PC、路数少硬件编码芯片自带编码器极低中上低嵌入式、多路直接转封装copy几乎为零无损最低源已是目标编码这里有个巨大的认知误区很多人以为推流一定要重新编码。其实如果摄像头出来的就是 H.264而目标也是 H.264你完全可以用-c:v copy直接转封装CPU 占用几乎为零。这就是能不解码的绝不解码。但现实往往没这么美好。摄像头出来的 H.264 可能是 Baseline profile码率飘忽不定分辨率五花八门而服务器要求统一的 High profile 和固定码率。这时候就必须解码再编码。5 路场景下软编码基本判死刑必须上硬件编码器。硬件编码器的原理是把编码任务从 CPU 卸载到专用电路ASIC或 GPU 上。它的优势是功耗低、占用少代价是画质调优空间小、参数支持有限。不同芯片的硬件编码器能力差异很大选盒子的时候一定要确认它支持几路并发编码、支持什么分辨率、码率范围是多少。3.2 封装格式与协议RTMP 为什么还在用RTMP 是个老协议基于 TCP延迟通常在 1 到 3 秒。很多人问为什么不用更低延迟的 WebRTC 或者 SRT。答案很实际兼容性。绝大多数流媒体服务器、CDN、播放器对 RTMP 的支持是最成熟的推流端用 RTMP服务端再转成 HLS 或 HTTP-FLV 分发这是行业里跑了十几年的稳定组合。RTMP 封装成 FLV 格式FLV 的结构很简单一个 header 加一连串 tag每个 tag 是一段音频或视频数据。这种简单结构带来的好处是封装开销极小非常适合嵌入式设备。推流时几个关键参数-f flv指定输出封装为 FLVRTMP 必须用它。-flvflags no_duration_filesize推流场景建议加上避免 FFmpeg 等待文件结束才写元数据。-rtmp_live live告诉服务器这是直播流。注意RTMP 基于 TCP弱网下丢包会触发重传导致延迟累积。如果现场网络抖动严重要么加本地缓存要么考虑在服务端做抗抖动处理。这是我在工地项目里踩过的最大的坑后面会细说。3.3 时间戳与同步多路推流最容易翻车的地方单路推流时间戳乱一点问题不大。5 路一起推时间戳处理不好服务器那边就会出现花屏、音画不同步、甚至直接断流。FFmpeg 处理时间戳的核心概念是 PTS显示时间戳和 DTS解码时间戳。对于有 B 帧的 H.264DTS 和 PTS 不一样因为 B 帧需要参考后面的帧才能解码。推流时如果时间戳不连续或者回退服务器会认为流有问题。多路场景下每一路都要有独立且单调递增的时间戳。常见做法是给每一路单独起一个 FFmpeg 进程让它们各自维护时间戳互不干扰。如果硬要用一个进程处理多路时间戳管理会复杂到让你怀疑人生。这一点在 MEDAI V2 实战部分会展开。4. 滤镜与性能那些让你 CPU 爆表的隐形杀手4.1 scale 滤镜最容易被忽视的性能黑洞推流时经常需要把摄像头的高分辨率缩到目标分辨率比如 4K 缩到 1080P。这时候就会用到 scale 滤镜-vf scale1920:1080看起来人畜无害实际上 scale 是 CPU 杀手。默认的缩放算法是 bicubic画质好但慢。如果对画质要求没那么极致可以换成更快的算法-vf scale1920:1080:flagsfast_bilinear不同算法的对比算法速度画质建议neighbor最快最差几乎不用bilinear快一般实时推流可用fast_bilinear较快一般推荐bicubic慢好点播转码lanczos最慢最好高质量转码在 5 路场景下如果每路都要 scale这个开销会叠加。更聪明的做法是让摄像头直接输出目标分辨率从源头省掉 scale。如果摄像头不支持那就考虑用硬件缩放很多芯片的 GPU 或 VPU 支持硬件 scale。4.2 像素格式转换看不见的拷贝摄像头出来的数据格式五花八门常见的有 YUV422、NV12、YUYV 等而编码器通常要求 YUV420P。这个转换由 libswscale 完成也是一笔不小的开销。在嵌入式平台上很多芯片的硬件编码器直接支持 NV12 输入这时候如果你强行转成 YUV420P 再喂给编码器就白白多了一次转换。正确做法是查清楚编码器支持哪些输入格式让上游直接输出对应格式。实操心得用ffprobe或者芯片厂商提供的工具确认摄像头输出格式再对照编码器支持列表尽量让两者对齐。我在一个项目里发现摄像头输出 NV12编码器也支持 NV12去掉格式转换后 CPU 占用直接降了 15%。4.3 多路并发的资源账怎么算假设盒子四核 A53主频 1.5GHz要推 5 路 1080P25。我们来算一笔账硬件编码每路约占用 5% 到 10% 的 CPU主要是数据搬运和调度5 路约 25% 到 50%。如果走软编码每路 1080P25 的 libx264 veryfast 大约需要 1 到 1.5 个核心5 路需要 5 到 7.5 个核心四核根本不够。内存带宽5 路 1080P NV12 数据每帧约 3MB25 帧每秒就是 75MB/s 每路5 路 375MB/s。这个带宽对嵌入式内存控制器是不小的压力。所以结论很明确5 路必须硬件编码且要尽量减少内存拷贝。这也是为什么选盒子时不能只看 CPU 核数还要看它有没有独立的视频处理单元和足够的内存带宽。5. MEDAI V2 实战把 5 路 RTMP 装进 118 克盒子5.1 硬件与系统准备MEDAI V2 这类盒子通常具备几个特征重量在 100 到 150 克之间支持 5V 供电带多个视频输入接口内置硬件编解码单元。拿到盒子后第一步不是急着推流而是把基础环境摸清楚。先确认系统信息uname -a cat /proc/cpuinfo free -h然后确认硬件编码器是否可用。不同芯片的 FFmpeg 硬件加速接口不一样常见的有某类芯片用h264_omx某类芯片用h264_v4l2m2m某类芯片用h264_rkmpp某类芯片用h264_nvencPC 端用这条命令列出当前 FFmpeg 支持的所有编码器ffmpeg -encoders | grep h264如果看到带硬件标识的编码器说明可以用。如果没有要么是 FFmpeg 编译时没开要么是驱动没装。这一步卡住的人非常多建议优先解决。5.2 单路推流跑通先证明链路没问题不要一上来就搞 5 路。先用一路把整条链路跑通确认摄像头能读、编码器能用、服务器能收。假设摄像头是/dev/video0输出 1080P25目标是推到本地服务器的rtmp://192.168.1.100/live/cam1ffmpeg -f v4l2 -input_format nv12 -video_size 1920x1080 -framerate 25 -i /dev/video0 \ -c:v h264_v4l2m2m -b:v 2000k -g 50 -f flv rtmp://192.168.1.100/live/cam1几个关键参数解释-input_format nv12指定摄像头输出格式避免 FFmpeg 内部转换。-framerate 25指定帧率和摄像头能力对齐。-c:v h264_v4l2m2m使用硬件编码器以某类芯片为例。-b:v 2000k目标码率 2Mbps。-g 50GOP 大小25 帧每秒的话就是 2 秒一个关键帧。GOP 太大会导致首屏慢太小会增加码率。跑起来后用ffprobe或者服务器端工具确认流是否正常。如果画面卡顿先看 CPU 占用如果花屏检查像素格式如果连不上检查网络和 RTMP 地址。5.3 扩展到 5 路进程模型与资源分配单路跑通后扩展到 5 路有两种思路思路一5 个独立 FFmpeg 进程每路一个进程各自读自己的摄像头各自编码推流。优点是隔离性好一路崩了不影响其他路时间戳各自维护简单可靠。缺点是进程多了调度开销略大内存占用叠加。思路二单进程多路用一个 FFmpeg 进程处理 5 路输入用 filter_complex 拼接后输出多路。优点是进程少缺点是 filter_complex 配置复杂时间戳管理困难一路出问题可能全崩。我的建议是优先用思路一。在嵌入式场景下稳定性和可维护性比省那点内存重要得多。5 个进程的调度开销在四核 A53 上完全可以接受。启动脚本可以这样写#!/bin/bash SERVERrtmp://192.168.1.100/live for i in 0 1 2 3 4; do ffmpeg -f v4l2 -input_format nv12 -video_size 1920x1080 -framerate 25 -i /dev/video$i \ -c:v h264_v4l2m2m -b:v 2000k -g 50 \ -f flv $SERVER/cam$i sleep 1 done wait注意那个sleep 1它的作用是错开启动时间避免 5 路同时初始化硬件编码器导致资源争抢。这个细节是我调试了很久才发现的同时启动时硬件编码器会报设备忙。5.4 码率与 GOP 的精细调优5 路 1080P 如果每路 2Mbps总上行就是 10Mbps。现场网络能不能扛住要先测。如果带宽紧张可以降到 1.5Mbps 甚至 1Mbps但画质会明显下降。码率控制模式也很关键。硬件编码器通常支持 CBR固定码率和 VBR可变码率。推流场景建议用 CBR因为网络带宽是固定的VBR 的峰值可能瞬间打满带宽导致丢包。GOP 的设置要平衡首屏速度和码率。GOP 越大关键帧越少码率越低但新观众加入时等待首屏的时间越长。直播场景一般设 1 到 2 秒一个 GOP也就是 25 到 50 帧。实操心得在弱网环境下把 GOP 设小一点比如 25虽然码率会上升但丢包后恢复更快。我在地铁工地项目里把 GOP 从 50 降到 25卡顿投诉明显减少。5.5 弱网对抗让 5 路流在抖动网络里活下来工地、户外、移动场景的网络特点是带宽波动大、丢包率高、延迟不稳定。RTMP 基于 TCP丢包会重传重传会导致延迟累积延迟累积到一定程度服务器就会断流。几个实用的对抗手段本地缓冲在 FFmpeg 输入端加缓冲用-thread_queue_size增大队列避免读摄像头时丢帧。降低码率带宽不够时降码率比降分辨率更有效。动态调整写个监控脚本检测网络质量自动切换码率档位。断线重连FFmpeg 本身断线后不会自动重连需要外层脚本监控进程挂了就重启。断线重连脚本示例#!/bin/bash while true; do ffmpeg -f v4l2 -i /dev/video0 -c:v h264_v4l2m2m -b:v 1500k \ -f flv rtmp://192.168.1.100/live/cam0 echo stream ended, restarting in 3s... sleep 3 done这个简单的循环能解决 80% 的断流问题。剩下的 20% 需要从网络层解决比如换更好的天线、调整 AP 位置。6. 常见问题与排查技巧实录6.1 推流失败速查表现象可能原因排查方法连不上服务器地址错、网络不通、服务器没开ping 服务器telnet 端口画面花屏像素格式不匹配检查输入输出格式音画不同步时间戳问题检查 PTS/DTS加 -vsyncCPU 爆满走了软编码确认用了硬件编码器延迟越来越高网络丢包重传降码率加缓冲推几秒就断时间戳回退检查输入源时间戳硬件编码器报忙多路同时初始化错开启动时间6.2 几个我踩过的深坑坑一以为硬件编码器一定快。有些芯片的硬件编码器在小分辨率下反而不如软编码因为硬件有固定的初始化开销。5 路 1080P 用硬件没问题但如果只是 1 路 480P软编码可能更省事。坑二忽略了散热。118 克的盒子没有风扇5 路硬件编码跑满时芯片温度能到 70 度以上触发降频后编码能力下降流就开始卡。解决办法是加散热片或者限制并发路数。我在一个项目里贴了块铜片温度降了 15 度稳定性大幅提升。坑三摄像头供电不足。5 个摄像头同时工作电流需求可能超过盒子 USB 或接口的供电能力导致摄像头随机掉线。一定要算清楚总电流必要时用带独立供电的 Hub。坑四时间戳用了系统时间。有些方案用系统时间做时间戳盒子没有 RTC 或者 NTP 同步失败时时间戳会跳变导致服务器断流。正确做法是用单调时钟或者让 FFmpeg 自己生成时间戳。6.3 性能监控与调优清单上线前建议做一轮完整压测监控这些指标CPU 各核心占用确认没有单核跑满。内存占用和增长趋势确认没有泄漏。芯片温度确认不会触发降频。网络上行带宽确认不超过链路容量的 70%。端到端延迟用秒表对着画面测。调优优先级先保证不崩再保证不卡最后才追求画质。很多项目失败是因为一开始就追求高画质结果稳定性一塌糊涂。7. 一些关于 FFmpeg 和边缘推流的个人体会FFmpeg 这东西越用越觉得它像一把真正的好刀——刚上手觉得笨重用久了发现它什么都能切。但它的学习曲线也确实陡因为它的文档是参考手册式的告诉你每个参数是什么却不告诉你什么时候该用哪个。真正的经验只能从项目里攒。5 路 RTMP 推流装进 118 克盒子这件事技术难点其实不在 FFmpeg 命令本身而在于对整个链路的理解摄像头输出什么格式、芯片能硬解硬编什么、网络能扛多少码率、散热能撑多久。把这些搞清楚命令自然就写对了。最后分享一个小技巧调试推流时先用ffplay在本地拉流看效果比直接看服务器日志直观得多。命令是ffplay rtmp://server/live/stream画面、声音、延迟一目了然。等本地看着没问题了再上服务器验证能省掉大量来回排查的时间。这套方案后来在那个工地项目里跑了半年多5 路流基本没出过大问题。中间换过一次散热方案调过两次码率其余时间都很省心。边缘音视频这行稳定压倒一切花哨的功能都是次要的。