Sincronización. 1.Información de servicios 2.Acceso a la Tabla TDT 3.Sincronismo 4.MHPRelojDigital.

Presentación del tema: "Sincronización. 1.Información de servicios 2.Acceso a la Tabla TDT 3.Sincronismo 4.MHPRelojDigital."— Transcripción de la presentación:

1 Sincronización

2 1.Información de servicios 2.Acceso a la Tabla TDT 3.Sincronismo 4.MHPRelojDigital

3 Las aplicaciones deben ser señalizadas antes de transmitirlas en una trama de transporte para: –Indicar al receptor de la presencia de dicha aplicación –Indicar al receptor el contenido y/o localización de dicha aplicación –Eventualmente mandar señales desde el broadcaster a la aplicación Introducción

4 La Información de Servicios (SI) contiene metadatos para poder localizar, sintonizar y mostrar dichos servicios Esta información viene bien estructurada y repartida en tablas de Información, las cuales contienen Descriptores (Unidad más pequeña de datos de SI) Introducción

5 La Información de Servicios (SI) contiene metadatos para poder localizar, sintonizar y mostrar dichos servicios Esta información viene bien estructurada y repartida en tablas de Información, las cuales contienen Descriptores (Unidad más pequeña de datos de SI) Introducción

6 Tablas de información comunes: –Program Allocation Table (PAT) –Program Mapping Table (PMT) –Condicional Access Table (CAT) –Bouquet Associantion Table (BAT) –Service Description Table (SDT) –Network Information Table (NIT) –Event Information Table (EIT) –Time and Date Table (TDT) –Time Offset Table (TOT) Tablas de Información

7 Existen ciertas tablas independientes de la trama de transporte sitonizada –Time and Date Table (TDT) –Time and Offset Table (TOT) –Network Information Table (NIT) Dentro de una misma Red de Emisión –Bouquet Information Table (BAT) (*) Dentro de un mismo bouquet de servicios Tablas de Información

8

9 El acceso a Tablas de Información se realiza asíncronamente porque: –La información no es accesible inmediatamente –No debemos bloquear una aplicación –Podemos recibir distintos tipos de información Introducción

10 Podemos acceder a las tablas de información a través de 2 paquetes –org.dvb.si –javax.tv.service javax.tv.service nos da un grado mayor de abstracción org.dvb.si nos da una granularidad mayor Introducción

11 Tabla comparativa entre JavaTv y Dvb.Si para acceso a tablas de Información

12 Dvb.SI : –El modelo dvb.si mapea claramente la estructura de DVB-SI –Mas cómodo cuando se manejan varias peticiones a la vez puesto que tenemos una mejor semántica en las respuestas –Sintonizar otras tramas de transporte sin para obtener sus SI sin salirnos del Servicio –Todas las peticiones que no sean a EIT deberían ser realizadas con dvb.si –Acceso directo a descriptores solo posible desde dvb.si Javax.tv –Fácil acceso a la tabla EIT, solución bastante adecuada para realizar EPG’s –Cambio de Servicio es solo posible desde javax.tv Casos de Uso de JavaTv y Dvb.SI

13 El procedimiento de acceso a TDT es válido para cualquier otra tabla en general y se divide en 6 pasos: 1.Recuperar una lista de Información (SIDatabase) de servicios (uno por cada interfaz de televisión) 2.Crear y realizar una petición (SIRequest) pasando como objeto la petición concreta (suele ser un String) 3.Cuando la información esté disponible la SIDatabase genera un SISuccessfulRetrieveEvent que nos informa de que la petición ha devuelto el objeto con la información exitosamente. Podemos ahora comprobar si es la información solicitada comprobando el objeto pasado 4.Una vez obtenido el objeto de respuesta podemos llamar a getResult() que nos devuelve un Iterador conteniendo los objeto (valores) de Información requeridos 5.Podemos ahora iterar por cada uno de estos objetos que implementan la interfaz SIInformation para hacer uso de ellos Acceso a la Tabla TDT

14 La información solicitada puede estar ya disponible en el propio terminal por eso se distinguen tres peticiones –FROM_CACHE_ONLY –FROM_STREAM_ONLY –FROM_CACHE_OR_STREAM En el caso del acceso a TDT siempre deberemos hacer FROM_STREAM_ONLY Acceso a la Tabla TDT

15 ¿Como nos podemos mantener actualizados en cuanto a Información de Servicio? –Podemos realizar una petición cada X tiempo –Se puede realizar una monitorización de tablas de Información Nos notifican mediante eventos si ha habido algún cambio en alguna tabla No tiene sentido hacer monitorización sobre algunas tablas de cambios continuos Monitorización de Tablas

16 Podríamos querer acceder a un descriptor privado o a la información de teletexto Dbv.Si nos ofrece el poder acceder directamente al descriptor de una tabla Acceso directo a descriptores

17

18 Se pretende ahora sincronizar una aplicación con la hora actual (local) donde reside el Set-Top Box Nos vienen a la cabeza varias alternativas: –Sincronizar el reloj haciendo uso de un servidor externo por el Return Channel –Sincronizar el reloj consultando con la hora del sistema (como se podría hacer en Desktop) –Sincronizar el reloj haciendo peticiones a las tablas de Información Introducción

19 Sincronizar el reloj haciendo uso de un servidor externo por el Return Channel –Sería una buena alternativa el poder sincronizar el reloj de nuestro terminal con la hora exacta a través de un servidor de reloj universal –El problema nos surge al por dar por hecho que todos los set-top boxes tienen implementado un canal de retorno y más aún hacer una petición tan corta y simple a través de modem Introducción

20 Sincronizar el reloj consultando con la hora del sistema (como se podría hacer en Desktop) –Este sistema es bastante usual en sistemas desktop donde la máquina lleva un reloj interno (gracias a la pila del BIOS) –El problema se nos presenta al dar por hecho que nuestro reloj del sistema ya está puesto en hora y permanece encendido siempre Introducción

21 Sincronizar el reloj haciendo peticiones a las tablas de Información –En vista de todos estos problemas MHP nos ofrece la sincronización del reloj haciendo uso de las tablas de información sin más que hacer peticiones reiterativas cada X tiempo Introducción

22

23 Se pretende realizar un reloj digital que esté sincronizado con la hora local del terminal El reloj debe ser reutilizable y autocontenido El reloj debe ser un componente MHP El reloj no debe bloquear la aplicación Introducción

24 En el desarrollo del MHPRelojDigital se han obtenido las siguientes resoluciones: –La hora y fecha del sistema es automáticamente sincronizado con las tablas de información al arrancar el terminal y configurado desde el Setup del mismo –El terminal sobrescribe el método getUTCTime() que nos devuelve la hora universal y hace una llamada a System.getCurrentMilles() que nos devuelve la hora actual del sistema en milisegundos –Por tanto es equivalente acceder a la hora y fecha mediante tablas de información que con la hora del sistema (siendo este último método mucho más rápido) Desarrollo

25 Problemas en cuanto a implementación –Se requería que el reloj fuese a su vez componente y no bloquease el programa Para solucionarlo debemos tener el reloj en un hilo aparte y a su vez que herede de HComponent. Implementación

26 ¿Como creamos un hilo? 1. Hacemos que la clase extienda de Thread e implemente el método run() –Creamos un objeto con MiReloj miReloj = new MiReloj(); 2. Hacemos que la clase implemente la interface Runnable y el método run() –Creamos un objeto con MiReloj miReloj = new MiReloj(); Thread Mihiloreloj = new Thread(miReloj); Implementación

27 En cualquiera de los dos casos, al final obtenemos un Thread el cual no podemos añadir como componente a ningún contendor –La primera solución visible pasa por tener un MiReloj que extienda de HComponent y que tenga un objeto Thread aparte como atributo que se encargue del proceso de repintado Perderíamos una de las premisas de que sea autocontenido, aparte que tendríamos que cambiar el paint() de un componente desde otro objeto (!!!) Implementación

28 La solución final pasa por tener un MiReloj que extienda de Hcomponent e implemente Runnable, y que a su vez contenga un atributo tipo Thread (hilo) que, al instanciar un MiReloj se añade a si mismo al hilo… ¿Comor? Implementación

29 public class MHPReloj extends KDBComponent implements Runnable, Serializable { private Thread hiloReloj; … public MHPReloj(int x, int y, int width, int height) { registerKeyListener(); setBounds(x, y, width, height); this.crearHilo();} … public void crearHilo() { hiloReloj = new java.lang.Thread(this,"MHPReloj"); hiloReloj.start();} Implementación Tenemos un atributo privado de tipo Thread (hiloReloj) En el constructor creamos un hilo y nos añadimos como objeto del hilo puesto que implementamos Runnable

30 Presentación

31 Ruegos y Preguntas Acceso a Tablas de Información (sincronización) [---------- Proyecto ----------] MHProject v2.0 www.mhproject.org E.T.S de Ingenieros de Telecomunicación Universidad Pública de Navarra www.mhproject.org [---------- Autor ----------] Alejandro Fanjul fanjul.35858@e.unavarra.es afanjul@mhproject.org fanjul.35858@e.unavarra.es afanjul@mhproject.org [---------- Tutor ----------] Mikel Sagues mikel.sagues@unavarra.es mikel.sagues@unavarra.es [---------- Bibliografía ----------] KDB Reference guide MHP-kdb.org Interactive Tv Standards Steven Morris 18/12/2006 Creative Commons 2.5: MHProject.orgMHProject.org C r é d i t o s y B i b l i o g r a f í a