Кодек MJPEG

Идея этого метода кодирования достаточно проста: каждый кадр кодируется независимо от остальных, кадры сжимаются алгоритмом с потерями типа JPEG (который так широко используется для сжатия фотографий). Существует несколько реализаций алгоритма, в том числе и аппаратные: так, карта захвата Pinnacle Studio DC10+ выдаёт поток в формате MJPEG. Из программных реализаций наиболее распространены кодеки от Morgan Multimedia и Pegasus Imaging Corp. Кодек от Morgan специалисты не жалуют: и качество изображения у него похуже, и совместимость (не умеет декодировать некоторые MJPEG файлы). Кодек от Pegasus (PICVideo MJPEG) наоборот — очень популярен. Практически у него есть одна настройка: уровень качества (от 1 до 20). При захвате видео с целью получения максимального качества как правило используется уровень 19, поток данных при этом получается 5–7 Мбайт/сек (17–25 Гбайт/час). При этом видео с размером кадра 768x576 можно захватывать на процессоре 450 МГц.

Использовать самый большой уровень качества нет смысла: поток данных получается 12–17 Мбайт/сек (40–60 Гбайт/час) — это больше, чем HuffYUV. При этом MJPEG сжимает с потерями, а HuffYUV — без потерь. Да и требования к процессору в таком режиме получаются побольше, чем у HuffYUV.

Вы можете использовать и меньшие значения уровня качества — при этом и поток данных, и загрузка процессора будут меньше. Но уже при уровне 18 артефакты сжатия становятся заметны на глаз: случайный шум в ТВ программах иногда вырождается в регулярные узоры (муар). При уровне 17 муар становятся постоянными.

Кстати, VirtualDub содержит встроенный декодер формата MJPEG. Специалисты, правда, настоятельно рекомендуют не использовать его, а установить в систему кодек от Morgan или Pegasus.

Pegasus недавно выпустили новую версию своего кодека: PICVideo MJPEG 3. Среди прочих новшеств этот кодек содержит пост-процессинг при декодировании видео: по аналогии с MPEG?4 декодерами. Это позволит использовать более высокие степени сжатия видео при сохранении приблизительно такого же визуального качества изображения.

MPEG–1, MPEG–2

Мне не известны качественные MPEG–1 или MPEG–2 кодеры со стандартным DirectShow или V4W интерфейсом, которые бы можно было установить в систему и использовать из всех программ по работе с видео. Потому ниже пойдёт речь про MPEG кодеры, которые встроены в программное обеспечение карты захвата — как правило они позволяют сохранять видео в формате MPEG–1 и MPEG–2. Также более дорогие карты захвата имеют встроенные MPEG-кодеры, они способны проводить сжатие видео «на лету» аппаратно, передавая системе для записи уже готовый MPEG поток.

Стандарт MPEG–1 предусматривает потоки данных до 1,5 Мбит/сек для видео (лишь 188 Кбайт/сек) при разрешении до 384x288 — потому его не разумно применять для захвата видео в виду исключительно низкого качества. На практике, правда, некоторые программы захвата игнорируют эти ограничения и способны создавать MPEG-1 потоки с большими размером кадра и шириной потока данных: AverTV из комплекта поставки карты Aver203 может создать MPEG-1 видео с потоком вплоть до 20 Мбит/сек (2,5 Мбайт/сек, 9 Гбайт/час) и размером кадра 768x576. Полученный файл, конечно, не соответствует стандартам — однако VirtualDub вполне в состоянии его прочитать.

Формат MPEG-2 формально имеет ограничение в 40 Мбит/сек, однако конкретные программные реализации MPEG-2 кодеров как правило ограничены ещё меньшими потоками. Упомянутый выше AverTV ограничен 20 Мбитами/сек, ATI Multimedia Center имеет ограничение в 15 Мбит/сек (2 Мбайта/сек, 7 Гбайт/час). Учтите, что VirtualDub не в состоянии читать файлы MPEG-2. VirtualDubMod имеет дополнительную надстройку, которая позволяет открывать ему файлы с MPEG-2 видео.

Во время захвата видео кодеры MPEG-1 и MPEG-2 кодируют видео в режиме с постоянным потоком данных (CBR) и с постоянным видом группы кадров (GOP). Как было сказано в разделе «Поток данных (bitrate)» — это не оптимальный режим для метода сжатия с потерями. Группу кадров лучше сделать достаточно короткой (3-5 кадров), двунаправленные кадры не использовать вовсе (см. также раздел «Группы кадров»). Вы можете даже использовать только ключевые кадры — кодер будет работать в режиме, подобном MJPEG. Однако, специалисты указывают на то, что иногда кодеры даже при больших потоках данных допускают артефакты, особенно это заметно для цветовой составляющей (см. Видеокарты от ATI с видевходом: Лучшие возможности для оцифровки видеозаписей).

MPEG-4

Использовать MPEG-4 кодеры при захвате видео практически бессмысленно: DivX 5.1.1 в режиме 1-pass quality based (fastest, quality: 1, max keyframe interval: 1) создаёт поток такой же ширины, как и PICVideo MJPEG с качеством 19, при этом потребляет втрое больше мощности процессора. Возможно, в каких-то компромиссных вариантах — с низким качеством, небольшим размером кадра — DivX и можно использовать. Но в любом случае, он потребляет уйму вычислительных ресурсов. Если вы собираетесь сжимать в DivX видео с размером кадра 768x576 «на лету» — запаситесь процессором как минимум в 2ГГц. Очевидно, что с XviD ситуация аналогичная.

DV

Цифровые камеры используют свой формат сжатия видеозаписей — DV (Digital Video). Технически он схож с MJPEG, но не совместим с ним. Формат DV содержит дополнительные возможности, как то: наложение титров (удобно для видеокамер: подпись к записи записывается отдельно изображения, а не поверх него), специальный способ синхронизации аудио и видео информации. Поток данных DV имеет постоянную ширину: 3,6 Мбайт/сек (12,5 Гбайт/час).

Существует несколько программных кодеков формата DV, более того: DirectX 6 и новее стандартно содержат DV кодек — правда он поддерживает только DirectShow интерфейс (соответственно VirtualDub не в состоянии его использовать). Тем не менее специалисты рекомендуют использовать кодек от MainConcept: он обеспечивает корректную цветопередачу, более высокое качество изображения, а также менее ресурсоёмок. На сайте доступна демонстрационная версия, полная версия стоит $49. Декодер от Cannopus поддерживает только декодирование. Также в интернете можно найти кодек от Panasonic: судя по всему он какое-то время назад был доступен на японском сайте компании, потом его убрали — но добрые люди успели его скопировать.

Мне неизвестно, какой из этих кодеков лучше и почему — я совсем мало имею дела с цифровыми камерами и DV. За информацией по работе с DV рекомендую обратиться к сайту М. Афанасенкова или к FAQ по созданию и редактированию цифрового видео.