Nuevo SDK para VP8: “Bali”, más rápido
El blog del proyecto WebM ha anunciado una versión actualizada del SDK para el códec de vídeo VP8 que ha sido bautizado con el nombre en clave “Bali“. Esta versión está centrada en acelerar el proceso de compresión de vídeo y hacerlo mejorando también la calidad del vídeo.
Comparado con la versión lanzada inicialmente (19 de mayo de 2010) y con la anterior versión con nombre en clave Aylesbury (28 de octubre de 2010) la nueva versión Bali dispone de las siguientes mejoras:
- Velocidad de compresión para el modo “Best”: en procesadores x86, Bali se ejecuta 4,5 veces más rápido que nuestra versión inicial y 1,35 veces más rápido que Aylesbury.
- Velocidad de compresión para el modo “Good”: Bali es 2,7 veces más rápido que la primera versión y 1,4 veces más rápido que Aylesbury.
- En plataformas ARM con extensiones Neon, la compresión en tiempo real de contenidos de telefonía de vídeo es un 7% más rápido que Aylesburyen un ARM Cortex A9 con un núcleo, mientras que es un 15% en un A9 dual-core y un 26% más rápido en micros quad-core.
- En la plataforma NVIDIA Tegra 2, la compresión en tiempo real es entre un 21 y un 36% más rápida que Aylesbury, dependiendo de los parámetros de compresión.
Como indican en OSNews, en la versión Aylesbury ya se había mejorado en un 7% el rendimiento de la métrica PSNR (6,3% en el caso de SSIM), lo que indica que desde la primera versión hasta Bali se ha mejorado un 12,8% en esta métrica, lo que implica una mejora significativa en la calidad de imagen.
Ahora queda por ver si la adopción de VP8 y del contenedor WebM se generalizan en Internet, y es que las comparaciones con el estándar de facto, H.264, son inevitables.
Related posts:
Ok comprime mas rapido (cosa secundaria, la primaria es la calidad del video) y en que parte dice que tiene mas calidad o volveremos a la vieja ignorancia de “Si Google lo dice es porque es verdad”??
Google Web Store y Google TV dos proyectos mas fracasados de Google, WebM es otro mas, WebM no es malo porque lo tenga Google sino porque Google congelo el spec igual al de VP8 y VP8 no supero a H.264, al congelar el spec Google sentencio WebM a ser inferior a H.264 probablemente por alrededor de 10 años.
Google actua desesperadamente porque era su unico chance de que H.264 (codigo acogido por la industria como standard) fuese el codec por defecto en HTML 5, y claro sus nuevos amigotes Adobe les recomendaron esta movida sabiendo que le video tag no estara listo y Adobe seguira con su plugin Flash molestando en la web.
Vean como una empresa por arrogancia intenta limitar a un mundo entero, por lo menso Adobe lo hace por los $$$, estos lo hacen por los $$$$$$$ y son tan descarados que dicen que es por una web abierta, por favor Google ha intentado segmentar la web en varias ocasiones y en todas ha fracasado, suerte que la FSF no dirige a donde va la web sino no existiria siquiera HTML 4.
P.S. Espere Google Native Client (nombre actual no el oficial), dele un poco de cabeza, aprende desarrollo de aplicaciones web, vuelva a leer y se dara cuenta que es otro intento mas de Google de fragmentar la web, pero es por una web abierta verdad, todo se le permite a Google… buenos hipocritas.
H264 es un estándar y tiene un compresor bajo GPL y opensource (x264). Malo no es, solo que en ciertos países (no todos), hay que pagar por ciertos usos de parte de su código (que no todo).
Significa que dispositivos con menos recursos pueden comprimir/capturar-comprimir videos a este formato con la misma calidad que por cierto es lo mejor desde hace mucho inclusive antes de que Google lo comprase solamente que no era tan popular, el h.264 es comparable al VP7.
Lo cierto es que en la web NO DEBERÍA SI QUIERA PENSARSE EN UN FORMATO PROPIETARIO, que ya tenemos suficiente con Flash por ejemplo.
Las teconologías web deben ser LIBRES y no que dependan de un consorcio propietario como el H.264, recuerden que google en un principio su codec no era libre, lo liberó porque la mismísima FSL se lo solicitó porqué no se podía creer que una tecnología como H.264 fuera a convertirse en el estándar de html5 y que dispositivos por ejemplo tengan que pagar regalías por utilizarlo.
El único punto a favor del h.264 es la capacidad de algunos chips de tener el codec por hardware pero eso es solamente obra de que sea el más popular cosa que pasaría con webM de ser más popular tan bien.
Mira que yo soy defensor de web-m y VP8, pero tengo que decir que estás equivocado. Los codecs que siguen el estandar h264 son superiores a VP8, e incluso algunos expertos (como el desarrollador del codec x264) analizaron detalladamente el porqué nunca podría VP8 superar a los del estandar h264. ¿Esto significa que los resultados con VP8 son malos? No, bajo ningún concepto. Que el otro sea mejor no significa que VP8 sea malo. El 90% de los usuarios comunes no notaría la más mínima diferencia entre videos codificados con uno u otro en similares condiciones. En esta disputa por elegir un estandar para html5, hay que elegir uno bueno (no necesariamente el mejor) y que le genere el menor conflicto a la gente de todo el mundo, por ejemplo conflictos de licencias. Y sin dudas eso lo logra web-m con el VP8. Después de todo aunque no se elija a h264 como estandar, se podría implementar un soporte para html5, supongo.
Si, un análisis realizado por alguien que se dedica a desarrollar para uno de los 2 codecs en concreto va a ser subjetivo e imparcial.
Es como el test de HTML5 que Microsoft le pasó a IE9
Aclaración: Cuando dije como “el” desarrollador del codec x264, es en realidad: “como uno de los actuales desarrolladores…”
@dnog, pero si x264 es un proyecto de Videolan, y el developer al que me refiero lo es además de FFMPEG, así que seguramente ellos también son los encargados de traernos el soporte de VP8 y Web-M en GNU/Linux. No considero que sean poco objetivos. De cualquier modo el expuso su punto de vista, y cualquiera podría refutar o contradecirlo si está equivocado:
http://x264dev.multimedia.cx/archives/377
http://x264dev.multimedia.cx/archives/486
http://x264dev.multimedia.cx/archives/541#more-541
Igualmente de lo que principalmente se queja en un principio es de las especificaciones de VP8, o mejor dicho, de la falta de ellas. Creo que también se mencionan puntos a favor de VP8 sobre el h264.
Saludos.
O como el test de Google y el XOOM que n isiquiera HTL 4 compliant es???
Me tomé el trabajo de dar una respuesta elaborada, incluso busqué los links del desarrollador de x264, pero el comentario quedó en moderación y no se publicó. Espero que el trabajo que me tomé no haya sido en vano…
Bueno, parece que hay que ser troll para que le publiquen a uno los comentarios. No veo cual era el problema con los enlaces que puse.
En definitiva, se pueden buscar los artículos relacionados de uno de los desarrolladores actuales de x264 donde habla de VP8 en su blog, “Diary Of An x264 Developer”
Esta persona no trabaja para MPEG-LA, sino que es desarrollador para Videolan y FFMPEG, y son los mimos que nos traen soporte para VP8 en GNU/Linux. Así que no veo por que a priori tildar de poco objetivo su análisis, y en todo caso si el dice algo incorrecto a favor de h264, el que así lo crea puede refutarlo con argumentos.
Saludos.
Todo lo que tenga que ver con internet y su infraestructura no tiene que depender de ninguna empresa en concreto.
Lo demás son pamplinas.
Imaginad que en su dia el protocolo tcp/ip o ethernet hubiese sido privativo…
No es lógico.
Si como GIF, JPEG y MP3 los hizo la comunidad del Free Software verdad???
Hablando de eso que ha hecho el Free Software por el internet porque todos los standares los promueven todos menos la gente del Free Software entonces por que tengo que aceptarles cualquier cosa a esta gente??
Uno cosa es que te creas el chantaje moralista proque suena bonito, otra es que no conozcas las historia de la web.
Como si te comes un pimiento haciendo puenting…
La infraestructura de internet debe ser libre y pública, como lo son los protocolos de transmisión, las tecnologías básicas, los standarts etc, etc. no te digo que innovaciones propias o de empresas no se propaguen después sobre la base pública, pero no en su totalidad, por favor, utiliza la cabeza un poco mas que para odiar a stallman o llevar sombrero…
No hay mas tutía, tal vez a ti no te importe que ciertas cosas deban ser públicas y no privadas.
Como dice la frase: “Res publica, non dominetur”
HTML ha cumplido una máxima, los códigos deben ser libres y gratuitos. Parte del éxito de internet es que no tiene costos por la parte material para nadie. Si te quieres montar una pagina web y alojarla en tu propio servidor lo único que te costará será la conexión. Vamos el servicio no la herramienta es lo que cuesta.
H264 de momento solo tiene promesas de gratuidad (cobra a encoders y decoders, haz un programa aunque sea con x264 y ve a EEUU y dime sino te cobran) y de libre bueno habla con la Mpeg-LA. Por cierto en muchas Webs salio que la MPEG-LA iba a presionar con sus patentes, lo que no he visto ha sido que el departamento de justicia de EEUU investiga a MPEG-LA por posible obstrucción de la competencia. No todo es tan bonito con h264.
he oido que theora ha mejorado mucho y se ha optimisado para ser una alternativa web alguien sabe como va esto?
http://www.theora.org/news/
Hasta donde sé, ¿no anunciaron nada ? aún así me destilaría por WebM
El enlace de osnews manda a la pagina de error de muylinux, el enlace debe ser http://www.osnews.com/story/24502/WebM_Project_Releases_New_Version_of_VP8_Codec