Автор: Виталий Гаврилов / Vitamin.

Рубрика: В помощь разработчику.

Номер: №21 (14.10.2004).

---

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

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

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

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

- хранение экранов, сжатых по отдельности каким-либо упаковщиком картинок. Выигрыш будет колебаться в пределах 10...60% и зависеть от характера изображения и его сложности. Недостаток - низкая скорость распаковки, приблизительно до 7 fps (это для быстрых распаковщиков).

- хранение черезстрочных экранов. Данный метод с успехом применялся в некоторых демках. Там осуществлялось чтение напрямую с диска на экран самым быстрым из возможных способов. Скорость вывода - до 7 fps. На диск влезает 212 кадров, что составляет около 35 секунд.

- различные вариации предыдущего метода - вывод 1/3 и 2/3 экрана. Параметры пропорциональны размеру кадра.

- чанковое видео. В самом лучшем случае один кадр будет занимать 1.5 килобайта. Достаточно большие затраты процессорного времени для вывода текстур на экран. Также применялся в некоторых демках, воспроизводя данные как из памяти, так и напрямую с диска.

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

- другие способы (атрибутное видео, спрайты и т.д).

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

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

А теперь можно и перейти к более подробному описанию алгоритма.

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

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

3) пусть у нас есть некий критерий, указывающий предельно допустимый уровень потерь при сжатии. Очевидно, что он будет обратно пропорционален качеству видео и прямо пропорционален размеру итогового файла. Этот критерий определяет, какие знакоместа будут переданы на выход, а какие нет. В нашем случае, не превышает ли количество несовпавших пикселов в знакоместе некий порог, являющийся этим критерием.

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

5) на этом цикл повторяется до тех пор, пока у нас не закончатся входные файлы.

Примечания.

(*) - если кадр у нас первый, ясно, что сравнивать его не с чем. Поэтому его нужно сделать ключевым - сжать с минимально возможными потерями и поместить в выходной поток.

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

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

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

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

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

- для малоподвижных последовательностей возможно сжатие не непосредственно измененного знакоместа, а его побитовой разности между тем же знакоместом предыдущего кадра. Методом сжатия может служить тот же BitPack, в данном контексте именуемый DeltaPack.

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

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

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

Если вы послали мне письмо, а я не ответил, значит проблемы с почтой, потому как я обычно отвечаю на все письма.

P.S. Статья написана по заказу автора сайта zxvideo.fatal.ru.