Agradecimentos

• Ao prof. Luiz Fernando, que muito mais que orientador, foi um amigo inestimável, proporcionando um excelente ambiente de trabalho no nosso laboratório, além do exemplo como docente, pela sua dedicação e empenho;
• À minha esposa Carla, pelo apoio, carinho e compreensão nos momentos em que esta dissertação estava em preparação;
• Aos amigos Selan e Cati pelo apoio dado nos momentos mais difíceis de minha estada aqui no Rio, bem como pelo continuado incentivo e papos descontraídos, arrancando-me do laboratório em vários momentos em que eu precisava desopilar;
• Aos meus irmãos: Jaudelice pelo apoio incondicional dado em todas as circunstâncias de minha vida, Jáuber pelas dicas, constante preocupação e auxílio na preparação da próxima etapa de minha vida e Jaudênia pelo apoio quando da minha chegada ao Rio;
• Aos amigos Reinaldo e Marta pelos ótimos conselhos e opiniões, técnicas ou não;
• Aos amigos da Módulo Informática de Fortaleza, em especial Alexandre Bruno, pelo apoio e incentivo à minha vinda à PUC, bem como pelos papos descontraídos nas melhores pizzarias de Fortaleza;
• A todos os amigos do nosso Laboratório TeleMídia e do Departamento de Informática da PUC-Rio, pelas valiosas idéias e excelente ambiente de trabalho;
• Aos ex-mestres da Universidade Federal do Ceará, pelo embasamento fundamental para um bom desempenho no curso de mestrado;
• Aos amigos de Fortaleza, pelos agradáveis momentos pré-PUC;
• A Arthur Ronald e Márcio Caio, que ajudaram a resolver definitivamente o problema de moradia, quando cheguei ao Rio;
• À CAPES, Embratel e CNPq pelo apoio financeiro fornecido durante todo o desenvolvimento desta dissertação, sem o qual este trabalho sequer teria sido iniciado.

Resumo

Esta dissertação descreve a implementação de um sistema de videoconferência, o TVS (TeleMídia Videoconferencing System), resultado dos estudos realizados no Laboratório TeleMídia do Grupo de Redes e Sistemas Multimídia do Departamento de Informática da PUC-Rio. O TVS é um sistema que possibilita, além da transmissão básica das mídias áudio e vídeo de forma síncrona e padronizada, a manipulação de documentos multimídia/hipermídia, baseada no Modelo de Contextos Aninhados (MCA), em conformidade com a proposta de padrão MHEG. O sistema apresenta suporte à votação e envio de mensagens entre os participantes, além de permitir uma ampla configuração do ambiente. Todo o controle de acesso ao ambiente é realizado por deteção de silêncio, por razões de eficiência com relação à interatividade em uma reunião.

Abstract

This dissertation describes the implementation of a videoconferencing system, the TVS (TeleMídia Videoconferencing System), result of the research done at the TeleMídia Laboratory, part of the Computer Networks and Multimedia Systems Team from the Computer Science Department of the Pontifical Catholic University of Rio de Janeiro, PUC-Rio. TVS is a system that allows the basic transmission of medias such as video and audio in a synchronized and standardized mode. In addition, TVS handles multimedia/hypermedia documents through the Nested Context Model (NCM), according to the MHEG standard proposal. The TVS system supports voting and message sending facilities among participants, in addition to allowing ample environment configuration. The floor control is done by silence detection, in order to improve the interaction among conferees.

1. Introdução

2. Características Desejáveis de um Sistema de Videoconferência

2.1. A Recomendação ITU-T F.730

2.3. Início e Término da Conferência

2.4. Gerenciamento da Conferência

2.5. O Controle de Acesso

2.6. Manipulação Cooperativa de Documentos

2.7. Votação

2.8. Minimização na Utilização do Sistema de Comunicação

2.9. Facilidades Adicionais Desejáveis

3. Trabalhos Relacionados

3.1. Codificação das mídias básicas: áudio e vídeo

3.2. Empacotamento de dados

3.3. Transferência segura de informações

3.4. Sincronismo entre as mídias áudio e vídeo

3.5. Tratamento de Documentos

3.6. Suporte a Votações

3.7. Envio de Mensagens Textuais

3.8. Controle de Acesso (Floor Control)

3.9. Existência de um Coordenador

3.10. Identificação do Interlocutor

3.11. Minimização na Utilização do Sistema de Comunicação

4. Arquitetura do TeleMídia Videoconferencing System

4.1. O Modelo de Contextos Aninhados

4.2. A Estrutura Distribuída do TVS

4.3. O Daemon de Controle e de Conexão

4.4. Interface com o Usuário

4.5. Pré-Conferência

4.6. Início e Término da Conferência

4.7. Gerenciamento da Conferência

4.8. Controle de Acesso ao Ambiente

4.9. A Codificação da Mídia Áudio

4.10. A Codificação da Mídia Vídeo

4.14. Envio de Mensagens Textuais

5. A Implementação

5.1. O Módulo de Interação com o Usuário

5.2. O Daemon de Controle e de Conexão

5.4. A Interação do TVS com os Browsers

5.5. A Interação do TVS com a Máquina HyperProp

5.6. A Manipulação Cooperativa de Documentos Multimídia/Hipermídia

5.7. A Codificação de Áudio e Vídeo

5.8. A Estrutura do Quadro

5.9. O Sincronismo das Mídias Básicas

5.10. O Controle de Acesso ao Ambiente

5.11. A Votação

5.12. Mensagens Textuais

5.13. Números da Implementação

6. Conclusão

6.1. Contribuições da Dissertação

6.2. Trabalhos Futuros

Referências Bibliográficas

A. Código Fonte do Sistema

Lista de Figuras

Figura 3.1: Interface Cornell/CU-SeeMe

Figura 3.2: Interface Xerox Parc/nv

Figura 3.3: Interface LBL-UCB/vic

Figura 3.4: Interface Inria/IVS

Figura 3.5: Arquitetura Ottawa/MCRLab

Figura 3.6: Interface Ottawa/MCRLab

Figura 3.7: Codificação de Vídeo do nv

Figura 3.8: O formato IVS / Super-CIF

Figura 4.1: Hierarquia de Classes do MCA

Figura 4.2: Arquitetura HyperProp

Figura 4.3: Camadas TVS

Figura 4.4: Interações numa Sessão de Videoconferência

Figura 4.5: Interface PUC-Rio/TVS

Figura 4.6: Menu de Conferências

Figura 4.7: Codificador PCM

Figura 4.8: Conversão de valores m -law para A-law

Figura 4.9: Blocos Componentes de um Macro-Bloco

Figura 4.10: Codificador/Decodificador de Vídeo

Figura 4.11: O Macrobloco

Figura 4.12: Camadas H.261

Figura 4.13: Camada Imagem: Diagrama de Sintaxe

Figura 4.14: Camada de Imagem: Diagrama de Bloco

Figura 4.15: Grupos de Blocos CIF e QCIF

Figura 4.16: Camada GOB: Diagrama de Sintaxe

Figura 4.17: Camada GOB: Diagrama de Bloco

Figura 4.18: Macroblocos em um GOB

Figura 4.19: Camada Macrobloco: Diagrama de Sintaxe

Figura 4.20: Endereços dos Macroblocos

Figura 4.21: Tabela de Códigos para MTYPE

Figura 4.22: Códigos para MVD

Figura 4.23: Códigos para CBP

Figura 4.24: Camada de Bloco: Diagrama de Sintaxe

Figura 4.25: Transmissão em Ziguezague

Figura 4.26: H.320: Estrutura de Bloco

Figura 4.27: Recuperação de um Documento

Figura 5.1: Hierarquia de Classes do TVS

Figura 5.2: Formato do Quadro da Camada de Controle

Figura 5.3: Mensagens de Controle

Figura 5.4: Diagrama de Estados do Daemon

Figura 5.5: Formato do Quadro da Camada Browser

Figura 5.6: Formato do Quadro da Camada HyperProp

Figura 5.7: Formato do Quadro de Transmissão de Mídias

Figura 5.8: Valores do Campo cType

Figura 5.9: O Mecanismo de Controle de Acesso

Figura 5.10: O Diálogo de Envio de Mensagens

Figura 5.11: Dados da implementação

Figura 6.1: Quadro Comparativo dos Sistemas de Videoconferência

Figura 6.2: TVS sobre ATM, Modelo A

Figura 6.3: TVS sobre ATM, Modelo B

1. Introdução

O ser humano, por sua natureza social e para aquisição de conhecimentos, necessita de grande interação com os seus semelhantes. Com o avanço da espécie, a dispersão em áreas cada vez maiores trouxe dificuldades na tão necessária troca de informações. Para amenizar o problema, se criou métodos para troca de mensagens a longa distância, desde os primários sinais de fumaça dos nossos ancestrais até os dispositivos atuais de telecomunicações. Entretanto, quando existe a necessidade de reunião de um grupo de indivíduos para discutir assuntos quaisquer com qualquer intuito, ainda é necessária a locomoção dos mesmos para um lugar comum. Este procedimento acarreta desperdício de tempo e dinheiro, sem contar com o risco envolvido. Considere, por exemplo, uma reunião mundial, como a ECO 92, onde a maioria dos chefes de nação do planeta se deslocaram até o Rio de Janeiro para discutir problemas sobre o meio ambiente.

Na tentativa de melhorar este quadro, vários grupos de pesquisa iniciaram estudos com o objetivo de desenvolver um novo conjunto de serviços de comunicação denominados serviços de teleconferência.

Serviços de teleconferência são definidos [SoMB 88, Fluc 95] como um conjunto de facilidades de telecomunicações que permite aos participantes, em duas ou mais localidades distintas, estabelecer uma comunicação bidirecional através de dispositivos eletrônicos de comunicação, enquanto compartilham, simultaneamente, seus espaços acústicos e visuais, tendo a impressão de estarem todos em um único ambiente.

Os serviços de teleconferência são classificados em geral pela literatura [H.200, SoMB 88, Fluc 95], em:

• Áudio Conferência - Sistemas onde somente sinais de áudio e controle são transmitidos entre os participantes;
• Conferência Áudio-Documentária - Similar à áudio conferência, havendo, entretanto, o tratamento de documentos textuais;
• Conferência Audiográfica - Serviço com suporte a transmissão de áudio, sinais de controle, documentos textuais e imagens estáticas;
• Freeze-Frame Videoconferência - Serviço similar à conferência audiográfica acrescida do envio periódico de imagens estáticas dos participantes;
• Teleseminário - Serviço que consiste da distribuição dos eventos ocorridos num local (áudio e vídeo) para todos os demais participantes, sendo o áudio o único sinal de retorno;
• Videoconferência - Serviço similar à conferência audiográfica acrescida do envio, em tempo real, de sinais de vídeo entre os vários participantes.

• Telefonia Convencional - Incluída com o intuito de levantar considerações sobre interoperabilidade com os demais serviços;
• Videofonia - Serviço com transmissão ponto-a-ponto bidirecional de sinais de áudio e vídeo;
• Telemonitoramento - Serviço de transmissão unidirecional de sinais com o intuito de efetuar observação de ambientes. Ainda não existe proposta de padrão para este tipo de serviço.

Como resultado das pesquisas desenvolvidas nos últimos anos, vários protótipos de sistemas de teleconferência, em particular videoconferência, foram apresentados e se encontram operacionais. Tais protótipos apresentam, no entanto, algumas limitações. Muitos não seguem os padrões acordados, além de se limitarem apenas às transmissões sem sincronismo das mídias áudio e vídeo e, mesmo assim, com qualidade duvidosa.

Para ser interoperável, o sistema deve seguir os padrões estabelecidos para transmissão das diversas mídias, bem como para o intercâmbio dos objetos multimídia/hipermídia manipulados. Os organismos de padronização internacional (ISO e ITU-T) indicam a utilização do H.261 [H.261] ou mais recentemente H.262 e H.263 [Draft H.263] para codificação de vídeo on-line e em tempo real, MPEG, MPEG-2 ou MPEG-4 [Fluc 95] para armazenamento e recuperação de vídeo, JPEG [Wall 91] para codificação de imagens estáticas, G.711 [G.711] obrigatoriamente, para a codificação de áudio e opcionalmente G.722, G.728, G.723 [G.722, G.728, G.723]. A obediência a padrões de codificação das várias mídias é condição necessária, mas não suficiente, se se deseja um sistema de videoconferência aberto. Padrões para codificação de informações multimídia/hipermídia em sua forma final, incluindo aí o sincronismo espacial e temporal das diversas mídias e a descrição da apresentação, devem ser igualmente seguidos. A proposta de padrão MHEG [MHEG 95] da ISO preenche esta lacuna. Da mesma forma, o empacotamento dos dados multimídia deve seguir padrões adequados, como o H.221 [H.221] ou os mais recentes H.222 e H.223 [H.223], bem como os mecanismos de segurança [Schn 95]. Recentemente uma proposta para a transmissão dos dados de controle foi também apresentada pela ITU-T [Draft H.245].

O uso de padrões adequados é muito importante, pois além de permitir a portabilidade do sistema, permite a interoperabilidade com sistemas afins, por exemplo videofonia [F.720, F.721], conferência audiográfica [F.710, F.711, T.120], outros sistemas de videoconferência, e até a própria telefonia convencional. Adotados e seguidos os padrões, a compatibilização pode ser realizada através da filtragem das mídias de modo apropriado, sendo transmitidas apenas as mídias conhecidas em cada serviço. O áudio [G.711] é a mídia básica, para fins de compatibilização, estando presente em todos os serviços audiovisuais [H.200, F.710, F.711, F.720, F.721, F.730], o que possibilita que um indivíduo num aparelho telefônico participe da mais refinada videoconferência, obviamente enviando e recebendo apenas os sinais de áudio básicos.

Um grande problema na implementação de um sistema de videoconferência é a sobrecarga gerada no sistema de comunicação pela transmissão das várias mídias. O sistema deve prover mecanismos de diminuição no fluxo das mídias, em especial o áudio e vídeo, que mais utilizam recursos de banda passante da rede. Tais mecanismos devem evitar, por exemplo, que um vídeo seja transmitido mais de uma vez para uma mesma sub-rede, se possível.

Um sistema de videoconferência deve oferecer outras facilidades adicionais à simples transmissão síncrona de áudio e vídeo. Tais facilidades incluem uma etapa anterior à conferência (denominada pré-conferência) para agendamento e configuração do ambiente, facilidades para manipulação de documentos e trabalho cooperativo, suporte à votação, facilidades para troca de mensagens entre os usuários, possibilidade de gravação da conferência para posterior assistência e, em todas as suas funções, mecanismos de segurança.

Em qualquer sistema de teleconferência o controle de acesso ao ambiente (comumente denominado "floor control"), que gerencia quais participantes têm direito à fala, à manipulação de documentos, etc. em um dado instante, bem como o controle do período máximo de tempo que cada participante tem, quando detém um controle específico do ambiente, é um mecanismo chave e, em geral, de difícil implementação. Um sistema ideal deve permitir a configuração completa do acesso às suas facilidades, e se encarregar de gerenciar as regras estabelecidas.

Esta dissertação descreve a implementação de um sistema de videoconferência, o TVS (TeleMídia Videoconferencing System), resultado dos estudos realizados no Laboratório TeleMídia do Grupo de Redes e Sistemas Multimídia do Departamento de Informática da PUC-Rio. Tal sistema busca cumprir os requisitos anteriormente mencionados, procurando estar em conformidade com as recomendações ITU-T e padrões ISO pertinentes.

O TVS é um sistema que possibilita, além da transmissão das mídias áudio [G.711] e vídeo [H.261] de forma síncrona e padronizada, a manipulação de documentos multimídia/hipermídia, baseada no Modelo de Contextos Aninhados (MCA), em conformidade com a proposta de padrão MHEG [MHEG 95]. O sistema apresenta suporte à votação e envio de mensagens entre participantes, além de permitir uma ampla configuração do ambiente. Todo o controle de acesso ao ambiente é realizado por deteção de silêncio [Fari 92], por razões de eficiência com relação à interatividade em uma reunião.

