Сжатие без потерь
Сжатие "без потерь": сравнительное тестирование 13 lossless-кодеков с разными настройками в различных цветовых форматах
При частой/постоянной работе с видео нередка одна из ситуаций, в которой мы сталкиваемся либо с нехваткой места на диске, либо с тем, что, имея мощный процессор для кодирования, видим, что процесс сжатия упирается в "бутылочное горлышко", а именно в скорость отдачи видеопотока винчестером (в качестве примера, - обычный поток 720х576 4:2:2 - 160 Мбит/с, казалось бы, по формальным характеристикам не превышает скорости передачи данных ATA-дисков, на практике же получается торможение, причем весьма заметное). Понятно, что вторая проблема частично или полностью обходится установкой простейшего RAID, но далеко не все имеют подобную возможность. И обе проблемы можно попытаться обойти при помощи использования "сжатия без потерь" - мы одновременно уменьшаем и место, необходимое для хранения видео, и снижаем поток данных, запрашиваемых с жесткого диска.
Lossless-кодеки (или же lossless-режимы некоторых кодеков) - особая подгруппа энкодеров видеопотока, позволяющая сократить объем занимаемый видео на жестком диске, но при этом сохранить всю видеоинформацию без потерь в определенном (YUV или RGB) цветовом формате. Последняя оговорка весьма важна для понимания того, что большинство lossless-кодеков работают в режимах YUY2 (4:2:2) или YV12 (4:2:0), поэтому, если Вы не хотите потерь цвета, внимательно проверьте цветовой формат видео на входе и установки lossless-кодека при сжатии.
Следует добавить, однако, что если Вы собираетесь хранить свои материалы на DVD или в MPEG4-подобном формате (xVid, DivX, WMV9, VP6/7, h.263, h.264, все форматы для мобильных устройств), то YV12, возможно, более предпочтителен, т.к. при сохранении материала в эти форматы поток все равно будет преобразован в YV12. Поэтому при захвате и обработке видео лучше сразу выбирать YV12. (При отсутствии такого режима захвата в тюнере/карте захвата попробуйте найти подходящие драйверы, - например, для чипов Philips SAA713x YV12 есть в версии драйвера от Beholder или же в референсном драйвере.) При этом будет экономиться дисковое пространство при захвате или при архивном хранении материала (видеопоток в формате YV12 занимает в несжатом состоянии на 25% меньше места по сравнению с несжатым YUY2 - выигрыш даже в этом).
Данный материал рассматривает характеристики ряда lossless-кодеков, доступных в сети, по параметрам, интересным для применения, а именно: степени сжатия и нагрузке на CPU при кодировании/декодировании (буквально: скорости, выраженной в частоте кадров).
Тесты проходили на системе с установленным Intel Pentium IV 3.5 ГГц, запись и чтение производились с разных физических устройств.
Сжатие в YV12
Нижеприведенная таблица демонстрирует результаты, полученные при сжатии минутного фрагмента (источник - эфир, захват на ТВ-тюнере, качество - субъективно хорошее, формат - чересстрочный YV12). Таблица отсортирована так, что сверху располагаются кодеки, давшие лучшее сжатие, снизу - худшее. Изначальный размер видеофрагмента - 933 165 056 байтов.
|
Кодек
|
Размер сжатого потока
|
Время кодирования
|
Декодирование, fps
|
|
SNOW
|
394 803 200
|
4:41
|
11
|
|
FFV1
|
396 853 248
|
0:55
|
25
|
|
MSU Lossless Video Codec v0.6.0-balanced
|
409 339 904
|
4:54
|
10.4
|
|
MSU Lossless Video Codec v0.6.0-Fast
|
409 409 536
|
2:37
|
10.41
|
|
Lagarith
|
416 184 320
|
0:44
|
38.38
|
|
x264
|
436 954 979
|
5:06
|
15.9
|
|
CorePNG VFW Codec v0.8.2 best
|
438 734 848
|
13:18
|
56.02
|
|
huffyuvadapt
|
450 869 248
|
0:31
|
65.83
|
|
Alparysoft Lossless Codec Max
|
456 022 016
|
3:21
|
27.59
|
|
Ljpeg
|
496 582 656
|
0:36
|
48.7
|
|
CorePNG VFW Codec v0.8.2 fast
|
502 091 776
|
2:25
|
|
|
Morgan Multimedia M-JPEG2000 V2
|
504 766 464
|
3:16
|
9.63
|
|
Alparysoft Lossless Codec Fast
|
541 724 672
|
0:34
|
|
|
Arithyuv (YUY2)
|
549 120 000
|
0:28
|
15.46
|
|
LZOCodec v0.3 (Gzip-9)
|
554 835 968
|
4:52
|
6.38
|
|
huffyuv
|
559 773 696
|
0:31
|
58.88
|
|
LZOCodec v0.3 (LZOC)
|
901 007 360
|
1:09
|
29.55
|
Что можно сказать, глядя на результат? Ну, выбирать кодек-победитель для сжатия не в тесных временных рамках каждый должен сам - по степени сжатия или по оптимальному соотношению степень сжатия/скорость. А вот про применение кодеков из таблицы для сжатия при захвате следует сказать, что те из них, что показали время больше минуты, непригодны, и FFV1, который на минутное видео потратил 55 секунд тоже под вопросом - проверьте его вначале, вдруг Ваша система не окажется столь быстрой для него. Также отмечу "призом за волю к победе" Arithyuv - работая в формате YUY2 (!), он, конечно, проиграл - но не всухую!
Сжатие в YUY2
Целесообразность использования данного формата может проявлять себя только в том случае, если исходное видео у Вас имеет цветовую размерность не хуже 4:2:2 и оно более или менее приличного качества. Во всех остальных случаях - не ломайте голову и смело используйте YV12.
В таблице чуть ниже приведены результаты, полученные при сжатии другого минутного фрагмента (источник - RAW YUY2). Таблица отсортирована так, что сверху располагаются кодеки, давшие лучшее сжатие, снизу - худшее. Изначальный размер видеофрагмента - 1 244 205 056 байтов.
|
Кодек
|
Размер сжатого потока
|
Время кодирования
|
|
FFV1
|
490 870 784
|
1:15
|
|
MSU Lossless Video Codec v0.6.0-Fast
|
492 859 392
|
3:15
|
|
Lagarith
|
521 379 840
|
0:52
|
|
Alparysoft Lossless Codec Max
|
532 965 376
|
4:21
|
|
Arithyuv
|
537 458 688
|
0:28
|
|
huffyuvadapt
|
566 771 712
|
0:36
|
|
LZOCodec v0.3 (Gzip-9)
|
615 905 280
|
5:08
|
|
Morgan Multimedia M-JPEG2000 V2
|
616 921 088
|
4:09
|
|
CorePNG VFW Codec v0.8.2 fast
|
638 289 920
|
3:07
|
|
huffyuv
|
720 355 328
|
0:36
|
|
LZOCodec v0.3 (LZOC)
|
1 044 928 512
|
1:19
|
Выводы, используя уже сказанное нами, Вы легко сделаете сами!
Lossless и двух-ядерные процессоры
Протестировав 13 кодеков на степень сжатия и быстродействие, мы решили проверить, увеличится ли их производительность при работе на двух-ядерных процессорах. Для этого был проведен тест по сжатию видео всеми вышеуказанными кодеками на системе с установленным AMD Athlon64 4200+ DualCore: сравнивалась производительность работы с двумя разрешенными ядрами и одним. Увы, чуда не произошло: 11 из 13 кодеков практически не увеличили скорости работы - небольшое увеличение, конечно, имело место, но за счет переноса нагрузки системы по чтению/записи на второе ядро, в то время, как первое занималось сжатием потока.
Лишь два кодека на данный момент поддерживают мультипоточное кодирование. Это - Lagarith, в который подобный функционал заранее заложен разработчиками. Как показали эксперименты, скорость кодирования, в зависимости от видеопотока и дисковой подсистемы, увеличивалась в 1.5 - 1.8 раза. Что ж, поставим плюс этому кодеку :)
Второй кодек, также поддерживающий мультпроцессорные конфигурации, это x264 losless, который показал чуть худшие, нежели Lagarith, результаты. На тестовой системе скорость кодирования возрастала в 1.3 - 1.7 раза. Тоже плюс! :)
Что касается ближайшего будущего, то можно ожидать появления стабильной версии ffdshow (включающей кодеки SNOW, FFV1, huffyuvadapt, huffyuv и Ljpeg), которая будет использовать многопотоковое кодирование. Тогда мы проверим указанные кодеки еще раз.
В связи с доступностью двухпроцессорных систем возникает вполне понятный вопрос - а нужно ли вообще, в таком случае, сжатие видео "без потерь"? Ведь на двухпроцессорной системе мы достаточно просто "посадим" на один процессор фрейм-сервер, который будет выполнять обработку видео на лету (например, AVISynth), а на втором процессоре у нас будет происходить финальное сжатие (в MPEG-2 для DVD, в MPEG-4 или во что угодно). И нет нужды каждый раз изыскивать свободное место на дисках:
Что тут сказать. Раньше на этот вопрос ответить было достаточно просто: используя сжатие без потерь после обработки видео (очистка, преобразование, подготовка к кодированию) до финального сжатия, мы зачастую экономили время - ведь большинство кодеков и энкодеров, используемых нами для подготовки финального потока, применяют двух- или мульти- проходные методики, т.е. каждый раз, встраивая в цепочку обработки фрейм-сервер, мы сильно увеличивали время финального сжатия. А если финальный вариант должен быть в нескольких форматах, то тут вообще обработка могла вестись сутками. Поэтому запись подготовленного видеопотока в формат без сжатия экономил массу времени.
Сейчас так просто, увы, не ответишь - ведь, если энкодер для финального сжатия использует только одно ядро процессора (яркий пример - Canopus Procoder 1.5), то второе простаивает, и на него вполне можно повесить фрейм-сервер. В общем, каждый выберет сам - приведем лишь доводы в пользу lossless-сжатия: во-первых, проекты, как правило, лежат несколько недель "на всякий случай", во-вторых, параллельно со сжатием можно заняться другой работой (часть второго ядра- то простаивает :) ), в третьих , а зачем еще нужны терабайтные RAID'ы? :)
Надеемся, что помогли Вам в нелегком выборе кодека - безопасного для Вашего видео и Вашего свободного места на винчестерах. И очень рады, если слегка взбаламутили вопросом "а нужно ли это?" - если так, приходите, вспомним старые споры "lossless-сжатие vs frame-server"
