Codificación de video avanzada

Diagrama de bloque de la capa de codificación de vídeo del encoder H.264 con puntuación de calidad perceptual

Codificación de video avanzada (AVC), también conocida como H.264 o MPEG-4 Parte 10, es un estándar de compresión de video basado en codificación compensada por movimiento y orientada a bloques. Es, con mucho, el formato más utilizado para la grabación, compresión y distribución de contenido de video, utilizado por el 91 % de los desarrolladores de la industria del video a partir de septiembre de 2019. Admite una resolución máxima de 8K UHD.

La intención del proyecto H.264/AVC era crear un estándar capaz de proporcionar una buena calidad de video a tasas de bits sustancialmente más bajas que los estándares anteriores (es decir, la mitad o menos de la tasa de bits de MPEG-2, H.263, o MPEG-4 Parte 2), sin aumentar tanto la complejidad del diseño que sería poco práctico o excesivamente costoso de implementar. Esto se logró con características tales como una transformación de coseno discreta de enteros de complejidad reducida (DCT de enteros), segmentación de tamaño de bloque variable y predicción entre imágenes de múltiples imágenes. Un objetivo adicional era proporcionar suficiente flexibilidad para permitir que el estándar se aplicara a una amplia variedad de aplicaciones en una amplia variedad de redes y sistemas, incluidas tasas de bits bajas y altas, video de baja y alta resolución, transmisión, almacenamiento de DVD, RTP/ Redes de paquetes IP y sistemas de telefonía multimedia ITU-T. El estándar H.264 puede verse como una "familia de estándares" compuesto por una serie de perfiles diferentes, aunque su "Perfil alto" es, con diferencia, el formato más utilizado. Un decodificador específico decodifica al menos uno, pero no necesariamente todos los perfiles. El estándar describe el formato de los datos codificados y cómo se decodifican los datos, pero no especifica los algoritmos para codificar video; eso queda abierto para que los diseñadores de codificadores seleccionen por sí mismos, y se ha desarrollado una amplia variedad de esquemas de codificación. desarrollado. H.264 se usa normalmente para la compresión con pérdida, aunque también es posible crear regiones codificadas sin pérdida dentro de imágenes codificadas con pérdida o admitir casos de uso poco frecuentes en los que la codificación completa es sin pérdida.

H.264 fue estandarizado por el Grupo de expertos en codificación de video (VCEG) de ITU-T del Grupo de estudio 16 junto con el Grupo de expertos en imágenes en movimiento (MPEG) ISO/IEC JTC 1. El esfuerzo de asociación del proyecto se conoce como Joint Video Team (JVT). El estándar ITU-T H.264 y el estándar ISO/IEC MPEG-4 AVC (formalmente, ISO/IEC 14496-10 – MPEG-4 Part 10, Advanced Video Coding) se mantienen de forma conjunta para que tengan un contenido técnico idéntico. El trabajo de redacción final de la primera versión de la norma se completó en mayo de 2003, y se han agregado varias extensiones de sus capacidades en ediciones posteriores. La codificación de video de alta eficiencia (HEVC), también conocida como H.265 y MPEG-H Parte 2, es un sucesor de H.264/MPEG-4 AVC desarrollado por las mismas organizaciones, mientras que los estándares anteriores todavía son de uso común.

H.264 es quizás mejor conocido como el formato de codificación de video más utilizado en discos Blu-ray. También es ampliamente utilizado para la transmisión de fuentes de Internet, como videos de Netflix, Hulu, Amazon Prime Video, Vimeo, YouTube y iTunes Store, software web como Adobe Flash Player y Microsoft Silverlight, y también varias transmisiones de HDTV por tierra. (ATSC, ISDB-T, DVB-T o DVB-T2), cable (DVB-C) y satélite (DVB-S y DVB-S2).

H.264 está restringido por patentes propiedad de varias partes. Una licencia que cubre la mayoría (pero no todas) las patentes esenciales para H.264 es administrada por un grupo de patentes administrado por MPEG LA. El uso comercial de tecnologías H.264 patentadas requiere el pago de regalías a MPEG LA y otros propietarios de patentes. MPEG LA ha permitido el uso gratuito de tecnologías H.264 para la transmisión de video por Internet que es gratuito para los usuarios finales, y Cisco Systems paga regalías a MPEG LA en nombre de los usuarios de binarios por su codificador H.264 de código abierto openH264.

Nombramiento

El nombre H.264 sigue la convención de nomenclatura ITU-T, donde las recomendaciones reciben una letra correspondiente a su serie y un número de recomendación dentro de la serie. H.264 es parte de "Recomendaciones de la serie H: sistemas audiovisuales y multimedia". H.264 se clasifica además en "H.200-H.499: Infraestructura de servicios audiovisuales" y "H.260-H.279: Codificación de video en movimiento". El nombre MPEG-4 AVC se relaciona con la convención de nomenclatura en ISO/IEC MPEG, donde el estándar es la parte 10 de ISO/IEC 14496, que es el conjunto de estándares conocido como MPEG-4. El estándar se desarrolló conjuntamente en una asociación de VCEG y MPEG, luego de un trabajo de desarrollo anterior en ITU-T como un proyecto VCEG llamado H.26L. Por lo tanto, es común referirse al estándar con nombres como H.264/AVC, AVC/H.264, H.264/MPEG-4 AVC o MPEG-4/H.264 AVC, para enfatizar la herencia común. Ocasionalmente, también se lo conoce como "el códec JVT", en referencia a la organización Joint Video Team (JVT) que lo desarrolló. (Esta asociación y la denominación múltiple no son infrecuentes. Por ejemplo, el estándar de compresión de video conocido como MPEG-2 también surgió de la asociación entre MPEG y el ITU-T, donde el video MPEG-2 es conocido por la comunidad del ITU-T como H.262.) Algunos programas de software (como VLC media player) identifican internamente este estándar como AVC1.

Historia

Historial general

A principios de 1998, el Grupo de expertos en codificación de video (VCEG - ITU-T SG16 Q.6) emitió una convocatoria de propuestas sobre un proyecto llamado H.26L, con el objetivo de duplicar la eficiencia de codificación (lo que significa reducir a la mitad el bit necesaria para un determinado nivel de fidelidad) en comparación con cualquier otro estándar de codificación de video existente para una amplia variedad de aplicaciones. VCEG fue presidido por Gary Sullivan (Microsoft, anteriormente PictureTel, EE. UU.). El primer borrador del diseño de ese nuevo estándar se adoptó en agosto de 1999. En 2000, Thomas Wiegand (Instituto Heinrich Hertz, Alemania) se convirtió en copresidente de VCEG.

