Con la finalidad de evitarse un problema  que se estaba gestando, Google decidió separar la parte que garantiza la patente de la licencia de copyright. Así la compañía logra refugiarse en una licencia BSD (Apache y GPLv3).

De esta manera lo que se crea es una licencia BSD que contiene tres cláusulas y cuenta con la venia de la OSI, lo que garantiza que independientemente de las demandas que se puedan presentar, el proyecto WebM podrá seguir adelante.

Link: Changes to the WebM Open Source License (WebM Project)

(cc) Gregory Maxwell

El fin de semana les contamos sobre la advertencia planteada por Steve Jobs respecto a que se estaba gestando una posible demanda en contra de Theora y otros codecs que se denominan de “código abierto”, debido a que todos ellos estaban protegidos por diversas patentes.

Luego de un par de días de silencio Gregory Maxwell (Desarrollador en Jefe de la organización Xiph.org, creadores del contenedor OGG, del codec de audio Vorbis y de Theora), salió a tranquilizar las aguas mostrando su extrañeza ante las supuestas palabras de Jobs (incluso especula sobre la posibilidad de que otra persona lo haya suplantado).

Es en la lista de correos de Theora en donde Maxwell se explaya señalando que difícilmente se podría estar gestando una especie de asociación que busque demandar a un tercero, sin siquiera tomarse la molestia de contactarlos para hablar del tema.

Para Maxwell el hecho de que nadie los contactara lo lleva a concluir que no se esta gestando una demanda en contra de ellos, por lo que las supuestas palabras de Jobs podrían ser producto de una suplantación de su persona o un malentendido. Termina su comentario dando a entender que incluso estas declaraciones podrían ser creadas de manera artificial por los propietarios de codecs licenciados, con el objeto de sembrar un manto de dudas respecto a tecnologías que son competencia y cuya finalidad es interferir en su desarrollo a futuro.

Link: [theora] Steve Jobs about theora (Vía CHW)

(c) developer.mozilla.org

La actual discusión por el uso de codecs de video libres en Internet podría terminar en los tribunales, así por lo menos lo adelanta Steve Jobs en respuesta a una carta abierta publicada por Hugo Roy de la Free Software Foundation.

En su carta Roy analiza las palabras expresadas por Jobs en relación a la tecnología Flash, dando a entender que uno de los motivos por los cuales su compañía no adoptaba Flash era porque esta tecnología era 100% propietaria.

Roy en cierta manera le encuentra razón a Jobs en este punto en particular, pero a su vez le recuerda que Apple utiliza el codec H.264 para la reproducción de videos, siendo que este exige el pago de royalties a quienes deseen implementarlo en sus aplicaciones. Esta opción es contraria a la que adoptaron tanto Mozilla Firefox como Opera, quienes optaron por ocupar el codec Theora por ser de código abierto y libre de patentes.

La respuesta de Jobs no se hizo esperar y vino acompañada de un golpe directo al mentón:

Todos los codecs de vídeo están protegidos por patentes. Se esta formando un consorcio de patentes que irá tras Theora y otros ‘codecs abiertos’. Por desgracia, sólo porque algo es de código abierto no significa ni garantiza que no se infringen las patentes de otros. Un estándar abierto difiere de ser libre de derechos o de código abierto

A nadie debería extrañarle que uno de los integrantes de dicho consorcio sea Apple, ya que esta compañía se relaciona con la MPEG-LA que viene amenazando con presentar demandas contra varios codecs que se llaman “abiertos” desde hace tiempo.

Tendremos que ver si las palabras de Jobs se convierten en realidad, con seguridad podría convertirse en una de las batallas legales más interesantes de los últimos tiempos.

Link: Updated: MPEG LA Pool Planning to Torpedo OGG Theora, Says Jobs (Vía CHW)

El mes pasado nuestro guía espiritual editorial Felipe Figueroa, nos relataba la soterrada lucha existente para definir un formato de video estándar para ser utilizado en la red.

