Download dit/UPM - Universidad Politécnica de Madrid
Document related concepts
no text concepts found
Transcript
UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN DEPARTAMENTO DE INGENIERÍA DE SISTEMAS TELEMÁTICOS Título: “Desarrollo de un servicio de acceso y presentación de contenidos multimedia personales e interactivos” Autor: D. Bonifacio García Gutiérrez Tutor: D. José Luís Ruiz Revuelta Ponente: D. Juan Carlos Dueñas López Departamento: Departamento de Ingeniería de Sistemas Telemáticos Tribunal calificador: • Presidente: D. Pedro Alonso Martín • Vocal: D. Santiago Pavón Gómez • Secretario: D. Juan Carlos Dueñas López • Suplente: D. Juan Carlos Yelmo García Fecha de lectura: Calificación: Proyecto Fin de Carrera Desarrollo de un servicio de acceso y presentación de contenidos multimedia personales e interactivos Autor: Bonifacio García Gutiérrez Tutor: José Luís Pérez Revuelta Ponente: Juan Carlos Dueñas López UPM - Universidad Politécnica de Madrid ETSIT - Escuela Técnica Superior de Ingenieros de Telecomunicación DIT - Departamento de Ingeniería de Sistemas Telemáticos Junio 2005 A mi madre, añorada día a día. Agradecimientos Todo el mundo que me conoce sabe que los últimos años han sido duros, muy duros para mí y para mi familia. Todo se ha hecho más difícil, incluida la realización de este Proyecto Fin de Carrera. Ahora que por fin he llegado al final, sólo puedo tener palabras de agradecimiento para la toda la gente que ha estado conmigo y me ha apoyado. En primer lugar tengo que dar las gracias a José Luís Ruiz y Juan Carlos Dueñas, tutor y ponente de este proyecto respectivamente. Gracias JL por toda tu ayuda, consejos, y por todo el trabajo que has realizado conmigo. Gracias JC por hacer posible este proyecto. A ambos muchas gracias por vuestra comprensión en determinadas fases del mismo. Gracias a toda la comunidad del software libre. Sin el trabajo de tantas personas dispuestas a compartir su trabajo y conocimientos, serían imposibles proyectos como este. De la gente de la universidad, no puedo pasar por alto la inestimable ayuda de Manuel Santillán. Muchas gracias por ayudarme en el desarrollo del modelo de canales y demás. Muchas gracias a Vaishali por su ayuda con la traducción, así como por su incondicional apoyo. También a Rodrigo Cerón, José Luís Arciniegas, Lucy, Rafael Barriuso (a.k.a. Barrix), José María del Álamo, Carol Antón, Xavier Cenoz, y la gente del DAT (de cuyos nombres no puedo acordarme). Un saludo también para mis compañeros de trabajo, que durante los últimos meses me han oído repetir una y otra vez la misma frase: “ya tengo el proyecto casi acabado”. A todos mis amigos de Leganés. Ya son casi diez años los que llevamos juntos pero parece toda una vida. Muchas gracias por estar siempre ahí, y por ayudarme a reír de vez en cuando. El mayor de los agradecimientos es para toda mi familia. A mi padre y hermanas, así como para mis abuelos, tíos, primos, y demás. A todos nos gustaría que las cosas fueran de otra manera. Nada puede ya cambiar lo ocurrido, y tampoco hay forma alguna de aplacar tanto dolor. Sólo quiero daros las gracias por hacerme sentir tan querido y arropado en todo momento. El agradecimiento más especial es para la personita que se ha convertido en la principal razón de alegría para toda mi familia. Ella es Andrea, y es la cosa más bonita que he visto en 25 años y pico. A todos, gracias. Boni Resumen La convergencia de los sectores de las telecomunicaciones, la informática y el audiovisual gracias a las redes de banda ancha es una tendencia bastante consolidada. Esta situación hace que los operadores tradicionales ya no abarcan toda la cadena de valor, y aparecen nuevos servicios convergentes que incluyen voz, datos, audio, vídeo, control, etc. En este escenario, los servicios audiovisuales se apartan cada vez más del modelo tradicional. Aparece así un amplio abanico de nuevas posibilidades, como por ejemplo vídeo bajo demanda, servicios interactivos añadidos, y un largo etcétera. Por otro lado, se está produciendo un aumento del equipamiento electrónico de los hogares: informático, audiovisual, de comunicaciones, domótico, etc. Ahora se impone la necesidad de conectar estos dispositivos electrónicos entre sí (Home Networking) con el exterior (Internet) para poder disfrutar de servicios cada vez más avanzados. El Hogar Digital es la materialización de esta idea de convergencia de servicios, y el elemento que integra las distintas redes domésticas y las interconecta con el exterior es conocido como “pasarela residencial”. En este ámbito nace OSGi (Open Services Gateway Initiative). OSGi es un grupo de trabajo creado en Marzo de 1999, cuyo objetivo es especificar y promocionar un entorno software para el desarrollo de pasarelas residenciales. El estándar OSGi define una arquitectura software que se ejecuta en una pasarela residencial. También ha experimentado un crecimiento importante el movimiento de software libre. Si bien el software libre no es un fenómeno nuevo ya que existe desde los orígenes de la informática, sí es relativamente reciente su modelo cooperativo de producción en red y el movimiento social que lo avala (comunidad del software libre). Ligado a la extensión de Internet y a la popularización de los ordenadores personales, el movimiento del software libre ha alcanzado su masa crítica, y ha dejado de ser sólo cosa de algunos programadores para convertirse en un fenómeno de cooperación social liberada. Partiendo de estas tres realidades (convergencia, hogar digital y software libre) y centrándonos en los servicios audiovisuales, este Proyecto Fin de Carrera presenta una solución para un servicio convergente audiovisual a través de pasarela residencial. Tomando como modelo de trabajo la filosofía de código abierto (open source), se ha desarrollado un reproductor de contenidos multimedia, con el valor añadido de la interactividad y la personalización, todo ello ofrecido a través de una pasarela residencial OSGi. Palabras clave Pasarela Residencial, Hogar Digital, Código Abierto, OSGi, Java, JMF, Multimedia, Reproductor de audio y vídeo, Streaming, Personal, Interactivo, piPlayer. Abstract The telecommunications, informatics and audiovisual sectors convergence has become a big tendency due to broadband networks. As a consequence, traditional operators no longer include the whole value chain and new convergent services appear. These services include voice, data, audio, video, control, etc. Therefore, the audiovisual services keep on diverting from the traditional model and a large amount of new possibilities are open, such as video on demand, interactive services, etc. On other hand, electronic equipment increase is taking place in all households: personal computers, audiovisual, communications, domotics, etc. In order to enjoy more advanced services, it is necessary to connect electronic devices to each other (Home Networking) and to the outside world (Internet). This idea's materialization, the idea of services convergence is the Digital Home, whereas the Service Gateway is the element that combines the different domestic networks and interconnects them with the outside. This is where OSGi is born (Open Services Gateway Initiative). OSGi is a work group created in March 1999. Its aim is to specify and promote software surroundings for service gateways' development. The OSGi standard defines a software architecture, executed in a service gateway. The free software movement has also experienced an important growth. Free software is not a new phenomenon; it exists from the origins of computer science. But its cooperative production model in network and the social movement that guarantees it (open source community) is relatively recent. Joining this to Internet's extension and the personal computers's increase, the free software movement has reached its critical mass. It has stopped being something related to just some programmers and become a released social cooperation phenomenon. The combination off of these three realities (convergence, digital home and free software) and specifying in audiovisual services, this Master Thesis introduces a solution for an audiovisual convergent service through service gateway. A OSGicompliant multimedia player has been developed taking as work model the open source philosophy and adding and interactive and personalized value through a service gateway. Keywords Service Gateway, Digital Home, Open Source, OSGi, Java, JMF, Multimedia, Video/Audio Player, Streaming, Personal, Interactive, piPlayer. Índice 1. Introducción.................................................................................................................1 1.1. Presentación ........................................................................................................1 1.2. Objetivos ..............................................................................................................4 1.3. Plan de proyecto ..................................................................................................5 1.4. Estructura del documento ....................................................................................6 2. Estado del arte ............................................................................................................8 2.1. Convergencia del sector audiovisual....................................................................8 2.1.1. TV Digital.......................................................................................................8 2.1.1.1. TV analógica ..........................................................................................9 2.1.1.2. TV digital ................................................................................................9 2.1.1.3. Ventajas de la TV digital.......................................................................10 2.1.1.4. Estandarización ....................................................................................11 2.1.1.5. Tipos de TVD........................................................................................11 2.1.1.6. Agentes de la TVD ...............................................................................12 2.1.1.6.1. STB................................................................................................14 2.1.1.6.2. PVR ...............................................................................................16 2.1.1.6.3. Antenas colectivas.........................................................................17 2.1.1.7. Legislación TVD ...................................................................................18 2.1.2. MHP ............................................................................................................19 2.1.2.1. Introducción ..........................................................................................19 2.1.2.2. DVB ......................................................................................................20 2.1.2.3. Especificación MHP..............................................................................22 2.1.2.3.1. Perfiles MHP..................................................................................22 2.1.2.3.4. Arquitectura MHP ..........................................................................24 2.1.2.3.5. Software del sistema (middleware) ...............................................25 2.1.2.3.6. API MHP........................................................................................26 2.1.2.3.7. El gestor de aplicaciones...............................................................28 2.1.2.3.8. La tabla AIT ...................................................................................28 2.1.3. Formatos multimedia...................................................................................29 2.1.3.1. Formatos contenedores........................................................................29 2.1.3.1.1. AVI.................................................................................................29 2.1.3.1.2. OGG ..............................................................................................30 2.1.3.1.3. OGM ..............................................................................................30 2.1.3.1.4. Matroska........................................................................................31 2.1.3.1.5. MPEG ............................................................................................31 2.1.3.1.6. Quicktime.......................................................................................32 2.1.3.1.7. Realmedia .....................................................................................32 2.1.3.1.8. ASF................................................................................................32 2.1.3.1.9. WAV ..............................................................................................32 2.1.3.2. Codecs de vídeo ..................................................................................33 2.1.3.2.1. MPEG vídeo ..................................................................................33 2.1.3.2.3. MPEG-2.........................................................................................35 2.1.3.2.4. MPEG-4.........................................................................................37 2.1.3.2.5. DivX ...............................................................................................38 2.1.3.2.6. XviD ...............................................................................................38 2.1.3.2.7. Theora ...........................................................................................38 2.1.3.2.8. H.261 .............................................................................................39 2.1.3.2.9. H.263 .............................................................................................39 2.1.3.2.10. H.264 ...........................................................................................39 2.1.3.2.11. Vídeo JPEG.................................................................................39 2.1.3.2.12. WMV............................................................................................39 2.1.3.2.13. RealVideo ....................................................................................39 i 2.1.3.3. Codecs de audio ..................................................................................40 2.1.3.3.1. MPEG audio ..................................................................................40 2.1.3.3.2. Vorbis ............................................................................................41 2.1.3.3.3. FLAC .............................................................................................41 2.1.3.3.4. Speex ............................................................................................41 2.1.3.3.5. AC3................................................................................................42 2.1.3.3.6. AAC ...............................................................................................42 2.1.3.3.7. WMA..............................................................................................42 2.1.3.3.8. RealAudio ......................................................................................42 2.1.4. Streaming ....................................................................................................42 2.1.4.1. RTSP ....................................................................................................43 2.2. El hogar digital....................................................................................................44 2.2.1. La Pasarela Residencial..............................................................................44 2.2.2. Iniciativa OSGi.............................................................................................44 2.2.2.1. Especificaciones OSGi .........................................................................46 2.2.3. Implementaciones de la plataforma OSGi...................................................46 2.3. El software libre..................................................................................................48 2.3.1. GNU/Linux...................................................................................................49 2.3.2. Licencias libres............................................................................................51 2.3.3. Java y software libre....................................................................................51 2.3.4. Eclipse.........................................................................................................52 2.3.4.1. IDEs......................................................................................................52 2.3.4.2. Terminología eclipse ............................................................................53 2.3.4.3. Plataforma Eclipse................................................................................53 3. Análisis de requisitos ................................................................................................54 3.1. Visión de sistema ...............................................................................................54 3.2. Requisitos del sistema .......................................................................................55 3.2.1. Requisitos funcionales ................................................................................55 3.2.2. Requisitos no funcionales ...........................................................................56 3.3. Casos de uso .....................................................................................................58 3.3.1. CU1 – Reproducir multimedia .....................................................................60 3.3.2. CU2 – Ejecutar canales...............................................................................60 3.3.3. CU3 – Conectar usuario..............................................................................61 3.3.4. CU4 – Desconectar usuario ........................................................................62 3.3.5. CU5 – Gestionar plugins .............................................................................62 3.3.6. Casos de uso frente a requisitos.................................................................63 4. Herramientas.............................................................................................................65 4.1. Introducción........................................................................................................65 4.2. Sistema operativo...............................................................................................65 4.3. Herramientas de edición ....................................................................................66 4.4. Pasarela Residencial..........................................................................................66 4.5. Programación .....................................................................................................67 4.5.1. Entorno de desarrollo integrado ..................................................................68 4.6. Herramientas multimedia ...................................................................................69 4.7. Servidores ..........................................................................................................69 4.8. Otras utilidades ..................................................................................................70 5. Diseño del sistema....................................................................................................71 5.1. Introducción........................................................................................................71 5.2. Diagramas de despliegue...................................................................................71 5.3. Diagrama de paquetes .......................................................................................75 5.4. Diagramas de clases..........................................................................................76 5.4.1. Bundle piPlayer ...........................................................................................76 5.4.1.1. Módulo principal ...................................................................................76 5.4.1.2. Módulo de herramientas.......................................................................77 5.4.1.3. Módulo de interfaz gráfica ....................................................................78 ii 5.4.1.4. Módulo de reproducción multimedia.....................................................79 5.4.1.5. Módulo de servicios web ......................................................................80 5.4.1.6. Módulo de funcionalidades OSGi .........................................................81 5.4.1.7. Módulo de pruebas unitarias ................................................................83 5.4.2. Bundles IA (aplicaciones interactivas).........................................................83 5.4.3. Bundle de canales (channels) .....................................................................84 5.5. Diagramas de secuencia....................................................................................85 5.5.1. Sincronización entre multimedia y aplicaciones ..........................................86 5.5.2. Autenticación de usuario y obtención de un perfil.......................................87 5.5.3. Despliegue de canales ................................................................................88 5.6. Diagramas de estados .......................................................................................89 6. Pruebas.....................................................................................................................91 6.1. Pruebas unitarias ...............................................................................................91 6.1.1. Resumen de las pruebas ............................................................................92 6.1.2. Pruebas de personalización ........................................................................92 6.1.3. Pruebas de interactividad............................................................................93 6.1.4. Pruebas de reproducción ............................................................................94 6.2. Prueba de sistema: caso de estudio ..................................................................95 6.3. Pruebas de calidad.............................................................................................97 6.3.1. Complejidad ciclomática..............................................................................98 6.3.2. Acoplamiento eferente ..............................................................................100 6.3.3. Pérdida de cohesión Chidamber-Kemerer ................................................101 6.3.4. Número de niveles ....................................................................................101 6.3.5. Número de líneas de código .....................................................................102 6.3.6. Número de campos ...................................................................................103 6.3.7. Número de parámetros .............................................................................103 7. Conclusiones...........................................................................................................105 7.1. Trabajo desarrollado ........................................................................................105 7.2. Cumplimiento de objetivos ...............................................................................106 7.3. Limitaciones .....................................................................................................107 7.4. Trabajo futuro ...................................................................................................107 8. Anexos ....................................................................................................................109 8.1. Manual de usuario............................................................................................109 8.1.1. Introducción...............................................................................................109 8.1.2. Instalación .................................................................................................109 8.1.2.1. JVM ....................................................................................................109 8.1.2.1. OSCAR...............................................................................................109 8.1.2.3. Servicios web .....................................................................................114 8.1.3. Reproducción de vídeo .............................................................................116 8.1.4. Canales interactivos ..................................................................................119 8.1.4.1. How Computer Works ........................................................................123 8.1.5. Panel de control ........................................................................................124 8.1.6. Interfaz gráfica...........................................................................................126 8.2. Impresión de snapshotsIA................................................................................128 8.3. Ficheros de despliegue de servicios web.........................................................134 8.4. Estructura de ficheros fuente ...........................................................................135 8.5. Licencia LGPL ..................................................................................................137 9. Presupuesto ............................................................................................................138 9.1. Costes materiales.............................................................................................138 9.2. Costes de mano de obra ..................................................................................138 9.3. Gastos generales .............................................................................................139 9.4. Presupuesto total .............................................................................................139 10. Referencias ...........................................................................................................140 11. Glosario.................................................................................................................147 iii Índice de figuras Figura 1.1. El hogar digital ..............................................................................................2 Figura 1.2. Escenario de pasarela residencial ................................................................2 Figura 1.3. Escenario OSGi ............................................................................................3 Figura 1.4. Ciclo de vida del proyecto .............................................................................5 Figura 1.5. Ciclo de vida de un módulo...........................................................................5 Figura 1.6. Diagrama de Gantt........................................................................................6 Figura 2.1. Adopción mundial de estándares de transmisión .......................................11 Figura 2.2. Agentes TVD...............................................................................................12 Figura 2.3. Recepción de TVD ......................................................................................14 Figura 2.4. Esquema fundamental de un STB ..............................................................15 Figura 2.5. Esquema de capas de un STB ...................................................................15 Figura 2.6. Esquema de una ICT ..................................................................................18 Figura 2.7. Perfiles MHP ...............................................................................................23 Figura 2.8. Arquitectura MHP........................................................................................25 Figura 2.9. Arquitectura MHP en detalle .......................................................................25 Figura 2.10. Arquitectura de las APIs en MHP..............................................................28 Figura 2.11. Estructura de la trama de transporte MPEG-2..........................................36 Figura 2.12. MP3 y MP3Pro ..........................................................................................41 Figura 2.13. Arquitectura OSGi .....................................................................................45 Figuras 2.14 y 2.15. Arquitectura SW OSGi..................................................................46 Figura 3.1. Visión inicial del sistema .............................................................................54 Figura 3.2, 3.3 y 3.4. Relaciones entre casos de uso. ..................................................58 Figura 3.5. Diagrama de casos de uso .........................................................................59 Figura 3.6. CU1 – Reproducir multimedia .....................................................................60 Figura 3.7. CU2 – Ejecutar canales ..............................................................................60 Figura 3.8. CU3 – Conectar usuario .............................................................................61 Figura 3.9. CU4 – Desconectar usuario ........................................................................62 Figura 3.10. CU5 – Gestionar plugins ...........................................................................62 Figuras 4.1. y 4.2. Bayanet ...........................................................................................67 Figura 5.1. Logo piPlayer ..............................................................................................71 Figura 5.2. Diagrama de nodos.....................................................................................72 Figura 5.3. Diagrama de barras ....................................................................................73 Figura 5.4. Diagrama de componentes .........................................................................74 Figura 5.5. Diagrama de paquetes................................................................................75 Figura 5.6. Diagrama de clases: piplayer......................................................................77 Figura 5.7. Diagrama de clases: tools...........................................................................77 Figura 5.8. Diagrama de clases: gui .............................................................................78 Figura 5.9. Diagrama de clases: player ........................................................................80 Figura 5.10. Diagrama de clases: webservices.............................................................81 Figura 5.11. Diagrama de clases: osgi (despliegue de canales)...................................82 Figura 5.12. Diagrama de clases: osgi (eventos de multimedia) ..................................82 Figura 5.13. Diagrama de clases: junit..........................................................................83 Figura 5.14. Diagrama de clases: dia ...........................................................................83 Figura 5.15. Diagrama de clases: eia ...........................................................................84 Figura 5.16. Diagrama de clases: sia............................................................................84 Figura 5.17. Diagrama de clases: channels ..................................................................85 Figura 5.18. Diagrama de secuencia de eventos de vídeo ...........................................86 Figura 5.19. Diagrama de secuencia de autenticación .................................................87 Figura 5.20. Diagrama de secuencia de despliegue de canales...................................88 Figura 5.21. Diagrama de estados de los bundles........................................................89 Figura 5.22. Diagrama de estados de un player ...........................................................90 Figura 6.1. How Computer Works .................................................................................96 iv Figura 6.2. Snapshots IA...............................................................................................97 Figura 6.3 Complejidad ciclomática ..............................................................................99 Figura 6.4. Warnings en Eclipse ...................................................................................99 Figura 6.5. Acoplamiento eferente ..............................................................................100 Figura 6.6. Otro warning en Eclipse............................................................................100 Figura 6.7. Pérdida de cohesión Chidamber-Kemerer................................................101 Figura 6.8. Número de niveles ....................................................................................102 Figura 6.9. Número de líneas de código .....................................................................102 Figura 6.10. Número de campos.................................................................................103 Figura 6.11. Número de parámetros ...........................................................................104 Figura 8.1. Consola OSCAR (inicio)............................................................................110 Figura 8.2. Consola OSCAR (instalación del bundle piPlayer) ...................................112 Figura 8.3. GUI piPlayer..............................................................................................112 Figura 8.4. Consola OSCAR (instalación del bundle channels)..................................113 Figura 8.5. Consola OSCAR (despliegue de aplicaciones interactivas) .....................113 Figura 8.6. Consola OSCAR (desinstalación del bundle channles) ............................114 Figura 8.7. Consola GNU/Linux (arranque Tomcat y despliegue del servicio web)....115 Figura 8.8. Consola GNU/Linux (anulación del despliegue del servicio web).............116 Figura 8.9. Menú de reproducción multimedia ............................................................116 Figura 8.10. Abrir fichero en local ...............................................................................117 Figura 8.11. Abrir sesión RTP .....................................................................................117 Figura 8.12. Mensaje de temporizador vencido ..........................................................117 Figura 8.13. Mensaje de reproducción remota............................................................117 Figura 8.14. Reproduciendo vídeo y audio .................................................................118 Figura 8.15. Reproducción a pantalla completa..........................................................118 Figura 8.16. Menú de autenticación de usuario ..........................................................119 Figura 8.17. Menú de canales (vacío en un primer momento)....................................120 Figura 8.18. Cuadro de dialogo para introducir usuario y contraseña ........................121 Figura 8.19. Usuario incorrecto ...................................................................................121 Figura 8.20. Servicio de autenticación no disponible ..................................................121 Figura 8.21. Autenticación correcta ............................................................................121 Figura 8.22. Servicio de autenticación no disponible ..................................................122 Figura 8.23. Desconexión del perfil.............................................................................122 Figura 8.24. Eliminación de los canales......................................................................123 Figura 8.25. Multimedia de How Computer Works......................................................123 Figura 8.26. Snapshots Interactive Application ...........................................................124 Figura 8.27. Petición de impresión..............................................................................124 Figura 8.28. Opción de menú “Archivo” ......................................................................125 Figuras 8.29, 8.30, 8.31 y 8.32. Panel de control........................................................125 Figura 8.33. Multiidioma ..............................................................................................126 Figura 8.34. Menú de interfaz gráfica .........................................................................126 Figura 8.35, 8.36 y 8.37. Diferentes apariencias.........................................................127 Figura 8.38. Acerca de................................................................................................127 v Índice de tablas Tabla 2.1. Recursos de receptores de TVD ..................................................................24 Tabla 2.2. Comparativa STB – TV ................................................................................24 Tabla 2.3. Comparativa PC – TV ..................................................................................24 Tabla 2.4. Formatos VCD, SVCD y derivados ..............................................................34 Tabla 2.5. Comparativa MPEG-1, MPEG-2 y MPEG-4.................................................38 Tabla 2.6. Formatos VCD, SVCD y derivados ..............................................................40 Tabla 3.1. Casos de uso frente a requisitos..................................................................64 Tabla 5.1. Casos de uso frente a módulos ...................................................................76 Tabla 6.1. Casos de uso frente a pruebas ....................................................................92 Tabla 6.2. Resumen de las pruebas unitarias...............................................................92 Tabla 6.3. Pruebas de autenticación.............................................................................93 Tabla 6.4. Pruebas de interactividad.............................................................................94 Tabla 6.5. Pruebas de reproducción en local................................................................95 Tabla 6.6. Pruebas de reproducción en remoto ............................................................95 Tabla 9.1. Costes materiales ......................................................................................138 Tabla 9.2. Tareas y tiempos de ejecución...................................................................138 Tabla 9.3. Costes de la mano de obra ........................................................................139 Tabla 9.4. Presupuesto total .......................................................................................139 vi 1. Introducción 1. Introducción Este capítulo sirve de introducción y presentación de este Proyecto Fin de Carrera. En primer lugar, se presentan los conceptos de base de este proyecto, que son la convergencia tecnológica, el hogar digital y el código abierto. En segundo lugar se describen los objetivos marcados para la realización del mismo. En tercer lugar se detalla el plan seguido para la realización del proyecto. Por último se describe la estructura del presente documento. 1.1. Presentación Es una tendencia consolidada el fenómeno de convergencia entre los sectores de las telecomunicaciones, la informática y el audiovisual gracias a las redes de banda ancha. Esta convergencia puede verse como un proceso evolutivo, en el que paulatinamente se produce una integración entre los sectores implicados. El resultado de este proceso es la creación de un sector global, el llamado “Hipersector de la información y las comunicaciones”. Las tecnologías implicadas en el proceso se conocen como Tecnologías de la Información y las Comunicaciones (TIC) [GRET 2000]. Las soluciones tecnológicas nacidas para esta nueva situación tienen muchas características comunes. Algunas de las más importantes son: • • • Digitalización: La información va en formato binario. Este hecho supone muchas ventajas: se independizan la fuente de información, se abaratan costes de equipos (economía de escala), la calidad es un parámetro fácilmente controlable, y además se gana en eficiencia y flexibilidad. Interactividad: La información viaja en los dos sentidos. De este modo los usuarios pueden interactuar con las aplicaciones y servicios a los que tienen acceso. Banda Ancha: Más que un concepto técnico, el término “banda ancha” se refiere a la capacidad de comunicaciones necesaria para cubrir las necesidades de un usuario. No es un concepto estático, sino que evoluciona con el tiempo. La convergencia conduce hacia mercados y servicios ubicados en “tierra de nadie”. Uno de los paradigmas de la convergencia es la televisión (TV) digital. En este entorno convergente el medio o red por el que se oferten los servicios será indiferente para los usuarios, que tenderán a usar terminales multiservicio: acceso a Internet a través del televisor, ordenador personal (PC) con tarjeta de vídeo capaz de sintonizar la televisión, etc. También aparecen nuevas formas de difusión de información que amenazan o diversifican la modalidad convencional, como por ejemplo el streaming a través de Internet. De este modo los receptores de TV tradicionales van a evolucionar hacia sistemas más completos. Además, pueden aparecer nuevos terminales capaces de acceder a contenidos audiovisuales: videoconsolas, PC’s, etc. Por otro lado, es una tendencia también imparable el aumento del equipamiento electrónico de los hogares: informático, audiovisual, de comunicaciones, domótico, etc. En este punto se impone la necesidad de conectar estos dispositivos electrónicos entre sí (Home Networking) con el exterior (Internet) para poder disfrutar de servicios cada vez más avanzados. El Hogar Digital es la materialización de esta idea de 1 1. Introducción convergencia de servicios: de entretenimiento, de comunicaciones, de gestión digital del hogar, y de infraestructuras y equipamiento [LBHOGARDIGITAL2003]. Figura 1.1. El hogar digital El elemento que integra las distintas redes domésticas y las interconecta con el exterior es conocido como “pasarela residencial”. La pasarela residencial, también llamada pasarela doméstica, SG (Service Gateway) o AMI (Adaptador Multimedia Interactivo), conecta las infraestructuras de telecomunicaciones (datos, control, automatización, etc.) de la vivienda a una red pública de datos, como por ejemplo Internet. La SG normalmente combina las funciones de un router, de un hub, de STB (Set Top Boxes), de un módem con acceso a Internet para varios PC’s, de cortafuegos e incluso de servidor de aplicaciones de entretenimiento, como VoD/AoD, de comunicaciones, VoIP (telefonía sobre Internet) o de telecontrol [CASADOMO]. Figura 1.2. Escenario de pasarela residencial Debido a la diversidad de tecnologías existentes en los hogares, se hace evidente la necesidad de un estándar común que establezca un marco de trabajo sobre el que las compañías puedan desarrollar servicios y aplicaciones para las pasarelas, sin tener 2 1. Introducción que preocuparse por aspectos de bajo nivel como tecnologías de red o hardware. En este ámbito de necesidad nace OSGi (Open Services Gateway Initiative). OSGi es un grupo de trabajo creado en Marzo de 1999, cuyo objetivo es especificar y promocionar un entorno software para el desarrollo de pasarelas residenciales. El estándar OSGi define una arquitectura software que se ejecuta en una pasarela residencial. Los servicios y aplicaciones de manera concurrente, compartiendo recursos y se hace así homogéneo el acceso a datos, recursos y dispositivos por parte de los mismos [OSGi]. Figura 1.3. Escenario OSGi El tercer aspecto de importancia creciente en la actualidad es el movimiento de desarrollo de software de código abierto (open source). En el sector informático, el modelo de negocio tradicional es el software propietario. De este modo, los productos desarrollados presentan economías de red: cuantos más usuarios disponen de un producto, mayor utilidad les proporciona (el fax es el ejemplo clásico de economía de red, cuantos más usuarios disponen de fax mayor es su utilidad). El software es un producto que presenta economías de red, esto es, cuantos más usuarios disponen de un producto, mayor utilidad les proporciona (el fax es el ejemplo más clásico de economía de red). Esto unido a su despreciable coste de copia frente al costo de desarrollo, hace que sea un sector que tiende de forma natural al monopolio. La globalización, y en especial la generalización del uso de Internet en el mundo desarrollado han facilitado el advenimiento de operadores globales en el mundo del software. Los mayores, Microsoft, HP, Oracle, IBM, Cisco, son corporaciones transnacionales de origen estadounidense. El software libre constituye una alternativa a las soluciones propietarias para la mayoría de ámbitos públicos y privados. Este conjunto de soluciones informáticas generadas bajo distintas licencias, facilitan la reutilización de la experiencia (al estilo del conocimiento científico) y su uso generalizado y gratuito. El software libre es generado por expertos programadores voluntarios, empresas, administraciones y otros tipos de organizaciones que 'ofrecen' las soluciones desarrolladas al resto de la comunidad para que se utilicen de forma 'libre'. [LBSWLIBRE2004] Si bien el software libre no es un fenómeno nuevo ya que existe desde los orígenes de la informática, sí es relativamente reciente su modelo cooperativo de producción en red y el movimiento 3 1. Introducción social que lo avala (comunidad del software libre). Ligado a la extensión de Internet y a la popularización de los ordenadores personales, el movimiento del software libre ha alcanzado su masa crítica, y ha dejado de ser sólo cosa de algunos programadores para convertirse en un fenómeno de cooperación social liberada. Este Proyecto Fin de Carrera (PFC) presenta una solución para un servicio convergente audiovisual a través de pasarela residencial. Tomando como modelo de trabajo la filosofía de código abierto (open source), se ha desarrollado un reproductor de contenidos multimedia, con el valor añadido de la interactividad y la personalización, todo ello ofrecido a través de una pasarela residencial OSGi. Este proyecto se encuentra encuadrado en la demostración del cuarto paquete de trabajo del proyecto europeo ITEA OSMOSE [OSMOSE]. El objetivo general del proyecto OSMOSE (Open Source Middleware for Open Systems in Europe) es el desarrollo, mejora y validación, en contextos de prueba definidos, de un middleware (capa intermedia entre el sistema operativo y las aplicaciones que hace posible la computación distribuida) adaptable e integral para ser hospedado por el consorcio ObjectWeb [OBJECTWEB]. 1.2. Objetivos El objetivo general de este proyecto es desarrollar un sistema software capaz de recibir contenidos audiovisuales digitales, personales e interactivos a través de una pasarela residencial OSGi. Todo el sistema se ensamblará a partir de componentes de código abierto. Para cumplir el objetivo general, a continuación se detallan objetivos más específicos, que se derivan del general y lo complementan: 1. Hacer un estudio del estado del arte de las líneas maestras de este proyecto. Esas líneas son tres: o Convergencia del sector audiovisual. Estudio del sector tradicional (TV, TV Digital) frente a las nuevas soluciones convergentes: MHP (Multimedia Home Platform), streaming, etc. o Hogar digital y pasarela residencial. Estudio de OSGi y el hogar digital. o Software libre. Este PFC se enmarca en el ámbito del proyecto europeo OSMOSE. Por ello, el desarrollo del sistema objeto de este PFC debe estar dentro del paradigma open source o código abierto, ya que es un objetivo explícito del proyecto OSMOSE (Eureka 2023, ITEA ip00004) [OSMOSE]. Por todo esto, se realizará un estudio del estado tecnológico actual del software libre. 2. Definir los requisitos funcionales y no funcionales del sistema. Para ello se realizará una fase de análisis previa al diseño propiamente dicho. 3. Realizar un diseño e implementación del sistema. Con la información recavada en las fases anteriores, se dispondrá del criterio suficiente para realizar un diseño acorde a las necesidades del sistema. Así mismo, se habrá decidido el uso de las herramientas más adecuadas para la instrumentación del mismo. 4. Comprobar la validez del sistema. Realizar pruebas en cuánto a funcionamiento y calidad. Así mismo, se realizará un caso de estudio completo para comprobar la validez del sistema en tres aspectos: o Reproducción de contenidos multimedia. o Interactividad. o Personalización. 4 1. Introducción 1.3. Plan de proyecto Para el desarrollo de este proyecto, se ha utilizado un ciclo de vida en cascada sobre el que se ha aplicado un ciclo de vida iterativo incremental para cada uno de los módulos. Este ciclo de vida comienza con la realización de un exhaustivo estudio del estado del arte junto con una etapa de análisis del sistema. Con la información obtenida, se define un diseño de la arquitectura general del sistema. De este modo se consigue hacer una división de las funcionalidades del sistema en módulos. Para módulo se aplica un ciclo de vida incremental, pasando por los ciclos de diseño, implementación, integración y pruebas. A continuación se puede ver el ciclo de vida descrito en forma gráfica: Figura 1.4. Ciclo de vida del proyecto Cada módulo de la figura anterior sigue un ciclo de vida incremental. Véase: Figura 1.5. Ciclo de vida de un módulo 5 1. Introducción La integración y pruebas de cada módulo se harán con pruebas unitarias. Según se van añadiendo funcionalidades al sistema se deben repetir dichas pruebas unitarias, para comprobar que el sistema sigue funcionando correctamente. Una vez desarrollados todos los módulos, se realizarán pruebas de sistema, es decir, se comprobará la validez del sistema desarrollado. Para ello se desarrollará un caso de estudio completo que responda a la especificación del sistema: reproducción multimedia personal e interactiva. En las primeras fases de desarrollo del proyecto se planificó el tiempo mediante un diagrama de Gantt. En este diagrama se cubría solamente parte del desarrollo, ya que con este ciclo de vida se revisan las planificaciones para cada nueva funcionalidad (módulos). Véase el diagrama: Figura 1.6. Diagrama de Gantt 1.4. Estructura del documento La memoria de este PFC consta de siete capítulos y cinco anexos. Esta división corresponde a las fases principales del desarrollo de software seguido. En este primer capítulo se ha hecho una presentación al proyecto, así como se hecho una descripción de los objetivos principales. En el segundo capítulo se hace un estudio detallado del estado del arte. Se estudian las tres áreas principales del proyecto: convergencia del sector audiovisual, hogar digital/pasarela residencial y software libre. Este capítulo es importante para conocer el estado tecnológico actual del ámbito del proyecto. Las conclusiones obtenidas en este capítulo serán fundamentales para afrontar el resto del proyecto, y condicionarán de algún modo todo el desarrollo. En el tercer capítulo se procede a hacer un estudio de análisis de requisitos (funcionales y no funcionales), así como los diferentes casos de uso del sistema. El objetivo de esta fase es definir exactamente la funcionalidad que debe proporcionar el sistema a desarrollar. En el cuatro capítulo se recogen las herramientas que se han de utilizar para la realización del desarrollo del sistema. Esta elección se hace a posteriori del estudio del estado del arte y de la captura de requisitos. Esto es así porque tras estas dos fases se disponen de conocimientos y criterios que antes no estaban claros. 6 1. Introducción En el quinto capítulo, y una vez claro claros los requisitos del sistema, se procede a realizar un diseño detallado. En este apartado se verán multitud de diagramas UML (Unified Model Language), tanto dinámicos como estáticos, para definir de forma precisa cómo hay que implementar el sistema. En el sexto capítulo se detallan las pruebas realizadas. En este apartado se verán todas las pruebas unitarias realizadas con JUnit. Además, se ve un caso de estudio completo como prueba de sistema. Además, se muestran métricas para calibrar la calidad de la programación desarrollada. En el séptimo capítulo se extraerán las conclusiones generales del proyecto en el capítulo séptimo. Se describirán las limitaciones detectadas en el sistema y el posible trabajo futuro para el mismo. A continuación se incluye una sección de anexos, con los documentos que no tenían un sitio definido en la estructura de esta memoria. En el noveno capítulo se da un prepuesto de lo que conllevaría la realización del proyecto. Por último se detallan dos capítulos de referencias y glosario (capítulos diez y once respectivamente). 7 2. Estado del arte 2. Estado del arte El término anglosajón ‘state-of-the-art’ (estado del arte) es sinónimo del nivel más alto de desarrollo de un dispositivo, técnica, o disciplina científica en un momento determinado. Este capítulo es una síntesis del estudio previo necesario para enfrentarse a la realización de este proyecto. En este estudio habrá tres líneas maestras: convergencia en el sector audiovisual, hogar digital/pasarela residencial, y por último software libre. 2.1. Convergencia del sector audiovisual Como paradigma de la convergencia entre telecomunicaciones, informática y audiovisual está la TV Digital (TVD) y los servicios convergentes que giran alrededor de este sector. La convergencia conduce hacia mercados y servicios cada vez más apartados del modelo de negocio tradicional. En este primer apartado del estado del arte se va a estudiar el sector audiovisual, partiendo de los servicios tradicionales (TV, TV Digital), pasando por las nuevas soluciones (MHP), hasta llegar a nuevas soluciones convergentes (como el streaming). 2.1.1. TV Digital En los últimos años hemos asistido a una paulatina transformación de los formatos de representación de información desde el plano analógico al digital. Las ventajas del formato digital, desde el punto de vista tecnológico, empresarial o del usuario, han supuesto la desaparición fulminante de medios como la cinta de audio y el disco de vinilo en favor del CD, y la cinta de vídeo en favor del disco DVD. Le llega el turno al formato de transmisión del medio de comunicación de masas por antonomasia en la sociedad actual: la televisión (TV). [GRET2000] Tecnológicamente, parecen resueltos los problemas para implementar una solución digital que garantice un mínimo de calidad ajustándose a los recursos actualmente disponibles o cuya introducción parece razonable. Económicamente, los actores involucrados están dispuestos a asumir el riesgo asociado, ya sea por el convencimiento acerca de los beneficios que el cambio promete reportar, o bien por ser conscientes de que el no estar en primera línea ante un cambio tan importante puede suponer un retraso competitivo y un deterioro de la imagen corporativa. Administrativamente, ante la trascendencia económica del sector, los gobiernos han impulsado y regulado una transición que obligará a la desaparición de las transmisiones analógicas en una década. Las ventajas del uso de la tecnología digital se pueden resumir en cuatro puntos clave: • Independiza de la fuente de información. Esto nos lleva a generar economías de escala (producir más abaratando el coste por unidad). Los equipos digitales son más baratos que los equipos analógicos. • Versatilidad. La calidad es un parámetro que se puede controlar fácilmente, en función de los requisitos del sistema. • Eficiencia. A igualdad de costes es mejor usar la tecnología digital. Por ejemplo, una copia de una información en formato digital será exactamente igual que el original. En formato analógico no es tan sencillo. 8 2. Estado del arte • Flexibilidad. Digitalizar nos permite realizar operaciones como son el cifrado, la compresión, detección y corrección de errores, selección de destinatario, etc. 2.1.1.1. TV analógica En España la TV nació en el año 1952 con la creación del ente público Radio Televisión Española (RTVE). La primera emisión se produjo el 28 de Octubre de 1956. En el año 1989 se liberalizó el sector con la Ley de la Televisión Privada. Los sistemas de TV analógicos utilizan muy pocas líneas (baja definición). Son distintos e incompatibles para cada país. Hoy día en Europa y en algunas partes del mundo se utiliza el sistema de TV llamado PAL (Phase Alternate Line, Línea de Fase Alterna), compuesto por 625 líneas y 25 imágenes completas por segundo que proporcionan una alta definición, ya que al transmitir cada fotograma (cuadro) como dos imágenes entrelazadas (campos), se ven 50 imágenes por segundo. En Estados Unidos sin embargo se adoptó la norma NTSC (National Television System Commitee, Comité Nacional de Sistema de Televisión) de 525 líneas horizontales por fotograma y una frecuencia de 30 fotogramas por segundo, la mitad del ciclo de la corriente eléctrica, que es de 60 Hz, lo que disminuye el parpadeo de la imagen. La transmisión de la señal se hace mediante difusión (broadcast), por lo que se envía desde un punto (pueden ser varios) para que sea recibido por todos aquellos interesados en esa señal. Debido a la naturaleza del servicio, se suele usar difusión por radio, ya que el aire es un medio barato que no requiere infraestructuras costosas. La transmisión vía radio se hace mediante una antena omnidireccional desde el origen de la señal de transmisión. Para evitar la pérdida de potencia de la señal a causa de la distancia o la orografía del terreno, se ponen repetidores de señal. El ancho de banda de los canales de TV es de 8 MHz. [BIT140] 2.1.1.2. TV digital La TV Digital (TVD) es la difusión de señales de TV que utiliza la más moderna tecnología digital. La TVD revoluciona el concepto que se tiene hasta ahora de la TV, aumentando la calidad de la recepción y con nuevos servicios que le confieren un valor añadido. [TVD] Unido a la TVD va el concepto de interactividad. La TV interactiva (iTV) permitirá a los usuarios dejar de ser sujetos pasivos en el esquema tradicional de la TV. La TV convencional es unidireccional: los sistemas de TV convencionales se limitan a recibir la señal y a presentar los contenidos. Para que exista interactividad los usuarios deberían poder interactuar con las aplicaciones y servicios que la TVD le va a ofrecer. Esto se hace necesario un canal de retorno. La iTV es pues un sistema de comunicación bidireccional. [ITV] El otro concepto unido al de TVD es el de personalización. La TV personal (pTV) permite controlar en tiempo real el visionado de la misma, es decir, permite adelantar, rebobinar, etc. lo que se quiere ver. También se podrá grabar los contenidos que se deseen, entre otras funcionalidades. La TV del futuro previsiblemente reunirá las cualidades comentadas: Televisión Digital Personal e Interactiva. 9 2. Estado del arte 2.1.1.3. Ventajas de la TV digital • Nuevos contenidos y servicios. Nuevas emisoras y mayor número de canales. • Mejor recepción de la señal digital en comparación con la analógica (se eliminan las imágenes dobles y las interferencias). La señal digital es mucho más robusta que la analógica (menos sensible a ruido, interferencias, permite regeneración de la señal, etc.). • Permite la recepción portátil y en movimiento. • Calidad de imagen y sonido similar al de formato DVD. • Mayor resolución. Permite diferentes formatos: o Formato convencional (relación de aspecto 4:3): Una imagen digital está formada por 720x576 pixels. Almacenar una imagen requiere 1 MByte y transmitirla durante un segundo requiere 170 Mbps. o Formato panorámico (relación de aspecto 16:9): Una imagen digital está formada por 960x576 pixels y requiere un 30% más de capacidad (1,3 MByte y un segundo de imágenes 221 Mbps). o Formato de alta definición, HDTV (relación de aspecto también 16:9): Contiene 1920x1080 pixels, con lo que una imagen ocupa 4 MBytes y la transmisión durante un segundo requiere 1 Gbps. El audio es Dolby-Digital AC-3. Existen a su vez dos tipos de HDTV: El primero de ellos tiene 1.080 líneas activas con 1.920 píxeles cuadrados por área y con un barrido con un valor de entre 59.94 y 60 cuadrados por segundo. El segundo modelo tiene 720 líneas activas con 1.280 píxeles y con el mismo barrido que el primer modelo. • Permite enviar sonido digital multicanal 5.1, pudiéndose conseguir efectos de sonido (envolvente, etc.) o la transmisión de múltiples idiomas (versión original, lección de idiomas y subtítulos). • Servicios interactivos y acceso a la Sociedad de la Información (SI). • Guías electrónicas de programación (EPG, Electronic Program Guide). Son aplicaciones que permiten al usuario informarse sobre la programación actual y futura de los diversos canales de televisión. • Compresión de la señal digital en MPEG-2. La compresión de la imagen puede ser temporal o espacial. o Compresión espacial: Se comprimen los datos a transmitir con técnicas similares a las usadas en la compresión de imágenes en sistemas informáticos, ordenadores, etc. o Compresión temporal: La TV transmite 25 imágenes por segundo, con lo que las diferencias entre dos imágenes consecutivas son relativamente pocas. Lo que se hace es identificas las partes comunes y no repetir la transmisión de estas, ahorrando de esta forma ancho de banda. MPEG-2 define un formato de transporte para los contenidos ya no sólo de audio y vídeo sino de cualquier tipo de datos. Esta capacidad puede ser aprovechada para insertar aplicaciones y proporcionar así interactividad a la TV. • Un mejor aprovechamiento del espectro. Los canales radioeléctricos de la televisión digital ocupan el mismo ancho de banda que los de TV analógica (8MHz), pero gracias a la citada compresión, tienen capacidad para un número variable de programas de televisión (4 o 5 canales, dependiendo de la calidad y de la fuente de información). [TVD] [TVDSI] [BIT140] 10 2. Estado del arte 2.1.1.4. Estandarización Actualmente existen dos grandes grupos de estándares para la transmisión de televisión digital. El europeo, Digital Video Broadcasting (DVB), y el estadounidense, Advanced Television Systems Committee (ATSC). El desarrollo de ATSC empezó en 1987 y culminó diez años después. El desarrollo de la norma europea DVB se inició en 1993. Se dispone de formatos para DVB-S (Satélite), DVB-C (Cable) y DVB-T (Terrestre). Las dos normativas se basan en la digitalización de la TV con MPEG-2, pero con diferente compresión de sonido y esquema de transmisión. [TERRATVD] Figura 2.1. Adopción mundial de estándares de transmisión 2.1.1.5. Tipos de TVD Se puede clasificar las diferentes modalidades de TVD como sigue: [GRET 2000] • TVD Terrenal (TDT). Transmisión por ondas terrestres o hertzianas en la banda VHF-UHF. • TVD por satélite (TDS). Recepción de señal a través de satélite, como Astra e Hispasat en España. • TVD por cable (CATV). Por cable se entiende las redes HFC (Hibrid Fiber/Coax), que combina las redes de fibra óptica (núcleo de red) y cable coaxial (hasta el usuario). • TVD por soluciones xDSL (ADSL y VDSL principalmente). Estas tecnologías utilizan el bucle de abonado en bandas de frecuencia superiores a la banda vocal. 11 2. Estado del arte • TVD por microondas mediante tecnología LMDS o similar (MMDS). Esta tecnología pretende ser un equivalente inalámbrico del cable. Usa bandas de 500 MHz en con portadoras de 10-28 GHz. De estas modalidades de TVD, dos de ellas tienen programación en abierto: [TVD] • TDT: Comenzó sus emisiones en abierto en abril de 2002 y convivirá con la TV analógica hasta el 31 de diciembre de 2011 según el Plan Técnico Nacional de la Televisión Digital Terrenal. En esta fecha las emisiones analógicas desaparecerán (‘apagón analógico’) La recepción de la TDT se realiza a través de la antena de TV convencional existente en los edificios. • TDS: Además de la oferta de TV de pago ofrecida por plataformas de TVD, cuenta con canales de TV en abierto. Comenzó sus emisiones en España en 1997. Su recepción se realiza a través de antenas parabólicas. 2.1.1.6. Agentes de la TVD A continuación se muestra un diagrama con los elementos que intervienen en la distribución de TVD: [REGUTVD] [TVDI] Figura 2.2. Agentes TVD • Proveedor de contenidos: La TV es un negocio de contenidos. Del atractivo de los contenidos depende la suscripción de los usuarios al servicio. Los contenidos más interesantes para el gran público son los deportes (sobre todo el fútbol) y las películas (sobre todo las hechas en EEUU). Algunos ejemplos son Mediapark (por ejemplo las cadenas Palomitas o Buzz), SogeCable (por ejemplo las cadenas Canal+, Cinemania, o la de radio Cadena Ser), TimeWarner (CNN), Fox (Fox Kids, Fox News, etc). • Proveedor de servicios: Provee servicios interactivos o contenidos destinados a servicios interactivos. Puede ser por ejemplo un banco que ofrezca datos financieros mediante una pasarela segura a sus clientes, o el proveedor de información meteorológica para la aplicación del tiempo. 12 2. Estado del arte • Servidor de aplicaciones: Se encarga de preparar las aplicaciones para su codificación antes de su emisión. Integra datos (posiblemente en tiempo real) de los proveedores de servicios. • Centro de emisión (programador): Recoge las señales de los proveedores de contenidos y la prepara para su codificación y emisión. • Operador de multiplex (encoding/mux): Codifica la información de vídeo, audio y datos (servicios interactivos) convirtiéndola en paquetes MPEG-2. Encripta esta información mediante el sistema de acceso condicional (CA) de la plataforma. Por último combina (o multiplexa) toda la información (vídeo, audio y datos) en un flujo de transporte MPEG (MPEG-TS, MPEG Transport Stream). • Operador de red de difusión (broadcast): Transmite el flujo MPEG-TS hacia los usuarios. • Equipo terminal de usuario: dispone de un mecanismo de recepción (una antena en la mayoría de los casos) y un equipo terminal en el interior del domicilio. Puede ser una de estas dos opciones: o Receptor digital externo (STB, Set Top Boxes también conocido como IRD, Integrated Receiver Decoder) conectado a un TV analógico convencional. Un STB permite capturar la señal digital y realiza el tratamiento necesario sobre ésta, para entregar a su salida una señal adecuada para el TV analógico. o Televisor digital integrado que permita su recepción directa (IDTV, Integrates Digital Television). Estos tipos de televisores previsiblemente utilizarán la tecnología MHP (Multimedia Home Platform), desarrollada por el DVB. El usuario también puede contar además con un PVR (Personal Video Recorder). Este dispositivo hace realidad el concepto de pTV (personal TV). El PVR es un vídeo digital capaz de almacenar un número de horas determinadas de programación en el disco duro del STB. Además, de este servicio tiene otras funciones como la de adelantar, rebobinar o parar un programa de televisión. • Operador de retorno: La estructura de distribución de la TVD no incorpora directamente un canal de retorno como medio de transmisión que garantiza la interactividad completa entre el abonado y el prestador del servicio. En principio, cualquier tipo de canal de retorno puede ser contemplado: RTB, RDSI, ADSL, LMDS, GSM, GPRS, UMTS, etc. A continuación se muestra una configuración genérica de recepción de TVD: [MURILLO2002] 13 2. Estado del arte Figura 2.3. Recepción de TVD 2.1.1.6.1. STB El STB es el dispositivo que posibilita la recepción en el hogar de la TVD y todas sus ventajas: los servicios interactivos, el acceso condicional o la televisión de alta definición. Los STB son diferentes según sea la señal digital que recibe. Es decir, hay STB’s diferentes para TVD por satélite, por cable, terrestre, etc. No son más que un paso intermedio hasta que los televisores digitales integrados se comercialicen. Básicamente un STB se encarga de recibir una señal digital en alguno de los estándares de TV digital existentes, comprueba que tenga permiso para mostrarla y envía la señal de forma analógica al televisor. El funcionamiento detallado es como sigue: [TVDI] 1. Primero se sintoniza la señal para recibir la información de audio, vídeo y datos (los tres tipos que vienen mezclados). 2. Después se separan los tres tipos de paquetes según su tipo (audio, vídeo o datos). 3. A continuación, el sistema de acceso condicional se encarga de decidir qué permisos tiene el subscriptor para ver unos contenidos u otros, y en función de eso, descifra los paquetes. 4. Los paquetes de audio y vídeo cifrados se pasan a los dispositivos de vídeo y audio del televisor. 5. Los paquetes de datos que forman una aplicación se ejecutan si es necesario. 6. El STB puede disponer de un canal de retorno. Así se consigue la interactividad. 14 2. Estado del arte Figura 2.4. Esquema fundamental de un STB Para poder ejecutar los datos o programas que se descargan de la señal se necesitan una serie de elementos software. Los STB se pueden describir con un esquema de capas de forma parecida a como se describiría un PC. [TVDSI] Figura 2.5. Esquema de capas de un STB 1. Hardware (HW): CPU, memoria, acceso condicional, decodificador de MPEG, etc. 2. Drivers (controladores): Los drivers son programas que comunican el sistema operativo con los dispositivos hardware. Cada driver interactúa con un dispositivo en particular, y hace de interfaz al resto de programas para su uso. 3. RTOS (Real-Time Operative Systems): Sistema Operativo en tiempo real. Es un tipo especial de SO que realiza operaciones en tiempo de ejecución, como por ejemplo la decodificación de MPEG (que necesitan ser realizadas al instante). Algunos ejemplos son: RTLinux (Real Time Linux), MS Windows CE o pSOS. 4. Middleware (plataforma): Es la una capa de SW cuya misión es facilitar el desarrollo y ejecución de aplicaciones interactivas. La plataforma facilita una API (Application Programming Interface) para cada lenguaje de programación que soporte. Tipos de middleware: 15 2. Estado del arte o Middleware propietarios: OpentTV. Con un 70% de cuota de mercado, es la solución dominante en middleware. MediaHighway. Solución middleware de Canal+. Basada en PanTalk. NDS, Microsoft TV o Liberate. Basadas en tecnología web: HTML y Javascript. o Middleware abiertos: MHEG-5: Antiguo estándar ISO para iTV. Usado en Reino Unido para sistemas de TV terrestre. MHP: Estándar DVB para iTV. Basado en Java. DAVIC: Basado en Java. Por sí sólo no tenido mucho éxito, pero la especificación MHP ha adoptado alguna de las APIs DAVIC. OCAP (OpenCable Application Plataform): Especificación de middleware para TVD por cable. OpenCable es un consorcio compuesto por operadores de cable de Estados Unidos. 5. Aplicaciones. Aquí es donde se encuentran las aplicaciones interactivas que una vez descargadas se pueden ejecutar (por ejemplo, las EPGs, anuncios interactivos, chats, etc.). A diferencia del resto de capas, esta es la única que no necesita estar residente permanentemente. Es decir, se pueden descargar las aplicaciones bajo demanda o en un momento determinado y ser borradas de la memoria cuando ya se hayan utilizado o pueden residir permanentemente (como una EPG si queremos que su acceso sea rápido). Los servicios que ofrece un STB se clasifican como sigue: • Si emplean o no el canal de retorno: o Interactividad local: No usa el canal de retorno. Sólo recibe datos del canal de broadcast. El usuario interactúa con la aplicación descargada. Ejemplos: juegos monousuario sin envío de puntuación, servicios de información, sistemas de búsqueda de programación, EPG, etc. o Interactividad remota: Emplea el canal de retorno para enviar o recibir datos. Se puede realizar prácticamente cualquier servicio: chat, e-mail, juegos en red, consulta de bases de datos (BD), T-commerce; T-banking; participación en concursos, etc. • Según se integra o no con el contenido audiovisual: o TV-Sites: Poca o nula integración con el contenido audiovisual. o Enhanced TV (ETV): Máxima integración. Aplicaciones enriquecidas con contenido audiovisual. Un STB también permite otro tipo de funcionalidades añadidas: • Unidad de disco duro (más información en PVR). • Terminal bancario para gestión de operaciones vía una tarjeta de crédito (por ejemplo, compra de productos y/o servicios, recarga de tarjetas monedero, etc.) • Conexión de periféricos u otros dispositivos (por ejemplo, cámaras de vídeo para el envío por e-mail de capturas, impresoras, etc.) 2.1.1.6.2. PVR Los terminales de usuario van a sufrir profundos cambios hasta que probablemente lleguen a convertirse en auténticos centros de ocio, comunicaciones e información en los hogares. Se trata del concepto de Home Media Server (HMS) que, en primera aproximación, estaría representado por los dispositivos PVR (Personal Video Recorder) que empresas como TiVo, UltimateTV o ReplayTV están popularizando en 16 2. Estado del arte Estados Unidos y que alguna empresa española como InOutTV ha anunciado que lanzará en España. [TVDI] Las principales funciones del PVR son: • Grabar programas en el disco duro del STB. Hasta 60 horas en el caso de Tivo y Replay TV. • Eliminación de cortes publicitarios. • Realizar búsquedas para que el PVR encuentre y/o grabe los programas favoritos del usuario. La búsqueda se puede realizar en función del título del programa, actores, directores, género o eventos deportivos. • Parar, adelantar, rebobinar,... cualquier programa. • Controlar o restringir el acceso a determinados programas. 2.1.1.6.3. Antenas colectivas En cuanto a instalación para captar, adaptar y distribuir las señales de TV (antenas colectivas) son dos los supuestos que se pueden dar: [TVD] • Edificios de nueva construcción: Los edificios de nueva construcción deben contar con una Infraestructura Común de Telecomunicaciones (ICT). La ICT debe estar proyectada por un Ingeniero de Telecomunicaciones o por un Ingeniero Técnico de Telecomunicaciones e instalada por una empresa instaladora inscrita en el Registro de Empresas Instaladoras de Telecomunicaciones del Ministerio de Ciencia y Tecnología. La ICT estará preparada, al menos, para captar (antena), adaptar (cabecera) y distribuir (cableado) a todas las viviendas la señal de TDT y distribuir la señal de TDS. Asimismo dispondrá de las canalizaciones necesarias para la TDC. • Edificios habitados sin ICT: En general, los edificios construidos con antelación a 1998 necesitarán adaptar sus instalaciones para recibir TVD, ya que sus antenas colectivas se diseñaron únicamente para la recepción de TV analógica. 17 2. Estado del arte Figura 2.6. Esquema de una ICT 2.1.1.7. Legislación TVD Marco jurídico: [TVDSI] • Constitución Española: o Articulo 20: libertad de información (activa y pasiva). o Articulo 128.2: reserva de ley, servicios esenciales. o Articulo 149.1.27: competencia Estado en materia audiovisual. • Estatuto de la Radio y la TV (1980). • Ley del Tercer Canal (1983). • Ley de la Televisión Privada (1988). • Ley de TV sin Fronteras (1994-99). • Ley de la Televisión Local (1995) modificada por la Ley 53/2002 • Ley 37/1995, de Telecomunicaciones por Satélite. • Ley 42/1995, de Telecomunicaciones por Cable. • Ley 17/1997, sobre aspectos técnicos de la TV digital, modificad por RD Ley 16/1997. • D. Adicional 44 de la Ley 66/1997 (habilita al Gobierno para el desarrollo de la TDT; modificada por la Ley de Medidas 55/99) y DA 44 de la Ley 50/1998 (régimen transitorio de los operadores de cable). • Leyes Orgánicas que aprueban los Estatutos de Autonomía (recogen competencias en desarrollo competencias audiovisuales). • Ley 53/2002, de Medidas Fiscales, Administrativas y del Orden Social (modifica la Ley de Televisión Local para adaptarla al entorno digital). • Ley 32/2003, General de Telecomunicaciones. 18 2. Estado del arte Normas reglamentarías: • Orden de 9 de octubre de 1998, por la que se aprueba el Reglamento Técnico y de Prestación del Servicio de Televisión Digital Terrenal. • Real Decreto 2169/1988, de 9 de octubre, por el que se aprueba el Plan Técnico Nacional de Televisión Digital Terrenal. Otras normas del audiovisual: • Ley de Propiedad Intelectual (1987-1999). • Incorporación de Directiva europea sobre Propiedad Intelectual en la Sociedad de la Información (2003-2004). • “LSSI” Ley Servicios de la Sociedad de la Información y Comercio electrónico (2002). • Código Penal (piratería de los contenidos). • Reforma Código Penal (piratería/acceso). Queda pendiente por aprobar por el Gobierno la Ley General de Radio y Televisión. Esta ley hará una distinción entre ‘televisión digital’ y ‘contenidos audiovisuales’. Respecto del espectro radioeléctrico, se repartirá el asignado a Quiero entre las principales cadenas de televisión (redistribución del espectro). 2.1.2. MHP Tras estudiar la TV Digital en el apartado anterior, se propone el estudio de MHP (Multimedia Home Platform). MHP es un estándar del DVB que define una interfaz genérica entre aplicaciones digitales y los terminales en los que se ejecutan. MHP puede ser una solución para servicios convergentes en un futuro próximo. 2.1.2.1. Introducción El reto que plantea la transición hacia la TVD no es la resolución de problemas tecnológicos. La mayor dificultad reside en lograr la viabilidad económica de unos proyectos cuya envergadura y alcance implica la realización de importantes inversiones, tanto en tecnología como en la generación de contenidos. Para reducir el riesgo de estas inversiones es fundamental alcanzar pronto una masa crítica de consumidores que posibilite la obtención de beneficios en un plazo razonable. Y para ello, sin duda, es necesario optimizar la relación entre el valor añadido que se le ofrece al usuario y el coste que le supone. [MHPLIBRE2002] Hasta el momento, la mayoría de las redes de distribución de TVD muestran una integración vertical, en la que un único proveedor controla toda la cadena de difusión: la cabecera, el sistema de acceso condicional, los equipos transmisores, y el HW y SW del STB. Para el desarrollo, difusión y ejecución de aplicaciones interactivas, estas redes emplean APIs propietarias, por ejemplo MediaHighway y OpenTV. Para conseguir la integración de estos nuevos servicios en el mercado de la TV, es necesario normalizar las tecnologías empleadas a lo largo de la cadena de distribución, porque sólo un mercado horizontal y sólidas garantías de compatibilidad permitirán la reducción de costes (economías de escala) y alcanzar al mayor número de usuarios posible. 19 2. Estado del arte En este escenario de intento de normalización, el organismo más influyente hoy en día es el consorcio DVB (Digital Video Broadcasting), surgido en el seno del grupo europeo de desarrollo de la TVD. El DVB ha conseguido gran aceptación en sus propuestas referidas a la transmisión por difusión, la información de servicio, y el canal de retorno para servicios interactivos. La última fase de estandarización, todavía en desarrollo, se centra en la integración de los nuevos formatos de información y en la arquitectura del receptor. Estos son los aspectos cubiertos por la especificación MHP (Multimedia Home Platform). Un grupo del DVB denominado TAM (Technical Aspect of the MHP) fue el encargado de desarrollar las especificaciones técnicas. Frente a las soluciones comerciales existentes, el TAM consideró que la tecnología Java de Sun Microsystems podía ser la tecnología base de MHP, debido principalmente a dos razones: • El lenguaje Java proporciona soporte para la convergencia entre Internet y las redes de difusión de contenido. Este soporte incluye protocolos Internet y muchas opciones de seguridad. • Java es una tecnología independiente del sistema operativo y del procesador. Basa su ejecución en la existencia de una Máquina Virtual Java (JVM, Java Virtual Machine). Por esto el DVB tomó la decisión de adoptar la tecnología Java para el desarrollo de TVD Interactiva, creando una plataforma Java específica para receptores de TVD Interactiva. Esta plataforma fue llamada DVB-J. [MHPVIGO] 2.1.2.2. DVB El DVB es un consorcio de más de 300 operadores de red, difusores de TV, proveedores de contenidos, fabricantes de equipos, etc, en unos 35 países cuyo objetivo es crear estándares para TVD y servicios de datos. Fue formado en septiembre de 1993 en el ámbito europeo. [DVB] El objetivo de DVB es el establecimiento de un marco de referencia para la introducción de servicios de TVD a través de diversos medios de transmisión, así como el desarrollo de normas y métodos de operación de sistemas de transmisión por satélite, cable, etc. El DVB mantiene relaciones constantes con los organismos de normalización mundial y con otros grupos vinculados a sistemas digitales, como DAVIC y MPEG: • DAVIC (Digital Audio Visual Council, Consejo de Audiovisual Digital): Organización internacional de normalización sin ánimo de lucro. Promueve la aplicación de servicios audiovisuales y digitales. • MPEG (Moving Picture Experts Group): es un grupo de trabajo de la ISO/IEC (International Organization for Standardization/Internacional Electrotechnical Comisión, Organización Internacional para la Normalización/ Comisión Internacional de Electrotécnia). Desarrollan estándares para la representación de audio y vídeo digital. El proyecto DVB desarrolla especificaciones para TVD, que son convertidos en estándar por organismos como el ETSI, el CENELEC o el EBU: 20 2. Estado del arte • ETSI (European Telecommunications Standards Institute, Instituto Europeo de Normalización de las Telecomunicaciones). Organización oficial de normalización de telecomunicaciones a nivel europeo. • CENELEC (Comité Européen de Normalisation Electrotechnique, Comité Europeo de Normalización Electrotécnica). Desarrolla trabajos de normalización en el campo electrotécnico. En otros sectores técnicos está el CEN (Comité Européen de Normalisation, Comité Europeo de Normalización). • EBU (European Broadcasting Union, Unión Europea de Difusión). Promueve el desarrollo de las nuevas tecnologías de difusión y contribuye al desarrollo de sistemas de radio y TV. Estos tres organismos han formado un comité técnico llamado JTC Broadcast (Joint Technical Committee, Comité Técnico Combinado) para tratar los estándares del DVB. Una vez que las especificaciones son convertidas en estándar, se promueve su uso para ser internacionalmente adoptados y utilizados. Existen familias de estándares relativos a la transmisión y distribución, la implementación del canal de retorno, la radiodifusión de datos, la navegación asistida y el acceso condicional, entre otros. Sin embargo los procesos de normalización, diseño y puesta en el mercado son lentos, teniendo en cuenta esto, DVB permite la salida a determinados productos como soluciones interinas (legacy). Las características comunes de los estándares DVB son las siguientes: • Abiertos: Los estándares DVB, una vez han sido publicados, están disponibles para cualquier persona en todo el mundo, independientemente del lugar en el que se hayan desarrollado. • Interoperabilidad: Cualquier sistema DVB ha de ser compatible con otro sistema DVB. Además, tienen la posibilidad de ser trasladados de un medio a otro de forma sencilla. Por ejemplo, las señales DVB se mueven fácilmente del satélite al cable y del cable al sistema terrestre. • Flexibles: DVB puede entregar a casa casi todo lo que puede ser digitalizado. De manera que puede trabajar con TV de Alta Calidad (HDTV), con datos multimedia en banda ancha e incluso con servicios interactivos. • Dirigidos al mercado: DVB se encarga de desarrollar los productos que necesita el mercado, para ello se hace un estudio de los requisitos comerciales y en base a ellos realiza sus estándares. Esto le permite trabajar en lo que busca el usuario, dándole una fuerte ventaja a la hora de mostrar sus productos. El inconveniente de esta filosofía es que ha de funcionar con agendas muy apretadas. Los éxitos de los estándares DVB han sido muy notables y han traspasado las fronteras europeas, siendo muchos los países que han adoptado ya alguno de los sistemas DVB disponibles. El conjunto de todos los estándares del DVB cubre un marco muy amplio y complejo. Por eso el DVB ha editado un libro que resume dichos estándares, recogiendo una descripción de los múltiples documentos generados en el entorno del DVB. Este libro se conoce como Cookbook, y en él encontramos la siguiente división: [DVBCOOK] • Procesado: Una de las primeras (y más importantes) decisiones que tuvo que tomar el DVB fue elegir MPEG-2 para la codificación de audio y vídeo, así como para el flujo de transporte. Estándares DVB-MPEG y DVB-SI (entre otros). • Transmisión: Según el sistema de transmisión, existen tres divisiones posibles a ser contempladas: 21 2. Estado del arte Por satélite: El estándar se llama DVB-S. Por cable: El estándar se llama DVB-C. Por radiodifusión terrestre: El estándar se llama DVB-T. Por microondas: Según la frecuencia, el estándar será DVB-MS (a partir de 10 GHz), o bien DVB-MC (menos de 10 GHz). • Acceso condicional: Estándar DVB-CA. Este estándar incluye los siguientes tipos de acceso condicional: o Simulcrypt: Es un sistema que se caracteriza por permitirle a la plataforma poseer varios sistemas de acceso condicional diferentes. La ventaja es que puede utilizar diferentes fabricantes de descodificadores. o Multicrypt: Permite la utilización de dos sistemas de acceso condicional en el mismo descodificador mediante un módulo de ampliación (posiblemente una tarjeta PCMCIA). • Servicios interactivos: Muchos de los servicios requieren de interactividad. Por esto es necesario un canal de retorno. El conjunto de herramientas para proporcionar este retorno son dos: o Independiente de la red: Pila de protocolos de nivel 2-3 según el modelo OSI Una importante parte de esta pila es derivada de los protocolos DSM-CC (Digital Storage Media Command Control) creados por el MPEG. o Dependientes de la red. Estándares de retornos de redes como PSTN (Public Switched Telephone Networks, RTB), ISDN (Integrated Services Digital Networks, RDSI), GSM (Global System for Mobile communications), DECT (Digital Enhanced Cordless Telecommunications), LMDS (Local Multi-point Distribution Systems). • Plataforma multimedia del hogar: El estándar DVB-MHP define un interfaz entre las aplicaciones digitales interactivas y los terminales en los que se ejecutan. o o o o 2.1.2.3. Especificación MHP La norma MHP define además un contexto de ejecución para las aplicaciones digitales interactivas así como un interfaz genérico (la API MHP) entre dichas aplicaciones y los terminales donde se ejecutan. Este interfaz independiza a los proveedores de aplicaciones y contenidos del HW y SW específico del terminal receptor. Estos terminales son [MHPVIGO]: • STBs de altas o bajas prestaciones. • Televisores digitales integrados. • PCs multimedia. MHP ofrece una solución para la ejecución de aplicaciones interactivas y para la presentación de contenidos de Internet en el terminal de usuario. Proporciona un modelo abstracto para el acceso a flujos de información, eventos, archivos, registros de datos y recursos hardware. Las versiones actuales de MHP son MHP 1.0 y MHP 1.1. [MHP], 2.1.2.3.1. Perfiles MHP Las posibilidades que el formato digital de la información abre al mundo de la TV son muchas y muy variadas. La especificación MHP no es ajena a esta variedad, por lo que se han considerado desde el principio una jerarquía de áreas de aplicación. Cada una de estas áreas define una extensión de servicios sobre la anterior, con la 22 2. Estado del arte consiguiente necesidad de mayores recursos HW y SW para dar soporte a los nuevos servicios. [MHP] [DVB] Inicialmente, estas áreas de aplicación (denominadas perfiles de aplicación en la norma MHP), son tres: • Difusión enriquecida (enhanced broadcasting). Combina la difusión de audio y vídeo con la posibilidad de ejecutar aplicaciones que ofrecerán interactividad local sin la necesidad de un canal de retorno. • Difusión interactiva (interactive broadcasting). Extiende la difusión enriquecida permitiendo ofrecer un amplio número de servicios interactivos sustentados en la existencia de un canal de retorno. • Acceso a Internet (Internet Access). Extiende la difusión interactiva proporcionando contenidos y servicios Internet. El grado de definición de la TV como medio de representación es notablemente inferior al de un monitor de ordenador, así como las condiciones en las que los usuarios observan la pantalla. Por ello, el DVB, en un intento de adaptar lenguajes y formatos para optimizar la calidad de representación, ha particularizado la versión de HTML empleada por las aplicaciones que gestionen el acceso a Internet. A esa adaptación se le denomina DVB-HTML. Figura 2.7. Perfiles MHP Para cada perfil los requerimientos del equipo receptor son mayores. A continuación se muestra una tabla comparativa de los recursos necesarios en cuánto a procesamiento (CPU), memoria (RAM y FLASH) ente un STB básico, MHEG-5 y cada uno de los tres perfiles de MHP. [NEWELL2002] 23 2. Estado del arte STB básico MHEG-5 Middleware propietario típico (OpenTV, por ejemplo) MHP perfil 1: Difusión enriquecida MHP perfil 2: Difusión interactiva MHP perfil 3: Difusión enriquecida CPU 30 MHz 50 MHz 50 MHz RAM 1-2 MB 4 MB 4-8 MB FLASH 1-2 MB 2 MB 4 MB 50 MHz 8-16 MB 4 MB 80-130 MHz 8-16 MB 8 MB 150-200 MHz 16-32 MB 16 MB Tabla 2.1. Recursos de receptores de TVD Este es uno de los principales escollos que se encuentra la tecnología MHP: es necesario equipos de altas prestaciones en comparación con los sistemas actuales. A continuación se muestran otras tablas comparativas, entre un PC y un TV/STB: Resolución CPU Almacenamiento Interfaz STB 720x576 Limitada Limitado mando a distancia PC 800x600 – 1074x768 ... potente y creciente muy grande, creciente ratón / teclado Tabla 2.2. Comparativa STB – TV Distancia Uso Ámbito Manejo Intención TV 3 metros Familiar Universal mando a distancia Ocio PC 40 centímetros personal/profesional Reducido ratón / teclado Trabajo Tabla 2.3. Comparativa PC – TV 2.1.2.3.4. Arquitectura MHP Un receptor MHP y su SW asociado tienen acceso a distintos flujos de información. Básicamente, debe procesar flujos de entrada y/o salida de datos, vídeo y audio, asociados al canal de difusión y al canal de interacción (el que posibilita la comunicación con el proveedor de servicios). Procesará también eventos de entrada del usuario y debe presentar la información adecuada en un medio audiovisual, como puede ser un televisor. [MHPVIGO] La arquitectura genérica de un receptor MHP está definida en tres capas [MHP]: • Recursos HW: Típicamente estos recursos son procesadores MPEG, dispositivos de E/S, CPU, memoria y el sistema de gráficos. También entran en esta capa los recursos SW dependientes de HW (drivers). • SW de sistema: Capa de recursos SW independiente del HW, también conocida como también como middleware. Esta capa usa los recursos disponibles para proporcionar una plataforma de cara a las aplicaciones. • Aplicaciones. 24 2. Estado del arte Figura 2.8. Arquitectura MHP La norma MHP se centra en la descripción de la capa de SW de sistema y en la interfaz entre ésta y la capa de aplicación (API MHP). 2.1.2.3.5. Software del sistema (middleware) La capa de SW de sistema consiste en un sistema operativo sobre el que se apoya una plataforma Java denominada DVB-J definida específicamente para un receptor de TVD interactiva. Dicha plataforma consta de una JVM que da soporte a una serie de diversas APIs que en su conjunto conforman el interfaz MHP que verán las aplicaciones. La siguiente figura muestra la arquitectura SW de MHP en detalle: [MHPVIGO] Figura 2.9. Arquitectura MHP en detalle 25 2. Estado del arte Una aplicación DVB-J (también conocida como Xlet) es un programa escrito en Java que cumple dos requisitos principales: • Hace uso únicamente de las librerías y APIs de clases Java definidas expresamente en la norma MHP. • Genera y atiende a una serie de señales que implementan un ciclo de ejecución (ciclo de vida) perfectamente especificado en la norma MHP, y que permite que una aplicación sea fácilmente controlada por el gestor de aplicaciones de la máquina MHP. El gestor de aplicaciones es la entidad encargada de arrancar y parar las distintas aplicaciones y de monitorizar su ejecución. La especificación define otra entidad adicional (que no aparece en la figura anterior) denominada Home Navigator. Consiste en una aplicación residente en el receptor que no está sujeta al ciclo de vida diseñado para las Xlets. Esta aplicación permite la interacción entre usuario y receptor. Se basa en un interfaz gráfico que facilita al usuario la elección del canal a visionar y la ejecución de las aplicaciones que acompañan a cada uno de ellos. A pesar de que el Home Navigator no sea una aplicación DVB-J sí requiere incluir una parte de DVB-J, puesto que debe tener acceso a sistemas definidos como DVB-J en el estándar, como sintonizar servicios o controlar el ciclo de vida de las aplicaciones. 2.1.2.3.6. API MHP Para la API MHP, el DVB ha aprovechado varios trabajos anteriores para incluirlos en la especificación. Se pueden distinguir cuatro bloques: [MHPVIGO] [WEBITV] • Sun Java APIs. APIs desarrolladas por Sun Microsystems. Dentro de este bloque se diferencian: o Parte del núcleo fundamental definido en la plataforma Java JDK 1.1.8. Se incluyen paquetes como java.lang, java.util, java.io, etc. Pero hay restricciones y omisiones. La más notable para los desarrolladores puede ser la restricción de java.awt y la omisión de java.applet. Pero ambos paquetes sí que son soportados para el perfil de acceso a Internet. Esta parte puede ser implementada con PJava (Personal Java). o JMF (Java Media Framework) APIs. MHP utiliza JMF para presentar y controlar el audio y el vídeo. Los siguientes paquetes han de ser soportados por una implementación MHP (con ciertas restricciones): javax.media y javax.media.protocol. o JSEE (Java Secure Sockets Extensión) APIs. Conjunto de paquetes que aseguran comunicaciones seguras a través de Internet. Implementa la versión Java de SSL (Secure Sockets Layer) y de TLS (Transport Layer Security) e incluye funcionalidades para encriptación de datos, autenticación, etc. o Subconjunto de la API JavaTV. JavaTV es un conjunto de paquetes genéricos que proporcionan un control sobre funcionalidades exclusivas del entorno de la TV interactiva, y que pueden ser definidas de manera independiente de un protocolo de transporte específico. Alguna de éstas son: acceso a la información de servicio del flujo de transporte, acceso a los detalles de la programación de los servicios transmitidos, localización de código y datos de las aplicaciones... JavaTV está definido en un alto nivel de abstracción con respecto al HW y a los protocolos de transporte. Por tanto, es igualmente válida en un sistema DVB como en otro sistema diferente. La parte más relevante de la API JavaTV es el paquete javax.tv.xlet. En él se proveen las interfaces que utilizan las aplicaciones y el Gestor de Aplicaciones para comunicarse. El paquete define dos entidades: 26 2. Estado del arte Xlet y XletContext. La función de las mismas es la de modelar y manejar los estados por los que puede pasar una aplicación DVB-J (su ciclo de vida). Xlet es un interfaz que ha de ser implementado por la clase principal de toda aplicación. Cuando una aplicación DVB-J (también llamada Xlet) es cargada, se crea una instancia de la clase principal. La aplicación es controlada vía llamada a métodos de esa instancia. Los métodos del interfaz Xlet son utilizados por el Gestor de Aplicaciones para hacer llegar a las mismas solicitudes de cambios de estado. Así mismo, al ser cargada, la aplicación recibe una instancia de XletContext, a través de la cual hace llegar al Gestor notificaciones de cambios de estado. Cada Xlet recibe su propia instancia de XletContext. • DAVIC APIs. Dentro de MHP se incluyen algunas partes del estándar DAVIC. Trata temas relacionados con funciones de bajo nivel del STB: sintonización del flujo de transporte, acceso condicional, filtrado de secciones privadas de MPEG-2, uso de recursos escasos, etc. o org.davic.media: Proporciona varias extensiones a JMF para el control de audio/vídeo orientado a la TV. Muchas de las clases e interfaces no requeridas por la especificación MHP no han sido incluidas. o org.davic.mpeg: Proporciona clases de utilidad para el manejo de conceptos comunes sobre MPEG (como el acceso al filtrado de secciones). o org.davic.net: Incluye aspectos relacionados con el sistema de acceso condicional, y la sintonización del múltiplex MPEG-2. o org.davic.resources: proporciona un marco para la gestión de recursos escasos. • HAVi GUI APIs. La norma HAVi (Home Audio Video Interoperability) define las características más apropiadas que deben tener los elementos empleados para desarrollar el interfaz gráfico (GUI, Grafic User Interface) de las aplicaciones en un contexto como el de la televisión. Los paquetes HAVi incluidos en la especificación MHP sustituyen las funcionalidades del java.awt que han sido omitidas en MHP o org.havi.ui: Proporciona clases para creación de interfaces de usuario y para pintar gráficos e imágenes. • APIs específicas definidas por DVB (paquete org.dvb) En ellas se definen todos los aspectos necesarios para gestionar las nuevas funcionalidades de los receptores y que no han sido cubiertos todavía por las APIs ya mencionadas: o org.dvb.application: Proporciona acceso a la lista de aplicaciones disponibles en un contexto determinado y la posibilidad de arrancarlas o org.dvb.dsmcc: Proporciona acceso a los ficheros que viajan embebidos en el flujo de difusión. o org.dvb.event: Permite acceder a los eventos de entrada provocados por el usuario antes de que éstos sean procesados por el mecanismo de gestión de eventos del paquete java.awt. o org.dvb.io: Proporciona soporte a aspectos como la comunicación entre aplicaciones. o org.dvb.lang: Proporciona funcionalidades relacionadas con el núcleo de la plataforma que no se encuentran en el paquete java.lang. o org.dvb.media: Proporciona extensiones específicas de DVB a JMF o org.dvb.net: Incluye extensiones a la API de acceso condicional de DAVIC (org.dvb.net.ca); manejo de conexiones IP bidireccionales basadas en sesiones desde el punto de vista de la aplicación (org.dvb.net.rc); y extensiones a la API de sintonizado de la API DAVIC (org.dvb.net.tuning). o org.dvb.si: Proporciona acceso a las tablas SI (Service Information) de DVB o org.dvb.test: Permite que las aplicaciones realicen logs durante su ejecución y notifiquen su terminación de una manera independiente de la plataforma o org.dvb.ui: Extiende funcionalidades gráficas o org.dvb.user: Proporciona acceso a las preferencias y configuraciones realizadas por el usuario final 27 2. Estado del arte La siguiente figura muestra como encajan las diferentes APIs juntas en una posible implementación de un receptor MHP. Las APIs sombredas están construidas encima de la API de gestión de recursos escasos de DAVIC. [WEBITV] Figura 2.10. Arquitectura de las APIs en MHP Como se puede ver, las APIs pueden dividirse de manera aproximada en dos partes. Una de las partes tiene que ver con los flujos MPEG y los servicios que éstos llevan asociados. La otra parte está construida directamente sobre PJava. 2.1.2.3.7. El gestor de aplicaciones El Gestor de Aplicaciones es el responsable de arrancar y parar las aplicaciones cuando sea preciso, así como de monitorizar su ejecución. Cualquier interacción entre el resto de la plataforma MHP y una aplicación que pueda afectar a su ciclo de vida ha de ser llevada a cabo a través del Gestor de Aplicaciones. [MHPVIGO] 2.1.2.3.8. La tabla AIT El DVB ha definido para MHP una nueva tabla de información de servicio (SI) que completa las ya existentes para MPEG2. Esta tabla se denomina AIT (Application Information Table), y es difundida con cada servicio que contenga aplicaciones MHP. Incluye una entrada por cada aplicación válida en ese servicio. [MHP] La AIT contiene toda la información que el receptor necesita para ejecutar una aplicación (nombre de la misma, localización de sus ficheros, argumentos que se le han de proporcionar, etc.) y para informar al usuario de las aplicaciones disponibles en un momento determinado. Toda aplicación difundida tiene un identificador único que también se almacena en la AIT y que permite a los demás componentes del sistema referirse a ella de forma unívoca. En la AIT se incluye un indicador de status para cada aplicación. Según el mismo, una aplicación puede arrancar automáticamente cuando el servicio es seleccionado (autoarranque), puede ser detenida automáticamente si está ejecutándose o puede esperar a ser arrancada manualmente por el usuario. Los ficheros de las aplicaciones, como ya se ha introducido, son difundidos como parte del flujo de transporte MPEG-2, en un carrusel de objetos según la norma DSM-CC. En la AIT también se incluye por cada aplicación un descriptor de localización que identifica el carrusel de objetos en el que viaja la misma así como el path dentro de ese carrusel (ya que un mismo carrusel puede tener más de una aplicación). 28 2. Estado del arte Cuando el receptor conmuta a un nuevo servicio (canal), en primer lugar el Gestor de Aplicaciones examina el conjunto de aplicaciones que se están ejecutando en ese momento. Todas aquellas que estén definidas como "ligadas al servicio" (es decir, que sólo pueden ejecutarse en el entorno de ese servicio en concreto) son detenidas automáticamente para que no continúen en el nuevo servicio. Posteriormente se obtiene la AIT del nuevo servicio y el gestor examina las aplicaciones que aparecen en ella. Todas aquellas que estén señalizadas como de autoarranque son cargadas y puestas en ejecución. Las aplicaciones del anterior servicio que no aparezcan en el nuevo se eliminan, a no ser que dispongan de una autorización especial que aparece en la AIT (mediante un sistema de autorizaciones a aplicaciones externas que se basa en los identificadores únicos comentados anteriormente). De esta manera un broadcaster A puede llegar a un acuerdo con otro B mediante el cual se permita que las aplicaciones de A sigan ejecutándose a pesar de que se haya conmutado de un servicio de A a un servicio de B (siempre que no haya conflicto entre aplicaciones de uno y de otro). Otro aspecto a tener en cuenta es que cada aplicación especifica qué perfil MHP y qué versión del mismo requiere para ser ejecutada. Toda entrada en una tabla AIT que señalice un perfil o versión de perfil superior al que el receptor puede manejar será ignorada. [MHPVIGO] 2.1.3. Formatos multimedia Para entender las soluciones convergentes del sector audiovisual, en primer lugar hay que realizar un estudio pormenorizado de los diferentes sistemas de codificación de contenidos multimedia. Dicho estudio se va a realizar en este apartado. En primer lugar hay que distinguir entre un codec y un formato contenedor: [VIDEOLAN] • Un codec es un algoritmo de compresión, utilizado para reducir el tamaño de un flujo. Existen codecs de audio y codecs de vídeo. MPEG-1, MPEG-2, MPEG-4, Vorbis, DivX, Xvid, etc. • Un formato contenedor contiene uno o varios flujos ya codificados por codecs. Normalmente hay un flujo de audio y uno de vídeo. Ejemplos de formatos contenedores son AVI, OGG, MOV, ASF, MKV, MKA, etc. Los flujos que contengan pueden ser codificados utilizando diferentes codecs. A continuación se detalla una lista los formatos contenedores y codecs más populares en la actualidad. Evidentemente, el número total de formatos es muy superior al que se incluye en esta memoria, pero estos son los descritos a continuación son los más relevantes. 2.1.3.1. Formatos contenedores 2.1.3.1.1. AVI El formato AVI (Audio Video Interleave) fue diseñado por Microsoft y es un formato amplio multipropósito actualmente usado por la mayoría de los vídeos DivX Xvid. Tiene un funcionamiento muy simple, pues almacena la información por capas, guardando una de vídeo seguida por una de audio. Soporta solo un flujo de vídeo y de 29 2. Estado del arte 0 a 99 flujos de audio y puede ser de hasta 2GB de grande, pero existe una extensión que permite archivos más grandes llamada OpenDML. La principal ventaja de AVI es que es un formato maduro y soportado por la mayoría de programas multimedia. La desventaja de este formato es que no fue diseñado para streaming, con lo que no es eficiente a la hora de transmitirlo en tiempo real. La estructura de un fichero AVI no es secuencial. Existen estructuras de datos que están multiplexadas con los flujos de audio y vídeo. Esto hace que a la hora de hacer saltos en la ejecución (seek) sea necesario leer de varias posiciones. En transmisión por streaming esto es un problema, ya que no se dispone de todo el fichero en el momento de la reproducción. Hay un hack (truco informático) que permite que los archivos AVI contengan flujos de audio en Ogg Vorbis, pero los hace incompatibles con los AVI estándar. [MPLAYERDOC] 2.1.3.1.2. OGG OGG es el nombre del formato contenedor de audio creado por la fundación Xiph.org. Pertenece al proyecto homónimo OGG. [OGG] Xiph.Org es una fundación sin ánimo de lucro dedicada a proteger la esencia de la Internet multimedia del control de las grandes corporaciones. Su propósito es apoyar y desarrollar una serie de protocolos libres y abiertos, el Proyecto OGG, y programas libres para servir al público, los desarrolladores y las empresas. [XIPH] OGG fue diseñado para streaming, y el flujo de audio que contiene va codificado con un codec llamado Vorbis. [VORBIS] OGG no ha sido diseñado para vídeo, ni cualquier otro tipo de audio. 2.1.3.1.3. OGM OGM (OGg Media) es la implementación de OGG para soportar vídeo, otros codecs de audio, y un tipo de subtítulo. Es un formato bastante nuevo, así que el soporte de software es muy limitado. Hay poco programas de edición que permitan utilizarlo como entrada o salida. OGM es una extensión no oficial (no forma parte de xiph.org) del OGG capaz de almacenar otros formatos (XviD, DivX, mp3, ac3, etc.) aparte de los oficiales de la xiph.org (FLAC, Vorbis, Speex, Theora). OGG no es un formato contenedor en si. El formato contenedor sería OGG. OGM es un archivo OGG renombrado para indicar que contiene vídeo. [BARRAPUNTO] Es mejor que AVI por algunas características importantes [DIVX-DEUX]: • Soporta de forma nativa audio de bitrate variable. AVI estándar no lo es. Los ficheros AVI que soportan esta característica están hackeados. • Los saltos en la reproducción (seek) son instantáneos. Con AVI el vídeo tiene que acelerarse hasta sincronizarse con el audio cuando hay un salto. • La sincronización con el audio es perfectamente estable, tiene chequeo de integridad y permite recuperar partes de un archivo aunque se haya dañado. 30 2. Estado del arte 2.1.3.1.4. Matroska Matroska [MATROSKA] es un proyecto que ha nacido con el atrevido objetivo de convertirse en el Formato Contenedor Multimedia estándar. Matroska es un proyecto estándar abierto. El código fuente de todas las librerías desarrolladas por el equipo de desarrollo de Matroska serán licenciadas bajo licencias GNU GPL y QPL (Licencia dual). Los fundadores de Matroska tienen las siguientes metas: • Crear y documentar un moderno, flexible, y multiplataforma contenedor de audio/vídeo. • Establecer Matroska como la alternativa de código abierto a los contenedores existentes como AVI, ASF, MOV, RM, MP4, MPG. • Desarrollar un conjunto de herramientas para la creación, edición e implementación de los ficheros Matroska, bajo una licencia de tipo GNU GPL. • Desarrollar librerías y herramientas para que los desarrolladores de software puedan ofrecer soporte a Matroska en sus aplicaciones. • Preparar soporte hardware de ficheros Matroska en la próxima generación de unidades de reproducción individuales, en cooperación cerrada con los creadores de dispositivos. • Soporte adaptable e implementación de las librerías de Matroska a OpenBeOS Mediakit y Gstreamer (Multimedia Framework para Linux, equivalente a Microsoft DirectShow para Windows). • Lanzar un conjunto de filtros DirectShow para la reproducción y creación de ficheros Matroska en Sistemas Operativos Windows. Las extensiones de los archivos Matroska son: • mkv: Archivos de audio y/o vídeo. • mka: Archivos de audio, puede contener cualquier formato de compresión de audio, como MP2, MP3, Vorbis, AAC, AC3, DTS, PCM • mks: Llamada 'elementary' de Matroska, que puede contener cualquier cadena de subtítulos. [MATROSKA.INFO] 2.1.3.1.5. MPEG MPEG (Moving Picture Experts Group) el grupo de trabajo 11, subcomité 29 de ISO/IEC12 Joint Technical Committes 1. Fue establecido en 1988. MPEG se encarga de desarrollar estándares para la representación de audio digital y vídeo, como por ejemplo: [MPEG-GROUP] Los archivos MPEG vienen en diferentes formas: [MPLAYERDOC] [DOOM] • MPG/MPEG: Esta es la forma más básica de los archivos de formato MPEG. Contiene vídeo MPEG-1 ó MPEG-2, y audio MP2 (MPEG-1 layer 2) o rara vez audio MP1. • DAT: Este es exactamente el mismo formato que un MPG con la diferencia en la extensión. • VOB: Este es el formato de archivo MPEG en DVDs. Es el mismo que MPG, sumando la capacidad para contener subtítulos o audio no-MPEG (AC3). Contiene 31 2. Estado del arte • • • • vídeo codificado con MPEG-2 y normalmente audio en AC3, pero DTS, MP2 y LPCM sin comprimir también está permitido. M1V/M2V: Formato de sólo vídeo para MPEG-1 y MPEG-2 respectivamente MP1/MP2/MP3: Formato audio para audio MPEG-1 layer 1, 2 y 3 respectivamente. M2P: Formato de audio y vídeo MPEG-2 PS (Program Stream). M2T: Formato de audio y vídeo MPEG-2 TS (Transport Stream). 2.1.3.1.6. Quicktime Quicktime es un sistema de reproducción de vídeo/audio propietario de Apple. [APPLE] Los formatos de vídeo quicktime pueden contener cualquier codec, CBR o VBR. Los archivos de quicktime tienen extensión MOV, QT y MP4 entre otras. [QUICKTIME] 2.1.3.1.7. Realmedia La compañía RealNetworks proporciona una plataforma universal para la difusión de contenido multimedia a través de redes como Internet. [REALNETWORKS] En base a este principio, los formatos de RealMedia (ficheros RM) son muy adecuados para streaming. 2.1.3.1.8. ASF ASF (Advanced Streaming Format) es la respuesta de Microsoft a RealMedia y el resto de los medios de streaming en general. ASF es un formato de archivo extensible diseñado para almacenar información multimedia sincronizada. Es compatible con la entrega de datos en una gran variedad de redes y protocolos, así como con la reproducción local. ASF admite funciones multimedia avanzadas, como tipos de medios extensibles, descarga de componentes, tipos de medios escalables, establecimiento de prioridades especificadas por el autor para las secuencias, compatibilidad con varios idiomas y amplias funciones bibliográficas (por ejemplo, administración de documentos y de contenido). ASF se reproducir en el reproductor de Windows, el Windows Media Player. [MICROSOFT] 2.1.3.1.9. WAV WAV (o WAVE), apócope de WAVEform audio format, es un formato de audio digital normalmente sin compresión de datos desarrollado y propiedad de Microsoft y de IBM que se utiliza para almacenar sonidos en el PC. Es una variante del formato RIFF, método para almacenado en paquetes, y relativamente parecido al IFF y al formato AIFF usado por Macintosh. El formato toma en cuenta algunas peculiaridades de la CPU Intel, y es el formato principal usado por Windows. A pesar de que el formato WAV puede soportar casi cualquier codec de audio, se utiliza fundamentalmente con el formato PCM (no comprimido) y al no tener pérdida de calidad puede ser usado por profesionales. 32 2. Estado del arte No es funcional para transmitirlo por Internet, porque los archivos sin compresión son muy grandes. Son más frecuentes los formatos comprimidos con pérdida, como el MP3 o el OGG Vorbis. Como éstos son más pequeños la transferencia a través de Internet es mucho más rápida. 2.1.3.2. Codecs de vídeo 2.1.3.2.1. MPEG vídeo El grupo MPEG ha desarrollado toda una familia de estándares de audio y vídeo. A continuación se detallan los codecs de vídeo MPEG: [MPEG-GROUP] • MPEG-1: Estándar más popular para el audio y vídeo. Productos como el VCD o MP3 están basados en este estándar. La calidad es similar a la ofrecida por un VCR. • MPEG-2: Estándar para TV digital, DVD, o SVCD. Más potente que MPEG-1, mejor calidad. • MPEG-4: Estándar para multimedia. Tanto MPEG7 como MPEG21 extienden la funcionalidad de MPEG4. • MPEG-7: Estándar para la descripción y búsqueda de contenidos de audio y vídeo. • MPEG-21: "Multimedia Framework". Proporciona interactividad con el audio-vídeo para los usuarios finales. • MPEG-A: "Multimedia Application Format". Diseñado para integrar los estándares MPEG en una única especificación que sea extensible a las aplicaciones. Existen muchas variantes para VCD (MPEG-1) y SVCD-2 (MPEG-2). En la siguiente tabla se detallan las más importantes, así como sus características más significativas: [MUNDODIVX] 33 Máx. permitido 44.100 / 48.000 352x576 352x480 25 23.976 / 29.976 MPEG-2 MPEG Layer 2 CBR / VBR Hasta 2550 Máx. permitido 44.100 / 48.000 704x576 720x576 704x480 720x480 25 23.976 / 29.976 MPEG-2 MP2 / AC3 / WAV CBR / VBR 34 Hasta 9000 Máx. permitido 48.000 Tabla 2.4. Formatos VCD, SVCD y derivados Fijos o seleccionables No Fijos o seleccionables Si 35 ... 60 60 ... 240 35 ... 60 SI SI SI Fijos o seleccionable s Si Hasta 2550 CBR / VBR MPEG Layer 2 MPEG-2 23.976 / 29.976 25 480x480 480x576 Super Vídeo CD China Vídeo Disc Digital Vídeo Disc SVCD CVD DVD 35 ... 60 No Fijos o seleccionables SI 44.100 / 48.000 Máx. permitido 64 ... 3000 CBR / VBR 35 ... 60 No Fijos o seleccionables SI 44.100 / 48.000 Máx. permitido 64 ... 3000 CBR / VBR MPEG Layer 2 MPEG-1 / MPEG-2 MPEG-1 / MPEG-2 MPEG Layer 2 23.976 / 29.976 25 528x480 528x576 K Vídeo Compression Dynamics KVCDx3 23.976 / 29.976 25 544x480 544x576 K Video Compression Dynamics KVCDx3A 35 ... 60 No Fijos NO 44.100 Máx. permitido Hasta 2350 CBR / VBR MPEG Layer 2 MPEG-1 23.976 / 29.976 25 480x480 480x576 Extended Vídeo CD XVCD 74 ... 130 Si Fijos NO 44.100 96 ... 224 300 ... 1150 CBR / VBR MPEG Layer 2 MPEG-1 23.976 / 29.976 25 352x240 352x288 Compressed Vídeo CD CVCD 74 / 80 / 90 Si Fijos NO 44.100 224 1150 CBR MPEG Layer 2 MPEG-1 23.976 / 29.976 25 352x240 352x288 Vídeo CD VCD Formato Framerate Resolución (Kbit/s) Bitrate Minutos / disco Compatible con autorías DVD Subtítulos Varios audios Frec. Audio (Hz) Audio Vídeo Tipo de bitrate Audio Vídeo NTSC PAL NTSC PAL Nombre Formatos 2. Estado del arte 2. Estado del arte 2.1.3.2.3. MPEG-2 En Europa, el proyecto DVB toma el estándar MPEG-2 (Moving Picture Experts Group Layer 2) como procedimiento de codificación de vídeo y audio, adaptándolo a sus necesidades. Este estándar trata tres aspectos para el desarrollo de la difusión de la TVD: [TVS] [MPEG] • El empaquetamiento de la Información. • El tratamiento de la información específica de programa (PSI, Program Specific Information). • Las velocidades de transmisión. Lo más interesante, a la hora de conocer cómo funciona este estándar internacional, es lo referido a la integración de la información que queremos transmitir (vídeo, audio y datos), en los paquetes de flujo de transporte (MPEG2-TS). La constitución de la estructura de dicho paquete de transporte se realiza como sigue: • Se parte de las Unidades de Presentación (PS, Presentation Units), que son las imágenes iniciales (vídeo) y el conjunto de muestras de sonido (audio). • Estas PS son codificadas, quedando la información segmentada, en lo que se denomina Elemento Básico de Flujo (ES, Elementary Stream); éste mecanismo de codificación y segmentación encapsula los ES en los paquetes de datos, que pueden contener un número variable de bytes contiguos, de un ES. • Los paquetes de datos son insertados en Paquetes de Flujo Elemental (PES, Packetized Elementary Stream), que contienen una cabecera seguida de varios paquetes de datos. En la cabecera se incluye información sobre la PS a la que pertenecen los paquetes de datos de cada PES, así como la información relativa al propio proceso de codificación (necesaria para la decodificación), y la información sobre el orden de secuencia de los distintos PES en los que se segmenta la imagen o sonido inicial. • Los PES son agrupados y se introducen como carga útil (payload) del Paquete de Transporte. Cada paquete de transporte lleva un Identificador de Paquete (PID) propio, de manera que todos los paquetes de transporte con el mismo identificador, llevan datos del mismo ES; en un paquete de transporte no se mezclan datos de ES distintos. La carga útil puede ser información de vídeo/audio (los PES) o puede ser información específica de programa (PSI). • Finalmente varios Paquetes de Transporte son multiplexados conformando la Trama de Transporte que está constituida por 188 bytes, de los cuales 4 forman la cabecera, donde se introduce la información necesaria para una decodificación eficaz, y el resto representan la carga útil de la trama, como se representa en la siguiente figura. • Para construir la TS, el MPEG-2 dispone de dos métodos, denominados Flujo de Programa (PS, Program Stream) y Flujo de Transporte (TS, Transport Stream). o PS: Similar a MPEG-1. Suele emplearse en la transmisión de información multimedia en entornos en los que la probabilidad de error es casi nula, como el CD-ROM. o TS: Da mejores prestaciones en entornos en los que la probabilidad de error de transmisión es elevada, como son los de radiodifusión. 35 2. Estado del arte Figura 2.11. Estructura de la trama de transporte MPEG-2 Para poder recoger los paquetes de un mismo programa al receptor le debe llegar información sobre PIDs correspondientes. Para resolver esta cuestión MPEG-2 establece unas tablas, en las que incluye toda la información necesaria para la localización de los distintos paquetes; estas tablas viajan también multiplexadas en el TS. • Tabla de Asociación de Programas (PAT): Esta es una de las tablas para las que se reservan algunos PIDs. Su función es simplemente la de indicar al receptor dónde puede encontrar las otras tablas de información. • Tabla de Acceso Condicional (CAT): Informa de los PIDs de los paquetes que contienen la información de los mensajes de gestión y control de cada Sistema de Acceso Condicional. Para esta tabla también se reservan algunos valores de PIDs. • Tabla de Mapa de Programas (PMT): Indica la localización de la cadena de inicio de cada servicio (asocia cada programa con los PIDs de los paquetes que lo componen), así como, la localización de la referencia de sincronismo del mismo. • Tabla de Información de la Red (NIT): es una tabla privada, por lo que el MPEG-2 no especifica su contenido. El Proyecto DVB amplía el campo del PSI con tablas privadas, determinando otras seis tablas propias, que engloban lo que se denomina como Información de Servicio (SI). La información transmitida en esas tablas permite, por ejemplo, que el usuario reciba las Guías Electrónicas de Programación (EPG). Las seis tablas especificadas son: • Tabla de Mapa de Programas (PMT): Indica la localización de la cadena de inicio de cada servicio (asocia cada programa con los PIDs de los paquetes que lo componen), así como, la localización de la referencia de sincronismo del mismo. • Tabla de Descripción del Servicio (SDT): describe cada uno de los servicios ofertados. • Tabla de Información de Eventos (EIT): cada transmisión concreta se considera como un evento, y esta tabla contiene información sobre la hora de inicio, la duración, etc., de cada uno de ellos. • Tabla de Estado de Funcionamiento (RST): informa sobre el desarrollo de los distintos eventos en curso. • Tabla de Tiempos y Fechas. 36 2. Estado del arte • Tabla de Tiempo de offset. • Tabla de Relleno (ST): se utiliza para alterar los límites en algunas secciones de servicio. Una de las características del MPEG es que permite adaptar la velocidad de transmisión a la calidad requerida por el programa o servicio considerado. Por ejemplo, una película puede codificarse con alrededor de 4 Mbit/s. El vídeo de calidad superior puede estar entre 6 y 8 Mbit/s, quizá lo necesario para un partido de fútbol. Un telediario podría requerir 3 Mbit/s y los dibujos animados unos 2 Mbit/s. Es posible que los sistemas de pay-per-view se codifiquen alrededor de unos 3 Mbit/s, en el caso de películas de cine que son, sorprendentemente, más fáciles de codificar, lo que mantiene, en general, una calidad mayor que una cinta de vídeo comercial. También es posible la aparición de algunos efectos extraños en la imagen (artifacts) como consecuencia de la compresión. 2.1.3.2.4. MPEG-4 MPEG-4 surge para solucionar la convergencia de tres áreas (comunicación, computación y entretenimiento). Es independiente del protocolo de transporte, esto es, define un mecanismo de comunicación basado en mensajes que puede beneficiarse fácilmente de las nuevas tecnologías de mensajería que puedan ir surgiendo. Es compatible hacia atrás con las versiones anteriores MPEG. MPEG-4 está formado por varios estándares (denominados partes). A continuación se detallan estas partes: [MPEG-GROUP] • Parte 1 (ISO/IEC 14496-1): Sistemas: Describe la sincronización y multiplexación del vídeo y audio. • Parte 2 (ISO/IEC 14496-2): Vídeo: Compresión de vídeo, texturas, imágenes, etc. Uno de los muchos perfiles de la parte 2 es el ASP (Advanced Simple Profile). • Parte 3 (ISO/IEC 14496-3): Audio: Conjunto de codecs de audio, entre los que se incluyen el AAC (Advanced Audio Coding) así como otras herramientas de codificación de habla/audio. • Parte 4 (ISO/IEC 14496-4): Conformidad: Describe procedimientos para comprobar el funcionamiento de las partes del estándar. • Parte 5 (ISO/IEC 14496-5): Software: Proporciona software para demostraciones, así como para clarificar las partes del estándar. • Parte 6 (ISO/IEC 14496-6): Entorno de integración de entrega multimedia (Delivery Multimedia Integration Framework, DMIF). • Parte 7 (ISO/IEC 14496-7): Referencias software: Proporciona ejemplos de como mejorar las implementaciones. • Parte 8 (ISO/IEC 14496-8): Transporte en redes IP: Especifica métodos de como transportar MPEG-4 en redes IP. • Parte 9 (ISO/IEC 14496-9): Referencias hardware: Proporciona hardware para implementar otras partes del estándar. • Parte 10 (ISO/IEC 14496-10): Advanced Video Coding (AVC): Un codec avanzado para vídeo llamado AVC y que es técnicamente idéntico al estándar del ITU-H H.264. • Parte 12 (ISO/IEC 14496-12): ISO Base Media File Format. Formato de archivos para contenido multimedia. • Parte 13 (ISO/IEC 14496-13): Extensiones IPMP (Intellectual Property Management and Protection). 37 2. Estado del arte • Parte 14 (ISO/IEC 14496-14): Formato de fichero MPEG-4. Formato contenedor para contenidos MPEG-4. • Parte 15 (ISO/IEC 14496-15): Formato de fichero AVC. Contenedor AVC. • Parte 16 (ISO/IEC 14496-16): Entorno de ejecución para animaciones (AFX, Animation Framework eXtension). • Parte 17 (ISO/IEC 14496-17): Formato para subtítulos. • Parte 18 (ISO/IEC 14496-18): Compresión y streaming. • Parte 19 (ISO/IEC 14496-19): Texturas, síntesis. • Parte 20 (ISO/IEC 14496-20): Lightweight Scene Representation (LASeR). • Parte 21 (ISO/IEC 14496-21): MPEG-J Extensiones. A continuación se muestra una tabla comparativa entre MPEG-1, MPEG-2 y MPEG-4: Tamaño típico de imagen Ancho de banda típico Ancho de banda máximo MPEG-1 352x240(perfil estándar) 1.5Mbps MPEG-2 720x480 (perfil principal, máximo nivel) 5Mbps MPEG-4 720x480 (perfil principal, L2) 2Mbps 2.5Mbps 15Mbps 4Mbps Tabla 2.5. Comparativa MPEG-1, MPEG-2 y MPEG-4 2.1.3.2.5. DivX DivX es un codec de vídeo, un formato de vídeo comprimido. La primera versión de DivX se llamaba “DivX ;)” y fue creada por dos jóvenes programadores (Jerome Rota y Max Morice). Este primer desarrollo formato es una modificación no legal del formato MPEG-4 de Microsoft. Actualmente el desarrollo es totalmente legal, llevado a cabo por DivxNetworks [DIVXNETWORKS], que viendo el potencial real de este codec lo comercializó y trasladó al mercado de consumo. En la actualidad no es difícil encontrar reproductores domésticos capaces de leer este formato. La versión actual es DivX Pro 5.2.1. Está disponible para Windows y Mac. [DIVX] 2.1.3.2.6. XviD Es un codec de vídeo libre (licencia GPL v2) diseñado bajo el estándar MPEG-4. Originalmente basado en el codec OpenDivX, XviD comenzó su desarrollo por un grupo de programadores, después de que se cerrara el proyecto OpenDivX. La versión estable actual es XviD 1.0.3, del 20 de diciembre de 2004. [XVID] El XviD no tiene nada que envidiar al DivX, de hecho son prácticamente compatibles ya que ambos se basan en el mismo estándar de compresión MPEG4. La mayor ventaja de XviD es que es libre. 2.1.3.2.7. Theora Es un codec de vídeo abierto que está siendo desarrollado por el Xiph.org como parte de su proyecto OGG. Todavía esta en fase de desarrollo, y la versión que está actualmente disponible es la 1.0 alpha 4. [THEORA] 38 2. Estado del arte 2.1.3.2.8. H.261 H.261 (recomendación ITU-T H.261) es un codec de vídeo para servicios p x 64 kbit/s. Forma parte del grupo de estándares H.320 para comunicaciones audiovisuales. Fue diseñado para una tasa de datos múltiplo de 64 Kbit/s. Lo cual coincide con las tasas de datos ofrecidas por los servicios ISDN. [VOIPINFO] 2.1.3.2.9. H.263 H.263 es un codec del ITU-T de vídeo. Está diseñado para videoconferencia con tasas binarias bajas. Es una versión mejorada de H.261. Existen versiones mejoradas de H.263, que son H.263v2 (también conocida como H.263 1998 ó H.263+) y H.263v3 (H.263 2000 ó H.263++). [VOIPINFO] 2.1.3.2.10. H.264 H.264 (también conocido como MPEG-4 AVC, e incluso MPEG-10) es un codec de vídeo desarrollado por el ITU-T (serie H.26x) junto con el grupo MPEG de ISO/IEC. Por parte de ITU-T el nombre es H.264, y por parte de ISO/IEC el nombre es AVC dentro de MPEG-4. [MPEG-GROUP] H.264 se utilizará para compresión de vídeo en Internet. Actualmente se encuentra en desarrollo, pero promete ser el inicio de una nueva gama de codecs y tecnologías que permitirán transmitir vídeo con calidad de DVD en Internet, sin necesidad de consumir un gran ancho de banda. 2.1.3.2.11. Vídeo JPEG Hay tres codecs basados en JPEG usados en archivos quicktime. Estos son PhotoJPEG, MJPEG-A (Motion JPEG) y MJPEG-B. MJPEG no es lo mismo que MPEG, aunque debido a que sus nombres son similares puede llevar a confusión. Las principales ventajas de MJPEG son que la compresión JPEG es muy barata de hacer con hardware y que soporta casi cualquier tamaño del vídeo que se desea trasmitir. Esto significa que se puede usar MJPEG para imágenes en tamaño desde Sub-QCIF hasta las de tamaño completo en HDTV 1080i (1920x1080) y superiores. El MJPEG no se recomienda en ambientes con ancho de banda limitado, debido a su elevado consumo del mismo. [VIDEOCONF] 2.1.3.2.12. WMV Formato de vídeo de Microsoft. Versiones: Windows Media Video v7 (WMV1), v8 (WMV2) y v9 (WMV3). Posee un sistema de licencias para proteger los contenidos. Actualmente han publicado una nueva versión de este codec, el WMV de alta definición (WMV-HD). [MICROSOFT] 2.1.3.2.13. RealVideo 39 2. Estado del arte Formatos de vídeo de RealNetworks. Estos codec son el RealVideo 1.0, 2.0, 3.0 (para RealPlayer 8), 4.0 (RealPlayer 9). [REALNETWORKS] 2.1.3.3. Codecs de audio 2.1.3.3.1. MPEG audio La familia de codecs de audio desarrollado por el grupo MPEG son los estándares MPEG-1, y hay 3 niveles de compresión (layers): [MPEG-GROUP] • MPEG-1 layer 1: MP1. • MPEG-1 layer 2: MP2. • MPEG-1 layer 3: MP3. El MP3 se caracteriza por tener la razón de compresión más alta, que varía entre 1:10 y 1:12 y la velocidad más baja 112-128 Kbps. MPEG-1 Compresión Velocidad Layer 1 1:4 384 Kbps Layer 2 1:6 - 1:8 256-192 Kbps Layer 3 1:10 - 1:12 128-112 Kbps Tabla 2.6. Formatos VCD, SVCD y derivados El MP3 es el más común de los tres esquemas de codificación para la compresión de señales de audio. Usa codificación perceptual de audio y compresión psicoacústica para eliminar toda la información superflua (más específicamente, las partes redundantes e irrelevantes de una señal de sonido (componentes que el oído humano no puede escuchar). También agrega un MDCT (Modified Discrete Cosine Transform) que implementa un banco de filtros, aumentando la resolución de frecuencia 18 veces más que en el layer 2. El resultado en términos prácticos es que el layer 3 comprime el dato original de audio de un CD (de unos 1411.2 kbits por segundo de música estéreo) por un factor de 12 (o sea uno 112-128 kbps) sin sacrificar calidad de sonido. Dado que los archivos MP3 son más pequeños, pueden transferirse fácil y rápidamente a través de Internet. Debido a esto el MP3 se ha convertido en un formato muy extendido, para streaming de audio, compresión de audio de alta calidad, y demás, gracias a la posibilidad de ajustar la calidad de la compresión, proporcional al tamaño por segundo (bitrate), y por tanto el tamaño final del archivo, que podía llegar a ocupar 12 e incluso 15 veces menos que el archivo original sin comprimir. La evolución de MP3 es MP3pro. La calidad mejora muchísimo gracias a la incorporación de las frecuencias altas a través de una nueva tecnología que han llamado Spectral Band Replication (SBR). Esto hace que sea beneficioso tanto para la emisión en streaming como para ser utilizado con los reproductores, donde el tamaño es muy importante. [MP3PRO] 40 2. Estado del arte Figura 2.12. MP3 y MP3Pro 2.1.3.3.2. Vorbis Formato de audio de propósito general comprimido con pérdida. Forma parte del Proyecto OGG, con lo que es totalmente abierto, no-propietario, libre de patentes y de royalties, y es adecuado para audio de media a alta calidad (8kHz-48.0kHz 16+ bit, polifónico) a bitrates fijos y variables, de 16 a 128 kbps/canal. Diseñado para streaming Ofrece una calidad bastante superior a MP3, WMA, o RealAudio ocupando el mismo tamaño. También es superior a la de los codecs comerciales de última generación, como AAC y MP3Pro, según una Prueba de audición a ciegas con más de 5000 participantes con la ventaja añadida de que OGG-Vorbis es libre. [XIPH] [VORBIS] [OGG] 2.1.3.3.3. FLAC FLAC (Free Lossless Audio Codec) es un codec de audio sin pérdidas y abierto. A diferencia de otros codec como MP3 y AAC, no elimina información del flujo de audio. El 29 de enero de 2003, Xiph.org anunció la incorporación de FLAC al proyecto OGG, junto a VORBIS, Theora y Speex. [FLAC] 2.1.3.3.4. Speex Speex es el codec de audio dentro del proyecto OGG que se encarga de la codificación del habla. Además, está adaptado a las aplicaciones Internet y proporciona nuevas características que no están presentes en la mayoría de codecs de audio. [SPEEX] 41 2. Estado del arte 2.1.3.3.5. AC3 AC3 (Audio Coding 3) es un sinónimo de Dolby Digital [DOLBY], que una tecnología avanzada de compresión que permite codificar 6 canales separados de audio a tasas de bits de 320kbit/s, o mas. Es el formato en el que vienen los tracks Dolby Digital de los DVD. Pueden ser 2.0 o 5.1. [DOOM9] 2.1.3.3.6. AAC AAC (Advanced Audio Coding) es un codec que usa dos estrategias para reducir considerablemente el tamaño de los ficheros manteniendo la calidad del audio. La primera de esas estrategias parte de la base de que las componentes del sonido irrelevantes a nivel de percepción pueden ser eliminadas. Además, las redundancias en el audio codificado son eliminadas. AAC usa un banco de filtros con una resolución de frecuencias finas que proporciona una gran compresión de la señal. AAC también utiliza una serie de nuevas herramientas como formación de ruido temporal (temporal noise shaping), predicción lineal adaptable hacia atrás, técnicas de codificación joint stereo (unión del estéreo) y código Huffman, cada uno de los cuales proporciona una capacidad de compresión adicional. [AAC] 2.1.3.3.7. WMA WMA (Windows Media Audio) es un formato de compresión de audio con pérdida propiedad de Microsoft. Microsoft usa como estratégica comercial la inclusión de soporte en el reproductor Windows Media Player, incluido en su popular sistema operativo Windows. A diferencia del MP3, el formato posee una infraestructura para proteger el Copyright y así hacer más difícil el tráfico ilegal de música. [MICROSOFT] 2.1.3.3.8. RealAudio El audio para los archivos de RealMedia usa la siguiente familia de codecs propietarios: [REALAUDIO] • • • • • • • lpcJ: Codec predictivo lineal a 8kbps. 28_8: G.728, conocido como RealAudio 2.0. dnet: Dolby AC3 a bajo bitrate. Conocido como RealAudio 3.0. sipr: Codec de voz Sipro. cook: RealAudio G2 Codec. atrc: Sony ATRAC3. ralf: Formato RealAudio sin pérdidas. 2.1.4. Streaming El streaming es una tecnología que permite la recepción instantánea, sin esperas, de información que fluye desde un servidor. Los contenidos multimedia son entregados 42 2. Estado del arte en un flujo continuo de manera que no haya que esperar varios minutos o más para descargarlos. Antes de que la primera instancia de tecnología streaming apareciera en abril de 1995 (con el lanzamiento de real audio 1.0), la reproducción de contenido multimedia a través de Internet necesariamente implicaba tener que descargar completamente el archivo contenedor al disco duro local. Sin embargo, con la tecnología del streaming un archivo puede ser descargado y accedido al mismo tiempo, con lo que el tiempo de espera es mínimo. El streaming funciona de la siguiente manera. El cliente de streaming conecta con el servidor y le realiza una petición de un fichero. El servidor le empieza a mandar el fichero, y el cliente comienza a recibir el fichero, construyendo un buffer donde empieza a guardar la información. Cuando se ha llenado el buffer con una pequeña parte del archivo, el cliente lo empieza a mostrar y a la vez continúa con la descarga. El sistema está sincronizado para que el archivo se pueda ver mientras que el archivo se descarga, de modo que cuando el archivo acaba de descargarse el fichero también ha acabado de visualizarse. Si en algún momento la conexión sufre descensos de velocidad se utiliza la información que hay en el buffer, de modo que se puede aguantar un poco ese descenso. Si la comunicación se corta demasiado tiempo, el buffer se vacía y la ejecución el archivo se cortaría también hasta que se restaurase la señal. Los clientes de streaming más populares son: • Real Player. [REALNETWORKS] • Windows Media Player. [WINDOWS] • Quicktime Player. [QUICKTIME] UDP y RTSP son los protocolos empleados por algunas implementaciones de streaming ya que las entregas de paquetes IP de servidor a cliente son más rápidas que las que se obtiene con TCP y HTTP. Esta eficiencia es alcanzada por una modalidad que favorece el flujo continuo de paquetes IP. Cuando TCP y HTTP sufren un error de transmisión, siguen intentando transmitir los paquetes IP perdidos hasta conseguir confirmación de que la información arribó en su totalidad; sin embargo, UDP continúa mandando los paquetes IP sin tomar en cuenta interrupciones, ya que en una aplicación multimedia una leve pérdida de datos no es significativa. 2.1.4.1. RTSP El protocolo RTSP (Real Time Streaming Protocol) permite realizar un control remoto de sesión de transmisión multimedia. Concretamente, permite: [RTSP] • Localizar un determinado contenido multimedia de un servidor. • Invitar a un servidor multimedia a una multiconferencia. • Grabar una multiconferencia. Es un protocolo basado en texto, independiente del protocolo de transporte. Soporta cualquier descripción de la sesión (por ejemplo, SDP). Permite utilizar unicast y multicast. Los métodos principales RTSP son: 43 2. Estado del arte • • • • SETUP: El servidor asigna recursos y establece una sesión RTSP. PLAY: Empieza la transmisión de datos. PAUSE: Detiene temporalmente la transmisión. TEARDOWN: Libera los recursos y termina la sesión RTSP. RTSP tiene tres modos de operación con relación a las comunicaciones: • Conexiones TCP persistentes para varias solicitudes/respuesta. • Una conexión TCP para cada solicitud/respuesta • Sin conexión, sobre UDP. 2.2. El hogar digital Es una tendencia consolidada el aumento del equipamiento electrónico de los hogares: informático, audiovisual, de comunicaciones, domótico, etc. Hasta el momento dichos dispositivos han permanecido aislados y realizando las labores específicas que tenían asignadas. Ahora se impone la necesidad de conectar estos dispositivos electrónicos entre sí (Home Networking) y con el exterior (Internet) para poder disfrutar de servicios cada vez más avanzados. De hecho, la domótica, si bien es una disciplina que ha crecido de forma lenta desde los años 90, ha adquirido un nuevo impulso al unir las posibilidades de la comunicación entre los distintos dispositivos de la vivienda con las comunicaciones de ésta con el exterior en lo que ya se llama "Teledomótica". El Hogar Digital es la materialización de esta idea de convergencia de servicios: de entretenimiento, de comunicaciones, de gestión digital del hogar, y de infraestructuras y equipamiento. [Domotica.net] 2.2.1. La Pasarela Residencial La Pasarela Residencial (SG, Service Gateway) es un dispositivo que surge de la necesidad de interconectar las diferentes opciones de redes de acceso con los distintos equipos y electrodomésticos de una vivienda. Igualmente, sirve de punto de acceso para las comunicaciones y plataforma de soporte de aplicaciones típicas del hogar (tales como control domótico, seguridad, vigilancia, control energético, entretenimiento, e-comercio, teleasistencia, etc). [Domotica.net], [Domótica Viva] 2.2.2. Iniciativa OSGi El Open Services Gateway Initiative (OSGi) es un grupo de trabajo que surgió en Marzo de 1999, cuyo principal impulsor es Sun Microsystems. El resto de los miembros fundadores son: Alcatel, Cable and Wireless, Electricité de France, Enron Communications, Ericsson, IBM, Liberate Technologies, Lucent Technologies, Motorola, Nortel Networks, Oracle, Philips Electronics, Sybase and Toshiba. Actualmente ya tiene socios españoles como Unión Fenosa y Telefónica I+D. [OSGi] OSGi trabaja en la propuesta de un marco de trabajo de plataforma abierta de desarrollo de servicios domóticos, automovilísticos e industriales. De esta forma, Proveedores de Internet (ISP), operadores de red y fabricantes de equipos pueden 44 2. Estado del arte ofrecer una amplia gama de servicios a los usuarios finales utilizando la misma pasarela. OSGi también se centra en la definición de las APIs que permitan integrar la plataforma. El núcleo de las especificaciones consiste en una colección de APIs que definan la pasarela de servicios. Siempre que sea posible se confiará en los estándares existentes de Java, tales como Jini o JDBC. Como la especificación OSGi está orientada a la capa de aplicación se complementa con cualquier iniciativa de las capas inferiores, en las que se incluyen los protocolos de comunicación y redes domóticas existentes. Tales como Bluetooth, CAL, CEBus, HAVi, Home API, HomePNA, HomePNP, HomeRF y VESA. Las características fundamentales de OSGi son las siguientes: • Independencia de la plataforma: Arquitectura basada en Java e interfaces de aplicaciones en APIs. • Independencia de Suministrador: Permite soportar aplicaciones desarrolladas por distintos fabricantes y provisionadas por distintos proveedores, de forma transparente. • Escalable: No son necesarios cambios en plataforma si evolucionan las aplicaciones. Los operadores de las pasarelas y los propios usuarios pueden ampliar las capacidades de estas con nuevos servicios aportados por terceras empresas en cualquier momento. • Coexistencias con múltiples soluciones de conectividad: Compatibilidad con distintas soluciones de networking y dispositivos. La arquitectura de OSGi tiene dos elementos fundamentales: [MARPKRI 2001] • Marco de Servicio (Service Framework): Plataforma de ejecución de aplicaciones basada en Java. • Plataforma de Servicio (Service Plataform): Conjunto de servicios (bundles) que proporcionan una determinada funcionalidad a otros servicios o directamente al usuario final y que se ejecutan sobre el Framework. Este elemento además será el encargado de permitir la interacción entre dispositivos o redes de dispositivos que empleen distintas tecnologías para comunicarse. Las bundles están escritas en lenguaje Java y son descargables como archivos JAR (Java Archive). Figura 2.13. Arquitectura OSGi 45 2. Estado del arte La arquitectura OSGi a nivel SW se puede ver en las siguientes figuras: Figuras 2.14 y 2.15. Arquitectura SW OSGi 2.2.2.1. Especificaciones OSGi La primera especificación se llamó OSGi Service Gateway 1.0. Fue publicada en mayo de 2000. Esta especificación define una plataforma abierta, y con una arquitectura que permite a los agentes implicados (proveedores de servicio, desarrolladores de SW y fabricantes de equipos) manejar múltiples servicios en una pasarela residencial (que puedes ser un STB, un módem xDSL, un cable-módem, o un PC dedicado a pasarela residencial). La especificación consiste en un conjunto de APIs Java y una plataforma de servicio (Service Framework) que proporciona un entorno de ejecución para servicios electrónicos descargables conocidos como bundles. Esta especificación incluye tres servicios básicos: servicio de login (log), un servidor web (HTTP), y el acceso a dispositivos. En octubre de 2000 se lanza la segunda especificación, llamada OSGi Service Plataform 2.0. Con esta versión se mejoraron y ampliaron las APIs existentes. Además se añadieron nuevos servicios: administración de usuarios, administración de configuración y gestión de bundles. Además se simplificó el framework, con nuevas características para simplificar la programación de bundles, seguridad y un sistema para controlar las versiones de las bundles. En marzo de 2003 la alianza OSGi publicó la tercera versión de la especificación OSGi (OSGi service plataform, Release 3). En esta nueva versión se incluye procesamiento de XML (XML parsing), servicios de localización, y driver JINI y UPnP. [OSGi] 2.2.3. Implementaciones de la plataforma OSGi La especificación de la plataforma de servicios OSGi está principalmente enfocada a su despliegue en STBs, pasarelas residenciales, cablemódems, aparatos de electrónica de consumo, PCs, computadoras industriales y automóviles [OSGi]. Actualmente se pueden encontrar disponibles las siguientes implementaciones de OSGi: • Propietarias (requiere el pago de licencias por su uso): 46 2. Estado del arte o Java Embedded Server (JES) de Sun Microsystems [SUN], a partir de su versión 2.0 es conforme con la especificación OSGi. JES es un entorno de trabajo que permite el desarrollo, despliegue e instalación de aplicaciones y servicios en dispositivos empotrados de manera remota sobre la red. [JES] o Service Management Framework (SMF) de IBM [IBM] implementa la especificación OSGi R2 (release 2), aunque está diseñado para ser totalmente compatible con la especificación OSGi R3. SMF es parte integral de la plataforma software empotrada IBM WebSphere Everyplace, la cual proporciona una solución completa y escalable para el despliegue, mantenimiento y eliminación de aplicaciones y elementos de tiempo de ejecución sobre millones de dispositivos. [SMF] o mBedded Server de ProSyst, actualmente en su versión 5.2, implementa la especificación OSGi R3, aunque todavía se encuentra en proceso de certificación por la alianza OSGi, de la cual ProSyst es miembro. Existen tres versiones de mBedded Server: mBedded Server Smart Home Edition, mBedded Server Telematics Edition y mBedded Server Mobile Edition, cada una de las cuales está orientada respectivamente a pasarelas domésticas, automóviles y dispositivos móviles. [PROSYST] o Espial DeviceTop 3.1 de Espial. Es un entorno gráfico que implementa la especificación OSGi R2, orientada a dispositivos empotrados de recursos hardware limitados (cualquiera de los llamados smart devices). [DEVICETOP] o aveLink Embedded Gateway de Atinav implementa la especificación OSGi R3, aunque todavía se encuentra en proceso de certificación, orientada tanto a pasarelas residenciales como a automóviles, e incluso a dispositivos móviles. [AVELINK] o Matilda 1.0 de Acunia implementa OSGi R2, aunque su versión 2.0 será certificada con el estándar OSGi R3. Por otra parte, Acunia ha creado OTF (Open Telematics Framework), una herramienta para la gestión remota de aplicaciones en ejecución en gran número de terminales distribuidos (clientes OTF) controlados por un servidor central (servidor de negocio OTF). OTF emplea el estándar OSGi en tanto que permite a terminales OSGi individuales conectarse con el servidor de gestión OTF (servidor de negocio OTF), convirtiéndose así en una pasarela para servicios remotamente gestionados. [ACUNIA] o Gatespace Distributed Service Platform (GDSP) de la compañía sueca Gatespace AB, implementa OSGi R2 además de extensiones propias añadidas por ella. Esta implementación está orientada a pasarelas de servicios en vehículos. En el momento de la realización de este estudio sobre el estado del arte, esta implementación todavía se encontraba disponible, sin embargo, muy poco tiempo después esta compañía se reestructuró, dando como resultado la empresa Gatespace Telematics AB y la liberación del código de la plataforma GDSP en un nuevo producto libre llamado Knopflerfish. • De código abierto (se distribuye públicamente su código fuente y forma binaria): o Java Embedded Framework FREE (JEFFREE) es una joven implementación pública y de código abierto de la especificación OSGi R2. JEFFREE se distribuye bajo licencia LGPL (GNU Lesser General Public License). [JEFFREE] o Open Service Container Architecture (OSCAR) [28] es una implementación de código abierto de la especificación OSGi que pretende cubrir tanto la R2 como la R3. Actualmente este estable entorno de trabajo se encuentra en su versión 0.9.4a que cumple casi totalmente las especificaciones OSGi R2 y R3. OSCAR se distribuye bajo una licencia Apache modificada. [OSCAR] o ServiceTango es una implementación de OSGi R1. [SERVICETANGO] o Knopflerfish es una implementación abierta de la especificación OSGi R2 que proviene del anteriormente conocido como Gatespace Distributed Service Platform (GDSP) de Gatespace, compañía que decidió liberar su código a finales 47 2. Estado del arte del año 2003. Knopflerfish OSGi es un entorno de trabajo completo y totalmente probado que destaca por su escritorio gráfico, el cual permite la gestión de las aplicaciones de una forma más visual e intuitiva. El software, actualmente en su versión 1.0.2, se distribuye bajo una variante de licencia BSD en dos formas a elegir: el entorno de trabajo completo, que incluye todo el software, código fuente y documentación; o el núcleo del entorno, y carga las aplicaciones (bundles) remotamente desde la web. [KNOPFLERFISH] 2.3. El software libre Software Libre se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. De modo más preciso, se refiere a cuatro libertades de los usuarios del software: • Libertad 0: La libertad de usar el programa, con cualquier propósito. • Libertad 1: La libertad de estudiar cómo funciona el programa, y adaptarlo a tus necesidades. El acceso al código fuente es una condición previa para esto. • Libertad 2: La libertad de distribuir copias, con lo que puedes ayudar al resto de personas. • Libertad 3: La libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie. El acceso al código fuente es un requisito previo para esto. Un programa es software libre si los usuarios tienen todas estas libertades. Así pues, deberías tener la libertad de distribuir copias, sea con o sin modificaciones, sea gratis o cobrando una cantidad por la distribución, a cualquiera y a cualquier lugar. El ser libre de hacer esto significa (entre otras cosas) que no tienes que pedir o pagar permisos. También se debería tener la libertad de hacer modificaciones y utilizarlas de manera privada en tu trabajo u ocio, sin ni siquiera tener que anunciar que dichas modificaciones existen. Si publicas tus cambios, no tienes por qué avisar a nadie en particular, ni de ninguna manera en particular. La libertad para usar un programa significa la libertad para cualquier persona u organización de usarlo en cualquier tipo de sistema informático, para cualquier clase de trabajo, y sin tener obligación de comunicárselo al desarrollador o a alguna otra entidad específica. La libertad de distribuir copias debe incluir tanto las formas binarias o ejecutables del programa como su código fuente, sean versiones modificadas o sin modificar (distribuir programas de modo ejecutable es necesario para que los sistemas operativos libres sean fáciles de instalar). Está bien si no hay manera de producir un binario o ejecutable de un programa concreto (ya que algunos lenguajes no tienen esta capacidad), pero debes tener la libertad de distribuir estos formatos si encontraras o desarrollaras la manera de crearlos. Para que las libertades de hacer modificaciones y de publicar versiones mejoradas tengan sentido, debes tener acceso al código fuente del programa. Por lo tanto, la posibilidad de acceder al código fuente es una condición necesaria para el software libre. 48 2. Estado del arte Para que estas libertades sean reales, deben ser irrevocables mientras no se haga nada incorrecto; si el desarrollador del software tiene el poder de revocar la licencia aunque no le hayas dado motivos, el software no es libre. Son aceptables, sin embargo, ciertos tipos de reglas sobre la manera de distribuir software libre, mientras no entren en conflicto con las libertades centrales. Por ejemplo, copyleft es la regla que implica que, cuando se redistribuya el programa, no se pueden agregar restricciones para denegar a otras personas las libertades centrales. Esta regla no entra en conflicto con las libertades centrales, sino que más bien las protege. 'Software libre' no significa 'no comercial'. Un programa libre debe estar disponible para uso comercial, desarrollo comercial y distribución comercial. El desarrollo comercial del software libre ha dejado de ser inusual; el software comercial libre es muy importante. Pero el software libre sin ‘copyleft' también existe. Creemos que hay razones importantes por las que es mejor usar 'copyleft', pero si tus programas son software libre sin ser 'copyleft', se pueden utilizar de todos modos. [HISPALINUX] 2.3.1. GNU/Linux GNU/Linux es la denominación defendida por Richard Stallman y otros para el sistema operativo que utiliza el kernel Linux en conjunto con las aplicaciones de sistema creadas por el proyecto GNU. Comúnmente este sistema operativo es denominado simplemente Linux. Desde 1984, Richard Stallman y voluntarios están intentando crear un sistema operativo libre con un funcionamiento similar al UNIX, recreando todos los componentes necesarios para tener un sistema operativo funcional que se convertiría en el sistema operativo GNU. En el comienzo de los años 1990, después de seis años, GNU tenía muchas herramientas importantes listas, como compiladores, depuradores, intérpretes de comando etc, excepto por el componente central: el núcleo. Con el surgimiento del kernel Linux, esta laguna fue llenada y surgió el sistema operativo con el kernel Linux en conjunto con las herramientas GNU. De esta manera, Stallman juzga que este sistema operativo es una "versión modificada" del sistema GNU y por lo tanto debe tener la denominación GNU/Linux. Esta denominación resolvería la confusión entre el núcleo y el sistema operativo completo a que puede llevar, y de hecho ha llevado, la denominación Linux en solitario. Stallman también espera que con el aporte del nombre GNU, se dé al proyecto GNU que él encabeza el reconocimiento que merece por haber creado las aplicaciones de sistema imprescindibles para ser un sistema operativo compatible con UNIX. [GNU] El núcleo (kernel) del sistema (Linux) sigue en continuo desarrollo bajo la coordinación de Linus Torvalds, la persona de la que partió la idea de este proyecto, en 1991. Linus, por aquel entonces un estudiante de informática de la Universidad de Helsinki, empezó (como proyecto de fin de carrera y sin poder imaginar en lo que se llegaría convertir) a programar las primeras líneas de código de este sistema operativo llamado LINUX. El origen de Linux estuvo inspirado en MINIX, un pequeño sistema Unix desarrollado por Andy Tanenbaum. Las primeras discusiones sobre Linux fueron en el grupo de 49 2. Estado del arte noticias comp.os.minix, en estas discusiones se hablaba sobre todo del desarrollo de un pequeño sistema Unix para usuarios de Minix que querían más. Linus nunca anunció la versión 0.01 de Linux (agosto 1991), esta versión no era ni siquiera ejecutable, solamente incluía los principios del núcleo del sistema, estaba escrita en lenguaje ensamblador y asumía que uno tenía acceso a un sistema Minix para su compilación. El 5 de octubre de 1991, Linus anunció la primera versión "oficial" de Linux, (versión 0.02). Con esta versión Linus pudo ejecutar Bash (GNU Bourne Again Shell) y gcc (el compilador GNU de C) pero no mucho más. En este estado de desarrollo ni se pensaba en los términos soporte, documentación, distribución. Después de la versión 0.03, Linus saltó en la numeración hasta la 0.10. Más y más programadores a lo largo y ancho de Internet empezaron a trabajar en el proyecto y después de sucesivas revisiones, Linus incrementó el número de versión hasta la 0.95 (Marzo 1992). Más de un año después (diciembre 1993) el núcleo del sistema estaba en la versión 0.99 y la versión 1.0 llego el 14 de marzo de 1994. La serie actual del núcleo es la 2.6.x y sigue avanzando día a día con la meta de perfeccionar y mejorar el sistema. Aunque se podrían hacer un sistema Linux desde el principio, lo más normal es obtener una distribución ya empaquetada y que suele contener el propio sistema operativo más centenares de programas, ya listos para su uso. Existen cientos de distribuciones Linux en el mundo; la mayoría se pueden obtener a través de Internet, aunque también se pueden comprar algunas de ellas. Las distribuciones más conocidas son: • Debian GNU/Linux: Es una distribución Linux que basa sus principios y fin en el software libre. Creado por Debian Project el año 1993, la organización responsable de la creación y mantenimiento de la misma distribución, centrado en GNU/Linux y utilidades GNU. También mantienen y desarrollan otros sistemas operativos GNU basados en los núcleos the Hurd, llamado Debian GNU/Hurd, todavía en estado embrionario y NetBSD, llamado Debian GNU/NetBSD. [DEBIAN] • Slackware: Es una distribución de un completo sistema multitarea de 32-bits. Desarrollada inicialmente por Linus Torvalds. [SLACKWARE] • SUSE LINUX: SuSE es el acrónimo del alemán "Software- und Systementwicklung" el cual formaba parte del nombre original de la compañía y que se podría traducir "desarrollo de software y sistemas". Entre las principales virtudes de esta distribución se encuentra el que sea una de las más sencillas de instalar y administrar, ya que cuenta con varios asistentes gráficos para completar diversas tareas. [SUSE] • Red Hat Linux: Es una distribución Linux creada por Red Hat. Ha sido muy popular en entornos de usuarios hogareños. Desde el 2003, Red Hat ha desplazado su enfoque hacia el mercado de los negocios con la distribución Red Hat Enterprise Linux. Red Hat Linux 9, la versión final, llegó oficialmente al final de su vida útil el pasado 30 de abril de 2004, aunque el proyecto Fedora Legacy continua publicando actualizaciones. [REDHAT] • Fedora: El proyecto Fedora, es la continuación del proyecto de Red Hat mantenido por la comunidad Linux y esponsorizado por Red Hat. Esta distribución solo contiene open source. Es una distribución no comercial de GNU/Linux, al estilo de Slackware o Debian. [FEDORA] 50 2. Estado del arte • Mandriva Linux (antes Mandrake Linux): Es una distribución Linux aparecida en julio de 1998 propiedad de Mandriva, enfocada a principiantes o usuarios medios. [MANDRIVA] • Knoppix: Es una distribución de Linux basada en Debian y utilizando KDE. Está desarrollada por el consultor de GNU/Linux Klaus Knopper. A diferencia de la mayoría de las distribuciones Linux, no requiere una instalación en el disco duro; el sistema puede iniciarse desde un simple CD de 700 MB. Además, Knoppix reconoce automáticamente la mayoría del hardware del ordenador soportado por Linux cuando se inicia. Se caracteriza por ser totalmente libre y con programas como GIMP, OpenOffice y KDE. [KNOPPIX] 2.3.2. Licencias libres En el mundo del software libre existen diversos tipos de licencias bajo las cuales se amparan las producciones realizadas por los desarrolladores y/o usuarios: • GPL: GNU General Public License. Es la más conocida, cubre la mayor parte del software de la Free Software Foundation, y otros muchos programas. • FDL: GNU Free Documentation License (FSF). Cubre manuales y documentación para el software de la Free Software Foundation, con posibilidades en otros campos. • LGPL: GNU Lesser General Publication License. Se aplica a algunos paquetes de software diseñados específicamente (típicamente librerías) de la Free Software Foundation y de otros autores que deciden usarla. • Creative Commons: está inspirada en la licencia GPL de la Free Software Foundation. La idea principal es posibilitar un modelo legal y ayudado de herramientas informáticas para así facilitar la distribución y el uso de contenidos para el dominio público. Ofrece una serie de licencias, cada una con diferentes configuraciones o principios como el derecho del autor original a dar libertad para citar su obra, reproducirla, crear obras derivadas, ofrecerlo públicamente y con diferentes restricciones como no permitir el uso comercial o respetar la autoría original. [CREATIVECOMMONS] 2.3.3. Java y software libre Un lenguaje posible para la realización de este proyecto es Java. Ante esto, surge la siguiente cuestión: ¿Es Java libre? La respuesta a esta pregunta no es sencilla. [JAVALIBRE] Para responder a esta pregunta, primero hay que plantearse otra pregunta: ¿Qué es Java? La respuesta a esta pregunta no es única, ya que Java se puede a referir a: • • • • Un lenguaje de programación. Una especificación de una máquina virtual. Una especificación de un formato binario (código de bytes o bytecodes). Un conjunto de clases y librerías que nos permiten la realización de programas mediante un dialecto determinado. Según a que concepto se esté refiriendo al hablar de Java, la respuesta a la pregunta formulada anteriormente se verá alterada. Para cualquiera de las tres primeras acepciones la respuesta es SI, Java es libre. Las especificaciones son públicas y están disponibles para todo el mundo, por lo que cualquiera puede descargárselas y crear su 51 2. Estado del arte propia implementación del lenguaje, su propia máquina virtual o su propio formato de código, y además cualquiera puede distribuir estas creaciones libremente. Si por el contrario, creemos que Java es un conjunto de librerías y clases, es decir, un kit de desarrollo, en este caso su libertad depende de quién haya creado dicho kit de desarrollo: • Utilizar el JDK de SUN Microsystems: El JDK [JDK] (Java Developer's Kit ) es el kit de desarrollo oficial de desarrollo con Java ya que es SUN Microsystems [SUN] la empresa que lo distribuye. Este SDK no es libre. Su código fuente se distribuye bajo la licencia SCSL, una licencia que es muy restrictiva. Esta licencia permite ver el código fuente pero no la realización de modificación alguna. Tampoco se permite redistribuir el kit de desarrollo ni versiones modificadas del mismo. • Utilizar un kit de desarrollo de algún licenciatario de SUN Microsystems: Otra opción que se plantea es utilizar un SDK proporcionado por algún licenciatario de SUN Microsystems, por ejemplo el de IBM. Estos SDKs tampoco son libres, ya que normalmente lo que se licencia es el código fuente. A pesar de que el licenciatario obtiene permisos para modificar el software original y distribuirlo, no se produce lo mismo para los usuarios de éstos nuevos SDKs. • Utilizar una implementación independiente: Como se ha visto anteriormente, Java no sólo es un SDK sino que también es una especificación de un lenguaje, máquina virtual y de un formato de código de bytes. Estas especificaciones son públicas y cualquiera puede implementarlas desde cero, razón por la que existen numerosas implementaciones libres. El único requisito para dichas implementaciones es que no pueden llamarse Java (palabra propiedad de SUN Microsystems). Estas implementaciones, incluso pueden certificarse como compatibles con Java aunque esto requeriría ya el pasar a ser licenciatario de SUN Microsystems. Ejemplos de este tipo de implementaciones son GCJ o Jikes. 2.3.4. Eclipse Hoy día, para el desarrollo de software la opción más ventajosa es el empleo en un entorno de desarrollo integrado (IDE, Integrated Development Environments). Un IDE de software libre con muchas posibilidades es Eclipse. 2.3.4.1. IDEs Los desarrolladores de software se dividen en dos tipos: los que usan entornos de desarrollo integrado o IDEs y los que no. Estos últimos prefieren un editor de texto (como Emacs o el Bloc de notas), un compilador y un depurador. Los pertenecientes al primer tipo, sin embargo, prefieren usar IDEs para ayudarles a la generación del código y a la construcción de proyectos. Los IDEs, por supuesto, también tienen sus desventajas: en comparación con el clásico triunvirato editor de texto-compilador-depurador consumen muchísimos más recursos, tienden a ser lentos (particularmente los escritos en Java) y su manejo requiere un cierto aprendizaje que se tira a la papelera cuando se pasa a otro IDE, debido a la heterogeneidad de los IDEs que proliferan en el mercado. La irrupción de Eclipse, un nuevo jugador en el mercado de IDEs para Java apadrinado por IBM y respaldado por un poderoso consorcio de empresas, supone un firme intento de homogeneizar el mercado de IDEs (no sólo de Java) y de establecer 52 2. Estado del arte un estándar para las herramientas de desarrollo de software. Eclipse no es un IDE más a añadir a la lista: el objetivo de IBM es crear una plataforma de desarrollo modular que cualquier herramienta de desarrollo pueda usar con cualquier lenguaje de programación. 2.3.4.2. Terminología eclipse Según la documentación oficial de Eclipse [ECLIPSE], Eclipse es un proyecto desarrollo de software de código fuente abierto cuyo objetivo es la construcción herramientas integradas para el desarrollo de aplicaciones. La palabra "Eclipse" utiliza en dicha documentación para referirse al proyecto en conjunto de creación herramientas integradas para desarrollar aplicaciones. Este proyecto global compone de tres subproyectos: de de se de se • Proyecto Eclipse. • Proyecto Herramientas de Eclipse. • Proyecto Tecnología Eclipse. El proyecto Eclipse es el subproyecto de Eclipse dedicado a proporcionar una plataforma base común para el desarrollo de herramientas integradas. Este proyecto, a su vez, se subdivide en otros tres, dedicados al desarrollo y mejora de la plataforma Eclipse (núcleo básico o kernel de Eclipse), del JDT (Java Development Tools) y del PDE (Plugin Development Kit). El término "Eclipse SDK (Standard Development Kit)" alude al conjunto de la plataforma Eclipse, el JDT y el PDE; por tanto, puede afirmarse que el proyecto Eclipse se dedica, en conjunto, al desarrollo y mejora del SDK de Eclipse. Todos estos acrónimos se irán explicando a lo largo del artículo. 2.3.4.3. Plataforma Eclipse La Plataforma Eclipse es una plataforma universal para integrar herramientas de desarrollo con una arquitectura abierta, basada en plugins. Plataforma universal, pues emplea una estructura abierta de plugins que permite expandir las capacidades de la plataforma base hasta el infinito. Arquitectura abierta, en definitiva, porque es un producto de código fuente abierto (open source). [ECLIPSEARCH] 53 3. Análisis de requisitos 3. Análisis de requisitos Una vez concluido el proceso de estudio del estado del arte, se disponen de los conocimientos teóricos para sentar las bases del desarrollo del presente proyecto. Ahora es necesario definir formalmente los requisitos funcionales y no funcionales del mismo. Con el compendio de información formado por el estado del arte y el análisis de requisitos detallado a continuación, se puede definir exactamente que el trabajo que hay que desarrollar. 3.1. Visión de sistema El escenario inicial parte de una pasarela residencial que conecta una red domestica al exterior a través de Internet. La pasarela residencial ofrecerá al usuario el servicio de reproducción de vídeo/audio personal e interactivo. Este servicio es ofrecido a través de Internet conectándose a servidores específicos: • Servidor de Perfiles: Se encarga de autenticar usuarios para permitir el acceso a determinados contenidos. • Servidor de Contenidos: Ficheros multimedia de audio/vídeo. Enviados a través de Internet mediante streaming. • Servidor de Aplicaciones: Existe la posibilidad de ligar contenidos multimedia a aplicaciones interactivas. En estos se servidor se alojan las aplicaciones que instrumentan dicha interactividad. Figura 3.1. Visión inicial del sistema 54 3. Análisis de requisitos 3.2. Requisitos del sistema Partiendo de la visión presentada en el apartado anterior, a continuación se detallan los requisitos del sistema. Los requisitos pueden ser de dos tipos: • Requisitos funcionales: Funciones del sistema. • Requisitos no funcionales: Limitaciones y condicionantes de funcionamiento del sistema, así como funciones extras del sistema. Además, para cada uno de los requisitos (funcionales y no funcionales) se dará su prioridad: • Obligatorio: Características imprescindibles del sistema. La realización de todos los requisitos obligatorios es condición necesaria para que se pueda dar por concluido el desarrollo del presente proyecto. • Opcional: Características deseables, aunque no imprescindibles. 3.2.1. Requisitos funcionales RF1. Reproducción multimedia. El sistema desarrollado debe ser capaz de reproducir archivos de audio/vídeo. Este requisito se desdobla claramente en dos: RF1.1. Reproducción de ficheros en local. Cuando los ficheros multimedia están almacenados en la misma máquina en la que está siendo ejecutado el sistema. RF1.2. Reproducción de streaming. Cuando los ficheros multimedia están almacenados en otras máquinas, pero a las que se puede acceder mediante una conexión a Internet por la tecnología de streaming. Este requisito a su vez se desdobla en otros dos: RF1.2.1. Reproducción multimedia bajo demanda. El usuario es el que decide en que momento desea comenzar la reproducción. RF1.2.2. Reproducción multimedia por difusión. La difusión sigue el modelo clásico de la TV: en un momento dado se comienza la emisión, y el receptor decide si desea verlo o no Prioridad: OBLIGATORIO (de todos los apartados y subapartados del RF1) RF2. Ejecución de canales interactivos. Se introduce aquí un concepto clave en este proyecto: el canal. Un canal en este sistema es la unión de dos conceptos: • Un contenido multimedia. • Una o más aplicaciones interactivas unidas a este contenido y sincronizadas con él. El sistema desarrollado debe ser capaz de reproducir estos canales interactivos propuestos. Prioridad: OBLIGATORIO. 55 3. Análisis de requisitos RF3. Despliegue de canales. El sistema debe ser capaz de presentar al usuario canales interactivos para que éste los ejecute cuando desee. Para garantizar la personalización, previo a la ejecución de los canales el usuario debe obtener un perfil, obteniendo así los permisos pertinentes a los canales. Prioridad: OBLIGATORIO. RF4. El usuario podrá seleccionar y cambiar de canal. Una vez autenticado el usuario, se ofrece al usuario la oferta de canales disponibles y con acceso. Éste será capaz de reproducir los canales a su elección. Prioridad: OBLIGATORIO. RF5. Gestión de plugins. En este sistema, el concepto de plugin se entiende como aquellos componentes software (codecs y demás) que forman parte del reproductor de vídeo/audio. El usuario debe poder gestionar (ver, añadir, eliminar) los plugins. Al ser éstos piezas externar, se le confiere al sistema la capacidad de crecimiento, imprescindible para todo reproductor multimedia que se precie. Prioridad: OBLIGATORIO. RF6. El usuario se conectará (login) y desconectará (logout) para acceder a su perfil. La autenticación es el modo que tienen los usuarios para obtener un perfil. De este modo se obtienen los permisos de acceso a los canales. Prioridad: OBLIGATORIO. 3.2.2. Requisitos no funcionales RNF1. Compatible con el estándar OSGi R3. Este sistema debe ser ofrecido a través de una pasarela residencial compatible con el estándar OSGi Release 3. Prioridad: OBLIGATORIO. RNF2. Código abierto. El sistema será publicado bajo la licencia de código abierto LGPL (GNU Lesser General Public License). [LGPL] Prioridad: OBLIGATORIO. RNF3. Modelado con UML. 56 3. Análisis de requisitos Se ha utilizará el lenguaje de modelado UML [BOOCHRUMBJACOB1999] como lenguaje de análisis y diseño. Se usará la filosofía de programación orientada a objetos. Prioridad: OBLIGATORIO. RNF4. Extensible, escalable. Al tratarse de un reproductor multimedia, se debe dotar de la posibilidad de crecimiento. Los formatos multimedia es un mundo en constante evolución, con lo que es importante tener esta capacidad abierta. Por ello, se podrán gestionar dinámicamente los plugin (codecs y demás). Prioridad: OBLIGATORIO. RNF5. Multiidioma. Este proyecto se forma parte del proyecto europeo ITEA OSMOSE [OSMOSE]. Por ello, el lenguaje principal del mismo será el inglés. Sería deseable que también se pudiera ejecutar el sistema en español, lo que requiere dotar al sistema de multiidioma. Prioridad: OPCIONAL. RNF6. Reproducción del mayor número posible de formatos. Existe un gran número de formatos multimedia. Sería deseable que el sistema pudiera reproducir todos ellos, aunque es difícil lograr cubrir la totalidad. Se intentará dotar al sistema de la capacidad de reproducir los más modernos y extendidos. Prioridad: OBLIGATORIO. RNF7. El sistema tendrá un mecanismo de interacción con el usuario tipo GUI. Se entiende por GUI (Graphic User Interface) la interfaz gráfica de usuario. Prioridad: OBLIGATORIO. RNF8. Amigable y de fácil uso. Es deseable que el sistema sea accesible para cualquier usuario y que no requiera de conocimientos técnicos excesivos para su uso. Prioridad: OPCIONAL. RNF9. Reproducción de los contenidos a pantalla completa. Además de la reproducción normal de los contenidos con pista de vídeo (al tamaño que venga codificado dicha pista), se debe poder reproducir a pantalla completa. Prioridad: OBLIGATORIO. RNF10. Sincronizará la ejecución de las aplicaciones asociadas a los canales. 57 3. Análisis de requisitos El modo de conseguir interactividad entre multimedia y aplicaciones será sincronizar la reproducción multimedia con la ejecución de la aplicación. Prioridad: OBLIGATORIO. RNF11. El modelo de canales debe ser compatible con la arquitectura de OSGi. El modelo de canales (despliegue, interactividad) debe ser totalmente compatible con la arquitectura OSGi. Prioridad: OBLIGATORIO. RNF12. El sistema tendrá control de acceso basado en usuario/clave (login/password). Para obtener permisos a los canales, el usuario debe realizar una conexión (login) contra un servidor de perfiles. Asimismo realizará una desconexión (logout). Prioridad: OBLIGATORIO. 3.3. Casos de uso A partir de la visión y los requisitos del sistema, se pueden identificar a los actores involucrados y definir los casos de uso del sistema. De forma gráfica se pueden representar estos elementos. A continuación se da una breve descripción de éstos: • Actores: Un actor es algo identificado por un rol. Puede ser como una persona, un sistema informatizado, organización, etc. Realiza algún tipo de interacción con el sistema. Representado con figuras esquemáticas humanas. • Casos de uso: Expresa una unidad coherente de funcionalidad del sistema. Se representa en el diagrama de casos de uso mediante una elipse con el nombre del caso de uso en su interior. • Relaciones entre casos de uso: o Inclusión («include»): una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino. o Extensión («extend»): El caso de uso origen extiende el comportamiento del caso de uso destino. o Herencia: El caso de uso origen hereda la especificación del caso de uso destino y posiblemente la modifica y/o amplía. Figura 3.2, 3.3 y 3.4. Relaciones entre casos de uso. 58 3. Análisis de requisitos Para el sistema desarrollado en este proyecto, se han identificados tres actores principales: • Usuario del sistema: receptor final de los contenidos multimedia, personales e interactivos. • Gestor de canales: encargado de desplegar los canales para que estén disponibles en el sistema. • Gestor de perfiles: Encargados de autenticar usuarios. En función de esta autenticación se desplegarán los correspondientes canales interactivos. Figura 3.5. Diagrama de casos de uso A continuación se detalla cada uno de los Casos de Uso (CU) del diagrama. 59 3. Análisis de requisitos 3.3.1. CU1 – Reproducir multimedia Figura 3.6. CU1 – Reproducir multimedia • Descripción del escenario de éxito: Reproducción de contenidos multimedia, es decir, vídeo, audio o audio/vídeo. • Actores implicados: Usuario, multimedia. • Caso de uso relacionado: Reproducción streaming, reproducción en local, reproducción bajo demanda, reproducción por difusión, ejecutar canales. • Inicio/Fin: El caso de uso puede comenzar de dos formas. La primera es que el usuario pida la reproducción de un contenido multimedia (en local o remoto). La otra es que el usuario pida la ejecución de un canal, lo que también supone reproducir multimedia. • Precondiciones: Para streaming es necesario disponer de conexión a Internet. Para ejecutar canales previamente es necesario autenticar al usuario y desplegar los canales. • Postcondiciones: • Requisitos relacionados: o Funcionales: RF1 y todos sus apartados (RF1.1, RF1.2, RF1.1.1 y RF1.1.2). o No funcionales: RNF2, RNF3, RNF5, RNF6, RNF7, RNF8, RNF9. • Secuencia de interacciones: 1. Solicitud de reproducción. 2. Reproducción. 3. Solicitud de finalización o bien alcanzar el final de la reproducción. 3.3.2. CU2 – Ejecutar canales Figura 3.7. CU2 – Ejecutar canales 60 3. Análisis de requisitos • Descripción del escenario de éxito: Reproducción de un canal interactivo, esto es, contenido multimedia con aplicaciones interactivas asociadas al mismo. • Actores implicados: Usuario. • Caso de uso relacionado: Ejecutar aplicaciones interactivas, reproducir multimedia. • Inicio/Fin: El usuario pide la ejecución de un canal interactivo, con lo que se inicia la reproducción del contenido multimedia así como la o las aplicaciones interactivas (si las hay). • Precondiciones: Es necesario que el usuario esté dado de alta y que se haya desplegado algún canal. • Postcondiciones: • Requisitos relacionados: o Funcionales: RF2, RF3, RF4. o No funcionales: RNF1, RNF2, RNF3, RNF4, RNF5, RNF7, RNF8, RNF10, RNF11. • Secuencia de interacciones: 1. Solicitud de ejecución de canal. 2. Reproducción multimedia y ejecución de aplicación, ambas de manera sincronizada. 3. Solicitud de finalización o bien alcanzar el final de la reproducción. 3.3.3. CU3 – Conectar usuario Figura 3.8. CU3 – Conectar usuario • Descripción del escenario de éxito: El usuario introduce un nombre y clave (login y password) correctos, de manera que se despliegan los canales y se seleccionan aquellos canales a los que el usuario tiene acceso. • Actores implicados: Usuario, gestor de perfiles, gestor de canales. • Caso de uso relacionado: Seleccionar canales, desplegar canales. • Inicio/Fin: El comienzo de este caso de uso tiene lugar cuando se realiza una petición de login. Se da por terminado cuando se ofrecen los canales al usuario, o bien si no hay canales a ofrecer (porque no tiene acceso a ninguno o porque ha habido error en el login). • Precondiciones: - 61 3. Análisis de requisitos • Postcondiciones: Los canales desplegados y con acceso para el usuario estarán disponibles para su ejecución. • Requisitos relacionados: o Funcionales: RF6. o No funcionales: RNF2, RNF3, RNF5, RNF7, RNF8, RNF12. • Secuencia de interacciones: 1. Petición de login. 2. Despliegue de canales (si la pareja login – password) es correcta. 3. Selección de los canales a los que tiene acceso 3.3.4. CU4 – Desconectar usuario Figura 3.9. CU4 – Desconectar usuario • Descripción del escenario de éxito: El usuario cierra la sesión iniciada anteriormente, con lo que los canales accesibles antes dejan de estar disponibles. • Actores implicados: Usuario, gestor de perfiles. • Caso de uso relacionado: • Inicio/Fin: El comienzo de este caso de uso tiene lugar cuando se realiza una petición de desconexión (logout). Los canales que estaban disponibles con el login, no lo estarán ahora. • Precondiciones: Es necesario realizar el proceso de conexión antes. • Postcondiciones: Los canales dejan de estar disponibles. • Requisitos relacionados: o Funcionales: RF6. o No funcionales: RNF2, RNF3, RNF5, RNF7, RNF8. • Secuencia de interacciones: 1. Petición de logout. 2. Eliminación de canales. 3.3.5. CU5 – Gestionar plugins Figura 3.10. CU5 – Gestionar plugins 62 3. Análisis de requisitos • Descripción del escenario de éxito: El usuario tiene la opción de modificar la información relativa a plugins (codecs, multiplexer, etc.). • Caso de uso relacionado: • Inicio/Fin: El usuario pide el acceso a los plugins. Se muestra una lista con todos los valores de los mismos, y puede modificar lo que desee. • Precondiciones: • Postcondiciones: • Requisitos relacionados: o Funcionales: RF5. o No funcionales: RNF2, RNF3, RNF4, RNF5, RNF7, RNF8. • Secuencia de interacciones: 1. Petición de logout. 2. Eliminación de canales. 3.3.6. Casos de uso frente a requisitos A continuación se ofrece una comparativa entre casos de uso y requisitos del sistema, mediante la siguiente tabla: Casos de uso Requisitos RF1. Reproducción multimedia RF2. Ejecución de Canales RF3. Despliegue de canales RF4. Selección y cambio de canal RF5. CU1. Reproducción Multimedia CU2. Ejecución Canales CU3. Conexión Usuario CU4. Desconexión Usuario X X X X Gestión de plugins RF6. Conexión y desconexión RNF1. Compatible con el estándar OSGi R3. RNF2. Código abierto. RNF3. Modelado UML. RNF4. Extensible y escalable. RNF5. Multiidioma. RNF6. Reproducción de muchos formatos. CU5. Gestión Plugins X X X X X X X X X X X X X X X X X X 63 X X X X 3. Análisis de requisitos RNF7. Interacción con el usuario tipo GUI. RNF8. Amigable y de fácil uso. RNF9. Reproducción a pantalla completa. RNF10. Sincronización de las aplicaciones asociadas a los canales. RNF11. El modelo de canales debe ser compatible con la arquitectura OSGi. RNF12. Control de acceso basado en usuario/clave X X X X X X X X X X X X X X Tabla 3.1. Casos de uso frente a requisitos 64 4. Herramientas 4. Herramientas En este punto del desarrollo, ya se sabe exactamente qué se va a hacer. Además, gracias al estudio realizado en el “Estado del Arte” se han adquirido los conocimientos necesarios para poder tomar decisiones con mejor criterio. Es el momento de definir las herramientas a utilizar para la realización del proyecto. 4.1. Introducción Son muchas las herramientas y necesarias para desarrollar un sistema software. Son también muchas las decisiones a tomar, en cuánto a que tecnologías usar. Por ello se ha seguido ha agrupado las herramientas a usar como sigue: • • • • • • • Sistema operativo. Herramientas de edición. Pasarela Residencial. Programación. Herramientas multimedia. Servidores. Otras utilidades. 4.2. Sistema operativo La primera decisión que se debe tomar es qué sistema operativo se va a usar. Está claro que es una decisión importante, ya que en un sistema software el sistema operativo es la base del sistema. El RNF2 impone la obligatoriedad de usar herramientas open source, luego se debe usar alguna de las distribuciones GNU/Linux (ver punto 2.3.1.). La distribución más libre de todas es Debian GNU/Linux, ya que basa sus principios y fin en el software libre, es decir, es open source y lo seguirá siendo por siempre (o dejará de existir). [DEBIAN]. Hay tres distribuciones Debian: • stable : distribución estable, robusta y probada. El nombre de esta distribución en el momento de la realización de este PFC es woody. • testing : distribución estable, robusta y probada. El nombre de esta distribución en el momento de la realización de este PFC es sarge. • unstable : distribución estable, robusta y probada. El nombre de esta distribución se conoce siempre como sid. Se ha optado por elegir sid como distribución a usar porque los paquetes de esta distribución son los más nuevos y con el software más utilizado. Se corre el riesgo de que las cosas no funcionen a la primera, ya que es una distribución que todavía no es estable. Lejos de ser un inconveniente, este hecho ayuda aprendizaje del universo Linux, a costa de algún que otro quebradero de cabeza eventual. Como entorno de escritorio se ha elegido KDE (K Desktop Environment). Es un entorno de escritorio gráfico e infraestructura de desarrollo para sistemas Unix y en particular Linux. De acuerdo al sitio de KDE: "KDE es un entorno gráfico contemporáneo para estaciones de trabajo Unix. KDE llena la necesidad de un 65 4. Herramientas escritorio amigable para estaciones de trabajo Unix, similar a los escritorios de MacOS o Windows". Se ha trabajado con la versión 3.0 de KDE. [KDE] 4.3. Herramientas de edición En este apartado se van a elegir las herramientas de edición de texto, de gráficos, de diagramas UML y de diagramas Gantt. Para la edición de texto se usará OpenOffice, en su versión 2.0 beta para Linux, por ser la última versión actualmente. Esta herramienta es sin duda la referencia en cuanto a herramientas ofimáticas en el movimiento open source. [OPENOFFICE] Para la edición de imágenes se usará Gimp (GNU Image Manipulation Program). GIMP es un programa de manipulación de imágenes del proyecto GNU. Esta herramienta es la alternativa más firme del software libre en cuánto a creación y retoque de imágenes. Se publica bajo la licencia GPL. Se utilizará la versión 2.2. [GIMP] Para la edición de diagramas UML se usará Poseidon for UML Community Edition de Gentleware. Es una herramienta de análisis bastante sencilla e intuitiva. [POSEIDON] Para la edición de diagramas Gantt se usará la herramienta Mr. Project. Esta herramienta viene incluida con la distribución sid de Debian, con lo que no es necesaria instalarla si partimos de un sistema Debian. 4.4. Pasarela Residencial Una vez con un sistema operativo instalado, y con las herramientas de edición descritas, se necesita decidir que tipo de pasarela residencial se va a usar. Como punto de partida se dispone de la información del apartado 2.2.3, concretamente las implementaciones libres. Además, el RNF1 de este proyecto obliga al sistema a ser “compatible con el estándar OSGi R3”. Con estas premisas, las posibilidades se reducirían a dos Knopflerfish y OSCAR. Dado que OSCAR (Open Service Container Architecture) está dentro del proyecto Osmose, esta será el framework elegido para este proyecto. [OSCAR] Para dotar a nuestra aplicación de interactividad se utilizarán los recursos de despliegue de servicios de OSCAR. Los canales interactivos presentados en el RF2 y RF3 del apartado 3.2.1 pueden ser implementados mediante aplicaciones OSGi (bundles). Dada la naturaleza meramente software de la plataforma de servicios OSGi, ésta puede instalarse en cualquier ordenador personal (PC) con el hardware deseado (interfaces de red local, inalámbrica, domótica, módem, etc). Por lo demás el ordenador sólo necesita un sistema operativo, una máquina virtual Java y una implementación de la plataforma OSGi, que puede ser cualquiera de las comentadas anteriormente. Por este motivo, una forma sencilla de construir una pasarela de servicios para el hogar es adquirir un mini-ordenador o barebone (que es similar a un PC común, pero con dimensiones reducidas) con las características hardware deseadas e instalar el software comentado. 66 4. Herramientas El equipo que hace las veces de barebone será “Bayanet”. Este equipo ha sido desarrollado por el DIT (Departamento de Ingeniería de Sistemas Telemáticos). Sus características son las siguientes: • Procesador EPIA VIA C3.2 a 1GHz. • Placa VIA EPIA M9, con decodificador MPEG2 integrado, 6 puertos USB, puerto Firewire... • Memoria 512 MB RAM. • Disco Duro 60 GB. Además, se le ha añadido un a Bayanet una tarjeta de Philips llamada Luddite. Esta tarjeta es un prototipo, no tiene referencias comerciales. Permite realizar la decodificación de MPEG-2 vía hardware, con lo que libera de mucha carga de procesamiento a la pasarela. Figuras 4.1. y 4.2. Bayanet 4.5. Programación El sistema aquí desarrollado debe ser una aplicación OSGi ya que será ofrecida a través de pasarela residencial (objetivo del proyecto). Las aplicaciones OSGi son conocidas como bundles, y son ficheros JAR. Esto significa que deben estar programados en Java. Así pues, el lenguaje a utilizar en este proyecto es Java. Como se vio en el apartado 2.2.3 del estado del arte, Java es libre en cuanto a: • Un lenguaje de programación. • Una especificación de una máquina virtual. • Una especificación de un formato binario (bytecodes). Pero no es libre si se entiende por Java: • Un conjunto de clases y librerías que nos permiten la realización de programas mediante un dialecto determinado. Como entorno de desarrollo Java se ha optado por usar J2SE 1.4 de Sun Microsystems. Este entorno de desarrollo no es libre ya que se distribuye bajo la licencia SCSL. Esto impide redistribuir el kit de desarrollo, aunque se permite su uso. Dado a que en este proyecto solo se necesita su uso, es perfectamente válida esta solución. 67 4. Herramientas Si se desea desarrollar toda la aplicación en lenguaje Java, es necesario usar una API para la manipulación de contenidos multimedia. La API elegida es JMF de Sun Microsystems, en su versión 2.1.1e [JMF]. La API JMF (Java Media Framework) proporciona mecanismos de reproducción de vídeo, tanto en local como en remoto. De este modo completamente quedan cubiertos el RF1. La estructura de plugins de JMF (Demultiplexer, Codec, Effect o Renderer) coincide justo con lo planteado por los requisitos RF5 (gestión de plugins) y RNF4 (extensible, escalable). A continuación se detallan los cinco tipos de plugins JMF: • Un Demultiplexer es la unidad que acepta un flujo multimedia (formato contenedor) a su entrada y extrae las pistas (tracks) individuales. • Un Multiplexer es la unidad que hace la operación contraria al Demultiplexer: obtiene las pistas codificadas (tracks) como parámetros de entrada y las entrelaza en un fichero contenedor a su salida. • Un Codec es el plugin JMF que implementa el algoritmo de decodificación multimedia de las pistas (tracks). • Un Renderer es la unidad de procesamiento que redirige los flujos hacia el destino final, o sea, la pantalla o el sistema de audio. La traducción más fidedigna de la palabra inglesa "render" es "interpretación", aunque se habla vulgarmente de "renderizar". • Un Effect es la unidad de procesamiento que toma como entrada las pistas (tracks) y les aplica algún procesado especial. Por sí solo JMF no soluciona todas las necesidades del sistema a desarrollar en este PFC. Los formatos soportados por la versión 2.1.1e son reducidos y bastante antiguos. Al final se ha optado por usar JMF porque existen plugins libres que añaden funcionalidad al reproductor. De esta manera queda cubierto el RNF6 (reproducción del mayor número posible de formatos). Estos plugins son: • Fobs4JMF: Plugins para JMF que extiende a funcionalidad de esta API. De esta forma, es posible reproducir formatos como XviD, DivX, OGG, y un largo etcétera. [FOBS] • Jffmpeg: Mejora alguno de los codecs de JMF, como por ejemplo H.263. [JFFMPEG] • JMF MP3 plugin: Codec para soportar la reproducción de ficheros MP3 [MP3PLUGIN] 4.5.1. Entorno de desarrollo integrado Se utilizará eclipse como entorno de desarrollo integrado (IDE) debido a las cualidades descritas en el apartado 2.3.4 del presente documento. Eclipse cuenta con muchas herramientas que facilitan el desarrollo de software. En este proyecto, serán de utilidad las siguientes herramientas: • JUnit: Sirve para realizar pruebas unitarias en código Java. JUnit proporciona una manera diferente de probar el código, consistente con la filosofía del Extreme Programming (XP), que se puede resumir con la frase “programa un poco, prueba un poco, refactoriza un poco” (test a little, code a little, refactor a little). JUnit facilita que las pruebas se desarrollen a medida que se desarrolla el código. [JUNIT] 68 4. Herramientas • Teaminabox: Plugin para control de métricas y generación de estadísticas. [TEAMINABOX] • Ant: Ant es una herramienta del proyecto Jakarta de Apache que viene a ser un equivalente de make (mucho más moderno) para los desarrolladores Java. [ANT] • CVS: CVS (Concurrent Versions System) es una herramienta para la gestión de la configuración de proyectos software, puesto que permite mantener simultáneamente múltiples versiones y ramas de un mismo proyecto, permitiendo la modificación concurrente del código fuente por parte de múltiples colaboradores y su posterior fusión permitiendo manejar los conflictos. [CVS] Como se ha indicado en el RNF2, el sistema desarrollado en este proyecto será libre y publicado con licencia LGPL. El sitio web donde estará disponible la aplicación será OS4OS (Open Software for Open Services). [OS4OS] Se aprovechará el repositorio CVS que brinda OS4OS. • Javadoc: La documentación sobre el código Java se generará con Javadoc. Esta herramienta permite crear páginas HTML con información de todas las clases, propiedades, y métodos. [JAVADOC] 4.6. Herramientas multimedia Son necesarias aplicaciones de edición de multimedia. Esto es así debido a que para probar el reproductor de vídeo se necesitan archivos de diferentes formatos. Las herramientas multimedia elegidas son las siguientes. • Avidemux. Editor de vídeo y audio. Soporta multitud de formatos de entrada y de salida. [AVIDEMUX] • FFmpeg. Aplicación que graba y convierte audio y vídeo. [FFMPEG] • Qt4linux. Solución completa de edición de audio y vídeo con formato Quicktime para Linux. [QT4LINUX] • Transcode. Editor de vídeo para XviD. [TRANSCODE] 4.7. Servidores Se necesitan tres tipos de servidores en este PFC: • Servidores web: Para realizar streaming a través de HTTP. • Servidores multimedia: Servidores de streaming propiamente dicho, a través de los protocolos RTSP y RTP. El servidor web elegido no podía ser otro que Apache, paradigma de los servidores web de software libre. [APACHE] Como servidores de streaming se usarán los siguientes: • Darwin Streaming Server (DSS). Servidor de streaming [DSS] liberado por Apple bajo la licencia APSL (Apple Public Source License) [APSL]. • FFserver. Servidor de streaming incorporado con la herramienta de edición de vídeo FFmpeg [FFMPEG]. 69 4. Herramientas • VideoLAN. Es una solución de software completa para transmisión de vídeo, con licencia GPL. VideoLAN está diseñado para transmitir vídeo MPEG en redes con gran capacidad de ancho de banda. [VIDEOLAN] La posibilidad de autenticar usuarios y desplegar canales en función de esto (requisito RF6) se implementará mediante servicios web (webservices). Esta tecnología se ha convertido en un estándar de facto para la comunicación entre aplicaciones son Los Servicios Web en su conjunto pueden definirse como una plataforma intermedia de acoplamiento débil, basada en el estándar XML (Extensible Markup Language), que hace posible que una aplicación que implementa un servicio en cualquier sitio en Internet sea accesible utilizando protocolos estandarizados como el protocolo de transporte de hipertexto (HTTP, Hypertext Transfer Protocol) o el de transporte de correo (SMTP, Simple Mail Transfer Protocol). Estos servicios web se instrumentarán con Axis y Tomcat. Tomcat es quizás la herramienta más conocida del proyecto Yakarta. Es poderoso servidor web con soporte a Java Servlets y JSP (Java Server Pages). [TOMCAT] AXIS (Apache EXtensible Interaction System) de Apache es esencialmente un motor SOAP de código abierto, esto es, una plataforma para construir procesadores de SOAP tales como clientes, servidores, etc., en definitiva, servicios web. AXIS está diseñado para ser flexible, rápido, estable e incorpora herramientas que facilitan la transformación de interfaces Java a documentos WSDL y viceversa. Además, gracias a sus descriptores de despliegue WSDD (Web Service Deployment Descriptor), el despliegue de cualquier servicio web sobre el motor se hace sencillo. [AXIS] 4.8. Otras utilidades El resto de utilidades que se necesiten se obtendrán de los repositorios de aplicaciones libres. Como el sistema operativo es GNU/Linux Debian, es fácil instalar todo tipo de aplicaciones con la herramienta de consola apt-get. Como navegador se va a usar Mozilla FireFox. [FIREFOX] Es el navegador de nueva generación de Mozilla. Como analizador de red se usará la herramienta Ethereal. Esta herramienta será útil cuando se desee ver la comunicación entre cliente y servidor en los servicios web, mensajes SDP y RTSP, etc. [ETHEREAL] 70 5. Diseño del sistema 5. Diseño del sistema El diseño es una parte muy importante en todo desarrollo software. Una vez creado el modelo de sistema y definidas exactamente las tecnologías y herramientas a utilizar, es necesario precisar cómo se va a implementar el sistema. Siguiendo con el ciclo de vida definido para este proyecto, en primer lugar se definirán los módulos en base a funciones del sistema. Para cada una de esos módulos se realiza un diseño, se implementa y se realizan pruebas. Para realizar los diseños se han realizado principalmente diagramas UML. 5.1. Introducción Está perfectamente claro que el sistema a desarrollar es un reproductor de vídeo personal interactivo a través de pasarela residencial. El modo de proporcionar interactividad a los contenidos multimedia será implementar canales, que son asociaciones sincronizadas de multimedia con aplicaciones. El modo de proporcionar personalización será la obtención de un perfil, el cual discrimina los permisos de acceso a los diferentes canales. Los canales se desplegarán en la pasarela de forma autónoma al reproductor, y serán accedidos a posteriori previa obtención del perfil. Sentadas las bases del desarrollo, se ha bautizado este sistema con el nombre de piPlayer (Personal Interactive Player) o sea, Reproductor Personal e Interactivo. El logotipo diseñado para de esta aplicación se basa en el la letra griega pi. Figura 5.1. Logo piPlayer Dado que este PFC se enmarca en el ámbito del proyecto europeo OSMOSE, el idioma en el que se basará el desarrollo del sistema será el inglés. Es por ello que el nombre de la aplicación responda a términos anglosajones. Asimismo, toda la programación se hará en este idioma. 5.2. Diagramas de despliegue Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo contiene instancias de componentes software. En general, un nodo es una unidad de computación de algún tipo. El primer diagrama que se presenta es el diagrama de despliegue en el que sólo aparecen los nodos, esto es, las máquinas involucradas en el sistema a desarrollar. Viene a ser el diagrama UML presentado en el punto 3.1 de esta memoria (figura 3.1). 71 5. Diseño del sistema Figura 5.2. Diagrama de nodos El sistema principal será ejecutado en la pasarela residencial. Se comunicará con los servidores con los protocolos marcados: • Pasarela residencial Æ Servidor de aplicaciones: protocolo HTTP. • Pasarela residencial Æ Servidor de perfiles: protocolo SOAP (servicios web). • Pasarela residencial Æ Servidor de streaming: protocolos HTTP/RTSP/RTP. La pasarela residencial ejecutará un framework OSGi, concretamente OSCAR. En OSGi las aplicaciones se conocen con el nombre de bundles y están programadas en lenguaje Java. Todos los componentes que se ejecutarán en la pasarela residencial serán bundles. Son los siguientes: • piPlayer: Aplicación propiamente dicha. Encargada de proporcionar una interfaz gráfica (GUI, Graphic User Interface) de cara al usuario, reproducción de vídeo, ejecución de canales, y autenticación de usuario. Es la pieza central del desarrollo. • Paquetes de canales (channels). Estos bundle contienen los canales interactivos. Podrá haber un número indeterminado de canales dentro de cada paquete. De igual manera, el número de paquetes no está definido a priori. • Aplicaciones interactivas (ia, interactive application). Cada una de las aplicaciones que están sincronizadas con sendos contenidos multimedia para formar lo que llamamos canal. • Paquete AXIS: Conjunto de librerías necesarias para realizar peticiones SOAP y obtener perfiles. Es la forma de instrumentar servicios web. • Paquete JMF: Conjunto de librerías de la API JMF. Necesario para la reproducción de vídeo. • Plugins JMF: Componentes software adicionales a JMF para extender la funcionalidad del mismo. De este modo se consigue que el reproductor sea compatible con más formatos multimedia de los meramente soportados por JMF. Estos componentes son: 72 5. Diseño del sistema o Fobs4JMF: Codecs necesarios para la reproducción de Xvid, DivX, MPEG-4, WMV, y RealMedia, entre otros. o MP3Plugin: Codec para la reproducción del formato de audio MPEG-1 Layer 3. o JFFMPEG: Codec que mejora la reproducción de H.263, añadiendo la funcionalidad de H.263+ y H.263++. A continuación se describe de forma gráfica (mediante un diagrama de barras) los bundles descritos. Se corresponde con la arquitectura software a desplegar en el nodo “Pasarela Residencial” de la figura 5.2. Figura 5.3. Diagrama de barras Los bundles AXIS, JMF y Plugins JMF (pintados en naranja en el diagrama de la figura 5.3) son las librerías utilizadas por el bundle piPlayer. Es necesario que sean bundles por la propia naturaleza del framework OSGi. No requieren ninguna labor de adicional de desarrollo. Sólo hay que tener cuidado a la hora de crear el bundle. En el manifiesto de este (Manifest.mf) habrá que incluir una línea con los paquetes que exportará. El encabezado de esta línea es Export-Package y es necesaria porque de otro modo se producirían errores en tiempo de ejecución al no localizar las clases requeridas. Dicho esto, el trabajo se centra en: • • • • Desarrollar el bundle piPlayer. Desarrollar los bundles de canales. Desarrollar los bundles de aplicaciones interactivas. Instrumentar un servicio web para la autenticación y el acceso a los canales. 73 5. Diseño del sistema Para completar este apartado del diseño se propone el siguiente diagrama de componentes. Figura 5.4. Diagrama de componentes Básicamente, este diagrama muestra las interacciones del bundle piPlayer con las aplicaciones interactivas (IA) y los paquetes de canales (channels). La idea es que los paquetes de canales son desplegados de forma transparente al usuario final. Para la interacción entre los bundles se implementa un mecanismo de eventos basado en el patrón whiteboard. En primer lugar se estudia este patrón para la interacción piPlayer-Channels. 1. Se crea una interfaz común (Channel). 2. Se crea una interfaz ChannelListener que será implementado por el bundle que quiere ser notificada de eventos. Se registra esta implementación en el registro OSGi. Los eventos son dos: ChannelAdded y ChannelRemoved. 3. Se crea una interfaz ChannelAdmin, cuya implementación (ChannelAdminImpl) además extiende la funcionalidad de ServiceListener. Cuando ocurre se registra o se elimina una instancia de la implementación de Channel, el ChannelAdminImpl busca en el registro OSGi los servicios ChannelListener y se encarga de notificarles el evento. De este modo se consigue crear un modelo interactivo para el mantenimiento de canales, con la ayuda del registro OSGi que proporciona el framework OSCAR. De manera similar se procede con la interacción piPlayer-IA. Esta relación instrumentará la sincronización entre la reproducción de vídeo y la ejecución de la aplicación interactiva correspondiente. La idea es capturar los eventos de vídeo propios de la reproducción de vídeo. Estos eventos son generados por el usuario, al iniciar la reproducción de vídeo (START), pararla (PAUSE), dar un salto en la ejecución (SEEK), o bien terminar ejecución (STOP). Estos eventos tienen que tener reflejo en la aplicación interactiva (IA) para que la sincronización sea efectiva. Se procede con el mismo patrón que para los canales, pero esta vez la fuente de eventos es el propio piPlayer y el listener pasa a ser la IA. Este modelo es muy importante para el correcto funcionamiento del sistema. Para clarificar su funcionamiento, se va a ir explicando en detalle en los próximos apartados de este diseño. 74 5. Diseño del sistema 5.3. Diagrama de paquetes Cualquier sistema grande se debe dividir en unidades más pequeñas, ya que es más sencillo trabajar con una cantidad de información limitada. Los paquetes son unidades de organización jerárquica de uso general de los modelos de UML. Ofrecen un mecanismo general para la organización de los módulos agrupando funcionalidades. Se aprovechará esta división para realizar las diversas iteraciones en el ciclo de vida propuesto. La división es como sigue: Figura 5.5. Diagrama de paquetes En este diagrama se ve claramente que la pieza central de la aplicación es el bundle piPlayer, ya que contenido en el paquete de igual nombre se encuentran los módulos necesarios para desarrollar el sistema. Véase: 75 5. Diseño del sistema • piplayer.player: Módulo de reproducción de vídeo y audio. • piplayer.gui: Módulo de interfaz gráfica de usuario. • piplayer.webservices: Módulo de obtención de perfiles (autenticación y acceso a los canales) mediante servicios web. • piplayer.tools: Herramientas varias. • piplayer.junit: Módulo de pruebas unitarias. • piplayer.osgi: Módulo de implementación de servicios OSGi. • piplayer.osgi.services: Módulo de interfaces de servicio OSGi. Casos de uso Módulos piplayer.player piplayer.gui piplayer.webservic es piplayer.tools piplayer.junit piplayer.osgi piplayer.osgi.servi ces channel ia CU1. Reproducción Multimedia X X CU2. Ejecución Canales CU3. Conexión Usuario CU4. Desconexión Usuario CU5. Gestión Plugins X X X X X X X X X X X X X X X X X X X X X X X X Tabla 5.1. Casos de uso frente a módulos El diseño de estos módulos se ha ido haciendo progresivamente. En el siguiente apartado se detallan todos los módulos mediante diagramas de clases. 5.4. Diagramas de clases Las clases representan los bloques de construcción de los sistemas orientado a objetos. Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. En este apartado se van a mostrar los diagramas de clases del sistema, agrupados por componentes (bundles) y módulos (paquetes). 5.4.1. Bundle piPlayer 5.4.1.1. Módulo principal El llamado ‘Módulo principal’ corresponde al paquete piplayer. Este paquete contiene a todos los demás. Hay que destacar un aspecto. La aplicación piPlayer ha sido diseñada con la premisa de ofrecer servicio a través de una pasarela residencial. Esto significa que es una bundles, y por lo tanto, que su clase iniciadora es una clase Activator (extiende a BundleActivator). En cualquier caso, se ha generado también una clase Main, para que quepa la posibilidad de ejecutar la aplicación fuera de OSCAR. En esta situación, piPlayer pierde su doble valor de personalización e interactividad que está íntimamente ligado con OSGi, pero en esta situación seguiría poder reproducir multimedia. 76 5. Diseño del sistema Figura 5.6. Diagrama de clases: piplayer 5.4.1.2. Módulo de herramientas En este paquete se incluyen una serie de utilidades genéricas para la aplicación. Estas herramientas instrumentan el multiidioma, la impresión de mensaje hacia el usuario, y herramientas XML. Figura 5.7. Diagrama de clases: tools 77 5. Diseño del sistema 5.4.1.3. Módulo de interfaz gráfica Dado la naturaleza misma de este sistema, la interfaz con el usuario es más importante que otro tipo de sistema. La calidad de la interfaz gráfica, usabilidad y facilidad de uso pueden determinan el éxito o fracaso de la aplicación. Además, la interfaz de usuario es la encargada de recoger los eventos de usuario y redirigir el flujo de ejecución hacia el resto de módulos. Figura 5.8. Diagrama de clases: gui 78 5. Diseño del sistema Inspeccionando el diagrama anterior se puede ver una división clara en los elementos de la interfaz. Como elemento central está la clase MainFrame. La estructura por debajo de esta clase es como sigue: • FrameSettings: Clase que agrupa los parámetros de configuración de la GUI. • ImageFactory: Clase encargada de acceder a las imágenes necesarias para mostrar. • FrameElements: Elementos del marco (frame) principal. Son los siguientes: o MenuBar: Menú de usuario. Esta clase es muy importante porque sus métodos instrumentarán toda la acción generada por la interacción con el usuario. o StatusBar: Barra de estado. En ella aparecerán mensajes para el usuario. o Toolbar: Barra de herramientas. Botonera de acceso rápido a las funciones principales del sistema. o Paneles: Conjunto de paneles de la GUI: MediaPanel, ControlPanel, HomePanel, etcv o Cuadros de diálogos: Popups de la aplicación: UrlDialog, About, LoginDialog, etc. 5.4.1.4. Módulo de reproducción multimedia Para la reproducción multimedia se dispone de un conjunto de clases estáticas que pueden ser accedidas desde el resto de la aplicación sin necesidad de ser instancias. Esto es así debido a la naturaleza estática de la reproducción multimedia. El diagrama es el siguiente: 79 5. Diseño del sistema Figura 5.9. Diagrama de clases: player A continuación se detallan las características de estas clases: • • • • • • • LocalPlayer: Encargada de la reproducción en local. Streaming: Encargada de la reproducción en remoto (HTTP, RTSP, RTP). ChannelControl: Muestra/oculta los canales en la GUI previa autenticación. FullScreen: Reproducción a pantalla completa. Stop: Para la reproducción de cualquier tipo de reproductor (local o remoto). Listener: Escuchador de eventos multimedia. Fobs: Clase para controlar los codecs Fobs. Estos codecs tienen un fallo, y es que necesitan siempre pista de vídeo. Este hecho hace que sea imposible reproducir archivos de sólo audio (mp3 y demás formatos). Por ello se hace necesario controlar esta situación. Con esta clase se detecta si se están utilizando los codecs Fobs; si se intenta reproducir audio, los desactiva para volver a activarlos una vez terminada la ejecución. 5.4.1.5. Módulo de servicios web Para los servicios web se usa AXIS. El desarrollo de la parte cliente y servidora se ha hecho con las herramientas de AXIS Java2WSDL y WSDL2Java. El despliegue del servicio web en el servidor se hace con ficheros WSDD. La llamada al servicio de login es como sigue: LoginServiceLocator l = new LoginServiceLocator(); Ps4PiSoapBindingStub stub = (Ps4PiSoapBindingStub) l.getps4pi(); String channels_allowed[] = stub.login(login, password); … y la llamada al servicio de logout es totalmente equivalente: LoginServiceLocator l = new LoginServiceLocator(); Ps4PiSoapBindingStub stub = (Ps4PiSoapBindingStub) l.getps4pi(); stub.logout(); Estas clases son generadas automáticamente con las herramientas de AXIS Java2WSDL y WSDL2Java. [AXIS] A continuación se muestra las relaciones entre dichas clases mediante un diagrama de clases UML: 80 5. Diseño del sistema Figura 5.10. Diagrama de clases: webservices 5.4.1.6. Módulo de funcionalidades OSGi La intervención de OSCAR para conseguir enriquecer la reproducción multimedia es fundamental. Para instrumentar el despliegue de canales según el patrón whiteboard planteado en el apartado 5.2 de esta memoria se necesitan las siguientes clases: • ChannelAdmin: Administración de canales (interfaz). Contiene los métodos de gestión de canales así como los de autenticación. • ChannelAdminImpl: Implementación del interfaz ChannelAdmin. Además implementa el interfaz ServiceListener, de modo que hace las veces de escuchador de clases Channel en el registro OSCAR. • ChannelAdminDummyImpl: Implementación ‘tonta’ del interfaz ChannelAdmin. Implementa los métodos pero sin añadir funcionalidad ninguna. Esta clase se usa cuando piPlayer es ejecutado fuera de OSCAR, y solamente funciona como reproductor de vídeo. • ChannelListener: Escuchador de canales. Notifica la ocurrencia de los eventos que a su vez le comunica ChannelAdminImpl. • ChannelListenerImpl: Implementa la interfaz ChannelListener. • Channel: Interfaz que define a un canal. La implementación de este interfaz está fuera de piPlayer, concretamente en el/los bundle/s de canal/es (channels). Las relaciones entre estas clases se puede observar en la siguiente figura: 81 5. Diseño del sistema Figura 5.11. Diagrama de clases: osgi (despliegue de canales) El siguiente diagrama que se presenta en este paquete es el correspondiente a la gestión de eventos multimedia para conseguir sincronización con las aplicaciones: Figura 5.12. Diagrama de clases: osgi (eventos de multimedia) Mediante estas clases se consigue capturar los eventos multimedia generados por los canales y enviarlos a las aplicaciones interactivas (IA) asociadas a éstos. Para ver el funcionamiento de forma más clara, se aconseja la lectura de los diagramas de secuencia. 82 5. Diseño del sistema 5.4.1.7. Módulo de pruebas unitarias Las pruebas unitarias se instrumentan con clases independientes que implementan distintos casos de prueba. Estas pruebas se hacen necesarias para ir probando la coherencia y funcionalidad de cada uno de los módulos. También son muy importantes para asegurar la integración entre módulos. A continuación se detalla una breve descripción de los casos de prueba: • • • • LocalPlayerTest: Pruebas unitarias de la reproducción en local. StreamingTest: Pruebas unitarias de la reproducción en remoto. LoginTest: Pruebas unitarias de la autenticación. VideoEventTest: Pruebas unitarias de la interactividad. Figura 5.13. Diagrama de clases: junit 5.4.2. Bundles IA (aplicaciones interactivas) Se van a desarrollar 3 tipos de aplicaciones interactivas (IAs): • DIA (Dummy IA): Aplicación interactiva ‘tonta’. No hace nada. Su función es existir tal cual pero sin ninguna capacidad de acción. Figura 5.14. Diagrama de clases: dia • EIA (Echo IA): Aplicación interactiva de eco. Muestra por la consola OSCAR los eventos multimedia recibidos (START, STOP, PAUSE, SEEK) y el tiempo en el que ocurrieron. Esta aplicación no tiene una utilidad práctica real, pero resulta muy útil para calibrar la sincronización. Sirve como punto de partida para generar cualquier otra IA con más funcionalidad. 83 5. Diseño del sistema Figura 5.15. Diagrama de clases: eia • SIA (Snapshots IA): Aplicación interactiva de transparencias. Es una aplicación completa. Corresponde con el caso de uso (ver apartado 6.3 de esta memoria). Consiste en un vídeo educacional, “How Computer Works” [HOWCOMPUTER] al que se le ha añadido una aplicación interactiva consistente en las transparencias de la clase, sincronizada con el ritmo del profesor. Además, el usuario puede tomar apuntes para cada transparencia, y al finalizar el vídeo puede imprimir todas las transparencias con sus correspondientes apuntes. Figura 5.16. Diagrama de clases: sia 5.4.3. Bundle de canales (channels) Este componente viene a ser un paquete de canales que se despliegan en la pasarela residencial OSGi. Cuando es instalado este bundle (estado INSTALLED en el diagrama 5.21) se despliegan en el framework las aplicaciones interactivas de los canales. Como todos los bundles, consta de una clase que implementa BundleActivator (llamada Activator en la figura). Además, cuenta con la implementación del interfaz Channel. Este interfaz realmente pertenece al bundle piPlayer, pero es compartido en el framework OSCAR ya que es exportado por piPlayer. 84 5. Diseño del sistema La clase ChannelImpl define los canales que forman el paquete. Los datos que forman un canal son los siguientes: • name: Nombre del canal. • uid: Identificador único del canal. Es una especie de clave primaria de canal. • url[ ]: Array de URL de contenidos multimedia. Normalmente este array tendrá una posición para URL del tipo HTTP y RTSP. En el caso de RTP este array tendrá típicamente 2 posiciones, ya que cada sesión URL corresponde con una pista multimedia, y lo normal es contar de una pista para vídeo y otra para audio. • app[ ]: Array de URL de aplicaciones interactivas al canal. • description: Descripción del canal. Figura 5.17. Diagrama de clases: channels 5.5. Diagramas de secuencia Los diagramas de secuencia sirven para ordenar en el tiempo los mensajes compartidos entre los objetos del sistema. En el caso del desarrollo de esta aplicación son de vital importancia para clarificar tres escenarios fundamentales en el sistema: • Sincronización entre multimedia y aplicaciones (para conseguir así la interactividad). • Autenticación de usuario y obtención un perfil (para conseguir la personalización). • Despliegue de canales en la pasarela, y acceso a los mismos desde piPlayer (siempre y cuando el perfil obtenido permita el acceso a los mismos). 85 5. Diseño del sistema 5.5.1. Sincronización entre multimedia y aplicaciones Como se ha explicado en el apartado 5.2, la interacción entre los bundles para conseguir la interactividad se implementa mediante un mecanismo de eventos basado en el patrón whiteboard. Hay que tener en cuenta algo muy importante. La interactividad se consigue cuando la sincronización es real entre multimedia y aplicaciones. Este es el concepto. Para conseguir esto, habrá que capturar los eventos que proceden de la reproducción multimedia y hacerlos llegar hacia la aplicación que quiere estar sincronizada con dicho multimedia. La aplicación será la encargada de actuar como desee con esos eventos, es decir, deberá sincronizar su ejecución en base a los eventos que recibe. De esta forma se consigue que la reproducción multimedia y la ejecución de la aplicación esté así sincronizada, consiguiendo la ansiada interactividad. En el siguiente diagrama de secuencia se muestran estos eventos ordenados en el tiempo. El objeto “Interactive Application (IA)” es la aplicación interactiva. El objeto “OSCAR Registry” representa el registro OSGi implementado por el framework OSCAR. Las otras tres clases pertenecen al bundle piPlayer. Figura 5.18. Diagrama de secuencia de eventos de vídeo 86 5. Diseño del sistema Dada la importancia de este diagrama, es necesario explicar en detalle los pasos del mismo: • Registro de la fuente de eventos (pasos 1 y 2 del diagrama): En primer lugar, el bundle piPlayer registra en OSCAR un objeto que será la fuente de eventos multimedia (VideoEventSource). • Registro del receptor de eventos (pasos 3 y 4 del diagrama): Por otro lado, la aplicación interactiva se registra en OSCAR como receptora de eventos multimedia (VideoEventListener). • Generación de eventos multimedia (pasos 5, 8, 11 y 14 del diagrama): Cuando se reproduce un fichero multimedia se dan una serie de eventos: o START: Comienzo de la reproducción. Siempre va a ser el primer evento multimedia, pero también puede significar la reanudación de una reproducción que había quedado detenida. o SEEK: Salto en la reproducción. Se produce cuando el usuario adelanta o retrocede la reproducción. Puede producirse con la reproducción en marcha o estando pausada. o PAUSE: Pausa en la reproducción, pero sin que esto signifique que se deja de reproducir. o STOP: Fin de la reproducción, bien por alcanzar el fin de fichero, o por petición explicita del usuario. • Comunicación de los eventos multimedia hacia la aplicación interactiva (pasos 6-7, 9-10, 12-13 y 15-16): El objeto encargado de controlar los eventos multimedia (VideoEventSource) es avisado de la recepción de un evento. En ese momento busca en el registro OSCAR los objetos que se hayan registrado como receptores de los mismo (VideoEventListener) y les comunica dicho evento. 5.5.2. Autenticación de usuario y obtención de un perfil La autenticación es el paso previo a la obtención de un perfil, y con él los permisos de acceso a los canales interactivos. Es la forma de conseguir personalización en el sistema a desarrollar. Véase el diagrama de secuencia: Figura 5.19. Diagrama de secuencia de autenticación 87 5. Diseño del sistema Es el usuario el que inicia el proceso de autenticación. La interfaz gráfica de la aplicación debe ofrecer al usuario la opción de introducir su login y su password y enviarlo al servidor de perfiles (paso 1). Usando un servicio web, el stub que forma parte de piPlayer se comunicará con el servidor de perfiles (paso 2). Si todo va correctamente, se obtendrán una lista de canales a los que se tiene acceso (pasos 3 y 4). Después se pondrá a disposición del usuario los canales que estén desplegados en la pasarela, del conjunto de canales permitidos por el perfil obtenido (pasos 5 y 6). Para desligarse del perfil obtenido previamente (logout) se procede exactamente igual en el caso anterior. La diferencia es que ahora dejarán de estar disponibles para el usuario los canales que lo estaban antes (pasos 7 a 11). 5.5.3. Despliegue de canales Del siguiente diagrama, el objeto “Channels” pertenece al bundle channels. El resto pertenece a piPlayer, salvo “OSCAR Registry” que simboliza el registro OSGi. Figura 5.20. Diagrama de secuencia de despliegue de canales En primer lugar, el objeto encargado de la gestión de canales de piPlayer (ChannelAdmin) se registra en OSGi como escuchador de objetos Channel (paso 1). Ese hecho hace que cuando se registre un objeto Channel en la pasarela (paso 2) se notifique este evento al gestor de canales (paso 3). En este punto de la secuencia se procede a notificar que se ha añadido un canal nuevo (paso 5), y se si se tiene acceso a él (si se tiene permiso, dado a que pertenece al perfil del usuario) se muestra con el resto de canales (paso 7). 88 5. Diseño del sistema El paso 6 (reLogin) merece una mención especial. Este punto es necesario para actualizar los permisos sí y sólo si el usuario está autenticado y tiene un perfil dado (tiene permisos definidos a determinados canales). Este hecho se hace necesario para garantizar que el despliegue de canales en piPlayer sea interactivo. Se hace por si el perfil ha cambiado (en el servidor de perfiles) en el momento de desplegar nuevos canales. 5.6. Diagramas de estados Los diagramas de estados muestran el comportamiento de un objeto, es decir, el conjunto de estados por los cuales pasa un objeto durante su vida, junto con los cambios que permiten pasar de un estado a otro. En este sistema es importante observar el ciclo de vida de los bundles, ya que los componentes principales son de este tipo. Tener claro los estados y transiciones de los bundles se hace necesario para poder desarrollar el sistema: Figura 5.21. Diagrama de estados de los bundles El otro ciclo de vida a tener en cuenta para el desarrollo del sistema es el de los player JMF. Se debe reproducir el ciclo de vida para reproducir multimedia en local y en remoto. 89 5. Diseño del sistema Figura 5.22. Diagrama de estados de un player 90 6. Pruebas 6. Pruebas Para cada uno de los módulos de la aplicación es necesario realizar pruebas unitarias. De este modo se comprueba que todo funciona como se espera, y según se van añadiendo nuevas funcionalidades (nuevos módulos) se tendrá la certeza de que lo antes funcionaba, lo sigue haciendo después de etapas de integración. Para hacer pruebas de sistema se desarrollará un caso de estudio completo que responda al paradigma de este PFC: reproducción personal e interactiva. También es importante tener en cuenta la calidad de código programado. Es por ello que durante la implementación del sistema se tendrán en cuenta métricas de programación. En este apartado se recogen los resultados de esas métricas. 6.1. Pruebas unitarias Para el desarrollo de software actual está muy aceptadas las pruebas unitarias como medida para dotar de robustez y mantenibilidad a una aplicación. Estas pruebas tienen como principales objetivos comprobar que el código se comporta de la manera esperada y prevenir la aparición de errores inesperados al modificar o refactorizar el código. Las ventajas de realizar este tipo de pruebas son: código más depurado, mayor seguridad a la hora de refactorizar y mayor velocidad de desarrollo, aparte de obtener código de mayor calidad. Actualmente las pruebas unitarias se desarrollan con herramientas tipo JUnit [JUNIT] y objetos mock [MOCK]. Las herramientas tipo JUnit se aplican para comprobar que el estado de un objeto, los valores retornados por los métodos, excepciones lanzadas, etc., son los esperados. Los objetos ficticios o mocks permiten aislar el código a probar de las dependencias con otras clases colaboradoras mediante el desarrollo de clases ficticias que simulan el comportamiento de estas clases colaboradoras. Esto permite centrar la prueba sólo en el código que se desea probar. La estrategia para desarrollar este tipo de pruebas consiste en extraer el comportamiento del colaborador a una interfaz y realizar dos implementaciones de la misma, una real que se utilizará en producción y una implementación ficticia, mediante un mock, que se utilizará en las pruebas unitarias. En este proyecto se va a usar JUnit debido a su sencillez y potencia. Además, su uso esta integrado con el IDE Eclipse, lo que facilita la labor de obtención de resultados de pruebas unitarias. Siguiendo los módulos de este sistema, se han realizado pruebas unitarias dividas en tres bloques. Estos bloques son tests de las tres funcionalidades básicas de el sistema desarrollado, esto es, personalización, interactividad y reproducción de multimedia (piPlayer = personal interactive player). Se ha usado la herramienta Ant para generar los bundles del sistema. El fichero de configuración para Ant es build.xml. Se ha aprovechado esto para añadir una nueva tarea para automatizar las pruebas unitarias con JUnit, así como la generación automática de informes con los resultados de dichas pruebas. Para ello se han usado las tareas JUNIT y JUNITREPORT. Para la automatización de las pruebas se ha añadido una tarea al fichero build.xml, que la entrada para que la herramienta Ant lleve a cabo las tareas de compilación 91 6. Pruebas 6.1.1. Resumen de las pruebas En la siguiente tabla se muestra una relación entre casos de uso y las pruebas realizadas: Casos de uso Módulos LoginTest VideoEventTest LocalPlayerTest StreamingTest CU1. Reproducción Multimedia CU2. Ejecución Canales CU3. Conexión Usuario X CU4. Desconexión Usuario X CU5. Gestión Plugins X X X X X Tabla 6.1. Casos de uso frente a pruebas A continuación se muestra una tabla con el resumen de todas las pruebas. En total se han realizado 20 pruebas, todas ellas situadas en el paquete piplayer.junit, con un porcentaje de éxito del 100%: Summary Tests Failures Errors Success rate Time 20 0 0 100.00% 5.989 Note: failures are anticipated and checked for with assertions while errors are unanticipated. Packages Name Tests Errors Failures Time(s) Piplayer.junit 20 0 0 5.989 Tabla 6.2. Resumen de las pruebas unitarias 6.1.2. Pruebas de personalización Como ya se sabe, la personalización se logra obteniendo un perfil contra un servicio web. Dicho perfil permite al usuario tener acceso a un conjunto determinado de canales de los que tenga desplegados en su pasarela residencial. Por esto, las pruebas de personalización se van a basar en testear el proceso de login que tiene como resultado la obtención de los permisos de acceso a los canales. La clase encargada de realizar estas pruebas se llama LoginTest. Esta clase lanza una petición de login mediante servicios web. El servidor de perfiles desarrollado es básicamente un servicio web desplegado en AXIS que atiende a peticiones de login y logout. Se ha bautizado a este servicio con el nombre de ps4pi (Personal Server for piPlayer). Tal y como está desarrollado este servicio, las credenciales válidas son 4 parejas login y password diferentes, a las que corresponden diferentes permisos de acceso a los canales. Para más información sobre el funcionamiento de este servicio ver el manual de usuario en la sección de anexos. 92 6. Pruebas Es por esto por lo que se han lanzado 4 pruebas con parejas login-password diferentes. Son las cuatro parejas válidas, según está implementado el servidor de perfiles ps4pi. Las pruebas serán satisfactorias cuando se obtengan los permisos de acceso a los canales tras invocar el servicio de login. En caso contrario el test fallará. Las pruebas se basan en recibir un conjunto de permisos de acceso a canales tras la llamada al servicio web. Si el resultado es null o se captura una excepción, test será erróneo. El código más importante de esta clase es el siguiente: try { … LoginServiceLocator l = new LoginServiceLocator(); Ps4PiSoapBindingStub stub = (Ps4PiSoapBindingStub) l.getps4pi(); String channels_allowed[] = stub.login(login, password); assertNotNull(channels_allowed); } catch(Exception e2) { fail("Web Service unreachable"); } El resultado de estas pruebas se desglosa en las siguientes tablas: Class piplayer.junit.LoginTest Name Tests Errors Failures Time(s) LoginTest 4 0 0 1.345 Tests Name Status Type Time(s) Login #1 Success 1.236 Login #2 Success 0.039 Login #3 Success 0.030 Login #4 Success 0.025 Tabla 6.3. Pruebas de autenticación 6.1.3. Pruebas de interactividad La interactividad se logra con canales, en los que viven sincronizados el contenido multimedia con las aplicaciones. Para instrumentar esto se ha creado un mecanismo de eventos, en los que la fuente es la reproducción multimedia y el escuchador es la aplicación interactiva. Las pruebas unitarias para comprobar que la interactividad se está logrando están enfocadas a la fuente de eventos multimedia (VideoEventSource). Mediante la clase llamada VideoEventTest se hacen cuatro pruebas. Cada una de esas pruebas genera un evento multimedia (instrumentado con la clase VideoEvent) y cuyo tipo puede ser START, STOP, PAUSE y SEEK. Después se comprueba que se ha recibido 93 6. Pruebas correctamente dicho evento por el escuchador de eventos (VideoEventListener). Véase un fragmento de código (se va cambiando de valor la variable type y time para los diferentes test de la prueba): VideoEventSource ve = new VideoEventSourceImpl(); VideoEvent event = new VideoEvent(type, time); HashSet vl = ve.getListeners(); if (vl != null) { Iterator e = ve.getListeners().iterator(); while(e.hasNext()) ((VideoEventListener)(e.next())).executeAction(event); } Los resultados son los siguientes: Class piplayer.junit.VideoEventTest Name Tests Errors Failures Time(s) VideoEventTest 4 0 0 0.703 Tests Name Status Type Time(s) Start Success 0.208 Pause Success 0.156 Seek Success 0.130 Stop Success 0.193 Tabla 6.4. Pruebas de interactividad 6.1.4. Pruebas de reproducción Para el módulo de reproducción multimedia, se han desarrollado diferentes pruebas consistentes es reproducción en local y remoto (streaming). En estas pruebas se llamarán a los métodos de las clases de reproducción con diferentes URLs (en local y en remoto) y con diferentes formatos multimedia. Las pruebas serán satisfactorias cuando dé comienzo el ciclo de vida del reproductor de vídeo de modo satisfactorio. Tanto las pruebas locales y remotas funcionan de un modo similar. En primer lugar se llama al método de la clase que realiza la reproducción. La forma de ver si todo está yendo correctamente mediante programación es observar a la clase escuchador de eventos multimedia. Como se ha visto en el apartado 5.4.1.4 de esta memoria, dicha clase se llama Listener: Véase estos fragmentos de código: LocalPlayer.openLocalFile(url); assertNotNull(PiPlayer.mediaListener); … Streaming.openRTP(urls); assertNotNull(PiPlayer.mediaListener); 94 6. Pruebas … Streaming.openURL(url); assertNotNull(PiPlayer.mediaListener); Para las pruebas en local se ha implementado la clase LocalPlayerTest : Class piplayer.junit.LocalPlayerTest Name Tests Errors Failures Time(s) LocalPlayerTest 9 0 0 2.364 Tests Name Status Type Time(s) Local Player - MPEG-1 Success 0.845 Local Player - MPEG -2 Success 0.232 Local Player - DivX Success 0.289 Local Player - Xvid Success 0.194 Local Player – H.263 Success 0.161 Local Player - jpeg Success 0.090 Local Player - wav Success 0.186 Local Player - mp2 Success 0.216 Local Player - mp3 Success 0.132 Tabla 6.5. Pruebas de reproducción en local Para las pruebas en remoto se ha implementado la clase StreamingTest : Class piplayer.junit.StreamingTest Name Tests Errors Failures Time(s) StreamingTest 3 0 0 1.577 Tests Name Status Type Time(s) HTTP test Success 1.070 RTSP test Success 0.109 RTP test Success 0.381 Tabla 6.6. Pruebas de reproducción en remoto 6.2. Prueba de sistema: caso de estudio 95 6. Pruebas Para probar el sistema completo se ha implementado un caso de estudio, es decir, un canal multimedia con una aplicación interactiva asociada. El canal desarrollado se podría catalogar como canal de teleeducación bajo demanda. Se trata de una charla tecnológica, en la que además de ver al profesor explicando la materia, el usuario cuenta con una aplicación que le presenta de forma sincronizada al vídeo las transparencias de la charla. El nombre del canal será "How Computer Works", debido a que el contenido de la versa sobre el funcionamiento de los ordenadores. El vídeo se ha obtenido de aduni.org [ADUNI]. Se ha elegido este contenido porque se distribuye con licencia Creative Commons bajo las condiciones de: • Reconocimiento. Debe reconocer y citar al autor original. • Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. El autor del curso es Gill Pratt. Es la persona que imparte el curso. La charla es en inglés. Este hecho es idóneo a los requisitos de piPlayer. El contenido del curso está disponible en http://aduni.org/courses/hcw/. El vídeo es un fragmento de la charla de una duración de 5 minutos y 17 segundos. Está codificado con Xvid para el vídeo y MP3 a 85 Kbps para audio. El formato contenedor es AVI. Figura 6.1. How Computer Works La aplicación interactiva asociada se ha bautizado con el nombre de Snapshots Interactive Application (SIA, aplicación interactiva de transparencias). Se instrumenta 96 6. Pruebas con un frame en el que van apareciendo las transparencias del curso en perfecta sincronía con el vídeo. Aunque el usuario haga saltos en la ejecución o pausas el sincronismo se sigue manteniendo. Esto se consigue gracias al método de eventos implementado. Para cada transparencia el usuario dispondrá de una caja de texto donde puede ir cogiendo notas y/o apuntes. De esta forma se consigue disponer de una especie de cuaderno interactivo en la que el usuario sólo tiene que prestar atención a la clase y tomar las notas que considere oportunas. Figura 6.2. Snapshots IA Cuando acaba la reproducción, bien porque se llega al final del fichero o bien porque el usuario se le brinda al usuario la posibilidad de imprimir las transparencias junto a las notas que haya tomado. De esta forma el usuario, al acabar la "clase" tendrá en papel o fichero el contenido de las transparencias con sus notas personales. Se puede ver un ejemplo de esta impresión en el anexo 8.3 del presente documento. 6.3. Pruebas de calidad El objetivo principal de la ingeniería del software es desarrollar un sistema, aplicación o producto de calidad. Para lograr este objetivo, los ingenieros de software deben aplicar métodos efectivos junto con herramientas dentro del contexto de un proceso maduro de desarrollo del software. Además, un buen ingeniero del software debe medir si la alta calidad se va a llevar acabo. 97 6. Pruebas La calidad de un producto software es tan importante como los requisitos que describen el problema, el diseño que modela la solución, el código que conduce a un programa ejecutable y las pruebas que ejercitan el software para detectar errores. Un buen ingeniero del software debe utilizar mediciones que evalúan la calidad del análisis y los modelos de diseño, el código fuente y los casos de prueba que se han creado al aplicar la ingeniería del software. Para lograr esta evaluación de la calidad, se deben utilizar medidas técnicas que evalúan la calidad con objetividad, no con subjetividad. En este proyecto ha utilizado la herramienta Teaminabox como herramienta para generar métricas. La elección de esta herramienta se debe al hecho de que se utiliza el IDE Eclipse como entorno de desarrollo. Usar esta herramienta supone durante la programación de las diferentes clases que componen la aplicación ayuda a mejorar la calidad final. Esto es así porque aparecen alertas en eclipse (warnings) cuando se superan ciertos límites en las métricas. Esta retroalimentación de errores ayuda a detectar y corregir los errores en el momento de cometerlos, de forma que no se propagan hasta el final del proyecto, cuando realizar demasiados cambios en el código es una tarea cuando menos peligrosa. El resumen de datos de la implementación se desglosa como sigue: • • • • • • Número de líneas de código Número de paquetes Número de clases Número de interfaces Número de métodos Número de atributos 3146 12 61 9 288 161 A continuación se muestran de forma gráfica las métricas obtenidas, con una explicación de cada una de ellas. 6.3.1. Complejidad ciclomática La complejidad ciclomática es una métrica software que determina de manera cuantitativa la complejidad lógica de un programa. Esta medida está basada en la teoría de grafos y nos da una métrica de software muy útil. 98 6. Pruebas Figura 6.3 Complejidad ciclomática En esta gráfica se observa que hay un valor fuera de rango completamente. Este error es debido a la clase Ps4PiSoapBindingStub. Se trata del stub de comunicaciones para los servicios web. Esta clase es generada con la herramienta WSDL2Java de AXIS. Es por ello que la programación no es manual, sino automática. Se ha optado por aceptar este valor de complejidad ciclomática ya que tampoco influye en el funcionamiento de la aplicación, y no modificar la clase Ps4PiSoapBindingStub. Figura 6.4. Warnings en Eclipse 99 6. Pruebas 6.3.2. Acoplamiento eferente Esta métrica mide el número de clases dentro del paquete que dependen de otras clases fuera del mismo. Figura 6.5. Acoplamiento eferente Vuelve a aparecer un valor fuera de rango para esta métrica, y la clase responsable de esto vuelve a ser Ps4PiSoapBindingStub: Figura 6.6. Otro warning en Eclipse 100 6. Pruebas 6.3.3. Pérdida de cohesión Chidamber-Kemerer Esta métrica indica la calidad de la abstracción hecha en las clases. Usa el concepto de grado de similitud de métodos. Si no hay atributos comunes, el grado de similitud es cero. Una baja cohesión incrementa la complejidad y por tanto la facilidad de cometer errores durante el proceso de desarrollo. Estas clases podrían probablemente ser divididas en dos o más subclases aumentando la cohesión de las clases resultantes. Es deseable una alta cohesión en los métodos dentro de una clase, ya que ésta no se puede dividir fomentando el encapsulamiento. [HENDERSONSELLERS1996] Figura 6.7. Pérdida de cohesión Chidamber-Kemerer 6.3.4. Número de niveles Esta métrica es una indicación del número máximo de niveles jerárquicos en un método. Un valor elevado en esta métrica indica mayor complejidad y menor comprensibilidad. 101 6. Pruebas Figura 6.8. Número de niveles 6.3.5. Número de líneas de código Esta métrica mide el número de líneas en los métodos. Una línea viene determinada por la aparición del carácter de fin de línea. Si el resultado de esta métrica es elevado puede ser interesante plantearse refactorizar código. Figura 6.9. Número de líneas de código 102 6. Pruebas En esta gráfica y por tercera vez la clase Ps4PiSoapBindingStub vuelve a obtener mala nota en cuanto las métricas se refiere. Se puede ver claramente el warning “Lines of Code in Method is 65” de la figura 6.4. Conclusión: los desarrolladores de AXIS no han tenido en cuenta métricas a la hora de programar la herramienta WSDL2Java, o bien han utilizado rangos muy permisivos. 6.3.6. Número de campos Número de atributos por clase. Figura 6.10. Número de campos 6.3.7. Número de parámetros Esta métrica mide el número de parámetros pasados a los diferentes métodos de las clases. 103 6. Pruebas Figura 6.11. Número de parámetros 104 7. Conclusiones 7. Conclusiones En este apartado se exponen las conclusiones obtenidas de la realización de este proyecto. También se detalla el grado de cumplimiento de los objetivos planteados en un primer momento. Por último, se explican las limitaciones observadas en el sistema desarrollado, así como las líneas de trabajo futuras para el sistema. 7.1. Trabajo desarrollado Este proyecto está situado en un marco muy específico. El sistema desarrollado es un reproductor de vídeo ofrecido a través de pasarela residencial. El sistema en cuestión tiene dos variables de valor añadido, que son la personalización y la interactividad. Además, el sistema debía ser desarrollado siguiendo la filosofía de código abierto (open source). Vamos a analizar todos estos factores por partes. Es un sistema que pretende dar soluciones de reproducción de vídeo. El servicio prestado por el sistema no se encuadra dentro la televisión digital. Es un servicio convergente, a medio camino entre el sector audiovisual, las comunicaciones y la informática. Dado a que el la convergencia es un proceso bastante actual, los sectores que surgen son siempre novedosos, y las tecnologías implicadas no tienen el grado de madurez más deseable para un desarrollo cómodo. Es un sistema ofrecido por pasarela residencial. Como sabemos, la pasarela residencial es el elemento que conecta el hogar digital con el exterior (Internet), además de proveer servicios hacia el interior (redes domóticas). La domótica es un sector que aunque no es nuevo, nunca ha acabado de explotar del todo. En cuanto a la pasarela residencial, sí que es un elemento bastante novedoso. Además de todo esto, el sistema desarrollado en este proyecto debe ser libre. Esto significa que debe usar software libre y debe ser licenciado como tal. Este hecho hace que este el ciclo de vida del piPlayer no se limite al período de tiempo de desarrollo de este Proyecto Fin de Carrera. Es muy posible que el proyecto sea adoptado por la comunidad opensource, y que se realicen nuevas versiones y mejoras. El desarrollo del sistema ha sido bastante difícil, debido a que es una pieza que tiene que encajar con otras en diferentes aspectos. Debe ser una solución convergente a la reproducción de vídeo, pero muy cercano a la TV Digital. Debe ser un sistema que va a ser ejecutado en una pasarela residencial, concretamente con tecnología OSGi. Además de esto, debe ser una aplicación libre. Teniendo en cuenta estos tres pilares, la solución obtenida para el problema planteado es bastante satisfactoria. El sistema desarrollado, el reproductor piPlayer responde con hechos a los objetivos marcados: • Reproducción de vídeo: Se ha conseguido reproducir la gran mayoría de formatos multimedia, tanto en local como remoto (por medio de la tecnología de streaming). Además, se deja el reproductor abierto al cambio, ya que cuenta con la posibilidad de adoptar nuevos algoritmos de codificación-decodificación (codec) debido a su capacidad de registrar codecs y demás plugins. • Interactividad: Se ha acuñado el concepto de canal interactivo, entendido como la asociación entre multimedia y aplicaciones, sincronizadas en el tiempo mediante un mecanismo de generación-recepción de eventos. Este modelo de canales permite 105 7. Conclusiones dotar de un gran dinamismo a la aplicación, ya que todo cambio en el registro en cuanto a canales (registro y desregistro) tiene constatación directa en el aplicación. • Personalización: Se ha acuñado otro concepto, el de perfil. Un perfil es obtenido previa autenticación del usuario, y brinda a éste acceso a un conjunto de canales entre los disponibles en la pasarela. En las primeras etapas del desarrollo de este Proyecto Fin de Carrera, los conceptos ahora expuestos no existían. Se tenía una idea más o menos clara de lo que se quería hacer, pero no se sabía exactamente cómo poder hacerlo. El desarrollo de piPlayer y todos los componentes asociado ha supuesto un ejercicio de ingenio para conseguir los objetivos. Ha sido necesario el aprendizaje de muchas nuevas tecnologías, de las cuales por supuesto no se tenía ningún conocimiento. Es por ello que la realización de este proyecto no ha sido nada sencilla, pero ahora que se han solucionado todos los problemas y se dispone por fin del sistema final funcionando, se puede decir que ha merecido la pena todo el esfuerzo. Por último, hay que destacar el hecho de haber participado en un proyecto de software libre. Ha sido una experiencia difícil pero a la vez muy gratificante. El mundo de código abierto tiene cierta barrera de entrada, ya que requiere de conocimientos técnicos altos para la mayoría de procesos. Pero una vez superada esta barrera, es un mundo casi sin límites. Maravilla descubrir la cantidad de proyectos libres que se desarrollan en cooperación en todo el mundo, y es realmente interesante sentirse parte de uno. Éste proyecto en particular, además de ser un proyecto con filosofía opensource forma parte de un proyecto europeo, con lo cual la satisfacción es doble, ya que la posibilidad de que la aplicación llegue a entornos de producción es bastante alta. 7.2. Cumplimiento de objetivos El objetivo general de este proyecto era desarrollar un sistema software capaz de recibir contenidos audiovisuales digitales, personales e interactivos a través de una pasarela residencial OSGi. Todo el sistema se debía ensamblará a partir de componentes de código abierto. De este objetivo principal se derivaban otros más específicos. A continuación se detalla el grado de cumplimiento: • Hacer un estudio del estado del arte: Efectivamente se ha realizado un estudio de las tecnologías, estándares, etc., que guardan relación con el desarrollo del sistema de este proyecto. Se han cubierto las tres líneas maestras de investigación: convergencia en el sector audiovisual, hogar digital/pasarela residencial, y por último software libre. Ha sido una tarea bastante dura, ya que existe mucha documentación al respecto de cada uno de los tres frentes de investigación. La realización de esta tarea ha supuesto tenido como fruto principal el aprendizaje. • Definir los requisitos funcionales y no funcionales del sistema. Con los objetivos primeros marcados para la realización de este proyecto, y tras el estudio del estado del arte no fue nada complicado definir los requisitos (funcionales y no funcionales) para el sistema a desarrollar. • Realizar un diseño e implementación del sistema. Ha sido la parte que más tiempo ha llevado, como no podía ser de otra forma. Se ha usado un ciclo de vida combinado, una mezcla entre ciclo de vida e iterativo incremental. Esto se ha hecho así debido a que no se tenía claro desde un primer momento como iban a ser los resultados. Por esto se iban desarrollando prototipos a los que se le iban añadiendo nuevas funciones y módulos. El resultado ha sido un ciclo de vida muy dinámico y altamente recomendable en desarrollo de sistemas complejos a priori como este. 106 7. Conclusiones • Comprobar la validez del sistema. Se han desarrollado pruebas unitarias como medio de probar la validez de los diferentes módulos. Estas pruebas han hecho las veces de pruebas de integración con el resto de módulos en el ciclo de vida de la aplicación. Al final, se ha desarrollado un caso de estudio que es en sí la demostración de la validez del sistema. 7.3. Limitaciones Ni que decir tiene que este sistema no es ideal. Como todos los sistemas, son mejorables. A continuación se describen las limitaciones observadas. Como principal fuente de discordia está el núcleo de la reproducción de vídeo, la API JMF. Esta API de SUN ofrece soluciones pero también problemas. Se eligió esta API por las siguientes razones: • Al ser java, todo el sistema se desarrollaría preferentemente en este lenguaje. Recordemos que las aplicaciones OSGi (bundles) están programadas en java. • Su estructura basada en plugins la hacia perfecta para garantizar un sistema abierto y escalable. • Se encontraron codecs (Fobs, mp3plugin, jffmpeg) que extendían la funcionalidad de JMF, con lo que se podrían reproducir la mayoría de los formatos de más extendidos en la actualidad. Estas razones eran suficientes para elegir JMF como tecnología de reproducción de vídeo. Ahora bien, hay problemas inherentes a su uso: • Es una API propietaria de SUN que se distribuye con licencia SCSL. Es una licencia compleja, pero no es compatible del todo con la filosofía opensource. La alternativa libre a JMF sería como por ejemplo la desarrollada por Blackdown. El problema está en que esta implementación de JMF para Linux desde Blackdown, se encuentra deshabilitada desde Agosto del 2002. • Reproducción RTSP reducida. Los formatos soportados se limitan a los formatos que se pueden codificar con indicaciones para streaming. Por otro lado, es una limitación clara el consumo de recursos. Es necesario que el equipo donde se ejecute piPlayer cuente con recursos suficientes de procesamiento y memoria. Esto es debido a la decodificación multimedia realizada vía software. 7.4. Trabajo futuro Aunque piPlayer es una aplicación que acaba de nacer, ya está perfectamente claro cual va a ser su evolución. Esto es debido a que su marco de referencia es el proyecto europeo ITEA Osmose. • Login programático, mediante eventos de tarjeta JavaCard conectada al sistema. De este modo se sustituirá la autenticación vía login/password para hacerlo con una tarjeta. • Despliegue de canales filtrando por código de usuario. • Integración del sistema sobre un entorno de escritorio (desktop) de Telvent, además de funcionamiento standalone sobre OSGi. [TELVENT] 107 7. Conclusiones • Extensión del modelo de aplicaciones interactivas, adaptado al entorno gráfico de Telvent. • Cambio de canales mediante un mando a distancia. De esta manera se consigue hacer el reproductor más sencillo de usar, acercándose más al modo tradicional de funcionamiento de la televisión. • Enriquecimiento del sistema de eventos para instrumentar la interactividad. Se podrán capturar, enviar y recibir eventos de usuario, además de los eventos propios de la reproducción multimedia. • Implantación de un sistema de gestión de dependencias para los diferentes bundles que compoenten del sistema. Además de estas nuevas funciones que están claras, piPlayer puede tener otras vías de crecimiento. Esto es así porque va a ser liberado con licencia LGPL, de modo que las futuras versiones vendrán marcadas por las necesidades de hipotéticos desarrolladores de software libre. 108 8. Anexos 8. Anexos En este apartado de la memoria se adjunta un compendio de anexos. El primero de ellos se trata del manual de usuario, necesario para la instalación y manejo de la aplicación por cualquier usuario. El segundo anexo es una reproducción exacta de la impresión que realiza la aplicación interactiva (snapshots IA) del canal interactivo (How Computer Works) desarrollado como caso de estudio para probar el sistema. En tercer lugar se presentan los ficheros wsdd necesarios para el despliegue de servicios web en AXIS. El cuarto anexo es una estructura de todos los ficheros fuentes programados en el proyecto, y por último se dedica un apartado a la licencia elegida para publicar el sistema, esta es la licencia LGPL. 8.1. Manual de usuario A continuación se detalla un completo manual de usuario. Se dan los pasos necesarios para poder instalar correctamente la aplicación. También se describe el funcionamiento completo del sistema. 8.1.1. Introducción En el siguiente manual se describe el funcionamiento de piPlayer (Personal Interactive Player), que es un sistema de reproducción de vídeo, personal e interactivo. Este sistema se ha diseñado para funcionar sobre una pasarela residencial OSGi, concretamente en un framework OSCAR. Por tanto, todos los componentes de este sistema que se ejecutan bajo dicho framework son bundles. Hay conceptos importantes en el ámbito de esta aplicación. Son los siguientes: • CANAL: Un canal es el conjunto formado por un contenido multimedia y con aplicaciones interactivas asociadas a los mismos. • PERFIL: Un perfil es la unidad de personalización del sistema. Para obtener un perfil es necesaria la autenticación con credenciales del tipo login+password contra un servidor remoto. Cuando se obtiene un perfil se conceden permisos de acceso a determinados canales • PLUGIN: Componentes software necesarios para la reproducción multimedia. 8.1.2. Instalación 8.1.2.1. JVM Es necesario recordar que esta aplicación esta programada en lenguaje java. Los bundles son ficheros JAR. De este modo lo primero que se debe hacer para instalar es cerciorarse que se tiene instalada una máquina virtual java (JVM). La versión requerida de la JVM es la 1.4.2. Ver http://java.sun.com/j2se/1.4.2/index.jsp 8.1.2.1. OSCAR Una vez instalada la JVM, se debe proceder a instalar el framework OSCAR. Hay tres requisitos para ejecutar OSCAR para piPlayer: 109 8. Anexos 1.- Exportar una variable llamada LD_LIBRARY_PATH, que es donde estarán ubicados las librerías nativas de reproducción de vídeo. 2.- Crear un fichero en la raíz del fichero personal (/home/username/) llamado .jmfdir. El contenido de este fichero es la ruta en el que se encuentra el fichero jmf.properties, que registra los plugins de JMF. 3.- Ejecutar OSCAR pasándole como parámetros de la máquina virtual el fichero piplayer.system.properties. Si se desea se puede automatizar estas tres tares con el script ./oscar.sh: LD_LIBRARY_PATH=/demo/lib export LD_LIBRARY_PATH exec java -Doscar.system.properties=piplayer.system.properties -jar lib/oscar.jar ... dónde piplayer.system.properties: oscar.auto.start.1=file:bundle/shell.jar file:bundle/shelltui.jar file:bundle/bundlerepository.jar oscar.auto.install=file:/demo/bundles/axis-bundle.jar file:/demo/bundles/jmfbundle.jar file:/demo/bundles/jmf-extras-bundle.jar Figura 8.1. Consola OSCAR (inicio) Si se desea ejecutar la aplicación de esta forma, es necesario crear la siguiente estructura de ficheros: /demo/bundles /demo/lib /demo/media ... siendo el contenido de estos directorios: 110 8. Anexos /demo/bundles axis-bundle.jar channels.jar channels2.jar dia.jar eia.jar jmf-bundle.jar jmf-extras-bundle.jar piplayer.jar sia.jar /demo/lib jmf.properties libfobs4jmf.so libjmcvid.so libjmdaud.so libjmfjawt.so libjmg723.so libjmgsm.so libjmh261.so libjmh263enc.so libjmjpeg.so libjmmpa.so libjmmpegv.so libjmmpx.so libjmutil.so libjmv4l.so libjmxlib.so /demo/media video1.mpg xvid_mp3.avi audio1.mp3 audio2.mp3 El vídeo xvid_mp3.avi corresponde al contenido multimedia del canal "How Computer Works" (licencia Creative Commons). Se puede descargar con el resto de aplicaciones. Una vez hecho esto, hay que desplegar el bundle piplayer y el/los bundles de canales: > install file:/demo/bundles/piplayer.jar > start 7 111 8. Anexos Figura 8.2. Consola OSCAR (instalación del bundle piPlayer) Con la ejecución de la última línea (start 7) debe aparecer la interfaz gráfica de usuario de piPlayer. Figura 8.3. GUI piPlayer Para instalar el/los bundles de canales, se ejecutan los siguientes comandos en la consola OSCAR: 112 8. Anexos > install file:/demo/bundles/channels.jar > start 8 Figura 8.4. Consola OSCAR (instalación del bundle channels) En este momento ya se habrán desplegado las aplicaciones interactivas. Se pueden ver con el comando ps en la consola OSCAR: Figura 8.5. Consola OSCAR (despliegue de aplicaciones interactivas) 113 8. Anexos De igual manera, si se desinstala el bundle de canales, desaparecen dichas aplicaciones: Figura 8.6. Consola OSCAR (desinstalación del bundle channles) 8.1.2.3. Servicios web Para instrumentar la autenticación y el acceso a los canales, es necesario desplegar el servicio web de autenticación en un contenedor de servicios web. El elegido para realizar las pruebas ha sido AXIS/TOMCAT. Hay que realizar dos pasos: 1.- Arrancar el servidor TOMCAT con AXIS 2.- Registrar el servicio ps4pi (personal server for piPlayer) De manera análoga a lo anterior, se puede proceder a ejecutar los scripts que automatizan las tareas. Para lanzar el servidor, se debe ejecutar ./start_tomcat. Hay que ser cuidadoso de que los siguientes valores sean correctos: TOMCAT_HOME=/home/boni/jakarta-tomcat-4.1.27 export JAVA_HOME=/home/jose/dev_boni/j2sdk1.4.2_08/ exec $TOMCAT_HOME/bin/startup.sh Siendo JAVA_HOME el directorio de la JVM (debe ser la distribución de SUN, requisito de TOMCAT) y TOMCAT_HOME el directorio de instalación de TOMCAT (con AXIS). Para registrar el servicio se puede usar el script ./register_service. Este script copia el servicio ps4pi al directorio de despliegue de servicios web de AXIS en TOMCAT y se registra el servicio web mediante el descriptor de despliegue de servicios web (wsdd). 114 8. Anexos AXIS_HOME=/home/boni/jakarta-tomcat-4.1.27/webapps/axis/WEB-INF/classes cp -r ps4pi/server/ps4pi $AXIS_HOME exec $JAVA_HOME/java -cp .:./lib/activation.jar:./lib/mail.jar:./lib/axisant.jar:./lib/axis.jar:./lib/commons-discovery.jar:./lib/commonslogging.jar:./lib/jaxrpc.jar:./lib/log4j1.2.8.jar:./lib/saaj.jar:./lib/wsdl4j.jar org.apache.axis.client.AdminClient p8080 ps4pi/server/ps4pi/deploy.wsdd Figura 8.7. Consola GNU/Linux (arranque Tomcat y despliegue del servicio web) Con esto debe quedar finalizado el despliegue del servicio web y ya se está en disposición de ejecutar la aplicación con todas sus funciones. Si se desea eliminar el ./unregister_service: servicio registrado, se puede usar el script JAVA_HOME=/home/boni/j2sdk1.4.2_08/bin exec $JAVA_HOME/java -cp .:./lib/activation.jar:./lib/mail.jar:./lib/axisant.jar:./lib/axis.jar:./lib/commons-discovery.jar:./lib/commonslogging.jar:./lib/jaxrpc.jar:./lib/log4j1.2.8.jar:./lib/saaj.jar:./lib/wsdl4j.jar org.apache.axis.client.AdminClient p8080 ps4pi/server/ps4pi/undeploy.wsdd 115 8. Anexos Figura 8.8. Consola GNU/Linux (anulación del despliegue del servicio web) 8.1.3. Reproducción de vídeo Para la mera reproducción de vídeo no intervienen ni los servios web ni los canales. Las funciones son las siguientes: Figura 8.9. Menú de reproducción multimedia 116 8. Anexos Player -> Open Local File (Ctrl+O): Abrir archivo en local Figura 8.10. Abrir fichero en local Player -> Open RTP Session (Ctrl+R): Abrir sesión RTP Figura 8.11. Abrir sesión RTP Al intentar iniciar una sesión RTP se inicia un temporizador. Si vence el temporizador antes de iniciar la sesión RTP, se entenderá que la conexión no se puede realizar, y se notificará al usuario mediante el siguiente mensaje: Figura 8.12. Mensaje de temporizador vencido Player -> Open URL (Ctrl+U): Abrir URL. Los formatos aceptados de URL son dos: Figura 8.13. Mensaje de reproducción remota http://maquina:puerto/directorios/fichero rtsp://maquina:puerto/directorios/fichero 117 8. Anexos Véase dos ejemplos de reproducción (vídeo y audio respectivamente): Figura 8.14. Reproduciendo vídeo y audio Una vez que se esté reproduciendo, se pueden usar dos funciones: Player -> Stop (Ctrl+W): Termina la reproducción Player -> Full Screen (Ctrl+W): Pantalla completa (no en ficheros de sólo audio) Figura 8.15. Reproducción a pantalla completa 118 8. Anexos Previa a la reproducción, se puede marcar la opción: Player -> Auto Loop ... si se desea que la reproducción sea en bucle (comience de nuevo al llegar al final del archivo). 8.1.4. Canales interactivos Para reproducir canales interactivos en primer lugar es necesario obtener un perfil, esto es, mandar credenciales login-password correctas. Esto se hace en la opción de menú "Profile": Figura 8.16. Menú de autenticación de usuario En un primer momento, no se ha obtenido ningún perfil de usuario. Es por esto que la opción de menú "Channels" está vacía. Cuando se autentique al usuario aquí aparecerán los canales correspondientes al perfil. 119 8. Anexos Figura 8.17. Menú de canales (vacío en un primer momento) Las credenciales válidas para ps4pi son: #1 login: root password: root -> Acceso a los canales 1,2,3,4,5 y 6 #2 login: user1 password: user1 -> Acceso a los canales 1,2 y 3 #3 login: user2 password: user2 -> Acceso a los canales 4,5 y 6 #4 login: user3 password: user3 -> Acceso a los canales 1,2 y 7 Se corresponde con el contenido del fichero ps4pi.properties (en el directorio /ps4pi1.0/ps4pi/server/ps4pi): user1=root|root|1|2|3|4|5|6 user2=user1|user1|1|2|3 user3=user2|user2|4|5|6 user4=user3|user3|1|2|7 Las credenciales se introducen en "Profile -> Login": 120 8. Anexos Figura 8.18. Cuadro de dialogo para introducir usuario y contraseña Si se introduce una pareja de usuarios no válida el mensaje de error será el siguiente: Figura 8.19. Usuario incorrecto Si no se ha desplegado el servicio web de autenticación se obtiene este otro mensaje: Figura 8.20. Servicio de autenticación no disponible Si todo ha ido correcto, el mensaje es el siguiente: Figura 8.21. Autenticación correcta ... y además se desplegarán los canales interactivos (se notifica en la barra de estado de la aplicación): 121 8. Anexos Figura 8.22. Servicio de autenticación no disponible Para desligarse del perfil introducido con el login se procede con "Profile -> Logout": Figura 8.23. Desconexión del perfil De esta forma dejan de estar disponibles los canales. Este hecho es indicado mediante un mensaje en la barra de estado de la aplicación: 122 8. Anexos Figura 8.24. Eliminación de los canales 8.1.4.1. How Computer Works Este canal es el caso de estudio principal de la aplicación. Es canal educativo de vídeo bajo demanda, con el valor añadido de una aplicación de transparencias sincronizado con el contenido multimedia. Además, esta aplicación interactiva permite ir tomando notas a modo de apuntes en cada transparencia. Figura 8.25. Multimedia de How Computer Works 123 8. Anexos Figura 8.26. Snapshots Interactive Application Cuando se decide acabar la visualización se llega al final del mismo, la aplicación interactiva pregunta al usuario si desea imprimir las transparencias con sus notas. Figura 8.27. Petición de impresión 8.1.5. Panel de control El acceso al panel de control está disponible desde File -> Preferences (Ctrl-P): 124 8. Anexos Figura 8.28. Opción de menú “Archivo” Este panel de control de piPlayer permite configurar los plugins JMF (demultiplexer, codec, effect, renderer, multiplexer). Figuras 8.29, 8.30, 8.31 y 8.32. Panel de control 125 8. Anexos IMPORTANTE: Para poder modificar la lista de plugins es necesario tener acceso de escritura sobre el fichero jmf.properties. Siguiendo la notación dada, este fichero se encontraría en /demo/lib. Además, el panel de control permite cambiar el idioma de toda la aplicación simplemente modificando una opción. Para que los cambios sean efectivos será necesario reiniciar la aplicación (no es necesario reiniciar OSCAR, solamente piPlayer) Figura 8.33. Multiidioma 8.1.6. Interfaz gráfica La opción de menú "View" permite modificar la apariencia de la interfaz gráfica de usuario. Figura 8.34. Menú de interfaz gráfica 126 8. Anexos Se permiten eliminar los elementos de la misma, hacer más grandes los botones, y modificar el fondo de la aplicación. Figura 8.35, 8.36 y 8.37. Diferentes apariencias Por último, la opción de menú "Help" brinda el acceso a la ayuda online, así como el panel de “Acerca de”. Figura 8.38. Acerca de 127 8. Anexos 8.2. Impresión de snapshotsIA En este anexo se muestra el resultado de imprimir las transparencias de la aplicación interactiva snapshotsIA, perteneciente al canal “How Computer Works”, tratado en el caso de estudio. 128 8. Anexos 129 8. Anexos 130 8. Anexos 131 8. Anexos 132 8. Anexos 133 8. Anexos 8.3. Ficheros de despliegue de servicios web deploy.wsdd <!-<!-<!-<!-<!-<!-<!-- Use this file to deploy some handlers/chains and services Two ways to do this: java org.apache.axis.client.AdminClient deploy.wsdd after the axis server is running or java org.apache.axis.utils.Admin client|server deploy.wsdd from the same directory that the Axis engine runs --> --> --> --> --> --> --> <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <!-- Services from LoginService WSDL service --> <service name="ps4pi" provider="java:RPC" style="rpc" use="encoded"> <parameter name="wsdlTargetNamespace" value="urn:ps4pi" /> <parameter name="wsdlServiceElement" value="LoginService" /> <parameter name="wsdlServicePort" value="ps4pi" /> <parameter name="className" value="ps4pi.Ps4PiSoapBindingImpl" /> <parameter name="wsdlPortType" value="Login" /> <parameter name="typeMappingVersion" value="1.2" /> <operation name="login" qname="operNS:Login" xmlns:operNS="urn:ps4pi" returnQName="LoginReturn" returnType="rtns:ArrayOf_soapenc_string" xmlns:rtns="urn:ps4pi" soapAction=""> <parameter qname="in0" type="tns:string" xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/" /> <parameter qname="in1" type="tns:string" xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/" /> </operation> <operation name="logout" qname="operNS:Logout" xmlns:operNS="urn:ps4pi" soapAction="" /> <parameter name="allowedMethods" value="login logout" /> <parameter name="scope" value="Session" /> <typeMapping xmlns:ns="urn:ps4pi" qname="ns:ArrayOf_soapenc_string" type="java:java.lang.String[]" serializer="org.apache.axis.encoding.ser.ArraySerializerFactory" deserializer="org.apache.axis.encoding.ser.ArrayDeserializerFactory" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </service> </deployment> undeploy.wsdd <!-<!-<!-<!-<!-<!-<!-- Use this file to undeploy some handlers/chains and services Two ways to do this: java org.apache.axis.client.AdminClient undeploy.wsdd after the axis server is running or java org.apache.axis.utils.Admin client|server undeploy.wsdd from the same directory that the Axis engine runs <undeployment xmlns="http://xml.apache.org/axis/wsdd/"> <!-- Services from LoginService WSDL service --> <service name="ps4pi" /> </undeployment> 134 --> --> --> --> --> --> --> 8. Anexos 8.4. Estructura de ficheros fuente piplayer Activator.java Main.java Locator.java PiPlayer.java PlayerListener.java WindowCloser.java gui About.java ContentPanel.java ControlPanel.java FrameElements.java FrameSettings.java HomePanel.java ImageFactory.java LoginDialog.java MainFrame.java MainPanel.java MediaPanel.java MenuBar.java PluginsPanel.java PluginType.java ProtocolPanel.java RtpDialog.java SettingsPanel.java Splash.java StatusBar.java ToolBar.java UrlDialog.java osgi ApplicationNotFoundException.java ChannelAdmin.java ChannelAdminDummyImpl.java ChannelAdminImpl.java ChannelListener.java ChannelListenerImpl.java ChannelNotAvailableException.java VideoEventSourceDummyImpl.java VideoEventSourceImpl.java services Channel.java VideoEvent.java VideoEventListener.java VideoEventSource.java webservices Login.java LoginService.java LoginServiceLocator.java Ps4PiSoapBindingStub.java 135 8. Anexos player ChannelControl.java Fobs.java FullScreen.java Listener.java LocalPlayer.java RtpListener.java Stop.java Streaming.java TimeoutListener.java tools Language.java Message.java XMLFactory.java junit LocalPlayerTest.java LoginTest.java StreamingTest.java VideoEventTest.java channel Activator.java ChannelImpl.java dummyIA ActivatorDIA.java echoIA ActivatorEIA.java snapshotsIA ActivatorSIA.java CloserSIA.java FrameSIA.java PanelSIA.java PrintSIA.java SnapSIA.java 136 8. Anexos 8.5. Licencia LGPL Como se indicó en los requisitos no funcionales, se debe publicar el sistema con la licencia de código abierto LGPL (GNU Lesser General Public License). [LGPL] La diferencia con la licencia GPL es que la LGPL permite enlazar con código no LGPL, mientras que con GPL no se puede. Esto hace de LGPL una licencia muy flexible. En todos los componentes desarrollados en este proyecto se ha añadido la siguiente cabecera. De esta forma se informa al hipotético usuario que piPlayer se distribuye bajo licencia LGPL: piPlayer (Personal Interactive Player) Copyright (C) 2005 DIT Telematics Engineering Department UPM Technical University of Madrid This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 137 9. Presupuesto 9. Presupuesto Este proyecto se ha desarrollado dentro del Departamento de Ingeniería de Sistemas Telemáticos de la Universidad Politécnica de Madrid. A continuación se dividen los costes de ejecución material en costes de equipamiento (o costes materiales) y costes de mano de obra. 9.1. Costes materiales El DIT cuenta ya con el equipo de trabajo utilizado para el desarrollo del prototipo y la realización de las pruebas del mismo. Se calculará la amortización de este material, incluyendo en “costes generales” el suministro eléctrico, el material fungible y de comunicaciones. Concepto Precio 1 PC sobremesa Pentium IV 1,7 GHz 1 PC barebone VIA C3 Ezra Costes generales TOTAL 1.200,00 € 800,00 € Período de Período amortización de uso 36 meses 12 meses 36 meses 12 meses 36 meses 12 meses 1866,67 € Coste 400,00 € 266,67 € 1.200,00 € Tabla 9.1. Costes materiales 9.2. Costes de mano de obra En este proyecto ha intervenido un solo Ingeniero Superior de Telecomunicación que se ha encargado de realizar las diferentes tareas que engloba. A continuación se desglosan dichas tareas indicando su duración aproximada, para seguidamente calcular el coste derivado de su realización. Tarea Estudio del sector audiovisual Estudio del hogar digital Estudio del software libre Análisis de requisitos del sistema Elección de las herramientas a utilizar Diseño del sistema general Diseño del módulo de reproducción multimedia Implementación del módulo de reproducción multimedia Pruebas del módulo de reproducción multimedia Diseño del módulo de interactividad Implementación del módulo de interactividad Pruebas del módulo de reproducción interactividad Diseño del módulo de personalización Implementación del módulo de personalización Pruebas del módulo de personalización Pruebas de sistema (caso de estudio) Escritura de la memoria TOTAL Tabla 9.2. Tareas y tiempos de ejecución 138 Horas 110 horas 70 horas 50 horas 40 horas 40 horas 40 horas 35 horas 95 horas 35 horas 35 horas 90 horas 30 horas 35 horas 80 horas 30 horas 85 horas 400 horas 1300 horas 9. Presupuesto Multiplicando el tiempo total por el sueldo por hora de un ingeniero, se obtiene el coste total de la mano de obra. Responsable Ingeniero Superior de Telecomunicaciones Tiempo 1300 horas Coste 30 €/hora Total 39.000,00 € Tabla 9.3. Costes de la mano de obra 9.3. Gastos generales Se consideran gastos generales las amortizaciones, las cargas fiscales y jurídicas y gastos de instalación, que se valoran en el 15% del presupuesto de ejecución material. 9.4. Presupuesto total La siguiente tabla resume el presupuesto total necesario para la realización de este proyecto. 1.866,67 € 39.000,00 € 6.130,00 € 7.519,47 € 54.516,13 € Coste material Coste de mano de obra Gastos generales (15%) I.V.A. (16%) PRESUPUESTO TOTAL Tabla 9.4. Presupuesto total De este modo, el presupuesto total del proyecto alcanza la cifra de CINCUENTA Y CUATRO MIL QUINIENTOS DIECISEIS EUROS CON TRECE CÉNTIMOS. Madrid, 28 de junio de 2005 EL INGENIERO PROYECTISTA Bonifacio García Gutiérrez 139 10. Referencias 10. Referencias En este capítulo se detallan todas las referencias bibliográficas consultadas para la realización del proyecto. En esta memoria se ha ido haciendo alusión a las mismas mediante la palabra entre corchetes que identifica el recurso consultado. [AAC] Codificación de audio avanzada. http://www.aac-audio.com [ACUNIA] Sitio web de la compañía Acunia. http://www.acunia.com [ADUNI] Cursos online bajo licencia Creative Commons http://aduni.org [APPLE] Web de la compañía Apple. http://www.apple.com [APSL] Licencia Apple Public Source License. http://www.opensource.apple.com/apsl [ANT] Herramienta de construcción Java. http://ant.apache.org [AVELINK] Página web de aveLink Embedded Gateway. http://www.atinav.com/osgi/index.htm [AVIDEMUX] Editor de audio/vídeo. http://fixounet.free.fr/avidemux [AXIS] Web Services open source. http://ws.apache.org/axis [BARRAPUNTO] Noticias sobre tecnología y software libre. http://barrapunto.com [BIT118] Radio y Televisión Digital. Sección especial del número 118 (noviembrediciembre 1999) de la revista electrónica BIT, editada por el COIT/AEIT (Colegio Oficial/Asociación Española de Ingenieros de Telecomunicación). http://www.coit.es/publicac/publbit/bit118/especial.html [BIT133] Televisión Digital Terrestre. De los problemas técnicos a los jurídicos. Marta García Vallejo, César Rico, Antonio Marcos y Dionisio Oliver. Sección ‘Café de redacción’ del número 133 (mayo-junio 2002) de la revista electrónica BIT, editada por el COIT/AEIT (Colegio Oficial/Asociación Española de Ingenieros de Telecomunicación). http://www.coit.es/publicac/publbit/bit133/cafe.htm [BIT140] Modelos de televisión. Julio Alba. Sección ‘Qué es’ del número 140 (agostoseptiembre 2003) de la revista electrónica BIT, editada por el COIT/AEIT (Colegio Oficial/Asociación Española de Ingenieros de Telecomunicación). http://www.coit.es/publicac/publbit/bit118/especial.html 140 10. Referencias [BOOCHRUMBJACOB1999] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modelling Language User Guide. Addison-Wesley Pub. Co , 1999. [CASADOMO] Portal de domótica y hogar digital. http://www.casadomo.com [CREATIVECOMMONS] creativecommons.org: Copyright flexible http://creativecommons.org [DEVICETOP] Página web de Espial Device Top. http://www.espial.com/index.php?page=prod_devicetop_over [DEBIAN] Distribución GNU/Linux Debian. http://www.debian.org [DIVX] Web sobre productos DivX. http://www.divx.com [DIVX-DEUX] Web dedicada al formato DivX. http://www.divx-deux.com [DIVXNETWORKS] Compañía que desarrolla el formato de vídeo DivX. http://www.divxnetworks.com [DOLBY] Web de Dolby. http://www.dolby.com [DOOM9] Guía sobre multimedia. http://doom9.org [DOMOTICA.NET] Portal de domótica en español. http://www.domotica.net [DOMOTICAVIVA] Portal de domótica en español. http://www.domoticaviva.com [DSS] Servidor de streaming Darwin. http://developer.apple.com/darwin/projects/streaming [DVB] Consorcio DVB. Sitio web del consorcio DVB. http://www.dvb.org [DVBCOOK] ‘Cookbook’ del DVB. Guía general de los estándares del DVB. http://portal.etsi.org/broadcast/cookbook.asp [ECLIPSE] Plataforma Eclipse http://www.eclipse.org [ECLIPSEARCH] El Archipiélago Eclipse http://www.javahispano.org/articles.article.action?id=75 [FEDORA] Web del Fedora Project http://fedora.redhat.com [FFMPEG] Editor de audio/vídeo. 141 10. Referencias http://ffmpeg.sourceforge.net [FLAC] Web de FLAC, codec de audio sin pérdidas del proyecto OGG. http://flac.sourceforge.net [FOBS] Plugins para JMF. http://fobs.sourceforge.net [GIMP] The GNU Image Manipulation Program. http://www.gimp.org [GRET2000] GRETEL. Convergencia, Competencia y Regulación en los Mercados de las Telecomunicaciones el Audiovisual e Internet. Ed. COIT. Madrid 2000. [GNU] GNU’s Not Unix. http://www.gnu.org [HENDERSONSELLERS1996] Henderson-Sellers, measures of complexity, Prentice-Hall, 1996. B., Object-oriented metrics [HISPALINUX] Linux en español. http://www.hispalinux.es [HOWCOMPUTER] How Computer Works (licencia Creative Commons). http://aduni.org/courses/hcw/ [IBM] Página web oficial de IBM. http://www.ibm.com [ITV] Diccionario de la TV interactiva. http://www.itvdictionary.com [JAVADOC] Herramienta de generación de documentación a partir de código Java. http://java.sun.com/j2se/javadoc [JAVALIBRE] Java y Software Libre, ¿Realidad o Ficción? http://www.javahispano.org/articles.article.action?id=77 [JDK] Java Developer's Kit http://java.sun.com/j2se [JEFFREE] Sitio web de Java Embedded Framework FREE. http://jeffree.objectweb.org [JES] Página web de Java Embedded Server de Sun. http://www.sun.com/software/embeddedserver [JFFMPEG] Codecs adicionales para JMF. http://jffmpeg.sourceforge.net [JMF] Java Media Framework API http://java.sun.com/products/java-media/jmf [JUNIT] Testing Resources for Extreme Programming. http://www.junit.org 142 10. Referencias [KDE] K Desktop Environment http://www.kde.org [KNOPFLERFISH] Sitio web de Knopflerfish. http://www.knopflerfish.com [KNOPPIX] Distribución GNU/Linux contenida en un CD. http://www.knoppix.org [LBHOGARDIGITAL2003] Telefónica de España, “Libro blanco del Hogar Digital y las Infraestructuras Comunes de Telecomunicaciones” http://www.fundacion.telefonica.com/publicaciones/libro_blanco/libro_blanco.htm [LBSWLIBRE2004] Libro Blanco del software libre en España. Implantación del software libre en la sociedad y en especial en la administración pública. http://www.libroblanco.com [LGPL] GNU Lesser General Public License. http://www.gnu.org/licenses/lgpl.html [OBJECTWEB] Sitio web del consorcio ObjectWeb. http://www.objectweb.org [OS4OS] Open Software for Open Services. http://forge.os4os.org [OSCAR] Sitio web de Open Service Container Architecture. http://oscarosgi.sourceforge.net [OSMOSE] Sitio web del proyecto OSMOSE http://www.itea-osmose.org [PROSYST] Página web de ProSyst. http://www.prosyst.com [QT4LINUX] Editor de audio/vídeo. http://heroinewarrior.com/cinelerra.php3 [MANDRIVA] Distribución Mandriva, antes conocida como Mandrake. http://www.mandrivalinux.com [MARPKRI2001] The Open Services Gateway Initiative: An Introductory Overview. Marples y Kriens. IEEE Communications Magazine, Volume 39, Issue 12, 2001. [MUNDODIVX] Manuales on-line sobre DivX, MPEG, DVD, etc. http://www.mundodivx.com/mpeg/index.php [MATROSKA] Web de matroska, formato contenedor estándar de audio/vídeo abierto y extensible. http://www.matroska.org [MATROSKA.INFO] Información sobre el formato contenedor Matroska. http://www.matroska.info 143 10. Referencias [MHPVIGO] Sistema de recepción digital multimedia. Trabajo sobre MHP realizado por el Grupo de Ingeniería de Software (GRIS) de la Universidad de Vigo. http://mhp.det.uvigo.es/mhp [MICROSOFT] Web de la compañía Microsoft. http://www.microsoft.com [MOCK] Endo-Testing: Unit Testing with Mock Objects. eXtreme Programming and Flexible Processes in Software Engineering - XP2000. Mackinnon, Tim; Freeman, Steve; Craig, Philip. [MPEG] Sitio dedicado a los estándares MPEG. http://www.mpeg.org [MPEG-GROUP] Página web oficial de MPEG. http://www.chiariglione.org/mpeg [MP3PLUGIN] Codec para reproducir MP3 con JMF. http://java.sun.com/products/java-media/jmf/mp3/download.html [MP3PRO] Web de MP3pro. http://www.mp3prozone.com [MPLAYERDOC] MPlayer: el reproductor de películas para Linux. http://www.mplayerhq.hu/DOCS/HTML/es/index.html [MURILLO2002] Alberto Murillo. Hacia la Televisión Digital. Comunicaciones World nº 165 (febrero de 2002) y nº 168 (junio de 2002) http://www.albertomurillo.com [NEWELL2002] An introduction to MHP 1.0 and MHP 1.1. J.C. Newell. Mayo 2002. Research & Development British Broadcasting Corporation. [OGG] Web del Proyecto Ogg http://www.xiph.org/ogg [OPENOFFICE] OpenOffice en español http://es.openoffice.org [OSGi] Sitio web oficial del consorcio OSGi. http://www.orgi.org [OSGiTV] OSGiTV: une plate-forme de dçeploiement d-applications de télévision interactive basée sur OSGi. Stéphan Chomat, Didier Donsez. Laboratorio LSR, Instituto IMAG, Universidad Joseph Fourier. Octubre de 2003. http://www-adele.imag.fr/~donsez/pub/publi/papier_osgitv_cfse2003.pdf [POSEIDON] Poseidon for UML. Herramienta de análisis y diseño. http://www.gentleware.com [QUICKTIME] Producto multimedia de Apple. http://www.apple.com/quicktime [REALAUDIO] Guía de RelaAudio en la web. http://www.realaudio.com 144 10. Referencias [REALNETWORKS] Web de la compañía RealNetworks, http://www.realnetworks.com [REDHAT] Red Hat Linux. http://www.redhat.com [REGULTVD] La regulación de la televisión digital. Estudio de los aspectos más importantes de la TVD realizado por el Grupo de Tecnologías de la Información y las Comunicaciones (GTIC), perteneciente a la Escuela Técnica Superior de Ingenieros de Telecomunicación (ETSIT) de la Universidad Politécnica de Madrid (UPM). http://www.gtic.ssr.upm.es/soci/regulaci/tvdigital/tvdigital.htm [RRSSMD] Apuntes de la asignatura Redes y Servicios Multimedia Domésticos. Asignatura impartida por el GATE. Profesor responsable: Rubén de Diego Martínez http://casafutura.diatel.upm.es/rrssmd [RTSP] RFC 2326 - RTSP: Real Time Streaming Protocol http://www.ietf.org/rfc/rfc2326.txt [SDP] RFC 2327 - SDP: Session Description Protocol http://www.faqs.org/rfcs/rfc2327.html [SERVICETANGO] Página web de ServiceTango. http://servicetango.sourceforge.net [SLACKWARE] http://www.slackware.com [SMF] Página web de Service Management Framework de IBM. http://www.ibm.com/software/wireless/smf [SPEEX] Web de Speex, codec para el habla del proyecto OGG. http://www.speex.org [SUN] Página web oficial de Sun Microsystems. http://www.sun.com [SUSE] Distribución GNU/Linux SUSE. http://www.novell.com/linux/suse [TEAMINABOX] Control de métricas y generación de estadísticas http://www.teaminabox.co.uk [TELVENT] The Global Real Time IT Company http://www.telvent.com [TERRATVD] Odisea 2010 o lo que falta para la televisión digital. Ana Bedia. Artículo sobre TVB publicado en la sección ‘eNegocios’ del portal Terra, el 26 de enero de 2004. http://www.terra.es/tecnologia/articulo/html/tec10390.htm [THEORA] Web oficial del formato de vídeo Theora, del proyecto OGG. www.theora.org 145 10. Referencias [TOMCAT] Servidor de Java Servlets y JSPs del proyecto Yakarta http://jakarta.apache.org/tomcat [TRANSCODE] Editor de audio/vídeo. http://freshmeat.net/projects/transcode [TVD] Folleto informativo sobre TV digital: "Adaptarse hoy para la nueva Televisión". Editado por la Secretaria de Estado de Telecomunicaciones y para la Sociedad de la Información (SETSI) del Ministerio de Ciencia y Tecnología. http://www.setsi.mcyt.es/sgcinfor/tv_dig.pdf [TVDSI] Seminario sobre Televisión Digital y Sociedad de la Información. Evento internacional celebrado entre el 12 y 14 de mayo de 2003 en Antigua (Guatemala). Organizado por la Secretaria de Estado de Telecomunicaciones y para la Sociedad de la Información (SETSI) del Ministerio de Ciencia y Tecnología. http://www.setsi.mcyt.es/eventos/antigua/programa.htm [TVDI] TV Digital Interactiva en España. Portal de TVD interactiva. http://www.tvdi.net [TVS] Tecnología y Servicios de TV Digital por Satélite. Claudio Feijóo González, Luis Castejón Martín, Ana Vía Mélich y Jorge Pérez Martínez. Artículo para su publicación en Global Communications. 12 de mayo de 1997. http://www.gtic.ssr.upm.es/artihtm/arttecno.htm [VIDEOCONF] Recetarios de videoconferencia http://www.videnet.gatech.edu/cookbook.es [VIDEOLAN] Soluciones de software libre para streaming. http://www.videolan.org [VOIPINFO] Web dedicada a la voz sobre ip. http://www.voip-info.org [VORBIS] Web sobre el formato de audio libre OGG VORBIS. http://www.vorbis.com [WEBITV] The Interactive TV Web. Web dedicada a los estándares abiertos de de televisión interactiva. http://www.mhp-interactive.org [WSUNIT] The Web Services Testing Tool https://wsunit.dev.java.net [XIPH] Web de la fundación Xiph.org http://xiph.org [XVID] Web oficial de XviD http://www.xvid.org 146 11. Glosario 11. Glosario Por último se adjunto una colección de los acrónimos utilizados en esta memoria. Se adjunta tanto la descripción en español como en inglés (si la hubiera). A AAC: Codificación de audio avanzada (Advanced Audio Coding). ABR: Tasa binaria disponible (Available Bit Rate). AC3: Codificación de audio 3 (Audio Coding 3). ADSL: Línea Digital de Abonado Asimétrica (Asymmetric Digital Subscriber Line). AIT: Tabla de información de aplicación (Application Information Table). AoD: Audio bajo demanda (Audio-on-Demand). AFX: Entorno de ejecución para animaciones (Animation Framework eXtension). AMI: Adaptador Multimedia Interactivo. APSL: Licencia de código público Apple (Apple Public Source License). ASF: Formato avanzado de streaming (Advanced Streaming Format). ASP: Perfil Simple Avanzado (Advanced Simple Profile). ATSC: Comité Avanzado de Sistemas de Televisión (Advanced Television Systems Committee). AVC: Codificación de vídeo avanzada (Advanced Video Coding). AVI: Entralazado de audio y vídeo (Audio Video Interleave). AXIS: Sistema de interacción extensible de Apache (Apache EXtensible Interaction System). B BD: Base de datos (DataBase). BIT: Tabla de Información de Bundles (Bundle Information Table). bps: Bits por segundo. Bps: Bytes por segundo. C CA: Acceso Condicional (Conditional Access). CAT: Tabla de Acceso Condicional. CBR: Tasa binaria constante (Constant Bit Rate). CD: Disco Compacto (Compact Disk). CD-ROM: Memoria de Sólo Lectura en formato de Disco Compacto (Compact Disc Read Only Memory). CEN: Comité Europeo de Normalización (Comité Européen de Normalisation). CENELEC: Comité Europeo de Normalización Electrotécnica (Comité Européen de Normalisation Electrotechnique). CIF: Formato Intermedio Común: 352x288 (Common Intermidiate Format). CPU: Unidad Central de Proceso (Central Process Unit). CU: Casos de Uso. CVCD: VCD comprimido (Compressed Video CD). CVD: Disco de vídeo chino (China Video Disc). CVS: Sistema de versiones concurrentes (Concurrent Versions System). D DAM: Dispositivo de Gestión de Acceso (Device Access Manager). 147 11. Glosario DAVIC: Consejo de Audiovisual Digital (Digital Audio Visual Council). DECT: Telecomunicaciones Inalámbricas Digitales Mejoradas (Digital Enhanced Cordless Telecommunications). DIA: Aplicación interactiva tonta (Dummy Interactive Application). DIT: Tabla de Información de Drivers (Driver Information Table). DIT: Departamento de Ingeniería de Sistemas Telemáticos. DMIF: Entorno de integración de entrega multimedia (Delivery Multimedia Integration Framework). DSM-CC: Medio de almacenamiento digital, comando y control (Digital Storage Medium Command and Control). DSS: Servidor de Streaming Darwin (Darwin Streaming Server). DVB: Difusión de Vídeo Digital (Digital Video Broadcasting). DVD: Disco de Vídeo Digital (Digital Video Disk). E EBU: Unión Europea de Difusión (European Broadcasting Union). EIA: Aplicación interactiva de eco (Echo Interactive Application). EPG: Guía Electrónica de Programa (Electronic Program Guide). ES: Elemento Básico de Flujo (Elementary Stream). ETSI: Instituto Europeo de Normalización de las Telecomunicaciones (European Telecommunications Standards Institute). ETSIT: Escuela Técnica Superior de Ingenieros de Telecomunicación. ETV: TV Mejorada (Enhanced TV). F FDL: Licencie de Documentación Libre (GNU Free Documentation License). FSF: Fundación para el Software libre (Free Software Foundation). G GDSP: Gatespace Distributed Service Platform. GIMP: Programa de manipulación de imágenes GNU (GNU Image Manipulation Program). GNU: GNU No es Unix (GNU’s Not Unix). GPL: Licencia Pública General GNU (GNU General Public License). GSM: Sistema Global para comunicaciones Móviles (Global System for Mobile communications). GUI: Interfaz Gráfico de Usuario (Grafic User Interface). H HAVi: Interoperabilidad Audiovisual en el Hogar (Home Audio Video Interoperability). HAN: Red del Hogar (Home Area Network). HDTV: Televisión de Alta Definición (High Definition TV). HFC: Redes Hibridas de Fibra/Coaxial (Hibrid Fiber/Coax). HTTP: Protocolo de Transferencia de HiperTexto (HyperText Transfer Protocol). HW: Hardware. Hz: Hertzios. I 148 11. Glosario IA: Aplicación Interactiva (Interactive Application). IDE: Entornos de Desarrollo Integrado (Integrated Development Environments). IDTV: Televisor Digital Integrado (Integrates Digital Television). IEC: Comisión Electrotécnica Internacional (International Electrotechnical Commission). IP: Protocolo Internet (Internet Protocol). IPMP: Protección y gestión de propiedad intelectual (Intellectual Property Management and Protection). IRD: Receptor Decodificador Integrado (Integrated Receiver Decoder). ISDN: Red Digital de Servicios Integrados, RDSI (Integrated Services Digital Networks). ISO: Organización Internacional para la Estandarización (International Organization for Standardization). ISP: Proveedor de Servicios de Internet (Internet Service Provider). ITU: Unión Internacional de Telecomunicaciones (International Telecommunications Union). iTV: Televisión Digital Interactiva (Interactive TV). J JAR: Archivo Java (Java Archive). JDK: Kit de Desarrollo Java (Java Development Kit). JDT: Herramientas de desarrollo java (Java Development Tools). JES: Java Embedded Server. JINI: Infraestructura de Red Inteligente Java (Java Intelligent Network Infraestructure). JTC: Comité Técnico Combinado (Joint Technical Committee). JMF: Plataforma Multimedia Java (Java Media Framework) JPEG: Grupo Experto en Imágenes (Join Photographers Experts Group). JRE: Entorno de Ejecución Java (Java Runtime Environment). JSEE: Extensión de Seguridad para Sockets Java (Java Secure Sockets Extensión) JVM: Máquina Virtual Java (Java Virtual Machine). K KVCD: VCD comprimido dinámicamente (K Video Compression Dynamics). KDE: Entorno de escritorio molón (Kool Desktop Environment). L LGPL: Licencia Pública General Menor (GNU Lesser General Public License). LMDS: Sistema de Distribución de Microondas Local (Local Microwave Distribution System). M MDCT: Transformada discreta modificada del coseno (Modified Discrete Cosine Transform). MHEG: Grupo de Expertos en Codificación de Información Multimedia e Hipermedia (Multimedia and Hypermedia Information Coding Experts Group). MHP: Plataforma Doméstica Multimedia (Multimedia Home Plataform). MJPEG: JPEG en movimiento (Motion JPEG). MPEG: Grupo de expertos en imágenes en movimiento (Moving Picture Experts Group). 149 11. Glosario MPEG-TS: Flujo de Transporte MPEG (MPEG Transport Stream). MMDS: Sistema de Distribución de Microondas Multipunto (Multipoint Microwave Distribution System). MP1: MPEG-1 layer 1. MP2: MPEG-1 layer 2. MP3: MPEG-1 layer 3. N NTSC: Comité nacional de estándares de televisión (National Television Standards Committee). NIT: Tabla de Información de la Red. O OCAP: Plataforma para Aplicaciones de OpenCable (OpenCable Application Plataform). OGM: OGg Media. OS4OS: Software abierto para servicios abiertos (Open Software for Open Services). OSGi: Iniciativa de Pasarela para Sistemas Abiertos (Open System Gateway Initiative). OSMOSE: Software intermedio de código abierto para sistemas abiertos en Europa (Open Source Middleware for Open Systems in Europe). OTF: Open Telematics Framework. P PAL: Alternancia de fase en línea (Phase Alternation Line). PAT: Tabla de Asociación de Programas. PDE: Kit de desarrollo de conectores (Plug-in Development Kit). PC: Ordenador Personal (Personal Computer). PCM: Modulación de impulsos codificados (Pulse Code Modulation). PCMCIA: Asociación Internacional de Tarjetas de Memoria para Ordenador Personal (Personal Computer Memory Card International Association). PES: Paquetes de Flujo Elemental (Packetized Elementary Stream). PFC: Proyecto Fin de Carrera. PID: Identificador de Paquete (Packet IDentifier). piPlayer: Reproductor Personal e Interactivo (Personal Interactive Player). PJava: Java Personal (Personal Java). PMT: Tabla de Mapa de Programas. PnP: Conectar y Usar (Plug aNd Play). PS: Flujo de program (Program Stream). PS4PI: Servidor personal para piPlayer (Personal Server For piPlayer). PSI: Información Específica de Programa (Program Specific Information). PSTN: Red Telefónica Conmutada Pública, RTC o RTB (Public Switched Telephone Networks). PVR: Grabador de Vídeo Personal (Personal Video Recorder). pTV: Televisión Personal (Personal TV). Q QCIF Quarter CIF: 176x144. 150 11. Glosario R RF: Requisito Funcional. RFC: Petición de Comentarios (Request For Comments). RNF: Requisito No Funcional. RTP: Protocolo de Tiempo Real (Real Time Protocol). RTCP: Protocolo de Control de Tiempo Real (Real Time Control Protocol). RTSP: Protocolo de transferencia en tiempo real (Real Time Streaming Protocol). RTVE: Radio Televisión Española. S SBR: Replicación de banda de espectro (Spectral Band Replication). SCSL: Licencia de fuentes de la comunidad Sun (Sun Community Source License). SDK: Kit de desarrollo estándar (Standard Development Kit). SDP: Protocolo de Descripción de Sesión (Session Description Protocol). SG: Servidor de Pasarela (Service Gateway). SI: Sociedad de la Información. SI: Información de Servicio. SIA: Aplicación interactiva de transparencias (Snapshots Interactive Application). SO: Sistema Operativo (Operative System). SOAP: Protocolo de acceso fácil a objetos (Simple Object Access Protocol). SMF: Service Management Framework. SMTP: Protocolo de transferencia simple de correo (Simple Mail Transfer Protocol). SQCIF Sub-Quarter CIF: 128X96. SSL: Capa de Seguridad para Sockets (Secure Sockets Layer) STB: Set-Top Boxes. SVCD: Super Vídeo CD. SW: Software. T TCP: Protocolo de Control de Transmisión (Transmission Control Protocol). TDT: Televisión Digital Terrestre. TIC: Tecnologías de la Información y las Comunicaciones. TLS: Capa de Seguridad de Transporte (Transport Layer Security). TS: Flujo de transporte (Transport Stream). TV: Televisión. TVD: Televisión Digital. U UDDI: Especificación universal de descripción, descubrimiento e integración (Universal Description, Discovery and Integration specification). UDP: Protocolo de Datagramas de Usuario (User Datagram Protocol). UML: Lenguaje Unificado de Modelado (Unified Model Language). UPM: Universidad Politécnica de Madrid. UPnP: PnP Universal (Universal PnP). V VBR: Tasa binaria variable (Variable Bit Rate). 151 11. Glosario VCR: Grabador de Casetes de Vídeo (Video Cassette Recorder). VCD: Vídeo CD. VDSL: Línea Digital de Abonado de muy Alta (Very High date rate Digital Subscriber Line). VOB: Objetos de vídeo (Video Objects). VoD: Vídeo bajo demanda (Video-on-Demand). VoIP: Voz sobre IP (Voice over IP). W WAV: Formato audio de forma de onda (WAVEform audio format). WMA: Formato Windows de audio (Windows Media Audio). WMV: Formato Windows de vídeo (Windows Media Video). WSDL: Lenguaje de descripción de servicios web (Web Services Description Language). X xDSL: Diferentes variaciones de DSL (Línea de Usuario Digital, Digital Suscriber Line), tales como ADSL, VDSL, etc. XML: Lenguaje extensible de marcado (eXtensible Markup Language). XP: Programación extrema (Extreme Programming). WSDD: Descriptor de despliegue de servicios web (Web Service Deployment Descriptor). XVCD: VCD extendido (Extended Video CD). Y Z 152