Изготовление высококачественных
DVD-рипов вездеходов

Концепт руководство


Конечно же, в Интернете имеется огромное количество статей о том, как самому сделать DVD-рип, встречаются среди них и довольно толковые.

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

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

Поскольку термин “качество”, вынесенный в заголовок, довольно субъективен, будем понимать под ним максимальное приближение к оригиналу. В общем-то эта декларация достаточно очевидна, однако далеко не всегда ей следуют в реальной жизни, мы к этому еще вернемся.

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

Мое кредо - рип должен воспроизводиться на любом компьютере и на любом бытовом плеере с поддержкой MPEG-4. И воспроизводиться он должен без глюков. И с высоким качеством, разумеется.

Под любым компьютером я понимаю не только тип процессора и тактовую частоту, но и имеющийся на борту набор программного обеспечения. Мне могут возразить - мол, поставьте такие-то восхитительные кодеки, такой-то замечательный медиаплеер, потом настройте этот плеер на эти самые кодеки, и все будет в шоколаде. Более агрессивные предпочитают унижать неопытных пользователей, жалующихся на проблемы, сентенциями вроде: “сам дурак, руки у тебя растут не из того места”.

На мой взгляд, это совершенно неправильно. Большинство пользователей персональных компьютеров вообще не представляет, с помощью каких кодеков воспроизводится тот или иной контент, и понятия не имеет ни о каких FOURCC. И не нужно заставлять их вникать в эти дебри, пусть как можно дольше пребывают в счастливом неведении. Они хотят всего лишь посмотреть фильм. И с этим уважающим себя риперам необходимо считаться.

Последнее предварительное замечание - по поводу используемого инструментария. Существуют многочисленные программы конвертации DVD-AVI в стиле “один клик”. Мне лично такой подход не нравится тем, что закрывает от нас GUI-интерфейсом суть происходящих процессов. И, стало быть, дает на выходе непредсказуемые результаты.

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

Такие топики забиты отзывами вроде: “Клевая прога, и так шустро работает! Пасибки аффтору за то, шо научил ей пользовацца. Седня я сделал свой первый рип. Ладно, покеда, некогда мне тут с вами, побежал выкладывать его на торренты”.

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

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

Поэтому я буду использовать на каждом этапе наиболее приспособленные для него специализированные программы. Автоматизация необходима, если вы делаете много рипов, впрочем, в этом случае используются совершенно другие инструменты. А уж в них-то как раз все обсуждаемые здесь вопросы неизбежно так или иначе “вылезут”.

Теперь что касается платформы. Обычно компьютер среднестатистического пользователя представляет из себя невообразимую помойку из кодеков, установленных специально либо втихую многочисленными приложениями. И очень часто проблемы с качеством происходят из-за того, что при кодировании были использованы (без вашего ведома) какие-то левые компоненты. Ситуация усугубляется тем, что некоторые приложения используют инфраструктуру Video for Windows, а другие - DirectShow. Хотя имеется довольно много программ для исследования и тонкой настройки этого хозяйства, разобраться в нем довольно непросто.

Не исключая полезности высокоинтеллектуального подхода, сам я обычно действую по-другому - методом грубой силы (т.е. виртуальных машин). Для выполнения каждого вида работ я завожу отдельную виртуальную машину, и устанавливаю на гостевой операционке только  необходимые компоненты. То есть - никаких проигрывателей, никаких кодек-паков, исключительно то, без чего нельзя обойтись. Да, работает кодировка на виртуальной машине примерно в полтора раза дольше, зато не нужно заморачиваться и имеется абсолютная уверенность в чистоте экспериментов. Замечу еще, что у меня довольно старый процессор, не поддерживающий виртуализацию на аппаратном уровне. Полагаю, что на современных моделях замедление будет существенно меньшим. Если вы собираетесь апгрейдить компьютер, обратите внимание на поддержку технологий Intel VT или AMD-V.

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

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

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

www.kinozal.ws/forums/index.php?showtopic=4751
rutracker.org/forum/viewtopic.php?t=2660571
dvd2avi.narod.ru
www.nwml.nm.ru/dvd/dvd2mp4.htm
www.kinozal.ws/forums/index.php?showtopic=1807

Только обязательно возвращайтесь!

1. Запись DVD на жесткий диск

Этот этап необходим, только если DVD закодирован. Используются программы DVD Decrypter (www.doom9.org/software.htm) или SmartRipper (smartripper.en.softonic.com).

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

2. Разборка DVD-диска

Разборку DVD-диска на составляющие я произвожу программой PgcDemux (www.doom9.org/software.htm).

Интерфейс очевиден - нужно войти в каталог VIDEO_TS DVD-диска, выбрать файл .IFO, соответствующий основному фильму (его номер совпадает с номером большинства файлов .VOB; проверьте также поле “Cells” - для фильма это значение обычно намного больше единицы), задать режим “by PGC”, пометить галочкой все потоки, задать выходной каталог и нажать кнопку “Process!”. В результате в указанном вами месте образуются файлы видео (.M2V), аудио (.AC3), субтитров (.SUP) и глав (celltimes.txt).

Если для вас привычнее программа VobEdit - результат абсолютно идентичен за исключением именования файлов и отсутствия файла разбиения на главы.

3. Кодирование видео

Кодирование видео целесообразно производить старой доброй программой VirtualDub (sourceforge.net/projects/virtualdub) - она удобна, надежна, интуитивно понятна и, к тому же, совершенно бесплатна. Чудеса, да и только. В качестве монтажной системы она, конечно, слабовата, а вот для изготовления рипов подходит как нельзя лучше.

По программе есть масса руководств, навскидку - forum.megashara.com/showthread.php?t=8706.

Одна беда - VirtualDub не читает файлы MPEG-2, но эту проблему легко уладить установкой соответствующего плагина - fcchandler.home.comcast.net/~fcchandler/. Заодно прихватите оттуда же плагин AC3, ну, и что еще вам приглянется - бесплатно ведь. Скопируйте модули для вашей платформы (32 или 64 разряда) в каталог plugins VirtualDub.

Сразу же предостерегаю вас от использования для кодирования видео программы VirtualDubMod, в которую модуль чтения файлов MPEG-2 уже встроен - он подмыливает картинку и искажает цвета. Плагин от fccHandler, на мой взгляд, намного лучше. Кому-то, возможно, цветовая гамма, которую выдает VirtualDubMod, понравится больше, но не забываем о нашем определении качества! Цвета, яркость и контраст можно легко отрегулировать в плеере, не нужно делать всех зрителей заложниками вкусов конкретного рипера.

Впрочем, программа VirtualDubMod тоже может нам пригодиться, поэтому заодно забираем и ее в свою коллекцию (sourceforge.net/projects/virtualdubmod).

Наверное, совет использовать для кодирования самый лучший доступный исходник выглядит достаточно банально. Тем не менее сплошь и рядом приходится сталкиваться с рипами, сделанными из DVD5 (пережатыми из DVD9) или рипами для PSP, использующими в качестве источника рип DivX. Двойное пережатие еще никому не шло на пользу. 

Запускаем VirtualDub и загружаем файл с видео. Здесь нас ожидает первый перекур.

Для начала идем в меню Video\Frame Rate… и проверяем частоту кадров. К сожалению, на торрентах довольно часто встречаются фильмы с неправильной длительностью. Это обычно не заметно на глаз при просмотре, но зачем же делать некорректно? К тому же в этом случае возникают лишние проблемы с подгрузкой внешних аудиодорожек и субтитров. Длительности рипа и DVD должны в точности совпадать.

Советую также на всякий случай проверить совпадение количества кадров видео. Не поленитесь дважды (при кодировании и сборке) переместить свой драгоценный взор на самый конец ползунка в VirtualDub и сравнить числа.

3.1. Фильтры VirtualDub

Без фильтров нам никак не обойтись, поэтому сразу идем в меню Video\Filters… и без разговоров нажимаем кнопку Add.

Если источник имеет чересстрочную развертку, должен быть установлен фильтр, выполняющий деинтерлейс (deinterlace). Определить это очень просто: пощелкайте по кадрам с интенсивным движением, если увидите характерную “гребенку” - изображение чересстрочное, если картинка просто смазана - прогрессивное. По моим наблюдениям, чаще всего деинтерлейс не нужен.

Потом необходимо поставить фильтр null transform, он загружается ради опции Cropping… - как правило, фильм приходится подрезать, чтобы устранить некрасивые разноцветные полоски по краям изображения.

Отдельным вопросом стоят широкие черные вертикальные боковые полосы (так называемые “шторки”). Образуются они потому, что из стандартных 720 точек по горизонтали активными являются только 702. В аналоговом сигнале оставшийся участок занят служебной информацией, а в цифровом формате он остается черным.

Обрезать ли эти полосы? Палка, как часто бывает, о двух концах. С одной стороны, выглядят эти полосы на компьютере некрасиво, особенно с учетом того, что прилегающие к изображению стороны обычно бывают неровными. С другой - если эти полосы обрезать, то на телевизоре изображение будет немного выходить за пределы экрана.

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

Встречаются и горизонтальные “шторки”, они добавляются создателями DVD для приведения нестандартных пропорций (1.85:1 или 2.35:1) к стандартной (16:9). Их оставлять я не вижу никакого смысла.

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

Далее должен стоять фильтр изменения размера (resize). Это достаточно сложный фильтр, поскольку зачастую выбор правильного размера кадра - скорее искусство, чем наука. Или даже элементарное везение.

Сразу не соглашусь с многочисленными таблицами “правильных” значений размеров кадров, которые часто приводятся в руководствах по рипованию. По моему мнению, во главу угла должны ставиться правильные пропорции реального изображения, а не формальные соотношения стандартов - 4:3, 16:9 или 1.85:1. Что толку в абсолютно правильном Aspect Ratio картинки, если в результате вы будете любоваться сплюснутыми физиономиями?

Жизнь полностью совпадала бы с теорией, если бы не было обрезания изображения. Поэтому при ресайзе это обрезание необходимо учитывать.

Но на самом деле действительность еще причудливее, поскольку ряд фильмов снят в нестандартных форматах, коих за длинную и тернистую жизнь синематографа скопилось более чем достаточно (Вики). При переводе на цифровые носители они по мере сил приводились к стандартным. Уточнить исходное соотношение сторон фильма можно в разделе технических спецификаций на сайте www.imdb.com.

При выборе соотношения сторон необходимо понимать, что мы не можем задавать  размер кадра произвольно. Самое жесткое ограничение - горизонтальная сторона (W-Mod) должна нацело делиться на 32, а вертикальная (H-Mod) - на 16 (это ограничение оверлея некоторых видеокарт). Более мягкое - W-Mod=16 и H-Mod=16 (размер макроблока DCT). Ниже W-Mod=8 и H-Mod=8 (размер блока DCT) нельзя опускаться ни в коем случае. Лично я W-Mod=16/H-Mod=16 считаю вполне разумным компромиссом.

Для анаморфных изображений ресайз необходимо делать в любом случае. DVD-проигрыватели умеют приводить кадр телевизионного формата к широкоэкранному виду 16:9, а вот многие медиаплееры - нет, они просто показывают пиксели. Поэтому перестраивать изображение в этом случае придется нам самим (точнее, конечно же, фильтру resize).

Да, чуть не забыл, еще одно ограничение - горизонтальный размер не должен превышать 720 пикселей (для SD-изображений, само собой, HD - это тема отдельного разговора).

Ладно, так и быть, сжалюсь над вами и приведу эти магические числа, чтобы вам не обшаривать весь Инет. Помните только, что если обрезание кадра существенное, они уже не подойдут.

4:3 (1.33:1) - 720x544, 704х528, 640х480, 576х432, 512х384, 496x368, 448x336, 384x288, 352x264, 320x240.
16:9 (1.78:1) - 720x400, 704x400, 656х368, 640x360, 576x324, 544х304, 512х288, 496x272, 480х272, 448x252, 384x216.
1.85:1 - 720x384, 640х336, 624х336, 592х320, 576х304, 512х272, 496x272, 480х256, 448х240, 416х224.
2.39:1 (2.35:1) - 720x304, 704x288, 672х288, 640х272, 576x240, 528х224, 512x208, 496x208, 448x192, 384x160.

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

Однако на телевизоре неполный кадр будет масштабирован на весь экран, и пропорции за счет неравномерности растяжения по осям исказятся. Так что я стараюсь всегда делать картинку с 720 пикселями по горизонтали, поскольку на телевизоре она будет воспроизводиться “as is”, с правильными пропорциями.

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

Конечно, такой размер кадра требует соответствующего битрейта. Так дайте ему этот битрейт, не жадничайте - и овцы будут сыты, и волки целы.

Теперь, наконец, мы готовы считать. Для начала необходимо определить, в каком формате выполнен фильм - 4:3 или 16:9. Это сразу видно невооруженным глазом - разница слишком велика.

Если формат был 4:3, то, казалось бы, скорректировать нужно будет только обрезанные края - составить элементарную математическую пропорцию, какую часть изображения вы отрезали по вертикали, а какую - по горизонтали. Однако это не так - на телевизоре, в отличие от компьютера, пиксель не квадратный, а прямоугольный. Чтобы сохранить пропорции, размер кадра должен быть 720*3/4=540 пикселей. Именно поэтому в таблице “правильных размеров” первым стоит значение 720x544 (округлено до кратности 16), а не 720x576.

Для формата 16:9 необходимо будет провести анаморфное преобразование, опять же с учетом обрезанных областей.

Чтобы хоть как-то облегчить вам задачу выбора значений ширины и высоты кадра в общем случае, прилагаю “универсальную” таблицу - список чисел, делящихся нацело на 16. Из него можно подобрать наиболее подходящую для каждого конкретного случая пару, максимально близкую к реальному соотношению сторон.

720, 704, 688, 672, 656, 640, 624, 608, 592, 576, 560, 544, 528, 512, 496, 480, 464, 448, 432, 416, 400, 384, 368, 352, 336, 320, 304, 288, 272, 256, 240, 224, 208, 192, 176, 160.

Приведу небольшой пример - рип фильма “Ромео и Джульетта” Франко Дзеффирелли. Изображение 16:9, черные вертикальные “шторки”. При кропинге было отрезано 20 вертикальных пикселей, 18 за счет формата (720-702), плюс 1 на цветную полоску, ну и еще 1 для ровного счета. По горизонтали все было чисто и резать не пришлось.

Берем мою любимую ширину 720 пикселей и строим пропорцию:  720*9/16=405. Но это было бы без вертикального обрезания. Корректируем с учетом обрезания: 405*720/700=416.571. Мне повезло - 416 делится на 16, и разница получилась всего в полбита, это очень близко.

Обратите внимание, что чисто формально соотношение абсолютно неправильное, 720/416=1.73 вместо 1.78, это уже довольно много. Тем не менее, пропорции соблюдены практически идеально, проверено как на компьютерах, так и на CRT- и LCD-телевизорах. А вот на рипе этого же фильма, скачанного с одного из торрентов, при безукоризненном Aspect Ratio 712x400=1.78 изображение было ощутимо сплюснуто. К тому же легко проверить, что 712 не кратно 16, значит - у кого-то будут проблемы с воспроизведением.

Для контроля правильности пропорций в фильме желательно найти предмет с известным соотношением сторон - круг или квадрат. Если таковые отсутствуют - не беда, вы ведь можете замерить любой подходящий объект (хотя бы сам кадр) сначала в DVD-проигрывателе (который обычно показывает пропорции правильно), а затем - в своем рипе. Ну, или посмотрите, что должно быть на самом деле, на сайте www.imdb.com.

Замерять проще всего компьютерной линейкой, например, этой - pitomec.boom.ru.

Также неплохо проверить пропорции на телевизоре - но тут уж обычной рулеткой, никуда не денешься.

В фильтре resize необходимо выбрать алгоритм масштабирования, лично я предпочитаю Precise bicubic (А= -1.00), кому-то больше нравится Lanczos3 (ясное дело, он же без параметров).

Теперь - что касается других фильтров. Некоторые любят обрабатывать фильмы различными “улучшайзерами” - поднять резкость, подавить шумы, насытить цвета. Настоятельно советую либо не делать этого вообще, либо, в случае крайней необходимости, корректировать изображение в минимальной степени. Обычно источник DVD бывает вполне хорошего качества, а ничего в этой жизни не дается даром - улучшая одно, вы неизбежно ухудшите что-то другое.

Если кому-то нравится смотреть перешарпленное изображение - пожалуйста, только гораздо проще решить этот вопрос раз и навсегда установкой соответствующего фильтра в медиаплеере, а не корежить “под себя” каждый фильм.

3.2. Выбор и настройка кодека

DivX или XviD - вот в чем вопрос.

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

Для себя я выбрал XviD - у него значительно гибче настройки, имеется очень мощный режим зонального кодирования, продукт бесплатен (www.koepi.info/xvid.html).

Итак, заходим в Video\Compression… и выбираем кодек XviD.

Рассмотрим теперь наиболее важные параметры.

Вкладка Profile @ Level: выставляем Profile - Advanced Simple@L5, Quantization type - H.263, Quarter Pixel - off, Global Motion Compensation - off. Эти параметры в первую очередь влияют на совместимость.

К сожалению, очень часто на торрентах встречаются фильмы, закодированные с Quantization type MPEG и MPEG-Custom; многие аппаратные и даже некоторые программные декодеры “идут пятнами” и дают скачки яркости при использовании MPEG-матриц квантизации. И это не удивительно - обратите внимание, что DivX, к примеру, не дает выбрать матрицу квантизации MPEG при задании любого профиля совместимости, за исключением High Definition.

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

В любом случае, мизерное отличие в качестве не стоит проблем совместимости. Если вы уж так озабочены качеством - смотрите DVD, например, DVD5, пережатые из DVD9. Качество при этом остается на высоте, но уходят специфические проблемы “девяток” - дороговизна и капризность двухслойных болванок, неопределенность срока их жизни, отсутствие перезаписываемых блинов.

Ну, или используйте более современный кодек H.264 в контейнере .MKV - и качество получится повыше, и ни у кого не будет иллюзий, где этот файл потом можно будет успешно воспроизвести.

Только не воспринимайте последнее замечание как совет - проведенные сравнения убедили меня, что качество видео H.263 и H.264 при средних битрейтах  отличается не так уж и принципиально, и даже не всегда в пользу H.264. А в совместимости проиграете очень сильно - за бортом сразу же окажется большинство аппаратных MPEG-4 плееров. Декодер H.264 гораздо сильнее нагружает процессор, поэтому на многих слабых или плохо настроенных компьютерах наверняка будет подтормаживание картинки. Поэтому, если вдруг до этого места дошли обычные зрители, советую неопытным пользователям обратное - не скачивать при прочих равных фильмы в формате H.264/MKV. Исключение могут составить низкобитрейтные фильмы, на них преимущество более совершенного кодера будет уже заметным.

Следующая группа параметров связана с так называемыми B-фреймами (bi-directional frames) - при декодировании они восстанавливаются не только из предыдущего (как P-фреймы), но и из следующего кадра и имеют самый большой коэффициент сжатия. При этом может задаваться максимальное число подряд идущих B-фреймов (параметр Max consecutive BVOPs).

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

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

Сам я прироста качества при использовании B-фреймов  (по крайней мере на средних и высоких битрейтах) не заметил и поэтому всегда снимаю флажок с параметра B-VOPs.

Параметр Packed bitstream имеет смысл только при использовании B-фреймов и также отрицательно влияет на совместимость. Однако не стоит отключать его здесь - я заметил, что в этом случае видео на некоторых системах начинает кое-где подергиваться. Поэтому, если вы все же решили использовать B-фреймы (лучше, конечно, не более одного подряд), установите Packed bitstream - on. Потом его можно будет сбросить программой MPEG4 Modifier.

Многие программы испытывают проблемы с позиционированием кадров при снятом флаге Packed bitstream, при этом воспроизведение и потоковая обработка функционируют совершенно нормально. Поэтому имеет смысл убирать его после завершения всех работ, с финального релиза.

Параметр Adaptive Quantization по идее должен влиять только на качество, устанавливать его или нет - зависит от исходного материала, иногда получается лучше, а иногда - хуже. Здесь есть еще один момент - хотя XviD запрещает устанавливать этот параметр только в самом жестком профиле Simple@0, кодер DivX не дает возможности использовать аналогичную опцию Psychovisual Enhancements на довольно распространенном профиле Home Theater. Поэтому сам я всегда ставлю Adaptive Quantization - off.

Кодировать, безусловно, необходимо в два прохода. Если лень дожидаться окончания первого прохода - воспользуйтесь режимом VirtualDub Queue batch operation. Тут будет даже не обеденный перерыв, скорее - полноценный, здоровый сон, сиеста, так сказать.

Теперь необходимо определиться с битрейтом или результирующим размером файла. Обычно рациональнее последнее, поскольку существуют определенные стандарты на размеры фильмов: 700 МБ, 1.37 ГБ, 1.46 ГБ. Это связано с удобством размещения нескольких фильмов на одном диске. Также важным является вариант, примыкающий к 2 ГБ - это максимальный размер, поддерживаемый контейнером .AVI версии 1.0, а также файловой системой ISO DVD-диска. По соображениям совместимости файлы большего объема делать не следует, в крайнем случае, фильм можно порезать на куски во время финальной сборки.

Нередко приходится сталкиваться с такой аргументацией: “В чем проблема-то - сами возьмите  и порежьте фильм на части, если что-то не устраивает”. Я полагаю, что квалификационные требования рипер должен предъявлять только к самому себе, но никак не к зрителям. Да, многие пользователи могут порезать на части, сменить контейнер, модифицировать флаги, переименовать файлы. Но далеко не все. А немало людей может и фильм пережать - только вы-то, уважаемый рипер, тогда зачем?

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

Отмечу в этой связи, что считаю “стандартный” размер 2.05 Гб, принятый на многих трекерах, совершенно неудачным (правильное значение, на мой взгляд - 1.99). Несколько раз я имел беседы с модераторами различных трекеров на эту тему, но ничего более осмысленного, чем “таковы правила” услышать не удалось. К счастью, и с требованием переделать под стандарт либо каким-либо ущемлением релиза сталкиваться тоже не приходилось.

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

Большую помощь при подсчете размера окажет встроенный в XviD Bitrate Calculator.

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

Конечно, битрейт существенно зависит от размера кадра. Наверное, не стоит делать полный кадр 720x576 при 500 kbps. С другой стороны, какой интерес рассматривать на 19-дюймовом мониторе изображение величиной с почтовую марку? Конечно, его придется масштабировать, а это тот же самый ресайз, только производимый в реальном масштабе времени, чаще всего по упрощенным алгоритмам (по крайней мере, таковы настройки по умолчанию моих  медиаплееров). На мой взгляд, время сверх-компактных рипов уже давно прошло. Наверное, они имеют право на существование - для фильмов в стиле “побыстрее скачал, вполглаза посмотрел”. На PSP или iPhone в толкучке метро.

Размер кадра и битрейт участвуют в так называемом соотношении Quality factor (Qf), который часто считается показателем качества видео. Qf = b/(v*h*f), где b - это битрейт, v - вертикальный размер кадра,  h - горизонтальный размер кадра и  f - число кадров в секунду.

На мой взгляд, показатель этот довольно искусственный, реальное качество очень сильно зависит от многих факторов, в том числе от исходного материала. В принципе, нормальные результаты обычно получаются в диапазоне Qf=0.15–0.25, здесь больше нужно доверять своим глазам, а не цифрам. Проблема только в том, что некоторые трекеры (или релиз-группы) формально ограничивают диапазон Qf.

Далее у нас (точнее, у разработчиков XviD) идет описание зон кодирования - мощнейшего средства, позволяющего в некоторых ситуациях существенно повысить качество фильма. Сплошь и рядом бывает, что в целом фильм смотрится замечательно, а вот некоторые сцены явно “выбиваются” - на них сильно заметны артефакты сжатия. Можно, конечно, повысить общий битрейт, только зачем? Запоминаем эти сцены при просмотре и ищем их потом в VirtualDub, который выдает нам, в том числе, текущие номера кадров изображения. Эти номера потребуются при описании зон XviD: ставим критичным сценам вес, равный двум (W 2.00), а остальным - равным единице (W 1.00).

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

Максимальный битрейт можно вычислить с помощью бесплатной программы Bitrate Viewer. Также конкретные места бывает удобно посмотреть в плеере MPC Home Cinema (установите флажок View\Statistics). Желательно, чтобы битрейт видео никогда не превышал 6500 kbps. Если получается больше - поставьте Q 3.00. Или не заморачивайтесь и используйте веса - с W 2.00 я чрезмерного битрейта не замечал.

В принципе как-то ограничить битрейт можно профилями кодирования. Так, выбранный нами профиль Advanced Simple@L5 имеет потолок 8000 kbps, по всей видимости, такой поток считается вполне нормальным. На мой взгляд величина эта слишком большая, на слабых системах картинка иногда “замораживается”. Однако предыдущий профиль, описанный в стандарте MPEG-4 Part 2, Advanced Simple@L4, выставляет ограничение потока в 3000 kbps, а это уже слишком мало. XviD имеет нестандартный профиль Home, он ограничивает битрейт величиной 4854 kbps, что, в общем-то, тоже маловато. Впрочем, строгость этого ограничения, как это нередко случается, компенсируется необязательностью его исполнения.

В любом случае вопрос пикового битрейта довольно нетривиален, более подробно он рассмотрен в разделе “Часть 2. Выжимаем еще немного качества или Осваиваем AviSynth”.

К сожалению, количество зон в текущей сборке XviD не особенно велико - их может быть не более 64. Фрагментов при этом будет приблизительно вдвое меньше - чуть больше 30. На первый взгляд, этого должно быть вполне достаточно, но я, как видите, уперся в данное ограничение - иначе откуда бы я про него узнал? В принципе, количество зон можно увеличить самостоятельно - исходники кодера находятся в свободном доступе.

Я предпочитаю, чтобы зоны начинались с ключевого кадра, в VirtualDub он помечается признаком [I] (в поле, где указывается номер кадра). В этом случае и на вкладке зон XviD необходимо отметить флажок Begin with keyframe.

