La API MHP

1. La API MHP Amaia Urtasun Garraza Leire Urriza Oiz

2. Definición de la API MHP

3. 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 E.T.S de Ingenieros de Telecomunicacion

4. 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 E.T.S de Ingenieros de Telecomunicacion

5. 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. “subAPIs” • Control de los “mandos” del decodificador pero no éste directamente • Control del tunner • Recibir datos del carrousel • Acceso al canal interactivo E.T.S de Ingenieros de Telecomunicacion

6. Clasificación de las APIs

7. 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 E.T.S de Ingenieros de Telecomunicacion

8. 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 E.T.S de Ingenieros de Telecomunicacion

9. 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 E.T.S de Ingenieros de Telecomunicacion

10. 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. E.T.S de Ingenieros de Telecomunicacion

11. 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 E.T.S de Ingenieros de Telecomunicacion

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

13. 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. E.T.S de Ingenieros de Telecomunicacion

14. 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 codepara eventos del mando a distancia. • Estos últimos son únicos disponibles en cualquier receptor E.T.S de Ingenieros de Telecomunicacion

15. 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 • Dar contexto de ejecución a las aplicaciones • Tarea imprescindible  API obligada Ciclo de vida de una aplicación E.T.S de Ingenieros de Telecomunicacion

16. 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. E.T.S de Ingenieros de Telecomunicacion

17. 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. E.T.S de Ingenieros de Telecomunicacion

18. 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. E.T.S de Ingenieros de Telecomunicacion

19. 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. E.T.S de Ingenieros de Telecomunicacion

20. 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, 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. E.T.S de Ingenieros de Telecomunicacion

21. 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. E.T.S de Ingenieros de Telecomunicacion

22. 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 Video Layer Graphics Layer E.T.S de Ingenieros de Telecomunicacion

23. 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 E.T.S de Ingenieros de Telecomunicacion

24. 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  800x600 • Resolución para TV con formato 4:3  720x625 • 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 E.T.S de Ingenieros de Telecomunicacion

25. 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. E.T.S de Ingenieros de Telecomunicacion

26. 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 • JavaTV 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 E.T.S de Ingenieros de Telecomunicacion

27. 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 E.T.S de Ingenieros de Telecomunicacion

28. 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) E.T.S de Ingenieros de Telecomunicacion

29. 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 E.T.S de Ingenieros de Telecomunicacion

30. Stream Event (broadcast) Stream Event (carousel) NPT(referencia temporal) Identificador Identificador 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 E.T.S de Ingenieros de Telecomunicacion

31. 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 E.T.S de Ingenieros de Telecomunicacion

32. 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. E.T.S de Ingenieros de Telecomunicacion

33. 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. E.T.S de Ingenieros de Telecomunicacion

34. 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 E.T.S de Ingenieros de Telecomunicacion

35. 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) E.T.S de Ingenieros de Telecomunicacion

36. 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. E.T.S de Ingenieros de Telecomunicacion

37. 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 E.T.S de Ingenieros de Telecomunicacion