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

Estaba leyendo este artículo y vi que una CPU es mejor para la compresión de video que una GPU.

El artículo solo dice que sucede porque el procesador puede manejar algoritmos más complejos que la GPU, pero quiero una explicación más técnica, hice algunas búsquedas en Internet pero no encontré nada.

Entonces, ¿alguien sabe cómo explicar o vincular un sitio?

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

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

El control de frecuencia ABR de una pasada de x264 no se implementa como límite CRF +. Sin embargo, 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 dejar algo de tiempo de CPU libre para otras tareas. O establezca la prioridad de x264 en verylow, para que solo obtenga el tiempo de CPU que ninguna otra tarea desea.

También mezcla hilos = 1 con el uso de CUDA, o algo así. No es de extrañar que tenga preguntas, porque ese artículo tiene una explicación TERRIBLE. Básicamente, todo el artículo se reduce a: usar x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, o tal vez usar algo de filtrado de luz con un script de entrada AviSynth. En realidad recomienda "placebo". Eso es hilarante. Nunca he visto un archivo pirateado codificado con placebo. (puede distinguir me=esao me=tesa, en lugar de me=umhtodos 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 volver a convertir a 8 bits, obtienes un mejor SSIM de 8 bits. Tener más precisión para los vectores de movimiento aparentemente ayuda. Además, no es necesario redondear exactamente a un valor completo de 8 bits. Puede pensar en 8 bits por componente como un hack de velocidad; cuantificar en el dominio de la frecuencia y luego comprimir eso con CABAC significa que los coeficientes de profundidad de bits más altos no tienen que ocupar más espacio.

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

Para responder a su pregunta real:

edit: doom9 está de nuevo ahora, así que ordenaré el enlace. Vaya a él para citar adecuadamente 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 la cita. 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 altamente irregulares (modos de omisión) y la manipulación de bits (codificación de cuantificación / entropía) no se adaptan a las GPU actuales. En mi opinión, la única aplicación realmente buena en este momento son los algoritmos de búsqueda completa ME, 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 puede hacer, simplemente no se puede paralelizar).

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

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

Incorrecto, CUDA admite matemática entera.

- Shikari oscuro

Dark Shikari es el responsable de mantenimiento x264 y desarrollador de la mayoría de las funciones desde 2007 más o menos.

AFAIK, este proyecto CUDA no funcionó. Hay soporte para usar OpenCL para descargar parte del trabajo del subproceso anticipado (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 temprana de las rutas de búsqueda en las CPU supera la fuerza bruta que las GPU traen a la mesa, al menos para la codificación de alta calidad. Solo se compara con el lugar -preset ultrafastdonde podría elegir razonablemente 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 hyperthreading). En una CPU rápida (i7 quad core con hyperthreading), x264 superfastprobablemente será tan rápido y se verá mejor (a la misma tasa de bits).

Si está haciendo una codificación donde la distorsión de velocidad (calidad por tamaño de archivo) es importante, debe usar x264 -preset mediumo más lento. Si está archivando algo, pasar un poco más de tiempo de CPU ahorrará bytes mientras mantenga ese archivo.

nota al margen, si alguna vez ve mensajes de deadrats en un video foro, no será útil. Se ha equivocado sobre 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 x264 GPU. 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 2017:

ffmpeg admite la codificación de video acelerada por GPU h264 y h265 NVENC . Puede realizar codificaciones de 1 o 2 pasadas con la calidad que elija, ya sea para hevc_nvenc o h264_nvenc, o incluso con una GPU de nivel de entrada 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 pasadas:

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

Codificación predeterminada de 1 pasada:

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 la 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.

Para profundizar un poco más sobre 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 realizarse pero no tienen dependencias entre sí, o una tarea en la que está realizando lo mismo Matemáticas en grandes cantidades 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 al cálculo C, entonces no puede acelerarlo teniendo un trabajo central diferente en cada tarea ( A, B o C) porque uno no puede comenzar hasta que el otro termine.

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

También hay otras consideraciones. Tal vez podría encontrar una manera de paralelizar los cálculos, pero solo 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 llevar los datos a 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.