LINUX.ORG.RU

FFmpeg 3.2

 ,


1

1

FFmpeg включает в себе набор программ и библиотек для операций над различными форматами видео и аудио (запись, декодирование видео и аудио и т. д.). В новый выпуск включены стабильные наработки из веток mt (декодирование в несколько потоков) и libav (форк FFmpeg). Пакет распространяется под лицензиям GPL и LGPL. Ведётся смежная с FFmpeg разработка MPlayer.

Основные изменения, вошедшие в релиз:

  • Новые фильтры: weave, gblur (размытие по Гауссу), avgblur, nimeans, sobel, acrusher и др.
  • Поддержка ускорения декодирования VP8, H.263, VP9 и HEVC.
  • Возможность использовать аппаратное ускорение чипов MediaCodec для кодирования и декодирования популярных кодеков (H. 264, MPEG-4 и т. д.).
  • Добавлена поддержка протокола tee для разделения вывода на несколько потоков (например, tee:file://path/to/local/this.avi|file://path/to/local/that.avi).
  • В утилите ffplay реализована поддержка вывода через SDL2.
  • Прекращена поддержка SDL1.
  • Удалён кодировщик libfaac.
  • Исправлено множество ошибок.

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

★☆

Проверено: Klymedy ()
Последнее исправление: sudopacman (всего исправлений: 2)

Кто кодировкой видео занимается? На Linux можно делать мощные рипы, достойные Рутрекера? Видюха нужна nVidia, ибо остальные говно?

anonymous
()

Только я для себя ffplay запатчил, так они в тот же день на SDL2 перешли. Только я написал свой биткрушер, они свой сделали. Хватить воровать у меня код!

По факту ничего нового. В очередной раз выкинули мое AAC и не извинились, потому ffmpeg с момента выкидывания libaacplus меня не сильно интересует.

ruzisufaka
()

MVC так и не запилили?

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

Опять api переколбасили.

Печально. В моём проекте на работе, использующем ffmpeg (в линукс-сборке приходится брать довольно старую версию) и так #ifdef-ов выше крыши...

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

Почему это? Ты хочешь сказать что есть КАЧЕСТВЕННАЯ разница на чем кодировать - на процессоре или видеокарте? Мало того что я часто видел как народ пишет что на GPU кодировка во много раз быстрее, но нигде не читал что по каким-то причинам должно снижаться качество рипа. Качество же задается отдельными параметрами. Как сам факт использования GPU может снизить качество рипа?

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

Я тоже не понял почему. Программа же использует просто «мощности», которых в видюхе как правило больше. Значит рип одинакового качестве на видюхе делается просто быстрее.

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

На видеокарте качество страдает в пользу скорости.

Большего бреда я еще не слышал.

Ну что сказать. А такое вполне легко бывает.

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

И где там доказательство что на GPU хуже? А, клоун? Где хоть одна картинка-пруф с логами из mediainfo? Так я и знал, очередные форумные балаболы.

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

Libav вроде затем и придумали.

Чтобы API ломать. Изменения в последнем libav 12 аналогичные. Оттуда их и передирают.

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

Печально. В моём проекте на работе, использующем ffmpeg (в линукс-сборке приходится брать довольно старую версию) и так #ifdef-ов выше крыши...

Теперь ими сложновато будет отделаться: https://blogs.gentoo.org/lu_zero/2016/03/29/new-avcodec-api/ А так пока можно потянуть время. Старую функцию ещё не выкинули, а просто обозвали устаревшей.

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

Ну как есть.

mediainfo

mediainfo не выводит информацию о качестве файла в том смысле, в котором можно сделать какой-то вывод. Сравнить можно только скрины между собой.

PS: я вектор направления указал, а если ты не хочешь думать, а просто охота спорить и троллить, то это твои проблемы.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 3)

По поводу ускорения кодирования h264 на видеокартах и снижения качества.

Во-первых, не все алгоритмы можно ускорить за счет распараллеливания, а именно этим видяшки берут. Во-вторых, в какой-то момент времени все данные надо синхронизировать и тем самым потерять все профиты. Но можно «схитрить» и распараллелить до состояния «вот этот кусок кодирую я, а это кодируй ты». Это все равно, что 100 мегабайтный текстовый файлик не сжимать сразу в gzip, а сначала порезать на 100 частей, каждую часть жать отдельно, а потом упакованное склеить. Да, так можно делать, но файлик будет заметно больше, чем при однопроходном кодировании. Именно поэтому аппаратными енкодерами обычно ставят битрейт не менее 30 мегабит для простой картинки. Потому что если будет меньше - будет хреновое качество. Вот так качество падает в угоду скорости.

Очень хочу послушать обсуждение «этого бреда», которого вы, в силу своей ограниченности, никогда не слышали.

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

Вообще, он прав, только надо скорее не медиаинфо, а какую-то хрень от тектроника, которая умеет анализировать весь поток. Было бы интересно посмотреть.

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

Дураку всё что он не понял кажется бредом.

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

Да может и переписать. API теперь асинхронный. Кидаем данные через avcodec_send_packet, а получаем из avcodec_receive_frame. Если верить заметке, то пока всё можно сделать в одном потоке. А так, как я понял, в будущем ffmpeg будет плодить свои потоки, с которыми асинхронно надо будет взаимодействовать, ну или sleep-ов понавтыкать, чтобы дождаться, когда оно там внутри себя что-то перелопатит.

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

не менее 30 мегабит

1080p@60 ~8-10 уже почти не отличить от оригинала на сложной динамичной картинке, 20 по-моему максимум что можно выставить для nvenc

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

PS: я вектор направления указал

Ты говна набросил. Там нет ни доказательств, ни скринов.

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

Опять api переколбасили.

в рамках Major версии - обратно-совместимо. В т.ч. на бинарном уровне.

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

В очередной раз выкинули мое AAC и не извинились, потому ffmpeg с момента выкидывания libaacplus меня не сильно интересует.

спроси обоснование. Обычно выкидывают неподдерживаемое апстримом. Но таки да, не хватает расширения списка кодеков и форматов на уровне добавления .so. Тогда можно было бы сторонним разработчикам свои расширения пилить.

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

Речь про использование аппратных блоков кодирования/декодирования. По типу Intel QSV. Про другие не знаю, не сильно возиться приходилось.

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

Логичное действие, в системе фильтров давно подобным образом было организованно. Да ровно как и в ресемплере/рескейлере. Судя по всему, хотят к 4.0 отладить. А пока можно спокойно жить на старом API.

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

Мы используем OpenH264 и сами муксим в контейнер, для mp4 строчек двести.

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

Нет, если используется аппаратный энкодер он в силу ограничений архитектуры хуже по качеству.

anonymous
()

Удалён кодировщик libfaac.

перелопатили капитально

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

Не увидел логики. Кода стало больше, плюс надо ещё типы ошибок ловить. А так да, старый API можно использовать, или даже вообще не обновляться 10 лет. Никто же не мешает этого делать. Только вот на оценку адекватности действий разработчиков это, увы, уже не влияет.

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

libav придумали истерички. И нет, не для этого.

Только не понятно, зачем у этих истеричек коммиты так упорно дёргают.

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

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

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

От вендора зависит. Например, в процессоре интела есть отдельный блок энкодеров и дальнейшая обработка происходит на их же видеокарте, из-за чего аппаратное кодирование не работает если встроенная видеокарта интел не используется. В невидии реализовано поверх куды, но чтобы эффективно распараллелить поступились качеством. Потому что те же самые алгоритмы нельзя эффективно реализовать на видеокарте.

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

Понятно. В общем от реализации зависит. И если верить некоторым в этом треде, на видеокарте она не фонтан.

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

Прицельно не интересовался, но мне всегда казалось что «рипты достойные рутрекера» (т.е. те которые делают опытные люди для публики, а не рандомные люди для сеюя) в основном делаются процом. И судя по mediainfo частенько они делаются как-раз ffmpeg-ом (скорее всего через какие-то графические обёртки).
Если очень интересно то можешь сходить на какой-нибудь hd-club, там наверное где-то есть мануалы про то как делать Это правильно. Ну и на рутрекере они есть точно.

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

Так и сделаю. Пора зариповать хороших видюшек, да поделиться с миром. Да взорвутся пуканы правообладателей!

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

Потоки оно и раньше плодить умело, даже ошибками сыпать умело про разные треды, надо было втыкать ему примитивы для синхронизации. Но вот теперь эта асинхронщина, я так понимаю, будет камнем преткновения и жора оперативы.

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

Не исключено. Я лично работал с intel media sdk и cuda-версией нвидии из gpu computing sdk (nvcuvid), оба хуже софтварной версии но для превью сгодились, пока на цпу в остальных потоках кодируется-муксится

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

Будет плеер в плеере. А хотелось просто единый API для кучи кодеков.

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