Feb 08 2010

Explicacion del desarrollador de Flash para linux de por que va tan mal

Escrito por founds en Incidencias, Linux

Un intenso debate se está llevando a cabo en el sitio Phoronix y en el blog de Mike Melanson – desarrollador del plug-in de Adobe Flash para Linux – sobre los problemas que debe sortear para implementar la reproducción de video con un rendimiento aceptable.  Mike inicialmente publicó un breve post en donde culpaba a la falta de estandarización de las API’s de Video en Linux como el motivo para no soportar ningún tipo de aceleración, recibiendo una contundente respuesta de la comunidad, que mostró como ejemplo otras aplicaciones de video que muy por el contrario, se ven beneficiadas por estas API’s.

Para nadie es un misterio que independiente del sistema operativo, reproducir videos con el plug-in de Flash en sitios como YouTube es lento, algo que se nota sobre todo en computadores con procesadores antiguos o al tratar de abrir varias pestañas con videos. Cualquier usuario que intente reproducir un video de YouTube con cualquier otro reproductor de video como por ejemplo Minitube, puede darse cuenta de que los los reproductores nativos consumen muy pocos recursos en comparación al plug-in de Adobe.

Hasta hace poco, se desconocían los motivos por los que el plug-in de Adobe se comportaba tan lento, y aunque Mike partió mal quejándose sin mayor fundamento en su blog, poco a poco se ha ido entendiendo en donde está el problema, y en este artículo intentaremos explicar de qué se trata el asunto.

Las tres etapas

La reproducción de video se puede dividir en tres etapas : decodificación, postproceso y render final.  En la decodificación, se toman los datos comprimidos directamente del archivo o del stream de video para obtener un sólo cuadro o imagen, se puede ver como el acto de tomar unos pocos bytes y convertirlo en un pixmap sin compresión.  El postproceso puede ser la aplicación de filtros (desentrelazado, eliminación de ruido, etc)  o cualquier otra operación que se desee realizar sobre el cuadro obtenido, por ejemplo el dibujado de los subtítulos o un logotipo.  Finalmente el render se encarga de volcar esa imagen final en memoria de video para que quede a la vista del usuario, esto incluye pasar por el sistema gráfico y en el caso de Flash en particular, dibujar el cuadro en un área rectangular de la página web renderizada en un browser.

Mike dice que no se puede comparar el rendimiento del plug-in de Flash con un reproductor de video normal porque se trata de resolver problemas que muy diferentes: En un reproductor de video normal las tres etapas son baratas en términos de uso de recursos porque no hay mayor transformación desde el cuadro obtenido en la primera etapa y el render final, por ejemplo el video decodificado puede ser enviado directamente a render usando aceleración por hardware, a menos que se requiera postproceso y aún así, los reproductores de video pueden usar métodos muy económicos para esta etapa.

200px-Barn-yuvComponentes YUV de un cuadro – (cc) Wikimedia

El problema principal radica en que Flash Player necesita trabajar sobre imágenes que operan en el espacio de colores RGB, es decir, cada pixel tiene un componente de rojo, verde y azul, mientras que el procesamiento de video usualmente opera en el espacio de colores YUV (o derivado), en donde la representación de los pixeles se realiza con componentes más adecuados a la percepción humana e ideales para la compresión.  Esta diferencia hace que mientras un reproductor de video puede pasar YUV directamente a la tarjeta de video, Flash tiene que convertir el cuadro completo a RGB para recién comenzar el postproceso que incluye el dibujo de otros componentes de Flash.

En la actualidad no hay forma de convertir YUV a RGB a través del hardware de video (GPU) y es una tarea que se hace “por software” en la CPU.

Seguramente Ustedes han visto una opción para habilitar la aceleración de video por hadware en el plug-in de Flash, Mike aclara que esta opción es sólo para el render final y lo que hace es aprovechar la GPU para escalar el cuadro al tamaño definitivo (ver bonus track). Tarea no menos importante, ya puede producir un mundo de diferencia entre reproducir el video en su tamaño original y llevarlo a pantalla completa, aún así la decodificación y conversión YUV->RGB sigue siendo sin ayuda del hardware.

En la versión 10.1 lo que se hizo fue aprovechar la aceleración por hardware para decodificación de video (primera etapa) en Windows:  Se trata de DirectX Video Acceleration o DXVA, y es una API especialmente diseñada para este propósito y que permite a una aplicación usar la aceleración de video provista por el fabricante de hardware, como PureVideo de NVIDIA o Unified Video Decoder de ATI en forma independiente del hardware.