Ahora es la Free Software Foundation (FSF) la que sale al baile publicando una carta abierta, en donde le solicita a Google que libere el códec VP8 bajo una licencia abierta y que lo utilice en YouTube con la finalidad que se convierta en un estándar libre de video.

Recordemos que Google adquirió On2 (propietaria del códec VP8), pero desde hace un tiempo que experimenta video HTML5 con el códec H.264.

En su carta la FSF señala que Google tiene la oportunidad de liberar a la web de formatos propietarios (como es el caso de Flash y el mismo H.264). Para ello debe dotar a VP8 de una licencia abierta y libre de royalties. Agrega que Google posee la suficiente influencia para convertir dicho formato libre en un estándar global, sólo con integrarlo a su servicio de video YouTube.

Estaremos atentos a la respuesta de Google.

Link: Open letter to Google: free VP8, and use it on YouTube (FSF)

(cc) by Alexander Grundner

Recientemente y después de mucho tiempo sin mayores novedades, se liberó la version 0.5 del set de codecs y utilidades de audio y video FFmpeg.  Este proyecto de código abierto es el que está detras de los sistemas de audio y video en Linux como mplayer/mencoder y gstreamer, y también está disponible para sistemas Unix como ffmpegX en Mac OSX.

Esta versión nos trae el soporte para VDPAU, nuevos codecs, varias correcciones y muchas otras mejoras. Todo esto lleva a preguntarse que otras proyecciones podría tener el proyecto y entre ellas si veremos un adecuado soporte Blu-ray o si vendría en un futuro cercano una versión 1.0.

El sitio Phoronix realizó una entrevista a los desarrolladores de FFmpeg para despejar estas interrogantes, y la hemos separado en dos partes para que no se pierdan los detalles.  Aqui va nuestra primera entrega.

A continuación una breve presentación de las víctimas:

• Diego Biurrun originalmente comenzó a trabajar en Mplayer, pero actualmente desarrolla FFmpeg. Es responsable de mantención del código, manejo de asuntos jurídicos y otras tareas de organización. Diego se incorporó haciéndose cargo de la posición de Release Manager en la versión 0.5.
• Coudurier Baptiste descubrió FFmpeg hace tres años y cuando se dió cuenta de que era el mejor conjunto de herramientas para multimedia en Linux comenzó por corregir errores al azar.  Rápidamente se convirtió en el mantenedor del código que maneja a QuickTime, y es considerdo como el salvador del soporte de MOV/MP4 en FFmpeg.
• Robert Swain se aventuró en iniciar el desarrollo de software libre de multimedia a través de la actualización de los codecs de Xvid y X.264, y más tarde en FFmpeg.  Luego se decidió continuar sólo con FFmpeg, interesándose particularmente en facilitar su uso. Robert es también es el mantenedor del decodificador AAC de FFmpeg y anteriormente participó en el proyecto como parte del programa Google Summer of Code.

El lanzamiento de la versión 0.5

El ChangeLog de esta versión tiene más de 150 cambios y la lista sigue creciendo.  En los últimos dos años siempre se dijo a los que quisieran usar el proyecto FFmpeg que lo descargaran directamente desde el repositorio SVN en donde se encuentra el código fuente, sin tener un release oficial. ¿Qué motivó a los desarrolladores de FFmpeg a liberar una nueva versión? Diego explica que fueron bombardeados con solicitudes para hacer una presentación oficial, pero ninguno tenía la suficiente motivación y apuro para organizar la liberación de esta versión de FFmpeg. En última instancia Diego decide tomar las riendas y logra la liberación de FFmpeg 0.5 actuando como Release Manager.  En el futuro estiman que el proyecto se moverá en ciclos de lanzamiento entre tres y seis meses, de una forma similar a los ciclos que se están usando con éxito en otros proyectos importantes como es el caso del escritorio GNOME y distribuciones de Linux como Ubuntu y Fedora.

El camino a FFmpeg 1.0

Con el característico toque de humor de los proyectos de código abierto, la versión 0.5 ha recibido el nombre clave de “half-way to world domination A.K.A. the belligerent blue bikeshed“, que en Chile se podría traducir como “medio camino a la dominación mundial, también conocido como la beligerante mocha azul“.

Al ser preguntados sobre cuanto tiempo de trabajo queda para ver FFmpeg 1.0, Diego dice que el término 1.0 está demasiado idealizado y no cree en los roadmaps o en los planes de liberación tipo old-school, prefiere el enfoque de release basado en el tiempo como lo están haciendo muchos, por lo que lo que sería una versión 1.0 aun está en el misterio.

Lo que se encuentra hoy en SVN, que fue la base de la liberación de la versión 0.5, fue la eliminación de APIs obsoletas, donde se está trabajando para sustituirlas. Los desarrolladores tienen también la esperanza de tener mas optimizaciones y mejoras en la documentación en un futuro próximo. En camino en este momento viene el soporte de codecs para TwinVQ, WMA9, HE-AAC y AMR.  Este último es muy utilizado en los equipos móviles, por ejemplo cuando se graba un video con el teléfono celular.

Baptiste está especialmente interesado en que el ambito de aplicación de FFmpeg se amplie dando soporte a formatos y codecs utilizados en el campo profesional como son MXF, GXF y D-10 relacionados con SMPTE y DNxHD de Avid.

Blu-ray en Linux

Las películas Blu-ray ahora se pueden reproducir en Linux, pero no existe mucho soporte y exige mucha intervención manual. Por ejemplo si el disco Blu-Ray tiene DRM, el usuario debe instalar una utilidad y aplicar otras medidas para ver una película que fue comprada en forma legítima, y cuando tienen audio en formato DTS-HD MA simplemente no funciona. Hace algunos meses había algo de código propuesto para resolver parcialmente este problema en FFmpeg, pero más tarde fue rechazado. Ninguno de los entrevistados tiene equipos con Blu-Ray por lo que no tienen un interés personal en este tema, Diego reiteró que esta interesado en el soporte a “todo formato bajo el sol, ciertamente Blu-Ray”, pero no se acepta cualquier parche y se rechazan aquellos que tienen problemas técnicos. Los tres desarrolladores están de acuerdo en que el soporte Blu-Ray aparecerá en FFmpeg, pero no están seguros de cuando estará disponible para que todos lo puedan usar en forma decente.

OpenCL y GPGPU

Después de hablar acerca de Blu-Ray, la discusión se dirigió a un nuevo estándar llamado Open Computing Language (OpenCL). Se trata de un nuevo lenguaje estándar de programación paralela dirigido a la GPGPU (programación de propósito general en procesadores gráficos). Tanto Nvidia, ATI/AMD e Intel, están trabajando para hacer que su hardware y drivers sean compatibles con Open CL, lo que transformará a sus procesadores gráficos en potentes procesadores que puedan correr código OpenCL. Con el soporte de GPGPU por medio de OpenCL, la codificación y decodificación de audio/vdeo se podrá hacer mucho mas rápido en estos procesadores. De todas formas confiesan que desconocen si hay alguien ya trabajando en estos temas, y mencionan que tanto OpenCL como el esfuerzo de Nvidia llamado Compute Unified Device Architecure CUDA (Arquitectura de dispositivo de computo unificada) son interesantes y tienen mucho potencial.

Conscientes de que tanto material es dificil de masticar, dejaremos para una segunda entrega el resto de la entrevista en donde se tocan otros temas como : VDPAU, VA-API y XvBA, nuevos codecs, aspectos legales y los desafíos que enfrenta este proyecto tan importante.

Link: An interview with the developers of FFmpeg (Phoronix.com)