Скопировано с сайта zxvideo.fatal.ru по просьбе его автора Видео на спектруме. Реально? (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 Если вы послали мне письмо, а я не ответил, значит проблемы с почтой, потому как я обычно отвечаю на все письма.