https://www.opennet.ru/openforum/vsluhforumID3/120956.html После десяти месяцев разработки доступен мультимедиа-пакет FFmpeg 4.3, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53162<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#59 Tue, 23 Jun 2020 12:21:19 GMT Закрытое он врядли использует. Тот же xvid, может чья-то сборка. xvid как раз очень тюнингуют, чтобы получить что-то пристойное. В частности используют нестандартную матрицу. Если посмотреть в mediainfo, то будет видно, что Matrix: Custom. Скорее всего он также применяет предфильтрацию: шумоподавление, дебандинг. Хотя, на шумных исходниках меньше блочности появляется. Я бы так сказал, что съедобно кодировать в xvid, это искусство, которое я не осилил.<br>Насчет ошибки, ходили слухи, что в xvid до 65 что-ли версии был какой-то баг. Может быть с закрытым (старым) Divx что-то путное получится? Как ни странно, я встречал очень неплохие рипы с ним, но в основном с шумного исходника (чтобы не было бандинга и квадратов) с минимальным колебанием битрейта. Явно ручное исключение делается только для сложных сцен, типа воды, где битрейт увеличивают. На рутрекере есть кодек 2008 года, можно запустить в wine + virtualdubmod.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#58 Mon, 22 Jun 2020 21:28:20 GMT Попробую ваши предложения, но есть сильное ощущение, что это всё я делал, но так и не получил даже близко той картинки что выкладывает scarabey на торрентах (естественно используя те же исходники видео). У скарабея в бложике есть статья как они кодируют, и там используется закрытый виндовый кодек. Так вот там уверенно получается довольно пристойная картинка, с минимум вмешательства в настройки. Есть такое подозрение, что в реализации кодека у ффмпег для этого формата присутствует ошибка.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#57 Sun, 21 Jun 2020 19:19:58 GMT Да вот только у меня двухъядерный проц. Виндовый AviSynth (QTGMC preset Faster) загружает его при дефолтных настройках на 70%, но кодирует на 25-33% быстрее, чем линусковый VaspourSynth, который загружает на 100%. При том, что на винде, выставив минимальный приоритет, еще можно чем-то заниматься, а на линуксе, несмотря на приоритеты, отзывчивость падает сильнее.<br><br>Знаю, питон только парсит скрипты, аналог которых (точнее устаревшие порты, как и в случае с плагинами) это avs и avsi. Только вот avs* не тянет в систему питонятину, а только маленький avisynth.dll.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#56 Sun, 21 Jun 2020 19:14:47 GMT Съел vapoursynth мне мозг в очередной раз. Возвращаюсь на старый добрый avisynth. Все-таки не тянет линукс десктоп даже в 2020 году...<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#55 Sun, 21 Jun 2020 04:22:47 GMT &gt; libavdevice.so.58 зависит от libvapoursynth-script.so.0<br><br>Потому что ffmpeg 4.3 я собрал с поддержкой vapoursynth. Развел слаку из убунты. Кто-то скажет "есть же гента" (или арч), но я не люблю роллинг, потому что там нет постоянства.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#54 Sun, 21 Jun 2020 04:16:01 GMT &gt; mpv 0.14 эту библиотеку не ищет<br><br>Потому что он собран с системным /usr/lib/libavdevice-ffmpeg.so.56, который про vapoursynth ничего не знает.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#53 Sun, 21 Jun 2020 04:12:42 GMT ldd показывает зависимости зависимостей. mpv зависит от libavdevice.so.58, а libavdevice.so.58 зависит от libvapoursynth-script.so.0 и libpng12.so.0, хотя libpng12 в Debian Buster тоже нет. При просмотре в двоичном редакторе дебиановского mpv, я не нашел никаких упоминаний vapousynth. А в собранном мной бинарнике упоминания были. Короче, сбил меня с толку ldd. Соответственно, в посте выше я чушь написал.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#52 Sun, 21 Jun 2020 03:28:27 GMT Еще наблюдение. Команда -vtag xvid не играет никакой роли. При кодировании в mkv кодек всегда помечается MPEG4, при кодировании в avi всегда xvid. По крайней мере, по данным MediaInfo. Еще MediaInfo не может извлечь информацию о B кадрах и матрице кодирования из AVI, закодированных в ffmpeg. Поэтому кодировать ffmpeg libxvid лучше в MKV.<br> https://www.opennet.ru/openforum/vsluhforumID3/120956.html#51 Sun, 21 Jun 2020 03:17:52 GMT Интересное наблюдение. Проверка 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 в зависимостях, хотя в арче обычно собирают со всеми флагами.<br><br>А вот mpv 0.29 из deb-multimedia для Buster явно требует vapoursynth http://deb-multimedia.org/dists/stable/main