The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск мультимедиа-пакета FFmpeg 4.1

06.11.2018 10:43

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

Из изменений, добавленных в FFmpeg 4.1, можно выделить:

  • Добавлена возможность использования формата кодирования видео AV1 в контейнерах MP4 и реализован парсер для AV1. AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия;
  • Добавлена поддержка реализации TLS на базе библиотеки mbedTLS;
  • Новые кодировщики и декодировщики:
    • Декодировщик формата кодирования звука Sony ATRAC9 (Adaptive Transform Acoustic Coding);
    • Кодировщик и декодировщик формата сжатия звука и видео AVS2, стандартизированного в Китае. Реализация основана на библиотеке libdavs2;
    • Декодировщик для звукового кодека iLBC (Internet Low Bitrate Codec), оптимизированного для передачи голоса по низкоскоростным каналам связи;
    • Кодировщик и декодировщик для звукового кодека pcm vidc;
    • Декодировщик для видеокодека IMM4;
    • Декодировщик для формата кодирования видео Brooktree ProSumer;
    • Декодировщик для формата WinCam Motion Video;
    • Декодировщик для форматов MatchWare Screen Capture и RemotelyAnywhere Screen Capture, используемых при записи содержимого экрана;
    • Для формата h264 реализовна поддержка декодирования таймкода S12M;
    • Представлен распаковщик (demuxer) медиаконтейнеров SER;
    • В декодировщике vc1 задействован алгоритм bit-exact;
  • Новые фильтры:
    • deblock - удаление блочных артефактов из видео;
    • tmix - смешивание следующих друг за другом видеокадров;
    • amplify - усиление разницы между текущим пикселем и пикселями в том же месте из соседних кадров;
    • fftdnoiz - подавление шума в кадрах при помощи фильтра 3D FFT (frequency domain filtering);
    • aderivative и aintegral - вычисление производной и интеграла для звукового потока. Применение одного фильтра после другого позволяет восстановить оригинальный звуковой поток;
    • pal75bars и pal100bars - генерирует цветовые шаблоны на основе рекомендаций EBU PAL с 75% и 100% уровнем цвета;
    • adeclick - удаление импульсных помех из звукового потока, которые заменяются на интерполированные сэмплы, используя авторегрессионное моделирование;
    • adeclip - заменяет повреждённые сэмплы при помощи авторегрессионного моделирования;
    • lensfun - корректирует вносимые объективом искажения, используя библиотеку lensfun;
    • colorconstancy - корректирует цвет объектов в зависимости от цвета освещения;
    • lut1d - применение цветового преобразования 1D LUT к видео;
    • cue и acue - задержка применения фильтров к видео или звуку до наступления указанной временной метки (позиции в потоке);
    • transpose_npp - перестановка местами строк и столбцов в видео;
    • amultiply - объединение двух звуковых потоков;
    • bm3d - подавление шумов в кадрах при помощи алгоритма Block-Matching 3D;
    • acrossover - разделение звукового потока с разбивкой по частотным диапазонам;
    • afftdn - подавление шума в звуковом потоке при помощи быстрого преобразования Фурье (FFT);
    • graphmonitor и agraphmonitor - отображения различной статистики работы видео и звуковых фильтров;
    • yadif_cuda - устранение чересстрочности в видео, используя реализацию алгоритма yadif, ускоренную при помощи CUDA;
    • xstack - совмещение нескольких видео (каждое видео показывается в своей области экрана);
    • sinc - генерация коэффициентов FIR для звукового потока;
    • chromahold - удаление информации о всех цветах за исключением указанного;
    • setparams - установка параметров для кадра, влияющих на работу других фильтров и кодировщиков;
    • vibrance - увеличение или уменьшение цветовой насыщенности;
    • Для фильтров на основе методов глубинного машинного обучения (DNN), таких как srcnn (Super-Resolution Convolutional Neural Network), подготовлен новый бэкенд на основе libtensorflow;


  1. Главная ссылка к новости (http://ffmpeg.org/download.htm...)
  2. OpenNews: VideoLAN и FFmpeg разработали новый декодировщик для видеокодека AV1
  3. OpenNews: Выпуск мультимедиа-пакета FFmpeg 4.0
  4. OpenNews: Основатель QEMU и FFmpeg развивает систему синхронизации файлов VFsync
  5. OpenNews: В FFmpeg устранена уязвимость, которая может привести к утечке локальных файлов
  6. OpenNews: Лидер проекта FFmpeg сложил с себя полномочия
Лицензия: CC-BY
Тип: Программы
Ключевые слова: ffmpeg
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (76) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 11:21, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >TLS

    А зачем это в наборе мультимедиа-библиотек?

     
     
  • 2.3, Аноним (3), 11:26, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >>TLS
    > А зачем это в наборе мультимедиа-библиотек?

    Потоковое вещание в шифрованием.

     
     
  • 3.8, Антон (??), 12:07, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    разве потоковое вещание не дело сервиса потокового вещания, а не мультимедиа-библиотеки?
     
     
  • 4.11, Annoynymous (ok), 12:23, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ffmpeg умеет работать сервисом потокового вещания.

    //К.О.

     
     
  • 5.19, Аноним (19), 13:25, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • –14 +/
    А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?  
     
     
  • 6.31, Твоя мамка (?), 14:48, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Авторизация для потокового вещания тоже доступна.
     
  • 6.32, Qwerty (??), 15:05, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Судя по дислайкам - нет.
     
  • 6.48, Аноним (-), 08:14, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?

    Гугель именно им ютуб кодирует, если не ошибаюсь. Поучи их видео кодировать, умник.

     
  • 6.59, Аноним (59), 10:11, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что-что, а ффмпег в этом плане достаточно надежный. Люди(и я в тч) годами используют его для круглосуточного кодирования без проблем. Плохому танцору как говорится.
     
  • 3.26, Zenitur (ok), 13:36, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте
     
     
  • 4.33, фывфывфыв (?), 15:22, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    КЭП: Дабы организовывать закрытые трансляции.
     
  • 4.49, Аноним (-), 08:15, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте

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

     
  • 2.14, Mihail Zenkov (ok), 12:49, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен.

    На сколько я понимаю, теперь для встроенных решений можно не тянуть OpenSSL/LibreSSL, а использовать более компактную mbedTLS.

     
     
  • 3.24, Аноним (19), 13:31, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен.

    CD/DVD Болванки умеет прожигать?

     
     
  • 4.29, A.Stahl (ok), 14:43, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    В нём даже пасьянса нет, какие болванки?
     
     
  • 5.56, Аноним (56), 08:56, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В нём даже пасьянса нет, какие болванки?

    И директикс не ставит. Не то что неро!

     
  • 4.30, Аноним (30), 14:47, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > CD/DVD Болванки умеет прожигать?

    Какой неугомонный анонимчик. Неудачные выходные?

     
  • 4.38, anonymous (??), 17:41, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > CD/DVD Болванки умеет прожигать?

    Не настолько хорошо, как ты табуретки.

     
  • 3.34, Stax (ok), 15:28, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами? Более того, оно даже libssh готово подтянуть туда же для проигрывания через ssh: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/libssh.c

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

    Далеко ходить не надо, https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html - что совершенно неудивительно с учетом того, что форматов там реально ОЧЕНЬ много, пишут их куча людей, в т.ч. студенты и далеко не все достаточным образом проверено на безопасность - их тесты в целом требуют только эталонного разбора и декодирования форматов. И в этот же код, эти же библиотеки суют HTTP, TLS, RTP, SSH и прочее.. Этому место снаружи, как минимум в коде, который не является общим с демуксером (если уж авторам ffmpeg так хочется дать готовые библоитеки для работы с сетью).

     
     
  • 4.36, Аноним (36), 16:41, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Эту "хитрую работу со всеми возможными сетевыми протоколами" по-любому кто должен будет делать. Так пусть её делает кто-то из команды ffmpeg, совместно и согласованно с остальной командой ffmpeg.
     
     
  • 5.41, Stax (ok), 20:42, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью в одну библиотеку?
     
     
  • 6.50, Аноним (-), 08:20, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью
    > в одну библиотеку?

    Может потому что демукс протокола от демукса файла не так уж принципиально отличается? А в каком-нибудь HLS и DASH так еще одно завязано на другое и гораздо плотнее чем может показаться.

    Например половина смысла оных: если видно что сеть или что там еще не тянут текущий поток, при запросе очередного куска разрешение видео плавно даунгрейдится до того что фактически пролезает и прожевывается. Прозрачно для юзера и даже в рамках обычного HTTP(S). И вот это требует от декодера осознать проблемы и сообщить уровню выше что мы хотим другой кусок стрима, с другим разрешением. И как бы если оно будет в совсем разных либах, то удачи, конечно, но...

     
     
  • 7.62, Stax (ok), 13:53, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для разбора которых требуются хитрые манипуляции байтами с реализацией на C (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который умеет ходить по ssh не должны совмещаться. И тем более этого не должно происходить в одной библиотеке, которую потом подключает все кому не лень. И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью - но этот код разом оказывается во всех этих приложениям.

    Ходить в сеть "прозрачно для юзера", как вы пишете, в т.ч. по ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, не вижу смысла обсуждать это с вами дальше.

    Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop (я может там в приватном чате пароль к архиву кидаю, а оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, ему можно передать URL и тп) и т.п.

     
     
  • 8.67, пох (?), 20:04, 08/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    с каких пор ffmpeg вам что-то должен вам уже разжевали куча форматов видео _... текст свёрнут, показать
     
     
  • 9.70, Stax (ok), 23:25, 09/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Он должен не мне, а своим пользователям с точки зрения здравого смысла Хотя бы ... текст свёрнут, показать
     
     
  • 10.71, Mihail Zenkov (ok), 12:06, 10/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    1 ffmpeg лазит не сам, а через openssl openssh Если этим будет заниматься кто-... текст свёрнут, показать
     
     
  • 11.73, пох (?), 13:18, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого по... текст свёрнут, показать
     
  • 11.75, Аноним (75), 00:54, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас еще DASH актуален В нем ютуб вещает, да и остальные веб-сервисы видео в ... текст свёрнут, показать
     
  • 10.72, пох (?), 13:15, 12/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    у него, к счастью, нет пользователей в вашем смысле Ну то есть есть некоторое... текст свёрнут, показать
     
  • 8.74, Аноним (75), 00:50, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А на чем еще реализовывать критичный к скорости код Безопасность там кстати здо... текст свёрнут, показать
     
  • 4.43, Аноним (43), 00:10, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что круг использования ffmpeg плеерами не ограничивается (более того, обычно он напрямую в плеерах не используется).
     
  • 4.64, Ordu (ok), 14:17, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами?

    Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать и вовремя отрендерить. Если у нас временной лаг на чтении, то это выльется в лаги на экране. Эти проблемы можно решать generic способом включая буферизацию на несколько секунд вперёд, но это приведёт к задержке в несколько секунд (что может быть существенно в каких-то сценариях использования), и к перерасходу памяти. ffmpeg идёт другим путём, он использует стратегии чтения наилучшим образом подходящие для носителя: если мы читаем с жёсткого диска, то достаточно иметь небольшой кеш упреждающего чтения, если мы читаем по сети, то... тут я чесслово не знаю какого масштаба усложнения начинаются, но если предполагать по максимуму, то надо договориться с передающей стороной о том, как много мы хотим читать вперёд, какого размера кусками, как долго ждать до повторной передачи куска, в случае отсутствия подтверждения о получении, надо получая эти куски правильно их переупорядочивать,... большую часть этого на себя берёт стек tcp/ip, но стеку ведь можно подсказать как лучше действовать в данной ситуации.

    Но вообще может быть любопытной задачей создание какого-нибудь внятного API между декодером и reader'ом, которое позволило бы разнести их по разным адресным пространствам, сохранить гибкость системы при подстройке к конкретной ситуации, не потерять в производительности, и не столкнуться при этом с проблемой breaking changes в каждой минорной версии этого API. Если ты такой умный, как выглядишь, то займись этим -- разнеси код ffmpeg на два процесса и создай API между ними.

     
     
  • 5.76, Аноним (75), 00:57, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать
    > и вовремя отрендерить.

    Более того - вся логика DASH сводится к тому что если это не получилось, следующий сегмент будет взять с более паршивым качеством. Автоматически. Так что у юзера видео по сети будет такое, какое его железо и сети реально способны прожевать. А не так что мы тут пытаемся 10-мегабитный поток впихивать в несчастного GPRSника до упора, а тот смотрит его рывками по 3 секунды каждые полчаса.

     
     
  • 6.79, Ordu (ok), 03:58, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, спасибо за пример. Очень показательно. Я сам не могу приводить примеров, ибо не в теме вообще, рассуждаю из самых общих соображений.
     
  • 2.37, ттт (?), 17:16, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ffmpeg не работает с TLS, это делает сторонная библиотека, которой пользуется ffmpeg.
     
     
  • 3.39, Stax (ok), 17:50, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ясен пень, что алгоритма шифрования там нет. Но все-таки это именно библиотека с демуксерами форматов (libavformat) работает с TLS: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls.c https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls_gnutls.c https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls_openssl.c
     
     
  • 4.57, Аноним (56), 08:57, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Было бы странно если бы он умеючи HTTPSные урлы не умел бы TLS :)
     
  • 2.47, Аноним (-), 08:13, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А зачем это в наборе мультимедиа-библиотек?

    Затем что ffmpeg и прочие ffplay умеют видео не только локально из файлов, но и по сети. Включая http(s). Сюрприз.

     

  • 1.2, Аноним (2), 11:23, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный  

    сколько лет работы 4-ядерного проца потребуется, чтобы закодировать в нем 10-минутный ролик?

     
     
  • 2.9, Аноним (9), 12:11, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    В апреле этого года 1 секунда 1080p кодировалась 5 часов. Сейчас ситуация изменилась, но ненамного - результаты тестов широкой публике особо не представляются.
    По сути AV1 становится вторым вейландом. Он вот-вот будет готов, чтобы вытеснить все прочие кодеки. Вот еще чуть-чуть. Уже совсем скоро... Его даже начали поддерживать браузеры. То есть не то чтобы начали... Но скоро начнут.
     
     
  • 3.13, Crazy Alex (ok), 12:41, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Добавим данных маленько.
    Вот, например, на Ryzen 1700x скорость кодирования 0.2 fps для FullHD со средней нагрузкой на проц 50% - https://www.reddit.com/r/AV1/comments/9afr5d/my_1700x_encoding_speed_results_m - это августовская статья, что с тех времён изменилось (и изменилось ли) - понятия не имею.

     
  • 3.15, Crazy Alex (ok), 12:53, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот ещё ссылочка - если коротко, то он здорово улучшился и в прицнипе уже на живой похож. http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=127956&Page - в 10 раз медленнее vp9 на сжатии - пытаться что-то делать уже можно.
     
     
  • 4.20, Mihail Zenkov (ok), 13:25, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При равных опциях (cpu-used=0) разница в 40 раз. Разница уменьшается до 10 раз при cpu-used=2 у av1 и cpu-used=0 у vp9.

    Если я правильно понял, то при увеличении cpu-used падает качество, так что не понятно, будет ли av1 при таком подходе существенно лучше сжимать, чем vp9.

    Вообще как ни крути, а все равно очень медленно, особенно в сравнении с h264.

     
     
  • 5.52, Аноним (-), 08:38, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Большинство оптимизаций идет в cpu-used 1, 0 для перфекционистов, которым ЛЮБОЙ... текст свёрнут, показать
     
  • 3.51, Аноним (-), 08:23, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В апреле этого года 1 секунда 1080p кодировалась 5 часов.

    BBB в 480p целиком за ночь кодируется в 4 потока, speed = 1..3. Это не самый гламурный 0, но тоже весьма ничего.

    > результаты тестов широкой публике особо не представляются.

    Они меняются по три раза на дню. И при том - в правильную сторону.

    > То есть не то чтобы начали... Но скоро начнут.

    В смысле? Хромиум его просто берет и играет. Гугля за словом и делом в карман не лезет - вкомитили и включили.

     
     
  • 4.65, Аноним (65), 14:49, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Кому нужны результаты сжатия в 480p в 2018? Пиарщикам? Типа, "посмотрите, как все здорово, обработка не занимает две недели... правда, это справедливо только для sd качества". С тем же успехом можно хвалиться скоростью сжатия видео в 240p.
    Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать, что это прорыв технологий и будущее. Анон выше уже сравнил этот "прорыв" с вяленым, который лет 10 все никак не достигнет готовности.
     
     
  • 5.68, Аноним (68), 09:18, 09/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.
     
     
  • 6.78, Аноним (-), 01:13, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.

    А еще ему 480p не нравится, видите ли. А пусть этот умник попробует для начала сохранить себе на винч нежатый YUV в 1080p и посмотрит сколько это весит и какая там скорость потока, чтоли. Тогда узнает почему "лайтовые" забеги на посмотреть как вообще кодек были в 480p.

     
  • 5.77, Аноним (-), 01:06, 19/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В 500 кбитах то Тем кто мувик по сети будет смотреть на дохлом канале, например... текст свёрнут, показать
     

  • 1.4, Олег (??), 11:32, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    С версии 3.4 до версии 4.0 скорость в наших тестах возрасла в два раза
    Gpu h264
    Нужно тестить 4.1)
     
     
  • 2.21, Аноним (19), 13:25, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    В версии 4.1 упала в три.
     
     
  • 3.28, Олег (??), 14:10, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проверяли?
     
     
  • 4.45, Аноним (45), 07:53, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это клоуны пишут
     

  • 1.6, h31 (ok), 11:52, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Расскажите, чем сейчас в Линуксе можно восстановить цифровую копию с VHS-пленки? Даже не для качества, а чтобы весь этот шум и дребезг не увеличивали размер закодированного файла.
     
     
  • 2.7, Ivan_83 (ok), 11:58, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда у тебя будет больше мыла.
    Если совсем руками то OpenCV и самому ручками, всякие готоые фильтры можно через сабж поприменять.
     
  • 2.18, Kido Katsuragi (?), 13:24, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    http://www.vapoursynth.com/
     
  • 2.53, Аноним (-), 08:45, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > не для качества, а чтобы весь этот шум и дребезг не
    > увеличивали размер закодированного файла.

    Да тем же сабжем и восстановить, делая не просто кодирование а еще и -vf=<денойзер_по_вкусу>. Который из них на VHS лучше работает - черт бы его знает, но очень зашумленное видео с мобилы в темноте удалось окультурить очень даже. Я даже и не думал что там столько информации и что оно так хорошо восстановится.

     

  • 1.12, Андрей (??), 12:30, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Для фильтров на основе методов глубинного машинного обучения (DNN), таких как srcnn (Super-Resolution Convolutional Neural Network), подготовлен новый бэкенд на основе libtensorflow;

    Похоже, скоро можно будет удобненько нейронно-автоматически раскрашивать ч/б видео, используя софт из недавней новости: https://www.opennet.ru/opennews/art.shtml?num=49550
    :)

     
  • 1.16, guest34567 (ok), 13:06, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нигде внятно не нашел, как прикрутить IntelQuickSync для сжатия H264 на FreeBSD
     
     
  • 2.22, Аноним (19), 13:26, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Спроси на канале #Anime
     
  • 2.25, Аноним (25), 13:35, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://unrelenting.technology/articles/freebsd-on-the-thinkpad-x240

    https://www.freshports.org/multimedia/ffmpeg/
    BEIGNET=off: DRM/VAAPI to OpenCL mapping for i965 + Beignet

    https://trac.ffmpeg.org/wiki/Hardware/QuickSync
    https://trac.ffmpeg.org/wiki/Hardware/VAAPI

     
     
  • 3.42, guest2222 (?), 00:05, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а если нет Х-ов на сервере? какие пакеты еще доставлять? Добавил BEIGNET, скомпилил. При запуске вылетает с ошибкой:
    [AVHWDeviceContext @ 0x80cc1b080] No VA display found for device: /dev/dri/renderD128.
    Device creation failed: -22.
    [h264 @ 0x80cc17e00] No device available for decoder: device type vaapi needed for codec h264.

    kldstat:
    1   47 0xffffffff80200000 20647f8  kernel
    2    1 0xffffffff82266000 381080   zfs.ko
    3    2 0xffffffff825e8000 a380     opensolaris.ko
    4    3 0xffffffff825f3000 44d70    ipfw.ko
    5    2 0xffffffff82638000 13850    libalias.ko
    6    1 0xffffffff8264c000 61a8     ipfw_nat.ko
    7    1 0xffffffff82653000 253a0    dummynet.ko
    8    1 0xffffffff82b11000 7a2b8    i915kms.ko
    9    1 0xffffffff82b8c000 3f8cc    drm2.ko
    10    4 0xffffffff82bcc000 1ed0     iicbus.ko
    11    1 0xffffffff82bce000 e58      iic.ko
    12    1 0xffffffff82bcf000 1570     iicbb.ko

     
     
  • 4.54, Аноним (56), 08:53, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а если нет Х-ов на сервере? какие пакеты еще доставлять?

    Кишки MESA - va-drivers для MESA, libdrm и плагин к ней для конкретного gpu. Как это в бзде называется и есть ли отличия - логично где-то в их вике смотреть.

    И список модулей прекрасно, но на нем одном вы далеко не уедете. FFmpeg как бы не будет вызывать напрямую ядерный модуль, или где?!

     
  • 2.27, Олег (??), 14:09, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Собрать пакет;)
     

  • 1.17, АнонимЪ (?), 13:21, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Такой большой объём изменений каждый выпуск, а кто спонсирует разработку?
     
     
  • 2.35, Аноним (35), 16:11, 06/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну во всяком случае не мы...(с)
     
  • 2.44, Андрей (??), 05:57, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Список более менее похож на Just-for-Fun, т.е. основные разработчки устроены в типа нон-профит организациях и получают зарплату (и удовольствие), а остальные получают только удовольствие, и вообще им была оказана честь, что их патчи приняли. Вот если бы какие-то ошибки были исправлены! Что даже за деньги не хочется делать.
     

  • 1.23, Вот оно че (?), 13:27, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Недавно откопал 15 летний КПК Dell Axim X5(320х240, CPU 300MHz). Полностью исправный, даже акк не деградировал. Отдал ребенку баловаться. А там еще флеха 2Gb. Думаю, дай-ка попробую погонять видео на нем.

    Перекодировал ffmpeg'ом под разрешение экрана, mpeg4, видео поток 128Кб/сек, звук 22050, моно. 1 час видео ~70Мб. Тянет норм, качество картинки удовлетворительное.

    Добавил в контекстное меню Thunar'а пункт для перекодировки .avi файлов. Красота!

     
  • 1.40, Андрей (??), 19:00, 06/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия; ---пффф, пока единственное что у этого av1 заметно, причем очень и очень сильно, то только то что он на corei7 слайд шоу показывает. а уж про то что на этом же corei7 что то пожать попытаться, в этот av1 я вообще не говорю даже, так как боюсь к моему пенсионному возрасту едва первый фильм только конвертироваться закончится, да и то не факт что вообще до этого момента получиться дожить. аппаратного декодинга нет, и не предвидится, а в софте такое непотребство ну ненужно совершенно.
     
     
  • 2.60, нах (?), 10:37, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    gpu декодер будет (ну, как обычно, не в линуксе), надо же как-то продвигать более мощные видеокарты, майнеры что-то подустали.

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

     

  • 1.46, Аноним (46), 08:04, 07/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?
     
     
  • 2.55, Аноним (56), 08:55, 07/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?

    А это надо было багрепорт ДО релиза писать наверное. Можно и после, конечно, но тогда вот так.

     
  • 2.69, Аноним (59), 10:30, 09/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Написать аппле, все как вы любите.
     

  • 1.58, iZEN (ok), 09:53, 07/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На FreeBSD прилетел ffmpeg-4.1. Теперь в браузере Firefox на сайте Youtube нельзя выставить разрешение видео больше 720p. В "Статистике для сисадминов" используются кодеки: avc1.64001F, mp4a.40.2. При этом дропнутых кадров 2,5%!
     
  • 1.61, Аноним (61), 11:35, 07/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сергей Шаблин(Blender dev) недавно сказал, что еще Intel делает какие-то оптимизации для FFMPEG(ну и для Blender тоже) под новые процы. Этих оптимизаций здесь нет или про такие вещи не пишут в новостях?
     
     
  • 2.66, Олег (??), 18:52, 08/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Libx264 затачивается под avx-512
    Правда уже года два пилят
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру