Programando em NCL 3.0

NCL (Nested Context Language) a linguagem declarativa do
middleware Ginga, recomendao ITU-T para servios IPTV e padro

ISDB-T
B
do Sistema Nipo-Brasileiro de TV Digital Terrestre.
Programando em NCL o livro oficial da linguagem NCL,
oferecendo uma viso passo a passo da linguagem, desde a concepo de
aplicaes bem simples, at as mais complexas, envolvendo adaptao de
contedo, o uso de mltiplos dispositivos de exibio em redes
residenciais, e gerao de aplicaes ao vivo, viabilizando as chamadas
redes sociais.
Por ser uma linguagem declarativa de alto nvel de abstrao
voltada a aplicaes para TV Digital e para a Web, NCL pode ser
facilmente apreendida, mesmo por quem no tem conhecimento de
programao. Este livro tem como foco programadores-visuais,
desenvolvedores de animaes, Web designers, e, certamente,
programadores de software. No entanto, nenhum pr-requisito de
programao exigido para o desenvolvimento de grande parte das
aplicaes.
Programando em NCL dividido em trs partes: uma parte
introdutria, onde o leitor apresentado informalmente, atravs de
exemplos, linguagem. Uma segunda parte, onde cada conceito da
linguagem explorado em toda sua potencialidade, e uma terceira parte
onde conceitos mais avanados de NCL so discutidos, incluindo sua
linguagem de script Lua, uma das mais utilizadas no mundo na rea de
jogos e entretenimento.
Luiz Fernando Gomes Soares e Simone Diniz Junqueira barbosa
so professores do Departamento de Informtica da PUC-RIO. Autores
de vrios livros, artigos em revistas e congressos nacionais e
internacionais, tm atuado nas reas de sistemas multimdia, interface
humano computador e TV digital, reas nas quais tm ministrado cursos
em todo o pas e no exterior.
2

2012, Pontifcia Universidade c do Rio de Janeiro (PUC-Rio)

Todos os direitos reservados e protegidos pela Lei n
o
9.610, de
10/02/1998.

Nenhuma parte deste livro, sem autorizao prvia da PUC-Rio,
poder ser reproduzida ou transmitida sejam quais forem os meios
empregados: eletrnicos, mecnicos, fotogrficos, gravao ou
quaisquer outros.

Este livro foi licenciado com uma Licena Creative Commons - Atribuio -
NoComercial - SemDerivados 3.0 No Adaptada.

NOTA: Muito zelo e tcnica foram empegados na edio desta obra.
No entanto, podem ocorrer erros de digitao, impresso ou dvida
conceitual. Em qualquer das hipteses, solicitamos a comunicao ao
nosso Servio de Atendimento, enviando mensagem para
ncl@telemidia.puc-rio.br, para que possamos esclarecer ou encaminhar
a questo.
Nem a Pontifcia Universidade Catlica do Rio de Janeiro nem os
autores assumem qualquer responsabilidade por eventuais danos ou
perdas a pessoas ou bens, originados do uso desta publicao.
ii

Agradecimento

A todos aqueles que acreditaram no sonho e ajudaram na
construo e consolidao da linguagem NCL e do
middleware Ginga.
Luiz Fernando Gomes Soares
Simone Diniz Junqueira Barbosa
iii

Apresentao

O impacto da TV digital muito mais significativo do que a simples
troca de um sistema de transmisso analgico para digital, proporcionando
uma melhora da qualidade de imagem e de som. Mais do que isso, um sistema
de TV digital permite um nvel de flexibilidade inatingvel com a difuso
analgica. Um componente importante dessa flexibilidade a possibilidade de
expandir as funes do sistema por aplicaes construdas sobre a base de
um sistema padro de referncia.
Tais aplicaes so programas computacionais residentes em
dispositivos receptores ou provenientes de dados enviados conjuntamente com
o udio principal e o vdeo principal de um programa televisivo. A integrao
de uma capacidade computacional ao dispositivo receptor permite o
surgimento de uma vasta gama de novos servios e de programas de TV
compostos no apenas pelo udio principal e vdeo principal, mas tambm por
outros udios e vdeos, imagens, textos etc., sincronizados em uma aplicao
muitas vezes guiada por interaes do usurio telespectador, ao qual poder
ser delegado o controle do fluxo de um programa.
A construo de tais aplicaes baseadas na linguagem NCL (Nested
Context Language), linguagem declarativa padro do Sistema Nipo-Brasileiro
de TV Digital Terrestre e Recomendao H.761 da Unio Internacional de
Telecomunicaes para servio IPTV, o foco deste livro.
O livro tem como propsito introduzir o conceito de TV digital,
analisando em profundidade no apenas o desenvolvimento de aplicaes para
tais sistemas, mas tambm o desenvolvimento de aplicaes hipermdia para a
Web. Programando em NCL o livro oficial da linguagem NCL, oferecendo
uma viso passo a passo da linguagem, desde a concepo de aplicaes bem
simples, at as mais complexas, envolvendo adaptao de contedo, o uso de
mltiplos dispositivos de exibio em redes, e gerao de aplicaes ao vivo.
Sobre o Contedo
O livro est dividido em trs partes. A Parte I apresenta uma introduo
TV digital, e guia o leitor, por meio de exemplos, em uma apresentao
iv
informal da linguagem NCL. A Parte II explora em detalhes cada conceito da
linguagem, em toda sua potencialidade, apresentando os elementos e atributos
de NCL. A Parte III discute os conceitos mais avanados de NCL, incluindo
sua linguagem de script Lua, uma das mais utilizadas no mundo na rea de
jogos e entretenimento.
O livro comea com uma introduo aos sistemas de TV digital e aos
seus padres de referncia para codificao de udio e de vdeo, para
multiplexao e para modulao. Compondo o conjunto de padres de
referncia, o Captulo 1 apresenta ento a camada que ser assunto do
restante do livro: o middleware. So discutidos os middlewares de vrios
sistemas existentes e levantados os requisitos impostos a eles pelas
aplicaes. Ainda nesse captulo, so discutidos os diversos paradigmas
utilizados na especificao de aplicaes e como os middlewares se dividem
em ambientes declarativos e ambientes imperativos, conforme o suporte dado
a um desses paradigmas. Por fim, uma discusso apresentada sobre
middlewares declarativos, sua importncia e abrangncia, quando ento a
linguagem NCL apresentada.
O Captulo 2 apresenta o modelo conceitual de dados da linguagem
NCL, denominado Nested Context Model. Nesse captulo as diversas
entidades bsicas do modelo so informalmente apresentadas, e dada uma
pequena noo de como elas sero mapeadas em elementos da linguagem.
O Captulo3 traz uma introduo passo a passo a diversos elementos
que compem o perfil NCL 3.0 para TV digital. Nessa introduo, no existe
a preocupao de definir cada elemento da linguagem e cada um de seus
atributos, o que feito na Parte II do livro. O intuito j prover ao leitor a
habilidade de desenvolver programas NCL simples e capacit-lo a melhor
entender e exercitar os demais conceitos apresentados na Parte II. A
introduo feita atravs de um nico exemplo, construdo passo a passo
junto com o leitor.
O Captulo 4 introduz, de forma genrica, os vrios perfis e mdulos da
linguagem NCL. O captulo apenas uma introduo Parte II do livro
dedicada apresentao do perfil EDTV (Enhanced Digital TV), definido
para sistemas de TV digital.
A Parte I se encerra com quatro apndices. O Apndice A discute mais
detalhadamente os diversos mtodos de compactao e compresso de dados,
apresentando os padres para textos, imagens, udios e vdeos. O Apndice B
traz uma introduo ao padro DSM-CC (Digital Storage Media Command
and Control) para transporte de dados. O Apndice C apresenta em detalhes
o modelo NCM introduzido pelo Captulo 2. Finalmente, o Apndice D
apresenta um documento NCL especificando uma base de conectores,
conceito discutido no Captulo 3 e detalhado no Captulo 10.
v
A Parte II do livro dedicada apresentao de cada elemento e cada
atributo da linguagem NCL.
O Captulo 5 descreve a estrutura das aplicaes NCL, apresentando
todos os elementos e atributos do mdulo Structure do perfil EDTV da
linguagem NCL.
O Captulo 6 descreve os elementos e atributos para definio de regies
de apresentao em classes de dispositivos de exibio, apresentando todos os
elementos e atributos do mdulo Layout do perfil EDTV da linguagem NCL.
O Captulo 7 descreve os elementos e atributos responsveis pela
definio dos parmetros de exibio de uma mdia em uma dada regio. Ou
seja, apresenta os elementos e atributos responsveis pela configurao de
como os objetos de mdia devero ser apresentados. O captulo tambm
descreve como pode ser feita a navegao entre objetos de mdia por meio das
teclas (setas) de navegao, e como efeitos de transio podem ser associados
s apresentaes dos objetos. Assim, o captulo apresenta todos os elementos
e atributos dos mdulos Descriptor, Timing, KeyNavigation, Transition e
TransitionBase do perfil EDTV da linguagem NCL.
O Captulo 8 apresenta os tipos de objetos de mdia permitidos em
NCL, incluindo alguns tipos de objetos especiais. Nesse captulo so tambm
apresentados os objetos contextos, que permitem a estruturao do cdigo
para aumentar tanto a legibilidade quanto as oportunidades de reso. No
captulo so apresentados todos os elementos e atributos dos mdulos Media
e Context do perfil EDTV da linguagem NCL.
O Captulo 9 descreve as interfaces oferecidas em NCL pelos objetos de
mdia e de contexto. So definidas as ncoras de contedo, que permitem o
uso de trechos dos objetos em relacionamentos, para um sincronismo mais
fino do que quando se usa o objeto inteiro. So tambm definidas as
propriedades, que possibilitam aos relacionamentos a manipulao de
atributos dos objetos durante a execuo da aplicao. O captulo apresenta
todos os elementos e atributos dos mdulos MediaContentAnchor,
PropertyAnchor e CompositeNodeInterface do perfil EDTV da linguagem
NCL.
O Captulo 10 apresenta os elos e conectores que definem o sincronismo
e, em particular, a interatividade entre os objetos de uma aplicao NCL.
Conectores definem relaes sem especificar seus participantes. Elos definem
relacionamentos referindo-se a um conector e definindo os participantes da
relao. O captulo apresenta todos os elementos e atributos dos mdulos
Link e Animation, e da rea funcional Connectors do perfil EDTV da
linguagem NCL.
vi
O Captulo 11 descreve como adaptar uma aplicao durante sua
execuo, atravs da avaliao de regras e a correspondente seleo de
objetos ou de formas de apresentao de objetos, apresentando todos os
elementos e atributos da rea funcional Presentation Control e do mdulo
SwitchInterface do perfil EDTV da linguagem NCL.
O Captulo 12 descreve como metadados podem ser especificados em
aplicaes, apresentando todos os elementos e atributos do mdulo
Metainformation do perfil EDTV da linguagem NCL.
O Captulo 13 apresenta mecanismos adicionais de reso fornecidos
pela NCL: reso de contedo, importao de documentos, importao de
bases de um documento e reso de objetos, intra e interdocumentos. O
captulo apresenta todos os elementos e atributos da rea funcional Reuse do
perfil EDTV da linguagem NCL.
A Parte II se encerra com o Apndice E, que introduz o conceito de
Normal Play Time, ou NPT, como definido pelo padro MPEG-2.
A Parte III do livro discute os conceitos mais avanados e inovadores de
NCL, e voltada para gerao de aplicaes ao vivo, aplicaes para
mltiplos dispositivos, e extenses da linguagem para o aninhamento de
objetos cujos contedos so cdigos escritos em outras linguagens, em
especial a linguagem Lua, linguagem de script de NCL.
O Captulo 14 discute como objetos com contedo hipermdia
especificado por uma linguagem declarativa podem ser definidos, como eles
podem se relacionar com outros objetos em um documento NCL e como
exibidores (players) para esses objetos se comportam.
O Captulo 15 apresenta como dispositivos de exibio podem se
registrar em classes ativas e passivas, e as vrias formas de um documento
NCL especificar em que dispositivos sero exibidos os seus objetos, bem
como o comportamento do formatador NCL e dos vrios exibidores de mdia
nesses dispositivos, ilustrando os conceitos sempre com exemplos.
O Captulo 16 descreve os Comandos de Edio NCL. Por meio de
Comandos de Edio, aplicaes NCL podem ser criadas e modificadas em
tempo de exibio, ou seja, podem ser editadas ao vivo.
O Captulo 17 discute como objetos com cdigo imperativo podem ser
definidos, como eles podem se relacionar com outros objetos em um
documento NCL e como exibidores (engines) para esses objetos se
comportam. Objetos e exibidores NCLua (objetos imperativos com cdigo
Lua), por definio parte dos perfis da linguagem NCL para TV digital, so
introduzidos no captulo.
O Captulo 18 se dedica aos objetos NCL com cdigo Lua, os
chamados scripts NCLua, apresentando uma srie de exemplos de casos de
vii
usos. Esse captulo de co-autoria com Francisco SantAnna e Carlos de Salles
Soares Neto foi por eles gentilmente cedidos ao livro.
A Parte III se encerra com trs apndices de contedo avanado. O
Apndice F discute as vrias formas como os comandos de edio,
introduzidos pelo Captulo 16, podem ser transportados, tanto atravs de
estruturas de dados recebidas sem solicitao, como atravs de estruturas de
dados recebidas sob demanda. O Apndice G traz uma discusso a respeito
das estruturas de dados usadas em procedimentos de escalonamento,
realizados tanto pelos receptores quanto pelos provedores de contedo das
aplicaes, e como elas podem ser deduzidas de uma outra estrutura de dados
nica chamada HTG Hypermedia Temporal Graph. Finalmente, o Apndice
H apresenta a interpretao dada pelos vrios exibidores de mdia, incluindo
os objetos de mdia com cdigo imperativo e declarativo, a comandos
enviados pelo formatador NCL e a comandos de edio NCL. O apndice
tambm apresenta a interpretao dada pelo formatador quando as aes so
submetidas a ns de composio NCL.
A Quem se Destina o Livro
Por ser uma linguagem declarativa de alto nvel de abstrao voltada a
aplicaes para TV Digital e para a Web, a NCL pode ser facilmente
apreendida, mesmo por quem no tem conhecimento de programao. Este
livro tem como foco programadores-visuais, desenvolvedores de animaes,
Web designers, e, certamente, programadores de software. No entanto,
nenhum pr-requisito de programao exigido para o desenvolvimento de
grande parte das aplicaes.
O livro o resultado de um amplo trabalho desenvolvido no Laboratrio
TeleMdia do Departamento de Informtica da Pontifcia Universidade
Catlica do Rio de Janeiro e seu contedo tem sido usado tanto em cursos de
graduao quanto de ps-graduao em diversas reas, como Informtica,
Comunicao e Artes. O livro, no entanto, no tem como alvo apenas a rea
acadmica.
Como Utilizar o Livro
Existem vrias formas de utilizao deste livro, em cursos regulares ou
como leitura auto-didtica.
Aqueles interessados apenas em entender como opera um sistema de TV
digital, os vrios padres envolvidos e como um leitor sem conhecimentos
prvios de programao poderia desenvolver aplicaes para o middleware
viii
Ginga devem se concentrar na Parte I do livro, usando a Parte II como
consulta ao desenvolver suas aplicaes.
O leitor interessado em sistemas hipermdia e na utilizao da linguagem
NCL para desenvolvimento para Web poderia pular os Captulos 1 e 4 da
Parte I e se concentrar nos detalhes oferecidos pela Parte II do livro. Em uma
primeira leitura, os Captulos 11 a 13 da Parte II poderiam ser ignorados,
bem como toda a Parte III. Para o desenvolvimento de aplicaes mais
complexas, no entanto, so essenciais os Captulos 11 e 13 da Parte II, e os
Captulos 17 e 18 da Parte III.
O leitor interessado na utilizao da linguagem NCL para
desenvolvimento para TV digital tem um perfil parecido com o caso anterior,
mas, nesse caso, os Captulos 1 e 4 da Parte I so essenciais, mesmo em uma
primeira leitura.
Profissionais para o desenvolvimento de aplicaes NCL para TV
digital (terrestre, IPTV, P2PTV, WebTV e Internet TV), quer sejam
programadores de software, programadores-visuais, desenvolvedores de
animaes, Web designers etc. devem ler todo o livro e a sugesto que seja
na ordem apresentada. A Parte II e III sero sempre teis como consulta
freqente a detalhes da linguagem.
Agradecimentos
Gostaramos neste ponto de agradecer a todos os colegas e alunos do
Departamento de Informtica da PUC-Rio pela contribuio dada a este
trabalho, principalmente queles que ao longo dos anos contriburam na
especificao da linguagem e na implementao do middleware Ginga. Em
especial gostaramos de agradecer s equipes dos laboratrios TeleMdia e
SERG da PUC-Rio que viabilizaram a padronizao mundial da linguagem
NCL e a implementao de referncia do middleware Ginga. Citar nomes aqui
um risco que no queremos correr por esquecimento.
No poderamos deixar de agradecer mais uma vez a Francisco
SantAnna e Carlos de Salles Soares Neto que, em co-autoria com os autores
do livro, desenvolveram o ltimo captulo sobre Lua e abriram mo de seus
direitos de propriedade intelectual. Agradecemos tambm a Romualdo
Resende Costa pela co-autoria do Apndice G.
Temos muito a agradecer a Marcelo Ferreira Moreno, a Mrcio Ferreira
Moreno e a toda equipe do laboratrio TeleMdia, por eles coordenada, pelo
desenvolvimento das diversas ferramentas de autoria e da implementao de
referncia do middleware Ginga que deram suporte ao desenvolvimento das
aplicaes NCL que compem esse livro.
ix
Gostaramos ainda de agradecer Editora Campus e toda sua equipe
pelo empenho e dedicao na realizao da primeira edio deste livro.
Foi graas ao Departamento de Informtica da PUC-Rio que tivemos
toda a infra-estrutura necessria para a realizao desta tarefa. Sem o apoio
financeiro proporcionado pelo Ministrio da Cincia e Tecnologia, em
especial do programa CETIC, e do Ministrio das Telecomunicaes, por
meio do FUNTTEL, este livro no poderia sequer ter sido iniciado.
Finalmente no poderamos deixar de agradecer aos nossos cnjuges Isa
Haro Martins e Lus Fernando Diniz Junqueira Barbosa pela compreenso
pelas muitas horas de convvio roubadas durante a escrita do livro.
Luiz Fernando Gomes Soares
Simone Diniz Junqueira Barbosa
x

Acrnimos

AAC Advanced Audio Coding
ABNT Associao Brasileira de Normas Tcnicas
ACAP Advanced Common Application Platform
ADTB Advanced Digital Television Broadcasting
API Application Programming Interface (interface de
programao de aplicaes)
ARIB Association of Radio Industries and Businesses
ATSC Advanced Television Systems Committee
AVC Advanced Video Coding
BDTV Basic Digital Television (perfil TVD Bsico)
BER Bit Error Ratio (taxa de erro de bits)
BML Broadcast Markup Language
BST-OFDM Band Segmented Transmission Orthogonal Frequency
Division Multiplexing
COFDM Coded Orthogonal Frequency Division Multiplexing
CPU Central Processing Unit
DD Dolby Digital
DOM Document Object Model
DSM-CC Digital Storage Media Command and Control
DVB-T Digital Video Broadcasting Terrestrial
EDTV Enhanced Digital Television (perfil TVD Avanado)
FDM Frequency Division Multiplexing (multiplexao por diviso
de frequncia)
xi
HDTV High-Definition Television (TV de alta definio)
HE-AAC High-Efficiency Advanced Audio Coding
HTML HyperText Markup Language
IANA Internet Assigned Numbers Authority
IPTV Internet Protocol Television
ISDB-T Integrated Services Digital Broadcasting Terrestrial
ISDB-T
B
International Standard for Digital Broadcasting -Terrestrial
ISI Inter-Symbol Interference
ITU-R International Telecommunication Union The
Radiocommunication Sector
ITU-T International Telecommunication Union
Telecommunication Standardization Sector
JIT Just in Time
JPEG Joint Photographic Experts Group
JVM Java Virtual Machine
MHP Multimedia Home Platform
MIME Multipurpose Internet Mail Extensions
MJPEG Motion JPEG
MP2 MPEG-1 Audio Layer II
MP3 MPEG-1 Audio Layer III
MPEG-2 Motion Picture Experts Group
NCL Nested Context Language
NCM Nested Context Model
OFDM Orthogonal Frequency Division Multiplexing
OQAM Offset Quadrature Amplitude Modulation
P2PTV Peer-to-Peer TV
PAT Program Association Table
PDA Personal Digital Assistant
PDF Portable Document Format
xii
PMT Program Map Table
PS Parametric Stereo
PSI Program-Specic Information
QAM Quadrature Amplitude Modulation
QPSK Quadrature Phase-Shift Keying
RDF Resource Description Framework
SBR Spectral Band Replication
SBTVD-T Sistema Brasileiro de TV Digital Terrestre
SDTV Standard-Definition Television
SMIL Synchronized Multimedia Integration Language
SVG Scalable Vector Graphics
TS Transport Stream
TVD TV Digital
URI Uniform Resource Identier
UTC Universal Time Coordinated
VSB Vestigial Side Band
W3C World Wide Web Consortium
WMA Windows Media Audio
XHTML Extensible HyperText Markup Language
XML Extensible Markup Language

xiii
Sumrio

PARTE I
INTRODUO TV DIGITAL E LINGUAGEM NCL
Captulo 1 TV Digital ....................................................................................... 2
1.1 Introduo .............................................................................. 3
1.2 Sistema de TV Digital: Viso Geral........................................ 8
1.2.1 Codificao do udio ............................................. 10
1.2.2 Codificao do Vdeo .............................................. 12
1.2.3 Sistema de Transporte ............................................ 14
1.2.3.1 Multiplexao de Dados ............................ 15
1.2.3.2 Fluxo Elementar de Dados......................... 17
1.2.3.3 Fluxo de Transporte .................................. 18
1.2.4 Modulao .............................................................. 20
1.2.5 Canal de Retorno ou Canal de Interatividade .......... 22
1.3 Middleware .......................................................................... 23
1.3.1 Requisitos ............................................................... 24
1.3.2 Ambientes de Programao ..................................... 29
1.3.3 Middlewares Declarativos ....................................... 32
Bibliografia .................................................................................... 36
Captulo 2 Modelo Conceitual NCM ............................................................... 40
2.1 Entidades Bsicas XHTML .................................................. 41
2.2 Entidades Bsicas do NCM .................................................. 42
Bibliografia .................................................................................... 49
Captulo 3 Introduo Linguagem NCL ....................................................... 50
3.1 O Primeiro Joo ................................................................... 51
3.2 Sincronismo de Mdia sem Interatividade e com Reso
Apenas de Relao .............................................................. 51
3.3 Sincronismo de Mdia sem Interatividade, com Reuso de
Caractersticas de Apresentao e Importao de Base ......... 61
3.4 Adicionando Sincronismo com Interatividade...................... 67
3.5 Adicionando o Uso de Contextos ......................................... 73
3.6 Adicionando Reso de Objetos de Mdia .............................. 78
3.7 Usando o Canal de Interatividade ........................................ 82
3.8 Uso de Mltiplos Dispositivos de Exibio .......................... 87
3.9 Adaptao de Contedo ....................................................... 89
xiv
3.10 O Uso do N Settings .......................................................... 95
3.11 Efeitos de Transio e Animao ....................................... 104
3.12 Navegao por Teclas ........................................................ 112
3.13 Acrescentando um Objeto NCLua ...................................... 125
Bibliografia .................................................................................. 139
Captulo 4 Perfis NCL ................................................................................... 140
4.1 Introduo ......................................................................... 141
4.2 Mdulos NCL .................................................................... 142
4.3 Perfis NCL ........................................................................ 145
4.3.1 Informaes sobre Verses da NCL....................... 146
Bibliografia .................................................................................. 147

PARTE II
LINGUAGEM NCL PERFIL EDTV
Captulo 5 Estrutura de Aplicaes NCL ...................................................... 150
5.1 Introduo Estrutura do Cdigo NCL .............................. 151
Bibliografia .................................................................................. 154
Captulo 6 Leiaute da Apresentao: Regies ................................................. 155
6.1 Introduo ......................................................................... 156
6.1.1 Importao de Base de Regies ............................. 157
6.1.2 Atributos de Base de Regies ................................ 158
6.1.3 Atributos de Regio .............................................. 159
6.2 Referncia Rpida Regies ............................................. 169
Bibliografia .................................................................................. 170
Captulo 7 Apresentao de Objetos de Mdia: Descritores ......................... 171
7.1 Introduo a Descritores .................................................... 172
7.1.1 Importao de Bases de Descritores ...................... 173
7.1.2 Atributos Bsicos de Descritor ............................. 174
7.1.3 Parmetros de Descritor ....................................... 180
7.2 Navegao por Teclas ........................................................ 185
7.3 Efeitos de Transio .......................................................... 190
7.3.1 Base de Transies ............................................... 191
7.3.2 Transies............................................................ 191
7.3.3 Atributos de Descritor para Transies ................. 194
7.4 Referncia Rpida Descritores .................................... 195
Bibliografia .................................................................................. 196
Captulo 8 Objetos de Mdia e Contexto ....................................................... 197
8.1 Objetos de Mdia e seus Atributos ...................................... 197
8.1.1 Atributos de Objeto de Mdia ............................... 198
8.1.2 O Atributo src ...................................................... 199
8.1.3 O Atributo type .................................................... 201
xv
8.2 Contextos .......................................................................... 203
8.3 Portas ................................................................................ 205
8.4 Referncia Rpida Mdias, Contextos e Portas ............. 207
Bibliografia .................................................................................. 207
Captulo 9 ncoras de Contedo e Propriedades.......................................... 208
9.1 ncoras de Contedo......................................................... 209
9.2 Propriedades ...................................................................... 213
9.3 Objeto de Mdia do Tipo application/x-ncl-settings ....... 218
9.4 Variveis de Ambiente ...................................................... 218
9.5 Referncia Rpida - ncoras de Contedo e Propriedades.. 224
Bibliografia .................................................................................. 224
Captulo 10 Sincronizao: Conectores e Elos ................................................ 225
10.1 Introduo ......................................................................... 226
10.2 Base de Conectores ............................................................ 226
10.3 Conectores......................................................................... 226
10.4 Elos ................................................................................... 235
10.5 Conectores e Elos de Interatividade ................................... 245
10.6 Conectores com Mltiplas Aes e Condies.................... 250
10.7 Conectores que Definem Novos Papis .............................. 259
10.8 Conectores e Elos que Manipulam Propriedades ................ 260
10.9 Elos do Tipo get and set ................................................. 271
10.10 Conectores e Elos com Atribuio ao Longo do Tempo para
Efeito de Animao ........................................................... 272
10.11 Importao de Conectores .................................................. 273
10.12 Elos Referenciando Composies ....................................... 274
10.13 Referncia Rpida Conectores ....................................... 275
Bibliografia .................................................................................. 276
Captulo 11 Adaptao do Contedo e da Apresentao: Regras, Switches e
Switches de Descritor ................................................................. 277
11.1 Regras ............................................................................... 278
11.2 Switch ............................................................................... 279
11.3 Switch de Descritor ............................................................ 283
11.4 Referncia Rpida Regras, Switches e Switches de Descritor
.......................................................................................... 285
Bibliografia .................................................................................. 286
Captulo 12 Metadados .................................................................................... 287
12.1 Metadados em Aplicaes NCL ......................................... 288
12.2 Exemplo de Metadados na Aplicao O Primeiro Joo ..... 290
Bibliografia .................................................................................. 294
Captulo 13 Reso ............................................................................................ 295
13.1 Espelhamento de Contedo................................................ 296
xvi
13.2 Reso de Objetos de Mdia ................................................ 298
13.3 Reso de Contextos ........................................................... 302
13.4 Reso entre Documentos NCL ........................................... 302
13.4.1 Importao de um Documento NCL ........................ 302
13.4.2 Reso de um Documento NCL como um Objeto de
Mdia ............................................................................... 305
13.5 Importao da Base de um Documento NCL ...................... 305
13.6 Referncia Rpida Importao de Documentos e Bases . 307
Bibliografia .................................................................................. 307

PARTE III
TPICOS AVANADOS
Captulo 14 Objetos Hipermdia Declarativos em NCL ................................. 310
14.1 Integrando Objetos Hipermdia Declarativos NCL .......... 311
14.2 Interfaces de Objetos de Hipermdia Declarativos .............. 312
14.2.1 ncoras de Contedo .............................................. 312
14.2.2 Propriedades ........................................................... 315
14.3 Exemplo O Primeiro Joo ..................................................... 317
Bibliografia .................................................................................. 321
Captulo 15 Programando para mltiplos Dispositivos ................................... 322
15.1 Especificando o Dispositivo de Exibio ............................ 323
15.1.1 Classes de Dispositivos ........................................... 323
15.1.2 Comportamento dos Dispositivos de Entrada .......... 324
15.2 Comportamento de Dispositivos na Classe Passiva ............ 325
15.3 Comportamento de Dispositivos na Classe Ativa ............... 331
15.4 Comportamento de Dispositivos Cadastrados nas Classes
Ativa e Passiva .................................................................. 337
15.5 Formatador Distribudo ..................................................... 338
15.6 Adaptando Mltiplos Dispositivos para um Ambiente com um
nico Dispositivo .............................................................. 338
Bibliografia .................................................................................. 340
Captulo 16 Comandos de Edio NCL ........................................................... 341
16.1 Introduo ......................................................................... 342
16.2 Comandos de Edio NCL ................................................. 342
16.3 Exemplos de Comandos de Edio NCL ............................ 349
16.3.1 Abrir uma Base Privada .......................................... 350
16.3.2 Ativar a Base Privada aberta ................................... 351
16.3.3 Adicionar um Documento na Base Privada Aberta .. 351
16.3.4 Iniciar a Exibio do Documento ............................ 352
16.3.5 Adicionar uma Regio Base de Regies e em
Seguida Remov-la ................................................. 353
xvii
16.3.6 Adicionar uma Interface a um Objeto do
Documento ............................................................. 354
16.3.7 Adicionar um Novo Objeto ao Documento .............. 355
16.3.8 Adicionar um Elo Ligando a Nova Interface
Adicionada ao Novo Objeto Adicionado.................. 356
16.3.9 Parar a Exibio do Documento .............................. 357
16.3.10 Salvar o Documento .............................................. 357
16.3.11 Fechar a Base Privada Aberta ............................... 358
Bibliografia .................................................................................. 358
Captulo 17 Objetos Imperativos em NCL ...................................................... 359
17.1 Integrando Objetos Imperativos NCL .............................. 360
17.2 Elemento <media type=application/x-???> ..................... 362
17.3 Comportamento Esperado de Exibidores de Objetos
Imperativos em Aplicaes NCL ....................................... 364
17.3.1 Ponte entre os Ambientes Declarativo e Imperativo. 364
17.3.2 Modelo de Execuo de um Objeto Imperativo ........ 365
Bibliografia .................................................................................. 368
Captulo 18 Programando com Objetos NCLua ............................................. 369
18.1 A Linguagem Lua ............................................................. 370
18.1.1 Extenses de NCLua ............................................... 370
18.2 Programao Orientada a Eventos ..................................... 371
18.2.1 Classes de Eventos .................................................. 374
18.3 Interagindo com o Documento NCL .................................. 375
18.3.1 Eventos em ncoras de Contedo e Propriedades ... 381
18.3.1.1 Eventos do Tipo presentation ................. 381
18.3.1.2 Eventos do Tipo attribution .................... 381
18.4 Desenhando na Regio do Objeto ...................................... 387
18.4.1 Programando com Animaes ................................ 392
18.4.2 Corrotinas de Lua ................................................... 393
18.5 Reso de Cdigo Lua ......................................................... 397
Bibliografia .................................................................................. 401

APNDICES
Apndice A ..................................................................................................... 403
A.1 Informao e Sinal ............................................................ 404
A.2 Converso de Sinais .......................................................... 406
A.2.1 Converso A/D ....................................................... 406
A.2.2 Converso D/A ....................................................... 408
A.2.3 Outros Codificadores de Onda ................................ 409
A.3 Compresso e Compactao............................................... 410
A.3.1 Codificao por Carreira ......................................... 410
A.3.2 Codificao de Shannon-Fano ................................ 411
xviii
A.3.3 Codificao de Huffman ......................................... 412
A.3.4 Codificao de Lempel-Ziv-Welch .......................... 413
A.3.5 Outras Tcnicas de Compactao ............................ 414
A.3.6 Compresso em Imagem Esttica ............................ 414
A.3.7 Compresso em udio ............................................ 420
A.3.8 Compresso em Vdeo ............................................ 427
H.261 ..................................................................... 430
MPEG-1 e MPEG-2 Vdeo ..................................... 431
MPEG-4 Vdeo ....................................................... 435
A.3.9 Multiplexao e Sincronizao ............................... 437
A.4 Requisitos de Comunicao das Diversas Mdias ............... 440
A.4.1 Texto ...................................................................... 441
A.4.2 Imagem .................................................................. 442
A.4.3 udio ..................................................................... 443
A.4.4 Vdeo...................................................................... 445
Bibliografia: ................................................................................. 446
Apndice B ...................................................................................................... 450
B.1 Introduo ......................................................................... 451
B.2 Carrossel de Dados ............................................................ 451
B.3 Carrossel de Objetos .......................................................... 453
B.4 Eventos de Fluxo ............................................................... 458
B.5 MPE: Multi-protocol Encapsulation .................................. 460
Bibliografia .................................................................................. 460
Apndice C ...................................................................................................... 462
C.1 Introduo ......................................................................... 463
C.2 Entidades e Propriedades ................................................... 464
C.3 Ns e ncoras ................................................................... 464
C.4 Ns de Mdia ..................................................................... 466
C.5 Ns de Composio ........................................................... 467
C.6 Ns de Contexto ................................................................ 469
C.7 Ns Switch (Alternativas de Ns) ...................................... 470
C.8 Eventos ............................................................................. 472
C.9 Elos ................................................................................... 476
C.9.1 Conectores .............................................................. 477
C.9.2. Binds de Elos.......................................................... 485
C.10 Objetos de Dados X Objetos de Representao ............... 489
C.11 Descritores Genricos, Descriptores e Switches de
Descritores ........................................................................ 490
C.12 Trilhas .............................................................................. 492
C.13 Hiperbase Pblica e Bases Privadas ................................... 494
Bibliografia .................................................................................. 495
Apndice D ...................................................................................................... 496
xix
D.1 Conectores Causais ............................................................ 497
Apndice E ...................................................................................................... 500
E.1 Introduo ......................................................................... 501
Bibliografia .................................................................................. 503
Apndice F ...................................................................................................... 504
F.1 Introduo ......................................................................... 505
F.2 Transporte de Comandos por Descritores de Eventos de
Fluxo e Carrossel de Objetos DSM-CC .............................. 505
F.3 Transporte de Comandos de Edio Usando Estruturas
Especficas Definidas pelo Ginga-NCL .............................. 509
F.3.1 Transporte em um Tipo Especfico de Seo
MPEG-2 ................................................................. 512
F.3.2 Transporte das Estruturas de Metadados como
Parmetro de Comandos de Edio ......................... 514
F.3.3 Transporte de Estruturas de Metadados em Sees
de Metadados MPEG-2 ........................................... 515
Bibliografia .................................................................................. 517
Apndice G ..................................................................................................... 518
G.1 Escalonadores.................................................................... 519
G.2 Hypermedia Temporal Graph (HTG) ................................. 520
G.2.1 Clculo das Duraes das Arestas ........................... 525
G.3 Planos de Escalonamento .................................................. 526
Bibliografia .................................................................................. 529
Apndice H ..................................................................................................... 530
H.1 Introduo ......................................................................... 531
H.2 Comportamento dos Exibidores de Objetos de Mdia No-
Declarativos ...................................................................... 531
H.2.1 Comportamento na Execuo de Aes sobre
Eventos de Apresentao ........................................ 531
H.2.1.1 Instruo start ............................................ 531
H.2.1.2 Instruo stop ............................................. 534
H.2.1.3 Instruo abort ........................................... 536
H.2.1.4 Instruo pause .......................................... 537
H.2.1.5 Instruo resume ........................................ 538
H.2.1.6 Trmino Natural de uma Apresentao....... 539
Eventos de Atribuio ............................................. 540
H.2.2.1 Instruo start ............................................ 541
H.2.2.2 Instrues stop, abort, pause e resume ........ 541
H.2.3 Comportamento na Execuo de Comandos de
Edio .................................................................... 542
H.2.3.1 Instruo addEvent..................................... 542
xx
H.2.3.2 Instruo removeEvent ............................... 542
H.3 Comportamento do Formatador NCL na Exibio de
Composies ..................................................................... 542
H.3.1 Iniciando a Apresentao de um Contexto .............. 543
H.3.2 Parando a Apresentao de um Contexto ................ 543
H.3.3 Abortando a Apresentao de um Contexto ............. 543
H.3.4 Pausando a Apresentao de um Contexto .............. 544
H.3.5 Retomando a Apresentao de um Contexto ........... 544
H.3.6 Relao entre as Mquinas de Estado de Eventos de
Apresentao de um N e a Mquina de Estado do
Evento de Apresentao de seu N de Composio
Pai .......................................................................... 544
H.4 Comportamento de Exibidores de Objetos Hipermdia com
Contedo Declarativo ........................................................ 545
H.4.1 Iniciando a Apresentao de um Objeto Hipermdia
com Contedo Declarativo ...................................... 545
H.4.2 Parando a Apresentao de um Objeto Hipermdia com
Contedo Declarativo ............................................. 546
H.4.3 Abortando a Apresentao de um Objeto Hipermdia
H.4.4 Pausando a Apresentao de um Objeto Hipermdia
H.4.5 Retomando a Apresentao de um Objeto Hipermdia
Eventos de Atribuio de um Objeto Hiperdia com
Cdigo Declarativo ................................................. 548
H.4.7 Relao entre os Estados de uma Cadeia Temporal
de um Objeto Hipermdia e suas ncoras de
Contedo ................................................................ 549
Bibliografia .................................................................................. 549

xxi
Figuras, Listagens e Tabelas

Figuras
Figura 1.1 Efeito de mltiplos percursos. ................................................. 4
Figura 1.2 Parmetros da SDTV. ............................................................ 5
Figura 1.3 Receptor de TV digital. .......................................................... 8
Figura 1.4 Sistema de TV digital terrestre. .............................................. 9
Figura 1.5 Padres de referncia para TV digital terrestre. ..................... 10
Figura 1.6 Multiplexao do udio principal e vdeo principal. .............. 14
Figura 1.7 Transporte de dados sncronos. ............................................. 15
Figura 1.8 Transporte de dados sincronizados. ...................................... 16
Figura 1.9 Transporte de dados assncronos. ......................................... 16
Figura 1.10 Fluxo de transporte MPEG-2 System. .................................. 19
Figura 1.11 Padres de referncia do sistema brasileiro de TV digital
terrestre. .............................................................................. 24
Figura 1.12 Exemplo de programa no-linear. ......................................... 25
Figura 1.13 Mltiplos dispositivos de exibio. ....................................... 27
Figura 1.14 Desempenho de Lua e de LuaJIT
(http://shootout.alioth.debian.org/) comparado
JavaScript. ........................................................................... 35
Figura 2.1 Modelo conceitual XHTML bsico. ...................................... 41
Figura 2.2 Modelo conceitual NCM bsico............................................ 42
Figura 2.3 Interfaces de um n NCM. ................................................... 43
Figura 2.4 Interfaces de um n NCM. ................................................... 47
Figura 2.5 Entidades NCM e elementos da linguagem NCL. .................. 48
Figura 3.1 Viso temporal. .................................................................... 52
xxii
Figura 3.2 Viso de leiaute. ................................................................... 53
Figura 3.3 Viso estrutural.................................................................... 57
Figura 3.4 Cenas da aplicao O Primeiro Joo. ................................... 61
Figura 3.5 Viso estrutural.................................................................... 67
Figura 3.6 Cenas da aplicao O Primeiro Joo com interatividade. ...... 73
Figura 3.7 Cenas da aplicao O Primeiro Joo usando contextos. ........ 74
Figura 3.8 Reso. ................................................................................. 78
Figura 3.9 Viso estrutural da verso com o uso do canal de
interatividade. ...................................................................... 82
Figura 3.10 Cenas da aplicao O Primeiro Joo com uso do canal de
interatividade. ...................................................................... 87
Figura 3.11 Cenas da aplicao O Primeiro Joo com o uso de
mltiplos dispositivos. .......................................................... 89
Figura 3.12 Viso estrutural da verso com adaptao de contedo. ........ 89
Figura 3.13 Viso estrutural do contexto de interatividade. ...................... 96
Figura 3.14 Viso estrutural da nova verso de O Primeiro Joo............. 98
Figura 3.15 Cenas da aplicao O Primeiro Joo com controle de
interatividade. .................................................................... 104
Figura 3.16 Viso estrutural de O Primeiro Joo, com efeito de
animao e transio. ......................................................... 106
Figura 3.17 Cenas da aplicao O Primeiro Joo com efeitos de
transio. ........................................................................... 111
Figura 3.18 Viso estrutural de O Primeiro Joo com navegao por
teclas. ................................................................................ 115
Figura 3.19 Cenas da aplicao O Primeiro Joo com navegao no
menu por teclas. ................................................................. 125
Figura 3.20 Viso estrutural da verso final do exemplo O Primeiro
Joo. ................................................................................. 129
Figura 3.21 Cenas da aplicao O Primeiro Joo com objeto NCLua. ... 139
Figura 6.1 Leiaute de exemplo com uma regio (rgCentro)
centralizada sobre uma regio pai (rgTV). ...................... 160
Figura 6.2 Atributos de posicionamento e dimenso de uma regio....... 162
xxiii
Figura 6.3 Leiaute de exemplo com diversas regies (rgMenu1,
rgMenu2, rgMenu3, rgMenu4) posicionadas de
forma relativa a uma regio pai (rgMenu). ...................... 162
Figura 6.4 Leiaute de exemplo com diversas regies (rgMenu1,
rgMenu2, rgMenu3, rgMenu4) posicionadas de
forma relativa a uma regio pai (rgMenu), prximas ao
lado direito da regio rgTV. ............................................ 164
Figura 6.5 Viso estrutural do exemplo para reproduo de um nico
vdeo, sem sincronismo ou interao com o usurio. ............ 164
Figura 6.6 Viso de leiaute do exemplo. .............................................. 165
Figura 6.7 Vises temporal e espacial do exemplo. .............................. 165
Figura 7.1 Viso estrutural ilustrando n inatingvel. ........................... 175
Figura 7.2 Viso estrutural do Exemplo 7.1. ........................................ 176
Figura 7.3 Viso de leiaute do Exemplo 7.1. ........................................ 176
Figura 7.4 Vises temporal e espacial do Exemplo 7.1. ........................ 177
Figura 7.5 Ilustrao do parmetro de descritor fit com o valor fill. . 182
Figura 7.6 Ilustrao do parmetro de descritor fit com o valor
hidden. ........................................................................... 183
meet. .............................................................................. 183
meetBest. ........................................................................ 183
slice. ............................................................................... 184
Figura 7.10 Atributos de descritor relacionados navegao em um
menu vertical de seis itens: (a) no-circular e (b) circular. ... 186
Figura 7.11 Ilustrao de diferentes valores de focusBorderWidth
para traar uma moldura ao redor do elemento em foco. ...... 187
Figura 7.12 Ilustrao de uma transio de entrada type barWipe,
subtype=leftToRight, startProgress=0.5, que
apresenta a imagem inicialmente j a 50% do progresso
total da transio. ............................................................... 193
Figura 8.1 Sintaxe de um URI ............................................................. 199
xxiv
Figura 8.2 Porta pVideo1 como ponto de entrada a um n video1
interno a um contexto. ........................................................ 205
Figura 8.3 Exemplo de portas e contextos, definidos na Listagem 8.3. .. 206
Figura 9.1 ncoras de uma mdia na viso estrutural. .......................... 209
Figura 10.1 Ilustrao de um conector causal (elemento
<causalConnector>) com papis (role) de condio e
ao. .................................................................................. 227
Figura 10.2 Ilustrao de elo (elemento <link>). .................................. 227
Figura 10.3 Conector onBeginStart, que define o comportamento:
quando a mdia associada ao papel onBegin iniciar, a
mdia associada ao papel start tambm iniciar. ............... 228
Figura 10.4 Mquina de estados de eventos. .......................................... 231
Figura 10.5 Viso estrutural do exemplo, destacando o elo de
sincronismo entre as mdias. ............................................... 236
Figura 10.6 Elo que utiliza o conector onBeginStart, ligando as
mdias videoPrincipal ao papel onBegin e
imgInteratividade ao papel start do conector,
respectivamente. ................................................................. 237
Figura 10.7 Viso estrutural correspondente Listagem 10.4, com
destaque nos elos de sincronismo de incio e trmino de
exibio das mdias. ........................................................... 239
Figura 10.8 Vises temporal e espacial correspondentes Listagem
10.4, que sincroniza o incio e o trmino de exibio de
duas mdias. ....................................................................... 240
Figura 10.9 Viso estrutural de uma aplicao que utiliza um conector
com retardo. ....................................................................... 242
Figura 10.10 Vises temporal e espacial do exemplo de conector que
permite a uma mdia ser iniciada com um retardo aps uma
outra. ................................................................................. 242
Figura 10.11 Viso estrutural do exemplo de conector de interatividade. .. 246
Figura 10.12 Storyboard do exemplo de utilizao do conector
onKeySelectionStart...................................................... 247
xxv
Figura 10.13 Conector com mltiplos papis de ao, cada qual podendo
ser associado a um nmero indefinido de objetos
(max=unbounded). ........................................................ 250
Figura 10.14 Viso estrutural com elo que utiliza um conector de aes
compostas. ......................................................................... 251
Figura 10.15 Conector com mltiplos papis de condio, ligados pelo
operador and................................................................... 254
Figura 10.16 Viso estrutural com elo que utiliza um conector com
condio composta. ............................................................ 255
Figura 10.17 Viso estrutural do Exemplo 10.5. ...................................... 257
Figura 10.18 Viso de leiaute do Exemplo 10.5. ...................................... 258
Figura 10.19 Vises temporal e espacial do Exemplo 10.5. ...................... 258
Figura 10.20 Viso estrutural de aplicao que manipula o valor de
diversas propriedades. ........................................................ 261
Figura 10.21 Viso estrutural de aplicao que manipula um valor de um
grupo de propriedades. ....................................................... 262
Figura 10.22 Exemplo 10.6, passo 1, contexto replay com as mdias,
sendo que a porta pVideo1 deve estar mapeada para
video1, que o vdeo que deve tocar visvel e com som
inicialmente; video2 deve referenciar um descritor com
visible=false e soundLevel=0. ................................ 263
Figura 10.23 Exemplo 10.6, passo 2, elo para iniciar video2 e
imgCamera2 assim que video1 inicia, fazendo uso do
conector onBeginStart. .................................................. 264
Figura 10.24 Exemplo 10.6, passo 3, elo para encerrar a apresentao de
todas as mdias quando video1 termina, fazendo uso do
conector onEndStop. ...................................................... 264
Figura 10.25 Exemplo 10.6, passo 4, lo para trocar a visibilidade do
video1 pela do video2. Alm disso, troca o boto de
cmera, de imgCamera2 para imgCamera1. ............... 265
Figura 10.26 Exemplo 10.6, passo 5, elo anlogo ao anterior, desta vez
para trocar a visibilidade do video2 pela do video1.
Alm disso, troca o boto de cmera, de imgCamera1
para imgCamera2. ......................................................... 265
Figura 10.27 Vises temporal e espacial do Eemplo 10.6 ......................... 266
xxvi
Figura 10.28 Entrelaamento de vdeos no fluxo elementar. ..................... 269
Figura 11.1 Viso estrutural ilustrando um <switch> com duas
regras. ............................................................................... 280
Figura 11.2 Viso estrutural ilustrando um <switch> com duas regras
e um <switchPort> spAudio. ....................................... 281
Figura 11.3 Switch contendo contextos. ................................................. 282
Figura 13.1 Storyboard ilustrando objetos de mdia independentes e
espelhados. ........................................................................ 297
Figura 13.2 Viso estrutural parcial do exemplo de reuso de objetos de
mdia. ................................................................................ 300
Figura 13.3 Viso estrutural parcial ilustrando a importao de
documentos NCL. .............................................................. 305
Figura 14.1 Exibio do objeto hipermdia declarativo NCL em
dispositivo secundrio. ....................................................... 313
Figura 14.2 Viso estrutural de O Primeiro Joo com objeto
hipermdia declarativo NCL. .............................................. 313
Figura 14.3 Cadeia temporal de NCLAdvert.......................................... 314
Figura 15.1 Viso estrutural da nova verso do exemplo O Primeiro
Joo. ................................................................................. 327
Figura 15.2 Mltiplos dispositivos em classe passiva com mapas de
memrias idnticos. ............................................................ 330
Figura 15.3 Viso estrutural com objeto de mdia do tipo
application/x-ncl-NCL. ................................................... 332
Figura 15.4 Mltiplos dispositivos em classe ativa com exibies
diferentes. .......................................................................... 337
Figura 15.5 Apresentao em um nico dispositivo por ausncia de
registros em classes. ........................................................... 340
Figura 16.1 Sistema de arquivos do documento a ser adicionado. ........... 351
Figura 17.1 Mquina de estado associada a ncoras de contedo ou
propriedade. ....................................................................... 364
Figura 18.1 Paradigma de programao orientado a eventos. ................. 372
xxvii
Figura 18.3 Viso estrutural do Exemplo 18.11. .................................... 378
Figura 18.6 Resultado da execuo do script da Listagem 18.13. ........... 387
Figura 18.9 Imagem dos cavalos do Exemplo 18.4. ............................... 395
Figura 18.10 Viso Estrutural do Exemplo 18.5. ..................................... 397
Listagens
Listagem 3.1 Elementos <media>. ........................................................ 52
Listagem 3.2 Elementos <area>............................................................ 53
Listagem 3.3 Elementos <property>. .................................................... 54
Listagem 3.4 Elementos <body> e <port>. ........................................... 55
Listagem 3.5 Elementos <link> e <bind>. ............................................. 55
Listagem 3.6 Elemento <causalConnector> e seus elementos filhos. ...... 56
Listagem 3.7 Elemento <head> e seus elementos filhos. ........................ 57
Listagem 3.8 Elemento <body> e seus elementos filhos. ........................ 58
Listagem 3.9 Documento NCL. ............................................................ 61
Listagem 3.10 Elementos <region> e <regionBase>. ............................... 62
Listagem 3.11 Elementos <descriptor> e <descriptorBase>..................... 62
Listagem 3.12 Elementos <media> redefinidos. ...................................... 63
Listagem 3.13 Elementos <importBase> e <connectorBase>. .................. 63
Listagem 3.14 Redefinio dos elementos <link>. ................................... 64
Listagem 3.15 Elemento <head> e seus elementos filhos. ........................ 65
Listagem 3.16 Documento NCL com reuso e importao. ....................... 66
xxviii
Listagem 3.17 Conjunto de elementos <media> da nova verso da
aplicao......................................................................... 68
Listagem 3.18 Definio dos novos elementos <region> e dos novos
elementos <descriptor>. ................................................... 69
Listagem 3.19 Definio dos novos relacionamentos. .............................. 70
Listagem 3.20 O Primeiro Joo com sincronismo por interao.............. 73
Listagem 3.21 Uso do elemento <context> na definio da propaganda
da chuteira. ..................................................................... 74
Listagem 3.22 O Primeiro Joo com uso de contextos. ........................... 78
Listagem 3.23 Reso de objeto de mdia. ................................................ 79
Listagem 3.24 O Primeiro Joo com reso. ........................................... 81
Listagem 3.25 Novos elementos para a apresentao do formulrio. ....... 83
Listagem 3.26 Relacionamentos modificados para a nova verso. ........... 84
Listagem 3.27 O Primeiro Joo com uso do canal de interatividade. ....... 87
Listagem 3.28 Uso de mltiplos dispositivos de exibio. ....................... 88
Listagem 3.29 Elementos <ruleBase> e <rule>. ...................................... 90
Listagem 3.30 Elementos <switch> e seus elementos filhos. .................... 91
Listagem 3.31 Redefinio dos relacionamentos para referncia ao
elemento <switch>. ......................................................... 92
Listagem 3.32 O Primeiro Joo com adaptao de contedo. ................. 95
Listagem 3.33 O elemento <media> do tipo application/x-ncl-
settings. ......................................................................... 96
Listagem 3.34 Contexto de interatividade. .............................................. 97
Listagem 3.35 Novo relacionamento para a exibio do cone da
chuteira (icon). ............................................................ 99
Listagem 3.36 Elemento <connector> onBeginVarStart. ...................... 99
Listagem 3.37 O Primeiro Joo com controle de propagandas
interativas. .................................................................... 104
Listagem 3.38 Elementos <transitionBase> e <transition>. ................... 105
Listagem 3.39 Efeito de transio. ........................................................ 105
Listagem 3.40 Efeito de transparncia. ................................................. 105
xxix
Listagem 3.41 Novo relacionamento com animao. ............................. 106
Listagem 3.42 O Primeiro Joo com efeitos de animao e transio. ... 111
Listagem 3.43 Base de regies da nova verso. ..................................... 112
Listagem 3.44 Novos descritores com a definio de atributos para
navegao por teclas. .................................................... 113
Listagem 3.45 Finalizao de todos os elementos em exibio do
contexto menu. .......................................................... 115
Listagem 3.46 Redefinio do elemento <ruleBase> e seus novos
elementos filhos. ............................................................ 116
Listagem 3.47 Elemento <context> menu. ......................................... 117
Listagem 3.48 Redefinio do elemento <link> lMusic. ..................... 118
Listagem 3.49 Passando o foco ao formulrio assim que inicia sua
apresentao. ................................................................ 118
Listagem 3.50 O Primeiro Joo com navegao no menu por teclas. .... 125
Listagem 3.51 Objeto de mdia NCLua................................................. 126
Listagem 3.52 Definio da regio de apresentao do objeto NCLua. .. 127
Listagem 3.53 Elos para incremento da varivel counter. ...................... 128
Listagem 3.54 Elo para exibio do resultado final das mudanas de
ritmo. ............................................................................ 128
Listagem 3.55 Script Lua do elemento <media> changes. .................. 130
Listagem 3.56 O Primeiro Joo com objeto NCLua. ............................ 138
Listagem 5.1 Estrutura do elemento <head>, indicando a ordem
recomendada para seus elementos filhos numa aplicao
NCL. ............................................................................ 152
Listagem 6.1 Definio das bases de regies para dois dispositivos e
suas regies filhas, onde sero exibidas as mdias. ......... 157
Listagem 6.2 Importao de uma base de regies e uso de regio
importada, assumindo que no arquivo
baseRegDocumentario.ncl haja uma regio com
identificador rgLegenda.............................................. 158
Listagem 6.3 Exemplo de definio de regio centralizada em outra. ... 159
xxx
Listagem 6.4 Definio de regies para um menu vertical com quatro
opes........................................................................... 163
Listagem 6.5 Alterao de atributo de uma regio pai. ........................ 163
Listagem 6.6 Esqueleto bsico de uma aplicao NCL. ....................... 166
Listagem 6.7 Definio dos objetos de mdia no ncleo do documento. 168
Listagem 6.8 Definio dos objetos de mdia no ncleo do documento. 168
Listagem 6.9 Listagem completa do exemplo. ..................................... 169
Listagem 7.1 Definio de descritor simples que apenas faz
associao com uma regio. .......................................... 172
Listagem 7.2 Definio de uma base de descritores. ............................ 173
Listagem 7.3 Listagem completa do Exemplo 7.1. .............................. 179
Listagem 7.4 Exemplo de descritor com transparncia. ....................... 185
Listagem 7.5 Definio de descritores de um menu vertical de quatro
itens. ............................................................................. 190
Listagem 7.6 Definio de efeito de transio do tipo fade. ............... 195
Listagem 8.1 Esquema de definio de contexto. ................................. 204
Listagem 8.2 Programa estruturado em contextos. .............................. 204
Listagem 8.3 Exemplo de portas e contextos. ...................................... 206
Listagem 9.1 Definio de ncoras de contedo em uma mdia do tipo
vdeo. ............................................................................ 209
Listagem 9.2 ncoras de contedo. .................................................... 211
Listagem 9.3 ncoras de propriedade e de contedo. .......................... 217
Listagem 9.4 N settings com duas propriedades que podem ser
manipuladas pela aplicao. .......................................... 218
Listagem 10.1 Definio do conector onBeginStart. .......................... 228
Listagem 10.2 Cdigo para definio de um elo que utiliza o conector
onBeginStart para sincronizar o incio das mdias
videoPrincipal e imgInteratividade, utilizando o
connector definido na Figura 10.1 .................................. 237
Listagem 10.3 Cdigo para definio de um conector onEndStop e
elo que o utiliza para sincronizar o trmino das mdias
videoPrincipal e imgInteratividade. ..................... 237
xxxi
Listagem 10.4 Conector e elo para sincronizar o incio e o trmino de
exibio de duas mdias. ................................................ 239
Listagem 10.5 Definio de conector com retardo fixo de trs
segundos. ...................................................................... 241
Listagem 10.6 Definio de conector com retardo parametrizado. ......... 241
Listagem 10.7 Definio de elo que informa ao conector o valor do
retardo desejado. ........................................................... 241
Listagem 10.8 Redefinio de conector e elo para permitir a ligao de
mais de uma mdia num mesmo papel. ........................... 243
Listagem 10.9 Diferentes valores de retardo informados por
parmetros de elo e de ligao. ...................................... 244
Listagem 10.10 Esqueleto de cdigo de definio do elo.......................... 245
Listagem 10.11 Conector e elo que apresentam objetos quando uma
determinada tecla do controle remoto acionada. ........... 247
Listagem 10.12 Cdigo NCL de aplicao que exibe uma imagem de
menu quando o usurio pressiona a tecla vermelha do
controle remoto. ............................................................ 250
Listagem 10.13 Conector onKeySelectionStartStop e elo
correspondente, ilustrando a composio de aes. ......... 251
Listagem 10.14 Cdigo NCL de aplicao que exibe uma imagem de
menu e encerra a imagem de interatividade quando o
usurio pressiona a tecla vermelha do controle remoto. .. 253
Listagem 10.15 Conector
onKeySelection_and_NodeStateTestStartStop
cujas duas condies precisam ser verdadeiras para o
elo correspondente ser acionado. .................................... 256
Listagem 10.16 Conectores onEndStart e
onKeySelectionAbortStop, o elo que mantm o objeto
video1 em loop e o elo que interrompe o objeto em
loop. ............................................................................. 259
Listagem 10.17 Conector que manipula uma propriedade de n. ............. 260
Listagem 10.18 Elo que manipula propriedades de mdia. ....................... 261
xxxii
Listagem 10.19 Elo que manipula posio e dimenses de uma mdia
atravs da propriedade bounds, bem como a mdia
que define a propriedade. ............................................... 262
Listagem 10.20 Aplicao NCL preparada para uma interrupo
quando h vdeos entrelaados. ...................................... 270
Listagem 10.21 Utilizao de um papel denominado getValue para
alinhar o volume de dois udios. .................................... 272
Listagem 10.22 Alinhamento gradual do topo de duas mdias.................. 273
Listagem 10.23 Importao de uma base de conectores. .......................... 274
Listagem 11.1 Definio de uma base de regras. ................................... 278
Listagem 11.2 Regras e switch que seleciona o udio conforme o
idioma em vigor. ........................................................... 280
Listagem 11.3 Regras e switch que seleciona um trecho do udio
conforme o idioma em vigor. ......................................... 281
Listagem 11.4 Regras e switch que seleciona o udio conforme o
idioma em vigor, usando elementos <switchPort>. ..... 282
Listagem 11.5 Switch contendo contextos. ............................................ 283
Listagem 11.6 Definio de um <descriptorSwitch> que seleciona
um descritor que exibe ou oculta as legendas, conforme
as regras rLegendaOn e rLegendaOff. .................. 284
Listagem 11.7 Elos que fazem uso de um <descriptorSwitch> de
maneira idntica que faziam de um <descriptor>
homnimo. .................................................................... 284
Listagem 12.1 Definio de metadados atravs de listas de
propriedades. ................................................................ 288
Listagem 12.2 Definio de metadados atravs de rvore RDF. ............ 289
Listagem 12.3 Definio de metadados em um contexto. ....................... 289
Listagem 12.4 Definio de metadados em um contexto. ....................... 294
Listagem 13.1 Objetos de mdia distintos, mas com o mesmo contedo
(arquivo-fonte definido pelo atributo src). ..................... 296
Listagem 13.2 Reso de objetos de mdia atravs dos atributos refer e
instance. .................................................................... 299
Listagem 13.3 Reso de contextos atravs do atributo refer. ............... 302
xxxiii
Listagem 13.4 Importao de documentos NCL e uso de elementos do
documento importado. ................................................... 304
Listagem 13.5 Reso de documento como um objeto de mdia. .............. 305
Listagem 13.6 Importao de uma base de regies. ............................... 306
Listagem 13.7 Importao de uma base de conectores. .......................... 307
Listagem 14.1 Objeto de mdia com cdigo NCL. ................................. 311
Listagem 14.2 ncoras de contedo em objetos de mdia declarativos. .. 315
Listagem 14.3 Propriedades em objetos de mdia declarativo................. 316
Listagem 14.4 Codificao do objeto hipermdia NCLAdvert. ............... 318
Listagem 14.5 Aplicao O Primeiro Joo com objeto hipermdia
declarativo. ................................................................... 321
Listagem 15.1 O Primeiro Joo com mltiplos dispositivos de
exibio. ....................................................................... 329
Listagem 15.2 Mapa de memria de vdeo apresentada no dispositivo
pai. ............................................................................... 331
Listagem 15.3 Documento NCL da propaganda da chuteira. ................. 333
Listagem 15.4 Externalizao da propriedade
service.currentKeyMaster. ......................................... 334
Listagem 15.5 Iniciao e passagem de controle para o objeto de mdia
NCLAdvert. .................................................................. 334
Listagem 15.6 O Primeiro Joo com mltiplos dispositivos de
exibio independentes. ................................................. 336
Listagem 15.7 Apresentao alternativa exibio em uma classe sem
dispositivos registrados. ................................................ 339
Listagem 17.1 Objeto de mdia com cdigo Lua.................................... 363
Listagem 17.2 Objeto de mdia com cdigo Lua.................................... 367
Listagem 18.1 Paradigma de programao orientado a eventos ............. 373
Listagem 18.2 Representao de evento em NCLua. ............................. 373
Listagem 18.3 Exemplo de evento postado por um NCLua para
sinalizar ao documento NCL o seu fim natural. .............. 374
Listagem 18.4 Exemplo de cdigos NCL e NCLua que tratam um
evento de apresentao de um objeto NCL. .................... 375
xxxiv
Listagem 18.5 Elo disparado pelo cdigo do objeto NCLua. ................. 376
Listagem 18.6 Cdigo NCL do Exemplo 18.1. ..................................... 379
Listagem 18.7 Cdigo do arquivo 1.lua do Exemplo 18.1. .................... 379
Listagem 18.10 Cdigo NCL parcial do Exemplo 18.2. .......................... 385
Listagem 18.11 Cdigo NCLua do Exemplo 18.2. .................................. 386
Listagem 18.12 Cdigo NCL de uma regio a ser associada com um
objeto NCLua ............................................................... 387
Listagem 18.13 Script ilustrando o uso do canvas................................... 388
Listagem 18.14 Cdigo NCL do Exemplo 18.3. ..................................... 390
Listagem 18.15 Primeira parte do cdigo NCLua do Exemplo 18.3. ....... 390
Listagem 18.16 Segunda parte do cdigo NCLua do Exemplo 18.3. ....... 391
Listagem 18.17 Terceira parte do cdigo NCLua do Exemplo 18.3. ........ 392
Listagem 18.18 Exemplo (ruim) de animao em NCLua. ...................... 392
Listagem 18.19 Exemplo de animao em NCLua que utiliza um
temporizador. ................................................................ 393
Listagem 18.20 Exemplo de uso de corrotinas para realizar uma
animao. ..................................................................... 394
Listagem 18.21 Tabela representando os cavalos .................................... 395
Listagem 18.22 Funo de redesenho ..................................................... 396
Listagem 18.23 Corrotina para animao dos cavalos ............................. 396
Listagem 18.24 Elemento <media> para a entrada .................................. 399
Listagem 18.25 Elementos <media> para as sadas ................................. 400
Listagem 18.26 Relacionando o campo de entrada e o primeiro campo
de sada ......................................................................... 400
Listagem 18.27 Relacionando o campo de entrada e o segundo campo de
sada ............................................................................. 400

xxxv
Tabelas
Tabela 1.1 Codificao de udio no sistema brasileiro de TV digital
terrestre ............................................................................... 12
Tabela 1.2 Codificao de vdeo no sistema brasileiro de TV digital ....... 14
Tabela 1.3 Ambientes de aplicaes para receptores fixos e mveis ........ 31
Tabela 1.4 Ambientes de aplicaes para receptores portteis ................ 31
Tabela 1.5 Ambientes de aplicaes para servios IPTV ........................ 32
Tabela 4.1 reas funcionais da NCL 3.0 ............................................. 142
Tabela 4.2 Identificadores dos mdulos de NCL 3.0 ............................. 144
Tabela 4.3 Identificadores dos perfis NCL 3.0 ..................................... 146
Tabela 5.1 Elementos, Atributos e Contedo (Elementos Filhos) que
Definem a Estrutura de Documentos NCL no Perfil EDTV . 152
Tabela 5.2 Mdulos que Definem os Elementos da NCL no Perfil
EDTV, Filhos dos Elementos <head> e <body>, e os
Respectivos Captulos que os Descrevem ............................ 153
Tabela 6.1 Elementos, Atributos e Contedo (Elementos Filhos)
Definidos pelo Mdulo Layout do Perfil EDTV ................. 170
Tabela 7.1 Elementos, Atributos e Contedo (Elementos Filhos) de
uma Base de Transies ..................................................... 191
Tabela 7.2 Tipos e Subtipos de Transio ............................................ 192
Tabela 7.3 Elementos, Atributos e Contedo (Elementos Filhos) das
Transies ......................................................................... 194
Tabela 7.4 Elementos, Atributos e Contedo (Elementos Filhos) que
Definem Descritores para o Perfil EDTV ............................ 196
Tabela 8.1 Alguns Tipos MIMES ........................................................ 202
Tabela 8.2 Elementos, Atributos e Contedo que Definem Ns de
Mdia, Contextos e Portas no Perfil EDTV ......................... 207
Tabela 9.1 Alguns nomes reservados para propriedades e seus valores
default ............................................................................... 215
Tabela 9.2 Variveis de Ambiente do Grupo system .......................... 220
Tabela 9.3 Variveis de Ambiente do Grupo user ............................... 222
xxxvi
Tabela 9.4 Variveis de Ambiente do Grupo default .......................... 222
Tabela 9.5 Variveis de Ambiente do Grupo service .......................... 223
Tabela 9.6 Variveis de Ambiente do Grupo SI .................................... 223
Tabela 9.7 Variveis de Ambiente do Grupo channel......................... 223
Tabela 9.8 Elemento e Atributos que Definem ncoras de Contedo e
Propriedades no Perfil EDTV ............................................. 224
Tabela 10.1 Papis Predefinidos de Condio........................................ 229
Tabela 10.2 Papis Predefinidos de Ao............................................... 230
Tabela 10.3 Valores de atributos eventType e transition assumidos
por default quando o atributo role usa palavras reservadas
em uma condio ............................................................... 232
Tabela 10.4 Valores de atributos eventType assumidos por default
quando o atributo role usa palavras reservadas em uma
ao ................................................................................... 234
Tabela 10.5 Elementos, atributos e contedo que definem elos ............... 245
Tabela 10.6 Cdigos de teclas definidos para uso em aplicaes NCL .... 248
Tabela 10.7 Operadores de comparao que podem ser utilizados em
elementos <assessmentStatement>. ........................... 254
Tabela 10.8 Elementos, atributos e contedo que definem conectores no
perfil NCL EDTV .............................................................. 275
Tabela 11.1 Operadores de Comparao que Podem ser Utilizados nas
Regras ............................................................................... 278
Tabela 11.2 Elementos e Atributos que Definem Regras no Perfil
EDTV ................................................................................ 285
Tabela 11.3 Elementos e Atributos que Definem Elementos <switch>
no Perfil NCL EDTV ......................................................... 285
Tabela 11.4 Elementos e Atributos que Definem Elementos
<descriptorSwitch> no Perfil NCL EDTV .................... 286
Tabela 12.1 Elementos, Atributos e Contedo (Elementos Filhos)
Definidos pelo Mdulo Metainformation para o Perfil
EDTV ................................................................................ 288
xxxvii
Tabela 13.1 Comportamento da Aplicao de Exemplo de Reuso de
Objetos de Mdia. Estado o significa Occurring e
Estado s Significa Sleeping .......................................... 300
Tabela 13.2 Elementos e Atributos Relacionados ao Reso de
Documentos e Bases de Documentos NCL no Perfil NCL
EDTV ................................................................................ 307
Tabela 16.1 Descritor de Evento para Comandos de Edio ................... 342
Tabela 16.2 Comandos de Edio para o Gerenciador da Base Privada
Ginga ................................................................................. 344
Tabela 16.3 Identificadores Usados nos Comandos de edio ................. 348
Tabela 16.4 Descritor de evento para abrir uma base privada ................. 350
Tabela 16.5 Descritor de evento para ativar uma base privada aberta ..... 351
Tabela 16.6 Descritor de evento para adicionar um documento a uma
base privada aberta ............................................................ 352
Tabela 16.7 Descritor de evento para iniciar a exibio de um
documento ......................................................................... 353
Tabela 16.8 Descritor de evento para acrescentar uma regio a uma
base de regies ................................................................... 354
Tabela 16.9 Descritor de evento para remover uma regio ...................... 354
Tabela 16.10 Descritor de evento para adicionar uma interface a um
objeto de um documento ..................................................... 355
Tabela 16.11 Descritor de evento para acrescentar um objeto a um
documento ......................................................................... 356
Tabela 16.12 Descritor de evento para acrescentar um elo a um
documento ......................................................................... 356
Tabela 16.13 Descritor de evento para parar a exbio de um documento . 357
Tabela 16.14 Descritor de evento para savar um documento .................... 357
Tabela 16.15 Descritor de evento para fechar uma base privada ............... 358

1
PARTE I

Introduo TV Digital e
Linguagem NCL

2
Captulo
1

TV Digital:
Fundamentos e
Padres
Um sistema de TV digital (seja ele para TV aberta ou terrestre, IPTV,
WebTV, P2PTV etc.) composto por uma srie de mdulos funcionais. Em
sistemas para TV digital aberta, cada um dos mdulos funcionais segue, em
geral, padres internacionais ou nacionais de operao. Servios IPTV
tendem tambm a seguir Recomendaes da Unio Internacional de
Telecomunicaes (ITU-T International Telecommunication Union). Este
captulo apresenta os fundamentos da TV digital interativa e os padres de
referncia usuais para sistemas de TV digital aberta e IPTV, com destaque
para o Sistema Brasileiro de TV Digital, em particular seu middleware,
denominado Ginga.
1

1
Este captulo se baseia em Soares e Barbosa (2008). O uso do material foi gentilmente cedido pela
Sociedade Brasileira de Computao.
3
1.1 Introduo
A mudana da TV analgica para a TV digital se faz sentir,
primeiramente, pela melhor qualidade de imagem e de som.
Em um sistema de transmisso no-guiado (caso da TV digital terrestre
analgica e digital), o canal de transmisso introduz diversas interferncias e
rudos no sinal original, limitando a capacidade do sistema, como
apresentamos a seguir.
O rudo aleatrio est presente em todo o espectro de frequncias e no
pode ser evitado. Na transmisso analgica, ele provoca queda na qualidade
do sinal recebido, causando o aparecimento de chuviscos na imagem. A
queda da qualidade depende da relao entre as potncias do sinal e do rudo
(relao S/N). medida que a relao diminui e isso pode acontecer pela
atenuao do sinal quando nos afastamos da fonte , diminui tambm a
qualidade do sinal recebido. Nos sistemas digitais, o rudo pode modificar um
nvel digital do sinal transmitido a ponto de ele passar a ser confundido com
outro nvel. Uma baixa relao S/N pode, assim, aumentar a probabilidade de
erro de bit. Para evitar o problema, todos os padres de transmisso dos
sistemas de TV digital terrestre utilizam cdigos corretores de erro. Se a taxa
de erro estiver abaixo de um limiar, o cdigo corretor capaz de corrigir
todos os erros introduzidos pelo canal e no haver queda da qualidade da
imagem. Entretanto, se a taxa de erros estiver acima do limiar, o sistema no
ser capaz de corrigir o cdigo transmitido e poder at mesmo introduzir
erros, em vez de corrigi-los. Por isso, usual dizer que, na TV digital,
teremos um sinal perfeito, sem nenhum chuvisco ou nenhum sinal. Como a
relao S/N decai com a distncia do transmissor, caso o sistema no esteja
bem dimensionado, pode haver problemas de cobertura, com a introduo das
chamadas reas de sombra.
A deteriorao de um sinal recebido tambm pode dar-se pelos mltiplos
percursos seguidos desde sua origem, como habitual nos sistemas de
transmisso por radiodifuso. Cada um dos percursos pode apresentar
atenuao e atraso diferentes dos demais, fazendo com que o sinal recebido
seja formado pela sobreposio dos vrios sinais provenientes dos diferentes
caminhos, como ilustra a Figura 1.1. O efeito em uma TV analgica o
aparecimento de fantasmas. J na TV digital, mltiplos percursos podem
produzir uma interferncia entre smbolos (ISI Inter-Symbol Interference),
isto , a sobreposio entre os bits transmitidos, como mostra o sinal recebido
na casa receptora da Figura 1.1. Se o intervalo de durao de um smbolo
(um smbolo representa um padro de bits) transmitido for muito pequeno,
bem como o intervalo de guarda entre os smbolos, a ponto de a diferena de
retardo entre os mltiplos percursos causar a superposio de smbolos
diferentes, a taxa de erros de recepo poder aumentar. Se nenhuma
4
contramedida for tomada, a ISI pode inviabilizar a recepo. Como sempre,
na TV digital, tudo ou nada.
Mltiplos percursos
(reflexes)

Figura 1.1 Efeito de mltiplos percursos.
O rudo impulsivo outra fonte de degenerao de um sinal. Rudo
impulsivo aquele decorrente, por exemplo, de interferncias de motores
eltricos (aparelhos eletrodomsticos, motores industriais, elevadores etc.),
veculos automotores, transformadores de distribuio de energia eltrica,
descargas atmosfricas etc. Como o rudo aleatrio, o rudo impulsivo
provoca, na transmisso analgica, a queda na qualidade do sinal recebido
(aparecimento de chuviscos na imagem). No caso dos sistemas de TV
digital, se o rudo demorar tempo suficiente para causar uma rajada de erros
em smbolos consecutivos do sinal, o sistema corretor de erros pode no ser
capaz de corrigir o cdigo transmitido, levando queda da recepo. Sistemas
de TV digital devem ser robustos o suficiente para evitar o problema.
Enfim, por pior que o sinal analgico chegue televiso, o telespectador
consegue receb-lo. No caso do sinal digital, ou ele chega perfeito ou no ser
recebido. Por isso, importante avaliar qual sistema de transmisso o mais
robusto, para garantir a chegada adequada do sinal digital nas residncias.
Note tambm que algumas dessas interferncias, sempre presentes na TV
digital terrestre, podem no ser significante em meios de transmisso guiados,
como, por exemplo, nos meios utilizados na TV a cabo.
Melhor qualidade de imagem e som tambm se fazem sentir com a
aplicao de tcnicas de compresso de dados em sinais digitais, permitindo a
produo de sinais de maior resoluo na fonte, ou seja, sinais de melhor
qualidade.
5
A TV analgica tem uma qualidade de imagem prxima da TV digital
padro (SDTV), isto , 30 quadros por segundo, com cada quadro sendo
composto por 480 linhas ativas entrelaadas, em uma TV com relao de
aspecto igual a 43. O critrio para o dimensionamento desses parmetros de
imagem sempre atender a acuidade visual (o que o olho humano consegue
discernir) dentro das limitaes tecnolgicas. Como mostra a Figura 1.2, a
qualidade SDTV foi projetada com um tamanho de pixel tal que a acuidade
visual de um minuto de grau fosse respeitada, a uma distncia de sete vezes a
altura da tela. Nessa distncia, o ngulo de visualizao horizontal de 10
graus (suficiente para que o ser humano capture informaes).
h = 480
640 pixels
1 minuto de grau
7 x h
Elemento de Imagem
(pixel)
linhas

Figura 1.2 Parmetros da SDTV.
Na qualidade SDTV, recomendao BT 601-4 [ITU-R BT.601-4, 1994]
(ver Apndice A), so gerados aproximadamente 162 Mbps (29,97
quadros/seg 480 linhas/quadro 704 pixels/linha (8 bits de luminncia +
8 bits de crominncia)). Essa taxa de bits deve poder ser transmitida em um
canal de TV de 6 MHz (no caso da TV terrestre do Brasil), que suporta uma
taxa de bits da ordem de 19,3 Mbps. As tcnicas atuais de compresso
permitem essa taxa de compresso (162:19,3) e muito mais. Temos assim,
com a tecnologia digital, a possibilidade de ter uma qualidade de imagem
ainda melhor que a obtida na SDTV.
De fato, a TV digital terrestre possibilita, no mesmo canal de 6 MHz, a
transmisso da qualidade chamada de alta definio (HDTV), com os
seguintes parmetros: 30 quadros por segundo, 1.920 pixels por linha, 1.080
linhas, com a acuidade visual de 1' de grau obtida a uma distncia de
6
aproximadamente trs vezes a altura da tela, que passa a ter uma relao de
aspecto de 169. Nessa distncia e com essa relao de aspecto, o ngulo de
visualizao horizontal de 30 graus, possibilitando ao telespectador maior
sensao de presena na cena (imerso).
Graas s tcnicas de compresso de dados, a melhora em um sistema
de TV digital tambm se faz sentir na qualidade do udio. Dentro da mesma
faixa de 6 MHz de um sistema terrestre tambm possvel transmitir udio
no padro 5.1 (multicanal), dando ao telespectador, agora sob o aspecto da
sensibilidade auditiva, maior sensao de imerso na cena.
As tcnicas de compresso digital permitem tambm a alternativa de se
ter vrios programas de menor qualidade de definio na TV digital terrestre;
por exemplo, de se ter vrios programas de qualidade SDTV, em vez de se ter
um nico programa (udio principal e vdeo principal) de maior qualidade
(HDTV) ocupando toda a faixa de 6 MHz. Essa nova possibilidade advinda
do emprego da tecnologia digital o que chamamos de multiprogramao.
Todos os programas em um mesmo canal de 6 MHz podem estar
relacionados a um mesmo contedo ou no. Um exemplo de relacionamento
poderia ser a transmisso de um jogo de futebol, no qual uma cmera poderia
estar posicionada atrs de um dos gols, captando tambm o som proveniente
da torcida ali posicionada, outra cmera poderia estar posicionada no outro
gol, ainda uma outra no centro do estdio etc. Ao telespectador seria dada a
opo de escolher qual cmera visualizar em um determinado momento ou
mesmo visualizar todas simultaneamente. Quando o contedo da
multiprogramao est relacionado, muitas vezes o processo chamado de
multicmera.
Em uma multiprogramao, entretanto, os vrios programas podem ser
completamente independentes, o que nos leva a revisitar o conceito de canal.
Na TV analgica, o canal de 6 MHz (ou seja, o canal de frequncia) era
confundido com o canal de programao (normalmente associado a uma
radiodifusora). Agora no precisa ser mais assim. Em um mesmo canal de
frequncia podemos ter vrios programas diferentes.
O impacto da TV digital muito mais significativo, no entanto, do que a
simples troca de um sistema de transmisso analgico para digital, e muito
mais do que uma melhora da qualidade de imagem e de som. Mais do que
isso, um sistema de TV digital permite um nvel de flexibilidade inatingvel
com a difuso analgica. Um componente importante dessa flexibilidade a
possibilidade de expandir as funes do sistema por aplicaes construdas
sobre a base de um sistema padro de referncia.
Tais aplicaes so programas computacionais, residentes em um
dispositivo receptor ou provenientes de dados enviados conjuntamente
(multiplexados) com o udio principal e o vdeo principal de um programa
7
televisivo. Assim, uma das caractersticas mais importantes da TV digital a
integrao de uma capacidade computacional significativa no dispositivo
receptor, permitindo o surgimento de uma vasta gama de novos servios,
como a oferta de guias eletrnicos de programas, o controle de acesso e a
proteo de contedo, a distribuio de jogos eletrnicos, o acesso a servios
bancrios (T-banking), servios de sade (T-health), servios educacionais
(T-learning), servios de governo (T-government) e, em especial, os
programas no-lineares.
Um programa no-linear um programa de TV composto no apenas
pelo udio principal e vdeo principal, mas tambm por outros dados
transmitidos em conjunto. Esses dados se constituem de outros udios e
vdeos, alm do principal, imagens, textos etc., e uma aplicao relacionando
temporalmente e espacialmente todos esses objetos de mdia, incluindo o
vdeo principal e o udio principal. Esses relacionamentos podem ser guiados
por interaes do usurio telespectador, ao qual poder ser delegado o
controle do fluxo de um programa televisivo, determinando se um contedo
especfico deve ser exibido ou no e, em sendo, a forma como ser exibido.
Como o fluxo de um programa televisivo
2
deixa de ser contnuo em sua
concepo e com vrios caminhos alternativos de exibio, esse programa
chamado de no-linear.
Resumindo, na TV analgica, vdeo, udio e alguma informao de
dados limitada (como o closed captioning) so transmitidos multiplexados, de
tal forma que um receptor, de projeto relativamente simples, possa decodificar
e reagrupar os vrios elementos do sinal para produzir um programa. Como
tal, um programa completo transmitido em sua forma final. Em um sistema
de TV digital, contudo, nveis adicionais de processamento so necessrios. O
receptor processa o fluxo digital extraindo do sinal recebido uma coleo de
elementos do programa (vdeo principal, udio principal, outros vdeos e
udios, imagens, textos etc.), que denominamos anteriormente objetos de
mdia, que compem o servio selecionado pelo consumidor. Essa seleo
feita usando informaes do sistema e do servio, que tambm so
transmitidas. Uma vez que os objetos de mdia tenham sido recebidos, eles
so exibidos de acordo com um documento de especificao (parte da
aplicao), tambm recebido junto com os dados, que ao ser processado se
encarrega da exibio final.
A capacidade computacional necessria ao novo sistema pode ser
integrada no prprio dispositivo exibidor: um aparelho de TV digital, um

2
Como o leitor j deve ter percebido, muitos termos usados em TV digital devem ser adjetivados
para sua inteira compreenso. Visando simplificar o texto, vamos adotar a seguinte conveno: chamaremos
o programa televisivo simplesmente de programa ou programa de TV; um programa computacional,
incluindo seus dados, ser chamado de aplicao ou aplicativo. Note que, na TV digital, um programa no-
linear uma aplicao contendo o udio e vdeo principal entre os seus objetos de mdia.
8
celular, um PDA etc. Como h um grande legado de TVs analgicas, uma
soluo simples para oferecimento desses novos servios nesses sistemas
receptores legados utilizar, junto TV, um sistema de processamento
capaz de tratar corretamente o sinal recebido, decodific-lo e exibi-lo de
forma consistente: no apenas o udio e vdeo principal, mas as aplicaes e
os servios avanados. Esse sistema de processamento chamado de
conversor digital (ou set-top box).
A Figura 1.3 apresenta o diagrama em blocos de um receptor de TV
digital terrestre, que pode estar embutido ou ser externo ao aparelho exibidor,
como mencionamos. O sinal recebido, depois de sintonizado e demodulado
(retirado do canal de frequncia), separado (demultiplexado) e entregue para
os decodificadores de udio e de vdeo, e para processamento em uma CPU.
Note, na figura, que o receptor tem acesso a outra rede (rede externa na
figura) atravs da qual pode receber ou enviar dados, conforme comandado
pela aplicao recebida. O canal de acesso a essa rede chamado de canal de
retorno ou canal de interatividade, conforme veremos no decorrer do
captulo. Em um sistema de IPTV ou P2PTV, usualmente o sinal no
modulado, entrando direto em um mdulo demultiplexador aps ser
sintonizado; mais ainda, tambm usual que o canal de interatividade seja
constitudo pela mesma rede de transmisso por onde vm os dados
multiplexados de uma transmissora.
Demodulador
Decod. do Canal
Dec. udio
Dec. Vdeo
CPU
Memria
VC
RF
IR CR
Video out
Audio
Surround
Audio out
RF out
Rede
Externa
RF in
API SO

Figura 1.3 Receptor de TV digital.
1.2 Sistema de TV Digital: Viso Geral
Um sistema de TV digital um sistema tpico cliente/servidor. Em um
sistema de TV digital terrestre, o servidor compe o ambiente de uma
9
radiodifusora (parte esquerda da Figura 1.4) ou de um provedor de contedo,
e o cliente, o ambiente do usurio telespectador (parte direita da Figura 1.4).
Difuso e Acesso
Transmisso
Cod. Canal / Modulao
MUX
TS
Encap. IP
Cod. de
Sinais Fonte
Fluxos de
Dados
Contedo
da Aplicao
Terminal de Acesso
Recepo
Decod. Canal / Demodulao
DEMUX
TS
Desencap. IP
Decod. de
Sinais Fonte
Middleware
Aplicaes
Interativas
udio Vdeo
Canal de Interatividade
Especificao
da Aplicao
Contedo da Aplicao

Figura 1.4 Sistema de TV digital terrestre.
Um programa composto de um udio principal e um vdeo principal,
capturado ao vivo de uma cmera, como na Figura 1.4 (lado esquerdo) ou
proveniente de um servidor de vdeo. Um programa pode tambm conter
dados adicionais, incluindo o documento da aplicao que define o
relacionamento entre os vrios objetos de mdia definidos nesses dados. Os
dados adicionais podem vir encapsulados no formato IP ou em outro formato,
como veremos oportunamente. O vdeo e o udio so entregues aos
codificadores digitais, responsveis pela gerao dos respectivos fluxos de
vdeo principal e udio principal comprimidos. Esses fluxos, mais os fluxos
dos outros dados, so ento multiplexados em um nico sinal, denominado
fluxo de transporte (TS Transport Stream). Aps, no caso de um sistema
terrestre, o fluxo de transporte modulado para um canal de frequncia e
transmitido no ar. J em um servio IPTV, em geral, o fluxo de transporte
transmitido diretamente em pacotes IP sem qualquer modulao.
Do lado da recepo (lado direito da Figura 1.4), o sinal recebido e
demodulado (retirado do canal de frequncia sintonizado), no caso da TV
terrestre, e entregue ao demultiplexador, que separa os fluxos de udio
principal e vdeo principal (entregando-os a decodificadores apropriados) dos
fluxos de dados, que so entregues para processamento.
10
O processamento dos dados recebidos pode demandar novos dados,
obtidos pelo canal de interatividade. Dados tambm podem ser enviados pela
aplicao emissora ou outro destino qualquer na rede do canal de
interatividade.
Um sistema de TV digital composto por um conjunto de padres que
regulam cada um dos procedimentos descritos na Figura 1.4, chamados
padres de referncia. Nas subsees seguintes discutiremos vrios desses
padres, seguindo a Figura 1.5 no sentido de cima para baixo.
8-VSB COFDM
MPEG2
MPEG2 - SDTV MPEG2 - HDTV
MPEG2 BC MPEG2 AAC DOLBY AC3
Vdeo
udio
BST-OFDM
MPEG2
H.264 HP@L4.0 H.264 BP@L1.3
MPEG - 4 HE-AAC@L4
Vdeo
udio MPEG - 4 HE-AAC@L3

Figura 1.5 Padres de referncia para TV digital terrestre.
1.2.1 Codificao do udio
Um sinal digital carrega, em geral, muita informao redundante. Se
eliminarmos essa redundncia, conseguiremos reduzir em muito a quantidade
de bits gerados.
Quando eliminamos apenas a redundncia de um sinal, no h perda de
informao, e dizemos que houve uma compactao ou compresso sem
perdas. No entanto, podemos tambm diminuir a quantidade de bits com
alguma perda de informao. Dependendo de quem for o usurio de uma
informao, parte da informao pode ser considerada pouco til. Raramente
necessrio manter o sinal original 100% intacto, no caso das mdias de
vdeo, udio e imagens estticas, uma vez que o usurio final perderia de
qualquer forma parte da informao por limitaes fsicas; por exemplo,
limitaes do ouvido e olho humanos. A quantidade de informao que
podemos perder pode ser dependente do usurio, mas tambm pode depender
da tarefa em desenvolvimento: por exemplo, perder um pouco da nitidez de
um vdeo em uma videotelefonia pode ser perfeitamente aceitvel, enquanto a
perda da qualidade do vdeo pode ser inadmissvel em uma aplicao mdica.
Quando na reduo dos dados gerados h perda de informao, dizemos que
houve uma compresso com perdas ou simplesmente compresso. Quando
essa perda no perceptvel pelo ser humano, dizemos que houve uma
compresso perceptualmente sem perdas.
11
Em um sistema de TV digital, tcnicas de compresso perceptualmente
sem perdas so empregadas no udio gerado, levando em conta o modelo
psicoacstico humano. O modelo divide o domnio de frequncia audvel em
vrias bandas, e sobre elas aplica filtros, levando em conta a sensibilidade do
ouvido humano, o mascaramento de frequncia, o mascaramento temporal e a
forma como o ser humano percebe udio multicanal, como discutido no
Apndice A. O resultado um udio de alta qualidade e com baixa taxa de
bits gerada.
O sistema americano de TV digital terrestre usa o padro de codificao
AC3/ATSC [ATSC AC3, 2005], antigo nome da codificao chamada hoje
de Dolby Digital (DD). A codificao, proprietria da empresa Dolby, utiliza
seis canais de udio, sendo cinco com alta qualidade (20 a 20 KHz) e um
apenas para as baixas frequncias (20 a 120 Hz).
O sistema europeu de TV digital terrestre usa o padro MP2 (MPEG-1
Layer 2) [ISO/IEC IS 11172-3, 1993], mas algumas implementaes seguem
o padro MPEG-2 Advanced Audio Coding (AAC) [ISO/IEC 13818-7,
1997], tambm adotado pelo sistema terrestre japons.
O MPEG-2 AAC, tambm conhecido como MPEG-2 Parte 7 ou
MPEG-4 Parte 3, foi projetado como um codec (codificador/decodificador),
de desempenho melhor em relao ao MP3 (MPEG-1 Layer 3) [ISO/IEC IS
11172-3 1993], para codificao de udio em taxas de bits mdias a altas. A
AAC considerada o estado da arte para udio de alta qualidade em uma
taxa de bits tpica de 128 Kbps. Abaixo dessa taxa, a qualidade do udio
comea a degradar, o que pode ser compensado por tcnicas de
melhoramento, como SBR (Spectral Band Replication) e PS (Parametric
Stereo).
A SBR uma tcnica de extenso que permite a mesma qualidade de
som do AAC a aproximadamente metade da taxa de bits. A combinao de
AAC e SBR chamada de HE-AAC (High efficiency-AAC) verso 1
[ISO/IEC 14496-3, 2004], tambm conhecida como aacPlus v1.
A PS aumenta a eficincia de codificao ainda mais, atravs de uma
representao paramtrica da imagem estreo de um sinal de entrada. A
combinao de AAC, SBR e PS chamada de HE-AAC (High efficiency-
AAC) verso 2 [ISO/IEC 14496-3, 2004].
Note que o HE-AAC, definido no padro MPEG-4, um superconjunto
do ncleo AAC, que estende a alta qualidade de udio AAC para taxas de bits
mais baixas. Decodificadores HE-AAC v2 so capazes de decodificar fluxos
HE-AAC v1 e fluxos AAC. Por sua vez, decodificadores HE-AAC v1 so
tambm capazes de decodificar fluxos AAC.
12
O sistema brasileiro de TV digital terrestre adotou o padro MPEG-4
para a codificao do udio principal de um programa [ABNT NBR 15602-2,
2011], com as caractersticas apresentadas na Tabela 1.1.
Tabela 1.1 Codificao de udio no sistema brasileiro de TV digital terrestre
Receptores Fixos e Mveis Receptores Portteis
Padro ISO/IEC 14496-3 (MPEG-4
AAC)
ISO/IEC 14496-3 (MPEG-4
AAC)
Nvel e perfil AAC@L4 (para multicanal 5.1)
HE-AAC v1@L4 (para estreo)
HE-AAC v2@L3 (dois canais)
Taxa de
amostragem
48kHz 48kHz
1.2.2 Codificao do Vdeo
Um sinal de vdeo digital carrega muita informao redundante,
espacialmente (redundncia intraquadro) e temporalmente (redundncia
interquadros).
Em um quadro de vdeo no ocorre, em geral, mudana abrupta de um
pixel para um pixel consecutivo, exceto nos contornos dos objetos. Em
particular, podemos empregar a codificao JPEG [ISO/IEC 10918-1, 1994]
em cada quadro do vdeo para tirarmos proveito dessa redundncia espacial.
Essa tcnica, aplicada quadro a quadro, constitui a base da codificao
chamada MJPEG (Motion JPEG). Entretanto, ao empregarmos essa
codificao, estaremos levando em conta apenas a redundncia intraquadro,
quando a maior redundncia pode estar nas informaes contidas em quadros
consecutivos (redundncia interquadros), o que explorado no padro MPEG
vdeo.
No padro MPEG-2 vdeo [ISO/IEC 13818-2, 2000], cada bloco
(conjunto de 88 pixels) pode ser codificado usando apenas a informao
intraquadro. Quadros em que todos os blocos so codificados dessa forma so
denominados quadros I.
Um macrobloco (conjunto de 1616 pixels) pode tambm ser codificado
de forma preditiva. A predio MPEG pode ser feita baseada em quadros
passados e em quadros futuros da sequncia de um vdeo. Quando a predio
feita baseada em um quadro passado, codificado o erro de predio
(diferena do macrobloco que se quer codificar para o macrobloco de
referncia do quadro passado), usando os mesmos procedimentos usados para
os blocos intraquadros, e o vetor de movimento (que d a posio relativa do
macrobloco que se quer codificar para o macrobloco de referncia do quadro
13
passado). Quadros codificados usando esse tipo de predio so chamados
quadros P. No MPEG-2 vdeo, a predio sempre baseada no primeiro
quadro do tipo I ou P anterior.
Macroblocos tambm podem ser codificados baseados no primeiro
quadro I ou P, posterior ou anterior. Nesse caso teremos dois quadros de
referncia para a procura do melhor casamento. A codificao pode ser
realizada baseada no quadro anterior, no quadro posterior ou, ainda, na
interpolao dos quadros anterior e posterior. Quadros codificados usando
esse tipo de predio so chamados quadros B.
O padro MPEG-2 vdeo admite vrios formatos de quadros e diferentes
resolues para as componentes de crominncia (subamostragem de
crominncia). De fato, o MPEG-2 especifica vrios conjuntos de parmetros
de restrio, que so definidos nos seus perfis e nveis. Um perfil especifica
as facilidades de codificao que sero utilizadas (por exemplo, tipos de
quadros, subamostragem etc). Um nvel especifica a resoluo dos quadros,
as taxas de bits etc.
Para a TV digital, o MPEG-2 vdeo define o perfil principal (utiliza os
quadros I, P e B e uma subamostragem de cor 4:2:0) e os nveis principal
(720 pixels/linha 480 linhas 30 quadros/seg) e alto (1.920 pixels/linha
1080 linhas 30 quadros/seg), respectivamente para SDTV e HDTV. Os
sistemas americano, europeu e japons de TV digital terrestre adotam o
MPEG-2 vdeo como seu padro para codificao do vdeo.
O sistema brasileiro de TV digital terrestre emprega uma tcnica de
codificao mais recente: o H.264 [ISO/IEC 14496-10, 2005], tambm
conhecido como MPEG-4 Parte 10 ou MPEG-4 AVC (Advanced Video
Coding). O objetivo do projeto H.264/AVC foi criar um padro capaz de
prover um vdeo de boa qualidade a uma taxa substancialmente mais baixa do
que os padres anteriores (MPEG-2 entre eles), sem aumentar muito sua
complexidade, para facilitar uma implementao barata e eficiente. Um
objetivo adicional era fornecer flexibilidade suficiente para permitir sua
aplicao em uma variedade de sistemas de taxas de transmisso altas e
baixas, e tambm de resolues de vdeo altas e baixas.
O H.264 contm vrias facilidades novas que permitem uma
compresso de vdeo muito mais eficiente e flexvel. As tcnicas empregadas
fazem do H.264 um padro significativamente melhor do que os padres
anteriores, sob uma variedade de circunstncias e ambientes de aplicao, em
particular o ambiente de TV digital, onde ele oferece um desempenho bem
melhor do que o MPEG-2 vdeo. Em especial nas situaes de alta resoluo
e alta taxa de bits, o padro H.264, para a mesma qualidade de vdeo, gera
uma taxa 50% ou ainda menor do que a taxa gerada pelo padro MPEG-2.
14
Da mesma forma que o padro MPEG-2 vdeo, o H.264 dividido em perfis e nveis. No
caso do sistema brasileiro de TV digital terrestre, so usados os perfis alto (HP) para os
receptores fixos e mveis e o perfil base (BP) para receptores portteis [ABNT NBR 15602-
1, 2007], conforme indica a Tabela 1.2.
Tabela 1.2 Codificao de vdeo no sistema brasileiro de TV digital
Receptores Fixos e Mveis Receptores Portteis
Padro ITU-T H.264 (MPEG-4 AVC) ITU-T H.264 (MPEG-4 AVC)
Nvel e perfil HP@L4.0 BP@L1.3
Nmero de
linhas do nvel
480 (4:3 e 16:9), 720 (16:9),
1080 (16:9)
SQVGA (160120 ou 16090),
QVGA (320240 ou 320180) e
CIF (352288); todos em 4:3 e 16:9
Taxa de quadros 30 e 60 Hz 15 e 30 Hz
1.2.3 Sistema de Transporte
Tanto os sistemas americano, europeu e japons quanto o sistema
brasileiro de TV digital terrestre padronizam a forma como informaes
audiovisuais, juntamente com os dados, devem ser multiplexadas em um
nico fluxo. Todos os sistemas mencionados adotam o mesmo padro de
multiplexao, MPEG-2 System [ISO/IEC 13818-1, 2000], com poucas
variaes. Muitos sistemas IPTV tambm adotam o MPEG-2 System.
O MPEG-2 System adiciona aos fluxos elementares de udio principal e
vdeo principal informaes para suas exibies sincronizadas. A
sincronizao realizada seguindo o paradigma de eixo do tempo (timeline)
pela adio de selos de tempo (timestamps) a conjuntos de amostras
codificadas de vdeo e udio, baseadas em um relgio compartilhado. A
Figura 1.6 ilustra o procedimento.
MUX
MPEG 2
System
DEMUX
MPEG 2
System
y
y
x x
z
z
udio principal
vdeo principal

Figura 1.6 Multiplexao do udio principal e vdeo principal.
15
A gerao e a multiplexao dos fluxos de dados (dos outros dados alm
do udio e vdeo principal) tambm so determinadas pelo padro. Vejamos
primeiro a multiplexao, partindo de fluxos j gerados.
1.2.3.1 Multiplexao de Dados
Os fluxos de dados podem ser transportados atravs de servios
sncronos (fracamente acoplados), sincronizados (fortemente acoplados) ou
assncronos (desacoplados).
O servio de transporte sncrono assume que os fluxos de dados so
sincronizados entre si, seguindo o paradigma de eixo do tempo (timeline) pela
adio de selos de tempo (timestamps). Os fluxos de dados, no entanto, no
esto relacionados temporizao dos fluxos de udio principal e vdeo
principal. A Figura 1.7 ilustra o procedimento. Note que os selos de tempo
associados aos fluxos de dados so diferentes daqueles associados aos fluxos
de udio principal e vdeo principal.
MUX
MPEG 2
System
DEMUX
MPEG 2
System
x
x
z z
w
w
udio principal
vdeo principal
}
dados
udio principal
vdeo principal
udio principal
vdeo principal
}
dados

Figura 1.7 Transporte de dados sncronos.
Exibio de comerciais, estatsticas de esportes, sistemas de ajuda, entre
muitos outros, so exemplos de aplicaes que somente possuem sentido no
contexto da exibio do vdeo principal. Portanto, com a possibilidade de
envio desses dados por difuso, os padres de TV digital devem estabelecer
mecanismos que permitam a sincronizao desses dados com os fluxos de
udio principal e vdeo principal.
O servio de transporte sincronizado assume que os fluxos de dados so
sincronizados entre si e tambm com os fluxos de udio principal e vdeo
principal, sempre seguindo o paradigma de eixo do tempo (timeline), pela
adio de selos de tempo (timestamps). A Figura 1.8 ilustra o procedimento.
Note que os selos de tempo associados aos fluxos de dados so iguais queles
associados aos fluxos de udio principal e vdeo principal.
16
MUX
MPEG 2
System
DEMUX
MPEG 2
System
x
x
z z
x
x
udio principal
vdeo principal
}
dados
udio principal
vdeo principal
udio principal
vdeo principal
}
dados

Figura 1.8 Transporte de dados sincronizados.
Fluxos de dados no transporte sncrono e sincronizado s permitem o
sincronismo quando o instante de tempo de sincronizao determinstico.
Aplicaes interativas, nas quais a sincronizao dada em um tempo
aleatrio determinado pelo usurio telespectador, aplicaes nas quais o
contedo gerado em tempo de exibio e no se pode determinar o tempo
exato em que eventos ocorrero e aplicaes cujo contedo determinado em
tempo real (em tempo de exibio) no podem ser sincronizadas usando o
servio sncrono ou o servio sincronizado. O suporte, nesse caso, dado pelo
servio de transporte assncrono.
Servios assncronos implicam que nenhuma marca de tempo
(timestamp) associada aos dados. No entanto, pode haver sincronismo entre
os vrios objetos transportados e entre esses objetos e os fluxos de udio e/ou
vdeo principal. Para tanto, o paradigma de sincronizao timeline
abandonado, sendo substitudo pelo paradigma de causalidade/restrio
(tambm chamado de orientado a evento).
Nos servios assncronos, junto com os dados mandado o documento
da aplicao (hachurado na Figura 1.9), que especifica, em uma linguagem de
programao especfica, o comportamento relativo dos dados, do udio
principal e do vdeo principal, no tempo e no espao.
MUX
MPEG 2
System
DEMUX
MPEG 2
System
x
x
z z
udio principal
vdeo principal
}
dados
udio principal
vdeo principal
udio principal
vdeo principal
}
dados

Figura 1.9 Transporte de dados assncronos.
O servio assncrono a nica forma de sincronizao de objetos com
tempo de sincronizao indeterminado. Ele, no entanto, exige uma linguagem
para especificao do sincronismo e, no receptor, uma mquina capaz de
interpretar e executar os comandos de sincronizao especificados nessa
17
linguagem. O padro MPEG-2 System especifica os vrios tipos de servio,
mas no especifica a linguagem usada para sincronizao no servio
assncrono. Esse assunto ser tema da Seo 1.3. Note tambm que possvel
em uma transmisso que parte dos dados sigam um servio e parte outros.
1.2.3.2 Fluxo Elementar de Dados
At agora partimos do pressuposto de que os fluxos de dados j estavam
gerados e empacotados. O padro MPEG-2 especifica tambm vrias formas
pelas quais esses dados podem ser transportados e opes para o processo de
gerao desses fluxos, como discutido a seguir.
Fluxos de udio e vdeo a serem transportados usando os servios
sncrono e sincronizado so gerados de forma similar gerao dos fluxos de
udio e vdeo principal.
Todo fluxo elementar deve ser quebrado em pacotes de forma a poderem
ser multiplexados no fluxo de transporte, como discutimos na seo anterior.
Para ajudar a solucionar esse problema, o MPEG define o conceito chamado
de sees privadas, ou simplesmente sees, usadas para empacotar os dados
a serem transportados no servio assncrono para posterior multiplexao. As
sees seguem um formato padronizado [ISO/IEC 10918-1, 1994]. Cada
seo pode conter at 4.096 bytes de dados e um cabealho que informa ao
receptor quantas sees esto sendo usadas para transportar um fluxo de
dados especfico e como os dados devem ser remontados.
Como a sintonizao de um canal especfico de TV (e, assim, de um
fluxo multiplexado MPEG-2 System) pode ser realizada em qualquer
instante, dados sem solicitao (pushed data) que no tenham relao
temporal especificada por meio de selos de tempo devem ser enviados
ciclicamente. Se assim for feito, o recebimento desses dados ser
independente do instante de sintonizao.
Para dar suporte ao envio cclico de dados, prevalece nos sistemas de
TV digital terrestre a utilizao dos protocolos carrossel de dados e carrossel
de objetos, especificados no padro DSM-CC (Digital Storage Media
Command and Control) [ISO/IEC 13818-6, 1998]. Carrossis de dados e de
objetos so transportados em sees privadas especficas MPEG-2. Cabe
observar que outros protocolos para difuso de dados sem solicitao
(pushed data) so utilizados principalmente em sistemas de IPTV e P2PTV.
Um carrossel de dados DSM-CC permite o envio de dados no-
estruturados. A estruturao fica por conta do sistema de TV digital que o
utiliza. O sistema japons de TV digital faz uso dessa facilidade do padro.
Um carrossel de objetos permite o envio cclico de um sistema de arquivos.
Assim, ao sintonizar um determinado canal, o receptor deve ser capaz de
18
decodificar os dados recebidos e coloc-los em uma rea de memria para que
possam ser utilizados, preservando a estrutura de arquivos e diretrios
enviada. Dados enviados tanto nos sistemas americano e europeu quanto no
sistema brasileiro de TV digital terrestre utilizam o carrossel de objetos.
Cabe observar que mais de um carrossel pode ser transmitido
simultaneamente e que um carrossel de objetos pode fazer uso de recursos
(arquivos, diretrios e outros objetos [ISO/IEC 13818-6, 1998]) que estejam
sendo transferidos em outros carrossis. Mais ainda, aplicaes transferidas
em arquivos de um carrossel podem fazer referncia a recursos presentes no
mesmo carrossel ou a recursos de outros carrossis. Por exemplo, uma pgina
HTML transmitida em um carrossel pode referenciar uma imagem cujo
contedo transmitido em um outro carrossel de objetos.
O carrossel de objetos de fato um protocolo de transmisso cclica de
dados. O resultado um fluxo elementar de dados que contm o sistema de
arquivos transmitido de forma cclica. Assim, se um determinado receptor no
recebeu um bloco de dados em particular (devido a uma falha na transmisso
ou por ter sintonizado o canal aps a transmisso desse bloco), basta esperar
pela sua retransmisso correta.
Como mencionado anteriormente, em um transporte de dados
assncrono, toda especificao de sincronismo entre os dados, o udio
principal, o vdeo principal e os outros dados enviados pelos servios sncrono
ou sincronizado enviada em um documento de especificao da aplicao
(bloco hachurado na Figura 1.9). Esse documento tambm pode ser
transportado em uma seo privada MPEG (por exemplo, em um carrossel
DSM-CC). Para que a aplicao entre em execuo, um comando deve ser
enviado ao receptor. O padro MPEG-2 System tambm especifica como isso
pode ser realizado atravs do envio de eventos de sincronismo DSM-CC (ou
simplesmente eventos DSM-CC).
O Apndice B traz uma discusso tcnica mais detalhada sobre o padro
DSM-CC. O Apndice F traz uma discusso detalhada das vrias opes de
transporte de dados e eventos de comando oferecidas pelo middleware Ginga
(apresentado na Seo 1.3). Eventos de comando so discutidos e
exemplificados no Captulo 16.
1.2.3.3 Fluxo de Transporte
Cada fluxo elementar MPEG-2 System (udio principal, vdeo principal,
fluxo do carrossel etc.) tem um identificador nico. As especificaes MPEG-
2 System definem ainda o termo programa, chamado de servio no contexto
da TV digital, como um grupo composto de um ou mais fluxos elementares
com uma mesma base temporal. O fluxo de transporte multiplexado pode
19

conter vrios servios (programas) simultaneamente, cada qual podendo ter
uma base de tempo diferente.
Simplificadamente, multiplexar servios em um fluxo de transporte
significa organizar os pacotes dos vrios fluxos elementares pertencentes aos
servios contemplados em um nico fluxo. Para isso, necessrio inserir no
fluxo de transporte informaes que permitam ao decodificador MPEG-2
identificar a qual servio um dado fluxo elementar pertence. Essas
informaes so dispostas como um conjunto de tabelas de informao
especfica de programa (PSI Program Specific Information). Uma PSI
particular, denominada PMT (Program Map Table), contm a lista de
identificadores dos fluxos elementares que compem um servio. Cada PMT
encontrada representa um servio disponvel. As PMTs so localizadas
atravs de outra PSI, denominada PAT (Program Association Table), que
contm identificadores dos fluxos elementares contendo as PMTs. O fluxo
elementar que possui a PAT possui identificador fixo com o valor
hexadecimal 0x00. A Figura 1.10 ilustra a multiplexao MPEG-2 System,
incluindo os fluxos elementares das tabelas PSI.
Fluxos elementares
(vdeo/udio/dados)
Mapa dos fluxos elementares
(Program map table)
Fluxo de programa
Fluxos de programa 1n
Mapa dos fluxos de programa
(Program association table)
Fluxo de transporte
PCR- Program
Clock Reference

Figura 1.10 Fluxo de transporte MPEG-2 System.
20
1.2.4 Modulao
Um dos padres mais importantes em um sistema de TV digital terrestre
o que define o processo de modulao, responsvel por receber um fluxo de
transporte e posicion-lo em um canal de frequncia.
As tcnicas de modulao digital podem ser divididas em dois grupos:
aquele com portadora nica, como no sistema americano 8-VSB (Vestigial
Side Band)/ATSC [ATSC A-53, 2007] e no sistema chins 4-16 ou 64-
OQAM (Quadrature Amplitude Modulation))/ADTB [ADTB, 2001], e
aquele com mltiplas portadoras, como no sistema europeu COFDM/DVB-T
[ETSI EN 300 744 V1.1.2, 1997] e no sistema japons BST-OFDM/ISDB-T
[ISDB-T, 1998], que podem tambm ser moduladas em fase (QPSK, 16QAM
e 64QAM). No caso do sistema japons, as portadoras tambm podem ser
moduladas com DQPSK. O sistema brasileiro BST-OFDM/SBTVD-T
[ABNT NBR 15601, 2007] utiliza a mesma modulao do sistema japons.
A acomodao de um canal de HDTV numa banda de apenas 6 MHz
exige no apenas tcnicas eficientes de compresso, como discutido na Seo
1.2.1, mas tambm tcnicas de modulao com mltiplos nveis. Alguns
sistemas simples de modulao digital transportam apenas um bit de
informao por smbolo. Em outras palavras, cada smbolo deve ser
representado por um de dois possveis estados (nveis), representando o bit 1
ou 0. Nesse caso, a taxa de bits do sistema a mesma que a taxa de smbolos.
Entretanto, outros sistemas podem ter muitos estados possveis para cada
smbolo. Geralmente, o nmero de estados tal que consiste numa potncia de
dois e, assim, a taxa de bits do sistema algum mltiplo inteiro da taxa de
smbolos. Os sistemas de modulao digital so frequentemente indicados
pelo tipo de modulao precedido por um nmero que representa o nmero de
estados de cada smbolo. Por exemplo, 4QAM descreve uma modulao com
quatro possveis estados para cada smbolo. Quatro estados podem carregar
dois bits de informao (00, 01, 10 e 11); assim, a taxa de bits de um sistema
4QAM duas vezes a taxa de smbolos.
Embora seja tentador, no podemos aumentar impunemente o nmero de
nveis, aumentando a taxa de transmisso possvel, porque, ao aumentarmos o
nmero de nveis, diminumos a sensibilidade a rudos, aumentando a
probabilidade de interferncia entre smbolos, o que reduz o desempenho do
sistema quanto taxa de erro de bits (BER).
Nas tcnicas de portadora nica, os smbolos digitais so transmitidos
serialmente, o que significa que o intervalo de sinalizao (janela de tempo)
associado a cada smbolo muito pequeno quando as taxas de transmisso
so altas. As propostas atuais de HDTV, que usam taxas de
aproximadamente 19,3 Mbps, trazem problemas tcnicos de difcil resoluo
para a radiodifuso, sendo inevitveis os fenmenos de mltiplos percursos,
21
j discutidos na Seo 1.1. Como apresentado naquela seo, um intervalo de
sinalizao pequeno aumenta a probabilidade de a interferncia intersmbolos
causar erros de recepo do sinal. Quando o intervalo de sinalizao muito
pequeno, tambm aumenta a sensibilidade a rudo impulsivo, uma vez que
erros podem ser causados em sequncias de bits consecutivos. O combate a
esses problemas exige o uso de equalizadores adaptativos muito complexos.
O desempenho desses equalizadores fundamental para que o sistema
funcione de maneira adequada. Caso o nmero de percursos existentes seja
maior do que a capacidade de atuao do equalizador, a taxa de erro se torna
elevada a ponto de colocar o sistema fora de operao.
Por outro lado, as tcnicas com mltiplas portadoras prometem um
desempenho muito melhor frente ao rudo impulsivo e mltiplos percursos, j
que cada smbolo pode ter o seu perodo de transmisso aumentado de tal
maneira que seja muito maior que a durao dos impulsos de rudo e o
intervalo de disperso da propagao. Para tanto, um fluxo digital de alta
taxa de bits dividido em um grande nmero de canais com baixa taxa de
bits. Esses canais so usados para modular as subportadoras individuais e so
transmitidos em paralelo (isto , simultaneamente), ao contrrio da tcnica de
portadora nica, onde os dados so enviados em srie. Essa diferena
fundamental permite ampliar o tempo de transmisso de cada dado para
combater os efeitos da disperso temporal e do rudo impulsivo.
A tcnica utilizada na modulao das subportadoras uma variao da
multiplexao por diviso de frequncia (FDM). Em um sistema FDM, as
portadoras so suficientemente espaadas de modo a poderem ser recebidas
utilizando filtros convencionais. Para tornar a filtragem possvel, intervalos de
guarda tm de ser introduzidos entre essas portadoras, o que resulta em uma
diminuio da eficincia espectral. J na tcnica utilizada na modulao das
subportadoras (OFDM Orthogonal Frequency Division Multiplexing), em
vez de se utilizar um intervalo de guarda entre subportadoras, elas so
sobrepostas, mas sem que haja interferncia entre elas. Para que isso seja
possvel, as subportadoras devem ser matematicamente ortogonais
(linearmente independentes), da a denominao OFDM, resultando em um
ganho espectral de at de 50% em relao tcnica FDM.
Para se tornar pouco sensvel ao problema de multipercurso, a
modulao OFDM adota um intervalo de guarda com durao superior
disperso produzida nos mltiplos percursos. Satisfeita essa condio, no
haver interferncia entre smbolos. Assim, a modulao OFDM no requer
equalizadores complexos para que se tenha sucesso na recepo em canais
com mltiplos percursos.
Vejamos um exemplo bem simples. Se enviarmos um milho de
smbolos por segundo usando uma modulao com portadora nica, a
durao de cada smbolo ser de 1 microssegundo, impondo graves restries
22
interferncia de mltiplos percursos. Se os mesmos smbolos forem
enviados em mil subcanais, em paralelo, a durao de cada smbolo ser de 1
milissegundo. Suponhamos agora que um intervalo de guarda de 1/8 de
smbolo seja introduzido entre cada smbolo. Interferncias entre smbolos
sero evitadas se o tempo de recepo entre o primeiro e o ltimo eco for
menor que o intervalo de guarda, ou seja, 125 microssegundos, o que equivale
a uma diferena de caminho de propagao de aproximadamente 37,5
quilmetros.
Como mencionamos na Seo 1.1, todos os padres de transmisso para
TV digital terrestre utilizam cdigos corretores de erro. A modulao OFDM
invariavelmente usada em conjunto com a codificao do canal, da a
denominao COFDM. Tanto no sistema DVB-T quanto no ISDB-T, a
codificao de canal envolve a codificao de Reed-Solomon e de Trelia.
A tcnica de modulao BST-OFDM (Band Segmented Transmission
Orthogonal Frequency Division Multiplexing) proposta no sistema japons
(ISDB-T, ISDB-TSB e ISDB-C) melhora a tcnica COFDM em dois
sentidos, introduzindo a segmentao de banda e a intercalao no tempo
(time interleaving).
A intercalao no tempo espalha ao longo de um sinal transmitido
smbolos consecutivos gerados no sinal original. Dessa forma, quando
acontecem erros, eles no afetam smbolos consecutivos, mas so de fato
espalhados com relao ao sinal original. Evitando-se a concentrao de
erros, evita-se que corretores de erros no sejam capazes de recuper-los.
A segmentao de banda explora o fato de que algumas portadoras
podem ser moduladas de forma diferente de outras. Assim, o canal de TV de
6 MHz pode ser segmentado e modulado com a tcnica mais apropriada para
cada servio. possvel, por exemplo, enviar sinais de vdeo em um canal
com modulao otimizada para recepo mvel, enviar outros sinais de vdeo
em outro canal otimizado para recepo fixa etc.
1.2.5 Canal de Retorno ou Canal de Interatividade
Um sistema de TV digital terrestre pode operar sem canal de retorno (ou
canal de interatividade). Nesse caso, as aplicaes podem usar (ou navegar
em, por semelhana com a Web) apenas os dados transmitidos por difuso.
Caso as aplicaes permitam a interao do usurio, o servio oferecido
chamado de interatividade local.
Padres de referncia de um sistema de TV digital podem incluir,
contudo, o uso de um canal de retorno.
23
O canal de retorno pode ser unidirecional, permitindo ao receptor
apenas o envio de dados. Um segundo nvel de interatividade ento definido,
permitindo ao usurio telespectador o envio de dados, por exemplo,
solicitando a compra de um determinado produto, votando em um
determinado assunto etc.
O canal de retorno tambm pode ser bidirecional assimtrico,
possibilitando ao receptor fazer o carregamento (download) de dados
utilizados pelas aplicaes. Nesse caso, uma aplicao pode receber dados
por difuso ou pela rede de retorno. Um terceiro nvel de interatividade
ento fornecido, permitindo ao usurio telespectador o acesso a dados no
provenientes por difuso, por exemplo, permitindo a navegao na Web.
Um canal de retorno bidirecional pode tambm permitir o envio de dados
em banda larga (upload). Nesse caso, o receptor pode passar a atuar como
uma pequena emissora. Esse nvel de interatividade, chamada de
interatividade plena, possibilita, entre outras coisas, o que vem sendo
chamado de TV social (social TV) ou TV em comunidade (community
TV), que se caracteriza por um grupo de usurios telespectadores de um
mesmo programa que podem trocar dados entre si.
O sistema brasileiro de TV digital terrestre permite, em suas normas, os
quatro nveis de interatividade, assim como os sistemas americano, europeu e
japons de TV digital terrestre.
1.3 Middleware
Na Seo 1.2.3 vimos como uma aplicao, em particular um programa
no-linear, pode ser enviada por difuso e sem solicitao atravs de sees
privadas MPEG-2. Essa especificao tambm poderia ser obtida sob
demanda, como usual em servios IPTV ou Web TV. A especificao da
aplicao, entre outras funes, deve ser a responsvel pela sincronizao
espacial e temporal dos vrios objetos de mdia que compem a aplicao.
Uma aplicao poderia ser executada diretamente sobre o sistema
operacional de um receptor (ver Figura 1.3). No entanto, os sistemas
operacionais de propsito geral no esto preparados para dar um bom
suporte s aplicaes de TV digital. Alm disso, uma aplicao de TV deve
ser capaz de ser executada em qualquer plataforma de hardware e sistema
operacional.
Para tornar as aplicaes independentes da plataforma de hardware e
software de um fabricante de receptor especfico e para dar melhor suporte s
aplicaes voltadas para a TV, uma nova camada acrescentada nos padres
de referncia de um sistema de TV digital. A essa camada denominamos
24
middleware. A Figura 1.11 apresenta os padres de referncia do sistema
nipo-brasileiro de TV digital terrestre, incluindo seu middleware de nome
Ginga.
BST-OFDM
MPEG-2 System
H.264 HP@L4.0 H.264 BP@L1.3
MPEG - 4 HE-AAC@L4 MPEG - 4 HE-AAC@L3
Ginga
APL1 APL2 APLn
...
Demodulador
Decod. do Canal
D
e
m
u
x
.
Dec. udio
Dec. Vdeo
CPU
Memria
VC
RF
IR CR
Video out
Audio
Surround
Audio out
RF out
Rede
Externa
RF in
API SO
...
BST-OFDM
MPEG-2 System
H.264 HP@L4.0 H.264 BP@L1.3
MPEG - 4 HE-AAC@L4 MPEG - 4 HE-AAC@L3
Ginga
APL1 APL2 APLn
...
Demodulador
Decod. do Canal
D
e
m
u
x
.
Dec. udio
Dec. Vdeo
CPU
Memria
VC
RF
IR CR
Video out
Audio
Surround
Audio out
RF out
Rede
Externa
RF in
API SO
...

Figura 1.11 Padres de referncia do sistema brasileiro de TV digital terrestre.
O middleware um dos componentes mais importantes de um sistema de
TV digital porque, na prtica, ele que regula as relaes entre duas
indstrias de fundamental importncia: a de produo de contedos e a de
fabricao de aparelhos receptores. Do ponto de vista do software, podemos
dizer, sem exagero, que ao definir o middleware estamos, de fato, definindo
um sistema de televiso. Dominar o conhecimento dessa tecnologia
estratgico para um pas, pois o no-domnio certamente acarretaria tambm
o no-domnio de seu uso.
1.3.1 Requisitos
Uma das funes de um middleware fornecer suporte s aplicaes. O
suporte fornecido atravs de uma interface de programao de aplicaes
(API Application Programming Interface), cuja funcionalidade oferecida
deve ser regida pelas necessidades das aplicaes a serem executadas no
ambiente de TV digital. Dentre essas aplicaes, obviamente, esto os
programas no-lineares, foco principal de qualquer sistema de TV digital.
Levantar os requisitos das aplicaes , assim, levantar os requisitos de
um middleware, e o que trataremos nesta seo.
Na Seo 1.2.3 discutimos as vrias formas de sincronizao de dados e
vimos como o suporte sincronizao essencial quando o servio utilizado
o servio assncrono, nico servio em que a sincronizao com tempos no-
determinsticos possvel. O suporte sincronizao, com ou sem a interao
25
do usurio telespectador, se faz necessrio em todos os programas no-
lineares e na grande maioria das outras aplicaes de TV.
Como exemplo de sincronizao, tomemos a exibio de um jogo de
futebol. Durante a exibio do vdeo principal, um torcedor poderia entrar em
foco com um copo na mo. Sincronizado com esse exato instante poderia
aparecer um objeto de mdia texto com o aviso Se beber, no dirija ou
mesmo uma imagem com a propaganda de uma marca de bebida. No decorrer
do jogo poderia acontecer um lance duvidoso. Quando isso acontecesse,
poderia aparecer, sincronamente, um cone do tira-teima que, quando
acionado (sincronismo com a interao do telespectador), redimensionaria o
vdeo principal, exibiria o lance em outro objeto de mdia vdeo e mostraria a
animao grfica tira-teima em outra janela da tela, como ilustra a Figura
1.12. De tempos em tempos, poderia aparecer na tela um cone que, se
acionado pela interao sncrona do telespectador, exibiria os resultados dos
outros jogos da rodada do campeonato. Em um jogo, comum a cena de um
jogador amarrando sua chuteira. Se isso acontecesse no nosso exemplo,
sincronizado com esse exato momento, poderia aparecer um outro objeto de
mdia, por exemplo um outro vdeo, fazendo a propaganda da marca da
chuteira e, sincronizado com o final desse vdeo, um formulrio para compra
que, se preenchido, seria enviado pelo canal de retorno ao fornecedor, que se
encarregaria de entregar o pedido na casa do telespectador.
Tira Teima
Brasil 1 x 0 Argentina
Voltar
Tira
Teima

Figura 1.12 Exemplo de programa no-linear.
Esse exemplo ilustra vrios aspectos possveis em um programa no-
linear:
- Propagandas no-interativas (de aparecimento obrigatrio):
propaganda da bebida.
- Propagandas interativas (de aparecimento sob comando do usurio
telespectador): propaganda da chuteira.
- Informaes adicionais obrigatrias ao contedo do programa: o
aviso se beber, no dirija.
26
- Informaes adicionais opcionais ao contedo do programa: a
exibio dos resultados da rodada do campeonato e a exibio do
tira-teima.
- Uso do canal de retorno: no caso, para compra da chuteira.
Mais do que apresentar exemplos de uso, esse exemplo ilustra a
importncia do sincronismo de mdia, com e sem a interao do usurio. Isso
nos leva ao primeiro requisito de um middleware: suporte ao sincronismo de
uma forma geral e, como caso particular, interao do usurio.
No mesmo exemplo, poder-se-ia questionar que a televiso analgica j
permite algumas das facilidades, como por exemplo, o aparecimento das
propagandas (bebida) sem a interao do usurio. Isso verdade, mas para
tanto, na TV analgica, a propaganda teria de ser multiplexada com o vdeo
principal na origem, na emissora, gerando um novo vdeo principal. Para o
receptor isso seria indiferente, uma vez que ele continua tratando um nico
objeto de mdia, o vdeo principal. Imaginemos, no entanto, a possibilidade de
exibio dessa propaganda de forma adaptativa. Por exemplo, se uma criana
estivesse assistindo ao jogo, apareceria a propaganda de um guaran; se fosse
um adulto, apareceria a propaganda de uma cerveja. Isso possvel com a TV
digital, mas seria impossvel na analgica. A adaptao poderia ser em funo
do usurio, do dispositivo que est exibindo a informao ou mesmo do local
onde est o telespectador. Por exemplo, a propaganda da bebida para um
usurio adulto em Ipanema poderia trazer beba cerveja no Garota de
Ipanema, j para um telespectador no centro da cidade do Rio de Janeiro, a
propaganda poderia trazer beba cerveja no Amarelinho.
O pargrafo anterior nos traz um segundo requisito importante a ser
oferecido por um middleware: suporte adaptao de contedo e da forma
como um contedo exibido.
Em uma aplicao para TV, a interatividade deve ser usada com
parcimnia. Diferentemente de uma aplicao voltada para computador, uma
aplicao de TV deve levar em considerao que:
- a transmisso de grande parte das informaes por difuso e no
personalizada (isso 100% verdadeiro com a interatividade apenas
local);
- a TV, em geral, se assiste a uma distncia razovel da tela (isso pode
no ser verdade no caso de dispositivos portteis);
- os dispositivos de interao (controle remoto) so ainda pobres em
termos de expressividade e usabilidade;
- o vdeo principal a principal fonte de sincronismo, incluindo a
interao;
27
- assistir a um programa muitas vezes uma atividade coletiva
(novamente no caso de dispositivos portteis, isso pode no ser
verdade);
- a TV usada para lazer e o telespectador no quer nada de muito
complexo em seu uso.
Em uma assistncia coletiva, alm da dificuldade imposta pelo ambiente
interao, o aparecimento de informaes adicionais pela demanda de um
telespectador pode aborrecer seu companheiro ao lado. O uso de dispositivos
de exibio pessoais (controle remoto com tela de baixa resoluo, celulares,
PDAs etc.) poderia amenizar o problema. Como exemplo, tome novamente a
Figura 1.12. Ao pedido de um usurio para ver o tira-teima, esse poderia
aparecer em seu dispositivo particular, no caso exemplificado pela Figura
1.12 em um celular, e no aparecer na tela principal da televiso, perturbando
os demais telespectadores.
Tira Teima

Figura 1.13 Mltiplos dispositivos de exibio.
Isso nos leva a um terceiro requisito a ser oferecido por um middleware:
suporte a mltiplos dispositivos de exibio.
Dispositivos receptores pessoais podem tambm comunicar entre si.
Poderiam, por exemplo, permitir a incluso de comentrios textuais ou outros
objetos de mdia na aplicao de TV recebida, e que o novo programa assim
criado fosse distribudo aos demais participantes de uma comunidade (grupo
de telespectadores), via, por exemplo, o canal de retorno, constituindo o que
chamamos anteriormente de TV social ou TV em comunidade.
A insero de objetos de mdia sincronizados em um programa no-
linear em tempo de exibio importante no s por possibilitar a aplicao
de TV em comunidade, descrita no pargrafo anterior, onde a edio ao vivo
realizada no cliente telespectador, mas tambm por possibilitar a gerao de
28
programas no-lineares ao vivo pela emissora de TV. Em muitos programas,
a deciso de quais objetos de mdia comporo o servio pode ser decidida ao
vivo. Retornando ao nosso exemplo do jogo de futebol, suponha que no
momento em que um jogador marcar um gol ser exibida a estatstica dos gols
em toda a sua carreira. Ora, a princpio no se sabe quem vai marcar o gol
nem se vai haver gol. A deciso de qual objeto de mdia com a estatstica ser
transmitido e quando s pode ser tomada aps a ocorrncia do gol.
Isso nos leva a um quarto requisito que deve ser oferecido por um
middleware: suporte edio ao vivo (em tempo de exibio).
Comentamos anteriormente que o vdeo principal a fonte mais
importante de sincronismo, incluindo a interao do usurio. Diferentemente
das aplicaes usuais de navegao na Web, que so usualmente baseadas em
texto, as aplicaes de TV so usualmente baseadas no contedo do vdeo
(programa de TV) principal. Embutir informao de navegao em vdeo
problemtico, quando no impossvel. Assim, permitir a definio de
relacionamentos entre objetos de mdia sem embutir tais relacionamentos
nos contedos um requisito importante.
Isso nos traz a um quinto requisito: suporte definio de
relacionamentos de sincronismo espacial e temporal separado da definio do
contedo dos objetos de mdia relacionados. Na literatura isso conhecido
como definio baseada na estrutura (structure-based), em contraste com a
definio embutida no contedo dos objetos de mdia, conhecida como
baseada no contedo de mdia (media-based).
Em resumo, um middleware deve oferecer um bom suporte para:
- o sincronismo de uma forma geral e, como caso particular, a
interao do usurio;
- a definio de relacionamentos de sincronismo espacial e temporal
separado da definio do contedo dos objetos de mdia relacionados;
- a adaptao do contedo e da forma como o contedo exibido;
- o uso de mltiplos dispositivos de exibio;
- a edio ao vivo (em tempo de exibio).
No caso do Brasil, a TV pode representar um grande veculo
complementar para incluso digital, permitindo s classes menos
privilegiadas no s o acesso informao, mas tambm a gerao
(produo) de informao (contedo). Assim, acresce aos requisitos de um
middleware o bom suporte a aplicaes ditas cidads, como as voltadas para
as reas de sade, educao, cultura etc.
29
1.3.2 Ambientes de Programao
As aplicaes de TV digital vo desde aquelas em que a aplicao
transmitida no tem nenhuma relao semntica com o programa principal em
exibio (como, por exemplo, a exibio de mensagens de notcias urgentes
durante a exibio de um programa de TV) at os programas no-lineares
(onde todos os objetos de mdia so sincronizados entre si, incluindo o udio
principal e o vdeo principal), passando pelas aplicaes com vrios objetos
de mdia relacionados entre si e que s fazem sentido dentro do contexto do
programa sendo assistido, mas no tendo nenhum relacionamento temporal
com o udio principal e o vdeo principal.
Aplicaes so usualmente desenvolvidas usando dois paradigmas de
programao distintos: o declarativo e o no-declarativo.
Linguagens de programao declarativas (linguagens que seguem o
paradigma declarativo) so linguagens de mais alto nvel de abstrao, muitas
vezes ligadas a um domnio ou objetivo especfico. Nas linguagens
declarativas, o programador fornece apenas o conjunto das tarefas a serem
realizadas, no estando preocupado com os detalhes de como o executor da
linguagem (interpretador, compilador ou a prpria mquina real ou virtual de
execuo) realmente implementar essas tarefas. Linguagens declarativas
resultam em uma declarao do resultado desejado, em vez da sua
decomposio em uma implementao algortmica e, portanto, normalmente
no necessitam de tantas linhas de cdigo para definir uma certa tarefa e so
menos sujeitas a erros de programao. Entre as linguagens declarativas mais
comuns esto a NCL (Nested Context Language) [ABNT NBR 15606-2,
2011] [ITU-T H.761, 2011], a SMIL [W3C REC-SMIL2-20051213, 2008],
a SVG [W3C REC-SVG11-20110816, 2011] e a XHTML [W3C REC-
xhtml1-20020801, 2002].
Numa programao no-declarativa, devemos informar cada passo a ser
executado. Pode-se afirmar que, em uma especificao seguindo o paradigma
no-declarativo, o programador possui maior poder sobre o cdigo, sendo
obrigado a estabelecer todo o fluxo de controle e execuo de seu programa.
Entretanto, para isso, ele deve ser qualificado e conhecer bem os recursos de
implementao. Linguagens no-declarativas podem seguir diferentes
modelos. Temos, assim, as linguagens baseadas em mdulos, orientadas a
objetos etc. Entre as linguagens no-declarativas mais comuns no domnio da
TV digital esto C, Java e ECMAScript.
O universo das aplicaes de um sistema de TV digital pode ser
particionado em um conjunto de aplicaes declarativas e um conjunto de
aplicaes no-declarativas. Uma aplicao declarativa aquela em que o
tipo do contedo de sua entidade inicial declarativo. Por outro lado, uma
aplicao no-declarativa aquela cujo tipo do contedo de sua entidade
30

inicial no-declarativo. Uma aplicao declarativa pura aquela na qual o
contedo de todas suas entidades do tipo declarativo. Uma aplicao no-
declarativa pura aquela na qual o contedo de todas suas entidades do
tipo no-declarativo. Uma aplicao hbrida aquela cujo conjunto de
entidades possui tanto contedo do tipo declarativo quanto no-declarativo.
A especificao de uma tarefa usando uma linguagem declarativa , a
princpio, muito mais fcil que o desenvolvimento usando uma linguagem
no-declarativa e tambm muito menos sujeita a erros de programao. Como
mencionado, linguagens declarativas possuem alto nvel de abstrao, no
exigindo grande expertise para o projeto de programas, ao contrrio das
linguagens no-declarativas que, em geral, exigem um programador
especialista. Tudo isso, no entanto, apenas um lado da verdade.
Linguagens declarativas muitas vezes so focadas em um domnio ou
um objetivo especfico. Quando o foco da linguagem casa com o foco do
problema a resolver, tudo o que mencionamos no pargrafo anterior verdade
e a linguagem declarativa tem uso preferencial sobre uma linguagem no-
declarativa. Quando, no entanto, o foco do problema no casa com o foco
da linguagem declarativa, sua resoluo pode ser muito difcil, se no
impossvel, usando a linguagem. Nesse caso, o uso de uma linguagem de
propsito geral, por exemplo uma linguagem imperativa, prefervel.
Praticamente todos os middlewares para TV digital terrestre e IPTV
oferecem suporte para o desenvolvimento de aplicaes usando os dois
paradigmas de programao. Alguns middlewares s oferecem o suporte para
aplicaes declarativas (puras ou hbridas). D-se, informalmente, o nome de
ambiente declarativo a esse suporte. Todos os middlewares padronizados
pelo ITU-T para servios IPTV contm apenas o ambiente declarativo.
Outros middlewares, no entanto, oferecem o suporte apenas a aplicaes no-
declarativas. D-se, informalmente, o nome de ambiente imperativo a esse
suporte. A maioria dos middlewares para TV terrestre, no entanto,
composta dos ambientes imperativos e declarativos. A Tabela 1.3 ilustra os
ambientes dos middlewares dos sistemas americano, europeu, japons e
brasileiro, para receptores fixos e mveis, em seus padres para TV digital
terrestre. Note que o middleware Ginga obrigatoriamente requer o ambiente
declarativo Ginga-NCL, mas admite extenses. Uma dessas extenses o
ambiente imperativo Ginga-J, adotado no Brasil como obrigatrio para
receptores fixos.
31
Tabela 1.3 Ambientes de aplicaes para receptores fixos e mveis
Middleware Sistema de TVD Ambiente Declarativo Ambiente Imperativo
ACAP Americano/ATSC ACAP-X [ATSC A-101,
2005]
(linguagem declarativa =
XHTML like; linguagem no-
declarativa = ECMAScript)
ACAP-J [ATSC A-101, 2005]
(linguagem no-declarativa =
Java
MHP Europeu/DVB-T DVB-HTML [ETSI TS 102
812 V1.2.2, 2006]
XHTML like; linguagem no-
MHP [ETSI TS 102 812
V1.2.2, 2006]
Java)
ARIB-BML Japons/ISDB-T ARIB BML [ARIB B-24,
2004]
BML (XHTML like);
linguagem no-declarativa =
ECMAScript)
Opcional (GEM [ETSI TS
102 819 V1.3.1, 2005] like);
no implementado)
Ginga Latino-Americano
/ISDB-T
B

Ginga-NCL [ABNT NBR
15606-2, 2011]
NCL; linguagem no-
declarativa = Lua)
Ginga-J [ABNT NBR 15606-
4, 2010]
Java
A Tabela 1.4 ilustra os ambientes dos middlewares dos sistemas japons
e brasileiro para receptores terrestres portteis.
Tabela 1.4 Ambientes de aplicaes para receptores portteis
Middleware Sistema de TVD Ambiente Declarativo Ambiente
Imperativo
ARIB-BML Japons/ISDB-T ARIB BML [ARIB B-24, 2004]
(linguagem declarativa = BML
(XHTML like; linguagem no-
X
Ginga Latino-
Americano/ ISDB-
T
B

Ginga-NCL [ABNT NBR 15606-5,
2011]
(linguagem declarativa = NCL;
linguagem no-declarativa = Lua)
Opcional
A Tabela 1.5 ilustra os ambientes dos middlewares Recomendaes
ITU-T para servios IPTV.
32
Tabela 1.5 Ambientes de aplicaes para servios IPTV
Middleware Ambiente Declarativo Ambiente
Imperativo
LIME LIME [ITU-T H.762, 2010]
(linguagem declarativa = LIME
(XHTML like; linguagem no-
X
Ginga Ginga-NCL [ITU-T H.761, 2011]
(linguagem declarativa = NCL;
linguagem no-declarativa = Lua)
X
Terminando esta seo, cabe enfatizarmos que tanto o ambiente
declarativo quanto o imperativo (tambm algumas vezes chamado de
procedural) de um middleware devem dar suporte a todos os requisitos
discutidos na Seo 1.3.1. Cabe tambm salientar que todos os middlewares
que apresentam os dois ambientes permitem que cada um deles use as
facilidades do outro atravs de uma ponte definida por meio de APIs
bilaterais padro.
1.3.3 Middlewares Declarativos
Como mostra a Tabela 1.3, parte dos ambientes declarativos para TV
digital terrestre e IPTV baseada em XHTML + ECMAScript. XHTML
[W3C REC-xhtml1-20020801, 2002] uma linguagem inicialmente projetada
para navegao em informaes textuais pela interao do usurio. XHTML
privilegia a interatividade em detrimento da sincronizao no seu sentido mais
amplo e em detrimento da adaptabilidade de contedo que, por no fazerem
parte do foco da linguagem, s podem ser definidas por procedimentos
imperativos usando a linguagem ECMAScript [ECMA 262, 1999]. Como
vimos, isso torna o desenvolvimento das aplicaes mais difcil para usurios
leigos e mais propensa a erros de programao.
XHTML s permite a definio de relacionamentos de interatividade
envolvendo parte de um contedo (ncora) de um objeto de mdia, se esse
objeto for textual ou se a ncora for puramente espacial. No caso de um
texto, o relacionamento deve ser embutido no contedo, ou seja, XHTML
uma linguagem do tipo media-based, como definimos na Seo 1.3.1. Como
no possvel embutir os relacionamentos, por exemplo, em um objeto de
vdeo, a interao deve ser possibilitada pela seleo de todo o objeto, ou seja,
habilitada em qualquer momento da exibio do vdeo ou, ento, novamente
devemos fazer uso de procedimentos no-declarativos utilizando
ECMAScript.
33
A linguagem XHTML no oferece suporte para edio ao vivo atravs
de comandos do provedor de contedos (ambiente das emissoras). No entanto,
todos os middlewares apresentados baseados em XHTML oferecem esse
suporte, atravs de extenses linguagem e uso de eventos DSM-CC
(conforme mencionamos na Seo 1.2.3 e discutimos no Apndice B) e
eventos DOM, mas novamente fazendo uso de objetos ECMAScript
embutidos.
Diferentemente dos ambientes declarativos baseados em XHTML,
Ginga-NCL [ABNT NBR 15606-2, 2011], o ambiente declarativo do
middleware do sistema nipo-brasileiro de TV digital terrestre e padro ITU-T
para servios IPTV, baseado em uma linguagem declarativa, uma aplicao
XML [W3C REC-xml- 20060816, 2006], que oferece um verdadeiro suporte
declarativo para todos os requisitos listados na Seo 1.3.1. Diferentemente
da linguagem XHTML, a linguagem NCL (Nested Context Language)
[ABNT NBR 15606-2, 2011] [ITU-T H.761, 2011], linguagem-base do
Ginga-NCL, uma linguagem do tipo structure-based (ver Seo 1.3.1), que
define uma separao bem demarcada entre o contedo e a estrutura de uma
aplicao, provendo um controle no-invasivo da ligao entre o contedo, o
leiaute e sua apresentao.
O foco da linguagem declarativa NCL mais amplo do que o oferecido
pela linguagem XHTML. Atravs de elementos da linguagem, suporte
declarativo oferecido a todos os requisitos anteriormente citados:
- a definio de relacionamentos de sincronismo espacial e temporal
separado da definio do contedo dos objetos de mdia relacionados,
atravs dos elementos <area>, <property>, <port> e <portSwitch> e
dos elementos <link> e <connector>. A interao do usurio tratada
apenas como caso particular de sincronizao temporal;
- a adaptao do contedo e da forma como o contedo exibido,
atravs dos elementos <switch> e <descriptorSwitch>;
- mltiplos dispositivos de exibio, atravs do elemento
<regionBase>;
- a edio ao vivo (em tempo de exibio), atravs de
nclEditingCommands associados a descritores de eventos.
Como a NCL tem uma separao mais acurada entre o contedo e a
estrutura de uma aplicao, ela no define nenhum objeto de mdia em si. Ao
contrrio, ela define a cola que prende os objetos de mdia em apresentaes
multimdia. Uma aplicao NCL apenas define como os objetos de mdia so
estruturados e relacionados, no tempo e no espao. Como uma linguagem de
cola, ela no restringe ou prescreve os tipos de contedo dos objetos de mdia.
Nesse sentido, podemos ter objetos de imagem (GIF, JPEG etc.), de vdeo
(MPEG, MOV etc.), de udio (MP3, WMA etc.), de texto (TXT, PDF etc.),
34
de cdigo declarativo (HTML, SMIL, NCL aninhados etc.), de cdigo
imperativo e funcional (Xlet, Lua etc.), entre outros, como objetos de mdia
NCL. Quais objetos de mdia so suportados depende dos exibidores de mdia
que esto acoplados ao formatador NCL (exibidor NCL).
3
Um desses
exibidores o decodificador/exibidor MPEG-4, normalmente implementado
em hardware no receptor de televiso digital. Dessa forma, o vdeo principal
e o udio principal MPEG-4 so tratados como todos os demais objetos de
mdia que podem estar relacionados utilizando NCL.
Outro objeto de mdia possvel aquele baseado em XHTML. A NCL
no substitui, mas embute documentos (objetos) baseados em XHTML.
Como acontece com outros objetos de mdia, qual linguagem baseada em
XHTML ter suporte em um formatador NCL uma escolha de
implementao e, portanto, depende de qual navegador XHTML ser
incorporado no formatador NCL e atuar como exibidor dessa mdia.
A NCL permite ainda objetos de mdia escritos em outras linguagens
declarativas, alm da linguagem XHTML, como objetos com cdigo SMIL,
SVG etc.
A NCL possui uma linguagem de script (a linguagem Lua), com um
desempenho muito superior ECMAScript em todos os quesitos importantes
para uma aplicao em TV digital, mencionados nos prximos pargrafos.
Alm de objetos NCLua (com cdigo Lua), a NCL permite objetos com
outros cdigos imperativos como, por exemplo, objetos NCLet com cdigo
Java (Xlets), parte da ponte entre o ambiente declarativo e o ambiente
imperativo do middleware Ginga.
Lua [ABNT NBR 15606-2, 2011] uma linguagem de programao
funcional e imperativa, procedural, pequena e leve, projetada para expandir
aplicaes em geral, para ser usada como linguagem extensvel e para ser
embarcada em softwares complexos.
Lua combina programao procedural com poderosas construes para
descrio de dados, baseadas em tabelas associativas e semntica extensvel.
A linguagem tipada dinamicamente, interpretada a partir de bytecodes, e
tem gerenciamento automtico de memria com coleta de lixo. Essas
caractersticas fazem de Lua uma linguagem ideal para configurao,
automao (scripting) e prototipagem rpida, caracterstica de grande
importncia para as aplicaes de TV, cujo desenvolvimento rpido
fundamental.

3
Renderizador de documentos, agente do usurio e exibidor (player) so outros nomes atribudos ao
formatador de documentos. O formatador NCL o mdulo central do ambiente Ginga-NCL.

35
Lua portvel. Seu ncleo muito pequeno e totalmente ANSI C. A
ttulo de comparao, enquanto mquinas JavaScript (ECMAScript) ocupam
de 936 Kbytes (SpiderMonkey JavaScript to Mozilla) a 1,7 Mbytes
(Rhino), Lua ocupa aproximadamente 120 Kbytes (retirando o parser e as
bibliotecas, Lua pode chegar a 60 Kbytes); LuaJIT (Lua Just in Time), uma
extenso da mquina Lua com 32 KB a mais de cdigo, ocupa um total de
150 Kbytes.
Lua facilmente embarcvel. Como mencionado, seu interpretador
uma biblioteca C, embarcvel em vrias linguagens, entre elas C/C++
(linguagem da implementao de referncia do Ginga-NCL) e Java
(linguagem do ambiente imperativo do Ginga).
Lua uma das linguagens dinmicas mais eficientes: eficiente para
descrio de dados, eficiente em ocupao de memria de seus programas e
rpida. Outras linguagens usam a frase as fast as Lua como aspirao.
Benchmarks independentes mostram a eficincia de Lua. A Figura 1.14
apresenta uma comparao de Lua com JavaScript (ECMAScript) do
SpiderMonkey, segundo o benchmark em http://shootout.alioth.debian.org/.
As comparaes so feitas sobre implementaes de problemas propostos no
site e submetidos por qualquer um. Nos grficos, cada par de linhas
representa um dos problemas propostos: linhas pretas para uso de memria;
linhas brancas para tempo de CPU. As linhas vo na direo do vencedor.
Quanto maior a linha, maior a diferena na comparao.
Lua vs JS LuaJIT vs JS

Figura 1.14 Desempenho de Lua e de LuaJIT (http://shootout.alioth.debian.org/) comparado
JavaScript.
36
Outras caractersticas de Lua, importantes na rea de entretenimento,
so: coleta de lixo incremental, evitando a longa pausa necessria em uma
coleta de lixo atmica; referncias fracas, permitindo melhor controle sobre as
referncias para objetos que podem ser coletados; e suporte a corrotinas como
alternativa ao uso de multithreading para programao concorrente, que
permite ao programador ter maior controle sobre a troca de contexto entre as
linhas de execuo concorrentes, alm de no necessitar de mecanismos de
sincronizao, como semforos e monitores. Tipicamente, isso permite o
desenvolvimento de programas mais eficientes e com comportamento mais
determinstico. Vale a pena destacar que Javascript no possui nenhum
recurso para programao concorrente.
Lua hoje a linguagem de script padro no seguimento de
entretenimento. Alguns dos jogos mais famosos da atualidade utilizam Lua.
Bibliografia
ABNT NBR 15601 (2007). Associao Brasileira de Normas Tcnicas,
Televiso digital terrestre sistema de transmisso. Sistema Brasileiro
de TV Digital Terrestre, NBR 15601.
ABNT NBR 15602-1 (2007). Associao Brasileira de Normas Tcnicas,
Televiso digital terrestre codificao de vdeo, udio e multiplexao,
Parte 1: Codificao de vdeo. Sistema Brasileiro de TV Digital
Terrestre, NBR 15602-1.
Parte 2: Codificao de udio. Sistema Brasileiro de TV Digital
Televiso digital terrestre codificao de dados e especificaes de
transmisso para radiodifuso digital, Parte 2: Ginga-NCL para receptores
fixos e mveis Linguagem de aplicao XML para codificao de
aplicaes. Sistema Brasileiro de TV Digital Terrestre, NBR 15606-2.
portteis Linguagem de aplicao XML para codificao de
aplicaes. Sistema Brasileiro de TV Digital Terrestre, NBR 15606-5.
Televiso digital terrestre Codificao e transmisso de dados para
37
radiodifuso digital, Parte 7: Ginga-NCL Diretrizes operacionais para as
Normas ABNT NBR 15606-2 e ABNT NBR 15606-5.
ADTB (2001). Zhang, Wenjum; Xia, Jingsong; Wang, Kuang e Ge, Jianhua.
Advanced Digital Television Broadcasting System.
ARIB B-24 (2004). Terrestrial Integrated Services Digital Broadcasting,
XML-based Multimedia Coding Scheme. ARIB Standard B-24 Data
Coding and Transmission Specifications for Digital Broadcasting,
version 4.0.
ATSC AC-3 (2005). Advanced Television Systems Committee, Digital
Audio Compression Standard (AC-3, E-AC-3).,Washington, D.C., junho.
ATSC A-101 (2005). Advanced Television Systems Committee Advanced
Application Platform (ACAP).,ATSC Standard: Document A/101,
Washington, D.C., agosto.
ATSC A-53 (2007). Advanced Television Systems Committee A/53: ATSC
Digital Television Standard, Parts 1-6.
ECMA 262 (1999). ECMA International, ECMAScript Language
Specification.
ETSI EN 300 744 V1.1.2 (1997). Digital Video Broadcasting, Framing
structure, channel coding and modulation for digital terrestrial television.
European Telecommunications Standards Institute, EN 300 744 V1.1.2.
ETSI TS 102 812 V1.2.2 (2006). Digital Video Broadcasting, Digital Video
Broadcasting (DVB); Multimedia Home Platform (MHP) Specification
1.1.1. European Telecommunications Standards Institute, TS 102 812
V1.2.2.
ETSI TS 102 819 V1.3.1 (2005). Digital Video Broadcasting (DVB),
Globally Executable MHP (GEM) Specification 1.0.2. European
Telecommunications Standards Institute, TS 102 819 V1.3.1.
ISDB-T (1998). Terrestrial Integrated Services Digital Broadcasting,
Specification of Channel Coding, Framing Structure and Modulation.
ISO/IEC 10918-1 (1994). International Organization for
Standardization/International Eletrotecnical Committee, Digital
Compression and Coding of Continuous-Tone Still Images, Part 1:
Requirements and Guidelines, ISO/IEC IS 10918-1.
Standardization/International Eletrotecnical Committee, Information
Technology Coding of Moving Pictures and Associated Digital Storage
Media at up to About 1.5 Mbits/s, Part 3: Audio, ISO/IEC 11172-3.
38
Technology Generic coding of moving pictures and associated audio
information, Part 1: Systems, ISO/IEC 13818-1.
Technology Generic coding of moving pictures and associated
information, Part 2: Video, ISO/IEC 13818-2.
information, Part 6: Extensions for DSM-CC, ISO/IEC 13818-6.
information, Part 7: Advanced Audio Coding (AAC), ISO/IEC 13818-7.
Technology Coding of Audio-Visual Objects, Part 3: Audio, ISO/IEC
14496-3.
Technology Coding of Audio-Visual Objects, Part 10: Advanced
Video, ISO/IEC 14496-10.
ITU-R BT.601-4 (1994). International Communication Union, Encoding
Parameters of Digital Television for Studios, Recommendation BT.601-
4, BT Series Volume, Geneva.
ITU-T H.761 (2011). Nested Context Language (NCL) and Ginga-NCL for
IPTV Services. Recommendation H.761, Genebra.
ITU-T H.762 (2009). Lightweight interactive multimedia environment.
Recommendation H.762, Genebra.
Soares, L.F.G e Barbosa, S.D.J. TV digital interativa no Brasil se faz
com Ginga: fundamentos, padres, autoria declarativa e
usabilidade. Jornada de Atualizao em Informtica, 2008.
Sociedade Brasileira de Computao. Julho de 2008; pp. 105-174.
ISBN: 978-85-7669-188-4.
39
W3C REC-SMIL2-20051213 (2008). World Wide Web Consortium,
Synchronized Multimedia Integration Language SMIL 2.1
Specification, W3C Recommendation SMIL2-20051213.
W3C REC-SVG11-20110816 (2011). World Wide Web Consortium,
Scalable Vector Graphics SVG 1.1 Specification (2
nd
. Edition),
W3C Recommendation.
W3C REC-xhtml1-20020801 (2002). World Wide Web Consortium,
XHTML 1.0 The Extensible HyperText Markup Language, W3C
Recommendation xhtml1-20020801.
W3C REC-xml- 20060816 (2006). World Wide Web Consortium,
Extensible Markup Language (XML) 1.0, W3C Recommendation xml-
20060816.

40
Captulo
2

Modelo Conceitual
NCM
Toda linguagem declarativa baseada em um modelo conceitual de
dados. Um modelo conceitual deve representar os conceitos estruturais dos
dados, assim como os eventos e relacionamentos entre os dados. O modelo
deve tambm definir as regras estruturais e as operaes sobre os dados para
manipulao e atualizao das estruturas.
Aps introduzir muito resumidamente o modelo bsico da linguagem
XHTML, linguagem declarativa-base dos sistemas americano, europeu e
japons de TV digital terrestre, este captulo apresenta uma viso geral do
modelo NCM (Nested Context Model) e, ao final, relaciona as entidades do
modelo NCM aos elementos da linguagem NCL correspondentes.
1

1
Este captulo se baseia em Soares et al. (2005). O uso do material foi gentilmente cedido pelo
Departamento de Informtica da PUC-Rio.
41
2.1 Entidades Bsicas XHTML
O modelo conceitual bsico XHTML muito simples e composto de
apenas quatro entidades bsicas, como mostra a Figura 2.1.
Entidade
Elo
N
ncora
ncora
Regio
elo
ncora
Regio
elo
Elo
ncora de origem
ncora de destino
Elo
ncora de origem
ncora de destino
N (pgina)
identificador
lista de ncoras
contedo
N (pgina)
identificador
lista de ncoras
contedo
Objeto
Objeto
contedo
Objeto
contedo

Figura 2.1 Modelo conceitual XHTML bsico.
Resumidamente, um n, usualmente chamado de pgina, possui um
identificador nico (um URI Uniform Resource Identifier [IETF RFC
2396, 1998]), uma lista de ncoras e um contedo. O contedo formado por
um texto com marcao de formatao [W3C REC-xhtml1-20020801, 2002
e W3C REC-CSS2-19980512, 1998] e outros objetos embutidos.
Os objetos embutidos podem ser imagens, scripts (ECMAScript o
usual em ambientes de TV digital), applets etc.
Uma ncora uma regio (conjunto de informaes) marcada de um n,
portanto definida embutida no n. ncoras podem ser definidas pela
marcao de trechos do texto de um n ou pela marcao de todo o contedo
de um objeto. Em XHTML no possvel a definio declarativa de ncoras
temporais internas a um objeto, mas apenas ncoras espaciais (especificadas
por coordenadas).
Relacionamentos so definidos embutidos no contedo de um n, mais
precisamente como atributos de uma ncora do n. Elos definem
relacionamentos de interao entre uma ncora de origem e ncoras de
destino. Elos so definidos embutidos em ncoras de origem.
Embora tendo por base o modelo simples apresentado, a linguagem
XHTML utiliza um modelo conceitual estendido, no qual vrias outras
entidades so responsveis pelo leiaute e formatao (listas, tabelas,
42
formulrio etc.). No entanto, nenhuma forma de relacionamento de
sincronismo ou de adaptao de contedo foi acrescida.
De fato, o modelo conceitual bsico XHTML tem na simplicidade sua
grande vantagem, e foi ela a responsvel pela grande disseminao da
linguagem. No entanto, foi concebido para navegao na Web, onde
predominantemente se navega em informaes textuais e com a interao do
usurio. Como j mencionamos, qualquer outra forma de relacionamento tem
de ser oferecida por objetos imperativos (ECMAScript, Java etc.) acionados
por eventos definidos sobre elementos e atributos da linguagem [W3C REC-
DOM-Level-2-Core-20001113, 2000]. Adicionalmente, no existe nenhuma
entidade do modelo que d suporte adaptao de contedo.
2.2 Entidades Bsicas do NCM
A linguagem declarativa NCL tem por base o modelo NCM (Nested
Context Model) [Soares et al., 2005], cuja descrio em detalhes fornecida
no Apndice C. Nesta seo faremos apenas uma introduo aos conceitos do
NCM, de um modo bastante informal. A Figura 2.2 apresenta as entidades
bsicas do modelo. Na figura, os termos so propositalmente deixados em
ingls para um melhor casamento com os elementos da linguagem NCL.
Entity
Connector Link
Causal
DescriptorSwitch Descriptor DescriptorSwitch Descriptor
Node
Composition
Switch Audio Video Text Image ...
Media
Context

Figura 2.2 Modelo conceitual NCM bsico.
Um n (node na Figura 2.2) NCM, tambm chamado objeto NCM,
possui um identificador, um contedo e um conjunto de ncoras. O contedo
de um n formado por um conjunto de unidades de informao. A noo
exata do que constitui uma unidade de informao parte da definio do n
43
e depende de sua especializao, conforme ser exemplificado mais adiante.
Uma ncora (anchor na Figura 2.3) um subconjunto das unidades de
informao de um n.
Um n de mdia, ou n de contedo (media na Figura 2.2), representa o
que chamamos no Captulo 1 de objeto de mdia. Ns de mdia devem ser
especializados em subclasses para melhor definir a interpretao do contedo
(texto, imagem, udio, vdeo, objetos com cdigo Lua, objetos com cdigo
imperativo Java, objetos com cdigo declarativo HTML etc.). Por exemplo,
em um n de vdeo, o conjunto de unidades de informao pode ser formado
pelos quadros que, em sequncia, compem seu contedo. Uma ncora, nesse
caso, poderia definir um trecho do vdeo. Uma ncora especial aquela que
delimita todo o contedo.
ncoras em NCM so definidas em separado do contedo de um n.
Como j mencionamos no Captulo 1, o NCM um modelo baseado na
estrutura (structure-based) e no no contedo da mdia (media-based), como
XHTML.
Usando como metfora o conjunto de animais racionais, podemos fazer
a seguinte analogia. Podemos dizer que o conjunto de animais racionais
composto por seres humanos (objetos de mdia). Todo ser humano tem um
identificador, por exemplo, seu CPF. Partes do ser humano so suas ncoras,
corao, crebro etc. O corpo, como um todo, a ncora que delimitaria todo
o contedo. Da mesma forma que ns de mdia tm tipos (udio, vdeo etc.),
os seres humanos tambm podem ser classificados quanto ao sexo, raa etc.
Os seres humanos possuem propriedades, como, por exemplo, o dinheiro
que carregam, seu cargo no trabalho etc. Da mesma forma, ns NCM
possuem propriedades (property na Figura 2.3). Por exemplo, para ns de
mdia, sua cor de fundo, sua posio na tela etc. so suas propriedades. Os
seres humanos se relacionam atravs de suas propriedades e ncoras. De
forma anloga, os objetos de mdia relacionam entre si. As propriedades e
ncoras de um objeto de mdia constituem suas interfaces.
Interface
Anchor Property Port Switch Port

Figura 2.3 Interfaces de um n NCM.
44
Os seres humanos se vestem de acordo com a situao. Por exemplo, se
vai a uma festa de gala, um homem pode usar terno e gravata; porm, se vai
praia, usa um calo. Da mesma forma, objetos (ns) de mdia podem ser
exibidos de forma diferente, conforme a situao. A forma como um objeto de
mdia deve ser exibido, onde e por quem especificada na entidade descritor
(descriptor na Figura 2.2). nessa entidade que so dadas as caractersticas
iniciais da apresentao. Iniciais porque elas podem mudar com o tempo. Por
exemplo, o posicionamento de um objeto pode mudar, e, de forma anloga,
um ser humano pode mudar sua vestimenta com o tempo (no decorrer da
animao da festa de gala, o homem pode, por exemplo, tirar a gravata).
Devemos notar que o descritor tambm define onde o objeto deve ser
apresentado, incluindo a o dispositivo de exibio. Assim, essa entidade a
base para o suporte a mltiplos dispositivos de exibio.
Note que a forma como um ser humano se veste pode ser adaptada
situao. Do mesmo modo, a forma como um n exibido depende da
situao. Assim, podemos associar vrios descritores a um mesmo n de
mdia, que sero escolhidos de acordo com a situao, de acordo com uma
regra (rule). O conjunto de descritores alternativos deve ser definido dentro
da entidade switch de descritores (descriptorSwitch na Figura 2.2). Essa
entidade que vai permitir NCL a definio declarativa da forma como um
contedo deve ser apresentado, adaptada a um certo contexto de exibio.
Objetos de mdia podem se relacionar, assim como os seres humanos.
Exemplos de relacionamentos foram definidos no Captulo 1; por exemplo, os
relacionamentos temporais e espaciais entre objetos de mdia, to
mencionados naquele captulo.
Um relacionamento definido por uma relao e pelos participantes da
relao. Voltando nossa metfora, uma relao entre seres humanos poderia
ser definida como homem casado com mulher. Em um relacionamento,
um ser humano do tipo homem vai exercer o papel homem na relao e outro
do tipo mulher vai exercer o papel correspondente mulher. Assim, temos o
relacionamento Joo casado com Maria. Devemos notar que, em uma
sociedade que no admite a poligamia, apenas um ator pode exercer cada
papel nessa relao. Tomemos agora mais trs relaes entre seres humanos:
ser humano amigo de ser humano, ser humano tipo cardiologista cuida
do enfarte de ser humano, ser humano paga dinheiro a ser humano. Na
primeira dessas relaes, vrios seres humanos podem exercer o mesmo
papel, por exemplo: Tadeu amigo de Jos e de Antnio. Concluso:
relacionamentos podem ser do tipo n:m. Na segunda relao descrita, o
relacionamento se d entre partes do ser humano, por exemplo: Marcos (um
cardiologista) cuida do enfarte do corao de Severino. Concluso:
relacionamentos relacionam ncoras; como caso particular, a ncora que
representa todo o contedo. No terceiro caso de relao descrito, o
45
relacionamento se d entre ser humano e uma propriedade do ser humano, por
exemplo: Gustavo paga dinheiro a Marcelo (aumentando o valor de
propriedade quantidade de dinheiro do Marcelo). Concluso: os papis de
uma relao podem ser exercidos por quaisquer das interfaces (ncoras ou
propriedades). Como concluso geral: um relacionamento n:m e relaciona
interfaces.
Faamos agora um paralelo da nossa metfora com os objetos de mdia
NCM. Em NCM, uma relao definida pela entidade conector (connector
na Figura 2.2). Um conector define uma relao atravs de seus papis (roles)
e da cola (glue) entre os papis. Por exemplo: um trecho de n de mdia, ao
ter sua apresentao iniciada, deve iniciar a apresentao de um trecho de
n de mdia (a cola foi destacada em itlico). Os papis um trecho do n de
mdia podem ser exercidos por qualquer ncora, como no exemplo de
relacionamento: no exato momento de uma novela (trecho de um n de vdeo)
em que uma atriz d uma mordida em um pedao de pizza, deve ser iniciada a
propaganda da pizzaria (um n de imagem por inteiro).
No NCM, os conectores podem ser causais e de restrio, mas no caso
da NCL 3.0, em seu perfil para TV digital, os conectores so sempre causais
(a cola sempre de causalidade), ou seja, quando as condies em um
conjunto de papis forem satisfeitas, um conjunto de aes deve ser aplicado
em um conjunto de papis. Conectores definem relaes n:m entre interfaces
de ns.
No NCM, a ligao entre o papel de um conector e uma interface de um
n se d atravs da entidade elo (link na Figura 2.2). Assim, um elo
composto por um conector e por ligaes (binds) entre os papis dos
conectores e interfaces de ns que exercem o papel. Atravs de elos,
relacionamentos de sincronismo temporal e espacial podem ser definidos, em
particular relacionamentos com interao do usurio.
Como dissemos, um descritor, ou um switch de descritores, pode ser
associado a um n definindo como, onde e por quem ser exibido. Essas
entidades podem ser associadas ao n atravs de um atributo do n, ou
atravs de um elo, mais precisamente atravs de uma ligao (bind) de um
elo. No caso de dupla associao, as definies contidas nas associaes
realizadas por elos se sobrepem quelas realizadas por atributos de ns.
Voltando nossa metfora, os seres humanos em geral pertencem a um
conjunto de organizaes ou estruturas. Por exemplo, Joo mora em uma
casa, pertence a um clube, toma regularmente um certo nibus etc. Vamos
chamar essas estruturas que agrupam os seres humanos de contineres. Note
que um continer pode conter outros contineres e mais seres humanos. Por
exemplo, uma rua pode conter vrias casas e seres humanos transeuntes; em
uma dessas casas pode morar Joo e Maria. Uma rua est dentro de um
46
bairro, que est dentro de uma cidade, que pertence a um estado etc. Devemos
notar que uma organizao no necessariamente hierrquica e que um
objeto pode pertencer a mais de uma estrutura (continer). Mais ainda,
devemos notar que, dentro de uma organizao, os seres humanos se
relacionam. Por exemplo, no trabalho (continer empresa), Joaquim patro
de Manoel.
De forma anloga, bastante interessante poder organizar objetos de
mdia em conjuntos. Tomemos um exemplo tpico de uma aplicao de TV.
Uma novela composta de captulos, que por sua vez so compostos de
cenas, que so compostos por tomadas, compostas de trechos de vdeo,
trechos de udio, textos de legenda, informaes adicionais sobre um ator,
propagandas enxertadas (que podem ser contineres incluindo outros objetos
de mdia) e outros objetos de mdia. Note que objetos de mdia podem se
relacionar em cada um desses nveis organizacionais. Organizar os objetos
independentes da forma temporal e espacial como sero apresentados muito
importante. Os contineres NCM so chamados de composio (composition
na Figura 2.2) e so a base da organizao lgica de um documento NCM.
Um n de contexto (context na Figura 2.2), ou objeto de contexto, um
tipo de n de composio cujo contedo inclui um conjunto de ns de mdia e
um conjunto de ns de composio, recursivamente. Da o nome de modelo de
contextos aninhados. Um n de contexto possui como atributos adicionais um
conjunto de elos relacionando seus objetos (ns).
Voltando nossa metfora, um ser humano dentro de um continer pode
querer se relacionar com outro ser humano em outro continer. Por exemplo,
Joo pode estar em um quarto de uma casa e querer conversar com Maria,
que est em outro quarto. Para tanto, Joo deve abrir portas de quartos at
chegar Maria. Portanto, contineres devem ter portas para permitir
relacionamentos com o exterior.
De forma anloga, um n de composio, em particular um n de
contexto, possui nas suas interfaces, alm de ncoras e propriedades, portas
(ver Figura2.3). Essas portas so mapeadas em outras interfaces interiores
composio e so elas que permitem composio expor, controladamente, as
interfaces de seus ns internos. Assim, cada elo contido no conjunto de elos
de um n de contexto C pode definir um relacionamento entre interfaces de
ns recursivamente contidos em C.
Vamos ver atravs de um exemplo como isso til. Tomemos
novamente o exemplo do jogo de futebol da Seo 1.3.1 do Captulo 1.
Relembrando, sincronizado com o exato momento em que um jogador amarra
sua chuteira, aparece um outro objeto de mdia, por exemplo um outro vdeo,
fazendo a propaganda da marca da chuteira e, sincronizado com o final desse
vdeo, um formulrio para compra. Ora, como essa propaganda pode
47
aparecer em vrios momentos do jogo, mais ainda, em vrios jogos diferentes,
conveniente defini-la em um contexto (contexto da propaganda na Figura
2.4) que poder ser reusado em outro documento (reso abordado nos
Captulos 3 e 13). Vamos assumir que a propaganda ocorreu em dois
momentos, definidos pelos trechos de vdeo (ncoras A e B na Figura 2.4) do
jogo. Nesses momentos, o vdeo dentro do contexto da propaganda deve ser
iniciado, o que pode ser feito pela porta P do contexto, como mostra a Figura
2.4.
Contexto do Jogo de Futebol
Contexto da
Propaganda
Preencha o formulrio para comprar
Carto:
Nmero:
Data de expirao:
Endereo:
Preencha o formulrio para comprar
Carto:
Nmero:
Data de expirao:
Endereo:
OnBegin Start
OnBegin Start
OnBegin Start
A B
P

Figura 2.4 Interfaces de um n NCM.
Finalmente, ainda dentro de nossa metfora, os seres humanos podem
estar presentes em um continer e ser selecionados para um relacionamento,
dependendo de uma regra a ser avaliada em um momento preciso. Tomemos
como exemplo um consultrio dentrio, onde a sala de espera pode conter
vrios seres humanos. Um dentista vai se relacionar (tratar) em um dado
instante de tempo com apenas um ser humano, escolhido, por exemplo, pela
ordem de chegada.
De forma anloga, em uma aplicao pode ser necessria a escolha entre
ns (objetos). Por exemplo, imagine no caso da Figura 2.4 que, dependendo
da lngua do usurio telespectador, fosse escolhido um formulrio para
compra da chuteira em ingls ou em portugus. Com o objetivo de permitir a
especificao de alternativas de ns a serem exibidos, o NCM define uma
entidade chamada n switch. O n switch (switch na Figura 2.2), ou objeto
switch, uma outra especializao de ns de composio. O contedo de um
n switch um conjunto que pode incluir ns de contexto e ns de mdia. O
n switch tem um atributo adicional que define, para cada n contido no seu
conjunto de ns, uma regra associada. As regras so definidas em uma lista
ordenada. Em um dado instante de exibio, o primeiro n que tenha a sua
regra avaliada como verdadeira deve ser eleito a alternativa selecionada.
48
Alm da j mencionada lista ordenada de portas, comum a todo n de
composio, ns switch possuem uma lista ordenada de portas-switch (switch
port na Figura 2.3). Portas-switch contituem mais um ponto de interface. Elas
definem um conjunto de mapeamentos para interfaces de ns contidos no n
switch. A definio de portas-switch permite que elos sejam definidos
ancorando em ns switch, independentemente do n filho que ser
selecionado. As portas tradicionais do switch permitem que elos sejam
associados a alternativas especficas. Se essa alternativa no for selecionada,
o elo ser simplesmente ignorado durante a apresentao do documento.
Assim como um switch de descritores o suporte necessrio para a
definio de alternativas da forma de exibio de um mesmo contedo de
mdia, um n switch o suporte necessrio para a definio de alternativas de
contedos.
Terminando este captulo, a Figura 2.5 mostra como entidades do
modelo NCM esto relacionadas a elementos da linguagem NCL. No perfil
NCL 3.0 para TV digital, nem todas as facilidades providas pelo modelo
NCM so refletidas na linguagem, mas todas as facilidades apresentadas
nesta seo so refletidas.
O leitor interessado pode obter uma descrio mais detalhada do modelo
conceitual NCM no Apndice C.
Entity
Connector Link
Causal
DescriptorSwitch Descriptor
Node
Composition
Switch Audio Video Text Image ...
Media
Context <context/>
<media/>
<descriptor/>
<descriptorSwitch/>
<switch/>
<connector/> <link/> Interface
<area/>
<property/>
<port/>
<switchPort/>

Figura 2.5 Entidades NCM e elementos da linguagem NCL.
49
Bibliografia
IETF RFC 2396 (1998). Uniform Resource Identifiers (URI): Generic
Syntax. RFC 2396.
Soares, L.F.S. e Rodrigues, R.F. (2005). Nested Context Model 3.0 Part 1
NCM Core. Monografias em Cincia da Computao do
Departamento de Informtica, PUC-Rio, N. 18/05. Rio de Janeiro. Maio.
ISSN 0103-9741.
W3C REC-CSS2-19980512 (1998). World Wide Web Consortium,
Cascading Style Sheets, level 2, W3C Recommendation CSS2-
19980512.
W3C REC-DOM-Level-2-Core-20001113 (2000). World Wide Web
Consortium, Document Object Model (DOM) Level 2 Core
Specification, W3C Recommendation DOM-Level-2-Core-20001113.
W3C REC-xhtml1-20020801 (2002). World Wide Web Consortium,
XHTML 1.0 The Extensible HyperText Markup Language, W3C
Recommendation xhtml1-20020801.

50
Captulo
3

Introduo
Linguagem NCL
A NCL (Nested Context Language) uma linguagem declarativa, uma
aplicao XML. Baseada no modelo conceitual NCM, a NCL traz uma
separao clara entre os contedos de mdia e a estrutura de uma aplicao.
Um documento NCL apenas define como os objetos de mdia so estruturados
e relacionados, no tempo e no espao. Como uma linguagem de cola, ela no
restringe nem prescreve os tipos de contedo dos objetos de mdia de uma
aplicao.
Este captulo traz uma introduo passo a passo de diversos elementos
que compem o perfil NCL 3.0 para TV digital. Nesta introduo, no existe
a preocupao de definir cada elemento da linguagem e cada um de seus
atributos, o que ser feito na Parte 2 do livro. O intuito aqui j fornecer ao
leitor a habilidade de desenvolver programas NCL simples e capacit-lo a
melhor entender e exercitar os demais conceitos apresentados na Parte 2. A
introduo ser feita atravs de um nico exemplo, construdo
paulatinamente.
1

1
Os contedos dos exemplos deste captulo esto disponveis sob a Licena Creative Commons
Atribuio Uso No-Comercial Compartilhamento pela mesma Licena 3.0 Unported, conforme
publicado em clube.ncl.org.br.
51
3.1 O Primeiro Joo
Para introduzir a programao em NCL, vamos utilizar um nico
exemplo, O Primeiro Joo, que construiremos passo a passo.
O Primeiro Joo baseado em um vdeo, uma animao de mesmo
nome produzida por Andr Castelo, que por sua vez foi baseado nas
crnicas de Man Garrincha, escritas por Gerson Soares. A animao conta
por que Garrincha passou a chamar de Joo todos os seus marcadores. A
histria se passa em um campo de pelada, onde Man, ainda pr-adolescente,
pobre, j fazia sua histria. Ao ser marcado impiedosamente, Garrincha
arrasa, com dribles desconcertantes, o time adversrio e, principalmente, seu
marcador, o pobre primeiro Joo; dribles esses que seriam repetidos na
gloriosa carreira do dolo brasileiro.
Vamos dividir nossa aplicao em 12 partes. Ao final deste captulo
teremos nosso programa no-linear interativo completo.
3.2 Sincronismo de Mdia sem Interatividade e
com Reso Apenas de Relao
Durante o vdeo da animao O Primeiro Joo, Garrincha d o seu
famoso drible em que leva os marcadores para a ponta, finge que vai avanar
e retorna, por diversas vezes, at que finalmente realiza o drible e passa. Esse
drible foi aplicado pelo Man por diversas vezes em jogos oficiais, inclusive
na Copa do Mundo pela seleo brasileira. Em outro trecho do vdeo, mais
frente, aparece o Garrincha e seu marcador, cado no cho, aps um drible
desconcertante. Cena idntica aconteceu em um jogo oficial do Botafogo e
Vasco, anos depois.
Nossa primeira aplicao, bem simples, ilustra como fcil, em NCL,
introduzir vrios objetos de mdia sincronizados no tempo. Vamos
acrescentar:
1. uma msica de fundo (um chorinho), que dever comear assim que
terminar a apresentao inicial do vdeo e comear a animao
propriamente dita;
2. um outro objeto de vdeo, que dever ser exibido em paralelo e
sincronizado com o famoso drible do vaivm do Man, retratado na
animao; e ainda
3. uma outra imagem, uma foto, que dever ser exibida junto com a
cena do marcador cado no cho.
52
O novo vdeo acrescentado uma rplica, uma clonagem do drible real
aplicado por Garrincha, realizado por garotos da Comunidade Beira Rio, no
Rio de Janeiro, produzido pelo Ponto de Cultura CIDS-VG, daquela
comunidade. Ele mostra garotos descalos em um campo de vrzea, como era
Garrincha na poca em que aplicou o drible no primeiro Joo. O mesmo
Ponto de Cultura tambm responsvel pela foto que retrata exatamente a
mesma situao ocorrida na animao, quando o marcador do Garrincha vai
ao cho, foto representada pelos mesmos garotos atores.
A Figura 3.1 ilustra a viso temporal da aplicao.
animation
drible photo
choro
tempo

Figura 3.1 Viso temporal.
Para definir todos esses objetos de mdia, a NCL faz uso de seu
elemento <media>, como ilustrado na Listagem 3.1.
<media id="animation" src="../media/animGar.mp4"/>
<media id="choro" src="../media/choro.mp3"/>
<media id="drible" src="../media/drible.mp4"/>
<media id="photo" src="../media/photo.png"/>
Listagem 3.1 Elementos <media>.
Todo elemento <media> tem um identificador, definido pelo atributo id,
para que possa ser posteriormente referenciado. Ele tem tambm um atributo
denominado src, que contm um URI para a localizao do contedo. Em
todos os casos de nosso exemplo, os contedos esto no diretrio /media,
filho do mesmo diretrio onde est definida a aplicao. usual, em
aplicaes para TV digital, o atributo src referenciar um fluxo elementar
MPEG System
2
. No faremos isso no nosso exemplo para facilitar sua

2
Como veremos no Captulo 8, se referenciarmos um fluxo elementar MPEG System, a URI usada
ser: sbtvd-ts://program_number.component_tag. Essa URI identifica o servio dentro de um canal
sintonizado da TV, por meio do program_number; e identifica um fluxo elementar, um vdeo por exemplo,
dentro do servio especificado, por meio do component_tag.
53
execuo nos dispositivos mais usuais disponveis para o leitor. Voltaremos a
esse ponto no Captulo 8.
Note que todo elemento NCL deve comear com o caractere <.
Quando o elemento no tem nenhum contedo nem elementos filhos, ele deve
terminar sempre com />, como na Listagem 3.1. Em caso contrrio, a
definio dos atributos do elemento termina com o caractere >. Aps a
definio de seu contedo ou elementos filhos, o elemento termina repetindo
seu nome envolvido com os caracteres </ na frente e o caractere > atrs,
como visto a seguir, na redefinio do elemento <media id=animation.../>
da Listagem 3.1 que, na Listagem 3.2 representa o vdeo da animao com
dois elementos filhos aninhados, denominados <area>.
<media id="animation" src="../media/animGar.mp4"
descriptor="screenDesc">
<area id="segDrible" begin="12s"/>
<area id="segPhoto" begin="41s"/>
</media>
Listagem 3.2 Elementos <area>.
Os elementos <area> delimitam trechos (no tempo ou espao) do
contedo do seu objeto de mdia pai. No caso, so delimitados o instante em
que, na animao, o Garrincha inicia o drible de vaivm e o instante, aps
outro drible, em que o marcador aparece cado no cho. O primeiro instante
delimitado por meio do atributo begin igual a 12 segundos, e o segundo pelo
atributo begin igual a 41 segundos. Como no foi especificado o valor do
atributo end, ele assumido, por default, como tendo o mesmo valor do final
do vdeo da animao, em ambos os casos. Note que todo elemento <area>
tambm possui um identificador (atributo id).
Nosso prximo passo no projeto da aplicao definir em que posio
da tela os vrios objetos de mdia sero exibidos. A Figura 3.2 apresenta a
viso de leiaute desejada. So definidas regies para exibio do vdeo da
animao (screenReg), em tela cheia, e uma regio para exibio do vdeo
do drible e da foto (frameReg).
5%
6.7%
frameReg
screenReg (100% x 100%)

Figura 3.2 Viso de leiaute.
54
A definio dos espaos de exibio pode ser realizada por meio de
elementos <property>, filhos dos elementos <media> que representam cada
objeto de mdia da aplicao, como ilustrado na Listagem 3.3.
<media id="animation" src="../media/animGar.mp4">
<area id="segDrible" begin="11.5s"/>
<property name="width" value="100%"/>
<property name="heigth" value="100%"/>
<property name="zIndex" value="2"/>
</media>
<media id="drible" src="../media/drible.mp4">
<property name="left" value="5%"/>
<property name="top" value="6.7%"/>
<property name="width" value="18.5%"/>
<property name="heigth" value="18.5%"/>
</media>
<media id="photo" src="../media/photo.png">
<property name="explicitDur" value="5s"/>
</media>
Listagem 3.3 Elementos <property>.
Todo elemento <property> possui um identificador vlido no escopo do
objeto de mdia, definidos por seu atributo name. Por exemplo, left, top
width, height, right, e bottom so propriedades que definem a rea de
apresentao em relao tela total do dispositivo de exibio (os valores
defaults para esses atributos, bem como o que acontece em caso de
inconsistncia de valores, so discutidos na Parte II do livro). Essas
propriedades podem ser definidas de forma absoluta ou como uma
porcentagem, sempre com relao tela total do dispositivo de exibio. A
propriedade zIndex especifica como fica a sobreposio de regies. Uma
regio de maior valor para zIndex se sobrepe quela de menor valor. Assim,
no exemplo, so definidas uma regio para exibio do vdeo da animao em
tela cheia, e uma regio para exibio do vdeo do drible e da foto se
sobrepondo ao vdeo da animao.
55
Elementos <property> podem ser usados para a definio do valor de
qualquer propriedade de um objeto de mdia, e no apenas aquelas que
definem espaos de exibio. Por exemplo, para o objeto de mdia
representando a foto, uma durao de 5s pode ser associada ao elemento
<media> correspondente, por meio de sua propriedade explicitDur, como
ilustra a Listagem 3.3.
Finalmente, podemos agora definir os relacionamentos de sincronizao
entre os vrios objetos de mdia. Em NCL, o elemento <body> agrupa todos
os objetos de um documento e seus relacionamentos.
O elemento <body> nico em um documento NCL e pode ter um ou
mais elementos <port> como filho. O elemento <port> indica por onde pode
comear uma exibio do documento. No nosso exemplo, como ilustrado na
Listagem 3.4, a exibio comea sempre pela apresentao do vdeo da
animao.
<body>
<port id="entry" component="animation"/>

<!definio dos diversos elementos de <media> do documento -->

<!definio dos diversos relacionamentos, elementos <link> do
documento -->
</body>
Listagem 3.4 Elementos <body> e <port>.
Relacionamentos so definidos por elementos <link>, como ilustrado na
Listagem 3.5, para nosso exemplo de O Primeiro Joo. O relacionamento
ilustrado define que, ao ser iniciada a exibio do vdeo da animao, o udio
com o chorinho tambm deve ser iniciado, mas 5 segundos depois (como
determinamos no enunciado do exemplo, esse objeto de mdia apresentado
aps os crditos iniciais do vdeo da animao, que duram 5 s).
<link id="lMusic" xconnector="onBeginStart_delay">
<bind role="onBegin" component="animation"/>
<bind role="start" component="choro">
<bindParam name="delay" value="5s"/>
</bind>
</link>
Listagem 3.5 Elementos <link> e <bind>.
Um relacionamento em NCL especificado referindo-se a uma relao,
dada pelo valor URI do atributo xconnector do elemento <link>, e pelos
56

atores que exercero os papis da relao, dados pelos elementos <bind>. Um
elemento <bind> especifica o papel da relao, atravs de seu atributo <role>,
e a interface que exercer o papel, dada pelos atributos component, que
seleciona um objeto a ser relacionado, e interface, que seleciona uma
interface desse objeto. Por enquanto, as nicas interfaces que definimos foram
por meio de elementos <area>. Quando no especificada, o valor default para
a interface assume uma rea contendo todo o contedo do objeto.
No relacionamento definido pelo elemento <link> lMusic da Listagem
3.5, a relao referenciada definida pelo elemento <causalConnector>, filho
do elemento <connectorBase>, conforme ilustra a Listagem 3.6. Na relao
(Listagem 3.5), o papel onBegin do conector associado ao componente
animation, que, como vimos na Listagem 3.2, associado ao vdeo da
animao, definindo que, ao comear a exibio do vdeo, deve-se dar partida
(role = start) exibio do chorinho, mas 5 segundos a partir do incio do
vdeo.
<connectorBase>
<causalConnector id="onBeginStart_delay">
<connectorParam name="delay"/>
<simpleCondition role="onBegin"/>
<simpleAction role="start" delay="$delay" max="unbounded"
qualifier="par"/>
</causalConnector>
</connectorBase>
Listagem 3.6 Elemento <causalConnector> e seus elementos filhos.
A relao causal, onde a condio dada pelo papel onBegin, e a
ao start, com o parmetro delay (retardo) a ser definido pelo
relacionamento (o elemento <link>), quando da sua especificao. O atributo
max=unbounded definido na ao especifica que um nmero ilimitado de
atores pode exercer esse papel. Quando existe mais de um ator para o papel, o
atributo qualifier define a forma como as aes devem ser executadas, se em
paralelo ou em sequncia.
A Figura 3.3 apresenta a viso estrutural da aplicao com todos os
relacionamentos entre os vrios objetos de mdia definidos.
57
onBegin
Start
onBegin
Start
onBegin
Start
onEnd
Stop

Figura 3.3 Viso estrutural.
Bases de conectores so definidas como elemento filho do elemento
<head>, que define, como veremos, as partes reusveis de uma aplicao. No
caso, um mesmo conector pode ser usado por mais de um elemento <link>. A
Listagem 3.7 apresenta a definio completa do elemento <head> da
aplicao exemplo.
<head>
<connectorBase>
qualifier="par"/>
</causalConnector>
<causalConnector id="onBeginStart">
<simpleAction role="start" max="unbounded" qualifier="par"/>
</causalConnector>
<causalConnector id="onEndStop">
<simpleCondition role="onEnd"/>
<simpleAction role="stop" max="unbounded" qualifier="par"/>
</causalConnector>
</connectorBase>
</head>
Listagem 3.7 Elemento <head> e seus elementos filhos.
Podemos agora definir todo o elemento <body> e seus filhos, para o
exemplo, apresentados na Listagem 3.8.
<body>
58
</media>
</media>
</media>
</bind>
</link>
<link id="lDrible" xconnector="onBeginStart">
<bind role="onBegin" component="animation"
interface="segDrible"/>
<bind role="start" component="drible"/>
</link>
<link id="lPhoto" xconnector="onBeginStart">
<bind role="onBegin" component="animation" interface="segPhoto"/>
<bind role="start" component="photo"/>
</link>
<link id="lEnd" xconnector="onEndStop">
<bind role="onEnd" component="animation"/>
<bind role="stop" component="choro"/>
</link>
</body>
Listagem 3.8 Elemento <body> e seus elementos filhos.
59
O elemento <link> lDrible define que, ao comear (role onBegin) o
trecho do vdeo da animao correspondente ao drible de vaivm do
Garrincha (component animation interface segDrible), o vdeo do drible
deve ser iniciado (role start).
De forma anloga, o elemento <link> lPhoto define que, ao comear
(role onBegin) o trecho do vdeo da animao correspondente ao momento
em que o marcador cai no cho (component animation interface
segPhoto), a foto do marcador deve ser exibida (role start).
Finalmente, o elemento <link> lEnd define que, ao findar (onEnd) o
vdeo da animao, o chorinho deve parar (stop) de tocar.
Os elementos <head> e <body> devem ser declarados como filhos do
elemento <ncl>, completando a definio do documento: a aplicao
declarativa NCL.
A Listagem 3.9 ilustra a aplicao completa. Note que toda aplicao
NCL comea com a linha:
<?xml version="1.0" encoding="ISO-8859-1"?>
seguida da especificao do elemento <ncl>, onde o atributo id define um
identificador para a aplicao e o atributo xmlns define o espao de nomes
(namespace) onde esto definidos os esquemas do perfil NCL EDTV, para
verificao, pelo parser XML, da validade da aplicao.

<ncl id="syncEx" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<connectorBase>
qualifier="par"/>
</causalConnector>
</causalConnector>
</causalConnector>
</connectorBase>
60
</head>

<body>
</media>
</media>
</media>
</bind>
</link>
<link id="lDrible" xconnector="onBeginStart">
</link>
<link id="lPhoto" xconnector="onBeginStart">
interface="segPhoto"/>
</link>
<link id="lEnd" xconnector="onEndStop">
61
</link>
</body>
</ncl>
Listagem 3.9 Documento NCL.
A Figura 3.4 ilustra dois momentos da exibio, o incio do drible do
Garrincha e o incio da apresentao da foto, obtidos durante a execuo da
aplicao na implementao de referncia do middleware Ginga-NCL.

Figura 3.4 Cenas da aplicao O Primeiro Joo.
3.3 Sincronismo de Mdia sem Interatividade, com
Reuso de Caractersticas de Apresentao e
Importao de Base
Nossa segunda aplicao idntica primeira, mas agora especificada
com a reutilizao das caractersticas de exibio dos vrios objetos de mdia
e com a definio da base de conectores externa ao documento NCL. Ou seja,
fora a nova sintaxe do documento NCL, nada mais foi acrescentado.
Nossa primeira alterao diz respeito definio das regies onde os
diversos objetos de mdia sero posicionados, que no ser mais especificada
por meio dos elementos <property>, filhos dos elementos <media>
correspondentes. Para permitir o reuso das regies, elas sero definidas
parte, por meio dos elementos <region>. O conjunto de elementos <region>
definido como filho do elemento <regionBase>, como ilustrado na Listagem
3.10.
62
<regionBase>
<region id="screenReg" width="100%" height="100%"
zIndex="2">
<region id="frameReg" left="5%" top="6.7%"
width="18.5%" height="18.5%" zIndex="3"/>
</region>
</regionBase>
Listagem 3.10 Elementos <region> e <regionBase>.
Todo elemento <region> possui um identificador e atributos homnimos
aos definidos pelos elementos <property> (left, top width, height, right,
bottom e ZIndex) que definem sua rea de exibio em relao regio pai
(os valores defaults para esses atributos, como j mencionamos, bem como o
que acontece em caso de inconsistncia de valores, so discutidos na Parte II
do livro). Note que esses atributos podem ser definidos de forma absoluta ou
como uma porcentagem, mas agora sempre com relao aos mesmos atributos
da regio pai. Quando o elemento no possui uma regio pai, o
posicionamento realizado com relao tela total do dispositivo de exibio.
Por exemplo, na Listagem 3.10, a regio frameReg definida como filha da
regio screenReg, ou seja, todos os valores definidos para seu
posicionamento so relativos regio screenReg. Note ainda que essa
regio ser reusada tanto para a definio do posicionamento da foto quanto
do posicionamento do vdeo do drible.
Avanando em nosso projeto da aplicao, temos agora de especificar
como as regies definidas (elementos <region>) so associadas aos vrios
objetos de mdia definidos (elementos <media>). Isso se d atravs dos
elementos <descriptor>. O conjunto de todos os descritores definido como
filho do elemento <descriptorBase>, como ilustrado na Listagem 3.11.
<descriptorBase>
<descriptor id="screenDesc" region="screenReg"/>
<descriptor id="photoDesc" region="frameReg" explicitDur="5s"/>
<descriptor id="audioDesc"/>
<descriptor id="dribleDesc" region="frameReg"/>
</descriptorBase>
Listagem 3.11 Elementos <descriptor> e <descriptorBase>.
O elemento <descriptor> especifica as caractersticas iniciais para a
exibio de um objeto de mdia, inclusive seu posicionamento, dado por seu
atributo region, que usado para referenciar um elemento <region>. Um
descritor pode ter outros atributos adicionais, como o atributo explicitDur,
que determina o tempo de durao explcita de uma mdia. Por exemplo, o
63
elemento <descriptor> photoDesc especifica que a mdia deve ser exibida
por 5 segundos. Note assim que o elemento <descriptor> pode definir outras
propriedades de um objeto de mdia que no as de posicionamento, no caso
exemplo, a propriedade explicitDur, definida na Seo 3.2 por meio do
elemento <property>. Propriedades definidas pelo elemento <descriptor>
podem ser reusadas na definio de vrios objetos de mdia.
muito importante ressaltar que os elementos <region> e <descriptor>
no definem novas propriedades, mas valores iniciais para propriedades
reservadas de um objeto de mdia. Vrias dessas propriedades sero
apresentadas medida que avanamos com nosso exemplo. Uma lista dessas
propriedades apresentada no Captulo 9.
Como mencionamos, um elemento <descriptor> ligado a um objeto de
mdia pelo atributo descriptor do elemento <media> que representa o objeto,
como ilustra a Listagem 3.12 na definio de todos os elementos <media>,
agora sem os elementos <property> filhos.
</media>
<media id="choro" src="../media/choro.mp3" descriptor="audioDesc"/>
<media id="drible" src="../media/drible.mp4"
descriptor="dribleDesc"/>
<media id="photo" src="../media/photo.png" descriptor="photoDesc"/>
Listagem 3.12 Elementos <media> redefinidos.
Voltemos nossa ateno agora para os conectores. Em relacionamentos
definidos por elementos <link>, a relao referenciada pode ser definida em
um documento externo, que deve ser importado para o documento em
questo. Isso especificado pelo elemento <importBase>, filho do elemento
<connectorBase>, conforme ilustra a Listagem 3.13. Na listagem, conectores
esto definidos em um arquivo, com o nome causalConnBase.ncl, no
mesmo diretrio onde se encontra o diretrio com nosso documento NCL de
exemplo. Esse arquivo de conectores, usados em todos os exemplos que se
seguem neste captulo, ser conhecido pelo apelido conEx, como definido
pelo atributo alias. O contedo desse arquivo apresentado no Apndice D.
<connectorBase>
<importBase documentURI="../causalConnBase.ncl" alias="conEx"/>
</connectorBase>
Listagem 3.13 Elementos <importBase> e <connectorBase>.
64

Ao referenciar um conector definido externamente ao documento, um
elemento <link> deve concatenar o valor do atributo alias com o caractere
especial # seguido do identificador do conector. Os mesmos conectores
definidos na Seo 3.2, quando definidos externamente no arquivo
causalConnBase.ncl, devem ser referenciados como ilustra a Listagem
3.14, que apresenta a redefinio de todos os elementos <link> do exemplo O
Primeiro Joo.
<body>

<link id="lMusic" xconnector="conEx#onBeginStart_delay">
</bind>
</link>
<link id="lDrible" xconnector="conEx#onBeginStart">
</link>
<link id="lPhoto" xconnector="conEx#onBeginStart">
</link>
<link id="lEnd" xconnector="conEx#onEndStop">
</link>
</body>
Listagem 3.14 Redefinio dos elementos <link>.
Todas as bases que definimos, <regionBase>, <descriptorBase> e
<connectorBase>, devem ser filhas do elemento <head> da NCL, como
ilustrado na Listagem 3.15.
65
<head>
<regionBase>
zIndex="2">
<region id="frameReg" left="5%" top="6.7%" width="18.5%"
height="18.5%" zIndex="3"/>
</region>
</regionBase>
<descriptorBase>
<descriptor id="photoDesc" region="frameReg"
explicitDur="5s"/>
</descriptorBase>
<connectorBase>
<importBase documentURI="../causalConnBase.ncl"
alias="conEx"/>
</connectorBase>
</head>
Listagem 3.15 Elemento <head> e seus elementos filhos.
A Listagem 3.16 apresenta a aplicao completa.

<ncl id="sync" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
zIndex="2">
</region>
</regionBase>
<descriptorBase>
explicitDur="5s"/>
</descriptorBase>
66
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>
<body>
</media>
<media id="choro" src="../media/choro.mp3"
descriptor="audioDesc"/>
<media id="photo" src="../media/photo.png"
descriptor="photoDesc"/>
</bind>
</link>
</link>
</link>
</link>
</body>
</ncl>
Listagem 3.16 Documento NCL com reuso e importao.
67
3.4 Adicionando Sincronismo com Interatividade
Vamos agora incrementar nossa aplicao introduzindo um exemplo de
sincronismo temporal com a interao do usurio.
Em certo trecho do vdeo da animao, ao cair no cho, o adversrio do
nosso Garrincha mostra sua chuteira. Nesse instante, faremos aparecer o
cone de uma chuteira que, se selecionado pelo telespectador atravs do boto
vermelho do controle remoto, far aparecer um vdeo de propaganda da
chuteira. Lembramos que, na animao, Garrincha era uma criana pobre, ele
jogava descalo. Assim, no vdeo de propaganda, tambm realizado pelo
Ponto de Cultura CIDS-VG, aparece uma criana, a mesma que representou
Garrincha no vdeo do drible e na foto, sonhando em possuir uma chuteira.
Durante a exibio do vdeo de propaganda, o vdeo da animao dever ser
redimensionado, possibilitando a exibio simultnea dos dois vdeos sem
sobreposio, mas se sobrepondo a uma imagem de fundo introduzida no
exemplo.
A Figura 3.5 ilustra a viso estrutural da nova verso da aplicao.
Note o acrscimo de trs objetos de mdia, de uma nova ncora para o vdeo
animao, de trs novos relacionamentos e na modificao (extenso) dos
relacionamentos que davam partida ao udio e comandavam seu fim.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Set
size
Start
onSelection
Set
size
onBegin
Start
Stop
onEnd

Figura 3.5 Viso estrutural.
Temos, ento, de modificar a definio do elemento <media> que
representa a animao, introduzindo uma nova ncora, ou seja, um novo
elemento <area>, correspondendo ao tempo em que o cone da chuteira dever
aparecer. Como o vdeo da animao deve ser redimensionado, caso o cone
seja selecionado, necessrio definir as propriedades de leiaute que sero
modificadas. As propriedades de um objeto de mdia passveis de
manipulao atravs de relacionamentos devem ser explicitadas por meio de
68
elementos <property>, mesmo que seus valores iniciais sejam definidos
usando elementos <descriptor> ou <region>. No caso, queremos manipular as
variveis de posicionamento e dimenso (left, top, width, height),
representadas pelo valor bounds, como ilustrado pela Listagem 3.17, onde
tambm ilustrada a incluso dos trs novos objetos de mdia no conjunto de
objetos de mdia anteriormente definido: a imagem de fundo (background),
o cone (icon) e o vdeo de propaganda (shoes).
<media id="background" src="../media/background.png"
descriptor="backgroundDesc"/>
<area id="segIcon" begin="45s" end="51s"/>
<property name="bounds"/>
</media>
<media id="icon" src="../media/icon.png" descriptor="iconDesc"/>
<media id="shoes" src="../media/shoes.mp4" descriptor="shoesDesc"/>
Listagem 3.17 Conjunto de elementos <media> da nova verso da aplicao.
Temos agora de acrescentar os descritores e as regies para a
apresentao dos novos objetos de mdia, como ilustra a Listagem 3.18. Note
que as novas regies para exibio do cone e do vdeo de propaganda foram
definidas como filhas do elemento <region> screenReg, ou seja, relativas a
essa regio previamente definida.
<regionBase>
...
<region id="screenReg" width="100%" height="100%" zIndex="2">
...
<region id="iconReg" left="87.5%" top="11.7%" width="8.45%"
<region id="shoesReg" left="15%" top="60%" width="25%"
height="25%" zIndex="3"/>
</region>
</regionBase>
<descriptorBase>
...
<descriptor id="iconDesc" region="iconReg" explicitDur="6s"/>
69
<descriptor id="shoesDesc" region="shoesReg"/>
</descriptorBase>
Listagem 3.18 Definio dos novos elementos <region> e dos novos elementos
<descriptor>.
Resta agora definir os trs novos relacionamentos introduzidos, e
incorporar aos relacionamentos lMusic e lEnd as aes para iniciar e
terminar a apresentao da imagem de fundo, como ilustra a Listagem 3.19.
<bind role="start" component="background">
</bind>
</bind>
</link>

<bind role="stop" component="background"/>
</link>

<link id="lIcon" xconnector="conEx#onBeginStart">
interface="segIcon"/>
<bind role="start" component="icon"/>
</link>

<link id="lAdvert" xconnector="conEx#onKeySelectionStopSet_varStart">
<bind role="onSelection" component="icon">
<bindParam name="keyCode" value="RED"/>
</bind>
<bind role="set" component="animation" interface="bounds">
<bindParam name="var" value="5%,6.67%,45%,45%"/>
</bind>
<bind role="start" component="shoes"/>
<bind role="stop" component="icon"/>
</link>

<link id="lEndAdvert" xconnector="conEx#onEndSet">
70
<bind role="onEnd" component="shoes"/>
<bindParam name="varSet" value="0,0,222.22%,222.22%"/>
</bind>
</link>
Listagem 3.19 Definio dos novos relacionamentos.
Os dois primeiros elementos <link> (lMusic e lEnd) determinam o
incio e o fim da exibio da imagem de fundo como coincidindo com o incio
e fim da exibio do udio chorinho, respectivamente.
O terceiro elemento <link> (lIcon) define que, ao comear (condio
onBegin) a apresentao do trecho da animao quando o cone deve
aparecer, ele tenha sua apresentao iniciada (ao start).
O quarto elemento <link> (lAdvert) mais complexo. Ele define que,
se o cone da chuteira for selecionado (condio onSelection) pela tecla
vermelha do controle remoto (passada como parmetro do papel
correspondente, keycode=RED), o vdeo da animao deve ser
redimensionado (ao set na propriedade bounds definida no elemento
animation) para os valores passados como parmetros (left=5%,
top=6,67%, width e height =45%, todos relativos aos valores iniciais). O
relacionamento tambm determina que a propaganda da chuteira deve ser
iniciada (ao start no elemento shoes) e que o cone deve parar sua
exibio (ao stop no elemento icon).
O quinto elemento <link> (lEndAdvert) especifica que, quando o
vdeo correspondente propaganda da chuteira terminar (condio onEnd),
o vdeo da animao deve retomar suas dimenses originais (ao set na
propriedade bounds definida no elemento animation).
A Listagem 3.20 apresenta o programa NCL correspondente nova
verso da aplicao.

<ncl id="syncInt" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="backgroundReg" width="100%" height="100%"
zIndex="1"/>
zIndex="2">
71
<region id="iconReg" left="87.5%" top="11.7%"
</region>
</regionBase>
<descriptorBase>
<descriptor id="backgroundDesc" region="backgroundReg"/>
explicitDur="5s"/>
<descriptor id="iconDesc" region="iconReg"
explicitDur="6s"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>

<body>
</media>
<media id="icon" src="../media/icon.png"
descriptor="iconDesc"/>
<media id="shoes" src="../media/shoes.mp4"
descriptor="shoesDesc"/>
72
</bind>
</bind>
</link>
</link>
</link>
</link>
</link>
<link id="lAdvert"

xconnector="conEx#onKeySelectionStopSet_varStart">
</bind>
</bind>
</link>
<link id="lEndAdvert" xconnector="conEx#onEndSet">
73
<bindParam name="varSet" value="0,0,222.22%,222.22%"/>
</bind>
</link>
</body>
</ncl>
Listagem 3.20 O Primeiro Joo com sincronismo por interao.
A Figura 3.6 ilustra mais dois momentos da exibio, o incio do
aparecimento do cone e o momento da apresentao da propaganda, obtidos
durante a execuo da aplicao na implementao de referncia do
middleware Ginga-NCL.

Figura 3.6 Cenas da aplicao O Primeiro Joo com interatividade.
3.5 Adicionando o Uso de Contextos
Em NCL, elementos <context> podem ser usados para estruturar uma
aplicao. Nesta seo vamos exemplificar o uso de contextos, agrupando
todos os elementos da propaganda da chuteira. Isso possibilitaria, alm de
maior estruturao do programa, o reso de toda a estrutura. Vamos tratar o
reso na prxima seo.
74
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Set
size
Start
Set
size
onBegin
Start
Stop
onEnd
onSelection
onSelection

Figura 3.7 Cenas da aplicao O Primeiro Joo usando contextos.
Note, na Figura 3.7, que no possvel acessar diretamente objetos de
mdia dentro de um contexto. Como visto no Captulo 2, o acesso deve ser
feito passando pelas portas, que so responsveis por exportar o que visvel
dentro de um contexto por relacionamentos externos. Portanto, ns devemos
no s incluir os elementos <media> icon e shoes dentro de um elemento
<context>, como tambm redefinir os trs relacionamentos definidos na seo
anterior. Mais ainda, note que um dos relacionamentos pode ser definido
dentro do prprio contexto, uma vez que s envolve elementos que so seus
filhos. Assim, a definio do contexto fica como ilustrado na Listagem 3.21.
<context id="advert">
<port id="pIcon" component="icon"/>
<port id="pShoes" component="shoes"/>
<link id="lBeginShoes"
xconnector="conEx#onKeySelectionStopStart">
</bind>
</link>
</context>
Listagem 3.21 Uso do elemento <context> na definio da propaganda da chuteira.
75
Note que o contexto oferece duas portas para o mundo exterior: uma
para seu componente icon, que ser usada como entrada no comando de
incio da apresentao do cone e como sada no comando para o
redimensionamento do vdeo da animao; e uma porta para o componente
shoes, que ser usada como sada no comando para restaurar o vdeo da
animao em suas dimenses originais.
Os trs relacionamentos definidos na seo anterior foram
desmembrados em quatro, para que um relacionamento seja definido dentro
do contexto. Esse relacionamento, identificado como lBeginShoes na
Listagem 3.21, especifica que ao ser selecionado (condio onSelection) o
cone da chuteira, por meio do boto vermelho do controle remoto, a
propaganda deve iniciar (ao start sobre o componente shoes) e a figura
do cone deve findar sua exibio (ao stop sobre o componente icon).
Os outros trs relacionamentos restantes so especificados como filhos
do elemento <body>, substituindo os trs relacionamentos definidos na seo
anterior, como ilustra a Listagem 3.22, que apresenta o novo programa para
essa nova verso. Note os novos relacionamentos lIcon, lAdvert,
lEndAdvert.

<ncl id="contextExample"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
zIndex="1"/>
zIndex="2">
</region>
</regionBase>
<descriptorBase>
explicitDur="5s">
<descriptorParam name="transparency" value="0.6"/>
76
</descriptor>
explicitDur="6s"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>

<body>
</media>
<port id="pShoes" component="shoes"/>
</bind>
77
</link>
</context>
</bind>
</bind>
</link>
</link>
</link>
</link>
<bind role="start" component="advert" interface="pIcon"/>
</link>
<link id="lAdvert" xconnector="conEx#onKeySelectionSet_var">
<bind role="onSelection" component="advert"
interface="pIcon">
</bind>
</bind>
</link>
<link id="lEndAdvert" xconnector="conEx#onEndSet_var">
<bind role="onEnd" component="advert" interface="pShoes"/>
<bindParam name="var" value="0,0,222.22%,222.22%"/>
78
</bind>
</link>
</body>
</ncl>
Listagem 3.22 O Primeiro Joo com uso de contextos.
3.6 Adicionando Reso de Objetos de Mdia
O reso de objetos de mdia e de contexto torna uma aplicao mais
limpa, mais fcil de manter e menos sujeita a erros. Mesmo correndo o risco
de tornar o contexto definido na seo anterior menos passvel de reso em
outras partes do vdeo da animao (ou mesmo em outro vdeo), vamos
utilizar esse contexto para introduzir o reso de objetos de mdia, com o
intuito apenas de tornar mais simples a definio de relacionamentos.
O que faremos criar um novo objeto de mdia dentro do elemento
<context> advert, que herdar toda a definio do elemento <media>
animation e, mais ainda, representar o mesmo objeto de mdia: o vdeo da
animao. Como discutido na Seo 2, o modelo NCL permite que um mesmo
n esteja contido em mais de um contexto, e isso feito atravs do reso.
A Figura 3.8 ilustra o reso do elemento <media> animation. Note a
simplificao da definio dos elos ligados propaganda da chuteira, uma
vez que agora eles so internos ao contexto e no precisam mais utilizar
portas para o acesso ao vdeo da animao.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Set
size
Start
onSelection
Set
size
onBegin
Start
Stop
onEnd

Figura 3.8 Reso.
79
O novo elemento <media> definido dentro do contexto tem a definio
dada pela Listagem 3.23. Note que o uso do atributo refer indica que o
elemento herdar toda a definio do elemento referido, no caso o
animation. O elemento referenciado e o elemento que o referencia tambm
devem ser considerados o mesmo n em relao apresentao se o atributo
instance receber um valor instSame, como no caso presente.
<media id="reusedAnimation" refer="animation" instance="instSame">
</media>
Listagem 3.23 Reso de objeto de mdia.
Note tambm que, no novo elemento, novas interfaces (elementos
<area> e <property>) podem ser criadas. No caso, para exemplificar,
retiraremos a definio da propriedade bounds do elemento animation e a
reincluiremos no reuso do elemento, como indicado na Listagem 3.23.
Nessa nova verso, os quatro relacionamentos introduzidos na seo
anterior devem ser modificados e redefinidos como pertencendo ao contexto.
Os quatro relacionamentos voltam a ser apenas trs, e agora devem
referenciar o elemento <media> reusedAnimation, como ilustra a Listagem
3.24, contendo todo o novo programa NCL.

<ncl id="reuse" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
zIndex="1"/>
zIndex="2">
</region>
</regionBase>
<descriptorBase>
explicitDur="5s"/>
80
explicitDur="6s"/>
</descriptorBase>
<connectorBase>
</connectorBase>
</head>
<body>
</media>
<media id="reusedAnimation" refer="animation"
instance="instSame">
</media>
<bind role="onBegin" component="reusedAnimation"
</link>
81
</bind>
<bind role="set" component="reusedAnimation"
interface="bounds">
</bind>
</link>
<link id="lEndShoes" xconnector="conEx#onEndSet_var">
interface="bounds">
</bind>
</link>
</context>
</bind>
</bind>
</link>
</link>
</link>
</link>
</body>
</ncl>
Listagem 3.24 O Primeiro Joo com reso.
82
3.7 Usando o Canal de Interatividade
Vamos agora acrescentar em nosso exemplo o uso do canal de
interatividade. Nessa nova verso do programa NCL, caso o cone da chuteira
seja selecionado, vamos no s apresentar a propaganda da chuteira, mas
tambm um formulrio HTML. O formulrio, se devidamente preenchido e
enviado loja da propaganda por meio do canal de interatividade, trar como
resposta a confirmao da compra. A loja, tendo recebido o formulrio, pode
depois providenciar a entrega do material adquirido.
Note que as nicas modificaes foram a introduo de um objeto de mdia
representando o formulrio no contexto da propaganda, o acrscimo de mais
um ator no relacionamento disparado pela seleo do cone da chuteira, que
permitir a exibio do formulrio, e o fato de que agora no o final da
exibio da propaganda da chuteira que volta o vdeo da animao ao seu
tamanho original, mas sim o final do preenchimento do formulrio ou o final
do tempo mximo para seu preenchimento.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Set
size
Start
onSelection
Set
size
onBegin
Start
Stop
onEnd
Start

Figura 3.9 Viso estrutural da verso com o uso do canal de interatividade.
Ao termos de introduzir um novo elemento de <media>, temos tambm
de introduzir o elemento <region> especificando onde ele ser apresentado, e
o elemento <descriptor>, fazendo a ligao do elemento <media> com o
elemento <region>. A Listagem 3.25 ilustra os novos elementos inseridos.
Note, mais uma vez, que a regio definida para a exibio do formulrio
filha da regio definida para a exibio do vdeo da animao, ou seja, o
posicionamento da primeira realizado relativo segunda. Note tambm que
no descritor foi especificado um tempo mximo para o preenchimento do
formulrio, no caso igual a 45 segundos.
83
<head>
<regionBase>
...
...
<region id="formReg" left="56.25%" top="8.33%"
</region>
</regionBase>
<descriptorBase>
...
<descriptor id="formDesc" region="formReg" focusIndex="1"
explicitDur="45s"/>
</descriptorBase>
...
</head>

<body>
...
...
<media id="ptForm" src="../media/ptForm.htm"
descriptor="formDesc"/>
...
</context>
...
</body>
Listagem 3.25 Novos elementos para a apresentao do formulrio.
Ainda na Listagem 3.25, note que no elemento <descriptor> formDesc
um novo atributo foi definido: focusIndex. Esse atributo define o elemento em
foco para navegao por setas do controle remoto. No caso s h um
elemento, mas quando incrementarmos mais nosso exemplo, na Seo 3.12,
outros elementos focveis sero definidos. L explicaremos melhor esse
atributo. Um elemento em foco, caso seja pressionada a tecla ENTER,
passa a receber (controlar) toda a navegao pelo controle remoto at que a
tecla BACK seja pressionada, retornando ento o controle ao formatador
NCL. No caso em questo, aps ser pressionada a tecla ENTER, o
formulrio HTML pode ser preenchido.
Devemos agora alterar alguns relacionamentos da verso anterior para
espelhar a nova verso. O relacionamento lBeginShoes deve acrescentar um
papel ao para dar incio apresentao do formulrio. O relacionamento
84
lEndShoes deve ser substitudo pelo relacionamento lEndForm, uma vez
que agora o trmino da apresentao do formulrio que volta o vdeo da
animao para seus valores de posicionamento iniciais, e no mais o trmino
do vdeo de propaganda da chuteira. Os relacionamentos modificados so
apresentados na Listagem 3.26.
</bind>
<bind role="start" component="ptForm"/>
interface="bounds">
</bind>
</link>
<link id="lEndForm" xconnector="conEx#onEndSet_var">
<bind role="onEnd" component="ptForm"/>
interface="bounds">
</bind>
</link>
Listagem 3.26 Relacionamentos modificados para a nova verso.
A especificao completa da nova verso com uso do canal de
interatividade ilustrada na Listagem 3.27.

<ncl id="return" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
zIndex="1"/>
zIndex="2">
85
</region>
</regionBase>
<descriptorBase>
explicitDur="5s"/>
explicitDur="6s"/>
explicitDur="15s"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>
<body>
</media>
86
</media>
</link>
</bind>
interface="bounds">
</bind>
</link>
<bind role="onEnd" component="ptForm"/>
interface="bounds">
</bind>
</link>
</context>
</bind>
</bind>
</link>
87
</link>
</link>
</link>
</body>
</ncl>
Listagem 3.27 O Primeiro Joo com uso do canal de interatividade.
A Figura 3.10 ilustra o momento da apresentao da propaganda da
chuteira, obtido durante a execuo da aplicao na implementao de
referncia do middleware Ginga-NCL.

Figura 3.10 Cenas da aplicao O Primeiro Joo com uso do canal de interatividade.
3.8 Uso de Mltiplos Dispositivos de Exibio
Podemos agora alterar a verso anterior da aplicao para trabalhar
com mltiplos dispositivos de exibio.
88
Vamos, nessa nova verso, exibir toda a propaganda interativa, ou seja,
o vdeo da propaganda e o formulrio de compra, em outro dispositivo
diferente do usado para a apresentao das demais mdias.
Quando fazemos uso de mais de um dispositivo de exibio, devemos
para cada base de regies (elemento <regionBase>) especificar a que
dispositivo as regies definidas se referem. Isso feito no atributo device do
elemento <regionBase>, como ilustra a Listagem 3.28; quando no declarado,
assume um valor default.
<regionBase>
zIndex="1">
</region>
</regionBase>

<regionBase device="systemScreen(1)">
zIndex="1">
<region id="shoesReg" left="0" top="25%" width="50%"
<region id="formReg" left="50%" top="0" width="50%"
</region>
</regionBase>
Listagem 3.28 Uso de mltiplos dispositivos de exibio.
Na Listagem 3.28, o vdeo da animao, o vdeo do drible, a foto do
marcador cado e o cone da chuteira aparecero na tela do dispositivo-base
da apresentao, declarado por default. No caso do Sistema Brasileiro de TV
Digital Terrestre, por default o dispositivo-base a tela da TV. J a figura de
fundo, a propaganda da chuteira e o formulrio a preencher aparecero em
um segundo dispositivo de exibio; por exemplo, a tela de um celular usado
para interao.
O programa NCL deve agora ser modificado porque, como no haver
mais superposio de informaes, no necessrio redimensionar o vdeo da
animao. Fica por conta do leitor fazer essas modificaes, visto que no
prosseguiremos mais com esse exemplo at o Captulo 15 A Figura 3.11
ilustra o momento da apresentao da propaganda, obtido durante a execuo
da aplicao na implementao de referncia do middleware Ginga-NCL.
89

Figura 3.11 Cenas da aplicao O Primeiro Joo com o uso de mltiplos dispositivos.
3.9 Adaptao de Contedo
Vamos agora voltar verso da Seo 3.7 e nela acrescentar a
facilidade de adaptao de contedo. Para tanto, vamos exibir o formulrio
em diferentes lnguas, dependendo do perfil do telespectador. Se o usurio
falar a lngua inglesa, vamos apresentar o formulrio em ingls; caso
contrrio, apresentaremos o formulrio em portugus.
A viso estrutural para essa verso do programa NCL ilustrada na
Figura 3.12.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Set
size
Start
onSelection
Set
size
onBegin
Start
Stop
onEnd
Start

Figura 3.12 Viso estrutural da verso com adaptao de contedo.
90
O leitor deve notar, comparando a Figura 3.9 e a Figura 3.12, que a
nica diferena ocorre no objeto de mdia que representa o formulrio. Na
Figura 3.12, esse objeto substitudo por um elemento <switch>,
representado em cinza dentro do contexto da propaganda. O elemento
<switch>, por sua vez, contm tanto o objeto de mdia representando o
formulrio em portugus quanto o objeto de mdia representando o formulrio
em ingls. Todos os relacionamentos que tinham como ator o objeto de mdia
formulrio (ptForm), na verso da Seo 3.7, devem agora se referenciar ao
elemento <switch> na nova verso do programa NCL.
O elemento <switch> escolhe um dos seus componentes filhos para
apresentar, baseado em um conjunto de regras. As regras devem ser
especificadas como filhas do elemento <ruleBase>, que por sua vez filho do
elemento <head>, conforme ilustrado para o exemplo em questo na Listagem
3.29.
<head>
<ruleBase>
<rule id="en" var="system.language" value="en"
comparator="eq"/>
</ruleBase>
...
</head>
Listagem 3.29 Elementos <ruleBase> e <rule>.
Um elemento <rule> tem um identificador, um atributo especificando
uma varivel a ser testada (var), um atributo especificando o valor sobre o
qual a varivel deve ser testada (value) e um atributo especificando o
operador de comparao. No caso da Listagem 3.29, a regra en
especificada para testar se a varivel system.language tem seu valor igual a
en. A varivel system.language uma varivel controlada pelo sistema
receptor, que atribui um valor a ela dependendo do idioma do usurio
telespectador. Vrias so as variveis controladas pelo sistema. O Captulo 9
discute o uso e a manuteno dessas variveis.
A adaptao do contedo especificada pelo elemento <switch>,
conforme ilustrado na Listagem 3.30 para a nova verso de O Primeiro Joo.
<switch id="form">
<switchPort id="spForm">
<mapping component="enForm"/>
<mapping component="ptForm"/>
</switchPort>
<bindRule constituent="enForm" rule="en"/>
<defaultComponent component="ptForm"/>
91
<media id="enForm" src="../media/enForm.htm"
</switch>
Listagem 3.30 Elementos <switch> e seus elementos filhos.
Um relacionamento no pode referenciar diretamente um elemento filho
do <switch>, mas pode faz-lo indiretamente por meio de portas do switch.
Um elemento <switchPort> define uma porta que pode ser usada para
referenciar qualquer interface de um elemento filho do <switch> para o qual
um mapeamento (elemento <mapping>) com a porta foi estabelecido. Em
outras palavras, quando o relacionamento estabelecido com uma
<switchPort>, a interface do elemento selecionado pelo switch e que tem
mapeamento com a porta que participa como ator do relacionamento.
O elemento <bindRule> determina qual elemento filho do <switch>
escolhido, dependendo da regra definida pelo elemento <rule>, por ns j
discutida. Por exemplo, na Listagem 3.30, se a regra en for atendida
(lembre-se de que essa regra especificava que o idioma do usurio
telespectador era o ingls), o elemento <media> enForm dever ser
escolhido.
As regras so avaliadas em sequncia, e a primeira regra que atende s
exigncias tem seu componente selecionado. Caso nenhuma regra seja
satisfeita, o componente definido no elemento <defaultComponent> deve ser
escolhido. Um elemento <switch> pode ter como elementos filhos
selecionveis elementos <media> ou <context>.
Como mencionamos anteriormente, essa nova verso do programa NCL
deve modificar seus relacionamentos para referenciarem o elemento <switch>,
definido na Listagem 3.30, e no mais diretamente o elemento <media>
ptForm, conforme ilustra a Listagem 3.31. Note a referncia ao elemento
<switch> form e sua porta (<switchPort>) spForm.
</bind>
<bind role="start" component="form" interface="spForm"/>
interface="bounds">
92
</bind>
</link>

<bind role="onEnd" component="form" interface="spForm"/>
interface="bounds">
</bind>
</link>
Listagem 3.31 Redefinio dos relacionamentos para referncia ao elemento <switch>.
A especificao completa da nova verso do programa NCL ilustrada
na Listagem 3.32.

<ncl id="switch" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<ruleBase>
comparator="eq"/>
<rule id="int" var="service.interactivity" value="true"
comparator="eq"/>
</ruleBase>
<regionBase>
zIndex="1"/>
zIndex="2">
</region>
</regionBase>
<descriptorBase>
93
explicitDur="5s"/>
explicitDur="6s"/>
explicitDur="15s"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>

<body>
</media>
</media>
<switch id="form">
94
</switchPort>
</switch>
</link>
</bind>
interface="bounds">
</bind>
</link>
interface="bounds">
</bind>
</link>
</context>
</bind>
</bind>
95
</link>
</link>
</link>
</link>
</body>
</ncl>
Listagem 3.32 O Primeiro Joo com adaptao de contedo.
3.10 O Uso do N Settings
Vamos agora permitir em nossa aplicao O Primeiro Joo que todas as
propagandas interativas (e s elas) sejam habilitadas ou inibidas pelo
telespectador. Se inibidas, por exemplo, o cone da chuteira nem aparecer,
impossibilitando o acionamento da propaganda correspondente.
Para fazer o controle da interatividade, vamos definir uma varivel
global do programa (servio) denominada service.interactivity. Conforme o
valor dessa varivel, as propagandas interativas sero inibidas
(service.interactivity = false) ou habilitadas (service.interactivity = true).
Na verdade, o valor da varivel ser usado (testado nos relacionamentos) para
permitir ou no o aparecimento dos cones que permitem a propaganda
interativa (no caso da nossa aplicao, o cone da chuteira).
Em uma aplicao NCL, variveis globais so tratadas como
propriedades do n settings. Em NCL, esse n representado pelo elemento
<media>, com atributo type igual a application/x-ncl-settings. Propriedades
cujos valores podem ser manipulados por uma aplicao NCL devem ser
declaradas no elemento <property> filho do elemento <media> representando
o n settings (exceto quando a manipulao for pelas regras, como
discutiremos no Captulo 11). Assim, para nossa nova verso da aplicao, o
96
n settings deve ser declarado e seu valor iniciado, como ilustra a Listagem
3.33.
<media id="globalVar" type="application/x-ncl-settings">
<property name="service.interactivity" value="true"/>
</media>
Listagem 3.33 O elemento <media> do tipo application/x-ncl-settings.
Para o controle das propagandas interativas, vamos definir um contexto
de interatividade, pois assim ser possvel seu reso em outras aplicaes, o
que tornar tambm nosso programa mais bem estruturado. O elemento
<context> interactivity conter o n settings, um cone para avisar o
usurio telespectador que a interatividade est ativa e outro para alertar que
ela est inibida. Conforme o usurio selecione um cone, ele substitudo pelo
outro, permitindo assim ao usurio habilitar e desabilitar a interatividade.
Cada vez que o cone trocado, a varivel service.interactivity muda de
valor.
Como, no incio da aplicao, o cone informando que a interatividade
est habilitada (iniciao do procedimento) deve ser exibido e a varivel
colocada em true, vamos, para facilitar a estruturao, colocar um elemento
<media> no contexto de interatividade representando a mesma instncia de
apresentao do filme da animao, que dar partida ao procedimento de
iniciao. A colocao desse elemento de fato dificulta o reso do contexto
em outra aplicao, mas vamos usar o procedimento mesmo assim para mais
uma vez exemplificar o mecanismo de reso.
A Figura 3.13 ilustra a viso estrutural do contexto de interatividade.
Set Ioff
Set Ioff
Start
Start
Start
Set Ion
onBegin
onSelection
Stop
onSelection
Stop

Figura 3.13 Viso estrutural do contexto de interatividade.
O leitor deve notar a existncia de trs relacionamentos. O primeiro
inicia a varivel service.interactivity e a exibio do cone intOn. O
segundo, quando da seleo do cone intOn pela tecla INFO, para sua
exibio, inicia a apresentao do cone intOff e troca o valor de
service.interactivity. O terceiro parecido com o segundo, quando da seleo
do cone intOff pela tecla INFO, para sua exibio, inicia a apresentao
97
do cone intOn e troca o valor de service.interactivity. A Listagem 3.34
apresenta o cdigo NCL correspondente.
<context id="interactivity">
</media>
<media id="anotherAnimation" refer="animation"
instance="instSame"/>
<media id="intOn" src="../media/intOn.png" descriptor="intDesc"/>
<media id="intOff" src="../media/intOff.png" descriptor="intDesc"/>
<link id="lInt" xconnector="conEx#onBeginSet_varStart">
<bind role="onBegin" component="anotherAnimation"/>
<bind role="start" component="intOn"/>
<bind role="set" component="globalVar"
interface="service.interactivity">
<bindParam name="var" value="true"/>
</bind>
</link>
<link id="lOn" xconnector="conEx#onKeySelectionStopSet_varStart">
<bind role="onSelection" component="intOn">
<bindParam name="keyCode" value="INFO"/>
</bind>
<bind role="start" component="intOff"/>
<bind role="stop" component="intOn"/>
<bindParam name="var" value="false"/>
</bind>
</link>
<link id="lOff" xconnector="conEx#onKeySelectionStopSet_varStart">
<bind role="onSelection" component="intOff">
</bind>
<bind role="stop" component="intOff"/>
</bind>
</link>
</context>
Listagem 3.34 Contexto de interatividade.
98
Agora, que j temos a manipulao da varivel service.interactivity
definida, vamos usar seu valor para controlar o aparecimento ou no do cone
da chuteira, que habilita a propaganda interativa. Para tanto, temos de
modificar o relacionamento que d o incio da apresentao do cone, para
que ele teste antes o valor da varivel service.interactivity. Como a varivel
uma propriedade do n settings, vamos reus-lo (aqui, sim, um exemplo de
reso bem til) dentro do contexto da propaganda como o ator (de fato sua
propriedade service.interactivity) do relacionamento que dispara a
apresentao do cone. A Figura 3.14 ilustra a viso estrutural de toda a nova
verso de O Primeiro Joo. Note que um novo elemento <bind> foi
adicionado ao elo que finaliza todos os objetos ao trmino do vdeo da
animao. Esse novo elemento <bind> ligado ao contexto de interatividade
sem especificar nenhuma porta de entrada. Isso significa, em NCL, que a
ao stop do elo ser aplicada a todos os objetos do contexto que ainda
esto sendo apresentados.
Set Ioff
Set Ioff
Start
Start
Start
Set Ion
onBegin
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Contexto de Propaganda
Contexto de Interatividade
Set
size
Start
onSelection
Set
size
onBegin
Start
Stop
onEnd
I = on
Start onSelection
Stop
onSelection
Stop
Stop

Figura 3.14 Viso estrutural da nova verso de O Primeiro Joo.
O leitor deve observar, pela comparao do contexto de propaganda da
Figura 3.12 e da Figura 3.14, que apenas um relacionamento mudou. Todo o
resto permaneceu igual. O novo relacionamento deve testar o valor da
varivel service.interactivity para iniciar ou no a apresentao do cone da
chuteira, conforme o valor dessa varivel, conforme ilustra a Listagem 3.35.
...
<media id="reusedGlobalVar" refer="globalVar"
99
...
<link id="lIcon" xconnector="conEx#onBeginVarStart">
<bind role="var" component="reusedGlobalVar"
interface="service.interactivity"/>
</link>
...
</context>
Listagem 3.35 Novo relacionamento para a exibio do cone da chuteira (icon).
Vale a pena abrirmos aqui um parnteses para ver a definio do
elemento <connector> onBeginVarStart, especificado externamente, como
<causalConnector id="onBeginVarStart">
<compoundCondition operator="and">
<assessmentStatement comparator="eq">
<attributeAssessment role="var"
attributeType="nodeProperty" eventType="attribution"/>
<valueAssessment value="true"/>
</assessmentStatement>
</compoundCondition>
<simpleAction role="start"/>
</causalConnector>
Listagem 3.36 Elemento <connector> onBeginVarStart.
Na Listagem 3.36, a condio de disparo da relao composta. O
disparo ocorre se for iniciada a apresentao de uma interface correspondente
ao papel onBegin (no relacionamento da Listagem 3.35, quando for
apresentado o instante do vdeo da animao especificado para o
aparecimento do cone) e se a varivel correspondente ao papel var (no
relacionamento da Listagem 3.35, a varivel service.interactivity) tiver o
valor atribudo igual a true. Valores de variveis so testados a partir de
elementos <assessmentStatement>, conforme veremos no Captulo 10.
Quando a condio composta for satisfeita, ser disparada a ao que inicia a
apresentao do papel start (no relacionamento da Listagem 3.35,
associado ao cone icon).
Finalmente, note que, para a apresentao do cone, devem ser definidos
o elemento <region> para seu posicionamento e o elemento <descriptor>
100
ligando o elemento <region> ao elemento <media> que o representa. A
Listagem 3.37 apresenta o cdigo NCL correspondente a essa nova verso de
O Primeiro Joo.

<ncl id="settings"
<head>
<ruleBase>
comparator="eq"/>
</ruleBase>
<regionBase>
zIndex="1"/>
zIndex="2">
<region id="intReg" left="92.5%" top="91.7%"
</region>
</regionBase>
<descriptorBase>
explicitDur="5s"/>
explicitDur="6s"/>
explicitDur="15s"/>
<descriptor id="intDesc" region="intReg"/>
101
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>

<body>
</media>
</media>
<media id="intOn" src="../media/intOn.png"
descriptor="intDesc"/>
<media id="intOff" src="../media/intOff.png"
</bind>
</link>
<link id="lOn"
102
</bind>
</bind>
</link>
<link id="lOff"
</bind>
</bind>
</link>
</context>
</media>
<switch id="form">
</switchPort>
103
</switch>
</link>
</bind>
interface="bounds">
</bind>
</link>
interface="bounds">
</bind>
</link>
</context>
</bind>
</bind>
</link>
</link>
104
</link>
<bind role="stop" component="interactivity"/>
</link>
</body>
</ncl>
Listagem 3.37 O Primeiro Joo com controle de propagandas interativas.
A Figura 3.15 ilustra o momento da apresentao do cone de
interatividade e um outro momento em que a interatividade foi inibida, obtidos
durante a execuo da aplicao na implementao de referncia do
middleware Ginga-NCL.

Figura 3.15 Cenas da aplicao O Primeiro Joo com controle de interatividade.
3.11 Efeitos de Transio e Animao
Vamos agora introduzir um efeito de transio no aparecimento do
drible de vaivm do Garrincha (elemento <media> drible). O efeito de
transio uma caracterstica de apresentao e, portanto, pode ser definido
no elemento <descriptor> associado ao elemento <media> onde se quer a
transio.
Antes de associarmos transies ao elemento <descriptor>, devemos
criar uma base de transies para a aplicao NCL em questo. Isso feito
atravs do elemento <transitionBase>, tambm filho do elemento <head>.
Uma base de transies contm, como diz seu prprio nome, transies
105
especificadas pelo elemento <transition>. A Listagem 3.38 ilustra dois tipos
de transio que usaremos em nossa aplicao. A primeira transio,
identificada como trans1, especifica um desvanecimento de 2 segundos. A
segunda transio, identificada como trans2, especifica um efeito de
varredura de barra vertical durante 1 segundo.
<head>
...
<transitionBase>
<transition id="trans1" type="fade" dur="2s"/>
<transition id="trans2" type="barWipe" dur="1s"/>
</transitionBase>
...
</head>
Listagem 3.38 Elementos <transitionBase> e <transition>.
Agora podemos associar as transies ao elemento <descriptor>
associado ao vdeo drible, conforme ilustrado na Listagem 3.39.
<descriptor id="dribleDesc" region="frameReg" transIn="trans1"
transOut="trans2"/>
Listagem 3.39 Efeito de transio.
Pela Listagem 3.39, uma transio de desvanecimento de entrada do
vdeo drible e uma de varredura vertical ao final do vdeo foram definidas.
Ainda nessa mesma verso da aplicao, vamos acrescentar um efeito de
animao foto do marcador cado no cho (elemento <media> photo) e
tambm introduzir um efeito de transparncia a essa foto. A Listagem 3.40
ilustra como o descritor associado foto pode ser alterado para produzir o
efeito de transparncia (uma transparncia de 60% foi definida).
<descriptor id="photoDesc" region="frameReg" explicitDur="5s">
</descriptor>
Listagem 3.40 Efeito de transparncia.
O efeito de animao que queremos bem simples. Vamos apenas fazer
com que a foto seja apresentada e depois se desloque vertical e
continuamente. Para tanto, teremos de mexer no relacionamento que define o
incio da apresentao da foto. Iremos acrescentar ao relacionamento uma
outra ao, uma ao de atribuio de valores, que ir modificar o valor do
atributo top do elemento continuamente, at um certo valor final. A Figura
106
3.16 ilustra a nova viso estrutural, onde, por clareza, os contextos de
interatividade e de propaganda so apresentados de forma resumida.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
onEnd
Stop
Contexto de
Propaganda
Contexto de
Interatividade
Start
Set
position
Stop

Figura 3.16 Viso estrutural de O Primeiro Joo, com efeito de animao e transio.
Como vamos modificar o atributo top, ele precisa ser explicitamente
declarado no elemento <media> photo, conforme ilustra a Listagem 3.41,
que tambm traz a definio do novo relacionamento.
<body>
...
descriptor="photoDesc">
<property name="top"/>
</media>
...
<link id="lPhoto"
xconnector="conEx#onBeginStartSet_var_delay_duration">
<bind role="set" component="photo" interface="top">
<bindParam name="var" value="290"/>
<bindParam name="duration" value="3s"/>
</bind>
</link>
...
<body>
Listagem 3.41 Novo relacionamento com animao.
Na Listagem 3.41, note o novo papel introduzido (papel set). Ele
estabelece que, depois de transcorrido 1 segundo do incio da exibio da foto
107
(parmetro delay), o seu valor de topo deve mudar para 290 pixels
continuamente, em um intervalo de 3 segundos (parmetro duration). O
efeito que se ter o da foto se deslocando verticalmente.
na Listagem 3.42.

<ncl id="animationExample"
<head>
<ruleBase>
comparator="eq"/>
</ruleBase>
<transitionBase>
</transitionBase>
<regionBase>
zIndex="1"/>
<region id="intReg" left="92.5%" top="91.7%" width="5.07%"
</region>
</regionBase>
<descriptorBase>
explicitDur="5s">
</descriptor>
108
<descriptor id="dribleDesc" region="frameReg"
transIn="trans1" transOut="trans2"/>
explicitDur="15s"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>

<body>
</media>
</media>
</media>
109
</bind>
</link>
<bindParam name="varSet" value="false"/>
</bind>
</link>
<link id="lOn"
</bind>
</bind>
</link>
<link id="lOff"
</bind>
</bind>
</link>
</context>
</media>
110
<switch id="form">
</switchPort>
type="text/html" descriptor="formDesc"/>
</switch>
</link>
</bind>
interface="bounds">
</bind>
</link>
interface="bounds">
</bind>
</link>
</context>
111
</bind>
</bind>
</link>
</link>
<link id="lPhoto"
</bind>
</link>
</link>
</body>
</ncl>
Listagem 3.42 O Primeiro Joo com efeitos de animao e transio.
A Figura 3. 17 ilustra o efeito de transio de sada, do tipo bar wipe,
no vdeo do canto superior esquerdo, que se sobrepe ao vdeo da animao.

Figura 3.17 Cenas da aplicao O Primeiro Joo com efeitos de transio.
112
3.12 Navegao por Teclas
A prxima funcionalidade que agregaremos em nossa aplicao O
Primeiro Joo a opo de escolher a msica de fundo, ou seja, a
substituio do chorinho pelo rock, ou um techno, ou um estilo
cartoon.
A escolha do ritmo se dar por meio de navegao sobre cones
(imagens) que os representam. A navegao se dar por meio das teclas
CURSOR_RIGHT e CURSOR_LEFT do controle remoto. O cone em foco,
se selecionado pela tecla ENTER, efetuar a substituio da msica.
Como os cones estaro sempre visveis, para no sobrep-los ao vdeo
da animao vamos redimensionar a regio que define onde esse vdeo ser
apresentado. Teremos tambm de definir as regies onde os cones sero
exibidos. Assim, o novo elemento <regionBase> pode ser definido conforme
ilustrado na Listagem 3.43. Devemos notar, pela nova definio, que todas as
regies so definidas com relao regio da figura de fundo e que os cones
correspondentes aos vrios ritmos da msica de fundo sero apresentados na
parte mais inferior da tela.
<regionBase>
<region id="backgroundReg" width="100%" height="100%" zIndex="1">
<region id="screenReg" width="100%" height="88%" zIndex="2"/>
<region id="formReg" left="56.25%" top="8.33%" width="38.75%"
<region id="chorinhoReg" left="2.5%" top="91.7%"
<region id="rockReg" left="25%" top="91.7%" width="11.7%"
<region id="technoReg" left="47.5%" top="91.7%" width="11.7%"
<region id="cartoonReg" left="70%" top="91.7%" width="11.7%"
</region>
</regionBase>
Listagem 3.43 Base de regies da nova verso.
113
Como prximo passo, temos de definir o novo conjunto de descritores.
Descritores so especificados para cada um dos quatro cones, a serem
apresentados para a seleo do ritmo.
Na definio de cada descritor, devemos informar seu ndice para a
navegao pelas teclas do controle remoto. Isso feito pelo atributo
focusIndex do elemento <descriptor>. Devemos tambm informar os
prximos elementos a receberem o foco quando navegarmos por meio das
teclas CURSOR_RIGHT e CURSOR_LEFT, indicando os prximos valores
de focusIndex que devero ser objeto de foco. Isso ser feito por meio dos
atributos moveRight e moveLeft, respectivamente. Assim, tomando como
exemplo o elemento <descriptor> chorinhoDesc da Listagem 3.44, vemos
que seu ndice para foco 2 e que, quando o elemento <media> que o
referencia est com o foco e a tecla CURSOR_RIGHT do controle remoto
pressionada, o foco movido para o elemento <media> que referencia o
elemento <descriptor> com o atributo focusIndex igual a 3. Analogamente,
quando o elemento <media> que referencia o elemento <descriptor>
chorinhoDesc est com o foco e a tecla CURSOR_LEFT do controle
remoto pressionada, o foco movido para o elemento <media> que
referencia o elemento <descriptor> com o atributo focusIndex igual a 5. A
Listagem 3.44 ilustra a definio dos novos descritores. Note que a
navegao pelos cones que representam os ritmos circular.
<descriptorBase>

<descriptor id="chorinhoDesc" region="chorinhoReg" focusIndex="2"
moveRight="3" moveLeft="5"/>
<descriptor id="rockDesc" region="rockReg" focusIndex="3"
<descriptor id="technoDesc" region="technoReg" focusIndex="4"
<descriptor id="cartoonDesc" region="cartoonReg" focusIndex="5"
</descriptorBase>
Listagem 3.44 Novos descritores com a definio de atributos para navegao por teclas.
O leitor j deve ter percebido que, alm dos quatro cones mencionados,
tambm teremos de acrescentar aplicao mais trs objetos de udio, uma
vez que o udio do chorinho j estava presente na verso anterior da
aplicao.
Vamos, ento, estabelecer o seguinte cenrio para nossa aplicao.
Como anteriormente, o udio chorinho comear 5 segundos aps o incio da
aplicao. Juntamente com o incio do choro, vamos tambm iniciar a
apresentao dos cones (imagens) para choro, rock, techno e cartoon. Para
114

tanto, vamos colocar o elemento <media> choro do tipo udio e os
elementos <media> imgChorinho, imgRock, imgTechno e
imgCartoon, do tipo imagem, dentro (como filhos) de um elemento
<context> menu. Vamos tambm colocar cinco elementos <port>, cada um
mapeando para cada um dos novos elementos <media> definidos. Como
realizar uma ao start em um contexto sem especificar a porta significa
que todas as portas devem receber a ao, bastar termos um relacionamento
especificando o start do elemento <context> menu para que todos os
cones sejam apresentados e o chorinho iniciado, como queramos.
Continuando com nosso cenrio, vamos estabelecer que, em qualquer
instante em que um dos cones for acionado, com exceo do cone do
chorinho, o chorinho ter seu volume colocado em zero (mudo), o ritmo
correspondente ao cone selecionado iniciar sua apresentao e os demais
ritmos sero abruptamente terminados. A qualquer momento que o cone do
chorinho for selecionado, os demais ritmos cessaro e o udio do choro ser
restabelecido em seu valor inicial.
Para conseguirmos o efeito descrito no pargrafo anterior mais
facilmente, vamos reunir os trs udios (elementos <media> rock, techno
e cartoon) em um elemento <switch>, identificado como musics, e
coloc-lo tambm como filho do elemento <context> menu. O elemento
<switch> ter uma porta (elemento <switchPort>) mapeada para os trs
elementos de mdia representando os udios, que sero escolhidos conforme o
valor do atributo focusIndex do elemento <media> representando o cone
associado ao ritmo que foi selecionado pela tecla ENTER do controle remoto.
Para tanto, a varivel global service.currentFocus (uma propriedade do n
settings por ns j discutido) ser consultada. Essa varivel mantida pelo
sistema exibidor da aplicao NCL, contendo sempre o valor do atributo
focusIndex corrente.
Quando quisermos parar todos os elementos filhos do elemento
<context> menu, bastar realizar uma ao stop sobre o contexto, sem
especificar nenhuma porta. Na nova verso da aplicao, vamos querer que
isso acontea quando o vdeo da animao atingir o ponto em que so
apresentados os crditos dos autores (elemento <area> segCred). Vamos
tambm aproveitar para trocar o trmino do contexto de interatividade para
esse ponto do vdeo da animao. A Listagem 3.45 ilustra a definio do
elemento <link> que permite esse procedimento.
115
<link xconnector="conEx#onEndStop">
<bind role="onEnd" component="animation" interface="segCred"/>
<bind role="stop" component="menu"/>
</link>
Listagem 3.45 Finalizao de todos os elementos em exibio do contexto menu.
Teremos, ento, a viso estrutural ilustrada na Figura 3.18 para essa
nova verso de O Primeiro Joo.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Stop
Contexto de
Propaganda
Contexto de
Interatividade
Start
Set
position
chorinho
rock
techno cartoon
Set vol.
onSelection
onEnd
Stop
Stop
Set vol.
onSelection
currentFocus = ?
Start
Stop
onBegin

Figura 3.18 Viso estrutural de O Primeiro Joo com navegao por teclas.
Note pela Figura 3.18 que a seleo de qualquer um dos trs cones,
imgRock, imgTechno ou imgCartoon, coloca o volume do chorinho em
zero, para a exibio dos demais udios e inicia a apresentao do udio
correspondente ao foco corrente, ou seja, ao udio associado ao cone
selecionado.
Para definir o elemento <switch> menu, novas regras de seleo
devem ser definidas no elemento <ruleBase> que, em sua nova verso, segue
a especificao ilustrada na Listagem 3.46. Note que as novas regras
introduzidas dizem respeito varivel service.currentFocus, que ter seu
valor testado contra o valor do atributo focusIndex de cada um dos cones
associados aos elementos <media> representando os vrios ritmos. A regra
considerada satisfeita se houver igualdade entre os valores.
116
<ruleBase>
<rule id="en" var="system.language" value="en" comparator="eq"/>
comparator="eq"/>
<rule id="rRock" var="service.currentFocus" value="3"
comparator="eq"/>
<rule id="rTechno" var="service.currentFocus" value="4"
comparator="eq"/>
<rule id="rCartoon" var="service.currentFocus" value="5"
comparator="eq"/>
</ruleBase>
Listagem 3.46 Redefinio do elemento <ruleBase> e seus novos elementos filhos.
Agora podemos definir o elemento <context> menu, incluindo entre
seus filhos o elemento <switch> musics para a escolha dos ritmos e os
demais elementos discutidos nesta seo, conforme ilustra a Listagem 3.47.
<context id="menu">
<port id="pChoro" component="choro"/>
<port id="pChorinho" component="imgChorinho"/>
<port id="pRock" component="imgRock"/>
<port id="pTechno" component="imgTechno"/>
<port id="pCartoon" component="imgCartoon"/>
<media id="imgChorinho" src="../media/chorinho.png"
descriptor="chorinhoDesc"/>
<media id="imgRock" src="../media/rock.png"
descriptor="rockDesc"/>
<media id="imgTechno" src="../media/techno.png"
descriptor="technoDesc"/>
<media id="imgCartoon" src="../media/cartoon.png"
descriptor="cartoonDesc"/>
<media id="choro" src="../media/choro.mp3" descriptor="audioDesc">
<property name="soundLevel" value="1"/>
</media>
<switch id="musics">
<bindRule constituent="rock" rule="rRock"/>
<bindRule constituent="techno" rule="rTechno"/>
<bindRule constituent="cartoon" rule="rCartoon"/>
<media id="rock" src="../media/rock.mp3"/>
<media id="techno" src="../media/techno.mp3"/>
<media id="cartoon" src="../media/cartoon.mp3"/>
</switch>
<link id="lChoro" xconnector="conEx#onSelectionSet_varStop">
117
<bind role="onSelection" component="imgChorinho"/>
<bind role="set" component="choro" interface="soundLevel">
</bind>
<bind role="stop" component="musics"/>
</link>
<link id="lOthers"
xconnector="conEx#onSelection_orSet_varStopStart">
<bind role="onSelection" component="imgRock"/>
<bind role="onSelection" component="imgTechno"/>
<bind role="onSelection" component="imgCartoon"/>
</bind>
<bind role="start" component="musics"/>
</link>
</context>
Listagem 3.47 Elemento <context> menu.
Note, na Listagem 3.47, a definio das portas para todos os cones que
representam os diferentes ritmos e para o udio do chorinho, conforme
discutimos anteriormente. Note tambm a definio do elemento <switch>
musics e, ainda, a definio dos elementos <link>. O primeiro
relacionamento (lChoro) especifica que, ao ser selecionada (condio
onSelection) a imagem correspondente ao cone do chorinho, o som do
udio do choro deve ser colocado em seu volume original (ao set
colocando o valor de soundLevel em 1), e todos os outros ritmos devem ser
encerrados (ao de stop no elemento <switch> musics). O segundo
relacionamento (lOthers) especifica que, ao ser selecionada (condio
onSelection) qualquer das imagens correspondentes aos outros ritmos (rock,
techno e cartoon), o volume do udio do choro deve ser abaixado totalmente
(ao set colocando o valor de soundLevel em 0), qualquer outro ritmo
que estiver sendo tocado deve parar (ao de stop no elemento <switch>
musics), e o udio correspondente ao cone selecionado (cujo valor de
focusIndex ento atribudo ao currentFocus) deve ser iniciado (ao de
start no elemento <switch> musics, com a seleo do componente
segundo o valor da varivel service.currentFocus).
Finalmente, podemos realizar as duas ltimas alteraes na verso
anterior da aplicao. A primeira, alterando o elemento <link> lMusic, para
que ele agora inicie a apresentao do elemento <context> menu a partir
dos 5 segundos do incio do vdeo da animao, isto , inicie a apresentao
118
do chorinho e dos cones correspondentes a todos os ritmos, conforme ilustra
a Listagem 3.48.
</bind>
<bind role="start" component="menu">
</bind>
</link>
Listagem 3.48 Redefinio do elemento <link> lMusic.
A segunda alterao bem sutil. Quando da apresentao do formulrio
para compra da chuteira, devemos obrigatoriamente colocar o formulrio com
o foco, independentemente de onde o foco esteja (em relao aos cones
representando os diversos ritmos). Essa ao tornar possvel o
preenchimento do formulrio. Caso no faamos assim, o foco ficar
circulando entre os cones e nunca ser dado ao formulrio. Note que, quando
o formulrio ganhar o foco, ele s ser novamente passado aos cones no final
de sua apresentao. A Listagem 3.49 ilustra o elemento <link> responsvel
por determinar o foco no formulrio, assim que se inicia sua apresentao.
Note que, para estabelecer o foco, basta colocar a varivel global
service.currentFocus com o valor do atributo focusIndex do formulrio (no
caso, o valor 1).
<link id="lFormFocus" xconnector="conEx#onBeginSet_var">
<bind role="onBegin" component="form"/>
<bind role="set" component="reusedGlobalVar"
interface="service.currentFocus">
</bind>
</link>
Listagem 3.49 Passando o foco ao formulrio assim que inicia sua apresentao.
na Listagem 3.50.

<ncl id="menuEx" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
119
<ruleBase>
comparator="eq"/>
comparator="eq"/>
comparator="eq"/>
comparator="eq"/>
comparator="eq"/>
</ruleBase>
<transitionBase>
</transitionBase>
<regionBase>
zIndex="1">
zIndex="2"/>
<region id="intReg" left="92.5%" top="91.7%"
<region id="rockReg" left="25%" top="91.7%"
<region id="technoReg" left="47.5%" top="91.7%"
<region id="cartoonReg" left="70%" top="91.7%"
</region>
</regionBase>

<descriptorBase>
120
explicitDur="5s">
</descriptor>
<descriptor id="dribleDesc" region="frameReg"
transIn="trans1" transOut="trans2"/>
explicitDur="6s"/>
explicitDur="15s"/>
<descriptor id="chorinhoDesc" region="chorinhoReg"
focusIndex="2" moveRight="3" moveLeft="5"/>
<descriptor id="technoDesc" region="technoReg"
<descriptor id="cartoonDesc" region="cartoonReg"
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>
<body>
<area id="segCred" end="64s"/>
</media>
121
</media>
<property name="service.currentFocus"/>
</media>
</bind>
</link>
<link id="lOn"
</bind>
</bind>
</link>
<link id="lOff"
</bind>
</bind>
</link>
122
</context>
</media>
<switch id="form">
</switchPort>
</switch>
</link>
</bind>
interface="bounds">
</bind>
</link>
123
<link id="lFormFocus" xconnector="conEx#onBeginSet">
</bind>
</link>
interface="bounds">
</bind>
</link>
</context>
<context id="menu">
descriptor="audioDesc">
</media>
</switch>
<bind role="set" component="choro"
124
interface="soundLevel">
</bind>
</link>
<link id="lOthers"
<bind role="set" component="choro"
interface="soundLevel">
</bind>
</link>
</context>
</bind>
</bind>
</link>
</link>
<link id="lPhoto"
</bind>
</link>
125
<bind role="onEnd" component="animation"
interface="segCred"/>
</link>
</link>
</body>
</ncl>
Listagem 3.50 O Primeiro Joo com navegao no menu por teclas.
A Figura 3.19 ilustra a navegao por teclas na implementao de
referncia do middleware Ginga-NCL. Na figura esquerda, o foco est sob
o cone de seleo do choro. J na figura direita, o foco se deslocou para o
cone que, se selecionado, troca a msica para techno.

Figura 3.19 Cenas da aplicao O Primeiro Joo com navegao no menu por teclas.
3.13 Acrescentando um Objeto NCLua
A ltima funcionalidade que agregaremos ao nosso exemplo ser um n
com cdigo Lua, bem simples. Nosso objetivo implementar um contador que
armazenar quantas vezes o usurio de nosso exemplo O Primeiro Joo
trocou de ritmo musical. Em outras palavras, cada vez que um novo ritmo
escolhido, o contador incrementado. No final da apresentao do vdeo da
animao, o resultado ser apresentado na tela: Nmero de vezes que voc
trocou de ritmo: x.
Para realizar essa nova computao, vamos criar um objeto NCLua
(elemento <media> do tipo application/x-ncl-NCLua), que identificaremos
126
por changes, contendo um script Lua que, ao ser iniciado, colocar sua
varivel interna counter com o valor 0. Vamos tambm definir uma
propriedade para esse objeto de mdia, denominada add (name=add) e
uma ncora de contedo identificada como print (id=print), definindo
uma interface identificada como fim (label=fim). Cada vez que um valor
numrico for atribudo propriedade add, por meio de um elemento <link>,
o objeto NCLua dever somar esse valor varivel counter. Se o objeto
NCLua tiver sua interface print acionada, ele dever imprimir na tela o
valor da varivel conter, compondo a frase Nmero de vezes que voc
trocou de ritmo: valor da varivel counter.
A especificao do objeto de mdia NCLua dada pelo elemento
<media> changes na Listagem 3.51, e tem seu contedo armazenado no
arquivo counter.lua. O leitor deve notar que o tipo do objeto (atributo type)
no precisou ser declarado, porque o formatador NCL vai infer-lo a partir da
extenso .lua do arquivo imposto ao atributo source do elemento.
Na Listagem 3.51, ns definimos o elemento <media> changes como
filho do elemento <context> menu, onde esto tambm todos os cones para
seleo dos ritmos. A partir de agora, quando o elemento <context> menu
for iniciado, no s todos os cones correspondentes aos ritmos sero exibidos
juntamente com o udio do chorinho, como tambm o objeto NCLua ser
iniciado, conforme especificado por todas as portas do elemento <contex>
menu que esto mapeadas para ncoras de ns filhos do contexto.
<context id="menu">
<port id="pNCLua" component="changes"/>
...
<media id="changes" src="../script/counter.lua"
descriptor="changesDesc">
<area id="print" label="fim"/>
<property name="add"/>
</media>
...
</context>
Listagem 3.51 Objeto de mdia NCLua.
127
O resultado da computao do script ser apresentado em uma regio da tela
referenciada no elemento <descriptor> e definida no elemento <region>,
conforme ilustra a Listagem 3.52.
<regionBase>
...
<region id="changesReg" left="0%" top="90%" width="100%"
</region>
</regionBase>
<descriptorBase>
...
<descriptor id="changesDesc" region="changesReg"/>
</descriptorBase>
Listagem 3.52 Definio da regio de apresentao do objeto NCLua.
Para incrementarmos a varivel counter do script Lua, vamos, a cada
vez que um ritmo trocado, atribuir o valor 1 propriedade add do
objeto NCLua. Faremos isso acrescentando um elemento <bind> ao elo de
seleo dos ritmos rock, techno e cartoon, e outro ao elo de seleo do
cone chorinho. Esses elos, pertencentes ao elemento <context> menu,
ficam como ilustrado na Listagem 3.53.
<context id="menu">
...
</bind>
<bind role="set" component="changes" interface="add">
</bind>
</link>
<link id="lOthers"
128
</bind>
</bind>
</link>
</context>
Listagem 3.53 Elos para incremento da varivel counter.
Como j mencionamos, o objeto NCLua ser iniciado quando o
elemento <context> menu for iniciado. Seu trmino se d pelo trmino do
mesmo contexto, como anteriormente, mas que agora tambm inclui o objeto
NCLua. Para chamar o tratador do objeto NCLua que imprime o resultado,
vamos incluir o objeto animation dentro do contexto menu, com o nome
newAnimation, reusando toda a especificao definida anteriormente e
incluindo uma nova ncora (segLua), cujo trmino ocorre 3 segundo antes
de se iniciarem os crditos (61s). Vamos usar essa nova interface para
acionar a impresso do resultado, com a introduo do novo elo apresentado
na Listagem 3.54.
<media id="newAnimation" refer="animation"
<area id="segLua" end="61s"/>
</media>

...

<link xconnector="conEx#onEndStart">
<bind role="onEnd" component="newAnimation" interface="segLua"/>
<bind role="start" component="changes" interface="print"/>
</link>
Listagem 3.54 Elo para exibio do resultado final das mudanas de ritmo.
A Figura 3.20 apresenta a viso estrutural dessa verso final do
exemplo O Primeiro Joo.
129
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Stop
Contexto de
Propaganda
Contexto de
Interatividade
Start
Set
position
chorinho
rock
techno cartoon
Set vol.
onSelection
onEnd
Stop
Stop
Set vol.
onSelection
Start
Stop
onBegin
Set
counter
Set
counter
currentFocus = ?
Start
onBegin

Figura 3.20 Viso estrutural da verso final do exemplo O Primeiro Joo.
Vamos agora ver o contedo do objeto NCLua. Ao iniciarmos um objeto
com cdigo Lua, no importa por qual de suas ncoras, ele primeiro executa
uma rotina de iniciao, quando so cadastradas todas as funes tratadoras
de eventos disparados interna ou externamente ao objeto. No caso de nosso
exemplo, queremos cadastrar a funo que tratar eventos que mudam o valor
da propriedade add do elemento <media> changes, e a funo que tratar
o evento que imprime o resultado, chamada a partir do elemento <area
id=print ...\> do mesmo elemento <media> changes. A Listagem 3.55
exibe o script Lua de nosso exemplo.
Na Listagem 3.55, a linha 1 inicia o contador (varivel local counter)
em zero. A linha 2 define as variveis cujos valores contero a largura e a
altura do canvas onde ser apresentado o resultado. Esses valores so obtidos
pela funo canvas:attrSize(), que os obtm do elemento <descriptor>
do objeto NCLua: no nosso caso (veja a Listagem 3.52) 100% e 10% da
tela de exibio, respectivamente. Da linha 3 linha 14, temos a definio da
funo que tratar do evento de atribuio de valores propriedade add do
objeto NCLua. A linha 29 registra essa funo, ou seja, deixa o objeto pronto
para receber eventos que dispararo a funo tratadora. Da linha 15 linha
28, temos a definio da funo que tratar do evento de apresentao da
interface print do objeto NCLua. A linha 30 registra essa funo. Todo o
procedimento descrito neste pargrafo executado quando o objeto NCLua
iniciado (instanciado) pela ao start sobre o elemento <context> menu.
130
1 local counter = 0
2 local dx, dy = canvas:attrSize() -- dimensoes do canvas

3 function handler1 (evt)
4 if evt.class=='ncl' and evt.type=='attribution' and
evt.action=='start' and evt.name=='add' then
5 counter = counter + evt.value

6 event.post {
7 class = 'ncl',
8 type = 'attribution',
9 name = 'add',
10 action = 'stop',
11 value = counter,
12 }
13 end
14 end

15 function handler2 (evt)
16 canvas:attrColor ('black')
17 canvas:drawRect('fill',0,0,dx,dy)
18 canvas:attrColor ('yellow')
19 canvas:attrFont ('vera', 24, 'bold')
20 canvas:drawText (10,10, 'O nmero de vezes que voc trocou
de ritmo foi: '..counter)
21 canvas:flush()

22 event.post {
23 class = 'ncl',
24 type = 'presentation',
25 label = 'fim',
26 action = 'stop',
27 }
28 end

29 event.register(handler1)
30 event.register(handler2,'ncl','presentation','fim','start')
Listagem 3.55 Script Lua do elemento <media> changes.
Como indicado na linha 4 da Listagem 3.55, a funo tratadora de
evento chamada toda vez que acontece o incio (note bem que o incio, pois
retornaremos a esse ponto logo frente neste texto) de atribuio ao elemento
131
<propriedade> cujo atributo name=add, e essa ao de atribuio parte de
um elo do documento NCL (evt.class= = 'ncl').
As linhas 5 indica que o valor da varivel counter deve ser adicionado
do novo valor atribudo. Como, no nosso caso, a atribuio sempre 1
(veja a Listagem 3.53), o valor da varivel counter incrementado.
A ao de start sobre a propriedade add, proveniente de um elo do
documento NCL, apenas inicia a atribuio de um valor a essa propriedade.
Independentemente do valor que for atribudo, o final da atribuio deve ser
sinalizada pelo objeto NCLua, to logo ele termine a realizao das tarefas
chamadas pelo nicio do evento de atribuio. Isso realizado pelas linhas 6 a
12, na Listagem 3.55. Essas linhas comandam a gerao de um evento
(event.post) de fim de atribuio na propriedade add, deixando como
valor final dessa propriedade o valor da varivel local counter. Note, assim,
que a atribuio comea atribuindo o valor 1 (que pode ser visto como
parmetro de entrada para a funo tratadora) e termina com o valor da
varivel counter (que pode ser visto como parmetro de sada da funo
tratadora).
As linhas 15 a 28 indicam o que acontece quando a interface print tem
sua apresentao iniciada. Nesse caso, queremos imprimir na tela o valor
final da varivel counter. Para tanto, as linhas 16 e 17 comandam o
preenchimento de todo o canvas com a cor preta. As linhas 18 e 19
estabelecem a cor e a fonte para o texto da mensagem. A linha 20 comanda a
impresso da mensagem Nmero de vezes que voc trocou de ritmo:,
concatenado com o valor da varivel counter. A linha 21 comanda a
atualizao (refrescamento) do canvas.
De forma anloga ao evento de atribuio sobre a propriedade add,
ao de start sobre a interface print, proveniente de um elo do documento
NCL, apenas inicia a apresentao. O final da apresentao deve ser
sinalizado pelo objeto NCLua, to logo ele termine a realizao da tarefa.
Isso realizado pelas linhas 22 a 27, na Listagem 3.55. Essas linhas
comandam a gerao de um evento (event.post) de fim de apresentao da
ncora print.
Note como os tratadores foram registrados nas linhas 29 e 30 da
Listagem 3.55. O primeiro tratador deve receber qualquer evento. A filtragem
feita no seu cdigo (linha 4 na listagem). J para o segundo tratador, a
filtragem feita pelo exibidor Lua antes de chamar o tratador, como mostra a
linha 30 da listagem.
na Listagem 3.56.
132

<ncl id="nclua" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<ruleBase>
comparator="eq"/>
comparator="eq"/>
comparator="eq"/>
comparator="eq"/>
comparator="eq"/>
</ruleBase>
<transitionBase>
</transitionBase>
<regionBase>
zIndex="1">
zIndex="2"/>
<region id="rockReg" left="25%" top="91.7%" width="11.7%"
<region id="technoReg" left="47.5%" top="91.7%"
<region id="cartoonReg" left="70%" top="91.7%" width="11.7%"
<region id="changesReg" left="0%" top="90%" width="100%"
133
</region>
</regionBase>
<descriptorBase>
<descriptor id="photoDesc" region="frameReg" explicitDur="5s">
</descriptor>
<descriptor id="dribleDesc" region="frameReg" transIn="trans1"
transOut="trans2"/>
explicitDur="15s"/>
<descriptor id="chorinhoDesc" region="chorinhoReg"
<descriptor id="technoDesc" region="technoReg" focusIndex="4"
<descriptor id="cartoonDesc" region="cartoonReg"
<descriptor id="changesDesc" region="changesReg"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>

<body>
<area id="segCred" end="62s"/>
</media>
134
</media>
<property name="service.currentFocus"/>
</media>
</bind>
</link>
<link id="lOn"
</bind>
</bind>
</link>
<link id="lOff"
</bind>
135
</bind>
</link>
</context>
</media>
<switch id="form">
</switchPort>
</switch>
</link>
</bind>
136
interface="bounds">
</bind>
</link>
<link id="lFormFocus" xconnector="conEx#onBeginSet_var">
</bind>
</link>
interface="bounds">
</bind>
</link>
</context>
<context id="menu">
<port id="pNCLua" component="changes"/>
<media id="changes" src="../script/counter.lua"
descriptor="changesDesc">
<area id="print" label="fim"/>
<property name="add"/>
</media>
</media>
137
<media id="newAnimation" refer="animation"
<area id="segLua" end="61s"/>
</media>
</switch>
</bind>
</bind>
</link>
<link id="lOthers"
</bind>
</bind>
</link>
<link xconnector="conEx#onEndStart">
<bind role="onEnd" component="newAnimation"
interface="segLua"/>
<bind role="start" component="changes" interface="print"/>
</link>
</context>
138
</bind>
</bind>
</link>
</link>
<link id="lPhoto"
</bind>
</link>
interface="segCred"/>
</link>
</link>
</body>
</ncl>
Listagem 3.56 O Primeiro Joo com objeto NCLua.
A Figura 3.21 ilustra o uso de objetos NCLua na implementao de
referncia do middleware Ginga-NCL. Note a mensagem sobre quantas vezes
o ritmo foi trocado.
139

Figura 3.21 Cenas da aplicao O Primeiro Joo com objeto NCLua.
Bibliografia
aplicaes, Sistema Brasileiro de TV Digital Terrestre, NBR 15606-2.
W3C REC-xml-20060816 (2006). World Wide Web Consortium,
20060816.
W3C REC-xml-names-20060816 (2006). World Wide Web Consortium,
Namespaces in XML (2. ed.), W3C Recommendation xml-names
20060816.
NCM Core. Monografias em Cincia da Computao do
Departamento de Informtica, PUC-Rio, N. 18/05. Rio de Janeiro. Maio.
ISSN 0103-9741.
140
Captulo
4

Perfis
NCL
Todos os elementos da linguagem NCL so oferecidos no perfil
completo da linguagem. No entanto, a linguagem pode ser restrita a domnios
especficos (por exemplo, TV Digital), e, para esses domnios, perfis
especficos da linguagem podem ser definidos.
Este captulo introduz, de forma genrica, os vrios perfis e mdulos da
linguagem NCL. Toda a Parte II deste livro dedicada apresentao do
perfil EDTV (Enhanced Digital TV), definido para sistemas de TV digital.
1

1
Este captulo se baseia em Soares et al. (2006). O uso do material foi gentilmente cedido pelo
141
4.1 Introduo
A abordagem modular tem sido utilizada em vrias linguagens XML
[W3C REC-xml-20060816, 2006] recomendadas pelo W3C.
Mdulos so colees de elementos, atributos e valores de atributos
XML semanticamente relacionados que representam uma unidade de
funcionalidade. Os mdulos so definidos em conjuntos coerentes. Essa
coerncia expressa por meio da associao de um mesmo namespace [W3C
REC-xml-names-20060816, 2006] aos elementos desses mdulos.
Um perfil de linguagem uma combinao de mdulos. Os mdulos
so atmicos, isto , no podem ser subdivididos quando includos em um
perfil de linguagem. Alm disso, a especificao de um mdulo pode incluir
um conjunto de requisitos para integrao, com o qual os perfis de linguagem,
que incluem o mdulo, devem obrigatoriamente ser compatveis.
A NCL foi especificada de forma modular, permitindo a combinao de
seus mdulos em perfis de linguagem. Cada perfil pode agrupar um
subconjunto de mdulos NCL, permitindo a criao de linguagens voltadas
para as necessidades especficas dos usurios. Alm disso, os mdulos e
perfis NCL podem ser combinados com mdulos definidos em outras
linguagens, permitindo a incorporao de caractersticas da NCL naquelas
linguagens e vice-versa.
Normalmente, h um perfil de linguagem que incorpora quase todos os
mdulos associados a um nico namespace. Esse o caso do perfil
Linguagem NCL.
Um outro perfil da linguagem, com a mesma expressividade do perfil
Linguagem NCL, definido contendo as facilidades mnimas de reuso da
linguagem. Nesse perfil, denominado Raw, mdulos que definem elementos
apenas para facilitar o reuso so evitados. importante salientar que uma
aplicao que segue o perfil Linguagem NCL sempre poder ser convertida
para o perfil Raw. Usualmente, o formatador (player) para o perfil Raw
mais fcil de ser implementado do que aquele para o perfil Linguagem
NCL. Por outro lado, desenvolver aplicaes seguindo o perfil Raw pode
ser difcil e trabalhoso, ao contrrio do perfil Linguagem NCL que possui
entidades de mais elevado nvel de abstrao. Pode-se ento dizer que o perfil
Raw privilegia o desenvolvimento de formatadores NCL, enquanto o perfil
Linguagem NCL privilegia o desenvolvimento de aplicaes.
Outros perfis de linguagem podem ser especificados como subconjuntos
de um perfil maior ou incorporar uma combinao de mdulos associados a
diferentes namespaces. Exemplos do primeiro caso so os perfis TVD Bsico
(perfil BDTV) e TVD Avanado (perfil EDTV) da NCL [Soares et al.,
2006; ABNT NBR 15606-2, 2011; ITU-T H.761, 2011]. Esses perfis foram
142
definidos para ajustar a linguagem s caractersticas do ambiente de televiso
digital, com seus vrios dispositivos de apresentao: aparelho de televiso,
dispositivos mveis, dispositivos portteis etc.
O principal objetivo da conformidade com perfis de linguagem
aumentar a interoperabilidade. Os mdulos obrigatrios so definidos de
forma que qualquer documento, especificado em conformidade com um perfil
de linguagem, resulta em uma apresentao razovel quando apresentado em
um perfil distinto daquele para o qual foi especificado. O formatador de
documentos, suportando o conjunto de mdulos obrigatrios, ignoraria todos
os outros elementos e atributos desconhecidos.
4.2 Mdulos NCL
Como mencionamos na seo anterior, mdulos so colees de
elementos, atributos e valores de atributos XML semanticamente relacionados
que representam uma unidade de funcionalidade.
A verso NCL 3.0 dividida em 15 reas funcionais, que so
novamente divididas em mdulos. Das 15 reas funcionais, 14 so utilizadas
para definir os perfis TVD Avanado e TVD Bsico [Soares et al., 2006]. As
14 reas funcionais e seus mdulos correspondentes usados nos perfis para
TV digital so apresentados na Tabela 4.1.
Tabela 4.1 reas funcionais da NCL 3.0
reas
Funcionais
Mdulos Elementos
Structure Structure ncl
head
body
Layout Layout regionBase
region
Components Media media
Context context
Interfaces MediaContentAnchor area
CompositeNodeInterface port
PropertyAnchor property
SwitchInterface switchPort
mapping
Presentation
Specification
Descriptor descriptor
descriptorParam
143
descriptorBase
Linking Linking bind
bindParam
linkParam
link
Connectors
CausalConnectorFunctionality

(agrupa funcionalidades dos
mdulos:
ConnectorCausalExpression;
ConnectorCommonPart;
ConnectorAssessmentExpression;
CausalConnector)
causalConnector
connectorParam
simpleCondition
compoundCondition
simpleAction
compoundAction
assessmentStatement
attributeAssessment
valueAssessment
compoundStatement
ConnectorBase connectorBase
Presentation
Control
TestRule
ruleBase
rule
compositeRule
TestRuleUse bindRule
ContentControl
switch
defaultComponent
DescriptorControl
descriptorSwitch
defaultDescriptor
Timing Timing
Reuse
Import
importBase
importDocumentBase
importNCL
EntityReuse
ExtendedEntityReuse
Navigational
Key
KeyNavigation
Animation Animation
Transition
Effects
TransitionBase transitionBase
Transition transition
Meta-
Information
Metainformation
meta
metadata
Os identificadores de namespace XML para o conjunto completo de
mdulos, elementos e atributos NCL 3.0 esto contidos no seguinte
namespace: http://www.ncl.org.br/NCL3.0/.
144
Cada mdulo NCL possui um identificador nico a ele associado. Os
identificadores dos mdulos NCL 3.0 esto de acordo com aTabela 4.2.
Tabela 4.2 Identificadores dos mdulos de NCL 3.0
Mdulos Identificadores
Animation http://www.ncl.org.br/NCL3.0/Animation
CompositeNodeInterface http://www.ncl.org.br/NCL3.0/CompositeNodeInterface
CausalConnector http://www.ncl.org.br/NCL3.0/CausalConnector
CausalConnectorFunctionality http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality
ConnectorCausalExpression http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression
ConnectorAssessmentExpression http://www.ncl.org.br/NCL3.0/ConnectorAssessmentExpression
ConnectorBase http://www.ncl.org.br/NCL3.0/ConnectorBase
ConnectorCommonPart http://www.ncl.org.br/NCL3.0/ConnectorCommonPart
ContentControl http://www.ncl.org.br/NCL3.0/ContentControl
Context http://www.ncl.org.br/NCL3.0/Context
Descriptor http://www.ncl.org.br/NCL3.0/Descriptor
DescriptorControl http://www.ncl.org.br/NCL3.0/DescriptorControl
EntityReuse http://www.ncl.org.br/NCL3.0/EntityReuse
ExtendedEntityReuse http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse
Import http://www.ncl.org.br/NCL3.0/Import
Layout http://www.ncl.org.br/NCL3.0/Layout
Linking http://www.ncl.org.br/NCL3.0/Linking
Media http://www.ncl.org.br/NCL3.0/Media
MediaContentAnchor http://www.ncl.org.br/NCL3.0/MediaContentAnchor
KeyNavigation http://www.ncl.org.br/NCL3.0/KeyNavigation
PropertyAnchor http://www.ncl.org.br/NCL3.0/PropertyAnchor
Structure http://www.ncl.org.br/NCL3.0/Structure
SwitchInterface http://www.ncl.org.br/NCL3.0/SwitchInterface
TestRule http://www.ncl.org.br/NCL3.0/TestRule
TestRuleUse http://www.ncl.org.br/NCL3.0/TestRuleUse
Timing http://www.ncl.org.br/NCL3.0/Timing
TransitionBase http://www.ncl.org.br/NCL3.0/TransitionBase
Transition
http://www.ncl.org.br/NCL3.0/Transition
Metainformation
http://www.ncl.org.br/NCL3.0/MetaInformation
A Parte II deste livro dedicada a uma discusso detalhada de cada rea
funcional e de cada um de seus mdulos (seus elementos e atributos).
145
4.3 Perfis NCL
Como j mencionamos, cada perfil NCL pode agrupar um subconjunto
de mdulos NCL, permitindo a criao de linguagens de acordo com as
necessidades dos usurios.
Qualquer documento em conformidade com os perfis NCL deve
obrigatoriamente ter o elemento <ncl> como seu elemento-raiz.
O perfil NCL 3.0 completo, tambm chamado de perfil Linguagem NCL
3.0, o perfil completo da linguagem NCL 3.0. Ele compreende todos os
mdulos NCL e fornece todas as facilidades para a autoria declarativa de
documentos NCL.
O perfil NCL 3.0 Raw inclui os mdulos: Structure, Media, Context,
MediaContentAnchor, CompositeNodeInterface, PropertyAnchor, Linking,
CausalConnectorFunctionality, ConstraintConnectorFunctionality (no
discutido neste livro), ConnectorBase, EntityReuse, ExtendedEntityReuse e
Meta-Information.
Como j mencionamos, o perfil NCL 3.0 Raw to expressivo quanto
ao perfil completo da linguagem, mas sem os aucares sintticos definidos
para reso. Embora possa ser usado na autoria de documentos, tipicamente
um perfil projetado para sintaxe de transferncia. Por isso, no ser discutido
neste livro.
Os perfis definidos para uso em Sistemas de TV Digital [Soares et al.,
2006] so:
NCL 3.0 DTV Avanado EDTV
Inclui os mdulos: Structure, Layout, Media, Context,
MediaContentAnchor, CompositeNodeInterface, PropertyAnchor,
SwitchInterface, Descriptor, Linking, CausalConnectorFunctionality,
ConnectorBase, TestRule, TestRuleUse, ContentControl,
DescriptorControl, Timing, Import, EntityReuse, ExtendedEntityReuse,
KeyNavigation, Animation, TransitionBase, Transition e Meta-
Information.
NCL 3.0 DTV Bsico BDTV
Inclui os mdulos Structure, Layout, Media, Context,
MediaContentAnchor, CompositeNodeInterface, PropertyAnchor,
SwitchInterface, Descriptor, Linking, CausalConnectorFunctionality,
ConnectorBase, TestRule, TestRuleUse, ContentControl,
DescriptorControl, Timing, Import, EntityReuse, ExtendedEntityReuse e
KeyNavigation.
146
NCL 3.0 CausalConnector
Inclui os mdulos Structure, CausalConnectorFunctionality e
ConnectorBase.
Ambos os perfis EDTV e BDTV so usados para criao de aplicaes
declarativas. A nica diferena que no perfil BDTV os efeitos de transio e
animao no podem ser realizados de forma declarativa, e metainformaes
extras no podem ser includas.
O perfil NCL 3.0 CausalConnector permite a criao de conectores
causais simples, alguns deles por ns utilizados no Captulo 3.
Da mesma forma que seus mdulos, cada perfil possui um identificador
de namespace XML nico a ele associado. Os identificadores dos perfis NCL
3.0 para TV digital devem estar de acordo com a Tabela 4.3.
Tabela 4.3 Identificadores dos perfis NCL 3.0
Perfis Identificadores
EDTV http://www.ncl.org.br/NCL3.0/EDTVProfile
BDTV http://www.ncl.org.br/NCL3.0/BDTVProfile
CausalConnector http://www.ncl.org.br/NCL3.0/CausalConnectorProfile
A nova verso da linguagem NCL (verso 4.0) inclui a possibilidade de
manipulao de objetos 3D: como embutir objetos 3D em documentos NCL,
como exibir objetos 2D em superfcies 3D, como controlar o comportamento
de objetos 3D por meio de elementos <link> de NCL, como relacionar objetos
3D especificados em diferentes mundos, como relacionar objetos 2D e 3D etc.
Alm do suporte a objetos 3D, NCL 4.0 traz um melhor suporte ao uso de
mltiplos dispositivos, ao uso de dispositivos de entrada multimodal e a
aplicaes NCL cientes de contexto. Para tanto, o uso de meta informaes
tambm bastante aprimorado nessa nova verso da NCL.
4.3.1 Informaes sobre Verses da NCL
As seguintes instrues de processamento devem ser includas em um
documento NCL. Elas identificam documentos NCL que contenham apenas
os elementos definidos na verso NCL com a qual o documento est de
acordo.
147

O atributo id do elemento <ncl> pode receber qualquer cadeia de
caracteres como valor.
O nmero de verso de uma especificao NCL consiste em um nmero
principal e outro secundrio, separados por um ponto. Os nmeros so
representados como uma cadeia de caracteres formada por nmeros decimais,
na qual os zeros esquerda so suprimidos. O nmero de verso inicial do
padro para TV digital 3.0.
Novas verses da NCL podero ser publicadas, mas sempre de acordo
com a seguinte poltica de versionamento:
- se os receptores compatveis com verses mais antigas ainda puderem
receber um documento com base na especificao revisada, com relao a
correes de erro ou por motivos operacionais, a nova verso da NCL
deve obrigatoriamente ser publicada com o nmero secundrio atualizado;
- se os receptores compatveis com verses mais antigas no puderem
receber um documento baseado nas especificaes revisadas, o nmero
principal deve obrigatoriamente ser atualizado.
Uma verso especfica sempre definida sob o URI
http://www.ncl.org.br/NCL3.0/profileName, onde o nmero da verso
escrito imediatamente aps a sigla NCL, seguido de / e o nome do perfil.
Bibliografia
fixos e mveis linguagem de aplicao XML para codificao de
Soares, L.F.G. e Rodrigues, R.F. (2006) Nested Context Model 3.0 Part 8
NCL (Nested Context Language) Digital TV Profiles. Monografias
em Cincia da Computao do Departamento de Informtica, PUC-Rio,
N. 35/06. Rio de Janeiro. Outubro de 2006. ISSN 0103-9741.
<ncl id="qualquer string" xmlns="http://www.ncl.org.br/NCL3.0/profileName">
148
W3C REC-xml-20060816 (2006). World Wide Web Consortium,
20060816.
W3C REC-xml-names-20060816 (2006). World Wide Web Consortium,
Namespaces in XML (2. ed.), W3C Recommendation xml-names
20060816.

149
PARTE II

Linguagem NCL
Perfil EDTV

150
Captulo
5

Estrutura de
Aplicaes NCL
Neste captulo, descrevemos a estrutura bsica de aplicaes NCL.
1
Ao
final do captulo, voc ser capaz de localizar, no cdigo de uma aplicao
NCL, os elementos correspondentes s diferentes caractersticas do
documento, o que facilita a leitura e o entendimento de aplicaes.

1
Os elementos estruturais de documentos NCL e seus atributos so definidos no mdulo Structure
[ABNT, NBR 15606-2, 2007;ITU-T, H.761, 2011].
151
5.1 Introduo Estrutura do Cdigo NCL
Como descrito no captulo anterior, assim como qualquer arquivo XML, toda
aplicao NCL deve apresentar um cabealho XML como primeira linha do
arquivo:
<?xml version=1.0 encoding=ISO-8859-1?>
A estrutura bsica de uma aplicao NCL formada pelo elemento <ncl>, e
por seus elementos filhos <head> (cabealho) e <body> (corpo). O elemento
<ncl> possui os atributos id e xmlns, que identificam a aplicao e o perfil de
linguagem utilizado, respectivamente, conforme o seguinte formato:
<ncl id=qualquer_cadeia_de_caracteres
xmlns=http://www.ncl.org.br/NCL3.0/nomePerfil>
O atributo id de um elemento <ncl> obrigatrio e pode ter como valor
qualquer cadeia de caracteres que comece com uma letra ou sublinhado ("_")
e que contenha apenas letras, dgitos, "." e "_".
2

O nome do perfil, no caminho do URI do namespace, tambm obrigatrio e
deve ser EDTVProfile ou BDTVProfile, para indicar o perfil Enhanced
DTV ou Basic DTV, respectivamente.
3

O elemento <head> contm bases de elementos referenciados pelo corpo da
aplicao NCL (definido no elemento <body>), como as regies, os
descritores, as transies, os conectores e as regras. Tambm no elemento
<head> que se definem os documentos que podem ser reutilizados pelo
documento atual, bem como os metadados que auxiliam na descrio do
documento como um todo.
O elemento <body> contm os elementos que definem o contedo da
aplicao propriamente dita, tais como objetos de mdia, elos, contextos e
objetos switch. Os elementos, atributos e contedos que definem a estrutura
de documentos NCL no perfil EDTV esto sumarizados na Tabela 5.1.
4

2
Na verdade, o valor do atributo id de qualquer elemento da NCL deve seguir essa mesma regra de
formao.
3
Como veremos no Captulo 10, o perfil CausalConnectorProfile tambm usado, mas para a
definio de uma base de relaes e no na definio de uma aplicao.
4
Como de praxe, ao definir um elemento filho utilizaremos a seguinte conveno: uma
interrogao indica que o elemento opcional (pode no existir ou ter uma ocorrncia), um asterisco
indica que o elemento pode ocorrer zero ou mais vezes, e um sinal de mais indica que o elemento deve
ocorrer pelo menos uma vez, mas tambm pode ocorrer vrias vezes. Os atributos de um elemento que tm
sua declarao obrigatria so sublinhados, ao contrrio dos demais.
152
Tabela 5.1 Elementos, Atributos e Contedo (Elementos Filhos) que Definem a Estrutura
de Documentos NCL no Perfil EDTV
Elementos Atributos Contedo
ncl id, title,
xmlns
(head?, body?)
head (importedDocumentBase?, ruleBase?,
transitionBase?, regionBase*, descriptorBase?,
connectorBase?, meta*, metadata*)
body id (port | property | media | context | switch | link |
meta | metadata)*
recomendado que os elementos filhos do elemento <head> sejam declarados
na ordem indicada na tabela e ilustrada pela Listagem 5.1. J os elementos do
<body> podem ser definidos em qualquer ordem.
<head>
<importedDocumentBase>

</importedDocumentBase>
<ruleBase>

</ruleBase>
<transitionBase>

</transitionBase>
<regionBase >

</regionBase>
<descriptorBase>

</descriptorBase>
<connectorBase>

</connectorBase>
<meta/> 
<metadata>

</metadata>
</head>
Listagem 5.1 Estrutura do elemento <head>, indicando a ordem recomendada para seus
elementos filhos numa aplicao NCL.
153
Os elementos filhos dos elementos <head> e <body> so definidos em outros
mdulos e apresentados em diferentes captulos deste livro, conforme indicado
na Tabela 5.2. Os mdulos so indicados aqui para facilitar a consulta a
outros documentos de especificao da NCL (p. ex., ABNT, NBR, 15606-2,
2011 e ITU-T, H.761, 2011).
Tabela 5.2 Mdulos que Definem os Elementos da NCL no Perfil EDTV, Filhos dos
Elementos <head> e <body>, e os Respectivos Captulos que os Descrevem
Pai
Elemento
(Lista parcial)
Mdulo
Captulo
ou seo
head importedDocumentBase Import 13
ruleBase TestRule 11.1
transitionBase TransitionBase 7.3
regionBase
region
Layout 6
descriptorBase
descriptor
Descriptor 7
descriptorSwitch DescriptorControl 11.3
connectorBase ConnectorBase (e outros) 10
meta
metadata
Metainformation 12
body port CompositeNodeInterface 8.3
media Media 8.1
area MediaContentAnchor 9.1
property PropertyAnchor 9.2
context Context 8.2
switch ContentControl 11.2
switchPort SwitchInterface 11.2
link Linking 10
154
Bibliografia
ABNT NBR 15606-2 2011. Associao Brasileira de Normas Tcnicas,
Televiso digital terrestre Codificao de dados e especificaes de
[ITU-T H.761 2011. Nested Context Language (NCL) and Ginga-NCL for
IPTV. ITU-T Rec. H.761. Genebra.

155
Captulo
6

Leiaute da
Apresentao:
Regies
Neste captulo, descrevemos os elementos e atributos para definio de
regies de apresentao em classes de dispositivos de exibio.
1
Ao final deste
captulo, voc ser capaz de definir onde os objetos de mdia de uma
aplicao NCL podem ser inicialmente apresentados.

1
Regies e seus atributos so definidos no mdulo Layout [ABNT, NBR, 15606-2, 2011; ITU-T,
H.761, 2011].
156

6.1 Introduo
A NCL permite definir onde cada objeto de mdia ser apresentado, isto ,
em que classe de dispositivos e em qual regio de apresentao de cada classe
de dispositivos.
As classes de dispositivos e suas regies podem ser definidas por meio de
propriedades dos objetos de mdia (veja Captulo 9), por meio de elementos
descritores (veja Captulo 7), ou por meio de elementos <regionBase> e
<region>, respectivamente, discutidos neste captulo.
Para cada classe de dispositivos de sada podemos definir, no cabealho do
documento (dentro do elemento <head>), uma base de regies utilizando o
elemento <regionBase>.
Dentro de uma base de regies, definimos as regies atravs de elementos
<region>. Os elementos <region> definem as reas, nos dispositivos de sada,
onde os objetos de mdia podero ser exibidos inicialmente.
2
Para organizar o
leiaute das diversas partes do documento hipermdia, as regies podem ser
aninhadas. Em outras palavras, uma regio pode ser definida com relao
rea total associada ao dispositivo correspondente a uma base de regies ou
aninhada em outra regio. A definio de base de regies com diversas
regies aninhadas ilustrada pela Listagem 6.1.
Vale relembrar que, como uma aplicao NCL descrita em um documento
XML, um elemento, que pode ou no conter outros (p. ex., <region>), possui
duas formas de definio:
- elemento atmico, sem outros elementos aninhados:
<region id=rgPDAmenu1 />
- elemento com outros elementos aninhados e com o fechamento
explcito ao final do bloco:
<region id=rgPDAmenu >
</region>

2
Como visto na Seo 10.3, durante a apresentao de um objeto de mdia, a aplicao NCL pode
alterar os atributos que definem onde ele exibido.
157
<head>

<regionBase id=rbTV> 
<region id=rgTVtelaInteira> 
<region id=rgTVmenu > 
<region id=rgTVmenu1 />
</region>
</region>
</regionBase>
<regionBase id=rbPDA device=systemScreen(1)> 
<region id=rgPDAtelaInteira> 
<region id=rgPDAmenu > 
</region>
</region>
</regionBase>

</head>
Listagem 6.1 Definio das bases de regies para dois dispositivos e suas regies filhas,
onde sero exibidas as mdias.
6.1.1 Importao de Base de Regies
Alm de elementos <region>, uma base de regies tambm pode conter
elementos <importBase>, para importar as regies definidas na base de
regies de um outro documento NCL. O elemento <importBase> possui os
seguintes atributos
3
:
alias: apelido do arquivo importado, ou seja, o nome que ser utilizado
como prefixo para se referir aos elementos importados, no formato
apelido#id_do_elemento_importado;
documentURI: a localizao e o nome do arquivo que contm a base a ser
importada;
region: no caso de o arquivo importado conter uma base de regies, o
atributo define qual regio da aplicao conter as regies importadas. Se

3
Como sempre, neste captulo, os atributos sublinhados so obrigatrios.

T
V
P
D
A

158
o atributo no for especificado, assume-se que seja toda a rea de
exibio do dispositivo.
A Listagem 6.2 apresenta o cdigo correspondente importao e uso de
uma base de regies de um documento NCL externo. As regies definidas na
base de regies do arquivo baseRegMenu.ncl so importadas como filhos
de <regionBase> do documento atual, ao passo que as regies definidas na
base de regies do arquivo baseRegMenu.ncl so importadas como filhos
da regio rgVideoAux.
<regionBase>
<importBase alias=regMenu documentURI=baseRegMenu.ncl />
<importBase alias=regDoc
documentURI=baseRegDocumentario.ncl
region=rgVideoAux />

<region id=rgTV>
<region id=rgVideoAux top=5% left=5%
width=50% height=50% />
...
</region>
</regionBase>
...
<descriptorBase>
<descriptor id=dLegenda region=regDoc#rgLegenda />
...
</descriptorBase>
Listagem 6.2 Importao de uma base de regies e uso de regio importada, assumindo que
no arquivo baseRegDocumentario.ncl haja uma regio com identificador rgLegenda.
6.1.2 Atributos de Base de Regies
Uma base de regies <regionBase> possui os seguintes atributos:
- id: identificador unvoco da base de regies. Esse atributo no
obrigatrio para o elemento <regionBase>, mas quando
especificado deve seguir a mesma regra de formao para o
atributo id definida no Captulo 5;
- device: classe de dispositivos qual os filhos do elemento
<regionBase> se referem. Pode conter valores como
systemScreen(i), systemAudio(i), onde i um inteiro maior que
zero, conforme as classes de dispositivos disponveis.
O atributo device tambm opcional. Se no for definido, ele assume como
default a classe systemScreen(0). Nessa classe, s um dispositivo
159
registrado, tambm por default: o dispositivo de exibio associado ao
dispositivo onde est sendo processado o documento NCL. Neste captulo,
vamos supor que temos apenas um dispositivo de exibio e que, portanto,
ser declarado por default. Esse dispositivo pode ser uma TV ligada ao
conversor digital (set-top box) onde a aplicao NCL est sendo executada, a
tela de um computador onde a aplicao NCL est sendo processada etc. No
Captulo 15 trataremos da programao para mltiplos dispositivos de
exibio.
Vale observar que, ao associar uma classe de dispositivos a uma base de
regies <regionBase>, o dispositivo escolhido define variveis globais de
ambiente, tais como:
- system.screenSize(i): tamanho de tela da classe de dispositivos i,
expresso em (linhas, pixels/linha);
- system.screenGraphicSize(i): resoluo do plano grfico da classe
de dispositivos i, expresso em (linhas, pixels/linha);
- system.audioType(i): tipo de udio da classe de dispositivos i, que
pode assumir um dos seguintes valores: mono, stereo ou 5.1.
Essas e outras variveis de ambiente so definidas na Seo 9.3.1.
6.1.3 Atributos de Regio
Como j mencionamos, uma regio serve para iniciar a posio dos objetos
de mdia num local especfico. Para apresentar um vdeo no centro da tela e
com uma margem de 10%, por exemplo, podemos definir duas regies:
rgTV, que ocupa toda a rea disponvel do dispositivo, e rgTVcentro,
para que um objeto mdia seja apresentado no centro da tela, conforme a
Listagem 6.3.
<regionBase id=rbTV device=systemScreen(0)>
<region id=rgTV>
<region id=rgTVcentro left=10% top=10%
</region>
</regionBase>
Listagem 6.3 Exemplo de definio de regio centralizada em outra.
Essa definio corresponde ao leiaute apresentado na Figura 6.1.
160
rgTV
rgTVcentro

Figura 6.1 Leiaute de exemplo com uma regio (rgCentro) centralizada sobre uma regio
pai (rgTV).
A NCL define os seguintes atributos de regio:
- id: identificador nico, utilizado nas referncias regio (por exemplo,
pelos descritores dos objetos de mdia que sero apresentados na
regio), que segue a mesma regra de formao para o atributo id
definida no Captulo 5;
- left (esquerda): coordenada x do lado esquerdo da regio, com relao
coordenada do lado esquerdo da regio pai (ou da rea total
associada ao dispositivo, no caso de a regio no estar aninhada a
nenhuma outra);
- top (topo): coordenada y do lado superior da regio, com relao
coordenada do lado superior da regio pai (ou da rea total associada
ao dispositivo, no caso de a regio no estar aninhada a nenhuma
outra);
- right (direita): coordenada x do lado direito da regio, com relao
coordenada do lado direito da regio pai (ou da rea total associada ao
dispositivo, no caso de a regio no estar aninhada a nenhuma outra);
- bottom (base): coordenada y do lado inferior da regio, com relao
coordenada do lado inferior da regio pai (ou da rea total associada ao
dispositivo, no caso de a regio no estar aninhada a nenhuma outra);
- width (largura) e height (altura): dimenses horizontal e vertical da
regio;
- zIndex: nmero entre 0 e 255 que define a camada da regio ou
posio da regio no eixo z, utilizado geralmente para indicar, no
161
caso de regies sobrepostas, quais regies aparecem sobre quais outras.
Camadas com zIndex maior so apresentadas no topo de camadas com
zIndex menor (isto , sobrepondo essas ltimas). Quando no
especificado, assume o valor default 0;
- title (ttulo): ttulo da regio, cujo uso depende da implementao do
formatador.
Todos os atributos de um elemento <region> so opcionais, exceto o
atributo id.
Os atributos left, top, right, bottom, width e height podem ser
representados em pixels (p.ex., 50px ou simplesmente 50) ou em
porcentagem (p. ex., 25%). O percentual sempre relativo largura do pai,
no caso das definies dos atributos right, left e width, e altura do pai,
para as definies dos atributos bottom, top e height. Uma restrio que as
regies filhas no podem ficar fora da rea estabelecida por suas regies pais.
Quando qualquer um desses atributos no for especificado e no puder ter seu
valor calculado a partir de outros atributos, seu valor deve ser herdado do
valor correspondente definido no pai do elemento <region> que define o
atributo.
O autor pode escolher especificar as dimenses de uma regio conforme
sua convenincia. Por exemplo, em certos casos, pode ser melhor definir os
atributos right, bottom, width e height. Em outros casos, pode ser mais
apropriado especificar os atributos top, left, width e height. importante
observar que, caso todos os atributos de posicionamento e dimenso sejam
especificados, os atributos left e width tm precedncia sobre o atributo
right, assim como os atributos top e height tm precedncia sobre o atributo
bottom.
Quando duas ou mais regies possurem o mesmo valor de zIndex, e em
cada regio for apresentada uma mdia, existem duas possibilidades: caso
uma mdia seja apresentada antes da outra, a mdia que for iniciada depois vai
se sobrepor que foi iniciada antes (ordem temporal). Caso as duas mdias
sejam iniciadas ao mesmo tempo, a ordem escolhida arbitrariamente pelo
formatador.
A Figura 6.2 ilustra os atributos top, left, right, bottom, width, height e
zIndex.
162
rgPai
rgFilho
t
o
p
width right left
h
e
i
g
h
t
b
o
t
t
o
m
zIndex = 1
zIndex = 2
zIndex = 3

Figura 6.2 Atributos de posicionamento e dimenso de uma regio.
Vale observar que uma regio herda por default os atributos da sua regio
pai. Vamos considerar um menu vertical de quatro opes. Em vez de
definirmos a regio correspondente a cada item de menu com posio relativa
tela do dispositivo, podemos aninh-las a uma regio que simboliza toda a
rea de tela (bounding box) ocupada pelo menu (Figura 6.3).
rgTV
rgMenu1
rgMenu2
rgMenu3
rgMenu4
rgMenu

Figura 6.3 Leiaute de exemplo com diversas regies (rgMenu1, rgMenu2,
rgMenu3, rgMenu4) posicionadas de forma relativa a uma regio pai (rgMenu).
Observamos na Listagem 6.4 que a regio rgMenu1 comea a uma
distncia de 50 pixels das bordas superior e esquerda da tela e possui largura
de 200 pixels, pois herda os valores desses atributos da regio rgMenu. Por
outro lado, a altura de rgMenu1 de 50 pixels, conforme definido no
atributo do prprio elemento.

163

<regionBase>
<region id=rgTV>
<region id=rgMenu left=50 top=50
width=200 height=240>
<region id=rgMenu1 height=50 />
<region id=rgMenu2 top=60 height=50 />
</region>
</region>
</regionBase>
Listagem 6.4 Definio de regies para um menu vertical com quatro opes.

Para exemplificar a utilidade desse aninhamento de regies, suponha que
agora se decida que o menu deve ficar no lado direito da tela, em vez de no
lado esquerdo. A partir da definio anterior, a nica modificao que precisa
ser feita na especificao dos atributos da regio rgMenu: em vez de
situar o menu a 50 pixels do lado esquerdo da regio pai rgTV (posio
definida atravs do atributo left), definimos agora o atributo right, situando o
menu a 50 pixels do lado direito da regio pai rgTV, conforme o trecho de
cdigo apresentado na Listagem 6.5. As demais regies permanecem
inalteradas.
<regionBase>
<region id=rgTV>
<region id=rgMenu right=50 top=50
width=200 height=240>
<region id=rgMenu1 height=50 />
</region>
</region>
</regionBase>
Listagem 6.5 Alterao de atributo de uma regio pai.
A Figura 6.4 ilustra essa nova disposio das regies do menu.
164
rgTV
rgMenu1
rgMenu2
rgMenu3
rgMenu4
rgMenu

Figura 6.4 Leiaute de exemplo com diversas regies (rgMenu1, rgMenu2, rgMenu3,
rgMenu4) posicionadas de forma relativa a uma regio pai (rgMenu), prximas ao lado
direito da regio rgTV.
Exemplo 6.1. Reproduzindo um Vdeo em Tela Inteira
Como exemplo, esta seo apresenta uma aplicao NCL simples, que
apenas reproduz um vdeo em tela inteira. Apesar de no se tratar de um
documento hipermdia tpico (pois no h elos ligando objetos), o exemplo
tem por objetivo apenas explorar alguns atributos de regio e tambm
relembrar como as regies so associadas atravs de elementos <descritores>
a elementos <media>, sem entrar em detalhes sobre esses elementos, que so
assuntos de outros captulos.
A Figura 6.5 apresenta a viso estrutural desse exemplo. Observamos que
o contexto <body> contm apenas um n de mdia, videoPrincipal,
mapeado pela porta pVideoPrincipal.

pVideoPrincipal
body
videoPrincipal
Legenda:
Ci contexto
Mi n
porta
mapeamento

Figura 6.5 Viso estrutural do exemplo para reproduo de um nico vdeo, sem
sincronismo ou interao com o usurio.
165
A Figura 6.6 ilustra a viso de leiaute, com a regio rgTVtelaInteira
ocupando a tela inteira do dispositivo, representada aqui pela regio rgTV.
rgTVtelaInteira: 0,0 (100%x100%)
rgTV: 0, 0 (100%x100%)

Figura 6.6 Viso de leiaute do exemplo.
A Figura 6.7 ilustra as vises temporal e espacial do documento. A viso
temporal bem simples: envolve apenas a exibio integral da mdia
videoPrincipal. A viso espacial reflete quais mdias so exibidas para o
espectador num determinado instante de tempo. Nesse exemplo em especial,
apenas a mdia videoPrincipal exibida durante todo o tempo de execuo
do documento.
rgTVtelaInteira
videoPrincipal
videoPrincipal @ rgTVtelaInteira
(dTVtelaInteira)
viso espacial
viso temporal
pVideoPrincipal
1

Figura 6.7 Vises temporal e espacial do exemplo.
166
Passo a passo
Para construir uma aplicao NCL, podemos partir do esqueleto bsico
apresentado na Listagem 6.6, no qual os trechos destacados indicam as
lacunas que devemos preencher.
<ncl id=exemplo xmlns=http://www.ncl.org.br/NCL3.0/EDTVProfile>
<head>
<regionBase>

</regionBase>
<descriptorBase>

</descriptorBase>
</head>
<body >
<port id=nomeDaPorta component=umNoDesteContexto />

</body>
</ncl>
Listagem 6.6 Esqueleto bsico de uma aplicao NCL.
Para construir uma aplicao em NCL que reproduz um vdeo, criamos os
seguintes elementos:
1. o dispositivo onde a aplicao ser exibida;
2. a regio da tela onde o vdeo ser exibido;
3. o descritor que determina a forma como o vdeo ser exibido e em que
regio. Nesse caso, o vdeo associado a esse descritor ser exibido na
regio rgTVtelaInteira, com as propriedades default de exibio de
vdeo;
4. o n de mdia videoPrincipal, o vdeo propriamente dito;
5. a porta que define o ponto de entrada do documento hipermdia. Nesse
caso, a porta pVideoPrincipal, que mapeia para o nico elemento de
mdia, videoPrincipal.
Observao: Esse exemplo assume que h um arquivo de vdeo chamado
principal.mpg num subdiretrio media/ do documento atual.
167
Passos 1 e 2: Definindo Regies de Tela
Como visto anteriormente, as regies definem onde as mdias podero ser
apresentadas. So definidas por elementos <region> de uma base de regies
<regionBase> no cabealho <head> do documento. As regies podem ser
aninhadas umas nas outras, para facilitar o seu posicionamento relativo.
Nesse exemplo, temos apenas uma regio que ser associada mdia de
vdeo (rgTVtelaInteira), aninhada regio associada tela da TV
(rgTV) e ocupando todo o seu espao:
<head>
...
<regionBase>
<region id=rgTV left=0 top=0
width=100% height=100%>
<region id=rgTVtelaInteira left=0 top=0
</region>
</regionBase>
...
</head>
Vale observar que a posio default left=0 e top=0, e que a largura e
altura defaults so 100%. Sendo assim, as regies desse exemplo podem ser
definidas de forma mais concisa:
<head>
...
<regionBase>
<region id=rgTV>
<region id=rgTVtelaInteira />
</region>
</regionBase>
...
</head>
Lembramos ainda que os elementos da NCL (regio, descritor, objeto de
mdia, porta etc.) devem possuir identificadores nicos, representados pelo
atributo id. Por exemplo, uma mdia no pode ter o mesmo id de uma regio
ou de qualquer outro elemento.
Passo 3: Definindo o Descritor que Determina como o Vdeo ser Exibido
Tendo especificado as regies, definimos agora o descritor que determinar
como o vdeo ser exibido. Nesse exemplo, o descritor utilizado apenas para
associar uma mdia a uma regio. O cdigo NCL correspondente ao descritor
criado o seguinte:
168
<head>
...
<descriptorBase>
<descriptor id=dTVtelaInteira
region=rgTVtelaInteira
/>
</descriptorBase>
...
</head>
Esse descritor dTVtelaInteira extremamente simples, pois faz somente
a associao com uma regio, rgTVtelaInteira.
Passo 4: Definindo a Mdia Propriamente Dita
Tendo definido as regies e os descritores, o prximo passo criar os
objetos de mdia <media> que compem o documento. Lembrando o
esqueleto de uma aplicao NCL, a definio dos ns do documento feita na
seo <body>, que corresponde ao contexto do documento como um todo,
conforme ilustrado pela Listagem 6.7.
<body>
<media .../>
<media .../>

</body>
Listagem 6.7 Definio dos objetos de mdia no ncleo do documento.
Em sua definio mais abreviada, uma mdia deve definir, alm do seu
identificador, o arquivo de mdia propriamente dito e o descritor que define
como a mdia ser apresentada inicialmente. No exemplo, h apenas uma
mdia de vdeo, identificada como videoPrincipal, que deve ser apresentada
atravs do descritor dTVtelaInteira. O arquivo de vdeo que deve ser
reproduzido quando esse objeto for iniciado o arquivo principal.mpg,
localizado num subdiretrio media/ do diretrio onde se encontra o arquivo
NCL, conforme a Listagem 6.8.
<body>
...
<media id=videoPrincipal src=media/principal.mpg
descriptor=dTVtelaInteira />
...
</body>
Listagem 6.8 Definio dos objetos de mdia no ncleo do documento.
169
Passo 5: Definindo a Porta do Contexto <body> que Determina o Incio da
aplicao (Quais Mdias Devem ser Apresentadas Inicialmente)
Para concluir a criao desse exemplo, necessrio definir pelo menos uma
porta do contexto <body> que mapeie para um n de mdia, cuja apresentao
ser iniciada quando a aplicao for executada. No exemplo, o cdigo NCL
correspondente porta do <body> o seguinte:
<body>
<port id=pVideoPrincipal component=videoPrincipal />
...
</body>
A Listagem 6.9 apresenta o cdigo completo do exemplo, que reproduz o
vdeo armazenado em media/principal.mpg em tela inteira.
1: <?xml version=1.0 encoding=ISO-8859-1?>
2: <ncl id=exemplo xmlns=http://www.ncl.org.br/NCL3.0/EDTVProfile>
3: <head>
4: <regionBase>
5: <region id=rgTV>
6: <region id=rgTVtelaInteira zIndex=1 />
7: </region>
8: </regionBase>
9: <descriptorBase>
10: <descriptor id=dTVtelaInteira
region=rgTVtelaInteira />
11: </descriptorBase>
12: </head>
13: <body>
14: <port id=pVideoPrincipal component=videoPrincipal />
15: <media id=videoPrincipal src=media/principal.mpg
descriptor= dTVtelaInteira />
16: </body>
17: </ncl>
Listagem 6.9 Listagem completa do exemplo.
6.2 Referncia Rpida Regies
A Tabela 6.1 sumariza os elementos e atributos do mdulo Layout.
170
Tabela 6.1 Elementos, Atributos e Contedo (Elementos Filhos) Definidos pelo Mdulo
Layout do Perfil EDTV
regionBase id, device (importBase|region)
+
region id, left, right, top, bottom, height,
width, zIndex, title
(region)*
Bibliografia
ITU-T H.761 2011. Nested Context Language (NCL) and Ginga-NCL for
171
Captulo
7

Apresentao de
Objetos de Mdia:
Descritores
Neste captulo, descrevemos elementos e atributos de descritores,
1

responsveis pela definio dos parmetros de exibio de uma mdia em
dada regio, ou seja, pela configurao de como os objetos de mdia devero
ser apresentados. Os descritores descrevem tambm como pode ser feita a
navegao entre objetos de mdia atravs das teclas (setas) de navegao.
Ainda neste captulo, descrevemos os efeitos de transio disponveis em
NCL e como podem ser utilizados pelos descritores.
Ao final deste captulo, voc ser capaz de definir como um n
apresentado e como o usurio poder navegar pelos objetos de mdia atravs
das teclas (setas) de navegao.

1
Descritores e seus atributos so definidos no mdulo Descriptor [ABNT NBR, 15606-2 ,2011;
ITU-T, H.761, 2011].
172

7.1 Introduo a Descritores
Os descritores (elemento <descriptor>) especificam como os objetos de
mdia a eles associados sero exibidos inicialmente. Assim como as regies,
os descritores so definidos no cabealho do documento (dentro do elemento
<head>), em uma base de descritores definida pelo elemento
<descriptorBase>. No entanto, h duas diferenas importantes com relao
definio de regies:
- uma aplicao NCL no pode possuir mais de uma base de
descritores <descriptorBase>;
- um descritor <descriptor> no pode estar aninhado a outro
descritor.
O tipo mais simples de descritor apenas faz a associao com uma
regio, conforme o exemplo da Listagem 7.1.
<head>

<descriptorBase>
</descriptorBase>

</head>
Listagem 7.1 Definio de descritor simples que apenas faz associao com uma regio.
Nesse caso, toda mdia associada ao descritor dTVtelaInteira ser
apresentada inicialmente na regio rgTVtelaInteira, com os valores
defaults de exibio (volume de som, dimensionamento na regio etc.).
Um descritor pode, no entanto, definir parmetros adicionais de exibio
de mdia, atravs de elementos filhos <descriptorParam>, conforme ilustra a
Listagem 7.2.
173
<head>


<descriptorBase>
<descriptor id=dTVtelaInteira region=rgTVtelaInteira />
<descriptor id=dTVmenu region=rgTVmenu>
<descriptorParam name=transparency value=30% />
</descriptor>
<descriptor id=dTVmenu1 region=rgTVmenu1 />
</descriptorBase>

</head>
Listagem 7.2 Definio de uma base de descritores.
Elementos <descriptorParam> definem valores para propriedades dos
objetos de mdia que referem o descritor e pode incluir entre eles valores para
os atributos que definem uma regio: left, right, width, right, zIndex etc.
Nesse caso, esses valores sobrescrevem aqueles definidos pelos elementos
<region>.
O elemento <descriptorBase> possui apenas um atributo, id, que
opcional. Nesse elemento, o id serve para possibilitar o reso da base de
descritores em uma outra aplicao NCL, como apresentado na Seo 13.
Como todo atributo id, ele deve ser nico por todo o documento NCL e segue
a mesma regra de formao para o atributo id definida no Captulo 5.
7.1.1 Importao de Bases de Descritores
Assim como ocorre com a base de regies, uma base de descritores tambm
pode conter, alm de elementos <descriptor>, elementos <importBase> para
importar os descritores definidos na base de descritores de um outro
documento NCL. O elemento <importBase> possui os seguintes atributos:
alias: apelido do arquivo importado, ou seja, o nome que ser utilizado
apelido#id_do_elemento_importado;
documentURI: a localizao e o nome do arquivo que contm a base a ser
importada;
174
region: no caso de o arquivo importado conter uma base de regies,
define qual regio da aplicao conter as regies importadas.
Quando a base de descritores de um documento NCL importada, alm
dos descritores contidos nessa base, as regies e as regras das bases no
documento importado tambm so importadas para as bases correspondentes
no documento NCL atual (importador).
7.1.2 Atributos Bsicos de Descritor
A NCL define os seguintes atributos de descritor:
- id: identificador nico, utilizado nas referncias ao descritor (por
exemplo, nos objetos de mdia apresentados pelo descritor). Esse o
nico atributo obrigatrio de um elemento <descriptor>, e segue a
mesma regra de formao para o atributo id definida no Captulo 5;
- region: identificador da regio associada ao descritor. Todo objeto de
mdia que utilize esse descritor ser exibido inicialmente nessa regio.
Esse atributo s faz sentido para objetos que possuem um contedo
visual a ser exibido;
- explicitDur:
2
define a durao do objeto de mdia associado ao descritor.
O valor desse atributo pode ser expresso em segundos, no formato
9.9s (valor numrico inteiro ou real seguido da letra s). O valor pode
tambm ser expresso como horas:minutos:segundos.frao, onde
horas um inteiro no intervalo [0,23]; minutos um inteiro no
intervalo [0,59]; segundos um inteiro no intervalo [0,59]; e frao
um inteiro positivo. Quando explicitDur no for especificado, o objeto
que estiver associado ao descritor ser exibido com sua durao default.
Objetos de mdia sem durao intrnseca, como textos e imagens
estticas, possuem durao default infinita, ou seja, para suas exibies
terminarem, precisamos definir esse atributo ou encerr-las
explicitamente por um elo de sincronismo. Por exemplo, para que um
vdeo seja apresentado por apenas trs segundos, podemos associ-lo a
um descritor especificado como a seguir:
<descriptor id=dTVtelaInteira region=rgTVtelaInteira
explicitDur=3s />

2
Os atributos explicitDur e freeze so definidos pelo mdulo Timing [ABNT, NBR 15606-2,
2011; ITU-T, H.761, 2011].
175
- freeze: identifica o que acontece ao final da apresentao do objeto de
mdia associado ao descritor. O valor default do atributo false. Em
um vdeo, o valor true indica que, ao trmino natural do vdeo, o
ltimo quadro deve ser congelado indefinidamente, at que algum elo
termine sua exibio. Por exemplo, caso se queira manter o ltimo
quadro do vdeo congelado, seu descritor deve ser definido da seguinte
maneira:
<descriptor id=dTVtelaInteira region=rgTVtelaInteira
freeze=true />
- player: identifica a ferramenta de apresentao a ser utilizada para
exibir o objeto de mdia associado ao descritor. Quando esse atributo
omitido, o formatador NCL deve levar em conta o atributo type do
elemento <media> correspondente ao objeto de mdia a ser apresentado.
Se esse atributo tambm no for especificado, o formatador NCL deve
considerar a extenso do arquivo especificado no atributo src do
elemento <media>.
Exemplo 7.1 Reproduzindo uma Imagem sobre um Vdeo
Esta seo apresenta uma modificao sobre a aplicao NCL do exemplo
do captulo anterior. O novo exemplo reproduz um vdeo em tela inteira e uma
imagem que aparece no canto superior direito para indicar uma oportunidade
de interao. Essa imagem utilizada em exemplos posteriores para iniciar a
interatividade, atravs do acionamento de uma tecla do controle remoto.
Vamos iniciar a exibio da imagem junto com o vdeo. Para fazer isso,
no basta apenas acrescentar o novo objeto de mdia, o descritor e a regio
correspondente, pois o n no seria apresentado jamais (Figura 7.1).
pVideoPrincipal
body
videoPrincipal imgInteratividade
IN
C
O
M
P
L
E
T
O

Figura 7.1 Viso estrutural ilustrando n inatingvel.

176

Para que a exibio da imagem ocorra no incio da aplicao, junto com o
vdeo, suficiente declararmos outra porta (pImgInteratividade),
mapeando para a imagem (imgInteratividade), conforme a viso estrutural
ilustrada na Figura 7.2.
pVideoPrincipal
body
videoPrincipal imgInteratividade
pImgInteratividade

Figura 7.2 Viso estrutural do Exemplo 7.1.
A viso de leiaute apresentada na Figura 7.3. Observamos que foi
introduzida uma nova regio (rgInteratividade), onde ser apresentado o
novo objeto de mdia.
rgTVtelaInteira
rgTV
rgInteratividade

Figura 7.3 Viso de leiaute do Exemplo 7.1.
Surge um problema, no entanto. Como uma imagem no tem durao
intrnseca, ela , por default, exibida indefinidamente, e, nesse caso, a
aplicao no terminar jamais. Para resolver esse problema, no exemplo a
imagem definida como tendo a durao explcita de quatro segundos. Uma
soluo melhor apresentada no Captulo 10, dedicado a elos e conectores.
As vises temporal e espacial desse exemplo so ilustradas na Figura 7.4.
177

videoPrincipal videoPrincipal
rgInteratividade
rgTVtelaInteira
viso espacial
viso temporal
1 2
pVideoAbertura
pImgInteratividade
imgInteratividade
videoPrincipal
4 segundos
imgInteratividade

Figura 7.4 Vises temporal e espacial do Exemplo 7.1.
Passo a passo
Tomando como base o exemplo do captulo anterior, para construir o novo
exemplo, necessrio criar os seguintes elementos:
1. a regio da tela onde a imagem ser exibida, no caso rgInteratividade;
2. o descritor que determina a forma como a imagem ser exibida, em que
regio e durante quanto tempo (dInteratividade). Nesse caso, o vdeo
associado a esse descritor ser exibido na regio rgInteratividade,
durante quatro segundos;
3. o n de mdia imgInteratividade, a imagem propriamente dita;
4. a porta que mapeia para a imagem, no caso pImgInteratividade.
Observao: Para executar o exemplo, so necessrios um arquivo de
vdeo chamado principal.mpg e um arquivo de imagem chamado
vermelhoI.png.
Passo 1: Definindo a regio onde exibir a imagem do boto
Assim como no exemplo do captulo anterior, devemos definir, na seo
<regionBase> do cabealho do documento, uma regio para a apresentao
do n de mdia da imagem. Para garantir que a imagem ser apresentada
numa camada superior camada de vdeo, utilizamos o atributo de regio
zIndex.
178
<head>
...
<regionBase>
<region id=rgTV>
<region id=rgInteratividade right=5% bottom=5%
width=45 height=45 zIndex=3 />
</region>
</regionBase>
...
</head>
Passo 2: Definindo o descritor que determina como a imagem do boto ser
exibida
Assim como no exemplo do captulo anterior, devemos definir, na seo
<descriptorBase> do cabealho do documento, um descritor para a
apresentao do n de mdia de imagem na regio rgInteratividade.
Devemos definir tambm o atributo explicitDur para restringir a durao da
imagem a quatro segundos:
<head>
...
<descriptorBase>
<descriptor id=dTVelaInteira region=rgTVtelaInteira />
<descriptor id=dInteratividade region=rgInteratividade
explicitDur=4s />
</descriptorBase>
...
</head>
Passo 3: Definindo a mdia correspondente imagem do boto
Para criar o n de mdia para a imagem, devemos editar a seo <body> e
acrescentar o elemento de mdia correspondente, indicando qual descritor deve
ser utilizado para iniciar sua apresentao:
<body>
...
<media id=imgInteratividade src=media/vermelhoI.png
descriptor=dInteratividade />
...
</body>
179
Passo 4: Definindo a porta adicional para a nova imagem
Para que a imagem seja iniciada junto com o incio da aplicao, devemos
acrescentar, tambm na seo <body>, uma nova porta mapeando para o
novo elemento de mdia:
<body>
<port id=pInteratividade component=imgInteratividade />
...
</body>
Quando a aplicao iniciar, as mdias mapeadas em todas as portas do
contexto <body> so iniciadas; nesse caso, videoPrincipal e
imgInteratividade. A Listagem 7.3 apresenta o cdigo completo do
Exemplo 7.1.
<ncl id=exemplo02 xmlns=http://www.ncl.org.br/NCL3.0/EDTVProfile>
<head>
<regionBase>
<region id=rgTV>
<region id=rgTVtelaInteira zIndex=1 />
</region>
</regionBase>
<descriptorBase>
explicitDur=4s />
</descriptorBase>
</head>
<body>
descriptor= dTVtelaInteira />
</body>
</ncl>
Listagem 7.3 Listagem completa do Exemplo 7.1.
180
Nesse exemplo, a imagem do boto de interatividade exibida por um
perodo de tempo pr-definido (quatro segundos). No Captulo 10, mostramos
como fazer para sincronizar a imagem com o vdeo, iniciando e terminando a
exibio da imagem junto com o vdeo.
7.1.3 Parmetros de Descritor
A NCL define, ainda, o seguinte elemento opcional contido num elemento
de descritor:
- <descriptorParam>: define um parmetro do descritor como um par
(propriedade, valor). As propriedades e seus respectivos valores
dependem da ferramenta de exibio da mdia associada ao
descritor.
Cada descritor pode conter diversos elementos <descriptorParam>,
definidos no formato:
<descriptor ...>
<descriptorParam name=nomeParam value=valorParam />
<descriptorParam name=nomeParam value=valorParam />
...
</descriptor>
Por exemplo, um descritor pode definir um parmetro adicional
soundLevel, com valor 0.9 ou 90%, para indicar que a mdia
correspondente deve ser reproduzida com o volume a 90% do seu volume de
gravao:
<descriptor id=dTVtelaInteira region=rgTVtelaInteira>
<descriptorParam name=soundLevel value=0.9 />
</descriptor>
ou, ainda,
<descriptor id=dTVtelaInteira region=rgTVtelaInteira>
<descriptorParam name=soundLevel value=90% />
</descriptor>
O uso de parmetros de descritor promove alto grau de flexibilidade. Cabe
a cada programa de exibio do objeto de mdia (ferramenta de exibio)
interpretar essas propriedades da forma adequada.
Existem parmetros de descritor reservados para diversos tipos de mdia:
objetos de mdia com udio, objetos de mdia visual e objetos de mdia
textual. Na verdade, os nomes reservados so para propriedades de objetos de
181
mdia que podem ter seu valor inicial especificados pelo elemento
<descriptorParam>.
Alguns parmetros parmetros de descritor reservados para objetos
de mdia com udio:
- soundLevel, trebleLevel, bassLevel: valores entre 0 e 1, ou
entre 0% e 100%. No caso de soundLevel, 0 = mute; 0.5 ou
50% = volume pela metade; e 1 ou 100% = volume mximo).
- balanceLevel: valor entre -1 e 1, ou entre 100% e 100%.
Alguns parmetros de descritor reservados para objetos de mdia
visual:
- top, left, bottom, right, width, height: posio e dimenses
do objeto de mdia, conforme definido pelos atributos anlogos do
elemento <region>;
- location: posio do objeto de mdia, formatada como dois nmeros
separados por vrgula, na ordem left, top num dos seguintes formatos:
- nmeros reais entre 0 e 100, seguidos do sinal de porcentagem; ou
- nmeros inteiros que especifiquem um valor em pixels;
- size: dimenses do objeto de mdia, formatada como dois nmeros
separados por vrgula, na ordem width, height, num dos seguintes
formatos:
- nmeros inteiros no-negativos que especifiquem um valor em pixels;
- bounds: posio e dimenses do objeto de mdia, formatada como
quatro nmeros separados por vrgula, na ordem left, top, width,
height, num dos seguintes formatos:
- nmeros inteiros que especifiquem um valor em pixels;
- zIndex: posio da regio no eixo z, utilizado geralmente para
indicar sobreposies de regies, conforme definido pelo atributo
anlogo do elemento <region>;
182
- background: cor de fundo exibida quando a mdia no couber na
regio (dependendo do valor do atributo fit). Deve ser utilizado um dos
seguintes nomes de cores reservados: white, black, silver, gray,
red, maroon, fuchsia, purple, lime, green, yellow,
olive, blue, navy, aqua ou teal. Tambm pode ser
transparent;
- visible: true (a mdia deve ser apresentada na tela do dispositivo) ou
false (a mdia no deve ser apresentada na tela do dispositivo);
- transparency: nmero real entre 0 e 1 (ou entre 0 e 100%) indicando
transparncia: 0 significa totalmente opaco e 1 ou 100% significa
totalmente transparente;
- fit: um dos seguintes valores: fill, hidden, meet, meetBest ou
slice, cujos efeitos so descritos a seguir:
- fill: redimensiona o contedo do objeto de mdia para que toque todas
as bordas da regio, distorcendo-o caso necessrio, conforme ilustrado
pela Figura 7.5;
figuras
originais
figuras exibidas na regio
com fit igual a fill

Figura 7.5 Ilustrao do parmetro de descritor fit com o valor fill.
- hidden: se a altura intrnseca ao contedo da mdia for menor que o
atributo height, o objeto precisa ser renderizado a partir do topo e ter
sua altura restante preenchida com a cor de background; caso seja
maior, o restante deve ser cortado. Idem para a largura esquerda,
conforme ilustrado pela Figura 7.6, para os dois casos: mdia menor que
a regio e mdia maior que a regio;
183
hidden
hidden
mdia menor que
regio
mdia maior que regio
mdia mdia apresentao apresentao

Figura 7.6 Ilustrao do parmetro de descritor fit com o valor hidden.
- meet: redimensiona o contedo do objeto de mdia mantendo suas
propores at atingir uma das bordas da regio. Caso haja um espao
vazio direita ou na parte de baixo, deve ser preenchido com a cor de
background, conforme ilustrado pela Figura 7.7;
figuras
originais
com fit igual a meet

Figura 7.7 Ilustrao do parmetro de descritor fit com o valor meet.
- meetBest: semelhante ao meet, mas o objeto de mdia no
ampliado em mais do que o dobro das dimenses originais, conforme
ilustrado pela Figura 7.8;
figuras
originais
com fit igual a meetBest

Figura 7.8 Ilustrao do parmetro de descritor fit com o valor meetBest.
184
- slice: redimensiona o contedo do objeto de mdia mantendo suas
propores at que toda a regio seja preenchida. Parte do contedo pode
ser cortado direita ou na parte de baixo do contedo, conforme
ilustrado pela Figura 7.9.
figuras
originais
com fit igual a slice

Figura 7.9 Ilustrao do parmetro de descritor fit com o valor slice.
Alguns parmetros de descritor reservados para objetos de mdia
textual;
- scroll: um dos seguintes valores: none, horizontal, vertical, both
ou automatic. Se o valor for automatic, as barras de rolamento s
aparecem caso necessrio, ou seja, caso o texto no caiba na regio
qual est associado;
- style: localizao de um arquivo de folha de estilo;
- fontColor: a cor da fonte (white, black, silver, gray, red,
maroon, fuchsia, purple, lime, green, yellow, olive,
blue, navy, aqua ou teal);
- fontFamily: lista priorizada com nomes de fontes especficas ou
genricas. Especificao obrigatria;
- fontSize: tamanho da fonte, em pontos. Especificao obrigatria;
- fontVariant: texto normal ou em small-caps (letras maisculas
pequenas);
- fontWeight: normal ou bold (negrito).
185
Alguns parmetros de descritor reservados para qualquer tipo de
objeto de mdia:
- reusePlayer: define se um player j instanciado e se pode ou no ser
reutilizado. Pode assumir os valores false ou true;
- playerLife: define o que acontece com o player quando termina de tocar
a mdia associada ao descritor: keep ou close.
No Captulo 9, valores default para propriedades, definidas ou no por
meio de elementos <descriptorParam>, so estabelecidos.
Exemplo 7.2 Reproduzindo uma Imagem com Transparncia
sobre um Vdeo
Este exemplo apresenta uma modificao sobre a aplicao NCL do
exemplo anterior, de modo a exibir a imagem de boto com transparncia.
Para isso, necessrio apenas acrescentar um parmetro (atravs do elemento
<descriptorParam>) ao descritor dInteratividade, conforme ilustrado no
cdigo da Listagem 7.4. As vises estrutural, de layout e temporal no sofrem
alteraes.
explicitDur=4s>
</descriptor>
Listagem 7.4 Exemplo de descritor com transparncia.
7.2 Navegao por Teclas
Para permitir a navegao por itens de um menu utilizando teclas,
utilizamos os atributos focusIndex, moveLeft, moveRight, moveUp,
moveDown, focusBorderColor, focusBorderTransparency,
focusBorderWidth, focusSrc, focusSelSrc e selBorderColor do elemento
<descriptor>.
3
Como sempre, esses atributos definem, de fato, valores para
propriedades de objetos de mdia associados ao descritor.
Definimos a navegao por teclas nos descritores utilizados pelos ns que
podem ter o foco da interao. Para cada descritor, definimos um atributo

3
Atributos de descritor relacionados navegao esto descritos no mdulo KeyNavigation
[ABNT, NBR 15606-2, 2011; ITU-T, H.761, 2011].
186
focusIndex, cujo valor corresponde a um ndice que o objeto de mdia
associado quele descritor receber. Utilizamos o valor desse atributo nos
demais descritores para indicar o destino do foco quando o usurio pressionar
a seta para cima (atributo moveUp), para baixo (atributo moveDown), para a
esquerda (atributo moveLeft) e para a direita (atributo moveRight). A
ausncia de um desses atributos significa que no h navegao com a tecla
de seta correspondente do controle remoto.
Por exemplo, num menu vertical de seis itens, faz sentido definir como
valores para o atributo focusIndex os valores de 1 a 6. Os atributos
moveDown e moveUp de cada descritor indicam para qual opo deve mudar
o foco quando as teclas DOWN e UP forem pressionadas, respectivamente.
Por exemplo, no descritor de focusIndex 1, definimos o atributo
moveDown como 2 para significar que, quando o foco estiver no elemento
associado ao descritor com focusIndex 1, se o usurio pressionar a tecla de
seta para baixo o foco passa para o elemento associado ao descritor com
focusIndex 2. possvel, ainda, definir um menu circular, no qual o
atributo moveUp do primeiro descritor do primeiro item tem como valor o
focusIndex do descritor do ltimo item. A Figura 7.10 ilustra esses atributos
para a verso simples e para a verso circular.
focusIndex=1
moveDown=2
focusIndex=3
moveUp=2
moveDown=4
focusIndex=2
moveUp=1
moveDown=3
focusIndex=5
moveUp=4
moveDown=6
focusIndex=4
moveUp=3
moveDown=5
focusIndex=6
moveUp=5
focusIndex=1
moveUp=6
moveDown=2
focusIndex=3
moveUp=2
moveDown=4
focusIndex=2
moveUp=1
moveDown=3
focusIndex=5
moveUp=4
moveDown=6
focusIndex=4
moveUp=3
moveDown=5
focusIndex=6
moveUp=5
moveDown=1
(a) (b)

Figura 7.10 Atributos de descritor relacionados navegao em um menu vertical de seis
itens: (a) no-circular e (b) circular.
187
De forma anloga, para menus horizontais, os atributos moveLeft e
moveRight de cada descritor indicam para qual opo deve mudar o foco
quando as teclas LEFT e RIGHT forem pressionadas, respectivamente.
Nesse tipo de menu, imprescindvel que o usurio seja mantido informado
sobre qual a seleo atual. Para isso, este exemplo utiliza o conceito de foco
introduzido em NCL 3.0. Podemos definir cor, transparncia e largura de
moldura do elemento em foco pelos atributos focusBorderColor,
focusBorderTransparency e focusBorderWidth. Um valor negativo (p. ex.,
2) para a largura indica que a moldura deve ser exibida ocupando alguns
(no caso, 2) pixels dentro da regio em que o boto aparece, enquanto um
valor positivo projeta a moldura para fora dessa regio, circunscrevendo o n,
conforme ilustrado pela Figura 7.11.
focusBorderColor=black
focusBorderWidth=2"
(sem moldura)
focusBorderColor=black
focusBorderWidth=-2"

Figura 7.11 Ilustrao de diferentes valores de focusBorderWidth para traar uma moldura
ao redor do elemento em foco.
Alm de traar uma moldura, a NCL permite que o prprio objeto de mdia
seja modificado quando o descritor ganha o foco, atravs do atributo
focusSrc. Seu valor um URI, semelhante ao atributo src do elemento
<media>, que apresentamos no prximo captulo. Quando o usurio pressiona
o boto OK para selecionar o elemento em foco, tambm possvel mudar a
cor da moldura e a mdia, atravs dos atributos selBorderColor e
focusSelSrc.
Resumindo, os atributos do elemento <descriptor> relacionados
navegao por teclas so os seguintes:
- focusIndex: define um ndice de navegao para o objeto de mdia
associado ao descritor. Caso no seja definido um valor para esse
atributo, o objeto de mdia associado ao descritor no poder receber o
foco da navegao. O foco inicial estar no objeto com focusIndex
188
menor. Vale observar que cada valor de focusIndex deve ser nico por
todo o documento. Caso dois ou mais descritores diferentes possuam o
mesmo valor de focusIndex, um deles ser ignorado; focusBorderColor:
define a cor da moldura que destaca o elemento em foco, ou seja, o
retngulo que deve aparecer sobrescrito regio desse descritor quando
o objeto a ele associado receber o foco. Pode ser um dos seguintes
valores: (white, black, silver, gray, red, maroon, fuchsia,
purple, lime, green, yellow, olive, blue, navy, aqua ou
teal). Esse atributo assume o valor default especificado pela
propriedade defaultSelBorderColor do n settings do documento;
- focusBorderWidth: define a espessura, em pixels, da moldura desse
descritor quando o elemento a ele associado receber o foco. Caso seja
igual a 0, nenhuma borda ser apresentada. Um valor positivo indica que
a borda estar fora do contedo do objeto, ao passo que um valor
negativo indica que a borda ser desenhada sobre o contedo do objeto.
Esse atributo assume o valor default especificado pela propriedade
defaultFocusBorderWidth do n settings do documento;
- focusBorderTransparency: define a porcentagem de transparncia da
moldura. Deve ser um valor real entre 0 e 1 (ou um valor em
porcentagem, entre 0 e 100%), onde 0 significa totalmente opaco e 1
significa totalmente transparente. Esse atributo assume o valor default
especificado pela propriedade defaultFocusBorderTransparency do n
settings do documento;
- focusSrc: define o caminho de uma mdia alternativa que deve ser
exibida quando o elemento associado a esse descritor estiver com o foco.
Segue o mesmo formato do atributo src do elemento <media>, conforme
apresentado no prximo captulo;
- focusSelSrc: define o caminho de uma mdia alternativa que deve ser
exibida quando for pressionada a tecla de ativao (OK, Enter ou
equivalente) enquanto o elemento associado a esse descritor estiver com
o foco. Segue o mesmo formato do atributo src do elemento <media>,
conforme apresentado no prximo captulo;
- selBorderColor: define uma cor de moldura que deve ser exibida quando
for pressionada a tecla de ativao (OK, Enter ou equivalente) enquanto
o elemento associado a esse descritor estiver com o foco. Esse atributo
assume o valor default especificado pela propriedade
defaultFocusBorderColor do n settings do documento;
189
- moveLeft: identifica o ndice de navegao do elemento E que deve
receber o foco caso seja pressionada a seta para a esquerda enquanto o
elemento associado a esse descritor estiver com o foco (definido pelo
atributo focusIndex do elemento E). Caso o elemento que receberia o
foco esteja com a propriedade visible igual a false ou no esteja sendo
apresentado, o foco no se desloca;
- moveRight: identifica o ndice de navegao do elemento E que deve
receber o foco caso seja pressionada a seta para a direita enquanto o
foco esteja com a propriedade visible igual a false ou no esteja sendo
apresentado, o foco no se desloca;
- moveUp: identifica o ndice de navegao do elemento E que deve
receber o foco caso seja pressionada a seta para cima enquanto o
foco esteja com visible igual a false ou no esteja sendo apresentado, o
foco no se desloca;
- moveDown: identifica o ndice de navegao do elemento E que deve
receber o foco caso seja pressionada a seta para baixo enquanto o
foco esteja com visible igual a false ou no esteja sendo apresentado, o
foco no se desloca.
Vale observar que se, a qualquer momento da apresentao, o foco for
perdido (p. ex., se a mdia associada ao descritor em foco terminar de ser
exibida), um novo foco ser definido para o elemento cujo descritor tiver o
menor valor para focusIndex. Alm disso, caso o foco deva ser deslocado
para um elemento cuja propriedade visible est com o valor false ou para
um elemento que no esteja sendo apresentado, o foco atual no se desloca,
como j mencionado.
Quando um elemento em foco selecionado pressionando-se a tecla de
ativao (ENTER, OK), o controle passado para o player do elemento
<media> correspondente. A partir de ento, o player pode seguir suas
prprias regras de navegao (p. ex., uso de setas para fazer o rolamento em
uma pgina HTML). O controle de foco deve ser passado de volta ao
formatador NCL quando a tecla BACK (volta) for pressionada. Nesse caso, o
foco se desloca para o elemento identificado pelo atributo
service.currentFocus do n settings, varivel de ambiente vista na Seo
190
9.3.1. O controle de foco tambm pode ser deslocado por programao. Para
isso, devemos atribuir valores propriedade service.currentKeyMaster do n
settings, atravs de um elo
4
ou de um comando de um objeto imperativo
(NCLua ou NCLet)
5
ou, ainda, pelo player (ferramenta de exibio) do n
que est com o controle de foco atual.
A Listagem 7.5 apresenta a definio dos descritores de um menu vertical
de quatro itens, cujas imagens e molduras so modificadas quando cada item
ganha o foco.
<descriptorBase>
<descriptor id=dMenuItem1 region=rgMenuItem1
focusIndex=1 moveUp=4 moveDown=2
focusSelSrc=media/menu1ON.gif
focusBorderWidth=3 focusBorderColor=white
selBorderColor=white />
...
</descriptorBase>
Listagem 7.5 Definio de descritores de um menu vertical de quatro itens.
7.3 Efeitos de Transio
Para exibir mdias com efeitos de transio, utilizamos os atributos transIn
e transOut do elemento <descriptor>, que fazem referncia a elementos

4
Elos que manipulam propriedades so apresentados na Seo 10.8.

5
Objetos imperativos so apresentados nos Captulos 17 e 18.
191
<transition> de uma base de transies <transitionBase>.
6
Os efeitos de
transio no so obrigatrios no perfil BDTV da linguagem NCL 3.0, mas
apenas no perfil EDTV. Antes de examinar os atributos transIn e transOut,
descrevemos a base de transies, seus elementos e atributos.
7.3.1 Base de Transies
As transies (elemento <transition>) especificam efeitos de transio que
os descritores podem utilizar na exibio de objetos de mdia em uma
aplicao NCL. Assim como os descritores, as transies so definidas no
cabealho do documento (dentro do elemento <head>), em uma base de
transies definida pelo elemento <transitionBase>:
<transitionBase>
<transition ... />
</transitionBase>
Assim como a base de descritores, uma aplicao NCL pode possuir
apenas uma base de transies. Assim como os descritores, transies
tambm podem ser importadas de documentos NCL externos, atravs do
elemento <importBase> e seus atributos alias e documentURI. A Tabela 7.1
sumariza os atributos e contedo do elemento <transitionBase>.
Tabela 7.1 Elementos, Atributos e Contedo (Elementos Filhos) de uma Base de Transies
transitionBase id (importBase, transition)+
7.3.2 Transies
A NCL utiliza os tipos de transio e seus respectivos subtipos
apresentados na Tabela 7.2. Cada tipo de transio descreve um grupo de
transies que so intimamente relacionadas. Dentro desse tipo, cada uma das
transies individuais associada a um subtipo que enfatiza as caractersticas
distintas da transio. O atributo type de um elemento <transition>
obrigatrio e utilizado para especificar a transio geral. O atributo subtype
fornece o controle especfico para a transio. Esse atributo opcional e, se
especificado, deve ser um dos subtipos de transio apropriados para o tipo

6
A especificao das transies encontra-se nos mdulos TransitionBase e Transition [ABNT,
NBR 15606-2, 2011; ITU-T, H.761, 2011].
192
correspondente. Se esse atributo no for especificado, a transio deve ser
revertida para o subtipo default do tipo especificado. Vale notar que apenas
os subtipos default so obrigatoriamente implementados no middlewares
Ginga para TV digital terrestre. Outros tipos e subtipos so opcionais. Caso
um tipo ou subtipo no esteja definido na implementao em um determinado
dispositivo, o efeito de transio correspondente ser ignorado, mas a
aplicao ser executada sem erros.
Tabela 7.2 Tipos e Subtipos de Transio
Tipo Subtipos (Valor Default Sublinhado)
barWipe leftToRight, topToBottom
irisWipe rectangle, diamond
clockWipe
clockwiseTwelve, clockwiseThree, clockwiseSix,
clockwiseNine
snakeWipe
topLeftHorizontal, topLeftVertical, topLeftDiagonal,
topRightDiagonal, bottomRightDiagonal,
bottomLeftDiagonal
fade crossfade, fadeToColor, fadeFromColor
Os tipos de transio podem ser descritos como:
- barWipe: varredura simples, horizontal ou vertical;
- irisWipe: varredura a partir do centro de um objeto de mdia,
seguindo uma figura geomtrica;
- clockWipe: varredura como um ponteiro de relgio;
- snakeWipe: varredura em espiral;
- fade: mudana gradual de cores.
Os atributos do elemento <transition> so os seguintes:
- id: atributo obrigatrio que identifica a transio, que ser utilizado
como valor para os atributos transIn e transOut dos descritores, e
que segue a mesma regra de formao para o atributo id definida no
Captulo 5;
193
- type: atributo obrigatrio que especifica o tipo da transio,
conforme a Tabela 7.2;
- subtype: subtipo da transio, conforme o tipo (Tabela 7.2);
- direction: especifica a direo em que ocorrer a transio. Os
valores permitidos so forward e reverse. O valor default
forward. Nem todas as transies tero interpretaes reversas
significantes. Por exemplo, um crossfade no uma transio
geomtrica e, portanto, no tem interpretao de direo reversa. As
transies que no tm interpretao reversa devem ter o atributo
direction ignorado e o valor default forward assumido;
- dur: durao da transio, em segundos. O default 1s;
- startProgress: especifica o quanto de progresso para a transio
deve ser assumido ao iniciar a execuo, entre [0.0,1.0]. Um valor
de 0.5 para uma transio de entrada type barWipe, subtype
leftToRight, significa que, no incio da transio, metade da
transio j ter ocorrido, ou seja, metade da imagem do objeto de
mdia j aparece de imediato, e a transio prossegue revelando o
restante da imagem, conforme ilustrado pela Figura 7.12;

Figura 7.12 Ilustrao de uma transio de entrada type barWipe, subtype=leftToRight,
startProgress=0.5, que apresenta a imagem inicialmente j a 50% do progresso total da
transio.
- endProgress: especifica at quanto de progresso para a transio
deve ser realizado at terminar a execuo entre [0.0,1.0]. Ao
atingir esse valor, toda a mdia revelada;
- fadeColor: cor utilizada pelo efeito de transio do tipo fade, com
subtipo fadeToColor ou fadeFromColor. O valor default para o
atributo black. Esse atributo ignorado para outros tipos e
subtipos de transio;
194
- horRepeat: quantas vezes a transio deve ser realizada no eixo
horizontal. O valor default 1;
- verRepeat: quantas vezes a transio deve ser realizada no eixo
vertical. O valor default 1;
- borderWidth: largura da moldura gerada ao longo da borda da
transio. Se for 0 (o default), no gerada nenhuma moldura ao
longo da borda da transio;
- borderColor: cor da moldura gerada ao longo da borda da
transio. Se for blend, a moldura gerada ao longo da borda ser
de uma cor aditiva s cores das mdias de origem. O valor default
para esse atributo black.

A Tabela 7.3 sumariza os atributos e contedo do elemento <transition>.
Tabela 7.3 Elementos, Atributos e Contedo (Elementos Filhos) das Transies
transition id, type, subtype, dur, startProgress,
endProgress, direction, fadeColor, horRepeat,
vertRepeat, borderWidth, borderColor

7.3.3 Atributos de Descritor para Transies
Os atributos transIn e transOut do elemento <descriptor> so definidos
do seguinte modo:
- transIn: identificador da transio que ser executada ao iniciar a
apresentao do objeto de mdia, tal como definida pelo elemento
<transition> na base de transies <transitionBase>. Podem ser
definidas diversas transies, separadas por ponto-e-vrgula, para o
caso de a transio desejada prioritariamente no estar disponvel;
- transOut: identificador da transio que ser executada ao terminar
a apresentao do objeto de mdia, tal como definida pelo elemento
<transition> na base de transies <transitionBase>. Podem ser
definidas diversas transies, separadas por ponto-e-vrgula, para o
caso de a transio desejada prioritariamente no estar disponvel.

195

Exemplo 7.3 Reproduzindo uma Imagem com Transio de
Sada
O novo exemplo apresenta uma modificao sobre a aplicao NCL do
exemplo anterior, de modo a terminar a exibio da imagem de interatividade
com uma transio do tipo fade. Para tanto, necessrio definir uma base de
transies e acrescentar o atributo transOut ao descritor correspondente,
conforme ilustrado na Listagem 7.6.
<head>
...
<transitionBase>
<transition id=tFade type=fade
subtype=crossfade dur=0.5s />
</transitionBase>
<descriptorBase>
explicitDur=4s transOut=tFade>
</descriptor>
</descriptorBase>
...
</head>
Listagem 7.6 Definio de efeito de transio do tipo fade.
7.4 Referncia Rpida Descritores
A Tabela 7.4 sumariza os elementos e atributos que definem os descritores.
Como sempre, os atributos obrigatrios so sublinhados.
196
Tabela 7.4 Elementos, Atributos e Contedo (Elementos Filhos) que Definem Descritores
para o Perfil EDTV
descriptor id, player, explicitDur, region,
freeze, transIn, transOut,
moveLeft, moveRight, moveUp,
moveDown, focusIndex,
focusBorderColor,
focusBorderWidth,
focusBorderTransparency,
focusSrc, focusSelSrc,
selBorderColor
(descriptorParam)*
descriptorParam name, value
descriptorBase id (importBase |
descriptor |
descriptorSwitch)+
Bibliografia

197
Captulo
8

Objetos de Mdia
e
Contexto
Neste captulo, descrevemos os elementos e atributos dos objetos de mdia
1
e
contextos.
2
Apresentamos os tipos de objetos de mdia permitidos em NCL,
incluindo alguns tipos de objetos especiais. Na medida em que as aplicaes
NCL se tornam maiores e mais complexas, seu cdigo pode ser estruturado
em contextos para aumentar a legibilidade e as oportunidades de reso do
cdigo. Ao final deste captulo, voc ser capaz de estruturar os ns e os elos
de uma aplicao em contextos para obter esses benefcios.
8.1 Objetos de Mdia e seus Atributos
Cada objeto de mdia geralmente possui, alm de seu identificador, os
atributos src, que define um URI do contedo do objeto (isto , onde o

1
Objetos de mdia e seus atributos so definidos no mdulo Media [ABNT, NBR 15606-2, 2011;
ITU-T, H.761, 2011].
2
Contextos e seus atributos so definidos no mdulo Context [ABNT, NBR 15606-2, 2011; ITU-T,
H.761, 2011].
198
contedo do objeto se encontra), type, que define o tipo de objeto (vdeo,
udio, texto etc.) e descriptor, que referencia o descritor que define como a
mdia ser apresentada.
Um objeto (n) de mdia ou de contedo representado pelo elemento
<media>. Cada definio de objeto de mdia pode apresentar, alm do arquivo
de origem da mdia, o descritor que regular a apresentao daquele objeto de
mdia. No exemplo a seguir, so definidos objetos de mdia do tipo vdeo e
imagem. Note que o atributo type opcional. No caso, ele pode ser inferido
pela extenso do arquivo que define o contedo do objeto. O atributo
descriptor tambm opcional. Se no for especificado, todas as definies
que regulam a apresentao do objeto devem ser inferidas dos elementos
<property> do objeto de mdia em questo, conforme discutido no Captulo 9.
8.1.1 Atributos de Objeto de Mdia
Um objeto de mdia possui os seguintes atributos:
- id: identificador nico, obrigatrio, do objeto de mdia, utilizado nas
referncias ao objeto (por exemplo, nas portas dos contextos que levam
mdia), e que segue a mesma regra de formao para o atributo id
definida no Captulo 5;
- src: fonte do objeto de mdia, ou seja, a localizao ou caminho do
objeto de mdia, conforme apresentado na Seo 8.1.2;
- type: atributo opcional que define o tipo de mdia, especificado como
tipo MIME, conforme apresentado na Seo 8.1.3;
- descriptor: identificador (id) do descritor que controla a apresentao do
objeto de mdia;
- refer:
3
referncia a um outro n de mdia previamente definido, como
forma de reso de n (utiliza os atributos do n de mdia referenciado,
exceto o id). Esse atributo descrito na Seo 12.1;
- instance:
4
utilizado apenas quando o atributo refer definido. Pode
assumir os valores new, instSame e gradSame, conforme visto na
Seo 12.2.

3
O atributo refer definido no mdulo EntityReuse [ABNT. NBR 15606-2. 2011; ITU-T,
H.761, 2011].
199
8.1.2 O Atributo src
O atributo src define um URI do contedo do objeto. Um URI composto
de um esquema e uma parte especfica do esquema, como na Figura 8.1.
Esquema
Parte especfica
do esquema
http://www.telemidia.puc-rio.br/index.html

Figura 8.1 Sintaxe de um URI
O esquema especifica o protocolo a ser usado para a transferncia do
contedo, e sua parte especfica define o caminho para o contedo em um
dado servidor.
// servidor [:port] / url-caminho / #fragmento

Um URI absoluto contm todas as informaes necessrias para localizar
seu recurso. A NCL, no entanto, tambm permite o uso de URI relativo. URIs
relativos so endereos incompletos aplicados a um URI-base para completar
a localizao. As partes omitidas so o esquema do URI, o servidor e,
tambm, em alguns casos, parte do caminho.
O benefcio principal da utilizao de URIs relativos a possibilidade de
mover ou copiar para outros locais os documentos e diretrios contidos no
URI, sem exigir a troca dos valores dos atributos referindo-se ao URI dentro
dos documentos. Apenas o URI-base mudaria de valor. Isso especialmente
interessante quando se transportam documentos de provedores de contedo
para os receptores. Os caminhos relativos do URI so tipicamente utilizados
como um meio rpido de localizao de arquivos de mdia armazenados no
mesmo diretrio do documento NCL atual ou em um diretrio prximo a ele.
Quando o arquivo est localizado no mesmo diretrio do documento NCL
atual, o caminho relativo consiste apenas no nome do arquivo (incluindo,
opcionalmente, um identificador de fragmento dentro do arquivo). Um
caminho relativo tambm pode trazer um caminho de diretrios antes do nome
do arquivo, especificando o caminhar desde o diretrio do documento NCL
atual at o arquivo em questo que se deseja localizar.

4
O atributo instance definido no mdulo ExtendedEntityReuse [ABNT, NBR 15606-2,
2011; ITU-T, H.761, 2011].
200

Os seguintes URIs so definidos pelo Sistema Brasileiro de TV Digital
terrestre:
- arquivos locais:
file:///caminho_arquivo/#id_fragmento
- arquivos remotos baixados do canal de interatividade utilizando o
protocolo http:
http://id_servidor/caminho_arquivo/#id_fragmento
- arquivos remotos baixados do canal de interatividade utilizando o
protocolo https:
https://id_servidor/caminho_arquivo/#id_fragmento
- streams baixados do canal de interatividade utilizando o protocolo rtsp:
rtsp://id_servidor/caminho_arquivo/#id_fragmento
- streams baixados do canal de interatividade utilizando o protocolo rtp:
rtp://id_servidor/caminho_arquivo/#id_fragmento
- streams recebidos como fluxos elementares no fluxo de transporte;
5

sbtvd-ts://program_number.component_tag
- fluxo de contedo idntico a um fluxo que esteja em apresentao por
um outro objeto de mdia:
ncl-mirror://identificador (id) do objeto de mdia
Note que, nesse ltimo caso, o objeto que referencia ter contedo
idntico e ser apresentado sempre no mesmo ponto de exibio do
objeto referenciado.
Para objetos de mdia com o atributo src, cujo valor identifica o esquema
sbtvd-ts, a parte especfica do esquema, mais precisamente, o
program_number.component_tag, pode ser substitudo pelas seguintes
palavras reservadas:

5
Streams recebidos como fluxos elementares do fluxo de transporte TS podem vir entrelaados. Por
exemplo, o contedo de uma propaganda pode vir em um mesmo fluxo elementar entremeado com o fluxo de
um filme. Em um mesmo fluxo elementar, um stream de um mesmo contedo de um objeto de mdia
identificado por seu contentId (ver Apndice E). Todo objeto de mdia tem uma propriedade (propriedades
so discutidas no Captulo 9) que contm o valor do contentID de um stream. Esse valor adquirido pelo
sistema (por exemplo, o middleware Ginga-NCL) do fluxo de transporte, to logo o objeto instanciado para
apresentao.
201

video Correspondente ao vdeo ES principal que est sendo
apresentado no plano de vdeo, conforme definido pela ABNT
NBR 15604.
audio Correspondente ao udio ES principal, conforme definido pela
ABNT NBR 15604
text Correspondente ao texto ES principal, conforme definido pela
ABNT NBR 15604
video(i) Correspondente ao i-simo menor vdeo ES component-tag
listado na PMT dos servios sintonizados.
audio(i) Correspondente ao i-simo menor udio ES component-tag
text(i) Correspondente ao i-simo menor texto ES component-tag
8.1.3 O Atributo type
Como mencionamos, o atributo type opcional. Quando um objeto de
mdia inicia sua apresentao, o formatador NCL escolhe a ferramenta de
exibio conforme a propriedade player do objeto de mdia a ser exibido. Se
esse atributo no for especificado, o formatador deve levar em conta o
atributo type do elemento <media>. Se esse atributo tambm no for
especificado, o formatador deve considerar a extenso do arquivo
especificado no atributo src do elemento <media>.
Os valores permitidos para o atributo type dependem do perfil NCL e
devem obrigatoriamente seguir o formato MIME Media Types (ou,
simplesmente, mimetypes). Um mimetype uma cadeia de caracteres que
define a classe da mdia (udio, vdeo, imagem, texto, aplicao) e um tipo de
codificao de mdia (como jpeg, mpeg etc.). Os mimetypes podem ser
registrados ou informais. Os mimetypes registrados so controlados pela
IANA (Internet Assigned Numbers Authority). Os mimetypes informais no
so registrados pela IANA, mas so definidos de comum acordo; eles
normalmente tm x ou vnd antes do nome do tipo de mdia. A Tabela 8.1
apresenta alguns tipos MIMES. Cabe ao sistema de TV digital definir seus
tipos obrigatrios e opcionais; em ABNT, NBR 15606-1, 2011 podem ser
encontrados os tipos definidos pelo SBTVD.
202
Tabela 8.1 Alguns Tipos MIMES
Valor de type Extenso de Arquivo do Atributo src
text/html .htm, .html, .xhtml
text/css .css
text/xml .xml
text/plain .txt
image/bmp .bmp
image/png .png
image/gif .gif
image/jpeg .jpg, .jpeg, .jpe
audio/basic .ua
audio/x-wav .wav
audio/mpeg .mp1, .mp2, .mp3
audio/mpeg4 .mp4, .mpg4
video/mpeg .mp2, .mpeg, .mpg, .mpe
video/mp4 .mp4, .mpg4
video/x-mng .mng
video/quicktime .qt, .mov
video/x-msvideo .avi
application/x-ginga-ncl, ou
application/x-ncl-NCL
.ncl
application/x-ginga-NCLua, ou
application/x-ncl-NCLua
.lua
application/x-ginga-NCLet .xlt, .xlet, .class
application/x-ginga-settings,
ou
application/x-ncl-settings
6

No tem arquivo associado (no se define
o atributo src). Tambm chamado de n
ou objeto settings, um objeto que define
atributos globais para ser utilizado em
regras e em relacionamentos
application/x-ginga-time, ou
application/x-ncl-time
O atributo src define a hora de acordo com
a Universal Time Coordinated (UTC)

6
O n do tipo settings descrito em detalhes na Seo 9.3.
203
Pela Tabela 8.1, cinco tipos especiais so definidos para objetos de mdia.
Objetos de mdia do tipo application/x-ginga-NCL, ou application/x-ncl-
NCL, tm como contedo um documento especificado em NCL, ou seja,
cdigo NCL. Esses objetos so assunto do Captulo 14. Objetos de mdia do
tipo application/x-ginga-NCLua, ou application/x-ncl-NCLua, tm como
contedo cdigo Lua, assunto dos Captulos 17 e 18; j objetos de mdia do
tipo application/x-ginga-NCLet, ou application/x-ncl-NCLet, tm como
contedo cdigo imperativo Java. Objetos imperativos assunto do Captulo
17. O objeto de mdia do tipo application/x-ginga-settings, ou
application/x-ncl-settings, nico em um documento NCL, define atributos
globais e assunto da Seo 9.3.
O tipo application/x-ginga-time, ou application/x-ncl-time, aplicado
a um elemento <media> especial cujo contedo o Universal Time
Coordinated (UTC). S pode existir um objeto de mdia com esse tipo em um
documento NCL. Seu contedo segue a seguinte sintaxe:
Ano:Ms:Dia:Hora:Minuto:Segundo.Frao,
onde Ano um inteiro, Ms um inteiro no intervalo [1,12], Dia um inteiro
no intervalo [1,31], Hora um inteiro no intervalo [0, 23], Minuto um
inteiro no intervalo [0,59], Segundo um inteiro no intervalo [0,59] e Frao
um inteiro positivo. Chamamos a ateno para o fato desse objeto de mdia
especificar um tempo absoluto, independentemente do incio de exibio do
objeto de mdia ou da aplicao NCL.
Podemos definir um cronmetro numa aplicao NCL utilizando um
elemento <media> sem fonte, que define uma espcie de relgio relativo ao
tempo de incio desse elemento <media>.
8.2 Contextos
Um contexto agrupa objetos (de mdia, de contexto ou switch)
7
e elos. O
elemento <body> de toda aplicao NCL um caso particular de contexto
que representa a aplicao como um todo.
Os demais contextos de uma aplicao NCL so definidos pelo elemento
<context>. Um contexto pode aninhar outros contextos ou switches, mas
existe uma restrio: um contexto no pode conter recursivamente a si
mesmo. Os contextos podem ser aninhados, por exemplo, para refletir a
estrutura do documento e ajudar o autor a organizar os segmentos da
aplicao. Um contexto (elemento <context>) definido conforme o modelo
da Listagem 8.1.
204
<context id=ctxNome>



...
</context>
Listagem 8.1 Esquema de definio de contexto.
Suponha uma aplicao NCL instrucional que tenha, alm do vdeo
principal, um menu que d acesso a uma entrevista com o diretor do vdeo,
um portflio com a biografia dos atores e um quizz sobre o contedo do
vdeo. Essas diferentes partes da aplicao podem ser estruturadas em
diferentes contextos, conforme a Listagem 8.2.
<body>
...
<context id=menu> ... </context>
<context id=entrevista>
<context id=protagonista> ... </context>
<context id=coadjuvante1> ... </context>
</context>
<context id=biografias> ... </context>
<context id=quizz> ... </context>
...
</body>
Listagem 8.2 Programa estruturado em contextos.
Os atributos de um contexto so:
- id: identificador nico do contexto, que segue a mesma regra de
formao para o atributo id definida no Captulo 5;
- refer:
7
referncia a um outro contexto previamente definido (utiliza
os atributos e elementos filhos do contexto referenciado, exceto o
atributo id); O atributo refer descrito no Captulo 13.
Um contexto encapsula os objetos e elos que contm. Sendo assim, para
acessar um objeto dentro de um contexto, necessrio definir portas no
contexto que mapeiem para os objetos que se deseja acessar, conforme
descrito na prxima seo.

7
O atributo refer definido no mdulo EntityReuse [ABNT, NBR 15606-2, 2007; ITU-T,
H.761 ,2009].
205
8.3 Portas
Uma porta <port> um ponto de interface de um contexto que oferece
acesso externo ao contedo (objetos internos) do contexto.
8
Em outras
palavras, para um elo ser ligado a um objeto interno ao contexto, esse
contexto deve possuir uma porta que mapeie o objeto interno desejado,
conforme ilustrado pela Figura 8.2.
body
video1
pVideo1
Legenda:
Ci contexto
Mi n
porta
mapeamento

Figura 8.2 Porta pVideo1 como ponto de entrada a um n video1 interno a um
contexto.
Observe que, na Figura 8.2, a porta pVideo1 do contexto <body>
mapeia para o vdeo video1. Isso significa que, ao iniciar a execuo do
documento, o formatador seguir a porta pVideo1, que leva ao n de
contedo video1, que ser ento apresentado.
Uma porta possui os seguintes atributos:
- id: identificador nico da porta, utilizado nas referncias porta (por
exemplo, por elos), que segue a mesma regra de formao para o
atributo id definida no Captulo 5;
- component: objeto de mdia ou contexto ao qual a porta mapeia;
- interface: nome do ponto de interface de destino. Caso o valor de
component seja um objeto de mdia, o valor de interface deve ser o
identificador de uma ncora (de contedo ou propriedade) do objeto;
9

caso component seja um contexto, o valor de interface deve ser o
identificador de uma porta do contexto (Figura 8.3). Caso no seja

8
Portas e seus atributos so definidos no mdulo CompositeNodeInterface [ABNT, NBR 15606-2,
2007; ITU-T, H.761, 2009].
9
ncoras so definidas no Captulo 9.
206
especificada, a interface se refere ao objeto de destino como um todo
(ncora de contedo total).
body
ctxMenu
img1
pMenu
Legenda:
Ci contexto
Mi n
porta
mapeamento
pImg1

Figura 8.3 Exemplo de portas e contextos, definidos na Listagem 8.3.
<body>
<port id=pMenu component=ctxMenu interface=pImg1 />
<context id=ctxMenu>
<port id= pImg1 component= img1 />
...
</context>
...
</body>
Listagem 8.3 Exemplo de portas e contextos.
Em todo documento costuma haver pelo menos uma porta de entrada
(elemento <port> dentro do <body>), indicando qual o objeto de mdia ou
contexto inicial. Caso se queira iniciar mais do que uma mdia no incio da
exibio de um contexto, podemos criar mais portas, tal como no exemplo a
seguir:
<body>
...
</body>
Observe que esse exemplo indica apenas que as mdias videoPrincipal e
imgInteratividade sero iniciadas ao mesmo tempo com o incio da
exibio do documento, mas no implica que as mdias terminaro ao mesmo
207
tempo. Para sincronizar o trmino de apresentao de objetos, necessrio
definir um ou mais elos, conforme visto no Captulo 10.
8.4 Referncia Rpida Mdias, Contextos e
Portas
A Tabela 8.2 sumariza os atributos e contedo dos elementos <media>,
<context> e <port> definidos pelo perfil NCL EDTV. Como sempre, os
atributos sublinhados so obrigatrios.
Tabela 8.2 Elementos, Atributos e Contedo que Definem Ns de Mdia, Contextos e Portas
no Perfil EDTV
Elemento
s
Atributos Contedo
media id, src, type, descriptor,
refer, instance
(area | property)*
context id, refer (port|property|media|context|link
|switch|meta|metadata)*
port id, component, interface
Bibliografia

208
Captulo
9

ncoras de Contedo
e
Propriedades
Este captulo apresenta ncoras de contedo e propriedades.
1
As primeiras
delimitam trechos de mdias que podem ser utilizados por elos para um
sincronismo mais fino do que a mdia inteira. J as propriedades permitem
que os elos manipulem propriedades dos ns durante a execuo da aplicao.
Ao final deste captulo, voc ser capaz de definir diferentes janelas de
oportunidade para sincronismo e interao em diferentes momentos de
apresentao de uma mesma mdia, bem como definir propriedades de objetos
de mdia, que podero ser alteradas por elos, como sua posio e suas
dimenses, durante a execuo da aplicao.

1
ncoras de contedo e propriedades, bem como seus atributos, so definidos nos mdulos
MediaContentAnchor e PropertyAnchor, respectivamente ABNT, NBR 15606-2, 2011 e ITU-T, H.761,
2011.
209
9.1 ncoras de Contedo
Uma ncora de contedo define um trecho da mdia (intervalo de tempo,
regio no espao ou ambos) como uma interface que poder ser utilizada
como ponto de ativao ou ao de elos. Um trecho de mdia um conjunto
de unidades de informao (information units) contguas de um objeto. A
definio dessas unidades de informao depende do tipo de mdia. As
unidades de informao de um vdeo, por exemplo, podem ser os quadros
(frames) do vdeo. Para definir um trecho de uma mdia dinmica como um
vdeo, por exemplo, uma ncora define geralmente o perodo de tempo, em
segundos, que delimita um trecho do vdeo desejado. Alternativamente, pode
definir um trecho do vdeo atravs de um intervalo de quadros.
As ncoras de contedo so utilizadas comumente para sincronizar mdias,
bem como para delimitar uma janela de interao, que , na verdade, uma
sincronizao, mas com a interveno do usurio. Uma ncora de contedo
definida como um elemento <area> dentro do elemento <media>.
<media ...>
<area ... />
<area ... />
...
...
</media>
Na Listagem 9.1, so definidas trs ncoras de contedo para um n de
vdeo.
<media id=video1 src=media/video1.mpg descriptor=dVideo1>

<area id=a1 begin=5s end=9s />
</media>
Listagem 9.1 Definio de ncoras de contedo em uma mdia do tipo vdeo.
Na viso estrutural, as ncoras so ilustradas por pontos de interface em
um objeto de mdia, conforme ilustrado pela Figura 9.1.
videoPrincipal
a1
a2
a3

Figura 9.1 ncoras de uma mdia na viso estrutural.
210
A NCL define os seguintes atributos de ncora de contedo:
- id: identificador nico, obrigatrio, da ncora, que segue a mesma regra
de formao para o atributo id definida no Captulo 5;
- begin: incio da ncora de uma mdia contnua. Pode ser definido em
segundos, no formato 99.9s, ou no formato
Hora:Minuto:Segundo.Frao, onde Hora um inteiro no
intervalo [0,23], Minuto um inteiro no intervalo [0,59], Segundo um
inteiro no intervalo [0,59] e Frao um inteiro positivo;
- end: trmino da ncora de uma mdia contnua. Pode ser definido em
segundos, no formato 99.9s, ou no formato
Hora:Minuto:Segundo.Frao, onde Hora um inteiro no
intervalo [0,23], Minuto um inteiro no intervalo [0,59], Segundo um
inteiro no intervalo [0,59] e Frao um inteiro positivo;
2

- first: incio da ncora de uma mdia contnua. Pode ser definido em
quadros, no formato 32f, em amostras, no formato 32s ou em NPT
(Normal Play Time), no formato 32npt;
- last: trmino da ncora de uma mdia contnua. Pode ser definido em
quadros, no formato 32f, em amostras, no formato 32s ou em NPT
(Normal Play Time), no formato 32npt;
- beginText, endText: texto da ncora no arquivo de origem (atributo
vlido apenas para mdias de texto);
- beginPosition, endPosition: ocorrncia do texto (especificado pelo
atributo beginText, ou endText, respectivamente) da ncora no arquivo
de origem (atributo vlido apenas para mdias de texto);
- coords: coordenadas em pixels dos vrtices do polgono que determina a
ncora espacial (atributo vlido para mdias visuais), no formato
X1,Y1, X2,Y2,...,Xn,Yn;
- label: identificador da ncora no arquivo de origem, seguindo a
interpretao dada pela ferramenta de exibio.
- clip: identificador de um trecho de uma cadeia temporal de um objeto
hipermdia declarativo (apresentado no Captulo 14), seguindo a
interpretao dada pela ferramenta de exibio do objeto.

2
Para o elemento <media> do tipo application/x-ncl-time, os atributos begin e end devem ser
especificados de acordo com a seguinte sintaxe:
Ano:Ms:Dia:Hora:Minutos:Segundos.Frao
de acordo com a zona do tempo do pas. O formatador NCL responsvel por traduzir esse valor para um
valor correspondente de UTC.
211
Alguns valores default para os atributos do elemento <area> que definem
uma ncora de contedo so assumidos por um formatador NCL. Se o
atributo begin for definido, mas o atributo end no for especificado, o final
de toda a apresentao do contedo de mdia considerado como
encerramento da ncora. Por outro lado, se o atributo end for definido sem
uma definio explcita de begin, o incio de toda a apresentao do contedo
de mdia considerado como o incio da ncora. Comportamento semelhante
esperado com relao aos atributos first e last. Comportamento semelhante
tambm esperado com relao aos atributos beginText e endText. No caso
de um elemento <media> do tipo application/x-ncl-time, os atributos begin e
end devem obrigatoriamente ser especificados.
No NCM (ver Captulo 2), todo objeto de mdia ou de contexto tem uma
ncora de contedo representando o conjunto de todas as unidades de
informao que compem o contedo do objeto. Essa ncora chamada de
ncora de contedo total (whole-content anchor) e declarada por default
nos documentos NCL. Toda vez que um componente NCL referenciado sem
a especificao de uma de suas ncoras, a ncora de contedo total deve ser
assumida.
A Listagem 9.2 exemplifica trechos de cdigo NCL com a definio de
vrias ncoras de contedo para vrios objetos de mdia, algumas dessas
definies omitindo atributos para os quais so assumidos valores default
anteriormente mencionados.
<media id="film" type="video/mpeg" src="ginga.mp4" descriptor="vDesc">
<area id="anchor1" begin="10s" end="40s />
<area id="anchor2" first="100f" end="200f />
<area id="anchor3" begin="00:05:00.0 />
<area id="anchor4" end="1200f />
</media>

<media id="music" type="audio/mpeg" src="../media/samba.mp3"V
<area id="anchor5" end="50s />
<area id="anchor6" first="8000s" end="80000s />
</media>

<media id="lyrics" type="text/plain" src="../media/letra.txt"
descriptor="textoDesc">
<area id="anchor7" beginText="mulata" begingPosition="2
endText="mulata" endPosition="2/>
</media>

<media id="photo" type="image/jpg" src="noel.jpg" descriptor="iDesc">
<area id="anchor8" coords="10,100,110,100,110,200,10,200 />
</media>

<media id="time" type="application/x-ncl-time">
<area id="anchor9" begin="2009:05:21:15:00:00.0"
end="2009:05:21:15:30:00.0 />
</media>

<media id="animation" type="application/x-ncl-nclua"
src="animacao.lua" descriptor="animacaoDesc">
<area id="anchor10" label="danca />
</media>
Listagem 9.2 ncoras de contedo.
212
Para o objeto de mdia film foram definidas quatro ncoras. A ncora
anchor1 inicia a 10 segundos do incio de exibio do objeto de mdia
film e termina a 50 segundos desse incio. A ncora anchor2
semelhante, e inicia em 100 quadros e termina em 200 quadros. J a ncora
anchor3 inicia a 5 minutos do incio do objeto de mdia film e termina
apenas quando o objeto de mdia termina de exibir todo o seu contedo. E a
ncora anchor4, por sua vez, inicia com o incio de exibio do objeto de
mdia film e termina a 1.200 quadros do incio dessa exibio.
O objeto de mdia music define duas ncoras: anchor5, de 0 a 50
segundos, e anchor6, de 8.000 a 80.000 amostras do arquivo de udio.
Para o objeto de mdia lyrics, a anchor7 foi definida para a segunda
ocorrncia do texto mulata. Por exemplo, a ncora seria definida para a
palavra indicada em negrito no seguinte exemplo de contedo do objeto
lyrics.
Ai, mulata assanhada
Que passa com graa
Fazendo pirraa
Fingindo inocente
Tirando o sossego da gente

Ai, mulata se eu pudesse
E se meu dinheiro desse
Eu te dava sem pensar
Essa terra, este cu, este mar
E ela finge que no sabe
Que tem feitio no olhar
No caso do objeto de mdia photo, a ncora anchor8 definida por
coordenadas na tela. Essa definio de ncora por coordenadas til para
dispositivos com apontador ou tela de toque.
O objeto de mdia time define a ncora anchor9 como iniciando s 15
horas do dia 21 de maio de 2009 e terminando meia hora depois. Podemos
observar que, como ocorre em todos os objetos de mdia, a ncora s tem
efeito caso o objeto de mdia tenha sido iniciado.
Finalmente, o objeto de mdia animation define a ncora anchor10
como sendo identificada pelo rtulo danca. Cabe ao objeto imperativo
213
animacao.lua tratar os eventos disparados sobre essa ncora, como ser
visto no Captulo 17.
9.2 Propriedades
As ncoras de propriedade ou simplesmente propriedades definem
propriedades ou grupos de propriedades de um objeto de mdia ou de contexto
como interfaces que podero ser manipuladas pelos elos. Diversas
propriedades dos objetos de mdia podem ser manipuladas por elos (por
exemplo: volume de udio de um objeto de udio, coordenadas e dimenses de
exibio de um objeto de mdia visual, grau de transparncia etc.). Algumas
propriedades, no entanto, como o identificador do objeto de mdia, no podem
ser alteradas.
A NCL define os seguintes atributos de ncora de propriedade:
- name: nome da propriedade ou grupo de propriedades;
- value: valor inicial atribudo propriedade ou grupo de
propriedades;
- externable: valor booleano que define se a propriedade visvel
para relacionamentos ou no.
O atributo value de um elemento <property> opcional e define um valor
inicial para a propriedade declarada como name. Quando o valor no
especificado, a propriedade assume como valor inicial aquele definido nos
atributos homnimos do descritor ou regio associados ao objeto onde a
propriedade foi definida. Quando o atributo value especificado, ele tem
prioridade sobre o valor definido nos atributos homnimos do descritor ou
regio associados ao n.
Todas as propriedades (e seus valores iniciais) de um objeto NCL podem
ser definidas apenas pelos seus elementos <property>. Os elementos
<descriptor>, <descriptorParam> e <region> so apenas uma opo a mais
(opo de reso) para a definio dos valores iniciais das propriedades.
possvel ter exibidores de documentos NCL (formatadores) que definam
algumas propriedades de ns implicitamente. Entretanto, em geral, de boa
prtica definir explicitamente as interfaces a serem manipuladas, por
segurana. Pela especificao do Ginga-NCL [ABNT, NBR 15606-2, 2011;
ITU-T, H.761, 2011], todas as interfaces que forem manipuladas por elos
devem ser explicitamente definidas por meio de elementos <property> com o
atributo externable igual a true. Quando uma propriedade definida por
meio dos elementos <descriptor>, <descriptorParam> e <region> o atributo
externable recebe o valor false por default. Quando uma propriedade
214
definida por meio do elemento <property> o atributo externable recebe o
valor true por default, se no declarado.
Os elementos <body>, <context> e <media> podem ter vrias propriedades
embutidas (pr-definidas). Exemplos dessas propriedades so: top, left,
bottom, right, width, height, plan, explicitDur, background,
transparency, visible, fit, scroll, style, soundLevel, balanceLevel,
trebleLevel, bassLevel, fontColor, fontFamily, fontStyle, fontSize,
fontVariant, fontWeight, reusePlayer, playerLife etc..
Se as propriedades left, right, top, bottom, width ou height de um
objeto de mdia tiverem seus valores definidos em percentagem (%) em
elementos <property>, as percentagens se referem ao tamanho da tela do
dispositivo onde o objeto de mdia ser exibido.
Para propriedades relativas a objetos de mdia do tipo udio (soundLevel,
trebleLevel e bassLevel), os vaores definidos em elementos <property>
devem ser entendidos como relativos ao volume gravado.
A propriedade visible tambm pode ser associada a um elemento
<context> ou ao elemento <body>. Nesses casos, quando a propriedade tiver
seu valor igual a true, vale a especificao de visible de cada objeto filho
da composio. Quando tiver o seu valor igual a false, todos os elementos
da composio so exibidos de forma invisvel.
3

Algumas propriedades tm o seu valor definido pelo prprio sistema (por
exemplo, o middleware Ginga-NCL), como a propriedade contentId,
4

associada a um objeto de mdia contnua cujo contedo se refere a um fluxo
elementar. Inicialmente, contentId tem o valor nulo, mas assim que o objeto
iniciado contentId assume o valor do identificador (contido no campo
tambm chamado contentId) transportado no descritor de referncia NPT (ver
Apndice E). Outro exemplo de propriedade manipulada pelo sistema a
standby. Essa propriedade assume o valor true enquanto um objeto de
mdia contnua, j iniciado e cujo contedo se refere a um fluxo elementar,
estiver com seu contedo temporariamente interrompido por outro contedo
entrelaado no mesmo fluxo elementar. Lembramos que, mesmo quando uma
propriedade definida de forma embutida, se for utilizada em um

3
Em particular, quando um documento tem seu elemento <body> com a propriedade visible =
false e seu evento de apresentao (ver Captulo 10) no estado=paused, diz-se que a aplicao est em
espera (stand-by). No middleware Ginga-NCL, quando uma aplicao entra em stand-by, o vdeo
principal do servio volta a ocupar 100% da dimenso da tela em que exibido e o udio principal a 100%
de seu volume.
4
No Captulo 8 mencionamos, tambm como nota, essa propriedade, descrita em detalhes no
Apndice E. Relembrando o captulo anterior, streams recebidos como fluxos elementares do fluxo de
transporte TS podem vir entrelaados. Por exemplo, o contedo de uma propaganda pode vir em um mesmo
fluxo elementar entremeado com o fluxo de um filme. Em um mesmo fluxo elementar, um stream de um
mesmo contedo de um objeto de mdia identificado por seu contentId.
215
relacionamento (elo), ela deve ser explicitamente declarada em um elemento
<property>.
Um grupo de propriedades de um objeto tambm pode ser explicitamente
declarado como uma nica interface para o objeto, isto , um nico elemento
<property>. Isso permite que os autores especifiquem o valor de vrias
propriedades com uma propriedade nica. Os seguintes grupos so
reconhecidos por qualquer formatador em conformidade com a NCL:
location, agrupando (left, top), nessa ordem; size, agrupando (width,
height), nessa ordem; e bounds, agrupando (left, top, width, height), nessa
ordem. Quando um formatador trata uma alterao no valor de um grupo de
propriedades, ele testa a consistncia do processo apenas ao seu final.
As palavras top, left, bottom, right, width, height, plan,
baseDeviceRegion, deviceClass, explicitDur, background, transparency,
visible, rgbCromakey, fit, scroll, style, soundLevel, balanceLevel,
trebleLevel, bassLevel, zIndex, fontColor, fontFamily, fontStyle, fontSize,
fontAlign, fontVariant, fontWeight, player, reusePlayer, playerLife,
moveLeft, moveRight, moveUp, moveDown, focusIndex, focusBorderColor,
selBorderColor, focusBorderWidth, focusBorderTransparency, focusSrc,
focusSelSrc, freeze, transIn, transOut, location, size e bounds so palavras
reservadas para valores do atributo name do elemento <property>. Seus
significados so definidos nos Captulos 6 e 7, e seus valores default so
dados na Tabela 9.1
Tabela 9.1 Alguns nomes reservados para propriedades e seus valores default
Propriedade Default
top, left, bottom, right,
width, height
Se qualquer valor dessas propriedades no for
definido e no puder ser inferido das regras
definidas pela especificao NCL, ele deve
obrigatoriamente assumir o valor 0.
location Veja primeira linha da tabela
size Veja primeira linha da tabela
bounds Veja primeira linha da tabela
plan
video,para objeto de mdia com o atributo
src referindo um PES de um fluxo TS,
graphic, para todos os outros casos.
baseDeviceRegion No existe default.
deviceClass A mesma classe de dispositivo que executa o
216
formatador NCL.
explicitDur
Para mdias contnuas deve assumer o valor da
durao da apresentao natural do contedo,
caso contrrio deve assumir o valor nill
background transparent
visible true
transparency 0%
rgbChromakey nill
fit fill
scroll none
style nill
soundLevel, trebleLevel,
bassLevel
1
balanceLevel 0
zIndex 0
fontColor white
fontAlign left
fontFamily
fontStyle normal
fontSize No existe default.
fontVariant normal
fontWeight normal
player No existe default.
reusePlayer false
playerLife close
moveLeft, moveRight,
moveUp, moveDown,
focusIndex
nill
focusBorderColor O valor definido por default.focusBorderColor
selBorderColor O valor definido por default.selBorderColor
focusBorderWidth O valor definido por default.focusBorderWidth
217
focusBorderTransparency
O valor definido por
default.focusTransparency
focusSrc, focusSelSrc nill
freeze false
transIn, transOut string vazia
Note que o valor inicial de uma propriedade de um objeto de mdia pode ser
definido em um elemento <region> associado ao objeto, em um elemento
<descriptor> (ou em seu elemento filho <descriptorParam> associado ao
objeto) ou em um elemento <property> definido como filho do elemento
<media> que define esse objeto. No caso de o valor inicial ser atribudo por
mais de uma forma, o valor definido no elemento <property> tem precedncia
sobre o valor definido pelo <descriptor> (ou pelo <descriptorParam>) que,
por sua vez, tem precedncia sobre o valor definido no elemento <region>.
A Listagem 9.3 define quatro propriedades para um n de vdeo, alm de
uma ncora de contedo. As duas primeiras propriedades assumem como
valores iniciais aqueles especificados pelos atributos do mesmo nome do
elemento <region> ao qual o objeto videoPrincipal est associado. A
terceira propriedade especifica o valor inicial de 200 pixels para o atributo
width e 100 pixels para o atributo height, mesmo que tenham sido
atribudos outros valores iniciais por meio de um elemento <region>
associado ao objeto videoPrincipal ou por meio de um elemento
<descriptorParam> filho do elemento <descriptor> dVideo1. A quarta
propriedade define uma nova propriedade rate com o valor inicial igual a
15.
<media id=videoPrincipal src=media/video1.mpg descriptor=dVideo1>

<property name=top />
<property name=left />
<property name=size value=200,100 />
<property name=rate value=15 />


<area id=aVideo1Imagem1 begin=3s end=8s />
</media>
Listagem 9.3 ncoras de propriedade e de contedo.
218
9.3 Objeto de Mdia do Tipo
application/x-ncl-settings
Como vimos no Captulo 9, existe um objeto de mdia especial definido com o
tipo application/x-ncl-settings, tambm chamado de objeto settings. Esse
tipo de objeto utilizado para agrupar propriedades globais definidas pelo
autor do documento e variveis de ambiente (tambm chamadas de variveis
de contexto) reservadas.
A Listagem 9.4 ilustra a definio de um objeto settings com duas
propriedades. A propriedade system.language, mantida pelo formatador
NCL, especifica o idioma para o qual a apresentao ser feita. J a
propriedade interaction definida pelo autor do documento, nesse caso para
indicar se a interatividade permitida (valor true) ou no (valor false).
Podemos observar que a interatividade permitida inicialmente, conforme
indicado pelo atributo value=true. A definio de um valor para o atributo
value equivale a definir um valor default para a propriedade.
<media id=nodeSettings type=application/x-ncl-settings>
<property name=system.language />
<property name=interaction value=true />
</media>
Listagem 9.4 N settings com duas propriedades que podem ser manipuladas pela
aplicao.
Devemos novamente observar que um documento NCL pode conter apenas
um objeto do tipo settings.
9.4 Variveis de Ambiente
O middleware Ginga define diversas variveis de ambiente, que funcionam
como propriedades com diferentes escopos e tipos de acesso. Alguns tipos de
variveis de ambiente podem ter seus valores alterados por aplicaes NCL;
outros, apenas lidos. As variveis de ambiente so divididas em seis grupos:
- system: variveis gerenciadas pelo sistema receptor. Elas podem ser
lidas, mas no podem ter seus valores alterados por uma aplicao NCL,
nem por um procedimento Lua nem por um procedimento Xlet. As
aplicaes nativas do receptor podem alterar os valores dessas variveis.
Os valores dessas variveis devem persistir por todo o ciclo de vida do
receptor. Essas variveis tm o prefixo system., como por exemplo
system.language;
219
- user: variveis gerenciadas pelo sistema receptor. Elas podem ser lidas,
mas no podem ter seus valores alterados por uma aplicao NCL, nem
por um procedimento Lua nem por um procedimento Xlet. As aplicaes
nativas do receptor podem alterar os valores dessas variveis. Os valores
dessas variveis devem persistir por todo o ciclo de vida do receptor.
Essas variveis tm o prefixo user., como por exemplo
user.location;
- default: variveis gerenciadas pelo sistema receptor. Elas podem ser
lidas e ter seus valores alterados por uma aplicao NCL, por um
procedimento Lua ou por um procedimento Xlet. As aplicaes nativas
do receptor podem alterar os valores dessas variveis. Os valores dessas
variveis devem persistir por todo o ciclo de vida do receptor. No
entanto, a cada troca de canal, os valores dessas variveis retornam aos
seus valores iniciais. Essas variveis tm o prefixo default., como por
exemplo default.focusBorderColor;
- service: variveis gerenciadas pelo formatador NCL. Elas podem ser
lidas e, em geral, ter seus valores alterados por uma aplicao NCL do
mesmo servio. Elas podem apenas ser lidas por um procedimento Lua
ou por um procedimento Xlet do mesmo servio. As modificaes sobre
os valores devem ser feitas atravs de comandos NCL. Os valores devem
persistir por todo o ciclo de vida do servio. Essas variveis tm o
prefixo service., como por exemplo service.currentFocus;
- SI: variveis gerenciadas pelo middleware Ginga. Elas podem ser lidas,
mas no podem ter seus valores alterados por uma aplicao NCL, nem
por um procedimento Lua nem por um procedimento Xlet. Os valores
dessas variveis persistem durante todo o tempo de sintonia de um canal.
Essas variveis tm o prefixo si., como por exemplo
si.channelNumber;
- channel: variveis gerenciadas pelo formatador NCL. Elas podem ser
lidas e ter seus valores alterados por uma aplicao NCL do mesmo
canal. Elas podem apenas ser lidas por um procedimento Lua ou por um
procedimento Xlet do mesmo canal. As modificaes sobre os valores
devem ser feitas atravs de comandos NCL. Os valores devem persistir
at a prxima troca de canal. Essas variveis tm o prefixo channel.;
- shared: variveis gerenciadas pelo formatador NCL. Elas podem ser
lidas e ter seus valores alterados por uma aplicao NCL. Elas podem
apenas ser lidas por um procedimento Lua ou por um procedimento Xlet
do mesmo canal. As modificaes sobre os valores devem ser feitas
220
atravs de comandos NCL. Os valores dessas variveis devem persistir
por todo o ciclo de vida do servio que as definiu. Essas variveis tm o
prefixo shared..
A Tabela 9.2 descreve o significado e os valores possveis das variveis de
ambiente do grupo system no middleware Ginga-NCL.
Tabela 9.2 Variveis de Ambiente do Grupo system
Varivel Significado Valores possveis
system.language Idioma do udio
Valores definidos
pela ISO 639-1
system.caption Idioma do closed caption
Valores definidos
pela ISO 639-1
system.subtitle Idioma das legendas (subtitle)
Valores definidos
pela ISO 639-1
system.returnBitRate(i)
Taxa do canal interativo (i)
em Kbps
real
system.screenSize
Tamanho da tela do
dispositivo de exibio, em
linhas, pixels/linha, quando
uma classe no definida
(inteiro, inteiro)
system.screenGraphicSize
Resoluo configurada para o
plano grfico da tela do
dispositivo de exibio, em
(linhas, pixels/linha), quando
uma classe no definida
(inteiro, inteiro)
system.audioType
Tipo de udio do dispositivo
de exibio, quando uma
classe no definida
mono | stereo |
5.1
system.screenSize (i)
Tamanho da tela do
dispositivo (i) em (linhas,
pixels/linha)
(inteiro, inteiro)
system.screenGraphicSize(i)
Resoluo definida para o
plano grfico do dispositivo (i)
em (linhas, pixels/linha)
(inteiro, inteiro)
system.audioType(i)
Tipo de udio do dispositivo
(i)
mono | stereo |
5.1
system.devNumber(i)
Nmero de dispositivos de
exibio cadastrados na
classe (i)
inteiro
system.classType(i) Tipo da classe (i) (passive | ative)
221
system.parentDeviceRegion(i)
Identifica o element <region>
em uma outra <regionBase>
associada ao dispositivo pai
que cria o mapa de bits
enviado classe passiva (i);
nesta regio, o mapa de bits
tambm deve ser exibido
Cinco nmeros
separados por
vrgulas, cada um
seguindo as regras
de valores
associados para as
propriedades left,
top, width, height, e
zIndex,
respectivamente,
system.info(i)
Lista de exibidores de mdia
da classe (i) de dispositivos
de exibio
string
system.classNumber
Nmero de classes de
dispositivos de exibio
definidas
inteiro
system.CPU
Desempenho da CPU em
MIPS
real
system.memory
Espao de memria em
Mbytes
inteiro
system.operatingSystem Tipo do sistema operacional string
system.javaConfiguration
Tipo e verso da configurao
Java suportada pelo receptor
JVM
string
(tipo imediatamente
seguido da verso,
como por exemplo:
CLDC1.1)
system.javaProfile
Tipo e verso do perfil Java
suportado pelo receptor JVM
string
(tipo imediatamente
seguido da verso,
como por exemplo:
MIDP2.0)
system.luaVersion
Verso da mquina Lua
suportada pelo receptor
string
system.ncl.version Verso da linguagem NCL string
system.GingaNCL.version
Verso do ambiente Ginga-
NCL
string
system.xxx
Qualquer varivel com o prefixo system deve ser
reservada para uso futuro
ambiente do grupo user no middleware Ginga-NCL.
222
Tabela 9.3 Variveis de Ambiente do Grupo user
Varivel Significado Valores
possveis
user.age Idade do usurio inteiro
user.location Localizao do usurio (cdigo de
endereamento postal)
string
user.genre Sexo do usurio m | f
user.xxx Qualquer varivel com o prefixo user deve ser reservada para
uso futuro
ambiente do grupo default no middleware Ginga-NCL.
Tabela 9.4 Variveis de Ambiente do Grupo default
Varivel Significado Valores possveis
default.focusBorderColor Cor default
aplicada
moldura de um
elemento em foco
white | black | silver |
gray | red | maroon |
fuchsia | purple | lime |
green | yellow | olive |
blue | navy | aqua |
teal
default.selBorderColor Cor default
aplicada
moldura de um
elemento em foco
ao ser ativado
white | black | silver |
gray | red | maroon |
fuchsia | purple | lime |
green | yellow | olive |
blue | navy | aqua |
teal
default.focusBorderWidth Largura default
(em pixels)
aplicada
moldura de um
elemento em foco
integer
default.focusBorderTransparency Transparncia
default aplicada
moldura de um
elemento em foco
valor real entre 0 e 1 (p. ex.,
0.3), ou valor real entre 0
e100 seguido do caractere
% (p. ex., 30%), onde
1 e 100% significam
transparncia total e 0 e
0% significam nenhuma
transparncia
default.xxx Qualquer varivel com o prefixo default deve
ser reservada para uso futuro
ambiente do grupo service no middleware Ginga-NCL.
223
Tabela 9.5 Variveis de Ambiente do Grupo service
possveis
service.currentFocus O valor de focusIndex do elemento
<media> em foco
inteiro
service.currentKeyMaster Identificador (id) do elemento <media>
que controla as teclas de navegao; caso
esse elemento <media> no esteja em
pausa, o controle das navegaes por
teclas pertence ao formatador NCL
string
service.xxx Qualquer varivel com o prefixo service deve ser
ambiente do grupo si no middleware Ginga-NCL.
Tabela 9.6 Variveis de Ambiente do Grupo SI
possveis
si.numberOfServices Nmero de servios disponveis, no
pas, para o canal sintonizado
inteiro
si.numberOfPartialService
s
Nmero de servios 1-seg disponveis,
no pas, para o canal sintonizado
inteiro
si.channelNumber Nmero do canal sintonizado inteiro
si.xxx Qualquer varivel com o prefixo si deve ser
ambiente do grupo channel no middleware Ginga-NCL.
Tabela 9.7 Variveis de Ambiente do Grupo channel
possveis
channel.keyCapture
Requisio de teclas alfanumricas
por aplicaes NCL
string
channel.virtualKeyboard
Requisio do teclado virtual por
aplicaes NCL
(true | false)
channel.keyboardBounds
Regio de exibio do teclado virtual
(left, top, width, height)
(inteiro, inteiro,
inteiro, inteiro)
channel.xxx
Qualquer varivel com o prefixo channel deve ser
224
9.5 Referncia Rpida ncoras de Contedo e
Propriedades
A Tabela 9.8 apresenta o elemento e os atributos que definem ncoras de
contedo e propriedades. Como sempre, ao atributos sublinhados so
obrigatrios.
Tabela 9.8 Elemento e Atributos que Definem ncoras de Contedo e Propriedades no
Perfil EDTV
area id, coords, begin, end,
beginText, beginPosition,
endText, endPosition first, last,
label, clip

property name, value, externable
Bibliografia

225
Captulo
10

Sincronizao:
Conectores e Elos
Este captulo apresenta os elos e conectores
1
que definem o sincronismo e, em
particular, a interatividade entre os objetos de uma aplicao NCL. Ao final
deste captulo, voc estar apto a criar aplicaes com diversos
comportamentos de sincronismo entre objetos, tais como iniciar um objeto
quando outro terminar, iniciar um objeto junto com o incio de outro, terminar
um objeto junto com outro, exibir um objeto de mdia quando uma tecla
pressionada pelo usurio, redimensionar um objeto de mdia quando outro
iniciado, entre outros.

1
Elos e seus atributos so definidos no mdulo Linking, ao passo que conectores e seus atributos so
definidos no mdulo ConnectorBase [ABNT, NBR 15606-2, 2011; ITU-T, H.761, 2011].
226
10.1 Introduo
Um elo (elemento <link>) associa objetos por meio de um conector (elemento
<causalConnector>), que define a semntica da associao. Os elos so
definidos como descendentes do elemento <body>, ao passo que os conectores
so definidos numa base de conectores (elemento <connectorBase>) filha do
elemento <head> da aplicao NCL. Este captulo detalha os elementos filhos
e atributos de conectores de sincronismo de apresentao, de interatividade,
de manipulao de propriedades, bem como os elementos e atributos de elos.
10.2 Base de Conectores
Os conectores so definidos em uma base de conectores (elemento
<connectorBase>), que contm como nico atributo o identificador (atributo
id) da base. Uma base de conectores pode possuir os seguintes elementos
filhos:
<causalConnector>: define um conector propriamente dito, conforme
descrito na prxima seo;
<importBase>: permite importar uma base de conectores de um outro
arquivo. Esse elemento descrito no Captulo 12, sobre reso em
aplicaes NCL.
Sendo assim, uma base de conectores pode ser definida conforme a seguinte
estrutura:
<connectorBase id=meusConectores>
<importBase ... />
<importBase ... />

<causalConnector id=onBeginStart>
...
</causalConnector>
<causalConnector id=___>
...
</causalConnector>
</connectorBase>
10.3 Conectores
Como apresentado na Parte I deste livro, em NCL o sincronismo no feito
por marcas de tempo (timestamps), mas sim por relaes de causalidade
227
definidas nos conectores (connectors).
2
Um elemento <causalConnector>
representa uma relao causal que pode ser utilizada por elementos <link> na
definio de relacionamentos entre objetos. Em uma relao causal, uma
condio deve ser satisfeita para que aes possam ser disparadas. Um
<causalConnector> especifica, atravs de seus elementos filhos, um conjunto
de pontos da interface, chamados papis (role), conforme ilustrado pela
Figura 10.1.
condio ao
<causal
Connector>
role role

Figura 10.1 Ilustrao de um conector causal (elemento <causalConnector>) com papis
(role) de condio e ao.
Um elemento <link> refere-se a um <causalConnector> e define um
conjunto de mapeamentos (elementos <bind> filhos do elemento <link>), que
associam interfaces de objetos de uma aplicao NCL a um papel do conector
utilizado, conforme ilustrado pela Figura 10.2.

role role

condio ao
<causal
Connector>
role role

objeto objeto
<bind> <bind>
<link>

Figura 10.2 Ilustrao de elo (elemento <link>).

2
Bases de conectores, conectores e seus atributos so especificados nos mdulos ConnectorBase,
ConnectorCommonPart, CausalConnector, CausalConnectorFunctionality, ConnectorCausal-
Expression, ConnectorAssessmentExpression e ConnectorTransitionAssessment [ABNT, NBR
15606-2, 2011; ITU-T, H.761, 2011].
228
Os elementos filhos de um <causalConnector> so:
<connectorParam>: define parmetros de conector cujos valores
devero ser definidos pelos elos que utilizam o conector;
<simpleCondition> e <compoundCondition>: definem as condies
simples ou compostas de ativao do elo que utiliza o conector;
<simpleAction> e <compoundAction>: definem as aes simples ou
compostas que so realizadas quando o elo que utiliza o conector
ativado.
Podemos definir um conector bastante simples para iniciar uma mdia junto
com outra, como o conector onBeginStart ilustrado na Figura 10.3 e
definido pela Listagem 10.1.
connector
onBegin
Start
start
on
Begin

role

Figura 10.3 Conector onBeginStart, que define o comportamento: quando a mdia
associada ao papel onBegin iniciar, a mdia associada ao papel start tambm iniciar.
<simpleCondition role=onBegin />
<simpleAction role=start />
</causalConnector>
Listagem 10.1 Definio do conector onBeginStart.
Na Listagem 10.1, o conector define a condio (<simpleCondition>) sob a
qual o elo pode ser ativado e a ao (<simpleAction>) que ser realizada
quando o elo for ativado. Um conector deve possuir pelo menos uma condio
e uma ao. Cada condio ou ao associada a um papel (role).
Em geral, o comportamento de um conector pode ser lido do seguinte
modo: quando condio/evento, ento ao. Por exemplo, no caso do
conector onBeginStart da Listagem 10.1, lemos: quando <algum objeto
ligado ao papel onBegin> iniciar, inicia tambm <algum objeto ligado ao
papel start>. Frisando mais uma vez, o conector define os papis de
condio e ao (p. ex., iniciar, terminar) e seu comportamento; cabe aos elos
ligar objetos a esses papis.
229
Os nomes dos papis onBegin e start fazem parte de um conjunto de
papis predefinidos, cujo comportamento interpretado corretamente por um
formatador NCL, como o implementado pelo middleware Ginga-NCL. Por
convenincia, para cada condio ou ao que pode ser definida num conector
pode existir um nome de papel predefinido reconhecido pelo formatador NCL.
A Tabela 10.1 apresenta os papis de condio predefinidos e a Tabela 10.2
apresenta os papis predefinidos de ao que devem ser reconhecidos por
qualquer formatador NCL.
Tabela 10.1 Papis Predefinidos de Condio
Papel Descrio (Quando o Elo Ser Ativado)
onBegin Quando a apresentao for iniciada...
onEnd Quando a apresentao for terminada
(naturalmente ou por uma ao stop)...
onAbort Quando a apresentao for abortada...
onPause Quando a apresentao for pausada...
onResume Quando a apresentao for retomada aps uma
pausa...
onSelection
ou
onBeginSelection
Quando uma tecla (a ser especificada) for
pressionada enquanto o objeto ligado a esse papel
estiver sendo apresentado ou quando a tecla OK
for pressionada enquanto o objeto ligado a esse
papel estiver com o foco, ou quando um
dispositivo apontador, por exemplo o mouse,
selecionar o objeto em apresentao ligado a esse
papel...
onEndSelection Quando uma tecla (a ser especificada) terminar de
ser pressionada enquanto o objeto ligado a esse
papel estiver sendo apresentado ou quando a tecla
OK terminar de ser pressionada enquanto o objeto
ligado a esse papel estiver com o foco, ou quando
um dispositivo apontador, por exemplo o mouse,
terminar a seleo do objeto em apresentao
ligado a esse papel...
onBeginAttribution Logo antes que um valor (a ser especificado) seja
atribudo a propriedades ligadas a esse papel...
onEndAttribution Logo aps um valor (a ser especificado) ter sido
atribudo a propriedades ligadas a esse papel...
onAbortAttribution Quando a atribuio for abortada...
onPauseAttribution Quando a atribuio for pausada...
onResumeAttribution Quando a atribuio for retomada aps uma
pausa...
230
Tabela 10.2 Papis Predefinidos de Ao
Papel Descrio (Ao a Ser Realizada Quando o Elo for
Ativado)
start ... inicia a apresentao dos objetos associados a esse
papel
stop ... termina a apresentao dos objetos associados a
esse papel
abort ... aborta a apresentao dos objetos associados a
esse papel
pause ... pausa a apresentao do objeto associados a esse
papel
resume ... retoma a apresentao do objeto associados a esse
papel (caso esteja em pausa)
set ... estabelece um valor (a ser especificado) s
propriedades associadas a esse papel
startAttribution ... inicia a atribuio de um valor (a ser especificado)
s propriedades associadas a esse papel
stopAttribution ... termina a atribuio
abortAttribution ... aborta a atribuio
pauseAttribution ... pausa a atribuio
resumeAttribution ... retoma a atribuio
Mais precisamente, as relaes definidas por elementos <causalConnector>
so baseadas em eventos. Um evento uma ocorrncia no tempo que pode ser
instantnea ou ter durao mensurvel.
A NCL, em sua verso 3.0, define os seguintes tipos de eventos:
- evento de apresentao: apresentao de um subconjunto das unidades de
informao (ncora de contedo) de um objeto de mdia. Um caso
particular a ncora de contedo total (ver Captulo 9). Eventos de
apresentao tambm podem ser definidos sobre ns de composio
(representados por um elemento <body>, <context> ou <switch>),
representando a apresentao das unidades de informao de qualquer n
dentro do n de composio;
- evento de seleo: seleo de um subconjunto das unidades de informao
(ncora de contedo) de um objeto de mdia sendo apresentado e visvel;
231
- evento de atribuio: atribuio de um valor a uma propriedade de um
objeto, que deve ser declarada explicitamente em um elemento <property>,
filho do objeto;
- evento de composio: apresentao da estrutura de um n de composio
(representado por um elemento <body>, <context> ou <switch>). Os
eventos de composio so utilizados para apresentar o mapa da
composio (organizao da composio). Essa funcionalidade opcional
no perfil EDTV e BDTV.
Cada evento define uma mquina de estados controlada pelo formatador
NCL, apresentado na Figura 10.4

paused
sleeping occurring
resume
stop | abort
pause
stop| natural end
abort
start

Figura 10.4 Mquina de estados de eventos.
Voltando aos papis predefinidos: os papis de condio onBegin,
onEnd, onAbort, onPause e onResume, assim como os papis de
ao start, stop, abort, pause e resume esto relacionados s
possveis transies de estados de eventos de apresentao de ncoras de
contedo, conforme ilustrado na Figura 10.4.
Os papis de condio onSelection, onBeginSelection
onEndSelection esto relacionados s possveis transies de estados de
eventos de seleo de ncoras de contedo. Eles so ligados interatividade,
realizada por meio de dispositivos de entrada, como o controle remoto da TV;
vamos deixar sua discusso especfica para a Seo 10.5. J os papis de
condio onBeginAttribution, onEndAttribution, onAbortAttribution,
onPauseAttribution e onResumeAttribution, bem como os papis de ao
set, startAttribution, stopAttribution, abortAttribution,
pauseAttribution e resumeAttributionesto relacionados aos eventos de
atribuio, isto , manipulao de valores de propriedades; vamos deixar
sua discusso especfica para a Seo 10.8.
232
O papel (atributo role) apenas um dos atributos de uma condio, mas
existem outros atributos. A NCL define os seguintes atributos do elemento
<simpleCondition>:
role: nome do papel. atributo obrigatrio e deve ser nico dentro de
um conector. Como dissemos, por convenincia, utilizamos com
frequncia um dos papis de condio predefinidos, como os descritos
na Tabela 10.1;
delay: tempo decorrido entre a condio ser verdadeira e o elo ser
ativado, em segundos, e no formato 9s, tendo como valor default
0s;
eventType: tipo de evento associado ao papel da condio. Pode
assumir o valor presentation (para eventos de apresentao),
selection (para seleo, p. ex., atravs de teclas) ou attribution
(para eventos de atribuio de valor). Caso o valor do atributo role
seja um dos valores predefinidos na Tabela 10.1, esse atributo
assume um valor default, como apresentado na Tabela 10.3.
transition: transio na mquina de estados. Pode assumir os
valores: starts, stops, aborts, pauses ou resumes,
conforme a mquina de eventos de um objeto. Caso o valor do
atributo role seja um dos valores predefinidos na Tabela 10.1, esse
atributo assume um valor default, como apresentado na Tabela 10.3;
Tabela 10.3 Valores de atributos eventType e transition assumidos por default quando o
atributo role usa palavras reservadas em uma condio
Valor de role Valor de transition
Valor de
eventType
onBegin starts presentation
onEnd stops presentation
onAbort aborts presentation
onPause pauses presentation
onResume resumes presentation
onSelection starts selection
onBeginSelection starts selection
onEndSelection stops selection
onBeginAttribution starts attribution
onEndAttribution stops attribution
onAbortAttribution aborts attribution
onPauseAttribution pauses attribution
onResumeAttribution resumes attribution
233
key: cdigo da tecla do controle remoto que ativa o elo, no caso de
eventType selection. Pode assumir um dos seguintes valores: 0,
1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E,
F, G, H, I, J, K, L, M, N, O, P, Q, R,
S, T, U, V, W, X, Y, Z, *, #, MENU,
INFO, GUIDE, CURSOR_DOWN, CURSOR_LEFT,
CURSOR_RIGHT, CURSOR_UP, CHANNEL_DOWN,
CHANNEL_UP, VOLUME_DOWN, VOLUME_UP,
ENTER, RED, GREEN, YELLOW, BLUE, BACK,
EXIT, POWER, REWIND, STOP, EJECT, PLAY,
RECORD, PAUSE;
min: cardinalidade mnima do papel, ou seja, o nmero mnimo de
interfaces
3
de objetos que devem ser associadas a esse papel no elo
que o utilize. O default 1;
max: cardinalidade mxima do papel, ou seja, o nmero mximo de
interfaces de objetos que devem ser associadas a esse papel no elo
que o utilize. Caso no haja limite no nmero mximo de interfaces
que podem ser associadas ao papel, deve assumir o valor
unbounded. O default 1;
qualifier: define se todas as condies devem ser satisfeitas por todas
as interfaces ligadas ao papel (valor and) ou se basta que qualquer
uma delas seja satisfeita (valor or). Esse atributo s tem efeito
quando a cardinalidade mxima do papel maior do que 1. O default
or.
Tambm para as aes, o papel apenas um de seus atributos. A NCL
define os seguintes atributos do elemento <simpleAction>:
role: nome do papel. Deve ser nico dentro de um conector. Como
dissemos, por convenincia, utilizamos com frequncia um dos papis
de ao predefinidos, como os descritos na Tabela 10.2;
delay: tempo decorrido entre a ativao do elo e o disparo da ao,
em segundos, e no formato 9s. O default 0s;
eventType: tipo de evento associado ao papel da ao. Pode assumir
o valor presentation (para eventos de apresentao), selection

3
At agora definimos as ncoras de contedo e as propriedades como interfaces de um objeto de
mdia, e as portas e propriedades como interfaces de contextos. Como veremos em outros captulos, um
contexto tambm pode ter ncoras de contedo como interface (esse conceito ser extremamente til quando,
na Parte III, estudarmos objetos hipermdia declarativos). Como veremos no prximo captulo, um objeto
switch define ainda um outro tipo de interface, denominada portSwitch.
234
(para seleo, p. ex., atravs de teclas) ou attribution (para eventos
de atribuio de valor). Caso o valor do atributo role seja um dos
valores predefinidos na Tabela 10.2, esse atributo opcional. Esse
atributo assume valores por default, como apresentado na Tabela
10.4;
actionType: ao que causa uma transio na mquina de estados do
evento. Pode assumir os valores start, stop, abort, pause ou
resume. Caso o valor do atributo role seja um dos valores
predefinidos na Tabela 10.1, esse atributo assume valores por
default, como apresentado na Tabela 10.4.
Tabela 10.4 Valores de atributos eventType assumidos por default quando o atributo role
usa palavras reservadas em uma ao
Valor de role Valor de actionType Valor de eventType
start start presentation
stop stop presentation
abort abort presentation
pause pause presentation
resume resume presentation
set start attribution
startAttribution start attribution
stopAttribution stop attribution
abortAttribution abort attribution
pauseAttribution pause attribution
resumeAttribution resume attribution
value: valor a ser atribudo s propriedades associadas ao papel, caso
o valor de eventType seja attribution;
min: cardinalidade mnima do papel, ou seja, o nmero mnimo de
interfaces de objetos que devem ser associados a esse papel no elo
que o utilize. O default 1;
max: cardinalidade mxima do papel, ou seja, o nmero mximo de
interfaces de objetos que devem ser associados a esse papel no elo
que o utilize. Caso no haja um limite no nmero mximo de
interfaces de objetos que podem ser associadas ao papel, deve
assumir o valor unbounded. O default 1;
235
qualifier: define se as aes, em cada interface de objeto ligada ao
papel, devem ser disparadas em paralelo (valor par) ou em
sequncia (valor seq). Esse atributo s tem efeito quando a
cardinalidade mxima do papel maior do que 1. O default par;
repeat: esse atributo s vlido no caso de evento de apresentao e
no caso de a ao ser start. Ele define o nmero de vezes em que a
apresentao da ncora de contedo deve se repetir, com o intervalo
de repeatDelay segundos entre cada repetio. O valor default 0;
repeatDelay: tempo em segundos decorrido entre cada repetio da
ao, no formato 9s. Esse atributo s tem efeito quando o valor de
repeat maior que 0;
duration: tempo de durao de uma atribuio. O default 0, ou
seja, a atribuio feita instantaneamente. Caso o valor seja maior
que zero, o valor da propriedade gradualmente modificado at
chegar ao valor final, cujo incremento definido pelo atributo by;
by: incremento a cada passo de atribuio ao longo do tempo definido
por duration. Caso seja indefinite, a atribuio feita linear e
continuamente, conforme a implementao do formatador. Esse
atributo s tem efeito quando o atributo duration assume um valor
maior que zero.
Os atributos duration e by so utilizados para atingir efeitos de animao,
por exemplo, para mover ou redimensionar um objeto na tela gradualmente,
conforme detalhado na Seo 10.10.
Como mencionado, palavras reservadas para papis facilitam a definio
de conectores. No entanto, os papis de um conector no esto restritos
queles definidos por meio de palavras reservadas. Para definir um papel que
no tenha sido predefinido, necessrio definir um valor para o atributo
eventType.
No caso do elemento <simpleCondition>, necessrio definir tambm um
valor para o atributo transition. No caso do elemento <
attributeAssessment>, necessrio definir tambm um valor para o atributo
attributeType. J no caso do elemento <simpleAction>, necessrio definir
tambm um valor para o atributo actionType.
10.4 Elos
Um elo define o relacionamento de sincronismo propriamente dito entre
interfaces de objetos de uma aplicao NCL. Seu comportamento definido
pelo conector que o elo utiliza.
236
Para fazer a associao de interfaces de objetos com os papis de um
conector, um elo simplesmente utiliza elementos <bind> (ligao), conforme o
seguinte esquema:
<link xconnector=id_do_conector>
<bind role=id_de_papel_de_condicao
component=id_de_um_objeto
interface=id_de_uma_interface />
<bind role=id_de_papel_de_acao component=id_de_um_objeto
interface=id_de_uma_interface />
</link>
Como exemplo, a Figura 10.5 apresenta a viso estrutural correspondente a
um exemplo de sincronismo de incio de apresentao de objetos de mdia,
destacando o elo de sincronismo que deve iniciar a apresentao da mdia
imgInteratividade assim que a apresentao da mdia videoAbertura
comear.
onBeginStart
pVideoAbertura
body
videoAbertura
img-
Interatividade

Figura 10.5 Viso estrutural do exemplo, destacando o elo de sincronismo entre as mdias.
Na Figura 10.5, ao utilizar o conector, o elo associa a mdia
videoPrincipal (a ncora de contedo total assumida por default) ao papel
onBegin, e a mdia imgInteratividade (novamente com a ncora de
contedo total assumida por default) ao papel start, conforme ilustrado na
Figura 10.6 e pela Listagem 10.2. Como j mencionamos, os conectores so
definidos numa base de conectores (elemento <connectorBase> dentro da
seo <head>), ao passo que os elos so definidos no ncleo do documento
(dentro da seo do elemento <body> ou de algum contexto interno a ela).
237
video
Principal
img
Interatividade
connector
onBegin
Start
start
on
Begin

role role

Figura 10.6 Elo que utiliza o conector onBeginStart, ligando as mdias videoPrincipal
ao papel onBegin e imgInteratividade ao papel start do conector, respectivamente.
<link id=lVideoPrincInicia xconnector=onBeginStart>
<bind role=onBegin component=videoPrincipal />
<bind role=start component=imgInteratividade />
</link>
Listagem 10.2 Cdigo para definio de um elo que utiliza o conector onBeginStart para
sincronizar o incio das mdias videoPrincipal e imgInteratividade, utilizando o
connector definido na Figura 10.1
No caso da Listagem 10.2, podemos ler o elo como: Quando iniciar
(onBegin) a apresentao do videoPrincipal, inicia tambm (start) a
apresentao da imgInteratividade.
Analogamente, para sincronizar o trmino de apresentao das mdias,
podemos definir um conector onEndStop, utilizado por um segundo elo,
conforme indicado na Listagem 10.3.
<connectorBase>
<causalConnector id=onEndStop>
<simpleCondition role=onEnd />
<simpleAction role=stop />
</causalConnector>
</connectorBase>
... trecho da seo <head>
... trecho da seo <body>
<link id=lVideoPrincTermina xconnector=onEndStop>
<bind role=onEnd component=videoPrincipal />
<bind role=stop component=imgInteratividade />
</link>
Listagem 10.3 Cdigo para definio de um conector onEndStop e elo que o utiliza para
sincronizar o trmino das mdias videoPrincipal e imgInteratividade.
238
A NCL define os seguintes atributos de elo (elemento <link>):
- id: identificador nico do elo, que deve seguir a mesma regra de
formao para o atributo id definida no Captulo 5. Note que esse
atributo opcional;
- xconnector: atributo obrigatrio, identificador do conector
associado ao elo, que tambm deve seguir a mesma regra de
formao para o atributo id definida no Captulo 5.
A NCL define os seguintes elementos como filhos de num elemento <link>:
- <bind>: indica uma ligao entre a interface (interface) do
componente (component, objeto de mdia, de contexto ou switch) e
seu papel (role) no elo, conforme a semntica do conector. Um elo
pode conter diversos elementos <bind>, mas deve conter pelo menos
um <bind> para cada papel definido no conector.
- <linkParam>: define um parmetro do elo como um par
[propriedade, valor]. As propriedades e seus respectivos valores
dependem da definio do conector ao qual o elo est associado. Um
elo pode conter diversos elementos <linkParam>.
A Listagem 10.4 apresenta o cdigo completo de uma aplicao NCL que
sincroniza o incio e o trmino da apresentao das mdias videoPrincipal e
imgInteratividade.
<ncl id=exemplo xmlns=http://www.ncl.org.br/NCL3.0/EDTVProfile>
<head>
<regionBase>
<region id=rgTV>
</region>
</regionBase>
<descriptorBase>
<descriptor id=dTVtelaInteira region=rgTVtelaInteira />
explicitDur=4s>
</descriptor>
</descriptorBase>
<connectorBase>
239
</causalConnector>
<causalConnector id=onEndStop>
</causalConnector>
</connectorBase>
</head>
<body>
descriptor=dInteratividade/
<link id=lVideoPrincInicia xconnector=onBeginStart>
</link>
<link id=lVideoPrincTermina xconnector=onEndStop>
<bind role=onEnd component=videoPrincipal />
</link>
</body>
</ncl>
Listagem 10.4 Conector e elo para sincronizar o incio e o trmino de exibio de duas
mdias.
A Figura 10.7 apresenta a viso estrutural correspondente Listagem 10.4.
Na figura, rotulamos o elo com o identificador do conector por ele utilizado,
para evidenciar o comportamento do elo. Alm disso, as mdias que esto
ligadas a papis de condio ficam na origem do elo, ao passo que as mdias
ligadas a papis de ao ficam no destino do elo, conforme indicado pela
direo da seta.
onBeginStart
onEndStop
pVideoPrincipal
body
videoPrincipal
img-
Interatividade

Figura 10.7 Viso estrutural correspondente Listagem 10.4, com destaque nos elos de
sincronismo de incio e trmino de exibio das mdias.
240
A Figura 10.8 apresenta as vises temporal e espacial correspondentes
Listagem 10.4. Podemos observar na figura a indicao de que os elos de
sincronismo que garantem que a apresentao da mdia imgInteratividade
ser iniciada e concluda junto com a mdia videoPrincipal.
videoPrincipal

rgInteratividade
rgTelaInteira
viso espacial
viso temporal
imgInteratividade
videoPrincipal
onBeginStart onEndStop
imgInteratividade
elos de sincronismo:
conectores
onBeginStart e
onEndStop

Figura 10.8 Vises temporal e espacial correspondentes Listagem 10.4, que sincroniza o
incio e o trmino de exibio de duas mdias.
Damos a seguir mais alguns exemplos de definio de elos e conectores.
Exemplo 10.1 Sincronizando o Incio de Exibio de Objetos
de Mdia com um Retardo
Continuando o exemplo anterior, suponha agora que a imagem
imgInteratividade deva comear a ser exibida trs segundos aps o incio
do vdeo videoPrincipal. Na definio do conector, possvel definir um
retardo para a execuo de uma ao, ou seja, um perodo de tempo em
segundos que deve transcorrer aps a ativao do elo para que aquela ao
seja executada.
A Listagem 10.5 ilustra a definio de um conector com retardo fixo de trs
segundos, atravs do atributo delay do elemento <simpleAction>. Observe
241
que, no caso de uma durao de tempo, o valor do parmetro deve ser seguido
da letra s.
<connectorBase>
<causalConnector id=onBeginStartDelay3>
<simpleAction role=start delay=3s />
</causalConnector>
</connectorBase>
Listagem 10.5 Definio de conector com retardo fixo de trs segundos.
Apesar de esse conector produzir o efeito necessrio, ele especfico
apenas para o caso de retardos de trs segundos. Para que o conector possa
ser reaproveitado por mais elos, importante que o valor do retardo seja
informado pelo elo e no determinado pelo conector. Para contemplar esses
casos, a NCL permite definir um parmetro de conector (atravs do elemento
<connectorParam>), conforme ilustra a Listagem 10.6. Note que, para
utilizar o valor desse parmetro no atributo delay do elemento
<simpleAction>, ele deve ser precedido de um sinal de cifro.
<connectorBase>
<causalConnector id=onBeginStart_vDelayelay>
<connectorParam name=vDelay />
<simpleAction role=start delay=$vDelay />
</causalConnector>
</connectorBase>
Listagem 10.6 Definio de conector com retardo parametrizado.
O elo que utilizar o conector com retardo parametrizado precisa informar
qual o valor desejado para o retardo. Isso feito atravs do elemento
<linkParam>, conforme ilustrado pela Listagem 10.7. O valor do atributo
name deve ser o nome do parmetro tal como tiver sido definido no conector
atravs do atributo name do elemento <connectorParam>.
<link id=lVideoPrincipalInicia xconnector=onBeginStart_vDelay>
<linkParam name=vDelay value=3s />
</link>
Listagem 10.7 Definio de elo que informa ao conector o valor do retardo desejado.
A Figura 10.9 apresenta a viso estrutural desse exemplo, semelhante
viso estrutural do exemplo anterior, modificando apenas o rtulo do elo que
utiliza o conector com retardo.
242

Figura 10.9 Viso estrutural de uma aplicao que utiliza um conector com retardo.
As vises temporal e espacial deste exemplo so apresentadas na Figura
10.10.

videoPrincipal
1
videoPrincipal

rgInteratividade
rgTelaInteira
viso espacial
viso temporal
pVideoPrincipal
imgInteratividade
imgInteratividade
videoPrincipal
onBeginStartDelay onEndStop
3 seg
2
elos de sincronismo:
conectores
onBeginStartDelay
e onEndStop

Figura 10.10 Vises temporal e espacial do exemplo de conector que permite a uma mdia
ser iniciada com um retardo aps uma outra.
243
Exemplo 10.2 Ligando Diversos Objetos a um Mesmo Papel
Da forma como foi definido o conector do exemplo, o elo deve associar
apenas um objeto a cada papel. Muitas vezes, no entanto, necessrio
realizar um mesmo tipo de ao ou condio sobre diversos objetos. Suponha
que haja um outro objeto de mdia definido com o id imgImagem1 e ele
deva aparecer junto com a imgInteratividade. O conector deve ser
modificado para permitir a ligao de vrios objetos no papel de ao start,
e o elo deve criar mais uma ligao atravs do elemento <bind>, conforme
O atributo max indica o nmero mximo de ligaes para aquele papel,
cujo valor unbounded significa que o nmero de ligaes permitidas
ilimitado. J o atributo qualifier indica como devem ser acionados os objetos
ligados quele papel, em paralelo (valor par) ou sequencialmente (valor
seq).
No elo so definidas as ligaes para cada objeto que deve ser iniciado
quando o elo for ativado. Observe que, por causa da definio do retardo,
todos os objetos ligados ao papel start sero iniciados trs segundos aps a
ativao do elo.
<connectorBase>
<causalConnector id=onBeginStart_vDelay>
<connectorParam name=vDelay />
<simpleAction role=start delay=$vDelay
max=unbounded qualifier=par />
</causalConnector>
</connectorBase>
<bind role=start component=imgImagem1 />
</link>
Listagem 10.8 Redefinio de conector e elo para permitir a ligao de mais de uma mdia
num mesmo papel.
244
Exemplo 10.3 Passando Parmetros pelas Ligaes do Elo
No exemplo anterior, o valor de retardo informado ser utilizado por todos
os objetos ligados ao papel start. Muitas vezes, no entanto, necessrio
definir diferentes valores de retardo para cada objeto. Isso pode ser feito
atravs de parmetros das ligaes, definidos por elementos <bindParam> de
cada ligao <bind>:
- <bindParam>: define um parmetro especfico do <bind> como um
par [propriedade, valor]. As propriedades e seus respectivos valores
dependem da definio do conector ao qual o elo est associado.
Suponha que o objeto de mdia definido pelo id imgImagem1 deva ser
iniciado aps um retardo maior. Utilizando o elemento <bindParam>,
podemos definir um retardo diferente do default do elo para esse objeto de
mdia, conforme ilustrado pela Listagem 10.9.
<bind role=start component=imgImagem1>
<bindParam name=vDelay value=5s />
</bind>
</link>
Listagem 10.9 Diferentes valores de retardo informados por parmetros de elo e de ligao.
Nesse exemplo, os objetos de mdia iniciam, por default, trs segundos aps
a ativao do elo, conforme definido pelo parmetro de elo <linkParam>. O
objeto de mdia imgImagem1, no entanto, iniciado cinco segundos aps a
ativao do elo, conforme o valor de retardo definido atravs do parmetro da
ligao <bindParam>.
Observe que, caso um mesmo parmetro seja definido tanto por uma
ligao quanto por um elo, o valor definido pelo parmetro da ligao (no
elemento <bindParam>) tem prioridade sobre o parmetro de elo (no elemento
<linkParam>) homnimo.
A Tabela 10.5 sumariza os atributos e contedo dos elementos que definem
elos. Como sempre, os atributos obrigatrios esto sublinhados.
245
Tabela 10.5 Elementos, atributos e contedo que definem elos
link id, xconnector (linkParam*, bind+)
bind role, component, interface,
descriptor
(bindParam)*
bindParam name, value
linkParam name, value
A Listagem 10.10 apresenta um esqueleto de cdigo de definio do elo, com
todos os seus elementos filhos.
<body>
...
<link xconnector=___>
<linkParam name=___ value=___ />
<linkParam name=___ value=___ />

<bind role=___ component=___ interface=__>
<bindParam name=___ value=___ />
</bind>

<bind role=___ component=___ interface=__>
</bind>

<bind role=___ component=___ interface=__ />
<bind role=___ component=___ interface=__ />
</link>
...
</body>
Listagem 10.10 Esqueleto de cdigo de definio do elo.
10.5 Conectores e Elos de Interatividade
Os conectores apresentados at agora neste captulo no envolveram
interatividade, ou seja, a possibilidade de ao do usurio sobre a aplicao
principal caracterstica de programas de TV digital interativa. Conforme
246
visto na Tabela 10.1, o papel predefinido onSelection utilizado para esse
fim. Ao definir uma condio que utiliza esse papel, o conector pode definir
tambm o atributo key, que identifica o cdigo da tecla utilizada para acionar
os elos que utilizam o conector.
Exemplo 10.4 Exibindo um Objeto Quando o Usurio
Pressiona uma Tecla
Este exemplo define um conector e um elo para apresentar um objeto
quando o usurio pressiona uma determinada tecla. Suponha que haja um
objeto de mdia identificado por imgMenu (alm de seus respectivos
descritor e regio) representando um menu que deve ser apresentado quando o
telespectador pressionar a tecla vermelha (RED) do controle remoto,
enquanto o objeto imgInteratividade estiver sendo apresentado. Esse
comportamento pode ser ilustrado pela viso estrutural apresentada na Figura
10.11, considerando o nome do conector como onKeySelectionStart.

Figura 10.11 Viso estrutural do exemplo de conector de interatividade.
A Listagem 10.11 apresenta a definio do conector
onKeySelectionStart e um elo que o utiliza para fins do exemplo. Observe
que, assim como nos conectores que definimos anteriormente que disparam
uma ao com retardo, esse conector recebe o cdigo da tecla como
parmetro (denominado vKey), para propiciar seu reso.
<causalConnector id=onKeySelectionStart>
<connectorParam name=vKey />
<simpleCondition role=onSelection key=$vKey />
<simpleAction role=start max=unbounded qualifier=par />
</causalConnector>
247
<link xconnector=onKeySelectionStart>
<bind role=onSelection component=imgInteratividade>
<bindParam name=vKey value=RED />
</bind>
<bind role=start component=imgMenu />
</link>
Listagem 10.11 Conector e elo que apresentam objetos quando uma determinada tecla do
controle remoto acionada.
O fato de o papel onSelection estar associado ao objeto de mdia
imgInteratividade significa que o elo s est disponvel enquanto esse
objeto estiver sendo apresentado. Caso o usurio pressione a tecla vermelha
em outro momento, o elo no ser ativado e o objeto imgMenu no ser
apresentado. Esse mecanismo permite contextualizar a janela de oportunidade
de interao aos objetos do documento. A Figura 10.12 apresenta um
storyboard para ilustrar o comportamento do exemplo.
A aplicao apresenta apenas
videoPrincipal.

videoPrincipal

Mesmo que o usurio pressione a
tecla vermelha do controle remoto,
nada acontece.
videoPrincipal

Trs segundos aps o incio de
videoPrincipal,
imgInteratividade iniciada.
videoPrincipal
imgInteratividade

Se o usurio pressiona a tecla
vermelha agora, a aplicao exibe
imgMenu.
videoPrincipal
imgInteratividade
imgMenu

Figura 10.12 Storyboard do exemplo de utilizao do conector onKeySelectionStart.
248
A Tabela 10.6 apresenta os cdigos de tecla definidos pela linguagem NCL
e que podem ser utilizados como valores do atributo key.
Tabela 10.6 Cdigos de teclas definidos para uso em aplicaes NCL
Tipo de Tecla Cdigo
Numricas 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, #
Alfabticas A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U,
V, W, X, Y, Z
Guia de
programao
MENU, INFO, GUIDE
Setas CURSOR_LEFT, CURSOR_RIGHT, CURSOR_UP,
CURSOR_DOWN
Acionamento ENTER
Mudanas de canal CHANNEL_UP, CHANNEL_DOWN
Mudanas de
volume
VOLUME_UP, VOLUME_DOWN
Cores RED, GREEN, YELLOW, BLUE
Controle BACK, EXIT, POWER, REWIND, STOP, EJECT, PLAY,
RECORD, PAUSE

A Listagem 10.12apresenta o cdigo completo da aplicao NCL do
Exemplo 10.4, com destaque para o conector e o elo de interatividade.
<ncl id="exemplo" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="rgTV">
<region id="rgTVtelaInteira" />
<region id="rgInteratividade" right="20" top="20"
width="40" height="40" zIndex="3" />
<region id="rgMenu" zIndex="4" bottom="5" left="0"
width="1920" height="75 />
</region>
249
</regionBase>
<descriptorBase>
<descriptor id="dTVtelaInteira" region="rgTVtelaInteira" />
<descriptor id="dInteratividade" region="rgInteratividade"
explicitDur="4s">
<descriptorParam name="transparency" value="60%" />
</descriptor>
<descriptor id="dMenu" region="rgMenu" />
</descriptorBase>
<connectorBase>
<causalConnector id="onBeginStart_vDelay">
<connectorParam name="vDelay" />
<simpleCondition role="onBegin" />
<simpleAction role="start" delay="$vDelay"
max="unbounded" qualifier="par/>
</causalConnector>

<simpleCondition role="onEnd" />
<simpleAction role="stop" max="unbounded" qualifier="par/>
</causalConnector>

<causalConnector id="onKeySelectionStart">
<connectorParam name="vKey" />
<simpleCondition role="onSelection" key="$vKey" />
</causalConnector>
</connectorBase>
</head>
<body>
<port id="pVideoPrincipal" component="videoPrincipal />

<media id="videoPrincipal" src="media/principal.mpg"
descriptor="dTVtelaInteira" />
<media id="imgInteratividade" src="media/vermelhoI.png"
descriptor="dInteratividade />
<media id="imgMenu" src="media/menu.png" descriptor="dMenu" />

<link id="lVideoPrincipalInicia" xconnector="onBeginStart_vDelay">
<bind role="onBegin" component="videoPrincipal" />
<bind role="start" component="imgInteratividade">
<bindParam name="vDelay" value="3s" />
</bind>
</link>

<link xconnector=" onKeySelectionStart ">
250
<bind role="onSelection" component="imgInteratividade">
<bindParam name="vKey" value="RED" />
</bind>
<bind role="start" component="imgMenu" />
</link>

<link xconnector="onEndStop">
<bind role="onEnd" component="videoPrincipal" />
<bind role="stop" component="imgInteratividade" />
<bind role="stop" component="imgMenu" />
</link>
</body>
</ncl>
Listagem 10.12 Cdigo NCL de aplicao que exibe uma imagem de menu quando o
usurio pressiona a tecla vermelha do controle remoto.
10.6 Conectores com Mltiplas Aes e Condies
Os conectores apresentados at aqui envolvem apenas uma condio e uma
ao. No entanto, h ocasies em que, para uma mesma condio,
necessrio disparar dois ou mais tipos de aes diferentes, conforme ilustrado
pela Figura 10.13.

onKeySelection-
StartStop
role
onSelection
role start
role stop

Figura 10.13 Conector com mltiplos papis de ao, cada qual podendo ser associado a um
nmero indefinido de objetos (max=unbounded).
A Figura 10.14 ilustra o uso desse tipo de conector. Trata-se de uma
pequena alterao viso estrutural da Figura 10.11. Ao pressionar a tecla
vermelha (RED) do controle remoto, o elo no apenas inicia a apresentao
de imgMenu, mas tambm encerra a apresentao de imgInteratividade.
251

Figura 10.14 Viso estrutural com elo que utiliza um conector de aes compostas.
O elemento <compoundAction> permite definir mais do que uma ao num
mesmo conector, conforme especificado na Listagem 10.13. Esse elemento
possui um atributo operator, que define a ordem em que as aes que ele
contm so disparadas: em paralelo (par) ou em sequncia (seq). No caso
do conector deste exemplo, as aes so disparadas em paralelo. Alm disso,
diversos objetos podem ser ligados aos papis start e stop, devido
definio do atributo max com valor unbounded em cada ao.
<causalConnector id=onKeySelectionStartStop>
<connectorParam name=aKey />
<simpleCondition role=onSelection key=$aKey />
<compoundAction operator=par>
<simpleAction role=start max=unbounded operator=par/>
<simpleAction role=stop max=unbounded operator=par/>
</compoundAction>
</causalConnector>
<link xconnector="onKeySelectionStartStop">
</bind>
</link>
Listagem 10.13 Conector onKeySelectionStartStop e elo correspondente, ilustrando a
composio de aes.
252
A Listagem 10.14 apresenta o cdigo completo da aplicao NCL que utiliza
o conector onKeySelectionStartStop, com destaque para as linhas de
cdigo relevantes ao exemplo.
<ncl id="exemplo" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="rgTV">
<region id="rgTVtelaInteira" />
<region id="rgInteratividade" right="20" top="20"
width="40" height="40" zIndex="3" />
<region id="rgMenu" zIndex="4" bottom="5" left="0"
width="1920" height="75 />
</region>
</regionBase>
<descriptorBase>
<descriptor id="dTVtelaInteira" region="rgTVtelaInteira" />
<descriptor id="dInteratividade" region="rgInteratividade"
explicitDur="4s">
<descriptorParam name="transparency" value="60%" />
</descriptor>
<descriptor id="dMenu" region="rgMenu" />
</descriptorBase>
<connectorBase>
<causalConnector id="onBeginStart_vDelay">
<connectorParam name="vDelay" />
<simpleCondition role="onBegin" />
<simpleAction role="start" delay="$vDelay"
max="unbounded" qualifier="par />
</causalConnector>

<simpleCondition role="onEnd" />
<simpleAction role="stop" max="unbounded" qualifier="par />
</causalConnector>

<causalConnector id="onKeySelectionStartStop">
<compoundAction operator="par">
<simpleAction role="start"
max="unbounded" qualifier="par" />
<simpleAction role="stop"
max="unbounded" qualifier="par" />
</compoundAction>
</causalConnector>
253
</connectorBase>
</head>
<body>
<port id="pVideoPrincipal" component="videoPrincipal />

<media id="videoPrincipal" src="media/principal.mpg"
descriptor="dTVtelaInteira" />
<media id="imgInteratividade" src="media/vermelhoI.png"
descriptor="dInteratividade />
<media id="imgMenu" src="media/menu.png" descriptor="dMenu" />

<link id="lVideoPrincipalInicia" xconnector="onBeginStart_vDelay">
<bind role="onBegin" component="videoPrincipal" />
<bind role="start" component="imgInteratividade">
<bindParam name="vDelay" value="3s" />
</bind>
</link>

<link xconnector="onKeySelectionStartStop">
</bind>
</link>

<bind role="onEnd" component="videoPrincipal" />
<bind role="stop" component="imgMenu" />
</link>
</body>
</ncl>
Listagem 10.14 Cdigo NCL de aplicao que exibe uma imagem de menu e encerra a
imagem de interatividade quando o usurio pressiona a tecla vermelha do controle remoto.
Do mesmo modo, um conector pode definir mais do que uma condio. As
condies vistas at agora (onBegin, onEnd, onSelection) esto
relacionadas com a transio de um evento de apresentao ou de
interatividade. Alm dessas, possvel construir condies que testem o
estado de apresentao de um evento, atributos associados a eventos ou
valores de propriedades, como definido no Captulo 9. O elemento
<assessmentStatement> utilizado para fazer tais comparaes. A Figura
10.15 ilustra um conector que faz uso de mltiplos papis de condio.
254
onKeySelection-
NodeStateTest-
StartStop
role onSelection role start
role stop
and
role test

Figura 10.15 Conector com mltiplos papis de condio, ligados pelo operador and.
O elemento <assessmentStatement> possui dois tipos de elementos filhos:
<attributeAssessment>, que define um atributo cujo valor ser testado, e
<valueAssessment>, que define um valor a ser testado. O elemento
<assessmentStatement> possui ainda o atributo comparator, que define o
operador de comparao, conforme definido na Tabela 10.7. O valor de um
atributo definido pelo elemento <attributeAssessment> pode ser testado
contra o valor de outro atributo definido por outro elemento
<attributeAssessment> ou contra um valor definido pelo elemento
<valueAssessment>.
Tabela 10.7 Operadores de comparao que podem ser utilizados em elementos
<assessmentStatement>.
Valor Significado
eq igual a (equal to)
ne diferente de (not equal to)
gt maior que (greater than)
lt menor que (less than)
gte maior ou igual a (greater than or equal to)
lte menor ou igual a (less than or equal to)

O elemento <attributeAssessment> possui um atributo role cujo valor
deve ser nico no conjunto de papis do conector. Como normalmente ocorre,
um role um ponto de interface do conector, que associado s interfaces
dos objetos por um elemento <link> que referencia o conector. Um elemento
<attributeAssessment> tambm define um tipo de evento (atributo
eventType, podendo assumir os valores presentation, selection ou
attribution), que ter o valor de seu estado (state) ou de seus atributos
255
(occurrences ou repetitions)
4
comparados, conforme especificado pelo
atributo attributeType (que no caso pode ter como valor state,
occurrences ou repetitions). Se o eventType for attribution, o
attributeType opcional e pode ter tambm o valor nodeProperty
(default), indicando que uma propriedade do objeto deve ser avaliada. Se o
valor de eventType for selection (seleo), conveniente que o elemento
tambm defina a qual dispositivo de entrada a seleo se refere (por exemplo,
teclas de um teclado ou controle remoto), atravs do atributo key. Um valor
de compensao (offset) pode ser adicionado a um elemento
<attributeAssessment> antes da comparao (por exemplo, uma
compensao pode ser adicionada a uma avaliao de atributo para
especificar a posio vertical da tela mais 50 pixels).
O elemento <valueAssessment> tem um atributo value que deve
obrigatoriamente assumir um valor de estado de evento (sleeping,
occurring ou paused) ou um valor qualquer a ser comparado com uma
propriedade do objeto ou atributo de evento.
A Figura 10.16 ilustra a viso estrutural de uma aplicao que utiliza um
elo com condio composta, definido na Listagem 10.15.

Figura 10.16 Viso estrutural com elo que utiliza um conector com condio composta.
O conector, definido na Listagem 10.15, acionado apenas quando duas
condies so satisfeitas: 1) uma determinada tecla (identificada pelo
parmetro vKey) pressionada e 2) o estado de apresentao do objeto o

4
Os atributos occurrences e repetition informam quantas vezes um evento j ocorreu e
quantas vezes ele ainda dever ocorrer imediatamente aps o final da ocorrncia atual, respectivamente. Para
eventos de seleo, o atributo repetitions no definido.
256
estado desejado (identificado pelo parmetro vState). Observe que o
atributo operator do elemento <compoundCondition> que define se todas
as condies devem ser satisfeitas (operator= and) ou se apenas uma das
condies precisa ser satisfeita para acionar o elo (operator=or).
Os estados de apresentao de um objeto que podem ser testados com esse
conector so: occurring (em apresentao), paused (em pausa) ou
sleeping (parado). O elo ilustrado na Listagem 10.15 apresenta o objeto de
mdia imgMenu quando a tecla vermelha selecionada, mas apenas se o
objeto de mdia imgInteratividade estiver sendo apresentado. Sendo assim,
o comportamento semelhante ao do elo apresentado na Listagem 10.11. A
soluo ilustrada pela Listagem 10.11 a preferencial. No entanto, pode
haver casos em que um elo deve ser acionado apenas quando mais de uma
mdia estiver sendo apresentada. Nesses casos, a definio de um
<assessmentStatement> se faz necessria.
<causalConnector id=onKeySelection_and_NodeStateTestStartStop>
<connectorParam name=vState />
<compoundCondition operator=and>
<assessmentStatement comparator=eq>
<attributeAssessment role=test
eventType=presentation attributeType=state/>
<valueAssessment value=$vState />
</compoundAction>
</causalConnector>
<link xconnector=onKeySelection_and_NodeStateTestStartStop>
<bind role=onSelection component=videoPrincipal>
</bind>
<bind role=test component=imgInteratividade>
<bindParam name=vState value=occurring />
</bind>
<bind role=start component=imgMenu />
</link>
Listagem 10.15 Conector onKeySelection_and_NodeStateTestStartStop cujas duas
condies precisam ser verdadeiras para o elo correspondente ser acionado.
257
Do mesmo modo como as condies podem ser compostas, tambm as
clusulas de comparao podem ser compostas, atravs do elemento
<compoundStatement>, que pode conter diversos elementos
<assessmentStatement> e tambm outros elementos <compoundStatement>.
Exemplo 10.5 Exibindo um Vdeo em Loop at a Interveno
do Usurio
O objetivo deste exemplo exibir um vdeo em loop, permitindo ao usurio
interromper essa exibio pressionando a tecla azul (BLUE) do controle
remoto.
Para que um objeto de mdia contnua possa ser exibido em loop, pode-se
utilizar um conector onEndStart com o mesmo n de vdeo nos papis
onEnd e start. Para parar esse vdeo e iniciar o prximo, no entanto,
surge um problema. Caso seja utilizada a ao stop, o elo associado ao
conector onEndStart ser acionado novamente, e a exibio do primeiro
vdeo reiniciar. Para terminar a apresentao do vdeo sem acionar esse elo,
necessrio interromper o vdeo em loop utilizando a ao abort, que no
aciona os elos com mdias no papel onEnd.
Para que o usurio saiba qual a tecla que pode pressionar a cada instante,
importante que um objeto de mdia seja exibido indicando as oportunidades
de interao e o que ser feito. Nesse exemplo, exibida uma imagem
indicando que a tecla azul do controle remoto serve para interromper o loop e
parar o documento.
Para iniciar, terminar e abortar objetos quando uma tecla do controle
remoto selecionada, criamos um conector denominado
onKeySelectionAbortStop.
A Figura 10.17 apresenta a viso estrutural do exemplo e a Figura 10.18
apresenta a viso de leiaute.
body
onEndStart
video1
pVideo1
imgQuebraLoop
onBeginStart
onKeySelectionAbortStop
abort
stop

258
rgTelaInteira
rgTV
rgBotao

Figura 10.18 Viso de leiaute do Exemplo 10.5.
As vises temporal e espacial do Exemplo 10.5 so apresentadas na Figura
10.19.
rgTelaInteira
video1
pVideo1
onEndStart
elo de sincronismo:
conector onEndStart
rgBotao
imgQuebraLoop
onBeginStart
stop
elo de interao:
conector onKeySelectionAbortStop
abort
elo de sincronismo:
conector onBeginStart
video1
imgQuebraLoop
viso espacial
viso temporal

A Listagem 10.16 apresenta os conectores e elos do Exemplo 10.5, com
destaque aos trechos relacionados com o uso da ao abort.
259
<causalConnector id="onEndStart">
</causalConnector>

<causalConnector id="onKeySelectionAbortStop">
<compoundAction operator="par">
<simpleAction role="abort" />
<simpleAction role="stop" />
</compoundAction>
</causalConnector>
<link xconnector="onEndStart">
<bind component="video1" role="onEnd" />
<bind component="video1" role="start" />
</link>

<link xconnector="onKeySelectionAbortStop">
<bind component="imgQuebraLoop" role="onSelection">
<bindParam name="vKey" value="BLUE" />
</bind>
<bind component="video1" role="abort" />
<bind component="prog3" role="stop" />
</link>
Listagem 10.16 Conectores onEndStart e onKeySelectionAbortStop, o elo que mantm
o objeto video1 em loop e o elo que interrompe o objeto em loop.
10.7 Conectores que Definem Novos Papis
Como mencionamos na Seo 10.3, palavras reservadas para papis
facilitam a definio de conectores. No entanto, os papis de um conector no
esto restritos queles definidos por meio de palavras reservadas. Como
vimos naquela seo, para definir um papel que no tenha sido predefinido,
necessrio definir um valor para o atributo eventType.
No caso do elemento <simpleCondition>, necessrio definir tambm um
valor para o atributo transition. No caso do elemento
<attributeAssessment>, necessrio definir tambm um valor para o
atributo attributeType. J no caso do elemento <simpleAction>, necessrio
definir tambm um valor para o atributo actionType.
260
10.8 Conectores e Elos que Manipulam
Propriedades
Uma utilizao comum de propriedades ocorre quando uma mdia precisa
ser reposicionada ou redimensionada durante a execuo da aplicao. Para
alterar o valor de uma propriedade, definimos um conector que utiliza o papel
predefinido set.
De modo semelhante aos elos definidos com retardo ou tecla de ativao,
para tornar o conector mais til, o valor a ser atribudo definido como
parmetro do conector. A Listagem 10.17 apresenta o cdigo de um conector
que apresenta o seguinte comportamento: quando uma determinada tecla
pressionada, um ou mais objetos so redimensionados e um ou mais objetos
so apresentados.
<causalConnector id=onKeySelectionSet_vNewValueStartStop>
<connectorParam name=vNewValue />
<simpleAction role=set value=$vNewValue max=unbounded/>
<simpleAction role=start max=unbounded />
<simpleAction role=stop max=unbounded />
</compoundAction>
</causalConnector>
Listagem 10.17 Conector que manipula uma propriedade de n.
Para o elo fazer a ligao com uma propriedade de um n, necessrio que
o elemento <bind> defina, alm dos atributos role e component, o atributo
interface, para identificar a propriedade que se deseja alterar. Alm disso,
esse <bind> deve conter um parmetro (<bindParam>), que define o novo
valor a ser atribudo propriedade correspondente. A Listagem 10.18
apresenta um elo que acionado quando a tecla vermelha pressionada e,
quando isso acontece, redimensiona o objeto videoPrincipal e apresenta a
imagem imgFundo.
<link xconnector= onKeySelectionSet_vNewValueStartStop>
</bind>
<bind role=set component=videoPrincipal interface=left>
<bindParam name=vNewValue value=45% />
</bind>

261

<bind role=set component=videoPrincipal interface=top>
</bind>
<bind role=set component=videoPrincipal interface=width>
</bind>
<bind role=setcomponent=videoPrincipal interface=height>
</bind>
<bind role=start component=imgFundo />
</link>
Listagem 10.18 Elo que manipula propriedades de mdia.
A Figura 10.20 apresenta a viso estrutural que ilustra o conector e o elo
definidos nas Listagens 10.17 e 10.18.

Figura 10.20 Viso estrutural de aplicao que manipula o valor de diversas propriedades.
Observe que, assim como possvel manipular cada propriedade de
posio e dimenses separadamente, tambm possvel definir e manipular
em conjunto todos esses valores, atravs do grupo de propriedades bounds
(Listagem 10.19).
262
<media id=videoPrincipal src=media/video1.mpg descriptor=dVideo1>
<property name=bounds />
</media>
...
<link xconnector= onKeySelectionSet_vNewValueStartStop>
</bind>
<bind role=set component=videoPrincipal interface=bounds>
<bindParam name=vNewValue value=45%,30%,40%,40% />
</bind>
<bind role=start component=imgFundo />
</link>
Listagem 10.19 Elo que manipula posio e dimenses de uma mdia atravs da
propriedade bounds, bem como a mdia que define a propriedade.
A Figura 10.21 apresenta a viso estrutural que ilustra o conector e o elo
definidos nas Listagens 10.17 e 10.19.

Figura 10.21 Viso estrutural de aplicao que manipula um valor de um grupo de
propriedades.
Exemplo 10.6 Alternando a Visibilidade de Mdias
Vamos considerar agora uma situao em que h dois vdeos pr-gravados
e armazenados apresentando diferentes tomadas de uma mesma cena, como,
por exemplo, arquivos de vdeo curto cujo contedo corresponde a diferentes
cmeras em um jogo de futebol. Vamos considerar uma aplicao NCL que
permita ao usurio explorar o replay de uma jogada de melhores momentos
sob demanda, trazendo os arquivos de vdeo mencionados durante o jogo ou o
intervalo. A jogada do replay nica, mas h os dois arquivos de vdeo, cada
263
qual correspondendo a um ngulo do jogo. Para o usurio alternar entre os
diferentes vdeos, que correspondem s diferentes cmeras, no possvel
utilizar as aes de apresentao (p. ex., start/stop, pause/resume)
para mostrar um vdeo e ocultar o outro. A ao start inicia a apresentao
de uma mdia armazenada desde seu incio, e a ao resume inicia do ponto
em que foi feita a pausa no vdeo, e no do ponto em que est o outro vdeo.
Enfim, como no h nenhuma relao temporal entre os dois vdeos pr-
armazenados, necessrio manter os dois vdeos tocando em paralelo, mas
um deles deve permanecer oculto e sem som at que seja feita a troca.
O objetivo deste exemplo permitir ao usurio alternar entre dois vdeos,
atravs da seleo das teclas vermelha (RED) e verde (GREEN) do
controle remoto. Ambos os vdeos devem ser apresentados na mesma posio
da tela.
Os dois vdeos devem ser iniciados de forma sincronizada, sendo que um
deles deve iniciar invisvel e sem som. Quando o usurio fizer uma seleo
com as teclas do controle remoto, os valores das propriedades dos dois vdeos
devem ser invertidos. Quando o primeiro vdeo (video1) terminar, deve-se
ocultar as mdias ilustrando os botes e o segundo vdeo (video2).
Como sempre, importante apresentar para o usurio mdias que indiquem
as oportunidades de interao com o programa. Alm disso, apresentar para o
usurio uma opo de interatividade que de fato no produz efeito no uma
boa prtica de design, com relao usabilidade do programa. Sendo assim,
somente o boto que trocar o vdeo atual deve ser exibido.
As Figuras 10.22 a 10.26 ilustram a construo passo a passo da viso
estrutural do Exemplo 10.6.
replay
video1
video2
imgCamera1
imgCamera2
pVideo1
visible=false
soundLevel=0"

Figura 10.22 Exemplo 10.6, passo 1, contexto replay com as mdias, sendo que a porta
pVideo1 deve estar mapeada para video1, que o vdeo que deve tocar visvel e com
som inicialmente; video2 deve referenciar um descritor com visible=false e
soundLevel=0.
264
replay
video1
video2
imgCamera1
imgCamera2
pVideo1
onBeginStart
start
start

Figura 10.23 Exemplo 10.6, passo 2, elo para iniciar video2 e imgCamera2 assim que
video1 inicia, fazendo uso do conector onBeginStart.
replay
video1
video2
imgCamera1
imgCamera2
pVideo1
onBeginStart
start
start
onEndStop
stop
stop
stop

Figura 10.24 Exemplo 10.6, passo 3, elo para encerrar a apresentao de todas as mdias
quando video1 termina, fazendo uso do conector onEndStop.
265

Figura 10.25 Exemplo 10.6, passo 4, lo para trocar a visibilidade do video1 pela do
video2. Alm disso, troca o boto de cmera, de imgCamera2 para imgCamera1.

Figura 10.26 Exemplo 10.6, passo 5, elo anlogo ao anterior, desta vez para trocar a
visibilidade do video2 pela do video1. Alm disso, troca o boto de cmera, de
imgCamera1 para imgCamera2.
266
Podemos observar que foi utilizado o mesmo conector do exemplo anterior,
onKeySelectionSet_varStartStop.
A Figura 10.27 apresenta as vises temporal e espacial do Exemplo 10.6.
rgBotao
rgBotao
rgVideo1
video1
video2
imgCamera2
imgCamera1
onEndStop
pVideo1
viso espacial
viso temporal
onBeginStart
stop
video1
imgCamera2
video2
imgCamera1
onKeySelectionSetStartStop
onKeySelectionSetStartStop
stop

Figura 10.27 Vises temporal e espacial do Eemplo 10.6
Passo a passo
Passo 1: Criando novo descritor para o segundo vdeo
Como as duas mdias sero iniciadas ao mesmo tempo, mas com valores de
propriedades de visibilidade e som distintos, necessrio criar um descritor
diferente para o segundo vdeo, reusando a mesma regio de video1, mas
com os valores das propriedades correspondentes s definidas no seu
descritor, para que no haja som nem exibio no incio:
267
<descriptor id="dVideo2" region="rgVideo1">
<descriptorParam name="visible" value="false" />
<descriptorParam name="soundLevel" value="0" />
</descriptor>
Passo 2: Declarando as propriedades que sero manipuladas pelos elos
Para que seja possvel alterar as propriedades visible e soundLevel,
necessrio criar ncoras de propriedades nos ns de mdia correspondentes:
<media id="video1" src="media/video1.mpg" descriptor="dVideo1">
<property name="visible" />
<property name="soundLevel" />
</media>

<media id="video2" src="media/video2.mpg" descriptor="dVideo2">
<property name="visible" />
<property name="soundLevel" />
</media>
Passo 3: Criando os elos para manipular as propriedades, iniciar e parar
mdias
necessrio criar dois elos para efetuar a seleo do vdeo, atravs do
conector onKeySelectionSet_varStartStop. Esse conector utilizado para
trocar as propriedades de visibilidade e volume do som, trocando o vdeo
sendo exibido conforme o boto selecionado: o boto vermelho ativa o
video2 e o boto verde ativa o video1:

<link xconnector="meusConectores#onKeySelectionSet_varStartStop">
<bind component="imgCamera1" role="onSelection">
</bind>
<bind component="video1" interface="visible" role="set">
<bindParam name="var" value="true" />
</bind>
<bind component="video1" interface="soundLevel" role="set">
<bindParam name="var" value="1" />
</bind>
<bindParam name="var" value="false" />
</bind>
268
</bind>
<bind component="imgCamera2" role="start" />
<bind component="imgCamera1" role="stop" />
</link>

<link xconnector="meusConectores#onKeySelectionSet_varStartStop">
<bind component="imgCamera2" role="onSelection">
<bindParam name="vKey" value="GREEN" />
</bind>
<bindParam name="var" value="true" />
</bind>
</bind>
</bind>
</bind>
<bind component="imgCamera2" role="stop" />
</link>
Observamos que, como o elo deve alterar algumas propriedades dos ns de
vdeo, cada elemento de ligao (<bind>) deve especificar no apenas o
componente de destino do elo (atributo component), mas tambm a sua
propriedade (atravs do atributo interface), tal como definida no n da mdia.
Alm disso, como o valor dessa propriedade deve ser modificado, o novo
valor deve ser passado como parmetro (atravs do elemento <bindParam>):
</bind>
<bindParam name="var " value="0" />
</bind>
Passo 4: Modificando o elo para iniciar as mdias
Para informar o usurio sobre as oportunidades de interao, o elo de
exibio inicial do vdeo e dos botes deve exibir apenas a imagem do boto
269
vermelho, pois pressionar a tecla verde enquanto o video1 est tocando no
produz efeito:


<link id="lVideo_Botoes_start" xconnector="connectors#onBeginStart">
<bind component="video1" role="onBegin" />
<bind component="video2" role="start" />
</link>
Exemplo 10.7 Interrompendo uma Aplicao NCL no Caso de
Vdeos Entrelaados no Fluxo Elementar
Como apresentado nos Captulos 8 e 9 e detalhado no Apndice E,
possvel que haja vdeos entrelaados em um mesmo fluxo elementar.
Suponha uma aplicao NCL idApl associada a um filme pagu, que
interrompido por uma propaganda. possvel que a aplicao NCL esteja
exibindo algum outro objeto de mdia sobre o vdeo pagu no momento dessa
interrupo. A aplicao deve ser pausada e tornada invisvel, at que a
propaganda acabe. Ao trmino da propaganda, o filme pagu deve ser
retomado e, juntamente com ele, a aplicao, que tambm deve ser tornada
visvel.
A igura 10.28 ilustra essa situao.
filme pagu propaganda filme pagu
filme pausado (propriedade standby de pagu recebe true)
necessrio pausar e ocultar a aplicao
filme retomado (propriedade standby de pagu recebe false)
necessrio retomar e exibir a aplicao

Figura 10.28 Entrelaamento de vdeos no fluxo elementar.
A Listagem 10.20 apresenta o cdigo que manipula a propriedade visible
da aplicao NCL conforme o valor da propriedade embutida standby do
objeto de mdia filme do fluxo elementar. Note que tanto a propriedade
visible do elemento <body> da aplicao como a propriedade standby do
objeto de mdia pagu devem ser explicitamente declaradas (a listagem no
apresenta esse trecho de cdigo).
270
<ncl id="idApl" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<connectorBase>
<causalConnector id="onEndAttribution_and_TestSetFalsePause">
<simpleCondition role="onEndAttribution" />
<attributeAssessment role="testIfTrue"
<compoundAction operator="seq">
<simpleAction role="setAsFalse"
eventType=attribution actionType=start value="false"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttribution_and_TestSetTrueResume">
<simpleCondition role="onEndAttribution"/>
<attributeAssessment role="testIfFalse"
attributeType="nodeProperty" eventType="attribution/>
<valueAssessment value="false />
<simpleAction role="resume />
<simpleAction role="setAsTrue"
eventType=attribution actionType=start value="true/>
</compoundAction>
</causalConnector>
</connectorBase>
</head>
<body>
...
<link xconnector="onEndAttribution_and_TestSetFalsePause">
<bind role="onEndAttribution" component="pagu"
interface="standby/>
<bind role="testIfTrue" component="pagu" interface="standby/>
<bind role="setAsFalse" component="idApl" interface="visible/>
<bind role="pause" component="idApl />
</link>
<link xconnector="onEndAttribution_and_TestSetTrueResume">
<bind role="onEndAttribution" component="pagu"
interface="standby/>
<bind role="testIfFalse" component="pagu" interface="standby/>
<bind role="resume" component="idApl />
<bind role="setAsTrue" component="idApl" interface="visible/>
</link>
</body>
</ncl>
Listagem 10.20 Aplicao NCL preparada para uma interrupo quando h vdeos
entrelaados.

271
10.9 Elos do Tipo get and set
Os elos vistos at aqui definem como valores de parmetro apenas valores
literais fixos, ou seja, at o momento s podemos atribuir valores fixos a
propriedades de um objeto. No entanto, s vezes importante utilizar o valor
atual de uma propriedade como o novo valor de uma outra propriedade.
Como vimos na Seo 10.3, se o valor do atributo eventType de elemento
<simpleAction> for attribution, o elemento deve tambm definir o valor a
ser atribudo, atravs de seu atributo value. Se esse valor for especificado
como $qualquerNome (onde o $ smbolo reservado e qualquerNome
qualquer cadeia de caracteres, exceto um dos nomes reservados para papis),
o valor a ser atribudo deve ser obtido da propriedade ligada a
role=qualquerNome, definida em um elemento <bind> do elemento <link>
que utiliza o conector. Se esse valor no puder ser obtido, nenhuma atribuio
deve ser realizada.
Devemos chamar a ateno para o fato de que, no conector usado pelo elo,
o papel qualquerNome no precisa ser declarado, ele declarado
implicitamente. Em outras palavras, declarar o atributo
role=qualquerNome em um elemento <bind> de um <link>, implica ter um
papel implicitamente declarado como: <attributeAssessment
role=qualquerNome eventType=attribution
attributeType=nodeProperty />. Esse o nico caso possvel de um
elemento <bind> se referir a um papel no definido explicitamente em um
conector. A nica restrio que o valor a ser atribudo deve
obrigatoriamente ser o valor de uma propriedade (elemento <property>) de
um componente da mesma composio onde o elo que referencia o evento
definido ou uma propriedade da prpria composio onde o elo definido ou,
ainda, uma propriedade de um elemento acessvel atravs de uma porta de um
contexto ou switch (elementos <port> ou <switchPort>) aninhado na mesma
composio onde o elo definido.
Mas vamos a um exemplo para tornar claro o conceito. Suponha que exista
um udio que, ao ser continuado de um ponto onde foi pausado, deve pausar
um outro udio e tocar com o mesmo volume do udio que pausou. Suponha
ainda que essa mudana de udios ocorra quando um vdeo de propaganda
termina. A Listagem 10.21 apresenta um elo que define esse comportamento.
<causalConnector id="onEndSet_varPauseResume">
<connectorParam name="var />
<simpleCondition role="onEnd />
<simpleAction role="set" value="$var />
<simpleAction role="pause />
272
<simpleAction role="resume />
</compoundAction>
</causalConnector>
<link xconnector="onEndSet_varPauseResume">
<bind role="onEnd" component="propaganda/>
<bind role="getValue" component="rock" interface="soundLevel/>
<bind role="set" component="samba" interface="soundLevel">
<bindParam name="var" value="$getValue/>
</bind>
<bind role="pause" component="rock/>
<bind role="resume" component="samba/>
</link>
Listagem 10.21 Utilizao de um papel denominado getValue para alinhar o volume de
dois udios.
Nesse caso, a declarao de um papel getValue no elemento <bind>
define implicitamente uma avaliao do tipo <attributeAssessment
role=getValue eventType=attribution
attributeType=nodeProperty />.
10.10 Conectores e Elos com Atribuio ao Longo
do Tempo para Efeito de Animao
Em todos os exemplos anteriores, as mudanas nos valores de propriedades
disparadas por aes de elos foram instantneas. No entanto, uma mudana
brusca de algumas propriedades, como por exemplo a posio vertical de um
objeto, pode desorientar o usurio. Para evitar esse tipo de problema,
podemos criar um efeito de animao atravs da mudana gradual do valor da
propriedade.
Como vimos na Seo 10.3, uma ao de atribuio (role=set) possui
dois atributos opcionais, duration e by, cujos valores defaults so 0 e
indefinite, respectivamente. O atributo duration define o perodo de tempo
decorrido entre o disparo do elo e a atribuio do valor final propriedade
ligada pelo elo. J o atributo by define o incremento utilizado para cada
atribuio. A atribuio de valores segue uma funo linear, onde cada passo
definido pelo valor do atributo by.
A Listagem 10.22 apresenta o cdigo de um conector e um elo que
produzem um efeito de animao na propriedade top de um objeto. Note
273
que, no exemplo, quando o objeto de mdia video1 atinge o trecho
aMenu, um outro objeto de mdia menu comea a ser exibido em uma
posio dada pelo descritor que foi associado exibio desse objeto. No
entanto, o objeto menu se move verticalmente, desde o incio de sua
exibio, at que, passados dois segundos, os dois objetos video1 e menu
estejam alinhados pelo topo.
<causalConnector id=onBeginStartSet_vNewValue_vDuration_vBy>
<connectorParam name=vNewValue />
<connectorParam name=vDuration />
<connectorParam name=vBy />
<simpleAction role=start max=unbounded />
<simpleAction role=set value=$vNewValue max=unbounded
duration=$vDuration by=$vBy />
</compoundAction>
</causalConnector>
<link id=linkAlignTopPosition
xconnector=onBeginStartSet_vNewValue_vDuration_vBy>
<bind role=onBegin component=video1 interface=aMenu />
<bind role=start component=menu />
<bind role=get component=video1 interface=top />
<bind role=set component=menu interface=top>
<bindParam name=vNewValue value=$get />
<bindParam name=vDuration value=2s />
<bindParam name=vBy value=4 />
</bind>
</link>
Listagem 10.22 Alinhamento gradual do topo de duas mdias.
10.11 Importao de Conectores
Conectores da base de conectores de um documento NCL podem ser
importados atravs do elemento <importBase>, filho de <connectorBase>, de
forma semelhante importao das bases vistas nos outros captulos. Basta
definir os atributos alias (apelido do arquivo importado) e documentURI (a
localizao e o nome do arquivo que contm a base a ser importada).
A Listagem 10.23 ilustra a importao de uma base de conectores e o uso
de um dos conectores importados. Esse exemplo assume que, no arquivo
conectores.ncl, existe um <causalConnector> com id
onKeySelectionStartStop.
274
<connectorBase>
<importBase alias=meusConectores documentURI=conectores.ncl/>
</connectorBase>
<link xconnector=meusConectores#onKeySelectionStartStop>
<bind component=menu interface=pMenuItem1 role=onSelection/>
<bind component=menu role=stop/>
<bind component=prog01 role=start/>
</link>
Listagem 10.23 Importao de uma base de conectores.
10.12 Elos Referenciando Composies
Se um elemento <simpleAction> com valor de atributo eventType igual a
presentation for associado por um elo a um elemento <context> ou <body>
como um todo (ou seja, sem que uma de suas interfaces seja informada), a
instruo deve obrigatoriamente ser refletida nas mquinas de estado de
evento dos ns filhos da composio. As seguintes regras so seguidas pelo
formatador NCL.
Se um elemento <context> ou <body> participar em um papel (role) action
cujo tipo de ao "start", quando essa ao for acionada, a instruo start
tambm aplicada a todos os eventos de apresentao mapeados pelas portas
dos elementos <context> ou <body>. Se quisermos iniciar a apresentao
usando uma porta especfica, devemos indicar o id do elemento <port> como
valor de interface do elemento <bind>.
cujo tipo de ao "stop" ou abort, quando essa ao for acionada, a
instruo tambm aplicada a todos os eventos de apresentao dos ns
filhos da composio. Se a composio contiver elos sendo avaliados, as
avaliaes so suspensas e nenhuma ao correspondente acionada.
cujo tipo de ao "pause", quando essa ao for acionada, a instruo pause
aplicada a todos os eventos de apresentao dos ns filhos da composio
que estejam no estado occurring. Se a composio contiver elos sendo
avaliados, todas as avaliaes devem ser suspensas at que uma ao resume,
stop ou abort seja emitida. Se a composio contiver ns-filhos com eventos
de apresentao no estado paused quando a ao pause for emitida, esses ns
so identificados, porque, se a composio receber uma instruo resume,
esses eventos no devem ser retomados.
275
cujo tipo de ao "resume", quando essa ao for acionada, a instruo
resume aplicada a todos os eventos de apresentao dos ns filhos da
composio que estejam no estado paused, exceto aqueles que j estavam
pausados quando a composio foi pausada. Se a composio contiver elos
com avaliaes pausadas, elas so retomadas.
10.13 Referncia Rpida Conectores
A Tabela 10.8 sumariza os atributos e o contedo dos elementos que definem
conectores. Como usual, os atributos obrigatrios esto sublinhados.
Tabela 10.8 Elementos, atributos e contedo que definem conectores no perfil NCL EDTV
causalConnector id (connectorParam*,
(simpleCondition |
compoundCondition),
(simpleAction |
compoundAction))
connectorParam name, type
simpleCondition role, delay,
eventType, key,
transition, min,
max, qualifier

compoundCondition operator, delay ((simpleCondition |
compoundCondition)+,
(assessmentStatement |
compoundStatement)*)
simpleAction role, delay,
eventType,
actionType, value,
min, max, qualifier,
repeat, repeatDelay,
duration, by

compoundAction operator, delay (simpleAction |
compoundAction)+
assessmentStatemen
t
comparator (attributeAssessment,
(attributeAssessment |
valueAssessment))
attributeAssessment role, eventType, key,
attributeType, offset

valueAssessment value
compoundStatement operator, isNegated (assessmentStatement |
compoundStatement)+
276
Bibliografia

277
Captulo
11

Adaptao do
Contedo e da
Apresentao: Regras,
Switches e Switches de
Descritor
Este captulo descreve como adaptar uma aplicao durante sua
execuo, atravs da avaliao de regras e a correspondente seleo de
objetos ou de formas de apresentao (descritores) de objetos. Ao final deste
captulo, voc ser capaz de construir aplicaes que fazem uso de regras,
switches e descriptorSwitches para adaptar o contedo de uma aplicao e a
forma de apresentao desse contedo.
278
11.1 Regras
As regras usadas em uma aplicao NCL so definidas no elemento
<ruleBase>, filho do elemento <head>.
1
Cada regra possui a referncia a uma
propriedade do objeto settings, um operador de comparao e um valor,
conforme a Listagem 11.1. O identificador de uma regra opcional e quando
definido deve seguir a mesma regra de formao para o atributo id definida
no Captulo 5.
<ruleBase>
<rule id=rLegendaLigada var=legenda
comparator=eq value=ligada />
<rule id=rLegendaDesligada var=legenda
comparator=eq value=desligada />
</ruleBase>
Listagem 11.1 Definio de uma base de regras.
O valor do atributo var deve ser uma propriedade do elemento <media
type=application/x-ncl-settings>. J o atributo comparator pode
assumir um dos valores apresentados na Tabela 11.1.
2

Tabela 11.1 Operadores de Comparao que Podem ser Utilizados nas Regras
Valor Significado
eq igual a (equal to)
ne diferente de (not equal to)
gt maior que (greater than)
lt menor que (less than)
gte maior ou igual a (greater than or equal to)
lte menor ou igual a (less than or equal to)
A NCL tambm permite definir regras compostas, atravs do elemento
<compositeRule>, cujo atributo operator pode assumir os valores and ou
or. Uma regra para avaliar se a legenda est ligada e o idioma portugus
poderia ser definida do seguinte modo:

1
Regras e seus atributos so definidos no mdulo TestRule [ABNT, NBR 15606-2, 2011; ITU-T,
H.761, 2011].
2
Esses operadores de comparao so idnticos aos apresentados na Tabela 10.5.
279
<compositeRule id=idiomaPtlegendaOn operator=and>
<rule id=rLegendaLigada var=legenda comparator=eq value=on/>
<rule id=rIdioma var=idioma comparator=eq value=pt/>
</compositeRule>
As regras so utilizadas para adaptao de contedo, atravs do elemento
<switch> e para adaptao de apresentao, atravs do elemento
<descriptorSwitch>, vistos a seguir.
11.2 Switch
Um <switch> uma composio contendo ns (objetos de mdia,
contextos, ou outros switches) alternativos, ou seja, dentre os quais apenas
um ser selecionado.
3
Um switch pode conter qualquer tipo de n de mdia,
de contexto e outros switches. A deciso sobre qual n ser selecionado
dada por regras de mapeamento, definidas atravs de elementos <bindRule>.
4

As regras so avaliadas na ordem em que foram definidas. A primeira regra
avaliada como verdadeira ter seu n correspondente selecionado. Alm disso,
podemos definir um n que ser selecionado por default, no caso de nenhuma
regra ser satisfeita, atravs do elemento <defaultComponent>.
A Listagem 11.2 apresenta uma base de regras que avaliam o valor da
propriedade system.language e um switch que, ao ser acionado, apresenta
a mdia de udio correspondente regra em vigor.
<ruleBase>
<rule id=rEn var=system.language comparator=eq value=en />
<rule id=rPt var=system.language comparator=eq value=pt />
</ruleBase>
<media id=noSettings type=application/x-ncl-settings>
</media>
...
<switch id=switchAudioIdioma>
<bindRule rule=rEn constituent=audioEn />
<bindRule rule=rPt constituent=audioPt />
<defaultComponent component=audioPt />

3
Switches e seus atributos so definidos no mdulo ContentControl [ABNT, NBR 15606-2, 2011;
ITU-T, H.761, 2011].
4
O elemento <bindRule> definido no mdulo TestRuleUse [ABNT, NBR 15606-2, 2011;
ITU-T, H.761, 2011].
280
<media id=audioEn src=media/audioEn.mp3 descriptor=dAudio1 />
<media id=audioPt src=media/audioPt.mp3 descriptor=dAudio1 />
</switch>
Listagem 11.2 Regras e switch que seleciona o udio conforme o idioma em vigor.
Nesse exemplo, a mdia audioEn ser reproduzida caso a regra rEn
seja vlida, ou seja, caso system.language possua o valor en. Se essa
regra no for vlida, o prximo mapeamento avaliado, e assim
sucessivamente, at uma regra vlida ser alcanada ou at terminar o
conjunto de mapeamentos daquele <switch>. Caso o idioma possua um valor
diferente de en e pt, o n audioPt apresentado, conforme definido
pelo elemento <defaultComponent>.
A Figura 11.1 ilustra a viso estrutural do trecho de cdigo da Listagem
11.2.
switchAudioIdioma
[rEn, rPt]
audioPt
(se rPt)
audioEn
(se rEn)

Figura 11.1 Viso estrutural ilustrando um <switch> com duas regras.
No exemplo anterior, o objeto switch selecionou um objeto por inteiro, ou
seja, selecionou para exibio a ncora de contedo total do objeto, definida
por default. Quando necessrio selecionar no apenas o objeto, mas tambm
qual de suas interfaces, o elemento <switchPort> deve ser definido. O
elemento <switchPort> permite a criao de interfaces em um elemento
<switch>, que podem ser mapeadas a um conjunto de interfaces alternativas
de ns internos, permitindo a um elo ancorar no componente e na interface
escolhida quando o <switch> for processado. Um elemento <switchPort>
conter, assim, um conjunto de elementos de mapeamento. Um elemento de
mapeamento (<mapping>) define um caminho a partir do <switchPort> para
uma interface (atributo interface) de um dos componentes do <switch>
(especificados por seu atributo component).
Como novo exemplo vamos assumir que, na Listagem 11.2, os objetos de
mdia de udio, quando escolhidos, tocaro apenas um trecho de seu
281
contedo, especificado pelas ncoras de contedo trechoPt e trechoEn,
respectivamente. Para esse novo exemplo, teremos a Listagem 11.3.
<ruleBase>
</ruleBase>
</media>
...
<switchPort id="spaudio">
<mapping component="audioEn" interface=trechoEn />
<mapping component="audioPt" interface=trechoPt />
</switchPort>
<bindRule rule=rEn constituent=audioEn interface= />
<media id=audioEn src=media/audioEn.mp3 descriptor=dAudio1>
<area id=trechoEn begin=20s end=50s />
</media>
<area id=trechoPt begin=20s end=50s />
</media>
</switch>
Listagem 11.3 Regras e switch que seleciona um trecho do udio conforme o idioma em
vigor.
A Figura 11.2 ilustra a viso estrutural do trecho de cdigo da Listagem
11.3.

switchAudioIdioma
audioPt
audioEn
spAudio
rPt
rEn

Figura 11.2 Viso estrutural ilustrando um <switch> com duas regras e um <switchPort>
spAudio.
282
Embora no seja obrigatrio, mesmo quando um switch seleciona objetos
por inteiro, boa prtica de programao identificar esse tipo de seleo
explicitamente utilizando o elemento <switchPort>. Seguindo essa regra, o
exemplo da Listagem 11.2 ficaria como na Listagem 11.4.
... trecho da seo <head
<ruleBase>
</ruleBase>
</media>
...
<switchPort id="spaudio">
<mapping component="audioEn />
<mapping component="audioPt />
</switchPort>
<bindRule rule=rEn constituent=audioEn />
<media id=audioEn src=media/audioEn.mp3 descriptor=dAudio1 />
</switch>
Listagem 11.4 Regras e switch que seleciona o udio conforme o idioma em vigor, usando
elementos <switchPort>.
A Figura 11.3 ilustra o uso de switches na escolha de objetos internos a
contextos, cujo trecho de cdigo NCL dado pela Listagem 11.5.

switchAudioIdioma
[rEn, rPt]
ctxPt (se rPt)
ctxEn (se rEn)
audioPt
pNivelBasico
<switchPort>
pEn
pPt
audioEn

Figura 11.3 Switch contendo contextos.
283
<bindRule rule=rEn constituent=ctxEn />
<bindRule rule=rPt constituent=ctxPt />
<defaultComponent component=ctxPt />

<switchPort id=pNivelBasico>
<mapping component=ctxEn interface=pEn />
<mapping component=ctxPt interface=pPt />
</switchPort>

<context id=ctxEn>
<port id=pEn component=audioEn />
<media id=audioEn src=media/audioEn.mp3
descriptor=dAudio1 />

</context>
<context id=ctxPt>
<port id=pPt component=audioPt />
<media id=audioPt src=media/audioPt.mp3
descriptor=dAudio1 />

</context>
</switch>
Listagem 11.5 Switch contendo contextos.
Sendo mais precisos, podemos dizer que uma referncia (p. ex., por meio
de um elo) a um componente interno a um switch deve ser feita atravs de um
elemento <switchPort> ou, por default ao elemento <switch> sem especificar
uma <switchPort>. Nesse ltimo caso, considerado como se a referncia
fosse feita a uma <switchPort> que contivesse elementos <mapping> para
cada elemento filho do switch e se referindo s ncoras de contedo total
desses elementos. Mais ainda, um elemento <switchPort> pode definir um
mapeamento para apenas um subconjunto dos elementos filhos do switch.
Quando um elo ancorando nessa <switchPort> avaliado e nenhuma das
regras que ligam aos elementos mapeados satisfeita, o elemento definido
pelo elemento <defaultComponent> deve ser o escolhido, caso o elemento
<defaultComponent> tiver sido definido; em caso contrrio nenhum elemento
deve ser selecionado.
11.3 Switch de Descritor
Assim como utilizamos o elemento <switch> para selecionar um objeto
conforme uma regra, podemos utilizar o elemento <descriptorSwitch> para
selecionar um descritor conforme uma regra. Assim como no caso anterior,
284
so utilizados elementos <bindRule> para ligar uma regra ao descritor
correspondente, como exemplificado na Listagem 11.6.
<descriptorBase>
...
<descriptorSwitch id=dLegenda>
<bindRule rule=rLegendaOn constituent=dLegendaOn />
<bindRule rule=rLegendaOff constituent=dLegendaOff />
<descriptor id=dLegendaOn region=rgLegenda />
<descriptor id=dLegendaOff region=rgLegenda>
<descriptorParam name=visible value=false />
</descriptor>
</descriptorSwitch>
</descriptorBase>
Listagem 11.6 Definio de um <descriptorSwitch> que seleciona um descritor que exibe
ou oculta as legendas, conforme as regras rLegendaOn e rLegendaOff.
Na Listagem 11.6, o switch de descritor indica que, caso a legenda esteja
ligada (regra rLegendaOn vlida), o descritor utilizado dLegendaOn,
que exibe a mdia correspondente na regio rgLegenda, com os parmetros
de exibio default. Caso a legenda esteja desligada, por outro lado (regra
rLegendaOff vlida), o descritor utilizado o dLegendaOff, atravs do
qual a mdia oculta (parmetro visible com valor false).
<media id=video1 src=media/melhoresMomentos.mpg
descriptor=dVideoFullscreen>
</media>
<media id=legenda1 src=media/leg01.html descriptor=dLegenda />
...

<link xconnector=onBeginStart>
<bind component=video1 interface=a1 role=onBegin />
<bind component=legenda1 role=start />
</link>
<link xconnector=onEndStop>
<bind component=video1 interface=a1 role=onEnd />
<bind component=legenda1 role=stop />
</link>
...
Listagem 11.7 Elos que fazem uso de um <descriptorSwitch> de maneira idntica que
faziam de um <descriptor> homnimo.
285
11.4 Referncia Rpida Regras, Switches e
Switches de Descritor
Nas tabelas a seguir, como usual em nossas descries, os atributos
obrigatrios esto sublinhados.
A Tabela 11.2 apresenta os elementos e atributos utilizados para definir o
elemento <rule>, conforme o perfil NCL EDTV.
Tabela 11.2 Elementos e Atributos que Definem Regras no Perfil EDTV
ruleBase id (importBase|rule|compositeRule)
+
rule id, var, comparator,
value

compositeRule id, operator (rule | compositeRule)+
A Tabela 11.3 apresenta os elementos e atributos utilizados para definir
elementos <switch>, conforme o prefil NCL EDTV.
Tabela 11.3 Elementos e Atributos que Definem Elementos <switch> no Perfil NCL
EDTV
switch id, refer (defaultComponent?,
(switchPort|bindRule|media|context|
switch)*)
bindRule constituent,
rule

defaultComponent component
switchPort id mapping+
mapping component,
interface

286
A Tabela 11.4 apresenta os elementos e atributos utilizados para definir
elementos <descriptorSwitch>, conforme o perfil NCL EDTV.
Tabela 11.4Elementos e Atributos que Definem Elementos <descriptorSwitch> no
Perfil NCL EDTV
descriptorSwitch id (defaultDescriptor?,
(bindRule|descriptor)*)
defaultDescriptor descriptor
Bibliografia

287
Captulo
12

Metadados
Metadados so dados sobre dados. Um metadado no contm informaes
de contedo utilizadas ou exibidas durante a apresentao de um documento.
Em vez disso, contm informaes sobre o contedo utilizado ou exibido, que
podem ser processadas automaticamente. Por exemplo, podemos definir
palavras-chave como metadados de uma aplicao NCL para facilitar buscas
de aplicaes com determinadas caractersticas.
288

12.1 Metadados em Aplicaes NCL
A NCL permite dois tipos de metadados, representados pelos elementos
<meta> e <metadata>. Esses elementos e seus atributos so definidos no
mdulo Metainformation e sumarizados na Tabela 12.1.
Tabela 12.1 Elementos, Atributos e Contedo (Elementos Filhos) Definidos pelo Mdulo
Metainformation para o Perfil EDTV
meta name, content
metadata rvore RDF
O elemento <meta> destinado a metadados simples, com uma
propriedade (definida pelo atributo name) e um valor ou lista de valores
(definidos pelo atributo content). Por exemplo, o autor, a data de criao e o
tipo de licena de uma aplicao NCL podem ser representados conforme
ilustrado pela Listagem 12.1.
<meta name=author content=Telemidia />
<meta name=data content=2009-01-03 />
<meta name=license content=cc 3.0 by-nc-nd />
Listagem 12.1 Definio de metadados atravs de listas de propriedades.
O elemento <metadata> destinado a metadados mais estruturados. Eles
so representados como uma rvore RDF (1999), onde o elemento
<metadata> atua como a raiz da rvore, como ilustrado na Listagem 12.2.
289
<metadata>
<rdf:RDF
xmlns:rdf = http://www.w3.org/1999/02/22-rdf-syntax-ns#
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
rdf:about=http://www.telemidia.puc-rio.br/ex/ex01>
<dc:title>Meu primeiro exemplo NCL</dc:title>
<dc:description>
Exemplo simples, sem sincronismo de midia nem
interatividade, para familiarizar o desenvolvedor com a estrutura de
uma aplicacao NCL
</dc:description>
<dc:publisher>Telemidia</dc:publisher>
<dc:date>2009</dc:date>
<dc:rights>Copyright 2009 Telemidia</dc:rights>
<dc:license> cc 3.0 by-nc-nd</dc:license>
<dc:format> text/ncl</dc:format>
<dc:creator>
<rdf:Seq ID=CreatorsAlphabetical>
<rdf:li>Luiz Fernando Gomes Soares</rdf:li>
<rdf:li>Simone Barbosa</rdf:li>
</rdf:Seq>
</dc:creator>
</rdf:Description>
</rdf:RDF>
</metadata>
Listagem 12.2 Definio de metadados atravs de rvore RDF.
Metadados podem ser associados a uma aplicao NCL como um todo, e,
nesse caso, devem ser definidos como elementos filhos do elemento <head> de
uma aplicao. Metadados podem tambm ser associados a contextos
(definidos como elementos filhos deles), representados pelos elementos
<body> e <context>. A Listagem 12.3 ilustra a definio de metadados em
um contexto de propaganda.
<context id=propaganda>
<meta name=produto content=detergente LimpaBem />
<meta name=agencia content=MarketingDoBom />
<meta name=data content=2009-05-03 />
...
</context>
Listagem 12.3 Definio de metadados em um contexto.
290
12.2 Exemplo de Metadados na Aplicao
O Primeiro Joo
Como exemplo, vamos retomar uma das listagens do Captulo 3, sobre a
animao O Primeiro Joo e vamos reche-la de metadados, salientados em
negrito na Listagem 12.4. Teremos metadados para:
1) informaes sobre a aplicao em si, seus autores, copyright etc., inseridas
no elemento <head>;
2) informaes sobre o contedo dos objetos de mdia utilizados, inseridas no
elemento <body>;
3) informaes sobre a propaganda adicionada por interao, inseridas no
elemento <context> que a define.
<ncl id="switch" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<ruleBase>
<rule id="en" var="system.language" value="en" comparator="eq/>
comparator="eq/>
</ruleBase>
<regionBase>
zIndex="1/>
width="18.5%" height="18.5%" zIndex="3/>
<region id="shoesReg" left="15%" top="60%"
width="25%" height="25%" zIndex="3/>
</region>
</regionBase>
<descriptorBase>
<descriptor id="backgroundDesc" region="backgroundReg/>
<descriptor id="screenDesc" region="screenReg/>
<descriptor id="photoDesc" region="frameReg" explicitDur="5s/>
<descriptor id="audioDesc/>
<descriptor id="dribleDesc" region="frameReg />
<descriptor id="iconDesc" region="iconReg" explicitDur="6s/>
<descriptor id="shoesDesc" region="shoesReg />
explicitDur="15s/>
</descriptorBase>
291
<connectorBase>
<importBase documentURI="../causalConnBase.ncl" alias="conEx/>
</connectorBase>
<meta name=telemidia_ref content=TM-0132 />

<metadata>
<rdf:RDF
<rdf:Description
rdf:about=http://www.telemidia.puc-rio.br/ex/Joao>
<dc:title>O Primeiro Joo</dc:title>
<dc:description>
Exemplo de uso de metadados em aplicaes NCL
</dc:description>
<dc:publisher>Telemidia</dc:publisher>
<dc:date>2009</dc:date>
<dc:rights>Copyright 2009 Telemidia</dc:rights>
<dc:license> cc 3.0 by-nc-nd</dc:license>
<dc:format> text/ncl</dc:format>
<dc:creator>
<rdf:Seq ID=CreatorsAlphabetical>
<rdf:li>Luiz Fernando Gomes Soares</rdf:li>
<rdf:li>Simone Barbosa</rdf:li>
</rdf:Seq>
</dc:creator>
</rdf:Description>
</rdf:RDF>
</metadata>
</head>

<body>
<metadata>
<rdf:RDF
<rdf:Description
rdf:about=http://www.telemidia.puc-rio.br/m/Joao>
<dc:title>O Primeiro Joo</dc:title>
<dc:description>
Animao sobre o Garrincha
</dc:description>
<dc:format> avi</dc:format>
<dc:creator>Andr Castelo</dc:creator>
</rdf:Description>

<rdf:Description
rdf:about=http://www.telemidia.puc-rio.br/m/vF01>
292
<dc:title>Cenas de futebol</dc:title>
<dc:description>
Vdeo com cenas de futebol no CIDS
</dc:description>
<dc:creator>PC-CIDS-VG</dc:creator>
</rdf:Description>

<rdf:Description
rdf:about=http://www.telemidia.puc-rio.br/m/iJ01>
<dc:title>Imagem de jogadores</dc:title>
<dc:description>
Imagem de jogadores de futebol no CIDS
</dc:description>
<dc:creator>PC-CIDS-VG</dc:creator>
</rdf:Description>

</rdf:RDF>
</metadata>

<port id="entry" component="animation/>
descriptor="backgroundDesc/>
<area id="segDrible" begin="12s/>
<area id="segPhoto" begin="41s/>
<area id="segIcon" begin="45s" end="51s/>
</media>
descriptor="audioDesc/>
descriptor="dribleDesc/>
descriptor="photoDesc/>
<meta name=genero content=Propaganda />
<meta name=autor content=PC-CIDS-VG />
<property name="bounds/>
</media>
<media id="icon" src="../media/icon.png" descriptor="iconDesc/>
descriptor="shoesDesc/>
<switch id="form">
<mapping component="enForm/>
293
<mapping component="ptForm/>
</switchPort>
<bindRule constituent="enForm" rule="en/>
<defaultComponent component="ptForm/>
descriptor="formDesc/>
descriptor="formDesc/>
</switch>
interface="segIcon/>
<bind role="start" component="icon/>
</link>
<link id="lBegingShoes"
connector="conEx#onKeySelectionStopSet_varStart">
<bindParam name="keyCode" value="RED/>
</bind>
<bind role="start" component="shoes/>
<bind role="start" component="form" interface="spForm/>
<bind role="set" component="reusedAnimation" interface="bounds">
<bindParam name="var" value="5%,6.67%,45%,45%/>
</bind>
<bind role="stop" component="icon />
</link>
<bind role="onEnd" component="form" interface="spForm/>
interface="bounds">
<bindParam name="var" value="0,0,222.22%,222.22%/>
</bind>
</link>
</context>
<bind role="onBegin" component="animation/>
<bindParam name="delay" value="5s/>
</bind>
<bindParam name="delay" value="5s/>
</bind>
</link>
interface="segDrible/>
<bind role="start" component="drible/>
</link>
294
interface="segPhoto/>
<bind role="start" component="photo />
</link>
<bind role="onEnd" component="animation/>
<bind role="stop" component="background/>
<bind role="stop" component="choro/>
</link>
</body>
</ncl>
Listagem 12.4 Definio de metadados em um contexto.
Bibliografia
SMIL 2.1 Specification, SMIL 2.1 Synchronized Multimedia Integration
Language SMIL 2.1 Specification, W3C Recommendation. Dezembro
de 2005.

295
Captulo
13

Reso
medida que as aplicaes se tornam mais complexas e que padres de
projeto emergem na definio de diversos elementos, torna-se necessrio
buscar mecanismos que aumentem a eficincia da autoria dessas aplicaes.
Como vimos nos captulos anteriores, a NCL proporciona o reuso de diversos
elementos definidos nas suas bases (p. ex., <regionBase>, <descriptorBase>,
<connectorBase> etc.). Este captulo apresenta mecanismos adicionais de
reuso fornecidos pela NCL: reuso de contedo, importao de documentos,
importao de bases de um documento e reuso de ns, intra- e
interdocumentos.
1

Ao final deste captulo, voc ser capaz de reutilizar elementos definidos
em diferentes aplicaes NCL.

1
Este captulo se baseia em Soares, L.F.G. e Soares Neto, C.S. [2009]. O uso do material foi
gentilmente cedido pelo Departamento de Informtica da PUC-Rio.
296
13.1 Espelhamento de Contedo
Em geral, cada elemento <media> define um objeto de mdia distinto.
Mesmo quando dois objetos tm o mesmo valor de atributo src, por default
eles constituem objetos de mdia distintos, cada qual com sua mquina de
estados independente. Isso significa que a apresentao de um objeto
totalmente independente da apresentao do outro. H casos, no entanto, em
que pode ser necessrio exibir no apenas o mesmo contedo em paralelo,
mas efetivamente que esse contedo exiba as mesmas unidades de informao
em um dado momento. Isso realizado definindo no atributo src de um
elemento que ele a cpia espelhada de outro, referenciado no atributo.
Embora definido unidirecionalmente, a relao de espelhamento entre os
objetos reflexiva, simtrica e transitiva. No existe nenhuma dependncia de
mestre-escravo, ou seja, o espelhamento em duas vias.
A Listagem 13.1 define trs elementos <media> exatamente com o mesmo
contedo. Os objetos video1 e video2 so independentes e, portanto,
podem ser apresentados em paralelo em diferentes momentos de seu contedo,
ao passo que, ao iniciar o video3, ele ser exibido, tambm em paralelo,
mas no mesmo ponto em que video1 estiver sendo exibido.
<media id=video1 src=propaganda.mp4 descriptor= d1/>
<media id=video2 src=propaganda.mp4 descriptor= d2/>
<media id=video3 src=ncl-mirror://video1 descriptor= d3/>
Listagem 13.1 Objetos de mdia distintos, mas com o mesmo contedo (arquivo-fonte
definido pelo atributo src).
A igura 13.1apresenta um storyboard envolvendo esses objetos, ilustrando
o mecanismo de espelhamento.
A aplicao inicia video1.
1
video1

Aps 4 segundos, inicia video2.
5
video1
1
video2

297
Aps mais 5 segundos, inicia
video3.
10
video1
6
video2
10
video3

Aps mais 2 segundos, pausa
video3.
12
video1
8
video2
12
video3

Um segundo depois, video3
continua pausado mas video1
prossegue.
13
video1
9
video2
12
video3

Aps mais 1 segundo, retoma
video3, que assume a mesma
posio de video1.
14
video1
10
video2
14
video3

Aps mais 5 segundos, algum elo
encerra video1, mas video3
prossegue.
15
video2
19
video3

Aps mais 2 segundos, ocorre o
fim natural de video3.
17
video2

Figura 13.1 Storyboard ilustrando objetos de mdia independentes e espelhados.
298

13.2 Reso de Objetos de Mdia
Como vimos brevemente no Captulo 8, utilizamos os atributos refer e
instance para reusar um objeto de mdia, incluindo seu contedo, seu
descritor e quaisquer ncoras e propriedades definidos para ele.
O atributo refer indica o id do objeto que deve ser reutilizado. Existe uma
nica restrio do uso. Um atributo refer no pode referenciar um objeto
definido na mesma composio que o contm diretamente.
Quando um elemento declara um atributo refer, todos os atributos e
elementos filhos definidos pelo elemento referenciado so herdados. Todos os
outros atributos e elementos filhos, se definidos pelo elemento que realiza a
referncia, so ignorados pelo formatador NCL, exceto o atributo id que deve
ser definido e, em alguns, o atributo descriptor, que pode ser redefinido
(nesse caso excepcional, o atributo instance, apresentado a seguir, deve ter o
valor new). Ainda outra exceo a possibilidade de se adicionar novos
elementos filhos <area> e <property>. Se o novo elemento <property>
adicionado tiver o mesmo atributo name de um elemento <property> j
existente (definido no elemento <media> reutilizado), o novo elemento
<property> adicionado ignorado. Igualmente, se o novo elemento <area>
adicionado tiver o mesmo atributo id de um elemento <area> j existente
(definido no elemento <media> reutilizado), o novo elemento <area>
adicionado ignorado.
O atributo instance pode ter os seguintes valores:
- new: objeto totalmente independente (reso do cdigo declarativo que
especifica o objeto). Trata-se de um novo objeto que uma cpia do objeto
referenciado, incluindo suas ncoras de contedo e propriedades. Esse o
valor default para o atributo instance. Apenas nesse caso o atributo
descriptor pode ser redefinido;
- instSame: trata-se do mesmo objeto, iniciado para exibio junto com o
objeto referido, isto , o objeto em exibio incorporar, desde sua
iniciao, todas as propriedades e ncoras de contedo definidas no
elemento referenciado e nos elementos que o referenciam, e reportar todas
as mudanas nas mquinas de estado de evento dessas interfaces a todos
os elos associados a esses elementos <media>;
299

- gradSame: trata-se do mesmo objeto, mas que incorporar gradualmente
as propriedades e ncoras de contedo definidas no elementos que
referenciam e o referenciado, medida que eles sofrerem aes de start.
Apenas os elos associados aos elementos que j receberam a ao de start
recebem a notificao de mudanas nas mquinas de estado de evento das
interfaces j incorporadas.
Para facilitar o entendimento dessas diferentes formas de reso, vamos
considerar o cdigo da Listagem 13.2.
<media id=video1 src=propaganda.mp4 descriptor=d1>
<area id=a1_1 begin=3s end=5s />
</media>

<media id=video2_n refer=video1 instance=new descriptor=d2>
</media>

<media id=video3_i refer=video1 instance=instSame>
</media>

<media id=video4_g refer=video1 instance=gradSame>
</media>
Listagem 13.2 Reso de objetos de mdia atravs dos atributos refer e instance.
Vamos supor, ainda, que haja elos disparados no incio e trmino de cada
ncora, intitulados link1_1_s, link1_1_e, link2_1_s, link2_1_e, e
assim por diante. A Figura 13.2 ilustra partes da viso estrutural
correspondente. Podemos observar que a ncora a1_1 herdada por todos
os objetos de mdia que se referem a video1 e que, por isso, pode participar
de outros elos nos diferentes contextos em que os objetos so definidos. Em
particular, definimos um elo link1_1_e_ctx4 no contexto ctx4 para
ilustrar essa caracterstica.
300
body
ctx2
ctx4
ctx3
video1
a1_1
link1_1_s
link1_1_e
video3_i
a3_1
link_3_1_s link3_1_e
video2_n
a2_1 a2_2
link2_1_s
link2_2_s link2_1_e
link2_2_e
video4_g
a4_1 a4_2
link4_1_s
link4_2_s link4_1_e
link4_2_e
a1_1
a1_1
a1_1
link1_1_e_ctx4

Figura 13.2 Viso estrutural parcial do exemplo de reuso de objetos de mdia.
A Tabela 13.1 ilustra o comportamento de uma aplicao NCL que inicia
os objetos video1, video2_n e video4_g em diferentes momentos (no
incio da aplicao, a trs segundos do incio e a quatro segundos do incio,
respectivamente) e termina video2_n e video1 a oito e nove segundos do
incio, respectivamente.
Tabela 13.1 Comportamento da Aplicao de Exemplo de Reuso de Objetos de Mdia.
Estado o significa Occurring e Estado s Significa Sleeping
Tempo
do Incio da
Aplicao
+ Evento
Objeto Estado da
ncora
de
Contedo
Total
Tempo de
Apresentao
do Objeto
ncoras
em
Occurring
Ativao de
Elos
0
aplicao
inicia
video1
video1 o 0
video2_n s
video3_i o 0
video4_g s
1
video1 o 1
video2_n s
video3_i o 1
video4_g s
2
video1 o 2
video2_n s
video3_i o 2 a3_1 link3_1_s
video4_g s
301
3
algum elo
inicia
video2_n
video1 o 3 a1_1 link1_1_s
video2_n o 0
video3_i o 3 a3_1
video4_g s
4
algum elo
inicia
video4_g
video1 o 4 a1_1
video2_n o 1 a2_1 link2_1_s
video3_i o 4 a3_1
video4_g o 4
5

video1 o 5 link1_1_e
video2_n o 2 link2_1_e
video3_i o 5 link3_1_e
video4_g o 5 link_1_1_e_ctx4
6
video1 o 6
video2_n o 3
video3_i o 6
video4_g o 6 a4_2 link4_2_s
7
video1 o 7
video2_n o 4 a2_2 link2_2_s
video3_i o 7
video4_g o 7 a4_2
8
algum elo
encerra
video2_n
video1 o 8
video2_n s a2_2 link2_2_e
video3_i o 8
video4_g o 8 a4_2
9
algum elo
encerra
video1
video1 s
video2_n s
video3_i s
video4_g s link4_2_e
Quando video1 iniciado, video3_i automaticamente iniciado
tambm. Quando video4_g iniciado, ele assume o mesmo tempo de
apresentao do objeto referido, video1. Como video4_g foi iniciado
apenas a quatro segundos do incio da aplicao, a ncora a4_1 nunca
ocorre e os elos link4_1_s e link4_1_e nunca so ativados.
Chamamos de reso de objeto de representao as formas de reuso
utilizadas pelos elementos <media> video3_i e video4_g: so o mesmo
objeto de mdia em exibio, cujos elementos so iniciados juntos (no caso de
instance=instSame) ou separadamente (no caso de instance=gradSame).
Por outro lado, video2 totalmente independente de video1. Trata-se
de um reso apenas do cdigo declarativo que especifica o objeto, que
chamamos de reso de objeto de dados. Nesse tipo de reso o objeto
302
video2_n aproveita todos os atributos, ncoras de contedo e propriedades
do objeto referido (video1), mas se trata de um objeto de mdia diferente.
Uma observao importante que esses elementos que representam o
objeto de mdia no precisam nem devem estar num mesmo contexto. Pelo
contrrio, o reso de objetos de mdia em diferentes contextos a principal
razo de ser desse mecanismo. Por exemplo, as ncoras de video3_i e
video4_g podem indicar diferentes oportunidades de interao associadas a
diferentes momentos de um mesmo vdeo, para iniciar um quizz e um slide
show, respectivamente, cada qual em seu prprio contexto (contextos ctx3
e ctx4).
Reuso de objeto de mdia foi bastante explorado no Captulo 3, nas vrias
verses da aplicao O Primeiro Joo. Sugerimos ao leitor revisitar aquele
captulo.
13.3 Reso de Contextos
Diferentemente do reso de objetos de mdia, o reso de contextos
realizado apenas pelo atributo refer e consiste no reso do cdigo declarativo
que o especifica. Em outras palavras, cria uma cpia do contexto
referenciado. A Listagem 13.3 apresenta um exemplo de reso de contexto.
<context id=menu>
...
</context>

<context id= quizz>
...
<context id=menu_no_quizz refer=menu />
</context>
Listagem 13.3 Reso de contextos atravs do atributo refer.
13.4 Reso entre Documentos NCL
O reso apresentado nas sees anteriores envolveu elementos de um
mesmo documento. A NCL oferece tambm diversas formas de reso de
elementos ou mesmo de documentos inteiros definidos em diferentes arquivos.
13.4.1 Importao de um Documento NCL
Como vimos nos captulos anteriores, bases de regies, de descritores, de
transies e de regras podem ser importadas por um documento NCL por
303
meio do elemento <importBase> definido como filhos da base importadora e
referenciando um URI da base a ser importada. A linguagem NCL permite,
no entanto, que se importe tambm documentos, como um todo.
Para importar um ou mais documentos NCL, utilizamos o elemento
<importedDocumentBase>, definido como filho do elemento <head> do
documento importador, que agrupa um ou mais elementos <importNCL>,
cada qual definindo um documento a ser importado.
2

Quando se importa um documento por meio do elemento <importNCL>,
todas as bases definidas dentro do documento importado, bem como o
elemento <body> do documento, so importados, todos de uma vez. As bases
so tratadas como se cada uma tivesse sido importada por um elemento
<importBase>. O elemento <body> importado tratado como um elemento
<context>. importante salientarmos que o elemento <importNCL> no
inclui o documento NCL referido, mas apenas torna o documento
referenciado visvel para que os seus componentes possam ser reusados pelo
documento que definiu o elemento <importNCL>, da mesma forma que resa
objetos, como discutimos nas sees anteriores. Assim, o <body> importado,
bem como quaisquer de seus ns, pode ser reusado dentro do documento NCL
que realizou a importao.
O elemento <importNCL> tem dois atributos: documentURI e alias. O
documentURI refere-se a um URI correspondente ao documento a ser
importado. O atributo alias especifica um nome a ser utilizado quando for
realizada uma referncia a elementos desse documento importado. O nome
deve ser nico (type=ID) e seu escopo restrito ao documento que definiu o
atributo alias.
Para reusar um documento importado, criamos um contexto que se refere
ao documento importado como alias#id_do_documento_importado.
Supondo que a aplicao prog1.ncl tenha id=prog1, o documento pode
definir um contexto que se refere ao documento prog1 inteiro. Como todo
reso de contexto, criada uma cpia do contexto original.
No apenas o documento como um todo, mas qualquer objeto definido pelo
documento importado pode ser reusado. Para reusar um elemento, o atributo
refer do elemento que far o reso deve conter o valor alias#element_id.
Como boa prtica de programao, recomenda-se que o mesmo alias seja
utilizado quando necessrio referir-se a elementos definidos nas bases do
documento importado (<regionBase>, <connectorBase>, <descriptorBase>
etc.).

2
Os elementos de importao de documentos, bases e seus atributos so definidos no mdulo Import
[ABNT, NBR 15606-2, 2011; ITU-T, H.761, 2011].
304
Cabe ainda mencionar que, como em todas as importaes de base, a
operao do elemento <importNCL> tambm tem propriedade transitiva, ou
seja, se o documentoA importar o documentoB que importa o
documentoC, ento o documentoA importa o documentoC. Entretanto,
o alias definido para o documentoC dentro do documentoB
desconsiderado pelo documentoA.
A Listagem 13.4 ilustra a importao de trs documentos NCL e a
definio dos contextos que se referem aos documentos importados. A
listagem apresenta ainda um elo que inicia a apresentao de um dos
contextos importados.
<ncl id=exemplo01> ... </ncl>
... documento prog1.ncl a ser importado
<importedDocumentBase>
<importNCL alias=docProg1 documentURI=prog1.ncl />
</importedDocumentBase>
... trecho da seo <head> do documento que importa os outros
... trecho da seo <body> do documento que importa os outros
<context id=prog01 refer=docProg1#exemplo01> ... </context>

<link xconnector=onKeySelectionStartStop>
<bind role=onSelection component=menu interface=pMenuItem1/>
<bind role=stop component=menu/>
<bind role=start component=prog01/>
</link>
Listagem 13.4 Importao de documentos NCL e uso de elementos do documento
importado.
A Figura 13.3 apresenta a viso estrutural parcial do exemplo ilustrando a
importao dos documentos tal como definida pela Listagem 13.4.
305
body
prog1.ncl
prog01
(docProg1#
exemplo01)
exemplo01
...
...
prog2.ncl
prog02
(docProg2#
exemplo02)
exemplo02
...
prog3.ncl
prog03
(docProg3#
exemplo03)
exemplo03
...
... ...
...
...

Figura 13.3 Viso estrutural parcial ilustrando a importao de documentos NCL.
13.4.2 Reso de um Documento NCL como um Objeto de
Mdia
Como mencionado no Captulo 8, tambm possvel reusar um documento
NCL inteiro como um objeto de mdia do tipo application/x-ncl-ncl. A
vantagem de se reusar um documento dessa maneira a possibilidade de
apresent-lo em uma regio especfica, em um dispositivo especfico, como
ser discutido nos Captulos 14 e 15. A Listagem 13.5 ilustra o reso de um
documento NCL como um objeto de mdia a ser apresentado na regio
associada ao descritor descPDA, ou seja, como se essa regio fosse toda a
tela do dispositivo disponvel para apresentar o documento importado.
<media id=mirrorProg1 type=application/x-ncl-ncl
refer=docProg1#exemplo01
descriptor=descPDA />
Listagem 13.5 Reso de documento como um objeto de mdia.
13.5 Importao da Base de um Documento NCL
Alm de objetos de mdia, contextos e documentos NCL inteiros, a NCL
oferece um mecanismo de reso de uma base definida em um arquivo externo,
306
como visto nos captulos que descrevem cada base. Para isso, utilizamos o
elemento <importBase> como um elemento aninhado ao elemento
correspondente base a ser importada. Para importar uma base de regies,
por exemplo, devemos definir um <importBase> dentro do elemento
<regionBase>, conforme ilustrado pela Listagem 13.6.
<regionBase>
<importBase alias=regioesDocumentario
documentURI=baseRegioesDocumentario.ncl />
</regionBase>
Listagem 13.6 Importao de uma base de regies.
O elemento <importBase> possui os seguintes atributos:
- alias: apelido do arquivo importado, ou seja, o nome que ser utilizado
apelido#id_do_elemento_importado. No caso do exemplo, a base de
conectores foi importada com o alias meusConectores. Para se referir
ao conector onEndStop dentro do arquivo importado, devemos utilizar a
string meusConectores#onEndStop;
- documentURI: a localizao e o nome do arquivo que contm a base a ser
importada. Nesse exemplo, como o arquivo de conectores est no mesmo
diretrio que o arquivo da aplicao, bastou definir apenas o nome do
arquivo;
- region: no caso de o arquivo importado conter uma base de regies, define
qual regio da aplicao conter as regies importadas.
- baseId: no caso de o arquivo importado conter mais de uma base de
regies, define qual base se quer importar.
Vale observar que, quando uma base de descritores importada, as regies
so importadas automaticamente. Em outras palavras, quando h um
<importBase> na seo <descriptorBase>, no necessrio fazer o
<importBase> correspondente s regies na seo <regionBase>, que pode
ficar vazia.
O uso mais comum de importao de bases de um documento a
importao de uma base de conectores definida em um documento NCL
dedicado a esse fim. A Listagem 13.7 apresenta novamente o exemplo
descrito no Captulo 10, que ilustra a importao de uma base de conectores e
o uso de um dos conectores importados. Esse exemplo assume que, no
307
arquivo conectores.ncl, existe um <causalConnector> com id
onKeySelectionStartStop.
<connectorBase>
<importBase alias=meusConectores
documentURI=conectores.ncl />
</connectorBase>
<link xconnector=meusConectores#onKeySelectionStartStop>
<bind component=menu interface=pMenuItem1
role=onSelection/>
<bind component=menu role=stop/>
<bind component=prog01 role=start />
</link>
Listagem 13.7 Importao de uma base de conectores.
13.6 Referncia Rpida Importao de
Documentos e Bases
A Tabela 13.2 apresenta os elementos e atributos relacionados ao reuso de
documentos e bases de documentos NCL via importao. Como usual, os
atributos obrigatrios esto sublinhados.
Tabela 13.2 Elementos e Atributos Relacionados ao Reso de Documentos e Bases de
Documentos NCL no Perfil NCL EDTV
importedDocumentBase id (importNCL)+
importNCL alias, documentURI
importBase alias, documentURI, region,
baseId

Bibliografia
ABNT, NBR 15606-2, 2011. Associao Brasileira de Normas
Tcnicas, Televiso digital terrestre Codificao de dados e
308
especificaes de transmisso para radiodifuso digital, Parte 2:
Ginga-NCL para receptores fixos e mveis Linguagem de
aplicao XML para codificao de aplicaes, Sistema Brasileiro
de TV Digital Terrestre, NBR 15606-2.
ITU-T, H.761, 2011. Nested Context Language (NCL) and Ginga-
NCL for IPTV. ITU-T Rec. H.761. Genebra.
Soares, L.F.S., Soares Neto, C.S. Reso e importao em Nested Context
Language. Monografias em Cincia da Computao do Departamento de
Informtica, PUC-Rio, N. 13/09. Rio de Janeiro, maro de 2009. ISSN
0103-9741.

309
PARTE III

Tpicos Avanados

310
Captulo
14

Objetos Hipermdia
Declarativos em NCL
Como vimos no Captulo 8, a linguagem NCL aceita no apenas objetos
de mdia convencionais (perceptuais), com contedo de vdeo, imagem, udio
e texto, mas tambm objetos de mdia cujo contedo composto por cdigo
declarativo ou imperativo na definio de seus elementos <media>.
Objetos de mdia com cdigo imperativo ou funcional so tratados no
Captulo 17. Neste captulo, discutiremos como objetos com contedo
hipermdia especificado por uma linguagem declarativa podem ser definidos,
como eles podem se relacionar com outros objetos em um documento NCL e
como exibidores (players) para esses objetos se comportam.
1

Em particular, objetos de mdia com cdigo NCL sero abordados. Em
outras palavras, uma aplicao NCL pode conter objetos de mdia
representando outras aplicaes NCL, recursivamente. Aliado ao suporte a
mltiplos dispositivos de exibio, discutidos no Captulo 15, esse um
conceito mpar de NCL.

1
Este captulo se baseia em Soares (2009). O uso do material foi gentilmente cedido pelo
311
14.1 Integrando Objetos Hipermdia Declarativos
NCL
Um objeto de mdia com contedo hipermdia especificado por um
cdigo declarativo, tambm denominado objeto hipermdia declarativo,
definido em NCL pelo elemento <media> com o atributo type recebendo o
valor application/x-???, onde ??? depende da linguagem declarativa usada.
Por exemplo, application/x-ncl-NCL usado no middleware Ginga para
objetos com cdigo NCL embutidos no documento NCL pai. A nica exceo
atual a essa regra o objeto declarativo do tipo text/html, que contm
cdigo HTML/XHTML.
Em um objeto hipermdia declarativo, o atributo src deve referenciar a
localizao do cdigo declarativo que compe o contedo do objeto. A
Listagem 14.1 ilustra um exemplo de especificao de objeto hipermdia
declarativo com cdigo NCL. Note que o fato de usarmos a extenso .ncl
nos desobriga da definio do atributo type, como usual.

Listagem 14.1 Objeto de mdia com cdigo NCL.
Igual para qualquer outro objeto de mdia, o elemento <media>
representando um objeto hipermdia com cdigo declarativo pode definir
ncoras de contedo (atravs do elemento <area>) e propriedades (atravs do
elemento <property>). Tambm igual para qualquer outro objeto de mdia, o
atributo descriptor, opcional, deve referir-se a um elemento <descriptor> que
responsvel pela iniciao de propriedades necessrias apresentao do
objeto, como, por exemplo, sua posio na tela em que ser exibido e em que
dispositivo de exibio.
Cabe ao exibidor do objeto hipermdia declarativo a responsabilidade de
interpretar a semntica associada a suas ncoras de contedo, propriedades e
descritor associado.
O descritor pode definir, alm do exibidor que dever ser utilizado, uma
srie de propriedades que serve para iniciar esse exibidor. Por exemplo, no
caso de um objeto de mdia de tipo application/x-ncl-NCL, seu exibidor,
um formatador NCL, capaz de obedecer semntica NCL usual dessas
propriedades e iniciar valores do objeto settings, contido no objeto hipermdia
declarativo, com os valores passados pelo descritor. Por exemplo, a regio
<media id=objetoNCLembutido src=exe.ncl descriptor=nclDesc/>
312
especificada pelo descritor utilizada para iniciar a varivel
system.screenSize do novo documento NCL sendo iniciado.
2

14.2 Interfaces de Objetos de Hipermdia
Declarativos
Objetos hipermdia declarativos podem definir ncoras de contedo
(atravs do elemento <area>) e propriedades (atravs do elemento
<property>), como usual para todo objeto de mdia de uma aplicao NCL.
14.2.1 ncoras de Contedo
Um objeto hipermdia com cdigo declarativo visto pelo formatador
NCL como composto de uma srie de cadeias temporais (o Apndice F
apresenta uma discusso detalhada do conceito). Uma cadeia temporal
corresponde a uma sequncia de eventos (ocorrncias no tempo), iniciada pelo
evento que corresponde ao incio da apresentao do objeto hipermdia
declarativo. Como existem eventos imprevisveis, isto , eventos cuja
ocorrncia no tempo s pode ser determinada durante a apresentao do
objeto de mdia declarativo (como, por exemplo, as interaes do
telespectador), a cadeia temporal por inteiro s pode ser determinada quando
o ltimo evento imprevisvel ocorrer. Assim, pela nossa definio de contedo
de um objeto hipermdia declarativo, pode no ser possvel determin-lo a
priori em todos os casos.
Como exemplo, vamos retomar a nossa velha conhecida animao de O
Primeiro Joo, do Captulo 3, agora em nova verso. Durante o vdeo da
animao, uma propaganda de chuteira, representada por um objeto
hipermdia declarativo, ser apresentada, como no Captulo 3, mas agora em
um dispositivo secundrio (o leitor no deve se preocupar neste captulo com
detalhes da exibio em mltiplos dispositivos; eles sero aprofundados no
Captulo 15). No perodo da possvel exibio da propaganda, um cone
exibido no dispositivo primrio, a tela de uma TV (canto superior direito da
Figura 14.1). Ao mesmo tempo, um cone da chuteira exibido no dispositivo
secundrio e, se selecionado, dispara a exibio de um vdeo, propaganda da
chuteira, e de um formulrio HTML, para compra; tudo sobre uma imagem
de fundo no dispositivo secundrio, como ilustra a Figura 14.1. Ao trmino

2
Outras variveis system.screenSize(i) podem ser iniciadas por parmetros do descritor passados em
seus elementos <descriptorParam>. Como todo objeto de mdia, todas essas propriedades podem tambm ser
definidas por elementos <property> do objeto hipermdia declarativo.
313
do vdeo de propaganda, toda a exibio no dispositivo secundrio
finalizada.

Figura 14.1 Exibio do objeto hipermdia declarativo NCL em dispositivo secundrio.
A Figura 14.2 apresenta a viso estrutural dessa nova verso da
aplicao NCL.
Stop
onBegin
Start
Start
onEnd
Start
Start
onSelection
Start
Stop
Stop
NCLAdvert

Figura 14.2 Viso estrutural de O Primeiro Joo com objeto hipermdia declarativo NCL.
O objeto hipermdia declarativo NCLAdvert da Figura 14.2 define a
cadeia temporal, nica, da Figura 14.3, que comea com o incio da
apresentao (evento de apresentao) do cone da chuteira. Aps seu incio,
o cone da chuteira pode ser selecionado (evento imprevisvel de seleo) em
qualquer instante de tempo X, fazendo com que a cadeia continue conforme
a coluna da direita da Figura 14.3 ou, ento, caso no haja seleo, a cadeia
termina, com o fim da apresentao do cone da chuteira, que tem um tempo
mximo de exibio de seis segundos. Devemos salientar que, embora nesse
exemplo s tenhamos uma cadeia temporal, existem casos em que o contedo
do objeto hipermdia declarativo define mais de uma cadeia. Isso acontecer,
314
por exemplo, se o objeto hipermdia declarativo NCL tiver mais de uma porta
de entrada.
Incio, Apresentao, cone da
chuteira
0s Incio, Seleo, cone da
chuteira
(0+X) s
Fim, Apresentao, cone da
chuteira
(0+X) s
Incio, Apresentao, imagem
de fundo
(0+X) s
Incio, Apresentao, vdeo de
propaganda
(0+X) s
Fim, Apresentao, cone da chuteira 6s Incio, Apresentao, formulrio
HTML
(0+X) s
Fim, Apresentao, vdeo de
propaganda
(X+13) s
Fim, Apresentao, formulrio
HTML
(X+13) s
Figura 14.3 Cadeia temporal de NCLAdvert.
Embora o contedo de um objeto hipermdia declarativo nem sempre
possa ser definido a priori, ncoras de contedo podem ser definidas, como
sempre, por meio de elementos <area>.
ncoras de contedo podem definir trechos nas cadeias temporais, por
meio do atributo clip do elemento <area>. O valor do atributo clip dado por
(chainId, beginOffset, endOffset).
O parmetro chainId identifica uma das cadeias temporais definidas
pelo objeto hipermdia com cdigo declarativo. Os parmetros beginOffset e
endOffset determinam o tempo de incio e de fim da ncora de contedo,
respectivamente, relativo ao incio da cadeia. Na grande maioria das vezes,
um objeto hipermdia com cdigo declarativo define apenas uma nica cadeia;
nesse caso, o parmetro chainId pode ser omitido. Da mesma forma, os
parmetros beginOffset e endOffset podem ser omitidos, quando ento
assumem seus valores default: 0s e o valor correspondente ao tempo final
da cadeia, respectivamente.
No caso especfico de um objeto hipermdia declarativo com cdigo
NCL, uma cadeia identificada pela porta de entrada do corpo da aplicao
NCL, identificada pelo atributo src do objeto hipermdia declarativo:
elemento <port>, filho do elemento <body> do documento NCL que define o
contedo do objeto hipermdia declarativo. Na Listagem 14.2, vemos uma
ncora que inicia quando a cadeia entry (identificador de uma porta do
elemento <body> de exemplo.ncl) atingir cinco segundos e termina junto
com o fim da cadeia.
315

Listagem 14.2 ncoras de contedo em objetos de mdia declarativos.
Uma ncora de contedo de um objeto hipermdia declarativo pode
tambm fazer referncia a qualquer ncora de contedo definida internamente
no prprio cdigo declarativo identificado pelo atributo scr do objeto
hipermdia declarativo. Nesse ltimo caso, o atributo label do elemento
<area> deve ser usado. ele que define a ncora de contedo e deve ter um
valor tal que o exibidor do objeto hipermdia declarativo seja capaz de
identificar uma de suas ncoras de contedo definidas internamente. A
mquina de estado de eventos da ncora definida , nesse caso, idntica da
ncora de contedo que ela referencia.
Como exemplo, no caso de um objeto de mdia do tipo application/x-
ncl-NCL, uma de suas ncoras de contedo (elemento <area> do objeto
hipermdia declarativo) deve obrigatoriamente fazer referncia a uma porta,
filha direta do elemento <body> do objeto, por meio do atributo label, que
deve ter como valor o identificador da porta. Essa porta, por sua vez, pode ser
mapeada em uma ncora de contedo (elemento <area>) de algum objeto
interno ao objeto hipermdia declarativo. Note, assim, que um objeto
hipermdia declarativo pode externar ncoras de contedo definidas
internamente para manipulao por elos definidos no documento NCL pai que
contm o objeto hipermdia declarativo.
Como usual na NCL, um objeto hipermdia declarativo sempre define
uma ncora representando o contedo total do n. Essa ncora, que ns
anteriormente conhecemos com o nome ncora de contedo total,
declarada por omisso (default). Essa ncora tem, entretanto, um sentido
especial em um objeto hipermdia declarativo. Ela representa a apresentao
de todas as cadeias definidas pelo objeto. Quando o objeto declarativo sofre
uma instruo start sem especificar nenhuma ncora, a ncora de contedo
total assumida, como usual, e todas as cadeias tm sua exibio disparada
em paralelo.
14.2.2 Propriedades
Um elemento <property>, filho de um elemento <media> com cdigo
declarativo, pode ser usado em NCL para parametrizar o comportamento do
<media id=objetoNCLembutido src=exemplo.ncl

descriptor=nclDesc>

<area id=ancora1 clip=(entry,5s,)/>
</media>
316
exibidor do objeto. Semelhante s ncoras de contedo, cabe ao exibidor de
mdia a responsabilidade de interpretar a semntica de cada propriedade.
As propriedades so atributos do n de mdia como um todo. No caso de
um objeto hipermdia com contedo declarativo, elas podem ser as
propriedades usuais de um objeto de mdia, como left, height, explicitDur,
soundLevel etc., como tambm fazer referncia a qualquer varivel (ou
propriedade) interna do objeto hipermdia declarativo. Nesse ltimo caso, o
atributo name do elemento <property>, que define a propriedade, deve ter um
valor tal que o exibidor do objeto hipermdia com contedo declarativo seja
capaz de identificar uma de suas variveis (ou propriedades) definida
internamente.
Como exemplo, no caso de um objeto de mdia do tipo application/x-
ncl-NCL, uma de suas propriedades (elemento <property> do objeto
hipermdia com cdigo declarativo) pode fazer referncia a uma porta, filha
direta do elemento <body> do objeto, por meio de seu atributo name, que
deve ter como valor o identificador da porta. Essa porta, por sua vez, pode ser
mapeada em uma propriedade (elemento <property>) de algum objeto interno
ao objeto hipermdia com contedo declarativo, incluindo o objeto settings.
Note, assim, que um objeto hipermdia declarativo pode externar propriedades
definidas internamente para manipulao por elos definidos no documento
NCL pai que contm o objeto hipermdia declarativo.
Na Listagem 14.3 temos duas propriedades definidas. A primeira se
refere ao atributo bounds do n de mdia com contedo declarativo,
especificando seu posicionamento na tela de exibio. A segunda se refere a
uma porta do elemento <body> do objeto de mdia, cujo identificador dado
pelo valor globalName. Essa porta, por sua vez, mapeada em uma
propriedade definida internamente em um dos elementos filhos do objeto de
mdia.

Listagem 14.3 Propriedades em objetos de mdia declarativo.
Cada mudana no valor de uma varivel (ou propriedade) interna
realizada pela execuo do objeto hipermdia com contedo declarativo
refletida no valor da propriedade correspondente desse objeto. Essa mudana
pode servir de condio para o disparo de elos internos ao documento NCL
pai do objeto hipermdia com contedo declarativo.
<media id=objetoNCLembutido src=exemplo.ncl

descriptor=nclDesc>
<property name=bounds/>
<property name=globalName/>
<area id=ancora1 label=(entry, 5s,)/>
</media>
317
Da mesma forma, cada mudana em uma propriedade de um objeto
hipermdia com contedo declarativo sofrida por aes externas se reflete no
valor da varivel (ou propriedade) correspondente, interna ao objeto. Essas
mudanas tambm podem servir para disparo de procedimentos internos aos
objetos hipermdia declarativos. Por exemplo, em um objeto de mdia do tipo
application/x-ncl-NCL, essas mudanas podem servir de condies para
disparo de elos internos ao objeto de mdia.
14.3 Exemplo O Primeiro Joo
Nesta seo vamos completar o exemplo iniciado na Seo 14.2.1 sobre
a aplicao O Primeiro Joo, ilustrada na viso estrutural da Figura 14.2.
Para comear, vamos codificar o objeto hipermdia declarativo NCL,
como ilustrado na Listagem 14.4. A essa altura do livro, a codificao
dispensa explicaes, mas vamos salientar dois pontos. Primeiro, note que o
pano de fundo da aplicao foi especificado para ocupar toda a regio que lhe
for passada pelo descritor do objeto hipermdia declarativo. Segundo, observe
que a aplicao comea pela porta de entrada interaction do elemento
<body>. Ele representa a cadeia temporal definida pelo objeto.

<ncl id="NCLadvert"
<head>
<regionBase>
zIndex="1">
<region id="iconReg" width="100%" height="100%"
zIndex="2"/>
<region id="formReg" left="50%" top="5%" width="45%"
</region>
</regionBase>
<descriptorBase>
<descriptor id="formDesc" region="formReg"
focusIndex="1"/>
explicitDur="6s"/>
318
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>
<body>
<port id="interaction" component="icon"/>
<link id="lBeginAdvert"

<bind role="onSelection" component="icon"/>
<bind role="start" component="background"/>
</link>
<link id="lEndShoes" xconnector="conEx#onEndStop">
<bind role="stop" component="ptForm"/>
</link>
</body>
</ncl>
Listagem 14.4 Codificao do objeto hipermdia NCLAdvert.
Voltando viso estrutural da Figura 14.2, podemos agora definir a
aplicao NCL pai, como ilustrado pela Listagem 14.5. Vrios pontos da
especificao merecem ser destacados:
1. Uma ncora anchor2 definida para o objeto hipermdia declarativo
NCLAdvert fazendo referncia cadeia temporal iniciada pela porta
interaction. Na Listagem 14.4, essa porta do elemento <body> indica que a
cadeia deve ser apresentada, iniciando-se pela exibio do cone da chuteira.
2. Pelo descritor nclDesc passado para a exibio do objeto de mdia
NCLAdvert, a exibio deve ocupar toda a tela (100% nas duas dimenses,
319
como especificado) do dispositivo secundrio. Pela Listagem 14.4, o cone da
chuteira ocupa toda essa regio delimitada para o dispositivo secundrio.
3. Pela Listagem 14.5, o objeto de mdia NCLAdvert define uma aplicao
NCL filha da aplicao NCL identificada por glue. Contudo, a aplicao
NCLAdvert, da Listagem 14.4, tambm embute um outro objeto hipermdia
declarativo: o objeto ptForm, contendo cdigo declarativo HTML. Vemos,
assim, um aninhamento de objetos de mdia declarativos que bastante
comum em aplicaes para mltiplos dispositivos, como veremos no Captulo
15. Mais ainda, o objeto declarativo HTML pode embutir outra aplicao
NCL, recursivamente. E mais ainda, o objeto declarativo HTML pode
embutir cdigo imperativo ECMAScript. Um objeto hipermdia com cdigo
declarativo sempre pode embutir outros objetos quaisquer.
4. Devemos observar que o link l01, ao iniciar o objeto hipermdia
declarativo, declarado na Listagem 14.5 com a propriedade focusIndex=1,
passa-lhe o controle das teclas de navegao, ao atribuir o valor 1
propriedade service.currentKeyMaster do objeto settings.
5. Por ter o foco, o cone da chuteira selecionado pela tecla ENTER do
controle remoto. Na verdade, se a propriedade service.currentKeyMaster do
objeto settings no tivesse sido colocada em 1, no haveria problema, pois o
foco recairia no cone da chuteira de qualquer jeito, pois ele o nico que tem
o focusIndex entre os objetos sendo exibidos. No entanto, isso exigiria que a
tecla ENTER fosse pressionada duas vezes: uma para que o objeto
NCLAdvert ganhasse o controle das teclas de navegao e, mais uma vez,
para que a seleo da chuteira fosse efetivada.
6. Quando o cone da chuteira selecionado, o vdeo propaganda comea a
ser exibido, bem como o formulrio HTML que, por ter a propriedade
focusIndex=1, ganha o foco para navegao. O acionamento da tecla
ENTER faz com que esse objeto ganhe o controle das teclas de navegao.
7. Finalmente, devemos notar que o acionamento da tecla BACK do
controle remoto tira o controle da navegao do documento HTML, passando
para o objeto de mdia NCLAdvert, embora o foco continue sobre o
documento HTML. Um novo acionamento da tecla BACK retira o controle
da navegao do objeto NCLAdvert, passando para a aplicao NCL pai.

<ncl id="glue"
<head>
<regionBase>
<region id="videoReg" width="100%" height="100%"
zIndex="1">
320
<region id="imageReg" left="87.5%" top="11.7%"
</region>
</regionBase>
<region id="nclReg" width="100%" height="100%"
zIndex="1"/>
</regionBase>
<descriptorBase>
<descriptor id="videoDesc" region="videoReg"/>
<descriptor id="imageDesc" region="imageReg"
explicitDur="6s"/>
<descriptor id="nclDesc" region="nclReg"
focusIndex="1"/>
</descriptorBase>
<connectorBase>
<causalConnector id="onBeginStartSet_var">
<connectorParam name="var"/>
<simpleAction role="start" max="unbounded"
qualifier="par"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<simpleAction role="stop" max="unbounded"
qualifier="par"/>
</causalConnector>
</connectorBase>
</head>
<body>
<media id="animation" type="video/mpeg"
src="../media/animGar.mp4" descriptor="videoDesc">
<area id="anchor1" begin="10s" end="30s"/>
</media>
<media id="secIcon" type="image/png"
src="../media/icon.png" descriptor="imageDesc"/>
<media id="NCLAdvert" type="application/x-ncl-ncl"
src="../media/advert.ncl" descriptor="nclDesc">
<area id="anchor2" `clip="(interaction,,)"/>
</media>
<media id="globalVar"
321
type="application/x-ginga-settings">
<property name="service.currentKeyMaster"/>
</media>
<link id="l01" xconnector="onBeginStartSet_var">
interface="anchor1"/>
<bind role="start" component="secIcon"/>
<bind role="start" component="NCLAdvert"
interface="service.currentKeyMaster">
<bindParam name="var" value="NCLAdvert"/>
</bind>
</link>
<link id="l02" xconnector="onEndStop">
<bind role="stop" component="secIcon"/>
<bind role="stop" component="NCLAdvert"/>
</link>
</body>
</ncl>
Listagem 14.5 Aplicao O Primeiro Joo com objeto hipermdia declarativo.
Bibliografia
Soares, L.F.S. Nested Context Language 3.0 Part 11 Declarative
Objects in NCL: Nesting Objects with NCL Code in NCL
Documents. Monografias em Cincia da Computao do Departamento
de Informtica, PUC-Rio, N. 12/09. Rio de Janeiro, maro de 2009.
ISSN 0103-9741.
[Soares et al. 2009] Relating Declarative and Imperative Objects through
the NCL Glue Language. Soares, L. F. G.; Moreno, M.F;
SantAnna, F. Proceedings of the ACM Symposium on Document
Engineering. Munich, Alemanha. Setembro de 2009.

322
Captulo
15

Programando para
Mltiplos
Dispositivos
Um documento NCL pode ser exibido em mltiplos dispositivos. Esses
dispositivos podem se registrar em classes de dois tipos: aquelas em que seus
dispositivos membros devem ser aptos para executar exibidores de mdia e
aquelas, ditas passivas, em que no exigido de seus dispositivos membros a
capacidade de processar as funes de um exibidor de mdia.
Este captulo apresenta as vrias formas de um documento NCL
especificar em que dispositivos sero exibidos seus objetos, e o
comportamento do formatador NCL e dos vrios exibidores de mdia nesses
dispositivos, ilustrando com alguns exemplos.
1

1
Este captulo foi baseia-se em Soares [2009]. O uso do material foi gentilmente cedido pelo
323
15.1 Especificando o Dispositivo de Exibio
Vamos comear este captulo com uma srie de definies. Chamamos
de dispositivos de execuo aos dispositivos capazes de processar
atividades de exibio. Para ns, entretanto, o mais importante definir os
chamados dispositivos de exibio, que o nome dado juno de um
dispositivo de execuo com seus dispositivos de sada (somente os de sada).
Vamos chamar de aparelho, ao conjunto dispositivo de execuo e seus
dispositivos de sada e entrada associados. Vamos tambm definir um
domnio como um conjunto de aparelhos. Finalmente, vamos chamar de
dispositivo-base o dispositivo de execuo que contm o formatador NCL
raiz de todo o documento a ser apresentado em um domnio, e de aparelho-
base o aparelho que contm esse dispositivo.
Como vimos no Captulo 6, cada elemento <regionBase> de um
documento NCL pode estar associado a uma classe de dispositivos onde
ocorrer a apresentao. Para identificar a associao, o elemento
<regionBase> define o atributo device, que pode ter os valores
systemScreen(i) ou systemAudio(i), sendo i um nmero inteiro maior ou
igual a zero. Quando o atributo no for especificado, nenhuma classe
associada, e a apresentao deve ocorrer no prprio dispositivo de exibio
que est executando a aplicao.
Dispositivos de execuo podem se cadastrar em classes
(systemScreen(i) ou systemAudio(i)) de um domnio. O nmero de
classes de um domnio pode ser obtido da varivel de ambiente
system.classNumber do n Settings. Um dispositivo pode pertencer a mais
de uma classe.
Relembrando ainda o Captulo 6, uma classe (i) escolhida define as
variveis globais de ambiente: system.screenSize(i),
system.screenGraphicSize(i) e system.audioType(i), especificadas no n
Settings.
15.1.1 Classes de Dispositivos
Existem dois tipos de classe de dispositivos de exibio: passiva e
ativa.
Um dispositivo de exibio que se cadastra em uma classe do tipo
ativa deve ser capaz de executar as funes de exibidores de objetos de
mdia, exigidos por essa classe, conforme discutido no Apndice H.
De um dispositivo de exibio que se cadastra em uma classe do tipo
passiva no exigida a capacidade de executar as funes de exibidores de
324
mdia. Ele deve ser capaz apenas de apresentar o mapa de memria de vdeo
que lhe passado e exibir as amostras de udio que lhe so passadas. O
exibidor de cada objeto de mdia, nesse caso, ser executado por um
dispositivo de execuo (chamado dispositivo pai), que responsvel pela
criao do mapa e do conjunto de amostras de udio que embute a
apresentao dos objetos.
O mapa criado (ou a sequncia de amostras de udio criada) pelo
dispositivo pai, para os dispositivos em classe passiva que comanda, pode
tambm ser exibido no prprio dispositivo pai. Para tanto, uma regio no
dispositivo pai deve ser referenciada pelo elemento <regionBase>, atravs de
seu atributo region, que define a classe passiva. Devemos ressaltar que o
atributo region de um elemento <regionBase> s ter algum sentido quando
esse elemento estiver associado a uma classe do tipo passiva.
Uma classe ativa deve especificar quais exibidores devem estar
disponveis em todos os seus dispositivos cadastrados.
Algumas simplificaes foram definidas para esse procedimento. Entre
elas assumido que, quando existir apenas um dispositivo de exibio, ele
no precisa se cadastrar. Na verdade, o dispositivo-base tem uma classe
(ativa) s para ele, em que nenhum outro dispositivo pode se cadastrar, e essa
classe no precisa ser declarada. As classes systemScreen (1) ou
systemAudio(1) so reservadas como classes passivas e as classes
systemScreen (2) ou systemAudio(2) como classes ativas, onde todos os
seus dispositivos de exibio cadastrados so capazes de executar todos os
exibidores de objetos mdia especificados pelo sistema que adotou a NCL
como linguagem, incluindo os exibidores de objetos imperativos, funcionais e
hipermdia declarativos.
Qualquer que seja o tipo de classe, passiva ou ativa, seus dispositivos de
exibio s podem exibir objetos de mdia vindos de um mesmo dispositivo,
chamado dispositivo pai. Uma classe no pode ter mais de um dispositivo
pai em um dado momento. Mais ainda, o dispositivo-base no pode receber
objetos (diretamente ou embutidos em mapas de memria/amostras de udio),
para exibir, de outro dispositivo exibidor do domnio. Em outras palavras,
no h possibilidade de um dispositivo ser ascendente ou descendente de si
mesmo, formando ciclos.
15.1.2 Comportamento dos Dispositivos de Entrada
No incio de uma apresentao, todos os dispositivos de entrada
associados ao domnio dos dispositivos do documento NCL que especifica a
aplicao so controlados pelo dispositivo-base.
325
Quando um elemento <media> em exibio por um dispositivo
registrado em uma classe ativa receber o foco e for selecionado, o exibidor de
seu contedo ganha o controle de todos os dispositivos de entrada do mesmo
aparelho do dispositivo de exibio e dos dispositivos de entrada de todos os
dispositivos que esto em classes que sero suas descendentes. O exibidor
pode, ento, seguir suas prprias regras para navegao. O controle dos
dispositivos de entrada devolvido ao dispositivo pai quando a tecla de
mnemnico BACK for pressionada. Nesse caso, o foco vai para o elemento
identificado pelo atributo service.currentFocus do n settings (elemento
<media> do tipo application/x-ncl-settings) em exibio controlada pelo
dispositivo pai.
Devemos notar que pode haver mais de um dispositivo com controle de
navegao por teclas, mas cada um com dispositivos de entrada diferentes dos
outros.
De posse de todas as informaes desta Seo 15.1, podemos agora
analisar as vrias alternativas para exibio em mltiplos dispositivos.
15.2 Comportamento de Dispositivos na Classe
Passiva
Como comentamos anteriormente, no caso de uma classe passiva, todo o
processamento de um exibidor de mdia estar a cargo de um dispositivo de
exibio capaz de executar exibidores de objetos de mdia, que chamamos de
dispositivo pai.
Nesse caso, o dispositivo pai se comunica com os dispositivos de
exibio da classe (dispositivos filhos) passando ou o mapa de memria do
plano de exibio (frame buffer), no caso de dispositivos visuais, ou amostras
de udio, no caso de dispositivos com sada sonora. Um dispositivo de
exibio visual deve apenas ser capaz de varrer a matriz e apresentar os
pixels correspondentes em sua tela. Um dispositivo de exibio sonora deve
apenas ser capaz de varrer e apresentar as amostras de udio na caixa de
som.
Ainda que mais de um dispositivo de exibio seja associado a uma
mesma classe, quando um elemento <media> for exibido nessa classe, apenas
uma nica instncia de exibio deve ser criada (no dispositivo pai) e
compartilhada por todos os dispositivos. No jargo do modelo NCM, um
objeto de representao nico criado e exibido em todos os dispositivos
filhos.
importante salientarmos que no existe zIndex para os mapas de
memria/amostras de udio nos dispositivos filhos. Todos so exibidos com
326
zIndex=0. Se vrios mapas/amostras so recebidos, apenas o ltimo recebido
ser exibido.
Se um elemento <media>, em exibio na classe passiva, receber o foco
e for selecionado, o exibidor de seu contedo ganhar o controle do foco (ou
seja, de todos os dispositivos de entrada controlados pelo dispositivo pai). O
exibidor pode ento seguir suas prprias regras para navegao. O controle
de foco devolvido ao dispositivo pai quando a tecla BACK for
pressionada.
A Figura 15.1 retoma o exemplo da Seo 3.7 (Figura 3.9), O Primeiro
Joo, com algumas pequenas modificaes para que o contexto da
propaganda no seja mais exibido no dispositivo-base (tela principal), mas em
dispositivos secundrios registrados em uma dada classe passiva. Como o
cone da chuteira no mais ser exibido na tela principal, vamos introduzir
uma nova imagem (um novo cone), a ser apresentada na tela principal apenas
como aviso de que h informaes no dispositivo secundrio. Uma vez que o
vdeo principal (vdeo da animao) no ser mais redimensionado, a imagem
de fundo foi colocada dentro do contexto da propaganda (para servir de fundo
no dispositivo que apresentar a propaganda), e os elos para o
redimensionamento do vdeo principal foram retirados; como consequncia,
uma vez que no mais existiro relacionamentos com o vdeo principal dentro
do contexto de propaganda, o reuso do vdeo foi retirado do contexto. A porta
para o contexto de propaganda, mapeada para o cone da chuteira, foi
reintroduzida. Finalmente, o final da exibio do vdeo de propaganda
terminar com todo o contexto da propaganda, e no mais um tempo fixo
para a manipulao do formulrio para compra. Recordando o Captulo 3,
agora j com as modificaes, nossa aplicao, bem simples, ilustra como
fcil, em NCL, introduzir vrios objetos de mdia sincronizados no tempo em
mltiplos dispositivos:
1. uma msica de fundo (um chorinho) (<media id="choro" .../>), que
comea assim que termina a apresentao inicial do vdeo e inicia a
animao propriamente dita;
2. um objeto de vdeo (<media id="drible" ...>), que exibido em paralelo e
sincronizado com o famoso drible do vaivm do Man, retratado na
animao;
3. uma imagem (<media id="photo" .../>), uma foto, que exibida junto com
a cena do marcador cado no cho, aps mais um drible desconcertante;
4. uma imagem, um cone, sinalizando a existncia de contedo em
dispositivos secundrios, que exibida quando o marcador do Man cai no
cho de pernas para o alto;
327
5. uma imagem, um cone, de uma chuteira (<media id="icon" .../>), que
exibida para seleo por interatividade, quando o marcador do Man cai
no cho de pernas para o alto, nos dispositivos secundrios;
6. uma imagem de fundo (<media id="background" .../>), exibida nos
dispositivos secundrios quando o cone do item anterior for selecionado
atravs da tecla vermelha do controle remoto;
7. um formulrio (<media id="ptForm" ...) exibido nos dispositivos
secundrios quando for iniciada a apresentao da imagem de fundo;
8. um vdeo de propaganda da chuteira (<media id="shoes" .../>), tambm
exibido nos dispositivos secundrios quando iniciada a apresentao da
imagem de fundo e que, ao final de sua apresentao, termina a imagem de
fundo e o formulrio.
Toda a apresentao do contexto da propaganda (cone da chuteira,
vdeo da propaganda, imagem de fundo e formulrio) definida dentro do
contexto (<context id="advert" ...>), como anteriormente. So os objetos
desse contexto que queremos exibir em um dispositivo diferente do da
exibio dos outros objetos de mdia do exemplo, cuja viso estrutural da
aplicao apresentada na Figura 15.1.
Stop
onBegin
Start
onBegin
Start
onEnd
onBegin
Start
Start
onBegin
Start
Stop
onEnd
Start
onSelection
Stop
Stop
Start
Start

Figura 15.1 Viso estrutural da nova verso do exemplo O Primeiro Joo.
Na Listagem 15.1, o documento NCL do exemplo apresentado. Note a
definio de duas bases de regies. A primeira define onde sero exibidos
todos os objetos, exceto os relacionados propaganda dentro do contexto da
Figura 15.1. Essa base de regies no especifica o atributo device, indicando
por omisso (default) que os objetos devem ser exibidos no dispositivo-base
328
(que executa o documento NCL). A segunda, identificando o dispositivo
systemScreen(1), define onde sero exibidos todos os objetos da
propaganda (vdeo da propaganda, imagem de fundo e formulrio).

<ncl id="devices" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="secIconReg" left="87.5%" top="11.7%" width="8.45%"
</region>
</regionBase>
zIndex="1">
<region id="iconReg" width="100%" height="100%" zIndex="2"/>
</region>
</regionBase>
<descriptorBase>
<descriptor id="secIconDesc" region="secIconReg"
explicitDur="6s"/>
<descriptor id="formDesc" region="formReg" focusIndex="1"/>
</descriptorBase>
<connectorBase>
</connectorBase>
</head>
<body>
</media>
<media id="secIcon" src="../media/secIcon.png"
329
descriptor="secIconDesc"/>
<link id="lBegingAdvert"
</bind>
</link>
</link>
</context>
</bind>
</link>
</link>
</link>
</link>
<bind role="onBegin" component="animation" interface="segIcon"/>
<bind role="start" component="advert" interface="pIcon"/>
</link>
</body>
</ncl>
Listagem 15.1 O Primeiro Joo com mltiplos dispositivos de exibio.
330

Devemos notar que, se no exemplo o cone da chuteira for selecionado, o
vdeo da propaganda e o formulrio aparecero em todos os dispositivos
cadastrados como systemScreen(1), como apresenta a Figura 15.2. Caso o
formulrio seja selecionado em um desses dispositivos, qualquer navegao
feita por qualquer dispositivo de entrada controlado pelo dispositivo pai ser
exibida em todos os dispositivos de sada cadastrados em systemScreen(1).
Caso queiramos que a navegao no formulrio seja individual em cada
dispositivo, a soluo da prxima seo deve ser adotada.

Figura 15.2 Mltiplos dispositivos em classe passiva com mapas de memrias idnticos.
A Listagem 15.1 mostra como fcil especificar a apresentao em
mltiplas classes de dispositivos. Apenas um elemento (<regionBase
device="systemScreen(1)">) teve de ser adicionado para distinguir a
apresentao em mltiplos dispositivos daquela onde todos os objetos seriam
apresentados apenas no aparelho de TV.
Em NCL, o mapa de vdeo apresentado nos dispositivos secundrios
pode tambm ser apresentado em uma regio do dispositivo pai. Para tanto,
suficiente que adicionemos um atributo ao elemento <regionBase>, que define
a classe passiva systemScreen(i), referindo-se a uma regio filha do
elemento <regionBase> associado ao dispositivo pai. A Listagem 15.2 ilustra
o procedimento para o exemplo da Listagem 15.1.

331

<head>
...
<regionBase>
<region id="memoryMap" left="87.5%" top="87.5%" width="10%" ...
...
</region>
</regionBase>
<regionBase device="systemScreen(1)" region="memoryMap">
...
</regionBase>
...
</head>
Listagem 15.2 Mapa de memria de vdeo apresentada no dispositivo pai.
15.3 Comportamento de Dispositivos na Classe
Ativa
No caso de uma classe ativa, todo o processamento para exibio de um
objeto de mdia a ela direcionado ser delegado aos dispositivos registrados
na classe, pelo que chamamos anteriormente de dispositivo pai.
Quando mais de um dispositivo de exibio for associado a uma mesma
classe ativa, e um elemento <media> for exibido nessa classe, uma instncia
de exibio deve ser criada pelo exibidor de cada dispositivo. No jargo do
modelo NCM, um objeto de representao criado em cada dispositivo e
controlado por ele. Na definio de um elo, elementos <bind> que se referem
a esse elemento <media> devem ter seu atributo de cardinalidade max com o
valor unbounded.
Toda ao de apresentao ou atribuio (stop, abort, pause e resume)
realizada sobre o elemento <media> cujas vrias instncias de exibio foram
criadas deve refletir em todas as instncias. As aes devem ser aplicadas em
qualquer ordem. Qualquer condio derivada desse elemento <media>
considerada satisfeita somente quando a condio for satisfeita em todas as
instncias (simultaneamente ou no), se o atributo qualifier do elemento
<bind> for igual a and, ou se a condio for satisfeita em pelo menos uma
instncia, se o atributo qualifier do elemento <bind> for igual a or.
Enquanto nenhum dos elementos <media> em exibio nessa classe for
selecionado (aps receber o foco), toda a interao do usurio nos diversos
dispositivos de entrada passada ao dispositivo pai.

332

Se um elemento <media> em exibio nessa classe receber o foco e for
selecionado, o exibidor de seu contedo ganha o controle do foco (ou seja, de
todos os dispositivos de entrada do mesmo aparelho do dispositivo de
exibio e de todos os aparelhos cujo dispositivo de exibio estiver em
classes que sero suas descendentes, como vimos na Seo 15.1.2) para
navegao por teclas (Key Navigation). O exibidor pode ento seguir suas
prprias regras para navegao. O controle de foco devolvido ao dispositivo
pai quando a tecla de mnemnico BACK for pressionada.
A Figura 15.3 retoma o exemplo da seo anterior. Nela o contexto de
propaganda foi substitudo por um objeto de mdia NCL, elemento <media
type=application/x-ncl-NCL .../>, por ns discutido no Captulo 14. De
resto, tudo muito parecido com o exemplo anterior, como mostra a viso
estrutural na figura.
Stop
onBegin
Start
onBegin
Start
onEnd
Start
Start
onBegin
Start
Stop
onEnd
Start
Start
onSelection
Start
Stop
Stop
onBegin

Figura 15.3 Viso estrutural com objeto de mdia do tipo application/x-ncl-NCL.
Na Figura 15.3, toda a parte interna do objeto de mdia NCLAdvert
(elemento <media type=application/x-ncl-NCL) definida em um novo n
(documento) NCL, apresentado na Listagem 15.3.
333

<ncl id="advert" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="iconReg" width="100%" height="100%" zIndex="2"/>
</region>
</regionBase>
<descriptorBase>
<descriptor id="formDesc" region="formReg" focusIndex="1"/>
</descriptorBase>
<connectorBase>
alias="conEx"/>
</connectorBase>
</head>
<body>
<media id="shoes" src="../media/shoes.mp4" descriptor="shoesDesc"/>
<link id="lBegingAdvert"
</bind>
</link>
</link>
</body>
</ncl>
Listagem 15.3 Documento NCL da propaganda da chuteira.
334
Queremos que, na nova verso do documento da aplicao O Primeiro
Joo com o novo objeto de mdia NCLAdvert, uma vez que o cone de
existncia de informao em dispositivos secundrios seja exibido, o novo
objeto de mdia seja apresentado em outra classe de dispositivos de exibio,
e tambm queremos que, ao iniciar a apresentao de tal objeto, ele ganhe o
controle dos dispositivos de entrada do aparelho correspondente ao dispositivo
de exibio. Como vimos anteriormente, uma vez que so criadas instncias
para cada dispositivo de exibio da classe, cada dispositivo de exibio ter
uma navegao independente.
Para passar o controle dos dispositivos de entrada para o objeto de
mdia NCLAdvert, a varivel global service.currentKeyMaster do elemento
<media type="application/x-ncl-settings" ...> ser usada.
Primeiramente, tal varivel precisa ser definida em um elemento
<property>, para permitir seu uso no documento, como mostra a Listagem
15.4.

Listagem 15.4 Externalizao da propriedade service.currentKeyMaster.
Ao ser iniciada a apresentao do objeto de mdia NCLAdvert, o
controle do foco deve ser passado a ele pelo mesmo elo usado para sua
iniciao, como mostra a Listagem 15.5. Uma vez que a apresentao da
propaganda iniciada, como a propriedade service.currentKeyMaster
recebe o identificador do objeto NCLAdvert, o objeto recebe o controle da
navegao por teclas (Key Navigation) do aparelho de exibio
correspondente.
<link id="lBeginAdvert" xconnector="conEx#onBeginSet_varStart">
<bind role="start" component="NCLAdvert"/>
</bind>
</link>
Listagem 15.5 Iniciao e passagem de controle para o objeto de mdia NCLAdvert.
O documento completo dessa nova verso da aplicao O Primeiro
Joo apresentado na Listagem 15.6.
</media>
335

<ncl id="indDevices" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="secIconReg" left="87.5%" top="11.7%"
</region>
</regionBase>

<region id="NCLAdvertReg" width="100%" height="100%" zIndex="1"/>
</regionBase>

<descriptorBase>
<descriptor id="secIconDesc" region="secIconReg"
explicitDur="6s"/>
<descriptor id="NCLAdvertDesc" region="NCLAdvertReg"/>
</descriptorBase>
<connectorBase>
</connectorBase>
</head>
<body>
</media>
</media>
336
<media id="secIcon" src="../media/icon.png"
descriptor="secIconDesc"/>
<media id="NCLAdvert" src="advert.ncl" descriptor="NCLAdvertDesc"/>
</bind>
</link>
</link>
<bind role="onBegin" component="animation" interface="segPhoto"/>
</link>
</link>
<link id="lBeginAdvert" xconnector="conEx#onBeginSet_varStart">
<bind role="start" component="NCLAdvert"/>
</bind>
</link>
</body>
</ncl>
Listagem 15.6 O Primeiro Joo com mltiplos dispositivos de exibio independentes.
A Figura 15.4 ilustra o mesmo momento definido na Figura 15.2, s que
para mltiplos dispositivos em classe ativa. Note que, por ser classe ativa, a
exibio pode ser diferente em cada dispositivo da classe (focalize a ateno
no formulrio, que na Figura 15.4 mostra a compra j efetuada).

337

Figura 15.4 Mltiplos dispositivos em classe ativa com exibies diferentes.
15.4 Comportamento de Dispositivos Cadastrados
nas Classes Ativa e Passiva
Esta seo apenas ressalta que um mesmo dispositivo de exibio pode
estar cadastrado simultaneamente em classes passivas e ativas, desde que
todas sejam controladas por um mesmo dispositivo pai em um dado instante,
como usual. Nesse caso, ele herda o comportamento dos dois tipos de classe.
Recordando:
- um dispositivo de exibio s pode exibir objetos recebidos (diretamente
ou embutidos em mapas de memria/amostras de udio) pelas classes em
que se cadastrou, ou exibir objetos confinados (contidos) nos objetos
recebidos (por exemplo, um objeto de mdia dentro de um elemento
<media> recebido com contedo possuindo cdigo declarativo);
- o dispositivo-base no pode receber objetos (diretamente ou embutidos em
mapas de memria/amostras de udio) para exibir de outro dispositivo
exibidor do domnio;
- quando um objeto for recebido para exibio em uma classe ativa, uma
instncia independente ser criada para cada dispositivo de exibio da
classe e o comportamento deve ser igual ao descrito para aquela classe;
- quando objetos forem passados pela classe passiva atravs de mapa de
memria/amostras de udio, ser criada apenas uma instncia para cada
objeto, no aparelho do dispositivo exibidor que enviou o objeto.
338
No entanto, devemos ressaltar:
- No existe zIndex para os mapas de memria/amostras de udio. Todos
so exibidos com zIndex=0 nos dispositivos filhos. Se vrios mapas de
memria/amostras de udio forem recebidos, apenas o ltimo recebido
ser exibido. Toda exibio de objetos recebidos em uma classe ativa se
superpe aos mapas de memria/amostras de udio recebidos.
15.5 Formatador Distribudo
Um formatador NCL pode, por meio da anlise do seu grafo temporal
(veja Apndice G), descobrir que parte de uma cadeia temporal ser exibida
em uma classe ativa de dispositivos de exibio e que os dispositivos dessa
classe so capazes de exibir documentos NCL. Nesse caso, em vez de o
formatador instanciar a exibio de cada objeto de mdia no dispositivo de
destino, ele pode tirar proveito da situao e passar toda a cadeia para o
formatador NCL desse dispositivo, que ento se encarregar de instanciar
cada exibidor de mdia da cadeia.
Para o leitor interessado nessa opo recomendamos uma leitura atenta
do Apndice G.
15.6 Adaptando Mltiplos Dispositivos para um
Ambiente com um nico Dispositivo
Trabalhar com classes de dispositivos libera o autor de uma aplicao
NCL da preocupao de quantos e quais dispositivos esto registrados nas
classes, nmero que pode variar com o tempo de exibio de uma aplicao.
Entretanto, quando o nmero de dispositivos registrados em uma classe
zero, nenhum objeto de mdia endereado a essa classe ser apresentado.
Nesse caso, seria bem conveniente permitir ao autor especificar uma
apresentao alternativa, e isso possvel.
Conforme vimos no Captulo 7, o posicionamento inicial da
apresentao de um objeto de mdia determinado em NCL pelo elemento
<descriptor> referido pelo objeto. Esse elemento associa o objeto de mdia a
uma regio de apresentao que, por sua vez, est associada a uma classe de
dispositivos. Uma varivel global system.devNumber(i) do n settings
(<media type="application/x-ncl-settings" ...>) mantm o nmero de
dispositivos registrados em uma classe systemScreen(i). Assim, pelo
teste do valor dessa varivel, um elemento <descriptorSwitch> capaz de
selecionar uma regio dessa classe, caso haja algum dispositivo nela
registrado ou uma apresentao alternativa.
339
O exemplo da Listagem 15.7 ilustra a definio de uma regra que
satisfeita quando o nmero de dispositivos registrados na classe
systemScreen(2) zero. Se substituirmos o elemento <descriptor
id="NCLAdvertDesc" region="NCLAdvertReg"/> do exemplo da
Listagem 15.6 pelo elemento <descriptorSwitch
id="NCLAdvertDesc"> da Listagem 15.7 e, se no houver nenhum
dispositivo registrado na classe ativa systemScreen(2), a propaganda
definida pelo elemento <media id="NCLAdvert" src="advert.ncl">
ser exibida no aparelho de TV da classe-base, como ilustra a Figura 15.5.
<head>
<ruleBase>
<rule id="single" var="system.devNumber(2)" value="0"
comparator="eq"/>
</ruleBase>
<regionBase>
...
<region id="NCLAdvertSingleReg" left="5%" top="5%"
width="30%" height="30%" zIndex="2"/>
</region>
</regionBase>
<region id="NCLAdvertMultiReg" width="100%" height="100%"
zIndex="1"/>
</regionBase>

<descriptorBase>
...
<descriptorSwitch id="NCLAdvertDesc">
<bindRule constituent="NCLAdvertSingleDesc" rule="single"/>
<defaultDescriptor descriptor="NCLAdvertMultiDesc"/>
<descriptor id="NCLAdvertSingleDesc"
region="NCLAdvertSingleReg"/>
<descriptor id="NCLAdvertMultiDesc"
region="NCLAdvertMultiReg"/>
</descriptorSwitch>
</descriptorBase>
...
</head>
Listagem 15.7 Apresentao alternativa exibio em uma classe sem dispositivos
registrados.
340

Figura 15.5 Apresentao em um nico dispositivo por ausncia de registros em classes.
Bibliografia
ABNT, NBR 15606-2 (2011). Associao Brasileira de Normas Tcnicas,
N. 35/06. Rio de Janeiro, outubro de 2006. ISSN 0103-9741.
Soares, L.F.S. (2009). Nested Context Model 3.0 Part 12 Support to
Multiple Exhibition Devices. Monografias em Cincia da Computao
do Departamento de Informtica, PUC-Rio, N. 03/09. Rio de Janeiro,
janeiro de 2009. ISSN 0103-9741.

341
Captulo
16

Comandos de Edio
NCL
Comandos de edio NCL podem vir por diferentes modos: pela rede
(canal de difuso, canal de interatividade ou outra rede qualquer), atravs dos
objetos imperativos embutidos no prprio documento NCL, ou mesmo atravs
de alguma aplicao externa comandada por um usurio da aplicao.
Atravs de comandos de edio, documentos NCL podem ser criados e
modificados em tempo de exibio.
Este captulo descreve os comandos de edio NCL, deixando para o
Apndice F a discusso sobre a forma como esses comandos podem ser
transportados, tanto atravs de estruturas de dados recebidas sem solicitao,
como atravs de estruturas de dados recebidas sob demanda.
1

1
Este captulo foi baseado em Soares et al. [2006]. O uso do material foi gentilmente cedido pelo
342
16.1 Introduo
O ncleo da mquina de apresentao de documentos NCL composto
pelo formatador NCL e pelo mdulo Gerenciador de Base Privada.
O formatador NCL responsvel por receber um documento NCL e
controlar sua apresentao, tentando garantir que as relaes especificadas
entre os objetos de mdia sejam respeitadas. O formatador lida com aplicaes
NCL que so coletadas dentro de uma estrutura de dados conhecida como
base privada. Como exemplo, no Sistema Brasileiro de TV Digital Terrestre,
o middleware Ginga associa pelo menos uma base privada a um canal de
televiso.
Os documentos NCL em uma base privada podem ser iniciados,
pausados, retomados, parados e referir uns aos outros.
O Gerenciador de Base Privada responsvel por receber comandos de
edio de documentos NCL e pela execuo desses comandos, incluindo a
edio de documentos NCL ativos (documentos sendo apresentados), ou seja,
edies ao vivo.
Comandos de edio podem ser recebidos por diferentes vias. Por
exemplo, em um ambiente de TV digital terrestre usual adotar o protocolo
DSM-CC (ver Apndice B) para o transporte de comandos de edio gerados
pelos provedores das emissoras de TV. tambm possvel receber comandos
de edio pelo canal de interatividade ou mesmo diretamente do telespectador,
fazendo uso de uma aplicao residente no receptor. As diferentes vias de
recepo de comandos de edio so assunto do Apndice F.
16.2 Comandos de Edio NCL
Os comandos de edio NCL [Soares et al., 2006] so envelopados em
uma estrutura chamada descritor de evento. Cada descritor de evento (de
edio) tem uma estrutura composta basicamente por um id, uma referncia
de tempo e um campo de dados privados. A identificao define univocamente
cada evento de edio (e no cada tipo de comando). A referncia de tempo
indica o exato momento de disparar o evento. Tempo de referncia igual a
zero informa que o evento de edio deve ser disparado imediatamente aps
ser recebido (eventos carregando esse tipo de referncia de tempo so
comumente conhecidos como eventos do it now). O campo de dados
privados oferece suporte para identificao do comando e definio de
parmetros do evento de edio, como apresentado na Tabela 16.1.
Tabela 16.1 Descritor de Evento para Comandos de Edio
343
Sintaxe Nmero de Bits
EventDescriptor ( ) {
eventid 16
eventNPT 33
privateDataLength 8
commandTag 8
sequenceNumber 7
finalFlag 1
privateDataPayload 8 a 1928
FCS 8
}
O campo commandTag identifica univocamente os tipos de comandos
de edio, como especificado na Tabela 16.2. Para permitir o envio de um
comando completo com mais de 255 bytes em mais de um descritor de evento,
todos os descritores de um mesmo comando devem ser numerados e enviados
em sequncia (isto , no podem ser multiplexados com outros comandos de
edio com o mesmo commandTag), com o finalFlag igual a 1, exceto para o
ltimo descritor, que deve ter o campo finalFlag igual a 0. O campo
privateDataPayload contm os parmetros do comando de edio.
Finalmente, o campo FCS contm um checksum de todo o campo
privateData, inclusive o privateDataLength.
Os comandos de edio NCL so divididos em trs grupos: o primeiro
para operao da base privada (para abrir, ativar, desativar, fechar e salvar
bases privadas); o segundo para manipulao de documentos (para adicionar,
remover e salvar um documento em uma base privada aberta e para iniciar,
pausar, retomar e parar apresentaes de documentos em uma base privada
ativa); e o ltimo para manipular entidades NCL de um documento em uma
base privada aberta. Para cada entidade NCL, foram definidos os comandos
add e remove. Se uma entidade j existir, o comando add tem a semntica de
atualizao (alterao).
Os comandos add tm entidades NCL como seus argumentos
(parmetros de comando especificados em XML). As entidades so definidas
utilizando uma notao sinttica idntica quela usada pelos esquemas NCL
[Soares et al., 2006], com exceo do comando addInterface: o atributo
begin ou first de um elemento <area> pode receber o valor now,
especificando o NPT atual do objeto determinado pelo argumento nodeId (ver
Tabela 16.2). A consistncia do documento mantida pelo formatador NCL,
quer a entidade especificada j exista ou no, no sentido de que todos os
atributos de identidade obrigatrios tm de ser definidos. H apenas uma
exceo a essa regra - o atributo interface de um elemento <bind> filho de um
344
elemento <link> pode ser deixado inconsistente, referindo-se a um elemento
<area> a ser preenchido por um comando addInterface cujo atributo begin
possui o valor now". Nesse caso, o elemento <link> deve obrigatoriamente
ser avaliado assim que o comando addInterface for recebido.
Se o parmetro de comando baseado em XML for curto o suficiente, ele
pode ser transportado diretamente no payload dos descritores de evento. Se
no, o privateDatePayload transporta um conjunto de pares de referncia
{uri, id}, com a interpretao dada a seguir.
No caso de arquivos recebidos pelo canal de difuso (documentos NCL
ou objetos de documentos NCL enviados sem solicitao), cada par relaciona
um caminho de arquivo ou diretrio de arquivos e sua respectiva localizao
no sistema de transporte. No necessria a incluso de um par {uri, id} no
comando para cada arquivo enviado por difuso. Mas necessrio que a
partir dos pares {uri, id} includos no comando todo arquivo recebido possa
ter o seu caminho absoluto (uri) no sistema transmissor deduzido.
No caso de arquivos recebidos sob demanda pelo canal de interatividade
ou localizados no prprio receptor, nenhum par de referncias necessita ser
enviado, exceto se o arquivo for o da especificao do documento NCL ou da
especificao XML do objeto NCL que dever ser adicionado, segundo o
comando de adio correspondente. Nesse caso, o par {uri, null} deve ser
enviado especificando o caminho do arquivo a ser buscado.
A Tabela 16.2 mostra as strings de comando e, entre parnteses, os
parmetros transportados como contedo (payload) do descritor de evento de
edio (nclEditingCommand) [Soares et al., 2006].
Tabela 16.2 Comandos de Edio para o Gerenciador da Base Privada Ginga
String de Comando Tag de
Comand
o
Descrio
openBase (baseId, location) 0x00 Abre uma base privada existente, localizada pelo parmetro
location. Se a base privada no existir ou se o parmetro
location no for informado, uma nova base criada com o
identificador baseId. O parmetro location deve especificar o
dispositivo e o caminho onde est a base a ser aberta
activateBase (baseId) 0x01
Ativa uma base privada aberta. Todas as aplicaes ficam
ento aptas a serem iniciadas.
deactivateBase (baseId) 0x02
Desativa uma base privada aberta. Todas as suas aplicaes
devem ser terminadas.
saveBase (baseId, location) 0x03 Salva todo o contedo da base privada em um dispositivo de
armazenamento persistente (se disponvel). O parmetro location
deve especificar o dispositivo e o caminho para salvar a base
closeBase (baseId) 0x04 Fecha a base privada aberta e descarta todo o seu contedo
345
addDocument (baseId, {uri,
id}+)
0x05 Adiciona um documento NCL a uma base privada aberta. Os
arquivos do documento NCL podem ser:
1) Enviados pela rede de difuso de dados como um conjunto de
arquivos enviados sem solicitao; nesse caso, o par {uri, id}
usado para relacionar um conjunto de caminhos de arquivos
especificados no documento NCL com suas respectivas
localizaes no sistema de transporte (veja exemplos no
Apndice F)
NOTA O conjunto de pares de referncia deve ser suficiente
para que se possa mapear qualquer referncia a arquivos
presentes na especificao do documento NCL na sua
localizao concreta na memria do dispositivo receptor.
2) Recebidos sob demanda pelo canal de interatividade ou j
serem residentes no receptor; para esses arquivos, nenhum par
{uri, id} necessita ser enviado, exceto o par {uri, null}
associado ao documento NCL que dever ser adicionado na base
baseId, se o documento NCL no for recebido sem solicitao
(pushed file)
removeDocument (baseId,
documentId)
0x06 Remove um documento NCL de uma base privada aberta
startDocument (baseId,
documentId, interfaceId, offset,
nptBaseId, nptTrigger)

NOTA O parmetro offset
especifica um valor de tempo

NOTA O nptTrigger um
valor de NPT, e o nptBaseId
um identificador de uma base
de tempo NPT
0x07 Inicia a reproduo de um documento NCL em uma base
privada ativa, iniciando a apresentao a partir de uma interface
especfica do documento. A referncia do tempo transportada no
campo nptTrigger estabelece o ponto de incio do documento,
com respeito base de tempo NPT identificada pelo campo
nptBaseId. Trs casos podem ocorrer:
1) Se nptTrigger for diferente de zero e for maior ou igual ao
valor de NPT corrente da base temporal NPT identificada por
nptBaseId, espera-se at que NPT atinja o valor dado em
nptTrigger e comea a exibio do documento do seu ponto
incial no tempo+offset
2) Se nptTrigger for diferente de zero e for menor que o valor de
NPT corrente da base temporal identificada por nptBaseId, o
incio da exibio do documento imediata e deslocada no
tempo de seu ponto incial do valor offset+(NPT
nptTrigger)
seconds

NOTA Somente nesse caso o parmetro offset pode receber um
valor negativo, mas offset+(NPT nptTrigger)
seconds
deve ser um
valor positivo
3) Se nptTrigger for igual a 0, a exibio do documento
imediata e a partir de seu ponto incial no tempo + offset
stopDocument (baseId,
documentId)
0x08 Cessa a apresentao de um documento NCL em uma base
privada ativa. Todos os eventos do documento que esto em
andamento devem ser parados
pauseDocument (baseId,
documentId)
0x09 Pausa a apresentao de um documento NCL em uma base
privada ativa. Todos os eventos do documento que esto em
andamento devem ser pausados
resumeDocument (baseId,
documentId)
0x0A Retoma a apresentao de um documento NCL em uma base
privada ativa. Todos os eventos do documento que foram
previamente pausados pelo o comando de edio
pauseDocument devem ser retomados
saveDocument (baseId,
documented, location)
0x2E Salva um documento NCL de uma base privada aberta em um
dispositivo de armazenamento persistente (se disponvel). O
parmetro location deve especificar o dispositivo e o caminho no
dispositivo onde o documento ser salvo. Se o documento NCL
estiver sendo exibido, ele deve primeiro ser parado (todos os
eventos no estado occurring devem ser parados)
346
addRegion (baseId,
documentId, regionBaseId,
regionId, xmlRegion)
0x0B Adiciona um elemento <region> como filho de outro <region>,
no <regionBase>, ou como filho do <regionBase>
(regionId=null) de um documento NCL em uma base privada
aberta
removeRegion (baseId,
documentId, regionId)
0x0C Remove um elemento <region> de um <regionBase> de um
documento NCL em uma base privada aberta
addRegionBase (baseId,
documentId, xmlRegionBase)
0x0D Adiciona um elemento <regionBase> ao elemento <head> de um
documento NCL em uma base privada aberta. Se a especificao
XML do regionBase for enviada em um sistema de transporte
como um sistema de arquivo, o parmetro xmlRegionBase
apenas uma referncia para esse contedo
removeRegionBase (baseId,
documentId, regionBaseId)
0x0E Remove um elemento <regionBase> do elemento <head> de um
addRule (baseId, documentId,
xmlRule)
0x0F Adiciona um elemento <rule> ao <ruleBase> de um documento
NCL em uma base privada aberta
removeRule (baseId,
documentId, ruleId)
0x10 Remove um elemento <rule> do <ruleBase> de um documento
NCL em uma base privada aberta
addRuleBase (baseId,
documentId, xmlRuleBase)
0x11 Adiciona um elemento <ruleBase> ao elemento <head> de um
documento NCL em uma base privada aberta. Se a especificao
XML do ruleBase for enviada em um sistema de transporte como
um sistema de arquivo, o parmetro xmlRuleBase apenas uma
referncia para esse contedo
removeRuleBase (baseId,
documentId, ruleBaseId)
0x12
Remove um elemento <ruleBase> do elemento <head> de um
addConnector (baseId,
documentId, xmlConnector)
0x13
Adiciona um elemento <connector> ao <connectorBase> de um
removeConnector (baseId,
documentId, connectorId)
0x14
Remove um elemento <connector> do <connectorBase> de um
addConnectorBase (baseId,
documentId,
xmlConnectorBase)
0x15
Adiciona um elemento <connectorBase> ao elemento <head> de
um documento NCL em uma base privada aberta. Se a
especificao XML do connectorBase for enviada em um sistema
de transporte como um sistema de arquivo, o parmetro
xmlConnectorBase apenas uma referncia para esse contedo
removeConnectorBase (baseId,
documentId, connectorBaseId)
0x16
Remove um elemento <connectorBase> do elemento <head> de
um documento NCL em uma base privada aberta
addDescriptor (baseId,
documentId, xmlDescriptor)
0x17
Adiciona um elemento <descriptor> ao <descriptorBase> de um
removeDescriptor (baseId,
documentId, descriptorId)
0x18
Remove um elemento <descriptor> do <descriptorBase> de um
addDescriptorSwitch (baseId,
documentId,
xmlDescriptorSwitch)
0x19
Adiciona um elemento <descriptorSwitch> ao <descriptorBase>
de um documento NCL em uma base privada aberta. Se a
especificao XML do descriptorSwitch for enviada em um
sistema de transporte como um sistema de arquivo, o parmetro
xmlDescriptorSwitch apenas uma referncia para esse
contedo
removeDescriptorSwitch
(baseId, documentId,
descriptorSwitchId)
0x1A
Remove um elemento <descriptorSwitch> do <descriptorBase>
de um documento NCL em uma base privada aberta
addDescriptorBase (baseId,
documentId,
xmlDescriptorBase)
0x1B
Adiciona um elemento <descriptorBase> ao elemento <head> de
especificao XML do descriptorBase for enviada em um
sistema de transporte como um sistema de arquivo, o parmetro
xmlDescriptorBase apenas uma referncia para esse contedo
removeDescriptorBase (baseId,
documentId, descriptorBaseId)
0x1C
Remove um elemento <descriptorBase> do elemento <head> de
addTransition (baseId,
documentId, xmlTransition)
0x1D
Adiciona um elemento <transition> ao <transitionBase> de um
347
removeTransition (baseId,
documentId, transitionId)
0x1E
Remove um elemento <transition> do <transitionBase> de um
addTransitionBase (baseId,
documentId,
xmlTransitionBase)
0x1F
Adiciona um elemento <transitionBase> ao elemento <head> de
especificao XML do transitionBase for enviada em um sistema
de transporte como um sistema de arquivo, o parmetro
xmlTransitionBase apenas uma referncia para esse contedo
no carrossel
removeTransitionBase (baseId,
documentId, transitionBaseId)
0x20
Remove um elemento <transitionBase> do elemento <head> de
addImportBase (baseId,
documentId, docBaseId,
xmlImportBase)
0x21
Adiciona um elemento <importBase> base (elemento
<regionBase>, <descriptorBase>, <ruleBase>, <transitionBase>
ou <connectorBase>) de um documento NCL em uma base
privada aberta
removeImportBase (baseId,
documentId, docBaseId,
documentURI)
0x22
Remove um elemento <importBase>, cujo atributo
documentURI identificado pelo parmetro documentURI, a
partir da base (elemento <regionBase>, <descriptorBase>,
<ruleBase>, <transitionBase> ou <connectorBase>) de um
addImportedDocumentBase
(baseId, documentId,
xmlImportedDocumentBase)
0x23
Adiciona um elemento <importedDocumentBase> ao elemento
<head> de um documento NCL em uma base privada aberta
removeImportedDocumentBas
e (baseId, documentId,
importedDocumentBaseId)
0x24
Remove um elemento <importedDocumentBase> do elemento
<head> de um documento NCL em uma base privada aberta
addImportNCL (baseId,
documentId, xmlImportNCL)
0x25
Adiciona um elemento <importNCL> ao elemento
<importedDocumentBase> de um documento NCL em uma base
privada aberta
removeImportNCL (baseId,
documentId, documentURI)
0x26
Remove um elemento <importNCL>, cujo atributo
documentURI identificado pelo parmetro documentURI, a
partir do <importedDocumentBase> de um documento NCL em
uma base privada aberta
addNode (baseId, documentId,
compositeId, {uri, id}+)
0x27
Adiciona um n (elemento <media>, <context> ou <switch>) a
um n de composio (elemento <body>, <context> ou
<switch>) de um documento NCL em uma base privada aberta.
A especificao XML do n e seu contedo de mdia podem:
1)Ser enviados pela rede de difuso de dados como um conjunto
de arquivos enviados sem solicitao; nesse caso, o par {uri, id}
usado para relacionar um conjunto de caminhos de arquivos
definidos no documento XML da especificao do n, com suas
respectivas localizaes no sistema de transporte (veja exemplos
no Apndice F)
NOTA Os conjuntos de pares de referncia devem ser
suficientes para que o middleware possa mapear qualquer
referncia a arquivos, presentes na especificao do n, na sua
localizao concreta na memria do dispositivo receptor
2) Recebidos sob demanda pelo canal de interatividade como um
conjunto de arquivos ou j serem residentes no receptor; para
esses arquivos, nenhum par {uri, id} necessita ser enviado,
exceto o par {uri, null} associado especificao XML do n
que dever ser adicionado em compositeId, caso o documento
XML no seja recebido sem solicitao (pushed file)
removeNode(baseId,
documentId, compositeId,
nodeId)
0x28
Remove um n (elemento <media>, <context> ou <switch>) de
um n de composio (elemento <body>, <context> ou
<switch>) de um documento NCL em uma base privada aberta
348
addInterface (baseId,
documentId, nodeId,
xmlInterface)
0x29
Adiciona uma interface (<port>, <area>, <property> ou
<switchPort>) a um n (elemento <media>, <body>, <context>
ou <switch>) de um documento NCL em uma base privada
aberta
removeInterface (baseId,
documentId, nodeId,
interfaceId)
0x2A
Remove uma interface (<port>, <area>, <property> ou
<switchPort>) de um n (elemento <media>, <body>, <context>
ou <switch>) de um documento NCL em uma base privada
aberta. O parmetro interfaceID deve identificar um atributo
name de um elemento <property> ou um atributo id de um
elemento <port>, <area> ou <switchPort>
addLink (baseId, documentId,
compositeId, xmlLink)
0x2B
Adiciona um elemento <link> a um n de composio (elemento
<body>, <context> ou <switch>) de um documento NCL em
removeLink (baseId,
documentId, compositeId,
linkId)
0x2C
Remove um elemento <link> de um n de composio (elemento
<body>, <context> ou <switch>) de um documento NCL em
setPropertyValue(baseId,
documentId, nodeId,
propertyId, value)
0x2D
Atribui o valor a uma propriedade. O parmetro propertyId deve
identificar um atributo name de um elemento <property> ou um
atributo id de elemento <switchPort>. O <property> ou
<switchPort> deve pertencer a um n (elemento <body>,
<context>, <switch> ou <media>) de um documento NCL em
uma base privada aberta identificada pelos parmetros
A Tabela 16.3 apresenta os identificadores utilizados nos comandos de
edio e suas definies.
Tabela 16.3 Identificadores Usados nos Comandos de edio
Identificadores Definio
baseId O identificador de uma base privada. Usualmente, em
ambientes de TV digital, uma base privada associada a um
canal de TV. Assim, um identificador do canal de TV pode ser
usado como valor de baseId
documentId Atributo id de um elemento <ncl> de um documento NCL
nptTrigger Um valor de NPT
nptBaseId Identificador contentId de uma base temporal NPT
regionId Atributo id de um elemento <region> de um documento NCL
ruleId Atributo id de um elemento <rule> de um documento NCL
connectorId Atributo id de um elemento <connector> de um documento
NCL
descriptorId Atributo id de um elemento <descriptor> de um documento
NCL
descriptorSwitchId Atributo id de um elemento <descriptorSwitch> de um
documento NCL
transitionId Atributo id de um elemento <transition> de um documento
NCL
regionBaseId Atributo id de um elemento <regionBase> de um documento
NCL
349
ruleBaseId Atributo id de um elemento <ruleBase> de um documento NCL
connectorBaseId Atributo id de um elemento <connectorBase> de um documento
NCL
descriptorBaseId Atributo id de um elemento <descriptorBase> de um documento
NCL
transitionBaseId Atributo id de um elemento <transitionBase> de um documento
NCL
docBaseId Atributo id de um elemento <regionBase>, <ruleBase>,
<connectorBase>, <descriptorBase> ou <transitionBase> de um
documento NCL
documentURI Atributo documentURI de um elemento <importBase> ou um
elemento <importNCL> de um documento NCL
importedDocumentBaseId Atributo id de um elemento <importedDocumentBase> de um
documento NCL
compositeID Atributo id de um elemento <body>, <context> ou <switch> de
um documento NCL
nodeId Atributo id de um elemento <body>, <context>, <switch> ou
<media> de um documento NCL
interfaceId Atributo id de um elemento <port>, <area>, <property> ou
<switchPort> de um documento NCL
linkId Atributo id de um elemento <link> de um documento NCL
propertyId Atributo id de um elemento <property> ou <switchPort> de um
documento NCL
A Seo 16.3 apresenta alguns exemplos simples de comandos de edio
NCL. Os comandos de edio addDocument e addNode, bem mais
complexos, so exemplificados no Apndice F, onde so apresentadas vrias
opes de transporte para esses comandos.
16.3 Exemplos de Comandos de Edio NCL
Vamos agora aplicar os vrios conceitos apresentados neste captulo em
uma srie de exemplos.
A srie de exemplos composta dos seguintes passos, realizados atravs
de comandos de edio NCL:
1. Abrir uma base privada.
2. Ativar a base privada aberta.
3. Adicionar um documento na base privada aberta.
4. Iniciar a exibio do documento inserido.
350
5. Adicionar uma regio base de regies do documento e em seguida
remov-la.
6. Adicionar uma interface (ncora de contedo) a um objeto do
documento.
7. Adicionar um novo objeto ao documento.
8. Adicionar um elo ligando a nova interface adicionada ao novo
objeto adicionado.
9. Parar a exibio do documento.
10. Salvar o documento.
11. Fechar a base privada.
Note que todo comando a partir do passo 4 se dar com o documento em
exibio, ou seja, todos os comandos de 5 em diante so de edio ao vivo.
Passemos. ento. realizao de cada passo.
16.3.1 Abrir uma Base Privada
Para abrir uma nova base privada, anteriormente inexistente, devemos
enviar o comando:
openBase (baseId=TV GINGA)
A no-especificao do parmetro location indica a abertura de uma nova
base privada.
O descritor de evento ter a sintaxe vista na Tabela 16.4.
Tabela 16.4 Descritor de evento para abrir uma base privada
Campo Valor
eventid Qualquer valor de 16 bits
eventNPT 0
privateDataLength Comprimento do restante do comando
commandTag 0x00
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA
FCS 8 bits de checksum
Note que o comando determina uma abertura imediata da base (evento
do tipo do it now), que ter o identificador TV GINGA.
351
16.3.2 Ativar a Base Privada aberta
Para ativar a nova base privada, devemos enviar o comando:
activateBase (baseId=TV GINGA).
Tabela 16.5 Descritor de evento para ativar uma base privada aberta
Campo Valor
eventNPT 0
commandTag 0x01
sequenceNumber 0x00
finalFlag 0
Note que o comando, tambm nesse caso, determina a ativao imediata
(evento do tipo do it now) da base TV GINGA.
16.3.3 Adicionar um Documento na Base Privada Aberta
Vamos adicionar o documento weatherConditions.ncl base privada TV
GINGA. Suponha que o documento e seus arquivos de contedo esto no
sistema de arquivos mostrado na Figura 16.1.
C:\nclRepository
Sistema de Arquivo Local
weather
images
brazilianMap.png
weatherConditions.ncl
a
b
c

Figura 16.1 Sistema de arquivos do documento a ser adicionado.
352
Suponha tambm que todos os arquivos do documento sero enviados
em um nico carrossel de objetos (veja Apndice F) e que todos os objetos de
mdia do documento tm seu atributo src especificado de forma relativa
localizao da especificao NCL do documento. Nesse caso, basta que o
comando de edio faa referncia ao caminho do diretrio onde est o
documento NCL e onde ele ser transportado no carrossel (no caso, por
exemplo: Service Domain 0x1, module 0x1 e object 0x2), pois todos os
arquivos podero ter seus caminhos absolutos resolvidos a partir desse
relacionamento, como discutido no Apndice F.
O comando de edio a ser enviado dado por:
addDocument (baseId=TV GINGA,
{uri,id}={C:\nclRepository\weather,0x1, 0x1, 0x2})
Tabela 16.6 Descritor de evento para adicionar um documento a uma base privada aberta
Campo Valor
eventNPT 0
commandTag 0x05
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, {C:\ nclRepository\weather,0x1, 0x1, 0x2}
Note que, mais uma vez, o comando determina a adio imediata do
documento na base.
16.3.4 Iniciar a Exibio do Documento
Vamos agora supor que o documento weatherConditions.ncl tenha um
objeto de vdeo (id= noticias) sobre um noticirio em exibio e que tal
objeto tem como fonte o fluxo de vdeo principal de um programa. Vamos
tambm supor que, quando o fluxo de vdeo atingir o valor de NPT= 49,
estar no momento em que o noticirio apresentar a previso do tempo e
que, por isso, desejamos iniciar a exibio do documento
weatherConditions.ncl. Note que esse um caso comum em que a base
353
temporal para o incio do documento proveniente do fluxo do vdeo principal
sintonizado.
2

Para iniciar a apresentao do documento, devemos enviar o comando:
startDocument (baseId=TV GINGA,
documentId=Jornal Ginga, interfaceId=porta,
offset=0, nptTrigger=49,nptBaseId=null),
em que a interface de entrada do documento tem id = porta.
Tabela 16.7 Descritor de evento para iniciar a exibio de um documento
Campo Valor
eventNPT 0
commandTag 0x07
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, porta, 0, 49, null
Note que o comando determina o incio da exibio em NPT = 49.
16.3.5 Adicionar uma Regio Base de Regies e em
Seguida Remov-la
Apenas como exemplo de remoo, vamos adicionar e remover uma
regio da base de regies (id = regBase).
Para adicionar uma nova regio, o seguinte comando deve ser enviado:
addRegion (baseId=TV GINGA, documentId=Jornal
Ginga, regionBaseId=regBase, regionId=null,
xmlRegion=<region id="regiaoX" width="100%"
height="100%" zIndex="1"/>)

2
No caso do Sistema Brasileiro de TV Digital Terrestre, quando em um comando startDocument, o
parmetro nptBaseId for null, o valor do campo eventId do descritor de eventos de fluxo deve estar listado
em um objeto de eventos de fluxo DSM-CC cujo campo id de seu STR_NPT_USE tap (campo use do tap)
identifica a base de tempo NPT (o campo id do tap deve obrigatoriamente conter o contentId da base de
tempo).
354
Tabela 16.8 Descritor de evento para acrescentar uma regio a uma base de regies
Campo Valor
eventNPT 0
commandTag 0x0B
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, regBase, null, <region
id="regiaoX" width="100%" height="100%" zIndex="1"/>
Note que, mais uma vez, o comando determina a adio imediata
(evento do tipo do it now) da regio.
Para remover a nova regio, o seguinte comando deve ser enviado:
removeRegion (baseId=TV GINGA,
documentId=Jornal Ginga, regionId=regiaoX)
O descritor de evento ter a e sintaxe vista na Tabela 16.9.
Tabela 16.9 Descritor de evento para remover uma regio
Campo Valor
eventNPT 0
commandTag 0x0B
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, regiaoX
16.3.6 Adicionar uma Interface a um Objeto do Documento
Para adicionar uma nova ncora de contedo ao objeto de vdeo
(id=noticias), o seguinte comando deve ser enviado:
355
addInterface (baseId=TV GINGA, documentId=Jornal
Ginga, nodeId=noticias, xmlInterface=<area
id="tempoRio" first="72npt" last="75npt"/>)
Note que a ncora comea quando o vdeo chega ao tempo 72 npt e
termina em 75 npt.
Tabela 16.10 Descritor de evento para adicionar uma interface a um objeto de um
documento
Campo Valor
eventNPT 0
commandTag 0x29
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, noticias, <area id="tempoRio"
first="12npt" last="15npt"/>
16.3.7 Adicionar um Novo Objeto ao Documento
Vamos agora adicionar ao documento weatherConditions.ncl um objeto
com uma imagem que, posteriormente, desejaremos exibir quando o vdeo
(notcias) atingir a ncora que introduzimos na seo anterior. O objeto ser
adicionado como filho do elemento <body id= idBody>.
Suponha que o arquivo XML que especifica o objeto deva ser buscado
em ftp://salgueiro.telemidia.puc-rio.br/tmp e que o contedo da imagem deva
ser buscado no mesmo site. Nesse caso, apenas um par {uri, id} deve ser
enviado, com id= null.
O comando de edio a ser enviado dado por:
addNode (baseId=TV GINGA, documentId=Jornal Ginga,
compositeId=idBody,
{uri,id}={ftp://salgueiro.telemidia.puc-rio.br/tmp,
null})
356
Tabela 16.11 Descritor de evento para acrescentar um objeto a um documento
Campo Valor
eventNPT 0
commandTag 0x27
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, idBody,
{ftp://salgueiro.telemidia.puc-rio.br/tmp, null}
Note que, mais uma vez, o comando determina a adio imediata do
elemento de mdia.
16.3.8 Adicionar um Elo Ligando a Nova Interface
Adicionada ao Novo Objeto Adicionado
Suponha que o elo que permitir a exibio da imagem adicionada ao
documento to logo o vdeo (notcias) chegue a 72 npt, tenha sido definido em
um arquivo que est sendo transportado no carrossel de objetos com a
localizao dada por Service Domain=0x1, module=0x1 e object=0x3.
O seguinte comando de adio deve ser ento enviado:
addLink (baseId=TV GINGA, documentId=Jornal Ginga,
compositeId=idBody, xmlLink=(0x1, 0x1, 0x3))
O descritor de evento ter a e sintaxe vista na Tabela 16.12.
Tabela 16.12 Descritor de evento para acrescentar um elo a um documento
Campo Valor
eventNPT 0
commandTag 0x2B
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, idBody, (0x1, 0x1, 0x3)
357
16.3.9 Parar a Exibio do Documento
Para parar a exibio do documento, devemos enviar o comando:
stopDocument (baseId=TV GINGA,
documentId=Jornal Ginga)
Tabela 16.13 Descritor de evento para parar a exbio de um documento
Campo Valor
eventNPT 0
commandTag 0x08
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga
16.3.10 Salvar o Documento
Para salvar o documento, devemos enviar o comando:
3

saveDocument (baseId=TV GINGA, documentId=Jornal
Ginga, location=C:\baseDeDocumentos)
Tabela 16.14 Descritor de evento para savar um documento
Campo Valor
eventNPT 0
commandTag 0x2E
sequenceNumber 0x00
finalFlag 0
privateDataPayload TV GINGA, Jornal Ginga, C:\baseDeDocumentos

3
Cabe ressaltar que no seria necessrio o envio do comando para parar a execuo do documento,
uma vez que a execuo do comando para salvar um documento tem como primeira ao parar sua
apresentao.
358
16.3.11 Fechar a Base Privada Aberta
Finalmente, para fechar a base privada, devemos enviar o comando:
closeBase (baseId=TV GINGA).
Tabela 16.15 Descritor de evento para fechar uma base privada
Campo Valor
eventNPT 0
commandTag 0x04
sequenceNumber 0x00
finalFlag 0
Bibliografia
Soares, L.F.S. e Rodrigues, R.F.; Costa, R.R; Moreno, M. (2006). Nested
Context Model 3.0 Part 9 NCL Live Editing Commands.
Monografias em Cincia da Computao do Departamento de Informtica,
PUC-Rio, N. 35/06. Rio de Janeiro, dezembro de 2006. ISSN 0103-9741.

359
Captulo
17

Objetos Imperativos
em NCL
A NCL aceita no apenas objetos cujo contedo composto por cdigo
declarativo na definio de seus elementos <media>, como vimos no Captulo
14, mas tambm objetos cujo contedo composto por cdigo imperativo.
Neste captulo, discutiremos como objetos com cdigo imperativo
podem ser definidos, como eles podem se relacionar com outros objetos em
um documento NCL e como os exibidores (engines) para esses objetos se
comportam.
1

Objetos e exibidores NCLua (objetos imperativos com cdigo Lua
2
) so
por definio parte dos perfis da linguagem NCL para TV digital, e a eles
dedicaremos os captulos seguintes deste livro. Lua a principal linguagem de
script de NCL, e linguagem-padro do Sistema Nipo-Brasileiro de TV
Digital terrestre, e da Recomendao ITU-T H.761 para servio IPTV, na
especificao-padro do middleware Ginga.

1
Este captulo foi baseado em Soares et al. (2008). O uso do material foi gentilmente cedido pelo
2
Na verdade Lua uma linguagem multiparadigma: imperativa e funcional.
360
17.1 Integrando Objetos Imperativos NCL
Como vimos no Captulo 1,o universo das aplicaes de TVD (TV
Digital) pode ser particionado em um conjunto de aplicaes declarativas e
um conjunto de aplicaes imperativas. A entidade inicial de uma aplicao,
isto , aquela que dispara a aplicao, que define a que conjunto a aplicao
pertence, dependendo de essa entidade ser codificada segundo uma linguagem
declarativa ou imperativa. Note que aplicaes declarativas podem conter
entidades imperativas e vice-versa; o que as caracteriza apenas a entidade
inicial.
Linguagens declarativas enfatizam a descrio declarativa de uma
tarefa, em vez de sua decomposio passo a passo, em uma definio
algortmica do fluxo de execuo de uma mquina, como fazem as descries
imperativas. Por ser de mais alto nvel de abstrao, tarefas descritas de
forma declarativa so mais fceis de ser concebidas e entendidas, sem exigir
um programador especialista, como usualmente necessrio nas tarefas
descritas de forma imperativa. Contudo, uma linguagem declarativa muitas
vezes visa a um determinado domnio de aplicaes e define um modelo
especfico para esse domnio.
Linguagens imperativas de propsito geral so bem expressivas, porm
a um elevado custo. Como mencionado, elas usualmente exigem um
programador especialista, geralmente colocam em risco a portabilidade de
uma aplicao, e o controle da aplicao muito mais sujeito a erros
cometidos pelo programador.
A autoria de aplicaes puramente declarativas usando linguagens de
domnio especfico vantajosa quando ela depende apenas de recursos
previstos no projeto da linguagem. Quando uma aplicao necessita de
funcionalidades no-previstas pela linguagem declarativa, a soluo pode se
tornar complicada ou at mesmo impossvel.
Uma soluo para esse impasse consiste em adicionar algum suporte
imperativo linguagem declarativa de domnio especfico; assim, o autor de
aplicaes poder usar a forma declarativa sempre que possvel e tirar
proveito da forma imperativa quando necessrio. Quando uma tarefa casar
com o modelo da linguagem declarativa, o paradigma declarativo ser, em
geral, a melhor escolha. No entanto, nos casos em que o foco de realizao de
uma tarefa no casar com o foco da linguagem declarativa, o paradigma
imperativo ser, em geral, a melhor escolha. De fato, a soluo pode advir
pela adio, linguagem declarativa de domnio especfico, de suporte
proveniente do uso de linguagens de propsito geral, incluindo, alm das
linguagens imperativas, as linguagens funcionais, linguagens lgicas etc.
361
Em NCL, a realizao de algumas tarefas complicada sem auxlio
imperativo, tal como processamento matemtico, manipulao sobre textos,
animaes complexas e colises para objetos grficos, enfim, de modo geral,
tarefas que necessitem da especificao de algoritmos e estruturas de dados
que no aquelas providas de forma nativa pela linguagem.
Objetos imperativos podem ser includos em documentos NCL
definindo novos tipos de elemento <media>, cujo contedo (localizado atravs
do atributo src) seria composto por cdigos em alguma linguagem
imperativa
3
. Por exemplo, os perfis BDTV e EDTV da NCL para o Sistema
Brasileiro de TV Digital terrestre incluem os tipos application/x-ncl-NCLua,
para objetos de mdia com cdigo Lua (extenso de arquivo .lua), e
application/x-ginga-NCLet, para objetos de mdia com cdigo Java (Xlet)
(extenso de arquivo .class ou .jar), esse ltimo s para dispositivos fixos. A
Recomendao H.761 para servios IPTV inclui apenas o tipo application/x-
ncl-NCLua.
Alguns requisitos devem ser cumpridos na integrao de linguagens
declarativas e imperativas.
No caso de linguagens declarativas e imperativas j especificadas e
implementadas, deve-se mexer o mnimo nas linguagens, para evitar o
surgimento de dependncias mtuas que comprometam a evoluo
independente de cada uma delas.
Linguagens declarativas, como a NCL, so facilmente compreendidas
por autores de contedo audiovisual que no possuem base de programao,
ao contrrio de linguagens imperativas. Sendo assim, na integrao de
linguagens declarativas e imperativas, tambm desejado que haja o mnimo
de intercalao entre seus cdigos de modo a simplificar a diviso de tarefas
entre equipes de profissionais tcnicos e no-tcnicos em linguagens de
programao.
Por fim, em apresentaes multimdia, o documento declarativo deve ser
o componente-mestre no qual todos os relacionamentos entre entidades da
aplicao, sejam elas declarativas ou no, devem ser definidos explicitamente
(por meio de elementos da linguagem declarativa), impedindo que entidades
imperativas sobrepujem essa hierarquia por meio de acessos diretos
estrutura do documento.

3
Devemos mais uma vez enfatizar que NCL, como uma linguagem cola, no restringe nem prescreve
qualquer tipo de objeto de mdia. Assim poderamos tambm ter objetos de mdia com cdigo puramente
funcional, ou em uma linguagem lgica etc. Esses novos objetos poderiam at seguir as mesmas definies
dadas neste captulo. No entanto, vamos, no momento, nos restringir a objetos imperativos, ou seja, cujo
contedo definido por trechos de cdigo especificados em uma linguagem seguindo o paradigma
imperativo, incluindo linguagens, como Lua, que no so puramente imperativas.
362
Todos os requisitos explicitados nos trs pargrafos anteriores guiaram
a integrao de objetos imperativos NCL. Um objeto com cdigo imperativo
deve ser escrito em um arquivo separado do documento NCL, que apenas o
referencia. Os cdigos imperativos usam a mesma abstrao para objetos de
mdia usada para imagens, vdeos e outras mdias (ver Parte II). Em outras
palavras, um documento NCL apenas relaciona objetos de mdia, no
importando qual o tipo de seu contedo. Mais ainda, como para todo objeto
de mdia, a comunicao com o mundo externo ao objeto somente pode ser
feita atravs de elos (elementos <link>, ver Captulo 10) ou da leitura de
variveis do n NCL settings (elemento <media type=application/x-ncl-
settings>, ver Captulo 8), que tambm s podem ser escritas atravs do uso
de elos.
Resumindo, a motivao de mnima intruso destaca trs requisitos, que
foram obedecidos pela NCL na sua integrao com entidades especificadas
em uma linguagem imperativa:
1. Tanto a NCL quanto a linguagem imperativa so alteradas o mnimo
possvel na viabilizao da integrao.
2. Do ponto de vista do desenvolvedor, mantida uma fronteira bem
delineada entre os dois paradigmas de programao.
3. Em termos de projeto, a relao entre as duas mquinas
4
de execuo
(declarativa NCL e imperativa) ortogonal; em outras palavras, operaes no
ambiente de uma mquina no produzem efeitos imprevistos no ambiente da
outra mquina.
17.2 Elemento <media type=application/x-???>
Um objeto de mdia com cdigo imperativo definido em NCL pelo
elemento <media> com o atributo type recebendo o valor application/x-???,
onde ??? depende da linguagem imperativa usada. Por exemplo,
application/x-ncl-NCLua usado no middleware Ginga para objetos com
cdigo Lua. O atributo src deve, nesse caso, referenciar a localizao do
cdigo imperativo que compe o contedo do objeto. A Listagem 17.1 ilustra
um exemplo de especificao de objeto imperativo com cdigo Lua. Note que
o fato de usarmos a extenso .lua nos desobriga da definio do atributo
type.

4
Uma mquina de execuo declarativa (tambm chamada de player, formatador, agente de
usurio etc.) aquela que inicia e gerencia todo o ciclo de vida de uma aplicao declarativa. Analogamente,
uma mquina de execuo imperativa (chamada de engine, mquina virtual etc.) aquela que inicia e
gerencia todo o ciclo de vida de uma aplicao imperativa.
363

Listagem 17.1 Objeto de mdia com cdigo Lua.
Igualmente para qualquer outro objeto de mdia, o elemento <media>
representando um objeto de mdia com cdigo imperativo pode definir ncoras
de contedo (atravs do elemento <area>) e propriedades (atravs do
elemento <property>). Tambm igual para qualquer outro objeto de mdia, o
atributo descriptor, opcional, deve se referir a um elemento <descriptor> que
responsvel pela iniciao de propriedades necessrias apresentao
(execuo) do objeto.
Em uma implementao de um formatador NCL, cabe ao exibidor de
um objeto de mdia a responsabilidade de interpretar a semntica associada a
suas ncoras. Por exemplo, em caso de elementos <media> do tipo imagem,
uma ncora pode definir uma regio em pixels da imagem completa; em caso
de elementos <media> do tipo video, uma ncora pode definir um trecho
temporal do vdeo. No caso de objetos imperativos, cabe ao programador de
cada objeto especificar (programar) o comportamento de suas ncoras. Um
possvel e comum comportamento o de executar um trecho do cdigo (uma
funo, um mtodo etc.) de mesmo nome da ncora, especificado atravs do
atributo label do elemento <area>, como ilustrado na Listagem 17.1 pela
ancora1. comum tambm o uso de ncoras apenas para definio de
mquinas de estados, cuja execuo comandada pelo cdigo imperativo,
como ilustrado na Listagem 17.1 pela ancora2. Essas ltimas ncoras
poderiam ser usadas em papis de condio de elementos <link>, disparando
aes em outros objetos de um documento NCL, como discutiremos na Seo
17.3.1.
Como usual na NCL, um objeto imperativo sempre define uma ncora
representando o contedo total do n. Essa ncora, que anteriormente
conhecemos com o nome ncora de contedo total, declarada por omisso
(default). Essa ncora tem, entretanto, um sentido especial em um objeto de
mdia imperativo. Ela representa a execuo de qualquer trecho de cdigo
do objeto.
Todo objeto imperativo define tambm por omisso (default) uma outra
ncora chamada ncora de contedo principal. Cada vez que um objeto
imperativo iniciado (ao start no objeto) sem especificar uma de suas
ncoras de contedo ou propriedade, a ncora de contedo principal
assumida e, como consequncia, o trecho de cdigo a ela associado
executado. Em todos os outros casos de referncia a um objeto imperativo
<media id=objetoLua src=exemplo.lua>
<property name=propriedade1/>
<property name=propriedade2 value=0/>
<area id=ancora1 label=final/>
<area id=ancora2/>
</media>
364
sem especificar uma de suas ncoras de contedo ou propriedade, a ncora
de contedo total assumida.
Um elemento <property>, filho de um elemento <media>, usado para
parametrizar o comportamento do exibidor do objeto. Como para as ncoras
de contedo, cabe ao exibidor de mdia a responsabilidade de interpretar a
semntica de cada propriedade. Por exemplo, um exibidor de texto deve ser
capaz de interpretar as propriedades fontStyle e fontSize; j um exibidor de
som, as propriedades soundLevel e bassLevel. No caso de objetos
imperativos, cabe ao programador de cada objeto especificar (programar) o
comportamento de suas propriedades. Uma abordagem possvel e comum
mapear cada propriedade em variveis de mesmo nome do cdigo imperativo
a executar, como ilustrado na Listagem 17.1 pela propriedade1 ou, ento, a
trechos de cdigo (funes, mtodos etc.) que tratem de forma especial o
valor atribudo propriedade, como ilustrado na Listagem 17.1 pela
propriedade2.
De forma anloga a qualquer objeto de mdia, toda ncora de contedo
ou propriedade possui uma mquina de estado de evento (veja Figura 17.1)
associada.
paused
sleeping occurring
resume
stop | abort
pause
stop| natural end
abort
start

Figura 17.1 Mquina de estado associada a ncoras de contedo ou propriedade.
17.3 Comportamento Esperado de Exibidores de
Objetos Imperativos em Aplicaes NCL
Um exibidor de objeto imperativo (mquina de execuo da linguagem)
deve obrigatoriamente prover a interface do ambiente de execuo imperativo
com o formatador NCL, como se segue.
17.3.1 Ponte entre os Ambientes Declarativo e Imperativo
Os autores podem definir elos NCL para iniciar, parar, pausar, retomar
ou abortar uma ncora de contedo de um objeto imperativo. Nesses casos,
365
callbacks no cdigo imperativo so disparados. A forma como esses
callbacks so definidos responsabilidade de cada cdigo associado com o
objeto imperativo.
Por outro lado, um cdigo imperativo pode tambm comandar o incio, a
parada, a pausa, a retomada ou o aborto de suas ncoras de contedo, atravs
de alguma API oferecida pela linguagem. Essas transies podem ser
utilizadas como condies de elos NCL para disparar aes em outros objetos
do mesmo documento NCL.
Pelos dois pargrafos anteriores, temos a primeira forma de estabelecer
uma sincronizao de duas vias entre o cdigo imperativo e o restante do
documento NCL.
A outra forma que um cdigo imperativo pode ser sincronizado com
outros objetos de um documento NCL atravs de elementos <property>, j
definidos na seo anterior. Naquela seo, vimos que um elemento
<property> de um objeto de mdia imperativo pode ser mapeado para um
trecho de cdigo (funo, mtodo etc.) ou para um atributo do cdigo.
Quando mapeado para um trecho de cdigo, uma ao de elo start
aplicada propriedade causa a execuo do cdigo com os valores atribudos
interpretados como parmetros de entrada. O atributo name do elemento
<property> deve obrigatoriamente ser utilizado para identificar o trecho de
cdigo imperativo. Quando o elemento <property> mapeado para um
atributo do cdigo imperativo, a ao start deve atribuir um valor ao
atributo.
Um elemento <property> tambm pode estar associado a um assessment
role de um elo NCL. Nesse caso, o formatador NCL consulta o valor da
propriedade para avaliar a expresso do elo. Se o elemento <property> for
mapeado para um atributo de cdigo, seu valor retornado pelo exibidor do
objeto de mdia imperativo ao formatador NCL. Se o elemento <property> for
mapeado para um trecho de cdigo, ele chamado e o valor do resultado de
sua execuo retornado pelo exibidor do objeto de mdia imperativo ao
formatador NCL.
17.3.2 Modelo de Execuo de um Objeto Imperativo
O ciclo de vida de um objeto de mdia imperativo controlado pelo
formatador NCL. O formatador responsvel por disparar a execuo do
objeto e por mediar a comunicao desse objeto com outros objetos do
documento NCL, como vimos na seo anterior.
366
Como todo exibidor de objeto de mdia, uma vez instanciado, o exibidor do
objeto imperativo executa um procedimento de iniciao. Diferentemente do
que acontece para os outros exibidores de mdia, esse procedimento deve ser
especificado (programado) pelo autor do objeto. O procedimento de iniciao
executado apenas uma vez, para cada instncia, e cria todos os trechos de
cdigos e estrutura de dados que podem ser usados durante a execuo do
objeto. Esse procedimento tambm o responsvel por registrar um ou mais
tratadores de evento para a comunicao com o formatador NCL. O leitor
deve ter em mente que pelo menos o cdigo associado ncora de contedo
principal deve ser criado no procedimento de iniciao.
Depois do procedimento de iniciao, a execuo do objeto imperativo se
torna orientada a eventos, nas duas direes. Isto , qualquer ao comandada
pelo formatador NCL entregue aos tratadores de evento registrados, e
qualquer modificao na mquina de estado de eventos, comandadas por
instrues do cdigo imperativo, tambm programadas pelo autor do objeto,
enviada como um evento ao formatador NCL (como caso particular, o final
natural da execuo de um trecho de cdigo).
A Listagem 17.2 ilustra o uso de ncoras de contedo em um objeto
imperativo com cdigo Lua. Uma ao de start (disparada por um elo no
sentido do ambiente imperativo) no objeto Lua aciona o procedimento de
iniciao do objeto (se ele j no foi acionado e o exibidor j no est
instanciado). Na Listagem 17.2, os trechos de cdigo que podem ser usados
na execuo do objeto so ento criados (no caso, apenas o cdigo associado
ncora de contedo principal) e o tratador de eventos registrado. O evento
de start da execuo (apresentao) ento passado ao tratador de eventos,
que aciona a execuo do cdigo associado ncora de contedo principal,
mostrado na figura.
Ainda na Listagem 17.2, a execuo do cdigo, em certo ponto, coloca a
mquina de estado da ncora de atributo label=final no estado ocorrendo,
devendo essa mudana de estado ser notificada pelo exibidor do objeto de
mdia imperativo ao formatador NCL (event.post (out, evt), na
figura). Essa transio de estado pode, por exemplo, ser a condio de
disparo de um elo. Esse exemplo simples ilustra como cabe ao programador
controlar a execuo das mquinas de estado associadas s suas ncoras de
contedo (e s suas propriedades, embora estas no sejam mostradas no
exemplo). Ao final, podemos observar mais uma vez como o programa
controla a sinalizao ao formatador NCL, agora para notificar o fim da
execuo do objeto imperativo (event.post ({class=ncl,
type=presentation, action=stop}).
367

Listagem 17.2 Objeto de mdia com cdigo Lua.
Diferentemente dos procedimentos realizados para outros tipos de
elementos <media>, se um exibidor de objeto de mdia com cdigo imperativo
receber uma instruo start para um evento associado a um elemento <area>
e esse evento estiver no estado sleeping, ele inicia a execuo do cdigo
imperativo associado ao elemento, mesmo se outra parte do cdigo imperativo
do objeto de mdia estiver em execuo (pausado ou no). Contudo, se o
evento associado ao elemento-alvo <area> estiver no estado occurring ou
paused, a instruo start ignorada pelo exibidor imperativo, que continuar
controlando a execuo anteriormente iniciada. Como consequncia, o leitor
deve estar atento ao fato de que, diferentemente do que ocorre para os outros
elementos <media>, uma ao de stop, pause, resume ou abort de
um elo deve ser ligada a uma interface do n imperativo, que no ignorada
quando a ao aplicada, ao contrrio dos outros tipos de objeto de mdia de
um documento NCL.
A instruo start emitida pelo formatador para um evento associado a
um elemento <property> aplicada a um objeto de mdia imperativo
independentemente do fato de ele estar em execuo ou no (neste ltimo
caso, seu exibidor deve j ter sido instanciado para que a ao se realize). No
primeiro caso, a instruo start precisa identificar o objeto de mdia
imperativo, um evento de atribuio monitorado e um valor a ser passado ao
cdigo imperativo associado ao evento. No segundo caso, pode tambm
identificar o elemento <descriptor> que ser usado quando da execuo do
objeto (anlogo ao que feito para a instruo start em um evento de
apresentao).
Uma vez terminada a execuo do objeto imperativo, sua instncia no
precisa ser eliminada. O leitor deve lembrar do Captulo 7 que o atributo
function handler (evt)
if (evt.class==ncl) and
(evt.type==presentation) and
(evt.action==start) then
...
evt.area=final
event.post (out, evt)
...
event.post (out, {
class=ncl, type=presentation, action=stop
})
end
end
Event.register (handler)
368
playerLife pode permitir o reso de uma instncia de exibidor para a
apresentaes futuras.
Neste ponto, uma releitura do exemplo O Primeiro Joo, da Seo 3.12
do Captulo 3, pode ser til para firmar os conceitos discutidos neste captulo.
O Apndice H traz uma discusso das vrias aes sobre eventos de
apresentao e atribuio definidos por um objeto de mdia, incluindo os
objetos de mdia imperativos.
Bibliografia
Soares, L.F.S.; SantAnna, F.F; Cerqueira, R. (2008). Nested Context
Language 3.0 Part 10 Imperative Objects in NCL: The NCLua
Scripting Language. Monografias em Cincia da Computao do
Departamento de Informtica, PUC-Rio, N. 02/08. Rio de Janeiro, janeiro
de 2008. ISSN 0103-9741.
Soares, L.F.S.; Moreno, M.F.; SantAnna (2009). Relating Declarative
and Imperative Objects through the NCL Glue Language.
Proceedings of the ACM Symposium on Document Engineering.
Munique, setembro de 2009.

369
Captulo
18

Programando com
Objetos NCLua

No captulo anterior, vimos como objetos com cdigo imperativo podem ser
definidos, como eles podem se relacionar com outros objetos em um
documento NCL e como exibidores (engines) para esses objetos se
comportam. Neste captulo, nos dedicamos aos objetos NCL com cdigo Lua,
os chamados scripts NCLua.
1

Ao final deste captulo, voc ser capaz de construir objetos com cdigo
imperativo em NCLua e utiliz-los em sua aplicao NCL.

1
Este captulo foi baseado em [SantAnna et al. 2009]. O uso do material foi gentilmente cedido pelo
Departamento de Informtica da PUC-Rio e por seus autores.

370
18.1 A Linguagem Lua
Desde o incio de seu desenvolvimento, no incio dos anos 1990, Lua foi
projetada para ser usada em conjunto com outras linguagens, no sendo
comum encontrar programas escritos puramente em Lua. Nesse sentido, Lua
normalmente usada para permitir que uma aplicao principal seja estendida
ou adaptada atravs do uso de scripts. A aplicao principal pode ser um
videogame, em que um script Lua usado para definir o comportamento de
um personagem; um editor de textos, que permite que os textos sejam
acessados e modificados por scripts Lua; ou, de maneira mais geral,
aplicaes que usam Lua em scripts de configurao. Esse tipo de uso
caracteriza Lua como uma linguagem de scripts no seu sentido mais puro. O
prprio nome da linguagem, Lua, remete ideia de uma linguagem satlite.
Lua uma linguagem de fcil aprendizado, que combina sintaxe procedural
com declarativa, com poucos comandos primitivos. Dessa caracterstica
resulta uma implementao leve e muito eficiente quando comparada com
linguagens de propsitos similares. Lua tambm apresenta alto grau de
portabilidade, podendo ser executada com todas as suas funcionalidades em
diversas plataformas, tais como computadores pessoais, celulares, sistemas
embarcados e consoles de videogames.
As caractersticas de Lua mencionadas simplicidade, eficincia e
portabilidade alm de sua licena livre, casam perfeitamente com o cenrio
de TV digital. Uma linguagem simples bem-vinda onde comum equipes
formadas no s por programadores, mas tambm por designers e produtores
de contedo. A portabilidade importante quando o middleware deve ser
desenvolvido para dispositivos com caractersticas conflitantes, como
celulares e set-top boxes. A eficincia e o tamanho da linguagem requerem
menos custos com hardware. J a licena livre de royalties reduz a custo zero
a adoo do interpretador por unidade produzida. Um indicador de como a
linguagem Lua se adapta bem a esse tipo de cenrio a liderana de Lua
como linguagem de script em videogames, nicho que compartilha as mesmas
caractersticas descritas.
Uma apresentao mais detalhada da sintaxe e funcionalidades de Lua fica
fora do escopo deste livro. Explicaremos os conceitos da linguagem
necessrios, conforme forem utilizados nos exemplos deste captulo.
18.1.1 Extenses de NCLua
Para se adequar ao ambiente de TV Digital e se integrar NCL, a
linguagem Lua foi estendida com novas funcionalidades. Por exemplo, um
NCLua precisa se comunicar com o documento NCL para saber quando o seu
371
objeto <media> correspondente iniciado por um elo. Um NCLua tambm
pode responder a teclas do controle remoto ou desenhar livremente dentro da
regio NCL a ele destinada. Essas funcionalidades so especficas da
linguagem NCL e, obviamente, no fazem parte da biblioteca-padro de Lua.
O que diferencia um NCLua de um programa Lua puro o fato de ser
controlado pelo documento NCL no qual est inserido e utilizar as extenses
descritas a seguir.
Alm da biblioteca-padro de Lua, os seguintes mdulos esto disponveis
para scripts NCLua:
mdulo event: permite que objetos NCLua se comuniquem com o
documento NCL e outras entidades externas (tais como controle remoto
e canal de interatividade);
mdulo canvas: oferece funcionalidades para desenhar objetos grficos
na regio do NCLua;
mdulo settings: oferece acesso s variveis definidas no objeto
settings do documento NCL (objeto do tipo application/x-ncl-settings);
mdulo persistent: exporta uma tabela com variveis persistentes
entre execues de objetos imperativos.
O Captulo 10 da ABNT, NBR 15606-2 [2011] lista detalhadamente todas
as funes suportadas por cada mdulo mencionado.
As seguintes funes da biblioteca-padro de Lua so dependentes de
plataforma e por isso no esto disponveis para scripts NCLua:
no mdulo package: a funo loadlib;
no mdulo io
2
: todas as funes;
no mdulo os: as funes clock, execute, exit, getenv, remove,
rename, tmpname e setlocale;
no mdulo debug: todas as funes.
18.2 Programao Orientada a Eventos
No Captulo 17 discutimos o modelo de execuo e comunicao de objetos
imperativos embutidos em documentos NCL. No caso de objetos NCLua, os

2
O modulo io assncrono est disponvel apenas para aplicaes residentes.
372
mecanismos de integrao com o documento NCL se fazem atravs do
paradigma de programao orientada a eventos.
No somente a comunicao com o documento NCL, mas tambm
qualquer interao com entidades externas aplicao, como o canal de
interatividade, controle remoto e temporizadores, se faz pela difuso e
recepo de eventos. O mdulo event de NCLua, usado para esse fim, a
mais importante extenso linguagem Lua, e seu entendimento essencial
para desenvolver qualquer aplicao que utilize objetos NCLua.
A Figura 18.1 exibe ao centro um NCLua, envolto por diversas entidades
com as quais ele pode interagir. Para se comunicar com um NCLua, uma
entidade externa deve inserir um evento na fila indicada na figura, que ento
redirecionado s funes tratadoras de eventos, definidas pelo programador
do script NCLua. Enquanto cada tratador, um de cada vez, processa um
evento, nenhum outro evento da fila tratado. Sendo assim, fica a cargo do
programador escrever tratadores que executem o mais rpido possvel, de
maneira a evitar o congestionamento da fila. Um NCLua tambm pode se
comunicar com entidades externas postando eventos dentro de seus tratadores,
como mostram as setas saindo do NCLua.
3

Controle Remoto
Canal de
Interatividade
eventos ncl e edit
NCLua
fila de eventos
tratador 1
tratador N
eventos key
eventos tcp e sms
eventos si
Formatador NCL Emissora
eventos ncl
eventos tcp e sms
eventos user

Figura 18.1 Paradigma de programao orientado a eventos.

3
A fila de eventos controlada pelo sistema e no visvel a um NCLua.
373
A principal vantagem do uso do paradigma de eventos a sua
caracterstica de acoplamento fraco entre as entidades do sistema. Como se

pode observar pela figura, a remoo ou adio de uma entidade no acarreta
mudanas internas em nenhuma outra entidade. Essa caracterstica vai ao
encontro dos requisitos de mnima intruso levantados no Captulo 17.
Para ser informado quando eventos externos so recebidos, um NCLua
deve registrar pelo menos uma funo de tratamento em seu corpo atravs de
uma chamada funo event.register (o nome da funo a ser registrada
pode ser qualquer um). O cdigo de um NCLua segue uma estrutura comum
a todos os scripts, como na Listagem 18.1.
... -- cdigo de iniciao
function tratador (evt)
... -- cdigo de um tratador
end
event.register(tratador) -- registro de pelo menos um tratador
Listagem 18.1 Paradigma de programao orientado a eventos
O cdigo de iniciao, a definio do tratador e seu registro so executados
antes que qualquer evento gerado pelo documento NCL (ou qualquer entidade
externa ao script) seja sinalizado aos tratadores NCLua, inclusive o de incio
de apresentao do objeto. Aps esse processo de carga do script, efetuado
pelo sistema, apenas o cdigo do tratador chamado, toda vez que ocorre um
evento externo. O cdigo de iniciao pode ser utilizado para criar objetos e
funes auxiliares que sero usadas pelos tratadores.
Eventos so representados por tabelas Lua com chaves e valores
descrevendo seus atributos. Como exemplo, a funo tratadora pode receber
um evento (parmetro evt do tratador, na Listagem 18.1), indicando que a
tecla vermelha do controle remoto foi pressionada pelo telespectador.
evt = {
class = 'key',
type = 'press',
key = 'RED',
}
Listagem 18.2 Representao de evento em NCLua.
A funo event.post utilizada para que um NCLua poste eventos e
possa, por exemplo, enviar dados pelo canal de interatividade ou sinalizar seu
estado ao documento NCL. No exemplo a seguir (Listagem 18.3), o NCLua
sinaliza ao documento o seu fim natural.
374

event.post {
class = 'ncl',
type = 'presentation',
action = 'stop',
}
Listagem 18.3 Exemplo de evento postado por um NCLua para sinalizar ao documento NCL
o seu fim natural.
Como um NCLua (por meio de seus tratadores) deve executar rapidamente,
a funo de envio de eventos nunca aguarda o retorno de um valor. Caso o
destino necessite retornar uma informao ao NCLua, o far atravs do envio
de um novo evento.
18.2.1 Classes de Eventos
O campo class de uma tabela representando um evento obrigatrio e tem
a finalidade de separar os eventos em categorias. A classe identifica no
somente a origem de eventos passados aos tratadores, mas tambm o seu
destino, caso o evento seja gerado e postado por um script NCLua.
As seguintes classes de eventos esto definidas:
Classe ncl: usada na comunicao entre um NCLua e o documento
NCL que contm o objeto de mdia.
Classe key: representa o pressionamento de teclas do controle remoto
pelo usurio.
Classe tcp: permite acesso ao canal de interatividade por meio do
protocolo tcp.
Classe sms: usada para envio e recebimento de mensagens SMS.
Classe edit: permite que os comandos de edio ao vivo apresentados
no Captulo 16 sejam disparados a partir de scripts NCLua.
Classe si: prov acesso a um conjunto de informaes multiplexadas em
um fluxo de transporte e transmitidas periodicamente por difuso.
Classe user: atravs dessa classe, as aplicaes podem estender sua
funcionalidade criando seus prprios eventos.
375

Observe, pela Figura 18.1, que h eventos apenas de entrada, apenas de
sada ou que so usados em ambos os sentidos.
O modelo orientado a eventos de NCLua foi projetado para suportar outras
entidades externas estendendo o modelo bsico, bastando para isso definir
novas classes de eventos.
18.3 Interagindo com o Documento NCL
Assim como qualquer objeto de mdia, um NCLua interage com o
documento NCL atravs de elos.
Em elos que acionam um NCLua, a condio satisfeita faz com que o
NCLua receba um evento da classe ncl descrevendo a ao a ser tomada. No
trecho da Listagem 18.4, quando o elo for disparado com o incio de
videoId, o tratador de eventos de NCLua receber o evento no cdigo do
objeto NCLua.
<link xconnector="onBeginStart">
<bind role="onBegin" component="videoId"/>
<bind role="start" component="luaId"/>
</link>
arquivo NCL que contm o objeto NCLua
arquivo NCLua
-- Evento recebido pelo tratador do NCLua no
-- disparo do elo:
evt = {
class = 'ncl',
action = 'start',
}
Listagem 18.4 Exemplo de cdigos NCL e NCLua que tratam um evento de apresentao de
um objeto NCL.
J em elos cuja condio depende de um NCLua, a ao do elo ser
disparada quando o NCLua sinalizar o evento que casa com a condio
esperada. No trecho da Listagem 18.5, quando o NCLua sinalizar o evento
indicado, o elo ser disparado e a imagem exibida.
376
<bind role="onEnd" component="luaId"/>
<bind role="start" component="imagemId"/>
</link>
arquivo NCL que contm o objeto NCLua
arquivo NCLua
-- O elo acima ser disparado quando o evento a seguir
-- for postado pelo NCLua 'luaId':
event.post {
class = 'ncl',
action = 'stop',
}
Listagem 18.5 Elo disparado pelo cdigo do objeto NCLua.
O tipo presentation indica que os eventos se referem apresentao do
NCLua. Como nenhuma ncora foi especificada, assumida a ncora de
contedo total, conforme descrito no Captulo 17.
Como os dois exemplos indicam, a interao de um NCLua com o
documento NCL se d sempre atravs da classe de eventos ncl, seja para
receber instrues do formatador, seja para notificar o estado de suas
ncoras.
Exemplo 18.11 Ciclo de Vida de Objetos NCLua
Este exemplo apresenta uma aplicao com o fim de ilustrar o modelo de
execuo de objetos imperativos NCLua em documentos NCL.
Ao iniciar a aplicao, trs objetos NCLua so iniciados, cada um com um
comportamento interno diferente:
O primeiro NCLua executa indefinidamente.
O segundo NCLua termina a si prprio no mesmo momento em que
iniciado.
O terceiro NCLua termina a si prprio trs segundos aps ser iniciado.
Associados a cada NCLua h um boto verde e um vermelho, indicando se
o NCLua est ocorrendo ou terminado, respectivamente. As vises temporal e

377

espacial da aplicao, mostradas na Figura 18.2 tem o comportamento
descrito.
lua1
verde3
lua3
vermelho2
lua2
vermelho3
viso temporal
viso espacial
verde1
3 segundos
vermelho2 verde1 verde3 vermelho2 verde1 vermelho3

A Figura 18.3 exibe a viso estrutural do documento NCL. O primeiro
NCLua ligado aos outros por meio de um elo onBeginStart. Como o
primeiro NCLua est ligado porta de entrada do documento, os trs objetos
iniciam juntamente com a aplicao. Cada NCLua se liga por meio de um elo
onBeginStart com seu respectivo boto verde, para que eles sejam exibidos
com o incio de cada NCLua. Para esconder seu respectivo boto verde e
exibir o vermelho, cada NCLua tambm utiliza um elo onEndStopStart
com seus botes, conforme mostra a figura.
378
lua1
vermelho1 verde1
onEnd
start
stop
onBegin
start
start
pInicio
onBegin
start
lua3
vermelho3 verde3
onEnd
start
stop
start
lua2
vermelho2 verde2
onEnd
start stop
onBegin
start
onBegin

Figura 18.3 Viso estrutural do Exemplo 18..
O documento NCL responsvel por definir e iniciar os trs objetos
NCLua, assim como pela cola lgica entre cada NCLua e seus botes
correspondentes, conforme definido na Listagem 18.6.
<body>

<port id="pInicio" component="lua1"/>


<media id="lua1" src="1.lua"/>
<media id="verde1" src="verde1.png" descriptor="ds1"/>
<media id="vermelho1" src="verm1.png" descriptor="ds1"/>


<bind role="onBegin" component="lua1"/>
379
<bind role="start" component="lua2"/>
<bind role="start" component="lua3"/>
</link>


<bind role="onBegin" component="lua1"/>
<bind role="start" component="verde1"/>
</link>
... 


<link xconnector="onEndStopStart">
<bind role="onEnd" component="lua1"/>
<bind role="stop" component="verde1"/>
<bind role="start" component="vermelho1"/>
</link>
... 
</body>
Listagem 18.6 Cdigo NCL do Exemplo 18.1.
Note como neste exemplo o NCL no aciona o trmino de nenhum objeto
NCLua. Esse papel ficou a cargo de cada script NCLua, como mostrado a
seguir.
O primeiro NCLua um script vazio (sem nenhuma linha de cdigo).
Em particular, como no possui um tratador de eventos, nunca sinaliza o
seu trmino para o documento NCL. O efeito visual a exibio
permanente do primeiro boto verde.
-- 1.lua
-- vazio
Listagem 18.7 Cdigo do arquivo 1.lua do Exemplo 18.1.
O segundo NCLua registra um tratador de eventos que gera seu fim
natural ao receber um start do documento NCL. Visualmente, assim
que o segundo boto verde exibido, exibido instantaneamente o boto
vermelho correspondente (o boto verde pode nem ser visto).

380
-- 2.lua:
if (evt.class == 'ncl') and (evt.type ==
'presentation')
and (evt.action == 'start') then
event.post {
class = 'ncl',
action = 'stop'
}
end
end
event.register(tratador)
To logo o evento indicando seu incio recebido, o NCLua posta um
evento para sinalizar o seu fim natural.
O terceiro NCLua registra um tratador de eventos que cria um
temporizador de trs segundos que, por sua vez, gera seu fim natural ao
expirar. Como efeito visual, temos a exibio do terceiro boto verde e,
aps trs segundos, a mudana para vermelho.
-- 3.lua:
if (evt.class == 'ncl') and
(evt.type == 'presentation') and
(evt.action == 'start') then
event.timer(3000,
function()
event.post {
class = 'ncl',
action = 'stop'
}
end)
end
end
O temporizador de trs segundos (3.000 milissegundos) criado assim que
o evento de incio recebido, passando a funo que deve ser executada
quando o temporizador expira. Essa funo posta um evento idntico ao do
segundo NCLua para sinalizar seu fim natural.
381
Enquanto executa indefinidamente, o primeiro NCLua no consome
recursos e pode responder a eventos (apesar de no o fazer por no possuir
um tratador para tal fim). O mesmo ocorre com o terceiro NCLua enquanto
aguarda os trs segundos para terminar.
18.3.1 Eventos em ncoras de Contedo e Propriedades
No exemplo anterior, apenas a ncora de contedo principal de cada
NCLua foi acionada. No entanto, ncoras de contedo especficas e
propriedades tambm podem ser relacionadas entre o documento NCL e o
objeto NCLua.
Dados os tipos de eventos gerados pelo formatador NCL, o campo type de
um evento da classe ncl pode assumir os valores presentation ou
attribution, conforme o atributo eventType dos conectores NCL (ver Seo
10.5). Eventos do tipo selection so tratados pela classe key.
18.3.1.1 Eventos do Tipo presentation
Eventos de apresentao esto associados apresentao de ncoras de
contedo, sendo identificadas pelo campo label do evento. O campo action
indica a ao a ser realizada ou sinalizada pelo NCLua, dependendo de ele
estar recebendo ou gerando o evento.
Um evento de apresentao possui a seguinte estrutura:
class: 'ncl'
type: 'presentation'
label: [string] rtulo da ncora associada ao evento
action: [string] pode assumir os seguintes valores: 'start',
'stop', 'abort', 'pause' e 'resume'
18.3.1.2 Eventos do Tipo attribution
Eventos de atribuio esto associados s propriedades do objeto NCLua,
sendo identificados pelo campo name.
O campo value preenchido com o valor a ser atribudo propriedade e
sempre uma string, uma vez que vem de um atributo NCL. A ao de start
em um evento de atribuio corresponde ao papel set (ou start) de um elo
NCL.
Um evento de atribuio possui a seguinte estrutura:
382
class: 'ncl'
type: 'attribution'
name: [string] nome da propriedade associada ao evento
action: [string] pode assumir os seguintes valores: 'start',
'stop', 'abort', 'pause' e 'resume'
value: [string] novo valor a ser atribudo propriedade
O campo action de um evento ncl (seja ele de apresentao ou atribuio)
pode assumir os valores correspondentes aos seus tipos, como mostrado nas
Tabelas 10.6 e 10.7. No entanto, o nome das transies na Tabela 10.6
usado sem o s final (starts vira start), de maneira a unificar a sintaxe
para eventos recebidos ou sinalizados pelo NCLua.
Exemplo 18.2 Contador de Cliques
Vamos supor uma aplicao NCL que exiba um boto Clique aqui em
quatro momentos diferentes. Se o usurio selecion-lo com o controle remoto
por pelo menos trs vezes, ao final da apresentao ser exibido o boto Voc
ganhou, caso contrrio ser exibido o boto Voc Perdeu. A Figura 18.4
mostra as vises temporal e espacial da aplicao.
temp
viso temporal
viso espacial
aqui
ganhou
OU
perdeu
area01 area02 area03 area04
aqui aqui aqui aqui
resultado
ganhou
perdeu
cliques

No possvel fazer a contagem de cliques puramente em NCL de forma
simples, uma vez que no h suporte a expresses aritmticas na linguagem.
Neste exemplo, usaremos um NCLua para contar e armazenar o nmero de
383
cliques em uma propriedade, que ser consultada ao final para determinar o
resultado.
O documento NCL mostrado a seguir define um temporizador (temp)
com quatro ncoras temporais (area01 at area04) durante as quais o
boto Clique aqui exibido. O temporizador tambm define uma ncora
temporal para exibir o resultado aps o boto ser exibido por quatro vezes.
Alm do temporizador e os botes, o documento define um NCLua
responsvel pela contagem dos cliques e exporta a propriedade contador
para manter esse valor. A Figura 18.5 mostra a viso estrutural da aplicao.
temp
pInicio
area02
area03
cliques
aqui
ganhou
perdeu
onEnd
stop
stop
stop
stop
resultado
and
onBegin
inc
test
contador >= 3
start
and
onBegin
start
test
contador < 3
( ... )
stop
onBegin
start
onBegin onEnd
start stop
onBegin
start
stop
onEnd
area04
contador
start
onSelection
area01

A porta de entrada da aplicao o temporizador, que tambm dispara o
NCLua por meio de um elo onBeginStart. Cada ncora de exibio do
boto Clique aqui possui um elo onBeginStart e onEndStop para o
384
mesmo. Toda vez que o boto selecionado pelo usurio (o que s pode
acontecer enquanto est sendo exibido), a ncora inc do NCLua iniciada e
o boto escondido, conforme o elo onSelectionStopStart saindo do
prprio boto. O tratamento dado ncora inc e propriedade contador
especificado no cdigo do NCLua. Ao final da ncora resultado do
temporizador, dois elos testam se o valor da propriedade contador maior
ou menor que trs cliques. Dependendo do resultado, a imagem Voc ganhou
ou Voc perdeu exibida.
O documento NCL para a aplicao exibido na Listagem 18.1.
<body>

<port id="pInicio" component="temp"/>


<media id="temp">

<area id="area01" begin="3s" end="6s"/>

<area id="resultado" begin="35s"/>
</media>


<media id="cliques" src="cliques.lua">
<area id=incrementa label="inc"/>
<property name="contador"/>
</media>


<media id="aqui" descriptor="dsBotao" src="aqui.jpg"/>
<media id="ganhou" descriptor="dsBotao" src="ganhou.jpg"/>
<media id="perdeu" descriptor="dsBotao" src="perdeu.jpg"/>


<bind role="onBegin" component="temp"/>
<bind role="start" component="cliques"/>
</link>


<bind role="onBegin" component="temp"
385
interface="area01"/>
<bind role="start" component="aqui"/>
</link>
... 

<bind role="onEnd" component="temp" interface="area01"/>
<bind role="stop" component="aqui"/>
</link>
... 


<link xconnector="onSelectionStopStart">
<bind role="onSelection" component="aqui"/>
<bind role="stop" component="aqui"/>
<bind role="start" component="cliques"
interface="incrementa"/>
</link>


<link xconnector="onCondGteBeginStart">
<linkParam name="var" value="3"/>
<bind role="onBegin component="temp"
interface="resultado"/>
<bind role="attNodeTest" component="cliques"
interface="contador"/>
<bind role="start" component="ganhou"/>
</link>
<link xconnector="onCondLtBeginStart">
<linkParam name="var" value="3"/>
<bind role="onBegin" component="temp"
interface="resultado"/>
<bind role="attNodeTest" component="cliques"
interface="contador"/>
<bind role="start" component="perdeu"/>
</link>
</body>
Listagem 18.10 Cdigo NCL parcial do Exemplo 18.2.
O cdigo do NCLua deve lidar em sua funo tratadora de eventos com as
duas interfaces com o documento NCL a ncora inc e a propriedade
contador. A Listagem 18.11 apresenta o cdigo do script.

386
local contador = 0
contador = contador + 1
local evtContador = {
class = 'ncl',
type = 'attribution',
name = 'contador',
value = contador,
}
evtContador.action = 'start'
event.post(evtContador)
evtContador.action = 'stop'
event.post(evtContador)
event.post {
class = 'ncl',
label = 'inc',
action = 'stop',
}
end
event.register(tratador,'ncl','presentation','inc','start')
Listagem 18.11 Cdigo NCLua do Exemplo 18.2.
O script comea declarando uma varivel para guardar a contagem de
cliques. A varivel no possui relao direta com a propriedade do NCLua,
de mesmo nome, definida no documento NCL. O manuseio da propriedade
feito atravs da postagem de eventos, conforme apresentado a seguir.
A funo tratador ento definida e registrada (na ltima linha do
cdigo). Os parmetros extras na chamada funo register servem para
filtrar apenas os eventos desejados; no caso, eventos ncl de incio de
apresentao da ncora inc. Quando o boto selecionado, iniciando a
ncora inc, a funo tratador executada. A funo incrementa o contador
interno e posta um evento de incio de atribuio (action='start'), para indicar
a mudana na propriedade contador.
IMPORTANTE: Note que necessrio sinalizar tambm o fim da
atribuio, fazendo com que a mquina de estados da propriedade contador
volte ao estado sleeping e futuras atribuies surtam efeito. Pelo mesmo
motivo, necessrio sinalizar o trmino da ncora inc, postando o evento
de stop da apresentao, no fim da funo.
O NCLua no tem como saber o momento exato em que a propriedade
contador ser consultada pelo documento NCL por isso, sempre que
incrementa o valor, tambm atualiza a propriedade.
387
Neste ponto, uma releitura do exemplo O Primeiro Joo, da Seo 3.12,
pode ser til para firmar os conceitos discutidos at aqui neste captulo.
18.4 Desenhando na Regio do Objeto
Quando um NCLua carregado, o formatador NCL cria um objeto grfico
para representar a regio associada mdia NCLua no documento. Esse
objeto grfico pr-carregado na varivel global canvas do script, e
atravs dela que todas as operaes grficas so efetuadas. Caso o objeto de
mdia NCLua no esteja associado a nenhuma regio, o valor do canvas
ser igual a nil.
Como exemplo (Listagem 18.12), caso a regio a seguir esteja associada ao
objeto NCLua, a varivel canvas do script ir represent-la, com tamanho
300100 e posicionada em (20,200).
<region id="luaRegion" width="300" height="100"
top="200" left="20"/>
Listagem 18.12 Cdigo NCL de uma regio a ser associada com um objeto NCLua
Existem diversas operaes grficas suportadas pelo mdulo de canvas,
tais como desenho de linhas, textos e imagens. A lista completa de operaes
pode ser consultada no Captulo 10 da NBR 15606-2 [ABNT, 2011]. O
exemplo a seguir cria um novo canvas representando a imagem passada,
desenhando-a centralizada na regio e acompanhada de uma legenda. A
Figura 18.6 exibe o resultado visual da execuo do script da Listagem 18.3.

Figura 18.6 Resultado da execuo do script da Listagem 18.13.
388
local regLarg, regAlt = canvas:attrSize()

local img = canvas:new('ginga.png')
local imgLarg, imgAlt = img:attrSize()
local imgX = (regLarg - imgLarg) / 2
local imgY = (regAlt - imgAlt) / 2
canvas:compose(imgX, imgY, img)

local txt = 'TV Digital se faz com Ginga'
local txtLarg, txtAlt = canvas:measureText(txt)
local txtX = (regLarg - txtLarg) / 2
local txtY = imgY + imgAlt + 2
canvas:attrColor('white')
canvas:drawText(txtX, txtY, txt)

canvas:flush()

Listagem 18.13 Script ilustrando o uso do canvas.
O script da Listagem 18.13 comea guardando as dimenses da regio
inteira do NCLua nas variveis regLarg e regAlt com a chamada funo
canvas:attrSize(), que retorna a largura e a altura do canvas. Em seguida,
o mtodo canvas:new() recebe uma imagem e retorna um novo canvas,
img, que a representa. As dimenses da imagem so ento recuperadas e
utilizadas para calcular a posio centralizada na qual a imagem desenhada
na regio (imgX e imgY). A chamada canvas:compose(imgX,imgY,img)
sobrepe a imagem do Ginga regio do NCLua na posio informada.
4

Para desenhar a legenda do texto, primeiramente medido o tamanho que o
texto ocupa no canvas, com a chamada canvas:measureText(). A
posio horizontal centralizada do texto calculada de maneira similar da
imagem. J sua posio vertical calculada para um pouco abaixo da
imagem. Por fim, a chamada a canvas:attrColor('white') altera o
atributo de cor para branco, em futuras operaes sobre o canvas, para ento
desenhar o texto na posio calculada. Apenas com a chamada funo
canvas:flush() as operaes grficas descritas so de fato efetuadas.
Como se pode deduzir ao observar o exemplo, um objeto canvas guarda
em seu estado diversos atributos sob os quais as primitivas grficas devem
operar. Os atributos so acessados atravs de mtodos de prefixo attr

4
As coordenadas passadas para todos os mtodos grficos so sempre relativas ao ponto mais
esquerda e no topo do canvas (0,0), como comum entre sistemas grficos.
389
acompanhado do nome do atributo (por exemplo, attrColor), e servem tanto
para leitura, quando chamados sem parmetros (como o caso da chamada a
attrSize()), como para escrita, quando chamados com os novos parmetros
(como o caso da chamada a attrColor('white')).
Como mencionamos, a referncia completa do mdulo canvas, com todos
os atributos e operaes grficas suportados, pode ser encontrada no Captulo
10 da NBR 15606-2 [ABNT, 2011].
Exemplo 18.3 Grficos e Controle Remoto
Este exemplo apresenta um jogo bastante simples, no qual so exibidos os
logotipos das linguagens Lua e NCL. O usurio deve mover com o controle
remoto o logotipo de Lua at o de NCL, quando exibida uma imagem
indicando o fim do jogo. O exemplo explora os eventos da classe key e o
pacote grfico canvas. A Figura 18.7 mostra as vises temporal e espacial da
aplicao.
lua
lua
viso temporal
viso espacial
ganhou
tempo do movimento que o usurio
faz do logotipo NCL
lua
chegou
ganhou

O documento NCL possui como mdias apenas o objeto NCLua (lua)
com o jogo e a imagem Voc ganhou (ganhou), que exibida quando o
logotipo de Lua encontra o de NCL (acontecimento representado pela ncora
chegou do NCLua). O jogo inicia assim que o documento carregado. A
Figura 18.18 mostra a viso estrutural da aplicao.
390
lua
ganhou
chegou
pInicio
onBegin start

O cdigo NCL bem simples, como definido na Listagem 18.14. Note
que a aplicao NCL propositalmente no tem fim, para manter sua
simplicidade.
<body>
<port id="pInicio" component="lua"/>
<media id="lua" src="jogo.lua" descriptor="dsLua">
<area id="chegou" label=chegou/>
</media>
<media id="ganhou" src="ganhou.jpg"
descriptor="dsGanhou"/>

<bind role="onBegin" component="lua" interface="ganhou"/>
<bind role="start" component="ganhou"/>
</link>
</body>
Listagem 18.14 Cdigo NCL do Exemplo 18.3.
Nos exemplos anteriores, o cdigo da aplicao estava concentrado no
documento NCL; agora praticamente todo o cdigo est dentro do NCLua. As
primeiras linhas do cdigo NCLua criam duas tabelas para representar os
logotipos de Lua e NCL (Listagem 18.15).
local img = canvas:new('lua.png')
local larg, alt = img:attrSize()
local logoLua = { canvas=img, x=10,y=10, larg=larg,alt=alt }

local img = canvas:new('ncl.png')
local logoNcl = { canvas=img, x=10,y=10, larg=larg,alt=alt }
Listagem 18.15 Primeira parte do cdigo NCLua do Exemplo 18.3.
391
Conforme a Listagem 18.15, o logotipo de Lua representado pela tabela
logoLua, guardando o canvas com a imagem lua.png, as coordenadas x e y
onde ela deve ser desenhada, e sua largura e altura. A tabela logoNcl guarda
os mesmos atributos (mas para a imagem ncl.png) para representar o logotipo
de NCL.
A Listagem 18.16 define a funo de redesenho da tela, chamada durante a
execuo do NCLua toda vez que o usurio movimenta o logotipo de Lua.
Sempre que chamada, a funo redraw desenha um retngulo preto ocupando
a regio inteira (para limp-la) e em seguida compe os canvas das duas
tabelas logoNcl e logoLua, sobre o canvas principal, em suas posies
correntes.

function redraw ()
canvas:attrColor('black')
canvas:drawRect('fill', 0,0, canvas:attrSize())
canvas:compose(logoNcl.x, logoNcl.y, logoNcl.canvas)
canvas:compose(logoLua.x, logoLua.y, logoLua.canvas)
canvas:flush()
end
Listagem 18.16 Segunda parte do cdigo NCLua do Exemplo 18.3.
Por fim, a Listagem 18.17 define a funo tratadora de eventos,
responsvel por tratar as teclas do controle remoto e por sinalizar, ao
documento NCL, o momento em que os logotipos se sobrepem.
-- apenas eventos de tecla interessam
if evt.class == 'key' and evt.type == 'press'
then
-- apenas as setas que movem o logotipo Lua
interessam
if evt.key == 'CURSOR_UP' then
logoLua.y = logoLua.y - 10
elseif evt.key == 'CURSOR_DOWN' then
logoLua.y = logoLua.y + 10
elseif evt.key == 'CURSOR_LEFT' then
logoLua.x = logoLua.x - 10
elseif evt.key == 'CURSOR_RIGHT' then
logoLua.x = logoLua.x + 10
end
-- testa se os logotipos esto sobrepostos
if sobrepondo(logoLua, logoNcl) then
-- sinaliza que a ancora "chegou" esta ocorrendo
392
event.post {
class = 'ncl',
label = 'chegou',
action = 'start',
}
end
redraw() -- redesenha a tela inteira
end
end
Listagem 18.17 Terceira parte do cdigo NCLua do Exemplo 18.3.
Na Listagem 18.17, o script inicia testando se alguma das teclas direcionais
foi pressionada (campo key do evento de tecla), alterando a posio do
logotipo de Lua de acordo com a tecla. Caso os logotipos estejam se
sobrepondo, postado o evento para sinalizar que a ncora chegou iniciou.
A funo sobrepondo foi omitida sem prejuzo do entendimento. Por fim, a
tela redesenhada, qualquer que seja a tecla que tenha sido pressionada.
Em um evento da classe key, o valor da tecla uma string, guardada no
campo key. O campo type pode ser press ou release, dependendo de a
tecla ter sido pressionada ou solta.
18.4.1 Programando com Animaes
Imaginemos agora que o logotipo de Lua fosse movimentado com o passar
do tempo, como em uma animao, em vez de ser guiado pelo controle
remoto. Ao receber a instruo de start, o trecho hipottico da Listagem
18.18 atualiza a posio do logotipo a cada 30 milissegundos, at que sua
posio chegue a 100.
if evt.action == 'start' then
while logoLua.x < 100 do
redraw()
sleep(30)
end
end
end
event.register(tratador, 'ncl', 'presentation')
Listagem 18.18 Exemplo (ruim) de animao em NCLua.
393
O problema com esse cdigo que a chamada funo sleep bloqueia o
tratador, no permitindo que outros eventos sejam processados, inviabilizando
essa proposta.
Uma possvel soluo seria criar uma funo de update a ser chamada a
cada 30 milissegundos por um temporizador (Listagem 18.19).
function update ()
redraw()
if logoLua.x < 100 then
event.timer(update, 30)
end
end
update()
end
end
Listagem 18.19 Exemplo de animao em NCLua que utiliza um temporizador.
Pela listagem anterior, ao ser chamado, o tratador ativa a funo update,
que atualiza a posio do logotipo de Lua, chama a funo de redesenho e,
caso o logotipo ainda no tenha alcanado a posio 100, se programa para
ser chamado novamente aps 30 milissegundos de espera.
Essa soluo no to legvel quanto um loop localizado, mas mantm o
NCLua reativo a possveis eventos que possam chegar durante os 30
milissegundos.
18.4.2 Corrotinas de Lua
O mecanismo de corrotinas de Lua simplifica muito a programao de
aplicaes em que muitos objetos interagem e devem estar permanentemente
sincronizados.
Apesar de serem comumente comparadas a threads, as corrotinas so,
na verdade, muito mais prximas do conceito comum de funo (ou rotina).
Da mesma forma que as funes, chamadas a corrotinas so sncronas, isto ,
o cdigo que chama uma corrotina sempre aguarda o seu retorno. No entanto,
uma corrotina pode explicitamente suspender sua prpria execuo,
preservando o seu estado corrente (isto , variveis locais, contador de
instrues), antes do seu trmino completo. Ao se suspender, uma corrotina
retorna imediatamente o controle a quem a chamou. Nesse caso, a corrotina
394
pode, a partir de outro trecho do cdigo, ter sua execuo continuada do
ponto onde parou, executando at o seu trmino ou nova suspenso. Note que
uma corrotina que no se suspende antes de terminar exatamente uma rotina
comum.
O uso de corrotinas em Lua feito atravs das seguintes primitivas:
- coroutine.create (f): retorna uma nova corrotina a partir da funo
passada como parmetro. Cria os meios pelos quais o estado de uma
corrotina preservado entre suspenses
- coroutine.resume (co): recomea a execuo da corrotina do ponto onde
parou. Tambm serve para iniciar a corrotina
- coroutine.yield (): suspende a execuo da corrotina em execuo
- coroutine.status (co): retorna o estado da corrotina passada, que pode ser
running, suspended, normal ou dead
Voltando ao exemplo da animao do logotipo de Lua, agora podemos
usar o loop problemtico da Listagem 18.18, bastando coloc-lo dentro de
uma corrotina e trocando a chamada sleep() por coroutine.yield() (Listagem
18.20).
function animaLogoLua ()
while lua.x < 100 do
lua.x = lua.x + 5
redraw()
coroutine.yield() -- sleep(30)
end
end
coAnimaLogoLua = coroutine.create(animaLogoLua)

function update ()
coroutine.resume(coAnimaLogoLua)
if coroutine.status(coAnimaLogoLua) ~= 'dead' then
event.timer(30, update)
end
end

update()
end
end
Listagem 18.20 Exemplo de uso de corrotinas para realizar uma animao.
395
Na listagem, a funo update acorda a corrotina a cada 30
milissegundos at que ela termine, o que acontece quando o logotipo chega
posio 100 quando o loop encerrado.
O uso de corrotinas simula a execuo sequencial de cdigo em
situaes em que, na verdade, uma entidade externa aplicao controla sua
execuo (o temporizador, no exemplo apresentado).
possvel, ainda, trocar valores entre chamadas e suspenses de
corrotinas, analogamente passagem de parmetros de funes. Para uma
descrio mais detalhada do suporte a corrotinas de Lua, o manual da
linguagem deve ser consultado [Ierusalimschy et al., 2006].
Exemplo 18.4 Corrida de Cavalos (Parte I)
Imaginemos a simulao de uma corrida de cavalos. Neste exemplo, a
primeira parte da simulao, o script para a animao de apenas um cavalo,
criado. A segunda parte, apresentada no Exemplo 18.5, resa esse script na
definio de todos os cavalos.
A Figura 18.9 apresenta uma tira de imagens, com o cavalo em diversas
posies. A cada intervalo de tempo, uma imagem diferente do cavalo ser
mostrada na tela, dando uma sensao de realidade animao.

Figura 18.9 Imagem dos cavalos do Exemplo 18.4.
A tabela representando o cavalo um pouco diferente da usada para
representar os logotipos do exemplo anterior (Listagem 18.21).
local img = canvas:new('cavalo.png')
local cavalo = { canvas=img, quadro=0,
larg=larg/5, alt=alt }
Listagem 18.21 Tabela representando os cavalos
A largura do cavalo igual largura da imagem dividida pelo nmero de
quadros da tira. Alm disso, a tabela tambm guarda o quadro a ser exibido,
que varia durante a animao.
A funo de redesenho deve exibir apenas a parte da imagem dos cavalos
que representa o quadro corrente. A funo compose aceita parmetros extras
para indicar que regio do canvas de origem (cavalo.img) deve ser composta.
396
Os parmetros so as posies x,y da origem e a largura e altura a partir
desse ponto (Listagem 18.22).
function redraw ()
canvas:attrColor('black')
canvas:drawRect('fill', 0,0, canvas:attrSize())
canvas:compose( cavalo.x, cavalo.y, cavalo.canvas,
cavalo.quadro*cavalo.larg,0,
cavalo.larg,cavalo.alt) )
canvas:flush()
end
Listagem 18.22 Funo de redesenho
Para animar o cavalo, usaremos uma corrotina, como no exemplo anterior
(Listagem 18.23).
function animaCavalo ()
local partida = 10 -- posio da linha de partida
local chegada = 500 -- posio da linha de chegada
local mudaQuadro = 20 -- muda de quadro a cada 20px
cavalo.x = partida
while cavalo.x < chegada do
coroutine.yield()
local deslocamento = 3 + math.random(1,3)
cavalo.x = cavalo.x + deslocamento
mudaQuadro = mudaQuadro deslocamento
if mudaQuadro < 0 then
quadro = (quadro + 1) % 6
mudaQuadro = 20
end
redraw()
end
end
coAnimaCavalo = coroutine.create(animaCavalo)
Listagem 18.23 Corrotina para animao dos cavalos
O deslocamento do cavalo, a cada 30 milissegundos, varia de 3 a 6 pixels,
de acordo com a chamada funo math.random, para que a aplicao tenha
alguma imprevisibilidade. O cdigo para a funo update e o tratador de
eventos so iguais aos do exemplo anterior, bastando trocar o nome da
corrotina de animao.
Novamente, o uso de uma corrotina permite que o cdigo do cavalo seja
escrito sequencialmente, facilitando o desenvolvimento e o entendimento do
mesmo.
397
18.5 Reso de Cdigo Lua
Conforme mencionado por diversas vezes, um documento NCL no contm
cdigo Lua diretamente, mas referencia um objeto contendo o cdigo Lua.
Isso cria dois ambientes isolados de programao e tambm permite que um
mesmo cdigo Lua possa ser reusado em diversos objetos de mdia NCL.
Para tornar ainda mais verstil essa abordagem, elos de atribuio em NCL
podem ser usados para informar parmetros a scripts Lua. ncoras em
objetos de mdia NCLua permitem tanto que o cdigo Lua sirva como
condio para o disparo de elos quanto permitem que o cdigo Lua trate
aes provenientes de elos, como j vimos.
O reso de cdigo Lua permite, por exemplo, que se definam componentes
grficos (ou widgets), tais como caixas de texto ou painis de opo, uma
nica vez. Cada componente grfico poderia ser reusado e parametrizado em
documentos NCL como um objeto de mdia orquestrado, tal como qualquer
outro objeto de mdia.
Exemplo 18.5 Corrida de Cavalos (Parte II)
Este exemplo estende o Exemplo 18.4 para ilustrar uma corrida entre
cavalos. O mesmo script NCLua, responsvel pela animao de um nico
cavalo, reusado na especificao de quatro objetos de mdia, demonstrando
o uso de NCL como um orquestrador entre objetos de cdigo imperativo de
igual contedo.
A Figura 18.10 apresenta a viso estrutural do exemplo. O objeto de mdia
cavalo1 a porta de incio da exibio do documento. Quando cavalo1
iniciado, os outros objetos de mdia cavalo2, cavalo3 e cavalo4
tambm so iniciados. Os quatro objetos de mdia referenciam o mesmo
arquivo de extenso .lua.
cavalo1
cavalo2
pInicio
cavalo3
onBegin
start
start
cavalo4
start

Figura 18.10 Viso Estrutural do Exemplo 18.5.
398
A Figura 18.11 ilustra as vises temporal e espacial do exemplo. Na viso
temporal, as quatro animaes em NCLua aparecem com o mesmo tempo
total de exibio, por simplificao. Na prtica, conforme explicado no
Exemplo 18.4, o tempo total de cada animao imprevisvel, j que cada
cavalo possui um fator de deslocamento que varia de 4 a 6 pixels a cada 30
milissegundos.
viso temporal
viso espacial
cavalo1
cavalo2
cavalo3
cavalo4
cavalo1
cavalo2
cavalo3
cavalo4

Exemplo 18.6 Passagem de Valores
Esta seo apresenta uma aplicao que ilustra o reso de cdigo Lua em
documentos NCL e a passagem de valores de propriedades entre objetos
NCLua.
Quando inicia a aplicao, um campo de entrada e dois campos de sada
so exibidos na tela. Enquanto o usurio preenche o campo de entrada, o
primeiro campo de sada automaticamente atualizado com o texto que vai
sendo digitado. Apenas quando o usurio encerra a digitao por meio do
boto OK do controle remoto ou atravs do ENTER no teclado alfanumrico,
o texto digitado at o momento copiado para o segundo campo de sada.
A Figura 18.12 ilustra a viso estrutural deste exemplo. O objeto NCLua
entrada disparado no incio do documento, o que faz iniciar tambm os
outros dois objetos NCLua saida1 e saida2. O foco para a digitao
inicia no campo de entrada onde a propriedade texto armazena o valor
atual digitado pelo usurio. A cada mudana no valor da propriedade texto,
399
seu valor copiado para a propriedade texto do objeto saida1, o que
atualiza o que exibido pelo primeiro campo de sada. Por outro lado, apenas
quando a ncora selecao do objeto entrada iniciada, seu valor
copiado para a propriedade texto do objeto saida2.
entrada
saida1
selecao
onBeginSet
set
output2.texto = input.texto
pInicio
saida2
onBeginStart
start
start
onEndAttributionSet
texto
set
saida1.texto = entrada.texto

Os campos de entrada e sada so implementados em dois scripts Lua
diferentes. Ambos os cdigos tratam a propriedade texto mantendo-a com o
texto visualizado. No caso do campo de entrada, a propriedade texto
controlada pelo prprio NCLua e alterada toda vez que uma nova tecla
pressionada. No caso do campo de sada, a propriedade texto deve ser
controlada pelo documento NCL, atravs de elos de atribuio.
Neste exemplo, os objetos NCLua podem ser vistos como caixas-pretas,
no importando o contedo dos arquivos .lua. Para o autor do documento
NCL basta saber a interface que cada um dos NCLua oferece com suas
propriedades texto e a ncora selecao, especificamente no campo de
entrada. Dessa forma, os arquivos .lua podem ser reusados em outras
aplicaes.
O campo de entrada representado em NCL pelo cdigo na Listagem
18.24.
<media id="entrada" src="input.lua" descriptor="dsInput">
<area id="selecao" label=sel/>
<property name="texto"/>
</media>
Listagem 18.24 Elemento <media> para a entrada
O objeto possui a ncora selecao, que iniciada sempre que o usurio
pressiona OK no controle remoto ou ENTER no teclado alfanumrico.
400
Os campos de sada so representados com o cdigo da Listagem 18. 25.
<media id="saida1" src="output.lua" descriptor="dsOutput1">
</media>
<media id="saida2" src="output.lua" descriptor="dsOutput2">
</media>
Listagem 18.25 Elementos <media> para as sadas
A parte mais importante do documento a que contm os elos responsveis
por copiar o contedo do campo de entrada para os campos de sada.
O primeiro campo de sada atualizado sempre que a propriedade texto
do campo de entrada alterada (Listagem 18.26).
<link xconnector="onEndAttributionSet">
<bind role="onEndAttribution" component="entrada"
interface="texto"/>
<bind role="set" component="saida1" interface="texto">
<bindParam name="var" value="$get"/>
</bind>
<bind role="get" component="entrada" interface="texto"/>
</link>
Listagem 18.26 Relacionando o campo de entrada e o primeiro campo de sada
A associao com o papel get, definido no prprio elo, permite consultar
o valor de uma propriedade de qualquer objeto, guardando-o na varivel
$get. No exemplo, a propriedade consultada texto do objeto entrada.
A varivel $get, por sua vez, utilizada na associao com o papel de
atribuio set, fazendo com que o valor da entrada seja copiado para a
propriedade texto do objeto saida1.
O segundo campo de sada atualizado somente quando a ncora
selecao do objeto de entrada iniciada (Listagem 18.27).
<link xconnector="onBeginSet">
<bind role="onBegin" component="entrada"
interface="selecao"/>
<bind role="set" component="saida2" interface="texto">
<bindParam name="var" value="$get"/>
</bind>
<bind role="get" component="entrada" interface="texto"/>
</link>
Listagem 18.27 Relacionando o campo de entrada e o segundo campo de sada
401
O mesmo mecanismo de cpia de valores de uma propriedade para outra
tambm usado para a cpia do valor digitado no campo de entrada para o
segundo campo de sada.
Bibliografia
ABNT, NBR 15606-2, 2011. Associao Brasileira de Normas Tcnicas,
Ierusalimschy, R.; Figueiredo, L.H.; Celes, Waldemar. Lua 5.1 Reference
Manual. Lua.org, Agosto de 2006. ISBN 85-903798-3-3.
ITU-T, H.761, 2011. Nested Context Language (NCL) and Ginga-NCL for
IPTV. ITU-T Rec. H.761.
SantAnna F.; Soares Neto, C.S.; Barbosa, S.D.J. Aplicaes
Declarativas NCL com Objetos NCLua Imperativos Embutidos.
PUC-Rio, N. 17/09. Rio de Janeiro, junho de 2009. ISSN 0103-9741.
Soares, L.F.G.; SantAnna, F.F; Cerqueira, R. (2008). Nested Context
Language 3.0 Part 10 Imperative Objects in NCL: The NCLua
Scripting Language. Monografias em Cincia da Computao do
Departamento de Informtica, PUC-Rio, N. 02/08. Rio de Janeiro, janeiro
de 2008. ISSN 0103-9741.
Soares, L.F.G.; Moreno, M.F.; SantAnna (2009). Relating Declarative and
Imperative Objects through the NCL Glue Language. Proceedings of the
ACM Symposium on Document Engineering. Munique, setembro de 2009

402

Apndices

403
Apndice A

Codificao Digital
na Comunicao de
Dados Multimdia
A digitalizao presenciada nos sistemas de telecomunicao, em
paralelo aos avanos que a tecnologia digital j estava proporcionando aos
sistemas computacionais, motivou, nos anos 1990, a idia de que a
convergncia dessas duas reas traria benefcios incomparveis. A evoluo
tecnolgica tornou possvel o desenvolvimento de sistemas para
processamento e comunicao de informaes representadas pela integrao
de vrias mdias: texto, udio, vdeo etc. O efeito da convergncia sobre os
usurios , entretanto, menos tecnolgico e mais prtico. O que se percebe, ao
longo desse processo, a crescente disponibilidade de um conjunto de
servios totalmente integrados, oferecidos de forma padronizada, de fcil
acesso e a preos baixos, alm da introduo de servios, chamados de valor
adicionado, que se juntam a um servio principal complementando-o de forma
a agregar valor e gerar mais interesse por parte do consumidor.
A mistura de diferentes tipos de mdia em sistemas integrados de
transmisso de informao decorrente da convergncia digital exige novas
formas para a codificao eficiente dos dados. Neste captulo, apresentaremos
os principais conceitos envolvidos na codificao digital dessas informaes e
na sua comunicao.
404
A.1 Informao e Sinal
Os seres humanos adquirem informao atravs de seus sentidos: viso,
audio, tato, olfato e paladar. Esses sentidos so denominados mdias
1
de
percepo. As informaes adquiridas so ento codificadas em estruturas de
dados que denominamos mdias de representao, ou simplificadamente
mdias. So exemplos de mdias de representao as mdias texto, grfico,
udio e vdeo. Note que no existe uma correspondncia biunvoca entre as
mdias de percepo e de representao e que ainda , no mnimo, pouco
usual a utilizao de mdias representando informaes adquiridas pelo olfato,
tato e paladar, embora j existam estudos nesse sentido.
Podemos definir [Soares et al., 1995] sinais como ondas que se
propagam atravs de algum meio fsico, possuindo, por exemplo, uma
amplitude que varia ao longo do tempo, correspondendo codificao da
informao transmitida. Um sinal pode ser distorcido durante sua
transmisso, por ele ter em suas componentes de frequncia atenuaes
diferentes devido a limitaes do meio de transmisso. provvel tambm
termos perda ou deformao de parte do sinal por rudos, como tambm
discutido em Soares et al. (1995). Ao transmitir informaes esperamos, no
entanto, preservar seu significado e recuperar seu entendimento.
Podemos, ento, introduzir informalmente o conceito de qualidade de
sinal e qualidade da informao transmitida, atravs de um exemplo. Um
vdeo transmitido a 30 quadros por segundo (padro de TV), certamente tem
uma qualidade de sinal melhor do que se fosse transmitido a 10 quadros por
segundo (imagine, por exemplo, que a cada trs quadros dois so perdidos).
Se estivssemos filmando uma paisagem sem qualquer movimento, a
qualidade da informao transmitida seria, entretanto, a mesma (nesse caso
extremo bastaria at mesmo a transmisso de um nico quadro),
independentemente do sinal recebido. Se, no entanto, o vdeo tivesse muito
movimento, a qualidade da informao transmitida no seria boa a 10
quadros por segundo e a sensao obtida seria a de vrias imagens com
movimentos bruscos, sem naturalidade.
Do exemplo anterior, podemos notar que um sinal pode carregar muita
informao redundante. Tcnicas para reduo dessa redundncia,
denominadas tcnicas de compresso e de compactao, so usualmente
empregadas. Sobre elas teremos muito o que discutir ao longo deste apndice.
Vamos, no entanto, primeiramente, aprofundar um pouco mais a discusso
sobre informaes e sinais, analgicos e digitais.

1
Em portugus, mdia vem da palavra latina medius (de onde derivou a palavra anglo-saxnica
medium), e seu plural mdias (correspondendo palavra anglo-saxnica media).
405
Inicialmente, os computadores estavam restritos ao processamento e
comunicao de dois tipos de dados letras e nmeros. Cdigos para
nmeros (binrios, BCD, ponto flutuante IEEE etc.) esto hoje padronizados
e estabilizados. Cdigos para caracteres alfanumricos (ASCII, EBCDIC
etc.) so tambm amplamente aceitos. Enfim, a mdia textual hoje
razoavelmente bem entendida como codificao digital.
A mdia grfica foi a segunda mdia a ganhar representao nos
computadores digitais. Ela possui dois formatos: o vetorial e o matricial. O
formato vetorial bastante utilizado em modelagem geomtrica e nele as
figuras so representadas por um conjunto de segmentos de reta ou curvas,
dados pelas coordenadas de seus pontos e pelos atributos das linhas que os
unem. Imagens no formato matricial so usualmente chamadas de imagens
estticas. Nesse formato, as imagens so divididas em pequenas regies,
chamadas de elementos de fotografia, ou pixels (picture elements, algumas
vezes tambm chamados de pels). Para cada uma dessas regies guarda-se
sua informao codificada de cor. Quanto maior o nmero de bits para
codificar a cor, mais cores pode-se codificar e mais prximo pode-se chegar
da cor original. Temos, assim, uma matriz de M linhas e N colunas, onde
cada elemento representa um dos MxN pixels que compem a imagem. Na
reproduo da imagem, os pixels so reconstrudos utilizando-se a informao
de cor armazenada na matriz. Quanto menor for o tamanho do pixel, mais fiel
ser sua colorao com relao original, mas maior ser a matriz da
imagem. Ao tamanho da matriz d-se o nome de resoluo geomtrica da
imagem. A quantidade de bits utilizados para armazenar a cor de um pixel
chama-se resoluo de cor da imagem.
Informaes capturadas nas mdias textual e grfica so originalmente
digitais. Por isso, muitas vezes essas mdias so referidas como mdias
discretas. J informaes geradas por fontes sonoras e de vdeo apresentam
variaes contnuas de amplitude, constituindo o tipo de informao que
comumente percebida pelos sentidos humanos atravs de sinais que
denominamos analgicos. Devido a isso, as mdias de vdeo e udio so
usualmente referidas como mdias contnuas.
importante que se entenda que qualquer tipo de informao (seja
analgica ou digital) pode ser codificada em uma estrutura de dados (mdia de
representao) digital, e essa codificao digital pode ser transmitida em um
sinal analgico ou digital, como veremos.
A codificao digital de informaes tem, em geral, vantagens em uma
comunicao. Isso se deve, principalmente, possibilidade de podermos
restaurar, no receptor, a informao codificada original, mesmo na presena
de distores, falhas ou rudos no sistema de transmisso.
406
A.2 Converso de Sinais
Para utilizarmos as vantagens da codificao digital, devemos
transformar as mdias contnuas de udio e vdeo, normalmente adquiridas
atravs de sinais analgicos. A essa transformao chamamos de converso
analgica digital, ou converso A/D.
Uma vez processados e transmitidos, os sinais digitais
2
podem ter de ser
transformados em analgicos para percepo pelos sentidos humanos. A essa
transformao chamamos de converso digital analgica, ou simplesmente
converso D/A.
A.2.1 Converso A/D
O teorema de Nyquist [Soares et al., 1995] assegura que uma taxa de
amostragem de 2W vezes por segundo o suficiente para recuperar um sinal
com largura de banda de W Hz. Isso quer dizer que, de um sinal analgico,
basta guardar os valores das amplitudes de suas amostras tomadas a
intervalos regulares de 1/2W segundos para que se possa ter toda a
informao necessria para reconstru-lo integralmente. O processo de
amostrar e guardar os valores dessas amostras, ilustrado na Figura A.1,
conhecido como Pulse Amplitude Modulation (PAM).
t
t
t 0
1
2
3
4
5
6
7
3,0
4,6
6,9
5,1
6,5
2,8
1,0
011 101 111 101 110 011 001
Sinal Original
Pulsos PAM
Quantizao
Sada PCM 011101111101110011001

Figura A.1 Pulsos PAM e PCM.

2
Um sinal digital pode ser transformado em sinal analgico, para transmisso em um dado meio,
tambm pelo processo de modulao, comentado no Captulo1.
407

A partir dos pulsos PAM, podemos produzir os pulsos PCM (Pulse
Code Modulation) atravs de um processo conhecido como quantizao, em
que cada amostra PAM aproximada a um inteiro de n bits. No exemplo da
Figura A.1, escolhemos n = 3, dando origem a oito nveis (2
3
) de
quantizao. A sada PCM corresponde ao resultado dessa quantizao.
Podemos calcular, a partir desse processo, denominado converso A/D,
a taxa gerada pela transmisso de informao analgica atravs de sinais
digitais.
3
Considere o caso de sinais de voz, por exemplo. Se assumirmos que
a banda passante necessria desses sinais tem largura igual a 3.100 Hz, a
taxa de amostragem de Nyquist , nesse caso, igual a 6.200 amostras por
segundo. Normalmente, amostra-se a uma taxa maior, para facilitar a
construo dos codecs (codificadores/decodificadores). Se escolhermos uma
taxa de 8.000 amostras por segundo e codificarmos cada amostra com oito
bits, a taxa gerada ser 8.000 8 = 64 Kbps, que a taxa definida pelo
padro ITU-T G.711 [ITU-T G.711, 1988] para telefonia digital.
A Figura A.1 ilustra o caso em que os nveis de quantizao so
igualmente espaados, ou seja, o quantum AQ (diferena entre nveis)
constante. Como consequncia, o erro mximo de quantizao dado por
AQ/2. Chamamos esse caso de quantizao linear. Nele, as amostras
pequenas so, em termos proporcionais, mais penalizadas pelo erro de
quantizao do que as grandes.
Para melhorar a qualidade do sinal amostrado, podemos usar uma
quantizao logartmica, onde o sinal primeiro transformado,
logaritmicamente, de forma a manter o erro mximo de quantizao
aproximadamente constante, a despeito da amplitude da amostra. Vrias
funes logartmicas foram propostas e estudadas com esse intento. Duas
dessas funes so largamente utilizadas e padronizadas, sendo denominadas
lei A e lei (Figura A.2). A primeira mais utilizada na Europa, enquanto a
segunda predomina nos Estados Unidos.

3
Neste apndice, consideraremos sempre o sinal digital gerado a partir de uma informao codificada
digitalmente com um bit por intervalo de sinalizao, ou seja, um sinal onde sua taxa em bauds a mesma
que sua taxa em bits por segundo [Soares et al., 1995].
408

Figura A.2: Lei A e lei .
A Tabela A.1 apresenta o resultado da converso A/D de alguns sinais
de udio e vdeo.
Tabela A.1 Converso A/D para alguns sinais de udio e vdeo
Sinais Faixa
Passante
Frequncia de
Amostragem
Codificao
Bits/Amostra (b/a)
Taxa de
Bits
Voz
(ITU-T G711)
3003.400 Hz 8.000 Hz Log PCM (8b/a) 64 Kbps
Qualidade CD
(estreo)
0 21 KHz 44,1 KHz Log PCM (16 b/a
por canal)
1,41 Mbps
(2 720,6
Kbps)
Vdeo (NTSC -
luminncia)
04,2 MHz 10 MHz 8 b/a 80 Mbps
A.2.2 Converso D/A
Pode-se demonstrar que um trem de pulsos PCM, obtido pela
amostragem de um sinal em uma frequncia maior ou igual dada pelo
teorema de Nyquist, tem o mesmo espectro de frequncia que o sinal
amostrado, no intervalo de frequncias dado pela banda passante desse sinal.
A converso D/A se faz, ento, pela simples passagem do trem de pulsos
409
PCM por um filtro na faixa passante (e, assim, com a largura de banda) do
sinal originalmente amostrado.
No fosse pelo erro de quantizao, o sinal obtido da sada do filtro
seria idntico ao sinal analgico original.
Note que o sinal de sada to mais prximo do sinal original quanto
menor for o erro de quantizao. O erro de quantizao, por sua vez, to
menor quanto maior o nmero de nveis de quantizao, ou seja, quanto maior
o nmero de bits utilizados na codificao.
A.2.3 Outros Codificadores de Onda
A codificao PCM representa cada amostra pelo seu valor absoluto,
mas essa no a nica representao possvel. Alternativamente, possvel
representar apenas a diferena entre o valor de uma amostra e o valor de sua
antecessora. Esse esquema de codificao denominado DPCM (Differencial
Pulse Code Modulation). Quando os valores das amostras so muito
prximos uns dos outros, necessitamos de um menor nmero de nveis para
representar as diferenas do que o necessrio para representar os valores
absolutos das amostras, para um mesmo erro de quantizao. Como um
menor nmero de nveis pode representar um menor nmero de bits para
codificar todos os nveis, utilizando o DPCM poderemos ter um menor
nmero de bits gerados pela codificao. O DPCM um caso particular de
codificao preditiva, em que o valor predito da amostra corrente o valor
da amostra anterior, guardando-se (codificando-se) ento o erro (diferena) de
predio.
A ideia do DPCM pode ser ainda refinada um pouco mais, variando-se
dinamicamente os nveis de quantizao, dependendo de o sinal variar muito
ou pouco. Dessa forma, prev-se no apenas o valor da amostra corrente
baseado na amostra anterior, mas tambm o valor do quantum, baseado em
uma funo, bem conhecida, dos valores de amostras anteriores. Esse
esquema denominado ADPCM, de Adaptative Differencial Pulse Code
Modulation.
Existem ainda outras formas de codificao que independem do tipo do
sinal analgico. Vamos citar apenas mais uma, a SBC (SubBand Coding). Na
codificao por sub-bandas, o espectro de frequncia do sinal dividido em
vrias bandas de frequncia. Cada banda ento tratada como se
representasse um sinal distinto, e nela aplicada qualquer uma das tcnicas
anteriores. A vantagem da SBC que, atravs da anlise de um sinal,
podemos identificar suas bandas mais importantes no transporte da
informao. Para essas bandas, utilizamos um erro de quantizao menor do
que aquele usado nas bandas menos importantes, ou seja, podemos codificar
410
as bandas menos importantes utilizando um nmero menor de bits por
amostras.
A.3 Compresso e Compactao
Um sinal digital, em geral, carrega muita informao redundante. Se
eliminarmos essa redundncia conseguiremos reduzir em muito a quantidade
de bits gerados, que, em alguns casos, pode ser muito grande; pela Tabela
A.1, por exemplo, observa-se que apenas 1 minuto de vdeo preto-e-branco
gera 600 Mbytes.
Quando eliminamos apenas a redundncia de um sinal, no h perda de
informao e dizemos que fizemos uma compactao, ou compresso sem
perdas. No entanto, podemos tambm diminuir a quantidade de bits com
alguma perda de informao. Dependendo de quem for o usurio da
informao, parte dela pode ser considerada pouco til. Raramente
necessrio manter o sinal original intacto no caso das mdias vdeo, udio e
imagens estticas, uma vez que o usurio final perderia de qualquer forma
parte da informao por limitaes fsicas; tal o caso do ouvido e do olho
humanos. Vemos, assim, que a quantidade de informao que podemos perder
dependente do usurio, mas ela tambm pode depender da tarefa em
desenvolvimento: por exemplo, perder um pouco da nitidez de um vdeo em
uma videotelefonia perfeitamente aceitvel, enquanto a perda da qualidade
do vdeo pode ser inadmissvel em uma aplicao mdica. Quando na reduo
dos dados gerados h perda de informao, dizemos que fizemos uma
compresso com perdas, ou simplesmente compresso.
Existem vrias tcnicas de compresso sem perdas (compactao) que
podem ser aplicadas a qualquer tipo de dados, independentemente da mdia
representada. As Sees A.3.1 a A.3.5 so dedicadas a algumas dessas
tcnicas mais usuais. As tcnicas de compresso com perdas sero estudadas
para cada mdia em particular nas Sees A.3.6 a A.3.8.
A.3.1 Codificao por Carreira
O desempenho da codificao por carreira (run length coding) depende
muito da estatstica dos dados de entrada. Ela consiste simplesmente em
representar os dados pelo seu valor e o nmero de vezes que ele se repete. A
unidade para codificao pode ser um bit, um byte, um caractere, um pixel,
uma amostra etc. A Figura A.3 ilustra o caso da unidade ser um pixel de 8
bits e o caso da unidade ser o bit.
411
13 13 13 13 13 14 15 15 15 15 16 16
13 | 05 14 | 01 15 | 04 16 | 02
imagem binria
0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0
0 | 06 1 | 05
1
. . .
0 | 05

Figura A.3 Codificao por carreira.
A.3.2 Codificao de Shannon-Fano
Para as duas prximas tcnicas de codificao, imagine que nossos
dados sejam apenas os smbolos A, B, C, D e E (que podem representar um
pixel, uma amostra de udio ou vdeo, um caractere etc.) e que eles ocorram
na frequncia dada pela tabela a seguir.
Smbolo A B C D E
Nmero de
Ocorrncias
15 7 6 6 5

A codificao de Shannon-Fano constri a rvore de codificao
seguindo o seguinte algoritmo:
1. Alinhe os smbolos de acordo com suas
frequncias/probabilidades, por exemplo, ABCDE.
2. Divida recursivamente em duas partes, cada uma com
aproximadamente o mesmo nmero de contagem (soma das
frequncias).
A rvore gerada fica ento:

412
E temos a seguinte codificao, gerando uma compactao de 117:89.
Smbolo Frequncia Cdigo Subtotal (n. de
bits)
A 15 00 30
B 7 01 14
C 6 10 12
D 6 110 18
E 5 111 15

A.3.3 Codificao de Huffman
Tomando o mesmo exemplo da seo anterior, a codificao de
Huffman constri a rvore de codificao seguindo o seguinte algoritmo:
1. Iniciao: ponha todos os ns em uma lista ABERTA.
Mantenha a lista alinhada todo o tempo de aplicao do
algoritmo (por exemplo, ABCDE).
2. Repita at que a lista ABERTA contenha apenas um n:
a. Pegue os dois ns de mais baixas frequncias/probabilidades
e crie um n pai para ambos.
b. Atribua ao n pai a soma das frequncias/probabilidades
dos filhos e o insira na lista ABERTA.
c. Atribua cdigos 0 e 1 aos dois ramos da rvore e retire os
filhos da lista ABERTA.
A rvore gerada fica ento:

E temos a seguinte codificao, gerando uma compactao de 117:87.

413
Smbolo Frequncia Cdigo Subtotal (n. de
bits)
A 15 0 15
B 7 100 21
C 6 101 18
D 6 110 18
E 5 111 15
Note que, quer usando a codificao de Huffman ou de Shannon-Fano, o
decodificador deve usar o mesmo dicionrio de cdigos gerado pelo
codificador para recuperar os smbolos originais.
A.3.4 Codificao de Lempel-Ziv-Welch
Um procedimento diferente dos dois anteriores processar smbolo a
smbolo e ir construindo o dicionrio de cdigos passo a passo. medida que
o dicionrio vai sendo construdo, ele pode ser usado na codificao do
prximo smbolo, dinamicamente.
No esquema de Lempel e Ziv, posteriormente estendido por Welch, o
dicionrio construdo como uma estrutura de dados, uma tabela que mantm
sequncias de smbolos, em conjunto com um identificador nico (cdigo)
para toda a sequncia. A tabela contm at, digamos, 2
j
posies
(sequncias). Ela iniciada simplesmente com o conjunto dos 2
k
possveis
smbolos, isto , todas as sequncias de tamanho 1. Os melhores desempenhos
so conseguidos quando k << j, dependendo, obviamente, do grau de
redundncia dos dados.
A codificao se inicia definindo a sequncia de smbolos corrente S
como o primeiro smbolo a codificar. Note que S membro do dicionrio. A
codificao ento continua como a seguir:
1. Se no existem mais smbolos para codificar, d como sada o cdigo
da sequncia (j bits) para S. Em caso contrrio,
2. Pegue o prximo smbolo P e concatene a S, obtendo a nova
sequncia SP.
3. Se SP j estiver no dicionrio, faa S = SP e volte para o passo 1.
Em caso contrrio,
4. D como sada o cdigo da sequncia (j bits) para S.
5. Adicione SP ao dicionrio, se ainda houver espao.
6. Faa S = P e volte para o passo 1.
414
Note que, assim procedendo, o decodificador no tem a necessidade de
conhecer a priori todo o dicionrio, pois pode reconstru-lo passo a passo,
dinamicamente, a partir dos dados codificados. A decodificao se inicia
definindo a sequncia de smbolos corrente S como a entrada no dicionrio
correspondente ao primeiro cdigo a decodificar e dando como sada o
smbolo S. Se houver mais cdigos a decodificar:
1. Leia prximo cdigo X.
2. Se houver a entrada no dicionrio (P) correspondente a X:
a) D como sada P.
b) Adicione S concatenado ao primeiro smbolo de P no dicionrio,
caso a entrada no exista.
Se no houver a entrada no dicionrio (P) correspondente a X:
a) Faa P igual a S concatenado ao primeiro smbolo de S e
adicione ao dicionrio.
b) D como sada P.
3. Faa S igual a P e volte para o passo 1, se houver mais smbolos a
decodificar.
A.3.5 Outras Tcnicas de Compactao
Alm das tcnicas anteriormente mencionadas, outras so encontradas,
bem como variantes das primeiras. Uma, no entanto, merece destaque por ser
comumente utilizada: a codificao aritmtica.
A codificao aritmtica tambm parte do conhecimento da frequncia
de ocorrncias dos smbolos, tal qual as codificaes de Shannon-Fano e de
Huffman. Baseado na frequncia de ocorrncias, intervalos so associados
aos smbolos e, a partir desses intervalos, novos intervalos so construdos
para sequncias de smbolos. Uma sequncia pode ento ser codificada por
qualquer nmero dentro do intervalo calculado para a sequncia, garantindo
sua decodificao posterior sem ambiguidade. Em Cormen et al. (2002) pode-
se encontrar a especificao detalhada do algoritmo.
A.3.6 Compresso em Imagem Esttica
As imagens geram, normalmente, uma quantidade de informao muito
grande. Se levarmos em considerao a correlao do valor (cor) de cada
pixel, poderemos reduzir a quantidade de informao gerada.
Existe grande nmero de formatos para imagens estticas, com base em
esquemas diferentes de compresso. Dentre os mais usuais atualmente
415
podemos citar os formatos TIFF e GIF, que so baseados no algoritmo de
Lempel-Ziv, apresentado na Seo A.3.4, e o padro ISO para imagens
estticas, chamado JPEG [ISO/IEC 10918-1, 1994], baseado em
transformadas, como veremos mais adiante.
A forma mais simples de compresso de uma imagem a reduo da
sua resoluo geomtrica. Isso implica aumentarmos o tamanho da regio de
um pixel. Tal procedimento pode ser feito at um certo limite, dependendo do
usurio final e do dispositivo de exibio, para evitar o efeito apresentado na
Figura A.4, onde vemos primeiro a imagem original dividida em pixels e, em
seguida, a imagem reproduzida; a diferena se deve ao fato de o pixel
representar uma regio grande.

Figura A.4 Efeito do tamanho da regio de um pixel na codificao/decodificao.
Outra forma de compresso a reduo do espao de cor pela simples
utilizao de um nmero menor de bits para representao de cada pixel.
Cabe antes, no entanto, uma discusso sobre como as cores so
representadas.
Atravs das adies das cores vermelha, verde e azul, podemos obter
quase todas as cores visveis pelo olho humano. Assim, uma representao
bem comum a RGB (de Red, Green, Blue), na qual um pixel representado
pelos valores dessas componentes. comum encontrarmos o padro RGB 8-
8-8, em que se utilizam 8 bits para codificao de cada componente, e o
padro 5-6-5, em que reservado um nmero maior de bits (6) para a
componente verde, por ser o olho humano mais sensvel a essa componente.
Outra representao bastante utilizada o sistema YC
r
C
b
. A componente Y
denominada luminncia, e uma medida da sensibilidade do olho humano s
vrias componentes de frequncia de uma cor. Para as fontes usuais de luz
provenientes de dispositivos de vdeo, Y dada por:
416
Y = 0,299R + 0,587G + 0,114B
As componentes C
r
e C
b
so chamadas de crominncia e sua definio
varia de padro para padro, bem como o seu nome (componentes I e Q, no
padro NTSC de TV, e componentes U e V, no padro PAL de TV). C
r
e C
b

so os nomes utilizados pelos padres MPEG e JPEG, e tm seus valores
dados por:
C
r
= ((R Y)/1,6) + 0,5
C
b
= ((B Y)/2) + 0,5
O leitor deve observar que o conjunto de equaes para Y, C
r
e C
b

linearmente independente (isso tambm acontece para as outras definies de
C
r
e C
b
), ou seja, dados Y, C
r
e C
b
, obtm-se facilmente R, G e B.
O olho humano mais sensvel luminncia do que crominncia;
assim, na compresso pela reduo da resoluo de cor, podemos utilizar um
nmero menor de bits para as componentes da crominncia. Mais comum, no
entanto, utilizarmos uma menor resoluo geomtrica para as componentes
de crominncia do que aquela utilizada para a luminncia.
Uma outra forma de compresso de imagem esttica, geralmente sem
perdas, a codificao preditiva. De forma anloga explicao da Seo
A.2.3, na codificao preditiva de uma imagem realiza-se uma predio do
valor do pixel baseada em valores de outros pixels da imagem. A diferena do
valor real para o valor predito ento codificada. A Figura A.5 ilustra o caso.

Figura A.5 Imagem original e imagem com apenas os erros de predio.
Se, na imagem, os pixels tiverem valores muito prximos, pode-se usar
um nmero menor de bits para armazenar o erro da predio do que aquele
usado para codificar o valor absoluto do pixel. Alm disso, uma imagem com
poucos contornos vai gerar muitos valores pequenos ou mesmo o valor zero,
tornando o emprego de um outro mtodo de compresso posterior bem
eficiente.
417
Antes de continuarmos nossa discusso sobre tcnicas de compresso,
devemos ressaltar que, normalmente, as tcnicas de compresso so seguidas
pela aplicao de algum esquema de compactao. Muitas vezes, o esquema
de compresso simplesmente prepara os dados para que possam sofrer maior
compactao. Nada impede tambm que apliquemos vrias tcnicas de
compresso em sequncia.
Um exemplo de codificao preditiva pode ser encontrado no padro
JPEG [ISO/IEC 10918-1, 1994] no modo sem perdas, onde a codificao de
Huffman aplicada aps a codificao preditiva. No esquema apresentado na
Figura A.6, o codificador por entropia utiliza a codificao de Huffman. Note
tambm, pela figura, que existem sete possveis predies para um pixel X.
imagem
fonte
imagem
comprimida
Preditor
Codificador
por entropia
Tabela de
especificao

A
C

X
B

Selees
0
1
2
3
4
5
6
7
Predio
sem predio
A
B
C
A+BC
A+((BC)/2)
B+((AC)/2)
(A+B)/2

Figura A.6 JPEG sem perdas.
Existem ainda outras tcnicas para compresso de imagem, tais como a
codificao por sub-bandas (similar apresentada na Seo A.2.3) e a
quantizao vetorial. Entretanto, nos deteremos apenas em mais uma, por ser
utilizada nos padres JPEG e MPEG: a codificao por transformadas.
O leitor j deve ter percebido, pelas vrias referncias Seo A.2.3,
que existem vrias similaridades entre amostras no tempo e pixels. Na
verdade, podemos considerar os pixels como se fossem amostras do sinal
imagem, s que amostras obtidas no no tempo, mas no espao.
exatamente por isso que podemos aplicar todas as tcnicas da Seo A.2.3
nas imagens estticas. Note tambm que, em um sinal de vdeo, o grupo de
vrias amostras temporais forma um quadro (por exemplo, no sistema de TV
brasileiro, existem 30 quadros por segundo). Esse quadro uma imagem
esttica onde as amostras temporais do vdeo so os pixels (amostras
espaciais). Esse fato que nos permite no somente tratar o vdeo como um
sinal contnuo e nele aplicarmos todas as tcnicas de compresso conhecidas
para sinal contnuo, como tambm trat-lo como uma sequncia de imagens
estticas no tempo, aplicando as mesmas tcnicas de compresso utilizadas
para imagens.
418
Uma vez que uma imagem esttica pode ser considerada uma sequncia
de amostras espaciais, podemos agora pensar, como fizemos com os sinais
analgicos, em aplicar uma transformada (por exemplo, Fourier) para
descrever o mesmo sinal no domnio da frequncia. S que, agora, no domnio
das frequncias espaciais. Como estamos com um sinal discreto, precisaremos
de uma transformada discreta. Poderamos usar a transformada discreta de
Fourier, como mencionado, mas outra transformada leva a melhores
resultados na compresso: a transformada discreta de cossenos.
No espao bidimensional de uma imagem de 88 pixels, a transformada
discreta de cossenos (FDCT Forward Discrete Cosine Transform) dada
por:
F u v C u C v f x y
x u y v
x y
( , ) ( ) ( ) ( , ) cos
( )
cos
( )
=
+
(
+
(
= =

1
4
2 1
16
2 1
16
0
7
0
7
t t
C w para w ( ) =
=
1
2
0
C w para w ( ) , , ... , = = 1 1 2 7
F u v C u C v f x y
x u y v
x y
( , ) ( ) ( ) ( , ) cos
( )
cos
( )
=
+
(
+
(
= =

1
4
2 1
16
2 1
16
0
7
0
7
t t
C w para w ( ) =
=
1
2
0
C w para w ( ) , , ... , = = 1 1 2 7 C w para w ( ) , , ... , = = 1 1 2 7

E a transformada inversa (IDCT Inverse Discrete Cosine Transform)
por:
f x y C u C v F u v
x u y v
u v
( , ) ( ) ( ) ( , ) cos
( )
cos
( )
=
+
(
+
(
= =

1
4
2 1
16
2 1
16
0
7
0
7
t t

No domnio da frequncia, as mudanas abruptas que acontecem nos
contornos de uma figura esto concentradas nas frequncias mais altas.
Assim, uma imagem com poucos contornos deve concentrar seus coeficientes
nas frequncias baixas. Mais ainda, os coeficientes das frequncias altas so
menos importantes, e perdas nesses coeficientes podem diminuir um pouco a
nitidez da imagem, mas para muitas aplicaes isso pode ser aceitvel.
Pelos motivos mencionados no pargrafo anterior, aps uma imagem ser
transformada os coeficientes gerados so quantizados de forma diferenciada,
usando maior preciso (quantum menor) para as frequncias mais baixas.
Assim procede o padro JPEG [ISO/IEC 10918-1, 1994] no modo
sequencial, dividindo uma imagem em blocos de 88 pixels e aplicando uma
compresso em cada bloco, conforme o diagrama mostrado na Figura A.7. A
imagem varrida uma nica vez, da esquerda para a direita, de cima para
baixo.
419
Tabela de
especificao
imagem
fonte
imagem
comprimida
FDCT Quantizador
Codificador por
entropia
Tabela de
especificao

Figura A.7 Codificao JPEG modo sequencial.
No JPEG, aps a aplicao da transformada discreta de cossenos e a
quantizao dos coeficientes, estes so organizados da mais baixa frequncia
para a mais alta,
4
quando ento aplicada a codificao por carreira, seguida
da codificao de Huffman (ou codificao aritmtica), ilustradas na Figura
A.7 pelo bloco codificador por entropia.
A decodificao JPEG modo sequencial ilustrada na Figura A.8.
Tabela de
especificao
imagem
reconstruda
imagem
comprimida
IDCT Dequantizador
Decodificador
por entropia
Tabela de
especificao

Figura A.8 Decodificao JPEG modo sequencial.
O padro JPEG ainda possui mais dois modos de compresso: o
progressivo e o hierrquico.
O modo progressivo tambm utiliza a transformada de cossenos, mas a
imagem codificada em vrias varreduras. Na variante denominada seleo
de espectro, a cada varredura so codificados coeficientes das mesmas
frequncias de todos os blocos, da mais baixa frequncia para a maior
frequncia. J na variante denominada aproximao sucessiva, primeiro
codificado o coeficiente de mais baixa frequncia de todos os blocos e depois
so codificados, paulatinamente, os bits dos demais coeficientes de todos os
blocos, do mais significativo para o menos significativo.

4
Na verdade, um passo adicional existe no JPEG, quando os coeficientes DC (frequncia zero) de um
bloco so codificados pela diferena entre seu valor e o valor do coeficiente DC do bloco anterior.
420
Note que, no modo progressivo, os primeiros dados da imagem que so
decodificados j permitem ter uma viso completa da cena, embora ainda sem
muita nitidez. Com o restante dos dados, a nitidez vai se tornando cada vez
melhor. Isso pode ser til em vrios casos. Muitas vezes, navegando na Web,
queremos apenas ter uma ideia da informao que vem na pgina a seguir.
Certas vezes essa informao nem aquela que desejamos. Ter uma viso
rpida dessa informao, ainda que no com todos os detalhes, pode acelerar
em muito a tarefa sendo executada. Outras vezes podemos estar trafegando
com a imagem em um meio de pequena banda passante ou mesmo em um
trecho congestionado de uma rede. Nesses casos, o descarte seletivo dos
dados que no trazem muita informao pode ser a nica forma vivel de
manter a aplicao em funcionamento. Como veremos, um bom sistema de
comunicao deve poder identificar a parte da informao que ele deve
manter ntegra e quais partes ele pode perder, em caso de necessidade ou
convenincia.
O modo JPEG hierrquico tambm permite separar da imagem os dados
mais relevantes dos menos relevantes, mas atravs do aumento progressivo da
resoluo geomtrica. Nesse modo, a imagem codificada com mltiplas
resolues, de forma que a menor resoluo pode ser decodificada sem a
necessidade de se ter a resoluo maior.
A.3.7 Compresso em udio
A compresso de um sinal de udio depende muito do tipo de sinal.
Vamos comear pela voz humana.
Um ser humano falando emite surtos de voz apenas durante 35% a 40%
do tempo de fala. O restante do tempo preenchido com silncio que existe
entre palavras e entre uma sentena e outra. Se pudermos detectar esse
silncio e elimin-lo da codificao, de forma que ele possa ser recuperado na
decodificao, reduziremos muito a quantidade de dados gerados. Essa
tcnica aplicada telefonia digital com o nome TASI (Time Assignment
Digital Interpolation). Ainda como outra caracterstica da voz e do ouvido
humanos, a perda tolerada de surto de voz e de silncio muito diferente.
Perdas da ordem de 1% da informao do surto de voz so tolerveis,
5
ao
passo que podemos tolerar a perda de at 50% do silncio. Note que, com a
deteco de silncio, transformamos um trfego de voz contnuo em um
trfego em rajadas.

5
Na realidade, a porcentagem de perda depende do tamanho do surto de voz e se a perda ocorre no
incio ou no meio do surto. Em Gruber (1985] possvel encontrar uma discusso sobre o assunto.
421
Uma outra forma de comprimir a voz humana codificar, em vez de
suas amostras, os parmetros de um modelo analtico do trato vocal capaz de
gerar aquelas amostras. No mtodo conhecido como LPC (Linear Predictive
Coding), apenas os parmetros que descrevem o melhor modelo que se adapta
s amostras codificado. Um decodificador LPC usa esses parmetros para a
gerao sinttica da voz, que usualmente parecida com a original. O
resultado inteligvel, mas a tonalidade aquela de um rob falando (voz
metlica).
O CELP (Code Excited Linear Predictor) bastante similar ao LPC. O
codificador CELP gera os mesmos parmetros LPC, mas computa os erros
entre a fala original e a fala gerada pelo modelo sinttico. Tanto os
parmetros do modelo analtico do trato vocal quanto uma representao
comprimida dos erros so codificados. A representao comprimida um
ndice em um vetor de excitao (que pode ser pensado como um livro de
cdigos compartilhado pelo codificador e o decodificador). O resultado do
CELP tem uma qualidade de fala muito boa a uma taxa bem baixa. A Tabela
A.2 apresenta alguns padres para voz recomendados pelo ITU-T [ITU-T
G.711, 1988; ITU-G.722, 1988; ITU-T G.723, 1996; ITU-T G.726, 1990;
ITU-T G.728, 1992; ITU-T G.729, 1996].
Tabela A.2 Padres ITU-T para voz
Padro Algoritmo
Taxa de
Compresso (Kbps)
Recursos de
Processamento
Necessrios
Qualidade da
Voz Resultante
Atraso
Adicionado
G.711 PCM
48, 56, 64 (sem
compresso)
Nenhum Excelente Nenhum
G.722 SBC/ADPCM
64 (faixa passante
de 50 Hz a 7 KHz)
Moderado Excelente Alto
G.723 MP-MLQ 5.3, 6.3 Moderado
Boa (6.3)
Moderada (5.3)
Alto
G.726 ADPCM 16, 24, 32, 40 Baixo
Boa (40)
Moderada (24)
Muito baixo
G.728 LD-CELP 16 Muito alto Boa Baixo
G.729 CS-ACELP 8 Alto Boa Baixo
Mais especificamente para udio, de forma geral, um padro muito
importante o MPEG udio [ISO/IEC 11172-,3 1993; ISO/IEC 13818-3,
1998; ISO/IEC 13818-7, 1997; ISO/IEC 14496-3, 2004].
O MPEG udio leva em conta o modelo psicoacstico humano para
realizar uma compresso perceptualmente sem perdas. O modelo divide o
domnio de frequncia audvel (entre 20 Hz e 20 KHz) em 32 bandas,
chamadas bandas crticas. O sistema de audio tem uma resoluo limitada e
422
dependente da frequncia. A medida perceptualmente uniforme de frequncias
pode ser expressa em termos das larguras das bandas crticas. A Figura A.9
mostra a sensibilidade do ouvido humano nas diversas frequncias.
40
30
20
10
0
0 2 4 6 8 10 12 14 16
d
B
Frequncia (kHz)
Limite no Silncio

Figura A.9 Sensibilidade do ouvido humano.
Note que a sensibilidade do ouvido ilustrada na Figura A.9 medida em
decibis (dB SPL dB Sound Preassure Level ou, simplificadamente,
dB). O decibel uma unidade conveniente para expressar o que se chama de
nvel sonoro. O som, de forma geral, tem uma medida de intensidade que a
potncia transferida por uma onda sonora por rea de uma superfcie que
intercepta essa onda. O decibel nada mais do que uma forma comparativa
de analisar valores. Nesse caso, em vez de fornecer o valor absoluto da
intensidade sonora para uma frequncia, podemos fornecer o seu valor
dividido pela menor intensidade perceptvel ao ouvido humano
6
e utilizar uma
escala logartmica para representar essa razo, j que o intervalo de
intensidades produzido pela voz humana muito grande. Assim, o nvel
sonoro em decibis | definido como:
|
|
.
|
\
|
=
0
10
log 10
I
I
|

onde I
0
o menor valor de intensidade sonora perceptvel ao ouvido e I a
intensidade do som sendo medido. Note que, para I = I
0
, temos | = 0 dB, ou
seja, a nossa referncia de menor intensidade perceptvel corresponde a 0 dB.
Voltando ao MPEG udio, seu modelo leva em conta o mascaramento
de frequncias, caracterstica do ouvido humano que, quando submetido a um
sinal de certa amplitude em dada frequncia, mascara as outras frequncias

6
O valor de referncia definido como I
0
= 10
12
watts/m
2
. Ele corresponde a aproximadamente o
limiar da audio humana. No entanto, o limiar de audio varia de frequncia para frequncia e com a
intensidade do som, como descoberto por Fletcher e Munson em 1933.
423
ao redor que possuam uma amplitude abaixo de um certo limite. A Figura
A.10 ilustra o caso.
Amplitude
Sinal tonal forte
Regio onde os sinais
fracos so mascarados
Frequncia

Figura A.10 Mascaramento de frequncias.
O MPEG udio transforma o sinal para o domnio da frequncia e
aplica o mascaramento de frequncias, codificando apenas aquelas
componentes de frequncia que no so mascaradas. A Figura A.11 ilustra o
procedimento.
0 Frequncia
Depois
20.000
0 Frequncia 20.000
Antes

Figura A.11 Mascaramento de frequncias nas bandas crticas MPEG.
O MPEG udio tambm leva em considerao resultados psicoacsticos
que mostram que, para frequncias maiores que 2 KHz, o ouvido percebe a
424
imagem estereofnica baseado mais no envelope temporal do udio do que em
sua estrutura mais refinada. Assim, no modo intensity stereo, o codificador
soma as frequncias mais altas do sinal estereofnico em um nico sinal. Os
canais de esquerda e direita so reconstrudos com a mesma forma, mas com
magnitudes diferentes, baseadas em fatores de escala.
Na codificao MPEG, para cada intervalo de tempo de udio
codificado (isto , para cada conjunto de amostras), existe um nmero fixo de
bits total para todas as 32 sub-bandas. Escolhe-se o nmero de bits de uma
banda de forma a minimizar a percepo auditiva do rudo de quantizao
levando em conta, como j mencionamos, o mascaramento de frequncias.
O MPEG 1 udio [ISO/IEC 11172-3, 1993] define trs mtodos de
compresso, denominados camadas 1, 2 e 3 (MP1, MP2, MP3).
O MP1 agrupa 12 amostras para cada uma das 32 sub-bandas. Cada
grupo de 12 recebe, ento, os bits para codificao e, se o nmero de bits no
for zero, um fator de escala.
O MP2 e o MP3 ainda levam em conta uma outra caracterstica
psicoacstica, o mascaramento temporal. Quando emitido um tom em uma
dada frequncia e com uma certa amplitude, esse tom mascara os tons, na
mesma frequncia, abaixo de uma certa amplitude, que varia no tempo. A
Figura A.12 ilustra o fato com um tom emitido a 60 dB.
-5 0 5 10 20 50 100 200 500
Tempo (ms)
Tom de teste
60
40
20
d
B
Tom de
mascaramento

Figura A.12 Mascaramento temporal.
O MP2 codifica os dados em grupos maiores: para cada sub-banda,
agrupa trs grupos de 12 amostras. Isso modela um pouco da mscara
temporal, pois faz-se uma alocao de bits e usam-se trs fatores de escala
para cada trio de 12 amostras.
Tanto o MP1 quanto o MP2 usam bandas uniformes, isto , do mesmo
tamanho, que no modelam bem o ouvido humano, como pode ser visto pela
425
Figura A.9. O MP3 usa bandas no-uniformes e faz uma alocao de bits
melhor. Faz tambm melhor clculo do quantum de cada banda, isto , melhor
distribuio de bits, usando inclusive o conceito de reservatrio de bits (como
mencionado, o nmero de bits total para as 32 bandas fixo para cada grupo
de amostras, mas no MP3 pode haver emprstimos de bits de um grupo de
amostras para outro).
O MP2 e o MP3 tambm permitem o MS stereo mode, alm do stereo
intensity mode. O modo MS stereo codifica os sinais de frequncias mais
altas dos canais direito e esquerdo como a soma (middle-channel) e a
diferena (side-channel). Tcnicas de sintonizao so ento utilizadas para
comprimir o sinal side-channel.
A Tabela A.3 apresenta uma comparao das vrias camadas MPEG 1
udio.
Tabela A.3 Camadas MPEG 1 udio (a codificao pode ser realizada com taxas de
amostragem de 32, 41.1 e 48 KHz)
Camadas Taxa de Bits Alvo
(Kbps)
Taxa de
Compresso
Qualidade Retardo
Mximo (ms)
MP1 32 a 448 4:1 50
MP2 32 a 384 6:1 100
MP3 32 a 320 12:1
Telefonia: 8 Kbps
Rdio AM: 32 Kbps
Rdio FM: 64 Kbps
CD: 128 Kbps
150

As camadas do padro MPEG 1 udio, denominadas fase 1 (MP1, MP2
e MP3) preveem apenas o uso de dois canais em um fluxo de udio, ou seja,
apenas o estreo tradicional. O padro MPEG 2 [ISO/IEC 13818-3, 1998]
introduz algumas extenses. O padro MPEG 2 udio (fase 2) comum,
chamado de BC (Backward Compatible), tem as mesmas camadas e usa os
mesmos algoritmos com os mesmos parmetros do udio MPEG 1. A
diferena que o MPEG 2 prev a formao de fluxos de udio com at seis
canais (5.1), em vez de implementar apenas o estreo com dois canais.
A codificao AAC (Advanced Audio Coding) novidade do udio
trazida pelo MPEG-2, conhecida como NBC (Non Backward Compatible),
de no-compatvel com MPEG 1 (tambm conhecido como MPEG-2 Parte 7
[ISO/IEC 13818-7, 1997] ou MPEG-4 Parte 3 [ISO/IEC 14496-3, 2004]).

426

Essa codificao mais eficiente que o MPEG 1 (MP3 etc.), tolera at 48
canais de udio e 15 canais de frequncias baixas, com taxas de amostragem
de 8 a 96 KHz. A AAC necessita de menos processamento e,
consequentemente, tem retardo menor na (de)codificao.
A AAC considerada o estado da arte para udio de alta qualidade em
uma taxa de bits tpica de 128 Kbps. Abaixo dessa taxa, a qualidade do udio
comea a degradar, o que pode ser compensado por tcnicas de
melhoramento, como SBR (Spectral Band Replication) e PS (Parametric
Stereo).
A SBR uma tcnica de extenso que permite a mesma qualidade de
som a aproximadamente metade da taxa de bits. A combinao de AAC e
SBR chamada de HE-AAC (High efficiency-AAC) verso 1 [ISO/IEC
14496-3, 2004], tambm conhecida como aacPlus v1.
A PS aumenta a eficincia de codificao ainda mais, atravs de uma
representao paramtrica da imagem estreo de um sinal de entrada. A
combinao de AAC, SBR e PS chamada de HE-AAC (High efficiency-
AAC) verso 2 [ISO/IEC 14496-3, 2004].
Note assim que HE-AAC, definido no padro MPEG-4, um
superconjunto do ncleo AAC, que estende a alta qualidade de udio AAC
para taxas de bits mais baixas. Decodificadores HE-AAC v2 so capazes de
decodificar fluxos HE-AAC v1 e fluxos AAC. Por sua vez, decodificadores
HE-AAC v1 so tambm capazes de decodificar fluxos AAC. Como vimos
no Captulo 1, o sistema brasileiro de TV digital terrestre adotou o padro
MPEG-4 para a codificao do udio principal de um programa [ABNT
NBR 15602-2 ,2007], com as caractersticas apresentadas na Tabela 1.1.
Alm das codificaes apresentadas, ainda existem vrias outras em uso
atualmente. Entre elas podemos citar a DD e a DTS.
AC-3 era o antigo nome da codificao chamada hoje de Dolby Digital
(DD). Essa codificao propriedade da empresa Dolby, mas foi adotada
pelos Estados Unidos como codificao de udio a ser utilizada nos DVDs e
em HDTV (High Definition TV). Ela utiliza seis canais de udio, sendo cinco
com qualidade de CD (20 Hz a 20 KHz) e um apenas para as baixas
frequncias (20 a 120 Hz). A taxa dessa codificao de cerca de 384 Kbps.
A Figura A.13 apresenta a distribuio sugerida de autofalantes para os seis
canais de udio.
427
Surround
Esquerdo
Principal
Direito
Principal
Esquerdo
Subwoofer
Central
Surround
Direito

Figura A.13 udio multicanal.
A Europa usa ainda uma outra codificao proprietria, a DTS. Essa
codificao tambm multicanal, mas a taxa gerada de cerca de 1,536
Mbps. Tanto DD quanto DTS trabalham com codificao por sub-bandas
(at 576 na DD). Testes exaustivos com especialistas em udio no
conseguem chegar a uma definio sobre qual codificao a melhor. No
entanto, trilhas DD obviamente ocupam menos espao de armazenamento (e
de banda, quando transmitidas) e, por isso, a codificao DD tem sido
preferida pelos fabricantes de DVD.
A.3.8 Compresso em Vdeo
Como vimos na Seo A.2, o sinal de vdeo pode ser codificado usando
qualquer uma das tcnicas l mencionadas: PCM, DPCM, ADPCM, SBC
etc. Tambm conforme vimos na Seo A.3.6, um vdeo pode ser considerado
como uma sequncia de imagens estticas ou quadros. Cada um desses
quadros pode ser codificado usando as mesmas tcnicas empregadas para as
imagens estticas. Em particular, poderamos empregar a codificao JPEG
em cada quadro. Essa tcnica constitui a base da codificao chamada
MJPEG (Motion JPEG). Entretanto, ao empregarmos essa codificao,
estaremos levando em conta apenas a redundncia de informao contida em
428
um quadro (redundncia intraquadro), quando a maior redundncia pode
estar nas informaes contidas em quadros consecutivos (redundncia
interquadros).
Nesta seo nos deteremos na anlise de dois padres de codificao de
vdeo que levam em conta no apenas a redundncia intraquadro, mas
tambm a existente interquadros: os padres H.261 e MPEG vdeo. Antes,
porm, vamos analisar alguns padres de sinal de vdeo.
Sinais de TV so, em geral, adquiridos no formato RGB, mas
transmitidos no formato YC
r
C
b
, no qual a resoluo geomtrica dos canais de
crominncia menor que a de luminncia, levando em conta a maior
sensibilidade do olho humano luminncia, como discutimos na Seo A.3.6.
Os sinais so ento multiplexados e modulados, gerando um sinal chamado
vdeo composto modulado, conforme ilustrado na Figura A.14.
R
G
B
Cmera
Componentes de
vdeo (BNC)
S-VHS (mini DIN)
Y
Cr
Cb
Vdeo Composto
(RCA)
VC
VCM
Vdeo Composto
Modulado
Subamostragem
na crominncia
Somador
Subtrator
Multiplexador
Modulador

Figura A.14 Gerao de sinal de vdeo de TV.
Sistemas de vdeo apresentam informaes como uma sequncia de
quadros, sendo cada quadro composto de linhas. Um dos sistemas de
distribuio de televiso mais utilizados usa 525 linhas por quadro, a uma
taxa de 30 quadros por segundo ( o padro M de TV, utilizado tanto pelo
padro americano NTSC quanto pelo padro brasileiro PAL-M).
7
As
televises tm uma relao de aspecto de 4:3, dando ao padro M uma
resoluo para a luminncia de 700 525 pixels por quadro.
Nem todas as linhas da televiso so visveis. A maioria dos formatos de
vdeo digital est relacionada com a rea visvel para cada padro de

7
Na verdade, a taxa de quadros de 29,97 quadros por segundo para TV em cores. Os padres
europeus, em geral, usam 25 quadrospor segundo e 625 linhas por quadro.
429
televiso. A recomendao BT 601-4 [ITU-R BT.601-4, 1994] especifica 483
linhas ativas, com 720 pixels por linha. Apenas 480 das 483 linhas e 704 dos
720 pixels (os primeiros e ltimos 8 pixels so descartados) so usados para
codificao. O padro especifica a subamostragem de crominncia 4:2:2,
conforme dado pela Figura A.15, indicando que, para cada dois valores de
luminncia na horizontal, apenas um de cada crominncia deve ser gerado.
Isso implica uma taxa gerada de:
704 480 29,97 16 = 162 Mbps
A Figura A.15 apresenta tambm outras subamostragens de
crominncia utilizadas em outros padres de codificao, como veremos.
4:2:0 4:4:4 4:2:2 4:1:1
1 pixel de luminncia 1 pixel de crominncia Cr e 1 pixel de crominncia Cb

Figura A.15 Subamostragem de crominncia MPEG 2.
O padro H.261 do ITU-T, discutido mais adiante, usa os formatos CIF
(Common Interchange Format), com 288 linhas e 352 pixels por linha, e
QCIF (Quarter CIF), com 144 linhas e 176 pixels por linha, para a
luminncia. Sua extenso, H.263, acrescenta trs novos formatos: o sub-
QCIF (128 96), o 4CIF (704 576), tambm conhecido como SCIF, e o
16CIF (1408 1152). Todos os formatos citados possuem subamostragem de
crominncia (relao de aspecto) 4:2:0, conforme ilustrado na Figura A.15.
O padro MPEG 1 vdeo pode codificar imagens de at 4.096 linhas
4.096 pixels 60 quadros por segundo. No entanto, a maioria das aplicaes
usa o formato SIF, com 240 linhas, 352 pixels por linha e subamostragem de
crominncia 4:2:0.
O padro MPEG 2 pode codificar imagens de at 16.383 linhas
16.383 pixels. O padro organizado tal qual o padro MPEG-4, como
veremos, em diversos perfis e nveis, que especificam o formato utilizado.
Exemplos de formato so: nvel baixo (240 linhas 352 pixels por linha 30
quadros por segundo idntico ao SIF MPEG 1), nvel principal, visando
codificao com qualidade de TV (720 480 30), e os nveis altos, visando
TV de alta resoluo HDTV e produo de filmes (em geral, 1280
430
720 30; 1920 1080 30 ou 1440 1152 30). O padro permite
subamostragem de crominncia 4:2:0, 4:2:2 e 4:4:4.
Note que vrios formatos so menores que os tamanhos de TV atuais.
Note tambm que as imagens de TV so significativamente menores do que as
telas atuais das estaes de trabalho. Quase todos os formatos de vdeo digital
apresentam a imagem em uma rea menor do que a tela da estao. Alguns
padres, no entanto, chegam a resolues suficientes para atender qualidade
das TVs de alta resoluo, a HDTV.
H.261
H.261 [ITU-T H.261, 1993] o padro de compresso mais usado em
sistemas de videoconferncia. Seu objetivo inicial foram as aplicaes para
redes comutadas por circuito, mais especificamente RDSI-FE (Redes Digitais
de Servios Integrados de Faixa Estreita). Da decorre sua gerao de trfego
CBR (Constant Bit Rate, isto , taxa constante) nas taxas de p 64 Kbps, p
variando de 1 a 30.
H.261 divide cada quadro (QCIF ou CIF) em macroblocos de 16 16
pixels, gerando seis blocos de 8 8 pixels (4 de luminncia e 2 de
crominncia), conforme ilustra a Figura A.16.
(a) Blocos
Pixels
(b) Macroblocos
Y
Cb Cr

Figura A.16 Blocos H.261.
O padro define dois tipos de codificao. Na codificao intraquadro, o
macrobloco codificado levando em conta apenas a redundncia espacial do
bloco. Cada bloco passa por um processo muito parecido com o descrito no
431
JPEG modo sequencial, gerando os blocos codificados. Na codificao
preditiva, realizada uma pesquisa no quadro anterior procura de um
macrobloco, o mais parecido possvel com o macrobloco que se quer codificar
(a pesquisa realizada apenas na componente de luminncia e apenas em uma
regio que circunda o macrobloco). O erro de predio (diferena entre os
macroblocos) ento enviado para codificao, sofrendo o mesmo processo
descrito para a codificao intraquadro. No caso da codificao preditiva,
deve tambm ser codificado o vetor (chamado de vetor de deslocamento), que
especifica o deslocamento entre o macrobloco corrente e o macrobloco do
quadro anterior usado para a predio.
Todo macrobloco sofre uma codificao intraquadro e preditiva. A que
gera a maior compresso escolhida. Uma vez codificados, os quadros so
enviados a um buffer que vai regular o fluxo de informao para uma taxa de
bits constante. Lembre-se de que o H.261 foi pensado para uma rede
comutada por circuitos. Como a taxa de entrada no buffer VBR (Variable
Bit Rate, isto , taxa varivel), se no fosse tomada nenhuma providncia
poderia ocorrer estouro de buffer ou falta de bits codificados. Para que isso
no acontea, o tamanho do passo do quantizador (o quantum), dos
coeficientes gerados a partir da transformada de cossenos, ajustado, quando
necessrio, conforme a quantidade de dados no buffer, para se chegar taxa
CBR desejada de sada.
O ajuste no passo do quantizador afeta a qualidade do vdeo gerado,
privilegiando os vdeos com poucas mudanas de cena. Pouca mudana de
cena implica maior compresso, isto , menos bits gerados na codificao que
entra no buffer, o que faz o processo de realimentao diminuir o quantum
para aumentar a quantidade de bits gerados. Como consequncia da
diminuio do quantum, tem-se uma imagem de melhor qualidade. Como em
aplicaes de videoconferncia e videotelefonia no existem, em geral, muitas
mudanas de cenas, o padro bem apropriado para elas.
O padro H.263 [ITU-T H.263, 2005] estende o padro H.261,
introduzindo novos formatos de quadros, como discutimos anteriormente,
otimizando o H.261 para codificao de vdeo a taxas inferiores a 64 Kbps e
adicionando facilidades para maior qualidade e melhores servios. Contudo,
as idias bsicas de compresso so as mesmas.
MPEG-1 e MPEG-2 Vdeo
Idnticos ao H.261, os padres MPEG-1 e MPEG-2 vdeo [ISO/IEC
11172-2, 1993 e ISO/IEC 13818-2, 2000] dividem um quadro em
macroblocos, como apresentado na Figura A.16, vlido tambm para o
MPEG com amostragem de crominncia 4:2:0.
432
Cada bloco pode ser codificado usando apenas a informao
intraquadro, de forma idntica ao que foi apresentado para o JPEG. Quadros
em que todos os blocos so codificados dessa forma so denominados
quadros I.
Um macrobloco pode tambm ser codificado de forma preditiva,
semelhante ao H.261. No entanto, a predio MPEG-1 mais rica, uma vez
que pode ser feita baseada em quadros passados e em quadros futuros da
sequncia de um vdeo. Quando a predio feita baseada em um quadro
passado, tal qual o H.261, codificado o erro de predio (diferena do
passado), usando os mesmos procedimentos usados para os macroblocos
intraquadros e o vetor de movimento (que d a posio relativa do
passado). Quadros codificados usando esse tipo de predio so chamados
quadros P. A predio sempre baseada no primeiro quadro do tipo I ou P
anterior.
A estimao do movimento (estimao do macrobloco mais prximo
daquele que se quer codificar) se d dentro de uma regio do quadro de
referncia, conforme ilustra a Figura A.17. Para TV, por exemplo, obtm-se
bom desempenho com p = 15 pixels em cenas comuns de noticirio e p = 63
em cenas de muito movimento, como por exemplo, cenas de esporte.

Figura A.17 Estimao de movimento.
433
Macroblocos tambm podem ser codificados com base no primeiro
quadro I ou P, posterior ou anterior. Nesse caso, teremos dois quadros de
referncia para a procura do melhor casamento. A codificao pode ser
realizada com base no quadro anterior no quadro posterior, ou na
interpolao do quadro anterior e posterior. Quadros codificados usando esse
tipo de predio so chamados quadros B.
Quadros B apresentam como vantagem o fato de, normalmente,
apresentarem uma compresso maior que os quadros I e P (Tabela A.4). So
tambm quadros que, se perdidos, no afetam tanto a qualidade da imagem,
pois o erro cometido no se propagar, uma vez que esses quadros no so
usados como referncia de predio (note que a perda de um quadro I ou P
implica a perda de todos os quadros at o prximo quadro I). No entanto,
quadros B introduzem um retardo extra no processo de codificao porque
devem ser codificados fora da sequncia, alm de exigirem mais
processamento para codificao.
Tabela A.4 Tamanhos tpicos de quadros MPEG 1
Tipo de Quadro Tamanho (Kbytes) Compresso
I 18 2:1
P 6 7:1
B 2,5 50:1
Mdia 4,8 27:1

Ao contrrio do H.261, que escolhe sempre a melhor codificao para o
macrobloco, no MPEG o padro de codificao de quadros um parmetro
da escolha do usurio, isto , o usurio escolhe qual a sequncia de quadros I,
P ou B a ser utilizada. Note que essa escolha vai depender das aplicaes. Por
exemplo, como veremos na Seo A.4.3, o retardo de transferncia pode ser
crtico em aplicaes em que h interatividade em tempo real entre os
participantes, como em um sistema de videoconferncia. Nesse caso, o
nmero de quadros B em sequncia no pode ser muito grande, devido ao
retardo que isso introduz.
O padro MPEG-1 trabalha, em geral, com o formato SIF, embora
maior resoluo tambm seja permitida por sua sintaxe. O padro MPEG-2,
como j mencionado, admite vrios formatos de quadros e diferentes
resolues para as componentes de crominncia. De fato, o MPEG-2
especifica vrios conjuntos de parmetros de restrio, que so definidos nos
434
seus perfis e nveis. Um perfil especifica as facilidades de codificao que
sero utilizadas. Um nvel especifica a resoluo dos quadros, as taxas de bits
etc. Vrias combinaes de perfis e nveis foram definidas, como veremos
mais adiante. O MPEG-2 usa os mesmos tipos de quadro I, P e B, como o
MPEG-1, mas introduz outros mtodos de predio [Netravali et al., 1995]
para lidar com vdeo entrelaado.
8

O MPEG-2 tambm apresenta vrias extenses de escalabilidade
[ISO/IEC 13818-2, 2000]. As extenses proveem, basicamente, duas ou mais
sequncias de bits, ou camadas, que podem ser combinadas para prover um
nico sinal de vdeo de alta qualidade. A camada-base pode, por definio,
ser totalmente decodificada por si mesma, de forma a prover um vdeo de
baixa qualidade. Como veremos a seguir, muitas das tcnicas empregadas so
semelhantes s codificaes progressivas e hierrquica do JPEG.
Com a escalabilidade SNR (Signal to Noise Ratio), outra camada pode
ser adicionada camada-base, oferecendo melhoria na preciso dos
coeficientes da DCT (Discrete Cosine Transform), adicionando valores de
correo para serem utilizados antes da decodificao (aplicao da DCT
inversa). Essa extenso tambm prov a codificao do vdeo na resoluo
4:2:2, tendo por camada-base o vdeo na resoluo 4:2:0.
Escalabilidade por partio de dados uma verso simplificada da
escalabilidade SNR. Com essa extenso, at um certo nmero de coeficientes
de frequncias DCT enviado pela camada-base. Os coeficientes restantes
so enviados por outra camada a ser adicionada bsica.
Na escalabilidade espacial, a camada-base tem uma resoluo espacial
(resoluo geomtrica de cada imagem) menor do que a do vdeo original. A
camada de melhoramento ento acrescida camada-base para se obter a
resoluo original.
Na escalabilidade temporal, a camada-base tem uma resoluo
temporal (nmero de quadros por segundo) menor do que a do vdeo original.
Novamente, a camada de melhoramento adicionada camada-base para a
obteno da resoluo original.
Escalabilidade especialmente til em redes que permitem distinguir os
tipos de fluxos e privilegiar a entrega do mais importante. Assim, em caso de
necessidade ou convenincia de perda, um sinal de vdeo com um mnimo de
qualidade ainda poder ser recebido.

8
Vdeo entrelaado tipicamente usado em TV, onde so primeiro varridas as linhas mpares e
depois as pares. Aos conjuntos de linhas mpares e pares chamamos campos. Assim, um quadro composto
de dois campos.
435
No MPEG-2, o perfil principal (main profile) utiliza os quadros I, P e B
e uma amostragem de cor 4:2:0. O perfil simples (simple profile)
basicamente o perfil principal sem os quadros B. O perfil escalvel SNR
(SNR Profile) adiciona a escalabilidade SNR ao perfil principal. O perfil
escalvel espacialmente (spatially scalable profile) adiciona a escalabilidade
espacial ao perfil escalvel SNR. O perfil alto adiciona cor 4:2:2 ao perfil
escalvel espacialmente. Todos os perfis so limitados ao mximo de trs
camadas. O nvel principal (main level), como mencionado no incio desta
seo, est definido basicamente para o vdeo ITU-R Rec. 601. O nvel
simples (simple level) definido para vdeo SIF. Os dois nveis altos para
HDTV so o nvel alto 1440 (high-1440 level), com um mximo de 1.440
pixels por linha, e o nvel alto (high level) com no mximo 1.920 pixels por
linha. Nem todas as combinaes de perfis e nveis foram padronizadas. No
futuro, quando necessrio, perfis e nveis podero ser adicionados ao padro.
MPEG-4 Vdeo
O MPEG 4 (ISO/IEC 14496) foi finalizado em outubro de 1998 e
tornou-se um padro internacional nos primeiros meses de 1999. No final de
1999 foram acrescentadas novas extenses (MPEG-4 verso 2), tornando-se
um padro internacional formal no comeo de 2000.
O padro em sua forma atual dividido em vrias partes, entre elas:
- Parte 1 Sistema
- Parte 2 Vdeo
- Parte 3 udio
- Parte 10 Codificao Avanada de Vdeo
Das diversas partes, em termos de codificao de vdeo, interessa-nos
especialmente a Parte 10, por incorporar todas as melhorias trazidas pelo
MPEG-4 com relao ao padro MPEG-2.
Em 2001, o grupo de trabalho da especificao MPEG da ISO
reconheceu o potencial dos trabalhos desenvolvidos pelo grupo H.26L
(VCEG Video Coding Expert Group) do ITU-T, como evoluo dos
trabalhos do H.263, e a partir de ento os trabalhos dos dois grupos se
fundiram (JVT Joint Video Team) para a definio de um novo padro de
codificao de vdeo. O resultado foram dois padres idnticos: ISO MPEG-4
Parte 10 [ISO/IEC 14496-10, 2005] e ITU-T H.264, oficialmente conhecidos
como AVC (Advanced Video Coding), publicado pela primeira vez em 2003.

436
Como o MPEG-2, o padro dividido em perfis. O perfil baseline visa
a fluxos de vdeo simples (de baixa resoluo); por exemplo, para
videotelefonia; o perfil principal visa qualidade de TV de definio padro;
o perfil alto (perfil estendido) visa a fluxos de vdeo de alta definio. Esse
ltimo perfil subdividido em quatro perfis: o perfil alto (para o suporte a
vdeo de 8 bits por amostra com subamostragem de crominncia 4:2:0); o
perfil alto 10 (para o suporte a vdeo de at 10 bits por amostra com
subamostragem de crominncia 4:2:0); o perfil alto 4:2:2 (para o suporte a
vdeo de at 10 bits por amostra com subamostragem de crominncia 4:2:2) e
o perfil alto 4:4:4 (para o suporte a vdeo de at 12 bits por amostra com
subamostragem de crominncia 4:4:4 e transformada de cor residual inteira
para codificao de sinal RGB).
Os elementos funcionais bsicos (predio, transformada, quantizao,
codificao por entropia) do AVC tm poucas diferenas com relao aos
padres anteriores (MPEG-1, MPEG-2, MPEG-4 Parte 2, H.261, H.263). As
mudanas importantes ocorrem em detalhes de cada um dos elementos.
O processo de codificao processa quadros de vdeo em unidades de
macroblocos (1616 pixels). Ele forma a predio do macrobloco baseada em
dados j previamente codificados, ou do quadro corrente (predio intra) ou
de quadros j codificados e transmitidos (predio inter).
O mtodo de predio AVC mais flexvel do que os dos padres por
ns anteriormente discutidos, permitindo uma predio mais precisa e, assim,
uma melhor compresso. Os blocos de predio so de tamanhos variveis. A
predio intra pode usar blocos de tamanho 1616 ou 44. A predio inter
pode usar blocos 1616, 168, 816, 88, 84, 48 ou 44.
Diferentemente do MPEG-1, do MPEG-2 e do MPEG-4 Parte 2, a
predio de cada macrobloco pode ser baseada em um ou dois quadros
quaisquers, passados ou futuros, que j foram codificados. Essa possibilidade
extremamente importante quando o movimento na cena peridico.
Um bloco, obtido aps a predio, transformado usando uma
transformada inteira 44 ou 88 (a transformada inteira uma forma
aproximada da transformada discreta de cosseno).
Os valores e parmetros resultantes (elementos sintticos) so
convertidos em cdigo binrio usando codificao por carreia e/ou
codificao aritmtica, tambm com algumas melhoras incorporadas.
A Figura A.18 ilustra o processo de codificao, e a Figura A.19, o
processo de decodificao .
437
Reordena
Codifica
por
entropia
T Q Fn (atual)
Fn-1
(referncia)
MC
ME
Escolhe
predio
Intra
Predio
Intra
Fn
(reconstrudo)
T
-1
Q
-1
Dn X
NAL
Inter
Intra
uFn
Dn
(1 ou 2 quadros
previamente
codificados)
+
+
+
P
Filtro

Figura A.18 Processo de codificao AVC.
Reordena
Decodifica
por
entropia
T
-1
Q
-1 Fn
(reconstrudo)
Fn-1
(referncia)
MC
Predio
Intra
Dn X
NAL
Inter
Intra
(1 ou 2 quadros
previamente
codificados)
+
P
+
Filtro
uFn

Figura A.19 Processo de decodificao AVC.
A.3.9 Multiplexao e Sincronizao
Tanto o H.261 quanto o MPEG padronizam a forma como informaes
audiovisuais devem ser multiplexadas (unidas em um nico fluxo). No caso
do MPEG, a padronizao MPEG System [ISO/IEC 11172-1, 1993 e
ISO/IEC 13818-1, 2000] responsvel por essa especificao, como
mencionamos no Captulo 1. Ambos os padres adicionam aos fluxos
elementares de udio e vdeo informaes para suas exibies sincronizadas.
A sincronizao realizada pela adio de selos de tempo (timestamps) a
conjuntos de amostras codificadas de vdeo e udio, baseadas em um relgio
compartilhado. A Figura A.20 ilustra o procedimento.
438
Fonte de
udio
Codificador
de udio
Fonte de
vdeo
Codificador
de vdeo
Codificador e
Multiplexador
Relgio do sistema
Fluxo

Figura A.20 Multiplexao e sincronizao dos fluxos de udio e vdeo.
Um fluxo MPEG-1 organizado em duas camadas: a camada pack e a
camada packet. A camada pack contm informaes utilizadas por todos os
fluxos elementares, e a camada packet, as informaes particulares a cada
fluxo. Um fluxo MPEG consiste em um ou mais packs. O cabealho pack
contm informaes de temporizao do sistema e sobre as taxas de dados. O
cabealho packet contm a identificao do fluxo elementar, os requisitos de
armazenamento e informaes de temporizao. Os dados packet contm um
nmero de bytes varivel de um mesmo fluxo elementar. Assim, depois de
remover o cabealho packet, os dados packet de todos os packets com o
mesmo identificador so concatenados para a recuperao de um fluxo
elementar. At 32 fluxos de udio e 16 fluxos de vdeo podem ser
multiplexados em um fluxo MPEG-1. A Figura A.21 apresenta a estrutura de
camadas MPEG-1 System [ISO/IEC 11172-1, 1993].

Figura A.21 Camadas MPEG-1 System.
439
A funo do MPEG-2 System [ISO/IEC 13818-1, 2000] idntica do
MPEG-1. Contudo, o MPEG-2 System especifica dois formatos de dados: o
fluxo de programa (program stream) e o fluxo de transporte (transport
stream) (Figura A.22), conforme j mencionamos no Captulo 1. O fluxo de
programa similar e compatvel com o fluxo MPEG-1 System. Ele foi
otimizado para aplicaes multimdia e para ser processado por software.
O fluxo de transporte pode transportar mltiplos programas
simultaneamente e otimizado para aplicaes nas quais a perda de dados
comum. O fluxo de transporte consiste em pacotes de tamanho fixo (188
bytes, incluindo 4 bytes de cabealho).
Codificador
de vdeo
Empacotador
Codificador
de udio
Empacotador
Program stream
Dados de
vdeo
Dados de
udio
Mux PS
Mux TS
Transport stream
Abrangncia da Especificao System
Vdeo
PES
udio
PES

Figura A.22 MPEG-2 System.
Similar ao MPEG-1 e MPEG-2, o MPEG-4 System [ISO/IEC 14496-1,
2001] desenvolvido para fornecer multiplexao de fluxos de dados
elementares, sincronizao e empacotamento. Adicionalmente, o MPEG 4
System fornece parmetros de representao/manipulao bsicos
(translao, rotao e zoom) no cabealho da camada de fluxo de dados de
cada objeto.
Diferentemente da codificao linear de udio e vdeo do MPEG-1 e
MPEG-2, a codificao MPEG 4 , no entanto, baseada em objetos, isto , as
cenas audiovisuais so codificadas em termos de objetos. Um objeto pode ser
uma imagem, um vdeo ou um udio.
Objetos codificados separadamente fornecem trs benefcios:
reusabilidade a abordagem orientada a objeto permite aos autores
reusarem material audiovisual mais rapidamente; escalabilidade objetos
podem ser codificados usando diferentes resolues espaciais e temporais (a
resoluo do objeto pode ser ajustada para casar com a capacidade do meio
de transporte); interatividade porque os objetos audiovisuais so
compostos em quadros no decodificador, o usurio pode controlar a sada.
440
O MPEG-4 considera uma cena como sendo composta de objetos de
vdeo (Video Objects) VOs. Os VOs tm propriedades como forma,
movimento, textura etc. Eles vo constituir as entidades no fluxo de bits que o
usurio pode manipular e ter acesso. Um plano de objetos de vdeo (Video
Object Plane VOP) uma ocorrncia de um VO em dado instante de
tempo. Cada quadro consiste em vrios VOPs. Uma cena que contm somente
um VOP pode corresponder aos padres correntes, tais como MPEG-1,
MPEG-2 e MPEG-4. Cada VOP tem sua prpria resoluo espacial e
temporal.
Uma cena dividida em objetos, como mencionado, possui uma
organizao hierrquica. Uma informao adicional enviada com os VOPs a
fim de informar ao receptor como compor a cena. A descrio de cada cena
baseia-se em conceitos da Virtual Reality Modeling Language (VRML
linguagem de modelagem de realidade virtual). Contudo, o padro MPEG 4
introduziu novos conceitos de modelagem e otimizou os j existentes, dando
origem a uma linguagem diferente e mais poderosa: Binary Format for
Scenes (BIFS).
Note que, ao dividir uma cena em objetos e relacion-los utilizando uma
linguagem de descrio de cenas, o padro MPEG-4 est de fato tentando
padronizar uma linguagem que pode ser usada na descrio de
relacionamentos para a transmisso de dados assncronos, conforme
discutimos na Seo 1.2.3.1 do Captulo 1. Naquele captulo comentamos que
o padro MPEG-2 System, utilizado em todos os principais sistemas de
televiso digital terrestre, especificava os vrios tipos de servio, mas no
especificava a linguagem usada para sincronizao no servio assncrono. O
padro MPEG-4 vai um passo adiante na especificao do BIFS. Mais
recentemente discute-se dentro do MPEG-4 a adoo de uma linguagem mais
eficiente e de mais alto nvel (MPEG-4 Parte 20) dentro da representao
denominada LASeR (Lightweight Application Scene Representation)
[ISO/IEC 14496-20, 2006].
A.4 Requisitos de Comunicao das Diversas
Mdias
As caractersticas e requisitos de comunicao exigidos pelos diversos
tipos de mdia so muito diferentes. Vrias caractersticas devem ser
consideradas ao classificarmos fontes de trfego. A natureza do trfego
gerado uma de suas caractersticas mais importantes, dando origem a trs
classes bsicas: a classe de trfego contnuo com taxa constante (Constant Bit
Rate CBR), a classe de trfego em rajadas (bursty) e a classe de trfego
contnuo com taxa varivel (Variable Bit Rate VBR).
441
Na classe de trfego contnuo com taxa constante,
9
o trfego, como o
prprio nome diz, constante e, por conseguinte, sua taxa mdia igual sua
taxa de pico. Essa taxa o nico parmetro necessrio para caracterizar tal
fonte.
As fontes cujo trfego gerado tem caracterstica de rajadas apresentam
perodos ativos (durante os quais h gerao de informao pela fonte, que
opera na sua taxa de pico) intercalados por perodos de inatividade (durante
os quais a fonte no produz trfego algum). Para caracterizar uma fonte com
trfego em rajadas no suficiente utilizarmos a taxa mdia de gerao de
informao, j que essa taxa no representa corretamente o seu
comportamento. A taxa mdia nem sequer representa uma taxa na qual a
fonte opera em algum momento. Muito mais significativas so informaes
sobre a distribuio das rajadas ao longo do tempo, a durao das rajadas e a
taxa de pico atingida durante as rajadas. Alguns parmetros comumente
utilizados para caracterizao desse tipo de trfego incluem a durao mdia
dos perodos de atividade e a explosividade (burstiness) da fonte a razo
entre a taxa de pico e a taxa mdia de utilizao do canal.
10

Por fim, as fontes de trfego contnuo com taxa varivel apresentam
variaes na taxa de transmisso ao longo do tempo. Parmetros como a
mdia e a varincia da taxa de transmisso podem ser utilizados para
caracterizar o comportamento de fontes com essa caracterstica. O parmetro
de explosividade (burstiness) tambm bastante utilizado na caracterizao
dessas fontes.
Requisitos sobre a qualidade do servio de comunicao desejado
(QoS), tais como retardo mximo de transferncia, variao estatstica do
retardo (jitter), vazo mdia, taxas aceitveis de erro de bit e de pacote de
dados, variam muito de uma mdia para outra e so dependentes da aplicao.
De forma geral, podemos caracterizar as diversas mdias, quanto aos
requisitos de comunicao exigidos, como se segue.
A.4.1 Texto
O trfego gerado por informaes em texto , em sua grande maioria, de
rajada. Para compreender essa natureza do trfego, pense na comunicao de
um terminal com um computador durante a execuo interativa de um
programa. A vazo mdia dos dados vai depender muito da aplicao,

9
Em geral, os padres de comunicao utilizam a palavra contnuo para caracterizar sem
interrupo e a taxas constantes. Note, no entanto, que temos, alm do trfego em rajadas, o trfego sem
interrupo mas com taxa varivel. Em geral, os padres chamam apenas de trfego com taxa varivel
(VBR) a ambos os trfegos (em rajadas e contnuo com taxa varivel), independentemente de serem sem
interrupo ou no.
10
Existem outras definies para a medida da explosividade da fonte: a razo entre o desvio padro e
a taxa mdia gerada, por exemplo.
442
variando desde alguns poucos bits por segundo para aplicaes de correio
eletrnico, at alguns megabits por segundo em transferncia de arquivos.
Para texto, excetuando-se algumas aplicaes em tempo real, como por
exemplo para controle de processos crticos, o retardo mximo de
transferncia e a variao estatstica do retardo no constituem problemas,
sendo seus requisitos, em geral, facilmente satisfeitos pelo sistema de
comunicao. Quanto tolerncia a erros, na grande maioria das aplicaes
no se pode tolerar erro nem em um nico bit: suponha, por exemplo, o caso
da perda de um bit numa transferncia eletrnica de fundos.
A.4.2 Imagem
O trfego gerado em aplicaes grficas animadas, onde vrios quadros
so gerados em intervalos regulares de tempo, tem caractersticas bem
semelhantes s da mdia de vdeo, comentadas mais frente. Excetuando o
caso de imagens animadas, a natureza do trfego gerado pela mdia grfica
tambm de rajadas, com vazes mdias chegando a algumas dezenas de
megabits por segundo. Como em textos, o retardo mximo e a variao
estatstica do retardo, em geral, no so relevantes.
Como discutido na Seo A.1, as imagens grficas podem estar no
formato vetorial ou matricial. Para imagens no formato matricial e sem
compresso, a taxa de erro de bit pode ser bem maior que a taxa de erro de
pacote, uma vez que, em geral, no haver nenhum problema se, por exemplo,
um nico pixel de uma tela ficar azul em vez de verde. O mesmo no se pode
dizer da perda de um pacote, que poder, por exemplo, apagar um bloco da
imagem na tela. Para imagens no formato vetorial e imagens (vetoriais ou
matriciais) em que foram utilizadas tcnicas de compresso ou compactao,
a tolerncia perda depende muito da aplicao e de seus usurios. Como
discutimos na Seo A.3.6, existem mtodos de compresso que identificam a
poro mais importante dos dados de uma imagem. Para esses dados, deve-se
evitar ao mximo as perdas. As pores menos importantes podem ser
descartadas, se necessrio (seja por erro na transmisso, por
congestionamento no sistema de comunicao ou mesmo porque o usurio
final no necessita delas para obter a informao que deseja). Um sistema de
comunicao deve poder identificar as pores que ele deve manter ntegras.
Outro caso importante, com relao s perdas, so as imagens que no so
processadas somente pelo olho humano, mas tambm pelo computador como,
por exemplo, imagens mdicas ou cartogrficas. Nesse caso, a perda de um
nico bit (seja devido comunicao ou ao mtodo de compresso) pode ser
intolervel (imagine uma doena que se quer diagnosticar atravs de uma
imagem mdica).
443
A.4.3 udio
A mdia de udio tem caractersticas bem distintas das mencionadas nos
dois pargrafos anteriores, principalmente em aplicaes de tempo real com
interatividade, como os servios conversacionais do ITU-T. Comeando pela
natureza do trfego gerado, a mdia de udio se caracteriza por gerar um
trfego contnuo com taxa constante. Mesmo quando, no sinal de voz,
realizada a compactao por deteco de silncio, por exemplo, passando a se
caracterizar como um trfego de rajada [Gruber, 1982], ele deve ser
reproduzido no destino a uma taxa constante. O trfego gerado para
comunicao dessa mdia do tipo CBR, caso no seja empregada nenhuma
tcnica de compactao ou compresso. Em caso contrrio, o trfego se
caracteriza como VBR e, s vezes, como no caso da voz com deteco de
silncio, como um trfego em rajadas.
A vazo mdia gerada pela mdia de udio depende da qualidade do
sinal, da codificao e compactao ou compresso utilizadas. Para sinais de
voz, por exemplo, j apresentamos a tcnica PCM, que gera 64 Kbps se
utilizarmos 8 bits para codificar cada amostra (tomada a cada 125 seg, isto
, 8.000 amostras por segundo). Com qualidade aproximadamente igual, a
codificao ADPCM gera 32 Kbps. Sinais de udio de alta qualidade
(qualidade de CD estreo, por exemplo) geram taxas bem superiores, como,
por exemplo, os CDs de udio, onde a taxa de 1,411 Mbps, como vimos na
Seo A.2.1.
Quanto s perdas, as taxas de erros de bits ou de pacotes podem ser
relativamente altas, devido ao alto grau de redundncia presente nos sinais de
udio. O nico requisito que os pacotes no sejam muito grandes (no caso
da voz, menores que uma slaba), o que normalmente j satisfeito para no
se perder tempo no empacotamento e, assim, no aumentar o retardo de
transferncia. Perdas da ordem de 1% da informao de voz so tolerveis
11

[Gopal, 1984; Gruber, 1985]. Uma vez que as redes de comunicao
utilizam, hoje em dia, meios fsicos de alta confiabilidade, a deteco de erros
para a voz nessas redes pode ser tranquilamente dispensada, em benefcio de
um maior desempenho. Apesar da baixa taxa de erros das redes, por exemplo
em fibra tica, nas mdias grfica e de texto a deteco de erros ainda , na
maioria das vezes, necessria, e em alguns casos at a deteco e a correo.
Um cuidado adicional deve ser tomado quando, devido s tcnicas de
compresso utilizadas no udio, um erro pode se propagar para outros bits.
Nesse caso, o erro pode ser intolervel. Ainda com respeito ao udio, pores
da informao podem ser diferenciadas quanto tolerncia s perdas. No
caso da voz, por exemplo, perdas nos intervalos de silncio so muito mais

11
Na realidade, como j comentamos, a porcentagem de perda depende do tamanho do surto de voz e
se a perda ocorre no incio ou no meio do surto.
444
tolerveis do que perdas durante os surtos de voz. Um sistema de
comunicao deve poder identificar as pores mais sensveis a perdas, caso
seja necessrio o descarte de dados.
No caso da utilizao de sistemas de comunicao que apresentam
variao estatstica do retardo (como as redes comutadas por pacotes em um
sistema de WebTV), tal variao deve ser compensada. Para entendermos
melhor o problema, analisemos a Figura A.23.
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
TEMPO
ORIGEM
TEMPO
DESTINO
Surto de Voz
Perodo de Silncio
Silncio Introduzido Silncio Eliminado

Figura A.23 Efeito da variao estatstica do retardo na comunicao de voz.
Na linha horizontal superior vemos os surtos de voz e de silncio sendo
gerados na fonte a uma taxa constante. Os surtos de voz so divididos em
pacotes, que so as unidades que transitaro no sistema de comunicao (os
surtos de silncio no so transmitidos). Uma vez que o pacote gerado, ele
imediatamente entregue para transmisso (veremos a seguir que o retardo
mximo um requisito importante). Se os pacotes sofrerem retardos
variveis, chegaro ao destino no mais preservando a continuidade,
conforme mostra a linha horizontal inferior da figura, podendo gerar
intervalos de silncio dentro de um surto de voz ou diminuir, e at mesmo
eliminar, intervalos de silncio, o que pode causar a perda da inteligibilidade
da informao no destino. Alguma forma de compensao dessa variao
estatstica do retardo deve ser realizada.
12
A estratgia utilizada pelos
algoritmos de compensao baseia-se fundamentalmente em assegurar uma

12
Note que a variao estatstica do retardo no necessariamente introduzida s pela rede de
comunicao, mas por todo o sistema. Ela introduzida desde a interao da placa de udio com o sistema
operacional da estao, passando pelos protocolos de comunicao (sistema operacional de rede), at chegar
ao sistema de transmisso. No destino, o caminho semelhante, mas em ordem inversa, tambm pode
introduzir aleatoriedade no retardo antes da reproduo. Assim, embora muitas vezes o sistema de
transmisso no introduza aleatoriedade no retardo, a compensao ainda deve ser feita.
445
reserva de pacotes antes de dar incio ao processo de reproduo,
introduzindo um retardo inicial a cada surto de voz. Aparentemente, o
problema estaria resolvido se escolhssemos o retardo inicial bem grande;
entretanto, o valor desse retardo est limitado pelo mximo retardo de
transferncia (desde a gerao at a reproduo) permitido para o sinal de
voz, sem que haja perda da interatividade da comunicao [Bastos et al.,
1992]. As referncias [Soares et al., 1991; Bastos et al.. 1992; Soares et al..
1992; Gopal. 1984; Adams et al.. 1985; Faria. 1992] discutem com algum
detalhe a anlise de desempenho de vrios algoritmos para compensao da
variao estatstica de retardo, com o objetivo de manter a continuidade em
sinais de voz. Embora apresentados para sinais de voz, os algoritmos podem
ser facilmente estendidos para qualquer sinal contnuo (com taxa constante ou
varivel).
O retardo de transferncia mximo crtico para o udio,
principalmente no caso de conversaes. Um dos motivos o problema do
eco, mas, mesmo nos casos em que o eco no causa problemas ou que
canceladores de eco sejam utilizados, o retardo de transferncia mximo pode
ser crtico. Cada interlocutor, em uma conversao, normalmente espera o fim
do discurso do outro para dar incio sua fala; se o retardo de transferncia
for muito grande, a conversao comea a sentir um efeito de ruptura,
podendo at se tornar invivel (se o leitor j utilizou a rede telefnica via
satlite, deve ter sentido esse efeito). Um retardo de transferncia maior que
200 ms j comea a incomodar os interlocutores [Bastos et al., 1992]. Os
padres de telefonia estipulam 40 ms para distncias continentais e 80 ms
para distncias intercontinentais como limites para o retardo mximo de
transferncia. bom frisarmos novamente que os problemas de retardo s so
crticos em aplicaes que exigem comunicao interativa em tempo real.
Nesse caso, como no podemos introduzir um retardo inicial muito grande
para compensarmos a variao estatstica do retardo, a compensao s
poder ser efetiva se a variao estatstica apresentada for pequena.
A.4.4 Vdeo
Tal qual a mdia de udio, a mdia de vdeo se caracteriza por gerar um
trfego contnuo com taxa constante. Da mesma forma que no udio, mesmo
quando no sinal realizada alguma tcnica de compactao ou compresso e
o trfego gerado para comunicao se caracterizar como um trfego com
taxas variveis, o sinal deve ser reproduzido no destino a uma taxa constante.
Como na mdia de udio, o retardo de transferncia mximo tem grande
importncia, e a variao estatstica do retardo deve ser compensada.
Normalmente, como o vdeo vem acompanhado de udio (sincronizado com
446
udio), uma vez obedecidos os requisitos de retardo deste, so obedecidos os
daquele.
A vazo mdia gerada por uma fonte de vdeo varia com a qualidade do
sinal e os algoritmos de codificao, compactao e compresso empregados,
conforme discutido na Seo A.3.8.
Em vdeo, a taxa de erro de bit pode ser maior que a taxa de erro de
pacote, pelos mesmos motivos explicitados para as imagens grficas no
formato matricial. No entanto, no vdeo, como a imagem no esttica e
devem ser gerados vrios quadros por segundo, a taxa de erro de pacote no
to crtica. Mesmo a taxa de erro de bit tolervel maior do que aquela para
imagens estticas [Hehmann et al., 1990]. Na verdade, a discusso sobre a
taxa de erro aceitvel no to simples. Quando utilizamos tcnicas de
compresso, um erro pode se propagar. Dessa forma, alguns quadros em que
o erro no se propaga podem tolerar erros de bits e de pacotes. Naqueles em
que o erro se propaga, s vezes at um nico erro de bit pode ser intolervel.
Tal qual nas imagens no formato matricial, quando se utilizam tcnicas de
compresso ou compactao, a tolerncia perda depende muito da aplicao
e de seus usurios. Como discutimos na Seo A.3.8, existem mtodos de
compresso que identificam a poro mais importante dos dados de um vdeo.
Para esses dados, deve-se evitar ao mximo as perdas, as pores menos
importantes podem ser descartadas, se necessrio (por erro na transmisso ou
por congestionamento no sistema de comunicao, ou mesmo porque o
usurio final no necessita delas para obter a informao que deseja). Mais
uma vez, um sistema de comunicao deve poder identificar as pores em
que deve minimizar as perdas.
Bibliografia:
Parte 1: Codificao de vdeo, Sistema Brasileiro de TV Digital
Adam, C. e Ades, S. Voice Experiments in the Universe Project.
Proceedings of International Conference on Communications, 29.4.1
29.4.9, 1985.
Bastos, T.L.P. e Soares, L.F.G. Anlise de algoritmos para reproduo em
tempo real de voz em redes de pacotes. Relatrio Tcnico IBM CCR-141,
Rio de Janeiro. Janeiro, 1992.
Cormen, T.H.; Leiserson, C.E.; Rivest, R.L.; Stein, C. Algoritmos. Traduo
da 2. ed. americana. Teoria e Prtica. 2002.
447
Faria, A.L.A. Implementao do mecanismo de controle de acesso por
deteco de silncio em um sistema de teleconferncia. Dissertao de
Mestrado, Depto. de Engenharia Eltrica, PUC-Rio. Maro, 1992.
Gruber, J.G. A Comparison of Mesure and Calculated Speech Temporal
Parameters Relevant to Speech Activity Detection. IEEE Transactions
on Communications, vol. com-30, n.4. Abril, 1982.
Gruber, J.G. Subjective Effects of Variable Delay and Speech Loss in
Dinamically Managed Voice Systems. IEEE Transactions on Com-
munications, vol. com-33. Agosto, 1985.
Gopal, P.M., Wong, J.W. e Majithia, J.C. Analysis of Playout Strategies for
Voice Transmission Using Packet Switching Techniques. Performance
Evaluation, n.4. Fevereiro, 1984.
Hehmann, D. B., M.G. Salmony, and H.J. Stuttgen. Transport services for
multimedia applications on broadband networks. Computer
Communications Vol. 13 N. 4, 1990, pp. 197-203.
Standardization/International Eletrotecnical Committee, Digital
Compression and Coding of Continuous-Tone Still Images, Part 1:
Requirements and Guidelines, ISO/IEC IS 10918-1.
Standardization/International Eletrotecnical Committee. Information
Media at up to About 1.5 Mbits/s, Part 1: Systems. ISO/IEC IS 11172-1.
Media at up to About 1.5 Mbits/s, Part 2: Video, ISO/IEC IS 11172-2.
Media at up to About 1.5 Mbits/s, Part 3: Audio, ISO/IEC 11172-3.
448
Technology Generic coding of moving pictures and associated
information, Part 2: Video, ISO/IEC 13818-2.
Technology Generic Coding of Moving Pictures and Associated Audio:
Audio. ISO/IEC JTC1/SC29/WG11 13818-3.
information, Part 7: Advanced Audio Coding (AAC), ISO/IEC 13818-7.
Standardization/International Eletrotecnical Committee. Coding of
Audio-Visual Objects, Part 1: Systems. ISO/IEC JTC1/SC29/WG11
14496-1. 2001.
Standardization/International Eletrotecnical Committee. Coding of
Audio-Visual Objects, Part 2: Visual.ISO/IEC JTC1/SC29/WG11
14496-2. 2001.
Technology Coding of Audio-Visual Objects, Part 3: Audio, ISO/IEC
14496-3.
Technology Coding of Audio-Visual Objects, Part 10: Advanced
Video, ISO/IEC 14496-10.
Technology Coding of Audio-Visual Objects, Part 20: Lightweight
Application Scene Representation (LASeR) and Simple Aggregation
Format (SAF), ISO/IEC 14496-20.
ITU-R BT.601-4 (1994). International Communication Union Encoding
Parameters of Digital Television for Studios, Recommendation BT.601-
4, BT Series Volume, Geneva.
ITU-T G.711 (1988). International Communication Union. Pulse Code
Modulation of Voice Frequencies. Recommendation G.711. Geneva.
ITU-T G.722 (1988). International Communication Union. 7 khz Audio-
Coding Within 64 kbit/s. Recommendation G.722. Geneva.
449
ITU-T G.723.1 (1996). International Communication Union. Dual Rate
Speech Coder for Multimedia Communications Transmitting at 5.3 and
6.3 kbit/s. Recommendation G.723.1. Geneva.
ITU-T G.726 (1990). ITU-T. 40, 32, 24, 16 kbit/s Adaptive Differential
Pulse Code Modulation (ADPCM). ITU-T G.726.
ITU-T G.728 (1992). International Communication Union. Coding of
Speech at 16 kbit/s Using Low-Delay Code Excited Linear Prediction.
Recommendation G.728. Geneva.
ITU-T G.729 (1996). International Communication Union. Coding of
Speech at 8kbit/s Using Conjugate-Structure Algebraic-Code-Excited
Linear-Prediction (CS-ACELP). Recommendation G.729. Geneva.
ITU-T H.261 (1993). International Communication Union. Video Codec for
Audiovisual Services at p*64 kbit/s. Recommendation H.261. Geneva.
ITU-T H.263(2005). International Communication Union. Video Coding for
Low Bit Rate Communication. Recommendation H.263. Geneva.
Netravali, A.N.; Haskell, B.G. Digital Pictures. 2. ed. Plenum Press,
1995.
Soares, L.F.G., Martins, S.L. e Bastos, T.L.P. Um algoritmo para
compensao da variao estatstica do retardo em redes comutadas por
pacotes. Anais do 8. Simpsio Brasileiro de Redes de Computadores,
1991.
Soares, L.F.G. e Bastos, T.L.P. Anlise de algoritmos para reproduo em
tempo real de voz em redes depPacotes. Anais do 10. Simpsio
Brasileiro de Redes de Computadores. Recife. 1992.
Soares, L.F.G.; Colcher, S. e Souza, G.L. Redes de computadores: das
LANs, MANs e WANs s redes ATM. Rio de Janeiro: Campus, 1995.
450
Apndice B

DSM-CC
Digital Storage Media
Command and
Control
O DSM-CC (Digital Storage Media Command and Control) tem uma
especificao extremamente complexa, e grande parte dela no est
diretamente relacionada a nenhum dos padres dos sistemas de TV digital.
Como consequncia, neste apndice ignoraremos grande parte do padro,
simplificaremos em muito a discusso de outras partes e consideraremos
apenas os casos necessrios ao entendimento de como o DSM-CC atua na
difuso de dados nos principais sistemas de TV digital.

451
B.1 Introduo
O DSM-CC [ISSO/IEC 13818-6, 1998] foi originalmente projetado
para ser implementado usando algum tipo de mecanismo RPC (Remote
Procedure Call) em outras palavras, onde os dados seriam buscados
(pulled from) de um provedor de contedos. Sistemas de difuso, como a TV
digital terrestre, so, no entanto, de natureza diferente. Neles, os dados so
enviados sem requisio (pushed to), do provedor para o cliente consumidor.
Uma outra soluo deve ento ser encontrada para o acesso aos dados.
A soluo encontrada bastante simples, mas nem um pouco eficiente.
Arquivos de dados devem ser periodicamente transmitidos pelo provedor de
contedos, devendo o cliente receptor aguardar pelo arquivo que deseja. Esse
tipo de soluo chamada de carrossel.
O DSM-CC d suporte a dois tipos de carrossel: carrossel de dados e
carrossel de objetos, assunto das Sees B.2 e B.3, respectivamente.

B.2 Carrossel de Dados
O carrossel de dados a forma mais simples de transmisso de dados
DSM-CC. Nele no existe qualquer indicao sobre em que consistem os
dados. Cabe ao receptor analisar os dados de um modo que faa sentido para
ele. As especificaes ATSC (padro americano) [ATSC A/90, 2001] e
ARIB (padro japons) [ARIB STB-B24 V 4.0, 2004] fazem uso dessa
modalidade de transmisso.
Um carrossel de dados consiste em um nmero de mdulos, em que cada
mdulo contm um item de dados como, por exemplo, um arquivo. No existe
nenhuma estruturao de mais alto nvel acima do mdulo.
Cada mdulo pode, por sua vez, ser quebrado em blocos, como mostra a
Figura B.1.

Figura B.1 Mdulo de um carrossel.
452
Elementos de um carrossel DSM-CC so inseridos em um conjunto de
mensagens DSM-CC:
- DSM-CC DownloadDataBlock message (DDB), que contm os dados dos
mdulos de um carrossel. Cada mensagem contm um bloco, todos do
mesmo tamanho, exceto o ltimo bloco de um mdulo, o que torna mais
fcil o parser de mensagens. A Figura B1 ilustra tais mensagens.
- DSM-CC download control messages, que especificam, para o receptor,
como as mensagens DSM-CC DownloadDataBlock so organizadas em
mdulos, isto , como a estrutura do mdulo.
Existe apenas um tipo de mensagem DDB. Cada mensagem contm uma
identificao do mdulo a que pertence e da verso do mdulo, alm da
numerao do bloco correspondente ao mdulo.
Como mencionamos, a estrutura de um mdulo definida em uma ou
mais mensagens de controle (download control messages), que podem ser de
vrios tipos.
Como mdulos grandes podem necessitar de mais de um bloco, e um
carrossel pode ter mais de um mdulo, necessria alguma informao
adicional para descrever como os blocos so agrupados em mdulos. Isso
feito dentro da mensagem DownloadInfoIndication (DII).
Cada DII contm uma descrio para um conjunto de mdulos e os
parmetros usados para suas transmisses. Todos os mdulos em uma DII
so ditos pertencerem ao mesmo grupo.
A DII especifica o tamanho das mensagens DownloadDataBlock usadas
na transmisso dos mdulos, o ID de cada um dos mdulos, seus tamanhos e
suas verses, assim como vrios descritores que podem dar mais informaes
de cada mdulo.
Sabendo o tamanho de cada mdulo e o tamanho de cada um de seus
blocos, um receptor pode calcular quantos blocos so necessrios para a
recepo completa. O nmero de verso permite ao receptor saber quando o
contedo de um mdulo mudou.
Mensagens DDB e DII so transportadas em sees privadas MPEG-2,
por ns apresentadas no Captulo 1. Assim, uma limitao que o MPEG
impe ao DSM-CC o tamanho mximo de suas mensagens, igual ao
tamanho mximo de uma seo, isto , 4 KBytes.
Carrossis que podem ser descritos por uma nica mensagem DII (de
valor menor que 4 KBytes) so chamados carrossis de uma camada.
Para carrossis maiores, mais de uma mensagem DII pode ser
necessria. Nesse caso, uma mensagem DownloadServerInitiate (DSI) atua
453
como uma mensagem de alto nvel para as demais mensagens DII. Ela agrupa
mensagens DII e os grupos de mdulos de cada uma delas em um
supergrupo.Carrossis em que vrias mensagens DII so reunidas em um
supergrupo so chamados de carrossis de duas camadas.
Como mencionamos, uma aplicao que se utiliza do carrossel de dados
tem de saber o formato dos dados contidos e como manipul-los. Em
estruturaes de dados mais complexas, o carrossel de dados no muito til.
Como uma estrutura de arquivos e diretrios uma forma muito importante
de organizao, o carrossel de objetos oferece uma soluo melhor para esse
caso, como discutido na prxima seo.
B.3 Carrossel de Objetos
Carrossis de objetos so construdos tendo por base o modelo de
carrossel de dados, adicionando a ele o conceito de arquivos, diretrio e
fluxos. As especificaes SBTVD-T (padro brasileiro) [ABNT NBR 15606-
3, 2007] e DVB (padro europeu) [ETSI TS 102 812 v1.2.1, 2003] fazem
uso dessa modalidade de transmisso, que tambm foi adotado pelo ACAP
[ATSC A/90, 2001].
Nos carrossis de objetos, os dados so representados por objetos
(objeto de diretrio, objeto de arquivo, objetos de fluxo, objetos de eventos de
fluxo e objeto Service Gateway), que contm atributos (nome, tipo e,
possivelmente, contedo).
Objetos de fluxo permitem a um carrossel de objeto referenciar fluxos
elementares que so parte da difuso. Pode haver um nico tap (uma nica
referncia), que se refere a um fluxo completo, ou pode haver vrios taps, que
se referem a vrios fluxos que formam um nico fluxo lgico. Por exemplo,
um programa de TV pode conter duas trilhas de udio para lnguas diferentes.
Um nico objeto de fluxo DSM-CC pode referenciar a todo o servio, mas
pode tambm haver dois objetos de fluxo, cada um referenciando o vdeo e
um dos dois fluxos de udio.
Embora a forma mais bvia de se referenciar a um fluxo seja atravs do
seu PID, isso traz duas desvantagens: PIDs s se referem a fluxos
elementares e no a programas inteiros; o PID de um fluxo pode mudar
quando ele remultiplexado, o que implicaria atualizar cada referncia feita
pelo carrossel.
Para referncias, o DSM-CC introduz outro identificador chamado
association tag (ou component tag, no SBTVD e no DVB). Ele prov uma
identificao nica de um fluxo que no afetada pela remultiplexao. O
association tag ligado a um fluxo por meio de um descritor de association
454
tag associado ao fluxo pela PMT (Programming Mapping Table). Cada
programa tem uma PMT, e cada PMT tem uma lista de fluxos de um
programa; para cada elemento da lista, vrios descritores podem ser
associados, incluindo o descritor de association tag.
Objetos de eventos de fluxo permitem a um receptor saber a respeito de
um ponto especfico de sincronizao dentro desse fluxo elementar, como
veremos na Seo B.4.
Alm dos objetos de fluxos e objetos de eventos de fluxo, cada carrossel
de objetos contm uma rvore de diretrios, que quebrada em uma srie de
mdulos, que podem conter um ou mais arquivos (objetos de arquivo) ou
diretrios (objetos de diretrios e objetos Service Gateway). Cada mdulo
pode conter vrios objetos, desde que o tamanho seja menor que 64 Kbytes.
No possvel dividir um arquivo em mais de um mdulo. Dessa forma,
arquivos com tamanho maior que 64 Kbytes devem ser transportados em um
nico mdulo. Esse o nico caso em que um mdulo pode exceder o
tamanho de 64 Kbytes. Arquivos em um mdulo podem vir de qualquer parte
da rvore de diretrios porque eles no tm necessidade de pertencer ao
mesmo diretrio.
Objetos Service Gateway representam um conceito similar a um
diretrio. A principal diferena que um objeto Service Gateway identifica o
diretrio raiz da rvore de diretrios de um carrossel de objetos. Isso significa
que existir um e apenas um objeto Service Gateway em um carrossel de
objetos.
Quando quiser ter acesso a um determinado arquivo, o receptor deve
esperar pelo mdulo que contm o arquivo, quando poder analisar os dados
recebidos e delimitar o arquivo.
Um carrossel de objetos tambm chamado de service domain. Em
sistemas de difuso, no h distino entre os dois termos.
Segundo as especificaes DSM-CC, que so compatveis com o
framework ORB (Object Request Broker) definido pelas especificaes
CORBA (Common Object Request Broker Architecture) [OMG, 2004], cada
objeto deve ser encapsulado em uma mensagem BIOP (Broadcast Inter ORB
Protocol) que transmitida em um mdulo.
Uma mensagem BIOP deve ser transmitida em um nico mdulo, mas
um mdulo pode conter mais de uma mensagem, como consequncia do que
mencionamos anteriormente sobre o encapsulamento de objetos em mdulos.
A Figura B.2 ilustra o processo de quebra dos dados em um carrossel de
objetos DSM-CC, passando pela estrutura do carrossel de dados at a
gerao final de sees privadas DSM-CC. Cada seo DSM-CC de um
455
carrossel transmitida no fluxo de transporte MPEG, como um fluxo
elementar de dados, uma aps a outra.

Figura B.2 Mdulo de um carrossel.
Um mdulo pode ser inserido mais de uma vez em um ciclo do carrossel
(isso verdade tambm para os carrossis de dados). Como usual nos
carrossis, os mdulos so transmitidos um aps o outro at que todos os
mdulos de um ciclo tenham sido transmitidos, quando todo o processo
recomea, repetidamente.
Vamos tomar como exemplo a rvore de diretrios da Figura B.3,
representando uma aplicao NCL, contendo um objeto de mdia vdeo, dois
objetos de imagem e um objeto de mdia contendo cdigo Lua. Para criar o
carrossel para difuso, vamos adicionar arquivos em mdulos. Adicionar os
dois primeiros arquivos (joo.ncl e foto.png) no mesmo mdulo (Mdulo 1)
possvel, mas no podemos adicionar o arquivo chuteira.png nesse mesmo
mdulo porque ultrapassaria o tamanho mximo de 64 Kbytes. Assim, o
arquivo chuteira.png deve ir para o Mdulo 2, no qual poderemos tambm
adicionar o arquivo contendo o cdigo Lua (gols.lua). O arquivo drible.mp4
deve ocupar um nico mdulo (Mdulo3), por ser maior que 64 Kbytes.
Vamos, ento, adicionar as informaes do diretrio imagens no Mdulo 1, as
do diretrio cdigos lua no Mdulo 2, e as informaes do diretrio raiz no
objeto Service Gateway tambm no Mdulo1.
456
Aplicacoes
joao.ncl (2 Kbytes)
imagens
foto.png (50 Kbytes)
chuteira.png (40 Kbytes)
videos
drible.mp4 (108 Kbytes)
codigos Lua
goals.lua (1 Kbyte)
NCL
LUA

Figura B.3 rvore de diretrios para um carrossel.
A diviso anterior pode no ser a melhor diviso dos arquivos em
mdulos. A diviso depende de quando os arquivos sero necessrios, os
relacionamentos entre eles etc.
Vamos agora colocar os mdulos no carrossel. Como o Mdulo 1
contm a aplicao e ela deve ser carregada antes de tudo, para diminuir o seu
retardo de acesso vamos inserir o Mdulo 1 mais de uma vez no carrossel,
como ilustra a Figura B.4.
Mdulo 1
Mdulo 2
Mdulo 1
Mdulo 3

Figura B.4 Carrossel de objetos para o exemplo da Figura B.3.
Como mencionamos, transmitir um mdulo mais de uma vez em um
carrossel diminui seu tempo de acesso, mas aumenta o tamanho do carrossel e
o tempo de acesso dos outros mdulos. Mais ainda, como a banda passante de
difuso constante (6 MHz no caso do Brasil), aumentar o tamanho do
carrossel diminuir a banda dos outros fluxos que iro no mesmo sinal TS
(Transpor Stream), incluindo o udio e o vdeo principal de um programa de
TV. Diminuir a banda desses sinais diminuir sua qualidade.
Alternativamente, poderamos ter optado por colocar o arquivo joo.ncl nos
mdulos 1 e 2, pois nada impede que um arquivo seja transmitido mais de
uma vez, em mais de um mdulo. Entretanto, os mesmos cuidados devem ser
tomados. De fato, a otimizao de um carrossel um problema extremamente
complexo. No existe maneira de saber qual o carrossel de objetos mais
eficiente para todos os casos. necessrio saber a estrutura e o projeto de
cada aplicao especfica carregada pelo carrossel e, mesmo assim, no
nada fcil chegar soluo mais eficiente.
457

Como j mencionamos, cada instncia do carrossel de objetos
representada por um Service Domain, que consiste em uma identificao
nica do carrossel de objetos. Todo Service Domain possui um objeto Service
Gateway, que contm referncias para todos os objetos dispostos na raiz do
carrossel de objetos.
O Service Gateway um objeto do carrossel de objetos cuja localizao
transmitida em uma mensagem DownloadServerInitiate (DSI), que
apresentamos na Seo B.2 (um carrossel de objetos ser sempre
transportado em um carrossel de duas camadas).
O padro DSM-CC utiliza a mesma estrutura de referncias IOR
(Interoperable Object Reference), definidas nas especificaes CORBA para
referenciar um objeto no carrossel. No contexto do protocolo carrossel de
objetos, uma IOR normalmente composta pelo identificador do carrossel,
seguido do identificador do mdulo e pelo identificador do objeto.
Vamos a um exemplo um pouco mais simples que o anterior para tornar
mais claro o processo. Considere a rvore de diretrios apresentada na Figura
B.5 e o carrossel de objetos gerado a partir dessa rvore, com o Service
Domain de valor hexadecimal 1. Nesse Service Domain, dois mdulos so
gerados e identificados com valores em hexadecimal 1 e 2. O
identificador de cada objeto apresentado atravs do campo objectKey. O
objeto que representa o Service Gateway (na Figura B.5: objeto do tipo srg)
identificado com o valor 1 e encapsulado no Mdulo 1. Como
consequncia, a IOR do objeto Service Gateway transmitida na mensagem
DownloadServerInitiate definida por 1,1,1 (Service Domain = 1, id do
mdulo = 1 e id do objeto = 1). Os objetos que representam o arquivo
weatherConditions.ncl e o diretrio images so identificados pelos
valores hexadecimais 2 e 3, respectivamente, e tambm so encapsulados
no Mdulo 1. J o objeto que representa o arquivo contendo o contedo da
imagem identificado com o valor 1, mas encapsulado no Mdulo 2.
O objeto Service Gateway possui, por sua vez, duas IORs. Para
relacionar uma IOR ao nome do objeto que a mesma referencia, bem como ao
tipo desse objeto (arquivo, diretrio etc.), as especificaes DSM-CC utilizam
o conceito de binding. Assim, no exemplo, o objeto Service Gateway possui
dois bindings para os dois objetos do Mdulo 1 que so filhos diretos da
raiz do sistema de arquivos representado pelo carrossel.
458
Service Domain = 1
moduleId = 1
objectKey = 1
objectKind = srg
2 bindings
binding #1
objectName = weatherConditions.ncl
objectType = fil
IOR = 1,1,2
binding #2
objectName = images
objectType = dir
IOR = 1,1,3
...
objectKey = 2
objectKind = fil
data
...
objectKey = 3
objectKind = dir
1 binding
binding #1
objectName = brazilianMap.png
objectType = fil
IOR = 1,2,1
moduleId = 2
objectKey = 1
objectKind = fil
data
...
objectKey = 2
objectKind = ste
eventList
eventName = nclEditingCommand
eventId = 3
...
Sistema de Arquivos
weather
images
brazilianMap.png
NCL

Figura B.5 rvore de diretrios e carrossel de objetos correspondente.
Os objetos do tipo diretrio (dir) possuem a mesma sintaxe e
semntica dos objetos do tipo Service Gateway. Os objetos do tipo arquivo
(fil) possuem como atributo, alm da identificao do seu tipo, os dados
relativos ao seu contedo.
A Figura B.5 apresenta tambm um objeto do tipo eventos de fluxo
(ste). Esse objeto utilizado para definir tipos de eventos DSM-CC
possveis de serem descritos no fluxo de transporte. Para isso, o objeto
relaciona identificadores de descritores de eventos DSM-CC a uma string (na
figura, contedo do campo eventName). Vamos nos aprofundar um pouco
mais nesse tpico na Seo B.4.
Finalmente, importante notar, no exemplo da Figura B.5, que a
identificao da raiz do sistema de arquivos (diretrio weather) perdida
quando da gerao do carrossel. A consequncia dessa perda e a soluo para
o problema so discutidos no Captulo 16.
B.4 Eventos de Fluxo
Eventos de fluxo so descritores embutidos em um fluxo elementar
DSM-CC. Esses descritores vo fornecer um modo de sincronizar eventos
com um fluxo de mdia. Assim como os objetos de fluxo, os eventos de fluxo
contm uma lista de taps que se referem a fluxos elementares.
ncl
459
Eventos de fluxo so bastante teis para especificar eventos no-
previsveis. Por exemplo, em uma partida de futebol, o momento de um gol
que se quer sincronizar com outro objeto de mdia qualquer, como um
ranking dos artilheiros do campeonato.
Do ponto de vista da especificao DSM-CC, o tratamento de eventos
de fluxo so divididos em duas partes:
1. Objetos de eventos de fluxo, transportados em carrossis DSM-CC.
2. Descritores de eventos de fluxo, transportados em sees privadas
DSM-CC.
Um descritor de evento de fluxo determina o disparo de um evento e
pode ser referido por um objeto de eventos de fluxo, que descreve em mais
alto nvel o que significa o evento. Mais de um descritor de evento de fluxo
pode ser referido por um mesmo objeto de evento de fluxo.
Um objeto de eventos de fluxo possui um identificador (eventId) que
deve ser nico dentro de um carrossel e um nome legvel para o ser humano,
por exemplo, nclEditingCommand. Uma aplicao pode se registrar para
receber eventos por esse nome legvel. Por exemplo, o Gerenciador de Base
Privada do ambiente declarativo Ginga-NCL se registra para receber eventos
nclEditingCommand que correspondem a comandos de edio de documentos
NCL, como discutido no Captulo 16. O exemplo da Figura B.5 apresenta um
desses objetos do evento (tipo ste), identificando no campo eventName a
string nclEditingCommand associada ao evento 3.
Descritores de eventos so transportados em fluxos listados na tabela
PMT com o tipo igual a 0x0C. Cada descritor de evento possui um
identificador numrico nico (que o associa ao objeto de eventos de fluxo) e
uma referncia temporal, que indica ao receptor em qual instante o evento
dever ocorrer (usualmente baseado em um fluxo denominado Normal Play
Time NPT, como discutido no Apndice E).
Como caso particular, um descritor de eventos pode informar ao sistema
receptor que o evento deve ocorrer imediatamente; esse tipo de evento
chamado de evento do it now.
O SBTVD especifica que, para a maioria dos eventos de fluxo, um
descritor de evento deve ser enviado uma vez a cada segundo, pelo menos
cinco vezes, antes do tempo de disparo do evento. Uma exceo, claro, o
evento do it now, que enviado apenas uma vez.
Descritores de evento de fluxo com valores de NPT permitem ao
receptor saber antecipadamente o momento exato de ocorrncia do evento,
permitindo maior previsibilidade, uma vez que no possvel precisar o
momento da chegada de um descritor no receptor. Eles tambm so mais
confiveis, uma vez que so enviados mais de uma vez.
460
Alm do identificador e da referncia temporal, o descritor de evento
possui tambm um campo para dados especficos das aplicaes, que pode ser
utilizado de acordo com sintaxes e semnticas a serem tratadas pelas prprias
aplicaes, como discutido na Seo 16 para os comandos de edio para o
Ginga-NCL.
Resumindo, no middleware Ginga, quando um descritor de evento de
fluxo chega em um receptor, ele deve checar se um objeto de eventos de fluxo
de mesmo eventID est presente no carrossel de objetos associado. Se no
estiver, o descritor ignorado. Se o evento do tipo do it now, o evento
disparado imediatamente. Se no for do it now, o receptor verifica se o evento
j est agendado para disparar. Se estiver, o descritor ignorado; em caso
contrrio, o evento agendado, dependendo do tempo NPT.
B.5 MPE: Multi-protocol Encapsulation
Para alguns tipos de dados, os carrossis DSM-CC podem no ser
adequados como estrutura de transmisso. Isso pode ser particularmente
verdade para dados provenientes do mundo Internet. Assim, o DSM-CC
tambm prov um meio para transporte de dados IP (em uma nica direo)
diretamente em sees privadas MPEG-2, chamadas Datagram Sections.
Essas sees suportam qualquer protocolo do nvel 3, mas o alvo , em geral,
o protocolo IP.
Cada receptor deve ter atribudo um endereo MAC de 48 bits, usado
para identific-lo como destino de um datagrama. Contudo, o DSM-CC no
especifica como um endereo MAC atribudo a um receptor.
Cada Datagram Section carrega um nico datagrama para um nico
endereo MAC (Medium Access Control), embora este possa ser um
endereo de multicast. Embora um datagrama IP possa ter tamanho maior do
que uma seo MPEG-2, isso no permitido pelo DSM-CC.
Bibliografia
transmisso para radiodifuso digital, Parte 3: Especificao de
transmisso de dados, Sistema Brasileiro de TV Digital Terrestre, NBR
15606-3.
461
ARIB STB-B24 V 4.0 (2004). Association of Radio Industries and Business,
Data Coding and Transmission Specifications for Digital Broadcasting,
ARIB Standard. Fevereiro de 2004.
ATSC A/90 (2001). Advanced Television Systems Committee,
Implementation Guidelines for ATSC Data Broadcast Standard, ATSC
Recommended Practice. Junho de 2001.
ETSI TS 102 812 v1.2.1 (2003). European Broadcasting Union, Digital
Bideo Broadcasting (DVB); Multimedia Home Platform (MHP)
Specification 1.1.1. Technical Specification.
OMG Specification (2004). Common Object Request Broker Architecture
(CORBA/IIOP).
Steven Morris (2004) Interactive TV Web. A technical (and non-technical)
guide to DSM-CC. Disponvel em
http://interactivetvweb.org/tutorial/dtv-intro/dsm-cc/index.shtml.
Acesso em 21 de maro de 2008.
Balabanian, Casey and Greene (1996). Vahe Balabanian; Liam Casey; Nancy
Greene. An Introduction to Digital Storage Media Command and
Control (DSM-CC). Nortel, 1996.

462
Apndice C

Modelo de Contextos
Aninhados
NCM 3.0 Bsico
Este apndice descreve as entidades bsicas da verso 3.0 do NCM (Nested
Context Model). O NCM um modelo conceitual centrado na representao e
tratamento de documentos hipermdia. A linguagem NCL do middleware
Ginga do sistema brasileiro de TV digital tem por base o modelo NCM.
1

1

463
C.1 Introduo
A definio de documentos hipermdia
2
no NCM [Soares et al., 2005]
baseada nos conceitos usuais de ns e elos. Ns (nodes) (ou objetos) so
fragmentos de informao, e elos (links) so usados para a definio de
relacionamentos entre os ns. No entanto, os elos no so a nica forma de
definio de relacionamentos, como ficar evidente a seguir.
O modelo distingue duas classes bsicas de ns, chamados de ns de
contedo (content nodes) (ou objetos de mdia) e ns de composio
(composite nodes), sendo estes ltimos o ponto central do modelo. A Figura
C.1 ilustra a viso geral da hierarquia de classes do modelo,
3
que ser
detalhada ao longo deste apndice, seguindo uma abordagem top-down.
GenericDescriptor
ContentNode
TextNode ImageNode AudioNode VideoNode ApplicationNode
ContextNode
linkSet
presentationCollection
CompositeNode
portList
Node
content
anchorList
descriptor
SwitchNode
ruleList
nodeDefault
defaultPresentationCollection
Link
bindSet
connector
DescriptorSwitch
ruleList
descAlternatives
defaultDescriptor
Descriptor
player
eventDescriptions
Entity
id
name
description
owner
date
extendedProperties
TimeNode
PrivateBase
linkSet
descriptorSet
Trail
currentNode
view
PublicHyperbase
descriptorSet
SettingsNode
GenericDescriptor
ContentNode
TextNode ImageNode AudioNode VideoNode ApplicationNode
ContextNode
linkSet
CompositeNode
portList
Node
content
anchorList
descriptor
SwitchNode
ruleList
nodeDefault
defaultPresentationCollection
Link
bindSet
connector
DescriptorSwitch
ruleList
descAlternatives
defaultDescriptor
Descriptor
player
eventDescriptions
Entity
id
name
description
owner
date
extendedProperties
TimeNode
PrivateBase
linkSet
descriptorSet
Trail
currentNode
view
PublicHyperbase
descriptorSet
SettingsNode

Figura C.1 Viso geral da hierarquia de classes do NCM.
4

2
Uma especifica de aplicao para TV digital um caso particular de documento hipermdia.
3
necessrio salientar que, embora seguindo uma especificao orientada a objetos, o NCM no
obriga que sua implementao seja orientada a objetos. O NCM apenas um modelo hipermdia.
4
Com o objetivo de no poluir visualmente as figuras, os mtodos das classes foram omitidos nos
diagramas.
464
C.2 Entidades e Propriedades
Toda entidade (entity) do modelo possui como atributos: um
identificador nico (ID), um nome, uma descrio, a data de criao e um
autor.
5
Alm dessa coleo bsica de atributos, uma entidade NCM mantm
uma lista de atributos estendidos, para permitir extenses que no se
restrinjam apenas a heranas de classes. No NCM, a maioria dos atributos
chamada propriedade e eles devem ser envolvidos (wrapped) por uma classe
do modelo chamada propriedade (property). Isso permite ao NCM o suporte
para manuteno, para cada propriedade da entidade (bsica ou estendida),
de informaes acerca de direitos de acesso, do ltimo usurio que modificou
o seu valor, da data dessa modificao, se a mudana deve ocasionar ou no
um versionamento da entidade etc. Em outras palavras, o NCM prev um
controle granular bastante fino quando da implementao de suporte a
controle de verses e controle de acesso das entidades, obrigando que as
propriedades mantenham outros atributos. No entanto, sistemas que no
tenham interesse em explorar todas as capacidades do modelo podem optar
por representar os campos das classes como atributos tradicionais, em vez de
utilizar o wrapper propriedade oferecido pelo modelo. Mesmo para aqueles
sistemas que implementam controles de acesso e/ou de verses, campos de
classes que no necessitem ser monitorados com tal granularidade podem ser
representados sem a utilizao dos wrappers.
Entidades do modelo devem oferecer mtodos get e set para cada
propriedade bsica (por exemplo, getId, setId, getName, setName, etc.),
6

mtodos para adicionar/remover propriedades estendidas, e dois mtodos
genricos para consultar (get) e modificar (set) valores das propriedades
estendidas.
C.3 Ns e ncoras
Um n (node) uma entidade NCM que tem como propriedades bsicas
adicionais: um contedo, um descritor genrico (propriedade opcional) e uma
lista ordenada de ncoras.
O contedo de um n composto por uma coleo de unidades de
informao. A noo exata do que constitui uma unidade de informao

5
O NCM define um tipo usurio cuja implementao fica a cargo dos sistemas hipermdia que
utilizem as classes do modelo.
6
Deste ponto em diante, ser assumido que as subclasses devero especificar mtodos do tipo get e
set para manipular cada uma de suas propriedades.
465
parte da definio do n e depende de sua especializao, conforme ser
exemplificado mais adiante.
Descritores NCM sero explicados nas Sees C.10 e C.11. A definio
de um descritor como propriedade do n opcional. Quando especificado, ele
conter informaes (proprieadades) determinando como o n deve ser
exibido no tempo e no espao.
Cada elemento da lista ordenada de ncoras chamado ncora do n,
ou simplesmente ncora. Toda ncora (anchor) uma entidade NCM, que
pode ser especializada, conforme ilustrado no diagrama de classes da Figura
C.2.
7
O modelo define dois tipos de ncora (ou interfaces). O primeiro tipo
chamado de ncora de contedo (content anchor ou area anchor), que
possui um atributo denominado regio (region). A regio da ncora define
uma coleo de unidades de informao do contedo do n. Qualquer
subconjunto de unidades de informao do contedo de um n pode definir
uma ncora. Tem-se, assim, que a definio exata da regio da ncora
dependente do tipo de contedo do n. No entanto, o modelo requer que todo
n contenha uma ncora de contedo com uma regio representando a
marcao de todo o contedo do n. Essa ncora chamada de ncora
contedo total e sua regio correspondente representada pelo smbolo . A
ncora contedo total deve sempre ser a primeira ncora na lista de ncoras
do n. ncoras sero extremamente importantes na especificao de
relacionamentos entre ns.
Interface
Anchor
Port
node
nodeIntPt
AllContentAnchor
SwitchPort
nodeList
intPointList
Entity
ContentAnchor
region
AttributeAnchor
attributeName

Figura C.2 Hierarquia de classes das interfaces de ns NCM.

7
Na verdade, ncoras NCM herdam da classe ponto de interface, que por sua vez herda da classe
entidade.
466
O segundo tipo de ncora definido no modelo a ncora de atributo
(attribute anchor). A ncora de atributo aponta para um atributo (ou
propriedade) do n. Como ser explicado na Seo C.10, durante a
apresentao de documentos NCM, ns so associados a descritores. Na
especificao das ncoras de atributo do n, os autores podem referenciar no
apenas atributos do n, mas tambm atributos definidos no descritor que
venha a ser associado ao n. Na verdade, a ncora de atributo pode identificar
qualquer atributo recursivamente contido no n, atravs de referncias
qualificadas. Como exemplo, um autor pode usar o nome qualificado
descritorSelecionado.posicaoX para criar uma ncora de atributo que aponte
para um atributo posicaoX definido em um descritor selecionado para
apresentar o n.
Alm dos j mencionados mtodos para consultar e modificar os valores
dos atributos, os ns devem oferecer mtodos para manipulao de suas listas
de ncoras (por exemplo, adicionar, remover, recuperar uma ncora,
percorrer a lista etc.).
C.4 Ns de Mdia
Um n de mdia, tambm chamado n de contedo (content node) ou
objeto de mdia, um n que representa um objeto em uma mdia qualquer.
Ns de contedo devem ser especializados em subclasses para melhor definir
a interpretao do contedo (texto, udio, imagem, vdeo, aplicao etc.).
Conforme mencionado anteriormente, a noo exata do que constitui uma
unidade de informao do contedo parte da definio da classe do n. Por
exemplo, uma unidade de informao do contedo de um n vdeo pode ser
um quadro, enquanto uma unidade de informao do contedo de um n texto
pode ser um caractere ou uma palavra. O contedo de um n de mdia pode
ser definido como uma referncia (por exemplo, um URI) para o contedo
propriamente dito ou como uma sequncia de bytes (raw data). Alm disso,
cada subclasse de n de contedo pode ser refinada. Como exemplo, ns texto
podem ser especializados em ns HTML, ns PDF etc.
Um tipo especial de n de contedo definido pelo modelo o n de
tempo (time node). Como o prprio nome sugere, esse n representa o tempo.
Esse n representa tempos absolutos (baseados, por exemplo, na hora UTC)
ou um tempo relativo (baseado em eventos, como por exemplo o incio da
apresentao de um documento). Cada instante de tempo considerado uma
unidade de informao para o seu contedo. Dessa forma, intervalos podem
ser definidos como ncoras de um n de tempo. O n de tempo vai, assim,
permitir acionar eventos (Seo C.7) baseados em instantes de tempo
especficos.
467
Outro tipo especial de n de contedo o n de ambiente (settings
node). Esse n representa todas as variveis controladas diretamente pelo
formatador (ferramenta responsvel pela apresentao de um documento
NCM). As variveis so representadas pelos atributos (propriedades) do n.
Como discutido na Seo C.8, esses atributos podem ter seus valores
modificados por aes dos elos. Como discutido nas Sees C.9 e C.11, esses
atributos podem tambm ter seus valores testados pelas regras de ns switch e
de switch de descritores, a fim de realizar a escolha entre alternativas.
C.5 Ns de Composio
Um n de composio (composite node) C, ou simplesmente
composio, um n cujo contedo uma coleo C
L
de ns (de contedo ou
de composio, recursivamente) que constituem suas unidades de informao.
Diz-se que um n N em C
L
um componente de C e que N est contido em
C. Diz-se tambm que um n A est recursivamente contido em C se e
somente se A est contido em C ou A est contido em um n recursivamente
contido em C. Devemos tambm notar que os componentes de C podem ser
ordenados (lista ordenada), o que ser til na definio de operaes de
navegao. Note tambm que um n pode estar contido mais de uma vez em
C
L
. Uma restrio importante feita, no entanto: um n no pode estar
recursivamente contido em si mesmo.
Ns de composio diferentes podem conter um mesmo n e ser
aninhados em qualquer profundidade, desde que seja obedecida a restrio de
um n no conter recursivamente a si mesmo. Para identificar atravs de que
sequncia de ns de composio aninhados uma dada instncia de um n N
est sendo observada, introduzida a noo de perspectiva de um n. A
perspectiva de um n N uma sequncia P = (N
m
,....,N
1
), com m > 1, tal que
N
1
= N, N
i+1
um n de composio, N
i
est contido em N
i+1
, para i e [1,m)
e N
m
no est contido em qualquer n. Note que pode haver vrias
perspectivas diferentes para um mesmo n N, se esse n estiver contido em
mais de uma composio. A perspectiva corrente de um n aquela
percorrida pela ltima navegao ao n (as diversas formas de navegao
sero definidas a posteriori). Dada a perspectiva P = (N
m
,....,N
1
), o n N
1

chamado n-base da perspectiva.
Ns de composio so objetos cuja semntica bem conhecida pelo
modelo. Um modelo conceitual deve representar no apenas os conceitos
estruturais dos dados, mas tambm definir operaes sobre os dados para
manipulao e atualizao das estruturas. Assim, todo n C de composio
deve possuir os seguintes mtodos:
468
- Insere n: deferido (implementao dependente da subclasse de
composio).
- Retira n: retira um n da coleo de ns da composio.
Com base nas definies de contedo de composio e regies de
ncoras de contedo (Seo C.3), conclui-se que a regio de uma ncora de
contedo de uma composio deve especificar um subconjunto dos
componentes da composio. Um subconjunto especial aquele com todos os
ns da composio (ncora contedo total [] da composio).
Alm da lista ordenada de ncoras, ns de composio tm uma outra
propriedade chamada lista ordenada de portas. Portas e ncoras possuem
propsito similar e estendem um tipo comum denominado interface. Uma
porta (port) de uma composio C uma entidade NCM que possui dois
atributos adicionais: um n N e uma interface ip, onde N deve estar
obrigatoriamente contido em C e ip deve ser uma interface definida em N, ou
seja, contido em sua lista de ncoras ou de portas.
8
Como pode ser percebido,
a porta de um n de composio permite definir mapeamentos entre a
composio e seus ns internos. Como consequncia, o n de composio
pode tornar a interface de um n constituinte visvel para referncias externas
(elos hipermdia, por exemplo). O conjunto de interfaces (ncoras ou portas)
age como uma proteo para referncias a um n, no sentido de que qualquer
entidade s pode ter acesso a segmentos do contedo ou atributos de um n se
eles estiverem disponveis na interface do n (lista de ncoras ou de portas).
Dessa forma, as interfaces podem impedir que modificaes internas em um
n se reflitam em outras entidades que o referenciam. Tome como exemplo
um n texto com uma ncora de contedo cuja regio especifique seu segundo
pargrafo. Qualquer mudana no texto (por exemplo, a eliminao do
primeiro pargrafo) deve se refletir na regio da ncora, mas no dever
afetar as demais entidades que a referenciam, assim mantendo as referncias
para a parte correta do contedo (isto , o antigo segundo pargrafo agora
posicionado como sendo o primeiro). A proteo do n atravs de interfaces
tambm trar ao modelo o conceito de composicionalidade, permitindo provas
formais de propriedades dos documentos, como a consistncia temporal.
Define-se como sequncia de mapeamentos da porta p
k
de uma
composio N
k
a sequncia de ns e interfaces (N
k
, ip
k
....,N
1
, ip
1
) com k > 1,
tal que para i e [1,k]:
i) N
i+1
um n de composio, e N
i
est contido em N
i+1
,
ii) ip
i
uma interface do n N
i
na sequncia de ns da porta, e N
i
e ip
i

so os valores dos atributos n e interface, respectivamente, da porta
ip
i+1
. Diz-se que ip
i
pertence sequncia de mapeamentos da porta p.

8
Evidentemente, ip estar contido na lista de portas de N apenas se N for uma composio.
469
Note que a definio de dois tipos de interfaces de composies (ncoras
e portas) permite dois tipos de tratamento para aes de apresentao, muitas
vezes desejvel na construo de um documento hipermdia. Um autor pode
desejar apresentar uma composio para que a estrutura da composio seja
visualizada (por exemplo, um desenho mostrando o grafo estrutural da
composio). ncoras de composies so interfaces que a princpio
expressam esse tipo de comportamento, e a regio da ncora enumerar os
componentes que devem ser desenhados. Todavia, apresentar uma
composio algumas vezes pode significar apresentar seus constituintes a
partir de um ponto de entrada, sem que a viso estrutural da composio seja
exibida. Portas servem exatamente para fornecer pontos de acesso, permitindo
que referncias externas toquem em ns contidos dentro de um n de
composio, sem se perder a propriedade de composicionalidade do modelo
(isto , pontos de entrada e sada das composies devem ser explicitamente
definidos).
Uma ao sobre um n de composio deve especificar a interface onde
se aplica. Caso no especifique, deve ser considerada como sendo aplicada em
todas as suas portas.
Subclasses de composio iro definir semnticas para colees
especficas de ns. Cinco importantes subclasses de composio definidas
pelo modelo so: n de contexto, n switch, trilha, hiperbase pblica e base
privada.
C.6 Ns de Contexto
Um n de contexto (context node), ou objeto de contexto, ou
simplesmente contexto, um n de composio tal que seu contedo contm
um conjunto de ns de contedo, ns de contexto ou ns switch.
9
Os ns de
contexto possuem como atributos adicionais um conjunto de elos e uma
coleo de apresentao.
Cada elo l contido no conjunto de elos de um n de contexto C define
um relacionamento entre ns recursivamente contidos em C
10
ou o prprio n
de contexto C. Diz-se que um elo l um componente de um n de contexto C
e que l est contido em C. Diz-se tambm que um elo l est recursivamente
contido em C se e somente se l est contido em C ou l est contido em um n
de contexto recursivamente contido em C. Elos so o assunto da Seo C.8.

9
Ns switch sero apresentados na Seo C.9. N switch uma especializao de composio e
permite definir alternativas de ns para documentos adaptativos.
10
Como ser discutido na Seo C.8, relacionamentos podem ter seus participantes definidos atravs
de mapeamentos para ns recursivamente contidos na composio C.
470

Uma coleo de apresentao contm, para cada n contido em um n
de contexto C, um grupo de descritores genricos.
11
Como mencionado na
Seo C.3, descritores renem as informaes referentes s caractersticas de
apresentao do n e sero tratados em detalhes nas Sees C.10 e C.11.
Cada grupo de descritores genricos deve necessariamente formar um
conjunto, ou seja, no pode haver repetio de descritores no grupo.
12
No caso
de o n contido em C ser um n de contexto, o grupo de descritores deve
conter no mximo um descritor genrico.
Ns de contexto vo servir, entre outras coisas, para definir uma
estrutura lgica, hierrquica ou no, para documentos hipermdia. Essa
estruturao permitir a definio de diferentes vises de um mesmo
documento e tambm melhorar a orientao do usurio na navegao sobre
um documento.
Um n de contexto C deve ter definido o mtodo deferido de n de
composio:
- Insere n: insere um n de contedo, um n switch ou um outro n de
contexto no conjunto de ns de C.
Alm dos mtodos para consultar e modificar os valores dos atributos,
dos mtodos para manipular as listas de portas e de ncoras, e dos mtodos
para manipular o conjunto de ns, ns de contexto devem tambm prover
mtodos para manipular seus conjuntos de elos e suas colees de
apresentao (por exemplo, inserir, remover, consultar, percorrer etc.).
C.7 Ns Switch (Alternativas de Ns)
O NCM possui vrias caractersticas que oferecem suporte adaptao
de documentos. Uma importante facilidade o grupo de ns alternativos, cuja
seleo feita com base em regras (rules) associadas ao documento. A
Figura C.3 descreve o diagrama de classes para regras NCM.

11
O grupo pode estar vazio para qualquer constituinte do contexto.
12
A semntica por trs da definio do grupo de descritores selecionados para cada n N contido em
um n de contexto permitir uma navegao em profundidade para N especificando vrias exibies
diferentes simultneas, como ser explicado melhor na Seo C.10. Alm disso, como ser comentado na
Seo C.11, um descritor do grupo pode ser o resultado de uma seleo entre alternativas de descritores
(switch de descritores), cuja escolha poder depender de parmetros da plataforma ou do prprio usurio.
471
SimpleRule
var
op
value
CompositeRule
op
SwitchNode
DescriptorSwitch
Rule
id
2..n
1
2..n
1
1..*
0..*
1..* ruleList
0..*
1..*
0..*
1..*
ruleList
0..*
Descriptor
0..1 0..1
rule

Figura C.3 Diagrama de classes para regras.
Baseado nas informaes contextuais (por exemplo, preferncias do
usurio, caractersticas da plataforma de exibio etc.),
13
o formatador de
documentos NCM deve avaliar cada regra para descobrir se uma determinada
entidade associada regra deve ou no ser considerada na apresentao do
documento. A forma como entidades e regras so associadas ser explicada
adiante.
Uma regra pode ser simples ou composta. Uma regra simples (simple
rule) anloga expresso assertiva do conector, que compara uma
avaliao com um valor (Seo C.8.1) e possui trs atributos: um
identificador (var) da varivel a ser testada, um operador de comparao (=,
=, <, s, >, >) e um valor. A regra composta (compound rule) uma
expresso lgica compreendendo duas ou mais regras (simples ou compostas)
relacionadas atravs de operadores lgicos AND e OR.
Com o objetivo de permitir que um autor especifique alternativas de ns
dependendo da informao contextual (atributos do contexto de exibio), o
NCM define uma entidade chamada n switch. O n switch (switch node)
uma especializao de ns de composio. O contedo de um n switch um
conjunto que pode incluir ns de contexto e de contedo. O n switch tem um
atributo adicional que define, para cada n contido no seu conjunto de ns,
uma regra associada. As regras so definidas em uma lista ordenada. O
formatador de documentos deve avaliar cada uma das regras conforme a
ordem na lista. O primeiro n que tiver a sua regra avaliada como verdadeira
deve ser eleito a alternativa selecionada.

13
Como anteriormente mencionado, as informaes contextuais podem ser representadas por
atributos (propriedades) do n de ambiente (settings node).
472
O n switch pode conter um n default. Durante a apresentao do
documento, esse n deve ser eleito a alternativa selecionada do switch se
nenhuma das regras for avaliada como verdadeira. Na ausncia de um n
default e de uma regra avaliada como verdadeira, nenhum dos ns contidos no
n switch deve ser exibido.
Alm da mencionada propriedade de lista ordenada de portas da
composio (Seo C.5), os ns switch tm uma propriedade adicional
chamada lista ordenada de portas switch (ordered switch port list). Cada
porta switch (switch port) um ponto de interface (Figura C.2) que define um
conjunto de mapeamentos para interfaces de ns contidos no n switch.
As portas de composio tradicionais permitem que um elo seja
associado a uma alternativa especfica. Se essa alternativa no for
selecionada, o ponto terminal do elo ser simplesmente ignorado durante a
apresentao do documento. A definio de portas switch permite que elos
(relacionamentos discutidos na Seo C.9) sejam definidos ancorando em ns
switch, e sejam associados a mais de uma alternativa especfica. Se nenhuma
das alternativas for selecionada, o ponto terminal do elo ser simplesmente
ignorado durante a apresentao do documento.
Como os ns de contexto (Seo C.6), um n switch tem uma coleo
de apresentao, cujo objetivo permitir que sejam definidos grupos de
descritores para cada n contido no n switch.
14
Na verdade, o grupo deve
formar um conjunto de descritores, pois no pode haver mais de uma
instncia de um mesmo descritor em um grupo. Se o n contido no n switch
for um n de contexto, o grupo de descritores dever ser composto de, no
mximo, um descritor genrico. Se o n switch contiver um n default,
tambm pode ser especificado um grupo de descritores para esse n, desde
que as regras mencionadas neste pargrafo sejam seguidas.
O formatador de documentos NCM deve decidir quando avaliar as
regras a fim de resolver os ns switch.
C.8 Eventos
Seguindo a definio de Prez-Luque e Little [Prez-Luque, 1996], um
evento uma ocorrncia no tempo que pode ser instantnea ou ter uma
durao mensurvel. O NCM define algumas classes bsicas de evento que

14
O grupo pode ser vazio para qualquer constituinte do n switch.
473

podem ser estendidas: evento de exibio, evento de composio, evento de
seleo, evento de superposio, evento de proximidade, evento de coliso,
evento de arraste, evento de foco e evento de atribuio.
Um evento de exibio (presentation event), tambm chamado evento
de apresentao, representa a exibio de uma ncora de contedo (segmento
de mdia) de um n de contedo em uma dada perspectiva seguindo as
diretrizes de um dado descritor. Dessa forma, perspectivas distintas ou
descritores diferentes para um mesmo n geram diferentes eventos de
apresentao NCM. Os eventos de apresentao tambm podem ser definidos
sobre ns de contexto e switch, representando a apresentao das unidades de
informao de qualquer n dentro desses ns de composio.
Eventos de composio so definidos pela apresentao da estrutura de
um n de composio. Os eventos de composio so utilizados para
apresentar o mapa da composio (organizao da composio).
Um evento de seleo (selection event) representa a seleo de uma
ncora de contedo de um n em uma dada perspectiva seguindo as diretrizes
de um dado descritor. A forma mais comum para o usurio selecionar uma
ncora atravs de dispositivos de entrada como mouse e teclado, no entanto
outros dispositivos tambm podem ser utilizados na gerao desse evento,
como um controle remoto de TV. Os eventos de proximidade, de coliso, de
superposio (hovering event), de arraste (drag event) e de foco (focus event)
tambm representam a ao de interao correspondente sobre uma ncora de
contedo de um n em uma dada perspectiva seguindo as diretrizes de um
dado descritor.
Um evento de atribuio (attribution event) refere-se a uma ncora de
atributo de um n, dada uma perspectiva e um descritor especfico.
15

No NCM, cada evento define uma mquina de estados que deve ser
mantida pela mquina de controle da apresentao dos documentos,
denominada formatador [Soares et al., 2006]. A Figura C.4 mostra a
mquina de estados geral dos eventos NCM.

15
importante lembrar que, como definido na Seo C.3, uma ncora de atributo do n pode
referenciar tanto um atributo do n propriamente dito como um atributo do descritor associado ao n para
apresent-lo, como discutido na Seo C.10.
474
paused
sleeping occurring
resume
stop | abort
pause
stop| natural end
abort
start

Figura C.4 Mquina de estados dos eventos NCM.
Um evento NCM pode estar em um dos seguintes estados: dormindo
(sleeping), ocorrendo (occurring) ou pausado (paused). Todo evento possui
um atributo denominado ocorrncias (occurrences), que conta o nmero de
vezes que o mesmo muda do estado ocorrendo para o estado dormindo
durante a apresentao de um documento. Eventos como os de exibio e de
atribuio tambm possuem um atributo denominado repeties (repetitions),
que determina o nmero de vezes seguidas que o mesmo deve ocorrer. Esse
atributo pode conter um valor finito ou o valor indefinido, que levar a uma
execuo em loop do evento, at que a mesma seja interrompida.
Intuitivamente, considerando um evento de exibio como exemplo
(Figura C.4), o evento inicia no estado dormindo. Ao iniciar a exibio de
suas unidades de informao, o evento passa para o estado ocorrendo. Se a
apresentao for temporariamente suspensa, o evento vai para o estado
pausado e no mesmo permanece enquanto a situao durar. Ao final da
apresentao, o evento retorna para o estado dormindo, seu atributo
ocorrncias incrementado de uma unidade, e o atributo repeties
decrementado de uma unidade. Se, aps ser decrementado, o atributo
repeties possuir um valor maior que zero, a apresentao do evento ser
reiniciada automaticamente. Quando uma apresentao de um evento
interrompida abruptamente, atravs de um comando de aborto da exibio, o
evento passa para o estado dormindo, sem que o atributo ocorrncias seja
incrementado e tornando zero o valor do atributo repeties. Eventos de
seleo permanecem no estado ocorrendo enquanto a ncora correspondente
estiver sendo selecionada. De modo similar, eventos de arraste, foco e
superposio permanecem no estado ocorrendo enquanto a respectiva
operao sobre a ncora durar. J os eventos de atribuio permanecem no
estado ocorrendo enquanto os valores dos atributos estiverem sendo
modificados. Evidentemente, eventos instantneos, como uma simples
atribuio de valor, podem permanecer por um tempo infinitesimal no estado
ocorrendo.
475
Um evento de apresentao pode mudar do estado ocorrendo para
dormindo em duas situaes: como consequncia de um trmino natural da
exibio de suas unidades de informao ou devido a uma ao que force o
trmino do evento.
A durao de um evento o tempo que ele permanece no estado
ocorrendo. No caso de um evento de apresentao, essa durao pode ser
intrnseca ao objeto de mdia ou especificada pelo descritor do evento. A
durao de um evento de apresentao ser escolhida pelo formatador de
documentos levando em considerao parmetros intrnsecos ao contedo,
parmetros do descritor, relacionamentos do documento (principalmente os
elos) e outras informaes externas, como caractersticas da plataforma de
exibio.
Um evento de apresentao associado com um n de composio
permanece no estado ocorrendo enquanto pelo menos um evento de
apresentao associado com qualquer um dos ns filhos dessa composio
estiver no estado ocorrendo ou enquanto pelo menos um elo filho do n de
composio estiver sendo avaliado.
Um evento de apresentao associado com um n de composio est no
estado pausado se pelo menos um evento de apresentao associado com
qualquer um dos ns filhos da composio estiver no estado pausado e todos
os outros eventos de apresentao associados com os ns filhos da
composio estiverem no estado preparado ou pausado. Do contrrio, o
evento de apresentao est no estado dormindo.
Um evento de apresentao associado com um n switch permanece no
estado ocorrendo enquanto um elemento filho do switch, escolhido (n
selecionado) atravs das regras de ligao (bind rules), estiver no estado
ocorrendo. Ele est no estado pausado se o n selecionado estiver no estado
pausado. Do contrrio, o evento de apresentao est no estado dormindo.
Um evento de composio permanece no estado ocorrendo enquanto o
mapa da composio estiver sendo apresentado.
Elos definidos nos ns de contexto, na verdade, especificam
relacionamentos entre eventos definidos nas ncoras dos ns, mais
precisamente entre mquinas de estados dos eventos, como ser discutido na
prxima seo. Com o objetivo de facilitar a explicao dos elos NCM, a
Tabela C.1 define nomes para as transies de estados e tambm para as
aes que produzem uma determinada transio de estado nas mquinas de
estados dos eventos NCM.
476
Tabela C.1 Nomes de transies e aes para a mquina de estados dos eventos NCM
Transio (Causada pela Ao) Nome da Transio
sleeping occurring (start) starts
occurring sleeping (stop) stops
occurring sleeping (abort) aborts
occurring paused (pause) pauses
paused occurring (resume) resumes
paused sleeping (stop ) stops
paused sleeping (abort) aborts
C.9 Elos
Um elo (link) uma entidade NCM que possui duas propriedades
adicionais: um conector e um conjunto de associaes (binds) a esse conector.
O conector uma entidade cujo objetivo definir as semnticas das
relaes hipermdia, independentemente dos participantes que iro
efetivamente interagir [Muchaluat et al., 2002]. Conectores recebem o status
de entidades de primeira classe no modelo [Muchaluat et al., 2001], isto , os
conectores podem ser definidos independentemente de outras entidades do
modelo.
Elos representando o mesmo tipo de relao, mas interconectando
participantes (ns) diferentes, podem reusar o mesmo conector.
Um conector especifica um conjunto de pontos de acesso de interface
chamados papis. Um elo NCM referencia um conector e define um conjunto
de binds que relacionam cada extremidade do elo (ponto de interface de um
n) com um papel do conector referenciado.
A Figura C.5 apresenta a hierarquia de classes do elo NCM, discutida
nas subsees seguintes.
Entity
CausalLink ConstraintLink CausalConnector ConstraintConnector
Bind
role
component
interface
descriptor
embed
Link
2..n 1 2..n
bindSet
1
Role
Glue
HypermediaConnector
* 1
connector
* 1
2..n
1
2..n
roles
1
1
1
1
glue
1

Figura C.5 Hierarquia de classes do elo NCM.
477
C.9.1 Conectores
A Figura C.6 ilustra um conector R representando uma relao com trs
papis distintos, que significam trs tipos de participantes da relao. A
figura tambm mostra dois elos diferentes, l
1
e l
2
, reusando R. Enquanto o
conector define o tipo de relao, o conjunto de binds de um elo define os
participantes. O elo l
1
especifica trs binds, interligando os ns A, B e C aos
papis de R. O elo l
2
tambm especifica trs binds, s que interligando um
conjunto diferente de ns (B, C e D). Os elos l
1
e l
2
definem relacionamentos
diferentes, j que interligam conjuntos distintos de ns, mas representam o
mesmo tipo de relao, pois usam o mesmo conector. Na especificao de um
documento NCM, um elo deve fazer referncia a uma instncia de conector.
xconnector
node node anchor/port/attribute bind bind role role
xconnector R xconnector R
A
C
Link l
1
D
Link l
2
B
R
R
A
C
Link l
1
D
Link l
2
B
RR
RR

Figura C.6 Exemplos de elos que utilizam o mesmo conector R.
Conceitualmente, conectores podem representar qualquer tipo de relao
hipermdia, tal como relaes de referncia, relaes de sincronizao,
relaes semnticas, relaes de derivao etc. Essa verso 3.0 do NCM
concentra seus esforos na especificao de relaes de sincronizao espao-
temporal, assim como relaes de referncia,
16
oferecendo o suporte
necessrio para a criao de documentos hipermdia.
O conector (connector) NCM permite a definio de relaes
multiponto com semntica causal ou de restrio. Em uma relao causal,
uma condio deve ser satisfeita para que uma ao seja executada. Um
exemplo de relao causal a tradicional relao de referncia hipermdia,
que causa a navegao para um n de destino quando uma ncora de um n
de origem for selecionada pelo usurio. Um outro exemplo de relao causal
pode iniciar a apresentao de um n quando a apresentao de outro
terminar. Alm de relaes causais, relaes de restrio, sem nenhuma
causalidade envolvida, tambm podem ser especificadas por conectores

16
Na realidade, as relaes de referncia so tratadas como casos particulares de relaes de
sincronizao espao-temporal.
478

NCM. Considere, por exemplo, uma restrio especificando que um n deve
terminar sua apresentao ao mesmo tempo que outro comea a dele. A
ocorrncia de uma apresentao sem a ocorrncia da outra tambm satisfaz a
restrio, que especifica que, se e somente se esses dois ns forem
apresentados, seus tempos de fim e incio, respectivamente, devem coincidir.
Para capturar relaes causais e de restrio, conectores so
especializados em conectores causais e conectores de restrio. Em ambos os
tipos, a definio de um conector feita por um conjunto de papis (roles)
que determinam a funo dos participantes da relao e um atributo glue, que
descreve como os papis interagem. A definio de papis baseada no
conceito de evento (Seo C.8). Cada papel descreve um evento associado a
um participante da relao e o glue descreve a combinao entre os eventos
de acordo com a semntica de causalidade ou de restrio.
Cada papel de um conector define um identificador nico (id) no
conjunto de papis do conector, um tipo de evento e sua cardinalidade. O tipo
de evento (event type) especifica o nome de uma das especializaes da classe
evento. A Tabela C.2 descreve os nomes para os tipos de evento NCM. A
cardinalidade de um papel indica o nmero mnimo e mximo de participantes
que podem desempenhar o papel (nmero de binds) quando esse conector for
usado na criao de um elo, como ser definido posteriormente.
Tabela C.2 Definies dos nomes para os tipos de evento dos conectores NCM
Especializao do Evento Nome para o Tipo de Evento
Evento de apresentao presentation
Evento de seleo selection
Evento de superposio do
dispositivo apontador
pointOver
Evento de arraste drag
Evento de atribuio attribution
Evento de foco focus
Evento de coliso collision
Evento de proximidade proximity
Papis so especializados em condio (condition), ao (action) e
avaliao (assessment). Diferentes tipos de papis so usados de acordo com
o tipo de conector. Em conectores de restrio, somente papis do tipo
avaliao devem ser usados. Em conectores causais, qualquer tipo de papel
pode ser usado. A Figura C.7 apresenta a hierarquia de classe dos papis de
conectores NCM.
479
action
Role
id
eventType
minCardinality
maxCardinality
SimpleCondition
EventStateTransitionCondition
transitionName
EventAttributeCondition
attributeName
comparator
value
Action
actionType
delay
repetitions
delayBetweenRep
ActionRole
1 1 1 1
CompoundCondition
operator
isNegated
Condition
2..n
1
2..n
1
ConditionRole
1 1 1
condition
1
NodeAttributeCondition
attributeName
comparator
value
SimpleComparisonCondition
attributeName
comparator
value
AssessmentRole Assessment
offset
1 1
assessment
1 1
EventAttributeAssessment
attributeName
NodeAttributeAssessment
attributeName
EventStateTransitionAssessment
transitionName
AssignmentAction
value

Figura C.7 Hierarquia de classes dos papis de conectores NCM.
Papis do tipo ao (action roles) capturam aes que devem ser
executadas em uma relao causal. Os tipos de ao esto ilustrados na
Figura C.4 por arcos rotulados, que causam transies na mquina de
estados. Alm de seu tipo, a ao de um papel pode definir um valor (value) a
ser imposto a um atributo participante (no caso de eventos de atribuio). Um
exemplo de papel do tipo ao pause a exibio de um evento de
apresentao.
Aes NCM podem ser estendidas. Por exemplo, aes de animao
podem ser especificadas definindo um valor inicial, um valor final e uma
durao para que uma atribuio seja realizada (por exemplo, a posio x do
objeto na tela, em um eixo de coordenadas x e y).
Em conectores causais, condies devem ser satisfeitas para disparar as
aes. As condies so capturadas por papis do tipo condio (condition
role), que definem expresses lgicas avaliando transies nos estados dos
eventos, valores de atributos dos eventos ou valores de atributos dos ns.
Quando uma condio avaliada, ela retorna um valor booleano.
As condies podem ser simples ou compostas. Uma condio simples
(simple condition) pode testar uma transio de estado de um evento, o valor
de um atributo de um evento ou o valor de um atributo de um n. No caso da
condio sobre transio de estado do evento (chamada event state-
transition condition), o resultado do teste considerado verdadeiro apenas no
momento em que a transio ocorre, especificada em seu atributo nome da
transio (transition name), conforme definido na Tabela C.3. A condio
sobre atributo (attribute condition) deve especificar o tipo do atributo a ser
480
testado (attibuteType): estado de um evento ou atributo de um evento
(occurences ou repetitions), associado por um elo a uma ncora de um n, ou
atributo de um n (nodeAttibute), associado por um elo a um atributo
qualquer de um n. O atributo referenciado ser comparado com o valor
(value) especificado na condio, usando um dos seguintes comparadores: =,
=, <, s, >, >. A condio sobre atributo do n obriga que o tipo do evento
definido no papel seja de atribuio, conforme discutido na Seo C.8. Para
os eventos de seleo, o papel condio pode especificar, adicionalmente, a
que dispositivo de seleo ele se refere (por exemplo, teclado ou teclas de um
controle remoto), atravs do attributo Key.
Uma condio composta (compound condition) de um papel do tipo
condio consiste em uma expresso lgica baseada nos operadores and ou or
envolvendo duas ou mais condies que iro atuar sobre o mesmo evento. Um
exemplo de papel com condio composta a apresentao de um
participante terminou pela segunda vez, que seria especificada como
[(eventType = presentation), ((transition = stops) AND (occurrences =
2))].
17
Note que qualquer condio composta pode ser negada utilizando o
atributo booleano est negada (isNegated).
Enquanto uma condio sempre retorna um valor booleano, um papel de
avaliao (assessment role) contm uma avaliao que retorna qualquer tipo
de valor, dependendo do tipo do alvo da avaliao. Uma avaliao de
atributo (attribute assessment) retorna o valor de um atributo do evento
(attributeType igual a um dos atributos de evento: occurences ou repetitions)
ou o valor de um estado de evento (attributeType igual a state), quando
associado por um elo a uma ncora de um n, ou retorna um valor de atributo
de um n (attributeType igual a nodeAttribute), associado por um elo. Uma
avaliao de transio de estado do evento (event-state transition
assessment) retorna o instante de tempo em que uma transio de estado do
evento, especificada no atributo nome da transio (transitionName), ocorre.
Ao se referir a um evento de seleo, um papel de avaliao pode especificar,
adicionalmente, a que dispositivo de seleo ele se refere, atravs do atributo
key.
Como mencionado anteriormente, um conector definido por um
conjunto de papis e um glue, que especifica como os papis interagem. Todo
papel de um conector deve ser usado em seu glue. Um conector de restrio
tem um glue de restrio (constraint glue), que define uma expresso
assertiva (statement expression) relacionando papis do tipo avaliao. Um
conector causal tem um glue causal (causal glue), que define tanto uma
expresso de disparo (trigger expression), relacionando papis do tipo

17
Operadores de condies compostas podem ser estendidos com outros tipos, como operadores de
lgica temporal. Evidentemente, esses operadores tero de ser corretamente interpretados pelos formatadores
dos documentos.
481
condio ou avaliao, quanto uma expresso de aes (action expression),
relacionando papis do tipo ao. Quando a expresso de disparo for
satisfeita, a expresso de aes dever ser executada. A Figura C.8 ilustra a
hierarquia de classes definida pelo modelo para as expresses dos conectores
NCM.
Glue
SimpleStatement
comparator
mainAssessmentRole
mainRoleQualifier
mainAssessmentOffset
AssessmentValueStatement
value
AssessmentStatement
otherAssessmentRole
otherRoleQualifier
otherAssessmentOffset
CompoundStatement
operator
isNegated
StatementExpression
2..n
1
2..n
1
ConstraintGlue
1 1 1
expression
1
SimpleTriggerExpression
conditionRole
roleQualifier
ActionExpression
delay
TriggerExpression
minDelay
maxDelay
CausalGlue
1 1 1
actionExpression
1
1
1
1
triggetExpression 1
ConditionExpression
CompoundTriggerExpression
operator
isNegated
2..n
1
2..n
1
SimpleActionExpression
actionRole
roleQualifier
repeat
repeatDelay
CompoundActionExpression
operator

Figura C.8 Hierarquia de classes das expresses nos conectores NCM.
A expresso assertiva do glue de restrio pode ser simples ou
composta. Uma assertiva simples (simple statement) pode comparar papis
de avaliao do mesmo tipo (assertiva entre avaliaes assessment
statement) ou um papel de avaliao com um valor, do mesmo tipo, do
resultado da avaliao (assertiva de valor de avaliao assessment value
statement). Um valor de deslocamento (offset) pode ser adicionado a um
papel de avaliao antes da comparao. Por exemplo, um deslocamento pode
ser adicionado a uma avaliao especificando: 5 segundos aps o instante de
tempo em que um evento de apresentao termina ou, ainda, a posio
vertical na tela mais 50 pixels. A comparao pode usar os mesmos
comparadores definidos para as condies simples. Por exemplo, suponha que
um papel de avaliao de transio de estado de evento P especifique o tipo
de evento como apresentao e a transio starts (incio da ocorrncia do
evento), e que um outro papel de avaliao de transio de estado de evento Q
especifique o tipo de evento como apresentao e a transio stops (trmino
da ocorrncia do evento). Se uma assertiva entre avaliaes S
1
definir que P
= Q, S
1
ser avaliada como verdadeira se um evento de apresentao
associado a P iniciar ao mesmo tempo que um outro evento de apresentao
482
associado a Q terminar.
18
Como outro exemplo, suponha que um papel de
avaliao H contenha uma avaliao de atributo do n que especifique a
posio horizontal na tela. Se uma assertiva de valor de avaliao S
2
definir
que H > 100, S
2
ser avaliada como verdadeira se a posio horizontal de
um participante desempenhando o papel H for maior que 100. Quando o
valor da cardinalidade mxima de um papel maior do que um, vrios
participantes podem desempenhar o mesmo papel. Nesse caso, um
qualificador (qualifier) precisar ser definido cada vez que o papel for
utilizado nas expresses do glue, como ser explicado na descrio da Tabela
C.4.
Uma assertiva composta (compound statement) consiste em uma
expresso lgica, baseada nos operadores and ou or, envolvendo duas ou
mais outras expresses assertivas. Assertivas compostas podem
opcionalmente ser negadas.
Apesar de expresses assertivas poderem ser utilizadas em conectores
causais, sua principal utilidade est na especificao de conectores de
restrio. A semntica de um conector de restrio a de que a expresso
assertiva deve ser mantida verdadeira durante a apresentao. A Tabela C.3
ilustra um exemplo de conector de restrio expressando uma relao de
sincronizao espacial especificando que dois ns devem ser alinhados pelo
topo (o atributo top de seus descritores deve ser idntico).
Tabela C.3 Exemplo de conector de restrio
Tipo de Papel e
Id
Tipo do
Evento
Cardinalidad
e (min, max)
Nome do
Atributo
Avaliao P
1
attribuio (1,1) descriptor.top
Avaliao P
2
attribuio (1,1) descriptor.top

Tipo do Glue Expresso Assertiva
Restrio P
1
= P
2

Uma expresso de disparo de um glue causal tambm pode ser simples
ou composta. Uma expresso de disparo simples (simple trigger expression)
se refere a um papel do tipo condio. Uma expresso de disparo composta
(compound trigger expression) consiste em uma expresso lgica, baseada
nos operadores and ou or, envolvendo duas ou mais outras expresses de
disparo ou de assertiva. Uma expresso de disparo composta pode ser

18
Como comentado, se o primeiro evento de apresentao no for iniciado ou o segundo evento de
apresentao no terminar, a expresso permanece verdadeira.
483
opcionalmente negada. Qualquer expresso de disparo (simples ou composta)
pode especificar retardos mnimo (minimum delay) e mximo (maximum
delay) para sua avaliao. Por exemplo, dado que uma expresso de disparo
C verdadeira no instante t, C definida com minimum delay=t1 e
maximum delay=t2 verdadeira no intervalo [t+t1, t+t2].
19

Expresses de disparo compostas podem relacionar qualquer nmero de
papis de condio e de avaliao (atravs das expresses assertivas e
expresses de condio). Entretanto, uma restrio necessria para garantir
a consistncia de relaes causais. Toda expresso de disparo associada a um
conector causal deve ser satisfeita somente em um instante de tempo
infinitesimal, exigindo que pelo menos um papel de condio de cada conector
causal defina uma condio sobre uma transio de estado de um evento.
Uma expresso de aes (action expression) tambm pode ser simples
ou composta. Uma expresso de aes simples (simple action expression)
refere-se a um papel do tipo ao. Se o papel do tipo ao de uma expresso
de aes simples exercido por um evento do tipo de apresentao ou de
atribuio, um atributo repeat pode ter seu valor imposto ao atributo
repeties (repetitions) do evento. Um retardo entre repeties da ao
(repeat delay) tambm pode ser especificado. Uma expresso de aes
composta (compound action expression) consiste em uma expresso, baseada
nos operadores par, seq ou excl, envolvendo duas ou mais outras expresses
de aes. Expresses compostas de aes parelelas (par) ou sequenciais (seq)
especificam que a execuo das aes deve ser feita em qualquer ordem ou
em uma ordem especfica, respectivamente. Expresses compostas de aes
exclusivas (excl) especificam que somente uma das aes deve ser executada.
No ltimo caso, o formatador do documento deve decidir qual das aes deve
ser disparada ou por sua conta ou com o auxlio do usurio.
Uma expresso de aes pode tambm especificar um retardo (delay)
que deve ser respeitado antes que a ao seja efetivamente executada.
20

Como dito anteriormente, quando a cardinalidade mxima de um papel
for maior que um, vrios participantes podem desempenhar o mesmo papel.
Nesse caso, um qualificador (qualifier) deve ser especificado toda vez que
esse papel for usado em expresses do glue. A Tabela C.4 apresenta os
possveis valores para qualificadores.

19
Note que o comportamento temporal das relaes NCM tambm pode ser obtido utilizando o n de
tempo (Seo C.4), em vez de explorar os parmetros de retardo do conector.
20
Uma aplicao baseada no NCM pode permitir a parametrizao desse valor e de outros atributos
presentes nas expresses de um glue e nos papis. Na linguagem NCL, por exemplo, uma mesma
especificao de conector pode ser reusada, com valores diferentes de parmetros derivando conectores NCM
diferentes. De fato, a parametrizao NCL usada no apenas para atributos de aes, mas tambm para
atributos de condies e de avaliaes, especificados tanto nos papis do conector quanto nas expresses de
um glue. Parametrizao, contudo, uma questo de implementao e no de modelo. Por isso, ela deixada
para as definies das aplicaes.
484
Tabela C.4 Valores para os qualificadores dos papis com cardinalidade mxima maior que
um
Tipo do
Papel
Qualificado
r
Semntica
Condio all Todas as condies devem ser verdadeiras
Condio any Ao menos uma condio deve ser verdadeira
Avaliao all Todas as avaliaes devem ser consideradas
Avaliao any
Ao menos uma avaliao deve ser
considerada
Ao par Todas as aes devem executar em paralelo
Ao seq
Todas as aes devem executar em paralelo,
mas respeitando a ordem em que os
participantes foram associados ao papel
Ao excl Apenas uma das aes deve ser executada
A Tabela C.5 ilustra um exemplo de conector causal expressando uma
relao de sincronizao temporal. A especificao do conector pode ser
interpretada como se um grupo de participantes estiver sendo apresentado
(C
1
) e outro participante for selecionado (C
2
), pare a apresentao do grupo
de participantes (A
1
) e inicie a apresentao de outro participante (A
2
). Para
parar a apresentao do mesmo grupo de participantes que desempenhou o
papel C
1
, um elo usando esse conector deve criar dois binds para cada
participante do grupo, um para o papel C
1
e outro para o papel A
1
.
Tabela C.5 Exemplo de conector causal
Tipo do Papel e
Id
Tipo do
Evento
Cardinalidad
e (min, max)
Condio Ao
Condio C
1
apresentao
(1,
unbounded)
state=occurring
Condio C
2
seleo (1, 1) transition=stops
Ao A
1
apresentao
(1,
unbounded)
stop
Ao A
2
apresentao (1, 1) start

Tipo do Glue
Expresso de
Disparo
Expresso de
Aes
Causal all(C
1
) AND C
2
seq(par(A
1
), A
2
)
Como a definio de conectores no simples de ser feita por um
usurio leigo, pois ele precisaria conhecer os conceitos de estados e transies
de estados de eventos, a ideia fazer com que usurios experientes definam
conectores, os armazenem em bibliotecas, chamadas de bases de conectores
(connector bases), e as tornem disponveis para a criao de elos.
485
C.9.2. Binds de Elos
Conforme j mencionado, elos so definidos em uma composio (na
realidade, em um n de contexto). Um elo referencia um conector e define um
conjunto de binds que associam cada extremidade do elo (interface dos ns) a
um papel do conector referenciado. Binds so limitados a conectar interfaces
de ns que estejam diretamente contidos em uma composio C onde o elo
definido ou ncoras da prpria composio C. No entanto, uma vez que a
porta de um n de composio pode ser mapeada para a porta de um outro n
de composio interno, e assim por diante, at que a ncora de um n seja
alcanada, elos definidos em uma composio C podem indiretamente
associar aos papis do seu conector eventos definidos em qualquer n
recursivamente contido em C. Isso traz a noo de elos visveis e elos
contextuais, definidos a seguir.
Lembramos que, no NCM, ns de composio diferentes podem conter o
mesmo n, e os elos podem ser definidos em qualquer composio da
perspectiva de um n, sendo necessrio identificar quais elos efetivamente
ancoram em um n ou passam por um n (no caso de ns de composio), em
uma dada perspectiva. Ao conjunto de elos que ancoram em um n, em uma
dada perspectiva P, chamamos de elos contextuais de P; ao conjunto de elos
que ancoram ou passam por um n de composio, em uma dada perspectiva,
chamamos de elos visveis de P.
Mais precisamente, dado um n N
1
e uma perspectiva P = (N
m
,....,N
1
),
com m>0:
1. Um elo l visvel em P se e somente se existe um n de composio
N
i
, para i e[1,m], tal que N
i
ocorre em P, N
i
contm l e:
i) se i>1, ento (N
i1
, p...,N
1
,p
1
) define uma sequncia de
mapeamentos de uma porta (Seo C.5) p da composio N
i1
e p
diretamente associada a um papel do conector usado por l;
ii) seno, N
1
um n que possui uma interface diretamente
associada a um papel do conector usado por l.
2. Um elo l contextual em P se e somente se existe um n de
composio N
i
, para i e[1,m], tal que N
i
ocorre em P, N
i
contm l e:
486
i) se i>1, ento (N
i1
, p...,N
1
,p
1
) define uma sequncia de
mapeamentos de uma porta p da composio N
i1
, N
1
contm uma
ncora que pertence sequncia de mapeamentos da porta p e p
diretamente associada a um papel do conector usado por l;
ii) seno, N
1
um n que possui uma ncora diretamente
associada a um papel do conector usado por l.
Por exemplo, suponha que os ns A e Z contenham o n B, que por sua
vez contm os ns C, D, E e F, com elos ilustrados na Figura C.9. Ento, a
exibio do n C, atravs da perspectiva (A, B, C), vai mostrar um elo da
ncora i de C para a ncora j de E e um elo da ncora m de C para ncora n
de F, definidos em A e B, respectivamente. Ambos so elos contextuais e
visveis em (A, B, C). A exibio do n B, atravs da perspectiva (A,B), vai
mostrar um elo de B para B, que definido no n A. Esse o nico elo visvel
em (A, B); no h elos contextuais em (A, B).
conector
ncora / atributo
A
c1
Z
c4
B
E
j
s
C m
r
i
c1
p3
p2
p1
F
c2
D
k t
p4
c3
B
E
j
s
C m
r
i
c1
p3
p2
p1
F
c2
D
k t
p4
c3
papel
n
porta
ligao (bind) mapeamento

Figura C.9 Exemplos de elos visveis em contextuais no NCM.

487
Por outro lado, a exibio do n C, atravs da perspectiva (Z, B, C), vai
mostrar um elo a partir da ncora r de C para a ncora k de D e um elo a
partir da ncora m de C para a ncora n de F, definidos em Z e B,
respectivamente. Ambos so elos contextuais e visveis em (Z, B, C). A
exibio do n B, atravs da perspectiva (Z, B), vai mostrar um elo de B para
B, definido no n Z. Esse o nico elo visvel em (Z, B), no havendo elos
contextuais nessa perspectiva.
Binds de um elo possuem outros atributos alm daqueles utilizados para
associar uma interface a um papel: descritor e embed. Um atributo descritor
opcional e especifica um descritor genrico para o n associado com o papel
do conector. Se o n associado for um n de composio N, o descritor deve
ser nulo. Note que vrios binds para o mesmo n de contedo com diferentes
descritores levam a apresentaes simultneas do mesmo n com diferentes
caractersticas de exibio, similar ao que proporcionado com o grupo de
descritores e a navegao em profundidade discutida na Seo C.5.
O atributo embed um atributo booleano que s deve ser usado na
associao entre um papel de ao (somente para as aes start ou prepare)
com um evento de apresentao E. Se o descritor do bind referenciar uma
ferramenta de exibio (Seo C.11) que j esteja sendo utilizada para
controlar a apresentao de um outro evento F, a ferramenta de exibio
solicitada a tambm controlar E, sem parar F, se o atributo embed for
verdadeiro; caso contrrio, se embed for igual a falso, a ferramenta de
exibio dever ser solicitada a substituir (parar) F por E. Quando no
especificado, esse atributo deve ser considerado como igual a falso.
A definio de portas switch apresentada na Seo C.7 permite que elos
(relacionamentos) sejam definidos ancorando em ns switch,
independentemente do n que ser selecionado, como ilustrado na Figura
C.10. As portas de composio tradicionais permitem que um elo seja
associado a uma alternativa especfica. Se essa alternativa no for
selecionada, o elo ser simplesmente ignorado durante a apresentao do
documento.
488
X
Y
C A B
regras
n switch porta switch
a b c
mapeamentos
ponto de
interface
elo

Figura C.10 Ns switch, portas switch e elos.
Com base nas entidades do modelo ns switch, portas switch e binds de
elos, um autor pode especificar documentos que contemplem adaptao de
elos. Para isso, basta colocar em um mesmo n switch cpias de um mesmo
n, com diferentes elos associados s vrias ocorrncias do n. A Figura C.11
oferece um exemplo de uso das alternativas para adaptar os relacionamentos.
No exemplo, o elo que inicia a apresentao do n Z s estar habilitado no
documento se a regra a for avaliada como falsa e a regra b for avaliada como
verdadeira.
X Y
a b
elo ignorado se a for
verdadeira ou b for falsa
Z
A A
regras
n switch

Figura C.11. Ns switch, portas switch e elos.
489
C.10 Objetos de Dados X
Objetos de Representao
O NCM define um objeto de dados (data object) como uma entidade
que compreende um n NCM e todas as operaes para manipulao desse
n, exceto as operaes relacionadas com a apresentao do seu contedo
(suas unidades de informao, conforme definido na Seo C.3). A
funcionalidade de apresentar o contedo do n dada por uma instncia de
descritor que deve ser associada ao n (objeto de dados).
A agregao de um objeto de dados e um descritor NCM chamada de
objeto de representao. A associao entre objetos de dados e descritores
representada na Figura C.12 por linhas conectando os objetos de dados no
plano intermedirio com os objetos de representao, desenhados no plano
superior. Na figura, os ns so representados por crculos, e os elos por arcos
e composies, pela incluso de crculos e arcos em crculos maiores.
Z
1
C1
A
1
A
2
A
3
X
1
Y
1
Plano de representao
Plano de dados
ns (objetos de
representao)
Z
C
A
X
Y
ns (objetos de dados)
D
1
D
2
D
3
D
X
D
Y
D
Z
D
C
descritores

Figura C.12 Associao entre objetos de dados e descritores, gerando objetos de
representao.
490
Note que um n (objeto de dados) pode ser combinado a diferentes
descritores, originando diferentes representaes (objetos de representao) da
mesma entidade. A figura mostra essa caracterstica com a associao dos
descritores D
1
, D
2
e D
3
ao objeto de dados A, criando os objetos de
representao A
1
, A
2
e A
3
. O n A possui trs diferentes representaes
porque existem, por exemplo, trs diferentes formas de navegao at ele,
atravs dos dois elos ou atravs da hierarquia de composies. Note, assim,
que, devido ao fato de um mesmo objeto de dados poder gerar vrios objetos
de representao, um contexto objeto de representao pode conter um
nmero de elementos diferente do contexto objeto de dados por exemplo, o
contexto C
1
da figura possui trs ns, ao passo que o n objeto de dados
correspondente (contexto C) s tem um.
Pelas definies do NCM, um descritor pode ser definido em uma
propriedade do n, em um grupo de descritores da composio que contm o
n ou como um atributo de binds entre o n e os elos. Alm disso, descritores
default podem ser especificados para as classes dos ns (texto, imagem etc.)
ou explicitamente sugeridos pelos usurio leitor do documento. Se um n
possuir mais de um desses descritores especificados, o sistema de
apresentao (formatador de documentos NCM) dever construir um
descritor resultante baseado na regra de cascateamento definida a seguir.
Suponha um n N da classe C com a perspectiva corrente (C
k
, , C
1
,
N) alcanada atravs de uma navegao por elo (elo l). Seja D
1
um descritor
definido para a classe do n C, D
2
o descritor definido pela propriedade
descritor de N, D
3
o nico membro do grupo de descritores especificado para
N em C
1
, e D
4
um descritor especificado no bind feito para associar N ao
conector referenciado pelo elo l. O descritor resultante ser formado pela
soma de todos os atributos/propriedades dos seguintes descritores: D
1
, D
2
, D
3
,
D
4
. Se dois ou mais descritores definirem o mesmo atributo/propriedade com
diferentes valores, D
4
(descritor do elo) ter prioridade sobre D
3
(descritor da
composio), que ter prioridade sobre D
2
(descritor do n), que ter
prioridade sobre D
1
(descritor da classe). Se o usurio especificar um quinto
descritor ao navegar para N, esse descritor ser includo na lista de
cascateamento com precedncia sobre D
4
.
C.11 Descritores Genricos, Descriptores e
Switches de Descritores
Conforme mencionado anteriormente, descritores NCM agrupam
informaes das caractersticas de apresentao, objetivando separar essas
informaes do contedo do documento e de sua estrutura.
491
O NCM define uma classe descritor genrico (generic descriptor) que
especializada nas classes descritor (descriptor) e switch de descritores
(descriptor switch). O descritor NCM uma entidade que possui como
propriedades adicionais: uma especificao de incio de apresentao, uma
especificao de fim de apresentao e uma coleo de descries de
eventos.
A propriedade especificao de incio de apresentao deve conter um
identificador da ferramenta de exibio (player) utilizada pelo formatador.
Essa ferramenta ser responsvel por processar e exibir o contedo do n
durante a apresentao. Quando essa propriedade no estiver definida ou o
seu valor apontar para uma ferramenta inexistente no formatador, o
formatador de documentos dever escolher um exibidor default com base no
tipo de contedo do n.
A especificao de incio de apresentao pode tambm conter um
atributo especificando se uma nova ferramenta de exibio deve ser
instanciada ou se uma ferramenta j instanciada pode ser usada. Alm disso,
a especificao de incio de apresentao pode conter um conjunto de
atributos particulares que ser interpretado pelo exibidor selecionado para
controlar a apresentao do n. Alguns exemplos desses parmetros so:
- para ns com apresentaes visveis, como ns de texto, vdeo e
imagem, um parmetro dispositivo (device) especifica o dispositivo
onde a apresentao ocorrer; um parmetro regio espacial (spatial
region) especifica uma localizao para apresentar o contedo do n,
identificando a posio na tela do dispositivo especificado etc.
Quando esses parmetros no forem especificados, o formatador
dever escolher um dispositivo e uma rea default para apresentao
do n;
- para ns de udio, um parmetro dispositivo (device) especifica o
dispositivo de udio onde o som deve ser apresentado; um parmetro
volume especifica o volume inicial de apresentao etc.
21
Quando
esses parmetros no forem especificados, o formatador dever
escolher um dispositivo e uma rea default para apresentao do n;
- para um n de texto que deva ser exibido por uma ferramenta TtS
(text to speech), parmetros podem especificar a voz desejada, o
sotaque etc.
A propriedade especificao de fim de apresentao define aes que
devem ser executadas ao final de uma apresentao. Ela deve conter um

21
O autor pode escolher exibir alguma informao visual associada ao udio (por exemplo, uma
barra de progresso temporal). Nesse caso, os parmetros descritos no primeiro item tambm poderiam ser
especificados.
492
atributo especificando o que acontecer com a ferramenta de exibio ao final
da apresentao, isto , se a ferramenta ser fechada ou permanecer aberta,
pronta para uma prxima apresentao. Neste ltimo caso, deve tambm ser
especificado se a ferramenta de exibio permanecer escondida ou no.
Uma descrio de um evento, em um descritor, por sua vez, consiste na
tupla <Idncora, DurExplcita, FunoCusto, Rep>. O parmetro Idncora
um identificador de uma ncora do objeto de dados (n) ao qual o descritor
ser associado para a formao do objeto de representao (essa ncora pode
ser genericamente identificada por um rtulo ou por sua posio na lista de
ncoras para permitir que um mesmo descritor seja reusado por mais de um
n). DurExplcita opcional, somente podendo ser utilizada para eventos do
tipo exibio, e sobrescreve a durao de apresentao ideal intrnseca ao
contedo do n. FunoCusto tambm opcional, tambm s podendo ser
usada em eventos do tipo exibio, e especifica uma mtrica para guiar o
formatador em ajustes que precisem ser feitos na durao de apresentao da
ncora do n. Rep especifica um valor para iniciar o atributo repeties do
evento (Seo C.8). Em particular, todo descritor contm ao menos a
descrio de evento <, DurExplcita, FunoCusto, Rep> associada sua
ncora de contedo total, onde, como j mencionado, DurExplcita,
FunoCusto so opcionais.
De forma similar entidade n switch (Seo C.7), o switch de
descritores contm uma lista ordenada de regras, estando cada regra
associada a um descritor. O formatador de documentos deve percorrer a lista
avaliando cada regra e selecionando o primeiro descritor cuja regra tiver sido
satisfeita. Se nenhuma das regras for verdadeira, o switch de descritores pode
especificar um descritor default para ser selecionado.
A entidade switch de descritores permite que formatadores de
documentos NCM adaptem caractersticas da apresentao dos ns
independentemente das informaes estruturais e dos contedos. Obviamente,
ambos os tipos de flexibilidade (adaptao de apresentao e adaptao de
contedo) podem ser combinadas. Juntas com os ajustes de durao, essas
caractersticas do modelo proporcionam um suporte flexvel para que os
autores especifiquem documentos e apresentaes de documentos hipermdia
adaptativos.
C.12 Trilhas
Caractersticas como grande nmero de ns e grande nmero de elos,
muitas mudanas no documento, tempo de resposta ruim para as aes do
usurio, diferenas visuais insuficientes entre elos e ns, e usurios no-
orientados visualmente se combinam para dificultar os mecanismos de
493
navegao em um documento. Usurios desorientados precisam de
informaes de escopo para restabelecerem a noo de localizao. Em
particular, informaes do escopo temporal so necessrias para responder a
questes do tipo como eu cheguei aqui?. Essas questes encontram suas
respostas com a introduo do conceito de trilha.
Dada uma composio C, do tipo n de contexto, base privada ou
hiperbase pblica,
22
uma trilha T para C um n de composio cujo
contedo uma lista ordenada de ns de contedo, ns de contexto ou outros
ns de trilha, tais que todos os ns, que no so trilhas, esto recursivamente
contidos em C e todos os seus ns de trilhas so trilhas para C. Mais ainda, T
tem um atributo bsico adicional denominado n corrente, cujo valor indica a
posio de um n na lista ordenada de T, chamado de entidade corrente de T.
Trilhas possuem um outro atributo bsico adicional denominado viso, cujo
valor associa a cada ocorrncia de um n N, na lista de T, um aninhamento de
ns (N
m
,....,N
1
), com m > 1, e um descritor D, tal que N
1
= N, N
m
= C, N
i+1

um n de composio, N
i
est contido em N
i+1
, para i e [1,m). Diz-se que a
trilha T associada a C.
Toda trilha deve implementar o mtodo deferido da classe composio:
- Insere n: insere um n na lista de ns da trilha, em uma posio
especificada, com uma viso associada.
Adicionalmente, toda trilha deve implementar os seguintes mtodos:
- prximo: se o atributo n corrente no apontar para o ltimo n,
incrementa o atributo n corrente;
- anterior: se o atributo n corrente no apontar para o primeiro n,
decrementa o atributo n corrente;
- primeiro: coloca o atributo n corrente apontando para o primeiro n
da lista;
- ltimo: coloca o atributo n corrente apontando para o ltimo n da
lista;
- ativa: habilita os mtodos prximo, anterior, primeiro e ltimo, e
inibe os mtodos, insere n e retira n;
- desativa: desabilita os mtodos prximo, anterior, primeiro e ltimo,
e habilita os mtodos insere n e retira n.
A razo dos mtodos ativa e desativa no permitir que uma trilha seja
usada ao mesmo tempo para navegao (pela trilha) e para manter o histrico
da navegao. Ou ela usada para a realizao de uma tarefa ou da outra.

22
Bases privadas e hiperbase pblica sero definidas na prxima seo.
494
Note que um n pode aparecer mais de uma vez na lista ordenada de T.
Alm disso, cada ocorrncia do n associada com um aninhamento de ns
relativos a C. Dessa forma, trilhas so teis para linearizao de documentos
hipermdia e para implementao de viagens guiadas. Uma trilha especial do
sistema pode manter a histria de navegao do usurio durante uma sesso
de trabalho, de tal modo que o usurio possa mover-se aleatoriamente entre os
ns e depois recordar a navegao realizada. No entanto, se um n N contido
em um n switch S pertencer a uma trilha, esse n dever obrigatoriamente
ser a alternativa selecionada de S quando o usurio navegar pela trilha,
independentemente de a regra associada ao n no for mais verdadeira no
momento da navegao atravs da trilha.
A definio de trilhas importante para sistemas hipermdia, pois elas
representam travessias ordenadas. Atravs delas, os autores podem fornecer
ordens de leitura, que auxiliam leitores no-familiarizados com o material
informativo a navegar pelo hiperdocumento ou determinar uma ordem
apropriada de apresentao para uma certa audincia. Os usurios sentem-se
menos desorientados quando seguem uma trilha j definida, pois limitado o
nmero de opes que possuem para percorrer o documento.
Seguindo o modelo NCM, uma implementao possvel para trilhas que
mantenham o histrico de navegao criar uma trilha principal (ou trilha
do sistema). Toda vez que um usurio navegar para um n, esse n, sua
perspectiva corrente e o descritor resultante (descritor cascateado) so
inseridos na trilha principal pelo sistema. Se o usurio decidir navegar atravs
da trilha, criada uma cpia da trilha principal, e o mtodo ativa chamado
sobre essa cpia. Mesmo durante a navegao nessa cpia, a trilha especial
do sistema atualizada, de forma a sempre manter o histrico da navegao.
Se o usurio fizer qualquer navegao fora da dada pela trilha cpia, a cpia
destruda.
C.13 Hiperbase Pblica e Bases Privadas
A hiperbase pblica um conceito do NCM que representa o repositrio
pblico global das entidades disponveis em um sistema hipermdia. A
hiperbase pblica (public hyperbase) um n de composio nico que,
estando um n de composio C nele contido, ento todos os ns
recursivamente contidos em C devem tambm pertencer hiperbase. A
composio hiperbase pblica tem como propriedade bsica adicional um
conjunto de descritores. Os descritores desse conjunto so aqueles utilizados
para criao dos objetos de representao (veja Seo C.10), a partir do
conjunto de ns contidos na hiperbase pblica.
Uma base privada um tipo especial de n de composio, tal que:
495
i) ela pode conter ns de contedo, ns de contexto, ns switch, trilhas e
outras bases privadas;
ii) uma base privada pode pertencer a, no mximo, uma base privada;
iii) se um n de composio estiver contido em uma base privada PB, seus
componentes podem estar contidos em PB, contidos na hiperbase pblica
ou contidos em alguma base privada recursivamente contida em PB.
Bases privadas possuem como propriedades bsicas adicionais um
conjunto de elos e um conjunto de descritores. Cada elo contido no conjunto
de elos de um n-base privada PB define um relacionamento entre ns
recursivamente contidos em PB. Os descritores no conjunto de descritores de
uma base privada so aqueles utilizados para criar os objetos de
representao (veja Seo C.10) a partir dos ns recursivamente contidos na
base privada.
Intuitivamente, uma base privada rene todas as entidades utilizadas
durante uma sesso de trabalho do usurio.
Bibliografia
Muchaluat-Saade D.C., Soares L.F.G. Hypermedia Spatio-Temporal
Synchronization Relations Also Deserve First Class Status. VIII
Multimedia Modeling Conference. MMM'2001, Amsterdam, novembro
de 2001.
Muchaluat-Saade D.C., Rodrigues R.F., Soares L.F.G. XConnector:
Extending XLink to Provide Multimedia Synchronization. ACM
Symposium on Document Engineering. DocEng02, Virginia,. novembro
de 2002.
Prez-Luque M.J., Little T.D.C. A Temporal Reference Framework for
Multimedia Synchronization. IEEE Journal on Selected Areas in
Communications (Special Issue: Synchronization Issues in Multimedia
Communication), 14(1). Janeiro de 1996, pp. 36-51.
Soares, L.F.S. e Rodrigues, R.F. Nested Context Model 3.0 Part 1 NCM
Core, Monografias em Cincia da Computao do Departamento de
Informtica, PUC-Rio, N. 18/05. Rio de Janeiro, maio de 2005. ISSN
0103-9741.
Soares, L.F.S. e Rodrigues, R.F. Nested Context Model 3.0 Part 8 NCL
(Nested Context Language) Digital TV Profiles. Monografias em Cincia
da Computao do Departamento de Informtica, PUC-Rio, N. 35/06.
Rio de Janeiro, outubro de 2006. ISSN 0103-9741.
496
Apndice D

Exemplo de
Base de Conectores
Este apndice descreve os conectores causais usados nos exemplos do
Captulo 3, O Primeiro Joo, e do Captulo 15, sobre a utilizao de
mltiplos dispositivos de exibio.
1

1
O contedo deste captulo est disponvel sob a Licena Creative Commons Atribuio Uso
No-Comercial Compartilhamento pela mesma Licena 3.0 Unported, conforme publicado em
clube.ncl.org.br.

497
D.1 Conectores Causais
No Captulo 3 tivemos a oportunidade de discutir a concepo de alguns
dos conectores causais apresentados no documento NCL da Listagem D.1.
Outros conectores, contudo, foram apenas referenciados naquele captulo e no
Captulo 15.
Neste apndice, nos limitaremos apenas a apresentar as definies dos
conectores usados nos Captulos 3 e 15, sem discutir os detalhes de suas
concepes. No Captulo 10 o leitor pode encontrar uma discusso geral e
mais aprofundada sobre a concepo de conectores causais.
<ncl id="causalConnBase"
<head>
<connectorBase>

</causalConnector>

qualifier="par"/>
</causalConnector>

</causalConnector>

<causalConnector id="onBeginSet_varStart">
qualifier="par"/>
</compoundAction>
</causalConnector>

<causalConnector id="onKeySelectionStopSet_varStart">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
qualifier="par"/>
qualifier="par"/>
</compoundAction>
</causalConnector>

<causalConnector id="onEndSet_var">
498
</causalConnector>

<causalConnector id="onKeySelectionStopStart">
qualifier="par"/>
qualifier="par"/>
</compoundAction>
</causalConnector>

<causalConnector id="onKeySelectionSet_var">
</causalConnector>

<causalConnector id="onBeginVarStart">
<attributeAssessment role="var"
</causalConnector>

<causalConnector id="onBeginStartSet_var_delay_duration">
<connectorParam name="duration"/>
<simpleAction role="set" value="$var" delay="$delay"
duration="$duration"/>
</compoundAction>
</causalConnector>

<causalConnector id="onSelectionSet_varStop">
<simpleCondition role="onSelection"/>
<simpleAction role="set" value="$var" max="unbounded"
qualifier="par"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>

<causalConnector id="onSelection_orSet_varStopStart">
<simpleCondition role="onSelection" qualifier="or"
max="unbounded"/>
<simpleAction role="set" value="$var" max="unbounded"
qualifier="par"/>
<simpleAction role="stop"/>
</compoundAction>
499
</causalConnector>

<causalConnector id="onBeginSet_var">
</causalConnector>

<causalConnector id="onEndSet_varStop_delay">
<simpleAction role="stop" max="unbounded" qualifier="par"
delay="3s"/>
</compoundAction>
</causalConnector>
</connectorBase>
</head>
</ncl>
Listagem D.1 Exemplo de base de conectores causais.
500
Apndice E

NPT
Normal Play Time
Quando se trata de um fluxo elementar enviado por difuso sem solicitao, o
conceito de tempo de exibio de um objeto de mdia no pode ser
estabelecido, uma vez que podemos sintonizar (comear a receber) o fluxo em
qualquer ponto e, portanto, no h como saber quanto tempo j se passou
desde seu incio (ou at mesmo o que seja o incio). Para possibilitar uma
soluo para o problema, o padro MPEG-2 criou o conceito de Normal Play
Time, ou NPT, que o assunto deste apndice.

501
E.1 Introduo
Um receptor pode comear a receber um fluxo elementar enviado sem
solicitao a partir de qualquer ponto temporal do mesmo, uma vez que o
instante de sintonizao qualquer um. Mais ainda, usual que um fluxo
elementar carregue mais de um contedo de objeto de mdia. Por exemplo, um
fluxo elementar de uma determinada emissora de TV carrega um programa
em sequncia do outro. Pior ainda, um contedo pode ser entremeado por
outro. Por exemplo, quando uma propaganda inserida no meio de um
programa de TV. Tudo isso torna impossvel saber em que instante de tempo
estamos em um determinado contedo, se no houver algum auxlio extra.
Para possibilitar a soluo do problema, o padro MPEG-2 permite ao
difusor especificar, para o receptor, em que ponto uma mdia est sendo
apresentada, por meio da definio de um cdigo de tempo associado a fluxos
elementares. Denominado Normal Play Time, ou NPT, esse cdigo de tempo
transportado em um tipo especial de descritor em uma seo privada
MPEG-2, discutida no Captulo 1.
NPT uma linha de tempo sobre a durao de um evento, definido pelo
padro MPEG-2 [ISO/IEC 13818-11998] como sendo uma coleo de fluxos
elementares com a mesma base temporal, com um tempo de incio e um tempo
de fim associado.
Um NPT pode comear de qualquer valor e prov uma referncia de
tempo para um segmento de mdia. Embora o NPT cresa no decorrer de um
fluxo de mdia, seus valores podem apresentar descontinuidades. Isso
significa que, mesmo se um fluxo de mdia for editado, seu valores NPT no
necessitam mudar. A Figura E.1 ilustra um exemplo. Na figura, o NPT
original apresentado, bem como o NPT final, aps os cortes em cinza-claro
no vdeo e a insero de um comercial em cinza-escuro.
| | | | | | | | | | | | | | | | | | | | | | | | | | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
| | | | | | | | | | | | | | | | | | | | | | | | | | |
1 2 3 7 8 9 10 11 12 13 1 2 3 4 5 14 15 16 17 18 19 20 21 22 23 26 27
clip de mdia original
clip de mdia editado

Figura E.1 NPT em uma mdia editada.
502
Valores NPT podem ser aninhados. Para identificar a que contedo o
NPT se refere, os descritores de referncia NPT tm dois campos: o valor de
NPT (NPT_Reference) e um identificador (contentId) do contedo a que ele
se refere. Por exemplo, na Figura E.1, o contentId do comercial inserido
(cinza-escuro na figura) diferente do restante do vdeo.
Assim, uma descontinuidade em um NPT pode ser reconhecida como
sendo uma simples edio no fluxo original ou uma fronteira entre dois
diferentes segmentos de mdia.
Cada descritor de referncia NPT tambm inclui um valor de taxa,
especificando para o receptor quantas pulsaes do relgio STC (System
Time Clock) do fluxo associado correspondem a uma pulsao do NPT. Essa
taxa no precisa ser constante durante toda uma transmisso de um segmento
de mdia. A taxa especificada por dois campos do descritor: scaleNumerator
e scaleDenominator. Quando os dois campos so iguais a 1, significa que o
NPT est mudando a uma taxa equivalente ao STC. Se o campo
scaleNumerator igual a 0 e o scaleDenominator diferente de zero, isso
indica que o NPT no est mudando em relao ao STC, ou seja, tem um
valor constante. Se os dois campos tm o valor zero, indicado que o
descritor no carrega os dois campos mencionados. Um scaleNumerator
diferente de zero com scaleDenominator igual a zero no permitido.
A Tabela E.1 ilustra a sintaxe de um descritor de referncia NPT. Nela,
dois campos adicionais devem ser observados: postDiscontinuityIndicator e
STC_Reference. O primeiro, se receber o valor 1, indica que o descritor de
referncia NPT ser vlido na prxima descontinuidade da base temporal
STC; se receber o valor 0, indica que o descritor vlido no momento de
sua recepo. O segundo campo indica o valor de STC quando o valor de
NPT aquele dado no campo NPT_Reference.
Tabela E.1 Descritor de Referncia NPT
Sintaxe N.. de Bits
NPT ReferenceDescriptor(){
descriptorTag (igual a 0x01) 8
descriptorLength 8
postDiscontinuityIndicator 1
contentId 7
reserved 7
STC_Reference 33
reserved 31
NPT_Reference 33
scaleNumerator 16
scaleDenominator 16
}
503
Como mencionamos, um NPT pode comear (e obviamente terminar)
em qualquer valor. Para informar a um cliente receptor (que, como vimos,
pode sintonizar um fluxo com base temporal NPT em qualquer ponto do
tempo) os valores inicial e final do NPT de um evento corrente, o MPEG
define um outro descritor chamado NPT Endpoint Descriptor, ilustrado na
Tabela E.2.
Tabela E.2 Descritor de Endpoint NPT
Sintaxe N. de Bits
NPTEndpointDescriptor(){
descriptorTag (igual a 0x02) 8
descriptorLength 8
reserved 15
StartNPT 33
reserved 31
stopNPT 33
}
O Captulo 10 discute como o NPT usado para definir pontos de
sincronizao entre objetos de mdia de um documento NCL e como o
contentId de um descritor NPT associado a um trecho do fluxo.
Bibliografia
Steven Morris (2004). Interactive TV Web. A technical (and non-technical)
guide to DSM-CC. http://interactivetvweb.org/tutorial/dtv-
intro/dsm-cc/index.shtml. Acesso em 21 de maro de 2008.
Balabanian, Casey and Greene (1996). Vahe Balabanian; Liam Casey; Nancy
Greene. An Introduction to Digital Storage Media Command and
Control (DSM-CC). Nortel, 1996.
504
Apndice F

Transporte de
Comandos de Edio
em Sees MPEG-2
Comandos de Edio NCL podem vir de diferentes modos, como
discutido no Captulo 16, que se dedica descrio desses comandos.
Neste apndice nos centraremos na discusso das diversas formas como
esses comandos podem ser transportados, tanto atravs de estruturas de dados
recebidas sem solicitao como atravs de estruturas de dados recebidas sob
demanda, mas em especial usando Sees MPEG-2.
1

1
Este captulo foi baseado em Soares et al., (2006). O uso do material foi gentilmente cedido pelo
505

F.1 Introduo
Como mencionamos no Captulo 16, os parmetros dos comandos de
edio podem vir embutidos no descritor de evento de comando ou podem vir
em estruturas de dados externas, referenciadas pelos descritores de evento.
Esse sempre o caso dos comandos de edio addDocument e addNode.
Nesta seo vamos ver alguns exemplos dessas estruturas de dados e como
elas so transportadas. Vamos ver, tambm, como os descritores de evento
podem ser envelopados e transportados.
F.2 Transporte de Comandos por Descritores de
Eventos de Fluxo e Carrossel de Objetos DSM-CC
Em sistemas de TV digital terrestre comum o uso do protocolo DSM-
CC para transporte de comandos de edio em fluxos elementares de
transporte MPEG-2.
Comandos de edio NCL podem ser transportados usando descritores de
evento de fluxo DSM-CC. Como especificado em ISO/IEC 13818-6 [1998],
descritores de evento de fluxo DSM-CC tm uma estrutura muito parecida
com a dos descritores de evento NCL apresentados no Captulo 16 (ver
Figura 16.1). Na verdade, a estrutura dos descritores de evento NCL foi
definida para tornar o mais fcil possvel esse mapeamento (no caso, tornou
trivial). A Tabela F.1 apresenta a sintaxe de um descritor de evento de fluxo
DSM-CC para transporte de comandos de edio NCL, salientando em itlico
os campos adicionados ao descritor de evento definido no Captulo 16.

506
Tabela F.1 Descritor de Eventos de Fluxo para Comandos de Edio
Sintaxe N. de Bits
StreamEventDescriptor ( ) {
descriptorTag 8
descriptorLenght 8
eventId 16
reserved 31
eventNPT 33
privateDataLength 8
commandTag 8
sequenceNumber 7
finalFlag 1
privateDataPayload 8 a 2008
FCS 8
}
Para transmisso dos parmetros dos comandos de edio, o carrossel
de objetos DSM-CC pode ser usado [ISO/IEC 13818-6, 1998]. O protocolo
de carrossel de objetos DSM-CC permite a transmisso cclica de objetos de
eventos de fluxo e sistemas de arquivos, como vimos no Apndice B.
Em um carrossel de objetos, os objetos de eventos de fluxo so
utilizados para mapear nomes de eventos de fluxo em ids de eventos de fluxo,
definidos pelos descritores de evento. No caso dos eventos de comando NCL,
ele responsvel por mapear o nome nclEditingCommand em eventIds
definidos nos descritores de evento. Os nomes dos eventos permitem
especificar tipos de eventos, oferecendo maior nvel de abstrao s
aplicaes. O gerenciador da base privada, definido no Captulo 16, deve se
registrar como observador dos eventos com os quais lida, utilizando nomes de
evento; no caso de comandos de edio, o nome nclEditingCommand.
Como mencionamos no Apndice B, alm dos objetos de eventos de
fluxos, os carrossis de objetos DSM-CC podem tambm ser usados para o
transporte de arquivos organizados em diretrios. Um demultiplexador DSM-
CC responsvel por montar a estrutura recebida no dispositivo receptor.
Parmetros dos comandos de edio especificados como documentos XML
(documentos NCL ou entidades NCL que se quer adicionar) podem, assim,
ser organizados em sistemas de arquivos a serem transportados nesses
carrossis, como alternativa ao transporte dentro dos prprios descritores de
evento que definem os comandos. O gerador de carrossel de objetos o
responsvel por juntar esses arquivos e os objetos de eventos de fluxo em
fluxos elementares de dados MPEG-2.
507
Assim, quando um comando de edio NCL precisa ser enviado, um
objeto de eventos DSM-CC deve ser criado, mapeando a string
nclEditingCommand em uma id de evento de fluxo, e ento colocado em
um carrossel de objetos DSM-CC, que enviado em um fluxo elementar (o
tipo do fluxo deve ter o valor de 0x0B). Um ou mais descritores de evento de
fluxo DSM-CC com a id previamente selecionada podem ser ento criados e
enviados em outro fluxo elementar MPEG-2 TS. Esses eventos de fluxo
podem ter sua referncia de tempo colocadas em zero, mas tambm podem ser
adiados para serem executados em um tempo especfico. O gerenciador da
base privada deve se registrar como um ouvinte nclEditingCommand e ser
notificado quando esses eventos de fluxo chegarem. O commandTag recebido
ento utilizado pelo gerenciador da base privada para interpretar a
semntica da command string.
Se, no descritor de evento de comando de edio, o command parameter
baseado em XML for curto o suficiente, ele pode ser transportado diretamente
no payload dos descritores de evento. Se no for, o privateDatePayload
transportar um conjunto de pares de referncia. Nesse caso, a especificao
XML deve ser enviada no mesmo carrossel de objetos que carrega o objeto de
eventos. O parmetro uri do primeiro par de referncias deve ter o caminho
absoluto da especificao XML (o caminho no servidor de dados). O
parmetro id correspondente no par deve fazer referncia ao IOR da
especificao XML (carouselId, moduleId, objectKey) [ISO/IEC 13818-6,
1998] no carrossel de objetos. Em comandos de edio diferentes de
addDocument e addNode, o parmetro uri pode ser omitido. Se outros
sistemas de arquivos precisarem ser transmitidos usando outros carrossis de
objeto a fim de completar o comando de edio (como usual nos comandos
addDocument ou addNode) com contedo de mdia, outros pares {uri, id}
devem estar presentes no comando. Nesse caso, o parmetro uri deve ter o
caminho absoluto da raiz do sistema de arquivos (o caminho no servidor de
transmisso de dados), e o respectivo parmetro ior no par deve fazer
referncia ao IOR (carouselId, moduleId, objectKey) de qualquer arquivo ou
diretrio filho da raiz no carrossel de objetos (o service gateway do carrossel,
conforme apresentado no Apndice B).
A Figura F.1 ilustra um exemplo de transmisso de documento NCL,
por meio de um carrossel de objetos, a ser adicionado por meio de um
comando addDocument. Nesse exemplo, um provedor de contedo quer
transmitir o programa interativo chamado "weatherConditions.ncl",
armazenado em um de seus servidores de dados (sistema local de arquivos, de
acordo com a Figura F.1).
508
c:\nclRepository
images
brazilianMap.png
NCL
weather
Service Domain = 1
moduleId = 1
objectKey = 1
objectKind = srg
2 bindings
binding #1
objectName =
objectType = fil
IOR = 1,1,2
binding #2
objectName = images
objectType = dir
IOR = 1,1,3
...
objectKey = 2
objectKind = fil
data
...
objectKey = 3
objectKind = dir
1 binding
binding #1
objectName =
brazilianMap.png
objectType = fil
IOR = 1,2,1
moduleId = 2
objectKey = 1
objectKind = fil
data
...
objectKey = 2
objectKind = ste
eventList
eventName =
nclEditingCommand
eventId = 3
...
Descritor de Evento de Fluxo
descriptorTag = 0
descriptorLength = descriptorLen()
eventId = 3
Reserved
eventNPT = 0
privateDataLength = dataLen()
commandTag = 0x05
sequenceNumber = 0
finalFlag = 1
privateDataPayload = someBase,
x-sbtvd://c:/nclRepository/weather,
1,1,2
FCS = checksum()

Figura F.1 Exemplo de uma transmisso de documento NCL em carrossel DSM-CC.
Um carrossel de objetos deve ento ser gerado (domnio de servio = 1,
na Figura F.1), carregando todo o contedo do programa interativo (arquivo
.ncl e todos os arquivos de mdia) e tambm um objeto de eventos (moduleId
= 2 e objectKey = 2, de acordo com a Figura F.1) mapeando o nome
nclEditingCommand para o valor de eventId (valor 3 na Figura F.1).
Um descritor de evento de fluxo tambm deve ser transmitido com o
valor de eventId apropriado, no exemplo 3, e o valor 0x05 de
commandTag, que indica um comando addDocument (ver Captulo 16). O
parmetro uri conter opcionalmente o esquema (no caso x-sbtvd,
indicando o recebimento no carrossel) e o caminho absoluto do documento
NCL (C:\nclRepository\weather de acordo com Figura F.1). Finalmente, o
IOR do documento NCL no carrossel de objetos transportado no parmetro
xmlDocument (carouselId = 1, moduleId = 1, objectKey = 2, tambm de
acordo com a Figura F.1).
Note que os pares {uri, id} transportados nos descritores de evento so
suficientes para que a identificao dos recursos da aplicao no dispositivo
receptor possa ser feita de forma idntica quela realizada no ambiente de
autoria do documento, a despeito de os identificadores dos recursos usarem
URLs absolutas ou relativas e de um carrossel de objetos usados no
transporte fazer referncia a recursos transportados em outro carrossel. Por
exemplo, a aplicao weatherConditions.ncl poderia se referir ao arquivo
brazilianMap.jpg de forma absoluta ou relativa. Mais ainda, a aplicao
poderia se referir a um contedo armazenado em um provedor de contedos
diferente do da aplicao, que dever, ento, ser transportado em um
509
carrossel de objetos diferente daquele que transporta a aplicao. O
mapeamento para a localizao dos recursos realizado automaticamente
pelo gerenciador de bases privadas.
F.3 Transporte de Comandos de Edio Usando
Estruturas Especficas Definidas pelo Ginga-NCL
Na Seo F.2 discutimos o transporte de parmetros de comandos de
edio em sees MPEG-2 transportando carrossis de objetos. Nesta seo
discutiremos o uso de outras estruturas para transporte desses parmetros
[ABNT, NBR 15606-2, 2011].
Descritores de evento podem ser enviados em fluxo elementar MPEG-2
TS usando eventos de fluxo DSM-CC, como vimos na seo anterior, como
tambm usando qualquer protocolo para transmisso de dados sem solicitao
(pushed data).
Trs tipos de estrutura de dados so definidos [Soares et al., 2006] para
dar suporte transmisso de parmetros dos comandos de edio NCL, alm
da estrutura de descritor de evento j definida: mapa, metadados e arquivos de
dados.
Para estruturas de mapa, o campo mappingType identifica o tipo do
mapa. Se o valor de mappingType for igual a 0x01 (events), um mapa de
eventos caracterizado. Nesse caso, depois do campo mappingType, vem
uma lista de identificadores de eventos, como definido na Tabela F.2. Outros
valores para o campo mappingType podem ser definidos, mas no so
relevantes para nossa discusso.
Tabela F.2 Lista de Identificadores de Eventos Definidos pela Estrutura de Mapa
Sintaxe Nmero de Bits
mappingStructure ( ) {
mappingType 8
for (i=1; i<N; i++){
eventId 8
eventNameLength 8
eventName 8 to 255
}
}
510
Mapas do tipo events (mapas de eventos) so usados para mapear
nomes de eventos em eventIds dos descritores de evento. Mapas de eventos
so usados para indicar quais eventos devem ser recebidos (qualquer
semelhana com a funo dos objetos de eventos de fluxo DSM-CC no
mera coincidncia). Nomes de eventos permitem especificar tipos de eventos,
oferecendo maior nvel de abstrao s aplicaes. Assim, quando precisamos
enviar um comando de edio NCL, devemos criar um mapa de eventos,
mapeando a string nclEditingCommand em um eventId previamente
selecionado de um descritor de evento. Um ou mais descritores de evento com
o eventId previamente selecionado devero ser criados e enviados. Esses
descritores de evento podem ter os seus tempos de referncia como zero ou
podem ter sua execuo postergada para um tempo especificado. O
gerenciador de bases privadas de um sistema receptor deve se registrar como
ouvinte de um evento nclEditingCommand para ser notificado da chegada
desse tipo de evento.
Cada estrutura arquivos de dados de fato o contedo de um arquivo
que compe uma aplicao NCL ou um documento XML definindo uma
entidade NCL: um arquivo contendo a especificao XML da aplicao ou
entidade NCL, ou um dos arquivos com contedo de mdia da aplicao ou de
um n NCL (vdeo, udio, texto, imagem, ncl, lua etc.).
Uma estrutura de metadados um documento XML, como definido no
esquema a seguir. Note que o esquema define, para cada dado entregue sem
solicitao (pushed file), uma associao entre sua localizao no sistema de
transporte (identificao do sistema de transporte atributo component_tag
e a identificao do arquivo no sistema de transporte atributo
structureId) e seu identificador de recurso universal (atributo uri).

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:NCLSectionMetadataFile="http://www.ncl.org.br/
NCLSectionMetadataFile"
targetNamespace="http://www.ncl.org.br/NCL3.0/
NCLSectionMetadataFile"
elementFormDefault="qualified" attributeFormDefault="unqualified" >

<complexType name="NCLSectionMetadataType">
<sequence>
511
<sequence>
<element ref="NCLSectionMetadataFile:baseData"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<element ref="NCLSectionMetadataFile:pushedRoot"
minOccurs="0" maxOccurs="1"/>
<sequence>
<element ref="NCLSectionMetadataFile:pushedData"
</sequence>
</sequence>
<attribute name="name" type="string" use="optional"/>
<attribute name="size" type="positiveInteger" use="optional"/>
</complexType>

<complexType name="baseDataType">
<sequence>
<element ref="NCLSectionMetadataFile:pushedRoot"
minOccurs="0" maxOccurs="1"/>
<sequence>
<element ref="NCLSectionMetadataFile:pushedData"
</sequence>
</sequence>
<attribute name="uri" type="anyURI" use="required"/>
</complexType>

<complexType name="pushedRootType">
<attribute name="component_tag" type="positiveInteger"
use="optional"/>
<attribute name="structureId" type="string" use="required"/>
</complexType>

<complexType name="pushedDataType">
<attribute name="component_tag" type="positiveInteger"
use="optional"/>
<attribute name="structureId" type="string" use="required"/>
</complexType


<element name="metadata"
type="NCLSectionMetadataFile:NCLSectionMetadataType"/>
<element name="baseData"
type="NCLSectionMetadataFile:baseDataType"/>
<element name="pushedRoot"
type="NCLSectionMetadataFile:pushedRootType"/>
<element name="pushedData"
type="NCLSectionMetadataFile:pushedDataType"/>

</schema>
Para cada arquivo de documento NCL ou outros arquivos de documento
XML usados nos comandos de edio addDocument ou addNode, pelo menos
uma estrutura de metadados deve ser definida. Apenas um arquivo de
aplicao NCL ou um arquivo de documento XML representando um n
NCL a ser inserido pode ser definido por estrutura de metadados. Mais
precisamente, pode haver apenas um elemento <pushedRoot> em um
512
documento XML representando o metadados. Contudo, uma aplicao NCL
(e seus arquivos de contedo) ou um documento de especificao de um n
NCL (e seus arquivos de contedo) pode se estender por mais de uma
estrutura de metadados. Mais ainda, podem existir estruturas de metadados
sem qualquer aplicao NCL ou documento XML descritos em seus
elementos <pushedRoot> e <pushedData>.
As trs estruturas anteriormente definidas podem ser transmitidas
usando sistemas de transporte diferentes, como exemplificado no que se
segue.
F.3.1 Transporte em um Tipo Especfico de Seo MPEG-2
O uso de um tipo especfico de seo MPEG-2 (identificado por um
valor especfico do campo table_id de uma seo privada MPEG-2, conforme
apresentado no Apndice B), a partir de agora chamada de seo NCL, nos
permite transmitir as trs estruturas de dados anteriormente definidas: mapas,
metadados e arquivos de dados.
Cada Seo NCL pode conter os dados de apenas uma estrutura.
Contudo, uma estrutura pode se estender por vrias sees. Estruturas de
dados podem ser transmitidas em qualquer ordem e quantas vezes forem
necessrias.
O comeo de uma estrutura de dados delimitada pelo campo
payload_unit_start_indicator de um pacote TS. Depois dos quatro bytes do
cabealho TS, a carga (payload) do pacote TS comea, com um campo
ponteiro de um byte indicando o incio de uma seo NCL [ISO/IEC 13818-1,
2000]. O cabealho da seo NCL ento definido como uma seo MPEG-2
[ISO/IEC 13818-1, 2000]. O primeiro byte da carga (payload) da seo NCL
identifica o tipo da estrutura transportada (0x01 para metadatos; 0x02 para
arquivos de dados e 0x03 para mapa de eventos). O segundo byte carrega um
identificador nico da estrutura (structureId) no fluxo elementar de
transporte.
2

Depois do segundo byte vem uma estrutura de dados serializada que
pode ser a mappingStructure (como ilustrado pela Tabela F.2) ou a estrutura
de matadados (um documento XML), ou uma estrutura de arquivos de dados

2
O fluxo elementar e o identificador da estrutura so aqueles que devem ser associados pela estrutura
de metadados, atravs dos atributos component_tag e structureId dos elementos <pushedRoot> e
<pushedData>, a localizadores de arquivos (URL).
513
(um contedo de arquivo serializado). O demultiplexador de sees NCL
responsvel por montar toda a estrutura da aplicao no dispositivo receptor.
3

No mesmo fluxo elementar que carrega a especificao XML (o arquivo
do documento NCL ou outro documento XML usado nos comandos de
edio) recomendado que um arquivo mapa de eventos seja transmitido,
para que seja mapeado o nome nclEditingCommand no eventId do
descritor de evento que dever transportar os comandos de edio, como
descrito no Captulo 16. O campo privateDataPayload do descritor de evento
deve carregar o par de referncias {uri, id}, como sempre. Os parmetros uri
tm sempre o valor null. No caso dos comandos addDocument e addNode,
o parmetro id do primeiro par deve identificar o fluxo elementar
(component_tag) e a estrutura de metadados que ele transporta
(structureId). A estrutura de metadados, por sua vez, contm o caminho
absoluto do documento NCL ou da especificao do n NCL (o caminho no
servidor de dados) e a estrutura arquivos de dados relacionada (structureId)
transportada em sees NCL do mesmo fluxo elementar. Se outras estruturas
de metadados adicionais forem necessrias para completar os comandos de
edio addDocument ou addNode, outros pares {uri, id} devem estar
presentes no comando. Nesse caso, os parmetros uri devem tambm ter o
valor null e os parmetros id correspondentes devem referir-se ao
component_tag e estrutura de metadados transportada (structureId)
correspondente.
A Figura F.2 ilustra um exemplo de transmisso de um documento NCL
atravs de sees NCL. Nesse exemplo, um provedor de contedo quer
transmitir um programa interativo chamado weatherConditions.ncl,
armazenado em um de seus servidores de dados (sistema de arquivo local na
Figura F.2). Um fluxo elementar MPEG-2 (component_tag= 0x09) deve
ento ser gerado, carregando todo o contedo do programa interativo (o
arquivo ncl e todos os arquivos de contedo de mdia). Um mapa de eventos
tambm deve ser gerado (structureType=0x03; structureId=0x0C, na
Figura F.2), mapeando o nome nclEditingCommand ao valor de eventId
(valor 3, Figura F.2). Um descritor de evento tambm deve ser transmitido,
com o valor apropriado para eventId, no exemplo o valor 3, e o valor de
commandTag igual a 0x05, que indica um comando addDocument (veja
Captulo 16). O parmetro uri deve ter o valor null e o parmetro id deve
ter o valor (component_tag= 0x09, structureId= 0x0B), como na Figura
F.2.

3
importante salientar que sees NCL podem tambm transportar as estruturas de dados definidas
encapsuladas em outras estruturas de dados. Por exemplo, o MPE (Multi-protocol Encapsulation) pode ser
usado. Nesse caso, sees NCL seriam sees MPEG-2 de datagrama. Mais ainda, todas as estruturas de
dados mencionadas podem ser envelopadas em outro formato de dados de protocolo, como, por exemplo,
pacotes FLUTE.
514
C:\nclRepository
weather
images
brazilianMap.png
Descritor de Evento
descriptorTag = 0
descriptorLenght= descriptorLen ()
eventId= 3
Reserved
eventNPT = 0
privateDataLenght=dataLen()
commandTag= 0x05
Sequence number= 0
finalFlag= 1
privateDataPayload= someBase,
null, 0x09, 0x0B
FCS = checksum()
<metadata name=weatherConditions size= 110kb>
<baseData uri=file://c:/nclRepository/ weather/
<pushedRoot structureId=0x0A uri=weatherConditions.ncl
size=10kb/>
<pushedData structureId=0x09 uri=../images/brazilianMap.png
size=100kb/>
</baseData>
</metadata>
Estrutura de Metadados
Arquivo Mapa de Eventos
eventId = 3
eventNameLength = 0x0C

Figura F.2 Exemplo de transmisso de documento NCL usando sees NCL MPEG-2.
F.3.2 Transporte das Estruturas de Metadados como
Parmetro de Comandos de Edio
Uma alternativa ao transporte de estruturas de metadados diretamente
em sees NCL tratar essas estruturas como parmetros dos comandos
addDocument and addNode, transportados no campo privateDataPayload
dos descritores de evento.
Nesse caso, o conjunto de pares {uri, id} dos comandos addDocument e
addNode substitudo por parmetros da estrutura de metadados, que
definem um conjunto de pares {uri, component_tag, structureId} para
cada arquivo transmitido sem solicitao (pushed file).
Voltando ao exemplo da Figura F.2, o novo transporte seria exatamente
o mesmo, com exceo do descritor de evento. Em vez de esses descritores
terem o par {uri; id} igual ao valor {null; 0x09, 0x0B} como parmetro,
eles teriam a estrutura de metadados serializada. Na estrutura de metadados,
os atributos component-tag dos elementos <pushedRoot> e <pushedData>
devem, nesse caso, ser definidos, uma vez que a estrutura no mais
transportada no mesmo fluxo elementar que transporta os arquivos da
aplicao NCL.
515
F.3.3 Transporte de Estruturas de Metadados em Sees
de Metadados MPEG-2
Uma outra alternativa transportar as estruturas de metadados em
sees de metadados MPEG-2, transportadas em fluxos MPEG-2 do tipo
0x16 [ISO/IEC 13818-1, 2000]. Como sempre, cada seo de metadados
MPEG-2 poder conter dados de apenas uma estrutura de metadados.
Contudo, uma estrutura de metadados pode se estender por vrias sees de
metadados.
A Tabela F.3 ilustra a sintaxe da seo de metadados para o transporte
de estruturas de metadados, que devem estar de acordo com ISO/IEC 13818-
1, 2000.
Tabela F.3 Sintaxe da Seo para o Transporte de Estruturas de Metadados
Sintaxe N. de Bits Valor
Metadata section() {
table_id 8 0x06
section_syntax_indicator 1 1
private_indicator 1 1
random_access_indicator 1 1
decoder_config_flag 1 0
metadata_section_length 12 Inteiro
metadata_service_id 8 Inteiro
reserved 8
section_fragment_indication 2 De acordo com
a Tabela F.4
version_number 5 Inteiro
current_next_indicator 1 1
section_number 8 Inteiro
last_section_number 8 Inteiro
structureId 8 Inteiro
For (i=1; i< N; i++) {
serialized_metadata_structure_byte 8
}
CRC_32 32
}
516
Tabela F.4 Indicao de Fragmento de Seo
Valor Descrio
1
1
Uma nica seo de metadados carregando uma estrutura de metadados
completa.
1
0
Primeira seo de metadados de uma srie, com dados de uma mesma estrutura
de metadados.
0
1
ltima seo de metadados de uma srie, com dados de uma mesma estrutura
de metadados.
0
0
Uma seo de metadados de uma srie, com dados de uma mesma estrutura de
metadados, mas que no nem a primeira nem a ltima seo.
Como anteriormente, no mesmo fluxo elementar que transporta a
especificao XML (o arquivo do documento NCL ou um outro arquivo
XML usados nos comandos de edio), devemos transmitir um arquivo mapa
de eventos a fim de mapear o nome nclEditingCommand ao eventId do
descritor de evento que carregar o comando de edio. No caso dos
comandos addDocument e addNode, o campo privateDataPayload do
descritor de evento deve transportar um conjunto de pares de referncia {uri,
id}. Os parmetros uri devem ter o valor null. No caso de comandos
addDocument e addNode, o parmetro id do primeiro par deve identificar o
fluxo elementar (component_tag) do tipo= 0x16 e a estrutura de
metadados (structureId) que carrega o caminho absoluto do documento
NCL ou da especificao do n NCL (o caminho no servidor de dados). Se
outras estruturas de metadados forem usadas para relacionar arquivos
presentes no documento NCL ou na especificao do n NCL, a fim de
completar os comandos addDocument ou addNode com contedos de mdia,
outros pares de referncia {uri, id} devem ser definidos no comando. Nesse
caso, o parmetro uri deve ter o valor null, e o parmetro id correspondente
no par deve referir-se ao component_tag e ao structureId do metadado
correspondente.
Voltando ao exemplo da Figura F.2, com a nova estrutura de
transmisso tudo seria similar. Devemos fazer apenas pequenas mudanas, de
forma que o descritor de evento refira o fluxo elementar e sua seo que
carrega a estrutura de metadados (component_tag= 0x08 e structureId=
0x0B), e que a estrutura de metadados tambm refira o fluxo elementar
onde os arquivos do documento sero transportados. A Figura F.3 ilustra a
nova situao.
517
C:\nclRepository
weather
images
brazilianMap.png
Descritor de Eventos
descriptorTag = 0
descriptorLenght= descriptorLen ()
eventId= 3
Reserved
eventNPT = 0
privateDataLenght=dataLen()
commandTag= 0x05
Sequence number= 0
finalFlag= 1
privateDataPayload= someBase,
null, 0x08, 0x0B
FCS = checksum()
<metadata name=weatherConditions size= 110kb>
<baseData uri=file://c:/nclRepository/ weather/
<pushedRoot component_tag= 0x09 structureId=0x0A
uri=weatherConditions.ncl size=10kb/>
<pushedData component_tag= 0x09 structureId=0x09
uri=../images/brazilianMap.png size=100kb/>
</baseData>
</metadata>
Estrutura de Metadados
Arquivo Mapa de Eventos
eventId = 3
eventNameLength = 0x0C

Figura F.3 Exemplo de transmisso de documento NCL usando sees de metadados
MPEG-2.
Bibliografia
ISO/IEC 13818-6 (1998). International Organization for Standardizatio
International Eletrotecnical Committee, Information Technology
Generic coding of moving pictures and associated audio information, Part
6: Extensions for DSM-CC, ISO/IEC 13818-6.
Soares, L.F.S. e Rodrigues, R.F.; Costa, R.R; Moreno, M. (2006). Nested
Context Language 3.0 Part 9 NCL Live Editing Commands.
PUC-Rio, N. 35/06. Rio de Janeiro, dezembro de 2006. ISSN 0103-9741.

518
Apndice G

HTG
A apresentao com qualidade de uma aplicao NCL depende de uma srie
de procedimentos de escalonamento que devem ser realizados tanto pelos
receptores quanto pelos provedores de contedo das aplicaes.
Para a realizao desses procedimentos, estruturas de dados especficas
devem ser computadas. Este apndice traz uma discusso a respeito dessas
estruturas de dados e de como elas podem ser deduzidas de uma outra
estrutura de dados nica chamada HTG (Hypermedia Temporal Graph).

519
G.1 Escalonadores
Como j discutimos em diversas parte do livro, nas aplicaes em que o
sincronismo depende da ocorrncia de eventos com durao varivel ou
mesmo imprevisvel no momento da especificao, imperativo que essa
especificao seja realizada de forma relativa ocorrncia desses eventos,
isto , independentemente do momento temporal em que eles ocorrem e se de
fato eles ocorrerem. nesse paradigma orientado a eventos que se baseia a
linguagem NCL e a sua linguagem de script Lua.
Quando o sincronismo especificado de forma relativa, os instantes
temporais de ocorrncia dos eventos somente sero conhecidos na fase de
execuo da aplicao.
O uso do paradigma orientado a eventos traz no s o problema de
como especificar relacionamentos temporais e espaciais entre eventos,
solucionados pelo uso de NCL, como dois outros problemas adicionais:
1) como controlar a execuo de uma aplicao de forma a garantir que os
relacionamentos especificados sejam respeitados;
2) como gerenciar as transmisses, dos servidores de contedos para os
clientes receptores, mantendo uma qualidade de servio tal que garanta que os
contedos estejam presentes no receptor nos momentos necessrios de suas
apresentaes.
O primeiro problema diz respeito apenas aos receptores das aplicaes e
vai exigir o trabalho complementar de dois escalonadores na implementao
do formatador NCL.
O primeiro escalonador (escalonador de exibidores) responsvel por
instanciar os vrios exibidores de mdia, de forma que eles estejam prontos
nos momentos necessrios apresentao dos vrios objetos. Esse trabalho
no simples porque, devido limitao de memria da maioria dos
dispositivos receptores para TV, importante manter o mnimo de
componentes exibidores instanciados ou mesmo na memria principal (RAM)
do receptor.
O segundo escalonador (escalonador de apresentao) o ncleo
central do formatador, sendo responsvel por entregar os contedos a serem
apresentados pelos exibidores de mdia em um dado instante. Em outras
palavras, esse escalonador que de fato resolve todos os relacionamentos de
sincronismo temporal em tempo de execuo, transformando os tempos
relativos dos relacionamentos em tempos absolutos.
Entre os vrios problemas que deve tratar, o escalonador de
apresentao deve permitir que uma aplicao inicie a partir de qualquer
ponto de sua cadeia temporal de exibio de objetos. Isso muito importante
em aplicaes para TV digital, por exemplo, na qual um servio ou canal
520
pode ser sintonizado em qualquer instante de tempo de um programa de TV.
O escalonador deve tambm permitir que uma aplicao sofra operaes de
pausa e retomada, que exigem que ela prossiga, mesmo em um instante
temporal posterior ao da pausa. Esse tipo de operao comum quando o
usurio troca e, em seguida, retorna ao mesmo canal (ou servio) de TV.
Para enfrentar o segundo problema, o gerenciamento das transmisses,
devemos definir procedimentos, tanto nos provedores de contedo quanto nos
clientes receptores. Esses procedimentos dependem de os dados serem
recebidos sem solicitao (pushed data) ou sob demanda (pulled data).
No caso de dados recebidos sem solicitao, eles so geralmente
enviados ciclicamente (em carrossel), como discutido em detalhes no
Apndice F. A colocao e a retirada dos dados no carrossel e em qual
posio do carrossel so fundamentais para diminuir a banda necessria para
transmisso dos dados e para garantir que eles estaro presentes no receptor
quando necessrio. O escalonador de carrossel o responsvel por essas
tarefas nos provedores de contedo.
Do lado do cliente receptor, um escalonador de pr-busca necessrio
para retirar, nos momentos precisos, dados dos carrossis e carreg-los na
memria do receptor. Esse escalonador tambm responsvel por requisitar
dados sob demanda, de forma a garantir sua presena no dispositivo receptor
quando necessrio. Devemos notar, mais uma vez, que devido usual
limitao de memria dos dispositivos receptores importante manter o
mnimo de contedos de mdia na memria principal. Para busca desses
dados, pode ser necessria a negociao de QoS (Quality of Service) na rede.
Nesse caso, um escalonador de negociao de QoS responsvel pela
tarefa, garantindo a reserva de recursos na rede quando o escalonador de pr-
busca requisitar os dados.
Para dar suporte realizao das tarefas executadas pelos diversos
escalonadores mencionados, vrias estruturas de dados so computadas a
partir da especificao da aplicao NCL. Na implementao de referncia do
middleware Ginga, elas so baseadas e derivadas de uma estrutura de dados
nica, denominada Hypermedia Temporal Graph ou HTG.
G.2 Hypermedia Temporal Graph (HTG)
Para controlar o comportamento temporal das aplicaes durante a sua
execuo, o Ginga-NCL adota uma estrutura formada por grafos
direcionados (dgrafos). Essa estrutura, conhecida como Hypermedia
Temporal Graph ou HTG[Costa et al., 2008; Moreno et al., 2008], oferece
suporte ao incio ou retomada sncrona da apresentao a partir de um
instante de tempo qualquer.
521
No HTG, cada vrtice representa uma transio de estado de um evento.
Os eventos representados nessa estrutura so os mesmos definidos na NCL,
ou seja, os eventos de apresentao, seleo e atribuio, cada um controlado
por uma mquina de estados, repetida por comodidade de leitura na Figura
G.1.
paused
sleeping occurring
resume
stop | abort
pause
stop| natural end
abort
start

Figura G.1 Mquina de estado de um evento.
O grafo temporal obtido atravs da modelagem de uma aplicao deve
preservar todos os relacionamentos entre os eventos, sejam eles previsveis ou
imprevisveis, bem como o estado atual de cada mquina de estados associada
a um evento.
No HTG, as arestas entre os vrtices representam os relacionamentos
entre as transies de estados dos eventos. Cada aresta possui uma condio
associada que deve ser satisfeita para que a transio, representada pelo seu
vrtice de destino, seja disparada. Em resumo, os grafos nessa estrutura so
definidos por um conjunto de vrtices, arestas e condies de caminhamento
(V, A, C), onde:
- V = (v0, v1, v2, v3, ..., vn 1) um conjunto finito de vrtices, em que
cada vrtice representa uma transio na mquina de estados associada a
um evento. Cada vrtice representado por uma tripla: o nome da ao
que dispara a transio, o tipo de evento correspondente e o identificador
da ncora que identifica o objeto ou parte de seu contedo (se o evento
do tipo apresentao ou seleo) ou o identificador nico da propriedade e
seu valor (se for um evento de atribuio);
- A = (a0, a1, a2, a3, ..., am 1) um conjunto finito de arestas que
representam, individualmente, um relacionamento entre transies. Para
cada aresta a, v e w so os vrtices de origem e destino, respectivamente
((v, w) e V x V);
- C = {cij} um conjunto finito de condies associadas s arestas. Uma
condio cij associada com a aresta (vi, vj) e A e deve ser satisfeita
para que o disparo do vrtice (disparo da transio) destino da aresta
considerada seja realizado.
522
As condies podem ser simples ou compostas. Uma condio simples
definida por:
- um intervalo temporal que deve ser obedecido para que a transio,
representada no vrtice destino da aresta, seja executada;
- uma varivel que pode ser testada em relao a um valor desejado,
inclusive (e na maioria das vezes) variveis cujo valor so intervalos
temporais;
- aes externas aplicao, como as interaes do usurio.
Condies compostas so definidas atravs de operadores lgicos (OR,
AND, NOT), relacionando duas ou mais condies (simples ou compostas).
Para exemplificar o uso dos grafos temporais, considere a mesma
aplicao apresentada na Seo 3.6 do Captulo 3, cuja viso estrutural
apresentada na Figura G.2.
onBegin
Start
Stop
onBegin
Start
onBegin
Start
Start
onEnd
Stop
Set
size
Start
onSelection
Set
size
onBegin
Start
Stop
onEnd
Start

Figura G.2 Viso estrutural da aplicao O Primeiro Joo.
Recordando o Captulo 3, ao iniciar a animao propriamente dita da
aplicao O Primeiro Joo, logo aps um pequeno trecho de prefcio do
vdeo, iniciada uma msica de fundo e o pano de fundo de toda a exibio.
Em um trecho da aplicao apresentado um vdeo com o drible semelhante
quele em exibio no vdeo da animao. Mais adiante, uma foto de um
jogador cado, aps receber um drible, apresentada, tambm sincronizada
com o vdeo da animao. Um pouco mais frente exibido um cone de uma
chuteira que, se selecionado, exibe um vdeo de propaganda e uma pgina
HTML para que a compra seja realizada. A ao interativa provoca tambm
o redimensionamento do vdeo principal, que volta ao seu tamanho original
aps um certo tempo, em que tanto o vdeo da propaganda como o formulrio
523
HTML j terminaram (na verdade, volta ao tamanho original ao final da
apresentao do formulrio). A aplicao NCL para esse exemplo pode ser
revisitada na Listagem 3.22. Recomenda-se a leitura dessa listagem,
principalmente para entender alguns dos tempos especificados no grafo.
A Figura G.3 apresenta o grafo resultante da modelagem do exemplo da
Figura G.2. Para simplificar a figura, a descrio dos eventos de apresentao
foi suprimida nas triplas que definem os vrtices.
1 21
(start, animation)
4
2
5
11
10
7
8
6
a
n
i
m
a
t
i
o
n
D
u
r
=
1
2

s
anim
ationD
ur = 45 s
anim
ationDur =
41 s
d
e
l
a
y
L
M
u
s
i
c
D
u
r
=
5

s
3
9
dribleDur = 5 s
photoDur = 6 s
d
e
l
a
y
L
M
u
s
i
c
D
u
r
=
5

s
0 s
0 s
(start, segDrible)
(start, segPhoto)
(start, drible)
(natural end, drible)
(start, segIcon)
(natural end, photo)
(natural end, animation)
0 s
(start, background)
(start, choro)
(stop, background)
(natural end | stop, icon)
23
22
(stop, choro)
animationDur = 01:10 s
13 (start, icon)
14
Ao interativa
(start, selection, icon)
15 (start, attribution, bounds=V1)
0 s
0

s
16
17
0 s
(start, shoes)
(start, ptForm)
18
0 s
19
(natural end, shoes)
(natural end, ptForm)
20
ptformDur = 15 s
shoesDur = 13 s
(start, attribution, bounds=V2)
0
s
iconDur = 6 s
choroDur = indeterminado
backgroundDur = indeterminado

Figura G.3 Grafo temporal da aplicao O Primeiro Joo.
Na Figura G.3, o vrtice 1 o ponto de entrada da aplicao e
representa a transio de incio da apresentao do vdeo da animao.
Passados cinco segundos do incio da animao (delay especificado no elo
lMusic na Listagem 3.22 do Captulo 3), disparada a transio de incio
dos objetos de mdia background (vrtice 2) e choro (vrtice 3).
Decorridos 12 segundos a partir do incio do vdeo da animao, uma de
suas ncoras (elemento <area id=segDrible>) iniciada (vrtice 4). A
transio de incio dessa ncora dispara a transio de incio do objeto de
mdia drible, representada pelo vrtice 5, cuja durao de apresentao de
cinco segundos.
Nesse ponto temos vrios pontos a observar. Note que alguns intervalos
de tempo (por exemplo, 0 segundos) foram especificados diretamente como
524
condio de percurso de uma aresta, e outros como valores de variveis de
condies para o percurso, por exemplo delayLMusicDur=5s e
animationDur=12s. A diferena que certos intervalos de tempo podem ser
pausados, por efeito de aes de pausa em um objeto de mdia (caso do
intervalo animationDur) ou em objetos de composio.
Voltando ao nosso exemplo, decorridos 41 segundos a partir do incio do
vdeo da animao, outra de suas ncoras (elemento <area id=segPhoto>)
iniciada (vrtice 7). A transio de incio dessa ncora dispara a transio de
incio do objeto de mdia photo, representada pelo vrtice 8, cuja durao
de apresentao de seis segundos.
De forma anloga, decorridos 45 segundos a partir do incio do vdeo da
animao, outra de suas ncoras (elemento <area id=segIcon>) iniciada
(vrtice 10), o que causa o disparo da transio de incio do objeto de mdia
icon, representada pelo vrtice 11, indicando ao usurio a possibilidade de
interao com a aplicao. Se a apresentao desse objeto de mdia no
interrompida, ele tem seu fim natural aps decorridos seis segundos, conforme
representado pelo vrtice 13.
O vrtice 14 representa a transio de incio do evento de seleo. A
aresta, que relaciona esse vrtice com o vrtice 11, tem como condio a ao
de interatividade do usurio. O leitor deve notar que um nico grafo
utilizado para representar toda a aplicao e que, durante a apresentao,
podem ser retiradas partes desse grafo quando os eventos imprevisveis que
ligam essas partes ao restante do grafo no puderem mais ser disparados. No
contexto do nosso exemplo, se o usurio no realizar a ao interativa at o
fim da apresentao do objeto de mdia icon, representado pelo vrtice 13,
os eventos representados no grafo a partir do vrtice 14 nunca iro ocorrer.
Note, assim, que o HTG um grafo dinmico.
A partir da ocorrncia do evento interativo (vrtice 14), a disposio
espacial do objeto de mdia animation alterada (vrtice 15, propriedade
bounds=V1), e so iniciadas as exibies do vdeo de propaganda shoes
(vrtice 16) e do formulrio XHTML (vrtice 17). Note tambm que a
ocorrncia do evento interativo (vrtice 14) leva interrupo da
apresentao do cone de interao (vrtice 13).
Nesse ponto devemos fazer uma nova observao: as aes natural end
e stop so o nico caso de aes que podem levar a um mesmo vrtice, pois o
comportamento decorrente da entrada no estado sleeping ser indiferente a
qualquer um dos dois tipos de ao mencionados que levou a esse estado.
O objeto de mdia shoes tem seu fim natural aps 13 segundos de seu
incio (vrtice 18). O objeto de mdia ptForm tem seu fim natural aps 15
segundos de seu incio (vrtice 19). Ao trmino desse ltimo objeto, a
525
disposio espacial inicial do objeto de mdia animation restabelecida
(vrtice 20).
O leitor deve notar que foram criados dois vrtices (V15 e V20) para a
mesma propriedade (bounds), um para cada valor atribudo. Poderamos ter
criado apenas um vrtice, mas isso tornaria mais confuso o gerenciamento do
HTG, embora minimizasse o nmero de vrtices e arestas do grafo.
Finalmente, o trmino natural do vdeo de animao (vrtice 21) dispara
as transies de trmino do udio (choro) e do pano de fundo
(background), representadas pelos vrtices 22 e 23, respectivamente.
Terminando esta seo, cabe ressaltar que no exemplo da Figura G.1
exploramos apenas um tipo de no-determinismo, a interao do usurio.
Outros no-determinismos podem ocorrer; por exemplo, a resoluo de uma
regra de um elemento <switch> em tempo de execuo. Note que, nesse caso,
o no-determinismo pode ser representado por condies associadas s
arestas, tendo como variveis as regras.
G.2.1 Clculo das Duraes das Arestas
Durante a execuo das aplicaes, os exibidores de objetos de mdia
devem reportar todos os eventos, incluindo os no-determinsticos, para que
outros eventos relacionados possam ser disparados no HTG. O tempo de
exibio (media time) individual de cada objeto de mdia dever ser
controlado, uma vez que os eventos podem estar associados a trechos
especficos de seu contedo.
Para os contedos de mdia que estejam previamente disponveis junto
aos exibidores, o controle do tempo de exibio pode ser realizado
simplesmente verificando o tempo transcorrido a partir do incio de sua
exibio. Alm disso, estando os contedos previamente disponveis, seu
tempo total de durao (total media time) pode ser calculado. Ao contrrio,
para contedos entregues em tempo de exibio atravs de fluxos contnuos
(streaming), determinar o instante inicial do contedo ou seu tempo total de
exibio exige que o receptor esteja sintonizado desde o incio do fluxo ou,
ento, que mecanismos adicionais estejam disponveis.
Como discutido no Apndice E, um receptor pode comear a receber um
fluxo elementar, enviado sem solicitao, a partir de qualquer ponto temporal
do mesmo, uma vez que o instante de sintonizao qualquer um. Mais
ainda, usual que um fluxo elementar carregue mais de um contedo de
objeto de mdia. Por exemplo, um fluxo elementar de uma determinada
emissora de TV carrega um programa em sequncia do outro. Pior ainda, um
contedo pode ser entremeado por outro; por exemplo, quando uma
526

propaganda inserida no meio de um programa de TV. Tudo isso torna
impossvel saber em que instante de tempo estamos em um determinado
contedo, sem nenhum auxlio extra.
O Apndice E discute a soluo proposta pelo padro MPEG System
para o problema, por meio do uso de descritores de referncia NPT (Normal
Play Time). Atravs dos diferentes tipos de descritores, dos campos NPT e
contentId, possvel determinar o ponto exato de uma mdia.
G.3 Planos de Escalonamento
Tendo por base o HTG, as estruturas de dados para dar suporte aos
vrios escalonadores discutidos na Seo G.1 podem ser calculadas.
O conjunto de transies de eventos disparados sobre os objetos de uma
aplicao e os seus correspondentes momentos no tempo define o plano de
apresentao, a estrutura de suporte do escalonador de apresentao.
Aps modelar uma aplicao atravs de seu HTG, como apresentado no
exemplo da Figura G.3, os tempos para o disparo de seus eventos podem ser
estimados atravs do caminhamento nas arestas do grafo. Para aplicaes que
contm apenas eventos previsveis, os instantes para o disparo das transies
dos seus eventos podem ser totalmente calculados antes da execuo da
aplicao. Quando uma aplicao contm eventos imprevisveis, o clculo dos
instantes para o disparo das transies dos eventos tambm pode ser realizado
a priori; no entanto, nesse caso, alguns tempos de disparo sero computados
de forma relativa ocorrncia de um evento imprevisvel. Considerando o
exemplo apresentado na Figura G.3, os tempos dos eventos representados
pelos vrtices numerados de 15 a 20 so calculados com base no tempo da
ocorrncia do vrtice 14.
A Tabela G.1resume o plano de apresentao obtido a partir do grafo da
Figura G.3. Na tabela, as duas primeiras colunas representam os eventos que
no dependem da ao interativa, com exceo do evento de seleo. Nas
duas ltimas colunas encontram-se os eventos disparados a partir do evento
de seleo representado pelo vrtice 14. Como os tempos dessa coluna so
relativos ocorrncia do evento imprevisvel, seus tempos estimados esto
vinculados ao tempo da ocorrncia do evento imprevisvel.
527
Tabela G.1 Eventos do Plano de Apresentao
Incio, Apresentao, animation 70 s
Fim, Apresentao, icon (X+0)s
Incio, Apresentao, background 5 s Incio, Atribuio, bounds=V1
(X+0)s
Incio, Apresentao, choro 5 s Inicio, Apresentao, shoes
(X+0)s
Incio, Apresentao, segDrible 12 s Inicio, Apresentao, form
(X+0)s
Incio, Apresentao, drible 12 s Fim, Apresentao, shoes (X+13)s
Fim, Apresentao, drible 17 s Fim, Apresentao, form (X+15)s
Incio, Apresentao, segPhoto 41 s Incio, Atribuio, bounds=V2
(X+15)s
Incio, Apresentao, Photo 41 s
Incio, Apresentao, segIcon 45 s
Incio, Apresentao, icon 45 s
Incio, Seleo, icon X s
Fim, Apresentao, photo 47 s
Fim, Apresentao, icon 51 s
Fim, Apresentao, animation 70 s
Fim, Apresentao, choro 70 s
Fim, Apresentao, background 70 s
Com base no plano construdo, o escalonador de apresentao agora
capaz de entregar aos exibidores, no momento preciso, os contedos a serem
exibidos.
A partir do plano de apresentao, as operaes de incio/retomada da
exibio de uma aplicao NCL podem ser realizadas simplesmente
desprezando-se os eventos no-determinsticos que poderiam ter ocorrido
antes do tempo em que se pretende iniciar/retomar a apresentao, mas
levando em considerao todos os que de fato ocorreram, no caso de retomada
da exibio.
Voltemos ao nosso exemplo. Vamos considerar que estamos recebendo o
vdeo da animao como o vdeo principal do programa da emissora e que
estamos recebendo os outros objetos por datacasting. Conforme vimos no
Captulo 16, comandos de edio addDocument e startDocument so tambm
enviados ciclicamente aos receptores. Assim, ao sintonizar um canal, o
receptor passa a receber os fluxos elementares do fluxo de transporte,
incluindo os objetos de mdia transmitidos por datacasting, os descritores
NPT (ver Apndice E) e os comandos de edio (ver Captulo 16).
O comando addDocument ser interpretado pelos receptores fazendo
com que a especificao da aplicao seja adicionada s suas bases privadas.
O comando startDocument gera uma notificao ao formatador NCL, que
528
passa a construir o grafo temporal (HTG). Com o grafo construdo, o plano
de apresentao calculado.
Vamos agora supor que a sintonizao se deu durante a exibio da
animao, mas 43 segundos aps o seu comeo. Note que o middleware pode
calcular esse valor pela monitorao de descritores NPT. O escalonador de
apresentao ento informado desse tempo. De posse do valor, o
escalonador posiciona a aplicao nesse instante temporal do plano de
apresentao. No caso especfico do exemplo, o usurio ainda poderia
realizar a ao interativa e ser capaz de ter a foto (elemento de mdia photo)
exibida por quatro segundos (e no seis segundos, como na especificao para
a aplicao comeando do tempo zero).
O leitor deve notar que o mesmo procedimento pode ser utilizado para
operaes de pausa e retomada, com mudana intermediria de canal. Ao se
mudar o canal, a aplicao que estava executando entra em modo de espera
(stand by). Ao retornar ao canal, quando a base temporal for retomada
1

(quando voltar a receber o descritor NPT com o mesmo contentId, como
discutimos no Apndice E e no Captulo 9), a aplicao continua sua
execuo, a partir do ponto informado pelo valor do descritor NPT,
desconsiderando qualquer evento no-determinstico que poderia ter ocorrido
desde o momento de sua pausa at o momento de sua retomada.
Com base no plano de apresentao e levando em conta o tempo de
instanciao de cada exibidor, o plano de instanciao de exibidores pode ser
construdo. Esse plano a base para a operao do escalonador de exibidores,
conforme vimos na Seo G.1.
Tambm a partir do plano de apresentao, mas agora levando em conta
os retardos introduzidos pelo transporte dos vrios objetos de mdia at a
memria do receptor (retardos na rede, retardos de acesso ao carrossel etc.), o
plano de pr-busca pode ser construdo. Fundamentado nesse plano, base de
operao do escalonador de pr-busca e de retardos na reserva de recursos em
redes com QoS, planos de negociao de QoS podem ser calculados.
At agora focamos a construo do HTG do lado do cliente, isto , do
lado do receptor. Entretanto, para o controle da transmisso no-solicitada de
objetos de mdia, isto , para dar suporte ao escalonador de carrossel,
apresentado na Seo G.1, necessrio que o HTG seja tambm construdo
pelo provedor de datacasting. Tendo por base o HTG e alguma heurstica de
otimizao de banda passante e retardo de transmisso, o escalonador de
carrossel saber que objetos devem ser colocados em um carrossel para
transmisso cclica, quantas vezes deve ser colocado e em que posies.

1
Note que a base temporal pode ser retomada, mas no imediatamente aps o retorno ao canal, pois
no momento pode estar sendo exibido outro contedo, por exemplo, uma propaganda.
529
Bibliografia
Costa, R.R.; Moreno, M.F.; Soares, L.F.G. Intermedia Synchronization
Management in DTV Systems. Proceedings of the ACM Symposium on
Document Engineering. So Paulo, setembro de 2008, pp. 289-297.
ISBN: 978-1-60558-081-4.
Moreno, M.F.; Costa, R.R.; Soares, L.F.G.. Sincronismo entre Fluxos de
Mdia Contnua e Aplicaes Multimdia em Redes por Difuso. Anais do
XIV Simpsio Brasileiro de Sistemas Multimdia e Hipermdia, Vila
Velha, outubro de 2008, pp. 202-209. ISBN: 857669198-1.

530
Apndice H

Comportamento de
Exibidores
Para que no haja surpresa na execuo de uma aplicao declarativa NCL,
necessrio que o autor da aplicao saiba com preciso o comportamento do
formatador NCL e dos diversos exibidores de objetos de mdia envolvidos na
apresentao de um documento.
Este apndice apresenta a interpretao dada pelos vrios exibidores de mdia,
incluindo os objetos de mdia com cdigo imperativo e declarativo, a
comandos enviados pelo formatador NCL, a partir de aes determinadas nos
elementos <link> e tambm em alguns comandos de edio NCL. O apndice
tambm apresenta a interpretao dada pelo formatador quando as aes so
submetidas em ns de composio NCL (representados pelos elementos
<body>, <context> e <switch>).
1

1

531
H.1 Introduo
A apresentao de um documento NCL requer o controle da
sincronizao de vrios objetos de mdia (especificados atravs do elemento
<media>). Para cada objeto de mdia, um player (exibidor de mdia)
carregado para o controle do objeto e de seus eventos NCL. Um exibidor de
mdia (ou seu adaptador) deve ser capaz de receber os comandos de
apresentao, controlar (notificar) as mquinas de estado dos eventos do
objeto de mdia controlado e responder s demandas do formatador.
O comportamento dos exibidores de mdia e do formatador NCL so
apresentados nas Sees H2 e H3, respectivamente.
H.2 Comportamento dos Exibidores de Objetos de
Mdia No-Declarativos
Nesta seo discutiremos o comportamento para exibidores de objetos
de mdia, incluindo os objetos de mdia com cdigo imperativo, mas excluindo
os objetos de mdia cujo contedo um cdigo declarativo (objetos de mdia
declarativos). Esses ltimos so apresentados por exibidores de documentos,
que tm um comportamento semelhante ao formatador NCL, por isso so
discutidos em uma seo parte (Seo H.4). Afinal, o prprio formatador
NCL um exibidor de mdia declarativo para a linguagem NCL.
Um objeto de mdia em apresentao identificado pelo atributo id do
elemento <media> correspondente, e os atributos id dos elementos
<descriptor> que foram associados ao objeto de mdia. Por simplicidade,
chamaremos essa identificao de representationObjectId.
Eventos de Apresentao
H.2.1.1 Instruo start
Antes de enviar a instruo start, o formatador NCL encontra o exibidor
de mdia mais apropriado, com base no tipo de contedo a ser exibido. Para
tanto, o formatador leva em considerao o atributo player associado com o
objeto de mdia a ser exibido. Se esse atributo no for especificado, o
formatador leva em conta o atributo type do elemento <media>. Se esse
atributo tambm no for especificado, o formatador considera a extenso do
arquivo especificado no atributo src do elemento <media>.
532
A instruo start emitida por um formatador NCL informa ao exibidor
de mdia os seguintes parmetros: o localizador do contedo do objeto de
mdia a ser controlado, uma lista de todas as propriedades associadas ao
objeto de mdia, a identificao do objeto de mdia em apresentao
(representationObjectId), uma lista de eventos (apresentao, seleo ou
atribuio, definidos pelos elementos <area>, <property> e pelas ncoras de
contedo default do elemento <media>) que precisam ser monitorados pelo
exibidor de mdia, o evento de apresentao a ser iniciado (chamado evento
principal), um tempo de compensao (offset-time), opcional, e um tempo de
retardo, opcional. No caso de objetos de mdia imperativo, o evento de
apresentao a ser iniciado identificado pelo atributo label de suas ncoras
de contedo ou , por omisso (default), o evento associado ncora de
contedo principal.
O atributo src do elemento <media> usado, pelo exibidor de mdia,
para localizar o contedo e iniciar sua apresentao. Se o contedo no puder
ser localizado ou se o exibidor de mdia no souber como lidar com o tipo de
contedo, o exibidor de mdia encerra a operao de iniciao sem realizar
nenhuma ao.
Os descritores a serem utilizados so escolhidos pelo formatador
seguindo as diretrizes especificadas no documento NCL. Se a instruo start
resultar de uma ao de um elo que tenha um descritor explicitamente
declarado em seu elemento <bind> (atributo descriptor), o descritor resultante
informado pelo formatador mescla os atributos do descritor especificado pelo
<bind> com os atributos do descritor especificado no elemento <media>
correspondente, se esse atributo tiver sido especificado. Para atributos em
comum, a informao do descritor do <bind> sobrepe a do descritor do
<media>. Se o elemento <bind> no contiver um descritor explcito, o
descritor informado pelo formatador o descritor especificado pelo elemento
<media>, se o atributo tiver sido especificado. Caso contrrio, um descritor
default para o tipo de <media> especfico pode ser escolhido pelo formatador.
Baseado nesse procedimento, a lista dos ids dos descritores associados ao
objeto de mdia computada e, unificando as propriedades definidas no
descritor resultante com as propriedades explicitamente declaradas no
elemento <media> correspondente, a lista de propriedades associada ao objeto
de mdia avaliada.
A lista de eventos a serem monitorados por um exibidor de mdia
computada pelo formatador, levando em conta a especificao do documento
NCL. Para tanto, ele checa todos os elos dos quais participa o objeto de mdia
com o descritor resultante. Ao computar os eventos a serem monitorados, o
formatador considera a perspectiva do objeto de mdia, isto , o caminho a
partir do elemento <body> por vrios elementos <context> para alcanar em
profundidade o elemento <media> correspondente. Apenas os elos contidos
533
nesses elementos <body> e <context> so considerados na computao dos
eventos monitorados.
O parmetro offset-time opcional e tem zero como seu valor default.
O parmetro significativo somente para mdia contnua, ou esttica com
durao explcita. Nesse caso, o parmetro define um tempo de compensao,
desde o incio (beginning-time) do evento principal, a partir do qual a
apresentao desse evento imediatamente iniciada (isto , ele comanda o
exibidor para pular para o tempo de partida = beginning-time + offset-time).
Obviamente, o valor do offset-time deve ser menor que a durao do evento
principal. Caso contrrio, a instruo start ignorada.
Se o offset-time for maior que zero, o exibidor de mdia coloca o evento
principal no estado ocorrendo (occurring), mas a transio de incio (starts)
do evento no notificada. Se o offset-time for zero, o exibidor de mdia
coloca o evento principal no estado occurring e notifica a ocorrncia da
transio de incio. No caso de objetos de mdia que no so objetos
imperativos, os eventos que teriam seus tempos de trmino anteriores ao
tempo de incio do evento principal e os eventos que teriam seus tempos de
incio aps o tempo de trmino do evento principal no precisam ser
monitorados pelo exibidor de mdia (o formatador faz essa verificao quando
constri a lista de eventos monitorados).
Os eventos monitorados que teriam seus tempos de trmino aps o
tempo de incio do evento principal, mas antes do tempo de partida
(beginning-time + offset-time), tm seu atributo occurrences incrementado,
mas as transies de incio e trmino (stops) no so notificadas. Os eventos
monitorados que tm seu tempo de incio antes do tempo de partida
(beginning time + offset-time) e tempo de trmino aps o tempo de partida
so colocados no estado occurring, mas as transies de incio
correspondentes no so notificadas.
O tempo de retardo tambm um parmetro opcional, e seu valor
default tambm zero. Se maior que zero, esse parmetro contm um
tempo a ser esperado pelo exibidor de mdia antes de iniciar sua apresentao.
Com exceo dos objetos de mdia imperativos, se o exibidor receber
uma instruo de start para um objeto que j est sendo apresentado (pausado
ou no), ele ignora a instruo e mantm o controle da apresentao em
andamento. Nesse caso, o elemento <simpleAction> que causou a instruo
start no causa qualquer transio na mquina de estados do evento a ele
associado.
Diferentemente dos procedimentos realizados para os outros tipos de
elementos <media>, se um exibidor de objeto de mdia imperativo receber
uma instruo start para um evento associado a um elemento <area> e esse
evento estiver no estado sleeping, ele inicia a execuo do cdigo imperativo
534
associado ao elemento, mesmo se outra parte do cdigo imperativo do objeto
de mdia estiver em execuo (pausado ou no). Contudo, se o evento
associado ao elemento-alvo <area> estiver no estado occurring ou paused, a
instruo start ignorada pelo exibidor imperativo, que continuar
controlando a execuo anteriormente iniciada.
H.2.1.2 Instruo stop
No caso de objetos de mdia com cdigo imperativo, a instruo stop
precisa identificar um trecho de cdigo que j est sendo controlado.
Identificar o trecho de cdigo significa identificar o objeto de mdia sendo
controlado (representationObjectId) e a interface que identifica o trecho de
cdigo. Se a interface no for especificada, a ncora de contedo total
assumida. Nesse caso, a ao stop aplicada em todas as ncoras de
contedo. Para os outros objetos de mdia comuns, a instruo stop no
precisa especificar a interface; se um elemento <simpleAction> com o
actionType igual a stop ligado por um elo a uma interface desse n, a
interface ignorada quando a ao for executada.
A instruo stop ignorada pelo exibidor de objeto de mdia imperativo
se o trecho de cdigo associado com a interface especificada na instruo no
estiver sendo executado (se o evento correspondente no estiver nos estados
occurring ou paused) e se o exibidor do objeto imperativo no estiver
esperando devido a uma instruo retardada de start. Se o cdigo
correspondente da interface especificada na instruo start estiver em
execuo, a execuo parada, o evento de apresentao correspondente
transita para o estado sleeping, sua transio stops notificada ao formatador
e seu atributo occurrences no incrementado. Se o atributo repetitions do
evento for maior que zero, ele diminudo em um, e a apresentao do evento
associado interface reiniciada, aps o tempo entre repeties (o tempo de
retardo entre repeties transmitido ao exibidor de mdia como parmetro de
retardo de incio). Se um trecho de cdigo do objeto de mdia imperativo
estiver esperando para ser executado aps uma instruo start atrasada, e
uma instruo stop for emitida, a instruo de start anterior removida. Todo
esse procedimento, exceto para o evento associado ncora de contedo
total, deve ser realizado por instrues programadas pelo autor
(programador) do objeto imperativo para cada trecho de cdigo que pode ser
parado.
Ainda, apenas para os objetos de mdia com cdigo imperativo, se
qualquer ncora de contedo for parada e todos os outros eventos de
apresentao estiverem no estado sleeping, a ncora de contedo total ser
colocada no estado sleeping. Se uma ncora de contedo for parada e pelo
menos um outro evento de apresentao do objeto estiver no estado
535
occurring, a ncora de contedo total ser mantida no estado occurring. Em
todos os demais casos, se uma ncora de contedo for parada, a ncora de
contedo total ser colocada no estado paused. Novamente, todo esse
procedimento deve ser realizado por instrues programadas pelo autor
parado.
Para objetos de mdia que no tm cdigo imperativo, se o objeto no
estiver sendo apresentado (isto , se nenhum dos eventos na lista de eventos
do objeto estiver no estado occurring ou paused) e o exibidor de mdia no
estiver aguardando devido a uma instruo atrasada de start, a instruo stop
ignorada. Se o objeto estiver sendo apresentado, o evento principal (evento
passado como parmetro quando o objeto de mdia foi iniciado) e todos os
eventos monitorados no estado occurring ou paused com tempo de trmino
igual ou anterior ao tempo de trmino do evento principal transitam para o
estado sleeping (mesmo que um efeito de transio esteja sendo aplicado ao
objeto de mdia, isto , o efeito de transio tambm deve ser parado), e suas
transies stops so notificadas.
Ainda para objetos de mdia que no tm cdigo imperativo declarativo,
quando da aplicao de uma instruo stop, os eventos monitorados no estado
occurring ou paused com tempo de trmino posterior ao tempo de trmino do
evento principal so colocados no estado sleeping, mas suas transies stops
no so notificadas e seus atributos occurrences no so incrementados. A
apresentao do contedo do objeto parada. Se o atributo repetitions do
evento for maior que zero, ele diminudo em um e a apresentao do evento
principal reiniciada aps o tempo entre repeties (novamente, o tempo de
retardo entre repeties transmitido ao exibidor de mdia como parmetro de
retardo de incio). Se o objeto de mdia estiver esperando para ser apresentado
aps uma instruo start atrasada e se uma instruo stop for emitida, a
instruo de start anterior removida.
NOTA: Na norma brasileira para o Ginga-NCL [ABNT, NBR 15606-2,
2007], quando todos os objetos de mdia que se referem ao fluxo elementar que
transporta o vdeo principal de um programa estiverem no estado sleeping, a
exibio do vdeo principal deve ocupar a tela inteira. S por meio de um objeto de
mdia em execuo referindo ao vdeo principal, esse vdeo pode ser
redimensionado. O mesmo acontece com o udio principal de um programa:
quando todos os objetos de mdia que se referem ao fluxo elementar que transporta
o udio principal de um programa estiverem no estado sleeping, a exibio do
udio principal deve ocorrer com 100% de seu volume original.
536
H.2.1.3 Instruo abort
No caso de objetos de mdia com cdigo imperativo, a instruo abort
precisa identificar um trecho de cdigo que j est sendo controlado. Como
sempre, identificar o trecho de cdigo significa identificar o objeto de mdia
sendo controlado (representationObjectId) e a interface que identifica o
trecho de cdigo. Mais uma vez, se a interface no for especificada, a ncora
de contedo total assumida. Nesse caso, a instruo abort aplicada em
todas as ncoras de contedo. Para os outros objetos de mdia comuns, a
instruo abort precisa apenas identificar um objeto de mdia que j est
sendo controlado; se um elemento <simpleAction> com o actionType igual a
abort ligado por um elo a uma interface de n, a interface ignorada
quando a instruo for executada.
A instruo abort ignorada pelo exibidor de objeto de mdia
imperativo se o trecho de cdigo associado com a interface especificada na
instruo no estiver sendo executado (se o evento correspondente no estiver
nos estados occurring ou paused) e se o exibidor do objeto imperativo no
estiver esperando devido a uma instruo retardada de start. Se o cdigo
correspondente da interface especificada na instruo start estiver em
execuo, a execuo abortada, o evento de apresentao correspondente
transita para o estado sleeping, sua transio aborts notificada ao
formatador e seu atributo occurrences no incrementado. O atributo
repetitions do evento colocado em zero, e em nenhuma hiptese a
apresentao do evento associado interface reiniciada. Se um trecho de
cdigo do objeto de mdia imperativo estiver esperando para ser executado
aps uma instruo start atrasada e uma instruo abort for emitida, a
instruo de start anterior ser removida. Todo esse procedimento, exceto
para o evento associado ncora de contedo total, deve ser realizado por
instrues programadas pelo autor (programador) do objeto imperativo para
cada trecho de cdigo que pode ser parado.
Ainda, apenas para os objetos de mdia com cdigo imperativo, se a
execuo de qualquer ncora de contedo for abortada e todos os outros
eventos de apresentao estiverem no estado sleeping, a ncora de contedo
total colocada no estado sleeping. Se uma ncora de contedo for abortada
e pelo menos um outro evento de apresentao do objeto estiver no estado
occurring, a ncora de contedo total ser mantida no estado occurring. Em
todos os demais casos, se uma ncora de contedo for abortada, a ncora de
contedo total ser colocada no estado paused. Novamente, todo esse
parado.
537
estiver sendo apresentado e no estiver esperando para ser apresentado aps
uma instruo de start atrasada, a instruo abort ignorada. Se o objeto
estiver sendo apresentado, o evento principal e todos os eventos monitorados
no estado occurring ou paused transitam para o estado sleeping e suas
transies aborts so notificadas. Qualquer apresentao de contedo
abortada.
Se o atributo repetitions do evento for maior que zero, ele colocado em
zero e a apresentao do objeto de mdia no reiniciada. Se o objeto de
mdia estiver esperando para ser apresentado aps uma instruo start
atrasada e uma instruo abort for emitida, a instruo start removida.
H.2.1.4 Instruo pause
A instruo pause atua de forma semelhante instruo anterior.
No caso de objetos de mdia com cdigo imperativo, a instruo pause
de contedo total assumida. Nesse caso, a instruo pause aplicada em
todas as ncoras de contedo. Para os outros objetos de mdia comuns, a
instruo pause precisa apenas identificar um objeto de mdia que j est
pause ligado por um elo a uma interface de n, a interface ignorada
Tambm semelhante aos casos anteriores, a instruo pause ignorada
pelo exibidor de objeto de mdia imperativo se o trecho de cdigo associado
com a interface especificada na instruo no estiver sendo executado (se o
evento correspondente no estiver nos estados occurring ou paused) e se o
exibidor do objeto imperativo no estiver esperando devido a uma instruo
retardada de start. Se o cdigo correspondente da interface especificada na
instruo start estiver em execuo, a execuo pausada, o evento de
apresentao correspondente transita para o estado paused e sua transio
pauses notificada ao formatador. O tempo em que o cdigo se encontra no
estado paused no considerado no clculo da durao de sua execuo. Se
um trecho de cdigo do objeto de mdia imperativo estiver esperando para ser
executado aps uma instruo start atrasada e uma instruo pause for
emitida, a execuo do cdigo espera por uma instruo de resume para
continuar esperando pelo retardo especificado na instruo start. Todo esse
procedimento, exceto para o evento associado ncora de contedo total,
538
deve ser realizado por instrues programadas pelo autor (programador) do
objeto imperativo para cada trecho de cdigo que pode ser parado.
qualquer ncora de contedo for pausada e todos os outros eventos de
apresentao estiverem no estado sleeping ou paused, a ncora de contedo
total colocada no estado paused. Se uma ncora de contedo for pausada e
pelo menos um outro evento de apresentao do objeto estiver no estado
occurring, a ncora de contedo total mantida no estado occurring.
Novamente, todo esse procedimento deve ser realizado por instrues
programadas pelo autor (programador) do objeto imperativo para cada trecho
de cdigo que pode ser parado.
estiver sendo apresentado (se o evento principal, passado como parmetro
quando o objeto de mdia foi iniciado, no estiver no estado occurring) e o
exibidor de mdia no estiver esperando pelo retardo de incio, a instruo
pause ignorada. Se o objeto estiver sendo apresentado, o evento principal e
todos os eventos monitorados no estado occurring transitam para o estado
paused e suas transies pauses so notificadas. A apresentao do objeto
pausada e o tempo de pausa decorrido no considerado como parte da
durao do objeto. Como exemplo, se um objeto tiver durao explcita de 30
segundos e, aps 25 segundos, for pausado, mesmo se o objeto permanecer
pausado por, digamos, cinco minutos aps o reincio o evento principal do
objeto permanecer ocorrendo por mais cinco segundos. Se o evento principal
ainda no estiver ocorrendo porque o exibidor de mdia est esperando pelo
retardo de incio, o objeto de mdia espera por uma instruo resume para
continuar aguardando o retardo de incio.
H.2.1.5 Instruo resume
A instruo resume atua de forma semelhante s instrues anteriores.
No caso de objetos de mdia com cdigo imperativo, a instruo resume
de contedo total assumida. Se a ncora de contedo total no estiver no
estado paused, a instruo resume ignorada. Em caso contrrio, a instruo
resume aplicada em todas as ncoras de contedo que esto no estado
paused, exceto aquelas que j estavam pausadas quando a ncora de contedo
total recebeu a instruo pause. Para os outros objetos de mdia comuns, a
instruo resume precisa apenas identificar um objeto de mdia que j est
539
resume ligado por um elo a uma interface de n, a interface ignorada
A instruo resume ignorada pelo exibidor de objeto de mdia
imperativo se o trecho de cdigo associado com a interface especificada na
instruo no estiver pausado (se o evento correspondente no estiver no
estado paused) e se o exibidor do objeto imperativo no estiver esperando
devido a uma instruo retardada de start. Se o trecho de cdigo do objeto de
mdia imperativo estiver pausado na espera para ser executado aps uma
instruo start atrasada e ter sido submetido a uma instruo pause, ele
retoma a espera especificada na instruo start. Se o cdigo correspondente
da interface especificada na instruo start estiver pausado, o evento de
apresentao correspondente transita para o estado occurring, e a transio
resumes notificada ao formatador. Todo esse procedimento, exceto para o
evento associado ncora de contedo total, deve ser realizado por
Ainda apenas para os objetos de mdia com cdigo imperativo, se
qualquer ncora de contedo tiver sua execuo retomada, a ncora de
contedo total colocada no estado occurring. Se uma ncora de contedo
for pausada e pelo menos um outro evento de apresentao do objeto estiver
no estado occurring, a ncora de contedo total mantida no estado
occurring. Novamente, todo esse procedimento deve ser realizado por
estiver pausado (se o evento principal, passado como parmetro quando o
objeto de mdia foi iniciado, no estiver no estado paused) e o exibidor de
mdia no estiver pausado (esperando pelo retardo de incio), a instruo
ignorada. Se o exibidor de mdia estiver pausado aguardando o retardo de
incio, ele retoma a espera da exibio a partir do instante em que foi
pausado. Se o evento principal estiver no estado paused, o evento principal e
todos os eventos monitorados no estado paused so colocados no estado
occurring e suas transies resumes so notificadas.
H.2.1.6 Trmino Natural de uma Apresentao
Eventos de um objeto, com durao explcita ou intrnseca, normalmente
terminam suas apresentaes naturalmente, sem precisar de instrues
externas. Nesse caso, o exibidor de mdia transita o evento para o estado
sleeping e notifica a transio stops.
540
Para objetos de mdia com cdigo imperativo, se o atributo repetitions
do evento for maior que zero, ele diminudo em um, e a apresentao do
evento associado interface reiniciada aps o tempo entre repeties (o
tempo de retardo entre repeties transmitido ao exibidor de mdia como
parmetro de retardo de incio). Todo esse procedimento, exceto para o evento
associado ncora de contedo total, deve ser realizado por instrues
programadas pelo autor (programador) do objeto imperativo para cada trecho
de cdigo que pode ser parado.
qualquer ncora de contedo tiver um fim natural, e todos os outros eventos
de apresentao estiverem no estado sleeping, a ncora de contedo total
colocada no estado sleeping. Se uma ncora de contedo terminar e pelo
menos um outro evento de apresentao do objeto estiver no estado
occurring, a ncora de contedo total mantida no estado occurring. Em
todos os demais casos, se uma ncora de contedo terminar sua execuo, a
ncora de contedo total colocada no estado paused. Novamente, todo esse
parado.
Para objetos de mdia que no tm cdigo imperativo, os eventos
monitorados no estado occurring com o mesmo tempo de trmino do evento
principal ou com tempo de trmino desconhecido, quando o evento principal
termina, vo para o estado sleeping e suas transies stops so notificadas.
Os eventos no estado occurring com tempo de trmino posterior ao tempo de
trmino do evento principal so colocados no estado sleeping sem gerar a
transio stops e sem incrementar o atributo occurences. importante
ressaltar que, se o evento principal corresponder a uma ncora temporal
interna ao objeto, quando a apresentao dessa ncora terminar, toda a
apresentao do objeto de mdia termina.
Eventos de Atribuio
Antes de iniciarmos a discusso de cada instruo, importante
salientar que, embora as propriedades de um n de mdia com cdigo
imperativo possa estar associado com trechos de cdigo, a execuo desses
trechos no afeta mquinas de estado de ncoras de contedo que porventura
estejam associadas aos mesmos cdigos.

541
H.2.2.1 Instruo start
A instruo start pode ser aplicada a um objeto independentemente do
fato de ele estar sendo ou no apresentado (nesse ltimo caso, embora o
objeto no esteja sendo apresentado, seu exibidor de mdia j deve estar
instanciado). No primeiro caso, a instruo start precisa identificar o objeto
de mdia sendo controlado (representatioObjectId) e um evento de atribuio
monitorado. Deve tambm especificar um valor a ser atribudo propriedade
que definiu o evento, a durao do processo de atribuio e o passo de
atribuio..
Ao imputar um valor propriedade, o exibidor de mdia transita a
mquina de estado do evento de atribuio para o estado occurring e, depois
de terminada a atribuio, novamente para o estado sleeping, gerando a
transio starts e, em seguida, a transio stops. No caso de objetos de mdia
com cdigo imperativo, todo esse procedimento deve ser realizado por
cada elemento <property> declarado.
Para cada evento de atribuio monitorado, se o exibidor de mdia
alterar, por sua prpria conta, o valor correspondente de um atributo, ele
procede como se tivesse recebido uma instruo externa de start. Novamente,
no caso de objetos de mdia com cdigo imperativo, todo o procedimento deve
ser realizado por instrues programadas pelo autor (programador) do objeto
imperativo.
H.2.2.2 Instrues stop, abort, pause e resume
As instrues stop, abort, pause e resume precisam identificar o objeto
de media em apresentao (representation ObjectId) e um eveno de
atribuio sendo monitorado.
A instruo stop apenas cessa o procedimento de atribuio, trazendo o
evento de atribuio para o estado sleeping.
A instruo abort aborta o procedimento de atribuio, trazendo o
evento de atribuio para o estado sleeping e a propriedade para o seu valor
inicial.
A instruo pause apenas pausa o procedimento de atribuio, trazendo
o evento de atribuio para o estado paused.
Finalmente, a instruo resume retoma o procedimento de atribuio,
trazendo o evento de atribuio para o estado occurring.
542
No caso de objetos de mdia com cdigo imperativo, todos os
procedimentos citados nos pargrafos anteriores devem ser realizados por
instrues programadas pelo autor (programador) do objeto imperativo.
H.2.3 Comportamento na Execuo de Comandos de
Edio
H.2.3.1 Instruo addEvent
A instruo addEvent emitida no caso de recepo de um comando de
edio NCL addInterface (ver Captulo 16). A instruo precisa apenas
identificar um objeto de mdia que j esteja sendo controlado e um novo
evento de interface a ser includo e colocado em monitoramento.
No caso de objetos de mdia comuns, que no possuem cdigo
imperativo, todas as regras aplicadas interseo de eventos monitorados
com o evento principal so aplicadas ao novo evento. Se o tempo de incio do
novo evento for anterior ao tempo atual do objeto e o tempo de trmino do
novo evento for posterior ao tempo atual do objeto, o novo evento colocado
no mesmo estado do evento principal (occurring ou paused), sem notificar a
transio correspondente.
H.2.3.2 Instruo removeEvent
A instruo removeEvent emitida no caso de recepo de um comando
de edio NCL removeInterface. A instruo precisa identificar um objeto de
mdia que j esteja sendo controlado e um evento de interface que no se quer
mais controlar. O estado do evento da interface a ser removida colocado em
sleeping, sem gerar nenhuma transio.
H.3 Comportamento do Formatador NCL na
Exibio de Composies
Um <simpleCondition> ou <simpleAction> com valor do atributo
eventType igual a presentation pode ser associado por um elo a um n de
composio (representado por um elemento <context> ou <body>) como um
todo (isto , sem que uma de suas interfaces seja informada). Como
normalmente ocorre, a mquina de estado do evento de apresentao definido
pelo n de composio deve ser controlada pelo formatador, como discutimos
no Captulo 10. De forma anloga, um <attributeAssessment>, com valor de
543
atributo eventType igual a presentation e attributeType igual a state,
occurrences ou repetitions pode ser associado por um elo a um n de
composio (representado por um elemento <context> ou <body>) como um
todo.
A particularidade do procedimento se aplica quando uma
<simpleAction> com valor de atributo eventType igual a presentation for
associada por um elo a um n de composio (representado por um elemento
<context> ou <body>) como um todo (ou seja, sem que uma de suas
interfaces seja informada). Nesse caso, a instruo refletida nas mquinas
de estado de evento dos ns filhos da composio, como veremos a seguir.
H.3.1 Iniciando a Apresentao de um Contexto
Se um elemento <context> ou <body> participar de um papel (role) de
ao (action) cujo tipo de ao start quando essa ao for acionada, a
instruo start tambm aplicada a todos os eventos de apresentao
mapeados pelas portas do elemento <context> ou <body>, quando nenhuma
porta (elemento <port>) da composio for especificada na ao.
Se o autor quiser iniciar a apresentao a partir de uma porta especfica,
ele tambm deve indicar o id de <port> como valor do atributo interface do
elemento <bind>.
H.3.2 Parando a Apresentao de um Contexto
ao (action) cujo tipo de ao stop quando essa ao for acionada, a
instruo stop tambm aplicada a todos os eventos de apresentao dos ns
filhos da composio, quando nenhuma porta (elemento <port>) da
composio for especificada na ao.
Se a composio contiver elos sendo avaliados (ou com sua avaliao
pausada), as avaliaes so suspensas e nenhuma ao acionada.
H.3.3 Abortando a Apresentao de um Contexto
ao (action) cujo tipo de ao abort quando essa ao for acionada, a
instruo abort tambm aplicada a todos os eventos de apresentao dos
ns filhos da composio quando nenhuma porta (elemento <port>) da
composio for especificada na ao.
544
Se a composio contiver elos sendo avaliados (ou com sua avaliao
pausada), as avaliaes so suspensas e nenhuma ao acionada.
H.3.4 Pausando a Apresentao de um Contexto
ao (action) cujo tipo de ao pause quando essa ao for acionada, a
instruo pause tambm aplicada a todos os eventos de apresentao dos
ns filhos da composio que estejam no estado occurring quando nenhuma
porta (elemento <port>) da composio for especificada na ao.
Se a composio contiver elos sendo avaliados, todas as avaliaes so
suspensas at que uma ao resume, stop ou abort seja emitida.
Se a composio contiver ns filhos com eventos de apresentao no
estado paused quando a ao pause na composio for emitida, esses ns
so identificados porque, se a composio receber uma instruo resume,
esses eventos no devem ser retomados.
H.3.5 Retomando a Apresentao de um Contexto
ao (action) cujo tipo de ao resume e nenhuma porta (elemento
<port>) da composio for especificada na ao quando essa ao for
acionada, a instruo resume tambm aplicada a todos os eventos de
apresentao dos ns filhos da composio que estejam no estado paused,
exceto aqueles que j estavam pausados antes de a composio ser pausada.
Se a composio contiver elos com avaliaes pausadas, elas so
retomadas.
H.3.6 Relao entre as Mquinas de Estado de Eventos de
Apresentao de um N e a Mquina de Estado do Evento
de Apresentao de seu N de Composio Pai
Sempre que o evento de apresentao de um n (mdia ou composio)
for para o estado occurring, o evento de apresentao do n de composio
que contm o n tambm entra no estado occurring.
Quando todos os ns filhos de um n de composio tiverem seus
eventos de apresentao no estado sleeping, o evento de apresentao do n
de composio tambm vai para o estado sleeping.
545
Os ns de composio no inferem transies aborts a partir de seus ns
filhos. Essas transies nos eventos de apresentao de ns de composio
ocorrem apenas quando instrues so aplicadas diretamente ao seu evento de
apresentao.
Quando todos os ns filhos de um n de composio tm seus eventos de
apresentao em um estado diferente de occurring e ao menos um dos ns
tem seu evento principal no estado paused, o evento de apresentao do n de
composio deve tambm estar no estado paused.
Se um elemento <switch> for iniciado mas no definir um componente
default e nenhuma das regras <bindRule> referenciadas for avaliada como
verdadeira, a apresentao switch no vai para o estado occurring.
H.4 Comportamento de Exibidores de Objetos
Hipermdia com Contedo Declarativo
Um exibidor de objeto hipermdia com contedo composto por um
cdigo declarativo (mesmo tendo contedos imperativos embutidos) tem um
comportamento muito semelhante apresentao de um n de composio
realizado pelo formatador NCL. Na verdade, o formatador NCL o exibidor
de um objeto hipermdia contendo cdigo declarativo NCL. Em NCL, tais
objetos tm seu atributo type especificados como application/x-ncl-NCL.
Embora a implementao de referncia do middleware Ginga-NCL
permita que um documento NCL contenha objetos hipermdia com cdigo
SMIL [W3C REC-SMIL2-20051213, 2008] e X3D, a norma para o Sistema
Brasileiro de TV Digital s permite a documentos NCL embutirem outros
documentos NCL ou documentos X-HTML. Vamos, ento, neste apndice,
nos restringir a esses objetos. Contudo, como veremos, a discusso que aqui
faremos facilmente generalizada para objetos especificados em outras
linguagens declarativas.
H.4.1 Iniciando a Apresentao de um Objeto Hipermdia
com Contedo Declarativo
Se um elemento <media> com contedo declarativo (embutindo ou no
cdigos imperativos) participar de um papel (role) de ao (action) cujo tipo
de ao start, quando essa ao for acionada, uma instruo start tambm
aplicada a todas as cadeias temporais definidas pelo objeto (veja o Captulo
14 e o Apndice G), quando nenhuma cadeia do objeto for especificada na
ao. Por exemplo, para um objeto de mdia com tipo igual a application/x-
546
ncl-NCL, todas as portas do documento NCL especificadas em seu elemento
<body> sofrero a ao start.
Se o autor quiser iniciar a apresentao a partir de uma cadeia
especfica, ele tambm deve definir o identificador da cadeia. Por exemplo,
para um objeto de mdia com tipo igual a application/x-ncl-NCL, uma
interface do elemento <bind>, que se liga ao objeto com cdigo NCL, deve
indicar uma das ncoras do objeto, a qual referencia o id de um elemento
<port> que inicia a cadeia, conforme discutimos no Captulo 14.
H.4.2 Parando a Apresentao de um Objeto Hipermdia
de ao stop, quando essa ao for acionada, uma instruo stop tambm
aplicada a todas as cadeias definidas internamente pelo objeto quando
nenhuma cadeia especfica do objeto for especificada na ao. Por exemplo,
para um objeto de mdia com tipo igual a application/x-ncl-NCL, a ao
stop tambm aplicada a todos os eventos de apresentao dos ns filhos
do elemento <body> do objeto de mdia com cdigo NCL.
Se o autor quiser parar a apresentao de uma cadeia especfica, ele
tambm deve indicar o identificador da cadeia. Por exemplo, para um objeto
de mdia com tipo igual a application/x-ncl-NCL, uma interface do
elemento <bind>, que se liga ao objeto com cdigo NCL, deve indicar uma
das ncoras do objeto, a qual referencia o id de um elemento <port> que
inicia a cadeia, conforme discutimos no Captulo 14. Nesse caso, a instruo
stop tambm aplicada a todos os eventos de apresentao de todos os ns
filhos do elemento <body>, do objeto de mdia com cdigo NCL, que
participam da cadeia e no esto no estado sleeping.
Se o objeto de mdia com cdigo declarativo contiver alguma relao
entre seus objetos internos sendo avaliada (ou com sua avaliao pausada), a
avaliao suspensa e nenhuma ao acionada.
H.4.3 Abortando a Apresentao de um Objeto Hipermdia
de ao abort quando essa ao for acionada, uma instruo abort
tambm aplicada a todas as cadeias definidas internamente pelo objeto
547
quando nenhuma cadeia especfica do objeto for especificada na ao. Por
exemplo, para um objeto de mdia com tipo igual a application/x-ncl-NCL,
a instruo abort tambm aplicada a todos os eventos de apresentao dos
ns filhos do elemento <body> do objeto de mdia com cdigo NCL.
Se o autor quiser abortar a apresentao de uma cadeia especfica, ele
abort tambm aplicada a todos os eventos de apresentao de todos os ns
participam da cadeia e no esto no estado sleeping.
avaliao suspensa e nenhuma ao acionada.
H.4.4 Pausando a Apresentao de um Objeto Hipermdia
de ao pause quando essa ao for acionada, uma instruo pause
tambm aplicada a todas as cadeias definidas internamente pelo objeto que
estejam em apresentao quando nenhuma cadeia especfica do objeto for
especificada na ao. Por exemplo, para um objeto de mdia com tipo igual a
application/x-ncl-NCL, a instruo pause tambm aplicada a todos os
eventos de apresentao dos ns filhos do elemento <body> do objeto de
mdia com cdigo NCL que estejam no estado occurring.
Se o autor quiser pausar a apresentao de uma cadeia especfica, ele
pause tambm aplicada a todos os eventos de apresentao de todos os ns
participam da cadeia e que estejam no estado occurring.
avaliao suspensa at que uma ao resume, stop ou abort seja emitida.
548
Se o objeto de mdia com cdigo declarativo contiver cadeias temporais
no estado paused, quando a ao pause no objeto for emitida, essas cadeias
so identificadas porque, se o objeto receber uma instruo resume, essas
cadeias no devero ser retomadas.
H.4.5 Retomando a Apresentao de um Objeto Hipermdia
cdigos imperativos) participar se um papel (role) de ao (action) cujo tipo
de ao resume e nenhuma cadeia especfica do objeto for especificada na
ao quando essa ao for acionada, uma instruo resume tambm
aplicada a todas as cadeias definidas internamente pelo objeto que estejam no
estado paused, exceto aquelas que j estavam pausadas antes de o objeto
declarativo ser pausado. Por exemplo, para um objeto de mdia com tipo igual
a application/x-ncl-NCL, a instruo resume tambm aplicada a todos os
eventos de apresentao dos ns filhos do elemento <body>, do objeto de
mdia com cdigo NCL, que estejam no estado paused, exceto aqueles que j
estavam pausados antes de o objeto de mdia declarativo ser pausado.
Se o autor quiser retomar a apresentao de uma cadeia especfica, ele
resume tambm aplicada a todos os eventos de apresentao de todos os ns
filhos do elemento <body> do objeto de mdia com cdigo NCL que
participam da cadeia e que estejam no estado paused, exceto aqueles que j
estavam pausados antes de o objeto de mdia declarativo ser pausado.
entre seus objetos internos pausada, ela retomada quando a cadeia da qual
esses objetos participam so retomadas.
Eventos de Atribuio de um Objeto Hiperdia com Cdigo
Declarativo
As mquinas de estado associadas a propriedades de um objeto de mdia
com cdigo declarativo tm exatamente o mesmo comportamento das
mquinas de estado associadas a um objeto de mdia no-imperativo,
conforme descrito na Seo H.2.2.
549
H.4.7 Relao entre os Estados de uma Cadeia Temporal
de um Objeto Hipermdia e suas ncoras de Contedo
Sempre que qualquer cadeia temporal de um objeto de mdia com
contedo declarativo estiver sendo apresentada, o evento de apresentao
associado ncora de contedo total estar no estado occurring.
Um evento associado a uma ncora especfica de uma cadeia est no
estado occurring quando o trecho da cadeia que ele especifica est sendo
apresentado.
Quando todas as cadeias de um objeto de mdia com contedo
declarativo ainda no foram iniciadas (ou foram paradas ou abortadas), o
evento de apresentao associado sua ncora de contedo total estar no
estado sleeping.
estado sleeping quando o trecho da cadeia que ele especifica ainda no foi
iniciado ou foi parado ou abortado.
Quando todas as cadeias de um objeto de mdia com contedo
declarativo no estiverem sendo apresentadas e ao menos uma das cadeias
est pausada, o evento de apresentao associado sua ncora de contedo
total estar no estado paused.
estado paused quando o trecho da cadeia que ele especifica est pausado.
Bibliografia
Soares, L.F.G. e Rodrigues, R.F. (2006). Nested Context Model 3.0 Part 8
N. 35/06. Rio de Janeiro, outubro de 2006. ISSN 0103-9741.
W3C, REC-SMIL2-20051213 (2008). World Wide Web Consortium,

Programando em NCL 3.0

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Programando em NCL 3.0

Enviado por

Direitos autorais:

Formatos disponíveis

NCL (Nested Context Language) a linguagem declarativa do

middleware Ginga, recomendao ITU-T para servios IPTV e padro

Você também pode gostar