简介：基于C# WinForms框架的视频压缩源码项目，面向桌面应用开发与多媒体处理方向的学习者，用来理解视频压缩流程和图形用户界面交互设计，也适合作为课程设计或毕业设计的起步参考。压缩包内含三十一个文件，以C#源程序为主要内容，附带解决方案配置文件、编译生成的程序与调试信息、资源图标文件与版本缓存，总体积十一点二二兆字节，可在Visual Studio中直接加载运行。项目提供了完整示例，覆盖视频文件读取、压缩参数设置、实时预览和编码输出等关键环节，并展示如何调用Media Foundation或FFmpeg实现H.264标准的压缩。源码采用清晰的功能类划分，例如编码器与视频文件处理类，便于初学者参考窗体布局、控件事件以及多线程任务调度，进阶开发人员也能研讨编码参数优化与内存管理技巧。目前已有七十三人学习，非常适合入门C#桌面开发并探索视频处理技术。

1. 这个“WinForms版视频压缩源码”到底解决什么问题

一个 20 分钟的视频 1.2GB，网盘传不动、微信发不出去、剪辑时预览都卡，这是拿“基于C#的winfom框架GUI界面的视频压缩源码.zip”最典型的落地场景。标题拆开看就是两层：C# WinForms 负责让普通人能点按钮、看进度条、选文件；真正干压缩活的是 FFmpeg，C# 这边只是把转码命令包装成一个像样的 GUI。适合两类人：一类是有批量化压缩需求但不想面对命令行的小团队，另一类是有 C# 基础、想搞明白“上位机怎么调外部进程”的开发者。别指望它是封装好的成品，把它当成一个能改、能扩展的工程骨架更实在。

2. 把WinForms窗体和FFmpeg接起来：先看懂源码里的两件事

2.1 WinForms 项目为什么到今天还值得拿来做视频压缩界面

WPF 的动画和样式确实更好看，但视频压缩工具的核心诉求是稳定、可分发、老机器能跑。WinForms 在这件事上有三个不可替代的优势：发布体积小，一个 exe 加一个 ffmpeg.exe 就能拷走；兼容性好，Windows 7 到 Windows 11 只要装个 .NET Framework 4.8 就能跑，工控机上尤其省心；代码直观，Form1.cs 里拖几个控件、写几行事件，新手也能看懂。

标题里的“winfom”是 WinForms 的常见拼写错误，源码里可能到处都是这个错法，不影响编译，但如果你要对外发布，最好把命名空间一起改掉。拿这个源码做二次开发时，核心不要放在界面有多华丽，而是把“选文件 -> 设参数 -> 调 FFmpeg -> 回传进度”这条链路走通。

2.2 主窗体代码骨架：不靠设计器也能把一个能用的窗口搭起来

很多压缩工具的源码是直接在 VS 设计器里拖出来的，Form1.Designer.cs 动一下就容易冲突。我一般习惯用代码构建界面，可读性和可维护性都好得多。下面是一个最小可用的主窗体骨架，包含了输入路径、输出路径、进度条、日志框四个核心区域：

public partial class MainForm : Form { private TextBox _txtInput; private TextBox _txtOutput; private ProgressBar _pb; private TextBox _txtLog; private readonly string _ffmpegPath = Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "ffmpeg.exe"); public MainForm() { BuildLayout(); } private void BuildLayout() { Text = "视频压缩工具（WinForms）"; ClientSize = new Size(740, 440); _txtInput = new TextBox { Left = 10, Top = 10, Width = 500 }; _txtOutput = new TextBox { Left = 10, Top = 45, Width = 500 }; _pb = new ProgressBar { Left = 10, Top = 80, Width = 690, Height = 22, Minimum = 0, Maximum = 1000 }; _txtLog = new TextBox { Left = 10, Top = 115, Width = 690, Height = 300, Multiline = true, ReadOnly = true, ScrollBars = ScrollBars.Vertical }; var btnPickSource = new Button { Text = "选择源文件", Left = 520, Top = 8, Width = 100 }; var btnPickTarget = new Button { Text = "选择输出目录", Left = 520, Top = 43, Width = 100 }; var btnStart = new Button { Text = "开始压缩", Left = 630, Top = 8, Width = 100 }; btnPickSource.Click += (s, e) => PickSource(); btnPickTarget.Click += (s, e) => PickTarget(); btnStart.Click += async (s, e) => await StartCompress(); Controls.AddRange(new Control[] { _txtInput, _txtOutput, _pb, _txtLog, btnPickSource, btnPickTarget, btnStart }); } }

