La magia de H.264 (2016)
(sidbala.com)- H.264, usado en video por Internet, Blu-ray, teléfonos móviles, cámaras de seguridad y drones, es un estándar de compresión de video desarrollado para enviar video en movimiento completo con un ancho de banda realista
- Un video 1080p a 60 Hz sin comprimir llega a unos 370 MB/s según
1920×1080×60×3, por lo que incluso en un disco Blu-ray de 50 GB sería difícil guardar más de unos 2 minutos - La clave de la compresión es la compresión con pérdida: reducir detalles menos perceptibles y bajar la cantidad de datos mediante transformación al dominio de frecuencia, cuantización y submuestreo de crominancia
- La compresión temporal divide los fotogramas en I-frame, P-frame y B-frame, y restaura los cambios en lugar de fotogramas completos usando vectores de movimiento de macrobloques de 16×16 píxeles
- En el ejemplo, un video H.264 de 5 segundos a 60 fps, con 300 fotogramas, pesaba 175 KB, mientras que una sola captura PNG pesaba 1015 KB; el video original de 1.2 GB se redujo a 175 KB
Los datos que H.264 intenta reducir
- H.264 es un estándar de códec de compresión de video ampliamente usado en video por Internet, Blu-ray, teléfonos móviles, cámaras de seguridad, drones y más
- Su objetivo es reducir el ancho de banda necesario para la transmisión de video en movimiento completo
- Muchos de los conceptos tratados aquí se aplican no solo a H.264, sino también a la compresión de video en general
Por qué el video sin comprimir es tan grande
- Un archivo de video simple sin comprimir es un arreglo de búferes 2D que contiene los datos de píxeles de cada fotograma, y puede verse como un arreglo 3D de bytes con dos dimensiones espaciales y una dimensión temporal
- Cada píxel usa 3 bytes para los tres colores primarios: rojo, verde y azul
- Un video 1080p a 60 Hz genera unos 370 MB/s de datos en bruto con el siguiente cálculo
1920 × 1080 × 60 × 3
- Con ese tamaño, en un disco Blu-ray de 50 GB solo caben unos 2 minutos, y moverlo o almacenarlo también se vuelve difícil
Un video de 5 segundos más pequeño que una sola imagen PNG
- El ejemplo de la pantalla de la página principal de Apple muestra de forma intuitiva el efecto de la compresión H.264
- El video de 5 segundos a 60 fps tiene 300 fotogramas, pero su tamaño de archivo es aproximadamente una quinta parte del de un solo fotograma PNG
- Como un video que aparentemente contiene 300 veces más datos es más pequeño, H.264 parece mucho más eficiente que PNG
Información que se descarta con la compresión con pérdida
- H.264 es un códec de compresión con pérdida: descarta los bits menos importantes y conserva solo los importantes
- PNG es un códec de compresión sin pérdida, por lo que a partir de la imagen codificada puede recuperarse la imagen fuente original bit por bit
- H.264 no recorta la imagen ni descarta un cuadrante específico; igual que otros algoritmos de imagen con pérdida, reduce la información de detalle
- En la imagen de ejemplo desaparecen detalles como los agujeros de la rejilla del parlante de la MacBook Pro, pero si no se hace zoom es difícil notar la diferencia
- Solo con este paso, la imagen ya se reduce a alrededor del 7% del tamaño original
Entropía y eliminación de redundancia
- La entropía de información es la cantidad de bits necesarios para representar cierta información, y no es lo mismo que el tamaño simple de un conjunto de datos
- Puede entenderse como la cantidad mínima de bits necesaria para representar los estados posibles, como los resultados de lanzar una moneda
- Si al lanzar una moneda 10 veces todas salen cara, en vez de escribir
HHHHHHHHHHse puede expresar de forma más breve como “10 veces cara” - Este proceso no cambia la información en sí, solo reduce su representación, eliminando la redundancia
- A este tipo de codificador sin pérdida de propósito general se le llama codificador de entropía
Dominio de frecuencia y cuantización
- Los datos que varían en el espacio o el tiempo pueden transformarse a otro sistema de coordenadas, y los valores de brillo de una imagen también pueden representarse en el dominio de frecuencia
- En el dominio de frecuencia, los componentes de baja frecuencia están hacia el centro y los de alta frecuencia hacia los bordes
- Los patrones detallados, como una rejilla fina en una imagen, corresponden a componentes de alta frecuencia, mientras que los cambios suaves de color y brillo corresponden a componentes de baja frecuencia
- Si se enmascaran los bordes de una imagen en el dominio de frecuencia, puede descartarse la información de alta frecuencia; al transformarla de vuelta al sistema de coordenadas x-y normal, se obtiene una imagen similar a la original, pero con menos detalle
- Al cambiar el tamaño de la máscara también se puede ajustar el nivel de detalle de la imagen resultante
- En el ejemplo, aunque la entropía de información sea solo alrededor del 2% de la original, es difícil notar la diferencia si no se hace zoom
- En la compresión con pérdida, este proceso se llama cuantización (quantization)
Submuestreo de crominancia
- El ojo y el cerebro humanos detectan bien los cambios de brillo, pero distinguen relativamente peor las diferencias finas de color
- En las señales de TV, los datos de color RGB se transforman a Y+Cb+Cr
Y: luminancia, básicamente brillo en blanco y negroCb,Cr: crominancia, es decir, componentes de color
- RGB y YCbCr son equivalentes en términos de entropía de información
- En la época de la televisión en blanco y negro solo existía la señal Y; con la llegada de la TV a color, se empezó a codificar la información de color como Cb y Cr y a transmitirla junto con Y
- Los televisores en blanco y negro solo miran el componente Y, mientras que los televisores a color también usan los componentes de crominancia y los convierten internamente a RGB
- El método usado en H.264 consiste en guardar el componente Y a resolución completa y los componentes C a un cuarto de la resolución
- El submuestreo de crominancia descarta parte de la información de color, reduciendo el ancho de banda total a la mitad y manteniendo pequeñas las diferencias visuales
- Esta técnica no es exclusiva de H.264; se ha usado ampliamente durante décadas
Compensación de movimiento y compresión temporal
- H.264 es un estándar de compresión con compensación de movimiento
- Más allá de la compresión espacial dentro de un solo fotograma, procesa varios fotogramas juntos en la dimensión temporal
- En un video como un partido de tenis, donde la cámara está fija y solo se mueve la pelota, no hace falta guardar todo el fondo cada vez
- Por lo general, la imagen se divide en macrobloques de 16×16 píxeles, y el movimiento se estima por bloques
- Hay tres tipos principales de fotogramas
- I-frame: fotograma que contiene todos los bits necesarios para construir el fotograma completo
- P-frame: fotograma predictivo que codifica los vectores de movimiento de cada macrobloque a partir de un fotograma anterior
- B-frame: fotograma predictivo bidireccional que predice a partir de fotogramas pasados y futuros
- El decodificador comienza desde el último I-frame y construye el fotograma actual sumando los deltas de vectores de movimiento de los fotogramas siguientes
- El video de ejemplo de la página principal de Apple se comprime muy bien porque, en la práctica, consiste en macrobloques que se mueven a partir de tres I-frames
Por qué se queda pausado un momento después de retroceder
- El fenómeno en videos como los de YouTube, donde al retroceder unos segundos no se reproducen de inmediato y se quedan pausados un momento, está relacionado con la estructura de H.264
- Si el usuario salta a un fotograma arbitrario, el decodificador debe recalcular desde el I-frame más cercano
- Luego debe acumular los deltas de vectores de movimiento hasta el fotograma posterior para generar el fotograma actual, por lo que el costo computacional es alto
- Este método es muy eficiente en espacio, pero requiere cómputo para la decodificación
Última etapa de compresión sin pérdida
- Incluso en los I-frame que ya pasaron por las etapas con pérdida, todavía queda información redundante
- Los vectores de movimiento de macrobloques en los P-frame y B-frame también pueden formar grupos con los mismos valores
- Especialmente cuando la pantalla hace paneo, como en el video de prueba, varios macrobloques se mueven la misma cantidad
- El codificador de entropía se encarga de esta redundancia
- Como el codificador de entropía es un codificador sin pérdida de propósito general, los datos de entrada pueden recuperarse
Ejemplo de tasa de compresión
- El video original de ejemplo se capturó con una resolución no estándar de
1232×1154 - Con 5 segundos a 60 fps, el tamaño original es de unos 1.2 GB según el siguiente cálculo
1232 × 1154 × 60 × 3 × 5
- El video H.264 comprimido pesa 175 KB
- Usando la analogía del auto en el artículo, es como si un auto de 3000 libras se redujera a 0.4 libras, es decir, 6.5 onzas
- Esta explicación de la tasa de compresión simplifica enormemente décadas de investigación; para más detalles, se puede ver la página de Wikipedia de H.264/MPEG-4 AVC
1 comentarios
Opiniones de Hacker News
AV1 es un códec con mejores licencias y más mágico
Meta está llevando gradualmente los streams VP9/AV1 como base para el streaming de video: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
También usa AV1 para videollamadas: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft también empezó a usar AV1 en Teams, y AV1 tiene herramientas de codificación de video especialmente útiles para compartir pantalla: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
La mayoría de los videos que se ven hoy en YouTube son VP9 o AV1, y H.264 aparece solo de vez en cuando
H.264 seguirá bastante tiempo, pero parece muy probable que AV1 se convierta en la nueva base del video en Internet
Desde la perspectiva de los desarrolladores, debería estar al alcance de todos, pero por ahora estamos esperando a que esa capacidad llegue a la mayoría de los usuarios
Sería bueno que más usuarios compraran hardware con codificación/decodificación AV1, y parece que hace falta un logo tipo “AV1 inside”
Por ejemplo, en la línea iPhone, por ahora solo el iPhone 15 Pro ofrece decodificación por hardware
Tenía que grabar videos de clases y subirlos como archivos relativamente pequeños a 720p, pero eran videos de una persona moviéndose lentamente frente a líneas delgadas y nítidas en una pizarra blanca, con iluminación mediocre, así que el perfil de codificación predeterminado de x264 no encajaba bien
Aun así, tras ajustar la configuración durante un día o dos, logré que una laptop con solo una iGPU de alrededor de 2014 lo procesara la noche siguiente a la clase y pudiera subir el resultado al día siguiente
En cambio, libaom indicaba que renderizar un video de 3 horas tardaría más o menos una semana, y los valores predeterminados eran tan malos que no tenía margen para experimentar
Eso fue hace 4 años, así que quizá haya mejorado, pero no espero milagros
No necesariamente es un problema, pero el verdadero problema de AV1 es que la compresión exige demasiada computación
O tal vez mi vista mejoró
Me gustaría que hubiera algún artículo que profundizara en este tema
Artículos relacionados:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - marzo de 2022, 219 comentarios
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - mayo de 2019, 180 comentarios
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - mayo de 2018, 1 comentario
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - noviembre de 2016, 219 comentarios
Ahora, 8 años después de que se escribiera ese artículo, una buena parte de las patentes de H.264 está por expirar pronto, aproximadamente dentro de 1 o 2 años: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
No sorprende si se considera que la primera versión del estándar H.264 salió en 2003 y que las patentes suelen tener una vigencia de 20 años
La generación anterior, H.263 y MPEG-4 ASP, ya tiene las patentes vencidas y está en el dominio público
Entonces, ¿qué onda con H.265? Es un número más alto, ¿no? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
La codificación en H.265 requiere demasiado cómputo adicional para el espacio que ahorra
Es como tomar un archivo que con H.264 tardaría 1 hora en reducirse a 1 GB, y con H.265 tardar 12 horas para reducirlo a 850 MB
Según el uso, igual puede que necesites una versión H.264, que tiene soporte mucho más amplio en clientes
Si tienes recursos de cómputo a nivel de centro de datos, o si operas un servicio de streaming donde ahorrar 150 MB por video se acumula, te subirías a H.265; pero en muchos casos reales es difícil justificarlo
Está casi al nivel de VP9, pero por problemas de licencias todavía le costó ser adoptado en todas partes
VVC/H.266 parece sufrir el mismo problema, y AV1 es casi igual de bueno y ya está mucho más adoptado
Los códecs más nuevos comprimen mejor, pero la complejidad crece de forma no lineal
El tamaño de los archivos quedó mucho menor que con H.264
El estándar también es 10 años más joven que H.264: H.264 es de 2003 y H.265 de 2013
En el ejemplo de “si lanzas una moneda 10 veces y todas salen cara, no dices HHHHHHHHHH, sino ‘la lancé 10 veces y todas fueron cara’”, parece que esa cadena de H tiene algo de compresión con pérdida
Recuerdo cuando salió H.264 por primera vez
En esa época estaba metido con mplayer, así que solía bajar y compilar las versiones más recientes
Cuando recibí mi primer archivo H.264, mplayer no lo pudo leer, así que tuve que bajar y compilar la versión de desarrollo
Funcionó, y me di cuenta de dos cosas: la calidad de imagen era sorprendente, y mi Athlon 1800+ no podía con eso
Más adelante el rendimiento mejoró muchísimo en versiones de mplayer o libavcodec, pero todavía recuerdo ese día
Hace muchísimo que no uso mplayer, pero en ese entonces era lo mejor
Antes trabajé en una empresa que desarrollaba un producto basado en video, y otra empresa de Las Vegas les vendió a nuestros ejecutivos un “códec de video innovador” y un reproductor; para usarlo había que firmar un NDA
Al probarlo, se comportaba como mplayer; demasiado igual
Con 5 minutos más de investigación quedó al descubierto, y los ejecutivos que le habían pagado mucho dinero a esa empresa quedaron en ridículo
Incluso en el sector tecnológico, es sorprendentemente fácil engañar a tomadores de decisiones no técnicos
Es porque les preocupa demasiado quedarse atrás
Una persona inteligente llama a buenos ingenieros para que evalúen; los casos de Dunning-Kruger hacen fila con la cartera en la mano
Hubo una época en la que estaba por irme de una startup adquirida en 1999, y en ese momento yo estaba trabajando en codificación MPEG.
Una de las empresas en las que me entrevisté dijo que había creado un nuevo método de compresión de video y, después de firmar un NDA, me mostraron un clip corto codificado/decodificado con un códec de software no en tiempo real.
Me estaban entrevistando para ser la persona que hiciera una versión ASIC de ese algoritmo, pero con ver apenas 1 o 2 minutos de la salida ya me imaginé qué estaba haciendo.
Supuse que el ejemplo estaba elegido para mostrar las fortalezas del algoritmo, así que propuse una escena más difícil y también expliqué qué método me parecía que usaba.
No confirmaron ni negaron nada, pero me llamaron a una segunda entrevista.
En la segunda hablé con la pareja fundadora, CEO/CTO, y su plan no era vender ASIC, sino mantener el códec en secreto y usar el ASIC para crear una red de cable basada en DSL para distribuir video.
Les dije: “suena como si hubieran inventado un carburador mejor y quisieran construir una fábrica de autos para competir con GM”, y no se lo tomaron bien.
El punto en el que esta historia se conecta con H.264 es que su argumento era: “la compresión existente llegó a su límite, por eso solo nuestro códec puede enviar video de alta calidad por líneas DSL”.
Les respondí que los compresores seguirían mejorando y que, aunque no fuera así, cuando llegara Internet más rápido a los hogares desaparecería el propio umbral que ellos creían poder superar.
Ellos dijeron que, por las leyes de la física, había un límite a la tasa de bits que se podía enviar por un cable y que ya se había alcanzado ese límite.
No recibí una oferta de empleo, y tampoco la quería.
Esa empresa recibió dinero de VC, pero cerró unos años después; otras personas hicieron códecs mucho más eficientes, y una conexión a Internet de 2 Mbps no era el límite.
Seguramente en el algoritmo real había mucha matemática inteligente y fuerza algorítmica, así que técnicamente no eran tontos; les faltaba criterio de negocio.
Contado así suena a que soy un sabelotodo presumido, pero fue una de las dos veces en mi vida en que vi algo y en segundos descubrí el ingrediente secreto.
Hay muchos más ejemplos de cuando fui un tonto.
Nunca me confirmaron el algoritmo, pero por los artefactos de silueta era bastante evidente.
MPEG, como JPEG, comprime imágenes en bloques pequeños (8x8, 16x16, etc.), lo que limita el alcance para aprovechar la redundancia espacial, pero también limita el costo computacional de encontrar esa redundancia.
Su códec parecía algo parecido a lo que Microsoft había propuesto a fines de los 90 para la arquitectura gráfica Talisman.
En vez de dividir en bloques fijos, parecía analizar una secuencia de frames para encontrar regiones estructuralmente coherentes con bordes semi arbitrarios.
Por ejemplo, en un partido de tenis, el fondo es bastante cercano a un “cuerpo rígido”: si la cámara hace un paneo y un píxel se mueve, es probable que los píxeles alrededor sufran la misma transformación espacial.
El jugador cambia de un frame a otro, pero ese conjunto tiene correlaciones de iluminación y posición.
Después de identificar esas regiones, probablemente comprimían la imagen de cada región de una forma parecida a JPEG y, en el siguiente frame, analizaban cómo una región sufría una transformación afín, o una transformación más general, hacia el siguiente frame, codificándola con unos pocos parámetros.
Eso se convierte en la base de la predicción del siguiente frame y, si encaja bien, no se necesitan muchos bits para corregir el error de predicción.
Dicen que recibió 32 millones de dólares de VC y salió del modo stealth en 2002.
No pude encontrar qué pasó después.
El artículo es muy bueno, pero haber usado Information Entropy como si fuera un término aparte está entre las expresiones tipo “ATM machine” que más me molestan.
El texto en sí es bueno, pero la expresión pega fuerte.
En 02016, H.264 era una magia atada por patentes en varios países.
Ahora, el estándar se publicó en agosto de 02004 tras un año de trabajo de estandarización abierto; las patentes solo duran 20 años desde la fecha de solicitud, y no se puede patentar algo ya publicado, así que la mayoría ya venció o vencerá en unos meses.
En EE. UU. hay un período de gracia de un año si la divulgación la hizo el propio inventor, pero si hay alguna excepción, me encantaría escucharla.
userbinator apuntó a https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., pero la mayoría de las patentes de ahí tienen fechas de prioridad posteriores a la finalización del estándar H.264, así que no pueden ser esenciales para implementar H.264 en sí.
Salvo que se argumente que en el momento de la estandarización no se sabía que se podía implementar, pero eso suena bastante poco convincente.
Lo sorprendente es que durante los últimos 20 años han salido cosas que podrían llamarse un poco mejores, pero según mis pruebas con implementaciones de ffmpeg, no ha habido nada mucho mejor.
Si queda garantizado su estatus libre de patentes, parece muy probable que H.264, nos guste o no, se consolide aún más como códec estándar por un tiempo.
AV1 ofrece una calidad visual un poco mejor con el mismo ancho de banda, pero es mucho más lento y también es vulnerable a patentes solicitadas tan tarde como en 02018.
Eso de “como le pediste al decodificador que saltara a un frame arbitrario, tiene que empezar desde el I-frame más cercano y volver a hacer el cálculo de sumar los deltas de los vectores de movimiento hasta el frame actual, por eso se pausa un momento” era cosa de 2016.
Hoy en día es porque YouTube sabe que estás usando Firefox.