Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от opennews (ok), 06-Ноя-18, 11:21
После шести месяцев разработки доступен (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
Сообщение от A.Stahl (ok), 06-Ноя-18, 11:21
>TLS А зачем это в наборе мультимедиа-библиотек?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+6 +/–
	Сообщение от Аноним (3), 06-Ноя-18, 11:26
	>>TLS > А зачем это в наборе мультимедиа-библиотек? Потоковое вещание в шифрованием.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	8. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–1 +/–
	Сообщение от Антон (??), 06-Ноя-18, 12:07
	разве потоковое вещание не дело сервиса потокового вещания, а не мультимедиа-библиотеки?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	11. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+4 +/–
	Сообщение от Annoynymous (ok), 06-Ноя-18, 12:23
	Ffmpeg умеет работать сервисом потокового вещания. //К.О.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	19. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–14 +/–
	Сообщение от Аноним (19), 06-Ноя-18, 13:25
	А кодировать видео без крашей и утечек памяти Ffmpeg уже научился?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	31. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Твоя мамка (?), 06-Ноя-18, 14:48
	Авторизация для потокового вещания тоже доступна.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	32. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–2 +/–
	Сообщение от Qwerty (??), 06-Ноя-18, 15:05
	Судя по дислайкам - нет.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	48. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:14
	> А кодировать видео без крашей и утечек памяти Ffmpeg уже научился? Гугель именно им ютуб кодирует, если не ошибаюсь. Поучи их видео кодировать, умник.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	59. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Аноним (59), 07-Ноя-18, 10:11
	Что-что, а ффмпег в этом плане достаточно надежный. Люди(и я в тч) годами используют его для круглосуточного кодирования без проблем. Плохому танцору как говорится.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	26. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–3 +/–
	Сообщение от Zenitur (ok), 06-Ноя-18, 13:36
	Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	33. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+3 +/–
	Сообщение от фывфывфыв (?), 06-Ноя-18, 15:22
	КЭП: Дабы организовывать закрытые трансляции.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	49. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:15
	> Хм. А зачем шифровать потоковое видео? Это же не авторизация на сайте Да даже обычный https - для защиты приватности, чтобы пров не собирал досье кто и что смотрел крупным оптом, например.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	14. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Mihail Zenkov (ok), 06-Ноя-18, 12:49
	ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен. На сколько я понимаю, теперь для встроенных решений можно не тянуть OpenSSL/LibreSSL, а использовать более компактную mbedTLS.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	24. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–4 +/–
	Сообщение от Аноним (19), 06-Ноя-18, 13:31
	>ffmpeg умеет воспроизводить не только файлы, но и по сети. Соответственно TLS для https нужен. CD/DVD Болванки умеет прожигать?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	29. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+7 +/–
	Сообщение от A.Stahl (ok), 06-Ноя-18, 14:43
	В нём даже пасьянса нет, какие болванки?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	56. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (56), 07-Ноя-18, 08:56
	> В нём даже пасьянса нет, какие болванки? И директикс не ставит. Не то что неро!
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	30. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (30), 06-Ноя-18, 14:47
	> CD/DVD Болванки умеет прожигать? Какой неугомонный анонимчик. Неудачные выходные?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	38. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+4 +/–
	Сообщение от anonymous (??), 06-Ноя-18, 17:41
	> CD/DVD Болванки умеет прожигать? Не настолько хорошо, как ты табуретки.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+3 +/–
	Сообщение от Stax (ok), 06-Ноя-18, 15:28
	Почему нельзя работу с 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 так хочется дать готовые библоитеки для работы с сетью).
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	36. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (36), 06-Ноя-18, 16:41
	Эту "хитрую работу со всеми возможными сетевыми протоколами" по-любому кто должен будет делать. Так пусть её делает кто-то из команды ffmpeg, совместно и согласованно с остальной командой ffmpeg.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	41. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Stax (ok), 06-Ноя-18, 20:42
	Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью в одну библиотеку?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	50. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:20
	> Пускай. А зачем объединять демуксеры бинарных форматов и расширенную работу с сетью > в одну библиотеку? Может потому что демукс протокола от демукса файла не так уж принципиально отличается? А в каком-нибудь HLS и DASH так еще одно завязано на другое и гораздо плотнее чем может показаться. Например половина смысла оных: если видно что сеть или что там еще не тянут текущий поток, при запросе очередного куска разрешение видео плавно даунгрейдится до того что фактически пролезает и прожевывается. Прозрачно для юзера и даже в рамках обычного HTTP(S). И вот это требует от декодера осознать проблемы и сообщить уровню выше что мы хотим другой кусок стрима, с другим разрешением. И как бы если оно будет в совсем разных либах, то удачи, конечно, но...
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	62. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Stax (ok), 07-Ноя-18, 13:53
	Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для разбора которых требуются хитрые манипуляции байтами с реализацией на C (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который умеет ходить по ssh не должны совмещаться. И тем более этого не должно происходить в одной библиотеке, которую потом подключает все кому не лень. И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью - но этот код разом оказывается во всех этих приложениям. Ходить в сеть "прозрачно для юзера", как вы пишете, в т.ч. по ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, не вижу смысла обсуждать это с вами дальше. Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop (я может там в приватном чате пароль к архиву кидаю, а оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, ему можно передать URL и тп) и т.п.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	67. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от пох (?), 08-Ноя-18, 20:04
	> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для > разбора которых требуются хитрые манипуляции байтами с реализацией на C (и > высокими рисками каких-либо уязвимостей, что подтверждается практикой) и код, который > умеет ходить по ssh не должны совмещаться. с каких пор ffmpeg вам что-то "должен"? вам уже разжевали: куча форматов видео _в_принципе_ не существует в виде однозначного файла, точнее, где-то может этот файл и есть, но вам его не отдают. И парсинг этих сетевых радостей ничем не отличается (и да, он такой же или еще менее надежный, нехрен мешать порно с конями с банковскими акаунтами). > Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop > (я может там в приватном чате пароль к архиву кидаю, а то есть вы уже слили свой пароль телеграмму (без всякого ssh, православнейшим вебом, и совершенно неотличимо от, скажем, авторизации самого телеграмма - можно даже для удобства в один пакет упаковать), но вас беспокоит только то, что он, _теоретически_возможно_, каким-то невероятным образом, утечет ssh'ем (ssh'ем! С риском уже подставить хост потенциального злоумышленника, вот уж глупее не придумать) ? > оно мне это куда-нибудь по ssh?..), HandBrake-gui (обертка для конвертации), x264 x264 - совершенно самостоятельный проект, ffmpeg, наоборот, использует его кодек. Если включить. > (тупо конвертер и файлика в файлик!! И теперь ВНЕЗАПНО получил возможность > ходить по сети как угодно, ему можно передать URL и тп) да, и иногда это вполне удобно, не таскать ненужный двенадцатигиговый файлик через еще один диск, а перекодировать на лету. ну и вишенка на тортике: почти любые форматы, как и почти любые кодеки, внезапно, отключаются при сборке ffmpeg. Но типичный опеннетчик ничего сам собрать, конечно же, не умеет и не будет, ждет ебилдов.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	70. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Stax (ok), 09-Ноя-18, 23:25
	>> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для >> разбора которых требуются хитрые манипуляции байтами с реализацией на 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 и кучу-кучу всего? Чтобы сделать систему чуточку безопаснее? Вот спасибо!
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	71. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Mihail Zenkov (ok), 10-Ноя-18, 12:06
	> Мне вот категорически не нравится, когда то, что всегда было простым, надежным > и безопасным локальным конвертером вдруг научилось лазить по сети куда не > попадя. Этим должен заниматься кто-то другой. Не примитивная 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 в зависимости от задачи.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	73. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от пох (?), 12-Ноя-18, 13:18
	> Нет, собираете тот же ffmpeg, что и в системе, но с нужными вам опциями. Больше пересобирать > ничего не нужно (если линковка была динамической). тут могут быть сюрпризы - модные-молодежные эшелон-ноденизабудимлефтпад-игого поделочки могут оказаться с намертво embedded кривособранным. Но он как раз _будет_ требовать сетевой и tls стек, иначе как же вы в телефсбграмм-десктопе будете видео-то передавать?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	75. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (75), 19-Ноя-18, 00:54
	> Предлагаете все выпилить, даже явно мультимедиа типа rtmp*/hls ? Сейчас еще DASH актуален. В нем ютуб вещает, да и остальные веб-сервисы видео в основном на него переползают. Ну и ffmpeg резонно научили с ним работать. И на input и на output. Чтобы генерить серверам это, а потом как клиенту - жевать то что нагенерили. > 3. Текущий подход наоборот безопаснее: все плееры и прочий мультимедиа софт использует > одну и ту же реализацию из ffmpeg Вот именно. Обновить 1 либу с майнтайнерами которые в курсе политик безопасности - лучше чем 20 мелких, полузаброшенных, где автор чего доброго полагает что его супер-ЯП спасет от всего и вся, так что получается как у мозиллы с пдф и битмесаги с эвалом входных данных.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	72. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от пох (?), 12-Ноя-18, 13:15
	> Он должен не мне, а своим пользователям у него, к счастью, нет "пользователей" в вашем смысле. Ну то есть есть некоторое количество странных людей, включая меня, использующих именно ffmpeg, но их единицы и они знают что делают, в основном. > Это редкие исключения, а не правила. ffmpeg весь - "редкие исключения", а для "правила" вам вон av1 с единственно-верным кодеком положон. То есть он почти весь - миллион странных форматов и кодеков, и именно ради них и пилится в настоящее время. > А x264 как утилита командной строки это тулза для конвертации из <что-нибудь> в, собственно, > сжатый H.264 поток. Они решили добавить фильтры и расширенные входные форматы. ну и прекрасно - вот им и адресуйте свою попоболь, со словами что они добавили в том числе и https: в качестве формата (а может и quic заодно), и он очень, очень несекьюрно. Вдруг уговорите? к счастью, я использую очень старую версию x264, поскольку никаких чудес в самом кодеке не жду, и меня эта проблема не беспокоит, тем более что использую ее как кодек для ffmpeg и не более. На мой век хватит, x264 не изменится завтра с выходом новой камеры. > Мне вот категорически не нравится, когда то, что всегда было простым, надежным и безопасным > локальным конвертером вы просто не владеете темой, оно им не было со времен Белларда (да и тогда, вероятнее всего, могло нечаянно поисполнять подсунутый "видеофайл" как код, автора интересовали совершенно другие вещи) эта штука всегда была сложной, с кучей особенностей применения. Одной из них, кстати, является возможность собрать ее так, как надо применяющему для его узкоспециального случая. Но, боюсь у авторов x264 случай совсем не ваш - они не для того добавили в свою поделку libavformat, чтобы отрезать часть форматов - наоборот, именно для того и добавляли, чтобы форматы были. > А я умею curl, пайпы, vfs и кучу других абстракций. а знаний не имеете. например, что для mse это все не очень поможет.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	74. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (75), 19-Ноя-18, 00:50
	> Я выше написал про вопрос безопасности - поддержка огромного числа контейнеров, для > разбора которых требуются хитрые манипуляции байтами с реализацией на C А на чем еще реализовывать критичный к скорости код? Безопасность там кстати здорово подтянули - гугель фуззит это добро непрерывно, так что баги чинятся еще до того как их хакеры найдут. И если кто считает что его парсеры валидируются лучше - на честное слово мы ему таки не поверим, пусть делом докажет. Реализовав столько же парсинга с производительностью не хуже и безопаснее. Тогда будет разговор. > (и высокими рисками каких-либо уязвимостей, что подтверждается практикой) Практика сейчас такова что там continious fuzzing и куча тестов вылавливают в парсерах самые чудесатые баги. > и код, который умеет ходить по ssh не должны совмещаться. Очень интересный вывод. Наверное, уровень экспертизы такой же как и с безопасностью. > И тем более этого не должно происходить в одной библиотеке, которую потом подключает > все кому не лень. А может быть, правильный ответ - в том что эта библиотека все-же должна стать безопасной? И таки в этом направлении они хорошо подвинулись, нарулив фуззинг и тесты оптом. Если кто думает что может лучше - пусть придет и покажет, вместо разглагольствований о том что, чему и сколько "должен". Вас никто не заставляет пользоваться этими библиотеками вообще. А то что там парсеров дофига и в них баги случаются - да, человечество придумало дофига форматов и протоколов. Некоторые из них даже навороченные и без багов их все реализовать может быть нетривиально. Но наверное в этом не ffmpeg виноват. И даже более того - лажа будет и с другими ЯП и проч. > И далеко не всем из тех, кто использует ffmpeg нужно работать с сетью > - но этот код разом оказывается во всех этих приложениям. И, собственно, чего? Поэтому предлагается нагнуть тех кто все-таки хочет какое-нибудь потоковое аудио и видео? Так не пойдет. > ssh, в приложении, которое просто хотело сделать какие-то мультимедиа-конвертации - это > очень-очень плохо с точки зрения безопасности. Если вы этого не понимаете, > не вижу смысла обсуждать это с вами дальше. У меня ffmpeg сможет вылезти в сеть только очень гранулярно, контролируемо и тогда когда я этого явно захочу. И вот тогда мне будет вполне удобно и хорошо. Поговорите еще со мной о безопасности, мистер эксперт. > Может так станет понятнее, пример приложений, линкующихся к libavformat: telegram-desktop Пардон, он без сети бесполезен чуть более чем полностью. > (я может там в приватном чате пароль к архиву кидаю, И чего? Там еще и кутя мегов на сто кода. При том это не какие-то парсеры которые фуззером можно прозвонить а круто абстрагированные плюсы, на синтаксическом анализе которых спятит что угодно. Туда же и пихтонр@сты всякие, кстати - там вообще безопасность по методу неуловимого Джо. Когда Джо начинает шуметь, у него находят eval() на входных данных вообще, как в bitmessage (который в отличие от телеги еще и явно пиарился как такой из себя весь секурный, а достаточно то всего разик посмотреть в тот код, чтобы оценить чего ждать от этих кодеров). > а оно мне это куда-нибудь по ssh?..), Оно по ssh будет ломиться только если программа об этом явно попросит. И если твой телеграм уже поимели настолько что он просит либу сходить по ssh - жалкие потуги обрубить фичу в либе тебя явно не спасут, о великий спец по безопасности. > HandBrake-gui (обертка для конвертации), x264 > (тупо конвертер и файлика в файлик!! Так они и не вызывают функций работающих с сетью. Если стремно можно в контейнер вообще засунуть. > И теперь ВНЕЗАПНО получил возможность ходить по сети как угодно, > ему можно передать URL и тп) и т.п. А вот это еще не факт. Впрочем, если handbrake сможет транскодинг сразу с урлы - да это вообще пожалуй фича а не баг.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	43. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (43), 07-Ноя-18, 00:10
	Потому что круг использования ffmpeg плеерами не ограничивается (более того, обычно он напрямую в плеерах не используется).
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	64. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Ordu (ok), 07-Ноя-18, 14:17
	> Почему нельзя работу с TLS оставить плееру? Почему линковка с этими библиотеками засунута в библиотеку работы с форматами? Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать и вовремя отрендерить. Если у нас временной лаг на чтении, то это выльется в лаги на экране. Эти проблемы можно решать generic способом включая буферизацию на несколько секунд вперёд, но это приведёт к задержке в несколько секунд (что может быть существенно в каких-то сценариях использования), и к перерасходу памяти. ffmpeg идёт другим путём, он использует стратегии чтения наилучшим образом подходящие для носителя: если мы читаем с жёсткого диска, то достаточно иметь небольшой кеш упреждающего чтения, если мы читаем по сети, то... тут я чесслово не знаю какого масштаба усложнения начинаются, но если предполагать по максимуму, то надо договориться с передающей стороной о том, как много мы хотим читать вперёд, какого размера кусками, как долго ждать до повторной передачи куска, в случае отсутствия подтверждения о получении, надо получая эти куски правильно их переупорядочивать,... большую часть этого на себя берёт стек tcp/ip, но стеку ведь можно подсказать как лучше действовать в данной ситуации. Но вообще может быть любопытной задачей создание какого-нибудь внятного API между декодером и reader'ом, которое позволило бы разнести их по разным адресным пространствам, сохранить гибкость системы при подстройке к конкретной ситуации, не потерять в производительности, и не столкнуться при этом с проблемой breaking changes в каждой минорной версии этого API. Если ты такой умный, как выглядишь, то займись этим -- разнеси код ffmpeg на два процесса и создай API между ними.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	76. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Аноним (75), 19-Ноя-18, 00:57
	> Тайминги. Воспроизведение видео завязано на них. Надо вовремя прочитать, вовремя декодировать > и вовремя отрендерить. Более того - вся логика DASH сводится к тому что если это не получилось, следующий сегмент будет взять с более паршивым качеством. Автоматически. Так что у юзера видео по сети будет такое, какое его железо и сети реально способны прожевать. А не так что мы тут пытаемся 10-мегабитный поток впихивать в несчастного GPRSника до упора, а тот смотрит его рывками по 3 секунды каждые полчаса.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	79. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Ordu (ok), 19-Ноя-18, 03:58
	Да, спасибо за пример. Очень показательно. Я сам не могу приводить примеров, ибо не в теме вообще, рассуждаю из самых общих соображений.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	37. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от ттт (?), 06-Ноя-18, 17:16
	ffmpeg не работает с TLS, это делает сторонная библиотека, которой пользуется ffmpeg.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	39. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Stax (ok), 06-Ноя-18, 17:50
	Ясен пень, что алгоритма шифрования там нет. Но все-таки это именно библиотека с демуксерами форматов (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...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	57. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (56), 07-Ноя-18, 08:57
	Было бы странно если бы он умеючи HTTPSные урлы не умел бы TLS :)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	47. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:13
	> А зачем это в наборе мультимедиа-библиотек? Затем что ffmpeg и прочие ffplay умеют видео не только локально из файлов, но и по сети. Включая http(s). Сюрприз.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от Аноним (2), 06-Ноя-18, 11:23
>AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный   сколько лет работы 4-ядерного проца потребуется, чтобы закодировать в нем 10-минутный ролик?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+9 +/–
	Сообщение от Аноним (9), 06-Ноя-18, 12:11
	В апреле этого года 1 секунда 1080p кодировалась 5 часов. Сейчас ситуация изменилась, но ненамного - результаты тестов широкой публике особо не представляются. По сути AV1 становится вторым вейландом. Он вот-вот будет готов, чтобы вытеснить все прочие кодеки. Вот еще чуть-чуть. Уже совсем скоро... Его даже начали поддерживать браузеры. То есть не то чтобы начали... Но скоро начнут.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Crazy Alex (ok), 06-Ноя-18, 12:41
	Добавим данных маленько. Вот, например, на Ryzen 1700x скорость кодирования 0.2 fps для FullHD со средней нагрузкой на проц 50% - https://www.reddit.com/r/AV1/comments/9afr5d/my_1700x_encodi.../ - это августовская статья, что с тех времён изменилось (и изменилось ли) - понятия не имею.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	15. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
	Сообщение от Crazy Alex (ok), 06-Ноя-18, 12:53
	Вот ещё ссылочка - если коротко, то он здорово улучшился и в прицнипе уже на живой похож. http://www.streamingmedia.com/Articles/ReadArticle.aspx?Arti... - в 10 раз медленнее vp9 на сжатии - пытаться что-то делать уже можно.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	20. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Mihail Zenkov (ok), 06-Ноя-18, 13:25
	При равных опциях (cpu-used=0) разница в 40 раз. Разница уменьшается до 10 раз при cpu-used=2 у av1 и cpu-used=0 у vp9. Если я правильно понял, то при увеличении cpu-used падает качество, так что не понятно, будет ли av1 при таком подходе существенно лучше сжимать, чем vp9. Вообще как ни крути, а все равно очень медленно, особенно в сравнении с h264.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	52. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:38
	> При равных опциях (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 жмет быстро, но вот битрейта ему надо для хорошей картинки явно не столько.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	51. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:23
	> В апреле этого года 1 секунда 1080p кодировалась 5 часов. BBB в 480p целиком за ночь кодируется в 4 потока, speed = 1..3. Это не самый гламурный 0, но тоже весьма ничего. > результаты тестов широкой публике особо не представляются. Они меняются по три раза на дню. И при том - в правильную сторону. > То есть не то чтобы начали... Но скоро начнут. В смысле? Хромиум его просто берет и играет. Гугля за словом и делом в карман не лезет - вкомитили и включили.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	65. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (65), 07-Ноя-18, 14:49
	Кому нужны результаты сжатия в 480p в 2018? Пиарщикам? Типа, "посмотрите, как все здорово, обработка не занимает две недели... правда, это справедливо только для sd качества". С тем же успехом можно хвалиться скоростью сжатия видео в 240p. Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать, что это прорыв технологий и будущее. Анон выше уже сравнил этот "прорыв" с вяленым, который лет 10 все никак не достигнет готовности.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	68. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (68), 09-Ноя-18, 09:18
	Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	78. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 01:13
	> Вяленый достиг готовности ещё в 2012 году. Вы все не понимаете о чём говорите. А еще ему 480p не нравится, видите ли. А пусть этот умник попробует для начала сохранить себе на винч нежатый YUV в 1080p и посмотрит сколько это весит и какая там скорость потока, чтоли. Тогда узнает почему "лайтовые" забеги на посмотреть как вообще кодек были в 480p.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	77. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 19-Ноя-18, 01:06
	> Кому нужны результаты сжатия в 480p в 2018? Пиарщикам? В 500 кбитах то? Тем кто мувик по сети будет смотреть на дохлом канале, например. > С тем же успехом можно хвалиться скоростью сжатия видео в 240p. Бандвиз жрется и на 240p и на 1080p. Так что плотно сжать важно и тех и других. Кстати на HD экономия бандвиза еще эпичнее получается. А скорость - оптимизируют не по дням а по часам. Вот там китаец. В августе он начал с времени кодирования тестового куска 600000+ миллисекунд. Сейчас в его же комитах цифры типа 149000 фигурируют. > Как-то модно стало выкатывать полуготовые решения, но зато на каждом углу орать, "Release early, release often" :) > что это прорыв технологий и будущее. И таки мне оно нравится - жмет очень плотно. При том у меня нет кластеров как у гугли, я это на обычном компе пережал. А в x264 на тех же 500 кбит получается мутное гуано. А если видео сделать с битрейтом выше - нет, конечно, я и мпег2 зажать могу, так что плевый мувик который в av1 весит 35 мегов на все - станет размером под гиг наверное. А оно мне такое надо?
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

4. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+2 +/–
Сообщение от Олег (??), 06-Ноя-18, 11:32
С версии 3.4 до версии 4.0 скорость в наших тестах возрасла в два раза Gpu h264 Нужно тестить 4.1)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Выпуск мультимедиа-пакета FFmpeg 4.1"	–6 +/–
	Сообщение от Аноним (19), 06-Ноя-18, 13:25
	В версии 4.1 упала в три.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	28. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Олег (??), 06-Ноя-18, 14:10
	Проверяли?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	45. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (45), 07-Ноя-18, 07:53
	Это клоуны пишут
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

6. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от h31 (ok), 06-Ноя-18, 11:52
Расскажите, чем сейчас в Линуксе можно восстановить цифровую копию с VHS-пленки? Даже не для качества, а чтобы весь этот шум и дребезг не увеличивали размер закодированного файла.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Ivan_83 (ok), 06-Ноя-18, 11:58
	Тогда у тебя будет больше мыла. Если совсем руками то OpenCV и самому ручками, всякие готоые фильтры можно через сабж поприменять.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	18. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
	Сообщение от Kido Katsuragi (?), 06-Ноя-18, 13:24
	http://www.vapoursynth.com/
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	53. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (-), 07-Ноя-18, 08:45
	> не для качества, а чтобы весь этот шум и дребезг не > увеличивали размер закодированного файла. Да тем же сабжем и восстановить, делая не просто кодирование а еще и -vf=<денойзер_по_вкусу>. Который из них на VHS лучше работает - черт бы его знает, но очень зашумленное видео с мобилы в темноте удалось окультурить очень даже. Я даже и не думал что там столько информации и что оно так хорошо восстановится.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

12. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+1 +/–
Сообщение от Андрей (??), 06-Ноя-18, 12:30
> Для фильтров на основе методов глубинного машинного обучения (DNN), таких как srcnn (Super-Resolution Convolutional Neural Network), подготовлен новый бэкенд на основе libtensorflow; Похоже, скоро можно будет удобненько нейронно-автоматически раскрашивать ч/б видео, используя софт из недавней новости: https://www.opennet.dev/opennews/art.shtml?num=49550 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от guest34567 (ok), 06-Ноя-18, 13:06
Нигде внятно не нашел, как прикрутить IntelQuickSync для сжатия H264 на FreeBSD
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+4 +/–
	Сообщение от Аноним (19), 06-Ноя-18, 13:26
	Спроси на канале #Anime
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	25. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (25), 06-Ноя-18, 13:35
	https://unrelenting.technology/articles/freebsd-on-the-think... 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
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	42. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от guest2222 (?), 07-Ноя-18, 00:05
	а если нет Х-ов на сервере? какие пакеты еще доставлять? Добавил 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
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	54. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (56), 07-Ноя-18, 08:53
	> а если нет Х-ов на сервере? какие пакеты еще доставлять? Кишки MESA - va-drivers для MESA, libdrm и плагин к ней для конкретного gpu. Как это в бзде называется и есть ли отличия - логично где-то в их вике смотреть. И список модулей прекрасно, но на нем одном вы далеко не уедете. FFmpeg как бы не будет вызывать напрямую ядерный модуль, или где?!
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	27. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Олег (??), 06-Ноя-18, 14:09
	Собрать пакет;)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

17. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от АнонимЪ (?), 06-Ноя-18, 13:21
Такой большой объём изменений каждый выпуск, а кто спонсирует разработку?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (35), 06-Ноя-18, 16:11
	Ну во всяком случае не мы...(с)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	44. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Андрей (??), 07-Ноя-18, 05:57
	Список более менее похож на Just-for-Fun, т.е. основные разработчки устроены в типа нон-профит организациях и получают зарплату (и удовольствие), а остальные получают только удовольствие, и вообще им была оказана честь, что их патчи приняли. Вот если бы какие-то ошибки были исправлены! Что даже за деньги не хочется делать.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

23. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+3 +/–
Сообщение от Вот оно че (?), 06-Ноя-18, 13:27
Недавно откопал 15 летний КПК Dell Axim X5(320х240, CPU 300MHz). Полностью исправный, даже акк не деградировал. Отдал ребенку баловаться. А там еще флеха 2Gb. Думаю, дай-ка попробую погонять видео на нем. Перекодировал ffmpeg'ом под разрешение экрана, mpeg4, видео поток 128Кб/сек, звук 22050, моно. 1 час видео ~70Мб. Тянет норм, качество картинки удовлетворительное. Добавил в контекстное меню Thunar'а пункт для перекодировки .avi файлов. Красота!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от Андрей (??), 06-Ноя-18, 19:00
AV1 разработан альянсом Open Media (AOMedia) и позиционируется как общедоступный и не требующий оплаты отчислений свободный формат кодирования видео, который заметно опережает H.264 и VP9 по уровню сжатия; ---пффф, пока единственное что у этого av1 заметно, причем очень и очень сильно, то только то что он на corei7 слайд шоу показывает. а уж про то что на этом же corei7 что то пожать попытаться, в этот av1 я вообще не говорю даже, так как боюсь к моему пенсионному возрасту едва первый фильм только конвертироваться закончится, да и то не факт что вообще до этого момента получиться дожить. аппаратного декодинга нет, и не предвидится, а в софте такое непотребство ну ненужно совершенно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от нах (?), 07-Ноя-18, 10:37
	gpu декодер будет (ну, как обычно, не в линуксе), надо же как-то продвигать более мощные видеокарты, майнеры что-то подустали. а аппаратный это для умных телевизоров и прочей мути - будет, как только код стабилизируется. Не выпускать же какому-нибудь самсуню апдейты прошивок к телевизору - его пользователи этого и не поймут-с.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

46. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от Аноним (46), 07-Ноя-18, 08:04
Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (56), 07-Ноя-18, 08:55
	> Теперь на MacOS ffplay показывает черный квадрат вместо видео. Как теперь кино смотреть? А это надо было багрепорт ДО релиза писать наверное. Можно и после, конечно, но тогда вот так.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	69. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Аноним (59), 09-Ноя-18, 10:30
	Написать аппле, все как вы любите.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

58. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от iZEN (ok), 07-Ноя-18, 09:53
На FreeBSD прилетел ffmpeg-4.1. Теперь в браузере Firefox на сайте Youtube нельзя выставить разрешение видео больше 720p. В "Статистике для сисадминов" используются кодеки: avc1.64001F, mp4a.40.2. При этом дропнутых кадров 2,5%!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

61. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
Сообщение от Аноним (61), 07-Ноя-18, 11:35
Сергей Шаблин(Blender dev) недавно сказал, что еще Intel делает какие-то оптимизации для FFMPEG(ну и для Blender тоже) под новые процы. Этих оптимизаций здесь нет или про такие вещи не пишут в новостях?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	66. "Выпуск мультимедиа-пакета FFmpeg 4.1"	+/–
	Сообщение от Олег (??), 08-Ноя-18, 18:52
	Libx264 затачивается под avx-512 Правда уже года два пилят
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема