Видео на спектруме. Реально?
(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) далее производится вычисление разницы между текущим и преды-
дущим кадрами. В простейшем случае (как ни странно, он является
и наиболее подходящим), считается побитовая разность двух экра-
нов и подсчет несовпавших пикселов в каждом знакоместе.(*)
4) пусть у нас есть некий критерий, указывающий предельно допус-
тимый уровень потерь при сжатии. Очевидно, что он будет обратно
пропорционален качеству видео и прямо пропорционален размеру
итогового файла. Этот критерий определяет, какие знакоместа бу-
дут переданы на выход, а какие нет. В нашем случае, не превышает
ли количество несовпавших пикселов в знакоместе некий порог, яв-
ляющийся этим критерием.
5) на этом шаге у нас получен набор знакомест, которые надо со-
хранить для последующего восстановления при воспроизведении.
Обычно, они будут разбросаны по всему экрану, группируясь вокруг
сильно изменяющихся или подвижных объектов. Встает вопрос о фор-
мате, в котором будет храниться информация о каждом знакоместе.
Самый простой способ- хранить координаты и непосредственно дан-
ные каждого такого знакоместа. Но, как показали мои исследова-
ния, такой способ годится лишь для малоизменяющихся последова-
тельностей, в которых знакоместа разбросаны по всему экрану.
Другим, более оптимальным способом, является построчное сканиро-
вание каждой строки знакомест и занесение информации о расстоя-
ниях между соседними измененными знакоместами и из данных.(**)
6) на этом цикл повторяется до тех пор, пока у нас не закончатся
входные файлы.
Примечания.
(*)- если кадр у нас первый, ясно, что сравнивать его не с чем.
Поэтому его нужно сделать ключевым- сжать с минимально возможны-
ми потерями и поместить в выходной поток.
(**)- здесь тоже можно применить ряд хитростей, позволяющих по-
лучить довольно серъезный выигрыш в размере итогового файла.
-если число измененных знакомест велико, выгоднее будет сделать
этот кадр также ключевым (см. пред. примечание).
-если идет подряд несколько измененных знакомест, выгодно хра-
нить их группой, так как в этом случае не нужно указывать одина-
ковые единичные расстояния между этими знакоместами.
-возможна дополнительная обработка на этапе представления экрана
в виде индексов измененности знакомест, например, исправление
одиночных измененных или неизмененных знакомест- 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
Если вы послали мне письмо, а я не ответил, значит проблемы с
почтой, потому как я обычно отвечаю на все письма.
