应基于光流场统计特征判断抖动剧烈程度：中心区域光流向量的标准差＞3.0像素或模长＞5.0像素的向量占比＞15%即判定为剧烈抖动，因全局均值易掩盖局部异常而标准差更敏感。
OpenCV 中用 calcOpticalFlowFarneback 提取光流后怎么判断抖动剧烈程度
光流本身不直接给出“抖动”，它输出的是每帧每个像素的位移向量场。真正要检测剧烈抖动，得对这些向量做统计建模——不是看单个点偏移多大，而是看全局运动是否一致、是否有大量异常离群位移。
实操建议：
- 只在图像中心区域（比如 60% 宽高）采样光流向量，避开边缘畸变和无关背景干扰
- 对所有有效向量计算
mean和stddev：若stddev > 3.0（单位：像素），说明运动方向/幅度严重发散，大概率是抖动而非平滑运镜 - 额外统计位移模长 >
5.0的向量占比，超过 15% 就算剧烈抖动帧 - 别直接用全图均值——镜头轻微平移时均值可能接近 0，但标准差会明显抬升
为什么不用 estimateAffine2D 或 findHomography 做帧间配准来测抖动
这两个函数适合刚性或透视变换建模，但真实抖动常含局部形变（如手持时镜头微旋转+呼吸效应），强行拟合仿射会把高频抖动“抹平”成低频漂移，导致漏判。
更关键的是：它们返回单个变换矩阵，丢失了像素级运动细节。一旦某帧存在局部快速晃动（比如手突然一抖），全局矩阵可能仍很稳定，抖动就被掩盖了。
实操建议：
-
estimateAffine2D可用于后续防抖的粗配准，但不能用于抖动检测本身 - 如果非要用，务必开启
ransacReprojThreshold=2.0并检查内点数量；内点数 - 避免在低纹理场景（如纯色墙壁）调用，
findHomography会返回病态矩阵，cv::SVD分解时报matrix is singular
C++ 防抖逻辑里如何设计运动缓冲与平滑延迟
数字防抖本质是“用空间换时间”：靠历史帧运动趋势预测当前帧该补偿多少。缓冲太小响应快但噪声大；太大则拖影严重，尤其转头场景会明显滞后。
实操建议：
- 用双端队列
std::deque<:point2f></:point2f>存最近 15 帧的全局运动向量（从光流均值得到） - 平滑不用简单移动平均，改用带权重的中位数滤波：
nth_element取中间 5 个值再求均值，抗脉冲噪声更强 - 设置硬阈值：若当前帧运动向量模长 > 缓冲区中位数的 2.5 倍，视为突变抖动，只补偿中位数的 40%，避免过补偿
- 别在实时渲染线程里做复杂滤波——把运动估计和帧补偿拆到不同线程，否则
cv::remap会卡住视频流
防抖后画面裁剪与黑边处理的实际取舍
所有基于运动补偿的防抖都会导致画面边缘露黑，这是几何必然。所谓“无损防抖”只是把黑边用插值或扩展填充，但会引入模糊或伪影。
实操建议：
- 预计算最大可能位移半径
R = 1.8 * max(stddev_x, stddev_y)，初始化时就按此缩放原始帧（用cv::resize+INTER_AREA） - 填充黑边优先用
cv::copyMakeBorder的BORDER_REFLECT_101模式，比BORDER_CONSTANT更自然 - 如果输入是 1080p，输出坚持 1080p，宁可裁掉 8% 边缘也不放大填充——放大操作在
cv::warpAffine后做，会叠加插值误差 - 注意 OpenCV 的
cv::warpAffine默认使用INTER_LINEAR，在快速抖动下易出锯齿；高频场景建议切到INTER_CUBIC，但耗时增 35%
真正的难点不在算法，而在于抖动判定阈值必须随场景自适应：暗光下光流噪声大，白天强纹理下又容易把主体运动误判为抖动。静态背景检测、亮度直方图变化率、甚至音频能量（如果有同步音频）都得参与加权，单纯靠光流不够鲁棒。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
