gemini-omni-1.2-flash 实战：3 个视频生成业务场景与落地检查清单

先确认输入形态与参数边界

HiAPI 当前接入的公开模型 gemini-omni-1.2-flash 输出视频，提供四种生成模式：文生视频、首帧图生视频、首尾帧过渡、参考图生视频。动手写代码之前，先把「这次我要喂给它什么」确定下来，比先挑场景更有效。

当前不开放的能力包括：视频编辑、视频续写、视频或音频作为输入、seed 参数。依赖这些能力的流程，不能通过该模型实现。

请求参数

• prompt：唯一必填项，必须为非空字符串，最多 20000 字符。
• duration：整数，取值 3–15 秒，默认 10 秒。
• resolution：360p / 720p / 1080p / 4k，默认 720p。1080p 与 4k 为放大输出，4k 可能不含音轨。
• aspect_ratio：16:9 或 9:16，默认 16:9。

图片参数与互斥关系

• image_urls：1–10 张公开 HTTP(S) 参考图，走参考图生视频。只传一张时仍然是参考图，不会自动变成首帧模式。
• first_frame_url：指定起始画面，可单独使用，形成首帧图生视频。
• last_frame_url：必须与 first_frame_url 一起使用，形成首尾帧过渡。首尾帧模式最长 10 秒，并且请求中不能带 negative_prompt 或 system_prompt。
• image_urls 与 first_frame_url、last_frame_url 互斥，一次请求只能选其中一种模式。
• 所有图片参数只接受公开可访问的 HTTP(S) URL，不支持 Base64。

需要提前建立的预期：不保证各模式均带声音、口型同步、文字准确，也不保证生成结果中的主体或品牌与参考完全一致。这些都需要人工验收。

成本口径：按分辨率分档的每秒报价

该模型按请求时长计费，单价随分辨率分档。当前默认倍率下的报价如下：

• 360p：$0.0229/秒
• 720p：$0.0343/秒
• 1080p：$0.0343/秒
• 4k：$0.0800/秒

预算换算为：所选分辨率单价 × 请求时长 × 条数。同一规格、相同时长下，每新增一条成功任务，通常是在预算上增加一条任务的金额，而不是把每轮累计预算翻倍。

实际账单与适用倍率以站点价格面板为准。计费按请求时长计算，不能按输出文件容器中的小数秒数反推。

两条与预算直接相关的操作规范：对结果不满意而重新创建任务，会增加一条任务的预算；遇到网络超时，先查询已有任务的状态，确认没有创建成功再决定是否新建。

场景一：文字创意试稿

适用情形：手上只有文字 brief，需要在进入正式制作前比较多个视觉方向。这是文生视频最直接的用法。

做法

• 把 brief 改写成可视觉化的描述。「年轻女性在清晨的城市街头快步走，手持一杯咖啡，镜头跟拍」比「传递活力生活方式」更可执行。
• 只传 prompt，不传任何图片参数，按不同方向各提交一条任务。
• 用较短的 duration 控制单条预算，试稿阶段不需要长片；同一批里保持 duration 与 resolution 一致，便于横向比较。
• 结构化记录：prompt、duration、resolution、任务 ID 与结果地址一起存档，下一轮迭代才有参照。

边界

试稿产出的用途是帮助选方向，不是投放素材；分镜细节、品牌标识、合规字幕通常仍需后续专业制作。如果最终画面必须与既有素材对得上，应改用首帧图生视频或参考图生视频。

场景二：首帧图片动态化

适用情形：已经有高质量的静态图——商品图、封面、插画、海报——希望让画面动起来，同时保留原图主体。

做法

• 用 first_frame_url 指定起始画面，prompt 只描述运动与镜头（轻微推近、缓慢环绕、光影流动），而不是重新描述主体。
• 需要指定结束画面时，同时传 first_frame_url 与 last_frame_url，形成首尾帧过渡；此时 duration 不得超过 10 秒，且请求中不能带 negative_prompt 或 system_prompt。
• 图片先放到公开位置：只接受公开可访问的 HTTP(S) URL，内网地址或 Base64 都不可用。
• 逐条落库：记录源图 URL、prompt、duration、resolution 与任务 ID，便于回溯和二次利用。

与参考图模式的区别

first_frame_url 决定「从哪里开始」，image_urls 提供的是风格与内容参考。两者互斥，不能在同一次请求里同时使用；只传一张 image_urls 不会变成首帧模式。

场景三：参考图约束视觉

适用情形：需要一批素材在色调、质感、构图习惯上更接近某个既定视觉，而单条质量并不是主要矛盾。

做法

• 用 image_urls 传 1–10 张公开参考图，挑最能代表目标风格的少量素材；避免混用目标互相冲突的参考图，并检查实际生成结果。
• 明确这是参考图模式：即使只传一张，也仍然是参考图生视频，不涉及首帧或首尾帧。
• 建立固定检查项：主色调、光线倾向、画面密度、文字区域，对新产出的批次做横向比对。
• 发现漂移先查参考素材，再调整 prompt，而不是盲目重跑——重跑会新增按秒计费的任务。

边界

参考图可用于约束风格，但不保证主体或品牌完全一致，仍需人工抽检把关。把它理解为「风格基线」而不是「风格保险」，预期会更接近实际。

落地检查清单

开工前逐项确认，有助于及早发现入参和预算问题。

能力与参数

• 是否明确本次用哪种模式：文生视频、首帧图生视频、首尾帧过渡、参考图生视频？
• prompt 是否非空且不超过 20000 字符？
• duration 是否为 3–15 秒的整数？首尾帧模式是否已压到 10 秒以内？
• resolution 与 aspect_ratio 是否按用途选定（默认 720p、16:9）？
• 是否只用了其中一种图片来源：image_urls 或 first_frame_url/last_frame_url？
• 所有图片是否都是公开 HTTP(S) URL，没有 Base64？
• 首尾帧请求里是否已移除 negative_prompt 与 system_prompt？
• 是否用到视频编辑、续写、视频/音频输入或 seed？这些当前不开放。

成本

• 是否按所选分辨率的单价 × 时长 × 条数算出预算，而不是凭感觉？
• 预算是否按「候选条数」而非「交付条数」估算？
• 是否清楚同一规格、相同时长下，新增一条成功任务即增加一条任务的预算？
• 实际账单是否以站点价格面板与适用倍率为准，而不是按文件容器的小数秒推断？

工程

• 任务提交是否已异步化，请求侧不阻塞等待视频？
• 是否保留任务 ID 并落库，包含 prompt、duration、resolution 与结果地址？
• 是否有显式状态机与幂等键，避免重复提交？
• 网络超时是否先查询已有任务，而不是直接重新创建？
• 是否限制并发，并让批量任务在队列里等待？

质量与验收

• 验收标准是否提前写死：主体完整性、品牌要素、文字区域、声音是否符合预期？
• 是否保留人工抽检比例，放量时不降低？
• 是否为单日或单批预算设置熔断与告警？

四种模式共用同一个接口形态，差别只在入参。把模式选对、把互斥关系写进参数校验、把预算按条数算清，再进入批量，落地路径就清楚了。