这段代码里有几处值得注意。_ffmpegPath放在 exe 同级目录，比写死“C:\Program Files\ffmpeg\bin\ffmpeg.exe”要稳，打包分发时把 ffmpeg.exe 跟主程序放一起就不会出现找不到路径的问题。进度条的Maximum设成 1000 而不是 100，是为了后面计算百分比时可以保留一位小数，避免整数除法把进度直接砍成 0 或 100。控件全部用代码创建，意味着你拿到源码后不需要关心 Designer.cs 与窗体逻辑的绑定关系，把BuildLayout()里的坐标改一改就能调整布局。

2.3 文件选择与路径回填：把“选视频”这件事做稳妥

视频压缩最容易被忽略的一个细节是“用户选完文件后，输出路径自动生成”。如果让使用者手打输出文件名，十有八九会打出中文路径加空格，后面 FFmpeg 参数转义就会出问题。常见做法是在用户选完源文件后，自动在同目录生成一个带_compressed后缀的输出路径，随后用户可以再点“选择输出目录”修改。

private void PickSource() { using var dlg = new OpenFileDialog { Filter = "视频文件|*.mp4;*.avi;*.mov;*.mkv;*.wmv|所有文件|*.*", Title = "选择要压缩的视频" }; if (dlg.ShowDialog() != DialogResult.OK) return; _txtInput.Text = dlg.FileName; var dir = Path.GetDirectoryName(dlg.FileName); var name = Path.GetFileNameWithoutExtension(dlg.FileName); _txtOutput.Text = Path.Combine(dir, name + "_compressed.mp4"); } private void PickTarget() { using var dlg = new FolderBrowserDialog { Description = "选择输出目录" }; if (dlg.ShowDialog() != DialogResult.OK) return; var dir = dlg.SelectedPath; var name = Path.GetFileNameWithoutExtension(_txtInput.Text); _txtOutput.Text = Path.Combine(dir, name + "_compressed.mp4"); }

这段逻辑解决了一个实际问题：输出文件名永远不会跟输入文件名冲突。很多人第一次写压缩工具会默认输出到源文件同目录且同名，结果 FFmpeg 一启动就把原文件截断了，这个坑后面避坑章节还会细讲。FolderBrowserDialog在旧版 Windows 上看起来比较朴素，但它不需要额外引用，是 WinForms 里最稳的目录选择方式。

3. 真正的压缩按钮背后：C#进程调用、转码参数与进度回传

3.1 视频压缩的“压缩”到底压了什么：FFmpeg 与 x264 的工作边界

视频压缩不是简单降低分辨率或帧率，而是去掉空间冗余和时间冗余。拿 H.264 编码器 x264 举例：它会把画面分成一个个宏块，在帧内做 DCT 变换，丢掉人眼不敏感的高频细节；在帧间做运动估计，只记录“这一块从上一帧移动到了哪里、残差是多少”。FFmpeg 在这里承担的是输入解析、滤镜处理、编码调度、容器封装，真正的压缩算法在 libx264 里。

