Capacidades y funciones del terminal

Estas son las capacidades mínimas que el terminal debe ofrecer a las aplicaciones HbbTV. Se pueden añadir capacidades adicionales en el perfil de capacidades XML.

4.9.1

Capacidades mínimas

A diferencia de otras secciones del estándar, en este caso no se incorpora ninguna de las del OIPF DAE, son definidas directamente por el estándar HbbTV. Son las siguientes:

– Resolución del plano gráfico HbbTV: 1280x720 píxeles con una relación de aspecto de 16:9. El terminal deberá tener esta resolución como mínimo, si la resolución es mayor a las aplicaciones se les seguirá reportando como si fuese 1280x720.

– Formato de color: RGBA32 para resoluciones menores al menos debe soportar RGBA4444. Se permite la sobreimpresión de video (video overlay).

– Fuente proporcional, como mínimo la fuente “Tiresias Screefont v8.03” (o equivalente) con la codificación de caracteres Unicode “Basic Euro Latin Character Set” tal cual está definido en el anexo D del ETSI TS 102 809. Esta fuente debe poder ser accesible desde un CSS con la regla: font-family: Tiresias;

Como curiosidad, decir que la fuente Tiresias fue desarrollada por la BBC para ser usada con sus aplicaciones interactivas. Es una fuente especialmente diseñada para las pantallas de TV. Es una fuente sans-serif (sin ribetes), escalable y con anti-alias. Dos fuentes son “equivalentes” cuando tienen la misma altura, la misma anchura, tienen los mismos caracteres y son visualmente parecidas.

– Fuente no proporcional, “Letter Gothic 12 pitch” (o equivalente) en las mismas condiciones que la anterior y accesible por CSS con: font-family: “Letter gothic 12 Pitch”; Es una fuente mono espacio, escalable y con anti-alias.

– Método de entrada de texto: Debe incorporar el método multi-tap (tipo SMS de cuando los teléfonos solo tenían teclas) o tipo teclado software. En el caso del multi-tap o métodos equivalentes que usen eventos de teclado para introducir texto, los eventos no se pasarán a la aplicación, solo la cadena de texto final es la que se pasará a la aplicación. Desde el CSS se puede usar el método input-format para determinar cual de los métodos se va a usar.

– Número mínimo de filtros para DSM-CC: El terminal debe reservar recursos suficientes para registrar secciones DSM-CC para 3 flujos elementales (elementary streams) simultáneos, para un mismo carrusel DSM-CC. Y debe reservar al menos otro filtro para poder monitorizar los Stream Events de ese DSM-CC.

– Cache para el DSM-CC: Define que como mínimo ha de tener 3MB.

– Streaming unicast HTTP y descargas, formatos de archivo: se permitirán los formatos TS y mp4.

– Streaming unicast HTTP y descargas, formato de audio: HEAAC, AC3 y MP3.

– Gestión PVR: Si está implementada, el atributo manageRecordings deberá tener el valor “samedomain”

– Descargas: Si está implementada, el atributo manageDownload deberá tener el valor “samedomain”.

– No se requiere la presentación simultánea de contenido broadcast y broadband.

– Control Parental: Como mínimo ha de soportar la identificación de edad mínima, codificada según EN 300 468.

– Escalado de video: Los terminales deben poder escalar video en un factor de 0.125x0.125 y 0.25x0.25 . Para tamaños entre esos dos valores los terminales que no puedan escalar vídeo deberán recortarlo. Los terminales también deben poder escalar el video en un factor de 2x2. Además de esto, se podrá escalar video de forma arbitraria siempre y cuando se respete la relación de aspecto del video de tal forma que todo el video quepa en el área del objeto video/broadcast.

– Cookies: Las cookies que tengan fecha de expiración deberán almacenarse en la memoria persistente y los terminales deberán respetarla. Se soportarán al menos 100 cookies con un máximo de 20 por dominio y un tamaño individual hasta 4KB.

4.9.1.1

Acciones de usuario

El usuario debe poder manejar las aplicaciones con acciones de las teclas del mando a distancia. En la siguiente tabla se listan los tipos de evento de teclado mínimo que debe tener implementado cualquier terminal.

Botón Evento de teclado (key event)

Rojo, azul, verde, amarillo VK_RED, VK_GREEN, VK_BLUE, VK_YELLOW

Flechas arriba, abajo, dcha, izq. VK_UP, VK_DOWN, VK_RIGHT, VK_LEFT

ENTER / OK VK_ENTER

ATRÁS / BACK VK_BACK

Números (0 – 9) VK_0 → VK_9

Play, Stop, Pause VK_PLAY y VK_PAUSE o VK_PLAY_PAUSE, VK_STOP

Avence/Retroceso rápido VK_FAST_FWD, VK_REWIND

TEXT o TXT Este no se pasa a las aplicaciones, el terminal lanza la aplicación del teletexto directamente.

Las key events anteriores estarán disponibles para las aplicaciones cuando las pidan mediante un objeto KeySet. Las que no estén en la lista las tramitará la implementación del terminal y no se pasarán a la aplicación.

Tabla 4.6 – Eventos de teclado obligatorios en HbbTV. NOTA: Lo de VK viene del CEA2014, y significa Virtual Key.

