Portada :: Conocimiento Libre
Aumentar tamaño del texto Disminuir tamaño del texto Partir el texto en columnas Ver como pdf 01-02-2010

Las explicaciones del desarrollador de Adobe Flash para Linux y el soporte de video

Franco Catrin
FayerWayer


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 reproduccin de video con un rendimiento aceptable. Mike inicialmente public un breve post en donde culpaba a la falta de estandarizacin de las APIs de Video en Linux como el motivo para no soportar ningn tipo de aceleracin, 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 APIs.

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 pestaas 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 comparacin al plug-in de Adobe.

Hasta hace poco, se desconocan los motivos por los que el plug-in de Adobe se comportaba tan lento, y aunque Mike parti mal quejndose sin mayor fundamento en su blog, poco a poco se ha ido entendiendo en donde est el problema, y en este artculo intentaremos explicar de qu se trata el asunto.

Las tres etapas

La reproduccin de video se puede dividir en tres etapas : decodificacin, postproceso y render final. En la decodificacin, se toman los datos comprimidos directamente del archivo o del stream de video para obtener un slo cuadro o imagen, se puede ver como el acto de tomar unos pocos bytes y convertirlo en un pixmap sin compresin. El postproceso puede ser la aplicacin de filtros (desentrelazado, eliminacin de ruido, etc) o cualquier otra operacin que se desee realizar sobre el cuadro obtenido, por ejemplo el dibujado de los subttulos 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 grfico y en el caso de Flash en particular, dibujar el cuadro en un rea rectangular de la pgina 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 trminos de uso de recursos porque no hay mayor transformacin desde el cuadro obtenido en la primera etapa y el render final, por ejemplo el video decodificado puede ser enviado directamente a render usando aceleracin por hardware, a menos que se requiera postproceso y an as, los reproductores de video pueden usar mtodos muy econmicos para esta etapa.

El problema principal radica en que Flash Player necesita trabajar sobre imgenes 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 representacin de los pixeles se realiza con componentes ms adecuados a la percepcin humana e ideales para la compresin. 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 recin comenzar el postproceso que incluye el dibujo de otros componentes de Flash.

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

Seguramente Ustedes han visto una opcin para habilitar la aceleracin de video por hadware en el plug-in de Flash, Mike aclara que esta opcin es slo para el render final y lo que hace es aprovechar la GPU para escalar el cuadro al tamao definitivo (ver bonus track). Tarea no menos importante, ya puede producir un mundo de diferencia entre reproducir el video en su tamao original y llevarlo a pantalla completa, an as la decodificacin y conversin YUV->RGB sigue siendo sin ayuda del hardware.

En la versin 10.1 lo que se hizo fue aprovechar la aceleracin por hardware para decodificacin de video (primera etapa) en Windows: Se trata de DirectX Video Acceleration o DXVA, y es una API especialmente diseada para este propsito y que permite a una aplicacin usar la aceleracin 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 exista una API de decodificacin 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 decodificacin de video, se puede decir que es el equivalente a DXVA de Windows para Linux, y permite usar la aceleracin de decodificacin de video disponible en algunos chips de Intel, NVIDIA a travs de VDPAU, S3 y ATI a travs de XvBA.

En la actualidad varios reproductores de video ya estn usando estas APIs e incluso la implementacin del plugin de Flash libre llamada Gnash, ya puede usar VA-API.

Para Mike esto slo resolvera la primera etapa (decodificacin) pero al menos podra quedar a la par con Windows, y el nico sistema que quedara atrs sera MacOSX, ya que segn los desarrolladores de Flash no existe una API que permita obtener el cuadro decodificado tal como lo necesitan.

Aun as, aunque se cuente con decodificacin 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 estndar para la publicacin de videos.

Bonus Track : Las malas prcticas

Una de los aspectos ms criticados del plug-in de Flash en Linux es que no soporta ningn tipo de aceleracin 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 aceleracin en la tercera etapa de render y lo hace a travs de OpenGL, y tambin hay que decir que est mal implementado.

La idea es sencilla: El cuadro listo para ser renderizado se convierte en una textura y a travs de OpenGL se le pide al chip de video que ajuste esta textura al tamao que se necesita. Considerando que el hardware de video es especialista en transformar texturas, se trata de una operacin 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 tenan 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 deca SGI entonces deshabilitaba la aceleracin con OpenGL.

El problema es que salvo los drivers de NVIDIA, todos los dems dicen SGI porque usan una biblioteca comn 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 prctica:

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 informacin sobre la existencia o la calidad del render por hardware. Est orientado para propsitos de depuracin y usarlo para cualquier otra cosa est completa e innegablemente equivocado. Por favor corrige este bug.

Mike respondi que fue el nico mtodo confiable de deteccin que pudo encontrar y nuevamente Ian de Intel respondi:

Si encuentras que una interfaz debera funcionar pero no funciona, por favor, reporta el bug. No te conformes usando interfaces que no fueron diseadas para eso o que funcionan en formas no documentadas. S que es la forma estndar 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 mtodo ms confiable de deteccin sea confiable slo en el driver de cdigo 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 va, para que el usuario avanzado habilite la aceleracin por hardware explcitamente.

Conclusiones

De este debate se puede sacar una conclusin muy clara: Si el desarrollo del plug-in de Flash fuera abierto, por muy experto que sea Mike, podra haber recibido ayuda de otros expertos en video para Linux y tambin de fabricantes de hardware para implementar todo lo necesario con tal de habilitar la decodificacin de video y adems hubiera evitado el problema de la deteccin del hardware por medios no confiables, y que afect a muchos usuarios. De hecho le proponen implementar la conversin a RGB que necesita Flash en los mismos drivers, porque hay hardware que lo soporta, lo que mejorara el rendimiento del plug-in notablemente.

Se agradece que Mike haya compartido estos detalles que podran ayudar a obtener ms luces sobre el asunto, pero si trabajara ms cercano a la comunidad de cdigo abierto y los fabricantes de hardware, hace mucho tiempo que la experiencia de Flash en Linux podra haber mejorado.

http://www.fayerwayer.com/2010/01/las-explicaciones-del-desarrollador-de-adobe-flash-para-linux-y-el-soporte-de-video/



Envía esta noticia
Compartir esta noticia: delicious  digg  meneame twitter