“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 posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
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
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.
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.
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
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
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.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
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
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
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
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.
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.
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
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.
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,
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).
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 1abaixo.
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
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.
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
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
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.
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.
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
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
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
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.
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
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.
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
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 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
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
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;
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;
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.
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”.
