В данном тесте будет сжиматься DVD-ролик (MPEG2) в DivX формат. Чем быстрее происходит компрессия, тем лучше.
Автор:
Разместил: Amro   Дата: 2006-03-18 10:27
Комментарии: (0)   Рейтинг:

Сравнение UNIX и Windows посредством компрессии DVD-ролика в DivX

В данном тесте будет сжиматься DVD-ролик (MPEG2) в DivX формат. Чем быстрее происходит компрессия, тем лучше. Для лучшего понимания теста нужно знать следующие термины:

  • компрессия (compress) - процесс предоставления информации в другом более компактном виде.
  • фрейм (frame) - один кадр изображения.
  • изображение (image) - набор точек, имеющие цвет и позицию.
  • FourCC - 4 байта в видеофайле, показывающие кодек, которым был сжат фильм. Видеоплейер должен считать FourCC и вызвать необходимый декомпрессор (если он есть в системе).

Например,

FourCC  Описание           Владелец  
DIV6    DivX ;-)           MS MPEG-4 v3 
DIVX    DivX 4 (OpenDivX)  Project Mayo 
DX50    DivX 5.0           divx.com 
XVID    XviD               xvid.org (open source) 

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

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

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

  • Файл под каждой операционной системой будет сжиматься в 2 формата:
      1. DivX 5.1
      2. DivX ;) Low-Motion
  • При сжатии - обрезки черных областей НЕ будет. Фильм как шел с размером 720x480, таким и останется после компрессии.
  • Файл, который будет сжиматься, представляет собой DVD-ролик (MPEG2) с расширением vob. Ролик с диска Lilo&Stitch2 является рекламным и предназначен для показа по телевизору, записан в черезстрочном виде (NTSC 29,97 fps). Нам это добавит только проблем, но об этом позже.
  • Размер файла 91,4 Mb (95 924 224 byte). Количество фреймов - 3682.
  • Конфигурация моего тестового компьютера - AthlonXP 1700+/256 Mb/GeForce2 MX400 64Mb/80Gb Seagate Barracuda/SB Audigy
  • Драйвер NVidia для Windows XP - ForceWare 52.16 WHQL и DirectX 9.0
  • Драйвер NVidia для Linux - NVRM version: NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4363
  • Компрессировать ролик под Windows будет Xmpeg 5.0.3 (build 5.0.8.84) http://www.mp3guest.com/
  • Компрессировать ролик под ASPLinux 9.0 будет MEncoder 0.90rc5-3.2.2 http://www.mplayerhq.hu/
  • Звуковая дорожка будет сохранена как есть в формате AC3 5.1
  • Пакет K-Lite Codecs содержит кодеки следущих версий

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

  • Xmpeg - графическая программа (GUI), а MEncoder - консольная (CLI). Для Xmpeg убраны галочки, которые выводят графики и текущий обрабатываемый фрейм. То есть с помощью Xmpeg мы только графически сделали настройки.
  • Сохранить оригинальную дорожку AC3 в программах под Windows таких как Xmpeg и Flask не представляется возможным, происходит преобразование в PCM. Но можно скинуть дорожку в виде отдельного файла AC3. А затем склеить с сжатым фильмом за несколько секунд в Nandub. Так советуют поступать многие профессионалы, так как оригинальную дорожку можно преобразовать в любой другой формат, и при проблемах со звуком - колдовать над звуковой дорожкой отдельно. Поэтому под Windows AC3 дорожка будет скинута в отдельный файл, а под Linux - склеяна с фильмом во время компрессии видео. Я думаю так будет честнее, чем заставлять Xmpeg преобразовывать в PCM.
  • Для Xmpeg были пройдены тесты, и поставлена галочка "Самый быстрый" - чтобы Xmpeg сам выбрал лучший.
    Для MEncoder тестов нет, но при компиляции он был "заточен" под мою машину.
      Вот что MEncoder выдал до компрессии
      CPU: Advanced Micro Devices (Family: 6, Stepping: 1)
      Detected cache-line size is 64 bytes
      CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1  SSE2: 0
      
    То есть программы будут использовать компьютер по максимуму, по крайней мере они так заявили ;)
  • И самое страшное в чем я должен признаться.
        mpeg4 - ISO standard MPEG-4 (DivX 5, XVID compatible) 
        msmpeg4 - pre-standard MPEG-4 variant by MS, v3 (aka DivX3)
        
      Вроде можно считать, что параметр mpeg4 равен DivX 5, а msmpeg4 равен "DivX ;-) MPEG-4 Low-Motion" (aka DivX3), НО ...

      Программа GSpot(из пакета кодеков K-Lite Codec Pack) так и сказала про сладкую парочку msmpeg4 и "DivX ;-) MPEG-4 Low-Motion".

      msmpeg4                       FourCC=DIV3 и Name="DivX 3 Low-Motion"  
      "DivX ;-) MPEG-4 Low-Motion"  FourCC=DIV3 и Name="DivX 3 Low-Motion"
      

      НО с парочкой "DivX Pro(tm) 5.1 Codec" и mpeg4 проблемы. GSpot информировала

      mpeg4                     FourCC=DIVX и Name="DivX 4 (OpenDivX)"  
      "DivX Pro(tm) 5.1 Codec"  FourCC=DX50 и Name=DivX 5.0 
      

      По сведениям GSpot и по здравому смыслу DivX 5 не равен DivX 4. Но прочтите следущее:

      MPEG4, DivX ;-), OpenDivX (DivX4), DivX 5.02, XviD и другие вариации на тему MPEG4
      mpeg4 - ISO standard MPEG-4 (DivX 5, XVID compatible)
      

    Вообщем, я решил провести компрессию, а результаты в случае чего скоррелировать.

