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 ()

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

Ровно как и своё делают и параметры запуска не ломают. Собственно GPL и опенсорс - есть что интересное, почему не дёрнуть в обратку.

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

Такая схема работы обусловлена особенностью работы кодеков и многих существующих API. В том числе - аппаратных. Вообще, теоретически, возможны ситуации генерации нескольких фреймов из одного пакета, и такой подход позволяет более лаконично обрабатывать такие ситуации.

h4tr3d ★★★★★ ()

А интелевское ускорение кодирования mpeg2 заработало? Файлы-то оно пережимает из h.264 нормально, а вот с потоковым видео лажает, иногда вплоть до полного зависания сервера.

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

H265 уже готов для мощных рипов, достойных рутрекера? Если ли смысл выкладывать фильмы в h265 с битрейтом 8-10 Мбит в сек?

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

H265 уже готов для мощных рипов, достойных рутрекера? Если ли смысл выкладывать фильмы в h265 с битрейтом 8-10 Мбит в сек?

Офигеть можно! И сколько один такой фильм весит?

P.S.
Лет 10 назад, я ещё думал, что фильм с DVD качеством это идеал.

anonymous ()

Кстати, выкладывают на рутрекер рипы в VP8/9?

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

Вообще, теоретически, возможны ситуации

Если верить заметке (выше треду), то такой ситуации пока нет. И не факт, что будет.

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

Я регулярно качаю фильмы h264 с битрейтом 20 мбит в сек, весят около 20-40 Гигов. Качается за 2 часа :)

Мне кажется, имеет смысл пережимать 20 Мбит h.264 в 8 Мбит h.265.

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

Нет. Чтобы сжать фильм с этими кодеками с потоком 5-10 Мбит в секунду и с хорошим качеством - нужно ОЧЕНЬ ОЧЕНЬ много процессорного времени. Порядка 3 суток непрерывного кодирования на core i7 3770 4 Ггц.

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

Начиная с хасвелла побыстрее будет, у тебя проц старше.

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

Они там даже в основном выкладывают без полных возможностей h264 с ограниченным level до 3*, чтобы на аппаратных недоплеерах везде открывалось.

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

Уже 2 года h265 кодируют, это примерно как с h264-hi10p — в него кодировали когда ещё ни один софтварный плеер не умел в него, только форки форков. Правда тут ситуация получше.

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

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

  1. поблочный поиск векторов движения по оному из критериев ошибки предсказания;
  2. поблочное корреляционное преобразование (например, ДКП) для последующего компактного представления информации об изображении;
  3. передискретизация (снижение точности чисел, которыми представлены коэффициенты преобразования) и отбрасывание незначимых (и снова по какому-нибудь критерию ошибки)скалярных произведений коэффициентов корреляции с базисными функциями коэффициентов преобразования;
  4. благодаря декорреляции (временно́й по п.1 и пространственной по п.2) исходного видеоряда, а также в результате устранения избыточности по п.3, повышается вероятность оптимального (по критерию наименьшей ширины выходного потока данных) представления последовательности лексем, в которые превратился видеоряд после хитрокрученных преобразований пп.1-3, через арифметическое кодирование, понижающее энтропию данных.

Обращаю внимание, что наиболее нагруженным по вычислениям является п.1; он же имеет ярко выраженный очевидный компромисс: можно вести поиск коротких векторов движения (т. е. ограничивать область поиска наименьшей площадью кадра), обеспечив таким образом максимальные возможности для параллельного поиска в независимых вычислительных потоках, а можно вместо этого увеличить зону поиска движения с целью получить общую картину векторов движения, как можно ближе соответствующую перемещению объектов, различимому человеческим зрительным восприятием, т. е. приблизиться к оптимальному предсказанию движения.

Но это половина беды. В п.4 не вполне очевидно, что весь процесс пп.1-4 является итерационным: так для оценки движения в п.1 обеспечивается вариативность каждого законченного решения по предсказанию движения (т. к. в зависимости от данных, которыми станут лексемы от последующих пунктов, не очевидна оптимальность каждого отдельного решения после энтропийного кодирования); а п.2-3 параметризуются с целью формулирования оптимизационной задачи и последующего её решения относительно параметров (например, значения квантователя) и ширины потока данных на выходе.

Таким образом в нашей программе появляется многопетлевая отрицательная обратная связь, которая ставит массивный бетонный могильный камень над перспективой массовой параллелизации вычислений. Сама задача поиска компенсации движения сформулирована так, что для её решения предпочтительнее один быстрый камень, чем несколько медленных. Т. е. прощай куда-чуда-юда.

