Cómo cambiar la configuración de ffmpeg -threads

Trabajando en un sitio de tubo . Estoy ejecutando videos a través de ffmpeg en un servidor dedicado de Linux para convertir a mp4 .

Las especificaciones del servidor:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Stepping:              3
CPU MHz:               3491.749
BogoMIPS:              6983.49
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

El problema durante las pruebas es que incluso haciendo solo 4-5 a la vez, el servidor se dispara a un promedio de alrededor de 36. Esta es solo una persona. Me imagino que cuando se abra, muchas personas subirán a la vez.

Parece que ffmpeg intenta usar todos los recursos disponibles por conversión.

He oído que hay una configuración de hilos que puede cambiar, pero no puedo encontrarla. Tengo un servidor de 8 cpu. Solo se usa para conversiones, por lo que he oído que la mejor configuración sería entre 2 y 4. Puedo probarlo.

Pero, ¿cómo cambio esta configuración? Todo lo que veo en línea discute esta configuración, pero no los pasos para cambiarla.

El indicador de opción que desea es realmente justo -threadsy lo usaría así (solo para un hilo):

ffmpeg -i somefile.wmv -c:a libfdk_aac -c:v libx264  -threads 1 transcoded.mp4

Sin embargo, hay bastantes sutilezas que aumentarán la carga del servidor y el tiempo de operación, como el cambio de escala, la aplicación de filtros y la calidad de cuadro final / velocidad de cuadro, sin mencionar el hecho de que algunas arquitecturas VM realmente leen y escriben todo dos veces (una vez de forma nativa) y una vez virtualmente !!!)

Aquí hay algunos consejos para acelerar su velocidad:

1. use una cola, de modo que solo se transcodifique un elemento a la vez
2. solicita archivos más pequeños a tus usuarios
3. use toda la potencia de su máquina de la siguiente manera:
   • leer y escribir desde un disco RAM
   • cambio a metal desnudo para tareas de transcodificación
   • utilizar -threads 0

Hagas lo que hagas, mantén a tus usuarios informados sobre el proceso de transcodificación, porque solo lleva tiempo. (IJTT)

[comando editado para reflejar el comentario de LordNeckbeard]

Esto puede ser un poco viejo, pero esto suena como una tarea perfecta para un contenedor como docker.

• Deje que ffmpeg se ejecute con full horsepower(como lo llamó denjello)
• pero déjalo correr dentro de la ventana acoplable

Ahora puede limitar la cantidad de recursos que puede consumir una sola instancia de ffmpeg sin siquiera usar las opciones de línea de comandos de ffmpeg. Y no solo CPU sino también memoria e IO.

Aún más: tal vez tengas diferentes tareas que pueden ejecutarse en segundo plano y no te importa cuánto tiempo tarden y tienes tareas que deberían ejecutarse rápidamente, por lo que puedes poner un peso en diferentes tareas.

Ver https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources

Ya hay una imagen predefinida de ffmpeg en github: https://github.com/jrottenberg/ffmpeg

docker run jrottenberg/ffmpeg \
        -i http://url/to/media.mp4 \
        -stats \
        $ffmpeg_options  - > out.mp4

Es probable que una sola conversión se ejecute más lentamente debido a la sobrecarga, pero si ejecuta varias instancias simultáneamente, esto podría ser un gran beneficio. Todo esto se escalará muy bien, sin mencionar la seguridad mejorada porque cada tarea está aislada del sistema operativo subyacente.