Quality preset устанавливаем в (user defined), на вкладке Motion обычно советуют выбрать Motion search precision: 6 - Ultra High и VHQ mode: 4 - Wide Search. Ставить или сбрасывать VHQ for bframes too, Use chroma motion и Trellis quantization (на вкладке Quantization) - экспериментируйте сами, на совместимость они не влияют. Я обычно сбрасываю эти три флага.

Некоторые аппаратные плееры не любят идентификатор кодека XviD, поэтому на вкладке Encoder раздела Other Options… устанавливаем FourCC used: DX50 (кстати, имейте в виду, что в некоторых версиях кодера собственные профили Xvid Mobile, Xvid Home и т.д. не дают поменять этот параметр). Также во избежание проблем я ставлю здесь Number of threads = 1.

В кодере XviD еще довольно много параметров тонкой настройки типа Curve compression, но лично мне какого-либо заметного эффекта от их применения обнаружить не удалось. Вполне вероятно, что у вас на вашем материале это получится лучше, детальное описание XviD можно найти во многих местах, в частности, здесь - www.svcd.ru/docs/articles/convert/xvid.php?page=1 или здесь - www.dvdtocd.narod.ru/xvid.htm.

Буквально чуть-чуть о параметрах для поклонников DivX. По большому счету, все то же самое: Certification Profile - (Unconstrained), Multipass, Bitrate calculator, Encoding mode - Insane Quality, Quarter-pixel search - off, Global motion compensation - off, Quantization - H.263. B-фреймы спрятаны в параметре Bidirectional coding:, при этом Adaptive Single Consecutive соответствует в XviD Max consecutive BVOPs = 1, а Adaptive Multiple Consecutive - Max consecutive BVOPs = 2. Параметром Packed bitstream управлять нельзя (и правильно, как мне кажется), при использовании B-фреймов DivX устанавливает его всегда. После сборки фильма этот флажок можно будет отключить программой MPEG4 Modifier. Но лучше решить этот вопрос кардинально - поставить Bidirectional coding: off. Параметры Noise Reduction и Psychovisual Enhancements на совместимость не влияют (хотя относительно последнего у меня появились сомнения), выбирайте их по своему усмотрению в зависимости от исходного материала. Я обычно устанавливал их в off.

Лучше всего от греха подальше воспользоваться профилем совместимости Home Theater Profile - увидите, что он сразу же запретит устанавливать Quarter-pixel search, Global motion compensation, Adaptive Multiple Consecutive, Psychovisual Enhancements и матрицу квантизации MPEG.

Вот на этот факт предлагаю обратить особое внимание. Компания DivX, LLC - это коммерческая организация, прилагающая значительные усилия для продвижения своей продукции. В частности, она сертифицирует на совместимость устройства для воспроизведения MPEG4-видео сторонних производителей, неся за это финансовую и имиджевую ответственность. И если эта компания считает MPEG-матрицу квантизации, 2 B-фрейма подряд и тому подобные опции несовместимыми с аппаратными плеерами, к кому же нам еще прислушиваться? Неужели к энтузиастам, кодирующим рипы по профилю чипсета собственного проигрывателя?

Также кодер DivX имеет по сравнению с XviD (имеется в виду последний на данный момент “официальный” релиз) два расширения - многопроходное кодирование и матрицу квантизации H.263 Optimized. Что касается второго - особенной разницы со стандартной матрицей я не обнаружил, опять же непонятно, как это скажется на совместимости. А вот многопроходное кодирование я исследовал очень тщательно, на совместимость оно не влияет, а если можно получить прирост качества даром (компьютерных трудов мне не жалко) - это было бы просто замечательно. Собственно, именно эта возможность кодера DivX в свое время выдвинула его в моих глазах в лидеры. Однако как я ни старался, но так и не смог зафиксировать улучшение качества видео на третьем, четвертом и даже пятом проходах.

Необходимо обсудить еще один момент -  однопроходное кодирование. Совет кодировать с постоянным квантизером периодически встречается в мануалах по рипованию. Более того, чаще всего предлагается использовать Q=2, типа для достижения ультимативного качества. Я считаю такой подход абсолютно бессмысленным. При квантизере 2 размер видео уменьшается очень незначительно, у меня получилось всего в 1.5 раза. Кому нужен SD-рип размером 4 Гб? Если  места не жалко, лучше перекодировать фильм в формат DVD5 - качество получится лучше, можно сохранить меню и субтитры, плюс абсолютная совместимость.

Но все-таки определенное рациональное зерно в этих рассуждениях есть. Попробуйте Q=3 - это единственное исключение из правила, что при многопроходном кодировании для одинакового выходного размера результат всегда получается лучше. В зависимости от материала может выйти и наоборот. Кроме того, здесь вы застрахованы от ошибок кодера при распределении потока, а они, к сожалению, периодически встречаются. Битрейт, правда, немного высоковат - у меня получился около 2000 kbps, но для не особенно длинного фильма это вполне приемлемо. Однако при использовании постоянного целого квантизера невозможно попасть в стандартный размер, а это почти наверняка вызовет нарекания со стороны модераторов торрент-трекеров. Использование же дробного квантизера, на мой взгляд, вообще нелепо - фактически вы заставляете кодер уложиться в требуемый размер (битрейт), но принуждаете делать это вслепую, без возможности проанализировать поток. Ничего хорошего из этого не получится. Но если вы делаете рип исключительно для собственных нужд, кодирование с постоянным квантизером Q=3 - неплохой вариант: работает быстро и думать не нужно. Кстати, этот способ имеет смысл использовать при кодировании домашних фильмов в программе видеомонтажа типа Pinnacle Studio. Не DVD-рипом единым жив человек.

Теперь несколько замечаний для любителей поиграться параметрами (я надеюсь, не влияющими на совместимость).

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

Для кодирования домашнего видео я уже много лет использую программу Canopus Procoder версии 1.5 с кодером от версии 1.01.35 - эта связка неизменно давала самый медленный и самый качественный результат по сравнению с конкурентами, а также со своими более поздними версиями, включая “старшего брата” - Rhozet Carbon Coder. И вот однажды мне на глаза попалась статья, где на скриншотах как дважды два доказывалось, что очередная версия Cinema Craft Encoder (CCE) дает существенно лучшую картинку.

И я решил в который раз проверить, уж не упало ли, в самом деле, небо на землю. Нет, осталось там, где ему положено - старое видео понравилось мне намного больше, по сравнению с новым, закодированным CCE. Ради интереса я снял скриншоты, и каково же было мое удивление, когда кадры, вышедшие из CCE, действительно оказались лучше.

В чем же дело? А в том, что умудренный жизнью Canopus кодирует именно видеопоследовательность, а не набор кадров. Отдельные кадры, действительно, получаются немного хуже (но на видео это разглядеть невозможно), зато соседние кадры меньше различаются между собой. За счет этого видео выглядит гораздо лучше, на нем намного меньше видна рябь от шума сенсора видеокамеры и артефактов сжатия.

Мораль сей басни такова - не делайте выводов о качестве картинки только на основании скриншотов. Гораздо важнее - как выглядит видео. Обращайтесь к скриншотам только тогда, когда не можете различить видео. Или вообще не обращайтесь, если, конечно, вы делаете рип “обычного” фильма. Если это произведение искусства на все времена, можно и помучиться немного, подбирая оптимальные для этого фильма параметры чтобы получить идеальные стоп-кадры. Но только не в ущерб совместимости, я вас умоляю! Большинство людей незначительного прироста качества просто не заметит, а вот те, у кого будут проблемы с воспроизведением, помянут вас недобрым словом, уж будьте уверены.

Кроме того, сравнение нужно проводить в одинаковых для участников условиях, а их создать часто бывает весьма непросто. Во-первых, кадры бывают разных типов, и сжимаются они по-разному. Но это учесть не очень сложно - информацию о типе всех кадров можно почерпнуть из программ MPEG4Modifier (нажав последовательно VideoInfo и Write Frame List…) и Gspot (кнопка VGS). Далее - разница может быть просто за счет другого распределения битрейта. Различные кодеры, или различные их версии, и даже различные параметры приводят к разным схемам распределения. То есть какое-то видео будет лучше в одном месте, а другое - в другом. Хуже того, кодер может регулировать размер кадра довольно грубо, с точностью до квантизера. Допустим, он решил, что некоторый фрагмент требует определенного битрейта. Этому битрейту соответствует какой-то квантизер, например, 3.5. Но квантизер может быть только целым числом, поэтому кодер начинает чередовать кадры с квантизерами 3 и 4, чтобы в среднем получить требуемый битрейт. И вы вполне можете получить преимущество того или иного видеоряда просто попав не на ту пару кадров. А другая пара даст прямо противоположный результат. Конечно, сплошь и рядом бывают случаи, когда разница очевидна. Но вот близкие по качеству видеопоследовательности оценить объективно  не всегда легко.

Второе замечание касается воспроизводимости результатов кодирования. Проделайте такой эксперимент - закодируйте какой-нибудь небольшой фрагмент при одинаковом наборе параметров два раза (первый проход, затем второй, затем опять первый и, наконец, последний второй) и сравните варианты. Безусловно, вы ожидаете, что результат будет одинаковым; как правило, так оно и есть. Но бывают и исключения - с кодером DivX на одной системе у меня получались разные файлы! И речь идет не о служебной информации типа даты-времени - различным было содержимое кадров. При этом результаты кодирования в XviD полностью совпадали (кроме того, они были идентичны сделанным на других компьютерах с теми же настройками).

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

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

Конечно же, я не призываю при подборе оптимальных параметров кодировать каждый раз весь фильм. Однако отрезок должен быть достаточно представительным - как по длине, так и по набору сцен. Конкретизировать здесь достаточно сложно, тем более, что немаловажное значение имеет тот же самый битрейт - понятно, что чем он ниже, тем  критичнее может малая часть отличаться от целого. Я, по крайней мере, если речь не идет о совсем уж прикидочных тестах, обычно беру отрезок не менее 15 минут.

4. Кодирование аудио

Как известно, самое лучшее перекодирование - это отсутствие всякого перекодирования. Почему бы не использовать звуковые дорожки AC3, находящиеся на DVD-диске? И хлопот меньше, и качество не страдает.

Если вы отчаянно боретесь за каждый мегабайт - можете пережать звук в MP3, для этого есть множество инструментов, например, Lame (www.doom9.org/software.htm). Советую только кодировать с постоянным битрейтом (CBR). Встречается мнение, что лучшей версией этого кодера является 3.93.1 (ftp.core.pl/pub/people/konrad/winamp/lame-3.93.1.zip).

Ну и, конечно, не стоит к небольшому по размеру видео прицеплять несколько огромных аудиодорожек DTS. Собственно, дорожки DTS не стоит включать в рип в любом случае.

UPD: Жизнь не стоит на месте, и приходится учитывать новые нюансы. Когда писалась эта статья, мне не встречались аппаратные медиаплееры, не поддерживающие звуковые дорожки AC3. Но теперь такое случается сплошь и рядом, например в ресиверах DVB-T2, про проигрыватели мобильные устройства даже не говорю. Произошла столь печальная деградация из-за не вполне адекватной лицензионной политики компании Dolby Labs. Некоторые, правда, ресиверы цифрового телевидения и за медиаплееры-то не считают, но лично я не разделяю эту точку зрения. Посмотреть кино на даче на стареньком телевизоре - самое то. Поэтому сейчас для достижения максимальной совместимости по всей видимости следует использовать формат MP3.

5. Субтитры

Вкратце - субтитры бывают отключаемые (софтсаб) и неотключаемые (хардсаб, наложенные). За крайне редкими исключениями, имеет смысл делать субтитры первого типа, зачем портить изображение?

Для рипов чаще всего используются субтитры в формате .SRT, это обычные текстовые файлы с определенной разметкой. Самый лучший, на мой взгляд, инструмент их создания и корректировки - Subtitle Workshop (www.urusoft.net).

К сожалению, мне не известны медиаплееры, умеющие наложить субтитры, выдернутые с DVD-диска, на видеофайл .AVI. Поэтому очень часто возникает вопрос - какой волшебной программой можно конвертировать субтитры .SUP в формат .SRT?

Ответ будет огорчительным - никакой; на DVD субтитры представлены в графической форме, и это уже задача распознавания образов, а не просто переупаковка байтов. Конечно, конверсию вполне можно сделать, но работа эта достаточно кропотливая. Чаще всего гораздо проще бывает отыскать уже сделанные кем-то субтитры в текстовом виде. Готовые субтитры, инструменты для работы с ними, статьи и ссылки можно найти здесь - subtitry.ru.

Теперь пара слов об именовании субтитров. Для того чтобы плееры загружали субтитры по умолчанию, имя файла .SRT должно совпадать с именем контейнера .AVI. А как поступить, если субтитров несколько? Очень просто - добавьте после имени контейнера точку и название вида субтитров. Например: rj.1968.xvid.dvdrip.avi, rj.1968.xvid.dvdrip.ru.srt, rj.1968.xvid.dvdrip.en.srt.

