Генерування відео

Референсні вхідні дані вибирають режим виконання:

• Немає референсних медіа → generate
• Будь-який референс зображення → imageToVideo
• Будь-який референс відео → videoToVideo
• Референсні аудіовхідні дані не змінюють визначений режим; вони застосовуються поверх будь-якого режиму, який вибирають референси зображень/відео, і працюють лише з провайдерами, які оголошують maxInputAudios.

Змішані референси зображень і відео не є стабільною спільною поверхнею можливостей. Надавайте перевагу одному типу референсу на запит.

# Резервний перехід і типізовані параметри

Деякі перевірки можливостей застосовуються на рівні резервного переходу, а не на межі інструмента, тому запит, який перевищує обмеження основного провайдера, все ще може виконатися на спроможному резервному провайдері:

• Активний кандидат, який не оголошує maxInputAudios (або оголошує 0), пропускається, коли запит містить аудіореференси; пробується наступний кандидат.
• maxDurationSeconds активного кандидата нижчий за запитаний durationSeconds без оголошеного списку supportedDurationSeconds → пропускається.
• Запит містить providerOptions, а активний кандидат явно оголошує типізовану схему providerOptions → пропускається, якщо надані ключі відсутні у схемі або типи значень не збігаються. Провайдери без оголошеної схеми отримують параметри як є (зворотно сумісне наскрізне передавання). Провайдер може відмовитися від усіх параметрів провайдера, оголосивши порожню схему (capabilities.providerOptions: {}), що спричиняє таке саме пропускання, як і невідповідність типу.

Перша причина пропуску в запиті записується на рівні warn, щоб оператори бачили, коли їхнього основного провайдера було обійдено; наступні пропуски записуються на рівні debug, щоб довгі ланцюжки резервного переходу залишалися тихими. Якщо кожен кандидат пропущено, агрегована помилка містить причину пропуску для кожного.

# Дії

# Вибір моделі

OpenClaw визначає модель у такому порядку:

1. Параметр інструмента model - якщо агент вказує його у виклику.
2. videoGenerationModel.primary з конфігурації.
3. videoGenerationModel.fallbacks за порядком.
4. Автовиявлення - провайдери з чинною автентифікацією, починаючи з поточного провайдера за замовчуванням, потім решта провайдерів в алфавітному порядку.

Якщо провайдер завершується помилкою, автоматично пробується наступний кандидат. Якщо всі кандидати завершуються помилкою, помилка містить подробиці з кожної спроби.

Задайте agents.defaults.mediaGenerationAutoProviderFallback: false, щоб використовувати лише явні записи model, primary і fallbacks.

{
  agents: {
    defaults: {
      videoGenerationModel: {
        primary: "google/veo-3.1-fast-generate-preview",
        fallbacks: ["runway/gen4.5", "qwen/wan2.6-t2v"],
      },
    },
  },
}

# Примітки щодо провайдерів

# Режими можливостей провайдера

Спільний контракт генерації відео підтримує режимоспецифічні можливості замість лише плоских агрегованих обмежень. Нові реалізації провайдерів мають надавати перевагу явним блокам режимів:

capabilities: {
  generate: {
    maxVideos: 1,
    maxDurationSeconds: 10,
    supportsResolution: true,
  },
  imageToVideo: {
    enabled: true,
    maxVideos: 1,
    maxInputImages: 1,
    maxInputImagesByModel: { "provider/reference-to-video": 9 },
    maxDurationSeconds: 5,
  },
  videoToVideo: {
    enabled: true,
    maxVideos: 1,
    maxInputVideos: 1,
    maxDurationSeconds: 5,
  },
}

Плоских агрегованих полів, як-от maxInputImages і maxInputVideos, недостатньо, щоб оголосити підтримку режиму трансформації. Провайдери мають явно оголошувати generate, imageToVideo і videoToVideo, щоб live тести, контрактні тести та спільний інструмент video_generate могли детерміновано перевіряти підтримку режимів.

Коли одна модель у провайдера має ширшу підтримку вхідних посилань, ніж решта, використовуйте maxInputImagesByModel, maxInputVideosByModel або maxInputAudiosByModel замість підвищення обмеження для всього режиму.

# Live тести

Опційне live покриття для спільних вбудованих провайдерів:

OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts

Обгортка repo:

pnpm test:live:media video

Цей live файл завантажує відсутні змінні середовища провайдера з ~/.profile, за замовчуванням надає перевагу live/env API ключам перед збереженими профілями автентифікації та запускає release-safe smoke за замовчуванням:

• generate для кожного не-FAL провайдера в sweep.
• Односекундний prompt із lobster.
• Обмеження операції для кожного провайдера з OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS (180000 за замовчуванням).

FAL є опційним, оскільки затримка черги на боці провайдера може переважати час релізу:

pnpm test:live:media video --video-providers fal

Установіть OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1, щоб також запускати оголошені режими трансформації, які спільний sweep може безпечно виконувати з локальними медіа:

• imageToVideo, коли capabilities.imageToVideo.enabled.
• videoToVideo, коли capabilities.videoToVideo.enabled і провайдер/модель приймає локальне відео з buffer-backed введенням у спільному sweep.

Сьогодні спільна live lane videoToVideo охоплює лише runway, коли ви вибираєте runway/gen4_aleph.

# Конфігурація

Установіть стандартну модель генерації відео у вашій конфігурації OpenClaw:

{
  agents: {
    defaults: {
      videoGenerationModel: {
        primary: "qwen/wan2.6-t2v",
        fallbacks: ["qwen/wan2.6-r2v-flash"],
      },
    },
  },
}

Або через CLI:

openclaw config set agents.defaults.videoGenerationModel.primary "qwen/wan2.6-t2v"

# Пов’язане

• Alibaba Model Studio
• Фонові завдання - відстеження завдань для асинхронної генерації відео
• BytePlus
• ComfyUI
• Довідник конфігурації
• fal
• Google (Gemini)
• MiniMax
• Моделі
• OpenAI
• Qwen
• Runway
• Together AI
• Огляд інструментів
• Vydra
• xAI