¿Por qué el procesador es “ mejor ” para la codificación que la GPU?

El artículo que vinculó no es muy bueno.

Normalmente, las codificaciones de tasa de bits de un solo paso convierten su tasa de bits en un valor de RF con un límite máximo de velocidad de bits y lo toma desde allí.

El control de velocidad ABR de una pasada de x264 no está implementado como límite de CRF +. Tiene razón en que 2pass es, con mucho, la mejor manera de alcanzar una tasa de bits objetivo.

Y aparentemente no se da cuenta de que podría comenzar x264 con hilos = 3 o algo así, para deje algo de tiempo de CPU libre para otras tareas. O establezca la prioridad de x264 en muy baja, para que solo obtenga el tiempo de CPU que ninguna otra tarea desea.

También mezcla subprocesos = 1 con el uso de CUDA, o algo así. No es de extrañar que tenga preguntas, porque eso El artículo tiene una explicación TERRIBLE. El artículo completo básicamente se reduce a: use x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, o tal vez use un filtrado ligero con un script AviSynth de entrada. De hecho, recomienda » placebo «. Eso es muy gracioso. «Nunca he visto un archivo pirateado codificado con placebo. (Puedes saberlo por me=esa o me=tesa, en lugar de me=umh para todos los ajustes preestablecidos de buena calidad, hasta veryslow.

Tampoco menciona el uso de una profundidad de color de 10 bits. Más lento para codificar y decodificar, pero incluso después de convertir de nuevo a 8 bits, obtiene un mejor SSIM de 8 bits. Tener más precisión para los vectores de movimiento aparentemente ayuda. Además, no tener que redondear exactamente a un valor total de 8 bits ayuda. Puede pensar en 8 -bit por componente como un truco de velocidad; cuantificar en el dominio de frecuencia y luego comprimirlo con CABAC significa que los coeficientes de profundidad de bits más altos no tienen que ocupar más espacio.

(BTW, h. 265 obtiene menos beneficios de la codificación de 10 bits para video de 8 bits porque ya tiene más precisión para vectores de movimiento. Si hay un beneficio de usar x265 de 10 bits para entradas de video de 8 bits, es más pequeño que con x264. Por tanto, es menos probable que la penalización de velocidad Valgo la pena.)

Para responder a tu pregunta real:

edit: doom9 está activo de nuevo ahora, así que arreglaré el enlace. Vaya a él para citar correctamente quién dijo qué.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google solo almacena en caché la estúpida versión impresa que no muestra correctamente las citas. No estoy muy seguro de qué partes de estos mensajes son citas y cuáles se atribuyen a la persona misma.

Los patrones de ramificación muy irregulares (modos de salto) y la manipulación de bits (codificación de cuantización / entropía) no se adaptan a las GPU actuales. En mi opinión, el único La aplicación realmente buena en este momento son los algoritmos ME de búsqueda completa, al final, aunque la búsqueda completa acelerada sigue siendo lenta incluso si es más rápida que en la CPU.
– MfA

En realidad, básicamente todo se puede hacer razonablemente en la GPU, excepto CABAC (que se podría hacer, simplemente no se podría paralelizar).

x264 CUDA implementará un fullpel y subpel ME algoritmo inicialmente; más tarde podríamos hacer algo como RDO con una aprobación de costo de bits ximation en lugar de CABAC.

Porque tiene que hacer todo en un punto flotante de precisión simple
– MfA

Incorrecto, CUDA admite matemáticas enteras.

– Dark Shikari

Dark Shikari es el mantenedor de x264 y desarrollador de la mayoría de las características desde 2007 más o menos.

AFAIK, este proyecto CUDA no funcionó. Hay soporte para usar OpenCL para descargar algo de trabajo del hilo de búsqueda anticipada (decisión rápida de I / P / B, no una codificación final de alta calidad del marco).

Tengo entendido que el espacio de búsqueda para la codificación de video es TAN grande que la heurística inteligente para la terminación anticipada de las rutas de búsqueda en las CPU vence a las GPU de fuerza bruta traer a la mesa, al menos para una codificación de alta calidad. Es solo comparado con -preset ultrafast donde razonablemente podría elegir la codificación HW en lugar de x264, especialmente si tiene una CPU lenta (como una computadora portátil con doble núcleo y sin hiperproceso). En un CPU (i7 de cuatro núcleos con hyperthreading), x264 superfast probablemente será igual de rápido y se verá mejor (con la misma tasa de bits).

Si está creando una codificación en la que la distorsión de la velocidad (calidad por tamaño de archivo) es importante, debe usar x264 -preset medium o más lento. Si » Si estás archivando algo, gastar un poco más de tiempo de CPU ahora ahorrará bytes mientras «mantengas ese archivo alrededor.

nota al margen, si alguna vez ves mensajes de deadrats en un foro de video,» no va a ser de ayuda. Se ha equivocado en la mayoría de las cosas de las que habla en cada hilo que he visto. Sus publicaciones aparecieron en un par de hilos que busqué en Google sobre la codificación de GPU x264. Aparentemente, no entiende por qué no es fácil, y ha publicado varias veces para decirles a los desarrolladores de x264 por qué son «tontos …

Actualización de 2017:

ffmpeg admite codificación de video acelerada por GPU NVENC h264 y h265 . Puede realizar codificación de 1 paso o 2 pasos con la calidad que elija, ya sea para hevc_nvenc o h264_nvenc, o incluso con una GPU básica, es mucho más rápido que la codificación no acelerada y la codificación acelerada Intel Quick Sync.

Codificación de alta calidad de 2 pasos:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 

Codificación predeterminada de 1 paso:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 

Ayuda y opciones de NVENC ffmpeg:

ffmpeg -h encoder=nvenc 

Úselo, es mucho más rápido que la codificación de CPU.

Si no tiene una GPU, puede usar el códec Intel Quick Sync, h264_qsv, hevc_qsv o mpeg2_qsv, que también son mucho más rápidos que la codificación no acelerada.

Comentarios

• Úselo si valora la velocidad (y el bajo uso de la CPU) por encima de la calidad por. En algunos casos de uso, por ejemplo, transmisión a contracción, que ‘ es lo que desea (especialmente el bajo uso de la CPU). En otros, por ejemplo, codificar una vez para crear un archivo que se transmitirá / verá muchas veces, todavía no está no va a superar a -c:v libx264 -preset slower (que no es tan lento, como casi en tiempo real para 1920x1080p24 en un Skylake i7-6700k).
• El uso de ffmpeg con -vcodec h264_qsv en mi antiguo portátil Intel con Intel HD Grpahics 4000 hizo que el procesamiento fuera mucho más rápido.

Para desarrollar un poco más lo que dice Peter, en general, el uso de múltiples procesadores ayuda en los casos en que tiene varias tareas independientes que todas deben hacerse, pero no tienen dependencias entre sí, o una tarea en la que está realizando las mismas matemáticas en cantidades masivas de datos.

Sin embargo, si necesita la salida del cálculo A como la entrada del cálculo B, y la salida del cálculo B como la entrada del cálculo C, entonces no puede acelerarlo teniendo un trabajo central diferente en cada tarea (A, B o C) porque uno no puede «t comenzar hasta que el otro termine.

Sin embargo, incluso en el caso anterior, es posible que pueda o paralelizarlo de otra manera. Si puede dividir sus datos de entrada en fragmentos, es posible que un núcleo trabaje en hacer A, luego B, luego C con un fragmento de datos, mientras que otro núcleo trabaja en hacer A, luego B, luego C en un fragmento diferente de datos .

También hay otras consideraciones. Tal vez pueda encontrar una manera de paralelizar los cálculos, pero simplemente leer los datos del disco, o a través de la red, o enviarlos a la GPU, llevará más tiempo que hacer los cálculos. En ese caso, no tiene sentido paralelizarlo porque solo obtener los datos en la memoria lleva más tiempo que la cantidad de tiempo que ahorra al hacer el cálculo en paralelo.

En otras palabras, es tanto un arte como una ciencia.

Comentarios

• Oh, sí, x264 se paraleliza bastante bien en CPUs multinúcleo. Escalo casi linealmente hasta al menos 8 núcleos, y decentemente incluso más allá de 32. La estimación de movimiento se puede hacer en paralelo, dejando solo el trabajo necesariamente en serie para otro hilo y trucos similares.
• La pregunta no es ‘ t paralelismo en general, es ‘ s GPU en particular. Son ‘ mucho más restrictivos en el código que puede hacer que se ejecuten que las CPU. Creo que es ‘ s porque no puedes ‘ t tener código con ramas que van de diferentes maneras en diferentes bloques de la imagen. No ‘ no entiendo exactamente por qué, pero creo que ‘ es algo así. Cada procesador de flujo es tan simple, y con medios tan limitados para que se ejecute independientemente de los demás, que siempre tienes que esperar a que termine el más lento, o estás limitado en la ramificación, o ambos.
• Si tuvieras un grupo de computadoras (CPU con RAM independiente que no ‘ no competían entre sí por el ancho de banda de la memoria y la memoria caché de la CPU), ‘ d dividir el video de entrada en GOP y enviar secciones del video de entrada aún comprimido para decodificar y comprimir en otras máquinas del clúster.Por lo tanto, solo se tendría que transferir video de entrada o salida comprimido. En un sistema de memoria RAM / caché compartido multinúcleo como incluso una estación de trabajo x86 multisocket, tiene varios subprocesos que operan en los mismos marcos a la vez. (también significa que no ‘ no necesita un nuevo código para realizar un control de velocidad global para segmentar las codificaciones).