Создание коротких видео с помощью flux-3-max/text-to-video в API HiAPI

Почему короткое видео — это задача составления промптов

Большинство команд, терпящих неудачу в генерации видео из текста, делают это по одной и той же причине: они пишут один огромный промпт, описывающий всю сцену, и ожидают, что модель вернёт готовое тридцатисекундное видео. Генерация так не работает. Модель за один вызов создаёт только один непрерывный кадр, и каждый вызов — это небольшое, самодостаточное решение о субъекте, действии, композиции и звуке.

Рабочая ментальная модель — это оркестрация. Вы не подсказываете видео, вы режиссируете последовательность кадров, а затем собираете их вместе. Короткое видео — трейлер продукта, зацепка для соцсетей, закадровый рассказ — обычно состоит из четырёх-восьми кадров. Каждый кадр несёт одну задачу: установить, показать, перейти, завершить. Как только вы принимаете эту декомпозицию, API перестаёт быть игровым автоматом и становится шагом рендеринга в конвейере, который вы контролируете.

Это важно, потому что режимы отказа генерации видео из текста — это в основном отказы непрерывности, а не качества. Отдельный кадр может выглядеть красиво, но если в следующем кадре персонаж другой, направление света иное или камера внезапно уплывает, то этот кадр всё равно непригоден. Такие проблемы решаются до отправки запроса — тем, как вы планируете и описываете кадры, а не добавлением прилагательных в один гигантский промпт.

Остальная часть этого руководства проведёт вас через весь рабочий процесс на HiAPI с вызовом flux-3-max/text-to-video: разбиение сценария на кадры, написание промптов для каждого кадра, трактовка движения камеры как управляемого измерения, использование нативного звука для пропуска отдельного этапа обработки аудио и упаковка всего этого в компактный воспроизводимый цикл запросов.

Планирование кадров до вызова API

Прежде чем писать какой-либо код, превратите сценарий в список кадров. Список кадров — это чистая структура данных: один элемент на каждый вызов генерации, каждый элемент имеет чёткую цель. Следующая структура хорошо подходит в качестве промежуточного представления:

[
  {
    "id": "s1",
    "role": "establish",
    "subject": "керамическая воронка для пуровера на деревянной стойке",
    "framing": "средний крупный план, угол три четверти",
    "durationIntent": "короткий",
    "camera": "медленный наезд",
    "audio": "тихий фоновый шум комнаты, лёгкий пар"
  },
  {
    "id": "s2",
    "role": "demonstrate",
    "subject": "горячая вода закручивается спиралью над кофейной гущей",
    "framing": "плотный макросъёмка сверху",
    "durationIntent": "короткий",
    "camera": "статичная камера",
    "audio": "звук наливания воды, тихое шипение"
  }
]

Несколько правил планирования, которые сэкономят вам повторные попытки позже:

• Одна идея на кадр. Если ваше описание кадра содержит «затем», разделите его. Модель справляется с одним непрерывным действием гораздо лучше, чем с цепочкой тактов.
• Выражайте намерение длительности, а не точные секунды. Решите, будет ли кадр быстрым переходом или более длинной паузой, и выразите это как намерение. Точные моменты времени относятся к вашему этапу монтажа/склейки, где вы получаете покадровый контроль точности.
• Закрепите словарь кадрирования как можно раньше. Выберите такие термины, как wide, medium, close-up, overhead, low angle, и дословно повторяйте их во всех кадрах. Согласованный словарь даёт более согласованные результаты.
• Планируйте якоря непрерывности. Решите, что остаётся неизменным: описание персонажа, одежда, цветовая палитра, время суток, направление света. Запишите это один раз как общий префикс и повторяйте в каждом промпте.
• Порядок важен при проверке. Генерируйте в порядке сценария, чтобы проверять в том порядке, в котором будет финальное воспроизведение, а не рассматривать фрагменты как изолированные.

Как только список кадров существует, вызов API становится механическим — именно этого вы и хотите, потому что это делает вызовы повторяемыми и воспроизводимыми.

Написание промптов для каждого кадра для flux-3-max/text-to-video

Хороший промпт для кадра структурирован, а не разговорен. Вместо одной длинной строки свободного формата составьте каждый промпт из небольшого числа помеченных абзацев. Это делает промпты diff-пригодными, повторно используемыми и легко корректируемыми, когда что-то не так с одним элементом.

Пятичастная структура

1. Субъект — кто или что, включая выбранные вами детали непрерывности (внешность, одежда, характеристики продукта).
2. Действие — одно непрерывное движение или состояние, описанное в настоящем времени.
3. Окружение — место, время суток, качество света, цветовая палитра.
4. Камера — кадрирование плюс движение, с использованием вашего закреплённого словаря. Следующий раздел раскрывает это подробнее.
5. Аудио — намерение атмосферы и фоли-звуков для этого кадра.

Соберите их в фиксированном порядке, чтобы ваша собственная отладка тоже была согласованной:

CONTINUITY = (
    "минималистичная керамическая воронка для пуровера, матово-белая, "
    "на тёплой дубовой стойке, мягкий утренний свет из окна слева, "
    "приглушённая природная палитра"
)

def shot_prompt(subject, action, setting, camera, audio):
    return (
        f"{subject}. {action}. {setting}. "
        f"Camera: {camera}. Audio: {audio}."
    )

prompt = shot_prompt(
    subject=f"{CONTINUITY}",
    action="пар поднимается ровно, пока вода медленно раскрывает кофейную гущу",
    setting="кухонная стойка на рассвете, малая глубина резкости",
    camera="средний крупный план, медленный наезд, без тряски",
    audio="тихий фоновый шум комнаты, мягкое наливание воды, слабое шипение пара",
)

Сохранение визуальной согласованности кадров

Единственная привычка с наибольшим рычагом — это общий блок непрерывности. Поместите его в начало каждого сегмента субъекта и держите неизменным во всех кадрах последовательности. Когда какой-то кадр визуально уплывает, вы можете бинарно локализовать проблему: это блок непрерывности или действие, специфичное для кадра?

Ещё две привычки, снижающие дрейф:

• Избегайте противоречивых прилагательных. «Кинематографичный документальный ручной статичный» — это три конфликтующие инструкции. Выберите одну.
• Описывайте свет только один раз. Если блок непрерывности говорит об утреннем свете слева, не позволяйте последующим кадрам вводить верхний флуоресцентный свет — если только этот переход не является намеренным.

Что опускать в промптах

Вынесите соотношение сторон, длину вывода и другие технические параметры из текстового описания и передавайте их как параметры запроса, когда API их предоставляет. Текстовое описание говорит, что представляет собой кадр; параметры говорят, как он доставляется. Смешивание обоих делает и то, и другое труднее изменять.

Управление движением камеры

Движение камеры — это измерение, которое легче всего оставить на волю случая, и оно же сильнее всего влияет на то, воспринимается ли последовательность как режиссированная. Если вы не укажете его, модель будет двигать камеру каким-то образом; неуказанное движение проявляется как дрейф, а дрейф — это именно то, что заставляет сгенерированный материал выглядеть снятым случайно.

Относитесь к движению как к небольшому закрытому словарю

Не импровизируйте язык камеры для каждого кадра. Определите небольшой набор движений и повторяйте его:

• Статичная камера — без движения. Самый безопасный выбор для деталей продукта и крупных планов.
• Наезд / отъезд — движение к субъекту или от него. Подходит для акцента и раскрытия.
• Панорама влево / вправо — горизонтальное вращение. Используется для установления пространства.
• Наклон вверх / вниз — вертикальное вращение. Используйте осторожно; это читается как драматично.
• Следящая камера — движется вместе с субъектом. Требует явно движущегося субъекта в качестве якоря.

Запишите их в сегменте камеры, а затем добавьте отрицательную инструкцию, подавляющую остальное движение: Camera: slow push in, no shake, no handheld drift.

Отрицательное предложение важно. Просто «наезд» оставляет модели пространство для добавления тряски; «наезд, без тряски» сужает диапазон.

Пусть движение служит роли кадра

Движение должно служить монтажу. Практическое отображение:

