Um dos pontos principais deste trabalho é a utilização do atual sistema de envio de dados contextualizados da programação pela emissora, através das tabelas de informações e eventos, para o também envio dos momentos ou pontos de sincronismo entre a programação transmitida e um conteúdo web complementar a ser exibido por um dispositivo de segunda tela.
Há diversas formas, cada uma com suas vantagens e desvantagens, para o envio das informações necessárias ao sincronismo, como por exemplo, via Pulling, Pushing ou por Single Signaling. Em uma abordagem via Pulling a aplicação no dispositivo de segunda tela seria responsável por sistematicamente verificar a disponibilidade de um novo conteúdo no servidor, uma vez que ele não saberia de antemão os momentos de sincronismo. Esta abordagem seria muito custosa em diversos aspectos, como largura de banda, escalabilidade constante de conexões no servidor e gasto de recursos de bateria no dispositivo de segunda tela.
Em uma abordagem via Pushing, o envio das informações seria feito diretamente aos dispositivos de segunda tela. Neste cenário, seria necessário o armazenamento, por parte das emissoras, de todos os usuários da aplicação para que o envio por notificações push fosse possível. Esta abordagem requer a criação, manutenção e gerenciamento de
um banco de dados robusto e escalável e de um sistema de envio de notificações push que tornasse possível o envio instantâneo das informações de sincronismo a todos os usuários da base.
A abordagem Single Signaling, utilizada no desenvolvimento da solução Synced- DTV, utiliza a atual estrutura de envio de informações sobre a programação pelas emissoras, para o envio das informações necessárias ao sincronismo e que, uma vez recebida essas informações, apenas em momentos em que haja um ponto de sincronismo entre os conteúdos televisivo e complementar web, a conexão com o servidor de conteúdo necessita ser estabelecida. Ou seja, a partir de um sinal único, enviado pelas emissoras por broadcast de transmissão, contendo os pontos de sincronismo, é possível determinar os momentos em que os servidores devem escalar esperando por múltiplas conexões de usuários em busca do conteúdo complementar.
Para a implementação do Single Signaling é proposto neste trabalho a utilização de um dos campos opcionais já existente na tabela EIT, chamado Extended Event Descriptor, ou Descritor de Evento Estendido. Este campo, como o próprio nome enfatiza, deve ser utilizado para prover ao usuário uma descrição mais detalhada sobre a programação atual sendo transmitida, como por exemplo, uma descrição detalhada do capítulo atual de uma novela ou informações relevantes sobre onde encontrar informações adicionais a cerca de um determinado conteúdo em exibição.
O campo Descritor de Evento Estendido, como definido em (NBR 15603-2, 2008), deve obrigatoriamente estar de acordo com a EN 300 744 (2007), subseção 6.2.15. A semântica para este descritor deve obrigatoriamente ser:
1. Descriptor_number: campo de 4 bits que deve obrigatoriamente informar o número do descritor. Ele deve obrigatoriamente ser utilizado para associar a informação de que não cabe em um único descritor. O descriptor_number do primeiro extended_event_descriptor de uma associação de
extended_event_descriptors deve obrigatoriamente ser “0x0”. O
descriptor_number deve obrigatoriamente ser incrementado de 1 a cada extended_event_descriptor adicional nesta seção.
2. ISSO_639_language_code: campo de 24 bits que deve obrigatoriamente identificar a linguagem do componente (no caso de áudio ou dados) e uma descrição em texto que pode estar contida no descritor. A ISO
639_language_code contém um código de 3 caracteres conforme a ISO 639-2. Cada caractere deve obrigatoriamente ser codificado em 8 bits de acordo com a ISO/IEC 8859-15 e inserido na ordem no campo de 24 bits;
3. Text_char: O conteúdo enviado no campo text_char especifica o complemento do texto enviado pelo short_extended_descriptor. A informação do texto é codificada de acordo com a ISO/IEC 8859-15.
Uma vez definida a forma pela qual a informação necessária para que o sincronismo ocorra será enviado ao usuário, o próximo passo é definir uma estrutura textual simplificada capaz de transmitir os dados necessários ao correto sincronismo entre o conteúdo transmitido pela TV e o conteúdo complementar web. O documento JSON (JavaScript Object Notation – Notação de Objetos JavaScript) exibido na caixa de texto abaixo demonstra um exemplo da formatação proposta por este trabalho.
{ "syncpoints": [ {"time":"200","inttype":0, "url":"http://192.168.0.127/teste/index.php"}, {"time":"300","inttype":1, "url":"http://192.168.0.127/teste/teste1.php"}, {"time":"400","inttype":0, "url":"http://192.168.0.127/teste/teste2.php"} ] }
Note que a estrutura do documento JSON proposto apresenta determinadas chaves, cada uma com um propósito específico para o correto estabelecimento do sincronismo. São eles:
1. sync_points: Objeto principal do documento, tendo como conteúdo uma coleção ou array de elementos que contém os dados necessários ao sincronismo entre os conteúdos.
2. time: Contém o tempo, em segundos, a partir do início da transmissão do conteúdo televisivo no qual um sincronismo deve acontecer.
3. int_type: Diminutivo de Tipo de Interrupção (Interruption Type), podendo assumir inicialmente dois valores:
0: quando apenas uma notificação deve ser exibida ao usuário acerca de um novo ponto de sincronismo ocorrido.
1: quando a interrupção pode/deve alterar o conteúdo exibido na segunda tela.
4. url: URL para acessar o conteúdo web relacionado a este ponto de sincronismo.
É importante observar que o modelo proposto é expansível a qualquer quantidade de pontos de sincronismo necessários, assim como adaptável a qualquer realidade requerida pelas operadoras. Uma vez que o conteúdo a ser transmitido possa ser traduzido em texto, o JSON proposto pode ser adaptado ou reformatado para atingir às exigências requeridas.