可用ffprobe+cropdetect轻量检测黑边：先用ffprobe获取分辨率，再用ffmpeg -vf "cropdetect=limit=16:round=2"分析首尾帧，输出crop参数；敏感度由limit控制，需结合设备实测调优。
用 ffprobe 快速判断黑边是否存在（不编码）
直接靠 FFmpeg 解码逐帧分析太重，多数场景只需粗略检测首尾几帧的上下/左右边缘是否全黑。用 ffprobe 提取关键帧 + ffmpeg 的 cropdetect 滤镜更轻量：
-
ffprobe -v quiet -show_entries stream=width,height -of csv=p=0 input.mp4先拿到原始分辨率 - 再跑：
ffmpeg -i input.mp4 -vf "cropdetect=limit=24/255:round=2" -f null - 2>&1 | grep "crop="—— 这会输出类似crop=1280:704:0:48，表示检测到可裁剪区域 -
limit值越小越敏感（默认 24，对浅灰边可能漏检；设成16或8更稳妥），round=2表示宽高必须是 2 的倍数（适配 H.264 编码要求） - 注意：如果视频有字幕或固定台标，
cropdetect可能误判——得加skip=10跳过开头广告帧，或限定只分析中间帧：-ss 00:00:10 -t 5
在 C++ 中调用 avfilter 实现逐帧黑边判定
真正需要自定义逻辑（比如只裁顶部黑边、忽略底部噪点）时，得进 FFmpeg API 层。核心不是“检测”，而是“怎么定义黑”：按 YUV 的 Y 分量均值
- 用
av_frame_get_buffer()分配帧内存后，遍历frame->data[0]（Y 平面）的边缘行/列像素 - 别直接比像素值，先算局部均值：例如顶部 16 行每行取中间 1/3 区域，均值
- 裁剪参数要动态累积：记录连续 N 帧都满足黑边条件才确认（避免单帧抖动误触发），推荐 N=3～5
- 注意色彩空间：若输入是
AV_PIX_FMT_YUV420P，U/V 平面尺寸是 Y 的一半，但黑边检测只看 Y 平面就够了
用 libswscale 配合 crop 滤镜做无损裁剪
检测完只是开始，裁剪本身不能靠重采样硬缩放——那叫“拉伸”，不是“裁剪”。必须用 scale 滤镜前接 crop，且确保输出分辨率是硬件友好尺寸（如宽高均为 2 的倍数）。
- 滤镜图初始化时传入：
"crop=w:h:x:y,scale=trunc(iw/2)*2:trunc(ih/2)*2"—— 后半段强制对齐，避免某些解码器报错 - 若原始视频是 1920×1080，检测出
crop=1920:1040:0:20，实际裁剪应为crop=1920:1040:0:20,scale=1920:1040，而不是scale=1920:1040:flags=lanczos（插值会模糊） - C++ 中构建滤镜图用
avfilter_graph_parse_ptr()，注意inputs和outputs的命名必须匹配（如"in"/"out"），否则avfilter_graph_config()直接失败
常见错误：裁剪后画面撕裂或绿边
这基本不是算法问题，而是 FFmpeg 数据流同步没处理好。尤其多线程解码时，AVFrame 的 pts 和滤镜输入时间戳不一致会导致帧错位。
- 务必在送入滤镜前调用
av_frame_make_writable(frame)，否则crop滤镜修改原帧内存会污染后续帧 - 不要复用同一
AVFrame多次调用av_buffersrc_add_frame()，每次都要av_frame_clone()或重新分配 - 如果输出 MP4，
AVCodecContext的time_base必须和滤镜图输出的time_base一致，否则 muxer 会丢帧或重复帧 - 最隐蔽的坑：某些摄像头视频的 SAR（Sample Aspect Ratio）非 1:1，单纯裁剪会导致画面压扁——得同步更新
AVStream->sample_aspect_ratio
黑边检测的难点从来不在“找到黑”，而在于“定义什么是可接受的黑”。压缩失真、伽马校正、不同设备的亮度渲染差异，都会让阈值变得脆弱。建议先用 ffplay -vf "cropdetect=limit=16" 在目标设备上手动验证阈值，再固化到代码里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
