После десяти месяцев разработки доступен мультимедиа-пакет FFmpeg 4.3, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53162
> sierpinski - генерирует видеопоток с фракталами Серпинского;Это же трайфорс!
Больше раста!!!
" Добавлена возможность кодирования видео AV1 с использованием библиотеки librav1e, написанной на на языке Rust и развиваемой сообществами Xiph и Mozilla; "
не ссы - в ffmpeg уже лет десять не добавляются свои кодеки, не считая какой-нибудь никому ненужной херни типа видосиков в игруле двадцатилетней давности. Беллард давным-давно не участник проекта.Добавляются готовые либы кодеков - и пофиг, на хрусте они или вообще на gwbasic
>ffmpeg уже лет десять не добавляются свои кодекиДекодеры добавляют.
ffvp9 выкатили 6 лет назад и уделали по скорости декода остальных.
ffhevc тоже был, правда особо в бенчмарках не светился.
dav1d пишется совместными силами ffmpeg и vlc.Энкодеры писать (особенно качественные) куда сложнее, этим пусть лучше специалисты занимаются
> Добавляются готовые либы кодековИх надо добавлять сборщику. А это такой гемор.
Вот этих модулей (кодировщиков) по умолчанию нет (и много чего еще):
libass libbluray libmp3lame libopus libpulse libsoxr libspeex libtheora libtwolame libvorbis libvpx libwavpack libwebp libx264 libx265 libxvidЕсть следующие кодировщики (с пометкой native):
mpeg4 srt pcm aac ac3 dvvideo ffv1 opus truehd ffvhuff huffyuv utvideo flac png prores flv gif vorbis (bad) alac wavpack webvtt apng wmv wma ass ssa jpeg2000 mjpeg bmp mp2 mpeg1video mpeg2video dcaИмеется ключ --enable-vapoursynth. Требует установленный VapourSynth с /Include/VapourSynth.h
Я так полагаю, это позволит импортировать py скрипты напрямую. Собираю сейчас, собирается долго, даже без сторонних зависимостей.
> Я так полагаю, это позволит импортировать py скрипты напрямуюНе позволяет.
> Не позволяетЭто потому что по умолчанию vpy скрипты не обрабатываются. Нужно предварительно указать демультиплекстор -f vapoursynth ПЕРЕД -i
Но тут появляется другая проблема. В таком режиме ffmpeg совсем не выводит прогресс. Заставить его выводить хоть какую-то информацию о скорости и прогрессе можно добавив опцию -progress pipe:1
Таким образом, скрипт получается:
ffmpeg -f vapoursynth -i script.vpy -vcodec mpeg2video -q:v 1 -progress pipe:1 output.mkv
Интересно, что при открытии vpy скриптов напрямую (не через vspipe) передается информация об аспекте (если он анаморфный).
Это же касается и mpv, собранного с поддержкой vapoursynth. Так собирал я https://pastebin.com/raw/qdhf4rEu (у меня уже был собран свежий ffmpeg 4.3, поэтому я удалил старые ffmpeg dev либы)
mpv нужно запускать с опцией --demuxer-lavf-format=vapoursynth взято отсюда https://forum.doom9.org/showthread.php?t=180433
То есть, команда получается:
mpvvs --demuxer-lavf-format=vapoursynth ~/script.vpy
Чтобы не писать так каждый раз, можно добавить в ~./config/mpv/mpv.conf
[extension.vpy]
demuxer-lavf-format=vapoursynth
mpv получает информацию не только об аспекте, но и о длительности, потому можно попробовать подгружать внешние звуковые дорожки. Но вроде бы в январе 2020 года разработчик vapoursynth сделал встроенную поддержку звука и в версии R51 обещает ее доработать.
Интересное наблюдение. Проверка ldd ~/path_to_mpv-binary дебиановского mpv пакета (из buster, там версия 0.29) показала, что бинарник слинкован с libvapoursynth-script.so.0, хотя дефолтные репозитории Debian не содержат ни vapoursynth, ни zimg (в отличии от репозитория deb-multimedia). Кстати, собранный мной mpv 0.32 с поддержкой vapoursynth показывает в ldd также. Похоже, это самодеятельность самого mpv, при наличии libvapoursynth-script.so.0 (как у меня) он к ней обращается, но явно не требует. А вот mpv 0.14 эту библиотеку не ищет. Есть надежда, что собирать mpv специально с поддержкой vapoursynth не требуется и, если он установлен, новые версии mpv смогут обрабатывать vpy скрипты (с опцией --demuxer-lavf-format=vapoursynth, конечно). На это намекает также тот факт, что официальный пакет mpv из archlinux тоже не требует vapoursynth в зависимостях, хотя в арче обычно собирают со всеми флагами.А вот mpv 0.29 из deb-multimedia для Buster явно требует vapoursynth http://deb-multimedia.org/dists/stable/main/binary-i386/pack... (он собран с 47 версией). И ldd показывает в зависимостях не только libvapoursynth-script.so.0, но и libvapoursynth.so и эта последняя зависимость строгая. Видимо такую отвязку сделали, чтобы vapoursynth не требовался при установке mpv (а соответственно и python вместе с ним). А то в Debian 10 (Buster) с репозиторием deb-multimedia, я помню удивился, vapoursynth норовил установиться практически сразу (хотя, мне это и надо было), по зависимостям кодеки>mpv.
ldd показывает зависимости зависимостей. mpv зависит от libavdevice.so.58, а libavdevice.so.58 зависит от libvapoursynth-script.so.0 и libpng12.so.0, хотя libpng12 в Debian Buster тоже нет. При просмотре в двоичном редакторе дебиановского mpv, я не нашел никаких упоминаний vapousynth. А в собранном мной бинарнике упоминания были. Короче, сбил меня с толку ldd. Соответственно, в посте выше я чушь написал.
> mpv 0.14 эту библиотеку не ищетПотому что он собран с системным /usr/lib/libavdevice-ffmpeg.so.56, который про vapoursynth ничего не знает.
> libavdevice.so.58 зависит от libvapoursynth-script.so.0Потому что ffmpeg 4.3 я собрал с поддержкой vapoursynth. Развел слаку из убунты. Кто-то скажет "есть же гента" (или арч), но я не люблю роллинг, потому что там нет постоянства.
Съел vapoursynth мне мозг в очередной раз. Возвращаюсь на старый добрый avisynth. Все-таки не тянет линукс десктоп даже в 2020 году...
> это такой геморТо есть, надо поставить dev пакеты этих библиотек. Тогда, если делать shared сборку, ffmpeg бинарник будет зависеть от системных библиотек. Если делать static сборку, в старую систему можно поставить и свежие внешние библиотеки, они слинкуются в единый ffmpeg бинарник, у которого почти не будет внешних зависимостей (после сборки их можно будет удалить).
ну насчет хрустолибы - возможно и гемор (небось опять собирается только той версией хруста, которая сама еще не собирается, недокомитили последнюю правку)остальное - если для сборщика "гемор" поставить includes от пачки вполне стандартных библиотек - то может ему вообще лучше в макдак пойти поработать? Там уже открылись, очереди шо п-ц, вакансий должно бы быть.
другое дело - а зачем оно нам такое вообще, у всех этих либ обычно какой-то примитивный cli враппер и так есть, если кому очень уж хочется покодировать свою нетленку именно в самый модный тормозной формат.
>На базе Vulkan для Linux реализован кодировщик, использующий для ускорения движки AMD AMF/VCEЭто гевогюция, тогарищи!
О, интересно, vp9 на хасвелах заработает или нет.
не заработает, там нет аппаратной поддержки
> хасвел - 2013 годБез шансов
VP9 только в скайлейках появился. VP8 в броадвеллах.
> Добавлена поддержка протоколов ZeroMQ и RabbitMQ (AMQP 0-9-1);И ведь никто не ноет, что комбайн и не юникс-вей!
Он в каком-то роде юниксвэй, делает всего 1 вещь: "работает с видео"
ZeroMQ работает только с видео? А чего он делает в области IoT?
Кодоредактор пока в FFmpeg не вставили.
И а когда и в убунты придут такие апдейты? (У меня в "20.04" нет этого пока (не запуская менеджера обновлений я на ubuntuupdates.org смотрю, что там туда "завозят").
В 20.10 осенью
> а когда и в убунты придут такие апдейты?Как здесь соберут https://ffmpeg.org/download.html > https://johnvansickle.com/ffmpeg можешь закинуть в ~/.local/bin
В этом ppa собрали 4.3 для 16.04 и 18.04
https://launchpad.net/~jonathonf/+archive/ubuntu/ffmpeg-4
http://ppa.launchpad.net/jonathonf/ffmpeg-4/ubuntu/pool/main.../
Только надо иметь в виду, что системный софт (плееры и прочее) его использовать не будут, а будут дергать старые системные ffmpeg либы, с которыми слинкованы.
Причем, в отличии от static сборки, многие кодеры (x264, opus и прочее) тоже будут старыми системными. Так что лучше static, если только не нужен софт, использующий ffmpeg 4.3 shared либы (а он обычно тоже из ppa).
> Добавлена поддержка протоколов ZeroMQ и RabbitMQ (AMQP 0-9-1)Хммм... А для чего? (Да, мне лень ходить по ссылкам)
эту херню (ффмпег) можно запустить как подписчика этих очередей. и конвертить видео на лету, а не запуская через консоль.
Херня у тебя в штанах, а это шляпа. Что значит "на лету", ты имеешь в виду сказать дядя будет выставлять параметры с фильтрами? По-моему ты не понимаешь, как оно работает.
Великолепный релиз. Только chromium умирает на любом видеохостинге.
Пересоберите.
> хО, интересно, vp9 на хасвелах заработает или нет.У меня на Хасвеле вроде работает на ютубчике.)
Video ID / sCPN
V1Cx079qm2E / 7XQ9 94RJ N5M3
Viewport / Frames
1209x680 / 0 dropped of 69
Current / Optimal Res
1920x1080@25 / 1920x1080@25
Volume / Normalized
30% / 19% (content loudness 3.9dB)
Codecs
vp09.00.51.08.01.01.01.01.00 (248) / opus (251)
Color
bt709 / bt709
Как насчёт 4к?
Работать то работает, но аппаратного ускорения то нетуна haswell работает и av1, но процессор ебoшит как не в себя
> У меня на Хасвеле вроде работает на ютубчике.)Ты странный что ли??? Он у всех работает.
Имеется в виду аппаратное декодирование.
А у тебя играется на процессоре. И оно будет играться на одноядерном дюроне 2005го года, только со скоростью 1кадр/сек.
Аппаратной поддержки в видеоплатах встроенных в хасвелы нет и не будет никогда, ибо процессоры появились раньше самого кодека.
Не зря ведь придумали расширение для браузеров h264ify, которое запрещает ютюбчику выдавать не поддерживаемый аппаратно кодек, выдавая вместо этого поддерживаемый повсеместно h264.
А то выдал выхлоп плеера с ютюба и радуется, смешной какой... Смотри что пишет vainfo..
А еще лучше топи на https://wiki.archlinux.org/index.php/Hardware_video_accelera... там черным по белому написано какой проц чего поддерживает и через какую библиотеку.
> на одноядерном дюроне 2005гоесли 2005, то семпроне
если AviSynth будет работать, это ооооочень круто)
AviSynth работает (и старый AvXSynth, если соберешь, и новый AviSynth+), но мало плагинов портировано
https://aur.archlinux.org/packages/?O=0&K=avisynth
https://aur.archlinux.org/packages/?O=0&K=avxsynth
Сначала определись зачем тебе AviSynth. Многое можно сделать через ffmpeg. То, что нельзя, например, QTGMC деинтерлейс, SRestore, качественное FPS конвертирование (SVP, mvtools), лучше сделать в VapourSynth. Но он использует питона, а AviSynth на нормальном C. Насчет IVTC не знаю (в Handbrake есть, а он ffmpeg based), mencoder точно умеет (в том числе следовать pulldown флагам, для VapourSynth нужно собирать D2VWitch и d2vsource). Лучше бы в ffmpeg сделали поддержку прямого импорта VapourSynth скриптов, без vspipe. Или она есть, но надо собирать самому?Это на винде мода для простейшего конвертирования дергать AviSynth. А после всех этих *synth'ов теряются нелинейные таймкоды контейнера и переменная FPS. Так что лучше их не использовать без особой необходимости. Виндузятники об этом не знают, хотя я им говорил. Нахваливают свою XviD4PSP 5.
Так либы там вполне себе сишные, если ты за производительность переживаешь. Лишь бы не на одном ядре работало (т.е. не как на нормальном си).
Да вот только у меня двухъядерный проц. Виндовый AviSynth (QTGMC preset Faster) загружает его при дефолтных настройках на 70%, но кодирует на 25-33% быстрее, чем линусковый VaspourSynth, который загружает на 100%. При том, что на винде, выставив минимальный приоритет, еще можно чем-то заниматься, а на линуксе, несмотря на приоритеты, отзывчивость падает сильнее.Знаю, питон только парсит скрипты, аналог которых (точнее устаревшие порты, как и в случае с плагинами) это avs и avsi. Только вот avs* не тянет в систему питонятину, а только маленький avisynth.dll.
Годнота!
> Как насчёт 4к?Video ID / sCPN
0FYjApop7Mk / Q1Q4 3KVJ TT0P
Viewport / Frames
1209x680 / 0 dropped of 761
Current / Optimal Res
3840x2160@24 / 3840x2160@24
Volume / Normalized
81% / 49% (content loudness 4.4dB)
Codecs
vp09.00.51.08.01.01.01.01.00 (313) / opus (251)
Color
bt709 / bt709
Connection Speed
С подзагрузками.)
> В Linux осуществлён переход с фрэймсервера для нелинейного редактирования видеопотоков (виртуального видеокодека) AvxSynth, который уже 5 лет находится в заброшенном состоянии, на актуальный форк AviSynth+;Эхх... а ведь ему недавно 20 лет стукнуло. Это же целое поколение почти и до сих пор незаменим =)
Каких синтовских плагинов тебе не хватает в линуксе? А ведь Синт может подгружать и VirtualDub'овские плагины (которые работают в RGB32). Я как-то использовал их, чтобы убрать полосы с записи ТВ трансляции.AvXSynth это порт AviSynth версии 2.5, которую уже давно забросили плагинописатели. Работают разве что старые плагины (а на линукс их еще портировать надо). На винде сейчас модно плагины собирать в VS 2019, соответственно редистры 2015-2019 во все поля, фу. Хотя, на линуксе питонятина зато.
Ктож на линуксе видео редактирует.
Я
> Имеется в виду аппаратное декодирование.Конкретнее надо было изъясняться, я не сильно в теме, но у меня Хасвел и в целом работает.)
>> Имеется в виду аппаратное декодирование.
> Конкретнее надо было изъясняться, я не сильно в теме, но у меня
> Хасвел и в целом работает.)Смотри какое дело, как это обычно работает вообще:
предположим, что какая-то контора выпускает кодек и этот кодек начинают применять во всяких гуголах (ютюбах), мозилах и т.п. гигантами в индустриях..
но как применять? кодек - это всего лишь какое-то описание способа кодирования потока, просто математический алгоритм, так сказать... потому, все эти мозиллы, гуглы и прочие ffmpeg-и, пишут ЭТАЛОННЫЕ РЕАЛИЗАЦИИ данного кодека, соревнуясь за одно у кого быстрей получится...
и вот эти все ЭТАЛОННЫЕ и не очень реализации кодеков, они, как правило, пишутся на обычных сях и работают на центральном процессоре, что не очень эффективно само по себе, зато работает везде.
ВОТ ЭТО И ЕСТЬ ТВОЙ СЛУЧАЙ. И ВООБЩЕ ЭТО ОБЩИЙ СЛУЧАЙ КАК ПРАВИЛО.
а дальше поспевают новые видеокарточки.. в которых уже производитель железа добавляет аппаратную поддержку того или иного кодека.. или не добавляет.. или добавляет, но криво.. - тут еще как повезет.
и этот случай, очевидно, наиболее энергоэффективен. был бы, если бы не требовалась аппаратная поддержка еще и софтом - тем самым софтом, с самого верха этого ликбеза, который и без того работает на процессорах практически любых.
вот этот, последний случай, как раз и описывается в новости, например - добавили поддержку аппаратную vp9 через intel QSV, аппаратная поддержка vp9 в котором есть только для процев от Version 5 (Skylake). то есть, очевидно что АППАРТНО VP9 на HASWELL не заработает НИКОГДА.
Как-то мутно написано, вон с vdpau всё понятно, есть фьюча сеты и определённые параметры кодека поддерживаются только определёнными поколениями карточек (и более поздними). Это декодирование. С кодированием посложнее, там постоянная эволюция качества картинки в каждом новом поколении карточек, но тоже есть разделение. Когда добавили фич в аппаратный кодек, которые посзволили реализовать более качественное кодирование. У интела что-то мутное совсем, непонятно.
Стоит отметить, что почти не сломали api. И это не может не радовать.
Да, между 4.2 и 4.3 номера либ не менялись и это хорошо.
AVI MPEG4 по прежнему на квадратики рассыпаются? Этот формат уже устарел, а эти до сих пор его нормально кодировать не научились.
Используй libxvid (вместо mpeg4) вот с такими настройками:
-c:v libxvid -b:v 2000k -bf 2 -g 250
Следи чтобы битрейта хватало. У ffmpeg дурацкие дефолты при кодировании в AVI XVID. Во первых, нативный mpeg4 не поддерживает детектор сцен, во вторых GOP всего 12 кадров (это приводит к лишнему расходу битрейта на I кадры = качество ухудшается = квадратики), в третьих B кадры по умолчанию отключены. Команда выше избавлена от этих недостатков. Еще можно включить MPEG матрицу вместо H.263, но она требует больше битрейта -mpeg_quant 1
Есть продвинутые настройки https://ffmpeg.org/ffmpeg-codecs.html#libxvid
А команду -mpeg_quant я нашел здесь https://gist.github.com/tayvano/6e2d456a9897f55025e25035478a... (поиск по странице h.263) по выдаче startpage.com
И вот еще https://trac.ffmpeg.org/wiki/Encode/MPEG-4
Еще наблюдение. Команда -vtag xvid не играет никакой роли. При кодировании в mkv кодек всегда помечается MPEG4, при кодировании в avi всегда xvid. По крайней мере, по данным MediaInfo. Еще MediaInfo не может извлечь информацию о B кадрах и матрице кодирования из AVI, закодированных в ffmpeg. Поэтому кодировать ffmpeg libxvid лучше в MKV.
Попробую ваши предложения, но есть сильное ощущение, что это всё я делал, но так и не получил даже близко той картинки что выкладывает scarabey на торрентах (естественно используя те же исходники видео). У скарабея в бложике есть статья как они кодируют, и там используется закрытый виндовый кодек. Так вот там уверенно получается довольно пристойная картинка, с минимум вмешательства в настройки. Есть такое подозрение, что в реализации кодека у ффмпег для этого формата присутствует ошибка.
Закрытое он врядли использует. Тот же xvid, может чья-то сборка. xvid как раз очень тюнингуют, чтобы получить что-то пристойное. В частности используют нестандартную матрицу. Если посмотреть в mediainfo, то будет видно, что Matrix: Custom. Скорее всего он также применяет предфильтрацию: шумоподавление, дебандинг. Хотя, на шумных исходниках меньше блочности появляется. Я бы так сказал, что съедобно кодировать в xvid, это искусство, которое я не осилил.
Насчет ошибки, ходили слухи, что в xvid до 65 что-ли версии был какой-то баг. Может быть с закрытым (старым) Divx что-то путное получится? Как ни странно, я встречал очень неплохие рипы с ним, но в основном с шумного исходника (чтобы не было бандинга и квадратов) с минимальным колебанием битрейта. Явно ручное исключение делается только для сложных сцен, типа воды, где битрейт увеличивают. На рутрекере есть кодек 2008 года, можно запустить в wine + virtualdubmod.