AI funscript 生成的原理
AutoScript Sync 用完全在你电脑上运行的 AI 视频动作追踪从视频中读取动作：它对帧进行采样，用光流测量运动，加入可选的姿态和深度模型，把这些信号融合成一条位置轨迹，并在每次方向变化处放置一个脚本点。结果是一个保存在视频旁边的标准 .funscript。针对特定设备的适配发生在之后，而且只作用于发送给该设备的副本。
已于 2026 年 9 月 21 日对照应用代码核实。除非某行另有说明，描述的都是已发布的应用 2.121.1。
处理流程：从视频文件到设备
每个阶段一段说明
解码与采样
视频通过 OpenCV 的 FFmpeg 后端解码。应用会先请求硬件解码，如果编解码器、构建版本或驱动不支持，就退回软件解码。一个工作线程会提前解码到最多 64 帧的缓冲区，让解码和 AI 推理同时进行，而不是轮流进行。
Accuracy 设置决定分析多少帧：Fast 每 4 帧取 1 帧，Balanced（默认）每 3 帧取 1 帧，High 每 2 帧取 1 帧。对于 30 fps 的视频，就是每秒 7.5、10 或 15 次采样；对于 60 fps 的视频，频率翻倍。无论源分辨率多少，每个采样帧在分析前都会缩小到 320 px 宽。VR 画面会先还原为单眼的普通透视视图。
找到运动区域
除非你自己用 Set Motion Region… 或 Live Track 画出一个框，否则引擎会构建一张运动热力图，取其中最热的连通区域，并向外扩展 15%。光流和深度都在该区域内测量。
测量运动
光流是唯一始终运行的信号：DIS 稠密光流测量该区域在各采样帧之间的移动。YOLOv8 姿态估计为每个人加入 17 个身体关键点，MiDaS 深度估计则补上平面视频所隐藏的朝向/远离镜头的轴。这两个模型都是可选的；没有它们时，引擎只靠光流运行，并会明确告知。应用还会在后台线程中读取编解码器自身的运动矢量和 50 Hz 的音频响度包络，所用时间预算随影片长度而定。
融合
光流给出的是速度，随时间累加会产生漂移。因此引擎会根据区域中心、姿态和深度为每个视频选出一个锚点，再由 Kalman/RTS 平滑器把积分后的光流与该锚点融合成一条位置轨迹。默认情况下，锚点是所有可读通道的逐样本混合，只有当它的得分不低于单一选中锚点时才会采用。追踪中断的地方，会用延续周围行程的节律性动作补齐，补填而非实测的比例会写入脚本的元数据。
动作类型窗口
时间轴被切分为 2 秒的窗口。一个小型分类器根据六项运动特征为每个窗口标注动作类型，平滑处理则防止标签在相邻窗口之间来回跳变。标签决定该窗口动作的塑形方式。你自己设置的标签只要覆盖窗口的至少一半，就会在该窗口上优先于分类器。
脚本点与保存的文件
脚本点放在每次运动反转处，与前一个点的间隔不少于 120 ms，并且至少每 4 秒一个，随后点列表会被简化。应用会先把已有脚本复制为 .funscript.bak，再在视频旁写出同名的标准 .funscript JSON。文件内容见 funscript 格式。
设备适配
适配只作用于发送给设备的副本，从不作用于保存的文件：间隔小于设备分辨能力的点会被合并，超过设备速度上限的片段会缩小幅度但保留时间点，点密度也有上限。对于 Autoblow AI Ultra，反转点还会对齐到 16 fps 的网格。在已发布的应用中，这种适配只用于 Autoblow 上传；对 Intiface 设备同样适配将在下一次更新中推出。设备之后如何与视频保持同步，见漂移校正与同步时序。
各部分在哪里运行
所有分析都在你的电脑上进行。分析模块不含任何网络代码，视频从不会被上传。Hardware 设置提供 Auto（默认）、GPU (CUDA) 和 CPU 三个选项。
| 阶段 | 运行于 |
|---|---|
| 视频解码 | 有可用的硬件解码器时使用（任何厂商均可），否则使用 CPU |
| 姿态与深度模型 | 通过 CUDA 在 NVIDIA GPU 上运行（ONNX Runtime 或 PyTorch）；无法使用 CUDA GPU 时在 CPU 上运行 |
| 光流 | CPU（OpenCV），在所有机器上都是如此 |
AI 模型没有 AMD 或 Intel 加速，也不使用 TensorRT。如果要求使用 CUDA GPU 但无法使用，姿态和深度会退回到 CPU，应用会报告实际使用的执行提供程序；Check GPU 按钮会告诉你是哪一个。CPU 路径可以工作但慢得多：RTX 5080 测试电脑上的一条代码注释记录，小型深度模型每次调用在 GPU 上约 25.8 ms，在 CPU 上则为 234 ms。
除开发者自己的 GPU 外，我们没有在任何其他 GPU 或纯 CPU 电脑上测量过整部影片的处理速度，因此本页不做任何速度承诺。基准测试页面列出了测量过什么、在什么设备上测量，以及哪些尚未测量。
我们尚未解决的问题
以下结果来自开发者自己的评分：对照他亲手编写脚本的 28 个短片段，这些片段取自默认参数所依据调校的五部影片，使用的是 2.121.1 之后的构建版本（已构建，尚未发布）。这只是一位脚本作者和一个小样本，请把它们看作已知弱点，而不是基准测试。
- 漏掉方向变化。人工每秒有 2.29 次方向变化，引擎只有 1.80 次，少了约 21%。由于引擎的部分转向还是多余的或时机不对，人工的转向中只有大约一半能在 150 ms 内被匹配上。按影片计，行程转向的一致性为 0.33 到 0.71（F1，150 ms 以内）。
- 快速行程偏小。在行程最快的两部影片上，引擎的行程幅度分别只有人工的四分之一和一半。目前的解释是，Balanced 每秒 10 次的采样（30 fps 视频）把快速运动平滑掉了。
- 动作停止时它不会停。在人工标记为无动作的区间里，引擎每分钟仍会产生约 85 次方向变化。不过，当有真实运动的样本不到 5% 时，它确实会拒绝生成脚本。
- 动作类型标签尚未得到验证。在按视频留出、使用开发者自己标签的测试中，动作分类器单独使用时的得分低于常数猜测，默认应用也没有可以公布的准确率数据。你自己设置的标签会覆盖它。
目前实用的应对办法是：时间轴编辑器、对选中区间以完整帧率执行 Re-analyze，以及 funscript 故障排除。
延伸阅读
- 光流：读取帧与帧之间的运动每个脚本所依赖的信号，以及如何防止它漂移。
- 基于 YOLOv8 的姿态估计每个 Accuracy 档位使用哪个模型，以及关键点带来了什么。
- 基于 MiDaS 的深度估计朝向镜头的轴，以及每个视频统一的深度尺度。
- 设备如何保持同步Autoblow、Intiface 设备和 DeoVR 的同步规则。
- 基准测试与测量测量过什么、在哪台机器上测量，以及哪些尚未测量。
- AI funscript 生成器每个 AI 部分的作用，以及它如何从你的编辑中学习。