HTML5, la etiqueta video y la maldición de los códecs

Que levanten la mano las personas que han intentado ver un vídeo en un ordenador y se han llevado la sorpresa de «se oye, pero no se ve». «Mierda, los putos códecs, ¿cómo se llamaba el pack ese que me dijeron…»

Acabo de leer un artículo muy interesante que trata precisamente de esto mismo: los códecs, pero en un contexto mucho más grande: la web. Como sabéis, el futuro estándar HTML5 posee una nueva etiqueta <video /> que permitirá añadir vídeos fácilmente a las webs como lo hacemos ahora mismo con la etiqueta <img /> por ejemplo.

¿Qué podría permitir esto? Que Youtube no use Flash en sus reproductores o que DailyMotion haga lo mismo. ¿Habéis visitado las páginas? ¿No? Hacedlo. Visitad la primera con Firefox y la segunda con Safari (con Quicktime instalado). Ahora haced lo contrario. La primera con Safari y la segunda con Firefox.

¿Ya? Vale, ¿habéis visto lo que pasa? ¿Que Youtube sólo funciona con Safari + Quicktime pero no con Firefox y que DailyMotion sólo con Firefox y no con Safari?. Pues eso mismo es lo que os pasaba en los ordenadores de los demás: CÓDECS.

Analicemos la situación. Esta versión de prueba de Youtube que sólo utiliza etiquetas válidas de HTML5 hace uso de la etiqueta <video />, pero el pequeño problema es que HTML5 quitó qué códecs usar por defecto. Empezaron con OGG/Theora, pero se desechó esa opción (cualquier compañía grande ha creado su estándar cerrado y con patentes de vídeo: Microsoft WMV, Apple con h.264…). Así que cada uno puede elegir qué códec utilizar, y claro, ahí ya dependes de plugins exteriores para cargar el vídeo o bien de internos… pero un navegador no puede ser un VLC en potencia. Lo mismo que pasa ahora con los objetos flash, que dependemos del Plugin Flash (instalado casi de facto en todos los ordenadores).

Bien, así que Youtube usa un formato que DailyMotion no, porque Firefox no funciona en Youtube pero sí en este último.

Esta versión de prueba de Youtube usa vídeos en MP4, un formato con licencias, no libre, por el que hay que pagar patentes o canon para poder crear un reproductor o para utilizar las librerías para codificar/decodificar… (es más, cuando eliges un vídeo en Youtube en alta definición realmente estás eligiendo el vídeo en MP4 aunque sea Flash realmente el reproductor/decodificador). DailyMotion de hecho ha firmado un acuerdo con Mozilla para pasar sus vídeos al formato libre OGG/Theora (que hoy por hoy da menos calidad que el MP4, todo hay que decirlo) para que se use un formato de vídeo libre, estándar y sin patentes, por eso se puede ver sin ningún tipo de códec externo y todo de forma transparente al usuario.

Si os habéis fijado, el HTML5 está de moda, el <video /> está de moda… wait… ¿de qué navegadores estamos hablando? Safari y Firefox. Un 30% de cuota de mercado. ¿Quién sigue teniendo el 70% restante? ¿Alguien se cree que en un periodo razonable de tiempo (¿1 año?) Microsoft va a ser capaz de adaptar su navegador a los nuevos estándares propuestos por el grupo que desarrolla HTML5? Es más, ¿creéis que va a aceptar que se use un formato abierto cuando ellos tienen un formato propietario, licencias de por medio, con DRM llamado Windows Media Video?

Como acaba rezando el artículo <video /> es un gran avance, pero estarán durante mucho, mucho, mucho tiempo los reproductores Flash de por medio, comiéndonos los recursos de la CPU hasta que por lo menos Adobe decida optimizarlo o bien Microsoft se decida a usar <video />

Lo bueno es que Chrome ha decidido unirse a los navegadores (Firefox sólo por ahora) para soportar el formato OGG/Theora en su próxima versión, la 3.0. Ojalá dejemos de depender de formatos propietarios y lentos…

Actualización: Se me olvidaba comentar que hubo un excelente debate en Slashdot acerca de si HTML5 sustituirá a Flash como reproductor de vídeo. No os lo perdáis.

Actualización2: Me comenta Julen, que Opera también soporta la etiqueta <video /> desde ¡Noviembre de 2007! Incluso en sus últimas versiones estables. Además vía OGG/Theora como Firefox y en un futuro Google Chrome. Muy interesante

Prism, un Fluid multiplataforma

En mi último post hablaba acerca de por qué usaba Fluid, que recuerdo es una aplicación para crear aplicaciones web como escritorio (por ejemplo usar GMail como un cliente de correo desde el escritorio, o Google Reader, Tuenti, Facebook…).

Pues bien, ayer mismo salía a la luz una nueva versión de Prism (no definitiva, pero de ahí la podéis descargar), el cliente de la Fundación Mozilla que en un principio había descartado porque usaba una versión vieja del motor Gecko y era más lenta que Fluid.

Y esta nueva versión está basada en la rama 1.9, por lo que está equiparada con Firefox 3, pero esto sigue haciéndola menos compatible con los estándares que Safari 4 y, por extensión, Fluid. El motor Javascript también es más lento en teoría, ya que en la rama 1.9 de Gecko no está implementado Tracemonkey, algo que sí va a estar en la versión 1.9.1, sobre la que funcionará Firefox 3.5.

Pero, ¿vale la pena esta nueva versión de Prism? Y mi respuesta es un tajante y rotundo SÍ.

En primer lugar como aplicación autónoma, ya que es compatible con todos los sistemas y plataformas donde Firefox 3.0 funciona, ya que ambos están basados en Gecko. Fluid es sólo para MacOS X (donde todos sabemos que las aplicaciones están muy pulidas y optimizadas para los 4 procesadores, 4 tarjetas gráficas que utiliza Apple y punto).

Pero es que Prism me ha impresionado, no sólo porque su velocidad en MacOS X es más rápida que el propio Fluid, si no que además al ser multiplataforma puedo compartir mis aplicaciones web-escritorio con todo el mundo sin necesidad de hacer ni un solo cambio, por lo que los usuarios de Windows y de Linux también se benefician de estas mejoras.

Pero es que Prism, como aplicación independiente, está basado en Firefox 3.0, pero no es lo único que tenemos, si no que hay una extensión para Firefox 3.0 y 3.5 que utiliza el propio navegador como motor de renderizado. Y es increíble.

Si ya de por sí Prism como aplicación estándar tarda casi un segundo menos que Fluid en cargar GMail (Prism 3 segundos, Fluid unos 4), Refractor, la extensión para Firefox es increíble. Obviamente depende en qué versión de navegador lo instales, si es en un Firefox 3.0 tendrás la misma velocidad que Firefox 3.0 (o sea, igual que Prism), pero si lo instalas en Firefox 3.5 beta 4… lo gozas. Casi un segundo más rápido que Firefox 3.0 en cargar, debido, sobre todo, a Tracemonkey, ese gran, grandísimo motor Javascript escrito por la fundación Mozilla y los colaboradores. Clic en el enlace directo de Gmail, ventana, cargando…, ya tienes tu correo. En dos segundos desde que pincho en el icono, tengo todo mi correo web. Y usando sólamente 45 megas de memoria (no puedo comparar con Mail.app o con Thunderbird 3 beta porque tienen más cosas).

Como digo, estas aplicaciones son perfectas para personas que utilicen mucho páginas recargadas de Javascript, quieran tener perfectamente en forma su navegador y no quieran ver cómo tienen que poner otro giga de RAM sólo para navegar por internet.

Las dos principales desventajas de Prism es que (en MacOS X) no permite el uso de archivos de iconos .icns por lo que o bien usamos una imagen PNG para los enlaces directos o bien el favicon de la página, que suele tener tan poca resolución que es mejor ni ponerlo (he abierto un bug en Bugzilla acerca del uso de archivos icns en Mac, ya que si se edita internamente la aplicación se pueden usar sin problemas). El otro problema es que no tiene reconocimiento de páginas web muy populares. Así como en Fluid yo tenía abierto mi GMail y me mostraba en el icono los correos que tenía sin leer, Prism no. Igual es porque es mucho más genérico que Fluid, pero estaría bastante bien que la API permitiera hacer cositas de estas: modificar iconos al vuelo, tener patrones para hacer acciones…

Lo dicho, si queréis echarle un vistazo y probarla, en esta página tenéis las descargas de Fluid para los 3 grandes sistemas y la extensión para Firefox para Mac y Windows (para Linux aún no disponible debido al bug 436998).

Además intentaré hacer algunas webapps para alguna de las páginas más usadas en España, o por lo menos las que yo creo que se usan más.

video tag, Dreamhost and Firefox 3.5

I’m copy-pasting a blog post from blizzard, as we had a conversation on IRC about using the video tag on Firefox and Dreamhost hosting (due a problem with my other blog (in Spanish)):

A quick note if you’re going to be using OGG open web video hosted on web servers. There’s an important configuration change that you should make so that Firefox recognizes it as video. In my Apache configuration I’ve added this directive:

AddType application/ogg .ogg
AddType application/ogg .ogx AddType video/ogg .ogv
AddType audio/ogg .oga

Most web servers are likely to return the mime type as “text/plain” which Mozilla will not show as video. If you don’t set it, and it’s served up as text/plain then Firefox is likely to show either an error or endless buffering. (Although I suspect that the endless buffering is actually a bug in our internal player and will likely be fixed.)

Update 2: You should look at this post from Silvia for the correct information. Thanks, Frank.

Anyway, you should follow the original post, as it could be updated since the publish of this post.

And I have sent an email to Dreamhost support to get a global support for .ogv files. I will post the decision as soon as I’m getting the answer.