itv - interactive TV » 2009

Texto publicado inicialmente no Portal Imasters

Este texto continua a abordagem sobre sincronismo de mídias, apresentando os princípios da construção de conectores e introduzindo os links.

Neste texto iremos discutir as relações de sincronismo a partir da criação de conectores e links. Na linguagem NCL tudo é determinado a partir de uma causa. Ou seja, cada ação é precedida por outra; uma condição deve obrigatoriamente ser satisfeita para disparar uma ação.
Assim, todo sincronismo no espaço e no tempo segue uma lógica causal. Para determinar as relações de causa e efeito, precisamos definir conectores. Conectores são expressões que ligam uma condição a uma determinada ação. Assim, todo conector possui ao menos uma condição e uma ação. Por exemplo: quando o vídeo chegar em determinado ponto (condição) coloca uma imagem na tela (ação); quando a imagem iniciar (condição) redimensiona o vídeo (ação); quando o telespectador apertar um botão no controle remoto (condição), inicia a interatividade (ação). Resumindo: conectores são utilizados para especificar relações de sincronização espaço-temporais, tratando relações de referência (de interação com usuário) como um caso particular de relações de sincronização temporal.

A única exceção para essa relação causal é no início da aplicação. Portanto, a primeira ação é definida arbitrariamente pelo desenvolvedor, através do elemento <port> do <body>. Para exemplificar, vamos criar um conector que defina uma ação para quando algo iniciar. Por exemplo, quando um nó de mídia aparecer na tela, deve aparecer outro no mesmo instante. Lembrando que os conectores devem ser criados na base de conectores, dentro do cabeçalho.

Assim:
<connectorBase>
<causalConnector id=”onBeginStart”>
<simpleCondition role=”onBegin”/>
<simpleAction role=”start”/>
</causalConnector>
</connectorBase>

Neste conector temos a condição definida como <simpleCondition> “onBegin” (ou seja, quando começar) e a ação definida como <simpleAction> “start”. Este conector possui apenas uma condição e uma ação. No entanto, tanto as condições quanto as ações podem ser compostas. Nesse caso, temos uma <compoundCondition> e uma <compoundAction> como elementos pai de <simpleCondition> e <simpleAction>, respectivamente . A primeira pode ser qualificada como “or” ou “and”. Isso significa que, no caso “or” uma das condições precisa ser satisfeita para ocorrer a ação; já em “and” ambas precisam ser atendidas. Por exemplo: se o telespectador apertar o botão vermelho do controle remoto e o vídeo estiver redimensionado, começa um joguinho. Só o fato de apertar o botão não dispara a ação. O vídeo precisa estar redimensionado.

Além disso, podemos definir um retardo (delay) para a condição, especificando que a condição é verdadeira após um período de retardo a partir do momento em o evento ocorre.

Já as ações compostas são mais simples, podendo ocorrer em paralelo “par” ou em sequência “seq”. Da mesma forma como nas condições, um atributo delay pode também ser definido para a <simpleAction>, especificando que a ação só pode ocorrer após esperar pelo tempo pré-definido. Além disso, também pode ser definido um atributo repeat para ser aplicado ao atributo repetitions do evento, e um atributo repeatDelay, para ser aguardado antes da repetição da ação. Além de todos os atributos acima citados, o elemento <simpleAction> também pode ter atributos definidos na área funcional Animation (atributos duration e by). Assim é possível fazer animações simples em NCL.

Os conectores definem relações de causa e efeito. A atribuição das relações com as mídias é feita nos <links>, dentro do <body> do documento. Para testar nosso conector, vamos pegar o exemplo do texto anterior (Interatividade, sincronismo e documentos NCL), cujo objetivo era colocar um botão na tela. Esse botão foi definido arbitrariamente através do uso da porta (<port>) do contexto principal (<body>). Agora, outro botão deve aparecer simultaneamente.
Vamos declarar mais uma mídia, com ID Botao2, lembrando que deve ter um descritor e uma região associados, e fazer esse botão aparecer junto com o botão vermelho.

Neste link estamos afirmando que quando o nó de mídia “botao” começar, deve inciar também o nó “botao2”. Isso é feito através do uso do conector declarado na base de conectores “onBeginStart”, onde definimos as condições e as ações. No link ligamos as mídias a estas condições e ações, usando “binds”. O “bind” tem um componente, que é a mídia, e um papel, que é definido no conector.
O código completo da aplicação deve estar assim:

As causas possíveis de serem descritas nos conectores são:
onBegin – quando começar
onEnd – quando terminar
onAbort – quando abortar
onPause – quando pausar
onResume – quando sair da pausa e começar a tocar
onSelection – quando for selecionado
onBeginAttribution – quando uma atribuição começar
onEndAttribution – quando uma atribuição terminar

Já as ações são:
start - comece
stop - pare
abort - aborte
pause - pause
resume - reinicie
set - configure

Dessa forma é possível concatenar causa e consequência, construindo relações de sincronismo e de interatividade. Podemos ter uma causa e várias consequências, assim como várias causas para apenas uma única consequência. Lembrando apenas que um conector pode ser utilizado quantos vezes for necessário e podemos ter quantos conectores precisarmos em um documento NCL. Nos próximos textos iremos aprofundar o tema sincronismo e começar a definir a participação do telespectador.

Texto originalmente publicado no portal imasters

Tabelas Lua.

As tabelas, em Lua, são estruturas de dados da linguagem. São comuns em outras linguagens, estruturas de dados do tipo vetor e lista. Porem, Lua possui somente as tabelas, pois são flexíveis e permitem combinações.

Este artigo visa tratar, de maneira introdutória, seu uso e suas propriedades.

Na verdade já tivemos contato com esta estrutura nos últimos artigos sobre a biblioteca NCLua. Como vimos, a biblioteca se baseia na troca de mensagens entre o formatador NCL e a máquina de execução Lua. Tal comunicação acontece através do envio e recebimento de tabelas Lua. Essas tabelas representam os eventos, que acontecem durante a execução da aplicação.

Relembrando:

Vimos que para um script Lua se comunicar com o documento NCL é necessário que uma tabela, específica, seja enviada através do comando event.post().

Por exemplo, para que um script Lua inicie uma ancora em um nó NCL, o seguinte evento deve ser gerado:

tabela = {
class = ‘ncl’,
type = ‘presentation’,
action = ‘start’,
label = ‘nome_ancora’
}

Então esta tabela deve ser enviada ao NCL:

event.post( tabela )

Outro exemplo. Cada vez que um botão de teclado ou de controle remoto é pressionado uma tabela é gerada, porem no sentido contrário, no sentido NCL para Lua, e as propriedades da tabela contem outros valores, como por exemplo, a propriedade class, que contem o valor ‘key’.

Tabelas Lua.

Até agora vimos seu uso apenas na interface de comunicação NCLua, veremos agora a essência das tabelas, quais suas principais características e funções dentro da linguagem Lua.

Para começar, temos que saber que uma tabela começa e termina com colchetes, dado seu identificador. Então uma tabela t vazia:

t = {}

Uma propriedade importante é saber o tamanho da tabela, e conseguimos isso através do uso de #.

> print (#t)
0

O seguinte exemplo cria uma tabela com valores:

carro = {
[‘cor’] = ‘cinza’,
[‘cilindradas’] = ‘1600’,
[‘ano’] = ‘2008’,
[‘modelo’] = ‘2009’,
}

Uma tabela é composta por uma coleção de chaves e valores. Onde cada chave esta associada um valor. No exemplo, as palavras entre [ ] são as chaves e os seus valores vem depois do sinal de =, e cada par é separado do outro por virgula.

Usando a tabela:

> print( carro[‘ano’] )
2008

>print( carro[ ‘portas’] )
nil

Caso o índice não exista na tabela o valor nil é retornado.

Flexibilidade:

Como disse no inicio, tabelas tem muita flexibilidade, os índices nem sempre precisam estar entre [ ]. Um outro jeito de escrever a tabela acima é:

carro = {
cor = ‘cinza’,
cilindradas = ‘1600’,
ano = ‘2008’,
modelo = ‘2009’,
}

Outro jeito de acessar os valores:

Dada a tabela, os seguintes meios de acesso aos valores:

ano = { mes = { dia = “quarta” } }

> print( ano.mes.dia )
quarta
> print( ano.mes[‘dia’] )
quarta

> print( ano[‘mes’][‘dia’] )
quarta

Índices implícitos

Índices numéricos são implícitos quando há ausência de declaração deles no corpo da tabela. Por exemplo:

tabela = {“a”, “b”, “c”}

Esta implícito que os índices de “a”, “b” e “c” são 1, 2 e 3 respectivamente. Portanto:

>print( tabela[1])
a

A função ipairs

Muitas vezes temos que fazer iterações sobre uma tabela inteira, tendo que acessar cada par (índice, valor) da tabela. Fazemos isso usando laços de controle como um bloco while ou for, por exemplo, e implicitamente declarando um valor de inicio e final para as iterações. Uma alternativa mais eficiente para iterar sobre um array ou tabela é a função ipairs.

Considere o seguinte array ou tabela:

> letras = { “a”, ”b”, ”c” }

Se quisermos imprimir cada índice e cada valor usando um bloco for faríamos desta maneira:

>for i = 1, #letras do
>> print(“índice: ” .. i .. “ valor: ” .. letras[i] )
>end
indice: 1 valor: a
indice: 2 valor: b
indice: 3 valor: c

De maneira similar mas usando ipairs:

>for i, n in ipairs( letras ) do
>> print(“índice: ” .. i .. “ valor: ” .. n )
>end
indice: 1 valor: a
indice: 2 valor: b
indice: 3 valor: c

O trecho de código in ipairs( tabela ), sugere um loop sobre a tabela passada como parâmetro. A função percorre a tabela de maneira ordenada, atribuindo o índice ao primeiro parâmetro passado antes de in, que é i, e passa o valor correspondente para o segundo parâmetro, n.

Importante notar que a função ipairs percorre índices numéricos sem intervalos. Isto quer dizer que dada a tabela

> letras = { “a”, b, ”c” }

a função iria ate o primeiro índice apenas, pois o índice de b não é 2.

A biblioteca table

A linguagem ainda oferece outras funções básicas. A seguir listo algumas:

table.sort (tabela) – ordena uma tabela.
table.insert (tabela, valor) – insere o valor na tabela, na ultima posição.
table.remove (tabela, valor) – remove o valor na tabela, na ultima posição.

Bibliografia

Os conceitos vistos acima são o básico que devemos saber sobre o uso de tabelas. Para saber mais sobre o assunto recomendo a consulta aos seguintes livros:

Programming in Lua do Roberto Ierusalimschy, que é considerado a bíblia da linguagem e esta disponível on-line no site www.lua.org

e

Beginning Lua Programming de Kurt Jung e Aaron Brown, livro o qual baseei este artigo.

Ainda no site lua.org você encontra os binários para executar seus programas em Lua, para que usa Windows tem uma opção la também, basta baixar e executar o .exe.

Saiu mais uma pesquisa

Sumiram as reclamações

Artigo inicialmente publicado no Portal Imasters.

Este artigo introduz a linguagem de programação declarativa do ISDB-Tb, já padronizada e definida como componente da TV digital brasileira.

A NCL é definida por duas normas da ABNT como linguagem declarativa do ISDB-Tb: a NBR 15606 Parte 2: Ginga-NCL para receptores fixos e móveis – Linguagem de aplicação XML para codificação de aplicações; e NBR 15606 Parte 5: Ginga-NCL para receptores portáteis – Linguagem de aplicação XML para codificação de aplicações. Dessa forma, dúvidas sobre os recursos e possibilidades de uso devem ser tiradas nesses documentos. A consulta de outros documentos disponíveis on line também é válida, mas mantende a ressalva de que eles podem não estar compatíveis com a norma, uma vez que foram gerados anteriormente às definições da ABNT, que, por sugestão do Fórum do SBTVD, fez uma série de alterações nos recursos.
A linguagem NCL está estrutura de forma a colar as mídias da aplicação no tempo e no espaço. Explicando melhor, com a NCL não é possível criar nada, apenas gerenciar. Dessa forma, é preciso criar as mídias das aplicações em outras ferramentas e determinar onde as mídias irão aparecer (em quais regiões), como, quando.
A norma NBR 15606-2 explica que um documento NCL apenas define como os objetos de mídia são estruturados e relacionados no tempo e espaço. Como uma linguagem de cola, ela não restringe ou prescreve os tipos de conteúdo dos objetos de mídia. Nesse sentido, pode-se ter objetos de imagem (GIF, JPEG.), de vídeo (MPEG), de áudio (MP3,), de texto (TXT, HTML), de execução (Xlet, Lua), entre outros, como objetos de mídia dentro de documentos NCL. A linguagem faz o gerenciamento dessas mídias. Quais objetos de mídia são suportados depende dos exibidores de mídia que estão acoplados ao formatador NCL (exibidor NCL), ou seja, depende da implementação do Ginga (ambientes reais) ou do emulador (ambientes de teste em computadores). Um desses exibidores é o decodificador/exibidor MPEG-4, normalmente implementado em hardware no receptor de televisão digital. Dessa forma, o vídeo e o áudio MPEG-4 principal são tratados como todos os demais objetos de mídia que podem estar relacionados utilizando NCL. Assim, é possível utilizar NCL para gerenciar todos os recursos do receptor.
Além disso, pensando na interoperabilidade, um outro objeto de mídia NCL deve obrigatoriamente ser suportado: o objeto de mídia baseado em XHTML. A NCL não substitui, mas embute documentos (ou objetos) baseados em XHTML. Como acontece com outros objetos de mídia, a implementação do NCL define o suporte.
Assim, é possível ter navegadores de outros middlewares, como BML, DVB-HTML e ACAP-X individualmente embutidos em um exibidor de documento NCL. É possível também ter todos eles. É igualmente possível receber o código de um programa navegador através da difusão de dados e instalá-lo como plug-in (normalmente um plug-in Java). Também é possível ter um navegador genérico implementado e, se necessário, receber a parte complementar (específica) como um plug-in, para converter o exibidor XHTML genérico em um exibidor específico de um dos diversos padrões de navegadores de TV digital.
Em último caso, um documento NCL pode ser reduzido para conter apenas um objeto de mídia XHTML. Nesse caso, o exibidor do documento NCL atua quase como um navegador XHTML, isto é, como qualquer outro navegador dos padrões supracitados. Da mesma forma, é possível tratar programas feitos em Java (NCLet), Lua (NCLua). Por exemplo, é possível fazer uma aplicação inteira em Lua, onde o NCL apenas a executa no momento definido pelo programador.
Durante a exibição do conteúdo de objetos de mídia são gerados vários eventos. A apresentação de parte do conteúdo de um objeto de mídia, e a seleção de parte do conteúdo de um objeto são exemplos. Os eventos podem gerar ações sobre outros objetos de mídia, como iniciar ou terminar suas apresentações. Portanto, os eventos devem obrigatoriamente ser relatados pelos exibidores de mídia ao formatador NCL que, por sua vez, pode gerar ações a serem aplicadas a esses ou outros exibidores. Ginga-NCL define a API de um adaptador com o objetivo de padronizar a interface entre o formatador Ginga-NCL e cada exibidor específico.
A NCL admite as seguintes mídias:

Os próximos artigos irão tratar do uso dessas mídias, da estrutura modular, da sintaxe e organização da linguagem.

Your 40-Inch OLED TV Will Arrive in 2010, Thanks to Panasonic
BY Kit EatonTue May 12, 2009 at 6:04 PM

I know you’re fond of your nice, new LCD HDTV, I know–it’s much better than the big CRT brute you had before. But, and trust me on this, you’re going to want to buy a whole new TV next year. It’s going to be OLED you see, and it may come from Panasonic.

That’s because Panasonic just announced a partnership with Sumitomo Chemical company to develop advanced display panels using OLED technology. The partnership will turn into a joint venture to develop and manufacture screens that are 40 inches and over by 2010.

Why all the excitement about this? It’s pretty simple, OLED is about as much of a technological leap in display technology over current LCDs as the LCD was over your old cathode-ray-tube telly. In an LCD, each pixel consists of bunches of tiny packets of liquid crystal that change their structure when a voltage is applied–they don’t actually radiate any light themselves, and that’s why LCD screens need a cold-cathode or LED backlight. The technology works, and it’s been steadily improving for sure, but viewing the displays from different angles results in non-ideal pictures, and it’s difficult for true black to be displayed.

But in an OLED screen each pixel is an array of tiny, colored light-emitting diodes–each one actually glows with the corresponding color from the TV signal. As a result, the brightness, contrast and sharpness of an OLED screen is whole streets ahead of LCD. You can view them from any angle, they can show a wider range of colors than LCD and black areas show up as truly black. Oh, and because they don’t need a backlight they consume far less electricity, and can be much, much thinner. Down to millimeters deep, in fact. Do you want a new TV yet?

Panasonic’s clearly hoping to steal the march on this new tech–the only OLED TV on the market thus far is Sony’s XEL1 which is 3mm deep, but just 11-inches across and comes at a whopping $2000+ price point.

FONTE: ROUTERS

Agora é oficial:

No dia 29/04/2009, a linguagem NCL e seu ambiente de apresentação Ginga-NCL, tecnologias genuinamente nacionais criadas para oferecer interatividade plena em sistemas de TV Digital, foram aprovados como padrão pela Uniao Internacional de Telecomunicações (UIT), órgão de padronização e regulamentação em telecomunicações ligado às Nações Unidas.

A nova Recomendação H.761 “Nested Context Language (NCL) and Ginga-NCL for IPTV Services” define a linguagem NCL como padrão UIT-T para a construção de aplicações multimídia destinadas ao ambiente de TV interativa. Além de definir a linguagem NCL, a recomendação descreve os requisitos para a construção da máquina de apresentação Ginga-NCL, responsável pela exibição e controle de aplicações NCL. NCL e Ginga-NCL são tecnologias de propriedade intelectual da PUC-Rio, resultados de pesquisas realizadas no Laboratório TeleMídia de seu Departamento de Informática, financiadas pela FINEP e RNP a partir das ações estratégicas do Ministério de Ciência e Tecnologia (MCT) e do Ministério de Telecomunicações (MC).

Tal esforço de padronização se iniciou há quase dois anos, quando pesquisadores brasileiros presentes às primeiras reuniões do então chamado “focus group on IPTV” foram convidados por delegados japoneses a apresentar a arquitetura Ginga do Sistema Brasileiro de TV Digital Terrestre. A partir de então, pesquisadores da PUC-Rio vem participando das delegações brasileiras organizadas pela Anatel, para a defesa da proposta brasileira junto aos delegados da UIT-T no “study group 16 - codificação, sistemas e aplicações multimídia”.

A Recomendação H.761 representa um marco na evolução tecnológica do país, pois trata-se de um documento aprovado a partir de uma proposta integralmente brasileira, descrevendo uma tecnologia genuinamente nacional. Com a padronização, operadores de telecomunicações e radiodifusores de todo o mundo podem adotar uma tecnologia madura e bem definida, de forma interoperável entre os diversos provedores de conteúdo interativo. Fabricantes de receptores DTV podem desenvolver seus produtos seguindo as normas estabelecidas e permitindo sua comercialização para múltiplas redes e múltiplos mercados. Ginga-NCL é o primeiro framework de aplicações multimídia para serviços IPTV aprovado pela UIT-T.\

Parabéns ao pessoal do Telemídia/PUC-Rio e a todos nós, que ousamos sonhar e trabalhar para elevar o patamar tecnológico so país. Merecido reconhecimento.

S	T	Q	Q	S	S	D
« Abr				Jun »
				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	28	29	30	31

Maio de 2009

Trabalhando com links e conectores na linguagem NCL

Lua - Estruturas de dados: Tabelas

Números da internet

TV digital deslancha

A Nexted Context Language (NCL)

TV OLED vem aí

JavaDTV oficial

NCL e Ginga-NCL são aprovados como padrão internacional UIT-T

Arquivos:

Categorias: