La mayoría de la gente conoce los conceptos básicos de la teoría del color. Al combinar el brillo de varios colores primarios, puede recrear cualquier color visible para una persona. Mucha gente sabe que los colores individuales son simplemente las longitudes de onda del espectro electromagnético. Pero lo que muchos no se dan cuenta es lo difícil que se vuelve la situación cuando nos esforzamos por registrar y reproducir el color con precisión.
Hay muchos sistemas involucrados en la conversión de un valor triplete RGB en una longitud de onda de luz específica. Esta transformación debe estandarizarse para que todo el software, todos los decodificadores de video, tarjetas de video y monitores (incluso hechos por diferentes fabricantes en diferentes décadas) puedan producir los mismos resultados a partir de los mismos datos de entrada. Para hacer frente a este desafío, se han desarrollado estándares de color. Sin embargo, las pantallas y otras tecnologías han evolucionado con el tiempo. La televisión se volvió digital, comenzó la compresión y abandonamos los CRT en favor de LCD y OLED. El nuevo equipo era capaz de mostrar más colores con mayor brillo, pero las señales que recibía todavía estaban adaptadas a las capacidades de las pantallas más antiguas.
La solución a este problema fue crear un nuevo "espacio de color". Se puede producir nuevo contenido HD en un nuevo espacio de color y las nuevas pantallas HD pueden mostrarlo. Y si el espacio de color antiguo se convierte en uno nuevo antes de mostrarse, el contenido antiguo no perderá compatibilidad.
Esta es una solución que funciona, pero complica el proceso de creación de videos. En cada paso del proceso de captura, grabación, edición, codificación, decodificación, composición y visualización, debe considerar el espacio de color que está utilizando. Y si al menos una etapa del proceso utiliza equipos antiguos, o hay un error de software debido al cual no se tiene en cuenta el espacio de color, el resultado puede ser una imagen incorrecta. El video aún se puede ver, pero los colores pueden parecer demasiado oscuros o pálidos.
Hoy en día, los dos espacios de color más populares son BT.601 (también llamado smpte170m; usaré ambos nombres en este artículo), que se ha convertido en el estándar para contenido SD, y BT.709, que se ha convertido en el estándar para Contenido HD. También está BT.2020, que se está volviendo más popular gracias a su contenido HDR y UHD. Vale la pena señalar que la división HD / SD es un poco defectuosa aquí. No hay limitaciones técnicas, es solo un enfoque tradicional. El contenido HD se puede codificar en BT.601 y el contenido SD en BT.709. Si toma un archivo de video de 1080p y lo reduce a 480p, el espacio de color no cambiará automáticamente. Cambiar el espacio de color es un paso adicional que se realiza como parte del proceso.
¿Qué sucede si un proceso no se ejecuta correctamente? Hagamos un experimento.
El programa ffmpeg es un verdadero milagro de nuestro tiempo. Es una herramienta de video digital muy popular y toda la industria debe mucho a sus desarrolladores. En mi experimento, usaré esta herramienta para crear y modificar archivos de video.
Primero, crearé un archivo de prueba simple usando ffmpeg:
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -color_range pc -y 601.mp4
Una breve explicación de este comando:
ffmpeg
—
-f rawvideo
— ffmpeg, , .
-s 320x240
— . , . .
-pix_fmt yuv420p
— . Yuv420p — . , yuv(0,0,0) . RGB, , .
-t 1
— 1
-i /dev/zero
— . /dev/zero — , mac. , .
-an
— , .
-vcodec libx264
— libx264.
-profile:v baseline
— h.264. h.264, .
-preset:v placebo
— libx264, . , . , .
-color_range pc
— 0 255. 16-235. - , . ,pc
,tv
.
-crf 18
- la opción de factor de tasa constante le dice a libx264 que cree un archivo de video de alta calidad y use tantos bits como sea necesario para garantizar la calidad18
. Cuanto menor sea el número, mayor será la calidad. 18 es de muy alta calidad.
-y
- da permiso a ffmpeg para sobrescribir el archivo si existe.
601.mp4
- el nombre del archivo resultante.
Este comando crea un archivo 601.mp4 de 1 segundo de duración, que se puede abrir y reproducir. Después de ejecutar este comando, podemos verificar que ffmpeg no ha distorsionado los valores de píxeles ejecutando el siguiente comando y examinando la salida:
ffmpeg -i 601.mp4 -f rawvideo - | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000
00000010: 0000 0000 0000 0000 0000 0000 0000 0000
00000020: 0000 0000 0000 0000 0000 0000 0000 0000
00000030: 0000 0000 0000 0000 0000 0000 0000 0000
00000040: 0000 0000 0000 0000 0000 0000 0000 0000
00000050: 0000 0000 0000 0000 0000 0000 0000 0000
...
...
Estos datos en hexadecimal indican que todos los valores de píxeles después de la decodificación son cero.
Al renderizar un video en Safari, obtenemos una captura de pantalla como esta:
Surge la pregunta: ¿qué es este espacio de color? Llamé al archivo 601.mp4, pero en ninguna parte del comando especifiqué un espacio de color, entonces, ¿cómo supo Safari qué tono de verde renderizar? ¿Cómo sabe el navegador que yuv (0,0,0) debe ser igual a rgb (0,135,0)? Evidentemente, existe un algoritmo para calcular estos valores. De hecho, esta es una simple multiplicación de matrices. (Nota: algunos formatos de píxeles, incluido yuv420p, requieren un paso de procesamiento previo y posterior para la conversión, pero en esta demostración omitiremos tales sutilezas). Cada espacio de color tiene su propia matriz. Dado que no especificamos la matriz del espacio de color al codificar el video, Safari solo hace una suposición. Podemos iterar sobre todas las matrices, multiplicar todos los valores RGB por las matrices inversas y ver a qué corresponden,pero intentemos un enfoque más visual y veamos si podemos averiguar qué está haciendo Safari.
Para hacer esto, insertaré metadatos en el archivo para que Safari sepa qué espacio de color se está utilizando y no tenga que adivinar.
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -color_range pc -y 601vui.mp4
El comando ffmpeg sigue siendo prácticamente el mismo, pero agregué lo siguiente:
-color_trc smpte170m
-colorspace smpte170m
-color_primaries smpte170m
Estos son los metadatos del espacio de color en el que se codificará el archivo. No explicaré las diferencias entre estas opciones, porque esto requerirá otro artículo. Por ahora, solo establecemos todos ellos en el espacio de color que necesitamos. smpte170m es lo mismo que BT.601.
La especificación de un espacio de color no afecta la forma en que se codifica el archivo, los valores de los píxeles aún se codifican como yuv (0,0,0). Para verificar esto, podemos ejecutar el comando en el nuevo archivo
ffmpeg -i zero.mp4 -f rawvideo - | xxd
. Los indicadores del espacio de color no se ignoran, sino que simplemente se escriben en unos pocos bits dentro de la sección "información de usabilidad de video" (VUI) en el encabezado del flujo de video. El decodificador ahora buscará la VUI y la usará para cargar la matriz deseada.
Y aquí está el resultado:
Con y sin VUI, los videos se renderizan con el mismo color. Probemos el archivo BT.709:
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -y 709.mp4
Nuevas opciones:
-i 601vui.mp4
— 601vui.mp4
-vf "colorspace=all=BT.709"
— ffmpeg, . yuv rgb, . «all» — color_primaries, colorspace color_trc.
Aquí tomamos el video 601vui.mp4 y usamos el filtro de espacio de color para convertirlo a BT.709. El filtro de espacio de color puede leer el espacio de color de los datos entrantes del archivo vui 601vui.mp4, por lo que solo necesitamos especificar el espacio de color que queremos recibir en la salida. Al ejecutar el
comando para este archivo
ffmpeg -i 709.mp4 -f rawvideo - | xxd
, obtenemos después de la transformación del espacio de color los valores de píxel yuv (93,67,68). Sin embargo, al renderizar el archivo, deberíael mismo aspecto. Vale la pena señalar que los resultados finales pueden no ser idénticos porque seguimos usando 24 bits para codificar cada píxel, y BT.709 tiene una gama de colores ligeramente mayor. En consecuencia, algunos colores en BT.709 no se asignan exactamente a BT.601 y viceversa.
Al observar el resultado, puede ver claramente que algo anda mal. El nuevo archivo se representa con valores rgb de 0.157.0, mucho más brillante que el archivo de entrada.
Echemos un vistazo de cerca a las propiedades del archivo usando la aplicación ffprobe:
ffprobe 601vui.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 320x240, 9 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
Y
ffprobe 709.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc), 320x240, 5 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
La mayor parte de la información aquí no es importante para nosotros, pero notaremos que 601vui.mp4 está en el formato de píxeles “yuvj420p (pc, smpte170m)”. Así es como entendemos que el archivo tiene la VUI correcta. Pero 709.mp4 solo contiene "yuvj420p (pc)". Parece que los metadatos del espacio de color no se incluyeron en el archivo de salida. Aunque el filtro de espacio de color pudo leer el espacio de color original y especificamos el nuevo espacio explícitamente, ffmpeg no escribió el vui correcto en el archivo final.
Esto es malo ... Ffmpeg es la herramienta de conversión de video más popular. Y se está perdiendo información sobre el color. Esta es probablemente la razón por la que muchos videos no contienen metadatos de espacio de color y, por lo tanto, muchos videos se procesan con colores que no coinciden. En defensa de ffmpeg, este es un problema complicado. Para inicializar el codificador, necesita conocer el espacio de color de antemano. Además, el espacio de color se puede cambiar con un filtro de video. Este es un problema complicado de resolver en código, pero aún así es triste que este comportamiento sea estándar.
Puede solucionarlo agregando manualmente metadatos de espacio de color:
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -colorspace bt709 -color_primaries bt709 -color_trc bt709 -color_range pc -y 709vui.mp4
Como resultado, el valor de color en 709vui.mp4 será rgb (0.132.0). El brillo del canal verde es ligeramente menor que en 601vui.mp4, pero como la conversión del espacio de color se produce con pérdida, y el resultado me conviene, lo llamaremos éxito.
De esto podemos concluir que cuando no se especifica ningún espacio de color en el archivo, Safari asume que es BT.601. Y en el lado de Safari, esa es una muy buena suposición. Pero como se dijo anteriormente, BT.601 es el estándar de video SD y BT.709 es el estándar de video HD. Echemos un vistazo a los videos HD con y sin VUI y veamos cómo los procesa Safari. Usé los mismos comandos ffmpeg, solo cambié la resolución a 1920x1080.
Tanto en SD como en HD, el color se reproduce igual. Safari no considera la resolución cuando hace suposiciones sobre el espacio de color. Apple ha estado en los medios y en el espacio editorial durante mucho tiempo, por lo que esperaba que el producto de esta compañía ofreciera resultados decentes. Pero incluso si todo es tan inteligente en Safari, es interesante cómo es la situación en otros navegadores.
Cromo:
Chrome hace que el video 601 sea un poco más oscuro que Safari, pero el 709 se ve igual. Sospecho que la diferencia se debe a las optimizaciones de velocidad en los cálculos de punto flotante, pero esto es irrelevante para nuestra prueba.
Sé por experiencia que cuando la aceleración de hardware está deshabilitada en la configuración, Chrome se renderiza de manera diferente:
Al examinar este resultado, podemos ver que los valores en 601 se renderizan de manera muy similar a los anteriores, pero los archivos 709 se renderizan como si no tuvieran una VUI. De esto podemos concluir que Chrome, con la aceleración de hardware deshabilitada, simplemente ignora la VUI y procesa todos los archivos como si estuvieran en formato 601. Esto significa que los 709 archivos no se reproducirán correctamente.
Finalmente, exploremos Firefox:
Hay mucho que hacer aquí. Dado que 709.mp4 y 709vui.mp4 tienen el mismo aspecto, puede concluir que si VUI no está disponible, Firefox asumirá el formato BT.709. Representar 601vui.mp4 correctamente significa que para el contenido BT.601 se tiene en cuenta la sección VUI. Sin embargo, cuando un archivo BT.601 sin VUI se representa como 709, se vuelve muy oscuro. Obviamente, es imposible renderizar una imagen correctamente sin toda la información necesaria, pero el método elegido por Firefox distorsiona el color más que el elegido por los navegadores Safari y Chrome.
Como podemos ver, la situación de la reproducción del color del video sigue siendo el Salvaje Oeste. Desafortunadamente, solo hemos cubierto una parte del problema. Todavía no hemos estudiado Windows. Vamos a hacer eso.
Microsoft Edge:
Parece que Edge (al menos en mi computadora) simplemente ignora VUI y muestra todo como 601.
Chrome (con aceleración de hardware habilitada):
La situación no es muy diferente a la de Mac. Si hay VUI, se maneja correctamente, pero si no está presente, se asume que es BT.601 para contenido SD y BT.709 para contenido HD. Este es el único navegador en el que he visto esto, pero tiene cierta lógica. Dado que la renderización se realiza de manera diferente a la de Mac, sospecho que el problema está en el sistema operativo o, más probablemente, en algo al nivel de los controladores de la tarjeta de video, y esta elección no fue tomada por el equipo de desarrollo de Chrome.
Firefox se comporta como lo hace en una Mac.
Para Linux, iOS, Android, Roku, Fire TV, televisores inteligentes, consolas de juegos, etc., dejaré esto como un ejercicio para el lector.
¿Qué hemos aprendido? Lo más importante: siempreIncluya metadatos de espacio de color en sus videos. Si está utilizando ffmpeg y no establece marcas de color, entonces no está funcionando correctamente. En segundo lugar, si bien ffmpeg es un programa excelente, su popularidad, facilidad de uso y valores predeterminados mal elegidos han sido un flaco favor. Nunca debe asumir que el software es lo suficientemente inteligente como para resolverlo por sí solo. Los gerentes de proyectos de Ffmpeg, Google, Mozilla, Microsoft (y probablemente Nvidia y AMD) deben reunirse y trabajar juntos para encontrar una forma. Entiendo que no hay una buena solución aquí, pero mala y predecible es mejor que mala y aleatoria. Personalmente, recomiendo asumir siempre el formato BT.601 si falta la sección VUI. Esto crea la menor cantidad de distorsión. Puede seleccionarse para alinear este estándar FOMS, o incluso la AOM , ya que estas organizaciones están bastante bien representadas.
Por último, pero no menos importante, si tiene un video sin información de color y necesita convertirlo o renderizarlo, ¡buena suerte!
Publicidad
VDSina ofrece servidores económicos con pago diario. El canal de Internet para cada servidor es de 500 Megabits, la protección contra ataques DDoS está incluida en la tarifa, la posibilidad de instalar Windows, Linux o el SO en general desde su imagen, y también un panel de control de servidor propietario muy conveniente . Es hora de intentarlo;)
Únete a nuestro chat en Telegram .