• Устанавливающий кадр — одно чёткое движение (медленный наезд или мягкая панорама), дающее взгляду точку опоры.
• Кадр детали — статичная камера. Деталь сама по себе визуально насыщена; движение будет с ней конкурировать.
• Переход — согласованное движение в соседних кадрах (оба наезжают, оба панорамируют в одном направлении), чтобы даже без переходных эффектов склейка ощущалась намеренной.
• Герой-кадр — одно осознанное движение, никогда не два в комбинации.

Одно движение на кадр

Комбинированные движения («панорамировать вправо, одновременно наезжая и наклоняясь вверх») дают мутные результаты. Если такт требует сложного движения камеры, разделите его на два кадра. Ваш этап склейки соединит их, и при этом вы сохраните покадровый контроль над переходом.

Согласованность движения в последовательности

Заранее решите доминирующее движение всего произведения — например, «все кадры медленно наезжают» — и отклоняйтесь только тогда, когда нужен эффект. Последовательность с согласованным направлением движения читается как авторская; последовательность со случайным движением читается как сгенерированная.

Использование нативного звука в конвейере

Генерация нативного звука меняет архитектуру конвейера коротких видео. В традиционном процессе вы сначала генерируете немое видео, затем запускаете отдельный этап обработки аудио — либо модель генерации аудио из текста, либо лицензированные библиотеки фоли и музыки — а затем выравниваете оба в редакторе. Каждый этап — это ещё один сервис, ещё одни учётные данные, ещё один режим отказа и ещё одно место, где может возникнуть рассинхронизация.

Когда видеомодель генерирует звук встроенно, звук и изображение создаются на одном шаге вывода, поэтому он естественно согласован с тем, что происходит на экране. В момент, когда вода выливается, звук выливания совпадает с действием выливания. Это почти полностью устраняет работу по выравниванию.

Два конвейера, одно различие

Отдельный аудиоэтап:            Нативный звук:
  кадр -> видео (немое)           кадр -> видео + аудио
       -> генерация аудио              -> сборка
       -> выравнивание / микширование
       -> сборка

Практическое преимущество — меньше движущихся частей. Практическое ограничение — вам нужно планировать звук в промпте, а не добавлять его после.

Планируйте кадры с учётом звука

Поскольку аудио является частью генерации, пишите его как часть кадра, а не как дополнение после:

• Называйте доминирующий звук. Audio: water pouring, gentle hiss лучше, чем Audio: pleasant kitchen sounds.
• Будьте немногословны. Один-два чётких элемента на кадр. Многослойные описания аудио часто слипаются.
• Принимайте решение о музыке осознанно. Если вы планируете наложить музыкальную подложку на всё произведение в редакторе, оставьте в аудио кадров только атмосферу, чтобы она не конфликтовала с музыкальной дорожкой.
• Учитывайте непрерывность звука. Как и визуальная непрерывность, аудионепрерывность через склейки помогает — одинаковый фоновый шум комнаты в соседних кадрах заставляет последовательность ощущаться находящейся в одном месте.

Где редактор всё ещё выигрывает

Нативный звук не заменил редактор. Он заменил этап выравнивания. Вам всё ещё нужна финальная нормализация громкости, а если вы используете музыку — этап микширования, чтобы приглушить диалог и фоли под подложкой. Заложите на это бюджет в конвейере, но гораздо меньший, чем при использовании отдельного этапа генерации.

Готовый к запуску запрос и процесс сборки

Имея список кадров и построитель промптов, слой запросов становится тонким. Ключевые решения: как вызывать модель, как обрабатывать последовательность и повторные попытки и как передать результаты в склейку.

Цикл оркестрации

import time

SHOTS = [
    # ваш запланированный список кадров с предыдущего шага
]

def generate_shot(shot, attempt=0):
    payload = {
        "model": "flux-3-max/text-to-video",
        "prompt": build_prompt(shot),
        # передавайте параметры доставки здесь, а не в тексте:
        # соотношение сторон, длина и т.д. согласно справочнику API
    }
    try:
        return client.generate(payload)
    except TransientError:
        if attempt >= 3:
            raise
        time.sleep(2 ** attempt)
        return generate_shot(shot, attempt + 1)

