LINUX.ORG.RU

В сети появился ускоренный при помощи OpenACC x265

 , , видеокодек


1

2

В сети появился ускоренный при помощи OpenACC видеокодек x265. Скорость (средняя) перекодирования видео в разрешении 1280x720 из 10 bit в 10 bit, на AMD Phenom X3 и видеокарте Nvidia GeForce GT 730 и пресете placebo с тюнингом на максимальные настройки качества и CF=20, составляет 2 fps (2 кадра в секунду), что в 20–50 раз быстрее нативной кодировки силами только одного процессора, не имеющего SIMD выше SSE3.

Собирается только с gcc>=7 и флагам оптимизации выше -O2 и -fopenacc (в линковщике также нужен).

>>> Подробности



Проверено: Pinkbyte ()
Последнее исправление: Pinkbyte (всего исправлений: 4)

2 fps? Вы серьёзно? Вы что, предлагаете ждать неделю, пока перекодируется двухчасовой фильм? Или кластер делать (дорогое удовольствие)?

Dmitry_Sokolowsky ★★★★★
()
Ответ на: комментарий от Dmitry_Sokolowsky

Просто заюзать более дорогую видеокарту с числом унивесальных ядер более 1000. Если следовать линейной зависимости то фильм можно на такой закодировать за сутки . Тем не менее это лучше чем 0,1 fps на medium или чем 0,03 fps на placebo.

vovagubin1987
() автор топика

В сети появился ускоренный при помощи OpenACC видеокодек x265

А как со скоростью декодирования?

Подробности

Кроме комитов нет обзора?

gag ★★★★★
()
Последнее исправление: gag (всего исправлений: 1)
Ответ на: комментарий от Dmitry_Sokolowsky

Не неделю, а сутки. И для пресета placebo это очень быстро (к тому же тут ещё и затычка GT 730 вместо видеокарты, на нормальной ещё быстрее будет). Кодировать один раз, потом смотреть тысячи.

Но в любом случае, там есть и другие пресеты, которые быстрее в разы, даже slow (не slower) и medium, не говоря fast, faster и fastest. Правда то, что автор сабжа приводит пример только placebo (которым на практике обычно не пользуются), намекает, что с каким-нибудь slow всё не так радужно, и ускорение если и есть, то не во столько раз. Буду рад, если заблуждаюсь, и кто-то уже потестил на medium или slow, сравнив с обычными x265 и ffmpeg.

Psych218 ★★★★★
()
Последнее исправление: Psych218 (всего исправлений: 2)
Ответ на: комментарий от vovagubin1987

Если следовать линейной зависимости то фильм можно на такой закодировать за сутки .

Дык и на том, что приведено, можно. 2 fps же написано.

стандартный фильм полтора часа: 90*25*60/2/60/60 = 18.75 часов.

двухчасовой (120 минут): 120*25*60/2/60/60 = 25 часов. Что, конечно, на один час больше суток, но до недели очень далеко.

Psych218 ★★★★★
()

Что-то собрал я то, что по ссылке. Попробовал закодировать полутораминутный фрагмент. CRF23, пресет не указывал (по умолчанию medium используется). Закодировало за 91 секунду. Сравнил с обычным x265 из реп арча. Он закодировал тот же фрагмент с теми же опциями за 92.5 секунды. Разница явно в пределах погрешности. Магии не произошло. Я как-то не так собрал? делал cd build/linux ; ./make-Makefiles.bash ; make

Psych218 ★★★★★
()
Последнее исправление: Psych218 (всего исправлений: 1)
Ответ на: комментарий от Psych218

1-на gcc openacc включается только при автовекторизакии, что требует ключа O2 и выше.+ numa в USE. 2-скачавать надо именно ветку stable. Бранч default не отличается ничем от нативного x265. 3-я не нашёл в сети ничего определённого насчёт того, как gcc поддеживает OpenAcc, кроме того что 6 gcc работает через nvidia 100%. проверить время выполнения можно при помощи вот этого исходника http://my-files.ru/le7c7z. Компилировать его с флагами -03 -fopenacc 4-как у вас с opencl и cuda в системе мне не ясно. 5-вы правы насчёт пресетов. как не странно, но самым быстрым оказался placebo. Хотя чего странного, там много параллельного кода. 6-все измерения я проводил только на данном процессоре. мой проц не имеет ни sse4 ни avx. применение sse4 даёт выйгрыш уже в 4 раза. помножте на количество ядер и получится где-то порядок.

