AMV News

[Aggressor]

«У вас нет прав на просмотр черновиков.»

[Lirinis]

Тьфу, блин.
http://crossmotions.ru/site/?p=317

[Bill Ein]

Я так и не понял, потому что в кодировании вообще нифига не понимаю, но x264 lossless (qp0) - труъ или всё-таки нет? По графикам более же чем труъ, может кодирование в него в ASG добавить?

[Lirinis]

Bill Ein
1. Этот вариант x264 lossless почему-то не открывается в редакторах. VFW-версия, правда, открывается.
2. Перемотка открывшегося в редакторе работает ооочень медленно.

Так что тру-то тру, но не для редактирования.

[Bill Ein]

Lirinis, а и нафиг для редактирования, суть то для хранения именно, т.е. в АСГ то как раз к месту бы пришлось для одного из вариантов кодировки готового продукта.
Ну и может то что не открывается или тормозит - явление временное и в ЦС 6-7 с этим уже не будет проблем?

[Aggressor]

Когда-то уже нашёлся один уникум, который выкрутил битрейт в АСГ на четыре девятки. А потом пытался налапшать всему форуму (мне в т.ч.), что это АСГ виноват в растолстении 2х-минутного SD-клипа на более чем 100 метров. И техпроверку он прошёл, т.к. Турбо ему поверил. Хорошо, что я тогда уже вкрутил ограничение хоть на 9999, а то бы парниша и 20к мог не постесняться.
Я к чему: нельзя это просто так в АСГ. Чревато. Хотя потенциально полезная фича не только для хранения, но и для обмена материалом в МЭПах или проектах типа Ру.комикса. В общем, я пока подумаю над вариантами.

[Aggressor]

Вот немного инфы с главной страницы оф. сайта Лагарифа:
...Lagarith offers better compression than codecs like Huffyuv, Alparysoft, and CorePNG. There are a few lossless codecs that can compress better than Lagarith, such as MSU and FFV1; however Lagarith tends to be faster than these codecs.
...
The trade-off for this improved compression is speed. On a single processor system, Lagarith can be significantly slower than Huffyuv on typical video. Additionally, the decode speed tends to be slower than the encode speed;
...
For multiple processor systems, Lagarith 1.3.0 can take advantage of additional processors; while Huffyuv cannot. On such systems Lagarith may be faster than Huffyuv.
...
Lagarith was last updated on April 10, 2011.

[Lirinis]

Это ты к чему? Там раньше что-то другое было написано?

[Aggressor]

Во-первых, кое-что, написанное тут прямым текстом, можно было почитать и понять без тестов. Например, что Лаг медленнее Хаффа, но лучше жмёт (кстати, это потому, что написан на основе Хаффа с добавлением нового алгоритма компрессии к существующему).
Во-вторых, пункт про многопоточность, который ты упустил в тестах.
В-третьих, последний апдейт всего несколько дней назад, включающий оптимизацию и багфиксы => проект развивается.
И самое главное, в твоих тестах у тебя Хафф из ffdshow каким-то чудом поддерживает RGB, хотя такой функции у него в жизни не было.

[Lirinis]

[Aggressor]

[brdm-69]

[vivan]

Если кому интересно...
SSD (350 мбайт на чтение/запись) + i7 970.
Декодирование:
Лагариф - 26.9 фпс
UT Video (size) - 85.8 фпс
В обоих случаях поток ~400 Мбит (1920x1080@60 fps), так что даже на HDD в диск не должно упираться, по идее.
Вывод - если в системе больше 2х ядер - лучше UT Video Мб стоит в инструкцию по нарезке добавить?

И если интересна ситуация когда в диск не упирается (в конце концов можно и Ramdisk заюзать) - могу что-нибудь еще потестить.

brdm-69,
дело скорее не в скорости, а в задержках при случайном (по крайней мере не линейном) чтении/записи. Если читать и писать с одного диска - то головка будет метаться туда-сюда, вместо быстрой линейной записи.

[trampler]

Ого, надо бы всё таки потестить этот UT.

[brdm-69]

vivan

[vivan]

Оу, на запись 220. И по производителю, и по бенчмаркам на обзорных сайтах и по своим бенчмаркам Но последнее поколение дисков еще быстрее (415/260).
Живет полгода. Конечно про подобную проблему слышал, но она вроде бы решена в новых контроллерах. Ну по крайней мере пока скорость такая же какая и была.

[vivan]

Погонял x264 lossless в интра режиме.

7143 кадров в 1080p видео. Скорость мерил таймкодеком, dfps.
Все видео кодировалось с исходника. UT оптимизировал на сжатие.

AVC_source (287 MB):
ffdshow -> null - 398.9

Lagarith (5 121 MB, encode - 122s)
ffdshow -> null - 24.6
AVI Decompressor -> null - 28.9

UT Video (5 494 MB, 104s)
ffdshow -> null - 59.6
AVI Decompressor -> null - 87.1

AVC lossless veryfast fastdecode (5 389 MB, 70s)
--crf 0.0 --preset veryfast --keyint 1 --tune fastdecode
ffdshow -> null - 206.5

AVC lossless veryfast (4 736 MB, 122s)
--crf 0.0 --preset veryfast --keyint 1
ffdshow -> null - 93.8

AVC lossless veryslow fastdecode (5 121 MB, 202s)
--crf 0.0 --preset veryslow --keyint 1 --tune fastdecode
ffdshow -> null - 209.2

AVC lossless veryslow (4 681 MB, 303s)
--crf 0.0 --preset veryslow --keyint 1
ffdshow -> null - 95.4

