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:[email protected]"/> </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&#xe9;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&#xed;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&#xed;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&#xe1;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&#xe1;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="&amp;" 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="&apos;" 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="&#xc3;" 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="&#xd1;" 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 &#xc3; hace referencia a la Á y &#xd1; 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
