El estándar más utilizado para la compresión de vídeo
Advanced Video Coding ( AVC ), también conocido como H.264 o MPEG-4 Parte 10 , es un estándar de compresión de video basado en codificación orientada a bloques y con compensación de movimiento . [2] Es, por lejos, 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 septiembre de 2019. [actualizar][ 3] [4] Admite una resolución máxima de 8K UHD . [5] [6]
El objetivo del proyecto H.264/AVC era crear un estándar capaz de proporcionar una buena calidad de vídeo a velocidades de bits sustancialmente inferiores a las de los estándares anteriores (es decir, la mitad o menos de la velocidad de bits de MPEG-2 , H.263 o MPEG-4 Parte 2 ), sin aumentar tanto la complejidad del diseño que resultara poco práctico o excesivamente caro de implementar. Esto se logró con características como una transformada discreta de coseno entero de complejidad reducida (DCT entera), [7] 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 velocidades de bits bajas y altas, vídeo de baja y alta resolución, difusión , almacenamiento en DVD , redes de paquetes RTP / IP y sistemas de telefonía multimedia ITU-T . El estándar H.264 puede considerarse una "familia de estándares" compuesta por varios 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 algoritmos para codificar video; eso se deja abierto para que los diseñadores de codificadores lo seleccionen por sí mismos, y se ha desarrollado una amplia variedad de esquemas de codificación. H.264 se usa típicamente para compresión con pérdida , aunque también es posible crear regiones codificadas verdaderamente sin pérdida dentro de imágenes codificadas con pérdida o para admitir casos de uso poco frecuentes para los que toda la codificación es sin pérdida.
El estándar H.264 fue estandarizado por el Grupo de Expertos en Codificación de Vídeo (VCEG) de la Comisión de Estudio 16 de la UIT-T junto con el Grupo de Expertos en Imágenes en Movimiento (MPEG) del JTC 1 de la ISO/IEC . El esfuerzo conjunto del proyecto se conoce como Equipo de Vídeo Conjunto (JVT). El estándar H.264 de la UIT-T y el estándar MPEG-4 AVC de la ISO/IEC (formalmente, ISO/IEC 14496-10 – MPEG-4 Parte 10, Codificación de Vídeo Avanzada) se mantienen de manera conjunta, de modo que tienen un contenido técnico idéntico. El trabajo de redacción final de la primera versión del estándar se completó en mayo de 2003, y se han añadido varias ampliaciones de sus capacidades en ediciones posteriores. La Codificación de Vídeo de Alta Eficiencia (HEVC), también conocida como H.265 y MPEG-H Parte 2, es un sucesor del H.264/MPEG-4 AVC desarrollado por las mismas organizaciones, mientras que los estándares anteriores todavía se utilizan de forma común.
H.264 está restringido por patentes propiedad de varias partes. Una licencia que cubre la mayoría (pero no todas [ cita requerida ] ) de las patentes esenciales para H.264 es administrada por un fondo de patentes anteriormente administrado por MPEG LA . Via Licensing Corp adquirió MPEG LA en abril de 2023 y formó una nueva empresa de administración de fondos de patentes llamada Via Licensing Alliance . [8] El uso comercial de tecnologías H.264 patentadas requiere el pago de regalías a Via 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 pagó regalías a MPEG LA en nombre de los usuarios de binarios para su codificador H.264 de código abierto openH264 .
Nombramiento
El nombre H.264 sigue la convención de nomenclatura de la UIT-T , donde a las Recomendaciones se les asigna una letra correspondiente a su serie y un número de recomendación dentro de la serie. H.264 es parte de las "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 vídeo en movimiento". [9] 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 conocidos como MPEG-4. El estándar fue desarrollado conjuntamente en una asociación de VCEG y MPEG, después del trabajo de desarrollo anterior en la UIT-T como un proyecto VCEG llamado H.26L. Por ello, es habitual 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 denominación múltiple no es poco común. Por ejemplo, el estándar de compresión de video conocido como MPEG-2 también surgió de la asociación entre MPEG y la UIT-T, donde el video MPEG-2 es conocido por la comunidad de la UIT-T como H.262. [10] ) Algunos programas de software (como el reproductor multimedia VLC ) identifican internamente este estándar como AVC1.
Historia
Historia general
A principios de 1998, el Grupo de expertos en codificación de vídeo (VCEG – ITU-T SG16 Q.6) publicó una convocatoria de propuestas para un proyecto denominado H.26L, cuyo objetivo era duplicar la eficiencia de codificación (lo que significa reducir a la mitad la tasa de bits necesaria para un determinado nivel de fidelidad) en comparación con cualquier otro estándar de codificación de vídeo existente para una amplia variedad de aplicaciones. El VCEG estaba 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 ( Heinrich Hertz Institute , Alemania) se convirtió en copresidente del VCEG.
En diciembre de 2001, VCEG y el Moving Picture Experts Group ( 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. [11] La aprobación formal de la especificación llegó en marzo de 2003. El JVT fue (es) presidido por Gary Sullivan , Thomas Wiegand y Ajay Luthra ( Motorola , EE. UU.: más tarde 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 Codificación de Video Escalable (SVC). El equipo de gestión del JVT fue ampliado por Jens-Rainer Ohm ( RWTH Aachen University , Alemania). Desde julio de 2006 hasta noviembre de 2009, el JVT trabajó en la codificación de vídeo multivista (MVC), una extensión de H.264/AVC orientada a la televisión en 3D y la televisión de punto de vista libre de alcance limitado . Ese trabajo incluyó el desarrollo de dos nuevos perfiles del estándar: el perfil alto multivista y el perfil alto estéreo.
A lo largo del desarrollo de la norma, se han desarrollado mensajes adicionales para contener información de mejora complementaria (SEI). Los mensajes SEI pueden contener varios tipos de datos que indican la sincronización de las imágenes de vídeo o describen varias propiedades del vídeo codificado o cómo se puede utilizar o mejorar. También se definen mensajes SEI que pueden contener datos arbitrarios definidos por el usuario. Los mensajes SEI no afectan al proceso de decodificación central, pero pueden indicar cómo se recomienda posprocesar o visualizar el vídeo. Algunas otras propiedades de alto nivel del contenido de vídeo se transmiten en la información de usabilidad del vídeo (VUI), como la indicación del espacio de color para la interpretación del contenido de vídeo. A medida que se han desarrollado nuevos espacios de color, como para vídeo de alto rango dinámico y amplia gama de colores , se han añadido identificadores VUI adicionales para indicarlos.
Ampliaciones de gama Fidelity 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 ampliar el estándar original, el JVT desarrolló lo que se denominó Fidelity Range Extensions (FRExt). Estas extensiones permitieron una codificación de vídeo 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′C B C R 4:2:2 (también conocidas como YUV 4:2:2 ) y 4:4:4. También se incluyeron otras características en el proyecto FRExt, como la adición de una transformada discreta de coseno entero de 8×8 (DCT entera) con conmutación adaptativa entre las transformadas 4×4 y 8×8, matrices de ponderación de cuantificación basadas en la percepción especificadas por el codificador, codificación eficiente sin pérdida entre imágenes y compatibilidad con espacios de color adicionales. El trabajo de diseño del proyecto FRExt finalizó en julio de 2004, y el trabajo de redacción del mismo finalizó en septiembre de 2004.
Luego se desarrollaron otros cinco perfiles nuevos (ver la versión 7 a continuación) destinados principalmente a aplicaciones profesionales, agregando soporte para espacio de color de gama extendida, definiendo indicadores de relación de aspecto adicionales, definiendo dos tipos adicionales de "información de mejora suplementaria" (pista posterior al filtro y mapeo de tonos) y desaprobando uno de los perfiles FRExt anteriores (el perfil High 4:4:4) que los comentarios de la industria [ ¿por quién? ] indicaron que debería haber sido diseñado de manera diferente.
Codificación de vídeo escalable
La siguiente característica importante añadida al estándar fue la codificación de vídeo escalable (SVC). Especificada en el Anexo G de H.264/AVC, la SVC permite la construcción de flujos de bits que contienen capas de subflujos de bits que también cumplen con el estándar, incluido uno de esos flujos de bits conocido como la "capa base" que puede ser decodificada por un códec H.264/AVC que no admita SVC. Para la escalabilidad temporal del flujo de bits (es decir, la presencia de un subflujo de bits con una frecuencia de muestreo temporal menor que el flujo de bits principal), las unidades de acceso completas se eliminan del flujo de bits al derivar el subflujo de bits. En este caso, la sintaxis de alto nivel y las imágenes de referencia de interpredicción en el flujo de bits se construyen en consecuencia. Por otro lado, para la escalabilidad espacial y de calidad del flujo de bits (es decir, la presencia de un subflujo de bits con una resolución/calidad espacial menor que el flujo de bits principal), la NAL ( capa de abstracción de red ) se elimina del flujo de bits al derivar el subflujo de bits. En este caso, la predicción entre capas (es decir, la predicción de la señal de mayor resolución/calidad espacial a partir de los datos de la señal de menor resolución/calidad espacial) se utiliza normalmente para lograr una codificación eficiente. Las extensiones de codificación de vídeo escalable se completaron en noviembre de 2007.
Codificación de vídeo multivista
La siguiente característica importante que se agregó al estándar fue la codificación de video multivista (MVC). Especificada en el Anexo H de H.264/AVC, la MVC permite la construcción de secuencias 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 codificación de video multivista se completaron en noviembre de 2009.
Codificación estereoscópica 3D-AVC y MFC
Posteriormente se desarrollaron extensiones adicionales que incluyeron codificación de video 3D con codificación conjunta de mapas de profundidad y textura (denominada 3D-AVC), codificación estereoscópica compatible con cuadros de múltiples resoluciones (MFC) y 3D-MFC, varias combinaciones adicionales de características y tamaños de cuadros y velocidades de cuadros más elevados.
Versiones
Las versiones de la norma 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 la "Norma Internacional" en ISO/IEC son algo diferentes y ligeramente posteriores en la mayoría de los casos). Cada versión representa cambios relativos a la versión inmediatamente 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 que contiene perfiles base, principal y extendido. [12]
Versión 2 (Edición 1.1): (7 de mayo de 2004) Corrigendum que contiene varias correcciones menores. [13]
Versión 3 (Edición 2): (1 de marzo de 2005) Adición importante que contiene la primera enmienda, estableciendo las Extensiones de rango de fidelidad (FRExt). Esta versión agregó los perfiles Alto, Alto 10, Alto 4:2:2 y Alto 4:4:4. [14] Después de algunos años, el perfil Alto se convirtió en el perfil más comúnmente utilizado del estándar.
Versión 4 (Edición 2.1): (13 de septiembre de 2005) Corrigendum que contiene varias correcciones menores y agrega tres indicadores de relación de aspecto. [15]
Versión 5 (Edición 2.2): (13 de junio de 2006) Enmienda consistente en la eliminación del perfil High 4:4:4 anterior (procesado como una corrección en ISO/IEC). [16]
Versión 6 (Edición 2.2): (13 de junio de 2006) Enmienda que consiste en extensiones menores como soporte de espacio de color de gama extendida (incluido con los indicadores de relación de aspecto mencionados anteriormente en ISO/IEC). [16]
Versión 7 (Edición 2.3): (6 de abril de 2007) Enmienda que contiene la adición del perfil predictivo High 4:4:4 y cuatro perfiles solo intra (High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra y CAVLC 4:4:4 Intra). [17]
Versión 8 (Edición 3): (22 de noviembre de 2007) Adición importante a H.264/AVC que contiene la modificación para la codificación de video escalable (SVC) que contiene los perfiles escalable de línea base, escalable alto y escalable alto intra. [18]
Versión 9 (Edición 3.1): (13 de enero de 2009) Corrigendum que contiene correcciones menores. [19]
Versión 10 (Edición 4): (16 de marzo de 2009) Enmienda que contiene la definición de un nuevo perfil (el perfil de línea base restringida) con solo el subconjunto común de capacidades admitidas en varios perfiles especificados previamente. [20]
Versión 11 (Edición 4): (16 de marzo de 2009) Adición importante a H.264/AVC que contiene la modificación para la extensión de codificación de video multivista (MVC), incluido el perfil alto multivista. [20]
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 codificación de video de dos vistas con soporte de herramientas de codificación entrelazada y que especifica un mensaje de información de mejora suplementaria (SEI) adicional denominado mensaje SEI de disposición de empaquetamiento de cuadros. [21]
Versión 13 (Edición 5): (9 de marzo de 2010) Corrigendum que contiene correcciones menores. [21]
Versión 14 (Edición 6): (29 de junio de 2011) Enmienda que especifica un nuevo nivel (Nivel 5.2) que admite tasas de procesamiento más altas en términos de máximos de macrobloques por segundo, y un nuevo perfil (el perfil Progresivo Alto) que admite únicamente las herramientas de codificación de cuadros del perfil Alto especificado anteriormente. [22]
Versión 15 (Edición 6): (29 de junio de 2011) Corrigendum que contiene correcciones menores. [22]
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: los perfiles Constrained High, Scalable Constrained Baseline y Scalable Constrained High. [23]
Versión 17 (Edición 8): (13 de abril de 2013) Enmienda con indicadores de mensajes SEI adicionales. [24]
Versión 18 (Edición 8): (13 de abril de 2013) Enmienda para especificar la codificación de datos de mapas de profundidad para video estereoscópico 3D, incluido un perfil de profundidad alta de múltiples vistas. [24]
Versión 19 (Edición 8): (13 de abril de 2013) Corrección de errores en el proceso de extracción de subflujo de bits para video de múltiples vistas. [24]
Versión 20 (Edición 8): (13 de abril de 2013) Enmienda para especificar identificadores de espacio de color adicionales (incluido el soporte de la Recomendación ITU-R BT.2020 para UHDTV ) y un tipo de modelo adicional en el mensaje SEI de información de mapeo de tonos. [24]
Versión 21 (Edición 9): (13 de febrero de 2014) Enmienda para especificar el perfil alto de profundidad de vista múltiple mejorada. [25]
Versión 22 (Edición 9): (13 de febrero de 2014) Enmienda para especificar la mejora de compatibilidad de cuadros multiresolución (MFC) para video estereoscópico 3D, el perfil alto MFC y correcciones menores. [25]
Versión 23 (Edición 10): (13 de febrero de 2016) Enmienda para especificar el video estereoscópico MFC con mapas de profundidad, el perfil MFC Depth High, el mensaje SEI de volumen de color de pantalla de masterización e identificadores de puntos de código VUI adicionales relacionados con el color. [26]
Versión 24 (Edición 11): (14 de octubre de 2016) Enmienda para especificar niveles adicionales de capacidad del decodificador que admiten tamaños de imagen más grandes (niveles 6, 6.1 y 6.2), el mensaje SEI de metadatos verdes, el mensaje SEI de información de profundidad alternativa e identificadores de puntos de código VUI adicionales relacionados con el color. [27]
Versión 25 (Edición 12): (13 de abril de 2017) Enmienda para especificar el perfil Progressive High 10, log-gamma híbrido (HLG) y puntos de código VUI relacionados con el color adicionales y mensajes SEI. [28]
Versión 26 (edición 13): (13 de junio de 2019) Enmienda para especificar mensajes SEI adicionales para el entorno de visualización ambiental, información del nivel de luz del contenido, volumen de color del contenido, proyección equirectangular, proyección de mapa de cubos, rotación de esfera, empaquetamiento por región, ventana gráfica omnidireccional, manifiesto SEI y prefijo SEI. [29]
Versión 27 (Edición 14): (22 de agosto de 2021) Enmienda para especificar mensajes SEI adicionales para regiones anotadas e información del intervalo de obturación, y correcciones y aclaraciones menores diversas. [30]
El formato de vídeo H.264 tiene un rango de aplicación muy amplio que cubre todas las formas de vídeo comprimido digital, desde aplicaciones de transmisión por Internet de baja tasa de bits hasta aplicaciones de transmisión de HDTV y cine digital con codificación casi sin pérdidas. Con el uso de H.264, se han reportado ahorros de tasa de bits del 50% o más en comparación con MPEG-2 Parte 2. Por ejemplo, se ha reportado 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. [33] 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 18–25 Mbit/s. [34]
Para garantizar la compatibilidad y la adopción sin problemas de H.264/AVC, muchos organismos de normalización han modificado o añadido a sus normas relacionadas con el vídeo para que los usuarios de dichas normas puedan utilizar H.264/AVC. Tanto el formato Blu-ray Disc como el formato HD DVD , que ya no se fabrica, incluyen el formato H.264/AVC High Profile como uno de los tres formatos obligatorios de compresión de vídeo. El proyecto Digital Video Broadcast ( DVB ) aprobó el uso de H.264/AVC para la televisión abierta a finales de 2004.
El organismo de normalización del Comité de Sistemas de Televisión Avanzada (ATSC) de los Estados Unidos aprobó el uso de H.264/AVC para la televisión abierta en julio de 2008, aunque el estándar aún no se utiliza para transmisiones ATSC fijas en los Estados Unidos. [35] [36] También se ha aprobado para su uso con el estándar más reciente ATSC-M/H (Mobile/Handheld), que utiliza las partes AVC y SVC de H.264. [37]
Muchas DSLR comunes utilizan vídeo 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 agregando características y restricciones adicionales específicas de la aplicación).
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 compatible con ese estándar de vídeo. [38] [39] XAVC puede soportar una resolución de 4K (4096 × 2160 y 3840 × 2160) a hasta 60 cuadros por segundo (fps). [38] [39] Sony ha anunciado que las cámaras que admiten XAVC incluyen dos cámaras CineAlta : la Sony PMW-F55 y la Sony PMW-F5. [40] La Sony PMW-F55 puede grabar XAVC con una resolución de 4K a 30 fps a 300 Mbit/s y una resolución de 2K a 30 fps a 100 Mbit/s. [41] XAVC puede grabar una resolución de 4K a 60 fps con muestreo de croma 4:2:2 a 600 Mbit/s. [42] [43]
Diseño
Características
H.264/AVC/MPEG-4 Parte 10 contiene una serie de nuevas características que permiten comprimir vídeo de forma mucho más eficaz que los estándares anteriores y ofrecer más flexibilidad para su aplicación en una amplia variedad de entornos de red. En particular, algunas de estas características clave son:
Utilizar imágenes previamente codificadas como referencias de una forma mucho más flexible que en los estándares anteriores, lo que permite utilizar hasta 16 cuadros de referencia (o 32 campos de referencia, en el caso de la codificación entrelazada) en algunos casos. En los perfiles que admiten cuadros que no son IDR , la mayoría de los niveles especifican que debe haber suficiente almacenamiento en búfer para permitir al menos 4 o 5 cuadros de referencia a la resolución máxima. Esto contrasta con los estándares anteriores, donde el límite era típicamente uno; o, en el caso de las " imágenes B " convencionales (cuadros B), dos.
Compensación de movimiento de tamaño de bloque variable (VBSMC) con tamaños de bloque tan grandes como 16×16 y tan pequeños como 4×4, lo que permite una segmentación precisa de las regiones en movimiento. Los tamaños de bloque de predicción de luminancia admitidos incluyen 16×16, 16×8, 8×16, 8×8, 8×4, 4×8 y 4×4, muchos de los cuales se pueden usar juntos en un solo macrobloque. Los tamaños de bloque de predicción de croma son correspondientemente más pequeños cuando se utiliza el submuestreo de croma .
La capacidad de utilizar múltiples vectores de movimiento por macrobloque (uno o dos por partición) con un máximo de 32 en el caso de un macrobloque B construido con 16 particiones de 4×4. Los vectores de movimiento para cada región de partición de 8×8 o mayor pueden apuntar a diferentes imágenes de referencia.
La capacidad de utilizar cualquier tipo de macrobloque en fotogramas B , incluidos los macrobloques I, lo que da como resultado una codificación mucho más eficiente cuando se utilizan fotogramas B. Esta característica fue notablemente excluida del formato MPEG-4 ASP .
Filtrado de seis toques para la derivación de predicciones de muestras de luminancia de medio píxel, para una compensación de movimiento de subpíxeles más nítida. El movimiento de un cuarto de píxel se deriva mediante interpolación lineal de los valores de medio píxel, para ahorrar potencia de procesamiento.
Precisión de un cuarto de píxel para la compensación de movimiento, lo que permite una descripción precisa de los desplazamientos de las áreas en movimiento. Para el croma, la resolución se suele reducir a la mitad tanto vertical como horizontalmente (consulte 4:2:0 ), por lo que la compensación de movimiento del croma utiliza unidades de cuadrícula de un octavo de píxel de croma.
Predicción ponderada, que permite que un codificador especifique el uso de una escala y un desplazamiento al realizar una compensación de movimiento, y proporciona un beneficio significativo en el rendimiento en casos especiales, como transiciones de fundido a negro, fundido de entrada y fundido cruzado. Esto incluye predicción ponderada implícita para fotogramas B y predicción ponderada explícita para fotogramas P.
Predicción espacial a partir de los bordes de bloques vecinos para codificación "intra" , en lugar de la predicción "DC" únicamente que se encuentra en MPEG-2 Parte 2 y la predicción del coeficiente de transformación que se encuentra en H.263v2 y MPEG-4 Parte 2. Esto incluye tamaños de bloque de predicción de luminancia de 16×16, 8×8 y 4×4 (de los cuales solo se puede usar un tipo dentro de cada macrobloque ).
Transformada discreta del coseno de enteros (DCT de enteros), [6] [44] [45] un tipo de transformada discreta del coseno (DCT) [44] donde la transformada es una aproximación entera de la DCT estándar. [46] Tiene tamaños de bloque seleccionables [7] y cálculo de enteros de coincidencia exacta para reducir la complejidad, incluyendo:
Una transformación de bloque espacial de 4×4 enteros con coincidencia exacta, que permite la colocación precisa de señales residuales con poco de la " oscilación " que se encuentra a menudo en los diseños de códecs anteriores. Es similar a la DCT estándar utilizada en estándares anteriores, pero utiliza un tamaño de bloque más pequeño y un procesamiento de enteros simple. A diferencia de las fórmulas y tolerancias basadas en coseno expresadas en estándares anteriores (como H.261 y MPEG-2), el procesamiento de enteros proporciona un resultado decodificado especificado exactamente.
Una transformación de bloques espaciales de 8×8 enteros con coincidencia exacta que permite comprimir regiones altamente correlacionadas de manera más eficiente que con la transformación 4×4. Este diseño se basa en la DCT estándar, pero se ha simplificado y diseñado para proporcionar una decodificación especificada con exactitud.
Selección de codificador adaptativo entre los tamaños de bloque de transformación 4×4 y 8×8 para la operación de transformación de enteros.
Una transformada de Hadamard secundaria realizada sobre los coeficientes "DC" de la transformada espacial primaria aplicada a los coeficientes DC de croma (y también de luminancia en un caso especial) para obtener aún más compresión en regiones suaves.
Un modo de representación de "macrobloque PCM" sin pérdidas en el que las muestras de datos de vídeo se representan directamente, [47] lo que permite una representación perfecta de regiones específicas y permite establecer un límite estricto en la cantidad de datos codificados para cada macrobloque.
Un modo de representación de macrobloques sin pérdida mejorado que permite una representación perfecta de regiones específicas mientras que normalmente utiliza sustancialmente menos bits que el modo PCM.
Codificación de cuadro-campo adaptativo a macrobloques (MBAFF), que utiliza una estructura de pares de macrobloques para imágenes codificadas como cuadros, lo que permite macrobloques de 16×16 en modo de campo (en comparación con MPEG-2, donde el procesamiento en modo de campo en una imagen codificada como cuadro da como resultado el procesamiento de medios macrobloques de 16×8).
Codificación de campo-marco adaptativa a imágenes (PAFF o PicAFF) que permite 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 sencilla de la tasa de bits por parte de los codificadores y una escala de cuantificación inversa simplificada
Matrices de escala de cuantificación personalizadas por frecuencia seleccionadas por el codificador para la optimización de la cuantificación basada en la percepción
Un filtro de desbloqueo en bucle que ayuda a prevenir los artefactos de bloqueo comunes a otras técnicas de compresión de imágenes basadas en DCT, lo que da como resultado una mejor apariencia visual y eficiencia de compresión.
Codificación aritmética binaria adaptativa al contexto (CABAC), un algoritmo para comprimir sin pérdida los elementos de sintaxis en el flujo de video conociendo las probabilidades de los elementos de sintaxis en un contexto determinado. CABAC comprime los datos de manera más eficiente que CAVLC, pero requiere considerablemente más procesamiento para decodificarlos.
Codificación de longitud variable adaptativa al contexto (CAVLC), que es una alternativa de menor complejidad a CABAC para la codificación de valores de coeficientes de transformación cuantificados. Aunque es más compleja que CABAC, CAVLC es más elaborada y más eficiente que los métodos que se suelen utilizar para codificar coeficientes en otros diseños anteriores.
Características de resiliencia ante pérdidas que incluyen:
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 fundamental de H.264 es generar paquetes autónomos para eliminar la duplicación de encabezados, como en el código de extensión de encabezado (HEC) de MPEG-4. [48] Esto se logró desacoplando la información relevante para más de un segmento del flujo de medios. La combinación de los parámetros de nivel superior se denomina conjunto de parámetros. [48] La especificación H.264 incluye dos tipos de conjuntos de parámetros: conjunto de parámetros de secuencia (SPS) y conjunto de parámetros de imagen (PPS). Un conjunto de parámetros de secuencia activa permanece inalterado a lo largo de una secuencia de vídeo codificada, y un conjunto de parámetros de imagen activa permanece inalterado dentro de una imagen codificada. Las estructuras de los conjuntos de parámetros de secuencia e imagen contienen información como el tamaño de la imagen, los modos de codificación opcionales empleados y el mapa de grupos de macrobloques a segmentos. [48]
El ordenamiento flexible de macrobloques (FMO), también conocido como grupos de cortes, y el ordenamiento arbitrario de cortes (ASO), son técnicas para reestructurar el ordenamiento de la representación de las regiones fundamentales ( macrobloques ) en imágenes. Generalmente considerados como una característica de robustez ante errores o pérdidas, el FMO y el ASO también se pueden utilizar para otros fines.
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, lo que permite la aplicación de protección contra errores desiguales (UEP) y otros tipos de mejoras en la robustez ante errores o pérdidas.
Cortes redundantes (RS), una característica de robustez ante errores o pérdidas que permite a un codificador enviar una representación adicional de una región de imagen (normalmente con menor fidelidad) que puede utilizarse si la representación principal se daña o se pierde.
Numeración de cuadros, una característica que permite la creación de "subsecuencias", posibilitando la escalabilidad temporal mediante la inclusión opcional de imágenes adicionales 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.
Los cortes de conmutación, denominados cortes SP y SI, permiten que un codificador ordene a un decodificador que salte a una secuencia de vídeo en curso para fines tales como la conmutación de la tasa de bits de la transmisión de vídeo y la operación en "modo truco". Cuando un decodificador salta a la mitad de una secuencia de vídeo mediante la función SP/SI, puede obtener una coincidencia exacta con las imágenes decodificadas en esa ubicación en la secuencia de vídeo a pesar de utilizar imágenes diferentes, o ninguna imagen en absoluto, como referencias antes del cambio.
Un proceso automático simple para evitar la emulación accidental de códigos de inicio , que son secuencias especiales de bits en los datos codificados que permiten el acceso aleatorio al flujo de bits y la recuperación de la alineación de bytes en sistemas que pueden perder la sincronización de bytes.
Información de mejora complementaria (SEI) e información de usabilidad de video (VUI), que son información adicional que se puede insertar en el flujo de bits para diversos fines, como indicar el espacio de color utilizado en el contenido de video o diversas restricciones que se aplican a la codificación. Los mensajes SEI pueden contener cargas útiles de metadatos arbitrarios definidos por el usuario u otros mensajes con sintaxis y semántica definidas en el estándar.
Imágenes auxiliares que pueden utilizarse para fines tales como la composición alfa .
Admite muestreo de croma monocromático (4:0:0), 4:2:0, 4:2:2 y 4:4:4 (según el perfil seleccionado).
Admite una precisión de profundidad de bits de muestra que varía de 8 a 14 bits por muestra (dependiendo del perfil seleccionado).
La capacidad de codificar planos de color individuales como imágenes distintas con sus propias estructuras de corte, modos de macrobloque, vectores de movimiento, etc., lo que permite diseñar codificadores con una estructura de paralelización simple (compatible solo con los tres perfiles compatibles con 4:4:4).
Recuento 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 decodificadas aislados de la información de tiempo, lo que permite que la información de tiempo se transporte y controle/cambie por separado por un sistema sin afectar el contenido de la imagen decodificada.
Estas técnicas, junto con varias otras, ayudan a que el formato H.264 tenga un rendimiento significativamente mejor que cualquier otro estándar anterior en una amplia variedad de circunstancias y entornos de aplicación. El formato H.264 puede tener un rendimiento radicalmente mejor que el vídeo MPEG-2, obteniendo normalmente la misma calidad a la mitad de la tasa de bits o menos, especialmente en contenidos de vídeo de alta resolución y alta tasa de bits. [49]
Al igual que otros estándares de vídeo MPEG ISO/IEC, H.264/AVC tiene una implementación de software de referencia que se puede descargar de forma gratuita. [50] Su principal objetivo es proporcionar ejemplos de las características de H.264/AVC, en lugar de ser una aplicación útil en sí misma . También se ha llevado a cabo algún trabajo de diseño de hardware de referencia en el Moving Picture Experts Group . 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 identificadas para cumplir con un determinado conjunto de especificaciones de aplicaciones previstas. Esto significa que muchas de las características enumeradas no son compatibles con algunos perfiles. En la siguiente sección se analizan varios perfiles de H.264/AVC.
Perfiles
El estándar define varios conjuntos de capacidades, a las que se hace referencia como perfiles , que apuntan a clases específicas de aplicaciones. Estas 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 sistemas, 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 mucho, el perfil más utilizado es el perfil alto.
Los perfiles para aplicaciones de vídeo 2D no escalables incluyen los siguientes:
Perfil de línea base restringido (CBP, 66 con conjunto de restricciones 1)
Este perfil, que se utiliza principalmente en aplicaciones de bajo coste, se utiliza con mayor frecuencia en aplicaciones móviles y de videoconferencia. Corresponde al subconjunto de características que tienen en común los perfiles básico, principal y alto.
Perfil basal (PA, 66)
Este perfil se utiliza principalmente en aplicaciones de bajo costo que requieren una mayor solidez frente a la pérdida de datos y en algunas aplicaciones móviles y de videoconferencia. Este perfil incluye todas las características que admite el perfil de línea base restringido, además de tres características adicionales que se pueden utilizar para lograr solidez frente a la pérdida (o para otros fines, como la composición de secuencias de video multipunto con bajo retardo). La importancia de este perfil ha disminuido un poco desde la definición del perfil de línea base restringido en 2009. Todos los flujos de bits del perfil de línea base restringido también se consideran flujos de bits del perfil de línea base, ya que estos dos perfiles comparten el mismo valor de código de identificador de perfil.
Perfil extendido (XP, 88)
Concebido como un perfil de transmisión de video, este perfil tiene una capacidad de compresión relativamente alta y algunos trucos adicionales para brindar robustez ante pérdidas de datos y cambios de transmisión del servidor.
Perfil principal (MP, 77)
Este perfil se utiliza para transmisiones de televisión digital de definición estándar que utilizan el formato MPEG-4 tal como se define en el estándar DVB. [51] Sin embargo, no se utiliza para transmisiones de televisión de alta definición, ya que la importancia de este perfil se desvaneció cuando se desarrolló el Perfil Alto en 2004 para esa aplicación.
Perfil alto (HiP, 100)
El perfil principal para aplicaciones de transmisión y almacenamiento en disco, particularmente para aplicaciones de televisión de alta definición (por ejemplo, este es el perfil adoptado por el formato de almacenamiento de discos Blu-ray y el servicio de transmisión DVB HDTV).
Perfil alto progresivo (PHiP, 100 con conjunto de restricciones 4)
Similar al perfil alto, pero sin soporte de funciones de codificación de campo.
Perfil alto restringido (100 con conjunto de restricciones 4 y 5)
Similar al perfil Progressive High, pero sin soporte de cortes B (bipredictivos).
Perfil High 10 (Hi10P, 110)
Yendo más allá de las capacidades típicas de los productos de consumo convencionales, este perfil se basa en el perfil alto y agrega soporte para hasta 10 bits por muestra de precisión de imagen decodificada.
Perfil alto 4:2:2 (Hi422P, 122)
Dirigido principalmente a aplicaciones profesionales que utilizan video entrelazado, este perfil se basa en el perfil High 10 y agrega compatibilidad con el formato de muestreo de croma 4:2:2 mientras utiliza hasta 10 bits por muestra de precisión de imagen decodificada.
Perfil predictivo alto 4:4:4 (Hi444PP, 244)
Este perfil se basa en el perfil High 4:2:2 y admite un muestreo de croma de hasta 4:4:4, hasta 14 bits por muestra y, además, admite una codificación de región sin pérdida eficiente y la codificación de cada imagen como tres planos de color separados.
Para las videocámaras, la edición y las aplicaciones profesionales, el estándar contiene cuatro perfiles adicionales de solo intra-frame , que se definen como subconjuntos simples de otros perfiles correspondientes. Estos se utilizan principalmente para aplicaciones profesionales (por ejemplo, cámaras y sistemas de edición):
Perfil intra de 10 altos (110 con conjunto de restricciones 3)
El perfil High 10 está restringido al uso en todo Intra.
Perfil intra de alta relación 4:2:2 (122 con conjunto de restricciones 3)
El perfil alto 4:2:2 está restringido al uso en todo Intra.
Perfil intra de alta resolución 4:4:4 (244 con conjunto de restricciones 3)
El perfil alto 4:4:4 está restringido al uso en todo Intra.
Perfil intra del CAVLC 4:4:4 (44)
El perfil alto 4:4:4 está restringido al uso total de Intra y a la codificación de entropía CAVLC (es decir, no admite 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 de referencia escalable (83)
Este perfil, que se dirige principalmente a aplicaciones de videoconferencia, móviles y de vigilancia, se basa en el perfil de línea base restringida al que debe ajustarse la capa base (un subconjunto del flujo de bits). Para las herramientas de escalabilidad, se habilita un subconjunto de las herramientas disponibles.
Perfil de línea base restringido 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 alto escalable (86)
Este perfil, destinado principalmente a aplicaciones de transmisión y difusión, se basa en el perfil alto H.264/AVC al que debe ajustarse la capa base.
Perfil alto escalable y restringido (86 con conjunto de restricciones 5)
Un subconjunto del Perfil Alto Escalable destinado principalmente a aplicaciones de comunicación en tiempo real.
Perfil intradiario alto escalable (86 con conjunto de restricciones 3)
Dirigido principalmente a aplicaciones de producción, este perfil es el perfil alto escalable y está limitado al uso en todo Intra.
Como resultado de la extensión Multiview Video Coding (MVC), el estándar contiene dos perfiles multiview :
Este perfil admite dos o más vistas utilizando predicción entre imágenes (temporal) y entre vistas MVC, pero no admite imágenes de campo ni codificación de campo-marco adaptativa a macrobloques.
La extensión MFC (compatible con marcos de múltiples resoluciones) agregó dos perfiles más:
Perfil alto de MFC (134)
Un perfil para codificación estereoscópica con mejora de resolución de dos capas.
MFC Profundidad Perfil Alto (135)
La extensión 3D-AVC agregó dos perfiles más:
Vista múltiple con profundidad de perfil alto (138)
Este perfil admite la codificación conjunta del mapa de profundidad y la información de textura de video para mejorar la compresión del contenido de video 3D.
Vista múltiple mejorada con profundidad de perfil alto (139)
Un perfil mejorado para codificación multivista combinada con información de profundidad.
Compatibilidad con funciones en perfiles específicos
Niveles
Tal como se utiliza el término en la norma, un " nivel " es un conjunto específico de restricciones que indican un grado de rendimiento de decodificador requerido para un perfil. Por ejemplo, un nivel de soporte dentro de un perfil especifica la resolución máxima de imagen, la velocidad de cuadros y la velocidad de bits que un decodificador puede utilizar. Un decodificador que se ajuste a un nivel determinado 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 la de los perfiles base restringido, base, extendido y principal; 3 veces para Hi10P y 4 veces para Hi422P/Hi444PP.
La cantidad de muestras de luminancia es 16×16=256 veces la cantidad de macrobloques (y la cantidad de muestras de luminancia por segundo es 256 veces la cantidad de macrobloques por segundo).
Buffer de imágenes decodificadas
Los codificadores H.264/AVC utilizan imágenes codificadas previamente para proporcionar predicciones de los valores de las muestras en otras imágenes. Esto permite al codificador tomar decisiones eficientes sobre la mejor manera de codificar una imagen determinada. En el decodificador, dichas imágenes se almacenan en un búfer de imágenes decodificadas virtual (DPB). La capacidad máxima del DPB, en unidades de cuadros (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:
Donde MaxDpbMbs es un valor constante proporcionado en la tabla siguiente como una función del número de nivel, y PicWidthInMbs y FrameHeightInMbs son el ancho de la imagen y la altura del cuadro para los datos de video codificados, expresados en unidades de macrobloques (redondeados a valores enteros y teniendo en cuenta el recorte y el emparejamiento de macrobloques cuando corresponda). Esta fórmula se especifica en las secciones A.3.1.h y A.3.2.f de la edición de 2017 de la norma. [28]
Por ejemplo, para una imagen HDTV de 1.920 muestras de ancho (Ancho de imagen en mbs = 120) y 1.080 muestras de alto (Altura del marco en mbs = 68), un decodificador de nivel 4 tiene una capacidad máxima de almacenamiento DPB depiso(32768/(120*68))= 4 cuadros (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 cuadro 1920×1080.
La imagen actual que se está decodificando no se incluye en el cálculo de la capacidad máxima del DPB (a menos que el codificador haya indicado que se almacene para usarla como referencia para decodificar otras imágenes o para la sincronización de salida retrasada). Por lo tanto, un decodificador necesita tener memoria suficiente para manejar (al menos) un cuadro más que la capacidad máxima del DPB calculada anteriormente.
Implementaciones
En 2009, el grupo de trabajo HTML5 se dividió entre los partidarios de Ogg Theora , un formato de vídeo libre que se cree que no está sujeto a patentes, y H.264, que contiene tecnología patentada. En julio de 2009, se decía que Google y Apple admitían H.264, mientras que Mozilla y Opera admitían Ogg Theora (ahora Google, Mozilla y Opera admiten Theora y WebM con VP8 ). [52] Microsoft, con el lanzamiento de Internet Explorer 9, ha añadido compatibilidad con vídeo HTML 5 codificado con 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 va a adoptar HTML5". [53] En enero de 2011, Google anunció que retiraría el soporte para H.264 de su navegador Chrome y que permitiría que Theora y WebM / VP8 utilizaran únicamente formatos abiertos. [54]
El 18 de marzo de 2012, Mozilla anunció la compatibilidad con H.264 en Firefox para dispositivos móviles, debido a la prevalencia del video codificado en H.264 y la mayor eficiencia energética que supone utilizar hardware decodificador H.264 dedicado, común en dichos dispositivos. [55] El 20 de febrero de 2013, Mozilla implementó la compatibilidad en Firefox para decodificar H.264 en Windows 7 y versiones posteriores. Esta característica se basa en las bibliotecas de decodificación integradas de Windows. [56] Firefox 35.0, lanzado el 13 de enero de 2015, es compatible con H.264 en OS X 10.6 y versiones posteriores. [57]
El 30 de octubre de 2013, Rowan Trollope de Cisco Systems anunció que Cisco liberaría tanto los binarios como 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 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 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. [58] [59] [60] También el 30 de octubre de 2013, Brendan Eich de Mozilla escribió que utilizarí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. [61] Cisco publicó el código fuente de OpenH264 el 9 de diciembre de 2013. [62]
Aunque iOS no fue compatible con el lanzamiento del software de Cisco de 2013, Apple actualizó su Video Toolbox Framework con iOS 8 (lanzado en septiembre de 2014) para proporcionar acceso directo a la codificación y decodificación de video H.264/AVC basada en hardware. [59]
Codificadores de software
Hardware
Debido a que la codificación y decodificación H.264 requiere una potencia de cálculo significativa en tipos específicos de operaciones aritméticas, las implementaciones de software que se ejecutan en CPU de propósito general suelen ser menos eficientes en términos de consumo de energía. Sin embargo, las CPU x86 de propósito general de cuatro núcleos más recientes [ ¿cuándo? ] tienen suficiente potencia de cálculo para realizar 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 la basada en software es más bien de eficiencia energética, flexibilidad y 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, particularmente cuando la codificación debe realizarse simultáneamente en múltiples formatos, múltiples velocidades de bits y resoluciones ( video multipantalla ) y posiblemente con características adicionales en soporte de formato contenedor, características publicitarias integradas avanzadas, 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.
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 utilizado en el ASIC suele estar autorizado por una de unas pocas empresas, como Chips&Media , Allegro DVT, On2 (anteriormente Hantro, adquirida por Google), Imagination Technologies y NGCodec. Algunas empresas tienen ofertas de productos tanto FPGA como ASIC. [70]
Texas Instruments fabrica una línea de núcleos ARM + DSP que realizan codificación DSP H.264 BP 1080p a 30 fps. [71] 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.
El 26 de agosto de 2010, MPEG LA anunció que no se cobrarían regalías por los videos de Internet codificados en H.264 que son gratuitos para los usuarios finales. [76] Todas las demás regalías se mantendrán vigentes, como las regalías por productos que decodifican y codifican videos en H.264, así como por operadores de canales de televisión y suscripción gratuitos. [77] Los términos de la licencia se actualizan en bloques de 5 años. [78]
Dado que la primera versión de la norma se completó en mayo de 2003 (Hace 21 años) y el perfil más utilizado (el perfil Alto) se completó en junio de 2004 [ cita requerida ] (Hace 20 años), algunas de las patentes relevantes ya han expirado, [75] mientras que otras todavía están vigentes en jurisdicciones de todo el mundo y una de las patentes estadounidenses en el grupo MPEG LA H.264 (otorgada en 2016, prioridad desde 2001) dura al menos hasta noviembre de 2030. [79]
En 2005, Qualcomm demandó a Broadcom en el Tribunal de Distrito de los 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. [80] En 2007, el Tribunal de Distrito determinó que las patentes no eran ejecutables porque Qualcomm no las había revelado al JVT antes de la publicación del estándar H.264 en mayo de 2003. [80] En diciembre de 2008, el Tribunal de Apelaciones de los EE. UU. para el Circuito Federal confirmó la orden del Tribunal de Distrito de que las patentes no fueran ejecutables, pero remitió el caso al Tribunal de Distrito con instrucciones de limitar el alcance de la inaplicabilidad a los productos que cumplen con el estándar H.264. [80]
En octubre de 2023, Nokia demandó a HP y Amazon por infracción de patentes H.264/H.265 en EE. UU., el Reino Unido y otros lugares. [81]
Véase también
VC-1 , un estándar diseñado por Microsoft y aprobado como estándar SMPTE en 2006
^ MPEG-4, Advanced Video Coding (Part 10) (H.264) (borrador completo). Sustainability of Digital Formats. Washington, DC: Biblioteca del Congreso. 5 de diciembre de 2011. Consultado el 1 de diciembre de 2021 .
^ «H.264: codificación avanzada de vídeo para servicios audiovisuales genéricos». www.itu.int . Archivado desde el original el 31 de octubre de 2019. Consultado el 22 de noviembre de 2019 .
^ "Informe sobre desarrolladores de vídeo 2018" (PDF) . Bitmovin . Septiembre de 2019.
^ "Informe de desarrolladores de vídeo 2019". Bitmovin . Septiembre de 2019.
^ "Entrega de 8K mediante AVC/H.264". Mystery Box . Archivado desde el original el 25 de marzo de 2021 . Consultado el 23 de agosto de 2017 .
^ ab Wang, Hanli; Kwong, S.; Kok, C. (2006). "Algoritmo de predicción eficiente de coeficientes DCT enteros para optimización H.264/AVC". IEEE Transactions on Circuits and Systems for Video Technology . 16 (4): 547–552. doi :10.1109/TCSVT.2006.871390. S2CID 2060937.
^ ab Thomson, Gavin; Shah, Athar (2017). "Introducción a HEIF y HEVC" (PDF) . Apple Inc. Consultado el 5 de agosto de 2019 .
^ Ozer, Jan (8 de mayo de 2023), Heath Hoglund de Via LA habla sobre la fusión de los consorcios de patentes de licencias MPEG LA y Via, StreamingMedia.com
^ "Recomendaciones UIT-T". UIT . Consultado el 1 de noviembre de 2022 .
^ "H.262: Tecnología de la información — Codificación genérica de imágenes en movimiento e información de audio asociada: Vídeo" . Consultado el 15 de abril de 2007 .
^ "Recomendación UIT-T H.264 (05/2003)". UIT. 30 de mayo de 2003 . Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (05/2003) Cor. 1 (05/2004)". UIT. 7 de mayo de 2004 . Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (03/2005)". UIT. 1 de marzo de 2005 . Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (2005) Cor. 1 (09/2005)". UIT. 13 de septiembre de 2005 . Consultado el 18 de abril de 2013 .
^ ab "Recomendación UIT-T H.264 (2005) Enm. 1 (06/2006)". UIT. 13 de junio de 2006. Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (2005) Enm. 2 (04/2007)". UIT. 6 de abril de 2007. Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (11/2007)". UIT. 22 de noviembre de 2007 . Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (2007) Cor. 1 (01/2009)". UIT. 13 de enero de 2009 . Consultado el 18 de abril de 2013 .
^ ab "Recomendación UIT-T H.264 (03/2009)". UIT. 16 de marzo de 2009 . Consultado el 18 de abril de 2013 .
^ ab "Recomendación UIT-T H.264 (03/2010)". UIT. 9 de marzo de 2010 . Consultado el 18 de abril de 2013 .
^ ab "Recomendación UIT-T H.264 (06/2011)". UIT. 29 de junio de 2011 . Consultado el 18 de abril de 2013 .
^ "Recomendación UIT-T H.264 (01/2012)". UIT. 13 de enero de 2012 . Consultado el 18 de abril de 2013 .
^ abcd "Recomendación UIT-T H.264 (04/2013)". UIT. 12 de junio de 2013 . Consultado el 16 de junio de 2013 .
^ ab «Recomendación UIT-T H.264 (02/2014)». UIT. 28 de noviembre de 2014. Consultado el 28 de febrero de 2016 .
^ "Recomendación UIT-T H.264 (02/2016)". UIT. 13 de febrero de 2016. Consultado el 14 de junio de 2017 .
^ "Recomendación UIT-T H.264 (10/2016)". UIT. 14 de octubre de 2016 . Consultado el 14 de junio de 2017 .
^ abc "Recomendación UIT-T H.264 (04/2017)". UIT. 13 de abril de 2017. Véanse las Tablas A-1, A-6 y A-7 para ver las capacidades dependientes del nivel tabuladas . Consultado el 14 de junio de 2017 .
^ «H.264: Codificación avanzada de vídeo para servicios audiovisuales genéricos - Versión 26 (Edición 13)». www.itu.int . 13 de junio de 2019. Archivado desde el original el 4 de noviembre de 2021 . Consultado el 3 de noviembre de 2021 .
^ «H.264: Codificación avanzada de vídeo para servicios audiovisuales genéricos - Versión 27 (Edición 14)». www.itu.int . 22 de agosto de 2021. Archivado desde el original el 4 de noviembre de 2021 . Consultado el 3 de noviembre de 2021 .
^ ab "AVC/H.264 – Lista de patentes" (PDF) . MPEG LA . Consultado el 22 de diciembre de 2022 .
^ "Licenciantes AVC/H.264". MPEG-LA. Archivado desde el original el 30 de mayo de 2015. Consultado el 19 de mayo de 2013 .
^ Wenger y col. (febrero de 2005). "RFC 3984: Formato de carga útil RTP para vídeo H.264". Ietf Datatracker : 2. doi :10.17487/RFC3984.
^ "¿Qué modo de grabación es equivalente a la calidad de imagen del formato de vídeo de alta definición (HDV)?". Sony eSupport . Archivado desde el original el 9 de noviembre de 2017. Consultado el 8 de diciembre de 2018 .
^ "Estándar ATSC A/72 Parte 1: Características del sistema de video AVC en el sistema de televisión digital ATSC" (PDF) . Archivado desde el original (PDF) el 7 de agosto de 2011 . Consultado el 30 de julio de 2011 .
^ "Estándar ATSC A/72 Parte 2: Características del subsistema de transporte de video AVC" (PDF) . Archivado desde el original (PDF) el 7 de agosto de 2011 . Consultado el 30 de julio de 2011 .
^ "Estándar ATSC A/153 Parte 7: Características del sistema de video AVC y SVC" (PDF) . Archivado desde el original (PDF) el 26 de julio de 2011 . Consultado el 30 de julio de 2011 .
^ ab «Sony presenta el nuevo formato de grabación XAVC para acelerar el desarrollo del 4K en los mercados profesional y de consumo». Sony. 30 de octubre de 2012. Consultado el 1 de noviembre de 2012 .
^ ab «Sony presenta el nuevo formato de grabación XAVC para acelerar el desarrollo del 4K en los mercados profesional y de consumo» (PDF) . Sony. 30 de octubre de 2012. Consultado el 1 de noviembre de 2012 .[ enlace muerto permanente ]
^ Steve Dent (30 de octubre de 2012). "Sony va a la caza del rojo con las videocámaras profesionales CineAlta 4K con sensor Super 35 mm PMW-F55 y PMW-F5". Engadget . Consultado el 5 de noviembre de 2012 .
^ "F55 CineAlta 4K el futuro, antes de lo previsto" (PDF) . Sony. 30 de octubre de 2012. Archivado desde el original (PDF) el 19 de noviembre de 2012 . Consultado el 1 de noviembre de 2012 .
^ "Las tarjetas de memoria ultrarrápidas "SxS PRO+" transforman la captura de vídeo 4K". Sony. Archivado desde el original el 8 de marzo de 2013. Consultado el 5 de noviembre de 2012 .
^ "Las tarjetas de memoria ultrarrápidas "SxS PRO+" transforman la captura de vídeo 4K" (PDF) . Sony. Archivado desde el original (PDF) el 2 de abril de 2015 . Consultado el 5 de noviembre de 2012 .
^ ab Stanković, Radomir S.; Astola, Jaakko T. (2012). "Reminiscencias de los primeros trabajos en DCT: entrevista con KR Rao" (PDF) . Reimpresiones de los primeros días de las ciencias de la información . 60 : 17. Consultado el 13 de octubre de 2019 .
^ Kwon, Soon-young; Lee, Joo-kyong; Chung, Ki-dong (2005). "Corrección de medio píxel para la transcodificación MPEG-2/H.264". Análisis y procesamiento de imágenes – ICIAP 2005. Apuntes de clase en informática. Vol. 3617. Springer Berlin Heidelberg. págs. 576–583. doi : 10.1007/11553595_71 . ISBN.978-3-540-28869-5.
^ Britanak, Vladimir; Yip, Patrick C.; Rao, KR (2010). Transformadas discretas de coseno y seno: propiedades generales, algoritmos rápidos y aproximaciones enteras. Elsevier . pp. ix, xiii, 1, 141–304. ISBN9780080464640.
^ "El estándar de codificación de vídeo avanzado H.264/AVC: descripción general e introducción a las extensiones de rango Fidelity" (PDF) . Consultado el 30 de julio de 2011 .
^ abc RFC 3984, pág. 3
^ Apple Inc. (26 de marzo de 1999). «Preguntas frecuentes sobre H.264». Apple. Archivado desde el original el 7 de marzo de 2010. Consultado el 17 de mayo de 2010 .
^ Karsten Suehring. "Descarga del software de referencia H.264/AVC JM". Iphome.hhi.de . Consultado el 17 de mayo de 2010 .
^ "TS 101 154 – V1.9.1 – Transmisión de vídeo digital (DVB); Especificación para el uso de codificación de vídeo y audio en aplicaciones de transmisión basadas en el flujo de transporte MPEG-2" (PDF) . Consultado el 17 de mayo de 2010 .
^ "Descodificación del debate sobre el códec de vídeo HTML 5". Ars Technica . 6 de julio de 2009 . Consultado el 12 de enero de 2011 .
^ "Steve Ballmer, CEO de Microsoft, entrevistado en el Gartner Symposium/ITxpo Orlando 2010". Gartnervideo. Noviembre de 2010. Archivado desde el original el 30 de octubre de 2021. Consultado el 12 de enero de 2011 .
^ "Compatibilidad con códecs de vídeo HTML en Chrome". 11 de enero de 2011. Consultado el 12 de enero de 2011 .
^ "Video, Mobile, and the Open Web". 18 de marzo de 2012. Consultado el 20 de marzo de 2012 .
^ "WebRTC habilitado, compatibilidad con H.264/MP3 en Win 7 activada de forma predeterminada, interfaz Metro para Windows 8 y más: aspectos destacados del desarrollo de Firefox". hacks.mozilla.org . mozilla. 20 de febrero de 2013 . Consultado el 15 de marzo de 2013 .
^ "Firefox — Notas (35.0)". Mozilla .
^ "H.264 de código abierto elimina barreras para WebRTC". 30 de octubre de 2013. Archivado desde el original el 6 de julio de 2015 . Consultado el 1 de noviembre de 2013 .
^ ab "Preguntas frecuentes sobre el proyecto Cisco OpenH264" . Consultado el 26 de septiembre de 2021 .
^ "Licencia BSD simplificada OpenH264". GitHub . 27 de octubre de 2013 . Consultado el 21 de noviembre de 2013 .
^ "La interoperabilidad de vídeo en la Web recibe un impulso del códec H.264 de Cisco". 30 de octubre de 2013. Consultado el 1 de noviembre de 2013 .
^ "Compatibilidad con codificación x264 4:0:0 (monocromática)", consultado el 5 de junio de 2019.
^ "Compatibilidad con codificación x264 4:2:2", consultado el 5 de junio de 2019.
^ "Compatibilidad con codificación x264 4:4:4", consultado el 5 de junio de 2019.
^ "Soporte x264 para codificación de 9 y 10 bits", consultado el 22 de junio de 2011.
^ "x264 reemplaza el perfil High 4:4:4 sin pérdida con High 4:4:4 Predictive", consultado el 22 de junio de 2011.
^ "Guía de referencia rápida de las imágenes integradas de los procesadores Intel Core de última generación". Intel Software Network. 1 de octubre de 2010. Consultado el 19 de enero de 2011 .
^ "Intel Quick Sync Video". www.intel.com. 1 de octubre de 2010. Consultado el 19 de enero de 2011 .
^ "Design-reuse.com". Design-reuse.com. 1 de enero de 1990. Consultado el 17 de mayo de 2010 .
^ "Categoría:DM6467 - Wiki de procesadores integrados de Texas Instruments". Processors.wiki.ti.com. 12 de julio de 2011. Archivado desde el original el 17 de julio de 2011 . Consultado el 30 de julio de 2011 .
^ "OMS Video, un proyecto de la iniciativa Open Media Commons de Sun". Archivado desde el original el 11 de mayo de 2010. Consultado el 26 de agosto de 2008 .
^ "Licenciantes incluidos en la licencia de cartera de patentes AVC/H.264". MPEG LA . Consultado el 18 de junio de 2019 .
^ ab "AVC/H.264 – Lista de patentes". Vía Licensing Alliance . Consultado el 28 de abril de 2024 .
^ "La licencia AVC de MPEG LA no cobrará regalías por el vídeo de Internet que sea gratuito para los usuarios finales durante la vigencia de la licencia" (PDF) . MPEG LA. 26 de agosto de 2010. Archivado desde el original (PDF) el 7 de noviembre de 2013. Consultado el 26 de agosto de 2010 .
^ Hachman, Mark (26 de agosto de 2010). "MPEG LA recorta las regalías de los vídeos web gratuitos para siempre". pcmag.com . Consultado el 26 de agosto de 2010 .
^ "Preguntas frecuentes sobre AVC". MPEG LA. 1 de agosto de 2002. Archivado desde el original el 7 de mayo de 2010. Consultado el 17 de mayo de 2010 .
^ "Patente de los Estados Unidos 9.356.620 Baese, et al." . Consultado el 1 de agosto de 2022 .con fecha de prioridad más temprana del 14 de septiembre de 2001, tiene una extensión de plazo de 2.998 días.
^ abc Véase Qualcomm Inc. v. Broadcom Corp., No. 2007-1545, 2008-1162 (Fed. Cir. 1 de diciembre de 2008). Para artículos en la prensa popular, véase signonsandiego.com, "Qualcomm loses its patent-rights case" y "Qualcomm's patent case goes to jury"; y bloomberg.com "Broadcom Wins First Trial in Qualcomm Patent Dispute"
^ "nokia h264".
Lectura adicional
Wiegand, Thomas; Sullivan, Gary J.; Bjøntegaard, Gisle; Luthra, Ajay (julio de 2003). "Descripción general del estándar de codificación de vídeo H.264/AVC" (PDF) . IEEE Transactions on Circuits and Systems for Video Technology . 13 (7): 560–576. doi :10.1109/TCSVT.2003.815165 . Consultado el 31 de enero de 2011 .
Topiwala, Pankaj; Sullivan, Gary J.; Luthra, Ajay (agosto de 2004). Tescher, Andrew G (ed.). "El estándar de codificación de vídeo avanzado H.264/AVC: descripción general e introducción a las extensiones de rango de fidelidad" (PDF) . Aplicaciones de procesamiento de imágenes digitales XXVII de SPIE . Aplicaciones de procesamiento de imágenes digitales XXVII. 5558 : 454. Bibcode :2004SPIE.5558..454S. doi :10.1117/12.564457. S2CID 2308860 . Consultado el 31 de enero de 2011 .
Ostermann, J.; Bormans, J.; List, P.; Marpe, D.; Narroschke, M.; Pereira, F.; Stockhammer, T.; Wedi, T. (2004). "Codificación de vídeo con H.264/AVC: herramientas, rendimiento y complejidad" (PDF) . Revista IEEE Circuits and Systems . 4 (1): 7–28. doi :10.1109/MCAS.2004.1286980. S2CID 11105089. Archivado desde el original (PDF) el 6 de julio de 2017 . Consultado el 31 de enero de 2011 .
Puri, Atul; Chen, Xuemin; Luthra, Ajay (octubre de 2004). "Codificación de vídeo utilizando el estándar de compresión H.264/MPEG-4 AVC" (PDF) . Procesamiento de señales: comunicación de imágenes . 19 (9): 793–849. doi :10.1016/j.image.2004.06.003 . Consultado el 30 de marzo de 2011 .
Sullivan, Gary J.; Wiegand, Thomas (enero de 2005). "Video Compression—From Concepts to the H.264/AVC Standard" (PDF) . Actas del IEEE . 93 (1): 18–31. doi :10.1109/jproc.2004.839617. S2CID 1362034 . Consultado el 31 de enero de 2011 .
Richardson, Iain EG (enero de 2011). "Aprenda sobre la compresión de video y H.264". VCODEX . Vcodex Limited . Consultado el 31 de enero de 2011 .
Enlaces externos
Página de publicación de la UIT-T: H.264: Codificación avanzada de vídeo para servicios audiovisuales genéricos
Información sobre MPEG-4 AVC/H.264 Foro de Doom9
Tutoriales de H.264/MPEG-4 Parte 10 (Richardson)
"Parte 10: Codificación avanzada de vídeo". Página de publicación ISO: ISO/IEC 14496-10:2010 – Tecnología de la información – Codificación de objetos audiovisuales .
"Software de referencia H.264/AVC JM". Página de inicio de IP . Consultado el 15 de abril de 2007 .
«Sitio de archivo de documentos de JVT». Archivado desde el original el 8 de agosto de 2010. Consultado el 6 de mayo de 2007 .
"Publicaciones". Thomas Wiegand . Consultado el 23 de junio de 2007 .
"Publicaciones". Detlev Marpe . Consultado el 15 de abril de 2007 .
"Cuarta comparación anual de códecs de vídeo H.264". Universidad Estatal de Moscú.(fecha de diciembre de 2007)
"Discusión sobre H.264 en relación con las cámaras IP utilizadas en las industrias de seguridad y vigilancia". 3 de abril de 2009.(fecha de abril de 2009)