关键帧提取必须用FFmpeg命令行而非C#自行解析，因视频压缩帧间强依赖且无成熟纯托管解码器；正确做法是用select滤镜提取I帧，通过ffprobe获取时长与关键帧时间戳后精确截取，并注意跨平台参数适配与错误处理。
关键帧提取必须用 FFmpeg，C# 自己解析视频几乎不可行
因为视频是压缩编码的，帧之间有强依赖（比如 P 帧、B 帧依赖 I 帧），C# 没有成熟、轻量、跨平台的纯托管解码器能准确识别并随机定位到关键帧。你看到的“C# 提取关键帧”方案，底层 99% 都是在调用 ffmpeg 进程——不是调用 DLL，而是启动命令行进程并解析输出。
常见错误现象：MediaFoundation 或 FFmpeg.AutoGen 直接 seek 到时间点却返回模糊/错位帧；VideoFileReader（AForge）抽帧结果和播放器看到的关键帧不一致；自己写 AVI 解析器卡在 MJPEG 外壳里根本进不去 H.264 流。
- 真正有效的做法：用
ffmpeg -i input.mp4 -vf "select='eq(pict_type,I)'" -vsync vfr keyframe_%04d.jpg提取所有 I 帧 - 注意
select表达式里的反斜杠要转义（C# 字符串中写成"select='eq(pict_type\,I)'"） - 不要用
-frames:v 1加-ss组合来“跳到某秒取关键帧”——-ss在输入侧快进时，若没对齐 GOP 起始，会强制解码到最近关键帧再丢弃前面帧，但你无法控制它选哪个 I 帧
从 C# 启动 ffmpeg 进程的三个硬性要求
不是简单调 Process.Start 就完事。Windows 上路径含空格、Linux/macOS 权限、编码参数中的单引号和等号，都会让命令静默失败。
- 必须显式设置
ProcessStartInfo.UseShellExecute = false，否则重定向 stdout/stderr 会失败 -
ProcessStartInfo.RedirectStandardError = true必须开，ffmpeg的关键错误（如 no such file、codec not found）全走 stderr，stdout 可能空着就结束了 - Windows 下如果
ffmpeg.exe不在 PATH，路径含中文或空格时，FileName必须是绝对路径，且不能加引号（系统自动处理）；传参用Arguments字段单独填，别拼进 FileName
提取指定时间点附近的关键帧，别信“-ss + -vframes”
想取第 123 秒那一帧？直接 -ss 123 -vframes 1 极大概率拿到的是 122.8 或 123.7 秒的帧，而且不保证是 I 帧——因为 -ss 在解码前快进，精度取决于 GOP 长度（通常 0.5–2 秒）。
正确做法分两步：
- 先用
ffprobe -v quiet -show_entries format=duration -of default=nw=1 input.mp4获取总时长（避免用户传个损坏文件） - 再用
ffmpeg -i input.mp4 -vf "select='gt(scene,0.4)+eq(pict_type,I)'" -vsync vfr -frame_pts true -f null -扫描所有关键帧和场景切换帧的时间戳（输出在 stderr），解析出最接近目标时间的pkt_pts_time - 最后用精确时间戳（比如
122.943）配合-ss和-vframes 1截取——这时-ss放在输出参数前（即解码后快进），精度可达毫秒级
输出 JPG 质量与性能的隐性权衡
默认 ffmpeg 输出 JPG 是高质量（约 Q95），但如果你批量处理上千个视频，磁盘 IO 和编码耗时会陡增。而设太低（如 -q:v 30）会导致关键帧特征丢失，后续做图像比对或 OCR 时失败。
-
-q:v 2～5是视觉无损区间，文件体积比默认小 40%+，人眼看不出区别，推荐作为生产默认值 - 避免用
-compression_level（PNG 专用），对 JPG 无效，还可能触发警告 - 如果只要像素数据不要文件，改用
-f image2pipe -pix_fmt rgb24输出原始字节流，由 C# 直接读StandardOutput.BaseStream，省去磁盘写入——但要注意帧头缺失，需按width * height * 3手动切片
真正麻烦的从来不是调用命令，而是 ffmpeg 参数组合在不同版本间的行为漂移——比如 4.4 和 6.0 对 select 表达式里空格和括号的容忍度不同，还有 Windows 控制台默认代码页导致的中文路径乱码。上线前务必用目标环境的真实 ffmpeg 二进制跑通全流程。