Дополнительно расскажу, что со времён H.261 и его предшественников принципы неизменны, а развитие идёт по пути усложнения инструментов представления (расширение набора лексем) видеоряда. Грубо говоря, с каждой следующей версией к идее компенсации движения добавляют новых костылей, которые сильно увеличивают вычислительную сложность и дают небольшое приближение к оптимальному кодированию по критерию наименьшей заметности потерь при высоком коэффициенте сжатия. Качественно набор лексем ограничивается профилями современных стандартов (например, в H.264 есть их восемь), и количественно ограничивается уровнями. При этом производитель специализированной микросхемы (или ПЦОС-блока) не заинтересован в том, чтобы поехать на отличненько в попытке реализовать все мыслимые в стандарте лексемы и аппаратную синхронизацию вычислительных потоков, а потом всё это отладить и оптимизировать (скромно напомню, что в железе ошибки исправлять и искать не в пример сложнее, чем в программе). Посему программные кодеры, как правило, существенно сложнее, что в случае, например, libx264 обеспечивает существенный выигрыш в приближении к оптимальному сжатию.

Да, и про всё это русским языком написано в Википедии, но школьники из треда, конечно же, не читатели, да.

Такие дела.

anonymous ()

Пользуясь случаем спрошу у зала: хочу выдрать кадр из видео, обязательно ли для этого нужен ключевой кадр? Как я понял ffmpeg сначала ищет этот кадр, на это уходит определенное время и это время варьируется от видеоролика, иногда доходит до 5 сек.(много). Видос в mp4/flv

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

Да, обязательно. Причём в случае H.264 для восстановления произвольного кадра потребуется предварительно восстановить не только ключевой кадр, но и все ссылочные, которые в случае high profile могут быть и B-кадрами, и даже со ссылками высшего порядка (т. е. ссылаться на другие B-кадры). B-кадром называется такой кадр, который содержит хотя бы один макроблок (единицу предсказания движения), ссылающийся одновременно на макроблоки одного из предыдущих и одного из следующих кадров. Стандарт ограничивает общее число ссылочных кадров таким хитрым параметром как Reference Frames (опция --ref у x264); суть его — максимальное число кадров, которые требуется восстановить гипотетическому декодеру для восстановления произвольного кадра.

Т. о. если вы выбрали произвольный кадр, то восстановить потребуется не только ключевой кадр, но и до N-1 прочих ссылочных, где N — число reference frames, указанное в секции codec pivate вначале первого или каждого ключевого кадра закодированной последовательности. Школота отмечена не только рукоблудной страстью к Hi10P, но и стремлением не жалеть ни своё ни Ваше время путём разрешения большего числа reference frames.

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

Естественно. ТЫ же не процессоры используешь разные, а разные кодеки. Один программный, на процессоре, а другой аппаратный, на видеокарте.

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

массивный бетонный могильный камень

Ну ты прям загнул! Даже если решать честно (допустим так же честно как в ffmpeg, там тоже хаков хватает) и пытаться сделать все прям оптимально-оптимально, то все равно есть очень много мест для распараллеливания кода.

ИМХО, ниша у хардверных решений ближе к рилтайму. А там в любом случае ни о какой оптимальности не может идти речи...

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

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

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

допустим так же честно как в ffmpeg, там тоже хаков хватает

В libavcodec предсказатель движения распараллелен в зависимости от критерия оптимальности весьма хорошо: в основном в два треда.

очень много мест для распараллеливания кода

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

anonymous ()

H.263
2016

Бу-га-га. А чего сразу не MPEG1?

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

4-8k 60fps кое-какую нагрузку на проц создаст, думаю.

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

Хотя бы потому, что ролики в старых форматах не исчезли из-за появления новых.

anonymous ()

Кто-нибудь ffplay пользуется? Где, на чем?

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

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

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

И что мне нужно будет ждать этот час для выдирания картинки?

Если имелась в виду необходимость восстановления всех кадров последовательности, то её в случае H.261/H.262/H.263/H.264/H.265 при доступе к произвольному кадру нет, т. к. одной из принципиальных частей стандарта является спецификация на гипотетический декодер с ограниченным видеобуфером, в котором храниться весьма небольшое число кадров, которые ранее использованы кодером как ссылочные, т. е. в закодированной последовательности для любого произвольного кадра ограничено число ссылочных.

Пример со статичной картинкой неудачный, т. к. там нет предпосылок к двусторонней компенсации движения, все вектора из оптимального решения задачи поиска движения нулевые, и все ссылки, соответственно, ведут к первому кадру, являющемуся ключевым и по совместительству единственным ссылочным. В приведённом случае для восстановления такой последовательности потребуется получить два кадра: ближайший ключевой и Ваш произвольный. Но это если при кодировании статичной картинки тот, кто кодировал правильно настроил кодер, т. е. выключил компенсацию движения (указав нулевую область поиска) и B-макроблоки. На практике, картина будет несколько отличаться, но для видеопоследовательности, соответствующей уровням и профилям стандартов H.262/H.263/H.264/H.265 всю последовательность из, например, нескольких десятков кадров воспроизводить для доступа к произвольному кадру не потребуется в любом случае. Плюс ко всему, даже изготовить такую последовательность при помощи отлаженного кодера не то, чтобы очень просто, т. к. кодеру должен получить оптимальное по ширине потока решение, в которое не может вписаться большое число ссылочных кадров, т. к. каждая ссылка — это дополнительный трафик, а решение о каждой дополнительной ссылке для любого макроблока даёт убывающий возврат (т. е. экономия трафика в целом от увеличения числа ссылочных кадров на единицу убывает с числом ссылочных кадров, и довольно быстро).

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

Не затруднит показать?

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

А про motion compensation - основная сложность найти что куда переместилось. Не знаю как сейчас решают, но раньше чуть ли не в наглую брутфорсили каждый макроблок в ограниченном диапазоне алгоритмами вида «а если сюда, то какая будет ошибка, а если сюда и т.д.», а потом выбирали результаты с минимальной ошибкой (или точнее с допустимой ошибкой). По количеству изменившихся блоков и по диапазону поиска такой алгоритм должен неплохо параллелится. Решение потом придется принимать в один поток (после барьера наверное), но там уже вроде как и не нужны серьезные вычислительные мощности. Барьер тоже может снизить эффективность от распараллеливания, но вряд ли превратит задачу в «однопоточную».

С некоторыми стадиями сжатия наверное ничего не сделаешь. Например, когда-то давно в глубоком детстве я подбирал таблицу Хаффмана методом, отдаленно похожим на динамическое программирование. Наверное ту реализацию никак не получилось бы распараллелить... Так что с variable size motion compensation можно и встрять, или с решениями типа P-frame или B-frame, или с решениями типа перемещение блока или полная замена. Но если внутри распараллелить, то может и не нужно эти стадии пытаться снаружи оптимизировать...

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

Аппаратно кодит специальный чип с ограниченными возможностями и настройками. Не столько качество хуже, сколько хуже эффективность сжатия. Говорят хардварные кодеры жмут на уровне superfast veryfast пресетов x264. Качество обеспечить можно, но нужно больше битрейта. То есть, чем слабее сжимаемость, тем больше нужно битрейта для того же качества. Поэкспериментируйте сами в x264, сожмите с crf, например 18, на разных пресетах от ultrafast до placebo и посмотрите на получившийся битрейт. Так то и ultrafast может сжать вообще без потерь при crf=0.

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

Это декодирование при воспроизведении, для этого есть специальный чип. А для кодирования современные кодеки используют CUDA, DXVA + CPU, и соответственно настройки можно установить какие тебе угодно.

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

А для кодирования современные кодеки используют CUDA, DXVA + CPU, и соответственно настройки можно установить какие тебе угодно.

Серьёзно? А пруфануть ссылкой? Вот кое-какие соображения от разработчика: http://forum.doom9.org/showthread.php?p=1135399#post1135399 https://www.researchgate.net/publication/220810465_An_efficient_parallel_moti... https://sites.google.com/site/x264cuda/Home/x264-cuda.pdf?attredirects=0

Это декодирование при воспроизведении, для этого есть специальный чип.

Для кодирования тоже. Небольшой ликбез специально для тебя. См. http://www.nvidia.ru/object/tesla-gpu-accelerated-libraries-video-codec-sdk-r...

API NVIDIA NVENC... доступ к высокопроизводительному кодировщику видео H.264... специальное аппаратное обеспечение для осуществления кодировки видео...
ядра GPU с поддержкой CUDA... свободны для выполнения других задач...

NVENC — это отдельная кучка транзисторов на кристалле GPU, которая ничего кроме кодирования видео не умеет, да и настройки там совсем не любые. И да, эффективность сжатия весьма сомнительна. Даже настолько, что выигрыш в скорости при примерно той же эффективности сжатия у профиля ultrafast/superfast библиотеки libx264 не воплне очевиден.

См. также https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

dedicated video encoding and decoding hardware core.

Т. е. всё то же самое. Отдельная кучка транзисторов, специально для кодирования видео с убогим набором опций. Как и в случае с NVENC, здесь гораздо больше маркетинга, чем практически целесообразных технологий.

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