Esta dissertação está organizada em mais cinco capítulos, além desta introdução.

O Capítulo 2 discorre sobre as características desejáveis de um sistema de videoconferência, apresentando a recomendação F.730 da ITU-T, bem como levantando características de um sistema de videoconferência ideal.

O Capítulo 3 apresenta alguns dos protótipos disponíveis e em desenvolvimento por outros grupos de pesquisa espalhados pelo mundo. São apresentadas características do CuSee-Me - Cornell/EUA, nv - Xerox Park/EUA, ViC - LBL e UCB/EUA, do Sistema do Multimedia Communication Research Laboratory/Canadá, IVS - Inria/França e do TVS - PUC-Rio/Brasil.

O Capítulo 4 apresenta o TVS, sua arquitetura distribuída, a interface com o usuário e demais características provenientes do sistema de videoconferência ideal proposto no Capítulo 2, sempre levando em conta a aderência aos padrões pertinentes.

O Capítulo 5 apresenta detalhes da implementação do TVS em um ambiente distribuído, destacando os principais algorítmos, análise de possibilidades de implementação e motivação da opção disponibilizada.

O Capítulo 6 é dedicado à conclusão, incluindo trabalhos futuros e contribuições da dissertação.

O Apêndice A (em anexo) apresentam ainda o código fonte do sistema em C++.

A terminologia utilizada no restante da dissertação, uma extensão daquelas apresentadas por Szypersky [SzVe 93] e Soares [SoMB 88], pode ser resumida como se segue:

• Organizador: indivíduo que tem como tarefa agendar a conferência e, se necessário, divulgar aos participantes a existência da conferência. Pode ser um participante ou não.
• Participante: usuário da conferência com direitos, controlados pelo coordenador, à fala e às demais facilidades da conferência.
• Interlocutor: participante que detém, em um dado instante, o direito à fala e alteração dos documentos multimídia/hipermídia. Tal direito pode ser delegado a outro participante.
• Secretário: usuário da conferência a quem se delega o direito de escrita nos documentos multimídia/hipermídia compartilhados. Pode ser um participante ou não.
• Ouvinte: usuário da conferência que não está habilitado a transmitir sinais de áudio.
• Coordenador: participante com direitos especiais sobre todo o controle da conferência.
• Assento: dispositivo lógico que pode ser preenchido por um participante ou secretário.
• Base Privada: sessão de trabalho de um usuário, de acesso (controle) restrito a este usuário.
• Hiperbase ou Hiperbase Pública: depósito de documentos persistentes acessados por todos os usuários da conferência, de acordo com seus direitos.
• Base Compartilhada: depósito volátil de documentos que possibilita o trabalho cooperativo entre os participantes da conferência. É visível por todos os participantes, embora o controle de alteração seja realizado pelo sistema.

2. Características Desejáveis de um Sistema de Videoconferência

2.1. A Recomendação ITU-T F.730

A ITU-T, através da recomendação F.730, define um serviço de videoconferência como um serviço de teleconferência audiovisual de conversação interativa que provê uma troca bidirecional, e em tempo real, de sinais de áudio (voz) e vídeo entre grupos de usuários em dois ou mais locais distintos.

2.1.1. Nomenclatura

A ITU-T introduz a seguinte terminologia na sua recomendação F.730:

• Conference Convenor - Quem convoca os participantes para a reunião e faz todos os arranjos necessários (de acordo com a terminologia apresentada no capítulo 1, seria o organizador).
• Apresentador - Quem controla a informação visual em discussão {secretário + interlocutor}.
• Membro da audiência - Quem participa da conferência sem ser o apresentador {participante - (interlocutor + secretário)}.
• Condutor - Quem gerencia a conferência {Coordenador}.
• Unidade de Controle Multiponto (Multipoint Control Unit, MCU) - Equipamento para interconexão de três ou mais estações.
• Muting - Função que evita que sinais de áudio/vídeo sejam enviados por uma determinada estação.

Qualquer sistema de videoconferência deve, pelo menos, prover a transmissão das mídias de áudio e vídeo, cuja qualidade define dois tipos de videoconferência, a básica e a de alta qualidade. A videoconferência de alta qualidade fornece uma qualidade de áudio e vídeo similar à difusão de sinais de televisão (CCIR 601, entre outros). A videoconferência básica fornece uma transmissão de sinais de áudio e vídeo com qualidade reduzida (G.711 e H.261, por exemplo). Não existe ainda proposta de padrão para serviços de videoconferência de alta qualidade.

Assim, pela definição da ITU-T, apenas protótipos que apresentarem a transmissão básica das mídias áudio e vídeo podem ser classificadas como provedores de um serviço de videoconferência.

2.1.3. Características adicionais

A ITU-T estabelece ainda uma série de características adicionais que um sistema de videoconferência pode, opcionalmente, oferecer suporte. Entre outras:

• Transmissão de imagens estáticas de alta resolução - Com esta característica o sistema permite a distribuição de imagens de alta definição, no formato ISO JPEG por exemplo. Tal característica seria extremamente adequada para sistemas de diagnóstico médico remoto, onde um especialista poderia, por exemplo, observar uma imagem de Raio-X de um paciente.
• Encriptação para garantir privacidade - Essencial em qualquer tipo de serviço de comunicação, esta característica provê mecanismos de segurança que evitam, por exemplo, que intrusos decodifiquem as mensagens trocadas entre os diversos participantes. Esta característica é fundamental em sistemas de comunicação militares, por exemplo.
• Transmissão de dados em geral - Um sistema de videoconferência pode estar habilitado a manipular dados de bancos de dados, por exemplo.
• Utilização de câmeras auxiliares - O usuário poderia escolher qual das várias imagens ele desejaria difundir.
• Gravação da conferência - A operação permitiria que um usuário qualquer fosse capaz de assistir uma conferência antiga. Imagine o caso de um aluno que poderia assistir aulas perdidas.
• Existência de um coordenador (chairman) - Este indivíduo teria direitos especiais sobre todo o ambiente da conferência, podendo modificar a prioridade na passagem de permissão, desabilitar qualquer função de qualquer usuário ou mesmo desabilitar (expulsar da conferência) um usuário.
• Implementação do controle de acesso, comumente denominado Floor Control - O próprio sistema implementa um algoritmo de passagem de permissão para garantir que apenas um usuário por vez fale ou modifique alguma coisa.
• Identificação do interlocutor - O sistema indica qual dos diversos participantes da conferência é o interlocutor.
• Facilidade de tradução - O sistema implementaria um algoritmo de reconhecimento da fala com posterior tradução para outro idioma e síntese de voz. Deste modo, um usuário que fale um idioma conhecido pelo sistema poderia trocar informações com outros usuários de outras nacionalidades, tendo o sistema como interface comum.
• Facilidade de recuperação de imagens estáticas ou em movimento - O sistema deve ser capaz de recuperar estas mídias de algum sistema de armazenamento para posterior apresentação aos demais participantes da conferência.

Sistemas de videoconferência devem poder ser utilizados para várias aplicações onde a intercomunicação humana através de troca de informações audiovisuais é fundamental. Dentre elas pode-se destacar:

• Reuniões de negócios (conduzidas ou não);
• Consultas remotas;
• Suporte remoto em manutenções técnicas, diagnóstico médico etc.;
• Tele-educação;
• Painel de discussões.

Para a realização de uma conferência, existe uma série de etapas que devem ser realizadas. São elas:

• Reserva - Mecanismo que aloca recursos para a realização da conferência.
• Discagem direta - Etapa de conexão da estação em questão numa determinada conferência para a qual se fez uma reserva anteriormente.
• Gerenciamento da conferência
• Não Conduzido - Nenhum dos terminais tem prioridade sobre os demais.
• Conduzido - Um usuário é escolhido para ser o coordenador da conferência, que controla as transmissões de informação através de mensagens "asking for the floor" e "giving the floor".
• Muting - Cada participante deve poder desabilitar as funções de áudio e vídeo na sua sessão de trabalho. Tal desabilitação é ainda mais indicada quando a videoconferência utiliza esquema de deteção de nível de fala para seleção da imagem a ser difundida.

Um sistema de videoconferência deve ser capaz de trocar informações com outros sistemas de videoconferência, conferência audiográfica, videofonia e até a própria telefonia convencional.

A compatibilidade do sistema de videoconferência com os demais sistemas do mesmo tipo e com a videofonia é realizada através do uso de padrões comuns para a codificação de áudio, de vídeo e estrutura do quadro, como por exemplo G.711, H.261 e H.221, respectivamente.

A compatibilidade do sistema de videoconferência com a telefonia convencional deve ser implementada através da filtragem da única mídia presente na telefonia, o áudio G.711. Na videoconferência, deve aparecer mensagem indicativa na janela de vídeo do usuário que participa da conferência via telefonia convencional.

2.2. A Pré-Conferência

Um sistema ideal deve implementar uma etapa anterior à conferência, denominada pré-conferência, onde o organizador configura o ambiente da conferência. A etapa de reserva apontada pela recomendação F.730 é implementada aqui.

Na pré-conferência, configura-se a data e horário de uma conferência, quais participantes terão acesso à conferência, quais os acessos que cada participante possui, quem é o coordenador (se existir um) e informações para o algoritmo de controle de acesso, entre outras informações.

As informações de uma conferência devem poder ser alteradas em qualquer instante anterior à realização da mesma, devendo ser os participantes notificados das alterações ocorridas. Por exemplo, no caso de adiamento de uma determinada conferência.

2.3. Início e Término da Conferência

A conferência deve se iniciar no momento que o primeiro participante realizar a operação de conexão à mesma. Na operação de conexão a uma conferência, um participante em potencial deve visualizar uma lista de conferências que estejam agendadas e selecionar a que deseja participar. Neste instante, o sistema deve verificar se o participante em questão tem acesso ou não àquela conferência. Opcionalmente, a lista de conferências apresentada a um determinado usuário poderia conter apenas as conferências as quais aquele usuário tem permissão de conexão.

Uma conferência somente deve terminar quando o último participante se desconectar da conferência (voluntariamente ou pelo sistema). Quando um participante deixa uma conferência, os participantes, ou pelo menos o coordenador, deve ser informado.

Um participante deve estar habilitado a sair de uma conferência e retornar a qualquer instante da conferência, bastando que os participantes, ou o coordenador, sejam informados, e o coordenador permita.

2.4. Gerenciamento da Conferência

Tudo o que o organizador configurar antes do início da conferência deve poder ser alterado, em tempo de execução, pelo coordenador da conferência. Através desta característica, o coordenador estaria habilitado a incluir novos participantes na conferência, excluir algum participante inconveniente, alterar a configuração de acesso de cada usuário, além de intervir no algoritmo de controle de acesso implementado pelo sistema.

O sistema deve prover mecanismos que garantam que as regras de acesso estabelecidas pelo organizador, na pré-conferência, ou coordenador na conferência propriamente dita, sejam obedecidas. Por exemplo: se um determinado participante tiver uma fatia de tempo de cinco minutos no máximo como interlocutor, o sistema tem que garantir que findos os cinco minutos, o controle de acesso poderá ser passado para um outro participante.

Também faz parte do gerenciamento da conferência a garantia de consistência nos documentos multimídia/hipermídia que estejam sendo manipulados de modo cooperativo pelos vários participantes da conferência. Desse modo, o sistema deve evitar que mais de um usuário possa alterar um mesmo trecho do documento.

2.5. O Controle de Acesso

Indica qual participante tem direito de acessar os recursos da conferência e com quais direitos. Existem dois grandes grupos de recursos: a voz e a manipulação em documentos multimídia/hipermídia. Um sistema ideal deve prover mecanismo de controle de acesso a cada um destes grupos.

O sistema é quem determina qual dos diversos participantes da conferência será promovido a interlocutor, tendo direito de transmitir sinais de áudio para todas as demais estações, e secretário, tendo direito de manipular os documentos multimídia/hipermídia.

Os dois grupos de recursos não têm de estar, necessariamente, nas mãos de um único participante, embora seja perfeitamente aceitável que um interlocutor seja também secretário.

Os mecanismos de gerenciamento de controle de acesso podem ser implementados de várias formas, das quais destacamos:

• Acionamento de botão: Um usuário que deseja obter o controle de um determinado dispositivo (áudio por exemplo), pressionaria um botão, indicando a requisição de controle. Quando o sistema for passar o controle do dispositivo em questão para outro participante, executaria um algoritmo de escolha entre os participantes que pressionaram o botão. Este procedimento espelha o funcionamento de uma reunião onde os indivíduos, por exemplo, levantam o braço para indicar que desejam falar.
• Deteção de Silêncio: Um participante que deseja obter o controle de acesso ao dispositivo de áudio, por exemplo, simplesmente começa a falar ao detetar que o interlocutor está em silêncio. Este procedimento espelha a realização de uma conversação entre um grupo de indivíduos, uma vez que cada indivíduo aguarda a conclusão da locução de outro para iniciar sua locução. Um sistema que pretende prover este tipo de esquema de gerenciamento de acesso a um dispositivo necessita analisar a mídia áudio transmitida, em busca de intervalos de silêncio. Uma vez detetado o silêncio, o sistema deve detetar quais participantes desejam falar (deteção de voz) e executar um algoritmo de escolha entre estes, passando o controle do dispositivo para o participante selecionado.

O sistema de videoconferência deve permitir que o coordenador modifique a regra de acesso, podendo indicar qual participante será o próximo a ganhar o controle de acesso ao recurso.

O algoritmo de escolha deve selecionar o participante com maior prioridade dentre os vários candidatos a controlar o recurso. Caso exista mais de um participante com a mesma prioridade, o sistema deve escolher os participantes de modo a garantir a equidade na distribuição de controle sobre cada recurso. Idealmente, o sistema deve oferecer diversos mecanismos de prioridade.

Uma vez que o participante tenha ganho o controle de um determinado recurso, ele terá uma fatia de tempo máxima para utilização exclusiva do recurso, depois da qual o recurso é automaticamente liberado e o controle passado a outro participante. Um participante com controle de um dispositivo pode liberar o recurso antes do término da fatia de tempo a ele alocada. Os valores da fatia de tempo máxima de cada usuário são configurados pelo organizador ou pelo coordenador.

O sistema deve permitir que, a qualquer instante, o coordenador possa retirar, de um determinado participante, o direito de acesso a um dispositivo. Esta característica, conjugada com a modificação da regra de seleção do próximo participante a ganhar o controle, permite por exemplo, que o coordenador passe a palavra para um determinado usuário quando achar conveniente.

2.6. Manipulação Cooperativa de Documentos

Um sistema de videoconferência deve prover a manipulação cooperativa de documentos multimídia/hipermídia pelos diversos participantes da conferência. Tal característica deve incluir, adicionalmente, um completo mecanismo de controle de alterações no documento de forma a evitar inconsistências.

2.7. Votação

O processo de votação é extremamente natural quando da reunião de indivíduos, por ser o modo mais usual para tomada de decisões. O sistema de videoconferência deve prover mecanismo para que, durante a conferência seja possível criar uma votação, coletar e apurar os votos dos participantes. O mecanismo deve prover segurança num nível que evite fraudes e votos influenciados pelos votos dos outros participantes.

2.8. Minimização na Utilização do Sistema de Comunicação

Um sistema de videoconferência deve prover mecanismos para minimizar o uso da banda passante do meio, uma vez que as mídias utilizadas, principalmente áudio e vídeo, requisitam muitos recursos do sistema de comunicação.

2.9. Facilidades Adicionais Desejáveis

Adicionalmente, um sistema de videoconferência deve oferecer facilidades adicionais que sejam interessantes no sentido de melhorar o suporte à troca de informações entre indivíduos ou grupos de indivíduos de um determinado tipo de reunião, como a transmissão de mensagens textuais ¾ bilhetes ¾ entre os participantes, além daquelas citadas na seção 2.1.3.