Вывод - по скорости декодирования при --tune fastdecode avc рулит.
Правда есть один косяк - редакторы этот профиль AVC (High 4:4:4 Predictive) не поддерживают xDDD
Возможно этот косяк можно исправить с помощью avi-пустышек, но у меня не получилось (в мпц и дабе с ними все ок - а вегас ругается на неподдерживаемый формат) - то ли кривизна рук слишком большая, то ли вегас слишком умный.

UPD: поборол кривизну рук (ступил, нужен же еще 64 битные ffdshow и ависинт) - теперь в вегасе все ок.

Также еще пара вариантов c keyint 3. Т.к. в аниме 2-3 соседних кадра обычно имеют невероятно много общего - это позволяет сжать еще раза в 2.

AVC lossless veryslow (2 433 MB, 239s)
--crf 0.0 --preset veryslow --keyint 3
ffdshow -> null - 116.7

AVC lossless veryslow fastdecode (2 797 MB, 183s)
--crf 0.0 --preset veryslow --keyint 3 --tune fastdecode
ffdshow -> null - 260.2

Даже с первым вариантом 60 фпс летают в редакторе, а seeking такой же быстрый как и с UT.

Вывод: если пользоваться авц - то можно сжать видео в 2 раза сильнее + будет в целом быстрее работать. А если использовать fastdecode - до будет вообще летать на раритетных компьютерах ценой 15% прироста размера файла.

Думаю это объяняется тем, что:
x264 значительно "навороченнее" всех остальных кодеков вместе взятых. Использование всего 2х p/b кадров между ключевыми дает сжатие в 2 раза (для аниме). Также он полностью оптимизирован под современное железо - поэтому даже в самых тяжелых режимах отставание по скорости кодирования не такое огромное.
ffdshow также очень хорошо оптимизирован (а например лагариф вообще только 2 ядра использует). Да и сам стандарт AVC тоже оптимизирован (чего стоит один модифицированный DCT, который вместо кучи матана использует целочисленную арифметику - битовые сдвиги, сложения и вычитания)...

[vivan]

В общем погонял еще немного, потом еще превратив комп в слоупока (отрубил 4 из 6 ядер, частоту снизил до 2Ггц).
UT Video все равно быстрее. К примеру на 2х 2Ггц ядрах 60 фпс 1080p видео весьма неплохо игралось (позиционирование моментальное, воспроизведение на глаз ~фпс 40). Лагариф безбожно тормозил, при декодировании так вообще... Точно также вел себя avc без fastdecode. Но с fastdecode - что-то среднее между лагарифом и UT, ближе к UT.

А теперь цифры, которые ничего не значат (разве что размеры файлов полезны)...

1080p, 4473 кадров. Выбрал самые динамичные 4 минуты (поэтому x264 находится в худших возможных условиях).
Рендер - это я разрезал видео на 20 случайных кусков и перемешал их (чтобы ухудшить положение avc, которому нужно не ключевые кадры декодировать). Ну и разрешение самого рендера было низкое, в анкомп, и в рам (ramdisk) - чтобы минимизировать энкод (тестируется же декодирование).

Source (293 MB)
ffdshow -> null 302.5
makeAVIS -> AVI Decompressor -> null 285.9
Render 0:18

UT Video (4 107 MB, 1:20)
AVI Decompressor -> null 87.6
makeAVIS -> AVI Decompressor -> null 291.7
Render (makeAVIS) 0:16
Render 0:22

Lagarith (3 917 MB, 1:24)
AVI Decompressor -> null 26.6
makeAVIS -> AVI Decompressor -> null 31.8
Render 0:59

AVC_veryslow_keyint1 (3 883 MB, 4:18)
--crf 0.0 --preset veryslow --keyint 1
ffdshow -> null 71.7
makeAVIS -> AVI Decompressor -> null 69.8
Render 0:30

AVC_veryslow_keyint2 (2 914 MB, 4:18)
--crf 0.0 --preset veryslow --keyint 2
ffdshow -> null 72.7
makeAVIS -> AVI Decompressor -> null 77.9
Render 00:28

AVC_veryslow_keyint3 (2 570 MB, 4:38)
--crf 0.0 --preset veryslow --keyint 3
ffdshow -> null 86.7
makeAVIS -> AVI Decompressor -> null 83.9
Render 00:34

AVC_veryslow_keyint4 (2 393 MB, 4:38)
--crf 0.0 --preset veryslow --keyint 4
ffdshow -> null 80.5
makeAVIS -> AVI Decompressor -> null 85.9
Render 00:40

AVC_veryslow_keyint1_fastdecode (4 319 MB, 2:38)
--crf 0.0 --preset veryslow --keyint 1 --tune fastdecode
ffdshow -> null 173.7
makeAVIS -> AVI Decompressor -> null 247.6
Render 0:18

AVC_veryslow_keyint2_fastdecode (3 274 MB, 3:04)
--crf 0.0 --preset veryslow --keyint 2 --tune fastdecode
ffdshow -> null 191.5
makeAVIS -> AVI Decompressor -> null 267.2
Render 00:18

AVC_veryslow_keyint3_fastdecode (2 900 MB, 3:16)
--crf 0.0 --preset veryslow --keyint 3 --tune fastdecode
ffdshow -> null 202.1
makeAVIS -> AVI Decompressor -> null 274.9
Render 0:18

AVC_veryslow_keyint4_fastdecode (2 708 MB, 3:32)
--crf 0.0 --preset veryslow --keyint 4 --tune fastdecode
ffdshow -> null 200.4
makeAVIS -> AVI Decompressor -> null 271.8
Render 0:17