简介基于C# WinForms框架的视频压缩源码项目面向桌面应用开发与多媒体处理方向的学习者用来理解视频压缩流程和图形用户界面交互设计也适合作为课程设计或毕业设计的起步参考。压缩包内含三十一个文件以C#源程序为主要内容附带解决方案配置文件、编译生成的程序与调试信息、资源图标文件与版本缓存总体积十一点二二兆字节可在Visual Studio中直接加载运行。项目提供了完整示例覆盖视频文件读取、压缩参数设置、实时预览和编码输出等关键环节并展示如何调用Media Foundation或FFmpeg实现H.264标准的压缩。源码采用清晰的功能类划分例如编码器与视频文件处理类便于初学者参考窗体布局、控件事件以及多线程任务调度进阶开发人员也能研讨编码参数优化与内存管理技巧。目前已有七十三人学习非常适合入门C#桌面开发并探索视频处理技术。1. 这个“WinForms版视频压缩源码”到底解决什么问题一个 20 分钟的视频 1.2GB网盘传不动、微信发不出去、剪辑时预览都卡这是拿“基于C#的winfom框架GUI界面的视频压缩源码.zip”最典型的落地场景。标题拆开看就是两层C# WinForms 负责让普通人能点按钮、看进度条、选文件真正干压缩活的是 FFmpegC# 这边只是把转码命令包装成一个像样的 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、像素格式与兼容性参数是压缩工具的灵魂。下面的表是经过大量文件测试后我常用的参数组合参数常用值作用备注-c:v libx264固定视频编码器兼容性最好的 H.264 软编-presetmedium / veryfast编码速度与压缩率权衡越慢文件越小耗时越长-crf18 / 23 / 28恒定质量因子数值越小质量越高文件越大-pix_fmtyuv420p像素采样格式不设可能导致手机/网页播放器不认-tag:vavc1编码器标签写错会出现在电脑能放、手机不能放的情况-c:aaac音频编码器兼容性最好-movflagsfaststart将 moov 元数据移到文件头网页/在线播放无需下载完整个文件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 formatduration -of csvp0 \{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 csvp0让 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每行都是keyvalue用标准的 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 的值必须检查InvokeRequiredprivate void UpdateProgress(int percent) { if (InvokeRequired) { BeginInvoke(new Actionint(UpdateProgress), percent); return; } _pb.Value Math.Min(1000, Math.Max(0, percent)); }日志读取也类似FFmpeg 的编码信息、警告、错误都走 stderr把它接到日志框里压缩过程中能看到frame123 fps30 q28这类滚动信息。编码日志和进度是两个独立任务互不阻塞这正是异步读取的意义。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.xArgumentList不可用所以上面这个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 命令行里。这种做法天然规避了“程序发给别人后参数被反编译出来乱改”的问题配置和数据分离也让不同的压缩场景有各自的预设。批量压的逻辑不复杂遍历目录下所有视频文件逐个调用同一套压缩流程把源文件和时间戳写进一个待处理清单。这样早上把电脑一开晚上回来几十个视频就处理完了。我吃过一个亏批量压的时候忘了检查单个文件是否已经存在于输出目录结果一半文件被覆盖从那以后我的所有批量逻辑里都会先跑一遍“输入输出路径比对”再决定是跳过还是重命名。做这类工具宁可逻辑多一点也不能在数据安全上偷懒。希望这篇笔记能帮到你尤其是那些准备拿这个源码做二次开发的同行——把路径安全、异步不卡界面、参数模板这三件事做扎实工具就成功了一大半。本文还有配套的精品资源点击获取