Existem outros mecanismos úteis, como uma função que permita que indivíduos que não tenham tido oportunidade de participar de uma conferência, possam posteriormente assisti-la, através da recuperação da conferência previamente gravada.

Capítulo III

3. Trabalhos Relacionados

Muitos protótipos de sistemas de videoconferência já se encontram operacionais. Este capítulo apresenta alguns desses protótipos, através de uma análise comparativa de suas características, incluindo o TVS, proposto nesta dissertação.

Os protótipos aqui considerados são:

• O CU-SeeMe [Dorc 95, Arro 96], desenvolvido por Tim Dorcey na Universidade de Cornell, EUA. Foi um dos primeiros protótipos de videoconferência disponíveis pela Internet. Trata-se de um sistema baseado na idéia de refletores. Quando um usuário deseja participar de uma conferência, ele deve se conectar a um refletor daquela conferência, informando o identificador da conferência desejada. Caso a conexão seja realizada entre dois participantes apenas, o uso do refletor é opcional. O CU-SeeMe possui implementação para Macintosh (sua plataforma nativa) e Windows, devendo o refletor ser instalado em estações UNIX. A interface do CU-SeeMe é apresentada na Figura 3.1. Existe também uma versão comercial do CU-SeeMe, denominada "Enhanced CU-SeeMe", com várias caracteristicas acrescentadas, conforme comentado adiante;

• O nv [Fred 94], desenvolvido por Ron Frederick na Xerox PARC, EUA. O sistema tem como meta ser extremamente portátil, além de ser projetado para funcionar em redes das mais diversas larguras de banda. O nv possui implementação para ambientes UNIX. A interface do nv é apresentada na Figura 3.2;

• O vic [McJa 95], desenvolvido por Steven McCane e Van Jacobson no Lawrence Berkeley Laboratory e University of California, Berkeley, EUA. O sistema tem como meta a flexibilidade. O vic possui implementação para ambientes UNIX. Sua interface, desenvolvida em Tcl/Tk, é apresentada na Figura 3.3;

• O IVS [Turl 93, Turl 94, Turl 95], desenvolvido por Thierry Turletti no Inria, Sophia-Antipolis, França. O sistema possui implementação para várias plataformas baseadas em UNIX. A interface do IVS é apresentada na Figura 3.4;
• O sistema do MCRLab [LaHG 93], desenvolvido por Louis Lamond e Grant Henderson na Universidade de Ottawa, Canadá. O sistema possui uma arquitetura distribuída implementada através de três componentes: Servidores de Diretório (DS), Gerentes de Conferência (CM) e Agentes de Conferência (CA), Conforme apresentado na Figura 3.5. O primeiro componente é responsável por permitir o armazenamento e recuperação de documentos multimídia, enquanto os demais são responsáveis pelo andamento da conferência. A interface do sistema, que utiliza a biblioteca Andrew desenvolvida na Carnegie Mellon University, EUA, é apresentada na Figura 3.6;

• O TVS do Laboratório TeleMídia, PUC-Rio, apresentado em detalhes nos capítulos 4 e 5 desta dissertação e cuja interface, que utiliza a biblioteca IUP desenvolvida na PUC-Rio [Levy 93], é apresentada na Figura 4.3.

A seguir enumera-se um subconjunto das características levantadas no Capítulo 2, aquelas presentes em pelo menos um dos protótipos, tecendo comentários sobre o comportamento de cada um dos protótipos com respeito à característica mencionada.

3.1. Codificação das mídias básicas: áudio e vídeo

• O CU-SeeMe utiliza codificações proprietárias. O vídeo transmitido pode ter a resolução de 320´ 240 pixels (metade da resolução NTSC) ou, mais comumente, 160´ 120 pixels. Os pixels são codificados em 16 tons de cinza, com quatro bits por amostra. O algoritmo de codificação de vídeo possui três etapas bem definidas. A primeira é a etapa de redução da imagem, dos 640´ 480 pixels NTSC fornecidos pela câmera para a resolução adequada (metade ou quarta parte do NTSC), sendo a resolução de cores do pixel reduzida de 16 bits em cores para 4 bits em tons de cinza. A primeira etapa reduz um quadro na razão de 64:1. A segunda etapa consiste da divisão de um quadro em blocos de 8´8 pixels seguida de análise que garante a transmissão somente daqueles que possuirem suficientes modificações para o anterior. Mais precisamente, os blocos cuja expressão  seja verdadeira. p é o valor de um fator proporcional à quantidade de pixels vizinhos que sofreram modificação e serve para penalizar modificações em bloco, mais visíveis ao olho humano; f_i,j é o valor do i-ésimo pixel da j-ésima coluna do bloco em análise; a_i,j é o valor do i-ésimo pixel da j-ésima coluna do mesmo bloco último quadro transmitido; a é um valor limite utilizado para decidir se o bloco deve ou não ser transmitido. Cada bloco é transmitido periodicamente mesmo que não tenha sofrido alterações significativas, para evitar acumulação de distorção. A terceira e última etapa consiste de um algoritmo de compactação que manipula cada linha de 8 pixels com 4 bits cada como uma única palavra de 32 bits, o que melhora a performance em arquiteturas de 32 bits. A compactação proporciona uma redução adicional da ordem de 40% no sinal de vídeo. O áudio é igualmente codificado por algoritmo proprietário, estando disponível apenas em algumas das plataformas. Na sua versão comercial, o vídeo pode ser codificado em cores através de algoritmo desonvolvido por uma empresa denominada Crystal Net Corporation. Este algoritmo, não compatível com o ITU-T H.261, promete uma boa performance, embora não seja um padrão endossado por organismos internacionais.
• O nv utiliza a codificação MJPEG, ou a CellB da SUN Microsystems, ou ainda uma codificação proprietária em duas etapas, conforme configuração. O vídeo pode ser transmitido em cores ou em preto e branco. Na primeira etapa, o quadro é dividido em blocos de 8´8 pixels e então realizada a deteção de movimento. Na etapa seguinte, aos blocos a serem transmitidos, e aplicada a transformada de Haar [Turl 95] ou DCT (mais lenta, porém com maior compressão do sinal) [STCN 92], dependendo do estado do sistema de comunicação. A primeira etapa da codificação proporciona uma redução de 3:1 e a segunda uma redução de 6:1 ou 12:1 dependendo da utilização da transformada de Haar ou DCT, respectivamente. Periodicamente, o nv envia as porções sem modificação com a mesma codificação por transformadas, sem a execução da etapa de threshoulding, de acordo com a Figura 3.7. O nv não codifica sinais de áudio, não sendo, portanto, um sistema de videoconferência, segundo definição da ITU-T, apresentada no Capítulo II.

• O IVS é um sistema que funciona de acordo com as recomendações ITU-T, codificando vídeo H.261 [H.261], nos formatos padrão CIF e QCIF, respectivamente com 352´ 288 e 176´ 144 pixels, além de um novo formato, denominado SCIF [Turl 93, Turl 95] com 704´ 576 pixels, introduzido na recomendação H.263 com a denominação 4CIF [Draft H.263]. Uma imagem SCIF é formada por quatro imagens CIF denominadas CIF0, CIF1, CIF2 e CIF3, conforme apresentado na Figura 3.8. A codificação do áudio pode ser PCM [G.711], ADPCM ou VADPCM. Maiores detalhes sobre as recomendações ITU-T H.261 e G.711 estão apresentadas no Capítulo IV desta dissertação.

• O vic permite codificação e decodificação de sinais de vídeo MJPEG, CellB, H.261 e nv, garantindo interoperabilidade com os sistemas IVS e nv. O vic não codifica sinais de áudio, não sendo portanto um sistema de videoconferência, segundo definição da ITU-T. O tratamento de áudio é repassado a um outro aplicativo de teleconferência do mesmo grupo, o vat, que é um sistema de áudio conferência. Existe um esquema estabelecido para funcionamento conjunto do vic com o vat.
• O sistema do MCRLab está em etapa de integração das mídias de áudio e vídeo [LaHG 93], sendo portanto um sistema ainda sem transmissão das mídias básicas.
• O TVS é um sistema que funciona de acordo com as recomendações ITU-T, codificando vídeo H.261 [H.261] e áudio G.711 [G.711]. Estes algoritmos estão detalhados no Capítulo IV desta dissertação.

• O CU-SeeMe utiliza formato proprietário no empacotamento das mídias.
• O nv e vic utilizam o protocolo RTP [RTP 94] do IETF para o envio da mídia vídeo, a única que estes sistemas manipulam.
• O IVS utiliza formato de quadro não padrão para envio de pacotes de áudio e vídeo. Existe um formato de pacote para o áudio e outro para o vídeo. O tamanho do pacote de áudio depende da codificação utilizada, possuindo 2 octetos de cabeçalho. O primeiro octeto é utilizado para a codificação do tipo de pacote (2 bits) e número de seqüência (6 bits restantes) e o segundo octeto é utilizado para indicar o tipo de codificação utilizado. No corpo do pacote de áudio existem mais 1024 octetos para a codificação PCM, 512 octetos para a codificação ADPCM ou um tamanho variável para a codificação VADPCM. O quadro de vídeo possui três octetos de cabeçalho, sendo que o primeiro octeto é utilizado para codificar o tipo de pacote (2 bits) e mais dados de controle, o segundo octeto é utilizado para codificar o número do pacote e o terceiro octeto o número da imagem. Os pacotes de áudio são enviados pela porta UDP 2233 e os pacotes de vídeo pela porta UDP 2244.
• O sistema do MCRLab promete utilizar o protocolo SRTDD, desenvolvido pelo mesmo Laboratório.
• O TVS utiliza um formato de quadro não padrão, detalhado nos Capítulos IV e V desta dissertação.

• O vic permite transmissão segura fim-a-fim dos seus pacotes de vídeo, através de encriptação com o algoritmo DES [Schn 95]. A chave pública para a decriptação deve ser distribuída externamente por algum meio suficientemente seguro.
• O IVS apresenta, no seu último protótipo, a implementação de algoritmo de criptografia de dados.
• O TVS, nv, CU-SeeMe e o sistema do MCRLab não fornecem dispositivos de segurança na transferência de informações nas suas versões atuais.

• Não há dados disponíveis sobre dispositivos para sincronismo de mídias no CU-SeeMe.
• Não se aplica ao nv, uma vez que apenas a mídia vídeo é considerada.
• O IVS envia a mídia vídeo e a mídia áudio por portas UDP distintas. Em nenhum momento, a partir do envio, é reconsiderado o sincronismo entre as mídias que podem chegar ao destino dessincronizadas. O problema fica pouco explícito pela baixa quantidade de quadros por segundo conseguida na Internet, o que impossibilita que se verifique a perda do sincronismo labial definido em [H.320].
• O vic apenas transmite vídeo, sendo tarefa de outro aplicativo, o vat, a transmissão de áudio. Atualmente, não há relação entre as duas transmissões, o que pode acarretar no não sincronismo entre as mídias no destino. A documentação [McJa 95] promete a implementação de outro módulo, o ct, que coordenaria as transmissões do vic e vat de modo a garantir o sincronismo entre as mídias.
• O sistema do MCRLab ainda não transmite sinais de áudio e vídeo. Figura como assunto de estudos futuros o sincronismo entre as mídias, que seria implementado no destino.
• O TVS utiliza a técnica de time stamp nas mídias áudio e vídeo, que possibilita a exibição sincronizada no destino, quando adequadamente tratada.

• O CU-SeeMe oferece a facilidade de um whiteboard simplificado que permite a apresentação de uma imagem estática com resolução de 8 bits, em tons de cinza, como apoio às discussões em andamento.
• O nv e o IVS não possuem tratamento de documentos.
• O vic não fornece tratamento de documentos. Entretanto, existe um aplicativo do mesmo grupo, o wb, que funciona de modo independente do vic e permite o uso de uma área gráfica compartilhada entre os participantes.
• O sistema do MCRLab possui a facilidade de manipulação compartilhada de um documento multimídia. O sistema executa um algoritmo de controle de alterações no documento que, através de bloqueio de seções do documento, permite alterações em paralelo, desde que em seções distintas. Quando dois usuários desejam alterar um mesmo trecho do documento, o sistema nega o pedido a ambos os usuários.
• O TVS fornece a facilidade de manipulação compartilhada de documentos multimídia/hipermídia através do Modelo de Contextos Aninhados, em conformidade com a proposta de padrão MHEG [MHEG 95]. O TVS executa um algoritmo de controle de acesso de modo que apenas um participante tem permissão de manipular os documentos da base compartilhada por vez.

3.6. Suporte a Votações

• Apenas encontrada no TVS. Em tempo de execução da conferência, um usuário pode criar uma votação, selecionar uma das opções na cédula ou apagar uma votação, caso ele próprio a tenha criado.

• O CU-SeeMe permite que mensagens sejam escritas sobre a janela de vídeo dos participantes e na sua versão mais recente, apresenta uma janela de conversação, onde os diversos usuários podem digitar mensagens textuais.
• O TVS permite envio de mensagens para qualquer participante selecionado, ou para todos os participantes.
• O vic, nv e IVS e o sistema do MCRLab não fornecem esta facilidade.

• O vic não executa as funções de Controle de Acesso, porém existe a promessa de que o ct terá também esta função [McJa 95].
• O CU-SeeMe, nv, IVS e o sistema do MCRLab não implementam a função de controle de acesso ao ambiente da conferência. O sistema do MCRLab implementa apenas controle de acesso ao documento compartilhado, como apresentado na subseção anterior.
• O controle de acesso ao ambiente do TVS é implementado pelo através da técnica de deteção de silêncio [Fari 92]. Tal mecanismo garante a existência de apenas um interlocutor e secretário por vez. O coordenador pode intervir, modificando as regras de acesso.

• Apenas encontrado no TVS. O coordenador tem direitos especiais sobre todo o ambiente da conferência, podendo modificar a regra de passagem de controle de acesso, desconectar um participante, incluir ou excluir assentos, modificar os direitos de acesso individuais, entre outros.

• O vic, em conjunção com o vat, pode apresentar uma janela na qual aparece o interlocutor. O vat envia mensagem ao vic indicando a troca de interlocutor e este modifica a fonte de vídeo desta janela.
• O CU-SeeMe indica na janela de vídeo do participante se é ele quem está falando. Se um participante que não transmite vídeo é quem está falando, não há modo de se descobrir quem é, uma vez que os usuários observadores (lurkers) não possuem janela de vídeo.
• Como o TVS controla quem tem direito à fala ele está habilitado a indicar graficamente quem é o interlocutor num determinado instante.

• O CU-SeeMe, e o sistema do MCRLab não implementam mecanismos de otimização de utilização de banda passante, podendo haver melhora realizada através de configuração manual.
• O vic, nv e IVS utilizam o protocolo MBONE, que provê transmissões em multicast.
• O TVS não utiliza um protocolo específico para otimização na utilização de banda passante, porque foi implementado com o objetivo de funcionar, em uma implementação futura, sobre redes ATM, que possuem um elaborado mecanismo de transmissão ponto-multiponto.

Capítulo IV

4. Arquitetura do TeleMídia Videoconferencing System

Desde sua especificação, o TVS procurou seguir ao máximo os padrões estabelecidos para sistemas de videoconferência, bem como para o intercâmbio de objetos multimídia/hipermídia. O TVS foi desenvolvido buscando cumprir os requisitos levantados no Capítulo II, aproveitando as características apresentadas pelos protótipos apresentados no Capítulo III.

No TVS, o apoio ao trabalho cooperativo é realizado pela máquina hipermídia, denominada HyperProp. É sobre esse sistema, por exemplo, que todo o tratamento de documentos na teleconferência é realizado. Assim, antes de se entrar na definição da arquitetura do TVS propriamente dita, este capítulo traz uma breve introdução, na próxima sessão, ao Modelo de Contextos Aninhados, o modelo conceitual de dados do sistema HyperProp. Espera-se com isso definir alguns termos que serão utilizados no restante do capítulo.

4.1. O Modelo de Contextos Aninhados

O TVS utiliza as definições do MCA para possibilitar o trabalho cooperativo, através da manipulação de documentos multimídia/hipermídia, detalhada na seção 4.12.

O MCA possui a hierarquia de classes apresentada na Figura 4.1. Descreve-se a seguir, sucintamente, as classes relevantes, no contexto do TVS. Uma descrição detalhada do MCA pode ser encontrada em [SoRC 95]:

• Entidade ¾ É um objeto que possui três atributos: um identificador, uma lista de controle de acessos e um descritor. A lista de controle de acessos indica que participantes, com contexto do TVS, tem permissão de manipular a entidade.
• Elo ¾ É uma entidade que possui dois atributos especiais, um ponto de partida (origem) e um ponto de chegada (destino). Os pontos de origem e destino são identificados por âncoras. Uma âncora possui um identificador, um delimitador de região do nó e um conjunto de condições, com suas respectivas ações.
• Nó ¾ É uma entidade que possui dois atributos adicionais: conteúdo e lista de âncoras.
• Nó Terminal ¾ É um nó cujo conteúdo consiste de uma mídia simples bem definida. Adicionalmente um nó terminal possui ainda um conjunto de âncoras. No contexto do TVS, um nó terminal seria a base para o trabalho cooperativo, uma vez que apenas os nós terminais podem ser "levados" à base compartilhada, como detalhado adiante.
• Nó de Composição ¾ É um nó cujo conteúdo é composto de nós terminais ou outros nós de composição, recursivamente. Um nó de composição possibilita que se agrupe vários outros nós, montando um documento multimídia.
• Nó de Contexto ¾ É um nó de composição que contém apenas nós terminais, elos, trilhas e nós de contexto com a garantia de que não existe qualquer nó repetido.
• Nó de Contexto de Usuário ¾ Consiste de um nó que possui apenas nós terminais, elos e nós de contexto de usuário.
• Base Privada ¾ Trata-se de um contexto que contém os nós particulares de um determinado participante. No âmbito do TVS, a janela "Private Base" apresenta justamente os nós da base privada do participante.
• Hiperbase Pública ¾ Trata-se do repositório geral de documentos. Tal repositório possui a seguinte propriedade: Se um nó de contexto é componente da hiperbase pública, então todos os nós componentes do contexto também são componentes da hiperbase pública. O TVS apresenta os nós da hiperbase pública na janela "Hiperbase", cujos nós estão acessíveis a todos os participantes da conferência, de acordo com a lista de controle de acessos de cada nó.

Uma implementação em conformidade com o MCA, denominada Máquina HyperProp, provê o armazenamento das várias entidades MCA, bem como o controle de versões descrito. Tal implementação possui um módulo servidor, que implementa a camada de armazenamento e apresentação, e um módulo cliente, que implementa a camada de apresentação e aplicação, como apresentado na Figura 4.2.

O sistema TVS utiliza o módulo cliente para se comunicar com o servidor HyperProp. A comunicação possibilita o armazenamento e recuperação dos documentos multimídia/hipermídia. Uma discussão detalhada sobre o funcionamento da máquina HyperProp é encontrada em [Bati 94] e [UcMu 96].

Com o intuito de facilitar a navegação na estrutura dos documentos multimídia/hipermídia, foram criadas interfaces gráficas de navegação, denominadas browsers de base privada e de hiperbase pública. A tarefa dos browsers é facilitar a navegação do participante através de técnicas que forneçam sentido de orientação. Uma discussão detalhada sobre os browsers pode ser encontrada em [Much 96, MuSC 95].

O TVS troca mensagens com a máquina HyperProp e com os Browsers, com o intuito de prover o trabalho cooperativo sobre os documentos multimídia/hipermídia, detalhado na seção 4.12.

As seções seguintes discutem sobre as características principais do TVS, apresentando as soluções adotadas, bem como detalhado as demais interações do sistema com a máquina HyperProp e Browsers.

4.2. A Estrutura Distribuída do TVS

O TVS possui uma estrutura distribuída, apresentada na Figura 4.3, utilizando a pilha de protocolos TCP/IP [Come 95], mais precisamente o protocolo UDP. Acima dessa camada, o TVS apresenta uma camada de comunicação, com quatro subdivisões:

1. Mensagens de controle (Camada de Controle);
1. Mensagens de transporte das mídias propriamente ditas (Camada de Mídias);
1. Mensagens de interação com a máquina HyperProp (Camada HyperProp) e
1. Mensagens de interação com o Browser de Base Privada e de Hiperbase Pública (Camada Browser ou Camada de Seleção), que é utilizada para indicar os nós selecionados pelos participantes.

Acima da camada de comunicação está a camada MIU ¾ Módulo de Interação com o Usuário ¾ que é responsável pelas interações do sistema com o usuário.

Ainda faz parte da arquitetura distribuída TVS, o daemon de controle e de conexão ¾ TVSD ¾ que apenas possui a implementação da camada de comunicação de mensagens de controle.

O esquema de funcionamento de uma sessão de videoconferência é apresentado na Figura 4.4, onde as trocas de informação entre os vários componentes do ambiente TVS são ilustradas {A}. As trocas de mensagens de controle são efetuadas entre MIU’s de participantes distintos {B}, entre o MIU de um participante, via camada de comunicação de controle, e o daemon de controle e de conexão {C} ou do daemon para um ou mais participantes {D}. O envio das diversas mídias é realizado, pela camada de comunicação de mídias, entre os MIU’s dos participantes envolvidos na comunicação, sem passar pelo daemon {E}, visando um melhor desempenho do sistema de comunicação. Uma exceção a esta regra é o envio das mensagens textuais ¾ bilhetes ¾ que se utilizam de transmissões de controle. As trocas de mensagens entre a máquina HyperProp e o MIU de um participante são realizadas através da camada de comunicação HyperProp {F} e as mensagens trocadas com o Browser de Hiperbase Pública e de Base Privada através da camada de Comunicação de Seleção {G}.

  

  

4.3. O Daemon de Controle e de Conexão

O daemon é um processo, continuamente em execução, que troca mensagens de controle com o MIU de cada participante, em particular o coordenador. As mensagens do daemon são enviadas e recebidas pelo MIU através da camada de comunicação de mensagens de controle, de acordo com a Figura 4.4.c. As trocas de mensagens efetuadas tem como finalidade geral a configuração e o gerenciamento da conferência. São funções do daemon de controle e conexão:

• Manter dados das conferências agendadas: na etapa de pré-conferência o organizador interage com o daemon, através do seu MIU, com o intuito de agendar uma conferência. A manutenção dos dados informados pelo organizador é tarefa do daemon de controle e de conexão.
• Fornecer uma lista de conferências agendadas: quando um participante em potencial inicia a execução do módulo do participante, a sua MIU envia mensagem de controle para o daemon que responde com a lista de conferências agendadas. Posteriormente, esta lista é apresentada ao usuário para que ele escolha a conferência que deseja participar.
• Controlar os direitos de acesso à conferência: cabe ao daemon verificar se o usuário tem permissão de tornar-se participante da conferência selecionada.
• Controlar as conexões: cabe ao daemon notificar aos participantes, ou apenas ao coordenador, que um determinado usuário se conectou ou desconectou da sessão de videoconferência corrente.
• Manter uma lista de participantes da conferência: a lista inclui diversas informações sobre o ambiente de cada participante, esteja ele ativo ou não.
• Verificar se as conexões estão todas ativas: de tempos em tempos o daemon envia mensagens de controle com o intuito de detectar sessões de participantes inativas. Quando uma sessão de participante não responde à mensagem enviada pelo daemon, este desfaz a conexão do participante, indicando o ocorrido aos demais participantes ou, pelo menos, ao coordenador.
• Executar o algoritmo de passagem de controle de acesso ao ambiente: é o daemon que recebe as mensagens "Asking for the Floor" enviadas pelas estações interessadas em ganhar o controle de acesso ao ambiente da conferência, seleciona o participante de maior prioridade e envia a mensagem "Giving the Floor" para os participantes da conferência, indicando o novo interlocutor.
• Interagir com o coordenador da conferência e com os MIU’s dos participantes com o intuito de garantir o cumprimento das regras de acesso aos diversos dispositivos da conferência. O coordenador interage com o daemon para consultar e alterar as regras de acesso que determinado participante possui.
• Gerenciar as funções de votação: é o daemon que recebe os votos e apura os resultados de uma votação. O daemon também é responsável pelo armazenamento das votações com suas respectivas cédulas. Quando o MIU envia a mensagem de requisição de cédula eleitoral, o daemon envia as opções da votação para que o MIU apresente a cédula ao participante. Neste momento, o participante pode selecionar a opção desejada, que é então enviada ao daemon para a contabilização do voto.

O ambiente da conferência é composto de duas janelas obrigatórias e dez janelas configuráveis. As obrigatórias são: Janela Principal e Console. As janelas configuráveis são subdivididas em quatro grupos: Bases de Informação, Vídeos, Controle e Votação, conforme ilustra a Figura 4.5.

Nas janelas do grupo Bases de Informação encontra-se a janela de Hiperbase, Base Privada e Base Compartilhada.

As bases individuais de documentos multimídia/hipermídia estão mapeadas nas janelas Base Privada (onde se encontra a sessão de trabalho privada do participante) e Hiperbase (onde são exibidos, apenas para leitura, os documentos da conferência) e consistem de um browser [MuSC 95] da Hiperbase Pública e Base Privada do usuário, respectivamente, conforme o conceito do MCA [Hype 95, SoRC 95].

A Base Compartilhada consiste de uma abstração criada para a manipulação cooperativa de documentos. A mesma janela Base Compartilhada é exibida em todas as estações dos participantes. Esta janela é preenchida com documentos que podem ser modificados por qualquer participante da conferência, desde que lhe seja permitida a operação. Uma descrição mais detalhada do funcionamento da Base Compartilhada é apresentada na Seção 4.12.3.

Nas janelas do grupo Vídeo encontram-se a janela do vídeo do interlocutor, a do vídeo local (do participante da estação) e a do vídeo de participante, onde o vídeo de um participante qualquer, selecionado, é exibido. O vídeo do interlocutor é apresentado no formato CIF (352´ 288 pixels), por ser a imagem que deve ter maior atenção do usuário. Os demais vídeos utilizam o formato QCIF (176´ 144 pixels) de menor resolução. A Seção 4.10 apresenta detalhes sobre estes formatos.

No grupo Janelas de Controle encontram-se as janelas de controle de transmissão de vídeo, de áudio e a lista de participantes.

Na janela de controle de vídeo, o usuário faz seleções sobre o tipo de vídeo que ele próprio pretende enviar aos demais participantes da conferência. Esta janela apresenta botões para seleção de envio ou não de vídeo, envio de vídeo em cores ou em preto e branco e, finalmente, envio de vídeo ou de uma imagem estática (foto). Com estas opções o usuário pode desligar a transmissão do seu próprio vídeo se este for o seu desejo, pode enviar uma foto JPEG [Wall 91] se não dispuser de câmera, etc. Se a exibição do vídeo de um participante que tenha desligado sua transmissão for selecionada por outro participante, este último receberá na janela correspondente uma mensagem "Not Sending".

Na janela de controle de áudio o usuário configura o envio e recepção de sinais de áudio [G.711]. As seleções apresentadas são: saída de áudio desejada (Loudspeaker, External Loudspeaker ou Headphone), volume de saída de áudio e dispositivo de entrada de áudio desejada (Built-In Microphone, External Microphone ou No Audio). Os usuários que não enviam sinais de áudio não são considerados na disputa do controle de acesso, sendo portanto ouvintes. A janela de controle de áudio possui ainda o botão "lock", que pode ser utilizado pelo interlocutor para desabilitar a deteção de silêncio nas estações dos demais participantes da conferência. Esta operação permite que o interlocutor esteja em silêncio, sem que um outro participante esteja habilitado a lhe tomar o direito à fala. Neste caso, apenas quando a fatia de tempo de fala do interlocutor esgotar, ou quando o coordenador achar conveniente, o controle de acesso ao ambiente da conferência poderá ser disponibilizado para um outro participante.

Na janela de participantes o usuário recebe uma série de informações sobre os demais participantes da conferência. Nessa janela aparecem os nomes dos vários participantes, com indicação gráfica dos usuários que o estão observando. Ainda nesta janela o usuário pode selecionar qual o participante cujo vídeo deve ser exibido na janela de vídeo de participante. É também nesta janela que o usuário pode requisitar o envio de uma mensagem textual para o participante selecionado.

A Janela de Votação completa o ambiente da conferência, conforme ilustrado na Figura 4.5. Nesta janela o usuário pode, em tempo real, criar uma nova votação, apagar uma votação existente (caso ele próprio a tenha criado) ou selecionar uma das votações e efetivamente votar.

O ambiente TVS é completamente configurável, podendo o organizador otimizar a interface para o tipo de reunião desejada, excluindo janelas desnecessárias, reorganizando os vários diálogos etc. O participante pode alterar o seu ambiente, se desejar, durante a sessão.

4.5. Pré-Conferência

O TVS prevê uma etapa anterior à conferência propriamente dita, denominada pré-conferência. Nessa etapa, o organizador agenda e configura o ambiente da conferência. Nesse agendamento, se disponibiliza o assunto principal a ser tratado, a data da conferência, bem como o número de assentos disponíveis. Cada assento pode ter seu preenchimento configurado de uma entre três formas possíveis:

• assento cativo: quando se indica exatamente qual usuário pode ocupar o assento (fulano@inf.puc-rio.br). Neste tipo de preenchimento, somente o usuário com identificação fulano, no domínio inf.puc-rio.br, tem permissão de ocupar o assento. Caso este usuário não se conecte durante a execução da conferência, nenhum outro usuário estará habilitado a fazê-lo. Tal método de preenchimento deve ser utilizado para os usuários que necessitam ter garantida a participação na conferência, como os componentes da banca avaliadora de uma defesa de dissertação, além do próprio candidato, por exemplo.
• assento para um domínio: quando se deixa o assento disponível para uma comunidade de um determinado domínio (*@inf.puc-rio.br). Neste tipo de preenchimento qualquer usuário com domínio inf.puc-rio.br estaria habilitado a ocupar o assento. Com a configuração (*@*puc-rio.br) qualquer usuário cujo domínio possua a terminação puc-rio.br, poderia ocupar o assento. Este tipo de configuração deve ser utilizado se se deseja garantir assentos para um certo número de usuário de uma determinada comunidade numa conferência, como por exemplo, um número mínimo de usuários de um departamento na mesma defesa de dissertação.
• assento geral: quando se deixa o assento disponível para qualquer participante (*@*). Este tipo de preenchimento permite que qualquer usuário ocupe o assento. Tal configuração deve ser utilizada quando se deseja disponibilizar assentos para a comunidade em geral.

Pode-se ainda idealizar a utilização do sistema para suporte à educação à distância, onde as conferências seriam aulas para determinadas turmas. Os professores e alunos teriam assentos cativos e, opcionalmente, alguns assentos gerais poderiam ser disponibilizados. Educação à distância desponta como uma aplicação que pode vir a tirar bom proveito de sistemas de videoconferência.

Além dos assentos e tipos de preenchimento, o organizador deve indicar os direitos de acesso de cada participante. Esta operação é realizada através de operações de habilitação e desabilitação de cada uma das funções do sistema (como envio de áudio, vídeo e mensagens textuais, acesso à base compartilhada, hiperbase pública e base privada, visualização do vídeo do interlocutor, vídeo local ou vídeo de participante, votação etc.). O organizador pode selecionar um dos participantes para ser o coordenador da conferência.

Ainda na fase de pré-conferência, vários outros aspectos, como o tempo máximo dado a cada interlocutor, o tamanho do intervalo de silêncio a ser considerado para cada interlocutor e o formato da interface da conferência devem ser determinados.

O TVS implementa as operações de pré-conferência através de interações do MIU com o daemon de controle e de conexão. O daemon é responsável pela manutenção de um cadastro de conferências agendadas, dos assentos e seus tipos de ocupação, das votações ativas e apuração de votos de cada conferência. É o daemon que controla o acesso dos usuários às conferências e coordena a passagem do controle do ambiente (Floor Control) do interlocutor para outro participante. Uma discussão detalhada sobre a implementação é apresentada no Capítulo V desta dissertação.

