Компьютерра - Журнал «Компьютерра» № 38 от 17 октября 2006 года

Более практичен другой вариант: добиться «квадратности» пикселов, уменьшив разрешение по одной из координат. В этом случае разрешение картинки уменьшается, за счет чего увеличивается плотность информации на каждый кодируемый пиксел, а всеобщая квадратность улучшает совместимость выходного потока с разными декодерами h264.

• Crop: обрезка краев кадра. Нужна только в том случае, если в исходном видео присутствуют черные полосы или некачественные области у краев экрана (которые возникают при оцифровке VHS, например).

• Resize: изменение разрешения картинки. Этот неприметный пункт требует огромного числа мышедвижений. Сразу поставьте галочку suggest resolution (она обеспечит правильное соотношение сторон и кратность вертикального и горизонтального разрешений шестнадцати) и установите максимально возможное разрешение. Хотя очевидно, что выходное разрешение должно быть не больше входного, распространено заблуждение, что оно должно быть максимально возможным. Это не совсем так — ведь чем больше разрешение, тем больше пикселов требуется закодировать компрессору, тем меньше информации приходится на каждый из них и тем больше артефактов возникает при их сжатии. Но и слишком маленькое разрешение тоже не сахар — низкая степень квантования, или, проще говоря, здоровые квадраты на экране, не особенно радует глаз. Истина лежит где-то посередине, а чтобы ее отыскать, воспользуемся старым знакомым Wabc bitrate calculator’ом (в MeGUI есть встроенный bitrate calculator, но на момент написания статьи самой нужной возможности в нем не было). Принцип его работы я уже описывал в давнишней статье о захвате, так что для экономии места позволю себе ограничиться общими словами. Задача — выбрать минимально допустимый для качественного сжатия Quality Index (QI, то есть индекс количества информации, приходящейся на каждый пиксел картинки) вашего будущего ролика так, чтобы сохранить максимальное разрешение. Чтобы определить этот самый индекс, нужно заполнить все остальные пустующие информационные поля калькулятора.

Сразу вы можете указать Disk Space — желаемый объем ролика в килобайтах, его длительность и частоту кадров (она равна частоте кадров входного материала), а также разрешение, значение которого вы только что выставили в MeGUI. Битрейт, то есть количество информации, которое придется на секунду закодированного видео, считается как частное от деления желаемого объема ролика в килобитах на его длительность в секундах. Все бы хорошо, но вы наверняка обратили внимание, что битрейтов в калькуляторе не один, а два (рис. 2). И правда — звук кодируется независимо от видео, но в финальном-то файле он свое место займет! Выходит, чтобы определиться с битрейтом видео, нужно сначала определиться с аудио. Смело ставьте значение в пределах 64—192 кбит/с для каждой дорожки на свое усмотрение. Мое усмотрение по данному вопросу зависит от целей сжатия: если ролик планируется размещать в Сети, где важен каждый мегабайт, — обойдутся юзеры и 64 кбит/с. Если же пережимается какой-нибудь DVD для себя любимого — тогда, конечно, не стоит экономить. Nero AAC по сравнению с mp3 сделал огромный шаг вперед, и таких скромных битрейтов оказывается достаточно для вполне приличного кодирования даже шестиканального звука.

Ура! Теперь вы можете посчитать битрейт видео (запомните его и выбранный аудиобитрейт!), а стало быть, и первое приближение Quality Index’a с максимально возможным разрешением картинки. x264 обеспечивает практически неотличимое от оригинала качество при QI в пределах от 1200 до 2000 в зависимости от исходного фильма. Если получившееся у вас значение QI меньше 1200, чуть уменьшите разрешение в MeGUI и пересчитайте QI заново.

• Deinterlacing: перевод чересстрочной картинки в прогрессивную, или, по-простому, ликвидация эффекта «расчески».

После нажатия магической кнопки Analyse MeGUI возьмется определить тип вашего видео. В большинстве случаев, когда источник чисто прогрессивный или чересстрочный, MeGUI не ошибается. А вот когда я сжимал документальный фильм с вкраплениями кадров старой кинохроники (естественно, прогрессивных) на фоне общей чересстрочности материала MeGUI схалтурила и предложила страшный алгоритм деинтерлейсинга, который путал полукадры на границе смены планов. Мало того что алгоритм работал крайне медленно, так в итоге все пришлось пережимать заново. Поэтому обязательно проверьте, правильно ли MeGUI выбрала метод deinterlace (это можно сделать перед началом непосредственно кодирования), и в случае чего исправьте скрипт вручную, установив стандартный деинтерлейс командой Field Deinterlace(blend=false).