所以开发“视频压缩工具”时，90% 的工作量不是写压缩算法，而是把 FFmpeg 的命令行参数封装好。你不需要理解编码器内部的量化矩阵，但必须理解 CRF、preset、像素格式这几个直接影响文件大小和兼容性的参数。这也是很多“视频压缩源码”项目的真实形态：界面是 C# WinForms，核心是一个经过反复调试的 FFmpeg 参数模板。

3.2 C# 进程调用：最小可跑的压缩按钮

C# 里调用外部程序的标准做法是用System.Diagnostics.Process。网上很多源码直接用Process.Start("cmd.exe", "/c ffmpeg ...")，那样会闪黑窗，且容易受 cmd 转义规则影响。正确做法是直接启动 ffmpeg.exe，关闭 Shell，重定向标准输出和错误输出：

private async Task StartCompress() { var input = _txtInput.Text.Trim(); var output = _txtOutput.Text.Trim(); if (!File.Exists(input)) { MessageBox.Show("源文件不存在，请重新选择。"); return; } var arguments = $"-y -i \"{input}\" " + $"-c:v libx264 -preset medium -crf 23 " + $"-pix_fmt yuv420p -tag:v avc1 " + $"-c:a aac -b:a 128k " + $"-movflags +faststart " + $"\"{output}\""; var psi = new ProcessStartInfo { FileName = _ffmpegPath, Arguments = arguments, UseShellExecute = false, CreateNoWindow = true, RedirectStandardOutput = true, RedirectStandardError = true }; using var process = Process.Start(psi); var stdoutTask = Task.Run(() => ReadProgress(process, input)); var stderrTask = Task.Run(() => ReadLog(process)); await Task.WhenAll(stdoutTask, stderrTask); }

几个关键点需要说明。UseShellExecute = false是必须的，它告诉 .NET 直接启动进程而不经过 Shell，这样才能重定向输出、不弹黑窗。CreateNoWindow = true配合前者使用，否则压缩过程中会闪控制台窗口。路径用双引号包起来，是处理“Program Files”这类带空格路径的最基本手段，后面避坑章节会继续展开。

这段代码里stdoutTask和stderrTask同时读两条流，不是多此一举：如果只读 stderr 而不读 stdout，当 stdout 的管道缓冲区写满后，FFmpeg 会被阻塞住，整个进程卡死，这是个非常隐蔽的坑。-y参数表示输出文件已存在时直接覆盖，不需要用户再确认。

3.3 压缩参数怎么定：CRF、preset、像素格式与兼容性

参数是压缩工具的灵魂。下面的表是经过大量文件测试后我常用的参数组合：

CRF 的范围是 0 到 51，默认 23。做存档和剪辑素材时用 18 到 20，视觉上几乎无损；发微信、传网盘用 26 到 28，文件体积能压到原来的五分之一甚至更小。preset 从 ultrafast 到 veryslow 一共 9 档，我一般建议 medium 起步，觉得慢就换 veryfast，但不要直接上 ultrafast，同样的 CRF 下文件会明显变大。

-pix_fmt yuv420p是我见过最容易被漏掉的参数。libx264 有时候会根据源视频输出 yuv444，在 Windows 自带播放器上可能没问题，但放到某些手机播放器或网页播放器里就花屏。强制转成 yuv420p 牺牲一点点色彩精度，换来的是“在哪都能播”。-tag:v avc1同理，它会让封装器在 MP4 的 CodecTag 里写清楚这是 H.264 编码，避免安卓设备识别成其他编码导致无法硬解。

3.4 先拿总时长：把 ffprobe 接进来才能算进度百分比

进度条要显示百分比，就必须知道源视频总时长。ffprobe 和 ffmpeg 同目录，用一条命令就能读出时长：

private double GetDurationSec(string videoPath) { var psi = new ProcessStartInfo { FileName = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "ffprobe.exe"), Arguments = $"-v error -show_entries format=duration -of csv=p=0 \"{videoPath}\"", UseShellExecute = false, CreateNoWindow = true, RedirectStandardOutput = true, RedirectStandardError = true }; using var p = Process.Start(psi); var text = p.StandardOutput.ReadToEnd(); return double.TryParse(text.Trim(), out var seconds) ? seconds : 0; }

