Skip to content

[Feature]: VideoProvider 支持 Fal 队列协议,换用 kling-3.0-turbo 并按动作类型定时长 #539

Description

@johnnyzhang-eng

背景

2026-08-21 用同一只鸟、同一张首帧(#511 修复后产出,中灰底、主体占幅 42.5%)、同一条产品提示词,横评了七个视频模型。尺度漂移读数:

模型 时长 尺度漂移
seedance-2.0 5s +0%
kling-3.0-turbo 3s +2%
kling-v3 std 3s +3%
kling-v2-5-turbo(现役) 5s +6%
veo 3.1 4s +7%
veo 3.1 8s +21%
kling-v2-6 5s +27%

人工判定:kling-3.0-turbo 3s 表现最好;veo 更强但单价约 3 倍;kling-v3 std 把「飞」做成了走路;kling-v2-6 出杂物。

两条可复用的结论:漂移随时长单调上升(veo 4s +7% → 8s +21%),所以时长不是越长越好;而首帧主体占幅是前置条件(#511 之前只有 16.2%,模型会自己推镜重构角色)。

问题

现役 kling-v2-5-turbo 在这批里排第四。想换成 kling-3.0-turbo 有一个硬约束:它不在 OpenAI 协议面上。

POST /v1/videos 只认 kling-v3-omni / kling-video-o1 / sora*;kling-3.0-turbo 只在 Fal 队列面 queue/fal-ai/kling-video/v3/turbo/{mode}/image-to-video。而 SufyVideoProvider.i2v 只会说 OpenAI 面那一套(POST /videos + input_reference dataURI + GET /videos/{id} 轮询)。

所以这不是往 ALLOWED_VIDEO_MODELS 加一行就行。

范围

  • VideoProvider 支持 Fal 队列协议:submit → 轮询 status_url(IN_QUEUE / IN_PROGRESS / COMPLETED / FAILED)→ 取 response_urlvideo.url → 下 mp4。鉴权是 Authorization: Key,不是 Bearer
  • 首帧传法待定:队列面吃不吃 dataURI 没验出来(只给 image_url 不给 prompt 时,合法 dataURI 与非法裸串返回同一个「prompt 缺失」,说明 image 在 prompt 之后才校验)。若只吃公网 URL,则要在调用前把首帧上传对象存储 —— 产品已有这条能力
  • 时长按动作类型定,不写死 5 秒:简单循环动作(走路、待机、飞行)3 秒足够且漂移最小;复杂一次性动作(攻击、跳跃)再适当加长。当前 i2v(..., seconds=5) 是写死的
  • 时长变短后要核对抽帧密度:3s@24fps = 73 帧,抽 32 帧仍够,但这条要有断言而不是靠巧合
  • 不改抠图、对齐、像素化
  • 不接 veo / seedance:同一套队列协议做好后它们是加型号的事,但单价高,另议

验收

  • 同一只鸟同一首帧,走产品管线用 kling-3.0-turbo 3s 出片,尺度漂移与手工跑的那次同量级
  • 队列任务失败(FAILED)时任务落 failed 并解冻积分,不静默留在 running
  • 时长由动作类型决定,且有用例钉住「走路取 3s」这类映射
  • 现役 kling-v2-5-turbo 仍可用,不因为加了新协议而失效

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions