geração de fluxo de transporte aderente ao sistema...

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

Jackelyn Roxana Tume Ruiz

Geração de Fluxo de Transporte Aderente ao SistemaBrasileiro de Televisão Digital

Campinas

2015

Jackelyn Roxana Tume Ruiz

Geração de Fluxo de Transporte Aderente ao SistemaBrasileiro 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 paraa obtenção do título de Mestra em Engenha-ria Elétrica, na Área de Telecomunicações eTelemática.

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

Este exemplar corresponde à versãofinal da dissertação defendida pelaaluna Jackelyn Roxana Tume Ruiz,e orientada pelo Prof. Dr. LuísGeraldo P. Meloni

Campinas2015

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

Ficha catalográficaUniversidade Estadual de Campinas

Biblioteca da Área de Engenharia e ArquiteturaLuciana 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. UniversidadeEstadual 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 TVsystemPalavras-chave em inglês:Digital televisionInteractive televisionBand communication systemBroadcastÁrea de concentração: Telecomunicações e TelemáticaTitulação: Mestra em Engenharia ElétricaBanca examinadora:Luis Geraldo Pedroso MeloniPaulo Batista LopesYuzo IanoData de defesa: 30-01-2015Programa de Pós-Graduação: Engenharia Elétrica

Powered by TCPDF (www.tcpdf.org)

http://www.tcpdf.org

COMISSÃO JULGADORA - DISSERTAÇÃO DE MESTRADO

Candidato: Jackelyn Roxana Tume Ruiz RA: 134136Data da Defesa: 31 de Janeiro de 2015Tí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. Obrigadameu 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 agradecimentoespecial a minha mãe e ao meu pai, já que todas as minhas conquistas são para eles e poreles, para meus irmãos, vocês são meu coração, obrigada família, vocês são meu suportee 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 ambienteagradável para se viver e trabalhar.

A todas as pessoas que de alguma forma contribuíram com minha formaçãoacadêmica e pessoal, e muito obrigada a todos aqueles que me ajudaram sem nem mesmome 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 serrealizado.’

(Roberto Shinyashiki)

ResumoVivemos na atualidade em um mundo que avança cada vez mais rápido, a globalizaçãoestá presente no dia a dia das pessoas e graças ao desenvolvimento de novas tecnologiasa 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á orientadaa facilitar, em vários aspectos, a vida das pessoas.

O presente projeto de pesquisa considera o estudo e desenvolvimento de um de modelopara 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 modeloHybrid Broadband Broadcast também conhecido como HbbTV.

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

AbstractNowadays we live in a world that moves faster and faster, globalization is present in thedaily lives of people and thanks to the development of new technologies, society is nowmore 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 digitaltelevision, 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) . . . . . . . . . . . . . . . 25Figura 2 – Estrutura de pacotes PES (ABNT.15602-3, 2008) . . . . . . . . . . . . 34Figura 3 – Fluxo de dados no sistema MPEG Systems . . . . . . . . . . . . . . . 35Figura 4 – Estrutura de pacotes TS (ABNT.15602-3, 2008). . . . . . . . . . . . . . 36Figura 5 – Tabelas de informação específica. . . . . . . . . . . . . . . . . . . . . . 37Figura 6 – Arquitetura do sistema IBB (ITU-J.206, 2013). . . . . . . . . . . . . . 41Figura 7 – Arquitetura do modelo Hybridcast. . . . . . . . . . . . . . . . . . . . . 44Figura 8 – Modelo HbbTV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 9 – Funcionalidades presentes na arquitetura do Ginga. . . . . . . . . . . . 48Figura 10 – Segunda tela em sistemas híbridos . . . . . . . . . . . . . . . . . . . . 50Figura 11 – Esquema desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 12 – Teste: Incluindo aplicação Ginga no TS. . . . . . . . . . . . . . . . . . 64Figura 13 – Aplicação Ginga inclusa no TS . . . . . . . . . . . . . . . . . . . . . . 65Figura 14 – Teste: Aplicação Ginga no TS. . . . . . . . . . . . . . . . . . . . . . . . 65Figura 15 – Analisador do TS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Lista de tabelas

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

1.2.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.3 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 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 . . . . . . . . . . . . . . 222.1.1 O middleware Ginga . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2 O Processo de transmissão de dados . . . . . . . . . . . . . . . . . . 25

2.2 Codificação de áudio e vídeo . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.1 Padrão de compressão de vídeo H.264 . . . . . . . . . . . . . . . . . 272.2.2 Codificação de áudio MPEG-2 AAC . . . . . . . . . . . . . . . . . . 28

2.3 Sistema de multiplexação de sinais . . . . . . . . . . . . . . . . . . . . . . 342.3.1 Formato do Packetized Elementary Stream . . . . . . . . . . . . . . 342.3.2 Formato do Transport Stream . . . . . . . . . . . . . . . . . . . . . 352.3.3 Tabelas de informações específicas de programa - PSI . . . . . . . . 36

2.4 Televisão conetada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.5 Principais padrões de televisão híbrida . . . . . . . . . . . . . . . . . . . . 39

2.5.1 Integrated Broadcast Broadband . . . . . . . . . . . . . . . . . . . 392.6 Atuais modelos de televisão híbrida . . . . . . . . . . . . . . . . . . . . . . 40

2.6.1 Projeto Youview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.6.2 Hybridcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.6.3 HbbTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.7 Principais comparações e semelhanças entre um sistema híbrido e Ginga . . 472.7.1 Fator segunda tela . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Ambiente de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . 513.1 OpenCaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Opera HbbTV Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3 Fire HbbTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4 Cartão Dektec Multi-Standar VHF/UHF Modulator . . . . . . . . . . . . . 53

3.4.1 StreamXpress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.2 DtPlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 Implementação e Avaliação dos Resultados . . . . . . . . . . . . . . . . . . 554.1 Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3 Codificação de arquivos audiovisuais . . . . . . . . . . . . . . . . . . . . . 564.3.1 Codificação e empacotamento de vídeo . . . . . . . . . . . . . . . . 564.3.2 Codificação e empacotamento de aúdio . . . . . . . . . . . . . . . . 574.3.3 Geração de tabelas PSI . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

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

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

18

1 Introdução

A tecnologia da informação cresceu exponencialmente a partir da segundametade do século passado, quando surgiram várias invenções no campo das comunicações,tais como os televisores, TVs digitais, telefones celulares, 𝑠𝑚𝑎𝑟𝑡𝑝ℎ𝑜𝑛𝑒𝑠, 𝑡𝑎𝑏𝑙𝑒𝑡𝑠, entreoutros. Hoje em dia, tais aparelhos são usados pelo público de todas as idades, e a televisãoconectada é um dos avanços tecnológicos mais destacados nos últimos anos na área deeletrô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 BroadcastingTerrestrial (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 eabertos, que demonstraram que o padrão ATSC apresentava uma qualidade insuficientena recepção de sinal em ambientes fechados, e dentre os padrões ISDB-T e DVB-T; oprimeiro apresentava um melhor desempenho na recepção de sinal através de receptoresplenos 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çãoEm 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 implantarum padrão de televisão digital no Brasil. Dessa forma, foram levados em conta os resulta-dos oferecidos pela SET/ABERT, tornando-os oficiais, com apoio da ideia de se consideraro 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, participarammais 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óriofinal de seu estudo e a seleção do sistema japonês ISDB-T como base do SBTVD.

Capítulo 1. Introdução 19

Uma das características novas do SBTVD consiste no desenvolvimento de umnovo 𝑚𝑖𝑑𝑑𝑙𝑒𝑤𝑎𝑟𝑒 denominado "Ginga", o qual adicionou funções iterativas mais elabora-das.

Por outro lado, no ano 2000, a Europa desenvolveu sua principal plataforma detelevisão digital: Multimedia Home Platform (MHP). As aplicações desenvolvidas nessaplataforma são transmitidas pelo sinal de radiodifusão e são baseadas principalmente emlinguagem Java. O MHP teve sucesso principalmente na Itália, porém em outros paísesnão conseguiu a introdução esperada em virtude de fatos como complexidade para escreveraplicaçõ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 fabricantesde televisões começaram a incorporar um navegador Web no receptor, as já conhecidas𝑆𝑚𝑎𝑟𝑡−𝑇𝑉 𝑠 ou 𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑒𝑑−𝑇𝑉 𝑠 cada uma com novas e diferentes aplicações para atrairo público. Todavia, também ocorre o problema das incompatibilidades entre as diferentesmarcas, pois uma aplicação não vai funcionar necessariamente em duas ou três marcasdiferentes 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ó linguagempara todas as TVs conetadas e que fizesse a junção de sinais de 𝑏𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡 e 𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑, ouseja a integração da transmissão por radiodifusão e por banda larga, maximizando assima iteratividade. Este novo conceito é conhecido como televisão híbrida. Vários padrões detelevisã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 emissoraNHK e o HbbTV na comunidade pan-europeia, todos eles utilizando o sinal de radiodifusãoe 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 desenvolvera interoperabilidade permitindo a coexistência e convergência da tecnologia HbbTV e o𝑚𝑖𝑑𝑑𝑙𝑒𝑤𝑎𝑟𝑒 Ginga, em plataformas de provas de conceito para diferentes sistemas detelevisã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, HXDInteractive Television e Band TV.

O projeto está dividido em seis Work packages(WP), sendo designado cadaWP um determinado grupo de trabalho. A UNICAMP é responsável pelo WP3.4 cujoobjetivo é a criação de um protótipo da implementação de uma prova de conceito de umsistema de 𝑝𝑙𝑎𝑦𝑜𝑢𝑡.


1.2 ObjetivosEntre 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 demodulação ISDB-T e DVB-T.

A motivação principal do presente trabalho encontra-se no fato de conseguirum maior nível de iteratividade no atual sistema digital de televisão brasileiro, tendo comobase de estudo o padrão europeu HbbTV, já que o Brasil é país pioneiro na América Latinaem adaptar o padrão ISDB-T. Dessa forma, espera-se que as funções híbridas possamincorporar-se ao atual sistema, isto poderia não só ter um contato mais direto entre oradiodifusor e o usuário, e assim conforme o enfoque, poderia também trazer benefíciossociais.

1.2.1 Objetivo geral

O objetivo geral da pesquisa está relacionado com os objetivos do projetoGlobal-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 𝑝𝑙𝑎𝑦𝑜𝑢𝑡 doprojeto.

O projeto Global-ITV procura harmonizar as diferentes soluções atualmenteexistentes no que se refere à iteratividade da televisão híbrida. Os integrantes do projetovão unir forças para definir o caminho para o cenário de coexistência em direção à geraçãode uma plataforma baseada em televisão híbrida.

O escopo do projeto Global-ITV é desenvolver um esquema para a próximageraçã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 mostrarserviç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 aoISDB-Tb.


1.3 OrganizaçãoA 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áriospara a melhor compreensão e desenvolvimento do atual projeto, tais como os principaispadrõ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 dedesenvolvimento 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 5apresenta 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çõesgeradas durante este trabalho de pesquisa e o Apêndice B as principais tabelas que foramutilizadas 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 Sistemabrasileiro 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 devídeo H.264 (também conhecido como Advanced Video Codec (AVC) ou como MPEG-4part 10) (ISO.14496-3, 2005) em vez do H.262/MPEG-2, como era utilizado no sistemajaponê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 maioreficiência em relação às perdas por interferência, o qual garante uma melhor recepção tantofixa quanto móvel. O ISDB-T utiliza a técnica da modulação OFDM, de multiplexaçãoem 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 fixaquanto a móvel.

Outro fator positivo foi a inclusão do um novo middleware. Middleware é umacamada 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 movimentona 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 sistemajaponês, o middlware utilizado é o Broadcast Markup Language (BML).

2.1 Televisão digital no Brasil - O SBTVD e o GingaO 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ãodigital 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 SBTVDprovenientes 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 aoFórum é independente da nacionalidade da companhia.

Uma das tarefas mais importantes do Fórum da SBTVD é a elaboração denormas técnicas junto a ABNT que proporcionan a interoperabilidade de sisetmas detransmissão e recepção. Assim o padrão brasileiro foi escrito por especialistas no campodas 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 seguintesaspectos:

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

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

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

Atualmente, todos os fabricantes de equipamentos de televisão incorporam oGinga 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 televisoresfabricados no Brasil a partir daquele ano precisariam ter instalado o Ginga; para 2014este porcentual deve chegar a 90%. A partir do período definido no inciso III, a obrigaçãopassa 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 ABNTNBR 15601 a 15608. A norma ABNT 15601 define a parte da transmissão, a normaABNT NBR 15602 trata da parte de codificação de vídeo, áudio e multiplexação. Asprincipais normas nas quais se baseiam este trabalho são as normas ABNT NBR 15602-1correspondente à “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. Outranorma, a ABNT 15603 trata da “Multiplexação e serviços da informação (SI)”. Estedocumento está dividido em três partes: ABNT NBR 15603-1 - Serviços da informaçãopara sistemas de radiodifusão digital; ABNT NBR 15603-2 - Sintaxes e definições dainformação básica de SI e a ABNT NBR 15603-3 - Sintaxe e definição de informaçãoextendida 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 NBR15606 “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


de dados, ABNT 15606-2 - Ginga-NCL para receptores fixos e móveis-Linguagem deaplicação XML para codificação de aplicações e a norma ABNT 15606-3 - Especificação detransmissão de dados. Finalmente a norma ABNT NBR 15607 cuida os temas relacionadosao canal de iteratividade: protocolos, interfaces físicas e interfaces de software, e a normaABNT 15608 ao guia de operação.

A Tabela 1 amostra uma breve comparação entre o sistema japonês ISDB-T eo sistema brasileiro conhecido como ISDB-Tb

Tabela 1 – Comparação ISDB-T e ISDB-Tb

Descrição ISDB-T ISDB-TbCodec de áudio MPEG-2 AAC HE-AAC

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

Middlware utilizado BML GingaFrame/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 daquelados canais de televisão analógica, e isto é feito para evitar problemas de realocação deespectro radioelétrico. Na modulação BST-OFDM, a largura de banda de canal é divididaem 14 segmentos, sendo um segmento reservado para a banda de guarda então a largurade banda fica reduzida a 13 segmentos disponíveis para serviço. A banda de guarda ofereceuma margem de tolerância no caso de possíveis interferências com os canais vizinhos, essasmargens são conhecidas como “bandas de guarda”, correspondentes a 1/14 da banda docanal (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çãode aplicações. O ambiente de execução de aplicações suporta a execução de aplicaçõesdeclarativas NCL. As três partes são requeridos pelo SBTVD para terminais fixos e no casode terminais portáteis o Ginga-J é opcional. O Ginga Core é composto por decodificadoresde conteúdo comuns e de procedimentos que podem ser utilizados para preparar os dadosque serão transportados, em transport streams. Além disso o Ginga core também devesuportar o modelo conceitual de exibição, segundo a (ABNT15606-1, 2007). A arquiteturaGinga 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, poisnão se precisa que cada passo a ser executado seja especificado, só é necessário indicar oconjunto das tarefas que serão desenvolvidos. O Ginga-NCL é um subsistema lógico domiddlware 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ávelpelo processamento de documentos NCL. Um elemento chave para o Ginga-NCL é amáquina de interpretação de conteúdo declarativo, chamado formatador NCL. Outraspartes importantes são o exibidor XHTML (inclui interpretadores CSS e ECMAScript) ea máquina de apresentação LUA.

A linguagem procedural requer um maior conhecimento, pois dá mais controlesobre 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 subsistemalógico do middlware Ginga, encarregado da parte procedural do sistema. Uma parte chavede seu sistema é seu mecanismo de execução do conteúdo procedural, composto por umamáquina virtual Java.

2.1.2 O Processo de transmissão de dados

A informação das aplicações iterativas transmitidas pelo radiodifusor é peloar, 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 STBde desenvolvimento, ou à televisão.

Na televisão digital terrestre a transmissão de dados é feita por meio da utili-


zação do carrossel de dados que consiste no envio de dados ciclicamente. Este envio podeser 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 NBR15606-3 (ABNT15606-3, 2007), a transmissão de dados através do carrossel de dados oude objetos deve ser sinalizada por um PID de 0x0B ou 0x0D.

O nome carrossel é usado, pois ele repete os dados em um fluxo de transportede forma cíclica, semelhante a um carrossel do mundo real. O DSM-CC originalmente foidesenvolvido para fornecer funções de controle de fluxos de áudio e vídeo presentes em umfluxo de transporte. Mais tarde foi modificado para oferecer funções como seleção, acessoe 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 transportadofoi carregado em memória e pode ser lançado. Em virtude do fato de que o receptor nãotem registro de nenhum arquivo X em sua memória, este vai ser aceito e armazenadona sua memória até ter todos os arquivos necessários para a execução da aplicação. Porexemplo, se para executar uma determinada aplicação tem que se transmitir e executartrês arquivos X, Y e Z, mas um deles não é transmitido, então a aplicação não poderá serexecutada até que na sua próxima sequência seja transmitida novamente. No momento emque todos os arquivos forem recebidos, o receptor estará pronto para executar a aplicação.

2.2 Codificação de áudio e vídeoA 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 aomultiplexador. O sistema de decodificação recebe o sinal que previamente passou pelodemultiplexador do receptor e realiza sua descompressão obtendo como sinal de saída osinal reconstruído.

Atualmente existem vários tipos de compressão de vídeo, sendo que os maisconhecidos foram produzidos pelo Moving Picture Experts Group (MPEG) e pelo VideoCoding Experts Group (VCEG). Os padrões mais conhecidos são MPEG-1, MPEG-2 eMPEG-4, no entanto o MPEG-2 é o mais difundido, em razão do baixo custo dos seuscircuitos integrados, e corresponde a uma das tecnologias que mais se aprimoraram aolongo do tempo

O VCEG tem entre seus padrões mais conhecidos o H.261 e o H.263, e deum trabalho em conjunto, o MPEG e o VCEG desenvolveram o padrão H.264, tambémconhecido 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 metadeda 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 asincronização de sinais de vídeo, áudio, e dados adicionais incorporados, para assim formarum 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çõesem relação a outros padrões de televisão digital. Neste sentido, os objetivos do padrãoH.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 MPEG4parte 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 doITU-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 serutilizado 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 flexibilidadeda codificação, porém às expensas do incremento na complexidade com respeito a outrospadrões. Em (RAO; HWANG, 2014) e (WIEGAND; SULLIVAN, 2007) há um resumoem 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), eentre pixels na mesma posição em quadros adjacentes(inter-frame por compensaçãode 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 residualresultante da subtração do quadro predito do quadro original.

∙ Modelo espacial: nesta etapa, utiliza-se a redundância remanescente entre pixelsdo quadro residual, sobre eles aplica-se uma transformada, com o que se obtêmcoeficientes que serão quantificados para eliminar aqueles não significativos, ficandosó com os poucos que carregam a maior energia.


∙ 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 BinaryArithmetic 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 gamade aplicações, porque reconhece que nem todas elas requerem as mesmas configuração emtermos de taxa de bits, resolução, qualidade, etc. Assim, o H.264 define perfis os quaisimplementam apenas um subconjunto das técnicas especificadas no padrão, com o objetivode 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ávelo 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 baixafrequência LFE, os quais ocupam só uma fração da taxa de bits dos outros streams. Dosquatro diferentes tipos de arranjos espaciais (mono, estéreo, Dolby Surround e Surround5.1), o ISDB-Tb pode transmitir em estéreo e 5.1 multicanal simultaneamente, ou mesmocom 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 áudioe sistema de codificação e decodificação de som que vai ser utilizado no SBTVD. A basedestas normas foram as normas do ARIB.

Conforme a norma citada acima, as condições gerais para o formato de entradade á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 consistindoem dois ou mais sinais de áudio para obter uma reprodução envolvente ou espacialdo som); a taxa de amostragem para todos os sinais deve obrigatoriamente ser amesma;

∙ 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 aonúmero máximo de canais permitidos pela (ISO.14496-3, 2005);

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

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

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

Tabela 2 – Restrições de modos de codificação (ABNT.15602-2, 2008)

Parâmetros RestriçãoModos 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.


Interfaces

Entre as interfaces (barramentos) de entrada/saída digital permitidos, devemobrigatoriamente estar o (AES/EBU), contendo dois canais PCM por fluxo de bits), serialdigital 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édioestejam a −20𝑑𝐵 Full Scale (0 dB), para possibilitar homogeneidade no volume entrecanais distintos. O sinal deve acomodar picos de no mínimo 4 vezes sua potência médiaroot 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. Onú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 canalde baixas frequências (LFE) para transmissão multicanal “5.1” padrão. Os sinais fontesdevem obrigatoriamente ser pré-processados e/ou combinados previamente à entrada docodificador, para produzirem os canais de transmissão que devem obrigatoriamente estarpresentes no fluxo de bits. Uma mesma programação de áudio pode ser transmitida emmais 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 obrigatoriamenteser capazes de sintetizar o sinal estéreo por meio de conversão ( downmixing ), operaçõesde replicação, dematrixing, combinação e processamento de sinal no âmbito funcional dosistema 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 admitidos 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 podemser 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 debits) como, por exemplo, informação de quantidade e modo dos canais, perfil e nívelde codificação extraídas diretamente das tabelas PSI. Os dados nesta categoria devemobrigatoriamente 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ãodeve afetar a decodificação, mas sim trazer informações sobre os conteúdos dos programasde áudio associados a cada PID. Os dados nesta categoria devem obrigatoriamente serusados 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 aoprograma principal e são obrigatoriamente considerados serviços opcionais, com exceçãodo serviço de Áudio Descrição (DA), cuja transmissão é obrigatória conforme legislaçãovigente.