这里用-of csv=p=0让 ffprobe 只输出一个数字，不带字段名，方便TryParse。调用是同步的，因为 ffprobe 读取元数据极快，通常一秒钟内返回，不需要启动异步任务。如果拿到的时长是 0，要警惕两种可能：视频文件损坏，或者 ffprobe 路径不对导致Process.Start抛异常。

4. 压缩时界面卡死不是玄学：异步读取与进度条刷新的正确写法

4.1 压缩时窗体未响应，是主线程的消息循环被阻塞了

很多视频压缩源码跑起来后，一点“开始压缩”，整个窗体就变白、标题栏出现“未响应”。原因不是 FFmpeg 太占资源，而是你在 UI 线程里调用了process.WaitForExit()。Windows 的 WinForms 程序靠消息循环处理鼠标、键盘、重绘消息，UI 线程一旦同步等待子进程退出，就无法处理WM_PAINT，系统就会判定窗口无响应。

这个问题在 C# 上位机开发里非常常见。解决思路不是“把等待放到后台线程”这么简单，而是要把 FFmpeg 的输出读取、取消操作都放到非 UI 线程，只把进度和日志通过安全方式回传到 UI 线程。异步方法配合Task.Run是最常见的做法，上一章给的StartCompress就是异步版本，这章把进度读取部分展开讲。

4.2 用 progress 管道格式拿到实时压缩百分比

解析 FFmpeg 进度有好几种方案，最土的是从 stderr 里正则匹配time=，但 FFmpeg 的进度信息用\r结尾，StreamReader.ReadLine()按换行符拆分，经常拿不到完整数据。我推荐使用 FFmpeg 自带的-progress pipe:1 -nostats方案，它会让进度信息以固定格式写到 stdout，每行都是key=value，用标准的 ReadLine 就能稳定解析：

private void ReadProgress(Process process, double totalSec) { var lastShown = -1; while (!process.StandardOutput.EndOfStream) { var line = process.StandardOutput.ReadLine(); if (line == null || !line.StartsWith("out_time_ms=", StringComparison.Ordinal)) { continue; } var msText = line.Substring("out_time_ms=".Length); if (!long.TryParse(msText, out var micros) || totalSec <= 0) { continue; } var ratio = micros / 1_000_000.0 / totalSec; if (ratio > 1.0) ratio = 1.0; var percent = (int)(ratio * 1000); if (percent != lastShown) { lastShown = percent; UpdateProgress(percent); } } }

FFmpeg 的out_time_ms单位是微秒，不是毫秒，所以要先除以一百万换算成秒，再除以总时长得到比例。lastShown变量做的是节流：进度条按千分之一精度更新时，一秒钟可能触发几十次，每次都跨线程刷新 UI 不但浪费，还会让进度条闪烁。只有百分比真正变化时才更新，这是实际项目里很有效的手法。

对应的 UI 更新方法要注意跨线程问题。后台线程不能直接改 ProgressBar 的值，必须检查InvokeRequired：

private void UpdateProgress(int percent) { if (InvokeRequired) { BeginInvoke(new Action<int>(UpdateProgress), percent); return; } _pb.Value = Math.Min(1000, Math.Max(0, percent)); }

日志读取也类似，FFmpeg 的编码信息、警告、错误都走 stderr，把它接到日志框里，压缩过程中能看到frame=123 fps=30 q=28这类滚动信息。编码日志和进度是两个独立任务，互不阻塞，这正是异步读取的意义。

4.3 取消按钮与半成品文件的清理

用户压到一半发现参数设错了，想取消，这时不能直接杀掉进程了事。process.Kill()会立即终止 ffmpeg，但输出文件里可能已经写入了不完整的数据，留下一个半成品。取消的正确姿势是杀进程、清理半成品、把进度条归零：

private Process _currentProcess; private void CancelCompress() { try { _currentProcess?.Kill(); } catch { // 进程可能已经正常退出 } _currentProcess?.Dispose(); _currentProcess = null; var output = _txtOutput.Text.Trim(); TryDeleteIncompleteFile(output); UpdateProgress(0); } private void TryDeleteIncompleteFile(string path) { for (var i = 0; i < 5; i++) { try { if (File.Exists(path)) File.Delete(path); break; } catch (IOException) { Thread.Sleep(300); } } }

这里给_currentProcess留了个句柄，在StartCompress里Process.Start后立刻赋值。Kill之后要Dispose，否则进程对象会占用句柄。删除半成品时重试 5 次、间隔 300 毫秒，是因为输出文件可能刚被 FFmpeg 释放，也可能正被杀毒软件或播放器短暂占用，立刻删除会抛 IOException。等待轮询比直接报错要友好，这也是文件操作里的常见做法。

如果把 FFmpeg 当作上位机的子进程来管理，这套“启动、读取、取消、清理”的流程可以复用到很多场景，不只是视频压缩。记住一个原则：外部程序启动后，你不仅要管它怎么开始，还要管它怎么结束、结束时留下什么痕迹。

5. 参数怎么调都不对？五条高频踩坑记录与排查路径

5.1 标题里的“winfom”是笔误，项目代码里可能到处都是

现象：源码里项目名、命名空间、窗体类名都写着winfom，看起来像下载到了不完整的代码。原因：作者创建项目时手滑把 WinForms 拼错了，Visual Studio 不会纠正。解决：项目能编译就不用管；如果要发布或二次开发，用 VS 的重命名功能把命名空间和程序集名一起改掉，不影响任何功能。这类问题算不上故障，但排查问题时看到形如Winfom.VideoCompress的命名空间，要能一眼认出它对应的就是 WinForms 工程。

5.2 中文路径和带空格路径导致 FFmpeg 直接失败

现象：压缩按钮点了以后，日志框出现No such file or directory，或者只有一闪而过的错误提示，文件没生成。原因：ProcessStartInfo.Arguments接收的是一个普通字符串，系统会按空格把它拆成多个参数。C:\My Videos\测试素材.mp4这种路径一拆就乱。解决：所有路径都要手动加双引号包裹，参数串里不能裸放路径。必要时写一个专门的引用函数：

private static string Quote(string path) { return "\"" + path.Replace("\"", "\\\"") + "\""; }

如果项目已经迁移到 .NET 6 以上，优先使用ProcessStartInfo.ArgumentList，它会在内部处理引号和转义，能省掉一大半路径地狱。但老源码大概率是 .NET Framework 4.x，ArgumentList不可用，所以上面这个Quote函数在最常见的场景里更实用。

5.3 两条输出流只读一条，进程卡死在一半

现象：压缩开始后进度条停在一个数字不动，日志也不再刷新，但任务管理器里 ffmpeg 进程还在运行。原因：FFmpeg 同时往 stdout 和 stderr 写数据，如果只重定向了一条流，另一条流的管道缓冲区写满后，进程写入阻塞，整个编码被迫暂停。解决：两条流必须同时读取。之前StartCompress里用两个Task.Run分别读进度和日志，就是为了避免这个死锁。排查时先看代码里有没有只调用ReadToEnd没有开第二个读取任务的写法。

5.4 输入输出相同路径，原文件被截断成 0 字节

现象：压缩完，源文件变成 0 字节，输出文件也没有生成。原因：用户选择了源文件同目录、同文件名的输出路径，FFmpeg 在打开输出文件的瞬间就截断了原文件，然后编码器从空文件里读不到数据，整个任务失败。这是最可怕的一类坑，因为数据直接丢了。解决：在点击压缩按钮后、启动进程前，先比较输入和输出的完整路径：

if (string.Equals( Path.GetFullPath(_txtInput.Text), Path.GetFullPath(_txtOutput.Text), StringComparison.OrdinalIgnoreCase)) { MessageBox.Show("输出路径不能与源文件相同，已自动修改。"); _txtOutput.Text = Path.Combine( Path.GetDirectoryName(_txtInput.Text), Path.GetFileNameWithoutExtension(_txtInput.Text) + "_compressed.mp4"); return; }

从源头避免风险，好过压完发现文件没了再找后悔药。文件操作类的工具，所有覆盖写出的场景都要在代码层堵住这个可能。

5.5 退出码 0 但文件不存在：当前目录和杀毒软件一起捣乱

现象：进程正常结束，日志显示最后一行frame=...，退出码拿到 0，但输出目录里找不到文件。原因：两种常见情况。第一种，输出路径是相对路径，程序的工作目录被系统改成了C:\Windows\System32，文件被写到了奇怪的位置；第二种，杀毒软件或播放器占用了输出文件，FFmpeg 写入失败但没把退出码置为非 0。解决：输出路径在代码里用Path.GetFullPath强制转成绝对路径；压缩结束后轮询检查文件是否存在：

for (var i = 0; i < 5 && !File.Exists(outputAbsolutePath); i++) { Thread.Sleep(300); } if (!File.Exists(outputAbsolutePath)) { _txtLog.AppendText("压缩已结束，但输出文件不存在，请检查杀毒软件和输出目录。"); }

如果确实是被占用，等 300 毫秒重试往往就过去了。这个轮询也能顺带验证压缩流程是否真正走完，比只看退出码靠谱得多。

6. 压完怎么判断成不成：肉眼质检、批量压与配置外置

6.1 用 PSNR 和抽帧做客观对比

压缩完先看文件大小有没有达到预期，然后不能只看项目里能播就收工。把压缩前后的视频用 FFmpeg 算一下 PSNR，能快速得到一个客观数值：PSNR 高于 37dB 时肉眼几乎看不出差异，低于 30dB 就能明显看到块状失真和边缘模糊。实际命令不需要额外程序，FFmpeg 自带这个滤镜：

ffmpeg -i original.mp4 -i compressed.mp4 -lavfi psnr -f null -

终端会输出PSNR y:36.82 u:42.01 v:43.20 average:38.12，看 average 就行。这个值是个统计指标，不能完全替代人眼，但用来做不同 CRF 的对比验证非常有效率。我一般的习惯是压完先抽一帧暗部较多的画面放到手机上放大看，暗部噪点才是压缩最容易翻车的地方。

6.2 批量压缩：把参数模板和文件清单外置成 JSON

工具给一个人用，界面上写死 CRF 23 就够了；要给团队用，就要把参数做成可配置。最简单的做法是让程序启动时读取同级目录下的profiles.json，用 JSON 保存压缩模板，运行时 C# 反序列化成参数列表，再拼到 FFmpeg 命令行里。这种做法天然规避了“程序发给别人后，参数被反编译出来乱改”的问题，配置和数据分离，也让不同的压缩场景有各自的预设。

批量压的逻辑不复杂：遍历目录下所有视频文件，逐个调用同一套压缩流程，把源文件和时间戳写进一个待处理清单。这样早上把电脑一开，晚上回来几十个视频就处理完了。我吃过一个亏：批量压的时候忘了检查单个文件是否已经存在于输出目录，结果一半文件被覆盖，从那以后我的所有批量逻辑里都会先跑一遍“输入输出路径比对”，再决定是跳过还是重命名。

做这类工具，宁可逻辑多一点，也不能在数据安全上偷懒。希望这篇笔记能帮到你，尤其是那些准备拿这个源码做二次开发的同行——把路径安全、异步不卡界面、参数模板这三件事做扎实，工具就成功了一大半。

本文还有配套的精品资源，点击获取