RNPTV-UmServiçoparaIntegraçãoeDistribuiçãodeCanaisdeTVatravésdaInternet

(1)

RNPTV: Um Serviço para Integração e Distribuição de

Canais de TV através da Internet

Carlos E. S. Dias

Laboratório de Aplicações de Vídeo Digital - LAVID

Universidade Federal da Paraíba João Pessoa – Paraíba + 55 83 3216-7093, ramal 26

hacks@lavid.ufpb.br

Anselmo L. Gomes

anselmo@lavid.ufpb.br

Felipe S. de Oliveira

felipe@lavid.ufpb.br

Carlos E. C. F. Batista

bidu@lavid.ufpb.br

Guido L. de S. Filho

guido@lavid.ufpb.br

Gregório E. L. de Melo

gregorio@lavid.ufpb.br

Thiago Falcão

falcao@lavid.ufpb.br

ABSTRACT

The RNPTV service proposes an infrastructure to integrate and distribute TV channels over the Internet constituted by audiovisual content that already exist on the Internet and conventional TV channels. As being a heterogeneous content, where there is a great diversity of video encoding formats, the acknowledgment and adaptation of these formats is necessary to the service. Besides this, an adaptation of the information about these videos – the metadata – is also needed. The creation of the TV channels for the Internet is made with the Program Schedule tool, which accesses the database of the service's metadata looking for available videos to be used in the creation of the schedule. To distribute the channel, a system responsible for the transcoding of the selected videos was developed in order to generate a single continuous, homogeneous flow, which is sent to the RNP's Digital Video Network (RVD) to be broadcasted. Finally, the interaction with the service is done through the RNPTV Portal, where it is possible to access available channels using a Web EPG

(Electronic Programming Guide) and interact with the service and other users, through the Portal's content customization system. This system allows the creation of social networks involving the users of the service. The whole Portal was developed with the Authentication and Access Control Middleware (MACA), which gives the needed support for the permission control within the Portal.

RESUMO

O serviço RNPTV propõe uma infra-estrutura para integrar e distribuir canais de TV na Internet constituídos por conteúdo audiovisual já existente na Rede, além de canais de TV convencional. Por se tratar de um conteúdo heterogêneo, onde existe uma diversidade de formatos de codificação de vídeos, é necessário o reconhecimento e adaptação desses formatos ao serviço. Além disso, é preciso adaptar também as informações sobre esses vídeos – os metadados. A criação dos canais de TV para a Internet é feita através da ferramenta de Grade de Programação, que acessa a base de metadados do serviço à procura dos vídeos disponíveis para utilizar na criação da grade. Para distribuir o canal, foi desenvolvido um sistema de transcodificação dos vídeos selecionados para formar o canal em um único fluxo contínuo e homogêneo que é repassado para a Rede de Vídeo Digital da RNP (RVD) para distribuição. Por fim, a interação com o serviço é feita através do Portal RNPTV, onde é possível acessar os canais disponíveis através de um Web EPG (Electronic Programming Guide) e interagir com o serviço e

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

WebMedia'07, October 21-24, 2007, Gramado, RS, Brazil. Copyright

(2)

outros usuários, através do sistema de personalização de conteúdo do Portal. Este sistema permite a criação de redes sociais envolvendo os usuários do serviço. Todo o Portal foi desenvolvido com o Middleware de Autenticação e Controle de Acesso (MACA) que dá o suporte necessário ao controle de permissões no Portal.

Categories and Subject Descriptors

C.2.1 [Computer-communication Networks]: Network Architecture and Design - distributed networks. D.2.11 [Software

Engineering]: Software Architectures - Domain-specific architecture. H.5.1 [Information Interfaces and Presentation]: Multimedia Information Systems – video, audio input/output. J.7 [Computers in Other Systems]: consumer products, publishing.

General Terms

Performance, Management.

Keywords

GTTV, digital TV, digital video, video metadata.

1. INTRODUÇÃO

No contexto de convergência midiática vivido nos dias de hoje, o crescimento na demanda de aplicações multimídia foi quase que natural: meios de comunicação por todo o mundo pararam de se satisfazer – e de satisfazer sua clientela, por conseguinte – simplesmente por imprimir texto ou mostrar uma ou outra foto. A exigência de serviços que aliem texto, imagens estáticas, áudio e vídeo tornaram-se comum, e o mercado mundial de comunicação se apóia, hoje, cada vez mais na tecnologia e nos serviços oferecidos pelo futuro que se desdobra.

Dessa forma, é natural visualizarmos a Internet como sendo o meio perfeito para receber todo o fluxo de convergência de serviços que procura, atualmente, se reciclar e estruturar releituras de suas antigas contrapartes. Entre tantos, um dos meios que se destaca nessa empreitada é justamente a televisão, que, em sua dita "fusão" com a Rede alia dois fatores mais relevantes em seu mútuo sucesso: a quantidade de espectadores envolvidos no mercado televisivo e as possibilidades de velocidade e alcance dos serviços da Internet.

A transmissão de um canal de TV aberta tem sua abrangência limitada por fatores físicos. Com o advento da Internet, contudo, surge a possibilidade de emissoras disponibilizarem sua programação através da Rede, o que, em teoria, permite que a sua audiência passe a ter uma maior abrangência: com uma estrutura de grade de programação não-linear, com vídeos podendo ser assistidos sob demanda, o espectador transforma-se em co-autor da programação, passando a ter mais autonomia sobre o que assiste, sem precisar necessariamente ser uma audiência passiva, esperando pelos horários dos programas.

Pensando nisto, a Rede de Nacional de Ensino e Pesquisa (RNP), através de desdobramentos dos projetos Infra-estrutura Internet2 para Desenvolvimento e Teste de Programas e Ferramentas para TV Interativa (I2TV), Desenvolvimento de Software e Hardware para Sistemas de Televisão Digital de Alta Definição (HiTV) e do Grupo de Trabalho de Vídeo Digital (GTVD), criou o Grupo de Trabalho de Televisão Digital (GTTV), destinado ao desenvolvimento de plataformas que não só viabilizem, mas

potencializem as transmissões de TV através da Internet, com recursos disponíveis no âmbito de TV digital. Dessa forma, a intenção é que a infra-estrutura desenvolvida em conjunto com as aplicações seja utilizada para transmissão de canais de interesse da RNP e de suas instituições parceiras, criando a Rede de Televisão Digital da RNP (RTD RNP).

O GTTV desenvolveu uma infra-estrutura que permite aos usuários da Rede de Vídeo Digital (RVD) da RNP, terem acesso ao conteúdo de canais de TV distribuídos através da Internet. O acesso aos canais é feito através de uma aplicação navegadora de canais, um Guia Eletrônico de Programação (EPG) pela Web, que acessa uma base de metadados dos programas e canais cadastrados no serviço. Por meio do Web EPG os usuários da RVD podem fazer buscas por canais e programas, entre outros formatos de metadados.

A seguir, são apresentados mais detalhes sobre o serviço. A seção 2 apresenta detalhes sobre a infra-estrutura de rede que dá suporte à transmissão dos vídeos. A seção 3 trata da arquitetura do serviço, definindo o papel de cada camada. A seção 4 explica como o fluxo de vídeo do canal é produzido, apresenta os principais componentes do serviço, e como ele é finalmente exibido ao usuário final. Por fim as conclusões e trabalhos futuros são apresentados na seção 5.

2. A REDE DE VÍDEO DIGITAL DA RNP

A Rede Vídeo Digital (RVD) da RNP foi desenvolvida com o intuito de disponibilizar uma infra-estrutura de rede, servidores e equipamentos para dar suporte a experimentos que envolvam a captura, recuperação e transmissão de vídeo ao vivo e sob demanda. A RVD foi concebida durante as duas fases do Grupo de Trabalho de Vídeo Digital da RNP.

Durante a Fase I, cujo foco era o suporte a transmissões de vídeo sob demanda, foi montada uma infra-estrutura com máquinas posicionadas nos PoPs (pontos de presença RNP) RS, SC, SP, RJ, DF, PE e CE e nas universidades UFPB, UFRN e UFBA interligadas através da RNP. Na Fase II, o serviço foi estendido para fornecer suporte a transmissões ao vivo e sob demanda de forma integrada, além de integrar a RVD a um serviço de armazenamento distribuído – o IBP (Internet Backplane Protocol) [1].

2.1 Arquitetura da RVD

A arquitetura atual do serviço de distribuição oferecido pela RVD [1] baseia-se em uma estrutura de múltiplos níveis de distribuição: servidor-proxy, proxy-proxy e proxy-cliente, podendo existir diversos níveis de distribuição proxy-proxy. A Figura 1 ilustra a arquitetura de distribuição de vídeo.

Os servidores de vídeo atuam como fontes para os fluxos de vídeo digital, fluxos estes que podem advir de arquivos armazenados localmente (vídeo sob demanda) ou de dispositivos de captura (vídeo ao vivo). A idéia é que as instituições colaboradoras (provedoras de conteúdo) responsáveis pelas aplicações usuárias do serviço mantenham seus próprios servidores e recursos associados.

Opcionalmente, para incrementar os requisitos de tolerância a falhas, uma instituição poderá utilizar diversos servidores de vídeo, onde cada servidor de vídeo poderá possuir atribuições

(3)

específicas (armazenar parte de um acervo de vídeos, por exemplo).

Figura 1. Arquitetura de distribuição da RVD.

Um proxy também implementa uma cache (armazenada em memória volátil para vídeos ao vivo e em disco para vídeos sob demanda), utilizada por aqueles vídeos de maior audiência em sua área de atendimento. A arquitetura permite a conexão em cascata de proxies, configurando assim uma hierarquia de múltiplos níveis de cache. A principal vantagem desta abordagem é a distribuição otimizada do tráfego no backbone da RNP, redes regionais, redes institucionais e até mesmo nas redes locais [2].

Os servidores e proxies que compõem a arquitetura de distribuição possuem papéis distintos e bem definidos, porém os mesmos possuem em comum o fato de recuperarem o vídeo a partir de uma determinada fonte e distribuírem o mesmo para um determinado destino [2]. No caso do servidor de vídeo, a fonte pode ser o sistema de arquivos local (vídeo sob demanda) ou um dispositivo de captura de vídeo (vídeo ao vivo), enquanto que o destino poderá ser um proxy do serviço ou um cliente que o acessa diretamente.

No caso do proxy, a fonte pode ser um servidor de vídeo ou outro

proxy, enquanto o destino pode ser outro proxy ou o cliente.

Diferem, então, apenas nos tipos de fontes e destinos, enquanto o controle de fluxo entre a fonte e o destino é basicamente o mesmo. O desenvolvimento das fontes e destinos foi feito de forma modular, permitindo o acoplamento de diversos destinos e fontes. Isso é possível em tempo de configuração, ou até mesmo em tempo de execução, viabilizando assim uma implementação única para servidores e proxies de vídeo.

2.1.1 Servidores da RVD

A implementação do servidor-proxy da RVD possui duas instâncias com base em uma arquitetura única (apresentada na Figura 2): o JDVoD [1], que dá suporte a vídeos sob demanda, e o JDLive [3], que dá suporte à vídeos ao vivo. Ambos desenvolvidos em Java (o JDVoD foi desenvolvido a partir de uma versão prévia em C [4]), estes servidores, cujas funcionalidades foram concebidas com base nos requisitos da arquitetura da RVD previamente apresentados, suportam múltiplos protocolos para entrada (IBP, HTTP, UDP) e saída (HTTP e UDP).

Figura 2. Arquitetura comum do JDVoD e do JDLive

3. ARQUITETURA DO SERVIÇO

O serviço é dividido em camadas, onde cada camada provê serviços para a camada subseqüente da arquitetura. Esta abordagem oferece flexibilidade e independência aos serviços, pois cada camada funciona como um subsistema independente. A Figura 3 apresenta a arquitetura em camadas do serviço RNPTV.

Figura 3: Arquitetura do Serviço

Como podemos ver na Figura 3, a arquitetura do serviço é dividida em cinco camadas: produção de conteúdo, fornecimento do conteúdo, adaptação, distribuição e apresentação.

3.1 Produção de Conteúdo

Para alimentar o serviço proposto é necessária a parceria com entidades de produção de conteúdo audiovisual. Essas entidades são, principalmente, estações de TV e rádio e produtoras independentes de programas.

Nesta camada é assumido que as entidades fornecem o conteúdo audiovisual em algum padrão digital de codificação de áudio e vídeo, como MPEG-2, MPEG-4, Windows Media, entre outros.

3.2 Fornecimento de Conteúdo

A disponibilização do conteúdo das entidades produtoras é feito através dos fornecedores de conteúdo que são entidades responsáveis por armazenar e disponibilizar o acesso ao acervo de conteúdo audiovisual. Exemplos de sistemas com essas características são a Rede de Vídeo Digital da RNP [3], ou fontes externas à RVD, como o Google Video [5] e o YouTube [6], entre outros. Este conteúdo é disponibilizado de duas maneiras diferentes: vídeo sob demanda e vídeo ao vivo.

(4)

Um serviço de Vídeo sob Demanda (VoD, do inglês Video on

Demand) típico, permite que usuários remotos tenham acesso a

uma coletânea de vídeos variados. Tipicamente os arquivos destes vídeos são armazenados em um conjunto centralizado de servidores e distribuídos através de uma conexão de rede de alta velocidade para clientes dispersos geograficamente. Ao receber uma requisição de um cliente, o servidor envia a resposta como um fluxo de vídeo, sem necessidade de sincronização prévia. Para que o objetivo seja atingido, é necessária uma infra-estrutura de armazenamento e uma rede de distribuição com banda passante suficiente para que uma transmissão de vídeo contínua seja possível [7]. Um sistema de VoD é composto basicamente por três entidades: um servidor VoD (que armazena o acervo de vídeos), clientes remotos (que fazem requisições e exibem o conteúdo dos vídeos) e finalmente uma rede de distribuição de conteúdo (responsável por interconectar clientes e servidores) [8].

O serviço de vídeo ao vivo, por sua vez, é similar ao sistema sob demanda, porém o acervo de vídeos é gerado em tempo real, utilizando-se câmeras de captura de áudio e vídeo. O fluxo capturado é direcionado aos servidores que se encarregam de distribuir o vídeo [3].

No contexto do RNPTV, o conteúdo a ser acessado pelos usuários pode ser tanto de fornecedores de conteúdo localizados em servidores da Rede de Vídeo Digital (RVD), como de servidores externos, localizados fora da RVD. Além de servidores de vídeo ao vivo ou sob demanda, o serviço é capaz de agregar canais convencionais de TV, através de processos de codificação com

software e hardware específicos.

3.3 Camada de Adaptação

O acerto de vídeos disponibilizado pelos fornecedores de conteúdo muitas vezes é heterogêneo, existindo uma diversidade de formatos de codificação. Além disso, as informações sobre o vídeo – os metadados – podem estar incompletas ou não existirem. A camada de adaptação é então responsável por reconhecer o formato e/ou codificação de vídeo e dos metadados dos fornecedores de conteúdo e adaptá-los ao serviço, de forma padronizada e eficiente.

3.3.1 Codificação

O objetivo da adaptação na codificação é reconhecer o máximo de padrões de vídeo e áudio, tanto para a leitura quanto para a geração de novos vídeos em outros padrões. Dentre inúmeros padrões existentes, alguns têm maior destaque, pela grande popularidade. Alguns exemplos são: Windows Media Video, DivX , XviD, Flash Vídeo, MPEG-1, MPEG-2, Quicktime Movie, Mpeg Layer 3 (MP3), Windows Media Audio, dentre outros.

Também é necessário flexibilidade no acesso aos meios de armazenamento e distribuição dos vídeos, que podem estar localizados em discos rígidos, CDs ou DVDs, tipicamente para o caso de vídeos sob demanda, ou em fluxos de vídeo através da rede, usando unicast ou multicast. Neste último caso, existe a necessidade de reconhecer também padrões de transmissão de fluxo de vídeos, como HTTP, MMS, RTP/RTSP, entre outros.

3.3.2 Metadados

A convergência entre os serviços de televisão e web tem expandido o desenvolvimento das plataformas fornecedoras de serviços personalizados e de buscas baseadas em objetos, entrega e recepção de informações, resultando em cada vez mais opções de escolha para os espectadores-usuários. O detalhe é que, com o crescente número de canais e serviços interativos sendo disponibilizados dia após dia, o público passa a ter acesso a grades de programação armazenadas local e remotamente. Para tornar este modelo de TV Digital possível, é necessário um esquema de catalogação de metadados para os objetos multimídia, facilitando, assim, seu acesso por parte dos usuários. Para tanto, foi utilizado o TV-Anytime, padrão de descrição de metadados para TV Interativa [9]. Uma vantagem da padronização dos metadados é justamente garantir a portabilidade entre sistemas que fazem uso de tais ferramentas de descrição.

Cada vídeo em um serviço de distribuição possui metadados de catalogação e identificação associados. Estes metadados podem ter sido fornecidos pelo proprietário do vídeo, como nome, autor, data de criação, mas também são dados inerentes do próprio vídeo, como quadros por segundo, resolução, tamanho, taxa de bits por segundo.

A regra de se conhecer o maior número de padrões de metadados existentes também é válida aqui, porém com mais cautela, pois os padrões de metadados são em maior número do que os padrões de codificação de vídeo, por exemplo, e também mais flexíveis. Deve haver uma avaliação criteriosa quanto à necessidade de conhecimento de determinados metadados.

3.3.3 Personalização

O serviço de personalização fornece a opção de criação de perfis sobre o serviço, com a escolha programas e canais favoritos, fazer comentários, avaliar os vídeos de acordo com sua preferência, entre outras opções, interagindo com o sistema de forma pessoal. Além da interação pessoal, a personalização oferece a interação entre usuários do mesmo serviço, possibilitando a criação de uma rede social com o objetivo de prover a comunicação dos usuários entre si e para viabilizar uma rede de compartilhamento de conteúdo.

3.4 Camada de Distribuição

A camada de distribuição é constituída por uma rede de servidores de vídeo responsáveis por prover uma infra-estrutura de distribuição de conteúdo multimídia, sob a forma de vídeo ao vivo ou sob demanda, utilizando-se diversos meios de difusão da informação pela rede, como conexões multicast, unicast.

Em uma rede de vídeo digital também está presente o serviço de metadados, ou seja, uma base de dados onde os usuários terão acesso às informações pertinentes ao conteúdo cadastrado no serviço.

3.5 Camada de Apresentação

Nesta camada os serviços têm por finalidade a interação dos serviços das outras camadas com o usuário final. Ao usuário devem ser apresentadas interfaces de acesso ao sistema, com a apresentação do conteúdo visual através de players, sistemas de busca, de personalização, de gerenciamento, entre outros.

(5)

