视频防抖到底在抖什么？OIS、EIS、混合防抖一文搞清楚

前言

近日有新加入的开发者在问 ZEGO 的实时音视频 SDK 有没有视频防抖功能。答案是肯定的，我们早已经在 SDK 内置了视频防抖功能，在进行视频内部采集时，可设置相机的稳定模式，降低拍摄抖动造成的影响，提高视频采集质量。相关 API 请参考setCameraStabilizationMode。

借此机会，本文从”抖动的本质”出发，介绍什么是视频防抖、常见的三种防抖方案（OIS、EIS和混合防抖）的原理、适用场景与取舍。

视频防抖基础

视频防抖是一项关键技术，它通过消除或减少因相机抖动造成的图像不稳定来提升视频质量，从而改善观看体验。该技术已深度应用于多种场景，包括手持录制、无人机航拍、车载监控等。

视频为什么会抖？

拍视频时的抖动，本质上是相机（或手机）在拍摄过程中发生了非预期的位移和旋转。

抖动来源主要有三类：

• 手持抖动（最常见）：低频抖动，如走路、跑步引起的大幅晃动（0.5~3 Hz）；高频抖动，如手部肌肉颤抖（5~15 Hz）。
• 设备振动：骑车、车载、无人机螺旋桨振动（高频，20Hz+）。
• 场景运动：主动跟拍、摇镜头（这是”有意为之”，不该被消除）。

关键认知：防抖的目标是消除非预期抖动，而不是消除所有运动。这个边界判断，正是各种防抖方案最难的地方。

视频防抖算法

视频防抖算法有电子防抖、光学防抖、陀螺仪电子防抖、光学+电子混合防抖、微云台防抖、传感器防抖等。这些技术通过硬件或软件的方式，减少视频在拍摄或传输过程中的抖动，提高视频的稳定性和清晰度。

下面我们就来详细介绍三类最常见的算法：光学防抖(OIS)、电子防抖(EIS)、光学+电子混合防抖。

OIS：让镜头自己动起来

OIS（Optical Image Stabilization，光学防抖） 是硬件层面的解决方案。

原理

在镜头模组内置陀螺仪 + 音圈马达（VCM）：

陀螺仪检测到抖动
    ↓
计算需要补偿的位移量
    ↓
驱动音圈马达，让镜片组反向移动
    ↓
光路在传感器上保持稳定

用一句话描述：抖动发生之前，镜头已经在反向运动了。

优点

• 在光线不足时效果显著（可以用更慢的快门速度而不模糊）。
• 延迟极低，几乎是实时补偿。
• 不裁切画面，不损失视野。

缺点

• 补偿范围有限（通常 ±2°），大幅晃动无能为力。
• 依赖硬件，软件层无法干预。
• 成本高，低端机没有。

OIS 对你来说是透明的。你调用 Camera2 / AVFoundation 时，OIS 已经在硬件层工作了。你能做的只是查询设备是否支持，然后信任它。

EIS：用算法”裁”出稳定画面

EIS（Electronic Image Stabilization，电子防抖） 是纯软件方案，也是开发者最能介入的层。

原理

采集原始帧（比目标分辨率更大，留出裁切余量）
    ↓
分析相邻帧之间的运动向量（陀螺仪数据 or 图像特征点）
    ↓
计算"稳定后的虚拟相机路径"（平滑滤波）
    ↓
对每一帧做裁切 + 仿射变换，输出稳定帧

一句话描述就是把抖动的画面”裁”成稳定的画面，代价是损失一圈边缘视野。

优点

• 纯软件，任何设备都能跑
• 可以在后处理阶段介入（推流前、服务端都行）
• 补偿范围比 OIS 大

缺点

• 必然裁切画面（通常损失 10%~25% 视野）
• 引入帧延迟（需要缓冲若干帧才能平滑）
• 快速运动场景容易出现果冻效应（Jello Effect）

从开发者的角度来说，EIS 是你最能发挥的地方。Android 的 VideoStabilizationMode、iOS 的 videoStabilizationMode、FFmpeg 的 vidstab 滤镜，本质上都是 EIS。你需要关心的核心参数有：

• 裁切比例（影响视野）
• 平滑窗口大小（影响延迟 vs 稳定性）
• 降级策略（低端机怎么办）

混合防抖：1+1 > 2

现代旗舰手机（iPhone、Pixel、三星 S 系列）普遍采用 OIS + EIS 混合方案。

分工逻辑

• OIS 负责：高频小幅抖动（手部颤抖）→ 硬件实时补偿
• EIS 负责：低频大幅晃动（走路步伐）→ 软件平滑处理

两者互补，覆盖完整的抖动频谱。

Apple 的 Cinematic Stabilization

苹果在 iPhone 12 Pro 之后引入的”电影级防抖”，本质是激进的 EIS：

• 裁切比例更大（约 20%）
• 平滑算法更激进
• 专门针对步行场景优化

代价是视野损失明显，所以苹果把它做成了可选项，而不是默认开启。

Google 的 Cinematic Pan

Pixel 系列的特色，能识别”有意的摇镜头”并保留，只消除无意抖动。这正是前面说的”边界判断”难题，Google 用机器学习解决了它。

RTC 场景的特殊挑战

如果你在做实时音视频 RTC，防抖面临的约束和离线视频完全不同：

这意味着离线防抖的最优解，在 RTC 场景里可能不可用。

平滑窗口越大，稳定效果越好，但延迟越高，这是 RTC 防抖绕不开的核心矛盾。

选择用哪种视频防抖方案，最终还是根据场景来决定，比如：

• 离线视频处理：用 FFmpeg vidstab，效果好，不用考虑延迟。

• 实时场景（RTC/直播）
  • 目标设备有 OIS：优先依赖 OIS，EIS 作为补充。
  • 需要支持低端机：纯软件 EIS，注意降级策略。
  • 延迟要求 < 100ms：陀螺仪辅助 EIS，禁用大窗口平滑。

总结

一张图和一张表看懂 OIS、EIS 和混合防抖：