En estos sistemas, una de las quejas recurrentes es el mal rendimiento que tiene la reproducción de Flash, tanto en Mac OSX como en Linux.  Hace un tiempo ya comentamos que una de las causas es la falta de un soporte oficial para aceleración de la decodificación de video por hardware, un aspecto que Apple viene a resolver con la actualización 10.6.3, en donde incluye una nueva API llamada Video Decode Acceleration Framwork. Esta API permite que las aplicaciones accedan a las capacidades de decodificación de video disponibles en hardware NVIDIA, específicamente de los sistemas con chip GeForce 9400M, GeForce 320M y GeForce GT 330M.

Ahora que se ha eliminado esta traba técnica desde el lado del sistema operativo, y antes de que Jobs los vuelva a llamar flojos, en Adobe están preparando una nueva versión de Flash que utilice esta API, para dejar la lentitud de la reproducción de videos en el pasado.

Ahora que la API que necesitabamos está disponible, estamos trabajando en un release de Flash Player que vendrá después de la versión 10.1, de tal forma de incluir esta funcionalidad en configuraciones que cuenten con el hardware soportado por esta nueva API.

¿Y qué pasa con Linux? NVIDIA por su propia cuenta ya cuenta con una API para decodificación de video para sistemas Unix llamada VDPAU (Video Decoding and Presentation API for Unix), y está desde bastante tiempo disponible para Linux. A pesar de esto y de que ya existen varias aplicaciones importantes que la están usando, no se conoce de ningún esfuerzo de Adobe por aprovecharla en Flash.

Links:
- Adobe will accelerate Flash video using new Apple API (Ars Technica)
- Video Decoding Accleration Framework Reference (developer.apple.com)
- Las explicaciones del desarrollador de Flash para Linux y el soporte de video (FayerWayer.com)

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.

Componentes 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.

Link: Solving different problems (Penguin.SWF)

Sorprendentemente, Andy fue bastante completo y directo en sus respuestas, lo que produjo una entrevista imperdible para todo aquel que quiera conocer el punto de vista de NVIDIA respecto a la plataforma Linux y otros sistemas Unix como Solaris y FreeBSD.

En este artículo publicamos un extracto de lo que nos pareció más interesante.

Andy dice que la mayoría de los ingenieros trabajando en el equipo de Linux usan emacs y/o vim en forma diaria, el código fuente se mantiene a través de Perforce (como en Google) aunque algunos de ellos usan git en forma personal, antes de aplicar los cambios en Perforce.

Cuando llega la hora de poner a prueba el driver, usan un conjunto interno de tests que se encarga de asegurar una correcta implementación de OpenGL. Además usan algunas aplicaciones como Maya, Viewperf, Unigine Tropics, ETQW, Doom 3, Quake 3 y por su puesto, Compiz.

Más del 90% del código es multiplataforma

Se estima que más del 90% del código que está en el driver para Linux es el mismo que se usa para el resto de las plataformas. La compañía ha realizado un esfuerzo para tener una arquitectura en donde gran parte del código sea independiente de la plataforma, lo que hace que el código específico sea muy reducido.

Tanto así, que el módulo que se carga a nivel de kernel es casi completamente independiente del sistema operativo subyacente. La mayor parte del código es el mismo para Windows XP, Vista, 7, MacOSX, Solaris, FreeBSD y Linux.  De hecho, el binario nv-kernel.o es el mismo para Solaris, FreeBSD y Linux. La única parte que es específica para cada sistema es la que tiene que interactuar finalmente con el kernel y esa fracción es bastante pequeña.

En la implementación de OpenGL, la única parte que cambia es la que tiene que interactuar con el sistema de ventanas (WGL en Windows y GLX en Unix).  Por el lado del código que interactúa con el sistema gráfico X, obviamente es más específico de Unix, aunque no se comparte mucho entre los distintos sistemas. Finalmente, el driver para acelerar la decodificación de video por hardware (VDPAU) usa gran parte del código que fue escrito para Windows (PureVideo).

El segmento de mercado Linux para NVIDIA

Para NVIDIA, el mercado Linux siempre ha sido bastante fuerte, y éste se encuentra principalmente en estaciones de trabajo de gama alta para segmentos específicos de mercado, como por ejemplo la industria energética, automotriz y de producción cinematográfica.  Es aquí en donde el impacto de Linux como plataforma para su negocio es medible para NVIDIA.

Aunque no se tienen porcentajes concretos, del total de las estaciones de trabajo de gama alta que se ocupan para visualización, prácticamente la mitad son Linux, y en la creación de contenido digital, como ya se sabe, es principalmente Linux.

Las estaciones de trabajo 3D con Linux son una proporción importante para NVIDIA y es por ahí en donde se han explorado nuevas tecnologías, como por ejemplo el caso de CUDA, en donde la proporción de usuarios con Linux es alta.

Desde el punto de vista de las descargas del driver desde su sitio web, las cifras no reflejan esta realidad, ya que respecto al driver para Windows, las descargas del driver de Linux son sólo un 0,5%.  Como muchos usuarios obtienen en driver a través de la misma distribución o en el caso de los segmentos industriales, a través de instalaciones OEM, se sabe que este porcentaje no es muy representativo, y medir de esta forma siempre ha sido un desafío.

Abrir el código fuente del driver: imposible

Abrir el código fuente del driver de NVIDIA es algo que probablemente nunca sucederá, y Andy indica tres razones para ello:

• La competencia en otras plataformas, ya que más del 90% es código compartido con esas plataformas también.  Las piezas específicas para Linux son tan pocas y tienen tan poca influencia que no sería práctico liberarlas.
• Hay propiedad intelectual de NVIDIA que está contenida en el driver y no quieren exponer.
• La documentación que mantienen está pensada para ser distribuida en forma interna. Si en algún momento quisieran hacer pública esa documentación, requerirían de un esfuerzo monumental para transformar esos documentos en algo que sea entendible por gente externa a la compañía.

X no es un problema, sino que una oportunidad

Mirando hacia adelante, en NVIDIA creen que las oportunidades de crecimiento están en X, no porque sea malo (de hecho la arquitectura es bastante buena), sino porque la evolución del escritorio Linux está sucediendo ahí e involucra tanto a X, drivers, gestores de ventanas y de composición.

Afortunadamente, X está implementado de tal forma que se puede extender con la flexibilidad necesaria para enfrentar los desafíos que impone el escritorio moderno en Linux.

Link: NVIDIA Developer talks openly about Linux support (Phoronix)

Respecto al hardware, las series 6 de NVIDIA GeForce incluyen una característica llamada PureVideo que se encarga del soporte de decodificación y presentación de videos a través del procesador gráfico (GPU).  Mientras que en Windows se utiliza PureVideo mediante DirectX Video Acceleration API (DxVA), en Linux se podía utilizar esta característica sólo en forma limitada.

NVIDIA viene a cambiar esta situación con el desarrollo de una API equivalente a DxVA para el mundo Unix llamada VDPAU : Video Decoding and Presentation API for Unix (API para decodificación y presentación para video).  Antes de explicar de que se trata, repasemos cuales son los sistemas actuales de aceleración de la reproducción de videos en Linux:

• Sin aceleración : la CPU se encarga de realizar todos los cálculos de decodificación de video.  Posteriormente cada frame decodificado debe ser copiado a Video RAM aplicando otros cálculos adicionales para llegar al tamaño que se quiere desplegar, ya sea agregando o eliminando pixeles.  Mientras más grande es el video original o el area de despliegue, peor es el rendimiento del sistema completo.  Si la ventana del video es cubierta por otras ventanas, la CPU tiene que hacer los cálculos necesarios para copiar sólo los bloques visibles. Independiente de la velocidad del computador, es un método bastante lento.
• X-Video (xv) : La CPU se encarga de realizar todos los cálculos de la decodificación del video, pero es la GPU quien se encarga de escalar y mostrar el video en pantalla, por lo tanto el tamaño del video es irrelevante para el rendimiento.  Originalmente se utilizaba la técnica del Chorma Key, es decir, se pinta un fondo azul y la GPU reemplaza todos esos píxeles por la imagen del vídeo, no es necesario hacer ningún cálculo relacionado con ventanas que tapan areas del video.  Cuando surgen los sistemas de despliegue basados en composición (Compiz y sus efectos 3D) se elimina el uso de Chroma Key y el video se renderiza como si fuera una textura en un polígono, aprovechando toda la capacidad de las GPU con aceleración 3D.
• X-Video Motion Compensation (XvMC) :  La GPU se hace cargo de algunas tareas de la decodificación de video, especificamente dos importantes tareas de la decodificación de MPEG-2, el codec que se usa en los DVD’s y en sistemas de televisión digital.  El hardware de NVIDIA sólo soporta XvMC con su driver propietario hasta las series 7 de GeForce mientras que ATI lo soporta sólo en forma experimental.  VIA agrega una tercera tarea de decodificación y además soporta MPEG-4 (ASP) y H.264.  Intel lo soporta completamente en sus series 8xx/9xx y dice que está trabajando en el soporte de más codecs.

VDPAU : Video Decode and Presentation API for Unix

NVIDIA no siguió con el soporte de aceleración a través de XvMC y no es que abandone el barco, sino que se dedicaron a desarrollar un nuevo esquema de aceleración que oficialmente soporte más tareas de decodificación en la GPU y que además soporte una gran cantidad de codecs.

A partir de la versión 180.06 de su driver propietario, NVIDIA comenzó el soporte de VDPAU en la series 8 de GeForce y posteriores (las anteriores tienen XvMC).  Los codecs que pueden ser acelerados son MPEG-1, MPEG-2 (DVD), MPEG-4 (H.264), VC-1 (HD DVD/BlueRay) y WMV3/WMV9.

La mejora en el rendimiento de la reproducción de videos puede ser impresionante.   En pruebas de VDPAU realizadas con hardware barato (CPU: USD$20 + GPU: USD$30) se pueden apreciar mejoras del rendimiento en la decodificación de videos HD que van desde una relación 1:2 a casos extremos con una relación 1:9.

NVIDIA además ha ayudado a desarrollar los parches para que las aplicaciones de video en Linux puedan usar VDPAU, específicamente hay soporte en MythTV, FFmpeg, MPlayer, VLC y Xine a través de parches.

Intel por su parte estaba tratando de mejorar XvMC a través de una API funcionalmente equivalente a VDPAU pero llamada simplemente Video Acceleration API (VA-API), sin embargo no ha tenido un impulso tan grande como el que esta dando NVIDIA a su tecnología.  No sólo no hay mucho código disponible, sino que el único driver de Intel que soporta VA-API es para una familia de chips que fue adquirida a PowerVR, por lo tanto es diferente a todo lo existente para sus chips más conocidos.  Este hardware conocido como Poulsbo (GMA 500) se encuentra presente en dispositivos MID’s y netbooks, sus drivers tienen componentes privativos y han sido duramente criticados por su deficiente calidad.

Afortunadamente Intel ha declarado que está considerando a VDPAU para sus drivers de X.org, y si esto sucede, se espera que ATI también se una a esta iniciativa.

Links:
- NVIDIA Driver brings PureVideo features to Linux (phoronix.org)
- Intel considering VDPAU for X.org driver (phoronix.org)
- HD Video playback with a $20 CPU & $30 GPU on Linux (phoronix.org)