Roteiro. Módulo IV 3 horas. A arquitetura de um sistema digital de televisão Padrões de Middleware DASE MHP ARIB GINGA

Transcrição

1 Roteiro Módulo I 6 horas. Introdução à Organização; Arquitetura de Computadores; Hardware / Software / etc.; Processador Memória e Entrada / Saída (E/S); Sistema Operacional (SO): Características, Tipos e Funções. Módulo II 2 horas. Modelo OSI e Arquitetura TCP/IP. Endereçamento e Roteamento. Arquiteturas de Redes Dispositivos de Rede; Módulo III 1 hora. Introdução à Internet; Arquitetura Cliente / Servidor e Peer-to-Peer; Endereçamento na Internet e Serviços de Nomes; Protocolos e Serviços Básicos; Fundamentos de Segurança. Módulo IV 3 horas. A arquitetura de um sistema digital de televisão Padrões de Middleware DASE MHP ARIB GINGA 1

2 Avaliação Trabalho Escrito (em grupo de 3 alunos) sobre o tema: Uso da Tecnologia para Melhoria das Atividades já existentes e/ou criação de Novos Serviços / Atividades. 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

10 Evolução dos Microprocessadores Árvore rápida de referência com os principais processadores da Intel e os equivalentes da AMD: 10

11 11

12 12

13 13

14 14

15 15

16 16

17 SO Sistemas Operacionais Cisco IOS Linux (GNU-Linux) MacOS OS/2 Solaris Windows IOS Apple Android Windows Mobile Blackberry Web OS (Palm) Symbian 17

18 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 Computadores Pessoais PC sistema de computação dedicado a um único usuário. Praticidade e bem tempo de resposta. Usa mesma tecnologia desenvolvida para sistemas de grande porte. O uso pessoal não exige sofisticação no gerenciamento da CPU nem em aspectos de proteção. A utilização de PCs por vários usuários em rede, trazem novas necessidades de proteção e segurança. Computadores Pessoais em Rede PC Necessidade de Sistema Operacional adicional (SOR). Sistemas Operacionais de Rede Proporcionam compartilhamento de arquivos Gerenciam a comunicação Operam de forma independente de outros computadores da rede Arquitetura de rede Cliente-Servidor. Permite o funcionamento Peer-to-Peer. Evolução para as estações de trabalho. 26

27 27

28 28

29 29

30 30

31 31

32 32

33 33

34 34

35 Módulo II Modelo OSI e Arquitetura TCP/IP Endereçamento x Roteamento Arquiteturas de Redes Dispositivos de Redes 35

36 36

37 37

38 38

39 39

40 40

41 41

42 42

43 43

44 44

45 45

46 Módulo III Introdução à Internet Arquitetura Cliente / Servidor - Serviço Peer-to-Peer Endereçamento na Internet e Serviços de Nomes Protocolos e Serviços Básicos Fundamentos de Segurança 46

47 47

48 48

49 49

50 50

51 51

52 Módulo IV A arquitetura de um sistema digital de televisão Padrões de Middleware DASE MHP ARIB GINGA 52

53 A Arquitetura de Um Sistema Digital de Televisão Este módulo discute os tipos de Middleware usados para os principais Sistemas de Televisão Digital do mundo. Incluindo os padrões americano, europeu e japonês. As principais características de cada um destes padrões são esclarecidas no decorrer do mesmo. A Arquitetura de Um Sistema Digital de Televisão Similarmente ao modelo OSI em Redes de Computadores, a arquitetura de SDTV também é dividida em camadas. Primeiramente, é feita a captura de vídeo, áudio e dados através de uma câmera ou de um arquivo de streaming. o Este sinal é codificado (camada de middleware) e é feita a compressão dos dados do programa (camada de compressão) para que possam ser transmitidos. Depois da multiplexação dos dados comprimidos em fluxo de transporte (camada de transporte). Este fluxo codificado é adequado (modulação) ao meio de transmissão (camada de modulação). A camada mais baixa do transmissor é a camada de Transmissão, na qual é transmitido o sinal da TV. No receptor: o o o o O sinal da TV deve ser sintonizado (camada de recepção), Demodulado e decodificado em fluxo de transporte (camada de demodulação), O programa em questão deve ser demultiplexado (camada de transporte), Descomprimido (camada de descompressão) e finalmente extraídos pelo Middleware. 53

54 Etapas na Transmissão do Sinal Digital de Televisão Etapas na Recepção do Sinal Digital de Televisão 54

55 Middleware A função do middleware é a de possibilitar que aplicações possam ser escritas de modo mais independente possível do hardware e do sistema operacional, permitindo que uma mesma aplicação possa ser carregada e executada em diferentes equipamentos receptores. É importante ressaltar que acima da camada de middleware, existe a camada de aplicação onde são colocadas as aplicações para TV - Interativa, por exemplo. Além disso, para que possa ser visto em uma TV analógica, deve ser utilizado um SET-TOP BOX que transforma os sinais digitais em sinais específicos para a TV analógica. Padrões de Mídia Os padrões MPEG são usados para codificação e compressão de dados multimídia. O tipo MPEG-1 foi criado para vídeos codificados até 1,5 Mbps com qualidade VHS, e áudio codificado com 192 Kbps por canal. MPEG-2 é baseado em MPEG-1, mas mais otimizado. Ele é capaz de codificar vários vídeos entre 4 e 9 Mbps para TV ou entre 15 e 100 Mbps para HDTV. O padrão MPEG-4 representa conteúdos de mídia na forma de objetos. Com isso, pode ser feita tanto no servidor quanto no transmissor, a manipulação dos dados, removendo ou inserindo objetos. Além disso, cada padrão de televisão digital deve ter o seu tipo de codificação do sinal de áudio. O Dolby AC-3 é utilizado no ATSC, O MPEG-1 e MPEG-2 são utilizados no DVB O MPEG-2 AAC é utilizado no ISDB. 55

56 Camada de Transporte e Modulação A camada de transporte é que faz a multiplexação dos dados. Nesta camada é feito o agrupamento de áudio, vídeo e dados em um único fluxo MPEG- TS (Transport Stream) numa mesma base de tempo. Como são utilizados pequenos pacotes para encapsular os fluxos, torna-se fácil a resincronização de um vídeo para o caso de ocorrerem perdas de pacote no MPEG-TS. Os padrões de modulação utilizados hoje em dia são: COFDM (Coded Orthogonal Frequency Division Multiplexing) pelo ISDB (padrão japonês) e pelo DVB (padrão europeu). O padrão americano (ATSC) utiliza 8-VSB (8 L-Vestigial Side Band Modulation) para modular o sinal. Padrões de Middleware As aplicações de TV Digital (DTV) podem ser divididas em aplicações procedurais e aplicações declarativas. As linguagens procedurais são baseadas em módulos, orientadas a objetos. o Numa programação procedural, devemos informar ao computador cada passo a ser executado. o O programador possui, assim, um maior poder sobre o código, sendo capaz de estabelecer todo o fluxo de controle e execução de seu programa. Nas linguagens declarativas, existe um nível maior de abstração, usualmente ligadas a um domínio ou objetivo específico. o O programador fornece apenas o conjunto das tarefas a serem realizadas, não estando preocupado com os detalhes de como o executor da linguagem (interpretador ou compilador) realmente implementará essas tarefas. 56

57 Aplicações Aplicações para TV Digital, principalmente com enfoque interativo são chamados de Xlets. São similares a Applets em Java, mas não são iguais. Xlets são aplicações desenvolvidas em Java TV que é uma API que estende a plataforma Java. Desenvolvida pela Sun Microsystems para prover acesso e funcionalidades num receptor de televisão digital. A Sun Microsystems fornece um emulador para simular uma TV Digital em um desktop, chamado XletView. Este é baseado no middleware MHP e é Open Source. Desta forma, as aplicações (Xlets) desenvolvidas podem ser testadas de forma rápida e fácil. Para implementar um Xlet, devem ser implementados um número pequeno de métodos que controlam o ciclo de vida do mesmo. DASE (1) O middleware DASE ou DTV Application Software Enviroment é utilizado no padrão de TV Digital Norte-Americano ATSC. Este middleware permite que serviços interativos sejam executados normalmente por qualquer receptor. O padrão DASE é um esforço do Advanced Television System Committee (ATSC) que permite aos criadores de conteúdo aperfeiçoado e interativo as especificações necessárias para que os aplicativos e dados executem uniformemente em todos os modelos e marcas de receptores. Uma aplicação DASE é um conjunto de informações que são processadas por um ambiente de aplicação para fornecer interatividade com o usuário final ou alterar o estado do ambiente da aplicação. O conteúdo da aplicação pode ser de natureza declarativa ou procedural. 57

58 DASE (2) As aplicações declarativas tem como objetivo, principal, a apresentação de dados de forma estática. Fazem uso de várias tecnologias web, como linguagens baseadas em tags, XHTML, CSS (Cascading Style Sheets) e DOM (Document Object Model), fluxos de áudio e vídeo. Já os aplicativos procedurais são aqueles que incluem algum processamento lógico. Sendo implementados através de código escrito na linguagem de programação Java. Sendo assim, este tipo de aplicação é capaz de processar tarefas mais complexas dinamicamente. Existe ainda uma categoria de aplicações híbridas, que permite uma mistura de conteúdo de aplicativos tanto declarativos como procedurais. O ambiente de aplicativos DASE fornece browser para conteúdo de aplicações declarativas e uma Máquina Virtual Java. Este tipo de middleware não especifica a implementação de um set-top box específico. MHP (1) O padrão MHP é o middleware usado no padrão de TV Digital Europeu DVB. O padrão MHP consiste de uma combinação de suportes à broadcast e à Internet, oferecendo uma API acessível a todos que desejam desenvolver aplicações, receptores e aparelhos de TV. Perfis: No perfil Enhanced, não é oferecido suporte a canal de retorno e conexão IP. o Executa as aplicações via difusão (broadcast). No perfil Interactive suporta a um canal de retorno e conexão IP, permitindo assim a possibilidade de interatividade remota. No perfil Internet Access, suporta aplicações web, além de aplicações desenvolvidas em Java. o Este último perfil só foi disponibilizado na versão MHP 1.1. Todos os perfis possuem suporte a aplicações interativas desenvolvidas com a DVB-J que representa um conjunto de funções de alto nível, estruturas de dados e protocolos que representam uma interface padrão para o desenvolvimento de software independente de plataforma de hardware. 58

59 MHP (2) Diferentemente do MHP 1.0, o MHP 1.1 permite a possibilidade de armazenar localmente aplicações e plug-ins recebidos por difusão, além do acréscimo da DVB- HTML API - interface de programação de aplicações baseadas em HTML. Existem dois tipos de aplicações suportadas pelo padrão MHP: DVB-HTML (apresentada através de conteúdo hipermídia); DVB-J (representadas através de conteúdo compilado na linguagem Java). O MPH é dividido em três camadas: recursos (hardware embutidos), Software (aplicações) e interface das aplicações (interoperabilidade). Camadas do MHP Na camada de recursos estão incluídos os recursos de hardware embutidos na televisão ou set-top-box. Recursos disponíveis incluem hardware de decodificação MPEG, dispositivos de entrada e saída de dados, CPU, memória e sistemas de geração de imagem. Na camada de software, as aplicações não acessam diretamente os recursos de hardware. Traz uma visão abstrata dos recursos disponíveis. Este isolamento entre hardware e software cria portabilidade. Esta camada também inclui um gerenciador de aplicações, que é responsável por controlar o ciclo de vida das aplicações. Na camada de Interface das Aplicações, é mantida a interoperabilidade das diversas aplicações MHP desenvolvidas, utilizando principalmente a DVB-J API, aplicações estas orientadas a objeto e baseadas na linguagem de programação Java. 59

60 ARIB O padrão de middleware ARIB (Association of Radio Industries and Business) é utilizado no padrão Japonês ISDB. Áudio, vídeo e todos os serviços de dados são multiplexados e transmitidos via broadcasting de rádio, em um TS (Transport Stream) especificado pelo MPEG-2. Canais para a interatividade das comunicações são disponibilizados através dos canais interativos da rede. O sistema de transmissão de dados que utiliza o armazenamento dos pacotes como um fluxo de pacotes no PES (Packetized Elementary Stream) é usado para aplicações em tempo real, que necessitam de sincronização na decodificação e reprodução dos diferentes tipos de mídia. A estrutura lógica do display ARIB é composta, respectivamente, de plano de vídeo, plano de figura, plano de controle, plano de gráficos e textos e plano de legendas. Também existe o sistema de transmissão de dados, no qual os dados serão transmitidos inúmeras vezes - este serviço é especificado como carrossel de dados. Outra facilidade proporcionada pelo ARIB é que ele permite adicionar EPG (Electronic Program Guide), índice e funções de gravação automática para melhorar a seleção da programação, facilitando assim a programação pessoal do usuário. Estrutura do Modelo ARIB 60

