LINUX.ORG.RU

Вышел FFmpeg 2.0 с поддержкой OpenCL

 


1

3

В новой версии FFmpeg 2.0, программе для обработки и вещания мультимедиа потоков, добавлено много новых фильтров, стало больше кодеков и контейнеров, улучшена производительность и удобство использования.

Производительность

Кодирование AAC оптимизировано для x86/MIPS и стало быстрее на 10%. Фильтры теперь могут работать в несколько потоков, разбивая кадр на части и обрабатывать их параллельно. Добавлена поддержка OpenCL для использования GPU фильтрами. На данный момент только два фильтра могут использовать GPU: deshake, устраняющий дрожание камеры, и unsharp, изменяющий четкость или размытость изображения.

Удобство

У ffmpeg появились новые опции -filter_script и -filter_complex_script, которые позволяют задавать цепочки фильтров в отдельном файле, а не в командной строке. В ffplay добавлена поддержка аудио-фильтров.

Новые фильтры

  • sine - генерирует звуковой синусоидальный сигнал;
  • smptehdbars - генерирует тестовое изображение SMPTE RP 219-2002;
  • colorbalance, colorchannelmixer - модифицируют цветовые составляющие изображения;
  • vidstabdetect, vidstabtransform - стабилизируют изображение, используя vid.stab
  • trim, atrim - вырезают часть из входного потока, что позволяет теперь делать нелинейное редактирование одной командой без создания временных файлов;
  • zmq, azmq - принимает команды от libzmq клиента и отправляет их в цепочку фильтров, позволяет менять параметры фильтров «на лету»;
  • owdenoise - подавляет шум;
  • vignette - делает виньетку;
  • rotate - поворачивает изображение на произвольный угол;
  • и другие...

>>> Подробнее о FFmpeg 2.0

★★

Проверено: JB ()

На данный момент только два фильтра могут использовать GPU: deshake, устраняющий дрожание камеры, и unsharp, изменяющий четкость или размытость изображения.

Странно, что crop and scale из handbrake не взяли.

devl547 ★★★★★
()
Ответ на: комментарий от Indeec
Или оно уже гдето есть?

В винде есть. В линуксе надо ждать, пока кто-нибудь из производителей GPU не снизойдет.

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

У ffmpeg своего кодера h.264 нет. ffmpeg кодирует h.264 с помощью библиотеки x264, которая не так давно научилась использовать OpenCL. Скорость выше, но качество хуже, чем на CPU.

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

Или оно уже гдето есть?

в AMD OpenCL SDK есть поддержка VCE.
в CUDA SDK вроде как есть поддержка NVENC.

Но вот софт под онтопик никто не пишет(

devl547 ★★★★★
()

Омские линуксоиды одобряют!

Ждём ответа от команды libavconv. Конкуренция рулит и педалит.

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

lookahead на OpenCL реализован хуже, чем на C. А прироста скорости может и не быть, это зависит от конкретной ситуации. Можно сказать, что кодирования на GPU пока нет (я про ffmpeg).

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

И где теперь libav?

А что, они где-то еще кроме того места, куда они изначально забрались? У этих поттерингов один NIH на уме.

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

оно есть в libva. В ffmpeg можешь сам добавить.

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

У avconv все скучно. Одни исправления «ошибок». Они отстали от поезда. Даже смержиться с ffmpeg, похоже, сил не хватает.

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

Ждем возможности жать х264 на гпу... Или оно уже гдето есть?

Сомнительно что возможно с тем же качеством

namezys ★★★★
()

Добавлена поддержка OpenCL для использования GPU фильтрами. На данный момент только два фильтра могут использовать GPU: deshake, устраняющий дрожание камеры, и unsharp, изменяющий четкость или размытость изображения.

Знающие FFmpeg могут сказать команду для использования этих фильтров. Хочется протестировать со свободными дровами.

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

Судя по всему главное - отличаться от ffmpeg, причём версия должна быть побольше для придания солидности.

dinn ★★★★★
()

rotate - поворачивает изображение на произвольный угол

Джва года ждал.

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

Ждем возможности жать х264 на гпу... Или оно уже гдето есть?

Видел запутанный мануал, как использовать Intel QuickSync, но попробовать пока руки не дошли.

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

Да. Получается. Аппаратные кодеры дают худшее качество изображения по сравнению со сжатием на процессоре общего назначения. GPU - это некоторая середина между аппаратным кодером и CPU, т.к. он программируется (это плюс), но беден в выборе типа данных и операций (это минус).

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

Для libav есть декодер h.264 на Intel QuickSync. Он еще не вошел в главную ветку ни в libav, ни ffmpeg. Так что все будет, там интел суетится. Я мечтаю о ffmpeg с кодером h.264 и под LGPL!

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

Да фильтры те же, просто добавляется флаг opencl.

Без OpenCL:

ffmpeg -i tremor.avi -vf deshake fresh.avi
C OpenCL:
ffmpeg -i tremor.avi -vf "deshake=opencl=1" fresh.avi

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

Ни то, ни другое. Я имею в виду обычный Си для процессора общего назначения.

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

Да. По сравнению с версией 1.2 API изменен. LIBAV*_VERSION_MAJOR увеличен, это значит, программы с новым FFmpeg могут перестать собираться.

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

У меня этого примуса нет, но, чисто теоретически предположу, должно и на нем работать.

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

Почитай про кодеки семейства MPEG, и сжатие с потерями в целом, и про проблемы GPGPU.

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

То, что opencl очень ограничен, это да. Но проблема решается алгоритмами. Аппаратный если хуже, то не из-за каких-то физических законов, в конце-концов в fpga любой алгоритм залить можно (в штампуемую плату тоже), а из-за того, что туда плохой алгоритм залили.

Так что я надеюсь, проблемы временные.

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

Качество не хуже.

Хуже. Даже вантузятники готовящие рипы блю рей дисков не конвертируют на видеокарте. Поинтересуйся у них.

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

не конвертируют на видеокарте. Поинтересуйся у них.

Интересовался. Потому что существующие CUDA и аппаратные энкодеры (NVENC, QuickSync и VCE) - гуано полное и заточены под encode fast - encode ugly. Качество прыгает от программы к программе.
И самое интересное, что они с энтузиазмом смотрят на handbrake-opencl и x264-opencl, потому что качество не страдает.

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

Нет. Разработчикам avconv ЧСВ не позволит брать что-то из сабжа (не для того они отфоркивались и столько пафоса нагоняли).

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

Ждем возможности жать х264 на гпу... Или оно уже гдето есть?

Каков смысл ожидания?

Ага, а ещё на калькуляторе, FPGA, и микроволновке. x264 - это априори VLIW-based кодек, и ни на чём другом, кроме intel/amd и слегка ARM/Neon он работать не будет НИ-КО-ГДА. Да и вообще, зачем Вы ждёте H.264 на GPU? Чего хотите-то от этого? Новости на Лоре? А вот на отдельном видеопайплайне практически уже есть: http://software.intel.com/en-us/forums/topic/386795

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