基于FFmpeg进程与标准输入管道的C# RTMP推流实践

我最近在做一套桌面端的画面采集与转播工具，核心诉求只有一个:把本机采集到的画面和声音，稳稳当当地推到一台流媒体服务器上。听起来像是个被做烂的需求,可真落到 C# 这块地界上,能直接抄的完整方案并不多——大部分资料要么停在几行命令行 demo,要么是别的语言的封装,要么一上来就让你去编译 native 库。我最后选的路子是:宿主程序只负责"造帧",真正的编码、封装、推流全交给 FFmpeg 这个独立进程,C# 与它之间只用一根标准输入管道连接。这就是标题里说的基于 FFmpeg 的 RTMP 推流功能(C# 版)。

这套东西能干什么?把任意来源的原始画面(屏幕、摄像头、合成帧、甚至是程序里画出来的图表)实时编码成 H.264,叠一路音频,封装成 FLV,走 RTMP 协议推给流媒体服务。它解决的核心问题是:你不需要在 C# 里跟 native 库的指针、结构体、回调函数搏斗,也不需要为了换个编码器重写一遍代码,所有编码策略都退化成一条可拼接的命令行参数。适合三类人看:做桌面直播工具/录屏软件的开发者、需要把设备画面推到远端做集中监看的工程人员、以及想搞清楚"推流这件事在系统层面到底发生了什么"的技术爱好者。哪怕你只是想在本地搭个最小可跑的链路验证一下,文中第四章的步骤也能直接照抄。

1. 技术路线选型:为什么最后落在"进程 + 管道"上

1.1 把需求拆成三段,再决定哪一段自己写

推流这件事,拆开看就是采集、编码、传输三段。采集必须由宿主程序做,因为画面从哪里来只有业务清楚;传输这一段 RTMP 协议本身不复杂但坑极多,握手、分块、chunk 大小协商、时间戳回绕,任何一处写错都会表现为"连上了但没画面";编码是纯算力活,自己写等于重造一个 H.264 编码器。所以真正需要做决策的只有一件事:中间这段编码,是自己啃 API 还是外包出去。

我在纸上列了三条路,对着自己的实际约束逐条打勾,最后选了第三条,理由在下面几个小节里展开。这里先给结论:如果你的团队里没有专门啃 native 层的人,并且你未来半年内可能换编码器、换封装格式、加滤镜,那"独立进程 + 管道喂帧"是投入产出比最高的一条路。

1.2 三条路线的横向对比

纯托管这条我在早期试过一个原型,光是把 YUV 帧喂进系统的硬件编码接口就花了两周,而 RTMP 的分块写入在弱网下反复出现时间戳错乱,最后放弃了。P/Invoke 这条,理论上性能最好,但只要对方库升级一次结构体布局,你的程序就会在客户机器上以访问违例的方式崩掉,排查成本极高。

第三条路最"土",但有个别人替代不了的优势:故障边界清晰。FFmpeg 进程挂了,主程序还活着,你可以杀掉重启、可以换参数重来、可以把 stderr 里的日志整段吐给用户看。对一个要长期在客户机器上跑的工具来说,这个特性比省下那点拷贝开销重要得多。

1.3 独立进程方案的代价,得先想清楚

天下没有白吃的午餐,这条路有三个明确的代价,我提前讲明,免得你踩进去才后悔。

第一是一次完整的帧拷贝。1280×720 的 BGRA 帧是 3.68MB,30fps 下每秒要往管道里灌 110MB 左右的数据。这个量级对现代机器不算什么,但你要意识到它存在——如果采集帧率提到 60、分辨率提到 1080p,这个数字会翻到 500MB/s 以上,那时候管道本身就会成为瓶颈,需要重新评估。

第二是控制粒度粗。你没法在推流过程中动态改分辨率、改帧率,只能杀掉进程重新起一条。想要"平滑降码率"这种操作,得靠 FFmpeg 内部的码率控制策略,或者用两套参数做无缝合流切换,复杂度立刻上一个台阶。

第三是错误信息是文本,不是异常。FFmpeg 不会抛ConnectionRefusedException给你,它只会在 stderr 里打一行红字。你必须自己写一套日志解析,把文本翻译成状态机里的状态。这个工作量不大,但必须做,否则你的程序只能告诉用户"推流失败了",然后被追问到底是网络问题还是参数问题。

1.4 适用边界与影响范围

这套方案最适合的场景是:单机推 1~4 路、分辨率不超过 1080p、对端到端延迟要求在 1~3 秒这个量级。落到具体行业,桌面直播工具、在线教学的板书同步、无人值守设备的画面回传、多屏监看墙、会议录制归档,这些都能直接套。