En diciembre de 2001, VCEG y el Grupo de expertos en imágenes en movimiento (MPEG – ISO/IEC JTC 1/SC 29/WG 11) formaron un Equipo de video conjunto (JVT), con el mandato de finalizar el estándar de codificación de video. La aprobación formal de la especificación se produjo en marzo de 2003. El JVT estaba (es) presidido por Gary Sullivan, Thomas Wiegand y Ajay Luthra (Motorola, EE. UU.: luego Arris, EE. UU.). En julio de 2004, se finalizó el proyecto Fidelity Range Extensions (FRExt). Desde enero de 2005 hasta noviembre de 2007, el JVT estuvo trabajando en una extensión de H.264/AVC hacia la escalabilidad mediante un Anexo (G) llamado Scalable Video Coding (SVC). Jens-Rainer Ohm (Universidad RWTH Aachen, Alemania) amplió el equipo directivo de JVT. Desde julio de 2006 hasta noviembre de 2009, JVT trabajó en Multiview Video Coding (MVC), una extensión de H.264/AVC hacia la televisión 3D y la televisión de punto de vista libre de rango limitado. Ese trabajo incluyó el desarrollo de dos nuevos perfiles del estándar: el Multiview High Profile y el Stereo High Profile.

A lo largo del desarrollo del estándar, se han desarrollado mensajes adicionales para contener información de mejora suplementaria (SEI). Los mensajes SEI pueden contener varios tipos de datos que indican la sincronización de las imágenes de video o describen varias propiedades del video codificado o cómo se puede usar o mejorar. También se definen mensajes SEI que pueden contener datos arbitrarios definidos por el usuario. Los mensajes SEI no afectan el proceso de decodificación central, pero pueden indicar cómo se recomienda que el video sea procesado o mostrado. Algunas otras propiedades de alto nivel del contenido de video se transmiten en la información de usabilidad de video (VUI), como la indicación del espacio de color para la interpretación del contenido de video. A medida que se desarrollaron nuevos espacios de color, como para video de alto rango dinámico y amplia gama de colores, se agregaron identificadores VUI adicionales para indicarlos.

Ampliaciones de gama de fidelidad y perfiles profesionales

La estandarización de la primera versión de H.264/AVC se completó en mayo de 2003. En el primer proyecto para extender el estándar original, JVT desarrolló lo que se denominó Extensiones de rango de fidelidad (FRExt). Estas extensiones permitieron una codificación de video de mayor calidad al admitir una mayor precisión de profundidad de bits de muestra e información de color de mayor resolución, incluidas las estructuras de muestreo conocidas como Y′CBCR 4: 2: 2 (también conocido como YUV 4: 2: 2) y 4: 4: 4. También se incluyeron otras funciones en el proyecto FRExt, como la adición de una transformada de coseno discreta entera de 8 × 8 (DCT entera) con conmutación adaptativa entre las transformadas de 4 × 4 y 8 × 8, matrices de ponderación de cuantificación basadas en la percepción especificadas por codificador, codificación eficiente entre imágenes sin pérdidas y compatibilidad con espacios de color adicionales. El trabajo de diseño del proyecto FRExt se completó en julio de 2004 y el trabajo de redacción se completó en septiembre de 2004.

Luego se desarrollaron otros cinco perfiles nuevos (consulte la versión 7 a continuación) destinados principalmente a aplicaciones profesionales, agregando compatibilidad con espacio de color de gama ampliada, definiendo indicadores de relación de aspecto adicionales y definiendo dos tipos adicionales de "información de mejora complementaria" (sugerencia posterior al filtro y mapeo de tonos) y la desaprobación de uno de los perfiles FRExt anteriores (el perfil High 4:4:4) que, según los comentarios de la industria, debería haberse diseñado de manera diferente.

Codificación de video escalable

La siguiente función importante que se agregó al estándar fue la codificación de video escalable (SVC). Especificado en el Anexo G de H.264/AVC, SVC permite la construcción de flujos de bits que contienen capas de flujos de bits secundarios que también cumplen con el estándar, incluido uno de esos flujos de bits conocido como "base capa" que se puede decodificar con un códec H.264/AVC que no admite SVC. Para la escalabilidad del flujo de bits temporal (es decir, la presencia de un flujo de bits secundario con una tasa de muestreo temporal más pequeña que el flujo de bits principal), las unidades de acceso completas se eliminan del flujo de bits cuando se deriva el flujo de bits secundario. En este caso, las imágenes de referencia de sintaxis de alto nivel y de predicción mutua en el tren de bits se construyen en consecuencia. Por otro lado, para la escalabilidad del flujo de bits espacial y de calidad (es decir, la presencia de un flujo de bits secundario con una resolución/calidad espacial más baja que el flujo de bits principal), la capa de abstracción de red (NAL) se elimina del flujo de bits cuando se deriva el flujo de bits secundario.. En este caso, la predicción entre capas (es decir, la predicción de la señal de calidad/resolución espacial más alta a partir de los datos de la señal de calidad/resolución espacial más baja) se usa típicamente para una codificación eficiente. Las extensiones de codificación de video escalable se completaron en noviembre de 2007.

Codificación de vídeo multivista

La siguiente función importante que se agregó al estándar fue la codificación de video de vistas múltiples (MVC). Especificado en el Anexo H de H.264/AVC, MVC permite la construcción de flujos de bits que representan más de una vista de una escena de video. Un ejemplo importante de esta funcionalidad es la codificación de video 3D estereoscópico. Se desarrollaron dos perfiles en el trabajo de MVC: el perfil Multiview High admite una cantidad arbitraria de vistas y el perfil Stereo High está diseñado específicamente para video estereoscópico de dos vistas. Las extensiones de Multiview Video Coding se completaron en noviembre de 2009.

Codificación estereoscópica 3D-AVC y MFC

Más tarde se desarrollaron extensiones adicionales que incluían codificación de video 3D con codificación conjunta de mapas de profundidad y textura (denominado 3D-AVC), codificación estereoscópica y 3D-MFC compatible con marcos de resolución múltiple (MFC), varias combinaciones adicionales de funciones, y tamaños de fotogramas y velocidades de fotogramas más altos.

Versiones

Las versiones del estándar H.264/AVC incluyen las siguientes revisiones, correcciones y enmiendas completadas (las fechas son las fechas de aprobación final en ITU-T, mientras que las fechas de aprobación final de "Estándar internacional" en ISO/IEC son algo diferentes y ligeramente posteriores en la mayoría de los casos). Cada versión representa cambios con respecto a la siguiente versión inferior que se integra en el texto.

