直接切入正题。做直播开发或者自建流媒体服务的朋友应该都有过这种经历视频流采集好了却不知道用哪款工具推出去最稳服务器搭起来了拉流端却一直黑屏GitHub上项目翻了一大堆真正能拿来就跑的没几个。我最近正好把几款常用的开源免费推流工具重新整理了一遍从桌面端到命令行、从推流到拉流、从服务器到移动端完整跑通了几条链路。这篇就聊聊我实测下来最顺手的3款工具OBS Studio、FFmpeg、SRS。它们覆盖了“采集-推流-分发-拉流”的完整流程全部开源免费附带具体配置和源码级别的使用说明适合正在做直播项目、IoT视频传输、或者想自建流媒体服务的人直接参考。1. 为什么这3款能覆盖直播全链路1.1 直播链路拆解从摄像头到播放器经历了什么推荐工具之前得先把直播的底层链路讲清楚。一套最简单的直播系统本质上就四个环节采集从摄像头、麦克风、屏幕或者视频文件里拿到原始画面和声音。推流把采集到的音视频数据编码压缩通过特定协议如RTMP发送到服务器。分发服务器接收推流后将流转换成不同协议HLS、HTTP-FLV、WebRTC等分发给大量观众。拉流观众端通过播放器从服务器拉取视频流进行播放。很多初学者一上来就找“推流软件”其实推流只是个中间动作。你最终要跑到哪个目标端——服务器、云平台还是移动设备——决定了你在“推流”和“分发”两个环节各自需要什么工具。这也是我会把三款工具放一起讲的原因它们不在同一层但能无缝衔接。1.2 工具分工各管一段谁也替代不了谁说句实在话很多人的误区是试图用一款工具搞定所有事。有人拿OBS当播放器用有人拿FFmpeg做UI级别的导播还有人直接在服务器上装OBS——这些都不是最优解。正确思路是各司其职工具类型擅长环节典型场景OBS Studio图形化桌面软件采集、导播、推流游戏直播、会议直播、课程录制时把画面推给服务器FFmpeg命令行工具采集、编码、推流、拉流、转封装无人值守推流、自动化的测试推流、拉流转存SRS流媒体服务器接收推流、协议转换、分发拉流自建直播平台、给多个终端提供拉流地址选这三款还有个重要理由它们都是社区活跃、迭代频繁的项目遇到问题搜得到答案不会动不动就停更。OBS和FFmpeg就不用多说了SRS在开源流媒体服务器里的热度也是一直稳中有升的开源协议友好代码可以直接拿来改。2. OBS Studio桌面端推流的主力选手2.1 推流配置的三个关键输入服务器地址、推流密钥、编码参数OBS的推流逻辑很简单你把画面源配置好它负责采集、编码然后通过RTMP协议推到你填好的服务器地址。以推给自建SRS服务器为例需要这样填服务选择“自定义”。服务器rtmp://你的服务器IP:1935/live推流码自定义一个串比如test它其实是流名称。分辨率1080p直播推荐1920x108025到30帧网络上行不足就降到1280x720。视频比特率1080p建议4500到6000 Kbps720p建议2500到3500 Kbps。音频比特率128到192 Kbps语音类直播128 Kbps足够。关键帧间隔OBS里叫“关键帧间隔秒”务必设置成2秒。这个参数很多新手会漏但它直接关系到观众端的延迟和画面质量——服务器做转封装时关键帧越稀疏播放器启动越慢。推流地址的格式需要特别留意rtmp://IP:端口/应用名/流名称。这里“live”就是应用名“test”是流名称。很多情况下推流失败不是密码错了而是把端口、应用名、流名称的层级搞混了。2.2 实操心得为什么建议在OBS里用“高级输出模式”OBS默认的“简单”输出模式也能推流但隐藏了很多关键参数。我强烈建议切到“高级输出模式”理由有三个可以单独控制视频和音频的编码器。比如显卡支持NVENC的话推流时用硬件编码CPU占用会从40%直接降到5%。可以设置录制的分辨率与推流分辨率分离。比如你屏幕是4K推流输出1080p录制则保留4K原画。可以关闭“自定义缓冲大小”或者手动调大它。网络抖动时缓冲能起到平滑作用但延迟会稍微增加。我的推荐组合是视频编码器用x264软件编码兼容性最好画质最稳或NVENC硬件编码CPU占用低适合边推流边打游戏速率控制选CBR固定码率关键帧间隔填2CPU使用预设选veryfast或faster。第一次做直播不要为了画质把预设调到slow否则CPU满了掉帧观众看到的就是幻灯片。2.3 音频与画面的采集细节OBS的场景和来源机制用熟了会非常顺手。直播时我常用的来源组合显示器采集作为主画面来源捕获整个屏幕。图像源放直播Logo或者背景图画面没有信号时不至于全黑。文本源显示直播标题、滚动公告。音频输入采集麦克风。音频输出采集电脑的系统声音。如果你要直播播放视频文件记得把这个打开否则观众听不到影片声音。有个细节要注意OBS默认会给所有来源加一个“缓冲”导致画面和声音略有不同步。在“高级音频属性”里把每个音源的“同步偏移”检查一遍如果出现口型对不上先试试给音频源设置负偏移例如-200毫秒不要一上来就调视频。2.4 常见问题推流断开、黑屏、CPU占用满OBS最让我头疼的问题曾经是推流断开。后来定位到几个原因网络不稳定最简单的方式是降低视频比特率720p降码率后断流概率大幅下降。关键帧间隔设置不当如果设置太长比如10秒服务器收不到关键帧可能判定超时断开。防火墙拦截自建服务器时记得在服务器安全组和本机防火墙放行TCP 1935端口。显卡驱动版本问题使用NVENC推流时出现编码器报错更新驱动基本能解决。黑屏问题则大概率出在“显示器采集”上。如果你是在管理员权限下运行OBS显示器采集会抓不到画面解决办法是以普通用户权限运行或者改用“游戏捕获”。3. FFmpeg命令行里的推流与拉流瑞士军刀3.1 一条推流命令的完整拆解如果说OBS是开着重型卡车跑直播那FFmpeg就是一把能解所有螺丝的瑞士军刀。它没有界面但灵活度最高特别适合自动化脚本、服务器端推流以及各种测试场景。最基本的推流命令长这样ffmpeg -re -stream_loop -1 -i input.mp4 \ -c:v libx264 -preset ultrafast -b:v 2000k \ -c:a aac -b:a 128k \ -f flv rtmp://your-server-ip:1935/live/test逐段拆开说-re以原始帧率读取输入文件。不加它FFmpeg会以最快速度把文件推完直播还没开始就已经结束了。-stream_loop -1无限循环输入文件。适合7x24小时无人值守直播。-c:v libx264视频用H.264编码直播兼容性最好。-preset ultrafast牺牲一点点压缩率换取最快的编码速度。直播场景下CPU不够怎么办这个参数就是救命的。-b:v 2000k视频码率简单理解为每秒钟视频画面占2Mb的数据。-c:a aac -b:a 128k音频编码和码率。-f flv输出格式为FLVRTMP推流的标准容器格式。rtmp://...推流目标地址。3.2 拉流、转存、转封装同一个命令的三种用途FFmpeg不仅推流拉流同样是强项。所谓拉流就是从流媒体服务器上把直播流拉下来播放或保存。直接预览直播流ffplay rtmp://your-server-ip:1935/live/test把直播流实时录制成文件ffmpeg -i rtmp://your-server-ip:1935/live/test -c copy record.flv-c copy表示不重新编码直接复制流数据CPU占用几乎为零。前提是录制格式和原流格式匹配否则还是要加编码参数。另外我经常用到的是转封装场景把RTMP流转成HLS切片服务器端直接生成m3u8文件给观众看。这个操作FFmpeg一条命令就能完成ffmpeg -i rtmp://your-server-ip:1935/live/test \ -c copy -f hls -hls_time 4 -hls_list_size 0 output.m3u8但说实话这种生产级的协议转换任务我更推荐交给我下面要讲的SRS来做。FFmpeg适合临时处理、日常测试SRS适合稳定运行长期服务。3.3 不采集摄像头也能测推流FFmpeg内置测试源做开发调试的时候手边不一定有摄像头的视频信号。FFmpeg自带的测试源就是最佳工具ffmpeg -re -f lavfi -i testsrcsize1280x720:rate30 \ -f lavfi -i sinefrequency440:duration3600 \ -c:v libx264 -preset ultrafast -b:v 2000k \ -c:a aac -f flv rtmp://your-server-ip:1935/live/testtestsrc会生成一个标准测试图案彩条加滚动时间码sine会生成440Hz的正弦波音频。这样推流时拉流端能看到画面、听到声音链路通没通一目了然。这个技巧在排查“服务器配置对了没”的时候特别高效。3.4 我踩过的坑-re的位置和编码参数的匹配问题很多人在复制FFmpeg命令时容易忽略-re的位置。它必须放在-i input.mp4之前因为它控制的是“输入文件读取速率”。放在-i后面有时也能生效但放在前面的语义最明确、最不容易出错。另一个典型的坑是编码参数不匹配。推流时用了-c:v copy但源文件和输出封装格式不兼容比如源视频是MPEG-4编码输出FLV容器不支持FFmpeg会直接报错。这时候不要盲目加-c:v copy要确认源文件的编码格式。用ffprobe input.mp4查看编码信息再做判断。4. SRS服务器端接收与分发的开源流媒体方案4.1 为什么推流端和拉流端之间必须有SRS这类服务器有人会问既然OBS能推流FFmpeg能拉流那两个工具直连不就行了省掉服务器不是更简单理论上可以实际上行不通OBS推到FFmpeg使用的RTMP端口如果两边都在各自局域网内NAT穿透、防火墙这些麻烦事会让你怀疑人生。一个推流端往往对应多个拉流端。没有服务器做分发每个观众都直连推流端推流端的带宽和CPU很快被打满。生产环境需要协议转换手机浏览器看不了RTMP需要用HTTP-FLV、HLS、WebRTC。SRS这类服务器存在的意义就是把一路推流变成多路可用的拉流协议。4.2 Docker一条命令拉起SRSSRS全称是Simple Realtime Server是个国产开源的高性能流媒体服务器。部署它最省心的方式是用Dockerdocker run --rm -p 1935:1935 -p 8080:8080 \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5跑起来之后SRS默认就支持RTMP推流。把OBS推流地址填成rtmp://你的服务器IP:1935/live/test这时你用FFmpeg拉流测试ffplay rtmp://你的服务器IP:1935/live/test看到画面说明推拉流链路已经打通了。需要注意的是云服务器上跑Docker除了容器内的端口映射还要确认云平台的安全组放行了1935和8080端口。我遇到过太多次“docker run命令没报错但就是连不上”的案例最后发现是安全组没配置。4.3 开启HTTP-FLV和HLS手机浏览器也能看SRS默认配置只支持RTMP。想让手机端或者网页端也能看需要改一下配置文件。Docker启动时挂载自定义配置docker run --rm -p 1935:1935 -p 8080:8080 \ -v /path/to/srs.conf:/usr/local/srs/conf/srs.conf \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5配置文件srs.conf加上HTTP-FLV和HLS支持listen 1935; daemon off; srs_log_tank console; vhost __defaultVhost__ { # HTTP-FLV拉流配置 http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } # HLS切片配置 hls { enabled on; hls_fragment 2; hls_window 10; } }配置生效后同一路推流rtmp://IP:1935/live/test可以对应多个拉流地址RTMP原流rtmp://IP:1935/live/testHTTP-FLV流http://IP:8080/live/test.flvHLS流http://IP:8080/live/test.m3u8用浏览器直接播放HLS地址不需要安装任何播放器Video标签就能拉流。4.4 为什么在测试和上线时我更推荐SRS的HTTP-FLV而不是RTMP移动端浏览器和网页一般不支持RTMP协议但支持HTTP-FLV。它有两个明显优势HTTP-FLV走80端口穿防火墙更省心在弱网环境下的表现也更好。通过HTTP分发时可以配合CDN做边缘加速这是RTMP做不到的。所以我的建议是推流统一用RTMP拉流首选HTTP-FLV如果观众量大或者需要苹果设备Safari直接播放再叠加HLS。SRS这层配置非常简单改一下配置文件重启即可。5. 组合实战从摄像头到手机端的完整链路与排查手册5.1 全链路案例一路完整的直播流是怎么跑通的把三款工具组合起来可以搭一套完整的直播系统。我以最常见的“摄像头采集手机观看”为例PC上打开OBS设置显示器采集或摄像头来源。OBS推流地址填rtmp://你的服务器IP:1935/live/demo服务器上SRS已完成部署Docker容器运行中。用手机浏览器访问http://你的服务器IP:8080/demo.m3u8即可实时观看。如果服务器上的流是视频文件不用OBS也可以直接用FFmpeg推ffmpeg -re -i movie.mp4 -c:v libx264 -preset veryfast -b:v 3000k -c:a aac -f flv rtmp://你的服务器IP:1935/live/demo一套典型的“视频文件自动直播”方案就出来了常用于影音台、教学频道的7x24小时轮播。5.2 排查手册当推流或拉流出现问题时按这个顺序查直播链路越完整出问题时的搜索范围就越大。我的排查顺序是固定的分享给大家参考现象第一步检查第二步检查常见根因OBS推流成功但播放器拉不到流服务端SRS日志OBS推流地址中的流名称是否一致RTMP应用名或流名称拼写不一致推流卡顿观众端频繁缓冲上行带宽是否足够视频码率设置是否过高码率超出网络上行能力降到2000Kbps延迟越来越高关键帧间隔播放器缓存设置关键帧间隔过长或播放器缓存过大手机播放器黑屏但桌面端正常是否使用HLS地址服务器是否开启了HLS配置手机端不支持RTMP需统一走HLS画面正常但声音有回声OBS音频监听设置麦克风与扬声器距离开启了“监听并输出”导致二次采集5.3 实战经验延迟、卡顿、音画不同步的三个核心权衡做直播方案时延迟和卡顿是不可兼得的。RTMP/HTTP-FLV方案的延迟通常在1到3秒体验最好HLS方案的延迟通常在5到10秒因为它是切片传输播放器需要积累一定数据才敢播放。我的经验值是这样如果对时效性要求高比如互动直播、游戏直播走HTTP-FLV如果观众量大、对画质稳定性要求高比如讲座、演唱会走HLS如果做WebRTC比如视频会议需要另配SFU不在这次讨论范围内。音画不同步的问题很多时候出在HLS切片的生成上。SRS的hls_fragment参数控制在多大尺寸切片一次设定2秒是一个比较稳的数值。切片切太大播放器seek不准音画误差会逐渐累积。5.4 个人建议先跑通最小链路再考虑优化和规模化我最后想补一句自己做直播项目一直坚持的习惯第一次上手永远先跑最小链路不要一开始就想着CDN、边缘结点、多码率适配这些高阶方案。最小链路就是FFmpeg推一个测试源到SRS然后用ffplay拉RTMP地址。这条链路能在5分钟内验证服务器的端口、防火墙、带宽是否OK。链路跑通后再接OBS再配HTTP-FLV和HLS再考虑云平台分发。每加一层只改动一个变量出了问题定位容易得多。这3款工具加在一起其实就是一套从内容采集到内容分发的最小开源闭环。项目里有这部分代码兜底后续往上叠功能也心里有底。希望这篇整理能让你少走点弯路也欢迎在评论里聊聊你自己遇到的推流或拉流的坑。