不适合的场景也要说清楚:需要亚秒级延迟的互动场景,RTMP over TCP 本身就很难做到,得换传输协议;需要精确到帧的编辑级控制,命令行方案给不了你这种精度;单机推几十路的高密度场景,进程数会把内存和句柄吃光,应该走别的架构。

2. 推流管线拆开看:从一帧像素到 RTMP 包

2.1 输入环节的接口契约必须先定死

管道喂帧最容易出错的地方不是写,而是"约定"。FFmpeg 在-f rawvideo模式下,对输入流的唯一认知就是:每帧固定字节数、按顺序排列、没有帧头没有分隔符。所以你必须保证三件事严格一致:像素格式、宽高、每帧字节数。

我定死的契约是bgra+ 宽高在启动时确定 + 每帧width * height * 4字节。选 BGRA 是因为 Windows 上屏幕采集拿到的就是 BGRA,用Bitmap.LockBits也是这个格式,少一次格式转换就少一次 CPU 热点。如果你从别的源拿帧,比如某些采集 SDK 给的是 NV12 或者 RGB24,那要么在 C# 侧转,要么把-pix_fmt改成对应格式让 FFmpeg 转——后者通常更快,因为 FFmpeg 的转换是 SIMD 优化的,而你在 C# 里写循环转换会慢一个数量级。

还有一个隐形陷阱:有些采集接口给的每行字节数(步长)不等于width * 4,而是按 4 字节对齐后可能更大。这时候你不能直接Marshal.Copy整块内存进管道,必须逐行拷贝,跳过每行末尾的填充字节。我第一次接摄像头就栽在这,画面出现了斜向撕裂,排查了半天才反应过来是步长问题。

2.2 码率、GOP、缓冲:三个必须算一遍的参数

这三个参数是推流质量的地基,不能凭感觉填。先讲码率。

经验公式是:目标码率 ≈ 宽 × 高 × 帧率 × 每像素比特数。每像素比特数(bpp)在 H.264 里取 0.06~0.10 之间,画面简单取小值,细节多取大值。1280×720×30 = 2765 万像素/秒,乘 0.08 得到约 2.2Mbps。这个数和实际调试出来的结果非常接近。

GOP 的算法很简单:GOP 长度 = 帧率 × 关键帧间隔秒数。30fps 下想要 2 秒一个关键帧,就是 60。这里有个关键点:一定要加-sc_threshold 0把场景切换自动插关键帧关掉,否则遇到画面突变 FFmpeg 会自己插一个 I 帧,导致实际 GOP 忽长忽短,对下游的缓冲和秒开体验都不友好。

-bufsize我一般设成-maxrate的 2 倍。这个参数决定了码率控制的"弹性空间",设太小画面一复杂就糊,设太大网络抖动时容易堆积数据造成延迟上涨。-maxrate和-b:v设成相等,是让码率尽量恒定,这对 RTMP 这种长连接很关键。

2.3 音频链路:静音源也是一路正经流

很多流媒体服务在收流时会检查是否存在音频流,没有就直接拒掉或者转码失败。所以哪怕你的业务场景根本不需要声音,也建议显式给一路静音源:

-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100

anullsrc是 FFmpeg 内置的无限时长静音发生器,几乎不耗 CPU,配合-c:a aac -b:a 128k -ar 44100 -ac 2就能造出一条标准的 AAC 音轨。

如果确实要推真实音频,采集侧的坑比视频多得多。采样率不一致是最常见的:采集设备给你 48000,你重采样到 44100,如果重采样器配置不对,会出现周期性的"咔哒"声。我的做法是不重采样,直接把-ar设成设备的原生采样率,让整条链路统一在 48000,兼容性和音质都更好。

还有一个隐蔽问题:音频帧和视频帧的时间基不同。视频按帧率走,音频按采样点走,两路数据从不同管道进来时,如果你的喂数据节奏不均匀,就会出现音画不同步。用anullsrc时因为是 FFmpeg 内部生成,时间基天然对齐,反而不会有这个问题——这也是我建议先用静音源跑通链路、再接入真实音频的原因。

2.4 封装与传输:FLV 和 RTMP 的那点事

RTMP 只负责传字节流,不负责描述这些字节怎么组织,所以推 RTMP 必须配一个封装格式,实践中 99% 用的是 FLV。命令末尾的-f flv就是在指定这个。

有个参数值得单独说:-flvflags no_duration_filesize。默认情况下 FLV 封装器想在头部的 metadata 里写入总时长和文件大小,可推流是个无限长的过程,这两个值根本不存在,某些版本的 FFmpeg 会因此反复尝试回填,表现为"推流卡在开头几秒不动"。加上这个标志,明确告诉它别管这两个字段,问题就消失了。我在一个客户现场排查了整整一下午,最后就是这一行参数解决的。

