¿Puede H264 lograr la "equivalencia" con ProRes 422?

Bueno, siguiendo los números, h264 tiene una menor profundidad de bits y precisión de color que ProRes 422. PR422 tiene submuestreo de croma de 10 bits y 4: 2: 2, h264 tiene 8 bits y 4: 2: 0 a menos que codifique en el perfil Hi422P Intra que no es muy compatible en la naturaleza, pero ofrece 10 bits y 4:2:2. Entonces, en ese caso, no creo que haya ninguna diferencia entre los dos formatos, pero sí una mejor relación de compresión que con ProRes.

E: Si quieres convertirte en una auténtica mierda, también puedes codificar en el Intra Profile 4:4:4, que admite hasta 14 bits de profundidad de color. Tan técnicamente superior a ProRes4444. Aunque probablemente no encuentre ninguna aplicación comercial que lo admita.

En otra nota, no creo que la entrega de contenido para cine deba realizarse en h264 ni en ProRes 422, especialmente cuando planea codificar a un códec sin pérdidas (JPEG2000/DCP) después. Simplemente no tiene mucho sentido hacerlo, todo lo que pierde es calidad aunque no hay necesidad de hacerlo, solo ahorra espacio hasta que codifica su DCP. Hay otros buenos códecs sin pérdida, que ofrecen muy buena compresión, para usar antes de codificar el DCP.

Por ejemplo, podría ir directamente a DCP, Adobe Media Encoder ofrece exportar a 2k DCP desde CC 2014, puede omitir un paso de codificación y tener un códec sin pérdidas con muy buena relación de compresión.

Otro gran códec intermedio es UtVideo , así como Schrödinger (una implementación del códec Dirac de la BBC, disponible a través de FFmpeg ).

Al final, aunque la teoría siempre difiere de la práctica y si no realiza entregas para cines de todo el país con excelentes proyectores y demás, la diferencia de calidad en su cadena de entrega será insignificante. Lo único que podría ser un escollo es que h264 es muy complejo y por eso siempre propenso a algunos defectos visuales extraños, por lo que la inspección final siempre es una necesidad con h264.

¿Alguien ha realizado o visto alguna prueba que compare Apple ProRes 422 con H.264 de alta tasa de bits?

No, pero puedo decirte que x264 puede estar tan cerca de la pérdida como quieras (o incluso matemáticamente sin pérdida, con -qp 0). x264 puede producir flujos h.264 en espacios de color YUV 4:2:0, 4:2:2 o 4:4:4, a 8 o 10 bits por componente. (También puede hacer RGB, pero a menos que esté haciendo sin pérdidas, probablemente obtendrá una mejor calidad por tasa de bits de YUV).

La compatibilidad con el decodificador para cualquier cosa que no sea 4:2:0 de 8 bits no está tan extendida. (por ejemplo, las tarjetas de video tienen decodificadores de hardware que solo pueden acelerar 4:2:0 8 bits).

Tenga en cuenta que x264 debe compilarse para una salida de 8 o 10 bits. Necesita una compilación separada de libx264 (o una compilación estática completamente separada de ffmpeg) para 8 bits y 10 bits. Cualquiera de los dos puede manejar cualquier profundidad de bits de entrada que desee arrojar, pero siempre generará la profundidad de bits para la que se compiló.

El perfil Hi444PP h.264 admite una profundidad de hasta 14 bits para un funcionamiento con o sin pérdidas, pero x264 solo admite 8 o 10 bits. (También 9 bits, si lo compila con profundidad de bits = 9, pero realmente no tiene sentido hacerlo. El golpe de velocidad llega tan pronto como va más allá de 8)

Por cierto, incluso si su entrada es de 8 bits y su pantalla final es de 8 bits RGB, 10 bits h.264 se ve mejor para la misma tasa de bits. 8bit h.264 es una compensación entre velocidad y calidad. (y obviamente compatibilidad con el decodificador). Google debería encontrar algunos hilos en doom9, y un PDF de ateme, para respaldar esta afirmación.

Para entenderlo, recuerde que los códecs con pérdida no intentan reproducir todos los bits de entrada, solo algo que se parece. 10 bits permite una mayor precisión interna para la predicción de movimiento y permite que el codificador modifique los bits menos significativos para una mejor eficiencia de CABAC (trellis) sin producir una diferencia visible. Entonces obtienes menos bandas de gradientes.

Nos preguntamos si es posible alcanzar una calidad adecuada con H.264. Digamos, con tasas de bits de 50-100 Mbps, y ajustando el tamaño/estructura del GOP. (Por ejemplo, solo usando marcos "I").

Forzar más fotogramas I, o solo fotogramas I, NO aumenta la calidad. Los codificadores h.264 "saben" cómo su salida difiere de su entrada, y usarán macrobloques I donde son una mejor opción.

Los GOP cortos son útiles para buscar o recuperar errores en casos de uso de transmisión en tiempo real. Para la producción de video, un GOP corto le permite retroceder un cuadro sin tener que decodificar muchos cuadros del cuadro clave anterior. Para que puedas fregar con más precisión.

Si la búsqueda no es una preocupación en absoluto, podría establecer keyint=1000, y luego x264 podría usar un GOP casi tan largo como quisiera. (La detección de cortes de escena está activada en todos los ajustes preestablecidos excepto ultrarrápidos, por lo que x264 usará un IDR (fotograma clave) cada vez que un corte de escena hace que un encuadre I sea una buena idea de todos modos).

Actualización 2: Hice algunas pruebas más... con Adobe Media Encoder, usando MPEG2 y el perfil "4:2:2", ¡el archivo ProRes pasó de 1920 MB a 290 MB! Y yo diría, subjetivamente, que es 99% tan bueno. Esto es notable. (Con H264 bajé a 500-700 MB)

Si obtuvo resultados tan buenos con MPEG2, debería obtener fácilmente archivos aún más pequeños con un codificador h.264 decente. Su contenido probablemente se comprime bastante bien (grano bajo, algunas áreas con mucha similitud).

Si tiene su entrada en un archivo que ffmpeg puede leer (es decir, casi cualquier formato),

ffmpeg -i in.mp4 -c:a copy -c:v libx264 -preset medium -tune film -crf 10 -movflags +faststart out.mp4

CRF 10 es mucho más que visualmente sin pérdidas. ffmpeg tiene por defecto el mismo espacio de color que la entrada, si el códec de salida lo admite. Si su entrada es 4: 4: 4, pero desea submuestrear su croma, use algo como:

ffmpeg -i in ... -sws-flags lanczos+print_info -pix_fmt yuv422p  out
...
[swscaler @ 0x33be0c0] Lanczos scaler, from rgb24 to yuv422p using MMXEXT

Actualización 1: ¿Cómo se "probaría" técnicamente la diferencia? ¿O medir la información de color?

Medir la profundidad de color de salida? tal vez con mediainfo .

Para comparar la calidad de diferentes codificaciones de la misma fuente, mida el SSIM o PSNR de cada codificación en relación con la fuente. x264 puede medir ambas métricas durante el proceso de codificación. Hay otras herramientas para comparar dos archivos de video ya hechos, para medir esas métricas de calidad, pero no las he usado.

Para ffmpeg, use -ssim 1 -psnr -tune ssim. (No lo use -tune ssimexcepto al evaluar comparativamente esa métrica. De forma predeterminada, habilita las optimizaciones psicovisuales que producen una salida que se ve mejor para los humanos, pero es matemáticamente menos similar de acuerdo con esa métrica).

SSIM y PSNR son lo único que puede usar cuando trabaja con tasas de bits que van mucho más allá de la transparencia visual. Google en estos para obtener más información.

Para probar la ausencia de pérdidas, puede usar el -f framemd5códec de ffmpeg para asegurarse de que el h.264 decodifique los bits de forma idéntica a la entrada. (Vea esta pregunta para ver un ejemplo. Asegúrese de usar el mismo -pix_fmt para todas las pruebas, porque diferentes decodificadores pueden empaquetar los mismos datos de manera diferente).

Oh, solo lee la respuesta del profesor Sparkles. No me di cuenta de que eventualmente estabas generando sin pérdidas. Te estás disparando en el pie si usas algún códec con pérdida en el camino. El códec sin pérdidas tendrá que codificar todos los artefactos invisibles de bloqueo/timbre dejados por los códecs con pérdidas, por lo que normalmente obtendrá archivos más grandes de su códec sin pérdidas si lo alimenta con una entrada que ha pasado por un códec con pérdidas, en lugar de la fuente original.

Entonces, si desea usar h.264, use sin pérdidas. ( ffmpeg -i in -preset ultrafast -qp 0 out). (Los ajustes preestablecidos más lentos brindan solo una pequeña mejora de compresión para lossless. Sin embargo, nunca use ultrarrápido para nada que no sea sin pérdidas).