def run_sequence(shots):
    results = {}
    for shot in shots:
        results[shot["id"]] = generate_shot(shot)
    return [results[s["id"]] for s in shots]

Три вещи делают этот цикл производственно безопасным, а не просто демонстрацией:

• Упорядоченная итерация. Генерация в порядке сценария означает, что частичный сбой оставляет префикс, который можно проверить, а повторный запуск только недостающих кадров становится простым.
• Результаты, хранящиеся по ключу. Храните вывод по id кадра, а не по позиции в списке. Если третий кадр не удался и был перегенерирован, вы перезаписываете по ключу, а не добавляете заново.
• Ограниченные повторные попытки с задержкой. Транзиентные сбои нормальны для любого API генерации. Ограничьте число повторных попыток, чтобы один плохой кадр не блокировал всю задачу.

Передача в склейку

Ваш цикл генерации должен выдавать манифест — список кадров со ссылками на вывод — и на этом останавливаться. Склейка — это отдельный шаг, потребляющий этот манифест: он обрезает каждый фрагмент до предполагаемой длительности, применяет переходы, накладывает музыкальную подложку и нормализует громкость.

{
  "sequence": [
    {"id": "s1", "clip": "out/s1.mp4", "trim": "keep_first_portion"},
    {"id": "s2", "clip": "out/s2.mp4", "trim": "keep_first_portion"}
  ],
  "audioStrategy": "native_bed_plus_music"
}

Отделение склейки от генерации — это то, что делает весь конвейер воспроизводимым: вы можете перегенерировать кадр, поместить его в манифест и повторно отрендерить финальный монтаж, не трогая ничего остального.

Производственный чек-лист и частые ловушки

Конвейер коротких видео становится надёжным, когда скучная часть становится скучной. Перед масштабированием производства пройдите эти проверки.

Согласованность

• Блок непрерывности полностью одинаков во всех кадрах последовательности.
• Словарь кадров закрыт и повторно используется, а не импровизируется.
• Направление света и цветовая палитра объявляются один раз и в дальнейшем не противоречат.
• Проверяйте кадры по порядку — проблемы непрерывности невидимы при изолированном рассмотрении фрагментов.

Повторные попытки и идемпотентность

• Результаты ключуются по id кадра, так что перегенерация перезаписывает, а не дублирует.
• Повторные попытки ограничены и используют задержку; безнадёжно падающий кадр должен падать громко, а не молча.
• Манифест кадров — единственный источник правды о том, что было сгенерировано, — сохраняйте его вместе с выводом.

Контроль затрат

Генерация оплачивается по объёму работы, произведённой моделью, поэтому ваш главный рычаг — сколько кадров вы генерируете и сколько раз их перегенерируете. Практические средства контроля: зафиксируйте список кадров перед генерацией, проверьте один репрезентативный кадр каждой последовательности перед рендерингом остальных кадров, избегайте спекулятивных перебрасываний уже одобренных кадров. При планировании производства смотрите актуальные цены на панели цен сайта.

Проверка вывода

• Смотрите каждую последовательность целиком на реальной скорости воспроизведения, а не фрагмент за фрагментом.
• Сверяйте аудио с изображением: совпадает ли звук с этим моментом?
• Особенно проверяйте первые две секунды — именно там внимание к короткому видео завоёвывается или теряется.
• Держите небольшой набор известных хороших эталонных промптов и сравнивайте с ними новый вывод, когда качество, кажется, падает.

Частые ловушки

• Гигантские промпты. Один промпт, описывающий всю сцену, даёт один длинный, расфокусированный кадр. Разделите его.
• Указание длительности в текстовом описании. Выражайте моменты времени на этапе монтажа, а не в тексте промпта.
• Случайное движение камеры. Неуказанное движение дрейфует; указывайте движение и подавляйте остальное.
• Отношение к аудио как к отдельному продуктовому решению. Планируйте звук в кадрах, а затем микшируйте в редакторе.

Рабочий процесс из этого руководства — планирование кадров, структурированные промпты, управление движением камеры, использование нативного звука, оркестрация с помощью манифеста — превращает flux-3-max/text-to-video из непредсказуемого генератора в надёжный шаг рендеринга в конвейере, которым вы владеете.