A transmissão destes serviços deve ser realizada através da alocação de canaisde áudio auxiliares adicionais em programas de áudio (PID) distintos, ou no mesmo fluxode bits de um mesmo PID, respeitando-se sempre o número máximo de canais permitidosno 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, paratransmitir programas adicionais ao programa principal e áudio secundário proveniente deoutras 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çãoválida de tipo de componente ( component_type ) no respectivo descritor de áudio ( au-dio_component_descriptor ) do programa. Os canais auxiliares devem obrigatoriamenteser transmitidos em programas distintos (PID distintos), com a devida sinalização e iden-tificação de seus canais, para serem selecionados, decodificados e reproduzidos juntamentecom ou em substituição aos canais de áudio do programa principal.


Sistema de codificação de áudio

Os sinais de áudio devem obrigatoriamente ser codificados por um mecanismode codificação por transformada em frequência e processamento no tempo bloco a bloco. Atransformada 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údoem 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 debits. 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 emreferê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 LCcom o uso da ferramenta SBR (Spectral band Replication) para a versão 1 desteperfil, 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 devemobrigatoriamente ser compatíveis com LATM/LOAS, conforme a norma (ISO.14496-3,2005). O 𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦 𝑠𝑡𝑟𝑒𝑎𝑚 deve obrigatoriamente ser primeiramente encapsulado noformato de transporte LATM e deve obrigatoriamente utilizar o elemento de multiplexaçãoAudioMuxElement.


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 obrigato-riamente atender à Tabela 3.

Tabela 3 – Principais parâmetros de codificação de áudio para serviços one-seg.

Parâmetros RestriçãoMecanismos 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 HighEfficiency (HE): nível 4 (HE-AAC v1@L4) paramulticanal

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 deveser de 1024 amostras para AAC e 2048 quandousando 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áteisdevem obrigatoriamente atender à Tabela 4

Tabela 4 – Principais parâmetros de codificação de áudio para serviços one-seg

Parâmetros RestriçãoMecanismos 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 paratransmissão para dispositivos móveis e também é obrigatória para dispositivos fixos, casoestes 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çãorelativa a outros fluxos mas transporta informação de ordenação interna das imagens de


vídeo ou quadros de áudio. Um conjunto de ES pode formar um programa completo comdiversas informações como áudio, vídeo, legendas, etc.

2.3 Sistema de multiplexação de sinaisA 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 devemser multiplexadas através de pacotes e devem estar agrupados para um comprimentoarbitrá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 entredados de áudio, vídeo e outros dados. Todos os ES são agrupados em pacotes chamadosPES. 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 esempre é 00 00 001 que é utilizado para identificar um pacote PES. O byte seguinte é ocampo 𝑠𝑡𝑟𝑒𝑎𝑚 𝐼𝐷 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ãomostradas 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 dopacote PES. O cabeçalho opcional deve obrigatoriamente ser utilizado para transmitirinformações adicionais do cabeçalho. O 𝑝𝑎𝑦𝑙𝑜𝑎𝑑 deve obrigatoriamente ser utilizado paratransmissã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çãoque 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 queapresentam erros ou ruídos é utilizado o Transport Stream (TS), como por exemplo oISDB-T.

Em resumo, o ES é formado por AUs, a sua vez os ESs são transportados empacotes PES, que por sua vez, são transportadas por pacotes TS. O TS é utilizado emambientes com ruído ou erros, que podem ser originado por perdas de bits ou perdas depacotes, como se observa na Figura 3

CodificadorÁudio

Empacotador

Empacotador

PSMUX

TS MUX

CodificadorVí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 sobreuma base de tempo comum; o fluxo TS é composto por pacotes de tamanho fixo: 4 bytesde cabeçalho e 184 bytes de payload, num total de 188 bytes, mas podem ser agregadosbytes adicionais para correção de erros como no caso do SBTVD onde o tamanho totaldos pacotes enviados na transmissão é de 204 bytes, sendo utilizados 188 bytes para o TSe 16 bytes para a correção de erros e outras informações.

O fluxo TS pode conter diversos tipos de pacotes PES, e é identificado como PID que indica que tipo de dado contém um determinado fluxo TS. Os pacotes TS eES podem ter taxa fixa ou variável; a taxa do TS é definida pelos valores dos camposque contêm o relógio de referência do programa PCR o qual é uma informação de sincro-


nização do receptor necessária para a decodificação do vídeo, áudio, dados, e é incluídoperiodicamente nos pacotes de transporte. O receptor precisa dessa informação do PCRem aproximadamente dez vezes por segundo.

Na representação hexadecimal os TS começam com o identificador de pacotesPID de 13 bits que está contido num prefixo de 4 bytes, o PID indica o conteúdo dosdados 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 TSdevem 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 deveser obrigatoriamente um flag de 1 bit indicativo da presença de qualquer erro de bit nopacote TS. Se a sinalização contém o valor de "1"indica a presença de um erro incorrigívelde pelo menos 1 bit.

O campo 𝑃𝑎𝑦𝑙𝑜𝑎𝑑 𝑢𝑛𝑖𝑡 𝑠𝑡𝑎𝑟𝑡𝑖𝑛𝑑𝑖𝑐𝑎𝑡𝑜𝑟 ou indicador de início é um flag de 1bit 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 dasoutras tabelas e serve para estabelecer a correspondência entre o número de programa eo PID dos pacotes TS.

A tabela PMT faz uma descrição de todos os conteúdos que fazem parte de umprograma, assim especifica quais ES estão associados e vão formar cada programa. Dessaforma o receptor decodifica só os ES necessários que vão ser transmitidos no programanesse momento.

As tabelas PAT e PMT são enviadas dez vezes por segundo e cada tabelaocupa um pacote de 188 bytes, então serão enviados 188*8 bits cada segundo -> 15040bps.

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ãoaberta. 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

PATPrograma 1

Programa 2

Programa N

CAT

NIT

Figura 5 – Tabelas de informação específica.


2.4 Televisão conetadaNos últimos anos o mundo foi testemunha da rápida penetração no mercado

da televisão conectada, comumente chamada 𝑆𝑚𝑎𝑟𝑡 𝑇𝑉 . Os fabricantes de tecnologia deconsumo disponibilizam receptores set-top-boxes que oferecem aos consumidores conexãoà Internet tanto por ethernet quanto pelo WiFi. Tais dispositivos têm a capacidade deacessar 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 qualquerdispositivo, 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 osfabricantes.

Contudo, as TVs conectadas estão baseadas em tecnologias bem estabelecidase os fabricantes incluem acessibilidade 𝑤𝑒𝑏 em seus dispositivos, mas as soluções nemsempre funcionam da forma esperada, pois alguns 𝑤𝑒𝑏𝑠𝑖𝑡𝑒𝑠 não são navegáveis peloscontroles remotos convencionais.

Além disso, os atuais set-top-boxes estão limitados ao avanço da tecnologia enã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 umaexperiência iterativa ou uma experiência híbrida, pois embora tenha duas entradas, umadelas para sinal de radiodifusão (seja DVB ou ISDT-B) e outra para a internet (sejaethernet ou WiFi), eles não necessariamente oferecem convergência pois fazem trabalhose percursos independentes, não oferecendo sincronismo de fluxos de radiodifusão e bandalarga.

Em resumo, a maior parte das TVs conectadas atualmente só consegue seconectar a portais web proprietários que contêm aplicações que estão sob o controle dosfabricantes. 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çoentre o conteúdo broadcast (seja via redes satélite ou cabo) e o conteúdo oferecido viacanal de Internet, o que pode ser feito mediante um sistema adequado de sinalizaçãovia canal de iteratividade, seja via ethernet em Digital Subscriber Line (DSL) ou viaethernet via Community Antenna television (CATV) e, no caso das redes de banda largamóveis a conexão pode ser com redes como Long Term Evolution (LTE) ou outra redeIP disponível.


2.5 Principais padrões de televisão híbridaAtualmente 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 desistemas de iteratividade.

2.5.1 Integrated Broadcast Broadband

O padrão Integrated Broadcast Broadband (IBB) é o padrão internacional daITU e foi publicado como padrão BT.2037. Inicialmente foi criado um arcabouço para ossistemas 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 defineos 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 referidono 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 todosos requisitos para o sistema integrado broadcast broadband.

O padrão BT.2037 tem como título em português: "Requisitos gerais paraaplicaçõ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 detelevisão digital IBB. Esse sistema tem por base a combinação de especificações técnicase processos operacionais relacionados, os quais juntos definem como os serviços podem serprestados para o usuário final baseados em uma combinação de mecanismos de transmissãousando 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 criarconflito com os sistemas que estão atualmente em operação; isto é requerido paraminimizar 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 osradiodifusores 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,


tablets, entre outros. A maior diferença entre o sistema IBB e os serviços baseadosna web é a capacidade de combinar aplicações multifuncionais com os programastransmitidos normalmente pelos radiodifusores.

Há que se ter em foco o usuário, facilitando seu acesso. Tem que suportar conteúdopara pessoas com alguma deficiência, assim como mostrar ser capaz de apresentarconteúdo para casos de emergências.

3. Preservar os interesses das partes envolvidas na solução. Os radiodifusores têm umgrande interesse em assegurar a preservação de seu conteúdo e evitar as sobreposiçõesnão autorizadas. O conteúdo não deve ser alterado de nenhum modo pelas aplicaçõesIBB. 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 paraassim incentivar a conversão, em especial os radiodifusores.

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

Segundo a especificação ITU-T J.206 (ITU-J.206, 2013), a arquitetura de umreceptor 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ãoiterativa, cujas arquiteturas assemelham-se a um sistema integrado broadcast-broadbandentre eles o Hybridcast, o HbbTV e Ginga.

2.6 Atuais modelos de televisão híbridaNa 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. Assimtais sistemas enviam informação não só a nivel de radiodifusão, também enviam a nivelde 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 sistemahí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 "ProjetoCanvas"da BBC.

Inclui acesso à televisão digital terrestre gratuita e a serviços via broadbandcomo VOD, EPG integrado etc. O Youview sofreu diversos atrasos em sua entrada nomercado que foi adiada por dois anos; atualmente, alguns fabricantes de STB vendemreceptores Youview no mercado, pois ainda não há implementações em TVs. Vale lembrarque no início foi duramente criticado pelo fato de ter um preço muito alto, em torno de300 libras.

2.6.2 Hybridcast

A Nippon Hoso Kyokai (NHK), emissora nacional do Japão, desvendou seupróprio sistema híbrido de radiodifusão e banda larga, o Hybridcast, lançado em setembrode 2013. O Hybridcast TV permite ao espectador assistir tanto por radiodifusão quantopor banda larga na mesma tela de televisão, e os dois serviços podem ser ligados e inter-relacionados.


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ãode banda larga e recursos de radiodifusão. O sistema considera os cenários principais daRecomendação ITU-T J.205. A especificação também define um mecanismo para funçõesde 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 controlede aplicativos e informações de permissão podem ser transmitidos para notificar quais osaplicativos 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çospodem 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çosa 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 podemser 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 registraaplicativos que podem ser baixados pelos usuários e fornece listas de aplicações de acordocom 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, oqual pode prescindir de um provedor de serviços e atuar nos dois papéis.


(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 recebere apresentar o conteúdo de radiodifusão. O receptor fornece funções padronizadas e inter-faces (APIs) para a execução das aplicações. A função de colaboração com dispositivosmóveis como tablets e smartphones permite que a aplicação Hybridcast possa interagircom esses dispositivos que devem estar ligados ao receptor dentro de uma mesma rededoméstica (ℎ𝑜𝑚𝑒 𝑛𝑒𝑡𝑤𝑜𝑟𝑘), geralmente por Wi-Fi.

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

∙ 𝐵𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡 − 𝑜𝑟𝑖𝑒𝑛𝑡𝑒𝑑 𝑚𝑎𝑛𝑎𝑔𝑒𝑑 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑠 - são as aplicações que são controla-dos por sinal de controle de aplicação no sinal de transmissão. As aplicações sãoiniciadas ou terminadas pelo controle da emissora e têm permissão para acessaros recursos de transmissão com base nas informações de permissões nos sinais decontrole. Podem continuar o seu funcionamento se a aplicação se tem ativada ainstruçãp AUTOSTART.

∙ 𝑁𝑜𝑛 − 𝐵𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡 − 𝑜𝑟𝑖𝑒𝑛𝑡𝑒𝑑 𝑚𝑎𝑛𝑎𝑔𝑒𝑑 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑠 - são as aplicações que nãosão iniciadas ou terminadas pelo controle da emissora no sinal de transmissão, massã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 paraacessar o conteúdo do sinal.

∙ 𝐺𝑒𝑛𝑒𝑟𝑎𝑙 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑠 - nome geral para aplicações que não correspondem a qual-quer um dos dois tipos acima. As aplicações stand alone não são permitidas parapresentaçõ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 o pa-drão DVB e proporciona um mecanismo que integra serviços de radiodifusão e bandalarga.

O HbbTV foi desenvolvido em 2009 e estabelecido oficialmente em 2010. Ainformação sobre o padrão HbbTV é detalhada no documento ETSI TS 102 796 v.1.1.1


Figura 7 – Arquitetura do modelo Hybridcast.

(ETSI-102.796, 2010) cujo consórcio é atualmente composto por empresas de radiodifusãoe 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, poispraticamente 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 naFrança. Atualmente está sendo desenvolvido a versão HbbTV 2.0.

O padrão HbbTV está ganhando partidários em outros lugares do mundoincluindo a América e Ásia. A vantagem que oferece é que as funções híbridas chegam atoda pessoa que dispõe de um terminal que suporte tal padrão, independentemente damarca ou do modelo do receptor. O modelo HbbTV pode ser representado na Figura 8.

Os terminais híbridos que suportam HbbTV podem conectar-se simultane-amente às redes 𝑏𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡 e 𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑. No modelo atualmente em funcionamento naEuropa, 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ãotal 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 daaplicação.


Figura 8 – Modelo HbbTV.

No caso da rede 𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑, o terminal é conetado à Internet, o que permiteestabelecer 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çõese conteúdo audiovisual, ou seja, o conteúdo não linear.

No padrão HbbTV podem ser oferecido diferentes tipos de aplicações, depen-dendo dos fabricantes que desenvolvam tais aplicações e suas linhas de interesse. Sãodefinidos 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 umou mais canais de televisão, seja por radiodifusão ou pela internet, por exemplo, aaplicação do botão vermelho, teletexto digital. As aplicações de botão vermelho ourelacionadas 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 dousuário o acesso aos conteúdos não lineares.

∙ Aplicações independentes da radiodifusão - São aplicações disponíveis apenas viabanda larga, não precisam se declarar nos serviços do TS, e geralmente são de-senvolvidas por fabricantes independentes, por exemplo: jogos em rede, aplicaçõesassociadas a redes sociais etc.


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çãoa partir de outra dependendo da maneira com a qual foi desenvolvida a aplicação; porexemplo, 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 iterativosoferecidos.

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. É baseadonos padrões W3Ce e especifica um perfil HTML para os dispositivos. Define a lin-guagem de aplicação, tais como XHTML, CSS e JavaScript incluindo AJAX. Alémdisso, 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, focadaem definir e publicar padrões abertos, e foi desenvolvido para trabalhar com sistemaIPTV baseado no padrão DVB, mas as APIs que proporciona podem ser utilizadasem qualquer sistema híbrido DVB, e HbbTV é um deles. As APIs permitem que oconteúdo visto no sinal de radiodifusão seja combinado com as páginas HTML quedefinem 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 Hybridbroadcast/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 ApplicationInformation Table (AIT) e da Program Map Table (PMT)

Para implementar as aplicações HbbTV são utilizados linguagem de programaçãoespecificados no documento CEA-2014 e que são indicados no documento da ETSI(ETSI-102.809, 2010).

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

∙ HTML que é a linguagem predominante para a criação das páginas 𝑤𝑒𝑏, descreve oconteúdo e estrutura da aplicação e mesmo que não seja muito útil para o desenhográfico permite a aplicação de alguns estilos gráficos simples. Essa linguagem utilizaetiquetas que permitem fazer referência ao código que define os estilos gráficos daaplicação. Há três etiquetas: a inicial, a etiqueta do conteúdo e a etiqueta final. A


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

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

∙ CSS refere-se à linguagem desenvolvida para descrever a apresentação dos elementosdefinidos no código HTML. Mesmo que os estilos possam ser definidos na etiquetade 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 umconjunto de elementos segundo as conveniências. Para inserir um documento CSS aum 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 𝑤𝑒𝑏, eaplicações dinâmicas HbbTV que serão executadas no cliente. Permite iteratividadeentre o usuário e a aplicação, pois pode efetuar diferentes ações ao gerar diferentestipos 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 agregandoa sentença script type=text/javascript src=doc.js/<script> dentro da cabeçalho,fazendo-se referência a um documento externo JavaScript. Uma das vantagens doAJAX é a capacidade de atualizar partes da aplicação sem necessidade de carregartudo por inteiro.

SQL ou Structured Query Language ou linguagem de consulta estruturada é a lin-guagem de pesquisa declarativa padrão utilizada por diferentes bancos de dadosrelacionais para realizar operações de dados ou sobre os mesmos. O fato de ser umalinguagem declarativa reduz o tempo de aprendizagem para pessoas que iniciam seuestudo nessa linguagem.

2.7 Principais comparações e semelhanças entre um sistema hí-brido e Ginga

Embora Ginga não seja um sistema híbrido, é possível notar algumas seme-lhanças. O Ginga é baseado nos padrões ANBT e o HbbTV é baseado no padrão (ETSI-102.796, 2010) desenvolvido pela ETSI. Vale ressaltar que ambas têm um sistema de


montagem DSM-CC carrossel de objetos, o que abre caminho para o presente estudo.Ambos usam tabelas AITs utilizadas para a sinalização das aplicações.

Algumas dessas comparações se encontram na Tabela 6

Tabela 6 – Plataformas Ginga e HbbTV.

Nro Ginga HbbTV

1 Aplicação baseada em Java NCL Aplicação baseada emCE-HTML

2A sinalização de aplicações éutilizando AIT baseadas nos

padrões ABNT

AA sinalização de aplicações éutilizando AIT baseadas nos

padrões ETSI

3 Sistema de montagem: DSM-CCObject Carousel

Sistema de montagem: DSM-CCObject Carousel

4Os comandos de edição do Ginga

vão em direção ao DSM-CCbroadcast

Para comandos de ediçãodepende da applicação

CE-HTML

5Ginga NCL inclui suporte paratecnologia e padrão HTML do

W3C

Inclui suporte para tecnologia epadrão CE-HTML

Se fizermos uma comparação das funcionalidades presentes numa arquiteturaIBB e Ginga, pode ser observado o mostrado na Figura 9.

Figura 9 – Funcionalidades presentes na arquitetura do Ginga.


2.7.1 Fator segunda tela

Uma das características mais interessantes nas soluções híbridas 𝑏𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡

𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑 é a inserção da segunda tela como parte da iteratividade oferecida na solução.Em virtude do alto número de pessoas que atualmente têm acesso a dispositivos móveis,tais como 𝑠𝑚𝑎𝑟𝑡𝑝ℎ𝑜𝑛𝑒𝑠, 𝑡𝑎𝑏𝑙𝑒𝑡𝑠, entre outros, e do maior acesso da população a rede dedados seja pelo Wi-fi ou 3G/4G, foi introduzido o termo "segunda tela", referindo-se àinteração entre o usuário e o conteúdo oferecido pelo radiodifusor.

Há fortes razões para que os radiodifusores tenham interesse em implementaras segundas telas na sua programação, como segue abaixo:

∙ Capturar a atenção de uma audiência maior,

∙ Incremento de consumo não linear por parte dos espectadores,

∙ Venda de conteúdo iterativo,

∙ Proveito do uso do marketing.

Atualmente os radiodifusores oferecem soluções de segunda tela para ter umamaior aproximação com o usuário, mas em alguns casos só são soluções relativamentesuperficiais que não dão garantias de uma iteratividade direta entre o radiodifusor e ousuário. É bastante comun o uso das redes sociais, onde a iteração e a resposta do usuáriosão controladas pelo provedor da aplicação e não pelo radiodifusor. Além disso, o usuáriopode sofrer problemas de solução tais como propagandas ou anúncios não desejados ouproblemas de qualidade oferecidos pelo provedor da aplicação, mas que poderiam se atri-buir erroneamente ao radiodifusor causando prejuízo a sua imagem. Algumas das técnicasde sincronismo de conteúdo da segunda tela são

∙ Sincronismo por marca de água,

∙ Reconhecimento de áudio,

∙ Check-in na segunda tela,

∙ Uso da rede LAN,

∙ Fotografia de QR codes.

A falta de harmonia nessas soluções causa uma desordem tanto para o ra-diodifusor como para o usuário; no caso do radiodifusor há que se adequar às soluçõese/ou aplicações proprietárias; no caso ao usuário, poderia levar a um cenário de confuso,


pois não conseguiria identificar as aplicações do radiodifusor e as aplicações criadas porterceiros.

O sistema híbrido integrado 𝑏𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡 − 𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑 estabelece uma ordem àssoluções de segunda tela porque garante ao radiodifusor um controle total sobre as soluçõesde segunda tela, o que assegura que a informação enviada pelo usuário vai direto aoradiodifusor. O método de sincronização utilizado funciona em programação linear e nãolinear, em programas ao vivo ou gravados previamente nos receptores.

Rede de Àrea Local (LAN)ou Rede de Área Personal (PAN)

Radiodifusor,Operador de Rede

Figura 10 – Segunda tela em sistemas híbridos

51

3 Ambiente de desenvolvimento

Neste capítulo diversas opções de software e hardware serão analisadas paradesenvolver o presente trabalho. No caso de 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒, a prioridade é quanto a software𝑜𝑝𝑒𝑛 𝑠𝑜𝑢𝑟𝑐𝑒 já que permite acesso a tecnologia e aprimoramento, caso necessario.

No caso do ℎ𝑎𝑟𝑑𝑤𝑎𝑟𝑒 foram analisadas opções baseadas em plataformas decomputadoras pessoais.

As opções escolhidas para o desenvolvimento deste trabalho são as detalhadasa seguir.

3.1 OpenCasterO OpenCaster (OPENCASTER, 2008) é um 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 aberto e livre desen-

volvido pela companhia italiana Avalpa Digital Engineering, que nasceu a partir de seuantecessor JustDVB-IT. O OpenCaster oferece uma série de ferramentas que são utilizadaspara a geração, processamento, emissão e difusão de conteúdos 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚.

O software não tem interface gráfica e funciona em sistemas operacionais Linux,em que os comandos são executados através do terminal de comandos. A versão maisatualizada disponível na internet é o OpenCaster 3.2.2.

Cabe lembrar que o OpenCaster desempenhou um papel fundamental nestetrabalho, pois é uma ferramenta de muitas funcionalidades reunidas em uma só; todavia,foi necessária a instalação de alguns pacotes de Linux, sem os quais não se consegueriacolocar em funcionamento o OpenCaster, tais como: GCC, binutils, Libs6-dev, Libgomp1, Linux-libc-dev, Make, Libcap 0.8, Zlib1g-dev.

Outro dos requerimentos do OpenCaster foi a instalação da linguagem Python,que pode executar arquivos 𝑠𝑐𝑟𝑖𝑝𝑡𝑠 necessários para a criação e multiplexação das tabelasPSI.

As principais funcionalidades oferecidas pelo OpenCaster são:

∙ Criação de tabelas PSI,

∙ Transmitir arquivos de vídeo, áudio e dados, sempre que estejam codificados corre-tamente,

∙ Transformação dos arquivos de dados em carrosséis DSM-CC e otimização do car-rossel,

Capítulo 3. Ambiente de desenvolvimento 52

∙ Manipulação dos fluxos TS armazenados em disco rígido em tempo real.

O OpenCaster é utilizado como software multiplexador, aqui são explicadasalgumas de suas ferramentas e realizados testes de empacotamento e multiplexação depacotes.

∙ Entre os principais comandos do OpenCaster estão os seguintes:

– Esaudio2pes, permite encapsular os ES de aúdio em PES,

– pesaudio2ts, permite transformar o pacote PES de áudio em TS,

– tscbrmuxer, encarregado da multiplexação dos arquivos sejam de áudio, vídeo,dados, num só TS,

– oc-update.sh, a ferramenta permite a criação de um TS utilizando um carrosselde dados.

No anexo B é explicado um breve procedimento para a instalação do 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 OpenCas-ter.

3.2 Opera HbbTV EmulatorO Opera (OPERA, 1995) oferece um 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 emulador que permite visua-

lizar aplicações HbbTV via HTTP ou aplicações armazenadas no disco rígido, o OperaHbbTV Emulator, que apresenta uma versão de teste que permite visualizar as aplicaçõesdesenvolvidas.

Para poder utilizar este emulador, faz-se a instalação de uma máquina virtual(VIRTUALBOX, 2007) e o pacote oferecido por Opera (OPERAHBBTV, 2012). Atual-mente só existe uma versão Beta e é baseada na especificação 1.1.1 do HbbTV, errata2.

Opera HbbTV Emulator tem vários exemplos de teste para análise dos diferen-tes tipos de aplicações que podem ser feitas. Os detalhes da instalação do Opera HbbTVEmulator está no Anexo C.

3.3 Fire HbbTVO Fire HbbTV integra-se com a Firefox como plug-in para poder desenvolver

e testar aplicações HbbTV. Essa ferramenta é de instalação simples, pois é só descarregare instalar um pacote oferecido no servidor da Firefox (FIREHBBTV, 2012) e para testaras aplicações é necessário colocar a URL na barra de endereços 𝑤𝑒𝑏.


Esta ferramenta permite facilmente fazer modificações de tamanho da página,𝑟𝑒𝑠𝑖𝑧𝑒 inteligente, margens, além de uma ferramenta de controle o qual emula um controleremoto de televisão, dentre outras funcionalidades.

No Anexo C é detalhada uma breve explanacação da instalação do Fire HbbTV.

3.4 Cartão Dektec Multi-Standar VHF/UHF ModulatorNeste trabalho utilizou-se um cartão para barramento PCIe da empresa Dektec

(DEKTEC2111, 2011), que é um modulador multi-padrão de baixo custo do fabricante,em sua versão básica suporta as modulações ATSC, DVB-C, DVB-H, DVB-T, QAM-B,QAM-C, e como opcionais, suporta as modulações ADTB-T, CMMB, DAB+, DMB-T/H,DVB-C2, DVB-T2, IQ, ISDB-T.

Para realizar os testes, o cartão foi instalado no computador e o sinal foitransmitido à televisão pelo ar e/ou por cabo coaxial. Para obter mais informação técnicadeste cartão ver o Anexo A.

3.4.1 StreamXpress

Para utilizar o modulador da Dektec é necessário instalar os 𝑑𝑟𝑖𝑣𝑒𝑟𝑠 do cartãoe um software que permite fazer a configuração dos parâmetros de modulação, e istopode ser feito de acordo com o sistema operacional no qual vai se trabalhar. Utilizamos o𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 DTC-300 StreamXpress compatível com Windows e compatível com qualqueradaptador Dektec.

O primeiro passo é conectar o modulador instalado previamente no computa-dor, e ao transmitir a um STB ou TV seja via RF ou cabo. Deve-se, em seguida, selecionaro arquivo TS que se deseja transmitir. Deve-se indicar os parâmetros de modulação neces-sários para a transmissão, assim como frequência e canal de operação. O programa ofereceinformação sobre as tabelas PSI, NIT e PMT. O único inconveniente do StreamXpress éque só é compatível com o sistema operacional Windows, assim não é possível realizar oprocesso de multiplexação e transmissão no mesmo sistema operacional, pois neste tra-balho é utilizado o software 𝑂𝑝𝑒𝑛𝑐𝑎𝑠𝑡𝑒𝑟 para a geração do 𝑇𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑆𝑡𝑟𝑒𝑎𝑚 o qual sótrabalha no sistema operacional Linux.

Os parâmetros mais importantes que serão configurados no StreamXpress são:

∙ Frequência: vai ser escolhida a frequência de 6MHz por ser a largura de banda doISDB-Tb,

∙ Seleção de canal: os canais disponibilizados no StreamXpress para radiodifusão vãodo Canal 1 ao canal 62,


∙ Modo: podem ser ingressados três tipos de modos: O modo 1 utiliza 108 portadoraspor segmento, o modo 2 utiliza 216 portadoras por segmento e o modo 3 utiliza 432portadoras por segmento. Alguns outros parâmetros vão depender do tipo de modoque vai se utilizar,

∙ Modulação: as modulações disponíveis no StreamXpress são QPSK, 16QAM, 64QAMe DQPSK,

∙ Difusor: para a televisão digital vão ser utilizados 13 segmentos.

Mais detalhes deste software são mostrados no Anexo A.

3.4.2 DtPlay

Para utilizar o cartão modulador no sistema operacional Linux o Dektec, pro-porciona o software chamado DtPlay. O Dtplay não tem interface gráfica e é executadosó na linha de comandos, mas pelo fato de ser compatível com Linux pode-se realizar amultiplexação e transmissão no mesmo sistema operacional.

O DtPlay tem diversas opções de parâmetros a escolher, mas nem todos sãonecessários. Alguns deles tem valores por 𝑑𝑒𝑓𝑎𝑢𝑙𝑡, mas outros são indispensáveis parauma correta transmissão. Alguns deles são mostrados na Tabela 7

Tabela 7 – Parâmetros do DtPlay

Configuração de parâmetros no DtPlayDtPlay playfile.ts -l 1 -t 2111 -m 188 -mt ISDBT -mf 533 -r 0

Tabela 8 – Parâmetros da multiplexação no DtPlay

Parâmetro Descriçãoplayfile.ts Arquivo que é usado como fonte de entrada

-t Indica o modelo de cartão a utilizar2111 É o modelo de cartão modulador que se vai utilizar

-m Indica o modo de transmissão, e mostra que o arquivode entrada contém pacotes de 188 bytes.

-mt Indica o tipo de modulação, neste caso a modulaçãoISDB-T.

-mf indica a frequência em que vai ser transmitida o TS

Os parâmetros disponíveis no DtPlay estão descritos no Anexo A.

55

4 Implementação e Avaliação dos Resultados

Este capítulo apresenta a abordagem do presente estudo, assim como os recur-sos que foram necessários para realizá-lo

4.1 AbordagemTendo como objetivo final a implementação de funções híbridas no atual sis-

tema brasileiro de televisão digital, a abordagem desta dissertação enfoca, numa primeiraetapa, a criação das tabelas PSI para a inserção de eventos DSM-CC Ginga e posteriorinserção de uma aplicação híbrida, baseada no padrão 𝐻𝑦𝑏𝑟𝑖𝑑 𝑏𝑟𝑜𝑎𝑑𝑐𝑎𝑠𝑡 𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑 𝑇𝑉 .

4.2 RecursosO desenvolvimento deste trabalho foi realizado num computador de processa-

dor Intel Core I7 e 4GB de memória RAM. O sistema operativo utilizado foi Linux Debian7.5.

O software utilizado foi o OpenCaster pelo fato de ser um software de có-digo aberto, sendo compatível com os sistemas operativos Linux. No desenvolvimentodo presente trabalho o OpenCaster funcionou corretamente uma vez já terminada suainstalação.

Foram analisadas teoricamente diversas placas moduladoras, tendo em contarobustez, compatibilidade entre outras características. Foi escolhida uma placa modula-dora da empresa Dektec por ser compatível como o sistema brasileiro de televisão digital,assim como o software StreamXpress o qual vai proporcionar em tempo real a reproduçãode 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚.

Foram utilizados cabos coaxiais e antenas de transmissão para os testes reali-zados.

Segundo a fundamentação teórica obtida anteriormente, segue o esquema in-dicado na Figura 11.

Este capítulo apresenta a metodologia usada neste trabalho e diversos testesrealizados no contexto desta pesquisa, que aborda a criação de arquivos de configuração etabelas de informação para a geração do TS. São apresentados os detalhes dos parâmetrosde software e de configuração de hardware utilizados.

Capítulo 4. Implementação e Avaliação dos Resultados 56

Figura 11 – Esquema desenvolvido

4.3 Codificação de arquivos audiovisuaisPara a criação do TS, o OpenCaster tem que estar configurado adequadamente

para aderência com às normas brasileiras. Para isto, deve-se especificar principalmentedois aspectos: os arquivos de áudio e vídeo que vão ser transmitidos e a informação dastabelas PSI que vão definir os parâmetros do TS.

Neste trabalho foi concebido um 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚 a partir de um arquivo devídeo próprio chamado video1.mov e um arquivo de áudio obtido a partir de um vídeocontendo áudio, para gerar os 𝑒𝑙𝑒𝑚𝑒𝑛𝑡 𝑠𝑡𝑟𝑒𝑎𝑚 de áudio e vídeo.

Foram definidas tabelas tais como PMT, NIT entre outras, neste caso foramcriadas dentro de um arquivo 𝑠𝑐𝑟𝑖𝑝𝑡 de nome "tabelas.py". A descrição completa dastabelas está indicada no Apêndice B.

4.3.1 Codificação e empacotamento de vídeo

Para realizar a codificação, partiu-se do arquivo de vídeo video1.mov, e utili-zando a ferramenta ffmpeg. Converteu-se tal arquivo num arquivo auxiliar que vai repre-sentar o arquivo ES, e em seguida, converte-se tal arquivo num arquivo PES. A estrutura


dos comandos utilizados está descrita na Tabela 9.

Tabela 9 – Geração do PES de vídeo

Vídeo de origem: video1.mov𝑓𝑓𝑚𝑝𝑒𝑔 𝑖 𝑣𝑖𝑑𝑒𝑜1.𝑚𝑜𝑣 𝑓 𝑦𝑢𝑣4𝑚𝑝𝑒𝑔𝑝𝑖𝑝𝑒 𝑎𝑢𝑥 ‖𝑥264_𝑝𝑒𝑠 𝑎𝑢𝑥 − 𝑙𝑒𝑣𝑒𝑙 4.0 − 𝑛𝑎𝑙ℎ𝑟𝑑 𝑐𝑏𝑟

-vbvbufsize 2000 -bitrate 7200 -keyint 12 -vbv-init 0 -o video1.pes

∙ ffmpeg é um comando utilizado para o suporte para a codificação e decodificaçãode arquivos de áudio e vídeo e converte arquivos de um formato a outro e cria comosaída 𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦 𝑠𝑡𝑟𝑒𝑎𝑚𝑠.

∙ video1.mov é o nome do arquivo de entrada o qual vai ser transformado em PES

∙ video1.pes é o nome designado ao arquivo PES

∙ -f indica o formato de saída

∙ level, representa o nível; no h264 são usados níveis como 3, 3.1,4.

Geração de arquivo TS de video

Para fazer a geração do arquivo TS de vídeo, converte-se o arquivo obtido PESde vídeo à um arquivo TS de vídeo, utilizando o comando 𝑝𝑒𝑠𝑣𝑖𝑑𝑒𝑜2𝑡𝑠 do OpenCaster. Aestrutura dos comandos utilizados consta na Tabela 10.

Tabela 10 – Geração do Transport Stream de vídeo

Vídeo de origem: video1.pespesvideo2ts 2066 30 112 9200000 0 video1.pes > video1.ts

2066 indica o valor do PID que é designado este sinal de vídeo30 define os 𝑓𝑟𝑎𝑚𝑒𝑠 por segundo

9200000 indica a largura de banda em bits/seg0 indica que não existe um 𝑙𝑜𝑜𝑝 no vídeo

video1.pes é o arquivo PES de entradavideo1.ts é o arquivo TS de saída

4.3.2 Codificação e empacotamento de aúdio

De forma semelhante à codificação realizada no vídeo, utilizou-se a ferramentaffmpeg e desse modo pode-se utilizar apenas a parte correspondente ao aúdio do arquivode entrada, de maneira se obter o ES de áudio. A estrutura do comando utilizado podeser observada na Tabela 11.


Tabela 11 – Geração do ES de áudio

Vídeo de origem: video1.movffmpeg -i video1.mov -vn -acodec aac -strict -2 -ar 48000 -ab 448k audio.aac

-i indica o arquivo que é usado como fonte de entrada.-vn serve para ignorar o sinal de vídeo durante a conversão.

-acodec estabelece o códec de áudio.-ar define a frequência de amostragem a 48000Hz.-ab é a taxa binária de sinal de áudio, 448k.

video1.mov é o arquivo de entrada do qual se obtém só o áudio.audio.aac é o arquivo de saída com formatação aac.

Para o empacotamento do arquivo ES de áudio utilizou-se o comando 𝑒𝑠𝑎𝑢𝑑𝑖𝑜2𝑝𝑒𝑠

o qual converte o arquivo audio.aac em um arquivo tipo PES. A Tabela 12 detalha estecomando.

Tabela 12 – Geração do PES de áudio

Arquivo de origem: audio.aacesaudio2pes audio.aac 1024 48000 1194 -1 3750 > audio.pes

audio.aac indica o arquivo que é usado como fonte de entrada.1024 indica o número de amostras por trama de áudio, é um

valor designado ao MPEG-4.48000 é a frequência de amostragem do sinal de áudio.1194 é o tamanho de trama do áudio.3750 é o valor do PTS, utilizado para sincronizar de forma

empírica o áudio com o vídeo.audio.pes é o arquivo de saída PES.

Geração de arquivo TS de áudio

Uma vez gerado o packetized elementary stream, é necessário gerar o arquivotransport stream, para isto vai ser utilizado o comando "pesvideo2ts", o qual é amostradona Tabela 13.

4.3.3 Geração de tabelas PSI

De acordo com o apresentado no Capítulo 2, a criação das tabelas PSI é neces-sária para a geração do transport stream final, para isto o OpenCaster oferece uma sériede ferramentas e 𝑠𝑐𝑟𝑖𝑝𝑡𝑠 que serão compilados por meio da linguagem de programaçãoPython, a qual será utilizada para a criação das tabelas.

O arquivo Python criado tem o nome de tabelas.py, e neste arquivo são desig-nados determinados valores os quais serão utilizados em mais de uma tabela. Os principaisparâmetros são indicados na Tabela 14.


Tabela 13 – Geração do TS de áudio

Arquivo de origem: audio.pespesaudio2ts 2069 1024 48000 1194 0 audio.pes > audio.ts

2069 é o PID designado ao sinal de vídeo.1024 Indica o número de amostras por trama de áudio, é um

valor designado ao MPEG-4.48000 é a frequência de amostragem do sinal de áudio.1194 é o tamanho de trama do áudio, é calculado mediante

fórmula.0 indica que não existe um 𝑙𝑜𝑜𝑝 no vídeo.

audio.pes indica o arquivo que é usado como fonte de entrada.audio.ts é o arquivo de saída TS

Tabela 14 – Multiplexação do TS.

Data Valor Descrição

𝑡𝑒𝑠𝑡𝑒_𝑡𝑠_𝑖𝑑 0x073b Identificador do TransportStream

𝑡𝑒𝑠𝑡𝑒_𝑟𝑒𝑑𝑒_𝑟𝑡𝑑𝑠𝑝 0x073b Identificador da rede𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑖𝑎 533 Frequência de transmissão

𝑟𝑒𝑚𝑜𝑡𝑒_𝑐𝑜𝑛𝑡𝑟𝑜𝑙𝑒 0x06 Acesso por meio de controleremoto

𝑠𝑒𝑟𝑣𝑖𝑐𝑖𝑜_𝑖𝑑 xe760 Id para descrever o serviço

𝑝𝑖𝑑_𝑝𝑚𝑡 1031Id utilizado para descrever oPID que tem a informaçãodentro do transport stream

Tabela NIT

Uma das tabelas que compõem as tabelas PSI, é a tabela NIT e algumas dasconfigurações mais importantes são apresentadas na Tabela 15.

Tabela 15 – Tabela NITParâmetros configurados na tabela NITnit = network_information_sectionnetwork_id = teste_rede_rtdsp,network_descriptor(network_name = "RT-DSP"),service_type = 0x19,# Televisão digitaltds_frequency_item(freq = frequencias)transport_stream_information_descriptorremote_control_key_id = remote_controle = "RT-DSP"

Segundo os parâmetros contidos na Tabela 13, foi designado o id da rede;neste caso a rede foi chamada teste_rede_rtdsp, por outro lado é indicada a frequênciade trabalho, o identificador do controle remoto e o nome indicado para o TS.

Os parâmetros completos da tabela NIT estão no Apêndice B.


Tabela SDT

Outra das tabelas pertencentes às tabelas PSI é a SDT, que define o nome dosprovedores de serviços e tipos de serviços que estão sendo oferecidos na rede. A continuaçãona Tabela 16 seleciona alguns dos parâmetros indicados.

Tabela 16 – Parâmetros da tabela SDTParâmetros indicados na tabela SDT𝑠𝑑𝑡 = 𝑠𝑒𝑟𝑣𝑖𝑐𝑒_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑖𝑜𝑛_𝑠𝑒𝑐𝑡𝑖𝑜𝑛(𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑠𝑡𝑟𝑒𝑎𝑚_𝑖𝑑 = 𝑡𝑒𝑠𝑡𝑒_𝑡𝑠_𝑖𝑑,𝑜𝑟𝑖𝑔𝑖𝑛𝑎𝑙_𝑛𝑒𝑡𝑤𝑜𝑟𝑘_𝑖𝑑 = 𝑡𝑒𝑠𝑡𝑒_𝑟𝑒𝑑𝑒_𝑟𝑡𝑑𝑠𝑝,𝑠𝑒𝑟𝑣𝑖𝑐𝑒_𝐼𝐷 = 𝑠𝑒𝑟𝑣𝑖𝑐𝑖𝑜_𝑖𝑑,𝑠𝑒𝑟𝑣𝑖𝑐𝑒_𝑡𝑦𝑝𝑒 = 0𝑥19

𝑠𝑒𝑟𝑣𝑖𝑐𝑒_𝑛𝑎𝑚𝑒 = ”𝑅𝑇 − 𝐷𝑆𝑃”,

O nome designado ao provedor de serviços é UNICAMP, o nome do serviço éRT-DSP. O parâmetro 0x19 correspondente ao tipo de serviço indica que é áudio e vídeodigital. Segundo (ABNT15603-1, 2007) o valor de PID atribuido para a tabela SDT é0x0011 que corresponde ao número 17. Os parâmetros completos da tabela SDT estãodescritos no Apêndice B.

Tabela PAT

A tabela PAT associa cada programa com um número PID para assim registrá-los dentro da PMT. Primeiramente descreve o 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑠𝑡𝑟𝑒𝑎𝑚_𝑖𝑑, neste caso de nome𝑡𝑒𝑠𝑡𝑒_𝑡𝑠_𝑖𝑑, em seguida atribui-se um valor PID à PMT, como é amostrado na Tabela17.

Tabela 17 – Parâmetros da tabela PATParâmetros indicados na tabela PAT𝑝𝑎𝑡 = 𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑎𝑠𝑠𝑜𝑐𝑖𝑎𝑡𝑖𝑜𝑛_𝑠𝑒𝑐𝑡𝑖𝑜𝑛(𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑠𝑡𝑟𝑒𝑎𝑚_𝑖𝑑 = 𝑡𝑒𝑠𝑡𝑒_𝑡𝑠_𝑖𝑑,𝑃𝐼𝐷 = 16,𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑛𝑢𝑚𝑏𝑒𝑟 = 𝑠𝑒𝑟𝑣𝑖𝑐𝑖𝑜_𝑖𝑑,𝑃𝐼𝐷 = 𝑝𝑖𝑑_𝑝𝑚𝑡

Tabela PMT

Outra das tabelas geradas é a tabela PMT, onde são indicados parâmetros taiscomo os PID que são designados aos arquivos de áudio e vídeo, o tipo de fluxo para cadaum deles. Na Tabela 18 é indicado o PID 2066 para o caso de arquivo de vídeo e PID2069 para o caso do arquivo de áudio.

Finalmente as tabelas são escritas mediante o uso dos seguintes comandos:


Tabela 18 – Parâmetros da tabela PMTParâmetros indicados na tabela PMT𝑝𝑚𝑡_𝑠𝑑 = 𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑚𝑎𝑝_𝑠𝑒𝑐𝑡𝑖𝑜𝑛(𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑛𝑢𝑚𝑏𝑒𝑟 = 𝑠𝑒𝑟𝑣𝑖𝑐𝑖𝑜_𝑖𝑑,𝑠𝑡𝑟𝑒𝑎𝑚_𝑡𝑦𝑝𝑒 = 0𝑥1𝐵𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦_𝑃𝐼𝐷 = 2066,𝑠𝑡𝑟𝑒𝑎𝑚_𝑙𝑜𝑜𝑝_𝑖𝑡𝑒𝑚(𝑠𝑡𝑟𝑒𝑎𝑚_𝑡𝑦𝑝𝑒 = 0𝑥06𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦𝑃 𝐼𝐷 = 2069

out = open("./nit.sec", "wb"os.system("sec2ts 16 < ./nit.sec > ./nit.ts")os.system("sec2ts 0 < ./pat.sec > ./pat.ts")os.system("sec2ts 17 < ./sdt.sec > ./sdt.ts")os.system("sec2ts "str(pid_pmt)« ./pmt_sd.sec > ./pmt_sd.ts")

Com as tabelas feitas no arquivo Python, as tabelas são criadas automatica-mente ao executar o comando 𝑡𝑎𝑏𝑒𝑙𝑎𝑠.𝑝𝑦, e são gerados arquivos .sec e .ts de nome pat,sdt, 𝑝𝑚𝑡_𝑠𝑑, nit com as características descritas anteriormente.

Criação do Transport Stream

Com os arquivos TS de aúdio e vídeo e as tabelas criadas, é efetuada a mul-tiplexação, em que se utiliza a ferramenta 𝑡𝑠𝑐𝑏𝑟𝑚𝑢𝑥𝑒𝑟 a qual vai permitir obter um𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚 de nome prueba1.ts a partir dos 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚𝑠 de áudio e vídeo edas tabelas criadas.

Tabela 19 – Multiplexação do TS

tscbrmuxer 1200000 b:15040 pat.ts b:15040 pmt_sd.ts b:3008 sdt.ts b:3008 nit.tsb:9200000 video1.ts b:188000 audio.ts b:20534198 null.ts > prueba1.ts

Data Description1200000 O padrão ISDB-T pode transmitir 2000 pacotes por segundo, para

um arquivo de 60 segundos obtemos 1200000 pacotes para multi-plexar.

15040 Cada pacote tem 188 bytes ou 1504 bits, a PAT e PMT enviamdados a uma velocidade de 10 vezes por segundo então a largurade banda é 15040 bps.

9200000 Largura de banda do arquivo de vídeo de 9200000.188000 Largura de banda do arquivo de áudio de 188000.

20534198 Largura de banda dos pacotes nulos. O padrão ISDB-T tem umalargura de banda de 29958294 bps, então subtraindo a soma dosvalores listados acima, obtemos 20534198 .


Inserção da aplicação Ginga no Transport Stream

Ao adicionar a aplicação Ginga ao 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚; habilita-se abrindo ca-minho ao conteúdo iterativo. Assim de forma semelhante ao processo anterior, para confi-gurar os parâmetros do Ginga, é preciso criar uma tabela adicional, chamada tabela AIT.Para trabalhar com a norma ISDBT, foi utilizado o patch da (LIFIA, 2011) e adaptadopara a versão do Open Caster utilizada no presente trabalho OpenCaster 3.2.2.

A tabela AIT tem parâmetros específicos e muito importantes, pois são ane-xados às outras tabelas, e outros deles parâmetros são introduzidos dentro das tabelasexistentes.

𝑎𝑖𝑡 = 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑖𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛_𝑠𝑒𝑐𝑡𝑖𝑜𝑛(𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑡𝑦𝑝𝑒 = 0𝑥0009𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑛𝑎𝑚𝑒_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑛𝑎𝑚𝑒 = ”𝑎𝑝𝑝_𝑔𝑖𝑛𝑔𝑎”𝑔𝑖𝑛𝑔𝑎_𝑛𝑐𝑙_𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑏𝑎𝑠𝑒_𝑑𝑖𝑟𝑒𝑐𝑡𝑜𝑟𝑦 = ”/”,

𝑐𝑙𝑎𝑠𝑠_𝑝𝑎𝑡ℎ_𝑒𝑥𝑡𝑒𝑛𝑠𝑖𝑜𝑛 =,

𝑖𝑛𝑖𝑡𝑖𝑎𝑙_𝑐𝑙𝑎𝑠𝑠 = ”𝑝𝑟𝑖𝑛𝑐𝑖𝑝𝑎𝑙.𝑛𝑐𝑙”,

Dentro da tabela PMT são introduzidos alguns parâmetros, tais como”𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑡𝑦𝑝𝑒 = 𝑔𝑖𝑛𝑔𝑎_𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛” para definir o tipo de aplicação, entre outros.O arquivo Ginga tem nome teste.ncl e o código detalhado está apresentado no ApêndiceB.

Para escrever a tabela AIT para a aplicação Ginga, é necessário seguir o pro-cedimento das tabelas anteriores. Agrega-se ao arquivo tabelas.py os comandos seguintes:

out = open("./ait.sec", "wb")out.write(ait.pack())out.close()os.system("sec 2ts "+ str(2001) + « ./ait.sec > ./ait.ts")

Para que a nova tabela e as mudanças feitas na tabela PMT tenham efeito,tem que se executar novamente o arquivo Python "tabelas.py".

Neste trabalho foi utilizada a aplicação teste.ncl, desenvolvida por um inte-grante da equipe de Laboratório RT-DSP da FEEC-UNICAMP (RT-DSP, 2012), e foiintroduzida dentro da pasta "app_ginga", situada por sua vez na pasta de trabalho doOpenCaster.

Para a geração do carrossel de objeto, o OpenCaster oferece uma ferramenta


de nome oc_update.sh e é utilizado do seguinte modo:

< 𝑜𝑐_𝑢𝑝𝑑𝑎𝑡𝑒 .𝑠ℎ 𝑎𝑝𝑝_𝑔𝑖𝑛𝑔𝑎 0𝑥0𝐶 1 2005 2 >

O parâmetro 0x0C especifica o 𝑎𝑠𝑠𝑜𝑐𝑖𝑎𝑡𝑖𝑜𝑛_𝑡𝑎𝑔 de carrossel gerado. Este pa-râmetro é especificado na tabela AIT gerada anteriormente e especificada na norma dereferência (ISO.13818-6, 2000).

O número 2005 é o número do identificador PID na sinalização do carrossel.O número 2 indica o número identificador do carrossel.

Este conjunto de comandos permite a criação do arquivo app_ginga.ts, e podeser introduzido no 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚 a ser gerado.

A multiplexação é feita utilizando novamente o comando 𝑡𝑠𝑐𝑏𝑟𝑚𝑢𝑥𝑒𝑟 agre-gando os dados correspondentes à tabela AIT.

𝑡𝑠𝑐𝑏𝑟𝑚𝑢𝑥𝑒𝑟 1200000 𝑏 : 15040 𝑝𝑎𝑡.𝑡𝑠 𝑏 : 15040 𝑝𝑚𝑡_𝑠𝑑.𝑡𝑠 𝑏 : 3008 𝑠𝑑𝑡.𝑡𝑠

𝑏 : 3008 𝑛𝑖𝑡.𝑡𝑠 𝑏 : 1000000 𝑎𝑝𝑝𝑔𝑖𝑛𝑔𝑎.𝑡𝑠 𝑏 : 9200000 𝑣𝑖𝑑𝑒𝑜1.𝑡𝑠 𝑏 : 188000 𝑎𝑢𝑑𝑖𝑜.𝑡𝑠 𝑏 :201311190 𝑛𝑢𝑙𝑙.𝑡𝑠 > 𝑝𝑟𝑢𝑒𝑏𝑎1_𝑔𝑖𝑛𝑔𝑎.𝑡𝑠

Observa-se que agora o valores dos pacotes nulos diminuiu pois com a inclusãoda aplicação Ginga, a somatória total de bits será maior. Como é indicado na Tabela 20.

Tabela 20 – Multiplexação do TS incluíndo Ginga.

Dado Description

1200000O padrão ISDB-T pode transmitir 2000 pacotes porsegundo; para um arquivo de 60 segundos obtém-se1200000 pacotes para multiplexar.

15040Cada pacote tem 188bytes ou 1504bits, a PAT e PMTenviam dados a uma velocidade de 10 vezes por segundoentão a largura de banda é 15040bps.

9200000 Largura de banda do arquivo de vídeo de 9200000.188000 Largura de banda do arquivo de áudio de 188000.1000000 Tamanho da aplicação Ginga

201311190

Largura de banda dos pacotes nulos. O padrão ISDB-T tem uma largura de banda de 29958294 bps, entãosubtraindo a soma dos valores listados acima, obtemos201311190.

Assim foi obtido o 𝑇𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑆𝑡𝑟𝑒𝑎𝑚 𝑇𝑒𝑠𝑡𝑒𝑓𝑖𝑛𝑎𝑙.𝑡𝑠. Com a aplicação Gingaintroduzida, esta aplicação é transmitida à televisão mediante o cartão Dektec e o softwareStreamXpress.

Para uma conexão pora transmisão pelo ar, utilizaram-se os seguintes parâ-metros de configuração:


∙ Modulaçao: ISDB-T

∙ Potência: -12dB

∙ Largura de banda: 6 MHz

∙ Frequência de canal: 695.1 MHz

∙ Canal: 50

Para uma transmissão mediante cabo coaxial, a potência foi ajustada em -20dB.

Finalmente o teste é amostrado nas Figuras 12 e 13, como observamos, oícone da letra "i"cor vermelho indica a existência de uma aplicação Ginga dentro do sinalrecebido.

Figura 12 – Teste: Incluindo aplicação Ginga no TS.

A aplicação Ginga consiste numa breve guia sobre a Faculdade de EngenhariaElétrica e Computação da UNICAMP como é amostrado na Figura 14.

Por meio do SW StreamXpress, podem ser observados alguns parâmetros uti-lizados nas tabelas na criação do TS, tais como o nome do provedor de serviço, neste casofoi "unicamp". O número do canal foi direcionado de acordo à frequência estabelecida.

Adicionalmente se pode observar componentes do TS, tais como os arquivosde áudio, vídeo e dados, número de PID e tipo de padrão utilizado, como é amostrado naFigura 15.


Figura 13 – Aplicação Ginga inclusa no TS

Figura 14 – Teste: Aplicação Ginga no TS.

Abrindo caminho para o HbbTV

Devido ao fato de que o objetivo final do projeto Global-ITV é a inserção defunções híbridas no sinal de transmissão, o seguinte passo abre caminho para a inserção


Figura 15 – Analisador do TS.

de uma aplicação híbrida, tendo particular foco nas aplicações HbbTV.

Para a inserção de uma aplicação HbbTV, deve-se fazer um estudo detalhadodas tabelas e/ou parâmetros que devem ser inseridos no TS, há uma similaridade emalguns aspectos em relação às tabelas Ginga.

Para isto, ter-se-ia que se agregar um cabeçalho no arquivo principal Pythonindicando que vai se trabalhar com o padrão HbbTV, segundo (OPENCASTER, 2008)corresponderia o seguinte cabeçalho:

𝑓𝑟𝑜𝑚 𝑑𝑣𝑏𝑜𝑏𝑗𝑒𝑐𝑡𝑠.𝐻𝐵𝐵𝑇𝑉.𝐷𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟𝑠 𝑖𝑚𝑝𝑜𝑟𝑡*

No caso das tabelas PMT, indica-se o tipo de aplicação que será inserida,segundo (HBBTVERRATA2, 2012) quando se tem mais de um fluxo de dados como seriano caso de ter uma aplicação Ginga e uma aplicação HbbTV em um único TS, ter-se-iaque indicar o parâmetro 𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑡𝑦𝑝𝑒 com um valor de "0x0010" para sinalizar queestará presente uma aplicação HbbTV.

𝑝𝑚𝑡.𝑎𝑝𝑝𝑒𝑛𝑑(𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑚𝑎𝑝_𝑠𝑒𝑐𝑡𝑖𝑜𝑛(𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑛𝑢𝑚𝑏𝑒𝑟 = 𝑑𝑒𝑚𝑜_𝑠𝑒𝑟𝑣𝑖𝑐𝑒_𝑖𝑑[𝑖],𝑃𝐶𝑅_𝑃𝐼𝐷 = 2064 + 𝑖 * 2,

𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑖𝑛𝑓𝑜_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟_𝑙𝑜𝑜𝑝 = [],𝑠𝑡𝑟𝑒𝑎𝑚_𝑙𝑜𝑜𝑝 = [𝑠𝑡𝑟𝑒𝑎𝑚_𝑙𝑜𝑜𝑝_𝑖𝑡𝑒𝑚(


𝑠𝑡𝑟𝑒𝑎𝑚_𝑡𝑦𝑝𝑒 = ,

𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦_𝑃𝐼𝐷 = 𝑣𝑖𝑑𝑒𝑜_𝑝𝑖𝑑[𝑖],𝑒𝑙𝑒𝑚𝑒𝑛𝑡_𝑖𝑛𝑓𝑜_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟_𝑙𝑜𝑜𝑝 = []),𝑠𝑡𝑟𝑒𝑎𝑚_𝑙𝑜𝑜𝑝𝑖𝑡𝑒𝑚(𝑠𝑡𝑟𝑒𝑎𝑚_𝑡𝑦𝑝𝑒 = 3,

𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦_𝑃𝐼𝐷 = 𝑎𝑢𝑑𝑖𝑜_𝑝𝑖𝑑[𝑖],𝑒𝑙𝑒𝑚𝑒𝑛𝑡_𝑖𝑛𝑓𝑜_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟_𝑙𝑜𝑜𝑝 = []),𝑠𝑡𝑟𝑒𝑎𝑚_𝑙𝑜𝑜𝑝𝑖𝑡𝑒𝑚(𝑠𝑡𝑟𝑒𝑎𝑚_𝑡𝑦𝑝𝑒 = 5, 𝑖𝑛𝑑𝑖𝑐𝑎 𝑎 𝑡𝑎𝑏𝑒𝑙𝑎 𝐴𝐼𝑇

𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑟𝑦_𝑃𝐼𝐷 = 𝑎𝑖𝑡_𝑝𝑖𝑑[𝑖],𝑒𝑙𝑒𝑚𝑒𝑛𝑡_𝑖𝑛𝑓𝑜_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟_𝑙𝑜𝑜𝑝 = [𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑠𝑖𝑔𝑛𝑎𝑙𝑙𝑖𝑛𝑔_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑡𝑦𝑝𝑒 = 0𝑥0010, 𝑖𝑛𝑑𝑖𝑐𝑎 𝑞𝑢𝑒 è 𝑢𝑚 𝑠𝑒𝑟𝑣𝑖ç𝑜 𝐻𝑏𝑏𝑇𝑉

𝐴𝐼𝑇_𝑣𝑒𝑟𝑠𝑖𝑜𝑛 = 1,

Além disso, como a função híbrida incorpora uma função que depende da bandalarga, ter-se-ia que sinalizar na tabela adicional AIT que estará presente uma aplicação”𝑏𝑟𝑜𝑎𝑑𝑏𝑎𝑛𝑑”, a tabela AIT completa é detalhada no apêndice A.

𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟𝑠_𝑙𝑜𝑜𝑝 = [𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙_𝑖𝑑 = 0𝑥0003, #𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙𝑜𝐻𝑇𝑇𝑃 𝑙

𝑈𝑅𝐿_𝑏𝑎𝑠𝑒 = 𝑎𝑝𝑝𝑙𝑖_𝑟𝑜𝑜𝑡,

𝑈𝑅𝐿_𝑒𝑥𝑡𝑒𝑛𝑠𝑖𝑜𝑛𝑠 = [],𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙_𝑙𝑎𝑏𝑒𝑙 = 3, #𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙𝑜𝐻𝑇𝑇𝑃

𝑎𝑝𝑝𝑙𝑖_𝑛𝑎𝑚𝑒 = [”𝑢𝑛𝑖𝑐𝑎𝑚𝑝”, ”𝑢𝑛𝑖𝑐𝑎𝑚𝑝”] 𝑖𝑛𝑑𝑖𝑐𝑎 𝑜 𝑛𝑜𝑚𝑒 𝑑𝑎 𝑎𝑝𝑙𝑖𝑐𝑎çã𝑜

𝑎𝑝𝑝𝑙𝑖_𝑟𝑜𝑜𝑡 = [”ℎ𝑡𝑡𝑝 : //𝑒𝑥𝑒𝑚𝑝𝑙𝑜.𝑡𝑒𝑠𝑡𝑒/𝑑𝑒𝑐𝑜𝑚”, ”ℎ𝑡𝑡𝑝 : //𝑒𝑥𝑒𝑚𝑝𝑙𝑜.𝑡𝑒𝑠𝑡𝑒/𝑑𝑒𝑐𝑜𝑚”]𝑖𝑛𝑑𝑖𝑐𝑎 𝑎 𝑟𝑜𝑡𝑎 𝑜𝑛𝑑𝑒 𝑒𝑠𝑡𝑎𝑟𝑖𝑎 𝑙𝑜𝑐𝑎𝑙𝑖𝑧𝑎𝑑𝑎 𝑎 𝑎𝑝𝑙𝑖𝑐𝑎çã𝑜

𝑎𝑝𝑝𝑙𝑖_𝑝𝑎𝑡ℎ = [”𝑖𝑛𝑑𝑒𝑥.ℎ𝑡𝑚𝑙”, ”𝑖𝑛𝑑𝑒𝑥.ℎ𝑡𝑚𝑙”] é 𝑜 𝑎𝑟𝑞𝑢𝑖𝑣𝑜 𝑏𝑎𝑠𝑒 𝑑𝑎 𝑎𝑝𝑙𝑖𝑐𝑎çã𝑜 𝐻𝑏𝑏𝑇𝑉

𝑝𝑜𝑟 𝑒𝑥𝑒𝑚𝑝𝑙𝑜 ”ℎ𝑡𝑡𝑝 : //𝑀𝑖𝑛ℎ𝑎𝑝𝑟𝑖𝑚𝑒𝑖𝑟𝑎𝑎𝑝𝑙𝑖𝑐𝑎çã𝑜/𝑡𝑒𝑠𝑡𝑒/𝑖𝑛𝑑𝑒𝑥.ℎ𝑡𝑚𝑙”

No caso que a aplicação HbbTV seja do tipo DSM-CC, a informação incluidana tabela AIT seria a seguinte:

𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟𝑠_𝑙𝑜𝑜𝑝 = [𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙_𝑖𝑑 = 0𝑥0001, # 𝑎 𝑎𝑝𝑙𝑖𝑐𝑎çã𝑜 é 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑖𝑑𝑎 𝑒𝑚 𝐷𝑆𝑀 − 𝐶𝐶

𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡_𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙_𝑙𝑎𝑏𝑒𝑙 = 0𝑥0001, # 𝑎 𝑎𝑝𝑙𝑖𝑐𝑎çã𝑜 é 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑖𝑑𝑎 𝑒𝑚 𝐷𝑆𝑀 − 𝐶𝐶


𝑟𝑒𝑚𝑜𝑡𝑒_𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛 = 0, # 𝑝𝑎𝑟𝑎 𝐻𝑏𝑏𝑇𝑉

𝑐𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡_𝑡𝑎𝑔 = 0𝑥𝐵, # 𝑜𝑏𝑗𝑒𝑡𝑜 𝑐𝑎𝑟𝑟𝑜𝑠𝑠𝑒𝑙

),

𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑛𝑎𝑚𝑒_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑛𝑎𝑚𝑒 = 𝑎𝑝𝑝𝑙𝑖_𝑛𝑎𝑚𝑒),𝑠𝑖𝑚𝑝𝑙𝑒_𝑎𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛_𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛_𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟(𝑖𝑛𝑖𝑡𝑖𝑎𝑙_𝑝𝑎𝑡ℎ_𝑏𝑦𝑡𝑒𝑠 = 𝑎𝑝𝑝𝑙𝑖_𝑝𝑎𝑡ℎ),

Por outro lado, no caso do multiplexador, ter-se-ia que incluir a AIT exclusivapara aplicação HbbTV, uma possível alternativa de multiplexado seria o seguinte:

tscbrmuxer c:2300000 video1.ts b:188000 audio1.ts b:2300000 video2.ts b:188000audio2.ts b:3008 pat.ts b:3008 pmt0.ts b:3008 pmt1.ts b:1400 nit.ts b:1500 sdt.ts b:1400ait1.ts b:1400 ait2.ts > Tsfinal.ts

A aplicação HbbTV inserida no TS ainda não foi testada na televisão nomomento da finalização deste trabalho. A continuidade de projeto GlobalITV prevê odesenvolvimento de STB com suporte para HbbTV e Ginga simultaneamente.

69

5 Conclusão

A implementação do Sistema Brasileiro de Televisão Digital foi baseada nopadrão ISDB-T, mas incluiu algumas melhorias como a adoção do padrão MPEG-4 paraa codifição de vídeo e áudio e a implementação do 𝑚𝑖𝑑𝑑𝑙𝑤𝑎𝑟𝑒 Ginga. Embora o Gingaseja um middleware avançado, ainda não se observa uma utilização abrangente do mesmopor parte dos radiodifusores. Isto abre caminho para a busca de soluções que sejam defacto aceitas amplamente pelo mercado.

Atualmente, os fabricantes de televisões começaram a incorporar um navega-dor Web no receptor, as já conhecidas 𝑆𝑚𝑎𝑟𝑡−𝑇𝑉 𝑠 ou 𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑒𝑑−𝑇𝑉 𝑠, cada uma comnovas e diferentes aplicações para atrair o público. Todavia, ocorre problemas de incom-patibilidades entre as diferentes marcas, uma aplicação não vai funcionar necessariamenteem duas ou três marcas diferentes de televisões, além do problema de portal de acessoprivativo. A concepção de um sistema que ofereça a integração entre a radiodifusão ebanda larga da Internet está sendo pesquisada atualmente em diversas partes do mundo.

O presente trabalho enquadra-se no projeto Global-ITV, que tem entre seusobjetivos o desenvolvimento da interoperabilidade, coexistência e convergência da tecno-logia HbbTV e o 𝑚𝑖𝑑𝑑𝑙𝑒𝑤𝑎𝑟𝑒 Ginga, em diversas plataformas de televisão digital, taiscomo ISDB-T e DVB-T.

O trabalho apresentou os fundamentos teóricos gerais para compreensão das di-ferenças entre o sistema de televisão digital adotado pelo Brasil e o sistema japonês. Tam-bém foi estudada a fundamentação teórica para a criação das tabelas do 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚

e do carrossel de dados DCM-CC.

Assim também foram estudados os diferentes modelos de sistemas híbridos queexistem atualmente no mundo, entender suas diferenças e assim poder resgatar o melhorde cada uma delas.

A criação do 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚, com a inclusão do Ginga é um primeiro passopara a inclusão de funções híbridas. Para isto foi importante o estudo das normas do ISDB-T, para assim poder compreender e construir as tabelas PSI necessárias para a geraçãodo TS de acordo com as normas ABNT do Sistema Brasileiro de Televisão Digital.

Encontrou-se uma similaridade entre as tabelas para a inserção da aplicaçãoGinga no TS, com as tabelas a serem desenvolvidas para a inserção da aplicação HbbTVdentro do mesmo transport stream, o qual abre caminho para a inserção das funçõeshíbridas no ISDB-Tb.

Capítulo 5. Conclusão 70

5.1 Trabalhos futurosCom a inclusão da aplicação Ginga dentro do 𝑇𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑆𝑡𝑟𝑒𝑎𝑚 gerado e com

o estudo do sistema híbrido HbbTV, tem-se como trabalhos futuros a implementação dasfunções híbridas dentro do 𝑡𝑟𝑎𝑛𝑠𝑝𝑜𝑟𝑡 𝑠𝑡𝑟𝑒𝑎𝑚 gerado, para cumprir assim com o objetivomaior do projeto Global-ITV, onde a implementação das tabelas de sinalização estudasneste trabalho serão levadas em consideração.

Outro problema a ser estudado consistem em mecanismos de sincronismo dadenominada segunda tela, conforme foi comentado no presente trabalho.

71

Referências

ABNT NBR 15602-2. Televisão digital terrestre-Codificação de áudio: Sistemas demultiplexação de sinais. Rio de Janeiro, 2008. 16 p. Citado 3 vezes nas páginas , 28 e 29.

ABNT NBR 15602-3. Televisão digital terrestre-Codificação de vídeo, áudio emultiplexação: Sistemas de multiplexação de sinais. Rio de Janeiro, 2008. 21 p. Citado 3vezes nas páginas , 34 e 36.

ABNT NBR 15603-1. Televisão digital terrestre – Multiplexação e serviços daInformação(SI): Parte 1: Si del sistema de radiodifução. Rio de Janeiro, 2007. 305 p.Citado na página 60.

ABNT NBR 15606-1. Televisão digital terrestre – Codificação de dados e especificaçõesde transmissão para radiodifusão digital: Parte 1: Codificação de dados. Rio de Janeiro,2007. 305 p. Citado na página 24.

ABNT NBR 15606-2. Televisão digital terrestre – Codificação de dados e especificações detransmissão para radiodifusão digital: Parte 2: Ginga-ncl para receptores fixos e móveis –linguagem de aplicação xml para codificação de aplicações. Rio de Janeiro, 2007. 305 p.Citado 3 vezes nas páginas , 22 e 25.

ABNT NBR 15606-3. Televisão digital terrestre – Codificação de dados e especificaçõesde transmissão para radiodifusão digital: Parte 3: Especificação de transmissão de dados.Rio de Janeiro, 2007. 305 p. Citado na página 26.

ABNT NBR 15606-6. Televisão digital terrestre – Codificação de dados e especificaçõesde transmissão para radiodifusão digital: Parte 6: Java dtv 1.3. Rio de Janeiro, 2007.860 p. Citado na página 22.

DECRETO4901: "institui o sistema brasileiro de televisão digital - sbtvd, edá outras providências- presidência da república. 2003. Disponível em: <http://www.planalto.gov.br/ccivil_03/decreto/2003/d4901.htm>. Citado na página 18.

DEKTEC2111: Dektec dta21111 multi-standard vhf/uhf modulator. 2011. Disponívelem: <http://www.dektec.com/products/PCIe/DTA-2111/>. Citado 2 vezes naspáginas 53 e 85.

ETSI-102 796. Hybrid Broadcast Broadband TV : . France, 2010. 75 p. Citado 2 vezesnas páginas 44 e 47.

ETSI-102 809. Digital Video Broadcasting (DVB): Signalling and carriage of interactiveapplications and services in hybrid broadcast/broadband environments. France, 2010.98 p. Citado na página 46.

FIREHBBTV: Firehbbtv 1.3.17. 2012. Disponível em: <https://addons.mozilla.org/fr/firefox/addon/firehbbtv/>. Citado 2 vezes nas páginas 52 e 88.

GLOBALITV: "interoperability of interactive and hybrid tv systems - a new advancedscheme for future services and applications in a global enviroment". 2014. Disponível em:<http://www.globalitv.org>. Citado na página 19.

http://www.planalto.gov.br/ccivil_03/decreto/2003/d4901.htm

http://www.planalto.gov.br/ccivil_03/decreto/2003/d4901.htm

http://www.dektec.com/products/PCIe/DTA-2111/

https://addons.mozilla.org/fr/firefox/addon/firehbbtv/

https://addons.mozilla.org/fr/firefox/addon/firehbbtv/

http://www.globalitv.org

Referências 72

HBBTV.ORG. HbbTV Specification Errata 2 : . Alemanha, 2012. 57 p. Citado na página66.

ISO 13818-1. Information technology — Generic coding of moving pictures and associatedaudio information: Systems: Second edition. Suíça, 2000. 174 p. Citado 2 vezes naspáginas 27 e 33.

ISO 14496-3. Information technology — Coding of audio-visual objects: Parte 3: Áudio.Suíça, 2005. 1172 p. Citado 5 vezes nas páginas 22, 27, 29, 32 e 33.

ISO/IEC 13818-6. Information technology — Generic coding of moving pictures andassociated audio information: Part 6: Extensions for dsm-cc. Suiça, 2000. 8 p. Citado 2vezes nas páginas 26 e 63.

ITU-R BS.775-1. MULTICHANNEL STEREOPHONIC SOUND SYSTEM WITH ANDWITHOUT ACCOMPANYING PICTURE : Second edition. França, 1994. 10 p. Citadona página 29.

ITU-R BT.2267-2. Integrated broadcast-broadband systems: Broadcasting service.International Telecommunication Union, 2014. 42 p. Citado na página 40.

ITU-T J.206. Arquitecture for an application control framework using integrated broadcastand broadband digital television: Series j, application for interactive digital television.International Telecommunication Union, 2013. 32 p. Citado 3 vezes nas páginas , 40e 41.

LIFIA: Lifia. 2011. Disponível em: <ftp://tvd.lifia.info.unlp.edu.ar/OpenCaster2.4/README.OpenCaster2.4-lifia-rev362.txt>. Citado na página 62.

LINUXSDK: Drivers and software development kits (sdks). 2014. Disponível em:<http://www.dektec.com/Downloads/DriversSDKs.asp>. Citado na página 86.

OPENCASTER: Opencaster 3.2.2. 2008. Disponível em: <http://www.avalpa.com/the-key-values/15-free-software/33-opencaster>. Citado 2 vezes nas páginas 51 e 66.

OPERA: "opera software". 1995. Disponível em: <http://www.operasoftware.com/>.Citado 2 vezes nas páginas 52 e 88.

OPERAHBBTV: "opera hbbtv emulator". 2012. Disponível em: <http://business.opera.com/solutions/tv/emulator>. Citado na página 52.

RAO, D. N. K. K. R.; HWANG, J. J. Video Coding Standards. [S.l.]: Springer, 2014.Citado 2 vezes nas páginas 27 e 28.

RT-DSP: Laboratório de processamento digital de sinais em tempo real. 2012. Disponívelem: <http://www.rt-dsp.fee.unicamp.br/>. Citado na página 62.

STREAMXPRESS: Dtc-300 streamxpress. 2014. Disponível em: <http://www.dektec.com/products/Apps/DTC-300/>. Citado na página 85.

VIRTUALBOX: Oracle vm virtualbox. 2007. Disponível em: <https://www.virtualbox.org/>. Citado 2 vezes nas páginas 52 e 88.

ftp://tvd.lifia.info.unlp.edu.ar/OpenCaster2.4/README.OpenCaster2.4-lifia-rev362.txt

ftp://tvd.lifia.info.unlp.edu.ar/OpenCaster2.4/README.OpenCaster2.4-lifia-rev362.txt

http://www.dektec.com/Downloads/DriversSDKs.asp

http://www.avalpa.com/the-key-values/15-free-software/33-opencaster

http://www.avalpa.com/the-key-values/15-free-software/33-opencaster

http://www.operasoftware.com/

http://business.opera.com/solutions/tv/emulator

http://business.opera.com/solutions/tv/emulator

http://www.rt-dsp.fee.unicamp.br/

http://www.dektec.com/products/Apps/DTC-300/

http://www.dektec.com/products/Apps/DTC-300/

https://www.virtualbox.org/

https://www.virtualbox.org/

Referências 73

WIEGAND, T.; SULLIVAN, G. The h.264/avc video coding standard [standards in anutshell]. Signal Processing Magazine, IEEE, v. 24, n. 2, p. 148–153, March 2007. ISSN1053-5888. Citado na página 27.

Apêndices

75

APÊNDICE A – Artigos do autor

Os artigos realizados e presentados ao momento da presente dissertação demestrado, Janeiro do 2015, são os que seguem a continuação.

1. Diretrizes para a realização em hardware de um algoritmo DSP. Caso de estudo:TransformadaDiscreta de Cosseno J.R. Tume, J. L. Hinostroza e L. G. P. Meloni(Orientador) 4o

Simpósio de Processamento de Sinais da UNICAMP (SPS-UNICAMP’2013)

2. Analysis of the implementation of hybrid functions in the current brazilian digitaltelevision system Jackelyn Tume Ruiz, Felipe Chicaiza Gomez, Luis Geraldo P. Me-loni 2014 IEEE Fourth International Conference on Consumer Electronics - Berlin(ICCE-Berlin)

76

APÊNDICE B – Arquivo script

A continuação é amostrada a codificação necessária para a geração das tabelasPSI. Começamos a construção do arquivo indicando os cabeçalhos.

Indicação dos cabeçalhos!/usr/bin/env python import osfrom dvbobjects.PSI.PAT import *from dvbobjects.PSI.NIT import *from dvbobjects.PSI.SDT import *from dvbobjects.PSI.PMT import *from dvbobjects.SBTVD.Descriptors import *teste_ts_id = 0x073b # ID da rede.teste_rede_rtdsp_id = 0x073b # ID da rede original.frequencia = 533 #frequencia de transmissão.remote_controle = 0x05 # tecla do controle remoto virtual caso precisar.servicio_id = 0xe760 # identificador de serviço de televisão digital.pid_pmt = 1031 #PID da PMT que vai ser utilizado.

Data Descriptionteste_ts_id Identificador da rede

teste_rede_rtdsp_id Identificador da rede original

frequencia Frequência de transmissão do Transport Stream, nestecaso a frequencia é 533MHz

remote_controle Tecla de controle remoto virtual é usado para escolhero canal mais rápido

servicio_id Identificador de serviço de Tv digital

pid_pmt é o PID que vai ser utilizado para transmitir a informa-ção que compõe o serviço

Tabela 21 – Parâmetros dos cabeçalhos das tabelas PSI.

Definição da rede NITnit = network_information_section(network_id = teste_rede_rtdsp_id,network_descriptor_loop = [network_descriptor(network_name = "RT-DSP",), # nome de nossa redesystem_management_descriptor(

APÊNDICE B. Arquivo script 77

broadcasting_flag = 0, # indica que a transmissão é de televisão abertabroadcasting_identifier = 3, # o valor igual a 3 indica que o sistema é ISDB-Tadditional_broadcasting_identification = 0x01, # valor especificado pelo proveedoradditional_identification_bytes = [],)],transport_stream_loop = [transport_stream_loop_item(transport_stream_id = teste_ts_id, # serve para identificar a nossa rede e diferencia-lade outrasoriginal_network_id = teste_rede_rtdsp, # pega o valor da ID de redetransport_descriptor_loop = [service_list_descriptor( , # descriptor da lista de serviçosdvb_service_descriptor_loop = [service_descriptor_loop_item (service_ID = teste_rede_rtdsp, # ID de serviçoservice_type = 0x19, # serviço de TV digital),],),terrestrial_delivery_system_descriptor( # descritor do sistema de distribuição terrestrearea_code = 1341, # codigo de áreaguard_interval = 0x01,transmission_mode = 0x02, # valor segundo norma 2 bits, 10frequencies = [tds_frequency_item( freq=frequencia)],),partial_reception_descriptor ( # descritor de recepção parcialservice_ids = []),transport_stream_information_descriptor ( # descritor de de informação do transportstreamremote_control_key_id = remote_controle, # teclado de acesso ao canalts_name = "RT-DSP", #nome de meu transport streamtransmission_type_loop = [transmission_type_loop_item(transmission_type_info = 0x0F,service_id_loop = [


service_id_loop_item(service_id = servicio_id, # ID de serviço),]),transmission_type_loop_item(transmission_type_info = 0xAF,service_id_loop = [],),],)],),],version_number = 0, # numero da versão da tabela NITsection_number = 0,last_section_number = 0,)

Data Description

terrestrial_delivery_system_descriptor Define as propiedades da modulaçãotais como frequências de transmissão

system_management_descriptorDefine as propiedades tais como indi-cação que é sistema ISDB-T e que estásendo transmitido agora.

partial_reception_descriptor Define a lista de serviços de recepçãoparcial

transport_stream_information_descriptor

Define outras propiedades do TransportStream tais como a tecla do controleremoto, nome do TS, informação dostipos de serviços oferecidos, etc

Tabela 22 – Parâmetros da tabela NIT.

Definição dos serviços, tabela SDT

Serve para especificar os serviços disponíveis no TS

sdt = service_description_section(transport_stream_id = teste_ts_id, #numero ID para diferenciar à redeoriginal_network_id = teste_rede_rtdsp, # pega o valor do ID da rede original


service_loop = [service_loop_item(service_ID = servicio_id, #ID de serviço da TV digitalEIT_schedule_flag = 0, # Event Information Table, valor 0 indica que no existe infor-mação do evento atualEIT_present_following_flag = 0,running_status = 4, # o evento está sendo executadofree_CA_mode = 0, # se tem acesso a todos os streamservice_descriptor_loop = [service_descriptor( # descriptor de serviçoservice_type = 0x19, #o serviço é de televisão digitalservice_provider_name = " ", # nome do proveedor de serviçosservice_name = "RT-DSP", # nome do serviço),],),],version_number = 0, # numero da versão da tabela SDTsection_number = 0,last_section_number = 0,)

Definição do mapa de programa, tabela PAT

A tabela PMT define o jeito como e composto cada serviço.

pat = program_association_section(transport_stream_id = tvd_ts_id,program_loop = [program_loop_item(

Programa adicional para tabela NITprogram_number = 0,PID = 16, # PID da tabela NIT),program_loop_item(program_number = teste_ts_id,PID = pid_pmt, #PID da PMT de serviço),


],version_number = 0, #versão da tabela PATsection_number = 0, #indica qual seção foi utilizada para o envio da informaçãolast_section_number = 0, #numero total de seções para enviar)

Definição dos componentes de serviço, tabela PMT

Esta tabela define que tipo de fluxos componem o serviço, são detalhadas qualé o stream de áudio, vídeo, etc que componem o serviço. Também é definido em qual PIDencontra-se o PCR o qual é a marca de relógio do serviço. Nesta tabela definimos quenosso serviço é composto de um stream de vídeo no PID 2066 e um stream de áudio noPID 2069, além disso o PID do PCR é 2066, o mesmo que o PID de vídeo.

pmt_sd = program_map_section(program_number = servicio_id, #PID da PMT de serviçoPCR_PID = 2066, # indica PID do PCR, o mesmo que o PID de vídeo.program_info_descriptor_loop = [],stream_loop = [stream_loop_item(stream_type = 0x1B , # Fluxo de vídeo.elementary_PID = 2066, # PID de vídeo.element_info_descriptor_loop = []),stream_loop_item(stream_type = 0x11, # Stream de áudio AAC.elementary_PID = 2069, # PID de áudio.element_info_descriptor_loop = []),],version_number = 0,section_number = 0,last_section_number = 0,)

Codificação para escrever as tabelas en arquivos

Estos arquivos são parte das fontes necessárias para gerar a multiplexação final


do Transport Stream.

out = open("˙nit.sec", "wb")out.write(nit.pack() )out.close()os.system("sec2ts 16 < ./nit.sec > ./nit.ts")out = open("./pat.sec", "wb")out.write(pat.pack() )out.close()os.system("sec2ts 0 < ./pat.sec > ./pat.ts")out = open("./sdt.sec", "wb")out.write(sdt.pack() )out.close()os.system("sec2ts 17 < ./sdt.sec > ./sdt.ts")out = open("./pmt_sd.sec", "wb")out.write(pmt_sd.pack() )out.close()os.system("sec2ts " + str(tvd_pmt_pid_sd) +" < ./pmt_sd.sec > ./pmt_sd.ts")

Ao incluir a aplicação Ginga, se tem que adicionar alguns parâmetros no ar-quivo tables.py. Para começar, são adicionados os seguintes cabeçalhos

from dvbobjects.MHP.AIT importfrom dvbobjects.MHP.Descriptors import

Na tabela PMT será adicionada a seguinte informação:

stream_loop_item(stream_type = 5, # AIT stream typeelementary_PID = 2001,element_info_descriptor_loop = [data_component_descriptor (data_component_id = 0xA3, # sistema AITadditional_data_component_info = ait_identifier_info(application_type = 9, # GINGA-NCLait_version= 0).bytes(),


),application_signalling_descriptor(application_type = 9, # GINGA-NCLAIT_version1, current ait version),]),stream loop item(stream type = 0x0B, # DSMCC stream typeelementary_PID = 2004, #element_info_descriptor_loop = [association_tag_descriptor(association_tag = 0x0C, #use = 0,selector_lenght = 0,transaction_id = 0x80000000,timeout = 0xFFFFFFFF,private_data = " ",),stream_identifier_descriptor(component_tag = 0x0C,),carousel_identifier_descriptor(carousel_ID = 2,format_ID = 0,private_data = " ",),data_component_descriptor (data_component_id = 0xA0, sistema GINGAadditional_data_component_info = additional_ginga_j_info(transmission_format = 0x2,document_resolution = 0x5,organization_id= 0x0000000A,application_id= 0x0064,carousel_id= 2,


).bytes(),),])],version_number = 0,section_number = 0,last_section_number = 0,)

Anexos

85

ANEXO A – Modulação ISDB-T

Cartão ModuladorPara este projeto foi utilizado o cartão da Dektec DTA-2111 (DEKTEC2111,

2011), é um cartão multi-padrão VHF/UHF e foi selecionado pois suporta o padrão doSistema brasileiro de televisão digital. Algumas de suas principais caracteristicas são:

∙ Suporta os padrões ATSC, DVB-C, DVB-H, DVB-T, QAM-B, QAM-C. Na versãoGOLD, são suportados adicionalmente os padrões ADTB-T, CNMB, ISDBT, entreoutros.

∙ 𝐷𝑖𝑔𝑖𝑡𝑎𝑙 𝑢𝑝𝑐𝑜𝑛𝑣𝑒𝑟𝑠𝑖𝑜𝑛 para uma excelente qualidade de sinal sem necessidade decalibração.

∙ Suporta todas as constelações e modos de modulação para cada padrão suportado.

∙ Opção de simulador de canal digital.

∙ PCI Express v1.1; Label PCIe 1x

∙ Compatível com sistemas operacionais como Windows ou Linux.

StreamXpressPara usar o cartão Dektec DTA-2111 em ambiente Windows, vai ser utilizado o

𝑃𝑙𝑎𝑦𝑜𝑢𝑡 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 DTC-300 StreamXpress (STREAMXPRESS, 2014) e entre suas prin-cipais características estão:

∙ 𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒 𝑑𝑒 𝑝𝑙𝑎𝑦𝑜𝑢𝑡 de baixo custo e alto 𝑝𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 que suporta todos osdispositivos de saída Dektec.

∙ Entorno amigável em relação ao controle dos parâmetros.

∙ É executado em entorno Windows, especificamente em Windows XP, 2k3, Vista,2k8, 7 or Windows 8.

DtPlayPara usar o cartão Dektec DTA-2111 em ambiente Linux, temos que instalar o

software DtPlay, e para fazer a instalação deste software temos que instalar previamente o

ANEXO A. Modulação ISDB-T 86

controlador DTA. Os driver de todos os cartões PCI para Linux estão inclusos no pacoteLinuxSDK que estão disponibilizados na pagina web da Dektec (LINUXSDK, 2014)

Uma vez que o cartão Dektec foi conetado ao PCIe de nosso computar, foirealizada a descompressão do arquivo LinuxSDK.tar.gz descarregado anteriormente, parapoder executar-lo foram executados os seguintes comandos:

𝑠𝑢𝑑𝑜 𝑚𝑎𝑘𝑒

𝑠𝑢𝑑𝑜 𝑚𝑎𝑘𝑒 𝑖𝑛𝑠𝑡𝑎𝑙𝑙

Ao descarregar o software DtPlay da página do Dektec, colamos os arquivosDTAPI.h e DTAPI.o do pacote LinuxSDK ao arquivo do DtPlay e do mesmo jeito exe-cutamos o comando 𝑚𝑎𝑘𝑒. Ao fazer isto é gerado um arquivo executavel o qual pode serexecutado com o comando . /𝐷𝑡𝑃 𝑙𝑎𝑦

Para transmitir o vídeo desde o computador para televisão utilizamos no ter-minal o seguinte comando:

𝐷𝑡𝑃 𝑙𝑎𝑦 𝑛𝑜𝑚𝑒.𝑡𝑠 − 𝑙 0 − 𝑡 2111 − 𝑚 188 − 𝑚𝑡 𝐼𝑆𝐷𝐵𝑇 − 𝑚𝑓 533 − 𝑟 0

87

ANEXO B – Guia de instalação doOpenCaster

Para trabalhar e fazer a instalação do OpenCaster se requer de um ambienteLinux, um compilador C de Gcc e Python. Neste caso utilizamos a versão Python 2.7.3 epara fazer sua instalação executamos o seguinte comando no terminal:

𝑠𝑢𝑑𝑜 𝑎𝑝𝑡 − 𝑔𝑒𝑡 𝑖𝑛𝑠𝑡𝑎𝑙𝑙 𝑝𝑦𝑡ℎ𝑜𝑛2.7.3 − 𝑑𝑒𝑣

Se têm que asegurar que os seguintes pacotes de Linux estejam instalados:𝑏𝑖𝑛𝑢𝑡𝑖𝑙𝑠, 𝑔𝑐𝑐, 𝑙𝑖𝑏𝑐6 − 𝑑𝑒𝑣, 𝑙𝑖𝑏𝑔𝑜𝑚𝑝1, 𝑙𝑖𝑛𝑢𝑥 − 𝑙𝑖𝑏𝑐 − 𝑑𝑒𝑣, 𝑚𝑎𝑘𝑒, 𝑝𝑦𝑡ℎ𝑜𝑛 − 𝑑𝑒𝑣, 𝑧𝑙𝑖𝑏1𝑔 − 𝑑𝑒𝑣

Estes pacotes são necessários para fazer a compilação do OpenCaster, do con-trario vão se apresentar problemas de erros durante a instalação.

Descarregamos o OpenCaster da página ℎ𝑡𝑡𝑝 : //𝑤𝑤𝑤.𝑎𝑣𝑎𝑙𝑝𝑎.𝑐𝑜𝑚/

𝑐𝑑 /ℎ𝑜𝑚𝑒/𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒/𝑂𝑝𝑒𝑛𝐶𝑎𝑠𝑡𝑒𝑟

𝑡𝑎𝑟 𝑧𝑥𝑓 𝑂𝑝𝑒𝑛𝐶𝑎𝑠𝑡𝑒𝑟3.2.2.𝑡𝑔𝑧

São executados os seguintes comandos para a compilação e posterior instalação:

∙ 𝑚𝑎𝑘𝑒

∙ 𝑠𝑢𝑑𝑜 𝑚𝑎𝑘𝑒 𝑖𝑛𝑠𝑡𝑎𝑙𝑙.

Para os testes com H264 e áudio AAC foi necessário adicionar um 𝑐𝑙𝑎𝑠𝑠 𝑑𝑒𝑠𝑐𝑟𝑖𝑝𝑡𝑜𝑟

referente ao AAC.

88

ANEXO C – Emuladores HbbTV

Opera HbbTV EmulatorOpera HbbTV permite visualizar aplicações HbbTV mesmo via HTTP ou

desde a unidade de disco rígido. Para utilizá-lo se tem que descarregar a máquina virtual(VIRTUALBOX, 2007) e o pacote oferecido pelo Opera (OPERA, 1995).

Ao fazer a instalação da máquina virtual, inicializamos o sistema operativo oqual já é o emulador HbbTV. Para poder interagir com o emulador, está disponível umcontrole remoto baseado em 𝑤𝑒𝑏, podemos accesá-lo através de: ℎ𝑡𝑡𝑝 : //𝑙𝑜𝑐𝑎𝑙ℎ𝑜𝑠𝑡 : 5557.

Fire HbbTVPara poder utilizar o Fire HbbTV é necessário descarregar o pacote oferecido

pela Firefox (FIREHBBTV, 2012). Seguidamente se tem que reiniciar o 𝑏𝑟𝑜𝑤𝑠𝑒𝑟, ao fazeristo, vai aparecer um ícone na barra de ferramentas, similar a uma televisão, tal íconetem que ser ativado quando precisemos ver uma aplicação HbbTV.

Para testar as aplicações só temos que colocar o URL da aplicação e seleccionaro ícone.

—

geração de fluxo de transporte aderente ao sistema...

Documents