★ FEATURED ARTICLE 最近在弄一个小型直播项目会议室里一台电脑外接高清摄像头和麦克风要把现场画面和声音实时推到远端。没上导播台也没买硬件编码器我就靠 ffmpeg 一条命令把采集、编码、推流全串起来了。用 ffmpeg 采集摄像头、麦克风并推流是音视频领域非常经典的一条链路既能本地调试设备也能直接支撑直播、远程教学、安防监控这类场景。这篇文章把我实测走过的一套方案完整展开从设备识别、参数选择、推流命令到各种坑适合刚接触 ffmpeg 的开发者也适合想用命令行替代图形软件、把推流集成到脚本或服务里的朋友。1. 整体思路为什么用 ffmpeg 干这件事1.1 一条命令解决采集、编码、推流ffmpeg 本质上是一个流水线工具输入接设备输出接目标中间自动完成格式转换、编码、封装。你不需要单独装摄像头驱动、再装一个推流软件、再用编码器转一道只要把“从哪拿数据”、“数据怎么处理”、“送到哪去”三件事在命令行里说清楚剩下的都交给 ffmpeg。比如最基础的一条 Windows 命令ffmpeg \ -f dshow -video_size 1280x720 -framerate 25 -i videoUSB Camera \ -f dshow -sample_rate 44100 -audio_buffer_size 1000 -i audio麦克风 \ -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k \ -c:a aac -b:a 128k -f flv rtmp://your-rtmp-server/live/stream前半段是“采集”指定摄像头和麦克风的设备名中间是“编码”确定视频用什么编码器、码率多大结尾是“推流”把封装好的 FLV 流推到 RTMP 地址。很多人第一次看到这一串参数觉得难其实拆开看就是三部分每部分都只解决一个明确的问题。我用它做了好几件事本地录屏加摄像头、多机位同时推流、无人值守的定时直播。相比操作 OBS 那种图形界面命令行最大的优势是可脚本化、可嵌入后台、可重复执行改一个码率参数只需要改脚本里一处变量不用打开界面去找菜单。1.2 对比 OBS 和厂商 SDK 的实际取舍很多人会问OBS 不是更简单吗确实OBS 在“单机单路推流”场景下上手极快界面化配置、内置各种滤镜和转场还有虚拟摄像头功能但这只是故事的一部分。如果你要做的是“可编程、可自动化、可批量”的推流任务OBS 就差一些了。它的场景、源、设置都存在配置文件里虽然也支持命令行启动但控制粒度很难做到 ffmpeg 那样精细。而且 OBS 本身要跑一整套渲染界面内存和 CPU 占用明显高于纯命令行进程。厂商 SDK 又是另一个极端。很多摄像头厂商提供了自己的采集 SDK能直接拿到设备原始数据流但这类 SDK 通常绑定特定品牌甚至特定型号换一个设备就要重新适配更不用说还有平台限制。ffmpeg 的好处是它对设备做了统一抽象Windows 用 dshowLinux 用 v4l2/ALSAmacOS 用 avfoundation同一套推流逻辑可以跨平台复用不需要关心具体硬件是谁家的。方案上手难度自动化能力跨设备兼容资源占用ffmpeg 命令行中高高低OBS低低高中高厂商 SDK高中低中我个人的建议是一次性人工推流用 OBS省心要长期跑、要无人值守、要批量推流老老实实写 ffmpeg。后面讲的所有内容都是按“生产可复用”的标准来写的。2. 采集端先搞清楚摄像头和麦克风怎么被 ffmpeg 认出来2.1 Windows 下的 dshow 设备枚举在 Windows 上ffmpeg 默认使用 DirectShow简称 dshow访问摄像头和麦克风。第一步永远是先枚举本机设备千万不要凭猜测去写设备名设备名写错是新手报错最多的地方。ffmpeg -list_devices true -f dshow -i dummy这条命令会把当前机器可用的所有 dshow 设备列出来视频设备一般显示为类似Integrated Camera音频设备类似麦克风阵列 (Synaptics Audio)。注意很多设备名带空格、带中文、甚至带括号命令行里必须要用引号包裹否则 ffmpeg 会认为空格后面是新参数。有些设备名里带冒号比如USB Camera:1这表示设备的枚举带序号这种情况在 Windows 上偶尔会引发解析问题需要谨慎处理必要时把引号写成videoUSB Camera:1整体包裹。我自己实际遇到过一个设备名字是HD Webcam (02括号都不对称第一次写在命令里直接解析失败后来我都是先枚举、复制、再粘贴手打设备名这件事能不做就不做。枚举之后还可以进一步查看设备支持的格式ffmpeg -list_options true -f dshow -i videoIntegrated Camera这条会输出设备支持的分辨率、帧率、像素格式列表。不同摄像头差距很大有的是 1920x108030有的是 1280x72060还有的只支持 640x480。提前查清楚可以避免你设定一个设备根本不支持的参数。2.2 Linux 下的 v4l2 与 ALSALinux 的采集链路跟 Windows 不一样。视频设备走 v4l2挂在/dev/videoX下音频走 ALSA用hw:X,Y来表示声卡设备。先看有哪些视频设备ls /dev/video* # 或安装 v4l-utils 后执行 v4l2-ctl --list-devices再确认某个设备支持的采集格式ffmpeg -f v4l2 -list_formats all -i /dev/video0输出里会标出YUYV、MJPG、NV12等像素格式以及每种格式支持的分辨率和帧率组合。注意MJPG是摄像头硬件压缩后的 MJPEG 流ffmpeg 仍然能读只是后续编码就不需要再压缩一遍原始图像了CPU 占用会低不少。麦克风这边用arecord -l查看声卡列表arecord -l输出会显示card X: ...对应的 ALSA 设备就是hw:X,0或plughw:X,0。采集命令一般写成ffmpeg -f v4l2 -framerate 25 -video_size 1280x720 -input_format mjpeg -i /dev/video0 \ -f alsa -sample_rate 44100 -channels 1 -i hw:2,0 \ -c:v libx264 -preset fast -b:v 2500k \ -c:a aac -b:a 128k \ -f flv rtmp://your-rtmp-server/live/streamLinux 下最容易踩的坑是权限问题普通用户访问/dev/video0可能被拒绝临时最省事的办法是把自己加入video组。另一个坑是 v4l2 设备默认可能使用V4L2_PIX_FMT_YUYV但摄像头实际只支持 MJPEG带了-input_format mjpeg后 ffmpeg 会先请求 MJPEG如果设备不支持会自动降级然后你看到一片灰屏那多半就是格式协商失败。2.3 macOS 下的 avfoundationmacOS 上 ffmpeg 用的是 avfoundation 输入框架。枚举设备命令ffmpeg -f avfoundation -list_devices true -i 输出里视频设备是AVFoundation video devices列表音频设备是AVFoundation audio devices列表。采集时用-i 视频设备编号:音频设备编号的方式比如ffmpeg -f avfoundation -framerate 25 -video_size 1280x720 -pix_fmt uyvy422 -i 0:0 \ -c:v libx264 -preset medium -b:v 2500k \ -c:a aac -b:a 128k \ -f flv rtmp://your-rtmp-server/live/stream需要说明的是macOS 对摄像头像素格式的限制比较严格通常只能拿到 uyvy422 这类格式如果摄像头被其他应用占用比如 FaceTime 开着avfoundation 会直接报错这一点和 Windows 的“设备被占”很类似。2.4 采集参数配置细节采集参数不只是一串数字填进去那么简单里面藏着不少实际约束。分辨率、帧率和像素格式三个参数是绑定的。一条 USB 2.0 总线理论带宽约 480 Mbps但实际有效带宽大概只有一半。算一笔账720p 分辨率是 1280x720一帧 yuyv422 格式每个像素占 2 字节单帧大小就是 1280x720x2 1,843,200 字节25 帧每秒就是 46 MB/s约 368 Mbps。这个数值已经接近 USB 2.0 的极限。如果你强行采 1080p30 yuyv422单帧 1920x1080x2 ≈ 4 MB30 帧每秒就是 120 MB/s约 960 MbpsUSB 2.0 根本扛不住结果就是采集掉帧、花屏或者干脆打开失败。这也是为什么很多摄像头的 1080p 模式实际输出的是 MJPEG 流MJPEG 是摄像头内部先把画面压缩成 JPEG单帧只有几十到几百 KB带宽一下子降下来。代价是 ffmpeg 拿到的是压缩流画面细节在摄像头端就被“有损”过一次了。所以追求画质时要想清楚是选 yuyv422 原彩但降分辨率/帧率还是选 MJPEG 保高分辨率但接受压缩损失。这个取舍没有标准答案取决于你的实际场景。音频这边麦克风采样率选 44100 还是 48000取决于服务端和播放端的要求。如果下游只是网页播放44100 基本够用如果后面要做混音或专业处理48000 更安全。声道数则要看麦克风实际情况很多 USB 麦克风只有单声道你写-channels 2并不影响采集ffmpeg 会自动补但明确写 1 能少一些设备协商的麻烦。另一个常被忽略的参数是-audio_buffer_size这个值太大会增加延迟太小会导致音频频繁报ALSA buffer underrun需要结合实际环境微调。3. 推流端协议选型与完整命令实操3.1 推流协议怎么选ffmpeg 支持的推流协议很多但真正在“采集摄像头麦克风推流”场景里常用的就那么几个协议传输层延迟水平抗丢包典型场景RTMPTCP1-3秒一般直播平台、CDN推流RTSPUDP/TCP百毫秒级弱安防监控、局域网SRTUDP1秒以内强弱网长距离传输HLSHTTP/TCP5-15秒强点播、延迟不敏感场景WebRTCUDP亚秒级较强实时互动但 ffmpeg 直接支持有限我平常用的最多的还是 RTMP。原因很朴素直播服务商、CDN、播放器对 RTMP 的兼容性最好推上去之后还能统一转成 HLS 让普通播放器直接看。RTSP 在局域网里确实延迟低但它默认就走 UDP跨公网时经常被 NAT 和防火墙挡住如果硬要公网传RTSP Over TCP 是一个办法但也远不如 RTMP 省事。SRT 这些年越来越常见本质是用 UDP 做了一个可靠传输层抗丢包能力确实比 RTMP 强弱网环境下画面不容易断。但它要求接收端也得是 SRT 服务不是所有平台都支持。如果你的接收方是自建服务并且网络条件不太好可以优先考虑 SRT如果目标是各大直播平台RTMP 仍然是那个不折腾的选择。HLS 就不太适合实时采集推流了它的切片机制天然带来好几秒延迟做监控、直播互动都不合适只有服务商用他来分发到播放端时才值得碰。3.2 一条生产可用的推流命令逐段拆解下面这条命令是我在 Windows 环境下实际跑过一段时间的完整版本加了注释方便理解ffmpeg -y \ -f dshow -video_size 1280x720 -framerate 25 -pixel_format yuyv422 \ -i videoUSB Camera \ -f dshow -sample_rate 44100 -channels 1 \ -i audio麦克风 (Realtek(R) Audio) \ -threads 4 \ -c:v libx264 -preset veryfast -tune zerolatency \ -b:v 2500k -maxrate 2500k -bufsize 5000k \ -g 50 -keyint_min 25 -sc_threshold 0 \ -c:a aac -b:a 128k -ar 44100 -ac 2 \ -f flv -flvflags no_duration_filesize \ rtmp://your-rtmp-server/live/stream一段段看-y表示覆盖输出文件推流场景其实没有本地输出文件但加上它在脚本里可以避免意外交互卡住。-f dshow -video_size 1280x720 -framerate 25 -pixel_format yuyv422是视频采集参数组。这里 1280x720 和 25 帧是最稳的起步组合yuyv422 是大多数 USB 摄像头在 720p 下既能保证画质又不会把带宽撑爆的格式。注意-pixel_format不是所有 dshow 摄像头都能吃如果你的设备报格式不支持去掉这一项或改成mjpeg试试。-i videoUSB Camera是视频输入源设备名必须和枚举输出完全一致。-f dshow -sample_rate 44100 -channels 1是音频采集参数。-channels 1配合-ac 2可以理解成“采集时用单声道编码输出时转成立体声”这种做法能减少设备协商失败的概率也能让播放端声音更“满”一些。-c:v libx264 -preset veryfast -tune zerolatency是视频编码核心。preset 控制 x264 的速度优先级veryfast 是直播里很常用的档位编码速度快、CPU 占用可控、压缩率不如慢速档但画质够用。tune zerolatency对延迟敏感项目几乎是必加的它会调整编码器的缓冲策略让编码延迟尽量低。-b:v 2500k -maxrate 2500k -bufsize 5000k是码率控制。720p25 在 2500 kbps 是一个合理起点画面静止多的场景可以降到 1500 kbps画面运动剧烈的场景要升到 4000 kbps。maxrate和bufsize配合用来限制码率波动避免瞬时码率冲得太高把网络打爆。注意bufsize是缓冲器大小它不能小于码率一般取码率的 2 倍左右。-g 50 -keyint_min 25 -sc_threshold 0是 GOP 设置。-g 50表示每 50 帧一个关键帧25 帧每秒就是 2 秒一个关键帧。keyint_min限制了最小关键帧间隔避免某些场景自动插入过多关键帧。sc_threshold 0是关闭场景切换检测防止画面突变时 x264 自作主张插入关键帧导致 GOP 节奏不稳定。-c:a aac -b:a 128k -ar 44100 -ac 2是音频编码。AAC 是目前直播平台事实标准128 kbps 对语音绰绰有余对音乐也够用。-f flv -flvflags no_duration_filesize是封装格式设置。RTMP 推流的本质是发 FLV 流所以这里-f flv是必须的。no_duration_filesize这个 flag 可以避免某些接收端时不时报 metadata 相关错误。还有一个常见的疑问为什么要不要加-re答案是采集推流不要加。-re的意思是“按输入文件的时间戳匀速读取”适用于把本地文件像直播一样推出去的场景摄像头和麦克风是实时设备数据已经在匀速到达再加-re会造成帧堆积延迟会越来越大。3.3 编码参数与音画同步的处理编码这块最容易让人纠结的前缀是 preset。网上很多命令直接写-preset ultrafast实际上 ultrafast 牺牲了太多压缩率同码率下画质明显变差。直播场景里 veryfast 是甜点位如果 CPU 还有余量可以降到 fast 或者 medium画质会有提升。我做过一个对比同样的 2500 kbps720p25 内容在 veryfast 下运动边缘能看到块状噪声换成 medium 后明显平滑但 CPU 占用率从 15% 涨到 35%。如果你的机器是旧笔记本请老老实实 veryfast 。-tune zerolatency的副作用是会让码率整体偏高一点因为它不允许编码器用未来帧做参考。但直播场景下这个副作用完全可以接受延迟比那一点点码率重要得多。音画同步是另一个容易翻车的地方。摄像头和麦克风在物理上是两个独立的设备各走各的时钟不经处理直接推出去时间长了就会出现“嘴型对不上”。我的做法是给视频输入加上-use_wallclock_as_timestamps 1让视频帧的时间戳以墙钟时间为准音频保持自己的采样时钟到了播放端再由播放器做时间轴同步。ffmpeg -f dshow -use_wallclock_as_timestamps 1 -video_size 1280x720 -framerate 25 \ -i videoUSB Camera \ ...如果这一步还发现不同步可以在编码前手动复位时间戳-f dshow -use_wallclock_as_timestamps 1 -i video... \ -vf setptsPTS-STARTPTS -af asetptsPTS-STARTPTS这两行把视频和音频的时间戳都归零再交给编码器。它可以解决大量“推了一分钟之后完全对不上”的问题。但注意setpts和asetpts会丢弃原始时间戳信息如果你的推流服务端需要按时间戳做录制或索引可能带来副作用。轻重缓急自己权衡。4. 实战踩坑设备占用、花屏、无声、掉流的排查记录4.1 常见报错速查表下面是这几个月里我踩过、也在各个环境复现过的报错整理成一张速查表报错信息原因处理方式DirectShow device list: video... not found设备名写错重新执行枚举命令复制完整设备名Device or resource busy设备被其他程序占用关闭调用摄像头的软件如会议软件、浏览器标签页v4l2 input device doesnt support format像素格式协商失败先查-list_formats all换成支持的格式rtmp connect failed: Connection timed out推流地址不可达或服务端宕机检查地址端口、防火墙、服务端鉴权配置Non-monotonous DTS in output stream时间戳混乱检查-use_wallclock_as_timestamps、setptsError while opening encoder for output stream编码器不可用确认 ffmpeg 编译包含 libx264或换 libopenh264ALSA buffer underrun音频缓冲区配置过小增大-audio_buffer_size或降低采样率设备被占用是最常见的起步期问题。Windows 下你开着微信视频聊天再跑命令大概率直接报 busy先把占用摄像头的软件全关掉再试。Linux 下除了软件占用还有可能是v4l2设备的排他模式一个进程打开后其他进程就拿不到。像素格式不匹配也很常见。我遇到过一次摄像头只报 MJPEG 格式命令里硬写yuyv422报错之后查格式才发现问题。所以再次强调在写正式命令之前先用枚举命令看一下设备到底支持什么这一步能省一小时。4.2 推流稳定性与断线重推ffmpeg 本身是一次性进程如果推流过程中网络抖动断开它不会自动重连。生产环境下我一般用一个外层循环包住它做到基本的“断了就重启”#!/bin/bash urlrtmp://your-rtmp-server/live/stream while true; do ffmpeg -f dshow -video_size 1280x720 -framerate 25 -i videoUSB Camera \ -f dshow -sample_rate 44100 -channels 1 -i audio麦克风 \ -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k \ -c:a aac -b:a 128k \ -f flv $url echo $(date): ffmpeg exited, restarting ffmpeg.log sleep 3 done这个脚本的问题是如果 ffmpeg 是因为你按了 CtrlC 退出它也会自动重启。要避免这种尴尬要么用trap捕获退出信号要么把循环放到一个受控的服务环境里。更正规的做法是用 systemd 或 Docker 管理 ffmpeg 进程配置Restartalways或Restarton-failure日志交给服务框架统一收集。我实际跑过一个 24 小时无人值守的推流任务最开始用裸命令行凌晨网络抖动断了三次全靠服务框架自动拉起第二天早上检查日志才发现某个时段重推过。手动脚本不是不行只是管理和监控不如服务框架方便。还有一个隐蔽的稳定性问题长时间运行后内存缓慢增长。直播推流这个场景下ffmpeg 的内存泄漏不算常见但编码器在某些畸形输入流上可能卡住不退出导致循环脚本里ffmpeg -y卡死、后面的重启逻辑永远等不到。稳妥做法是给进程加超时监控比如用timeout命令包裹或者定期检查进程是否还在响应日志输出。4.3 低延迟实践的取舍很多人对“延迟”有执念一上来就追求几百毫秒结果发现怎么调都达不到。这里的关键是分清“编码器延迟”和“播放端延迟”。-tune zerolatency、-g设小一点、-bf 0关掉 B 帧确实能降低编码缓冲带来的延迟这部分在 100ms 量级是可行的。但 RTMP 推流到服务端后你的播放器如果缓冲设置保守照样会多等 1-2 秒。我在 ffplay 里常用的参数组合是ffplay -fflags nobuffer -flags low_delay \ -probesize 32 -analyzeduration 0 \ rtmp://your-rtmp-server/live/streamnobuffer让播放器几乎不做预读probesize 32和analyzeduration 0是跳过流的深度探测这一套组合实测能把播放端延迟压到非常低但代价是网络稍微抖动就可能卡顿。另外如果你发现“我采集到推流这一段延迟很小但远端播放还是慢”问题往往不在 ffmpeg而在服务端转封装和播放器的缓冲策略。这个锅不要甩给 ffmpeg。我通常会建议先量化把摄像头对准一个秒表页面推流之后在播放端截图对比时间差多测几次搞清楚延迟主要发生在采集、编码、网络还是播放。没有这一步调参就是在瞎猜。4.4 没有真实设备时的调试方案开发环境里不一定随时有摄像头和麦克风。ffmpeg 自带的 lavfi 虚拟设备可以模拟输入这一招用来验证推流链路、调试参数、压测服务端非常好用。虚拟视频源ffmpeg -f lavfi -i testsrc2size1280x720:rate25 \ -f lavfi -i sinefrequency1000:sample_rate44100 \ -c:v libx264 -preset veryfast -b:v 2500k \ -c:a aac -b:a 128k \ -f flv rtmp://your-rtmp-server/live/streamtestsrc2是 ffmpeg 内置的测试图案带移动色块和滚动时间戳用来判断推流是否正常再合适不过。sine是正弦波音频能让你直观判断声音链路通不通。如果你已经有一个录好的视频文件也可以用movie滤镜把它当成摄像头循环推流ffmpeg -re -f lavfi -i movie/path/to/test.mp4:loop0 \ -f lavfi -i sinefrequency440:sample_rate44100 \ -c:v libx264 -preset veryfast -b:v 2500k \ -c:a aac -b:a 128k \ -f flv rtmp://your-rtmp-server/live/stream注意这次加了-re因为文件输入不是实时设备必须用-re模拟实时推流速度。用这种方式我压测过服务端并发接收能力也让后期排查问题的时候不再依赖硬件到场。还有一类情况是摄像头是有的但音频设备缺失或驱动异常。这时候可以给视频配一条静音轨保证最终流有音频通道-f lavfi -i anullsrcr44100:clstereoanullsrc生成静音 PCM占的码率极低但它能让播放器正常进入播放状态不至于因为无音轨而找不到播放入口。这个方法做无人值守直播时很有用。写在后面的一点经验实际跑了几个月采集推流之后我最大的感受是ffmpeg 命令里踩的坑绝大多数不是 ffmpeg 的问题而是对设备和协议的理解不够。设备名不先枚举就手写、像素格式不看支持列表就硬填、延迟没分清楚在哪一段就开始乱调这些才是真正拖慢进度的东西。最后分享两个小技巧一是所有命令里的设备名、推流地址、码率、分辨率都用变量抽出来脚本顶部的配置区改参数就行省掉大量重复调试二是每次改动参数都保持日志可查用-loglevel info记录关键事件后面排查才有据可依。等这套链路稳定了你会发现再加多路摄像头、画中画、加字幕都只是沿着这条链路加滤镜的事基础打牢了扩展起来很快。
阅读完成 · 觉得有帮助？