Итак, тест по компрессии начался ...

ASPLinux 9.0 (http://www.asplinux.ru/)

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

1 #!/bin/sh
2 clear
3 date>log.txt
4 mencoder test.vob -ovc lavc -lavcopts vcodec=mpeg4 -ofps 24 -vop lavcdeint -oac copy -o stitch.avi >>log.txt
5 date>>log.txt

3 строка засекает начало теста. 5 строка - конец теста.
4 строка вызов mencoder с параметрами:

  • .* --- будем использовать эти кодеки, как лучшие
      .*
  • .* --- будем сжимать в OpenDivX (DivX4) и DivX ;) Low-Motion
      mpeg4 - ISO standard MPEG-4 (DivX 5, XVID compatible)
      msmpeg4 - pre-standard MPEG-4 variant by MS, v3 (aka DivX3)
      
  • .* --- ограничим количество кадров до 24 (29 будут преобразованы к 24)
  • .* --- уберем черезстрочную лесенку в фильме.
  • .* --- не трогаем (не компрессируем) звуковую дорожку AC3
  • .* --- выходной файл назвать stitch.avi

Находим в файле в начале и в конце строчки типа Птн Янв 30 12:07:22 MSK 2004 .
Вычисляем сколько потребовалось времени для компрессии:

msmpeg4 (DivX Low-Motion)

74 секунды

mpeg4 (DivX Pro(tm) 5.1 Codec)

72 секунды


Это часть лога ...

Writing AVI index...
Fixing AVI header...
Video stream: 807,750 kbit/s (100968 bps) size: 15481871 bytes 153,333 secs 4596 frames
Audio stream: 448,000 kbit/s (55999 bps) size: 8585472 bytes 153,312 secs
Птн Янв 30 12:08:35 MSK 2004

Windows XP (http://www.Microsoft.com/)

В Xmpeg настройки видео были сделаны как на картинке

настройки видео в Xmpeg

Галочка "Перестроить прогрессивную развертку" аналогична опции .* в MEncoder.
Иначе фильм был бы таким

NTSC в действии

Аудио настройки свелись к указанию копировать напрямую в файл.
Время в тесте я засекал ручками, точнее глазками ;-). Вызвал окно времени и глядя на него, следил за прогрессом кодирования фильма и секундной стрелкой.

DivX ;-) Low-Motion

240 секунд

DivX Pro(tm) 5.1 Codec

440 секунд


Вообщем, кто не понял, то

График итогового сравнения

Махание кулаками после драки

1. Пробовал в Xmpeg менять "iDCT настройки". Разница +/- 10 сек. Это не серьезно. Для желающих все оспаривать скажу следущее, пока я писал данную статью, фильм кодировался десятки раз и всегда результаты времени поражали своей постоянностью.

2. Если Xmpeg заставить не скидывать звуковую дорожку AC3 в файл, а преобразовывать в PCM и склеивать сразу с фильмом, то время компрессии НЕ изменяется. Наверное, для такого преобразования требуется мало процессорного времени, ведь это не сжатие в формат mp3.

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

4. Одна из философий Linux и UNIX - гласит, будь программа хоть суперграфической у нее должен присутствовать возможность задавать параметры в командной строке. Для кого скорость компрессии это наиважнейший параметр и не испугается разбора командной строки, то рекомендую компрессировать под Linux.
Посмотрите эти математические выкладки, которые я хочу вскоре проверить на практике.

Теория для DivX 5.1

OS

91 Mb

4 556 Mb DVD

Linux

0:01:12

1:01:53

Windows

0:07:20

6:07:57


Теория для DivX Low-Motion

OS

91 Mb

4 556 Mb DVD

Linux

0:01:14

1:01:53

Windows

0:04:00

3:20:42

Согласитесь что разница, ждать 1 час или 3 часа при компрессии с помощью DivX Low-Motion, есть. Разница огромная, но надо это проверить на практике.

Проверил 29.02.2004г результаты на реальном DVD, очень интересные выводы.

Тест закончился с победой MEncoder'a.