stringtranslate.com

Codificación avanzada de vídeo

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

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. [ 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 extensiones 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 es quizás mejor conocido por ser el formato de codificación de video más comúnmente usado en discos Blu-ray . También es ampliamente utilizado por fuentes de Internet de transmisión, como videos de Netflix , Hulu , Amazon Prime Video , Vimeo , YouTube y la iTunes Store , software web como Adobe Flash Player y Microsoft Silverlight , y también varias transmisiones de HDTV en sistemas terrestres ( 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 [ 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.

Titulares 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 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]

Los mercados de circuito cerrado de televisión y de videovigilancia han incluido la tecnología en muchos productos.

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).

AVC-Intra es un formato de compresión intracuadro únicamente, 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 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

Diagrama de bloques de H.264

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:

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 :

Estéreo de perfil alto (128)
Este perfil apunta al video 3D estereoscópico de dos vistas y combina las herramientas del perfil Alto con las capacidades de predicción entre vistas de la extensión MVC.
Vista múltiple de perfil alto (118)
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:

DpbCapacity = min(piso( MaxDpbMbs / ( AnchoPicInMbs * AlturaMarcoInMbs )), 16)

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

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

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.

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

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.

Licencias

En los países donde se respetan las patentes de algoritmos de software , se espera que los vendedores y usuarios comerciales de productos que utilizan H.264/AVC paguen regalías por licencias de patentes por la tecnología patentada que utilizan sus productos. [72] Esto también se aplica al Perfil de referencia. [73]

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

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

Referencias

  1. ^ 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 .
  2. ^ «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 .
  3. ^ "Informe de desarrolladores de vídeo 2018" (PDF) . Bitmovin . Septiembre de 2019.
  4. ^ "Informe de desarrolladores de vídeo 2019". Bitmovin . Septiembre de 2019.
  5. ^ "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 .
  6. ^ 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.
  7. ^ ab Thomson, Gavin; Shah, Athar (2017). "Introducción a HEIF y HEVC" (PDF) . Apple Inc. Consultado el 5 de agosto de 2019 .
  8. ^ 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
  9. ^ "Recomendaciones UIT-T". UIT . Consultado el 1 de noviembre de 2022 .
  10. ^ "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 .
  11. ^ Equipo de vídeo conjunto, sitio web de la UIT-T .
  12. ^ "Recomendación UIT-T H.264 (05/2003)". UIT. 30 de mayo de 2003 . Consultado el 18 de abril de 2013 .
  13. ^ "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 .
  14. ^ "Recomendación UIT-T H.264 (03/2005)". UIT. 1 de marzo de 2005 . Consultado el 18 de abril de 2013 .
  15. ^ "Recomendación UIT-T H.264 (2005) Cor. 1 (09/2005)". UIT. 13 de septiembre de 2005 . Consultado el 18 de abril de 2013 .
  16. ^ 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 .
  17. ^ "Recomendación UIT-T H.264 (2005) Enm. 2 (04/2007)". UIT. 6 de abril de 2007. Consultado el 18 de abril de 2013 .
  18. ^ "Recomendación UIT-T H.264 (11/2007)". UIT. 22 de noviembre de 2007 . Consultado el 18 de abril de 2013 .
  19. ^ "Recomendación UIT-T H.264 (2007) Cor. 1 (01/2009)". UIT. 13 de enero de 2009 . Consultado el 18 de abril de 2013 .
  20. ^ ab "Recomendación UIT-T H.264 (03/2009)". UIT. 16 de marzo de 2009 . Consultado el 18 de abril de 2013 .
  21. ^ ab "Recomendación UIT-T H.264 (03/2010)". UIT. 9 de marzo de 2010 . Consultado el 18 de abril de 2013 .
  22. ^ ab "Recomendación UIT-T H.264 (06/2011)". UIT. 29 de junio de 2011 . Consultado el 18 de abril de 2013 .
  23. ^ "Recomendación UIT-T H.264 (01/2012)". UIT. 13 de enero de 2012 . Consultado el 18 de abril de 2013 .
  24. ^ abcd "Recomendación UIT-T H.264 (04/2013)". UIT. 12 de junio de 2013 . Consultado el 16 de junio de 2013 .
  25. ^ ab «Recomendación UIT-T H.264 (02/2014)». UIT. 28 de noviembre de 2014. Consultado el 28 de febrero de 2016 .
  26. ^ "Recomendación UIT-T H.264 (02/2016)". UIT. 13 de febrero de 2016. Consultado el 14 de junio de 2017 .
  27. ^ "Recomendación UIT-T H.264 (10/2016)". UIT. 14 de octubre de 2016 . Consultado el 14 de junio de 2017 .
  28. ^ 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 .
  29. ^ «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 .
  30. ^ «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 .
  31. ^ ab "AVC/H.264 – Lista de patentes" (PDF) . MPEG LA . Consultado el 22 de diciembre de 2022 .
  32. ^ "Licenciantes AVC/H.264". MPEG-LA. Archivado desde el original el 30 de mayo de 2015. Consultado el 19 de mayo de 2013 .
  33. ^ 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.
  34. ^ "¿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 .
  35. ^ "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 .
  36. ^ "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 .
  37. ^ "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 .
  38. ^ 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 .
  39. ^ 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 ]
  40. ^ 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 .
  41. ^ "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 .
  42. ^ "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 .
  43. ^ "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 .
  44. ^ 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 .
  45. ^ 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.
  46. ^ 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. ISBN 9780080464640.
  47. ^ "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 .
  48. ^ abc RFC 3984, pág. 3
  49. ^ 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 .
  50. ^ Karsten Suehring. "Descarga del software de referencia H.264/AVC JM". Iphome.hhi.de . Consultado el 17 de mayo de 2010 .
  51. ^ "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 .
  52. ^ "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 .
  53. ^ "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 .
  54. ^ "Compatibilidad con códecs de vídeo HTML en Chrome". 11 de enero de 2011. Consultado el 12 de enero de 2011 .
  55. ^ "Video, Mobile, and the Open Web". 18 de marzo de 2012. Consultado el 20 de marzo de 2012 .
  56. ^ "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 .
  57. ^ "Firefox — Notas (35.0)". Mozilla .
  58. ^ "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 .
  59. ^ ab "Preguntas frecuentes sobre el proyecto Cisco OpenH264" . Consultado el 26 de septiembre de 2021 .
  60. ^ "Licencia BSD simplificada OpenH264". GitHub . 27 de octubre de 2013 . Consultado el 21 de noviembre de 2013 .
  61. ^ "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 .
  62. ^ "README actualizado · cisco/openh264@59dae50". GitHub .
  63. ^ "Compatibilidad con codificación x264 4:0:0 (monocromática)", consultado el 5 de junio de 2019.
  64. ^ "Compatibilidad con codificación x264 4:2:2", consultado el 5 de junio de 2019.
  65. ^ "Compatibilidad con codificación x264 4:4:4", consultado el 5 de junio de 2019.
  66. ^ "Soporte x264 para codificación de 9 y 10 bits", consultado el 22 de junio de 2011.
  67. ^ "x264 reemplaza el perfil High 4:4:4 sin pérdida con High 4:4:4 Predictive", consultado el 22 de junio de 2011.
  68. ^ "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 .
  69. ^ "Intel Quick Sync Video". www.intel.com. 1 de octubre de 2010. Consultado el 19 de enero de 2011 .
  70. ^ "Design-reuse.com". Design-reuse.com. 1 de enero de 1990. Consultado el 17 de mayo de 2010 .
  71. ^ "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 .
  72. ^ "Portafolio informativo" (PDF) . www.mpegla.com .
  73. ^ "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 .
  74. ^ "Licenciantes incluidos en la licencia de cartera de patentes AVC/H.264". MPEG LA . Consultado el 18 de junio de 2019 .
  75. ^ ab "AVC/H.264 – Lista de patentes". Vía Licensing Alliance . Consultado el 28 de abril de 2024 .
  76. ^ "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 .
  77. ^ 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 .
  78. ^ "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 .
  79. ^ "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.
  80. ^ 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"
  81. ^ "nokia h264".

Lectura adicional

Enlaces externos