Facultad de Inform´atica
Departamento de Computaci´on
PROYECTO FIN DE CARRERA
INGENIER´IA INFORM´
ATICA
Desarrollo de un Set Top Box basado en
Linux para un servicio de v´ıdeo bajo
demanda
Autor: Samuel Rivas Gonz´alez
Tutor: V´ıctor M. Gul´ıas Fern´andez
Especificaci´
on
T´ıtulo del proyecto: Desarrollo de un Set Top Box ba-sado en Linux para un servicio de v´ıdeo bajo demanda
Clase: Proyecto cl´asico de ingenier´ıa.
Nombre del alumno: Samuel Rivas Gonz´alez.
Nombre director : V´ıctor M. Gul´ıas Fern´andez.
Nombre del tutor : V´ıctor M. Gul´ıas Fern´andez.
Miembros del tribunal :
Miembros suplentes:
Fecha de lectura:
Agradecimientos
Supongo que ser´a innecesario decir que no he sido yo el ´unico art´ıfice de que llegara el momento de escribir estas l´ıneas; son tantas las personas a las que debo mucho por el apoyo y ayuda que he recibido durante todos estos a˜nos de carrera que ser´ıa imposible nombrarlas a todas sin adjuntar un nuevo tomo a este documento. Me gustar´ıa, sin embargo, mencionar a algunas personas que han tenido una especial influencia en el hecho que que ahora mismo est´e a punto de terminar este proyecto:
A mis padres, por darme la oportunidad de llegar hasta el final de este carrera y el apoyo necesario para conseguirlo.
A mis hermanos, mis abuelos y mis t´ıas que me llevan aguantando tantos a˜nos.
A Rub´en y Julio, por las pr´acticas y los ex´amenes que preparamos juntos.
A Pablo, por las horas de estudio que compartimos.
A todos los que soportaron la convivencia conmigo: Iv´an durante 5 a˜nos y Xavi, Fernando y Julio (otra vez) durante este ´ultimo a˜no de carrera.
A V´ıctor, por llevarme el proyecto.
A la gente del laboratorio LFCIA por toda la ayuda que me ofrecieron durante este trabajo.
Y a todos mis amigos que en alg´un momento de mi vida me han ayudado o sencillamente han compartido parte de su tiempo conmigo. Sin eso ser´ıa imposible haber llegado hasta aqu´ı.
Resumen
El objetivo de este proyecto es desarrollar un Set Top Box que permita al usuario final acceder a un servicio de v´ıdeo bajo demanda a trav´es de una inter-faz definida en un servidor remoto.
Las limitaciones de espacio a las que se debe atener el software desarrollado para realizar las funcionalidades requeridas en el Set Top Box obligan a la utiliza-ci´on de bibliotecas de bajo nivel para el control del hardware gr´afico. Para ello se ha elegido la biblioteca DirectFB, que permite controlar directamente el dispo-sitivo framebuffer de Linux a trav´es de un API escrito en C, que ser´a el lenguaje utilizado para implementar la aplicaci´on encargada de comunicarse con el usuario. La interfaz presentada por el Set Top Box al usuario ser´a definida utilizando el est´andar XML. Para ello se ha desarrollado una aplicaci´on que proporcionar´a los documentos XML necesarios a la aplicaci´on cliente residente en el Set Top Box. Para el desarrollo de esta aplicaci´on se ha elegido el lenguaje funcional Erlang.
El software desarrollado para el Set Top Box deber´a ser capaz de realizar las siguientes funciones:
Comunicarse con el servidor de documentos XML utilizando el protocolo HTTP.
Comprender los documentos XML recibidos y mostrar al usuario una inter-faz de acuerdo con dichos documentos.
Comprender eventos generados por el usuario a trav´es de los perif´ericos de entrada pertinentes (por ejemplo, el mando a distancia).
Realizar las acciones necesarias ante los eventos de entrada generados por el usuario; de acuerdo con las especificaciones de los documentos XML. Dichas acciones comprenden, entre otras, solicitud de nuevos documentos XML, reproducci´on de v´ıdeo, cambios en las preferencias del usuario ... La aplicaci´on encargada de proporcionar los documentos XML se desarro-llar´a de forma que realice las funciones m´ınimas necesarias para poder validar el correcto funcionamiento del software implementado para el Set Top Box. Esta aplicaci´on recibir´a peticiones HTTP y responder´a enviando documentos XML uti-lizando el mismo protocolo. La informaci´on necesaria sobre los distintos usuarios y los medios disponibles se mantendr´a en una base de datos.
DirectFB, framebuffer, Set Top Box, C, v´ıdeo bajo demanda, XML, HTTP, Erlang, v´ıdeo, interfaz.
´Indice general
1. Introducci´on 1
1.1. Introducci´on . . . 1
1.2. Objetivos . . . 2
1.3. Etapas del proyecto . . . 3
1.4. Estructura de la memoria . . . 4
2. Contextualizaci´on 5 2.1. V´ıdeo bajo demanda . . . 6
2.1.1. Introducci´on . . . 6
2.1.2. Servidores de v´ıdeo comerciales . . . 7
2.1.3. El servidor VoDKA . . . 8
2.2. Set Top Boxes . . . . 9
2.2.1. Introducci´on . . . 9
2.2.2. Middleware . . . . 12
2.2.3. Funcionalidades t´ıpicas . . . 14
2.2.4. Ejemplos comerciales . . . 15
2.3. Programaci´on gr´afica en Linux . . . 17
2.3.1. Introducci´on . . . 17 2.3.2. Framebuffer . . . . 19 2.3.3. Microwindows . . . 20 2.3.4. Qt . . . 21 2.4. DirectFB . . . 23 2.4.1. Introducci´on . . . 23 2.4.2. Arquitectura . . . 24 2.4.3. T´erminos importantes . . . 26 2.4.4. API . . . 27 3. An´alisis 29 3.1. Introducci´on . . . 29 3.2. Protocolo de comunicaci´on . . . 30
3.3. Set Top Box . . . . 31 i
3.4. Aplicaci´on DFBCIn . . . 32 3.4.1. Introducci´on . . . 32 3.4.2. M´odulo gr´afico . . . 32 3.4.3. Parser . . . . 34 3.4.4. Conclusiones . . . 35 3.5. Servidor XML (VXMLS) . . . 36 3.6. Ciclo de Desarrollo . . . 37 3.6.1. Introducci´on . . . 37 3.6.2. Prototipo . . . 37 3.6.3. DFBCIn . . . 39 3.6.4. VXMLS . . . 40
3.6.5. Prueba del sistema conjunto . . . 40
4. Dise˜no 41 4.1. Introducci´on . . . 42
4.2. Definici´on de la interfaz y objetos del dominio . . . 42
4.2.1. Introducci´on . . . 42
4.2.2. La clase Menu . . . . 43
4.2.3. La interfaz Action . . . 45
4.3. Documentos XML . . . 48
4.3.1. Introducci´on . . . 48
4.3.2. Descripci´on de los men´us . . . 48
4.4. Protocolo de comunicaci´on . . . 54
4.5. Dise˜no de DFBCIn . . . 55
4.5.1. Divisi´on en subsistemas . . . 55
4.5.2. Interacci´on entre m´odulos . . . 56
4.5.3. Objetos comunes . . . 58
4.5.4. Dise˜no del motor de la aplicaci´on . . . 59
4.5.5. Dise˜no del m´odulo VXMLS . . . 65
4.5.6. Dise˜no del m´odulo gr´afico . . . 71
4.6. Dise˜no de VXMLS . . . 75
4.6.1. Introducci´on . . . 75
4.6.2. Objetos del dominio . . . 76
4.6.3. Modelo entidad-relaci´on . . . 78
4.6.4. Dise˜no de la capa modelo . . . 78
4.6.5. Dise˜no de la vista y el controlador . . . 80
5. Implementaci´on de DFBCIn 85 5.1. Introducci´on . . . 86
5.2. Est´andares de codificaci´on . . . 87
´Indice general iii
5.2.2. Objetos . . . 89
5.3. Control de errores . . . 90
5.4. Control de concurrencia . . . 92
5.5. Tipos de datos de uso general . . . 94
5.5.1. Pilas . . . 94 5.5.2. Arrays . . . . 95 5.6. La clase Menu . . . . 96 5.7. La clase Option . . . . 98 5.8. La clase Key . . . . 99 5.9. La interfaz Action . . . . 100 5.9.1. Introducci´on . . . 100 5.9.2. Tipos de datos . . . 100 5.9.3. Funciones . . . 104
5.9.4. ¿C´omo instanciar una acci´on? . . . 107
5.9.5. ¿C´omo a˜nadir una nueva acci´on? . . . 108
5.10. Implementaci´on del motor de la aplicaci´on . . . 108
5.10.1. Main . . . . 108
5.10.2. Interface . . . . 110
5.10.3. InterfaceInput . . . . 114
5.10.4. Mp3Player . . . 116
5.11. Implementaci´on del m´odulo VXMLS . . . 118
5.11.1. M´odulo HTTP . . . 118
5.11.2. Parser VXMLS . . . . 120
5.11.3. Parser para los documentos menu . . . . 121
5.11.4. Implementaci´on de la fachada VXMLS . . . 133
5.12. Implementaci´on del M´odulo gr´afico . . . 136
5.12.1. Introducci´on . . . 136
5.12.2. Estructuraci´on del c´odigo . . . 137
5.12.3. La fachada graphics.c . . . 137
5.12.4. La inicializaci´on de DirectFB . . . 138
5.12.5. Control de eventos de entrada . . . 138
5.12.6. Impresi´on de men´us y texto . . . 140
5.12.7. Reproducci´on de v´ıdeo . . . 141
5.12.8. M´odulo de pruebas . . . 144
5.13. Sistema de propiedades . . . 145
5.14. Etapas de codificaci´on . . . 145
5.14.1. Desarrollo del n´ucleo de la aplicaci´on . . . 145
5.14.2. Reproducci´on b´asica de v´ıdeo . . . 146
5.14.3. Pruebas en el Set Top Box . . . . 147
5.14.4. Varias mejoras . . . 147
5.14.6. Integraci´on con VXMLS . . . 148
5.14.7. Integraci´on con VoDKA . . . 149
5.14.8. Reproductor Mp3 y acciones de texto . . . 149
6. Implementaci´on de VXMLS 151 6.1. Introducci´on . . . 152
6.1.1. Generalidades sobre Erlang/OTP . . . 152
6.1.2. ¿C´omo funciona Inets? . . . . 152
6.1.3. ¿C´omo funciona Mnesia? . . . . 153
6.1.4. Servidores gen´ericos . . . 154 6.1.5. Estructura de la aplicaci´on VXMLS . . . 154 6.1.6. Tipos de datos . . . 155 6.1.7. Control de errores . . . 156 6.2. Capa Modelo . . . 157 6.2.1. Tipos de datos . . . 157
6.2.2. Administraci´on de la base de datos . . . 159
6.2.3. Funciones de la fachada . . . 159 6.3. Capa Vista . . . 165 6.4. Capa Controlador . . . 167 6.4.1. Generaci´on de la respuesta HTTP . . . 167 6.4.2. Traducci´on de mensajes . . . 167 6.4.3. Fachada . . . 168
6.4.4. Creaci´on y destrucci´on de sesiones . . . 168
6.4.5. Propiedades de personalizaci´on . . . 169
6.4.6. Generaci´on de men´us . . . 169
6.4.7. Composici´on de objetos Menu . . . . 171
6.4.8. Men´us definidos . . . 172
6.4.9. Ejemplos de vxmls get menu . . . 173
6.5. Extensibilidad . . . 175
7. Validaci´on 179 7.1. Despliegue del sistema . . . 179
7.2. Tama˜no del software para el Set Top Box . . . . 180
7.3. DFBCIn . . . 181
7.3.1. Problemas de rendimiento . . . 181
7.3.2. Problemas con avifile . . . 182
7.4. VXMLS . . . 184
7.4.1. Comportamiento general . . . 184
7.4.2. Problemas con Inets . . . . 184
´Indice general v
8. Conclusiones y l´ıneas futuras 187
8.1. Conclusiones . . . 187
8.2. Continuaci´on de este proyecto . . . 189
8.2.1. DFBCIn . . . 189
8.2.2. VXMLS . . . 190
A. DTD utilizados 193 A.1. DTD utilizado para la definici´on de men´us . . . 193
A.2. DTD utilizado para la especificaci´on de las respuestas de VXMLS 195 B. API del m´odulo gr´afico de DFBCIn 197 C. Definici´on de IDirectFBVideoProvider 199 D. Tipos de datos en Erlang 203 E. Instalaci´on y ejecuci´on 205 E.1. Estructura de la distribuci´on . . . 205
E.2. Instalaci´on de VXMLS . . . 205
E.2.1. Compilaci´on . . . 205
E.2.2. Instalaci´on . . . 206
E.3. Instalaci´on de DFBCIn . . . 207
E.3.1. Requisitos previos . . . 207
E.3.2. Compilaci´on . . . 207
E.3.3. Ejecuci´on . . . 208
F. Glosario 209
´Indice de figuras
1.1. Relaci´on entre el usuario y el servidor de VoD . . . 2
2.1. Configuraci´on interna de un Set Top Box . . . . 10
2.2. Capas de un Set Top Box . . . . 11
2.3. Prismiq MediaPlayer . . . . 16
2.4. Set Top Box de HMMI . . . . 16
2.5. XPC SS50 . . . 17
2.6. Acceso de una aplicaci´on DirectFB al hardware gr´afico . . . . . 25
2.7. Relaci´on entre las interfaces de DirectFB . . . 27
3.1. Prototipo de interfaz con el usuario . . . 33
3.2. Creaci´on de parsers con expat . . . . 35
3.3. Aplicaci´on DFBSee . . . . 38
3.4. Aplicaci´on DFBPoint . . . . 39
4.1. Primera aproximaci´on a la clase Menu . . . . 43
4.2. Segunda aproximaci´on a la clase Menu . . . . 43
4.3. Dise˜no definitivo de la clase Menu . . . . 44
4.4. Acciones para el manejo de men´us . . . 46
4.5. Acciones para el control de v´ıdeos . . . 47
4.6. Resto de acciones del sistema . . . 47
4.7. M´odulos de DFBCIn . . . 56
4.8. Interacci´on entre los m´odulos de DFBCIn . . . 57
4.9. Clase Menu en DFBCIn . . . . 59
4.10. Clases para el almacenamiento de datos . . . 60
4.11. Clases del motor . . . 61
4.12. Detecci´on de eventos de entrada . . . 62
4.13. Ciclo de ejecuci´on . . . 62
4.14. Estados de InterfaceInput e Interface . . . . 63
4.15. M´aquina de estados de Interface . . . . 64
4.16. Interacci´on entre los componentes del m´odulo VXMLS . . . 66 vii
4.17. Clases del m´odulo VXMLS . . . 67
4.18. Clases utilizadas para la construcci´on del parser para descripciones de men´us . . . 68
4.19. Clases utilizadas para la construcci´on m´odulo gr´afico . . . 73
4.20. M´aquina de estados de VideoPlayer . . . . 74
4.21. Aspecto visual de las dos implementaciones del m´odulo gr´afico . . 75
4.22. Patr´on Model/View/Controller en el dise˜no de VXMLS . . . . 76
4.23. Objetos del dominio . . . 77
4.24. Objetos valor utilizados para definir objetos Menu . . . . 77
4.25. Objetos valor utilizados por VXMLS . . . 78
4.26. Modelo entidad-relaci´on . . . 79
4.27. Clases de la vista y el controlador de VXMLS . . . 81
7.1. Despliegue del sistema final . . . 180
7.2. DFBCIn funcionando en el Set Top Box . . . . 181
7.3. Capas de acceso al servicio de streaming . . . . 185
Cap´ıtulo 1
Introducci´
on
´Indice General
1.1. Introducci´on . . . 1
1.2. Objetivos . . . 2
1.3. Etapas del proyecto . . . 3
1.4. Estructura de la memoria . . . 4
1.1.
Introducci´
on
Un servicio de v´ıdeo bajo demanda (VoD de aqu´ı en adelante para simplificar) permite a los usuarios finales el acceso a medios de v´ıdeo de forma interactiva sin ning´un tipo de programaci´on preestablecida. Para proporcionar este tipo de ser-vicio es necesario un servidor de streaming que sea capaz de distribuir los medios en un flujo continuo de datos de forma que puedan ser reproducidos mientras se reciben.
Para el usuario final, el servidor de streaming puede ser visto como un gran conjunto de medios sin estructura a los que puede acceder. Permitir el uso de esos recursos pasa por la obligaci´on de desarrollar un sistema que posibilite el acceso de forma controlada a dichos medios y que los presente de forma comprensible y ordenada. Este es el objetivo que persigue este proyecto: desarrollar un Set
Top Box que proporcione acceso desde el hogar a los medios distribuidos por un
servidor VoD.
Para mantener centralizado el control de las interfaces presentadas a los usua-rios, el software desarrollado seguir´a el paradigma cliente-servidor, de forma que el software que controla el funcionamiento del Set Top Box obtendr´a la informa-ci´on necesaria de un servidor, con el que se comunicar´a utilizando el est´andar XML sobre el protocolo HTTP.
Actor
Set Top Box
Servidor VoD
Servidor XML
Flujo
n
1
Figura 1.1: Relaci´on entre el usuario y el servidor de VoD
El desarrollo de la aplicaci´on cliente se ha realizado utilizando el lenguaje C y las bibliotecas DirectFB [1], para el control del hardware gr´afico, y expat [2], para la implementaci´on del parser XML. Esta aplicaci´on recibe el nombre de DFBCIn (acr´onimo de DirectFB Client Interface).
El servidor XML se ha implementado utilizando el lenguaje funcional Er-lang [3] y diversas herramientas proporcionadas por la plataforma de desarrollo Erlang/OTP [4].
Como servidor de VoD se utilizar´a VoDKA [5]. Por ello, a la aplicaci´on encar-gada de servir los documentos XML se le ha bautizado como VXMLS (VoDKA XML Server ).
1.2.
Objetivos
El principal objetivo del proyecto es el dise˜no y desarrollo de un Set Top Box basado en Linux que permita el acceso de forma controlada al servidor de VoD VoDKA. El software desarrollado deber´a ajustarse a las restricciones de espacio
Etapas del proyecto 3 presentadas por este tipo de sistemas.
Como objetivo secundario tambi´en se desarrollar´a una aplicaci´on que act´ue como servidora de los documentos XML que necesitar´a el Set Top Box para ge-nerar la interfaz que presentar´a al usuario.
Tanto el desarrollo del Set Top Box como de la aplicaci´on encargada de pro-porcionar la descripci´on de la interfaz deber´an cumplir los siguientes objetivos:
Permitir al usuario acceder a los servicios de VoDKA a trav´es de un televisor convencional.
Controlar el acceso a los medios, manteniendo informaci´on sobre los usuarios que disfrutan de los mismos.
Permitir a los usuarios elegir ciertas configuraciones para adaptar los ser-vicios a sus necesidades. Por ejemplo, cada usuario deber´ıa poder elegir el idioma en el que se le proporcione la informaci´on que precise.
Mantener la interfaz presentada a los usuarios siempre actualizada, pudien-do variar seg´un, por ejemplo, la hora del d´ıa, las preferencias del usuario, etc.
1.3.
Etapas del proyecto
Durante el desarrollo del proyecto se ha pasado por las siguientes etapas:
1. Estudio de las diferentes alternativas existentes para programar accediendo
directamente al dispositivo framebuffer de Linux.
2. Elecci´on de una de las alternativas (en este caso DirectFB) e
implementa-ci´on de una aplicaimplementa-ci´on de ejemplo para comprobar su idoneidad.
3. Elecci´on de la estructura de los documentos XML que deber´a interpretar la
aplicaci´on cliente.
4. Dise˜no e implementaci´on de la aplicaci´on cliente DFBCIn siguiendo el
pa-radigma de desarrollo incremental. Como no se dispone todav´ıa del servidor de documentos los incrementos iniciales trabajar´an con documentos est´ati-cos: en las primeras fases con ficheros y, una vez avanzado el desarrollo, solicitando los documentos de un directorio remoto utilizando el protocolo HTTP.
5. Estudio de las herramientas proporcionadas por Erlang/OTP para el desa-rrollo de aplicaciones HTTP.
6. Dise˜no e implementaci´on del servidor de documentos XML VXMLS.
7. Ultimo incremento de la aplicaci´on cliente, en el que se a˜nadir´a la funciona-´
lidad necesaria para permitir la comunicaci´on con el servidor implementado en el paso anterior.
8. Integraci´on del sistema resultante con VoDKA.
9. Validaci´on del sistema.
1.4.
Estructura de la memoria
En el cap´ıtulo 2 se expone una introducci´on a la tecnolog´ıa de v´ıdeo bajo de-manda, en la que se hace una breve descripci´on del servidor VoDKA. Tambi´en se exponen las caracter´ısticas generales de los Set Top Boxes y de la programaci´on gr´afica bajo Linux, finalizando con un apartado dedicado a los aspectos generales de la biblioteca DirectFB.
Los cap´ıtulos 3 y 4 describen las fases de an´alisis y dise˜no de este proyecto. La fase de implementaci´on se divide dos cap´ıtulos: en el cap´ıtulo 5 se documenta la implementaci´on del software dise˜nado para el Set Top Box y en el cap´ıtulo 6 se documenta la implementaci´on del servidor de documentos XML.
En el cap´ıtulo 7 se documenta la fase de validaci´on del sistema.
Por ´ultimo, en el cap´ıtulo 8 se exponen las conclusiones obtenidas tras la fi-nalizaci´on del proyecto y se exponen una serie de l´ıneas de trabajo que quedan abiertas.
Se incluyen varios ap´endices con diversa informaci´on que puede ser de utilidad para comprender alguna de las secciones de esta memoria, informaci´on sobre la instalaci´on y ejecuci´on del software desarrollado y un glosario en el que se explican los acr´onimos utilizados a lo largo de este documento.
Cap´ıtulo 2
Contextualizaci´
on
´Indice General
2.1. V´ıdeo bajo demanda . . . 6
2.1.1. Introducci´on . . . 6
2.1.2. Servidores de v´ıdeo comerciales . . . 7
2.1.3. El servidor VoDKA . . . 8
2.2. Set Top Boxes . . . . 9
2.2.1. Introducci´on . . . 9
2.2.2. Middleware . . . . 12
2.2.3. Funcionalidades t´ıpicas . . . 14
2.2.4. Ejemplos comerciales . . . 15
2.3. Programaci´on gr´afica en Linux . . . 17
2.3.1. Introducci´on . . . 17 2.3.2. Framebuffer . . . . 19 2.3.3. Microwindows . . . 20 2.3.4. Qt . . . 21 2.4. DirectFB . . . 23 2.4.1. Introducci´on . . . 23 2.4.2. Arquitectura . . . 24 2.4.3. T´erminos importantes . . . 26 2.4.4. API . . . 27 5
2.1.
V´ıdeo bajo demanda
2.1.1.
Introducci´
on
La intenci´on de un servicio de VoD es proporcionar un servicio de v´ıdeo en el que m´ultiples usuarios pueden solicitar un objeto de v´ıdeo en cualquier momento. Las posibles aplicaciones de un sistema de este tipo pueden ser: pel´ıculas bajo demanda, noticias interactivas, aprendizaje a distancia, etc.
Un sistema de este tipo debe incluir los siguientes elementos:
El servidor de v´ıdeo: Es similar a un servidor de ficheros normal, pero a
diferencia de estos, debe priorizar el mantenimiento del flujo de datos cons-tante. Un servicio de v´ıdeo no puede proporcionar el v´ıdeo completo ante una petici´on, puesto que el tama˜no de los datos es demasiado grande. En lugar de esperar a recibir el v´ıdeo completo, el terminal cliente recibe un flujo constante de datos, que ir´a reproduciendo a medida que le van lle-gando. Por lo tanto, el servidor de v´ıdeo tiene que mantener el flujo de datos de manera ininterrumpida y con la cadencia adecuada para que la reproducci´on del v´ıdeo en el terminal sea continua. Esta t´ecnica se conoce como streaming. Para este proyecto se ha utilizado VoDKA como servidor de v´ıdeo.
El servidor de aplicaciones: Debe incluir dos m´odulos b´asicos:
• La aplicaci´on de usuario: Garantiza la conectividad de los usuarios
desde sus puestos remotos y le permite explorar entre los contenidos a los que est´a autorizado. Asimismo, esta aplicaci´on tambi´en controla los datos y estad´ısticas de los distintos usuarios registrados. En el caso de este proyecto, se desarrollar´a la aplicaci´on de usuario VXMLS. • La aplicaci´on de gesti´on: La aplicaci´on de gesti´on de un sistema de
v´ıdeo bajo demanda incluye: alta, clasificaci´on, modificaci´on y borrado de los contenidos y los meta-datos; gesti´on y asignaci´on de los perfiles de usuario; asignaci´on de claves de acceso para los distintos niveles de contenido y monitorizado en tiempo real del estado del sistema. Los datos manejados por esta aplicaci´on estar´an en una base de datos a la que tambi´en acceder´a la aplicaci´on de usuario. En [6] se ha desarro-llado una aplicaci´on de gesti´on para VoDKA que permite gestionar y administrar los usuarios y medios asociados al servidor VoDKA.
Los codificadores en l´ınea: Permiten ofrecer material no pregrabado. Deben
ser capaces de obtener el v´ıdeo y comprimirlo en tiempo real para propor-cional material visual en directo.
V´ıdeo bajo demanda 7
Los terminales: En ellos es donde el usuario puede ver el v´ıdeo que ha
solici-tado. Estos terminales pueden ser de dos tipos: ordenadores personales o Set
Top Boxes (En este proyecto se desarrolla un terminal del segundo tipo).
Los terminales reciben el v´ıdeo, lo decodifican y lo presentan por pantalla al usuario. Normalmente, el software que controla el terminal tambi´en debe proporcionar la posibilidad de comunicarse con la aplicaci´on de usuario. En este proyecto se desarrolla la aplicaci´on DFBCIn para este prop´osito.
La red: Deben tenerse en cuenta los factores de QoS, protocolos unicast y multicast y otros factores espec´ıficos para la transmisi´on de v´ıdeo.
2.1.2.
Servidores de v´ıdeo comerciales
En los ´ultimos a˜nos las empresas m´as importantes que comercializan produc-tos multimedia han desarrollado sistemas relacionados con el v´ıdeo bajo demanda. Algunas de las soluciones est´an m´as adaptadas a redes de bajo ancho de ban-da, como es el caso de RealVideo Server, de Real Networks, que hacen uso de tecnolog´ıas de cach´e de los streams para optimizar el uso de una red con las caracter´ısticas de Internet, o Microsoft Windows Media Server, que utiliza proto-colos propietarios y puede ser utilizado en entornos de un mayor ancho de banda con un rendimiento menor.
Otras soluciones se enfocan m´as a entornos LAN o WAN, con mayor dispo-nibilidad de ancho de banda. Las m´as representativas son Darwing Streaming
Server [7], de Apple, que es la versi´on de c´odigo abierto de Quicktime Strea-ming Server, y s´olo es un servidor de streaStrea-ming RTP, sin incluir la gesti´on del
almacenamiento; DB2 Digital Library Video Charger [8], de IBM; Oracle Video
Server [9, 10], quiz´a el m´as utilizado de todos, con arquitectura cliente-servidor,
pero con limitaciones de escalabilidad; Kassenna MediaBase, una evoluci´on de
WebForce MediaBase, de SGI, con caracter´ısticas comunes al dise˜no de VoDKA
(modular, separaci´on de funciones de adquisici´on, distribuci´on y streaming, ba-sado en sistemas UNIX), pero una menor flexibilidad y capacidad de adaptaci´on;
Philips WebCine Server [11], servidor de streaming MPEG4 basado en Linux; Cisco IP/TV [12], soluci´on cerrada con herramientas orientadas al mercado de
formaci´on; y el sistema de SUN: StorEdge Media Central [13]. Tambi´en existen soluciones de caja negra, que consisten en la combinaci´on de un hardware espe-cializado con alguno de los productos anteriores.
En el contexto acad´emico la mayor´ıa de los proyectos poseen un car´acter alta-mente experimental. En [14] se analiza una soluci´on jer´arquica para la
construc-ci´on de servidores multimedia. En Stony Brook Video Server Project [15, 16, 17] se intenta crear un servidor distribuido que proporcione al usuario caracter´ısti-cas de indexaci´on, b´usqueda y streaming de v´ıdeos, y est´a desarrollada con una interesante arquitectura cliente servidor, adaptada para redes locales. En [18] se presenta una alternativa totalmente distinta a la expuesta en este art´ıculo, utili-zando una arquitectura de memoria compartida.
Un estudio m´as detallado de algunas de estas soluciones se puede encontrar en [19].
2.1.3.
El servidor VoDKA
2.1.3.1. Caracter´ısticas generales de VoDKA
El sistema VoDKA es un servidor de streaming multimedia bajo demanda extremadamente flexible, pero optimizado para el entorno de una operadora de telecomunicaciones.
Caracter´ısticas principales:
Multiprotocolo: soporte para streaming de medios arbitrarios CBR por HTTP,
MPEG-4 y Quicktime sobre RTSP/RTP, MPEG Layer3 (MP3) sobre RTP, MP3 sobre Icecast y ASF sobre HTTP con control del medio.
Multiproveedor: previsi´on de m´ultiples proveedores de medios integrados en
una ´unica red de distribuci´on de contenidos, cada uno en su dominio admi-nistrativo.
Flexibilidad en el almacenamiento: posibilidad de utilizar almacenamiento
en disco o cinta propio, servidores webDAV [20] u otros servidores VoDKA encadenados como fuentes de medios.
Modularidad: el sistema est´a compuesto de una serie de m´odulos que se
inter-conectan de forma flexible para adaptarse a configuraciones muy diferentes.
Distribuido: los distintos componentes del sistema se comunican entre s´ı de
for-ma transparente a su localizaci´on. El servidor puede configurarse de forfor-ma adaptada a la topolog´ıa de red, reduciendo costes de despliegue. Adem´as, se modelan mediante funciones de coste las caracter´ısticas de red y equipos para optimizar la utilizaci´on de enlaces y equilibrar la carga, asegurando calidad de servicio.
Set Top Boxes 9
Escalabilidad: gracias a su arquitectura, es posible configurar tanto un
micro-servidor contenido en un equipo embebido como un cluster de cientos de nodos, e incluso metaclusters o agrupaciones de clusters.
2.1.3.2. Plataformas soportadas
La mayor parte de VoDKA est´a desarrollada en Erlang/OTP (Open Telecom
Platform). El c´odigo Erlang se ejecuta dentro de un runtime (ERTS), que incluye
una m´aquina virtual (en la que se ejecuta o bien bytecode o bien c´odigo nativo), bibliotecas y una interfaz al sistema operativo y al hardware com´un a todas las plataformas. Todos los m´odulos desarrollados en Erlang, por tanto, pueden, en principio, instalarse sobre cualquier plataforma soportada por el ERTS: Solaris, AIX, BSD, VxWorks, Win32 y Linux sobre m´ultiples arquitecturas (x86, SPARC, ARM, PowerPC, S/390).
Algunas partes de VoDKA est´an desarrolladas en C y C++ , y puede que no est´en disponibles para todas las arquitecturas.
2.1.3.3. Red de interconexi´on
Cuando una instalaci´on de VoDKA abarca m´as de un nodo f´ısico, se supone que existe una red IP que interconecta todos los nodos entre s´ı. Es posible, sin embargo, dividir la red de nodos VoDKA en clusters independientes, pero com-plica el mantenimiento.
En casos excepcionales es factible utilizar una red no IP, pero no es aconseja-ble en absoluto.
VoDKA utiliza toda la infraestructura del sistema operativo para acceder a la red, con lo que podr´a emplear cualquier interfaz soportado por ´este. Habitual-mente se desarrolla y prueba sobre interfaces Ethernet, Fast Ethernet y Gigabit Ethernet en Linux, y Fast Ethernet y ATM con LANE en Solaris.
2.2.
Set Top Boxes
2.2.1.
Introducci´
on
Un Set Top Box puede ser visto como un dispositivo que permite realizar ciertas operaciones como el acceso a Internet o la recepci´on de v´ıdeo digital desde el hogar, utilizando un televisor convencional como interfaz de salida y (posible-mente) un mando a distancia como dispositivo de entrada. En algunas ocasiones
se denomina a los Set Top Boxes como decodificadores, o IRDs.
Como ejemplos conocidos de Set Top Boxes se pueden citar los decodificado-res de Canal+, Canal Sat´elite, V´ıa Digital, Quiero TV, etc.
Internamente, un Set Top Box es similar a un ordenador personal convencio-nal, pero con algunas modificaciones para adaptarlo espec´ıficamente a la ejecuci´on de aplicaciones multimedia, como pueden ser decodificadores MPEG hardware, salidas de televisi´on digital, salida de audio est´ereo, puerto de infrarrojos para el mando a distancia, etc. Como medios de almacenamiento secundario pueden disponer de un disco duro y/o memoria flash. Tambi´en deben disponer de alg´un tipo de dispositivo de red para recibir la informaci´on multimedia, receptores de se˜nal de televisi´on y un dispositivo de acceso condicional para controlar la utili-zaci´on de los servicios de pago tales como el pago por visi´on.
xDSL video por cable Decodificador de
Decodificador MPEG
Interfaz HDD Disco Duro/Flash USB Unidad de Acceso Condicional Logica de Control Distribucion de reloj Memoria CPU Logica de Control y generacion de graficos Control de pantalla Codificador NTSC/PAL de audio DACs de video DACs Modem RS232 IEEE1394 video via satelite
Decodificador de
video via terrestre Decodificador de Control de E/S
Puerto de infrafojos
Figura 2.1: Configuraci´on interna de un Set Top Box
Sobre la capa hardware se apilan las capas software necesarias para el correcto funcionamiento del Set Top Box, de forma similar a como se har´ıa en un PC, como se puede ver en la figura 2.2.
1. Receptor de televisi´on digital : Dispositivos hardware necesarios para la
con-Set Top Boxes 11
Receptor de television digital Drivers Tiempo Real Sistema Operativo de Middleware API Plataforma Software
Aplicaciones Capa de aplicacion
Capa RTOS
Capa Hardware
Figura 2.2: Capas de un Set Top Box
templan los dispositivos b´asicos para el funcionamiento del sistema (memo-ria, CPU, etc), pero se denomina receptor de televisi´on digital para se˜nalar que no es una plataforma hardware gen´erica, sino que est´a orientada a esa tarea en particular.
2. Sistema Operativo: Se utilizan sistemas operativos de tiempo real (RTOS)
como pSOS, WindowsCE, Linux, VxWorks, OS20 o Nucleus.
3. Plataforma software: Tambi´en conocido como middleware. Conjunto de
m´odulos que facilitan un desarrollo m´as eficiente. Proporciona un API para cada lenguaje de programaci´on soportado. Para la implementaci´on del API, el middleware puede incluir un gestor de aplicaciones, una m´aquina virtual, las bibliotecas, el motor interactivo y las bases de datos.
4. Aplicaciones: Esta capa no necesita estar residente permanentemente, sino
que puede ser descargada bajo demanda.
Un Set Top Box est´a pensado para ser una m´aquina asequible, que el usuario colocar´a en su hogar cerca del televisor para que realice las tareas necesarias que permitan el disfrute de un servicio de v´ıdeo digital. Por lo tanto, es necesario aplicar ciertas restricciones sobre el hardware a utilizar.
Debe ser razonablemente econ´omico, esto implica que la CPU no tendr´a to-da la potencia de las ´ultimas generaciones adem´as de constre˜nir la cantito-dad de memoria RAM y la capacidad del dispositivo de almacenamiento secun-dario utilizado (disco duro o memoria flash).
No debe ser voluminoso ni ruidoso. Esta restricci´on afecta a la utilizaci´on de discos duros y de chips o fuentes de alimentaci´on que requieran dispositivos de ventilaci´on para su correcta refrigeraci´on.
Para compensar las restricciones de potencia de la CPU, se suelen incluir de-codificadores MPEG hardware para liberar a la CPU de la carga de esta tarea.
Para disminuir los costes, ruidos y consumo, los Set Top Boxes no suelen incluir disco duro, sino que utilizan memoria flash como dispositivo de almacena-miento secundario. Adem´as, es deseable que el bloque de memoria utilizado sea de la menor capacidad posible para no encarecer el sistema final.
2.2.2.
Middleware
En la actualidad existen varias organizaciones desarrolladoras de est´andares para el desarrollo de plataformas middleware.
DVB: El proyecto DVB [21] es un consorcio compuesto por alrededor de
300 operadores de v´ıdeo, operadores de red, desarrolladores de software, fabricantes, etc. creado para el desarrollo de est´andares para la transmisi´on de televisi´on digital y servicios de datos. De este proyecto han salido cuatro est´andares mundialmente aceptados:
• DVB-S Est´andar para la transmisi´on de v´ıdeo digital v´ıa sat´elite.
• DVB-T Est´andar para la transmisi´on de v´ıdeo digital por v´ıa terrestre.
Actualmente no est´a instaurado en Am´erica, en donde se utiliza ATSC, ni en Jap´on, en d´onde se sigue el est´andar ISDB-T.
• DVB-C Est´andar para la transmisi´on de v´ıdeo digital por cable.
• MHP Est´andar de televisi´on digital interactiva. Define un interfaz
gen´erico entre las aplicaciones interactivas y el terminal que las debe ejecutar. Un middleware que proporcione el interfaz MHP podr´a eje-cutar las aplicaciones desarrolladas de acuerdo con este est´andar inde-pendientemente de la plataforma hardware que utilice.
ATSC : Es una organizaci´on internacional sin ´animo de lucro para
Set Top Boxes 13 numerosos est´andares para transmisi´on de v´ıdeo, codificaci´on, compresi´on de audio digital, acceso condicional, etc. En cuanto a est´andar de
middle-ware ATSC ha propuesto el est´andar DASE [22].
OpenCable: Es una iniciativa para dotar a la industria de televisi´on por
cable de los est´andares necesarios para desarrollar servicios interactivos. Como est´andar de middleware propone OCAP [23].
JavaTV [24]: Especifica un API que proporciona una plataforma ideal de
desarrollo y utilizaci´on de aplicaciones sobre la plataforma Java. Dicho API proporciona operaciones para realizar streaming tanto de audio como de v´ıdeo, acceso condicional, control de canales y control de gr´aficos en panta-lla.
Algunas de las plataformas m´as utilizadas son:
OpenTV [25]: Es la plataforma m´as utilizada en la actualidad para el
desa-rrollo de sistemas de televisi´on digital sobre Set Top Boxes. Es una soluci´on comercial ampliamente utilizada por compa˜n´ıas de televisi´on interactiva. Proporciona la plataforma middleware, aplicaciones, herramientas de de-sarrollo y soporte t´ecnico. Las aplicaciones proporcionadas por OpenTV abarcan campos como el t-comercio, el streaming, telebanca, juegos, nave-gadores, etc. Es la tecnolog´ıa utilizada por el Set Top Box de V´ıa Digital y QueroTV.
Media Highway: Es un middleware propietario desarrollado por Canal+ Technologies [26]. Soporta los est´andares DVB, OpenCable, y ATSC. Puede
ejecutar aplicaciones interactivas escritas en lenguajes soportados por dichos est´andares como Java, HTML o XDML. Es el middleware que utiliza el Set
Top Box de Canal Sat´elite.
Alticast [27]: Construye aplicaciones de televisi´on digital para una cantidad
importante de proveedores en Asia. Su middleware soporta los est´andares de aplicaci´on MHP y DASE. Como m´aquina virtual en la que ejecutar las aplicaciones utiliza AltiJVM, que es una implementaci´on de la m´aquina virtual de Java.
TV Navigator : Desarrollado por Liberate [28], es un middleware con una
representaci´on importante en los Set Top Boxes de Estados Unidos. Soporta Java y HTML.
MSTV [29]: Es el middleware desarrollado por Microsoft. Engloba varios
productos como WebTV, PersonalTV y UltimateTV. Estos productos per-mitieron obtener a Microsoft el liderazgo en el mundo de la televisi´on inte-ractiva, pero con el tiempo han ido perdiendo viabilidad comercial y est´an siendo abandonados. Ahora, Microsoft concentra sus esfuerzos en un
mid-dleware basado en su sistema operativo WindowsCE para compa˜n´ıas de
cable.
NDS Core [30]: Middleware desarrollado por NDS, principalmente instalado
en Set Top Boxes de Am´erica Latina y Asia. Pretende ser compatible tanto con MHP como con OCAP y soporta Java y HTML.
2.2.3.
Funcionalidades t´ıpicas
Adem´as de la recepci´on y reproducci´on de canales de audio y v´ıdeo digital, los Set Top Boxes pueden realizar otro tipo de actividades como pueden ser la utilizaci´on de Internet, descarga de juegos, telecompra, telebanca, tienda virtual, solicitud de informaci´on de forma interactiva ...
Para los Set Top Boxes comerciales m´as conocidos en Espa˜na, las funcio-nalidades van desde la m´as b´asica del Set Top Box de Canal+ hasta las m´as avanzadas ofrecidas por Canal Sat´elite y V´ıa Digital.
El Set Top Box de Canal+ simplemente decodifica la se˜nal recibida para per-mitir al abonado visualizar la programaci´on que no se distribuye en abierto.
Los Set Top Boxes de Canal Sat´elite y V´ıa Digital ofrecen servicios interacti-vos, adem´as de proporcionar el acceso a los diferentes canales de v´ıdeo. Algunas de las operaciones que permiten realizar son:
Compra de estrenos o partidos. Consulta de informaci´on burs´atil. Operaciones bancarias.
Recarga de telefon´ıa.
Servicios de mensajes a m´oviles. Informaci´on deportiva.
Set Top Boxes 15 Comercio por televisi´on (t-comercio).
Teniendo en cuenta las posibilidades ofrecidas por un Set Top Box, se puede establecer la siguiente clasificaci´on:
Set Top Box para TV por broadcast: Es el nivel m´as b´asico de Set Top Box.
No dispone de canal de retorno, simplemente recibe una se˜nal de v´ıdeo que decodifica para que el usuario pueda disfrutarla (por ejemplo, el
decodifica-dor de Canal+).
Set Top Box para TV digital : Dispone de un canal de retorno para permitir
la interacci´on del usuario con el proveedor del servicio de TV.
Set Top Box avanzado: Tiene caracter´ısticas muy similares a un PC: tienen
una CPU potente, disco duro de gran capacidad, etc. Disponen de acceso de alta velocidad a Internet, posibilidad de grabaci´on digital de v´ıdeo, juegos, capacidad para el env´ıo y recepci´on de correo electr´onico, etc.
Sidecar : Proporciona un nuevo canal de recepci´on de datos para trabajar
conjuntamente con el canal recibido por el cliente en su Set Top Box origi-nal.
Set Top Box h´ıbrido: Set Top Box especializado para televisi´on por cable y
que incluye otras funciones, por ejemplo, reproducci´on de DVDs.
2.2.4.
Ejemplos comerciales
2.2.4.1. Prismiq MediaPlayer
Este Set Top Box obtiene medios audiovisuales de la red y los presenta de forma ordenada, permitiendo al usuario disfrutarlos en un televisor. Puede repro-ducir v´ıdeo en formato MPEG 1 y 2 y DIVX con ayuda de un PC.
La configuraci´on de este Set Top Box es bastante simple, ya que el trabajo de localizar, adaptar y enviar los medios lo realiza una aplicaci´on servidora que debe ser instalada en un PC:
CPU : microprocesador NEC uPD61130 32-bit MIPS con un decodificador
MPEG integrado.
Memoria: 64 megabytes de SDRAM
Figura 2.3: Prismiq MediaPlayer
Salidas de v´ıdeo: S-Video y v´ıdeo compuesto. Salidas de audio: S/P DIF y RCA (est´ereo).
Software: Linux 2.4, navegador y cliente AOL integrados.
2.2.4.2. Set Top Box de HMMI
En este Set Top Box se hicieron algunas pruebas al principio del proyecto, pero el soporte de framebuffer para la tarjeta gr´afica que tiene dio bastantes problemas y no se consigui´o hacer funcionar correctamente la aplicaci´on DFBCIn en ´el.
Figura 2.4: Set Top Box de HMMI
2.2.4.3. Shuttle Spacewalker XPC SS50
Este es el Set Top Box que se utiliz´o para la validaci´on del sistema, se le instal´o un receptor de infrarrojos para recibir la se˜nal del mando a distancia y
Programaci´on gr´afica en Linux 17 un disco duro para facilitar las pruebas. La configuraci´on original utiliza una memoria flash como almacenamiento secundario.
Figura 2.5: XPC SS50
Las caracter´ısticas de este Set Top Box son muy pr´oximas a las de un PC:
CPU : Intel Pentium 4 Socket478.
Tarjeta de sonido: C-Media Electronics Inc CM8738 integrada.
Tarjeta de v´ıdeo: Silicon Integrated Systems SiS650/AGP VGA Display
Adapter integrada.
Memoria: 2 slots DIMM con capacidad de hasta 2 gigabytes de memoria
DDR.
Interfaz de red: 10/100 Fast Ethernet integrada.
Salida de televisi´on/S-Video.
Slots de expansi´on AGP y PCI.
Puertos USB y Firewire.
2.3.
Programaci´
on gr´
afica en Linux
2.3.1.
Introducci´
on
Hoy en d´ıa, la programaci´on de interfaces gr´aficas para Linux se hace habi-tualmente sobre el sistema X Windows que proporciona una capa de abstracci´on
sobre el hardware gr´afico y un API para desarrollar interfaces basadas en venta-nas y eventos (tanto de teclado como de rat´on).
El sistema X Windows se ha transformado en el est´andar de facto para la programaci´on gr´afica en Linux y Unix. X Windows permite el desarrollo de apli-caciones gr´aficas independientes del sistema operativo y la plataforma hardware, es transparente a la red y soporta numerosos entornos de escritorio muy popula-res hoy en d´ıa.
Sin embargo, La utilizaci´on del sistema X Windows supondr´ıa una sobrecarga demasiado pesada para el Set Top Box. Como se dijo en la secci´on 2.2.1, un siste-ma de este tipo debe ser asequible y silencioso, lo que implica poco espacio en el almacenamiento secundario y una CPU de potencia limitada. Para aprovechar el
hardware disponible ser´a necesario utilizar alg´un framework de orientaci´on menos
gen´erica que X Windows.
Por lo tanto ser´a necesario buscar otras alternativas para la programaci´on de la interfaz gr´afica. La idea es bajar el nivel de programaci´on y acceder direc-tamente al hardware gr´afico. Se utilizar´a un lenguaje de nivel medio-bajo para escribir directamente en el framebuffer (ver la secci´on 2.3.2).
Sin embargo, trabajar directamente sobre el framebuffer es complicado y hace el c´odigo dependiente de la plataforma (si se quieren utilizar las posibilidades de aceleraci´on gr´afica). Por ello, se han estudiado distintos frameworks que propor-cionen una mayor abstracci´on en forma de un API independiente del hardware gr´afico.
Las opciones estudiadas fueron:
Microwindows [31]: Proporciona un API escrito en C que permite realizar
operaciones gr´aficas b´asicas (rect´angulos, c´ırculos, ...) y operaciones con ventanas. Est´a orientado a la implementaci´on de aplicaciones gr´aficas con ventanas, pero prescindiendo de sistemas como Microsoft Windows o X
Windows.
Qt [32]: Proporciona un API C++ y una gran colecci´on de objetos que
permiten realizar aplicaciones con un look and feel nativo independien-te de la plataforma. Para esindependien-te proyecto se estudi´o su versi´on embebida (Qt/Embedded), que trabaja directamente sobre el framebuffer para evitar sobrecargas.
Programaci´on gr´afica en Linux 19
DirectFB [33]: Proporciona un API escrito en C, pero con dise˜no objetual.
Est´a pensado para realizar operaciones gr´aficas con aceleraci´on, evitando la utilizaci´on del sistema X Windows, en favor de la utilizaci´on del dispositivo
framebuffer directamente [1]. Proporciona una abstracci´on de proveedor de
imagen, de proveedor de fuentes y de proveedor de v´ıdeo; Tiene operacio-nes para manejar la entrada ya sea por teclado, mando a distancia, rat´on, joystick o pantalla t´actil y define un sistema de gestor de ventanas.
El framework elegido para la programaci´on gr´afica fue DirectFB, ya que proporciona muchas opciones interesantes para el desarrollo de software para un
Set Top Box. Principalmente, la opci´on m´as ´util es la abstracci´on que
propor-ciona para el manejo de v´ıdeo, que desacopla la aplicaci´on del formato de v´ıdeo utilizado.
2.3.2.
Framebuffer
El framebuffer es una parte de la memoria RAM de la computadora en la que se almacena la informaci´on para una imagen o frame. Esta informaci´on consiste t´ıpicamente en los valores de color para cada pixel de la pantalla.
El kernel de Linux ha incorporado (a partir de su versi´on 2.1.107) el disposi-tivo framebuffer [34], con el que permite la programaci´on gr´afica en una consola. Este dispositivo fue desarrollado con el objetivo inicial de permitir al kernel de Linux emular una consola de texto en sistemas como Apple Macintosh, que no soportan el modo texto VGA. Finalmente, el dispositivo framebuffer pas´o a estar completamente integrado en el kernel de Linux y se espera que llegue a ser el modo est´andar de acceso al hardware gr´afico.
El dispositivo framebuffer presenta una abstracci´on del hardware gr´afico y permite a las aplicaciones software acceder al hardware gr´afico utilizando una interfaz bien definida. De esta forma, el software no necesita conocer los detalles de bajo nivel (registros hardware), excepto para la aceleraci´on hardware.
La utilizaci´on del dispositivo framebuffer supone las siguientes ventajas: Proporciona un m´etodo unificado para el acceso al hardware gr´afico a trav´es de diferentes plataformas.
Los controladores pueden ser compartidos entre distintas arquitecturas, lo que disminuye la duplicaci´on de c´odigo.
Proporciona control tanto para una como para varias pantallas activadas, se soportan hasta 8 dispositivos framebuffer (8 pantallas).
El dispositivo framebuffer puede ser utilizado desde el espacio de usuario accediendo al dispositivo especial /dev/fb[0-7], de la misma forma que se accede al resto de dispositivos.
E/S normal: Se puede acceder a los contenidos del framebuffer mediante
las operaciones de lectura y escritura read() y write().
nmap: Utilizando la llamada nmap() se puede hacer mapping de los
conte-nidos del framebuffer en la memoria de usuario, de forma que el framebuffer se vuelve una pieza de memoria accesible. Tambi´en se puede hacer mapping de los registros MMIO en el espacio de usuario, pero para ello es necesa-rio desactivar la aceleraci´on hardware para la consola de texto para evitar conflictos en el acceso a dichos registros.
ioclt: La llamada ioctl() permite realizar otro tipo de operaciones
co-mo cambiar el co-modo gr´afico, obtener informaci´on sobre el hardware subya-cente... Cada dispositivo framebuffer particular puede definir ioctls para operaciones especificas del dispositivo de ser necesario.
No hay c´odigo gen´erico de aceleraci´on gr´afica en el kernel (solo para consola de texto), todas las operaciones gen´ericas de aceleraci´on hardware deber´an hacerse desde el espacio de usuario utilizando mapping sobre los registros MMIO.
2.3.3.
Microwindows
Microwindows [31] es un proyecto de C´odigo Abierto que tiene como
objeti-vo dotar las caracter´ısticas de los sistemas de ventanas modernos a dispositiobjeti-vos y plataformas m´as peque˜nos. Permite desarrollar aplicaciones y probarlas en el escritorio de Linux para luego compilarlas para el dispositivo deseado.
Proporciona dos APIs, uno compatible con el API del sistema de ventanas de los sistemas Win32/WinCE, llamado Microwindows, y otro similar al de Xlib, la biblioteca de desarrollo de aplicaciones para el sistema X Windows, llamado
Nano-X. Bajo Linux es m´as utilizado el API Nano-X ya que soporta la
arquitec-tura cliente-servidor.
Actualmente funciona en sistemas Linux de 32 bits utilizando el soporte
Programaci´on gr´afica en Linux 21
desarrollo) y utilizando la biblioteca SVGAlib1. Adicionalmente, Microwindows
ha sido portado para los sistemas operativos ELKS (Linux embebido de 16 bits), MS-DOS, tanto en modo protegido como en modo real, y RTEMS (sistema ope-rativo de tiempo real).
Las desventajas que presenta este framework con respecto a los objetivos que se persiguen en este proyecto son:
Est´a orientado a la creaci´on de interfaces con ventanas. La interfaz que se pretende desarrollar est´a basada en un sistema de men´us a pantalla completa.
El API proporcionado no es orientado a objetos, esto complicar´ıa la es-tructuraci´on del c´odigo, obligando a la implementaci´on de una biblioteca propia para ocultar la utilizaci´on de este framework al resto del c´odigo de la aplicaci´on.
No proporciona operaciones de alto nivel como la reproducci´on de v´ıdeo, aunque s´ı tiene operaciones para manipular im´agenes y fuentes.
2.3.4.
Qt
Qt es un [32] framework para la creaci´on de aplicaciones e interfaces gr´aficas multiplataforma. Incluye una biblioteca C++ y herramientas para facilitar el de-sarrollo r´apido de aplicaciones.
La biblioteca C++ proporciona una gran cantidad de clases completamente funcionales e interfaces consistentes. Est´a desarrollada totalmente siguiendo el paradigma de orientaci´on a objetos.
Las aplicaciones hechas con Qt se ejecutar´an nativamente en las plataformas soportadas, las aplicaciones podr´an ser portadas a nuevas plataformas simplemen-te recompil´andolas con la bibliosimplemen-teca Qt correspondiensimplemen-te a la nueva plataforma.
Este framework se distribuye para cuatro tipos de sistemas:
Qt/Windows: Permite compilar las aplicaciones Qt para Microsoft Windows
95/98/Me, NT4, 2000 y XP.
Qt/X11 : Para Linux, Solaris, HP-UX, IRIX, AIX y otras variantes de UNIX.
1biblioteca que facilita el acceso a hardware de v´ıdeo compatible con los est´andares VGA y
Qt/Mac: Aplicaciones que funcionen sobre Apple Mac OS X.
Qt/Embedded: Sistemas Linux embebidos utilizando el framebuffer en lugar
del sistema X Windows como hace Qt/X11.
La soluci´on estudiada para el desarrollo del proyecto fue Qt/Embedded. Este framework no utiliza capas de emulaci´on ni m´aquinas virtuales para po-sibilitar la portabilidad, cada edici´on es una implementaci´on en c´odigo nativo del API ofrecido.
La utilizaci´on de Qt ofrece las siguientes ventajas:
Independencia real de plataforma. Para este proyecto no es especialmente importante, ya que la aplicaci´on se desarrollar´a s´olo para sistemas embebi-dos.
Acceso a bases de datos utilizando un API independiente para bases de datos SQL. Esta caracter´ıstica tampoco es necesaria para el software a desarrollar en este proyecto.
Posibilidad de desarrollo r´apido de aplicaciones. La plataforma Qt propor-ciona herramientas de productividad como QtDesigner, una herramienta para desarrollar interfaces gr´aficas.
Soporta internacionalizaci´on.
Velocidad de ejecuci´on (se ejecuta en c´odigo nativo). Aspecto visual (look and feel) configurable.
Incluye m´odulos de espacio de trabajo (soporte MDI), vista de iconos, redes, XML, canvas, OpenGL, ...
Sin embargo, Qt fue rechazado por dos razones:
Est´a orientado al desarrollo de interfaces gr´aficas basadas en la utilizaci´on de ventanas. Como se coment´o en la secci´on anterior, la interfaz que se desarrollar´a no ser´a basada en ventanas, sino que estar´a formada por varios men´us a pantalla completa.
Es una soluci´on demasiado “grande”. Est´a pensado para realizar aplicacio-nes con interfaces visuales complejas y que se puedan ejecutar en diferentes plataformas. Para este proyecto interesa una soluci´on m´as ajustada, para respetar las restricciones de espacio presentadas por los Set Top Boxes.
DirectFB 23
2.4.
DirectFB
2.4.1.
Introducci´
on
DirectFB [1] es una biblioteca ligera desarrollada teniendo en cuenta las ne-cesidades especiales de los sistemas embebidos. Proporciona aceleraci´on gr´afica, control y abstracci´on de dispositivos de entrada, sistema de ventanas integrado y soporte de m´ultiples capas visuales sobre el dispositivo framebuffer de Linux.
Es una capa de abstracci´on completa, que incluye la utilizaci´on de operacio-nes software para aquellos casos en los que la operaci´on no est´e soportada por el
hardware subyacente.
Tambi´en proporciona un sistema de ventanas integrado, que permite la crea-ci´on de ventanas transl´ucidas.
Proporciona las siguientes operaciones gr´aficas aceleradas por hardware: Dibujo/relleno de rect´angulos.
Dibujo/relleno de tri´angulos. Dibujo de l´ıneas.
Copia de im´agenes (blitting) tanto el´astica como directa. Mezcla con un canal alpha (alpha blending).
Mezcla con un valor alpha constante (alpha modulation).
Nueve funciones de mezcla para el origen y el destino respectivamente. Modulaci´on por color (colorizing).
Copia basada en color (color keying) tanto para el origen como para el destino.
DirectFB tiene su propia gesti´on de recursos de memoria de v´ıdeo, de forma que recursos como capas visuales, dispositivos de entrada o superficies pueden ser bloqueados para acceso exclusivo. Proporciona abstracciones para los diferentes objetos gr´aficos, tales como capas, superficies y ventanas. Esto permite la selec-ci´on entre aplicaciones basadas en ventanas o aplicaciones pensadas para pantalla completa.
El API de DirectFB est´a dise˜nado para facilitar la creaci´on de plugins que implementen las siguientes partes:
Aceleraci´on gr´afica: Las operaciones que no puedan ser realizadas por hard-ware (seg´un la implementaci´on existente para el hardhard-ware que se est´e
uti-lizando) ser´an realizadas por software. Soporta las tarjetas gr´aficas Matrox G200/G400/G450/G550, ATI128, Vodoo 3, NeoMagic, nVidia RIVA TNT, S3 Savage y Cyber Pro, aunque para algunas no est´a soportada la acelera-ci´on para todas las operaciones. Cualquier otra tarjeta puede ser utilizada sin aceleraci´on hardware, ya sea utilizando un dispositivo framebuffer es-pec´ıfico o el framebuffer gen´erico VESA.
Dispositivos de entrada: Permite abstraer el concepto de dispositivo de
en-trada, de forma que los programas no tengan que preocuparse del hardware utilizado, s´olo deber´an tener en cuenta los eventos generados. Actualmente, los dispositivos de entrada soportados son teclado, ratones serie y PS/2,
joysticks, pantallas t´actiles y dispositivos remotos por infrarrojos.
Proveedor de imagen: Abstrae el concepto de imagen de forma que las
apli-caciones no tengan que preocuparse del formato utilizado por la imagen que desean mostrar. Soporta los formatos JPEG, PNG, GIF y MPEG2 I-Frame.
Proveedor de v´ıdeo: La misma idea, pero para archivos de v´ıdeo. Puede
reproducir v´ıdeos en formato MPEG1/2, AVI, Macromedia Flash y Open-quickTime. Tambi´en soporta Video4Linux.
Proveedor de fuentes: Permite utilizar distintos tipos de fuente de forma
homog´enea. Soporta el formato propio de fuentes de DirectFB y fuentes
TrueType.
2.4.2.
Arquitectura
DirectFB utiliza la interfaz proporcionada por el dispositivo framebuffer de Linux para acceder al hardware gr´afico. Hay controladores especiales para los
framebuffers de ciertos dispositivos integrados en el kernel de Linux, el resto de
dispositivos funcionar´an tambi´en utilizando el controlador para el framebuffer VESA, pero con ciertas limitaciones.
Independientemente de que se utilice aceleraci´on gr´afica o no, DirectFB utilizar´a el dispositivo framebuffer para realizar las siguientes operaciones:
Establecer el modo de v´ıdeo (resoluci´on, profundidad de color y temporiza-ciones).
DirectFB 25
Mapping de la memoria del framebuffer de la tarjeta.
Cambios en el ´area visible (viewport) del framebuffer para soportar doble
buffering. De esta forma se podr´an realizar cambios en un ´area no visible
y hacerla visible de forma s´ıncrona con el barrido del monitor para evitar efectos visuales desagradables.
Si la tarjeta est´a soportada por DirectFB y el controlador para el chipset est´a presente en el kernel, DirectFB tambi´en usar´a el dispositivo framebuffer para las siguientes tareas:
Mapping de memoria de los puertos de entrada/salida de las tarjetas.
Desactivaci´on de la aceleraci´on interna del dispositivo framebuffer.
Para ejecutar una operaci´on gr´afica espec´ıfica, el controlador de DirectFB har´a un mapping de los puertos de entrada/salida de la tarjeta en memoria para transmitir la operaci´on concreta a realizar. Como se dijo en la secci´on 2.3.2, la aceleraci´on hardware se programa completamente desde el espacio de usuario. Ver la figura 2.6. Aplicacion DirectFB registros de temporizacion y framebuffer modo de video motor de aceleracion DirectFB Controlador para el chipset
Desactivado mientras se ejecute una aplicacion DirectFB Solo se aplica cuando se utiliza la consola del framebuffer
Espacio del Usuario
Espacio del kernel
Hardware grafico
Controlador para el dispositivo framebuffer
Figura 2.6: Acceso de una aplicaci´on DirectFB al hardware gr´afico Para acceder a los dispositivos de entrada, DirectFB utiliza las interfaces est´andar que Linux proporciona para los distintos dispositivos. DirectFB no accede nunca al hardware de entrada directamente.
2.4.3.
T´
erminos importantes
Blitting: Se refiere al proceso de copiar datos de una imagen. El caso m´as simple
es copiar una imagen de una superficie a otra cuando ambas superficies tiene el mismo tama˜no y el mismo formato de pixel. En este caso solamente tiene que ser copiada la memoria sin ning´un tipo de procesado. Otros casos m´as avanzados son la copia el´astica (stretch blitting) entre superficies de distinto tama˜no, la copia con canal alpha o copia con cambio de formato de pixels. La mayor´ıa de las tarjetas gr´aficas incluyen un blitter hardware capaz de realizar diversas operaciones de copia.
Superficie: Es un zona de memoria reservada en la que se almacena la
informa-ci´on sobre los pixels de una imagen en un formato espec´ıfico. Una superficie puede residir en la memoria de v´ıdeo y/o en la memoria del sistema. Es posible realizar operaciones de dibujo sobre una superficie, o copiar una su-perficie en otra, como se explic´o anteriormente. Adicionalmente cada super-ficie puede utilizar un doble buffer de gr´aficos, de forma que las operaciones realizadas sobre ella s´olo se vuelven v´alidas cuando se llama a una funci´on para cambiar el buffer visible.
En el modo de pantalla completa, la pantalla visible es representada por la “Superficie Primaria”. Esta superficie normalmente dispondr´a de doble
buffer para evitar efectos desagradables cuando se realicen operaciones sobre
ella.
Subsuperficie: Presenta el mismo interfaz que una superficie normal, pero no
tiene memoria reservada para s´ı misma.
Capa: Dependiendo del hardware gr´afico, puede haber una o m´as capas visibles.
La mayor´ıa de las tarjetas gr´aficas de PC s´olo disponen de una capa, pero la tarjeta de un Set Top Box puede soportar dos o m´as capas. Las capas ocupan diferentes posiciones en la memoria de v´ıdeo y suelen ser combinadas utilizando mezcla alpha, esto lo hace el hardware autom´aticamente.
Ventana: Normalmente, los contenidos de una superficie de una capa son
con-trolados por el sistema de ventanas integrado que muestra las ventanas pertenecientes a la capa sobre un fondo configurable. Cada ventana tiene su propia superficie que es utilizada por el sistema de ventanas para compo-ner la imagen de ventanas superpuestas. Alternativamente, las aplicaciones pueden obtener acceso exclusivo a la capa, de esta forma la aplicaci´on tiene acceso directo a la capa y a su contenido, no se muestran ventanas ni fondos. Esta ser´a la forma en la que se desarrollar´a el software de este proyecto.
DirectFB 27
2.4.4.
API
El API de DirectFB est´a estructurado utilizando interfaces. Una interfaz es una estructura C que contiene punteros a funciones. Dependiendo de la imple-mentaci´on de dicha interfaz, estos punteros apuntar´an a distintas funciones. Por ejemplo IDirectFBSurface puede representar la pantalla completa, los conteni-dos de una ventana o una subsuperficie.
IDirectFB es la “Super Interfaz”. Es la ´unica que puede ser creada por una funci´on global (DirectFBCreate). El resto de interfaces ser´an creadas llamando a funciones de IDirectFB o a funciones de interfaces ya creadas. Se puede acce-der a las interfaces existentes (por ejemplo los dispositivos de entrada) a trav´es de IDirectFB. En la figura 2.7 se puede observar la relaci´on entre las distintas interfaces de DirectFB. IDirectFBSurface IDirectFBInputDevice IDirectFBDisplayLayer IDirectFBImageProvider IDirectFBVideoProvider IDirectFBFont IDirectFBInputBuffer IDirectFBWindow «super interface>> IDirectFB Crear Obtener Obtener Obtener Obtener Crear Crear Crear
Figura 2.7: Relaci´on entre las interfaces de DirectFB
Ciertas interfaces est´an implementadas como m´odulos que ser´an cargados en tiempo de ejecuci´on en caso de que sea necesario. Las interfaces implementa-das de esta forma son IDirectFBImageProvider, IDirectFBVideoProvider e IDirectFBFont. La aplicaci´on cargar´a la implementaci´on necesaria en cuando se construya la interfaz.
Otras interfaces tambi´en implementadas como m´odulos ser´an cargadas duran-te la inicializaci´on de la aplicaci´on. Estas induran-terfaces son IDirectFBInputDevice y GfxCard (interfaz interna inaccesible para las aplicaciones, que contiene el c´odigo encargado de utilizar la aceleraci´on hardware en caso de que sea posible).
De esta forma se podr´an a˜nadir nuevas implementaciones de controlador de aceleraci´on, dispositivos de entrada y proveedores de medios sin necesidad de recompilar ni DirectFB ni la aplicaci´on.
Cap´ıtulo 3
An´
alisis
´Indice General
3.1. Introducci´on . . . 29
3.2. Protocolo de comunicaci´on . . . 30
3.3. Set Top Box . . . 31
3.4. Aplicaci´on DFBCIn . . . 32 3.4.1. Introducci´on . . . 32 3.4.2. M´odulo gr´afico . . . 32 3.4.3. Parser . . . . 34 3.4.4. Conclusiones . . . 35 3.5. Servidor XML (VXMLS) . . . 36 3.6. Ciclo de Desarrollo . . . 37 3.6.1. Introducci´on . . . 37 3.6.2. Prototipo . . . 37 3.6.3. DFBCIn . . . 39 3.6.4. VXMLS . . . 40
3.6.5. Prueba del sistema conjunto . . . 40
3.1.
Introducci´
on
El objetivo principal de este proyecto es el desarrollo de un sistema que per-mita al usuario final el acceso de forma controlada a los medios disponibles en el
servidor de VoD VoDKA.
Por lo tanto, se necesita un dispositivo que act´ue como mediador entre el usua-rio y el servidor VoD. Es deseable que dicha interacci´on pueda ser controlada de forma remota y centralizada, de forma que pueda adaptarse seg´un las condiciones del entorno. Esto nos lleva a la necesidad de implementar otro dispositivo adi-cional que permita definir el protocolo de interacci´on que se presentar´a al usuario. As´ı pues, este proyecto se analizar´a dividido en dos subproyectos: el desarrollo de un Set Top Box y el de un servidor que proporcione a dicho Set Top Box la informaci´on necesaria para controla la interacci´on con el usuario.
Esta separaci´on supone la necesidad de definir un protocolo de comunicaci´on entre el Set Top Box y el servidor de “definiciones de interfaz”. Para estable-cer dicho protocolo, se han utilizado los est´andares HTTP [35] y XML [36], lo que permitir´a la utilizaci´on de herramientas ya existentes para el desarrollo del
software necesario.
3.2.
Protocolo de comunicaci´
on
Para definir el protocolo de comunicaci´on entre el Set Top Box y el servidor de “definiciones de interfaz” se necesita especificar:
El sistema de comunicaci´on: Se utilizar´a el protocolo HTTP sobre una
co-nexi´on TCP convencional. El Set Top Box actuar´a como cliente, solicitando la informaci´on que necesite mediante peticiones HTTP al servidor.
La estructura de la informaci´on: Se utilizar´a el est´andar XML. El servidor
devolver´a la informaci´on requerida por el cliente enviando un documento XML en una respuesta HTTP.
El est´andar XML permite especificar la estructura que debe tener un docu-mento de forma independiente de su contenido. Hay diferentes formas de expresar la estructura de un documento XML, en este proyecto se utilizar´an DTDs [36] para definir la forma en la que los documentos deben expresar la informaci´on requerida.
El servidor de “definiciones de interfaz” (servidor XML de aqu´ı en adelante) necesitar´a expresar dos tipos de respuestas: la definici´on de la interfaz solicitada por el Set Top Box y los mensajes de confirmaci´on o de error para el resto de
Aplicaci´on DFBCIn 31 operaciones que el Set Top Box pueda solicitarle (por ejemplo, iniciar la sesi´on).
La estructura del documento de confirmaci´on simplemente tiene que compro-bar dos casos: ´exito o fracaso.
Los documentos utilizados para definir la interfaz son bastante m´as complejos. Deben poder expresar tanto el aspecto visual como la funcionalidad a realizar por la interfaz definida. Por lo tanto, debe dise˜narse una estructura que sea f´acilmente extensible, para no constre˜nir el aumento de funcionalidades del Set Top Box.
3.3.
Set Top Box
El desarrollo del Set Top Box debe tener como objetivo un sistema que sea capaz de realizar las siguientes tareas:
Comunicarse con el servidor VXMLS para obtener la informaci´on necesaria sobre la interfaz a presentar al usuario. Esta interfaz debe lo suficientemente clara y sencilla, de forma que no suponga ninguna dificultad para cualquier tipo de usuario.
Presentar dicha interfaz al usuario en un televisor convencional y permitirle interactuar con ella a trav´es de un mando a distancia.
Reproducir v´ıdeo recibido del servidor VoD VoDKA. Debe ser un sistema razonablemente econ´omico.
El software se desarrollar´a de forma que no sea dependiente de la plataforma, deber´a ser posible ejecutarlo en cualquier Set Top Box que disponga de una salida para televisi´on y una tarjeta de red.
Como sistema operativo se utilizar´a Linux. Para respetar las restricciones de espacio ser´a necesario evitar el sistema X Windows, por lo que la programaci´on gr´afica se har´a accediendo directamente al hardware mediante el dispositivo
fra-mebuffer de Linux (ver la secci´on 2.3).
Para controlar la interacci´on con el usuario y la comunicaci´on con el servidor XML se desarrollar´a una ´unica aplicaci´on llamada DFBCIn (DirectFB C In-terface).
La comunicaci´on con el servidor VoD se ocultar´a al resto del sistema utilizando el proyecto desarrollado en [37] que permite manejar un v´ıdeo servido con el m´etodo de streaming como si se tratara de un fichero local.