Cuando se esté utilizando la navegación de teclas arriba, abajo, izquierda, derecha, el terminal decidirá cual de los siguientes mecanismos utilizar, ordenados por prioridad:

– Permitirá a las aplicaciones capturar los eventos evitando la llamada “navegación JavaScript”.

– Utilizar la navegación direccional del CSS3 nav-up, nav-right, nav-down y nav-left. – Usar la navegación del terminal que permite ir pasando por todos los elementos que

puedan tener foco, conocida como “navegación por foco”.

De todas formas las aplicaciones deberán marcar el bit NAVIGATION del objeto KeySet aunque las teclas de navegación se usen solo para hacer navegación por foco y no se usen para navegación javascript ni por CSS con nav-*.

4.9.2

Funciones del terminal

Favoritos

El terminal debería proporcionar un mecanismo para organizar las aplicaciones bc-independent más usadas. Cuando se dice debería, no implica obligación pero si que debe haber un motivo muy claro por el cual no hacerlo.

Para las aplicaciones los portales del fabricante o de listas de favoritos (www.hbbig.com, por ejemplo) el terminal puede usar el título, el icono que se especifica en la sección de encabezado HTML y la URL de la primera página.

Streaming y Descarga

Los terminales no permiten que se guarde el contenido streaming en una memoria persistente cuando ese contenido se ha iniciado usando el API de streaming (CEA 2014 AV Control Object). Si el proveedor de contenidos quiere que el contenido pueda ser almacenado, deberá iniciar la descarga utilizando el API de descargas.

Grabación (PVR)

Es el terminal el que decide si ejecutar las ordenes directamente o si permite que sea la aplicación quien pueda realizar acciones, como por ejemplo abrir un diálogo para pedir permiso al usuario para empezar la grabación.

4.9.3

Consulta de capacidades y cadenas opcionales

Es posible consultar al terminal la lista de capacidades que tiene implementadas. Es una forma de saber que funciones hace el terminal para poder adaptar los contenidos a sus capacidades. El intercambio se hace usando archivos XML codificados de tal forma que en un archivo se pasan los detalles de todo lo que el terminal puede poner a disposición de la aplicación.

Para el nivel de funciones básico se usará el siguiente XML como propiedad xmlCapabilities del objeto application/oipfCapabilities:

<profilelist>

<ui_profile name="OITF_HD_UIPROF+DVB_T+ " />

<video_profile name="TS_AVC_SD_25_HEAAC" type="video/mpeg" /> <video_profile name="TS_AVC_HD_25_HEAAC" type="video/mpeg" /> <video_profile name="MP4_AVC_SD_25_HEAAC" type="video/mp4" /> <video_profile name="MP4_AVC_HD_25_HEAAC" type="video/mp4" /> </profilelist>

DVB_T puede sustituirse por el sistema de radiodifusión utilizado, o se puede añadir más sistemas si el terminal así lo lleva incorporado.

Como se puede ver, los perfiles de A/V coinciden con los mencionados en el apartado de formatos para el canal broadband (punto 4.5.2.2). No se especifican los formatos del canal broadcast.

Si además el terminal soporta audio E-AC3 el XML sería ampliado con:

<profilelist>

<ui_profile name="OITF_HD_UIPROF+DVB_T+ " />

<video_profile name="TS_AVC_SD_25_HEAAC" type="video/mpeg" /> <video_profile name="TS_AVC_HD_25_HEAAC" type="video/mpeg" /> <video_profile name="MP4_AVC_SD_25_HEAAC" type="video/mp4" /> <video_profile name="MP4_AVC_HD_25_HEAAC" type="video/mp4" />

<video_profile name="TS_AVC_SD_25_E-AC3" type="video/mpeg" /> <video_profile name="TS_AVC_HD_25_E-AC3" type="video/mpeg" /> <video_profile name="MP4_AVC_SD_25_E-AC3" type="video/mp4" /> <video_profile name="MP4_AVC_HD_25_E-AC3" type="video/mp4" />

</profilelist>

En la siguiente tabla vemos cuales son las cadenas válidas para indicar cuales de las funciones opcionales están implementadas en el terminal:

Cadena opcional Significado

“+DL” Se permite la descarga de contenidos “+PVR” Se permite la grabación de contenidos

“+RTSP” Se permite el streaming RTSP

Las cadenas definidas en esta tabla se usarán de la siguiente forma: – En el encabezado User-Agent HTTP

– Como hemos visto arriba en el XML, como opción dentro del ui_profile name del objeto application/oipfCapabilities.

– Como parámetro del método hasCapability() del objeto

application/oipfCapabilities. Así es como se pregunta de forma dinámica si un terminal tiene una determinada característica implementada.

El soporte para DRM se indicará usando el elemento <drm>. Un ejemplo que indica que se soporta el DRM para el TS del canal broadcast:

<drm DRMSystemID="urn:dvb:casystemid:12345">TS</drm>

El soporte para CI+ se indicará usando también el elemento <drm> pero añadiendo el atributo protectionGateways con el valor “ci+”. Ejemplo que indica que se puede acceder al contenido protegido por DRM con un sistema Common Interface:

<drm DRMSystemID="urn:dvb:casystemid:12345" protectionGateways="ci+">TS</drm>

En HbbTV el soporte de CI+ se hace pensando en el canal broadcast, no en el broadband. Para el broadband está previsto usar DRMs.