encoding - vp9 - x265 ffmpeg
¿Por qué el hilo cortado afecta tanto a la codificación en tiempo real usando ffmpeg x264? (1)
Estoy usando ffmpeg libx264 para codificar una pantalla 720p capturada de x11 en tiempo real con un fps de 30. Cuando uso -tune parámetro de latencia cero , el tiempo promedio de codificación por fotograma puede ser tan grande como 12 ms con la línea base del perfil.
Después de estudiar el código fuente de ffmpeg x264, descubrí que el parámetro clave que conduce a un tiempo de codificación tan largo es el de los hilos en rodajas, habilitados por -tune zerolatency. Después de deshabilitar el uso de -x264-params sliced-threads = 0, el tiempo de codificación puede ser tan bajo como 2 ms
Y con los sliced-threads desactivados, el uso de la CPU será del 40%, mientras que solo será del 20% cuando esté habilitado.
¿Alguien puede explicar los detalles sobre este hilo en rodajas? Especialmente en la codificación en tiempo real (supongamos que ningún marco está almacenado en el búfer para codificarse, solo codifica cuando se captura un fotograma).
La documentación muestra que el enrutamiento basado en cuadros tiene un mejor rendimiento que el basado en sectores. También observa que este último no se escala bien debido a las partes del codificador que son en serie.
Speedup vs. hilos de codificación para el perfil muy veryfast (no en tiempo real):
threads speedup psnr
slice frame slice frame
x264 --preset veryfast --tune psnr --crf 30
1: 1.00x 1.00x +0.000 +0.000
2: 1.41x 2.29x -0.005 -0.002
3: 1.70x 3.65x -0.035 +0.000
4: 1.96x 3.97x -0.029 -0.001
5: 2.10x 3.98x -0.047 -0.002
6: 2.29x 3.97x -0.060 +0.001
7: 2.36x 3.98x -0.057 -0.001
8: 2.43x 3.98x -0.067 -0.001
9: 3.96x +0.000
10: 3.99x +0.000
11: 4.00x +0.001
12: 4.00x +0.001
La principal diferencia parece ser que el enrutamiento de trama agrega latencia de trama ya que necesita diferentes tramas para trabajar, mientras que en el caso de subprocesamiento basado en trama, todos los subprocesos funcionan en el mismo marco. En la codificación en tiempo real, tendría que esperar a que lleguen más cuadros para llenar la tubería en lugar de fuera de línea.
Enhebrado normal, también conocido como enhebrado basado en marcos, utiliza un sistema inteligente de marcos escalonados para el paralelismo. Pero tiene un costo: como se mencionó anteriormente, cada hilo adicional requiere un marco de latencia más. El subprocesamiento basado en rebanadas no tiene ese problema: cada cuadro se divide en secciones, cada sector se codifica en un núcleo y, a continuación, el resultado se junta para formar el cuadro final. Su eficacia máxima es mucho menor por una variedad de razones, pero permite al menos cierto paralelismo sin un aumento en la latencia.
De: Diario de un desarrollador x264
Subprocesamiento Sliceless: ejemplo con 2 hilos. Comience el cuadro de codificación # 0. Cuando esté medio hecho, comience a codificar el cuadro n. ° 1. El hilo # 1 ahora solo tiene acceso a la mitad superior de su marco de referencia, ya que el resto todavía no se ha codificado. Por lo tanto, debe restringir el rango de búsqueda de movimiento. Pero eso probablemente sea correcto (a menos que use muchos hilos en un marco pequeño), ya que es bastante raro tener vectores de movimiento vertical tan largos. Después de un momento, ambos subprocesos han codificado una fila de macrobloques, por lo que el subproceso n. ° 1 puede usar el rango de movimiento = +/- 1/2 de alto de cuadro. Más tarde, el hilo # 0 termina el cuadro # 0 y pasa al cuadro # 2. El subproceso n. ° 0 ahora tiene restricciones de movimiento, y el subproceso n. ° 1 no está restringido.
De: http://web.archive.org/web/20150307123140/http://akuvian.org/src/x264/sliceless_threads.txt
Por lo tanto, tiene sentido habilitar sliced-threads con -tune zereolatency ya que necesita enviar un marco tan pronto como sea posible en lugar de codificarlo de manera eficiente (rendimiento y calidad).
Usar demasiados hilos, por el contrario, puede afectar el rendimiento ya que la sobrecarga para mantenerlos puede exceder las ganancias potenciales.