Рассматривайте запрос к API преобразования видео в видео как задание, а не как готовое видео. У задания есть входные данные, выбранная модель, идентификатор задачи и результат, который всё ещё требует проверки. Это различие помогает не принять подтверждённый запрос за готовый к использованию ресурс. OdiRouter содержит документацию по мультимодальной конфигурации, отправке задач и опросу статуса. Начните с OdiRouter Quick Start, затем используйте актуальную документацию как контракт для выбранной модели.
Начните с контракта задания
Определите задание до выбора модели. Зафиксируйте расположение исходного видео, цель преобразования, идентификатор модели, отправленные параметры и идентификатор корреляции, принадлежащий вашему приложению. Храните входные данные и окончательный результат в одной записи. Если запуск завершается ошибкой или даёт неожиданный результат, эта запись предоставляет конкретные данные для проверки.
Не принимайте неопределённый вход с названием «видео». Установите правила, необходимые вашему продукту, например ссылку на файл, ограничение длительности, политику в отношении аудио или требование согласия. Отклоняйте входные данные, не соответствующие этим правилам, до их передачи провайдеру генерации.
Настройте OdiRouter до запуска производственного трафика
В Quick Start описано создание API-ключа и пополнение баланса перед использованием в production-среде. multimodal setup guide описывает базовый URL, конечную точку и заголовки аутентификации для мультимодальных вызовов. Не допускайте попадания учетных данных в исходные медиафайлы, записи задач и журналы на стороне клиента.
Проверьте актуальный OdiRouter model catalog перед выбором модели. В настоящее время на страницах с описанием моделей указаны wan2.7-videoedit и happyhorse-1.0-video-edit. Однако это не делает ни одну из моделей подходящей для всех преобразований. Перед отправкой запросов в рабочую среду ознакомьтесь с текущей страницей с подробной информацией.
Отправьте один раз и сохраните идентификатор задачи
Код ошибки task-submission guide указывает на необходимость создания многомодальной задачи и сохранения идентификатора запроса и URL-адреса для последующих операций. Сохраните этот идентификатор вместе с идентификатором корреляции, идентификатором модели, нормализованными параметрами, ссылкой на входные данные и временем создания.
Сделайте поведение при повторных попытках осознанным. Если у клиента истекает время ожидания после отправки запроса, сначала найдите задачу по сохранённому идентификатору. Повторная отправка задания без проверки может создать дублирующую работу и оставить пользователя с несколькими правдоподобными результатами. Ваше приложение должно различать запрос, который так и не покинул клиент, принятую задачу и задачу, результат которой уже готов.
Опрос статуса как переход между состояниями
status-polling guide различает состояния ожидания, завершения и ошибки. Выполняйте опрос с ограниченным интервалом и прекращайте его при достижении конечного состояния. Установите для задачи дедлайн на уровне приложения, чтобы запуск, остающийся вне конечного состояния, попадал в очередь на проверку, а не исчезал из поля зрения.
Принятие не означает доставку. Переводите задание к проверке результата только после конечного состояния успеха. При конечной ошибке сохраняйте идентификатор задачи, сведения о модели и параметрах, а также безопасный контекст ошибки для повторной попытки или расследования службой поддержки.
Проверяйте возвращённое видео перед доставкой
После завершения проверьте результат на соответствие контракту, который вы составили вначале. Убедитесь, что ваша система может получить ссылку на результат, что тип медиа подходит для следующего шага и что результат по-прежнему связан с предназначенными для него входными данными и задачей. Если требуется проверка рабочего процесса, разместите ее после технической проверки и перед действиями по публикации или обмену информацией, доступными для пользователей.
Сохраняйте небольшую неизменяемую запись для каждого принятого результата. Полезные поля включают ссылку на входные данные, идентификатор задачи, выбранную модель, отправленные параметры, время завершения, ссылку на результат и итог проверки. Не следует размещать в этой записи ключи API или конфиденциальные данные исходного видео.
Обеспечьте воспроизводимость выбора модели.
Видеомодели и параметры меняются. Сохраняйте идентификатор модели и фактические значения параметров для каждого запуска, а при планировании следующей интеграции сверяйтесь с текущим каталогом. Эта запись позволяет сравнивать результаты запусков, не гадая, откуда взялось различие: из-за входных данных, параметра или выбранной модели.
Для нового сценария использования создайте небольшой тестовый набор из входных данных, которые вам разрешено использовать. До запуска решите, что именно будете проверять. Можно проверить, произошло ли запрошенное преобразование, поступает ли результат в следующую систему и соответствует ли он вашей внутренней политике проверки. Это проверяет вашу интеграцию. Это не является широким утверждением о качестве модели.
Встройте согласие и проверку в рабочий процесс
Преобразование видео может затрагивать людей, голоса, бренды и конфиденциальные контексты. Собирайте только те разрешения, которые необходимы вашему рабочему процессу, ограничивайте круг лиц, которые могут отправлять или получать исходные медиафайлы, и сохраняйте путь проверки для материалов, которые не следует доставлять автоматически. Технически корректный API-запрос не отменяет этих обязанностей по отношению к продукту.
Следующий шаг
Создайте небольшую тестовую задачу из OdiRouter Quick Start, изучите multimodal setup и выберите актуальную модель из OdiRouter catalog. Затем реализуйте отправку задач и опрос их статуса, используя текущую документацию как источник истины для контракта этой модели.