¿Cómo preservar el color RGB tanto como sea posible al convertir una serie de archivos PNG a un contenedor de video con ffmpeg?

Question

Tengo 950 archivos PNG que están destinados a convertirse en fotogramas individuales en una pista de vídeo de 38 segundos a 25 fotogramas por segundo. Los nombres de los archivos son idénticos excepto el número de secuencia, como es habitual en este tipo de casos.

Quiero producir un contenedor de un formato ampliamente admitido, idealmente WebM si se pueden cumplir todos los criterios, o MPEG-4, por ejemplo, con un códec compatible con los navegadores modernos para la reproducción, a partir de esta serie de imágenes PNG. tener. El problema es que los colores cambian y el color de fondo del vídeo decodificado ya no coincide con el mismo triplete RGB muestreado del color de fondo de las imágenes PNG. Esto da como resultado que el video sobresalga del fondo previsto en mi página HTML donde está incrustado el video.

Probé lo simple:

ffmpeg -f image2 -i image%03d.png output.webm

lo que de hecho me dio una pista de video VP9 de 25 fps empaquetada en un contenedor WebM.

Las imágenes PNG tienen un estilo de animación, con un fondo sólido y formas simples que se animan en primer plano. Parecen ser de colorsin etiquetar(Eso es lo que me dice Adobe Bridge, supongo que esto significa que no hay ningún perfil de color incrustado o una referencia a uno). El problema con mi intento anterior es que, aunque el contenedor se reproduce en Chrome, el color de fondo tomado de la imagen PNG, con triplete RGB #ED4D56, no coincide perceptivamente con el color de fondo que aparece en el video que se está reproduciendo.

¿Es este un efecto secundario inevitable de la conversión de color de RGB a YUV (codificación) a RGB (reproducción)? ¿Hay alguna manera de mitigar esto? No insisto en que los fotogramas de la pista de vídeo se codifiquen usando RGB, supongo que YUV está bien, siempre y cuando un navegador moderno que reproduzca estos fotogramas produzca el mismo triplete RGB (dentro de un margen de error insignificante) al decodificar y mostrar el marco(s).

Mi pregunta es, ¿qué línea de comando ffmpegpuedo intentar mitigar esto? Estoy dispuesto a cambiar el códec de vídeo, el formato de píxeles, habilitar la gestión del color en ffmpeg si existe, etc.

Answer 1

Tuve una tarea muy similar recientemente y diría que todavía no existe una solución perfecta (a octubre de 2018). Este es el efecto secundario de la conversión de color RGB a YUV a RGB de baja precisión. Incluso algunas variantes de códecs "sin pérdidas" (por ejemplo, libvpx-vp9 -lossless) producen colores distorsionados debido al espacio de color YUV.

• Si se aceptan colores no exactos, entonces ellibvpxEl códec puede hacer un buen trabajo:

  ffmpeg -r 25 -i image%03d.png -c:v libvpx -crf 4 -b:v 0 output.webm
  

  Con estos ajustes se produjo una cantidad insignificante de cambio de color o incluso los colores exactos para algunos conjuntos de fotogramas. Los códecs VPx son ampliamente compatibles (todos los principales navegadores excepto IE y Safari) y producen archivos de tamaño razonable.

• Si los colores exactos son estrictamente necesarios, entonces debemos evitar la conversión del espacio de color. La única solución para varios navegadores que se me ocurrió es usaranimado pngimágenes. ffmpegsolo tiene soporte muy básico para apng, por lo que es mejor usar otras herramientas, por ejemplo apngasm:

  apngasm output.png image001.png 1 25
  

  funcionará en todas partes excepto en IE y Edge (allí volverá al primer fotograma estático). Los tamaños de archivos son enormes, pero ese es el precio de la codificación real sin pérdidas.

• Ellibx264rgbTambién se debe mencionar el códec: usarlovoluntad será la forma correcta de codificar los colores RGB precisos cuando/si los navegadores lo admitan.