Решил начать делиться рабочими моментами, происходящими в очередном проекте, которым я довольно плотно занимаюсь уже некоторое время, но о котором пока не могу рассказать. Анонс случится когда-нибудь в этом году.

Проект включает создание нового оригинального ретро-видеокодека, похожего на кодеки видеороликов в играх 1990-х годов, до повсеместного внедрения MJPEG/MPEG сжатия. То есть Cinepak-подобный кодек со статистическим сжатием.

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

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

Всё это, однако, основано на библиотеке ExoQuant родом из 2004 года, со злой математикой, которую я не вполне осиливаю в деталях (понимаю общую идею), и от которой многое зависит. Библиотека формирует оптимальную индексированную палитру методом рекурсивного деления цветовых кубов, что бы это ни значило, а также маппит изображение на заданную палитру, то есть переводит RGB в индексированный цвет, с поддержкой нескольких алгоритмов дитеринга.

Как оказалось, для 2004 года этот код поразительно медленно работает. Один кадр в итоге конвертируется в индексированный цвет дольше одной секунды, а для кодирования видеопотока это катастрофа — примерное соотношение скоростей получается 1 секунда видео к 15 секундам кодирования. Или, если угодно, 1 час видео кодируется 15 часов реального времени, и это на i5 3.5 ГГц.

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

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

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