Lehmen comments: На самом деле, кодирование в реальном времени возможно, если не сильно (или совсем не) заботит качество выходного материала. Чего на практике не происходит при кодировании именно DVD в Divx. Кроме совершенно жуткого качества изображения, использование методик, описанных в данной статье, совсем не гарантирует отсутствие проблем со звуком. Поэтому данная статья представляет интерес (и не малый) только как сравнение процессоров и кодеков, с точки зрения оптимизации одного под другое. Использовать её как руководство к действию при кодировании видео нельзя.
Lehmen comments: не советую использовать Flask для кодирования. В своё время это была замечательная программа, но сейчас появились гораздо лучшие методы, которые дают качество выходного материала, недостижимое для Flask и ему подобных программ. Некоторые из них уже описаны мной на 3DNews.
Lehmen comments: И это не может не радовать. Хотя, я бы не был так оптимистичен. Дело в том, что ещё попадаются программы, которые, обнаруживая процессор от AMD, даже не пытаются использовать SSE, несмотря на то, что Athlon XP его поддерживает. К счастью, с выходом различных патчей и новых версий таких программ становится всё меньше.
К тому же, после выпуска DivX 4.11 ситуация с программным обеспечением изменилась. Кроме появления кодеков, оптимизированных под SSE (типа DivX 4.11), появилась еще одна революционная функция - использование цветового пространства YUV вместо старого RGB, что заметно ускоряет преобразование DVD/MPEG-2 в MPEG-4. Давайте попытаемся найти причину.
Lehmen comments: На самом деле использовать YUV2 можно было достаточно давно, даже с Divx 3.11 кодеком (естественно, при использовании "правильного" программного обеспечения), так что до революции здесь далеко...
Нас разочаровало меню настроек нового DivX 4.11. Оно выглядит точно так же, как и в версии 4.02, которую мы до этого использовали. Однако движок в 4.11 в корне отличается. Впрочем, показанные на иллюстрации настройки - это именно те настройки, с которыми мы и производили тестирование. Обратите внимание на то, что параметр "performance/quality" (производительность/качество) установлен в "slowest" (медленное) позицию. Таким образом, мы получаем высококачественную картинку, в зависимости от установленного потока. Все наши последующие комментарии в тестировании относятся именно к режиму "slowest". Установка в положение "fastest" (быстрое) автоматически увеличит частоту кадров. Но все же, мы отражаем подход большинства пользователей, предпочитающих качество скорости.
Lehmen comments: Движок и кодек - вещи не одинаковые, и разочарование здесь выглядит достаточно странно. Насколько мне известно, изменения и оптимизация в новом кодеке коснулись, в основном, того КАК делается, но ЧТО делается осталось прежним. Хотя, если бы в кодек добавили настроек, я бы не огорчился ;-)
Насчёт "высококачественной" картинки, которую можно получить при битрейте 780 и размере кадра в 720*576 (как они кодили) я промолчу. На tomshardware работают либо очень непритязательные люди, либо они сами не смотрели, что у них получилось. Либо я - китайский лётчик :-)
Когда мы начали искать альтернативный инструмент преобразования в MPEG-4, наше внимание привлек DVD2AVI. Первоначально нас поразила его стабильность. Даже VOB файлы или MPEG-2 файлы со случайными ошибками изображения обрабатывались DVD2AVI без всяких проблем. Мы также были приятно удивлены скоростью преобразования по сравнению со старым FlaskMPEG 0.6. Но самой хорошей чертой стала возможность переключения в цветовое пространство YUV. При ее задействовании программа стала просто "летать".
Пришло время добавить ложку дегтя. Версия 1.76 не умеет одновременно преобразовывать звук в MP3 параллельно с видеопотоком. Вместо этого, программа оснащена простейшей функцией демультиплексирования. Если вы пожелаете соединить видео и аудио, вам придется воспользоваться еще одной программой, к примеру, VirtualDub. DVD2AVI обладает еще одним существенным минусом: кривым преобразованием масштаба кадра (к примеру, при переходе от 4:3 к 16:9). Некоторые DVD в формате 16:9 вообще показываются как 4:3. Такое преобразование приводит к эффекту кривого зеркала, точнее, к "длинным лицам" (позднее мы более подробно остановимся на этом).
Lehmen comments: DVD2AVI замечательная программа, которая великолепно работает в качестве frame server'а. И то что она не растягивает анаморфное изображение (что у Тома называется кривым преобразованием, что неправильно, потому что вся "фишка" в том, что никакого преобразования нет и в помине) - огромный плюс. Это даёт возможность в процессе дальнейшего кодирования использовать для преобразования сколь угодно продвинутый и качественный метод.
Такие преобразования слишком сложны для обычного пользователя, который предпочитает все делать за один прием. По дружественному пользователю интерфейсу, FlaskMPEG - безусловный лидер.
Lehmen comments: Полностью согласен. Но настоятельно не рекомендую делать всё за один приём, если вас заботит то, как будет выглядеть и звучать результат.
Сейчас по Интернету распространяется взломанная версия DVD2AVI 1.82. В нее уже встроен MP3 компрессор для аудио. Однако, судя по нашему опыту, эта версия нестабильна, поэтому вряд ли стоит ее использовать.
Lehmen comments: Более того, в "взломаной" версии изменён формат проектов создаваемых DVD2AVI, что делает её использование уж совсем бесмысленным.
Lehmen comments: Кроме выигрыша в скорости, использование YUV цветов даёт более правильную цветовую гамму (и, соответственно, качество) итогового материала что, на мой взгляд, гораздо важнее. Начёт "старого" стандарта, который не якобы не работает с YUV, у Toma несколько погорячились, это не совсем так ;-)
Опция YUV2 указывает на революционные изменения в XMPEG 4.2a. Как только вы ее включаете, она значительно увеличивает скорость кодирования DVD. Похоже, сейчас мы увидим возрождение многих популярных продуктов благодаря массовому проникновению YUV.
Еще одной приятной возможностью является поддержка различных форматов кадра. Кроме стандартных форматов 4:3 и 16:9, пользователь может выбирать и специальные. Некоторые DVD и MPEG-2 видео используют необычные форматы кадра, что иногда приводит к эффекту "длинных лиц". Все это можно скорректировать в XMPEG 4.2a.
Довольно полезны и функции обрезки/конверта (cropping/letterboxing). Они позволяют вам легко обрезать изображение и убрать ненужные черные края. Лучший способ посмотреть на результат - обратиться к панели предварительного просмотра.
Французские программисты за основу взяли интерфейс DVD2AVI-MMX, который используется во многих программах. Но пусть суффикс MMX не вводит вас в заблуждение. Кодек DivX 4.11 оптимизирован, главным образом, для использования с SSE - "DVD2AVI MMX" просто его название в программе.
Lehmen comments: Всё выше написанное конечно же правда, но я не думаю, что это движение в правильном направлении. Скорее, это путь в тупик. Поезд, на котором едут нормальные кодировщики, давно свернул в другую сторону, и если вы хотите на него попасть, вам придётся забыть про методику, описанную выше. Эта информация представляет собой интерес только в том, по какой методике тестировались процессоры, но ничего более.
Как вы понимаете, за сжатие отвечает как кодек, так и утилита.
Lehmen comments: За само сжатие отвечает только кодек, утилита отвечает за то, в каком виде видеопоток будет "доставлен" к кодеку (обрезание краёв, изменение размера, изменение пропорций, и т. д.)
| Тестовая система на базе Windows XP | |||||||
| Аппаратное обеспечение | |||||||
| Процессоры | Athlon XP 1900+ (1600/133 МГц FSB) Athlon XP 2000+ (1666/133 МГц FSB разгон) |
Socket 423: Intel Pentium 4 2,0 ГГц | |||||
| Материнские платы | EPOX EP-8KHA+ (VIA KT266A) | Socket 423: ASUS P4T-E (Intel 850) | |||||
| Память | Socket 478: 256 Мб, PC800, 400 МГц, Viking Socket 462: 256 Мб, PC2100, 133 МГц, CL2.0, Micron |
||||||
| Жесткий диск | 40 Гб, 5T040H4, Maxtor UDMA100, 7200 об/мин, 2 Мб кэш | ||||||
| Видеокарта | NVIDIA GeForce3 64 Мб DDR 400/250 | ||||||
| Звуковая карта | Createive Soundblaster Live 5.1 | ||||||
| Программное обеспечение | |||||||
| Операционная система | Windows XP Professional, DirectX 8.1, VIA 4-in-1 v4.35 | ||||||
| Видеодрайверы | NVIDIA Detonator 4 v21.88 | ||||||
В старом DivX 4.02 Athlon XP показал лучший результат. Однако с новым DivX 4.11 Pentium 4/2000 вышел на первое место.
Выпустив модифицированную версию FlaskMPEG 0.6, Intel доказала что процесс сжатия в MPEG4 можно еще улучшить. Владельцам Athlon XP использовать эту версию противопоказано, так как на процессорах AMD она работает только медленнее. Старый FlaskMPEG 0.6 благополучно справился с преобразованием в цветовое пространство RGB, поскольку YUV ему не по зубам. Все указанные опции относятся только к видео - мы отключили кодирование звука. Без звука, Intel смогла преодолеть порог реального времени 25 fps (PAL - Европа, Азия). Если бы мы использовали NTSC видео (Северная Америка), Pentium 4/2000 так же хорошо с ним бы справился. Давайте посмотрим повнимательнее на различия между PAL и NTSC.
*пиксельный поток PAL: 720x576 пикселей x 25 fps = 10,4 Мпиксель/сВ одинаковом цветовом пространстве пиксельный поток прямо пропорционален битовому потоку, таким образом, получается отсутствие разницы между PAL или NTSC. Если процессор смог взять барьер реального времени в PAL, то он сможет сделать то же самое и в NTSC. Пожалуйста смотрите на формат видео в каждой тестовой диаграмме.
*пиксельный поток NTSC: 720x480 пикселей x 30 fps = 10,4 Мпиксель/с
Примечание: вообще-то точная частота кадров в NTSC на самом деле 29,97 fps, но мы взяли приближенное значение.
Lehmen comments: Вообще-то при работе с NTSC материалом следует "возвращать" (это называется IVTC) его в оригинальные 24 кадра (на самом деле 23.976), в которых он и снимался на киноплёнку.
При использовании версии DivX 4.02, Pentium 4/2000 не смог угнаться за Athlon XP 1900+/2000+. Но DivX 4.11 изменил ситуацию. Без обработки аудиопотока, все процессоры смогли взять барьер реального времени (30 fps для NTSC) в цветовом пространстве YUV. Причем улучшение здесь заметно не только для Pentium 4/2000, но и для Athlon XP.
В тестировании мы использовали еще один фильм. Мы взяли отрывок с погоней BMW из фильма про Джеймса Бонда. Такой отрывок критичен к пропускной способности. Обратите внимание - формат фильма PAL, где порог реального времени - 25 fps. Как видим, с 4.11 версией DivX улучшились результаты и Athlon XP, и Pentium 4. И вновь Pentium 4 вышел на первое место.
Феноменально! Даже при самом сложном преобразовании 5-канального звука Dolby Digital и MPEG-2 потока, Pentium 4/2000 смог взять порог реального времени. Однако следует заметить, что Athlon XP 1900+ и 2000+ (эта модель вскоре будет выпущена) дышат Pentium 4 в затылок. Владельцы Athlon XP также получат преимущество от нового кодека DivX 4.11.
Ранее почти неизвестное, цветовое пространство YUV, наконец, стало использоваться в программах. Его предшественник, пространство RGB, никогда не давало такой частоты кадров как YUV. Владельцы Athlon XP могут "на халяву" воспользоваться плодами Intel, оптимизировавшей DivX кодек под SSE. И Athlon XP (Palomino), и новый Duron (Morgan) получают прирост от оптимизации. Маленькое замечание: вы должны использовать последние версии программ, так как наш ветеран FlaskMPEG 0.6, разработанный Альберто Вигатой, уже заслужил почетный отдых.
На сегодняшний момент бесплатная программа Flask XMPEG 4.2a обладает наибольшим потенциалом, и она, к тому же, явно быстрее коммерческих продуктов по копированию DVD.
Lehmen comments: А вот это уже совсем интересно. Что это имелось в виду под коммерческими продуктами по копированию DVD? Это кто же такое дозволил? А как же куча судебных процессов? За что, спрашивается, боролись?? За что кровь проливали??? За что DeCSS погибла так геройски и безвинно (почти)?
Так что если вам нужен инструмент, быстро кодирующий DVD или MPEG-2 в MPEG-4 формат, обратите свое внимание на XMPEG 4.2a.
Lehmen comments: Не надо... в смысле, быстро кодировать. Лучше медленнее, да лучше :-)
Intel доказала, что оптимизация исходного кода под SSE может добавить определенный процент производительности даже в старую FlaskMPEG 0.6. Хорошо бы французские программисты попросили Intel оптимизировать XMPEG 4.2a под SSE.
С другой стороны, разработчики должны быть уверены, что Intel не изменила исходные коды для умышленного "замедления" Athlon XP. Или разработчики должны дать AMD возможность также внести свою лепту. Или каждый производитель процессоров должен разработать свой plug-in, независимо от другого. А уж пусть потом пользователь решает, что ему больше нравится.