FFmpeg больше не включает пресеты и профили на основе текстового файла для libx264, то есть то, что вы использовали с -vpreопцией. Они были изношено и удалены в пользу доступа фактические x264 пресеты, профили (и мелодии) с -preset, -profile:vи -tuneварианты. Старые текстовые файлы эмулировали только официальные пресеты и профили x264, и из-за нескольких ограничений не могли предложить полную функциональность, которую обеспечивает новая система. Это также намного легче поддерживать.
Кроме того, многие кодеры имеют свои собственные отдельные параметры; также называется "частные варианты". Вам нужно будет посмотреть опции кодирования аудио и видео для распространенных кодеков в онлайн-документации FFmpeg или проверить вывод ffmpeg -h fullполного списка поддерживаемых опций. Например, x264 перечисляет свои параметры libx264 AVOptionsв выводе полной справки.
Если ваш ffmpeg поддерживает, -presetто никакие пресеты текстовых файлов не должны использоваться, и FFmpeg больше не поставляется с какими-либо другими, кроме некоторых нестандартных пресетов iPod. Это распространенное заблуждение, что текстовые пресеты можно просто скопировать из любого места и использовать с любым ffmpeg. Это не соответствует действительности и приведет к поломке.
В основном, пресеты позволяли вам делать следующие вещи:
Контроль качества
Качество контролируется либо путем указания скорости передачи -b:v(для видео) или -b:a(для аудио), либо путем указания любого другого метода кодирования, который может поддерживать кодек.
Для x264 существуют различные методы кодирования, при этом метод коэффициента постоянной скорости является наиболее сложным. Это приводит к переменному битрейту, но в целом хорошее качество за один проход. Значения CRF варьируются от 0 до 51, но нормальные значения находятся где-то между 19 и 26, в зависимости от вашего источника и того, какое качество вы хотите. 23 по умолчанию, так что вы можете, например, выбрать 18 для «высокого качества» и 28 для «низкого качества», что бы это ни значило для вас.
ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4
У x264 есть и другие методы кодирования , но это выходит за рамки этого.
Эти профили определяют набор функций, которые кодер может использовать для соответствия возможностям определенного декодера. В недавнем FFmpeg используйте следующий синтаксис, чтобы указать профиль, где профиль может быть baseline, mainили high:
ffmpeg -i input.mp4 -c:v libx264 -profile:v baseline output.mp4
Дополнительную информацию и информацию о том, когда вам следует использовать какой профиль, смотрите: В чем различия между профилями H.264?
Выберите кодировку x264 preset
Эти пресеты влияют на скорость кодирования. Использование более медленных пресетов обеспечивает лучшее сжатие или качество для каждого размера файла, в то время как более быстрые пресеты дают худшее сжатие. В общем, вы должны просто использовать пресет, который вы можете позволить себе ждать. Предварительные настройки могут быть ultrafast, superfast, veryfast, faster, fast, medium( по умолчанию), slowи veryslow. Вот пример:
ffmpeg -i input.mp4 -c:v libx264 -preset slow output.mp4
Кодировать видео без потерь
Это возможно, указав CRF 0, поэтому просто используйте -crf 0:
ffmpeg -i input.mp4 -c:v libx264 -crf 0 output.mp4
Наконец, давайте поговорим о ProRes быстро. ProRes принимает либо фиксированный битрейт с -b:v, либо вы можете указать профиль, который должен иметь значение от 0 до 3 , где битрейты выбираются в соответствии с профилем. Выше значит лучше:
ffmpeg -i input.mp4 -c:v prores -profile:v 0 output.mov
Ffmbc Wiki предполагает , что могут быть использованы имена профилей - это , однако , не удается в FFmpeg 1.0.
ffmpeg -i input.mp4 -c:v libx264 output.mp4? CRF: 23 и пресет: средний?Я провел тест, в котором я транскодировал (используя кодирование libx264
.mp4) видео высокого качества с видеокамеры Sony, используя полный диапазон предустановленных значений (кроме плацебо) для диапазона значений CRF (18, 21, 24 и 27). ). Я хотел знать, что даст мне лучшее сочетание скорости кодирования, качества вывода и размера файла.Для каждого значения CRF я дал каждой операции транскодирования балл за время кодирования (например, для CRF = 18, предустановленное значение сверхбыстрого времени 5,7 секунд получило балл 1,0, Veryslow-время 162 секунд получило 0, со всеми другие баллы масштабируются между). Я рассчитал выходной размер файла аналогичным образом, конечно же, наименьший файл получил лучший результат. Затем я добавил две оценки для «комбинированной» оценки скорости / размера.
Для каждого из четырех значений CRF «очень быстрая» предустановка была победителем в хендс-апе с почти идеальными показателями 1,94 (для CRF 18 и 21), 1,96 (CRF 24) и 1,97 (CRF 27). Я нахожу очень любопытным, что «очень быстрый» каждый раз генерирует файл с наименьшим размером , теряя только «очень низкий» и никогда не слишком.
Одно из различий, которое я заметил среди различных предустановленных значений, заключалось в том, что операционная система (Windows 7) давала мне разные эскизы. Более быстрые пресеты будут показывать миниатюру на несколько секунд в видео, где миниатюры для медленных пресетов будут отражать начальный кадр (и) видео. Это не важно для меня; что я узнал, так это то, что «очень быстрое задание» кажется легким выбором.
Вот мои результаты (в виде снимка электронной таблицы Excel):
Вот таблица Excel в виде csv-текста:
источник