Seedance 2.5: первый и последний кадр, ошибка финала 5.4

Seedance 2.5 относится к последнему кадру как к пункту назначения, а не как к подсказке. Дайте ему оба конца сцены — и он приедет ровно туда, куда просили. Именно этого 2.0 Mini делать не хотел.

Эндпоинт:     POST /v1/videos  ->  202 + polling_url
Поле:         frame_images[] с frame_type first_frame / last_frame
Правило:      aspect_ratio на кадровых задачах 2.5 — это 400. Опустить или adaptive.
На 2.0 так же? Нет. 2.0-mini принимает aspect_ratio вместе с кадрами.
Ошибка финального кадра, средняя абсолютная разница 0–255, меньше — ближе:
              Seedance 2.5, 720p     2.0
              Seedance 2.5, 480p     5.4
              Seedance 2.0 Mini     35.9
              две несвязанные картинки  39.0  (потолок)
Тариф:        $0.11/с на 480p, $0.24/с на 720p, по строке text-to-video
Измерено:     2026-08-24, по одному клипу 5 секунд на конфигурацию

Обновлено 2026-08-24. Все числа ниже получены через POST /v1/videos на ofox в этот день. Маршрутизация видеомоделей меняется, поэтому перед переносом таблицы проверок в свой код перепроверьте четыре случая с ошибками.

Как передать первый и последний кадр

Два элемента в frame_images, у каждого свой frame_type. Переключателя режима нет: эндпоинт выводит image-to-video из тела запроса.

import base64, json, requests

def data_uri(path):
    return "data:image/jpeg;base64," + base64.b64encode(open(path, "rb").read()).decode()

body = {
    "model": "bytedance/seedance-2.5",
    "prompt": "The woman stops walking on the rain-slicked street, turns toward the "
              "camera, and the shot pushes in to her face. Hand-painted 2D animation style.",
    "duration": 5,
    "resolution": "480p",
    # aspect_ratio здесь намеренно отсутствует: см. следующий раздел
    "frame_images": [
        {"type": "image_url", "image_url": {"url": data_uri("wide.jpg")},  "frame_type": "first_frame"},
        {"type": "image_url", "image_url": {"url": data_uri("close.jpg")}, "frame_type": "last_frame"},
    ],
}

r = requests.post("https://api.ofox.io/v1/videos", json=body,
                  headers={"Authorization": "Bearer YOUR_OFOX_API_KEY"})
print(r.status_code, r.json())   # 202 {'id': ..., 'status': 'queued', 'polling_url': ...}

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

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

Действительно ли модель приходит в последний кадр

Да, и разрыв с 2.0 Mini совсем не тонкий. Те же две картинки, тот же промпт, та же длительность, тот же день.

Чтобы получить число, мы вытащили нулевой и финальный кадр каждого клипа, привели кадр и исходное изображение к 256x144 и посчитали среднюю абсолютную разницу по каналам в шкале 0–255. Меньше — ближе.

Читайте с последней строки. Две картинки, не имеющие друг к другу отношения, дают около 39. Финал Mini — 35.9, то есть он закончил там, где сам решил: палитра дождя та же, персонаж другой, кадрирование другое. С первым кадром история иная, его держат обе модели, и это совпадает с поведением линейки 2.0, где первый кадр соблюдается, а последний уплывает.

Две оговорки, прежде чем строить на этом. Каждая конфигурация — один прогон, а не распределение, поэтому выводом считайте порядок, а десятые — одной точкой. И метрика намеренно грубая: она накажет верную композицию, которая пришла на два кадра раньше. Эта грубость и делает 35.9 убедительной. Настолько тупой метрикой невозможно случайно получить значение, вплотную подошедшее к «несвязанным картинкам».

Почему aspect_ratio даёт 400 на кадровой задаче 2.5

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

POST /v1/videos  {model: bytedance/seedance-2.5, resolution: 480p,
                  aspect_ratio: "16:9", frame_images: [first, last]}

400 invalid_request
"The parameter ratio specified in the request is not valid. For first-frame or
 first-last-frame generation, the output ratio follows the first-frame image."

Ловушка вот в чём: наше изображение первого кадра ровно 1280x720, то есть отправленное 16:9 было верным. И всё равно отказ. API не сравнивает ваше значение с картинкой — он в этом режиме не принимает значение вообще.

Отсюда три следствия, и все три измерены, а не предположены:

То есть ограничение принадлежит именно кадровым задачам 2.5. Это не правило про генерацию видео, не правило про всю модель и не правило шлюза. Код, который месяцами работал против Seedance 2.0, начнёт возвращать 400 в тот день, когда кто-то поправит ID модели на 2.5, и сообщение об ошибке будет про параметр, которого никто не трогал.

ByteDance документирует это прямо. Гайд по промптам Seedance 2.5 делит задачи на заблокированные и незаблокированные, помещает «редактирование, первый и последний кадры, продление» в первую группу и поясняет, что заблокированные означают: «соотношение сторон выходного видео, а в ряде случаев и длительность, зафиксированы». На той же странице есть фраза, объясняющая наш результат на 2.0: «Seedance 2.0 не делает такого различия».

Что ещё отклоняет валидатор frame_images

Четыре формы, все ловятся до отправки к провайдеру. Каждая вернулась примерно за секунду и ничего не стоила.

Обратите внимание на путь с индексом в третьей строке. Когда тела запросов генерируются в цикле, frame_images[0] сразу показывает, на какой элемент смотреть. Большинство видео API столько не отдают.

Все пять отказов — живые вызовы к Seedance 2.5. Строка ffprobe внизу относится к трём клипам, которые всё-таки отработали, и именно там видно смену кодека на 1080p.

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

Сколько на самом деле стоит клип image-to-video

Он тарифицируется по строке text-to-video для своего разрешения. Карточка модели считает цену по разрешению и режиму, строки image-to-video там нет, поэтому естественно опасаться, что вы попадёте на «все остальные комбинации» по $0.568/с. Не попадёте.

Три разрешения, три точных совпадения. Файлы вернулись как 854x480, 1280x720 и 1920x1080, все по 24 кадра в секунду с дорожкой AAC на 32 кГц. Длительность выходит 5.04 секунды, а не ровно 5, поэтому считайте по полю usage.video_seconds, а не по собственной арифметике.

Для сравнения: тот же запрос на bytedance/seedance-2.0-mini в 480p обошёлся в $0.10 за клип. Поэтому Mini остаётся правильным инструментом для потоковой работы, где финальный кадр никто не проверяет. Он в пять с половиной раз дешевле — и на этой задаче разница видна.

Какие разрешения принимает Seedance 2.5

Спрашивайте таблицу цен, а не описание. Карточка модели сейчас печатает текстовое резюме про 480p или 720p, тогда как таблица цен на той же странице содержит строки 1080p для text-to-video и video-to-video, а задача 1080p с первым и последним кадром у нас дошла до конца.

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

На 1080p меняется то, о чём на странице не сказано: файл вернулся в HEVC, тогда как выходы 480p и 720p были H.264. Если вы склеиваете клипы копированием потоков или отдаёте их прямо в браузер, смешанная по кодекам партия вас укусит. Проверяйте кодек у файла, а не предполагайте его по модели.

Длительность — вторая ось, изменившаяся между поколениями: 2.5 берёт от 4 до 30 секунд, линейка 2.0 останавливается на 15. Клипу в 30 секунд нужно около десяти тактов действия в промпте, иначе модель растянет один момент на десять секунд. Про этот ритм мы писали в гайде по промптам 2.5, а остальные отличия — в сравнении 2.5 и 2.0.

Как сравнить две видеомодели без двух консолей

Сравнение в этой статье потребовало ровно одной неудобной вещи: прогнать одно и то же тело запроса на seedance-2.5 и seedance-2.0-mini, не меняя больше ничего. Два ID модели, один ключ, одна форма эндпоинта. Нативно это две консоли провайдеров, два баланса и две схемы запроса — и на этом месте большинство сравнивает одну модель со своим воспоминанием о другой и называет это бенчмарком.

Обе модели здесь отвечают на одном и том же POST /v1/videos, потому что видеоэндпоинт не зависит от модели: разница между прогонами была только в поле model. Мы использовали видеоэндпоинт ofox, и тот же приём работает с любым шлюзом, который сохраняет форму запроса между вендорами. Перед тем как доверять межмодельному сравнению, проверьте, не нормализует ли шлюз поля по дороге. Если бы aspect_ratio вёл себя одинаково на 2.5 и 2.0, это был бы плохой знак. Он вёл себя по-разному — значит, поле доходит до каждой модели нетронутым.

Источники

• BytePlus ModelArk: руководство по Seedance 2.5
• BytePlus ModelArk: гайд по промптам Seedance 2.5
• ffmpeg: документация ffprobe
• Pillow: справочник ImageChops
• ofox: создание видео
• ofox: статус видеозадачи
• ofox, карточка модели: Seedance 2.5
• ofox, карточка модели: Seedance 2.0 Mini