Видео на Спектруме. Реально?

(C) Vitamin/CAIG/2001

Если вы читаете данную статью, значит уже успели заглянуть на сайт zxvideo.fatal.ru, по заказу автора которого и была написана данная статья, и убедиться, что вопрос, вынесенный в заголовок имеет вполне однозначный ответ - да, реально. Уровень качества реализации, как вы сами понимаете, вопрос отдельный. Специфика аппаратной части спектрума диктует нам свои условия, обойти которые мы не можем без потери совместимости и головной боли. Это, в первую очередь, графическая часть - экран, имеющий разрешение 256х192 при 16 цветах, но с достаточно ограниченным диапазоном применения цвета. Также это и достаточно маленький (по современным меркам, разумеется, да и то смотря с какой стороны...) объем памяти. В довесок это еще и медленные устройства хранения информации (система, в которой процессор занят передачей данных не может работать быстро). А нетривиальная задача создания видеопоследовательности ставит достаточно жесткие рамки для всех составляющих платформы. Но не все так печально - малое разрешение экрана требует меньше памяти для хранения картинки (плюс к этому достаточно специфичное строение экрана), малый объем памяти заставляет упорно работать над сокращением программ и уменьшением объема данных, живя под девизом "Ни байта врагу!" :) Различные примочки типа DMA позволяют обойти последний препон - низкую скорость работы накопителей. Но в дальнейшем мы рассматривать такие аппаратные решения не будем.

Возвращаясь к теме видео. Существует достаточно много способов хранения видео в памяти компьютера. Они различаются по степени сжатия, по скорости упаковки и воспроизведения. Перечислю несколько пришедших на ум методов:
-хранение экранов целиком: никакого выигрыша в размере мы не по- лучаем. Взамен этого имеем дикую избыточность и малое число кад- ров, которые удается одновременно вщемить в далеко не резиновую память. Да и скорость вывода достаточно низкая- приблизительно 25 кадров в секунду.
-хранение экранов, сжатых по отдельности каким-либо упаковщиком картинок. Выигрыш будет колебаться в пределах 10...60% и зави- сеть от характера изображения и его сложности. Недостаток- низ- кая скорость распаковки, приблизительно до 7fps (это для быстрых распаковщиков).
-хранение черезстрочных экранов. Данный метод с успехом приме- нялся в некоторых демках. Там осуществлялось чтение напрямую с диска на экран самым быстрым из возможных способов. Скорость вы- вода- до 7fps. На диск влезает 212 кадров, что составляет около 35 секунд.
-различные вариации предыдущего метода- вывод 1/3 и 2/3 экрана. Параметры пропорциональны размеру кадра.
-чанковое видео. В самом лучшем случае один кадр будет занимать 1.5 килобайта. Достаточно большие затраты процессорного времени для вывода текстур на экран. Также применялся в некоторых дем- ках, воспроизводя данные как из памяти, так и напрямую с диска.
-чанковое видео с удалением избыточности. В простейшем случае, данные каждого кадра подвергаются сжатию без потерь, используя какой-либо алгоритм. Иногда можно достичь достаточно больших степеней сжатия, но увеличиваются затраты на декодирование кад- ра.
-другие способы (атрибутное видео, спрайты и т.д)

Теперь я, пожалуй, расскажу вам о своих наработках в области сжатия видео. Я намеренно не упомянул еще один вариант сжатия- полноэкранные картинки с высоким качеством и скоростью вывода до 50fps, причем в стандартные 128 килобайт можно вместить не 18 кадров, а 18 секунд видео. А как это?! Ведь даже самый простой подсчет показывает, что один кадр занимает ровно 6 килобайт па- мяти и в 128 килобайт их влезет именно 18, ну может на пару больше, но никак не под сотню, да еще с такой скоростью вывода!