Предыдущий пример не слишком удачен в том смысле, что если аппаратный DVD-плеер не понимает длинных имен, то и субтитры он подгрузить не сможет. Поэтому старайтесь использовать названия покороче, в пределе - 8.3. Беда только в том, что правила именования, принятые на некоторых трекерах, могут не дать вам такой возможности. Напишите гневное письмо Администрации.

6. Сборка фильма

Если у вас всего одна аудиодорожка - ничего, кроме VirtualDub, и не понадобится. Если дорожек несколько, то чаще всего используют два инструмента - программу AVI-Mux GUI (www.alexander-noe.com) либо нашего старого знакомца VirtualDubMod.

По поводу AVI-Mux сразу скажу, что встречаются отзывы о проблемах при воспроизведении изготовленных с ее помощью фильмов, и использование этой программы на ряде торрент-трекеров не приветствуется. С другой стороны, это единственная известная мне программа, которая корректно встраивает субтитры .SRT в контейнер .AVI.

Нужно ли их встраивать - это отдельный вопрос, бытовые MPEG-4 плееры все равно чаще всего не умеют воспроизводить внутренние субтитры, поэтому приходится иметь также внешние. Но тогда компьютерные медиаплееры будут предлагать вам два комплекта субтитров - внутренние и внешние, а это не очень красиво.

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

Короче, сам я по вышеперечисленным соображениям субтитры не встраиваю и использую VirtualDubMod, чего и вам желаю. Если у ряда пользователей возникают проблемы с фильмами, собранными AVI-Mux, кому это надо? Наш рип должен работать у всех без исключения. Да что там далеко ходить - у меня самого пару раз на файлах, изготовленных AVI-Mux, зависала программа Ulead Video Capture.

Если без AVI-Mux вы по каким-то причинам обойтись не можете - дам несколько советов по ее использованию, баловался я с ней одно время, пока меня не посетило озарение.
- Ничего нельзя удалять, программа вылетает. Также вылетает, если результирующий файл захвачен.
- Используйте версию - 1.17.7 (в 1.17.8 не сохраняются имена потоков). Если появились более поздние версии, проверьте первым делом этот момент.
- Файлы необходимо добавлять в том порядке, как они должны отображаться (включая generate data source!). Выделите потоки по умолчанию: видео, аудио, субтитры, причем желательно, чтобы они были первыми (в своем разряде).
- Настройки: снять флажки с Open DML output, make Rec list, MP3 CBR frame mode.

Итак, если аудиодорожка одна - загружаем в VirtualDub подготовленное на предыдущем этапе видео, аудио (Audio\Audio from other file…), не забываем выставить для обоих потоков режим Direct stream copy, и, наконец, Save old format AVI. Символы кириллицы в имени файла крайне желательно не использовать.

Если аудиодорожек  несколько - загружаем в VirtualDubMod видео, открываем пункт меню Streams\stream list и добавляем файлы аудио, сначала тот, который, по вашему мнению, должен загружаться по умолчанию. Чтобы в медиаплеерах отображались осмысленные названия, для каждого потока невредно задать имя - отмечаем нужный поток, жмем кнопку Comments, выбираем Title, и в поле Value пишем соответствующее значение - лучше, конечно же, латиницей. Не забываем надавить на кнопку Add.

Теперь один нюанс. VirtualDubMod, в отличие от  VirtualDub и AVI-Mux, записывает фреймы аудио AC3 в режиме Split across interleaves, т.е. одна часть фрейма расположена в одном блоке (chunk), а другая - в следующем. При этом на некоторых системах я наблюдал периодическое подергивание видео. Интересно, что фреймы MP3 CBR VirtualDubMod располагает всегда целиком в одном блоке (режим Aligned on interleaves).

И настроить режим упаковки аудио нельзя. Что же делать?

К счастью, VirtualDubMod можно обмануть. Дело в том, что независимо от битрейта, каждый фрейм AC3 при частоте 48 килогерц (а это почти всегда так) имеет длительность 32 миллисекунды. Необходимо щелкнуть правой кнопкой мыши на каждом аудиопотоке, выбрать пункт  Interleaving… и задать в полях Preload и Interleave audio every количество миллисекунд, кратное 32 (я обычно ставлю значение 320 в оба поля). Естественно, перещелкиваем радио-кнопку с frames на ms.

Опять же, не забываем выставить для всех потоков (включая видео) режим Direct stream copy, выбираем пункт меню Save as и отмечаем флажок Save AVI in old 1.0 format. Если есть сомнения, что результирующий фильм получится размером меньше двух гигабайт, ставим галочку на параметре Segment output file. Для фильмов, заведомо превышающих два гигабайта, можно поставить размер порции 1000 МБ - если резать, так уж резать! Так вы сможете соблюсти самое жесткое из известных мне ограничений на размер файла (кстати, недаром именно на такие куски режут обычно VOB-файлы программы DVD-авторинга).

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

Работает сборка быстро, даже кофе с удовольствием от успешно завершенной работы попить не получится. Поэтому есть все основания последовать совету бывалых риперов - разделять процессы кодирования видео, аудио и сборки фильма.

7. Резюме по настройкам

Меня могут спросить - как же так, вот вы рекомендуете одни настройки, кто-то советует другие, а кое-кто - диаметрально противоположные. Вы уж там разберитесь между собой и выдайте нам глобально оптимальные параметры.

К сожалению, это невозможно. Разный материал, разные глаза и разные руки. Впрочем, на самом деле это и не нужно, необходимо просто понять, что является существенным, а что - нет. Главное - не делать грубых ошибок, а пятипроцентное улучшение или ухудшение качества не заметит никто, в том числе и вы сами. Я уверен, что используя MPEG-2 плагин от fccHandler и настройки XviD по умолчанию, вы получите более качественное видео, чем провозившись неделю с тонким тюнингом параметров при использовании встроенного модуля MPEG-2 VirtualDubMod.

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

0. Делайте рип на “чистой” системе.
1. Используйте VirtualDub с MPEG-2 плагином от fccHandler.
2. Соблюдайте правильное соотношение сторон (реальное, а не формальное), размер по горизонтали предпочтителен 720 пикселей для сохранения пропорций на телевизоре.
3. Не забывайте про формальные ограничения размера кадра - не более 720 пикселей по ширине, W-Mod=16(32)/H-Mod=16.
4. При ресайзе используйте алгоритм Precise bicubic (А= -1.00) либо Lanczos3.
5. Используйте кодер XviD с зональной обработкой критичных сцен (только не забывайте при этом об ограничении битрейта).
6. Используйте матрицу квантизации H.263 и не используйте Quarter Pixel, Global Motion Compensation и B-фреймы.
7. Не экономьте на битрейте, но и не раздувайте его, наиболее целесообразным представляется диапазон 1200-1600 kbps.
8. Если ничего хорошего не получается - попробуйте отключить в кодере мультипотоковую обработку (Number of threads = 1).
9. Не перекодируйте без необходимости аудиодорожки (UPD: в настоящее время я в этом не уверен из-за нередких сейчас проблем с поддержкой AC3).
10. Не используйте без крайней необходимости видеофильтры-улучшайзеры.
11. Используйте контейнер .AVI версии 1.0 и постарайтесь уместить фильм в 2 ГБ.
12. Сборку с одной аудиодорожкой производите VirtualDub, с несколькими - VirtualDubMod.  Заставьте VirtualDubMod задействовать режим упаковки фреймов AC3 Aligned on interleaves.
13. Если аудиодорожек несколько - именуйте их, не заставляйте зрителей применять тотальный перебор.
14. Не встраивайте субтитры в контейнер, дайте шанс неопытным пользователям скорректировать или заменить их.
15. В именах не используйте символы кириллицы и экзотические спецсимволы.
16. Убедитесь, что количество кадров видео и длительность рипа соответствуют оригинальному DVD.

8. Формальный контроль

На всякий случай проверяем формальные параметры результата - для этого я использую утилиты Gspot (gspot.headbands.com) и MPEG4 Modifier (moitah.net). Кому-то больше по душе MediaInfo (mediainfo.sourceforge.net), к тому же она умеет сгенерировать текстовый отчет, который часто просят включить в описание раздач на торрентах. Кстати, я советую включать этот отчет всегда - есть пользователи, которых интересуют подробности релизов. А ведь нам теперь стыдиться нечего.

Программа Gspot позволяет определить тип контейнера (должен быть AVI 1.0), режим упаковки аудио (должен быть Aligned on interleaves), а также подсчитает за нас с вами коэффициент Qf.

Используя программу MPEG4 Modifier, можно выяснить состояние флажка Packed bitstream и, в случае необходимости, снять его. В разделе Video стоит посмотреть параметры видеопотока, в том числе матрицу квантизации.

9. А теперь - смотрим, что получилось

Перед тем, как выкладывать рип на всеобщее обозрение, неплохо было бы просмотреть фильм самому и проверить, все ли в порядке. Совместить, так сказать, приятное с полезным.

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

Core Media Player - совершенно “голый” плеер, все декодеры на пустой ОС Windows XP необходимо ставить отдельно.

Для декодирования видео я использую XviD, он нравится мне больше всего, причем независимо от того, что использовалось при кодировании. Встречается, правда, мнение, что декодер DivX справляется с этой задачей лучше, но тут уж дело вкуса. Для декодирования AC3 можно использовать бесплатный фильтр sourceforge.net/projects/ac3filter/files/ac3filter/ac3filter_0_70b/. Чтобы воспроизводились субтитры, нужен фильтр VobSub (www.doom9.org/software.htm).

MPC Home Cinema (mpc-hc.sourceforge.net) - имеет встроенные декодеры MPEG-4 и AC3, но я предпочитаю заменить их на вышеуказанные. Для показа субтитров необходимо настроить вывод видео на vmr7 (renderless) или vmr9 (renderless), для последнего требуется установка directx9, для обоих вариантов также необходима поддержка direct3d. Лучше использовать vmr9, так как появляется возможность регулировки цвета (Options\Miscellaneous), но эта опция работает не на всех системах.

KMPlayer (www.kmplayer.com) - сразу работает все и безо всяких настроек (хотя там их имеется море). Тем не менее, пара ответов на часто задаваемые вопросы. Если кому-то не нравится внешний вид плеера - достаточно скачать с сайта производителя один (или несколько - под различные состояния духа) из двух сотен имеющихся там скинов. И еще один момент, с которым пришлось немного повозиться - лично меня раздражает, когда цвета ползунков постоянно меняются от загрузки к загрузке. Лечится это так - в Настройках устанавливается Расширенное меню, при этом появляется меню Обложки, и уже в нем выбираем Цветовую схему по вкусу, отличную от Случайно, которая там почему-то установлена по умолчанию (сори за русское меню). И еще - отключите опцию нормализации громкости, она изрядно портит звук (Аудио - Нормализация).

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

Для тестирования вместо декодера XviD желательно выбрать что-нибудь похуже. Я, например, для этих целей обычно использую изумительный по своей капризности и глючности декодер Intervideo (mp4vdec.ax, от 21.02.05, file version 0.8.7.0, 290901 байт), поставленный в свое время вместе с WinDVD Platinum 6.0.6.128. Если уж на нем все будет в порядке...

Да и монитор (при возможности, конечно) хорошо бы взять поплоше - на моем домашнем, с матрицей S-IPS, контролировать не очень легко, он почти все показывает прилично. А вот на рабочем компьютере артефакты порой так и прут.

Хорошо бы еще проверить релиз на каком-нибудь (стареньком!) железном плеере, не забываем, что мы делаем рип для всех.

Кроме визуального контроля, могу предложить еще элементарное средство автоматизации: установите в MPC Home Cinema флажок View\Statistics, а в настройках Playback - Play = 1 times и снимите флажок Rewind when done playing. Запустите фильм и после окончания посмотрите параметр Frames dropped: (Пропущенные кадры) - хорошо бы, чтобы он так и остался нулевым.

10. Заключение

Теории - это, конечно, замечательно. Давайте взглянем теперь, что получается на практике.

Посмотреть рип фильма Франко Дзеффирелли “Ромео и Джульетта”, сделанный в соответствии с указанными выше соображениями, вы можете здесь -  kinozal.tv/details.php?id=696707 или здесь - rutracker.org/forum/viewtopic.php?t=3218285.

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

Между прочим, этот рип является неплохой иллюстрацией того, что совместимость очень часто совершенно не вредит качеству. Сравнение видео показало, что несмотря на диктуемые портабильностью ограничения, качество картинки получилось самое лучшее по сравнению с пятью имеющимися на трекере релизами эквивалентного размера в классе ASP (один из которых, кстати, был закодирован с матрицей квантизации MPEG, другой - с B-фреймами и еще два имели размер более двух гигабайт) - rutracker.org/forum/viewtopic.php?p=39823986#39823986, rutracker.org/forum/viewtopic.php?p=39134105#39134105. Более того, рип достойно конкурирует с раздачами, закодированными H.264. Вот сравнительные скриншоты релизов H.264 (1190 kbps) и H.263 (1376 kbps) - screenshotcomparison.com/comparison/3698, screenshotcomparison.com/comparison/7548. А вот H.264 (1609 kbps) и H.263 (1376 kbps) - screenshotcomparison.com/comparison/3704. Как видите, увеличение битрейта практически ничего не прибавляет и кодеру H.264.

Ну, и замечательный фильм заодно лишний раз посмотрите, тоже невредно.

15.11.2010


Часть 2. Выжимаем еще немного качества или Осваиваем AviSynth

Для использования AviSynth есть несколько резонов.

1. AviSynth умеет работать в различных цветовых пространствах, VirtualDub - только в RGB. Поскольку и DVD-диски, и MPEG-4 ASP кодируются, как правило, в цветовом пространстве YV12, при обработке в VirtualDub производится сначала прямое, а затем обратное преобразование цвета. Попробуем обойтись без него.
2. Для AviSynth существует больше различных современных фильтров, нежели для VirtualDub, и эти фильтры лучше поддерживаются. Кроме того, фильтры VirtualDub могут использоваться с AviSynth, но не наоборот.
3. AviSynth является очень мощным и гибким инструментом, поскольку позволяет составлять достаточно сложные сценарии обработки. Многие известные медиаконверторы являются ничем иным, как графической оболочкой, надстроенной над AviSynth. Если вы решили серьезно заняться обработкой видео, рано или поздно все равно к нему придете.
4. В AviSynth загрузка MPEG-2 сделана более грамотно. Сначала проводится однократная индексация файла программой DGIndex, за счет этого фильм открывается очень быстро. В плагинах VirtualDub предварительной индексации нет, поэтому фильм загружается чрезвычайно долго. При проведении экспериментов по подбору оптимальных параметров такое поведение весьма раздражает.

Получить AviSynth можно здесь - sourceforge.net/projects/avisynth2/files/, последняя стабильная версия на момент написания - 2.5.8. Во избежание проблем сразу обновите  входящий в дистрибутив фильтр DirectShowSource до версии 2.5.8.8 (sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/DirectShowSource_2588.zip/download). Документацию на русском языке можно скачать отсюда - avisynth.org.ru/docs/russian/, есть еще немало хороших статей, например, эта - www.ixbt.com/divideo/avisynth1.shtml. Только учтите, что документация на русском языке частенько не соответствует актуальным версиям фильтров, так что лучше для справок пользоваться оригинальной документацией. Что-то можно почерпнуть из конференции IXBT - forum.ixbt.com/topic.cgi?id=29:9331.

Для того чтобы избежать конверсии цветового пространства, необходимо вместо режима Full processing mode использовать Fast recompress. При этом, естественно, нельзя будет использовать фильтры VirtualDub (имеется в виду - в интерфейсе VirtualDub, в скрипте AviSynth их использовать можно).

Чтобы освоить этот режим, мы немного отвлечемся и быстренько сделаем одну небольшую “халтурку”.

Не так давно на торрентах появился рип замечательного спектакля Театра на Малой Бронной “Варшавская мелодия”. Пожалуй, это лучший спектакль, который я видел за последние годы, и поэтому с нетерпением ожидал его, периодически сканируя трекеры. Дело в том, что мне посчастливилось быть в театре как раз в момент записи постановки, и где-то она рано или поздно должна была “всплыть”. И вот, наконец, добрые люди выложили этот шедевр.

К сожалению, на моем DVD-плеере рип этот в нескольких местах подтормаживал, ну, и цвета кое-где прыгали. Хотя в целом качество картинки очень достойное.

Смотрим MPEG4 Modifier - так и есть: матрица квантизации MPEG-custom, отсюда проблема с цветами. И B-фреймы присутствуют, а флажок Packed bitstream снят. Поскольку использовался кодек XviD, вполне возможно, что флажок снят при кодировании, вот вам и тормоза.

Давайте попробуем перекодировать этот фильм с совместимыми параметрами, а заодно и посмотрим, насколько деградирует качество.

Поскольку никаких фильтров нам применять не нужно, целесообразно использовать режим Fast recompress. И в раздельной обработке видео и аудио в данном конкретном случае нет никакого смысла, поэтому устанавливаем режим обработки аудиодорожки Direct stream copy. Конечно же, как обычно, сохраняем в контейнере old format AVI. Результат получился превосходный - отличия от оригинала можно найти только на скриншотах и только с лупой. А вот при использовании режима Full processing mode разница уже более заметна.

Продолжаем эксперименты. Почему бы не попробовать закодировать фильм c помощью DivX? В итоге получилось еще чуть-чуть, но лучше. Что я вам и говорил - качество кодеров DivX и XviD сейчас практически одинаково. Незначительное преимущество в картинке имеет то один, то другой в зависимости от материала и битрейта.

Все это очень здорово, качество не пострадало, цвета встали на место, но вот подтормаживание так и осталось. Стало быть, с B-фреймов и флажка Packed bitstream обвинения (в данном эпизоде) снимаем. Наверное, дело в слишком высоком битрейте. Смотрим проблемные места - битрейт видео выше 7000 kbps.

Можно ли понизить максимальный битрейт? К счастью - да: нужно надавить в настройках DivX кнопку Advanced и найти в окошке Manual CLI строчку типа -vbv 4854000,3145728,2359296. Первый параметр ключа Video Buffering Verifier (VBV) кодера как раз и отвечает за максимальный битрейт. Как же получилось, что при ограничении меньше 5000 kbps битрейт зашкалил за 7000 kbps? Проблема в том, что параметр Max bitrate ограничивает не мгновенный пик потока, а его превышение определенной длительности. По моим наблюдениям, разница между этими двумя понятиями составляет около 2000 kbps. Исходя из этого, понижаем параметр Max bitrate до 3000 - 4000 kbps. Не забываем нажать кнопку Apply. Особо переусердствовать в этом деле не стоит, иначе динамичные сцены могут рассыпаться на квадратики.

Для особо пытливых сообщу также, что в реестре Windows имеется ключ, который по идее должен ограничивать максимальный битрейт, однако мои эксперименты по его уменьшению не принесли каких-либо результатов.
[HKEY_CURRENT_USER\Software\DivXNetworks\DivX4Windows]
"VBV Channel Bitrate"=dword:006a1120

Однако в итоге, несмотря на предпринятые усилия, полностью избавиться от замораживания изображения так и не удалось. Не ловит ограничитель битрейта DivX резкие скачки изменения потока, хоть ты тресни.

Пришлось вернуться в старый добрый XviD и воспользоваться уже знакомой зональной технологией, на этот раз с прямо противоположной целью - поставить слишком динамичным фрагментам вес меньше единицы. Конечно, это значительно муторнее, чем задать один глобальный параметр, зато дает реальный результат. Как правило, W=0.5 вполне хватало, но в некоторых местах пришлось поставить W=0.4.

Но почему бы не задействовать профиль Home, который, как мы помним, ограничивает битрейт кодера XviD величиной 4854 kbps? Увы, и здесь, как и в случае с DivX, ситуация аналогичная - параметр этот не соблюдается.