4. RNPTV

O serviço RNPTV foi desenvolvido como uma aplicação usuária da RVD e está modelada de acordo com a Arquitetura do Serviço, apresentada no item 3. A Figura 4 apresenta a arquitetura do RNPTV.

Figura 4: Arquitetura RNPTV

4.1 Base de Dados

A base de dados do sistema consiste em metadados relativas aos vídeos e canais cadastrados, funcionando como um repositório de metadados para objetos multimídia cadastrados. Além destas, também são mantidos na base de dados as informações dos usuários do sistema e grades de programação do canal da RNP. Dentre as informações pertinentes, estão presentes: o título, duração, gênero e língua do vídeo, dentre outras; aos canais, país, língua, taxa de aspecto e taxa de transferência dos bits do fluxo de vídeo integram os metadados. Os dados relativos aos usuários são: nome, nome de usuário e senha. Relativo às grades de programação, as informações persistidas são os horários de início e fim de execução da grade e os vídeos que a compõem.

Para gerenciar estes dados, o sistema gerenciador de bancos de dados (SGBD) escolhido foi o PostgreSQL [10], uma vez que este atende os requisitos especificados para o RNPTV e não apresenta custos para aquisição de licenças de uso. Visando facilitar a interação entre o SGBD e a aplicação, foi adicionada ao sistema uma camada mais de persistência que gerenciasse a impedância objeto-relacional, gerada pelo uso de diferentes paradigmas, objetos JAVA na aplicação e tabelas relacionais no SGBD. Para esse gerenciamento foi utilizado o Hibernate [11].

4.2 Gerenciador de Metadados

O Gerenciador de Metadados é responsável por gerenciar o acesso aos dados cadastrados no sistema. Os serviços de inserção de dados, busca, atualização e remoção de informações são prestados pelo Gerenciador de Metadados, possibilitando a validação dos dados antes de realizar a operação solicitada pelo usuário do sistema. Para a realização desses serviços, o Gerenciador de Metadados recebe as informações do usuário e, caso estas sejam informações válidas, abre uma sessão para a comunicação com a base de dados e realiza a operação solicitada.

4.3 Sistema de Autenticação

O Sistema de Autenticação é responsável pela definição das permissões dos usuários do Portal RNPTV. O sistema utiliza o modelo de separação de responsabilidades, onde o usuário tem

papéis associados. Cada papel representa um conjunto de permissões de autorização para executar operações dentro sistema, de forma que o usuário só terá permissão de acessar as partes do sistema definidas em seu papel.

Para isso é utilizado o Middleware de Autenticação e Controle de Acesso (MACA) que disponibiliza serviços de autenticação de usuários e controle de acesso para aplicações legadas ou em fase de desenvolvimento. É um sistema independente de plataforma e linguagem de programação que segue o modelo para controle de acesso baseado em papéis (CABP) padronizado pelo National Institute Standards and Technology (NIST) [12]. O CABP tem características adequadas para definição e administração viável de políticas de acesso, particularmente em aplicações corporativas emergentes, que demandam um controle com granularidade fina para um grande número de usuários e recursos [13].

4.4 Geração de Canais

O canal da RNP é constituído de programas oriundos de diferentes produtores, com diferentes formatos de codificação. Além da diferença de formatos, estes programas se encontram em diferentes servidores, não necessariamente dentro da rede de vídeo digital da RNP. O canal também pode ser composto por programas ao vivo, onde se faz necessário o controle da duração da exibição de programas deste tipo. Por isso, tornam-se essenciais mecanismos de aquisição de programas, de controle de tempo de exibição destes e de transcodificação dos vídeos.

4.4.1 Aquisição de conteúdo

Como dito previamente, os vídeos que compõem o canal da RNP não necessariamente encontram-se em seus servidores. Tal característica foi definida durante o período de análise do sistema, já que, além de evitar possíveis limitações de armazenamento que pudessem surgir, permite que sejam feitas parcerias com diferentes produtores de conteúdo e o material compartilhado possa ser incluído nas grades de programação do canal da RNP, o que pode ser considerado uma das principais características do sistema.

Durante a inicialização do sistema, ocorre a verificação da existência da presença de grades de programação com início a partir da data e horário de inicialização do sistema, ordenadas pelo seu horário de início. Sendo encontrada alguma grade, o Controlador de Execução, entidade responsável pela execução e controle do tempo de exibição de cada grade e seus programas, aguarda o início desta grade para iniciar suas atividades. Uma vez em tempo de ser executado, o controlador verifica a lista de programas presentes na grade de programação, solicita ao Gerenciador de Metadados alguns dados relativos a estes programas e prepara uma lista com estes dados. Estão presentes neste conjunto de dados a URI indicando o endereço do vídeo, a duração e os horários de início e fim de cada programa que compõe a grade. Além disso, o controlador precisa ser informado se o vídeo corresponde a um programa ao vivo ou não, para indicar a necessidade ou não de controlar a duração da execução deste programa.

