Захват, обработка и хранение видео с использованием ПК
- Описание задачи
- Выбор аппаратуры
- Что необходимо знать о видео сигналах
- Телевизионные стандарты
- Разрешение и чёткость изображения
- Кадры, поля и чересстрочное изображение
- Цифровое видео
- Технологический процесс
- Использованные термины и сокращения
Что необходимо знать о видеосигналах
Вам необходимо обеспечить совместимость карты захвата с источником видеосигнала по используемому способу передачи видео.
В большинстве стран мира принят один из вещательных телевизионных стандартов: NTSC (Америка и Япония), PAL (Европа) или SECAM (Франция и бывший СССР). В каждой стране продаётся видео техника, способная работать с принятым в этой стране телевизионным стандартом. Если вы используете приобретённую в другой стране технику, обязательно проверьте в документации к вашему оборудованию, что ваш источник видео сигнала и карта захвата способны работать в едином телевизионном стандарте.
Существуют также подтипы ТВ стандартов, как то: PAL–B, PAL–D, PAL–G и так далее. Они отличаются не собственно способом кодирования сигнала, а его параметрами (частотами и ширинами поддиапазонов). Карты захвата обычно способны работать с любым подтипом стандарта, нужно только указать его при настройке карты: либо указывается собственно название подтипа стандарта, либо название страны, где такой подтип стандарта принят для телевизионного вещания.
Ввиду того, что стандарты PAL и SECAM очень похожи: оба передают 25 кадров в секунду и одинаково кодируют яркостную составляющую сигнала (чёрно-белое изображение), подавляющее большинство распространённой у нас видео техники способно работать с обоими стандартами — PAL и SECAM. По этой же причине видеокамеры на нашем рынке работают в стандарте PAL: рынок в бывшем СССР не такой уж большой, чтобы разрабатывать специальную SECAM версию; а раз все наши телевизоры и видеомагнитофоны поддерживают PAL то это и не нужно.
NTSC же использует другой способ кодирования видеосигнала, в частности передаёт 30 кадров в секунду. Большинство используемой у нас видеотехники не способно работать с NTSC. Часто выпускаются две версии карт захвата: для работы с PAL/SECAM и отдельно для NTSC. Обязательно проверьте, что ваша карта захвата способна работать с вашим источником видеосигнала.
Низкочастотные блоки всех карт захвата универсальны и способны оцифровать поданный на видеовход видеосигнал любого стандарта: вам лишь нужно указать в настройках правильное значение частоты кадров (25 или 30 для NTSC). Высокочастотные блоки — ТВ-приёмники — наоборот, специфичны для каждого ТВ-стандарта. Потому ваша карта захвата сможет записывать видео из ТВ-эфира только в том стандарте (одном или нескольких), на который она рассчитана. У нас продают карты с ТВ-приёмниками стандарта PAL-D/SECAM-D, который принят в странах бывшего СССР.
Вам не нужно беспокоиться, если вы используете цифровой источник видео: цифровая камера сделает всё за вас. Единственная разница будет в том, что видео оцифрованное с NTSC сигнала будет содержать 30 кадров в секунду вместо 25.
Далее по тексту я для простоты буду считать, что в нашем видео сигнале 25 кадров в секунду. В случае если в вашем видео 30 кадров в секунду, вам лишь необходимо заменить соответствующие цифры «25» на «30», а также «50» на «60» — остальная информация остаётся в силе.
За более подробной информацией обратитесь к другим статьям, например, Телевизионные стандарты: описания, характеристика.
Разрешение и чёткость изображения
Следует различать понятия разрешение — которое является характеристикой хранилища видео сигнала в цифровом виде — и чёткость, которое описывает свойства собственно видео сигнала.
Рассмотрим такой пример: нарисуем в графическом редакторе картинку, состоящую из чередующихся белых и чёрных строк.
|
Пусть её размер по вертикали будет 10 строк. Мы можем сохранить это изображение в графический файл, имеющий 10 пикселей по вертикали. |
 |