• Versión 1 (edición 1): 30 de mayo de 2003) Primera versión aprobada de H.264/AVC con perfiles Baseline, Main y Extended.
• Versión 2 (edición 1.1): (7 de mayo de 2004) Corrección que contiene diversas correcciones menores.
• Versión 3 (edición 2): (1 de marzo de 2005) Mayor adición que contiene la primera enmienda, estableciendo las extensiones de rango de Fidelity (FRExt). Esta versión añadió los perfiles Alto, Alto 10, Alto 4:2:2, y Alto 4:4:4. Después de unos años, el perfil alto se convirtió en el perfil más utilizado del estándar.
• Versión 4 (edición 2.1): (13 de septiembre de 2005) Corrigendum containing various minor corrections and adding three aspect ratio indicators.
• Versión 5 (edición 2.2): (13 de junio de 2006) Enmienda consistente en la eliminación del perfil anterior Alto 4:4:4 (procesado como corrección en ISO/IEC).
• Versión 6 (edición 2.2): (13 de junio de 2006) Enmienda que consiste en extensiones menores como soporte espacial de gama ampliada (englosado con indicadores de relación de aspecto arriba mencionados en ISO/IEC).
• Versión 7 (edición 2.3): (6 de abril de 2007) Enmienda que contiene la adición del perfil predictivo 4:4:4 y cuatro perfiles intra-sólo (High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, and CAVLC 4:4:4 Intra).
• Versión 8 (edición 3): (22 de noviembre de 2007) Important addition to H.264/AVC containing the amendment for Scalable Video Coding (SVC) containing Scalable Baseline, Scalable High, and Scalable High Intra profiles.
• Versión 9 (edición 3.1): (13 de enero de 2009) Corrección que contiene correcciones menores.
• Versión 10 (edición 4): (16 de marzo de 2009) Enmienda que contiene la definición de un nuevo perfil (el perfil Baseline Constrained) con sólo el subconjunto común de capacidades soportadas en varios perfiles previamente especificados.
• Versión 11 (edición 4): (16 de marzo de 2009) Important addition to H.264/AVC containing the amendment for Multiview Video Coding (MVC) extension, including the Multiview High profile.
• Versión 12 (edición 5): (9 de marzo de 2010) Enmienda que contiene la definición de un nuevo perfil MVC (el perfil Stereo High) para la codificación de vídeo de dos vistas con soporte de herramientas de codificación interrelacionadas y especificando un mensaje adicional de mejora (SEI) llamado el arreglo de embalaje de marco mensaje SEI.
• Versión 13 (edición 5): (9 de marzo de 2010) Corrección que contiene correcciones menores.
• Versión 14 (edición 6): (29 de junio de 2011) Enmienda que especifica un nuevo nivel (Nivel 5.2) que soporta tasas de procesamiento más altas en términos de macroblocks máximos por segundo, y un nuevo perfil (el perfil superior progresivo) que solo soporta las herramientas de codificación de marcos del perfil alto especificado anteriormente.
• Versión 15 (edición 6): (29 de junio de 2011) Corrección que contiene correcciones menores.
• Versión 16 (edición 7): (13 de enero de 2012) Enmienda que contiene la definición de tres nuevos perfiles destinados principalmente a aplicaciones de comunicación en tiempo real: la línea de base constricida de alto nivel, escalable y perfiles elevados escalables.
• Versión 17 (edición 8): (13 de abril de 2013) Enmienda con indicadores adicionales de mensajes de SEI.
• Versión 18 (edición 8): (13 de abril de 2013) Enmienda para especificar la codificación de los datos del mapa de profundidad para el vídeo estereoscópico 3D, incluyendo un perfil multiview Depth High.
• Versión 19 (edición 8): (13 de abril de 2013) Corrección para corregir un error en el proceso de extracción sub-bitstream para vídeo multivisual.
• Versión 20 (edición 8): (13 de abril de 2013) Enmienda para especificar identificadores adicionales de espacio de color (incluido el apoyo de la Recomendación ITU-R BT.2020 para UHDTV) y un tipo de modelo adicional en el mensaje de mapa de tonos SEI.
• Versión 21 (edición 9): (13 de febrero de 2014) Enmienda para especificar el perfil superior de profundidad multivista mejorado.
• Versión 22 (edición 9): (13 de febrero de 2014) Enmienda para especificar la mejora del marco multi-resolución compatible (MFC) para el vídeo estereoscópico 3D, el perfil MFC High y correcciones menores.
• Versión 23 (edición 10): (13 de febrero de 2016) Modificación para especificar el vídeo estereoscópico MFC con mapas de profundidad, el perfil MFC Depth High, el mensaje SEI de volumen de visualización de imágenes de color y los identificadores de códigos VUI relacionados con colores adicionales.
• Versión 24 (edición 11): (14 de octubre de 2016) Enmienda para especificar niveles adicionales de capacidad de decodificador que soportan tamaños de imagen más grandes (Nivel 6, 6.1, y 6.2), el mensaje SEI de metadatos verdes, la información de profundidad alternativa mensaje SEI, e identificadores de código VUI relacionados con el color.
• Versión 25 (edición 12): (13 de abril de 2017) Enmienda para especificar el perfil progresivo High 10, log-gamma híbrido (HLG), y puntos de código VUI relacionados con el color adicionales y mensajes SEI.
• Versión 26 (edición 13): (13 de junio de 2019) Enmienda para especificar mensajes adicionales de SEI para entorno de visualización ambiental, información de nivel de luz de contenido, volumen de color de contenido, proyección equirectangular, proyección de cubemap, rotación de esferas, envasado por región, visualización omnidireccional, manifiesto SEI y prefijo SEI.
• Versión 27 (edición 14): (22 de agosto de 2021) Enmienda para especificar los mensajes adicionales de la SEI para las regiones anotadas y la información de intervalos de obturación, y correcciones y aclaraciones menores diversas.

Titular de patentes

Las siguientes organizaciones poseen una o más patentes en el grupo de patentes H.264/AVC de MPEG LA.

Aplicaciones

El formato de video H.264 tiene una gama de aplicaciones muy amplia que cubre todas las formas de video comprimido digital, desde aplicaciones de transmisión por Internet de baja tasa de bits hasta transmisiones de HDTV y aplicaciones de cine digital con codificación casi sin pérdidas. Con el uso de H.264, se reportan ahorros de tasa de bits del 50% o más en comparación con MPEG-2 Parte 2. Por ejemplo, se ha informado que H.264 brinda la misma calidad de TV satelital digital que las implementaciones actuales de MPEG-2 con menos de la mitad de la tasa de bits, con las implementaciones actuales de MPEG-2 trabajando a alrededor de 3,5 Mbit/s y H.264 a solo 1,5. Mbit/s. Sony afirma que el modo de grabación AVC de 9 Mbit/s es equivalente a la calidad de imagen del formato HDV, que utiliza aproximadamente de 18 a 25 Mbit/s.

Para garantizar la compatibilidad y la adopción sin problemas de H.264/AVC, muchos organismos de estándares han modificado o agregado sus estándares relacionados con el video para que los usuarios de estos estándares puedan emplear H.264/AVC. Tanto el formato Blu-ray Disc como el formato HD DVD ahora descontinuado incluyen H.264/AVC High Profile como uno de los tres formatos de compresión de video obligatorios. El proyecto Digital Video Broadcast (DVB) aprobó el uso de H.264/AVC para la transmisión de televisión a finales de 2004.

El organismo de estándares del Comité de Sistemas de Televisión Avanzada (ATSC) de los Estados Unidos aprobó el uso de H.264/AVC para la transmisión de televisión en julio de 2008, aunque el estándar aún no se usa para las transmisiones ATSC fijas dentro de los Estados Unidos. También ha sido aprobado para su uso con el estándar ATSC-M/H (móvil/de mano) más reciente, utilizando las partes AVC y SVC de H.264.

Los mercados de CCTV (Circuito Cerrado de TV) y Video Vigilancia han incluido la tecnología en muchos productos.

Muchas DSLR comunes usan video H.264 envuelto en contenedores QuickTime MOV como formato de grabación nativo.

Formatos derivados

AVCHD es un formato de grabación de alta definición diseñado por Sony y Panasonic que utiliza H.264 (conforme a H.264 pero agrega características y restricciones adicionales específicas de la aplicación).

AVC-Intra es un formato de compresión solo intraframe desarrollado por Panasonic.

XAVC es un formato de grabación diseñado por Sony que utiliza el nivel 5.2 de H.264/MPEG-4 AVC, que es el nivel más alto admitido por ese estándar de video. XAVC puede admitir una resolución de 4K (4096 × 2160 y 3840 × 2160) a hasta 60 fotogramas por segundo (fps). Sony ha anunciado que las cámaras compatibles con XAVC incluyen dos cámaras CineAlta: la Sony PMW-F55 y la Sony PMW-F5. El Sony PMW-F55 puede grabar XAVC con resolución 4K a 30 fps a 300 Mbit/s y resolución 2K a 30 fps a 100 Mbit/s. XAVC puede grabar en resolución 4K a 60 fps con muestreo de croma 4:2:2 a 600 Mbit/s.

Diseño

Características

Diagrama de bloques de H.264

H.264/AVC/MPEG-4 Parte 10 contiene una serie de características nuevas que le permiten comprimir video de manera mucho más eficiente que los estándares anteriores y brindar más flexibilidad para la aplicación en una amplia variedad de entornos de red. En particular, algunas de estas características clave incluyen:

• Predicción entre imágenes múltiples incluyendo las siguientes características:
  • Usando imágenes previamente codificadas como referencias de una manera mucho más flexible que en estándares anteriores, permitiendo hasta 16 marcos de referencia (o 32 campos de referencia, en el caso de la codificación interrelacionada) para ser utilizados en algunos casos. En los perfiles que soportan los marcos no relacionados con el DIDR, la mayoría de los niveles especifican que se debe disponer de suficiente amortiguación para permitir al menos 4 o 5 marcos de referencia a la máxima resolución. Esto contrasta con los estándares anteriores, donde el límite era típicamente uno; o, en el caso de "B imágenes" convencionales (B-frames), dos.
  • Indemnización de movimiento de tamaño de bloque variable (VBSMC) con tamaños de bloque tan grande como 16×16 y tan pequeño como 4×4, permitiendo segmentación precisa de las regiones en movimiento. Los tamaños de bloques de predicción luma soportados incluyen 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, y 4×4, muchos de los cuales se pueden utilizar juntos en un solo macroblock. Los tamaños de bloques de predicción croma son correspondientemente más pequeños cuando se utiliza el subampling de croma.
  • La capacidad de utilizar múltiples vectores de movimiento por macroblock (uno o dos por partición) con un máximo de 32 en el caso de un macrobloque B construido de 16 particiones 4×4. Los vectores de movimiento para cada región de partición 8×8 o mayor pueden apuntar a diferentes imágenes de referencia.
  • La capacidad de utilizar cualquier tipo de macrobloqueo en B-frames, incluyendo I-macroblocks, resultando en una codificación mucho más eficiente al utilizar B-frames. Esta característica fue notablemente excluida de MPEG-4 ASP.
  • Filtro de seis puntas para derivación de predicciones de muestras de luma de medio-pel, para una compensación de movimiento subpixel más aguda. El movimiento trimestral de píxeles se deriva por interpolación lineal de los valores de medio píxeles, para ahorrar poder de procesamiento.
  • Precisión trimestral para la compensación de movimiento, lo que permite una descripción precisa de los desplazamientos de las zonas en movimiento. Para el croma la resolución suele reducirse verticalmente y horizontalmente (véase 4:2:0) por lo que la compensación de movimiento del croma utiliza unidades de rejilla de croma pixel de un octavo.
  • Predicción ponderada, permitiendo que un encoder especifique el uso de un escalado y compensación al realizar una compensación de movimiento, y proporcionando un beneficio significativo en el rendimiento en casos especiales, como las transiciones de fade-to-black, fade-in y cross-fade. Esto incluye la predicción ponderada implícita para los marcos B, y la predicción ponderada explícita para los marcos P.
• Predicción espacial de los bordes de bloques vecinos para codificación "intra", en lugar de la predicción "DC" sólo encontrada en MPEG-2 Parte 2 y la predicción del coeficiente de transformación encontrada en H.263v2 y MPEG-4 Parte 2. Esto incluye los tamaños de bloques de predicción de luma de 16×16, 8×8, y 4×4 (de los cuales sólo un tipo se puede utilizar dentro de cada macroblock).
• Integer discrete cosine transform (integer DCT), un tipo de discreta transformación cosina (DCT) donde la transformación es una aproximación entero del DCT estándar. Tiene tamaños de bloques seleccionables y computación de enteros de serie exacta para reducir la complejidad, incluyendo:
  • Un número exacto de integer 4×4 de bloque espacial transforman, permitiendo la colocación precisa de señales residuales con poco de la "relacha" a menudo encontrado con diseños codec previos. Es similar al estándar DCT utilizado en estándares anteriores, pero utiliza un tamaño de bloque más pequeño y un procesamiento simple entero. A diferencia de las fórmulas y tolerancias basadas en cosina expresadas en estándares anteriores (como H.261 y MPEG-2), el procesamiento de entero proporciona un resultado decodificado exactamente especificado.
  • Un entero entero de 8×8 se transforma, permitiendo que las regiones altamente correlativas sean comprimidos más eficientemente que con la transformación 4×4. Este diseño se basa en el DCT estándar, pero simplificado y hecho para proporcionar decodificación especificada exactamente.
  • Selección de encoder adaptativo entre los tamaños de bloques de transformación 4×4 y 8×8 para la operación de transformación del entero.
  • Una transformación secundaria Hadamard realizada en coeficientes "DC" de la transformación espacial primaria aplicada a los coeficientes de croma DC (y también luma en un caso especial) para obtener aún más compresión en regiones lisas.
• Características de codificación macroblock sin pérdida, incluyendo:
  • Un modo de representación sin pérdidas "PCM macroblock" en el que las muestras de datos de vídeo están representadas directamente, permitiendo una representación perfecta de regiones específicas y permitiendo un límite estricto para ser colocado en la cantidad de datos codificados para cada macroblock.
  • Un modo de representación macrobloqueo mejorado que permite una representación perfecta de regiones específicas mientras que normalmente utiliza sustancialmente menos bits que el modo PCM.
• Características de codificación de vídeo entrelazado flexibles, incluyendo:
  • Macroblock-adaptive frame-field (MBAFF) coding, utilizando una estructura de par macroblock para imágenes codificadas como marcos, permitiendo macroblocks 16×16 en modo de campo (comparados con MPEG-2, donde el procesamiento de modo de campo en una imagen que se codifica como un marco resulta en el procesamiento de 16×8 semi-macroblocks).
  • Codificación de campo foto-adaptivo (PAFF o PicAFF) permitiendo una mezcla libremente seleccionada de imágenes codificadas como marcos completos donde ambos campos se combinan para la codificación o como campos individuales individuales.
• Un diseño de cuantificación que incluye:
  • Control de tamaño de paso logarítmico para una gestión más fácil de velocidad de bits por encoders y escalado de cuantificación inversa simplificado
  • Matrices de escalada de cuarentena acostumbradas seleccionadas por el encoder para la optimización de la cuantificación basada en el perceptual
• Un filtro de desbloqueo en la plataforma que ayuda a prevenir los artefactos de bloqueo comunes a otras técnicas de compresión de imágenes basadas en DCT, resultando en una mejor apariencia visual y eficiencia de compresión
• Un diseño de codificación entropía incluyendo:
  • Codificación aritmética binaria context-adaptiva (CABAC), un algoritmo para comprimir sin pérdidas elementos de sintaxis en la secuencia de vídeo sabiendo las probabilidades de elementos de sintaxis en un contexto dado. CABAC comprime datos más eficientemente que CAVLC, pero requiere mucho más procesamiento para decodificar.
  • Codificación de longitud variable context-adaptiva (CAVLC), que es una alternativa de menor complejidad a CABAC para la codificación de los valores de coeficiente de transformación cuantificados. Aunque la complejidad es menor que la CABAC, CAVLC es más elaborada y más eficiente que los métodos utilizados normalmente para codificar coeficientes en otros diseños anteriores.
  • Una técnica común de codificación de longitud variable simple y muy estructurada (VLC) para muchos de los elementos de sintaxis no codificados por CABAC o CAVLC, denominado codificación Exponential-Golomb (o Exp-Golomb).
• Características de la resiliencia de la pérdida:
  • Una definición de Capa de Abstracción de Red (NAL) que permite utilizar la misma sintaxis de vídeo en muchos entornos de red. Un concepto de diseño muy fundamental de H.264 es generar paquetes autocontenidos, para eliminar la duplicación de encabezados como en el Código de Extensión de Header de MPEG-4 (HEC). Esto se logró decodificando información relevante a más de una rebanada de la corriente de medios. La combinación de los parámetros de alto nivel se llama conjunto de parámetro. La especificación H.264 incluye dos tipos de conjuntos de parámetros: Sequence Parameter Set (SPS) y Picture Parameter Set (PPS). Un conjunto de parámetro de secuencia activa permanece sin cambios a lo largo de una secuencia de vídeo codificada, y un conjunto de parámetro de imagen activo permanece sin cambios dentro de una imagen codificada. Las estructuras de conjunto de secuencia y parámetro de imagen contienen información como tamaño de imagen, modos opcionales de codificación empleados, y macroblock para rebanar mapa de grupo.
  • Ordenación de macrobloque flexible (FMO), también conocido como grupos de rodajas y orden de rodajas arbitrarias (ASO), que son técnicas para la reestructuración del orden de la representación de las regiones fundamentales (macrobloques) en fotos. Típicamente considerada una función de robustez de error/pérdida, FMO y ASO también pueden utilizarse para otros fines.
  • La partición de datos (DP), una característica que proporciona la capacidad de separar elementos de sintaxis más importantes y menos importantes en diferentes paquetes de datos, permitiendo la aplicación de la protección desigual de errores (UEP) y otros tipos de mejora de la robustez de error/pérdida.
  • Rebanadas de rodajas (RS), una función de robustez de error/pérdida que permite a un codificador enviar una representación adicional de una región de imagen (normalmente inferior a la fidelidad) que se puede utilizar si la representación primaria está corrompida o perdida.
  • Número de marco, una característica que permite la creación de "sub-sequences", permitiendo la escalabilidad temporal mediante la inclusión opcional de imágenes extra entre otras imágenes, y la detección y ocultación de pérdidas de imágenes enteras, que pueden ocurrir debido a pérdidas de paquetes de red o errores de canal.
• Interruptor de rodajas, llamadas rodajas SP y SI, permitiendo que un encoder dirija un decodificador para saltar en un flujo de vídeo continuo con fines tales como el cambio de velocidad de streaming de vídeo y operación de "modo de ladrillo". Cuando un decodificador salta en el centro de una secuencia de vídeo usando la función SP/SI, puede conseguir un partido exacto a las imágenes decodificadas en esa ubicación en la secuencia de vídeo a pesar de usar diferentes imágenes, o no imágenes en absoluto, como referencias antes del interruptor.
• Un simple proceso automático para prevenir la emulación accidental de códigos de inicio, que son secuencias especiales de bits en los datos codificados que permiten el acceso aleatorio en el bitstream y la recuperación de alineación byte en sistemas que pueden perder sincronización byte.
• Información complementaria de mejora (SEI) e información de usabilidad de vídeo (VUI), que son información adicional que se puede insertar en el bitstream para diversos fines, como indicar el espacio de color utilizado el contenido de vídeo o varias restricciones que se aplican a la codificación. Los mensajes de SEI pueden contener cargas de metadatos arbitrarias definidas por el usuario u otros mensajes con sintaxis y semántica definidas en la norma.
• Fotos auxiliares, que se pueden utilizar para fines tales como compositing alpha.
• Soporte de monocromo (4:0:0), 4:2:0, 4:2:2, y 4:4 muestras de croma (dependiendo del perfil seleccionado).
• Soporte de la precisión de la muestra de bits que van de 8 a 14 bits por muestra (dependiendo del perfil seleccionado).
• La capacidad de codificar planos individuales de color como imágenes distintas con sus propias estructuras de rebanada, modos macroblock, vectores de movimiento, etc., permitiendo que los encoders sean diseñados con una estructura de paralización simple (solo soportados en los tres perfiles 4:4-capaces).
• Cuenta de orden de imagen, una característica que sirve para mantener el orden de las imágenes y los valores de las muestras en las imágenes descodificadas aisladas de la información de tiempo, permitiendo que la información de tiempo se lleve y controle/cambie por separado por un sistema sin afectar el contenido de imagen descodificado.

Estas técnicas, junto con varias otras, ayudan a H.264 a funcionar significativamente mejor que cualquier estándar anterior en una amplia variedad de circunstancias en una amplia variedad de entornos de aplicación. H.264 a menudo puede funcionar radicalmente mejor que el video MPEG-2, generalmente obteniendo la misma calidad a la mitad de la tasa de bits o menos, especialmente en contenido de video de alta resolución y alta tasa de bits.

Al igual que otros estándares de video ISO/IEC MPEG, H.264/AVC tiene una implementación de software de referencia que se puede descargar libremente. Su objetivo principal es dar ejemplos de funciones H.264/AVC, en lugar de ser una aplicación útil per se. También se han realizado algunos trabajos de diseño de hardware de referencia en el Grupo de expertos en imágenes en movimiento. Los aspectos mencionados anteriormente incluyen características en todos los perfiles de H.264. Un perfil para un códec es un conjunto de características de ese códec identificado para cumplir con un determinado conjunto de especificaciones de las aplicaciones previstas. Esto significa que muchas de las funciones enumeradas no se admiten en algunos perfiles. En la siguiente sección se analizan varios perfiles de H.264/AVC.

Perfiles

El estándar define varios conjuntos de capacidades, que se conocen como perfiles, dirigidos a clases específicas de aplicaciones. Estos se declaran utilizando un código de perfil (profile_idc) y, a veces, un conjunto de restricciones adicionales aplicadas en el codificador. El código de perfil y las restricciones indicadas permiten que un decodificador reconozca los requisitos para decodificar ese flujo de bits específico. (Y en muchos entornos de sistema, solo se permite el uso de uno o dos perfiles, por lo que los decodificadores en esos entornos no necesitan preocuparse por reconocer los perfiles menos utilizados). Con diferencia, el perfil más utilizado es el perfil alto.

Los perfiles para aplicaciones de video 2D no escalables incluyen lo siguiente:

Perfil Constrained Baseline (CBP, 66 con sistema de restricción 1)

Principalmente para aplicaciones de bajo costo, este perfil se utiliza más típicamente en videoconferencias y aplicaciones móviles. Corresponde al subconjunto de características que se encuentran en común entre el Baseline, el Principal y los Altos Perfiles.

Perfil de referencia (BP, 66)

Principalmente para aplicaciones de bajo costo que requieren mayor robustez de pérdida de datos, este perfil se utiliza en algunas aplicaciones de videoconferencia y móviles. Este perfil incluye todas las características que se soportan en el Perfil Baseline Constrained, además de tres características adicionales que se pueden utilizar para la pérdida de robustez (o para otros fines, como la composición de secuencias de vídeo multipuntos de baja velocidad). La importancia de este perfil se ha desvanecido en cierta medida desde la definición del Perfil de Bases Constrained en 2009. Todos los bitstreams de Perfil de Bases Constrained también se consideran Baseline Profile bitstreams, ya que estos dos perfiles comparten el mismo valor de código identificador de perfil.

Perfil ampliado (XP, 88)

Intended as the streaming video profile, this profile has relatively high compresión capacity and some extra tricks for robustness to data losses and server streaming switching.

Perfil principal (MP, 77)

Este perfil se utiliza para las transmisiones de televisión digital de definición estándar que utilizan el formato MPEG-4 como se define en el estándar DVB. No se utiliza, sin embargo, para las emisiones de televisión de alta definición, ya que la importancia de este perfil se desvaneció cuando el Alto Perfil fue desarrollado en 2004 para esa aplicación.

Perfil alto (HiP, 100)

El perfil principal de las aplicaciones de transmisión y almacenamiento de discos, en particular para las aplicaciones de televisión de alta definición (por ejemplo, este es el perfil adoptado por el formato de almacenamiento Blu-ray Disc y el servicio de transmisión DVB HDTV).

Perfil elevado progresivo (PHiP, 100 con conjunto de restricciones 4)

Similar al perfil alto, pero sin soporte de características de codificación de campo.

Perfil elevado (100 con ajuste 4 y 5)

Similar al perfil Progresivo Alto, pero sin soporte de B (bi-predictivo) rebanadas.

Perfil alto 10 (Hi10P, 110)

Más allá de las capacidades típicas de los productos de consumo, este perfil se basa en la parte superior del perfil alto, agregando soporte para hasta 10 bits por muestra de precisión de imagen descodificada.

Alto 4:2:2 Perfil (Hi422P, 122)

Este perfil se basa principalmente en aplicaciones profesionales que utilizan vídeos interrelacionados, en la parte superior del perfil High 10, agregando soporte para el formato de muestreo 4:2:2 croma mientras utiliza hasta 10 bits por muestra de precisión de imagen descodificada.

Alto 4:4:4 Perfil predictivo (Hi444PP, 244)

Este perfil se construye en la parte superior del perfil alto 4:2:2, soportando hasta 4:4 muestras de croma, hasta 14 bits por muestra, y además apoyando la codificación eficiente de la región sin pérdidas y la codificación de cada imagen como tres planos de color separados.

Para videocámaras, edición y aplicaciones profesionales, el estándar contiene cuatro perfiles adicionales solo intracuadro, que se definen como subconjuntos simples de otros perfiles correspondientes. Estos son principalmente para aplicaciones profesionales (por ejemplo, cámara y sistema de edición):

Perfil Intra de 10 Altos (110 con conjunto de restricción 3)

El perfil alto 10 se limitó a todo uso intra.

Alto 4:2:2 Perfil de Intra (122 con ajuste de restricción 3)

El perfil alto 4:2:2 limitado a todo uso intra.

Alto 4:4:4 Perfil de Intra (244 con ajuste 3)

El perfil alto 4:4:4 limita a todo uso intra.

CAVLC 4:4:4 Perfil intra (44)

El perfil alto 4:4:4 limita a todo uso intra y a la codificación entropía CAVLC (es decir, no apoyando CABAC).

Como resultado de la extensión Scalable Video Coding (SVC), el estándar contiene cinco perfiles escalables adicionales, que se definen como una combinación de un perfil H.264/AVC para la capa base (identificado por la segunda palabra en el nombre del perfil escalable) y herramientas que logran la extensión escalable:

Perfil básico escalable (83)

Este perfil se basa principalmente en aplicaciones de videoconferencia, móvil y vigilancia, en la parte superior del perfil Baseline Constrained al que debe conformarse la capa base (un subconjunto del bitstream). Para las herramientas de escalabilidad, se habilita un subconjunto de las herramientas disponibles.

Perfil de Base de referencia constreñido escalable (83 con conjunto de restricciones 5)

Un subconjunto del perfil de referencia escalable destinado principalmente a aplicaciones de comunicación en tiempo real.

Perfil elevado escalable (86)

Principalmente dirigida a aplicaciones de transmisión y streaming, este perfil se basa en la parte superior del H.264/AVC High Profile al que debe conformarse la capa base.

Scalable Constrained High Profile (86 con el set de restricción 5)

Un subconjunto del alto perfil escalable destinado principalmente a aplicaciones de comunicación en tiempo real.

Perfil de Intra High escalable (86 con conjunto de restricción 3)

Este perfil se centra principalmente en aplicaciones de producción, siendo el perfil alto escalable limitado a todo uso intra.

Como resultado de la extensión Multiview Video Coding (MVC), el estándar contiene dos perfiles multivista:

Stereo High Profile (128)

Este perfil se centra en el vídeo 3D estereoscópico de dos vistas y combina las herramientas del perfil alto con las capacidades de predicción intervisual de la extensión MVC.

Multiview High Profile (118)

Este perfil soporta dos o más puntos de vista usando tanto la predicción inter-picture (temporal) como la predicción inter-view MVC, pero no admite imágenes de campo y codificación macroblock-adaptive frame-field.

La extensión Multi-solution Frame-Compatible (MFC) agregó dos perfiles más:

MFC High Profile (134)

Perfil para codificación estereoscópica con mejora de resolución de dos capas.

MFC Depth High Profile (135)

La extensión 3D-AVC agregó dos perfiles más:

Multiview Depth High Profile (138)

Este perfil soporta la codificación conjunta de mapa de profundidad y la información de textura de vídeo para una mejor compresión de contenido de vídeo 3D.

Multiview Depth High Profile (139)

Un perfil mejorado para la codificación multivista combinada con información de profundidad.

Soporte de características en perfiles particulares

Niveles

Como se usa el término en el estándar, un "nivel" es un conjunto específico de restricciones que indican un grado de desempeño del decodificador requerido para un perfil. Por ejemplo, un nivel de compatibilidad dentro de un perfil especifica la resolución de imagen, la velocidad de fotogramas y la velocidad de bits máximas que puede utilizar un decodificador. Un decodificador que se ajuste a un nivel dado debe poder decodificar todos los flujos de bits codificados para ese nivel y todos los niveles inferiores.

La tasa de bits máxima para el perfil alto es 1,25 veces mayor que la de los perfiles básico, básico, extendido y principal limitados; 3 veces para Hi10P y 4 veces para Hi422P/Hi444PP.

La cantidad de muestras luma es 16 × 16 = 256 veces la cantidad de macrobloques (y la cantidad de muestras luma por segundo es 256 veces la cantidad de macrobloques por segundo).

Búfer de imagen decodificada

Los codificadores H.264/AVC utilizan las imágenes codificadas anteriormente para proporcionar predicciones de los valores de las muestras en otras imágenes. Esto permite que el codificador tome decisiones eficientes sobre la mejor manera de codificar una imagen dada. En el decodificador, dichas imágenes se almacenan en una memoria intermedia de imágenes decodificadas (DPB) virtual. La capacidad máxima de la DPB, en unidades de marcos (o pares de campos), como se muestra entre paréntesis en la columna derecha de la tabla anterior, se puede calcular de la siguiente manera:

DpbCapacidad = min(flor)MaxDpbMbs /PicWidthInMbs * FrameHeightInMbs)), 16)

Donde MaxDpbMbs es un valor constante proporcionado en la siguiente tabla en función del número de nivel, y PicWidthInMbs y FrameHeightInMbs son el ancho de la imagen y la altura del marco para los datos de video codificados, expresados en unidades de macrobloques (redondeado a valores enteros y teniendo en cuenta el recorte y el emparejamiento de macrobloques cuando corresponda). Esta fórmula se especifica en los apartados A.3.1.h y A.3.2.f de la edición de 2017 de la norma.

Por ejemplo, para una imagen HDTV de 1920 muestras de ancho (PicWidthInMbs = 120) y 1080 muestras de alto (FrameHeightInMbs = 68), un decodificador de nivel 4 tiene una capacidad máxima de almacenamiento DPB de piso(32768/(120*68)) = 4 marcos (u 8 campos). Por lo tanto, el valor 4 se muestra entre paréntesis en la tabla anterior en la columna derecha de la fila para el Nivel 4 con el tamaño de marco 1920×1080.

Es importante tener en cuenta que la imagen actual que se está decodificando no se incluye en el cálculo de la plenitud de DPB (a menos que el codificador haya indicado que se almacene para su uso como referencia para decodificar otras imágenes). o para temporización de salida retardada). Por lo tanto, un decodificador debe tener suficiente memoria para manejar (al menos) un cuadro más que la capacidad máxima del DPB calculada anteriormente.

Implementaciones

Estadísticas de vídeo de YouTube con AVC (H.264) codec de vídeo y formato de audio de Opus

En 2009, el grupo de trabajo de HTML5 se dividió entre los partidarios de Ogg Theora, un formato de video gratuito que se considera libre de patentes, y H.264, que contiene tecnología patentada. Todavía en julio de 2009, se decía que Google y Apple admitían H.264, mientras que Mozilla y Opera admiten Ogg Theora (ahora Google, Mozilla y Opera admiten Theora y WebM con VP8). Microsoft, con el lanzamiento de Internet Explorer 9, agregó soporte para video HTML 5 codificado usando H.264. En el Gartner Symposium/ITXpo de noviembre de 2010, el director ejecutivo de Microsoft, Steve Ballmer, respondió a la pregunta "¿HTML 5 o Silverlight?" diciendo "Si quieres hacer algo que sea universal, no hay duda de que el mundo se está volviendo HTML5." En enero de 2011, Google anunció que retiraría la compatibilidad con H.264 de su navegador Chrome y admitiría tanto Theora como WebM/VP8 para usar solo formatos abiertos.

El 18 de marzo de 2012, Mozilla anunció la compatibilidad con H.264 en Firefox en dispositivos móviles, debido a la prevalencia del video codificado en H.264 y la mayor eficiencia energética del uso de hardware decodificador H.264 dedicado común en dichos dispositivos.. El 20 de febrero de 2013, Mozilla implementó compatibilidad en Firefox para decodificar H.264 en Windows 7 y superior. Esta función se basa en Windows' bibliotecas de decodificación integradas. Firefox 35.0, lanzado el 13 de enero de 2015, es compatible con H.264 en OS X 10.6 y superior.

El 30 de octubre de 2013, Rowan Trollope de Cisco Systems anunció que Cisco lanzaría los archivos binarios y el código fuente de un códec de video H.264 llamado OpenH264 bajo la licencia BSD simplificada y pagaría todas las regalías por su uso a MPEG LA para cualquier proyecto de software que use los binarios precompilados de Cisco, lo que hace que los binarios OpenH264 de Cisco sean de uso gratuito. Sin embargo, cualquier proyecto de software que use el código fuente de Cisco en lugar de sus archivos binarios sería legalmente responsable de pagar todas las regalías a MPEG LA. Las arquitecturas de CPU de destino incluyen x86 y ARM, y los sistemas operativos de destino incluyen Linux, Windows XP y versiones posteriores, Mac OS X y Android; iOS estuvo notablemente ausente de esta lista, porque no permite que las aplicaciones obtengan e instalen módulos binarios de Internet. También el 30 de octubre de 2013, Brendan Eich de Mozilla escribió que usaría los binarios de Cisco en futuras versiones de Firefox para agregar soporte para H.264 a Firefox donde los códecs de la plataforma no están disponibles. Cisco publicó el código fuente de OpenH264 el 9 de diciembre de 2013.

Aunque iOS no era compatible con la versión de software de Cisco de 2013, Apple actualizó Video Toolbox Framework con iOS 8 (lanzado en septiembre de 2014) para brindar acceso directo a la codificación y decodificación de video H.264/AVC basada en hardware.

Codificadores de software

Hardware

Debido a que la codificación y decodificación H.264 requiere una potencia informática significativa en tipos específicos de operaciones aritméticas, las implementaciones de software que se ejecutan en CPU de uso general suelen ser menos eficientes en el consumo de energía. Sin embargo, las últimas CPU x86 de uso general de cuatro núcleos tienen suficiente potencia de cálculo para realizar la codificación SD y HD en tiempo real. La eficiencia de la compresión depende de las implementaciones algorítmicas de video, no de si se utiliza una implementación de hardware o software. Por lo tanto, la diferencia entre la implementación basada en hardware y software radica más en la eficiencia energética, la flexibilidad y el costo. Para mejorar la eficiencia energética y reducir el factor de forma del hardware, se puede emplear hardware de propósito especial, ya sea para el proceso completo de codificación o decodificación, o para asistencia de aceleración dentro de un entorno controlado por CPU.

Se sabe que las soluciones basadas en CPU son mucho más flexibles, especialmente cuando la codificación se debe realizar simultáneamente en múltiples formatos, múltiples velocidades de bits y resoluciones (video de múltiples pantallas), y posiblemente con funciones adicionales en soporte de formato de contenedor, publicidad integrada avanzada características, etc. La solución de software basada en CPU generalmente hace que sea mucho más fácil equilibrar la carga de múltiples sesiones de codificación simultáneas dentro de la misma CPU.

La segunda generación de Intel "Sandy Bridge" Los procesadores Core i3/i5/i7 presentados en el CES (Consumer Electronics Show) de enero de 2011 ofrecen un codificador H.264 Full HD de hardware en el chip, conocido como Intel Quick Sync Video.

Un codificador de hardware H.264 puede ser un ASIC o un FPGA.

Los codificadores ASIC con funcionalidad de codificador H.264 están disponibles en muchas empresas de semiconductores diferentes, pero el diseño central que se utiliza en el ASIC suele tener la licencia de una de unas pocas empresas, como Chips&Media, Allegro DVT, On2 (anteriormente Hantro, adquirida por Google), Imagination Technologies, NGCodec. Algunas empresas tienen ofertas de productos FPGA y ASIC.

Texas Instruments fabrica una línea de núcleos ARM + DSP que realizan la codificación DSP H.264 BP 1080p a 30 fps. Esto permite flexibilidad con respecto a los códecs (que se implementan como código DSP altamente optimizado) y, al mismo tiempo, es más eficiente que el software en una CPU genérica.

Licencias

En países donde las patentes de algoritmos de software son válidas, se espera que los proveedores y usuarios comerciales de productos que usan H.264/AVC paguen regalías de licencia de patente por la tecnología patentada que usan sus productos. Esto también se aplica al perfil de referencia.

Una organización privada conocida como MPEG LA, que no está afiliada de ninguna manera con la organización de estandarización de MPEG, administra las licencias de patentes que se aplican a este estándar, así como otros grupos de patentes, como MPEG-4 Part 2 Video., HEVC y MPEG-DASH. Los titulares de patentes incluyen Fujitsu, Panasonic, Sony, Mitsubishi, Apple, Columbia University, KAIST, Dolby, Google, JVC Kenwood, LG Electronics, Microsoft, NTT Docomo, Philips, Samsung, Sharp, Toshiba y ZTE, aunque la mayoría de las patentes en el grupo está en manos de Panasonic (1197 patentes), Godo Kaisha IP Bridge (1130 patentes) y LG Electronics (990 patentes).

El 26 de agosto de 2010, MPEG LA anunció que no se cobrarán regalías por los videos de Internet codificados en H.264 que son gratuitos para los usuarios finales. Todas las demás regalías permanecen vigentes, como las regalías por productos que decodifican y codifican video H.264, así como a operadores de televisión gratuita y canales de suscripción. Los términos de la licencia se actualizan en bloques de 5 años.

Desde que se completó la primera versión del estándar en mayo de 2003 (hace 20 años) y el perfil más utilizado (el perfil alto) se completó en junio de 2004 (hace 18–19 años), varias de las patentes relevantes que se aplican al estándar vencen cada año, aunque una de las patentes estadounidenses en el grupo MPEG LA H.264 dura al menos hasta noviembre de 2030.

En 2005, Qualcomm demandó a Broadcom en el Tribunal de Distrito de EE. UU., alegando que Broadcom infringió dos de sus patentes al fabricar productos que cumplían con el estándar de compresión de video H.264. En 2007, el Tribunal de Distrito determinó que las patentes eran inaplicables porque Qualcomm no las había revelado a JVT antes del lanzamiento del estándar H.264 en mayo de 2003. En diciembre de 2008, el Tribunal de Apelaciones del Circuito Federal de EE. UU. afirmó la orden del Tribunal de Distrito de que las patentes sean inaplicables, pero se devolvió al Tribunal de Distrito con instrucciones para limitar el alcance de la inaplicabilidad a los productos que cumplen con H.264.