на главную страницуна главную страницуна главную страницу

Новости | 3D-Видео, тюнеры и LCD | iT-Среда | MacLife | Мобильные устройства | Ноутбуки | Носители информации | Платформа ПК | Приложения и утилиты | Принтеры и периферия | ProAudio | Проекторы и ТВ | Сети и серверы | Цифровой звук | Цифровое видео | Цифровое фото | Карта сайта | Поиск

DivX: особенности сжатия видео в домашних условиях


Введение

Данная статья не претендует на полное описание процесса сжатия видео в формат DivX. Тем более, что в интернете полно описаний процесса перевода видео с DVD или VCD в DivX или SVCD. Лично мне эта информация показалась недостаточной, что стало причиной собственных исследований. Ниже я опишу результаты, которые были получены мною в ходе решения конкретной практической задачи. Чтобы отыскать наиболее оптимальный режим сжатия, я проделал некоторую работу, провел различные тестирования и сравнения — их результаты будут приведены в полном объеме. Я далек от мысли «вывести универсальный для всех рецепт» — у каждого свои требования, свои предпочтения. Однако приведенная ниже информация поможет вам при решении аналогичных задач предоставит дополнительную информацию для выбора своего оптимума.

Предполагается, что читатель уже имеет определенные знания и навыки по нелинейному монтажу цифрового видео, хотя бы на базовом уровне. Также вся работа с видео будет проводиться при помощи программ VirtualDub и NanDub — навык их использования будет очень кстати.

От автора

Автор в полной мере понимает необходимость четкого структурирования материала. Однако на сегодня существует такое количество информации, посвященной сжатию видео при помощи DivX, что мне приходится идти на компромисс. Эта статья не претендует на всеохватывающее изложение всего, что касается данной темы. Последовательность изложения материала выбрана такой, чтобы максимально упростить для восприятия весь материал в целом. Я отдаю себе отчет в том, что многим неинтересны некоторые разделы этого изложения. В любом случае, я советую при первом чтении просмотреть весь материал — хотя бы ради того, чтобы запомнить, в каком разделе говорится об интересных для вас деталях. Также это важно для того, чтобы не пропустить объяснение какого-нибудь термина: все термины вводятся по мере необходимости прямо в тексте, их первое использование выделено курсивом.

Исходная задача

Итак, сверхзадача. Я захотел преобразовать видеоролики с сайта BMWfilms.com из формата Apple QuickTime 5 в DivX. Причин тому много. Это и много большая распространенность формата DivX (в частности, возможность проигрывания не только под Windows, но и под различными клонами Unix), и меньшая ресурсоемкость его декодеров (например, на моем домашнем iCel 433 исходные ролики в формате QuickTime не могут проигрываться без пропуска кадров, а результат в DivX — запросто), и наличие огромного количества программных проигрывателей на любой вкус (в контексте интересовала возможность наложения внешних субтитров: ролики-то на английском, который понимают далеко не все мои знакомые. Делать голосовой перевод у меня наглости не хватает, а вот перевести субтитры — запросто). На результаты вы можете полюбоваться у меня на сайте.

Распространено мнение о «нелегальности» DivX. Сам по себе формат не может быть нелегальным. Противозаконными могут быть лишь действия, противоречащие действующему законодательству — совершенно безотносительно использования формата сжатия видео DivX. Так, распространение в формате DivX видеопродукции, защищенной Законом об авторском праве, в нарушение прав распространителя является незаконным. Но не потому, что используется «нелегальный формат DivX», а потому, что нарушается закон: нарушаются права распространителя. Лицензионное соглашение с сайта BMWfilms.com позволяет для личного некоммерческого использования делать с этими материалами что угодно. Раз так — приступим!

Как прочесть видео в формате QuickTime?

Начну издалека. Этот вопрос имеет смысл осветить, так как он звучит слишком часто. В конференции FIDOnet ru.mpeg этот вопрос задается чуть ли не раз в две недели. Итак, поставим себе задачей конвертировать видео в формате Apple QuickTime в какой-либо другой формат.