vovagubin1987
() автор топика
Ответ на: комментарий от Dmitry_Sokolowsky

первые реализации считали кадр несколько часов

mittorn ★★★★★
()
Ответ на: комментарий от gag

В сети появился ускоренный при помощи OpenACC видеокодек x265

А как со скоростью декодирования?

Если со скоростью декодирования всё так же как и без OpeACC, тогда надо исправить заголовок новости на: "... ускоренный при помощи OpenACC видеокодер x265", чтобы не вводить в заблуждение тех, кого интересует только ускорение декодирования.

gag ★★★★★
()

Часто слышу как в телевизоре рекламируют какое-то АЦЦ. Так вот что имели в виду!

А если серьёзно, почитать об этой технологии можно вот. Это работает в связке с CUDA.

Использовать сабж я конечно же не буду. Даже если на 1060 он выдаёт 120 FPS в 4k. Я лучше дождусь, когда выйдет поколение карточек с аппаратным кодированием в h265. Насколько я знаю, GeForce 8xxx научились декодировать h264 (кроме 8800 GTX), затем GeForce GT (X) 6xx научились кодировать h264, затем GeForce GT (X) 9xx научились декодировать h265. Недолго ждать осталось!

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

это уже давно вышло за пределы cuda. Другим компиляторам(комерческим) уже давно без разницы, что является сопроцессором и через какие грабли они работают.

vovagubin1987
() автор топика
Ответ на: комментарий от vovagubin1987

Интересно. Я думал что NVIDIA-шные штуки работают только на CPU и на GPU от NVIDIA. И никак иначе. Например PhysX и волосы в Ведьмаке 3.

То, что OpenAAC ускоряется не только с CUDA, это здорово!

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 4)
Ответ на: комментарий от ZenitharChampion

Недолго ждать осталось!

На Skylake 1080p видео кодируется в hevc по 50 кадров в секунду. Зачем ждать? Аппаратные (наверное) кодеры уже давно работают.

i-rinat ★★★★★
()
Ответ на: комментарий от ZenitharChampion

когда выйдет поколение карточек с аппаратным кодированием в h265

Вылезай из криокамеры. Хуанг начиная минимум с паскаля умеет в HEVC Main10 кодировать аппаратным блоком.

devl547 ★★★★★
()
Последнее исправление: devl547 (всего исправлений: 1)
Ответ на: комментарий от vovagubin1987

Да я в курсе, что оно каким-то образом поддерживает это. Но нормальные люди, если не смогли осилить CUDA, то собирают OpenACC хотя бы с помощью PGI.

MuZHiK-2 ★★★★
()
Ответ на: комментарий от kirill_rrr

Разбирать видеоряд на осмысленные составляющие и предсказывать, как поведут себя персонажи в следующем кадре - дорогое удовольствие.

dn2010 ★★★★★
()
Ответ на: комментарий от i-rinat

не надо передергивать, в топике 10bit и skylake его не умеет.

в kabylake quicksync не завезли, а vaapi кодирует как жопа

hizel ★★★★★
()

на этойже видеокарте x264 с nvenc кодирует 1920*1080 60фпс видео с битрейтом 12к и пресетом «slow»(качество)
со скоростью 4x (60*4=240 фпс/сек)

темнемении x265 даже через процессор обгоняет vp8/9 в разы (я не видел ничего медленнее vp8/9)

testersup889
()
Ответ на: комментарий от ZenitharChampion

все карт с 9xx нвидии поддерживают x265 кодирование/декодирование через nvenc/vdpau

стыдно такого не знать, лучшеб инфу гуглил перед тем как чтото писать

anonymous
()
Ответ на: комментарий от testersup889

темнемении

Убейся, дебил.

anonymous
()
Ответ на: комментарий от hizel

в топике 10bit

Чото пропустил я это.

в kabylake quicksync не завезли, а vaapi кодирует как жопа

Они чем-то отличаются?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

разное api, для конченого юзера важно, что

quicksync работает в linux только под определенной версией centos или патчить одну из версий ядра и libva и libdrm, в свежей версии api поддерживаются текущая и предыдущая архитектура. Сейчас kaby lake на linux не завозят с формулировкой - несерверные процы. Изначально прогали в районе СПб

в vaapi китайские программисты расширяют просто libva, выглядит это как блобик и обвязка, мало крутилок

intel контора большая можно и пару api поддерживать

hizel ★★★★★
()
Ответ на: комментарий от hizel

Так качество ощутимо разное? Я думал, что это API просто разное, а ядро алгоритмов кодеров одинаковое. Зачем два раза одно и то же писать, если можно просто выдернуть код вычислительного ядра из intel-vaapi-driver?

i-rinat ★★★★★
()
Ответ на: комментарий от dn2010

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от dn2010

Но это же даёт максимум 10-15% дополнительного сжатия.

kirill_rrr ★★★★★
()
Ответ на: комментарий от AndreyKl

если в следующем кадре точно известно как они себя поведут и следующий кадр доступен сейчас

Да, не вопрос. Вопрос в том, ка описать это движдение в терминах разностных блоков и векторов движения как можно более компактно, да, так, чтобы в ближайших кадрах большинство векторов движения не поменялось. Тут классика решения оптимизационной задачи с отрицательной ОС. А там, где ООС — там прощай параллельность. Здесь приходится всегда делать выбор между тем, насколько субоптимальным будет представление в зависимости от используемого числа независимых вычислительных потоков: чем больше, тем дальше от оптимального.

anonymous
()
Ответ на: комментарий от AndreyKl

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

dn2010 ★★★★★
()
Ответ на: комментарий от dn2010

Вообще-то, доступен. Декодеру и кодеру доступны данные кадров как минимум на расстояние кадровой задержки (один доп. кадр с односторонним предсказанием и два с двусторонней). На практике, кодеру и декодеру доступно гораздо большее число кадров ссылочных макроблоков из разных кадров, определяемое параметром ref в стандартах H.264 или H.265.

anonymous
()

Текущий stable не собирается. Похоже, чувак вообще не проверял на собираемость - куски кода просто вставлены в случайных местах; часть кода обновлена из upstream, часть - нет; и т.д. «Оптимизация», по ходу, сводилась к вставке прагм перед каждым циклом. Нафиг.

anonymous
()
Ответ на: комментарий от kirill_rrr

Закон падающего возврата. Слыхал про такой? Первые попытки оптимизации вблизи правильно выбранного локального минимума, как правило, дают большую часть выигрыша. А с каждым следующим изощрением выигрыш становиться всё меньше, а затраты на его достижение растут. Я полагаю, что битва идёт сложность кодека (энергозатраты на вычисления) против телекоммуникационного ресурса (обобщённые затраты на радиочастотный ресурс и энергию для передачи). Вполне возможно, что в итоге H.265 и не взлетит на практике в самых желаемых профилях и уровнях (которые таки по коэффициенту сжатия делают H.264 почти вдвое).

anonymous
()
Ответ на: комментарий от anonymous

Что доступен - это вы верно сказали. А про остальное наврали.

И кодировщик, и декодер может вносить задержку на некоторое количество кадров (в libx264 и libx265 - до 16; стандарты кодирования не ограничивают это значение, ЕМНИП). По сути, эта задержка используется для переупорядочивания кадров для кодирования B-кадров (т.е. кадров, которые ссылаются на прошлые и будущие кадры в порядке воспроизведения). Так что кодировщик выдает закодированные кадры в порядке декодирования, который отличный от порядка воспроизведения, и с задержкой, а декодер декодирует кадры в порядке декодирования и выдает кадры в порядке воспроизведения, и тоже с задержкой.

Параметр refs, а точнее reference frames, про который вы вспомнили, совсем о другом. Этот параметр говорит, сколько буферов кадров должно быть в кодере/декодере. Потенциально, каждый закодированный кадр может ссылаться на столько угодно других уже декодированных кадров (не обязательно последних), в пределах этого ограничения.

anonymous
()
Ответ на: комментарий от anonymous

Потенциально, каждый закодированный кадр может ссылаться на столько угодно других уже декодированных кадров (не обязательно последних), в пределах этого ограничения.

Неправильно выразился. Кадр может ссылаться на любые кадры в этих буферах.

anonymous
()

Не вижу самого главного — где же график SSIM от коэффициента сжатия. Плюс не вполне ясно, как сочетается такой сильно параллелизованный вариант поиска и компенсации движения со всякими психовизуальными оптимизациями для квантизации (квартизации по решётке и прочими отличными от мёртвой зоны). Я бы посмотрел, пока этого нет, то и обсуждать особо нечего — рекорд ради рекорда с весьма сомнительной практической ценностью. Примерно, как аппаратные кодеры (из затычек для слотов и последних камней Штеуд) — скорее маркетинг, нежели практически целесообразное средство.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

стандарты кодирования не ограничивают это значение, ЕМНИП

Ограничивают. Профилями и уровнями.

А про остальное наврали.

Для человека, ориентирующегося по «ЕМНИП», у вас резковат тон. Сбавьте,, пожалуйста!

Параметр refs, а точнее reference frames, про который вы вспомнили, совсем о другом.

Да неужели. Кадры в декодер не надо передавать вперёд? Хранить их декодированными в видеобуфере не надо? Зависимостей нет? Физическая суть ссылок и задержек та же. Уровень абстракций языка кодовой последовательности чуть-чуть другой. Уже с MPEG-4 стандарт оперирует в качестве ссылочного материала не целыми кадрами а непосредственно конструкциями из макроблоков.

anonymous
()
Ответ на: комментарий от kirill_rrr

0,03 fps? Что не так с этим кодеком?

Популярность в сети за прошедшие пять лет ни на что не намекает?
Выше ведь правильно сказали

Кодировать один раз, потом смотреть тысячи.

еще довольно оптимистично

wxw ★★★★★
()
Ответ на: комментарий от anonymous

результат должен быть эквивалентным ванильному libx265

Аналогичнось, да. Эквивалентность вряд ли.

anonymous
()
Ответ на: комментарий от anonymous

стандарты кодирования не ограничивают это значение, ЕМНИП
Ограничивают. Профилями и уровнями.

Профили включают/отключают фичи, в частности, в h264 наличие B-frame. Уровни, по сути, задают минимальную производительность декодера, а именно разрешение, fps, bitrate. Профили не ограничивают максимальное количество последовательных B-frame или задержку. Для формата кодирования вообще нет таких понятий. Вот количество референсных буферов - да, ограничивается.

А про остальное наврали.

Для человека, ориентирующегося по «ЕМНИП», у вас резковат тон. Сбавьте,, пожалуйста!

Вот уже не думал, что на ЛОР заходят ранимые личности. :) Ничего оскорбительного ввиду не имел.

Параметр refs, а точнее reference frames, про который вы вспомнили, совсем о другом.

Да неужели. Кадры в декодер не надо передавать вперёд? Хранить их декодированными в видеобуфере не надо? Зависимостей нет? Физическая суть ссылок и задержек та же.

Нет, не та же. Как используются рефепенсные буферы решает кодировщик, и в общем случае их количество не имеет отношения ни к задержке, ни к B-frame. Ну то есть, конечно, для декодирования B-frame нужно как минимум 2 референсных буфера, но и только. К примеру, часть референсных буферов может использоваться для долговременных референсных кадров, на которые можно опирать кадры в случае потерь в сети. Или, к примеру, реализовать Temporal SVC, когда разные слои опираются только на кадры из своего и более низких слоев.

Уровень абстракций языка кодовой последовательности чуть-чуть другой. Уже с MPEG-4 стандарт оперирует в качестве ссылочного материала не целыми кадрами а непосредственно конструкциями из макроблоков.

А с этим я и не спорю.

anonymous
()
Ответ на: комментарий от anonymous

1-Прошу прощение за невнимательность. Подпавил заголовочные и всё пересобрал. Handbrake не падает.

vovagubin1987
() автор топика
Ответ на: комментарий от anonymous

А с этим я и не спорю.
Вот уже не думал, что на ЛОР заходят ранимые личности.

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

Для формата кодирования вообще нет таких понятий.
max_num_ref_frames specifies the maximum number of short-term and long-term reference frames, complementary reference field pairs, and non-paired reference fields that may be used by the decoding process for inter prediction of any picture in the sequence. max_num_ref_frames also determines the size of the sliding window operation as specified in subclause 8.2.5.3. The value of max_num_ref_frames shall be in the range of 0 to MaxDpbFrames (as specified in subclause A.3.1 or A.3.2), inclusive.

и в общем случае их количество не имеет отношения ни к задержке, ни к B-frame.
Ну то есть, конечно, для декодирования B-frame нужно как минимум 2 референсных буфера

Это, конечно, хорошо, что вы раскрываете технические детали, но не могли бы вы дать точные ответы именно на те вопросы, которые задал я, а не на те, на которые желаете ответить вы?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.