В последнее время только ленивый, похоже, не пишет собственные CD. Среди самых разных направлений использования этих темно-синих "блюдец" выделяются, пожалуй, два. Про первое я и говорить не буду, это слив всякого софта не первой свежести (потому как взломанного...) на дешевые болванки (в Москве свободно можно найти цены 40 рублей плюс-минус пять, и это не в подвале, который завтра исчезнет с продавцом вместе, а в нормальном компьютерном салоне), - речь пойдет о втором.
Всякие сейшены, свадьбы и тусовки, оккупировавшие вашу домашнюю свалку видеокассет, только и ждут того, чтобы оказаться на изящных пластинках навеки, либо - в одночасье рухнуть вместе с полкой на вашу же голову...
Итак, вы уже знаете, чего хотите добиться. Давайте вместе напишем лозунг: час видео на сидюке. Ниже будут рассмотрены программы сжатия (кодеки), наиболее "модные" сейчас и не только.
В качестве примера я взял запись, полученную захватом платой ELSA Victory Erazor сигнала, воспроизведенного бытовым видеомагнитофоном (в свою очередь, видак писал с бытового же телевизора). Для сохранения приемлемого размера файлов снимки пришлось немного сжать программой Ulead SmartSaver в формат JPEG, но при этом особенности, на которые стоит обратить внимание, были сохранены.
Сравнение проводилось среди кодеков MPEG4 двух версий, оба произведены в Microsoft, VDOwave корпорации VDOnet, Intel Indeo 5.06 и (в качестве эталонного изображения) MainConcept M-JPEG. Фрагмент клипа, сжатый в процессе захвата в формат M-JPEG, сжимался разными кодеками и результат изучался на предмет выявления потерь качества.
Поскольку понятие качества весьма субьективно, я решил просто остановиться на наиболее характерных свойствах каждого из кодеков, полагая, что вам дальнейший выбор придется сделать самостоятельно.
original M-JPEG
Исходный материал: 352x288 24 бит, 24 кадра в секунду, поток около 7.3 Мб/сек, размер клипа 8м:32с более 3 Гб, сжатие порядка 9:1, сжатый клип занимает 402 Мб (аудио 32 кГц 16 бит моно). Неплохо, но великоват...
Для оценки качества обратите внимание на прямолинейность лучей света прожектора в левой части кадра и радиальные блики на макете CD-ROM в правой части кадра.
MPEG4 1200kb
Клип сжат кодеком MPEG-4 V3 от пакета Windows Media Tools Майкрософт с потоком 1200 килобит/с или 150 кбайт/с, аудио - ADPCM. Размер клипа 87 мегабайт. Забегая вперед, можно сказать, что это и есть победитель. Не только по размеру клипа, но по сумме показателей.
На этом кадре заметно размывание лучей слева и размазывание бликов на правом CD. Кроме того, на светлых участках стала заметна легкая рябь из прямоугольников (о них речь еще впереди).
MPEG4 512kb
Пойдем далее, уменьшим поток до 512 килобит/с. Налицо дальнейшая деградация качества. Радиальных бликов не осталось, изображение в целом стало заметно менее резким. Хм... зато всего 64 кбайт/с без учета аудио. Здесь, пожалуй, стоит остановиться и отметить, что доля аудио в суммарном обьеме клипа стала весьма заметна по сравнению с видео и оставлять звук без сжатия было бы опрометчиво.
MPEG4 256kb
Это тот предел качества (причем в лучшую сторону), который был достижим при использовании старого кодека Майкрософт, входившего в состав MS NetShow Tools. Обратите внимание на форму лучей прожектора в левой части кадра. Это уже далеко не прямые линии...
Немного прервемся и заглянем внутрь кодеков MPEG-4. Кадр разбивается на квадратики 8x8 пикселов и для них путем несложных математических преобразований находится "среднее" значение яркости и величины "пульсаций" около этого среднего значения, которые образуют детали картинки внутри этой квадратной области. Примерно то же происходит и с цветностью, только учитывая сравнительно низкую чувствительность глаза к цветовым переходам, используют вдвое или вчетворо меньше отсчетов, чем для яркости. После этого полученные числа делят на определенный коэффициент, из-за чего часть из них становятся нулевыми. Это и требуется для эффективного сжатия. Конечно, чтобы сжать видео еще сильнее, можно хранить не кадр целиком, а только его изменившуюся часть. В принципе, так же работают кодеки и более ранних версий MPEG, 1 и 2, с учетом их менее мощных алгоритмов сжатия.
Зачем это вам ? Да тут все просто... Если кодеку сказано сжать поток видеоданных до определенного размера, он сожмет. Но вот какой ценой ? [
Сначала ухудшается качество резких тонких линий. Кодек пытается обнулить побольше коэффициентов малой величины. Далее повышается содержание прямоугольных переливающихся близкими оттенками областей на сжатом изображении, что при просмотре смахивает на вид из окна, когда на улице ливень. Что сделает кодек дальше ? Будут выброшены кадры, которые оказались чересчур похожи на соседние, что на взгляд воспринимается как утрата плавности движения. Клип все больше становится похож на слайд-шоу.
Здесь, кстати, уместно напомнить о таком противоречии: можно оцифровать видео в низком разрешении, но при сжатии до заданного обьема кодек не сильно изуродует клип, поскольку ему хватает пропускной способности. И воспроизвести с масштабированием 2:1. Будет неплохо (если видеоплата не S3Trio64...)
И, напротив, можно оцифровать клип высокого разрешения, но для сжатия в тот же обьем кодек будет должен жертвовать качеством. Вашим качеством. Другими словами, вчетверо больший по площади размер кадра потребует более сильного сжатия, чем меньший, и что более безобидно - масштабировать маленький клип до размеров большого или регулировать сжатие - решать вам...
Для сравнения далее посмотрим на кодеки Indeo и VDOwave. В общем-то, особо и сравнивать-то нечего... Алгоритм один и тот же, wavelet-компрессия. Что происходит - видно, тотальное снижение резкости. Если вы полагаете, что я ругаюсь, не угадали. Есть сюжеты, которые смотрятся лучше именно в таком "мягком" исполнении. Один нюанс, - в варианте VDO размер клипа значительно меньше...
VDO 256kbit
Один недостаток - все волосяные покровы зайца превратились непонятно во что...
MPEG4 256kbit
старый знакомый, старые проблемы - прямоугольнички :(
Indeo 5.06
Да, сначала я тоже думал, что это VDO. Нет, размер ролика не дает усомниться...
orig. MJPEG
Без комментариев. Исходный вариант клипа.
Немного о сжатии аудиосигнала.
Если вы полагаете, что сжать клип, например, кодеком MPEG, а звуковой поток кодеком IMADPCM - круто, вы недалеки от истины. Только вот кто его сможет проиграть ? На моих тестах загрузка процессора PII333 составляла до 60 процентов при воспроизведении весьма средненького по качеству видео. Другое дело, связь некоторых кодеков между собой, мешающая сделать желаемый выбор... Например, Darim Vision - DVMPEG, естественно, сжатие звука влечет за собой и необходимость для видео использовать их же мпег :( А я не хочу. Кстати, вот ответ на напрашивающийся вопрос, почему же не сжимать в .MPG - все просто. Качество MPEG1-MPEG2, обеспечиваемое на той же скорости потока данных, что MPEG4, существенно ниже (Попробуйте!), а при субьективно равном качестве последний дает файлы заметно меньшего размера. И, вдогонку, качество ADPCM заметно выше качества, обеспечиваемого тем же L3Pro (создающим под Windows файлы .wav с сжатым по технологии MPEG layer 3 звуком) при сравнимых размерах.
Итак, если я вас окончательно запутал, отправляйтесь цифровать ваши кассеты. Полка уже потрескивает...
Какую же цель я преследовал этой статьей ? Пожалуй, больше вопросов возникло, чем решилось. С другой стороны, сообща мы их быстрее одолеем... Для размышлений приведу размеры файлов полученных клипов. Поиграйте с калькулятором, это занимательно.
драйвера - 85137
Обсудить статью на форуме
Версия для печати