Обработка видео

Сжатие без потерь

Сжатие "без потерь": сравнительное тестирование 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"
Яндекс.Метрика Copyright by www.Malbred.com 2005