Wiki Notes

Appearance

视频模型专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：正在做视频理解、长视频摘要、教学视频解析、广告视频生成、短片工作流、素材剪辑和视频内容运营的产品、研发与平台工程同学

视频模型和图像模型看起来很像，但工程上绝不是“多几张图”那么简单。

视频系统一旦进入真实业务，马上就会面对：

  • 时间连续性
  • 镜头切换
  • 音视频多通道融合
  • 长上下文成本
  • 异步渲染与队列
  • 更长的人审与交付流程

根据 2026-07-09 复核可访问的 OpenAI Video generation with Sora、Sora 2 Prompting Guide、Data controls in the OpenAI platform，以及 Google Gemini Video understanding 官方资料，可以先抓住一个核心判断：

  • 视频任务真正的难点不是“模型会不会看视频”，而是怎样把时间轴、镜头语言、音频文本、生成链路、下载留存和成本约束统一成一条生产流程。

1. 视频任务至少有三种完全不同的形态 ​

1.1 视频理解 ​

典型任务：

  • 视频摘要
  • 事件识别
  • 教学视频解析
  • 监控片段理解
  • 长视频问答

1.2 视频生成 ​

典型任务：

  • 文生视频
  • 图生视频
  • 品牌创意短片
  • 动画镜头草图

1.3 视频编辑与延展 ​

典型任务：

  • 给已有片段做局部风格调整
  • 延长既有镜头
  • 连续片段拼接
  • 版本化迭代修改

这三类任务的架构、成本和评测方式完全不同。

2. 视频理解最核心的是时间轴，不是单帧 ​

图像任务很多时候只解决：

  • 这一帧里有什么

视频任务则必须处理：

  • 前后帧是不是一个连续事件
  • 同一主体是否保持稳定
  • 关键事件发生在什么时间点
  • 画面和语音是否互相支持

这也是为什么视频理解里，最常见的失败不是“完全没看懂”，而是：

  • 顺序判断错
  • 镜头跳转后丢上下文
  • 只抓住局部画面，没抓住整段过程

2.1 时间轴决定了很多产品能力 ​

例如：

  • 章节摘要
  • 精准问答
  • 关键片段定位
  • 事件回放

如果没有时间轴意识，后面很难做：

  • 带证据的视频问答
  • 带跳转点的视频摘要

2.2 更稳的输出通常应该带时间锚点 ​

Google Gemini 当前视频理解文档明确支持用 MM:SS 的时间格式向具体时间点提问，也支持让模型输出带时间点的关键事件描述。

这对产品设计的启发很直接：

  • 视频摘要最好不是一整段自然语言
  • 而是 结论 + 时间点 / 时间段 + 证据说明

3. 真实视频理解系统往往先拆再看 ​

很多视频系统并不是把整段视频直接丢进模型，而是先做拆解。

常见链路：

text
Video
 -> shot split / sampling
 -> OCR / audio transcription / frame understanding
 -> timeline aggregation
 -> retrieval / prompt assembly
 -> summary / QA / classification

3.1 常见拆法 ​

  • 固定间隔抽帧
  • 按镜头切割
  • 按字幕时间轴切片
  • 按语音停顿切段
  • 按章节或页面切段

3.2 为什么要先拆 ​

因为不拆通常会带来：

  • token 成本过高
  • 时间定位不清
  • 模型被冗余片段淹没
  • 长视频 QA 难以追溯证据

3.3 拆得太细也会有反作用 ​

如果切得过细，常见问题包括：

  • 语义被切断
  • 关键上下文丢失
  • 聚合难度上升

所以真正的工程难点不只是“拆不拆”，而是：

  • 怎么拆得既省成本又保语义

3.4 Gemini 给出的一个很现实的约束 ​

Google Gemini 当前视频理解文档说明：

  • File API 适合大文件、长视频和可复用文件
  • 小于 100MB 的短视频更适合 inline data
  • 大文件和长视频更建议走 File API

也就是说，视频理解从输入方式开始就已经分出两条路：

  • 一次性小视频，偏同步请求
  • 可复用长视频，偏上传后复用

这不是“SDK 写法不同”，而是：

  • 请求大小
  • 处理时长
  • 复用频率
  • 成本与排障方式

都不同。

4. 抽帧策略不是实现细节，而是效果上限 ​

Google Gemini 当前官方文档明确写到：

  • 默认按 1 FPS 采样视频帧
  • File API 处理音频时按 1Kbps 单声道处理
  • 每秒会自动补时间戳

这几个事实特别重要，因为它们直接决定了视频理解的默认盲区。

4.1 为什么 1 FPS 会改变你的产品设计 ​

1 FPS 对大多数内容已经够用，但它很可能漏掉：

  • 快速动作
  • 瞬时转场
  • 很短暂的屏幕提示
  • 高速切镜头

所以如果你的任务高度依赖这些信号，就不能把“默认整段送进模型”当成唯一方案。

4.2 更稳的补救方式通常是这些 ​

  • 先做 shot split，再按镜头采样
  • 对关键区段单独提高抽样密度
  • 对快动作片段额外做短 clip 二次分析
  • 把 OCR 和转写结果一起并回时间轴

4.3 长视频不是不能看，而是要先预算 ​

Gemini 当前文档说明：

  • 1M context 的模型在默认媒体分辨率下可处理大约 1 小时视频
  • 在低媒体分辨率下可处理大约 3 小时视频

这意味着长视频系统最该先做的不是“盲目堆上下文”，而是：

  • 先按业务目标决定哪些段落真的值得进入高分辨率理解

5. 视频理解几乎都应该结合音频和 OCR ​

Google Gemini 当前 Video understanding 文档明确强调：

  • 视频理解要同时处理音频和视觉流

绝大多数真实视频任务都不应该只看画面。

原因很简单：

  • 画面给场景
  • 语音给语义
  • 字幕和屏幕文字给关键名词与结构

例如教学视频、产品演示、会议录屏、广告复盘这类任务，如果只靠视觉帧，往往会遗漏：

  • 讲解逻辑
  • 品牌话术
  • 数字参数
  • 页面文字

所以更稳的系统通常是：

  • 视觉理解
  • 音频转写
  • OCR
  • 时间轴聚合

一起工作。

5.1 一个更像生产系统的证据对象 ​

如果要把视频理解结果给下游问答、审核或回放系统用，更建议保留一类结构化证据：

  • clip_id
  • start_ts
  • end_ts
  • shot_id
  • transcript_excerpt
  • ocr_excerpt
  • visual_summary
  • confidence_hint

这样做的好处是：

  • 摘要可回放
  • QA 可追证
  • 审核可复查
  • 错误可定位到具体时间段

6. 视频生成要先把“镜头语言”和“参数边界”分开 ​

OpenAI 当前 Sora 2 Prompting Guide 很清楚地把两件事拆开了：

  • prompt 负责主体、动作、光线、风格、镜头语言
  • API 参数负责 model、size、seconds、characters

这对工程很关键，因为很多人会把它们混成一句自然语言需求。

6.1 哪些东西应该写进 prompt ​

更好的视频 prompt 不是更长，而是更像 storyboard brief。

更值得优先明确的是：

  • 镜头远近和角度
  • 主体是谁
  • 动作按什么节奏发生
  • 光线和色彩锚点是什么
  • 环境和风格是什么

OpenAI 的 prompting guide 还特别强调：

  • 每个 shot 最好只有一个清晰的 camera move
  • 每个主体动作最好也只有一条清晰主线

这背后的工程启发是：

  • prompt 不要同时要求太多镜头意图

6.2 哪些东西应该明确放到 API 参数 ​

OpenAI 当前文档里，下面这些不该只写在 prose 里：

  • model
  • size
  • seconds
  • characters

这意味着企业视频工作台里更稳的交互通常不是一个大文本框，而是：

  • 参数面板 + 镜头描述 + 资产选择

6.3 短片段通常更稳 ​

OpenAI 的 prompting guide 明确提到：

  • 模型一般在更短的片段里更容易遵循指令
  • 如果允许后期拼接，两个 4 秒片段很多时候会比一次生成一个 8 秒片段更稳

所以企业里更可控的路线通常是：

  • 先做短镜头
  • 再做 stitch / extend / edit

7. input_reference、characters、extensions、edits 解决的不是同一个问题 ​

这部分是很多视频产品最容易混的地方。

7.1 input_reference 更像“给新镜头一个起始画面” ​

OpenAI 当前视频文档明确说明：

  • input_reference 用来指导生成的开场画面
  • 图片分辨率要和目标视频分辨率一致
  • 支持 jpeg/png/webp

它更适合：

  • 品牌 KV 起始帧
  • 海报图转动态
  • 已有场景参考

7.2 characters 更像“可复用的非人角色资产” ​

OpenAI 当前官方文档说明：

  • characters 用短 MP4 创建可复用角色
  • 适合动物、吉祥物、物件等非人主体
  • human likeness 默认受限

它和 input_reference 的关键区别在于：

  • input_reference 更像单次生成的开场条件
  • characters 更像跨多个镜头复用的角色资产

而且官方文档还特别提醒：

  • prompt 里仍然要明确写出角色名称

7.3 extensions 更像“沿着已有片段继续往后拍” ​

OpenAI 当前文档说明：

  • extension 会把完整源视频当作上下文
  • 更适合保持运动、机位方向和场景连续性
  • 单次最多加 20 秒
  • 单个视频最多扩 6 次，总长最多 120 秒
  • extensions 不支持 characters 和 image references

这意味着：

  • extensions 不是“万能续写”
  • 它更像同一 shot / sequence 的自然延展

7.4 edits 更像“在保留结构的前提下改局部” ​

OpenAI 当前文档明确说：

  • edits 适合做 targeted adjustments
  • 原结构、连续性和构图会尽量保留
  • 小而明确的改动通常更稳

所以 edits 更适合：

  • 调色
  • 换一个局部元素
  • 微调镜头情绪

而不是完全重做整个片段。

8. 视频生成天然是异步任务，不要硬做成“同步聊天” ​

OpenAI 当前视频生成文档明确写到：

  • POST /videos 返回的是带 id 和初始 status 的 job
  • 可以轮询 GET /videos/{video_id}
  • 也可以用 webhook 收 video.completed 和 video.failed

这意味着视频生成从接口层就是：

  • job system

而不是：

  • “一个请求马上返回最终媒体文件”

8.1 一个更稳的任务状态机 ​

工程里至少可以按下面心智理解：

  1. submitted
  2. queued
  3. processing
  4. completed / failed
  5. downloaded
  6. approved / rejected

8.2 为什么 webhook 比死轮询更适合生产 ​

因为企业里视频任务经常会伴随：

  • 长时渲染
  • 大量并行 job
  • 失败重试
  • 审核和通知

如果只做前端轮询，常见问题包括：

  • 资源浪费
  • 状态漂移
  • 重试逻辑分散
  • 很难挂接审批和告警

8.3 batch 不是普通 create 的简单批量版 ​

OpenAI 当前文档明确说明：

  • Batch 当前只支持 POST /v1/videos
  • Batch 请求必须用 JSON
  • 需要提前上传资产并在 JSON 里引用
  • Batch 场景里的 input_reference 只能用 file_id 或 image_url
  • multipart 上传方式不支持 Batch

所以 batch 更适合：

  • 营销素材多版本
  • 夜间离线渲染
  • 大批量实验任务

而不是人工交互式逐条生成。

9. 下载、留存和删除边界要在产品第一天就想清楚 ​

很多团队会把视频看作“生成完成就结束”，但官方资料已经明确告诉你并不是这样。

9.1 下载窗口通常比想象中更短 ​

OpenAI 当前视频文档写得很清楚：

  • 单个生成结果的下载 URL 最长有效 1 小时
  • 每个完成视频还可以额外下载 thumbnail 和 spritesheet
  • Batch 生成的视频在 batch 完成后可下载约 24 小时

这直接影响你的产品设计：

  • 是否自动归档到自有对象存储
  • 是否要生成预览图和拖动预览条
  • 是否允许用户事后回来继续编辑

9.2 平台留存和你自己的归档不是一回事 ​

OpenAI 当前 Data controls in the OpenAI platform 明确写到：

  • /v1/videos 在处理过程中会落盘
  • 为了方便下载，生成结果会保留 48 小时
  • 之后还会保留 30 天用于 abuse monitoring
  • /v1/videos 目前不支持 MAM / ZDR

这意味着如果你的组织对留存有严格要求，就必须把：

  • 平台留存
  • 自建归档
  • 项目级 retention 设置

一起设计，而不是等法务追问时再补。

9.3 删除动作最好可审计 ​

OpenAI 当前官方文档还提供了：

  • GET /videos
  • DELETE /videos/{video_id}

这对生产系统意味着你至少要保留：

  • 生成 job ID
  • 资产来源
  • 下载时间
  • 删除时间
  • 删除操作者

否则后面很难做：

  • 内容下线
  • 版权撤回
  • 审计复盘

10. 视频理解和视频生成需要完全不同的产品形态 ​

10.1 视频理解更像分析系统 ​

它更适合提供：

  • 摘要
  • 章节
  • 时间点
  • 搜索
  • 证据跳转

10.2 视频生成更像素材工厂 ​

它更适合提供：

  • Prompt 模板
  • 镜头库
  • 角色资产
  • 批量生成
  • 编辑与审核工作台

如果把两者混成同一套交互，产品往往会变得非常别扭。

10.3 一个很实用的分工方式 ​

  • 视频理解系统：围绕 上传、切分、问答、回放、证据
  • 视频生成系统：围绕 资产、模板、任务、审批、交付

这两类系统可以共享底层对象存储、队列和权限，但最好不要共享同一套操作台心智。

11. 视频任务怎么评测才不只剩主观打分 ​

11.1 理解类 ​

适合看：

  • 关键事件识别率
  • 时间点定位误差
  • 摘要覆盖率
  • 问答准确率
  • 证据片段命中率

11.2 生成类 ​

适合看：

  • 连续性
  • 可控性
  • 风格一致性
  • 失败率
  • 审核返工率

11.3 产品类 ​

适合看：

  • 平均渲染时长
  • 批量成功率
  • 人工返修率
  • 审核通过率
  • 下载成功率

11.4 企业里还应额外看什么 ​

例如：

  • 单分钟成本
  • 重试成本
  • 队列积压
  • 素材复用率
  • 归档成功率

11.5 一定要分桶，不要只看“整体观感” ​

至少应把用例拆成几桶：

  • 短 clip 摘要
  • 长视频问答
  • 高速动作片段
  • 品牌素材生成
  • extensions
  • edits
  • batch 大规模离线生成

因为这些桶的失败根因往往完全不同。

12. 企业里更实用的几条建议 ​

12.1 先做短片段，再做长片段 ​

因为长视频会把：

  • 时序
  • 成本
  • 评测

问题同时放大。

12.2 先做异步，再谈实时 ​

大多数视频任务本来就不适合实时。

12.3 先建镜头模板和角色资产 ​

比起让每个人都从头写 prompt，更稳妥的做法是：

  • 预设镜头语法
  • 预设角色资产
  • 预设风格模板
  • 预设参数档位

12.4 先用编辑和延展，再考虑全量重做 ​

局部编辑往往比整段重生更便宜、更稳、更可控。

12.5 先打通归档和审计，再放大运营规模 ​

因为一旦量起来，最先出问题的常常不是“生成不出来”，而是：

  • 找不到资产
  • 下载过期
  • 删除无记录
  • 审核链路断裂

13. 常见反模式 ​

13.1 直接把整段视频全量送模型 ​

这样通常最贵、最慢、最难回溯。

13.2 只看视觉，不看音频和 OCR ​

这在真实业务里几乎一定会漏信息。

13.3 把视频生成当成图片生成的放大版 ​

结果通常是：

  • 镜头不稳
  • 连续性差
  • 参数边界混乱

13.4 不做异步队列和人审 ​

企业视频流程很容易因此失控。

13.5 不记录时间轴和资产谱系 ​

后果通常是：

  • 无法复查
  • 无法重跑
  • 无法撤回

13.6 不提前设计留存和删除边界 ​

等到内容审核、合规或版权撤回时，往往会非常被动。

14. 推荐搭配阅读 ​

15. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：