В своих прошлых статьях «Три пути к 4K» и «Нейросетевой апскейлинг дома» я рассказывал о выборе софта, базовых принципах нейросетевого апскейлинга и реставрации исходников уровня DVD и VHS. Но время идёт, навыки растут, и вот от простого (кусок дерева -> игрушка) мы переходим к сложному (игрушка -> коллекционная фигурка), а именно на территорию 720p–1080p исходников, Blu-ray и вебки.

И именно здесь для меня началось то, что я назвал «долиной отчаяния».

Вы берёте отличный исходник, выбираете крутую open-source модель, запускаете рендер… и всегда получаете что-то странное на выходе. Цвета поплыли, контраст упал, на градиентах неба появились какие-то искажённые линии, а ваш FPS в процессе ужасен. Кажется, что ПО сломано, а ИИ-модели взбесились и вместо «качественного апскейла» портят картинку.

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

Введение

Прежде чем мы начнём разбор полётов, нужно понять, почему в целом привычный инструментарий при переходе на 720p–1080p начинает вести себя иначе.

Когда мы работали с 480p, мы брали тяжёлые 2x–4x модели, которые призваны «восстанавливать» детали. Их задача — буквально додумать и сгенерировать недостающие детали так, чтобы получившееся месиво из пикселей выглядело «адекватно» на большем экране: повышение резкости, насыщение цветов, удаление ореолов и шума и множество других операций. Но если натравить такую модель на качественный 1080p исходник, то на выходе это будет выглядеть совершенно обратно — как «деградация».

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

А чтобы обрабатывать повышенное изначальное разрешение без драматического падения скорости, мы будем использовать менее известный софт для запуска ESRGAN-моделей, не ChaiNNer, а REAL-Video-Enhancer (RVE). Это ещё более недружелюбный по UI инструмент, но самый быстрый в open-source-сегменте. Его главная фича — автоматическое использование технологии TensorRT от Nvidia: если сильно упрощать, RVE берёт модель апскейлера и оптимизирует его под вашу видеокарту и текущие параметры видео, что многократно ускоряет обработку в сравнении с аналогами, которые так не умеют делать.

Но опять же, за эту скорость приходится платить — защит от «дурака» мало, и если всё прожать «по умолчанию», результат выйдет далёким от ожиданий.

Итак, узнаем, кто же у нас украл все цвета и адекватную картинку.

1. Ловушка цветов

Начало. Вы открыли RVE, загрузили своё видео и выбрали подходящую модель с openmodeldb.info. Настройки по умолчанию, жмём «Start» — и после некоторого времени ожидания получаем первый результат.

Мдэ, тёмная область стала светлой и повсюду перенасыщенность, коей не было в оригинале.

Миф (Очевидный подход)

Вот вы порылись на форумах, узнали, что цвета могут потеряться, если не указать их для FFmpeg. В данном случае мы переводим из bt709 туда же в bt709, чтобы программа автоматически не подставила свою абракадабру и не превратила их в bt601. Пробуем открыть вкладку «Advanced» в RVE и прописываем: -color_primaries bt709 -color_trc bt709 -colorspace bt709. Снова перезапускаем рендер.

Реальность

Результат особо не поменялся — цветам всё ещё плохо.

Теория

А проблема вообще не в указанных цветовых пространствах. После долгих тестов выяснилось, что виноват RVE.

В стабильных версиях (вплоть до 2.4.1) что-то из внутреннего конвейера передачи кадров ломало цвета. Никакие жонглирования флагами или цветовыми пространствами проблему толком не решают.

Практика

Решение очень простое. Нужно отправиться на GitHub разработчика, в отдел релизов …и зайти в Tags, чтобы обнаружить там тайную новую версию 2.4.2.

Помечено пре-релизом спустя аж полгода, хотя я никаких багов не обнаружил в своих кейсах использования. В самих заметках исправление бага с цветом вынесено в одну строчку о каких-то «улучшениях потока программы».

Скачиваем, устанавливаем — ничего от себя в «Advanced» не пишем, запускаем.

Вот теперь совсем другой результат! Цвета совсем приближены к оригиналу. А если же по старой памяти туда записать какие-либо флаги-улучшалки, то цвета станут точь-в-точь такими же поплывшими, как в прошлой версии.

2. Парадокс скорости: почему NVENC — это ловушка