De posse deste conjunto de informações relativas aos vídeos da grade de programação sendo executada, o controlador está pronto para iniciar a exibição da grade e a transcodificação dos vídeos. O controlador solicita ao Sistema de Transcodificação que seja

(6)

criada uma lista de execução com os endereços dos vídeos que compõem a grade de programação, sendo o Sistema de Transcodificação a entidade responsável por gerar o fluxo de vídeo do canal com os vídeos da lista, transcodificando-os durante sua exibição. Para vídeos sob demanda, os quais são sempre executados em sua íntegra, não há a necessidade de se verificar o tempo de execução de cada vídeo. Assim, para este caso, o Controlador de Execução apenas acompanha o andamento da transcodificação dos vídeos.

Como o Sistema de Transcodificação mantém-se transcodificando um dado vídeo até que o fluxo deste seja interrompido, é necessário que o Controlador de Execução intervenha no controle da transcodificação de vídeos ao vivo, de modo que estes tenham sua transmissão encerrada dentro do horário estipulado na grade de programação. Caso contrário, a transcodificação do vídeo ao vivo poderia prolongar-se para além do previsto na grade de programação, corrompendo a grade de programação.

Apesar de acontecer com pouca freqüência, os vídeos podem não ser encontrados quando sua execução for solicitada. Quando o Controlador de Execução inicia a execução de uma grade, este deve verificar se o endereço dos vídeos que compõem a grade ainda possa ser encontrado a partir do URI fornecido. Caso tal condição não seja satisfeita para alguns dos vídeos presentes na grade, o controlador deve evitar que esta fique corrompida, com os vídeos que a compõe possuindo horário de início e fim diferentes do que foi definido anteriormente. Assim, o Controlador de Execução solicita ao Sistema de Transcodificação que este inicie a transcodificação de um vídeo padrão, o qual contém uma mensagem de erro, e, ainda, controla a duração da exibição deste vídeo, atuando da mesma forma como para programas ao vivo, com a duração correspondendo àquela definida para o vídeo que não foi encontrado. Deste modo, evita-se a corrupção da grade de programação, uma vez que o vídeo inexistente é substituído, preservando, assim, os horários de início de cada programa definidos na geração da grade.

4.4.2 Sistema de Transcodificação

Dado que nem todos os vídeos da base de vídeos do sistema possuem um mesmo padrão de codificação e que é necessário que haja um único formato para transmissão do fluxo de vídeo gerado, surge a necessidade de um sistema de transcodificação capaz de decodificar a maior quantidade possível de formatos de codificação e codificar em um formato compatível com a maioria dos players multimídia disponíveis. Além disso, o sistema de transcodificação deve ser capaz de receber um endereço de um vídeo, o qual não necessariamente estará presente no mesmo sistema de arquivos do transcodificador, decodificá-lo assim que lhe for solicitado e codificá-lo no padrão escolhido, simultaneamente.

Para atender a estes requisitos, o software escolhido foi o VideoLAN (VLC) [14]. O VLC consegue decodificar a maioria dos formatos de vídeo existentes, a partir de diversas fontes, como discos rígidos, HTTP, MMS, RTP/RTSP, entre outras. Entre suas funcionalidades desejáveis ao serviço está a habilidade de criar listas de reprodução a partir de diversos endereços na Internet. Além disso, para o desenvolvimento do sistema de transcodificação foram necessárias modificações no VideoLAN possível apenas por ser um software licenciado sob GPL [15].

Quando do início da execução de uma grade de programação, o Controlador de Execução inicia uma conexão TCP com o VLC, criando uma lista de reprodução do VLC, contendo URIs indicando os endereços dos vídeos que compõem a grade de programação, e configura os parâmetros de transcodificação dos vídeos e a saída do fluxo de vídeo resultante. Terminada a exibição da grade de programação, o Controlador de Execução solicita ao VLC que o processo de transcodificação seja finalizado (caso o próprio VLC ainda não tenha realizado tal finalização). Em seguida, o controlador encerra a conexão TCP com o VLC e aguarda o início da programação seguinte para restabelecer uma nova conexão e iniciar um novo processo de exibição de grade de programação, semelhante para cada grade de programação. O fluxo de vídeo do canal de TV gerado durante o processo descrito acima é, então, disponibilizado para ser exibido no tocador multimídia do usuário final. Por serem utilizados padrões de codificação de áudio e vídeo que podem ser interpretados pela maioria das aplicações decodificadoras, é permitido ao usuário final do canal da RNP a escolha de qual aplicação utilizar para a decodificação. E, de modo a facilitar o acesso ao canal, decidiu-se, além disso, embutir um tocador no Portal RNPTV, detalhado a seguir.

