Lucas Correia Villa Real

Uma Arquitetura para An alise de Fluxo de Dados Estruturados Aplicada ao Sistema Brasileiro de TV Digital

Disserta ca o

apresentada

` a

Escola

Polit ecnica da Universidade de S ao Paulo para obten c ao do T tulo de Mestre em Engenharia El etrica.

S ao Paulo 2009

Lucas Correia Villa Real

Uma Arquitetura para An alise de Fluxo de Dados Estruturados Aplicada ao Sistema Brasileiro de TV Digital

Disserta ca o

apresentada

` a

Escola

Polit ecnica da Universidade de S ao Paulo para obten c ao do T tulo de Mestre em Engenharia El etrica. Area de concentra ca o: Sistemas Eletr onicos Orientador: Prof. Dr. Marcelo Kn orich Zuo

S ao Paulo 2009

Ficha Catalogr aca

Real, Lucas Correia Villa Uma Arquitetura para An alise de Fluxo de Dados Estruturados Aplicada ao Sistema Brasileiro de TV Digital. Ed. Rev. S ao Paulo, 2009. 95 p. Disserta c ao (Mestrado) Escola Polit ecnica da Universidade de S ao Paulo. Departamento de Engenharia de Sistemas Eletr onicos. 1. Sistemas multim dia 2. Televis ao digital 3. An alise de dados 4. Tipos abstratos de dados 5. Apresenta c ao de informa c ao I.Universidade de S ao Paulo. Escola Polit ecnica. Departamento de Engenharia de Sistemas Eletr onicos. II.t.

Dedicat oria
Esse trabalho e dedicado em sua plenitude aos meus pais, por todo o apoio e carinho recebido, fundamentais para a realiza c ao dessa disserta c ao.

The revolution will not be televised (Gil Scott-Heron)

Agradecimentos
Antes do esfor co e dedica ca o demandados para a elabora ca o desta disserta c ao de mestrado veio uma incans avel jornada de aprendizado, incentivada e apoiada incondicionalmente desde meus primeiros passos como pessoa. Agrade co e dedico essa disserta ca o ` aqueles que tornaram isto poss vel: meus pais. Reservo o primeiro par agrafo tamb em ` a minha irm a, por quem tenho a maior admira ca o, e ` a Priscilla, que emprestou-me sua fam lia, seu ombro e seu amor sempre que necess ario. Algumas pessoas marcaram essa trajet oria em momentos de muita import ancia. Gostaria de agradecer aos amigos e mentores Mois es de Souza, Gerson Cavalheiro e Mark Smith por instigarem meu esp rito de pesquisa. Tamb em agrade co ao Hisham Muhammad e ao Andr e Detsch pelos incont aveis dias e madrugadas de discuss ao produtiva acerca de t opicos diversos de computa ca o e m usica. A m usica certamente ajudou. Muito obrigado a todos do laborat orio de TV digital do LSI, em especial aos colegas Rog erio Nunes, Rafael Herrero, C elio Hira, Marcelo Biase, Fl avio Alves, Alfredo Marua e Hilel Becher, que ofereceram sua experi encia prossional e pessoal durante o per odo agitado de proposta, concep ca o e reda ca o deste trabalho. Agrade co tamb em ao meu orientador Marcelo Zuo por sua ajuda e aten c ao nos momentos em que foram solicitadas. Finalmente, gostaria de agradecer a todos os amigos e familiares que estiveram presentes e ajudaram-me de uma maneira ou outra durante esse per odo de dedica ca o exclusiva.

Resumo
Diversos sistemas computacionais transmitem informa ca o em uxos cont nuos de dados estruturados e, por vezes, hierarquizados. Este modelo de transmiss ao de dados tem como uma de suas caracter sticas a grande densidade de informa ca o, o que exige de um receptor o tratamento imediato das unidades extra das deste canal de comunica ca o. Muitas vezes o volume de transmiss ao n ao permite que a informa ca o recebida seja armazenada permanentemente no receptor, o que torna a an alise do conte udo desses uxos de dados um desao. Este trabalho apresenta uma arquitetura para a an alise de uxo de dados estruturados aplicado ` a hierarquia l ogica denida pelo Sistema Brasileiro de TV Digital para a transmiss ao de programas de televis ao, validada por meio de uma implementa c ao de refer encia completamente funcional.

Abstract
Various computing systems transfer data in structured data streams which also happen to be, sometimes, hierarchically organized. Such data stream model is characterized by the dense amount of information transmitted, which requires the receiver to immediately manipulate the elements extracted from that communication channel. The high rate in which data ows also makes it hard, if not impossible, for the receiver to store the desired information in its memory, which makes data ow analysis especially challenging. This work presents a novel structured data ow analysis architecture applied to the logical hierarchy dened by the Brazilian Digital TV System for the transmission of television programs, validated by means of a fully functional reference implementation.

Lista de Figuras
2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 Fluxo de Dados de Entrada . . . . . . . . . . . . . . . . . . . . . Fluxo de Dados de Entrada e Sa da . . . . . . . . . . . . . . . . . Amostragem com o algoritmo Min-Wise . . . . . . . . . . . . . . Exemplo de gera ca o de uma sinopse . . . . . . . . . . . . . . . . . Atualiza ca o de um elemento no algoritmo de Count-Min . . . . . Estrutura de Dados Hierarquizada de um Pacote TCP/IP . . . . 24 25 27 28 29 30

Banco de Dados Hierarquizado no Sistema de Arquivos no MUMPS 31 Arquitetura de recep ca o e decodica c ao sincronizada de TV digital 38 Estrutura de um pacote de uxo de dados do MPEG-2. (Os campos de bits s ao representados com o bit mais signicativo ` a direita.) 39

3.3 3.4 3.5

Rela c ao entre as tabelas de informa ca o de servi co NIT, PMT e PAT 41 Encapsulamento de v deo, audio e dados no uxo de transporte . Exemplo de estrutura de diret orios transmitida em um carrossel de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 44 47 49 42

3.6 3.7 4.1 6.1 6.2 6.3 6.4 6.5 6.6 6.7

Composi c ao de uma mensagem BIOP . . . . . . . . . . . . . . . . Aplicativo StreamXpert, da Dektec . . . . . . . . . . . . . . . . . A arquitetura de um analisador de uxo de dados proposta . . . .

Fluxo de uma chamada de sistema a um sistema de arquivos FUSE 67 A plataforma de TV digital Tall . . . . . . . . . . . . . . . . . . . Diagrama de blocos do DemuxFS . . . . . . . . . . . . . . . . . . O uxo de um pacote no DemuxFS . . . . . . . . . . . . . . . . . Os diret orios /Reports e /Streams expandidos . . . . . . . . . . O segundo n vel hier arquico do DemuxFS . . . . . . . . . . . . . . O subdiret orio Programs da tabela PAT . . . . . . . . . . . . . . 68 71 72 74 75 76

6.8 6.9

A composi ca o da tabela PMT no DemuxFS . . . . . . . . . . . . A descri c ao de uxos elementares de audio e v deo na PMT . . .

77 78

6.10 Formata ca o de um arquivo conforme indicado em seu atributo estendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11 Alinhamento dos arquivos FIFO com o cabe calho de pacotes PES 6.12 Representa c ao de data e hora no DemuxFS . . . . . . . . . . . . . 6.13 Tabelas DII e DDB, com expans ao do sistema de arquivos do DSMCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.14 Tabela DDB, sem expans ao do sistema de arquivos do DSM-CC . 81 82 79 80 80

Lista de Tabelas
2.1 Exemplo de valores para e e os valores resultantes de n e d. . . 28

Lista de Abreviaturas
AIT Application Information Table (Tabela de Informa c ao da Aplica c ao) ANSI American National Standards Institute (Instituto Nacional Americano de Padroniza c ao) API Application Programming Interface (Interface de Programa c ao de Aplicativos) ARM Advanced RISC Machines (M aquinas RISC Avan cadas) ASCII American Standard Code for Information Interchange (Padr ao Americano Para o Interc ambio de Informa c oes) ATSC Advanced Television Systems Committee (Comit e de Sistemas Avan cados de Televis ao) BIOP Broadcast Inter-ORB Protocol (Protocolo de Transmiss ao Inter-ORB) CRC Cyclic Redundancy Check (Verica c ao de Redund ancia C clica) DDB Download Data Block (Bloco de Dados de Download ) DII Download Information Indication (Indica ca o de Informa ca o de Download ) DVB Digital Video Broadcasting (Transmiss ao de V deo Digital) DSM-CC Digital Storage Media Command and Control (Comandos e Controles de Armazenamento de M dias Digitais) EPG Electronic Program Guide (Guia Eletr onico de Programa ca o) ES Elementary Stream (Fluxo Elementar) FAT File Allocation Table (Tablea de Aloca ca o de Arquivos) FIFO First In, First Out (Primeiro a Entrar, Primeiro a Sair) FUSE File System in User Space (Sistema de Arquivos em Espa co de Usu ario) HDTV High Denition Television (Televis ao de Alta Deni c ao)

 HE-AAC High-Eciency Advanced Audio Coding (Codica ca o de Audio Avan cada de Alta Eci encia) IEC International Electrotechnical Commission (Comiss ao Eletrot ecnica Internacional) IGMP Internet Group Management Protocol (Protocolo de Gerenciamento de Grupos na Internet) IP Internet Protocol (Protocolo de Internet) ISDB Integrated Services Digital Broadcasting (Transmiss ao Digital de Servi cos Integrados) ISO International Organization for Standardization (Organiza ca o Internacional de Padroniza co es) MPEG Moving Picture Expert Group (Grupo de Especialistas em Imagens em Movimento) MUMPS Massachusetts General Hospital Utility Multi-Programming System (Sistema de multiprograma ca o do Hospital Geral de Massachusetts) NIT Network Information Table (Tabela de Informa ca o de Rede) SO Sistema Operacional PAT Program Allocation Table (Tabela de Aloca ca o de Programa) PC Personal Computer (Computador Pessoal) PCR Program Clock Reference (Rel ogio de Refer encia do Programa) PES Packetized Elementary Stream (Fluxo Elementar Empacotado) PID Packet Identication (Identicador do Pacote) POSIX Portable Operating System Interface (Interface de Sistema Operacional Port avel) PMT Program Map Table (Tabela de Mapeamento de Programa) ProcFS Process File System (Sistema de Arquivos de Processos) PSI Program Specic Information (Informa ca o Espec ca de Programa) RAM Random Access Unit (Unidade de Acesso Aleat orio)

RTSP Real Time Streaming Protocol (Protocolo de Fluxo de Dados em Tempo Real) SBTVD Sistema Brasileiro de TV Digital SDT Service Description Table (Tabela de Descri ca o de Servi co) SDTV Simple Denition Television (Televis ao de Deni ca o Simples) SGML Standard Generalized Markup Language (Linguagem Padr ao de Formata c ao Generalizada) SI Service Information (Servi co de Informa c ao) SQL Structured Query Language (Linguagem de Consulta Estruturada) TCP Transfer Control Protocol (Protocolo de Controle de Transfer encia) TOT Time Oset Table (Tabela de Deslocamento de Hor ario) TS Transport Stream (Fluxo de Transporte) VFS Virtual File System (Sistema de Arquivos Virtual) XML Extensible Markup Language (Linguagem Extens vel de Formata c ao)

Sum ario

1 Introdu c ao 1.1 1.2 1.3 1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribui co es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organiza c ao do texto . . . . . . . . . . . . . . . . . . . . . . . . .

18 19 20 21 21

2 O Estado-da-Arte nos Mecanismos de An alise de Fluxo de Dados Estruturados 2.1 2.2 Modelos de Fluxo de Dados . . . . . . . . . . . . . . . . . . . . . T ecnicas de Amostragem e de Recupera ca o da Informa ca o . . . . 2.2.1 2.2.2 2.2.3 2.3 O Algoritmo Reservoir . . . . . . . . . . . . . . . . . . . . O Algoritmo Min-Wise . . . . . . . . . . . . . . . . . . . . A T ecnica de Sinopses . . . . . . . . . . . . . . . . . . . . 23 24 25 25 26 27 29 30 32 34 36 37 37 38 39 45

Representa ca o de Dados Estruturados . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.3.3 A Linguagem de Programa c ao MUMPS . . . . . . . . . . . Sistemas de Arquivos Especiais . . . . . . . . . . . . . . . Objetos Textuais em XML . . . . . . . . . . . . . . . . . .

2.4

S ntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Sistemas de TV Digital 3.1 TV Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.2 A Arquitetura de Transmiss ao e Recep ca o de TV Digital . O Fluxo de Transporte do MPEG-2 . . . . . . . . . . . . .

Elementos de An alise em um Fluxo de Transporte de TV Digital .

3.3

S ntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4 Uma Arquitetura para An alise de Fluxo de Dados Estruturados 49 4.1 4.2 Requisitos do Modelo de An alise de Fluxo de Dados Estruturados Deni c ao do Modelo de Exposi c ao de Elementos Estruturados em Sistemas de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 4.3 Canais de Comunica ca o Unidirecionais Entre Processos . . Mecanismos de Atributos . . . . . . . . . . . . . . . . . . . Liga c oes Simb olicas no Sistema de Arquivos . . . . . . . . 52 53 54 55 55 50

S ntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Aplica c ao da Arquitetura Proposta no Sistema Brasileiro de TV Digital 5.1 Um Sistema de Arquivos para An alise do Fluxo de Transporte . . 5.1.1 5.1.2 5.1.3 O Uso de arquivos FIFO . . . . . . . . . . . . . . . . . . . A Aplica ca o de Atributos Estendidos . . . . . . . . . . . . A Organiza c ao de Vers oes e Depend encias com Liga co es Simb olicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 S ntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 62 64 64 65 67 69 70 72 73 74 82 57 58 59 60

6 A Implementa c ao de Refer encia DemuxFS 6.1 Considera c oes de Implementa ca o . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.2 6.3 Sistemas de Arquivos em Espa co de Usu ario . . . . . . . . A Plataforma de TV Digital Tall . . . . . . . . . . . . . .

Requisitos Computacionais . . . . . . . . . . . . . . . . . . . . . . A Arquitetura de An alise de Fluxo de Dados do DemuxFS . . . . 6.3.1 6.3.2 6.3.3 6.3.4 A sem antica e o uso dos arquivos FIFO . . . . . . . . . . . Pr evias do Fluxo de V deo . . . . . . . . . . . . . . . . . . Organiza c ao da Estrutura de Diret orios . . . . . . . . . . . Medidas M etricas para An alise Quantitativas . . . . . . .

6.4

S ntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83 84 84 85

7 Conclus oes 7.1 7.2 Contribui co es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . .

Anexos
A B Atributos Estendidos em Sistemas de Arquivos Legados Disponibilidade do C odigo Fonte do DemuxFS

87
87 90 91

Refer encias Bibliogr acas

18

Introdu c ao

Em sistemas computacionais a transmiss ao de dados por meio de uxos cont nuos e estruturados e utilizada em diversas areas da computa ca o, como no tr afego de pacotes IP em redes de computadores, na transmiss ao de imagens entre um decodicador especializado e um controlador de v deo ou ainda em aplica c oes nanceiras, como em estat sticas da bolsa de valores. A produ ca o do conte udo contido nesses uxos ocorre muitas vezes em tempo real sendo que sua transmiss ao costuma se dar de forma imediata. Com isso, cabe ao receptor interpretar as estruturas de dados em tempo h abil para que elas sejam processadas e, eventualmente, descartadas de seu espa co de armazenamento nito. Este cen ario torna especialmente dif cil a tarefa de aplicativos de an alise de dados, visto que em muitos casos n ao h a espa co f sico para armazenar toda a informa ca o tratada. Al em disso, t ecnicas tradicionais de an alise de programas de computador, como mensagens de rastro ou aplicativos de monitoramento e controle de outros programas, n ao podem ser escalados na mesma propor ca o em que o volume de dados recebidos aumenta. Com isso, outras metodologias se fazem necess arias para que estes dados sejam apresentados ao usu ario de maneira descomplicada. Algumas t ecnicas para lidar com grandes volumes de dados estruturados s ao sugeridas na literatura, como o uso de amostragens e do agrupamento dos elementos recebidos de acordo com algumas caracter sticas estabelecidas (CORMODE, 2007). A amostragem de elementos tamb em faz-se necess aria quando n ao existe um crit erio para a sele ca o dos dados de entrada que ser ao armazenados; assim, diversos algoritmos s ao empregados para determinar quando um elemento do uxo de entrada deve ser analisado e armazenado pelo receptor. O modelo de transmiss ao de dados estruturados e adotado tamb em em sistemas de TV digital, nos quais o envio dos quadros de v deo, audio e outros elementos e feito constantemente, de modo unidirecional, por um produtor de

1.1 Objetivos

19

conte udo. No entanto, uma caracter stica do protocolo de transporte adotado nesses sistemas restringe a an alise do seu conte udo a um subconjunto nito de elementos: os elementos que comp oem as tabelas de informa c ao de programas de TV digital s ao transmitidos repetidamente e, no cabe calho de cada um, a sua vers ao e informada. Assim, o analisador do protocolo pode desconsiderar elementos cujas vers oes j a tenham sido lidas, reduzindo o tempo de processamento e o espa co de armazenamento necess arios para a sua opera ca o.

1.1

Objetivos

Este trabalho tem como objetivo principal investigar e propor uma arquitetura para a an alise de uxo de dados estruturados, especicamente aplicada ao Sistema Brasileiro de TV Digital (SBTVD). Esta arquitetura permite que dados organizados conforme uma rela c ao hier arquica sejam exibidos com diferentes n veis de detalhe, de acordo com a necessidade do usu ario. Para garantir a portabilidade do formato no qual os dados analisados s ao armazenados, um modelo j a consolidado que ofere ca exibilidade em m ultiplas plataformas e utilizado. A arquitetura proposta e aplicada ao modelo de transmiss ao de dados adotado pelo SBTVD, em vigor desde Novembro de 2007. Este estudo permitiu a elabora ca o de um ambiente funcional para a identica c ao e an alise dos v arios elementos estruturados transmitidos no SBTVD, que foi validado em uma plataforma PC e em um terminal de acesso de TV digital de baixo custo. Para a elabora c ao deste trabalho, foram estudadas diferentes t ecnicas de an alise de dados, como as tradicionalmente utilizadas para a inspe ca o de estruturas de processos em execu ca o em um computador e t ecnicas especializadas em extra ca o de informa ca o oriunda de grandes volumes de dados. Este estudo engloba tamb em diferentes modelos de representa c ao de dados que permitem ao usu ario um acesso direto e simples a grandes volumes de informa ca o. Para a aplica ca o da proposta ao SBTVD, foram tomados como base trabalhos de multiplexa c ao de conte udo em TV digital e as normas brasileiras de informa co es de servi co, que detalham os formatos dos elementos transmitidos no uxo de transporte recebido pelos terminais de acesso de TV digital. O estudo de metodologias de an alise se estendeu tamb em a patentes nesta area, que descrevem com detalhes os mecanismos adotados por produtos comerciais encontrados no mercado.

1.2 Metodologia

20

1.2

Metodologia

O trabalho pode ser subdividido em seis etapas principais: (1) pesquisa sobre sistemas de an alise de uxo de dados estruturados; (2) estudo de modelos para armazenamento e representa ca o de grandes volumes de dados estruturados; (3) proposta de uma arquitetura para a an alise de uxo deste tipo de dados; (4) aplica ca o desta arquitetura ao formato de dados transmitido no Sistema Brasileiro de TV Digital; (5) especica c ao e implementa ca o de um analisador de uxo de dados estruturados para o Sistema Brasileiro de TV Digital; (6) avalia ca o do modelo proposto e implementado. A primeira etapa consiste em uma an alise do estado-da-arte e de mecanismos que buscam resolver o problema de monitoramento de uxo de dados estruturados. S ao introduzidas t ecnicas fundamentais usadas para resumir a informa c ao contida nestes uxos, como a amostragem, o agrupamento de amostras e o uso de estruturas compactas, que revelam estat sticas de determinados elementos. Na segunda etapa s ao analisados modelos de armazenamento e representa c ao de dados estruturados. Conceitos de banco de dados e de sistemas de arquivos s ao revisados, bem como formatos de arquivos ex veis e padronizados que permitam o armazenamento de dados estruturados e hierarquizados. A proposta de uma arquitetura para a an alise de uxo de dados hier arquico e ent ao apresentada. S ao levados em considera ca o os fundamentos revisados na primeira e segunda etapas, que d ao respaldo para a deni ca o de um mecanismo port avel e multiplataforma. Na quarta etapa, a arquitetura proposta e aplicada ao protocolo de dados presente no Sistema Brasileiro de TV Digital (SBTVD). S ao introduzidos conceitos relevantes para a compreens ao de como um terminal de acesso de TV digital determina quais s ao os elementos que comp oem um programa enviado por uma emissora e de como essa informa ca o e expressa na arquitetura de forma a ressaltar as informa co es desej aveis em uma an alise. A quinta etapa apresenta a especica c ao de um analisador de uxo de dados estruturados aplicado ao SBTVD e aspectos de sua implementa ca o em uma arquitetura PC e em um terminal de acesso de TV digital. A sexta e u ltima etapa e composta por uma an alise da aplica c ao do modelo aos protocolos do SBTVD e por avalia c oes gerais do modelo proposto, ressaltando suas caracter sticas e aspectos que permitam a cria ca o de trabalhos que derivem deste.

1.3 Contribui c oes

21

1.3

Contribui co es

A an alise de elementos em uxos de dados cont nuos requer o uso de t ecnicas espec cas. Diversos trabalhos neste segmento denem mecanismos de amostragem de uxos de dados que oferecem uma vis ao consistente do conjunto de dados de entrada. Entretanto, mesmo se tratando de uma amostragem, um grande volume de dados ainda precisa ser agrupado de forma que possa ser avaliado pelo usu ario. Este trabalho busca contribuir com a deni ca o de uma arquitetura simples, por em expressiva, para a an alise de uxos de dados estruturados quaisquer. A solu ca o apresentada permite a avalia c ao dos elementos capturados em diferentes ambientes computacionais, possibilitando tamb em express a-los com diferentes n veis de detalhamento. Em sua aplica ca o ao Sistema Brasileiro de TV Digital, a contribui ca o deste trabalho est a na gera c ao de uma ferramenta pr atica que possa ser utilizada em laborat orio e que sirva de refer encia para pesquisadores da area de TV digital.

1.4

Organiza c ao do texto

Este texto est a estruturado em 7 cap tulos. O Cap tulo 2 introduz o conceito de uxo de dados, apresenta t ecnicas de amostragem de elementos contidos nesses uxos e discute os principais modelos de exposi c ao e representa ca o de dados estruturados. O Cap tulo 3 apresenta conceitos de televis ao digital e do formato do uxo de dados utilizado nesse meio. S ao tamb em identicados os elementos de an alise desse uxo, baseados em caracter sticas encontradas em analisadores comerciais e em pesquisas aplicadas a este t opico. No Cap tulo 4, uma arquitetura gen erica para a an alise de uxo de dados estruturados e proposta, compreendendo m etodos para a exposi c ao de elementos, o acesso a dados e metadados deste uxo, a representa c ao de depend encias, a comunica c ao com m odulos espec cos da arquitetura e o acesso direto ao uxo de transporte ou a segmentos dele. A maneira na qual essa arquitetura se aplica ao SBTVD e explicada no Cap tulo 5. O Cap tulo 6 introduz o sistema implementado para a valida c ao dessa proposta. Esse cap tulo e formado por 3 se co es que consistem em considera c oes

1.4 Organiza c ao do texto

22

de implementa c ao, m etodos para limitar o uso de recursos computacionais e na aplica ca o pr atica das propostas conceituais feitas at e ent ao. Finalmente, o Cap tulo 7 apresenta as conclus oes nais deste trabalho e poss veis trabalhos futuros que possam ser desenvolvidos com base nessa proposta.

23

O Estado-da-Arte nos Mecanismos de An alise de Fluxo de Dados Estruturados

Em sistemas computacionais, e comum o uso de um modelo de transmiss ao de dados cont nuo, denominado uxo de dados. Nele, a quantidade de informa c ao carregada e t ao grande que se torna impratic avel a um receptor armazen a-la em sua plenitude. Cabe ao receptor, assim, extrair os dados na mesma taxa em que eles s ao transmitidos, de forma a evitar a perda de informa c ao. Esse modelo e utilizado em diversas areas da computa ca o, como no tr afego de pacotes IP em uma rede de computadores, na transmiss ao de m usica por uma r adio digital, no envio de estat sticas de aplica c oes nanceiras na bolsa de valores, entre muitos outros (CRANOR et al., 2003). Os elementos encapsulados e transmitidos em um uxo s ao geralmente estruturados, ou seja, apresentam uma organiza ca o l ogica que exp oe diversos atributos de cada elemento, constituindo, assim, unidades de informa ca o. Cabe ao receptor extrair os dados de cada unidade e utiliz a-los da maneira que lhe for mais adequada. A natureza de transmiss ao cont nua e o grande volume de dados produzido torna a tarefa de an alise das unidades de informa c ao especialmente desaadora. Os recursos para armazenamento dispon veis em um analisador s ao menores do que o volume dos dados de entrada, o que requer o uso de t ecnicas especiais para resumir ao usu ario informa co es relevantes quanto aos elementos encapsulados no uxo (CORMODE, 2007). Este cap tulo apresenta os modelos de uxo de dados e t ecnicas de an alise e armazenamento de grandes volumes de informa c ao.

2.1 Modelos de Fluxo de Dados

24

2.1

Modelos de Fluxo de Dados

Fluxos de dados podem ser descritos por dois modelos: uxos de entrada e uxos de entrada e sa da. Em ambos, cada unidade do uxo e descrita por uma tupla em que o primeiro elemento representa um identicador e o segundo um valor associado, como um peso, um contador ou um conjunto de bytes. Dados estes elementos, e poss vel representar um uxo de dados como um vetor, indexado pelos identicadores de cada tupla e armazenando valores que indicam a quantidade de vezes que aquele identicador j a foi encontrado desde o in cio do reconhecimento do conte udo de entrada (MUTHUKRISHNAN, 2005). Um vetor ilustrativo e mostrado na Figura 2.1, em uma situa ca o hipot etica em que cada um dos 4 identicadores indexados foi encontrado 2, 3, 4 e 2 vezes, respectivamente.

Figura 2.1: Fluxo de Dados de Entrada

O que difere um uxo de entrada de um uxo de entrada e sa da e que neste u ltimo existe a possibilidade de se substituir elementos j a adicionados ao vetor. Esta opera ca o se d a com a subtra c ao do valor previamente armazenado na posi c ao indexada pelo identicador do elemento lido e a inser c ao de um novo elemento na mesma posi ca o. O modelo de entrada e sa da pode ser aplicado a um sistema em que, por exemplo, os elementos carregados no uxo contenham um campo que dena a vers ao da informa c ao trazida. Nesse caso, sempre que uma vers ao diferir daquela j a armazenada no vetor e que o sistema substituir o conte udo associado ` aquele elemento, uma opera ca o de sa da ser a efetuada. Esse modelo e ilustrado e o tempo t = 11 cont em um campo de na Figura 2.2: todos os elementos lidos at vers ao com valor 1. Na chegada de um elemento de vers ao 2 no tempo t = 12, o conte udo do vetor que o indexa e descartado, dando lugar ` a nova informa ca o e reiniciando o contador de ocorr encias privado (MUTHUKRISHNAN, 2003).

2.2 T ecnicas de Amostragem e de Recupera c ao da Informa c ao

25

Figura 2.2: Fluxo de Dados de Entrada e Sa da

2.2

T ecnicas de Amostragem e de Recupera c ao da Informa c ao

Para lidar com o grande volume de informa ca o presente em um uxo de dados, muitas vezes se faz necess ario utilizar t ecnicas de amostragem, a m de limitar a quantidade de mem oria utilizada pelos algoritmos e de reduzir a carga computacional exigida pela execu ca o destes. Diversas classes de algoritmos foram propostas para resolver esse problema, como os algoritmos de Reservoir e Min-Wise, que denem m etodos para escolher uniformemente os elementos do uxo de dados que ser ao armazenados. Outra t ecnica desenvolvida foi a de Sinopse, que consiste em armazenar um resumo incremental dos elementos lidos. As solu co es encontradas por estes algoritmos e os aspectos de cada um s ao apresentadas nas subse c oes a seguir.

2.2.1

O Algoritmo Reservoir

Proposto por Vitter (1985), o algoritmo Reservoir, literalmente traduzido como Reservat orio, consiste na escolha de um universo de amostras de tamanho m, com base no qual uma amostra aleat oria de tamanho m pode ser gerada. O valor de m e tipicamente escolhido de acordo com as restri co es de mem oria e de processamento do receptor do uxo de dados.

2.2 T ecnicas de Amostragem e de Recupera c ao da Informa c ao

26

O primeiro passo do algoritmo consiste na inser c ao dos primeiros m elementos lidos no reservat orio. A partir deste ponto, o restante dos elementos e processado sequencialmente, e a chance de cada um deles fazer parte do reservat orio (retirando, assim, algum elemento previamente selecionado) e denida por uma fun ca o de probabilidade (HANKERSON; JOHNSON; HARRIS, 2003). A probabilidade de que o item i (sendo que i m + 1) seja escolhido e de at e o momento. A probabilidade de que um elemento qualquer do reservat orio seja removido na eventualidade do novo candidato ter sido selecionado para inser c ao e a probabilidade do elemento i ser selecionado multiplicado pela probabilidade do elemento que j a est a no reservat orio ser escolhido aleatoriamente para dar lugar ao elemento i. Assim, a probabilidade de que um elemento qualquer seja removido e de
m i m , i

uma raz ao

entre o tamanho m aximo do reservat orio e o n umero de elementos encontrados

1 m

=1 , e a probabilidade de que ele continue no conjunto de amostras e i

igual a 1 1 . i Durante a recep c ao do uxo de dados, diversas substitui c oes s ao realizadas, alternando os elementos conforme uma probabilidade uniforme para que a amostra nal seja composta por elementos escolhidos aleatoriamente. Dessa forma, a probabilidade de que um elemento i se encontre na amostragem nal e denida pela probabilidade de i ser amostrado quando ele for encontrado, multiplicada pela probabilidade de que ele sobreviva at e o m, sem ser retirado do reservat orio por outro elemento. Para um reservat orio de tamanho m = 1, a Equa ca o 2.1 mostra a probabilidade de i fazer parte da amostragem nal. 1 i (i + 1) (n 2) (n 1) 1 = i (i + 1) (i + 2) (n 1) n n

(2.1)

2.2.2

O Algoritmo Min-Wise

O algoritmo Min-Wise oferece uma solu c ao simples para a escolha de elementos para amostragem. Para cada item do conjunto de entrada, associa-se um valor aleat orio entre 0 e 1, e ent ao escolhem-se os itens com os menores valores para amostragem. Como cada item tem a mesma probabilidade de receber um valor aleat orio m nimo, este algoritmo tem uma caracter stica de amostragem uniforme. A Figura 2.3 ilustra uma amostragem segundo este algoritmo, em um cen ario com 4 diferentes tipos de elementos. Outra caracter stica do Min-Wise e que, por n ao existir interdepend encia

2.2 T ecnicas de Amostragem e de Recupera c ao da Informa c ao

27

Figura 2.3: Amostragem com o algoritmo Min-Wise

entre os elementos na escolha de um candidato ` a amostragem, ele permite que diferentes segmentos do uxo de entrada sejam processados por unidades independentes de processamento; cada uma destas unidades gera um resultado e, ao t ermino, estes resultados s ao combinados e fornecidos para um u ltimo passo do algoritmo (BRODER et al., 2000).

2.2.3

A T ecnica de Sinopses

Enquanto os algoritmos de amostragem trabalham com a aquisi c ao de elementos aleat orios do uxo de entrada, uma outra classe de algoritmos pode processar todos os elementos recebidos. Ainda assim, as estruturas de dados nas quais os elementos s ao representados constituem meramente um sum ario deles, ou uma sinopse. Por esse motivo, praticamente nenhuma fun c ao que precise ser computada em um elemento armazenado no vetor pode ser feita com precis ao (DIMITROPOULOS et al., 2008). A Figura 2.4 apresenta este conceito por meio de

uma fun ca o geradora de sinopses que consiste na multiplica c ao de uma matriz de proje c ao sobre cada elemento do vetor . O algoritmo de Count-Min e uma variante deste conceito apresentada por Cormode e Muthukrishnan (2004). Ele considera um vetor , de dimens ao n, onde cada ndice armazena um contador que indica o n umero de vezes que um determinado elemento foi encontrado no uxo de dados. O estado do vetor no tempo t e denido por (t) = [1 (t), . . . , i (t), . . . , n (t)]. Para cada elemento i (t) em (t), o seu estado inicial e i (0) = 0. A sinopse de i e atualizada sempre que uma nova ocorr encia deste elemento ocorrer no vetor . Neste caso, o valor previamente armazenado e modicado conforme o valor de entrada. Denindo este conceito formalmente, a atualiza c ao de i no tempo t

2.2 T ecnicas de Amostragem e de Recupera c ao da Informa c ao

28

Figura 2.4: Exemplo de gera ca o de uma sinopse

e denida pela tupla (it , ct ), de forma que it (t) = it (t 1) + ct e que i (t) = i (t 1), i = it . (2.3) (2.2)

A posi c ao em em que um elemento ser a inserido e denida por uma fun ca o hash h(i) escolhida arbitrariamente. Como podem ocorrer colis oes, o algoritmo Count-Min utiliza, ao inv es de um u nico vetor, uma matriz de tamanho n e profundidade d, sendo que cada uma das linhas de 1..d e coordenada por uma fun c ao hash diferente, igualmente selecionada de forma arbitr aria durante a inicializa ca o do algoritmo. Os valores de n e d s ao denidos conforme dois par ametros e , que denem a precis ao esperada e a probabilidade com que se deseja que esta precis ao seja alcan cada, respectivamente. Assim, n e calculado conforme a fun ca o teto as dimens oes da tabela para algumas combina c oes de vari aveis. Tabela 2.1: Exemplo de valores para e e os valores resultantes de n e d. 0.1 0.1 0.1 0.01 0.01 0.01 0.1 0.01 0.001 0.1 0.01 0.001 n d 28 3 28 5 28 7 272 3 272 5 272 7 nd 84 140 196 816 1360 1904
e

(onde e e a base do logaritmo natural) e d por ln( 1 ) . A Tabela 2.1 apresenta

2.3 Representa c ao de Dados Estruturados

29

A inser c ao e as subsequentes atualiza co es de um elemento i na matriz s ao feitas em cada uma das linhas d da matriz, nas colunas indicadas pelo resultado das fun co es hash de cada uma delas. Cada um dos ndices retornados pelas fun c oes e incrementado em 1, indicando que uma nova ocorr encia daquele elemento ocorreu, conforme mostra a Figura 2.5. A opera ca o de consulta de um elemento e feita por meio das mesmas fun co es hash. Ele e buscado em cada uma das linhas da matriz, e o menor valor encontrado e retornado como resultado da consulta.

Figura 2.5: Atualiza ca o de um elemento no algoritmo de Count-Min

2.3

Representa c ao de Dados Estruturados

Para que os elementos de um uxo de dados capturados possam ser analisados pelo usu ario e necess ario que eles estejam, primeiramente, armazenados em estruturas de dados que permitam a sua representa ca o efetiva. Naturalmente, a estrutura de dados escolhida est a diretamente relacionada ao conte udo de cada elemento: a representa c ao de uma sequ encia de notas musicais e provavelmente diferente da sequ encia de pacotes TCP em uma rede de computadores. Enquanto o primeiro pode ser representado por simples elementos escalares, o u ltimo requer o uso de registros mais complexos que representem os diversos atributos que o comp oem, como os endere cos de origem e de destino, o tamanho do pacote, informa co es de integridade e a carga u til do pacote. Nesse caso, diz-se que os dados s ao estruturados. Dependendo da rela ca o entre os atributos de um dado estruturado, a estrutura de dados que o representa pode ainda ser hierarquizada, tal como em uma arvore geneal ogica ou em uma estrutura organizacional. O atributo de maior inu encia e representado no topo da hierarquia (sua raiz ), seguido de diversos descendentes conforme os elos l ogicos entre os atributos.

2.3 Representa c ao de Dados Estruturados

30

A Figura 2.6 mostra como uma hierarquia pode ser organizada para representar um segmento de dados encapsulado em pacotes IP e TCP em uma rede de computadores. N ao casualmente a gura se assemelha a uma estrutura de dados em arvore; cada atributo pode ser intuitivamente mapeado a um nodo e a rela ca o entre os atributos pode ser feita por meio de liga co es entre os nodos e seus descendentes e ancestrais diretos.

Figura 2.6: Estrutura de Dados Hierarquizada de um Pacote TCP/IP

Diversas t ecnicas de representa ca o de dados estruturados hierarquizados em arvore foram propostas nos u ltimos anos. Algumas dessas s ao apresentadas a seguir, como a adotada no sistema de arquivos de suporte ` a linguagem de programa ca o MUMPS, em sistemas de arquivos especiais e em documentos XML.

2.3.1

A Linguagem de Programa c ao MUMPS

MUMPS e uma linguagem de programa ca o interpretada desenvolvida na d ecada de 60 no laborat orio de animais do Massachussets General Hospital nos Estados Unidos e padronizada pelo instituto ANSI em 1977 (LEWKOWICZ, 1989). Sintaticamente, MUMPS lida com um u nico tipo de dados, as strings, que podem abrigar at e 255 caracteres. Semanticamente, entretanto, a linguagem permite dados de tipos num ericos e vetores multidimensionais, convertidos automaticamente para strings por meio de rotinas internas da linguagem. 2.3.1.1 O Banco de Dados Hier arquico em Sistema de Arquivos de MUMPS

Um dos aspectos mais interessantes da linguagem MUMPS e a sua integra ca o nativa com um banco de dados (n ao relacional) hier arquico no sistema de arquivos. Este banco de dados e usado pela linguagem para armazenar persistentemente os valores de vari aveis especiais denominadas globais, prexadas pelo caracter ,

2.3 Representa c ao de Dados Estruturados

31

ap os a execu ca o de um programa. Tais vari aveis s ao vis veis e modic aveis tanto pelo programa que as criou quanto por outros programas em execu ca o, o que faz deste o mecanismo de intercomunica ca o entre processos em ambientes MUMPS. A declara ca o de vari aveis em MUMPS admite tanto a deni ca o de valores simples quanto hier arquicos, conforme o exemplo na Listagem 2.1: Listagem 2.1: Declara ca o de uma vari avel global em MUMPS SET i d e n t i f i c a d o r = 2112 SET p a c o t e (PMT, Vers a o ) = 2 SET versaoPMT = p a c o t e (PMT, Vers ao ) Na primeira linha do exemplo e denida uma vari avel denominada identificador. Essa vari avel e armazenada no n vel superior da hierarquia do sistema de arquivos integrado ao MUMPS, em um arquivo denominado identificador. O conte udo desse arquivo e a string 2112. A segunda linha do exemplo atribui o valor 2 ` a tupla (P M T, V ersa o) da vari avel pacote. Na terceira linha, o conte udo dessa tupla e armazenado na vari avel local versaoPMT. A vari avel global pacote (linha 2 da Listagem 2.1) e representada no sistema de arquivos por uma hierarquia em arvore, na qual a raiz e dada por um arquivo que leva o mesmo nome da vari avel global, pacote. A raiz da arvore cont em o descendente direto indexado pelo valor da vari avel PMT e o descendente indireto indexado pela vari avel Vers ao que receber a a string 2 atribu da no programa. Os descendentes da raiz, no entanto, n ao s ao armazenados em objetos distintos no sistema de arquivos. Cada n vel na hierarquia, com exce ca o da raiz, e representado por uma lista de blocos encadeados composta por segmentos e ponteiros para deslocamentos dentro do arquivo que leva o nome do nodo raiz.

Figura 2.7: Banco de Dados Hierarquizado no Sistema de Arquivos no MUMPS

2.3 Representa c ao de Dados Estruturados

32

Um bloco em MUMPS pode assumir um tamanho de 128 a 512 bytes. Tais blocos s ao compostos por estruturas denominadas segmentos, que representam os diversos nodos de uma hierarquia em arvore. Um segmento e composto por um campo inteiro para indexa ca o, uma area de dados de tamanho vari avel de at e 255 bytes e um ponteiro para a sub arvore de seu descendente, caso haja um. Os segmentos apresentam ainda um cabe calho com dois campos, utilizados para indicar o tamanho total do segmento e apontar o deslocamento no arquivo onde o pr oximo segmento de mesmo n vel est a armazenado (WEIDERHOLD, 1987). O armazenamento em disco de uma vari avel global no MUMPS e mostrado pela estrutura de dados em arvore na Figura 2.7. Nela, os segmentos utilizados para denir os nodos PMT, PAT e NIT s ao indexados pelos valores 1, 2 e 3, respectivamente, sendo todos eles armazenados em um mesmo bloco. O banco de dados de MUMPS organiza nodos de um mesmo n vel em um u nico bloco de tamanho xo para otimizar o acesso ao disco, evitando a movimenta ca o excessiva das suas cabe cas de leitura. Nota-se ainda na Figura 2.7 que cada descendente dos segmentos do primeiro n vel cont em um u nico nodo, Vers~ ao, indexado pelo valor 4. Novamente, todos os segmentos deste n vel da hierarquia s ao armazenados em um mesmo bloco de dados. No u ltimo n vel hier arquico encontram-se nalmente os nodos folha, que cont em os valores das n-uplas percorridas.

2.3.2

Sistemas de Arquivos Especiais

Sistemas de arquivos especiais permitem que dados armazenados em m dias vol ateis sejam acessados por meio da interface tradicional de sistemas de arquivos (WEINBERGER, 1984).

O primeiro sistema de arquivos especial criado denomina-se

ProcFS e e explicado a seguir. O sistema de arquivos Proc (ProcFS) surgiu da necessidade de um mecanismo eciente para a depura ca o de processos em execu c ao em sistemas operacionais oria UNIX. Proposto por Killian (1984), a ideia consiste em expor o mapa de mem de processos em execu ca o para que aplicativos especializados possam acess a-los para ler e modicar os estados internos e controlar a execu ca o dos programas. Em sua concep c ao original, o mapa de mem oria de um processo era representado por um u nico arquivo segmentado, cuja cria ca o, remo ca o e controle de acesso eram gerenciados por um sistema de arquivos especial. Dessa forma, os dados expostos por meio dele n ao se encontravam sicamente armazenados em uma m dia n ao-vol atil, mas em mem oria RAM.

2.3 Representa c ao de Dados Estruturados

33

A concep c ao do ProcFS foi adotada por diversos sistemas operacionais, cada qual o estendeu para permitir a descri c ao de outros atributos privados do n ucleo de execu ca o. Alguns dos sistemas operacionais que implementaram o ProcFS incluem o IRIX (SGI, 1996), o Plan 9 (PIKE et al., 1990), o Solaris (MCDOUGALL;
MAURO, 2007) e o Linux (BENVENUTI, 2005).

A representa ca o dos processos em execu ca o deixou de ser feita por meio de um u nico arquivo por processo a partir da vers ao 2.6 do Solaris, um sistema operacional desenvolvido pela Sun Microsystems. Nele, as informa co es referentes ao mapa de mem oria de um processo em execu c ao passaram a ser estruturadas e disponibilizadas como diversos arquivos dentro de uma hierarquia de diret orio espec ca para aquele processo. Essa hierarquia inclui tamb em subdiret orios com arquivos de controle para cada processo leve (thread ) criado a partir do processo principal, permitindo a inspe c ao detalhada de seus atributos espec cos. A exibilidade oferecida pela exposi ca o de metadados de processos por meio de um sistema de arquivos e explorada tamb em na implementa c ao do ProcFS no Plan 9, um sistema operacional desenvolvido pelo Bell Labs. Nele, e poss vel acessar a estrutura de diret orios ProcFS de um computador remoto e depurar, a dist ancia, um processo em execu ca o no outro computador (PIKE et al., 1992). 2.3.2.1 Aspectos de Implementa c ao

Para tornar poss vel a exposi ca o de metadados de processos como arquivos e necess ario que o sistema operacional mantenha as informa co es referentes aos processos em estruturas que possam ser acessadas ecientemente. A especica c ao dos arquivos que ir ao compor um diret orio virtual e geralmente feita por meio de uma interface de programa ca o (API) que permita o cadastro de uma vari avel, do nome que a representar a no sistema de arquivos e de um conjunto de fun c oes que ir ao tratar requisi c oes de leitura, escrita e de envios de comandos sobre o arquivo. Finalmente, faz-se necess ario integrar as rotinas de cria ca o e destrui c ao de processos com o sistema de arquivos de forma que ele represente corretamente o estado atual dos processos em execu c ao no computador (SINGH, 2006). No caso do ProcFS, os arquivos exportados para a arvore virtual n ao exp oem apenas o conte udo de determinados atributos de um processo; eles permitem tamb em que o processo seja controlado e depurado por um outro programa situa ca o esta que pode exigir a interfer encia de outros subsistemas do n ucleo de execu ca o. A exemplo da implementa c ao original do ProcFS na 8a Edi c ao do UNIX, a depend encia de outros subsistemas e bastante grande:

2.3 Representa c ao de Dados Estruturados

34

Quando uma opera ca o de controle sobre um arquivo no ProcFS e detectada pelo sistema de pagina c ao1 , o processo que ser a controlado e marcado como um potencial candidato a ter seus dados movidos para a mem oria secund aria: na eventual falta de espa co livre na mem oria principal, um processo em depura ca o tem menor prioridade na ocupa ca o da mem oria em rela c ao aos demais; A cada solicita c ao de leitura de estado de vari aveis ou de incremento no passo de execu c ao do programa, o sistema de pagina ca o recupera os dados solicitados que podem se encontrar na mem oria secund aria e os disponibiliza na mem oria principal; A cada opera ca o de controle feita sobre o arquivo, o escalonador do n ucleo de execu ca o alterna o processo em depura c ao entre as listas de tarefas aptas a executar e de tarefas em espera para execu ca o. Nota-se, entretanto, que uma integra c ao semelhante a essa tamb em seria necess aria caso um outro mecanismo que n ao o de arquivos fosse usado para permitir o controle de um processo por outro. Essa integra ca o mostra, no entanto, que a exposi ca o de estruturas de dados privadas de um sistema operacional ou de uma aplica ca o espec ca pode requerer a coordena c ao de diversos componentes para garantir a eci encia no uso dos recursos computacionais providos no ambiente.

2.3.3

Objetos Textuais em XML

A eXtensible Markup Language (XML) e uma especica ca o de prop osito geral para a cria ca o de linguagens de marca ca o, que consiste em um conjunto de s mbolos e palavras que descrevem trechos de um documento. A especica c ao do XML foi feita pelo Cons orcio W3 (W3C, 1994) em 1996 que tinha, entre os seus objetivos principais, a cria ca o de um formato de representa ca o de dados que fosse facilmente compreendido quando lido diretamente por pessoas e que pudesse ser adotado amplamente na Internet. Sua especica c ao foi feita a partir de um subconjunto da linguagem SGML (ISO, 1996), de forma que um documento XML e tamb em um documento SGML v alido. Um documento XML e composto sicamente por unidades denominadas entidades, que s ao representadas por uma raiz que pode referenciar outras entidades, e assim sucessivamente. Logicamente, os elementos de um documento XML s ao
O sistema de pagina c ao e respons avel por movimentar segmentos de dados entre a mem oria principal e uma mem oria secund aria
1

2.3 Representa c ao de Dados Estruturados

35

descritos entre dois marcadores balanceados que delimitam o seu in cio e m. Cada elemento cont em um tipo, e identicado por um nome e pode ter um conjunto de atributos no formato (nome, valor). A estrutura de um objeto em XML e, dessa forma, descrita por uma s erie de elementos, cada qual podendo descrever outros elementos em uma hierarquia em arvore. O exemplo ilustrado anteriormente na Figura 2.7 pode ser descrito em XML em uma constru ca o similar ` a indicada na Listagem 2.2. Para possibilitar a realiza ca o de consulta a nodos, valores e atributos, que podem ser representados em formatos textuais ou bin arios, a hierarquia em arvore denida no documento deve ser reconstru da. Essa tarefa e realizada por um processador XML, geralmente encapsulado na forma de uma biblioteca de fun co es para que aplica co es possam compartilhar objetos segundo esse formato ou integrado a linguagens de programa c ao especializadas (KAMINA; TAMAI, 2002). Listagem 2.2: Declara c ao de um objeto em XML < pacote > <PMT > <Vers a o >2</Vers ao> </PMT > <PAT > <Vers a o >1</Vers ao> </PAT > <NIT> <Vers a o >7</Vers ao> </NIT> </pacote > Por tornar poss vel a descri ca o de estruturas ricas e complexas, o formato XML e especialmente importante para o armazenamento de estruturas de dados em disco. A especica ca o do formato OpenDocument (ODF), padronizado pela organiza ca o ISO/IEC (ISO/IEC, 2006), adota o XML para esse m, utilizando-o como base para a declara ca o de documentos de processamento de texto, planilhas, bancos de dados orientados a objetos, apresenta co es, gr acos e de equa co es matem aticas.

2.4 S ntese

36

2.4

S ntese

Fluxos de dados s ao empregados por diversos sistemas computacionais em modelos de transmiss ao de dados cont nuos, potencialmente innitos. Esse tipo de transmiss ao torna especialmente dif cil a tarefa de an alise dos elementos trafegados em tais uxos, visto que o espa co de armazenamento de um receptor e geralmente limitado. Dessa forma, a an alise de uxos de dados requer o uso de t ecnicas que amostrem ou sintetizem o conte udo dos elementos nele trafegados. A representa c ao de elementos estruturados transmitidos nos uxos de dados pode ser feita por meio de estruturas em arvore, e a sua exposi ca o pode ser feita de diferentes maneiras para o usu ario. Tr es t ecnicas de exposi c ao de informa c oes estruturadas foram apresentadas nesse cap tulo bancos de dados hierarquizados, sistemas de arquivos especiais e documentos textuais estruturados , nas quais aspectos importantes quanto ` a portabilidade e acesso ` a informa ca o podem ser observados. A estrutura de diret orios no sistema de arquivos Proc permite o acesso a metadados de processos de maneira simples e bem conhecida entre usu arios de computadores: a estrutura de dados e o pr oprio sistema de arquivos. Nenhuma aplica ca o especial e necess aria para acessar a informa ca o contida em um arquivo. A organiza ca o l ogica com delimitadores balanceados em arquivos textuais adotada por documentos XML permite a declara ca o de hierarquias complexas que podem ser lidas e criadas tanto diretamente pelos usu arios quanto por processadores XML, ainda que possam gerar documentos longos e de dif cil leitura; o formato de descri c ao de elementos em um documento XML, entretanto, permite sua portabilidade entre diferentes sistemas computacionais. Embora os atributos de um elemento estruturado n ao estejam completamente expostos no banco de dados integrado ` a linguagem de programa c ao MUMPS, eles podem ser consultados por meio de uma abstra c ao da linguagem. O formato do arquivo gravado em disco, no entanto, requer o uso de uma aplica ca o especializada para reconstituir a hierarquia e pode ainda impedir a reconstru c ao dos dados caso um arquivo esteja parcialmente corrompido. Esses aspectos ser ao retomados no pr oximo cap tulo, na deni c ao de um mecanismo de uma arquitetura para an alise de uxo de dados estruturados, que e um caso especial de uxo de dados na qual a an alise de seus dados estruturados requer o uso de t ecnicas de exposi ca o de informa ca o ecientes.

37

Sistemas de TV Digital

Este cap tulo apresenta os conceitos de TV digital aplicados neste trabalho. A sua organiza c ao e feita em duas grandes partes que compreendem, primeiramente, as caracter sticas fundamentais de um sistema de TV digital e, em seguida, o conceito de uxo de transporte, que identica a rela c ao dos dados trafegados por meio dele com elementos estruturados hierarquizados.

3.1

TV Digital

A televis ao e ainda hoje um dos meios mais importantes de comunica c ao. Por muito tempo, a informa ca o foi transmitida pelas emissoras e recebida pelos telespectadores apenas por meio de canais e tecnologias anal ogicas, que apresentavam muitas vezes uma alta taxa de ru do e erros. Estes problemas eram facilmente observados com a exibi c ao de imagens com baixa nitidez e uma m a qualidade de audio e de legendas (YAMADA et al., 2004). O sistema de TV digital surgiu para corrigir estes problemas fundamentais. Todavia, ele traz n ao apenas uma melhoria signicativa na qualidade do sinal de audio e v deo, mas tamb em a possibilidade de interoperabilidade com outras tecnologias digitais e a intera ca o com o telespectador. Estas melhorias foram poss veis gra cas aos novos m etodos de modula ca o, que denem processos nos quais o sinal original e codicado para ser enviado pelo meio f sico. Tal processo de modula c ao permite a identica ca o e a corre ca o de erros, possibilitando uma recep ca o livre de interfer encias audiovisuais. Al em disso, as tecnologias empregadas no sistema de TV digital utilizam meios de compress ao de dados, de forma a aproveitar melhor o espectro de transmiss ao reservado para as emissoras e ainda assim apresentando um conte udo de audio e v deo com maior deni c ao. Tais meios de compress ao incluem o uso de formatos como o denido na norma do MPEG-2 (ISO, 1996) e do H.264 (ITU-T, 2007), usados para a transmiss ao de conte udos em deni ca o simples (SDTV) e

3.1 TV Digital

38

alta (HDTV), respectivamente. Em um espectro de 6 MHz, utilizado hoje para a transmiss ao de um u nico canal de TV anal ogico, o uso desses meios de compress ao permitem que uma emissora transmita at e quatro programas em deni c ao simples ou dois em alta deni ca o (CARVALHO, 2008).

3.1.1

A Arquitetura de Transmiss ao e Recep c ao de TV Digital

Um cen ario de transmiss ao de TV digital e composto por duas entidades: um transmissor e um receptor, representado por um terminal de acesso que permite a apresenta ca o dos programas emitidos pelo primeiro. Cabe ao transmissor codicar os sinais de audio e v deo produzidos em est udio com os algoritmos de compress ao estipulados pelo sistema de TV digital vigente. Desse processo resultam uxos elementares de audio e v deo devidamente combinados de forma que sua reprodu ca o pelo receptor seja s ncrona. Podem ainda ser somados a esses uxos elementos como legendas, programas interativos e metadados diversos, igualmente sincronizados (caso necess ario) com um rel ogio de sistema. Esses uxos s ao ent ao multiplexados em pacotes de tamanho xo, propriamente identicados por meio de tabelas de informa ca o de servi co, que indicam ao receptor como recompor esses elementos. O processo de multiplexa c ao resulta em um uxo de transporte que e modulado e transmitido por meio de radiodifus ao para os diversos receptores (PEREIRA et al., 2005).

Figura 3.1: Arquitetura de recep ca o e decodica ca o sincronizada de TV digital

Na arquitetura do receptor, o sinal transmitido e recebido por um sintonizadordemodulador, tamb em chamado Front End. Esse componente e respons avel pela sintonia, redu ca o de ru dos, demodula ca o e recomposi ca o do sinal recebido na

3.1 TV Digital

39

antena, que e entregue para o sistema digital de demultiplexa c ao na forma de um uxo de transporte (BEDICKS JR, 2008). Conforme a indica c ao das tabelas de informa ca o de servi co, um aplicativo residente no terminal de acesso determina os uxos de audio e v deo que ser ao enviados aos decodicadores e, com base nas estampas de tempo presentes no uxo, apresentados ao usu ario. Essa arquitetura e contemplada na Figura 3.1.

3.1.2

O Fluxo de Transporte do MPEG-2

O uxo de transporte e um protocolo de transmiss ao de dados denido pela norma ITU-T H.220.0 para o padr ao MPEG-2 (ISO, 1996). Projetado para permitir o transporte de conte udo de v deo, audio e dados sincronizados, o uxo de transporte do MPEG-2 foi adotado como meio de encapsulamento de dados nos padr oes de TV digital ISDB (ARIB, 2008), DVB (ETSI, 1997), ATSC (ATSC, 2007) e SBTVD (ABNT, 2008a), vigentes no Jap ao, Europa, Am erica do Norte e Brasil, respectivamente. A composi c ao do uxo de transporte e feita por pacotes consecutivos de 188 bytes denominados TS (do ingl es Transport Stream ), cada qual abrigando um segmento dos uxos elementares de audio, v deo, dados ou de tabelas de informa ca o de servi co estas u ltimas denidas pelo MPEG-2 e estendidas pelo padr ao de TV digital espec co. Para indicar o seu conte udo, um cabe calho ocupa os primeiros 4 bytes de cada pacote, que inclui um byte de sincronismo (0x47), o n umero identicador do pacote (PID), sinaliza c ao de erro e sua prioridade, entre outros. O cabe calho do pacote pode ainda ser sucedido por um campo de tamanho vari avel denominado campo de adapta ca o que, caso seja transmitido, ocupa parte dos 188 bytes reservados ` a carga u til (CHERNOCK et al., 2001). Essa estrutura e mostrada na Figura 3.2.

Figura 3.2: Estrutura de um pacote de uxo de dados do MPEG-2. (Os campos de bits s ao representados com o bit mais signicativo ` a direita.)

3.1 TV Digital

40

3.1.2.1

Tabelas de Informa c ao de Servi co

As tabelas de informa c ao de servi co denidas no MPEG-2 s ao obtidas a partir do n umero identicador dos pacotes (PID) e processadas pelo software residente no terminal de acesso para recuperar o nome da emissora e a programa c ao contida no uxo de transporte. A transmiss ao dessas tabelas ocorre de maneira c clica, em uma taxa determinada pela norma de TV digital. Dessa forma, um terminal de acesso rec em ligado n ao requer muito tempo de espera para identicar o conte udo e iniciar a apresenta ca o da programa ca o. Entre as tabelas de informa ca o denidas no MPEG-2, tr es s ao de uso mandat orio no Sistema Brasileiro de TV Digital (ABNT, 2007a): 1. Tabela de Informa c ao de Rede (NIT): cont em o nome da emissora, o c odigo de area que dene a regi ao na qual a transmiss ao se destina e os d gitos no controle remoto que devem acessar o seu servi co principal, entre outros; 2. Tabela de Mapeamento de Programas (PMT): indica o PID dos pacotes que carregam os uxos elementares de audio e v deo que comp oem um programa, al em do PID dos pacotes que descrevem o tempo de decodica c ao e apresenta ca o destes. Um programa pode ser composto por mais de um canal de audio e v deo, possibilitando sua reprodu c ao em diversas l nguas e angulos. Um uxo de transporte que transmita dois programas apresenta duas tabelas PMT para descrever os PIDs que comp oem cada um deles; 3. Tabela de Associa ca o de Programas (PAT): indica o PID das tabelas PMT que cont em programas habilitados para reprodu ca o e o PID da tabela de informa c ao de rede (NIT). A tabela PAT tem um n umero de identica ca o xo (0x00), o que torna poss vel a reconstru c ao de toda a arvore de programa c ao a partir de um pacote desse tipo. O relacionamento entre essas tabelas pode ser observado na Figura 3.3. Nela, a tabela PAT indica que o uxo de transporte e composto por uma tabela NIT, de PID 0x10, e por dois programas, de PIDs 0x21 e 0x22, cada qual descrevendo os identicadores dos pacotes de audio, v deo e de sincronismo (PCR) que o comp oem. O programa de PID 0x22, embora presente no uxo de dados, n ao foi habilitado pelo transmissor para sua exibi ca o logo n ao deve ser processado, tampouco considerado para decodica c ao, pelo terminal de acesso. Nota-se tamb em na Figura 3.3 a exist encia de dois campos denominados table id e version, ambos presentes na carga u til de cada pacote. O primeiro

3.1 TV Digital

41

Figura 3.3: Rela ca o entre as tabelas de informa ca o de servi co NIT, PMT e PAT

e usado para identicar o tipo de tabela trazida no pacote. Esse campo se faz necess ario tendo em vista que apenas alguns tipos de tabela t em seu PID xado pela norma. O segundo campo indica a vers ao da tabela transmitida. Ele e incrementado sempre que houver uma atualiza ca o no conte udo de uma tabela, situa ca o essa que ir a requerer uma nova interpreta ca o de seu conte udo por parte do terminal de acesso. Um exemplo t pico de atualiza ca o de vers ao ocorre na troca de programa c ao de uma emissora, que passa a transmitir uma nova composi ca o de elementos de audio e v deo com PIDs diferentes do programa anterior. Al em das tabelas PMT, PAT e NIT, diversas outras tabelas de informa ca o de servi co s ao compreendidas no SBTVD. Em comum, todas cont em um cabe calho com membros que indicam a vers ao da tabela, seu tamanho e seu identicador, entre outros. Algumas dessas tabelas apresentam, tamb em, um conjunto opcional ou mandat orio de descritores, que trazem informa c oes adicionais como a codica ca o do audio e v deo, restri c oes parentais, logotipo da emissora, rel ogio de refer encia, taxa de bits e zona de fuso hor ario, essenciais para que um terminal de acesso programe corretamente seus decodicadores e respeite as classica c oes indicativas da programa ca o. 3.1.2.2 Encapsulamento de Fluxos Elementares de Audio e V deo

No SBTVD, a formata c ao dos uxos elementares de audio e v deo que comp oem um programa e feita de acordo com as especica co es de codica ca o do H.264 e do HE-AAC v2, respectivamente. Como estes uxos apresentam uma depend encia temporal entre si, e necess ario que sua transmiss ao traga informa co es adicionais

3.1 TV Digital

42

que permitam identicar os tempos de decodica ca o e apresenta ca o, de forma que sua reprodu c ao seja sincronizada. Assim, o transporte dos pacotes que trazem segmentos de audio e v deo n ao e feito apenas pelos pacotes TS de 188 bytes; um outro protocolo denominado PES (Packetized Elementary Streams ) e adotado e usado para encapsular esse conte udo antes que ele seja mapeado aos pacotes TS do uxo de transporte. Em pacotes PES tamb em incluem-se informa co es relativas ao rel ogio do transmissor. Essa informa c ao e utilizada pelo receptor para que a decodica ca o dos uxos de audio e v deo seja feita com sincronia. Embora segmentado em pacotes de tamanho xo, a extens ao de um pacote PES completo e vari avel, correspondendo, tipicamente, ao tamanho de um quadro de audio ou de v deo. Naturalmente, a carga u til de pacotes de audio e v deo n ao apresenta um campo de vers ao, pois todos os pacotes transmitidos devem ser decodicados pelo receptor.

Figura 3.4: Encapsulamento de v deo, audio e dados no uxo de transporte

O processo de convers ao de uxos elementares para pacotes TS e mostrado e na Figura 3.4. O posicionamento de cada pacote TS no uxo de transporte decidido por um algoritmo de escalonamento, que considera as taxas de transmiss ao de tabelas m nimas exigidas pela norma de TV digital para denir a ordem
et al., 2005). A gura mostra tamb temporal de cada pacote (GIRAO em como e

feita a tradu c ao de dados de programas em pacotes TS; maiores detalhes s ao apresentados no t opico a seguir.

3.1 TV Digital

43

3.1.2.3

Tabelas de Transmiss ao de Dados

A transmiss ao de elementos de dados que n ao requerem sincronia com outros uxos e feita por meio de uma fam lia de protocolos denominada DSM-CC, do ingl es Digital Storage Media Command and Control (Comandos e Controles de Armazenamento de M dias Digitais) (ISO, 1996). Denido pela ISO/IEC e parte da fam lia de padr oes do MPEG, o DSM-CC foi originalmente concebido para suportar a entrega de v deo sob demanda em redes com um canal de comunica c ao bidirecional, mas acabou sendo estendido para atender a redes unidirecionais. O DSM-CC e utilizado no contexto de TV digital para a transmiss ao c clica de dados, tal como atualiza co es de software enviadas pelos fabricantes de terminais de acesso pelo uxo de transporte ou aplica co es interativas que s ao interpretadas por um Middleware. Este tipo de transmiss ao recebe o nome de carrossel (ABNT, 2007b).

Figura 3.5: Exemplo de estrutura de diret orios transmitida em um carrossel de objetos

Dois tipos de carross eis s ao denidos pelo protocolo: carross eis de dados e de objetos. No primeiro, o conte udo dos dados transmitidos n ao e especicado; por meio dele que s o receptor precisa ter conhecimento de como trat a-los. E ao enviadas as atualiza co es de software dos terminais de acesso, cujos dados s o dizem respeito a uma fam lia espec ca de aparelhos. Os carross eis de objetos, por outro lado, cont em dados identic aveis, como imagens, arquivos de texto, m usica, ou de aplica co es, transmitidos juntamente com uma estrutura de diret orios, que indica a organiza ca o l ogica dos objetos transmitidos, como no exemplo mostrado na Figura 3.5. A formata c ao dos dados no carrossel de objetos e descrita por mensagens que seguem um protocolo denominado BIOP. As mensagens BIOP consistem em um cabe calho, que cont em informa co es como o tamanho da mensagem e a vers ao do protocolo na qual ela est a codicada, e um subcabe calho, que descreve par ametros

3.1 TV Digital

44

Figura 3.6: Composi ca o de uma mensagem BIOP

espec cos do tipo de objeto na mensagem. Em um objeto que representa um diret orio, por exemplo, o subcabe calho cont em os nomes dos elementos contidos naquele diret orio. Uma mensagem BIOP e composta por m odulos de tamanho m aximo de 64 KiB. Cada um desses m odulos divide-se subsequentemente em outros blocos menores, denominados blocos de dados, que s ao encapsulados em mensagens de download de acordo com um protocolo denominado DDB (Download Data Block, ou Bloco de Dados de Download ). Cada mensagem DDB e encapsulada, por sua vez, em unidades denominadas se c oes, que s ao nalmente distribu das em pacotes do uxo de transporte de 188 bytes (Figura 3.6). Para identicar os blocos que comp oem um determinado conte udo, o DSM-CC envia mensagens denominadas DII (do ingl es Download Information Indication, ou Indica c ao de Informa ca o de Download ), que descrevem os blocos v alidos de maneira similar ` a forma como a tabela PAT indica a composi ca o dos programas v alidos de uma emissora (INFANTE; NASIOPOULOS, 2008).

3.2 Elementos de An alise em um Fluxo de Transporte de TV Digital

45

3.2

Elementos de An alise em um Fluxo de Transporte de TV Digital

A informa c ao contida nas tabelas de servi co e em seus descritores e essencial para a correta apresenta c ao dos programas transmitidos pela emissora. Logo, e de suma import ancia validar seu conte udo em um processo de an alise do uxo de transporte. A listagem a seguir indica os elementos de an alise mais comuns em produtos comerciais, por serem algumas das principais fontes de erro no uxo de transporte, bem como funcionalidades adicionais que se mostram bastante u teis no aux lio ` a identica c ao de problemas: Identica c ao das tabelas de informa ca o de servi co (SI) do MPEG-2. A interpreta c ao dos campos que comp oem as tabelas SI permite a identica ca o de par ametros incorretos ou n ao suportados por uma implementa ca o espec ca; Identica c ao das tabelas de informa ca o de servi co estendidas e de descritores denidos pelo DVB, ISDB, ATSC ou SBTVD (os valores que alguns descritores podem assumir podem n ao ser v alidos em todos esses padr oes). As tabelas e descritores mandat orios e opcionais especicados por uma norma de transmiss ao devem seguir uma formata ca o que, caso esteja fora da especica c ao, pode levar ` a exibi ca o de informa co es incorretas para o usu ario ou mesmo impedir a decodica ca o de uxos elementares de audio e v deo; Decodica ca o e exibi c ao de dados do Guia de Programa c ao Eletr onico (EPG). Essa informa c ao permite que se possa validar os resumos e tempo de dura ca o da programa ca o enviados pela emissora; Decodica ca o e exibi ca o de dados de legenda e closed caption. O protocolo de legenda especica uma s erie de informa c oes quanto a disposi c ao do texto e rolagem autom atica que devem ser respeitados por um terminal de acesso para que esse recurso n ao apresente problemas visuais indesej aveis. Alguns analisadores permitem a decodica ca o desse protocolo para auxiliar na depura ca o de problemas associados a esse recurso; Decodica ca o e exibi ca o de carross eis de dados e objetos. A atualiza ca o do software residente no terminal de acesso e a execu c ao de conte udos interativos requer a recep ca o e armazenamento dos objetos transferidos pela pilha de protocolos do DSM-CC. O acesso ao conte udo de cada arquivo e di-

3.2 Elementos de An alise em um Fluxo de Transporte de TV Digital

46

ret orio transmitidos auxilia na identica c ao de erros que podem bloquear a utiliza c ao de um terminal de acesso ou interferir no seu bom funcionamento; Separa c ao e grava ca o individual dos uxos elementares de audio e v deo. Alguns aplicativos s ao especializados na an alise de uxos elementares, compreendendo diversos protocolos de decodica c ao. A extra c ao e a grava ca o dos uxos elementares de audio e v deo em disco permitem que eles sejam analisados separadamente; Decodica ca o dos uxos de audio e v deo presentes no uxo de transporte analisado. Esse recurso permite que um usu ario tenha acesso e possa reproduzir individualmente um uxo de audio ou v deo e comparar a qualidade de reprodu ca o ` aquela observada em um terminal de acesso; Identica c ao da taxa de transmiss ao das tabelas de informa ca o de servi co (SI). As normas de TV digital especicam a taxa de transmiss ao m nima de algumas tabelas SI. O atraso na recep c ao de uma tabela SI pode impedir a identica c ao de um servi co durante a varredura de frequ encias ou desabilit alo durante uma troca de canais. A valida c ao das taxas de transmiss ao das tabelas SI e, dessa forma, bastante importante para a resolu c ao desse tipo de problema; Valida ca o do CRC presente em cada pacote. Interfer encias f sicas, o mau funcionamento de um software controlador de dispositivo ou mesmo a transmiss ao de dados em uma taxa acima daquela suportada pelo padr ao de TV digital podem levar a falhas de integridade de pacotes do uxo de transporte. A verica ca o do CRC de pacotes recebidos pode, assim, indicar a presen ca de algum problema f sico ou l ogico no lado do transmissor ou receptor; Listagem de erros presentes em cada PID. Todo o uso incorreto de par ametros ou erro detectados em um PID s ao agrupados e listados para que o usu ario tenha um resumo dos defeitos de cada elemento analisado. Alguns produtos permitem tamb em detectar a inconformidade de um uxo de transporte por meio da an alise cruzada de tabelas. Matthew (2004a) descreve um mecanismo baseado em uma lista, populada a partir dos programas e identicadores listados na tabela PAT. A seguir, o uxo de transporte e varrido em busca das tabelas PMT presentes naquela lista. Caso alguma tabela PMT n ao seja encontrada e nenhuma nova vers ao da tabela PAT seja recebida para informar que

3.2 Elementos de An alise em um Fluxo de Transporte de TV Digital

47

aquela PMT n ao se encontra efetivamente no uxo de transporte, uma condi c ao de erro e gerada. (MATTHEW, 2004b) tamb em descreve uma metodologia similar, utilizada pelos sistemas analisadores de uxo de transporte da Tektronix, para constatar se todos os programas identicados na tabela de descri ca o de servi cos (SDT) foram transmitidos no uxo de transporte 1 . Esses elementos de an alise s ao encontrados em produtos comerciais como (ZANALYZER, 2008; DEKTEC, 2006) e (ELECARD, 2006), que os apresentam ao usu ario

em interfaces criadas especialmente para essa nalidade. A Figura 3.7 mostra a composi ca o t pica de um aplicativo de an alise de uxo de dados: uma listagem exibe as tabelas reconhecidas, que podem ser expandidas em diferentes n veis hier arquicos para mostrar a informa ca o com mais detalhes. Nesta gura tamb em nota-se a representa c ao da informa c ao por meio de gr acos, usados para auxiliar o usu ario a compreender determinados eventos no uxo de transporte. Para a an alise de erros, o aplicativo pode indicar valores incorretos ou inesperados por meio do realce de cores.

Figura 3.7: Aplicativo StreamXpert, da Dektec

Um outro aplicativo de an alise popular entre engenheiros de TV digital e o DVBsnoop (SCHERG, 2001), um software livre desenvolvido para a an alise de
Esses pedidos de patente n ao foram aceitos pelo Escrit orio de Patentes Europeu (OFFICE, 2004).
1

3.3 S ntese

48

uxos de dados codicados conforme o padr ao europeu (DVB) que utiliza uma interface em modo texto para a exposi ca o dos resultados capturados. Assim como o o StreamXpert, o DVBsnoop apresenta um recurso bastante desej avel que n ao se encontra em muitas solu co es propriet arias: a captura e an alise do uxo de transporte em tempo real.

3.3

S ntese

Este cap tulo apresentou os principais elementos da arquitetura de transmiss ao de TV digital e o modelo de transmiss ao de informa c ao em elementos estruturados. O uxo de transporte do MPEG-2 utilizado por sistemas de transmiss ao de TV digital representa um caso especial de uxo de dados. Dois tipos de elementos trafegam nesse uxo: tabelas de informa ca o de servi cos, que s ao tratadas pelo receptor caso a vers ao da tabela n ao seja a mesma daquela previamente recebida, e uxos elementares de audio, v deo e dados que, em raz ao de sua vaz ao, n ao podem ser armazenados plenamente na mem oria do analisador. Os aspectos apresentados neste cap tulo s ao importantes para a compreens ao de como a proposta da arquitetura de an alise de uxo de dados, apresentada no pr oximo cap tulo, se aplica ao Sistema Brasileiro de TV Digital (Cap tulo 5).

49

Uma Arquitetura para An alise de Fluxo de Dados Estruturados

A arquitetura proposta para a an alise de um uxo de dados compreende 5 componentes principais: (i) a interface de captura de dados, por onde a leitura de elementos e realizada; (ii) um m odulo destinado ` a escolha dos elementos que ser ao processados; (iii) uma camada respons avel pelo processamento e gera ca o de metadados dos elementos escolhidos; (iv ) uma estrutura para o armazenamento dos resultados e (v ) uma interface que disponibilize os resultados produzidos ao usu ario (Figura 4.1).

Figura 4.1: A arquitetura de um analisador de uxo de dados proposta

Embora o tratamento dos elementos lidos dependa de caracter sticas intr nsecas a eles, a Se c ao 2.2 mostrou que diversos algoritmos estat sticos podem ser aplicados para denir quais elementos procedentes do uxo de dados ser ao processados. Da mesma forma, e poss vel denir um conjunto de regras gen ericas que, aplicadas a elementos estruturados de um uxo de dados, permitam a sua an alise de maneira consistente e sistem atica. Este cap tulo apresenta a contribui c ao principal desta disserta ca o, que e uma arquitetura para a an alise de uxo de dados estruturados. Sua composi c ao e feita da seguinte maneira: primeiramente s ao apresentadas as justicativas que

4.1 Requisitos do Modelo de An alise de Fluxo de Dados Estruturados

50

levaram ` a proposta do mecanismo de an alise; em seguida, s ao apresentadas as caracter sticas que tornam vi avel a implementa c ao deste mecanismo e, por m, s ao descritas as vantagens de sua ado ca o frente a outros modelos de armazenamento e exposi c ao de elementos estruturados amostrados.

4.1

Requisitos do Modelo de An alise de Fluxo de Dados Estruturados

A seguir s ao apresentados os requisitos desej aveis para a deni c ao de um modelo que permita expor os v arios atributos de um conjunto de dados estruturados. Parte destes requisitos foi determinada com base em experi encias pessoais na an alise de uxos de dados em TV digital e de pacotes em redes de computadores. S ao eles: 1. Integra c ao com aplica co es j a existentes; este requisito e importante pois existem ` a disposi c ao in umeras ferramentas gen ericas (por exemplo, processadores de texto) e espec cas (como aplicativos de an alise matem atica) j a integradas ` a maioria dos sistemas operacionais que podem ser usados para a manipula ca o e an alise de dados. 2. Uso de estruturas de dados leg veis e compreens veis por usu arios; o advento da internet e a evolu ca o de linguagens de marca c ao incrementaram o debate acerca da import ancia da legibilidade e intuitividade das linguagens declarativas e procedurais. Considerando a possibilidade dos dados estruturados serem muito complexos, este requisito torna-se desej avel. 3. Independ encia de ambientes computacionais; a cada dia aumenta a diversidade de microprocessadores, sistemas operacionais e linguagens de programa c ao. Portanto, um sistema de an alise abrangente deve ser capaz de operar numa diversidade grande de ambientes computacionais. 4. Facilidade de localiza ca o de elementos, atributos e metadados; considerando que as estruturas de dados s ao oferecidas na forma de uxos e os dados estruturados podem ser complexos, a agilidade de localiza c ao de elementos, atributos e metadados torna-se desej avel para uma an alise r apida e eciente. 5. Exposi ca o das informa co es capturadas sem requerer aplica co es especializadas; o objetivo deste requisito e evitar a necessidade de ferramentas sosticadas requerendo esfor cos adicionais de desenvolvimento.

4.1 Requisitos do Modelo de An alise de Fluxo de Dados Estruturados

51

6. Possibilitar a navega ca o na estrutura hier arquica com diferentes n veis de detalhamento; como a expans ao de todos os n veis hier arquicos dos elementos estruturados pode resultar em um grande volume de dados, torna-se desej avel que cada n vel possa ser expandido individualmente. 7. Permitir a representa c ao de depend encias entre elementos; em alguns casos os uxos de transporte podem transportar elementos que contenham metadados de outros elementos. Nesse caso a representa c ao de depend encias entre elementos torna-se uma caracter stica importante de ser analisada e exposta. 8. Elabora ca o de uma plataforma aberta a partir desses requisitos que possa ser usada efetivamente pela comunidade. V arios desses requisitos podem ser atendidos por uma representa c ao em arquivos textuais, tal como documentos XML. O grande volume de dados gerado por uma an alise, entretanto, pode tornar dif cil a leitura de um documento XML, considerando que cada elemento pode ser composto por sub arvores de profundidade variada, que podem exceder os limites do campo visual. Essa limita c ao poderia ser contornada com o desenvolvimento de uma aplica ca o que permita o ltro de seu conte udo e o colapso e a expans ao de sub arvores que n ao sejam de interesse do usu ario. Essa solu c ao, entretanto, impede a satisfa ca o do requisito de n umero 5. Tecnologias de armazenamento e consulta de informa co es baseadas em banco de dados permitem que o acesso a grandes volumes de elementos, sub arvores e atributos espec cos seja feita com grande eci encia e abstra c ao. Para isso, o formato dos dados em disco e geralmente otimizado para que o banco de dados tenha um baixo tempo de resposta ` as solicita c oes feitas pelo usu ario. Esse formato, entretanto, n ao e projetado para sua compreens ao visual, o que requer o uso de aplicativos especializados para a extra ca o dos dados armazenados. Essa caracter stica impede que os requisitos de n umero 2 e 5 sejam satisfeitos. Muito embora o desempenho no acesso a uma estrutura de diret orios dependa dos algoritmos e das estruturas de dados empregados no sistema de arquivos, a exposi ca o de elementos estruturados hierarquizados por meio dessa abstra ca o e aderente aos requisitos n ao atendidos pelas solu c oes anteriores, pois o suporte a opera co es sobre objetos em um sistema de arquivos est a presente em qualquer aplica ca o e sistema operacional moderno. Al em disso, ela permite, por meio do colapso e expans ao de diret orios, que cada n vel da hierarquia seja exposto ou

4.2 Deni c ao do Modelo de Exposi c ao de Elementos Estruturados em Sistemas de Arquivos52

ocultado da interface pelo pr oprio usu ario, sem a necessidade do desenvolvimento de aplica co es especiais para esse m. Por u ltimo, a representa c ao de depend encias entre elementos e a exposi c ao de atributos e metadados pode ser feita com o uso de recursos padronizados, permitindo a portabilidade na exposi ca o de elementos segundo essa abstra c ao. A ubiquidade de sistemas de arquivos no universo de plataformas computacionais e as possibilidades de representa c ao de dados por meio de seus objetos e funcionalidades tradicionais justica, assim, a escolha de um mecanismo para armazenamento e exposi c ao de elementos estruturados hierarquizados baseado nesse conceito.

4.2

Deni c ao do Modelo de Exposi c ao de Elementos Estruturados em Sistemas de Arquivos

A estrutura de um elemento n ao vazio e constitu da por um ou mais atributos e zero ou mais metadados. Cada atributo pode conter uma quantidade diversa de informa c ao a respeito do elemento inclusive subdivididas em um outro conjunto de atributos. Denimos que cada conjunto de atributos e mapeado para um diret orio e que cada atributo que n ao seja subdividido em outros atributos e mapeado para um arquivo, cujo conte udo e aquele contido na carga u til do atributo. Metadados podem conter informa co es a respeito de um atributo espec co ou de um conjunto deles. Denimos que cada metadado e representado por um par ordenado (nome, valor), e que essa tupla e mapeada para um atributo do arquivo ou diret orio que representa os dados. Por u ltimo, denimos que a rela ca o de depend encia entre dois elementos e e representada por um par ordenado (, ), onde e um arquivo especial pertencente ao diret orio que aponta para o diret orio ou arquivo . Essas regras s ao sucientes para representar hierarquias complexas, que podem ser acessadas com o uso de ferramentas tradicionais de ambientes computacionais, como as interfaces de abertura e leitura de arquivos e diret orios, especicadas e recomendadas pelos padr oes internacionais de interoperabilidade entre sistemas operacionais POSIX. As subse co es a seguir especicam com detalhes como esses e outros conceitos

4.2 Deni c ao do Modelo de Exposi c ao de Elementos Estruturados em Sistemas de Arquivos53

de sistemas de arquivos se relacionam com a an alise de elementos estruturados.

4.2.1

Canais de Comunica c ao Unidirecionais Entre Processos

Al em da funcionalidade b asica de representa ca o de elementos distintos capturados em um uxo de dados, o acesso direto em tempo real ao conte udo do uxo benecia diversas classes de problemas. A exemplo, os elementos analisados em um uxo de v deo H.264 podem conter informa co es quanto ` a congura ca o dos par ametros da imagem, ao coeciente de quantiza ca o, entre outros (ABNT, 2008d). Entretanto, pode ser interessante para o usu ario reproduzir a m dia do uxo de v deo em paralelo ao processo de captura e processamento dos elementos espec cos, sem que a integridade dos dados encaminhados ao componente de processamento seja comprometida. Essa funcionalidade e suportada na arquitetura de an alise proposta por um canal de comunica c ao unidirecional ab entre o processo produtor a e um u nico processo consumidor b, por onde cada elemento de entrada passa. A restri ca o a um u nico processo consumidor e feita para que o modelo de recep ca o de dados, no qual uma interface de leitura recebe apenas um uxo de dados, seja representado corretamente. Do contr ario, uma implementa ca o pode ter seu desempenho prejudicado devido ` a realiza ca o de c opias redundantes dos elementos de entrada a cada um dos consumidores. Um tipo de arquivo especial denominado FIFO (do ingl es First-In,First-Out ) e denido pelo padr ao POSIX para prover servi cos de comunica ca o entre processos por meio de arquivos. Um processo produtor abre o arquivo em modo de escrita e um outro processo o abre em modo de leitura. No entanto, diferentemente de uma opera c ao sobre dados em disco, a area de armazenamento do sistema de arquivos n ao e utilizada; a troca de dados por meio de um FIFO ocorre com uma transfer encia direta de dados da origem para o destino. As propriedades de FIFOs permitem, dessa forma, a preserva ca o da sem antica denida para um canal de comunica c ao ab , justicando sua recomenda c ao para a implementa c ao do recurso de um canal de comunica c ao unidirecional entre processos em uma arquitetura de an alise de elementos estruturados.

4.2 Deni c ao do Modelo de Exposi c ao de Elementos Estruturados em Sistemas de Arquivos54

4.2.2

Mecanismos de Atributos

A informa ca o contida em um elemento estruturado pode ser descrita com o uso de metadados pares ordenados do tipo (nome, valor). Esses pares, quando atribu dos a um elemento, permitem que algumas informa c oes sejam obtidas sem a necessidade da interpreta ca o completa dos seus dados. Por exemplo, um elemento que represente uma imagem digital pode conter os pares (Resolu c ao,1920x1080), (Local,S ao Paulo), (Evento,S ao Silvestre), facilitando a classica ca o dessa imagem pelo usu ario. A gera c ao de metadados pode ser feita de duas maneiras: pelo fornecimento expl cito do usu ario ou pela pr opria arquitetura de an alise de uxo de dados, caso haja informa c ao suciente para sua gera ca o autom atica. A arquitetura proposta neste trabalho dene a seguinte pol tica para a atribui c ao de metadados nos arquivos que representam os elementos e seus atributos: 1. Gera c ao autom atica: e feita sempre que alguma informa ca o relevante estiver dispon vel no uxo de dados, ou que algum erro l ogico tenha sido identicado no elemento lido. Tais informa co es s ao descritas por um nome prexado por um radical determinado, reservado para metadados gerados automaticamente. Exemplo: (system.error, Sintaxe inv alida). 2. Atribui c ao pelo usu ario: e feita pelo usu ario para o envio de comandos arbitr arios aos diferentes componentes da arquitetura representados por arquivos FIFO. Tais comandos s ao prexados por um radical determinado, diferente daqueles usados na gera c ao autom atica de metadados. Exemplo: (user.buffer size, 4096). Quatro opera c oes sobre atributos s ao denidas na arquitetura: cria ca o, modica ca o, leitura e exclus ao. A pol tica de modica ca o e exclus ao segue os mesmos princ pios adotados para a cria c ao: metadados gerados automaticamente pelo sistema ou pelo usu ario podem apenas ser modicados ou exclu dos pelo mesmo. Uma classe de fun c oes estabelecidas pela norma POSIX 1003.1e (IEEE, 2001) permite a manipula ca o de metadados em arquivos. A interface de atributos estendidos denida no padr ao foi inicialmente concebida para permitir a implementa c ao de listas de controle de acesso a arquivos, por em ela e abrangente o suciente para permitir o armazenamento de quaisquer pares de dados. Uma discuss ao sobre o suporte a atributos estendidos em sistemas de arquivos tradicionais, que n ao foram projetados para suport a-los, pode ser encontrada no

4.3 S ntese

55

Anexo A.

4.2.3

Liga co es Simb olicas no Sistema de Arquivos

Com frequ encia, os elementos obtidos de um uxo de transporte passam por algum processo de classica ca o, seja ele com a nalidade de agrupar elementos que tenham caracter sticas similares ou de indicar aqueles que apresentem correla ca o com outros. Essa necessidade traz, como consequ encia, o armazenamento de tais elementos (arquivos e subdiret orios) dentro de um ou mais diret orios, o que pode implicar um aumento signicativo na quantidade de espa co de armazenamento requerido. Para evitar c opias redundantes de arquivos e sub arvores, e denido o u ltimo componente do sistema de arquivos para an alise de elementos estruturados, a liga c ao simb olica. Uma liga ca o simb olica e um arquivo especial que mapeia um outro arquivo ou diret orio . Ao acessar um objeto , o sistema de arquivos deve recuperar a informa ca o do alvo e redirecionar a opera ca o para ele. Al em disso, opera co es especiais sobre o arquivo devem permitir a identica ca o do seu alvo (sem que para isso seja necess ario ler o conte udo do arquivo alvo) e a cria ca o de uma liga c ao simb olica para um alvo inexistente. O padr ao POSIX suporta esse tipo de declara c ao por meio de arquivos especiais validados em tempo de execu ca o. O conte udo do objeto alvo n ao e replicado no arquivo de liga c ao simb olica; este consiste apenas na informa c ao do seu alvo. Com esse recurso, o modelo hier arquico deixa de oferecer uma u nica vis ao xa e monol tica da estrutura em arvore, possibilitando o agrupamento de elementos e a descri ca o de depend encia de dados com um impacto m nimo no espa co de armazenamento requerido 1 .

4.3

S ntese

Este cap tulo apresentou uma proposta de uma arquitetura para a an alise de uxo de dados estruturados com base em um sistema de arquivos. Essa proposta foi realizada a partir da deni c ao de diversos requisitos desej aveis, os quais permitiram delinear o modelo de representa ca o de dados e os recursos que esse modelo deveria apresentar. A implementa ca o de um analisador de uxo de dados segundo a deni ca o
O espa co requerido e vari avel e depende da implementa c ao de liga c oes simb olicas em cada sistema operacional
1

4.3 S ntese

56

dessa arquitetura pode ser feita com o uso de ferramentas e interfaces padronizadas. Com isso, a exposi ca o de elementos estruturados hierarquizados pode ser feita com grande portabilidade, visto que os recursos b asicos exigidos est ao presentes em qualquer plataforma que respeite padr oes internacionais de interoperabilidade entre sistemas operacionais. Essa mesma arquitetura oferece ainda um mecanismo ex vel para a comunica ca o e o envio de comandos a componentes diversos que a comp oem, de forma que suas funcionalidades b asicas sejam estendidas, de forma a atender a outros requisitos desej aveis. Assim sendo, essa proposta supera os objetivos iniciais almejados, tornando-se gen erica o suciente para permitir o mapeamento de uma ampla classe de problemas. O pr oximo cap tulo apresenta como essa arquitetura pode ser aplicada para permitir a an alise de componentes transmitidos em um uxo de transporte de um sistema multim dia, mais especicamente do Sistema Brasileiro de TV Digital (SBTVD). A seguir, a valida ca o da implementa c ao de um sistema de arquivos para a an alise do uxo de transporte do SBTVD e apresentada, consolidando essa proposta.

57

Aplica c ao da Arquitetura Proposta no Sistema Brasileiro de TV Digital

Este cap tulo apresenta como a arquitetura de an alise de elementos estruturados proposta pode ser aplicada a um sistema multim dia, mais especicamente ao Sistema Brasileiro de TV Digital (SBTVD). A escolha desse tema ocorreu em fun ca o do envolvimento do autor deste trabalho com a recomenda ca o, deni ca o e implementa ca o do sistema no pa s. Desde as primeiras fases de implanta ca o do SBTVD no Brasil, que ocorreu a partir de dezembro de 2005, a an alise do uxo de dados emitido pelos produtores de conte udo se mostrou essencial para a valida c ao dos elementos transmitidos e a correta implementa ca o de terminais de acesso de TV digital. A r apida identica ca o da origem de condi co es an omalas na decodica ca o de elementos do uxo de dados continua sendo determinante para que a transi ca o do sistema de transmiss ao anal ogico para digital ocorra dentro dos prazos estabelecidos pelo Governo. Dessa forma, torna-se essencial a exist encia de mecanismos ecientes de an alise que possam ser utilizados pelos diversos participantes desse f orum. Este cap tulo apresenta primeiramente a t ecnica empregada para a amostragem dos elementos que ser ao expostos ao usu ario, seguida por uma proposta para a disposi ca o desses elementos em uma hierarquia de diret orios segundo a arquitetura denida no cap tulo anterior. O cap tulo e nalizado com as conclus oes gerais da aplica c ao da arquitetura proposta no uxo de transporte do SBTVD.

5.1 Um Sistema de Arquivos para An alise do Fluxo de Transporte

58

5.1

Um Sistema de Arquivos para An alise do Fluxo de Transporte

O Cap tulo 3 mostrou que as tabelas transmitidas no uxo de transporte seguem uma organiza c ao estruturada e hierarquizada, o que permite seu mapeamento direto a uma arvore composta por arquivos e diret orios em um sistema de arquivos. A transmiss ao c clica de tabelas e o uxo cont nuo de elementos de audio, v deo e dados, no entanto, tende a exigir um espa co de armazenamento innito para que toda a informa c ao seja mantida na mem oria do receptor. Dessa forma, denimos algumas restri co es quanto ao tipo de dado que car a permanentemente acess vel no sistema de arquivos: 1. O armazenamento de tabelas de informa c ao de servi co e priorit ario em rela c ao a outros elementos do uxo de transporte; 2. A estrutura de dados deve expor diferentes vers oes de uma tabela em sub arvores distintas. Para otimizar o consumo de mem oria exigido para manter duas ou mais vers oes de uma mesma tabela, uma l ogica similar e empre` a do algoritmo Count-Min (CORMODE; MUTHUKRISHNAN, 2004) gada: apenas os atributos que diferem daqueles j a armazenados em vers oes anteriores daquela tabela s ao registrados; 3. Fluxos elementares de audio e v deo n ao s ao amostrados, por em o acesso ao seu conte udo deve ser poss vel; 4. A estrutura de arquivos e diret orios transferidos por meio dos carross eis de dados e objetos do DSM-CC pode demandar um espa co de armazenamento maior do que aquele encontrado na mem oria RAM. Para permitir que os pacotes de dados recebidos possam ser analisados, uma parti c ao de dados n ao-vol atil e usada para a sua grava c ao. A tradu ca o de elementos presentes no uxo de transporte para objetos no sistema de arquivos e feita conforme um conjunto de regras: 1. Tabelas do MPEG-2 e do SBTVD s ao armazenadas na raiz do sistema de arquivos na forma de diret orios que recebem o nome da tabela em quest ao. Uma listagem do diret orio raiz indica todas as tabelas reconhecidas e analisadas at e ent ao;

5.1 Um Sistema de Arquivos para An alise do Fluxo de Transporte

59

2. Um subdiret orio dentro dos diret orios de cada tabela indica a vers ao recebida e abriga todos os atributos presentes naquela tabela. Descritores presentes em cada tabela s ao armazenados em subdiret orios espec cos no mesmo n vel hier arquico que abriga os seus atributos; 3. Atributos simples s ao armazenados na forma de arquivos. Atributos estruturados s ao armazenados em um diret orio que recebe o nome do atributo e que cont em dois ou mais arquivos ou subdiret orios. 4. Pacotes PES s ao armazenados na raiz do sistema de arquivos na forma de diret orios que recebem como nome o n umero PID do pacote em quest ao. 5. Objetos recebidos nos carross eis de dados s ao armazenados em uma sub arvore conforme a hierarquia especicada nas mensagens BIOP dos pacotes DSMCC. Como eles s ao transmitidos em pacotes PES, a sub arvore e criada dentro de um diret orio criado conforme a regra anterior; 6. Fluxos elementares de audio e v deo, presentes em pacotes PES, s ao representados por meio de canais unidirecionais FIFO, que t em seu conte udo produzido sob demanda, dependendo da exist encia de um processo consumidor. A apresenta ca o de metadados e os erros e inconformidades encontrados a partir da an alise de cada tabela s ao dispostos por meio do mecanismo de atributos estendidos. O uso desse e outros objetos de sistema de arquivos e explicado a seguir.

5.1.1

O Uso de arquivos FIFO

Arquivos FIFO s ao usados para permitir o acesso direto aos uxos elementares de audio e v deo. A arquitetura de an alise pode prover acesso direto tanto aos pacotes PES, que cont em um cabe calho com informa co es de tempo de decodica ca o e apresenta ca o de cada quadro, quanto aos pacotes elementares (ES), que comp oem a carga u til dos pacotes PES. O acesso a ambos e interessante do ponto de vista de an alise, pois muitas plataformas de terminal de acesso apresentam recursos para a reprodu ca o de uxos ou arquivos monom dia. A escolha de arquivos segundo a sem antica de FIFOs permite o acesso direto aos uxos elementares, sem a necessidade de que os mesmos sejam armazenados em disco ou mantidos em mem oria pelo sistema de arquivos. Ao mesmo tempo, um arquivo FIFO permite a captura de uxos individuais de audio e

5.1 Um Sistema de Arquivos para An alise do Fluxo de Transporte

60

v deo para fornec e-los a aplicativos especializados na an alise dos seus protocolos de codica c ao. Essa arquitetura tamb em possibilita a integra ca o de extens oes ao sistema de arquivos: um analisador de H.264 poderia ser implementado como um processo consumidor da FIFO que representa um uxo elementar de v deo. Outros elementos transferidos por meio de pacotes PES s ao os dados de legenda e closed caption. Eles podem ser igualmente acessados por arquivos FIFO ou processados separadamente por um aplicativo capaz de interpretar os protocolos utilizados para o transporte desse tipo de informa c ao.

5.1.2

A Aplica c ao de Atributos Estendidos

Atributos estendidos s ao pares ordenados do tipo (nome, valor) associados a um arquivo ou diret orio. Seu uso na an alise de elementos capturados do uxo de transporte e feito de 3 maneiras diferentes. Na primeira, tuplas s ao geradas automaticamente pelo sistema de an alise para indicar a ocorr encia de erros ou dados informativos relevantes. A nomenclatura system.error.<erro> e adotada em atributos indicativos de erro; um problema de CRC, por exemplo, e indicado por um atributo estendido de nome system.error.crc, associado ao diret orio principal que representa a tabela. O conte udo presente no campo valor pode assumir uma frase indicativa como Lido 0x2112, esperado 0x1221. Dados informativos s ao agregados ao arquivo ou diret orio segundo o padr ao system.info.<info>. A indica ca o da taxa de transmiss ao de uma tabela segue essa sintaxe, em que o u ltimo campo assume o valor bitrate. Nota-se que a lista de nomes v alidos deve ser de conhecimento do usu ario para que ele possa automatizar a extra c ao de informa ca o a partir da leitura dos atributos de cada arquivo ou diret orio. Tamb em com o intuito de facilitar a extra ca o autom atica de informa co es de arquivos, o segundo uso dado a atributos estendidos consiste na indica ca o da formata ca o dos dados presentes em cada arquivo. O nome reservado system.format e denido para tal, podendo assumir valores como binary data, number, string, signicando que um conte udo bin ario, num erico ou textual e encontrado no arquivo. Outras constru c oes s ao tamb em admitidas, como string [number] e number [<new line>number], indicando a presen ca de um texto leg vel seguido de um n umero e de um ou mais n umeros separados por quebras de linha, respectivamente. Esses atributos s ao gerados automaticamente pelo

5.1 Um Sistema de Arquivos para An alise do Fluxo de Transporte

61

sistema de an alise e n ao podem ser modicados pelo usu ario. Ou ltimo uso denido para atributos estendidos na arquitetura de an alise de uxos de transporte do SBTVD e para especicar o tamanho dos buers internos dos arquivos FIFO que d ao acesso aos uxos elementares de audio e v deo. A nalidade desse atributo e permitir a redu c ao, em tempo de execu ca o, do consumo de mem oria do computador analisador ou o aumento de quadros mantidos em mem oria para possibilitar a reprodu ca o ininterrupta do seu conte udo. O atributo reservado para essa nalidade, user.buffer size, e especicado pelo usu ario.

5.1.3

A Organiza c ao de Vers oes e Depend encias com Liga c oes Simb olicas

Liga co es simb olicas s ao utilizadas na arquitetura de an alise para indicar qual, entre uma ou mais vers oes de uma tabela j a recebida, denota a u ltima vers ao transmitida no uxo de transporte. Uma constru c ao similar e usada para indicar os uxos elementares principais e secund arios de audio e v deo em programas compostos por m ultiplas l nguas e c ameras. Essa indica ca o e especialmente u til para identicar o motivo pelo qual um programa e decodicado em espanhol quando o audio em portugu es e esperado, por exemplo. A liga ca o simb olica criada para a vers ao atual de uma tabela permite tamb em o acesso a elementos espec cos por meio de caminhos invari aveis; a u ltima vers ao de um determinado arquivo pode ser sempre encontrada pela leitura de um caminho conhecido como /PMT/Current/table id, que tem a liga c ao simb olica Current apontando para um subdiret orio dentro de /PMT. A decis ao de utilizar liga c oes simb olicas dessa maneira vem da proposta de Muhammad e Detsch (2002), que prop oe uma estrutura de diret orios coerente para o armazenamento de programas instalados em sistemas operacionais Linux. Depend encias entre tabelas s ao tamb em representadas por meio desses objetos no sistema de arquivos. A rela ca o entre as tabelas PAT e PMT apresentada anteriormente na Figura 3.3 pode ser descrita com o uso dessa abstra ca o; assumindo a exist encia das sub arvores /PMT/0x20/2/ e /PMT/0x21/1/ que representam as tabelas PMT trazidas nos PIDs 0x20 e 0x21 e da estrutura de diret orio /PAT/1/Programs/, a conex ao entre as tabelas e indicada por duas liga co es simb olicas /PAT/1/Programs/1 /PMT/0x20/2 e /PAT/1/Programs/2 /PMT/0x21/1. Uma propriedade especial do uso de liga c oes simb olicas nesse caso e a simplicidade com que um uxo de transporte fora de conformidade com o padr ao e exposto para o usu ario: caso uma das tabelas anunciada pela PAT

5.2 S ntese

62

n ao tenha sido transmitida, por exemplo, a liga c ao simb olica apontar a para um diret orio inexistente, resultando em um elo quebrado situa c ao facilmente identic avel por ferramentas padronizadas de listagem de diret orios como o comando ls especicado pelo POSIX 1003.2 1 . Uma u ltima aplica ca o dada ` as liga c oes simb olicas e o agrupamento de elementos que se encaixem em uma mesma categoria. Por exemplo, todos os pacotes que trazem uxos elementares de audio, v deo ou legendas podem ser listados no diret orio /FluxosElementares, que ir a conter arquivos especiais apontando para o local de armazenamento de cada um deles, sem que o usu ario precise navegar na hierarquia de diret orios para encontr a-los.

5.2

S ntese

Este cap tulo apresentou como o mecanismo de an alise de uxo de dados proposto pode ser aplicado ` as tabelas encapsuladas no uxo de transporte do Sistema Brasileiro de TV Digital, um superconjunto do uxo de transporte do MPEG-2. Com a proposta, se mostrou ser poss vel representar os principais elementos de an alise presentes em produtos comerciais e desej aveis na resolu ca o de problemas de uxos de transporte por meio de uma estrutura de diret orios conceitualmente simples. Mesmo com um car ater de transmiss ao potencialmente innito, o estabelecimento de algumas regras permite a an alise das tabelas essenciais em um uxo de transporte, ao mesmo tempo em que o acesso aos pacotes de audio, v deo e legendas pode ser feito para acompanhar cada programa recebido. Os mesmos objetos no sistema de arquivos usados para essa nalidade permitem a extra ca o de uxos independentes para sua an alise posterior, recurso este executado com uma opera c ao bastante tradicional de c opia de arquivos. Diversas funcionalidades s ao fornecidas por meio de atributos estendidos, como a indica c ao de erros e dados informativos e a congura ca o do tamanho de mem oria reservada para os buers de uxos elementares. A exibilidade fornecida por esse mecanismo permite ainda que outros metadados sejam agregados ` as tabelas, bastando para isso tornar p ublica a lista de nomes reservados usados pela implementa ca o. Al em da nalidade de representar interdepend encias entre tabelas e de fornecer uma vis ao consistente do sistema de arquivos, liga co es simb olicas possibili1

Atualmente incorporado ao POSIX 1003.1

5.2 S ntese

63

tam a quebra do paradigma tradicional de um modelo hier arquico que representa apenas uma vis ao xa e monol tica da estrutura em arvore. Essa caracter stica, somada ` a naturalidade com que a proposta se integra a outras estruturas de dados hier arquicas (como as transmitidas nos carross eis de dados), valida a escolha de uma abstra ca o de arquivos na deni ca o de uma arquitetura para a an alise do uxo de transporte do SBTVD.

64

A Implementa c ao de Refer encia DemuxFS

Este cap tulo apresenta a caracter sticas da implementa ca o de refer encia de um sistema de arquivos para a an alise do uxo de dados do Sistema Brasileiro de TV Digital, denominada DemuxFS. Sua concep c ao e feita de acordo com as especica co es consolidadas no cap tulo anterior. As se co es a seguir s ao divididas da seguinte forma. A primeira apresenta as considera co es quanto ` a escolha das arquiteturas de hardware e software. A segunda parte avalia os recursos computacionais exigidos por essa implementa ca o, considerando as caracter sticas de uxos de dados mostradas no Cap tulo 2 e dos elementos que comp oem o uxo de transporte do MPEG-2. Em seguida, a maneira segundo a qual os recursos denidos no Cap tulo 4 s ao empregados no DemuxFS e demonstrada. Encerrando este cap tulo, encontram-se as conclus oes obtidas com a implementa ca o e o uso do DemuxFS pelo grupo de pesquisa em TV digital do Laborat orio de Sistemas Integr aveis da USP.

6.1

Considera co es de Implementa c ao

As plataformas de hardware e software compat veis com a implementa ca o do sistema de arquivos foram determinadas com base em dois crit erios: portabilidade, para permitir sua execu ca o na maior quantidade de plataformas com o menor n umero de modica co es no c odigo poss vel, e integra c ao com um terminal de acesso de TV digital de baixo custo, de forma a possibilitar a an alise de uxos de transporte a partir do pr oprio aparelho usado para assistir ao conte udo de radiodifus ao. Um sistema de arquivos tradicional e intrinsicamente ligado ` as interfaces de programa ca o (APIs) internas do sistema operacional (SO) no qual ele e desenvolvido, tais como fun c oes de aloca c ao de mem oria, prote c ao de acesso a regi oes cr ticas, metodologias de declara ca o e registro de m etodos, entre outros. Ele

6.1 Considera c oes de Implementa c ao

65

tamb em e diretamente dependente do formato de estruturas de dados do SO, como aquelas que representam inst ancias de arquivos abertos e de cache de dados. Assim, mesmo que as interfaces de comunica ca o de aplica co es do usu ario com o sistema de arquivos sigam as especica co es do padr ao POSIX, sua implementa c ao torna-se completamente dependente do sistema operacional no qual foi desenvolvido, demandando a reescrita de uma grande parte do c odigo quando este e portado para outro sistema operacional. A implementa ca o de um sistema de arquivos port avel requer, assim, que sua concep ca o seja feita em espa co de usu ario 1 , de onde o acesso aos recursos do sistema operacional pode ser feito por meio de interfaces padronizadas. Essa funcionalidade e encontrada na arquitetura de software proposta pelo FUSE (SZEREDI, 2009), do ingl es Filesystem in Userspace, adotada na concep ca o do DemuxFS. O FUSE e destacado e apresentado com detalhes na subse ca o a seguir. Como base para a implementa ca o do DemuxFS, duas arquiteturas de hardware foram escolhidas. A primeira, devido a sua abrang encia, e a plataforma PC. Nela, a entrada do uxo de transporte e feita por meio de arquivos que contenham segmentos de programas de TV digital, capturados de transmiss oes reais ou gerados em laborat orio. A segunda arquitetura consiste em uma plataforma ARM XScale para eletr onicos de consumo no segmento de TV digital. Essa arquitetura, projetada e desenvolvida pelo Laborat orio de Sistemas Integr aveis da USP, e apresentada na subse ca o seguinte ` a do FUSE. Embora diversos trabalhos relacionados a TV digital tenham sido desenvolvidos em conjunto com outros pesquisadores do Laborat orio de Sistemas Integr aveis da USP, a implementa ca o do DemuxFS foi feita separada e individualmente at e o dep osito desta disserta c ao.

6.1.1

Sistemas de Arquivos em Espa co de Usu ario

O FUSE (Filesystem in Userspace ) prov e um mecanismo para a implementa ca o de sistemas de arquivos em espa co de usu ario em ambientes POSIX. Inicialmente concebido no Linux, ele encontra-se hoje integrado a sistemas operacionais como
O termo espa co de usu ario denota um modo de execu c ao no qual processos t em acesso restrito a recursos computacionais, como instru c oes privilegiadas e leitura/ escrita a regi oes de mem oria quaisquer; apenas o n ucleo do sistema operacional, que executa em espa co de sistema, com base nessa separa acessa-os livremente. E c ao que sistemas operacionais implementam mecanismos de prote c ao de acesso ` a mem oria, de seguran ca e de virtualiza c ao (SILBERSCHATZ; GALVIN; GAGNE, 2004).
1

6.1 Considera c oes de Implementa c ao

66

o FreeBSD, NetBSD, Mac OS X, GNU/Hurd e Open Solaris 2 . A arquitetura do FUSE e constitu da por dois m odulos: uma biblioteca de fun co es, denominada libfuse, por meio da qual um sistema de arquivos implementa as sem anticas das opera co es sobre seus objetos (arquivos e diret orios), e um m odulo espec co para o sistema operacional, implementado no n ucleo executivo, que ca respons avel pela comunica ca o entre o sistema de arquivos e as aplica co es que requisitam dados armazenados nele. Em sua implementa ca o no n ucleo do Linux, o canal de comunica ca o entre a libfuse e o gerenciador do n ucleo executivo e o dispositivo virtual /dev/fuse. Quando aberto, esse dispositivo retorna um descritor pelo qual o sistema de arquivos pode registrar seus servi cos e enviar e receber comandos, segundo um protocolo espec co. Uma vez registrado, os servi cos exportados pelo sistema de arquivos tornam-se dispon veis para as aplica c oes por meio de um ponto de montagem denido pelo administrador na arvore de diret orios do computador onde o processo do sistema de arquivos executa. O uxo de uma opera c ao no FUSE pode ser acompanhado na Figura 6.1. Nela, uma aplica c ao solicita a abertura de um arquivo /mnt/arquivo.txt por meio da fun ca o POSIX open. Essa fun ca o e fornecida pela biblioteca b asica do sistema (Glibc), que abstrai a interface de abertura de arquivo do n ucleo executivo utilizado, que nesse exemplo e a fun c ao syscall de n umero 5. A execu ca o dessa fun ca o gera uma interrup c ao de software, levando ` a troca do contexto de execu ca o do processo de modo usu ario para modo sistema. Ao passar a executar em modo privilegiado, uma camada denominada VFS (Virtual File System ) determina qual sistema de arquivos responde por requisi co es feitas ao diret orio /mnt, e ent ao redireciona a solicita ca o ao sistema de arquivos correspondente, que trata o comando e retorna o resultado para a aplica ca o solicitante (WEINBERGER, 1984). Ao oposto de sistemas de arquivos implementados no n ucleo executivo, como o 9P e o Procfs mostrados na Figura 6.1, os servi cos de um sistema de arquivos FUSE n ao se encontram efetivamente no espa co de sistema. Cabe ao m odulo FUSE, ent ao, redirecionar a solicita ca o, mais uma vez, ao processo em espa co de usu ario que implementa o servi co (identicado na gura pelo processo P2), que ir a nalmente trat a-la e retornar o resultado para a aplica c ao (identicado pelo processo P1). O impacto associado ao uso do FUSE em rela ca o a uma implementa ca o nativa
As diculdades t ecnicas e desaos associados ` a sua implementa c ao em plataformas Microsoft Windows s ao abordadas em (DRISCOLL; BEAVERS; TOKUDA, 2008).
2

6.1 Considera c oes de Implementa c ao

67

Figura 6.1: Fluxo de uma chamada de sistema a um sistema de arquivos FUSE

no n ucleo executivo est a nas trocas de contexto e c opia de dados extras que ocorrem para cada chamada de sistema durante a comunica ca o das duas entidades pelo canal /dev/fuse. A lat encia da chamada de sistema pode ser dramaticamente reduzida, em algumas implementa co es do FUSE, com o uso de segmentos de mem oria compartilhados, que evitam a c opia redundante de dados. Assim, nessas plataformas, o impacto no uso de sistemas de arquivos implementados em espa co de usu ario se reduz ` as trocas de contexto, de menor relev ancia para projetos que n ao requerem tempos de resposta previamente determinados, como eo caso do DemuxFS.

6.1.2

A Plataforma de TV Digital Tall

A Tall e uma plataforma para terminais de acesso de TV Digital. Desenvolvida no Laborat orio de Sistemas Integr aveis (LSI) da USP e baseada na arquitetura do processador de m dias Intel CE2110, a Tall e composta por um processador ARM XScale de 1 GHz e dois m odulos de mem oria RAM de 128 MiB cada. A periferia de componentes inclui decodicadores de v deo H.264 e MPEG-2, um acelerador gr aco para opera co es 2D e 3D e controladores SATA, USB 1.1, USB 2.0 e Smart Card, entre outros. Um sintonizador/demodulador digital capaz de interpretar o sinal do SBTVD e tamb em integrado ` a plataforma, que pode ser vista na foto da Figura 6.2.

6.1 Considera c oes de Implementa c ao

68

Figura 6.2: A plataforma de TV digital Tall

Tanto o projeto de hardware quanto o desenvolvimento do software b asico da plataforma Tall foram feitos pelo grupo de pesquisadores do LSI. Sua pilha de software e composta pelo n ucleo do Linux e pelas bibliotecas Glibc e GStreamer, que fornecem funcionalidades de programa ca o na linguagem C e de aplica c oes multim dia, respectivamente. A interface de leitura do uxo de transporte e feita a partir da sa da do sinal demodulado do tuner, que e enviado para um dispositivo demultiplexador program avel; e por meio dele que uma aplica ca o residente solicita a leitura de tabelas de informa ca o de servi co e encaminha os pacotes de uxos elementares de audio e v deo aos decodicadores dedicados. Uma aplica ca o completa de TV digital foi desenvolvida para a plataforma Tall pelo LSI. Entre os recursos suportados est ao a troca b asica de canais, a visualiza ca o de legendas e do guia de programa ca o enviado pelas emissoras, a atualiza ca o do software residente por carross eis de dados do DSM-CC e a sua integra c ao com o middleware. Essa aplica c ao integra-se ` a plataforma Tall de modo a oferecer uma solu c ao completa de TV digital no Brasil. A participa c ao pessoal na produ c ao dessa plataforma ocorreu em diversas etapas do projeto, que incluem a deni c ao e a implementa c ao dos protocolos de comunica ca o entre o middleware e a aplica ca o de reprodu c ao de m dias, o desenvolvimento de drivers de dispositivos e a infraestrutura geral dos programas residentes, respons aveis pela decodica c ao e exibi ca o de m dias. Essa anidade com o projeto tornou a escolha da Tall bastante natural para a valida c ao da proposta do tema desta disserta c ao.

6.2 Requisitos Computacionais

69

6.2

Requisitos Computacionais

O DemuxFS e um sistema de arquivos implementado em espa co de usu ario, cujos arquivos e diret orios s ao mantidos em uma area de armazenamento vol atil. Como consequ encia, a utiliza c ao da mem oria RAM deve ser otimizada de forma a maximizar a quantidade de elementos que possam ser amostrados do uxo de transporte. Os elementos armazenados em mem oria n ao-vol atil pelo DemuxFS s ao as tabelas de informa ca o de servi co (SI) descritas no uxo de transporte do MPEG2. O Cap tulo 5 mostrou que a transmiss ao das tabelas SI e feita de forma c clica, de modo que um terminal de acesso de TV digital possa identicar o conte udo transmitido no uxo de dados e iniciar a decodica ca o do programa sem que o usu ario precise aguardar por um per odo muito longo. Com exce ca o da tabela de descri ca o de data e hora, o formato do cabe calho presente nas tabelas SI e comum a todas. Nesse cabe calho, um campo em especial determina se o elemento deve ou n ao ser amostrado: a sua vers ao. Caso uma tabela de vers ao V j a tenha sido amostrada em um instante de tempo anterior ao atual, n ao se faz necess ario que ela seja processada e agregada ao sistema de arquivos mais uma vez. Dessa forma, caso o uxo de transporte n ao traga altera co es nas vers oes das tabelas j a amostradas, n ao haver a mais demanda para a aloca ca o de mem oria por parte do DemuxFS. A tabela de descri ca o de data e hora, que n ao apresenta um campo de vers ao, e processada sempre que recebida e a mem oria usada pela sua amostra anterior e reaproveitada e sobrescrita. Para n ao comprometer a disponibilidade de mem oria RAM, 3 diferentes pol ticas podem ser adotadas na chegada de novas vers oes de tabelas j a amostradas, escolhidas pelo usu ario durante a carga do DemuxFS. S ao elas: armazena todas as vers oes recebidas, cada qual em um subdiret orio Avida: exclusivo que leva o nome da vers ao presente no cabe calho do pacote. Caso o emissor gere novas vers oes em uma taxa excessivamente alta a ponto de repetir vers oes previamente amostradas, a amostra coletada anteriormente e removida e substitu da pela nova. Um indicador no sistema de arquivos denominado Current, implementado sob a forma de um link simb olico, aponta para a nova vers ao de modo que o usu ario que analisa o conte udo saiba qual e a vers ao da tabela em vigor. Essa pol tica e conceitualmente similar ` a deni ca o de um buer circular (CORMEN et al., 2001); Moderada: idem ` a anterior, mas at e N amostras diferentes de cada tabela

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

70

s ao mantidas em mem oria; Reservada: mant em apenas a u ltima vers ao V recebida da tabela em mem oria. A vers ao V 1 e retirada da arvore do sistema de arquivos e a mem oria ocupada por ela e liberada completamente assim que todas as refer encias feitas a seus arquivos e subdiret orios forem fechadas 3 . Para garantir uma vis ao consistente do sistema de arquivos, mesmo sob diferentes pol ticas de gerenciamento de mem oria, o indicador Current e atualizado para apontar para a nova e u nica vers ao amostrada dessa tabela. As restri co es de uso de mem oria s ao tamb em aplicadas aos arquivos FIFO que representam os uxos elementares de audio, v deo e outros dados transmitidos em pacotes PES. Por meio das chamadas de sistema de congura ca o de atributos estendidos, o usu ario pode minimizar o uso de mem oria RAM ou maximizar o desempenho de um aplicativo de reprodu ca o de m dias, de acordo com a sua necessidade.

6.3

A Arquitetura de An alise de Fluxo de Dados do DemuxFS

O DemuxFS e um sistema de arquivos real implementado sobre a infraestrutura do FUSE. Todos os objetos criados e exportados pelo DemuxFS tornam-se vis veis na estrutura de diret orios e podem ser acessados por qualquer programa e usu ario. A arquitetura b asica do DemuxFS e apresentada na Figura 6.3, dividida em 5 m odulos diferentes: entrada do uxo de transporte, extra ca o, valida ca o e processamento de pacotes e representa ca o na arvore de diret orios. A arquitetura admite a entrada do uxo de transporte por duas poss veis origens: arquivos e por um sintonizador (tuner ), este u ltimo dispon vel apenas na plataforma Tall. Os elementos de entrada s ao separados em pacotes de 188 bytes e encaminhados ao m odulo de valida ca o, que determina se o pacote e pass vel de an alise ou n ao: pacotes que n ao apresentam carga u til ou que n ao contemplam o byte de sincronismo 0x47 s ao descartados. Enquanto o primeiro caso e admitido pela especica ca o do uxo de transporte do MPEG-2, o u ltimo consiste em um erro, que e reportado pelo DemuxFS em um arquivo de registro de eventos. Ap os sua valida c ao, o pacote e encaminhado para o m odulo de processamento, de onde seu conte udo ser a extra do e exposto por meio do sistema de arquivos.
3

Esse comportamento e especicado na norma POSIX

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

71

Figura 6.3: Diagrama de blocos do DemuxFS

O tratamento dado aos pacotes de informa c ao de servi co (SI) e de uxos de audio, v deo e dados e mostrado na Figura 6.4. Cada pacote recebido e armazenado em uma lista de buers indexada pelo seu n umero identicador (PID). Apenas quando todos os pacotes de uma tabela SI estiverem no buer seu conte udo e extra do e exposto no sistema de arquivos. O mesmo e v alido para hierarquias de objetos transferidas por meio de mensagens BIOP do DSM-CC: a cada bloco inserido na lista daquele PID a tabela DII e vericada para identicar se todo o conte udo j a foi recebido. Quando todos os dados j a tiverem sido armazenados no buer os arquivos e diret orios transferidos pelo carrossel de objetos s ao armazenados no disco r gido e liga c oes simb olicas s ao criadas de dentro da arvore do DemuxFS para o ponto onde eles foram gravados. O uxo de pacotes PES de v deo e audio e dados (com exce ca o dos carross eis de dados e objetos) e mais simples; o destino desses pacotes e invariavelmente um arquivo FIFO. Uma u nica exce ca o ocorre no tratamento de pacotes PES de v deo, que podem conter uma identica ca o de tamanho zero. Esse caso e ao especicado na norma do SBTVD (ABNT, 2008b), signicando que o pacote n tem um tamanho denido. Logo, pacotes de v deo recebidos dessa maneira n ao necessitam ser acumulados em um buer antes de serem encaminhados ao arquivo FIFO correspondente.

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

72

Figura 6.4: O uxo de um pacote no DemuxFS

O modo de opera ca o dos arquivos FIFO e descrito com mais detalhes na subse ca o a seguir.

6.3.1

A sem antica e o uso dos arquivos FIFO

A sem antica das opera co es nos arquivos FIFO e denida pela implementa ca o do DemuxFS e reete no desempenho do sistema de arquivos. Primeiramente, apenas um processo consumidor e admitido. A tentativa de abertura de um FIFO que j a est a em uso por outro processo e negada, e um erro indicativo de recurso ocupado e retornado ao usu ario. Essa restri c ao garante que quando um descritor de arquivo v alido for retornado em uma opera c ao de abertura de um FIFO o processo ter a acesso a todos os pacotes transferidos por esse canal. Como medida de otimiza c ao, caso o FIFO associado a um pacote PES n ao tenha sido aberto por um processo, o pacote e descartado imediatamente; nenhum ac umulo e feito no buer daquele PID e nenhum dado e repassado para o FIFO.

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

73

O atributo estendido user.buffer size proposto no cap tulo anterior e aplicado aos arquivos desse tipo. A congura ca o desse par ametro implica a modica ca o do tamanho da mem oria de armazenamento interna de um arquivo FIFO espec co, podendo reetir na percep c ao do usu ario que reproduz um uxo elementar de audio ou v deo a partir desse arquivo. Os arquivos FIFO representam dois tipos de elemento no DemuxFS: pacotes PES, presentes no uxo de transporte, e pacotes ES, que consistem na carga u til dos pacotes PES. O desencapsulamento dos pacotes PES e feito internamente pelo DemuxFS para permitir a reprodu ca o de uxos monom dia (que n ao s ao sincronizados com uma segunda m dia) e para satisfazer decodicadores que n ao interpretem o cabe calho de pacotes PES, como ocorre no hardware especializado da plataforma Tall. A manuten ca o interna dos arquivos FIFO de pacotes PES e ES e feita separadamente para cada um deles. Assim, e poss vel que um processo consuma os pacotes ES, enquanto outro processo consuma os dados trafegados no FIFO do PES, embora a restri ca o de uma u nica abertura por FIFO ainda se aplique.

6.3.2

Pr evias do Fluxo de V deo

Em diversas situa co es de an alise de uxo de transporte, a visualiza ca o de uma u nica imagem do v deo e suciente para que o usu ario identique o programa transmitido ou verique alguma condi c ao de anomalia. Imagens est aticas capturadas do v deo s ao tamb em apreciadas na gera c ao de relat orios de problemas encontrados em uma determinada emissora. A captura de uma u nica imagem, no entanto, demanda os mesmos recursos de uma decodica ca o de v deo, como a reserva exclusiva de um decodicador em hardware. Esse recurso e incorporado no DemuxFS com o aux lio de um decodicador de v deo H.264 em software provido pelo projeto FFmpeg (BELLARD, 2000). Esse decodicador integra-se ao sistema de arquivos por meio dos arquivos FIFO de pacotes ES e acrescenta mais um objeto ` a sub arvore do diret orio, denominado snapshot.ppm 4 . A abertura do arquivo de pr evia de v deo requer a leitura do conte udo transmitido no arquivo FIFO dos pacotes ES. Assim, quando o sistema de arquivos recebe uma solicita ca o de abertura do arquivo snapshot.ppm, o contador de reO PPM e um formato de representa c ao de pixels de codica c ao extremamente simples, no qual cada ponto da imagem e representado por um valor num erico em texto (ASCII). Mais informa c oes sobre esse formato podem ser encontradas em (KAY; LEVINE, 1995)
4

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

74

fer encia do arquivo FIFO associado e incrementado, impedindo sua abertura por um processo externo at e que todos os quadros necess arios para a decodica c ao de uma imagem completa tenham sido lidos. Caso o arquivo FIFO j a esteja em uso por um processo no momento da abertura do arquivo snapshot.ppm, um erro informando que o recurso est a ocupado e retornado para a aplica ca o solicitante.

6.3.3

Organiza c ao da Estrutura de Diret orios

A an alise do uxo de transporte do SBTVD e feita no DemuxFS por meio da listagem e leitura de diret orios e arquivos e de seus atributos estendidos, dispostos hierarquicamente conforme a estrutura l ogica de cada tabela. O primeiro n vel (n = 0) e composto unicamente por diret orios, cada qual representando uma tabela de informa c ao de servi co, um uxo elementar ou uma sub arvore transmitida pelos carross eis de dados e objetos. Duas exce c oes s ao feitas para os diret orios /Report e /Streams, que n ao abrigam diretamente o conte udo de uma tabela espec ca. No primeiro se encontram relat orios de erros e avisos emitidos pelo DemuxFS, que possibilitam a visualiza ca o dos eventos conforme um ordenamento temporal, enquanto no segundo s ao encontradas liga c oes simb olicas para os diret orios do DemuxFS que abrigam uxos elementares de audio, v deo e dados. Esses diret orios s ao expandidos na Figura 6.5 5 .

Figura 6.5: Os diret orios /Reports e /Streams expandidos

Salvo os diret orios supramencionados, os elementos expostos no segundo n vel s ao denidos segundo tr es regras, aplicadas de acordo com as caracter sticas da tabela representada e com o conte udo do diret orio. Essas caracter sticas, listadas a seguir, podem ser acompanhadas na Figura 6.6:
5

As liga c oes simb olicas est ao listando origem e destino separados por uma seta (->)

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

75

Tabelas que n ao incluem um campo de informa ca o de vers ao: cont em apenas um diret orio denominado Current, dentro do qual os arquivos e diret orios associados ` a tabela se encontram. Esse e o caso da tabela de data e hor ario (TOT); Tabelas que incluem um campo de informa c ao de vers ao: cada vers ao da tabela recebida e armazenada em um diret orio separado. Uma liga ca o simb olica denominada Current e tamb em criada, apontando para o diret orio da u ltima vers ao recebida. Esse e o caso de tabelas como PAT, NIT e SDT; Diret orios de agrupamento: esse tipo de diret orio tem como nalidade agrupar todas as tabelas de um mesmo tipo recebidas no uxo de transporte, como a PMT. O diret orio principal recebe o nome da tabela em quest ao e abriga subdiret orios que levam como nome o PID de cada uma das tabelas que o comp oem. Dentro dos diret orios de PID a organiza c ao baseada em vers oes e em uma liga ca o simb olica para a u ltima vers ao recebida se aplica.

Figura 6.6: O segundo n vel hier arquico do DemuxFS

A estrutura ca o da arvore de diret orios dessa maneira traz uma coer encia estrutural de grande valia para a busca de elementos espec cos do uxo de transporte, visto que seu estado atual pode ser sempre encontrado dentro dos objetos Current. Assim cada diret orio cont em os dados que dizem respeito ` aquela tabela, como seus atributos e descritores. A seguir, algumas das tabelas que apresentam

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

76

caracter sticas peculiares quanto ao uso de liga co es simb olicas, atributos estendidos e formata c ao de seus dados s ao apresentadas. 6.3.3.1 Organiza c ao do Diret orio da Tabela PAT

Todas as tabelas de informa ca o de servi co s ao precedidas de um cabe calho em comum que apresenta informa co es quanto ` a sua identica ca o (expostos no DemuxFS dentro do diret orio tableHeader pelos arquivos table id e identifier), seu tamanho (section length), vers ao (version number) e n umero de se ca o (section number e last section number). Encontram-se tamb em nesse diret orio os atributos current next indicator, que indica se a informa ca o trazida na tabela deve ser imediatamente aplicada ou n ao, e o section syntax indicator, que deve ser um valor constante xado em 1. Alguns campos de uso reservado s ao tamb em encontrados nesse cabe calho, por em seus valores n ao devem afetar a decodica c ao ou a correta interpreta ca o de uma tabela de servi co. Por essa raz ao, eles n ao s ao expostos pelo sistema de arquivos.

Figura 6.7: O subdiret orio Programs da tabela PAT

A nalidade da tabela PAT e indicar o pacote que cont em a deni ca o atual da tabela de descri c ao de rede (NIT) e o mapeamento dos programas transmitidos pela emissora (PMT). Assim, al em dos arquivos comuns entre as tabelas de informa ca o de servi co, o diret orio da tabela PAT cont em um subdiret orio exclusivo denominado Programs, dentro do qual encontram-se uma liga ca o simb olica para o diret orio onde a tabela NIT atual est a armazenada e uma ou mais liga co es para cada um dos programas esperados nas tabelas PMT. A Figura 6.7 mostra como e feita a composi c ao dos alvos desses objetos.

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

77

6.3.3.2

Organiza c ao do Diret orio da Tabela PMT

A tabela PMT descreve os uxos elementares que devem ser combinados para formar um programa. S ao tamb em transferidos na PMT pacotes privados, que dizem respeito apenas a uma emissora em especial, e pacotes de carross eis de dados e de objetos. A variedade de dados que podem ser transmitidos na PMT leva a cria ca o de subdiret orios espec cos, como mostra a Figura 6.8. Cada uxo elementar e listado em um diret orio dedicado que leva o nome do PID que o transporta.

Figura 6.8: A composi c ao da tabela PMT no DemuxFS

Para facilitar a depura ca o de uxos de transporte, uma liga c ao simb olica denominada Primary indica os uxos elementares de audio, v deo e legenda de prioridade m axima, que devem ser reproduzidos por padr ao caso n ao haja interven c ao do usu ario na congura ca o do terminal de acesso. Caso haja mais de uma op ca o, uma liga ca o denominada Secondary e criada pelo DemuxFS, apontando para o uxo de segunda prioridade, conforme as regras estabelecidas pelo SBTVD para sua determina c ao. Essas liga c oes simb olicas n ao s ao geradas para os uxos de carrossel e de uso reservado da emissora pois seu tratamento n ao requer esse tipo de classica ca o.

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

78

Os uxos de audio e v deo destinados ` a reprodu ca o em dispositivos port ateis s ao diferenciados dos outros pela adi ca o do suxo -OneSeg 6 ao nome do diret orio, conforme indica a Figura 6.9. Essa gura tamb em introduz alguns importantes elementos do DemuxFS: a representa c ao de descritores, os arquivos FIFO e os arquivos de pr evia de v deo (snapshots ), explicados a seguir.

Figura 6.9: A descri ca o de uxos elementares de audio e v deo na PMT

Cada descritor presente em uma tabela do uxo de transporte e armazenado em um diret orio especial, mesmo que ele consista em apenas um atributo. O nome do diret orio e denido conforme o campo descriptor tag da tabela e e sempre representado em caracteres ma usculos. Como regra geral, sempre que houver como interpretar os dados de um descritor, tanto a representa c ao interpretada quanto a num erica constar a nos dados retornados na opera ca o de leitura do arEsse tipo de receptor e somente capaz de receber e decodicar sinais de perl b asico de TV digital, de um segmento. Dispositivos n ao-port ateis possibilitam a decodica c ao de m dias em 13 segmentos (ABNT, 2008c).
6

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

79

quivo. O exemplo da Figura 6.10 mostra o conte udo do arquivo component tag do uxo elementar de audio do PID 0x212 e o formato indicado pelo atributo estendido system.format. Enfatiza-se a estrutura do arquivo, formado pelo valor interpretado e seguido pelo valor num erico encontrado na tabela entre colchetes. $ getfattr STREAM_IDENTIFIER/component_tag system.format=string [number] $ cat STREAM_IDENTIFIER/component_tag Primary one-seg audio stream [0x83] Figura 6.10: Formata c ao de um arquivo conforme indicado em seu atributo estendido Os arquivos denominados ES e PES encontrados nos diret orios de audio e v deo representam os FIFOs do uxo elementar, por meio do qual uma aplica c ao pode ter acesso para sua decodica ca o, inspe ca o ou c opia. Como o tamanho desses arquivos e indenido, visto que a gera ca o do conte udo destes e potencialmente innita, cabe ` a aplica ca o que os l e determinar quando a leitura deve terminar. A leitura dos arquivos ES e de pr evia de v deo (snapshot.ppm) est a condicionada ` a disponibilidade do arquivo PES, por meio do qual o seu conte udo e gerado. Caso o arquivo PES j a esteja em uso por algum outro processo a abertura do arquivo snapshot.ppm e negada pelo DemuxFS. Ap os a abertura dos arquivos PES e ES, a primeira opera ca o de leitura garante que os primeiros valores lidos estejam sempre alinhados com o in cio de um pacote como no exemplo da Figura 6.11, em que os primeiros 4 bytes lidos cont em o cabe calho de um pacote PES de v deo, iniciado por 00 00 01 0e. Isso facilita o reconhecimento e o tratamento do conte udo extra do dos arquivos FIFO por outras aplica co es. 6.3.3.3 Organiza c ao do Diret orio da Tabela TOT

a A tabela TOT e usada pelas emissoras para enviar a data e hora atual. E partir desse valor de refer encia que outras tabelas de descri ca o de eventos s ao transmitidas, informando o hor ario de in cio e t ermino de cada programa na grade de programa ca o do canal. Al em disso, o valor da tabela TOT enviado por diferentes emissoras pode diferir por variadas raz oes, o que torna a interpreta c ao dessa tabela importante. Alguns dos problemas que podem ser resolvidos a partir da compreens ao do valor da TOT incluem a exibi ca o da data e hora nas tarjas de navega ca o da TV, o agendamento da grava c ao de um programa e o c alculo do

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

80

$ hexdump 00000000 00000010 00000020 00000030 00000040 00000050 00000060 00000070 ...

PMT/0x20/Current/VideoStreams/0x111/PES 00 00 01 e0 00 00 84 80 05 21 1a 25 5d 00 01 09 50 00 00 00 01 28 fa 43 cb 00 01 07 00 00 0a 00 00 03 00 14 02 02 be 00 00 01 01 9e 14 29 1f fc d6 ff 63 e7 32 33 72 6d b3 96 a8 72 da 40 73 2b f3 38 4d 3b e9 47 f2 dd 26 cd 00 bd 5c 3e 9f 94 0d de 3e 72 d1 aa 85 8d 11 48 92 d9 aa 85 41 e9 39 54 9b 60 8f c0 1f 77

6d 00 a0 3e 90 a6 59 0d

00 01 80 55 0f dd 6c 85

00 06 00 03 30 b5 ba 66

$ file PMT/0x20/Current/VideoStreams/0x111/PES PES: MPEG sequence Figura 6.11: Alinhamento dos arquivos FIFO com o cabe calho de pacotes PES tempo de dura ca o de um evento ou programa espec co. $ getfattr TOT/Current/ut3c_time system.format=string [number] $ cat TOT/Current/utc3_time Fri Dec 19 06:45:44 2008 [0xd623064544] Figura 6.12: Representa c ao de data e hora no DemuxFS Para facilitar a an alise da tabela TOT, o valor num erico de 40 bits utc3 time e convertido para um formato em texto compreens vel. Esse formato, juntamente com o valor original, e obtido na opera c ao de leitura do arquivo, como mostra a Figura 6.12. 6.3.3.4 Organiza c ao do Diret orio das Tabelas DII e DDB

A integra c ao do DemuxFS com a arvore de diret orios transmitida nos carross eis de dados e objetos e feita a partir da an alise da pilha de protocolos do DSM-CC. Duas tabelas s ao processadas para que os elementos do carrossel transmitidos no uxo de transporte possam ser expostos conforme a hierarquia estipulada no cabe calho das mensagens BIOP: a tabela DII e a tabela DDB. O recebimento da tabela DII, que indica os blocos que comp oem um determinado objeto, resulta na cria ca o de um diret orio DII na raiz do sistema de arquivos e de n subdiret orios denominados module i para cada m odulo i, 0 i<n, recebido no carrossel. Cada subdiret orio cont em arquivos que identicam e descrevem o tamanho e a vers ao do m odulo em quest ao. A recep ca o e a uni ao dos pacotes

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

81

DDB transmitidos conforme a descri ca o desses m odulos permite a reconstru ca o da hierarquia original, que ca exposta dentro de um diret orio denominado DSMCC, em um subdiret orio que leva o nome do programa interativo, obtido a partir das informa c oes de uma outra tabela denominada AIT (do ingl es Application Information Table, ou Tabela de Informa ca o da Aplica ca o).

Figura 6.13: Tabelas DII e DDB, com expans ao do sistema de arquivos do DSM-CC A tabela DDB e tamb em armazenada em um diret orio DDB na raiz do sistema de arquivos. Duas formas de representa c ao do conte udo transportado na tabela DDB s ao oferecidas pelo DemuxFS, permitindo a depura ca o dos arquivos transmitidos nas mensagens BIOP ou a verica c ao de consist encia de cada m odulo e bloco dos carross eis de dados e objetos. Na primeira op ca o, a arvore completa descrita no protocolo DSM-CC e extra da e armazenada em um diret orio persistente estipulado pelo usu ario, apontado no sistema de arquivos do DemuxFS pela liga ca o simb olica denominada DSM-CC. Esse cen ario e mostrado na Figura 6.13. Na segunda op ca o, n ao h a expans ao da arvore de diret orios do DSM-CC. Nesse caso, cada m odulo i recebido e armazenado em um diret orio module i e cada

6.3 A Arquitetura de An alise de Fluxo de Dados do DemuxFS

82

Figura 6.14: Tabela DDB, sem expans ao do sistema de arquivos do DSM-CC

um dos blocos j que comp oem esse m odulo e exibido em module i /block j .bin. Uma liga c ao e tamb em usada para a area persistente, visto que o tamanho dos dados transferidos pode ultrapassar os limites de mem oria RAM dispon veis na plataforma hospedeira do DemuxFS. A Figura 6.14 mostra a organiza c ao da hierarquia segundo esse crit erio. Em ambos os casos, duas liga co es simb olicas s ao criadas no DemuxFS. A primeira ca dentro do diret orio da PMT que anuncia as tabelas de carrossel de dados ou objeto, apontando para o diret orio /DDB/<PID>/<Vers~ ao>, enquanto a segunda e criada no diret orio /Streams, apontando para o diret orio da PMT. Com essas liga co es simb olicas todas as informa co es referente a um programa espec co cam dispon veis em um ponto central (o diret orio da PMT), ao mesmo tempo em que todos os uxos elementares de audio, v deo e dados transmitidos cam convenientemente centralizados em outro diret orio (/Streams), facilitando a localiza c ao de dados frequentemente observados.

6.3.4

Medidas M etricas para An alise Quantitativas

Um diret orio denominado Reports abriga na estrutura do DemuxFS relat orios indicativos de erros e avisos gerados durante o processamento dos pacotes do uxo de transporte. Cada evento e acompanhado da data e hora, tornando poss vel a gera ca o de gr acos desses eventos em fun c ao do tempo ou a obten c ao da taxa

6.4 S ntese

83

m edia de erros de integridade de pacotes, por exemplo. Nota-se, no entanto, que n ao existe integra ca o autom atica do DemuxFS com ferramentas de tra co de gr acos. Essa funcionalidade requer que uma aplica ca o extraia a informa c ao que for considerada relevante dos arquivos de relat orio para que ent ao os dados sejam encaminhados a uma biblioteca ou programa apropriado.

6.4

S ntese

Neste cap tulo foi apresentado o DemuxFS, uma implementa ca o de refer encia do sistema de arquivos para a an alise do uxo de transporte do SBTVD. Com o DemuxFS se mostrou ser poss vel expor os objetos de an alise mais comuns ou desej aveis em uma aplica ca o especializada por meio de conceitos simples e padronizados, validando a arquitetura proposta. Gra cas ` a escolha de uma plataforma de desenvolvimento em espa co de usu ario (FUSE) foi poss vel integrar um recurso de decodica c ao de v deo em software, permitindo a visualiza ca o imediata do quadro de v deo transmitido naquele instante, sem que seja necess ario um decodicador em hardware ou uma plataforma com alto poder de processamento para decodicar o uxo de v deo continuamente. Ainda assim o acesso direto aos uxos elementares e oferecido, por meio dos arquivos FIFO, possibilitando sua aquisi ca o ou reprodu ca o cont nua por software ou hardware, dependendo das capacidades da plataforma e seus decodicadores. Essas funcionalidades permitem que a arquitetura proposta seja utilizada para nalidades al em da an alise de dados, uma vez que sua infraestrutura acolhe os recursos necess arios para a implementa ca o de um sistema completo de um receptor de TV digital. Com a inclus ao do suporte a uma plataforma de hardware dedicada de desenvolvimento nacional, a valida ca o e an alise de uxos de transporte pode ser feitas em tempo real pelo pr oprio dispositivo utilizado para assistir TV. Este e um grande diferencial da implementa ca o realizada, considerando a inexist encia desse tipo de recurso em produtos comerciais encontrados no mercado. Espera-se com o DemuxFS que um novo conceito em servi co seja agregado aos terminais de acesso de TV digital, tornando o acesso aos elementos transmitidos no uxo de transporte trivial e universal.

84

Conclus oes

Fluxos de dados estruturados apresentam um fator especialmente importante para a sua an alise: a informa c ao transmitida e potencialmente innita. Essa caracter stica leva ` a necessidade da aplica ca o de t ecnicas que permitam extrair os elementos essenciais sem acarretar um impacto negativo no desempenho da an alise ou nos padr oes de uso de mem oria do receptor. Este trabalho apresentou uma proposta de arquitetura para a an alise de uxo de dados estruturados, na qual cada elemento estruturado e mapeado a um conjunto de arquivos e diret orios. A leitura de metadados e a realiza c ao de opera c oes especiais s ao poss veis por meio de opera co es padronizadas sobre esses tipos de objeto. A deni c ao de arquivos e regras especiais para lidar com elementos de grande vaz ao mostrou que essa arquitetura pode se aplicar ` a an alise de sistemas multim dia, como o adotado pelo Sistema Brasileiro de TV Digital (SBTVD).

7.1

Contribui co es

A arquitetura proposta traz uma contribui ca o concreta ` a area pela sua originalidade. A literatura aponta ferramentas similares, embora n ao haja um compromisso destas com a representa c ao dos elementos analisados em formatos port aveis e interoper aveis. A disponibilidade de uma implementa ca o de uma arquitetura poderosa de an alise de uxo de dados estruturados e original por permitir o tratamento de uxos de dados complexos, como o SBTVD, usando ferramentas padronizadas para a manipula ca o de sistemas de arquivos. Para a valida ca o desta proposta, um sistema de arquivos para a an alise do uxo de transporte do SBTVD foi implementado. A simplicidade na qual a informa ca o hier arquica de cada elemento e acessada mostrou que essa arquitetura e vi avel e escal avel. Al em disso, a possibilidade de execu ca o em uma plataforma de TV digital dedicada e de produ c ao nacional permite incorporar essa funcionalidade a produtos de f acil acesso e de baixo custo, facilitando a an alise de uxos de transporte em diferentes pontos do pa s.

7.2 Trabalhos futuros

85

Outra contribui ca o relevante deste trabalho e o pr oprio sistema de arquivos implementado. O DemuxFS, distribu do sob uma licen ca de software livre 1 , possibilita a an alise de uxos de transporte transmitidos por emissoras homologadas para transmiss ao no territ orio brasileiro e representa uma importante adi c ao para a comunidade acad emica e tecnol ogica. Dessa forma, a relev ancia deste trabalho no contexto do SBTVD e um dos seus principais m eritos.

7.2

Trabalhos futuros

Junto ` a sua implementa ca o de refer encia, essa arquitetura abre diversas op c oes de trabalhos futuros, sejam na forma de extens oes da ferramenta desenvolvida ou no acoplamento de m odulos para a an alise dos elementos disponibilizados nos objetos do tipo FIFO do sistema de arquivos como analisadores de protocolos de audio, v deo e legendas. A arquitetura permite ainda que outras fontes de entrada de dados sejam utilizadas, tornando poss vel a an alise de uxos de transporte oriundos da camada de rede, por exemplo. Dessa forma, um trabalho derivado de bastante relev ancia para o cen ario de TV digital encontra-se na adi c ao de suporte a tecnologias de Televis ao sobre IP, tamb em chamado de IPTV, na qual o uxo de transporte e encapsulado em outros protocolos como o IGMP (do ingl es Internet Group Management Protocol, ou Protocolo de Gerenciamento de Grupos na Internet) e o RTSP (Real Time Streaming Protocol, ou Protocolo de Fluxo de Dados em Tempo Real) (SILVERSTON et al., 2009). A arquitetura proposta pode tamb em ser estendida para permitir a escrita em determinados arquivos e diret orios para criar uxos de transporte derivados daquele recebido pelo m odulo de aquisi c ao de dados. Esse processo, conhecido como remultiplexa ca o, permite a simula c ao (ou corre c ao) de erros e a inclus ao de dados adicionais, como programas interativos, que n ao se encontravam no uxo de transporte original. HIRAYAMA e Silveira (2006) apresenta alguns dos problemas relacionados a este tema que precisam ser considerados ao se produzir uxos de transporte derivados de um outro. Mostra-se fact vel tamb em o desenvolvimento de aplica co es interativas de reprodu ca o de m dias digitais acerca da infraestrutura do DemuxFS, visto que toda a informa c ao necess aria por aplica c oes deste g enero se encontram para f acil acesso no sistema de arquivos exposto.
1

O c odigo fonte do projeto est a dispon vel em http://demuxfs.sourceforge.net

7.2 Trabalhos futuros

86

Este t opicos est ao diretamente alinhados com as linhas de pesquisa do Laborat orio do Sistemas Integr aveis da USP e devem se concretizar em projetos no decorrer dos pr oximos anos.

87

Anexo A -- Atributos Estendidos em Sistemas de Arquivos Legados

A deni ca o de interfaces de programa ca o port aveis para a implementa ca o de atributos estendidos em sistemas operacionais s o ocorreu com a publica ca o, em 1998, do padr ao POSIX 1003.1e, que trata de interfaces para listas de controle de acesso, separa c ao de privil egios de usu arios, controle de acesso mandat orio e mecanismos para rotular informa c oes (IEEE, 2001). Dessa forma, diversos sistemas de arquivos legados n ao contemplam um suporte efetivo a esse recurso. Esse e o caso do FAT32, que se tornou um padr ao de fato devido ` a popularidade do sistema operacional que o originou. A especica ca o do formato em disco do sistema de arquivos FAT32, descrita em (MICROSOFT, 2000), foi feita com base no FAT16 e FAT12, desenvolvidos originalmente pelo sistema de arquivos Microsoft MS-DOS em meados de 1980. A diferen ca b asica entre esses arquivos e a raz ao para seus nomes e o tamanho, em bits, dos objetos presentes na estrutura FAT em disco. S ao 12 bits para um objeto na FAT12, 16 bits para um objeto na FAT16 e 32 na FAT32. Duas estruturas de dados s ao contempladas e compartilhadas nos formato FAT12, FAT16 e FAT32: a estrutura FAT, que abriga informa c oes quanto ao volume (seu formato, capacidade, identica c ao e outros pertinentes ao setor de boot), e a estrutura de diret orios, que cont em dados como o nome do objeto, seus atributos de acesso (modo leitura, oculto, de sistema), o endere co f sico onde se encontra o primeiro agrupamento de dados (cluster ) desse objeto e estampas de tempo, que indicam a data e hora de sua cria ca o, modica ca o e quando ocorreu au ltima leitura de seu conte udo. O formato da estrutura de diret orios do FAT e denido conforme mostra a co es Listagem A.1 1 , na qual enfatiza-se a o membro clusterHigh. Pelas limita impostas ao tamanho m aximo dos objetos presentes no disco, tanto o FAT12
Os tipos de dados uint8 t, uint16 t e uint32 t denem vari aveis de tamanho de 1, 2 e 4 bytes, respectivamente. O tamanho do tipo char e tamb em de 8 bytes.
1

Anexo A -- Atributos Estendidos em Sistemas de Arquivos Legados

88

quanto o FAT16 n ao utilizam o espa co reservado para essa vari avel 2 , o que possibilita o seu uso para nalidades mais nobres. Listagem A.1: Estrutura de diret orios do FAT struct f a t d e n t r y { { char char uint8 t uint8 t uint8 t name [ 8 ] ; ext [ 3 ] ; attribute ; reserved ; / Nome do a r q u i v o / / Extens a o do nome / / M a scara de a t r i b u t o s / / Reservado / / Hora de c r i a c a o ( s e g ) / / Data de c r i a c a o / / Data de u l t i m o a c e s s o / / Endere c o a l t o do 1o c l u s t e r / / Hora de u ltima atualiza c a o / / Data de u ltima atualiza c a o / / Endere c o b a i x o do 1o c l u s t e r / / Tamanho em b y t e s /

createTimeMs ; / Hora de c r i a c a o (ms) /

u i n t 1 6 t createTime ; uint16 t createDate ; uint16 t accessDate ; uint16 t clusterHigh ; u i n t 1 6 t updateTime ; u i n t 1 6 t updateDate ; uint16 t clusterLow ; uint32 t size ; };

O campo de uso livre passou a ser utilizado pelo sistema operacional IBM OS/2 para implementar o recurso de atributos estendidos, que j a estava presente em seu sistema de arquivos HPFS (High Performance File System ). Os 2 bytes livres foram usados para indexar o primeiro de uma lista de clusters no disco que armazenam os atributos estendidos do arquivo. No entanto, essa lista n ao pode ser simplesmente gravada em unidades l ogicas livres pois, por n ao fazerem parte da lista encadeada iniciada no endere co indicado por clusterLow, o sistema de arquivos ainda os considera como blocos livres, possibilitando a perda de metadados caso eles sejam atribu dos para uso pelo sistema de arquivos. A solu c ao encontrada para armazen a-los de forma persistente e segura foi associar cada cluster de atributo estendido a um arquivo real 3 , que os mant em em uma lista encadeada iniciada no endere co v alido clusterLow. No sistema de arquivos FAT32 os 2 bytes do clusterHigh s ao usados para compor o endere co dos objetos no disco, que podem ser indexados de 0 bytes a 4
2 Sua exist encia, bem como a do campo reservado, se justica pela proje c ao da estrutura de diret orios FAT com base no sistema de arquivos do CP/M, que a utilizava para descrever a localiza c ao no disco dos clusters que compunham um arquivo. 3 Esse arquivo tradicionalmente recebe o nome de EA DATA.SF nos sistemas que o implementam.

Anexo A -- Atributos Estendidos em Sistemas de Arquivos Legados

89

GiB. Como a estrutura de diret orios do FAT e compartilhada pelo FAT12, FAT16 e FAT32, n ao existe, at e a presente data, uma maneira segura para armazenar atributos estendidos nesse sistema de arquivos.

90

Anexo B -- Disponibilidade do C odigo Fonte do DemuxFS

O c odigo fonte da implementa c ao de refer encia apresentada nesta disserta ca o encontra-se no CD-ROM em anexo. A sua vers ao mais recente pode ser sempre obtida no endere co de internet http://demuxfs.sourceforge.net.

91

Refer encias Bibliogr acas

ABNT. ABNT NBR 15603-2: Televis ao digital terrestre - Multiplexa c ao e servi cos de informa c ao (SI). Parte 2: Sintaxes e deni c oes da informa c ao b asica de SI. Rio de Janeiro, 2007. ABNT. ABNT NBR 15606-3: Televis ao digital terrestre - Codica c ao de dados e especica c oes de transmiss ao para radiodifus ao digital. Parte 3: Especica c ao de transmiss ao de dados. Rio de Janeiro, 2007. ABNT. ABNT NBR 15601: Televis ao digital terrestre - Sistema de transmiss ao. Rio de Janeiro, 2008. ABNT. ABNT NBR 15602-3: Televis ao digital terrestre - Codica c ao de v deo, audio e multiplexa c ao. Parte 3: Sistemas de multiplexa c ao de sinais. Rio de Janeiro, 2008. ABNT. ABNT NBR 15604: Televis ao digital terrestre - Receptores. Rio de Janeiro, 2008. ABNT. ABNT NBR 15608-2: Televis ao digital terrestre - Guia de opera c ao. Parte 2: Codica c ao de v deo, audio e multiplexa c ao - Guia para implementa c ao da NBR 15602:2007. Rio de Janeiro, 2008. ARIB. Service Information for Digital Transmission System ARIB STD-B10, version 4.6. Nittochi Bldg. 11F, 1-4-1, Kasumigaseki, Chiyoda-ku, Tokyo 100-0013, Japan, 2008. ATSC. ATSC Digital Television Standard Part 1: Digital Television System (A/53, Part 1:2007). 1750 K Street, N.W., Suite 1200, Washington, D.C. 20006, 2007. BEDICKS JR, G. Sintonizador-demodulador para o sistema brasileiro de TV Digital. Tese (Doutorado) Escola Polit ecnica da Universidade de S ao Paulo, Av. Prof. Luciano Gualberto, 158, Trav. 3 - Butant a, S ao Paulo/SP, Brasil, 2008. BELLARD, F. FFmpeg. 2000. Dispon vel em: <http://mpeg.org>. Acesso em: 01 de Mar co de 2009. BENVENUTI, C. Understanding Linux Network Internals. [S.l.]: OReilly Media, Inc., 2005. ISBN 0596002556. BRODER, A. Z. et al. Min-wise independent permutations. Journal of Computer and System Sciences, v. 60, n. 3, p. 630659, 2000. CARVALHO, E. R. de. Uma Plataforma Modular para Testes com Interatividade na TV Digital Brasileira. Disserta c ao (Mestrado) Escola Polit ecnica da Universidade de S ao Paulo, Av. Prof. Luciano Gualberto, 158, Trav. 3 - Butant a, S ao Paulo/SP, Brasil, Jul 2008.

Refer encias Bibliogr acas

92

CHERNOCK, R. S. et al. Data Broadcasting: Understanding the ATSC Data Broadcast Standard. New York, NY, EUA: McGraw-Hill Professional, 2001. ISBN 0071375902, 9780071375900. CORMEN, T. H. et al. Introduction to Algorithms, Second Edition. [S.l.]: The MIT Press, 2001. Paperback. ISBN 0-262-53196-8. CORMODE, G. Fundamentals of analyzing and mining data streams. European Workshop on Data Stream Analysis, San Leucio, Italy, Mar 2007. CORMODE, G.; MUTHUKRISHNAN, S. An improved data stream summary: The count-min sketch and its applications. LATIN 2004: Theoretical Informatics, p. 2938, 2004. CRANOR, C. et al. Gigascope: A stream database for network applications. In: Proceedings of the 8th ACM SIGMOD Workshop on Research Issues in Data Mining and Knowledge Discovery. New York, NY, USA: ACM, 2003. p. 11. DEKTEC. DTC-320 StreamXpert. Van Riebeeckweg 43A - 1212 EH Hilversum, Holanda: DekTec Digital Video BV, Mai 2006. Dispon vel em: <http://www.dektec.com>. Acesso em: 01 de Mar co de 2009. DIMITROPOULOS, X. et al. The eternal sunshine of the sketch data structure. Comput. Netw., Elsevier North-Holland, Inc., New York, NY, USA, v. 52, n. 17, p. 32483257, 2008. ISSN 1389-1286. DRISCOLL, E.; BEAVERS, J.; TOKUDA, H. FUSE-NT: Userspace File Systems for Windows NT. 2008. Dispon vel em: <http://pages.cs.wisc.edu/ driscoll/fusent.pdf>. Acesso em: 01 de Mar co de 2009. ELECARD. Elecard Stream Analyzer. 1700 South Amphlett Blvd, Suite 200. San Mateo, CA 94402, EUA: [s.n.], Jul 2006. Dispon vel em: <http://www.elecard.com>. Acesso em: 01 de Mar co de 2009. ETSI. Digital Video Broadcasting (DVB): Framing structure, channel coding and modulation for 11/12 GHz satellite services. European Telecommunications Standards Institute. 650 Route des Lucioles - Sophia Antipolis. Valbonne, FRANCE, 1997. GIRAO, G. et al. Implementation of a HDTV transport stream multiplexer based on ITU-T H.222.0 recommendation. In: WebMedia 05: Proceedings of the 11th Brazilian Symposium on Multimedia and the web. New York, NY, EUA: ACM, 2005. p. 19. HANKERSON, D. R.; JOHNSON, P. D.; HARRIS, G. A. Introduction to Information Theory and Data Compression. London, UK, UK: Chapman & Hall, Ltd., 2003. ISBN 1584883138. HIRAYAMA, R. M.; SILVEIRA, R. M. Framework para testes e avalia c ao de sincronismo para aplica c oes de TV digital m ovel. Disserta ca o (M.Sc.) University of S ao Paulo, S ao Paulo, 2006. Dispon vel em: <http://www.teses.usp.br/teses/disponiveis/3/3141/tde-19092006-172310/>. IEEE. IEEE Standard for Information Technology: Portable Operating Sytem Interface (POSIX). Part 1: System Interface. 1109 Spring Street, Suite 300, Silver Spring, MD 20910, USA: IEEE Standards Association, 2001.

Refer encias Bibliogr acas

93

INFANTE, S.; NASIOPOULOS, P. Real-time DVB-MHP interactive data transcoding to blu-ray. International Journal of Digital Multimedia Broadcasting, v. 2008, p. 18, 2008. ISO. ISO 8879:1986, Information processing Text and oce systems Standard Generalized Markup Language (SGML). Geneva, Switzerland: International Organization for Standardization, 1996. ISO. ISO/IEC 13818-1, Information Technology Generic Coding of Moving Pictures and Associated Audio Information: Systems. Geneva, Switzerland: International Organization for Standardization, 1996. ISO. ISO/IEC 13818-2, Information Technology Generic Coding of Moving Pictures and Associated Audio Information: Video. Geneva, Switzerland: International Organization for Standardization, 1996. ISO. ISO/IEC 13818-6, Information Technology Generic Coding of Moving Pictures and Associated Audio Information: Extensions for DSM-CC. Geneva, Switzerland: International Organization for Standardization, 1996. ISO/IEC. ISO/IEC 26300:2006, Information technology Open Document Format for Oce Applications (OpenDocument) v1.0. Geneva, Switzerland: International Organization for Standardization, 2006. ITU-T. H.264 : Advanced video coding for generic audiovisual services. Place des Nations, 1211 Geneva 20, Switzerland, 2007. KAMINA, T.; TAMAI, T. Embedding XML processing toolkit on general purpose programming language. Asia-Pacic Software Engineering Conference, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 159, 2002. ISSN 1530-1362. KAY, D. C.; LEVINE, J. R. Graphics Files Formats. 2. ed. New York: Windcrest/McGraw-Hill, 1995. ISBN 0-07-034025-0. KILLIAN, T. J. Processes as les. In: Proceedings of the USENIX Summer Conference. Salt Lake City, Utah: USENIX Association, 1984. p. 203207. LEWKOWICZ, J. M. The complete MUMPS: an introduction and reference manual for the MUMPS programming language. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1989. ISBN 0-13-162125-4. MATTHEW, T. Gb2393069: Monitoring program map tables of a compressed transport stream. Mar 2004. Dispon vel em: <http://www.wikipatents.com/gb/2393069.html>. Acesso em: 01 de Mar co de 2009. MATTHEW, T. Gb2393070: Monitoring service description tables of a compressed transport stream. Mar 2004. Dispon vel em: <http://www.wikipatents.com/gb/2393070.html>. Acesso em: 01 de Mar co de 2009. MCDOUGALL, R.; MAURO, J. Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture. Second. Upper Saddle River, NJ, USA: Sun Microsystems Press/Prentice Hall, 2007. 1072 p. ISBN 0-13-148209-2 (hardback).

Refer encias Bibliogr acas

94

MICROSOFT. FAT32 File System Specication FAT: General overview of on-disk format, version 1.03. Dez 2000. Dispon vel em: <www.microsoft.com/whdc/system/platform/rmware/fatgen.mspx>. Acesso em: 01 de Mar co de 2009. MUHAMMAD, H. H.; DETSCH, A. Uma nova proposta para a arvore de diret orios unix. In: UNIVERSIDADE DO VALE DO RIO DO SINOS. III Workshop sobre Software Livre (WSL2002). [S.l.], 2002. MUTHUKRISHNAN, S. Data streams: algorithms and applications. In: SODA 03: Proceedings of the fourteenth annual ACM-SIAM symposium on Discrete algorithms. Philadelphia, PA, USA: Society for Industrial and Applied Mathematics, 2003. p. 413413. ISBN 0-89871-538-5. MUTHUKRISHNAN, S. Data Streams: Algorithms and Applications. [S.l.]: Now Publishers Inc, 2005. ISBN 193301914X. OFFICE, A. P. The Patents and Designs Journal. Newport, South Wales NP10 8QQ, 2004. Edi c ao n umero 5991. PEREIRA, M. M. et al. Projeto e implementa c ao de um multiplexador de transport streams com suporte a HDTV. In: IV Workshop T ecnico Cient co do DIMAp. [S.l.]: Natal: EDUFRN, 2005. p. 4859. PIKE, R. et al. Plan 9 from bell labs. In: Proceedings of the Summer 1990 UKUUG Conference. Buntingford, UK: UKUUG, 1990. p. 19. ISBN 0-9513181-7-9. PIKE, R. et al. The use of name spaces in plan 9. In: EW 5: Proceedings of the 5th Workshop on ACM SIGOPS European Workshop: Models and paradigms for distributed systems structuring. New York, NY, EUA: ACM, 1992. p. 15. SCHERG, R. DVB Snoop. 2001. Dispon vel em: <http://dvbsnoop.sourceforge.net>. Acesso em: 01 de Mar co de 2009. SGI. IRIX Admin: Disks and Filesystems. [S.l.]: Silicon Graphics Inc., 1996. IRIX 6.2 Reference Manual, Document Number: 007- 2825-001. SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. Operating System Concepts. 7th. ed. Hoboken, NJ, EUA: John Wiley & Sons, Inc., 2004. ISBN 0-471-69466-5. SILVERSTON, T. et al. Trac analysis of peer-to-peer IPTV communities. Computer Networks, v. 53, n. 4, p. 470484, 2009. SINGH, A. Mac OS X Internals: A Systems Approach. 3rd. ed. Upper Saddle River, NJ, EUA: Addison-Wesley Professional, 2006. ISBN 0-321-27854-2. SZEREDI, M. File system in user space (FUSE). 2009. Dispon vel em: <http://fuse.sourgeforge.net>. Acesso em: 01 de Mar co de 2009. VITTER, J. S. Random sampling with a reservoir. ACM Trans. Math. Softw., ACM, New York, NY, USA, v. 11, n. 1, p. 3757, 1985. ISSN 0098-3500. W3C. World Wide Web Consortium. 1994. Dispon vel em: <http://www.w3.org>. Acesso em: 01 de Mar co de 2009.

Refer encias Bibliogr acas

95

WEIDERHOLD, G. (Ed.). File organization for database design. New York, NY, USA: McGraw-Hill, Inc., 1987. ISBN 0-070-70133-4. WEINBERGER, P. J. The version 8 network le system. In: Proceedings of the USENIX Summer Conference. Salt Lake City, Utah: USENIX Association, 1984. YAMADA, F. et al. Revista de Engenharia e Computa c ao. [S.l.]: Editora Mackenzie, 2004. Ano 5. ZANALYZER, I. Z1 DTSA. Smitheld, Rhode Island, EUA: [s.n.], 2008. Dispon vel em: <http://zanalyzer.com>. Acesso em: 01 de Mar co de 2009.