61 GINGA Primeiro padrão de middleware opensource da camada de software intermediário desenvolvido no Brasil com o intuito de prover funções de interatividade para TV Digital Padrão é divido em Ginga-NCL e Ginga-J: o o Ginga-NCL - é uma infra-estrutura de apresentação para aplicações declarativas escritas na linguagem Nested Context Language (NCL). NCL é uma aplicação XML com facilidades para a especificação de aspectos de interatividade e sincronismo espaço-temporal entre objetos de mídia. Ginga-J é a infra-estrutura de apresentação para aplicações procedurais (Java Xlet). E é através desta que pode ser implementada aplicações de maior complexidade que provê a interação com o usuário. Existe uma ponte entres os módulos Ginga-NCL e Ginga-J que é disponibilizado pela arquitetura Ginga. Também existe o módulo Common Core que é a camada de software que dá suporte para os outros módulos através de uma série de codecs e procedimentos para obter dados do MPEG-TS ou do canal de retorno que permite a possibilidade de interatividade. GINGA NCL (1) O Ginga-NCL é o primeiro padrão a ser aprovado e recomendado pela União Internacional de Telecomunicações (UIT) para aplicações interativas em IPTV. A Recomendação H.761 (Nested Context Language (NCL) and Ginga-NCL for IPTV services) foi aprovada pelo Setor de Normalização da UIT (UIT-T). O módulo NCL é padrão J.201 desde O subsistema lógico Ginga- NCL é composto por uma série de módulos. O mais importante módulo é o NCL Formatter, já que este é responsável por receber um documento NCL e controlar a sua apresentação, tentando garantir que relacionamentos entre objetos de mídia sejam respeitados. 61

62 GINGA NCL (2) Os documentos NCL são providos por uma estrutura chamada private base que corresponde um canal de TV. A partir da linguagem NCL, os objetos envolvidos são descritos e a sincronização entre eles é obtida, especificando o espaço temporal dos mesmos. Os objetos são descritos em documentos NCL que por sua vez são executados pelo Formatador NCL. Os tipos de objetos suportados depende diretamente do NCL player embutido no Formatador NCL. Um destes players é o decoder/player implementado em hardware pelo receptor. GINGA NCL Módulo LUA Outros módulos do Ginga-NCL merecem destaque. O XHTML-based user agent é composto por um interpretador stylesheet (CSS) e um interpretador ECMAScript. O módulo LUA engine é responsável por interpretar scripts LUA. o LUA é uma linguagem de programação leve e poderosa, projetada para estender aplicações. o Seus scripts são acoplados a programas maiores que precisam ler e executar programas escritos pelos usuários. 62

63 GINGA J (1) Ginga-J provê uma infraestrutura de execução de aplicações JAVA e extensões especificamente voltadas ao ambiente de TV. Dentre as camadas que compõem a arquitetura Ginga-J, merece destaque a de aplicações. Composta por APIs (Interfaces de Programação de Aplicativos) projetadas para suprir todas as funcionalidades necessárias para a implementação de aplicativos para televisão digital, desde a manipulação de dados multimídia até protocolos de acesso. A norma Ginga-J é destinada aos desenvolvedores de receptores compatíveis com o Sistema Brasileiro de Televisão Digital Terrestre (SBTVD) e aos desenvolvedores de aplicativos que utilizam a funcionalidade e API Ginga. Embora exista uma norma detalhando o Ginga-J, ela não pôde ser levada a cabo por questões relacionadas a licenças das APIs envolvidas(gem, ARIB, HAvi, etc). GINGA J (2) A arquitetura Ginga-J é composta de cinco camadas: Hardware, Sistema Operacional, Implementação Ginga e Java Virtual Machine (JVM), API Ginga-J e Xlets. Open Ginga - Forma a oferecer as APIS definidas nas especificações Ginga-J e GingaNCL através da união da Implementação de Referência Ginga-J sob responsabilidade do Laboratório de Aplicações de Vídeo Digital (LAVID) da Universidade Federal da Paraíba (UFPB) e a Implementação de Referência Ginga- NCL sob responsabilidade do Laboratório Telemídia da PUC-Rio. As outras parte da arquitetura Ginga são reconhecidas como padrão J.200 e o Ginga-J como padrão J

64 64

65 65