4.6. Início e Término da Conferência

Uma vez iniciado o sistema, a primeira tarefa do MIU é requisitar ao daemon a lista de conferências agendadas, possibilitando ao usuário escolher a conferência que deseja participar, conforme apresentado na Figura 4.6. Selecionada a conferência, o MIU solicita ao daemon uma autorização de entrada. Neste ponto, o acesso é negado ou o ambiente da conferência selecionada é apresentado ao usuário, dependendo da existência ou não de um assento que pode ser ocupado pelo participante em potencial.

Nas demais estações, dos participantes de uma conferência em andamento, as informações do novo usuário são acrescentadas à janela de participantes, além de surgir uma mensagem na console (ao menos do coordenador da conferência) indicando o ocorrido. Imediatamente o novo participante passa a ter os mesmos direitos e deveres dos demais.

Quando um participante deseja se desconectar de uma conferência, temporariamente ou não, a sua MIU deve enviar uma mensagem de desconexão ao daemon de controle e de conexão e este retransmite a mensagem em difusão para os demais usuários. Todas as estações atualizam a sua janela de lista de participantes, excluindo o ex-participante, e as operações dependentes dele são canceladas (por exemplo: se o ex-participante for o interlocutor, imediatamente a permissão é passada para outro candidato).

Na console (ao menos do coordenador da conferência) aparece uma mensagem indicando que o participante em questão se desconectou.

4.7. Gerenciamento da Conferência

Durante uma conferência o coordenador possui uma janela, acrescentada à sua interface, que permite que ele modifique a configuração de qualquer participante em qualquer instante e tantas vezes quantas ele julgue necessárias. Deste modo, o coordenador está habilitado a desligar o microfone de um participante qualquer, tornando-o mero ouvinte, ou até mesmo desconectar o participante da conferência (expulsá-lo).

O coordenador está habilitado ainda a interferir no algoritmo de passagem de controle de acesso ao ambiente da conferência, para isto basta que ele selecione quem deve ser o próximo interlocutor e, quando chegar o instante de permuta do interlocutor, o participante indicado ganha o controle.

A conjunção da indicação do próximo interlocutor com o desligamento do microfone do interlocutor atual, permite que o coordenador escolha quem será o próximo interlocutor e em qual momento, ignorando deste modo o algoritmo gerenciamento de passagem de permissão implementado pelo sistema.

Considerando estas características, pode-se configurar o TVS para que as mudanças de controle de acesso ao ambiente sejam realizadas, inclusive, manualmente pelo coordenador, bastando que se configure o tempo de locução de cada interlocutor e o tamanho do intervalo de silêncio com um valor suficientemente elevado.

4.8. Controle de Acesso ao Ambiente

O TVS implementa o controle de acesso, usualmente denominado floor control, através da técnica de deteção de silêncio [Fari 92]. O MIU do interlocutor envia sinais de áudio e vídeo diretamente para as demais estações. Os MIU’s receptores executam um algoritmo de deteção de silêncio em tempo real, buscando um intervalo de silêncio acima de um limite, estipulado pelo organizador para aquele interlocutor. O limite pode ser modificado pelo coordenador durante a conferência.

O algoritmo de deteção de silêncio é baseado na medição otimizada da amplitude e freqüência médias do sinal de áudio, através da média dos valores absolutos das amostras PCM [G.711] e da taxa de cruzamento por zero, respectivamente. Quando estas medidas se encontram abaixo de um limite configurado, o pacote de áudio é assumido como sendo de silêncio. Após um número de pacotes de silêncio consecutivos o sistema assume que foi finalmente detetado silêncio no sinal de áudio transmitido. O número de pacotes de silêncio que o sistema utilizará para a indicação de deteção de silêncio é calculado a partir do intervalo de tempo indicado pelo organizador de modo individual para cada participante da conferência.

Uma vez detetado o silêncio, o MIU do participante colhe algumas amostras do áudio local, analisa e envia um pacote de requisição do controle "Asking for the Floor" para o daemon de controle e de conexão. O pacote contém a média dos valores absolutos das amostras locais de áudio ou o valor nulo, se a análise das amostras indicar silêncio local.

Uma vez que o daemon tenha recebido as mensagens "Asking for the Floor" de todos os participantes da conferência, ele executa um algoritmo de seleção do próximo interlocutor e envia uma mensagem "Giving the Floor" de difusão para todos os participantes da conferência indicando o novo interlocutor. Automaticamente o novo interlocutor ganha o acesso ao ambiente da conferência.

O algoritmo de seleção do próximo interlocutor escolhe o participante cuja média dos valores (amplitude) das amostras PCM de áudio possuam valor acima do limite considerado silêncio e cujo participante possua a maior prioridade, isto é, escolhe o participante que demonstrou interesse em falar (não está em silêncio) e possui maior prioridade. Caso haja empate na prioridade de vários participantes, o sistema escolhe um deles de forma aleatória.

O coordenador pode interferir no mecanismo de escolha do próximo interlocutor através do envio de uma mensagem de prioridade para a estação de um participante que deve ser o próximo interlocutor. Quando um participante recebe a mensagem de prioridade do coordenador, o valor da prioridade é modificado para um valor padrão de maior prioridade que aquelas utilizadas pelos demais participantes. Desta forma fica garantida a seleção deste participante para próximo interlocutor.

4.9. A Codificação da Mídia Áudio

A codificação de áudio utiliza a recomendação G.711 da ITU-T, como indicado na recomendação F.730, apresentada na Seção 2.1. O PCM é um método de digitalização de um sinal, ou seja, transformação de um sinal analógico (a voz no nosso caso) em sinal digital. A recomendação G.701 define o PCM como um processo no qual um sinal é amostrado e cujas amostras são quantizadas de modo independente das outras e posteriormente convertidas para um sinal digital através de codificação. A Figura 4.7 apresenta um esquema do funcionamento do codificador PCM.

A ITU-T define, na sua recomendação G.711, uma codificação linear e duas codificações logarítmicas a m -law e A-law [G.711].

O sinal trocado pelas estações TVS é composto de amostras PCM com a codificação logarítmica m -law.

O PCM com codificação m -law é o padrão da telefonia nos Estados Unidos, Canadá e Japão, sendo utilizada a codificação logarítmica A-law no restante do mundo, inclusive o Brasil, bem como nas conexões internacionais. A conversão do PCM m -law para o PCM A-law é extremamente simples, bastando realizar a conversão apresentada na tabela da Figura 4.8, e pode ser utilizada para interconexão do TVS com a telefonia local, como requisitado no Capítulo II. A conversão consiste da troca dos valores m -law para os valores A-law correspondentes.

No instante da execução do algoritmo de deteção de silêncio, apresentado na Seção 4.7, as amostras PCM com codificação m -law de 8 bits são convertidos em amostras PCM linear de 14 bits, uma vez que a codificação linear se mostra mais apropriada para o algoritmo, que analisa a amplitude e freqüência do sinal.

4.10. A Codificação da Mídia Vídeo

O TVS utiliza a recomendação ITU-T H.261 [H.261] para codificar os sinais de vídeo, como requisitado pela recomendação ITU-T F.730 [F.730] apresentada na seção 2.1 desta dissertação. O H.261, também conhecida como p´ 64, é um método de codificação de sinal de vídeo desenvolvido para aplicações em tempo real. O H.261 define dois formatos de imagem, o CIF e o QCIF, respectivamente com resolução de 352 pixels por linha e 288 linhas por imagem e 176 pixels por linha e 144 linhas por imagem, ambas codificadas com uma componente de luminância e duas de crominância, como apresentado na Figura 4.9. A razão de apresentação das imagens é de 3:4, proporcional a uma imagem de televisão convencional.

O Codificador/Decodificador de Vídeo desta recomendação tem duas partes principais, apresentadas na Figura 4.10.

• Codificador da Fonte: responsável pela transformação da imagem captada pelo dispositivo de captura de vídeo, NTSC, PAL ou SECAM, para um dos formatos mencionados.
• Codificador de Vídeo Multiplexado: responsável pela codificação da imagem numa estrutura de dados hierárquica.

As próximas sessões apresentam resumidamente o processo de codificação e decodificação H.261 com o intuito de definir a estrutura de dados gerada. Maiores detalhes sobre os algoritmos, no entanto, devem ser buscados em [H.261, Turl 95, Turl 93, Liou 91, Reev 94].

4.10.1. O Codificador da Fonte

O Codificador da Fonte trabalha com blocos, que são grupos de 8´ 8 pixels. Cada quatro blocos de luminância são combinados com um par de componentes de crominância, conforme a Figura 4.9, formando o que se denomina um macrobloco.

A codificação de uma imagem pode ser verificada através da Figura 4.11, onde pode-se ver cada pixel do macrobloco com seus respectivos componentes de crominância.

4.10.2. O Codificador de Vídeo Multiplexado

O Codificador de Vídeo Multiplexado utiliza uma estrutura hierárquica com as seguintes camadas:

• Imagem: Essa camada serve para uniformizar os formatos de imagem em elementos padrão. A imagem é dividida numa quantidade de grupos de blocos, a próxima camada, de acordo com o formato utilizado.
• Grupo de Blocos (GOB): Consiste de um conjunto de 33 macroblocos, a próxima camada.
• Macrobloco (MB): Consiste de um conjunto de blocos, sendo quatro blocos compostos de sinais de luminância e dois com sinais de crominância.
• Bloco: Um bloco é um conjunto de 8´ 8 coeficientes.

Descreve-se a seguir a composição detalhada de cada uma destas camadas, mostradas na Figura 4.12, apresentando um diagrama de sintaxe e outro de blocos com os componentes da camada.

4.10.2.1. Camada de Imagem

Esta é a camada de nível mais alto cuja função é dividir a figura em grupos de blocos, que compõem a camada posterior.

Um diagrama de sintaxe para esta camada é apresentado pela Figura 4.13. Cada imagem é composta por um cabeçalho precedido de grupos de blocos. É importante ressaltar que os cabeçalhos das imagens que não são transmitidas, são desprezados.

Onde:

• PSC é uma palavra de 20 bits cujo valor fixo é: 0000 0000 0000 0001 0000
• TR é um número de 5 bits que serve para dar seqüência às imagens transmitidas através do incremento de um do valor da imagem anteriormente transmitida acrescentado do número de imagens descartadas.
• PTYPE consiste de um campo de 6 bits que contém as informações abaixo sobre a imagem transmitida.

• PEI ocupa apenas 1 bit que quando em 1 indica que o campo PSPARE está presente. Esta estrutura permitirá futuras expansões da recomendação, como visto na Figura 4.13. Pode-se utilizar tantos campos PSPARE quantos forem necessários.
• PSPARE. Cada estrutura PSPARE contém nove bits, sendo que os oito primeiros podem ser utilizados para armazenar um dado qualquer e o nono é mais um bit PEI. Desta forma, consegue-se um espaço útil de 0, 8, 16, ... bits com a utilização de 0, 1, 2, ... estruturas PSPARE.

4.10.2.2. Camada de Grupo de Blocos (GOB)

Cada imagem é dividida em 12 grupos de blocos se o formato utilizado for CIF e 3 se for o QCIF. Cada GOB tem 176 pixels por 48 linhas de sinais de luminância e 88 pixels por 24 linhas de cada um dos sinais de crominância, Figura 4.9. A disposição dos GOB's na imagem são apresentados na Figura 4.15.

Cada grupo de blocos tem um cabeçalho precedido por dados de macroblocos, que são a camada posterior, conforme apresentado no diagrama de sintaxe da Figura 4.16.

Os componentes do cabeçalho de um GOB são:

• GBSC é uma palavra de 20 bits cujo valor fixo é 0000 0000 0000 0000 0001
• GN é um número de 4 bits que indica a posição do GOB na imagem. A posição pode ser visualizada na Figura 4.15.

• GQUANT é uma palavra de tamanho fixo (5 bits) que indica o quantizador que deve ser utilizada pelo até que redefinido pelo campo MQUANT. A recomendação apresenta 32 quantizadores, sendo 1 utilizado para os coeficientes dc da codificação INTRA e 31 para os demais coeficientes. O campo GQUANT indica qual quantizador deve ser utilizado.
• GEI ocupa apenas 1 bit que quando setado em 1 indica que o campo GSPARE está presente. Esta estrutura permitirá futuras expansões da recomendação, como visto na Figura 4.16. Podemos utilizar tantos campos GSPARE quantos forem necessários.
• GSPARE. Cada estrutura GSPARE contém nove bits, sendo que os oito primeiros podem ser utilizados para armazenar um dado qualquer e o nono é mais um bit GEI.

4.10.2.3. Camada de Macroblocos (Macroblock layer - MB)

Cada Grupo de Blocos da camada anterior é dividida em 33 Macroblocos, como mostrado na Figura 4.18. Cada macrobloco possui 16 pixels por 16 linhas de valores de luminância e 8 pixels por 8 linhas de cada um dos sinais de crominância.

Cada macrobloco possui um cabeçalho e dados de Blocos, a próxima camada. O cabeçalho de um macrobloco tem a estrutura mostrada pelo diagrama de sintaxe visto na Figura 4.19.

Onde:

• MBA é uma palavra de tamanho variável que indica a posição do macrobloco dentro do GOB. A Figura 4.20 apresenta os códigos de cada macrobloco. Os códigos extra apresentados, MBA stuffing e Start Code, são códigos especiais. O primeiro precede o cabeçalho de um macrobloco e o segundo o antecede. Os macroblocos que não contém informações úteis para a imagem não são transmitidos.
• MTYPE é um campo de tamanho variável que fornece diversas informações, apresentadas na Figura 4.21, sobre o macrobloco, entre elas a codificação utilizada (NTRA ou INTER), a utilização ou não de compensação de movimento e de filtros.

• MQUANT é uma palavra de 5 bits que só está presente se indicado em MTYPE. A função deste campo é modificar o quantizador utilizado, definido pelo campo GQUANT ou MQUANT anterior.

• MVD é obtido pela subtração do vetor de um macrobloco do vetor do macrobloco à esquerda do atual. As posições são apresentadas na Figura 4.18. Os macroblocos que se encontram na borda esquerda, 1, 12 e 23, utilizam um vetor preenchido por zeros no cálculo, uma vez que não possuem macrobloco à esquerda. O MVD é uma palavra de tamanho variável para a componente horizontal e outra para a componente vertica. Os valores são apresentados na Figura 4.22.
• CBP, apenas está presente se indicado em MTYPE, é uma palavra que indica que blocos no macrobloco tiveram ao menos um coeficiente da transformada transmitidido. O número padrão é dado pela expressão , onde Pi = 1 se algum coeficiente está presente no bloco i, caso contrário vale 0. A numeração dos blocos no macrobloco é apresentada na Figura 4.9.

Os códigos para CBP são apresentados na Figura 4.23.

4.10.2.4. Camada de Blocos (Block Layer)

Um macrobloco é composto de quatro blocos de luminância e dois de crominância, conforme apresentado na Figura 4.9. Cada bloco tem uma palavra com os coeficientes da transformada precedidos por uma marca de fim de bloco. Vide Figura 4.24, que apresenta um diagrama de sintaxe para esta camada.

O campo TCOFF está presente em todos os seis blocos de um macrobloco, quando MTYPE indica INTRA mode, caso contrário MTYPE e CBP indicam que existem coeficientes de dados transmitidos. Os coeficientes da transformada são transmitidos na seqüência em ziguezague indicada pela Figura 4.25.

4.11. Empacotamento das Mídias

4.11.1. A Recomendação H.320

A recomendação H.320 da ITU-T especifica a estrutura básica de serviços de conferência audiográfica, videofonia e videoconferência. Esta recomendação aponta um conjunto de outras recomendações necessárias para estes serviços, como apresentado abaixo e na Figura 4.26.

