Estoy en un proceso de transcodificación de más de 100 MKV de 720p con tasa de bits de alta calidad que contienen H.264 (x264) a H.265 (x265 / HEVC) .
Hago esto con el software HandBrake bajo Linux Debian 9 en Intel Xeon E3-1225 v3 3.2GHz 4-core .
Siguen varias versiones.
Núcleo:
4.8.0-1-amd64
0.10.5 (x86_64)
x265 :
2.1-2
using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
Tengo estos ajustes aplicados, según 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
En resumen, he aplicado Calidad Constante RF21 y un preajuste muy lento .
Los originales tienen un tamaño fijo de 2 GiB. Los tamaños de mis codificaciones difieren (puede deducir cuánto tiempo tomó también de la lista de archivos):
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
Los archivos originales tienen estos ajustes aplicados:
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
La pregunta es, ¿está bien invertido el tiempo de la CPU ? Quiero decir, ¿puedo hacer optimizaciones obvias para acelerar las cosas sin tener como resultado archivos de menor calidad o más grandes?
EDITAR1 :
Cita de la fuente oficial :
x265 tiene diez opciones predefinidas que optimizan el equilibrio entre la velocidad de codificación (fotogramas codificados por segundo) y la eficiencia de compresión (calidad por bit en el flujo de bits). El preajuste predeterminado es medio. Hace un trabajo razonablemente bueno al encontrar la mejor calidad posible sin gastar ciclos de CPU excesivos buscando la forma más eficiente de lograr esa calidad. Cuando usa ajustes preestablecidos más rápidos, el codificador toma atajos para mejorar el rendimiento a expensas de la calidad y la eficiencia de la compresión. Cuando usa ajustes preestablecidos más lentos, x265 prueba más opciones de codificación, usando más cálculos para lograr la mejor calidad a la velocidad de bits seleccionada (o en el caso del control de velocidad –crf, la velocidad de bits más baja a la calidad seleccionada).
EDIT2 :
Configuración de hardware
Tipo: servidor dedicado mío. Actualmente se usa solo para transcodificar videos.
Procesador : Intel Xeon E3-1225 v3 3,2 GHz de 4 núcleos
GPU: Sin tarjeta dedicada, solo integrada
RAM: 32GB ECC 1600MHz
Discos:
SSD; utilizado para el sistema
HDD en RAID6; utilizado para escribir los videos de salida
Disco RAM de 20 GB; utilizado para leer los videos fuente
EDITAR3 :
Con respecto al comentario sobre el intercambio de memoria, he establecido vm.swappiness= 1.
Todo el día lo dediqué a probar varios escenarios. Lo siguiente se aplica a esta serie en particular en esta calidad en particular, por lo que no digo que se aplique en general . Así que en este caso se aplica lo siguiente:
los tamaños de los archivos con la misma configuración con solo mediumy veryslowpreestablecido cambiado varían insignificantemente: ~ -10 MiB en promedio a favor del veryslowpreestablecido
la calidad visual en una mirada muy cercana es más bien la misma en cualquiera de los dos mediumo veryslowpreestablecidos
Una cosa solucionada. He cambiado el preajuste a medium.
Otro misterio resuelto.
Siempre que ahora transcodifique a 25 fps, he elevado el RF a 20.
mediumcomo para veryslowpreestablecidos; Terminé con RAID6 como fuente y SSD como unidad de salidaSe resolvió el inconveniente de mover archivos a RAMDisk.
Para responder a la pregunta, el tiempo de CPU no se gastó nada bien .
En mi experiencia, los slowajustes preestablecidos -er marcan la diferencia cuando tienes objetos en movimiento en la escena. AFAIK, una de las principales áreas de mejoras en x265 es la "predicción" y la reutilización de información sobre objetos que se mueven en la escena.
Cuanto más poder de cómputo gaste el codificador en encontrar estos objetos en movimiento y la forma de codificarlos, mejor calidad (o menor tasa de bits) obtendrá.
Entonces, la respuesta es: depende del contenido de tus clips y de lo que quieras hacer con el resultado. ¿Necesita una buena calidad de cada fotograma? (Cámara de seguridad) Entonces vale la pena codificar con slowy -qb. ¿Es solo una grabación informativa? Luego ve con mediumy crf 28y -tune film.
gian
veryslowtoma mucho más tiempo para una mejora marginal. Sugeriríamediumpreestablecer con un CRF más bajo.puntapié
puntapié
puntapié
puntapié
LinuxSecurityFreak
puntapié
dnigmig
gian