Download dit/UPM - Universidad Politécnica de Madrid

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