Docstoc

Acceso a Informaci de servicios

Document Sample
Acceso a Informaci de servicios Powered By Docstoc
					Sincronización
1. Información de servicios
2. Acceso a la Tabla TDT
3. Sincronismo
4. MHPRelojDigital
                     Introducción


• 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


• 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


• 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)
              Tablas de Información


• 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


• 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
                Introducción


• 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


• 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
• Tabla
  comparativa
  entre JavaTv
  y Dvb.Si para
  acceso a
  tablas de
  Información
  Casos de Uso de JavaTv y Dvb.SI

• 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
                Acceso a la Tabla TDT

•    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


• 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
        Monitorización de Tablas


• ¿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
     Acceso directo a descriptores


• 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
                     Introducción


• 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


• 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


• 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


• 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


• 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
                          Desarrollo


• 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)
               Implementación


• 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


•   ¿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


•   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


• 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

public class MHPReloj extends KDBComponent               Tenemos un atributo privado
     implements Runnable, Serializable {
                                                          de tipo Thread (hiloReloj)
private Thread hiloReloj;

…

public MHPReloj(int x, int y, int width, int height) {
registerKeyListener(); setBounds(x, y, width, height);
this.crearHilo();}

…                                                        En el constructor creamos un
                                                          hilo y nos añadimos como
public void crearHilo() {                                  objeto del hilo puesto que
hiloReloj = new java.lang.Thread(this,"MHPReloj");        implementamos Runnable
hiloReloj.start();}
Presentación
                                                      Acceso a
                                               Tablas de Información



                     Créditos y Bibliografía
                                                  (sincronización)
Ruegos y Preguntas                             [---------- Proyecto ----------]
                                                        MHProject v2.0
                                                         www.mhproject.org

                                               E.T.S de Ingenieros de Telecomunicación
                                                Universidad Pública de Navarra

                                                 [---------- Autor ----------]
                                                     Alejandro Fanjul
                                                     fanjul.35858@e.unavarra.es
                                                        afanjul@mhproject.org

                                                 [---------- Tutor ----------]

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:9/20/2010
language:Spanish
pages:31