Geração De Fluxo De Transporte Aderente Ao Sistema Brasileiro De Televisão Digital

UNIVERSIDADE ESTADUAL DE CAMPINAS Faculdade de Engenharia Elétrica e de Computação

Jackelyn Roxana Tume Ruiz

Geração de Fluxo de Transporte Aderente ao Sistema Brasileiro de Televisão Digital

Campinas 2015 Jackelyn Roxana Tume Ruiz

Geração de Fluxo de Transporte Aderente ao Sistema Brasileiro de Televisão Digital

Dissertação de mestrado apresentada à Fa- culdade de Engenharia Elétrica e de Compu- tação da Universidade Estadual de Campi- nas como parte dos requisitos exigidos para a obtenção do título de Mestra em Engenha- ria Elétrica, na Área de Telecomunicações e Telemática.

Orientador: Prof. Dr. Luís Geraldo P. Meloni

Este exemplar corresponde à versão final da dissertação defendida pela aluna Jackelyn Roxana Tume Ruiz, e orientada pelo Prof. Dr. Luís Geraldo P. Meloni

Campinas 2015 Agência(s) de fomento e nº(s) de processo(s): CAPES

Ficha catalográfica Universidade Estadual de Campinas Biblioteca da Área de Engenharia e Arquitetura Luciana Pietrosanto Milla - CRB 8/8129

Tume Ruiz, Jackelyn Roxana, 1983- T83g TumGeração de fluxo de transporte aderente ao sistema brasileiro de televisão digital / Jackelyn Roxana Tume Ruiz. – Campinas, SP : [s.n.], 2015.

TumOrientador: Luís Geraldo Pedroso Meloni. TumDissertação (mestrado) – Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de Computação.

Tum1. Televisão digital. 2. Televisão interativa. 3. Sistema de comunicação em banda. 4. Radiodifusão. I. Pedroso Meloni, Luis Geraldo,1958-. II. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. III. Título.

Informações para Biblioteca Digital

Título em outro idioma: Generating a transport stream complying to brazilian digital TV system Palavras-chave em inglês: Digital television Interactive television Band communication system Broadcast Área de concentração: Telecomunicações e Telemática Titulação: Mestra em Engenharia Elétrica Banca examinadora: Luis Geraldo Pedroso Meloni Paulo Batista Lopes Yuzo Iano Data de defesa: 30-01-2015 Programa de Pós-Graduação: Engenharia Elétrica

Candidato: Jackelyn Roxana Tume Ruiz RA: 134136 Data da Defesa: 31 de Janeiro de 2015 Título da Tese: “Geração de Fluxo de Transporte Aderente ao Sistema Brasileiro de Televisão Digital”

Prof. Dr. Luís Geraldo Pedroso Meloni (Presidente, FEEC/UNICAMP) Prof. Dr. Paulo Batista Lopes (Universidade Presbiteriana Mackenzie ) Prof. Dr. Yuzo Iano (FEEC/UNICAMP)

A ata de defesa, com as respectivas assinaturas dos membros da Comissão Julgadora, encontra-se no processo de vida acadêmica do aluno. Dedico esta tese à minha família. Agradecimentos

Agradeço, A Deus, pela vida que me foi dada e pelas muitas bênçãos recebidas. Obrigada meu Deus por cuidar de mim e colocar em meu caminho as ferramentas para me proteger. À minha família, por estar sempre comigo e por inculcar em mim a fortaleza, segurança e liberdade para cumprir meus sonhos e metas na vida, e um agradecimento especial a minha mãe e ao meu pai, já que todas as minhas conquistas são para eles e por eles, para meus irmãos, vocês são meu coração, obrigada família, vocês são meu suporte e minha alegria, sempre. Ao professor Meloni, pela oportunidade, dedicação, paciência e confiança de- positadas em mim e em meu trabalho. À UNICAMP e aos professores da FEEC, pela educação que recebi. Agradeço a Capes, pelo apoio financeiro e ao SAE, pelo apoio quando procu- rado. Aos amigos e colegas do laboratório e da faculdade que tornaram o ambiente agradável para se viver e trabalhar. A todas as pessoas que de alguma forma contribuíram com minha formação acadêmica e pessoal, e muito obrigada a todos aqueles que me ajudaram sem nem mesmo me conhecerem, o que foi uma motivação a mais no meu dia a dia. ‘Tudo o que um sonho precisa para ser realizado é alguém que acredite que ele possa ser realizado.’ (Roberto Shinyashiki) Resumo

Vivemos na atualidade em um mundo que avança cada vez mais rápido, a globalização está presente no dia a dia das pessoas e graças ao desenvolvimento de novas tecnologias a sociedade está muito mais conetada em comparação a só alguns anos atras.

A interatividade é uma ferramenta muito importante que ajuda o obter e oferecer informa- ção em tempo real, economizando assim tempo, dinheiro, mas sobre tudo está orientada a facilitar, em vários aspectos, a vida das pessoas.

O presente projeto de pesquisa considera o estudo e desenvolvimento de um de modelo para adaptar, implementar e executar o atual sistema brasileiro de televisão digital incluindo funções híbridas de radiodifusão e banda larga, tomando como base ao modelo Hybrid Broadband Broadcast também conhecido como HbbTV.

Palavras-chaves: Televisão digital; Televisão hibrida; Televisão interativa; HbbTV. Abstract

Nowadays we live in a world that moves faster and faster, globalization is present in the daily lives of people and thanks to the development of new technologies, society is now more connected compared to only a few years ago.

Interactivity is a very important tool that helps people getting information in real time, saving time, money but chiefly it is geared to facilitate daily lives.

This research project considers the development of a study model looking for adapting, implementing and executing hybrid functions in the current Brazilian system of digital television, in other words, to send information using broadcasting and broadband, con- sidering as main model that of the Hybrid Broadcast broadband TV standard - HbbTV.

Keywords: Digital Television; Hybrid Television; HbbTV. Lista de ilustrações

Figura 1 – Arquitetura do Ginga (ABNT156062, 2007) ...... 25 Figura 2 – Estrutura de pacotes PES (ABNT.15602-3, 2008) ...... 34 Figura 3 – Fluxo de dados no sistema MPEG Systems ...... 35 Figura 4 – Estrutura de pacotes TS (ABNT.15602-3, 2008)...... 36 Figura 5 – Tabelas de informação específica...... 37 Figura 6 – Arquitetura do sistema IBB (ITU-J.206, 2013)...... 41 Figura 7 – Arquitetura do modelo Hybridcast...... 44 Figura 8 – Modelo HbbTV...... 45 Figura 9 – Funcionalidades presentes na arquitetura do Ginga...... 48 Figura 10 – Segunda tela em sistemas híbridos ...... 50 Figura 11 – Esquema desenvolvido ...... 56 Figura 12 – Teste: Incluindo aplicação Ginga no TS...... 64 Figura 13 – Aplicação Ginga inclusa no TS ...... 65 Figura 14 – Teste: Aplicação Ginga no TS...... 65 Figura 15 – Analisador do TS...... 66 Lista de tabelas

Tabela 1 – Comparação ISDB-T e ISDB-Tb ...... 24 Tabela 2 – Restrições de modos de codificação (ABNT.15602-2, 2008) ...... 29 Tabela 3 – Principais parâmetros de codificação de áudio para serviços one-seg. .33 Tabela 4 – Principais parâmetros de codificação de áudio para serviços one-seg .33 Tabela 5 – Estrutura de pacotes PES e suas seções...... 34 Tabela 6 – Plataformas Ginga e HbbTV...... 48 Tabela 7 – Parâmetros do DtPlay ...... 54 Tabela 8 – Parâmetros da multiplexação no DtPlay ...... 54 Tabela 9 – Geração do PES de vídeo ...... 57 Tabela 10 – Geração do Transport Stream de vídeo ...... 57 Tabela 11 – Geração do ES de áudio ...... 58 Tabela 12 – Geração do PES de áudio ...... 58 Tabela 13 – Geração do TS de áudio ...... 59 Tabela 14 – Multiplexação do TS...... 59 Tabela 15 – Tabela NIT ...... 59 Tabela 16 – Parâmetros da tabela SDT ...... 60 Tabela 17 – Parâmetros da tabela PAT ...... 60 Tabela 18 – Parâmetros da tabela PMT ...... 61 Tabela 19 – Multiplexação do TS ...... 61 Tabela 20 – Multiplexação do TS incluíndo Ginga...... 63 Tabela 21 – Parâmetros dos cabeçalhos das tabelas PSI...... 76 Tabela 22 – Parâmetros da tabela NIT...... 78 Lista de Abreviaturas e Siglas

A-CING Aqua Consult Ingenieros

ABERT Associação Brasileira das Empresas de Rádio e Televisão

AES3 Audio Engineering Society

AIFF Audio Interchange File Format

AIT Application Information Table

AJAX Asynchronous JavaScript and XML

ANATEL Agência Nacional de Telecomunicações

ATSC Advanced Television System Committee

AVC Advanced Video Codec

BAND TV Rede Bandeirantes de Televisão

BML Broadcast Markup Language

BST-OFDM Band Segmented Transmission Orthogonal Frequency Division Multi- plexing

CAT Conditional Map Table

CATV Community Antenna television

CEA-2014 Consumer Electronics Association

CSS Cascading Style Sheets

DA Descrição de áudio

DSL Digital Subscriber Line

DSM-CC Digital Storage Media Command and Control

DVB Digital Video Broadcasting

EBU European Broadcasting Union

ES Elementary Stream

ETSI European Telecommunications Standars Institute FPS Frames por segundo

Ginga-CC Ginga Common Core

Ginga-J Ginga - Java

Ginga-NCL Ginga Nested Context Model

HbbTV Hybrid broadcast broadband TV

HD-SDI High Definition Serial Digital Interface

HDMI High Definition Multimedia Interface

HDTV High Definition Television

HE High Efficiency

HTML HyperText Markup Language

IBB Integrated Broadcast Broadband

IPTV Internet Protocol TV

IRT Institut fuer Rundfunktechnik

ISDB-T Integrated Services Digital Broadcasting Terrestrial

ISDB-Tb Integrated Services Digital Broadcasting-Terrestrial versão B

JS JavaScript

LC Low Complexity

LFE Low-Frequency Effects

LSI-TEC Associação do Laboratório de Sistemas Integráveis Tecnológico

LTE Long Term Evolution

MHP Multimedia Home Platform

MPEG Moving Picture Experts Group

NCL Nested Context Language

NHK Nippon Hoso Kyokai

NIT Network Information Table

OFDM Orthogonal Frequency Division Multiplexing OIP Open IPTV Forum Release

PAT Program Association Table

PCM Pulse-Code Modulation

PCR Program Clock Reference

PES Packet Elementary Stream

PHP Hypertext Preprocessor

PID Packet Identifier

PMT Program Map Table

PS Program Stream

PSI Program Specific Information

PTS Presentation Time Stamp

PUC-RIO Pontifícia Universidade Católica de Rio de Janeiro

RMS Root Mean Square

SAP Programa de áudio secundário

SBR Spectral Band Replication

SBTVD Sistema Brasileiro de TV digital

SDI Serial Digital Interface

SET Sociedade dos Engenheiros de Televisão

SI Serviços da Informação

SQL Structured Query Language

TDT Time and Date Table

UCB Universidade Católica de Brasília

UFABC Universidade Federal do ABC

UFPA Universidade Federal do Pará

UNESP Universidade Estadual Paulista Júlio de Mesquita Filho

UNICAMP Universidade Estadual de Campinas USP Universidade de São Paulo

VCEG Video Coding Experts Group

W3C World Wide Web Consortium at GEIE ERCIM

WAVE Waveform Audio Format

WP Work packages

XHTML eXtensible Hypertext Markup Language Sumário

1 Introdução ...... 18 1.1 Contextualização e motivação ...... 18 1.2 Objetivos ...... 20 1.2.1 Objetivo geral ...... 20 1.2.2 Objetivos específicos ...... 20 1.3 Organização ...... 21 2 A Evolução da Televisão Digital aos padrões híbridos ...... 22 2.1 Televisão digital no Brasil - O SBTVD e o Ginga ...... 22 2.1.1 O middleware Ginga ...... 24 2.1.2 O Processo de transmissão de dados ...... 25 2.2 Codificação de áudio e vídeo ...... 26 2.2.1 Padrão de compressão de vídeo H.264 ...... 27 2.2.2 Codificação de áudio MPEG-2 AAC ...... 28 2.3 Sistema de multiplexação de sinais ...... 34 2.3.1 Formato do Packetized Elementary Stream ...... 34 2.3.2 Formato do Transport Stream ...... 35 2.3.3 Tabelas de informações específicas de programa - PSI ...... 36 2.4 Televisão conetada ...... 38 2.5 Principais padrões de televisão híbrida ...... 39 2.5.1 Integrated Broadcast Broadband ...... 39 2.6 Atuais modelos de televisão híbrida ...... 40 2.6.1 Projeto Youview ...... 40 2.6.2 Hybridcast ...... 41 2.6.3 HbbTV ...... 43 2.7 Principais comparações e semelhanças entre um sistema híbrido e Ginga . . 47 2.7.1 Fator segunda tela ...... 49 3 Ambiente de desenvolvimento ...... 51 3.1 OpenCaster ...... 51 3.2 Opera HbbTV Emulator ...... 52 3.3 Fire HbbTV ...... 52 3.4 Cartão Dektec Multi-Standar VHF/UHF Modulator ...... 53 3.4.1 StreamXpress ...... 53 3.4.2 DtPlay ...... 54 4 Implementação e Avaliação dos Resultados ...... 55 4.1 Abordagem ...... 55 4.2 Recursos ...... 55 4.3 Codificação de arquivos audiovisuais ...... 56 4.3.1 Codificação e empacotamento de vídeo ...... 56 4.3.2 Codificação e empacotamento de aúdio ...... 57 4.3.3 Geração de tabelas PSI ...... 58 5 Conclusão ...... 69 Conclusão ...... 69 5.1 Trabalhos futuros ...... 70

Referências ...... 71

Apêndices 74 APÊNDICE A Artigos do autor ...... 75 APÊNDICE B Arquivo script ...... 76

Anexos 84 ANEXO A Modulação ISDB-T ...... 85 ANEXO B Guia de instalação do OpenCaster ...... 87 ANEXO C Emuladores HbbTV ...... 88 18 1 Introdução

A tecnologia da informação cresceu exponencialmente a partir da segunda metade do século passado, quando surgiram várias invenções no campo das comunicações, tais como os televisores, TVs digitais, telefones celulares, 푠푚푎푟푡푝ℎ표푛푒푠, 푡푎푏푙푒푡푠, entre outros. Hoje em dia, tais aparelhos são usados pelo público de todas as idades, e a televisão conectada é um dos avanços tecnológicos mais destacados nos últimos anos na área de eletrônica de consumo. A TV digital no Brasil nasceu na década de 1990, época em que foram cons- tituídos grupos de estudo e de trabalho, compostos por técnicos da Sociedade dos Enge- nheiros de Televisão (SET) e da Associação Brasileira das Empresas de Rádio e Televisão (ABERT), os quais realizaram testes entre os padrões Digital Video Broadcasting (DVB), Advanced Television System Committee (ATSC) e Integrated Services Digital Broadcasting Terrestrial (ISDB-T). Os estudos não se limitaram a fazer comparações entre as características téc- nicas de cada padrão; assim foram feitos testes de transmissão em ambientes fechados e abertos, que demonstraram que o padrão ATSC apresentava uma qualidade insuficiente na recepção de sinal em ambientes fechados, e dentre os padrões ISDB-T e DVB-T; o primeiro apresentava um melhor desempenho na recepção de sinal através de receptores plenos fixos e móveis, além de oferecer a recepção a dispositivos portáteis no mesmocanal (TV móvel).

1.1 Contextualização e motivação

Em 1998, o Ministério de Comunicações do Brasil encomendou à Agência Na- cional de Telecomunicações (ANATEL) a realização de estudos para escolher e implantar um padrão de televisão digital no Brasil. Dessa forma, foram levados em conta os resultados oferecidos pela SET/ABERT, tornando-os oficiais, com apoio da ideia de se considerar o padrão ISDB-T como melhor opção a ser implantada no Brasil. Finalmente em 26 de novembro de 2003, foi publicado o decreto presidencial (DECRETO4901, 2003) o qual instituiu o programa de Sistema brasileiro de TV digital (SBTVD). Com fruto desse processo, em chamadas em editais públicos, participaram mais de 1200 pesquisadores de universidades, instituições de pesquisa e desenvolvimento, fabricantes do setor eletroeletrônico, emissoras de TV, etc. Após três anos de pesquisa e testes, o grupo de trabalho apresentou o relatório final de seu estudo e a seleção do sistema japonês ISDB-T como base doSBTVD. Capítulo 1. Introdução 19

Uma das características novas do SBTVD consiste no desenvolvimento de um novo 푚푖푑푑푙푒푤푎푟푒 denominado "Ginga", o qual adicionou funções iterativas mais elabora- das. Por outro lado, no ano 2000, a Europa desenvolveu sua principal plataforma de televisão digital: Multimedia Home Platform (MHP). As aplicações desenvolvidas nessa plataforma são transmitidas pelo sinal de radiodifusão e são baseadas principalmente em linguagem Java. O MHP teve sucesso principalmente na Itália, porém em outros países não conseguiu a introdução esperada em virtude de fatos como complexidade para escrever aplicações MHP e o uso de diversas patentes. Dez anos depois do desenvolvimento do MHP e do vasto crescimento do acesso à Internet ocorre a ascensão da televisão com conteúdo iterativo, fato que fez os fabricantes de televisões começaram a incorporar um navegador Web no receptor, as já conhecidas 푆푚푎푟푡−푇 푉 푠 ou 퐶표푛푛푒푐푡푒푑−푇 푉 푠 cada uma com novas e diferentes aplicações para atrair o público. Todavia, também ocorre o problema das incompatibilidades entre as diferentes marcas, pois uma aplicação não vai funcionar necessariamente em duas ou três marcas diferentes de televisões, além do problema de portal de acesso privativo. Nasceu assim a ideia da criação de um padrão que definisse uma só linguagem para todas as TVs conetadas e que fizesse a junção de sinais de 푏푟표푎푑푐푎푠푡 e 푏푟표푎푑푏푎푛푑, ou seja a integração da transmissão por radiodifusão e por banda larga, maximizando assim a iteratividade. Este novo conceito é conhecido como televisão híbrida. Vários padrões de televisão iterativa foram desenvolvidos em diferentes países do mundo, como o Youview, na Inglaterra, desenvolvido pela BBC; o Hybridcast no Japão, desenvolvido pela emissora NHK e o HbbTV na comunidade pan-europeia, todos eles utilizando o sinal de radiodifusão e a banda larga simultaneamente. Dentre as iniciativas para desenvolver e promover o sistema de televisão hí- brida está o projeto Global-ITV (GLOBALITV, 2014), cujo intuito é o de desenvolver a interoperabilidade permitindo a coexistência e convergência da tecnologia HbbTV e o 푚푖푑푑푙푒푤푎푟푒 Ginga, em plataformas de provas de conceito para diferentes sistemas de televisão digital tais como ISDB-T e DVB-T. O projeto GlobalITV é formado por parceiros brasileiros e europeus: IRT, TARA Systems, Retevision–Abertis Telecom, EBU, Fraunhofer, Symelar, A-CING, Sy- melar, W3C, TDF, USP, UNICAMP, UCB, UFPA, LSI-TEC, UFABC, UNESP, HXD Interactive Television e Band TV. O projeto está dividido em seis Work packages(WP), sendo designado cada WP um determinado grupo de trabalho. A UNICAMP é responsável pelo WP3.4 cujo objetivo é a criação de um protótipo da implementação de uma prova de conceito de um sistema de 푝푙푎푦표푢푡. Capítulo 1. Introdução 20

1.2 Objetivos

Entre os principais objetivos do projeto, visa-se conceber uma solução de 푝푙푎푦표푢푡 que tenha o suporte necessário para a adaptação aos principais esquemas de modulação ISDB-T e DVB-T. A motivação principal do presente trabalho encontra-se no fato de conseguir um maior nível de iteratividade no atual sistema digital de televisão brasileiro, tendo como base de estudo o padrão europeu HbbTV, já que o Brasil é país pioneiro na América Latina em adaptar o padrão ISDB-T. Dessa forma, espera-se que as funções híbridas possam incorporar-se ao atual sistema, isto poderia não só ter um contato mais direto entre o radiodifusor e o usuário, e assim conforme o enfoque, poderia também trazer benefícios sociais.

1.2.1 Objetivo geral

O objetivo geral da pesquisa está relacionado com os objetivos do projeto Global-ITV e especificamente com os objetivos que são responsabilidade da UNICAMP, como a criação de um protótipo de uma implementação da prova de conceito 푝푙푎푦표푢푡 do projeto. O projeto Global-ITV procura harmonizar as diferentes soluções atualmente existentes no que se refere à iteratividade da televisão híbrida. Os integrantes do projeto vão unir forças para definir o caminho para o cenário de coexistência em direção àgeração de uma plataforma baseada em televisão híbrida. O escopo do projeto Global-ITV é desenvolver um esquema para a próxima geração do Hybrid Broadcast Broadband System para assim definir os cenários de interoperabilidade e desenvolver arquiteturas de referência. Ao final do projeto, espera-se mostrar serviços e aplicações atrativas para as pessoas em geral.

1.2.2 Objetivos específicos

Os objetivos específicos do presente trabalho de dissertação de Mestrado são:

∙ Pesquisa e desenvolvimento dos protocolos de sinalização aderentes ao ISDB-T,

∙ Estudo do padrão HbbTV,

∙ Elaboração de uma prova de conceito de geração de transport stream aderente ao ISDB-Tb. Capítulo 1. Introdução 21

1.3 Organização

A organização deste trabalho é como segue: o presente capítulo apresenta uma introdução à televisão digital no país, assim como a motivação e os objetivos deste trabalho. O Capítulo 2 aborda uma revisão teórica sobre os temas estudados e necessários para a melhor compreensão e desenvolvimento do atual projeto, tais como os principais padrões de televisão digital relacionados à televisão híbrida e os principais modelos desenvolvidos em diferentes partes do mundo. No Capítulo 3, é discutido o ambiente de desenvolvimento desta pesquisa, em que são mostrados os principais softwares e hardwa- res utilizados. O Capítulo 4 mostra os resultados da presente pesquisa e o Capítulo 5 apresenta as avaliações e os resultados obtidos. Finalmente no Capítulo 6 são realizadas as conclusões deste estudo, que lan- çam algumas possibilidades de trabalhos futuros. O Apêndice A apresenta as publicações geradas durante este trabalho de pesquisa e o Apêndice B as principais tabelas que foram utilizadas para a geração do transport stream. 22 2 A Evolução da Televisão Digital aos pa- drões híbridos

O governo brasileiro optou por implementar o sistema de televisão digital terrestre derivado do padrão de sistema de televisão digital japonês, o ISDB-T. O Sistema brasileiro de televisão digital - SBTVD é também chamado de ISDB-Tb e basicamente é diferenciado do sistema japonês original pelo fato de utilizar o padrão de codificação de vídeo H.264 (também conhecido como Advanced Video Codec (AVC) ou como MPEG-4 part 10) (ISO.14496-3, 2005) em vez do H.262/MPEG-2, como era utilizado no sistema japonês. Nos dispositivos móveis, a taxa de apresentação é de 30 frames por segundo (fps), em contraste aos 15 fps do sistema japonês. O ISDB-T tem a capacidade de proporcionar serviços de High Definition Te- levision (HDTV) em uma largura de banda de canal de 6 MHz e apresenta uma maior eficiência em relação às perdas por interferência, o qual garante uma melhor recepção tanto fixa quanto móvel. O ISDB-T utiliza a técnica da modulação OFDM, de multiplexação em frequência com múltiplas portadoras ortogonais. Também é chamado BST-OFDM, porque utiliza a transmissão fragmentada por bandas, oferecendo tanto a recepção fixa quanto a móvel. Outro fator positivo foi a inclusão do um novo middleware. Middleware é uma camada de software intermediário entre a plataforma de hardware e o sistema de operação; o ISDB-Tb tem um middleware expressivo chamado Ginga (ginga é o principal movimento na expressão cultural da Capoeira) e é composto pela parte declarativa (ABNT156062, 2007) baseada em Nested Context Language (NCL) e pela parte de aplicações de procedimento escritas em linguagem Java DTV (ABNT156066, 2007) . No caso do sistema japonês, o middlware utilizado é o Broadcast Markup Language (BML).

2.1 Televisão digital no Brasil - O SBTVD e o Ginga

O Fórum do Sistema brasileiro de televisão digital é uma organização sem fins lucrativos fundado no ano 2007 e é constituído por empresas privadas e públicas e universidades, as quais são responsáveis pelos aspectos gerais no desenvolvimento da televisão digital no Brasil. Nasceu para direcionar as questões técnicas relacionadas ao SBTVD, conhecido como ISDB-Tb.

Atualmente há em torno de 80 companhias membros do Fórum da SBTVD provenientes de todas as áreas da indústria da televisão, incluindo universidades, radiodi- Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 23 fusores, indústrias de transmissão e recepção, indústrias de desenvolvimento de software, agências reguladoras governamentais, entre outras. Vale ressaltar que a associação ao Fórum é independente da nacionalidade da companhia. Uma das tarefas mais importantes do Fórum da SBTVD é a elaboração de normas técnicas junto a ABNT que proporcionan a interoperabilidade de sisetmas de transmissão e recepção. Assim o padrão brasileiro foi escrito por especialistas no campo das telecomunicações e televisão, procedentes de diferentes companhias e universidades. Tais normas técnicas contêm detalhes dos aspectos da SBTVD e pode ser obtido pela 푤푒푏, no site da ABNT. O projeto GlobalITV espera contribuir com o Fórum da SBTVD nos seguintes aspectos:

∙ Desenvolver uma solução de televisão híbrida,

∙ Desenvolver interoperabilidade com outras soluções de televisão híbrida, iterativa e conectada,

∙ Harmonização da ISDB-Tb com outras tecnologias relevantes.

Atualmente, todos os fabricantes de equipamentos de televisão incorporam o Ginga nos seus equipamentos, pois a partir de 2013 de acordo com a Portaria Interministe- rial Nro. 140 do Ministério de Comunicações, do ano de 2012, 75% de todos os televisores fabricados no Brasil a partir daquele ano precisariam ter instalado o Ginga; para 2014 este porcentual deve chegar a 90%. A partir do período definido no inciso III, a obrigação passa a ser aplicada à totalidade das TVs que disponibilizem suporte à conectividade IP, sem prejuízo do percentual total de aparelhos produzidos. O Sistema brasileiro de televisão digital está baseado nas normas da ABNT NBR 15601 a 15608. A norma ABNT 15601 define a parte da transmissão, a norma ABNT NBR 15602 trata da parte de codificação de vídeo, áudio e multiplexação. As principais normas nas quais se baseiam este trabalho são as normas ABNT NBR 15602-1 correspondente à “codificação de vídeo”, a ABNT 15602-2 correspondente à codificação de áudio e a ABNT 15602-3 correspondente aos sistemas de multiplexação de sinais. Outra norma, a ABNT 15603 trata da “Multiplexação e serviços da informação (SI)”. Este documento está dividido em três partes: ABNT NBR 15603-1 - Serviços da informação para sistemas de radiodifusão digital; ABNT NBR 15603-2 - Sintaxes e definições da informação básica de SI e a ABNT NBR 15603-3 - Sintaxe e definição de informação extendida do SI. A norma ABNT NBR 15604 trata dos temas relacionados aos receptores. A norma ABNT NBR 15605 tem como abordagem a segurança. A norma ABNT NBR 15606 “Codificação de dados e especificações de transmissão para radiodifusão digital” corresponde ao middlware, e está dividida em três partes: ABNT 15606-1 - Codificação Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 24 de dados, ABNT 15606-2 - Ginga-NCL para receptores fixos e móveis-Linguagem de aplicação XML para codificação de aplicações e a norma ABNT 15606-3 - Especificação de transmissão de dados. Finalmente a norma ABNT NBR 15607 cuida os temas relacionados ao canal de iteratividade: protocolos, interfaces físicas e interfaces de software, e a norma ABNT 15608 ao guia de operação. A Tabela 1 amostra uma breve comparação entre o sistema japonês ISDB-T e o sistema brasileiro conhecido como ISDB-Tb

Tabela 1 – Comparação ISDB-T e ISDB-Tb Descrição ISDB-T ISDB-Tb Codec de áudio MPEG-2 AAC HE-AAC H.264 /MPEG-4 Codec de vídeo MPEG-2 parte 10 Middlware utilizado BML Ginga Frame/seg dispositivos 15 30 móveis

Este padrão foi adotado por vários países vizinhos, entre eles: Argentina, Chile, Peru, Equador, Paraguai, Uruguai, Bolívia, entre outros. O SBTVD trabalha com uma largura de banda de canal de 6 MHz igual daquela dos canais de televisão analógica, e isto é feito para evitar problemas de realocação de espectro radioelétrico. Na modulação BST-OFDM, a largura de banda de canal é dividida em 14 segmentos, sendo um segmento reservado para a banda de guarda então a largura de banda fica reduzida a 13 segmentos disponíveis para serviço. A banda de guarda oferece uma margem de tolerância no caso de possíveis interferências com os canais vizinhos, essas margens são conhecidas como “bandas de guarda”, correspondentes a 1/14 da banda do canal (e.g. 6 MHz) e são deixadas metade para cada extremo do canal.

2.1.1 O middleware Ginga