Для чтения видео в формате QuickTime вам понадобится установленный проигрыватель Apple QuickTime. Номер необходимой версии зависит от содержимого файла, который вы хотите конвертировать — то есть, ваш файл должен проигрываться вашим проигрывателем. Собственно преобразование проводит программа RAD Video Tools — просто найдите нужный файл и нажмите Convert. RAD предложит вам выбрать параметры преобразования видео (я предпочитаю все преобразования делать потом — в Dub'е), после этого вы сможете выбрать кодек для сжатия видео. Я предпочитаю на этом этапе использовать сжатие видео без потерь — но это дело вкуса.

Кстати — для сжатия видео без потерь очень хорош кодек HuffYUV — его основное преимущество в том, что он обрабатывает видео в формате YUV (именно такое цветовое пространство используется в большинстве источников цифрового видео), а не RGB. Кодек сжимает видео почти вчетверо абсолютно без потерь качества.

Как ни хороша программа RAD Tools, но звук из файла QuickTime ей удается прочесть в очень редких случаях. Для записи звука из видеоролика я использовал программу Total Recorder. Эта программа устанавливает в вашу систему дополнительный драйвер устройства для вывода звука, который позволяет весь звук, издаваемый какой-либо программой, записать в файл. Установите программу, запустите проигрыватель QuickTime. В его параметрах (Edit | QuickTime Preferences… | Sound Out) установите вывод на устройство Total Recorder. Включите запись в Total Recorder'е (собственно запись начнется только после того, как проигрыватель QuickTime начнет издавать звуки). Запустите на проигрывание ваш видео клип. После окончания проигрывания остановите Total Recorder. Полученный файл вы можете сохранить как в формате wav, так и в формате mp3 (сжатие при помощи установленного в вашей системе ACM-кодека). Лично я предпочитаю сохранить звук в wav, а потом сжать его при помощи LAME.

В ходе работы я угробил приблизительно день на то, чтобы разобраться с неполадкой во взломанной версии Total Recorder 3.3. Бесплатная демонстрационная версия этой программы записывает только 40 секунд звука. После взлома программа записывает звук и дальше сороковой секунды, только вот секунды после 50-й звук безнадежно портится и тонет в хрипе и треске. Очевидно, это происходит из-за некорректного взлома программы (постфактум могу сказать, что версия программы без взлома работает отлично). Пусть это послужит иллюстрацией для любителей «ломанного» софта.

Таким образом, мы получили возможность извлечь из файла QuickTime как звуковую информацию, так и видеоряд. Что делать со звуком — ясно, об этом сказано и написано очень много, в том числе и мною. Разберемся теперь с видео.

Метод подбора параметров видео сжатия

Очевидно, что наилучшим методом подбора параметров процесса сжатия для любого видеоматериала будет «закодировать, посмотреть, оценить, скорректировать параметры, закодировать еще раз». Также очевидно, что такой метод займет неразумно много времени.

Я не претендую на новизну этого метода, однако на практике оказалось очень удобно вырезать около десяти фрагментов по 2-3 секунды из исходного материала с самыми разнородными сценами. Получился эдакий ролик длиной около тридцати секунд. Во-первых, его несложно просмотреть от начала до конца: даже с пристальным изучением некоторых кадров это не занимает много времени. Во-вторых, кодирование такого ролика занимает несравнимо меньше времени, чем кодирование всего материала. Сохраните такой ролик либо совсем без сжатия, либо в каком-то формате сжатия видео без потерь (опять же — очень хорош для этого HuffYUV). Естественно, что кодировать полученный ролик надо с тем же средним битрейтом, с которым вы планируете кодировать весь материал.

Какие сцены лучше включить в пробный ролик? Ответ на этот вопрос совсем не очевиден. Я считаю, что нужно включать максимально разнородные сцены: как с быстрыми эволюциями, так и с отсутствием движения в кадре — просто чтобы заставить кодер поработать в разных режимах. Отличным примером подбора сложных для сжатия сцен, в которых кодер выкладывается на все 100%, может послужить сравнение качества кодирования видеокодеров на сайте Doom9 - там автор предлагает сцены со взрывами, морским прибоем, множеством мелких частиц во всем кадре, ночные и подводные сцены.

Мне в некотором роде повезло: такие ролики были сделаны до меня. Для раскрутки своей продукции BMW of North America сделала 30-секундные рекламные ролики (trailers). Именно один из них я и использовал в своих изысканиях: Ambush. В качестве исходного материала я взял вариант высокого качества в формате Apple QuickTime, который вы можете скачать при помощи программы BMW film player. Этот ролик длится 30,063 секунд (24 кадра в секунду, 722 кадра) и имеет разрешение 800 на 340 точек (соотношение сторон 2,35:1). В дальнейшем изложении я буду приводить номера кадров именно из этого ролика — каждый из вас может повторить мои действия и проверить мои результаты. Этот ролик в формате HuffYUV 2.1 занимает около 180МБ (184 099 328 байтов).

На данном этапе у нас есть точная копия видеоряда, который содержался в исходном файле в формате Apple QuickTime. В следующем разделе будет предъявлено несколько кадров обработанного видео — во всех случаях использовалось сжатие видео без потерь информации.

Вычищение артефактов MPEG-сжатия

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

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

Попробуем подобрать видеофильтр, который позволит решить нашу проблему.

Видеофильтр — это программа, которая выполняет дополнительную обработку видео в процессе нелинейного монтажа. Действие фильтра аналогично различным эффектам в графическом редакторе: берется изображение на входе и с помощью некоторого алгоритма строится изображение на выходе. Некоторые видеофильтры могут оперировать не с одним кадром, а с цепочкой из нескольких кадров. VirtualDub содержит ряд стандартных фильтров. Также вы можете найти множество полезных фильтров для VirtualDub на сайте Дональда Графта.

2D Cleaner

Версия: Beta 0.6, автор — Джим Касабури, также проверялась версия 0.9, оптимизированная и доработанная Дональдом Графтом. Этот фильтр усредняет значения пикселов в заданном радиусе от исходного пиксела, если их значение не превосходит порога. Это позволяет избавиться от низкоуровнего шума, не смазывая резких границ. Даже из этого описания видно, что этот фильтр вряд ли нам подходит.

Посмотрим на результаты его работы: при низких значениях параметров (10 для порога и 2 для радиуса) получаем слишком слабое улучшение качества картинки:

При высоких значениях параметров (20 для порога и 5 для радиуса) картинка слишком сильно смазывается:

Ни при каких других значениях параметров я не смог получить удовлетворительных результатов.

Smoother

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

Однако уже при таком значении порога заметно сглаживание существенных деталей изображения (обратите внимание на лицо водителя):

Для сравнения — исходный кадр:

Temporal Smoother

Это также стандартный фильтр. Он должен усреднять значение пикселов из кадра в кадр — то есть в зависимости от времени, а не от пространственной координаты. Очевидно, что этот фильтр нам не подойдет:

Та же картина сохраняется при любых значения параметра (количества кадров для усреднения).

Тот же результат показал фильтр Temporal Cleaner, версия Beta 0.5, автор — Джим Касабури. По сути это сильно модифицированный и доработанный стандартный Temporal Smoother, однако и он нам не подходит.

Smart Smoother

Версия: 1.1, автор — Дональд Графт. Этот фильтр усредняет значения пикселов, однако сохраняет структуру изображения, что делает его идеальным для квадратных артефактов, характерных для сжатия MPEG/JPEG. Автор утверждает, что фильтр не то что не размывает изображение, а даже чуть повышает четкость.

Вроде как раз такой фильтр нам и нужен. Посмотрим, на что он способен:

Результат соответствует ожиданиям, однако не все так радужно. Вопреки утверждению автора, фильтр заметно размывает картинку:

Для сравнения — исходный кадр:

Я также попробовал использовать доработанный вариант этого фильтра, Smart Smoother HQ (High Quality), версии 2.11, написанный Клаусом Постом. Эта вариация содержит дополнительные возможности, призванные сохранить структуру исходного изображения и уменьшить размывание. Результат работы этого фильтра превзошел все ожидания.

Легко видеть, что квадраты в исходном видеоряде имеют размер 8 на 8, потому в качестве радиуса действия фильтра я выбрал 11 — с запасом больше размера артефакта, от которого я хочу избавиться. Порог срабатывания и оставил по умолчанию — 50. Качество получаемого результата не сильно зависит от этого параметра. Значение Amount, конечно, было максимальным — иначе зачем весь сыр-бор? Я выбрал взвешенный режим усреднения (Weighted average) пикселов — именно его автор советует для кино (кстати, в исходном фильтре Smart Smoother Дональда Графта используется только режим Average Pixels).

При выключенном параметре Weighed with difference этот фильтр смазывает изображение, пожалуй, еще больше, чем Smart Smoother:

Однако стоит нам включить Weighed with difference, как картина кардинально меняется, даже присутствует сетчатая структура на месте наших квадратов (Maintain Diffweight = 0):

Кстати, этот фильтр имеет прекрасную возможность: он умеет наглядно показывать, он делает. При включении параметра Visualize Blur весь кадр заливается белым цветом, а серым отмечаются области, где работает механизм повышения четкости. То есть, белые области размываются, черные — нет. Серые — пропорционально яркости. Этим методом очень удобно проверять, не размывает ли кодер важные для нас детали, и не сохраняет ли лишних артефактов. Главное — не забыть выключить этот параметр перед запуском процесса сжатия.

Так, картинка при выключенном Weighed with difference выглядит так:

При включенном Weighed with difference:

Эти две иллюстрации подтверждают увиденное ранее: при включении Weighed with difference изображение размывается намного меньше, причем даже сохраняется сетчатая структура от наших квадратов.

К счастью, мы можем управлять чувствительностью механизма определения деталей изображения при помощи параметра Maintain Diffweight. Если мы установим его значение в 5, то исчезнет сетка — с другой стороны, изображение все еще будет размываться много меньше, чем при выключенном Weighed with difference:

Также мы можем убедиться, что и в кадре 200 детали лица водителя не размыты:

Таким образом, для того, чтобы убрать артефакты MPEG-сжатия, лучше всего подходит фильтр Smart Smoother HQ в режиме Weighted average, Weighed with difference, а режим Visualize Blur позволяет наглядно и удобно подобрать необходимое значение параметра Maintain Diffweight. Полученный результат был записан в файл со сжатием без потерь — для того, чтобы не выполнять эту операцию каждый раз при сжатии DivX. Фильтр Smart Smoother HQ исключительно ресурсоемкий: обработка 30-секундного ролика на Intel Pentium 833 MHz длится 14 минут (исходный файл и результат сжаты HuffYUV). Также стоит помнить о том, что и этот фильтр сглаживает изображение — в моем случае, с этим можно смириться в силу огромного разрешения исходного материала. Если у вас на входе запись с ТВ-тюнера с разрешением в 384 пискела, вас вряд ли устроит такое снижение четкости. Как я уже говорил выше, не существует универсального рецепта: для каждого случая фильтры и настройки придется подбирать отдельно.

Интересно также привести такое косвенное подтверждение сказанного выше: все фрагменты после обработки разными фильтрами были сжаты кодером DivX 5 в режиме 1-pass quality based, quantizer 4 (quality 93%). Я получил файлы следующих размеров (в байтах):

2D Cleaner 5 443
584
2D Cleaner optimized 5 398
528
Smoother 5 056
512
Temporal Smoother 5 767
168
Temporal Cleaner 5 783
552
Smart Smoother HQ 4 755
456

В этом режиме сжатия размер файла тем меньше, чем больше сглажено изображение (тем проще кодеру сжимать). Тут мы видим, что некоторые фильтры сглаживают существенно лучше других — это Smoother и Smart Smoother. Выбор между ними был обоснован выше на основании качества результата.

Анализ многообразия DivX-кодеров

На сегодня в семействе DivX существуют кодеры версий 3, 4 и 5. Кодер 3-й версии представляет собой кодер Microsoft MPEG4 v.3 со взломанными ограничениями, как то: запрет записи в avi-файл и прочие. Собственно алгоритм сжатия не был изменен в процессе взлома, потому кодер DivX 3.x создает такой же поток данных, как и MS MPEG 4.3. Однако, DivX использует другую подпись кодера (FourCC) что приводит к тому, что видео в формате DivX не воспроизводится декодером MS MPEG 4.3. Последняя немодифицированная версия DivX кодера — 3.11. Позже кем-то была выпущена версия 3.20, которая содержала дополнение к алгоритму сжатия: механизм определения смены сцены (scene change detection). Также иногда в сети можно встретить DivX версии 3.22, которая по части сжатия видео ничем не отличается от 3.20.

Кодер DivX версии 4 был выпущен DivX Networks на основе завершившегося провалом проекта Open DivX — попытки создать MPEG-4 кодер с нуля (а, значит, полностью легальный — то есть без украденного кода Microsoft). Проект Open DivX работал по схеме с открытыми исходными кодами (open source), DivX Networks же свой код не разглашает. Первые версии кодера DivX 4 были весьма сырыми и давали более чем посредственный результат: это отрицательно сказалось на авторитете кодера DivX 4. Тем не менее, после вылова из кодера DivX 4 ошибок, мы получили отличный кодер видео: поддержка новых режимов кодирования, включая встроенную поддержку двухпроходного кодирования, множество настроек, ранее недоступных в DivX 3. Последняя версия кодера: DivX 4.12. На смену линии DivX 4 пришел DivX 5 — причем некоторые ошибки кодека DivX 4.12 так и перекочевали в более поздние версии, то есть DivX 5. Поэтому я настоятельно не рекомендую сегодня использовать кодеки DivX 4-й версии — даже минимально функциональная версия кодека DivX 5 полностью включает в себя функциональность DivX 4.12.

Следующая версия DivX-кодера в исполнении DivX Networks — версия 5.0, которая по сути своей продолжает линию DivX 4 (один из файлов поставки DivX 5.0 имел номер версии 4.13). В пятой версии нам предлагают еще больше сервисных возможностей, например, пресеты (preset), обрезка видео (cropping), deinterlace и так далее. Также пятая версия содержит существенные дополнения к алгоритмам кодирования видео: поддержка B-frames, Global motion compensation, работа с векторами движения с повышенной точностью (до четверти пиксела — quarter pixel). Впервые была представлена психовизуальная модель, которая учитывает особенности человеческого зрительного восприятия для определения областей видео, где можно сэкономить на размере: сделать картинку чуть похуже — ведь все равно глаз не заметит. Начальные версии DivX 5 содержали уйму ошибок в новом коде, которые часто приводили к краху программы сжатия видео или получению видео отвратительного качества. Последняя на сегодня версия — 5.02 — относительно стабильна и не замечена в создании откровенно провальных результатов.

Также заслуживает упоминания то, что DivX Networks решила начать получать деньги за свой видеокодер. DivX 5 поставляется в трех вариантах: DivX 5, DivX 5 Pro Ad, DivX 5 Pro Licensed. Каждая из версий содержит полнофункциональный декодер видео: то есть, если вы не планируете использовать кодер DivX 5 для сжатия видео, вам вполне достаточно минимальной версии DivX 5. Также первый из указанных вариантов кодера DivX 5 поддерживает сжатие видео во всех режимах, но дополнительные возможности сжатия ограничены в объеме кодера DivX 4 — нет поддержки поддержки B-frames, Global motion compensation, работы с векторами движения с повышенной точностью. Правда, психовизуальную модель использовать можно. Второй и третий вариант кодера абсолютно эквивалентны функционально и поддерживают все новинки DivX 5. Разница между ними в том, что Ad версия дополнительно устанавливает вам в систему программу для показа рекламных банеров — таким образом DivX Networks получает деньги за Pro-версию своего кодера. Licensed-версия рекламу не показывает, зато ее покупка стоит $30. В интернете можно найти множество программ для взлома DivX 5 Pro Licensed, однако лично я к ним отношусь более чем осторожно: не хочу для создания архивных копий видео пользоваться программой, в которой колупались шаловливые ручки какого-то хакера. Выше я уже приводил пример с Total Recorder 3.3: взлом программы привел к полной ее неработоспособности. DivX 5 Pro Ad функционально совершенно аналогична DivX 5 Pro Licensed, реклама показывается только в случае наличия соединения с интернетом — все не так уж и плохо. К тому же отключить программу для показа рекламы более чем просто.

Ради полноты картины замечу, что на сегодня существует и развивается проект по созданию видеокодера MPEG-4 с открытым кодом — речь идет о XviD. Однако этот кодер весьма далек от стабильности: то и дело выпускаются версии, которые дают абсолютно недопустимые результаты (см. сравнение качества кодирования видеокодеров на сайте Doom9). Мне кажется неразумным использовать такой кодер для создания архивных копий видеоматериала.

Выбор режима сжатия

Существует четыре режима сжатия, в которых работают кодеры стандарта MPEG-4 (в частности, DivX) — это однопроходный с постоянным битрейтом, однопроходный с переменным битрейтом, однопроходный с постоянным качеством и двухпроходный. Рассмотрим подробнее принципы работы каждого из режимов.

Однопроходный режим с постоянным битрейтом

Однопроходный режим с постоянным битрейтом самый простой: каждый кадр (или группа кадров — например, 25 последовательных кадров, это одна секунда видео) имеет одинаковый размер. Результирующий поток видеоданных имеет постоянный битрейт, что и определяет основное применение такого режима: цифровое видеовещание (digital video broadcasting). Также следует помнить, что алгоритм этого режима весьма простой, и, соответственно, нересурсоемкий — это может оказаться очень полезным в случае сжатия видео в реальном времени, например при оцифровке видео. Однако, результаты, полученные в таком режиме, существенно уступают результатам в других однопроходных режимах. На сколько мне известно, ни один из кодеров DivX не позволяет сжимать видео в таком режиме. Если вам необходим такой режим сжатия — а это, повторю, допустимо только в случае видео вещания — обратитесь, например, к решениям от Microsoft: их вещательный сервер содержит поддержку кодеров MS MPEG-4.

Однопроходный режим с переменным битрейтом

Однопроходный режим с переменным битрейтом реализует простейшую схему по избавлению от главного недостатка постоянного битрейта: одинаковое количество бит на каждую сцену, вне зависимости от сложности этой сцены для сжатия. Этот режим реализует простую схему: если кадр простой для сжатия, то мы используем лишь часть выделенных для нее битов. Остальные биты «откладываются» в своего рода копилку — резервуар (resevoir). Благодаря этому на сложных сценах мы можем использовать больше бит для сжатия кадра — заимствуется часть битов из резервуара. Данная схема проста и эффективна, потому с одной стороны она дает много лучшее качество изображения, чем в режиме с постоянным битрейтом. А с другой стороны — алгоритм сжатия не на много сложнее и вполне может использоваться для сжатия видео в реальном времени.

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

Этот и только этот режим был в своем время реализован в кодере DivX 3.11 (3.20 лишь дополнил его механизмом определения начала новой сцены). Две вариации этого кодера — Fast motion и Low motion — это не более чем пресеты, оптимизированные под динамичные сцены и под сцены с малым количеством движения. Поскольку редкий материал включает в себя только динамичные или только статичные сцены, то использование любого из этих режимов не дает оптимального результата.

В свое время — когда не было альтернативы DivX 3 с его однопроходным режимом — был даже создан инструментарий, который позволял склеивать видеоматериал из кусочков: эта сцена лучше смотрится закодированная Low motion, а эта же — напротив, High motion. Можете себе представить, насколько утомительным был процесс монтажа видео по такой схеме — существовавшие тогда алгоритмы автоматизации такого процесса были далеки от совершенства.

В кодерах DivX 4 и 5 этот режим называется «1-pass». Основной параметр в этом режиме — средний битрейт результирующего видеопотока. Следует понимать, что в результате описанных выше манипуляций с резервуаром на отдельный кадр может быть отведено битов как меньше среднего, так и больше. Также стоит упомянуть о том, что DivX 3 считает, что 1 kbps = 1024 bps, а для DivX 4/5 1 kbps = 1000 bps.

Однопроходный с постоянным качеством

Название этого режима — «с постоянным качеством» — не совсем корректно. В процессе сжатия остается постоянным так называемый quantizer — численная характеристика степени сжатия кадра. В программе NanDub этот параметр менее лаконично, но более вразумительно называется степень игнорирования деталей (detail removal factor, DRF). Стандарт сжатия MPEG использует аналогичное стандарту JPEG сжатие графической информации в кадре. Особенность этой схемы сжатия состоит в том, что чем выше степень сжатия, тем больше на сжатом изображении заметно квадратных блоков. Именно эту степень сжатия и описывает степень игнорирования деталей — чем этот показатель выше, тем больше сжатие, тем ниже качество, тем более заметны квадраты. Значения этого показателя могут быть от 2 (максимальное качество) до 31 (минимальное качество).

Данный эффект легче всего проиллюстрировать на примере сцены в кадрах 275-286: машина проносится мимо камеры на фоне темного неба, которое местами освещено несколькими источниками света:


Qualtiy: 100%, quantizer — 2.


Qualtiy: 90%, quantizer — 5.


Qualtiy: 80%, quantizer — 8.

В кодерах DivX 4/5 такой режим сжатия называется «1-pass quality based», основной параметр — средний уровень качества. В кодере DivX 5 также можно непосредственно указать значение quantizer — это позволит нам легко составить таблицу соответствия «уровня качества» в понимании DivX 5 и «степени игнорирования деталей»:

Quality, % Quantizer
100 2
97 3
93 4
90 5
86 6
83 7
79 8

Использовать более низкие значения quantizer'а я настоятельно не советую: квадраты будут очень заметны.

Кодер DivX 3 не поддерживает такой режим. Мне неизвестны программы, которые бы заставляли этот кодер работать в таком режиме.

Режим с постоянным качеством использует наиболее простой алгоритм сжатия, потому этот режим в первую очередь рекомендуется для сжатия видео в реальном времени — такой способ кодирования самый быстрый. Основной недостаток этого режима — мы не можем узнать заранее (до сжатия), какой размер будет иметь результат. Так, мы можем захотеть переписать час видеозаписи вечеринки с видеокамеры и записать его на один CD-R. Используя однопроходный режим с постоянным качеством мы рискуем получить как слишком маленький, так и слишком большой файл.

Двухпроходный режим

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

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

Кодеры DivX 4 и 5 содержат встроенную поддержку двухпроходного режима: у них есть два режима, для первого (2-pass, first pass) и второго проходов (2-pass, second pass) соответственно. Таким образом вы можете пользоваться двухпроходным кодированием при помощи любого видео редактора, который позволяет выбрать кодер видео.

Для использования кодера DivX 3 в двухпроходном режиме была создана модификация редактора VirtualDub, которая называется NanDub. Учтите, что NanDub был создан на основе относительно старой версии VirtualDub, потому в нем не содержатся исправления ряда ошибок, в частности для корректной работы с DivX 5. Использовать NanDub имеет смысл только там, где VirtualDub бесполезен: двухпроходное кодирование в DivX 3, создание avi файлов с двумя звуковыми дорожками и использование в avi VBR mp3 звуковой дорожки. Также следует учесть то, что NanDub требует наличия в системе кодера именно версии 3.11 — усовершенствования версий 3.20 и 3.22 полезны только для однопроходного режима, а в двухпроходном режиме они лишь мешают и портят результат.

К сожалению автор программы NanDub избрал простейший для программирования, но далеко не самый простой для использования, путь: он просто вывел в несколько окон настройки уйму параметров: как собственно кодера, так и алгоритма двухпроходного сжатия. Часто эти параметры влияют друг на друга вплоть до взаимного исключения. Некоторые параметры влияют на граничные режимы работы, которые практически никогда не встречаются на практике — эти параметры практически бесполезны. Долгое время NanDub был наилучшим решением для двухпроходного кодирования видео, за это время накоплено огромное количество опыта по выбору параметров сжатия. На русском языке информация наиболее полно представлена в руководстве Алексея Шашкова. Среди руководств по NanDub хочу выделить руководство, подписанное Koepi.

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

Так какой режим выбрать?

Лично я являюсь сторонником максимально качественного сжатия видео, потому для меня выбор однозначен: двухпроходный режим. Даже если задача состоит в оцифровке видео, я считаю вполне доступным на сегодня организовать захват видео в какой-либо формат сжатия без потерь (например, HuffYUV) — при нынешних ценах на жесткие диски это более чем доступно. В этом случае вы потратите намного больше времени, чем в случае оцифровки и параллельном сжатии видео в реальном времени, зато качество результата будет несравнимо лучше. Также такой режим существенно снижает требования к тактовой частоте процессора, на котором будет проводиться захват видео.

Размер видео

Наиболее объективной числовой характеристикой качества сжатого видео из известных мною на сегодня является среднее количество бит на пиксел (с учетом частоты кадров). Впервые я столкнулся с этой характеристикой в пакете для создания сжатых DivX копий DVD дисков GordianKnot. Эта величина отлично отражает качество сжатого видео для однородных источников видео: согласно моей статистике в почти 200 пиратских копий фильмов, для цифрового источника высокого качества (например, DVD) эта величина должна быть равна как минимум 0,20 для отсутствия в видеоряде явных огрехов кодирования. В случае, когда эта характеристика превышает 0,26, результат сжатия в DivX визуально идеален. В случае кодирования с VHS или видеокамеры (из-за наличия намного большего количества шумов) лишь результат сжатия при значениях выше 0,35 не вызывает отвращения. Таким образом, эта характеристика отражает степень передачи мелких деталей, а точнее — степень потери мелкий деталей в результате сжатия DivX.

Очевидно, что если мы снизим разрешение исходного видеоряда, то мы получим возможность выделить больше бит на каждый пиксел в кадре, а, значит повысим среднее количество бит на пиксел. С другой стороны понятно, что сильно уменьшая разрешение видеоряда мы будем терять мелкие детали. В некотором диапазоне эти две тенденции компенсируют друг друга и выбор компромиссного варианта зависит скорее от выбирающего. Так, я встречал человека, который предпочитает уменьшать размер видео до примерно 460 пикселов в ширину, что позволяет ему добиться значения около 0,35-0,40 для среднего количества бит на пиксел. Другие же считают, что уменьшение размера кадра привносит недопустимое количество искажений — хотя при высоком разрешении будет больше искажений за счет сжатия DivX (ведь среднее количество бит на пиксел получается меньше).

Для себя выбор размера видео я обосновываю другими причинами, которых существует целая уйма. Ниже я приведу все известные мне — возможно есть еще какие-то соображения. Учитывая сказанное выше, в первом приближении будем считать допустимым размер кадра по горизонтали от 460 до 800 пикселов.

Разрешение исходного материала

Причина первая — разрешение исходного материала. Очевидно, что не имеет смысла увеличивать размер видео: новых деталей это не добавит. Из-за того, что телевизионный сигнал обеспечивает четкость по горизонтали примерно в 500 точек, а стандарт DVD — примерно в 700 (720 или 704), то про 800 пикселов по горизонтали можно забыть. Разве что вы сами создаете видеоролик — например в 3D Studio. Или кодируете ролики с сайта BMWfilms.com ;-) В любом случае исходный материал в 800 пикселов в ширину -- это исключительная ситуация.

Разрешение монитора

Вторая причина — разрешение монитора. Знатоки считают — и с ними можно согласиться — что наивысшего качества воспроизведения видео на компьютере можно достичь, используя разрешение по горизонтали равное разрешению видео материала. В этом случае не используется масштабирование видеоряда, которое может привести к некоторому снижению качества картинки. Вы наверняка знаете, что все видеокарты поддерживают разрешение в 640 или 800 пикселов по горизонтали. Изредка также возможно выставить разрешение в 512 пикселов, однако я ни разу не слышал про видеокарты, способные выдавать разрешение в 704 или 720 пикселов. Честно говоря, поскольку подавляющее большинство народу не напрягает себя уменьшением разрешения ради просмотра видео, а смотрит прямо в рабочем разрешении (800, 1024, 1280 — у кого как), то эта причина носит скорее теоретический характер. Тем не менее для полноты картины я упомянул и ее.

Делимость чисел

Еще одна причина — делимость чисел. Дело в том, что на размер сжатого видео кодер DivX накладывает некоторые ограничения: макроблоки, на которые разбивается кадр в процессе сжатия, имеют размер 16х16 пикселов. Таким образом крайне желательно, чтобы размер результата сжатия имел целое количество макроблоков по горизонтали и вертикали — то есть делился на 16. Нарушение этого правила приводит иногда к весьма интересным и очень заметным артефактам, посмотрите, например, на кадр из фильма Snatch, закодированного в веселом состоянии одним моим знакомым в размер 592х321. Так его показывает декодер DivX 3.11:

А теперь посмотрите, как этот же кадр показывает декодер версии 5.02 (да и любая другая версия из линейки 4.х/5.х):

На протяжении всего фильма несколько раз снизу кадра появляются то голубые, то фиолетовые, то желтые пятна. Безусловно — это ошибка декодера. Декодеры версии 3 не содержат такой ошибки.

Также обращаю внимание, что DirectShow совместимые декодеры версий 4 и 5 при воспроизведении видео, которое имеет нечетный размер по вертикали, добавляет снизу кадра зеленую полоску высотой в один или три пиксела (чтобы высота кадра стала кратна 4), которая также здорово портит впечатление:

Кстати, всех описанных выше недостатков лишен DirectShow MPEG-4 декодер ffdShow. Он поддерживает воспроизведение видео в форматах DivX 3, 4, 5 (включая поддержку всех новый возможностей формата DivX 5), MS MPEG 4 v.1, v.2, v.3 и XviD. Этот декодер оптимизирован по скорости и работает примерно на 20-40% быстрее штатного декодера DivX. Он лишен основного недостатка DivX 4/5: в случае нехватки мощности процессора декодер пропускает кадры, а не воспроизводит видео с меньшей скоростью, что приводит к потере синхронизации между звуком и видео. Также декодер содержит исключительно разумное решение для выставления уровня постпроцессинга видео: уровень постпроцессинга регулируется автоматически в зависимости от загрузки процессора. В ffdShow вы сможете найти дополнительные фильтры по сглаживанию видео и для подчеркивания деталей, по добавлению шума для улучшения визуального восприятия низкокачественного видео и, конечно же, возможность регулировать яркость, контраст, цветность. Этот декодер разрабатывается по схеме с открытыми исходными кодами. На компьютерах некоторых конфигураций этот декодер работает медленее декодера DivX — однако будьте же снисходительны: проект пока только развивается. В любом случае вам стоит его попробовать — если у вас он будет работать нормально, то вы останетесь им довольны.

Очень распространено мнение, что кратный 16 размер видео нужен для того, чтобы при воспроизведении включались аппаратные возможности видеокарты по масштабированию видеоряда — т. н. оверлей (overlay). Это не так: в нормальном случае оверлей включается всегда при воспроизведении видео, вне зависимости от размеров кадра. Данное мнение сложилось из-за того, что многие достаточно распространенные видеокарты (Matrox G100, G200, G400, G450, некоторые модели nVidia Riva TNT) содержали ошибку в драйверах, которая позволяла использовать оверлей только для видео записей с горизонтальным размером кадра кратным 16 или 32. Для исправления этой ситуации была создана программа DivX G400 — она автоматически увеличивает размер видеоряда до числа, кратного 16 или 32 (за счет добавления черных полос по краям). Позже эта программа обросла большим набором удобных и полезных функций — например показ субтитров поверх видео, изменение соотношения сторон видео или частоты кадров «на лету» — так что теперь многие используют эту программу, даже если их видеокарта верно работает с оверлеем.

Вы можете сказать: «ну предположим, теперь у нас в 16 раз меньше вариантов, но и в этом случае между 460 и 800 их остается более чем достаточно: 20 штук». Давайте вспомним про соотношение сторон кадра. Как вы наверняка знаете, в подавляющем большинстве случаев видео записи имеют соотношение сторон 4:3, 16:9 или 2,35:1. Таким образом нам нужно выбрать такой размер по горизонтали, чтобы и размер по вертикали (полученный при помощи простой пропорции исходя из заданного соотношения сторон) также делился на 16. Легко видеть, что для соотношения 4:3 наилучшими вариантами получаются 768х576, 704х528, 640х480, 576х432 и 512х384. Для соотношения 16:9 (1,77:1) хороши 768х432, 656х368 и 512х288. Для 2,35:1 подойдут 752х320, 640х272 и 528х224. Иногда также встречается материал с соотношением сторон в 5:3 (1,66:1) — тогда подойдут 800х480, 720х432, 640х384, 560х336 и 480х288; а для 1,85:1 сгодятся 800х432, 624х336 и 592х320. По причине, указанной выше в замечании, не кратные 32 размеры по горизонтали не пользуются популярностью — хотя эта мера предосторожности совершенно излишняя — кратности 16 вполне достаточно.