• H.320 ¾ Estrutura básica para os serviços de teleconferência. Faz referência às outras recomendações da família [H.320].
• H.261 ¾ Codificação e compressão de sinais de vídeo, conforme apresentado na Seção 4.10 [H.261].
• H.221 ¾ Especifica a estrutura de quadro utilizada. Consiste de um padrão para multiplexação dos sinais de áudio e vídeo, bem como outras mídias, em um ou mais canais ISDN [H.221].
• H.230 ¾ Especifica o controle de transmissão de quadros, estendendo a Recomendação H.221 [H.230].
• H.231 ¾ Especifica o funcionamento dos MCU’s [H.231].
• H.242 ¾ Especifica o mecanismo de inicialização de comunicação [H.242].
• H.233 ¾ Especifica o mecanismo de encriptação para a implementação de confidencialidade nas comunicações [H.233].
• G.711, G.722 e G.728 ¾ Especifica codificações de áudio que podem ser utilizadas. A Seção 4.9 apresenta maior detalhamento da Recomendação G.711 [G.711, G.722, G.728].

Sobre o sincronismo entre as mídias áudio e vídeo, deve-se considerar as seguintes características do conjunto de recomendações da família H.320:

• A recomendação H.320 indica que o sincronismo entre as mídias áudio e vídeo deve ser implementado através da introdução de retardo no sinal de áudio, uma vez que a codificação do sinal de vídeo requer mais tempo que a codificação de áudio.
• A recomendação H.261, no seu Anexo C, apresenta um método de medida do retardo introduzido pelo codificador/decodificador de vídeo, comumente denominado codec, não indicando, entretanto, o algoritmo a ser utilizado.
• A recomendação H.221 especifica a multiplexação das mídias num único sinal, sem garantia da manutenção do sincronismo entre as mídias.

4.11.2. O padrão ISO-MPEG

O padrão ISO-MPEG possui cinco partes, a saber:

• MPEG-Video: que consiste de um padrão para a codificação e compressão de vídeo, estando descrito no documento IS 11172-2 da ISO.
• MPEG-Audio: que consiste de um padrão para a codificação e compressão de áudio, estando descrito no documento IS 11172-3 da ISO.
• MPEG-System: que especifica como os sinais de áudio e vídeo devem ser multiplexados, além de especificar um mecanismo para garantir a sincronização entre as mídias, estanto descrito no documento IS 11172-1 da ISO.
• MPEG-conformance testing: descrito no documento IS 11172-4 da ISO.
• MPEG-software coding: descrito no documento IS 11172-5 da ISO.

O MPEG-1 apresenta uma qualidade similar à de um VCR e taxa de transmissão inferior a 1.2 Mbps.

O MPEG-2 possui qualidade equivalente a sinais de vídeo de estúdios de TV, além de sinais de vídeo HDTV. A taxa de transmissão é inferior a 10 Mbps para TV convencional e inferior a 20 Mbps para HDTV.

O MPEG-3 estava sendo desenvolvido para HDTV, quando este formato foi incluído na especificação MPEG-2.

O MPEG-4 está sendo idealizado tendo qualidade razoável para sistemas de videoconferência em ambientes com baixíssima disponibilidade de banda passante. A taxa de transmissão deve ser inferior a 64 Kbps, com 10 quadros por segundo de imagens no formato ITU-T QCIF.

O sincronismo entre as mídias de áudio e vídeo é implementado através do uso de time-stamps, que consiste de marcar o sinal de áudio e vídeo com valores que indicam a relação entre as mídias. Estes valores são utilizados pela estação destino para o consumo simultâneo das mídias com a mesma marca.

4.11.3. O Formato de Quadro Utilizado

O TVS utiliza um formato de quadro genérico. O padrão H.221 não foi utilizado por introduzir uma complexidade no codificador e decodificador das mídias sem trazer benefício do sincronismo das mídias. Optou-se pela utilização da técnica de time-stamp utilizada no padrão ISO MPEG.

4.12. Suporte à Manipulação de Documentos

4.12.1. A Máquina HyperProp

A máquina HyperProp, na sua implementação atual, apresenta uma arquitetura cliente/servidor. No caso, a implementação da máquina é o servidor, continuamente em execução, aguardando requisições dos clientes. Cada uma das sessões do TVS são clientes, que enviam as requisições e recebem as respostas do servidor através da camada de comunicação HyperProp, que nada mais é que a implementação do módulo cliente HyperProp discutida na seção 4.1.

A máquina HyperProp armazena a estrutura de todos os documentos multimídia/hipermídia de todas as bases privadas, bem como da hiperbase. A máquina armazena também informações necessárias para a recuperação de um documento. Uma versão futura deve fornecer o próprio armazenamento dos documentos multimídia/hipermídia.

São ações usuais do TVS, quando interage com a máquina HyperProp, requisitar o tipo de um nó, requisitar os elos de um nó, requisitar o destino de um determinado elo, entre outras.

4.12.2. O Browser de Base e de Hiperbase

O browser de hiperbase é utilizado para possibilitar a navegação pela Hiperbase Pública, que consiste de um repositório de documentos acessível a todos os participantes de uma conferência.

O browser de base é utilizado para possibilitar a navegação pela Base Privada do participante, que consiste de um repositório volátil de documentos com acesso restrito ao participante em questão.

A função dos browsers é facilitar a navegação de um participante pelas estruturas aninhadas dos documentos multimídia/hipermídia que, quando possuem uma quantidade elevada de nós e elos, não é uma tarefa trivial [Much 96, MuSC 95]. Uma vez que a quantidade de nós pode dificultar a localização daqueles de interesse, os browsers utilizam a técnica de filtragem "olho de peixe". Esta técnica consiste do cálculo da "proximidade" de cada nó do "nó em foco", apresentando apenas os nós próximos ou de importância elevada. Os nós apresentados devem ser suficientes para que o participante tenha intuição sobre a sua localização temporal e espacial. Uma discussão detalhada sobre estes tópicos é apresentada em [Much 96].

Através dos browsers é possível selecionar nós, seguir seus elos e alcançar outros nós, criar novos nós etc. É possível, ainda, o secretário selecionar um nó cuja versão se deseja incluir na base compartilhada do TVS.

No ponto de vista do sistema, os browsers funcionam como processos de navegação e seleção pelos documentos multimídia/hipermídia. Os browsers enviam mensagens, indicando as seleções do secretário, para o sistema através da camada de comunicação de seleção ou comunicação do Browser.

Os browsers trocam mensagens com a máquina HyperProp com o intuito de recuperar e apresentar a estrutura dos documentos multimídia/hipermídia. Esta troca de mensagens está, entretanto, fora do escopo do sistema TVS, estando também detalhada em [Much 96].

4.12.3. Interação TVS / HyperProp / Browsers

O TVS provê suporte ao trabalho cooperativo através da função de manipulação cooperativa de documentos multimídia/hipermídia implementados na janela de base compartilhada, que funciona como uma área visualizada por todos os participantes da conferência.

Versões de documentos da Hiperbase Pública podem ser manipulados nesta janela de modo cooperativo pelos participantes. A regra de controle de acesso é simples: o interlocutor acumula as funções de secretário, podendo delegar estas funções a um outro participante da conferência. Periodicamente, as alterações, efetuadas pelo secretário, são espelhadas nas demais janelas de base compartilhada dos outros participantes. No instante em que ocorre uma mudança de interlocutor, o sistema automaticamente consolida as últimas alterações do secretário anterior e passa a permissão de alteração para o novo secretário, indicado pelo novo interlocutor. Caso o novo secretário seja o mesmo anterior, a operação fica transparente podendo o secretário prosseguir com suas alterações, sem interrupções. Conceitualmente, os documentos da janela Base Compartilhada fazem parte de uma base privada cujo "dono" é o próprio sistema. Assim, as alterações realizadas são na realidade requisições de alteração que o secretário faz ao sistema e este (dono da base) as realiza.

A Base Compartilhada pode ainda receber documentos provenientes da Base Privada do usuário, desde que tal documento obedeça as regras de versionamento do MCA, conforme detalhado em [SoCR 95].

Os documentos apresentados na base compartilhada consistem de uma versão dos documentos originais disponíveis nas demais bases do sistema. As alterações realizadas nesta versão compartilhada do documento não modificam o conteúdo do documento original, sendo necessária a operação de check-out definida pelo Modelo de Contextos Aninhados [SoCR 95] para que a nova versão do documento original seja consolidada na Hiperbase Pública, a única persistente.

O tempo de vida da base compartilhada de uma conferência, bem como das bases privadas de seus participantes, está limitado ao tempo de realização da conferência.

A Figura 4.27 apresenta a esta troca de mensagens realizada quando o secretário seleciona um documento multimídia/hipermídia em um dos browsers e uma versão do documento é apresentada na base compartilhada. Os seguintes passos são realizados:

• O browser envia uma mensagem ao MIU, através da classe de comunicação de mensagens do Browser, indicando o documento que o secretário selecionou {1}.
• O MIU envia uma mensagem para a Máquina HyperProp, através da camada de comunicação HyperProp, requisitando o conteúdo do documento multimídia/hipermídia {2}.
• A máquina HyperProp responde à requisição através de uma mensagem com as informações necessárias à recuperação do documento selecionado {3}.
• O MIU recupera o conteúdo do documento e o apresenta na Base Compartilhada, enviando ainda uma mensagem à máquina HyperProp, pela camada adequada, indicando a inclusão do novo documento na base compartilhada, que consiste da base privada do próprio sistema TVS.
• O MIU envia uma mensagem ao daemon {4}, e este retransmite a mensagem para os demais participantes da conferência {5}.
• Finalmente, os demais participantes requisitam da máquina HyperProp as informações necessárias à apresentação do conteúdo do documento {6} e a máquina HyperProp envia mensagem com estas informações {7}.

Conceitualmente o documento apresentado na base compartilhada é uma versão do documento original, proveniente de uma das duas outras bases.

A operação de check-out consiste do envio de mensagem à máquina HyperProp, para incluir a nova versão do documento na Hiperbase Pública, com posterior armazenamento do conteúdo do documento.

As operações de "abertura" de uma versão de um documento, em conjunto com a operação de check-out e controle de acesso aos documentos, permitem a manipulação cooperativa de documentos com as características levantadas no Capítulo II.

4.13. Votação

O TVS provê suporte a votações. Em qualquer instante um participante pode criar uma votação, indicando o título e as opções da votação, selecionar uma votação previamente configurada e finalmente votar. Um participante pode ainda apagar uma votação cujo criador for ele próprio.

Todas as operações relacionadas à votação implicam em troca de mensagens do MIU do participante com o daemon de controle e de conexão, via camada de comunicação de mensagens de controle.

Desta forma, o daemon centraliza a responsabilidade de criar e manter os dados de cada votação, bem como receber e validar os votos dos participantes, realizando a apuração dos resultados e indicando aos participantes, ou ao menos ao coordenador da conferência, o resultado da votação. Entre as operações de validação dos votos, o daemon evita que um mesmo participante vote mais de uma vez, através do descarte dos votos adicionais.

Um participante somente estará habilitado a votar se o coordenador, ou o organizador, o tiver habilitado a esta função. É usual que os assentos gerais ou restritos a um domínio não tenham direito a voto, uma vez que não se pode garantir qual participante o ocupará.

4.14. Envio de Mensagens Textuais

Em qualquer instante, um participante pode enviar uma mensagem textual para um outro participante ou grupo de participantes da conferência. Deste modo o sistema garante a troca de informações entre usuários, uma vez que não permite conversas paralelas. O organizador pode desabilitar esta função para um determinado usuário ou grupo de usuários, podendo também o coordenador habilitar/desabilitar esta função para cada usuário durante o desenrolar da conferência.

Existem dois tipos de mensagens textuais: aquelas endereçadas a um participante específico e aquelas endereçadas a todos os participantes da conferência. As primeiras mensagens são enviadas através da camada de comunicação de controle, do participante origem diretamente para o destino, sem passar pelo daemon. Já as outras são enviadas, também pela camada de controle, para o daemon e este envia em difusão para todos os participantes. O daemon, intermediando esta operação, diminui a sobrecarga sobre o MIU do usuário.

Capítulo V

5. A Implementação

5.1. O Módulo de Interação com o Usuário

A interface do TVS foi implementada utilizando o sistema de interfaces IUP/LED [Levy 93], desenvolvido no Departamento de Informática da PUC-Rio. A versão utilizada é a do IUP-Motif. O código do sistema TVS está escrito em C++, estando o daemon escrito em C.

A implementação atual cria uma abstração da interface apresentada ao usuário. Existe basicamente uma classe que dispara os métodos relacionados a cada elemento de interface (diálogo), uma classe que é responsável pela transmissão de sinais de controle, outra para transmissão das mídias e mais uma responsável pelas comunicações com a máquina HyperProp, como apresentado na Figura 5.1. Todas as transferências de informações são realizadas através de envio de datagramas através de soquetes UDP.

O MIU utiliza dois soquetes, um para envio de dados de controle e outro para envio das mídias, associados às portas 5551 e 5552, respectivamente. Adicionalmente o MIU utiliza um soquete, associado à porta 5555, para troca de mensagens com os Browsers de Base Privada e Hiperbase Pública, e outro, cuja porta é configurável, para troca de mensagens com a máquina HyperProp.

O TVS implementa a camada de comunicação através de três classes: Transmissão de Controle, Transmissão das Mídias e Comunicação HyperProp. A classe de transmissões de controle implementa as sub-camadas de comunicação de controle e de seleção (Browser). A classe de comunicação das mídias implementa a sub-camada de mesmo nome. A Classe HyperProp consiste do módulo cliente da implementação da máquina HyperProp, como apresentado em [UcMu 96], e implementa a sub-camada de mesmo nome.

A classe de vídeo local é a responsável pela captura e codificação das mídias de áudio e vídeo, uma vez que esta classe é responsável pela apresentação da mídia vídeo na janela de vídeo local. Posteriormente, os dados são enviados, através da camada de comunicação de mídias, para os participantes adequados. Os métodos desta classe são ainda responsáveis pelo empacotamento das mídias nos quadros TVS Mídia, cuja estrutura é apresentada adiante. A transmissão das demais mídias ¾ texto, imagem estática etc. ¾ é realizado quando da abertura de um nó da hiperbase pública ou da base privada de um participante. Posteriormente, apenas as atualizações são transmitidas, em tempo real.

Todas as mensagens enviadas através da camada de comunicação de mídias utilizam a codificação TVS Mídia, já as mensagens enviadas pela camada de controle utilizam um formato de pacote genérico, apresentado adiante.

5.2. O Daemon de Controle e de Conexão

5.2.1. Estruturas de Dados Utilizadas

Os dados sobre as conferências e votações são armazenadas em arquivos criptografados, lidos quando da ativação do daemon. Os arquivos possuem a seguinte nomenclatura, com as respectivas estruturas:

tvsd.cfg

0001 HyperProp Project Metting 04 10/02/1996
0002 Thesis Defense 05 08/15/1996
0003 ITU-T Geneva Metting (Working Group XV) 04 10/20/1996

Para cada uma das conferências temos ainda o seguinte arquivo com informações sobre os assentos, seus tipos de preenchimento e votações da conferência. No exemplo em questão, apresenta-se os nomes de arquivo para a conferência de código 0001:

tvsd0001.cfg

01 P hprop   inf.puc-rio.br 015 111111111111111
02 P *       inf.puc-rio.br 020 111111111111111
03 P jauvane inf.puc-rio.br 015 111111111111111
04 C lfgs    inf.puc-rio.br 012 111111111111111
v01 Sabor da Pizza

Para cada uma das votações indicadas no arquivo anterior, temos o seguinte arquivo com as opções da votação:

tvsd0001.vote01.cfg

Catupiri
4 Queijos
Mussarela
Vegetariana

Quando ativado, o daemon lê o arquivo de configuração tvsd.cfg. A partir dos dados deste arquivo o daemon lê os arquivos de configuração de cada uma das conferências, tvsd9999.cfg e, dependendo do conteúdo destes, lê cada um dos arquivos que contém dados de votação. Todos os dados armazenados em arquivos são utilizados para criar listas de conferências cujas entradas armazenam os dados da conferência, a saber: o identificador, assunto, número de assentos disponíveis, uma estrutura homogênea para armazenar os dados dos participantes, a data de realização da conferência, o número de votações ativas e uma lista com as informações das votações. De cada votação se armazena o título, um identificador, o identificador do participante que a criou, o número de opções e uma lista com as opções. De cada participante se armazena o nome, a estação e o domínio em que se encontra e dados de controle. As estruturas de dados utilizadas são as seguintes:

struct structVoteOption{
   char sVoteOption[41];
   struct structVoteOption *pNext;
};

struct structVote{
   char sTitle[41];
   int iVoteNumber;
   int iOwnerId;
   int iNumberOfVoteOptions;
   int iCurrentNumberOfVoteOptions;
   struct structVoteOption *pFirstVoteOption, *pLastVoteOption;
   struct structVote *pNext;
};

struct structParticipantNode{
   char sName[21];
   char sHost[21];
   char sDomain[81];
   signed bLive:3;
   unsigned bSeeMe:1;
   int iFloorControlValue;
   struct sockaddr_in stControl;
   struct sockaddr_in stMedia;
};
 
struct structConferencing{
   int iNumber;
   int iSpeakerId;
   char cIsInFloorControlTreatment;
   char sSubject[51];
   int iMaxNumberOfParticipants;
   char sDate[11];
   int iActive;
   int iNumberOfVote;
   struct structParticipantNode *pParticipant;
   struct structVote *pFirstVote, *pLastVote;
   struct structConferencing *pNext;
};

Uma vez que todas as listas estejam preenchidas, o daemon passa ao estado bloqueado, aguardando requisições de serviço. Caso alguma conferência esteja em curso, o daemon, a cada 60 segundos no estado bloqueado, envia uma mensagem de verificação "alive bit" com o intuito de detetar estações inativas. Caso alguma estação não responda à solicitação, o daemon envia uma mensagem de difusão avisando às demais estações da falha ocorrida. Neste instante ocorre a exclusão do participante na estação em falha.

5.2.2. Recursos Utilizados

O daemon possui um único soquete, do tipo datagrama (UDP) [Come 95], associado à porta 5550, para o envio e recepção de mensagens de controle. De acordo com a mensagem recebida, um tratamento adequado é realizado.

O daemon é um processo que usa poucos recursos de CPU, estando a maior parte do tempo bloqueado, aguardando a chegada de mensagens ou do timeout para envio da mensagem "alive bit". Se nenhuma conferência está ativa, ele fica bloqueado até a chegada de alguma requisição. A baixa utilização de CPU permite que a estação onde o daemon está sendo executado possa também executar o MIU do sistema.

5.2.3. Formato dos Quadros Transmitidos

O daemon implementa apenas a camada de transmissão de mensagens de controle. Recebendo e enviando mensagens para os MIU’s dos vários participantes das várias conferências. O quadro da camada de controle, apresentado na Figura 5.2, possui um formato genérico, sendo utilizado nas transmissões através do uso de seus campos para as mensagens de controle, apresentadas na Figura 5.3.

Os seis campos do quadro de controle são os seguintes:

• Com # é um número inteiro, 4 octetos, que indica o código da instrução requisitada.
• Int2 e Int3 são números inteiros, 4 octetos cada, utilizados para vários propósitos, dependendo do comando utilizado.
• String1, String2 e String3 são cadeias de caracteres de uso diverso, dependendo do comando utilizado. As duas primeiras possuem 80 caracteres úteis (81 ao todo), a última possui o restante dos octetos disponíveis para alcançar 256 octetos. A Figura 5.3 apresenta o conteúdo das cadeias de caracteres em vários comandos de controle.

A Figura 5.4 apresenta o diagrama de estados do daemon de controle e conexão. Note que o único estado no qual o daemon está bloqueado é o estado pronto, ou seja, em nenhuma ocasião o daemon envia mensagem para alguma estação e fica aguardando retorno. O daemon sempre recebe uma mensagem ou estoura o timeout para envio do alive bit, faz o tratamento adequado para a mensagem em questão (por vezes enviando mensagens às estações), e finalmente retorna ao estado pronto, onde aguarda a próxima mensagem.

5.3. A Interface Configurável

O TVS possui um arquivo de configuração, cujo conteúdo é apresentado abaixo.

tvs.cfg

logum-ede.inf.puc-rio.br
Hyperbase    : 0 0000 0597 0308 0168
Private Base : 0 0549 0597 0305 0168
Shared Base  : 0 0000 0101 0308 0287
Local Video  : 1 0549 0422 0103 0090
Speaker Video: 1 0549 0101 0211 0180
Partic. Video: 1 0738 0422 0103 0090
Partic. List : 1 0927 0422 0089 0090
Video Control: 1 0927 0101 0089 0065
Audio Control: 1 0927 0236 0089 0097
MainWindow   : 1 0000 0000 0308 0046
LogWindow    : 1 0549 0000 0305 0046
VoteWindow   : 0 -1 -1 0089 0110

A primeira linha do arquivo informa em qual máquina o daemon está sendo executado. A primeira tarefa do MIU, conforme comentado na seção 4.6, é enviar uma mensagem ao daemon, que se encontra no endereço especificado. As demais linhas configuram o ambiente padrão do usuário, possuindo, para cada diálogo, a posição dele na tela além de um flag indicando se o diálogo deve ou não ser apresentado.

A primeira tarefa executada pelo MIU do usuário, antes mesmo de contatar o daemon (como anteriormente comentado), é abrir o arquivo de configuração, armazenando então todas as informações nas classes adequadas. Posteriormente o MIU envia uma mensagem de pedido de informação para a porta utilizada pelo daemon na estação indicada no arquivo.

5.4. A Interação do TVS com os Browsers

As interações entre o MIU e os Browsers de base privada e hiperbase pública são realizados através de troca de mensagens de seleção pela camada Browser. A única ocasião onde ocorre o envio de mensagem de seleção é quando o participante seleciona um documento qualquer num dos browsers. Neste momento o browser sinaliza a seleção do participante ao seu MIU através do envio de uma mensagem de seleção, cujo formato é apresentado na Figura 5.5.

O campo iCode indica o código da operação realizada, o campo EntityId 1 consiste do identificador da perspectiva do nó selecionado, finalmente o campo EntityId 2 indica o identificador do nó selecionado. O conteúdo do terceiro campo é utilizado para o envio de mensagem de requisição de informações necessárias à recuperação do nó selecionado.

5.5. A Interação do TVS com a Máquina HyperProp

As interações entre o MIU do sistema TVS com a Máquina HyperProp são realizadas através de trocas de mensagens pela camada HyperProp, cuja implementação consiste do módulo cliente da arquitetura HyperProp, que possui ainda um processo servidor. O módulo cliente fornece uma interface de alto nível para a programação de aplicações que necessitam interagir com o servidor HyperProp. A arquitetura HyperProp é detalhadamente apresentada em [UcMu 96] e [Bati 94]. O formato dos quadros trocados pela camada HyperProp é mostrado na Figura 5.6.

As interações entre o TVS e a máquina HyperProp são realizadas:

• Após a recepção de uma mensagem de seleção, proveniente de um dos browsers, para obter informações indispensáveis à recuperação do conteúdo do documento multimídia/hipermídia selecionado para que uma versão seja apresentada na base compartilhada do sistema
• Quando operações de armazenamento de um documento da base compartilhada na hiperbase pública ou base privada são realizadas.

O interlocutor ou secretário por aquele indicado, tem o direito exclusivo de alteração nos documentos multimídia/hipermídia que estão na base compartilhada. Todas as operações de edição dos conteúdos dos nós são permitidas. Os demais participantes somente têm permissão de armazenar uma versão dos documentos da base compartilhada na sua base privada ou na hiperbase pública.

Quando o secretário realiza modificações no conteúdo de qualquer documento da base compartilhada, a sua MIU, periodicamente, envia mensagem de atualização do conteúdo dos documentos através da camada de controle.

5.7. A Codificação de Áudio e Vídeo

A codificação de áudio e vídeo é feita, na versão corrente, por software. O algoritmo utilizado é o G.711 [G.711] para o áudio, H.261 [H.261] para a codificação de vídeo. O áudio é capturado diretamente do dispositivo /dev/audio do Solaris com o uso do dispositivo de controle /dev/audioctl, para realizar as operações da classe de controle de áudio (volume, entrada e saída de áudio). O dispositivo de áudio do Solaris fornece as amostras PCM com a transformação logarítmica m-law (8 bits por amostra). Estas amostras são transmitidas pela rede, no destino as amostras PCM m -law são convertidas em amostras PCM linear com 14 bits por amostra para a execução do algoritmo de deteção de silêncio.

A captura de vídeo é feita através de funções da biblioteca Xil, que faz parte do SDK da SUN e executa operações sobre a placa SUNVIDEO de captura de vídeo. Cada quadro é codificado de acordo com a recomendação ITU-T H.261, no formato CIF ou QCIF, conforme o participante seja o interlocutor ou não.

5.8. A Estrutura do Quadro

Após a codificação, os sinais são acomodados em quadros TVS Mídia, apresentados na Figura 5.7. Posteriormente, os quadros são enviados, pelo soquete reservado às mídias, para todos os participantes da conferência, caso o usuário seja o interlocutor, ou, apenas o vídeo, para os participantes com a marca indicativa de observação do usuário em questão em suas janelas de "vídeo do participante".

Os campos do quadro são:

• cType ¾ Tamanho: 1 octeto. Indica o tipo de mídia transmitida. Os valores válidos são apresentados na Figura 5.8.
• iTimeStamp ¾ Tamanho: 4 octetos. Valor inteiro indicando o time stamp do quadro em questão. No destino, o quadro que chegar primeiro é armazenado até a chegada do seu quadro par, quando finalmente ambos são enviados para os dispositivos de saída, o que garante o sincronismo entre as mídias.
• iMediaSize ¾ Tamanho: 4 octetos. Valor inteiro que indica a quantidade de bytes do campo sData que possuem dados úteis.
• sData ¾ Tamanho: 1024 octetos. Contém a mídia propriamente dita.

A mídia áudio bloqueado é enviada pelo interlocutor quando este seleciona a opção "lock", indicando que não deseja ser interrompido, mesmo existindo silêncio. Desta forma, apenas é realizado a deteção de silêncio sobre amostras de áudio normais (cType = 2, na Figura 5.8).

5.9. O Sincronismo das Mídias Básicas

O sincronismo do áudio e vídeo é realizado através da utilização do campo iTimeStamp. Na origem, os quadros de vídeo e seu respectivo áudio são transmitidos com o mesmo valor de iTimeStamp. No destino, a mídia que chegar primeiro é retida até a chegada da outra mídia com o mesmo valor, ou valor próximo, de iTimeStamp, para envio simultâneo aos dispositivos de saída.

O objeto da classe de transmissão das mídias possui um atributo, denominado iTimeStamp, que possui um valor inteiro incrementado periodicamente, a cada 500ms. Quando o valor de iTimeStamp chega ao valor 2²⁴ -1, retorna a um.

Cada um dos pacotes de mídia enviados carrega o valor atual do atributo iTimeStamp, sendo transmitidos intercaladamente pacotes de áudio e vídeo.

5.10. O Controle de Acesso ao Ambiente

O mecanismo de controle de acesso ao ambiente TVS é realizado através de deteção de silêncio, conforme estudo descrito em [Fari 92]. O mecanismo, esquematizado na Figura 5.9, funciona através de um algoritmo bastante simples: Enquanto um interlocutor está expondo oralmente suas idéias, as demais estações ficam em modo de escuta. Cada estação executa o algoritmo de deteção de silêncio apresentado adiante. Quando se detecta um intervalo de silêncio maior que um intervalo de tempo específico, as estações de todos os participantes coletam amostras do áudio local e realizam o algoritmo de deteção de silêncio local. Se for detetado silêncio local ou se o participante for apenas um ouvinte, o MIU envia mensagem ao daemon indicando não haver interesse de concorrer pelo controle de acesso. Caso não seja detetado silêncio, o MIU envia ao daemon uma mensagem de requisição de controle de acesso. O daemon, após receber todas as requisições, seleciona um dos participantes para ser o novo interlocutor. A decisão leva em conta uma lista de prioridades configurada pelo organizador e coordenador da conferência. A seguir, a decisão é enviada a todos os participantes da conferência, quando então o novo interlocutor ganha o direito de acesso. Este Inicia sua locução, enquanto o secretário por ele indicado, ou ele próprio, ganha o direito de acesso à base compartilhada.

O modo de escolha utilizado pelo daemon pode facilmente ser modificado. Uma versão futura do sistema pode oferecer vários modelos de regra de escolha do próximo interlocutor inclusive, idealmente, permitir que se inclua novas regras, através de alguma linguagem de alto nível.

O algoritmo de deteção de silêncio utilizado é o seguinte:

iZeroCrossing = iAmplitudeAvg = 0;
iSampleSignal = 1;

for(iCounter=0; iCounter<44; iCounter++)
{
   iAmplitudeAvg+=abs((iLinearPCMSample = pAudioSamples[iCounter]));

   if((iSampleSignal==1) && (iLinearPCMSample<0))
   {
      riZeroCrossing++;
      riSampleSignal=-1;
   }
   else if ((iSampleSignal==-1) && (iLinearPCMSample>0))
   {
      iZeroCrossing++;
      iSampleSignal=1;
   }
}

iAmplitudeAvg/=iCounter;

if ((iAmplitudeAvg>MAXAVERAGE) || (iZeroCrossing>MINZEROCROSSING))
   iState=1;
else
{
   iSilence++;
   iState=0;
}

if ((iOldState==0) && (iState==1))
   iSilence=0;

if (iState==0 && iSilence>iSilenceNumber && !iSilenceDetected)
   iSilenceDetected = 1;

iOldState=iState;

Quando a quantidade de amostras de silêncio especificada pelo organizador, e modificada pelo coordenador, for atingida, o MIU assume que foi detetado silêncio no sinal de áudio transmitido.

5.11. A Votação

O mecanismo de apuração de uma votação é implementado de forma centralizada pelo daemon, através de mensagens enviadas pelo MIU via soquete de controle. O daemon valida o voto e contabiliza os resultados. Os votos enviados são armazenados em um arquivo cujo formato aparece abaixo.

tvsd0001.vote01.votes.cfg

01 01 hprop   inf.puc-rio.br
03 02 jauvane inf.puc-rio.br

O arquivo apresentado acima tem como função principal de controlar a votação de participantes em assentos gerais ou para um domínio, que podem ter vários participantes, um a cada instante. Quando um participante envia uma escolha de uma votação, o daemon pesquisa o arquivo procurando algum voto cujo Nome do Participante e Domínio coincidam com os dados do novo voto. Apenas os votos de participantes não reincidentes serão considerados. Esta operação impossibilita que um mesmo participante vote mais de uma vez numa votação.

Quando a maioria dos participantes cadastrados escolhe uma das opções, o daemon envia uma mensagem em difusão para todos os participantes da conferência indicando o resultado da votação. A indicação é feita através de mensagem na console.

5.12. Mensagens Textuais

Em qualquer instante um usuário pode enviar mensagens textuais ¾ bilhetes ¾ a qualquer outro participante da conferência, desde que este esteja presente. A mensagem é enviada diretamente à estação destino através do canal de controle. No destino a mensagem é apresentada na console do MIU.

A mensagem é enviada através do botão "Send Message To:" existente na janela "Lista de Participantes". Quando o botão é pressionado, aparece um diálogo, apresentado na janela 5.10, endereçado ao participante selecionado. Quando a mensagem é escrita e confirmada, pelo botão "Send", a mensagem é transmitida pela camada de controle até o destinatário e então exibida na console do destinatário.

5.13. Números da Implementação

A tabela apresentada na Figura 5.11 mostra vários dados quantitativos sobre a implementação do TVS.

Capítulo VI

6. Conclusão

6.1. Contribuições da Dissertação

O TVS apresenta grande maleabilidade de configuração de interface, sendo adequado como suporte a vários tipos de reunião, desde teleseminários às reuniões de decisão. Algumas facilidades, em especial a manipulação cooperativa de documentos multimídia/hipermídia, não são encontradas nos protótipos e produtos comerciais hoje disponíveis, embora sejam previstas e solicitadas pelos padrões ITU-T [F.730].

Com o intuito de levantar características e obter referencial para a implementação do TVS, foram instalados nas estações do Departamento de Informática o IVS, o ViC, o nv e já se encontrava instalado o Cu-SeeMe. Estes sistemas foram utilizados em laboratório enquanto em paralelo a documentação disponível destes sistemas e do sistema do MCRLab era estudada. Durante esta etapa de levantamento, iniciou-se a concepção da interface do TVS, bem como a especificação geral do funcionamento detalhado no Capítulo IV. Do IVS veio a inspiração para a utilização de um daemon de controle de conexão, dos demais sistemas foi aproveitada principalmente a bagagem adquirida na sua utilização, o que possibilitou vários refinamentos e a concepção do sistema com as atuais características.

O TVS possui lugar de destaque principalmente pela utilização de um modelo conceitual de para o armazenamento e recuperação de documentos multimídia/hipermídia, o MCA, de acordo com a proposta de padrão MHEG, da ISO. O único protótipo que também possui um mecanismo de compartilhamento de documentos é o sistema do MCRLab, cujo controle de acesso, permite que os usuários modifiquem um mesmo documento, desde que em posições não coincidentes. O TVS utiliza a técnica descrita o Capítulo V, onde existe um participante especial, denominado secretário, que está habilitado a modificar os documentos da base compartilhada. Os demais participantes podem, entretanto, modificar quaisquer documentos das suas bases privadas.

Quanto ao envio de mensagens textuais, os sistemas CU-SeMee possui um esquema equivalente ao utilizado pelo TVS, tendo o CU-SeeMe, o acréscimo da janela de conversação.

O TVS é o único protótipo a apresentar as características de suporte a votação, controle de acesso e existência de um coordenador.

A Figura 6.1 mostra um quadro comparativo dos diversos sistemas do Capítulo 3.

6.2. Trabalhos Futuros

Uma versão inicial do TVS se encontra operacional no ambiente OpenWindows de estações SUN Microsystems, interligadas por uma rede Ethernet usando o protocolo TCP/IP. A codificação de vídeo é realizada por software. Pretende-se brevemente realizar esta tarefa por hardware específico para aumentar o desempenho, bem como estender a implementação com o intuito de abranger outras arquiteturas e sistemas operacionais.

Como trabalhos futuros, espera-se implementar a operação de gravação de uma sessão de videoconferência, adaptar o sistema para uso em rede ATM, além de incluir mecanismos de segurança, inexistentes no primeiro protótipo, que devem levar em conta dois pontos de vista: transferência segura de informações confidenciais e autenticação de identidade de usuários. O primeiro problema pode ser resolvido através da utilização de um algoritmo eficiente de criptografia [Schn 95]. Já o segundo, é tema atual de pesquisas em vários centros de pesquisa e figura como problema ainda em aberto.

A adaptação para rede ATM utilizaria amplamente as conexões ponto-multiponto. Cada estação estabeleceria uma conexão ponto-multiponto. O interlocutor teria como destino todos os participantes da conferência e as mídias áudio e vídeo seriam transmitidas por esta conexão. Os demais participantes abririam uma conexão ponto-multiponto cujo destino seria composto pelos participantes da conferência marcados, na janela "Lista de Participantes", com o sinal que indica que aquele usuário deseja receber o sinal de vídeo, que seria transmitido nesta conexão. A Figura 6.2 apresenta um esquema do funcionamento de uma conferência com esta configuração.

Uma outra possibilidade seria implementar um MCU, que possui a função de receber as mídias provenientes dos vários participantes e enviar as mídias adequadas a cada estação. A Figura 6.3 apresenta um esquema do funcionamento de uma conferência com esta configuração.

Referências Bibliográficas

[Arro 96] Arrowood, A. - "CU-SeeMe Communications in an Emergent Technology" - LCC/IDT, OIT/NS GRA, Georgia Institute of Technology, February 1996

[Bati 94] Batista, T.C. - "Um Sistema de Autoria para Hiperdocumentos" - Dissertação de Mestrado, Departamento de Informática, PUC-Rio, Março de 1994

[Come 95] Comer, D. - "Internetworking with TCP/IP - Vol I" - 2nd Edition - Prentice-Hall, 1993.

[Come 93] Comer, D. - "Internetworking with TCP/IP - Vol III BSD Socket Version" - 2nd Edition - Prentice-Hall.

[SzVe 93] Szyperski, C. Ventre, G. - "A Characterization of Multi-Party Interactive Multimedia Applications" - International Computer Science Institute TR-93-006, January 1993.

[Dorc 95] Dorcey, T. - "CU-SeeMe Desktop Videoconferencing Software" - Connections, Volume 9, No. 3, March 1995.

[Draft G.723] International Telecommunication Union, Telecommunication Standardization Sector - "Dual Rate Speech Coder for Multimedia Communications Transmitting at 5.3 & 6.3 Kbit/s" - Draft ITU-T Recommendation G.723, September 1995.

[Draft H.263] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Video Coding for Low Bitrate Communications" - Draft ITU-T Recommendation H.263, July 1995.

[Draft H.223] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Multiplexing Protocol for Low Bitrate Multimedia Communication" - Final Draft ITU-T Recommendation H.223, to be published in next.

[Draft H.324] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Terminal for Low Bitrate Multimedia Communication" - Draft ITU-T Recommendation H.324, September 1995.

[Draft H.245] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Multimedia Control Protocol" - Draft ITU-T Recommendation H.324, September 1995.

[Erik 94] Erikson, H. - "MBONE: The Multicast Backbone" - Communications of the ACM, August 1994, Vol 37, pp 54-60.

[F.701] Comité Consultatif International de Télégraphique et Téléphonic - "Teleconference Service" - CCITT Recommendation F.710, from CCITT Blue Book. ITU-T Recommendation F.701.

[F.710] International Telecommunication Union, Telecommunication Standardization Sector - "Telematic, Data Transmission and Teleconference Services: Operation and Quality of Service - General Principles for Audiographic Conference Service" - ITU-T Recommendation F.710, March 1991.

[F.711] International Telecommunication Union, Telecommunication Standardization Sector - "Operation and Quality of Service: Audiovisual Service - Audiographic Conference Teleservice for ISDN" - ITU-T Recommendation F.711, August 1993.

[F.720] International Telecommunication Union, Telecommunication Standardization Sector - "Telematic, Data Transmission, ISDN Broadband, UPT and Teleconference Services: Operations and Quality of Service - Videotelefony Service - General" - ITU-T Recommendation F.720, August 1992.

[F.721] International Telecommunication Union, Telecommunication Standardization Sector - "Telematic, Data Transmission, ISDN Broadband, Universal, Personal Telecommunications and Teleconference Services: Operations and Quality of Service - Videotelefony Teleservice for ISDN" - ITU-T Recommendation F.721, August 1992.

[F.730] International Telecommunication Union, Telecommunication Standardization Sector - "Telematic, Data Transmission, ISDN Broadband, Universal, Personal Communications and Teleconference Services: Operation and Quality of Service - Videoconference Service - General" - ITU-T Recommendation F.730, August 1992

[Fari 92] Faria, A.L.A.; - "Implementação do Mecanismo de Controle de Acesso por Deteção de Silêncio em um Sistema de Teleconferência" - Dissertação de Mestrado - Departamento de Engenharia Elétrica / PUC-Rio, 1992

[Fluc 95] Fluckiger, F. - "Understanding Networked Multimedia - Applications and Technology" - Prentice Hall, 1995

[Fred 94] Frederick, R. - "Experiences with real-time software video compression" - Xerox PARC, July 1994.

[G.701]

[G.711] Comité Consultatif International de Télégraphique et Téléphonic - "Pulse Code Modulation (PCM) of Voice Frequencies" - CCITT Recommendation G.711, from CCITT Blue Book.

[G.722] Comité Consultatif International de Télégraphique et Téléphonic - "7kHz Audio-coding Within 64 kbits/s" CCITT Recommendation G.722, from CCITT Blue Book.

[G.725] International Telecommunication Union, Telecommunication Standardization Sector - "General Aspects of Digital Transmission Systems; Terminal Equipment - System Aspects for the Use of the 7 kHz Audio Codec Within 64 kbit/s" - ITU-T Recommendation G.725, 1988.

[G.728] International Telecommunication Union, Telecommunication Standardization Sector - "General Aspects of Digital Transmission Systems; Terminal Equipment - Coding of Speech at 16 kbit/s Using Low-Delay Code Excited Linear Prediction" - ITU-T Recommendation G.728, September 1992.

[H.100] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Visual Telephone Systems" - ITU-T Recommendation H.100, 1988.

[H.110] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Hypothetical Reference Connections for Videoconferencing Using Primary Digital Group Transmission" - ITU-T Recommendation H.110, 1988.

[H.120] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Codecs for Videoconferencing Using Primary Digital Group Transmission" - ITU-T Recommendation H.120, March 1993.

[H.130] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Frame Structure for Use in the International Interconnection of Digital Codecs for Videoconferencing or Visual Telephony" - ITU-T Recommendation H.130, 1988.

[H.140] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Systems - A Multipoint International Videoconferencing System" - ITU-T Recommendation H.140, 1988.

[H.200] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Framework for Recommendations for Audiovisual Services" - ITU-T Recommendation H.200, March 1993.

[H.221] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Frame Structure for a 64 to 1920 kbit/s Channel in Audiovisual Teleservices" - ITU-T Recommendation H.221, March 1993.

[H.230] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Frame Synchronous Control and Indication Signals for Audiovisual Systems" - ITU-T Recommendation H.230, March 1993.

[H.233] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Confidentiality System for Audiovisual Services" - ITU-T Recommendation H.233, March 1993.

[H.242] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - System for Establishing Communication Between Audiovisual Terminals Using Digital Channels up to 2 Mbit/s" - ITU-T Recommendation H.242, March 1993.

[H.261] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Video Codec for Audiovisual Services at p´ 64 Kbit/s" - ITU-T Recommendation H.261, March 1993.

[H.320] International Telecommunication Union, Telecommunication Standardization Sector - "Line Transmission of non-Telephone Signals - Narrow-Band Visual Telephone Systems and Terminal Equipment" - ITU-T Recommendation H.320, March 1993.

[Hype 95] Soares, L.F.G. at alii - "HyperProp - Uma visão geral" - I Workshop sobre Sistemas Multimídia Distribuídos, São Carlos, SP, Julho de 1995.

[LaHG 93] Lamont, G.; Henderson G.; Georganas, N.D. - "A Multimedia Real-Time Conferencing System: Architecture and Implementation" - Multimedia Communication Research Laboratory - Department of Eletrical Engineering - University Of Ottawa - September 1993.

[Levy 93] Levy, C.H. - "IUP/LED: Uma Ferramenta Portátil de Interface com o Usuário" - Dissertação de Mestrado - Departamento de Informática / PUC-Rio, 1993.

[Liou 91] Liou, M. - "Overview of the p´ 64 kbit/s video coding standard" - Communications of the ACM, No. 4, April de 1991.

[McJa 95] McCane, S.; Jacobson, V. - "vic: A Flexible Framework for Packet Video" - ACM Multimedia 95, San Francisco, CA, November 1995.

[MHEG 95] MHEG - Information Technology - "Coded Representation of Multimedia and Hypermedia Information Obects - Part 1: Base Notation", Committee Draft ISO/IEC, 1995.

[Much 96] Muchaluat, D. - "Browsers e Trilhas para Documentos Hipermídia Baseados em Modelos com Composições Aninhadas" - Dissertação de Mestrado, Departamento de Informática, PUC-Rio, março de 1996.

[MuSC 95] Muchaluat, D.; Soares, L.F.G; Casanova,M.A. - "Browsing in a Hypermedia System with Nested Composite Nodes" - Monografias em Ciência da Computação MCC23 - DI / PUC-Rio, 1995

[OlSo 96] Oliveira, J.C. de; Soares, L.F.G. - "TVS - Um Sistema de Videoconferência como Aplicação HyperProp" - Relatório Técnico TeleMídia # 96-2, Fevereiro de 1996.

[OlSo 96b] Oliveira, J.C. de; Soares, L.F.G. - "TVS - Um Sistema de Videoconferência com Documentos Compartilhados - Uma Visão Geral" - WoSH’96 - II Workshop em Sistemas Hipermídia, XIV SBRC - Simpósio Brasileiro de Redes de Computadores, Maio de 1996.

[Park 95] Parker, T. - "Cornell Welcome Page - http://CU-SeeMe.cornell.edu/" - Cornell University, 1995.

[Reev 94] Reeves, L. - "News document at /SPIB/news/comp.compression/1994.10" - October 1994.

[RTP 94] Schulzrine, H.; Casner, S.; Jacobson, V.; Frederick, R. - "RTP: A Transport Protocol for Real-Time Applications" - Internet Draft ietf-avt-rtp-05, July 1994.

[Schn 95] Schneier B. - "Applied Cryptografy" - 2nd Edition - John Willey, Novembro de 1995.

[SoMB 88] Soares, L.F.G.; Martins, S. de L.; Bastos, T.L.P. - "Lan Based Real Time Audio-Graphics Conferencing System, General Overview" - CCR066 Technical Report Rio Scientific Center-IBM Brasil, Novembro de 1988.

[SoCL 95] Soares, L.F.G.; Colcher, S.; Lemos, G. - "Redes de Computadores - Das LANS, WANS e MANS às Redes ATM" - Editora Campus, Janeiro de 1995.

[SoRC 95] Soares, L.F.G.; Rodriguez, N.L.R.; Casanova, M.A. - "Nested Composite Nodes and Version Control in an Open Hypermedia System" - Information Systems Vol 20, No. 6, pp. 501-519, 1995.

[Tane 96] Tanembaum, A.S. - "Computer Networks" - Third Edition - Prentice-Hall PTR, 1996.

[STCN 92] Soares, L.F.G.; Tucherman, L.; Casanova, M.A.; Nunes, P.R.R.L. - "Fundamentos de Sistemas Multimídia" - VIII Escola de Computação, Gramado, 1992.

[SzVe 93] Szyperski, C. Ventre, G. - "A Characterization of Multi-Party Interactive Multimedia Applications" - International Computer Science Institute TR-93-006, January 1993.

[Turl 93] Turletti, T. - "A H.261 Software Codec for Videoconferencing over the Internet" - INRIA Research Report, No. 1834, January 1993.

[Turl 94] Turletti, T. - "The INRIA Videoconferencing System (IVS)" - ConneXions, Volume VIII, No. 10, October 1994

[Turl 95] Turletti, T. - "Contrôle de Transmission pour Logiciel de Vidéoconférence sur l'Internet" - Thèse de Doctorat, L'Universite de Nice - Sophia Antipolis, Avril 1995.

[UcMu 96] Uchoa, R.C.; Muchaluat, D.C. - "Implementação do Módulo Cliente da Máuina HyperProp" - Relatório Técnico TeleMídia # 96-7, 1996

[Wall 91] Wallace, G.K. - "The JPEG Still Picture Compression Standard" - Digital Equipment Corporation (Submetido para publicação em dezembro de 1991 em "IEEE Transactions on Consumer Eletronics"), 1991.

A. Código Fonte do Sistema

Procure o Vol. II desta dissertação ou o arquivo TVS-Code.ps.zip em ftp://ftp.telemidia.puc-rio.br/pub/tvs

Dissertação de Mestrado apresentada por Jauvane Cavalcante de Oliveira, em 15 de agosto de 1996, ao Departamento de Informática da PUC-Rio e aprovada pela comissão julgadora formada pelos seguintes professores: