Dissertação de Mestrado - repositorio.ufpe.br · “Synced-DTV: Um Modelo para a Construção de...
109
Pós-Graduação em Ciência da Computação “Synced-DTV: Um Modelo para a Construção de Aplicativos Síncronos para TV Digital” Por RENATO AUGUSTO GOMES PINA FRANÇA Dissertação de Mestrado Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao RECIFE/2015
Transcript of Dissertação de Mestrado - repositorio.ufpe.br · “Synced-DTV: Um Modelo para a Construção de...
Pós-Graduação em Ciência da Computação
“Synced-DTV: Um Modelo para a Construção de
Aplicativos Síncronos para TV Digital”
Por
RENATO AUGUSTO GOMES PINA FRANÇA
Dissertação de Mestrado
Universidade Federal de Pernambuco
www.cin.ufpe.br/~posgraduacao
RECIFE/2015
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
RENATO AUGUSTO GOMES PINA FRANÇA
“SYNCED-DTV: UM MODELO PARA A CONSTRUÇÃO DE APLICATIVOS SÍNCRONOS PARA TV DIGITAL"
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADOR: Carlos André Guimarães Ferraz
RECIFE 2015
Catalogação na fonte
Bibliotecária Joana D’Arc Leão Salvador CRB4-532
F814s França, Renato Augusto Gomes Pina.
“Synced-DTV: um modelo para a construção de aplicativos síncronos para TV Digital” / Renato Augusto Gomes Pina França. – Recife: O Autor, 2014.
109 f.: fig., tab. Orientador: Carlos André Guimarães Ferraz. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIN,
Ciência da Computação, 2014. Inclui referências e apêndice.
1. Engenharia de software. 2. Televisão digital. I. Ferraz, Carlos André (Orientador). II. Titulo.
005.1 CDD (22. ed.) UFPE-MEI 2015-081
Dissertação de Mestrado apresentada por Renato Augusto Gomes Pina França à Pós-
Graduação em Ciência da Computação do Centro de Informática da Universidade Federal
de Pernambuco, sob o título “Synced-DTV: Um Modelo para a Construção de
Aplicativos Síncronos para TV Digital” orientada pelo Prof. Carlos André
Guimarães Ferraz e aprovada pela Banca Examinadora formada pelos professores:
______________________________________________
Prof. Kiev Santos da Gama
Centro de Informática/UFPE
______________________________________________
Prof. Carlos Eduardo Coelho Freire Batista
Centro de Informática /UFPB
_______________________________________________
Prof. Carlos André Guimarães Ferraz
Centro de Informática / UFPE
Visto e permitida a impressão.
Recife, 18 de dezembro de 2014.
___________________________________________________
Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
Dedico este trabalho a
minha família, em especial
a minha esposa Paula e
meu filho Renato, sem
eles não conseguiria ter
chegado até aqui.
AGRADECIMENTOS
Agradeço primeiramente a Deus, que de alguma forma, nos momentos
mais difíceis sempre esteve ao meu lado.
Ao meu orientador Prof. Dr. Carlos André Guimarães Ferraz, pelo
apoio e ideias oferecidas durante a construção deste trabalho. Agradeço também
por sua atenção, dedicação, confiança e por ter me aceitado como seu
orientando, tornando possível a realização do sonho de fazer mestrado. Seus
ensinamentos foram essenciais para a realização deste trabalho e para meu
engrandecimento pessoal.
À minha esposa Paula Souza, por seu amor, paciência, apoio e
compreensão que me deram forças para continuar nas horas mais difíceis.
Ao meu filho Renato França, por tudo que representa na minha vida e
por ser a razão de todo o meu esforço.
Ao Prof. Dr. Silvio Romero de Lemos Meira que também acreditou em
meu potencial e me aceitou inicialmente como orientando.
À empresa CESAR (Centro de Estudos e Sistemas Avançados do
Recife) por me permitir utilizar seu laboratório de TV digital para realizar as
pesquisas e contribuir na elaboração do trabalho. Agradeço também aos meus
colegas de trabalho do projeto Premium Apps e de tantos outros projetos, que
sem dúvida compartilharam comigo conhecimentos essenciais, os quais foram
aplicados neste trabalho e contribuíram para meu engrandecimento profissional.
Aos membros da banca avaliadora pelas valorosas contribuições
oferecidas.
Aos meus pais, Larri Pina de França e Maria de Fátima Gomes
Pereira, pela dedicação e ensinamentos da vida. Agradeço também por
contribuírem na construção do meu caráter e das minhas convicções, nas quais
obtive forças para persistir.
O período de maior ganho em conhecimento e experiência é
o período mais difícil da vida de alguém.
—DALAI LAMA
Resumo
A popularização da TV Digital no mundo trouxe consigo melhorias para o
telespectador como, imagem e som em alta definição, multiprogramação, mobilidade e
acesso à Internet. Este crescimento coincidiu com a popularização dos dispositivos
móveis inteligentes, smartphones e tablets, habilitando aos telespectadores à busca e
visualização de conteúdos diversos ao mesmo tempo que assiste a esta programação. O
uso destes aparelhos móveis enquanto se assiste a TV gerou o conceito de Segunda Tela.
No entanto, o conteúdo adquirido nem sempre possui ligação com o programa que está
sendo transmitido pela emissora de TV, tornando este tipo de tecnologia um concorrente
ou uma alternativa à programação transmitida, dispersando a atenção do telespectador.
Um dos grandes desafios é encontrar ferramentas computacionais mais eficientes para a
elaboração e implementação de formas de disponibilização de conteúdos complementares
ao transmitido pela TV, e ao mesmo tempo torná-las interessantes e atrativas aos olhos
dos usuários. Este trabalho propõe um modelo para o desenvolvimento de aplicativos para
TV Digital que utiliza informações contextuais da programação da TV, da própria TV e
do dispositivo de Segunda Tela para que, de forma automática e simples, seja possível a
exibição de conteúdos Web complementar à programação corrente da TV de forma
síncrona. Utilizando estruturas de comunicação atualmente em uso pelas emissoras e
definidas através de padrões regulamentados, o trabalho desenvolvido propõe uma
abordagem plausível de implantação, demonstrando que é possível prover conteúdos
complementares Web ao telespectador, de forma simples, automática e síncrona,
tornando a experiência de assistir televisão ainda mais rica e completa.
Palavras-chave: TV Digital. Segunda Tela. Sincronismo. Contextualização.
ABSTRACT
The popularization of digital TV in the world has brought improvements to the
viewer as, image and sound in high definition, multiprogramming, mobility and Internet
access. This increase coincided with the popularity of smart mobile devices, smartphones
and tablets, enabling viewers to search and display various types of content while
watching TV. The use of mobile devices while watching TV created the concept of
Second Screen. However, the mobile content does not always have connection with the
program being broadcast on TV, making this type of technology a competitor or an
alternative to broadcast programming, scattering the viewer's attention. A major challenge
is to find more efficient computational tools for designing and implementing ways of
providing additional content to broadcast on TV, and at the same time make them
interesting and attractive in the eyes of users. This paper proposes a model for the
development of applications for Digital TV that uses contextual information of TV
scheduling and the second screen device. So it may be possible in an automatically and
simple way to display web content related to the TV schedule synchronously. Using the
current communication structures by broadcasters and defined through regulated
standards, the developed work proposes a plausible approach to implementation,
demonstrating that it is possible to provide additional web content to viewer, in a simple
way, automatic and synchronously, making the experience of watch TV even more rich
and full.
Keywords: Digital TV. Second Screen. Synchronism. Context.
Lista de Ilustrações
Figura 1 - Estrutura das tabelas do PSI/MPEG-2. Derivado de: (EN 300 468,
1998) ................................................................................................................. 21
Figura 2 - Subsistemas do cenário do Synced-DTV. .................................... 36
Figura 3 - Diagrama de casos de uso nível zero do Synced-DTV. ................ 42
Figura 4 - Arquitetura da aplicação Synced-TVApp ................................... 45
Figura 5 - Arquitetura da aplicação Synced-SecondScreenApp .................... 47
Figura 6 - Diagrama de classes da aplicação Synced-TVApp ...................... 57
Figura 7 - Diagrama de sequência da captura de dados da TV. .................... 59
Figura 8 - Diagrama de classes da aplicação Synced-SeconScreenApp. ......... 64
Figura 9 - Estrutura visual da aplicação .................................................... 65
Figura 10 - Diagrama de sequência do serviço de conexão. ......................... 67
Figura 11 - Diagrama de sequência do sincronismo dos dados. .................... 70
Figura 12 – Processo de Normalização dos dados temporais. ...................... 74
Figura 13 - Sincronismo entre TV e Segunda Tela ..................................... 75
Figura 14 - Imagem da TV no primeiro sincronismo .................................. 81
Figura 15 - Imagem do smartphone no segundo sincronismo ...................... 81
Figura 16 - Imagem da TV no segundo sincronismo................................... 82
Figura 17 - Imagem do smartphone no segundo sincronismo ...................... 82
Figura 18 - Proporção dos Atrasos de Processamento ................................. 88
Figura 19 - Atrasos dos processamentos do sistema ................................... 89
Figura 20 - Synced-DTV em múltiplos dispositivos ................................... 93
Lista de Tabelas
Tabela 1 - Descrição do gênero do descritor. ................................................................. 24
Tabela 2 – Configurar a TV ............................................................................................ 43
Tabela 3 – Obter Dados Contextuais .............................................................................. 43
Tabela 4 – Validar Dados Contextuais ........................................................................... 44
Tabela 5 - Fatores de comparação .................................................................................. 49
Tabela 6 - Facilidade de Uso .......................................................................................... 91
Tabela 7 - Utilidade ........................................................................................................ 91
Sumário
1 Introdução ..................................................................................... 14
1.1 Motivação e Justificativas .......................................................... 14
1.2 Objetivos ................................................................................... 16
1.2.1. Objetivos Específicos ....................................................... 16
1.3 Estrutura do Trabalho ................................................................ 17
2 Estado da Arte .............................................................................. 19
2.1 TV Digital e Segunda Tela ......................................................... 19
2.2 Dados Contextuais de Televisão Digital .................................... 19
2.2.1. O Descritor: content_descriptor ........................................ 23
2.2.2. O Descritor: extended_event_descriptor .......................... 24
2.3 Segunda Tela ............................................................................ 25
2.4 Tecnologias Relacionadas ........................................................ 26
2.4.1. Impressão Digital de Áudio............................................... 26
2.4.2. Marca D’Água de Áudio ................................................... 27
2.4.3. Reconhecimento de Vídeo ............................................... 27
2.4.4. Sincronização Local de TV ............................................... 28
2.4.5. Sincronização de Internet ................................................. 28
2.5 Trabalhos Relacionados ............................................................ 28
2.5.1. Dados Contextuais ........................................................... 29
2.5.2. Sincronismo ...................................................................... 30
3 SYNCED-DTV .............................................................................. 34
3.1 Visão Geral ................................................................................ 34
3.2 Cenários de Uso ........................................................................ 36
3.2.1. Cenário Um ...................................................................... 36
3.2.2. Cenário Dois ..................................................................... 37
3.2.3. Cenário Três ..................................................................... 37
3.3 Levantamento dos requisitos ..................................................... 38
3.3.1. Requisitos Funcionais ...................................................... 39
3.3.2. Requisitos Não Funcionais ............................................... 40
3.4 Diagrama dos Casos de Uso ..................................................... 41
3.5 Descrições dos Casos de Uso .................................................. 42
3.6 Arquitetura ................................................................................. 45
3.6.1. Synced-TVApp ................................................................. 45
3.6.2. Synced-SecondScreenApp .............................................. 46
3.7 Comparação com Modelos de TV e Tecnologias de Sincronismo
48
3.8 Discussões ................................................................................ 51
4 Implementação da Solução .......................................................... 53
4.1 Sincronismo com Segunda Tela ................................................ 53
4.2 Synced-WebServers.................................................................. 56
4.3 Synced-TVApp .......................................................................... 57
4.3.1. Implementação da Arquitetura ......................................... 57
4.3.2. Formatação dos dados contextualizados ......................... 61
4.4 Synced-SecondScreenApp ....................................................... 64
4.5 Desafios de implementação do sistema .................................... 72
4.5.1. Normalização dos dados temporais ................................. 72
4.5.2. Sincronismo Automático ................................................... 74
4.5.3. Tomada de Decisão Sobre Interrupção ............................ 76
4.5.4. Atraso no Recebimento dos Metadados .......................... 77
4.5.5. Ausência dos Dados Contextuais ..................................... 80
4.6 Avaliação das Funcionalidades do Sistema .............................. 80
4.6.1. Cenário de Uso ................................................................ 80
4.6.2. Atrasos de Comunicação ................................................. 87
4.6.3. Avaliação de aceitação da solução .................................. 90
4.6.4. Sincronismo em Múltiplas Telas ....................................... 92
4.7 Ambiente operacional ................................................................ 93
4.8 Discussões ................................................................................ 94
5 Conclusões ................................................................................... 95
5.1 Contribuições do trabalho .......................................................... 98
5.2 Trabalhos Futuros ..................................................................... 99
Referências ....................................................................................... 100
APÊNDICE I ...................................................................................... 104
14
1 Introdução
Desde a criação da TV houve uma busca constante por melhorias na qualidade
de imagem e de som, o que levou à digitalização, também adotada em outros meios de
comunicação em massa, como o rádio. Esta mudança, denominada de TV Digital,
representa não apenas a substituição das plataformas analógicas pelas digitais, mas
também o rompimento com os moldes tradicionais de criação, distribuição e manipulação
de conteúdo. É o surgimento de uma nova mídia mais completa, complexa e abrangente
que sua antecessora analógica.
Esta nova mídia surge no momento em que a mobilidade e a portabilidade estão
revolucionando o cotidiano das pessoas, possibilitando a obtenção de informações em
qualquer lugar e a qualquer momento. As disponibilizações de informação em conjunto
com a digitalização da TV tornaram possível a criação de conceitos como o de Segunda
Tela (Second Screen), que pode ser descrita como toda e qualquer experiência de
engajamento da audiência, que inclui a TV Social (GIGLIETTO e SELVA, 2014) como
um elemento integrante.
Este posicionamento generaliza o uso da Segunda Tela não como apenas um
conteúdo que agrega valor ao programa distribuído pela emissora, mas como um
dispositivo utilizado em uma estratégia de comunicação que incentiva a participação do
telespectador, e o compartilhamento de conteúdo em sua rede de relacionamento de forma
atuante. Para isso, o conteúdo tem de ser relevante para o telespectador e ser capaz de
requerer um maior engajamento deste e prever ações (compartilhamento nas redes
sociais) por parte do usuário na construção desta relevância.
Para a utilização deste conceito é necessário definir o que é relevante para o
usuário durante uma interação com um dispositivo/serviço de TV Digital, capturar estes
dados de forma transparente e não intrusiva, e, finalmente, utilizar estas informações em
prol do próprio usuário. Esta variação de meios de acesso e a diversidade de conteúdo
disponibilizado é alvo de estudos frequentes no meio acadêmico e empresarial
internacional.
1.1 Motivação e Justificativas
De acordo com um estudo da Google (GOOGLE, 2012) os consumidores estão
se tornando cada vez mais “multi-screeners”, utilizando computadores, TVs, smartphones
15
ou tablets, dependendo da localização, da quantidade de tempo disponível e do conteúdo
sendo assistido. Este tipo de comportamento gerou um mercado mundial de
aproximadamente 490 milhões de dólares em 2013, estimando atingir 5,9 bilhões em
2017 (STEPHEN, 2012).
Diversos estudos mostram uma tendência, por parte de telespectadores, de uso
de dispositivos enquanto assistem TV. Segundo dados da empresa de pesquisa Nielsen
Ratings (http://www.nielsen.com), empresa que realiza medição de audiência, pessoas
utilizam com grande frequência tablets e smartphones enquanto assistem TV, sendo
observado um aumento considerável no número de comentários nas redes sociais sobre o
conteúdo sendo assistido durante a transmissão deste conteúdo.
Por outro lado, pesquisas recentes (PAVSEK e MOHAR, 2013) (GEMME e
CRAMER, 2013) mostram que, dos usuários que afirmam assistir TV com um
smartphone ou tablet em mãos, apenas 42% deles tenham realmente tentado utilizar uma
aplicação correspondente de segunda tela. Destes usuários, apenas 13% afirmaram que a
experiência sincronizada realmente modificou a experiência de assistir TV. Grande parte
da frustração com a experiência, demonstrada pelos usuários, é decorrente das
dificuldades encontradas em descobrir quais programas apresentam aplicativos de
sincronização, dificuldades no sincronismo destas aplicações e a falta de opções de
escolha de quais conteúdos devem ser sincronizadas.
Outro fator importante para o baixo nível de satisfação se deve à disponibilização
de aplicações específicas para determinadas programações, como por exemplo,
aplicações para seriados, programas de culinária e eventos esportivos. Este tipo de
abordagem exige que o usuário verifique a existência de aplicativos para uma
programação específica, sendo necessário aprender e se adaptar à forma como o
sincronismo ocorre e de como o conteúdo é exibido, além de não se aplicar a
programações televisivas abertas (GEMME e CRAMER, 2013).
A solução Synced-DTV, apresentada neste trabalho, propõe uma arquitetura
simples, contextualizada (DEY et al, 1999), que utiliza informações da própria
programação, e de fácil adoção pelas emissoras, que utiliza dados complementares da
programação transmitida em conjunto com informações do dispositivo de segunda tela
para prover uma experiência síncrona, automática e mais personalizada de assistir
16
televisão. DEY at al (1999) definem contexto como "qualquer informação que pode ser
usada para caracterizar a situação de uma entidade".
1.2 Objetivos
Este trabalho tem o objetivo de propor um modelo de desenvolvimento e
comunicação, chamado Synced-DTV, que demonstrará como as aplicações interativas
emergentes para as TVs híbridas (AL-MAJEED et al, 2012) podem fazer uso das
funcionalidades oferecidas pela plataforma, para oferecer ao telespectador um conteúdo
Web sensível à programação da TV de forma síncrona e automatizada. Este conteúdo é
contextualizado em relação ao programa corrente da transmissão broadcast, sendo obtido
na Internet e oferecido ao telespectador com o intuito de aprimorar a sua experiência
televisiva, agregando valor à aplicação interativa.
1.2.1. Objetivos Específicos
Para alcançar o objetivo geral do Synced-DTV, os seguintes objetivos específicos
foram determinados:
1. Propor um modelo para o desenvolvimento de aplicações e comunicação
para TV digital, que agreguem valor ao conteúdo da grade de
programação das emissoras, trazendo informações complementares de
forma síncrona e automatizada para dispositivos de Segunda Tela.
2. Desenvolver uma solução padronizada para o estabelecimento de
comunicação síncrona entre conteúdos de TV e Web complementar de
forma simplificada e automática, possibilitando a aderência de emissoras
sem a necessidade de alterações profundas e custosas nas atuais
estruturas utilizadas para a transmissão de conteúdo.
3. Propor um modelo genérico, facilmente extensível e adaptável, para o
desenvolvimento de aplicações que utilizam o contexto da programação
da TV, obtidas através do uso das tabelas de informações de sistemas,
como o padrão DVB (EN 300 744, 2007) para prover uma experiência
mais rica e completa ao telespectador.
4. Utilização eficiente de informações contextuais da TV, da programação
corrente e do dispositivo de Segunda Tela para a inferência das
17
preferências do telespectador, tornando possível uma disponibilização
personalizada, eficaz e menos intrusiva de conteúdos complementares.
5. Propor uma arquitetura de serviço para a elaboração de uma aplicação
para o ambiente do middleware brasileiro de televisão digital Ginga-J
(NBR 15606-4, 2010), com as características que se adequem melhor ao
cenário proposto no trabalho.
Para atingir estes objetivos, será necessário elaborar uma infraestrutura modular
de software que possibilite a obtenção das informações contextuais advindas das tabelas
de informação definidas para TV Digital (que representarão o contexto da programação
da TV), a obtenção do conteúdo complementar Web relacionado à programação corrente
e a exibição do conteúdo obtido ao telespectador de forma síncrona e automática. Esta
infraestrutura deverá ser independente dos sistemas operacionais utilizados, além de
possuir uma arquitetura de baixo acoplamento, viabilizando futuras alterações ou
acréscimos de módulos à solução. A concepção da solução, por sua vez, deverá ser
baseada em requisitos funcionais e não funcionais de modo que o desenvolvimento das
funcionalidades inerentes à solução possa ser avaliado através de cenários de testes.
1.3 Estrutura do Trabalho
Esta dissertação está estruturada em cinco capítulos. Neste primeiro capítulo
foram apresentadas as motivações/justificativas, objetivos e as principais contribuições
do trabalho. O segundo capítulo tem como objetivo apresentar conceitos sobre TV Digital
e Segunda Tela, e a forma como estes estão relacionados. Neste capítulo também são
descritos fundamentos sobre o sistema de metadados das tabelas de informações de TV
Digital, e sobre tecnologias atualmente no mercado utilizadas para o sincronismo entre
conteúdo televisivo e complementar. Por fim, são descritos trabalhos que estão
relacionados com a proposta do Synced-DTV.
O capítulo 3 apresenta uma visão de alto nível sobre a solução Synced-DTV,
descrevendo os seus módulos e as responsabilidades de cada um deles. Também são
descritos alguns possíveis cenários de uso, assim como o resultado do levantamento dos
requisitos funcionais e não funcionais. É apresentado o diagrama de casos de uso, a
descrição de cada um dos casos e, por fim, é descrita o modelo de desenvolvimento
elaborado para a solução.
18
O quarto capítulo, por sua vez, explana detalhes sobre a implementação de cada
um dos módulos componentes do modelo Synced-DTV, especificando as
responsabilidades atribuídas a cada um destes módulos. Detalhes sobre a forma como o
sincronismo entre os conteúdos televisivo e complementar será feito, os desafios
encontrados durante o desenvolvimento da solução e a forma utilizada para o sincronismo
automático entre os subsistemas da solução. Um cenário de uso que teste a
implementação, os resultados obtidos durante a experimentação e uma avaliação de
aceitação da aplicação finalizam este capítulo.
E por fim, o capítulo cinco encerra a dissertação apresentando as conclusões,
contribuições e sugestões de trabalhos futuros que podem dar continuidade à pesquisa
apresentada neste trabalho.
19
2 Estado da Arte
Este capítulo apresenta conceitos fundamentais aplicados à solução proposta
pelo trabalho.
2.1 TV Digital e Segunda Tela
A história da TV digital começa na década de 1970 no Japão, quando
a NHK (Nippon Hoso Kyokai) e um grupo composto por 100 estações de TV locais,
iniciam as pesquisas e o desenvolvimento de uma TV de alta qualidade de imagem,
ou HDTV (High Definition TV). O objetivo seria dar ao espectador mais realismo e
proximidade não só com a imagem, mas também com o som, aproximando a imagem da
TV com a imagem do cinema, inclusive no formato de tela larga (wide), usado no cinema
desde 1951 (CHEN et al, 2004).
Apenas em 1994, e já utilizando as novas tecnologias de compactação de som e
imagem, o MP3 para áudio e o MPEG (Motion Pictures Expert Group) para vídeo, foi
criado na Europa o padrão DVB (Digital Video Broadcast), que posteriormente serviu de
base para a criação do padrão japonês ISDB-T (Integrated Services Digital Broadcasting
- Terrestrial), e posteriormente o padrão SBTVD (Sistema Brasileiro de TV Digital) ou
ISDB-TB, atualmente em uso no Brasil.
O padrão DVB pode e deve ser considerado como um dos pioneiros para a
padronização da TV Digital no mundo, servindo de modelo e criando padrões genéricos
a serem implementados por quaisquer outros modelos derivados dele. Desta forma, é
possível afirmar que uma aplicação desenvolvida em complacência com o padrão DVB
ou um dos padrões derivados deste podem ser adaptados a qualquer dos outros padrões.
Assim, por serem baseados no padrão DVB, os padrões ISDB-T e SBTVD apresentam
características muito semelhantes na forma como as informações são tratadas para o envio
ao telespectador.
2.2 Dados Contextuais de Televisão Digital
Dentre os dados inseridos no fluxo de transporte (Transport Stream - TS) a ser
transmitido para a TV podem ser encontradas as informações de Closed Caption, dados
de interatividade, além das tabelas definidas pela norma MPEG-2 Systems (ISO/IEC,
2013). Entre as tabelas inseridas estão a PSI (Program Specifc Information) / SI (Service
20
Information). As informações PSI são as tabelas padronizadas pela norma MPEG-2
Systems e as informações SI são as tabelas específicas e características de cada sistema
de transmissão (DVB, ISDB, ATSC e SBTVD).
A ISO/IEC 13818-1 (ISO/IEC, 2013) define que os dados PSI proveem
informações necessárias à configuração automática do receptor para realizar a
demutiplexação e decodificação dos vários streams de programas dentro do sinal
multiplexado.
Os dados PSI são estruturados em quatro tipos de tabela.
1- PAT (Program Association Table): Indica os valores de localização (os
valores do PID (Packet Identifier)) dos pacotes do TS (Transport Stream). Contém
também a localização da NIT (Network Information Table).
2- CAT (Conditional Access Table): Contém informações sobre o sistema de
acesso condicional (Conditional Access - CA) utilizado na multiplexação.
3- PMT (Program Map Table): Identifica e disponibiliza a localização dos
stream que compõem cada serviço, assim como a localização dos campos PCR (Program
Clock Reference) do serviço.
4- NIT (Network Information Table): Provê informações sobre a rede física.
Complementar aos dados das tabelas PSI/MPEG-2, são necessárias outras
informações para a identificação dos serviços e dos eventos para o usuário. A
Figura 1 mostra uma organização geral das tabelas SI presentes na especificação
DVB.
Todas as outras tabelas fazem parte do conjunto das tabelas SI, inclusive a tabela
EIT (Event Information Table ou Tabela de Informações de Eventos). De acordo com a
norma, esta tabela é responsável por prover as informações em ordem cronológica sobre
os eventos que compõem o serviço e será de fundamental importância para o
desenvolvimento do modelo proposto por este trabalho.
21
Figura 1 - Estrutura das tabelas do PSI/MPEG-2. Derivado de: (EN 300 468, 1998)
As tabelas EIT contêm dados referentes aos eventos e programas como, por
exemplo, o nome do evento, horário de início e duração, entre outros. Estes dados são
responsáveis pela criação do chamado EPG (Electronic Program Guide – Guia Eletrônico
de Programação), que é um serviço para televisão, rádio ou outra aplicação multimídia
onde é possível mostrar informações sobre a programação corrente ou futura. A
implementação do EPG geralmente depende de algum middleware dedicado,
22
completamente dependente da tecnologia de distribuição, funcionalidades presentes e
largura de banda requerida.
Basicamente, para a construção de um EPG são necessários dois grupos de
tabelas:
1- Presente/Seguinte: Contém informações sobre eventos atualmente sendo
transmitidos e eventos que serão exibidos a seguir. Estas tabelas necessitam
de uma taxa de atualização bastante rápida, normalmente em torno de 2
segundos, possibilitando a recepção das informações pelo usuário
rapidamente.
2- Agendada: Contém informações sobre a programação a ser exibida no
futuro, podendo ser enviado o conteúdo de até 64 dias, no caso da
implementação de referência do DVB, podendo variar nos outros padrões
de TV Digital. A taxa de atualização destas tabelas pode ser
consideravelmente maior, chegando a 30 segundos na implementação
DVB.
A semântica das informações da seção que descreve a informação dos eventos
deve, obrigatoriamente, estar de acordo com a norma (EN 300 468, 1998) do DVB.
Porém, é importante ressaltar que em alguns casos, como no caso do SBTVD, algumas
seções podem ser compostas, por exemplo, pelos campos “table_id”, “start_time”,
“duration”, “format” e “running_status” que são descritos pela norma NBR 15603-2
(2007). A descrição dos principais campos desta seção, obtidos nas duas normas, pode
ser resumida da seguinte forma:
event_id: Número indicador de evento único.
start_time: A hora no qual o evento se inicia baseado no UTC.
duration: A duração do evento em segundos.
running_status: O status atual do evento. Ex. rodando, não-rodando,
pausado, etc.
free_CA_mode: Indica se algum componente do serviço é embaralhado
e controlado por um sistema condicional de acesso (CA system).
23
short_event_descriptor: Descritor básico para o evento. Contém o nome
e uma breve descrição do evento.
extended_event_descriptor: Descreve informações mais detalhadas
sobre o evento.
content_descriptor: Provê informações sobre a classificação de gênero
do evento.
component_descriptor: Provê informações sobre os componentes do
serviço do evento, como o formato do vídeo, sistema de compressão
utilizado e legendas.
Para este trabalho, dentre os descritores presentes no padrão DVB, e por herança
no padrão SBTVD, alguns são melhor explanados por terem uma relevância maior ou um
entendimento mais profundo acerca da implementação feita. Para esta explanação serão
utilizados valores extraídos da norma SBTVD, padrão utilizado como base para o
desenvolvimento deste trabalho.
2.2.1. O Descritor: content_descriptor
Este descritor deve ser, obrigatoriamente, utilizado para informar a classificação
de um evento. O descritor de conteúdo possui três campos em sua estrutura de dados: o
content_nibble_level_1, campo de 4 bits que é utilizado para representar o primeiro nível,
correspondente à classificação do gênero de um identificador de conteúdo (Ex. 0xC -
Filme); o content_nibble_level_2, campo de 4 bits que deve ser utilizado para representar
o segundo nível, correspondente à classificação do subgênero de um identificador de
conteúdo (Ex. 0x1 – Ação); e o user_nibble, campo de 4 bits que pode ser definido pelo
transmissor.
Pela norma do SBTVD o campo content_nibble_level_1 deste descritor de
conteúdo pode apresentar 16 valores distintos para os possíveis gêneros televisivos como
apresentado na Tabela 1 abaixo.
24
Tabela 1 - Descrição do gênero do descritor. Fonte: retirado de (NBR 15603-2, 2008)
A informação desta tabela é importante para este trabalho, pois permite a
definição por parte do usuário de quais gêneros televisivos são do seu interesse, servindo
como um filtro na entrega dos conteúdos sincronizados, como será detalhado na Seção
4.3.
2.2.2. O Descritor: extended_event_descriptor
De acordo com a norma (NBR 15603-2, 2008), o descritor de evento estendido
deve estar de acordo com a EN 300 744 (2007), subseção 6.2.15, e é definido como um
descritor opcional, ficando a cargo das emissoras o envio ou não de informações neste
descritor. A semântica para o descritor de evento estendido deve obrigatoriamente ser:
descriptor_number: campo de 4 bits que deve informar o número do descritor.
Ele deve, obrigatoriamente, ser utilizado para associar a informação 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 ser “0x0”. O descriptor_number deve obrigatoriamente ser incrementado de
25
1 a cada extended_event_descriptor adicional nesta seção (ver
(EN_300_468:2007, 2007), subseção 6.2 15);
ISO_639_language_code: campo de 24 bits que deve 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 ser codificado em 8 bits de
acordo com a ISO/IEC 8859-15 e inserido na ordem no campo de 24 bits - Ex. O
Português, idioma oficial do Brasil tem 3 caracteres de código “por”, que é
codificado como “0111 0000 0110 1111 0111 0010”.
text_char: campo de 8 bits. 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.
Este descritor é de grande importância para o trabalho proposto, pois através dele
os dados necessários à sincronização entre o conteúdo televisivo e os dados
complementares serão enviados, como será apresentado na Seção 4.4.
2.3 Segunda Tela
O conceito de Segunda Tela (Second Sceen) foi criado com o crescente uso de
dispositivos computacionais, normalmente um smartphone ou tablet, para o provimento
de uma experiência televisiva mais rica e completa, utilizando este dispositivo adicional
para o fomento de novos conteúdos adicionais ao assistido pela tela principal, como a TV.
Existem diversos aplicativos de Segunda Tela disponibilizados atualmente,
como por exemplo, o aplicativo da série de TV Walking Dead, que transmite ao usuário,
em tempo real, informações complementares à programação sendo transmitida, além de
possibilitar o acesso a informações relevantes para a série como descrição dos
personagens, resumo de capítulos anteriores e teasers de próximos capítulos.
Este uso crescente de dispositivos representa uma oportunidade para a criação
e oferecimento de novos serviços e produtos que possam aumentar o engajamento e
enriquecimento do conteúdo transmitido com os telespectadores. Uma vez que os
usuários podem assistir o conteúdo televisivo quando eles querem, os dispositivos de
segunda tela podem servir como grandes divulgadores de conteúdos assíncronos, quando
não são transmitidos diretamente via broadcast direto.
26
Diversos estudos foram realizados fomentando o uso de dispositivos de segunda
tela como potencializadores de conteúdo, como (BORCH et al, 2014), que propõe uma
arquitetura genérica para o desenvolvimento de soluções utilizando uma rede social de
pessoas, suas aplicações e dispositivos. Diversos aspectos da utilização da Segunda Tela
são explorados, tais como possíveis modelos de negócios, abordagens de obtenção e
propagação de conteúdos e os possíveis casos de uso, no qual o uso de Segunda Tela
poderia ser uma abordagem para criação de novos negócios. (KOVACEVIC et al, 2014)
descrevem uma forma de propagação das informações do guia eletrônico de programação
(EPG) para dispositivos Android, tornando possível a visualização do mesmo em um
dispositivo de segunda tela.
2.4 Tecnologias Relacionadas
Nesta seção, serão apresentadas tecnologias existentes no mercado que
possibilitam a comunicação e/ou sincronismo de conteúdos entre TV, Web e Segunda
Tela, com o objetivo de contextualizar e complementar o estado da arte e a metodologia
proposta por este trabalho.
2.4.1. Impressão Digital de Áudio
Assim como a impressão digital humana pode ser considerada única entre todos
os seres vivos por causa da disposição de suas linhas e cavidades, uma impressão digital
de áudio também pode ser considerada única segundo a representação de suas frequências
e amplitudes.
Segundo CANO et al (2002), basicamente, Impressão Digital de Áudio (Audio
Fingerprinting), funciona extraindo uma assinatura da trilha de áudio do conteúdo de
vídeo ou música e armazena em um banco de dados. Quando um áudio a ser identificado
é apresentado, sua “fingerprint” é calculada e comparada contra as armazenadas no banco
de dados. Utilizando estas fingerprints e algoritmos de comparação, versões distorcidas
de uma amostra de áudio podem ser identificadas como o mesmo conteúdo de áudio.
Esta técnica pode ser utilizada para a identificação do conteúdo broadcast de TV
em tempo real, possibilitando assim a utilização dos mesmos como marcas de
sincronismos a serem computadas. Uma vez que a identificação da fingerprint depende
da captação correta do áudio transmitido, esta captação pode tornar-se comprometida por
diversos fatores, como por exemplo, ruídos ou falhas no algoritmo de geração da
27
fingerprint. Outros fatores a serem considerados envolvem: o armazenamento das
fingerprints de comparação, o custo computacional para a extração da fingerprint e a
latência do serviço necessário para a comparação das mesmas.
2.4.2. Marca D’Água de Áudio
A adição de marcas d’água é comumente utilizada em documentos oficiais de
empresas a fim de demonstrar autenticidade de documentos, porém normalmente esta
marca não pode ser vista a não ser por pessoas que sabem exatamente onde encontrá-las.
Este mesmo conceito pode ser aplicado em arquivos de áudio também.
Devido às propriedades limitadas do ouvido humano, um sinal extra (marca
d’água) pode ser adicionado ou escondido na faixa de áudio original tornando-se
inaudível para seres humanos, mas podendo ainda ser capturado por microfones. Esta
característica define a técnica de Marca D’água de Áudio (Audio Watermarking).
Dependendo da técnica e algoritmo utilizados, um identificador e informações
de tempo podem ser adicionados sem serem notadas ou afetando a qualidade do áudio.
Uma vez que o programa seja capaz de capturar o sinal da marca d’água, informação
sobre qual programa está sendo assistido, assim como informações de tempo necessárias
para o sincronismo da aplicação.
É importante notar que, assim como na técnica de Audio Fingerprinting, a
qualidade do áudio capturado é o fator de maior influência para o sucesso da identificação
do conteúdo exibido.
2.4.3. Reconhecimento de Vídeo
Segundo SEGUNDO e SANTOS (2013), Reconhecimento de Vídeo (Video
Recognition) usa o vídeo ao invés do áudio para sincronizar aplicações de segunda tela.
Assim como em Audio Watermarking, esta técnica adiciona informações no conteúdo de
vídeo para sincronizar as aplicações.
Esta solução pode ser utilizada de várias formas, incluindo derivações das
soluções previamente apresentadas de Audio Watermarking e Fingerprinting. (Vignaroli,
Pero, & Negro, 2012), utilizaram uma marcação de QR Code para manipular parâmetros
e informações para a segunda tela. Através de um smartphone, este QR Code seria lido e
a aplicação de segunda tela seria sincronizada automaticamente. Existem também
28
soluções no mercado no qual uma foto do conteúdo televisivo deve ser tirada pela
aplicação de segunda tela, e enviada a um servidor que fará a busca nos conteúdos
previamente armazenados, ocorrendo assim a identificação deste conteúdo.
2.4.4. Sincronização Local de TV
Este mecanismo utiliza o receptor local da TV como gerenciador do processo de
sincronismo. Para isto, é necessário que de alguma forma, seja por bluetooth, rede local,
ou qualquer outra conexão, o aparelho de segunda tela possa se comunicar diretamente
com a TV para o envio de informações.
Algumas propostas seguindo esta abordagem foram feitas, como por exemplo,
(SOARES et al, 2009) propuseram um modelo de controle hierárquico em NCL para
suporte de exibição em múltiplos aparelhos. Este trabalho será mais bem detalhado na
seção de Trabalhos Relacionados.
2.4.5. Sincronização de Internet
Sincronização de Internet utiliza a Internet como meio de prover conteúdo
adicional ao transmitido via broadcast. Diferencia das outras formas de sincronismo por
não necessitar de uma conexão direta com a TV. Normalmente, o processamento
necessário à descoberta do conteúdo acontece em servidores externos, sendo uma API de
acesso disponibilizada para a integração com esses serviços.
Empresas como Synchronize.tv, TvTak e Never.no utilizam esta metodologia na
implementação de seus serviços de reconhecimento e sincronização de conteúdo. Um
cliente, por exemplo, pode contratar o serviço destas empresas para exibir um conteúdo
específico na segunda tela sempre que um comercial de algum concorrente esteja sendo
exibido.
2.5 Trabalhos Relacionados
Nesta seção, serão apresentados trabalhos presentes na literatura que analisam o
sincronismo e a oferta de conteúdos entre TV e conteúdo de segunda tela, com o objetivo
de contextualizar e complementar a metodologia proposta por este trabalho e o estado da
arte até então apresentado.
29
Estes trabalhos foram divididos em duas seções distintas, onde inicialmente são
apresentados trabalhos focados no uso dos dados contextuais da programação e
posteriormente serão apresentados trabalhos relacionados ao sincronismo em TV Digital.
2.5.1. Dados Contextuais
No trabalho de SOARES et al (2009) é apresentado um modelo de controle de
exibição do conteúdo de TV Digital em múltiplos dispositivos utilizando NCL (Nested
Context Language) em conjunto com Ginga-NCL (NBR 15606-4, 2010).
O modelo proposto especifica um modelo hierárquico de responsabilidades que
torna possível a orquestração de todos os dispositivos capazes de executar rotinas (tasks)
NCL. Estes dispositivos podem ser separados levando em consideração a capacidade de
exibir conteúdo contextual de mídia e os que são capazes de processar documentos com
informações contextuais NCL, formando o que foi chamado de Domínio de Dispositivo
(Device Domain). Por fim, estes dispositivos se registram no orquestrador que, então,
pode atribuir a responsabilidade de executar o conteúdo de mídia contido nos documentos
NCL (<Media> elements) a um dos dispositivos selecionados. Segundo os autores, “a
maioria das implementações comerciais de Ginga-NCL ainda não suportam essa
funcionalidade, uma vez que a implementação do middleware é obrigatória, mas o
hardware necessário é opcional”.
CALIXTO et al (2013), apresentam um modelo baseado em serviços globais
para TV Digital híbrida (AL-MAJEED et al, 2012) e interativa, aliando a disponibilidade
e escalabilidade funcionalidades executando como serviços de PaaS (Platform as a
Service) na nuvem, dispositivos de segunda tela e aplicações Web universalizadas,
capazes de executar em qualquer browser.
Esta abordagem foi proposta visando aumentar as possibilidades de interação em
todos os possíveis cenários apresentados, como por exemplo, a presença ou ausência de
internet, a possibilidade de testar e avaliar as aplicações Web em browsers, a utilização
de dispositivos de segunda tela para a exibição de conteúdos complementares e a
adaptabilidade dos serviços levando-se em consideração a demanda e a escalabilidade.
Propõe-se o uso de algumas tecnologias a fim de alcançar estes objetivos, como: o uso de
HTML5 ou CE-HTML para a criação das aplicações Web e a comunicação da Segunda
Tela com o conteúdo broadcast da TV através de QR Codes.
30
Outro fator considerado pelos autores é a diferença nos padrões adotados pelos
países para a interatividade na TV, o que impossibilita a criação de um modelo que possa
ser utilizado globalmente. Há também, por parte das operadoras de TV, a falta de um
padrão na criação de aplicações tornando necessário o desenvolvimento de sistemas
chamados regionais que atendem apenas a necessidade de uma operadora.
O trabalho feito por SOARES (2012) pode ser considerado como um dos
pioneiros na extração e uso dos dados das tabelas de informação do SBTVD utilizando
como base o subsistema de midleware Ginga-J. O modelo de seu trabalho propõe o uso
das informações contextuais da programação corrente da TV utilizando a interatividade
proporcionada pela TV como uma ferramenta de agregação de valor ao conteúdo da grade
de programação das emissoras, fazendo uso de uma aplicação interativa, elaborada para
o middleware da TV com acesso à Internet.
Este trabalho também foi responsável pelo desenvolvimento de um módulo de
captura de informações, para a aplicação interativa elaborada sobre o middleware Ginga-
J (NBR 15606-4, 2010) e (NBR 15606-6, 2010), que descrevem o contexto da
programação transmitida pela TV. Informações que, para este trabalho, serão advindas
das tabelas de informação de serviço (Service Information – SI) fornecidas pelas
emissoras de TV.
Em parte, o módulo de captura de informações da programação da TV
desenvolvido por SOARES (2012) foi utilizado como base para a implementação do
módulo denominado Synced-TVAPP da solução Synced-DVT, proposta por este trabalho.
2.5.2. Sincronismo
Em seu trabalho SIMON; COMUNELLO; WANGENHEIM (2013) propõem
uma arquitetura para a utilização de dispositivos móveis como segunda tela de uma forma
sincronizada e contextualizada. Esta arquitetura utiliza um framework UPnP para o
reconhecimento de dispositivos conectáveis e o posterior pareamento entre eles e a TV.
Buscando descobrir quais soluções estavam sendo propostas para melhorar a
interação entre a TV e os dispositivos de segunda tela, uma revisão sistemática foi
conduzida, localizando um total de 13 pesquisas relevantes ao tema. Estas puderam ser
divididas em duas categorias: pesquisas focadas em controle remoto e as outras em
segunda tela. As pesquisas de controle remoto, em sua maioria, focavam na utilização de
31
dispositivos móveis como motivação para a melhoria de interação e navegação do Guia
de Programação Eletrônico (EPG - Eletronic Program Guide). As pesquisas focadas em
segunda tela abordavam diversas áreas de estudo, desde a investigação de formas
eficientes de descobrimento de dispositivos disponíveis para pareamento com a TV, até
o desenvolvimento de um sistema multiplataforma para o aprendizado informal de
línguas.
Na solução final proposta, cada TV presente na sala é responsável por gerenciar
os dispositivos conectados a ela independentemente, assim como o estabelecimento e
manutenção das conexões, o recebimento de mensagens e o envio de conteúdos
interativos. A conexão entre a TV e os dispositivos de segunda tela presentes é realizada
utilizando comunicação via socket, sendo necessário a leitura de um QR Code na TV para
a obtenção dos valores necessários ao estabelecimento da conexão.
DUONG; HOWSON; LEGALLAIS (2012) propuseram um mecanismo híbrido
de sincronismo entre TV e segunda tela envolvendo uma técnica de Audio Fingerprinting,
utilizada para reduzir o custo computacional, em conjunto com uma técnica de
Generalized Cross Correlation (GCC-PHAT) (BRANDSTEIN e SILVERMAN, 1997),
que oferece uma forma eficiente de comparação e identificação de padrões similares de
áudio.
Para que ocorra uma identificação confiável com o uso de técnicas de Audio
Fingerprinting, geralmente é necessária a extração de vários segundos de gravação, em
média de 5 a 10 segundos, sendo necessário esperar este tempo para que o serviço de
identificação seja iniciado. Segundo a proposta, ao adotar uma técnica de Cross
Correlation, a amostra de áudio necessária para a correta identificação do áudio pode
diminuir para apenas um segundo, garantindo ainda uma porcentagem de reconhecimento
de aproximadamente 92%.
É importante lembrar que para que ambas as técnicas, Audio Fingerprinting e
Cross Correlation, sejam aplicadas corretamente é necessário um armazenamento prévio
em banco de dados do conteúdo original do sinal de áudio, assim como, de todos os
fingerprints previamente computados.
No trabalho apresentado por HOWSON et al (2011), intitulado Second Screen
Synchronization, é proposta uma solução para o sincronismo entre conteúdos transmitidos
32
via broadcast e broadband multicast. Utilizando-se a inserção de uma timeline nos dois
fluxos de conteúdo, é possível fazer o fino e correto sincronismo entre os mesmos. No
caso do fluxo broadcast o conteúdo da timeline é inserido na codificação MPEG2-TS da
programação a ser exibida de acordo com a especificação DVB para o envio de dados
auxiliares de sincronismo. Por sua vez, a informação de timeline no fluxo broadband não
segue qualquer especificação, sendo transmitida em conjunto com o conteúdo
complementar via RTSP (Real Time Stream Protocol).
A abordagem proposta no trabalho de HOWSON et al (2011) tem como
vantagem a adaptabilidade de uso para qualquer plataforma existente ou futura de TVD,
uma vez que a timeline necessária ao sincronismo é independente da plataforma.
Entretanto, um esforço maior é necessário para a manutenção destas timelines replicadas
e a necessidade de provedores de conteúdo de tempo real robustos num cenário real de
uso, tornando sua implantação bastante custosa e improvável.
SEGUNDO e SANTOS (2013) apresentam em seu trabalho uma solução para
a sincronização entre TV e dispositivos de Segunda Tela. A solução apresentada,
denominada Event Flow Synchronization, foi baseada no Protocolo de Sincronização de
Fluxo (Flow Synchronization Protocol) proposta por ESCOBAR; PARTRIDGE;
DEUTSCH (2002).
Este protocolo propõe calcular o atraso no recebimento de conteúdo nas duas
fontes que devem sincronizar, definindo qual dos atrasos é o maior adotando-o como
valor mínimo necessário para a sincronização dos diferentes fluxos. Uma vez que o
mesmo tempo de atraso passa a ser utilizado em ambos os fluxos as informações passam
a ser recebidas sincronizadas no destino.
É importante salientar que, para transmissões em TV digital, o atraso a ser
calculado deve levar em consideração o tempo necessário para o processamento do sinal
digital em todas as camadas do sistema da TV, incluindo os codificadores,
decodificadores e multiplexadores. Na segunda tela, o atraso deve considerar o tempo de
carregamento do conteúdo complementar, assim como a latência e banda da rede sendo
utilizada.
Uma vez que, modificar o tempo de atraso da transmissão do conteúdo televisivo
é inviável, dado que um usuário não tem acesso a fonte transmissora, em casos onde o
33
recebimento do conteúdo a ser exibido pela segunda tela é menor que o do conteúdo a ser
exibido pela TV, ou seja, o atraso da TV é maior que o da segunda tela, a proposta torna-
se inviável.
Diferentemente das propostas apresentadas anteriormente, o trabalho Synced-
DTV, proposto por este trabalho, apresenta um modelo simples e de fácil implantação que
utiliza os dados contextuais enviados pelas emissoras de televisão para a obtenção de
conteúdos complementares Web de forma síncrona utilizando uma infraestrutura de rede
local sem fio (wifi) e utilizando um dispositivo de Segunda Tela para a exibição deste
conteúdo complementar. Este modelo proposto não modifica o sinal transmitido pela
emissora nem, tampouco o conteúdo de áudio e vídeo enviado, tornando uma solução de
fácil adoção por emissoras que disponibilizam TV Digital aos seus telespectadores.
34
3 SYNCED-DTV
Uma vez descritos os conceitos relacionados às tecnologias de TV Interativa e
Segunda Tela, utilizados como fundamentação teórica para a elaboração deste trabalho,
este capítulo apresenta a metodologia de elaboração da solução proposta, intitulada de
Synced-DTV. Nele será apresentada a visão geral da proposta, descrevendo os
subsistemas que compõem a solução e suas funcionalidades, serão demonstrados alguns
cenários de uso que corroboram a aplicabilidade da solução. Posteriormente serão
descritos alguns dos principais requisitos levantados para a realização da implementação
da infraestrutura, serão apresentados o diagrama de casos de uso e a descrição detalhada
de cada um destes casos e, por fim, serão apresentadas a arquitetura adotada para a
implementação do Synced-DTV e a comparação do modelo proposto com outras
abordagens já existentes.
3.1 Visão Geral
O Synced-DTV pode ser considerado uma implementação de referência de uma
infraestrutura modular de software para TV digital híbrida, que tem por finalidade propor
uma forma contextualizada e menos invasiva de sincronismo entre o conteúdo transmitido
pela TV e conteúdos complementares oferecidos através da Internet aos telespectadores,
agregando valor à experiência televisiva do usuário.
Como forma de apresentar os conteúdos complementares advindos da Internet,
o modelo proposto utilizou websites que apresentam informações referentes à
programação oferecida por uma emissora de TV, podendo conter informações mais
detalhadas sobre os assuntos abordados pela programação da TV, descrições dos
personagens participantes do programa, cenas de um próximo capítulo ou então outros
conteúdos mais aprofundados que não puderam ser abordados devido à falta de tempo na
grade de programação. É importante ressaltar que, o conteúdo complementar
disponibilizado poderia ser de qualquer natureza que não websites, como por exemplo,
vídeos, outras aplicações de TV ou até mesmo aplicações para desktops, smartphones e
tablets.
Como a proposta deste modelo de referência é demonstrar uma forma contextual
e menos invasiva, do ponto de vista do telespectador, de agregar conteúdo complementar
Web sensível à programação corrente da TV, foi necessária a construção de uma
35
infraestrutura modular de software composta por vários subsistemas que funcionam de
maneira independente, mas que podem se comunicar através de conexões de rede. Estes
subsistemas, em conjunto, compartilham informações que possibilitam a convergência
entre o conteúdo transmitido pelo fluxo televisivo e um conteúdo complementar a ser
exibido em um dispositivo de segunda tela, como por exemplo, um smartphone ou tablet.
O modelo proposto apresenta basicamente três módulos principais, cada qual
com suas funcionalidades específicas e responsabilidades, são eles:
1- Synced-TVApp: Subsistema central da implementação de referência
responsável pela aquisição dos dados contextuais da programação da TV e
envio destas informações para a segunda tela.
2- Synced-WebServers: Subsistema responsável pelo armazenamento e
disponibilização do conteúdo complementar web para os outros módulos que
compõem o modelo.
3- Synced-SecondScreenApp: Subsistema responsável pelo processamento
contextual dos dados da TV, gerenciamento dos momentos de sincronismo
entre os conteúdos e por prover uma forma automatizada e contextualizada
para a exibição do conteúdo complementar de forma não invasiva e
personalizada.
A Figura 2 ilustra todos os subsistemas da infraestrutura de software
desenvolvida pelo trabalho projetado sobre uma infraestrutura de hardware que viabiliza
o cenário do Synced-DTV.
O subsistema residente na TV, Synced-TVApp, é responsável pela mineração dos
dados contextuais o que inclui a identificação do canal corrente, assim como a obtenção
de informações que possam identificar qual a programação sendo exibida no instante da
extração dos dados. Estas informações são disponibilizadas pelo sistema de TV Digital
(ex. SBTVD) podendo ser obtidas por meio das tabelas EIT (Event Information Table)
(NBR 15603-2, 2008) e (EN_300_468:2007, 2007) presentes em cada fluxo de
transmissão. Futuramente, no capítulo 4, será explicado o processo de captura das
informações contextuais das tabelas EIT, assim como a definição de quais destas
informações são relevantes à implementação da infraestrutura modular de software do
Synced-DTV.
36
Figura 2 - Subsistemas do cenário do Synced-DTV.
Uma vez que os dados contextuais da programação televisiva corrente estejam
disponíveis, estas informações são repassadas ao subsistema Synced-SecondScreenApp,
possibilitando a exibição dos recursos adicionais que possam ser pertinentes ao interesse
do usuário.
3.2 Cenários de Uso
Com o objetivo de enriquecer o entendimento deste trabalho, alguns cenários de
uso serão descritos, através de estórias, ilustrando a aplicabilidade do modelo Synced-
DTV no cotidiano dos usuários.
3.2.1. Cenário Um
“Anderson, um engenheiro de software de 25 anos de idade chega em sua casa
após o dia de trabalho, ativa a rede wifi do seu smartphone android, com a intenção de
receber os e-mails não lidos durante sua viagem para casa, e vai jantar. Após a refeição,
ele decide ligar sua TV Digital para assistir a telenovela, o qual, de acordo com o
horário, deve estar apenas no primeiro capítulo. Torcedor frenético do Clube Náutico
Capibaribe, sabe que após a novela será televisionado uma partida de seu time pelo
campeonato brasileiro. Estando bastante cansado da exaustiva jornada de trabalho e do
longo trajeto para casa, Anderson, decide ir descansar um pouco na sua cama até o
37
horário de início da partida, quando cai no sono. Por sorte, Anderson havia previamente
configurado a aplicação Synced-SecondScreenApp instalada em seu smartphone para
ser notificado quando transmissões esportivas estivessem sendo exibidas na TV. Assim
que a novela acaba e as informações da tabela EIT são atualizadas indicando o início da
partida, o módulo Synced-TVApp, executando na TV, notifica o subsistema Synced-
SecondScreenApp no smartphone e fazendo tocar um alarme de notificação que acordará
Anderson, possibilitando a ele assistir à partida de seu time.”
3.2.2. Cenário Dois
“Em uma quinta-feira, início da tarde, Fátima de 22 anos está em casa
estudando para as provas da faculdade que irá fazer no dia seguinte. Como principal
fonte de estudos utiliza um tablet contendo os materiais digitalizados necessários a
preparação para a prova, assim como acessa constantemente materiais complementares
em fóruns na Internet, sempre conectada pela rede sem fio de sua casa. Sua irmã, uma
criança de apenas 10 anos, passa a tarde inteira assistindo TV na sala, e para não
atrapalhar seus estudos Fátima decide ir estudar em seu quarto. Desejando saber o
momento em que o filme a ser exibido a tarde fosse começar para ir assistir juntamente
com sua irmã, ela configura a aplicação Synced-SecondScreenApp instalada em seu
tablet para ser interrompida quando um conteúdo televisivo do tipo Filme for iniciado,
porém gostaria de receber notificações para qualquer outro gênero de programação.
Desta forma poderia saber o momento em que o filme da tarde seria transmitido, assim
como também saber detalhes das programações, utilizando as URLs de conteúdo Web
complementar contextualmente extraídos pelo módulo Synced-SecondScreenApp na TV,
sua irmã mais nova está assistindo.”
3.2.3. Cenário Três
“Rodrigo, estudante de ciências políticas com 25 anos de idade, acorda cedo
todas as manhãs e assiste ao telejornal antes de sair para a faculdade. O principal motivo
de assistir ao telejornal é manter-se sempre informado sobre os acontecimentos do
cenário político brasileiro e as coligações partidárias feitas para as eleições vindouras.
Neste dia em especial houve uma entrevista ao vivo com o presidente de um dos principais
partidos para a corrida presidencialista, onde foi tratado o declínio nas últimas
pesquisas de seu candidato e os motivos para tal cenário. Devido ao tempo
disponibilizado para a entrevista pela grade televisiva, diversos pontos e
38
questionamentos ficaram inexplorados, sendo disponibilizada uma URL que
possibilitaria o envio de questionamento diretamente ao entrevistado e também a
disponibilização de informações das últimas pesquisas e dos últimos acontecimentos que
influenciaram a queda nas pesquisas“.
Analisando as estórias descritas anteriormente é possível identificar situações
em que o uso de conteúdos Web adicionais ou uma abordagem contextualizada das
informações disponibilizadas pela TV possam ser enriquecedores à experiência do
usuário, trazendo um volume maior de informações úteis ao telespectador. Observe que
a interação entre a TV e o dispositivo de segunda tela vai além da disponibilização de
conteúdos complementares, como mostrado no Cenário Um e Cenário Dois, servindo
também como intermediador do desejo do usuário por um gênero televisivo específico.
É importante perceber que a obtenção do contexto televisivo, que inclui todas as
informações necessárias para a identificação da programação sendo transmitida, é de
extrema importância e deve ser obtida da forma menos intrusiva ou imperceptível ao
usuário. Como observado no Cenário Três, caso haja a necessidade de alguma interação
complexa ou custosa do usuário para a obtenção do conteúdo complementar
disponibilizado, como por exemplo, a necessidade de copiar uma URL de acesso à
informação, poderia ocasionar um desinteresse pela obtenção da informação. Na solução
Synced-DTV aqui apresentada as informações relacionadas à programação é obtida de
forma menos intrusiva possível, assim como a obtenção do conteúdo relacionado a este
contexto pode ser facilmente acessado pelo usuário.
Outra característica explicitada pelo segundo e terceiro cenários é a possibilidade
da transmissão da informação da TV para o smartphone, pois, em alguns ambientes, a TV
como uma é utilizada ferramenta coletiva de entretenimento, e a intenção de interação
com as aplicações podem ser despertadas em apenas um usuário, ou até mesmo a intenção
pode ser de vários usuários, mas com intenções distintas.
3.3 Levantamento dos requisitos
As subseções a seguir apresentam alguns requisitos funcionais e não funcionais
à implementação de uma solução de compartilhamento contextual de informações entre
a plataforma de TVs híbridas, o uso de dispositivos de segunda tela e a comunicação entre
39
eles. Estes requisitos elucidam desde a obtenção dos dados contextuais da tabela EIT da
programação corrente até o carregamento das informações advindas da Web do conteúdo
complementar. Estas subseções elucidam alguns dos requisitos mandatórios observados
durante a implementação do Synced-DTV.
3.3.1. Requisitos Funcionais
A seguir serão listados os requisitos funcionais (RFs), sendo categorizados em
três módulos: RF-TV requisitos funcionais do módulo da TV (Synced-TVApp), RF-WS
requisitos funcionais do módulo provedor dos conteúdos complementares (Synced-
WebServers), RF-AA requisitos funcionais do módulo móvel (Synced-
SecondScreenApp).
Os requisitos funcionais do módulo da TV são:
RF-TV.1 – Fornecer um serviço responsável por realizar a captura das
informações contextuais da TV de forma não invasiva;
RF-TV.2 – Fornecer um serviço responsável pela validação,
armazenamento e processamento das informações contextuais da TV;
RF-TV.3 – Fornecer um serviço responsável pela geração de uma
estrutura de dados contendo as informações contextuais obtidas;
RF-TV.4 – Fornecer um serviço responsável pela obtenção dos
parâmetros de conexão necessários para a transmissão dos dados
contextuais;
RF-TV.5 – Fornecer um serviço responsável pelo estabelecimento das
conexões e consequentemente envio das informações contextuais aos
dispositivos de segunda tela;
Os requisitos funcionais do módulo dos WebServers são:
RF-WS.1 – Fornecer um serviço responsável pelo armazenamento dos
recursos referentes a cada um dos programas do canal de uma emissora;
RF-WS.2 – Fornecer um serviço responsável pela disponibilização de
transmissão dos recursos relacionados à programação para a TV;
40
Os requisitos funcionais do módulo de Segunda Tela são:
RF-AA.1 – Fornecer um serviço responsável pela captura dos dados
contextuais enviados pelo módulo da TV.
RF-AA.2 – Fornecer um serviço responsável pela interpretação e
validação dos dados contextuais enviados pelo módulo da TV.
RF-AA.3 – Fornecer um serviço responsável pelo sincronismo na
exibição dos conteúdos complementares.
RF-AA.4 – Fornecer um serviço responsável pela decisão das formas de
interação e exibição dos conteúdos complementares.
3.3.2. Requisitos Não Funcionais
Abaixo estão listados os principais requisitos não funcionais (RNF) tomados
para o desenvolvimento do modelo proposto.
RNF.1 – Desenvolver uma arquitetura de software que disponibilize
módulos de suporte à execução de aplicações sensíveis ao contexto para
TVs Híbridas fornecendo aos usuários conteúdos complementares
obtidos na Internet associados à programação broadcast;
RNF.2 – A solução proposta deve ser desenvolvida estando de acordo
com as especificações do Sistema Brasileiro de TV Digital (SBTVD);
RNF.3 – Especificar uma estrutura de dados simplificada porém
completa para a transmissão dos dados contextuais da programação da
TV ao dispositivo de segunda tela.
RNF.4 - Utilizar as informações contextuais do telespectador, tanto da
TV quanto da aplicação no dispositivo móvel, para a tomada de decisão
de quais ações devem ser realizadas durante o sincronismo entre os
módulos do sistema;
RNF.5 – Realizar a medição do esforço necessário a mineração dos dados
do contexto até a chegada e tratamento no dispositivo de segunda tela;
41
RNF.6 – Realizar um estudo de usabilidade buscando refinar os
parâmetros utilizados no algoritmo de temporização do sincronismo;
RNF.7 - A solução proposta deverá ser independente do sistema
operacional embarcado na plataforma de execução, sendo necessário
apenas que o módulo da TV deverá funcionar sobre o middleware Ginga,
os servidores Web sobre a máquina virtual Java, o canal de troca dos
dados contextuais utilizará o protocolo UDP (broadcast de rede) e o
módulo móvel executará sobre a plataforma Android.
3.4 Diagrama dos Casos de Uso
Uma vez levantados os requisitos demonstrados na seção anterior, foram
definidos alguns casos de uso baseados na linguagem UML, descrevendo as principais
funcionalidades do modelo e a interação dessas funcionalidades com os usuários do
sistema, ou seja, aborda em um nível maior de abstração as interações entre usuários
externos e o sistema. A seguir são descritos os principais atores presentes no Synced-
DTV:
Usuário: Representa a entidade que interage com a TV e com a aplicação
no dispositivo móvel, com o intuito de permitir e consumir os recursos
contextualizados com a programação;
Provedor de Conteúdo Web: Corresponde à entidade que é responsável
por armazenar e disponibilizar todos os recursos Web relacionados à
programação;
Transmissora: Corresponde à entidade responsável pelo envio do fluxo
de áudio e vídeo, assim como dos dados contextuais sobre a programação
transmitida para a TV via canal broadcast. Um provedor de serviço, no
contexto de TV aberta, pode ser informalmente conhecido como
emissora de TV.
A
42
Figura 3 a seguir representa um diagrama geral dos casos de usos que ilustra os
principais casos especificados para a infraestrutura deste trabalho.
Figura 3 - Diagrama de casos de uso nível zero do Synced-DTV.
3.5 Descrições dos Casos de Uso
As tabelas a seguir descrevem os principais casos de uso analisados durante o
desenvolvimento da solução, considerando a forma como o usuário interage com os
módulos da solução.
A Tabela 2 a seguir define o caso de uso que descreve o caso de uso “Configurar
a TV”.
43
Tabela 2 – Configurar a TV
Caso de Uso: 01 Configurar a TV
Ator Usuário.
Descrição
O usuário deve habilitar, através do menu de configuração da
TV, a propriedade que torna possível a execução automática de
aplicativos interativos recebidos pelo fluxo televisivo.
Evento Iniciador Configuração da TV
Pré-condição Nenhuma.
Pós-condição Execução automática de aplicações interativas.
Extensões Não há extensões.
Inclusões Caso de uso “Obter Dados Contextuais”, “Validar Dados
Contextuais” e “Enviar Dados Contextuais”.
A Tabela 3 a seguir define o caso de uso que descreve o caso de uso “Obter
Dados Contextuais”.
Tabela 3 – Obter Dados Contextuais
Caso de Uso: 02 Obter Dados Contextuais
Ator Usuário.
Descrição
A aplicação Synced-TVApp captura de forma implícita as
informações contextuais da programação sendo atualmente
exibida na TV, como o nome, horários e descrição.
Evento Iniciador Solicitação do conteúdo complementar pela aplicação.
Pré-condição
Aplicação Connected-TVApp em execução na TV, programação
digital com os dados das tabelas de informação de serviço e
eventos disponíveis.
Pós-condição Captura das informações contextuais da programação da TV
advindas das tabelas de informação de serviço (SI) e eventos
44
(EIT), utilizados posteriormente para o sincronismo do
dispositivo de segunda tela.
Extensões Não há extensões.
Inclusões Não há inclusões.
A Tabela 4 a seguir define o caso de uso que descreve o caso de uso “Validar
Dados Contextuais”.
Tabela 4 – Validar Dados Contextuais
Caso de Uso: 03 Validar Dados Contextuais
Ator Usuário.
Descrição
Validações sobre duplicidade e não conformidades dos dados são
executadas. Se os dados estiverem corretos, um JSON é criado
contendo as informações para posterior envio.
Evento Iniciador Solicitação do conteúdo complementar pela aplicação.
Pré-condição
Aplicação Connected-TVApp em execução na TV, programação
digital com os dados das tabelas de informação de serviço e
eventos já capturados e armazenados.
Pós-condição
Dados validados e tratados para o envio ao dispositivo de
segunda tela, ou dados descartados por serem ou inválidos ou
incompletos ou repetidos.
Extensões Não há extensões.
Inclusões Não há inclusões.
As descrições de caso de uso que não foram explanadas nesta seção podem ser
encontradas no APÊNDICE I
deste trabalho.
45
3.6 Arquitetura
Esta seção apresenta a arquitetura adotada para a implementação do modelo
proposto por este trabalho, apresentando detalhes da aplicação Synced-TVApp, que
executa na TV e que é considerada o módulo principal da solução por ser responsável
pela obtenção e gerenciamento dos dados contextuais, e da aplicação Synced-
SecondScreenApp, aplicação que executa no dispositivo de segunda tela.
A arquitetura utilizada para a implementação do modelo de comunicação entre
este módulo da proposta e o módulo no dispositivo de segunda tela, representado pela
aplicação Synced-SecondScreenApp, é a de cliente-servidor, pois o módulo residente na
TV se comporta como um servidor sendo responsável pelo envio e gerenciamento dos
dados contextuais e a aplicação móvel como cliente, recebendo estes dados, processando
e exibindo ao usuário.
3.6.1. Synced-TVApp
A arquitetura em camadas utilizada para o desenvolvimento do Synced-DTV
apresenta apenas dois módulos, Controller e Model, uma vez que não há a necessidade
de uma camada de UI, onde seria mais aconselhada a utilização de um padrão MVC. Esta
arquitetura foi escolhida pois concede um baixo acoplamento do código gerado,
mantendo a organização e proporcionando também uma melhor manutenção menos
dispendiosa dos componentes do software.
A Figura 4 a seguir demonstra a arquitetura adotada na construção da Synced-
TVApp.
Figura 4 - Arquitetura da aplicação Synced-TVApp
46
Na camada de Controller encontram-se as classes responsáveis pelo controle do
ciclo de vida da aplicação, representada pela classe XletMain. Esta classe é executada,
como falado anteriormente no caso de uso “Configurar a TV”, quando a aplicação é
recebida e instalada na TV. Nesta camada também se encontra o ServiceManager, módulo
responsável pelo gerenciamento das conexões de envio dos dados contextualizados para
os dispositivos de segunda tela.
A camada de Model é a responsável pelo controle e manipulação de dados, desde
o momento da garantia de acesso de leitura (processo de lock) à tabela IET para a
aquisição dos dados contextuais da programação corrente. Este processo de lock para a
obtenção dos dados é feito pela classe SIServiceHandler.
Uma vez que os dados podem ser acessados, a classe SIServiceProvider recupera
e armazena os dados contextuais da programação corrente da tabela, repassando essas
informações ao módulo NetworkDataService que é o responsável por realizar o envio da
informação via broadcast para o módulo Synced-SecondScreenApp.
3.6.2. Synced-SecondScreenApp
A arquitetura utilizada para o desenvolvimento do Synced-SecondScreenApp
segue os princípios do modelo MVC (Model View Controller). Na camada de View
contém as classes responsáveis pela criação do wizard inicial da aplicação, onde o usuário
47
define as suas preferências de conteúdo, e também a implementação necessária para a
exibição do conteúdo Web complementar.
Na camada de Model estão dispostas as classes responsáveis pelo
armazenamento, validação, normalização e disponibilização dos dados complementares
recebidos. Esta camada recebe inicialmente um JSON bruto enviado pela aplicação
Synced-TVApp, valida, extrai, normaliza os dados temporais dos pontos de sincronismo e
disponibiliza estes dados para a camada de controle.
A camada de Controller contém a classe ConnectionService, que é uma classe
do tipo Service do android, responsável por gerenciar o estabelecimento de conexões para
o recebimento dos dados contextuais da TV, assim como um módulo de suporte a este
Service, implementado utilizando BroadcastReceiver, representado pela classe
ConnectionBroadcastReceiver, capaz de identificar o status de conectividade de rede do
dispositivo, logo, sempre que é identificado que o usuário se conectou a uma rede wifi, o
BroadcastReceiver verifica a rede e inicializa o serviço possibilitando conexões serem
estabelecidas.
Outra atribuição da camada Controller é o processo de descobrimento do que o
usuário está fazendo no momento do recebimento do conteúdo da TV, sendo esta
informação levada em consideração na tomada de decisão na interrupção ou notificação
da chagada de dados novos ao usuário.
A Figura 5 a seguir ilustra a arquitetura adotada na construção da aplicação
Synced-SecondScreenApp:
Figura 5 - Arquitetura da aplicação Synced-SecondScreenApp
48
3.7 Comparação com Modelos de TV e Tecnologias de Sincronismo
No capítulo 2, foram descritos alguns modelos de TV Digital, assim como
algumas das tecnologias atualmente disponíveis para realização do sincronismo entre a
programação transmitida pelo fluxo televisivo e os conteúdos complementares
comumente disponibilizados pela web. Buscando comparar a arquitetura definida para a
implementação do processo de sincronismo dos dados contextuais do Synced-DTV com
as de outras soluções e abordagens descritas no capítulo 2, alguns critérios foram
levantados, levando-se em consideração o esforço para a adoção de uma destas propostas
num cenário realístico de uma emissora TV aberta.
Os critérios definidos para a comparação são:
1. Recursos Externos Necessários: Critério que considera a necessidade
de recursos de hardware externos exclusivamente para a implantação
da proposta, como por exemplo, servidores para processamento de
arquivos de mídia.
2. Complexidade de Desenvolvimento da Solução: Critério que
considera o esforço computacional necessário para a implantação de
49
uma solução, considerando a necessidade de criação de algoritmos
específicos.
3. Manipulação do Conteúdo de Mídia Original: Critério que
evidencia a necessidade de modificação do arquivo de mídia original
para a implantação da solução.
4. Facilidade de Uso: Critério que considera a dificuldade e o esforço
necessário durante o processo de sincronismo da aplicação do pondo
de vista do usuário.
5. Confiabilidade no Sincronismo: Critério que avalia a confiabilidade
do sincronismo da solução, seja durante o processo de captura dos
pontos de sincronismo, ou pelo atraso na exibição dos dados
contextuais.
A Tabela 5 abaixo demonstra o desempenho dos modelos e tecnologias
propostas no capítulo 2 utilizando o conjunto de critérios definido anteriormente.
Tabela 5 - Fatores de comparação
Solução Recursos
Necessários
Complexidade de
desenvolvimento
da Solução
Manipulaçã
o do
Conteúdo
de Mídia
Original
Facilid
ade de
Uso
Confiabilid
ade no
Sincronism
o
Audio Fingerprinting Sim Alta Sim Médio Médio
Audio Watermarking Sim Alta Sim Médio Médio
50
Video Recognition
Sim Alta Não Baixa Baixo
Local TV
Synchronization
Não Baixa Não Alta Alto
Internet
Synchronization
Não Baixa Não Alta Alto
Quando levado em consideração a necessidade de recursos externos para o
funcionamento da solução as técnicas de Audio Fingerprinting, Audio Watermarking e
Video Recognition claramente necessitam de servidores externos remotos para o
processamento necessário à identificação do fluxo televisivo e posterior sincronização.
Na técnica de Local TV Synchronization o uso de servidores externos para o sincronismo
não é necessário uma vez que a informação necessária para o sincronismo pode ser
enviada juntamente com o fluxo de mídia e no caso da Internet Synchronization o
conteúdo complementar é disponibilizado em tempo “real” com a programação exibida.
O segundo critério a ser considerado mostra a complexidade de implementação
de uma solução utilizando as técnicas demonstradas. Neste critério, mais uma vez, as
técnicas de Audio Fingerprinting, Audio Watermarking e Video Recognition demonstram
ser mais complexos, em grande parte, pela necessidade de desenvolvimento de um
algoritmo específico para o reconhecimento e sincronização das mídias. Nas outras
técnicas este artifício não é necessário pois o processo de sincronismo acontece através
de outros mecanismos.
O terceiro critério aborda a necessidade de manipular o conteúdo de mídia
original buscando inserir informações necessárias ao correto sincronismo entre o fluxo
televisivo e o conteúdo de segunda tela. Nas técnicas de Audio Fingerprinting e Audio
Watermarking este tipo de abordagem é necessária, como explicado no capítulo 2. As
51
outras técnicas descritas utilizam formas de sincronismo menos invasivas, tornando
dispensável a manipulação da mídia original.
A Facilidade de Uso, abordado no quarto critério da tabela, faz referência ao
esforço necessário ao usuário para que o sincronismo possa acontecer. Nas técnicas de
Local TV Synchronization e Internet Synchronization apresentam uma abordagem mais
satisfatória neste quesito, especialmente por não necessitar de interações constantes do
usuário, ou estão suscetíveis a falhas no sincronismo devido a ruídos ou má captura dos
frames do vídeo da programação.
Por fim, o ultimo critério aborda a confiabilidade do sincronismo gerado pela
solução, considerando todos os fatores exógenos que podem interferir no processo de
sincronização como, por exemplo, latência de Internet, processamento necessário para a
geração e/ou identificação dos pontos de sincronismo e as dependências, e possíveis
interferências, das soluções externas obrigatórias a execução de uma técnica. Neste
quesito, a técnica de Local TV Synchronization mostrou-se a mais satisfatória por não
apresentar dependências com serviços externo, dependendo assim apenas das
informações contextuais da TV e do inevitável carregamento do conteúdo web
complementar. A solução de Internet Synchronization, uma vez que contemplada da
forma correta, também tem o potencial de exibir uma ótima qualidade no sincronismo dos
conteúdos, uma vez que o mesmo provedor seria o responsável por gerenciar o envio
síncrono de ambos.
3.8 Discussões
Este capítulo apresentou detalhes sobre a elaboração do Synced-DTV como uma
proposta de solução para a sincronização de conteúdos complementares, através do uso
de informações contextuais da programação corrente, em ambientes de TV híbrida. Para
isto, a extração dos dados de alguns campos obrigatórios e opcionais da tabela SI do
SBTVD é essencial na obtenção dos pontos de sincronismo entre os conteúdos, assim
como das URLs de acesso ao conteúdo web complementar a programação atualmente
transmitida pela TV.
Foram apresentadas as arquiteturas das aplicações Synced-TVApp, Synced-
WebServers e Synced-SecondScreenApp que podem ser utilizadas como referências para
a implementação de qualquer outra solução de sincronismo de conteúdos de TV digital
52
híbrida, pois apresentam uma disposição modular e bem construída, podendo ser
estendida ou utilizada como base para o desenvolvimento de qualquer aplicação de
propósito semelhante.
53
4 Implementação da Solução
No capítulo anterior foram descritos detalhes sobre a elaboração dos requisitos
funcionais, bem como da arquitetura do Synced-DTV, além de uma visão geral da solução
proposta por este trabalho.
Este capítulo será focado na apresentação da implementação, execução e
validação das arquiteturas dos módulos que compõem a solução proposta por este
trabalho. Será explanada a forma proposta para o envio dos dados contextuais de
sincronismo com a segunda tela, assim como todos os artifícios utilizados para o
desenvolvimento dos módulos Synced-WebServers, Synced-TVApp e Synced-
SecondScreenApp. Também serão apresentados os resultados dos testes de desempenho
e aceitação realizados para a validação da estrutura do modelo proposto. Por fim, serão
abordadas a dificuldades encontradas e soluções adotadas, restrições tecnológicas, os
ambientes de software utilizados e as considerações finais do trabalho.
4.1 Sincronismo com Segunda Tela
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
54
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;
55
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.
56
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.
4.2 Synced-WebServers
O subsistema Synced-WebServers é responsável pelo armazenamento, controle
e disponibilização na web do conteúdo complementar consumido durante o processo de
sincronismo com a programação da TV. Este módulo tem relacionamento direto com a
aplicação Synced-SecondScreenApp que será explicado posteriormente.
Para a realização de um teste mais realístico, três servidores foram montados,
cada um responsável pelo armazenamento do conteúdo web contextual de um canal
televisivo específico. É importante salientar que a criação de um servidor específico para
cada programação de cada uma das emissoras tornaria a implementação dos servidores
muito custosa, por isto da decisão de criar um servidor para cada canal televisivo.
Então, por exemplo, para acessar a programação contextual de uma novela para
um determinado canal a URL seria: http://www.synced.com/novela. Enquanto para
acessar o conteúdo contextual referente a um programa jornalístico seria
http://www.synced.com/jornal. Este tipo de abordagem facilita a construção do conteúdo
a ser enviado da aplicação Synced-TVApp para a aplicação móvel Synced-
57
SecondScreenApp, uma vez que uma URL base pode ser adotada, diminuindo o tamanho
da informação a ser repassada entre as aplicações.
4.3 Synced-TVApp
O módulo Synced–TVApp é o subsistema da arquitetura Synced-DTV que
executa na TV. A função deste modulo é a obtenção do conteúdo contextual da
programação da TV, a validação desses dados e o envio via broadcast de rede, entre a
TV e a Segunda Tela, dessas informações na forma de um documento JSON para o
módulo Synced-SecondScreenApp.
4.3.1. Implementação da Arquitetura
A Figura 6, a seguir, representa o diagrama de classes da Synced-TVApp,
exibindo as classes do sistema, assim como o relacionamento entre elas.
Figura 6 - Diagrama de classes da aplicação Synced-TVApp
58
É importante observar que, como descrito na seção 3.6.1, não há classes para a
exibição de conteúdos no diagrama apresentado, sendo este um dos principais requisitos
deste módulo, a execução silenciosa, onde não há necessidade de interação para a
execução ou configuração da aplicação.
A classe XletMain é responsável por controlar todo o ciclo de vida da aplicação
para TV Digitals, chamado de Xlet, onde se encontra a instância do XletContext que é
responsável por monitorar todas as vezes em que o estado do Xlet é modificado. Outra
atribuição da classe XletMain é a inicialização da thread, representada pela classe
RemindTask, responsável pela captura das informações contextuais da programação. Esta
59
thread executa a cada cinco segundos e é iniciada assim que o Xlet é instalado e executado
como ilustrado no código abaixo.
// Initialize the xlet. public void initXlet(XletContext context) {
System.out.println("##initXlet called ##");
this.context = context;
serviceManager = ServiceManager.getInstance();
timer = new Timer();
}
// Start the xlet.
public void startXlet() {
System.out.println("################### startXlet called
############################");
timer.schedule(new RemindTask(),
Constants.SECONDS_TIMER_CHECK * 1000);
}
Uma vez iniciada a thread, o processo de captura dos dados contextuais da
programação pode ser feito. Para que haja uma captura eficiente dos dados da tabela e a
detecção da alteração destes dados, a thread RemindTask é executada a cada 5 segundos,
valor este escolhido por proporcionar a rápida detecção na alteração do conteúdo sem
sobrecarregar o processamento da TV. O processo de captura de informações dos dados
contextuais da tabela EIT é ilustrado a seguir pelo diagrama de sequência na Figura 7.
Figura 7 - Diagrama de sequência da captura de dados da TV.
60
A cada interação da thread a classe ServiceManager, do pacote
“br.ufpe.cin.ragpf.contextualginga.controller” é requisitada a iniciar o processo de
captura dos metadados das tabelas contextuais. Agindo como o controlador da
arquitetura, esta classe contém os métodos responsáveis por solicitar à camada de Modelo
da solução a execução dos serviços necessários para obter as informações que serão
enviadas a aplicação Synced-SecondScreenApp. Na classe ServiceManager encontram-se
os métodos getCurrentEvent e sendBroadcastDataToMobile (String data) responsáveis
por obter uma instância válida do evento corrente na TV e enviar este conteúdo obtido à
Synced-SecondScreenApp, respectivamente.
Os pacotes “br.ufpe.cin.ragpf.contextualginga.model” e
“br.ufpe.cin.jss.connectedginga.net” formam a camada de Modelo (Model) da
arquitetura. Esta camada é formada pelas classes que fornecem os serviços solicitados
pela camada de controle da Connected-TVApp. O pacote
“br.ufpe.cin.jss.connectedginga.net” contém a classe Connection que é responsável por
61
controlar o envio dos dados contextuais da programação para o módulo Synced-
SecondScreenApp. Esta classe é acessada diretamente pela camada Controller quando o
usuário solicita o envio dos dados ao dispositivo móvel. Nesta ocasião o método
sendBroadcast(String dataSend) é chamado. O envio destes dados é realizado através de
uma conexão por broadcast como ilustrado no trecho de código abaixo.
public void sendBroadCast(String sendData) throws IOException {
System.out.println("## sendBroadCast ##");
ArrayList list = getBroadcastAddresses();
for (int i = 0; i < list.size(); i++) {
DatagramSocket c = new DatagramSocket();
InetAddress inet = InetAddress.getByName((String)
list.get(i));
DatagramPacket p = new
DatagramPacket(sendData.getBytes(), sendData.getBytes().length,
inet, Constants.BROADCAST_PORT);
c.setReuseAddress(true);
c.send(p);
c.close();
}
System.out.println("## sendBroadCast close ##");
}
Observe que, uma vez que não há como identificar corretamente qual das
interfaces de rede ativas e disponíveis está sendo utilizadas para a conexão sem fio (wifi),
todas as interfaces de rede recebem o conteúdo dos dados contextuais da programação.
Esta é uma deficiência tanto da versão do java utilizado pelo Ginga-J quanto da API Ginga
disponibilizada.
4.3.2. Formatação dos dados contextualizados
Para o correto funcionamento do sincronismo entre os conteúdos web e
televisivo, algumas informações importantes sobre a programação corrente precisam ser
coletadas, como por exemplo, o nome, gênero, horário de início e duração. Estas
informações são necessárias tanto para o cálculo dos pontos de sincronismo, no caso dos
dados temporais, quanto para a tomada de decisão durante a avaliação dos critérios de
interrupção e notificação ao usuário.
A aquisição dessas informações é possível a partir de um objeto SIEvent
retornada pelo ServiceManager à uma chamada ao Service Provider. A interface SIEvent
62
é disponibilizada pela API do Ginga-J e tem como responsabilidade indicar um programa
especifico no serviço da TV. Segundo NBR 15606-4(2010), cada objeto que implementa
a interface SIEvent é identificado pela combinação do original_id, transport_stream_id,
service_id e event_id, sendo único para cada programa da grade.
Objetos que implementam esta interface disponibilizam métodos públicos de
acesso ao conteúdo contextual da programação, métodos estes utilizados para a formação
de um JSON com todas as informações relevantes ao sincronismo, como mostrado no
exemplo de código abaixo.
private String getJsonFromEvent(SIEvent event) {
System.out.println("##getJsonFromEvent ##");
String jsonResult = null;
if (siEvent.getLevel1ContentNibbles() != null) {
jsonResult = loadJsonData(event.getName(),
getHexString(event.getLevel1ContentNibbles()),
System.currentTimeMillis(), event.getStartTime().getTime(),
event.getDuration(), getSyncEvents());
}
return jsonResult;
}
private String getSyncEvents() {
String syncEvents = null;
if (siEvent.getExEventInformations() != null &&
siEvent.getExEventInformations().length > 0) {
for (int h = 0; h <
siEvent.getExEventInformations().length; h++) {
if (siEvent.getExEventInformations()[h].getName()
.equals(Constants.STR_SYNC_POINTS)) {
syncEvents =
siEvent.getExEventInformations()[h].getDescription();
}
strBuffer.append("SI EX Information: getName:" + "["
+ h + "]" + siEvent.getExEventInformations()[h].getName() + "\n");
strBuffer.append("SI EX Information:
getDescription:" + "[" + h + "]" +
siEvent.getExEventInformations()[h].getDescription()
+ "\n");
}
} else {
strBuffer.append("SIEXInformation : 0 ou NULL \n");
}
return syncEvents;
}
63
Uma vez coletados todos os dados contextuais inerentes ao sincronismo, um
objeto JSON é criado para ser enviado via broadcast par ao modulo Synced-
SecondScreenApp. O trecho de código abaixo mostra como o método loadJsonData, após
receber os dados contextuais da programação, forma o objeto JSON final para ser enviado
ao módulo Synced-SecondScreenApp.
public String loadJsonData(String name, String genre, long
currentTime, long initialTime, long programDuration, String
syncpoints) {
System.out.println("##################### loadJsonData
#######################################");
strBuffer = new StringBuffer("");
strBuffer.append("{ \"ProgramInfo\": {");
strBuffer.append(" \"Name\":\"" + name + "\",");
strBuffer.append(" \"Genre\":\"" + genre + "\",");
strBuffer.append(" \"CurrentTime\":\"" + currentTime +
"\",");
strBuffer.append(" \"ProgramInitialTime\":\"" + initialTime
+ "\",");
strBuffer.append(" \"ProgramDuration\":\"" + programDuration
+ "\"");
if (syncpoints != null) {
//Normaliza o JSON recebido pelo TS
String temp = syncpoints;
syncpoints = temp.substring(temp.indexOf("{")+1,
temp.lastIndexOf("}"));
strBuffer.append(",");
strBuffer.append(syncpoints);
}
strBuffer.append(" }");
strBuffer.append(" }");
System.out.println("json = " + strBuffer.toString());
return strBuffer.toString();
}
A correta formatação deste JSON é crucial ao funcionamento de todo o sistema,
uma vez que, se alguma informação estiver faltando ou o JSON for criada de forma
errada, a aplicação mobile não poderá interpretar corretamente os dados, comprometendo
a normalização dos dados temporais para o sincronismo dos conteúdos e afetará o
algoritmo responsável pela tomada de decisão da interrupção e notificação do usuário.
64
4.4 Synced-SecondScreenApp
Subsistema desenvolvido para executar no dispositivo de segunda tela. É
importante observar que a escolha pela plataforma Android foi dada pela grande
abrangência e pelo grande crescimento desta plataforma no cenário mundial de aparelhos
móveis, sendo esta mesma solução passível de ser implementada em qualquer outra
plataforma disponível como IOS ou Windows Phone.
Algumas das mais importantes funcionalidades do sistema são delegadas a este
modulo, como por exemplo, a exibição do conteúdo contextual web, normalização e
agendamento dos pontos de sincronismo e a lógica responsável por definir a forma com
a qual o usuário irá receber os dados contextuais provenientes da TV. Para a solução
proposta, apenas uma forma de transmissão de dados foi implementada, porém a forma
como a transmissão deve acontecer pode ser feita de várias formas, ficando a cargo do
desenvolvedor decidir qual a abordagem que se adequa melhor a sua necessidade.
O diagrama de classes da Figura 8 a seguir mostra as principais classes do
sistema e as interações e dependências entre elas.
Figura 8 - Diagrama de classes da aplicação Synced-SeconScreenApp.
65
A classe MainActivity representa a tela inicial da aplicação. Nela é exibida uma
lista com todos os gêneros de programação especificados em (NBR 15603-2, 2008). Para
cada gênero é permitido ao usuário definir qual a forma de interrupção será executada
caso ponto de sincronismo para o escolhido gênero seja recebido pela aplicação. A Figura
9 a seguir mostra a estrutura visual dessa classe.
Figura 9 - Estrutura visual da aplicação
Esta classe também dá acesso a uma forma mais específica de controle de
interrupção, onde, uma vez que o usuário defina a opção de Interromper para algum dos
gêneros disponibilizados, uma outra opção de configuração é habilitada, possibilitando
ao usuário definir quais aplicativos instalados serão consideradas exceções a interrupção.
Neste caso, caso um ponto de sincronismo seja recebido para um gênero e uma aplicação
escolhida como exceção estiver em execução no momento do sincronismo a interrupção
não será efetivada, apenas uma notificação irá ocorrer. O trecho de código a seguir mostra
como a chamada que permite essa nova configuração é realizada.
btnSetting.setOnClickListener(new View.OnClickListener()
{
@Override
public void onClick(View arg0)
{
66
Intent = new Intent(MainActivity.this,
GenrePreferenceActivity.class);
intent.putExtra(Util.GENRE_PREFERENCE_EXTRA,
genres.get(0).getPackageList());
startActivityForResult(intent, REQUEST_CODE);
}
});
A chamada de criação da nova tela é feita através de uma chamada a
startActivityForResult, o que indica a necessidade da nova tela retornar informações sobre
o processamento realizado. No caso, este retorno é capturado pelo método
onActivityResult, definido para ser notificado ao fim da execução da tela chamada com
ilustra o código abaixo.
protected void onActivityResult(int requestCode, int resultCode,
Intent data) {
super.onActivityResult(requestCode, resultCode, data);
Log.e(TAG, "onActivityResult - " + requestCode + " - " +
resultCode + " - " + data);
if (requestCode == REQUEST_CODE)
{
if (resultCode == RESULT_OK)
{
applicationExceptions =
data.getStringExtra(Util.GENRE_PREFERENCE_EXTRA);
//save on db new exceptions
genres.get(0).setPackageList(applicationExceptions);
mDatabaseHelper.updateGenre(genres.get(0));
}
else
{
Log.e(TAG, "onActivityResult - RESULT_ERROR");
}
}
}
Uma vez configuradas as formas de notificação para os gêneros e as exceções de
interrupção, a aplicação é finalizada e um serviço, objeto Service em Android, é
inicializado, representado pela classe ConnectionService. Um serviço é um componente
de aplicação capaz de executar longos processamentos em background e não contém
interface gráfica.
67
O diagrama de sequência da Figura 10 a seguir ilustra as etapas no processo de
configuração e inicialização do serviço de conexão da aplicação.
Figura 10 - Diagrama de sequência do serviço de conexão.
A classe ConnectionService tem como grande responsabilidade o
estabelecimento de conexões e posterior recebimento dos dados contextuais enviados
pelo módulo Synced-TVApp. Para isto é implementada uma técnica de pooling de
conexão, onde o objeto capaz de realizar a conexão fica “escutando” a rede numa
determinada porta específica a espera do recebimento dos dados. Este pooling de conexão
continua ativo sempre que o dispositivo de segunda tela possua uma conexão wifi
habilitada e conectada. O código a seguir mostra o funcionamento do pooling e a forma
como os dados contextuais é recebido.
DatagramSocket serverSocket = null;
try {
68
serverSocket = new DatagramSocket(Util.PORT);
byte[] receiveData = new byte[Util.DATA_LENGTH];
while (mWifiManager.isWifiEnabled()) {
try {
receiveData = new byte[Util.DATA_LENGTH];
DatagramPacket receivePacket = new
DatagramPacket(receiveData, receiveData.length);
Log.e(TAG, "Waiting for datagram packet");
serverSocket.setSoTimeout(Util.DATAGRAM_TIMEOUT);
serverSocket.setReuseAddress(true);
serverSocket.setBroadcast(true);
serverSocket.receive(receivePacket);
String sentence = new String(receiveData).trim();
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
Log.e(TAG, "From: " + IPAddress + ":" + port);
Log.e(TAG, "Message: " + sentence);
Message message = mHandler.obtainMessage();
message.obj = sentence;
message.what = STATUS_OK;
mHandler.sendMessage(message);
}
catch (IOException e)
{
Log.e(TAG, "IOException", e);
}
}
A constante Util.PORT especifica qual a porta está sendo “escutada” para que o
recebimento dos dados contextuais seja possível e deve coincidir com a porta definida
pelo módulo Synced-TVApp. Para a implementação desta solução esta constante é
definida como:
public static final int PORT = 7654;
O método receive da classe DatagramSocket é responsável pelo recebimento
dos dados contextuais. Este método, pela API, é definido como um método bloqueante,
onde a sua execução é condicionada ao estabelecimento da conexão ou a uma exceção
lançada caso um timeout de conexão seja lançada.
69
Uma vez recebida a informação, ela deve ser exatamente equivalente a
mensagem enviada pelo modulo Synced-TVApp, possibilitando que o tratamento das
informações seja executado de forma correta e os pontos de sincronismo gerados de forma
apropriada. O documento JSON recebido deve seguir a estrutura semelhante ao exemplo
abaixo.
{
"ProgramInfo": {
"Name": "Mais Voce",
"Genre":"0x6",
"CurrentTime":"3282986312986",
"ProgramInitialTime":"9874938739847",
"ProgramDuration":"090909098808",
"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"}
]
}
}
O exemplo acima demonstra quais os dados são essenciais para que a proposta
deste trabalho possa ser aplicada. São eles:
1. Name: Nome da programação sendo exibida.
2. Genre: Gênero da programação, seguindo o padrão especificado na norma.
3. CurrentTime: Horário atual da TV, em milissegundos.
4. ProgramInitialTime: Horário indicado na tabela EIT como sendo o do início
da programação atual.
5. ProgramDuration: Duração da programação, em milissegundos.
6. Syncpoints: Especificação dos pontos de sincronismo com os dados
contextuais web.
A utilização e relevância destes campos serão explanadas com maior
abrangência em seções posteriores, onde serão abordadas as necessidades de validação
contextual do gênero televisivo e dos tempos para o calculo dos momentos de
sincronismo.
70
Uma vez recebido o JSON pela classe ConnectionService, o processo
de análise dos critérios de interrupção e gerenciamento dos pontos de
sincronismo é delegado para a classe ParseJsonService. Como dito
anteriormente, esta classe contém os métodos responsáveis por realizar a
análise do documento JSON, verifica a ação a ser realizada de acordo com o
gênero e agenda os alarmes, objetos do tipo Alarm em Android, que farão o
sincronismo dos conteúdos contextuais.
O diagrama de sequência da
Figura 11 a seguir mostra o fluxo de execução desde o momento do
recebimento dos dados da TV até o momento do sincronismo do conteúdo.
Figura 11 - Diagrama de sequência do sincronismo dos dados.
71
Observe que, como mostrado no diagrama acima, uma vez que os dados
contextuais são recebidos, uma serie de processamentos são executados antes do
sincronismo esteja apto a acontecer. Inicialmente o gênero é extraído e validado de acordo
com as escolhas do usuário para este determinado gênero. Logo após os outros dados são
“parseados” e os tempos recebidos normalizados. Com os dados temporais normalizados,
os alarmes podem ser agendados de forma correta.
Quando um desses alarmes dispara, um componente do android denominado
BroadcastReceiver do tipo ScheduleAlarmreceiver é invocado, fazendo a chamada para
a inicialização da classe WebActivity que exibirá ou notificará acerca do conteúdo web
72
sincronizado. Os critérios utilizados na tomada de decisão da forma de notificação ao
usuário deste conteúdo sincronizado será explicado mais adiante.
4.5 Desafios de implementação do sistema
Esta seção elucida os desafios encontrados durante o desenvolvimento da
solução proposta por este trabalho e as soluções adotadas para a resolução de tais
problemas.
4.5.1. Normalização dos dados temporais
A normalização dos dados temporais é o fator mais importante para que o
sincronismo entre o conteúdo televisivo e o conteúdo complementar web possa
acontecer da forma esperada. O processo de normalização consiste em formatar,
para uma unidade de medida comum, os tempos dos horários da programação
extraídos da TV, dos pontos de sincronismo e o horário do dispositivo de segunda
tela.
Este processo de normalização ocorre nos seguintes passos:
1. Obter os dados temporais necessários à normalização.
2. Calcular, utilizando o horário atual da TV e o horário de início da
programação, o atraso no recebimento dos dados da tabela.
3. Em posse deste atraso, definir no dispositivo de segunda tela o horário
inicial da programação considerando o horário apresentado por este
dispositivo.
4. Verificar, utilizando o horário calculado, o momento de sincronismo
definidos nos dados dos pontos de sincronismo recebidos da TV.
5. Verificar se algum dos tempos de sincronismo já aconteceu e decidir
se deve utilizar ou descartar.
É importante salientar que, para que o processo descrito anteriormente
possa ser realizado corretamente, é imprescindível que pelo menos um dos tempos
analisados esteja correto, sendo utilizado como parâmetro para o ajustamento dos
outros valores. No caso, para o desenvolvimento desta solução, o tempo escolhido
foi o horário atual da TV. O horário da TV, no cenário de TV Hibrida, normalmente
73
é configurado buscando o horário através de um serviço na internet, o que garante
a veracidade da informação utilizada.
O trecho de código abaixo demonstra a implementação necessária para a
normalização dos tempos.
public ArrayList<NormalizedSyncPoint> normalizeTime(long
localCurrTime, ProgramInfoModel info)
{
long diffBTWInitialTimeAndCurrent =
info.getCurrentTime() - info.getProgramInitialTime();
long diffLOCAL = localCurrTime -
diffBTWInitialTimeAndCurrent;
ArrayList<NormalizedSyncPoint> normalizedList = new
ArrayList<NormalizedSyncPoint>();
// para cada syncpoint não normalizado
for (int i = 0; i < info.getList().size(); i++)
{
long normalizedTime = diffLOCAL +
(info.getList().get(i).getTime() * 1000);
normalizedList.add(new
NormalizedSyncPoint(normalizedTime,
info.getList().get(i).getUrl()));
}
return normalizedList;
}
No trecho de código mostrado, a variável recebida por parâmetro
localCurrTime representa o horário atual, em milissegundos, do dispositivo de
segunda tela e o objeto info contém os dados contextuais recebidos da TV. Observe
que, como definido anteriormente nos passos para que ocorra a normalização,
inicialmente é calculado o tempo transcorrido desde o início da programação,
subtraindo do valor atual do horário da TV, representado pela variável
diffBTWInitialTimeAndCurrent.
Logo após é calculado o horário de início da programação do ponto de
vista do dispositivo de segunda tela, representado pela variável diffLOCAL. Este
cálculo é necessário para que o agendamento dos momentos de sincronismo seja
feita de maneira correta, assim como o futuro descarte dos pontos de sincronismo
inválidos. Por fim, todos os pontos de sincronismo recebidos da TV são
74
recalculados e normalizados para o contexto temporal do dispositivo de segunda
tela, resultando nos dados contidos na variável normalizedList.
Todo o processo de normalização dos dados temporais pode ser observado
na Figura 12 abaixo.
Figura 12 – Processo de Normalização dos dados temporais.
Uma vez normalizados e formatados os dados, o agendamento dos pontos
de sincronismo pode ser feito, e os dados contextuais web exibido corretamente ao
usuário.
4.5.2. Sincronismo Automático
Uma das propostas mais importantes e fundamentais deste trabalho é o uso
contextual das informações da programação da TV e do ambiente da segunda tela
visando trazer ao usuário uma forma menos invasiva e mais automatizada na busca
e exibição de conteúdo adicionais complementares ao fluxo televisivo.
Um dos parâmetros analisados, como evidenciado na Seção 2.4 deste
trabalho, é a forma como o usuário acessa o conteúdo complementar no dispositivo
de segunda tela. Em muitas das técnicas apresentadas, sempre que o usuário deseje
acessar um conteúdo complementar o mesmo precisa estar presente no mesmo
ambiente e manualmente interagir com a TV, com a câmera ou microfone do
dispositivo de segunda tela, para que o acesso seja possível. Este processo é manual
e presencial precisando ser repetido sempre que uma nova programação seja
apresentada.
75
Este trabalho propõe uma forma automática de sincronismo entre a TV e
o dispositivo de segunda tela. Uma vez que ambos os dispositivos compartilhem a
mesma rede sem fio e as aplicações propostas como solução deste trabalho estejam
instaladas e configuradas corretamente, o estabelecimento de conexão entre os
dispositivos pode acontecer sem qualquer interação do usuário.
A Figura 13 a seguir exemplifica em alto nível o funcionamento do
processo de sincronismo entre a TV e a segunda tela.
Figura 13 - Sincronismo entre TV e Segunda Tela
Observe que uma vez conectados pela mesma rede sem fio, não há a
necessidade de proximidade entre os dispositivos. Como os dados contextuais da
programação corrente é enviado via protocolo UDP (broadcast), o envio dos dados
pode acontecer independente da proximidade física dos dispositivos. Como a
proposta deste trabalho também é o envio de todos os pontos de sincronismo da
programação corrente de uma única vez, a troca de informação entre a TV e o
dispositivo acontece apenas uma vez por programa, tornando possível assim que o
usuário acesse o conteúdo complementar web utilizando outra rede de sua
preferência.
76
4.5.3. Tomada de Decisão Sobre Interrupção
A personalização no processo de sincronismo dos dados complementares
também é um fator de importante e, uma vez que o processo de sincronismo torna-
se automático, o usuário acaba perdendo a tomada de decisão sobre qual
programação é de seu interesse e quais conteúdos complementares ele deseja
acessar.
Este trabalho propõe uma forma menos intrusiva e mais personalizada de
sincronismo onde o usuário pode decidir quais conteúdos são de seu interesse e
devem ser sincronizados e qual a forma que este sincronismo deve acontecer. A
tomada de decisão leva em consideração o contexto do dispositivo de segunda tela
no momento do sincronismo, como por exemplo, a aplicação atualmente em uso
pelo usuário.
Através de uma tela de wizard, o usuário pode definir quais dos gêneros
televisivos são do seu interesse e qual a forma de interrupção que irá acontecer caso
um conteúdo seja recebido. Há 3 opções de interrupção:
1- Não Notificar: Esta opção indica que o usuário não tem interesse neste
determinado gênero televisivo, então dados contextuais recebidos
deste gênero serão descartados.
2- Notificar: Esta opção indica que o usuário quer ser notificado de forma
não intrusiva acerca de um gênero especifico.
3- Interromper: Opção que permite à aplicação a interromper a atividade
corrente do usuário, exibindo automaticamente o conteúdo contextual
sincronizado.
A opção Notificar, caso seja selecionada e um conteúdo para este gênero
for recebido, exibirá uma Notification (espécie de lembrete) na barra de notificações
do Android, tornando possível ao usuário apagar ou acessar, caso seja de seu
interesse.
A opção Interromper consiste em exibir o conteúdo complementar web
em um WebView sobrepondo a UI da aplicação previamente sendo utilizada. Esta
opção funciona de uma forma um pouco diferente, pois permite ao usuário ainda
mais liberdade na escolha da forma que o sincronismo irá ocorrer. Uma vez que
77
esta opção é selecionada para qualquer dos gêneros, a opção de configuração
adicional de exceções de interrupção é disponibilizada.
Esta opção permite ao usuário a escolha de aplicações que sejam exceção
à regra da interrupção, ou seja, caso uma das aplicações selecionadas esteja em
execução no momento do sincronismo a interrupção não deve acontecer, sendo o
usuário apenas notificado do sincronismo.
Um cenário de exemplo que valida uso de exceções pode ser descrita por:
Imagine um usuário fanático por esportes que utilize a aplicação Synced-TVApp em
conjunto com o módulo Synced-SecondSreenApp a fim de receber informações
complementares dos eventos esportivos da programação televisiva. Ele, por
motivos de trabalho, define como exceção à regra de interrupção o aplicativo do
Microsoft Word. Neste cenário, mesmo ele tendo marcado que aplicações do gênero
“esportes” devem interrompê-lo, caso ele esteja trabalhando no momento utilizando
a aplicação Word, apenas uma notificação será exibida, uma vez que a aplicação
atualmente sendo utilizada está definida como uma exceção à regra de interrupção.
4.5.4. Atraso no Recebimento dos Metadados
Um dos principais problemas enfrentados durante o desenvolvimento do sistema
foi a falta de padrão quando se refere ao envio dos dados contextuais da programação
sendo transmitida pelas emissoras. Destes problemas observados destacam-se a falta de
informações na tabela mesmo para campos ditos obrigatórios pela norma (NBR 15603-2,
2008) e um grande atraso no envio dos dados da tabela EIT.
Este tipo de problema já havia sido reportado em (SOARES, 2012), no qual os
atrasos apresentados eram variáveis entre as emissoras em cenários que chegavam a
apresentar mais de vinte minutos de atraso com relação ao início da programação, ou seja,
em determinados momentos a informação da tabela era atualizado na metade do tempo
da duração do programa, o que inviabilizava as soluções de sincronismo propostas no
trabalho.
O teste consistiu em obter informações das tabelas de eventos da TV da
programação corrente, entre elas o nome do programa, o horário de início e duração, o
horário atual da TV e outras informações descritivas do programa. Este processo de
recuperação das informações foi executado com intervalos fixos de 2 segundos, visando
78
uma maior fidelidade das informações extraídas, principalmente na detecção da mudança
de programação.
A captura destas informações foi realizada durante todo o mês de maio de 2014,
no laboratório de TV digital do CESAR (Centro de Estudos e Sistemas Avançados do
Recife). Por estar utilizando a infraestrutura cedida pela empresa, a coleta dos dados só
pode ser realizada fora do horário comercial, geralmente nas noites entre os expedientes
de trabalho. A TV digital utilizada para coletar os dados conseguiu identificar o sinal
digital de três emissoras de TV, Rede TV, SBT e Rede Vida.
Diferente do ocorrido nos experimentos realizados por (SOARES, 2012), todas
as emissoras enviaram as informações ditas como obrigatórias pela norma NBR 15603-2
(2007), que obriga o envio de algumas informações referentes ao evento presente/seguinte
do serviço como, por exemplo, a descrição do nome do evento, a informação do seu tempo
de início e a descrição do seu estado de execução. O texto abaixo apresenta um exemplo
dos dados recebidos.
79
Extrato dos dados persistidos referentes à programação corrente da TV.
Mesmo havendo uma melhoria na consistência dos envios dos dados, ainda
assim foi facilmente identificar o atraso no recebimento das tabelas de eventos. Como no
exemplo mostrado acima, o programa iniciou-se às 18h45min, porém a informação da
tabela foi capturada apenas as 19h09min. Em situações como esta, a aplicabilidade da
solução proposta por este trabalho ficaria comprometida, uma vez que as demoras no
recebimento das informações necessárias ao sincronismo podem ser recebidas em um
momento no qual alguns ou diversos pontos de sincronismo tenham acontecido.
Para estas situações, alguns mecanismos de tomadas de decisão foram
implementadas e serão explicados e serão melhores explanadas na Seção 4.6.2
Nome do Evento: A Feia Mais Bela
Start Time: Mon May 26 18:45:00 BST 2014
Update Time: Mon May 26 19:09:30 BST 2014
Duracao: 2700
Series Name: null
Free CA Mode: false
Short Description: Letícia é uma garota muito inteligente, mas pouco agraciada fisicamente. Ela passará por pressões, desafios e desprezo, mas também conhecerá Fernando, alguém que mexerá com seu coração numa divertida história de superação.
SIEXInformation : 0 ou NULL
Event ID: 24
Original NET ID: 1038
Running Status: NOT RUNNING
Service ID: 33216
TransportStreamID: 1038
From Actual: true
Audio Component Descriptor: 0 ou null
Component Descriptor: [0]
Content Nibbles hexaString: 0f
Content User Nibbles hexaString: 00
Content Level 1 content Nibbles hexaString: 00
80
4.5.5. Ausência dos Dados Contextuais
Uma das questões analisadas durante o desenvolvimento da solução proposta foi
a definição de qual seria o comportamento esperado caso um ou mais valores necessários
à análise dos dados contextuais e estabelecimento dos pontos de sincronismo não fossem
enviados pela operadora. Com exceção do campo do nome da programação que é apenas
informativo, todos os outros campos especificados na Seção 4.4 são obrigatórios à
execução do sistema.
Caso alguma das informações obrigatórias não seja enviada pela emissora, os
dados contextuais extraídos da tabela são descartados pela aplicação Synced-TVApp e
nenhuma informação é enviada ao módulo da segunda tela. Este comportamento foi
definido visando inibir comportamentos errôneos ou inconsistentes com relação ao
sincronismo ou interrupção do usuário.
Para estes cenários onde informações primordiais não são enviadas, uma forma
de tentar viabilizar o acesso aos conteúdos complementares é a utilização da solução
proposta por (SOARES, 2012) que através da identificação do canal e do nome da
programação gera uma URL de acesso ao conteúdo complementar.
Uma outra alternativa, que foge ao escopo desta proposta, seria obter estes dados
complementares através de outras fontes, como por exemplo um serviço disponibilizado
pela emissora que seria responsável por armazenar e disponibilizar essas informações em
temo real como fonte alternativa de consulta.
4.6 Avaliação das Funcionalidades do Sistema
Esta seção demonstra a efetividade da solução proposta por este trabalho através
de um cenário de uso e da análise dos dados temporais que afetam o sincronismo. O
cenário de uso foi elaborado seguindo as diretrizes propostas por (Carroll, J M., 1999).
4.6.1. Cenário de Uso
“Paula, uma gerente de 30 anos chega a sua casa após o trabalho,
conecta seu tablet à rede sem fio de seu domicilio e vai jantar. Logo após a
refeição, ela decide ligar a sua TV digital para assistir algum filme com seu filho
Renato, sabendo que neste horário sempre há algum sendo transmitido. Notando
que ainda faltavam alguns minutos para o inicio do filme, Renato prontamente
81
vai buscar o seu smartphone para jogar um pouco enquanto aguarda o início do
filme. No momento em que o filme começa a ser exibido pela emissora, Renato se
espanta ao receber uma notificação no dispositivo em suas mãos informando
sobre o início da transmissão do filme, seguindo-se pela exibição de uma página
da Internet contendo informações detalhadas sobre o filme em exibição. A Figura
14 e Figura 15 a seguir demonstram, respectivamente, o conteúdo sendo exibido
pela TV e pelo smartphone no momento da notificação.
Figura 14 - Imagem da TV no primeiro sincronismo
Figura 15 - Imagem do smartphone no segundo sincronismo
82
Em outros momentos durante a exibição do filme, Renato e Paula
notaram que novas notificações eram recebidas, sempre trazendo novos
conteúdos relacionados ao filme exibido, como por exemplo, na Figura 16 e
Figura 17 abaixo, no momento em que o personagem principal do filme é exibido
pela primeira vez a página da Internet é rapidamente atualizada disponibilizando
a possibilidade da compra de um brinquedo semelhante ao personagem.
Figura 16 - Imagem da TV no segundo sincronismo
Figura 17 - Imagem do smartphone no segundo sincronismo
83
Este novo tipo de abordagem utilizando um dispositivo de segunda tela
em sincronismo com o conteúdo exibido pela TV representou, para ambos
telespectadores, uma nova experiência, ainda mais rica e inovadora, do meio de
assistir televisão.”
A estória contada acima elucida um cenário real da utilização da solução Synced-
DTV, apresentada por este trabalho, na melhoria e enriquecimento da experiência de
assistir televisão. Obviamente a estória segue a narrativa do telespectador, e a forma com
a qual ele interage com as interfaces dos módulos da solução. Entretanto, o ponto de vista
da solução deve ser analisado para que haja uma melhor compreensão das etapas
necessárias para que o sincronismo entre os dispositivos, elucidando os requisitos
necessários à comunicação e os artefatos trafegados entre os dispositivos.
Nesta nova ótica, a emissora tem basicamente duas responsabilidades, o envio
da aplicação, caracterizada pelo módulo Synced-TVApp, e o envio dos dados necessários
ao sincronismo através das tabelas EIT. No caso do cenário de uso descrito acima, os
dados de sincronismo enviados são descritos pelo texto abaixo.
Basicamente o que a informação acima descreve é que, após 100 segundos do
início da transmissão desta programação o conteúdo da página
“http://www.synceddtv.com.br/iceage1” deve ser exibido. Após mais 20 segundos, a
página deve ser atualizada para exibir o conteúdo da página
“http://www.synceddtv.com.br/iceage2”.
Uma vez que esta informação é recebida pela TV e processada pelo módulo
Synced-TVApp, os dados necessários ao sincronismo são então enviados por broadcast
para os dispositivos de segunda tela que contenha a aplicação Synced-SecondScreenApp
{"syncpoints":[
{"time":"100","inttype":0,"url":"http://www.synceddtv.com.br/iceage1"},
{"time":"120","inttype":1, "url":"http://www.synceddtv.com.br/iceage2"}
]}
84
instalado e que esteja na mesma rede sem fio da TV. O texto abaixo demonstra a
informação enviada entre a TV e a segunda tela.
Observe que além das informações dos pontos de sincronismo enviados pela
emissora, novas informações necessárias ao sincronismo são adicionadas aos dados
transmitidos à segunda tela, como por exemplo a hora de início e duração do programa e
a hora atual, que corresponde ao momento em que a informação foi recebida na TV.
Em posse destas informações, a aplicação Synced-SecondScreenApp é capaz de
determinar os momentos, considerando o horário atual do dispositivo de segunda tela, em
que o sincronismo deve acontecer, agendando alarmes para estes momentos específicos.
O texto abaixo demonstra, utilizando logs do terminal Android, o que acontece após o
recebimento das informações de sincronismo.
{ "ProgramInfo":
{"Name":"Ice Age",
"Genre":"0xC",
"CurrentTime":"1409168202207",
"ProgramInitialTime":"1409168157000",
"ProgramDuration":"1800",
"syncpoints":[{"time":"100","inttype":0,
"url":"http://www.synceddtv.com.br/iceage1"},{"time":"120","i
nttype":1, "url":"http://www.synceddtv.com.br/iceage2"}]
} }
85
08-28 17:05:07.794:E/ConnectionService(2997): From: /192.168.1.101:56885
08-28 17:05:07.794: E/ConnectionService(2997): Message: { "ProgramInfo": { "Name":"Ice Age", "Genre":"0xC",
"CurrentTime":"1409168202207", "ProgramInitialTime":"1409168157000",
"ProgramDuration":"1800","syncpoints":[{"time":"100","inttype":0,
"url":"http://www.synceddtv.com.br/iceage1"},{"time":"120","inttype":1,
"url":"http://www.synceddtv.com.br/iceage2"}] } }
08-28 17:05:07.799: D/ConnectionService(2997): handleMessage
08-28 17:05:07.799: D/ConnectionService(2997): STATUS_OK
08-28 17:05:07.799: D/ConnectionService(2997): unregisterPending
08-28 17:05:07.799: E/ConnectionService(2997): Waiting for datagram packet
08-28 17:05:07.809: D/ConnectionService(2997): sended intent
08-28 17:05:07.809: D/ParseJsonService(2997): ParseJsonService
08-28 17:05:07.814: D/ParseJsonService(2997): onHandleIntent [Intent {
cmp=br.ufpe.cin/.service.ParseJsonService (has extras) }]
08-28 17:05:07.819: D/ParseJsonService(2997): parseReceivedData
08-28 17:05:07.849: D/ParseJsonService(2997): name = Ice Age
08-28 17:05:07.849: D/ParseJsonService(2997): genre = 12
08-28 17:05:07.849: D/ParseJsonService(2997): currentTime = 1409168202207
08-28 17:05:07.849: D/ParseJsonService(2997): programInitialTime = 1409168157000
08-28 17:05:07.849: D/ParseJsonService(2997): programDuration = 1800
08-28 17:05:07.849: D/ParseJsonService(2997): timeInSeconds = 100
08-28 17:05:07.849: D/ParseJsonService(2997): url = http://www.synceddtv.com.br/iceage1
08-28 17:05:07.849: D/ParseJsonService(2997): timeInSeconds = 120
08-28 17:05:07.849: D/ParseJsonService(2997): url = http://www.synceddtv.com.br/iceage2
08-28 17:05:07.854: D/ParseJsonService(2997): normalizeTime
08-28 17:05:07.854: D/ParseJsonService(2997): info.getCurrentTime() = 1409168202207 - DATE = Wed Aug 27
16:36:42 BRT 2014
08-28 17:05:07.854: D/ParseJsonService(2997): info.getProgramInitialTime() = 1409168157000 - DATE = Wed
Aug 27 16:35:57 BRT 2014
08-28 17:05:07.859: D/ParseJsonService(2997): diffBTWInitialTimeAndCurrent = 45207 - 45seconds has passed
08-28 17:05:07.859: D/ParseJsonService(2997): localCurrTime = 1409256307851 - DATE = Thu Aug 28 17:05:07
BRT 2014
08-28 17:05:07.859: D/ParseJsonService(2997): deviceInitialTime = 1409256262644 - DATE = Thu Aug 28
17:04:22 BRT 2014
08-28 17:05:07.859: D/ParseJsonService(2997): endProgramTime = 1409258062644 - DATE = Thu Aug 28
17:34:22 BRT 2014
08-28 17:05:07.859: D/ParseJsonService(2997): normalizedTime[0] = 1409256362644 - DATE = Thu Aug 28
17:06:02 BRT 2014
08-28 17:05:07.859: D/ParseJsonService(2997): normalizedTime[0] VAI ALARMAR EM [54] Segundos
08-28 17:05:07.859: D/ParseJsonService(2997): normalizedTime[1] = 1409256382644 - DATE = Thu Aug 28
17:06:22 BRT 2014
08-28 17:05:07.859: D/ParseJsonService(2997): normalizedTime[1] VAI ALARMAR EM ~ [74] Segundos
08-28 17:05:07.864: D/ParseJsonService(2997): setAlarmList [ProgramInfoModel [mName=Ice Age, mGenre=12,
mCurrentTime=1409168202207, mProgramInitialTime=1409168157000, mProgramDuration=1800000,
mList=[br.ufpe.cin.model.SyncPoint@42a8de68, br.ufpe.cin.model.SyncPoint@42a8e110,
br.ufpe.cin.model.SyncPoint@42a8e2e8], mNormalizedList=[br.ufpe.cin.model.NormalizedSyncPoint@42a90c18,
br.ufpe.cin.model.NormalizedSyncPoint@42a911e0, br.ufpe.cin.model.NormalizedSyncPoint@42a91760],
mInterruptType=2]]
08-28 17:05:07.864: D/ParseJsonService(2997): normalizedList
[[br.ufpe.cin.model.NormalizedSyncPoint@42a90c18, br.ufpe.cin.model.NormalizedSyncPoint@42a911e0,
br.ufpe.cin.model.NormalizedSyncPoint@42a91760]]
08-28 17:05:07.874: D/ParseJsonService(2997): alarm [1409256362644] [http://www.synceddtv.com.br/iceage1]
08-28 17:05:07.884: D/ParseJsonService(2997): alarm [1409256382644] [http://www.synceddtv.com.br/iceage2]
86
Após o recebimento dos dados do sincronismo, as informações são extraídas e
normalizadas, e os alarmes configurados e agendados. Nos momentos definidos pelos
alarmes, o módulo responsável para ser informado que um sincronismo deve acontecer é
executado, iniciando o processo de exibição do conteúdo Web associado ao alarme sendo
processado. Este fluxo é demonstrado pelo texto abaixo, onde pode-se observar que os
dois pontos definidos pela informação enviada pela emissora são executados de forma
correta.
É importante notar que os alarmes acontecem precisamente no momento calculado
durante a normalização dos tempos recebidos da TV, como por exemplo no cenário
08-28 17:06:02.674: D/ScheduleAlarmReceiver(2997): onReceive [Intent { act=schedule.alarm.SCHEDULE_ACTION flg=0x14 cmp=br.ufpe.cin/.receiver.ScheduleAlarmReceiver (has extras) }]
08-28 17:06:02.679: D/ScheduleAlarmReceiver(2997): onReceive DATE [Thu Aug 28 17:06:02 BRT 2014]
08-28 17:06:02.679: D/ScheduleAlarmReceiver(2997): interruptType [2]
08-28 17:06:02.679: D/ScheduleAlarmReceiver(2997): url [http://www.synceddtv.com.br/iceage1]
08-28 17:06:02.679: D/ScheduleAlarmReceiver(2997): genre [12]
08-28 17:06:02.679: D/ScheduleAlarmReceiver(2997): interrupt [http://www.synceddtv.com.br/iceage1] [12]
08-28 17:06:02.694: D/ScheduleAlarmReceiver(2997): packageList []
08-28 17:06:02.694: D/ScheduleAlarmReceiver(2997): !isAtualTopStackActivityOnExcpetionList
08-28 17:06:02.924: D/WebActivity(2997): onCreate
08-28 17:06:03.049: I/webclipboard(2997): clipservice: android.sec.clipboard.ClipboardExManager@42ab2358
08-28 17:06:03.464: D/WebActivity(2997): loadWeb [http://www.synceddtv.com.br/iceage1]
----------------------------------------------------------------------------------------------------------
08-28 17:06:22.729: D/ScheduleAlarmReceiver(2997): onReceive [Intent { act=schedule.alarm.SCHEDULE_ACTION flg=0x14 cmp=br.ufpe.cin/.receiver.ScheduleAlarmReceiver (has extras) }]
08-28 17:06:22.739: D/ScheduleAlarmReceiver(2997): onReceive DATE [Thu Aug 28 17:06:22 BRT 2014]
08-28 17:06:22.739: D/ScheduleAlarmReceiver(2997): interruptType [2]
08-28 17:06:22.739: D/ScheduleAlarmReceiver(2997): url [http://www.synceddtv.com.br/iceage2]
08-28 17:06:22.739: D/ScheduleAlarmReceiver(2997): genre [12]
08-28 17:06:22.739: D/ScheduleAlarmReceiver(2997): interrupt [http://www.synceddtv.com.br/iceage2] [12]
08-28 17:06:22.759: D/ScheduleAlarmReceiver(2997): packageList []
08-28 17:06:22.759: D/ScheduleAlarmReceiver(2997): !isAtualTopStackActivityOnExcpetionList
08-28 17:06:22.819: D/WebActivity(2997): onNewIntent
08-28 17:06:22.824: D/WebActivity(2997): loadWeb [http://www.synceddtv.com.br/iceage2]
87
descrito nesta seção, foi definido que os momentos de sincronismo ocorreriam nos
horários:
O que pode ser confirmado pelo horário de disparo dos alarmes, responsáveis por invocar
os Receivers Android que por fim realizam a ação de exibir a página Web, como pode ser
observado no texto abaixo.
4.6.2. Atrasos de Comunicação
Anteriormente a validação da solução proposta, demonstrada na seção anterior,
achou-se necessário descobrir o fator de influência do atraso gerado pelo processamento
e pela comunicação entre os módulos do sistema. Para isto foram determinados quais os
pontos de interesse na medição do atraso, tornando possível a identificação de possíveis
gargalos que influenciariam no sincronismo da exibição do conteúdo complementar no
dispositivo de segunda tela.
O cálculo do atraso gerado pela execução e comunicação dos módulos
componentes da solução Synced-DTV é importante, pois deve ser considerado durante a
obtenção dos pontos de sincronismo entre os conteúdos televisivo e complementar. Por
exemplo, definindo-se que o atraso gerado pelas operações do sistema seja de um
segundo, todos os pontos de sincronismo calculados pelo módulo Synced-
SecondScreenApp durante a normalização dos dados temporais descritos na seção 4.5.1
deste trabalho, devem ser decrementados em um segundo, mantendo os momentos de
sincronismo corretos.
Os pontos definidos como relevantes à medição englobam a recepção dos dados
da tabela EIT, a formatação dos dados na TV, o envio dos dados do módulo Synced-
TVApp até a recepção pela aplicação Synced-SecondScreenApp, o tratamento dos dados
normalizedTime[0] = 1409256362644 - DATE = Thu Aug 28 17:06:02 BRT 2014
normalizedTime[1] = 1409256382644 - DATE = Thu Aug 28 17:06:22 BRT 2014
08-28 17:06:02.679: D/ScheduleAlarmReceiver(2997): onReceive DATE [Thu Aug 28 17:06:02 BRT 2014]
08-28 17:06:22.739: D/ScheduleAlarmReceiver(2997): onReceive DATE [Thu Aug 28 17:06:22 BRT 2014]
88
neste último e o tempo gasto para a chamada da tela de exibição de um conteúdo
sincronizado.
1. Recepção dos Dados da Tabela: Atraso de processamento realizado na
TV que compreende o tempo gasto entre o lock necessário a leitura dos
dados tabela EIT até a completa leitura dos dados contextuais necessário
ao sincronismo.
2. Formatação dos Dados: Atraso relativo à formatação adequada dos
dados contextuais obtidos para o envio ao modulo de segunda tela.
3. Envio dos Dados: Atraso que representa o tempo necessário para a
criação e estabelecimento da conexão e o envio dos dados entre os
módulos via broadcast.
4. Tratamento dos Dados: Representa o tempo necessário a analise dos
dados recebidos da TV, a extração dos dados relevantes e o agendamento
dos pontos de sincronismo.
5. Exibição do Conteúdo: Tempo transcorrido do momento em que um
ponto de sincronismo é alcançado até a chamada da classe responsável
pela exibição do conteúdo complementar.
O gráfico da Figura 18 mostra proporcionalmente o efeito desses
processamentos no atraso final obtido.
Figura 18 - Proporção dos Atrasos de Processamento
Para garantir a confiabilidade dos valores dos atrasos gerados na execução dos
testes, foi gerada a média dos atrasos a partir da execução de trinta ciclos de experimentos,
o que é considerado pela estatística como um valor considerável de amostras para a
89
obtenção de um valor inicial que represente o universo de possibilidades. Os valores dos
atrasos em milissegundos obtidos pela execução dos testes são mostrados a seguir:
Para esses valores a média calculada foi de 475.534 milissegundos. Uma vez que
a média aritmética não é um cálculo estatístico confiável, a partir da mesma amostra foi
calculado o desvio padrão, que mede a dispersão dos dados em torno da média da amostra,
gerando um valor igual a 9.2204. Quando o valor numérico ou a estimativa de um
parâmetro é reportado, geralmente é desejável dar alguma ideia da precisão da estimação.
A medida de precisão geralmente empregada é o erro padrão do estimador que está sendo
usado, que no caso dos dados acima resulta em um valor de erro padrão igual a 1.6834.
Como os valores de média, desvio padrão e erro padrão descritos anteriormente
foram gerados a partir de uma amostra, precisa-se definir o número mínimo de ciclos
necessários para garantir a validade dos dados para uma população inteira, precisando
para isso descobrir a quantidade mínima de experimentos necessários. O cálculo do
tamanho da amostra, além dos valores já reportados, necessita como entrada o nível de
confiança desejado, que expressa a certeza de que o dado que se busca realmente está
dentro da margem de erro definida. Para este experimento foi definido um nível de
confiança de 95%.
Para este nível de confiança e os valores de desvio padrão e erro antes definidos
estima-se a necessidade de 116 ciclos de execução, gerando o gráfico da Figura 19, que
corrobora o resultado observado durante a fase de experimentação, gerando um atraso
médio de aproximadamente 470 milissegundos.
Figura 19 - Atrasos dos processamentos do sistema
476;460;474;463;477;466;470;482;480;460;477;478;479;483;485;
494;481;477;458;486;473;483;458;488;474;474;476;487;471;476
90
O cálculo dos atrasos foi medido registrando-se o tempo inicial e final das
execuções das etapas necessárias à obtenção dos pontos de sincronismo e o efetivo
sincronismo nestes momentos calculados. O tempo de transmissão e recepção da
operadora é considerado no momento que se identifica o tempo percorrido entre o início
da programação corrente e o momento da recepção dos dados contextuais pelas tabelas
EIT.
Apenas lembrando que, alguns atrasos não foram levados em consideração seja
por apresentarem valores ínfimos ou por serem totalmente dependentes de fatores
externos, como por exemplo, o tempo necessário para o carregamento do conteúdo
complementar web. Este tempo não pode ser mensurado por depender da qualidade da
conexão de internet do usuário, o tamanho do conteúdo web a ser exibido e a distância
até o provedor deste conteúdo. Nos testes realizados desta solução, o conteúdo web era
armazenado em um servidor na mesma intranet do dispositivo de segunda tela, tornando
o carregamento da informação quase que instantâneo.
4.6.3. Avaliação de aceitação da solução
Apesar do atraso gerado pelo processamento e comunicação dos módulos da
solução apresentada ser consideravelmente pequeno ele ainda existe e afeta o momento
exato de quando o sincronismo entre os conteúdos televisivo e complementar deve
acontecer. Visando saber a eficácia dos momentos de sincronismos calculados na seção
4.5.1 e a influência do atraso definido pela seção anterior na confiabilidade e usabilidade
da solução, uma avaliação foi realizada e envolveu 20 voluntários.
Para o estudo foram consideradas pessoas de diversas faixas etárias, sendo a
quantidade proporcionalmente dividida pelo tempo comumente gasto assistindo TV.
Então foram 5(cinco) crianças entre 6 e 12 anos, 5(quatro) adolescentes entre 13 e 18
anos, 6(seis) adultos entre 19 e 40 anos e finalmente 4(quatro) pessoas de mais idade entre
41 e 60 anos. Cada usuário utilizava um smartphone com as aplicações previamente
instaladas e receberam um treinamento básico sobre como utilizar a aplicação. Os
participantes foram instruídos a usar a aplicação e a responder um questionário de
avaliação relacionado à experiência no uso da aplicação.
Para avaliar a aceitabilidade do sistema um questionário foi criado seguindo os
princípios definidos no TAM (Technology Acceptance Model). Este modelo considera os
91
seguintes princípios para a aceitação de uma aplicação: (I) Facilidade de Uso: Definido
como sendo “o grau em que uma pessoa entende que o uso de um sistema em particular
seria livre de esforço”; (II) Utilidade: Definido como o “grau que uma pessoa acredita
que o uso da aplicação aumenta o desempenho da realização e uma tarefa”.
As perguntas do questionário foram formuladas para serem curtas, diretas e
simples de serem respondidas, onde a resposta para cada uma das questões deve ser
compreendida numa escala entre 1 (discordo totalmente) e 5 (concordo totalmente). A
Tabela 6 e a Tabela 7 apresentam as perguntas apresentadas e os resultados da aplicação
do questionário aos usuários. As tabelas apresentam as perguntas em sua primeira coluna
e as porcentagens da escolha dos usuários nas colunas subsequentes, de “Discordo
Totalmente” à “Concordo Totalmente”.
Analisando os dados das duas tabelas é fácil observar que a aceitação do modelo
verificado foi alta, tanto para a “Facilidade de Uso”, quanto para a “Utilidade”. Na
questão 3, da Tabela 6, questionamentos foram feitos sobre a possibilidade da inferência
da decisão sobre a interrupção por um gênero televisivo ser automática, considerando
decisões previamente tomadas pelo usuário. Outro questionamento realizado, agora com
referência à questão 4, da Tabela 7, foi a necessidade de abrir a barra de notificações,
quando um conteúdo sincronizado com gênero previamente definido para “Notificar” for
recebido, para visualizar mais detalhes da notificação, sendo este um comportamento
padrão do Android.
Tabela 6 - Facilidade de Uso
Questão Discordo
Totalmente
Discordo
Parcialmente Neutro
Concordo
Parcialmente
Concordo
Totalmente
1. A aplicação é fácil de
usar.
0%(0) 0%(0) 5%(1) 15%(3) 80%(16)
2. A aplicação é fácil de
entender.
0%(0) 0%(0) 0%(0) 0%(0) 100%(0)
3. Com pouco esforço eu
posso
determinar meus
interesses.
0%(0) 0%(0) 5%(1) 20%(4) 75%(15)
4. Com pouco esforço eu
posso acessar o
conteúdo
sincronizado.
0%(0) 0%(0) 0%(0) 15%(3) 85%(17)
Tabela 7 - Utilidade
92
Questão Discordo
Totalmente
Discordo
Parcialmente Neutro
Concordo
Parcialmente
Concordo
Totalmente
1. A aplicação
simplifica a
obtenção de
informação
complementar?
0%(0) 0%(0) 0%(0) 0%(0) 100%(20)
2. A aplicação
sincroniza
corretamente?
0%(0) 0%(0) 5%(1) 10%(2) 85%(17)
3. A aplicação
respeita seus
interesses
contextuais?
0%(0) 0%(0) 0%(0) 10%(2) 90%(18)
4. Eu usaria a
aplicação no dia-
a-dia?
0%(0) 0%(0) 0%(0) 5%(1) 95%(19)
4.6.4. Sincronismo em Múltiplas Telas
Dado que a comunicação entre os módulos Synced-TVApp, executando na TV, e
Synced-SecondScreenApp, executando no dispositivo de segunda tela, é realizada através
do uso de conexões broadcast nada impede a extensão da arquitetura proposta por este
trabalho para o sincronismo com múltiplas telas.
Uma vez que os dispositivos que desejam receber o conteúdo complementar
compartilhem a mesma rede sem fio da TV e que estejam executando uma aplicação que
permita o recebimento dos dados via broadcast, todos estes aparelhos poderão exibir
conteúdo sincronizado com a programação da TV. É importante observar que
determinadas decisões do usuário, como a escolha de receber notificações sobre um
determinado gênero televisivo ou as exceções definidas para o modo de interrupção, serão
específicos de cada dispositivo sincronizado, tornando independente a forma como os
dados recebidos irão ser tratados.
A Figura 20 a seguir demonstra, em alto nível, o cenário descrito.
93
Figura 20 - Synced-DTV em múltiplos dispositivos
Este cenário demonstra o poder da personalização proposta por este trabalho,
dando poder ao usuário a escolha dos conteúdos sincronizados e a forma de como este
sincronismo deve ocorrer.
4.7 Ambiente operacional
O desenvolvimento da solução Synced-DTV foi realizado utilizando o ambiente
de programação do Eclipse com as bibliotecas fornecidas pela linguagem de programação
Java da Oracle e Android do Google, sendo o ambiente de programação executado sobre
o sistema operacional Windows.
O módulo Synced-TVApp foi desenvolvido tendo como base o sistema SBTVD
(Sistema Brasileiro de TV Digital), podendo a solução ser adaptada para o funcionamento
de qualquer outra estrutura de TV Digital no qual os dados contextuais da programação
seja m derivadas da especificação DVB (Digital Video Broadcasting).
O módulo Synced-SeconScreenApp que executa no dispositivo de segunda tela
foi desenvolvido em Android, uma plataforma altamente disseminada da Google, por
apresentar mecanismos interessantes que tornou possível a fácil prototipação e validação
dos requisitos pertinentes à implementação. Observe que outras plataformas existentes no
mercado, como IOS ou Windows Phone, poderiam facilmente realizar as funções
requeridas pelo módulo.
O desenvolvimento deste módulo Synced-WebServers foi feito utilizando
XAMPP, um ambiente de desenvolvimento de distribuição Apache que contém MySQL,
94
PHP e Perl. A decisão do uso deste ambiente foi pessoal, podendo ser adotada qualquer
tecnologia compatível para a implementação como, por exemplo, Java ou HTML5.
As bibliotecas relativas ao SBTVD, Ginga-J, e também o laboratório utilizado
para a elaboração e execução do modelo Synced-DTV foram gentilmente cedidos pelo
CESAR (Centro de Estudos em Sistemas Avançados do Recife). O laboratório forneceu
ao trabalho uma TV digital, com o middleware Ginga-J em estado funcional, com acesso
à Internet e a uma estrutura de rede sem fio local na qual foi validada a comunicação entre
o módulo da TV e os subsistemas Synced-SeconScreenApp e Synced-Webservers.
A infraestrutura disponibilizada permitiu que a solução proposta fosse elaborada
e testada em uma TV real, dispensando a necessidade da utilização de simuladores ou
emuladores. Além disso, a execução na TV proporcionou ao trabalho uma análise real
sobre as informações obtidas das tabelas de informação de serviços enviadas pelas
emissoras de TV digital da cidade do Recife/PE. Estas características proporcionaram ao
trabalho um ambiente de execução mais próximo do que seria encontrado caso a proposta
apresentada pelo Synced-DTV fosse utilizada comercialmente.
4.8 Discussões
Este capítulo apresentou detalhes sobre a implementação, execução e validação
das arquiteturas dos módulos que compõem a solução Synced-DTV. Explanou a proposta
de utilização de um documento JSON bem formatado em conjunto com as informações
extraídas das tabelas de informações da programação para o estabelecimento do
sincronismo entre o conteúdo televisivo e os dados complementares.
Foram apresentadas os detalhes de implementação das arquiteturas das
aplicações Synced-TVApp, Synced-WebServers e Synced-SecondScreenApp que podem
ser utilizadas como referencias para a implementação de qualquer outra solução de
sincronismo de conteúdos de TV digital híbrida, assim como os desafios encontrados
durante a concepção e conexão entre as aplicações.
Por fim, foram apresentados dados que validam a solução proposta, através da
analise dos atrasos observados e através dos resultados de uma pesquisa de aceitação.
95
5 Conclusões
Este trabalho propôs uma solução para a sincronização entre o conteúdo
transmitido pela programação broadcast das emissoras de TV e um conteúdo Web
complementar disponibilizado telespectador pelo uso de aplicações interativas e da
conectividade à Internet das TVs híbridas. O principal objetivo deste trabalho consistiu
na elaboração de um modelo de aplicações que tem por objetivo fornecer ao telespectador
um conteúdo complementar, obtido na Web de forma síncrona, transparente e sensível à
programação da TV. Para isto foi realizado o desenvolvimento de uma infraestrutura
modular de software que utiliza informações contextuais da programação da TV, da
própria TV e das preferências do usuário no dispositivo de segunda tela para tornar a
experiência mais rica e menos intrusiva para o usuário.
O modelo para a construção de aplicativos e de comunicação apresentado,
denominado Synced-DTV, foi desenvolvido como uma solução para a integração das
novas plataformas de TV digital com os recursos advindos da Internet, tornando possível
a utilização de conteúdos complementares na Web para o aprimoramento da experiência
televisiva dos telespectadores. Além disso, o modelo também mostra como as aplicações
emergentes para a plataforma da TV híbrida podem relacionar os conteúdos da TV e da
Internet com o intuito de potencializar a experiência televisiva do usuário e agregar valor
à interatividade oferecida pelas aplicações.
É importante salientar que a arquitetura de funcionamento das TV hibridas torna
possível a comunicação e posterior obtenção de conteúdos complementares na Internet,
porém a comunicação seria possível através de aplicativos específicos por emissora, ou
num cenário mais específico, através de aplicativos específicos para cada programa da
grade televisiva. Caso a solução proposta por este trabalho fosse adotada, esta necessidade
poderia ser descartada, uma vez que a aplicação interativa Synced-DTVApp, residente na
TV, adapta-se ao contexto televisivo do usuário buscando informações complementares
relacionadas a qualquer evento transmitido pela grade de programação, tornando possível
a busca por conteúdos complementares acontecer de forma direcionada e automática.
Uma vez que a localização dos conteúdos complementares são enviados em
conjunto com o conteúdo televisivo, é possível a construção de um modelo de aplicação
genérico capaz de atender a quaisquer programas de qualquer transmissora, ou ainda
96
elaborar uma aplicação unificada capaz de exibir conteúdos complementares
independente da emissora sintonizada.
O desenvolvimento deste trabalho seguiu diversas fases ou etapas até a
finalização do modelo, denominado Synced-DTV. Inicialmente foi necessário realizar um
estudo teórico sobre temas que abordam a TV digital interativa e conectada, assim como
o padrão DVB e os padrões derivados deste, a estrutura dos metadados e tabelas de
informações da programação. Estudos teóricos a respeito do conceito de Segunda Tela e
a forma como dispositivos móveis, como smartphones e tablets, estão sendo utilizados
também foi realizado. Finalmente, foram abordadas tecnologias disponíveis no mercado
que auxiliam na identificação e/ou extração de informações do fluxo de transmissão
televisivo que são utilizados para o sincronismo de conteúdos complementares.
Na etapa seguinte, foram definidos alguns cenários de uso que serviram para
ilustrar a utilização da proposta do Synced-DTV no cotidiano dos telespectadores. Depois
foram definidos requisitos funcionais e não funcionais para fixar metas no processo de
desenvolvimento da solução, sendo também apresentados o diagrama de casos de uso e a
descrição detalhada de cada um dos casos, para auxiliar a compreensão dos requisitos
estabelecidos, através da simulação de uso do sistema.
A próxima etapa consistiu em definir quais tecnologias seriam utilizadas no
desenvolvimento dos módulos da solução (aplicação da TV, do dispositivo de segunda
tela e web servers) e como seria realizada a comunicação entre estes módulos. Nesta etapa
também foi realizada a concepção e especificação da arquitetura do Synced-DTV, assim
como o projeto e elaboração do diagrama de classes. Determinada a arquitetura e o modo
de interação entre módulos componentes, precisou-se determinar quais as informações
mínimas necessárias para o funcionamento da solução, seja informações extraídas das
tabelas de informação do sistema, informações contextuais da própria TV e informações
a serem extraídas do dispositivo de segunda tela.
Uma vez determinado o conjunto de dados necessários, foi necessário
determinar um padrão e uma formatação para o tráfego desses dados entre os módulos do
sistema, sendo escolhido o padrão JSON, comumente utilizado para normalização de
dados textuais. O funcionamento do Synced-DTV foi descrito a partir de casos de uso e
também por meio de um diagrama de sequência juntamente com suas respectivas
descrições.
97
Uma vez especificadas e formalizadas as estruturas necessárias ao
funcionamento da solução, protótipos dos subsistemas componentes do modelo foram
desenvolvidos, tornando possível a experimentação do modelo proposto. Os subsistemas
desenvolvidos, Synced-TVApp, Synced-SeconScreenApp e Synced-WebServers, podem
funcionar de maneira independente, porém se comunicam através de uma conexão sem
fio ou através da Internet. O módulo Synced-TVApp, subsistema que executa na TV, é
responsável pela captura das informações das tabelas SI a respeito da programação
corrente, assim como informações contextuais da própria TV. Essas informações
incluem, por exemplo, os dados com informações sobre os pontos de sincronismo e as
URLs de comunicação com o módulo Synced-WebServers.
O módulo Synced-WebServers é responsável por armazenar e distribuir, de
acordo com as requisições recebidas, todas as informações complementares que estão
relacionadas à grade de programação da emissora de TV. Por fim, o subsistema da
segunda tela, Synced-SeconScreenApp, é responsável pelo cálculo dos momentos de
sincronismo e pela exibição síncrona das informações Web complementares ao conteúdo
televisivo.
Uma vez que a implementação dos módulos da solução estava concluída, testes
foram realizados com o intuito de avaliar os requisitos funcionais e não-funcionais
especificados na Seções 3.3.1 e 3.3.2 deste documento. Nesta etapa foram identificados
diversos problemas, principalmente relacionados com a falta ou forma errônea de envio
das informações sobre a programação corrente, onde informações ditas como obrigatórias
pela norma não são enviadas pelas emissoras ou as informações são enviadas com um
atraso relativamente alto, gerando inconsistências na aplicação.
Por fim, durante a fase de validação da implementação dos módulos do sistema,
foram identificados pontos que tornavam o sincronismo entre os conteúdos incorreto, em
grande parte por atrasos no processamento das informações contextuais. Na última etapa,
a solução foi submetida a um grupo de usuários que avaliaram a solução considerando
critérios de usabilidade.
As próximas subseções deste capítulo descrevem as contribuições do trabalho e
as sugestões de trabalhos futuros.
98
5.1 Contribuições do trabalho
A principal contribuição deste trabalho é um modelo genérico e adaptável a
qualquer dos subsistemas derivados do DVB, para a comunicação síncrona e sensível a
contexto de conteúdos complementares na Internet com o conteúdo televisivo
convencional (áudio e vídeo) de forma automática, onde o usuário não necessita
manualmente procurar por este conteúdo. Esta abordagem propicia ao usuário uma forma
simples de obter os conteúdos complementares sem que haja a dispersão de sua atenção
do conteúdo televisivo.
Como contribuição neste trabalho, também é proposto uma revisão das normas
que especificam o SBTVD, utilizado como base no desenvolvimento da solução, visando
uma utilização mais aprimorada das capacidades dispostas pelas tabelas SI, em especial
as tabelas EIT, podendo ser utilizada como recursos catalizadores de experiências mais
ricas e completas para os telespectadores. A solução proposta por este trabalho explorou
apenas um dos campos disponibilizados pela norma, Extended Event Descriptor, dita
como opcional pela norma, mas que utilizada de maneira correta tornou viável a
implementação da solução proposta por este trabalho. Além de uma revisão aprofundada
da norma, é necessário um maior empenho das emissoras em aderir ao que está
regulamentado, o que possibilitaria um maior investimento e aprimoramento de soluções
para TV digital.
A metodologia utilizada para o pareamento e sincronismo dos sistemas
envolvidos, TV e dispositivo de segunda tela, é mais uma contribuição deste trabalho.
Utilizando informações das interfaces de rede disponibilizadas pela TV foi possível
identificar qual o endereço IP da TV, e posteriormente identificar o endereço de broadcast
desta rede. Com esta informação é possível enviar informação entre todos os dispositivos
conectados em uma mesma rede sem que haja a necessidade de identificar o IP de todos
os dispositivos. Uma vez determinado o IP de broadcast, uma porta é selecionada e
utilizada para identificar a comunicação entre os dispositivos da solução.
A solução Synced-DTV pode e deve ser tomada como referência para os que
almejam desenvolver soluções em TV digital que utilizem informações contextuais da
programação da TV ou preferencias do próprio usuário para a inferência e
disponibilização de conteúdos complementares.
99
5.2 Trabalhos Futuros
Por se tratar de uma solução flexível e adaptável a quaisquer dos modelos
derivados do padrão DVB, novas funcionalidades podem ser acopladas no Synced-DTV.
Ao fim do desenvolvimento da solução foram identificadas possíveis melhorias ao
trabalho, sendo apresentadas nesta seção como possíveis trabalhos futuros.
Uma melhoria importante ocorreria com a contextualização automática, através
de técnicas de aprendizagem, para a definição das preferências do usuário com relação
aos gêneros televisivos. Poderia ser adotado um critério comum para todos os gêneros e,
com o passar do tempo e com a utilização do sistema pelo usuário, o sistema poderia se
adaptar às escolhas prévias e assumir posturas automatizadas de quando o usuário será
notificado, interrompido ou quando a informação deve ser descartada.
Modificar o Synced-DTV para que seja possível a integração com outros meios
de distribuição de outros tipos de conteúdo complementar, como feeds de notícias,
podcasts e rádios-online é uma outra proposta a ser abordada como forma de estender a
proposta deste trabalho, desta forma será possível prover ao usuário uma maior
diversidade de conteúdo, enriquecendo ainda mais a sua experiência televisiva.
Há a possibilidade de estender a implementação do módulo Synced-
SecondScreenApp para outras plataformas disponíveis no mercado, como IOS, Windows
Phone ou Tizen. Esta extensão possibilitaria uma maior abrangência de mercado,
tornando a solução acessível a praticamente todos os smartphones e tablets disponíveis.
100
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 15606-6:
Televisão digital terrestre - Codificação de dados e especificações de
transmissão para radiodifusão digital Parte 6: Java DTV 1.3.1. ABNT/CEE-085
Televisão Digital. São Paulo , 2010.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 15606-4:
Televisão digital terrestre - Codificação de dados e especificações de
transmissão para transmissão digital – Parte 4: Ginga-J - Ambiente para a
execução de aplicações procedurais. São Paulo, 2010
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 15603-
2:Televisão digital terrestre – Multiplexação e serviços de informação (SI) Parte
2: Estrutura de dados e definições da informação básica de SI. São Paulo,
2008.
AL-MAJEED, S et al. Effective synchronisation of Hybrid Broadcast and
Broadband TV. In: IEEE International Conference on Consumer Electronics ,
2012, Las Vegas, NV. ICCE, Las Vegas: IEEE. p. 160-161.
doi:10.1109/ICCE.2012.6161788.
BORCH, N. et al. An architecture for second screen experiences based upon
distributed social networks of people, devices and programs. In: W3C Web &
TV Convergence Workshop, 2014, Munich, Germany. Multi-screen 1, Munich:
W3C.
BRANDSTEIN, M.; SILVERMAN, H. A robust method for speech signal time-
delay estimation in reverberant rooms. In: IEEE International Conference on, 1.,
1997, Munich. Acoustics, Speech, and Signal Processing, Munich: ICASSP-
97., 1997. p. 375-378. doi:10.1109/ICASSP.1997.599651.
CALIXTO, G. M. et al. Cloud Computing Applied to the Development of Global
Hybrid Services and Applications for Interactive TV. In: International
Symposium on Consumer Electronics , 17., 2013, Hsinchu. ISCE, Hsinchu:
IEEE. p.283-284. doi:10.1109/ISCE.2013.6570229.
101
CANO, P. et al. A Review of Algorithms for Audio Fingerprinting. In: Workshop
on Multimedia Signal Processing, 2002, St. Thomas. Multimedia Systems, St.
Thomas: IEEE Signal Processing Society. p. 169-173.
doi:10.1109/MMSP.2002.1203274.
CHEN, K. et al. DVB-S2 backward-compatible modes: a bridge between the
present and the future. In: International Journal of Satellite Communications and
Networking, 22., 2004, Online. ISI Journal Citation Reports. p. 341 - 365.
doi:10.1002/sat.794.
DEY, A. K. et al. Towards a Better Understanding of Context and Context-
Awareness. In: Proceedings of the International Symposium on Handheld and
Ubiquitous Computing, 1., 1999, Netherlands. Workshop on the What, Who,
Where, When, and How of Context-Awareness, Netherlands: Springer-
Verlag, 1999. p. 304-307.
DUONG, N.; HOWSON, C.; LEGALLAIS, Y. Fast second screen TV
synchronization combining audio fingerprint technique and generalized cross
correlation. In: IEEE International Conference on Consumer Eletronics, 2012,
Berlin. Telecommunications Symposium, Berlin: IEEE. p. 241-244.
doi:10.1109/ICCE-Berlin.2012.6336458.
EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE. Digital
Video Broadcasting (DVB). EN 300 468: .Specification for Service Information
(SI) in DVB systems. European Standard. France, 2010.
EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE. Digital
Video Broadcasting (DVB). EN 300 744: Framing structure, channel coding and
modulation for digital terrestrial television. France, 2007
ESCOBAR, J.; PARTRIDGE, C.; DEUTSCH, D. Flow synchronization protocol.
In: IEEE/ACM Transactions on Networking, 2, 1994. ACM: IEEE. p. 111-121.
doi:10.1109/90.298430.
GEMME, E.; CRAMER, C. How Second Screen synchronization increases the
impact of TV ads. WYWY, Munich, out. 2013. Disponível em: <
102
http://wywy.com/wp-content/uploads/2012/07/131022-wywy-second-screen-
study-english.pdf >. Acesso em: 1 Abr. 2015.
GIGLIETTO, F; SELVA, D. Second Screen and Participation: A Content
Analysis on a Full Season Dataset of Tweets. In: Journal of Communication,
Italy, 2014. Big Data in Communication Research, Italy: Journal of
Communication, Volume 64, Issue 2. p. 260–277 Doi: 10.1111/jcom.12085.
GOOGLE. The New Multi-screen World:Understanding Cross.platform
Consumer Behavior. Google, U.S., ago. 2012. Disponível em: <
https://think.withgoogle.com/databoard/media/pdfs/the-new-multi-screen-world-
study_research-studies.pdf>. Acesso em: 1 Abr. 2015.
HOWSON, C. et al. Second Screen TV Synchronization. In: International
Conference on Consumer Electronics (ICCE-Berlin), 2011, Berlin. TV
Broadcasting & VoD, Berlin: IEEE. p. 361-365. doi:10.1109/ICCE-
Berlin.2011.6031815.
INTERNATIONAL ORGANIZATION FOR STANDARD. ISO/IEC 13818-1:
"Information technology - Generic coding of moving pictures and associated
audio information - Part 1: Systems. 2013.
KOVACEVIC, M. et al. One solution of implementation and display of electronic
program guide on the Android-based digital TV signal receiver. Berlin, 2014.
Third International Conference on Consumer Electronics (ICCE-Berlin).
Berlin: IEEE. p. 1-3. doi:10.1109/ICCE-Berlin.2013.6697994.
PARKER, C. A. The 2nd Screen: Transforming video consumption by enabling
companion applications and content everywhere. 2012. Technical Report. 2nd
Screen Society, p. 30. Disponível em: <
http://www.2ndscreensociety.com/research/report/ >. Acesso em 1 Abr. 2015.
PAVSEK, D.; MOHAR, N. The Second Screen: A growing phenomenon in the
multimedia industry. Beenius, 2013. Disponivel em: <
http://blog.beenius.tv/resources/the-second-screen-a-growing-phenomenon-in-
the-multimedia-industr/ >. Acesso em 1 Abr. 2015.
103
SEGUNDO, R.; SANTOS, C. Second screen event flow synchronization. In:
International Symposium on Broadband Multimedia Systems and Broadcasting
(BMSB), London, 2013. Digital TV Systems, London, 2013. p. 1-7. doi:
10.1109/BMSB.2013.6621761.
SIMON, H.; COMUNELLO, E.; WANGENHEIM, A. Enrichment of Interactive
Digital TV using Second Screen. In: International Journal of Computer
Applications, 64., IJCA, 2013. p. 58-64. doi:10.5120/10782-5764.
SOARES, J. CONNECTED-GINGA: Um Modelo de TV Híbrida para Acesso a
Conteúdo WEB Sensível à Programação de TV. 2012. 112f. Dissertação
(Mestrado em Engenharia de Software) – Centro de Informática, UFPE, Recife,
2012.
SOARES, L. et al. Multiple Exhibition Devices in DTV Systems. In: 17th ACM
International Conference on Multimedia, New York, 2012. MM '09, New
York, 2012. p. 281-290. New York: ACM. doi:10.1145/1631272.1631312.
STEPHEN, K. “Second Screens” unlock new business models. Global Media &
Communications, SPRING, 2012. Disponível em: <
http://www.hoganlovells.com/files/Publication/94462bd1-c3f6-40cf-b85a-
822f7d075630/Presentation/PublicationAttachment/3f67aec7-b513-4d90-89fb-
8369bbb317cc/Second_Screens_Unlock_New_Business_Models.pdf >. Acesso
em: 1 Abr. 2015.
VIGNAROLI, L.; PERO, R.; NEGRO, F. Personalized Newscasts and Social
Networks: A Prototype built over a Flexible Integration Model. In: International
Conference Companion on World Wide Web, 21., New York, 2012. WWW ’12
Companion, New York, 2012. p. 433-436. doi:10.1145/2187980.2188067.
104
APÊNDICE I
A seguir são apresentadas as tabelas com as Descrições dos Casos de Uso não
detalhadas na Seção 3.5 deste documento.
Caso de Uso: 04 Enviar Dados Contextuais
Ator Usuário.
Descrição
Uma vez obtida e validada, os dados contextuais tratados são
enviados via broadcast de rede para todos os dispositivos de
segunda tela registrados nesta mesma rede.
Evento Iniciador Solicitação do conteúdo complementar pela aplicação.
Pré-condição
Aplicação Connected-TVApp em execução na TV, programação
digital com os dados das tabelas de informação de serviço e
eventos já capturados e armazenados.
Pós-condição Dados enviados via broadcast de rede aos dispositivos
registrados.
Extensões Não há extensões.
Inclusões Não há inclusões.
Caso de Uso: 05 Configurar Aplicação Móvel
Ator Usuário.
Descrição
Configuração das preferencias da aplicação Synced-
SecondScreenApp através de um wizard simples, onde o usuário
definirá quais os gêneros televisivos de seu interesse e as formas
de interrupção resultantes da ação de sincronismo para cada um
desses gêneros.
Evento Iniciador Configuração das preferencias da aplicação móvel.
105
Pré-condição Aplicação Connected-TVApp instalada e executando no
dispositivo de segunda tela.
Pós-condição
Configurações feitas e salvas em um sistema de Preferencias do
Android. Inicialização automática dos serviços de
estabelecimento de conexão.
Extensões Não há extensões.
Inclusões
Caso de uso “Iniciar Serviço de Recebimento de Dados
Contextuais”, “Tratar Dados Contextuais Recebidos” e “Exibir
Conteúdo Contextualizado Sincronamente”.
Caso de Uso: 06 Iniciar Serviço de Recebimento de Dados Contextuais
Ator Usuário.
Descrição
Um Service Android, componente de aplicação que pode
executar operações de longa duração independente da UI, é
iniciado sendo responsável pelo estabelecimento de conexões
para o recebimento dos dados contextuais.
Evento Iniciador Configuração das preferencias da aplicação móvel.
Pré-condição Aplicativo Synced-SecondScreenApp instalado, configurado e
executando no dispositivo de segunda tela.
Pós-condição Service Android executando e apto ao recebimento de conexões
de broadcast do módulo Synced-TVApp.
Extensões Não há extensões.
Inclusões Não há inclusões.
Caso de Uso: 07 Tratar Dados Contextuais Recebidos
Ator Usuário.
106
Descrição
Leitura e manipulação dos dados JSON contextualizados
recebidos do módulo Synced-TVApp. Identificação dos pontos de
sincronismo, normalização temporal desses pontos e
gerenciamento das chamadas de carregamento dos conteúdos
complementares.
Evento Iniciador Configuração das preferencias da aplicação móvel.
Pré-condição
Aplicativo Synced-SecondScreenApp instalado, configurado e
executando no dispositivo de segunda tela. Dados contextuais
recebidos.
Pós-condição
Normalização dos tempos dos pontos de sincronismo e
inicialização do módulo responsável pelo carregamento síncrono
dos conteúdos complementares.
Extensões Não há extensões.
Inclusões Não há inclusões.
Caso de Uso: 08 Analisar Pilha de Activities
Ator Usuário.
Descrição
Analisar a pilha de telas de aplicações em execução buscando
identificar a categoria/gênero da aplicação atualmente sendo
utilizada pelo usuário. Esta informação é crucial ao processo de
decisão de quando o usuário deve ser interrompido ou notificado
sobre um novo sincronismo.
Evento Iniciador Configuração das preferencias da aplicação móvel.
Pré-condição
Aplicativo Synced-SecondScreenApp instalado, configurado e
executando no dispositivo de segunda tela. Dados contextuais
recebidos.
Pós-condição Aplicação em execução no topo da pilha de telas do android
identificada.
Extensões Não há extensões.
107
Inclusões Não há inclusões.
Caso de Uso: 09 Exibir Conteúdo Contextualizado Sincronamente
Ator Usuário.
Descrição
Exibição do conteúdo complementar de forma síncrona de
acordo com os valores dos dados contextuais recebido da
aplicação Synced-TVApp.
Evento Iniciador Configuração das preferencias da aplicação móvel.
Pré-condição
Aplicativo Synced-SecondScreenApp instalado, configurado e
executando no dispositivo de segunda tela. Dados contextuais
recebidos.
Pós-condição Conteúdo complementar exibido de forma síncrona.
Extensões Não há extensões.
Inclusões Não há inclusões.
Caso de Uso: 10 Consumir Notificação Sincronizada
Ator Usuário.
Descrição
De acordo com a configuração atribuída a um determinado
gênero televisivo, apenas uma Notification Android será exibida
informando ao usuário de acerca de novos dados contextuais
recebidos.
Evento Iniciador Configuração das preferencias da aplicação móvel.
Pré-condição Aplicativo Synced-SecondScreenApp instalado, configurado e
executando no dispositivo de segunda tela.
Pós-condição Notificação consumida seja para remover a notificação ou aceita-
la e exibir o conteúdo complementar relacionado.
108
Extensões Não há extensões.
Inclusões Não há inclusões.
Caso de Uso: 11 Gerenciar Conteúdo Complementar
Ator Provedor de conteúdo Web.
Descrição
Permite ao administrador do sistema a manipulação dos
conteúdos referentes à grade de programação da emissora para
acesso posterior.
Evento Iniciador Acionamento do serviço.
Pré-condição Synced-WebServers executando e disponibilizando os conteúdos
sobre a grade de programação.
Pós-condição Manipulação do conteúdo Web e posterior envio.
Extensões Não há extensões.
Inclusões Não há inclusões.
Caso de Uso: 12 Gerenciar Metadados da Programação
Ator Transmissora.
Descrição Permite ao administrador do sistema a criação, manipulação e
envio dos metadados referentes aos programas de TV.
Evento Iniciador Acionamento do serviço.
Pré-condição Gerenciador de metadados.
Pós-condição Armazenamento e envio dos metadados à TV.
Extensões Não há extensões.
Inclusões Não há inclusões.
