Opción de conteo de hilo en FFmpeg para la conversión MÁS RÁPIDA a h264?

Question

necesito velocidad de maximizar, mientras que la conversión de videos usando FFmpeg H264

• Cualquier formato de entrada de vídeos de origen
máquina
• de usuario puede tener cualquier número de núcleos
• de energía y la memoria de consumo son no problemas

Por supuesto, hay un montón de opciones s que se pueden ajustar pero esta pregunta es particularmente sobre elegir la mejor opción -thread <count>. Estoy tratando de encontrar un recuento ideal de hilos en función de

• no. de núcleos
• formato de video de entrada
• h264-friendly values ​​maybe?
• ¿Algo más se perdió arriba?

Soy consciente de que el predeterminado -thread 0 sigue un enfoque de un hilo por núcleo que se supone que es óptimo. Pero no estoy seguro de si esto es tiempo o espacio optimizado. Además, en ciertos casos de prueba, he visto más subprocesos (digamos 4 subprocesos en mi máquina de prueba de doble núcleo) que finalizan más rápido que el predeterminado.

En cualquier otro sentido, digamos configure options w.r.t. hilos, vale la pena perseguir?

Answer 1

Si su 'doble núcleo' tiene hyperthreading, entonces 2x núcleos probablemente serían correctos. Es poco probable que la ganancia vaya más allá de la cantidad de núcleos virtuales (por ejemplo, hyperthreading), pero tal vez debido a problemas internos en FFmpeg podría ser cierto.

Answer 2

He encontrado que threads no hago un buen trabajo al utilizar todos los núcleos, los hiper-hilos no se usan en absoluto. Una solución que podría surgir es ejecutar un proceso de 3 a 4 ffmpeg en paralelo, Ver: https://superuser.com/questions/538164/how-many-instances-of-ffmpeg-commands-can-i-run-in-parallel/547340#547340. Este enfoque termina usando todos los núcleos por completo y es más rápido que la entrada única, múltiples salidas en una sola opción de comando.

Answer 3

Experimenté a fondo con los hilos 0, 6, 12, 24 y no hace una diferencia en la velocidad de cuadros, el tiempo total de procesamiento o la utilización de la CPU. Tenga en cuenta que mi sistema tiene 12 núcleos físicos también. Por lo general, parece que hace un buen trabajo al utilizar su potencia de procesamiento sin especificar subprocesos en los que mis 12 núcleos están básicamente 98-99% utilizados mientras lo observo/monitor del sistema.

Ojalá hubiera una bala mágica, pero por ahora no hay otra manera de acelerar las cosas ya que ffmpeg actualmente está optimizado muy bien en mi opinión. La única alternativa es simplemente obtener más potencia informática o hacer un procesamiento distribuido.

* Tenga en cuenta todas mis pruebas estaban utilizando ffmpeg versión 3.3.1