Скорость декодирования

Вы наверняка не раз слышали, что видео записи, сжатые DivX, не могут нормально воспроизводится на слабых компьютерах. «Слабый» — это достаточно неточная характеристика, попробуем разобраться в этом вопросе подробнее.

Экспериментальным путем было установлено, что ресурсоемкость декодирования видео в DivX зависит от размера кадра — по сути от количества блоков, которые необходимо декодировать в единицу времени. Так, на моем домашнем Intel Celeron 433 MHz воспроизводятся все видеоролики в формате DivX, которые мне приходилось видеть, с размером вплоть до 800х340 (если не используется DivX 5 Qpel). Естественно, что для видео с большим размером кадра уровень постпроцессинга минимален, тогда как для видео с меньшим кадром вполне возможно и повысить качество декодирования. (Кстати, я уже и забыл, когда я в последний раз делал это вручную: декодер ffdShow позволяет регулировать уровень постпроцессинга автоматически в зависимости от загрузки процессора). На другой доступной мне для исследований машине — Intel Celeron 333 MHz — нормально можно воспроизвести только видео размера меньше, чем 496х372, 512х368 или 640х272 — то есть не более 190 тыс. пикселов в кадре. Естественно, все это при минимальном уровне поспроцессинга, использовании оптимизированного по скорости ffdShow и звуковой дорожке у видеоряда в формате mp3 — никакими ухищрениями невозможно повысить вычислительную мощность процессора: именно к ней декодирование DivX предъявляет повышенные требования.

Так какой размер выбрать?

В моем случае видео имеет соотношение сторон 2,35:1, причем размер по вертикали (340) не кратен 16. Очевидно, мне нужно уменьшить размер кадра. Абсолютно всем приведенным выше требованиям удовлетворяет разрешение 640х272, потому я остановился именно на нем. Так бывает не всегда, потому я в первую очередь советую выбирать разрешения кратные 16 — они перечислены в разделе Делимость чисел — и не увеличивать размер кадра. Требованием из раздела Разрешение монитора вполне можно пренебречь.

Обращаю ваше внимание, что уменьшение ширины на 20% позволяет практически на 40% уменьшить количество пикселов в кадре, что, в свою очередь, при том же битрейте приводит к примерно 60% увеличению среднего количества бит на пиксел. И, конечно же, пропорционально уменьшается требования к ресурсам процессора при декодировании видео.

Изменение размера видео

В каждом графическом редакторе используется два основных метода изменения размера изображений: линейная и кубическая интерполяция — bilinear и bicubic. Первую надо использовать при уменьшении размера, вторую — при увеличении. Нарушение этого правила приводит к нежелательным искажениям изображения, которые наиболее наглядно проиллюстрированы на сайте Nicky Pages. В предыдущем разделе мы уже договорились, что мы всегда уменьшаем размер кадра — значит нам нужно использовать линейное сглаживание. Выбор метода однозначен при работе со статическими изображениями — а вот в обработке видео не все так просто.

При использовании кубического сглаживания на границах объектов будут появляться четкие границы. Это, однако, совсем не плохо для подготовки к сжатию MPEG-4 — скорее наоборот. Революционное новшество стандарта сжатия MPEG-4 по сравнению с предыдущими (MPEG-1 и MPEG-2) состоит в том, что алгоритм способен обнаруживать в кадре движущиеся объекты, после чего проводится разделение кадра на статичные и подвижные области и сообразно этому делению разным областям кадра раздаются биты. Так вот подчеркивание границ объектов в результате кубической интерполяции играет на руку механизму нахождения движущихся объектов. С другой стороны алгоритму MPEG-4 куда как легче сжать изображение с более плавными цветовыми переходами: например в моем случае сжатый 1-pass quality based 100% quality DivX 5 видеоряд уменьшенный до 640х272 при помощи линейной интерполяции занимает приметно на 10% меньше места в сравнении с таким же видеорядом, уменьшенным при помощи кубического алгоритма. Конечно, не стоит забывать и о личных предпочтениях каждого: кому-то нравится подчеркивать детали, а кому-то нравится картинка с плавными цветовыми переходами.

Именно по описанным выше причинам до сих пор не устоялось единое мнение о том, какой метод интерполяции надо использовать при уменьшении размера видеоряда. Также нельзя не упомянуть о возникновении нескольких модификаций кубического метода, которые в разной мере подчеркивают детали, например bicubic soft, bicubic sharp.

Еще хочу упомянуть о таком распространенном заблуждении: кубическая интерполяция более точная (в частности, требует больших вычислительных ресурсов), чем линейная — а значит она лучше. Это неверно: на сайте Nicky Pages показан типичный пример — по-моему вполне достаточно посмотреть своими глазами и убедиться в превосходстве линейного метода при уменьшении размера.

Выбор кодера

Следующий вопрос — какой кодер выбрать и какие параметры использовать. Лучшее из известных мне на сегодня сравнение качества кодирования видео кодеров на сайте Doom9 лично меня не вполне устраивает: в нем используются настройки кодеров по умолчанию и совсем нет анализа влияния отдельных параметров на качество результата. Это сравнение лишь выявляет явных аутсайдеров (RealVideo 9, Windows Media Video 8, vp4, XviD) и оставляет нас все с тем же набором кодеров, который я привел выше: DivX версий 3 и 5 (поскольку DivX 5 по сути является продолжением линии DivX 4, не имеет ни малейшего смысла сегодня использовать какую-либо версию из линейки DivX 4).

Обратная совместимость

Отдельно хочу оговорить такой вопрос, как совместимость. Массовое распространение форматов MPEG-4 началось в эпоху DivX 3. Именно этот формат понимают проигрыватели под большинство из известных мне ОС: это Windows и достаточно популярный Linux, также и менее распространенные FreeBSD, MacOS, другие unix-клоны. Поскольку именно Windows сегодня самая популярная ОС на планете, то версии новых DivX кодеров выпускаются в первую очередь именно для Windows. Практически наверняка у каждого, кто хоть чуть-чуть разбирается в видео сжатии, сегодня установлен кодек DivX 5. На сайте DivX Networks доступна также версия кодека для Linux и MacOS — правда в обоих случаях функциональность кодера ограничена: в кодере для Linux нет возможностей DivX 5 Pro, а под Mac сейчас есть только декодер. А что делать владельцам других ОС? А что делать тем, кто когда-то установил себе под Windows DivX 3 кодек и горя не знал — а тут он вдруг получает файл, который не воспроизводится?

Я остановлюсь чуть подробнее на вопросах обратной совместимости кодеков DivX. Все декодеры DivX имеют поддержку декодирования старых форматов: то есть DivX 4 отлично справляется с воспроизведением материала, сжатого DivX 3, а DivX 5 отлично показывает DivX 3 и 4. С совместимостью в противоположном направлении не все так просто. Несмотря на то, что все версии DivX используют разные подписи кодера («DIV3», «DIVX» и «DX50» соответственно) их поведение при декодировании несколько неожиданно. Декодер DivX 3 просто не возьмется воспроизводить видео DivX 4 или 5. А вот декодер DivX 4 с радостью берется декодировать видео DivX 5, хотя далеко не всегда он это делает верно. Вернее Video for Windows совместимый декодер (который используют редакторы видео, например VirtualDub) откажется открывать неизвестный файл с подписью «DX50». А вот DirectShow совместимый декодер, который используют все программы проигрыватели видео, с радостью берется за воспроизведение видео, сжатого DivX 5. Если при создании такого видео не использовались новые возможности формата DivX 5, то видео воспроизводится корректно и без проблем. Если при создании сжатого DivX 5 видео были использованы B-frames, то верно показываются только ключевые кадры (key frames). Во всех остальных кадрах полно квадратов с мусором, точнее с фрагментами соседних кадров. В любом случае, смотреть такое невозможно.

Если при создании сжатого DivX 5 видео использовалась компенсация движения (global motion compensation, GMC), то попытка воспроизвести такой файл при помощи декодера DivX 4 приводит к краху программы проигрывателя. А если использовался режим Quarter pixel, то в кадре будут появляться маленькие квадратики с мусором на границах движущихся объектов (такое тоже смотреть невозможно).

Обобщая: проблема совместимости имеется, и о ней следует помнить тем, для кого она важна. Предположим, вы делаете рекламный ролик для размещения в сети. Одно дело скачать ролик и посмотреть его, совсем другое — скачать, убедиться в том, что он не воспроизводится и начать разбираться (если на это хватит терпения и любопытства). Даже подсказка типа «необходим DivX 5» сможет отпугнуть часть потенциальных зрителей.

Параметры сжатия DivX в двухпроходном режиме

Итак, мы добрались до самого интересного раздела: какие параметры использовать для двухпроходного сжатия при помощи DivX 3 и 5? Возможно, в ходе этого исследования мы сможем выявить явного лидера среди этих двух кодеров. Правда, до окончания исследования я обещать этого наверняка не могу. ;)

DivX 3

Мы будем использовать программу NanDub для того, чтобы заставить работать кодер DivX 3.11 в двухпроходном режиме — технология Smart Bitrate Control (SBC).

Как уже говорилось выше, автор этой программы избрал далеко не самый простой для использования вариант настройки режимов работы кодера: программа предоставляет массу настроек без каких-либо рекомендаций по их использованию. Изучение назначения всех настроек — задача нетривиальная, но вполне выполнимая. Начать имеет смысл с руководства Алексея Шашкова иди руководства, подписанного Koepi. Изучить же влияние наиболее важных настроек на качество результата — задача требующая огромного количества времени — как машинного для выполнения собственно сжатия, так и моего для изучения результатов.

Посему, подробное описание настроек NanDub'а я приведу позже. Часть материала уже накоплена — в частности о таких часто встречающихся особенностях сжатия DivX 3, как выпадение одного-двух блоков на крупных надписях в кадре, так называемые «плывуны» (переход текстуры статичного объекта на движущийся объект, в результате чего текстура фона уплывает в сторону) и так далее. Я не хочу излагать этот материал сейчас, до тех пор, пока я не соберу и не систематизирую всю возможную информацию о поведении кодера DivX 3 в двухпроходном режиме.

DivX 5

DivX Networks проделали отличную работу, в частности по конструированию интерфейса кодера. Так, в пятую версию было включено множество сервисных возможностей, которые традиционно являются привилегией редакторов видео, а не кодеров. Можно спорить об уместности этого шага, использовать эти возможности или нет — тем не менее это еще один плюс программистам DivX Networks. Они сделали свой кодер еще более функциональным, они еще раз опередили конкурентов.

Разница по сравнению с NanDub'ом огромна — в настройках кодера вы найдете только самые важные параметры, грамотное использование которых позволит вам выдавить максимум возможностей из кодера. Ничего лишнего, ничего дублирующего или исключающего друг друга. Ниже я рассмотрю назначение каждого из параметров, его влияние на результат, и дам некоторые рекомендации по использованию на практике.

Основные параметры

Bitrate

Variable bitrate mode — режим сжатия. Как уже обсуждалось выше, в разделе Выбор режима сжатия, мы будем использовать двухпроходный режим. Соответственно, выбираем 2-pass, first pass для первого и 2-pass, second pass второго проходов.

Encoding bitrare — собственно желаемый средний битрейт результата. Совсем не обязательно, чтобы эта цифра была одинакова для двух проходов. Однако, как предостерегает документация, слишком большая разница между значениями битрейта при первом и втором проходе приводит к ухудшению соответствия размера результата заданному размеру. Таким образом, вполне допустимо в случае, когда вас не устраивает размер результата, немного увеличить или уменьшить значение битрейта и повторить второй проход сжатия. Обратите внимание — первый проход повторять не нужно (если, конечно, вы не стерли файлы со статистикой, созданные DivX 5 на первом проходе).

Two pass encoding files

В этом разделе указывается расположение файлов со статистикой, в которые кодер DivX 5 записывает информацию о сжимаемости видеоряда во время первого прохода сжатия.

Если вы кодируете файлы строго по очереди (file1-pass1, file1-pass2, file2-pass1, file 2-pass2, file3-pass1, …) и уверенны в том, что вам не придется переделывать второй проход (например для получения результата с чуть большим или чуть меньшим размером) — то вы вполне можете использовать имена файлов по умолчанию. В противном случае задайте для каждого видео свои имена файлов со статистикой. Естественно, что для выполнения первого и второго проходов одного видеоряда должны использоваться одни и те же файлы.

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

Log file — имя файла со статистикой сжимаемости. Размер этого файла равен примерно 250 кБ на минуту сжимаемого видео, то есть примерно 15 МБ на час видеоряда.

Use MV file — включает создание/использование файла с записями о векторах движения. Этот параметр включает режим, в котором на первом проходе информация о векторах движения в кадре записывается в файл. На втором проходе эти вектора не рассчитываются заново, а читаются из файла, что сокращает время выполнения второго прохода примерно на треть. Учтите, что для того, чтобы иметь возможность пользоваться этой возможностью, настройки кодера для первого и второго прохода должны быть абсолютно одинаковыми (кроме среднего битрейта и уровня пре-процессинга, подробнее см. документацию). Использование этого режима настоятельно рекомендуется.

MV file — имя файла с рассчитанными векторами движения. Размер этого файла больше раз в 6-8 размера файла статистики, то есть примерно 50-70 МБ на час видеоряда.

Protect log/MV file — включает защиту файлов статистики. Защита заключается в том, что если файл с указанным именем уже существует, то кодер выдаст запрос вида «перезаписать файл, да/нет?». Очевидно, что если вы используете имена файлов статистики по умолчанию, то кодер будет только надоедать вам. Использование этого параметра — по вкусу. Помните только, что в случае запуска кодирования в пакетном режиме включение этого параметра вполне может привести к тому, что компьютер будет всю ночь ждать ответа на вопрос, вместо обработки видео материала.

Psychovisual Enhancements

Психовизуальная модель — это передний край технологии сжатия видео. Модель оказывает влияние на параметры сжатия таким образом, чтобы сэкономить на размере как раз в том месте, где человеческий глаз менее чувствителен к ухудшению качества изображения. Так, например, она увеличивает степень игнорирования деталей на темных сценах. Очевидно также, что этот код в силу своей новизны тестировался меньше всего, использование психовизуальной модели потенциально может привести к появлению нежелательных искажений результата сжатия видео. В версии 5.02 были исправлены явные промахи ранних версий кодера DivX 5, которые приводили к получению откровенно провальных результатов. Сегодня большинство специалистов по сжатию видео советуют использовать психовизуальную модель с значением Strong. Учтите, что если в вашем видеоряде нет очень темных или очень светлых мест (где в основном и работает психовизуальная модель) то результат сжатия вполне может совпадать один в один с тем, что вы получите без использования психовизуальной модели.

Keyframe

Примечание: подробное разъяснение того, что такое ключевой и промежуточный кадр приведено ниже, в разделе Двунаправленные кадры (Bidirectional frames).

Max. keyframe interval — максимально возможное количество промежуточных кадров подряд. За добавление в выходной поток ключевых кадров отвечает механизм определения начала новой сцены. В случае длинной статичной сцены кодер вполне может использовать только промежуточные кадры, которые имеют размер меньший, нежели ключевые кадры. Использование одних только промежуточных кадров не совсем удобно именно из-за их природы. В промежуточном кадре содержатся только изменившиеся по сравнению с предыдущем кадром блоки. Потому для отрисовки промежуточного кадра необходимо найти предыдущий ключевой кадр (в котором записан кадр целиком) и проанализировать все промежуточные кадры после него — аж до необходимого нам кадра. Именно этим объясняется задержка при перемотке DivX видео — она тем больше, чем больше расстояние между ключевыми кадрами (говоря совсем строго — математическое ожидание задержки пропорционально среднему расстоянию между ключевыми кадрами).

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

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

Scene change threshold управляет чувствительностью механизма определения смены сцены в видеоряде. Значение по умолчанию — 50% — вполне подходит для использования в большинстве случаев. Изменение этого значения в большую или меньшую сторону может привести к получению лучших результатов, однако оптимальное значение будет различным для разных видеорядов.

Data Rate control (RC)

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

Maximum quantizer — максимальное значение степени игнорирования деталей. В конечном видеоряде не окажется ни одного кадра с качеством хуже, чем указано в этой графе. Таким образом, уменьшая это значение можно получить более качественный результат сжатия видео — вплоть до максимального качества при указании здесь «2» (так мы получим аналог режима 1-pass quality based с качеством в 100%). С другой стороны это заставит кодер использовать больше бит в тех кадрах, где вполне можно было бы обойтись и менее качественным кадром. Это уничтожает смысл двухпроходного режима: кодер сам по себе достаточно умный, чтобы использовать качественные кадры там, где это необходимо — зачем его заставлять использовать качественные кадры там, где это не нужно?

Нельзя не упомянуть о том, что разработчики кодера не рекомендуют менять значение по умолчанию — «12». Они говорят о том, что алгоритм кодера оптимизирован под значения по умолчанию всех параметров из группы Data Rate control (кроме RC averaging period). Нарушение этого правила может, например, привести к некорректной работе психовизуальной модели, которая ориентирована на значения «12» и «2» для maximum и minimum quantizer соответственно.

Обращаю ваше внимание, что это значение означает не более чем ограничение: при достаточно высоком битрейте кодер может ни разу не создать кадра с минимальным качеством — вплоть до использования минимальной степени игнорирования деталей «2» во всех кадрах. Это, кстати, накладывает ограничение сверху на размер результата сжатия видео при помощи DivX — оно соответствует примерно 0,40 бит на пиксел.

Minimum quantizer — соответственно, минимальное значение степени игнорирования деталей. Ума не приложу, в каком случае может появиться необходимость увеличить значение по умолчанию — «2». Пожалуй, только разве что в случае экстремально низкого битрейта. То есть в нашем случае — стремимся к качественному результату — тут должно быть »2» и только «2».

RC averaging period, frames — указывает интервал, в пределах которого в двухпроходном режиме перераспределяются биты между кадрами. Очевидно, что наилучшим вариантом будет использовать перераспределение битов в пределах всего видеоряда. Так, разработчики кодера рекомендуют использовать значение в половину количества кадров сжимаемого видеоряда. Соответственно, имеет смысл установить это значение в «500000» — это больше 4 часов — и забыть про него навсегда. Значение по умолчанию — «2000» — соответствует примерно одной минуте и вряд ли может считаться удовлетворительным. Очевидно, что это значение подразумевает использование однопроходного режима.

RC reaction period, frames — указывает интервал, в пределах которого кодер игнорирует изменение количества движения в кадре. Соответственно, чем это значение меньше, тем лучше будут переданы короткие рывки, с другой стороны это может привести к слишком расходу бит для кодирования, скажем, случайных шумов в пределах нескольких кадров. Слишком высокое значение приведет к слишком медленному реагированию кодера и, как следствие, к нерациональному расходу битов в начале медленной сцены и низкому качеству начала динамичной сцены.

Значение по умолчанию — «10», его и рекомендую оставить, следуя рекомендациям разработчиков кодера.

Rate control down/up reaction — отвечает за скорость увеличения/уменьшения битрейта при изменении количества движения в кадре. Значение по умолчанию — «20», его и рекомендую оставить, следуя рекомендациям разработчиков кодера.

Use data partitioning

Этот параметр имеет смысл использовать только в некоторых случаях при вещании видео. У нас этот параметр должен быть всегда выключен.

Perfomance / quality

Этот параметр регулирует скорость работы кодера, точнее позволяет ускорить работу кодера за счет более низкого качества результата. Этот параметр имеет смысл изменять только в случае сжатия видео в реальном времени. Во всех остальных случаях установите его в Slowest — максимальное качество.

Write conversion log file

Указывает кодеру на необходимость создать файл с описанием полученного результата — сжатого видеоряда. В этом файле раскрывается работа кодера на втором проходе: какова сжимаемость каждого кадра, с каким качеством в итоге каждый кадр был сжат и тому подобное. По умолчанию кодер создает файл с именем analyse.log в текущем каталоге. Вы также можете указать любое другое место расположения и имя этого файла.

Новые возможности кодера DivX 5

Как уже говорилось выше, кодер DivX 5 впервые среди MPEG-4 видео кодеров реализует некоторые новые функции, в частности поддержку B-frames, Global motion compensation и работа с векторами движения с повышенной точностью (до четверти пиксела — quarter pixel). Как, опять же, упоминалось выше, эти возможности доступны лишь в Pro версии кодера DivX 5.

Двунаправленные кадры (Bidirectional frames)

Согласно стандарту MPEG-4, в потоке видео данных могут присутствовать кадры трех типов:

  • полные (intra, I-frame) — их содержимое сохраняется целиком, часто их называют ключевыми кадрами (key frames);
  • предсказуемые (predictable, P-frame) — часть содержимого этих кадров предсказывается на основании содержимого предыдущих кадров, безразлично I или P, часто их называют промежуточными кадрами (delta frames);
  • двунаправленные кадры (bidirectional, B-frames) — часть содержимого этих кадров предсказывается на основании содержимого предыдущих кадров (так же, как и у предсказуемых кадров), а часть — на основании содержимого последующих кадров.

Кодеры DivX версий 3 и 4 умели формировать поток только из I и P кадров. DivX 5 предоставляет возможность использовать и кадры типа B. На практике использование такого режима сжатия означает небольшое увеличение ресурсоемкости кодирования и декодирования потока (порядка 10%) и существенное — от 10 до 20% -- уменьшение размера сжатого видео при том же уровне качества. Это каждый может элементарно проверить, закодировав дважды какой-нибудь видео фрагмент в режиме 1-pass quality based: с использованием B-frames и без них.

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

Компенсация движения (Global motion compensation)

Этот режим позволяет использовать еще одну не задействованную ранее возможность стандарта MPEG-4. Компенсация движения создана для описания сцен с плавным панорамированием в стороны, вверх/вниз (например, титры) или в глубину (наезд/отъезд камеры). Промежуточные кадры формируются специальным образом, чтобы максимально использовать уже имеющуюся в предыдущих кадрах информацию о сцене — это дает существенный выигрыш в объеме результата. Конечно, этот режим применяется кодером только в сценах определенного типа — потому вполне возможно, что на видео материале, в котором подобных сцен мало, выигрыш в размере окажется мизерным. Тем не менее, эта возможность позволяет вам экономить на размере результата (или повышать качество других кадров, если размер результата фиксирован) с минимальными дополнительными затратами: увеличение ресурсоемкости кодирования и декодирования всего лишь около 10% Использование этого режима скорее желательно, чем нет.

Четверть пиксельная точность

Кодер DivX 5 позволяет работать с векторами движения с повышенной точностью: до четверти пиксела — quarter pixel. Старые версии DivX позволяли проводить расчеты с точностью лишь до половины пиксела. Теоретически такая технология позволит более точно описывать движение блоков в кадре, соответственно, повысить качество отображения границ движущихся объектов. На практике использование этого режима увеличивает размер результата на пару процентов, а вот ресурсоемкость как кодирования, так и декодирования подскакивает больше чем на четверть. Не могу сказать, что качество полученного результата настолько лучше, насколько больше ресурсов оно потребляет. А при таком среднем количестве бит на пиксел, которое я обычно использую, визуально разницу видно лишь при сравнении кадров один к одному — на скорости в 24 кадра в секунду все выглядит совершенно одинаковым. Таким образом этот режим себе же дешевле не использовать — ну разве что вы во что бы то ни стало хотите достичь максимального качества и у вас компьютер существенно быстрее 1 GHz (на Intel Pentium III 833 MHz видео размером 800х340, сжатое DivX 5 с включенными Qpel, B-frames и GMC, декодируется с полной загрузкой процессора на нулевом уровне постпроцессинга).

Прочие параметры

Опция Write DivX MP4 file позволяет создавать файлы не в формате avi, а в формате DivX MP4. В частности это позволяет обойти ограничение системы Video for Windows, которая требует одинаковой частоты кадров у видео на входе и на выходе кодера — то есть это реально необходимо в случае осуществления IVTC силами DivX 5 кодера. На практике файлы в формате avi куда как более распространены — так что эту опцию вам вряд ли придется когда-то включать.

В строке Quick config CLI (command line interface) вы можете видеть командную строку, которая будет использоваться для передачи выбранных вами параметров кодеру. Вы также можете вручную редактировать эту строку, в частности для указания таких параметров, которые невозможно выбрать при помощи оконного интерфейса — подробнее см. документацию кодера DivX 5.

Crop позволяет обрезать кадр перед кодированием — однако мне кажется намного удобнее и нагляднее делать это в какой-то программе, которая поддерживает режим предварительного просмотра: например VirtualDub или GordianKnot.

Resize позволяет изменить размер кадра видео перед кодированием. Опять же — мне намного удобнее сделать это при помощи фильтра в VirtualDub, тем более что фильтр Smart Resize содержит много полезных и удобных дополнений, облегчающих расчет размера результата.

Pre Processing Source позволяет провести обработку входного видеоряда, в частности провести сглаживание изображения и усреднение значений пикселов по времени. По сути это эквивалентно обработке фильтрами типа Smooth и Temporal Clean. Лично я считаю намного более удобным и гибким в настройке использование фильтров для VirtualDub — тут вы можете подобрать значения параметров для каждого из фильтров индивидуально, вместо абстрактных «Light», «Normal», «Strong» и «Extreme». Не забывайте также про возможность предварительного просмотра результата работы фильтра в VirtualDub'е.

Source Interlace позволяет провести обработку исходного видео перед сжатием: deinterlace и inverse telecine (IVTC). И снова — для этих более чем нетривиальных процедур существует несколько разнообразных фильтров для VirtualDub с огромным количеством настроек — зачем использовать простенький вариант от DivX кодера?

DivX MP4 Creator позволяет преобразовать готовые avi файлы, в которых записано видео с DivX 5 сжатием, в файлы формата MP4. Опять же — в силу повсеместной распространенности именно файлов в формате avi — вряд ли вам эта возможность понадобится.

Закладка Manage settings позволяет создавать и использовать пресеты кодера DivX 5. Это достаточно удобно для использования — однако вы вполне можете и игнорировать эту функциональность. На качество получаемого результата это не повлияет ;)

Заметки о настройке DivX 5

Обобщая приведенные выше сведения о настройках кодера DivX 5 мы еще раз убеждаемся в том, что интерфейс кодера доведен практически до совершенства. Я не советую использоавть возможности кодера, описанные в разделе Прочие настройки — куда как лучше и удобнее использовать для этих целей видео редактор. Это также позволит вам раз и навсегда отключить эти настройки и никогда не возвращаться к их конфигурированию. Подавляющее большинство других настроек устанавливается раз и навсегда в оптимальное значение, которое оптимально для любого видео материала. Из настроек, которые зависят от видео материала, остаются Max keyframe interval и Scene change threshold — но и их вполне можно один раз установить в универсальные значения и забыть об их существовании.

Таким образом конфигурирование кодера DivX 5 в двухпроходном режиме сводится к выбору среднего битрейта, первого или второго прохода и имен файлов со статистикой (кстати, если вы не кодируете несколько файлов сразу, то вполне можете использовать имена файлов со статистикой по умолчанию). Для расчета среднего битрейта исходя из желаемого размера результата можно использовать программу Advanced Bitrate Calculator — хотя он, в отличие от встроенного калькулятора NanDub'а, не понимает VBR mp3.

Как преобразовать MPEG-2 в DivX?

Этот вопрос задают мне, пожалуй, слишком часто — хочу ответить на него раз и навсегда. ;-)

Вы, вероятно, слышали, что видеоряд на DVD диске записан в формате MPEG-2. Именно потому процесс преобразования видео из MPEG-2 в DivX подробно описан в каждом руководстве по преобразованию видео с DVD в DivX. В последнее время все чаще видео в формате MPEG-2 появляется вне контекста DVD: это и файлы, полученные при захвате видео с некоторых карт видеозахвата, и файлы, переписанные с SVCD дисков, и файлы скачанные с интернета.

Я не хочу вдаваться в длинную дискусию «стоит ли преобразовывать видео из хорошего формата MPEG-2 — который включает поддержку черезстрочного видео (interlaced video) — в плохой формат MPEG-4 — который черестрочное видео не умеет, что влечет за собой необходимость применять deinterlace, который ухудшает качество видеоряда….» Ниже я просто отвечаю на вопрос, который мне часто задают. Если человек хочет преобразовать MPEG-2 в DivX — пускай. Его мотивы меня мало интересуют, он имеет право хотеть такого.

Для реализации задуманного вам понадобится пакет GordianKnot. Запустите программу DVD2AVI, которая входит в этот пакет. Откройте файлы в формате MPEG-2: программа позволяет открыть несколько файлов, при этом видеоряд будет склеен встык. Таким образом вам не нужно беспокоится о том, что видеоряд разрезан на несколько vob файлов на DVD диске или состоит из нескольких SVCD дисков. Про настройку преобразования видео (deinterlace, inverse telecine) сказано более чем достаточно в руководствах по копированию DVD и в руководстве самого GordianKnot'а — не буду повторяться. Выберите Demux all tracks — для того чтобы выделить все аудио потоки; они будут записаны каждый в свой файл вне зависимости от формата аудио: mp2, ac3 2.0 или 5.1, dts, … Выберите пункт Save project и сохраните файл d2v — при этом DVD2AVI просканирует весь видеоряд и запишет в d2v файл информацию о его структуре: в каком порядке идут промежуточные и ключевые кадры и по какому адресу их искать.

Что делать с полученными звуковыми файлами зависит в первую очечредь от их формата. Как правило они преобразуются в набор несжатых wav файлов, а потом сжимаются в желаемый формат — обычно это mp3 или ac3. Подробно этот процесс описан в руководствах по копированию DVD.

Следующим шагом будет открытие d2v файла в GordianKnot'е, при этом откроется окно с возможностью предварительного просмотра видеоряда. Вам нужно переключится в основное окно GordianKnot'а и выставить параметры видеоряда: пропорции видео, обрезку кадра и желаемый размер кадра (все параметры находятся на вкладке Resolution). Пропорции видео вы можете выставить исходя из информации о формате исходного видео или же на глаз, включив опцию показа размера видео после преобразований в окне предварительного просмотра видеоряда. Очень удобна возможность автоматической установки образки кадра, даже не смотря на то, что как правило после ее использования размер срезаемой области нужно увеличить на пиксел-другой. Изменять размер я лично предпочитаю в VirtualDub'е, потому на этом шаге слежу, чтобы коэффициент увеличения был ровно 100% — правда, это вопрос скорее личных пристрастий.

Дальше у вас есть возможность провести весь последующий процесс пережатия видео при помощи GordianKnot'а — как это сделать подробно описано в многочисленных руководствах. Я же предпочитаю сохранить так называемый avi script в файл и дальнейшую обработку проводить при помощи Dub'а. Для этого в окне с предварительным просмотром видеоряда нажмите Save и сохраните файл avs. Этот файл содержит в понятном для Dub'а формате информацию о местонахождении исходного видео (в формате MPEG-2), местонахождении d2v файла с информацией о структуре видеоряда, ссылку на библиотеку для декодирования MPEG-2 (часть комплекта GordianKnot — вы наверняка знаете, что Dub не умеет читать видео в формате MPEG-2 напрямую). За описанием параметров в окне сохранения avs опять же отправляю вас к руководствам по GordianKnot'у, я предпочитаю не использовать никаких фильтров кроме deinterlace при необходимости.

Полученный avs файл откройте в Dub'е как обычный avi — теперь вы имеете возможность обрабатывать видео как обычно при работе с Dub'ом, в том числе и сохранить в DivX используя ваши любимые фильтры.

Ссылки

Что почитать по теме

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

Сравнение качества кодирования видеокодеров на сайте Doom9.

Nicky Pages — сборник статей о видеомонтаже и цифровом редактировании видео.

Документация по использованию кодера DivX 5.

На русском языке информация наиболее полно представлена в руководстве от Алексея Шашкова.

Среди руководств по NanDub хочу выделить руководство, подписанное Koepi.

Моя статья об использовании пресетов mp3 кодера LAME.

Последняя версия этой статьи.

Программы

VirtualDub — без сомнения самый популярная и одна из самых мощных программ для нелинейного видео монтажа.

NanDub — вариация программы VirtualDub, созданная для сжатия в два прохода при помощи кодера DivX 3.11. Содержит также ряд полезных функций, недоступных для VirtualDub'а.

Сайт Дональда Графта — тут находится коллекция плагинов для VirtualDub'а.

Сайт Джима Касабури также содержит несколько полезных плагинов для VirtualDub'а.

DivX Networks — сайт производителя наилучшего на сегодня MPEG-4 видео кодера — DivX 5.

XviD — сайт проекта по созданию MPEG-4 видео кодера с открытыми исходными кодами, бесплатная альтернатива DivX.

HuffYUV — один из наиболее эффективных кодеков для сжатия видео без потерь качества.

GordianKnot — интегрированный пакет для создания копий DVD-дисков при помощи формата сжатия DivX.

RAD Video Tools — программа для преобразования видео с поддержкой форматов BIN, Smacker, QuickTime и других.

ffdShow — лучший из виденных мною на сегодня декодер видео в формате MPEG-4.

DivX G400 — программа для принудительного включения оверлея при воспроизведении видео, также содержит множество полезных функцию, как-то: отображение субтитров, изменение соотношения сторон и частоты кадров видеоряда.

Advanced Bitrate Calculator — программы для расчета среднего битрейта исходя из заданного размера результата. Пожалуй, более убогая, чем встроенный калькулятор NanDub'а, но многим нравится: если вы используете DivX 5, то NanDub'а у вас может вообще не быть.

Total Recorder — программа для захвата звука, который издает какая-нибудь программа, и записи его в файл.

LAME — наилучший на сегодня кодер звука в формат mp3.

Заключение

Как вы могли видеть, этот материал далек от совершенства. Совершенно не раскрыты возможности кодера DivX 3.11. Честно говоря, совсем недавно заинтересовался технологиями сжатия видео — примерно около года назад. И хоть за это время было изучено множество информации и проведена масса экспериментов, безусловно я еще не досконально владею материалом. Часть материала уже собрана и подготовлена, часть экспериментов только лишь задумана. Плюс я планирую еще организовать перевод домашнего видео архива с VHS видеокассет в файлы с DivX сжатием: бытовой видеомагнитофон и плата ТВ-тюнера с возможностью захвата видео — достаточно распространенная аппаратура. В ходе освоения технологии этого процесса будет появляться масса наработок, которые я также планирую оформить в виде статьи.

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

В случае же если вы считаете, что знаете меньше меня и хотите обратиться ко мне за советом — прошу вас, прежде чем написать мне, просмотрите эту статью еще раз. Как я уже говорил во введении, этому материалу не хватает четкой структуры. Поэтому вполне может оказаться, что ответ на ваш вопрос уже содержится в статье, просто при первом чтении вы его не заметили или не поняли. Также заранее предупреждаю, что я не намерен учить всех и каждого пользоваться VirtualDub'ом или разжевывать какой-либо еще тривиальный вопрос. В качестве ответа в таком случае вы получите ссылку на материал, изучения которого по моему мнению достаточно, чтобы вы получили ответ на свой вопрос.



Андрей Гуле(krolyk@hotmail.com)
Опубликовано — 14 ноября 2002 года
 
Комментарии?  Поправки?  Дополнения? mercoff@ixbt.com

[ Все статьи в разделе «Цифровое Видео» ]

на главную страницуна главную страницуна главную страницу

Новости | 3D-Видео, тюнеры и LCD | iT-Среда | MacLife | Мобильные устройства | Ноутбуки | Носители информации | Платформа ПК | Приложения и утилиты | Принтеры и периферия | ProAudio | Проекторы и ТВ | Сети и серверы | Цифровой звук | Цифровое видео | Цифровое фото | Карта сайта | Поиск

Copyright © by iXBT.com, 1997—2012. Produced by iXBT.com