Вместо введения
Относительно недавно я познакомился с ComfyUI. После не очень продолжительных танцев с бубном и установки кастомных ROCm‑драйверов для моей видеокарты (официальная поддержка начинается только с AMD RX7600) я столкнулся с проблемой генерации видео.
Если быть точнее, единственное, что я мог себе позволить для полноценного вычисления с помощью видеокарты, — это модель wan2.2_ti2v_5B. Но она работала очень нестабильно: не слушалась промптов и выдавала артефакты.
Квантование и выбор модели
Я начал более детально изучать информацию и узнал о такой вещи, как квантование, с помощью которого можно уменьшить размер модели. Вследствие этого зарезаются и её возможности, но, как многие отмечали, не в линейной зависимости.
Чем я и воспользовался. Я нашёл GGUF‑модель Wan2.2-I2V‑A14B с квантованием Q4_K_M, которая подошла мне по размеру и, как писали на форумах, показывает результаты намного лучше, чем wan2.2_ti2v_5B. Это, ко всему прочему, может обуславливаться тем, что помимо более сложной структуры генерация производится в два этапа: high и low noise. Первая генерирует основную композицию, а вторая — детали.
Также я использовал с данной моделью LoRA‑ускоритель lightx2v_4steps, что позволило получать удовлетворительный результат уже на 4 шагах. Это сильно сократило время генерации. Это решение мне ещё аукнется, но об этом позже.
Оптимизация железа
Затем я произвёл небольшую оптимизацию железа, а именно установил новый SSD, на который разместил все модели и файл подкачки. Последний, между прочим, дал довольно неожиданный прирост к скорости. Оперативной памяти у меня 32 ГБ, и её всегда хватало с запасом, но как только я разместил файл подкачки на SSD, оптимальное количество кадров для генерации видео разрешения 480×480 поднялось с 39 до 53.
Но данное количество кадров меня всё равно не устраивало, да и при переходе на разрешение 720×720 количество доступных генерируемых кадров резко падало. Также я хочу отметить, что даже при возможности использовать максимальный функционал данной модели больше 81 кадра за раз сформировать всё равно не получится.
Поиск решения: почему просто склеить не получится
После этого я начал думать, как последовательно генерировать видео.
Первая идея была подкидывать последний кадр как референс первого. Но эта идея была провальна, так как не сохранялась информация о предыдущих кадрах, и движения получались рваные и несогласованные.
Затем я начал искать какие‑нибудь готовые решения, но все они были заключены в одну большую ноду, к которой подключались все модели одновременно, что приводило к переполнению памяти. Такие варианты были нежизнеспособны. Мне нужен был какой‑нибудь более тонкий механизм для настройки оптимизации.
Нода Wan First‑Middle‑Last Frame to Video
В итоге после длительных изысканий я наткнулся на ноду Wan First‑Middle‑Last Frame to Video из пакета Wan22FMLF. Она умеет подготавливать данные для генерации видео по трём ключевым кадрам и с возможностью выбирать положение среднего кадра.
И тут у меня и зародилась идея о генерации нового видео по двум ключевым кадрам, взятым из предыдущего. Первый взят откуда‑то из середины предыдущего, а средний — с его конца. После генерации нам останется только подрезать пересекающиеся кадры для исключения несогласованности и объединить последний кадр с ключевым кадром из середины нового видео, которые не должны отличаться.
Единственное условие: индекс кадра среднего видео должен быть кратен четырём, так как это длина генерируемого сегмента моделью. Не номер строки, а именно индекс — индексы у нас начинаются с нуля.
Схема механизма
После данных операций у нас получается одно длинное видео, кадры между которому согласованы. Самый лучший результат я получил при перекрытии 12 кадров, но в сильно динамичных сценах лучше использовать 8.
Этот механизм можно масштабировать до бесконечности. И при увеличении сегментов время обработки растёт линейно.
Минусы, с которыми пришлось смириться
Пересвет среднего кадра
Первый и самый яркий минус, с которым я столкнулся, — это пересвет среднего кадра. Средний кадр как будто высветлялся и тянул за собой соседние. Этот эффект получилось довольно неплохо устранить за счёт настройки шума среднего кадра и увеличения перекрытия. Но полностью побороть его не получилось: в некоторых сценах он немного бьёт по глазам.
В целом на постпродакшене можно вручную поправить экспозицию и убрать засвет — ничего критичного в этом я не вижу. Чуть позже я выяснил, что этот эффект появляется из‑за lightx2v_4steps, но избавляться от него не стал, так как без него генерация видео будет длиться в 5 раз дольше.
Потеря деталей
Вторая проблема — это потеря деталей при переходе от секции к секции. В частности, если на первом и среднем кадре чего‑то нет, что было в начальном видео, скорее всего, его мы больше не увидим.
Результаты времени генерации
Разрешение | Кадров | Генераций | Время | Оверлей |
|---|---|---|---|---|
480×480 | 52 | 1 | 6 мин | — |
480×480 | 132 | 3 | 18 мин | 12 кадров |
480×832 | 132 | 3 | 30 мин | 12 кадров |
Пример сгенерированного видео
Заключение
На этом я закончу свой монолог. Надеюсь, данная статья была для вас полезна. Ниже приложу рабочий процесс с готовой реализацией данного механизма.
