Перекодирование более 100 файлов из H.264 в H.265

Я нахожусь в процессе перекодирования более 100 MKV с высоким качеством битрейта 720p , содержащих H.264 (x264) , в H.265 (x265 / HEVC) .

Я делаю это с помощью программного обеспечения HandBrake под Linux Debian 9 на Intel Xeon E3-1225 v3 3,2 ГГц 4-ядерный .

Далее следуют различные версии.

Ядро:

4.8.0-1-amd64

Ручной тормоз :

0.10.5 (x86_64)

х265 :

2.1-2
using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

У меня применены эти настройки, согласно mediainfo :

Encoding settings: wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=3 / tu-inter-depth=3 / me=3 / subme=4 / merange=57 / rect / amp / max-merge=4 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=40 / lookahead-slices=0 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=1 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Короче говоря, я применил Constant Quality RF21 и очень медленную настройку .

Все оригиналы имеют фиксированный размер 2 ГиБ. Размеры, которые я кодирую, различаются (вы также можете определить, сколько времени это заняло из списка файлов):

494M Dec  7 07:02 S05E16.mp4
551M Dec  7 00:14 S05E17.mp4
654M Dec  6 16:11 S05E18.mp4
668M Dec  6 08:10 S05E19.mp4

В исходных файлах применяются следующие настройки:

Encoding settings: cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5670 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

Вопрос в том, хорошо ли потрачено время процессора ? Я имею в виду, могу ли я сделать какую-либо очевидную оптимизацию, чтобы ускорить работу, не получив в результате более низкого качества и / или большего размера файлов?

РЕДАКТИРОВАТЬ1 :

Цитата из официального источника :

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

РЕДАКТИРОВАТЬ2 :

Конфигурация оборудования


Тип: Мой выделенный сервер. В настоящее время используется только для перекодирования видео.

Процессор: Intel Xeon E3-1225 v3 3,2 ГГц, 4 ядра

GPU: нет выделенной карты, только встроенная

Оперативная память: 32 ГБ ECC 1600 МГц

Диски:

  1. твердотельный накопитель; используется для системы

  2. HDD в RAID6; используется для записи выходных видео

  3. RAMДиск 20 ГБ; используется для чтения исходных видео

РЕДАКТИРОВАТЬ3 :

Что касается комментария о подкачке памяти, у меня было установлено значение vm.swappiness= 1.

veryslowтребуется гораздо больше времени для незначительного улучшения. Я бы предложил mediumпресет с более низким CRF.
Помните также, что файлы будут иметь одинаковое качество независимо от настройки скорости, использование veryslow просто потратит больше времени на их уменьшение (как сказал Мульвья, незначительно). Таким образом, вы можете расставить приоритеты между любыми двумя параметрами: скоростью, качеством или размером файла.
Вы пробовали запускать более одного кодирования параллельно? На многопроцессорных машинах это иногда может привести к значительному сокращению общего времени. Не уверен, что вы можете запустить более одного экземпляра Handbrake, но вы определенно можете с ffmpeg. Два или более параллельных кодирования означают, что пока одно из них не использует ЦП, например, во время дискового ввода-вывода, другое поглощает запасные циклы. Пока вы не используете всю память в своей системе, потому что тогда она начнет подкачиваться на диск, и все пойдет медленнее. Я бы посоветовал следить за процессором, дисковым вводом-выводом и использованием памяти во время кодирования, чтобы увидеть.
нет, см. последнее предложение: (или, в случае –crf, самый низкий битрейт при выбранном качестве). IOW, если вы используете crf, качество остается постоянным, меняется только размер или скорость кодирования.
Что ж, тогда вам нужно расставить приоритеты по размеру с течением времени, учитывая, что качество постоянно. Кстати, о каком сроке вы говорите?
@stib ~ 10 лет
Тогда вы должны быть правы с h.265. Если бы вы говорили о 100+ годах, я бы предложил кодек/контейнер с открытым исходным кодом.
Вы можете проверить software.intel.com/en-us/intel-media-server-studio/try-buy , если вам нужен более быстрый кодировщик. Он не предназначен для конечного пользователя, как ручной тормоз, но поставляется с примером кода.
Что касается ОП, вы вырезаете соответствующий пункт предложения, которое вы выделили жирным шрифтом, « для достижения наилучшего качества при выбранной вами скорости передачи данных ». Но поскольку вы используете режим CRF, следующая часть является действительно важной частью: « или, в случае управления скоростью –crf, самая низкая скорость передачи данных при выбранном качестве ». А с медленными пресетами разница в битрейте небольшая но потраченное время гораздо больше.

Ответы (2)

Целый день я посвятил тестированию различных сценариев. Следующее относится к этой конкретной серии в этом конкретном качестве, поэтому я не говорю, что это применимо в целом . Таким образом, в этом случае применяется следующее:

  • размеры файлов при одних и тех же настройках с изменением только mediumи veryslowпресета различаются незначительно: ~ -10 МБ в среднем в пользу veryslowпресета

  • визуальное качествоmedium при очень близком рассмотрении довольно одинаковое в любом из veryslowпресетов

Одна вещь решена. Я изменил предустановку на medium.


  • при очень близком рассмотрении исходные видео не в таком высоком качестве, как я думал , это объясняет, почему x265 сжимает почти до 1/4 исходного размера

Разгадана еще одна загадка.

При условии, что я сейчас транскодирую со скоростью 25 кадров в секунду, я поднял RF до 20.


  • RAMDisk в данном случае не дает пользы, как для пресета , так mediumи для него; veryslowВ итоге я выбрал RAID6 в качестве источника и SSD в качестве выходного диска.

Решено неудобство перемещения файлов на RAMDisk.


Чтобы ответить на вопрос, время ЦП было потрачено совсем не лучшим образом .

По моему опыту, slowпресеты -er имеют значение, когда на сцене есть движущиеся объекты. Насколько я знаю, одной из основных областей улучшений в x265 является «предсказание» и повторное использование информации об объектах, движущихся в сцене.

Чем больше вычислительной мощности энкодер тратит на поиск этих движущихся объектов и способ их кодирования, тем лучшее качество (или меньший битрейт) вы получаете.

Итак, ответ таков: это зависит от содержания ваших клипов и от того, что вы хотите сделать с результатом. Вам нужно хорошее качество каждого отдельного кадра? (Камера видеонаблюдения) Тогда стоит кодировать с slowи -qb. Это просто информационная запись? Затем используйте mediumи crf 28и -tune film.