publicidad interactiva para televisión móvil - IIT

Anuncio
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
PUBLICIDAD INTERACTIVA PARA
TELEVISIÓN MÓVIL
AUTOR:
DIRECTOR:
Elena Dolores Gutiérrez García
Ricardo Martínez Grazziani
MADRID, Junio 2007
AGRADECIMIENTOS
En primer lugar, quiero dar las gracias a mi director porque me ha ofrecido una
gran ayuda en la realización del proyecto. Sobre todo, ha sabido darme ideas para
resolver aquellos problemas que parecían irresolubles. Además, me ha propuesto la
realización de muchas mejoras de cara a la aplicación con el fin de que el resultado
fuese el mejor posible.
Agradecer a Fran su apoyo continuo y, particularmente, sus préstamos
temporales de ordenador.
A mi tía y a mi madre por preocuparse por la evolución del proyecto y darme
ánimos.
Y en general a todas aquellas personas que han mostrado interés por conocer el
estado del proyecto.
I
RESUMEN
Con la aparición de la televisión móvil digital, los usuarios pueden acceder a los
contenidos televisivos desde cualquier dispositivo portátil, como teléfonos móviles o
PDAs, en cualquier lugar donde puedan estar.
Los contenidos televisivos que reciba el usuario mediante este tipo de televisión
pueden estar dotados con posibilidades atractivas de interactividad: descargas de logos,
tonos, música, videoclips, enlaces a más información, encuestas, votaciones, venta de
productos, contenidos publicitarios, etc. Dentro de estos contenidos auxiliares
interactivos se incluye la publicidad interactiva para la televisión móvil. Dicha
publicidad puede presentar diferentes opciones de interactividad: comprar un
determinado producto, dirigir al usuario a la página web del anunciante, descargas, etc.
De hecho, para las campañas de marketing de muchas industrias, las compañías
han optado por la telefonía móvil, sustituyendo a la fija, pues los nuevos usos de estos
teléfonos posibilitan una nueva forma de marketing más directa y efectiva. Esto es
debido a que ningún otro medio de comunicación viaja en el bolsillo del cliente, está
encendido diez horas al día, admite sonidos, imágenes y videos, tiene una penetración
superior al 90 por ciento de la población (en España), es interactivo y además permite
realizar pagos de una forma segura como el teléfono móvil.
Aunque la idea de insertar publicidad ha tardado en llegar a la telefonía, se prevé
que la publicidad en teléfonos móviles crecerá el 50% de los valores actuales en los
próximos cinco años. Por otro lado, se estima que el número de usuarios de televisión a
través del móvil pase de 40 millones en 2006 a 750 millones en 2011. Por este motivo
la publicidad jugará un papel clave en el desarrollo de los canales de TV móvil, hasta
que se conviertan en un servicio de importancia para el consumidor.
Por tanto, hoy en día la publicidad en el móvil es una forma de marketing más
directa y efectiva que cualquier otro medio publicitario. Por ese motivo, actualmente ya
muchas compañías han optado por entregar sus contenidos publicitarios a través de este
medio. Por otro lado, la televisión en el móvil es un servicio que se encuentra
II
implantado actualmente en muy pocos países pero, sin embargo, se prevé que a corto
plazo sea implantado en muchos países. Es un servicio novedoso y, por los estudios y
encuestas realizados, parece que será aceptado y utilizado por muchos de los usuarios de
telefonía móvil. Dentro de este marco también es posible la inclusión de publicidad, por
lo que las diferentes empresas deberán considerar la televisión en el móvil como un
nuevo medio para poder ofrecer sus contenidos publicitarios.
Este proyecto se centra en los contenidos publicitarios para la televisión en el
móvil. A lo largo del documento se realiza un estudio sobre qué tecnologías están
relacionadas con este tema. Una vez analizadas dichas tecnologías, se propone una
arquitectura que engloba la creación de contenidos publicitarios para este medio,
técnicas de vinculación de contenidos interactivos y contenidos principales,
mecanismos que se pueden utilizar para entregar dichos contenidos a los terminales
móviles, tecnologías que permiten visualizar dichos contenidos en los dispositivos y,
por último, técnicas que se pueden utilizar para entregar a los usuarios sólo aquellos
contenidos publicitarios que sean de su agrado. No obstante, aunque el proyecto se
centra en los contenidos publicitarios, en algunos casos también se han considerado
otros tipos de contenidos auxiliares como pueden ser las votaciones que pueden estar
relacionadas con un contenido televisivo (por ejemplo, una votación del tipo Gran
Hermano que permita al usuario votar por aquella persona a la que desee expulsar de la
casa).
Dentro de esta arquitectura se han desarrollado dos aplicaciones que cubren la
creación de contenidos interactivos tanto publicitarios como de votaciones: una de las
aplicaciones debe ser utilizada por el proveedor de contenidos y la otra por el proveedor
de servicios. El proveedor de contenidos no tiene por qué conocer la tecnología
necesaria para crear los contenidos interactivos publicitarios. Con su aplicación puede
crear documentos XML que incluyan la información de los contenidos publicitarios (por
ejemplo, texto del anuncio, imagen del mismo, link para acceder a la página web del
anunciante, etc). Este fichero XML es enviado al proveedor de servicios que, a partir de
la información incluida en el mismo y con ayuda de su aplicación, es capaz de generar
el contenido interactivo auxiliar definitivo con la tecnología necesaria.
III
ABSTRACT
With the appearance of digital mobile television, the users can access to the
television contents from any portable device, as wireless telephones or PDAs, in any
place where they can be.
The television contents that the user receives by means of this television type
can be endowed with attractive possibilities of interactivity: discharges of logos, tones,
music, videoclips, connections to more information, surveys, votings, sale of products,
advertising contents, etc. inside these interactive auxiliary contents the interactive
publicity is included for mobile television. This publicity can present different
interactivity options: to buy a certain product, to direct to the user to the advertiser's
page web, discharges, etc.
In fact, for the campaigns of marketing of many industries, the companies have
opted for the mobile telephony, substituting to the fixed one, because the new uses of
these telephones facilitate a new form of more direct and more effective marketing. This
is because no other means of communication travels in the client's pocket, it is lit ten
hours a day, it admits sounds, images and videos, it has a superior penetration to the
population's 90 percent (in Spain), it is interactive and it also allows to carry out
payments in a sure way as the wireless telephone.
Although the idea of inserting publicity has taken in arriving to the telephony,
they predict that the publicity in wireless telephones 50% of the current values will
grow in next five years. On the other hand, it is considered that the number of television
users through the mobile passes of 40 millions in 2006 to 750 millions in 2011. For this
reason the publicity will play a key paper in the development of the channels of mobile
TV, until they become a service of importance for the consumer.
Therefore, today in day the publicity in the motive is a form of more direct and
more effective marketing that any other one half advertising. For that reason, at the
moment already many companies have opted to give their advertising contents through
this means. On the other hand, the mobile television is a service that is implanted at the
IV
moment in very few countries but, however, they predict that short term it is implanted
in many countries. It is a novel service and, for the studies and carried out surveys, it
seems that it will be accepted and used by many of the users of mobile telephony. Inside
this mark it is also possible the inclusion of publicity, for what the different companies
will consider the mobile television as a new means to be able to offer their advertising
contents.
This project is centered in the advertising contents for mobile television. Along
the document it is carried out a study on what technologies they are related with this
topic. Once analyzed this technologies, it intends an architecture that includes the
creation of advertising contents for this means, technical of linking of interactive
contents and main contents, mechanisms that can be used to give this contents to the
mobile terminals, technologies that allow to visualize this contents in the devices and,
lastly, technical that can be used to only give the users those advertising contents that
are of their pleasure. Nevertheless, although the project is centered in the advertising
contents, in some cases they have also been considered other types of auxiliary contents
as they can be the votings that can be related with a television content (for example, a
voting of the type Great Brother that allows the user to vote for that person to which
wants to expel of the house).
Inside this architecture two applications have been developed that cover the
creation of interactive contents so much advertising as of votings: one of the
applications should be used by the supplier of contents and the other one by the supplier
of services. The supplier of contents doesn't have why to know the necessary
technology to create the advertising interactive contents. With their application it can
create documents XML that include the information of the advertising contents (for
example, text of the announcement, image of the same one, link to consent to the
advertiser's page web, etc). This file XML is a correspondent to the supplier of services
that, starting from the information included in the same one and with the help of its
application, it is able to generate the definitive auxiliary interactive content with the
necessary technology.
V
ÍNDICE
1
INTRODUCCIÓN ...................................................................................... 1
1.1
LA PUBLICIDAD ......................................................................................... 2
1.2
MARKETING MÓVIL ................................................................................... 6
1.3
LA TELEVISIÓN EN DISPOSITIVOS MÓVILES ................................................ 9
1.4
LA PUBLICIDAD EN EL MÓVIL................................................................... 10
2
TECNOLOGÍAS RELACIONADAS ..................................................... 16
2.1
TECNOLOGÍAS HABILITADORAS DE RICH MEDIA ...................................... 18
2.2
GUÍAS DE PROGRAMACIÓN ...................................................................... 58
2.3
SISTEMAS DE VINCULACIÓN DE CONTENIDOS........................................... 73
2.4
TECNOLOGÍAS DE PRESENTACIÓN DE CONTENIDOS .................................. 75
2.5
TECNOLOGÍAS DE DISTRIBUCIÓN DE CONTENIDOS ................................... 81
2.6
TECNOLOGÍAS DE PERSONALIZACIÓN DE CONTENIDOS ............................ 90
3
ARQUITECTURA PROPUESTA: PUBLICIDAD PARA
TELEVISIÓN MÓVIL ......................................................................... 100
3.1
ARQUITECTURA PROPUESTA INICIAL ..................................................... 101
3.2
ARQUITECTURA PROPUESTA FINAL ........................................................ 105
3.3
IMPLEMENTACIÓN REALIZADA .............................................................. 109
4
APLICACIÓN ........................................................................................ 111
4.1
DESCRIPCIÓN ......................................................................................... 112
VI
4.2
GENERACIÓN DE PLANTILLAS SVG ....................................................... 114
4.3
GENERACIÓN DE PLANTILLAS XML ...................................................... 124
4.4
GENERACIÓN DE CONTENIDOS INTERACTIVOS ....................................... 126
4.5
VISOR SVG TINY .................................................................................. 130
4.6
IMPLEMENTACIÓN ................................................................................. 135
4.7
ESTUDIO FINANCIERO ............................................................................ 137
5
PILOTOS Y EXPERIENCIAS ............................................................. 138
5.1
PILOTO DVB-H EN ALCÁZAR DE SAN JUAN (CASTILLA LA MANCHA).. 139
5.2
PILOTO DE BÉLGICA MADUF ............................................................... 143
5.3
PILOTO DE LA REPÚBLICA CHECA ......................................................... 143
5.4
PILOTO DE PARÍS TDF........................................................................... 144
5.5
PILOTO DE PARIS CANAL +.................................................................... 145
5.6
PILOTO DE ALEMANIA ........................................................................... 145
6
CONCLUSIONES .................................................................................. 147
7
BIBLIOGRAFÍA .................................................................................... 150
8
ANEXOS ................................................................................................. 154
8.1
MANUAL DEL USUARIO .......................................................................... 155
8.2
ORGANISMOS DE ESTANDARIZACIÓN RELACIONADOS ........................... 181
8.3
APIS UTILIZADAS .................................................................................. 211
8.4
ACRÓNIMOS........................................................................................... 235
VII
Introducción
1 INTRODUCCIÓN
1.1 LA PUBLICIDAD
1.2 MARKETING MÓVIL
1.3 LA TELEVISIÓN EN DISPOSITIVOS MÓVILES
1.4 LA PUBLICIDAD EN EL MÓVIL
1
Introducción
1. Introducción
Introducción
Este proyecto se centra en la publicidad interactiva para la televisión en
dispositivos móviles. Para poder obtener una mejor comprensión del mismo en este
capítulo se describen nociones básicas de publicidad, marketing para dispositivos
móviles, televisión para dichos dispositivos y por último se realiza una breve
introducción a la publicidad en terminales móviles.
1.1 La publicidad
La publicidad es una técnica del marketing mix (mezcla de variables tácticas
controlables por la empresa que se utilizan para producir el resultado deseado en el
mercado objetivo) cuyo objetivo fundamental es crear imagen de marca, recordar,
informar o persuadir al público para mantener o incrementar las ventas de los bienes o
servicios ofertados. La publicidad hace uso de numerosas disciplinas tales como la
psicología, la sociología, la estadística, la comunicación social, la economía y la
antropología.
Los objetivos publicitarios pueden ser muy variados pero los más destacados son
los siguientes:
•
Incrementar el conocimiento de la marca. El conocimiento de la marca se mide
mediante encuestas. Efectuando una encuesta antes de la campaña publicitaria y
otra después, se puede comprobar el efecto de la publicidad en el conocimiento
de la marca.
•
Mejorar el conocimiento de las características del producto. En ocasiones es
preciso que los consumidores aprendan cómo se usa el producto. Otras veces
interesa que conozcan ciertas ventajas de un producto sobre los competidores.
•
Creación o mejora de una imagen de la empresa. Se mide también mediante
encuestas.
2
Introducción
•
Creación o mejora de la imagen del producto.
•
Conseguir una actitud o sentimiento más favorable respecto a la empresa o al
producto. Una primera etapa en el proceso de venta suele ser conseguir una
actitud favorable hacia la marca.
•
Aumentar las ventas a corto plazo. Muchas campañas de publicidad están
intentando mejorar las ventas en los días siguiente. Por ejemplo, la mayor parte
de las ventas de los libros, discos, juegos de ordenador y películas se generan en
unas pocas semanas a partir del lanzamiento. El lanzamiento con éxito de
muchos productos requiere una eficaz campaña de publicidad que logre vender
una gran cantidad de productos en las fechas inmediatamente posteriores.
•
Apoyar otras acciones de marketing. Ayudar al éxito de una promoción o apoyar
a los vendedores de la empresa. Por ejemplo conseguir que los consumidores
prueben el producto o incrementar las visitas de los vendedores o las ventas por
visita.
Los elementos fundamentales que intervienen en la publicidad son los
siguientes:
•
El anunciante: paga la publicidad.
•
Las agencias de publicidad: elaboran los mensajes. Buscan las mejores ideas y
las transforman en anuncios para televisión, prensa, radio, u otros medios.
•
Los medios de comunicación que son los vehículos para llevar la información.
La televisión, la radio y la prensa son, por ejemplo, medios de comunicación.
•
El público objetivo: la población que será receptora del mensaje.
La publicidad llega a su público objetivo a través de los medios de
comunicación. Entre ellos, podemos citar los siguientes:
•
Publicidad televisiva: sólo utilizable para productos o servicios de amplio
consumo. Se han introducido nuevas fórmulas como el patrocinio de programas
o recomendación de presentadores. Es sin lugar a dudas el mayor impacto en los
usuarios.
3
Introducción
•
Publicidad radiofónica: sigue siendo fundamental para amas de casa y jóvenes,
destacando su presencia en las emisoras musicales.
•
Publicidad en prensa y revistas: medio muy segmentado por su naturaleza:
existen revistas de niños, jóvenes, mujeres, profesionales, etc.
•
Publicidad exterior o vía pública: vallas, marquesinas, transporte público,
letreros luminosos, vallas, etc. Debe ser muy directa e impactante.
•
Publicidad en Punto de venta (PDV): se realiza por medio de displays, muebles
expositores, carteles, pósters, etc. que se sitúan en el lugar en el que se realizará
la venta. Es un refuerzo muy importante pues es allí donde se decide la compra.
•
Product Placement: es la presentación de marcas y productos de manera discreta
en películas de cine, programas de televisión, series, noticieros y similares. Esta
tendencia está comenzando a tomar el nombre de advertisement.
•
Publicidad Online: conformado por las campañas basadas en respuestas e
interactividad por parte de usuarios altamente focalizados. La tendencia apunta
hoy en día a la web 2.0. Es importante no confundir con simples anuncios de
banners o boletines informativos puesto que no son publicidad sino simples
anuncios sin estrategia.
Una de las teorías más antiguas de la publicidad (1895) es la teoría o regla
AIDA, nacida como simple recurso didáctico en cursos de ventas. Sus siglas
corresponden a las iniciales de Atracción, Interés, Deseo y Acción. Según esta regla
estos son los cuatro pasos básicos para que una campaña publicitaria alcance el éxito, es
decir, en primer lugar, hay que llamar la atención, después despertar el interés por la
oferta, seguidamente despertar el deseo de adquisición y, finalmente, exhortar a la
reacción u ofrecer la posibilidad de reaccionar al mensaje, derivando, generalmente, en
la compra.
Algunas estrategias para la realización de una publicidad efectiva son:
•
Asociación psico-emotiva al consumidor por medio de:
o Estética: imágenes, música, personas, etc.
o Humor.
4
Introducción
o Sentimientos: amor materno, enamoramiento, etc.
o Testimoniales: de unas figuras o personas famosas o reconocidas de
forma positiva o de personajes de asociación proactiva.
o Demostración: pruebas, tests, ensayos.
•
Oportunidad. el mensaje debería aprovechar el momento, coyuntura o situación
del tiempo de referencia.
•
Frecuencia. el consumidor comienza a retener un mensaje cuando este es
repetitivo.
•
Sinceridad. el fraude produce frustración en el consumidor.
•
Propuesta única de venta.
o Todo anuncio debe hacer una proposición concreta al consumidor.
o La proposición debe distinguirse de la competencia (ventaja competitiva,
elemento diferenciador o posicionamiento); esta es la condición más
importante.
o Debe ser tan atractiva que influya sobre la totalidad del mercado meta del
producto.
o Actualmente la proposición de venta es de carácter emocional.
La publicidad será objetiva si se cumple con unos objetivos que han sido fijados
de forma lógica y realista a priori del lanzamiento de la campaña publicitaria. Para fijar
los objetivos es necesario establecer la situación comercial previa de la empresa
anunciante y los efectos comerciales de la publicidad. Así, es posible vincular las ventas
con la publicidad porque es posible aislar el efecto específico de la publicidad. En este
sentido, el efecto de la publicidad es todo aquello que se puede manifestar en una
encuesta, como el recuerdo y actitudes. Además, para que las expectativas sean lógicas
es necesario saber la cuota de mercado y el porcentaje de las ventas propias con
respecto a la competencia.
5
Introducción
1.2 Marketing móvil
El Marketing es una forma de realizar negocios a través de la satisfacción de las
necesidades y los requerimientos de los clientes y los consumidores. Como forma de
negocios que es, tiene por obligación lograr valor para los dueños del negocio (socios o
accionistas) y forma parte inherente de la estrategia de negocios de la empresa. Se
encarga de estudiar todas las funciones que debe realizar una empresa para investigar
las necesidades del consumidor y traducir dicha información en la creación, producción
e introducción de nuevos productos del mercado, para lo cual se requiere desarrollar
actividades de investigación de mercados, planificación del producto, promoción de
ventas, ventas y distribución.
El marketing móvil es una subespecialidad del marketing que centra su actividad
en las campañas que se realizan a través de dispositivos móviles. Las actividades de este
tipo de marketing están autorreguladas por la industria a través de la Asociación Global
de Marketing Móvil o MMA (ver capítulo ANEXOS apartado Organismos de
estandarización relacionados subapartado MMA (Mobile Marketing Association)).
Entre las principales características y ventajas que presenta este tipo de
marketing están las siguientes:
-
Alcance y versatilidad: permite pasar del marketing masivo al marketing
one-to-one.
-
Ubicuidad e inmediatez: la tecnología permite personalizar el instante en que
el usuario recibe nuestro mensaje.
-
Interactividad: el mismo canal utilizado para contactar con el cliente puede
ser usado por éste para contestar y ponerse en contacto con la marca, de
modo que es posible establecer un canal de comunicación interactivo con el
usuario.
-
Conveniencia: los mensajes permiten acceder al cliente donde esté y a la
hora que esté.
-
Localización: la tecnología actual permite personalizar el lugar donde el
cliente recibe el mensaje y también lanzarlo sólo si el cliente se encuentra en
un determinado sitio.
6
Introducción
-
Rapidez y adaptabilidad: el tiempo necesario para poner en marcha una
campaña es mínimo y el feedback inmediato, permitiendo realizar cambios
de adaptación sobre la marcha.
1.2.1 Tipos de campañas publicitarias
En el marketing móvil existen dos tipos de campañas: las campañas Push y las
campañas Pull.
1.2.1.1 Campañas Push
Una campaña Push de marketing móvil es una acción de marketing directo que
utiliza el móvil como canal. Es una estrategia de comunicación poco desarrollada hasta
ahora, muy relacionada con el e-mail marketing y tiene numerosas posibilidades por su
gran aceptación: un 86% de los encuestados estaría de acuerdo en recibir publicidad a
través del teléfono móvil.
1.2.1.2 Campañas pull
Una campaña Pull es aquella en la que el público de interés de una marca inicia
el proceso de comunicación. Para generar el comienzo de esa interacción se necesita un
impacto publicitario a través de un medio tradicional así como ofrecer un incentivo.
•
Descarga de contenidos: los tipos de contenidos son melodías polifónicas,
sonidos reales, música real, videos, videoclips, imágenes, temas y aplicaciones.
•
Fidelización: este marketing permite llegar al público afiliado y establecer un
diálogo en tiempo real en cualquier momento y lugar.
•
Votaciones: permiten la presentación de datos en tiempo real tanto para la
empresa como para informar a los clientes.
•
Test: ayudan a las empresas a conocer mejor a sus clientes.
7
Introducción
•
Alertas/RSS: permiten a los usuarios recibir los anuncios publicitarios cuando
ellos quieran y sobre lo que a ellos les interese.
1.2.2 Publicidad personalizada
La publicidad dirigida o personalizada es una forma de comunicar un mensaje
publicitario a un consumidor perteneciente a un segmento o grupo de consumidores y
con un nivel de personalización que consiga atraer la atención del consumidor y
despertar su interés, provocando así una acción con mayor probabilidad.
La información del consumidor se obtiene mediante la interactividad del
consumidor con los anuncios. De esta interacción con los anuncios se pueden perfilar y
segmentar a los consumidores en grupos. El objetivo es el de ofrecerles un mensaje
publicitario más preciso y más efectivo, acorde con sus gustos y costumbres.
Un ejemplo del modelo de publicidad personalizada es el de las cuñas
publicitarias de los canales de televisión. La emisión de un programa se ve interrumpida
por una cuña de anuncios televisivos de treinta segundos de duración. Según el perfil
del usuario se pueden insertar ciertos anuncios cuya temática sea más parecida al gusto
del usuario (el usuario tiene un perfil de deportista y un anuncio de la cuña publicitaria
ofrece ofertas de viajes de aventura).
1.2.3 Contenidos publicitarios
Los formatos publicitarios que se pueden integrar en la televisión en el móvil
son los siguientes:
-
Banner: formato publicitario de dimensión horizontal, que ocupa una tamaño
inferior a ¼ de la pantalla en vertical.
-
Rascacielos o banner vertical: formato publicitario de dimensión vertical que
ocupa un tamaño inferior a ¼ de la pantalla en horizontal.
8
Introducción
-
Botón: formato publicitario de pequeño tamaño y seleccionable que puede
encontrarse en cualquier parte de la pantalla
-
Enlace de texto: texto de enlace a otras secciones, páginas, etc.
-
Robapáginas: formato publicitario de tamaño cuadrado o rectangular que
puede emplazarse en cualquier lugar de la pantalla
1.3 La televisión en dispositivos móviles
Con la llegada de la televisión digital interactiva (recientemente debido a la
televisión digital terrestre y a las posibilidades que ofrecen los set-top-box) se produce
un cambio radical en la forma en la que los usuarios disfrutan de la televisión, no sólo
debido a la mejora en la calidad de la señal sino también debido a las muchas
posibilidades que se plantean al existir la posibilidad de transmitir aplicaciones
interactivas a los usuarios. Con ello se consigue que el usuario no sea un mero receptor
de datos, sino que también pueda interactuar con ellos.
Esta revolución en el mundo televisivo va a aumentar considerablemente con la
aparición de la televisión móvil digital, permitiendo acceder a los contenidos televisivos
desde cualquier dispositivo portátil, como teléfonos móviles o PDAs, en cualquier lugar
donde pueda estar el usuario.
La televisión en el móvil puede ser unicast, multicast y broadcast:
-
unicast: la entrega del contenido se realiza a través de la red móvil
3G/HSDPA.
-
multicast: en este caso se utiliza MBMS (Multimedia Broadcast & Multicast
Service) ya que permite difundir información o contenido sobre la red 3G
simultáneamente a múltiples dispositivos.
-
Broadcast: utiliza la tecnología DVB-H, estándar que se ha adoptado
recientemente en Europa para la difusión de la televisión para dispositivos
móviles. Es la evolución del estándar de televisión digital terrestre (DVB-T)
9
Introducción
para dispositivos móviles (para más información consultar el capítulo
ANEXOS apartado Organismos de estandarización relacionados subapartado
DVB).
Debido a que el usuario va a disponer de un breve espacio de tiempo para
disfrutar de los contenidos en su dispositivo móvil (mientras está en el autobús yendo al
trabajo, en una cafetería, etc), resulta interesante que el usuario pueda recibir aquella
información que resulte de su interés.
Por otro lado, los contenidos televisivos que reciba el usuario pueden estar
dotados con posibilidades atractivas de interactividad: descargas de logos, tonos,
música, videoclips, enlaces a más información, encuestas, votaciones, venta de
productos, contenidos publicitarios, etc. Todos estos contenidos auxiliares pueden estar
o no relacionados con el contenido principal que el usuario está visualizando en un
momento preciso.
Dentro de estos contenidos auxiliares interactivos se incluye la publicidad
interactiva para la televisión móvil. Dicha publicidad puede presentar diferentes
opciones de interactividad: comprar un determinado producto, dirigir al usuario a la
página web del anunciante, descargas, etc.
En conclusión, la televisión móvil digital abre una amplia oferta de
oportunidades tanto a los proveedores de contenido y operadoras como a los usuarios.
1.4 La publicidad en el móvil
Para las campañas de marketing de muchas industrias, las compañías han optado
por la telefonía móvil, sustituyendo a la fija, pues los nuevos usos de estos teléfonos
posibilitan una nueva forma de marketing más directa y efectiva. Esto es debido a que
ningún otro medio de comunicación viaja en el bolsillo del cliente, está encendido diez
horas al día, admite sonidos, imágenes y videos, tiene una penetración superior al 90
10
Introducción
por ciento de la población (en España), es interactivo y además permite realizar pagos
de una forma segura como el teléfono móvil. Además, el móvil presenta otras ventajas
interesantes, como son: definir el público objetivo, controlar las campañas y medir los
impactos que recibe el consumidor potencial.
Según las estadísticas realizadas la realización de una campaña de marketing
directo a través del móvil aporta altos índices de efectividad:
-
85 % recuerda la marca del anuncio.
-
43% considera que la campaña tiene un efecto positivo.
-
7% considera que la campaña tiene un efecto negativo.
El bajo coste de estas campañas hace que este canal se convierta en una
herramienta de comunicación, no sólo para las grandes empresas que disponen de
amplios presupuestos, sino también para las pequeñas y medianas empresas que
precisan impulsar sus acciones de comunicación y marketing a un coste asequible.
Según un estudio realizado por Orange and Deloitte Consulting un 35% de las
compañías que han introducido soluciones SMS afirman haber incrementado su
productividad, un 44% ha ahorrado costes y un 37% afirma haber generado ingresos.
El marketing móvil va más allá de los SMS y de los MMS. Su futuro es
prometedor gracias a los nuevos servicios que los operadores ofrecen a sus usuarios:
televisión, música, juegos... los contenidos multimedia serán claves para el futuro
desarrollo del marketing móvil.
De acuerdo con la investigación realizada por la firma Júpiter Research la
publicidad en teléfonos móviles crecerá el 50% de los valores actuales en los próximos
cinco años, a pesar de que se anticipa una resistencia de los usuarios a aceptar el nuevo
recurso publicitario.
Actualmente se están llevando a cabo diferentes técnicas para conseguir
introducir la publicidad en los terminales móviles de una forma exitosa:
11
Introducción
-
Recepción de publicidad en el móvil percibiendo un descuento en la factura
telefónica. Más de nueve de cada diez usuarios de telefonía móvil darían su
permiso para recibir publicidad en su móvil si obtuviesen descuentos en la
factura telefónica (93,7%) o si obtuviesen puntos de fidelización de su
operador (90,6%). Por su parte, un 85% de los jóvenes la aceptarían en el
caso de que la publicidad fuera divertida, entretenida o creativa (datos
obtenidos de un estudio de Zed Digital).
Desde marzo de 2007 los abonados de Telefónica y Vodafone ya ofrecen
este tipo de descuentos como estrategia publicitaria. Concretamente, el
experimento consiste en permitir que los usuarios accedan a servicios y
productos de forma económica o gratuita a cambio de que los anunciantes
puedan incluir publicidad en su teléfono. Movistar, por ejemplo, ofrece gratis
los videogoles de fútbol a los clientes que antes reciben un pantallazo con el
banner de Coca Cola. El método de Vodafone son los mensajes
esponsorizados pero de momento se trata tan sólo de un proyecto piloto con
Ikea. Sus abonados podrán, a través de la descarga de una aplicación, incluir
en sus mensajes multimedia un banner de publicidad para conseguir un
descuento en el coste del SMS.
-
SMS gratuitos a cambio de enviar publicidad. Mediante la página web
www.SMSgratis.es se permite a los usuarios enviar tres SMS gratis al día
con
la
condición
de
incluir
una
cuña
publicitaria
en
ellos.
Entre un número de opciones predeterminadas, será el remitente quien
elegirá al anunciante que le financiará el envío y que, por lo tanto, aparecerá
en la publicidad.
La idea de insertar publicidad ha tardado en llegar a la telefonía aunque las
previsiones apuntan que el marketing móvil podría suponer un 37% del total de la
inversión en publicidad interactiva en 2009. A pesar de este retraso, los grandes
buscadores como Google y Yahoo! confían en el móvil como una potente arma de
ventas y canal de marketing por lo que ya están desarrollando herramientas en esta
línea. Yahoo, por ejemplo, dispone de una nueva herramienta desde marzo de 2007 que
mejora sus servicios de publicidad móvil. Esta herramienta se denomina Yahoo Mobile
12
Introducción
Ad Network e incluye tres nuevos servicios: Yahoo Mobile Content Engine, Mobile
Media Directory y Mobile Site Submit. Se ofrece a los publicistas la posibilidad de
elegir el formato con el que quieren estar presentes en los teléfonos móviles del público:
vídeos, juegos, enlaces... Y para ello, se ha asociado con las empresas MbiTV, que
ofrece televisión para dispositivos móviles, el navegador Opera y el servicio de páginas
de información Go2.
Por otro lado, un informe de eMarketer pronostica que el número de usuarios de
televisión y vídeo a través del móvil en todo el mundo crecerá de los 40 millones de
usuarios que había en 2006 hasta 750 millones de usuarios en 2011. Ante estas cifras,
los analistas de eMarketer señalan que la demanda de televisión por móvil está
aumentando.
Por este motivo la publicidad jugará un papel clave en el desarrollo de los
canales de TV móvil, hasta que se conviertan en un servicio de importancia para el
consumidor.
En España concretamente, las pruebas pilotos arrojan que el tiempo medio de
uso de la televisión en el móvil está entre los 16 minutos y los 25 minutos al día, aunque
más
del
20%
utilizó
el
servicio
entre
30
y
60
minutos
diarios.
Además, más del 75% de los encuestados dijo que recomendaría este servicio y que
estaría dispuesta a pagar por él.
13
Introducción
Como conclusión de los apartados anteriores, hay que destacar que hoy en día la
publicidad en el móvil es una forma de marketing más directa y efectiva que cualquier
otro medio publicitario. Por ese motivo, actualmente ya muchas compañías han optado
por entregar sus contenidos publicitarios a través de este medio.
Por otro lado, la televisión en el móvil es un servicio que se encuentra
implantado actualmente en muy pocos países pero, sin embargo, se prevé que a corto
plazo sea implantado en muchos países. Es un servicio novedoso y, por los estudios y
encuestas realizados, parece que será aceptado y utilizado por muchos de los usuarios de
telefonía móvil. Dentro de este marco también es posible la inclusión de publicidad, por
lo que las diferentes empresas deberán considerar la televisión en el móvil como un
nuevo medio para poder ofrecer sus contenidos publicitarios.
Este tipo de publicidad no debe seguir el mismo patrón que la que se utiliza
actualmente en televisión o en Internet. La clave radica principalmente en conseguir
hacer llegar al usuario sólo aquellos contenidos publicitarios que sean de su interés, así
como no utilizarlos de manera intrusiva.
Este proyecto se centra en los contenidos publicitarios para la televisión en el
móvil. A lo largo del documento se realiza un estudio sobre qué tecnologías están
relacionadas con este tema. Una vez analizadas dichas tecnologías, se propone una
arquitectura que engloba la creación de contenidos publicitarios para este medio,
técnicas de vinculación de contenidos interactivos y contenidos principales,
mecanismos que se pueden utilizar para entregar dichos contenidos a los terminales
móviles, tecnologías que permiten visualizar dichos contenidos en los dispositivos y,
por último, técnicas que se pueden utilizar para entregar a los usuarios sólo aquellos
contenidos publicitarios que sean de su agrado. No obstante, aunque el proyecto se
centra en los contenidos publicitarios, en algunos casos también se han considerado
otros tipos de contenidos auxiliares como pueden ser las votaciones que pueden estar
relacionadas con un contenido televisivo (por ejemplo, una votación del tipo Gran
14
Introducción
Hermano que permita al usuario votar por aquella persona a la que desee expulsar de la
casa).
Dentro de esta arquitectura se han desarrollado dos aplicaciones que cubren la
creación de contenidos interactivos tanto publicitarios como de votaciones: una de las
aplicaciones debe ser utilizada por el proveedor de contenidos y la otra por el proveedor
de servicios. El proveedor de contenidos no tiene por qué conocer la tecnología
necesaria para crear los contenidos interactivos publicitarios. Con su aplicación puede
crear documentos XML que incluyan la información de los contenidos publicitarios (por
ejemplo, texto del anuncio, imagen del mismo, link para acceder a la página web del
anunciante, etc). Este fichero XML es enviado al proveedor de servicios que, a partir de
la información incluida en el mismo y con ayuda de su aplicación, es capaz de generar
el contenido interactivo auxiliar definitivo con la tecnología necesaria.
15
Tecnologías relacionadas
2 TECNOLOGÍAS RELACIONADAS
2.1 TECNOLOGÍAS HABILITADORAS DE RICH
MEDIA
2.2 GUÍAS DE PROGRAMACIÓN
2.3 SISTEMAS
DE
VINCULACIÓN
DE
CONTENIDOS
2.4 TECNOLOGÍAS
DE
PRESENTACIÓN
DE
DE
DISTRIBUCIÓN
DE
CONTENIDOS
2.5 TECNOLOGÍAS
CONTENIDOS
2.6 TECNOLOGÍAS DE PERSONALIZACIÓN DE
CONTENIDOS
16
Tecnologías relacionadas
2. Tecnologías relacionadas
En este capítulo se analizan todas aquellas tecnologías que estén relacionadas
con la publicidad en el móvil. Para poder llevar a cabo este análisis, las diferentes
tecnologías se han agrupado en las siguientes áreas:
1.
Tecnologías habilitadoras de rich media: aquellas tecnologías que
permiten crear los contenidos publicitarios para la televisión en el
móvil.
2.
Guías de programación: estas guías permiten acceder a la
programación (tanto programación de contenidos televisivos como
contenidos auxiliares) de cada uno de los canales de televisión.
3.
Sistemas de vinculación de contenidos: permiten vincular los
contenidos de publicidad con los contenidos televisivos con los que
estén relacionados.
4.
Tecnologías de presentación de contenidos: involucra las tecnologías
que permiten visualizar en los terminales móviles los contenidos
publicitarios.
5.
Tecnologías de distribución de contenidos: en esta área se incluyen
aquellas tecnologías que permiten entregar los contenidos publicitarios
a los terminales móviles.
6.
Tecnologías de personalización de contenidos: estas técnicas permiten
que el usuario sólo reciba en su terminal aquellos contenidos que sean
de su agrado.
A continuación se analizan todas las áreas anteriormente mencionadas:
17
Tecnologías relacionadas
2.1 Tecnologías habilitadoras de rich
media
Se entiende por interactividad (en el contexto de un dispositivo móvil) cualquier
mecanismo que permita al usuario enviar o recibir información, participar, contribuir o
comunicarse en tiempo real con cualquier servicio o con otros usuarios desde su
teléfono móvil en un escenario o contexto específico (viendo la TV, escuchando la radio
etc.).
La interactividad beneficia a toda la cadena de valor:
•
Los usuarios pueden obtener, por ejemplo, más información de una canción,
participar en votaciones y concursos relacionados con algún programa etc.
•
Potencia el uso de la red móvil (como canal de retorno) de modo que las
operadoras móviles obtienen beneficios por el tráfico 2G/3G.
•
Potencia el uso de los servicios asociados (radio, televisión, etc).
•
Se crean nuevos negocios basados en la publicidad, venta de contenidos
digitales, etc., en los que publicistas y proveedores de contenidos pueden
colaborar para obtener beneficios.
•
Se impone un proceso de redefinición del marketing. La publicidad de tercera
generación implica la transición desde una publicidad intrusiva hacia un modelo
de marketing relacional basado en la comunicación personal y en la publicidad
consentida en el que es fundamental la participación de los operadores.
Para llevar a cabo esta interactividad se hace uso de contenidos rich media. Un
contenido rich media es una colección dinámica e interactiva de datos multimedia como
audio, video, gráficos, imágenes y texto, entregados a través de un único interfaz.
Gracias a estos contenidos se puede proporcionar una experiencia de usuario más rica y
única ya que permite además incluir interactividad. Por ejemplo, puede ser una película
enriquecida con capas superpuestas de gráficos vectoriales e interactividad, un servicio
complejo en varios pasos con interacciones que van fluyendo y diferentes tipos de
medios en cada paso, etc.
18
Tecnologías relacionadas
La demanda de servicios rich media se está incrementando a buen ritmo, incitada
por el desarrollo de la siguiente generación de infraestructura móvil y la generalización
de los contenidos televisivos para los nuevos entornos.
Por todos estos motivos, se recomienda que los contenidos auxiliares para
televisión en el móvil tales como publicidad o votaciones se realicen utilizando
tecnologías rich media. De esa forma se puede conseguir una experiencia más rica de
cara al usuario, así como también dotar de interactividad a dichos contenidos.
Los contenidos rich media en los terminales móviles permiten integrar todo tipo
de medios simulando una experiencia de navegación. A través de un clic (pulsar un
botón) se puede acceder a las aplicaciones y servicios. Por otro lado, es independiente
de las redes. Si lo comparamos con los accesos WAP, éstos sólo permiten acceder a
contenidos estáticos y con una navegación muy restringida que no integra diferentes
medios (únicamente texto e imágenes). El acceso a la información conlleva su tiempo y
es costoso.
Rich media
WAP
A continuación se muestran algunos ejemplos de contenidos interactivos rich
media para televisión en el móvil:
19
Tecnologías relacionadas
Existen varias tecnologías habilitadoras de rich media. Una de ellas es la
tecnología propietaria Flash, que ha tenido mucho éxito para PC ya que actualmente es
el estándar de facto para distribuir contenido rich media en Internet. El problema de
Flash es que no es un estándar abierto, cuestión muy importante para conseguir un
soporte de la industria masivo especialmente para dispositivos móviles. Flash dispone
de una versión especialmente diseñada para dispositivos móviles: Flash Lite.
Dos grupos de estandarización han intentado especificar estándares de
tecnologías rich media. Estos grupos son MPEG y W3C.
MPEG-4 BIFS es el primer intento del MPEG en este campo. Permite la
creación de contenido multimedia mezclado con gráficos 2D y 3D, introduce las
20
Tecnologías relacionadas
actualizaciones de la escena permitiendo streaming de las mismas y asegura una
sincronización entre los diferentes elementos audiovisuales de la escena. Su principal
inconveniente es que su estructura y codificación binaria lo hacen inapropiado para el
mundo móvil. La tecnología rich media más importante creada por este grupo es
LASeR.
Por otro lado, el W3C ha creado varios lenguajes rich media entre los que se
encuentran los estándares de SMIL y SVG. Ambos han sido adoptados por el 3GPP y
OMA en su perfil móvil. Tanto SMIL como SVG son lenguajes XML y se apoyan sobre
el modelo de consumo de HTML download-and-play o download progresivo y
presentación.
A continuación se analizan las principales tecnologías habilitadoras de rich
media:
-
Flash Lite
-
SVG
-
LASeR
-
MORE
2.1.1 Flash Lite
Flash Lite es el perfil de Macromedia Flash para el desarrollo de experiencias
multimedia interactivas destinadas a dispositivos de telefonía móvil (dispositivos con
restricciones tanto de memoria como de capacidad de proceso). Está basado en la
plataforma Flash de Adobe. Está destinada a programadores y diseñadores interesados
en extender el campo de aplicación de Flash hacia las plataformas móviles. El
reproductor resulta ideal para dispositivos móviles que carecen de la capacidad de
memoria y procesamiento necesaria para ejecutar Flash Player 7. Flash Lite se ejecuta
bajo el sistema operativo Symbian (s40, s60) o similar.
Flash Lite puede utilizar dos tipos de sonido:
21
Tecnologías relacionadas
-
Sonidos estándar de flash (o sonido nativo): pueden reproducirse bien como
sonido de evento o bien como sonido sincronizado. Estos sonidos se pueden
sincronizar con la línea de tiempo
-
Sonidos de dispositivo: consiste en un sonido codificado en el formato de audio
nativo del dispositivo (ej. MIDI). Sólo se utilizan como sonidos de eventos, pero
no pueden sincronizarse con la línea de tiempo.
Por otro lado, el proceso de desarrollo es mucho más sencillo y rápido que para
cualquiera de las otras plataformas, de forma que se pueden construir aplicaciones
sencillas en tiempos realmente cortos, y con resultados gráficos difícilmente alcanzables
por sus competidores. Además, no hay que preocuparse de perfiles o configuraciones.
Lo que se desarrolla una vez sirve para todos los dispositivos que soporten Flash Lite
(con la única precaución de prever que no todas las pantallas tienen el mismo tamaño).
La herramienta principal para el desarrollo de aplicaciones para Flash Lite es el
propio Macromedia Flash que además incluye (a partir de la versión 8) un emulador que
permite testear el contenido desarrollado contra una amplia variedad de dispositivos (en
realidad, contra todos los dispositivos que soportan Flash Lite). Además, el emulador
permite filtrar los dispositivos según el tipo de aplicación a desarrollar, es decir, que si
se está implementando, por ejemplo, un salvapantallas, dicho salvapantallas se puede
probar sólo en los teléfonos que soporten dicha funcionalidad.
2.1.1.1 Versiones
2.1.1.1.1 Flash Lite 1.0
Flash Lite 1.0 se lanzó en febrero de 2003 en Japón para los terminales NTT
DoCoMo 505i. Está basado en Flash Player 4. Con esta versión, los usuarios de
dispositivos móviles sólo podían disfrutar de contenido estático (salvapantallas, fondos
de escritorio) y sólo podían actualizarlo cambiando unos por otros.
Algunas de sus características son las siguientes:
-
Sólo se pueden emplear sonidos de dispositivo.
22
Tecnologías relacionadas
-
Sólo se puede reproducir un sonido como respuesta a la pulsación de una tecla
en el dispositivo del usuario.
-
No admite las teclas programables.
2.1.1.1.2 Flash Lite 1.1
Flash Lite 1.1 está construido sobre Flash Lite 1.0. Igualmente está basado en
Flash Player 4. Soporta ActionScript 0.5.
Las principales características de esta versión son las siguientes:
-
El contenido Flash Lite puede intercambiar datos con un servidor a través de una
conexión http, lo que permite diseñar aplicaciones con cabeceras de noticias,
resultados de los partidos y menús actualizándolos dinámicamente.
-
Soporte para el estándar W3C SVG Tiny (SVG-T)
-
Acceso a las capacidades del teléfono, como estado de la conexión de red, fecha
y hora, funcionalidad de vibración, soporte de audio e idioma, mensajes
multimedia, nivel de batería y otros.
-
Se pueden emplear sonidos de dispositivos y sonidos estándar.
-
Presenta soporte para los formatos de audio MP3, PCM, ADPCM y SMAF.
-
Presenta una API (denominada FSCommand2) para integrar contenido Flash
con la funcionalidad del teléfono. FSCommand2 está diseñada específicamente
para Flash Lite. Permite hacer llamadas externas desde Flash.
-
Se encuentra preinstalado en muchos modelos de terminales móviles.
A continuación se detallan las marcas y modelos de dispositivos móviles
soportados por Flash Lite 1.1 (cada marca y modelo requiere un instalador específico):
•
Series 60: Nokia 3600, 3620, 3650, 3660, 6260, 6600, 6620, 6630, 6670, 7610,
N-Gage, N-Gage QD / Sendo X / Siemens SX1
•
UIQ: Sony Ericsson P900, P910
23
Tecnologías relacionadas
Arquitectura Flash Lite 1.1
Algunas de las aplicaciones y juegos para móviles desarrollados con esta
tecnología son los siguientes: NinJa Bomb, Sanke eat Snake, FantasyQuest, Fantasy
TETRIS, FantasyQuest RPG, Mario Bomb Bee, Dark Killer, AirCombat, SpeedRacer,
FruitBall, MobileBus, Emulators Station, etc.
2.1.1.1.3 Flash Lite 2.0
Las versiones anteriores de Flash Lite (Flash Lite 1.0 y Flash Lite 1.1) están
basadas en Flash Player 4. Flash Lite 2.0 está basado en Flash Player 7 y es compatible
con la mayoría de las funciones disponibles en dicha versión de Flash Player. Flash Lite
2.0 también contiene varias funciones no disponibles en Flash Player 7 y que están
diseñadas para aplicaciones móviles.
Las principales novedades incluidas en Flash Lite 2.0 son las siguientes:
-
Soporta ActionScript 2.0. Con ActionScript 2.0 llega no sólo un lenguaje nuevo,
sino una metodología de desarrollo nueva (en comparación con la utilizada en
24
Tecnologías relacionadas
Flash Lite 1.1). Aplicaciones dirigidas por eventos, separación entre interfaz y
lógica de negocio, programación orientada a objetos, etc.
-
Se da soporte a la carga y posterior tratamiento de archivos XML, algo que
anteriormente no estaba soportado.
-
Existe la posibilidad de tener datos persistentes en el dispositivo, lo que
permitirá volcar a la memoria del teléfono estructuras de datos que podrán ser
recuperadas en posteriores sesiones de la misma aplicación.
-
Permite cargar imágenes y sonidos en tiempo de ejecución, desde el dispositivo
o desde la red. También reproducir vídeos, delegando dicha reproducción en el
hardware del dispositivo, y permitiendo que esos vídeos también puedan ser
cargados en tiempo de ejecución.
-
Presenta un consumo reducido de la memoria.
-
Posibilita implementar interfaces personalizados basados en Flash, permitiendo
generar Themes, Skins, etc.
-
Flashcat, que permite que las compañías puedan distribuir contenidos en Flash a
los teléfonos móviles que usen tecnología Flash Lite. De esta manera el usuario
podrá tener acceso a canales de información pudiendo consultar partes
meteorológicos, información de restaurantes, transportes públicos, etc. Todo ello
con la interactividad típica de los interfaces basados en Flash.
-
Soporte de tipos mime.
25
Tecnologías relacionadas
Arquitectura de Flash Lite
2.1.1.2 Ejemplos
A continuación se muestran varios ejemplos de imágenes/aplicaciones creadas
con Flash Lite:
26
Tecnologías relacionadas
2.1.2 SVG
SVG es un lenguaje para describir gráficos vectoriales bidimensionales, tanto
estáticos como animados (estos últimos con ayuda de SMIL) en XML.
SVG se convirtió en una recomendación del W3C en septiembre de 2001. SVG
ha sido expresamente diseñado para trabajar conjuntamente con otros estándares del
W3C tales como CSS, DOM y SMIL.
SVG tiene un ámbito de acción similar a Flash, tecnología propietaria de
Macromedia. Lo que lo diferencia de Flash es que SVG es una recomendación del W3C
y, por lo tanto un estándar abierto. Además está basado en XML y no en ningún formato
binario cerrado.
Las principales características gráficas del formato SVG son:
27
Tecnologías relacionadas
•
Es un formato de gráficos vectoriales por lo que los gráficos resultan editables,
admiten transparencias, suavizados, rastrillados, etc.
•
Produce gráficos escalables, que pueden aumentar o disminuir de tamaño sin
pérdida de calidad, lo que los hace adaptarse sin problemas a cualquier
resolución de pantalla.
•
Admite textos editables, admitiendo fuentes True Type y Type 1.
•
Admite gestión avanzada del color, manejando 24 bits de profundidad, pudiendo
además usarse en su definición cualquiera de los sistemas estándares: RGB,
CMYK, etc.
•
Se pueden incluir en un gráfico SVG sonidos y etiquetas explicativas.
•
Permite la creación de animaciones en escala de tiempo.
•
Admite diferentes tipos de filtros, consiguiendo resultados sorprendentes.
Además soporta características avanzadas como:
•
Transformación anidada (matrices de transformación).
•
Clipping Paths.
•
Alpha Masks.
•
Filtros gráficos
•
Interactividad y dinamismo, soportado tanto de forma declarativa como vía
scripting.
•
Hojas de Estilos en Cascada (CSS), permitiendo con ello definir con toda
exactitud el formato de presentación que van a tener los elementos del gráfico.
•
El acceso al DOM y lenguajes de script (JavaScript, VBScript, etc.), con lo que
es posible modificar las propiedades de los elementos de un gráfico en tiempo
real
28
Tecnologías relacionadas
Los dibujos de SVG pueden ser interactivos y dinámicos. Las animaciones se
pueden definir y lanzar declarativamente (es decir, encajando elementos de animación
SVG dentro de contenido SVG) o vía scripting. El DOM (Documento Object Model)
para SVG, que incluye el DOM XML completo, permite animaciones de gráficos
vectoriales sencillos y eficientes mediante ECMAScript o SMIL. Un juego amplio de
manejadores de eventos puede ser asignado a cualquier objeto SVG.
Las ventajas y posibilidades que presenta son las siguientes:
•
Tiene todas las ventajas asociadas a un formato vectorial: es escalable,
compacto, con formas siempre editables a través de curvas Bézier, con
contornos suavizados, transparencias, y capaz de incluir, si es preciso, bitmaps.
•
El tamaño de los SVG es muy compacto
•
El texto que incluyen es editable: admite las fuentes escalables más comunes.
Esto supone una diferencia enorme con los actuales GIF o JPG: el texto que
contienen se puede editar, seleccionar, ser indexado por los buscadores...
•
La calidad de color es excelente y el color del gráfico se puede calibrar con los
sistemas estándar de gestión de color.
•
Puede incluir código (scripts) que modifican el gráfico dinámicamente en
función de las necesidades
•
Al ser XML, es un formato extensible: los fabricantes podrán adoptarlo como
formato nativo de sus aplicaciones, añadiendo las características específicas que
deseen, pero siempre mantendrá la compatibilidad básica y universal con toda
aplicación que reconozca el formato.
•
Admite efectos como sonido, efectos visuales al hacer clic o mover el ratón,
etiquetas informativas.
El SVG DOM permite a los lenguajes de script el acceso a todos los elementos,
propiedades y atributos que componen un documento SVG. Además, existe la
posibilidad de asignar eventos a los distintos elementos (onmouseover u onclick).
29
Tecnologías relacionadas
Se recomienda que los ficheros SVG tengan extensión .svg o .svgz (en
minúsculas) en todas las plataformas.
SVG es compatible con: XML 1.0, XML Namespaces, XLink y XML Base para
la referencia a URIs, Xpointer, CSS, XSL, DOM nivel 1 y 2 incluyendo DOM-Style y
DOM-Event, SMIL 1.0 (sólo algunas de sus funcionalidades), HTML 4 y XHTML 1.0,
UNICODE y WAI
2.1.2.1 Versiones
Para PCs existen varias versiones de SVG: SVG 1.0, SVG 1.1 y SVG 1.2. No
obstante, debido a que en el ámbito de este proyecto sólo resultan interesantes las
versiones SVG para móviles, éstas serán las únicas que se estudien.
2.1.2.1.1 SVG Tiny 1.1+
Se trata de una especificación realizada por los fabricantes, operadores y
proveedores de telefónica móvil como respuesta a la demanda de características
adicionales no encontradas en la especificación Tiny 1.1. La especificación se completó
en enero de 2003.
SVG Tiny 1.1+ se encuentra entre SVG Tiny 1.1 y SVG Tiny 1.2, es decir, SVG
Tiny 1.1 es un subconjunto de SVG Tiny 1.1+ que a su vez es un subconjunto de SVG
Tiny 1.2. De esta manera un contenido realizado en SVG Tiny 1.1+ puede ser
interpretado en cualquier player que soporte SVG Tiny 1.2.
Las dos características principales que se encuentran en SVG Tiny 1.1+ que no
existían en SVG Tiny 1.1 son la opacidad (transparencia) y los gradientes. Estas dos
características se soportan de la misma manera que lo harán en SVG Tiny 1.2. En el
caso de la opacidad, sólo se soportan los atributos fill-opacity y stroke-opacity. Para el
caso de los gradientes se soportan los elementos linearGradient y radialGradient con
ciertas restricciones.
30
Tecnologías relacionadas
2.1.2.1.2 SVG Tiny 1.2
Es una revisión de SVG 1.1 en la que se añaden nuevas características necesarias
y solicitadas por la comunidad SVG.
En un principio SVG Tiny iba a ser un perfil dentro del SVG 1.2 pero al final y
por su importancia se convirtió en una especificación separada, existiendo ahora dos
especificaciones: SVG Full 1.2 y SVG Tiny 1.2.
La experiencia con SVG Tiny 1.1, que fue adoptado extensamente por la
industria y se admitió como estándar en una gran variedad de teléfonos móviles,
demostró que el perfil era demasiado restrictivo en algunas áreas. Las características de
SVG 1.1 tales como gradientes y opacidad, fueron vistas para tener valor substancial
para crear contenido atractivo, y fueron mostradas para ser implementadas en teléfonos
móviles. Había también considerable interés en la incorporación de capacidades de
audio y video, fundamentándose en el soporte de SMIL en SVG Tiny 1.1.
Avances como por ejemplo el nivel 3 de DOM, que introduce el soporte de
namespaces y la normalización de valor (value normalization), propició una segunda
revisión en el uso de lenguajes de programación y de scripting en SVG Tiny.
Conjuntamente con el grupo de Java JSR 226 se desarrolló un interfaz ligero llamado
microDOM, o uDOM, Esto podía ser, pero no necesariamente, implementado sobre el
nivel 3 de DOM. Con este avance, el control programático ligero de SVG (por ejemplo,
para juegos o interfaces de usuario) y el uso con lenguajes de scripting, llegaron a ser
factibles en la gama entera de plataformas desde los teléfonos móviles hasta los
ordenadores de escritorio. En consecuencia, existe solamente un sólo perfil móvil para
SVG 1.2: SVG Tiny 1.2.
SVG Tiny 1.2 introduce vídeo, audio, gradientes, opacidad de trazo y fondos,
formato de textos y la posibilidad de utilizar scripting en dispositivos móviles. Al igual
que SVG 1.2, SVG Tiny 1.2 se puede implementar en una gran variedad de dispositivos
incluyendo ordenadores portátiles y de sobremesa, teléfonos móviles, micro PC,
sistemas integrados en automóviles y consolas de ocio. SVG Tiny 1.2 ayuda a mejorar
31
Tecnologías relacionadas
la experiencia de la Web móvil, un objetivo fundamental para el W3C y para la
Iniciativa de Web Móvil (MWI).
El Grupo de Trabajo de Formato de Documentos Compuestos (CDF) utiliza
SVG Tiny 1.2 con XHTML Basic para crear WICD.
Las características más importantes que se han añadido a la especificación son:
•
Soporte de medios (audio y video) sincronizados.
•
Múltiples páginas.
•
Mejoras en el soporte de textos.
•
Streaming.
•
Características de composición y color para soportar calidad de media a alta en
la pantalla.
•
Enlaces extendidos.
SVG Tiny 1.2 fue creado con la ayuda de las principales empresas del sector.
Entre ellos se pueden destacar Abbra, Adobe Systems Inc., Canon, Inc., Ericsson,
Expway, Groupe des Ecoles de Télécommunications, Ikivo AB, ILOG, S.A., ITEDO
Software GmbH, KDDI Corporation, Mercurial Communications Inc., Nokia, BitFlash
Division of Open Text, Opera Software, Research In Motion, Ltd. (RIM), Sharp
Corporation, Streamezzo, Sun Microsystems, Inc., ETH Zurich, Telecom Italia SpA y
Vectoreal.
2.1.2.2 Soporte
Actualmente la gran mayor parte de los dispositivos móviles ya llevan integrada
la versión 1.1 Tiny de SVG. En la página http://www.svg.org/special/svg_phones se
mantiene una lista actualizada de los teléfonos que soportan SVG 1.1
32
Tecnologías relacionadas
2.1.2.3 Comparativa Flash Lite vs SVG 1.1
CONCEPTO
SWF
SVG 1.1
Tipo de especificación
Formato propietario
Especificación libre
Tipo de formato
Binario
Texto ASCII
Formatos
FLA, SWF
SVG
Compacto
Elevada
Muy elevada
Tipo MIME
application/x-shockwave-flash
image/svg+xml
Compresión
Sí (zlib)
Sí (gzip)
Herramienta de autor
Sí (Macromedia Flash)
Varios (no es
imprescindible)
Animación
Sí (Línea de tiempo)
Sí (nodos de interpolación)
Interactividad
Sí (basada en eventos y
scripting)
Sí (basada en eventos,
SMIL y scripting)
DOM
Propio
Especificación W3C
Modo de visualización
Plug-in (Macromedia Flash
Player)
Plug-in (varios)
Streaming
Sí
No
Arquitectura
Línea de tiempo
Objetos de animación
(basados en SMIL)
Tipos de animación
Fotograma a fotograma /
Interpolada
Interpolada
Gestión de la animación
Automática / controlada por
eventos
Automática / controlada por
eventos
Keyframes
Sí
Sí (KeyTimes / KeySplines)
Métodos de creación de
animaciones
Movimiento y morphing
Movimiento y morphing
(limitado)
Tipo de interpolación
lineal / polinómica
discreta / lineal /
polinómica
Trayectoria definida por el
usuario
Sí
Sí
Animación con velocidad
Sí
Sí
ANIMACIÓN
33
Tecnologías relacionadas
CONCEPTO
SWF
SVG 1.1
variable
INTERACCIÓN
Lenguaje de programación
ActionScript 2.0
ECMAScript
Interface de programación
ActionScript API
DOM nivel 2
Fuentes de Eventos
Foco / botones / ratón / teclado / Foco / ratón / visualización
cajas de texto /clips de película / / estado / animaciones /
fotogramas / ventana
modificaciones escena
(mutaciones)
Hipervínculo Web
Sí
Sí
Hipervínculo a otras entidades
Sí, Mediante ActionScript
Sí, directamente
Frecuencias de zámpelo
5.5 khz, 11 khz, 22 khz 44 khz
No soportado
Tipo
mono / estéreo
No soportado
Streaming
Sí
No soportado
Filtros
Implementados
No soportado
Tipo
Sincronización audio-video
No soportado
Streaming
Sí
No soportado
Filtros
Implementados
No soportado
SONIDO
VIDEO
2.1.2.4 Ejemplos
A continuación se muestran varios ejemplos de imágenes SVG. Sólo se
muestran imágenes estáticas.
34
Tecnologías relacionadas
Ejemplos de imágenes SVG Tiny
2.1.3 LASeR
Estas siglas corresponden a "Light Adaptation ScenE Representation" aunque
también es conocido formalmente como ISO/IEC 14496-20 (MPEG-4 parte 20). Es un
nuevo estándar de contenido rich-media dedicado a los dispositivos móviles.
La parte 20 del MPEG-4 define dos formatos binarios:
1.
LASeR, un formato binario para la codificación de escenas 2D, incluyendo
gráficos vectoriales, y modificaciones sincronizadas de la escena.
35
Tecnologías relacionadas
2.
SAF (Simple Aggregation Format), un formato binario para agregar en un
solo stream contenido LASeR con streams de audio y video.
La especificación LASeR se diseñó para permitir la representación eficiente de
escenas 2D que describan servicios rich-media para dispositivos de recursos limitados.
El estándar LASeR es por tanto un formato de contenido rich-media para dispositivos
móviles que proporciona una experiencia de usuario fluida de contenido enriquecido,
incluyendo audio, video, texto, y gráficos en redes y dispositivos de recursos ajustados.
Los requisitos de LASeR incluyen eficacia en la compresión, codificación y
ocupación en memoria. El estándar LASeR satisface estos requisitos construyéndose
sobre el formato SVG (Scalable Vector Graphics) definido por el World Wide Web
Consortium (W3C) y particularmente en su perfil "Tiny".
LASeR complementa SVG definiendo un conjunto de extensiones compatibles y
adecuadas a estos requisitos. Estas extensiones permiten entre otras cosas: la
sincronización precisa de los frames de la escena con los elementos audiovisuales, el
stream y la compresión eficiente del contenido SVG.
Las cuatro características principales de LASeR que realmente diferencian esta
tecnología con respecto a otras tecnologías existentes son:
1.
Las animaciones gráficas, el audio, el vídeo y el texto se empaquetan y se
difunden en conjunto. Contrariamente a las tecnologías existentes en el
móvil que son sobre todo agregación de varios componentes, no
necesariamente bien integrados entre ellos (ej. XHTML + SMIL + SVG +
CSS + Ecmascript +...). LASeR fundamenta su diseño en la misma idea que
logró el éxito del Flash de Macromedia en la Web: un componente único,
bien definido y determinista que integra todos los medios (audio, video,
texto, etc.). Esta integración asegura la riqueza y la calidad de la experiencia
del usuario final.
2.
Pantalla completa e interactividad con todos los streams. Con el uso de la
tecnología gráfica vectorial, el contenido se puede crear fácilmente para que
se ajuste al tamaño de la pantalla. Esta característica permite proporcionar
una visualización óptima del contenido aunque varíe la resolución de la
36
Tecnologías relacionadas
pantalla. Además, virtualmente, todos los píxeles se pueden utilizar como
elementos de la interfaz de usuario (se puede diseñar una caja en forma de
botón que al pulsarla realice una acción). Esto permite el diseño de interfaces
ricos y de uso amigable, similares a los que la gente usa cuando interactúa
con sus dispositivos.
3.
Entrega de contenido en tiempo real. LASeR se ha diseñado para la entrega
eficiente sobre redes de datos de reducido ancho de banda. Más
específicamente, el contenido rich-media LASeR, se puede entregar en
trozos empaquetados, permitiendo su exhibición tan pronto como un trozo es
recibido. Este concepto de "streaming", ya existía para los datos de audio y
de video y se ha generalizado para la descripción de la escena y para los
rich-media.
4.
LASeR se ha diseñado para entregar servicios de rich-media a partir de los
10 Kb/s. La principal tecnología usada es la compresión de los gráficos
vectoriales y las actualizaciones dinámicas de la escena. Esta característica
permite limitar drásticamente el tiempo de espera de los usuarios finales en
contra de lo que supone una página Web donde se vuelve a enviar la página
completa aunque solamente se hayan producido pequeños cambios.
Necesario para las redes de bajo bitrate tales como GPRS, esta funcionalidad
es también útil en una red de más alta capacidad donde los servicios richmedia se pueden enviar en un bitrate más bajo preservando el resto de ancho
de banda para mejorar la calidad del audio y del video.
Otras características también relevantes son las siguientes:
-
Descripción de escenas basada en SVGT 1.2.
-
Un mecanismo declarativo de actualización muy eficiente para modificar
contenido a bajo costo (sin script).
-
Soporte de tipo de letra de Opentype.
-
Soporte de cualquier dispositivo de entrada de datos.
-
Importa otros formatos: SVGT 1.1, SVGT 1.2, Macromedia Flash objects
TM, GIS, etc.
-
Codecs embebidos 3GP (ej. vídeo 3GPP, audio, imágenes...).
-
Formato de datos altamente comprimido.
37
Tecnologías relacionadas
-
Triggering y mecanismos precisos de sincronización.
-
Mecanismos de gestión de datos (lado del cliente y del servidor).
Las ventajas de estas características son: un desarrollo fácil de aplicaciones rich-
media, un renderizado rápido, una baja ocupación de ancho de banda (desde
10Kbytes/s) y ninguna latencia para los usuarios finales.
2.1.3.1 Características técnicas
El estándar LASeR especifica la representación codificada de presentaciones
multimedia para los servicios rich-media. En la especificación de LASeR, una
presentación multimedia es una colección de descripciones de escena y medios (cero,
una o más de una). Los medios son contenido audiovisual individual del tipo siguiente:
imagen (foto fija), vídeo (imágenes en movimiento), audio y por extensión datos del
tipo de letra (fonts). Una descripción de escena se compone de texto, gráficos,
animación, interactividad y la disposición espacial y temporal.
Una descripción de escena en LASeR especifica cuatro aspectos de una
presentación:
-
Cómo los elementos de la escena (audio, vídeo o gráficos) se organizan
espacialmente, es decir, la disposición espacial de los elementos visuales.
-
Cómo los elementos de la escena (audio, vídeo o gráficos) se organizan
temporalmente, es decir si lo están y cómo se sincronizan, cuando comienzan o
terminan.
-
Cómo interactuar con los elementos en la escena, es decir, cuando un usuario
hace clic sobre una imagen.
-
Si la escena está cambiando, cómo ocurren estos cambios.
Una descripción de la escena LASeR puede cambiar por medio de animaciones.
Los diversos estados de la escena durante la animación pueden ser deterministas (por
ejemplo conociendo cuándo comienza la animación) o no deterministas (por ejemplo
38
Tecnologías relacionadas
cuando un servidor envía modificaciones de la escena). La secuencia de una descripción
de la escena y de sus modificaciones sincronizadas se denomina stream LASeR.
La especificación define un motor LASeR como reproductor para las
presentaciones LASeR. Dicho motor tiene capacidades de composición rich-media por
encima de las de un reproductor multimedia clásico con audio, video, imágenes y
capacidades de texto. Estas capacidades de composición están basadas en SVG Tiny
1.1. Las capacidades de la composición se basan en el uso de un árbol de escena SVG.
Estas capacidades se mejoran con características especiales para los servicios móviles,
tales como una codificación binaria, actualizaciones dinámicas, representación avanzada
de tipos de letra y las características estables de la próxima especificación 1.2 de SVG
Tiny, incluyendo soporte de audio y vídeo.
Arquitectura de un motor LASeR
2.1.3.1.1 El árbol de la escena SVG
LASeR se basa en un árbol de escena SVG. Importa las primitivas de
composición de diversas especificaciones del W3C (todo el SVG Tiny 1.1, algo del
SVG 1.1 y SMIL 2) y usa el modelo de renderizado del SVG para presentar el árbol de
la escena. En medio de todas estas primitivas de composición, LASeR especifica
capacidades de hiperenlaces, audio y vídeo embebido, representaciones de gráficos
vectoriales, animación y características de interactividad.
39
Tecnologías relacionadas
2.1.3.1.2 Actualizaciones Dinámicas
SVG soporta actualmente los siguientes casos de uso para el consumo del
contenido:
-
La primera opción es el modo clásico de "descarga y reproducción". El usuario
espera hasta el final de la transferencia del archivo para comenzar a ver el
contenido.
-
La segunda opción es el modo de interpretación progresiva (progressive
rendering). Este modo es una versión mejorada de la anterior que permite la
visualización mientras se descarga el contenido. Pero el contenido descargado
agrega solamente el nuevo contenido al actual haciendo difícil el manejo de
documentos de larga duración.
-
La tercera opción se basa en el uso de scripting y el interfaz de software de red
DOM y de un protocolo ad hoc para comunicar las modificaciones de la escena
del servidor al cliente.
Sin embargo, los siguientes casos de uso, permitidos actualmente por Flash no se
pueden satisfacer de una manera eficiente e interoperable en SVG:
-
La representación eficiente de streams de dibujos animados.
-
La división de escenas en paquetes pequeños para encajarlos en mecanismos de
entrega de tamaño limitado (como las celdas de broadcast)
-
La creación dinámica de respuestas a una petición de usuario y su integración en
la escena actual.
-
La inserción (push) dinámica de contenido en una escena existente.
Para permitir estos casos de uso, LASeR complementa SVG con un mecanismo
de actualización dinámico que utiliza comandos LASeR para inserción, borrado,
reemplazado o cambio de una propiedad de un objeto. Usando estos comandos, un
servidor puede por ejemplo insertar o suprimir elementos gráficos o modificar las
características visuales de un objeto. Estos comandos se pueden también utilizar para
permitir un mecanismo del estilo de las cookies de los navegadores Web.
40
Tecnologías relacionadas
2.1.3.1.3 Codificación Binaria
Según lo especificado por el W3C, el contenido de SVG se crea, se almacena y
se transmite en formato XML. Aunque XML se ajusta bien para la Web, como en
navegadores para PC de gran potencia con conexiones a Internet de gran ancho de
banda, XML incurre en una pena severa de rendimiento, tamaño de código y requisitos
de memoria para vocabularios pequeños y predeterminados. El MPEG defiende que
decodificar una stream binario de LASeR es mucho más eficiente que la complejidad
del parseado del XML y por lo tanto propone una codificación binaria para el contenido
SVG.
El formato binario especificado en LASeR permite la codificación del contenido
SVG. Utiliza una representación compacta para la estructura de los elementos de SVG y
utiliza algoritmos específicos de codificación para codificar los valores de los atributos
de los elementos de SVG.
Puesto que los terminales móviles generalmente carecen del hardware necesario
para el cálculo complejo, la compresión de estos valores de los atributos tiene que ser
más simple que las que se utilizan para un PC. De esta manera, la codificación binaria
de LASeR es sencilla, y su calidad reside en el equilibrio entre complejidad y eficiencia.
Se tuvo un cuidado especial para la codificación de los valores para algunos tipos de
atributos, como la lista de las coordenadas en coma flotante, las trayectorias de los
gráficos vectoriales o las matrices de transformación.
La sintaxis binaria de LASeR es extensible. Para poder mezclar extensiones
privadas con elementos y atributos normales de LASeR, las extensiones privadas son
ignoradas por los decodificadores que no saben procesarlas.
2.1.3.1.4 Escenas incrementales
Muchos servicios rich-media se basan en una característica clave de LASeR: Las
escenas incrementales posibles gracias al modo "append" de LASeR. El modo "append"
41
Tecnologías relacionadas
añade la posibilidad de crear un stream LASeR que en lugar de contener una escena
independiente, contiene una adición o añadido de otra escena ya existente.
Existen dos casos típicos del uso de escenas incrementales:
-
Estilo streaming: La escena se diseña como una secuencia de frames, y existe un
stream continuo de actualizaciones para transformar el frame actual en el frame
siguiente. El uso del ancho de banda va variando pero nunca cae a 0. Las
escenas incrementales de esta clase son generalmente transportadas mejor
mediante protocolos de streaming como RTP. Un caso típico de este uso es una
animación de tipo dibujos animados.
-
Estilo interactivo: La escena es interactiva y las peticiones de usuario son
procesadas por el servidor. La respuesta a la petición del usuario es un cambio
de la escena existente, no una nueva escena. Esta situación también requiere
actualizaciones continuas de la escena, pero la estadística de la transmisión es
totalmente diferente a la del estilo anterior: El ancho de banda es utilizado en
gran medida pero por un tiempo corto, justo después de una petición del usuario,
y después cae a 0 hasta la siguiente petición del usuario. Dado la variedad de
usos de aplicaciones móviles, la siguiente petición de un usuario podría
producirse a los pocos segundos o algunas horas más tarde.
2.1.3.1.5 Integración en la arquitectura del terminal
La siguiente figura muestra la arquitectura de un cliente LASeR en la que se
aprecia que LASeR se construye sobre SVGT 1.2. Se estima que un player dual
LASeR/SVG Tiny 1.2 compartiría más del 60% del código.
Actualmente la huella del software de referencia LASeR v1 (fichero Jar) en
Java, sin optimizar, es de unos 100K (excluyendo fuentes SVG, codecs, parser XML y
uDOM).
42
Tecnologías relacionadas
Arquitectura del Cliente LASeR
Además, del mismo modo que un player SVG Tiny, el cliente LASeR puede ser
integrado en un navegador de múltiples formas:
-
Como un plugin: con Netscape API o usando el API del browser específico
-
Como un plugin con el uDOM API: se trata de una integración más genérica y
que ofrece servicios más interoperables.
-
Siguiendo las recomendaciones de CDF/WICD (W3C): con esto se consigue
una integración totalmente genérica que ofrece servicios interoperables y los
documentos compuestos se presentan igual en todas las implementaciones.
Integración de LASeR en el navegador como un plugin
43
Tecnologías relacionadas
Integración de LASeR en el navegador según CDF/WICD
2.1.3.1.6 Ejemplos
A continuación se muestran varios ejemplos de contenidos rich-media creados
con LASeR:
Ejmplo de contenido LASeR
A continuación se muestra un ejemplo de contenido rich media para televisión
móvil:
Ejemplo de contenido LASeR para televisión móvil
44
Tecnologías relacionadas
2.1.3.2 SAF (Simple Aggregation Format)
La entrega de contenido rich-media a dispositivos móviles es una tarea compleja
que consiste en entregar la representación de la presentación junto con todo el material
audio-visual. La entrega eficiente, especialmente en redes móviles de reducido ancho de
banda, requiere reactividad y fluidez.
La especificación SAF define las herramientas para permitir el transporte del
contenido LASeR junto con su material audiovisual según estos requisitos. Para ello,
SAF define un formato binario para un stream SAF, hecho de un stream LASeR con
cualquier tipo de stream de medios (video, audio, etc.).
Los streams de SAF son streams multiplexados de bajo bitrate que se pueden
entregar con éxito usando cualquier mecanismo de entrega: descargar y reproducir,
descarga progresiva, streaming o broadcasting. Para alcanzar reactividad, la
especificación de SAF define el concepto de "cache unit" que permite enviar por
adelantado el subcontenido que será utilizado más adelante en la presentación.
Así pues, la especificación SAF define las herramientas necesarias para
satisfacer todos los requisitos del diseño de los servicios rich-media en lo que respecta
al interfaz entre la representación de la escena y los mecanismos de transporte. Sus
funciones más importantes son:
45
Tecnologías relacionadas
-
Agregación simple de cualquier tipo de stream de medios (streams MPEG o no
MPEG), dando como resultado un stream SAF con un esquema multiplexado de
bajo bitrate para redes de reducido ancho de banda.
-
Posibilidad de cachear streams SAF.
El resultado de la multiplexación de los streams de medios es un stream SAF
que se puede entregar con cualquier mecanismo de entrega: descargar y reproducir,
descarga progresiva, streaming o broadcast.
Las características principales del formato de multiplexado de LASeR son las
siguientes:
-
Sincronización de todos los streams y contenido.
-
Soporta la inclusión de un nuevo stream o actualización dentro de un stream
SAF existente.
-
Descarga progresiva.
-
Actualizaciones dinámicas.
-
Streamable.
-
Independiente de la Red (GPRS, 2.5G, 3G, DVB-H, DMB...).
-
Independiente de formato de archivo (MP4, 3GP, SAF...).
-
Independiente del tipo de transporte (HTTP, RTP...).
Actualmente, los streams SAF pueden ser (se pueden añadir nuevos streams):
-
Empaquetados en formato RTP/RSTP usando el formato de payload definido en
RFC3640.
-
Empaquetados en ficheros MP4/3GP usando un mapeo definido en SAF.
-
Empaquetados en el TS MPEG-2 usando el mapeo SL de ISO/IEC. 14496-8.
46
Tecnologías relacionadas
2.1.4 MORE (Mobile Open Rich-media Environment)
MORE es una tecnología que permite realizar servicios móviles rich media
combinando varias tecnologías de los estándares W3C, OMA, 3GPP y IETF (por
ejemplo, el perfil Mobile 1.2 del SVG, MBMS, y el ISO Media File Format). Los
diferentes componentes del sistema incluyen formateo, empaquetado, transporte,
renderizado e interacción con ficheros y streams rich media. La solución MORE es
compatible también con el JSR-226 (API que permite cargar, manipular, renderizar y
animar un contenido SVG Tiny).
La sintaxis de escenas en MORE se basa en la iniciativa de REX (Remote
Events para XML) del W3C dirigida por el Work Group del SVG. La especificación de
la propuesta de actualización XML se basará en un conjunto de requisitos que piensan
mantener compatibilidad con los eventos de DOM y bien integrados con la arquitectura
WWW. La sintaxis para el mecanismo de actualización no está limitada solamente a
SVG si no que es también extensible a otros leguajes de marcas, además de ser muy
eficiente y ligero para las plataformas que son ya capaces de soportar el estándar móvil
de SVG.
Como el formato de presentación para rich-media utilizado tanto en el work ítem
de OMA-RME como en el 3GPP-DIMS está basado en SVG, MORE proporciona una
solución para embeber el contenido de los gráficos vectoriales tales como SVG dentro
de los formatos de ficheros de medios existentes ISO 3GPP, para el streaming de
contenido rich-media sobre los servicios MMS/PSS/MBMS. Este método permitirá que
el formato del contenedor utilizado para empaquetar el contenido rich-media (gráficos,
vídeo, texto, e imágenes), posibilite a los servidores de streaming generar los paquetes
RTP, y a los clientes interactuar, reproducir, o renderizar el contenido rich-media.
MORE proporciona la capacidad de soportar interactividad entre los clientes y
los servidores de rich-media. Los mecanismos para la interactividad incluyen provisión
para la interactividad local (lado del cliente) y remota (servidor-cliente), así como
retroalimentación en tiempo real sobre varios protocolos de transporte broadcast y peerto-peer. Los mecanismos locales de interactividad en MORE se basan en el modelo de
eventos de SVG Mobile 1.2, diseñado después de los modelos de eventos de W3C XML
47
Tecnologías relacionadas
y el nivel 3 de DOM. Para la interacción remota, MORE proporciona un framework y
una sintaxis del formato del mensaje para la retroalimentación del cliente.
Arquitectura general de MORE
El sistema MORE se puede percibir como una arquitectura cliente-servidor,
comprimiendo los tres componentes principales
-
Servidor rich media: toma como entrada un contenido rich media que contiene
medios discretos y continuos SVG.
-
Mecanismos de transporte.
-
Cliente rich media.
Arquitectura cliente-servidor de MORE
48
Tecnologías relacionadas
El contenido SVG se representa en escenas que se pueden actualizar
dinámicamente con actualizaciones de las mismas. Este contenido rich media se puede
encapsular en un formato contenedor, con información adicional como sincronización
de los medios y metadatos. El sistema utiliza varios mecanismos de transporte tanto
unicast como multicast para descargar los escenarios. El contenido se muestra en el
cliente, permitiendo interactividad local y remota y peticiones de datos.
Algunos de los ejemplos que se pueden realizar con el sistema MORE son los
siguientes:
-
Servicio de karaoke que muestra los caracteres SVG con un video clip.
-
Chat live que permite a los usuarios intercambiar dinámicamente contenido rich
media.
-
Servicio de televisión móvil interactiva para proporcionar acceso al contenido
de televisión y servicios adicionales dentro de los programas de televisión, como
votaciones.
2.1.4.1 Componentes
La tabla siguiente presenta los diversos componentes o áreas de alcance dentro
de la arquitectura de MORE, una breve descripción, organismos de estandarización
relevantes SDO (Standard Development Organization) y el estado de su publicación
49
Tecnologías relacionadas
Estado de la propuesta de MORE
2.1.4.2 Escenas y actualización de escenas
La escena, basada en el formato SVG, describe la organización espacial y
temporal de los elementos de la escena, la sincronización de la información y la
interacción entre los elementos. La escena es, o bien un documento SVG completo, o
bien contenido encerrado dentro de un grupo de elementos, enviado primero para
inicializar la distribución de la presentación en el cliente. Las actualizaciones de la
escena son actualizaciones incrementales de la escena que cumplen DOM. Estas
actualizaciones incluyen la agregación de uno o más elementos, el borrado de
elementos, el reemplazo de elementos y las operaciones de actualización de los atributos
de los elementos. El cliente entonces actualiza el documento SVG sin destruir ni recrear
el fichero SVG para cada paquete de información.
50
Tecnologías relacionadas
2.1.4.3 Formato contenedor
SVG soporta los elementos multimedia de una forma similar a SMIL. Los
elementos multimedia continuos contienen su propio frame predefinido basado en el
tiempo. El servidor es responsable de generar y transmitir paquetes que contengan datos
rich media a los clientes, de una manera temporal. Para ello, se utiliza un formato
contenedor para empaquetar de una forma eficiente los diferentes datos, proporcionando
sincronización de tiempo y permitiendo a los clientes realizar, ejecutar o representar
contenido rich media.
Los datos SVG, al ser un lenguaje basado en XML, se pueden almacenar en
ficheros individuales.
2.1.4.4 Mecanismos de transporte
Los mecanismos de transporte soportan la entrega de contenido rich media en
modo descarga unicast (http/TCP o MMS), descarga broadcast y multicast
(FLUTE/UDP o ALC/UDP), streaming unicast y streaming broadcast y multicast
(RTP/UDP). Los protocolos de transporte utilizados son:
-
Para descargas unicast: HTTP/TCP o MMS.
-
Para descargas broadcast/multicast: FLUTE/UDP o ALP/UDP.
-
Para streaming unicast/broadcast/Multicast: RTP/UDP.
51
Tecnologías relacionadas
Protocolos de transporte usados en MORE
Durante una aplicación rich media, un cliente puede informar sobre la calidad de
la transmisión y la presentación al servidor. Esa información es muy útil para el servidor
para tomar decisiones óptimas sobre el ajuste de los mecanismos de sincronización y del
esquema de transporte. Estas métricas nuevas definidas de QoS son: El número de
paquetes RTP perdidos durante un periodo específico, la lista de elementos SVG que no
han sido recibidos y decodificados correctamente, los elementos SVG recibidos,
decodificados y activados correctamente, la duración de la corrupción y los grupos
corruptos.
2.1.4.5 Interacción
Durante una presentación rich media, un usuario puede interactuar con el cliente
para solicitar más información, actualizar el contenido o incluso enviar información al
servidor. SVG proporciona interacción local a través de animaciones declarativas y
scripting.
La información de feedback tiene dos partes. La primera parte: contiene MSG
ID (identificador único para identificar el mensaje feedback desde el cliente),
52
Tecnologías relacionadas
ELEMENT ID (ID del elemento origen en SVG DOM que lanza el evento) y EVENT
(evento SVG o un evento definido por el usuario).
Estos datos de feedback se almacenan como una serie de octetos.
2.1.4.6 Cliente MORE
El cliente MORE es un cliente ligero debido a que se sitúa por encima de SVG
Mobile 1.2, ESMP y XHTML-basic. De ese modo puede reutilizar algunos
componentes como el parser XML, librerías de renderizado y decodificadores. El
cliente utiliza un paquete para desempaquetar los medios y obtener los diferentes
medios que constituyen la escena y las actualizaciones de las escenas.
El motor SVG toma los diferentes medios y la información de tiempo para
componer dinámicamente la presentación rich media. El cliente además es responsable
de transmitir el feedback que ocurra durante la interacción.
El cliente usa los media packet depacketizers para la obtención de los diferentes
medios que constituyen la escena y para la actualización de escenas en el caso de
streaming en tiempo real.
Si se trata de downloads, los medios son local o remotamente referenciados. En
este caso, el módulo de sincronización ayuda a sincronizar el frame rate y el timing de
los medios continuos con el contenido SVG, el motor SVG toma los medios y la
información de timing para componer la presentación rich media dinámicamente.
Además, el cliente es responsable de enviar las respuestas asociadas a las
interacciones.
53
Tecnologías relacionadas
Arquitectura del cliente MORE
2.1.4.7 Integración con el navegador
La integración con el navegador en MORE seguirá las directrices y también
dirigirá el trabajo del W3C relativo a Compound Documents Format (CDF). Este grupo
de trabajo del W3C está investigando la problemática relativa a combinar diferentes
lenguajes de marcado (XHTML+SVG, etc.) en un mismo documento, como por
ejemplo la propagación de eventos, las interacciones de usuario, la presentación, etc.
MORE soporta la inclusión de contenido SVG Mobile 1.2 en un documento
XHTML usando el tag <object> a través de la arquitectura de plug-in estándar del
navegador. En el largo plazo MORE se extenderá para soportar perfiles de documento
compuesto (CDR y CDI).
El Document Object Model (DOM) soportado en MORE se basa en el
subconjunto SVG DOM (uDOM) tal y como se define en la especificación SVG Mobile
1.2. El soporte de uDOM proporciona una API que permite manipular dinámicamente el
contenido Rich Media para por ejemplo, modificar atributos y valores de propiedades,
crear elementos, etc. El scripting en MORE se maneja a través del elemento ‘script’ que
54
Tecnologías relacionadas
contiene código ejecutable (código fuente ESMP o Java - archivo JAR compatible con
la API JSR 226).
2.1.4.8 Ejemplos
El siguiente ejemplo está realizado con MORE. Es una representación de una
actualización de contenido y de la interacción del usuario con una aplicación rich media.
En el paso a la escena rich media inicial es recibida por el cliente MORE. En el
paso b el usuario solicita más información a través del botón de menú. El contenido se
actualiza después de que el cliente transmita su petición y recibe la escena actualizada
en el paso c y en el paso d pulsa sobre diferentes regiones del mapa, obteniendo un
video informativo por streaming sobre la región indicada.
Ejemplo de contenido rich media MORE
55
Tecnologías relacionadas
2.1.5 Comparativa de tecnologías
Todas las tecnologías analizadas son tecnologías rich media que incluyen una
mayor potencia expresiva y permiten mezclar diversos elementos multimedia
(audio/video, imágenes, texto, elementos interactivos etc.) de forma sincronizada en una
presentación. De entre todas ellas es recomendable descartar la solución propietaria de
Flash Lite porque tal y como se comentó anteriormente, no es un estándar abierto y por
tanto es complicado conseguir un soporte de la industria masivo.
De las tecnologías restantes, si comparamos LASeR y MORE podemos apreciar
que ambas tecnologías persiguen el mismo propósito pero existen ciertas diferencias
entre ellas en los siguientes aspectos:
-
Compresión: LASeR define su propio mecanismo de compresión mientras que
MORE no define ninguno (recomienda GZIP para las escenas).
-
Mecanismos de sincronización: LASeR define un marco completo de
sincronización basado en tiempos y en frames mientras que MORE soporta los
mecanismos de SVG Tiny 1.2.
-
LASeR es ya un estándar internacional (en fase de evolución). MORE, en
contra, es un conjunto de estándares en diferente grado de avance.
Debido a que MORE se encuentra en las primeras fases del proceso de desarrollo,
para trabajos actuales no se recomienda su utilización. Por ese motivo, centraremos
nuestra atención en las tecnologías SVG y LASeR. A continuación se muestran las
principales características de ambas tecnologías.
Resumen de SVG y LASeR
Tecn.
SVG
Descripción
Lenguaje que permite la creación de gráficos vectoriales 2D
basado en XML.
Permite cierto dinamismo e interactividad así como integrar
audio y video.
Existen varios motores de renderizado SVG tanto propietarios
como de libre distribución.
La JSR 226 incorpora SVG Tiny 1.1 y la futura JSR 287
56
Grupo de
estandarización
W3C.
3GPP y OMA
colaboran para su
adopción en el
entorno móvil.
Tecnologías relacionadas
incorporará SVG Tiny 1.2.
LASeR
LASeR se basa en SVG 1.2. Añade extensiones para crear
servicios rich media, como:
- Compresión eficiente
- Tamaño de código y uso de la memoria ajustado
MPEG.
En consideración
dentro de RME
de OMA.
- Sincronización de la escena a nivel de frame con los elementos
audiovisuales
-Posibilidad de hacer streaming del contenido LASeR
- Permite la creación dinámica de respuestas a una petición del
usuario y su integración en la escena actual, o la inserción
dinámica de contenido en la escena existente. Características
importantes en cualquier servicio que requiera la creación de una
escena nueva o modificación de la actual en tiempo real como
consecuencia de la interacción del usuario.
LASeR compone un framework completo desde la creación,
presentación y transporte (SAF) de los contenidos, permitiendo
el sincronismo de todos los streams junto con el contenido
principal.
SVG, por su lado, presenta varios inconvenientes:
1. No permite la creación dinámica de respuestas a una petición del usuario y
su integración en la escena actual (mecanismo de actualización de escenas),
o la inserción dinámica de contenido en la escena existente, lo cual
empobrece la experiencia y la fluidez de la experiencia de usuario en
servicios interactivos como votaciones, apuestas, cuestionarios, etc.
2. SVG es un XML que se apoya sobre el modelo de consumo de HTML. Por
tanto, no es posible desarrollar interactividad a nivel de frame (servicios del
tipo película enriquecida con capas superpuestas de gráficos vectoriales e
interactividad).
Estas limitaciones son superadas por LASeR que se perfila como la
especificación más completa ya que está construido sobre SVG 1.2. En la siguiente
figura se muestra una comparativa de LASeR con respecto a otras tecnologías en
función de su potencia expresiva y características gráficas:
57
Tecnologías relacionadas
Comparativa de LASeR con otras tecnologías
Frente a LASeR, SVG juega con la ventaja de que muchos teléfonos móviles
incluyen un reproductor SVG y además Java ofrece métodos para cargar y reproducir
archivos SVG (JSR 226 y futuro JSR 287) lo que permite desde cualquier aplicación
Java acceder fácilmente a esta tecnología, cosa que con LASeR actualmente no sucede
(LASeR requiere de un middleware en el terminal).
2.2 Guías de programación
Las guías electrónicas de programas y/o servicios es una de las múltiples
prestaciones que ofrece la televisión digital. Gracias a ellas se ofrecen al usuario todos
los canales de los que dispone un distribuidor de televisión organizados de manera
rápida y sencilla. Estas guías electrónicas representan la evolución a la era digital del
tradicional servicio de programación que ofrece el teletexto.
A través de estas guías electrónicas el usuario puede consultar la programación
de los diferentes contenidos televisivos para cada una de las cadenas ofertadas, así como
(dependiendo de la guía) consultar los diferentes servicios ofertados.
58
Tecnologías relacionadas
Actualmente existen dos tipos de guías de programación:
-
EPG (Electronic Program Guide): sólo permite consultar la programación de los
contenidos televisivos.
-
ESG (Electronic Service Guide): además de permitir la consulta de la
programación televisiva, permite acceder a cualquier tipo de servicio que se
distribuya mediante IPDC (IP Datacasting).
A continuación se analizan en detalle ambas guías de programación.
2.2.1 EPG
En una EPG (Electronic Program Guide) se puede acceder a la programación de
los contenidos televisivos y además permite realizar una búsqueda exhaustiva
seleccionando diferentes temáticas (deportes, series, películas, informativos, etc) ó
mostrar información detallada sobre un contenido en concreto (sinopsis, título, director,
personajes, año de producción, etc).
Generalmente se utiliza el término EPG para hacer referencia al sistema capaz
de mostrar en el terminal la lista de canales y/o servicios de un determinado proveedor y
que permite al usuario navegar por ellos, seleccionarlos, descubrir contenido por
tiempo, título, canal, género, etc, mediante un control remoto, teclado e incluso un
teléfono móvil. La tecnología se basa en el broadcast de datos hacia una aplicación
residente (generalmente en un middleware dentro de un set-top box).
La presentación en pantalla viene dada mediante un menú o retícula donde se
estructuran las diferentes opciones que se ofrecen. Así, el usuario mediante su mando a
distancia puede navegar y acceder a los diferentes servicios. Dependiendo del operador
que proporcione la EPG, el formato, colores, así como la organización pueden variar,
pero siempre se busca la forma más fácil de presentarla para que su manejo resulte
sencillo y eficaz.
59
Tecnologías relacionadas
Elementos típicos de la interfaz de usuario de una EPG son el nombre del canal
y los programas que se ofrecen desde cada uno de los subcanales (pago por visión,
VOD, géneros, etc). Por cada programa se ofrece información adicional como el título,
descripción, synopsis, actores, directores, año de producción etc. La información se
muestra normalmente en forma de retícula, con la opción de mostrar más información
de cada programa. Las EPG de Radio suelen ser algo más simples y basadas en texto,
ofreciendo información del artista, el álbum, título, etc.
La EPG también puede estar conectada a un PVR (Personal Video Recorder) y
en este caso es posible planificar el visionado de programas o su grabación a disco para
un visionado posterior. Otras funciones son la construcción de sumarios, búsquedas por
género, acceso a un programa seleccionado, recordatorios (alertas), funciones de control
parental, etc.
La EPG es normalmente enviada en el broadcast transport stream, pero también
puede enviarse por un canal de datos especial.
En DVB, la EPG viene encapsulada dentro del Transport Stream, donde además
de los paquetes correspondientes a las emisiones de los diferentes canales de televisión,
encontramos paquetes de datos correspondientes a servicios de información de las
diferentes emisiones. Estos datos se encuentran estructurados en tablas, y en concreto
los datos correspondientes a la EPG se encuentran en la Service Info Table (DVB-SI).
Estos paquetes de datos llegan al set-top box donde son descodificados y procesados
para extraer la información.
A continuación se muestran algunos ejemplos de EPG:
60
Tecnologías relacionadas
Ejemplos de EPG
2.2.2 ESG
Las guías electrónicas actuales de programa usadas para DVB-T no son
suficientes para los servicios IP puesto que el IP datacasting permite la transmisión de
todo tipo de servicios. La EPG de DVB-T está enfocada solamente para describir
61
Tecnologías relacionadas
programas, mientras que con el IPDC (IP datacasting) los servicios pertenecen a una
gama mucho más amplia. Por ejemplo, sería muy complicado describir un videojuego
con una EPG. Por lo tanto, es necesaria una nueva guía para describir medios en IPDC.
Esta nueva guía se denomina guía electrónica de servicios o ESG (Electronic Service
Guide). La guía de servicios ESG es el punto de entrada de cualquier servicio
distribuido por IPDC.
De una manera genérica se puede describir una guía de servicios como uno o
varios ficheros XML con la información de la programación de un determinado canal o
canales de televisión. Para que un usuario sintonice un canal de televisión deberá
primero acceder a la guía de servicios y seleccionar el canal adecuado.
La guía se construye sobre el esqueleto de TV-Anytime puesto que la mayoría
de los servicios previstos que serán transportados por DVB-H probablemente sean
programas de audio y vídeo. La ESG y TV-Anytime se basan en XML.
La ESG consiste, básicamente, en un fichero XML con información asociada a
un stream (vídeo, audio) distribuido vía DVB-H. La ESG contiene la información sobre
los servicios digitales disponibles. Con la información de la ESG, el consumidor puede
visionar y comprar los servicios disponibles, seleccionar los servicios y los elementos
por los que está interesado y localizar los elementos almacenados en su terminal.
Esta información asociada puede incluir todo tipo de elementos entre los que
destacan horarios de emisión, precios, descripción del contenido, aplicaciones o
imágenes asociadas al stream, datos para la interacción del usuario final, etc.
Además del fichero XML, la ESG también incluye ficheros SDP que el terminal
necesita para localizar los streams y presentarlos correctamente. Asimismo, otros
contenidos pueden estar incluidos en la ESG, como pueden ser los logos o imágenes
asociados a un canal o programa concreto.
Las operaciones de la ESG ocurren después de que el receptor de DVB-H es
arrancado y el terminal se sincroniza con un stream de transporte particular que lleva
servicios IPDC. Una vez la información ESG es procesada y mostrada al usuario
mediante una aplicación cliente para la ESG, se puede seleccionar un servicio
62
Tecnologías relacionadas
específico. La ESG es por tanto el primer servicio interactivo y fundamental para el
usuario ya que la aplicación cliente, con esta información, mostrará al usuario la lista de
servicios disponibles y la posibilidad de seleccionarlos.
El descubrimiento de servicios es el mecanismo y proceso por el cual el terminal
adquiere la Guía Electrónica de Servicios.
A continuación se muestran unos ejemplos de ESG:
Ejemplos de ESG
63
Tecnologías relacionadas
Como en otros sistemas, los dos canales (broadcast e interactivo) constituyen
una alternativa a la hora de distribuir las ESGs. Por tanto, existen tres métodos
diferentes para la distribución:
•
Distribución íntegra por el canal de broadcast. En este caso todos los servicios
pueden ser vistos por todos los clientes. Lo más interesante de este método es la
sencillez de la distribución, puesto que las ESG se están enviando por un timeslice dedicado del que leen todos los terminales independientemente de los
servicios que tengan contratados. La sencillez implica la desventaja de tener que
dedicar un time-slice a las ESGs donde podrían ir otros servicios o streams. Otra
ventaja es que el cliente podrá ver en su terminal qué se está ofreciendo en
canales de pago, con lo que tiene un valor añadido al publicitar servicios que el
cliente puede comprar.
•
Distribución íntegra por GPRS/UMTS. Aquí cada cliente podría recibir la guía
de servicio a su medida, incluso pudiéndose construir él mismo una a la carta. La
ventaja de enviarle a un cliente una guía personalizada implica, no sólo mayor
comodidad para éste, sino también la posibilidad de enviarle sólo los servicios
que tenga contratados o de pago que pudieran interesarle, con lo que se evitaría
una carga excesiva de la red.
•
Distribución híbrida. Podría consistir, por ejemplo, en mandar los paquetes
comunes a todos los usuarios vía broadcast, incluyendo tanto contenidos
gratuitos o suscripciones básicas, como servicios que interese publicitar
mediante la guía a todos los usuarios. Por la red GPRS/UMTS se podría enviar
la parte personalizada a cada cliente. De esta forma además se consigue no
emplear en exceso ninguna de las dos redes, aunque se consuman recursos de
ambas.
A continuación se muestra un ejemplo de un modelo de datos ESG que se puede
utilizar para indicar la disponibilidad de una pista de audio en francés adicional durante
el broadcasting de un único ítem de contenido. Esto se realiza a través de la
64
Tecnologías relacionadas
instanciación de Acquisition Fragment que describe todos los componentes disponibles
y anuncia la disponibilidad de contenidos.
<ESGMain xmlns="urn:dvb:ipdc:esg:2005"
xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001"
xmlns:tva="urn:tva:metadata:2005"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<ESG>
<ContentTable>
<Content contentID="dvbipdc://example.com/Content1">
<Title xml:lang="en">Content Item 1</Title>
<Genre href="urn:tva:metadata:cs:ContentCS:2005:1.4.5"/>
<Duration>PT30M</Duration>
</Content>
<Content contentID="dvbipdc://example.com/Content21">
<Title xml:lang="en">Content 21</Title>
<Genre href="urn:tva:metadata:cs:ContentCS:2005:1.6"/>
<Duration>PT30M</Duration>
</Content>
<Content contentID="dvbipdc://example.com/Content100">
<Title xml:lang="en">Content Item 100</Title>
<Genre href="urn:tva:metadata:cs:ContentCS:2005:1.4.5"/>
<Duration>PT45M</Duration>
</Content>
</ContentTable>
<ScheduleEventTable>
<ScheduleEvent>
<PublishedStartTime>2006-03-02T20:15:00Z</PublishedStartTime>
<PublishedEndTime>2006-03-02T21:00:00Z</PublishedEndTime>
<ServiceRef IDRef="dvbipdc://example.com/Channel1" />
<ContentFragmentRef IDRef="dvbipdc://example.com/Content100"
/>
</ScheduleEvent>
<ScheduleEvent>
<PublishedStartTime>2006-03-02T21:00:00Z</PublishedStartTime>
<PublishedEndTime>2006-03-02T21:30:00Z</PublishedEndTime>
<ServiceRef IDRef="dvbipdc://example.com/Channel1" />
<ContentFragmentRef IDRef="dvbipdc://example.com/Content21"
/>
<AcquisitionRef
IDRef="dvbipdc://example.com/Acquisition/MultiLingualevent" >
<Label>Multiple Audio</Label>
</AcquisitionRef>
</ScheduleEvent>
<ScheduleEvent>
<PublishedStartTime>2006-03-02T21:30:00Z</PublishedStartTime>
<PublishedEndTime>2006-03-02T22:00:00Z</PublishedEndTime>
<ServiceRef IDRef="dvbipdc://example.com/Channel1" />
<ContentFragmentRef IDRef="dvbipdc://example.com/Content1" />
</ScheduleEvent>
</ScheduleEventTable>
<ServiceTable>
<Service serviceID="dvbipdc://example.com/Channel1">
<ServiceName>Channel1</ServiceName>
<AcquisitionRef
IDRef="dvbipdc://example.com/Acquisition/Channel1" />
65
Tecnologías relacionadas
</Service>
</ServiceTable>
<AcquisitionTable>
<!-- Generic Acquisition fragment containing the default Audio
track -->
<Acquisition contentMimeType="video/H264"
acquisitionID="dvbipdc://example.com/Acquisition/Channel1" >
<ComponentDescription>
<ComponentCharacteristic xsi:type="VideoComponentType">
<CodecCharacteristic>
<Codec href="urn:dvb:cs:VideoCodecCS:2006:1.1.2"/>
</CodecCharacteristic>
<FrameRate>25</FrameRate>
</ComponentCharacteristic>
<ComponentCharacteristic xsi:type="AudioComponentType">
<Codec href="urn:dvb:cs:AudioCodecCS:2006:1.3.2"/>
<Language>en</Language>
</ComponentCharacteristic>
<SessionDescription xsi:type="SDPRefType" >
<SDPStream>
<![CDATA[v=0o=example.com 751092616 751111042 IN IP4
10.45.2.30 s=SDP Delivery for Channel1 t=0 0 a=flutech:1
m=application 12345 FLUTE/UDP 0 c=IN IP4
239.255.255.102/127
a=flute-tsi:98765432 ]]>
</SDPStream>
<SDPURI>http://example.com/defaultSDP</SDPURI>
</SessionDescription>
</ComponentDescription>
</Acquisition>
<Acquisition contentMimeType="video/H264"
acquisitionID="dvbipdc://example.com/Acquisition/MultiLingualev
ent" >
<ComponentDescription>
<ComponentCharacteristic xsi:type="VideoComponentType">
<CodecCharacteristic>
<Codec href="urn:dvb:cs:VideoCodecCS:2006:1.1.2"/>
</CodecCharacteristic>
<FrameRate>25</FrameRate>
</ComponentCharacteristic>
<ComponentCharacteristic xsi:type="AudioComponentType">
<Codec href="urn:dvb:cs:AudioCodecCS:2006:1.3.2"/>
<Language>en</Language>
</ComponentCharacteristic>
<ComponentCharacteristic xsi:type="AudioComponentType">
<Codec href="urn:dvb:cs:AudioCodecCS:2006:1.3.2"/>
<Language>fr</Language>
</ComponentCharacteristic>
<SessionDescription xsi:type="SDPRefType" >
<SDPStream>
<![CDATA[v=0 o=example.com 751092616 751111042 IN IP6
FE80::1:4D3E s=SDP Delivery t=0 0 a=flute-tsi:9532 a=flutech:1 a=source-filter: incl IN IP6 * FE80::2::70CA
m=application 12345 FLUTE/UDP 0 c=IN IP6 FF15::1:141B ]]>
</SDPStream>
<SDPURI>http://example.com/multiAudioSDP</SDPURI>
</SessionDescription>
66
Tecnologías relacionadas
</ComponentDescription>
</Acquisition>
</AcquisitionTable>
</ESG>
</ESGMain>
Actualmente existen dos estándares referentes a la ESG, uno desarrollado por el
grupo CBMS del DVB Project (ver capítulo ANEXOS apartado ORGANISMOS DE
ESTANDARIZACIÓN RELACIONADOS subcapítulo DVB) y estandarizado por el
ETSI, y otro, aun en desarrollo, del grupo de trabajo BCAST de OMA (ver capítulo
ANEXOS apartado ORGANISMOS DE ESTANDARIZACIÓN RELACIONADOS
subcapítulo OMA). En los siguientes capítulos se detallan ambos estándares.
2.2.2.1 ESG de CBMS (DVB)
La siguiente figura muestra la arquitectura funcional de la ESG según el DVB:
Arquitectura Funcional de la ESG
Entre los bloques funcionales que forman parte de la arquitectura, se encuentran:
67
Tecnologías relacionadas
•
Fuente de la ESG (ESG Source). Genera los distintos fragmentos de le ESG
incluyendo la información de adquisición, compra, etc.
•
Fuente de información de compra (ESG purchase information). Genera la
información de compra.
•
Agregación lógica de ESG (Specific logical ESG aggregator). A partir de
bloques de ESG individuales se generan bloques de información ESG
exportados al agregador físico.
•
Agregación de Bootstrap ESG (Bootstrap ESG aggregator). Recibe los distintos
bloques de información ESG y genera el stream bootstrap (permite "descubrir" y
acceder a las diferentes guías de cada operador).
•
Calendario de eventos (Resource provisioning & scheduling). Planificación
sobre el envío de las ESG a los terminales.
•
Distribuidor de ESG por el canal interactivo (Interactive delivery Server).
Proporciona un acceso punto a punto (pull o push) para la entrega de la ESG por
el canal interactivo.
•
Agregación física de ESG (Physical ESG aggregator). Recibe archivos de
bootstrap y bloques de información de ESG. Ambos se introducen en un carrusel
FLUTE, optimizando la introducción en las diferentes ráfagas de DVB-H.
En la siguiente figura se muestra el modelo de datos de la ESG definido por el
DVB que se basa en un esquema XML dividido en diferentes fragmentos:
68
Tecnologías relacionadas
Esquema de la ESG
•
Servicio. Describe un servicio IPDC proporcionando todos los parámetros que lo
caracterizan como son el nombre del servicio, el número asignado al servicio, el
logotipo, una descripción, el género del servicio, el tipo (stream o descarga), la
clasificación por edades, el idioma, el proveedor del servicio, una referencia al
bloque de datos sobre la adquisición del servicio, referencias al material
relacionado con el servicio, datos privados, un identificador único del servicio,
un campo para indicar si el contenido está protegido y otro para indicar si se
protege mediante técnicas de "scrambling".
•
ServiceBundle. Grupo de objetos ofrecidos al usuario en forma de servicios.
Este agrupamiento puede usarse para ligar información de compra o añadir
información en el contexto del grupo. Este fragmento maneja datos como
nombre del bundle, proveedor, título del servicio relacionado, descripción,
genero, referencia al servicio, clasificación por edades, material relacionado y un
ID único del conjunto.
•
Contenido. Define un contenido con independencia de su formato o forma de
distribución. Éste se define con un título, una referencia a un sonido o imagen
que sirva de título para presentarlo, una referencia al servicio que lo contenga,
una sinopsis, unas palabras clave, un género, un tipo de contenido, una
69
Tecnologías relacionadas
clasificación por edades, un idioma, un idioma de subtítulos, un idioma de
signos, una lista de créditos, una referencia a material relacionado, una duración,
un campo para datos privados y un identificador único.
•
Calendario de eventos. Especifica cuándo van a ser distribuidos los contenidos
de un servicio. Para ello se precisa conocer ciertos datos como la hora de
comienzo de un contenido, la hora de fin, la referencia al servicio, la referencia
al contenido, la referencia a los datos de adquisición, la localización del
contenido, si el contenido es en directo o repetido, si está protegido, si se ha
usado "scrambling" y un identificador único.
•
Compra. Contiene la información de compra de un servicio con el objetivo de
ser mostrada al usuario. Además, incluye una referencia a un ServiceBundle por
lo que incluye el precio, tipo de compra (suscripción, pago por visión, etc),
unidad cuantitativa (hora, día…), rango de cantidad de unidades que se pueden
comprar, descripción, la petición que se debe realizar para iniciar el proceso de
compra, sistema DRM, datos de compra, referencia al canal de compra, título en
forma de imagen o sonido, periodo de validez de la información e identificador
único.
•
Canal de compra. Especifica el interfaz por el que el terminal o el usuario
pueden realizar la compra. Maneja datos como nombre, descripción, URL del
portal para hacer la compra, información de contacto, título en formato de
imagen o sonido, datos privados y un ID único.
•
Adquisición. Contiene información como la descripción del componente y de la
sesión, el MIME-type del contenido, características de adquisición e
identificador de adquisición entre otros, que sirven para la adquisición de cada
contenido y servicio.
2.2.2.2 ESG de BCast (OMA)
A continuación se muestra una figura con los bloques funcionales propuestos por
OMA necesarios para la creación, procesado y distribución de la ESG y su descripción:
Componentes de la función de la Guía de Servicios
70
Tecnologías relacionadas
•
Fuente de la ESG de la Creación de Contenidos (SGCCS). Ofrece información
de las características de los contenidos como pueden ser el perfil de los usuarios
o las capacidades de los terminales objetivo.
•
Fuente de la ESG de la Aplicación (SGAS). Ofrece información y descripción
de los usuarios, de los terminales y de la localización de los mismos, de los
servicios y los contenidos, la planificación, etc.
•
Fuente de la ESG de Suscripción (SGSS). Ofrece información de precios, de
aprovisionamiento, de la suscripción, información promocional, etc.
•
Adaptador de la ESG (SG-A). Adapta la ESG de acuerdo al Sistema de
Distribución Broadcast (Broadcast Distribution System, BDS) o lo que es lo
mismo, a la red del difusor.
•
Distribuidor de la ESG (SG-D). Es el encargado de distribuir la guía de
servicios. La distribución de la guía de servicios puede hacerse a través de la red
del difusor, pasando previamente por el sistema de adaptación si es necesario
adaptarla de acuerdo al BDS, a través de la red interactiva, tras una petición de
envío de la guía, o mandándola directamente a la red del operador de difusión
siendo éste el que la adapte y la envíe.
71
Tecnologías relacionadas
Cliente (SG-C). El terminal se encarga de recibir la información de la ESG,
desde la red broadcast o por el canal de interactividad, y hacerla disponible a otras
funciones del terminal llegando a realizar filtros de la misma de acuerdo al perfil de
usuario, capacidades del terminal, etc. La información de la ESG se muestra en un menú
o similar al usuario y este cliente puede enviar una petición a través de SG-C para
recuperar alguna información específica de la misma o incluso para volver a solicitar la
ESG al completo.
72
Tecnologías relacionadas
2.3 Sistemas
de
vinculación
de
contenidos
Los contenidos interactivos que son entregados al terminal del usuario deben
estar vinculados con el contenido principal que se esté emitiendo en ese momento. Por
ejemplo, si existe un contenido principal del tipo Gran Hermano y existe un contenido
interactivo de votación para votar a la persona a la que se desea expulsar de la casa,
ambos contenidos deben estar vinculados para que el contenido interactivo sea
entregado en el dispositivo móvil mientras se está visualizando el programa de Gran
Hermano y no mientras se visualice otro contenido televisivo.
No existen estándares que regulen la vinculación entre contenidos interactivos y
contenidos principales televisivos. Por ese motivo, cada empresa utiliza sus propias
técnicas de vinculación. Alcatel y Siemens, por ejemplo, disponen de mecanismos
propietarios para llevar a cabo este tipo de vinculaciones. Sin embargo, la gran mayor
parte del resto de las empresas utilizan la ESG para poder realizar esta vinculación. Para
ello, se hace uso del fragmento RelatedMaterial de la ESG, ya que hace referencia a
elementos relacionados con el servicio descrito permitiendo incluir una URL en la que
se pueda obtener información sobre el contenido interactivo.
A continuación se muestran varios ejemplos de fragmentos RelatedMaterial en
los que se puede observar cómo es posible referenciar elementos relacionados con el
contenido televisivo:
-
el recurso al que se apunta es una preview del contenido que se está ofreciendo
en ese momento:
<Content contentID="dvbipdc://example.com/Content5">
<Title xml:lang="en">Content Item 5</Title>
<Genre href="urn:tva:metadata:cs:ContentCS:2005:1.4.5"/>
<RelatedMaterial>
<HowRelated href=“urn:dvb:ipdc:cs:HowRelatedCS:2006:13”/>
<MediaLocator>
<mpeg7:MediaUri>rtsp://www.example.com/dvb/preview/Content5.mp4</mpeg7
:MediaUri>
</MediaLocator>
</RelatedMaterial>
<Duration>PT30M</Duration>
</Content>
73
Tecnologías relacionadas
-
se apunta a una página html que proporciona más información sobre el
contenido ofertado:
<Content contentID="dvbipdc://example.com/Content4">
<Title xml:lang="en">Content Item 4</Title>
<Genre href="urn:tva:metadata:cs:ContentCS:2005:1.4.5"/>
<RelatedMaterial>
<HowRelated href=”urn:dvb:ipdc:cs:HowRelatedCS:2006:7”/>
<MediaLocator>
<mpeg7:MediaUri>http://www.example.com/Details/Content4.html</mpeg7:Me
diaUri>
</MediaLocator>
</RelatedMaterial>
<Duration>PT30M</Duration>
</Content>
Como se puede ver en los ejemplos anteriores, mediante este fragmento es
posible apuntar a una URL. Para el caso de realizar la vinculación de contenidos, esta
URL podría ser la de un servidor en el que se encuentren los contenidos interactivos. De
esa forma, accediendo al servidor mediante esa dirección se podría acceder a dichos
contenidos.
El principal problema que presenta esta solución es que no permite indicar el
segundo exacto del contenido televisivo en el que deben aparecer los contenidos
interactivos. Esto, en cambio, sí es posible a través de las tecnologías propietarias de las
que disponen Alcatel o Ericsson.
74
Tecnologías relacionadas
2.4 Tecnologías
de
presentación
de
contenidos
Para que el contenido interactivo pueda ser visualizado en el terminal del usuario
es necesario que dicho terminal tenga integrado un motor rich media (motor de
renderizado que permite integrar todos los medios en una única presentación).
A continuación se describen los motores rich media más importantes que existen
en el mercado:
2.4.1 Streamezzo Rich Media Engine
Streamezzo Rich Media Engine es un software construido sobre el motor LASeR
MPEG-4 part 20 (incluyendo SVG Tiny). Es el cliente multimedia de la Suite Software
Rich Media de Streamezzo que incluye Streamezzo Studio y Streamezzo Service Node.
Streamezzo Rich Media Engine es capaz de juntar todos los tipos de recursos
multimedia sin estar obligados a pasar del navegador a los reproductores de video y
audio. Permite interactuar con el dispositivo móvil y navegar a través de diferentes
servicios rich media.
La arquitectura de Streamezzo Rich Media Engine está compuesta de:
-
un motor del núcleo que se dedica principalmente al renderizado de la escena
LASeR
(motor
bitmap/vector,
motor
fuente
y
texto,
dispositivo/fichero/sistema operativo, motor de codecs audio/video).
-
múltiples motores de negocio (SMS/MMS/mensajería).
-
un SDK disponible para Symbian y J2ME.
75
motor
Tecnologías relacionadas
Arquitectura de Streamezzo Rich Media Engine
Las características que presenta son las siguientes:
-
Proporciona una interfaz unificada para ofrecer a los clientes servicios
multimedia interactivos de Mobile TV, portales, etc
-
No es necesario desarrollar una versión por dispositivo específico
-
Puede integrarse como un plug-in en un navegador xHTML/WAP y ser lanzado
mediante una URL.
Se encuentra disponible para muchos sistemas operativos (Symbian 6, 7 y 8,
Windows CE, J2ME MIDP 1.0/MIDP 2.0, Doja, Linux) y presenta una pequeña
footprint (inferior a 150KB).
Los codecs soportados son los siguientes: MPEG-4 AAC, MPEG-4 HE-AAC,
3GPP AMR, H.263, H.264.
Streamezzo Rich Media Engine está escrito en C/C++ con el fin de poder ser
portado fácilmente a sistemas operativos nativos.
Las capas de transporte utilizadas son: LASeR/SAF sobre HTTP, RTP/RTSP y
JSR-135, DVB-H/DBM.
76
Tecnologías relacionadas
2.4.2 SVG Salamander
SVG Salamander es un motor SVG para Java que está diseñado para ser
pequeño y rápido. Es particularmente interesante para integrar fácilmente SVG en los
juegos java.
Las características que presenta son las siguientes:
-
Acceso directo al árbol gráfico de la escena. Se pueden utilizar comandos java
para manipularlo directamente.
-
La clase SVGIcon simplifica el proceso de carga y trazado de las imágenes en la
escena.
-
La tarea ant permite una fácil conversión desde SVG a imágenes desde dentro
de los scripts Ant.
-
Sólo es necesario incluir un fichero jar.
-
Se puede acceder fácilmente a un índice de todos los nombres de las figuras en
el gráfico SVG.
-
El motor no posee el contexto gráfico, por eso se le puede pasar cualquier
contexto gráfico que se quiera.
-
Los links internos y externos se implementan como URIs, que permiten al motor
importar los documentos con enlaces automáticamente (incluso aunque estén
almacenados en un servidor remoto).
-
SVG se puede leer desde un InputStream, lo que permite crear documentos
dinámicamente.
Al ser código 100% java, se puede utilizar en cualquier programa haciendo uso
del JAR correspondiente.
2.4.3 Ikivo
Este motor SVG soporta SVG Tiny 1.2 y JSR-226.
77
Tecnologías relacionadas
Sus principales características son un renderizado SVG móvil eficiente y una
baja utilización de la CPU. Al mismo tiempo, el uso que hace de la memoria es bajo. Su
pequeño tamaño del código y su configuración permiten un uso de la ROM bajo.
El motor SVG de Ikivo soporta varios sistemas operativos de tiempo real y
sistemas operativos abiertos. Además, también soporta todos los estándares de 3GPP,
W3C y OMA.
Algunos modelos de teléfonos móviles que incluyen este motor son:
-
Panasonic: MX6, SA6, SA7, VS3, VS7, X700, X800
-
Motorota: C975, C980, E1000, i870, V975, V980, V3X, V1050
-
Lenovo: P930
-
Nokia: E60, E61, E70, 3230, 3250, 3600, 3620, 3650, 3660, 6260, 6600, 6620,
6630, 6670, 6680, 6681, 6682, 7610, 7650, N70, N71, N80, N90, N91, N92, NGage, N-Gage QD
-
Sagem: myX-8
-
Samsung: SGH-D720, SGH-D730
-
Siemens: C65, C70, C75, CF75, CFX65, CL75, CX65, CX70, CX70 Emoty,
CX75, M65, M65 Rescue Edition, M75, S65, S75, SF65, SK65, SK65
Burlwood, SL65, SL65 ESCADA, SL65 ESCADA Rockin' Roll, SL75, SP65,
SX1, SX1 McLaren
-
Sony Ericsson: D750, F500, K300, K500, K508, K600, K608, K700, K750,
P990, S600, S700, S710, V600, V800, W550, W600, W800, Z500, Z520, Z800
-
Toshiba: TS 921, V902T
2.4.4 BitFlash SVG Tiny
El motor de BitFlash SVG Tiny muestra instantáneamente imágenes estáticas y
animaciones complejas. La velocidad de su motor permite que el contenido sea
renderizado en tiempo real, eliminando la necesidad de almacenar bitmaps de prerenderizado en memoria. BitFlash SVG Tiny cumple con SVG Tiny 1.1, 1.1+ y 1.2.
78
Tecnologías relacionadas
BitFlash proporciona acceso directo al uDOM a través de una API de C,
ECMAscript, o APIs de Java (JSR226), con lo que soporta las aplicaciones interactivas.
Sus principales características son las siguientes:
-
Requisitos de ROM bajos tanto para contenido estático como dinámico, No
necesita imágenes pre-renderizadas
-
Soporte de ECMAscript
-
Soporte de JSR 226
-
Footprint bajo (200 Kb)
-
Eventos XML
-
Soporte de contenido multimedia tanto audio como video
-
Transparencia y gradientes
-
Relleno de fondo / Relleno de fondo con transparencia
Las plataformas para las que se encuentra disponible son: Symbian y
WindowsCE.
Esta aplicación proporciona tres vistas sincronizadas del SVG que se está
generando, esto es, una visual, la estructural o DOM y el código fuente real. La
visualización previa gráfica, utilizando un emulador, muestra cómo se verá el contenido
en cualquier tamaño de pantalla y profundidad de color deseados.
2.4.5 eSVG
eSVG (embedded SVG) está basado en la especificación SVG 1.1, en los
perfiles Tiny y Basic de SVG, en la especificación SVG DOM 2 y en la especificación
ECMAScript.
Está disponible para WindowsCE y Symbian.
Las características del motor eSVG son las siguientes:
-
Ejecución de los script multihilos
79
Tecnologías relacionadas
-
Eventos de teclado y ratón para la activación de los script
2.4.6 Renesis SVG
Renesis es el nuevo motor de renderizado SVG 1.2 de EvolGrafiX. Renesis está
disponible en Windows CE, Linux embebido y Symbian.
Renesis soporta alrededor del 94% del estándar SVG 1.2 y el 100% del estándar
SVG Tiny 1.2.
Las características de este motor son las siguientes:
-
Extensible
-
Está optimizado para que el renderizado sea rápido
-
La calidad del renderizado es muy buena
80
Tecnologías relacionadas
2.5 Tecnologías
de
distribución
de
contenidos
Los contenidos interactivos móviles se pueden entregar al terminal móvil
utilizando diferentes tecnologías. La elección de una tecnología u otra dependerá del
tipo de contenido a entregar (contenido principal o contenido interactivo) y del modo de
entrega (broadcast o unicast). En este documento únicamente nos centraremos en la
entrega de contenido auxiliar.
A continuación se describen las posibles tecnologías a utilizar:
2.5.1 Red broadcast
El contenido que se entrega haciendo uso de la red broadcast se envía a todos los
usuarios. Por ese motivo, no es posible realizar una entrega personalizada del mismo
puesto que todos los usuarios reciben el mismo contenido. Su principal ventaja es que
no es necesario abrir canales de comunicación para cada uno de los usuarios que
requieran de dicho contenido.
En este tipo de entrega se utiliza el protocolo carrusel que permite la
transmisión cíclica de un conjunto (fijo o dinámico) de streams de datos individuales. El
carrusel utiliza el protocolo FLUTE.
2.5.1.1 Carrusel
El carrusel de DVB (ver capítulo ANEXOS apartado Organismos de
estandarización relacionados subapartado DVB) es un subconjunto de la especificación
DSM-CC (Digital Storage Media – Command & Control) para datos y control. Un
carrusel de datos DVB permite a un servidor de datos de televisión interactiva presentar
81
Tecnologías relacionadas
distintos objetos a un receptor de una forma cíclica, es decir, los contenidos se
transmiten varias veces.
DSM-CC soporta dos tipos de carrusel:
-
Carrusel de datos.
-
Carrusel de objetos.
2.5.1.1.1 Carrusel de datos
Es el carrusel más simple. Consiste en un número de módulos, donde cada
módulo contiene un ítem de datos (por ejemplo, un fichero). Este módulo podría estar
dividido en módulos para facilitar su envío, pero no hay una estructura de nivel superior
al nivel del módulo.
Existen, entonces, dos módulos: el módulo A, que es pequeño y puede contener
un único bloque y el módulo B, que es más grande y necesita dos bloques para mantener
todos los datos. Un carrusel de datos simple podría primero transmitir el bloque que
contiene el módulo A, luego el bloque que contiene la primera parte del módulo B,
luego el bloque que contiene la segunda parte del módulo B y entonces comenzar de
nuevo por el bloque que contiene el módulo A.
Para que el receptor pueda saber cuando finaliza el módulo A y comienza el B,
los elementos de un carrusel DSM-CC están contenidos en un conjunto de mensajes
DSM-CC. Hay dos categorías de este tipo de mensajes: mensajes de datos de descarga
DSM-CC, que contienen los datos actuales que pertenecen a los módulos en el carrusel
y los mensajes de control de descarga DSM-CC, que le indican al receptor cómo están
organizados los mensajes de datos en módulos.
Sólo existe un tipo de mensaje de datos de descarga. Este mensaje corresponde a
un bloque de datos que se envía como una sola unidad. Todos estos mensajes tienen el
mismo tamaño, excepto para el último bloque de cada módulo.
82
Tecnologías relacionadas
Dentro de los contenidos enviados por el carrusel la Guía de Servicios (ESG) es
el contenido más importante, ya que es necesaria para poder identificar y “engancharse”
a los diferentes canales de streaming a los que hace referencia
2.5.1.1.2 Carrusel de objetos
Para situaciones más complejas existe el carrusel de objetos, que se sitúa sobre
el carrusel de datos y proporciona mayor funcionalidad. DVB utiliza el formato del
carrusel de objetos.
Cada carrusel de objetos consiste en un árbol de directorios que se divide en una
serie de módulos, que pueden contener uno o más ficheros o directorios. Cada módulo
puede contener varios ficheros con un tamaño total inferior a 64 Kb. No se pueden
dividir ficheros en varios módulos, luego los ficheros más grandes de 64Kb deben ir en
su propio módulo, que contendrá un único fichero. Los ficheros en un módulo pueden
venir de cualquier parte del árbol de directorios.
Estos módulos se envían uno detrás de otro hasta que todos han sido enviados,
momento en el que el proceso comienza de nuevo y el primer módulo es enviado de
nuevo.
Para acceder a un fichero, el receptor debe esperar hasta recibir el módulo que
contenga dicho fichero. Esto podría no ser eficiente cuando la cantidad de datos a enviar
sea muy grande, por ello, los receptores deberán almacenar en caché algunos datos.
Un carrusel de objetos puede ser estático o dinámico:
-
Carrusel estático: consiste en que el carrusel tiene contenido multimedia
estático. Cuando sea necesario reemplazar el contenido o actualizar algunas de
sus propiedades, es necesario crear uno nuevo y cambiarlo en el carrusel.
83
Tecnologías relacionadas
Carrusel Estático
Carrusel Estático (2)
-
Carrusel dinámico: este carrusel es capaz de modificar su contenido o
propiedades “al vuelo”. Lo utilizan las operadoras que requieran controlar
aplicaciones interactivas en tiempo real.
Carrusel Dinámico
84
Tecnologías relacionadas
Carrusel Dinámico (2)
Existen varias diferencias entre el carrusel de datos y el carrusel de objetos:
-
La forma en la que la información es gestionada y accedida. En el carrusel de
datos un conjunto de ficheros individuales (módulo) se envía en un carrusel con
una tabla simple de contenidos. Esta tabla de contenidos se utiliza para gestionar
el carrusel.
-
El carrusel de objetos utiliza el concepto básico del carrusel de datos para
entregar y gestionar un conjunto de módulos pero además impone una estructura
jerárquica de la información contenida en el carrusel.
-
En el carrusel de datos, los datos se estructuran en base a su espacio de nombres
utilizado para describir los ficheros mientras que el carrusel de objetos utiliza el
concepto de los directorios de objetos.
2.5.1.2 FLUTE
Protocolo utilizado para la entrega UDP multicast y unicast. Está adaptado en
particular para las redes multicast.
Permite la entrega en modo broadcast de audio, video y ficheros de datos (no en
tiempo real) que van a ser almacenados en el receptor para ser reproducidos más tarde.
Los ficheros se reciben como objetos de transporte, con codificación del contenido
opcional (por ejemplo, gzip).
La especificación se basa en el protocolo ALC (Asynchronous Layered Coding),
el protocolo base diseñado para la distribución masiva y escalable multicast. Es la base
de los servicios del 3GPP MBMS e IP Datacasting sobre DVB-H.
85
Tecnologías relacionadas
Pila de protocolos sobre los que se construye FLUTE
FLUTE se construye sobre el protocolo Asynchronous Layered Coding (ALC),
que combina LCT con un bloque de Control de Congestión (CC) y un bloque de
corrección de errores (FEC - Forward Error Correction) para proporcionar entrega
asíncrona confiable con control de congestión (LCT proporciona el soporte a nivel de
transporte para protocolos de entrega confiable de contenidos o de un stream, el uso de
CC y FEC con FLUTE es opcional).
En IP Datacasting sobre DVB-H (DVB-H / IPDC), FLUTE es el protocolo de
transporte recomendado por DVB para el anuncio de ficheros en el canal de
descubrimiento de servicios y es el protocolo de transporte propuesto para entrega de
ficheros en modo push.
En 3GPP Multimedia Broadcast Multicast Service (MBMS), FLUTE es el
protocolo seleccionado para download de ficheros (en servicios del tipo "download" y
"play"), además se le añade un servicio complementario de reparación de ficheros.
Una sesión Flute consiste en uno o más canales ALC/LCT definidos por la
combinación de la dirección IP de un emisor y una dirección asociada con el canal por
el emisor. Un receptor se une a un canal para comenzar a recibir los paquetes de datos
enviados al canal por el emisor, y el receptor deja el canal para parar de recibir paquetes
de datos del canal.
En la siguiente figura se muestra cómo se divide un fichero en paquetes Flute.
Basándose en la longitud del objeto a transportar, la longitud del símbolo de
codificación y la longitud máxima del bloque origen, se calcula la estructura del bloque
origen. Cada bloque origen se fragmenta en símbolos origen de acuerdo con la longitud
del símbolo de codificación. Los símbolos origen y los símbolos paritarios comprimen
86
Tecnologías relacionadas
juntos los símbolos de codificación para el protocolo Flute. Después un paquete Flute se
construye con una cabecera Flute y un símbolo de codificación. Finalmente, el paquete
Flute está preparado para la entrega UDP/IP.
Paquetes FLUTE
El emisor comunica al receptor la longitud del objeto de transporte, la longitud
del símbolo de codificación y la longitud máxima del bloque origen en la cabecera Flute
o utiliza un objeto de transporte especial denominado File Delivery Table (FDT). Esta
instancia FDT puede describir todos o parte de los ficheros de una sesión Flute. El
receptor es capaz de calcular la estructura del bloque origen.
Existen varias implementaciones de Flute:
-
Propietarias: Nokia, Digital Fountain.
-
Open source: TUT (Tampere University of Technology), INRIA (Institut
National de Recherche en Informatique et en Automatique), Universidad de
Bremen.
2.5.2 Red móvil 3G/2.5G
En el caso de entrega de contenido mediante la red móvil nos encontramos ante
una comunicación unicast, es decir, el envío sólo se realizará al usuario con el que se
87
Tecnologías relacionadas
tiene abierta la comunicación. En este caso sí es posible realizar una entrega
personalizada del contenido porque cada usuario puede recibir un contenido distinto.
El mejor mecanismo de entrega de contenidos interactivos consiste en entregar
el primer documento mediante broadcast, de tal forma que todos los usuarios reciban el
mismo contenido. A partir de ese momento, cada usuario interactuará de una forma u
otra con el contenido y su interactividad se enviará a través del canal de retorno que se
implementa sobre la red móvil. A partir de ese momento la comunicación será unicast
para poder entregar a cada usuario un contenido distinto dependiendo de cómo hayn
interactuado con el contenido interactivo. Como ejemplo podemos citar un contenido
interactivo de tipo quiz en un programa del tipo ¿Quieres ser millonario?. En ese caso,
la votación de la pregunta se debe enviar a todos los usuarios por igual pero,
dependiendo de la respuesta que seleccione cada usuario, éste obtendrá un resultado u
otro que no será común para todos los usuarios.
Actualmente existen dos tipos de redes móviles implantadas: 3G y 2.5G.
2.5.2.1 2.5G
GPRS es el estándar europeo de 2.5G, la mejora de GSM. GPRS es una
arquitectura de conmutación de paquetes sobre la arquitectura de conmutación de
circuitos de GSM.
La velocidad de transferencia en GPRS es de hasta 144 kbps. La tarificación por
parte del operador de telefonía móvil sólo se produce por la información transitada, no
por el tiempo de conexión.
La red central GPRS está basada en IP estándar, lo que la convierte en el ideal
para proveer acceso inalámbrico a otras redes basadas en IP, tales como LANs
corporativas, ISPs y LANs de servicio de operadores. Permite la conexión permanente a
Internet, sin necesidad de efectuar una llamada a un proveedor.
88
Tecnologías relacionadas
2.5.2.2 3G
3G es una abreviatura para la tercera generación de telefonía móvil. Fue creado
por ITU (Internacional Telecommunication Union) conocido como IMT-2000.
El intento de IMT-2000 es conseguir a través de 3G un roaming global. No
obstante, existen cinco grupos estándar agrupados bajo IMT 2000: W-CDMA,
CDMA2000, TD-CDMA/TD-SCDMA, DECT y UWC-136
Los servicios asociados con la tercera generación proporcionan la posibilidad
para transferir tanto voz y datos (una llamada telefónica) y datos no-voz (como la
descarga de programas, intercambio de correo-e, y mensajería instantánea).
3G tiene soporte de conmutación de paquetes IP y soporte IP para videojuegos,
comercio electrónico, video y audio.
La principal ventaja de UMTS sobre la segunda generación móvil (2G), es la
capacidad de soportar altas velocidades de transmisión de datos de hasta 144 kbit/s
sobre vehículos a gran velocidad, 384 kbit/s en espacios abiertos de extrarradios y 2
Mbits/s con baja movilidad (interior de edificios). Esta capacidad sumada al soporte
inherente del protocolo IP, se combinan poderosamente para prestar servicios
multimedia interactivos y nuevas aplicaciones de banda ancha, tales como servicios de
video telefonía y video conferencia.
UMTS ofrece la transmisión de datos en paquetes y por circuitos de
conmutación de alta velocidad debido a la conectividad virtual a la red en todo
momento y a las formas de facturación alternativas (por ejemplo, pago por byte, por
sesión, tarifa plana, ancho de banda asimétrico de enlace ascendente / descendente)
según lo requieran los variados servicios de transmisión de datos que están haciendo su
aparición.
89
Tecnologías relacionadas
2.6 Tecnologías de personalización de
contenidos
Para poder entregar al usuario únicamente contenidos interactivos que sean de su
agrado es necesario realizar un proceso que consta de los siguientes pasos:
-
Identificar los contenidos que el usuario recibe en su dispositivo móvil. Esta
identificación se puede realizar siempre y cuando los contenidos estén
descritos a través de metadatos.
-
Caracterizar los gustos e intereses del usuario realizando un perfil del
mismo. Para ello, se pueden utilizar ontologías que permiten formalizar
perfiles y caracterizar los gustos e intereses de los usuarios.
-
Realizar un proceso de razonamiento para poder seleccionar de entre todos
los contenidos recibidos únicamente aquellos que se consideren adecuados
para el usuario. Este proceso de razonamiento debe poder establecer vínculos
entre los contenidos y los perfiles de usuario. Existen diferentes técnicas
incluidas dentro del ámbito de la Inteligencia Artificial que pueden llevar a
cabo esta tarea: técnicas bayesianas, lógica difusa, redes neuronales, etc.
El proceso para determinar si un contenido es o no del agrado de un usuario se
puede realizar en el terminal móvil o se puede realizar en el proveedor de servicios. Si
se realiza en el terminal móvil, éste recibirá todos los contenidos (televisivos e
interactivos) y cuando realice el proceso de razonamiento con el perfil del usuario que
tiene almacenado, podrá determinar qué contenidos son del agrado del usuario y cuales
no. Entonces podrá optar por mostrar al usuario sólo aquellos contenidos que sean de su
agrado o tan sólo hacerle una recomendación sobre aquellos que se consideren
interesantes. Si el proceso de razonamiento se realiza en el proveedor de servicios, éste
debe tener almacenado previamente el perfil del usuario. Una vez determinados cuáles
son los contenidos de su agrado, una posible opción es enviarle por unicast una lista de
identificadores (relativos a las ESG) de dichos contenidos.
A continuación se analizan en profundidad los dos primeros puntos del proceso
de personalización:
90
Tecnologías relacionadas
2.6.1 Etiquetado de contenidos
El etiquetado de contenidos permite caracterizar los recursos con un conjunto de
propiedades (metadatos) que permiten ser más precisos a la hora de su catalogación.
La iniciativa internacional más destacada en este campo es la norma MPEG-7
(Multimedia Content Description Interface), creada por el grupo MPEG (Moving
Picture Experts Group). MPEG-7 surge para la descripción de información multimedia
(fragmentos elementales, trabajos completos y bibliotecas) independientemente de su
formato y medio de almacenamiento. De esta forma la gestión de contenidos
multimedia es más eficiente, permitiendo una rápida y eficaz identificación de la
información relevante en cada caso. MPEG-7 permite la definición de descriptores. Los
descriptores dedicados a las características audiovisuales de bajo nivel (color, textura,
movimiento, etc) pueden ser extraídos automáticamente, mientras que los descriptores
dedicados a las características de alto nivel de los objetos semánticos, eventos y
conceptos abstractos requieren de la intervención humana. En cualquier caso, estos
descriptores pueden almacenarse en formato XML o binario.
MPEG-7 se basa en XML y RDF.
Una característica interesante de MPEG-7 es la utilización de segmentos para
definir el contenido multimedia. Así, un contenido multimedia puede organizarse en
diferentes segmentos de contenido en el espacio, tiempo y/o fuente de información. Los
tipos de segmentos más comunes son las regiones espaciales en 2 dimensiones
(fotogramas), intervalos temporales de vídeo y las secuencias espacio-temporales de
vídeo. Estos segmentos se
han enriquecido en MPEG-7 para definir mosaicos
(diferentes fotogramas de una misma imagen que permiten la composición de una nueva
imagen), regiones 3D, segmentos multimedia (compaginando diferentes tipos de
contenidos, páginas web, etc), segmentos propios de trabajos de edición, etc. En
cualquier caso, los segmentos definidos podrían estar conectados temporalmente, si son
continuos a lo largo del tiempo, o conectados espacialmente, si constituyen una región
espacial continua.
91
Tecnologías relacionadas
En la siguiente imagen se muestran los objetivos que persigue MPEG-7. El
primer paso consiste en un análisis del documento multimedia para obtener sus
características y las relaciones entre los elementos. Este análisis se podría hacer a mano
o mediante una herramienta informática. Para ello MPEG-7 define una serie de
descriptores estándares, que pueden ser ampliados. Todo ello será “descrito” usando las
herramientas que MPEG-7 dispone para ello, de tal modo que cualquier aplicación
pueda “entender” y usar la información obtenida. De este modo se podrán desarrollar
potentes buscadores o clasificadores de documentos multimedia, por ejemplo, tal y
como se muestra en la siguiente imagen:
Objetivos del MPEG-7
Para más información sobre MPEG-7 consultar el capítulo ANEXOS apartado
Organismos de estandarización relacionados subcapítulo MPEG.
Por otro lado, el forum TV-Anytime, formado por importantes empresas del
sector, ha adoptado también esta idea y ha elaborado la especificación TV-Anytime,
normalizada por ETSI, que ofrece una forma de etiquetar recursos audiovisuales. La
primera fase de la norma, publicada en el año 2003, uniformiza la descripción de
contenidos audiovisuales genéricos, instancias específicas de los mismos, perfiles de
usuario, información de segmentación de contenidos y políticas relacionadas con la
gestión de derechos y privacidad. Estas descripciones se realizan utilizando diferentes
92
Tecnologías relacionadas
tipos de metadatos y son totalmente independientes de la localización de los contenidos
(dada por el canal y la hora de difusión) y del protocolo de difusión utilizado.
La especificación TV-Anytime define cuatro tipos de metadatos para la
descripción de contenidos audiovisuales:
•
Los metadatos de descripción de contenidos permiten especificar características
como el género, idioma, título, resumen, palabras clave, créditos, fecha, etc. Este
tipo de datos permite que los usuarios realicen las búsquedas de material
audiovisual.
•
Los metadatos de descripción de instancias se utilizan para indicar las
características propias de un contenido concreto indicando su duración, si es en
directo o en diferido, su disponibilidad, etc.
•
Los metadatos sobre el consumidor se utilizan para caracterizar a los usuarios
según sus preferencias y su historial de visionado.
•
Los metadatos de segmentación permiten aportar información sobre cada uno de
los segmentos que constituyen un flujo audiovisual. En el caso de la norma TVAnytime, estos segmentos son exclusivamente fragmentos temporales de los
contenidos audiovisuales.
En la actualidad ya se ha publicado la segunda fase de esta norma.
A continuación se muestra un ejemplo de etiquetado de una película (Ocean’s
twelve) mediante TV-Anytime:
Etiquetado mediante TV-Anytime
<ProgramInformationTable>
<ProgramInformation programId="crid: 5551001">
<BasicDescription>
<Title> <![CDATA[Ocean's twelve]</Title>
<Synopsis length="short"> <![CDATA[Comedy about high-skilled thieves]
</Synopsis>
<Genre href='urn:tva:metadata:cs:OriginationCS:2005:3.5.7'>
<Name><![CDATA[Comedy]]></Name>
</Genre>
<CreditsList>
<CreditsItem role='urn:mpeg:mpeg7:cs:RoleCS:2001:ACTOR'>
93
Tecnologías relacionadas
<PersonName>
<mpeg7:GivenName><![CDATA[George]]></mpeg7:GivenName>
<mpeg7:FamilyName><![CDATA[Clooney]]></mpeg7:FamilyName>
</PersonName>
<Character>
<mpeg7:GivenName><![CDATA[Billy]]></mpeg7:GivenName>
<mpeg7:FamilyName><![CDATA[Ocean]]></mpeg7:FamilyName>
</Character>
</CreditsItem>
</CreditsList>
</BasicDescription>
</ProgramInformation>
</ProgramInformationTable>
2.6.2 Ontologías
Una ontología (en informática) intenta formular un exhaustivo y riguroso
esquema conceptual dentro de un dominio dado, con la finalidad de facilitar la
comunicación y la compartición de la información entre diferentes sistemas. Según el
Grupo de Trabajo en Ontologías del consorcio W3C, una ontología define los términos
que se usan para describir y representar un cierto dominio. Actualmente las ontologías
se utilizan en el campo de la inteligencia artificial y de la representación del
conocimiento.
Las ontologías tienen varios usos: razonamiento inductivo, clasificación, amplia
variedad de resolución de problemas, etc.
Las ontologías se relacionan con vocabularios fijos (ontología funcional) con
cuyos términos debe ser descrito todo lo demás.
Las ontologías resultan muy útiles para facilitar el razonamiento automático, es
decir, sin intervención humana. Partiendo de unas reglas de inferencia, un motor de
razonamiento puede usar los datos de las ontologías para inferir conclusiones de ellos.
Toda ontología modela, mediante conceptos y relaciones, lo que conocemos
sobre un dominio o un área de conocimiento. A menudo las ontologías se representan
mediante clases, propiedades y atributos de las clases, relaciones entre clases y
94
Tecnologías relacionadas
restricciones sobre los atributos y propiedades de las clases (por ejemplo, una bicicleta
tiene una rueda y no tres).
Al definir un vocabulario formal de los conceptos del dominio y un conjunto de
relaciones entre ellos, permiten que las aplicaciones “comprendan” la información.
Una ontología tiene aspecto de una jerarquía de términos que representan los
conceptos básicos de un determinado dominio.
Ejemplo de ontología
95
Tecnologías relacionadas
Las figuras anteriores representan una ontología de escritores. Dicha ontología
define las clases Escritor, Libro y MovimientoLiterario. Las dos primeras son subclases
de otras dos (Persona y Obra). André Breton, Nadja y Surrealismo son instancias de las
clases de la ontología.
Una ontología destacada es FOAF (Friend of a Friend). Permite modelar
personas por lo que resulta interesante a la hora de entregar contenido personalizado a
los usuarios. En dicha ontología se pueden incluir los datos personales del usuario y,
entre ellos, sus preferencias televisivas. No obstante, FOAF puede ser completada con
otras ontologías (por ejemplo VCARD) para incluir aquellos datos que no contemple
FOAF.
Descripción breve de una persona en FOAF
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:admin="http://webns.net/mvcb/">
<foaf:PersonalProfileDocument rdf:about="">
<foaf:maker rdf:resource="#me"/>
<foaf:primaryTopic rdf:resource="#me"/>
<admin:generatorAgent rdf:resource="http://www.ldodds.com/foaf/foafa-matic"/>
<admin:errorReportsTo rdf:resource="mailto:leigh@ldodds.com"/>
</foaf:PersonalProfileDocument>
96
Tecnologías relacionadas
<foaf:Person rdf:ID="me">
<foaf:name>Elena Gutiérrez</foaf:name>
<foaf:title>Sra</foaf:title>
<foaf:givenname>Elena</foaf:givenname>
<foaf:family_name>Gutiérrez</foaf:family_name>
<foaf:nick>Ele</foaf:nick>
<foaf:mbox_sha1sum>773d2dc0873ecf59bb7fef5debe57f4cea5070ed</foaf:mbox
_sha1sum>
<foaf:phone rdf:resource="tel:693589636"/>
<foaf:schoolHomepage rdf:resource="ICAI"/>
<foaf:knows>
<foaf:Person>
<foaf:name>Pedro</foaf:name>
<foaf:mbox_sha1sum>3bfe638c56ec1d73492b45a0b9764078228fb8cf</foaf:mbox
_sha1sum></foaf:Person></foaf:knows>
<foaf:knows>
<foaf:Person>
<foaf:name>Laura</foaf:name>
<foaf:mbox_sha1sum>df4d355afa6b54d37851343514572410cb303dd5</foaf:mbox
_sha1sum></foaf:Person></foaf:knows>
<foaf:knows>
<foaf:Person>
<foaf:name>Marta</foaf:name>
<foaf:mbox_sha1sum>790dd620841172aa6e6f892bd9f42ae5a1dc6460</foaf:mbox
_sha1sum></foaf:Person></foaf:knows></foaf:Person>
</rdf:RDF>
En el ejemplo anterior se está describiendo a la persona Elena Gutiérrez, a la que
hay que dirigirse mediante Sra, su nick es Ele, su teléfono de contacto 693589636, ha
estudiado en ICAI y conoce a Pedro, Laura y Marta.
2.6.2.1 Lenguajes de representación de ontologías
Hay muchos lenguajes que se usan para representar ontologías pero los más
destacados son: RDF, RDF Schema, DAM+OIL y OWL.
RDF permite especificar semántica para los datos basados en XML. Se puede
decir que RDF es un modelo de metadatos. Además, existe una representación de RDF
en XML, por lo que se pueden reutilizar todas las herramientas existentes para XML.
RDF no se asocia a ningún dominio en particular, se puede emplear en cualquier campo.
Cada persona u organización puede definir su propia terminología mediante lo que se
conoce como RDFS (RDF Schema). Al disponer de un esquema RDF se puede
comprobar si las propiedades aplicadas a los recursos son correctas y si los valores
vinculados a las propiedades tienen sentido. Los esquemas RDF modelan conocimiento
97
Tecnologías relacionadas
y especifican que interpretación hay que dar a las sentencias de un modelo de datos
RDF. El principal problema que presenta RDFS es que es tan general que se puede
emplear en muchos dominios y sirve como puente entre los vocabularios de cada uno.
OWL es un lenguaje desarrollado por el W3C. Es una extensión de RDF y
emplea el modelo de tripletas (sujeto, propiedad, objeto) de RDF pero OWL tiene
mucha más capacidad expresiva que RDFS. OWL tiene una sintaxis abstracta
(independiente de cualquier representación computacional), una basada en XML y otra
basada en RDF.
A continuación se muestra un ejemplo de ontología:
Ontología en OWL
98
Tecnologías relacionadas
99
Arquitectura propuesta
3 ARQUITECTURA PROPUESTA:
PUBLICIDAD PARA TELEVISIÓN MÓVIL
3.1 ARQUITECTURA PROPUESTA INICIAL
3.2 ARQUITECTURA PROPUESTA FINAL
3.3 IMPLEMENTACIÓN REALIZADA
100
Arquitectura propuesta
3. Arquitectura propuesta: Publicidad
para la televisión móvil
Tras el análisis realizado de tecnologías relacionadas con la publicidad para
televisión en el móvil, se propone una arquitectura que permite disfrutar de contenidos
interactivos publicitarios o de otros tipos (por ejemplo votaciones) en la televisión para
dispositivos móviles.
3.1 Arquitectura propuesta inicial
El diagrama de dicha arquitectura se muestra a continuación:
101
Arquitectura propuesta
Arquitectura propuesta inicial
Según la arquitectura expuesta, el proveedor de contenidos debe crear tanto el
contenido televisivo como el contenido interactivo y ambos deben estar etiquetados con
información que los describa. En esta arquitectura se propone crear los contenidos
interactivos de tal forma que sean rich media tal y como se ha descrito en el análisis de
tecnologías. Además se propone su creación mediante la tecnología SVG ya que está
muy afianzada en el mercado, tiene varios años de experiencia y está soportada por la
mayoría de los terminales móviles de hoy en día. Por otro lado, se propone realizar el
etiquetado de los contenidos mediante la norma TV-Anytime puesto que es la
tecnología que permite realizar la mejor descripción en cuanto a contenidos televisivos.
Una vez se han creado estos contenidos, se envían al proveedor de servicios que
debe realizar una vinculación entre los contenidos televisivos y los contenidos auxiliares
102
Arquitectura propuesta
(interactivos) que estén relacionados. Esta vinculación se hará a través de la ESG de la
siguiente manera: existirá un carrusel en el que se envíe el contenido interactivo del
programa actual y del programa siguiente. En la ESG se incluirá el tag RelatedMaterial
dentro de un fragmento Content indicando que dicho contenido tiene asociado un
contenido interactivo. En la URL de dicho RelatedMaterial se debe especificar una
dirección que apunte a una aplicación web con un parámetro indicando el identificador
del contenido principal con el que está relacionado. La aplicación web devolverá
entonces el nombre del fichero que contiene el contenido interactivo asociado a ese
contenido principal y para ese usuario. Dicho fichero se descargará previamente desde
el carrusel pero puede ocurrir que en ese momento aún no se haya descargado dicho
fichero al terminal móvil, en cuyo caso se presentan dos opciones:
-
Esperar a que el contenido interactivo se descargue del carrusel (esto puede
tener el inconveniente de que termine el contenido principal y no se llegue a
visualizar el contenido interactivo).
-
Pedir dicho fichero al servidor a través de la red móvil (canal de datos 3G).
Según esta arquitectura, en el proveedor de servicios es también donde se realiza
el proceso de razonamiento para determinar si un contenido es del agrado del usuario.
Para ello, se utilizará la ontología FOAF para describir a los usuarios y así incluir
información de los gustos televisivos. Cuando los distintos contenidos lleguen
correctamente etiquetados al proveedor de servicios, éste podrá llevar a cabo un proceso
de razonamiento entre dichos contenidos y los perfiles de los usuarios. A través de este
proceso se podrá determinar si un contenido es del gusto de un usuario o no. En caso de
que lo sea, se puede elaborar una lista con aquellos identificadores que correspondan a
los contenidos del agrado del usuario.
Una vez que los contenidos se han sincronizado, estos se envían mediante
broadcast (el contenido televisivo se envía mediante la tecnología DVB-H). Además,
también se debe enviar la ESG para que los usuarios tengan acceso a los contenidos. Por
otro lado, se debe enviar por unicast (red móvil) la lista de los identificadores de
aquellos contenidos que son del interés del usuario.
103
Arquitectura propuesta
El dispositivo móvil del usuario debe disponer de receptor DVB-H para poder
recibir la señal televisiva, de un cliente ESG para poder visualizar dicho contenido y de
un motor rich media que le permita realizar el renderizado del contenido rich media
interactivo. Como el formato rich media utilizado será SVG el cliente debe incluir un
motor SVG. El terminal móvil podrá realizar entonces un filtrado de los contenidos que
puede ser de dos maneras:
-
Mostrar únicamente al usuario los contenidos que sean de su interés. Esto es
posible puesto que el terminal habrá recibido una lista con los identificadores
de aquellos contenidos que son del agrado del usuario, luego si consulta la
ESG y compara los identificadores podrá determinar qué contenidos son de
su interés o cuales no.
-
Realizar recomendaciones al usuario indicándole qué contenidos se prevé
que serán de su agrado. Este filtrado es menos restrictivo puesto que el
usuario tiene acceso a todos los contenidos y únicamente recibe
recomendaciones sobre los que son de su interés.
Cuando este terminal recibe los contenidos interactivos, el usuario puede
interactuar con ellos (por ejemplo, si el contenido es una votación la interacción en este
caso ocurriría cuando el usuario realice su votación), por lo que dicha interactividad ha
de recogerse a través del canal de retorno que se implementa a través de la red móvil.
De esta forma las interacciones del usuario (en el ejemplo anterior las votaciones) serán
enviadas al proveedor de servicios y éste se deberá encargar de realizar las gestiones
correspondientes. En muchos casos, el proveedor de servicios deberá responder a esta
interacción enviando un nuevo documento SVG mediante unicast, lo cual se hará
haciendo uso de la red móvil (en el ejemplo de la votación, el proveedor de servicios
deberá responder con un mensaje tipo “Su votación se ha registrado con éxito”).
En el caso de los contenidos interactivos, el primer documento se envía mediante
la red broadcast a todos los usuarios pero cuando éstos empiezan a interactuar con los
contenidos, si el proveedor de servicios debe enviarles otros contenidos interactivos en
respuesta a esas peticiones, éstos se enviarán mediante unicast.
104
Arquitectura propuesta
3.2 Arquitectura propuesta final
Esta arquitectura inicial se modificó ligeramente al no ser útil el hecho de que el
proveedor de contenidos sea el responsable de generar el contenido interactivo. La
arquitectura final propuesta es la siguiente:
Arquitectura propuesta final
En esta nueva arquitectura el proveedor de contenidos únicamente crea plantillas
XML en las que introduce los datos de los contenidos interactivos pero sigue generando
los metadatos de los mismos. La única diferencia es que no genera el fichero interactivo
propiamente. Es el proveedor de servicios el que genera los contenidos interactivos a
partir de la plantilla XML que le envía el proveedor de contenidos. Este cambio en
105
Arquitectura propuesta
cuanto a qué proveedor debe generar el contenido interactivo definitivo se debe a varios
motivos:
-
El proveedor de contenidos no tiene por qué conocer la tecnología rich
media que se utiliza para generar los contenidos interactivos.
-
Cuando se generan determinados contenidos interactivos el proveedor de
servicios tiene que tener constancia de ellos. Por ejemplo, en un contenido de
votación será necesario registrar dicha votación para luego poder registrar
correctamente las votaciones de los usuarios.
A continuación se detalla el proceso que involucra a los contenidos interactivos
puesto que es el objeto de estudio en este proyecto.
3.2.1 Proceso detallado de los contenidos interactivos
Si analizamos en detalle el proceso que siguen los contenidos interactivos
podemos observar que se compone de los siguientes pasos:
1.
Creación de las plantillas XML en las que se incluye la información
necesaria para generar los contenidos interactivos.
2.
Creación de los contenidos interactivos definitivos en formato SVG a
partir de las plantillas XML ya creadas.
3.
Vinculación de los contenidos interactivos a sus correspondientes
contenidos televisivos principales. Como se ha comentado, esta
funcionalidad
se
puede
implementar
mediante
el
fragmento
RelatedMaterial que se incluye en la ESG.
4.
Envío de los contenidos interactivos (también televisivos) a través del
carrusel que, como se ha visto en capítulos anteriores, envía los datos
cíclicamente.
5.
Entrega de los contenidos interactivos al terminal móvil y
visualización de los mismos a través de un motor rich media que
permita su renderizado.
106
Arquitectura propuesta
6.
Al ser contenidos interactivos, los usuarios pueden interactuar con los
mismos. Las opciones del usuario son enviadas a un servidor que se
encarga de gestionar todas las peticiones.
7.
El servidor de interactividad recibe las peticiones del usuario. Por
ejemplo, si el contenido interactivo hubiese sido una votación el
servidor recibiría la votación seleccionada por el usuario.
8.
El servidor de interactividad realiza los procesos que requiera la
petición del usuario y, si fuera necesario, enviará una respuesta al
mismo. Retomando el ejemplo anterior de la votación, el servidor
podría enviar un nuevo contenido SVG con el que se le indique al
usuario que su respuesta ha sido procesada con éxito.
A continuación se muestra un esquema en el que se representan los pasos
anteriores:
Proceso de los contenidos interactivos
107
Arquitectura propuesta
Por otro lado, también hay que detallar el proceso de entrega de un contenido
interactivo relacionado con un contenido televisivo:
1. Se examina el fragmento RelatedMaterial de la ESG para determinar la URL
del servidor que proporcionará información sobre el contenido interactivo.
2. Se sigue dicha URL para acceder al servidor.
3. El servidor proporciona los datos del contenido interactivo asociado a ese
contenido televisivo
4. Se busca el contenido interactivo indicado en el terminal móvil.
Típicamente, dicho contenido ya se habrá descargado desde el carrusel
aunque no se siempre ha de ser así.
5. a. En el caso de que el contenido interactivo se encuentre en el terminal
móvil se muestra al usuario.
b. 1. Si el contenido interactivo aún no ha sido descargado, será necesario
solicitarlo a través de la red móvil para que sea descargado al terminal o, en
su defecto, esperar a que sea descargado del carrusel.
b. 2.Una vez el contenido interactivo ya esté descargado se podrá mostrar al
usuario.
108
Arquitectura propuesta
Entrega de contenido interactivo
3.3 Implementación realizada
Debido a la amplitud de la arquitectura propuesta, dentro de este proyecto se han
realizado dos aplicaciones que forman parte de dicha arquitectura pero sólo cubren una
pequeña parte de la misma. La primera aplicación desarrollada permite crear las
plantillas XML en el proveedor de contenidos con los datos que debe incluir el
contenido interactivo que se desee generar (Aplicación 1 en la imagen siguiente). La
segunda aplicación permite generar el contenido interactivo definitivo en el proveedor
de servicio a partir de las plantillas XML que le proporcione el proveedor de contenidos
(Aplicación 2 en la imagen siguiente). Ambas aplicaciones son analizadas con detalle en
el siguiente capítulo.
109
Arquitectura propuesta
A continuación se muestra de nuevo la imagen Proceso de los contenidos
interactivos en la que se indica con claridad qué parte cubre cada aplicación
desarrollada.
Proceso de los contenidos interactivos
La utilización conjunta de las dos aplicaciones permite la creación de contenidos
interactivos en formato rich media (en SVG en concreto). Esta creación se produce en el
proveedor de servicios pero es el proveedor de contenidos el que especifica los campos
que debe incluir el contenido interactivo. Esta especificación se plasma en el fichero
XML que una de las aplicaciones permite generar.
110
Aplicación
4 APLICACIÓN
4.1 DESCRIPCIÓN
4.2 GENERACIÓN DE PLANTILLAS SVG
4.3 GENERACIÓN DE PLANTILLAS XML
4.4 GENERACIÓN
INTERACTIVOS
4.5 VISOR SVG TINY
4.6 IMPLEMENTACIÓN
111
DE
CONTENIDOS
Aplicación
4. Aplicación
4.1 Descripción
La aplicación que se ha realizado en este proyecto permite crear contenidos
interactivos de tipo publicidad y votaciones para ser integrado en la televisión en el
móvil. Realmente se han realizado dos aplicaciones. Ambas son muy similares pero
tienen fines distintos:
-
Aplicación diseñada para el proveedor de contenidos: Esta aplicación
permite generar plantillas XML para, posteriormente, poder generar
contenido interactivo en formato SVG Tiny 1.1 con los datos de dichas
plantillas. El contenido que permite generar es de tipo publicidad y
votaciones/quiz (Nota: un contenido de votación sería por ejemplo "¿Quién
quieres que salga de la casa de Gran Hermano?", mientras que un contenido
de tipo quiz sería por ejemplo "¿Quién ganó el premio Nobel de medicina en
1985?". En el primer caso la pregunta no tiene ninguna respuesta mientras
que en el segundo caso la respuesta tiene una única posible respuesta).
El contenido interactivo debe tener un formato SVGT. El proveedor de
contenidos no tiene por qué conocer este formato, por lo que esta aplicación
le facilita el trabajo a la hora de la creación de estos contenidos. La
aplicación le permite personalizar los elementos del contenido (texto,
imagen, colores de fondo, tamaños, etc). Con todos estos datos la aplicación
genera un fichero XML que debe ser entregado al proveedor de servicios.
El proveedor de contenidos dispone de un visor SVGT implementado dentro
de la aplicación en el que puede visualizar el resultado del contenido con los
datos que va introduciendo. De esa forma, puede saber a priori cómo será el
contenido que se genere en el proveedor de servicios.
-
Aplicación diseñada para el proveedor de servicios: Esta aplicación permite
generar contenidos interactivos en formato SVG Tiny 1.1 a partir de los
112
Aplicación
ficheros plantilla XML que le envíe el proveedor de contenidos. Para ello,
extrae los datos contenidos en los ficheros XML y, con ellos, genera los
contenidos interactivos SVG.
Ambas aplicaciones tienen un interfaz prácticamente idéntico. La única
diferencia entre ellas es que, en el primer caso, con los datos introducidos por el usuario
se generan plantillas XML, mientras que en el segundo caso, con los datos extraídos de
los ficheros XML recibidos, se generan los contenidos SVGT definitivos.
En el siguiente esquema se muestra la conexión entre ambas aplicaciones:
Conexión entre las dos aplicaciones desarrolladas
Como se ha comentado anteriormente, la aplicación incluye un visor SVG Tiny
para que tanto el proveedor de contenidos como el proveedor de servicios puedan
visualizar los resultados que obtendrán con los datos introducidos. En el mercado
existen muchos visores SVG y, en concreto, también hay varios visores SVG Tiny. El
113
Aplicación
problema es que entre ellos no existe homogeneidad y, por tanto, el mismo fichero SVG
puede reproducirse de diferentes maneras en unos visores y otros. La aplicación
implementa un visor SVG Tiny para evitar este tipo de problemas, de tal manera que se
pueda homogeneizar la visualización que tengan del contenido tanto el proveedor de
contenidos como el proveedor de servicios.
A la hora de generar los contenidos interactivos, la aplicación permite elegir
entre diferentes efectos de animación tanto para los contenidos de publicidad como para
los contenidos de votación/quiz. Estas animaciones consiguen que el contenido sea más
llamativo y atractivo para el usuario final.
Para poder generar los contenidos interactivos, la aplicación dispone de varias
plantillas en formato SVGT (para más información sobre las mismas consultar el
apartado Generación de plantillas SVG). Con los datos introducidos, estas plantillas se
modifican y se personalizan, creando los contenidos SVGT definitivos.
4.2 Generación de plantillas SVG
Para generar las plantillas SVG Tiny se ha utilizado una aplicación
especialmente diseñada para tal fin. Dicha aplicación es e-Picture Pro 5.0 de la
compañía Beatware. Gracias a esta aplicación se pudieron desarrollar fácilmente las
plantillas para posteriormente modificar los diferentes elementos de las mismas y así
generar nuevos contenidos SVG personalizados en cada caso. Las plantillas tienen los
principales campos vacíos (campos del texto del anuncio, de la pregunta de la votación,
de la imagen publicitaria, etc). El proveedor de contenidos debe suministrar la
información para rellenar estos campos a través de los ficheros XML que debe crear
mediante la aplicación y, posteriormente, enviar al proveedor de servicios. Cuando ya se
dispone de la información necesaria, la aplicación lee dichos datos, coge la plantilla
adecuada en cada caso y genera el contenido interactivo final en formato SVG
rellenando los campos vacíos de la plantilla con la información suministrada.
114
Aplicación
Proceso de creación del contenido interactivo final
Como ya se ha comentado anteriormente, la aplicación permite crear tanto
contenidos interactivos publicitarios como contenidos de votación/quiz. En el caso de
los contenidos publicitarios se desarrollaron tres tipos de plantillas (las plantillas se
diferencian en la disposición de los elementos en el contenido, así como en los efectos
de animación de los mismos elementos), por lo que se pueden crear tres tipos distintos
de contenidos de ese tipo. En el caso de los contenidos de votaciones, existen también
tres posibles plantillas por lo que se pueden crear tres tipos distintos de contenidos de
votación o quiz.
Las plantillas de publicidad contienen básicamente los siguientes elementos:
-
Imagen publicitaria.
-
Logo publicitario.
-
Texto del anuncio.
-
Link a la página web del anunciante, establecido desde el texto del anuncio.
Para poder distinguir unos elementos de otros, cada plantilla creada por el
programa e-Picture Pro 5.0 se retocó para asignar un id único a cada elemento. Los ids
asignados han sido los siguientes:
Elemento
ID asignado
Imagen publicitaria
“logo”
Logo publicitario
“imagen”
Texto del anuncio
“texto”
Link al anunciante
“link”
115
Aplicación
Gracias a estos ids se pueden diferenciar fácilmente los diferentes elementos.
Las plantillas generadas para los contenidos publicitarios (con los identificadores
incluidos) son las siguientes:
Plantilla 1 de contenido publicitario
<?xml version="1.0" encoding="UTF-8"?>
<svg width="320" height="60" viewBox="-234 -30 320 60" strokemiterlimit="2"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:space="preserve" version="1.1" baseProfile="tiny">
<!-- Definitions -->
<defs>
logo
<image id="logo" width="103" height="60" xlink:href="$$"/>
<image id="imagen" width="95" height="60" xlink:href="$$"/>
imagen
</defs>
<!-- Background -->
<rect id="rect" fill="#fff" x="-234" y="-30" width="320" height="60"/>
<!-- Layer -->
<g id="Layer_1">
<use id="use1" visibility="hidden" x="20" y="-32" xlink:href="#logo"
transform="translate(-74,-81)">
<animate attributeName="visibility"
Referencia
values="hidden;visible;visible"
keyTimes="0;0.13;1"
al logo
dur="4.05s" fill="freeze"/>
<animateTransform attributeName="transform" type="translate"
values="-74,-81;-74,-39;-73,-6;-73,-6"
keyTimes="0;0.13;0.24;1"
dur="4.05s" fill="freeze"/>
</use>
Referencia a
<use id="use2" visibility="hidden" x="-30" y="-32"
xlink:href="#imagen"
la imagen
transform="translate(-336.5) scale(1.75455,1)">
<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.01;1"
dur="4.05s" fill="freeze"/>
<animateTransform attributeName="transform" type="rotate"
values="0 -336.5 0;-45.14 -180 0;-90.28 -180 0;-180.1 -180 0;360.21 -180 0;-360.21 -180 0"
keyTimes="0;0.03;0.07;0.11;0.14;1"
dur="4.05s" fill="freeze"/>
<animateTransform attributeName="transform" type="translate"
additive="sum"
values="-336.5,0;-180,0;-180,0;-180,0;-180,0;-180,0"
keyTimes="0;0.03;0.07;0.11;0.14;1"
dur="4.05s" fill="freeze"/>
<animateTransform attributeName="transform" type="scale"
additive="sum"
values="1.75455,1;1.75455,1;1.75455,1;1.75455,1;1.75455,1;1.75455,1"
keyTimes="0;0.03;0.07;0.11;0.14;1"
116
Aplicación
link
dur="4.05s" fill="freeze"/>
</use>
<a id="link" xlink:href="">
<text id="texto" x="-30" y="21" text-anchor="middle"
visibility="hidden" font-size="14" font-family="Bookman Old Style"
font-weight="bold" letter-spacing="-0.03em" fill="#666"
transform="translate(38,64) scale(1.62701) translate(4.84) skewX(13)">texto<animate attributeName="visibility"
values="hidden;visible;visible;hidden;visible;visible;hidden;visible
;visible"
keyTimes="0;0.19;0.24;0.35;0.46;0.58;0.69;0.8;1"
dur="4.05s" fill="freeze"/><animate attributeName="letter-spacing"
values="-0.03em;-0.03em;-0.06em;-0.06em"
keyTimes="0;0.22;0.24;1"
dur="4.05s" fill="freeze"/>
<animateTransform attributeName="transform" type="translate"
values="38,64;37.95,-10.05;37.95,-10.05"
keyTimes="0;0.24;1"
dur="4.05s" fill="freeze"/><animateTransform
attributeName="transform" type="scale" additive="sum"
values="1.62701,1.62701;1.62701,1.62701;1.62701,1.62701"
keyTimes="0;0.24;1"
dur="4.05s" fill="freeze"/></text></a>
</g> </svg>
link
texto
Plantilla 2 de contenido publicitario
<?xml version="1.0" encoding="UTF-8"?>
<svg width="320" height="60" viewBox="-234 -30 320 60" strokemiterlimit="2"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:space="preserve" version="1.1" baseProfile="tiny">
<!-- Definitions -->
<defs>
<image id="imagen" width="423" height="262" xlink:href="$$"/>
<image id="logo" width="200" height="150" xlink:href="$$"/>
</defs>
imagen
logo
<!-- Background -->
<rect id="rect" fill="#fff" x="-234" y="-30" width="320" height="60"/>
<!-- Layer -->
<g id="Layer_1">
<use id="use2" x="-211" y="-131" xlink:href="#imagen"
transform="rotate(419.25 -314 -27) translate(-302.65,-33.3)
scale(0.333333,0.229008)">
<animateTransform attributeName="transform" type="rotate"
values="419.25 -314 -27;436.41 -214 -26;453.56 -192 -16;470.71
-181 -15.5;488.26 -170 -15;505.81 -156.5 -15;531.53 -143 -15;557.25 132 -14;606.83 -120 4;657.99 -104 5;673.98 -86 5;697.48 -54 4;709.54 34 1;714.5 -15 1;719.36 5.99 1;719.36 5.99 1"
keyTimes="0;0.03;0.06;0.1;0.13;0.16;0.2;0.23;0.26;0.3;0.33;0.36;0.4;
0.43;0.46;1"
dur="1.5s" fill="freeze"/>
117
Referencia a
la imagen
Aplicación
<animateTransform attributeName="transform" type="translate"
additive="sum"
values="-302.65,-33.3;-204.16,-23.89;-182.16,-13.89;-171.16,13.39;-160.16,-12.89;-146.66,-12.89;-133.16,-12.89;-122.16,-11.89;110.16,6.1;-94.16,7.1;-76.16,7.1;-44.16,6.1;-24.16,3.1;5.16,3.1;15.83,3.1;15.83,3.1"
keyTimes="0;0.03;0.06;0.1;0.13;0.16;0.2;0.23;0.26;0.3;0.33;0.36;0.4;
0.43;0.46;1"
dur="1.5s" fill="freeze"/>
<animateTransform attributeName="transform" type="scale"
additive="sum"
values="0.333333,0.229008;0.333333,0.229008;0.333333,0.229008;0.3333
33,0.229008;0.333333,0.229008;0.333333,0.229008;0.333333,0.229008;0.33
3333,0.229008;0.333333,0.229008;0.333333,0.229008;0.333333,0.229008;0.
333333,0.229008;0.333333,0.229008;0.333333,0.229008;0.333333,0.229008;
0.333333,0.229008"
keyTimes="0;0.03;0.06;0.1;0.13;0.16;0.2;0.23;0.26;0.3;0.33;0.36;0.4;
0.43;0.46;1"
dur="1.5s" fill="freeze"/>
</use>
<use id="use1" visibility="hidden" x="-100" y="-75"
xlink:href="#logo"
transform="translate(-140,-61) scale(0.6,0.4)">
<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.36;1"
dur="1.5s" fill="freeze"/>
<animateTransform attributeName="transform" type="translate"
values="-140,-61;-140,-11;-140,-11"
keyTimes="0;0.66;1"
dur="1.5s" fill="freeze"/>
<animateTransform attributeName="transform" type="scale"
additive="sum"
values="0.6,0.4;0.6,0.4;0.6,0.4"
keyTimes="0;0.66;1"
dur="1.5s" fill="freeze"/>
</use>
<a id="link" xlink:href="">
<text id="texto" x="-209" y="49" visibility="hidden" font-size="18"
font-family="Bookman Old Style" font-weight="bold" letterspacing="0.11em" fill="#666"
transform="translate(0,16) translate(-0.85)
skewX(1)">texto<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.36;1"
dur="1.5s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,16;0,-29;0,-29"
keyTimes="0;0.9;1"
dur="1.5s" fill="freeze"/></text></a>
</g> </svg>
Plantilla 3 de contenido publicitario
<?xml version="1.0" encoding="UTF-8"?>
<svg width="320" height="60" viewBox="-234 -30 320 60" strokemiterlimit="2"
118
Referencia
al logo
link
texto
Aplicación
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:space="preserve" version="1.1" baseProfile="tiny">
<!-- Definitions -->
<defs>
<image id="imagen" width="423" height="262" xlink:href="$$"/>
imagen
<image id="logo" width="200" height="150" xlink:href="$$"/>
</defs>
<!-- Background -->
<rect id="rect" fill="#fff" x="-234" y="-30" width="320" height="60"/>
<!-- Layer -->
<g id="Layer_1">
<use id="use2" x="-211" y="-131" xlink:href="#imagen"
transform="rotate(719.36 138.99 1) translate(148.83,3.1)
scale(0.333333,0.229008)">
<animateTransform attributeName="transform" type="rotate"
values="719.36 138.99 1;719.36 3.99 1;719.36 3.99 1"
keyTimes="0;0.38;1"
dur="2.5s" fill="freeze"/>
<animateTransform attributeName="transform" type="translate"
additive="sum"
values="148.83,3.1;13.83,3.1;13.83,3.1"
keyTimes="0;0.38;1"
dur="2.5s" fill="freeze"/>
<animateTransform attributeName="transform" type="scale"
additive="sum"
values="0.333333,0.229008;0.333333,0.229008;0.333333,0.229008"
keyTimes="0;0.38;1"
dur="2.5s" fill="freeze"/>
</use>
<use id="use1" x="-100" y="-75" xlink:href="#logo"
transform="translate(-297,-11) scale(0.6,0.4)">
<animateTransform attributeName="transform" type="translate"
values="-297,-11;-151,-11;-151,-11"
keyTimes="0;0.38;1"
dur="2.5s" fill="freeze"/>
<animateTransform attributeName="transform" type="scale"
additive="sum"
values="0.6,0.4;0.6,0.4;0.6,0.4"
keyTimes="0;0.38;1"
dur="2.5s" fill="freeze"/>
</use>
<a id="link" xlink:href="">
<text id="texto" x="-357" y="20" font-size="18" font-family="Bookman
Old Style" font-weight="bold" letter-spacing="0.11em" fill="#666"
transform="translate(-27) translate(-0.34)
skewX(1)">texto<animateTransform attributeName="transform"
type="translate"
values="-27,0;146,0;146,0"
keyTimes="0;0.38;1"
dur="2.5s" fill="freeze"/></text></a>
</g>
</svg>
119
logo
Referencia a
la imagen
Referencia
al logo
link
texto
Aplicación
Los tres tipos de plantillas se diferencian básicamente en la disposición de los
elementos en la pantalla y en el tipo de animación de cada elemento.
Las plantillas de votaciones/quiz contienen básicamente los siguientes
elementos:
-
Imagen de fondo (elemento opcional).
-
Texto de la pregunta.
-
Texto de la respuesta 1.
-
Texto de la respuesta 2.
-
Texto de la respuesta 3.
-
Texto de la respuesta 4.
Para poder distinguir unos elementos de otros, cada plantilla se retocó para
asignar un id único a cada elemento. Los ids asignados han sido los siguientes:
Elemento
ID asignado
Imagen de fondo
“imagen”
Texto pregunta
“preg”
Texto respuesta 1
“resp1”
Texto respuesta 2
“resp2”
Texto respuesta 3
“resp3”
Texto respuesta 4
“resp4”
Gracias a estos ids se pueden diferenciar e identificar fácilmente los diferentes
elementos.
Las plantillas generadas para las votaciones/quiz (con los identificadores
incluidos) son las siguientes:
Plantilla 1 de votaciones
<?xml version="1.0" encoding="UTF-8"?>
<svg width="320" height="60" viewBox="-160 -30 320 60" strokemiterlimit="2" xmlns="http://www.w3.org/2000/svg"
120
Aplicación
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:space="preserve" version="1.1" baseProfile="tiny">
<!-- Definitions -->
<defs>
<image id="imagen" width="514" height="475" xlink:href="$$"/>
</defs>
<!-- Layer -->
<rect id="rect" fill="#fff" x="-160" y="-30" width="320" height="60"/>
<g id="Layer_1">
<use x="-257" y="-237" xlink:href="#imagen"
transform="translate(-1,-0.06) scale(0.626459,0.126316)"/>
<text id="preg" x="-130" y="-11" font-size="20" fontfamily="Arial">pregunta</text>
<text id="resp1" x="-221" y="7" visibility="hidden" font-size="18"
font-family="Arial">respuesta1<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.01;1"
dur="3.15s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;107,0;107,0"
keyTimes="0;0.22;1"
dur="3.15s" fill="freeze"/></text>
<text id="resp2" x="-228" y="24" visibility="hidden" font-size="18"
font-family="Arial">respuesta2<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.23;1"
dur="3.15s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;114,0;114,0"
keyTimes="0;0.46;1"
dur="3.15s" fill="freeze"/></text>
<text id="resp3" x="150" y="7" visibility="hidden" font-size="18"
font-family="Arial">respuesta3<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.47;1"
dur="3.15s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;-134,0;-134,0"
keyTimes="0;0.69;1"
dur="3.15s" fill="freeze"/></text>
<text id="resp4" x="150" y="24" visibility="hidden" font-size="18"
font-family="Arial">respuesta4<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.71;1"
dur="3.15s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;-133,0;-133,0"
keyTimes="0;0.93;1"
dur="3.15s" fill="freeze"/></text>
</g>
</svg>
Plantilla 2 de votaciones
<?xml version="1.0" encoding="UTF-8"?>
121
imagen
pregunta
Respuesta 1
Respuesta 2
Respuesta 3
Respuesta 4
Aplicación
<svg width="320" height="60" viewBox="-160 -30 320 60" strokemiterlimit="2"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:space="preserve" version="1.1" baseProfile="tiny">
<!-- Definitions -->
<defs>
<image id="imagen" width="514" height="475" xlink:href="$$"/>
</defs>
<!-- Layer -->
<rect id="rect" fill="#fff" x="-160" y="-30" width="320" height="60"/>
<g id="Layer_1">
<use x="-257" y="-237" xlink:href="#imagen"
transform="translate(-1,-0.06) scale(0.626459,0.126316)"/>
<text id="preg" x="-130" y="-47" visibility="hidden" font-size="20"
font-family="Arial">pregunta<animate attributeName="visibility"
values="hidden;visible;visible"
keyTimes="0;0.06;1"
dur="4s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;0,37;0,37"
keyTimes="0;0.11;1"
dur="4s" fill="freeze"/></text>
<text id="resp1" x="-114" y="47" visibility="hidden" font-size="18"
font-family="Arial">respuesta1<animate attributeName="visibility"
values="hidden;visible;hidden;visible;visible"
keyTimes="0;0.06;0.25;0.4;1"
dur="4s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;0,-39;0,-39"
keyTimes="0;0.17;1"
dur="4s" fill="freeze"/></text>
<text id="resp2" x="-114" y="64" visibility="hidden" font-size="18"
font-family="Arial">respuesta2<animate attributeName="visibility"
values="hidden;visible;hidden;visible;visible"
keyTimes="0;0.06;0.46;0.61;1"
dur="4s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;0,-39;0,-39"
keyTimes="0;0.17;1"
dur="4s" fill="freeze"/></text>
<text id="resp3" x="23" y="46" visibility="hidden" font-size="18"
font-family="Arial">respuesta3<animate attributeName="visibility"
values="hidden;visible;hidden;visible;visible"
keyTimes="0;0.06;0.65;0.8;1"
dur="4s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;0,-39;0,-39"
keyTimes="0;0.17;1"
dur="4s" fill="freeze"/></text>
<text id="resp4" x="23" y="64" visibility="hidden" font-size="18"
font-family="Arial">respuesta4<animate attributeName="visibility"
values="hidden;visible;hidden;visible"
keyTimes="0;0.06;0.83;1"
dur="4s" fill="freeze"/><animateTransform
attributeName="transform" type="translate"
values="0,0;0,-39;0,-39"
122
imagen
pregunta
Respuesta 1
Respuesta 2
Respuesta 3
Respuesta 4
Aplicación
keyTimes="0;0.17;1"
dur="4s" fill="freeze"/></text>
</g>
</svg>
Plantilla 3 de votaciones
<?xml version="1.0" encoding="UTF-8"?>
<svg width="320" height="60" viewBox="-160 -30 320 60" strokemiterlimit="2"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:space="preserve" version="1.1" baseProfile="tiny">
<!-- Definitions -->
<defs>
<image id="imagen" width="514" height="475" xlink:href="##"/>
</defs>
imagen
<!-- Layer -->
<rect id="rect" fill="#fff" x="-160" y="-30" width="320" height="60"/>
<g id="Layer_1">
<use x="-257" y="-237" xlink:href="#imagen"
transform="translate(-1,-0.06) scale(0.626459,0.126316)"/>
pregunta
<text id="preg" x="-130" y="-10" font-size="11" fontfamily="Arial">pregunta<animate attributeName="font-size"
values="8;11;20;20"
keyTimes="0;0.22;0.5;1"
dur="3.4s" fill="freeze"/>
<animateTransform attributeName="transform" type="translate"
additive="replace"
values="0;0;0;0"
keyTimes="0;0.22;0.5;1"
dur="3.4s" fill="freeze"/><animateTransform
attributeName="transform" type="scale" additive="sum"
values="1,1;1,1;1,1;1,1"
keyTimes="0;0.22;0.5;1"
dur="3.4s" fill="freeze"/></text>
<g>
<animateTransform attributeName="transform" type="rotate"
values="0 -75 10;92.87 -75 10;181.67 -75 10;269.52 -75
10;361.50 -75 10;361.50 -75 10"
keyTimes="0;0.2;0.27;0.38;0.5;1"
dur="3.4s" fill="freeze"/>
Respuesta 1
<text id="resp1" x="-114" y="8" font-size="18" fontfamily="Arial">respuesta1</text>
<text id="resp2" x="-114" y="25" font-size="18" fontfamily="Arial">respuesta2</text>
Respuesta 2
</g>
<g>
<animateTransform attributeName="transform" type="rotate"
values="0 70.5 9.5;-89.24 70.5 9.5;-179.41 70.5 9.5;-268.4 70.5
9.5;-360.94 70.5 9.5;-360.94 70.5 9.5"
keyTimes="0;0.2;0.27;0.38;0.5;1"
dur="3.4s" fill="freeze"/>
Respuesta 3
123
Aplicación
<text id="resp3" x="23" y="8" font-size="18" fontfamily="Arial">respuesta3</text>
<text id="resp4" x="23" y="25" font-size="18" fontfamily="Arial">respuesta4</text>
</g>
</g>
</svg>
4.3 Generación de plantillas XML
La aplicación del proveedor de contenidos genera un documento XML plantilla
con todos los datos que introduce el proveedor de contenidos. Este documento XML
debe ser enviado al proveedor de servicios y entonces, a partir de los datos que se
incluyen en dicho documento y utilizando la aplicación del proveedor de servicios, se
genera el contenido interactivo correspondiente en formato SVGT.
A continuación se muestran unos ejemplos de documentos XML plantilla:
Plantilla de votación
<?xml version="1.0" encoding="UTF-8"?>
<Informacion>
<tipo mostrarestadisticas="falso">Votacion</tipo>
<titulo>Salida de Gran Hermano</titulo>
<colorFondo fill="#ffffff"/>
<imagenFondo> </imagenFondo>
<plantilla tipo="plantilla2"/>
<pregunta fill="#000000" font-size="15" x="0.0" y="0.0">Quiero
expulsar de la casa a...</pregunta>
<respuesta correcta="falso" fill="#000000" font-size="15" x="0.0"
y="0.0">1.Roberto</respuesta>
<respuesta correcta="falso" fill="#000000" font-size="15" x="0.0"
y="0.0">2.Ruth</respuesta>
<respuesta correcta="falso" fill="#000000" font-size="15" x="0.0"
y="0.0">3.Laura</respuesta>
<respuesta correcta="falso" fill="#000000" font-size="15"
x="0.0" y="0.0">4.Alberto</respuesta>
</Informacion>
Plantilla de quiz
<?xml version="1.0" encoding="UTF-8"?>
<Informacion>
<tipo mostrarcorrecta="falso" subtipo="quiz">Votacion</tipo>
<titulo>Capital de Portugal</titulo>
<colorFondo fill="#ffffff"/>
<imagenFondo></imagenFondo>
124
Respuesta 4
Aplicación
<plantilla tipo="plantilla2"/>
<pregunta fill="#000000" font-size="15" x="0.0" y="0.0">¿Cuál es
la capital de Portugal?</pregunta>
<respuesta correcta="falso" fill="#000000" font-size="15" x="0.0"
y="0.0">1.Oporto</respuesta>
<respuesta correcta="falso" fill="#000000" font-size="15" x="0.0"
y="0.0">2.Madrid</respuesta>
<respuesta correcta="falso" fill="#000000" font-size="15" x="0.0"
y="0.0">3.Lugo</respuesta>
<respuesta correcta="verdadero" fill="#000000" font-size="15"
x="0.0" y="0.0">4.Lisboa</respuesta>
</Informacion>
Plantilla de publicidad
<?xml version="1.0" encoding="UTF-8"?>
<Informacion>
<tipo>Publicidad</tipo>
<titulo>Anuncio Wii</titulo>
<colorFondo fill="#ffffff"/>
<imagen x="0.0" y="0.0">nintendo_wii_mod.jpg</imagen>
<logo x="0.0" y="0.0">logo_wii_mod.jpg</logo>
<plantilla tipo="plantilla1"/>
<texto fill="#000000" font-size="15" x="0.0" y="0.0">Tu
consola</texto>
<link>http://wii.es.com</link>
</Informacion>
En primer lugar se indica el tipo de contenido interactivo: Publicidad o
Votación. Además, en el caso de contenido quiz se indica que el tipo es votación y el
subtipo es Quiz.
En el caso de votación se indica si es necesario mostrar estadísticas, es decir, si
cuando el usuario haga su elección de la votación desde su terminal móvil se desea que
le aparezcan por pantalla las estadísticas actuales de esa votación. Esto se indica a través
del atributo mostrarestadisticas. En este caso además no es necesario que ninguna de
las respuestas sea la correcta puesto que en una votación no hay ninguna respuesta que
sea correcta (ejemplo, una votación del tipo Gran Hermano no tiene ninguna respuesta
correcta).
En el caso de quiz se indica si se desea que al usuario se le muestre si la opción
seleccionada es correcta cuando realice su votación. Esto se indica a través del atributo
mostrarcorrecta. En este caso una de las preguntas debe ser la correcta por lo que su
atributo correcta debe tener valor verdadero.
125
Aplicación
En todos los tipos de contenido se indica obligatoriamente el título del mismo así
como la plantilla seleccionada (efecto de animación). En líneas generales, se indica el
texto en cada caso junto con el color, tamaño y su posición horizontal y vertical, el color
de fondo y las imágenes junto con su posición.
Para poder escribir los documentos XML con los datos necesarios y para poder
leerlos posteriormente una vez creados, se ha utilizado la API BATIK (para más
información consultar el capítulo ANEXOS apartado APIs utilizadas). No obstante,
debido a que esta API no permitía caracteres como los acentos o la ñ española, ha sido
necesario realizar algunos cambios en el código fuente de dicha API. Esto ha sido
posible debido a que es de código abierto.
4.4 Generación
de
contenidos
interactivos
Una vez creadas las plantillas SVGT con los campos vacíos, éstas permiten
generar contenidos interactivos personalizados. A través de la aplicación creada para el
proveedor de contenidos, éste establece la información necesaria para el contenido, por
ejemplo, el texto que desea como pregunta y el texto que desea en cada una de las
respuestas. Todos estos datos se almacenan en un fichero XML que se envía al
proveedor de servicios. Con este fichero y las plantillas SVGT, la aplicación del
proveedor de servicios es capaz de generar los contenidos interactivos definitivos en
formato SVGT.
Para poder leer los documentos plantilla SVG y modificar determinados
atributos y campos de los mismos se ha utilizado de nuevo la API BATIK.
Ejemplo de contenido interactivo definitivo de votación
<xml version="1.0" encoding="ISO-8859-1"?>
<svg contentScriptType="text/ecmascript" zoomAndPan="magnify"
xmlns:xlink="http://www.w3.org/1999/xlink" baseProfile="tiny"
contentStyleType="text/css" version="1.1" xml:space="preserve"
width="320"
stroke-miterlimit="2" preserveAspectRatio="xMidYMid meet"
126
Aplicación
viewBox="-160 -30 320 60" height="60"
xmlns="http://www.w3.org/2000/svg">
<!-- Definitions -->
<defs>
<image width="514" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="$$" xlink:type="simple" xlink:actuate="onLoad"
height="475" id="imagen" preserveAspectRatio="xMidYMid meet"
xlink:show="embed"/></defs>
<!-- Layer -->
<rect x="-160" y="-30" fill="#ffffff" width="320" height="60"
id="rect"/>
<g id="Layer_1">
<use x="-257" y="-237"
transform="translate(-1,-0.06) scale(0.626459,0.126316)"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="#imagen"
xlink:type="simple" xlink:actuate="onLoad"
xlink:show="embed"/>
<text x="-130.0" font-size="15" y="-11.0" fill="#000000"
font-family="Helvetica" id="preg">¿A quién quieres
expulsar de la casa?</text>
<text x="-221.0" font-size="15" y="7.0" fill="#000000"
font-family="Helvetica" visibility="hidden"
id="resp1">1.María<animate dur="3.15s"
fill="freeze" attributeName="visibility"
values="hidden;visible;visible" keyTimes="0;0.01;1"/>
<animateTransform type="translate" dur="3.15s"
keyTimes="0;0.22;1" fill="freeze" values="0,0;107,0;107,0"
attributeName="transform"/></text>
<text x="-228.0" font-size="15" y="24.0" fill="#000000"
font-family="Helvetica" visibility="hidden"
id="resp2">2.Roberto<animate dur="3.15s" fill="freeze"
attributeName="visibility" values="hidden;visible;visible"
keyTimes="0;0.23;1"/>
<animateTransform type="translate" dur="3.15s"
keyTimes="0;0.46;1" fill="freeze" values="0,0;114,0;114,0"
attributeName="transform"/></text>
<text x="150.0" font-size="15" y="7.0" fill="#000000"
font-family="Helvetica" visibility="hidden"
id="resp3">3.Lucía<animate dur="3.15s" fill="freeze"
attributeName="visibility" values="hidden;visible;visible"
keyTimes="0;0.47;1"/>
<animateTransform type="translate" dur="3.15s"
keyTimes="0;0.69;1" fill="freeze" values="0,0;-134,0;-134,0"
attributeName="transform"/></text>
<text x="150.0" font-size="15" y="24.0" fill="#000000"
font-family="Helvetica" visibility="hidden"
id="resp4">4.Marcos<animate dur="3.15s" fill="freeze"
attributeName="visibility" values="hidden;visible;visible"
keyTimes="0;0.71;1"/>
<animateTransform type="translate" dur="3.15s"
keyTimes="0;0.93;1" fill="freeze" values="0,0;-133,0;-133,0"
attributeName="transform"/></text></g>
</svg>
127
Imagen
(vacía)
pregunta
respuesta 1
respuesta 2
respuesta 3
respuesta 4
Aplicación
La apariencia del contenido interactivo de votación descrito en el código SVG
anterior es la siguiente:
Ejemplo de contenido interactivo definitivo de publicidad
<svg contentScriptType="text/ecmascript" zoomAndPan="magnify"
xmlns:xlink="http://www.w3.org/1999/xlink" baseProfile="tiny"
contentStyleType="text/css" version="1.1" xml:space="preserve"
width="320" stroke-miterlimit="2" preserveAspectRatio="xMidYMid meet"
viewBox="-234 -30 320 60" height="60"
xmlns="http://www.w3.org/2000/svg">
<!-- Definitions -->
<defs>
<image width="103" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="$$" xlink:type="simple" xlink:actuate="onLoad"
height="60" id="logo" preserveAspectRatio="xMidYMid meet"
xlink:show="embed" xlink:href="logo_wii_mod.jpg"/>
<image width="95" xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="$$" xlink:type="simple" xlink:actuate="onLoad"
height="60" id="imagen" preserveAspectRatio="xMidYMid meet"
xlink:show="embed" xlink:href="nintendo_wii_mod.jpg"/></defs>
<!-- Background -->
128
Logo
Imagen
Aplicación
<rect x="-234" y="-30" fill="#ffffff" width="320" height="60"
id="rect"/>
<!-- Layer -->
<g id="Layer_1">
<use x="20.0" y="-32.0" transform="translate(-74,-81)"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#logo"
xlink:type="simple" visibility="hidden" xlink:actuate="onLoad"
id="use1" xlink:show="embed">
<animate dur="4.05s" fill="freeze" attributeName="visibility"
values="hidden;visible;visible" keyTimes="0;0.13;1"/>
<animateTransform type="translate" dur="4.05s"
keyTimes="0;0.13;0.24;1" fill="freeze"
values="-74,-81;-74,-39;-73,-6;-73,-6"
attributeName="transform"/></use>
<use x="-30.0" y="-32.0" transform="translate(-336.5)
scale(1.75455,1)"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#imagen"
xlink:type="simple" visibility="hidden" xlink:actuate="onLoad"
id="use2" xlink:show="embed">
<animate dur="4.05s" fill="freeze" attributeName="visibility"
values="hidden;visible;visible" keyTimes="0;0.01;1"/>
<animateTransform type="rotate" dur="4.05s"
keyTimes="0;0.03;0.07;0.11;0.14;1" fill="freeze"
values="0 -336.5 0;-45.14 -180 0;-90.28 -180 0;-180.1 180 0;-360.21 -180 0;-360.21 -180 0"
attributeName="transform"/>
<animateTransform type="translate" dur="4.05s"
keyTimes="0;0.03;0.07;0.11;0.14;1" fill="freeze"
values="-336.5,0;-180,0;-180,0;-180,0;-180,0;-180,0"
attributeName="transform" additive="sum"/>
<animateTransform type="scale" dur="4.05s"
keyTimes="0;0.03;0.07;0.11;0.14;1" fill="freeze"
values="1.75455,1;1.75455,1;1.75455,1;1.75455,1;1.75455,1;1.75455,1"
attributeName="transform" additive="sum"/></use>
<a xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://es.wii.com" xlink:type="simple"
xlink:actuate="onRequest" id="link" xlink:show="replace">
<text font-size="9" x="-30.0" y="21.0"
transform="translate(38,64) scale(1.62701) translate(4.84)
skewX(-13)"
fill="#000000" text-anchor="middle"
font-family="Bookman Old Style" visibility="hidden"
id="texto"
font-weight="bold" letter-spacing="-0.03em">Tu consola
más divertida<animate dur="4.05s"
fill="freeze" attributeName="visibility"
values="hidden;visible;visible;hidden;visible;visible;hidden;visible;v
isible" keyTimes="0;0.19;0.24;0.35;0.46;0.58;0.69;0.8;1"/>
<animate dur="4.05s" fill="freeze"
attributeName="letter-spacing"
values="-0.03em;-0.03em;-0.06em;-0.06em"
keyTimes="0;0.22;0.24;1"/>Tu consola más
divertida<animateTransform type="translate"
dur="4.05s" keyTimes="0;0.24;1" fill="freeze"
values="38,64;37.95,-10.05;37.95,-10.05"
attributeName="transform"/>
<animateTransform type="scale" dur="4.05s" keyTimes="0;0.24;1"
fill="freeze"
values="1.62701,1.62701;1.62701,1.62701;1.62701,1.62701"
129
Link
Texto
Aplicación
attributeName="transform" additive="sum"/></text></a></g>
</svg>
La apariencia del contenido de publicidad descrito en el código anterior es la
siguiente:
4.5 Visor SVG Tiny
Tal y como se ha comentado al comienzo de este capítulo, existen varios visores
SVG Tiny en el mercado pero entre ellos no son homogéneos puesto que un mismo
documento SVG se reproduce de diferentes maneras en diferentes visores. Para evitar
que el proveedor de contenidos y el proveedor de servicios reproduzcan sus documentos
SVG de manera distinta, la aplicación implementa un visor SVG Tiny integrado dentro
130
Aplicación
de la misma. Este reproductor se ha creado utilizando la API de TinyLine (para más
información consultar el apartado ANEXOS capítulo APIs utilizadas).
El visor se puede utilizar tanto para ver el resultado final de los contenidos
interactivos creados con los datos aportados como para visualizar documentos SVG que
estén almacenados en el equipo.
El visor utiliza una única fuente embebida por lo que sea cual sea la fuente que
tengan establecida los elementos de texto del documento SVG a reproducir, siempre se
reproducirán con este tipo de letra. La API de TinyLine requiere que el tipo de letra esté
definido en un fichero SVG mediante definiciones propias de SVG. Por ese motivo, fue
necesario buscar una fuente de libre distribución en formato ttf (destacar que era
necesario que la fuente admitiera determinados caracteres como el acento o la ñ). Para
transformar esa definición de la fuente a formato SVG se utilizó la herramienta ttf2svg
de Batik, que permite realizar este tipo de transformaciones. Un fragmento de la fuente
resultante en formato SVG se muestra a continuación:
Definición de la fuente utilizada por el visor en formato SVG
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" >
<svg width="800" height="600">
<defs>
<font id="Helvetica" horiz-adv-x="436" ><font-face
font-family="Helvetica"
units-per-em="1000"
panose-1="2 11 6 3 6 1 0 0 0 0"
ascent="973"
descent="-219"
alphabetic="0" />
<missing-glyph horiz-adv-x="432" d="M33 0V666H366V0H33ZM66
33H333V633H66V33Z" />
...
<glyph unicode="!" glyph-name="exclam" horiz-adv-x="206" d="M142
195H65V711H142V195ZM50 46Q50 80 81 94Q92 98 103 98Q137 98 151 68Q153
62 154 57Q156 52 155 46Q155 12 125 -2Q114 -6 103 -6Q69 -6 55 24Q53 30
52 35Q50 40 50 46Z" />
<glyph unicode="&" glyph-name="ampersand" horiz-adv-x="626"
d="M381 600Q366 644 314 656Q299 660 282 660Q229 660 195 618Q172 590
172 554Q172 540 175 526Q187 468 241 446Q261 438 282
438H365V369H284Q194 369 151 301Q126 263 126 210Q126 193 129
177Q145 106 208 72Q242 54 279 54Q351 54 398 112Q431 152 431
199H326V267H581V198H512Q512 127 456 63Q387 -15 279 -15Q169 -15 101
67Q65 110 54 164Q49 187 49 210Q49 304 120 370Q153 400 183 407Q115 439
99 513Q95 533 95 554Q95 627 156 681Q211 729
282 729Q395 729 445 638L381 600Z" />
131
Aplicación
<glyph unicode="'" glyph-name="quotesingle" horiz-adv-x="207"
d="M78 533L68 716Q68 746 95 752Q99 753 103 753H105Q133 753 140 725Q141
721 141 716L131 533Q130 514 109 511Q107 510 104 510Q83 510 79 529Q78
531 78 533Z" />
...
<glyph unicode="A" glyph-name="A" horiz-adv-x="656" d="M327 613L231
303H426L327 613ZM448 247H205L121 0H40L296 711H358L614 0H531L448 247Z"
/>
...
<glyph unicode="t" glyph-name="t" horiz-adv-x="360" d="M124
458H55V524H124V646H198V524H294V458H198V105Q198 95 200 87Q208 48 255
48H289V-14H255Q155 -14 133 45Q130 53 128 62Q124 79 124 103V458Z" />
...
<glyph unicode="Ã" glyph-name="Atilde" horiz-adv-x="651" d="M179
864Q219 897 235 904Q252 911 268 911Q292 911 330 876Q375 840 398
837Q427 837 474 873Q486 882 490 885V814Q444 779 431 773Q414 766 398
766Q368 766 324 805Q287 838 267 840Q235
840 194 806Q182 795 179 793V864ZM337 613L241 303H436L337 613ZM458
247H215L131 0H50L306 711H368L624 0H541L458 247Z" />
<glyph unicode="Ñ" glyph-name="Ntilde" horiz-adv-x="651" d="M187
854Q227 887 243 894Q260 901 276 901Q300 901 338 866Q383 830 406
827Q435 827 482 863Q494 872 498 875V804Q452 769 439 763Q422 756 406
756Q376 756 332 795Q295 828 275 830Q243
830 202 796Q190 785 187 783V854ZM74 0V711H149L510
144V711H587V0H516L151 581V0H74Z" />
...
</font>
</defs>
</svg>
Como se puede observar en el código anterior, SVG describe cada una de las
letras que puede reproducir. Destacar que à hace referencia a la Á y Ñ hace
referencia a la letra Ñ.
A continuación se muestran diversos ejemplos tanto de contenidos publicitarios
como de votación/quiz generados por la aplicación desarrollada en el proyecto y
visualizados mediante el visor que se encuentra implementado en la misma (Nota: tener
en cuenta que estos contenidos son animados, característica que no se puede observar en
papel):
132
Aplicación
Ejemplos de contenidos publicitarios
133
Aplicación
Ejemplos de contenidos de votación/quiz
134
Aplicación
4.6 Implementación
La aplicación se ha desarrollado con el lenguaje java utilizando su plataforma de
desarrollo J2SE 5.0. El entorno de desarrollo utilizado ha sido Netbeans 5.5.
Para el tratamiento de documentos XML y, principalmente, SVG ha sido
necesario utilizar dos APIs de libre distribución que permiten trabajar con este tipo de
documentos:
-
API TinyLine
-
API Batik
La API TinyLine se ha utilizado para llevar a cabo la implementación del visor
SVG ya que contiene clases que permiten “dibujar” los documentos SVG. El visor SVG
es un componente que extiende al componente Canvas de la librería AWT de java.
La API Batik se ha utilizado para parsear los ficheros XML y SVG, es decir,
gracias a esta API se han podido leer correctamente los dos tipos de documentos así
como generar nuevos o modificar los existentes.
Debido a que los contenidos interactivos deben incluir texto en un castellano
correcto (es decir, deben incluir acentos, letras como la ñ, etc), fue necesario la
modificación de algunas clases de la API Batik ya que esta API, originalmente, no
aceptaba este tipo de caracteres. Al ser una API de código libre, fue posible descargar
los códigos fuentes, realizar las modificaciones pertinentes y volver a empaquetarlos
para poder ser utilizados por la aplicación. Si no se hubiesen realizado estos cambios, a
la hora de parsear un fichero XML o SVG que incluyera caracteres especiales, la
aplicación hubiera fallado.
Para generar el instalador de la aplicación se ha utilizado la herramienta IzPack
que es de libre distribución. Esta herramienta genera un fichero .jar que, si se ejecuta,
instala la aplicación en el ordenador. Como puede ocurrir que algunos usuarios no
conozcan el formato jar, posteriormente se ha utilizado la herramienta JSmooth para
generar un fichero .exe a partir del fichero .jar de instalación. De esta forma, el usuario
verá un fichero .exe que le será familiar.
135
Aplicación
A continuación se muestran los diagramas de clases de aquellas clases que
permiten crear y leer documentos SVG y documentos XML:
Diagramas de clases
EscribirXMLVotacion
+documento: Document = null
+path: String
<<create>>+EscribirXMLVotacion(_path: String)
+establecerImagenFondo(imagen: String): int
+establecerColorFondo(colorFondo: String): int
+establecerTitulo(tit: String): int
+establecerTipo(_subtipo: String, _adicional: boolean): int
+establecerPregunta(preg: String, color: String, tamaño: String, x: String, y: String): int
+establecerRespuesta(resp: String, color: String, tamaño: String, x: String, y: String, correcta: boolean): int
+establecerPlantilla(plantilla: String): int
~generaTextoXML(): String
+obtenerFicheroXML(): int
~grabaDocumentoXML(textoXML: String): int
EscribirXMLPublicidad
+documento: Document = null
+path: String
<<create>>+EscribirXMLPublicidad(_path: String)
+establecerImagen(imagen: String, x: String, y: String): int
+establecerLogo(logo: String, x: String, y: String): int
+establecerTexto(_texto: String, tamaño: String, color: String, x: String, y: String): int
+establecerTitulo(tit: String): int
+establecerTipo(): int
+establecerFondo(colorFondo: String): int
+establecerEnlace(enlace: String): int
+establecerPlantilla(plantilla: String): int
~generaTextoXML(): String
+obtenerFicheroXML(): int
~grabaDocumentoXML(textoXML: String): int
LeerSVG
LeerSVGPubli
+doc: SVGDocument
+doc: SVGDocument
<<create>>+LeerSVGPubli(tipo: int)
+getAlignHorizontalTexto(): double
+getAlignVerticalTexto(): double
+getAlignHorizontalImagen(): double
+getAlignVerticalImagen(): double
+getAlignHorizontalLogo(): double
+getAlignVerticalLogo(): double
<<create>>+LeerSVG(tipo: int)
+getAlignHorizontalPregunta(): double
+getAlignVerticalPregunta(): double
+getAlignHorizontalRespuesta1(): double
+getAlignHorizontalRespuesta2(): double
+getAlignHorizontalRespuesta3(): double
+getAlignHorizontalRespuesta4(): double
+getAlignVerticalRespuesta1(): double
+getAlignVerticalRespuesta2(): double
+getAlignVerticalRespuesta3(): double
+getAlignVerticalRespuesta4(): double
136
Aplicación
LeerXML
EscribirSVGVotacion
+doc: SVGDocument
+tipo: int
~svgGenerator: SVGGraphics2D
~svgRoot: Element
<<create>>+EscribirSVGVotacion(_tipo: int)
+cambiarImagen(imagenXML: String): int
+cambiarTextoPregunta(pregunta: String): int
+cambiarTextoRespuesta1(respuesta: String): int
+cambiarTextoRespuesta2(respuesta: String): int
+cambiarTextoRespuesta3(respuesta: String): int
+cambiarTextoRespuesta4(respuesta: String): int
+cambiarTamañoPregunta(tamaño: String): int
+cambiarTamañoRespuesta1(tamaño: String): int
+cambiarTamañoRespuesta2(tamaño: String): int
+cambiarTamañoRespuesta3(tamaño: String): int
+cambiarTamañoRespuesta4(tamaño: String): int
+cambiarColorPregunta(color: String): int
+cambiarColorRespuesta1(color: String): int
+cambiarColorRespuesta2(color: String): int
+cambiarColorRespuesta3(color: String): int
+cambiarColorRespuesta4(color: String): int
+cambiarAlineacionHorizontalPregunta(x: String): int
+cambiarAlineacionHorizontalRespuesta1(x: String): int
+cambiarAlineacionHorizontalRespuesta2(x: String): int
+cambiarAlineacionHorizontalRespuesta3(x: String): int
+cambiarAlineacionHorizontalRespuesta4(x: String): int
+cambiarAlineacionVerticalPregunta(y: String): int
+cambiarAlineacionVerticalRespuesta1(y: String): int
+cambiarAlineacionVerticalRespuesta2(y: String): int
+cambiarAlineacionVerticalRespuesta3(y: String): int
+cambiarAlineacionVerticalRespuesta4(y: String): int
+cambiarColorFondo(color: String): int
+obtenerFicheroSVG(path: String): int
EscribirSVGPublicidad
+doc: SVGDocument
+tipo: int
<<create>>+EscribirSVGPublicidad(_tipo: int)
+cambiarImagen(imagenXML: String): int
+cambiarLogo(imagenLogo: String): int
+cambiarTexto(texto: String): int
+cambiarLink(_link: String): int
+cambiarTamañoTexto(tamaño: String): int
+cambiarColorTexto(color: String): int
+cambiarColorFondo(color: String): int
+cambiarAlineacionHorizontalTexto(x: String): int
+cambiarAlineacionVerticalTexto(y: String): int
+cambiarAlineacionHorizontalImagen(x: String): int
+cambiarAlineacionVerticalImagen(y: String): int
+cambiarAlineacionHorizontalLogo(x: String): int
+cambiarAlineacionVerticalLogo(y: String): int
+obtenerFicheroSVG(path: String): int
+doc: Document = null
<<create>>+LeerXML(path: String)
+getTipo(): int
+getImagenPublicidad(): String
+getImagenVotacion(): String
+getAlineacionHorizImagenPublicidad(): String
+getAlineacionVertiImagenPublicidad(): String
+getLogoPublicidad(): String
+getAlineacionHorizLogoPublicidad(): String
+getAlineacionVertiLogoPublicidad(): String
+getPlantilla(): int
+getTextoPregunta(): String
+getTextoRespuesta1(): String
+getTextoRespuesta2(): String
+getTextoRespuesta3(): String
+getTextoRespuesta4(): String
+getTextoPublicidad(): String
+getAlineacionHorizTextoPublicidad(): String
+getAlineacionVertiTextoPublicidad(): String
+getAlineacionHorizPreguntaVotacion(): String
+getAlineacionVertiPreguntaVotacion(): String
+getAlineacionHorizRespuesta1Votacion(): String
+getAlineacionVertiRespuesta1Votacion(): String
+getAlineacionHorizRespuesta2Votacion(): String
+getAlineacionVertiRespuesta2Votacion(): String
+getAlineacionHorizRespuesta3Votacion(): String
+getAlineacionVertiRespuesta3Votacion(): String
+getAlineacionHorizRespuesta4Votacion(): String
+getAlineacionVertiRespuesta4Votacion(): String
+getLink(): String
+getTitulo(): String
+getTamañoTextoPublicidad(): String
+getTamañoTextoPreguntaVotacion(): String
+getTamañoTextoRespuesta1Votacion(): String
+getTamañoTextoRespuesta2Votacion(): String
+getTamañoTextoRespuesta3Votacion(): String
+getTamañoTextoRespuesta4Votacion(): String
+getColorTextoPublicidad(): String
+getColorTextoPreguntaVotacion(): String
+getColorTextoRespuesta1Votacion(): String
+getColorTextoRespuesta2Votacion(): String
+getColorTextoRespuesta3Votacion(): String
+getColorTextoRespuesta4Votacion(): String
+getColorFondo(): String
+getNumRespuestasVotacion(): int
+isResp1Correcta(): boolean
+isResp2Correcta(): boolean
+isResp3Correcta(): boolean
+isResp4Correcta(): boolean
+isMostrarEstadisticas(): boolean
+isMostrarSiCorrecta(): boolean
137
Aplicación
4.7 Estudio financiero
A continuación se muestra la siguiente tabla en la que se puede apreciar una
estimación del coste del proyecto realizado:
Módulo
Horas
estimadas
Coste/hora
Coste del módulo
(€)
Estudio de tecnologías
Tecnologías rich media
65
55
3575
Guías de programación
15
55
825
de
55
55
3025
Tecnologías de presentación de
contenidos
25
55
1375
Tecnologías de distribución de
contenidos
25
55
1375
Tecnologías de personalización
de contenidos
65
55
3575
Sistemas de
contenidos
vinculación
Subtotal estimado: …………………………………………………………………………………. 13.750
Implementación
Generación de plantillas SVG
80
30
2400
Generación de plantillas XML
60
30
1800
Interfaz gráfico
150
30
4500
60
30
1800
Generación
interactivos
de
contenidos
Subtotal estimado: ………………………………………………………………………………...... 10.500
Total: ………………………………………………………………………………………………. 24.250
El coste total del proyecto asciende a 24.250€ según los cálculos estimados.
137
Pilotos y experiencias
5 PILOTOS Y EXPERIENCIAS
5.1 PILOTO DVB-H EN ALCÁZAR DE SAN JUAN
5.2 PILOTO DE BÉLGICA MADUF
5.3 PILOTO DE LA REPÚBLICA CHECA
5.4 PILOTO DE PARÍS TDF
5.5 PILOTO DE PARIS CANAL +
5.6 PILOTO DE ALEMANIA
138
Pilotos y experiencias
5. Pilotos y experiencias
En este capítulo se describen los principales proyectos pilotos DVB-H que se
han realizado (o se están realizando) en Europa con entrega de contenidos interactivos a
los usuarios.
5.1 Piloto DVB-H en Alcázar de San Juan
(Castilla la Mancha)
Este piloto se puso en marcha en diciembre de 2006. Es el primer piloto con
tecnología DVB-H que se realiza en España con aplicaciones interactivas asociadas a la
visualización de contenidos audiovisuales en el teléfono móvil.
Los objetivos de este piloto son los siguientes:
-
Realizar el estudio, diseño y desarrollo de servicios interactivos avanzados
para TV Móvil basados en la tecnología DVB-H.
-
Analizar y evaluar el estado de interoperabilidad entre los distintos
suministradores, elementos o componentes técnicos que conforman la prueba
piloto.
-
Profundizar en el análisis y estudio de coberturas con la tecnología DVB-H.
-
Evaluar los requisitos y necesidades para adaptar las infraestructuras de
radiodifusión existentes para soportar la tecnología DVB-H.
Los 35 usuarios seleccionados para la prueba piloto, ciudadanos de la localidad
de Alcázar de San Juan, disponían de terminales móviles Motorola, especialmente
diseñados para mejorar la experiencia de TV en el móvil. Los dispositivos sólo se
podían utilizar en la localidad de Alcázar de San Juan.
Telefónica Móviles España lidera este piloto aportando la plataforma de servicio
y la plataforma de interactividad, y Telecom Castilla-La Mancha ha desplegado la
139
Pilotos y experiencias
infraestructura de radio necesaria para la difusión de la señal. En el proyecto colaboran,
como socios tecnológicos, Siemens, Sidsa, Hispasat y Telefónica Servicios
Audiovisuales. En cuanto a los contenidos, los de carácter generalista los aportan la
televisión de Castilla-La Mancha y la televisión local de Alcázar de San Juan, y Antena
3, TVE regional e Infinia aportarán contenidos específicos para las aplicaciones
interactivas (juego “Quieres ser Millonario”, video clips musicales y otros contenidos
de carácter regional).
Participantes del piloto
Arquitectura del piloto
En este piloto se han probado las siguientes aplicaciones interactivas:
•
JukeBox (“Gramola”)
140
Pilotos y experiencias
Aplicación para que el usuario elija contenidos específicos: documentales de la
región (campo, caza, culturales, etc), canal temático, música, etc.
Experiencia del usuario:
-
El usuario visualiza un canal de contenidos.
-
El usuario vota por aquella opción que desea sea emitida tan pronto finalice
el contenido que se está emitiendo en ese instante.
-
El siguiente contenido será el más votado por los usuarios, de una lista con
distintas opciones asociadas un contenido específico.
-
En todo momento el usuario puede visualizar el estado o balance de las
votaciones existente para cada contenido
•
Chat
Sobre un canal que se esté emitiendo, los usuarios crean una comunidad de
debate para dar su opinión sobre cualquier asunto relacionado con los contenidos
que se estén emitiendo.
Experiencia del usuario:
-
El usuario visualiza un canal de contenidos, normalmente emitidos en directo
(o en “vivo”).
-
El usuario puede identificarse con un pseudónimo e invocar y/o participar en
un debate alrededor del tema que se esté emitiendo.
-
Cada usuario además de estar identificado por su pseudónimo, se
diferenciará del resto por el color que haya seleccionado para destacar sus
intervenciones.
•
Juego “quieres ser millonario”
El usuario participa en el programa resolviendo las mismas preguntas que se
plantean al concursante. Como resultado conocerá qué jugador ha acertado más
preguntas.
Experiencia del usuario:
141
Pilotos y experiencias
-
Al usuario se le plantea la pregunta que está haciendo el presentador.
-
Debe dar su respuesta antes de que se desvele el resultado.
-
Si acierta continúa jugando hasta que el concursante quede eliminado o
termine la ronda.
-
Si falla la respuesta debe esperar a que empiece la siguiente ronda.
Ejemplos de contenidos interactivos del piloto
142
Pilotos y experiencias
5.2 Piloto de Bélgica MADUF
Este piloto (denominado MADUF) se inició en octubre de 2006 y se prevé que
finalice en abril de 2008. MADUF es un proyecto IBBT que intenta estudiar las
posibilidades de la televisión móvil utilizando DVB-H. Los participantes del proyecto
son las operadoras de telecomunicaciones Telenet, Belgacom y Proximus, VRT
(Vlaamse Radio en Televisie) como transmisor de red y Siemens, Option y Scientific
Atlanta como suministradores de equipos y sistemas. El proyecto está respaldado por
los centros de investigación de la Universidad Católica de Leuven (CUO y ICRI), la
universidad de Ghent (IBCN, WICA, MMLab y MICT), la universidad de Bruselas
(ETRO y SMIT) y IMEC.
El objetivo de MADUF es generar un modelo óptimo para proporcionar
servicios de televisión móvil en Bélgica a través de DVB-H y desarrollar una prueba de
concepto. Esto implica investigar no sólo los aspectos técnicos sino también los
aspectos legales y económicos.
El número de usuarios utilizados para realizar este piloto es de 100. Éstos
recibirán en sus teléfonos móviles contenidos televisivos, radio y servicios interactivos
(la plataforma de interactividad consta de una plataforma cliente servidor que permite
este tipo de contenidos).
El formato de video utilizado es H.264
5.3 Piloto de la República Checa
Este piloto se realizó en octubre de 2005. Las compañías participantes fueron las
siguientes: T-Mobile Czech (operador de red móvil), Siemens (BenQ), Ceské
Radiokomunikace (broadcaster terrestre), Rohde & Schwarz (componentes de red DVBH), Czech TV (canales de televisión) y TV Prima.
143
Pilotos y experiencias
El principal objetivo de este piloto era probar la interactividad de la televisión en
el móvil basándose en el estándar DVB-H. Los contenidos a los que pudieron acceder
los usuarios fueron los siguientes:
-
Cuatro cadenas de televisión: T-Music charts, CT24 (canal de noticias),
canales live, reality show.
-
Contenidos interactivos: votar por la canción favorita y descargar tonos.
El formato de video utilizado fue H.264 y la plataforma de interactividad
únicamente utilizaba SMS.
Los usuarios disponían de dispositivos BenQ para poder acceder a estos
servicios.
5.4 Piloto de París TDF
Este piloto comenzó en septiembre de 2005 y finalizó en junio de 2006. Como
compañías audiovisuales participaron: TF1, France Télévisions, ARTE, Canal, M6,
Lagardere Active Broadcast, TPS; como compañías de radio se incluyeron: Radio
France, RTL, NextRadio, RFI, Skyrock, Lagardere, Radio Orient, Radio Notre Dame,
Oui FM, Superloustic, MFM, Radio Classique; como operadores móviles participaron:
Orange, SFR, Bouygues Telecom.
En este piloto participaron cerca de 100 usuarios que pudieron acceder a 14
cadenas de televisión tanto terrestres como de satélite, a 13 cadenas de radio, a las guías
de programación (ESG) y a aplicaciones interactivas (la plataforma de interactividad
consta de acceso WAP a los servicios y ESG broadcast). La recepción de los programas
se realizó a través de terminales SAGEM MyX8.
El formato de video utilizado es H264.
144
Pilotos y experiencias
5.5 Piloto de Paris Canal +
Este piloto comenzó en septiembre de 2005 y finalizó en junio de 2006.
Los participantes de este proyecto son: grupo Canal+ (operador de la plataforma
broadcast), Nokia (proveedor de equipos y terminales DVB-H), SFR (operador de red
de telecomunicaciones) y Towercast (proveedor y operador de infraestructura
broadcast).
El número de usuarios de este piloto fue de 500. Estos pudieron disfrutar de los
siguientes contenidos:
-
13 canales de televisión.
-
4 estaciones de radio.
-
Servicios interactivos utilizando como plataforma de interactividad Nokia
IPDC.
El formato de video utilizado fue H263.
Los terminales de los que disponían los usuarios eran Nokia 7710.
5.6 Piloto de Alemania
Este piloto es el principal que se ha realizado orientado a la publicidad en la
televisión móvil. En él Ericsson ha colaborado con un operador móvil, una cadena de
televisión y un grupo de publicistas seleccionados.
El piloto incluía tanto anuncios estáticos (banners de imágenes ó tickers de
texto), como anuncios dinámicos/interactivos (personalizados, incluyendo encuestas
simples y con posibilidad de solicitar más información, de abrir un sitio WAP, o de
acceder a un clip informativo bajo demanda).
145
Pilotos y experiencias
Ejemplo de publicidad en el piloto
146
Conclusiones
6 CONCLUSIONES
147
Conclusiones
6. Conclusiones
Hoy en día la publicidad en el móvil es una forma de marketing más directa y
efectiva que cualquier otro medio publicitario. Por ese motivo, actualmente ya muchas
compañías han optado por entregar sus contenidos publicitarios a través de este medio.
Por otro lado, la televisión en el móvil es un servicio que se encuentra
implantado actualmente en muy pocos países pero, sin embargo, se prevé que a corto
plazo sea implantado en muchos países. Es un servicio novedoso y, por los estudios y
encuestas realizados, parece que será aceptado y utilizado por muchos de los usuarios de
telefonía móvil. Dentro de este marco también es posible la inclusión de publicidad, por
lo que las diferentes empresas deberán considerar la televisión en el móvil como un
nuevo medio para poder ofrecer sus contenidos publicitarios. Por este motivo la
publicidad jugará un papel clave en el desarrollo de los canales de TV móvil, hasta que
se conviertan en un servicio de importancia para el consumidor.
Se recomienda que los contenidos auxiliares para televisión en el móvil tales
como publicidad o votaciones se realicen utilizando tecnologías rich media. De esa
forma se puede conseguir una experiencia más rica de cara al usuario, así como también
dotar de interactividad a dichos contenidos. Existen varias tecnologías habilitadoras de
rich media para dispositivos móviles. Entre ellas, la más potente es LASeR.
Los contenidos interactivos deben estar vinculados a sus correspondientes
contenidos principales. Una forma de llevar a cabo esta vinculación es a través de la
ESG (Guía Electrónica de Servicios), haciendo uso de algunos fragmentos de la misma.
Por otro lado, la entrega de los contenidos interactivos a los terminales móviles
se puede realizar mediante unicast o mediante broadcast. En el caso de la comunicación
unicast, se realizará a través de la red móvil 2.5G/3G mientras que la distribución
broadcast se llevará a cabo a través del carrusel.
Una vez que el contenido se haya entregado al terminal, para poder visualizarlo
es necesario un motor rich media que permite integrar todos los medios en una única
presentación. En cuanto a los visores SVG que existen en el mercado, destacar que entre
148
Conclusiones
ellos no son homogéneos porque el mismo contenido se reproduce de manera distinta
con diferentes visores.
Este tipo de publicidad no debe seguir el mismo patrón que la que se utiliza
actualmente en televisión o en Internet. La clave radica principalmente en conseguir
hacer llegar al usuario sólo aquellos contenidos publicitarios que sean de su interés, así
como no utilizarlos de manera intrusiva. Para poder entregar al usuario el contenido
personalizado es necesario etiquetar los diferentes contenidos mediante metadatos que
los describan. Por otro lado, hay que crear el perfil del usuario con sus preferencias
televisivas a través de algún mecanismo, por ejemplo, mediante ontologías. Una vez que
se tienen los contenidos etiquetados y que se dispone del perfil del usuario, tan sólo es
necesario aplicar un proceso de razonamiento para determinar qué contenidos serán del
agrado del usuario y así sólo entregarle dichos contenidos.
En general, los principales foros, organismos e iniciativas (3GPP, OMA, DVB
etc) en el área de los servicios audiovisuales de la televisión móvil apenas han
comenzado a tratar la problemática específica asociada a la interactividad en este tipo de
servicios.
La publicidad ha tardado en llegar al móvil pero por las previsiones parece que
en los próximos años se producirá un gran despliegue en estos medios. De hecho OMA
dispone de un grupo de trabajo que está desarrollando un enabler para intentar
estandarizar este tipo de publicidad. En definitiva, la publicidad en el móvil está
comenzando a extenderse.
149
Bibliografía
7 BIBLIOGRAFÍA
150
Bibliografía
7. Bibliografía
Para la elaboración de la documentación que incluye este proyecto referente a se
han consultado las siguientes direcciones:
http://www.streamezzo.com/
https://svgsalamander.dev.java.net/
http://www.ikivo.com/
http://www.bitflash.com/prod_playerSVGT.html
http://esvg.ultimodule.com/bin/esvg/templates/splash.asp?NC=8286X
http://www.emiasys.net/
http://www.televisiondigital.es/TInteractiva/Conceptos/
http://www.w3.org/Graphics/SVG/
http://research.nokia.com/people/vidya_setlur/papers/1223CameraReady.pdf
http://inka.f4.fhtw-berlin.de/wci/docs/Dr.Richartz_web.pdf
http://mosaic.uoc.edu/articulos/ctardaguila1205.html
http://www.adobe.com/products/flashlite/
http://es.wikipedia.org/wiki/Gu%C3%ADa_Electr%C3%B3nica_de_Programas
http://www.answers.com/topic/electronic-program-guide
http://www.faqs.org/rfcs/rfc3926.html
http://www.tml.tkk.fi/Studies/T-111.590/2005/lectures/peltotalo.pdf
http://www.it.uniovi.es/docencia/Telematica/srcm/material/Tema7_TDT.pdf
151
Bibliografía
http://es.wikipedia.org/wiki/Ontolog%C3%ADa_(Inform%C3%A1tica)
http://es.wikipedia.org/wiki/Resource_Description_Framework
http://www.feedshow.com/show_itemsfeed=293c92bd58920832d06a8ebfe532a298
http://es.wikipedia.org/wiki/MPEG-7
http://www.tv-anytime.org/
http://es.wikipedia.org/wiki/TV-Anytime
http://www.w3.org/TR/owl-features/
http://alcazardesanjuan.wordpress.com/2006/12/15/servicios-de-tv-en-el-movilen-alcazar-de-san-juan/
http://www.mundoplus.tv/noticias.php?seccion=tv_digital&relacionadas=varios/
tdt&id=2598
http://www.dvb-h.org/services.htm
http://xmlgraphics.apache.org/batik/
http://www.tinyline.com/
http://izpack.org/
http://jsmooth.sourceforge.net/
http://www.openmobilealliance.org/
http://www.dvb.org/
http://mmaglobal.com/
http://www.mmaspain.com/
152
Bibliografía
http://www.mpeg.org/MPEG/index.html
http://marketingdirecto.com/
http://www.aecomo.org/cat.asp?catid=158
http://es.wikipedia.org/wiki/Publicidad
http://www.aulafacil.com/Publicidad/temario.htm
153
Anexos
8 ANEXOS
8.1 MANUAL DEL USUARIO
8.2 ORGANISMOS
DE
RELACIONADOS
8.3 APIS UTILIZADAS
8.4 ACRÓNIMOS
154
ESTANDARIZACIÓN
Anexos
8. Anexos
8.1 Manual del usuario
Debido a que se han desarrollado dos aplicaciones se requieren dos manuales de
usuario diferentes. El primero de ellos será el correspondiente a la aplicación destinada
al proveedor de contenidos mientras que el segundo explicará el funcionamiento de la
aplicación que usará el proveedor de servicios.
8.1.1 MiCanal ITG
MiCanal Interactive Template Generator (MiCanal ITG) permite crear plantillas
XML con los datos necesarios para que, una vez sean entregadas al proveedor de
servicio, éste sea capaz de generar el contenido interactivo descrito por dicha plantilla.
A través de esta aplicación se permiten crear plantillas para dos tipos de
contenidos interactivos: contenidos publicitarios y contenidos de votaciones o quiz.
8.1.1.1 Instalación de la aplicación
Adjunto a esta documentación se entrega un CD en el que se encuentra el fichero
que permite instalar esta aplicación. Dicho fichero es MiCanalITG.exe. Para comenzar
con la instalación del programa tan sólo hay que hacer doble clic sobre dicho fichero. La
primera pantalla que aparece en la instalación en la siguiente:
155
Anexos
Para comenzar con la instalación tan sólo es necesario pulsar el botón siguiente.
En la siguiente pantalla es necesario indicar el directorio de instalación que por defecto
será C:\Archivos de programa\MiCanal ITG:
156
Anexos
Pulsando siguiente se procede a la instalación de la aplicación que estará
completamente instalada cuando la pantalla tenga una apariencia similar a la siguiente:
Por último, pulsando en siguiente se muestra la última pantalla de la instalación
en la que se permite personalizar el grupo de programas de los accesos directos a la
aplicación así como crear accesos directos desde el escritorio:
157
Anexos
Pulsando en siguiente con las opciones seleccionadas se da por finalizada la
instalación:
158
Anexos
8.1.1.2 Inicio de la aplicación
Cuando se inicia la aplicación presenta un aspecto similar al siguiente:
La aplicación ofrece cuatro opciones posibles:
3. Abrir el visor SVG Tiny para poder visualizar un contenido SVG
4. Crear una nueva plantilla que permita generar contenidos publicitarios
5. Crear una nueva plantilla que permita generar votaciones/quiz
6. Cargar una plantilla XML ya creada
Las opciones anteriores están disponibles desde las siguientes opciones de menú
o desde la barra de herramientas:
•
Visor SVG: Complementos → Abrir Visor SVG Tiny o desde el botón Abrir
visor SVG Tiny de la barra de herramientas
•
Contenido publicitario: Archivo → Nuevo → Publicidad o desde el botón Nueva
publicidad de la barra de herramientas
159
Anexos
•
Contenido de votaciones/quiz: Archivo → Nuevo → Votación o desde el botón
Nueva votación de la barra de herramientas
•
Abrir plantilla XML: Archivo → Abrir Fichero XML o desde el botón Abrir
XML de la barra de herramientas
8.1.1.3 Visor SVG Tiny
Para mayor comodidad a la hora de crear las plantillas XML, la aplicación
incluye un visor SVG para poder visualizar el resultado que obtendrá el proveedor de
servicios cuando cree el contenido interactivo a partir de la plantilla XML que se
genere. Además, este visor también permite cargar otros contenidos SVG que estén
almacenados en el equipo.
Si se abre el visor SVG Tiny después de arrancar la aplicación se mostrará una
pantalla similar a la siguiente:
160
Anexos
De esta forma sólo se puede utilizar el visor para abrir ficheros SVG que se
encuentren almacenados en el equipo. Para abrir un fichero SVG hay que pulsar el
botón Abrir fichero SVGT y seleccionar el fichero que se desee abrir:
161
Anexos
Pasados unos segundos (dependiendo del peso del fichero cargado), éste se
mostrará en el visor siempre y cuando tenga un formato compatible, ya que si no es así
el visor informará de que el formato no es válido. La ruta del fichero cargado se
mostrará en la caja de texto situada debajo del visor.
Existen varios botones que permiten interactuar con la imagen/animación
cargada en el visor. Dichos botones están situados en la caja de herramientas situada a la
izquierda del visor y son los siguientes:
•
aumentar/disminuir zoom: estos botones permiten aumentar y disminuir el zoom
de la imagen cargada en el visor. A continuación se muestra el efecto del zoom
aumentado del ejemplo anterior:
162
Anexos
•
pan: permite mover la imagen cargada en el visor de un lado a otro de la
pantalla. Para ello se hace click sobre el visor y sin soltar se arrastra el ratón
hasta la posición deseada, dejando de presionar el botón de ratón. Aparece una
línea vertical que indica hacia donde se va a mover la imagen:
163
Anexos
•
link: este botón permite seguir los enlaces en el caso de que el documento SVG
contenga algún enlace, ya sea hacia una página web o hacia otro documento
SVG. Esta opción es especialmente útil cuando se crea un contenido publicitario
puesto que el texto de la publicidad puede incluir un enlace a la página web del
anunciante.
•
Refrescar: este botón permite volver al estado original del documento SVG
cargado, es decir, sin zoom o sin desplazamiento.
•
Play/pause: permite pausar o la animación que se esté visualizando en el visor.
8.1.1.4 Contenidos publicitarios
El formulario que se presenta para crear una plantilla XML de contenido
publicitario es el siguiente:
164
Anexos
Los campos a rellenar son los siguientes:
•
Nombre del anuncio: nombre que se le quiere asignar al anuncio. Por ejemplo,
anuncio Wii. Este campo es obligatorio.
•
Ruta de la imagen y ruta del logo: el anuncio publicitario puede tener una
imagen del artículo anunciado y un logo de la marca. Ambos elementos no son
obligatorios pero al menos uno de ellos sí se debe especificar. Tanto la imagen
como el logo se deben buscar dentro del equipo.
•
Texto del anuncio: texto que aparecerá en el anuncio. Este campo es obligatorio.
•
Link para más información: lo recomendable es que el texto tenga un link hacia
la página web del anunciante. En este campo se debe indicar dicha página web.
Es importante que la página empiece por http://.
•
Color de fondo: es el color de fondo que tendrá la publicidad. Destacar que si el
color de fondo no es blanco, sería recomendable que las imágenes tuvieran
fondo transparente y no blanco para obtener un mejor resultado.
165
Anexos
•
Efectos: para crear los contenidos publicitarios se han elaborado tres tipos de
efectos que difieren en la distribución de imagen, logo, texto y en las
animaciones de cada uno de ellos. Para poder distinguir un efecto de otro la
mejor opción es ver el resultado que se obtiene con cada uno de ellos pulsando
el botón Previsualizar Resultado (siempre que ya se hayan rellenado los campos
anteriores).
A continuación se muestran ejemplo de las diferentes animaciones:
Efecto 1
166
Anexos
Efecto 2
Efecto 3
167
Anexos
También se pueden modificar atributos del texto, del logo y de la imagen. En
todos los casos se puede modificar el desplazamiento tanto horizontal como vertical y
en el caso concreto del texto también se puede modificar su color.
Cuando se selecciona un efecto, el texto, el logo y la imagen están centrados
cada uno en la posición (0,0) respecto a sí mismos. Si se desea desplazar el elemento
hacia la derecha hay que incrementar su desplazamiento horizontal y si se desea
desplazar hacia la izquierda hay que decrementarlo; si se desea desplazar el elemento
hacia abajo hay que incrementar su desplazamiento vertical y si se desea desplazar hacia
arriba hay que decrementarlo.
Cuando se realizan modificaciones en los atributos de la publicidad, para poder
ver los resultados en el visor SVG es necesario pulsar el botón Previsualizar resultado.
Otra opción es activar la opción Auto Preview. Con dicha opción activada cualquier
cambio realizado se podrá visualizar de forma automática en el visor SVG.
Como se comentó en el apartado anterior, el visor tiene la opción de seguir los
enlaces. En el caso de la publicidad, el texto del anuncio tiene un enlace a la página web
del anunciante. Si se selecciona la opción Link del cuadro de herramientas del visor y se
hace click sobre el texto en el visor, se lanza un navegador a la página del anunciante y
se indica en la aplicación que "Para más información consultar en el navegador":
168
Anexos
Una vez visualizado el resultado y retocado según se considere más adecuado es
necesario seleccionar la ruta y el nombre del fichero XML que almacenará esta
información (Nota: el fichero XML se debe entregar al proveedor de servicios junto con
las imágenes correspondientes a la imagen y al logo, por lo que se recomienda que estén
en la misma carpeta todos estos ficheros).
Para terminar de generar el fichero XML es necesario pulsar sobre el botón
Generar fichero XML.
Por último, es posible visualizar el XML que se acaba de generar a través del
botón Ver XML generado.
8.1.1.5 Contenidos de votación/quiz
El formulario que se presenta para crear una plantilla XML de contenido de
votación o quiz es el siguiente:
169
Anexos
Los campos a rellenar son los siguientes:
•
Elección de votación o quiz. Un contenido de votación sería por ejemplo
"¿Quién quieres que salga de la casa de Gran Hermano?", mientras que un
contenido de quiz sería por ejemplo "¿Quién ganó el premio Nobel de medicina
en 1985?".
•
Nombre de la votación o quiz: nombre que se le quiere asignar a la votación. Por
ejemplo, Quiz capital de Francia. Este campo es obligatorio.
•
Ruta de la imagen: la votación puede tener de fondo una imagen aunque no es
obligatorio. La imagen se debe buscar dentro del equipo.
•
Número de respuestas: es el número de respuestas a la pregunta planteada que se
le ofrecen al usuario. Como mínimo han de ser dos y como máximo cuatro.
•
Color de fondo: es el color de fondo que tendrá la votación.
•
Efectos: para crear los contenidos de votación/quiz se han elaborado tres tipos de
efectos que difieren en las animaciones del texto de la pregunta y de las
respuestas. Para poder distinguir un efecto de otro la mejor opción es ver el
170
Anexos
resultado que se obtiene con cada uno de ellos pulsando el botón Previsualizar
Resultado.
•
Mostrar si la respuesta ha sido correcta: esta opción sólo estará habilitada para
contenidos de tipo quiz. En el caso de que se seleccione esta opción, cuando el
usuario envíe su respuesta a la pregunta se le enviará una confirmación
indicándole si la respuesta elegida es la correcta. En el caso de que esta opción
no esté seleccionada tan sólo se le indicará al usuario que su votación se ha
registrado con éxito.
•
Mostrar estadísticas: esta opción sólo estará habilitada para contenidos de tipo
votación. Si esta opción está seleccionada, cuando el usuario envíe su votación
se le mostrarán las estadísticas de ese momento de las votaciones registradas de
todos los usuarios.
•
Texto de la pregunta: texto que se mostrará al usuario para formular la pregunta
de la votación o quiz. Este campo es obligatorio.
•
Texto de las respuestas: textos correspondientes a las diferentes respuestas que
se ofrezcan para la pregunta formulada. Se deben rellenar obligatoriamente
tantas respuestas como número de respuestas se hayan indicado. También es
obligatorio seleccionar alguna de las respuestas como verdadera.
Tanto los textos de las respuestas como el de la pregunta tienen atributos que se
pueden modificar: tamaño, color, desplazamiento horizontal y desplazamiento vertical.
Al igual que en los contenidos publicitarios, cuando se selecciona un efecto, los
diferentes textos están centrados cada uno en la posición (0,0) respecto a sí mismos. Si
se desea desplazar el elemento hacia la derecha hay que incrementar su desplazamiento
horizontal y si se desea desplazar hacia la izquierda hay que decrementarlo; si se desea
desplazar el elemento hacia abajo hay que incrementar su desplazamiento vertical y si
se desea desplazar hacia arriba hay que decrementarlo.
Cuando se realizan modificaciones en los atributos de la votación, para poder ver
los resultados en el visor SVG es necesario pulsar el botón Previsualizar resultado. Otra
opción es activar la opción Auto Preview. Con dicha opción activada cualquier cambio
realizado se podrá visualizar de forma automática en el visor SVG.
171
Anexos
A continuación se muestra un ejemplo de un contenido de tipo quiz:
Una vez visualizado el resultado y retocado según se considere más adecuado es
necesario seleccionar la ruta y el nombre del fichero XML que almacenará esta
información (Nota: el fichero XML se debe entregar al proveedor de servicios junto con
la imagen de fondo en el caso de que ésta se incluya, por lo que se recomienda que estén
en la misma carpeta todos estos ficheros).
Para terminar de generar el fichero XML es necesario pulsa sobre el botón
Generar fichero XML.
Por último, es posible visualizar el XML que se acaba de generar a través del
botón Ver XML generado.
172
Anexos
8.1.1.6 Carga de plantillas XML
La aplicación también permite crear plantillas XML que se hayan generado
anteriormente. Para ello es necesario abrir el fichero XML que se desee cargar desde
Archivo → Abrir fichero XML o mediante la opción del menú Abrir XML.
Una vez seleccionado el fichero la aplicación detectará automáticamente si se
trata de un fichero de publicidad o de votación y cargará el formulario correspondiente
con los datos extraídos del fichero XML.
Es importante destacar que el fichero XML sólo almacena los nombres de los
ficheros de las imágenes o del logo, no su ruta completa. Por este motivo, cuando se
cargan las imágenes o logos de un fichero XML ya creado se toma como ruta la misma
que tenga el fichero XML abierto. En el caso de que se quiera visualizar ese contenido
en el visor y la imagen no se encuentre en el mismo directorio que el fichero XML
cargado, la aplicación avisará de que la imagen/logo no se encuentra en la ruta indicada.
En ese caso se recomienda modificar la ruta del mismo eligiendo el fichero correcto en
su ruta correcta.
173
Anexos
8.1.2 MiCanal ICG
MiCanal Interactive Content Generator (MiCanal ICG) permite crear contenidos
interactivos en formato SVG a partir de las plantillas XML generadas con la aplicación
MiCanal ITG. También es posible crear nuevos contenidos tanto de publicidad como
de votación/quiz.
A través de esta aplicación se permiten crear contenidos interactivos de dos
tipos: contenidos publicitarios y contenidos de votaciones o quiz.
8.1.2.1 Instalación de la aplicación
Adjunto a esta documentación se entrega un CD en el que se encuentra el fichero
que permite instalar esta aplicación. Dicho fichero es MiCanalICG.exe. El proceso de
instalación es similar al de la aplicación MiCanalITG.exe. Para más información
consultar el capítulo Manual del usuario apartado MiCanal ITG subcapítulo Instalación
de la aplicación.
8.1.2.2 Inicio de la aplicación
Cuando se inicia la aplicación presenta un aspecto similar al siguiente:
174
Anexos
La aplicación ofrece cuatro opciones posibles:
7. Abrir el visor SVG Tiny para poder visualizar un contenido SVG
8. Crear una nuevo contenido publicitario
9. Crear una nuevo contenido de tipo votaciones/quiz
10. Cargar una plantilla XML ya creada por la aplicación MiCanal ITG
Las opciones anteriores están disponibles desde las siguientes opciones de menú
o desde la barra de herramientas:
•
Visor SVG: Complementos → Abrir Visor SVG Tiny o desde el botón Abrir
visor SVG Tiny de la barra de herramientas
•
Contenido publicitario: Archivo → Nuevo → Publicidad o desde el botón Nueva
publicidad de la barra de herramientas
•
Contenido de votaciones/quiz: Archivo → Nuevo → Votación o desde el botón
Nueva votación de la barra de herramientas
175
Anexos
•
Abrir plantilla XML: Archivo → Abrir Fichero XML o desde el botón Abrir
XML de la barra de herramientas
8.1.2.3 Visor SVG Tiny
Esta aplicación también incluye un visor SVG para poder visualizar el resultado
de los contenidos interactivos finales. Además, este visor también permite cargar otros
contenidos SVG que estén almacenados en el equipo.
Si se abre el visor SVG Tiny después de arrancar la aplicación se mostrará una
pantalla similar a la siguiente:
176
Anexos
De esta forma sólo se puede utilizar el visor para abrir ficheros SVG que se
encuentren almacenados en el equipo. Para abrir un fichero SVG hay que pulsar el
botón Abrir fichero SVGT y seleccionar el fichero que se desee abrir (mismo
procedimiento que en la aplicación MiCanal ITG).
Existen varios botones que permiten interactuar con la imagen/animación
cargada en el visor. Dichos botones están situados en la caja de herramientas situada a la
izquierda del visor y son los siguientes:
•
aumentar/disminuir zoom: estos botones permiten aumentar y disminuir el zoom
de la imagen cargada en el visor.
•
pan: permite mover la imagen cargada en el visor de un lado a otro de la
pantalla. Para ello se hace click sobre el visor y sin soltar se arrastra el ratón
hasta la posición deseada, dejando de presionar el botón de ratón. Aparece una
línea vertical que indica hacia donde se va a mover la imagen.
•
link: este botón permite seguir los enlaces en el caso de que el documento SVG
contenga algún enlace, ya sea hacia una página web o hacia otro documento
177
Anexos
SVG. Esta opción es especialmente útil cuando se crea un contenido publicitario
puesto que el texto de la publicidad puede incluir un enlace a la página web del
anunciante.
•
Refrescar: este botón permite volver al estado original del documento SVG
cargado, es decir, sin zoom o sin desplazamiento.
•
Play/pause: permite pausar o la animación que se esté visualizando en el visor.
8.1.2.4 Carga de plantillas XML
La aplicación permite crear plantillas XML que se hayan generado con la
aplicación MiCanal ITG. Para ello es necesario abrir el fichero XML que se desee
cargar desde Archivo → Abrir fichero XML o mediante la opción del menú Abrir XML.
Una vez seleccionado el fichero la aplicación detectará automáticamente si se
trata de un fichero de publicidad o de votación y cargará el formulario correspondiente
con los datos extraídos del fichero XML.
Es importante destacar que el fichero XML sólo almacena los nombres de los
ficheros de las imágenes o del logo, no su ruta completa. Por este motivo, cuando se
cargan las imágenes o logos de un fichero XML ya creado se toma como ruta la misma
que tenga el fichero XML abierto. En el caso de que se quiera visualizar ese contenido
en el visor y la imagen no se encuentre en el mismo directorio que el fichero XML
cargado, la aplicación avisará de que la imagen/logo no se encuentra en la ruta indicada.
En ese caso se recomienda modificar la ruta del mismo eligiendo el fichero correcto en
su ruta correcta.
Una vez visualizado el resultado y retocado según se considere más adecuado es
necesario seleccionar la ruta y el nombre del fichero SVG que se creará con ese
contenido.
Para terminar de generar el fichero SVG es necesario pulsar sobre el botón
Generar fichero SVG.
178
Anexos
Por último, es posible visualizar el fichero SVG que se acaba de generar a través
del botón Ver SVG generado.
8.1.2.5 Contenidos publicitarios
El formulario que se presenta para crear un nuevo contenido publicitario es el
siguiente:
Los campos a rellenar son los mismos que en la creación de plantillas XML para
generar contenidos de publicidad en MiCanal ITG.
Una vez visualizado el contenido es necesario seleccionar la ruta y el nombre del
fichero SVG que se creará con ese contenido y, posteriormente, pulsar sobre el botón
Generar fichero SVG.
179
Anexos
8.1.2.6 Contenidos de votación/quiz
El formulario que se presenta para crear nuevos contenidos de votación/quiz es
el siguiente:
Los campos a rellenar son los mismos que en la creación de plantillas XML para
generar contenidos de votación/quiz en MiCanal ITG.
Una vez visualizado el contenido es necesario seleccionar la ruta y el nombre del
fichero SVG que se creará con ese contenido y, posteriormente, pulsar sobre el botón
Generar fichero SVG.
180
Anexos
8.2 Organismos
de
estandarización
relacionados
8.2.1 OMA
El foro Open Mobile Alliance (OMA) se formó en junio de 2002 con cerca de
200 compañías incluyendo operadoras, proveedores de dispositivos y redes, compañías
tecnológicas y proveedores de servicios y contenidos, constituyendo así una
organización para el desarrollo y publicación de especificaciones de aplicaciones para el
mundo móvil.
El objetivo de OMA es conseguir la interoperabilidad extremo a extremo de los
servicios que define entre los diferentes terminales, operadores, países, tecnologías
portadoras y sistemas operativos. Estos servicios móviles son definidos por OMA como
enablers o service enablers. Ejemplos de enabler son los servicios push, la gestión de
derechos digitales, la descarga de contenidos, intercambio de contenido seguro,
navegación, notificación de email, mensajería instantánea, etc.
OMA contempla dos tipos de interoperabilidad:
•
Interoperabilidad para enabler: Interoperabilidad extremo a extremo entre
diferentes productos que implementan el mismo enabler.
•
Interoperabilidad para servicios: Interoperabilidad extremo a extremo entre
diferentes productos que implementan diferentes enablers.
OMA está organizado en grupos de trabajo en los que se desarrolla una
determinada área tecnológica. Los grupos de trabajo de OMA más relacionados con el
presente proyecto son:
•
Browser Technologies (tecnologías de navegación): responsable de la
especificación de las tecnologías de aplicación usadas en la arquitectura móvil.
Dentro de este grupo existen otros subgrupos, siendo los más importantes los
siguientes:
181
Anexos
o Mobile Application Environment (MAE): se encarga de mejorar la
funcionalidad y la aplicabilidad de los entornos de aplicaciones de
navegación para el mundo móvil. Cuando la convergencia y la
interoperabilidad con Internet son una meta, los requisitos impuestos por
los dispositivos móviles presentan algunas restricciones únicas y a batir.
Es el responsable de las especificaciones heredadas del WAP Forum
(WML, WMLScript, etc.) así como la adaptación al entorno móvil de
tecnologías web existentes e incluso emergentes como pueden ser las de
Rich-media (Rich Media Environment - RME).
•
Broadcasting: se encarga de examinar las necesidades de los servicios broadcast
móvil y los entornos necesarios para su despliege. Incluye el descubrimiento del
servicio, guía de servicios electrónica (ESG) y protección de servicio.
•
Content distribution (distribución de contenido): especifica las formas de
distribución de información hacia el usuario sin su petición. En el modelo
tradicional de Internet el cliente solicita contenido del servidor web (servicio
pull) pero con el servicio push el servidor puede enviar contenido al cliente sin
la solicitud previa de éste. Para ello el usuario estará registrado previamente en
el servicio.
•
DRM (digital rights management): especifica protocolos a nivel de aplicación y
comportamientos que proporcionan una gestión transaccional y del ciclo de vida
del contenido y de las aplicaciones en los dispositivos móviles. Algunos
ejemplos son: entrega de contenido confirmada, protección de contenido
comercial y personal, distribución de contenido, soporte para el almacenamiento
y compartición de contenido y aplicaciones, etc.
8.2.1.1 OMA BROADCAST
Como se comentó anteriormente, Broadcasting es un grupo de trabajo dentro de
OMA que se encarga de definir un framework extremo a extremo para broadcast móvil.
182
Anexos
Este subgrupo de trabajo examina las necesidades de los servicios de broadcast y
los entornos necesarios para su despliegue. El término “Mobile Broadcast Services” se
refiere a una amplia gama de servicios de broadcast, que potencian la unión del
paradigma unidireccional del broadcast uno-a-muchos y el paradigma bidireccional
unicast de un entorno móvil. Entre las necesidades encontradas se identifican las
implicaciones sobre el aprovisionamiento del cliente y del servicio, las infraestructuras
de red, incluyendo las infraestructuras existentes, y los terminales.
Este grupo se encargará de la definición de un conjunto de enablers necesarios
para los servicios móviles de broadcast, incluyendo, entre otros, el descubrimiento del
servicio, guías electrónicas de programas o servicios (EPG/ESG), cobro (charging) y la
protección del contenido y servicios. Estos enablers serán independientes de la
portadora para ser útiles en infraestructuras diversas y heterogéneas.
OMA se centra únicamente en la construcción de servicios asegurando la
interoperabilidad entre componentes sin entrar en cuál debe ser la tecnología de
transporte, centrándose únicamente en la construcción de servicios. Uno de los
requisitos que impone indica que debe ser posible usar cualquier red que proporcione
Mobile Broadcast basado en IP (como IPDC sobre DVB-H, 3GPP MBMS, 3GPP2
BCMCS e ISDB-T principalmente).
La lista de servicios que cubre OMA BCAST es la siguiente:
•
Difusión de los flujos
•
Difusión de ficheros
•
Protección del servicio de difusión (comunicación/conexión los distintos
componentes/actores que lo integran)
•
Protección de los contenidos difundidos
•
Provisión del servicio (capacidad y gestión de las subscripciones)
•
Provisión del terminal (instalación, actualización y configuración de la
aplicación en el terminal)
183
Anexos
•
Descubrimiento del servicio y Guía del servicio
•
Notificaciones
•
Interactividad
Funciones y lista de protocolos de OMA BCAST
En la parte de la izquierda de la figura se muestran las funciones OMA BCAST
que hacen uso, interaccionan, mejoran y/o definen algunos de los protocolos
relacionados con OMA BCAST (los protocolos son los bloques rayados de la figura).
Estos protocolos pueden incluir protocolos 3GPP2 BCMCS o 3GPP MBMS.
El enabler OMA BCAST se construye sobre otros enablers de OMA,
fundamentalmente los de localización, Device Management y Digital Right
Management, y mejora a su vez a otros enablers ya existentes.
A continuación se muestra y explica la arquitectura así como las funciones más
importantes para el presente proyecto que son la guía de servicios, la interactividad y las
notificaciones.
184
Anexos
8.2.1.1.1 Arquitectura OMA BCAST
La siguiente figura representa la arquitectura de OMA BCAST:
Arquitectura OMA BCAST
Las entidades lógicas contempladas en esta arquitectura son:
•
Servidor de aplicaciones BCAST: Generador de los servicios BCAST como son
el streaming de audio y vídeo y la descarga de películas. Se encarga de realizar
la codificación, la protección de contenidos y la interacción relativa al servicio
BCAST.
•
Servidor de distribución / adaptación de BCAST: Se encarga de agregar y
entregar los servicios BCAST adaptándolos para su difusión por el BDS
(Broadcast Distribution System) específico. Es el encargado de ofrecer la
distribución de ficheros y streaming, la agregación de servicios, la protección de
servicios, generación y entrega de la ESG, entrega de notificaciones y
adaptación para con los sistemas de difusión subyacentes.
185
Anexos
•
Gestor de suscripciones BCAST: Se encarga de la provisión del servicio así
como de las funciones relacionadas de suscripción y pagos, provisión de
información necesaria para la recepción del servicio BCAST y gestión del
terminal. Entre las funcionalidades principales se encuentran la de notificación,
gestión de protección del servicio, gestión de protección de los contenidos,
soporte a la generación de la guía de programación, provisión del terminal e
interacción con los servicios de distribución para intercambiar información de
suscripciones con los terminales.
•
Terminales: Es el receptor de los contenidos y la información asociada al
servicio como la guía de servicios, información de protección del contenido etc.
Puede soportar un canal interactivo por el cual pueda comunicarse con la
plataforma si el servicio lo requiere.
8.2.1.1.2 Función de Interactividad
La función de interactividad proporciona comunicación punto a punto entre una
aplicación de servicio BCAST en la red y el terminal. La siguiente figura muestra los
componentes funcionales correspondientes a dicha función en la arquitectura de OMA
BCAST.
186
Anexos
Componentes de la función de interactividad
Content
Creation
BCAST Service Application
BCAST- 1
B roadcast S ervice Interaction
G eneric Functio n (B S II- G )
BCAST- 2
BCAST- 3
BCAST
Service
Distribution/
Adaptation
BCAST- 4
BCAST
Subscription
Management
BCAST- 8
Legend
BDSBDS-2*
BDSBDS-1*
BCAST LogicalEntities
Mandatory Non
-BCAST Entities
BCAST Functional Entities
BDS
Service Distribution
Optional Non
-BCAST Entities
X-1
Distribution
Broadcast
Distribution
System
System
BCAST Reference Points
BCAST-BDS Reference Points
S I-8
X-2
Interaction
Network
Other
OtherReference
ReferencePoints
Points
BCAST- 5
BCAST Functional Entity
Air Interface
BCAST-6
X-3
X-5
X-4
BCAST Interface
Terminal
Note: Interface over (*) reference points to be defined
in Adaptation Specification
X-6
BCAST- 7
B roadcast S ervice Interaction
C lient Function (B SI- C )
Cuando se requieren interacciones con el usuario se dispone del Service
Interaction Function que es soportado por la Interaction Network, que puede ser, la red
móvil o un sistema de mensajería. Se soportan diferentes tipos de interacción como,
entrada de llamada, SMS, MMS, envío de screenshots, descargas, email, links a otros
sites (como Chat rooms, WWW, WAP, HTTP y portales del operador). Existen dos
componentes funcionales que entran en juego en estas interacciones usando el interfaz
SI-8 (BCAST-8) para la comunicación de peticiones/respuestas entre ambos y que son:
•
Broadcast Service Interaction Generic Function (BSI-G): Responsable de servir
el servicio suplementario, el cual requiere la interacción del usuario final. El
componente de Content Creation proporciona los contenidos interactivos e
información adicional para ser usada en la generación del servicio BCAST.
•
Broadcast Service Interaction Client Function (BSI-C): Se encarga de enviar las
peticiones del usuario y recibir las respuestas a/de la BSI-G. Al recibir las
respuestas de usuario, la BSI-C puede realizar alguna operación directa o
interactuar con una aplicación concreta.
187
Anexos
Existen diferentes tipos de interacción contemplados entre el usuario final y el
proveedor de servicios:
•
Recuperación interactiva de la guía de servicios (ESG). El terminal solicita y
recibe la guía de servicio o las partes que han cambiado de la guía de servicios
para un servicio concreto. Si el terminal tiene capacidades de interactividad
soportará la recuperación interactiva de fragmentos de la Guía de Servicios.
•
Recuperación interactiva de información adicional relacionada con fragmentos
de la Guía de Servicios. Algunos fragmentos de la ESG pueden usar el elemento
ExtensionURL para obtener más información del mismo. Luego si el terminal
tiene capacidad de interacción entenderá dicho elemento y será capaz de acceder
al contenido adicional usando HTTP.
•
Servicio Interactivo. Interacción asociada al servicio, por ejemplo, votaciones o
descarga de contenidos asociados. El punto de entrada es la información de
interactividad que esté en la ESG y el contenido interactivo es distribuido por un
canal asociado.
•
Entrega interactiva de servicios de broadcast. Entrega sobre el canal de
interactividad. Esto se puede realizar usando AlternativeAccessURL o
InteractiveTransmissonScheme dentro de la ESG.
A continuación se describe el funcionamiento de los servicios interactivos y la
retroalimentación según OMA:
•
OMA describe un mecanismo para permitir al usuario interactuar con el servicio
como pudiera ser el caso de una solicitud de descarga de un tono. El punto de
entrada principal para los servicios interactivos es el fragmento InteractivityData
dentro de la ESG. Este fragmento apunta a un documento de interactividad
denominado “interactivity media document” que contiene los objetos
interactivos necesarios.
•
Un documento InteractivityMedia indica mediante un trigger al terminal que
reproduzca el mensaje de “los objetos interactivos multimedia” sobre el Interfaz
Gráfico de Usuario o GUI. Tanto el documento InteractivityMedia como el
188
Anexos
conjunto de ficheros multimedia se entregan usando la funcionalidad de
distribución de ficheros de BCAST. OMA especifica que:
o El sistema puede entregar los documentos InteractivityMedia y ficheros
asociados sobre el sistema de distribución de archivos broadcast o
enviarlos por el canal interactivo.
o El terminal soportará la recepción de documentos InteractivityMedia
sobre el método broadcast de distribución de ficheros.
o Si el terminal soporta el canal interactivo, el terminal soportará la
recuperación de los documentos InteractivityMedia y los archivos
asociados por el canal de interactividad.
o El método de la entrega usado para la entrega del InteractivityData será
indicado dentro del fragmento de la guía del servicio (ESG).
•
Una vez que se haya recuperado totalmente con éxito el documento
InteractivityMedia el terminal reproducirá los objetos en el momento en el que
esa interactividad haya sido programada. Si varios documentos son válidos al
mismo tiempo y pertenecen al mismo grupo, es decir, tienen el mismo GroupID,
a la hora de la reproducción de los objetos en el terminal prevalecerá el que
tenga el GroupPosition más elevado.
•
Los objetos definidos en el InteractivityMedia podrán ser reproducidos sin la
interrupción de la recepción y representación del stream broadcast normal
(vídeo, audio).
•
Un documento InteractivityMedia está compuesto de múltiples grupos de
objetos de medios, y cada grupo de medios puede consistir en uno o varios
conjuntos de medios. Un conjunto de objetos de medios es un paquete de objetos
de medios relacionados que se muestran como unidad (por ejemplo una página
XHTML más una hoja de estilos externa más imágenes) e identificados
claramente como pertenecientes a una tecnología específica de interactividad
(SMS, plantilla MMS, XHTML…). En un momento dado sólo un objeto del
grupo de objeto de medios es mostrado por el terminal. La reproducción de los
mismos va en función de la prioridad relativa y de que el terminal los soporte,
189
Anexos
teniendo en cuenta que si ninguno de los conjuntos de objetos de medios es
soportado por el terminal, éste mostrará un texto alternativo.
•
Los objetos de medios de un conjunto de objetos de medios van empaquetados
en un archivo y su transporte va por separado del documento InteractivityMedia.
Existe
una
estructura
descrita
por
el
documento
InteractivityMedia
desemparejada que permite al terminal desechar, al comenzar la recepción del
paquete, los conjuntos de objetos de medios que no soporta y evitar así su
almacenamiento. Esta estructura está compuesta de :
o La tecnología de interactividad implicada
o El tipo de objetos de medios incluido
o La información de entrega del archivo necesaria para recuperar el
paquete de los objetos de medios.
•
En el documento InteractivityMedia se pueden definir 3 grupos de medios para
que el comportamiento de la interacción sea dependiente del tiempo:
o El primero define los medios para empezar la interacción, como pudiera
ser un listado de preguntas de una votación. Aquí existe un plan de
actualización que permite la representación del objeto de medios fijado
para la siguiente pregunta.
o El segundo contiene otro grupo de medios que son presentados al usuario
si éste responde a tiempo en función del On_Action_Pointer, en función
de si el usuario responde dentro de un tiempo predefinido por el
Input_Allowed_Time.
o Si el usuario tarda en responder o no lo hace se presenta el tercer grupo
de medios en función del On_Time_Out_Pointer.
•
En la especificación OMA se describe el formato del fichero InteractivityMedia.
Con la descripción de cada uno de sus campos, así como las plantillas que deben
utilizarse como respuesta a los servicios interactivos mediante SMS o MMS.
190
Anexos
8.2.1.1.3 Función de Notificaciones
Mediante la creación y el envío de un mensaje de notificación a un terminal o
grupo de terminales se informa de un evento próximo del servicio de broadcast como
puede ser el cambio de la guía del servicio, el aviso del comienzo del servicio preferido
de un usuario (o un grupo de usuarios), una promoción de un servicio específico de
broadcast, u otras notificaciones relacionadas con el servicio (goles de un partido).
Cosas a tener en cuenta a la hora de llevar a cabo la notificación:
•
Para la entrega eficiente de un mensaje de notificación sobre el canal de
broadcast o sobre el canal de interactividad, la función de notificación utiliza la
funcionalidad proporcionada por la distribución/adaptación del servicio de
broadcast.
•
Esta función puede remitir un mensaje de notificación al BDS (Broadcast
Distribution System) o a la red de interactividad para que el BDS o la red de
interactividad pueda enviar un mensaje de notificación por su método nativo.
Algunos tipos de notificaciones posibles son:
•
Mensajes de emergencia
•
Anuncios generales (acerca de problemas en el sistema, anuncios del operador
etc.)
•
Notificaciones acerca del servicio o de sus contenidos (cambios en la
programación, información específica del servicio, datos auxiliares asociados al
contenido etc.)
•
Información a la que el usuario se ha suscrito
•
Etc.
A continuación se muestra una figura con los componentes de la función de
notificación y su descripción:
191
Anexos
Componentes de la función de notificación
•
Notification Event Component. El componente del evento de la notificación
(NTE) en la red es responsable de reenviar el aviso del evento de notificación
desde el creador de contenidos al componente de la generación de la notificación
en el gestor de la suscripción de BCAST.
•
Notification Generation Component. El componente de la generación de la
notificación (NTG) en la red es responsable de la generación de un mensaje de
notificación cuando ocurre un evento de notificación. Cuando NTG genera una
notificación, coopera con otras funciones de BCAST.
•
Notification
Distribution/Adaptation
Component.
El
componente
de
adaptación/distribución de la notificación (NTDA) determina qué canal se utiliza
para la entrega del mensaje de notificación según la disponibilidad del canal y el
número de los terminales que recibirán el mensaje de notificación.
•
Notification Client Component. El componente cliente de la notificación (NTC)
en el terminal es responsable de recibir un mensaje de notificación sobre el canal
de broadcast o sobre el canal de interactividad.
192
Anexos
8.2.2 DVB
El Digital Video Broadcasting Project, iniciado en 1992 como iniciativa
europea, es un consorcio liderado por la industria de cerca de 270 empresas de
radiodifusión, fabricantes, operadores de red, desarrolladores de software, organismos
reguladores y otras, en unos 35 países orientado al desarrollo de estándares para el
despliegue global de televisión digital y servicios de datos. Servicios que hacen uso de
los estándares DVB están disponibles en cada continente con cerca de 120 millones de
receptores DVB desarrollados.
Las especificaciones de este consorcio se convierten en estándares por medio de
organizaciones como ETSI o CENELEC. Una vez aceptados, los estándares son
promocionados para su adopción y posterior uso por cualquier país del mundo y
responden a una necesidad específica del mercado de la difusión digital.
Ejemplos de estos estándares son:
•
DVB-T: para la difusión terrestre.
•
DVB-S: para la difusión por satélite.
•
DVB-C: para la difusión por cable.
•
DVB-H: para difusión hacia dispositivos móviles.
8.2.2.1 BROADCAST DVB-H
Las siglas de DVB-H se corresponden con Digital Video Broadcasting Handheld
y es una especificación desarrollada por el DVB para emisiones broadcast de TV digital
basada en el DVB-T para dispositivos móviles.
Este nuevo estándar surgió ya que la DVB-T, aún pudiendo funcionar en
movimiento, presentaba problemas con respecto a las características de los dispositivos
móviles:
193
Anexos
•
Batería reducida: DVB-T precisa de elevados consumos de batería para las
capacidades que podemos encontrar en los dispositivos móviles.
•
Una única antena de recepción: DVB-T no opera adecuadamente en estas
condiciones.
DVB-H introduce una serie de cambios técnicos con respecto a DVB-T para
adecuarse a las características de los dispositivos móviles:
•
Modo de funcionamiento con 4k subportadoras para aportar un compromiso
entre resistencia al Doppler (2k) y tolerancia a los multitrayectos (8k).
•
Mayor protección frente a errores con codificación adicional y mayor
profundidad de entrelazado.
•
Soporte a portadoras de 5MHz para su uso en otras bandas no asignadas a la
distribución de TV.
•
Soporte a la recepción discontinua o Time Slicing que permite un ahorro en el
consumo de las baterías y realizar traspasos.
•
Capacidad de multiplexación con DVB-T en una misma portadora y poder
operar en redes mono y multifrecuencia.
La característica principal y más importante de este estándar y que lo diferencia
del DVB-T es el concepto de “time-slicing”. La funcionalidad básica del “time-slicing”
es la de enviar los datos en ráfagas que son almacenadas en un buffer y posteriormente
reproducidas, por lo que el terminal sólo está encendido cuando los datos relevantes
están disponibles. Esto da lugar a un aumento de la vida de la batería. A parte, los datos
se envían con la tecnología IPDC que ofrece transmisiones rápidas y confiables. El
ancho de banda puede ser de hasta 22Mb/s para recepción fija. Los servicios IP se
pueden transmitir dentro de los multiplexores de DVB junto con los programas de
televisión digital.
La siguiente figura representa los principales componentes de un sistema de
transmisión-recepción DVB-H teniendo en cuenta que está enmarcado dentro de la
infraestructura existente para la provisión de servicios DVB-T:
194
Anexos
Dibujo conceptual del sistema DVB-H
8.2.2.2 IPCD & DVB-H
IP Datacast (IPDC) es un sistema extremo a extremo para la entrega de cualquier
tipo de contenidos digitales mediante el uso de mecanismos IP. Éste fue diseñado para
que millares de receptores dentro del área de cobertura del transmisor pudieran recibir
su señal y por tanto la recepción masiva de servicios de datos.
En este tipo de comunicación el contenido se difunde simultáneamente a
múltiples receptores al contrario de lo que ocurre en la comunicación tradicional de
Internet en la que el usuario debe solicitar lo que quiere. La idea es poder difundir todo
el contenido que es enviado por Internet, pero muchos servicios IP no están diseñados
para ser entregados de una manera unidireccional, como los que usan el protocolo TCP,
por lo que estos servicios no pueden ser difundidos o tendrían que ser tratados de una
manera diferente. Por el contrario existen muchos servicios basados en UDP que si
pueden usar esta tecnología.
Las principales contribuciones de IPDC sobre DVB-H, en cuya base
proporcionada se construye, son:
195
Anexos
•
La guía electrónica de servicios
•
La adquisición y protección de los servicios
•
Los protocolos de entrega de contenidos
•
Los codecs, perfiles de codificación y formatos de ficheros
•
Calidad de servicio
•
Movilidad e itinerancia
Torre de Protocolos IPDC
IPDC es una plataforma de convergencia de servicios entre el mundo móvil y el
de difusión ya que está comprendido por un lado por un camino unidireccional de
difusión basado en DVB y por el otro de un camino bidireccional móvil.
Un sistema IPDC incluirá todos aquellos elementos típicos de un escenario de
provisión de servicios DVB-H más todas aquellas plataformas mediante las cuales
puedan proporcionarse el resto de funcionalidades.
196
Anexos
Arquitectura IPDC
Los principales elementos funcionales que componen esta arquitectura son:
•
Terminal: Desde la red DVB-H se reciben las transmisiones IPDC, y la
interactividad con el sistema se da a través de la red móvil.
•
Subsistema de Gestión del Servicio: Recibe información desde el subsistema de
aprovisionamiento que agrega a la ESG y proporciona soporte en la protección
del servicio (derechos de acceso al servicio o contenido)
•
Subsistema de aprovisionamiento: Se encarga de agregar y entregar, vía
difusión, servicios y contenidos proporcionando interactividad, soporte en la
protección de contenidos (cifrado) así como la transcodificación de los formatos
de los contenidos.
•
Subsistema de Comercio: Se encarga de la coordinación de las transacciones
comerciales con el usuario final:
o Autentica al usuario
o Negocia el precio y la selección de los servicios
o Intermedia en los pagos
197
Anexos
o Entrega los derechos de acceso a servicios y contenidos, etc.
Estas funciones pueden recaer en una entidad externa al subsistema, como
pudiera ser la red móvil para temas de autenticación y un sistema DRM externo para los
derechos de acceso.
•
Encapsulador IP. Este subsistema se encarga de:
o Encapsular el trafico IP en los transport streams de DVB-H
o Realizar el Time Slicing
o Realizar el MPE-FEC.
8.2.3 MPEG
Las siglas vienen de Moving Picture Experts Group, cuya designación oficial es
ISO/IEC JTC1/SC29 WG11. MPEG es un grupo de trabajo encargado del desarrollo de
la familia de estándares para la representación de audio y video digital. Este grupo se
estableció como tal en 1988, creciendo desde entonces hasta incluir en torno a 350
miembros de distintas industrias (unas 200 compañías) y universidades de más de 20
países.
Este grupo de trabajo se reúne como mínimo tres veces al año y está formado
por un grupo de expertos cada uno de los cuales está debidamente acreditado, abarcando
aquellos dominios con interés en el vídeo, audio y multimedia digitales.
MPEG provee un mecanismo probado para que los resultados de la investigación
terminen desembocando en estándares finales que promuevan la innovación.
Desde su creación MPEG ha desarrollado una cartera de tecnologías que ha
creado una industria valorada en varios cientos de miles de dólares. MPEG ha
normalizado los siguientes formatos de compresión y normas auxiliares:
198
Anexos
•
MPEG-1: estándar inicial de compresión de audio y vídeo. Usado después como
la norma para CD de vídeo, incluye popular formato de compresión de audio
Capa 3 (MP3).
•
MPEG-2: normas para audio y vídeo para difusión de calidad de televisión.
Utilizado para servicios de TV por satélite como DirecTV (Cadena
estadounidense de televisión vía satélite de difusión directa), señales de
televisión digital por cable y (con ligeras modificaciones) para los discos de
vídeo DVD.
•
MPEG-3: diseñado originalmente para HDTV (Televisión de Alta Definición),
pero abandonado posteriormente en favor de MPEG-2.
•
MPEG-4: expande MPEG-1 para soportar "objetos" audio/vídeo, contenido 3D,
codificación de baja velocidad binaria y soporte para gestión de derechos
digitales (protección de copyright).
•
MPEG-7: sistema formal para la descripción de contenido multimedia.
•
MPEG-21: MPEG describe esta norma futura como un "marco multimedia".
Funcionamiento de MPEG:
•
El MPEG utiliza códecs (codificadores-descodificadores) de compresión con
bajas pérdidas de datos usando códecs de transformación.
•
En los códecs de transformación con bajas pérdidas, las muestras tomadas de
imagen y sonido son troceadas en pequeños segmentos, transformadas en
espacio-frecuencia y cuantificadas. Los valores cuantificados son luego
codificados entrópicamente.
•
Los sistemas de codificación de imágenes en movimiento, tal como MPEG-1,
MPEG-2 y MPEG-4, añaden un paso extra, donde el contenido de imagen se
predice, antes de la codificación, a partir de imágenes reconstruidas pasadas y se
codifican solamente las diferencias con estas imágenes reconstruidas y algún
extra necesario para llevar a cabo la predicción.
199
Anexos
•
MPEG solamente normaliza el formato del flujo binario y el descodificador. El
codificador no está normalizado en ningún sentido, pero hay implementaciones
de referencia para los miembros, que producen flujos binarios válidos.
Además, MPEG ha iniciado nuevas líneas de estandarización:
•
MPEG-A provee estándares específicos de aplicación mediante la integración de
múltiples tecnologías MPEG.
•
MPEG-B, MPEG-C y MPEG-D proveen estándares específicos de sistemas,
audio y video respectivamente.
•
MPEG-E o M3W es el último estándar en desarrollo que soportará la descarga y
ejecución de aplicaciones multimedia.
8.2.3.1 MPEG-7
Es evidente que el valor de la información depende en buena medida de lo
sencillo que sea encontrarla, recuperarla, acceder a ella y gestionarla. Los documentos
con contenidos multimedia han supuesto un gran problema a la hora de la indexación,
búsqueda y recuperación, por lo que se ha trabajado (y se sigue trabajando) en distintas
tecnologías que faciliten el tratamiento de documentos multimedia. Entre ellas cabe
destacar una tecnología desarrollada por el grupo MPEG y aprobada por la
Organización Internacional de Estandarización (ISO). Esta tecnología se ha denominado
MPEG-7, que proporciona una infraestructura para la descripción de contenidos por
palabras clave y por significado semántico (quién, qué, cuando, dónde) y estructural
(formas, colores, texturas, movimiento, sonidos).
El formato MPEG-7 se asocia de forma natural a los contenidos audiovisuales
comprimidos por los codificadores MPEG-1, MPEG-2 y MPEG-4, pero se ha diseñado
para que sea independiente del formato del contenido. De esta forma, este nuevo
estándar ayuda a las herramientas de indexación a crear grandes bases de material
audiovisual (imágenes fijas, gráficos, modelos tridimensionales, audio, discursos, vídeo)
200
Anexos
proporcionándoles descriptores basados en catálogo (por ejemplo, título, creador,
derechos), semántica (información sobre objetos y eventos que aparecen en el
documento) y estructural (por ejemplo el histograma de color) que estandarizan la forma
de describir el contenido audiovisual y hace mucho más sencillo buscar en estas bases
de datos materiales de forma manual o automáticamente.
8.2.3.2 Estructura del MPEG-7
MPEG-7 es al multimedia lo que PostScript es al papel. PostScript describe a un
programa de textos el formato que debe tener la página, y MPEG-7 hace lo mismo, pero
sobre el contenido audiovisual. El MPEG-7 se basa en el popular lenguaje de metadatos
XML en un intento de favorecer la interoperabilidad y la creación de aplicaciones.
Sin embargo, una descripción en XML puede ser muy voluminosa. Es un
problema para las aplicaciones en las que el espacio de almacenamiento o el ancho de
banda de transmisión son insuficientes (discos con capacidad limitada, transmisión por
módem, etcétera). Para estos casos se ha desarrollado el compresor BIM (Binary Format
for MPEG-7).
En un escenario tipo, una aplicación genera la descripción MPEG-7 del
contenido de, por ejemplo, un millón de películas; luego se pasa al formato XML, se
almacena en servidores con discos de gran capacidad y ya está listo para su uso. Si la
información de la descripción es demasiado grande para los servidores o si se tiene que
mandar en un canal de transmisión con poco ancho de banda, el XML se compacta en
un espacio hasta 100 veces menor con el codificador BIM. Al final del proceso se puede
decodificar otra vez en XML y ya se pueden utilizar esos datos. Además, el BIM es más
robusto que el XML frente a los errores de transmisión.
MPEG-7 incluye, además de la descripción de los contenidos, información sobre
el tipo de compresión utilizada (JPEG, en dibujos; MPEG-2, en imágenes), las
condiciones para acceder (derechos, precio), clasificación (adultos, por ejemplo),
enlaces a otros materiales relevantes (para acelerar la búsqueda) y el contexto (final de
los 200 metros femeninos de los Juegos Olímpicos de Verano de 2000).
201
Anexos
Este estándar define una librería multimedia de métodos y herramientas que se
describen a continuación:
•
Un conjunto de descriptores. Un descriptor (D) es una representación de una
característica definida de manera sintáctica y semántica.
•
Un conjunto de esquemas de descripción. Un esquema de descripción (DS)
especifica la estructura y semántica de las relaciones entre sus componentes, que
pueden ser descriptores (D) o esquemas de descripción (DS)
•
El Description Defininition Language (DLL). Un lenguaje que especifica
esquemas de descripción permitiendo la extensión y modificación de los
esquemas de descripción existentes. Como se deduce de lo comentado
anteriormente, se trata de un lenguaje basado en XML.
•
Formas de codificar descripciones. Una descripción codificada es interesante
para que se puedan cumplir importantes requisitos como eficiencia de
compresión, acceso aleatorio, etc.
La relación entre los elementos descritos con anterioridad se puede observar en
la siguiente figura:
Elementos del MPEG-7
202
Anexos
El primer paso de MPEG-7 consiste en un análisis del documento multimedia
para obtener sus características y las relaciones entre los elementos. Este análisis se
podría hacer a mano o mediante una herramienta informática. Para ello MPEG-7 define
una serie de descriptores estándares, que pueden ser ampliados. Algunos de ellos son:
estructuras básicas, descriptores de color, descriptores de texturas, descriptores de
forma, descriptores de timbre, descriptores de melodía, etc. Además, se pueden usar
herramientas de anotación para describir la semántica del documento. Todo ello será
“descrito” usando las herramientas que MPEG-7 dispone para ello, de tal modo que
cualquier aplicación pueda “entender” y usar la información obtenida. De este modo
seremos capaces de desarrollar potentes buscadores o clasificadores de documentos
multimedia.
8.2.4 MMA (Mobile Marketing Association)
La asociación de marketing móvil (MMA) es una organización resultante de la
unión de las iniciativas Wíreless Advertising Association (WAA) y Wireless Marketing
Association (WMA), que se encarga de estimular el crecimiento del marketing móvil y
sus tecnologías asociadas. Este grupo se creó hace dos años y pretende proteger los
derechos tanto de los consumidores como de los distintos players del mercado.
Es una organización global con representación en 14 países. Su sede está en
Montainview (California) pero tiene oficinas en el Reino Unido, Alemania, Francia y
España (esta última inaugurada el pasado mes de julio). Entre los miembros de MMA se
incluyen agencias, anunciantes, fabricantes de dispositivos móviles, carriers, operadores
(O2, Vodafone, Orange, T-Mobile, Virgen Mobile...) minoristas, proveedores de
software y proveedores de servicio y contenidos móviles, así como cualquier compañía
relacionada con el marketing a través de los dispositivos móviles. El número de
miembros es superior a 200 entre compañías y miembros individuales. En España,
compañías como Movilisto y la anterior Telefónica Publicidad e Información (ahora
parte de British Yellow Pages) forman parte de la organización.
203
Anexos
La MMA nació con el fin de liderar y potenciar el desarrollo del marketing
móvil apoyando a las empresas en la creación de nuevos servicios y productos con
acciones concretas de colaboración, promoción y desarrollo. Su función consiste en
ofrecer a empresas e instituciones servicios de valor añadido que permitan, no sólo
mejorar la utilización de sus recursos actuales y futuros, sino también abrirse a nuevas
oportunidades de negocio y nuevos proyectos.
8.2.4.1 Importancia del marketing móvil
Una investigación reciente dada a conocer por la Mobile Marketing Association
ha puesto de relieve los beneficios tangibles que reporta para las marcas la utilización
del canal móvil a la hora de dirigir campañas de comunicación y acciones de marketing
a sus consumidores.
Para llegar a estas conclusiones, el estudio, llevado a cabo por la compañía de
investigación InterQuest, ha analizado distintas campañas que han sido llevadas a la
práctica en distintos mercados europeos, entre ellos el británico, el alemán y el italiano.
Entre las conclusiones que se pueden extraer del estudio destacan las siguientes:
•
Las campañas de marketing móvil están consiguiendo entre un 71% y un 96%
de ratio de respuesta por parte de los consumidores a los que éstas se dirigen.
•
Cerca del 70% de quienes responden a este tipo de campañas se encuentran
predispuestos a recomendar a sus amigos y conocidos que reciban mensajes de
marketing a través de su terminal móvil.
•
El 43% piensan que las campañas que reciben vía SMS tienen un impacto
positivo sobre la marca publicitaria, mientras que en el polo opuesto se
encuentra un 7% que tienen una opinión negativa.
•
Por encima del 40% de los que responden tienen intención de seguir
respondiendo a la llamada del anunciante (dependiendo de la acción de que se
trate: visitando un web site, viendo una publicidad.). Por el contrario, menos de
204
Anexos
un 5% declara que el hecho de recibir una campaña hace que disminuya su deseo
por responder al mensaje del anunciante.
Este estudio también concluye que las campañas vía móvil que están
desarrolladas para conducir el comportamiento del usuario están basadas normalmente
en mensajes múltiples, lo cual permite una mayor interacción entre el consumidor y la
marca.
Los resultados también demuestran que los impactos positivos de las campañas
vía móvil se distribuyen gradualmente a lo largo del tiempo, incluso en una de las
campañas analizadas se generó un 76% de respuesta durante los 15 días posteriores a
que se llevara a cabo la campaña.
El estudio de la MMA se llevó a cabo sobre 6 campañas de distintas firmas de
marketing móvil, como 12snap, Flytxt y Mindmatics. El tamaño de las campañas
variaban desde los 10.000 hasta los 30.000 participantes y en general la audiencia a la
que se dirigía iba de los 16 a los 26 años.
8.2.4.2 Descripción
Para llevar a cabo su cometido el MMA realiza las siguientes actividades:
•
Proporcionar un foro de industria donde discutir, planificar y trabajar de forma
cooperativa para resolver los problemas de la industria.
•
Juntar la industria con grupos de trabajo globales y regionales que se centren en
las iniciativas de la misma.
•
Proporcionar representación para la industria de mercado móvil y asegurar que
se alcanzan las necesidades de la industria.
•
Compartir perspectivas en el mercado móvil entre Europa, Asia, América
Latina, África y Estados Unidos.
205
Anexos
•
Impulsar la interacción peer-to-peer a través de seminarios, conferencias y
eventos.
•
Desarrollar métricas para medir la entrega de publicidad y la respuesta del
consumidor.
•
Desarrollar estándares técnicos y creativos, abiertos y compatibles con el
marketing móvil.
•
Definir y publicar un código de marketing móvil para los miembros, junto con
unas pautas de buen uso sobre privacidad, gestión de campañas y medidas.
•
Comprobar el valor y efectividad del marketing móvil a los anunciantes,
agencias y consumidores.
•
Servir como factor clave defensor en nombre de la industria del marketing
móvil.
•
Trabajar con marcas y vendedores para desarrollar marketing móvil como parte
de su marketing núcleo y así asegurar que los mercados del marketing está
maximizados y los objetivos de la campaña se cumplen.
•
Representar y defender los intereses empresariales y profesionales de sus socios
ante organismos públicos y privados, tanto nacionales como de la Unión
Europea.
•
Participar en las tareas comunitarias de la vida política, económica y social, que
interesen a los fines propios de la MMA.
•
Fomentar la comunicación y cooperación con organizaciones similares en otros
países.
•
Constituirse como un “Observatorio del Marketing Móvil” que trabaja con la
información de interés relativa al marketing móvil: marco legal, análisis de
tendencias, estudios de mercado, avances tecnológicos, estándares de la
industria, regulaciones en el ámbito nacional e internacional, etc.
•
Difundir información, económica, técnica y profesional, para el desarrollo y
perfeccionamiento de la actividad de los miembros de la MMA.
206
Anexos
•
Coordinar la búsqueda de socios nacionales e internacionales con el fin de
desarrollar proyectos de investigación conjuntos.
•
Coordinar su propia participación y/o la de los miembros que la soliciten en
iniciativas relacionadas con la promoción y desarrollo del marketing móvil.
•
Organizar congresos, seminarios y actividades formativas relacionados con el
marketing móvil, así como llevar a cabo todo tipo de iniciativas que faciliten la
adaptación a los cambios y oportunidades comerciales en el mercado
relacionadas con el marketing móvil.
•
Promover y profundizar en el conocimiento de las consecuencias sociales y
económicas de la innovación tecnológica en el proceso de construcción de la
Sociedad de la Información y en particular en el ámbito del marketing móvil.
•
Solicitar ante cualquier instancia, y ejecutar en su caso, la realización de
cualquier programa o proyecto relativo al marketing móvil en cualquier país de
la Unión Europea.
•
Proyectar, preparar y ejecutar cuantas acciones o actividades sean necesarias
para conseguir una adecuada formación y puesta al día permanente de todos los
colectivos vinculados directa o indirectamente con el marketing móvil y
especialmente dentro de la Asociación.
8.2.4.3 Comités
El MMA ha creado una serie de comités para establecer una serie de pautas a
nivel nacional e internacional para el marketing móvil.
Cada comité ha desarrollado un conjunto de iniciativas orientadas a la acción
que ellos mismos lideran. Los comités de MMA ayudan a dirigir las necesidades
actuales y futuras de las compañías activas añadiendo el móvil a su marketing.
Los comités de MMA globales incluyen:
207
Anexos
•
Comité de alcance académico (AOC): este comité está compuesto de voluntarios
de las diferentes compañías miembros de MMA. El objetivo de este comité es
fomentar y ayudar a formular un entorno para poder compartir teorías,
conceptos, frameworks, métodos.
•
Comité de apoyo: es importante para asegurar que los objetivos se alcancen y
que además, las acciones se comuniquen apropiadamente a la política pública de
las organizaciones.
•
Comité de buenas prácticas: establece una librería de buenas prácticas con el fin
de compartir conocimientos y difundir experiencias entre los agentes de la
industria y mejorar la efectividad y rentabilidad de los programas de marketing
móvil y la experiencia de los suscriptores de servicios. Publicando buenas
prácticas, los vendedores pueden incrementar la tasa de éxito de sus programas
de marketing. Estas pautas y recomendaciones están orientadas a conseguir
campañas de marketing en el móvil efectivas y eficientes a través de SMS,
MMS, Web wireless y PDA. También se encarga de desarrollar políticas y guías
de referencia para proteger la privacidad de los suscriptores y prevenir la
proliferación de los mensajes no solicitados o spam.
•
Comité de comercio móvil: su objetivo principal es permitir experiencias de
usuario simples, consistentes y compatibles a través de todos los carriers.
También debe establecer un consorcio con los carriers para proporcionar un
comercio móvil con controles de alta calidad para todos los players
•
Comité de métricas: desarrolla un conjunto de pautas recomendadas para medir
la efectividad de los programas de marketing móvil. Inicialmente está centrado
en desarrollar un informe de métricas que establecerá una línea para futuras
iniciativas de investigación (métricas) de marketing móvil.
•
Comité de publicidad móvil: establece una librería de pautas de formatos y
políticas para los anuncios con contenido en dispositivos móviles. Estas pautas
servirán como framework para las operadoras, agencias y anunciantes para
adoptarlo como estándares aprobados en la industria dentro de las iniciativas de
marketing móvil. El objetivo de este comité el año 2005 fue desarrollar
estándares de formato y políticas para banners dentro de WAP.
208
Anexos
•
Comité de estrategias de marketing móvil y buenas prácticas: establece una
librería de buenas prácticas para compartir el conocimiento en la industria.
Publicando estas buenas prácticas, los vendedores pueden incrementar su índice
de éxito de sus programas de marketing.
•
Comité de promociones móviles: desarrollará un documento de pautas que
servirán para ayudar a vendedores promocionales qie intentan ampliar sus
programas promocionales al canal móvil.
•
Comité de búsqueda móvil: su función es desarrollar modelos de negocio
comunes, procedimientos operacionales e interfaces tecnológicos que permitan a
los operadores ofrecer a los usuarios una experiencia de búsqueda en el móvil.
•
Comité de televisión y video móvil: se centra en establecer estándares y buenas
prácticas para el video en el móvil. Este grupo dirigirá el desarrollo de los
estándares desde una perspectiva de modelo de negocio y tecnológica.
•
Comité de contenido de portal off: se centra en desarrollar un conjunto de
estándares comunes para estandarizar la experiencia del usuario en una
aplicación o plataforma incluyendo la compra y la descarga de contenido, la
estandarización en la comunicación en la cadena de valor del contenido. El
propósito de estas pautas es proporcionar una forma sencilla y común de
compartir y entregar el contenido a los usuarios.
•
Comité de privacidad: trabaja con operadores, anunciantes y agencias
•
Grupo de trabajo del código corto: trabaja para establecer recomendaciones
sobre la utilización del código corto, desde una perspectiva administrativa y
tecnológica.
•
Foro de estándares técnicos: ayuda a tender un puente entre los protocolos
técnicos y aquellos protocolos que puedan ayudar a soportar modelos de negocio
del marketing móvil.
•
Comités internacionales MMA.
209
Anexos
8.2.4.4 Código de conducta
Este código fija estándares obligatorios y pautas de buenas prácticas en relación
con la provisión y operación de los servicios de marketing móvil basados en la
interpretación de MMA de la legislación aplicable actual en el Reino Unido en esta
área. El código MMA podría ser actualizado en el caso de que se introdujesen cambios
en la legislación.
Todos los miembros de MMA del Reino Unido deben cumplir este código. Por
ejemplo, se aplicará en todos los operadores móviles del Reino Unido como Orange, O2
y Virgen Mobile, que pertenecen a MMA.
El código cubre los siguientes aspectos:
•
Pautas generales.
•
Cuestiones clave a tener en cuenta cuando se quiere lanzar una promoción de
marketing móvil.
•
Información especial que hay que incluir en comunicaciones de marketing
móvil.
•
Marketing móvil para niños.
•
Juegos, competiciones, promociones con premios y sorteos con premios.
•
Consideraciones actuales cuando se va a lanzar una campaña.
•
Requisitos especiales para el marketing móvil relacionados con tipos de
productos o servicios particulares.
•
Requisitos especiales cuando se utilizan números Premium.
•
Requisitos especiales cuando se utiliza la localización basada en el marketing
móvil.
•
Requisitos especiales si actualmente se venden productos o servicios a los
usuarios a través de mecanismos de marketing móvil.
210
Anexos
8.3 APIs utilizadas
8.3.1 TinyLine
TinyLine (http://www.tinyline.com/) es un proyecto iniciado por Andrew Giron
que comenzó en 2002, momento en el que se incluyó dentro de las especificaciones
W3C Mobile SVG.
TinyLine es un kit de desarrollo de software para aplicaciones que quieran
utilizar imágenes en formato SVG para diversos propósitos en dispositivos móviles que
admitan java. La idea es entregar a los desarrolladores un conjunto de módulos que
puedan utilizar de forma conjunta o individual para soportar soluciones SVG móviles.
TinyLine es una implementación de SVG Tiny y gráficos avanzados 2D para la
plataforma J2ME.
El toolkit SVG TinyLine (http://www.tinyline.com/svgt/index.html) es un
conjunto de aplicaciones SVG Tiny y un SDK para dispositivos J2ME. TinyLine tiene
dos características principales:
-
Es una implementación J2ME CLDC 1.0, por lo que su instalación es muy
sencilla.
-
Debido a la característica anterior, se puede utilizar en muchos dispositivos
como teléfonos móviles, dispositivos portátiles y portátiles
El SDK es válido para varios perfiles java: J2ME MIDP 2.0, J2ME Personal
Profile y J2SE.
Sus principales características y beneficios son los siguientes:
-
Implementación de SVG Tiny y gráficos 2D avanzados para la plataforma
J2ME.
-
Soporta fuentes SVG, elementos de texto e imagen, paths, animaciones y
eventos.
-
Soporta opacidad y gradientes.
-
Alto rendimiento y tamaño de código compacto entorno a los 100Kb.
211
Anexos
-
SDK Java CLDC 1.0 para SVG Tiny y gráficos 2D.
-
Visores para MIDP2.0 y Personal Profile.
-
Permite streams SVG en formato gzip y textuales.
-
Fácilmente integrables en aplicaciones J2ME.
-
Se integra en los sistemas operativos Windows CE, Linux embebido, PalmOS,
Symbian, J2ME.
-
Proporciona esquemas para codificar desde SVG 1.1 a SVG Tiny.
-
Es libre.
El parser de bajo nivel de TinyLine está basado en el de Batik.
Andrew Giron, creador de este proyecto, ha presentado en SVG Open algunos
artículos interesantes sobre SVGT:
http://www.svgopen.org/2003/papers/Incremental_SVG_mobility_and_update/
(SVG Open 2003)
http://www.svgopen.org/2004/papers/SVGTinyCartoonsOnJavaDevices/ (SVG
Open 2004)
En el primer artículo se describen las actualizaciones incrementales de escena en
SVGT, mientras que en el segundo se describe la forma de realizar dibujos que tengan
animaciones.
Actualmente TinyLine se encuentra en la versión 1.10.
8.3.1.1 Descripción
TinyLine tiene soporte para:
-
Gradientes
-
Opacidad
212
Anexos
-
Renderizado
-
Perfil de animaciones SMIL de 3GPP
-
Imágenes JPEG, GIF y PNG (elemento <image>)
-
Elemento switch
-
Animaciones: soporta el subconjunto de animaciones SMIL 2.0 Perfil Básico
definido en SVG Tiny
-
Link: se puede crear un link desde un contenido SVG a otros recursos Web a
través del elemento <a>
-
Eventos: el contenido puede ser interactivo utilizando los eventos SVG
-
Los elementos definidos en SVGT: <svg>, <title>, <desc>, <defs>, <use> y
<metadata>
-
No soporta CSS (lógico puesto que SVGT 1.1 no lo soporta)
-
Los comandos SVGT/SVGB, excepto el comando elliptical arc curve
-
Las formas básicas: rectángulos, círculos, elipses, líneas, polilíneas y polígonos
-
El elemento <text>
-
Fuente: soporta las fuentes con relieve utilizando el atributo “d” en el elemento
<glyph>
8.3.1.2 API TinyLine
La API de TinyLine consiste en tres paquetes:
-
com.tinyline.svg
-
com.tinyline.tiny2d
-
com.tinyline.util
Estos paquetes son portables para los perfiles java. Las clases que utiliza
TinyLine son las siguientes:
-
java.lang.Exception
-
java.io.InputStream
213
Anexos
-
java.lang.Object
-
java.lang.System
-
java.lang.Throwable
com.tinyline.svg
El paquete interesante para este proyecto es com.tinyline.svg. Este paquete
implementa SVG Tiny 1.1, además soporta gradientes y módulos de opacidad (SVGT
1.2). La mayoría de las clases son elementos SVGT, aunque no ocurre así en todos los
casos. Las clases e interfaces son las siguientes:
-
XMLParser: interfaz para analizar documentos XML
-
SVGParser: se utiliza para analizar el stream de entrada SVGT
-
SVG: define las constantes SVG Tiny (elementos, atributos y valores). En la
API
se
puede
acceder
a
la
lista
de
dichas
constantes
(http://www.tinyline.com/svgt/download/docs/index.html).
-
SVGAttr: implementa el analizador (parser) de atributos SVGT
-
SVGDocument: implementa el nodo padre en la jerarquía de objetos SVGNode
(puntero a la raíz del árbol del documento). Representa el documento SVG
completo y proporciona el primer acceso a los datos del documento. Es posible
establecer la fuente SVG por defecto que se va a utilizar en el documento.
-
SVGRaster: esta clase realiza el rasterizado (convierte los datos en una imagen)
del árbol de objetos SVGNode.
-
SMILTime: esta clase es un tipo de datos que representa el número de veces
dentro del gráfico de tiempo. Tiene un tipo, unos valores clave que describen el
tiempo y un valor boolean para indicar si los valores están sin resolver, por
ejemplo, cuando un valor de inicio o fin se refiere a un evento, podría no ser
posible calcular el valor del tiempo.
-
SCGAnimationElem: implementa los elementos de animación definidos en
SMIL y en las especificaciones del perfil del lenguaje 3GPP SMIL Los tipos de
eventos permitidos son: activateEvent, beginEvent, endEvent
-
SVGEllipseElem: implementa los elementos <circle> y <ellipse>. El elemento
circle define un círculo basado en un punto central y un radio. El elemento
214
Anexos
ellipse define una elipse que está alineada con el sistema de coordenadas del
usuario, y se basa en un punto central y dos radios.
-
SVGFontElement: implementa el elemento <font>. Este elemento define una
fuente SVG. Consiste en una colección de SVGGlyphElems con la información
necesaria para utilizar esos glyphs.
-
SVGFontFaceElem: implementa el elemento <font-face>. Se utiliza para
describir las características de una fuente SVG que está contenida dentro del
mismo documento.
-
SVGGlyphElem: implementa el elemento <glyph>. Este elemento define los
gráficos para un determinado glyph (figura simbólica que representa una
palabra, una letra, etc). Cada SVGGlyphElem consiste en un identificador y un
conjunto de instrucciones de dibujo para dibujar dicho glyph.
-
SVGGradientElem:
implementa
los
elementos
<linearGradient>
y
<radialGradient>. Estos elementos pertenecen a la versión SVG Tiny 1.2 y
consisten en transiciones de color continuas en un vector desde un color a otro.
-
SVGGroupElem: implementa el elemento contenedor, es decir, un elemento
que puede contener elementos gráficos u otros elementos contenedores. Serían
los elementos <g>, <defs>, <a> y <switch>
-
SVGImageElem: implementa el elemento <image>. El tipo de imagen
permitida es PNG, JPEG y GIF (al igual que SVGT 1.1 o 1.2).
-
SVGLineElem: implementa el elemento <line> (un segmento que comienza en
un punto y finaliza en otro).
-
SVGMPathElem: implementa el sub-elemento <mpath>.
-
SVGNode: implementa la clase base para todos los elementos del lenguaje
SVG. Todas las clases que se corresponden con elementos SVG derivan de esta
clase base.
-
SVGPathElem: implementa el elemento <path>. Representa el contorno de una
forma que se puede rellenar.
-
SVGPolygonElem: implementa los elementos <polyline> y <polygon>
-
SVGRect: implementa el tipo <rectangle>.
-
SVGRectElem: implementa el elemento <rect>
-
SVGSVGElem: implementa el elemento <svg>
215
Anexos
-
SVGSStopElem: implementa el elemento <stop> (SVG Tiny 1.2). El desnivel
de colores a utilizar en un gradiente se define a través de este elemento.
-
SVGTextElem: implementa el elemento <text>
-
SVGUnknownElem: representa las etiquetas SVG o XML desconocidas del
input stream, es decir, aquellas que TinyLine no sabe cómo renderizar o
interpretar. De esta forma el parseado e interpretación de un stream de entrada
SVG no requiere que sea 100% válido para SVGT.
-
SVGUseElem: implementa el elemento <use>. Este elemento referencia otro
elemento e indica que los contenidos gráficos de esos elementos están incluidos
en ese punto en el documento. No se pueden referenciar ficheros completos.
A continuación se muestra una tabla en la que se indica qué clases de TinyLine
implementan los elementos de SVG Tiny. También se añade una columna con la
versión de SVGT, ya que en algunos casos los elementos implementados pertenecen a
SVGT 1.2.
Relación entre los elementos SVG Tiny y las clases de TinyLine
Elemento SVG
Clase/Interfaz TinyLine
Versión SVG Tiny
a
SVGGroupElem
SVG Tiny 1.1
animate
SVGAnimationElem
SVG Tiny 1.1
animateColor
SVGAnimationElem
SVG Tiny 1.1
animateMotion
SVGAnimationElem
SVG Tiny 1.1
animateTransform
SVGAnimationElem
SVG Tiny 1.1
circle
SVGEllipseElem
SVG Tiny 1.1
defs
SVGGroupElem
SVG Tiny 1.1
desc
No tiene clase asociada
SVG Tiny 1.1
ellipse
SVGEllipseElem
SVG Tiny 1.1
font
SVGFontElem
SVG Tiny 1.2
font-face
SVGFontFaceElem
SVG Tiny 1.1
font-face-name
SVGFontFaceElem
SVG Tiny 1.1
216
Anexos
font-face-src
SVGFontFaceElem
SVG Tiny 1.1
foreignObject
No tiene clase asociada
SVG Tiny 1.1
g
SVGGroupElem
SVG Tiny 1.1
glyph
SVGGlyphElem
SVG Tiny 1.1
hkern
No tiene clase asociada
SVG Tiny 1.1
image
SVGImageElem
SVG Tiny 1.1
line
SVGLineElem
SVG Tiny 1.1
linearGradient
SVGGradientElem
SVG Tiny 1.2
metadata
No tiene clase asociada
SVG Tiny 1.1
missing-glyph
No tiene clase asociada
SVG Tiny 1.1
mpath
SVGMPathElem
SVG Tiny 1.1
path
SVGPathElem
SVG Tiny 1.1
polygon
SVGPolygonElem
SVG Tiny 1.1
polyline
SVGPolygonElem
SVG Tiny 1.1
radialGradient
SVGGradientElem
SVG Tiny 1.2
rect
SVGRectElem
SVG Tiny 1.1
set
SVGAnimationElem
SVG Tiny 1.1
stop
SVGStopElem
SVG Tiny 1.2
svg
SVGSVGElem
SVG Tiny 1.1
switch
SVGGroupElem
SVG Tiny 1.1
text
SVGTextElem
SVG Tiny 1.1
title
No tiene clase asociada
SVG Tiny 1.1
use
SVGUseElem
SVG Tiny 1.1
Aquellos elementos que no tengan una clase asociada se podrán parsear
igualmente, es decir, se podrán reconocer al igual que el resto de los elementos cuando
se analiza el documento SVG.
217
Anexos
Proceso de parseado y renderizado
Para poder realizar el renderizado de un documento SVG, en primer lugar se
necesita el stream de entrada SVG Tiny. Para parsear dicho fichero hay que hacer uso
de SVGParser,
Durante el proceso de parseado, SVGParser obtiene el árbol del SVGNode desde
el stream de entrada del fichero SVG Tiny. Será necesario crear un SVGDocument, a
través del que se podrá acceder a la raíz del árbol SVGNode.
SVGRaster convertirá los objetos SVGNode en gráficos y los dibujará en
objetos TinyPixelbuf
El interfaz SVGImageProducer obtendrá la notificación de que hay nuevos
píxeles del objeto TinyPixelbuf que hay que enviar a la pantalla física.
Parseado y renderizado en TinyLine
En la siguiente URL se pueden encontrar ejemplos del renderizado que realiza
TinyLine sobre los ficheros SVG Tiny:
218
Anexos
http://www.tinyline.com/svgt/download/guide/index.html
com.tinyline.tiny2d
Esta API implementa un motor de gráficos 2D para móviles para la plataforma
J2ME (CLDC y CDC. Soporta las formas básicas, textos, imágenes, fuentes, paths, etc).
Se puede integrar en diversos perfiles de aplicaciones Java: CLDC/MIDP2.0,
CDC/Personal Java y J2SE.
Soporta el modelado de imágenes SVG Tiny, es decir, a la hora de representar
un fichero SVG Tiny con TinyLine sería necesario utilizar estas clases. Para realizar el
parseado del fichero se deberían utilizar las clases del paquete com.tinyline.svg pero
para poder mostrarlo gráficamente sería necesario hacer uso de las clases de este
paquete.
com.tinyline.util
Este paquete sólo contiene la clase GZIPInputStream que implementa un filtro
para los stream permitiendo leer datos que están comprimidos con el formato GZIP.
Esta
clase
es
una
implementación
J2ME
CLDC
del
estándar
java.util.zip.GZIPInputStream, que define un stream de entrada para leer datos
comprimidos en el formato GZIP.
Esta clase se puede utilizar tanto para SVG como para XML en J2ME, aunque
también se puede utilizar para realizar un procesado general XML. La idea es utilizar la
clase java.util.zip.GZIPOutputStream de J2SE en la parte del servidor para comprimir el
fichero SVG/XML y en el cliente utilizar GZIPInputStream para leer esos datos
comprimidos.
Se puede obtener un porcentaje de compresión de 50-70% en ficheros XML,
reduciendo el tráfico de red y el posible gasto de los usuarios.
El tamaño de com.tinyline.util.GZIPInputStream en el formato jar es de unos 6k.
219
Anexos
8.3.2 Batik
Batik es una API para Java que permite trabajar con imágenes en formato SVG
con diferentes propósitos: ver, generar y editar. Ha sido desarrollada por los miembros
del Apache XML Group.
Batik es un conjunto de herramientas desarrolladas en java y diseñadas para
aplicaciones o applets que quieran utilizar imágenes en formato SVG para diferentes
propósitos como mostrar dichas imágenes, generarlas o manipularlas.
El objetivo de este proyecto es dar a los desarrolladores un conjunto de módulos
que puedan utilizar de forma conjunta o individual para soportar soluciones específicas
SVG.
Con Batik se pueden manipular documentos SVG siempre que Java esté
disponible. Se permite generar, manipular y convertir a varios formatos imágenes SVG
en las aplicaciones o applets. Por ejemplo, utilizando el módulo SVG Generador una
aplicación java o applet puede fácilmente exportar gráficos al formato SVG; utilizando
el componente SVG viewing, una aplicación o applet puede integrar fácilmente un visor
SVG; utilizando los módulos de Batik se puede convertir SVG a varios formatos, por
ejemplo JPEG, PNG o TIFF u otros formatos como WMF o PDF.
El conjunto de herramientas de Batik incluye lo siguiente:
•
Módulos
o Implementación de SVG DOM
o Un conjunto de parsers SVG
o Un módulo de scripting
o Un generador que crea un documento SVG desde llamadas Java2D
o Un componente SVG de swing
o Un módulo para convertir a varios formatos
•
Herramientas y aplicaciones
220
Anexos
o Navegador SVG Squiggle
o Rasterizador SVG
o Conversor de TTF a SVG
o Impresora para ficheros SVG
Utilidades de Batik
La última versión de Batik, release 1.7, cumple con la implementación estática
de SVG y soporta interactividad, linking y scripting
221
Anexos
8.3.2.1 Módulos y herramientas
A continuación se explican brevemente los módulos y herramientas de los que
dispone Batik expuestos anteriormente:
8.3.2.1.1 Implementación de SVG DOM
DOM (Document Object Model) es una API para los documentos XML. Define
la estructura lógica de los documentos y la forma en la que un documento es accedido y
manipulado.
La API DOM define un interfaz denominado DOMImplementation que
representa la implementación DOM. Proporciona el método para crear un documento.
Luego, el documento concreto representa un documento XML y además actúa como un
factory para varios objetos DOM como Element, Attr y Text.
En Batik, la implementación DOM está en el paquete org.apache.batik.dom.svg
y la clase se llama SVGDOMImplementation. Una vez que se tiene la instancia de
DOMImplementation ya se puede utilizar la API DOM.
8.3.2.1.2 Conjunto de parsers SVG
En el módulo parser, cada microsintaxis es soportada por un par de clases: un
parser y un handler. El parser es una clase que implementa el interfaz Parser, que tiene
métodos para parsear valores desde un Reader o desde un String. El handler es un
interfaz específico para la microsintaxis.
Las microsintaxis soportadas por el módulo parser son las siguientes: ángulos,
valores de reloj, identificadores de fragmento, longitudes, listas de longitudes, números,
listas de números, datos path, puntos, valores de ratio preservados y listas de
transformación.
222
Anexos
8.3.2.1.3 Módulo de scripting
Los documentos SVG procesados por Batik soportan scripting con ECMAScript
utilizando el intérprete ECMAScript de Mozilla, Rhino.
Hay dos lugares en los que un fichero SVG puede tener scripts:
1.
En el elemento script, donde se puede poner cualquier código, incluyendo
definiciones de funciones, para que sea ejecutado justo antes del evento
SVGLoad.
2.
Para responder a un usuario o a un evento de documento utilizando los
atributos en SVG elements.
8.3.2.1.4 Generador que crea un documento SVG desde llamadas
Java2D
En la plataforma java, todo el renderizado se produce a través de la clase
abstracta Graphics2D. SVGGraphics2D es una nueva implementación de dicho interfaz
que genera contenido SVG en lugar de dibujarlo a una pantalla o a una impresora.
SVGGraphics2D tiene las siguientes características:
-
Permite a las aplicaciones exportar sus gráficos en formato SVG.
-
No requiere modificaciones del código de gráficos para exportar SVG.
-
Ofrece al usuario la posibilidad de usar la API DOM para manipular el
documento generado.
223
Anexos
SVGGraphics2D
8.3.2.1.5 Componente SVG de swing
El objetivo de este módulo es proporcionar un componente Swing que se pueda
utilizar para mostrar documentos SVG. Con la clase JSVGCanvas, se puede mostrar
fácilmente un documento SVG (desde una URI o desde un árbol DOM) y permitir al
usuario
manipularlo, mediante rotaciones, zoom, pan, selección de texto e
hipervínculos.
Un componente JSVGCanvas es un componente Swing que sigue las mismas
reglas de diseño que cualquier otro componente.
Existen
cinco
tipos
de
listener
SVGDocumentLoaderListener,
SVGLoadEventDispatcherListener
para
este
componente:
GVTTreeBuilderListener,
y
GVTTreeRendererListener,
UpdateManagerListener.
8.3.2.1.6 Módulo para convertir a varios formatos
El objetivo de esta API (paquete org.apache.batik.transcoder) es proporcionar
una API genérica para convertir de un formato a otro una entrada en una salida.
224
Anexos
A través de esta API es posible convertir un documento SVG a un formato
JPEG, PNG o TIFF.
8.3.2.1.7 Navegador SVG Squiggle
Squiggle es el navegador SVG que está incluido en Batik. Es posible descargarse
esta aplicación y utilizarla.
Ejemplo de visualización de Squiggle de Batik
8.3.2.1.8 Rasterizador SVG
El rasterizador es una utilidad que está incluida en la distribución de Batik.
Permite convertir ficheros SVG a un formato raster. La herramienta puede convertir
ficheros individuales o conjuntos de ficheros. Los formatos proporcionados son JPEG,
PNG y TIFF. Además, también se admite PDF.
225
Anexos
8.3.2.1.9 Conversor de TTF a SVG
La aplicación TrueType Font to SVG (ttf2svg) permite convertir un rango de
caracteres desde una fuente TrueType a un formato de fuente SVG. Esto es útil si se
quieren utilizar definiciones de fuentes embebidas en ficheros SVG. De esta forma se
asegura que el documento SVG siempre tendrá el mismo aspecto en todas las
plataformas ya que no se utilizarán las fuentes del sistema, si no la definición de la
fuente incluida en el documento SVG.
8.3.2.1.10 Impresora para ficheros SVG
Esta utilidad permite dar formato a los ficheros SVG
226
Anexos
8.3.3 API ITG (Interactive Template Generator)
La API generada para las aplicaciones de este proyecto consta de varios
paquetes pero el más importante es el paquete clasesSVG. Consta de las siguientes
clases:
-
EscribirSVGPublicidad
-
EscribirSVGVotacion
-
EscribirXMLPublicidad
-
LeerSVG
-
LeerSVGPubli
-
LeerXML
Estas clases permiten leer las plantillas SVG, generar los documentos SVG a
partir de las plantillas con los datos introducidos por los usuarios, así como generar los
ficheros XML con los datos de los usuarios para generar posteriormente los contenidos
interactivos. A continuación se muestran detalladamente dichas clases pero sólo se
mostrará una de cada tipo, es decir, sólo una clase de tipo EscribirSVG y una de
LeerSVG debido a que tanto la lectura como la escritura de contenidos publicitarios y de
tipo votación son muy similares.
227
Anexos
8.3.3.1 Clase EscribirSVGPublicidad
228
Anexos
229
Anexos
8.3.3.2 Clase EscribirXMLVotacion
230
Anexos
8.3.3.3 Clase LeerSVGPubli
231
Anexos
8.3.3.4 Clase LeerXML
232
Anexos
233
Anexos
234
Anexos
8.4 Acrónimos
3G
3rd Generation
3GPP
3rd Generation Partnership Project
API
Application Programming Interface
BDS
Broadcast Distribution System
CBMS
Convergence Broadcast & Mobile Services
CDF
Compound Document Formats
CSS
Cascading Style Sheets
CHTML
Compact HTML
DOM
Document Object Model
DVB
Digital Video Broadcasting
DVB-H
Digital Video Broadcasting - Handheld
DVB-S
Digital Video Broadcasting via satellite
DVB-T
Digital Video Broadcasting Terrestrial
EPG
Electronic Program Guide
ESG
Electronic Service Guide
FLUTE
File Delivery over Unidirectional Transport
235
Anexos
GPRS
General Packet Radio Service
GSM
Global System Mobile
HTML
Hyper Text Markup Language
http
Hypertext Transfer Protocol
IETF
Internet Engineering Task Force
IP
Internet Protocol
IPDC
IP datacast
IPSEC
Internet Protocol security
IPTV
Internet Protocol Television
J2ME
Java2 Micro Edition
J2SE
Java2 Standard Edition
LASeR
Light Adaptation ScenE Representation
MBMS
Multimedia Broadcast Multicast Service
MBS
Mobile Broadcast Services
MMA
Mobile Marketing Association
MMS
Multimedia Messaging Service
MORE
Mobile Open Rich-media Environment
MPEG
Moving Picture Experts Group
236
Anexos
OMA
Open Mobile Alliance
RME
Rich Media Environment
REX
Remote Events for XML
RSS
Really Simple Syndication
RTP
Real-Time Transport Protocol
RTSP
Real Time Streaming Protocol
SAF
Simple Aggregation Format
SMIL
Synchronized Multimedia Integration Language
SVG
Scalable Vector Graphics
SVGT
Scalable Vector Graphics Tiny
TCP
Transmission Control Protocol
TDT
Televisión Digital Terrestre
UDOM
microDOM
UDP
User Datagram Protocol
URL
Uniform Resource Locator
W3C
World Wide Web Consortium
WAP
Wireless Application Protocol
WICD
Web Integration Compound Document
237
Anexos
WML
Wireless Markup Language
XHTML
eXtensible Hyper Text Markup Language
XML
eXtensible Markup Language
238
Descargar