El vídeo HTML es un tema de la especificación HTML como la forma estándar de reproducir vídeo a través de la web. Introducido en HTML5 , [1] está diseñado para reemplazar parcialmente el elemento de objeto y el estándar de facto anterior de usar el complemento propietario Adobe Flash , aunque la adopción temprana se vio obstaculizada por la falta de acuerdo sobre qué formatos de codificación de vídeo y formatos de codificación de audio deberían ser compatibles con los navegadores web. A partir de 2020, el vídeo HTML es la única tecnología de reproducción de vídeo ampliamente compatible en los navegadores modernos, y el complemento Flash se está eliminando gradualmente.
El <video>
elemento comenzó a ser discutido por el WHATWG en octubre de 2006. [2] El <video>
elemento fue propuesto por Opera Software en febrero de 2007. [3] Opera también lanzó una versión preliminar que se mostró el mismo día, [4] [5] y un manifiesto que exigía que el vídeo se convirtiera en un ciudadano de primera clase de la web. [6]
El siguiente fragmento de código HTML incrustará un vídeo WebM en una página web.
< video src = "movie.webm" poster = "movie.jpg" controles >Este es un contenido de respaldo para mostrar a los agentes de usuario que no admiten la etiqueta de video.</ vídeo >
El atributo "controls" habilita la interfaz de usuario del navegador para controlar la reproducción. Alternativamente, la reproducción se puede controlar con JavaScript , que el diseñador web puede usar para crear una interfaz de usuario personalizada. El atributo opcional "poster" especifica una imagen para mostrar en el lugar del video antes de que comience la reproducción. Su propósito es ser representativo del video.
El soporte de formatos de video varía entre los navegadores (ver abajo), por lo que una página web puede proporcionar videos en múltiples formatos. Para otras funciones, a veces se utiliza el rastreo del navegador , lo que puede ser propenso a errores: el conocimiento de los navegadores de cualquier desarrollador web será inevitablemente incompleto o no estará actualizado. El navegador en cuestión "sabe mejor" qué formatos puede usar. El elemento "video" admite la opción de respaldo mediante la especificación de múltiples fuentes. Usando cualquier número de elementos <source>, como se muestra abajo, el navegador elegirá automáticamente qué archivo descargar. Alternativamente, se puede usar la función canPlayType() de JavaScript para lograr lo mismo. El atributo "type" especifica el tipo MIME y posiblemente una lista de códecs, lo que ayuda al navegador a determinar si puede decodificar el archivo sin comenzar a descargarlo. El tipo MIME denota el formato contenedor del archivo, y el formato contenedor define la interpretación de la cadena de códecs. [7]
< video poster = "poster.jpg" controles > < source src = "av1.mp4" type = 'video/mp4; codecs="av01.0.00M.08, opus"' > < source src = "avc.mp4" type = 'video/mp4; codecs="avc1.4D401E, mp4a.40.2"' > < source src = "vp9.webm" type = 'video/webm; codecs="vp9.0, opus"' > < source src = "theora.ogv" type = 'video/ogg; codecs="theora, vorbis"' > < p > Este es un contenido de respaldo para mostrar a los agentes de usuario que no admiten la etiqueta de video. </ p > </ video >
La especificación HTML no especifica qué formatos de vídeo y audio deben admitir los navegadores. Los agentes de usuario tienen la libertad de admitir cualquier formato de vídeo que consideren apropiado, pero los autores de contenido no pueden asumir que todos los agentes de usuario que cumplan con la especificación puedan acceder a cualquier vídeo, ya que los agentes de usuario no tienen un conjunto mínimo de formatos de vídeo y audio que admitir.
El grupo de trabajo HTML5 consideró conveniente especificar al menos un formato de vídeo que todos los agentes de usuario (navegadores) deberían admitir. El formato ideal a este respecto sería:
Inicialmente, Ogg Theora era el formato de vídeo estándar recomendado en HTML5, porque no se veía afectado por ninguna patente conocida. Pero el 10 de diciembre de 2007, la especificación HTML5 se actualizó [8] , reemplazando la referencia a formatos concretos:
Los agentes de usuario deben admitir video Theora y audio Vorbis, así como el formato contenedor Ogg.
con un marcador de posición: [9]
Sería de gran ayuda para la interoperabilidad que todos los navegadores pudieran soportar los mismos códecs. Sin embargo, no se conocen códecs que satisfagan a todos los actores actuales: necesitamos un códec que no requiera licencias por unidad o por distribuidor, que sea compatible con el modelo de desarrollo de código abierto, que tenga la calidad suficiente para ser utilizable y que no suponga un riesgo adicional de patente submarina para las grandes empresas. Se trata de un problema en curso y esta sección se actualizará una vez que haya más información disponible. [10]
El resultado fue una polarización del vídeo HTML entre formatos estándar de la industria , definidos por la ISO pero sujetos a patentes , y formatos abiertos . El nuevo formato AV1 de Alliance for Open Media pretende ser estándar de la industria, libre de regalías y abierto, y cuenta con un amplio apoyo de la industria.
Aunque Theora no se ve afectada por patentes conocidas que no son libres, Apple [11] ha expresado su preocupación por patentes desconocidas que podrían afectarla, cuyos propietarios podrían estar esperando a que una corporación con amplios recursos financieros utilice el formato antes de demandar. [12] [13] Formatos como H.264 también podrían estar sujetos a patentes desconocidas en principio, pero se han implementado mucho más ampliamente y por lo tanto se presume que cualquier titular de patentes ya se habría dado a conocer. Apple también se ha opuesto a exigir soporte para el formato Ogg en el estándar HTML (incluso como un requisito "debería") con el argumento de que algunos dispositivos podrían admitir otros formatos mucho más fácilmente, y que HTML históricamente no ha requerido formatos particulares para nada. [13]
Algunos desarrolladores web criticaron la eliminación de los formatos Ogg de la especificación. [14] También se produjo un debate de seguimiento en el blog de preguntas y respuestas del W3C. [15]
Mozilla y Opera solo admiten los formatos abiertos de Theora y WebM . Google manifestó su intención de eliminar la compatibilidad con H.264 en 2011, específicamente para la etiqueta de video HTML. [16] Aunque se ha eliminado de Chromium , a enero de 2021 [actualizar]aún no se ha eliminado de Google Chrome diez años después. [17] [18]
El estándar de transmisión de velocidad de bits adaptable MPEG-DASH se puede utilizar en navegadores web a través de las extensiones de fuente de medios (MSE) [19] y reproductores DASH basados en JavaScript. Estos reproductores son, por ejemplo, el proyecto de código abierto dash.js [19] del DASH Industry Forum, pero también existen productos como el reproductor de video HTML5 de Bitmovin [20] (que utiliza HTML con JavaScript, pero también reproductores DASH basados en Flash para navegadores web antiguos que no admiten MSE).
La adquisición de On2 por parte de Google en 2010 dio como resultado la adquisición del formato de vídeo VP8 . Google ha proporcionado una licencia libre de regalías para utilizar VP8. [21] Google también inició WebM , que combina el códec de vídeo de código abierto estandarizado VP8 con audio Vorbis en un contenedor basado en Matroska . La apertura de VP8 fue bien recibida por la Free Software Foundation . [22]
Cuando Google anunció en enero de 2011 que pondría fin al soporte nativo de H.264 en Chrome, [23] llegaron críticas de muchos sectores, entre ellos Peter Bright de Ars Technica [24] y el evangelista web de Microsoft Tim Sneath, que comparó la decisión de Google con la de declarar el esperanto como idioma oficial de los Estados Unidos. [25] Sin embargo, Haavard Moen de Opera Software criticó duramente el artículo de Ars Technica [26] y Google respondió a la reacción aclarando su intención de promover WebM en sus productos sobre la base de la apertura. [16]
Después del lanzamiento de WebM, Mozilla y Opera han pedido la inclusión de VP8 en HTML. [27]
El 7 de marzo de 2013, Google Inc. y MPEG LA , LLC anunciaron acuerdos que cubren técnicas que "pueden ser esenciales" para VP8, con Google recibiendo una licencia de MPEG LA y 11 titulares de patentes, y MPEG LA poniendo fin a sus esfuerzos para formar un fondo de patentes de VP8. [28] [29] [30] [31]
En 2012, Google lanzó VP9 como sucesor de VP8, también abierto y libre de regalías.
A finales de 2017, el nuevo formato AV1 desarrollado por la Alliance for Open Media (AOMedia) como evolución de VP9 ha alcanzado el punto de congelación de funciones, y se espera que el congelamiento del flujo de bits se produzca en enero de 2018. Las compilaciones nocturnas de Firefox ya incluyen soporte para AV1. [32]
El formato H.264/MPEG-4 AVC se utiliza ampliamente y tiene buena velocidad, compresión, decodificadores de hardware y calidad de vídeo, pero está sujeto a patentes. [33] Los usuarios de H.264 necesitan licencias de los titulares de patentes individuales o de MPEG LA , un grupo de titulares de patentes que incluye a Microsoft y Apple, excepto para algunos usos de transmisión de vídeo por Internet. [34] El formato H.264 se utiliza normalmente en el formato contenedor MP4, junto con el audio Advanced Audio Coding (AAC). El AAC también está cubierto por patentes en sí mismo, por lo que los usuarios de MP4 tendrán que obtener licencias tanto para H.264 como para AAC.
En junio de 2009, el WHATWG concluyó que ningún formato existente era adecuado como requisito específico. [35]
Apple todavía sólo admite H.264, pero Microsoft ahora admite VP9 y WebM, y ha prometido soporte para AV1 .
El 30 de octubre de 2013, Cisco anunció que iba a poner a disposición de los usuarios un módulo binario H.264 para su descarga. Cisco pagará los costes de licencia de patentes de esos módulos binarios cuando el software que los utiliza los descargue durante su instalación , lo que permitirá utilizar H.264 de forma gratuita en ese caso específico. [36]
En el anuncio, Cisco citó como motivo su deseo de promover el uso del proyecto WebRTC , ya que la función de chat de vídeo de WebRTC se beneficiará de tener un formato de vídeo compatible con todos los navegadores. [37] El módulo H.264 estará disponible en "todas las plataformas populares o que sean factibles de soportar, que se pueden cargar en cualquier aplicación". [38]
Cisco también está planeando publicar el código fuente de esos módulos bajo licencia BSD , pero sin pagar regalías, [36] por lo que el código será prácticamente software libre sólo en países sin patentes de software H.264 , lo que ya ha sucedido con otras implementaciones existentes.
El 30 de octubre de 2013, Brendan Eich , de Mozilla , anunció que Firefox descargaría automáticamente el módulo H.264 de Cisco cuando fuera necesario de forma predeterminada. También señaló que el módulo binario no es una solución perfecta, ya que los usuarios no tienen plenos derechos de software libre para "modificar, recompilar y redistribuir sin acuerdos de licencia ni tarifas". De esta forma, Xiph y Mozilla continúan con el desarrollo de Daala . [38] [39]
OpenH264 sólo es compatible con el perfil básico de H.264 y no resuelve por sí mismo la necesidad de un decodificador AAC. Por lo tanto, no se considera suficiente para el vídeo web MP4 típico, que normalmente tiene un perfil alto con el audio AAC. [40] [41] [42] Sin embargo, para su uso en WebRTC, la omisión de AAC se justificó en el anuncio de lanzamiento: "los organismos de normalización se han alineado con Opus y G.711 como los códecs de audio comunes para WebRTC". [37] Existe la duda de si una licencia global limitada de AAC, como la de Cisco para H.264, es factible después de que la oficina de licencias de AAC eliminara el límite de precio poco después del lanzamiento de OpenH264. [43]
Esta tabla muestra qué formatos de vídeo es probable que sean compatibles con un agente de usuario determinado . La mayoría de los navegadores que se enumeran aquí utilizan un marco multimedia para decodificar y mostrar vídeo, en lugar de incorporar dichos componentes de software. Por lo general, no es posible determinar el conjunto de formatos compatibles con un marco multimedia sin consultarlo, porque eso depende del sistema operativo y de los códecs de terceros. [44] En estos casos, la compatibilidad con formatos de vídeo es un atributo del marco, no del navegador (o su motor de diseño), suponiendo que el navegador consulte correctamente su marco multimedia antes de rechazar formatos de vídeo desconocidos. En algunos casos, la compatibilidad que se enumera aquí no es una función de los códecs disponibles dentro del marco multimedia subyacente del sistema operativo ni de las capacidades de códecs integradas en el navegador, sino que podría deberse a un complemento del navegador que podría, por ejemplo, omitir el análisis HTML normal del navegador de la etiqueta <video> para incrustar un reproductor de vídeo basado en complemento.
Tenga en cuenta que un archivo de vídeo normalmente contiene contenido de vídeo y audio, cada uno codificado en su propio formato. El navegador debe admitir tanto el formato de vídeo como el de audio. Consulte Audio HTML para ver una tabla de los formatos de audio que admite cada navegador.
El formato de vídeo se puede especificar mediante el tipo MIME en HTML (ver ejemplo). Los tipos MIME se utilizan para consultar los marcos multimedia sobre los formatos compatibles. [45]
De estos navegadores, sólo Firefox y Opera emplean bibliotecas para la decodificación integrada. En la práctica, Internet Explorer y Safari también pueden garantizar cierto soporte de formatos, porque sus fabricantes también hacen sus marcos multimedia. En el otro extremo de la escala, Konqueror tiene un soporte de formatos idéntico al de Internet Explorer cuando se ejecuta en Windows, y Safari cuando se ejecuta en Mac, pero el soporte seleccionado aquí para Konqueror es el típico para Linux , donde Konqueror tiene la mayoría de sus usuarios. En general, el soporte de formatos de los navegadores está muy dictado por los intereses en conflicto de los proveedores, específicamente que Media Foundation y QuickTime admiten estándares comerciales, mientras que GStreamer y Phonon no pueden admitir legalmente otros formatos que no sean los libres de forma predeterminada en los sistemas operativos libres a los que están destinados. [46]
Navegador | Sistema operativo | Teora ( Ogg ) | H.264 ( MP4 ) | HEVC ( MP4 ) | VP8 ( WebM ) | VP9 ( WebM ) | AV1 ( WebM ) |
---|---|---|---|---|---|---|---|
Navegador de Android | Androide | Desde 2.3 [47] | Desde 3.0 [47] | Desde 5.0 [47] | Desde 2.3 [47] | Desde 4.4 [47] | Desde 10 |
Cromo | Similar a Unix y Windows | Desde r18297 [48] | Vía FFmpeg [49] [50] | No [51] | Desde r47759 [52] | Desde r172738 [53] | Sí |
Google Chrome | Similar a Unix, Android, macOS y Windows | Desde 3.0 [54] [55] | Desde 3.0 [55] [a] | Desde 105 (decodificación de software; necesita códecs a nivel de sistema operativo) Desde 107 (decodificación de hardware; necesita decodificador de hardware) [57] [58] | Desde 6.0 [59] [60] | Desde 29.0 [b] | Desde el 70 [63] |
Explorador de Internet | Ventanas | Vía OpenCodecs | Desde 9.0 [64] | No [65] | Vía OpenCodecs | No | No |
Teléfono Windows | No | Desde 9.0 [66] | No | ||||
Ventanas RT | Desde 10.0 [66] | ||||||
Microsoft Edge | Similar a Unix, macOS y Windows (Cromo) | Desde v79 [67] [68] | Desde v79 (único navegador compatible con DRM PlayReady) [67] [69] | No [65] | Desde v79 [67] [70] | Desde v79 [67] [70] | Desde v79 [67] |
Windows 10 (versión Legacy EdgeHTML) | Desde 17.0 (con extensiones de medios web) [71] [72] [73] | Desde 12.0 [74] | Necesita decodificador de hardware [c] | Desde la versión 17.0 (compatible con la etiqueta <video> con extensiones de medios web y extensiones de video VP9) [72] | Solo se habilita de forma predeterminada si está presente el decodificador de hardware [77] Desde 17.0 (compatible con la etiqueta <video> con extensiones de medios web y extensiones de video VP9) [71] [72] [73] | Desde 18.0 (con extensión de video AV1) [78] | |
Windows 10 Móvil | No | Desde 13.0 [79] | Desde 15.0 (sólo vía MSE ) [80] | Desde 14.0 (sólo vía MSE ) [81] | No | ||
Conquistador | Similar a Unix y Windows | Necesita códecs a nivel de sistema operativo [d] | |||||
Mozilla Firefox | Windows 7+ | Desde 3.5 [82] | Desde 21.0 [e] | No [65] | Desde 4.0 [85] | Desde 28.0 [86] [87] | Desde 65.0 (64 bits) [88] Desde 66.0 (32 bits) [89] |
Windows Vista | Desde 22.0 [90] | ||||||
Ediciones de Windows XP y N | Desde 46.0 [91] | ||||||
Linux | 26.0 (a través de GStreamer ) [f] 43.0 (a través de FFmpeg ) [94] | Desde 67.0 [ cita requerida ] | |||||
Androide | Desde 17.0 [95] | en Nightly [ cita requerida ] | |||||
macOS | Desde 34.0 [96] | Desde 66.0 [89] | |||||
Sistema operativo Firefox | Desde 1.1 [97] | No | |||||
Opera Móvil | Android, iOS, Symbian y Windows Mobile | Desde 13.0 | Desde las 11.50 | No [98] | Desde 15.0 | Desde 16.0 | desde 57.0 [63] |
Ópera | MacOS, Windows | Desde 10.50 [99] | Desde 24.0 [100] | Desde 10.60 [101] [102] | Sí | desde 57.0 [63] | |
Linux | Necesita biblioteca de códecs [g] | ||||||
Safari | iOS | No | Desde 3.1 [104] | Desde las 11 [105] | Desde 17.4 (totalmente compatible) [106] Desde 12.1 (solo a través de WebRTC ) [107] | Desde 17.4 (totalmente compatible) [106] Desde 14 (solo a través de WebRTC ) [108] | Desde 17.0 (necesita decodificador de hardware; necesita contenedor MP4 [ cita requerida ] ) [109] [h] |
macOS | A través de los componentes QuickTime de Xiph ( macOS 10.11 y anteriores) | Desde 14.1 [110] | Desde 14.1 [110] | ||||
Web de GNOME | Linux y BSD | Necesita códecs a nivel de sistema operativo [i] |
Estos indican el nivel de compatibilidad con el elemento en cuestión en cada motor. De forma predeterminada, se da por sentado que se trata de la versión más reciente del motor. Sin embargo, se puede indicar un número de versión específico; cuando esto indica compatibilidad total, se trata de la versión inicial del motor que admite totalmente el elemento.
Valor | Significado |
---|---|
Sí | Totalmente compatible |
No | Nunca ha sido soportado |
Parcial | Solo se admiten algunos valores |
Incorrecto | No se implementa correctamente en todos los casos |
Experimental | Puede estar incompleto o tener errores. |
Construcción nocturna | Actualmente en desarrollo; se espera soporte completo |
Depende | Solo compatible con las condiciones especificadas |
Abandonó | Ya no es compatible |
El vídeo transparente, es decir, el vídeo con un canal alfa , tiene múltiples ventajas de diseño: [113]
transparent
[117] en su código de incrustación.El HTML tiene soporte para la gestión de derechos digitales (DRM, que restringe el modo en que se puede utilizar el contenido) a través de las extensiones de medios cifrados (EME). La incorporación de DRM es controvertida porque permite restringir la libertad de los usuarios para utilizar medios restringidos por DRM, incluso cuando el uso legítimo otorga a los usuarios el derecho legal de hacerlo. [118] Un argumento principal en la aprobación de EME por parte del W3C fue que, de lo contrario, el contenido de vídeo se entregaría en complementos y aplicaciones, y no en el navegador web. [119]
En 2013, Netflix agregó soporte para video HTML usando EME, además de su antiguo método de entrega usando un complemento Silverlight (también con DRM). [120]
En 2010, a raíz del lanzamiento del iPad de Apple y después de que Steve Jobs anunciara que los dispositivos móviles de Apple no soportarían Flash , varios sitios de alto perfil comenzaron a ofrecer video HTML H.264 en lugar de Adobe Flash para agentes de usuario que se identificaban como iPad. [121] El video HTML no estaba tan extendido como los videos Flash, aunque hubo lanzamientos de reproductores de video experimentales basados en HTML de DailyMotion (usando el formato Ogg Theora y Vorbis), [122] YouTube (usando los formatos H.264 y WebM), [123] y Vimeo (usando el formato H.264). [124]
La compatibilidad con vídeos en formato HTML ha ido aumentando de forma constante. En junio de 2013, Netflix añadió compatibilidad con vídeos en formato HTML. [125] En enero de 2015, YouTube pasó a utilizar vídeos en formato HTML en lugar de Flash de forma predeterminada. [126] En diciembre de 2015, Facebook pasó de Flash a HTML para todos los contenidos de vídeo. [127]
En 2016, Flash todavía se instala ampliamente en computadoras de escritorio, aunque generalmente no es compatible con dispositivos móviles como teléfonos inteligentes. [128] Se asume ampliamente, incluso por Adobe, [128] [129] que el complemento Flash está destinado a ser eliminado gradualmente, [130] [131] lo que dejará al video HTML como el único método ampliamente compatible para reproducir videos en la World Wide Web. Chrome, [132] [133] Firefox, [134] Safari, [135] y Edge, [136] tienen planes de hacer que casi todo el contenido Flash se reproduzca haciendo clic en 2017. El único navegador importante que no ha anunciado planes para descontinuar Flash es Internet Explorer. [137] Adobe anunció el 25 de julio de 2017 que finalizaría permanentemente el desarrollo de Flash en 2020. [138]
Un elemento de vídeo se utiliza para reproducir vídeos o películas.
{{cite web}}
: CS1 maint: copia archivada como título ( enlace )blog muestra varios casos de uso de videos transparentes en el diseño web, además de publicitar su propio producto de software, Rotato.
Chrome 31 ahora admite la transparencia alfa de vídeo en WebM. En otras palabras, Chrome tiene en cuenta el canal alfa al reproducir vídeos de pantalla verde codificados en WebM (VP8 y VP9) con un canal alfa. Esto significa que puedes reproducir vídeos con fondos transparentes: sobre páginas web, imágenes o incluso otros vídeos.
El color de fondo (color de escenario) de un archivo SWF se puede configurar como transparente. El color de fondo o la imagen de la página HTML que contiene el archivo SWF se muestran a través de él. Esta técnica permite superponer contenido SWF con contenido DHTML (HTML dinámico). No todos los navegadores web manejan la transparencia de la misma manera. Asegúrese de probar su archivo SWF en todos los navegadores que desee permitir que su audiencia lo use. La mayoría de los navegadores Linux no admiten la transparencia Animate.
transparente: el contenido SWF se superpone con otros elementos HTML en la página. El color de fondo del archivo SWF (color de escenario) es transparente. Los elementos HTML debajo del archivo SWF son visibles a través de cualquier área transparente del SWF, con combinación alfa. Esta opción reduce el rendimiento de reproducción en comparación con wmode=window o wmode=direct.