Google confirmó ayer los rumores de las últimas semanas anunciando un nuevo formato de vídeo de código abierto denominado WebM basando en el codec VP8 que la compañía adquirió el pasado año, el contenedor de Matroska y el audio Ogg Vorbis. El nuevo formato se ofrece bajo una licencia tipo BSD sin coste alguno y algunas compañías como Mozilla, Opera, Adobe o Nvidia ya han anunciado su apoyo al mismo y parece que Microsoft lo soportará en Internet Explorer aunque a diferencia del H.264 serán los usuarios lo que tengan que instalarlo.
Tanto Apple como Intel permanecen calladas por el momento mientras que Google, por supuesto, apoyará el WebM con Chrome y YouTube. El popular servicio de vídeos recodificará todos sus contenidos al nuevo formato, manteniendo el soporte a H.264 de forma paralela para no dejar en la estacada a, entre otros, los dispositivos móviles de Apple, el iPhone, el iPod touch y el iPad.
Nuestros compañeros de Genbeta se muestran muy optimistas con el WebM y motivos no les faltan. Google + Youtube + formato de vídeo gratuito de código abierto es un caballo ganador realmente obvio que podría imponerse como el santo grial del HTML5 y no sería de extrañar que la propia Apple terminase subiéndose al carro soportándolo también en Safari. Sin embargo, la carrera por el formato de vídeo de la web está lejos de terminar.
Jason Garrett-Glaser (también conocido como Dark Shikari), un desarrollador independiente que trabaja en el proyecto de código abierto x264 (que codifica vídeo H.264), asegura haber accedido a las especificaciones del nuevo codec, su código fuente y el software que Google ha presentado para facilitar el desarrollo y adopción del formato días antes de su presentación oficial, lo que le ha permitido realizar un detallado análisis técnico justo a tiempo para este anuncio que pone de manifiesto las carencias y problemas que plantea WebM en tres áreas diferenciadas: la especificación del formato, su implementación y el monstruo de las patentes.
WebM, la especificación es un desastre
Según Garrett-Glaser, la especificación consiste en un masivo copia y pega del código fuente del VP8, incluyendo TODOs, “optimizaciones” e incluso hacks específicos del lenguaje C, haciéndola realmente difícil de comprender en bastantes áreas.
“Puedo haberme quejado acerca de que la especificación H.264 sea excesivamente abundante y copiosa en palabras, pero al menos es precisa. En comparación, la especificación VP8 es imprecisa, poco clara, demasiado corta, dejando muchas partes del formato vagamente explicadas. En algunas partes incluso se llega a negar expresamente a explicar alguna característica concreta de forma completa, apuntando a alguna referencia en el código altamente optimizada y prácticamente imposible de entender como explicación. No hay una maldita forma de que nadie pueda escribir un decodificador utilizando únicamente esta especificación.”
El desarrollador también recuerda que la afirmación realizada por On2, los creadores originales del VP8, de que su codec fuese un 50% mejor que el H.264 no puede tomarse en serio y que en el pasado se han caracterizado por lanzar toda clase de absurdas afirmaciones sin llegar a aportar nunca una prueba con la que apoyarlas. Por ejemplo, el VP7 era supuestamente un 15% mejor que el H.264 y aunque resultó ser muy rápido, no llegó a igualar la velocidad y calidad de este último. Volviendo al WebM/VP8, su especificación puede ser un poco mejor que el perfil base del H.264 pero ni se acerca a los perfiles de mayor calidad. “Si Google está dispuesta a revisar las especificaciones, esto probablemente pueda ser mejorado.”
La implementación es un desastre
Al margen de lo buena que sea una especificación, no menos importante es lo buena que sea su implementación. “¿O va a pasar lo mismo que con el VP3, con el que On2 lanzó una inusualmente mala implementación con la esperanza de que la comunidad la corrigiese por ellos? Esperemos que no; ¡llevó seis años solucionar los problemas de Theora!” Garrett-Glaser se lanza a un análisis demasiado profundo como para que los profanos podamos comprenderlo aunque sí deja varias conclusiones acerca de las limitaciones de su diseño y las preocupantes similitudes que guarda con el H.264:
“Es algo a medio camino entre Xvid y el VC-1 de Microsoft en términos de calidad de imagen. Definitivamente puede mejorarse aún un montón, pero no a través de los medios convencionales. (...) Como decodificador es aún más lento que el H.264 en ffmpeg y probablemente no pueda mejorarse demasiado. (...) Copia demasiado de H.264 como para que nadie con dos dedos de frente no se sienta incómodo con él; no importa que de palabra se esconda tras la pretensión de ser libre de patentes. (...) No está listo para el gran público; la especificación es un montón de código C copiado y pegado y la interface del codificador está falto de muchas funciones y plagado de errores. (...) A falta de una especificación real, básicamente su implementación es en sí misma la especificación, y al definir esta como “definitiva”, cualquier error existente queda grabado ahora en piedra. Muchos de estos errores se han encontrado ya y Google se ha negado a solucionarlos.”
Peligro, patentes
Aún así, Garrett-Glaser también cree que como compresor, el nuevo codec es definitivamente mejor que Theora y Dirac, constituyendo una mejora en lo que a formatos de video libres de patentes se refiere. ¿El problema? Que aunque venga avalado por Google no hay garantías de que no terminen apareciendo un buen número de compañías reclamando los derechos de sus propiedades intelectuales, especialmente si se confirma que hay tantos parecidos con el H.264.
Y si no que le pregunten a Microsoft. Pocos años atrás, la compañía lanzó VC-1, un codec que también afirmaba estar libre de patentes y que se utilizaría extensamente en Windows Media Video 9 primero, y en el ya difunto HD-DVD después. Apenas unos meses después de su lanzamiento, una piara de compañías solicitaron sus patentes y al final terminó formándose un “pool de patentes” (una sociedad que gestiona y controla la tecnología que implica a varias compañías, como por ejemplo, la MPEG LA del H.264).
Yo por mi parte apuesto a que Apple mantendrá la misma postura neutral que suele tomar ante estas situaciones, y aunque permitirá que instalemos el códec a través de plugins como Perian, no lo adoptará a menos que no se vea completamente obligada a ello. Tendremos que esperar a ver si Google es capaz de solucionar las carencias del codec y hacer que los fabricantes de chips empiecen a soportarlo rápidamente mientras se compromete a indemnizar a sus socios de los posibles ataques de patentes.
Vía | Genbeta y Appleinsider
Sitio oficial | WebM Project
Ver 74 comentarios