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

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

Сжатие "без потерь": сравнительное тестирование 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"





DVD Russian VJ's Vol 2

russian vj Человек не может жить без музыки. И в то же время музыка становится только началом некой цепочки, к которой тянутся люди в свободные часы и во время самых радостных праздников.

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

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

подробнее

DVD Russian VJ's vol 1

russian vj  Вы когда-нибудь задумывались о том, что за странные и, в то же время завораживающие, картинки двигаются на экранах в клубе на уютной вечеринке или на многотысячном фестивале, на краю земли?

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

Кто следит за тем, чтобы ваши глаза впитывали музыку с экранов?

подробнее

Яндекс.Метрика Copyright by www.Malbred.com 2005