尧图网站建设 
简介这是一份基于WPF与C#调用FFmpeg实现的媒体转换器完整项目覆盖音频转换、视频转换、视频压缩、视频编辑与多文件合并等常用功能可满足普通用户日常转码、压缩和简单剪辑需求对开发者而言也能从中学习WPF界面布局与FFmpeg命令行集成的实战写法。压缩包内共256个文件以177个cs源码、6个xaml界面文件为主并包含34个bat功能脚本、15个dll运行库、可执行exe及工程配置文件整体仅18.05MB结构清晰便于按需查看与二次开发。除主程序外脚本还覆盖屏幕录制、RTMP推流、批量截图、摄像头参数探测等实用场景相当于一套可直接调用的FFmpeg操作示例。目前已有78人学习如果你正打算用WPF开发媒体处理工具或希望快速调用FFmpeg完成转码、推流、录屏等任务这套资源会是不错的参考。1. 先把 WPF 媒体转换器讲清楚FFmpeg 负责转码你负责不卡界面媒体转换器这类软件核心不是“把按钮接到 ffmpeg.exe 上”而是把 FFmpeg 的进程生命周期和 WPF 的 UI 生命周期对齐。许多人拿到类似的源码包后第一眼会去翻转码逻辑最后往往卡在同一个地方界面卡死、进度条不走、任务取消后留了一堆坏文件。其实 FFmpeg 的命令行本身很成熟真正的信息量在异步任务设计、进度解析和参数构造。下面这些内容直接用 WPF 做壳把 FFmpeg 当后台工作进程用覆盖音频转换、视频转换、视频压缩、视频编辑、合并转换这几类高频功能。适合 C# 桌面开发者和想从工具源码里摘一套稳定命令的人。2. FFmpeg 接入 WPF 的两种方式与最小 Runner 封装2.1 进程调用优先于库封装Windows 桌面上使用 FFmpeg常见做法是启动 FFmpeg.exe 子进程而不是把整套解码库编译进程序。子进程方式的好处是把人和机器的接口简化成命令行参数换音视频格式、压缩、裁剪、合并全部都是参数的排列组合不涉及 C# 与 C 的内存边界。少数情况会用到 FFmpeg.AutoGen 之类的绑定库比如需要逐帧拿到 AVFrame 做特效但那是媒体处理器的玩法不是媒体转换器的正常选择。下面这个表列出了两种路径的取舍接入方式开发量进度获取适合场景子进程调用 FFmpeg.exe低解析 stdout/stderr 或 progress音频转换、视频压缩、合并内嵌 FFmpeg 库绑定高回调、帧级数据自定义滤镜、帧级编辑对转换器而言选子进程还带来一个额外好处FFmpeg 更新紧跟官方不需要重新编译宿主程序。只要把 exe 版本换掉参数和进度解析逻辑可以原样保留。下面用一个 Runner 类来说明最少骨架。2.2 最小 Runner启动进程、同时读取两个输出流写 Runner 时最容易犯两个错误用字符串拼接命令行以及只重定向 stderr。前者让路径带空格的用户直接失败后者会因为 stdout 缓冲区写满让 FFmpeg 卡死。下面这个版本用 .NET 的 ProcessStartInfo 同时重定向标准输出和标准错误并在等待退出前启动两个读取任务public sealed class FFmpegRunner { private readonly string _ffmpegPath; public FFmpegRunner(string ffmpegPath) _ffmpegPath ffmpegPath; public async Taskint RunAsync(IReadOnlyListstring args, CancellationToken ct default) { var psi new ProcessStartInfo { FileName _ffmpegPath, UseShellExecute false, CreateNoWindow true, RedirectStandardError true, RedirectStandardOutput true, }; psi.ArgumentList.Add(-y); // 覆盖已存在的输出文件 psi.ArgumentList.Add(-hide_banner); // 去掉一屏幕的版本横幅 foreach (var a in args) psi.ArgumentList.Add(a); using var process Process.Start(psi) ?? throw new InvalidOperationException(无法启动 FFmpeg 进程); // 先启动输出读取避免管道缓冲区写满后 FFmpeg 阻塞 var stderrTask process.StandardError.ReadToEndAsync(ct); var stdoutTask process.StandardOutput.ReadToEndAsync(ct); await process.WaitForExitAsync(ct); _lastError await stderrTask; await stdoutTask; return process.ExitCode; } }ArgumentList会正确处理路径里的空格和引号所以输入输出路径直接加入集合即可不要手动拼\\。ReadToEndAsync必须在WaitForExitAsync之前启动否则当视频文件较大时FFmpeg 输出的日志会填满管道缓冲区子进程被堵住。退出码非 0 时_lastError里通常已经有 error 级别的具体原因显示给用户即可。2.3 构造参数而不是拼接字符串FFmpeg 的参数有明确的位置要求输入参数通常放在-i之前输出参数放在输出文件之前。把-ss、-t这类参数直接拼在路径后面很容易让它们被解析成输出选项造成诡异的播放时间错误。更可靠的做法是构造Liststring再用 Runner 的例子逐项加入var args new Liststring { -i, inputPath, -c:v, libx264, -crf, crf.ToString(), -preset, preset, outputPath };常见的参数位置如下表参数位置常见内容说明输入区-ss,-i input控制开始时间、输入文件输出区-c:v,-crf,-b:a,-vf决定编码方式和滤镜全局-y,-progress pipe:1,-loglevel覆盖、进度、日志控制-vf严格说是输出端滤镜要放在输出文件前。-map 0也在输出区用于选择流没有显式写时 FFmpeg 会自动选一条视频和一条音频但会忽略字幕。做工具时默认加-map 0并让用户在界面上勾选要保留的流比放任 FFmpeg 自动选择更容易控制。3. 媒体转换器的异步任务进度、取消与临时文件3.1 用 -progress pipe:1 得到可解析的进度FFmpeg 默认把转码信息写到 stderr格式是 frame、fps 这种给人读的内容换行时间不稳定解析会非常费劲。要拿给 UI 显示正确做法是让 FFmpeg 用-progress pipe:1输出键值对。它把进度分块写到标准输出每块结尾是 progresscontinue 或 progressend。配合-nostats -loglevel error标准错误就只剩真正的错误信息不用再过滤一屏的 bitrate。ffmpeg -progress pipe:1 -nostats -loglevel error -i input.mp4 -c:v libx264 output.mp4输出会是这样out_time_us8320000 out_time_ms8320000 out_time00:00:08.320000 speed3.15x progresscontinueout_time_us是当前已处理时间单位微秒除以 1e6 得到秒数。speed是编码速度可用来估算剩余时间。progressend出现后进度块就结束了。下面给出一个从 stdout 读取进度时间的解析器public static async IAsyncEnumerabledouble ReadOutTimeAsync( Stream stdout, CancellationToken ct) { using var reader new StreamReader(stdout); while (await reader.ReadLineAsync(ct) is { } line) { var pair line.Split(, 2); if (pair.Length ! 2 || pair[0] ! out_time_us) continue; yield return long.Parse(pair[1]) / 1_000_000.0; // 将微秒转成秒 } }注意ReadLineAsync的 CancellationToken 在进程被取消时会抛异常这是我们设计取消按钮的关键依据。3.2 百分比计算与 IProgress 回传进度百分比必须知道总时长。转换前调用一次 ffprobe 拿format.duration是最省事的做法ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 input.mp4C# 侧拿到总秒数后把ReadOutTimeAsync返回的已处理秒数转成百分比通过IProgressdouble上报public async Task ConvertAsync(ConvertJob job, IProgressdouble progress, CancellationToken ct) { double total await ProbeDurationAsync(job.InputPath); await foreach (var sec in ReadOutTimeAsync(process.StandardOutput.BaseStream, ct)) { progress.Report(total 0 ? Math.Min(99, sec / total * 100) : 0); } }为什么用ProgressT而不是 Dispatcher因为ProgressT在 UI 线程构造时捕获了 SynchronizationContext后台循环只要负责 ReportWPF 会调度回界面线程更新 ProgressBar。这样线程切换集中在 ViewModel 层而不是散落在解析函数里。3.3 取消时不要留下半成品取消转换不能只停掉进度循环还要处理正在写的输出文件。FFmpeg 在收到终止信号时可能已经写入了部分数据硬覆盖原文件会导致用户原有文件损坏。常见做法是输出路径用 .part 后缀转换成功后用 File.Move 替换正式文件string tmpOutput outputPath .part; try { var args BuildArgs(inputPath, tmpOutput); await runner.RunAsync(args, ct); File.Move(tmpOutput, outputPath, overwrite: true); } catch (OperationCanceledException) { File.Delete(tmpOutput); // 取消时清理临时文件 throw; }场景处理方式用户点击取消在取消回调里调用 Process.Kill(entireProcessTree:true)取消时已有输出删除 tmpOutput不触碰原文件转换失败保留 tmpOutput 和日志便于排错RunAsync内部需要在OperationCanceledException发生时调用 Kill因为 FFmpeg 不会主动监听 .NET 的 CancellationToken。整棵进程树都要杀否则后台可能残留 ffmpeg 子进程。4. 音频转换、视频压缩、视频编辑与合并转换的命令设计4.1 音频转换码率、采样率与声道音频转换的诉求一般是把 flac、wav 压成 m4a 或 mp3。参数模板ffmpeg -i input.wav -c:a aac -b:a 192k -ar 48000 -ac 2 output.m4a-c:a aac选择 AAC 编码-b:a 192k设置码率-ar改采样率-ac 2转双声道。转 mp3 时把-c:a aac换成-c:a libmp3lame即可。界面里把“音频格式”“码率”“采样率”做成三个下拉框就能覆盖大多数场景。4.2 视频转换编码器与封装格式视频转码最常用的是 H.264H.265 能把同等画质体积再压小一半但兼容性差一些。这里给 H.264 的模板ffmpeg -i input.mkv -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -pix_fmt yuv420p output.mp4-crf 23是默认平衡点值越小画质越高-preset medium是速度和质量的中庸选项。-pix_fmt yuv420p尤其重要否则 FFmpeg 会保留素材奇怪的色度抽样很多播放器显示成紫绿色。编码器速查表编码器典型 crf优点注意libx26418-28兼容性最好文件比 HEVC 大libx26524-32体积小不适合太老的设备libvpx-vp932-40Web 友好编码很慢4.3 视频压缩CRF、预设、分辨率一起压针对“压体积”的功能单独调 CRF 不够还需要顺手限制分辨率和预设。模板ffmpeg -i input.mp4 -vf scale1280:-2 -c:v libx264 -crf 28 -preset slow -c:a copy output_small.mp4scale1280:-2固定宽度高度自动算成偶数避免 H.264 遇到奇数尺寸报错。-crf 28会让画质比 23 弱一点但体积下降明显-preset slow在同等 CRF 下压出的文件更小代价是耗时。音频用-c:a copy跳过重编码转码速度能快不少。压缩按钮在 UI 里就是把这几个参数接到一个“视频压缩”分组。4.4 视频编辑裁剪、拼接与倍速裁剪常用流复制完成。-ss放在输入前表示快速 seek放在输出前表示精确裁剪ffmpeg -ss 00:01:20 -i input.mp4 -t 30 -c:v libx264 -c:a aac clip.mp4-ss在-i前生效时 seek 快但首帧可能不在关键帧上导致开头有几帧黑场对精确度要求高时把-ss放到-i之后FFmpeg 会解码到目标时间再编码。短视频剪辑选后者更稳。拼接使用 concat demuxerfile part1.mp4 file part2.mp4ffmpeg -f concat -safe 0 -i list.txt -c copy joined.mp4-c copy直接复制流不需要重编码但要求各部分编码参数完全一致。倍速播放则要同时挂视频和音频滤镜ffmpeg -i input.mp4 -filter:v setptsPTS/2 -filter:a atempo2.0 output.mp4注意setpts和atempo是两个独立滤镜倍速数字要对应上。4.5 合并转换统一规格后拼接“合并转换”是两个动作先把不同编码的输入统一成同一个中间规范再 concat。ffmpeg -i a.avi -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 128k tmp_a.mp4 ffmpeg -i b.mov -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 128k tmp_b.mp4 ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4统一编码还不够分辨率、帧率也要统一。可以在第二步的参数里追加-vf scale1920:1080,fps30把两个源强行对齐这样最终 concat 时不会出现画面跳切和音画不同步。用户把多个文件拖进 WPF 列表后程序对每个文件执行一次标准转换再调用 concat这就是一条可落地的合并转换链路。5. WPF 界面的参数映射下拉框、复选框与命令构造器5.1 用 MVVM 让界面只产生参数不决定转码WPF 做这种工具天然适合 MVVM界面上的下拉框、滑块、复选框和进度条都只是 ViewModel 的投影。这里的要点是不要把 ffmpeg 命令写死在按钮事件里。下面用 CommunityToolkit.Mvvm 的属性生成器定义一个转码选项模型public partial class MainViewModel : ObservableObject { [ObservableProperty] private string outputFormat mp4; [ObservableProperty] private int crf 23; [ObservableProperty] private bool useCompression; public string[] FormatList { get; } { mp4, mkv, avi }; }ObservableProperty编译后生成对应的通知属性FormatList只读提供给 ComboBox。CRF 的 Slider 就绑定Crf值变化时自动更新绑定。5.2 常见控件映射表界面层不需要知道 FFmpeg 的全部细节只需要记住每个控件都对应参数生成器里的一个输入。WPF 控件绑定的属性对应 ffmpeg 参数ComboBoxFormatList/OutputFormat文件后缀、封装格式SliderCrf-crfCheckBoxUseCompression是否追加-vf scale和-presetProgressBarProgress来自 IProgress 的百分比CRF 的 Slider 范围可以直接限制为 18-28比起 0-51 对用户友好得多。XAML 里数值范围写在 Maximum/Minimum 上值绑定到 ViewModel。5.3 命令构造器把 ViewModel 变成 FFmpeg 参数数组public Liststring BuildConvertArgs(ConvertOptions options) { var args new Liststring(); args.Add(-i); args.Add(options.InputPath); if (options.UseCompression) { args.Add(-vf); args.Add(scale1280:-2); args.Add(-c:v); args.Add(libx264); args.Add(-crf); args.Add(options.Crf.ToString()); args.Add(-preset); args.Add(slow); } else { args.Add(-c:v); args.Add(copy); // 不重编码视频 } args.Add(-c:a); args.Add(aac); args.Add(-b:a); args.Add(128k); args.Add(options.OutputPath); return args; }BuildConvertArgs只做参数生成不启动进程也不触碰控件。单元测试可以直接传输入输出路径断言生成的参数顺序和值。转码按钮里调FFmpegRunner.RunAsync即可。后续加“保留字幕流”“指定硬件编码”时只需要在这个构造函数里扩展。6. FFmpeg 媒体转换器的分发优化与排错技巧6.1 捆绑 FFmpeg 可执行文件而不是依赖 PATH分发 WPF 工具时最容易遇到“ffmpeg 不是内部或外部命令”。解决办法是把自己携带的 ffmpeg.exe 放在程序目录下启动时用AppContext.BaseDirectory计算路径加载前执行一次-version检查var ffmpegPath Path.Combine(AppContext.BaseDirectory, ffmpeg, ffmpeg.exe); if (!File.Exists(ffmpegPath)) { MessageBox.Show(缺少 ffmpeg 目录请重新解压); return; }这样即使系统 PATH 被清理工具也能正常工作。6.2 转换前自检与转换后验证真正减少用户问题的是转码前先用 ffprobe 读一次输入读不了就别启动转码完成后再用 ffprobe 读一次输出流的编码信息。两条固定命令ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 input.mp4 ffprobe -v error -select_streams v:0 -show_entries streamcodec_name,width,height -of defaultnoprint_wrappers1:nokey1 output.mp4输入自检在按钮启动时执行输出验证在 Runner 退出后执行。两者共用同一个日志文件存放在%LOCALAPPDATA%\YourApp\logs\出问题时让用户把最后几十行发过来。日志按天分文件同时把最后一次成功的out_time_us位置和 stderr 的最后三行写在一起二分定位比让用户截图进度条快得多。本文还有配套的精品资源点击获取 WPF + FFmpeg 媒体转换器开发：异步任务、进度解析与参数构造全指南
简介这是一份基于WPF与C#调用FFmpeg实现的媒体转换器完整项目覆盖音频转换、视频转换、视频压缩、视频编辑与多文件合并等常用功能可满足普通用户日常转码、压缩和简单剪辑需求对开发者而言也能从中学习WPF界面布局与FFmpeg命令行集成的实战写法。压缩包内共256个文件以177个cs源码、6个xaml界面文件为主并包含34个bat功能脚本、15个dll运行库、可执行exe及工程配置文件整体仅18.05MB结构清晰便于按需查看与二次开发。除主程序外脚本还覆盖屏幕录制、RTMP推流、批量截图、摄像头参数探测等实用场景相当于一套可直接调用的FFmpeg操作示例。目前已有78人学习如果你正打算用WPF开发媒体处理工具或希望快速调用FFmpeg完成转码、推流、录屏等任务这套资源会是不错的参考。1. 先把 WPF 媒体转换器讲清楚FFmpeg 负责转码你负责不卡界面媒体转换器这类软件核心不是“把按钮接到 ffmpeg.exe 上”而是把 FFmpeg 的进程生命周期和 WPF 的 UI 生命周期对齐。许多人拿到类似的源码包后第一眼会去翻转码逻辑最后往往卡在同一个地方界面卡死、进度条不走、任务取消后留了一堆坏文件。其实 FFmpeg 的命令行本身很成熟真正的信息量在异步任务设计、进度解析和参数构造。下面这些内容直接用 WPF 做壳把 FFmpeg 当后台工作进程用覆盖音频转换、视频转换、视频压缩、视频编辑、合并转换这几类高频功能。适合 C# 桌面开发者和想从工具源码里摘一套稳定命令的人。2. FFmpeg 接入 WPF 的两种方式与最小 Runner 封装2.1 进程调用优先于库封装Windows 桌面上使用 FFmpeg常见做法是启动 FFmpeg.exe 子进程而不是把整套解码库编译进程序。子进程方式的好处是把人和机器的接口简化成命令行参数换音视频格式、压缩、裁剪、合并全部都是参数的排列组合不涉及 C# 与 C 的内存边界。少数情况会用到 FFmpeg.AutoGen 之类的绑定库比如需要逐帧拿到 AVFrame 做特效但那是媒体处理器的玩法不是媒体转换器的正常选择。下面这个表列出了两种路径的取舍接入方式开发量进度获取适合场景子进程调用 FFmpeg.exe低解析 stdout/stderr 或 progress音频转换、视频压缩、合并内嵌 FFmpeg 库绑定高回调、帧级数据自定义滤镜、帧级编辑对转换器而言选子进程还带来一个额外好处FFmpeg 更新紧跟官方不需要重新编译宿主程序。只要把 exe 版本换掉参数和进度解析逻辑可以原样保留。下面用一个 Runner 类来说明最少骨架。2.2 最小 Runner启动进程、同时读取两个输出流写 Runner 时最容易犯两个错误用字符串拼接命令行以及只重定向 stderr。前者让路径带空格的用户直接失败后者会因为 stdout 缓冲区写满让 FFmpeg 卡死。下面这个版本用 .NET 的 ProcessStartInfo 同时重定向标准输出和标准错误并在等待退出前启动两个读取任务public sealed class FFmpegRunner { private readonly string _ffmpegPath; public FFmpegRunner(string ffmpegPath) _ffmpegPath ffmpegPath; public async Taskint RunAsync(IReadOnlyListstring args, CancellationToken ct default) { var psi new ProcessStartInfo { FileName _ffmpegPath, UseShellExecute false, CreateNoWindow true, RedirectStandardError true, RedirectStandardOutput true, }; psi.ArgumentList.Add(-y); // 覆盖已存在的输出文件 psi.ArgumentList.Add(-hide_banner); // 去掉一屏幕的版本横幅 foreach (var a in args) psi.ArgumentList.Add(a); using var process Process.Start(psi) ?? throw new InvalidOperationException(无法启动 FFmpeg 进程); // 先启动输出读取避免管道缓冲区写满后 FFmpeg 阻塞 var stderrTask process.StandardError.ReadToEndAsync(ct); var stdoutTask process.StandardOutput.ReadToEndAsync(ct); await process.WaitForExitAsync(ct); _lastError await stderrTask; await stdoutTask; return process.ExitCode; } }ArgumentList会正确处理路径里的空格和引号所以输入输出路径直接加入集合即可不要手动拼\\。ReadToEndAsync必须在WaitForExitAsync之前启动否则当视频文件较大时FFmpeg 输出的日志会填满管道缓冲区子进程被堵住。退出码非 0 时_lastError里通常已经有 error 级别的具体原因显示给用户即可。2.3 构造参数而不是拼接字符串FFmpeg 的参数有明确的位置要求输入参数通常放在-i之前输出参数放在输出文件之前。把-ss、-t这类参数直接拼在路径后面很容易让它们被解析成输出选项造成诡异的播放时间错误。更可靠的做法是构造Liststring再用 Runner 的例子逐项加入var args new Liststring { -i, inputPath, -c:v, libx264, -crf, crf.ToString(), -preset, preset, outputPath };常见的参数位置如下表参数位置常见内容说明输入区-ss,-i input控制开始时间、输入文件输出区-c:v,-crf,-b:a,-vf决定编码方式和滤镜全局-y,-progress pipe:1,-loglevel覆盖、进度、日志控制-vf严格说是输出端滤镜要放在输出文件前。-map 0也在输出区用于选择流没有显式写时 FFmpeg 会自动选一条视频和一条音频但会忽略字幕。做工具时默认加-map 0并让用户在界面上勾选要保留的流比放任 FFmpeg 自动选择更容易控制。3. 媒体转换器的异步任务进度、取消与临时文件3.1 用 -progress pipe:1 得到可解析的进度FFmpeg 默认把转码信息写到 stderr格式是 frame、fps 这种给人读的内容换行时间不稳定解析会非常费劲。要拿给 UI 显示正确做法是让 FFmpeg 用-progress pipe:1输出键值对。它把进度分块写到标准输出每块结尾是 progresscontinue 或 progressend。配合-nostats -loglevel error标准错误就只剩真正的错误信息不用再过滤一屏的 bitrate。ffmpeg -progress pipe:1 -nostats -loglevel error -i input.mp4 -c:v libx264 output.mp4输出会是这样out_time_us8320000 out_time_ms8320000 out_time00:00:08.320000 speed3.15x progresscontinueout_time_us是当前已处理时间单位微秒除以 1e6 得到秒数。speed是编码速度可用来估算剩余时间。progressend出现后进度块就结束了。下面给出一个从 stdout 读取进度时间的解析器public static async IAsyncEnumerabledouble ReadOutTimeAsync( Stream stdout, CancellationToken ct) { using var reader new StreamReader(stdout); while (await reader.ReadLineAsync(ct) is { } line) { var pair line.Split(, 2); if (pair.Length ! 2 || pair[0] ! out_time_us) continue; yield return long.Parse(pair[1]) / 1_000_000.0; // 将微秒转成秒 } }注意ReadLineAsync的 CancellationToken 在进程被取消时会抛异常这是我们设计取消按钮的关键依据。3.2 百分比计算与 IProgress 回传进度百分比必须知道总时长。转换前调用一次 ffprobe 拿format.duration是最省事的做法ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 input.mp4C# 侧拿到总秒数后把ReadOutTimeAsync返回的已处理秒数转成百分比通过IProgressdouble上报public async Task ConvertAsync(ConvertJob job, IProgressdouble progress, CancellationToken ct) { double total await ProbeDurationAsync(job.InputPath); await foreach (var sec in ReadOutTimeAsync(process.StandardOutput.BaseStream, ct)) { progress.Report(total 0 ? Math.Min(99, sec / total * 100) : 0); } }为什么用ProgressT而不是 Dispatcher因为ProgressT在 UI 线程构造时捕获了 SynchronizationContext后台循环只要负责 ReportWPF 会调度回界面线程更新 ProgressBar。这样线程切换集中在 ViewModel 层而不是散落在解析函数里。3.3 取消时不要留下半成品取消转换不能只停掉进度循环还要处理正在写的输出文件。FFmpeg 在收到终止信号时可能已经写入了部分数据硬覆盖原文件会导致用户原有文件损坏。常见做法是输出路径用 .part 后缀转换成功后用 File.Move 替换正式文件string tmpOutput outputPath .part; try { var args BuildArgs(inputPath, tmpOutput); await runner.RunAsync(args, ct); File.Move(tmpOutput, outputPath, overwrite: true); } catch (OperationCanceledException) { File.Delete(tmpOutput); // 取消时清理临时文件 throw; }场景处理方式用户点击取消在取消回调里调用 Process.Kill(entireProcessTree:true)取消时已有输出删除 tmpOutput不触碰原文件转换失败保留 tmpOutput 和日志便于排错RunAsync内部需要在OperationCanceledException发生时调用 Kill因为 FFmpeg 不会主动监听 .NET 的 CancellationToken。整棵进程树都要杀否则后台可能残留 ffmpeg 子进程。4. 音频转换、视频压缩、视频编辑与合并转换的命令设计4.1 音频转换码率、采样率与声道音频转换的诉求一般是把 flac、wav 压成 m4a 或 mp3。参数模板ffmpeg -i input.wav -c:a aac -b:a 192k -ar 48000 -ac 2 output.m4a-c:a aac选择 AAC 编码-b:a 192k设置码率-ar改采样率-ac 2转双声道。转 mp3 时把-c:a aac换成-c:a libmp3lame即可。界面里把“音频格式”“码率”“采样率”做成三个下拉框就能覆盖大多数场景。4.2 视频转换编码器与封装格式视频转码最常用的是 H.264H.265 能把同等画质体积再压小一半但兼容性差一些。这里给 H.264 的模板ffmpeg -i input.mkv -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -pix_fmt yuv420p output.mp4-crf 23是默认平衡点值越小画质越高-preset medium是速度和质量的中庸选项。-pix_fmt yuv420p尤其重要否则 FFmpeg 会保留素材奇怪的色度抽样很多播放器显示成紫绿色。编码器速查表编码器典型 crf优点注意libx26418-28兼容性最好文件比 HEVC 大libx26524-32体积小不适合太老的设备libvpx-vp932-40Web 友好编码很慢4.3 视频压缩CRF、预设、分辨率一起压针对“压体积”的功能单独调 CRF 不够还需要顺手限制分辨率和预设。模板ffmpeg -i input.mp4 -vf scale1280:-2 -c:v libx264 -crf 28 -preset slow -c:a copy output_small.mp4scale1280:-2固定宽度高度自动算成偶数避免 H.264 遇到奇数尺寸报错。-crf 28会让画质比 23 弱一点但体积下降明显-preset slow在同等 CRF 下压出的文件更小代价是耗时。音频用-c:a copy跳过重编码转码速度能快不少。压缩按钮在 UI 里就是把这几个参数接到一个“视频压缩”分组。4.4 视频编辑裁剪、拼接与倍速裁剪常用流复制完成。-ss放在输入前表示快速 seek放在输出前表示精确裁剪ffmpeg -ss 00:01:20 -i input.mp4 -t 30 -c:v libx264 -c:a aac clip.mp4-ss在-i前生效时 seek 快但首帧可能不在关键帧上导致开头有几帧黑场对精确度要求高时把-ss放到-i之后FFmpeg 会解码到目标时间再编码。短视频剪辑选后者更稳。拼接使用 concat demuxerfile part1.mp4 file part2.mp4ffmpeg -f concat -safe 0 -i list.txt -c copy joined.mp4-c copy直接复制流不需要重编码但要求各部分编码参数完全一致。倍速播放则要同时挂视频和音频滤镜ffmpeg -i input.mp4 -filter:v setptsPTS/2 -filter:a atempo2.0 output.mp4注意setpts和atempo是两个独立滤镜倍速数字要对应上。4.5 合并转换统一规格后拼接“合并转换”是两个动作先把不同编码的输入统一成同一个中间规范再 concat。ffmpeg -i a.avi -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 128k tmp_a.mp4 ffmpeg -i b.mov -c:v libx264 -pix_fmt yuv420p -c:a aac -b:a 128k tmp_b.mp4 ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mp4统一编码还不够分辨率、帧率也要统一。可以在第二步的参数里追加-vf scale1920:1080,fps30把两个源强行对齐这样最终 concat 时不会出现画面跳切和音画不同步。用户把多个文件拖进 WPF 列表后程序对每个文件执行一次标准转换再调用 concat这就是一条可落地的合并转换链路。5. WPF 界面的参数映射下拉框、复选框与命令构造器5.1 用 MVVM 让界面只产生参数不决定转码WPF 做这种工具天然适合 MVVM界面上的下拉框、滑块、复选框和进度条都只是 ViewModel 的投影。这里的要点是不要把 ffmpeg 命令写死在按钮事件里。下面用 CommunityToolkit.Mvvm 的属性生成器定义一个转码选项模型public partial class MainViewModel : ObservableObject { [ObservableProperty] private string outputFormat mp4; [ObservableProperty] private int crf 23; [ObservableProperty] private bool useCompression; public string[] FormatList { get; } { mp4, mkv, avi }; }ObservableProperty编译后生成对应的通知属性FormatList只读提供给 ComboBox。CRF 的 Slider 就绑定Crf值变化时自动更新绑定。5.2 常见控件映射表界面层不需要知道 FFmpeg 的全部细节只需要记住每个控件都对应参数生成器里的一个输入。WPF 控件绑定的属性对应 ffmpeg 参数ComboBoxFormatList/OutputFormat文件后缀、封装格式SliderCrf-crfCheckBoxUseCompression是否追加-vf scale和-presetProgressBarProgress来自 IProgress 的百分比CRF 的 Slider 范围可以直接限制为 18-28比起 0-51 对用户友好得多。XAML 里数值范围写在 Maximum/Minimum 上值绑定到 ViewModel。5.3 命令构造器把 ViewModel 变成 FFmpeg 参数数组public Liststring BuildConvertArgs(ConvertOptions options) { var args new Liststring(); args.Add(-i); args.Add(options.InputPath); if (options.UseCompression) { args.Add(-vf); args.Add(scale1280:-2); args.Add(-c:v); args.Add(libx264); args.Add(-crf); args.Add(options.Crf.ToString()); args.Add(-preset); args.Add(slow); } else { args.Add(-c:v); args.Add(copy); // 不重编码视频 } args.Add(-c:a); args.Add(aac); args.Add(-b:a); args.Add(128k); args.Add(options.OutputPath); return args; }BuildConvertArgs只做参数生成不启动进程也不触碰控件。单元测试可以直接传输入输出路径断言生成的参数顺序和值。转码按钮里调FFmpegRunner.RunAsync即可。后续加“保留字幕流”“指定硬件编码”时只需要在这个构造函数里扩展。6. FFmpeg 媒体转换器的分发优化与排错技巧6.1 捆绑 FFmpeg 可执行文件而不是依赖 PATH分发 WPF 工具时最容易遇到“ffmpeg 不是内部或外部命令”。解决办法是把自己携带的 ffmpeg.exe 放在程序目录下启动时用AppContext.BaseDirectory计算路径加载前执行一次-version检查var ffmpegPath Path.Combine(AppContext.BaseDirectory, ffmpeg, ffmpeg.exe); if (!File.Exists(ffmpegPath)) { MessageBox.Show(缺少 ffmpeg 目录请重新解压); return; }这样即使系统 PATH 被清理工具也能正常工作。6.2 转换前自检与转换后验证真正减少用户问题的是转码前先用 ffprobe 读一次输入读不了就别启动转码完成后再用 ffprobe 读一次输出流的编码信息。两条固定命令ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 input.mp4 ffprobe -v error -select_streams v:0 -show_entries streamcodec_name,width,height -of defaultnoprint_wrappers1:nokey1 output.mp4输入自检在按钮启动时执行输出验证在 Runner 退出后执行。两者共用同一个日志文件存放在%LOCALAPPDATA%\YourApp\logs\出问题时让用户把最后几十行发过来。日志按天分文件同时把最后一次成功的out_time_us位置和 stderr 的最后三行写在一起二分定位比让用户截图进度条快得多。本文还有配套的精品资源点击获取