stringtranslate.com

Discusión:Video HTML

Página desactualizada

La mayor parte del material y las fuentes parecen ser de 2010 y estar muy desactualizados. Las referencias a Youtube deberían actualizarse, ya que han cambiado al reproductor HTML5 por defecto. — Comentario anterior sin firmar añadido por 183.89.94.215 (discusión) 14:35, 29 de julio de 2015 (UTC) [ responder ]

AV1

El códec AV1 de Alliance for Open Media Video. — Comentario anterior sin firmar añadido por 2800:810:43F:8352:71B6:EDBA:ACD5:54AD (discusión) 17:26 6 ago 2017 (UTC) [ responder ]

Controles

Esa parte de "controles" necesita más explicación. GRACIAS -- 202.130.181.213 (discusión) 11:05 18 feb 2010 (UTC) [ responder ]

Relación con el elemento del objeto

El artículo debería mencionar cómo se relaciona el video con object , una etiqueta más antigua que también se puede usar para incrustar video u otros datos. Por ejemplo, debería describir las similitudes y diferencias entre sus implementaciones, sus limitaciones relativas entre sí (¿qué puede hacer el video que object no puede, y viceversa?), si los editores HTML5 eran conscientes de la capacidad de object de mostrar video a través de, por ejemplo,

<object data= "movie.ogv" type= "video/ogg" > <!-- el tipo puede ser reemplazado por HTTP Content-Type [1] --> <param name= "controls" value= "controls" /> < !-- parámetro hipotético que puede depender del reproductor -->
su navegador no soporta la etiqueta de objeto o no tiene un reproductor para videos Ogg </object> <!-- [1] http://www.w3.org/TR/html4/struct/objects.html#h-13.3 -->

(si existe un reproductor predeterminado), y si el editor HTML5 pretende que el vídeo complemente o reemplace el objeto para sus usos. -- un nombre extraño 20:58, 23 de febrero de 2010 (UTC) [ responder ]