UPD 06.04.2014
Однако буквально только что появилась информация, что последняя модификация XviD от Jawor (Xvid Video Codec 1.3.2 - Jawor's patched build) работает с ограничителями битрейта корректно.

Если так - давайте рассмотрим эти возможности более подробно. Вообще Video Buffering Verifier как таковой описан в стандарте MPEG-4 Part 2 и призван ограничить вариативность порождаемого видеопотока. XviD имеет три параметра, расположены они на вкладке Level. Параметр Max buffer size (в стандарте MPEG-4 он именуется как VBV buffer size) определяет минимальный размер памяти (в битах), требуемой для декодирования, он должен быть кратен 16384. Параметр Max bitrate задает максимальный битрейт (килобиты в секунду). В стандарте MPEG-4 он измеряется в битах в секунду и должен быть кратен 400. Параметр Max bits over any one second interval не определен в стандарте MPEG-4 и задает пиковый битрейт, превышающий одну секунду (в дебрях XviD он именуется vbv_peakrate). Интерфейс кодера не позволяет менять значения указанных параметров. Однако существует консольная версия - xvid_encraw, в которой это возможно, опции командной строки обозначаются соответственно -vbvsize, -vbvmax и -vbvpeak.

В общем-то не могу сказать, чтобы проблема с ограничением пикового битрейта была такой уж острой. Случай, с которым я столкнулся, является достаточно редким. Во-первых, качество источника было значительно хуже, чем типовое DVD-Video. А для кодирования плохого видео битрейт нужен существенно более высокий. Во-вторых, сцена была чрезвычайно тяжелая: в полумраке с потолка густо сыпались мелкие конфетти, имитирующие снег - практически “белый шум”. Вот кодеру и пришлось задирать битрейт. Художественные фильмы обычно стараются так не снимать.

Посмотреть, что получилось, можно здесь - kinozal.tv/details.php?id=814614, сравнение разницы с исходником - здесь screenshotcomparison.com/comparison/58497.

В итоге мы в очередной раз убедились, что кастомные матрицы MPEG и B-фреймы не добавляют качества видео (при достаточном битрейте) - оно практически не изменилось. И это при том, что было произведено пережатие фильма, в результате чего картинка в какой-то степени должна деградировать просто по определению. Если бы первоначальное кодирование производилось с совместимыми параметрами, полагаю, что разницы не было бы вообще (а то и немного лучше бы получилось).

Кстати говоря, скриншоты различных вариантов кодирования очень удобно сравнивать между собой в программе AvsP (avisynth.org/qwerpoi/Download.html) - открываете несколько вкладок (File - New tab), загружаете в них файлы (Edit - Insert - Insert Source), выходите на нужный кадр и просто переключаете вкладки колесиком мышки, сразу все видно. Если в видео используются B-фреймы и сброшен флаг Packed bitstream, AvsP порой показывает  совершенно не те кадры, которые должны быть. Установите флаг программой MPEG4 Modifier.

На этом релизе удобно также показать простейшие приемы обрезки видео, которые реализованы в VirtualDub.

Просматривая спектакль, я заметил в одном месте какое-то неприятное мельтешение. Открываю в VirtualDub - все понятно, при захвате на трех подряд идущих кадрах проскочили помехи в виде цветных кубиков. Нельзя ли их убрать?

Конечно же, можно, но трудоемкость этого сильно зависит от конкретной ситуации. Чтобы все было понятно в дальнейших рассуждениях - немного повторимся. Поток MPEG4 состоит из кадров трех типов. I-фреймы (еще их называют ключевыми, Key frames или K-фреймами) сжимаются сами по себе, при сжатии P-фреймов используется информация из предыдущего кадра, B-фреймов - предыдущего и последующего.

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

Как видите, B-фреймы и тут вредны. Без них все гораздо проще: удаление - от начала фрагмента до ближайшего I-фрейма, а выделение - от предыдущего I-фрейма до конца фрагмента.

К сожалению, VirtualDub показывает тип только для ключевых кадров - символом [K] в окне с номером фрейма. Более полную информацию о типе всех кадров можно узнать, как уже отмечалось, с помощью программ MPEG4Modifier и Gspot.

Да, если вы обнаружите, что VirtualDub “сошел с ума” и маркирует признаком ключевого кадра не начало, а конец эпизода, дублирует кадры либо вообще неожиданно всовывает фреймы из  другого куска - не пугайтесь. Виной всему, скорее всего, все тот же злополучный сброшенный флаг Packed bitstream.

В данном случае все оказалось до предела просто - три бракованные фрейма стояли как раз перед ключевым кадром, и в потоке присутствуют только P-фреймы. Просто выделяем кнопками Mark In (стоя на текущем кадре) и Mark Out (стоя на следующем кадре) нужный фрагмент и нажимаем Del. Теперь сохраняем фильм в режиме Direct Stream Copy, то есть без пересжатия.

Представим на секунду, что бракованные кадры оказались бы в середине последовательности. Тогда было бы значительно сложнее - просто так удалить их уже не удастся, декодер не сможет потом правильно восстановить изображение. Пришлось бы делать так - выделить фрагмент с нужными кадрами между соседними I-фреймами, разжать его каким-нибудь кодеком без потерь (например, Uncompressed RGB/YCbCr), удалить брак (теперь кадры не зависят друг от друга, поэтому их можно спокойно выбрасывать из любого места), а затем опять сжать кодером XviD(DivX), желательно с теми же параметрами, что и весь фильм. И в конце - заменить фрагмент в исходном фильме (Cut-Copy-Paste). Ну, и естественно, перегнать фильм в режиме Direct Stream Copy.

На самом деле “выкусывание” небольших фрагментов в конце эпизода используется не так уж и редко. Таким образом можно, например, синхронизовать аудио и видео потоки, не пережимая ни тот, ни другой.

Теперь возвращаемся назад, к нашим DVD-рипам и Ависинту. В двух словах идея работы AviSynth выглядит следующим образом - в программе VirtualDub вместо видеофайла (Open video file…) мы открываем скрипт с расширением .avs. Этот скрипт как раз и является источником кадров видео, которые VirtualDub тут же передаст выбранному нами кодировщику.

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

Для работы с видео MPEG-2 нам понадобится фильтр DGMPGDec, загрузить его можно отсюда hank315.nl, документацию можно получить здесь - neuron2.net. Архив включает в себя два файла - индексатор DGIndex.exe и собственно фильтр AviSynth DGDecode.dll, для простоты помещаем оба в каталог с фильмом.

Запускаем программу DGIndex, открываем в ней файл MPEG-2 и сохраняем проект, в результате получаем индексный файл .d2v.

Ну вот, теперь подготовительная часть завершена, займемся написанием скрипта (с этими словами открываем Notepad или любой другой текстовый редактор).

Вначале необходимо загрузить файл MPEG-2, пишем в скрипте следующие команды.

LoadPlugin("DGDecode.dll")
MPEG2Source(d2v="VideoFile.d2v")

Сохраняем этот простейший скрипт с расширением .avs и тут же открываем его в VirtualDub. В результате мы должны увидеть в окне VirtualDub наш фильм. Уфф! Пока все идет хорошо, как сказал один товарищ, пролетая мимо седьмого этажа.

Теперь самое время разобраться с колориметрией. В цифровом видео, в отличие от компьютерных мониторов, используется, как правило, унаследованный от телевидения цветоразностный сигнал YUV (Y - яркость, U - дополнение до красного, V - дополнение до голубого). Фишка здесь в том, что сохраняется совместимость с черно-белыми телевизионными приемниками (что на сегодняшний день уже не особенно актуально). Кроме того, человеческий глаз намного более чувствителен к яркостной составляющей, нежели к цветности, а вот это свойство чрезвычайно важно и поныне, поскольку цветоразностные составляющие могут быть сжаты существенно сильнее яркостной без видимого ухудшения качества.

Но есть некоторые нюансы. Во-первых, имеются различные немного отличающиеся друг от друга “рекомендации” по кодированию цветов, чаще всего в реальной жизни используются ITU-R BT.709 и ITU-R BT.601. В MPEG-4 ASP (XviD/DivX) почти всегда применяется вариант ITU-R BT.601, а на DVD-Video - обычно ITU-R BT.709.

Во вторых, при оцифровке применяются различные методы семплирования цветоразностного сигнала. На практике обычно встречается вариант YUY2 (он же 4:2:2), когда в изображении сохраняются все пиксели яркости и каждый второй по горизонтали пиксель каждой цветности (т.е. получаем 16 бит на точку), а чаще всего - YV12 (он же 4:2:0), когда сохраняются все пиксели яркости и только один усредненный бит каждой цветности из четырех соседних пикселей, образующих квадрат 2х2 (т.е. получаем 12 бит на точку). Поскольку цветоразностные компоненты усредняются не только по горизонтали, но и по вертикали (т.е. присутствуют точки из разных телевизионных строк), пространство YV12 плохо приспособлено для кодирования интерлейсного видео. Поэтому, если у вас чересстрочный источник, закодированный в YUY2, деинтерлейс необходимо производить до преобразования в YV12. Кроме того, теперь становится понятной рекомендация по обрезке полей, кратных двум пикселям, при кропинге изображения.

В третьих, существует два диапазона представления цвета, так называемые PC и TV. В первом, используемом на персональных компьютерах, значение цвета может меняться в пределах [0, 255], как и положено минимальному и максимальному значению восьмиразрядного целого беззнакового числа. Во втором, используемом в телевидении, значение яркости должно находиться в пределах [16, 235], а цветности - [16, 240]. То есть белый и черный цвета кодируются для телевидения и для компьютеров по-разному. В телевидении цвет ниже порога называют суперчерным, а выше - супербелым.

Более подробно о колориметрии можно почитать здесь - avisynth.org.ru/docs/russian/externalfilters/colormatrix.htm. Только имейте в виду, что это старое описание, не актуальное в смысле параметров фильтра ColorMatrix, оно приведено здесь для тех, кто не в ладах с английским. Остальным лучше сразу скачать последнюю версию фильтра (bengal.missouri.edu/~kes25c/ColorMatrixv25.zip), документация в комплекте.

Поглядим, что творится с колориметрией у нас. Добавляем в скрипт команду Info(), она выдает поверх видео основные параметры источника. Убеждаемся на всякий случай, что видео закодировано в цветовом пространстве YV12 (ColorSpace: YV12). Стало быть, конверсия нам не понадобится. Если бы цветовое пространство было другим, нужно было бы использовать команду ConvertToYV12(). Также конверсия необходима, если нам приходится использовать какой-нибудь волшебный фильтр, не поддерживающий цветовое пространство YV12, но не будем лезть в такие дебри.

Теперь заменяем последние две строчки командой MPEG2Source(d2v="VideoFile.d2v", info=1) и опять смотрим результат. Сейчас информацию о видео выводит уже фильтр DGMPGDec, нас больше всего интересует параметр Colorimetry, он имеет значение “ITU-R BT.470-2 System B, G (5)”. По табличке, приведенной в документации на ColorMatrix, определяем, что это и есть не что иное, как рекомендация ITU-R BT.601. То есть ничего преобразовывать нам не нужно! В противном случае пришлось бы вставить команду ColorMatrix(d2v="VideoFile.d2v", clamp=0). Первый параметр говорит о том, что информацию о колориметрии необходимо взять из исходного индексного файла, ко второму параметру мы вернемся чуть позже. По умолчанию ColorMatrix кодирует по рекомендации ITU-R BT.601, если потребуется что-либо иное - нужно будет установить соответствующее значение параметра dest.

Убираем из команды MPEG2Source параметр info=1 и добавляем в скрипт следующую строчку, после чего опять перезагружаем его в VirtuaDub.

ColorYUV(analyze=true)

Эта команда выдает максимальные и минимальные значения диапазонов цветовых компонент - яркости Y (она же Luma) и цветности U и V (они же Chroma) каждого кадра. При этом выводится две пары значений - абсолютный минимум-максимум и нестрогий (Loose) минимум-максимум, который не учитывает отдельные, редко встречающиеся нехарактерные точки. Анализировать нужно Loose Minimum/Maximum, поскольку в целом диапазон характеризуется именно этими значениями. Исключения будут воспроизводиться как суперчерный или супербелый цвета теми устройствами, которые на это способны, либо же просто отсечены в противном случае. Тем не менее, не стоит самостоятельно производить усечение “выбросов” командой Limiter(), как это иногда советуют. Кстати, именно за усечение диапазона отвечает параметр clamp команды ColorMatrix, значение 0 означает, что “обрезание” производить не нужно.

Пощелкаем теперь по различным кадрам видео и убедимся, что, судя по значениям Loose Minimum/Maximum, фильм закодирован в TV-диапазоне (было бы странно, если бы стандартный DVD-диск ему не соответствовал), и в то же время там присутствуют суперчерный и супербелый цвета.

Поскольку наш рип предназначен, в том числе, и для воспроизведения на телевизоре, преобразовывать диапазон мы не будем. В случае необходимости преобразование можно выполнить командой ColorYUV() либо той же самой ColorMatrix.

С цветами мы завершили, теперь все просто - необходимо выполнить кроп и ресайз, с которыми мы уже детально разобрались в прошлый раз. Отмечу только, что AviSynth предлагает значительно больше фильтров ресайза, нежели VirtualDub, их описание можно найти здесь - avisynth.org/mediawiki/Resize. В данном случае самые качественные результаты получились у меня с использованием фильтров Lanczos4Resize,  Sinc1024  и Spline16Resize (в порядке улучшения, но разница очень небольшая). Да, именно Spline16, хотя в упомянутом чуть выше описании говорится, что Spline36 и  тем более Spline64 дают более резкое изображение. У меня получилось с точностью до наоборот. И не вздумайте использовать ресайзер SincResize(), который появился начиная с версии 2.6 AviSynth - я получил просто отвратительные результаты (применялась последняя на тот момент версия 2.6.0 Alpha3 от 26.05.11). Лучше всего смоделировать Sinc имеющимися средствами:  Sinc256 эквивалентен LanczosResize(taps=8), а Sinc1024 - LanczosResize(taps=16).

Если вам необходимо увеличить размер кадра, начните с Lanczos4Resize. Из сплайновых ресайзеров мне больше всего понравился Spline36Resize. Сравнивая эти два, можно сказать так: как правило Lanczos4 дает чуть более резкое изображение,  а Spline36 - чуть более точное. Но не всегда - бывает и наоборот. Также в случае увеличения размера кадра можно попробовать применить следующий прием - увеличить картинку вдвое фильтром EDIUpsizer (web.missouri.edu/~kes25c/), а затем уменьшить ее до нужных размеров обычным фильтром ресайза.

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

Вот он, окончательный скрипт - как видите, ничего особенно страшного. Последняя строчка, исключенная сейчас символом комментария (#), использовалась для задания отрезка кодирования при тестировании различных алгоритмов ресайза.

LoadPlugin("DGDecode.dll")
MPEG2Source(d2v="VideoFile.d2v")
Crop(10, 0, -10, -0)
Spline16Resize(720, 416)
#Trim(0,55000)

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


Часть 3. Теперь немного пофильтруем или Вторгаемся на территорию ультранизкого битрейта

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

Мы рассмотрим только второй момент, поскольку во-первых, DVD Video имеет, как правило, хорошее качество, а во-вторых, устранение дефектов - вещь очень специфическая. Каждый тип дефекта требует применения собственных методов и фильтров, здесь лучше поискать тематические форумы. А вот фильтрование для улучшения сжимаемости - это достаточно универсальная тема, причем настолько, что некоторые даже советуют производить шумоподавление всегда (по крайней мере, при кодировании с помощью XviD/DivX).

Давайте разберемся. Кому какое дело до сжимаемости как таковой? Мне, например, никакого - важен качественный результат, и только. Так вот, качество практически не растет при увеличении битрейта более 1500 kbps. Это значит, что никакого смысла увеличивать сжимаемость видео в такой ситуации нет. И мы просто внесем фильтрами дополнительные искажения. А зачем?

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

Рассмотрим типовую задачу - изготовление DVD-Rip в типоразмере 700-745 Мбайт. Берем нашего обычного подопытного кролика - “Ромео и Джульетту”. Конечно же, не очень здорово издеваться так над бессмертным творением Франко Дзеффирелли, этот фильм заслуживает много большего. С другой стороны, с точки зрения сложности поставленной задачи вариант достаточно привлекательный: длительность более двух часов, старая пленка, да и оцифровка оставляет желать лучшего.

Для начала попробуем воспользоваться старыми рецептами рипования, просто понизив битрейт до 600 kbps - а вдруг прокатит?

Не прокатило, как и следовало ожидать - артефакты получились просто чудовищные. Стало быть, будем фильтровать.

Упомянутая выше статья www.ixbt.com/divideo/avisynth1.shtml содержит не только неплохое изложение основ AviSynth, но и введение в мир фильтрации. Написал ее не кто иной, как Александр Балахнин (aka Fizick) - автор довольно популярных фильтров шумоподавления DeGrainMedian и FFT3DFilter, и уж он разбирается в вопросе, можно не сомневаться.

Я опробовал практически все распространенные фильтры шумоподавления - VagueDenoiser, TemporalCleaner, DeGrainMedian, FFT3DFilter, TtempSmooth, FluxSmooth, SmoothHiQ, Convolution3D, RemoveGrain (avisynth.org/warpenterprises/). Причем с различными параметрами, рекомендованными как самими разработчиками фильтров, так и продвинутыми пользователями, съевшими собаку на этом деле. Более того, я пробовал различные монстрообразные сочетания фильтров типа MCTemporalDenoise.avsi (forum.doom9.org/showthread.php?t=139766) и “DVD MDegrain2 mask4 DLS.avs” (из программы XVID4PSP), грубо нарушив при этом завет Балахнина: “В среде профессионалов обычно распространено негативное отношение к скриптам верстки отдельных любителей, в которых нагромождено несколько фильтров подавления шума. Обычно это приводит к излишнему замыливанию картинки и накоплению артефактов”.

Каков же итог? А никакого. Либо не удается избавиться от артефактов, либо катастрофически падает резкость. Иногда получается так - скриншоты вышли очень неплохие, но при воспроизведении видео начинается настоящая свистопляска - мазня и рябь. Еще раз обращаю ваше внимание на то, что конечным продуктом является не набор стоп-кадров, а именно видеопоследовательность. К сожалению, не всегда визуально выигрышные кадры порождают качественное видео.

Безусловно, результат зависит от материала, поэтому воздержусь от глобальных выводов. Сформулирую так - далеко не факт, что фильтры помогут вам компенсировать дефицит битрейта. И уж я категорически против бездумного применения шумодавов “для лучшей лучшести”. Попробуйте сами - наиболее приличные результаты получились у меня при использовании следующих фильтров - FFT3DFilter(), VagueDenoiser(nsteps=6), FluxSmoothST(). Что характерно: как видите, практически везде - с параметрами по умолчанию.

Так что же делать? Как же люди умудряются изготавливать приличные рипы в данном типоразмере? Или для такого длинного фильма это вообще невозможно? Недаром минимальный битрейт для рипов ASP, допустимый на многих трекерах - 700 kbps (или даже выше).

Не будем терять надежды. Попробуем рассмотреть резервы, которые мы еще не задействовали.

Первый рецепт при недостатке битрейта очевиден - это уменьшение размера кадра. Берем из таблицы чисел, делящихся нацело на 16, несколько значений в районе 600 - 624, 608, 592, 576. Находим для каждого вертикальный размер так же, как делали это раньше. В моем случае лучше всего подошла ширина 608 пикселей: строим пропорцию - 608*9/16=342. Корректируем с учетом обрезания: 342*720/700=351,771. Опять повезло - 352 делится на 16, и разница получилась всего ничего.

Второй момент - ресайз. При недостатке битрейта нельзя использовать алгоритм lanczos и ему подобные, поскольку они увеличивают визуальную резкость, а нам нужно наоборот, немного “смягчить” изображение. Если вы до сих пор “застряли” в VirtualDub, используйте Precise bicubic (A=-0.60) вместо (A=-1.00), применявшегося раньше. Если уже перешли на AviSynth, лучше всего подойдет фильтр bicubic с параметрами по умолчанию (опробовались еще параметры, моделирующие фильтры VirtualDub - 0.6 и 0.75, а также 0.5 - Catmull-Rom spline). Можно еще попробовать алгоритм bilinear. В моем случае указанные варианты дали чуть худший результат.

И последнее - параметры кодирования. Если раньше (при достаточном битрейте) я рекомендовал выключать все опции кодера XviD, то сейчас подход будет диаметрально противоположным. Нужно наоборот, включить все параметры оптимизации - Adaptive Quantization, B-frames, Use chroma motion, Use VHQ for bframes too, Trellis quantization. Дадим кодеру шанс показать себя во всей красе.

И вот теперь все встало на свои места. Резкость, конечно, упала, но не катастрофически, артефакты почти незаметны. Конечно, B-фреймы вредят совместимости, но в данном случае без них никак не обойтись.

В общем, мои принципы подбора параметров кодера XviD в уточненной редакции таковы.

При достаточном битрейте выключите все опции кодирования. Затем, если желаете поэкспериментировать, включайте опции по одной - вполне возможно, что на конкретном материале какая-то из них “выстрелит”.

При дефиците битрейта включите все опции кодирования. Затем, если желаете поэкспериментировать, выключайте их по одной.

Важное замечание: параметры Quarter Pixel и Global Motion Compensation по-прежнему являются табу. Улучшения качества при использовании этих опции мне выявить не удалось, скорее - наоборот. Кроме того, не советую использовать более одного B-фрейма подряд. Вспомните также, что компания DivX, LLC считает все эти параметры несовместимыми с аппаратными плеерами.

На данном материале самый лучший результат получился у меня при включении всех параметров кроме Use chroma motion. Также некоторый прирост качества дала тонкая настройка кривых компрессии - Low bitrate scenes improvement = 20.

Посмотрим теперь, нельзя ли продвинуться еще дальше за счет использования MPEG-матрицы квантизации. Она, конечно же, тоже считается несовместимой, но в данном случае нам не до жиру - приходится чем-то жертвовать. В принципе, даже ярые поклонники матриц MPEG советуют использовать их только при битрейте более 1000 kbps. Однако существует специальный класс матриц, заточенных на ультранизкий битрейт. Я опробовал следующие - Jawor_1CD_Matrix.cqm, CCE Ultra Low Bitrate.cqm, Sharktooth's EQM v3ULR.cqm, Bulletproof's Heavy Compression Matrix.cqm (их легко найти в Инете по названиям). Но результат не порадовал - все они оказались хуже стандартной матрицы H.263. Приличнее всех выглядела матрица Jawor_1CD, изображение получилось в целом даже чуть более резким, зато взамен появились нехилые контурные “призраки”, которые начинали отчаянно “плясать” при воспроизведении видео. Сравнение скриншотов - здесь: screenshotcomparison.com/comparison/72240/. Полагаю, что популярность MPEG-матриц квантизации основана во многом на том, что релизеры ориентируются только на стоп-кадры, а вовсе не на видеопоследовательность. Ну, мы этот момент уже обсуждали.

Что-то мы совсем забыли про кодер DivX - может быть, он поможет нам добавить немного качества? Увы, мои опыты показали обратное - результат получился существенно хуже. Причем, на мой взгляд, психо-визуальные расширения реализованы в DivX, в отличие от XviD, из рук вон плохо.

В итоге, уменьшив размер кадра до 608х352, задействовав алгоритм ресайза bicubic с параметрами по умолчанию и установив опции кодирования Adaptive Quantization, 1 B-VOPs, Use VHQ for bframes too, Trellis quantization и Low bitrate scenes improvement = 20, мне удалось получить вполне приличный результат на битрейте 600 kbps. Посмотреть можно здесь - tfile.ru/forum/viewtopic.php?t=496843.

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

Не удержусь и процитирую еще одну мысль из статьи Александра Балахнина, всю гениальность которой я до конца осознал, только потратив кучу времени на возню с фильтрами, и так и не получив в итоге никакого удовлетворительного результата: “Мое мнение таково — если шума немного, то может лучше его не трогать? Просто добавьте битрейт, если это возможно. А если шума много, удалить его безболезненно тем более не получится”.

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


Часть 4. А теперь - Горбатый… тьфу, Matroska!

Выше я уже описывал причины своей нелюбви к связке H.264/.MKV. Тем не менее, нельзя не признать наличие у нее определенных достоинств, рассмотрением которых мы сейчас и займемся.

Если при использовании формата XviD/.AVI главным критерием была абсолютная совместимость (при отличном качестве), то сейчас во главу угла мы поставим максимальное качество в расчете на бит информации. Для достижения этой великой цели нам придется пойти на значительные жертвы - отправить в отставку большинство аппаратных MPEG-4 плееров и множество слабосильных компьютеров, а также предъявить повышенные квалификационные требования к пользователям, причем не только к релизерам, но и к зрителям.

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

Хотя, с другой стороны, у меня сложилось впечатление, что кодер H.264 имеет гораздо больший “запас прочности”, то есть прощает релизерам значительное количество ошибок без катастрофических последствий. Мне встречалось довольно много отвратительно закодированных рипов ASP, про AVC я такого сказать не могу. Впрочем, возможно, что все дело в том, что проектами AVC занимаются в основном более квалифицированные риперы.

1. Размер кадра

Самые большие изменения в теперешнем подходе коснутся ресайза - то есть его у нас не будет вообще (ну, или почти). Ограничения, связанные с кратностью сторон, увы, никуда не денутся.

А ведь и в самом деле, жалко выбрасывать из изображения горизонтальные строки, эта информация будет потеряна навсегда, а она является основой разрешения. И если в случае формата 4:3 мы потеряем всего 576-544=32 строки, то в 16:9 это будет уже целых 576-400=176 строк.

Конечно, изображение придется перестраивать в процессе просмотра, но мы уже договорились, что используем оборудование достаточной мощности.

Давайте прикинем, что у нас получится. Допустим, мы закодировали изображение 16:9 в формате 720х576. При воспроизведении проигрыватель должен восстановить пропорции. Если это будут те же 720х400 (даунскейл), то мы не выиграем ничего. И даже проиграем за счет того, что, используя тот же самый битрейт для кодирования большей площади кадра, мы своими собственными руками существенно уменьшили Qf.

Но если мы, вместо того, чтобы сжимать картинку по вертикали, растянем ее по горизонтали (апскейл), то за счет сохранения всех строк изображение будет выглядеть лучше, чем масштабированный в тот же размер вариант 720х400. Поскольку размеры экранов постоянно растут, именно этот вариант является предпочтительным.

Собственно, как раз так и поступают с анаморфным изображением DVD-плееры.

Берем опять наш любимый “Ромео и Джульетта”.

На этот раз мы будем делать кроп не 700 пикселей, как в прошлый раз, а 704 - ближайшее целое, кратное 16. Можно было бы, конечно, обрезать до 700 и растянуть затем до 704, но ведь любое преобразование ухудшает качество, а с этим мы примириться никак не можем. В принципе, черные полоски шириной в несколько пикселей, оставленные (или даже добавленные) для соблюдения правильных пропорций, обычно на трекерах ошибками не считаются.

Теперь мы должны подсчитать Aspect Ratio.

Вычисляем горизонтальный размер анаморфной картинки - 576*16/9=1024 пикселя.
С учетом обрезания - 704*1024/720=1001.24(4).

Теперь скачиваем отсюда - forum.doom9.org/showthread.php?t=107039 замечательный ARS Calculator, вбиваем в поля Width-Heigh Pixel Frame Size размер закодированного кадра (704x576), а в Movie Aspect Ratio - размер отображаемого кадра (1001,2444x576, внимательнее, дробная часть отделяется запятой) и нажимаем кнопку Calculate.

И о, чудо, калькулятор выдает соотношение 64:45, а это в точности соответствует PAL 16:9 стандарта де-факто (т.е. игнорирующего рекомендации ITU-R BT.601), согласно которому сделано большинство дисков DVD-Video. Значит, мы на правильном пути.

Для справки привожу таблички, которые часто цитируют в топиках, посвященных правильному выбору Aspect Ratio.

ITU-R BT.601
           PAL       NTSC
4:3   128:117 4320:4739
16:9 512:351 5760:4739

Generic PAR (Ignoring ITU)
         PAL   NTSC
4:3   16:15 8:9
16:9 64:45 32:27

MPEG-4 PAR
         PAL    NTSC
4:3   12:11 10:11
16:9 16:11 40:33

Более подробно с вопросом можно ознакомиться здесь.
rutracker.org/forum/viewtopic.php?t=858138
provegas.ru/forum/showthread.php?t=778
www.ruvideo.com/index.php?showtopic=35406
forum.doom9.org/showthread.php?s=9f2111e782317d0eafd8107ef49d3c1f&p=1058927#post1058927

2. Кодирование

При кодировании необходимо будет задать вычисленный только что Aspect Ratio (SAR width, SAR height), и, естественно, указать параметры, обеспечивающие максимальное качество изображения.

И здесь рипер должен пойти еще на одну жертву - времени: кодер AVC работает гораздо дольше (у меня - более чем в пять раз, 50 часов против 9 в случае XviD на одноядерном компьютере 3 ГГц под VMware Workstation).

На мой взгляд, наилучшим на сегодняшний день кодером в стандарте H.264 является бесплатный x264 - www.videolan.org/developers/x264.html. Реализацию в виде командной строки под Windows можно скачать отсюда - x264.nl. Запустите x264.exe --fullhelp, и вы получите подробное описание всех его опций, оно нам еще пригодится.

Чтобы не плодить сущности, будем использовать тот же инструментарий - VirtualDub с VfW-кодеком x264 от Komisar - komisar.gin.by/index.html. Многие релизеры для этих целей использует программы типа MeGUI (sourceforge.net/projects/megui/).

Итак, устанавливаем кодек и настраиваем параметры кодирования.

Если в случае с XviD/DivX при достаточном битрейте я советовал не использовать никаких экзотических настроек, то здесь все будет с точностью до наоборот. Для кодера H.264 опции нужно задействовать по максимуму. Во-первых, мы не имеем такой острой проблемы совместимости, как для H.263. Во-вторых, качество действительно значительно улучшается, на любом битрейте.

Опции сжатия я бы разделил на следующие категории.

1. Те, которые нужно ставить всегда.
Сюда я отношу: AVC level = 4.1, p4x4 = on, Fast P-skip = off, Mixed refs = on, Chroma ME = on, Weighted P-frames = Smart, In-loop deblocking filter = on, CABAC = on, DST Decimate = off. При использовании командной строки это выглядит так: --level "4.1" --partitions "p8x8, p4x4, b8x8, i8x8, i4x4" --no-fast-pskip --weightp 2 --no-dct-decimate.

2. Зависящие от вашего долготерпения и ценности кодируемого фильма.
Сюда я отношу: Max frame refs, ME algorithm, ME range, Subpixel ME refinement, Max consecutive B-frames, Adaptive B-frames, B-frames MV prediction, B-frames pyramid, Weighted B-frames prediction.

Для обычного случая можете оставить все по умолчанию, для максимального качества я использую следующие: Max frame refs = 4, ME algorithm = tesa, ME range = 24, Subpixel ME refinement = 10, Max consecutive B-frames = от 4 до 6, Adaptive B-frames = Optimal, B-frames MV prediction = Auto, B-frames pyramid = Normal, Weighted B-frames prediction = on. Для командной строки: --ref 4 --me "tesa" --merange 24 --subme 10 --bframes 4 --b-adapt "Optimal" --direct "auto" --b-pyramid "normal".

3. Зависящие от видеоматериала.
Сюда входят параметры для тонкой настройки (тюнинга) кодера. Лучше всего поступить следующим образом - взять за основу какой-нибудь имеющийся пресет --tune и плясать от него. Мне понравились два - film (оптимизация для среднестатистического фильма) и grain (оптимизация для зернистого изображения). Для “Ромео и Джульетты” с его старой кинопленкой лучше подошел последний. После некоторых экспериментов я “сдвинул” некоторые настройки в сторону пресета film. Вот что получилось в итоге: Psy RDO strength = 1.00, Deblocking strength = -2, Deblocking treshold = -2, Trellis = Always, Intra deadzone = 11, Inter deadzone = 21, Psy trellis strength = 0.15, AQ Mode = VAQ, Strength = 0.5, QP factor between I & P = 1.1, QP factor between P & B = 1.1, QP curve compression = 0.8. То же для командной строки: --deblock -2:-2 --trellis 2 --deadzone-intra 11 --deadzone-inter 21 --psy-rd 1.0:0.15 --aq-mode 1 --aq-strength 0.5 --ipratio 1.1 --pbratio 1.1 --qcomp 0.8.

4. Многопоточность, многопроходность, ассемблерная оптимизация.
К сожалению, процесс кодирования видео по своей природе последователен и не особенно хорошо поддается распараллеливанию. Что, несомненно, глубоко печалит владельцев многопроцессорных систем, распространенность которых даже на бытовом уровне растет сегодня день ото дня. Можно, конечно, было бы разбить фильм на отдельные сцены  и кодировать их независимо на уровне фронтального приложения. Однако программы, позволяющие автоматизировать такую процедуру, мне не известны, а делать это вручную муторно (да и коэффициент сжатия наверняка упадет). Многие кодеры, в том числе и x264, предоставляют возможность многопоточной обработки, разбивая кадр на слайсы, только это может пагубно повлиять на качество результата. Короче, сам я во избежание проблем использую опцию Threads = 1 (--threads 1). Конечно, если вы являетесь счастливым обладателем 2-х или 4-х ядерной системы - поэкспериментируйте в этой области.

Вероятно, отключение ассемблерной оптимизации в каких-то случаях может дать эффект, поскольку вычисления с плавающей точкой языка C точнее, чем SIMD-команды процессора. Однако в данном случае кодер x264 r1881 на процессоре Pentium 4 Northwood при использовании приведенных выше параметров показал абсолютно одинаковый результат. А время кодирования отличается в 3.5 раза. Так что я ставлю параметр Disable all CPU optimization = off. В случае командной строки процессорная оптимизация включена по умолчанию.

Кодер x264 поддерживает несколько однопроходных режимов - с постоянным квантизером (CQP), с постоянным качеством (CRF) и усредненным битрейтом (ABR). У меня результаты всегда получались хуже, чем при многопроходном кодировании (Multipass).

Многие советуют использовать для x264 трехпроходное кодирование. Однако я не смог обнаружить никакого прироста качества и поэтому кодирую в два прохода.

Также кодер x264 умеет работать с зонами, задайте в командной строке или в окне Extra options кодека VfW ключ --zones. Только обратите внимание, что в H264 применяется логарифмическая шкала квантизеров, формула соответствия: Qx264 = 12+6*log2(Qxvid).

В заключение хочу сказать, что по моим наблюдениям, для кодера H.264 параметры кодирования чрезвычайно важны, они даже важнее битрейта. Взгляните на сравнение двух релизов: screenshotcomparison.com/comparison/48033/ - первый на 40% больше, но существенно хуже.

3. Работа с частями

Контейнер MKV предоставляет возможность разбиения фильма на части, наподобие того, как это делается на дисках DVD. Не вижу причин, препятствующих переносу частей в наш рип.

Сначала список частей нужно импортировать с DVD. Проще всего это сделать бесплатной программой ChapterXtractor, заполучить ее можно, например, здесь - www.videohelp.com/download/ChapterXtractor_v0.962.zip. К сожалению, по умолчанию в ней отсутствует шаблон для контейнера MKV. Впрочем, его совсем несложно сделать самому.

Открываем конфигурационный файл ChapterXtractor.ini любым редактором и заполняем первый свободный пользовательский пресет.

Preset 7=MKV
Format 7=%sp%sp%sp%sp<ChapterAtom>\n <ChapterUID>12345%C%ms</ChapterUID>\n <ChapterFlagHidden>0</ChapterFlagHidden>\n <ChapterFlagEnabled>1</ChapterFlagEnabled>\n <ChapterDisplay>\n <ChapterString> </ChapterString>\n <ChapterLanguage>und</ChapterLanguage>\n </ChapterDisplay>\n <ChapterTimeStart>%hh:%mm:%ss.%ms</ChapterTimeStart>\n </ChapterAtom>\n
Header 7=<?xml version="1.0" encoding="UTF-8"?>\n\n<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->\n\n<Chapters>\n <EditionEntry>\n <EditionFlagHidden>0</EditionFlagHidden>\n <EditionFlagDefault>0</EditionFlagDefault>\n <EditionUID>2549807785</EditionUID>\n
Footer 7=%sp%sp</EditionEntry>\n</Chapters>\n

Запускаем программу, открываем вкладку Format и выбираем наш пресет MKV. Затем нажимаем на той же вкладке кнопку Open IFO, выбираем IFO-файл с основным фильмом (в конце концов, методом перебора) и получаем в главном окне список частей в нужном формате. Экспортируем его в текстовый файл с расширением .xml (Save data).

Существуют и другие инструменты экспорта частей - ChapterGrabber (jvance.com/files/ChapterGrabber.5.2.zip) и уже упомянутая MeGUI (Tools-Chapter Creator). Попробуйте сами - я ими не пользовался.

К несчастью, список частей содержит только временные отметки, названий частей там нет. Заполнить названия можно утилитой Chapter Editor, встроенной в программу mkvmerge (ее же мы будем использовать позже для сборки фильма).

Нужно загрузить (Load) в Chapter Editor файл .xml, “пройтись” по списку частей, вбить туда названия и выбрать необходимый идентификатор языка. Кстати, названий может быть несколько, чаще всего это нужно для поддержки нескольких языков. Ну, и Save as, как обычно.

4. Сборка фильма

Для сборки фильма используется программа mkvmerge из комплекта mkvtoolnix (www.bunkus.org/videotools/mkvtoolnix/win32/). Лично я остановился на версии 3.0.0, поскольку при использовании более свежих релизов неоднократно нарывался на неприятности.

В общем-то все стандартно - добавляем (add) на вкладке Input файлы видео, аудио и субтитров, в том порядке, как они должны появляться в проигрывателе, заполняем поля имени и языка трека. Установите для первой аудиодорожки тэги Default track flag = yes, Forced track flag = yes, для остальных - оба значения “no”. Для первой дорожки с субтитрами установите Default track flag = yes, Forced track flag = no, для остальных - оба значения “no”.

Далее загружаем на вкладке Global в разделе Chapters изготовленный на предыдущем этапе файл .xml с частями.

Жмем, наконец, заветную кнопку Start muxing.

5. Немного пофилософствуем

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

AVI: совместимость, ASP, ресайз, внешние субтитры.
MKV: качество, AVC, анаморф, встроенные субтитры.

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

Еще раз хочу подчеркнуть, что если все сделать правильно, и при условии достаточного битрейта (например, полуторачасовой фильм с одной-двумя дорожками в размере 1.46 Гб), то вариант, нацеленный на совместимость, будет уступать варианту, ориентированному на максимальное качество, довольно незначительно. По видео, не привлекая скриншоты, вряд ли кто-нибудь сумеет заметить разницу. Поэтому, если вы уж взялись за AVI, не стоит гнаться за микроскопическим улучшением качества в ущерб совместимости.

И еще мне довольно смешны яростные споры, что лучше: AVI или MKV, ASP или AVC. На мой взгляд, эти варианты должны существовать на трекерах абсолютно независимо, наряду с форматами DVD9 и DVD5. И каждый зритель сможет выбрать то, что ему подходит больше всего. И тогда сами собой уйдут многочисленные темы “Как мне MKV/MP4 перегнать в AVI”.

Кроме того, горячим поклонникам AVC/MKV стоит заглянуть на раздачи любого свежего популярного фильма и посмотреть, сколько пользователей качает/сидирует релиз MKV и сколько - AVI. И понять, что на самом деле нужно большинству зрителей (на сегодняшний день). Опять же возвращаемся к первоначальному вопросу - для кого вообще делается рип.

Сказанное вовсе не означает, что не нужно выкладывать для широкой аудитории AVC/MKV. Обязательно нужно! Но и замыкаться в элитарности, пренебрежительно относясь к ASP/AVI, тоже не стоит. Этот формат нам еще послужит.

6. Смотрим, что получилось

Для просмотра я рекомендую использовать KMPlayer, поставьте флажок Keep Display Aspect Ratio в меню Screen Control. При загрузке фильма плеер отображает разрешение картинки - в нашем случае, как вы помните, должно быть 1001х576. Если процессор достаточно мощный - установите какой-нибудь качественный алгоритм ресайза, например, bicubic (Preferences/Video Processing/Resize).

Неплохо теперь проверить качество изображения, переключение и синхронизацию звуковых дорожек и субтитров, а также выбор нужной части фильма (Bookmarks/Chapter).

Если все в порядке - бегом на трекер оформлять раздачу, пока нас не опередили конкуренты.

Я так и поступил - rutracker.org/forum/viewtopic.php?t=3570926.


06.07.2011

Добро пожаловать в мой литературный проект - роман «Постоянная времени»

WebMoney: R026331706659, Z515208365202    Яндекс.Деньги: 410013832498972



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


Приложение. Рейтинг российских торрент-трекеров с точки зрения релизера

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

1. rutor.org
Самое "мягкое" судейство. Если вы разбираетесь в обработке видео (что по прочтении вышеизложенного не вызывает каких-либо сомнений), достаточно аккуратны, а также внимательно изучили Правила оформления раздач, то с большой вероятностью вообще не узнаете, что это за зверь такой - "модератор".

Ваш релиз просто незаметно перейдет в разряд проверенных. Лично мне эта незаметность не нравится, т.к. все же хотелось бы явно зафиксировать, что раздача легитимна и заняться другими делами. На остальных трекерах факт проверки модератором отражается в явном виде. Неявным признаком может служить закрытие возможности редактирования описания релиза (при нажатии на кнопку "Редактировать" в нижней части формы добавляется текст "У Вас нет прав редактировать раздачи").

Хотя редактировать описание нельзя (что на мой взгляд плохо), его исходный текст  доступен и может быть использован как образец для создания описания похожих раздач. Кстати, инструментальные средства создания описания раздачи также продуманы очень хорошо. Вы можете не только заполнить, как обычно, соответствующий шаблон, но и (нажав кнопку "Правка BB") сразу перейти в режим редактирования исходного текста. На других трекерах для того, чтобы попасть в данный режим, приходится вбивать в три десятка полей формы какую-нибудь белиберду.

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

Старые релизы худшего качества удаляются на трекере достаточно оперативно.

Рейтинг - 5.

2. nnm-club.ru
Здесь встреча с модераторами гораздо более вероятна, впрочем, ничем особо страшным она вам не грозит. Модераторы вполне вменяемы и не досаждают релизерам мелочными придирками.

У администрации весьма практикуется не отвечать на личные сообщения пользователей.

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

Рейтинг - 4,5.

3. rutracker.org
Модераторы здесь более придирчивы. Порой создается впечатление, что они вообще не читают описание релиза, поскольку выдвигают странные замечания или задают вопросы, ответы на которые в явном виде отражены в описании.

Но - они весьма квалифицированы, нередко отвечают на письма и умеют выслушать собеседника. То есть если вы говорите дело - вам чаще всего пойдут навстречу.

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

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

А модераторы в художественной области совершенно некомпетентны, причем некомпетентны принципиально. "На вкус и цвет товарищей нет" - говорят они и с легким сердцем пропускают на трекер еще три разных типоразмера одного фильма с пятой по счету альтернативной озвучкой. Вместо того, чтобы попросить релизера выложить эту озвучку отдельно. И их нимало не заботит, что самая свежая (и следовательно, самая лучшая по мнению наивных пользователей) раздача оказалась на деле самой худшей. Увы.

Рейтинг - 4.

4. tfile.ru
Здесь к оформлению релизов относятся более трепетно, причем настолько, что модераторы иной раз сами правят описания.

На личные сообщения пользователей отвечают далеко не всегда.

Чистка сайта от устаревших релизов также оставляет желать лучшего.

На трекере есть один нюанс. Оформив раздачу, сразу нажмите на кнопку "список файлов". В некоторых случаях вместо упомянутого списка выдается сообщение "Ошибка. торрент не найден". Дело в том, что парсинг торрент-файла реализован здесь некорректно. Если это произошло - попробуйте перегенирировать торрент-файл другой программой. В частности, у меня торренты, изготовленные TorrentBuilder, имели эту проблему, а изготовленные BitTorrent - нет. Администрация заинтересованности в диагностировании и устранении ошибки не проявляет.

Рейтинг - 3,5.

5. kinozal.tv
Здесь принята многоуровневая система проверки релизов. Сначала вы попадаете в руки Менеджера, если он пропустит раздачу - ее утверждает Редактор; в сложных (по мнению Кинозал.ТВ) случаях за дело берется Совет Редакторов. Вона как!

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

Правила трекера сложны и запутаны, а у основной массы персонала не хватает квалификации для их адекватной трактовки.

С Редакторами дело обстоит несколько лучше, но ненамного. Половина из них ничем не отличается от Менеджеров. Вторая половина технически подкована не очень, но с ними можно хотя бы общаться. И только один Редактор, с которым мне пришлось встретиться, действительно хорошо разбирался в вопросах кодирования видео.

В общем, крайне не рекомендую вам соваться на Кинозал.ТВ без опыта оформления раздач на более вменяемых площадках. Или наоборот: после общения с данным ресурсом вы неминуемо превратитесь в закаленного бойца, которому сам черт - не брат.

Рейтинг - 2.


Добро пожаловать в мой литературный проект - роман «Постоянная времени»

 

WebMoney: R026331706659, Z515208365202    Яндекс.Деньги: 410013832498972



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


Комментариев нет: