Сжимаем фильмы с помощью ffmpeg - Видео лаборатория - eMule-Rus.Net Форум муловодов

Перейти к содержимому



Сжимаем фильмы с помощью ffmpeg


  • Вы не можете ответить в тему
  • Вы не можете создать новую тему
Сообщений в теме: 87

#1 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 17 Март 2018 - 22:16

FFmpeg — набор свободных библиотек с открытым исходным кодом, которые позволяют записывать, конвертировать и передавать цифровые аудио- и видеозаписи в различных форматах. Среди других программ он замечателен тем, что может работать на любой платформе с любыми форматами. Кроме того, он обладает широкими возможностями настройки и большой гибкостью. С помощью ffmpeg можно перекодировать аудио и/или видеотрек, перемультиплексировать запись (изменить формат файла без перекодирования), получить информацию о медиафайле, разбить на части/вырезать фрагмент или склеить видео из нескольких кусков, изменить разрешение, извлечь/наложить звук, увеличить/уменьшить скорость видео, обрезать картинку, превратить набор картинок в видео и порезать видео на картинки, работать с субтитрами, накладывать водяные знаки и т.д. Некоторые готовые рецепты можно посмотреть в этих статьях:

Понимаем FFmpeg
Полезные команды ffmpeg   
19 команд ffmpeg для любых нужд   
FFmpeg как консольный видеоредактор  

Есть, правда, один момент. Все эти действия выполняются через консоль (из командной строки). Неискушенному пользователю это может показаться неудобным, но, освоив его, вы получите в свои руки очень мощный и универсальный инструмент. Графические инструменты часто сбоят, они могут не поддерживать тот или иной формат. Библиотека ffmpeg поддерживает все существующие форматы и работает практически всегда, если правильно ею пользоваться. Кроме того, консольную утилиту легко использовать в скрипте или в командном файле для групповой обработки медиафайлов. К примеру, я без особых физических затрат перекодировал коллекцию из порядка двенадцати тысяч различных видеозаписей. При этом компьютер все делал сам, достаточно было запустить скрипт; мне оставалось лишь изредка следить за процессом. Конвертировал я, в основном, старые фильмы и мультфильмы из архива Arjlover, представленные в формате avi/(Xvid и DivX), в формат mkv/h.264. Качество изображения при этом сильно не изменилось, а объем занимаемого дискового пространства значительно сократился. В этой теме приводятся некоторые материалы (в вольном переводе), касающиеся общих принципов кодирования с помощью ffmpeg, которые довелось изучить в процессе работы, а также несколько примеров, демонстрирующих, как влияют разные настройки на степень сжатия, качество и скорость кодирования. Эти основные режимы и настройки также можно применять и в графических видеоредакторах, если вы не можете без них обойтись.

Сообщение отредактировал Al71: 17 Март 2018 - 22:34


#2 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 17 Март 2018 - 22:18

Для начала рассмотрим режимы управления битрейтом применительно к x264/x265/vpx.

Что такое "управление битрейтом" (rate control)? Это решения и действия кодера относительно того, сколько битов нужно выделить на данный кадр. Цель кодирования видео "с потерями" заключается в том, чтобы сэкономить как можно больше битов, уменьшив размер файла относительно оригинала и сохранив при этом как можно более высокое качество. Режимы управления битрейтом могут принимать различные формы: 1- и 2-проходное кодирование, “CBR” и “VBR”, быть может, вы слышали о “VBV” или “CRF”.
Почему это должно вас интересовать? Довольно часто вы видите примеры команд для кодирования видео, в которых применяется неправильный режим управления битрейтом или задаются неправильные битрейты. Этот пост представляет собой краткое руководство по различным режимам; в каких случаях лучше использовать тот или иной режим.

Переменный битрейт (VBR) против постоянного (CBR)

Многие из тех, кто еще помнит времена mp3, знакомы со способами управления битрейтом в аудиокодеках. Чтобы сделать рип компакт-диска, некоторое время использовался CBR, чуть позже появился VBR. Переменный битрейт гарантировал, что вы достигнете наименьшего возможного размера файла при максимально возможном качестве при заданных ограничениях (в соответствии с уровнем качества VBR).
Проще говоря, VBR позволяет кодеру использовать больше битов для материала, который сложно кодировать, и экономить биты в тех частях файла, которые кодировать легко. Что такое сложно и легко с точки зрения сжатия? Например, сцены, где много движения, требуют большего количества битов для кодирования, поскольку разница между соседними видеокадрами будет больше. Большие объекты с мелкими деталями и сложные текстуры также трудно кодировать.

Ваши намерения

Выбор режима управления битрейтом зависит от того, для чего вы кодируете файл:
1. Для архива. Вы хотите сжать файл для его хранения в своем архиве, например, на внешнем жестком диске или в вашем сетевом хранилище. Файл должен иметь максимально возможное качество при минимально возможном размере файла, но вам не важен точный размер.
2. Потоковая передача. Вы хотите передавать файл через Интернет, используя типичные решения для потокового видео по требованию (VoD), такие как HTTP progressive download или HTTP Adaptive Streaming. Вы должны быть уверены, что битрейт в файле не превышает определенной величины.
3. Прямая трансляция в реальном времени -- как и п.2, но нужно, чтобы кодирование выполнялось как можно быстрее.
4. Кодирование для устройств. Вы хотите поместить свой файл на DVD, Blu-ray и т.д. Вам надо получить файл определенного размера.

Примечание: такие кодеры, как x264, по умолчанию не заполняют кадры излишними битами. Это означает, что если у вас есть сцена, которую очень легко кодировать, ваш битрейт может оказаться ниже, чем тот, который вы указали. Не беспокойтесь об этом - просто имейте в виду, что нет смысла добиваться точного целевого битрейта, если он избыточен.

Постоянный параметр квантования (CQP)

Параметр квантования регулирует степень сжатия для каждого макроблока в кадре. Высокие значения означают более грубое квантование, большее сжатие и более низкое качество. Нижние значения означают противоположное. QP варьируется от 0 до 51 в H.264, и вы можете легко установить фиксированный QP для всего процесса кодирования с x264 и x265:

ffmpeg -i <input> -c:v libx264 -qp 23 <output>
ffmpeg -i <input> -c:v libx265 -x265-params qp=23 <output>

Если вы не знаете, что делаете, не используйте этот режим! Установка фиксированного QP означает, что результирующий битрейт будет жестко зависеть от сложности сцены, и входное видео будет кодироваться неэффективно. Вы можете зря потратить место и вы не контролируете фактический битрейт.

Хорош для: Исследования кодирования видео
Плохой выбор для: Почти всего остального

Средний битрейт (ABR)

Здесь мы задаем кодеру целевой битрейт и надеемся, что он сам решит, как достичь этого битрейта:

ffmpeg -i <input> -c:v libx264 -b:v 1M <output>
ffmpeg -i <input> -c:v libx265 -b:v 1M <output>
ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M <output>

Избегайте использования этого режима! Один из главных разработчиков x264 говорит, что вы никогда не должны его использовать. Почему? Поскольку кодер не знает точно, что его ждет впереди, ему придется угадывать, как обеспечить этот средний битрейт. Это означает, что текущий битрейт будет сильно меняться, особенно в начале клипа, пока в какой-то момент не достигнет целевого. Особенно для потоковой передачи типа HAS это приводит к огромным колебаниям качества на коротких сегментах.
Это не режим постоянного битрейта! В то время как ABR технически является режимом VBR, он не намного лучше, чем указание постоянного битрейта (в смысле качества сжатия).

Хорошо подходит для: быстрого и грязного кодирования
Плохо для: почти всего

Постоянный битрейт (CBR)

Если это требуется в вашем случае, вы можете заставить кодер всегда использовать определенный битрейт, включив опцию nal-hrd:

ffmpeg -i <input> -c:v libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M <output>

Выходной файл должен быть формата .ts (MPEG-2 TS), поскольку мр4 не поддерживает наложение NAL. Обратите внимание, что этот режим будет загружать сеть, даже если ваш источник легко кодировать, но он гарантирует, что битрейт остается постоянным по всему потоку. Использование этого режима может иметь смысл в некоторых приложениях, но, скорее всего, вы захотите разрешить кодеру использовать более низкий битрейт, когда это возможно.

Хороший выбор для: Поддержания постоянного битрейта (duh); видеостримминга (например, Twitch)
Плохой выбор для: Архива; эффективного использования полосы пропускания

2-проходное кодирование со средним битрейтом (2-Pass ABR)

Выполняя два (или более) прохода, кодер получает возможность оценить, что его ждет впереди. Он может рассчитать затраты на кодирование кадра в первом проходе, а затем, во втором проходе, более эффективно использовать доступные биты. Это гарантирует, что качество вывода будет наилучшим при определенном ограничении скорости передачи.

Для x264:
ffmpeg -i <input> -c:v libx264 -b:v 1M -pass 1 -f mp4 /dev/null
ffmpeg -i <input> -c:v libx264 -b:v 1M -pass 2 <output>.mp4

Для x265:
ffmpeg -i <input> -c:v libx264 -b:v 1M -x265-params pass=1 -f mp4 /dev/null
ffmpeg -i <input> -c:v libx264 -b:v 1M -x265-params pass=2 <output>.mp4

Для vp9:
ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -pass 1 -f webm /dev/null
ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -pass 2 <output>.webm

Это самый простой способ кодирования файла для потоковой передачи. С двумя оговорками: вы не знаете, каково будет итоговое качество, поэтому, чтобы убедиться, что ваш битрейт действительно достаточно высок для отдельных сложных участков, вам нужно будет проделать некоторые тесты. Другим недостатком этого режима является то, что в битрейте могут быть локальные пики, то есть вы можете отправлять больше, чем может получить ваш клиент. Что касается выбора битрейта, YouTube дает рекомендации по характеристикам загружаемых файлов, но имейте в виду, что они оптимизированы для загрузки файлов с хорошим качеством, поэтому на практике вы также можете выбрать более низкие битрейты.

Хорошо для: Достижения определенного целевого битрейта; кодирования для устройств
Плохо: Если вам нужно быстрое кодирование (например, прямая потоковая трансляция)

Постоянное качество (CQ) / Постоянный коэффициент скорости (CRF)

CRF обеспечивает постоянное качество сжатия в процессе кодирования. Это штука, которую можно «установить и забыть» - просто укажите crf и пусть кодер сделает все остальное. По своему принципу работы CRF является более совершенным методом, чем CQP, и обеспечивает эффективность сжатия лучше него. [CRF позволяет задействовать адаптивное квантование, т. е. сэкономить битрейт за счёт качества, в то время как CQP гарантирует кодирование с постоянной степенью сжатия для всех кадров и раздувает размер файла, но с шикарным качеством. CRF же действует подобно двухпроходному кодированию, пытаясь распределить битрейт в зависимости от сложности сцены. В итоге, при одинаковом размере выходного файла, в целом crf будет выглядеть качественнее.]

ffmpeg -i <input> -c:v libx264 -crf 23 <output>
ffmpeg -i <input> -c:v libx265 -crf 28 <output>
ffmpeg -i <input> -c:v libvpx-vp9 -crf 30 -b:v 0 <output>

В H.264 и H.265 CRF находится в диапазоне от 0 до 51 (подобно QP). 23 - значение по умолчанию для x264, а 28 - значение по умолчанию для x265. При crf=18 (или 24 для x265) результат визуально воспринимается как полное соответствие оригиналу; все, что ниже, скорее всего, будет попросту раздувать размер файла. Значения ± 6 приведут примерно к уполовиненному или удвоенному первоначальному битрейту. Для VP9 CRF может быть от 0 до 63.
Единственным недостатком этого режима является то, что вы не можете сказать заранее, каким будет окончательный размер файла.
Заметьте, что 2-проходный режим и однопроходное CRF-кодирование с одинаковым итоговым битрейтом будут одинаковыми по качеству. Основное отличие состоит в том, что с двухпроходным режимом вы можете контролировать размер файла (если это требуется), тогда как при CRF вы просто указываете качество кодирования, которое хотите получить.

Хороший выбор для: Архива; достижения наилучшего качества
Плохо для: Потоковой передачи; получения файла с определенным битрейтом / размером

Кодирование с ограничением битрейта (VBV)

Video Buffering Verifier (VBV) обеспечивает ограничение битрейта, чтобы он не превысил определенного максимума. Это полезно для потоковой передачи, так как теперь вы можете быть уверены, что в течение определенного отрезка времени не будете отправлять битов больше, чем обещали. VBV может использоваться как с двухпроходным VBR (используйте его в обоих проходах), либо с CRF-кодированием -- его можно «добавить» к уже представленным режимам управления битрейтом.
Задействуйте VBV с параметрами -maxrate и -bufsize для установки максимального битрейта и размера буфера:

ffmpeg -i <input> -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M <output>
ffmpeg -i <input> -c:v libx265 -crf 28 -x265-params vbv-maxrate=1000:vbv-bufsize=2000 <output>

VP9 имеет аналогичный режим, не называемый VBV, но идея та же:

ffmpeg -i <input> -c:v libvpx-vp9 -crf 30 -b:v 2M <output>

Примечание. Если вы кодируете для потоковой передачи в реальном времени и хотите ускорить процесс кодирования, для x264 и x265 можно добавить опции -tune zerolatency и -preset ultrafast. Они снижают качество, которое вы получаете при определенном битрейте (эффективность сжатия), но значительно ускоряют процесс. Для libvpx-vp9 можно установить -quality realtime и -speed.

Использование этого режима:

x264:
ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f mp4 /dev/null
ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 <output>

x265:
ffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=1:vbv-maxrate=1000:vbv-bufsize=2000 -f mp4 /dev/null
ffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=2:vbv-maxrate=1000:vbv-bufsize=2000 <output>

VP9:
ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f webm /dev/null
ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 <output>

Примечание. Здесь также может использоваться однопроходный метод, который, согласно разработчику x264, часто бывает не хуже двух проходов, но он не будет сжимать видео так же эффективно.
Как определить размер буфера bufsize? Это зависит от того, какие колебания битрейта вы допускаете. Хорошим значением по умолчанию является размер буфера в два раза больше максимальной скорости, но допуски могут отличаться в зависимости от настроек потоковой передачи. Если вы хотите строже ограничить скорость вашего потока, попробуйте настроить bufsize на половину максимальной скорости или меньше.
Когда вы применяете кодирование VBV в CRF, хитрость заключается в том, чтобы найти значение CRF, которое в среднем выдает нужный максимальный битрейт, но не более. Если ваш результат все время пытается превысить максимальный битрейт, CRF, вероятно, был слишком низким. В этом случае кодер пытается израсходовать биты, которых у него нет. С другой стороны, если у вас высокий CRF, при котором битрейт не достигает максимального значения, вы можете снизить его, чтобы улучшить качество. Например, вы кодируете с CRF=18, но без VBV. Ваше видео выходит со средним битрейтом 3,0 Мбит/с. Но вы хотите, чтобы ваши настройки VBV ограничивали видео на 1,5 Мбит/с, поэтому вам нужно увеличить CRF до 24, чтобы получить только половину битрейта.

Хорошо для: потоковой передачи с ограничениями полосы пропускания; прямой трансляции (с CRF, 1 проход); потоковой передачи VoD (с целевым битрейтом, 2-проходный)
Плохо для: людей, которые хотят поиграть; архив

Использованы материалы: Understanding Rate Control Modes (x264, x265, vpx)

#3 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 17 Март 2018 - 22:19

Теперь обратимся к краткому руководству по выбору опций кодека Н.264 (libx264).

Для этого кодека два основных режима управления битрейтом, которые обычно предлагаются для общего пользования -- это CRF (Constant Rate Factor) и 2-проходный ABR. Алгоритм управления битрейтом определяет, сколько бит будет использовано для каждого кадра. Это, в свою очередь, определяет размер выходного файла, а также его качество. Разные режимы управления битрейтом описаны в предыдущем посте. [Из него можно легко догадаться, что для своих целей я выбрал именно режим CRF.]

Constant Rate Factor (CRF)

Этот режим используется, когда вы хотите получить качественное видео и не стремитесь подогнать файл под определенный размер. Он обеспечивает наивысшую эффективность сжатия за один проход. Подстраивая так называемый квантователь для каждого кадра, кодер выбирает битрейт, необходимый для поддержания заданного уровня качества. Минусом является то, что вы не можете заранее определить размер выходного файла или конкретный битрейт, что делает этот метод неподходящим для записи на диски или потоковой передачи.

Выбор значения CRF

Возможные значения CRF лежат в пределах 0-51. 0 означает кодирование без потерь (lossless), 23 берется по умолчанию, а 51 -- наихудшее качество при максимальной степени сжатия, то есть чем меньше значение, тем выше качество кодирования. Субъективно воспринимаемые разумные значения лежат в диапазоне 17-28. При CRF равном 17 или 18 картинка визуально будет такая же, как во входном файле, но формально это не lossless. Зависимость битрейта и размера файла от CRF -- экспоненциальная, то есть увеличение/уменьшение CRF на 6 единиц приводит к уменьшению/увеличению битрейта примерно в два раза.
Выбирайте наивысшее значение CRF, которое все еще обеспечивает приемлемое качество. Если качество вас устраивает, попробуйте увеличить CRF, если нет -- уменьшить.

Опции preset и tune

Preset -- это набор предустановленных опций, которые определяют соотношение скорости кодирования и эффективности сжатия. Это означает, что чем дольше процесс кодирования, тем лучше сжатие (как отношение качества к размеру файла).
Возможные значения:
    ultrafast
    superfast
    veryfast
    faster
    fast
    medium  (default)
    slow
    slower
    veryslow
    placebo – игнорируйте как бесполезное

Выбирайте как можно более медленную скорость кодирования, на которую у вас хватит терпения.

Вы также можете использовать настройки tune в зависимости от типа входного видео. Текущие значения включают:
    film – используйте для фильмов с высоким качеством; снижает деблокинг
    animation – хороший выбор для мультиков; использует более высокий деблокинг и больше референсных кадров.
    grain – сохраняет зернистую структуру в старых фильмах
    stillimage – хорош для видео типа слайд-шоу
    fastdecode – обеспечивает быстрое декодирование путем отключения некоторых фильтров
    zerolatency – хорош для быстрого кодирования и прямой потоковой трансляции с малой задержкой (low-latency)
    psnr – используется только разработчиками кодека, игнорируйте
    ssim – используется только разработчиками кодека, игнорируйте

Еще одна опция -- это -profile:v, которая определяет профиль H.264 выходного файла. Ее можно не указывать, если только ваше устройство не ограничено определенным профилем и не имеет проблемы с совместимостью. Возможные значения:
    baseline, main, high (default), high10, high422, high444

Список всех возможных значений preset и tune в Linux можно получить командой

ffmpeg -hide_banner -f lavfi -i nullsrc -c:v libx264 -preset help -f mp4 -

(Пользователям Windows надо заменить выходное устройство "-" на NUL)

Пример использования CRF

Эта команда кодирует видео с неплохим качеством, используя опцию -preset slow для более эффективного сжатия:

ffmpeg -i input.avi -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv

Здесь форматы входного и выходного файлов определяются по их расширению, видео кодируется библиотекой кодека h264 (libx264) c CRF=22 и preset=slow, а звуковая дорожка просто копируется (как правило, перекодировать уже сжатый звук не рекомендуется, так как это неизбежно ведет к его ухудшению, даже при более высоком битрейте. Качественный звук можно получить только из lossless оригинала).
Если вы кодируете несколько однотипных видео, используйте одни и те же параметры для всех файлов, это гарантирует схожее качество.

2-проходное кодирование ABR

Используйте этот метод, если вы ориентируетесь на определенный размер выходного файла, и если качество вывода от кадра к кадру менее принципиально. Это лучше всего объяснить на примере. Ваше видео длится 10 минут (600 секунд) и должно занимать 200 MiB. Так как битрейт = размер файла / продолжительность:

(200 MiB * 8192 [преобразуем MiB в kBit]) / 600 секунд = ~2730 kBit/s (суммарный битрейт)
2730 - 128 kBit/s (заданный аудио битрейт) = 2602 kBit/s (видео битрейт)

Эти расчеты не требуются, если вы уже знаете, какой окончательный (средний) битрейт вам нужен.

Пример:

Для применения двухпроходного режима вам нужно запустить ffmpeg дважды с почти одинаковыми настройками, за исключением:
     В проходах 1 и 2 используйте опции -pass 1 и -pass 2 соответственно.
     В проходе 1 вывод осуществляется в нулевой файловый дескриптор, а не в реальный файл. (При этом создается файл журнала, который понадобится ffmpeg для второго прохода).
     В проходе 1 вам нужно указать выходной формат (опцией -f), который соответствует формату вывода, который вы будете использовать в pass 2.
     В проходе 1 укажите аудиокодек, используемый в проходе 2; во многих случаях опция -an в проходе 1 не будет работать.

Например:

ffmpeg -y -i input -c:v libx264 -b:v 2600k -pass 1 -c:a aac -b:a 128k -f mp4 /dev/null && \
ffmpeg -i input -c:v libx264 -b:v 2600k -pass 2 -c:a aac -b:a 128k output.mp4

(Пользователям Windows следует указывать NUL вместо /dev/null и ^ вместо \).

Как и в случае с CRF, здесь можно задавать опции -preset, -tune и -profile:v.


Дополнительная информация и советы

Совместимость

Если вы хотите, чтобы ваше видео воспроизводилось на самых ранних устройствах, поддерживающих Н.264, можно использовать следующую опцию:
-profile:v baseline -level 3.0
Это ограничит некоторые возможности кодека, но обеспечит лучшую совместимость (хотя обычно в этом нет необходимости, и более высокие профили могут обеспечить то же качество видео при меньшем битрейте).

Кроме того, вы можете использовать опцию -vf format=yuv420p (или -pix_fmt yuv420p, что то же самое) для обеспечения совместимости с QuickTime и большинством других проигрывателей/устройств, поддерживающих только этот формат цветовой субдискретизации.

Быстрая проверка настроек

Чтобы иметь представление, как будет выглядеть видео, не кодируя файл целиком, используйте опции -ss и -t/-to.
-ss задает время начала фрагмента в секундах либо в формате HH:MM:SS от начала файла.
-t -- продолжительность фрагмента.
-to -- время окончания фрагмента, отсчитываемое от начала файла.


Использованы материалы: H.264 Video Encoding Guide

#4 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 17 Март 2018 - 22:21

Обратная операция (из mkv в avi)

Кодирование в Н.264 удобно для хранения фильмов, так как позволяет существенно сэкономить дисковое пространство, но что делать, если ваш телевизор настолько древний, что поддерживает только старый MPEG-4(Xvid/DivX) в формате avi, а в вашем распоряжении только mkv-файл? В этом случае, можно воспользоваться внешней библиотекой libxvid:

ffmpeg -i input.mkv -c:v libxvid output.avi

..или встроенным кодером mpeg4:

ffmpeg -i input.mkv -c:v mpeg4 -vtag xvid output.avi

Встроенный кодер имеет то преимущество, что не требует внешней библиотеки. Оба кодера должны обеспечивать аналогичный вывод, но при низком битрейте/качестве видео (например, 1000 кбит/с для контента 720p) libxvid будет обеспечивать лучшее качество, чем mpeg4.
По умолчанию таблица кодов (FourCC), записываемая в файл с кодировкой MPEG-4, будет FMP4. Если вы хотите другую таблицу кодов, используйте опцию -vtag. Например, -vtag xvid будет записывать таблицу кодов xvid.

Переменный битрейт (VBR) с опцией -qscale

Вы можете выбрать уровень качества видео с помощью параметра -qscale:v n (или -q:v n), где n - число от 1-31, при этом 1 имеет наивысшее качество/наибольший размер файла, а 31 - наименьшее качество/наименьший размер файла. Это режим с переменным битрейтом, примерно аналогичный использованию -qp (постоянный QP [параметр квантования]) с x264. В большинстве случаев это предпочтительный метод.
Уровень качества звука задается параметром -qscale:a (или -q:a). Значение изменяется в зависимости от аудиокодека.

Пример:

ffmpeg -i input.mkv -c:v mpeg4 -vtag xvid -qscale:v 3 -c:a libmp3lame -qscale:a 4 output.avi

(здесь использована стандартная библиотека libmp3lame для кодирования звука в mp3)
Значение -qscale:v 1 используется редко. Обратите внимание, если вы выберете его, libxvid займет гораздо больше места, чем то же самое видео, сжатое mpeg4.

Постоянный битрейт (CBR)

Вы можете задать битрейт с помощью опции -b:v. Ее лучше всего использовать с двухпроходным кодированием. Нужный битрейт можно рассчитать аналогично 2-проходному режиму для x264 (см. предыдущий пост), исходя из продолжительности видео и нужного размера.

Пример 2-проходного кодирования:

ffmpeg -y -i input.mkv -c:v mpeg4 -vtag xvid -b:v 555k -pass 1 -an -f avi /dev/null
ffmpeg -i input.mkv -c:v mpeg4 -vtag xvid -b:v 555k -pass 2 -c:a libmp3lame -b:a 128k output.avi

(Пользователям Windows следует указывать NUL вместо /dev/null)


Использованы материалы: MPEG-4 Encoding Guide

#5 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 17 Март 2018 - 22:28

Результаты сжатия в примерах.

Для начала возьмем какой-нибудь современный фильм в HD качестве. Например, с такими характеристиками:

Качество: BDRemux (1080p)
Продолжительность: 01:55:08
Размер: 21.7 GB
Видео: 1920x1080, 24.0 fps, ~22.0 Mbps max, 0.39 bits/(pixel*frame)

Кодирование этого фильма целиком на моем процессоре Xeon E5-2680 V2 (10 ядер/20 потоков, 3.1 ГГц turbo) c -crf 25 и -preset veryfast заняло около 19 минут и выдало файл размером 3.8 ГБ. Остальные значения я проверял на минутном отрезке этого фильма без аудиотреков, чтобы сделать сравнительный анализ скриншотов, а также скорости кодирования и степени сжатия.

(Примеры команд:
Чтобы извлечь минутный кусок исходного видео [без аудио], начиная с 33-й минуты:
ffmpeg -i film.mkv -c:v copy -map 0:0 -ss 00:33:00 -t 60 fragment.mkv
Чтобы сжать этот кусок:
ffmpeg -i fragment.mkv -c:v h264 -crf 23 -preset medium fragment-compressed.mkv
)
Исходный размер фрагмента - 149.3 МБ, средний битрейт - 19.5 Mbps
1. -crf 23 -preset medium (значения по умолчанию): время сжатия - 30 сек, размер сжатого файла - 29.7 МБ, средний битрейт - 3 888 kbps
2. -crf 25 -preset veryslow: время сжатия - 2 мин 5 сек, размер - 19.1 МБ, средний битрейт - 2 504 kbps
3. -crf 25 -preset slow: время сжатия - 45 сек, размер - 21.7 МБ, средний битрейт - 2 842 kbps
4. -crf 25 -preset medium: время сжатия - 31 сек, размер - 21.3 МБ, средний битрейт - 2 796 kbps
5. -crf 25 -preset fast: время сжатия - 24 сек, размер - 22.0 МБ, средний битрейт - 2 879 kbps
6. -crf 25 -preset veryfast: время сжатия - 18 сек, размер - 18.5 МБ, средний битрейт - 2 428 kbps

Скриншоты:
Исходный кадр: http://images.vfl.ru...fc/21000491.bmp
1: http://images.vfl.ru...89/21000267.bmp
2: http://images.vfl.ru...3f/21000268.bmp
3: http://images.vfl.ru...98/21000269.bmp
4: http://images.vfl.ru...24/21000270.bmp
5: http://images.vfl.ru...24/21000271.bmp
6: http://images.vfl.ru...b5/21000272.bmp


Анализ данного примера приводит к некоторым интересным результатам:
- размеры сжатого файла при кодировании с пресетами veryslow и veryfast (а следовательно, и средние битрейты) - почти одинаковы, но качество картинки с veryslow за счет лучшей эффективности процесса сжатия заметно выше, чем c veryfast, xoтя и времени требуется несоизмеримо больше.
- разница в качестве картинки между пресетами veryslow и veryfast с одним и тем же значением crf выглядит даже сильнее, чем разница с одним и тем же пресетом, но между crf 23 и 25, хотя при более низком crf размер файла и битрейт намного больше.
- размер файла и средний битрейт между пресетами slow, medium и fast сильно не разняться, но, судя по снимкам, чем медленнее кодирование, тем качество лучше, что закономерно.

Кроме того, сравнение однопроходного crf и 2-проходного кодирования x264 при одинаковом итоговом битрейте не выявляет заметных различий, что также соответствует теории:
CRF: http://images.vfl.ru...0c/21000348.bmp
2-PASS: http://images.vfl.ru...50/21000347.bmp

Однако при дополнительном использовании видеофильтров (например, ресайзинга -vf scale=1280:720), 2-проходное кодирование дает заметно лучший результат (по крайней мере, в данном конкретном примере):
CRF: http://images.vfl.ru...e8/21000399.bmp
2-PASS: http://images.vfl.ru...e5/21000398.bmp



Возьмем теперь один из обычных фильмов, представленных в архиве в DVD-качестве. Например, этот:

Качество: DVDRip
Продолжительность: 01:05:00
Размер: 1 261 МБ
Видео: 704x304, 01:05:00, 25fps, DivX5, 2.6 Mbps

1. -crf 23 -preset medium: фильм сжался полностью за 6 мин 21 сек, размер - 415 МБ, средний битрейт - 777 kbps.
2. -crf 25 -preset slow: время сжатия - 9 мин 31 сек, размер - 313 МБ, средний битрейт - 564 kbps
3. -crf 25 -preset veryfast: время сжатия - 2 мин 11 сек, размер - 279 МБ, средний битрейт - 491 kbps

Здесь ухудшение качества можно разглядеть только в динамичных сценах:

Исходный кадр: http://images.vfl.ru...d6/21000460.bmp
1: http://images.vfl.ru...01/21000461.bmp
2: http://images.vfl.ru...bf/21000462.bmp
3: http://images.vfl.ru...df/21000463.bmp


Как видно из приведенных примеров, при разумных значениях crf и preset различия между исходным и сжатым фильмом можно обнаружить лишь при детальном сравнении. При обычном (и даже поочередном) просмотре фильма эта разница почти незаметна, однако и ее можно нивелировать путем более эффективного сжатия. При этом размер файла и средний битрейт не дают однозначного представления о том, насколько эффективно сжат фильм. Наконец, потери качества при сжатии проявляются вне зависимости от качества оригинала, но сам сжатый фильм смотрится гораздо лучше, если он произведен из четкого исходного материала.

Сообщение отредактировал Al71: 17 Март 2018 - 22:40


#6 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 17 Март 2018 - 22:30

В заключение приведу упрощенный вариант скрипта (для Linux), которым я пользовался и немного статистики.


Скрытый текстavitomkv.sh



Запускается скрипт в терминале (в папке с фильмами) командой
./avitomkv.sh film.avi
где fiml.avi -- имя конвертируемого файла. Чтобы сжать все фильмы в папке:
./avitomkv.sh *.avi
Кроме avi, он может конвертировать также видео других форматов (mpg, flv, wmv, mp4, webm, ts и mkv). Значения crf, preset, tune и прочие опции ffmpeg и кодеков задаются непосредственно в выделенной строке. Местоположение опции в строке имеет значение -- оно определяет, к чему относится опция: непосредственно к ffmpeg, входному файлу, кодеку видео, к кодеку аудио или выходному файлу.


Стоит добавить, что в архиве Arjlover собраны фильмы из разных источников, совершенно разного качества и с разными характеристиками. Сжимались они тоже по-разному: некоторые сильно, некоторые слабее, отдельные вообще увеличивались в размере, хотя и редко. Полный алгоритм действий в этом случае был такой: проверялась степень сжатия и, если размер сжатого файла составлял более 90% от исходного, то оставлялся исходный вариант. Также, сверялись длительности исходного и сжатого файлов, чтобы убедиться, что фильм сконвертировался полностью. В зависимости от результата проверок файлы сортировались по подкаталогам. Кроме того, многие фильмы, представленные в архиве, имеют неправильные пропорции (DAR), и при воспроизведении на некоторых плеерах их приходится устанавливать вручную, иначе картинка будет сильно вытянута или сплющена. Во избежание этого, DAR сравнивался с разрешением видео (как отношение ширины к высоте) и при расхождении более чем 0.1 кодирование производилось с aspect, соответствующим разрешению, что автоматически решало проблему. Еще стоит добавить, что кодер x264, хотя и поддерживает многопоточность, не загружает процессор на все сто процентов. Поэтому в своем полном скрипте я использовал параллельное кодирование двадцати фильмов в однопоточном режиме (опция -threads), применяя taskset для привязки по ядрам. Это позволило полностью загрузить процессор и сократить среднее время кодирования одного фильма более чем в два раза.

И наконец, немного статистики. Всего в архиве Arjlover представлено 11363 фильмов и мультфильмов общим размером 8344 ГБ и общей продолжительностью 1 год 1 месяц 9 дней 18 часов 20 минут 24 секунды. После сжатия общий объем занимаемого дискового пространства составил 3813 ГБ. Основная часть архива кодировалась с -crf 24 (что в среднем давало примерно уполовинивание размера), часть с -crf 25 и совсем небольшая часть с -crf 23. Для более эффективного кодирования везде использовался -preset slow. Чтобы перекодировать весь архив целиком потребовалось ~37 дней почти непрерывной работы скриптов. Файлов, которые остались без изменения по причине плохого сжатия, -- 472. Файлов с искаженными пропорциями -- 124. Файлов без аудиодорожки -- 16. Фильмов с русскими субтитрами -- 114. Фильмов с английскими субтитрами -- 29.
Из всего многотысячного объема перекодироваться автоматически отказались только два фильма (у них было нечетное число строк по высоте, что не понравилось кодеру). Их я сжал отдельно, использовав фильтр разрешения экрана (-vf scale).

#7 OFFLINE   Damian

 

    Долгожитель

  • Постоянные посетители
  • PipPipPipPipPipPipPipPipPipPip
  • сообщений: 1 473
    Последний визит:
    21 дек 2023 21:37
  • Пол:Мужчина
 

Отправлено 06 Июль 2020 - 08:35

Спасибо почитаю,у меня установлена ffmpeg version 3.4.6-0ubuntu0.18.04.1, а во что к примеру ты бы кодировал просто для хранения на жёстком диске чтобы места много не занимали файлы.Вот к примеру  
Скрытый текст
во что  лучше сделать чтоб мегабайт 30 занимал ну или побольше,чтобы просто хранить.

#8 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 06 Июль 2020 - 18:19

Видео с камеры я кодирую h264 (h265 сжимает сильнее, но не все устройства могут его воспроизводить). Сжать 1920х1080 в 30 МБ без существенных потерь качества не получится, лучше уменьшить разрешение (фильтр scale) и использовать однопроходный CRF:

ffmpeg -i input.avi -vf scale=1280:720 -c:v h264 -crf 23 -preset medium  -map 0:0 -c:a aac -b:a 128k -map 0:1 output.mkv

Чем выше -crf, тем сильнее сжатие и хуже качество. Увеличение на шесть единиц снижает размер выходного файла примерно вдвое, и наоборот. Для кодирования сразу нескольких файлов можешь воспользоваться скриптом, отредактировав опции в выделенной строке.

#9 OFFLINE   Damian

 

    Долгожитель

  • Постоянные посетители
  • PipPipPipPipPipPipPipPipPipPip
  • сообщений: 1 473
    Последний визит:
    21 дек 2023 21:37
  • Пол:Мужчина
 

Отправлено 07 Июль 2020 - 00:01

Я по честному не очень понял куда в скрипте названия файлов вписывать,у меня вот например есть 2 файла DVO00002.avi и DVO00005.avi   оба в хомяке,как мне скрипт твой отредактировать чтобы c теми параметрами которые ты для одного файла давал перекодировать?

#10 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 07 Июль 2020 - 08:17

Если запустить скрипт с аргументом *.avi, перекодируются все avi файлы в текущем каталоге. Если DVO*.avi -- все avi файлы, начинающиеся с DVO. Названия никуда вписывать не нужно.
А чтобы использовать параметры из поста выше, в выделенную строку надо добавить фильтр scale с разрешением и аудиокодек вместо copy. В итоге получается так:
ffmpeg -i "$fn" -vf scale=1280:720 -c:v h264 -crf 23 -preset medium -map 0:0 -c:a aac -b:a 128k -map 0:1 "$newfn"


#11 OFFLINE   UrryMan

 

    душевный парень

  • Модераторы
  • сообщений: 2 213
    Последний визит:
    Вчера, 18:08
  • Пол:Мужчина
  • Откуда:С-Пб
 

Отправлено 07 Июль 2020 - 12:30

Просмотр сообщенияAl71 сказал:

Видео с камеры я кодирую h264 (h265 ...
265 дольше кодирует и по качеству считается хуже


Просмотр сообщенияAl71 сказал:

ffmpeg -i "$fn" -vf scale=1280:720 -c:v h264 -crf 23
Я предпочитаю 19 (21 максимум)

#12 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 07 Июль 2020 - 16:06

Просмотр сообщенияUrryMan сказал:

Я предпочитаю 19 (21 максимум)

Я указал 23 как значение по умолчанию, в любом случае всегда приходится искать компромисс между качеством и размером. Чтобы уложиться в 30МБ, наверно, и 23 будет мало.

#13 OFFLINE   UrryMan

 

    душевный парень

  • Модераторы
  • сообщений: 2 213
    Последний визит:
    Вчера, 18:08
  • Пол:Мужчина
  • Откуда:С-Пб
 

Отправлено 07 Июль 2020 - 22:47

Просмотр сообщенияAl71 сказал:

Чтобы уложиться в 30МБ
Ну если взять аудио+видео=4000kbps , это примерно 60 секунд записи.

#14 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 08 Июль 2020 - 08:47

Исходное видео длится 2 мин 37 сек, как видно под спойлером, то есть в два с половиной раза больше. Обычно проще подобрать crf методом тыка, но ради интереса можно рассчитать точный битрейт и использовать двухпроходное кодирование ABR по вышеописанной методике, чтобы подстроиться под определенный размер:

(30 MiB * 8192 [преобразуем MiB в kBit]) / 157 секунд = ~1565 kBit/s (суммарный битрейт)
1565 - 128 kBit/s (заданный аудио битрейт) = 1437 kBit/s (видео битрейт)  (~1400k)

ffmpeg -y -i "$fn" -c:v libx264 -b:v 1400k -pass 1 -c:a aac -b:a 128k -f mkv /dev/null && \
ffmpeg -i "$fn" -c:v libx264 -b:v 1400k -pass 2 -c:a aac -b:a 128k "$newfn"

При этом время кодирования удвоится по сравнению с однопроходным CRF, что при больших объемах имеет значение.

#15 OFFLINE   Damian

 

    Долгожитель

  • Постоянные посетители
  • PipPipPipPipPipPipPipPipPipPip
  • сообщений: 1 473
    Последний визит:
    21 дек 2023 21:37
  • Пол:Мужчина
 

Отправлено 08 Июль 2020 - 15:39

Al71,запустил скрипт с аргументом DVO*avi, получилось следующее с твоим вариантом строки:
ffmpeg -i "$fn" -vf scale=1280:720 -c:v h264 -crf 23 -preset medium -map 0:0 -c:a aac -b:a 128k -map 0:1 "$newfn"
файл 190Mb вышел размером 53Mb,другой 326 Mb стал 87Mb,качество хуже не стало.Ещё если можно поподробнее что происходит в этих 2-х строках:

Цитата

ffmpeg -y -i "$fn" -c:v libx264 -b:v 1400k -pass 1 -c:a aac -b:a 128k -f mkv /dev/null && \
ffmpeg -i "$fn" -c:v libx264 -b:v 1400k -pass 2 -c:a aac -b:a 128k "$newfn"
это получается вместо одной строки с параметрами в скрипте будет две так?

#16 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 08 Июль 2020 - 17:04

Просмотр сообщенияDamian сказал:

это получается вместо одной строки с параметрами в скрипте будет две так?

Да. При этом все итоговое видео будет у тебя с заданным битрейтом (1400 кбит/с).

#17 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 08 Июль 2020 - 21:00

Просмотр сообщенияDamian сказал:

качество хуже не стало

Если у тебя монитор не рассчитан на FullHD (1920x1080), то ты можешь и не заметить разницы. Сравнение обычно делают покадрово, по мелким деталям.

#18 OFFLINE   Damian

 

    Долгожитель

  • Постоянные посетители
  • PipPipPipPipPipPipPipPipPipPip
  • сообщений: 1 473
    Последний визит:
    21 дек 2023 21:37
  • Пол:Мужчина
 

Отправлено 09 Июль 2020 - 08:27

Да у меня старый монитор,максимальное разрешение 1440 x 900 при том что мне нормально 1024 x 768, может вообще другое разрешение ставить а не 1280 x 720, ты наверное на телевизоре широкоформатном потом смотришь, а у меня вообще нет никакого.

#19 OFFLINE   Al71

 

    Мастер

  • [eMule-Rus]
  • сообщений: 3 275
    Последний визит:
    22 ноя 2022 07:59
  • Пол:Мужчина
  • Откуда:Москва
 

Отправлено 09 Июль 2020 - 08:37

Просмотр сообщенияDamian сказал:

может вообще другое разрешение ставить а не 1280 x 720

Можешь задавать какое тебе нравится, главное, чтобы пропорции сохранялись. Я лишь предложил стандартный вариант.

#20 OFFLINE   Damian

 

    Долгожитель

  • Постоянные посетители
  • PipPipPipPipPipPipPipPipPipPip
  • сообщений: 1 473
    Последний визит:
    21 дек 2023 21:37
  • Пол:Мужчина
 

Отправлено 10 Июль 2020 - 19:12

Просмотр сообщенияAl71 (17 Март 2018 - 22:30) писал:

Кроме avi, он может конвертировать также видео других форматов (mpg, flv, wmv, mp4, webm, ts и mkv).
тогда содержимое скрипта нужно менять? Или достаточно в терминале только файл или файлы нужные указать.





Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных