Если нужен ролик длиннее одного генерируемого фрагмента, удобнее строить его как последовательность коротких сцен. В этой статье разберём, как использовать api генерации видео для такого пайплайна: сначала сделать раскадровку, затем отправить сцены по очереди, дождаться результатов и собрать видео из нескольких сцен.
Подход особенно полезен, когда длинное видео нейросеть не выдаёт одним цельным результатом или когда отдельные эпизоды проще контролировать по описанию. Для работы с API ключ можно получить в разделе API: после входа ключ показывается один раз. Оплата идёт за запуск операции, без абонентской платы и минимального платежа, а при выпуске первого ключа на баланс начисляется 50 ₽ для пробного использования.
1) Почему ролик нельзя сгенерировать одним куском
Для длинного ролика проблема обычно не только в хронометраже. Чем больше событий находится внутри одного промпта, тем сложнее точно задать порядок действий, композицию, персонажей и визуальные изменения. Если результат одного длинного запроса не устраивает, приходится переделывать весь фрагмент.
При поэтапной генерации ошибка ограничивается одной сценой. Например, сюжет можно разбить на 12 эпизодов: общий план города, герой выходит из здания, садится в автомобиль, едет по ночной улице и так далее. Если третья сцена получилась неудачно, её можно перегенерировать отдельно, не трогая остальные.
API предоставляет операцию «Видео по описанию» с ценой 119 ₽ за один запуск. Сам запуск выполняется через POST /generate, а состояние задачи можно проверять через GET /tasks/{id}. Поэтому логика приложения получается достаточно простой: сформировать описание сцены, отправить операцию, сохранить идентификатор задачи, дождаться результата и перейти к следующему фрагменту.
Важно разделять два понятия: генерация сцен и сборка готового файла. API запускает операции генерации, но из предоставленной документации не следует наличие отдельного маршрута для монтажа нескольких видеороликов. Поэтому склейку стоит организовать на своей стороне после получения готовых файлов.

2) Раскадровка: как разбить замысел на сцены
До первого API-запроса стоит сделать таблицу сцен. Минимальные поля — номер, длительность, действие, камера, персонажи, окружение и ключевые визуальные признаки. Такая схема предотвращает ситуацию, когда соседние промпты описывают один и тот же эпизод разными словами.
Например, для рекламного ролика автомобиля можно сделать последовательность из шести сцен. Первая показывает автомобиль на парковке на рассвете, вторая — движение по городской улице, третья — крупный план колеса, четвёртая — поездку по загородной дороге, пятая — остановку у смотровой площадки, шестая — финальный общий план.
Каждую сцену лучше описывать как самостоятельный производственный блок. Не стоит писать в промпте второй сцены «продолжение предыдущей», потому что отдельный запуск не обязан знать содержание предыдущего результата. Вместо этого нужно повторять информацию, которая должна сохраняться: модель автомобиля, цвет, время суток, тип освещения, окружение и характер движения камеры.
Практически это можно представить как массив данных в Python:
scenes = [
{
"number": 1,
"prompt": "Черный спортивный автомобиль стоит на пустой городской улице на рассвете..."
},
{
"number": 2,
"prompt": "Тот же черный спортивный автомобиль движется по той же городской улице..."
},
{
"number": 3,
"prompt": "Крупный план переднего колеса того же черного спортивного автомобиля..."
}
]
Дальше программа может пройти массив циклом. Важный момент: запуск операции и получение результата — разные действия. После POST /generate нужно ориентироваться на возвращённый идентификатор задачи и проверять его состояние через /tasks/{id}, а не считать запрос завершённым только потому, что HTTP-запрос успешно отправлен.
Рабочий пример запуска операции через curl выглядит так:
curl -X POST "https://genius-bot.ru/wp-json/genius/v1/generate" \
-H "Authorization: Bearer ВАШ_КЛЮЧ" \
-H "Content-Type: application/json" \
-d '{
"operation": "video",
"prompt": "Черный спортивный автомобиль медленно движется по мокрой городской улице ночью, кинематографичный общий план"
}'
Названия полей, которые принимает конкретная операция, стоит сверять с актуальным описанием операции, полученным через GET /services. Известно, что именно этот маршрут возвращает список доступных операций и цен; поэтому перед автоматизацией полезно один раз запросить его и не зашивать цены и перечень операций в приложение вручную.
3) Единый стиль между сценами: что повторять в описании
Самая заметная проблема при сборке коротких сцен — нестыковка между ними. Персонаж может изменить одежду, автомобиль — цвет, освещение — время суток, а интерьер — архитектуру. Формально каждая сцена может выглядеть хорошо, но вместе они будут восприниматься как разные ролики.
Поэтому удобно завести «стиль-блок», который добавляется в каждый промпт. В нём фиксируются визуальная техника, цветовая палитра, время суток, характер света, окружение, внешний вид основных объектов и общий язык камеры. Индивидуальная часть промпта описывает только то, что меняется в конкретной сцене.
Например, постоянная часть может выглядеть так: «реалистичная кинематографичная съёмка, холодная сине-серая палитра, мягкий рассеянный свет, влажный асфальт, объектив с умеренной перспективой, естественное движение камеры». К ней добавляется действие: «автомобиль медленно проезжает мимо витрин» или «камера приближается к припаркованному автомобилю».
Повторять нужно не только художественные характеристики. Если в истории есть герой, полезно каждый раз явно указывать возрастной диапазон, одежду, цвет одежды, причёску и другие признаки, которые должны оставаться постоянными. Для предметов действует тот же принцип: цвет, форма, материал и положение относительно сцены лучше задавать явно.
При этом одинаковый промпт не гарантирует пиксельной идентичности. Генерация каждой сцены остаётся отдельной операцией. Поэтому перед склейкой стоит просмотреть соседние кадры именно парами: конец сцены 1 с началом сцены 2, затем конец сцены 2 с началом сцены 3.
Такой контроль позволяет обнаружить проблему до монтажа. Если в двух соседних сценах автомобиль выглядит по-разному, бессмысленно пытаться скрыть это длинным переходом. Проще перегенерировать одну из сцен с более подробным описанием постоянных элементов.

4) Склейка и переходы: минимальный набор инструментов
После генерации получается набор отдельных видеофайлов. Их нужно привести к одинаковым техническим параметрам и расположить в заданном порядке. На этом этапе особенно важно не маскировать плохие стыки эффектами: если в конце первой сцены камера резко смотрит вправо, а следующая начинается с неподвижного крупного плана, даже красивый переход может выглядеть искусственно.
Для обычного ролика достаточно трёх операций: привести фрагменты к единому формату, расположить их в нужной последовательности и добавить короткие переходы там, где они действительно нужны. Жёсткая склейка часто выглядит естественнее, чем большое количество эффектов.
Есть простой принцип для выбора места перехода. Если действие продолжается непрерывно, лучше использовать обычную склейку по движению. Если меняется место или время, допустим короткий раствор. Если начинается принципиально новый сюжетный блок, можно оставить небольшой визуальный разрыв вместо попытки искусственно соединить два кадра.
Склейка сцен видео api в данном случае означает не отдельную функцию API, а общий производственный процесс: API используется для получения исходных сцен, а монтаж выполняется после этого. Это важно учитывать при проектировании приложения, чтобы не ожидать от POST /generate готового трёхминутного монтажа.
Если приложение получает результаты асинхронно, удобнее сначала сформировать все задачи, а затем обрабатывать их результаты. Для небольшого ролика можно идти последовательно, чтобы проще контролировать ошибки. Для большого количества сцен стоит учитывать лимит частоты: не более 60 запросов в минуту на один ключ.
При наличии серверной инфраструктуры можно не держать постоянный цикл опроса. В API предусмотрен необязательный параметр callback_url: когда задача готова, на указанный адрес приходит POST. Это удобно, если генерация сцен выполняется в фоне и приложение не должно постоянно спрашивать состояние каждой задачи.
5) Звук поверх собранного видео
Звук лучше добавлять после того, как видеоряд собран. Тогда длительность музыки, шумов и озвучки можно подогнать под фактический монтаж, а не пытаться заранее рассчитать их по отдельным сценам.
Для музыки доступна операция «Создать музыку» за 59 ₽ за запуск. Для звуковых эффектов есть «Звук по описанию» за 9 ₽ за запуск, а для речи — «Озвучка текста» за 18 ₽ за 1000 знаков. Отдельно доступна операция извлечения звука из видео с ценой 0 ₽.
| Операция | Цена | Когда использовать |
|---|---|---|
| Видео по описанию | 119 ₽ за запуск | Отдельная сцена ролика |
| Создать музыку | 59 ₽ за запуск | Общий музыкальный фон |
| Звук по описанию | 9 ₽ за запуск | Отдельные звуковые эффекты |
| Озвучка текста | 18 ₽ за 1000 знаков | Дикторский текст |
Если нужен голос, текст удобно разбить на смысловые блоки, соответствующие сценам. Это упрощает монтаж: после изменения третьего эпизода не обязательно заново работать со всей озвучкой. Музыку, наоборот, часто удобнее генерировать одним отдельным треком и затем обрезать или зациклить его при сборке.
Python-вариант запуска генерации сцены через requests может выглядеть так:
import requests
BASE_URL = "https://genius-bot.ru/wp-json/genius/v1"
API_KEY = "ВАШ_КЛЮЧ"
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
payload = {
"operation": "video",
"prompt": (
"Тот же черный спортивный автомобиль, что и в предыдущей сцене. "
"Ночная мокрая улица, холодная сине-серая палитра, "
"мягкий рассеянный свет, плавное движение камеры."
)
}
response = requests.post(
f"{BASE_URL}/generate",
headers=headers,
json=payload,
timeout=60,
)
response.raise_for_status()
task = response.json()
print(task)
После запуска значение идентификатора из ответа нужно использовать для обращения к GET /tasks/{id}. В готовом скрипте стоит добавить обработку ошибок HTTP, таймауты и сохранение идентификаторов задач в базе или файле, чтобы после перезапуска процесса не потерять уже созданные сцены.

6) Сколько стоит трёхминутный ролик
Здесь нельзя честно назвать одну фиксированную цену без количества сцен: стоимость операции «Видео по описанию» указана за запуск, а не за минуту готового ролика. Поэтому сначала нужно определить, сколько самостоятельных генераций требуется для трёх минут.
Например, возьмём условную монтажную схему из 18 сцен по 10 секунд. Это именно расчётный пример, а не заявленная характеристика длительности одной генерации. При цене 119 ₽ за запуск только видеогенерация составит 18 × 119 = 2142 ₽.
| Состав | Расчёт | Стоимость |
|---|---|---|
| 18 видеосцен | 18 × 119 ₽ | 2142 ₽ |
| 1 музыкальный трек | 1 × 59 ₽ | 59 ₽ |
| Итого без озвучки | 2142 + 59 ₽ | 2201 ₽ |
Если часть сцен придётся перегенерировать, каждая новая попытка считается новым запуском. Например, три дополнительных варианта сцен добавят ещё 357 ₽. Поэтому в бюджете лучше отдельно учитывать основную генерацию и резерв на переделки.
Озвучка рассчитывается отдельно — 18 ₽ за каждые 1000 знаков. Если текст диктора занимает 4000 знаков, это четыре расчётных единицы по 1000 знаков, то есть 72 ₽. При этом фактический объём текста зависит от сценария, поэтому заранее включать эту сумму в универсальную стоимость трёхминутного ролика неправильно.
Перед запуском большого количества сцен можно проверить доступные операции и текущие цены через GET /services, а остаток средств — через GET /balance. Это особенно удобно для скрипта, который автоматически создаёт десятки задач и должен остановиться до исчерпания баланса.
В результате пайплайн получается таким: сценарий превращается в раскадровку, раскадровка — в набор независимых промптов, промпты — в задачи API, задачи — в отдельные видеосцены, а затем сцены собираются в один файл. Такой подход не скрывает швы, но делает их управляемыми: проблемную сцену можно заменить, а не переделывать весь ролик.
Частые вопросы
Можно ли сразу отправить в API запрос на трёхминутный ролик?
Для описанного подхода нет необходимости строить процесс вокруг одного большого запроса. Ролик разбивается на отдельные сцены, каждая запускается как операция «Видео по описанию», после чего результаты собираются на стороне приложения. Документация, приведённая для этого сервиса, не задаёт отдельной операции монтажа длинного ролика.
Как сохранить единый стиль между сценами?
Используйте постоянный блок описания с одними и теми же характеристиками света, палитры, окружения, камеры и внешнего вида персонажей или объектов. Переменную часть промпта оставляйте для действия конкретной сцены. Даже при таком подходе соседние результаты нужно проверять визуально.
Что делать, если одна сцена получилась неудачной?
Перегенерировать только её. Поскольку каждая сцена является отдельным запуском, остальные готовые результаты можно сохранить и использовать повторно. Новая попытка учитывается как отдельный запуск операции.
Как узнать, готово ли видео?
После запуска операции используется идентификатор задачи, а её состояние и результат доступны через GET /tasks/{id}. Для фонового процесса можно передать необязательный callback_url, чтобы получить POST после готовности задачи.
Есть ли ограничение на количество запросов?
На один API-ключ разрешено не более 60 запросов в минуту. При массовой генерации сцен это ограничение нужно учитывать в очереди задач и не отправлять запросы без контроля частоты.
Где получить ключ и посмотреть доступные операции?
Ключ выдаётся после входа в разделе работы с API и показывается один раз. Для программного получения списка операций и цен предусмотрен маршрут GET /services, а для проверки остатка — GET /balance.