传输层的超时也建议显式配置。默认的 RTMP 超时可能长达几十秒,网络断了你的程序要等很久才知道。用-rw_timeout 5000000(单位微秒,即 5 秒)能让失败快速暴露出来,加快重连节奏。

3. C# 侧封装:把命令行包成一个可控对象

3.1 参数构造要可配置,但不能过度抽象

我见过一种写法,把 FFmpeg 参数抽象成几十个属性加一个模板引擎,最后没人看得懂最终命令长什么样。我的做法相反:所有参数集中在一个方法里顺序拼装,每个参数旁边一行注释,整体读起来就是一条命令。这样做的理由是,你迟早会遇到"这条命令在别人机器上跑不通"的情况,那时候你需要的是能把完整命令原样打出来贴进终端复现,而不是从十个属性里反推。

拼装用ProcessStartInfo.ArgumentList而不是自己拼Arguments字符串。原因是路径里有空格、URL 里有特殊字符时,ArgumentList会替你处理转义,自己拼字符串是经典的翻车点——尤其是 Windows 路径里的反斜杠和空格。

public sealed class PushOptions { public string OutputUrl { get; set; } public int Width { get; set; } = 1280; public int Height { get; set; } = 720; public int Fps { get; set; } = 30; public int VideoKbps { get; set; } = 2500; public int AudioKbps { get; set; } = 128; public int AudioSampleRate { get; set; } = 44100; public int KeyframeIntervalSeconds { get; set; } = 2; public string PixelFormat { get; set; } = "bgra"; public string VideoEncoder { get; set; } = "libx264"; public string Preset { get; set; } = "veryfast"; } public IReadOnlyList<string> BuildArguments(PushOptions o) { int gop = o.Fps * o.KeyframeIntervalSeconds; return new List<string> { "-hide_banner", "-loglevel", "level+info", // 只要 info 级别，日志量可控 "-f", "rawvideo", "-pix_fmt", o.PixelFormat, "-s", $"{o.Width}x{o.Height}", "-r", o.Fps.ToString(), "-i", "pipe:0", // 关键：从标准输入读 "-f", "lavfi", "-i", $"anullsrc=channel_layout=stereo:sample_rate={o.AudioSampleRate}", "-c:v", o.VideoEncoder, "-preset", o.Preset, "-tune", "zerolatency", // 关掉编码器内部的前瞻缓冲 "-b:v", $"{o.VideoKbps}k", "-maxrate", $"{o.VideoKbps}k", "-bufsize", $"{o.VideoKbps * 2}k", "-g", gop.ToString(), "-keyint_min", gop.ToString(), "-sc_threshold", "0", // 禁止场景切换插关键帧 "-pix_fmt", "yuv420p", // 输出色彩空间，兼容性最好 "-c:a", "aac", "-b:a", $"{o.AudioKbps}k", "-ar", o.AudioSampleRate.ToString(), "-ac", "2", "-rw_timeout", "5000000", "-flvflags", "no_duration_filesize", "-f", "flv", o.OutputUrl }; }

注意这里有个容易搞混的地方:命令里出现了两次-pix_fmt。第一个在输入端,描述喂进来的数据是什么格式;第二个在输出端,描述编码后的数据是什么格式。前者不对,画面颜色会错乱;后者不对,下游播放器可能解不出来。我第一次写的时候只写了前面那个,结果推上去的画面在部分播放器里是绿屏。

3.2 进程启动:三个开关必须开

var psi = new ProcessStartInfo { FileName = ffmpegPath, UseShellExecute = false, CreateNoWindow = true, RedirectStandardInput = true, RedirectStandardOutput = true, RedirectStandardError = true, }; foreach (var a in BuildArguments(options)) psi.ArgumentList.Add(a); _process = new Process { StartInfo = psi, EnableRaisingEvents = true }; _process.Start(); _stdin = _process.StandardInput.BaseStream;

UseShellExecute = false是必须的,否则重定向全都不生效,而且会弹出一个黑窗口——在客户端软件里看到这个窗口,用户第一反应就是"这软件是不是有毒"。CreateNoWindow = true兜底,防止控制台子系统仍然创建窗口。

真正容易漏的是RedirectStandardError = true之后没人去读它。Windows 上管道的默认缓冲区只有几 KB,FFmpeg 的-stats输出是不断刷新的进度行,一旦缓冲区写满,FFmpeg 的日志线程就会阻塞,进而整个进程卡死,表现为"推流推了几分钟突然不动了"。这个坑我踩过两次,两次都是在线上的定时任务里发作,排查起来极其难受。

解决办法是给 stderr 单独开一个后台读取线程,循环ReadLine(),把内容丢进一个环形缓冲,同时做关键字匹配。顺带把StandardOutput也重定向并读空,虽然正常情况下 FFmpeg 不往 stdout 写东西,但保险起见还是读掉。

3.3 喂帧:节奏控制比写入本身更重要

写帧的代码本身很短,难的是节奏。

public bool WriteFrame(byte[] frame) { if (!_running || _stdin == null) return false; try { _stdin.Write(frame, 0, frame.Length); _stdin.Flush(); // 必须 Flush，否则数据会滞留在缓冲区 return true; } catch (IOException) { // 管道破裂 = FFmpeg 进程已经退出 HandleProcessExit(); return false; } }

Flush()这一句非常关键。BaseStream在 .NET 里默认带缓冲,如果你不 Flush,数据会攒到缓冲区满才真正写进管道,表现就是画面延迟越推越大,而且延迟量极不稳定。有人为了减少系统调用频率会把StandardInput换成自定义的大缓冲流,再做整帧批量写入——这确实能降低 CPU,但前提是你严格按帧边界 Flush,否则延迟会失控。

节奏方面,我的做法是维护一个"目标时间轴":启动时记一个Stopwatch,每写一帧就计算"这一帧本该在第几毫秒发出",如果当前时间落后于目标,立刻写;如果超前,就SpinWait或Thread.Sleep(1)等一小会儿。这样即使采集侧偶尔抖动,长时间平均帧率也是稳定的。

这里有个取舍要讲清楚:如果你不加-re参数,FFmpeg 会尽最大速度消费管道里的数据,它不关心你喂多快,帧率完全由你的写入速度决定。所以节奏控制的活必须在你这边干。相反,如果你给输入加了-re,FFmpeg 会按-r指定的帧率限速读取,你不喂它也会等着——但这样多了一层不必要的耦合,而且管道里的积压会变成延迟。我倾向于不加-re,自己在 C# 侧控节奏,链路更透明。

写帧失败的处理也要注意。管道破裂时Write抛的是IOException,不是ObjectDisposedException,别抓错类型。而且破裂之后这个_stdin就废了,必须整体重启进程,不能指望重新Open一次——StandardInput是一次性的。

3.4 日志解析:把文本翻译成状态机

FFmpeg 的进度行长这样:

frame= 1234 fps= 30 q=28.0 size= 2048kB time=00:00:41.13 bitrate= 407.9kbits/s speed=1.00x

我们要从里面抠三个数:fps、speed、bitrate。fps是实际编码帧率,speed是编码速度相对实时的倍率——这个值低于 1.0 就意味着编码跟不上采集,画面会开始堆积。bitrate用于检测码率是否按预期输出,如果实际码率远低于设定值,通常是画面太简单或者编码参数有问题。

private static readonly Regex ProgressRx = new Regex( @"frame=\s*(\d+).*?fps=\s*([\d\.]+).*?bitrate=\s*([\d\.]+)kbits/s.*?speed=\s*([\d\.]+)x", RegexOptions.Compiled); private void OnStderrLine(string line) { var m = ProgressRx.Match(line); if (m.Success) { _lastFps = double.Parse(m.Groups[2].Value); _lastBitrate = double.Parse(m.Groups[3].Value); _lastSpeed = double.Parse(m.Groups[4].Value); if (_lastSpeed < 0.9) RaiseWarning("编码速度不足，建议降低分辨率或换更快的预设"); return; } if (line.Contains("Connection refused") || line.Contains("Connection reset")) RaiseFault(FaultKind.NetworkUnreachable); else if (line.Contains("Server error") || line.Contains("handshake")) RaiseFault(FaultKind.AuthRejected); }

匹配失败时不要把整行丢掉,存进一个固定长度的环形缓冲(比如最近 200 行)。用户报障的时候,你把这 200 行导出成文本,问题基本就定位得差不多了。这个功能救过我很多次,因为用户描述的现象往往是"它不动了",而日志里写的是明确的原因。

3.5 优雅停止:别用 Kill 直接砍

停止推流时的顺序是:_stdin.Close()→ 等进程自己退出(最多等 3 秒) → 还没退就Kill()。先关管道,FFmpeg 读到 EOF 会自己结束并冲刷掉 FLV 的尾部数据,这样服务器那边收到的流是完整的,不会挂着一个"僵尸会话"直到超时。

直接Kill()的后果是服务器端迟迟不释放这个流 key,你立刻重连会被拒绝,典型报错是"stream already publishing"。这个现象在调试阶段特别迷惑人,因为代码看起来毫无问题,实际上要等服务器端超时清理。我在测试环境里专门加了一条规则:重启推流前至少等 2 秒。

Process对象本身也要Dispose(),否则句柄会泄漏。长期运行的程序里,每重连一次泄漏几个句柄,跑一两天就会耗尽。记得把EnableRaisingEvents打开的Exited事件也一并解绑,事件持有引用会阻止对象回收。

4. 完整实操:从零跑通一条本地推流链路

4.1 环境准备清单

先把东西备齐,这里列的版本区间是我实际验证过能稳的,不是随便写的。

选 FFmpeg 构建时有个必须注意的点:某些精简构建里不含 H.264 编码器,因为它涉及额外的许可条款。下载后一定要先验一遍:

ffmpeg -hide_banner -encoders | grep 264

Linux 上用grep,Windows 上换成findstr。输出里至少要看到libx264,如果想要硬件编码还要看到h264_nvenc(NVIDIA)、h264_qsv(Intel)、h264_amf(AMD)。看不到就换一个完整构建,别浪费时间在编译参数上。

关于分发,我建议把 FFmpeg 可执行文件随程序一起打包,放在ffmpeg/bin/目录下,启动时用相对路径解析。依赖系统 PATH 里的版本,在客户机器上几乎必然出问题——你永远不知道对方装的是哪个三年老版本,而且参数兼容性差异很大。

4.2 第一步:用测试信号跑通链路,先别碰采集

这一步是我强烈建议的做法:在接入真实采集之前,先用 FFmpeg 自己生成的测试图案验证整条链路。这样一旦出问题,你能确定问题在推流参数或服务器,不在采集代码。

ffmpeg -hide_banner -loglevel info ^ -re -f lavfi -i testsrc2=size=1280x720:rate=30 ^ -f lavfi -i sine=frequency=440:sample_rate=44100 ^ -c:v libx264 -preset veryfast -tune zerolatency ^ -b:v 2500k -maxrate 2500k -bufsize 5000k ^ -g 60 -keyint_min 60 -sc_threshold 0 ^ -pix_fmt yuv420p ^ -c:a aac -b:a 128k -ar 44100 -ac 2 ^ -flvflags no_duration_filesize ^ -f flv rtmp://127.0.0.1:1935/live/test

testsrc2会画出一个带时间码和移动色块的画面,sine生成 440Hz 的正弦音。这条命令跑起来之后,用播放器拉一下rtmp://127.0.0.1:1935/live/test,如果能听到"嘟——"的连续音、看到跳动的数字,说明服务器、网络、参数全都对了。这时候再往 C# 里搬,成功率会高很多。

这条命令里的-re是必须的,因为输入是文件式的 lavfi 源,不加-re会全速生成,一瞬间推完几百帧然后卡住。而到了管道输入的场景,-re就不需要了,原因前面讲过。

4.3 第二步:C# 侧的完整最小可用实现

下面这个类去掉了我项目里的业务耦合,只保留推流核心。可以直接建个控制台项目跑起来。

using System; using System.Collections.Generic; using System.Diagnostics; using System.IO; using System.Text.RegularExpressions; using System.Threading; public enum PushState { Idle, Starting, Running, Faulted, Stopped } public sealed class RtmpPusher : IDisposable { private Process _proc; private Stream _stdin; private Thread _errReader; private volatile bool _running; private readonly Queue<string> _logTail = new Queue<string>(); private readonly object _logLock = new object(); private double _lastFps, _lastSpeed; public PushState State { get; private set; } = PushState.Idle; public event Action<PushState, string> OnStateChanged; private static readonly Regex ProgressRx = new Regex( @"fps=\s*([\d\.]+).*?speed=\s*([\d\.]+)x", RegexOptions.Compiled); public bool Start(PushOptions o, string ffmpegPath) { if (_running) return false; try { var psi = new ProcessStartInfo { FileName = ffmpegPath, UseShellExecute = false, CreateNoWindow = true, RedirectStandardInput = true, RedirectStandardOutput = true, RedirectStandardError = true, }; int gop = o.Fps * o.KeyframeIntervalSeconds; var args = new List<string> { "-hide_banner", "-loglevel", "level+info", "-f", "rawvideo", "-pix_fmt", o.PixelFormat, "-s", $"{o.Width}x{o.Height}", "-r", o.Fps.ToString(), "-i", "pipe:0", "-f", "lavfi", "-i", $"anullsrc=channel_layout=stereo:sample_rate={o.AudioSampleRate}", "-c:v", o.VideoEncoder, "-preset", o.Preset, "-tune", "zerolatency", "-b:v", $"{o.VideoKbps}k", "-maxrate", $"{o.VideoKbps}k", "-bufsize", $"{o.VideoKbps * 2}k", "-g", gop.ToString(), "-keyint_min", gop.ToString(), "-sc_threshold", "0", "-pix_fmt", "yuv420p", "-c:a", "aac", "-b:a", $"{o.AudioKbps}k", "-ar", o.AudioSampleRate.ToString(), "-ac", "2", "-rw_timeout", "5000000", "-flvflags", "no_duration_filesize", "-f", "flv", o.OutputUrl }; foreach (var a in args) psi.ArgumentList.Add(a); _proc = new Process { StartInfo = psi, EnableRaisingEvents = true }; _proc.Exited += (s, e) => OnProcessExited(); _proc.Start(); _stdin = _proc.StandardInput.BaseStream; _errReader = new Thread(ReadStderrLoop) { IsBackground = true }; _errReader.Start(); _ = _proc.StandardOutput.ReadToEndAsync(); // 读空，防止缓冲写满 _running = true; SetState(PushState.Running, "started"); return true; } catch (Exception ex) { SetState(PushState.Faulted, "start failed: " + ex.Message); Cleanup(); return false; } } public bool WriteFrame(byte[] frame) { if (!_running || _stdin == null) return false; try { _stdin.Write(frame, 0, frame.Length); _stdin.Flush(); return true; } catch (Exception ex) when (ex is IOException || ex is ObjectDisposedException) { SetState(PushState.Faulted, "pipe broken"); return false; } } private void ReadStderrLoop() { try { string line; while ((line = _proc.StandardError.ReadLine()) != null) { lock (_logLock) { _logTail.Enqueue(line); while (_logTail.Count > 200) _logTail.Dequeue(); } var m = ProgressRx.Match(line); if (m.Success) { _lastFps = double.Parse(m.Groups[1].Value); _lastSpeed = double.Parse(m.Groups[2].Value); } } } catch { /* 进程退出时读线程会异常，忽略 */ } } private void OnProcessExited() { if (!_running) return; _running = false; string reason = string.Join(" | ", GetLogTail(10)); SetState(PushState.Faulted, "ffmpeg exited: " + reason); } public string[] GetLogTail(int n) { lock (_logLock) { var arr = _logTail.ToArray(); int start = Math.Max(0, arr.Length - n); return arr[start..]; } } public double LastFps => _lastFps; public double LastSpeed => _lastSpeed; public void Stop() { if (!_running && _proc == null) return; _running = false; try { _stdin?.Flush(); _stdin?.Close(); } catch { } try { if (_proc != null && !_proc.WaitForExit(3000)) _proc.Kill(true); } catch { } Cleanup(); SetState(PushState.Stopped, "stopped"); } private void Cleanup() { try { _stdin?.Dispose(); } catch { } _stdin = null; try { _proc?.Dispose(); } catch { } _proc = null; } private void SetState(PushState s, string msg) { State = s; OnStateChanged?.Invoke(s, msg); } public void Dispose() => Stop(); }

配套的喂帧循环,用一个伪造的渐变帧做压力测试:

int w = 1280, h = 720, fps = 30; var opts = new PushOptions { OutputUrl = "rtmp://127.0.0.1:1935/live/test", Width = w, Height = h, Fps = fps, VideoKbps = 2500 }; var pusher = new RtmpPusher(); pusher.OnStateChanged += (s, m) => Console.WriteLine($"[{s}] {m}"); pusher.Start(opts, "./ffmpeg/bin/ffmpeg.exe"); var frame = new byte[w * h * 4]; var sw = Stopwatch.StartNew(); long frameIndex = 0; bool wentDown = false; while (true) { if (pusher.State == PushState.Faulted && !wentDown) { wentDown = true; Console.WriteLine("推流中断，3 秒后重连"); pusher.Stop(); Thread.Sleep(3000); pusher = new RtmpPusher(); pusher.Start(opts, "./ffmpeg/bin/ffmpeg.exe"); wentDown = false; sw.Restart(); frameIndex = 0; continue; } // 造一个横向滚动的渐变，方便肉眼判断有没有卡顿 int shift = (int)(frameIndex * 4) % w; for (int y = 0; y < h; y++) { int row = y * w * 4; for (int x = 0; x < w; x++) { int p = row + x * 4; frame[p + 0] = (byte)((x + shift) & 0xFF); // B frame[p + 1] = (byte)(y & 0xFF); // G frame[p + 2] = (byte)((x + shift) >> 1); // R frame[p + 3] = 255; // A } } pusher.WriteFrame(frame); frameIndex++; long target = frameIndex * 1000 / fps; long actual = sw.ElapsedMilliseconds; if (actual < target) Thread.Sleep((int)(target - actual)); }

这段代码跑起来之后,拉流能看到一条横向流动的彩色渐变带,没有卡顿、没有撕裂,就说明管道、编码、传输全通了。测试时可以拔一下网线,观察State是否在几秒内变成Faulted,以及重连逻辑是否按预期工作。

4.4 第三步:换成真实采集源

真实采集和测试帧的区别只有一个:帧数据的来源和格式。屏幕采集场景下,Windows 上可以用系统提供的图形采集接口拿到位图,LockBits之后逐行拷贝到byte[]里,注意前面提到过的步长问题。摄像头场景下,大多数采集组件给的是 YUY2 或 MJPG,前者需要把-pix_fmt改成yuyv422并把每帧字节数调整为width * height * 2,后者如果你不想解码,可以直接让采集组件输出 MJPG 然后改用-f mjpeg输入——但那样 GOP 就不好控制了,一般还是解码成原始帧更可控。

还有一个实际项目里的经验:采集和推流之间要加一个容量为 2 的帧队列。采集回调把帧塞进队列,推流线程从队列取。队列满了就丢弃最旧的一帧并计数。这样采集侧的偶发卡顿不会直接传导到推流侧,代价是可能丢帧。经验值是队列深度不要超过 3,再大延迟就上去了。

5. 故障排查:那些日志里看不出来的坑

5.1 连不上、秒断、伪连接

Connection refused是最好处理的,就是地址或端口不对,或者服务器没起来。麻烦的是"能连上但立刻断开",日志里只有一行Server error。这种情况九成是流 key 不对,或者上一次推流的会话还没被服务器释放。

我的排查顺序是:先用 FFmpeg 生成测试图案推同一个地址,如果用命令行能推、用程序不能推,那问题在参数或喂帧;如果命令行也推不了,就是地址/服务端的问题,跟代码无关。这个二分手法是所有排查里最快见效的。

还有一种诡异情况:日志显示握手成功、开始编码,但拉流端黑屏。这通常是关键帧没有及时发出。检查-g和-keyint_min是否设了,以及-sc_threshold是否关了。有些编码器在低码率下会长时间不产关键帧,播放器就一直等。

5.2 花屏、绿边、马赛克

花屏的原因集中在两个地方。一是喂进去的帧字节数和-s/-pix_fmt不匹配,FFmpeg 会按固定长度切分你的数据流,一旦错位整条流就是垃圾。二是管道写入过程中出现了部分写入——Stream.Write在理论上可能写不满,虽然FileStream/管道流一般会写满,但在异常关闭时可能出现半帧。

绿边的典型原因是分辨率不是偶数。H.264 的色度采样是 2×2 一个块,宽高必须是偶数,奇数宽高会导致边缘色度信息缺失。我遇到过 1365 这种宽度,采集侧给的就是奇数,必须在 C# 里裁成 1364 再推。

马赛克在低码率下属于正常现象,但如果只在画面快速运动时出现,说明-bufsize太小,码率控制来不及调整。适当加大-bufsize或者提高-maxrate,画面会平滑很多。

5.3 音画不同步

用anullsrc静音源时几乎不会出现这个问题,一旦接入真实音频,不同步就是高频问题。判断方法很简单:看延迟是恒定偏移还是逐渐累积。恒定偏移通常是时间基设置问题,加-itsoffset补偿即可;逐渐累积则是喂数据节奏问题——音频和视频两路数据的到达速率和它们的名义时钟不匹配。

我的处理原则是:音频永远不丢,视频可以丢。人类对声音断裂极其敏感,对掉几帧画面基本无感。所以在队列拥塞时,优先丢弃视频帧,音频帧尽量完整送入。

5.4 延迟越推越大

这是 RTMP 推流最典型的"慢性病"。三个原因按概率排序:一是不 Flush,数据在缓冲区堆积;二是喂帧速度超过实时,FFmpeg 内部缓冲越积越多;三是网络带宽不够,-maxrate超过了实际上行能力。

第二个原因值得展开说。-tune zerolatency能关掉编码器的 B 帧和前瞻,但关不掉 FFmpeg 内部的封装缓冲。如果你的喂帧速度比实时快 10%,一小时后就会积压 6 分钟的数据。所以节奏控制那块代码不是可选项,是必需项。

5.5 速查表

6. 性能与长期运行的工程化考量

6.1 编码器怎么选:先把 CPU 占用测出来

libx264是最稳的选择,兼容性最好,但在 1080p60 下用medium预设能吃满好几核。veryfast是画质和速度的平衡点,我大多数场景都用它。如果机器上有独立显卡,h264_nvenc能把 CPU 占用压到个位数,代价是低码率下画质略差,而且不同代显卡支持的预设名不一样。

关键提醒:硬件编码器的-preset取值和 x264 不一样,你不能把veryfast直接传给它。我的做法是在参数构造里按编码器名做一次映射,遇到硬件编码器就换一套预设名,否则会直接报 "Unknown preset"。另外硬件编码器对-tune zerolatency的支持也参差不齐,传了可能被忽略,不会报错但延迟不会降,这点要有心理预期。

6.2 长期运行:内存、句柄、日志三件事

一个连续跑 24 小时的推流程序,最容易出问题的地方往往不是推流本身。

内存方面,注意别在喂帧循环里反复分配byte[]。1280×720 的 BGRA 帧是 3.6MB,每秒 30 次分配就是 110MB/s 的分配速率,GC 会被打得很惨,表现为周期性卡顿。正确做法是预分配两个缓冲区做双缓冲,采集线程写 A,推流线程读 B,避免分配也避免锁竞争。

句柄方面,每次重连都会创建Process、Stream、Thread,必须保证全部释放。我加过一个统计,单次重连泄漏 4 个句柄,跑一天重连几十次就上千个。用Process.GetCurrentProcess().HandleCount定时打点,能很快看出趋势。

日志方面,_logTail那个环形缓冲要设上限,而且要考虑磁盘写入。如果每行都File.AppendAllText,磁盘 IO 会成为新的热点。我的做法是内存里只留最近 200 行,遇到Faulted状态才落盘一次,文件名带上时间戳。

6.3 监控什么指标才算真的在监控

推起来的流"看起来正常"是不可靠的,必须有几个数字。

speed这个值我觉得是最有价值的,它几乎是"机器还行不行"的直接答案。我在一个低配设备上见过speed长期在 0.7 附近波动,表现就是画面时不时卡一下,换成硬件编码器之后立刻恢复。

6.4 断线重连的状态机怎么写才不出乱子

重连不是简单地再Start一次。要注意三点:第一,重连前必须确保旧进程已经完全退出,否则服务器会拒绝新连接;第二,重连要有退避,连续快速重试会把服务器打成限流;第三,重连后帧序号要重置,否则节奏控制会以为已经落后一大截,疯狂补帧。

我的退避策略是 2s、4s、8s、16s、30s 封顶,连续失败 5 次就停下来通知用户,不要无限重试。因为无限重试会掩盖真实问题——如果是流 key 错了,重试一万次也没用,反而让用户以为程序在正常工作。

7. 我踩过的几个具体坑,给后来人省点时间

第一个坑是-nostdin。看到某些示例里命令带了这个参数,我直接抄了过来,结果推流一启动就报 "Error opening input"。原因很简单:-nostdin的作用是禁止 FFmpeg 从标准输入读交互命令,而我们恰恰是用pipe:0作为输入源。这两个是冲突的,加了就等于把自己的数据通道堵死了。

第二个坑是路径里的中文和空格。Windows 上如果 FFmpeg 放在C:\Program Files\我的工具\ffmpeg.exe,自己拼字符串启动会失败。用ArgumentList能解决参数转义,但FileName本身的路径问题还得靠引号或者短路径。最稳妥的办法是把 FFmpeg 放在程序目录下一个纯 ASCII 名字的子目录里。

第三个坑是防火墙。程序第一次启动 FFmpeg 时,系统会弹出网络访问询问。如果用户点了"取消",后续所有连接都会失败,而且日志里看不出原因,只有Connection refused。这种情况要么在安装时预置规则,要么在界面上给一句提示,让用户知道该去哪里放行。我在这上面被远程支持折腾过好几次。

第四个坑是-loglevel。默认级别是info,每次连接都会打一堆握手细节,日志量不小。但如果设成error,进度行就没了,你的speed解析会全部失效。正确的做法是设成level+info,保留进度行但去掉更啰嗦的debug/trace。这个参数看起来不起眼,却直接影响你的监控能力。

最后一个算不上坑,但值得说:先跑通最短路径,再往上加功能。我最开始就想一步到位做成"支持任意源、任意编码器、动态切换码率"的通用组件,结果两周没跑通一条流。后来退回去,先用一个固定分辨率、固定参数、静音音轨的最小链路跑通,确认能拉流、能看画面、能退出,再一项一项往上加,速度快了不止一倍。推流这件事的变量太多,同时改三个以上参数,一旦失败你根本不知道是哪个引起的。

现在这套代码在我的项目里已经稳定跑了小半年,日常推 1080p30、单机单路,CPU 占用在 15% 左右,重连逻辑触发过七八次,每次都能在十秒内恢复。如果你也在这条路上,建议先把第四章那段最小实现原样跑一遍,把管道、编码、传输这三个环节各自的"正常长什么样"刻进脑子里,后面遇到异常时,判断会快很多。