Lo que indicó Mike en su primer post es que en Linux no existía una API de decodificación de video que se pudiera usar en este momento, lo que provocó la ira de usuarios y desarrolladores que conocen de la existencia de VDPAU de NVIDIA y XvBA de ATI, justamente los equivalentes en Linux de PureVideo y Unified Video Decoder respectivamente.  Por otra parte, Intel desarrolló Video Acceleration API (VA-API) para Linux, se trata de un mecanismo independiente del hardware para la decodificación de video, se puede decir que es el equivalente a DXVA de Windows para Linux, y permite usar la aceleración de decodificación de video disponible en algunos chips de Intel, NVIDIA a través de VDPAU, S3 y ATI a través de XvBA.

En la actualidad varios reproductores de video ya están usando estas API’s e incluso la implementación del plugin de Flash libre llamada Gnash, ya puede usar VA-API.

Para Mike esto sólo resolvería la primera etapa (decodificación) pero al menos podría quedar a la par con Windows, y el único sistema que quedaría atrás sería MacOSX, ya que según los desarrolladores de Flash no existe una API que permita obtener el cuadro decodificado tal como lo necesitan.

Aun así, aunque se cuente con decodificación por hardware se mantiene el problema de convertir los cuadros de YUV a RGB lo que hace que muchos se cuestionen qué tan adecuado es Flash para reproducir videos en la web y se enfatice la necesidad de que el famoso tag video de HTML5 tome fuerza y se convierta en un estándar para la publicación de videos.

Bonus Track : Las malas prácticas

Una de los aspectos más criticados del plug-in de Flash en Linux es que no soporta ningún tipo de aceleración y que los videos a pantalla completa pueden llegar a consumir gran parte del poder del procesador.  La verdad es que Flash en Linux sí usa aceleración en la tercera etapa de render y lo hace a través de OpenGL, y también hay que decir que está mal implementado.

La idea es sencilla: El cuadro listo para ser renderizado se convierte en una textura y a través de OpenGL se le pide al chip de video que ajuste esta textura al tamaño que se necesita. Considerando que el hardware de video es especialista en transformar texturas, se trata de una operación que no le hace ni cosquillas al computador.

El problema es que Mike, quien parece ser el único desarrollador de este plug-in, no encontró una forma confiable de detectar el hardware, y en sus pruebas se encontró con que algunos drivers de video tenían problemas si se trataba de llamar a la funcionalidad requerida y ésta no se encontraba soportada.  Por lo que simplemente se limitó a buscar el valor del el atributo “client glx vendor string” que arroja el comando glxinfo (glxinfo | grep client), y si este decía SGI entonces deshabilitaba la aceleración con OpenGL.

El problema es que salvo los drivers de NVIDIA, todos los demás dicen SGI porque usan una biblioteca común y no tiene nada que ver con las capacidades del hardware.  Ian Romanick, un representante de Intel en Architecure Review Board de OpenGL lo fustigó por esta mala práctica:

Como uno de los representantes de Intel en el ARB de OpenGL, estoy horrorizado por este mal uso del atributo client de GLX. Este atributo no tiene ninguna información sobre la existencia o la calidad del render por hardware.  Está orientado para propósitos de depuración y usarlo para cualquier otra cosa está completa e innegablemente equivocado.  Por favor corrige este bug.

Mike respondió que fue el único método confiable de detección que pudo encontrar y nuevamente Ian de Intel respondió:

Si encuentras que una interfaz debería funcionar pero no funciona, por favor, reporta el bug.  No te conformes usando interfaces que no fueron diseñadas para eso o que funcionan en formas no documentadas.  Sé que es la forma estándar de hacer estas cosas en Windows.  Nosotros preferimos corregir nuestros bugs cuando los conocemos, para que no tengas que hacer ese tipo de cosas aquí.  El hecho de que el “método más confiable de detección” sea confiable sólo en el driver de código cerrado de NVIDIA, es una clara evidencia de que no es confiable.

No es claro si este bug está o no corregido, pero al menos se incluyó un mecanismo para hacer que Flash no intente detectar el soporte de hardware por esta vía, para que el usuario avanzado habilite la aceleración por hardware explícitamente.

Conclusiones