Весь секрет заключается в том, что идущие подряд кадры обла- дают довольно большой избыточностью- практически все изображе- ния, за исключением некоторых деталей, повторяется. Так зачем же тратить драгоценную память на эти никому не нужные повторы? И тут уже в голове формируется алгоритм- сравнивать кадры попарно и на выход подавать только существенную информацию, а остальное отбрасывать. При воспроизведении на экран будут выводиться также только измененные части. Конечно, никакого попиксельного соот- ветствия быть не может (хотя это вполне даже возможно, вопрос только зачем?). Но нам это и не надо. Выигрыш в размере файла и скорости воспроизведения с лихвой перевешивает всякие огрехи и неточности, уровень которых тем более можно регулировать.

А теперь можно и перейти к более подробному описанию алгорит- ма.
1) сначала изображение разбивается на равные части, в пределах которых и будет производиться сравнение (в нашем случае это зна- коместа 8х8 пикселов, благо строение экрана позволяет).
2) далее производится вычисление разницы между текущим и преды- дущим кадрами. В простейшем случае (как ни странно, он является и наиболее подходящим), считается побитовая разность двух экра- нов и подсчет несовпавших пикселов в каждом знакоместе.(*)
3) пусть у нас есть некий критерий, указывающий предельно допус- тимый уровень потерь при сжатии. Очевидно, что он будет обратно пропорционален качеству видео и прямо пропорционален размеру итогового файла. Этот критерий определяет, какие знакоместа бу- дут переданы на выход, а какие нет. В нашем случае, не превышает ли количество несовпавших пикселов в знакоместе некий порог, яв- ляющийся этим критерием.
4) на этом шаге у нас получен набор знакомест, которые надо со- хранить для последующего восстановления при воспроизведении. Обычно, они будут разбросаны по всему экрану, группируясь вокруг сильно изменяющихся или подвижных объектов. Встает вопрос о фор- мате, в котором будет храниться информация о каждом знакоместе. Самый простой способ- хранить координаты и непосредственно дан- ные каждого такого знакоместа. Но, как показали мои исследова- ния, такой способ годится лишь для малоизменяющихся последова- тельностей, в которых знакоместа разбросаны по всему экрану. Другим, более оптимальным способом, является построчное сканиро- вание каждой строки знакомест и занесение информации о расстоя- ниях между соседними измененными знакоместами и из данных.(**)
5) на этом цикл повторяется до тех пор, пока у нас не закончатся входные файлы.

Примечания.

(*)- если кадр у нас первый, ясно, что сравнивать его не с чем. Поэтому его нужно сделать ключевым- сжать с минимально возможны- ми потерями и поместить в выходной поток.
(**)- здесь тоже можно применить ряд хитростей, позволяющих по- лучить довольно серъезный выигрыш в размере итогового файла.
-если число измененных знакомест велико, выгоднее будет сделать этот кадр также ключевым (см. пред. примечание).
-если идет подряд несколько измененных знакомест, выгодно хра- нить их группой, так как в этом случае не нужно указывать одина- ковые единичные расстояния между этими знакоместами.
-возможна дополнительная обработка на этапе представления экрана в виде индексов измененности знакомест, например, исправление одиночных измененных или неизмененных знакомест- LQ Filter в VideoStudio (далее я буду давать ссылки на свою программу, так как все вышесказанное там уже реализовано), взвешенный фильтр над индексами, позволяющий "предсказывать" изменения в малопод- вижных последовательностях- HQ Filter.
-возможно сжатие знакомест, т.е. непосредственно графической ин- формации, которую нам надо сохранить. С этим работает метод BitPack, специально разработанный для этой цели.
-для малоподвижных последовательностей возможно сжатие не непос- редственно измененного знакоместа, а его побитовой разности меж- ду тем же знакоместом предыдущего кадра. Методом сжатия может служить тот же BitPack, в данном контексте именуемый DeltaPack.
-над исходным изображением возможно проведение некоторых косме- тических изменений, как с целью имитации какого-либо эффекта, так и с целью улучшить сжатие и сгладить погрешности сжатия (фильтры контраста/яркости, линейные фильтры, пороговый фильтр и другое).

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

Snail: 347924, Россия, г.Таганрог, Рост.обл, ул.С.Лазо,
д.7, кв.54 Гаврилову Виталию Дмитриевичу.
Тел: (8634)375116 (19 - 23 MSD)
Mobil: 8928 6158129
e-mail: vitamin_caig@mail.ru