С цветами разобрались. Теперь стоит вернуться на шаг назад — как ускорить процесс? Казалось бы: «У меня же есть GPU-кодировщик NVENC, созданный специально для быстрой обработки видео! Если его использовать вместо штатного CPU, скорость всего рендера вырастет».

Миф

Во вкладке «Advanced» выбираем hevc_nvenc или h264_nvenc. Сейчас мы вытянем максимум скорости из всего железа.

Реальность

Вы запускаете процесс и… FPS не изменился! Так это вообще не компромисс скорости и качества, а просто «проигрыш» по всем фронтам :(

Теория

Узкое место в процессе — это вообще не кодирование финального видео. Прикол в том, как всё происходит под капотом — на самом деле это не монолитный GPU-процесс, как могло бы показаться, несмотря на все оптимизации для видеокарт.

Вот упрощённая схема того, как это происходит в деле:

1. Декодирование (CPU): процессор разбирает видео и декодирует кадр.

2. Подготовка (CPU): процессор переводит YUV в RGB.

3. Апскейл (GPU): RGB-кадр копируется из RAM в VRAM. Нейросеть отрабатывает все три канала и затем результат возвращается обратно в RAM.

4. Передача в кодировщик (CPU): готовый RGB-кадр пишется в FFmpeg.

5. Кодирование: а тут и вытекает суть подвоха. Во-первых, RGB-кадр CPU должен снова перемолотить в YUV, но уже при 4к разрешении, что более трудоёмко. Во-вторых, если 3 этап не выполняется достаточно быстро (а ESRGAN далеко не молниеносен), то никакой ускоритель на 5-м не даст выигрыша — он будет простаивать в ожидании следующего кадра от нейросети.

Практика

Исходя из логики и новоприобретённых знаний, в большинстве случаев больше профита от использования GPU-кодировщика не будет, за исключением крайне несбалансированных сборок уровня RTX 4070 + Ryzen 5 1600, где уже разумно поступиться качеством ради общей скорости.

Как отправная точка для поиска компромисса подходит вот такая конфигурация -preset veryfast -crf 5: она сохраняет практически всю информацию и не убьёт слишком сильно по весу на 4K.

Скорость рендера на современных картах среднего уровня и предтопах при апскейле 1080p -> 2160p редко превышает даже 20 fps. Любой современный HDD или SSD спокойно обработает такой поток видео. Видео будет весить значительно, но не катастрофично, а на выходе получится сырой материал при быстром рендере, который после уже можно будет качественно пережать в HandBrake или ручками через FFmpeg.

3. Иллюзия брака: почему ИИ уродует небо и откуда берутся ореолы (8 бит видео)

Скорость настроили, оригинальные цвета сохранили. Пробуем запуск… Ждём… И опять что-то не так. Артефакты, которых, казалось бы, не было в оригинале, хотя мы всё учли.

Миф

Апскейлер плохой и некачественный — разрушил идеальный градиент в сложной сцене. Нужно искать другую, более качественную модель.

Реальность

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

Теория

И вот уже в который раз нейросеть невиновна. Она всё сделала математически идеально и честно. На самом деле, она лишь проявила уже существующую проблему — бандинги (расслоение градиента), и она была в вашем исходнике изначально, особенно если мы говорим о 8-битном видео.

Большинство аниме-релизов, особенно старых, закодированы в 8-битном цвете. Если говорить простым языком — число бит определяет, сколько оттенков есть у каждого цветового канала, и нередко их не хватает даже на огромном битрейте, чтобы создать иллюзию идеального перехода цвета. Зачастую вы их не видели в оригинале по одной простой причине — относительно небольшое разрешение и затем алгоритмы сглаживания в вашем плеере их маскировали. А что делает апскейлер? На 720p–1080p качественные аниме-апскейлеры стараются никак не влиять на цвета, а вкупе с самой архитектурой апскейлера на ESRGAN он вообще может не понять, что это цветовые переходы, и добавить им тоже резкость, как и всем прочим линиям на видео.

Практика

Решение этой проблемы — не замена апскейлера, а предобработка или постобработка видео. Нужно воспользоваться программными фильтрами для устранения бандинга. Например, я зачастую пользуюсь такого вида связками в FFmpeg: deband=1thr=0.01:2thr=0.015:3thr=0.015:range=20:blur=1:coupling=1,noise=c0s=1:allf=t

Выглядит как заклинание, ну и по сути им же и является — для каждого материала желательно вручную перебирать параметры и фильтры. Что делает конкретно данная схема:

1. Deband: Ищет конкретно «ступеньки» и размывает их. Отдельные параметры 1thr, 2thr и 3thr задают порог чувствительности для канала яркости и каналов цвета.

2. Range: Определяет радиус поиска градиентов.

3. Noise: Закрепляет результат по аналогии с покрытием изделия лаком. За счёт естественного мелкозернистого шума при последующем сжатии кодек с меньшим рвением вернёт бандинг.

4. Финальный этап: Как правильно сравнить резлуьтат и не обмануться

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

Миф

Открываем видео в MPV/VLC, шорткатом вытаскиваем кадры, а затем загружаем их на какой-нибудь веб-сервис для сравнения.

Реальность

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

Теория

Тут мы встреваем в несколько ловушек разом. Проблема не в апскейлере, а в собственно инструментах сравнения. Мы сравниваем интерпретации видео, а не фактическую разницу.

Распишем пошагово:

1. Рендер плеера: Когда вы смотрите видео, плеер показывает не «сырые пиксели», а результат алгоритмов масштабирования, сглаживания и даже конвертации цветового пространства для вывода на монитор. Итоговый скриншот имеет мало общего с тем, что из себя представляет видео внутри как таковое. (Уточнение: например, в том же MPV можно достать чистый кадр через FFmpeg, если, конечно, не перепутать комбинацию клавиш — s/S, а не shift+s. Однако это не отменяет другой важный нюанс, о чём — ниже в разделе практики.)

2. Неточное извлечение кадра: Даже если использовать сырой FFmpeg — можно напортачить. При конвертации видео (YUV) в картинку (RGB) без явных инструкций FFmpeg выбирает их сам, исходя из метаданных и разумной логики (720p -> BT.709), что не всегда сходится с содержанием видео и желаемым форматом экспорта в картинку.

3. Искажения в браузере: Здесь проблема аналогична плееру — своя система отрисовки + сам сервис может пережать картинки.

В итоге вы сравниваете не «Оригинал vs Апскейл», а свою уникальную комбинацию вывода картинки по обе стороны разделительной линии сравнения. Переменных слишком много для объективных выводов.

Практика

«Правильное» сравнение состоит из двух шагов: математически точное извлечение кадров и их анализ в правильном софте.

Шаг 1: Извлечение кадров. Мы будем использовать фильтр zscale — с ним мы не угадываем параметры, а указываем их. Пример: ffmpeg -y -ss 00:00:07.174 -i "video.mkv" -vf "zscale=matrixin=709:matrix=709:rangein=limited:range=full" -frames:v 1 "output.png" Разберём, как это работает:

• -ss 00:00:07.174 — таймкод кадра.

• matrixin=709:matrix=709 — в данном случае мы указываем взять цвета из матрицы bt709 и сохранить в ней же.

• rangein=limited:range=full — видео хранится в ограниченном диапазоне (TV 16-235), а PNG, в свою очередь, работает в полном от 0 до 255. Без этого явного указания значения не растянутся и оба конца диапазона останутся пустыми — например, чёрное станет серым.

Проделываем это для оригинала и для апскейла.

Шаг 2: Сравнение. Полученные картинки нужно открывать в той среде, которая относится максимально щепетильно к изображениям.

• Графические редакторы: Krita, GIMP, Photoshop. Главный плюс: гарантия правильного отображения кадров.

• Специализированные утилиты: Именно столкнувшись на практике с проблемой любых веб-сравнивалок, я написал свой открытый инструмент — Improve-ImgSLI. Он рендерит всё локально и предлагает весь необходимый инструментарий для наших кейсов сравнения.

Выводы

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

В свою очередь, весь успех сводится к пониманию внутрянки софта и осознанному контролю всех «тайных» нюансов:

1. Заложи основу — максимально качественные цвета: чтобы не разбить все последующие старания о перенасыщенную картинку — берём пре-релизную версию RVE 2.4.2 и не шаманим над цветами в экспорте.

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

3. Источник видео тоже может быть источником «галлюцинаций»: перед тем как начать перебор моделей апскейлеров, следует дважды перепроверить оригинал.

4. Сравнение результата — не «самый лёгкий шаг» и требует педантичности: необходимо технически правильно извлечь кадры и сравнивать их локально.

Последний эшелон на пути к «простому результату» (увеличить разрешение видео быстро и качественно) достигается за счёт преодоления вечной проблемы «последней мили».

© 2026 ООО «МТ ФИНАНС»