La API MHP Amaia Urtasun Garraza Leire Urriza

La API MHP Amaia Urtasun Garraza Leire Urriza Oiz 21/11/2005 E. T. S de Ingenieros de Telecomunicacion

Definición de la API MHP 21/11/2005 E. T. S de Ingenieros de Telecomunicacion

Definición de la API MHP (I) • Interfaz entre una aplicación y una característica, función o recurso del MHP • Toda la comunicación entre las aplicaciones y la plataforma MHP se hace a través de la API 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 3

Definición de la API MHP (II) • Por debajo de la API: • “System Software” gestión de recursos (escribir por pantalla, leer del mando a distancia…) • “Application Manager” encargado de cargar las aplicaciones y vigilar su ejecución 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 4

Definición de la API MHP (III) • La API actúa como frontera entre las aplicaciones y los elementos (HW y SW) del receptor • La aplicación tiene acceso a través de la API a los bloques que rodean la línea. “sub. APIs” • Control de los “mandos” del decodificador pero no éste directamente • Control del tunner • Recibir datos del carrousel • Acceso al canal interactivo 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 5

Clasificación de las APIs 21/11/2005 E. T. S de Ingenieros de Telecomunicacion

Clasificación de las APIs • La APIs pueden ser clasificadas en varias categorías: • • • Acceso de bajo nivel a MPEG Acceso a datos de broadcast Control de medios (“media control”) “playback” Gráficos e interfaces de usuario Comunicación con un servidor back-end u otras aplicaciones Acceso al HW del receptor o a periféricos como tarjetas inteligentes (“smart cards”) para accesos seguros • Seguridad 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 7

Clasificación de las APIs • No todas las aplicaciones usarán todas las APIs pero incluso las aplicaciones más simples usarán un amplio número de ellas 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 8

API para gestión de recursos (I) • Los receptores de TV tienen normalmente recursos escasos disponibles para la aplicación y estos recursos deben ser compartidos: • Entre las aplicaciones que se están ejecutando • Entre las aplicaciones y el middleware • La gestión de recursos es una cuestión a tener en cuenta en: • Características de los receptores • Diseño de aplicaciones 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 9

API para gestión de recursos (II) • Los recursos MHP típicos incluyen: • • • Procesador MPEG Dispositivos de entrada y salida CPU Memoria Sistema gráfico • Los recursos de MHP, accesibles desde una aplicación, pueden estar contenidos en una serie de entidades físicas conectadas al terminal MHP. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 10

API para gestión de recursos (III) • “entidad” cada una de las piezas independientes de hardware que forman parte de un cúmulo local (múltiple) de elementos que, como un todo, conforman una MHP. • Una “entidad” es, por ejemplo: • STB • Video Cassette Recorder (VCR) digital • Módulo de acceso condicional 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 11

API para gestión de recursos (IV) • Una entidad contiene una serie de recursos • Cada recurso provee cierta cantidad de funciones. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 12

API para eventos de entrada de usuarios (I) • La mayoría de los receptores MHP reciben entradas de usuario desde un control remoto. • Aunque la entrada desde teclado y ratón pueden estar disponibles, no se suelen usar porque no es la idea. Más cómodo con el mando a distancia. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 13

API para eventos de entrada de usuarios (II) • Los Key code para eventos del teclado están definidos por la plataforma Java y son distintos que los Key code para eventos del mando a distancia. • Estos últimos son únicos disponibles en cualquier receptor 21/11/2005 Key events that may be generated by an MHP receiver. Source: TS 101 812 v 1. 3. 1 (MHP 1. 0. 3 specification). Constant name Key code (if standardized) VK_UP up arrow not standardized VK_DOWN down arrow not standardized VK_LEFT left arrow not standardized VK_RIGHT right arrow not standardized VK_ENTER enter (also known as select or OK) not standardized number keys 48 - 57 VK_TELETEXT teletext key 459 VK_COLORED_KEY _0 first coloured key 403 VK_COLORED_KEY _1 second coloured key 404 VK_COLORED_KEY _2 third coloured key 405 VK_COLORED_KEY _3 fourth coloured key 406 VK_0 to VK_9 E. T. S de Ingenieros de Telecomunicacion 14

API para control de Xlets • Permite: • Controlar el ciclo de vida (“lifecycle” ) de las aplicaciones. – Permite que el gestor de aplicaciones (“Application manager”) actúe sobre el ciclo de vida cambiando su estado – Permite a la aplicación informar al gestor sobre sus cambios de estado así como solicitarlos Ciclo de vida de una aplicación • Dar contexto de ejecución a las aplicaciones • Tarea imprescindible API obligada 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 15

API para comunicación entre Xlets • Implementa la comunicación de una Xlet con otras Xlets que se están ejecutando en el sistema. • Permite que tengan funciones comunes y puedan implementarse de “modo client-server”, de forma que esto aumenta la eficiencia en algunos casos. • Presenta un problema a la hora de referenciar objetos en una Xlet que se encuentran en otra. El modelo de classloader en Java no nos lo permite MHP nos da un API que lo puede solucionar. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 16

API para presentación de texto (I) • Casi todas las aplicaciones necesitan mostrar algún tipo de texto en pantalla. • Pensar en cuestiones distintas que para PC • 3 principales problemas a la hora de mostrar textos grandes: • Dificultad de leer texto en TV debido a la baja resolución y contraste de la pantalla si implementamos como para PC. – Elegir tipo de fuente adecuado Tiresias – Elegir el tamaño de fuente adecuado El número máximo de líneas en la pantalla debe ser 18. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 17

API para presentación de texto (II) • Navegación – Si el texto es demasiado largo el usuario necesitará algún medio para moverse por el texto. – Scrollbar usado en PCs no es adecuado para TV. Es mejor usar saltos entre páginas • Cuidado con que el método para movernos por el texto no interfiera con el método para navegar por la aplicación. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 18

API para gráficos • Cuestiones a tener en cuenta: • Pixel Aspect Ratio: En aplicaciones de vídeo y TV los píxeles no son cuadrados y en los gráficos para PC si difícil adaptación • Video Aspect Ratio: Formato (4: 3) ó (16: 9) influye en el diseño de la aplicación. El efecto de los gráficos e imágenes es distinto en ambos casos. • Translucidez y transparencia • Espacio de colores: Mapear de RGB (usado por Java) a YUV (usado por la señal de TV) • Window Manager: No hay gestor de ventanas. Porque son demasiado complejos para los receptores MHP. Las aplicaciones necesitan otro medio para obtener un área de diseño. • Interfaz con el usuario: Diferentes interfaces de usuario. Si una aplicación está activa, puede que otra no pueda aparecer por pantalla uso de una nueva interfaz. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 19

API para vídeo y gráficos (I) • La mayoría de los receptores de DTV tienen limitadas sus capacidades cuando empiezan a soportar vídeos y gráficos. • Un STB no es un PC • En un PC, PC vídeo y gráficos están administrados por el SW y eso hace fácil el escalar y posicionar vídeos. Es fácil integrarlos en el sistema de ventanas y que coexistan fácilmente con gráficos tan largos como la rapidez de la CPU permita. • En un STB las cosas son diferentes. Un receptor MHP posee su propio: – Procesador de gráficos – Demultiplexor y decodificador MPEG – CPU integrados en el mismo chip. Este chip habitualmente tendrá capacidades gráficas que permiten el soporte de muchas tareas de propósito general. Sólo nos interesan aquellas tareas relacionadas con características que necesite el receptor de TV digital. Por eso, los STB tienen habitualmente subsistemas gráficos especializados que soportan varios planos gráficos, cada uno para un tarea específica. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 20

API para vídeo y gráficos (II) • Tipos de planos en los subsistemas gráficos y de vídeo: • Background plane muestra un color simple detrás de todos los demás planos gráficos • Still image plane capacidad de mostrar una imagen estática detrás del vídeo decodificado u otros gráficos • Video plane muestra el vídeo decodificado. Algunos procesadores pueden tener más de un plano de vídeo para soportar múltiples video streams o para soportar picture-in-picture • Graphics plane muestra los gráficos de la aplicación o los subtítulos • Cursor plane muestra el cursor HW • No todos los receptores tienen todos los planos y algunos tienen más. Los receptores modernos tienen entre 5 y 13 planos en total, dependiendo de las características y del coste. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 21

API para vídeo y gráficos (III) • Los receptores MHP agrupan los planos en 3 capas: • Background layer (una) para el color de fondo e imágenes estáticas también de fondo • Video layer (una o más) para mostrar vídeos decodificados • Graphics layer (una o más) para mostrar gráficos Background Layer Graphics Layer 21/11/2005 Video Layer E. T. S de Ingenieros de Telecomunicacion 22

API para vídeo y gráficos (IV) • El mapeo entre los “graphics planes” del HW y las “graphics layers” de MHP no está estrictamente definido y por eso, más de un “graphic plane” físico puede estar dentro de una “graphic layer” simple de MHP. • Recíprocamente, un sistema que usa software MPEG puede mapear un “graphic plane” físico tanto en la “graphic layer” como en la “video layer” en su implementación del middleware 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 23

API para vídeo y gráficos (V) • Limitaciones entre los distintos “graphics planes”: • Algunos “graphics hardware” soportan más colores y otros sólo un conjunto básico • La forma de los píxeles puede ser diferente: » » » Vídeo pixeles no son cuadrados Graphic pixeles son cuadrados Resolución para PC con formato 4: 3 800 x 600 Resolución para TV con formato 4: 3 720 x 625 Los gráficos pueden no estar perfectamente alineados con el vídeo mostrado. • El “video plane” impone sus propias limitaciones: • Algunos decodificadores MPEG tienen la limitación de que el vídeo sólo puede ser escalado a un determinado tamaño. Otros sólo pueden posicionarse en determinadas áreas 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 24

API para vídeo y gráficos (VI) • Otra limitación, los subtítulos. Algunos dispositivos: • Limitan el posicionamiento de éstos • Limitan los colores disponibles para ellos. • Reservan una cantidad de pantalla sólo para ellos y esta sección no puede ser utilizada para otros propósitos • La interacción entre los diferentes planos también impone limitaciones: • Cambiar la configuración de otro planos puede afectar al “graphics plane”. » Ejemplo: Aunque la especificación MHP permite que el “background plane” contenga tanto un color de fondo como una imagen estática, algunos “graphics hardware” limitan esto. En muchos casos el hardware decodificador MPEG es necesario para decodificar la imagen de background y mientras se está realizando esto, no se puede decodificar el vídeo. Esto causa la interrupción de la decodificación del vídeo. Unas veces esta interrupción dura hasta que se acaba de decodificar la imagen de background, mientras que otros hardware reservan el decodificador MPEG hasta que dicha imagen se muestre. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 25

APIs para el control de medios • Media control APIs • MHP tiene dos APIs para controlar la forma de mostrar señales de vídeo y elegir qué señales mostrar al usuario: • JMF (Java Media Framework) API para controlar media clips individuales • Java. TV service selection API permite a las aplicaciones cambiar de servicio. Es peligroso y puede que la aplicación no sobreviva? ? ? • Relacionada tangencialmente Tunning API proporciona un medio a la aplicación para acceder a otro transport stream 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 26

API para sonido • Los sonidos son comunes en las aplicaciones. • 2 medios para incluir el sonido en la aplicación: • Usando JMF API • A través de la clase org. havi. ui. Hsound proporciona una API simple para reproducir “audio playback” pero no ofrece tanto control de medios como JMF 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 27

API para sincronizar aplicaciones y media (I) • Puede ser necesario sincronizar el comportamiento de la aplicación con la acción en pantalla. Xej: subtítulos • No podemos usar “media time” como mecanismo de sincronización porque no existe una referencia temporal en la trama MPEG-2 • En vez de eso se usan los DSM-CC stream events, (marcas que viajan embebidas en secciones privadas del flujo MPEG-2) 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 28

API para sincronizar aplicaciones y media (II) • Cada marca consiste en: • Un identificador permite que cada stream event sea identificado unívocamente • Una referencia temporal (NPT≡Normal Play Time) indica en que punto del stream debe disparase el evento • Esta marca es introducida por el broadcaster 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 29

API para sincronizar aplicaciones y media (III) • El transport stream también contiene un Object Carousel que contiene un conjunto de streams events objects. • streams events objects identifica cada evento con un nombre textual y permite el mapeo de ese nombre al identificador contenido en el evento mismo Stream Event (broadcast) Stream Event (carousel) NPT(referencia temporal) Identificador 21/11/2005 Identificador E. T. S de Ingenieros de Telecomunicacion 30

API para sincronizar aplicaciones y media (IV) • Podemos recibir varios Stream Events en el broadcast stream que se correspondan con un mismo Stream Event en el Object Carousel 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 31

Java TV service selection API • Permite cambiar el vídeo que está siendo mostrado pero esto es sólo un efecto lateral de usar esta API. Por eso hay que ser muy cuidadosos a la hora de usar esta API porque puede provocar efectos dramáticos en nuestras aplicaciones • “Service selection” ≡ cambiar de canal. • En TV analógica mostrar diferentes audios y videos • En TV digital mostrar diferentes audios, vídeos y aplicaciones. El nuevo set de aplicaciones puede no incluir la aplicación actual la aplicación debe finalizar autodestruyéndose Nota: No es necesario cambiar de servicio para mostrar distintos audios, vídeos y aplicaciones. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 32

API para la información sobre servicio • Permite a la aplicación acceder a la mayoría de las tablas transportadas en el transport stream: • Servicios disponibles • Hora de inicio • Hora de final • A la tabla AIT no se puede acceder utilizando esta API por razones de seguridad y funcionalidad. Para acceder a ella se logra a través de la API para control de Xlets. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 33

API para filtrado de secciones MPEG-2 • Permite que las aplicaciones puedan acceder a las secciones privadas del flujo MPEG-2: • Acceso al carrusel • Acceso a información sobre servicios 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 34

API para el acceso a ficheros • Una aplicación no puede hacer gran cosa sin acceder al sistema de ficheros. • En MHP las aplicaciones sólo pueden acceder al sistema de archivos de broadcast en el que fueron transmitidas. • También pueden acceder a un sistema de archivos persistente usado para guardar la configuración y preferencias de usuario en el receptor MHP (Acceso a través de Persistent Storage API) 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 35

API para el canal de retorno (I) • Los perfiles “interactive broadcast” e “internet access” incluyen soporte para usar un canal de retorno en el receptor MHP para comunicarse con el mundo exterior. • Tipos de canales de retorno: • • • PSTN modem Cable modem ADSL GPRS … • MHP no se preocupa, lo único que se define en las especificaciones MHP es que la conexión debe soportar TCP/IP. 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 36

API para el canal de retorno (II) • La conexión soporta DNS pero no son necesarios otro protocolos como HTTP, SMTP o IMAP, que son implementados por la aplicación. • MHP usa el paquete java. net para conectar con el mundo exterior con algunas restricciones. • La diferencia entre usar el canal de retorno en MHP y usar la API java. net es que ésta última asume una conexión a internet permanente y esto no es aplicable a un receptor MHP conectado vía PSTN modem necesaria session management API, que se usa también para impedir que aplicaciones no deseadas por el usuario usen el canal de retorno sin permiso de éste 21/11/2005 E. T. S de Ingenieros de Telecomunicacion 37