После шести месяцев разработки доступен (http://ffmpeg.org/download.html#release_4.1) мультимедиа-пакет FFmpeg 4.1 (http://ffmpeg.org/), включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer (http://www.mplayerhq.hu/).Из изменений (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES... добавленных (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;hb=... в FFmpeg 4.1, можно выделить:
- Добавлена возможность использования формата кодирования видео AV1 в контейнерах MP4 и реализован парсер для AV1. AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия;
- Добавлена поддержка реализации TLS на базе библиотеки mbedTLS (https://tls.mbed.org/);
- Новые кодировщики и декодировщики:- Декодировщик формата кодирования звука Sony ATRAC9 (https://en.wikipedia.org/wiki/Adaptive_Transform_Acoustic_Co... (Adaptive Transform Acoustic Coding);
- Кодировщик и декодировщик формата сжатия звука и видео AVS2 (https://en.wikipedia.org/wiki/Audio_Video_Standard), стандартизированного в Китае. Реализация основана на библиотеке libdavs2;
- Декодировщик для звукового кодека iLBC (https://en.wikipedia.org/wiki/Internet_Low_Bitrate_Codec) (Internet Low Bitrate Codec), оптимизированного для передачи голоса по низкоскоростным каналам связи;
- Кодировщик и декодировщик для звукового кодека pcm vidc (https://github.com/multipath-tcp/mptcp_3.12.x/blob/master/so...- Декодировщик для видеокодека IMM4;
- Декодировщик для формата кодирования видео Brooktree ProSumer;
- Декодировщик для формата WinCam Motion Video;
- Декодировщик для форматов MatchWare Screen Capture и RemotelyAnywhere Screen Capture, используемых при записи содержимого экрана;- Для формата h264 реализовна поддержка декодирования таймкода S12M;
- Представлен распаковщик (demuxer) медиаконтейнеров SER;
- В декодировщике vc1 задействован алгоритм bit-exact;- Новые фильтры (https://ffmpeg.org/ffmpeg-filters.html):
- deblock (https://ffmpeg.org/ffmpeg-filters.html#deblock) - удаление блочных артефактов из видео;
- tmix (https://ffmpeg.org/ffmpeg-filters.html#tmix) - смешивание следующих друг за другом видеокадров;
- amplify (https://ffmpeg.org/ffmpeg-filters.html#amplify) - усиление разницы между текущим пикселем и пикселями в том же месте из соседних кадров;- fftdnoiz (https://ffmpeg.org/ffmpeg-filters.html#fftdnoiz) - подавление шума в кадрах при помощи фильтра 3D FFT (frequency domain filtering);
- aderivative и aintegral (https://ffmpeg.org/ffmpeg-filters.html#aderivative_002c-aint... - вычисление производной и интеграла для звукового потока. Применение одного фильтра после другого позволяет восстановить оригинальный звуковой поток;- pal75bars и pal100bars (https://ffmpeg.org/ffmpeg-filters.html#allrgb_002c-allyuv_00... -
генерирует цветовые шаблоны на основе рекомендаций EBU PAL с 75% и 100% уровнем цвета;- adeclick (https://ffmpeg.org/ffmpeg-filters.html#adeclick) - удаление импульсных помех из звукового потока, которые заменяются на интерполированные сэмплы, используя авторегрессионное моделирование (https://ru.wikipedia.org/wiki/%D0%90%D0%...
- adeclip (https://ffmpeg.org/ffmpeg-filters.html#adeclip) - заменяет повреждённые сэмплы при помощи авторегрессионного моделирования (https://ru.wikipedia.org/wiki/%D0%90%D0%...
- lensfun (https://ffmpeg.org/ffmpeg-filters.html#lensfun) - корректирует вносимые объективом искажения, используя библиотеку lensfun (http://lensfun.sourceforge.net/);
- colorconstancy - корректирует цвет объектов в зависимости от цвета освещения;
- lut1d (https://ffmpeg.org/ffmpeg-filters.html#lut1d) - применение цветового преобразования 1D LUT к видео;
- cue (https://ffmpeg.org/ffmpeg-filters.html#cue-1) и acue (https://ffmpeg.org/ffmpeg-filters.html#acue) - задержка применения фильтров к видео или звуку до наступления указанной временной метки (позиции в потоке);- transpose_npp (https://ffmpeg.org/ffmpeg-filters.html#transpose_005fnpp) - перестановка местами строк и столбцов в видео;
- amultiply (https://ffmpeg.org/ffmpeg-filters.html#amultiply) - объединение двух звуковых потоков;
- bm3d (https://ffmpeg.org/ffmpeg-filters.html#bm3d) - подавление шумов в кадрах при помощи алгоритма Block-Matching 3D;
- acrossover (https://ffmpeg.org/ffmpeg-filters.html#acrossover) - разделение звукового потока с разбивкой по частотным диапазонам;
- afftdn (https://ffmpeg.org/ffmpeg-filters.html#afftdn) - подавление шума в звуковом потоке при помощи быстрого преобразования Фурье (FFT);- graphmonitor и agraphmonitor (https://ffmpeg.org/ffmpeg-filters.html#graphmonitor_002c-agr... - отображения различной статистики работы видео и звуковых фильтров;
- yadif_cuda (https://ffmpeg.org/ffmpeg-filters.html#yadif_005fcuda) - устранение чересстрочности в видео, используя реализацию алгоритма yadif, ускоренную при помощи CUDA;
- xstack (https://ffmpeg.org/ffmpeg-filters.html#xstack) - совмещение нескольких видео (каждое видео показывается в своей области экрана);
- sinc (https://ffmpeg.org/ffmpeg-filters.html#sinc) - генерация коэффициентов FIR (https://en.wikipedia.org/wiki/Finite_impulse_response) для звукового потока;
- chromahold (https://ffmpeg.org/ffmpeg-filters.html#chromahold) - удаление информации о всех цветах за исключением указанного;
- setparams (https://ffmpeg.org/ffmpeg-filters.html#setparams-1) - установка параметров для кадра, влияющих на работу других фильтров и кодировщиков;
- vibrance (https://ffmpeg.org/ffmpeg-filters.html#vibrance) - увеличение или уменьшение цветовой насыщенности;
- Для фильтров на основе методов глубинного машинного обучения (DNN), таких как srcnn (https://ffmpeg.org/ffmpeg-filters.html#sr) (Super-Resolution Convolutional Neural Network), подготовлен новый бэкенд на основе libtensorflow (https://www.tensorflow.org/install/lang_c);
URL: http://ffmpeg.org/download.html#release_4.1
Новость: https://www.opennet.dev/opennews/art.shtml?num=49563
>TLSА зачем это в наборе мультимедиа-библиотек?
>>TLS
> А зачем это в наборе мультимедиа-библиотек?Потоковое вещание в шифрованием.
разве потоковое вещание не дело сервиса потокового вещания, а не мультимедиа-библиотеки?
Ffmpeg умеет работать сервисом потокового вещания.//К.О.
А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?
Авторизация для потокового вещания тоже доступна.
Судя по дислайкам - нет.
> А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?Гугель именно им ютуб кодирует, если не ошибаюсь. Поучи их видео кодировать, умник.
Что-что, а ффмпег в этом плане достаточно надежный. Люди(и я в тч) годами используют его для круглосуточного кодирования без проблем. Плохому танцору как говорится.
Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте
КЭП: Дабы организовывать закрытые трансляции.
> Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайтеДа даже обычный https - для защиты приватности, чтобы пров не собирал досье кто и что смотрел крупным оптом, например.
ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен.На сколько я понимаю, теперь для встроенных решений можно не тянуть OpenSSL/LibreSSL, а использовать более компактную mbedTLS.
>ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен.CD/DVD Болванки умеет прожигать?
В нём даже пасьянса нет, какие болванки?
> В нём даже пасьянса нет, какие болванки?И директикс не ставит. Не то что неро!
> CD/DVD Болванки умеет прожигать?Какой неугомонный анонимчик. Неудачные выходные?
> CD/DVD Болванки умеет прожигать?Не настолько хорошо, как ты табуретки.
Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами? Более того, оно даже libssh готово подтянуть туда же для проигрывания через ssh: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/lib...Это просто клиника какая-то, запредельный уровень наплевательства на безопасность. В библиотеку, которая занимается разбором бинарных данных кучи разных форматов с реализациями различной степени качества и потенциально кучей уязвимостей, тащить хитрую работу со всеми возможными сетевыми протоколами, которым можно это самое видео скачать?
Далеко ходить не надо, https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... - что совершенно неудивительно с учетом того, что форматов там реально ОЧЕНЬ много, пишут их куча людей, в т.ч. студенты и далеко не все достаточным образом проверено на безопасность - их тесты в целом требуют только эталонного разбора и декодирования форматов. И в этот же код, эти же библиотеки суют HTTP, TLS, RTP, SSH и прочее.. Этому место снаружи, как минимум в коде, который не является общим с демуксером (если уж авторам ffmpeg так хочется дать готовые библоитеки для работы с сетью).
Эту "хитрую работу со всеми возможными сетевыми протоколами" по-любому кто должен будет делать. Так пусть её делает кто-то из команды ffmpeg, совместно и согласованно с остальной командой ffmpeg.
Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью в одну библиотеку?
> Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью
> в одну библиотеку?Может потому что демукс протокола от демукса файла не так уж принципиально отличается? А в каком-нибудь HLS и DASH так еще одно завязано на другое и гораздо плотнее чем может показаться.
Например половина смысла оных: если видно что сеть или что там еще не тянут текущий поток, при запросе очередного куска разрешение видео плавно даунгрейдится до того что фактически пролезает и прожевывается. Прозрачно для юзера и даже в рамках обычного HTTP(S). И вот это требует от декодера осознать проблемы и сообщить уровню выше что мы хотим другой кусок стрима, с другим разрешением. И как бы если оно будет в совсем разных либах, то удачи, конечно, но...
Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для разбора которых требуются хитрые манипуляции байтами с реализацией на C (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который умеет ходить по ssh не должны совмещаться. И тем более этого не должно происходить в одной библиотеке, которую потом подключает все кому не лень. И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью - но этот код разом оказывается во всех этих приложениям.Ходить в сеть "прозрачно для юзера", как вы пишете, в т.ч. по ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, не вижу смысла обсуждать это с вами дальше.
Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop (я может там в приватном чате пароль к архиву кидаю, а оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, ему можно передать URL и тп) и т.п.
> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для
> разбора которых требуются хитрые манипуляции байтами с реализацией на C (и
> высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который
> умеет ходить по ssh не должны совмещаться.с каких пор ffmpeg вам что-то "должен"?
вам уже разжевали: куча форматов видео _в_принципе_ не существует в виде однозначного файла, точнее, где-то может этот файл и есть, но вам его не отдают.
И парсинг этих сетевых радостей ничем не отличается (и да, он такой же или еще менее надежный, нехрен мешать порно с конями с банковскими акаунтами).
> Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop
> (я может там в приватном чате пароль к архиву кидаю, ато есть вы уже слили свой пароль телеграмму (без всякого ssh, православнейшим вебом, и совершенно неотличимо от, скажем, авторизации самого телеграмма - можно даже для удобства в один пакет упаковать), но вас беспокоит только то, что он, _теоретически_возможно_, каким-то невероятным образом, утечет ssh'ем (ssh'ем! С риском уже подставить хост потенциального злоумышленника, вот уж глупее не придумать) ?
> оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264
x264 - совершенно самостоятельный проект, ffmpeg, наоборот, использует его кодек. Если включить.
> (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность
> ходить по сети как угодно, ему можно передать URL и тп)да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через еще один диск, а перекодировать на лету.
ну и вишенка на тортике: почти любые форматы, как и почти любые кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам собрать, конечно же, не умеет и не будет, ждет ебилдов.
>> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для
>> разбора которых требуются хитрые манипуляции байтами с реализацией на C (и
>> высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который
>> умеет ходить по ssh не должны совмещаться.
> с каких пор ffmpeg вам что-то "должен"?Он должен не мне, а своим пользователям с точки зрения здравого смысла. Хотя бы чтобы не быть насквозь уязвимым рещетом.
> вам уже разжевали: куча форматов видео _в_принципе_ не существует в виде однозначного
> файла, точнее, где-то может этот файл и есть, но вам его
> не отдают.Это редкие исключения, а не правила. И ниоткуда не следует, что работа с абстракцией "это находится не тут" должна быть там же, где разбор бинарного формата.
>> оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264
> x264 - совершенно самостоятельный проект, ffmpeg, наоборот, использует его кодек. Если
> включить.Да что вы говорите!
$ ldd `which x264`|grep libav
libavformat.so.58 => /lib64/libavformat.so.58 (0x00007fe0b585b000)
libavcodec.so.58 => /lib64/libavcodec.so.58 (0x00007fe0b4537000)
libavutil.so.56 => /lib64/libavutil.so.56 (0x00007fe0b44bd000)Что там использует ffmpeg дело десятое. А x264 как утилита командной строки это тулза для конвертации из <что-нибудь> в, собственно, сжатый H.264 поток. Они решили добавить фильтры и расширенные входные форматы. И ради этого линкуются с ffmpeg, в т.ч. libavformat, который любезно готов ходить по сети.
Мне вот категорически не нравится, когда то, что всегда было простым, надежным и безопасным локальным конвертером вдруг научилось лазить по сети куда не попадя. Этим должен заниматься кто-то другой. Не примитивная command-line обертка над библиотекой кодера. Но текущее состояние ffmpeg не дает такой возможности.
> да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через
> еще один диск, а перекодировать на лету.Ну идите в свою винду, пользуйтесь комбайнами. А я умею curl, пайпы, vfs и кучу других абстракций. Это юникс, тут так не принято - как минимум потому, что это небезопасно.
> ну и вишенка на тортике: почти любые форматы, как и почти любые
> кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам
> собрать, конечно же, не умеет и не будет, ждет ебилдов.А после этого придется пересобрать vlc, x264, telegram-desktop и кучу-кучу всего? Чтобы сделать систему чуточку безопаснее? Вот спасибо!
> Мне вот категорически не нравится, когда то, что всегда было простым, надежным
> и безопасным локальным конвертером вдруг научилось лазить по сети куда не
> попадя. Этим должен заниматься кто-то другой. Не примитивная command-line обертка над
> библиотекой кодера. Но текущее состояние ffmpeg не дает такой возможности.1. ffmpeg лазит не сам, а через openssl/openssh. Если этим будет заниматься кто-то другой, то почему это будет безопаснее?
2. ffmpeg поддерживает много всего, кроме ssh/https: async bluray cache concat crypto data ffrtmpcrypt ffrtmphttp file ftp gopher hls http httpproxy https icecast librtmp librtmpe librtmps librtmpt librtmpte libsmbclient libsrt libssh md5 mmsh mmst pipe prompeg rtmp rtmpe rtmps rtmpt rtmpte rtmpts rtp sctp srtp subfile tcp tee tls udp udplite
Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ? Как уже отмечали - не будут вещи типа hls работать нормально, если их реализовывать без связи с демуксером.
3. Текущий подход наоборот безопаснее: все плееры и прочий мультимедиа софт использует одну и ту же реализацию из ffmpeg - это упрощает сам софт (меньше кода, меньше багов) и позволяет быстрее выявлять/исправлять проблемы.
>> да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через
>> еще один диск, а перекодировать на лету.
> Ну идите в свою винду, пользуйтесь комбайнами. А я умею curl, пайпы,
> vfs и кучу других абстракций. Это юникс, тут так не принято
> - как минимум потому, что это небезопасно.Я сам ретроград и за unix way, но ffmpeg - правильный комбайн: он покрывает работу мультимедиа форматами, в том числе и с сетевыми, что здорово облегчает жизнь в наше время (практически все мы берем из сети).
>> ну и вишенка на тортике: почти любые форматы, как и почти любые
>> кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам
>> собрать, конечно же, не умеет и не будет, ждет ебилдов.
> А после этого придется пересобрать vlc, x264, telegram-desktop и кучу-кучу всего? Чтобы
> сделать систему чуточку безопаснее? Вот спасибо!Нет, собираете тот же ffmpeg, что и в системе, но с нужными вам опциями. Больше пересобирать ничего не нужно (если линковка была динамической). Можно собрать две версии ffmpeg - с сетью и без и подсовывать их софту через LD_PRELOAD в зависимости от задачи.
> Нет, собираете тот же ffmpeg, что и в системе, но с нужными вам опциями. Больше пересобирать
> ничего не нужно (если линковка была динамической).тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого поделочки могут оказаться с намертво embedded кривособранным.
Но он как раз _будет_ требовать сетевой и tls стек, иначе как же вы в телефсбграмм-десктопе будете видео-то передавать?
> Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ?Сейчас еще DASH актуален. В нем ютуб вещает, да и остальные веб-сервисы видео в основном на него переползают. Ну и ffmpeg резонно научили с ним работать. И на input и на output. Чтобы генерить серверам это, а потом как клиенту - жевать то что нагенерили.
> 3. Текущий подход наоборот безопаснее: все плееры и прочий мультимедиа софт использует
> одну и ту же реализацию из ffmpegВот именно. Обновить 1 либу с майнтайнерами которые в курсе политик безопасности - лучше чем 20 мелких, полузаброшенных, где автор чего доброго полагает что его супер-ЯП спасет от всего и вся, так что получается как у мозиллы с пдф и битмесаги с эвалом входных данных.
> Он должен не мне, а своим пользователяму него, к счастью, нет "пользователей" в вашем смысле.
Ну то есть есть некоторое количество странных людей, включая меня, использующих именно ffmpeg, но их единицы и они знают что делают, в основном.> Это редкие исключения, а не правила.
ffmpeg весь - "редкие исключения", а для "правила" вам вон av1 с единственно-верным кодеком положон.
То есть он почти весь - миллион странных форматов и кодеков, и именно ради них и пилится в настоящее время.> А x264 как утилита командной строки это тулза для конвертации из <что-нибудь> в, собственно,
> сжатый H.264 поток. Они решили добавить фильтры и расширенные входные форматы.ну и прекрасно - вот им и адресуйте свою попоболь, со словами что они добавили в том числе и https: в качестве формата (а может и quic заодно), и он очень, очень несекьюрно. Вдруг уговорите?
к счастью, я использую очень старую версию x264, поскольку никаких чудес в самом кодеке не жду, и меня эта проблема не беспокоит, тем более что использую ее как кодек для ffmpeg и не более. На мой век хватит, x264 не изменится завтра с выходом новой камеры.
> Мне вот категорически не нравится, когда то, что всегда было простым, надежным и безопасным
> локальным конвертеромвы просто не владеете темой, оно им не было со времен Белларда (да и тогда, вероятнее всего, могло нечаянно поисполнять подсунутый "видеофайл" как код, автора интересовали совершенно другие вещи)
эта штука всегда была сложной, с кучей особенностей применения. Одной из них, кстати, является возможность собрать ее так, как надо применяющему для его узкоспециального случая.
Но, боюсь у авторов x264 случай совсем не ваш - они не для того добавили в свою поделку libavformat, чтобы отрезать часть форматов - наоборот, именно для того и добавляли, чтобы форматы были.> А я умею curl, пайпы, vfs и кучу других абстракций.
а знаний не имеете. например, что для mse это все не очень поможет.
> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для
> разбора которых требуются хитрые манипуляции байтами с реализацией на CА на чем еще реализовывать критичный к скорости код? Безопасность там кстати здорово подтянули - гугель фуззит это добро непрерывно, так что баги чинятся еще до того как их хакеры найдут. И если кто считает что его парсеры валидируются лучше - на честное слово мы ему таки не поверим, пусть делом докажет. Реализовав столько же парсинга с производительностью не хуже и безопаснее. Тогда будет разговор.
> (и высокими рисками каких-либо уязвимостей, что подтверждается практикой)
Практика сейчас такова что там continious fuzzing и куча тестов вылавливают в парсерах самые чудесатые баги.
> и код, который умеет ходить по ssh не должны совмещаться.
Очень интересный вывод. Наверное, уровень экспертизы такой же как и с безопасностью.
> И тем более этого не должно происходить в одной библиотеке, которую потом подключает
> все кому не лень.А может быть, правильный ответ - в том что эта библиотека все-же должна стать безопасной? И таки в этом направлении они хорошо подвинулись, нарулив фуззинг и тесты оптом.
Если кто думает что может лучше - пусть придет и покажет, вместо разглагольствований о том что, чему и сколько "должен". Вас никто не заставляет пользоваться этими библиотеками вообще. А то что там парсеров дофига и в них баги случаются - да, человечество придумало дофига форматов и протоколов. Некоторые из них даже навороченные и без багов их все реализовать может быть нетривиально. Но наверное в этом не ffmpeg виноват. И даже более того - лажа будет и с другими ЯП и проч.
> И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью
> - но этот код разом оказывается во всех этих приложениям.И, собственно, чего? Поэтому предлагается нагнуть тех кто все-таки хочет какое-нибудь потоковое аудио и видео? Так не пойдет.
> ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это
> очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете,
> не вижу смысла обсуждать это с вами дальше.У меня ffmpeg сможет вылезти в сеть только очень гранулярно, контролируемо и тогда когда я этого явно захочу. И вот тогда мне будет вполне удобно и хорошо. Поговорите еще со мной о безопасности, мистер эксперт.
> Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop
Пардон, он без сети бесполезен чуть более чем полностью.
> (я может там в приватном чате пароль к архиву кидаю,И чего? Там еще и кутя мегов на сто кода. При том это не какие-то парсеры которые фуззером можно прозвонить а круто абстрагированные плюсы, на синтаксическом анализе которых спятит что угодно. Туда же и пихтонр@сты всякие, кстати - там вообще безопасность по методу неуловимого Джо. Когда Джо начинает шуметь, у него находят eval() на входных данных вообще, как в bitmessage (который в отличие от телеги еще и явно пиарился как такой из себя весь секурный, а достаточно то всего разик посмотреть в тот код, чтобы оценить чего ждать от этих кодеров).
> а оно мне это куда-нибудь по ssh?..),
Оно по ssh будет ломиться только если программа об этом явно попросит. И если твой телеграм уже поимели настолько что он просит либу сходить по ssh - жалкие потуги обрубить фичу в либе тебя явно не спасут, о великий спец по безопасности.
> HandBrake-gui (обертка для конвертации), x264
> (тупо конвертер и файлика в файлик!!Так они и не вызывают функций работающих с сетью. Если стремно можно в контейнер вообще засунуть.
> И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно,
> ему можно передать URL и тп) и т.п.А вот это еще не факт. Впрочем, если handbrake сможет транскодинг сразу с урлы - да это вообще пожалуй фича а не баг.
Потому что круг использования ffmpeg плеерами не ограничивается (более того, обычно он напрямую в плеерах не используется).
> Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами?Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать и вовремя отрендерить. Если у нас временной лаг на чтении, то это выльется в лаги на экране. Эти проблемы можно решать generic способом включая буферизацию на несколько секунд вперёд, но это приведёт к задержке в несколько секунд (что может быть существенно в каких-то сценариях использования), и к перерасходу памяти. ffmpeg идёт другим путём, он использует стратегии чтения наилучшим образом подходящие для носителя: если мы читаем с жёсткого диска, то достаточно иметь небольшой кеш упреждающего чтения, если мы читаем по сети, то... тут я чесслово не знаю какого масштаба усложнения начинаются, но если предполагать по максимуму, то надо договориться с передающей стороной о том, как много мы хотим читать вперёд, какого размера кусками, как долго ждать до повторной передачи куска, в случае отсутствия подтверждения о получении, надо получая эти куски правильно их переупорядочивать,... большую часть этого на себя берёт стек tcp/ip, но стеку ведь можно подсказать как лучше действовать в данной ситуации.
Но вообще может быть любопытной задачей создание какого-нибудь внятного API между декодером и reader'ом, которое позволило бы разнести их по разным адресным пространствам, сохранить гибкость системы при подстройке к конкретной ситуации, не потерять в производительности, и не столкнуться при этом с проблемой breaking changes в каждой минорной версии этого API. Если ты такой умный, как выглядишь, то займись этим -- разнеси код ffmpeg на два процесса и создай API между ними.
> Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать
> и вовремя отрендерить.Более того - вся логика DASH сводится к тому что если это не получилось, следующий сегмент будет взять с более паршивым качеством. Автоматически. Так что у юзера видео по сети будет такое, какое его железо и сети реально способны прожевать. А не так что мы тут пытаемся 10-мегабитный поток впихивать в несчастного GPRSника до упора, а тот смотрит его рывками по 3 секунды каждые полчаса.
Да, спасибо за пример. Очень показательно. Я сам не могу приводить примеров, ибо не в теме вообще, рассуждаю из самых общих соображений.
ffmpeg не работает с TLS, это делает сторонная библиотека, которой пользуется ffmpeg.
Ясен пень, что алгоритма шифрования там нет. Но все-таки это именно библиотека с демуксерами форматов (libavformat) работает с TLS: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls.c https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls... https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/tls...
Было бы странно если бы он умеючи HTTPSные урлы не умел бы TLS :)
> А зачем это в наборе мультимедиа-библиотек?Затем что ffmpeg и прочие ffplay умеют видео не только локально из файлов, но и по сети. Включая http(s). Сюрприз.
>AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступныйсколько лет работы 4-ядерного проца потребуется, чтобы закодировать в нем 10-минутный ролик?
В апреле этого года 1 секунда 1080p кодировалась 5 часов. Сейчас ситуация изменилась, но ненамного - результаты тестов широкой публике особо не представляются.
По сути AV1 становится вторым вейландом. Он вот-вот будет готов, чтобы вытеснить все прочие кодеки. Вот еще чуть-чуть. Уже совсем скоро... Его даже начали поддерживать браузеры. То есть не то чтобы начали... Но скоро начнут.
Добавим данных маленько.
Вот, например, на Ryzen 1700x скорость кодирования 0.2 fps для FullHD со средней нагрузкой на проц 50% - https://www.reddit.com/r/AV1/comments/9afr5d/my_1700x_encodi.../ - это августовская статья, что с тех времён изменилось (и изменилось ли) - понятия не имею.
Вот ещё ссылочка - если коротко, то он здорово улучшился и в прицнипе уже на живой похож. http://www.streamingmedia.com/Articles/ReadArticle.aspx?Arti... - в 10 раз медленнее vp9 на сжатии - пытаться что-то делать уже можно.
При равных опциях (cpu-used=0) разница в 40 раз. Разница уменьшается до 10 раз при cpu-used=2 у av1 и cpu-used=0 у vp9.Если я правильно понял, то при увеличении cpu-used падает качество, так что не понятно, будет ли av1 при таком подходе существенно лучше сжимать, чем vp9.
Вообще как ни крути, а все равно очень медленно, особенно в сравнении с h264.
> При равных опциях (cpu-used=0) разница в 40 раз. Разница уменьшается до 10
> раз при cpu-used=2 у av1 и cpu-used=0 у vp9.Большинство оптимизаций идет в cpu-used=1, =0 для перфекционистов, которым ЛЮБОЙ ценой. На 1..3 качество не так уж сильно рушится, вот скорость растет заметно.
> Если я правильно понял, то при увеличении cpu-used падает качество, так что
> не понятно, будет ли av1 при таком подходе существенно лучше сжимать, чем vp9.Будет, он на cpu-used = 1...3 стабильно втыкает VP9 со всеми наворотами. Зажмите какой-нибудь кусок и посмотрите на хотя-бы PSNR. А лучше - картинку!
Я BBB@480p (нежатый) на 500 кбит использую как "бенчмарк". Ну и потом посмотреть на "трудные" места.
- Начальный fade in у VP9 заметно угловатее и дискретизованнее. В движении не видно, но если стопкадры простепать, хотя-бы "s" в ffplay...
- Там где в начале мувика блестит речка, VP9 при таком битрейте в принципе не может сделать блеск речки без квадратов. AV1 всех грамотно надувает, видимо CDEF'ом - выглядит отлично.
- Там где птиц машет крыльями - кодеки напрягаются на кодирование этого. Ну и в режиме стопкадра прекрасно видно кто есть кто. В динамике не особо видно, но если степать покадрово - разница весьма даже. А когда птиц потом падает и в кадре порхает перо, можно сравнить границы пера (резкая граница неудобна для DCT-like by design).
- Там где название мувика появляется, VP9 напрягается по битрейту, часть картинки ощутимо тянется за названием мувика - на апдейт макроблоков с бандвизом душняк. AV1 этим почти не страдает.
- Там где на мыша падает камень и бревно, сцены очень интенсивные, битрейта не хватает. И вот там прекрасно видно кто есть кто. Опять же в движении менее заметно если не знать что искать.
- Титры. Они там сделаны так что обламывают вообще все мыслимые кодеки. Но некоторых они обламывают значительно меньше чем других. AV1 это делает лучше всех остальных вместе взятых. Хоть и не идеально.> Вообще как ни крути, а все равно очень медленно, особенно в сравнении с h264.
Как ни крути а h264 из 480p bbb делает полное гуано! А так то и XVID жмет быстро, но вот битрейта ему надо для хорошей картинки явно не столько.
> В апреле этого года 1 секунда 1080p кодировалась 5 часов.BBB в 480p целиком за ночь кодируется в 4 потока, speed = 1..3. Это не самый гламурный 0, но тоже весьма ничего.
> результаты тестов широкой публике особо не представляются.
Они меняются по три раза на дню. И при том - в правильную сторону.
> То есть не то чтобы начали... Но скоро начнут.
В смысле? Хромиум его просто берет и играет. Гугля за словом и делом в карман не лезет - вкомитили и включили.
Кому нужны результаты сжатия в 480p в 2018? Пиарщикам? Типа, "посмотрите, как все здорово, обработка не занимает две недели... правда, это справедливо только для sd качества". С тем же успехом можно хвалиться скоростью сжатия видео в 240p.
Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать, что это прорыв технологий и будущее. Анон выше уже сравнил этот "прорыв" с вяленым, который лет 10 все никак не достигнет готовности.
Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.
> Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.А еще ему 480p не нравится, видите ли. А пусть этот умник попробует для начала сохранить себе на винч нежатый YUV в 1080p и посмотрит сколько это весит и какая там скорость потока, чтоли. Тогда узнает почему "лайтовые" забеги на посмотреть как вообще кодек были в 480p.
> Кому нужны результаты сжатия в 480p в 2018? Пиарщикам?В 500 кбитах то? Тем кто мувик по сети будет смотреть на дохлом канале, например.
> С тем же успехом можно хвалиться скоростью сжатия видео в 240p.
Бандвиз жрется и на 240p и на 1080p. Так что плотно сжать важно и тех и других. Кстати на HD экономия бандвиза еще эпичнее получается. А скорость - оптимизируют не по дням а по часам. Вот там китаец. В августе он начал с времени кодирования тестового куска 600000+ миллисекунд. Сейчас в его же комитах цифры типа 149000 фигурируют.
> Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать,
"Release early, release often" :)
> что это прорыв технологий и будущее.И таки мне оно нравится - жмет очень плотно. При том у меня нет кластеров как у гугли, я это на обычном компе пережал. А в x264 на тех же 500 кбит получается мутное гуано. А если видео сделать с битрейтом выше - нет, конечно, я и мпег2 зажать могу, так что плевый мувик который в av1 весит 35 мегов на все - станет размером под гиг наверное. А оно мне такое надо?
С версии 3.4 до версии 4.0 скорость в наших тестах возрасла в два раза
Gpu h264
Нужно тестить 4.1)
В версии 4.1 упала в три.
Проверяли?
Это клоуны пишут
Расскажите, чем сейчас в Линуксе можно восстановить цифровую копию с VHS-пленки? Даже не для качества, а чтобы весь этот шум и дребезг не увеличивали размер закодированного файла.
Тогда у тебя будет больше мыла.
Если совсем руками то OpenCV и самому ручками, всякие готоые фильтры можно через сабж поприменять.
http://www.vapoursynth.com/
> не для качества, а чтобы весь этот шум и дребезг не
> увеличивали размер закодированного файла.Да тем же сабжем и восстановить, делая не просто кодирование а еще и -vf=<денойзер_по_вкусу>. Который из них на VHS лучше работает - черт бы его знает, но очень зашумленное видео с мобилы в темноте удалось окультурить очень даже. Я даже и не думал что там столько информации и что оно так хорошо восстановится.
> Для фильтров на основе методов глубинного машинного обучения (DNN), таких как srcnn (Super-Resolution Convolutional Neural Network), подготовлен новый бэкенд на основе libtensorflow;Похоже, скоро можно будет удобненько нейронно-автоматически раскрашивать ч/б видео, используя софт из недавней новости: https://www.opennet.dev/opennews/art.shtml?num=49550
:)
Нигде внятно не нашел, как прикрутить IntelQuickSync для сжатия H264 на FreeBSD
Спроси на канале #Anime
https://unrelenting.technology/articles/freebsd-on-the-think...https://www.freshports.org/multimedia/ffmpeg/
BEIGNET=off: DRM/VAAPI to OpenCL mapping for i965 + Beignethttps://trac.ffmpeg.org/wiki/Hardware/QuickSync
https://trac.ffmpeg.org/wiki/Hardware/VAAPI
а если нет Х-ов на сервере? какие пакеты еще доставлять? Добавил 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
> а если нет Х-ов на сервере? какие пакеты еще доставлять?Кишки MESA - va-drivers для MESA, libdrm и плагин к ней для конкретного gpu. Как это в бзде называется и есть ли отличия - логично где-то в их вике смотреть.
И список модулей прекрасно, но на нем одном вы далеко не уедете. FFmpeg как бы не будет вызывать напрямую ядерный модуль, или где?!
Собрать пакет;)
Такой большой объём изменений каждый выпуск, а кто спонсирует разработку?
Ну во всяком случае не мы...(с)
Список более менее похож на Just-for-Fun, т.е. основные разработчки устроены в типа нон-профит организациях и получают зарплату (и удовольствие), а остальные получают только удовольствие, и вообще им была оказана честь, что их патчи приняли. Вот если бы какие-то ошибки были исправлены! Что даже за деньги не хочется делать.
Недавно откопал 15 летний КПК Dell Axim X5(320х240, CPU 300MHz). Полностью исправный, даже акк не деградировал. Отдал ребенку баловаться. А там еще флеха 2Gb. Думаю, дай-ка попробую погонять видео на нем.Перекодировал ffmpeg'ом под разрешение экрана, mpeg4, видео поток 128Кб/сек, звук 22050, моно. 1 час видео ~70Мб. Тянет норм, качество картинки удовлетворительное.
Добавил в контекстное меню Thunar'а пункт для перекодировки .avi файлов. Красота!
AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия; ---пффф, пока единственное что у этого av1 заметно, причем очень и очень сильно, то только то что он на corei7 слайд шоу показывает. а уж про то что на этом же corei7 что то пожать попытаться, в этот av1 я вообще не говорю даже, так как боюсь к моему пенсионному возрасту едва первый фильм только конвертироваться закончится, да и то не факт что вообще до этого момента получиться дожить. аппаратного декодинга нет, и не предвидится, а в софте такое непотребство ну ненужно совершенно.
gpu декодер будет (ну, как обычно, не в линуксе), надо же как-то продвигать более мощные видеокарты, майнеры что-то подустали.а аппаратный это для умных телевизоров и прочей мути - будет, как только код стабилизируется. Не выпускать же какому-нибудь самсуню апдейты прошивок к телевизору - его пользователи этого и не поймут-с.
Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?
> Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?А это надо было багрепорт ДО релиза писать наверное. Можно и после, конечно, но тогда вот так.
Написать аппле, все как вы любите.
На FreeBSD прилетел ffmpeg-4.1. Теперь в браузере Firefox на сайте Youtube нельзя выставить разрешение видео больше 720p. В "Статистике для сисадминов" используются кодеки: avc1.64001F, mp4a.40.2. При этом дропнутых кадров 2,5%!
Сергей Шаблин(Blender dev) недавно сказал, что еще Intel делает какие-то оптимизации для FFMPEG(ну и для Blender тоже) под новые процы. Этих оптимизаций здесь нет или про такие вещи не пишут в новостях?
Libx264 затачивается под avx-512
Правда уже года два пилят