https://mobile.opennet.me/openforum/vsluhforumID3/109502.html После четырёх месяцев разработки представлен (http://ffmpeg.org/download.html#release_3.2) мультимедиа-пакет FFmpeg 3.2 (http://ffmpeg.org/download.html#releases), включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Кроме изменений, созданных внутри проекта, в новую версию также включены все последние наработки, развиваемые в ветках ffmpeg-mt (http://gitorious.org/ffmpeg/ffmpeg-mt) (многопоточное декодирование) и libav (http://libav.org/) (форк FFmpeg). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer (http://www.mplayerhq.hu/).<br><br><br><br><br>Из изменений (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=RELEASE_NOTES;hb=release/3.2), добавленных (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;hb=release/3.2) в FFmpeg 3.2, можно выделить: <br><br><br><br><br><br>- Новые фильтры (https://ffmpeg.org/ffmpeg-filters.html): <br><br><br>- weave (https://ffmpeg.org/ff https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#42 Tue, 01 Nov 2016 13:26:04 GMT Я бы не использовал видеокарту. Нафик.<br><br>А так &#8212; 12-36 часов, в зависимости от степени перфекционизма и свежести процессора (x265, говорят, неплохо оптимизировали для AVX2).<br> https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#41 Tue, 01 Nov 2016 09:18:49 GMT Не нужно сравнивать среднестатистические уши и чужие :), не говоря уже о том, что если сравнивать на недопищалке для айфона то разницы и в mp3 на 64 КБит можно не заметить<br> https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#40 Mon, 31 Oct 2016 09:55:48 GMT &gt; ffmpeg кодеки и есть, их там ДО-ХРЕ-НА. Найти формат который ffmpeg не прожует - еще суметь надо. И никакой маздайной возни с кодекпаками и конфликтами кодеков.<br><br>Речь была не о кодеках, а об обработке видео и звука.<br> https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#39 Sun, 30 Oct 2016 21:39:31 GMT &gt; На том же Rutracker'е есть четкие ребята, спецы в своем деле - кодировании видео. Есть целые известные RG (Release Groups), которые "знают как надо". За многие годы они стали настоящими профи и делают шикарные рипы, которые весят очень мало, при этом имея превосходное качество.<br><br>Значительная часть рипов на рутрекере до сих пор делается кодеком XviD, который устарел около 10 лет назад. При этом о &#171;превосходном качестве&#187; при минимальном размере, естественно, говорить не приходится.<br>Сейчас мэйнстрим &#8212; формат H.264 и кодек x264, передовые технологии &#8212; форматы VP9 (кодек libvpx) и H.265 (x265), будущее &#8212; AoM. Всё это доступно в т.ч. и на Linux.<br><br>&gt; Я слышал для этого нужно мощное железо,<br><br>Сойдёт любое железо, вопрос только в скорости кодирования. Каждое новое поколение кодеков жмёт медленней примерно на порядок. Для скорости libvpx-vp9 очень полезно наличие набора инструкций AVX2.<br><br>&gt; кодировать в несколько проходов (и якобы чем больше, тем лучше)<br><br>Как правило, кодеки могут коди https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#38 Sun, 30 Oct 2016 21:05:33 GMT &gt; 3. Она там используют x264/x265, а что насчет открытых кодеков? Они не <br>&gt; такие хорошие?Есть ли конкурент x264/x265?<br><br>Сами эти кодеки открытые. Но патентованные. В exUSSR на это можно и забить. Если забивать не хочется и например хочется в браузере смотреть - посмотри на VP9. Он легко обижает x264 по битрейт/качество и рубается на равных с x265. Но вот кодирует он медленно. То-есть это конечно же настраивается, но на уровнях максимального качества он таки слоупок.<br> https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#37 Sun, 30 Oct 2016 21:03:32 GMT &gt; Сколько времени займет перекодировать его в 8 гиговый рип максимального качества? <br><br>А это зависит от того сколько ты готов ждать :). Чем больше ресурсов проца кодек может скушать тем лучше он может компенсировать движение и проч, достигая лучшего качества при меньшем размере или меньшего размера при равном качестве. И сколько это займет больше всего определяется мощностью проца и пределами толерантности.<br><br>Скажем если жать в VP9 - он делает h.264 по битрейт/качество как с куста. Но на самых медленных режимах скорость кодирования может начать измеряться не в fps а в fpm. Frames per minute. И тогда кодирование может занять до-фи-га. В общем перфекционизм штука такая...<br> https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#36 Sun, 30 Oct 2016 20:58:54 GMT &gt; Но, конечно, главное - это грамотно подобрать кодек и параметры кодирования. Кодеки <br>&gt; под Linux есть, и если не боишься командной строки и есть <br>&gt; куча свободного времени, то всё возможно.<br><br>В ffmpeg кодеки и есть, их там ДО-ХРЕ-НА. Найти формат который ffmpeg не прожует - еще суметь надо. И никакой маздайной возни с кодекпаками и конфликтами кодеков. <br><br>То что человеку надо - грамотно параметры кодирования выбрать. Все это без проблем, особенно для штучных вещей. Если с ffmpeg не вломак повозиться - он умеет немеряно. Насколько я помню - гугель вроде как именно им транскодирует видео на ютубе, а для них все это - вопрос на миллион и даже не один.<br> https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#35 Sun, 30 Oct 2016 20:50:34 GMT &gt; имея превосходное качество. Я слышал для этого нужно мощное железо, которое <br>&gt; позволяет кодировать в несколько проходов (и якобы чем больше, тем лучше)<br><br>Проходов делается два. В первом проходе кодек делает быстрое прикидочное кодирование для общего понимания насколько сложно те или иные кадры кодировать. Соотношение размера и качества при этом настолько ГЭ что результат обычно даже не сохраняют. Только статистику по кадрам. Хотя в ffmpeg можно и видео с первого прохода сохранить, но его соотношение размера и качества - полный трэш.<br><br>Во втором проходе делается "настоящее" кодирование. За счет первого прохода кодек заранее знает что будет дальше. Поэтому может гораздо более грамотно раскинуть бюджет размера файла (или бандвиза). Потому что априори знает - насколько сложно (затратно по битам) кодировать то что будет дальше.<br> <br>&gt; и все такое. Вобщем вопрос в чем - можно ли создавать <br>&gt; такие "самые четкие рипы", прям топовые рипы - на Linux.<br><br>Да. Используй двухпроходное кодирование. Ffmpeg его умеет и т https://mobile.opennet.me/openforum/vsluhforumID3/109502.html#34 Sun, 30 Oct 2016 20:31:08 GMT &gt; Debian же давно пообещал вернуться на ffmpeg по дефолту.<br><br>Так они и вернулись. По поводу чего пара свежих убунт уже вышли с ffmpeg'ом.<br>