Также мы можем сохранить это изображение в файл с 20 пикселей по вертикали… |
|
25 пикселей — и в каждом из них мы сможем увидеть лишь 10 линий: 5 белых и 5 чёрных. |
|
Если мы сохраним наше изображение в файл с 8 пикселей по вертикали, то мы сможем рассмотреть не 10 строк, а только 6: 3 белые и 3 чёрные. |
|
Если использовать 9 пикселей по вертикали, то останется только 8 строк (4 белые и 4 чёрные). |
Таким образом, на рассмотренном выше примере мы видим, что чёткость изображения (измеряется в количестве линий) не зависит от разрешения файла (измеряется в количестве пикселей), в который это изображение записано, если только разрешение не меньше чёткости изображения. Сохранение изображения в файл с разрешением меньшим, чем чёткость изображения, приводит к уменьшению чёткости. Отсюда следуют два простых правила: с одной стороны разрешение оцифрованного видео должно быть не ниже, чем чёткость исходного видео; с другой стороны не имеет смысл хранить видео с очень высоким разрешением: чёткости это не добавит, а занимать дополнительную память будет.
Чёткость видео в бытовой аппаратуре
Максимальную чёткость, которую способна обеспечить видеоаппаратура, можно измерить при помощи специальных источников сигнала: тестовых таблиц. Приблизительные значения чёткости изображения по горизонтали, которые обеспечивает бытовая аппаратура, примерно равны следующим значениям: видеомагнитофоны и камеры формата VHS: 210-220 линий. Новые качественные камеры и магнитофоны формата VHS, в том числе с 4 или более считывающими головками в состоянии обеспечить чёткость изображения до 240-260 линий. Видеокамеры формата Video8 в состоянии обеспечить до 270-280 линий. Аппаратура форматов Hi8 и S–VHS может обеспечить чёткость до 420-440 линий. Видеокамеры формата DV и DVD в состоянии обеспечить до 540 линий. Количество видимых строк в стандартах PAL и NTSC фиксировано и составляет соответственно 576 и 480.
Пояснение: эти самые линии по горизонтали считаются не на всей длине строки, а на её части, равной высоте экрана, т.е. в квадрате. Таким образом и подсчитан теоретический максимум для DV при нормальном соотношении сторон экрана 4 на 3: 720 пикселей * 3/4 = 540 линий.
Посмотрите, как падает чёткость изображения DVD качества после записи его на обычный бытовой видеомагнитофон формата VHS и последующем захвате видео:
Нет необходимости подписывать картинки — настолько разительна разница в чёткости. В этом примере горизонтальная чёткость уменьшилась больше чем надвое.
Резкость — чёткость границ
Очень часто термин «чёткость» в области обработки изображений (или видео) можно также услышать применительно к операции повышения чёткости границ (sharpen) — резкости изображения. Я призываю вас не путать эти понятия, так как чёткость изображения по вертикали или по горизонтали не имеет ничего общего с резкостью. Операции sharpen и blur увеличивают и уменьшают контрастность изображения вблизи границ объектов, тем самым резкие переходы на изображении подчёркиваются или скрадываются. Это приводит к тому, что объекты на рисунке воспринимаются человеком как более чёткие или более смазанные. Эффект проявляется в силу особенностей зрительного восприятия: мозг в первую очередь пытается выделить на изображении отдельные объекты. Резкость не имеет никакой количественной абсолютной характеристики.
Кадры, поля и чересстрочное изображение
Чересстрочное и прогрессивное видео
В настоящее время применяются два способа передачи видео: устаревший чересстрочный и более новый прогрессивный. Вещательный телевизионный сигнал по историческим причинам использует чересстрочный способ. Это означает, что кадр (frame) передаётся не целиком, а из двух половинок: сначала передаётся первый полукадр (или поле — field), который отображается в нечётные строки кадра, а потом — второй полукадр, соответственно он отображается в чётные строки.
Прогрессивный кадр содержит все строки: чётные, и нечётные. Компьютерная техника отображает изображение в прогрессивном формате. Прогрессивный кадр лишь недавно стал применяться в видеотехнике, например, новые видео DVD содержат кинофильмы, записанные с прогрессивной развёрткой. Телевещание и подавляющее большинство современных видеокамер используют чересстрочную развёртку. Видеокамеры с прогрессивной развёрткой завоёвывают всё б̀ольшую популярность, однако пока на рынке их достаточно мало.
Очевидно, разрешение каждого полукадра (количество строк) вдвое меньше разрешения полного кадра.
Особенности чересстрочного видео
Следует понимать, что в ТВ сигнале или при съёмке камерой каждый полукадр содержит изображение, отснятое на 1/50 секунды позже: то есть между первым и вторым полукадром проходит 20 мс. За это время объекты, находящиеся в кадре, могут сместиться. С другой стороны поля — элементы полного кадра, то есть 2–я строка (принадлежащая второму полю) расположена ниже 1–й строки (принадлежащей первому полю), 4–я (2–е поле) — ниже 3–й (1–е поле) и так далее. Таким образом, чётные полукадры находятся ниже нечётных. В силу этой особенности полукадры часто называют верхними (top) и нижними (bottom).
Всё сказанное выше справедливо также и для стандарта NTSC, с той только разницей что количество кадров в секунду составляет 30, соответственно полей в секунду — 60. Также различается и порядок следования полей: в PAL верхние поля следуют после (позже) нижних, а в NTSC — наоборот.
Захват чересстрочного видео
При захвате видео компьютеру передаётся набор полных кадров с частотой 25 к/сек, чётные строки кадра содержат одно поле, нечётные — другое. Порядок полей не оговорен стандартами и зависит от аппаратуры: первым может быть как верхнее, так и нижнее поле. Этот метод имеет, как свои преимущества, так и ряд недостатков — подробнее про них рассказано в следующем разделе.
Очень важно, чтобы при захвате чересстрочного видео использовалось полное разрешение по вертикали (обычно это 576 строк). В противном случае из-за уменьшения размера по вертикали часть строк будет потеряна; будет нарушено правило «одно поле в чётных строках, другое — в нечётных». Полученную видеозапись никакой алгоритм deinterlace не сможет исправить. Уменьшение размера по вертикали нужно обязательно делать не при захвате, а при обработке видео: после применения deinterlace или же каким-то другим методом, который не нарушит структуры полей (см. следующий раздел).
Отображение чересстрочного видео на компьютере
Описанная выше структура чересстрочного видео нормально воспринимается при воспроизведении на телевизоре — он имеет невысокое разрешение по вертикали, потому чётные и нечётные строки выводятся практически одна поверх другой. Мы видим все 50 фаз движения в секунду, полукадры всегда отображаются последовательно, один за другим.
Иначе обстоит дело, когда мы пытаемся воспроизвести чересстрочное видео на прогрессивном устройстве, каким является монитор компьютера. Существует ряд способов, как показать на компьютере чересстрочное видео:
1. показывать только чётные или только нечётные поля, получим 25 кадров в секунду;
2. показывать все поля по очереди, получим 50 кадров в секунду;
3. составить полный кадр из двух полей и показывать 25 кадров в секунду.
Оставляем только половину полей
Недостатки первого способа очевидны: мы теряем половину информации из исходного видео. Получаем картинку с половинным разрешением по вертикали и теряем половину фаз движения (половинное разрешение по времени). Этот способ исключительно прост, потому он достаточно распространён. Для восстановления исходных пропорций изображения обычно уменьшается вдвое разрешение по горизонтали, что ещё больше снижает чёткость оцифрованного видео. Безусловно, несложно программно увеличить вдвое разрешение по вертикали, что, конечно же, не добавит чёткости по вертикали (см. раздел «Разрешение и чёткость изображения»).
Сохраняем 50 кадров в секунду
Из 50 полей в секунду можно получить 50 кадров в секунду двумя способами: оставить разрешение кадра равным разрешению поля, то есть половине разрешения кадра; или увеличить разрешение по вертикали вдвое. Первый вариант не так хорош, как кажется: Поскольку одно из полей находится ниже другого, то при выводе полукадров последовательно на экран прогрессивного устройства (монитор компьютера) мы увидим мелкое дрожание изображения вверх-вниз (тремор). Второй вариант позволит сохранить вертикальную чёткость только в том случае, если при увеличении разрешения будет использоваться информация из двух полей (интерполяция), при этом вдвое вырастет время обработки видео и требуемый для хранения объём. Более чем вдвое возрастают требования к мощности компьютера для воспроизведения такого видео.
Реальная необходимость сохранять 50 фаз движения в секунду имеет смысл для записей ТВ трансляций спортивных передач: часто их просматривают в замедленном виде или же вообще покадрово. Также желательно сохранить 50 кадров в секунду для плохо снятых любительских записей видео камерой, когда камера у «оператора» постоянно дрожит.
Подробнее о работе с оцифрованным видео с сохранением 50 фаз движения в секунду вы можете прочесть в статье 50 кадров в секунду.
Формируем 25 кадров в секунду — deinterlace
Самый распространённый способ представления оцифрованного видео на компьютере — это составление полного кадра из двух полукадров: в нечётные строки записывается содержимое одного поля, в чётные — другого. Необходимо учитывать то, что разные полукадры могут относиться к разным моментам времени. За 20 мс, которые разделяют два полукадра, объекты в кадре могут сместиться. При выводе прогрессивного видео с частотой кадров 25 в секунду будут заметны дефекты изображения (артефакты), которые очень часто за характерную форму называют «гребёнкой» или «расчёской». Посмотрите, на этом примере автомобили движутся влево:
«Гребёнка» чересстрочного видео.
Для сравнения — прогрессивный кадр:
Вы видите, что контуры всех объектов, которые сместились за 20 мс, «двоятся»: в одном полукадре (который расположен в нечётных строках) мы видим одно положение объектов, в другом полукадре (чётные строки) — другое положение. Очевидно, что чем быстрее движется объект в кадре, тем больше несоответствие позиций объектов в полукадрах — и тем заметнее артефакты:
Пока правый автомобиль был далеко от камеры, разница его положений составляла всего пару пикселей.
Когда автомобиль приблизился к камере, разница его положений стала заметно больше.
На необычных видеоэффектах артефакты чересстрочности приобретают ещё более причудливые формы:
Надпись увеличивается.
Нужно добавить, что «гребёнка» содержит множество мелких деталей, а это чрезмерно усложняет процесс последующего сжатия видео.
Для устранения эффекта чересстрочности применяются специальные меры, которые называются deinterlace (произносится как «деинтерлейс»). Существует несколько методов deinterlace. Bob deinterlace применяется для вывода 50 фаз движения на прогрессивном устройстве: растягиваем первое поле вдвое по вертикали и при помощи интерполяции смещаем изображение на половину пикселя вниз, удлиняем второе поле вдвое по вертикали и при помощи интерполяции смещаем изображение на половину пикселя вверх. Field deinterlace строит один кадр из двух полукадров, результат обработки имеет 25 кадров в секунду. Способов устранения артефактов чересстрочности несколько: от простого усреднения содержимого двух полей, до сложных алгоритмов детектирования движения в кадре и построения результирующего прогрессивного кадра при помощи интерполяции. В результате применения таких методов несколько снижается чёткость изображения: у готового прогрессивного кадра чёткость практически равна чёткости исходного видеосигнала в статичных сценах, в динамичных сценах она несколько меньше.
Восстановление прогрессивного видео
Иногда прогрессивное видео передаётся посредством чересстрочного сигнала — например, кинофильм транслируется по ТВ. В таком случае верхний и нижний полукадры могут попадать в поля одного чересстрочного кадра (…[1в 1н] [2в 2н] [3в 3н] [4в 4н]…), но возможен такой вариант: …[1н 2в] [2н 3в] [3н 4в]… — то есть полукадры смещены на один. При просмотре кадра такого видео будет заметна «гребёнка», характерная для чересстрочного видео. В результате применения deinterlace мы получим гало — полупрозрачную дымку — вокруг всех движущихся объектов, будем видеть два полупрозрачных контура движущихся объектов.
Для того чтобы реконструировать исходное прогрессивное видео нам необходимо сдвинуть поля видеосигнала таким образом, чтобы восстановить их исходный порядок. Необходимыми возможностями обладают наиболее универсальные фильтры для проведения deinterlace.
Восстановление чересстрочного видео
В силу различных причин, описанная выше для прогрессивного видео ситуация может возникнуть и для чересстрочного видео. Алгоритму deinterlace это не помешает, если будет сохранён правильный порядок полей. Но часть аппаратуры по работе с видео (в том числе и некоторые карты захвата видео) грешит тем, что переставляет поля в пределах кадра, реже — ещё как-либо меняет порядок полей или кадров. В случае если после deinterlace вы получаете гало вокруг движущихся объектов — порядок полей в исходном видео сигнале перепутан.
Чтобы нормально обработать такую видеозапись вам необходимо переставить поля или кадры так, чтобы восстановить исходный порядок полей. Необходимыми возможностями обладают наиболее универсальные фильтры для проведения deinterlace. Комбинацию настроек, скорее всего, вам придётся подбирать экспериментально. Подробнее об этом написано в 4-м разделе статьи Захват и обработка аналогового видео с максимальным качеством для сжатия в MPEG-4.
К счастью, описанные выше проблемы появляются не часто: в подавляющем большинстве случаев чересстрочное видео имеет правильный порядок полей.
Сохраняем чересстрочное видео
Несмотря на то, что монитор компьютера выводит прогрессивное видео, мы можем сохранить наше чересстрочное видео в исходном виде. Потом нам нужно будет или производить deinterlace во время воспроизведения на компьютере, или выводить изображение на телевизор или видеомагнитофон (где артефакты чересстрочного видео не видны).
Проблем при этом подходе несколько. Во–первых, на 20–30% вырастают требования к размеру сжатого видео. Вторая проблема — как организовать вывод с компьютера на ТВ «честного» чересстрочного видео: с правильным порядком полей, которые бы сменялись 50 раз в секунду. Некоторые видеокарты с ТВ выходом позволяют это делать (например, ATI Radeon или Matrox), другие — нет.
Описанную выше проблему можно обойти, записав видео в доступном для аппаратных проигрывателей формате. До недавнего времени таким форматом был только MPEG–2 — его сможет воспроизвести любой DVD проигрыватель. Но для качественного сжатия видео в формат MPEG–2 необходимы огромные объёмы данных (25–30 минут на CD) — видео в формате MPEG–2 удобно записывать только на DVD. Такой вариант решения на сегодня достаточно дорог.
В последнее время начали появляться DVD проигрыватели с возможностью декодирования видео в формате MPEG–4. Последние версии кодеров DivX и XviD имеют режимы для сохранения чересстрочного видео. Но эти режимы пока мало протестированы, даже сами авторы кодеров не рекомендуют их использовать. Также сегодняшние версии программных декодеров не позволяют качественно воспроизвести чересстрочное видео на компьютере: DivX производит во время воспроизведения некий вариант field deinterlace, что приводит к «размазыванию» краёв движущихся объектов. Лучше доверить deinterlace более сложному алгоритму на этапе обработки видео, там он не будет стеснён жёсткими временными рамками «40 мс на кадр» и в состоянии обеспечить более высокое качество. Также вы можете использовать аппаратные проигрыватели с возможностью декодирования MPEG-4, например, проигрыватель Xoro в состоянии воспроизводить чересстрочное видео, закодированное DivX.
Также видео можно хранить непосредственно в формате DV. Такой вариант позволяет избежать дополнительных потерь при обработке и сжатии видео, с другой стороны — видео в формате DV занимает много места: 13 Гбайт/час. Вы можете хранить DV-записи на DV-кассетах, однако такой вариант достаточно дорог; кроме того кассеты подвержены механическому износу.
В этом разделе описаны базовые факты из области цифровой обработки видеоинформации, которые нужны для понимания дальнейшего материала.
Кодирование цвета
Карты захвата видео предоставляют возможность сохранить поток данных в таком же виде, в каком они выходят с чипа оцифровки видео. Эти чипы выдают информацию не в привычном для компьютера формате в виде набора цветовых компонент RGB (red, green, blue), а в виде яркостной и двух цветовых составляющих (YUV). Причём для группы из двух последовательно идущих пикселей сохраняется два значения яркости и по одному значению цветовых компонент, то есть получается 4 байта (32 бита) на 2 пикселя или 16 бит на пиксель. Такой метод называют chroma subsampling, а способ записи называют кодированием цвета YUV2 (или YUYV, или 4:2:2). Из-за особенностей человеческого зрения разницу с обычным RGB представлением увидеть практически невозможно: глаз более чувствителен к яркости, чем к цвету (точнее разрешающая способность глаза по яркости выше, чем по цвету — за счёт разной концентрации колбочек и палочек на сетчатке). Очевидно, такой нехитрый метод позволяет существенно снизить объём информации для оцифрованного видео: если сохранять привычные 24 бита на пиксель вместо 16, то потребуется в 1,5 раза больше места. Поскольку информация с карты захвата поступает уже в YUV2, нет абсолютно никакого смысла записывать на диск RGB.
Также распространён метод кодирования YUV12 (или 4:1:1) — в нём общие значения цветовых компонент имеют группы 2x2 пикселя. Для 4 пикселей сохраняется 4 байта яркости, 1 байт цветности U и 1 байт цветности V, в среднем получается 12 бит на пиксель — отсюда название. Подробнее про способы кодирования цвета см. напр. FAQ по оцифровке видео с минимальными затратами. Для нас важно то, что такие способы представления видео информации является традиционным для цифрового видео, они используется практически всеми кодерами видео.
Поток данных (bitrate)
Важно понимать, что означает термин «поток данных» (bitrate, часто используют русскую транскрипцию: битрейт). Поток данных — это количество информации в сжатом виде, приходящееся на единицу времени для какой-либо записи. Существует два способа сжатия информации: с постоянным потоком данных (CBR, constant bitrate) и с переменным потоком данных (VBR, variable bitrate). В первом варианте каждый блок данных сжатого файла (который имеет определённую длительность при воспроизведении) имеет постоянный размер — соответственно поток данных не меняется на протяжении всего файла. В случае переменного потока данных каждый блок по выбору кодера может иметь больший или меньший размер. Поскольку реальные сигналы имеют постоянно изменяющуюся сложность, метод кодирования с переменным потоком данных оказался существенно эффективнее. Очевидно, чтобы так же качественно закодировать информацию с постоянным потоком данных необходимо всегда использовать максимально возможный размер блока, что приведёт к перерасходу битов на несложных участках.
Когда поток данных не постоянен, то, говоря о ширине потока данных, подразумевают среднюю величину потока данных. Усреднение традиционно проводится в течение всей записи.
С точки зрения изменения сложности для сжатия, видеоинформация существенно сложнее, чем звуковая. Статичные сцены, где из кадра в кадр меняется лишь малая часть изображения, сменяются динамичными, где во время взрывов и погонь сложно найти два одинаковых кадра. Первые реализации MPEG кодеров использовали сжатие видео с постоянным потоком данных (в частности — стандарт Video CD, MPEG–1 сжатие). Однако это даёт настолько неудовлетворительные результаты, что сжатие видео с постоянным потоком данных на сегодня не используется нигде. Есть, правда, два исключения: совместимость со старыми стандартами (например, Video CD) и цифровое вещание (network broadcasting). Мы же всегда будем использовать сжатие видео с переменным потоком данных.
Ширина потока данных измеряется в битах в секунду или байтах в секунду. Потоки данных при работе с видео достаточно велики, потому чаще встречаются килобиты и мегабиты. Напомню, байт содержит 8 битов, килобайт содержит 1 024 байта, мегабайт равен 1 024 килобайтам, то есть 1 048 576 байтам. С битами не всё так просто: DivX Networks внесли изрядную путаницу, используя соотношение 1 кбит = 1 000 бит в своём кодере.
Устройство алгоритмов сжатия видео
Типы кадров
Поток данных в формате MPEG (1, 2 и 4) может содержать три типа кадров: ключевые кадры (keyframe, intra-frame, I–frame), промежуточные (predictable, forward predictable, P–frame) и двунаправленные (backward predictable, bi–directional, BiDir, B–frame).
Ключевой кадр содержит всю информацию об изображении в кадре и никак не зависит от других кадров.
Промежуточный кадр может ссылаться на блоки изображения в предыдущем ключевом или предыдущих промежуточных кадрах. Это позволяет делать такие кадры по размеру меньше ключевых: в них записано меньше информации об изображении. Для того чтобы полностью отобразить промежуточный кадр, необходимо взять ближайший перед ним ключевой кадр, а потом последовательно декодировать промежуточные кадры. Очевидно, что такой способ хорош при воспроизведении видео (когда все кадры отображаются последовательно: декодеру нужно лишь сохранять в памяти нужные предыдущие кадры). При монтаже такой способ хранения информации куда как менее удобен: во-первых, возрастает среднее время декодирования одного кадра (для декодирования промежуточного кадра нужно декодировать не один, а несколько кадров), во-вторых, разрезать и склеивать видеоряд возможно только так, чтобы первый кадр в отрезанном куске видеоряда был ключевым.
Двунаправленный кадр также содержит не всё изображение. Но в отличие от кадра, о котором говорилось выше, он может ссылаться и на последующие за ним кадры, вплоть до следующего промежуточного кадра: отсюда и происходит его название. Двунаправленные кадры занимают ещё меньше места, чем промежуточные. Способ декодирования двунаправленного кадра ещё сложнее, чем декодирование промежуточного кадра: сначала по описанной выше схеме декодируется следующий за двунаправленным промежуточный кадр; потом, используя информацию о соседних кадрах, декодируется двунаправленный кадр.
Из сказанного выше следует, что чем чаще в видеозаписи расположены ключевые кадры, тем быстрее осуществляется перемотка и доступ к произвольному кадру. Но, поскольку ключевые кадры занимают наибольший размер, тем хуже будет сжатие видеозаписи.
Группы кадров
Группой кадров (GOP, Group Of Pictures) называют последовательность между двумя ключевыми кадрами. Подгруппой кадров (Sub GOP) называют последовательность между двумя промежуточными кадрами. Традиционно у MPEG–1 и MPEG–2 кодеров задаётся длина групп и подгрупп кадров. Типичные параметры для MPEG-кодеров: 15 и 3, что соответствует последовательности кадров I BB P BB P BB P BB P BB I… Простые MPEG–1/2 кодеры используют эти параметры как руководство к действию, более сложные — как рекомендацию.
Очевидно, что когда в видеоряде сменилась сцена — новый кадр содержит абсолютно не похожее на предыдущий кадр изображение — имеет смысл начать новую сцену с ключевого кадра. Алгоритм, который вставляет ключевой кадр в начале новой сцены, называется «определением смены сцены» (scene change detection), он реализован во всех современных MPEG–4 кодерах. Несложные MPEG–1 и MPEG–2 кодеры, которые содержатся в программах для захвата видео, лишены его.
Ввиду особенностей развития MPEG–4 кодеров, поддержка двунаправленных кадров была реализована не сразу. DivX и XviD имеют настройки, которые позволяют включать и выключать использование двунаправленных кадров. В DivX можно ограничить последовательность двунаправленных кадров одним (последовательность кадров вида …IBPBPB…) или двумя (последовательность вида …IBBPBBP…), XviD также позволяет указать допустимое количество идущих подряд В-frame (по умолчанию — 2). И DivX, и XviD содержат параметр, который ограничивает сверху длину группы кадров — максимальное расстояние между ключевыми кадрами. Поскольку все MPEG–4 кодеры содержат алгоритм обнаружения смены сцены, этот параметр традиционно достаточно велик и равен по умолчанию примерно 10 секундам (240-300 кадров). Ключевые кадры добавляются кодером в случае необходимости, а ограничение длины группы кадров больше нужно для облегчения перемотки.
Если вы хотите использовать MPEG сжатие в качестве промежуточного, то вам крайне желательно отключить использование двунаправленных кадров, укоротить длину группы кадров. Это позволит повысить скорость доступа к произвольному кадру вашей видеозаписи, также снизится вычислительная сложность кодирования видео. С другой стороны такой способ сжатия потребует больше места. В идеале нужно заставить кодер сохранять последовательность из одних ключевых кадров, что сделает его подобным методу сжатия MJPEG.
Развитие MPEG–4 кодеров
За последние несколько лет мы наблюдаем бурное развитие кодеров видео. Сегодня различными разработчиками развивается множество программ, которые позволяют сжимать видео — большая часть основана на технологиях MPEG–4. 3ivX разработала набор кодеров: видео, звук (MPEG–4 AAC) и инструменты для поддержки контейнера MP4 (см. раздел «Формат контейнера видеозаписи»). Ahead Software для своего пакета записи и копирования CD и DVD дисков создала MPEG–4 кодер Nero Digital (также в комплекте с кодером AAC и поддержкой контейнера MP4). Microsoft продолжает выпускать новые версии кодеров Windows Media Video, которые также основаны на MPEG–4. Mpegable выпустила свой MPEG–4 кодер, особенно неплохой при небольших потоках данных (см. статью Хорошие и плохие стороны кодека Mpegable MPEG-4, рекомендации и советы по использованию). On2 выпустила очень необычный и многообещающий кодек VP6 (см. статью On2 VP6 6.2 (VP62) - 10 тысяч метров, полет нормальный). Последние версии формата RealVideo — 9–я и 10–я — также основаны на MPEG–4. DivX Networks продолжает развитие своего кодера DivX — пожалуй, самого успешного и популярного. Альтернативная разработка, основанная на исходных кодах старого доброго OpenDivX — XviD — продолжает развиваться, и уже достигла стабильного состояния. XviD на сегодня обеспечивает лучшее качество сжатия видео (см. напр. сравнение кодеров видео на сайте Doom9) и полную совместимость со стандартом MPEG–4. В среде Unix разрабатывается и используется библиотека с открытыми исходными кодами libavcodec — в частности она поддерживает кодирование MPEG–4 видео. Существуют реализации этого кодера под Windows: ffDShow и ffvfw (включён в состав новых версий ffDShow).
Множество пользователей использует разные MPEG–4 кодеры видео, в интернете можно найти множество информации по этому вопросу. Проводятся тестирования и сравнения — по качеству изображения, скорости работы и т.п. Самый известный на сегодня любительский сайт в области технологий сжатия видео — это Doom9. На этом сайте также действует форум, очень популярный в кругах энтузиастов от цифрового видео. Хозяин и автор сайта, Doom9, регулярно проводит сравнения разных кодеров видео, последнее из них он закончил к Новому 2004 году. Это тестирование выявляет явных аутсайдеров с точки зрения сохранения качества изображения (Windows Media 9, 3ivX, libavcodec, Nero Digital 4.1.4 — последний, правда, исключительно быстрый).
Выбор MPEG–4 кодера
Оставшиеся кодеры — RealVideo 9, VP6.0, DivX и XviD — представляют группу лидеров. RealVideo обеспечивает самую мягкую и смазанную картинку, XviD — самую чёткую, VP6 чуть-чуть хуже XviD. DivX занимает промежуточное место между VP6 и RealVideo 9.
Необходимо отметить, что RealVideo использует свой формат сжатия звука и свой контейнер (с поддержкой субтитров и закладок; в принципе, возможно поместить RealVideo в контейнер Матрёшка, см. подробнее «Формат контейнера видеозаписи»). Не каждая программа по работе с видео в состоянии работать с RealVideo. Видео, сжатое On2 VP6, хранится в файлах AVI, однако, этот формат сжатия не совместим со стандартом MPEG–4. То есть для воспроизведения RealVideo или VP6 вам понадобятся соответствующие декодеры. Декодеры эти есть далеко не у всех: если вы перепишите свои записи знакомым, не забудьте захватить соответствующий декодер. Про воспроизведение на аппаратном MPEG–4 проигрывателе вы можете забыть. Как известно, в Китае сейчас раскручивается стандарт EVD (Enhanced Video Disk) который использует обычный DVD в качестве носителя и VP6 в качестве формата сжатия видео. Соответственно, на рынке появляются аппаратные проигрыватели с поддержкой EVD, а значит и VP6. Однако дальнейшее распространение этого стандарта и его поддержки среди аппаратных проигрывателей пока находится под большим вопросом, тогда как поддержка MPEG–4 уже состоялась «в железе» и будет развиваться дальше.
И ещё одна существенная проблема есть как у RealVideo 9, так и у VP6: очень неточный механизм контроля над шириной потока данных. При сжатии видео исходя из желаемого размера сжатой видеозаписи задаётся ширина потока данных. DivX и XviD обеспечивают очень высокую точность контроля над шириной потока: разница между желаемым размером и действительным очень мала (не более 1 Мбайта на 1 час видео). RealVideo 9 стабильно делает файлы меньшего размера, иногда по 5–6 Мбайт на 1 час видео — правда, с этим ещё можно мириться. VP6 создаёт файлы существенно большего размера, иногда по 15 Мбайт на 1 час видео. Очевидно, что такое поведение кодера неудовлетворительно: если мы заказали размер сжатого видео в 1 CD, а получили результат на 15 Мбайт больше, то записать полученную видеозапись на CD мы не сможем. Единственный плюс кодера VP6: специфическая форма артефактов сжатия, которые гораздо менее заметны, чем квадраты DivX или XviD. Это позволяет использовать VP6 при очень малых потоках данных (2 часа записи на 1 CD: менее 800 Кбит/сек).
С точки зрения совместимости с аппаратными проигрывателями наилучшим является кодер DivX: производитель кодера DivX Networks организовала специальную программу сертификации аппаратных MPEG–4 проигрывателей на совместимость с DivX видео. Однако XviD также способен выдавать поток данных в строгом соответствии со стандартом MPEG–4 — аппаратные проигрыватели также в состоянии воспроизводить и его файлы.
Возможно кому-то настолько по душе мягкая картинка RealVideo 9 или чёткая картинка VP6, что он согласен мириться с необходимостью использовать специальные программы видеомонтажа (для RealVideo 9) и специальный декодер, с отсутствием поддержки распространёнными аппаратными проигрывателями, со скоростью кодирования примерно вдвое ниже скорости DivX или XviD, и с получением файлов случайного размера. Однако мне кажется совершенно очевидным, что выбирать сегодня MPEG–4 кодер имеет смысл только между DivX и XviD.
Легенда про DivX 3
DivX 3 — это взломанный вариант экспериментальной версии MPEG–4 кодера от Microsoft. Оригинальные версии кодера (их было 3: Microsoft MPEG 4.1, 4.2 и 4.3) имели существенное ограничение: они поддерживали только контейнер ASF (Advanced Streaming Format, позже этот формат был переименован в Windows Media). Jérôme Rota (известный также под кличкой ‘Gej’) поработал над тем, чтобы новый метод сжатия видео можно было использовать в привычных AVI файлах: тогда MPEG–4 сжатие станет доступно любой программе по работе с видео. То, что получилось в результате, было названо DivX. При помощи DivX можно было сжать целый фильм с видео DVD до размеров CD — в таком виде его можно передать через интернет. С появлением DivX начался бум пиратского копирования видео продукции, в первую очередь кинофильмов и видеоклипов. Это, в свою очередь, повлекло за собой с одной стороны широчайшее распространение DivX кодека, а с другой — бурю протеста, как со стороны Microsoft (по поводу нелегального использования их программы), так и со стороны издателей кинофильмов (особенно усердствует MPAA, Motion Picture Association of America, Американская ассоциация кинопроизводителей). Но самое главное — это было в далёком 1999 году!
За прошедшие годы многое произошло: Jérôme Rota основал компанию DivX Networks, которая занялась разработкой «лицензионно чистого» программного обеспечения для сжатия видео. Получив немалые инвестиции, в 2000–2001 годах компания организовала проект OpenDivX — разработка MPEG–4 кодера видео с открытыми исходными кодами. Позже, когда DivX Networks собрала коллектив разработчиков и доказала, что всё начато «с чистого листа», исходные коды проекта были закрыты: дальше проект развивался силами компании. На основе тех же исходных кодов OpenDivX возник проект с открытыми исходными кодами XviD, он развивался параллельно с DivX 4-5. Возникла довольно необычная ситуация: параллельно развивались два проекта, коммерческий и некоммерческий, с закрытыми и открытыми исходными кодами; причём оба являются продолжением OpenDivX. Такая конкуренция способствовала развитию обоих проектов: DivX и XviD сегодня — самые лучшие и распространённые MPEG–4 кодеки видео.
Microsoft также не сидела сложа руки: она выпустила две версии кодера Windows Media Video. Напомню, что даже последняя версия обеспечивает худшее качество, чем DivX или XviD.
В последние несколько лет только DivX 3 никак не развивался после окончательного варианта 3.11, который выпустил Gej. Это закономерно: исходных кодов кодера у сторонних разработчиков не было, сделать что-либо существенное можно было только снаружи кодека. Так, в начале 2000 года была выпущена дополненная версия — 3.20. Она содержала реализацию алгоритма определения смены сцены: версия 3.11 вставляла ключевые кадры только через заданные интервалы. Версия 3.20 содержала код по детектированию начала новой сцены и называлась VKI (variable keyframe interval, переменный интервал между ключевыми кадрами). Все версии кодера DivX 3 поддерживали только однопроходное сжатие с заданным средним битрейтом.
NanDub
Прогрессом в развитии DivX 3 стало создание варианта программы VirtualDub, которая заставляла работать кодер DivX 3.11 в режиме двухпроходного сжатия: NanDub (по имени автора этого варианта — Nando). В таком виде DivX 3.11 позволял добиваться намного лучших результатов, чем в режиме однопроходного сжатия. Долгое время DivX 3.11 в двухпроходном режиме был эталоном качества для MPEG–4 кодеров видео. Программа NanDub содержит уйму настроек — разобраться в них достаточно сложно, очень немногие смогли освоить эту программу на уровне гуру. Развитие NanDub было прекращено к лету 2001 года. Специалисты по двухпроходному сжатию всё больше обращали свои взоры в сторону DivX и многообещающего и быстро развивающегося XviD: например Koepi, автор руководства по использованию NanDub’а и соавтор некоторых модулей, сейчас принимает активное участие в развитии XviD.
Развитие всех программ, которые касаются DivX 3, было прекращено три года тому назад. За эти три года DivX и XviD прошли долгий путь и однозначно превзошли DivX 3 по качеству изображения (см. последнее сравнение видео кодеков Doom9). Тем не менее, до сих пор жива легенда о том, что, дескать, DivX 3 — лучший. Это следствие нескольких факторов: традиция (когда-то DivX 3 был действительно лучшим), лень (тем, кто овладел в какой–то степени NanDub’ом просто лень переучиваться) и обычная человеческая осторожность ко всему новому.
Сегодня я всех призываю: похороните DivX 3! Его время
уже прошло. Поскольку многие кодеки способны воспроизводить сжатое DivX 3
видео, удалите
из своей системы кодек DivX 3 и NanDub. Меня удивляет
количество новых видеозаписей, которые до сих пор сжимают при помощи
DivX 3. А ведь DivX 3 содержит ошибку, 
которая приводит к появлению
«выпавших» квадратных блоков при кодировании контрастных краёв (например:
титров, особенно иероглифов) — см. картинку. Только DivX 3
содержит ошибку, в результате которой некоторые текстуры ошибочно присваиваются
движущемуся объекту: в результате часть изображения вдоль контура подвижного
объекта уплывает в сторону — т. н. «плывун». На сегодня не осталось ни единого
аргумента «за» DivX 3 — только лень его использующих. И ещё: видеозаписи в
формате DivX 3 не вполне совместимы со стандартом MPEG-4 и не всегда
корректно воспроизводятся аппаратными проигрывателями.
DivX 4, DivX 5
Первая публично изданная версия кодера DivX 4 не поддерживала расширения стандарта MPEG–4 advanced simple profile: например, не позволяла создавать двунаправленные кадры. Также DivX 4 не содержал никаких дополнительных инструментов по работе с видеозаписью, только кодек. Ещё во времена DivX 4 компания DivX Networks заложила традиции нумерации версий: версия 4.0 содержала море ошибок. Некоторые из ошибок приводили к созданию некачественного сжатого видео, другие — к зависаниям программ по работе с видео. Ряд последующих версий содержал исправления ошибок и оптимизации, постепенно кодер достиг своего стабильного и работоспособного состояния (последняя версия: 4.12).
Кодек DivX 5 — это продолжение развития кодека DivX 4. Принципиальное отличие от кодера DivX 4 в том, что новая версия кодера содержит дополнительные возможности, совместимые со стандартом MPEG–4 advanced simple profile: двунаправленные кадры, компенсация движения (GMC, Global Motion Compensation), четвертьпиксельная точность (Quarter pixel motion, Qpel motion); а также содержит дополнительно ряд простейших инструментов по обработке видео: обрезание краёв, изменение разрешения, фильтр шумов и deinterlace. Такие дополнения весьма быстры, но удобнее использовать соответствующие фильтры в программе по обработке видео, так как это позволяет:
использовать фильтры в любом порядке, а не непосредственно перед DivX сжатием;
применять более качественные фильтры (например: встроенный фильтр шумоподавления DivX имеет тенденцию к созданию колебаний яркости на тёмных зашумленных сценах);
иметь возможность настраивать каждый из фильтров «по месту» с возможностью предварительного просмотра результата.
Дополнительные возможности кодера
Использование двунаправленных кадров позволяет существенно повысить эффективность сжатия: до 30-40%. Правда, кодер DivX ограничен в своих возможностях: в режиме обеспечения совместимости с профилями DivX Certified Profile он не способен генерировать более одного двунаправленного кадра подряд. Если использовать больше одного двунаправленного кадра подряд (XviD, DivX 5.2), то повысить эффективность сжатия можно ещё больше: до 40-60%. Использование двунаправленных кадров увеличивает потребление вычислительных ресурсов примерно на 25% во время сжатия и на 10% во время воспроизведения видео.
Глобальная компенсация движения призвана уменьшить поток данных в тех сценах, где большая часть изображения перемещается в сторону: панорама, прокручивающиеся титры и т. п. В поток сжатого видео записывается не само изображение кадра за кадром, а исходное изображение, и направление его перемещения. Очевидно, что для реализации этой возможности в декодере, нужен большой объём памяти для сохранения большой части изображения. По этой причине подавляющее большинство современных аппаратных декодеров MPEG–4 видео не поддерживают эту возможность. Также кодер имеет некоторые проблемы с отделением статичных объектов от перемещающихся частей изображения: например, если в вашем видео прокручиваются титры, а в углу экрана находится статичный полупрозрачный логотип, то есть шанс, что в закодированном видео логотип будет «прыгать». Использование глобальной компенсации движения увеличивает потребление вычислительных ресурсов примерно на 10%, как во время сжатия, так и во время воспроизведения видео.
Четвертьпиксельная точность при расчёте векторов движения блоков изображения позволяет более точно позиционировать движущиеся объекты в кадре, это в результате выражается в более плавных перемещениях мелких или далёких объектов. Применение этой возможности примерно на 10% ухудшает сжимаемость видео. Использование четвертьпиксельной точности увеличивает потребление вычислительных ресурсов примерно на 30–40% как во время сжатия, так и во время воспроизведения видео. По этой причине подавляющее большинство современных аппаратных декодеров MPEG–4 видео не поддерживают эту возможность. Также учтите, что процессора в 500 МГц будет недостаточно для воспроизведения видеозаписей, сжатых с использованием четвертьпиксельной точности — понадобится процессор не менее 800 МГц (и более, — зависит от разрешения видео).
Психовизуальные улучшения
Также в 5–й версии кодера DivX впервые реализована экспериментальная система, получившая название психовизуальные улучшения. Задача этой системы – обнаруживать те части изображения, в которых дефекты изображения будут наименее заметны человеческим глазом: например, очень тёмные или светлые области. Кодер сжимает соответствующую часть изображения с более низким качеством. Таким образом, объём результирующего файла при заданном среднем уровне качества может заметно уменьшиться. Кодирование с использованием психовизуальных улучшений замедляет процесс кодирования на 5-25%. Система психовизуальных улучшений — экспериментальная разработка, которая постоянно совершенствуется и изменяется, потому этот режим не рекомендовался к использованию. В версии 5.1 она была полностью обновлена. Её использование сейчас вполне оправданно.
По традиции версия 5.0 содержала множество ошибок и практически непригодна для использования, ошибки были исправлены в версии 5.0.2.
DivX 5.0.Х
Следующим существенным шагом (версия 5.0.3) было внедрение механизма контроля над шириной потока данных (rate control) — это особенно важно для аппаратных проигрывателей, вычислительная мощность которых ограничена. DivX Networks разработала ряд профилей, которые содержат набор требований к производительности декодера и ограничения для потока данных. Если вы планируете воспроизводить ваши видеозаписи только при помощи компьютера — вам имеет смысл отключить использование профилей. Так вы снимете дополнительные ограничения с кодека, что позволит ему шире варьировать свои возможности с целью создания более качественного сжатого видео. Также отказ от использования профилей увеличит скорость кодирования видео примерно на 1%, даст возможность использовать однопроходный режим с постоянным качеством (см. ниже), несколько двунаправленных кадров подряд и MPEG- матрицу квантования. Полученное видео как–то будет воспроизводиться на аппаратных проигрывателях, но качественное воспроизведение всей видеозаписи не гарантируется. С другой стороны, использование профиля при кодировании позволит гарантированно воспроизводить видеозапись на определённом классе аппаратных MPEG–4 проигрывателей. Рекомендуемый профиль: Home theatre, он соответствует бытовым проигрывателям видео (максимальное разрешение видеозаписи равно разрешению видео DVD).
Также DivX обрёл поддержку чересстрочного видео, режим многопроходного сжатия, небольшое повышение производительности и изменение интерфейса настройки кодера. Стабильная версия с исправленными ошибками — 5.0.5.
Поддержка чересстрочного видео реализована в соответствии со стандартом MPEG–4: решение использовать ли обычное (прогрессивное) кодирование или чересстрочное принимается на уровне блока изображения. Такое видео требует несколько больше места для хранения, чем прогрессивное. Некоторые подсистемы кодера DivX (например, психовизуальные улучшения) до сих пор не умеют работать с чересстрочным видео. Декодер DivX, который производит deinterlace «на лету» при воспроизведении, делает это далеко не лучшим образом. С другой стороны, аппаратные декодеры MPEG-4 позволяют корректно отображать чересстрочное видео.
DivX 5.1
Версия 5.1, кроме традиционных небольших улучшений почти всех подсистем кодера и очередного изменения интерфейса, содержит новый интеллектуальный алгоритм для выбора варианта кодирования изображения. Предположим для примера, что блок изображения можно закодировать такими способами: А (размер: 10, качество: 10), Б (размер: 5, качество: 8) и В (размер: 4, качество: 5). Обычный алгоритм выберет вариант с максимальным качеством (в нашем случае — А), интеллектуальный алгоритм выберет вариант с лучшим соотношением «качество/размер» (в нашем случае — Б). Такой выбор приведёт к тому, что при сохранении высокого качества будет израсходовано меньше битов, что позволит сжать другие сцены с более высоким качеством: общее качество сжатия видеозаписи окажется выше. Поскольку кодеру необходимо отрабатывать несколько вариантов сжатия изображения, скорость кодирования падает почти в 6 раз. В Официальном руководстве по DivX 5.2 советуют использовать интеллектуальный алгоритм только на последнем проходе, но даже в таком случае 2–проходное сжатие производится более чем втрое дольше, чем при использовании обычного алгоритма. Его использование оправдано при малых потоках данных (менее 700 Кбит/сек), иначе его влияние практически незаметно на глаз.
Кодер DivX 5.1 содержит два варианта реализации интеллектуального алгоритма сжатия: Slow (ориентирован на максимальную скорость) и Slowest (ориентирован на максимальное качество) — однако разница в скорости их работы практически незаметна на фоне шестикратного уменьшения производительности по сравнению с алгоритмом Standard. Кодер версии 5.2 содержит только один вариант интеллектуального алгоритма: Slow.
По традиции версия 5.1 содержала ряд ошибок, большинство было исправлено в версии 5.1.1 (однако кодер всё ещё изредка производит дефекты изображения, подробнее см. сравнение MPEG–4 кодеров Doom9 — эта проблема была исправлена лишь в версии 5.2).
DivX 5.2
Версия 5.2 выпущена в 4 языковых вариантах: английский, немецкий, французский и японский; на эти же языки переведён сайт DivX Networks. Из-за этого размер установки получился огромным: 8 Мбайт. Бесплатный вариант Pro-версии кодека больше не содержит Ad-ware программы и не будет показывать рекламу — теперь у кодера есть пробный период в 180 дней. Появился новый режим: Fast, который работает быстрее Standard, но обеспечивает почти такой же уровень качества сжатия видео — его рекомендуют использовать при захвате видео. Добавлен встроенный в интерфейс кодера bitrate calculator (который, правда, уступает калькулятору XviD’а по функциональности). Код был оптимизирован под Intel SSE3 (Prescott), что обеспечивает 15% прирост производительности.
Наконец-то стало возможным использовать более чем один двунаправленный кадр подряд и использовать не только H.263 матрицу квантования (что приводит к некоторому замыливанию картинки), но также MPEG-2 матрицу (кодер XviD давно предоставляет такие возможности). Правда, обе возможности становятся доступными лишь после отключения соответствия профилю кодирования DivX Certified Profile.
Использование более чем одного двунаправленного кадра подряд позволяет повысить эффективность сжатия видео на 10—15% при сохранении субъективно того же уровня качества. Использование разных матриц квантования определяет тенденцию кодера к сохранению чёткости изображения (MPEG-матрица) или же наоборот — размыванию мелких деталей (H.263). Соответственно, MPEG-матрицу нужно использовать только при достаточно больших потоках данных (более 1 Мбит/сек). Для достижения субъективно одинакового уровня качества при использовании разных матриц квантования и прочих равных условиях, MPEG-матрица потребует средний битрейт на 100—200 Кбит/сек. больше, чем H.263. Все эти рассуждения справедливы для любого MPEG-4 кодера (в частности для DivX и XviD).
Последняя версия — DivX 5.2 — содержит ряд недоработок (см. также сообщения на форуме), потому не рекомендуется использовать её до появления исправленной версии из линейки 5.2.X. Предыдущая версия, проверенная временем — 5.1.1.
DivX Q
В дальнейших планах DivX Networks — выпуск новой версии DivX Q в середине 2005 года, которая будет включать в себя не только сжатие видео, но и формат для сжатия звука и формат контейнера (подробнее см. интервью).
Дополнительная информация
Интересующихся вопросами обратной совместимости линейки кодеров DivX, отсылаю к статье DivX: особенности сжатия видео в домашних условиях.
На сайте DivX вы можете найти множество документации (на английском языке), особо стоит выделить Официальное руководство по DivX 5.2 — это 120–страничный отлично оформленный документ (в формате Adobe Acrobat, размер: 8 МБ, на английском, немецком, французском и японском языках), который содержит подробнейшее описание настроек кодера и декодера DivX, советы по использованию кодера, множество информации по современным технологиям сжатия видео на базовом уровне — для упрощения понимания механизма работы кодека DivX. Этот документ рекомендуется к прочтению всем, кто интересуется современными технологиями сжатия видео. Также на сайте DivX действует форум, в котором специалисты и энтузиасты делятся опытом.
XviD
Кодек XviD является результатом разработки MPEG–4 кодера с открытыми исходными кодами: сначала в рамках проекта OpenDivX, а после того, как компания DivX Networks начала разработку закрытого кодера DivX,– как самостоятельный проект.
В период бурного развития новые версии XviD выходили едва ли не каждую неделю — как у подавляющего большинства проектов с открытыми исходными кодами. Часто они содержали существенные ошибки, которые приводят к появлению искажений в сжатом видео, или зависаниям программы для обработки видео. Эти версии тестируются сотнями энтузиастов, ошибки находят и исправляют. Примерно раз в полгода выпускается т.н. стабильная (stable) версия, которая тестируется на протяжении длительного времени, и в которой не было обнаружено ошибок. Стабильные версии кодера выходят достаточно редко, а различные нововведения присутствуют только в регулярно выходящих альфа- и бета-версиях. Желание применять новейшие технологии подталкивает многих на использование этих тестовых версий для сжатия архивных видеозаписей. Конечно, даже тестовая версия имеет шанс сжать видео верно и без дефектов, но в случае с XviD известны случаи, когда сжатое видео невозможно было корректно воспроизвести никаким декодером, даже более новым декодером XviD. Использовать тестовые альфа- и бета- версии рискованно — из-за этого у кодера XviD закрепилась репутация «глючного», то есть работающего с ошибками и сбоями.
XviD поддерживает самые современные достижения в области кодирования видео: двунаправленные кадры (B–VOPs), интеллектуальный алгоритм выбора варианта кодирования изображения (тут он называется Trellis quantization), кодирование чересстрочного видео (Interlaced encoding) и психовизуальные улучшения (Adaptive quantization). XviD позволяет изменять некоторые настройки, которые невозможно поменять в кодере DivX, как то: матрица квантования (Quantization type matrix), структура подгруппы кадров (B–VOPs), точность (и, соответственно, скорость) алгоритма поиска движения в кадре (Motion search precision), задавать допустимый диапазон коэффициентов квантования (Quantizer restrictions) — это позволяет более тонко настроить процесс кодирования видео. Плюс XviD поддерживает некоторые возможности, которые отсутствуют в кодере DivX: соотношение сторон изображения (Aspect ratio, DivX поддерживает только квадратные пиксели), кодирование чёрно-белого изображения (Greyscale encoding), специальный мультипликационный режим (Cartoon Mode). Компенсация движения (GMC, Global Motion Compensation) и четвертьпиксельная точность (Quarter pixel motion, Qpel motion) в исполнении XviD не совместимы с DivX, хотя и соответствуют стандарту MPEG–4 — из–за этого такое видео некорректно воспроизводят декодер DivX и большинство аппаратных декодеров. Применять эти две возможности не рекомендуется.
XviD 1.0 Release
Важным этапом для XviD стала полная MPEG–4 совместимость, что позволяет воспроизводить видеозаписи сжатые XviD при помощи декодера DivX или при помощи аппаратных проигрывателей. В мае 2004 года была выпущена стабильная версия XviD 1.0: за полгода тщательного тестирования в ней не было обнаружено ошибок, которые бы влияли на качество сжатого видео.
Дополнительная информация
На данный момент не существует единого документа, который бы подробно описывал все настройки кодека XviD: руководство XviD Options Explained от Koepi порядком устарело. Однако на сайте Doom9 постоянно действует форум XviD, в котором участвуют и разработчики кодера, и специалисты, и просто любители. Вы можете найти там ответ на любой свой вопрос, или же спросить прямо у разработчиков кодека.
Различные методы сжатия видео
Современные кодеры имеют несколько режимов сжатия видео, каждый имеет свои преимущества и недостатки, свою область применения. В этом разделе описаны режимы кодирования видео MPEG–4 кодеров.
Однопроходное сжатие
Однопроходное сжатие нужно использовать тогда, когда исходный видеоматериал доступен только однажды (ТВ трансляция) или труднодоступен (видеоряд получается в результате сложных вычислений, например, в результате обработки многими фильтрами — вряд ли кому-то захочется повторять громоздкие вычисления дважды, как того требует двухпроходный режим).
Исторически первым появился режим сжатия с постоянным потоком данных (CBR, Constant bitrate): каждая группа кадров занимает одинаковый размер. Как было сказано в разделе «Поток данных (bitrate)», режим с постоянным потоком данных в силу низкого качества изображения нужно использовать только в тех случаях, где использовать переменный поток данных невозможно: при цифровом вещании (network broadcasting). Для включения этого режима в кодере DivX нужно отключить профили (Select Profile Wizard — Disable profiles), выбрать 1–pass и ввести нужное значение ширины потока данных в поля Encoding bitrate и Max bitrate (в Кбит/сек). Кодер XviD не поддерживает этот режим.
Следующий режим — с переменным потоком данных (VBR, Variable bitrate). Во время сжатия кодер будет стараться экономить биты на простых сценах и расходовать «накопленное» на сложных сценах, при этом кодер будет стремиться обеспечить среднюю ширину потока данных на заданном уровне. Однако в силу того, что кодер может принимать решения лишь на основе уже закодированных кадров (прошлого) и не знает, что ждёт его в будущем, стратегия расходования битов не будет оптимальной. Невозможно правильно рассчитать расход битов, не зная, как долго продлится простая или сложная для сжатия сцена. Используйте этот режим, если вам нужно при однопроходном режиме контролировать размер сжатого видео. Для включения этого режима в кодере DivX нужно выбрать 1–pass и ввести нужное значение средней ширины потока данных в поле Encoding bitrate (в Кбит/сек). Для включения этого режима в кодере XviD нужно выбрать Encoding type: Single pass, если нужно — нажать кнопку Target quantizer, в графе Target bitrate задать нужное значение средней ширины потока данных (в Кбит/сек). Для расчёта средней ширины потока данных вы также можете использовать встроенный калькулятор: кнопка Bitrate Calculator (Calc для XviD).
Режим с постоянным качеством (QB, Quality based, Constant quantizer). Во время сжатия кодер будет использовать для каждого кадра одинаковый коэффициент квантования (если задано целое число; если в качестве среднего коэффициента задать дробное число, то кодер будет использовать целые коэффициенты квантования (ближайшие к заданному дробному числу) таким образом, чтобы в среднем по всему видеоряду коэффициент квантования был равен заданному числу). Коэффициент квантования определяет величину потерь при сохранении изображения: чем коэффициент больше, тем больше потери; с другой стороны, чем больше коэффициент квантования — тем меньше размер сжатого изображения. Диапазон допустимых значений коэффициента квантования — от 1 (максимальное качество, максимальный размер) до 31 (минимальное качество, минимальный размер). Характер потерь при больших коэффициентах квантования проще продемонстрировать на примере:
Коэффициент квантования: 2
Коэффициент квантования: 5
Коэффициент квантования: 8
Этот режим имеет существенный недостаток: заранее невозможно предсказать размер файла со сжатым видео. С другой стороны, алгоритм такого сжатия достаточно прост: из всех режимов MPEG-4 кодеров этот — самый быстрый. Такой режим сжатия удобно применять при захвате видео или как промежуточный формат сжатия. Для включения этого режима в кодере DivX нужно отключить профили (Select Profile Wizard — Disable profiles), выбрать 1-pass quality-based и ввести нужное значение среднего коэффициента квантования в поле Quantizer. Для включения этого режима в кодере XviD нужно выбрать Encoding type: Single pass, если нужно — нажать кнопку Target bitrate, в графе Target quantizer задать нужное значение среднего коэффициента квантования.
В Официальном руководстве по DivX 5.2 описана интересная возможность: можно использовать режим сжатия с постоянным качеством вместо первого прохода двухпроходного сжатия. Для этого в настройках кодера DivX нужно выбрать режим 1–pass quality based и включить запись файла с анализом видеоряда (write log file) — именно он создаётся при первом проходе двухпроходного сжатия. При этом рекомендуется использовать небольшие коэффициенты квантования. Размер полученного файла будет на порядок меньше того же видео, сжатого без потерь. При втором проходе сжатия нужно использовать полученную запись в формате DivX и полученный файл с анализом видеоряда (log file). Кодер XviD также способен на такой фокус: нужно выбрать режим Twopass — 1st pass, в дополнительных настройках (more) включить Full quality first pass и выключить Discard first pass. Вы можете выбрать имя файла, в который будет записана информация об анализе видеоряда при помощи кнопки «…».
Примечание. Может показаться, что при таком варианте будут допущены потери качества изображения: в качестве промежуточного формата используется сжатие с потерями MPEG-4. Назовём исходный видеоряд как А. В результате первого прохода в режиме с постоянным уровнем качества был получен файл Б. Мы хотим получить файл В при помощи двухпроходного сжатия видеоряда А. При выполнении каждого прохода двухпроходного сжатия алгоритм сжатия MPEG‑4 сначала разделит изображение на блоки и проведёт их кодирование (квантование) — то есть изображение будет приведено точно тому же виду, в каком оно записано в файле Б (если при его записи использовался минимально возможный коэффициент квантования 1: это обеспечит максимальное качество изображения). Очевидно, что для получения файла В при втором проходе сжатия видео, что в качестве исходного видеоряда можно использовать как А, так и Б — результат будет одинаков. Применение такого метода не приводит к потерям качества изображения, зато позволяет сэкономить время (не нужно выполнять первый проход), а также существенно сэкономить дисковое пространство при обработке видео (полученный файл будет намного меньше файла со сжатием без потерь).
Двухпроходное сжатие
Двухпроходный режим, как ясно из названия, состоит из двух проходов. При первом проходе кодер анализирует информацию о сложности сжатия (сжимаемость, compressability) видеоряда и записывает её в специального вида файл (log file). На втором проходе кодер сжимает видеозапись, используя полученную при первом проходе информацию для перераспределения битов между различными сценами и кадрами. После первого прохода создаётся только файл с анализом видеоряда — и никакого видео. Однако для того чтобы обойти ограничение системы Video for Windows, программа по работе с видео вынуждена создавать видео файл: он остаётся пустым и не содержит какой-либо видеозаписи. Готовая видеозапись получается только после второго прохода.
Очень важно, чтобы при обоих проходах кодер работал с абсолютно одинаковым видеорядом: двухпроходный алгоритм основан на таком требовании. Таким образом, все настройки по обработке видеоряда должны быть абсолютно одинаковыми для первого и второго проходов: точно те же эффекты, фильтры с точно теми же настройками, одинаковые части видео должны быть вырезаны. В некоторых случаях получить второй раз точно такой же видеоряд невозможно: например, при записи с ТВ приёмника или при захвате аналогового видео (вам не удастся синхронизировать процесс захвата с точностью до кадра) — в таком случае нужно использовать однопроходный режим. В случае, если необходимый видеоряд получить очень сложно (например, вы хотите сжать полученную в результате обработки видеозапись, процесс обработки которой занимает несколько суток), вы можете вместо первого прохода использовать однопроходный режим с постоянным качеством и с записью анализа видеоряда (см. предыдущий раздел) — тогда второй проход нужно будет выполнить используя не исходный, а полученный на первом проходе файл.
Двухпроходный режим — самый эффективный для создания высококачественных архивных видеозаписей. С одной стороны, он позволяет контролировать размер сжатого видео, что удобно при записи на архивные носители (CD или DVD). Для расчёта целевого битрейта, исходя из ёмкости носителя, длины фильма и наличия звуковой дорожки (или нескольких дорожек), удобно использовать утилиты-калькуляторы (bitrate calculators). С другой стороны этот режим обеспечивает максимально возможное качество изображения для заданной ширины потока данных: благодаря предварительному анализу видеоряда кодер может распределять биты между разными сценами и кадрами эффективнее, чем в случае однопроходного алгоритма. Для включения этого режима в кодере DivX нужно выбрать Multipass, 1st pass для первого прохода или Multipass, nth pass для второго прохода, и ввести необходимое значение средней ширины потока данных в поле Encoding bitrate (в Кбит/сек) или рассчитать необходимое значение при помощи калькулятора (кнопка Bitrate Calculator). Вы можете выбрать имя файла для анализа видеоряда, нажав кнопку Select. Для включения первого прохода этого режима в кодере XviD для нужно выбрать режим Twopass — 1st pass, в дополнительных настройках (more) выключить Full quality first pass и включить Discard first pass. Вы можете выбрать имя файла, в который будет записана информация об анализе видеоряда при помощи кнопки «…». Для включения второго прохода этого режима в кодере XviD нужно выбрать режим Twopass — 2nd pass, в поле Target bitrate ввести необходимое значение средней ширины потока данных (в Кбит/сек) или рассчитать необходимое значение при помощи калькулятора (кнопка Calc). Вы можете выбрать файл с анализом видеоряда при помощи кнопки «…» в окне дополнительных настроек (кнопка more).
Многопроходное сжатие
DivX, начиная с версии 5.03, предоставляет возможность выполнять второй проход несколько раз подряд, это называется N–ным проходом (Nth pass). При выполнении N–ного прохода информация о распределении битов между кадрами модифицируется и записывается в файл с информацией об анализе видеоряда (если в настройках кодера не отключен режим Update log file). Таким образом, каждый следующий N–ный проход сжатия более эффективно распределяет биты между кадрами видеоряда, что ведёт к более высокому качеству сжатого видео при том же размере. В Официальном руководстве по DivX 5.2 достаточно дипломатично сказано «обычно оптимальное качество на 98–99% достигается за 3 прохода или менее». Вряд ли имеет смысл делать больше трёх проходов сжатия, да и третий проход, скорее всего, существенно поможет лишь при малых потоках данных (скажем, менее 700 Кбит/сек) — то есть когда небольшое перераспределение битов между кадрами может существенно повлиять на качество изображения.
Формат контейнера видеозаписи
Видеозапись состоит из видеоряда, звуковой дорожки (или нескольких), субтитров (возможно, нескольких), текстовых комментариев к ней и т. д. Файл, в который сохраняется видеозапись, имеет специальный формат. Помимо собственно видеоряда и звуковой дорожки он должен содержать некоторую служебную информацию: какой формат применён для сжатия видео и звука, так называемый индекс (index, блок данных, который содержит адреса расположения конкретных участков записи — он используется во время перемотки), текстовые описатели (тэги, tags — название записи, автор, информация об авторских правах и прочее). Формат такого файла называют контейнером (container). Процесс объединения набора файлов видеозаписи в один называется mux (сокращение от «multiplex», не путайте с mix — микширование), процесс выделения отдельных компонентов записи в файл — demux (demultiplex). Ниже я буду использовать русские термины внедрение (сведение) и извлечение.
AVI
Традиционный контейнер для видеозаписей — это AVI (Audio and Video Interleaved). Любая версия Windows содержит специальную программу (splitter или demultiplexer), которая обеспечивает воспроизведение файлов этого формата. Контейнер AVI имеет целый ряд ограничений: невозможно использовать звуковую дорожку в формате OGG Vorbis, не все программы поддерживают отображение внедрённых в AVI субтитров. Некоторые аппаратные проигрыватели не поддерживает переменный поток данных у звуковых дорожек (VBR, variable bitrate).
Поскольку контейнер AVI — стандартный контейнер для видеозаписей в системе Windows, его поддерживают все программы, которые работают с видео. Расширенные возможности по работе с AVI, как то: внедрение субтитров, множества звуковых дорожек, использование VBR звука, поддерживает VirtualDubMod и AVIMux_GUI (последний даже поддерживает формат сжатия звука AAC). Предпочтительно использовать для видеозаписей именно этот контейнер, в силу его универсальности и совместимости.
Ogg (OGM)
Серьёзный конкурент AVI — Ogg или OGM (Ogg Media Format). В рамках проекта Ogg разработан формат файла-контейнера и ряд форматов сжатия звука: Vorbis, FLAC и другие. Изначально этот контейнер планировалось использовать только для звуковой информации, но оказалось, что в него можно внедрить и видео данные. Для воспроизведения таких видеозаписей Tobias Waldvogel разработал DirectShow splitter для контейнера Ogg — с этого и началось его повсеместное распространение. Чтобы отличать видео файлы от звуковых, видео файлы начали называть OGM (хотя формально они используют тот же контейнер Ogg, что и звуковые файлы). Этот контейнер поддерживает субтитры, VBR звук и, конечно, звуковую дорожку в формате Ogg Vorbis. «Накладные расходы» контейнера OGM (блок index и прочая служебная информация) занимают больше места, чем в AVI.
Возможность интегрировать субтитры внутрь файла с видеозаписью была впервые реализована именно в программах для работы с контейнером OGM, что послужило причиной широкого распространения этого контейнера для видеозаписей. Сегодня множество записей (иногда даже с mp3 звуковой дорожкой) упаковываются в OGM. Однако контейнер Ogg разрабатывался как контейнер для потокового вещания через интернет (streaming), потому он не вполне подходит для хранения записей: например, иногда не работает перемотка записи назад.
Для работы с этим форматом сжатия звука и контейнером необходимы: DirectShow декодер Ogg, OGM splitter, OGM mux утилита (VirtualDubMod также поддерживает этот контейнер). Учтите, что декодер и splitter нужны также и для воспроизведения OGM файлов.
Матрёшка
Ещё одна альтернатива — контейнер Матрёшка (по-английски его называют Matroska). Это проект с открытыми исходными кодами. Он содержит несколько уникальных возможностей, например, субтитры в Матрёшке всегда хранятся в универсальной кодировке Юникод, что позволяет избежать проблем с кодировкой текста субтитров. Этот формат разрабатывался специально для хранения аудио и видеозаписей. Он основан на стандарте XML и обеспечивает двустороннюю совместимость: ваша запись может быть воспроизведена любым проигрывателем при помощи любого декодера (splitter’а) этого формата. «Накладные расходы» контейнера Матрёшка (блок index и прочая служебная информация) заметно меньше, чем в AVI. Если вы согласны использовать для своих записей нестандартный контейнер (не AVI), то Матрёшка — однозначно лучше Ogg.
Для работы с этим форматом также нужен комплект из Matroska splitter и утилиты для Matroska mux — они же нужны и для воспроизведения таких файлов. VirtualDubMod и AVIMux_GUI также поддерживают этот контейнер.
Windows Media, RealMedia, QuickTime, MP4 и другие
Microsoft продвигает контейнер для видеозаписей собственной разработки — Windows Media. В этом контейнере могут использоваться только форматы сжатия Windows Media разных версий: WMA (Audio) и WMV (Video). Работать с этим контейнером может Microsoft Windows Movie Maker. Сохранять видео в этот контейнер также может iuVCR. Формат этого контейнера закрытый, потому VirtualDub и другие программы не в состоянии его считать. Также пока не существует аппаратных проигрывателей, способных воспроизводить видеозаписи в WMV — на момент написания статьи только появилась информация о планах выпуска таких устройств. По описанным выше причинам формат этот не очень популярен.
В определённых приложениях распространены контейнеры MPEG для MPEG–1 и –2 потоков (они используются для записи Video CD и DVD). Контейнер RealMedia используется для хранения записей в формате RealVideo и RealAudio, потому он также мало распространён (как и Windows Media — это закрытый формат). Контейнер Apple Quicktime используется в первую очередь на компьютерной платформе Apple. Контейнер и не плох и универсален, но поддержка его на платформе Windows очень ограничена, формат — закрытый, потому — не популярный.
В стандарте MPEG–4 также есть описание контейнера — MP4. Его сейчас редко используют, но завтра ситуация может измениться. Уже сегодня некоторые программы — например, 3ivX и Nero Digital — обеспечивают поддержку этого контейнера. Основным форматом сжатия звука для этого контейнера является MPEG-4 AAC.
DivX Networks, разработчик совместимого с MPEG–4 формата сжатия DivX, обещают в середине 2005 года выпустить новую версию: DivX Q, которая будет включать в себя не только сжатие видео, но и формат для сжатия звука и формат контейнера (подробнее см. интервью).
Совместимость с аппаратными проигрывателями
Форматы дисков, совместимые с аппаратными проигрывателями Video CD или DVD — это набор соглашений о размере кадра видео, потоке данных, используемых форматах сжатия для видео и звука, ограничение на размер файла, способ именования файлов и расположения их по каталогам, и так далее. На компьютере вполне возможно создать диски, которые удовлетворяют спецификациям Video CD (MPEG–1, 352×288, 1150 Кбит/с CBR), Super Video CD (SVCD, MPEG–2, 480×576, 2500 Кбит/с VBR) или DVD (MPEG–2, 720×576, 6-8 Мбит/с VBR). Процесс подготовки и обработки видеозаписи для совместимости с аппаратными проигрывателями называется authoring (транскрипция: а́вторинг). Существует целый рад программ для авторинга DVD, которые позволяют подготовить записи, совместимые с аппаратными DVD-проигрывателями. В интернете вы можете найти множество информации по этому вопросу, например, на сайте Doom9 (на английском) или на сайте М. Афанасенкова (на русском). Подготовка записей в форматах VCD/SVCD описана в статье Как и из чего делать VCD/SVCD.
Аппаратные проигрыватели MPEG–4 более демократичны: они будут воспроизводить любой AVI файл, для которого они способны декодировать видео и звук. Набор ограничений у аппаратных MPEG–4 проигрывателей разнится от модели к модели, потому следует обратиться за подробностями к документации, вебсайту производителя проигрывателя и чипа декодера, или же к какому-нибудь тематическому форуму в интернете (например, форуму сайта Doom9).
| 2 августа 2004 г. | 
Андрей Гуле
|
|
| Дополнительно |
|