4.5 O Portal RNPTV

O Portal RNPTV, é a interface de interação com os usuários finais da aplicação. Ele inclui suporte a buscas e visualização dos programas e canais disponíveis, possibilita a interação entre usuários do portal, a classificação de programas e o gerenciamento de conteúdo. Além disso, o Portal também disponibiliza um guia de programação, responsável por apresentar as grades de programação do canal da RNP, permitindo que o usuário colete informações por ele desejadas interativamente. O Portal apresenta como principais funcionalidades o fluxo de vídeos do canal da RNP em um tocador multimídia embutido em sua página principal; o Web EPG, uma ferramenta que permite ao usuário navegar pelo guia de programações; um conjunto de canais associados, separados por taxa de transferência de bits de seus fluxos de vídeo; e uma ferramenta desenvolvida para auxiliar à geração de grades de programação do canal da RNP.

4.5.1 Trabalhos Relacionados

Atualmente podem ser encontradas várias TVs que transmitem seu conteúdo pela Internet em tempo real, bem como canais de TV exclusivamente virtuais. Podem ser citados, como exemplos, o Research Channel [16], o ALLTV [17], e a TV UOL [18]. Estes serviços agregam vídeos sob demanda, os quais encontram-se em seus servidores, de modo a formar grades de programação. A relevância do Canal da RNP consiste em permitir, também, a agregação de conteúdo de fontes diversas na Internet através de entidades fornecedoras de conteúdo e do serviço de distribuição de vídeo da Rede de Vídeo Digital. A plataforma também permite que vídeos ao vivo sejam adicionados às grades de programação, o que permite a apresentação de conteúdo de câmeras de captura de vídeo em tempo real e de outros canais na Internet. O RNPTV ainda conta com o diferencial de gerar um canal com um formato de codificação homogêneo, com as mídias transcodificadas (através do processo de Geração de Canais), um formato padrão de metadados e serviços de personalização de usuários.

(7)

4.5.2 Canal

O fluxo de vídeo gerado como resultado da transcodificação dos vídeos de uma programação do canal da RNP é exibido na página principal do portal, sendo decodificado por um tocador multimídia embutido na página. Este mesmo fluxo pode ser decodificado por um tocador multimídia standalone, caso o usuário assim prefira. Junto ao player multimídia são apresentadas algumas informações inerentes ao vídeo em exibição, como título, descrição e duração. Também são apresentados os títulos e os horários de início dos programas seguintes dentro da grade de programação sendo exibida.

4.5.3 Web EPG

De modo a facilitar o acesso às informações das programações e seus programas, foi desenvolvido o Web EPG, uma ferramenta que permite aos usuários navegar pelas programações cadastradas no sistema e consultar informações relativas aos programas presentes nestas programações. O Web EPG, a interface do guia de programação do RNPTV, acessado através da Internet, será responsável por exibir a programação dos canais parceiros que disponibilizem sua programação.

4.5.4 Pacotes de Canais

Além do fluxo principal de vídeo do canal RNP, exibido na página principal do Portal RNPTV, o portal também permite que seus usuários tenham acesso a fluxos de vídeo também gerados pelo sistema, composto de vídeos com definições de qualidade superiores aos vídeos do fluxo principal. Tais fluxos são agrupados a partir de suas taxas de transferência de bits. O portal permite, ainda, que, através dele, fluxos de vídeo provenientes de canais parceiros sejam acessados.

4.5.5 Ferramenta de Geração de Grades de

Programação

Para auxiliar na geração de grades de programação para o canal da RNP, foi desenvolvida uma ferramenta que permite ao usuário associar vídeos da base de vídeos do sistema a grades de programação. O usuário do sistema responsável por criar tais grades, durante o início do processo de criação da grade, indica a data e o horário de início da grade em questão. A ferramenta, então, disponibiliza a tal usuário um mecanismo de busca por vídeos que podem ser incluídos na grade. O usuário criador da grade, então, adiciona os vídeos desejados na grade de programação, os quais são adicionados um após o outro. O horário de início de cada programa depende da duração do vídeo anterior. Caso um dos vídeos desejados seja um vídeo ao vivo, a ferramenta solicita ao usuário que este forneça por quanto tempo o vídeo deve ser executado.

5. CONCLUSÃO

O presente trabalho apresentou o serviço RNPTV, que permite a integração e distribuição de canais de TV e canais convencionais pela Internet. Foi apresentada a definição de uma arquitetura de distribuição do serviço, modelada em camadas que funcionam como subsistemas independentes, dando maior flexibilidade de desenvolvimento de aplicações para o serviço. Já o serviço RNPTV foi proposto como uma aplicação usuária da Rede de Vídeo Digital da RNP, modelada sobre as camadas da arquitetura

de serviço. Foi desenvolvido todo um conjunto de ferramentas de suporte ao usuário do serviço para a criação dos canais e gerenciamento do serviço, bem como para a interação do usuário com o serviço, este último feito através do Portal RNPTV. Como trabalhos futuros, pretende-se integrar o RNPTV com outros serviços de distribuição de vídeo, como possíveis provedores de conteúdo. No contexto da TV Digital Interativa, pretende-se integrar a infra-estrutura do serviço ao Middleware de TV Digital Ginga [19].

6. REFERÊNCIAS

[1] BATISTA, Carlos Eduardo Coelho Freire; HAGEWOOD, Mark Hunter; SALMITO, Tiago Lima; LEITE, Luiz Eduardo Cunha; SILVEIRA, Glêdson Elias da; SOUZA FILHO, Guido Lemos de. J.D-VoD - Usando um Serviço de Armazenamento em Rede para Distribuir Vídeo sob Demanda. In: XI SIMPÓSIO BRASILEIRO DE MULTIMÍDIA E WEB - WEBMEDIA, 2005, Poços de Caldas. XI Simpósio Brasileiro de Multimídia e Web - WebMedia. 2005. p. 87-99.

[2] BATISTA, Carlos Eduardo Coelho Freire; SALMITO, Tiago Lima; LEITE, Luiz Eduardo Cunha; SOUZA FILHO, Guido Lemos de; SILVEIRA, Glêdson Elias da. Big Videos on Small Networks. In: MSAN - FIRST INTERNATIONAL CONFERENCE ON MULTIMEDIA SERVICES ACCESS NETWORKS, 2005, Orlando. 2005 1st International Conference on Multimedia Services Access Networks. 2005. v. 1, p. 15-19.

[3] SOUSA FILHO, G. F. de, SILVA, L. D. N. e, SILVEIRA, G. E. da, SOUZA FILHO, G. L. de, LEITE, L. E. C.. Uma Arquitetura Hierárquica e Distribuída para um Serviço de Distribuição de Vídeo ao Vivo. In: ___. X Simpósio Brasileiro de Sistemas Multimídia e Web (WebMedia) – Salão de Ferramentas, Ribeirão Preto – SP, Outubro, 2004 [4] SALMITO, T. L., FARIAS, J. P. F., SILVEIRA, G. E. da,

LEITE, L. E. C., FILHO, G. L. S.. Uma Arquitetura Hierárquica e Distribuída para um Serviço de Distribuição de Vídeo sob Demanda. In: ___. X Simpósio Brasileiro de Sistemas Multimídia e Web (WebMedia), Ribeirão Preto – SP, Outubro, 2004.

[5] Disponível em http://video.google.com. Acesso em: 12 Jul. 2007.

[6] Disponível em http://www.youtube.com. Acesso em: 13 Jul. 2007.

[7] MA, H., SHIN, K. G.. Multicast Video-on-Demand Services. In: ___. ACM Computer Communication Review. vol. 32, no. 1, Janeiro, 2002.

[8] PINHO, L. B., Ishikawa, E., and Amorim, C. L.. Glove : A distributed environment for scalable video-on-demand systems. In: ___. International Journal of High Performance Computing Applications, vol. 17 n.2. Sage Publications, Maio, 2003.

[9] TV-ANYTIME FORUM. Specification Series: S2 on: Systems Description, Final Specification , fev. 2003. Metadata, Version 1.1, Corrigendum 2. Disponível em:<ftp://tva:tva@ftp.bbc.co.uk/Specifications/SP001v12.zi p>. Acesso em: 02 Mar. 2007.

(8)

[10] MOMJIAN, Bruce, PostgreSQL: introduction and concepts, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 2001

[11] BAUER, Christian; KING, Gavin. Hibernate In Action. Manning Publications, 2004.

[12] MOTTA, G. H.M.B e Sérgio S.F. Um Modelo de Autorização Contextual para o Controle de Acesso Baseado em Papéis.

[13] MOTTA, Gustavo. MACA – Middleware de Autenticação e Controle de Acesso. Versão 3.3.2. Maca Administrativo - Manual do Usuário São Paulo, setembro de 2005.

[14] Disponível em http://www.videolan.org. Acesso em: 02 fev. 2007

[15] GPL, General Public License. Acesso em: 05 de Jun 2007. [16] Disponível em http://www.researchchannel.org. Acesso em:

10 fev. 2007.

[17] Disponível em http://www.alltv.com.br/. Acesso em: 15 fev. 2007.

[18] Disponível em http://tvuol.uol.com.br/. Acesso em: 16 fev. 2007.

[19] SOUZA FILHO, G. L. de, LEITE, L. E. C., BATISTA, C. E. C. F. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. In: ___. Journal of the Brazilian Computer Society, no 4, Vol 12, (ISSN 0104-6500) pp. 47-56. Março, 2007. Porto Alegre, RS, Brasil.