¿Alguien? :( -- un nombre extraño 23:25, 21 de marzo de 2010 (UTC) [ responder ]

<object> es un elemento que puede utilizarse para hacer prácticamente cualquier cosa, como incluir imágenes, vídeo, audio, secuencias de comandos, etc. No diría que <video> está relacionado con él más de lo que lo está <img> (algunos navegadores admiten SVG tanto en <object> como en <img>, por ejemplo). — Aryeh Gregor ( discusión  •  contribs ) 18:26 22 mar 2010 (UTC) [ responder ]

Código abierto

El código abierto puede tener muchos significados y las licencias de código abierto pueden conllevar restricciones. ¿Sabemos si la propuesta de Google de lanzar al mercado de código abierto los códecs On2 los hará gratuitos ? Stephen B Streater ( discusión ) 17:49 13 abr 2010 (UTC) [ responder ]

Todo lo que digamos será sólo especulación hasta el anuncio oficial de Google.
-- Gyrobo ( discusión ) 18:12 13 abr 2010 (UTC) [ responder ]
El software de código abierto, tal como lo define la OSI, significa casi exactamente lo mismo que el software libre, tal como lo define la FSF . Google publica toneladas de material libre/de código abierto y sabe perfectamente qué se considera libre/de código abierto. Supongo que se publicará completamente libre de patentes o con solo cláusulas de defensa de patentes. Pero los detalles son, en efecto, especulativos, por lo que solo podemos repetir la terminología exacta que dan nuestras fuentes. — Aryeh Gregor ( discusión  •  contribs ) 18:25, 13 de abril de 2010 (UTC) [ responder ]
Así que tal vez Gyrobo u otro editor quieran revertir su versión de mi edición que dice que aún no lo sabemos.[1] Stephen B Streater ( discusión ) 20:03 13 abr 2010 (UTC) [ responder ]
No, porque el texto actual es simplemente lo que dice la fuente. Cualquier otra inferencia sería especulativa.
-- Gyrobo ( discusión ) 21:01 13 abr 2010 (UTC) [ responder ]
Sí, ahora lo entiendo. Stephen B Streater ( discusión ) 21:38 13 abr 2010 (UTC) [ responder ]

Esta fuente de noticias menciona específicamente el código libre de regalías en contraposición al código abierto. También cubre los antecedentes de este problema. Stephen B Streater ( discusión ) 09:56 19 abr 2010 (UTC) [ responder ]

Ambigüedad en la sección de notas del artículo

Por ejemplo: "Cualquier formato compatible con QuickTime en OS X".

¿Significa esto que Safari admite cualquier formato QT en OS X o cualquier formato que el propio QT admita en OS X ? -- 91.11.218.75 (discusión) 23:01 21 abr 2010 (UTC) [ responder ]

Significa "Safari reproducirá cualquier formato que reproduzca el marco multimedia QuickTime", específicamente Ogg Theora cuando esté instalado XiphQT.-- 129.241.30.66 (discusión) 09:13 1 may 2010 (UTC) [ responder ]

Ausencia de patentes vs. patentes con licencia libre de regalías

Este artículo es confuso en cuanto a la situación de las patentes de Theora. Véase http://theora.org/faq/#24 Hsivonen ( discusión ) 12:00, 24 de abril de 2010 (UTC) [ responder ]

La tabla de compatibilidad de navegadores es engañosa

Salvo en el caso de (la minoría de) los navegadores que tienen códecs integrados, la compatibilidad con formatos multimedia no es una cuestión del navegador, por lo que no hay que presentarla como tal. En estos casos, la información es solo normativa. No hay que mezclar lo normativo con lo factual.

Ejemplos: Konqueror aparentemente soporta Theora y no H.264, aunque la nota dice correctamente que Phonon puede soportar cualquier formato. Es solo que el 99% de todos los usuarios de Konqueror usan GNU/Linux, que tiende a tener soporte para formatos ogg como base. Safari e IE9 aparentemente no soportan Theora, pero como sabemos por Safari, no es un problema del navegador. Poco se sabe sobre IE9 todavía, pero si usa el marco multimedia nativo de Windows, también debería reproducir Theora cuando se instalen los filtros de DirectShow a menos que se niegue a hacerlo. Mi punto es: No es un hecho.-- 129.241.30.66 (discusión) 10:13, 1 de mayo de 2010 (UTC) [ responder ]

Esta confusión simplemente demuestra por qué una tabla de comparación para navegadores web es inútil; una tabla de comparación para motores de renderizado aclararía este asunto, y hay una página de comparación específicamente para eso.
-- Gyrobo ( discusión ) 23:03 1 may 2010 (UTC) [ responder ]
He revertido temporalmente los cambios que has realizado hasta que podamos llegar a un consenso sobre este tema. No estoy en desacuerdo contigo sobre la importancia de enfatizar el soporte del backend, pero la tabla anterior era más fácil (al menos para mí) de entender.
-- Gyrobo ( discusión ) 23:09 1 may 2010 (UTC) [ responder ]
¡La tabla antigua es mejor para comprender/leer! mabdul 08:49, 2 de mayo de 2010 (UTC) [ responder ]
Vale, existe una tabla sensata, pero la mía era más detallada. No me rendiré.-- 129.241.30.66 (discusión) 05:06 3 may 2010 (UTC) [ responder ]
¡Podrías ayudarnos en eso! Estas tablas son más técnicas y creo que tu edición sería más útil allí. mabdul 08:10, 3 de mayo de 2010 (UTC) [ responder ]

Reorganización de la tabla de videos HTML5

Es necesario que exista algún tipo de métrica que podamos usar para determinar si un navegador admite vídeo HTML5 o no... Propongo el siguiente conjunto de condiciones para los navegadores.

Estas condiciones deberían estar señaladas de alguna forma en la tabla. De cualquier manera, creo que la tabla estaría más organizada si los lectores pudieran simplemente tener una respuesta "sí", "no" o "versión en desarrollo" para el navegador que desean consultar. -- 112.203.100.68 (discusión) 11:23 4 may 2010 (UTC) [ responder ]

  • Usando el último sistema operativo
    El sistema operativo no es relevante para la compatibilidad. Puede haber algunas peculiaridades (como que Opera use GStreamer y admita H.264 en Linux/FreeBSD), pero sería más fácil explicarlo con una nota.
  • Configuración de instalación predeterminada
    Estoy de acuerdo, los navegadores deberían describirse según su compatibilidad con códecs. Chrome Frame y XiphQT son buenos ejemplos de notas, pero el objetivo de las tablas de comparación como esta es comparar el software en sí, no los complementos.
  • Limite la cantidad de navegadores que se representarán en la tabla a solo los cinco principales en participación de uso
    Hubo una discusión en Talk:Comparación de motores de diseño (Hojas de estilo en cascada)#Agregar nuevos motores sobre este tipo de cosas, y todavía creo en lo que dije allí: que sí, para fines de importancia estadística y verificabilidad, definitivamente deberíamos limitar el número de motores.
  • De cualquier manera, creo que la tabla estaría más organizada si los lectores pudieran simplemente tener una respuesta "sí", "no" o "versión en desarrollo" para el navegador que desean verificar.
    Así es como está configurado actualmente. Hay todas esas dependencias de Otros , pero todas incluyen notas para los backends.
-- Gyrobo ( discusión ) 20:22 4 may 2010 (UTC) [ responder ]

No simplifiquemos demasiado:

  1. Creo que lo que querías decir es que Safari no es compatible con Theora.
  2. Estoy de acuerdo en que esta tabla es peligrosa y simplificada, porque hace referencia a navegadores web en lugar de a motores de diseño. Eso es lo que la Comparación de motores de diseño (medios HTML5) pretende corregir.
  3. Quise decir que el sistema operativo en sí no es relevante. La tabla trata sobre la compatibilidad nativa con videos, que incluye solo los códecs incluidos de manera consistente en todas las plataformas compatibles. Este es otro caso en el que una comparación solo de motores de renderizado resolvería el problema. Si un navegador es capaz de admitir más formatos directamente a través de un backend externo, eso no es importante, pero no indica compatibilidad nativa para el propósito de esta tabla.
  4. No se puede debatir si alguien cree o no que IE9 sólo será compatible con H.264, a menos que Microsoft diga que planea ofrecer compatibilidad con otros códecs. No lo ha hecho.
-- Gyrobo ( discusión ) 00:17 16 may 2010 (UTC) [ responder ]

Creo que deberíamos tener "sí" cuando es compatible con las configuraciones predeterminadas, y "depende" cuando depende de códecs de terceros. O quizás necesitamos otra categoría posible ("complementos disponibles"). Por ejemplo, IE9 aparentemente permitirá VP8 *si los códecs están instalados*, mientras que simplemente se niega a agregar soporte para Theora. El "no" de Theora es diferente del "no" de VP8. Luiscubal ( discusión ) 22:07 20 may 2010 (UTC) [ responder ]

Tal vez deberíamos incluir la plantilla:Explicación de las tablas2 , como hacen las páginas de comparación.
-- Gyrobo ( discusión ) 22:16 20 may 2010 (UTC) [ responder ]
Definitivamente, pero aparte de eso, creo que "depende" indica claramente que una propiedad se admite solo en casos específicos, lo que es cierto para la compatibilidad con IE9 y VP8. Luiscubal ( discusión ) 21:41 21 may 2010 (UTC) [ responder ]
Sin embargo, debemos ser coherentes con el soporte de Theora de Safari. Tanto Safari como IE cambian a depende, o ambos permanecen en "No" con una nota. Lo que decidamos aquí también se aplicará a Comparison_of_layout_engines_(HTML5_Media). Luiscubal ( discusión ) 21:45 21 may 2010 (UTC) [ responder ]
Tanto Theora para Safari como VP8 para IE deberían ser "no". La tabla compara la compatibilidad de códecs predeterminada, no la compatibilidad a través de software de terceros. Tanto XiphQT como los filtros DirectShow no son parte de ninguna instalación predeterminada. Así es como la Comparación de motores de diseño (HTML5 Media) trata a los motores de diseño. WebKit aparece como "depende" de muchos códecs porque los navegadores WebKit (Safari, Chrome) admiten exclusivamente distintos códecs. Solo los códecs que son compatibles de forma universal, en todos los navegadores WebKit, aparecen como un "sí" rotundo. Esa es mi opinión al respecto.
-- Gyrobo ( discusión ) 22:11, 21 de mayo de 2010 (UTC) [ responder ]
Sin embargo, esto pone a Theora y VP8 de IE9 en la misma categoría (como dije anteriormente), lo cual no es correcto. Sin soporte nativo no significa que no haya soporte en absoluto. Sin embargo, no incluimos el soporte de plugins/frameworks JS como "Depends" en otras comparaciones, por lo que esta falta de distinción podría ser aceptable Luiscubal ( discusión ) 18:27, 24 de mayo de 2010 (UTC) [ responder ]
No veo el propósito de la tabla a menos que se trate (exclusivamente) de describir el soporte nativo. Cualquier navegador puede soportar cualquier códec utilizando las combinaciones adecuadas de complementos. El objetivo de los elementos multimedia HTML5 es proporcionar soporte sin complementos.
-- Gyrobo ( discusión ) 18:39, 24 de mayo de 2010 (UTC) [ responder ]
Muy bien, entonces no lo es. Sin embargo, deberíamos añadir una nota a la página o mencionar en algún lugar de la misma que estos valores sólo se refieren al soporte nativo y excluyen la posibilidad de instalar codecs adicionales. Luiscubal ( discusión ) 22:14 24 may 2010 (UTC) [ responder ]
 Listo. Cambié el título en la parte superior de la tabla para que diga "Compatibilidad con video nativo". ¿Es lo suficientemente descriptivo? Este problema ha causado tanta confusión, asegurémonos de aclararlo perfectamente.
-- Gyrobo ( discusión ) 22:21 24 may 2010 (UTC) [ responder ]
Creo que sí. Luiscubal ( discusión ) 22:33 24 may 2010 (UTC) [ responder ]
No estoy de acuerdo. Creo que la tabla debería distinguir entre "No es compatible y no se puede añadir" y "No es compatible de fábrica, pero se puede añadir instalando un códec". Es una distinción muy significativa. Hsivonen ( discusión ) 13:29 26 may 2010 (UTC) [ responder ]
La tabla sí distingue esto, a través de notas en las celdas afectadas.
-- Gyrobo ( discusión ) 13:55 26 may 2010 (UTC) [ responder ]
La política de "soporte nativo solamente" significa que Opera, Konqueror y Epiphany ya no soportan H.264. Al igual que Safari e IE9 no soportan Theora, sino al revés. Sigo pensando que la política es errónea, pero es más importante hacer una comparación justa. En cuanto a IE9, no tenemos motivos para creer que soporta Theora menos que VP8. Recuerden, predije correctamente que usa filtros DirectShow, a pesar de que todas las fuentes dicen "solamente H264", lo que creo que demuestra mi comprensión de cómo funcionan estas cosas, en contraposición a lo que Microsoft quiere que la gente crea.-- 129.241.30.66 (discusión) 01:01, 25 de mayo de 2010 (UTC) [ responder ]
Disculpe, pero el hecho de que un navegador utilice DirectShow no significa que admita todos los códecs que admite DirectShow. Los problemas de seguridad y estabilidad pueden hacer que los navegadores tengan compatibilidad con códecs basada en listas blancas. Y Microsoft *SÍ* afirmó que sólo admitiría H.264. Recientemente cambiaron la declaración a "compatible con VP8 si está instalado", lo que significa que su lista blanca (la única forma posible que tienen para asegurarse de que el navegador utilice sólo estos dos códecs) incluye tanto H.264 como VP8. Tal vez IE9 no tenga una lista blanca, pero necesitamos una fuente fiable para afirmarlo (ya que la investigación original y las suposiciones a ciegas están prohibidas por las reglas de Wikipedia). —Comentario anterior sin firmar añadido por Luiscubal ( discusión • contribs ) 18:12, 27 de mayo de 2010 (UTC)[ responder ]
¿No ves la diferencia entre un códec y un complemento del navegador? Los códecs no tienen nada que ver con los navegadores. Tampoco con sus motores de diseño, por cierto. Esto es un problema del sistema operativo. ¿Por qué no hacer una tabla de "soporte del sistema operativo para formatos de vídeo" en su lugar? Esto es simplemente engañoso. 129.241.30.66 (discusión) 01:01, 25 de mayo de 2010 (UTC) [ responder ]
En primer lugar, sería bueno registrarse, ip ;) el sistema operativo significa solo que cada navegador que admita las API nativas también reproduciría el video en el navegador y el video sería codificado por el sistema operativo: eso solo sucedería en IE (en Win) y Safari (en Mac OS X) [y quizás OWB] ... el usuario debe instalar un complemento (o en el caso de IE y Safari: Mac por la rutina de actualización relacionada con el sistema operativo como Windows Update). Como ese no es el caso, en la mayoría de los casos los códecs son relevantes para el navegador instalado y esta tabla es correcta en este momento. Además de eso, solo necesitamos esperar unos meses y se lanzarán los nuevos navegadores y todos los problemas se resolverán con el tiempo. Este es realmente un problema a corto (tiempo). mabdul 01:19, 25 de mayo de 2010 (UTC) [ responder ]

¡GUAU! ¡Nunca pensé que mi plantilla "Explicación de las tablas 2" llegaría a aparecer en más artículos, excepto en las comparaciones de motores de diseño! ¡Buen trabajo por parte de todos! ¡Por el momento, le doy mi opinión a Gyrobos! mabdul 00:11, 25 de mayo de 2010 (UTC) [ responder ]

¿Podemos ahora limitar el número de navegadores que se representan en la tabla a sólo los cinco primeros, como se sugirió antes? Acabo de notar que los tres navegadores de abajo (Konqueror, Epiphany y Origyn) dependen del marco multimedia del sistema operativo. Esta característica se puede resumir y, de hecho, ahora está representada en los comentarios debajo de la tabla con las menciones de Phonon y Gstreamer respectivamente. Sugiero que se amplíe el comentario para incluir a Konqueror y Epiphany como ejemplos de navegadores que utilizan los marcos Phonon y Gstreamer para video HTML5, y hacer una nueva entrada para Origyn en el comentario como un ejemplo de un navegador que utiliza el marco FFmpeg para video HTML5. -- 112.203.100.68 (discusión) 07:02, 26 de mayo de 2010 (UTC) [ responder ]

  • Si quieres separar los navegadores multiplataforma de los que utilizan marcos multimedia, estoy totalmente de acuerdo. Solo recuerda que DirectShow y QuickTime son marcos multimedia, lo que deja solo a Firefox, Opera y Chrome en la tabla. Genial, porque la tabla ya no sería engañosa: la tabla quiere comparar "formatos compatibles de forma nativa". Donde "nativo" se refiere al sistema operativo, ¡por supuesto que se trata de una comparación (disfrazada) de sistemas operativos!
  • No estoy de acuerdo con limitar la atención a los 5 navegadores principales. Si el lector está interesado en los avances tecnológicos y las posibilidades de HTML5, nos gustaría mostrar su amplio soporte. ¿Tiene éxito donde Flash falla? Si la significación estadística es interesante, deje las estadísticas del navegador para que las interprete el lector. Como usuario de Konqueror, sé que las estadísticas son completamente erróneas porque mi navegador se contabiliza como Safari.-- 129.241.30.66 (discusión) 23:15 7 jun 2010 (UTC) [ responder ]

Creo que la tabla actual es falsa en los siguientes aspectos:

La razón por la que no realizo las modificaciones es que espero que Gyrobo simplemente me revierta como antes, cuando revirtió mi edición y afirmó efectivamente que los códecs conectables para GStreamer y QuickTime no eran análogos. Hsivonen ( discusión ) 11:10 28 ago 2010 (UTC) [ responder ]

Hay 2 tipos de navegadores: {cualquier formato, formatos específicos}

Formatos específicos

La compatibilidad de formatos de estos navegadores se establece en el momento de la compilación. Pueden utilizar códecs y bibliotecas internamente, pero no son conectables.

Cualquier formato

La compatibilidad de formatos de estos navegadores está determinada únicamente por su backend, y su backend permite conectar y desconectar códecs.

Disponibilidad de códecs para backends multimedia conectables

Esta es la realidad exacta. ¿Por qué descomprimir la realidad en una gran matriz de información no tan exacta más notas y excepciones, como si se tratara de llegar a una audiencia incompetente? -- 129.241.30.137 (discusión) 00:23 11 ene 2011 (UTC) [ responder ]

Respecto a las notas de soporte

En la tabla de compatibilidad de navegadores, la nota 1 dice: "Indirectamente posible si está instalado Google Chrome Frame". Esta nota se aplica a Theora y es precisa hasta donde yo sé. Sin embargo, en lo que respecta a la compatibilidad con VP8, solo se hace referencia a la instalación del códec en el sistema. ¿Google Chrome Frame no soportará VP8 de la misma manera que soporta Theora? ¿O estamos esperando a que se indique que esto es realmente posible? En cuanto a la nota 3, propongo cambiarla a "Indirectamente posible si están instalados tanto IE Tab como Google Chrome Frame". Es una pequeña diferencia, pero deja más claro que el "y" es intencional. Luiscubal ( discusión ) 18:45, 6 de junio de 2010 (UTC) [ responder ]

Audio HTML5

¿No deberíamos crear también una página separada para el audio HTML5? ¿O renombrar este artículo como HTML5 Media y crear dos páginas en rojo? He creado una para el audio HTML5 para comparar, pero no estoy muy contento con esta situación. mabdul 12:06, 13 de agosto de 2010 (UTC) [ responder ]

Se crearía un artículo si hubiera suficiente contenido. En este momento, el video HTML5 trata principalmente sobre el debate de formato sobre un códec predeterminado y su uso. No ha habido un debate tan grande sobre el audio HTML5, y el uso del audio HTML5 no ha sido tan prominente como el video. [ cita requerida ] Si encuentra suficientes fuentes para la implementación del audio HTML5, deberíamos incluirlo en un solo artículo de medios o en un artículo de audio HTML5 separado.
-- Gyrobo ( discusión ) 00:03, 14 de agosto de 2010 (UTC) [ responder ]

Técnicamente, cualquier debate sobre formato que se aplique al vídeo también se aplica al audio, porque el AAC también es un códec patentado que debe tener licencia para su uso. Lo mismo ocurre con el MP3: tampoco es un códec libre de regalías. El hecho de que nadie esté debatiendo sobre los códecs de audio en el contexto de HTML5 demuestra lo poco que entienden realmente sobre el contexto las personas que están debatiendo estos asuntos. —Comentario anterior sin firmar añadido por 67.40.16.99 ( discusión ) 20:53, 25 de marzo de 2011 (UTC) [ responder ]

Línea de problemas

H.264/MPEG-4 AVC es ampliamente utilizado y tiene buena velocidad, compresión [...] y calidad de video.

¿Existe alguna fuente para esta afirmación aparte de Apple y TUAW?

Por favor, no me discutas ad hominem por no haber iniciado sesión.

90.201.84.1 (discusión) 18:10 18 nov 2010 (UTC) [ responder ]

H.264/MPEG-4 AVC y patentes

¿Soy yo o estas dos afirmaciones no son compatibles? Según mi interpretación, la primera parece sugerir que el H.264 no está cubierto por patentes.

  1. "Formatos como el H.264 también podrían estar sujetos a patentes desconocidas en principio, pero se han utilizado mucho más ampliamente, por lo que se supone que los propietarios de patentes ya habrían demandado a alguien".
  2. "H.264/MPEG-4 AVC es ampliamente utilizado y tiene buena velocidad, compresión, decodificadores de hardware y calidad de video, pero está cubierto por patentes".

Maxferrario (discusión) 13:27 30 nov 2010 (UTC) [ responder ]

Son compatibles. La primera frase no sugiere que el H.264 no esté cubierto por patentes, sugiere que, al igual que Theora (o cualquier otra cosa), también puede estar cubierto por patentes desconocidas (de terceros), además de las conocidas licenciadas por MPEG LA.— JM ( discusión ) 15:44 30 nov 2010 (UTC) [ responder ]

¿Donde está el video?

Tengo una pregunta sobre la ubicación del video. En nuestro ejemplo...

< video  src = "movie.webm"  poster = "movie.jpg"  controles >Este es un texto de respaldo para mostrar si el navegadorNo admite el elemento de vídeo.</ vídeo >

... parece que movie.webm está en la misma carpeta que la página web que estoy viendo. ¿Esto no genera un problema de seguridad, ya que cualquiera podría descargar el archivo en lugar de simplemente verlo? ¿Hay alguna forma de evitar tal acción? (La misma pregunta para la etiqueta <audio>).

Esto parece relevante cuando se habla de esta tecnología, porque no puedo imaginar que un sitio que transmite audio/video quiera que esos archivos se descarguen. Entonces, en el caso de <audio> y <video>, ¿qué impide que un usuario robe los archivos? — Timneu22  · discusión 14:56, 13 de enero de 2011 (UTC) [ responder ]

¿Dónde está el problema de seguridad? Es sólo un problema de diseño, pero si eres un experto en tecnología sabrás que todo lo que ves en la pantalla se puede capturar... Flash también es sólo un contenedor para dos (¿o tres?) contenedores de vídeo diferentes como h264. Eso significa que tampoco es seguro para descargar. ¿Dónde está el problema ahora? mabdul 17:36, 13 de enero de 2011 (UTC) [ responder ]
Soy consciente de que se puede capturar cualquier cosa que aparezca en una pantalla, pero no la mayoría de la gente. Pero si Netflix utiliza <video> o Pandora utiliza <audio>, ¿no podré simplemente navegar hasta ese directorio y seguir viendo el archivo? Ahora mismo no es tan fácil. Me pregunto sobre la seguridad de estas etiquetas. — Timneu22  · discusión 18:22, 13 de enero de 2011 (UTC) [ responder ]
También podrías robar todas las imágenes de una página web o descargar el código HTML de cada página de acceso público en el sitio. HTML siempre ha hecho que eso sea fácil. Podría descargar fácilmente páginas web de Netflix y crear mi propio sitio que se vea exactamente como Netflix. Sin embargo, no puedo usar esa técnica para robar el video, porque han elegido no usar video HTML5. Si quieres DRM, el video HTML5 no es una opción. Reach Out to the Truth 20:21, 13 de enero de 2011 (UTC) [ responder ]
Ooooh. (Supongo que también funciona para <audio>). Creo que vale la pena mencionarlo en el artículo. Me dedico al desarrollo web y me hicieron creer que <video> y <audio> eran lo mejor que había existido . Si existen limitaciones sobre DRM y demás, creo que vale la pena mencionar una declaración con la fuente en el artículo. — Timneu22  · discusión 20:38, 13 de enero de 2011 (UTC) [ responder ]
Y aquí hay algunos:
  • http://gizmodo.com/5461711/giz-explains-why-html5-isnt-going-to-save-the-internet
  • http://gigaom.com/video/netflix-no-plans-for-html5-video/
  • http://www.pseudocoder.com/archives/why-html5-video-wont-replace-flash
Algunas fuentes... ¡probablemente debería haber buscado en Google antes de iniciar la conversación! — Timneu22  · discusión 20:46, 13 de enero de 2011 (UTC) [ responder ]
No sé qué me quieres decir. Nadie dijo que HTML5 salvará la WEB (no INTERNET); no importa si alguna compañía no planea dar soporte a HTML5 o usa otra tecnología, ni tampoco que HTML5 deba reemplazar a Flash (tienen áreas de trabajo diferentes...), tal vez video flash (ya que todos pueden instalar una extensión/complemento y descargar el video sin restricciones). mabdul 21:40, 13 de enero de 2011 (UTC) [ responder ]
No estoy seguro de lo que estás preguntando o diciendo, o por qué me estás respondiendo específicamente a mí. Creo que es notable que HTML5, si bien es una tecnología "nueva" que permite reproducir videos y audio, carece de características significativas que impiden que los principales sitios web de videos lo utilicen. — Timneu22  · discusión 21:44, 13 de enero de 2011 (UTC) [ responder ]
El sitio de videos más importante lo está usando: Youtube. The Pirate Bay, Archive.org, Wikipedia y otros están planeando o ya están usando HTML5. Nadie dijo que esto (o más bien) es una tecnología nueva. En primer lugar, todos los principales proveedores de navegadores lo estandarizaron y lo mejor es que estas especificaciones son abiertas y gratuitas. Eso es lo nuevo. Para Flash (por ejemplo) ¡hay que pagar! Y DRM (esa es la única característica "que falta") se puede agregar más adelante si estas especificaciones básicas funcionan. mabdul 21:51, 13 de enero de 2011 (UTC) [ responder ]
Bien observado, ¡éste es el quid de la cuestión! De hecho, los proveedores de contenidos que creen que pueden "proteger el contenido" para que no sea consumido de todas las formas que los consumidores deseen, están equivocados.
Teorema: Todo mecanismo de protección de contenidos es una negación de la libertad informática.
Prueba por contradicción: un usuario que tiene control sobre su propia computadora (una necesidad de la libertad informática) puede hacer que su computadora haga todo lo que sea físicamente capaz de hacer, incluyendo modificar el procesamiento del "contenido" de su computadora.
Corolario 1: Mientras cualquiera pueda controlar las computadoras, ningún mecanismo de protección de contenido podrá protegerlas, sólo podrán ofuscarlas/oscurecerlas.
Corolario 2: La protección de contenidos no puede estar contenida en el Software Libre, ya que ello la revelaría. Y si así fuera, se modificaría en beneficio del consumidor y no tendría sentido.
Dado que debería ser posible utilizar software libre, ¡no podemos permitir la protección de contenidos!
129.241.30.137 (discusión) 01:32 14 ene 2011 (UTC) [ responder ]

Google Chrome versión 10 y H.264

Hola, estoy un poco confundido sobre qué hacer. Varias fuentes ([2] [3] [4]) informan que la versión 10 de Google Chrome no tiene soporte para H.264. En otras palabras, en un Google Chrome lanzado recientemente, se eliminó la compatibilidad con H.264. Sin embargo, cuando ejecuto la prueba de HTML5 y la página de compatibilidad de formatos de video de Microsoft en Google Chrome 10 en mi computadora de casa (Linux o Windows), veo que hay compatibilidad con HTML5. Me resulta difícil seguir las fuentes cuando veo evidencia tan clara de lo contrario. ¿Sugerencias? ~a ( usuario • discusión • contribuciones ) 05:16, 22 de marzo de 2011 (UTC) [ responder ]

Google ha anunciado la eliminación, pero no la ha llevado a cabo todavía a partir de la versión 12. Las fuentes que afirman que la eliminación se produjo justo en el momento del anuncio están equivocadas. Hsivonen ( discusión ) 14:58 2 may 2011 (UTC) [ responder ]
Seguro que sí. Acabo de configurar un h264 en un contenedor mkv y Chrome lo reprodujo. Es necesario aclarar que aún no se ha eliminado. — Comentario anterior sin firmar añadido por 24.141.219.11 (discusión) 22:49, 13 de enero de 2012 (UTC)[ responder ]

Falta: Descripción general de las funciones admitidas y comparación con Flash/Silverlight/Java

Este artículo se centra únicamente en el debate sobre los formatos y códecs de vídeo. Lo que hace falta es una descripción general que enumere las características que SÍ se admiten explícitamente y las características que faltan pero que están presentes en los entornos de ejecución de aplicaciones web propietarios, como Silverlight, Flash y Java. Por ejemplo: transmisión RTSP, transmisión adaptativa HTTP, transmisión en directo, protección DRM, listas de reproducción del lado del cliente, extensibilidad de transporte/formato personalizado: todos estos son ejemplos de características de medios estándar que faltan en la especificación HTML5. ¿Por qué nadie habla de ellas? —Comentario anterior sin firmar añadido por 67.40.16.99 ( discusión ) 21:08, 25 de marzo de 2011 (UTC) [ responder ]

Porque no vivimos en Redmond, Washington. En serio: si tienes un conflicto de intereses, quizás quieras hacerlo saber. En cuanto al contenido de tu mensaje: algunas de estas cosas no se discuten aquí porque en gran medida no son importantes. El DRM como ejemplo: los usuarios no están pidiendo más DRM en sus estándares abiertos. ¿Cómo funcionaría el DRM en un estándar abierto? Estoy bastante seguro de que el DRM depende de un cierto nivel de secreto en cuanto a cómo se pasan las claves. Esto parece incompatible con un estándar abierto. ~a ( usuario • discusión • contribuciones ) 09:09, 30 de marzo de 2011 (UTC) [ responder ]

Eliminar la columna "Otros" de la tabla de formato

A todos los efectos prácticos, los formatos que resultan de interés en el contexto del vídeo HTML5 son WebM, Theora y H.264. En la práctica, no se utilizan otros formatos debido a que su interoperabilidad es peor que la de los tres formatos mencionados específicamente. Creo que la columna "Otros" de la tabla no aporta ningún valor real al lector y que eliminar la columna de la tabla haría que el artículo fuera más claro. Hsivonen ( discusión ) 15:02 2 may 2011 (UTC) [ responder ]

Complementos Flash preinstalados

"...muchos navegadores web tienen el Flash Player de Adobe preinstalado...". Esto es un poco engañoso. La mayoría de los navegadores no tienen el reproductor preinstalado. Lo he reformulado basándome en la página de Adobe Flash Player. —Comentario anterior sin firmar añadido por Laptcd (discusión • contribs ) 17:14, 23 de mayo de 2011 (UTC) [ responder ]

Eventos futuros

Varios editores (generalmente IPs) añaden constantemente a la tabla los "X planeados" (a saber, soporte h264 para Firefox y eliminación h264 para Chrome). Como no hay fechas establecidas, tales añadidos violan abiertamente WP:CRYSTAL . Por favor, anoten sólo los eventos que ya ocurrieron. — Dmitrij D. Czarkoff ( discusión ) 13:44 8 abr 2012 (UTC) [ responder ]

¿Qué pasa con los anuncios?

Si <video> se convierte en algo como <img> y todo el mundo deja de usar Flash, ¿los usuarios finales tendrían un "derecho digital" a poder detener la descarga de un anuncio de vídeo HTML5 mediante un menú contextual? — Comentario anterior sin firmar añadido por 184.21.215.174 ( discusión ) 07:44, 6 de septiembre de 2012 (UTC) [ responder ]

Correcto. La apertura fundamental que sustenta cada estándar web (al menos los creados por IETF, W3C, etc.) tiene como objetivo proteger su derecho a "controlar su computación", como diría Richard Stallman, y "ser dueño de sus datos", como diría Håkon Wium Lie. Esa es la regla de la web: nadie nunca tuvo el derecho de dictar cómo consume los datos que pasan por la red en primer lugar. Flash es una contaminación en ese sentido. -- 84.209.102.192 (discusión) 18:43 15 sep 2012 (UTC) [ responder ]

Tabla compleja

¿Es realmente necesario incluir las últimas versiones de cada navegador en cada sistema operativo? No me parece que sea tan relevante para el tema, pero debe requerir una actualización constante. Además, creo que Safari para Windows debería eliminarse, ya que Apple ya no lo soporta. ¿Son Web, Konqueror y Chromium realmente relevantes para el debate? La cuota de mercado de estos tres, incluso combinados, es minúscula. MatthewHaywood ( discusión ) 11:14 11 sep 2012 (UTC) [ responder ]

No, estos no son los números de versión más recientes ; indican para qué versión es relevante el soporte mostrado.
Los navegadores minoritarios son relevantes para mostrar la amplitud del soporte para HTML5 y eliminar el incentivo/mito de la portabilidad del uso de Flash.
Cuota de mercado: No creería en esas estadísticas, a menos que pudiera verificar la clasificación de los agentes de usuario en cuestión. Como usuario de Konqueror, estoy harto de que me reconozcan incorrectamente como usuario de Safari.
¿Complejo? Yo lo llamaría un poco simplificado, porque no se puede decir en general «este navegador admite ese formato». Depende más que nada de los códecs que vienen con el sistema operativo, algo que esta tabla no logra transmitir. --Anordal ( discusión ) 17:49 15 sep 2012 (UTC) [ responder ]
Agregué específicamente un gráfico con respecto a las cuotas de mercado para mostrar la disponibilidad de formatos por usuario, no por tipo de navegador. Por cierto, Konqueror no se identifica como Safari. —  Dmitrij D. Czarkoff ( discusión • pista ) 18:45, 15 de septiembre de 2012 (UTC) [ responder ]

La fila de Safari para Mac OS X parece ser información completamente falsa que se supone que se aplica a otro lugar. Por ejemplo, la nota de instalación manual o la falta de compatibilidad en la columna h.264 que hace referencia a una cita de WebM. Dasil003 (discusión) 12:44 8 nov 2012 (UTC) [ responder ]

Firefox frente a h.264

FireFox 3.5+ en Windows 7 con el complemento h.264 instalado admite bien el video h.264, incluido el método más común para reproducirlo (probado en http://www.html5rocks.com/en/tutorials/video/basics/)

Mozilla añadirá H264 para Firefox OS y Fennec: "Android 4/4.1: compatibilidad de decodificador de hardware y software para vídeo h.264" https://www.mozilla.org/en-US/mobile/17.0/releasenotes/ En el futuro, podría estar disponible en Mac OS, Windows 7 y Linux (con gtreamer-bad-plugin): https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ https://bugzilla.mozilla.org/show_bug.cgi?id=794282 https://bugzilla.mozilla.org/show_bug.cgi?id=799318 — Comentario anterior sin firmar añadido por 86.64.71.89 (discusión) 13:58, 16 de noviembre de 2012 (UTC) [ responder ]

Es posible habilitar h.264 en Firefox en Linux desde la versión 14. Solo hay que compilarlo con --enable-gstreamer. Pero las compilaciones oficiales aún no lo han habilitado. 194.36.2.117 (discusión) 14:17 18 jun 2013 (UTC) [ responder ]

Compatibilidad con navegadores

No añada sistemas operativos no compatibles a ningún navegador web que no esté realmente presente en el mercado, como FireFox en OS X 10.6 no compatible con una cuota de mercado inferior al 0,01 % en esta combinación. En el mercado hay cientos de navegadores web y miles en combinación con versiones de sistemas operativos, pero la mayoría de ellos tienen una cuota de mercado inmensurable. El objetivo de esta tabla no es imaginar todas las combinaciones posibles de navegadores web y versiones de sistemas operativos, sino solo combinaciones con una cuota de mercado apreciable. — Comentario anterior sin firmar añadido por 217.30.64.202 ( discusión ) 19:35, 10 de septiembre de 2014 (UTC) [ responder ]

HEVC en Android

@ LiberatorG : modificó la tabla para indicar que HEVC no es compatible con Android, y dice "El video HEVC en HTML5 del navegador Android no me funciona. La referencia es para compatibilidad con el sistema operativo, no con el navegador. Cite y especifique la versión del navegador si está disponible". Pero la referencia https://bugs.chromium.org/p/chromium/issues/detail?id=460703 era de hecho para el navegador; dice "Reproducir archivos HEVC mp4 simples en Chrome /Android/Nexus5 funciona bien, por ejemplo, este: http://www.bitmovin.net/hevc/720p.mp4".

Lo probé en mi propio teléfono Nexus 4 y reproduce archivos HEVC vinculados directamente, así como archivos HEVC dentro de una etiqueta de video HTML5. Caso de prueba: https://www.thuejk.dk/hevc.html

Si bien reconozco que no tengo una buena referencia sobre el funcionamiento de hevc en Android ni sé en qué versiones funciona, el "no" general actual es obviamente incorrecto. Jue ( discusión ) 09:25, 22 de marzo de 2016 (UTC) [ responder ]

@ Thue : HEVC es compatible con Android (en 5.0). La fila de la tabla en cuestión no es para el sistema operativo, es para el navegador estándar de Android de AOSP que era el navegador predeterminado al menos en Android 4 y anteriores. No creo que tenga otro nombre que "Navegador", lo que lamentablemente dificulta su discusión. Sé que algunos dispositivos más nuevos con Android 5 han cambiado el navegador predeterminado, por lo que ya ni siquiera se puede llamar navegador predeterminado. El enlace mencionado anteriormente es un comentario del lado de un usuario en un informe de error que habla de un navegador completamente diferente. ¿Probaste con el navegador estándar de AOSP? No pude encontrar ninguna fuente confiable que indique que HEVC es compatible con el navegador estándar de AOSP y encontré muchas afirmaciones de que no es compatible, pero si encuentras una, agrégala junto con el número de versión en la que es compatible. (Usted había dicho "Sí", dando a entender que es compatible con todas las versiones, pero he comprobado que eso no es exacto.) LiberatorG ( discusión ) 18:23 22 mar 2016 (UTC) [ responder ]
Ah, también http://www.bitmovin.net/hevc/720p.mp4 me da error 404. LiberatorG ( discusión ) 18:51 22 mar 2016 (UTC) [ responder ]
@ LiberatorG : Probé el video HTML5/HEVC en un navegador estándar en un Nexus 4 estándar. De hecho, me funcionó. El navegador predeterminado en mi Nexus 4 de marca Google se llama "Chrome", por lo que supongo que es de eso de lo que habla el informe de errores, no de "un navegador completamente diferente" como dices. Y como incluí en el enlace anterior, https://www.thuejk.dk/hevc.html es un caso de prueba de video HTML5 HEVC. Jue ( discusión ) 21:15, 22 de marzo de 2016 (UTC) [ responder ]
@ Thue : Quiero decir que el navegador AOSP llamado "Browser" (nombre del paquete com.android.browser) se basa en el código AOSP https://android.googlesource.com/platform/packages/apps/Browser/, mientras que el navegador Chrome de Android se basa en el código Chromium, por lo que son navegadores completamente diferentes. Sin embargo, debido a que los números de versión de Chrome son mucho más grandes y Chrome admite todos los formatos de video compatibles con el navegador AOSP, no debería haber ningún problema técnico con el uso de la misma fila para ambos siempre que se especifique una versión (no "Sí") y esté claro si cada declaración de compatibilidad incluye el navegador AOSP.
Sin embargo, mi mayor preocupación es que todas las fuentes remotamente oficiales que he encontrado implican que HEVC no es compatible con Chrome, excepto Chromecast. https://www.chromestatus.com/features#video y https://www.chromium.org/audio-video no mencionan HEVC en absoluto, y varias otras fuentes, como los mensajes de confirmación, afirman que no es compatible con Chrome, excepto con Chromecast. Incluso el informe de error al que haces referencia se cerró con el comentario "No tenemos planes de admitir HEVC en Chrome o Chromium". Es interesante que tu prueba, sin embargo, parezca funcionar en tu dispositivo, sin ninguna confirmación que parezca haberlo habilitado intencionalmente, lo que plantea la pregunta de si realmente es compatible o solo es experimental, tal vez con problemas que no se pueden solucionar fácilmente, o solo se habilita en algunos dispositivos o para algunos propósitos restringidos. Eso podría dar lugar a una publicación de blog interesante, pero va en contra de WP:OR . LiberatorG ( discusión ) 10:56, 23 de marzo de 2016 (UTC) [ responder ]
Bueno, el "no" que escribiste también va en contra de WP:OR. Jue ( discusión ) 11:05 23 mar 2016 (UTC) [ responder ]
Las páginas oficiales que enumeran los códecs compatibles son una fuente confiable y no incluyen HEVC. LiberatorG ( discusión ) 11:10 23 mar 2016 (UTC) [ responder ]

¿Deberíamos incluir los complementos en la tabla?

Respecto a esta edición (fue deshecha y luego rehecha por mí).

No estoy de acuerdo con que debamos incluir complementos en esta tabla. Si lo hiciéramos, podríamos completar todos los campos de Internet Explorer, Safari, Konqueror y los navegadores web con "A través de un complemento", ya que (por ejemplo) el complemento VLC admite todos los formatos de video enumerados.

OpenCodecs (para Internet Explorer en Windows) y Xiph QuickTime Components (para Safari en macOS) son un poco diferentes, ya que proporcionan los códecs a nivel del sistema operativo, pero tal vez también deberían eliminarse.

Lonaowna ( discusión ) 10:20 15 sep 2017 (UTC) [ responder ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de modificar 3 enlaces externos en un video HTML5 . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.

Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— InternetArchiveBot ( Reportar error ) 15:06, 27 de octubre de 2017 (UTC) [ responder ]

VP9 en formato MP4

Me pregunto por qué la gente piensa que VP9 no es compatible con MP4. ¿Por qué tengo que deshacer la edición que hice del artículo? — Comentario anterior sin firmar añadido por 93.153.138.62 ( discusión ) 09:13, 2 de noviembre de 2017 (UTC) [ responder ]

Hola.
Me pregunto qué te hace pensar que es compatible. ¿Podrías explicarnos algo?
Un cordial saludo,
Codename Lisa ( discusión ) 09:11 3 nov 2017 (UTC) [ responder ]
Hola.
¿Por casualidad te banearon de Google? Me pregunto.
Todo el mundo sabe que se apoya. Es de conocimiento público. — Comentario anterior sin firmar añadido por 93.153.138.62 ( discusión ) 08:27, 8 de noviembre de 2017 (UTC) [ responder ]
Hola
La carga de la prueba recae sobre la persona que afirma algo como un hecho . Todos los días, cientos de personas hacen afirmaciones descabelladas en Wikipedia. La mayoría de ellas son errores. Un pequeño porcentaje son mentiras descaradas. Un porcentaje aún menor son verdad.
La mayoría de los editores piden dinero para publicar lo que usted cree que es verdad. Wikipedia pide algo más: pruebas, en forma de fuentes confiables .
Un cordial saludo,
Codename Lisa ( discusión ) 09:27 8 nov 2017 (UTC) [ responder ]
Por lo tanto, los sitios web no son prueba suficiente para usted. https://www.google.ru/search?q=vp9+bmff
Entonces probablemente deberíamos esperar a que se publique un libro sobre este tema.
Al menos ahora entiendo por qué este artículo está desactualizado. — Comentario anterior sin firmar añadido por 93.153.138.62 ( discusión ) 10:26 8 nov 2017 (UTC) [ responder ]
Hola de nuevo
Algunos de los resultados de su búsqueda demuestran intentos de implementar VP9 en MP4. Puedo abrir www.chromestatus.com/feature/5762080762232832 en un par de navegadores web y ver si esos navegadores admiten VP9 en MP4, pero si alguien me pide una prueba de que efectivamente lo hice, en forma de una fuente confiable, no tengo ninguna. Alguien que haya realizado esta prueba primero debe publicar los resultados, luego podemos citar esa publicación.
Un cordial saludo,
Codename Lisa ( discusión ) 12:08 8 nov 2017 (UTC) [ responder ]