O middlware Ginga é dividido em três partes importantes: Common Core (Ginga-CC), Ginga -J e Ginga-NCL, estas últimas formam parte do ambiente de execução de aplicações. O ambiente de execução de aplicações suporta a execução de aplicações declarativas NCL. As três partes são requeridos pelo SBTVD para terminais fixos e no caso de terminais portáteis o Ginga-J é opcional. O Ginga Core é composto por decodificadores de conteúdo comuns e de procedimentos que podem ser utilizados para preparar os dados que serão transportados, em transport streams. Além disso o Ginga core também deve suportar o modelo conceitual de exibição, segundo a (ABNT15606-1, 2007). A arquitetura Ginga mostrada na Figura 1 foi projetada para ser aplicada a sistemas de radiodifusão. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 25

Figura 1 – Arquitetura do Ginga (ABNT156062, 2007)

Na televisão digital terrestre coexistem dois tipos de linguagens para as apli- cações, a linguagem declarativa e a procedural, a escolha depende do implementador. A linguagem declarativa, a princípio, não requer um especialista em programação, pois não se precisa que cada passo a ser executado seja especificado, só é necessário indicar o conjunto das tarefas que serão desenvolvidos. O Ginga-NCL é um subsistema lógico do middlware Ginga, que tem como base o NCL, que é uma linguagem declarativa desenvolvida pela Pontifícia Universidade Católica de Rio de Janeiro (PUC-RIO) e é responsável pelo processamento de documentos NCL. Um elemento chave para o Ginga-NCL é a máquina de interpretação de conteúdo declarativo, chamado formatador NCL. Outras partes importantes são o exibidor XHTML (inclui interpretadores CSS e ECMAScript) e a máquina de apresentação LUA. A linguagem procedural requer um maior conhecimento, pois dá mais controle sobre o programa, e precisa especificar o fluxo de execução. Um middlware procedural (Ginga-J) é apresentado como uma Java Virtual Machine, incluída como um subsistema lógico do middlware Ginga, encarregado da parte procedural do sistema. Uma parte chave de seu sistema é seu mecanismo de execução do conteúdo procedural, composto por uma máquina virtual Java.

2.1.2 O Processo de transmissão de dados

A informação das aplicações iterativas transmitidas pelo radiodifusor é pelo ar, da mesma forma que a transmissão da televisão tradicional, ou seja, por radiodifusão. O outro caminho é carregar as aplicações direitamente ao Set-top-box, caso seja um STB de desenvolvimento, ou à televisão. Na televisão digital terrestre a transmissão de dados é feita por meio da utili- Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 26 zação do carrossel de dados que consiste no envio de dados ciclicamente. Este envio pode ser feito por meio de dois mecanismos: o carrossel de dados e o carrossel de objetos, am- bos definidos pelo padrão DSM-CC, (ISO.13818-6, 2000). Segundo a norma ABNTNBR 15606-3 (ABNT15606-3, 2007), a transmissão de dados através do carrossel de dados ou de objetos deve ser sinalizada por um PID de 0x0B ou 0x0D. O nome carrossel é usado, pois ele repete os dados em um fluxo de transporte de forma cíclica, semelhante a um carrossel do mundo real. O DSM-CC originalmente foi desenvolvido para fornecer funções de controle de fluxos de áudio e vídeo presentes emum fluxo de transporte. Mais tarde foi modificado para oferecer funções como seleção, acesso e controle de fontes de vídeo e suporte na transmissão de dados num fluxo de transporte, entre outras. A partir da sintonia de um determinado canal, a memória do receptor é reini- ciada. Na recepção do carrossel, verifica-se o momento em que o arquivo X transportado foi carregado em memória e pode ser lançado. Em virtude do fato de que o receptor não tem registro de nenhum arquivo X em sua memória, este vai ser aceito e armazenado na sua memória até ter todos os arquivos necessários para a execução da aplicação. Por exemplo, se para executar uma determinada aplicação tem que se transmitir e executar três arquivos X, Y e Z, mas um deles não é transmitido, então a aplicação não poderá ser executada até que na sua próxima sequência seja transmitida novamente. No momento em que todos os arquivos forem recebidos, o receptor estará pronto para executar a aplicação.

2.2 Codificação de áudio e vídeo

A codificação de vídeo é realizada pelo sistema transmissor e a decodificação de vídeo que é realizada pelo sistema receptor. O codificador de vídeo recebe como entrada o sinal de vídeo bruto e realiza sua compressão, este sinal é, a seguir, enviado ao multiplexador. O sistema de decodificação recebe o sinal que previamente passou pelo demultiplexador do receptor e realiza sua descompressão obtendo como sinal de saída o sinal reconstruído. Atualmente existem vários tipos de compressão de vídeo, sendo que os mais conhecidos foram produzidos pelo Moving Picture Experts Group (MPEG) e pelo Video Coding Experts Group (VCEG). Os padrões mais conhecidos são MPEG-1, MPEG-2 e MPEG-4, no entanto o MPEG-2 é o mais difundido, em razão do baixo custo dos seus circuitos integrados, e corresponde a uma das tecnologias que mais se aprimoraram ao longo do tempo O VCEG tem entre seus padrões mais conhecidos o H.261 e o H.263, e de um trabalho em conjunto, o MPEG e o VCEG desenvolveram o padrão H.264, também conhecido como MPEG-4 parte 10 ou Advanced Video Coding (AVC), e representa um dos Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 27 maiores avanços em relação à compressão de vídeo, já que o H.264 proporciona a metade da taxa de bit oferecido pelo seu antecessor, o MPEG-2. O padrão do transporte do MPEG está nas normas ISO 13818 (ISO.13818-1, 2000) e 14496 (ISO.14496-3, 2005), nas quais são definidas diversas ferramentas para a sincronização de sinais de vídeo, áudio, e dados adicionais incorporados, para assim formar um só fluxo completo que será transmitido. O SBTVD adoptou o padrão H.264 como padrão de compressão de vídeo e é usado em definição padrão ou alta definição. A adoção deste padrão é uma das inovações em relação a outros padrões de televisão digital. Neste sentido, os objetivos do padrão H.264 são conseguir uma melhor taxa de compressão, adaptar o fluxo de conteúdo à transmissão pela rede e ter uma maior robustez frente a ruídos ou erros.

2.2.1 Padrão de compressão de vídeo H.264

O padrão de codificação de vídeo H.264, também conhecido como MPEG4 parte 10 ou Advanced Vídeo Coding (AVC), foi desenvolvido pelo denominado Joint Vi- deo Team (JVT), uma equipe composta por especialistas em compressão de vídeo do ITU-T Video Coding Expert Group (VCEG), e do ISO/IEC Moving Picture Expert Group (MPEG). O intuito do JVT foi criar um padrão que oferecesse uma eficiência de com- pressão de vídeo consideravelmente maior do que os padrões anteriores e que pudesse ser utilizado em qualquer aplicação. O resultado é um padrão que reduz em até 50% a taxa de bits quando compa- rado aos antecessores, além da maior resistência a erros, uma vez que permite flexibilidade da codificação, porém às expensas do incremento na complexidade com respeito aoutros padrões. Em (RAO; HWANG, 2014) e (WIEGAND; SULLIVAN, 2007) há um resumo em termos gerais, do padrão de codificação de vídeo, que é composto por três etapas:

∙ Modelo de predição: toma como entrada o vídeo original bruto, busca reduzir a re- dundância (similaridade) entre pixels vizinhos num mesmo quadro (intra-frame), e entre pixels na mesma posição em quadros adjacentes(inter-frame por compensação de movimento). A ideia é usar algumas amostras do quadro e/ou de quadros adjacentes para predizer o quadro completo. A saída dessa etapa é um quadro residual resultante da subtração do quadro predito do quadro original.

∙ Modelo espacial: nesta etapa, utiliza-se a redundância remanescente entre pixels do quadro residual, sobre eles aplica-se uma transformada, com o que se obtêm coeficientes que serão quantificados para eliminar aqueles não significativos, ficando só com os poucos que carregam a maior energia. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 28

∙ Codificador de entropia: Uma vez quantificados os coeficientes no domínio transfor- mado, estes são colocados junto com os parâmetros de predição da primeira etapa, num codificador de entropia que reduzirá a correlação estatística no fluxo debits, reduzindo assim a taxa final de bits.

Algumas das técnicas utilizadas pela primeira vez no H.264 e que são res- ponsáveis pelo incremento na eficiência de compressão e resistência aos erros são (RAO; HWANG, 2014):

∙ Predição intra-frame adaptativa.

∙ Tamanhos de bloco variáveis.

∙ Codificação de entropia melhorada através de CABACContext ( Adaptive Binary Arithmetic Coding) e CAVLC (Conext Adaptive Variable Length Coding)

∙ Ordenamento flexível de macro-bloco.

Uma das características do H.264 é que pode ser utilizado numa vasta gama de aplicações, porque reconhece que nem todas elas requerem as mesmas configuração em termos de taxa de bits, resolução, qualidade, etc. Assim, o H.264 define perfis os quais implementam apenas um subconjunto das técnicas especificadas no padrão, com o objetivo de melhor atender a um grupo específico de aplicações. Esses perfis são denominados: baseline, extended, main e high.

2.2.2 Codificação de áudio MPEG-2 AAC

De acordo com ITU-T, para todo novo sistema de televisão digital é desejável o uso de seis fluxos de informação de áudio: três fluxos frontais (R-rigth , C-center, L-left), dois fluxos posteriores (Ls-left surround, Rs - right surround) e o fluxo de efeitos de baixa frequência LFE, os quais ocupam só uma fração da taxa de bits dos outros streams. Dos quatro diferentes tipos de arranjos espaciais (mono, estéreo, Dolby Surround e Surround 5.1), o ISDB-Tb pode transmitir em estéreo e 5.1 multicanal simultaneamente, ou mesmo com número de canais maior. A codificação de áudio do sistema brasileiro de televisão digital segue anorma (ABNT.15602-2, 2008), na qual são especificados os parâmetros para os sinais de áudio e sistema de codificação e decodificação de som que vai ser utilizado no SBTVD. Abase destas normas foram as normas do ARIB. Conforme a norma citada acima, as condições gerais para o formato de entrada de áudio devem ser obrigatoriamente as descritas a seguir: Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 29

∙ “Frequência de amostragem do sinal de áudio: 32 kHz, 44,1 kHz ou 48 kHz;

∙ Na configuração de sinais estereofônicos e multicanal (ou seja, sinais consistindo em dois ou mais sinais de áudio para obter uma reprodução envolvente ou espacial do som); a taxa de amostragem para todos os sinais deve obrigatoriamente ser a mesma;

∙ Quantização dos sinais de entrada deve empregar 16 bits ou 20 bits;

∙ Um programa de áudio deve obrigatoriamente ter no mínimo um canal de áudio. O número máximo de canais no programa deve obrigatoriamente ser limitado ao número máximo de canais permitidos pela (ISO.14496-3, 2005);

∙ É recomendado que os programas multicanais sejam preparados conforme a ITU Recommendation (BS.775-1, 1994);

∙ Os programas de áudio em modo multicanal compatíveis com os modos previstos na ITU Recommendation (BS.775-1, 1994) devem obrigatoriamente estar em uma das configurações permitidas na Tabela 2;

∙ No caso de transmissão de somente um programa multicanal sem transmissão de um programa estéreo, o programa multicanal deve obrigatoriamente estar em modo 3/2 (5.0 ou 5.1, com ou sem adição do canal LFE de enriquecimento das baixas frequências) para permitir o downmix para estéreo”.

Tabela 2 – Restrições de modos de codificação (ABNT.15602-2, 2008) Parâmetros Restrição Modos de áudio permitidos Monaural (1/0), estéreo(2/0 e 2/0 + LFE), es- téreo multicanal (3/0, 2/1, 3/1, 2/2, 3/2, 3/2 + LFE) dois sinais de áudio independentes (monaural dual) multi-áudio (três ou mais sinais de áudio) e combinações destes. Modos de áudio recomendados Estéreo (2/0), multicanal (3/2 + LFE)

Principais parâmetros

Formatos

Devem obrigatoriamente ser admitidos fluxos de bits ou arquivos contendo áu- dio digital não comprimido em formato PCM, como WAVE ou AIFF, estéreo e multicanal. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 30

Interfaces

Entre as interfaces (barramentos) de entrada/saída digital permitidos, devem obrigatoriamente estar o (AES/EBU), contendo dois canais PCM por fluxo de bits), serial digital interface (SDI) em alta definição HD-SDI ea High definition multimedia interface (HDMI).

Níveis de sinal de áudio

O nível de referência para a intensidade ou pressão sonora deve obrigatoriamente ser igual a 0 dB SPL. A faixa dinâmica admissível de excursão deve obrigatoriamente ser limitada a +20 dB (headroom) e -70 dB com respeito à referência, corres- pondendo a uma faixa dinâmica típica de 90 dB. Convém que os níveis de áudio médio estejam a −20푑퐵 Full Scale (0 dB), para possibilitar homogeneidade no volume entre canais distintos. O sinal deve acomodar picos de no mínimo 4 vezes sua potência média root mean square (RMS).

Modos ou configurações multicanal

O modo de transmissão refere-se à configuração multicanal utilizada, ao nú- mero de canais disponíveis no fluxo de bits e à forma de codificação desses canais.O número de canais de áudio fonte deve obrigatoriamente ser no mínimo um para uma con- figuração básica, dois para transmissão padrão estéreo típico e cinco canais mais umcanal de baixas frequências (LFE) para transmissão multicanal “5.1” padrão. Os sinais fontes devem obrigatoriamente ser pré-processados e/ou combinados previamente à entrada do codificador, para produzirem os canais de transmissão que devem obrigatoriamente estar presentes no fluxo de bits. Uma mesma programação de áudio pode ser transmitida em mais de um modo, por exemplo, em estéreo (dois canais) mais modo multicanal 3/2 (5.1) simultaneamente, porém a transmissão simultânea não é obrigatória. No caso da trans- missão exclusiva em modo multicanal 3/2 (5.1), os receptores devem obrigatoriamente ser capazes de sintetizar o sinal estéreo por meio de conversão ( downmixing ), operações de replicação, dematrixing, combinação e processamento de sinal no âmbito funcional do sistema de reprodução de áudio do receptor.

Metadatos

No processo de codificação, dados auxiliares quando presentes, devem obrigatoriamente conter informações como descrições de conteúdo dos programas de áudio, parâmetros de configuração dos serviços de áudio e parâmetros dos sinais de áudio transmitidos no fluxo de bits. Podem ser admitidos como tipos de dados auxiliares: Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 31

∙ descrição do conteúdo dos programas de áudio sendo transmitidos (por exemplo, classificação de programa sonoro, descrição dos objetos de áudio mixados nocon- teúdo, descrição do conteúdo do canal de áudio auxiliar etc.);

∙ modo multicanal;

∙ volume de referência para operações de equalização na reprodução no receptor (loud- ness control).

Os dados auxiliares e a descrição de conteúdo de programas de áudio podem ser classificados em dois níveis. Um primeiro nível deve obrigatoriamente ser normativo. Esse nível deve afetar diretamente a operação do receptor (decodificação dos fluxos de bits) como, por exemplo, informação de quantidade e modo dos canais, perfil e nível de codificação extraídas diretamente das tabelas PSI. Os dados nesta categoria devem obrigatoriamente ser essenciais para a decodificação e reprodução correta do serviço de áudio no receptor. Um segundo nível deve obrigatoriamente ser informativo. Esse nível não deve afetar a decodificação, mas sim trazer informações sobre os conteúdos dos programas de áudio associados a cada PID. Os dados nesta categoria devem obrigatoriamente ser usados para processamento de informação sobre os programas no receptor.

Serviços de áudio e canais auxiliares

Os serviços de áudio incluem a transmissão de programas de áudio adicionais ao programa principal e são obrigatoriamente considerados serviços opcionais, com exceção do serviço de Áudio Descrição (DA), cuja transmissão é obrigatória conforme legislação vigente. A transmissão destes serviços deve ser realizada através da alocação de canais de áudio auxiliares adicionais em programas de áudio (PID) distintos, ou no mesmo fluxo de bits de um mesmo PID, respeitando-se sempre o número máximo de canais permitidos no fluxo de bits pelo perfil/nível de codificação usado. Canais adicionais ao programaprin- cipal podem ser utilizados para transmitir áudio em outros idiomas (como, por exemplo, Programa de áudio secundário (SAP)), para transmitir serviços de áudio descrição, para transmitir programas adicionais ao programa principal e áudio secundário proveniente de outras tomadas de som. Todos os canais adicionais referentes aos serviços de áudio auxiliares devem ser obrigatória e apropriadamente sinalizados utilizando uma identificação válida de tipo de componente ( component_type ) no respectivo descritor de áudio ( au- dio_component_descriptor ) do programa. Os canais auxiliares devem obrigatoriamente ser transmitidos em programas distintos (PID distintos), com a devida sinalização e iden- tificação de seus canais, para serem selecionados, decodificados e reproduzidos juntamente com ou em substituição aos canais de áudio do programa principal. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 32

Sistema de codificação de áudio

Os sinais de áudio devem obrigatoriamente ser codificados por um mecanismo de codificação por transformada em frequência e processamento no tempo bloco abloco.A transformada em freqüência decompoe o sinal de entrada em seus componentes de frequên- cia empregando a transformada discreta do cosseno (MDCT – 푀표푑푖푓푖푒푑 퐷푖푠푐푟푒푡푒 퐶표푠푖푛푒 푇 푟푎푠푛푠푓표푟푚) permitindo a redução de informação e buscando-se preservar o conteúdo em frequência de cada componente. A compressão de áudio e os procedimentos de transmissão devem obrigatoriamente ser compatíveis com a ISO/IEC 14496-3. O decodificador deve obrigatoriamente ser construído assumindo-se que qualquer estrutura válida da ISO/IEC 13818-1, incluindo-se descritores privados no fluxo de bits. O decodificador de áudio deve obrigatoriamente desconsiderar estruturas “reserva- das” ou aquelas que correspondem a funções não implementadas pelo receptor.

Procedimentos para compressão e transmissão de áudio

O fluxo de bits deve obrigatoriamente ser configurado conforme anormaem referência (ISO.14496-3, 2005).

Perfis e níveis

A codificação de áudio deve obrigatoriamente ser compatível com anorma (ISO.14496-3, 2005). Os seguintes perfis e níveis do padrão MPEG-4 AAC devem obrigatoriamente ser permitidos:

∙ LC (Low Complexity), perfil básico do padrão AAC; níveis L2 eL4;

∙ HE (High Efficiency), perfil avançado de alta eficiência, combinando o perfil LC com o uso da ferramenta SBR (Spectral band Replication) para a versão 1 deste perfil, níveis L2 e L4;

∙ HE combinado à ferramenta PS (푃 푎푟푎푚푒푡푟푖푐 푆푡푒푟푒표) para a versão 2 deste perfil; nível L2.

Camada de transporte e multiplexação

A codificação e o empacotamento (푓푟푎푚푖푛푔) intermediário do áudio devem obrigatoriamente ser compatíveis com LATM/LOAS, conforme a norma (ISO.14496-3, 2005). O 푒푙푒푚푒푛푡푎푟푦 푠푡푟푒푎푚 deve obrigatoriamente ser primeiramente encapsulado no formato de transporte LATM e deve obrigatoriamente utilizar o elemento de multiplexação AudioMuxElement. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 33

O áudio MPEG-4 transportado no fluxo de transporte MPEG-2 (TS), utilizando- se a sintaxe de transporte LATM/LOAS deve obrigatoriamente ser identificado por 푠푡푟푒푎푚_푡푦푝푒 0x11 de acordo com o 푠푡푟푒푎푚_푡푦푝푒 푎푠푠푖푔푛푚푒푛푡푠 na norma em referência (ISO.13818-1, 2000) Os principais parâmetros do sistema de codificação de áudio devem obrigatoriamente atender à Tabela 3.

Tabela 3 – Principais parâmetros de codificação de áudio para serviços one-seg. Parâmetros Restrição Mecanismos de transporte permitidos LATM/LOAS, conforme (ISO.14496-3, 2005) Números de canais recomendados Mono (1.0), 2 canais (estéreo ou 2.0), ou multicanal (5.1) Perfis e níveis permitidos Low complexity AAC: nível 2 (LC-AAC L2) para dois canais. Low complexity AAC: nível 4 (LC- AAC@L4) para multicanal High Efficiency (HE): nível 2 (HE-AAC v1@L2) para dois canais High Efficiency (HE): nível 4 (HE-AAC v1@L4) para multicanal Taxa máxima de bits permitida Conforme (ISO.14496-3, 2005) Amostras por quadro frameLengthFlag em GASpecificConfig() deve ter valor 0 indicando que a extensão do quadro deve ser de 1024 amostras para AAC e 2048 quando usando a SBR. Não devem ser utilizadas 960 amostras para AAC (ou 1 920 quando usando SBR).

Os principais parâmetros de codificação de áudio para dispositivos portáteis devem obrigatoriamente atender à Tabela 4

Tabela 4 – Principais parâmetros de codificação de áudio para serviços one-seg Parâmetros Restrição Mecanismos de transporte permitidos LATM/LOAS, conforme (ISO.14496-3, 2005) Perfis e níveis permitidos High efficiency (HE): nível 2 (HE-AAC v2@L2) Número máximo de canais codificados 2 canais por fluxo de bits (estéreo ou 2 canais mo- naurais) Taxa máxima de bits Conforme (ISO.14496-3, 2005)

A versão 2 do MPEG-4 AAC-HE deve obrigatoriamente ser adotada para transmissão para dispositivos móveis e também é obrigatória para dispositivos fixos, caso estes forem recuperar o serviço one-seg. Um componente básico do MPEG é o fluxo elementar 퐸푙푒푚푒푛푡푎푟푦 푆푡푟푒푎푚 (ES) o qual é um fluxo contínuo de dados que contém informação de uma única fonte, ou seja, informação só de áudio ou só de vídeo; não contém informação de sincronização relativa a outros fluxos mas transporta informação de ordenação interna das imagens de Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 34 vídeo ou quadros de áudio. Um conjunto de ES pode formar um programa completo com diversas informações como áudio, vídeo, legendas, etc.

2.3 Sistema de multiplexação de sinais

A transmissão de sinais de áudio e vídeo codificados segue a especificação na norma em referência (ABNT.15602-3, 2008) que indica que os sinais codificados devem ser multiplexadas através de pacotes e devem estar agrupados para um comprimento arbitrário de pacotes, esencialmente devem obedecer à estrutura de pacotes PES.

2.3.1 Formato do Packetized Elementary Stream

O padrão MPEG oferece duas camadas de multiplexação. A primeira é chamada Packet Elementary Stream (PES) e é utilizada para garantir a sincronização entre dados de áudio, vídeo e outros dados. Todos os ES são agrupados em pacotes chamados PES. Os pacotes têm um tamanho maximo de 64kbytes e começam com um cabeçalho (ℎ푒푎푑푒푟) de 6 bytes no mínimo, os primeiros 3 bytes são do campo start code prefix e sempre é 00 00 001 que é utilizado para identificar um pacote PES. O byte seguinte éo campo 푠푡푟푒푎푚 퐼퐷 o qual descreve o tipo de elementary stream que é transportado no 푝푎푦푙표푎푑 seja de áudio, vídeo ou dados. Cada PES é identificado com um Packet Identifier(PID) de 13 bits no cabe- çalho que permite posteriormente sua demultiplexação. As seções dos pacotes PES são mostradas na Tabela 5 e na Figura 2

Tabela 5 – Estrutura de pacotes PES e suas seções. Cabeçalho 48 bits Cabeçalho opcional Payload 8xN bits

Figura 2 – Estrutura de pacotes PES (ABNT.15602-3, 2008)

O cabeçalho deve obrigatoriamente ser utilizado para identificar o tipo do pacote PES. O cabeçalho opcional deve obrigatoriamente ser utilizado para transmitir informações adicionais do cabeçalho. O 푝푎푦푙표푎푑 deve obrigatoriamente ser utilizado para transmissão dos dados ‘N’ e deve obrigatoriamente representar um número inteiro positivo. A outra camada agrupa os pacotes PES e é dependente do meio de comunicação que vai ser utilizado. Para ambientes livres de erro usa-se o Program Stream (PS). O PS é o resultado de agrupar num só fluxo um ou mais PES com uma base de tempo comum Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 35 na qual estão referidos os 푡푖푚푒푠푡푎푚푝푠 insertados no cabeçalho PES. Para ambientes que apresentam erros ou ruídos é utilizado o Transport Stream (TS), como por exemplo o ISDB-T. Em resumo, o ES é formado por AUs, a sua vez os ESs são transportados em pacotes PES, que por sua vez, são transportadas por pacotes TS. O TS é utilizado em ambientes com ruído ou erros, que podem ser originado por perdas de bits ou perdas de pacotes, como se observa na Figura 3

PS Program Stream MUX Vídeo ES PES Codiﬁcador Empacotador Vídeo

Áudio ES PES Codiﬁcador Empacotador Áudio

TS Transport Stream MUX

DADOS

Figura 3 – Fluxo de dados no sistema MPEG Systems

2.3.2 Formato do Transport Stream

Como resultado de se combinar um ou mais programas num só fluxo sobre uma base de tempo comum; o fluxo TS é composto por pacotes de tamanho fixo: 4bytes de cabeçalho e 184 bytes de payload, num total de 188 bytes, mas podem ser agregados bytes adicionais para correção de erros como no caso do SBTVD onde o tamanho total dos pacotes enviados na transmissão é de 204 bytes, sendo utilizados 188 bytes para o TS e 16 bytes para a correção de erros e outras informações. O fluxo TS pode conter diversos tipos de pacotes PES, e é identificado com o PID que indica que tipo de dado contém um determinado fluxo TS. Os pacotes TSe ES podem ter taxa fixa ou variável; a taxa do TS é definida pelos valores doscampos que contêm o relógio de referência do programa PCR o qual é uma informação de sincro- Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 36 nização do receptor necessária para a decodificação do vídeo, áudio, dados, e é incluído periodicamente nos pacotes de transporte. O receptor precisa dessa informação do PCR em aproximadamente dez vezes por segundo. Na representação hexadecimal os TS começam com o identificador de pacotes PID de 13 bits que está contido num prefixo de 4 bytes, o PID indica o conteúdo dos dados dos pacotes TS fazendo uso das tabelas de informação especificas de programa PSI. De acordo à norma ABNT NBR 15602-3 (ABNT.15602-3, 2008) os pacotes TS devem atender o formato da Figura 4

Figura 4 – Estrutura de pacotes TS (ABNT.15602-3, 2008).

O Campo 푆푦푛푐 푏푦푡푒 ou byte de sincronismo deve ser obrigatoriamente 0x47. O campo 푇 푟푎푛푠푝표푟푡 푒푟푟표푟 푖푛푑푖푐푎푡표푟 ou indicador de erro de transporte deve ser obrigatoriamente um flag de 1 bit indicativo da presença de qualquer erro debitno pacote TS. Se a sinalização contém o valor de "1"indica a presença de um erro incorrigível de pelo menos 1 bit. O campo 푃 푎푦푙표푎푑 푢푛푖푡 푠푡푎푟푡푖푛푑푖푐푎푡표푟 ou indicador de início é um flag de 1 bit que deve indicar obrigatoriamente que o payload deste TS deve iniciar

2.3.3 Tabelas de informações específicas de programa - PSI

O 푀푃 퐸퐺 − 2 푇 푟푎푛푠푝표푟푡 푆푡푟푒푎푚 está baseado em várias 푚푒푡푎푑푎푡푎 푡푎푏푙푒푠, tabelas de informação, chamadas PSI ou tabelas de informações específicas de programa, necessárias para a correta demultiplexação por parte dos decodificadores. A PSI é composta por cinco tabelas, cada uma com seu próprio PID e uma função específica.

∙ Program Association Table (PAT) ou tabela de associação de programa.

∙ Conditional Map Table (CAT) ou tabela de acesso condicional

∙ Program Map Table (PMT) ou tabela de mapeamento de programa

∙ Network Information Table (NIT) ou tabela de informação da rede

∙ Time and Date Table (TDT) ou tabela de hora e data. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 37

A tabela PAT é a tabela principal do um TS, indica os valores de PID das outras tabelas e serve para estabelecer a correspondência entre o número de programa e o PID dos pacotes TS. A tabela PMT faz uma descrição de todos os conteúdos que fazem parte de um programa, assim especifica quais ES estão associados e vão formar cada programa. Dessa forma o receptor decodifica só os ES necessários que vão ser transmitidos no programa nesse momento. As tabelas PAT e PMT são enviadas dez vezes por segundo e cada tabela ocupa um pacote de 188 bytes, então serão enviados 188*8 bits cada segundo -> 15040 bps. A tabela NIT contém informação relacionada às frequências dos canais e outros aspectos referentes aos canais de transmissão. Em contrapartida, a tabela CAT só é acessada quando o TS é codificado para fins de acesso condicional, ausente na televisão aberta. Na Figura 5, pode-se verificar as principais tabelas de informação. As tabelas SDT, NIT, AIT serão enviadas a uma taxa de (tamanho do pacote em byte)*(8bits/byte)/(máximo intervalo para enviar as tabelas por segundo) -> (188byte)x8/(0.5 segundos) = 3008bps

PCR

Áudio Programa 1 PAT PMT 1 Vídeo

Data

PCR

Áudio Programa 2 PMT 2 Vídeo

Data

PCR

Áudio Programa N PMT N Vídeo

Data

CAT

NIT

Figura 5 – Tabelas de informação específica. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 38

2.4 Televisão conetada

Nos últimos anos o mundo foi testemunha da rápida penetração no mercado da televisão conectada, comumente chamada 푆푚푎푟푡 푇 푉 . Os fabricantes de tecnologia de consumo disponibilizam receptores set-top-boxes que oferecem aos consumidores conexão à Internet tanto por ethernet quanto pelo WiFi. Tais dispositivos têm a capacidade de acessar serviços baseados em Internet mas ainda limitados a ofertas específicas. O mercado dos dispositivos conectados cresceu exponencialmente durante os últimos anos. Os usuários podem receber aplicações praticamente a partir de qualquer dispositivo, seja 푡푎푏푙푒푡, 푠푚푎푟푡푝ℎ표푛푒, televisão conectada, entre outros. Há ainda a ques- tão dos vendedores proprietários de aplicações e alianças que podem ser feitas com os fabricantes. Contudo, as TVs conectadas estão baseadas em tecnologias bem estabelecidas e os fabricantes incluem acessibilidade 푤푒푏 em seus dispositivos, mas as soluções nem sempre funcionam da forma esperada, pois alguns 푤푒푏푠푖푡푒푠 não são navegáveis pelos controles remotos convencionais. Além disso, os atuais set-top-boxes estão limitados ao avanço da tecnologia e não têm suporte completo para alguns 푠표푓푡푤푎푟푒푠 por exemplo Flash, Java, HTML5, etc., os quais não deixam uma experiência totalmente gratificante aos usuários. Ter uma televisão conectada não significa que seja capaz de suportar uma experiência iterativa ou uma experiência híbrida, pois embora tenha duas entradas, uma delas para sinal de radiodifusão (seja DVB ou ISDT-B) e outra para a internet (seja ethernet ou WiFi), eles não necessariamente oferecem convergência pois fazem trabalhos e percursos independentes, não oferecendo sincronismo de fluxos de radiodifusão e banda larga. Em resumo, a maior parte das TVs conectadas atualmente só consegue se conectar a portais web proprietários que contêm aplicações que estão sob o controle dos fabricantes. Separadamente, eles operam como um terminal de Internet com funcionalidades limitadas da Internet ou como uma televisão, com serviço de radiodifusão tradicional, e é por esta razão que ainda não se pode falar de convergência num modelo como este. Para uma experiência real híbrida é requerido que seja estabelecido um laço entre o conteúdo broadcast (seja via redes satélite ou cabo) e o conteúdo oferecido via canal de Internet, o que pode ser feito mediante um sistema adequado de sinalização via canal de iteratividade, seja via ethernet em Digital Subscriber Line (DSL) ou via ethernet via Community Antenna television (CATV) e, no caso das redes de banda larga móveis a conexão pode ser com redes como Long Term Evolution (LTE) ou outra rede IP disponível. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 39

2.5 Principais padrões de televisão híbrida

Atualmente há dois padrões principais sobre os quais estão baseados os modelos mais importantes de televisão híbrida os quais nasceram para estabelecer propostas de sistemas de iteratividade.

2.5.1 Integrated Broadcast Broadband

O padrão Integrated Broadcast Broadband (IBB) é o padrão internacional da ITU e foi publicado como padrão BT.2037. Inicialmente foi criado um arcabouço para os sistemas IBB atualmente materializados nos padrões J.205 e J.206:

∙ A Recomendação ITU-T J.205 : J.acf-req “Requirements for an Integrated Broad- cast and Broadband DTV application control framework”. Esta recomendação define os requisitos para estabelecer um ambiente que dê suporte ao sistema integrado broadcast broadband. A recomendação ITU-R BT.2053 tem igual objetivo ao referido no J.205.

∙ A Recomendação ITU-T J.206 : J.acf-arch "Architecture and guidelines for na In- tegrated Boradcast and Broadband DTV application control framework”. Essa re- comendação define a arquitetura para implementar a plataforma que suporte todos os requisitos para o sistema integrado broadcast broadband.

O padrão BT.2037 tem como título em português: "Requisitos gerais para aplicações centradas em radiodifusão de sistemas integrados broadcast-broadband (IBB) e sua utilização prevista". Ele define os requisitos gerais para aplicações de sistemas de televisão digital IBB. Esse sistema tem por base a combinação de especificações técnicas e processos operacionais relacionados, os quais juntos definem como os serviços podem ser prestados para o usuário final baseados em uma combinação de mecanismos de transmissão usando a radiodifusão atualmente existente e as telecomunicações por banda larga. Entre as principais recomendações detalhadas no padrão ITU-R BT.2037, es- tão:

1. Manter a interoperabilidade com sistemas existentes. O novo sistema não pode criar conflito com os sistemas que estão atualmente em operação; isto é requerido para minimizar o impacto da introdução dos sistemas IBB no atual sistema de radiodi- fusão, do contrário geraria demora na implantação e custos elevados tanto para os radiodifusores quanto para os usuários.

2. Prover novos serviços como acesso a conteúdo linear e não linear assim como inte- gração com outros dispositivos, as chamadas ’segunda tela’, sejam telefones móveis, Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 40

tablets, entre outros. A maior diferença entre o sistema IBB e os serviços baseados na web é a capacidade de combinar aplicações multifuncionais com os programas transmitidos normalmente pelos radiodifusores. Há que se ter em foco o usuário, facilitando seu acesso. Tem que suportar conteúdo para pessoas com alguma deficiência, assim como mostrar ser capaz de apresentar conteúdo para casos de emergências.

3. Preservar os interesses das partes envolvidas na solução. Os radiodifusores têm um grande interesse em assegurar a preservação de seu conteúdo e evitar as sobreposições não autorizadas. O conteúdo não deve ser alterado de nenhum modo pelas aplicações IBB. Os comportamentos suspeitos e maliciosos tais como vírus, 푚푎푙푤푎푟푒푠 etc. devem ser evitados para proteger a segurança e os dados pessoais dos usuários para assim incentivar a conversão, em especial os radiodifusores.

4. Ter como objetivo uma implementação simples do sistema integrado fazendo uso de tecnologias compatíveis com as tecnologias existentes, fazendo uso de tecnologias livres e mundiais tanto quanto seja possível.

Segundo a especificação ITU-T J.206 (ITU-J.206, 2013), a arquitetura deum receptor IBB é como ilustrado na Figura 6 No ano 2013, a ITU-R desenvolveu o relatório BT.2267 (ITUBT.2267, 2014) sobre o título: "Integrated broadcast-broadband system"ou Sistemas integrados de radi- odifusão e banda larga, que contém informações sobre os sistemas atuais de televisão iterativa, cujas arquiteturas assemelham-se a um sistema integrado broadcast-broadband entre eles o Hybridcast, o HbbTV e Ginga.

2.6 Atuais modelos de televisão híbrida

Na atualidade, varios modelos de sistemas híbridos estão sendo desenvolvidos em diferentes países do mundo, por exemplo Japão e a comunidade pan-europeia. Assim tais sistemas enviam informação não só a nivel de radiodifusão, também enviam a nivel de banda larga.

Entre os principais modelos de televisão híbrida temos os detalhados a seguri.

2.6.1 Projeto Youview

O projeto Youview foi lançado na Inglaterra em julho 2012. É um sistema híbrido com características próprias e adaptado ao mercado britânico. O Youview tem Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 41

Figura 6 – Arquitetura do sistema IBB (ITU-J.206, 2013). parceria com duas operadoras de telefonia (BT TV, Talk Talk Plus TV) e quatro radiodifusores (BBC, ITV, Channel 4 e Channel 5), e se trata da evolução do antigo "Projeto Canvas"da BBC. Inclui acesso à televisão digital terrestre gratuita e a serviços via broadband como VOD, EPG integrado etc. O Youview sofreu diversos atrasos em sua entrada no mercado que foi adiada por dois anos; atualmente, alguns fabricantes de STB vendem receptores Youview no mercado, pois ainda não há implementações em TVs. Vale lembrar que no início foi duramente criticado pelo fato de ter um preço muito alto, em torno de 300 libras.

2.6.2 Hybridcast

A Nippon Hoso Kyokai (NHK), emissora nacional do Japão, desvendou seu próprio sistema híbrido de radiodifusão e banda larga, o Hybridcast, lançado em setembro de 2013. O Hybridcast TV permite ao espectador assistir tanto por radiodifusão quanto por banda larga na mesma tela de televisão, e os dois serviços podem ser ligados e inter- relacionados. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 42

A versão 1.0 do Hybridcast foi padronizada pelo Open IPTV Forum Japan. O Hybridcast permite oferecer uma variedade de serviços por combinação de transmissão de banda larga e recursos de radiodifusão. O sistema considera os cenários principais da Recomendação ITU-T J.205. A especificação também define um mecanismo para funções de colaboração com dispositivos móveis (푡푎푏푙푒푡푠 ou 푠푚푎푟푡푝ℎ표푛푒푠).

Principais características:

∙ Customização de programas e conteúdo (com sincronização de mídias),

∙ TV Social,

∙ Recomendações de programas,

∙ Conexão com Smart Devices.

Modelo do sistema :

Os principais componentes do sistema na especificação do Hybridcast são: radiodifusor, provedor de serviços e receptor.

(1) Radiodifusor: O radiodifusor fornece sinais de radiodifusão digital, metadados e con- teúdo de vídeo para prestadores de serviços. No sinal de transmissão, sinais de controle de aplicativos e informações de permissão podem ser transmitidos para notificar quais os aplicativos disponíveis e informações para executá-los, assim como a permissão para acessar os dados e recursos do sinal de TV. Mediante um contrato, os prestadores de serviços podem obter metadados e conteúdo de vídeo da emissora e oferecê-lo aos usuários finais.

(2) Provedor de serviços: O provedor de serviços é a "figura-chave"que presta serviços a partir deste sistema. Ele produz/distribui conteúdo e aplicações que oferecem servi- ços aos usuários e opera servidores para permitir que cada serviço esteja disponível. É possível que o provedor forneça 푙푖푛푘푠 com informações a outros prestadores de serviços. As interfaces de software (APIs) disponibilizadas para a comunicação entre o ambiente (푓푟푎푚푒푤표푟푘) Hybridcast no receptor e os servidores não são padronizadas, pois podem ser específicas de cada serviço e podem ser livremente definidas pelo provedor. Algunspro- vedores de serviços podem oferecer um repositório de aplicações. O repositório registra aplicativos que podem ser baixados pelos usuários e fornece listas de aplicações de acordo com pedidos de acesso dos receptores. O uso e acesso a um repositório é considerado, principalmente, para aplicações genéricas sem ligação com o conteúdo do radiodifusor, o qual pode prescindir de um provedor de serviços e atuar nos dois papéis. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 43

(3 ) Receptor: O receptor que provê um ambiente (푓푟푎푚푒푤표푟푘) Hybridcast fornece fun- ções para executar aplicações, apresentar informações e conteúdos controlados pela apli- cação e interagir com os usuários e / ou com outros dispositivos, bem como para receber e apresentar o conteúdo de radiodifusão. O receptor fornece funções padronizadas e interfaces (APIs) para a execução das aplicações. A função de colaboração com dispositivos móveis como tablets e smartphones permite que a aplicação Hybridcast possa interagir com esses dispositivos que devem estar ligados ao receptor dentro de uma mesma rede doméstica (ℎ표푚푒 푛푒푡푤표푟푘), geralmente por Wi-Fi.

Tipos de aplicação No sistema Hybridcast, existem três tipos de aplicações de acordo com os serviços de radiodifusão.

∙ 퐵푟표푎푑푐푎푠푡 − 표푟푖푒푛푡푒푑 푚푎푛푎푔푒푑 푎푝푝푙푖푐푎푡푖표푛푠 - são as aplicações que são controlados por sinal de controle de aplicação no sinal de transmissão. As aplicações são iniciadas ou terminadas pelo controle da emissora e têm permissão para acessar os recursos de transmissão com base nas informações de permissões nos sinais de controle. Podem continuar o seu funcionamento se a aplicação se tem ativada a instruçãp AUTOSTART.

∙ 푁표푛 − 퐵푟표푎푑푐푎푠푡 − 표푟푖푒푛푡푒푑 푚푎푛푎푔푒푑 푎푝푝푙푖푐푎푡푖표푛푠 - são as aplicações que não são iniciadas ou terminadas pelo controle da emissora no sinal de transmissão, mas são autenticadas pelas emissoras por meio de outros meios no sinal de transmissão. Após autenticadas, essas aplicações também têm permissão dos broadcasters para acessar o conteúdo do sinal.

∙ 퐺푒푛푒푟푎푙 푎푝푝푙푖푐푎푡푖표푛푠 - nome geral para aplicações que não correspondem a qualquer um dos dois tipos acima. As aplicações stand alone não são permitidas para presentações simultâneas com programas de radiodifusão.

Comparando a arquitetura do modelo Hybridcast com a do padrão IBB, é possível observar na Figura 7 os campos em comum.

2.6.3 HbbTV

HbbTV é um modelo específico da televisão híbrida desenvolvido sobre opa- drão DVB e proporciona um mecanismo que integra serviços de radiodifusão e banda larga. O HbbTV foi desenvolvido em 2009 e estabelecido oficialmente em 2010. A informação sobre o padrão HbbTV é detalhada no documento ETSI TS 102 796 v.1.1.1 Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 44

Figura 7 – Arquitetura do modelo Hybridcast.

(ETSI-102.796, 2010) cujo consórcio é atualmente composto por empresas de radiodifusão e da indústria da eletrônica de consumo. Na Europa, o padrão HbbTV está implementado em vários países europeus, entre eles Alemanha, França, Espanha, Áustria, República Checa, Dinamarca, Polônia, Suíça, Países baixos e Turquia, mas a maior penetração encontra-se na Alemanha, pois praticamente a metade de suas vendas de televisão tem o HbbTV incorporado. Assim, há mais de dois milhões de receptores ativos HbbTV e meio milhão de receptores ativos na França. Atualmente está sendo desenvolvido a versão HbbTV 2.0. O padrão HbbTV está ganhando partidários em outros lugares do mundo incluindo a América e Ásia. A vantagem que oferece é que as funções híbridas chegam a toda pessoa que dispõe de um terminal que suporte tal padrão, independentemente da marca ou do modelo do receptor. O modelo HbbTV pode ser representado na Figura 8. Os terminais híbridos que suportam HbbTV podem conectar-se simultaneamente às redes 푏푟표푎푑푐푎푠푡 e 푏푟표푎푑푏푎푛푑. No modelo atualmente em funcionamento na Europa, a rede 푏푟표푎푑푐푎푠푡 está baseada no padrão DVB (DVB-T/T2, DVB-S/S2, DVB- C/C2), por intermédio dessa rede o terminal pode receber o conteúdo de radiodifusão tal como vem sendo desenvolvido tradicionalmente. Tais conteúdos têm o nome de con- teúdos lineares. Por meio dessa rede também são enviadas informações de sinalização da aplicação. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 45

Figura 8 – Modelo HbbTV.

No caso da rede 푏푟표푎푑푏푎푛푑, o terminal é conetado à Internet, o que permite estabelecer uma comunicação bidirecional entre os usuários dos terminais com os provedo- res das aplicações, tornando possível a iteratividade e a recepção de dados das aplicações e conteúdo audiovisual, ou seja, o conteúdo não linear. No padrão HbbTV podem ser oferecido diferentes tipos de aplicações, dependendo dos fabricantes que desenvolvam tais aplicações e suas linhas de interesse. São definidos dois tipos de aplicações:

∙ Aplicações relacionadas à radiodifusão - São relacionadas com um serviço de ra- diodifusão, tem que ser declaradas na sinalização e permite a transmissão de um ou mais canais de televisão, seja por radiodifusão ou pela internet, por exemplo, a aplicação do botão vermelho, teletexto digital. As aplicações de botão vermelho ou relacionadas a programas normalmente são sinalizadas para se ativarem automa- ticamente ao sintonizar-se com o canal ao qual está associado; porém é opção do usuário o acesso aos conteúdos não lineares.

∙ Aplicações independentes da radiodifusão - São aplicações disponíveis apenas via banda larga, não precisam se declarar nos serviços do TS, e geralmente são desenvolvidas por fabricantes independentes, por exemplo: jogos em rede, aplicações associadas a redes sociais etc. Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 46

Em virtude dessa separação, o radiodifusor pode assegurar que no seu canal só será apresentado conteúdo enviado por ele. No entanto, é possível executar uma aplicação a partir de outra dependendo da maneira com a qual foi desenvolvida a aplicação; por exemplo, uma aplicação relacionada ao radiodifusor pode conter um enlace a uma apli- cação independente. O usuário finalmente decide se vai acessar os conteúdos iterativos oferecidos. O padrão HbbTV tem por base padrões existentes, tais como Consumer Elec- tronics Association (CEA-2014), Open IPTV Forum Release, European Telecommuni- cations Standars Institute (ETSI), entre outros:

∙ CEA -2014 : É quem define as principais funcionalidades do navegador. É baseado nos padrões W3Ce e especifica um perfil HTML para os dispositivos. Define alin- guagem de aplicação, tais como XHTML, CSS e JavaScript incluindo AJAX. Além disso, define como incluir o conteúdo não linear na aplicação.

∙ Open IPTV Forum Release Trata-se de uma organização sem fins lucrativos, focada em definir e publicar padrões abertos, e foi desenvolvido para trabalhar com sistema IPTV baseado no padrão DVB, mas as APIs que proporciona podem ser utilizadas em qualquer sistema híbrido DVB, e HbbTV é um deles. As APIs permitem que o conteúdo visto no sinal de radiodifusão seja combinado com as páginas HTML que definem a aplicação.

∙ ETSI TS 102 809, É uma especificação técnica de nome: " Digital Video Broad- casting: Signalling and carriage of interactive applications and services in Hybrid broadcast/broadband environments", que define a sinalização para a difusão das apli- cações HbbTV através do padrão DVB. Esse processo é feito por meio da Application Information Table (AIT) e da Program Map Table (PMT) Para implementar as aplicações HbbTV são utilizados linguagem de programação especificados no documento CEA-2014 e que são indicados no documento daETSI (ETSI-102.809, 2010).

No documento da ETSI são declarados algumas linguagens de programação definidos para o HbbTV, entre os quais estão:

∙ HTML que é a linguagem predominante para a criação das páginas 푤푒푏, descreve o conteúdo e estrutura da aplicação e mesmo que não seja muito útil para o desenho gráfico permite a aplicação de alguns estilos gráficos simples. Essa linguagem utiliza etiquetas que permitem fazer referência ao código que define os estilos gráficos da aplicação. Há três etiquetas: a inicial, a etiqueta do conteúdo e a etiqueta final. A Capítulo 2. A Evolução da Televisão Digital aos padrões híbridos 47

HTML define os conteúdos de forma que o navegador interpreta o código emostra os resultados.

∙ PHP é uma linguagem de programação livre utilizada para a geração de páginas web e aplicações dinâmicas; a linguagem PHP é interpretada pelo servidor e devolve uma resposta em formato HTML, cujo procedimento é transparente para o cliente e/ou usuário. A PHP oferece dinamismo e permite obter os conteúdos que mudam na base de dados. O código PHP pode ser incluso dentro do código HTML com as etiquetas ”푝ℎ푝 푦” e o conteúdo dentro dessas etiquetas será lido e traduzido pelo servidor para logo ser enviado ao cliente com todo o código HTML.

∙ CSS refere-se à linguagem desenvolvida para descrever a apresentação dos elementos definidos no código HTML. Mesmo que os estilos possam ser definidos naetiqueta de abertura de cada elemento, é mais prático definir um documento CSS em sepa- rado para facilitar a aplicação. Também se pode definir um estilo comum para um conjunto de elementos segundo as conveniências. Para inserir um documento CSS a um HTML, utiliza-se a sentença "link rel = stylesheet type = text/css href = doc.css"

∙ JavaScript é a linguagem de programação utilizada para a criação de páginas 푤푒푏, e aplicações dinâmicas HbbTV que serão executadas no cliente. Permite iteratividade entre o usuário e a aplicação, pois pode efetuar diferentes ações ao gerar diferentes tipos de eventos, além de ter a característica de criar, ler e eliminar 푐표표푘푖푒푠. Pode- se fazer a inserção do código JavaScript num documento HTML de duas formas: colocando a etiqueta script dentro do corpo do documento HTML ou agregando a sentença script type=text/javascript src=doc.js/