Geração de fluxo de transporte aderente ao sistema brasileiro de televisão digital

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

Ficha catalográfica

Universidade Estadual de Campinas Biblioteca da Área de Engenharia e Arquitetura

Luciana Pietrosanto Milla - CRB 8/8129

Tume Ruiz, Jackelyn Roxana,

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

COMISSÃO JULGADORA - DISSERTAÇÃO DE MESTRADO

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.

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.

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 in-cluindo funções híbridas de radiodifusão e banda larga, tomando como base ao modelo

Hybrid Broadband Broadcast também conhecido como HbbTV.

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.

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

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

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

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

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

VCEG Video Coding Experts Group

W3C World Wide Web Consortium at GEIE ERCIM WAVE Waveform Audio Format

WP Work packages

Sumário

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.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 B Arquivo script . . . 76

Anexos

84

ANEXO B Guia de instalação do OpenCaster . . . 87

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 mesmo canal (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 resulta-dos ofereciresulta-dos 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 do SBTVD.

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 interope-rabilidade 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.

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 traba-lho.

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 de-senvolvidos 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 hardwa-resultados da phardwa-resente 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 ter-restre 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 pro-cedimento 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 univer-sidades, 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-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

Codec de vídeo MPEG-2 H.264 /MPEG-4

parte 10

Middlware utilizado BML Ginga

Frame/seg dispositivos

móveis 15 30

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.

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

desenvol-vida 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.

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 ABNT NBR 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 em um 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 en-trada 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

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íVi-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 a outros 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 adja-centes 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 de bits, 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 CABAC (Context 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 a norma (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. A base 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:

∙ “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 (monau-ral 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 e a 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 obrigatoria-mente ser igual a 0 dB SPL. A faixa dinâmica admissível de excursão deve obrigatori-amente 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 um canal 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 obri-gatoriamente 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 trans-mitidos no fluxo de bits. Podem ser adtrans-mitidos como tipos de dados auxiliares:

∙ 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 no con-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 programa prin-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 auxi-liares 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 a bloco. 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 obrigatoria-mente ser compatíveis com a ISO/IEC 14496-3.

O decodificador deve obrigatoriamente ser construído assumindo-se que qual-quer 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 a norma em referência (ISO.14496-3, 2005).

Perfis e níveis

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

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

∙ 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

O áudio MPEG-4 transportado no fluxo de transporte MPEG-2 (TS), utilizando-se a sintaxe de transporte LATM/LOAS deve obrigatoriamente utilizando-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 obrigato-riamente 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 amos-tras 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 é cha-mada 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

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

Codificador Áudio Empacotador Empacotador PS MUX TS MUX Codificador Vídeo Vídeo Áudio ES ES PES PES DADOS Transport Stream Program Stream

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: 4 bytes 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 TS e ES podem ter taxa fixa ou variável; a taxa do TS é definida pelos valores dos campos 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 de bit no 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 é com-posta 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.

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 ou-tros 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 pa-cote em byte)*(8bits/byte)/(máximo intervalo para enviar as tabelas por segundo) -> (188byte)x8/(0.5 segundos) = 3008bps PMT 1 PCR Áudio Vídeo Data PMT 2 PCR Áudio Vídeo Data PMT N PCR Áudio Vídeo Data PAT Programa 1 Programa 2 Programa N CAT NIT

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 funcionalida-des 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.

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 bro-adcast 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 de um 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

Figura 6 – Arquitetura do sistema IBB (ITU-J.206, 2013).

parceria com duas operadoras de telefonia (BT TV, Talk Talk Plus TV) e quatro radio-difusores (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 aces-sar 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. Alguns pro-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.