De este debate se puede sacar una conclusión muy clara: Si el desarrollo del plug-in de Flash fuera abierto, por muy experto que sea Mike, podría haber recibido ayuda de otros expertos en video para Linux y también de fabricantes de hardware para implementar todo lo necesario con tal de habilitar la decodificación de video y además hubiera evitado el problema de la detección del hardware por medios no confiables, y que afectó a muchos usuarios.  De hecho le proponen implementar la conversión a RGB que necesita Flash en los mismos drivers, porque hay hardware que lo soporta, lo que mejoraría el rendimiento del plug-in notablemente.

Se agradece que Mike haya compartido estos detalles que podrían ayudar a obtener más luces sobre el asunto, pero si trabajara más cercano a la comunidad de código abierto y los fabricantes de hardware, hace mucho tiempo que la experiencia de Flash en Linux podría haber mejorado.

Visto en Fayerwayer | Fuente: Penguin.SWF

Artículos relacionados:

Feb 08 2010

Vodafone y su soporte tecnico

Escrito por founds en Incidencias

Casi 4€, 3,60 €, nada mas en llamadas al servicio de soporte técnico de Vodafone.

Y encima aun si arreglar mi incidencia del día 5/01/2010, que es la primera que abrí nada mas activarme la ADSL.

Artículos relacionados:

Feb 07 2010

Presentacion del iFreeTablet

Escrito por founds en General
Imagen de previsualización de YouTube

Visto | VivaLinux

Artículos relacionados:

  • No hay artículos relacionados
Feb 06 2010

La perlas de la semana

Escrito por founds en Humor

Los buscadores de Internet utilizan nuestras redes sin pagarnos nada, lo que es una suerte para ellos y una desgracia para nosotros, pero eso no va a poder seguir, es evidente. Es decir, las redes las ponemos nosotros, el peering lo hacemos nosotros, los sistemas los hacemos nosotros, el customer care lo hacemos nosotros, el servicio pos-venta lo hacemos nosotros, el servicio de instalación lo hacemos nosotros… lo hacemos todo. Quiero decir, ellos tienen algoritmos,  y los contenidos.

César Alierta, Presidente de Telefónica. Visto en Elotrolado

Si lo del Software Libre se entiende como Software Gratuito, creo que en Microsoft y en otras compañías, se ofrece software que se puede utilizar de manera gratuita

María Garaña, Directora Microsoft España. Visto en Barrapunto

María Garaña y la innovación tecnológica en España (En Días Como Hoy)

Artículos relacionados:

Feb 04 2010

El directorio temporal ‘c:\ruta\Temp_dir\’ no es un directorio válido

Escrito por founds en Incidencias, Windows

Hoy me ha salido esto actualizando unos equipos el .Net Framework 3.5 en Windows XP, el problema salta tanto con Windows Update como con una instalación local.

El problema es que las variables del entorno que apunta a TMP y TEMP estaban cambiadas a “C:\ruta larga numerica\temp_dir\“.

Para arreglar esto solo tenemos que ir a Panel de Control/Sistema, ahora nos vamos a la pestaña de “Opciones Avanzadas” y pinchamos en Variables de Entorno.

Comprobamos que las secciones TEMP y TMP tengan la ruta “c:\Windows\temp

Ahora reiniciamos y ya podemos instalar Framework 3.5

Artículos relacionados:

Feb 03 2010

Vodafone y el abuso

Escrito por founds en Incidencias

Yo -Buenas tardes quisiera la baja de mi servicio ya que tengo contratado 6Mb y solo me sincroniza a 5Mb-

Operador -Un momento que compruebo sus datos…..-

Operador -Lo siento no podemos darle de baja sin penalización si soporte técnico aun no se ha puesto en contacto con usted-

Yo -¿Se ha fijado usted cuando abrí la incidencia?-

Operador -Si señor, el día 5 de enero-

Yo -Y no cree que ya es hora-

Operador -Lo siento caballero pero hasta que no se ponga en contacto con usted no podemos darle la baja sin penalización-

Yo – Entonces que pasa con mi mega que falta-

Operador – Caballero, son hasta 6 mb -

Yo – ¿Me puede decir donde dice eso en el contrato o en la publicidad? -

Operador – pi. pi. pi. pi. (Ha colgado)

Artículos relacionados:

Feb 02 2010

Vodafone la misma mierda que Orange

Escrito por founds en Incidencias

Si ya salí escaldado de Orange y pensaba que una compañía no puede ser peor, pues me equivocaba Vodafone es igual o peor. En tan solo un mes ya estoy maldiciendo a esta compañía.

Todo ha empezado a mediados de noviembre de 2009, dándome de alta en una ADSL de 6Mb, en la que aseguraban que tenía cobertura y que en otras compañías he llegado a tener más velocidad.

Después de 1 mes y 4 días, todavía sin activar y navegando por la 3G, me doy cuenta de que tengo duplicadas las líneas y como es normal llamo y especifico la línea duplicada incorrecta, y ellos muy listos y eficientes dan de baja la correcta.

- ¡Joder, vaya putada, pero no es para tanto!- Ya pero no acaba hay la cosa.

Llega el día 5 de enero, y por reyes, Vodafone se digna a regalarme la activación de la ADSL, ¡¡pero noooooo!! no podía ser tan idílico regalo fuera bien, la ADSL me sincronizaba a 5Mb.

Llamo al servicio técnico y se lo comunico, con la jilipolles que me sortaron ya me estaba mosqueando un poco y es que decirte: – Pero si 5Mb es bastante rápido, para que vamos a abrir una incidencia por un mega que falta.-, tócate los cojones, si tengo contratado 6Mb pues quiero que sincronice a tal, que no he contratado el “Hasta 20Mb.”

Sigo,  iluso de mí, contrato también una portabilidad para sacarme el HTC Magic ya que la tarifa plana que dispone ya no tiene tope de descarga. Lo que en principio era 9 días a mi se me fue a 18 días por que la amable señorita se equivoco tomándome los datos, para mas inri fue presencial en la tienda Vodafone que esta en Nervión Plaza.

El día 7 de enero se efectúo la portabilidad, el 11 murió el móvil y tengo que esperar hasta mediados de febrero para que me devuelvan el móvil.

Ayer, 1 de febrero de 2010, llamo para ver como esta mi incidencia y me dicen que tengo que llamar a un teléfono de soporte técnico que solamente por llamar son 0,50 € y que para que quiero mas velocidad si ya tengo bastante, en esto ultimo se libro la señorita de que fuera por teléfono por que me la hubiera comido.

Recapitulemos, Vodafone es una empresa que sirve una serie de servicios, esos servicios con su mantenimiento están ligados a Vodafone pero te cobran de entrada 0.50€ por llamar por errores en su infraestructura.

Supongamos que esta empresa tenga unos 10.000.000 de usuarios, supongo que será mas, por 0.50€, sale 5.000.000€ que ganan con nosotros por errores suyos.

Así cualquiera saca un negocio de la incompetencia de esta empresa.

A los que siempre me preguntáis que compañía de internet recomiendo, os digo que Vodafone y Orange: NUNCA.

No alentemos a la incompetencia.

Artículos relacionados:

Feb 02 2010

Nuevo numero de Linux+

Escrito por founds en General

Nuevo número de esta fantástica revista online donde aprenderéis bastantes trucos y  algo más. Ver

Artículos relacionados:

Ene 31 2010

El mejor firewall del mundo es la mujer y no esta online

Escrito por founds en Humor

Una célula humana contiene 75MB de información genética.
Un espermatozoide contiene la mitad; eso significa 37.5MB
Un ml de semen contiene 100 millones de espermatozoides.
En promedio la eyaculación dura 5 segundos y contiene 2.24 ml de semen
Esto significa que la producción del miembro de un hombre equivale 37.5MB x 100,000,000 x 2.25)/5 = 1,687,500,000,000,000 bytes/segundo = 1,6875 Terabytes/seg

Esto quiere decir que el óvulo femenino soporta este ataque DDoS a 1,5 terabytes por segundo, y solo permite que pase un solo paquete de información lo que la hace el mejor hardware firewall del mundo.
La mala noticia de esto, es que ese paquete de información que deja pasar, cuelga el sistema por aproximadamente nueve meses.

Vía: rm -rf /identidadgeek

Artículos relacionados:

  • No hay artículos relacionados
Ene 30 2010

Paquete de brochas para Gimp

Escrito por founds en Diseño

Como algunos sabréis estoy muy liado con la tienda online de mi patrocinador, Freipc Informática, una e-commerce pero con algunas ideas originales que esperamos que a la gente les atraiga, ya que este sector es muy jodido y hay mucha competencia.

Bueno el caso es que buscando recursos para Gimp para el tema del diseño me he encontrado este fantástico paquete de brochas empaquetado en un .Deb que me ha sido de mucha utilidad.

Instalar brochas aquí

Por consola:

sudo apt-get install gimp-data-extras

Via:Foro-cualquiera

Artículos relacionados: