NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
28 de julho de 2000 | volume 4, número 4

volta à página inicial de NewsGeneration

Nesta edição:

NewsGeneration:



Endereçamento Multicast e Aplicações Multimídia Distribuídas na RMAV-FLN

Fabiano Bachmann <>
Ivan L. Martins <>
Jean-Marie Farines <>

Núcleo de Redes de Alta Velocidade e Computação de Alto Desempenho
Universidade Federal de Santa Catarina

Resumo
1 Introdução
2 O Problema da Compressão e Transmissão de Mídias Contínuas
2.1 Transmissão de Mídias Contínuas - (Media Streaming)
2.2 Codificação e Compressão de Dados
2.3 Sistemas de Teleconferência
3 Endereçamento Multicast [Kum95]
4 Protótipos Multicast na RMAV-FLN [Bac00a]
4.1 Contexto do Trabalho
4.1.1 Sistemas Finais
4.1.2 Suporte de Comunicação
4.2 Ferramentas Avaliadas
4.3 Protótipos Disponibilizados
4.3.1 Teleseminário Multicast
4.3.1.1 Monitoramento Remoto para as Câmeras
4.3.2 TV Multicast
4.3.3 Rádio Multicast
4.3.4 Rádio MP3 Multicast
4.3.5 Teleconferência Multicast
5 Ensaios e Medidas Realizadas
5.1 Otimização da Utilização dos Recursos
5.2 Avaliação do Suporte de Comunicação
5.3 Melhoria da Qualidade nos Protótipos
5.3.1 TV Multicast
5.3.2 Videoconferência em Desktop
6 Comentários
7 Conclusões e Perspectivas
8 Referências

Resumo

A necessidade de se otimizar a utilização dos recursos de rede, evidenciada pelo crescente volume de dados que trafegam por esta, torna indiscutível a importância do endereçamento multicast, principalmente em aplicações como videoconferência, ensino e treinamento a distância, rádio e TV via Internet.

Outrossim, aplicações multimídia cada vez mais sofisticadas, como as supracitadas, demandam redes de alta velocidade para trafegarem volumes de dados cada vez maiores como voz, imagens e vídeo, muitas vezes com requisitos de tempo-real.

Este artigo apresenta assuntos e conceitos relevantes e relacionados com endereçamento multicast sobre um backbone de alta velocidade, no âmbito do projeto RMAV-FLN - Rede Metropolitana de Alta Velocidade de Florianópolis. Em seguida são apresentados os protótipos, que fazem uso do endereçamento multicast, desenvolvidos durante a primeira fase do projeto. Finalmente são apresentados resultados, avaliações, conclusões, atividades atuais e perspectivas para novos trabalhos nestas áreas.

^

1 Introdução

A maioria das aplicações tradicionais da Internet operam entre um emissor e um receptor. Com os recentes avanços tecnológicos e o aparecimento de aplicações cada vez mais sofisticadas surge a necessidade de transmitir informações para um grupo seleto de participantes distribuídos pelo mundo, como por exemplo, transmissão de mensagens corporativas, áudio e videoconferência para encontros remotos, trabalho corporativo, ensino e treinamento a distância, monitoramento de ambientes e processos remotos, entretenimento, entre outros.

Paralelamente, a necessidade de transferir volumes de informações cada vez maiores por tais aplicações emergentes torna evidente a necessidade de melhoramentos na infra-estrutura da rede atual e também, muitas vezes considerado mais viável, a utilização de mecanismos de comunicação que melhorem a performance de tais aplicações. Assim, é necessário que os mecanismos de comunicação em grupo permitam o uso de endereçamentos de grupo, livrando o programador de detalhes de endereçamento dos processos individuais que compõem o grupo e simultaneamente utilizem a largura de banda disponível na rede de forma mais eficiente. É aí que entra a necessidade do endereçamento multicast.

O que torna o endereçamento multicast tão eficiente é o fato de um pacote poder atingir todas as estações conectadas a uma rede, sem para isto ter de ser replicado. A informação destinada a uma estação usa a mesma largura de banda necessária para alcançar N estações diferentes [Kum95].

Com o desenvolvimento de elementos de rede com suporte ao endereçamento multicast surge, através da Internet, uma rede virtual chamada de Multicast Backbone, ou seja MBone.

Por outro lado, as redes ATM apresentam-se como uma solução que busca resolver grande parte das limitações impostas às aplicações emergentes da Internet, procurado oferecer maior capacidade de transferência de dados através da rede, além de vários serviços exigidos por uma classe de aplicações que surge da sinergia de áreas como redes de banda larga, comunicação de grupo e sistemas distribuídos: os Sistemas Multimídia Distribuídos.

^

2 O Problema da Compressão e Transmissão de Mídias Contínuas

Disponibilizar ambientes multimídia distribuídos a fim de suportar aplicações como videoconferências, ensino e treinamento à distância, teleseminários , rádio e TV via Internet nem sempre são tarefas triviais. Para a realização de tais experimentos tornam-se necessários conhecimentos em diversas áreas, como por exemplo, algoritmos de compressão, protocolos de rede, sistemas operacionais, trabalho cooperativo, endereçamento de grupo, sistemas tempo-real, sistemas distribuídos, entre outros. Na confluência destas áreas encontra-se o foco deste artigo, sistemas multimídia distribuídos que utilizam o endereçamento multicast.

^

2.1 Transmissão de Mídias Contínuas - (Media Streaming)

O Processo de transmissão de informações multimídia, em particular para aplicações tempo-real via Internet, geralmente não é trivial, embora fique transparente para os usuários finais destas aplicações [Flu95].

Como pode ser visto na Figura 1, existem basicamente dois pontos críticos neste processo, que são o meio de comunicação e os sistemas finais utilizados nas pontas do processo. Nas videoconferências atualmente realizadas através da Internet, o suporte de comunicação tem uma grande responsabilidade no baixo desempenho das aplicações.

Figura 1: Transmissão de mídias contínuas

Por outro lado, as redes MANs, que utilizam novas tecnologias de comunicação para interconexão de seus sistemas finais, como o ATM, buscam prover o suporte de comunicação de maior largura de banda e de serviços a fim de garantir melhor desempenho e mais recursos para tais aplicações. Entretanto, é necessário que a evolução aconteça simultaneamente no dois principais pontos de congestionamento, nos sistemas finais e no suporte de comunicação, caso contrário a limitação de um ou de outro prevalecerá.

^

2.2 Codificação e Compressão de Dados

A compressão de dados, especialmente de áudio e vídeo, é necessária para se otimizar a utilização da largura de banda existente nas redes atuais e limitar a demanda por maior capacidade de armazenamento e transferência.

A necessidade de aplicar algoritmos de compressão às mídias difundidas torna-se evidente quando se analisa a Tabela 1, onde são mostrados alguns valores típicos de taxas sem compressão.

Tabela 1: Largura de banda utilizada por alguns padrões de mídias típicos [Flu95]

As técnicas de compressão seguem basicamente dois modos: a compressão sem perda, onde a informação é recuperada sem qualquer alteração depois da descompressão; e a compressão com perda ou irreversível, onde a informação depois da descompressão é diferente da informação original sem compressão. Este modo é o mais conveniente e utilizado para mídias contínuas, como áudio e vídeo.

Os algoritmos de compressão não serão abordados aqui, porem é necessário mencionar que dispensou-se maior atenção aos algoritmos de compressão de vídeo, já que estes geralmente manipulam maior volume de dados num sistema multimídia distribuído, conforme Tabela 1, e também por necessitarem da maioria dos recursos utilizados por tais sistemas.

Enfim, dedicou-se especial atenção aos algoritmos de compressão suportados pelas ferramentas utilizadas nesta primeira etapa do projeto [Bac00b], a saber: M-JPEG, MPEG-1, MPEG-2, ITU-T H.261, ITU-T H.263, Cellb, NV e NVDCT.

^

2.3 Sistemas de Teleconferência

Um sistema de teleconferência pode ser definido como um conjunto de ferramentas que usam meios eletrônicos para garantir comunicação entre duas ou mais pessoas distribuídas em dois ou mais lugares distintos, compartilhando espaço de trabalho, visual e acústico comuns a todos os participantes [Pat98].

Figura 2: Taxonomia dos sistemas de teleconferência

Os sistemas de teleconferência podem ser classificados segundo três aspectos, conforme mostrado na Figura 2. Qualquer sessão de teleconferência ou software pode ser classificada utilizando-se este escopo para os parâmetros, podendo fornecer aos participantes informações sobre aspectos técnicos e humanos muito valiosas. Classificações atuais, como teleconferências tempo-real, não tempo-real, audioconferências, conferências áudio-gráficas, teleconferências em desktop, teleseminários, teleconferências em auditórios, entre outras, podem ser perfeitamente classificadas utilizando-se a taxonomia apresentada na Figura 2.

^

3 Endereçamento Multicast [Kum95]

O conceito de endereçamento multicast para comunicação de grupo na Internet, foi proposto por Steve Deering em sua tese de doutorado na Universidade de Stanford, e mais tarde desenvolvido na XeroxParc. Multicast para Internet foi adotado pela primeira vez no encontro da Internet Engineering Task Force (IETF) celebrado em março de 1992.

Multicast é um modelo de comunicação em que um host emissor envia uma mensagem a um grupo de hosts de destino. Muito embora isso possa ser feito mandando-se diferentes mensagens do tipo unicast (um-para-um), conforme Figura 3, existem várias razões pelas quais a comunicação multicast é desejável.

A primeira vantagem é que o endereçamento multicast diminui a carga de tráfego na rede, já que o transmissor envia somente um pacote da mensagem, como pode ser visto na Figura 4, sendo que o pacote é replicado apenas se necessário, não consumindo largura de banda da rede com pacotes replicados para participantes de uma mesma sub-rede.

Figura 3: Conexões unicast

Figura 4:Conexões multicast

Outra vantagem é a descoberta de recursos, ou seja, existem muitas aplicações em que um host precisa descobrir se certos tipos de serviços estão disponíveis ou não na rede. Para isso ele transmite mensagens multicast para os vários potenciais hosts de destino que podem fornecer este serviço. O escopo dos pacotes multicast pode ser limitado usando o campo time-to-live (TTL) desses pacotes.

Cada vez mais aplicações com suporte a áudio e vídeo vêm usando a comunicação multicast. Receptores, ao invés de usar a conexão ponto-a-ponto entre os hosts do grupo, utilizam o endereçamento multicast para a distribuição dos dados multimídia entre os hosts destino. A flexibilidade para se integrar e se retirar de determinado grupo, fornecida pelo multicast, torna a manipulação dos integrantes do grupo muito fácil.

Para transmissões Multicast, hosts emissores e receptores e a infra-estrutura de rede entre eles devem suportar o protocolo multicast, por exemplo IP MULTICAST, incluindo os roteadores intermediários.

Requerimentos para os emissores e receptores suportarem IP Multicast são:

Já para expandir o tráfego multicast para uma WAN é necessário que todos os roteadores intermediários entre o emissor e o receptor suportem IP Multicast, ou através da utilização de túneis, além dos firewalls reconfigurados para permitir tráfego IP Multicast.

^

4 Protótipos Multicast na RMAV-FLN [Bac00a]

Esta seção apresenta o contexto, a metodologia utilizada e os protótipos disponibilizados durante o primeiro período do projeto RMAV-FLN, no âmbito dos sub-projetos de caráter geral Comunicação Multicast e Teleconferência.

^

4.1 Contexto do Trabalho

Para a realização das atividades foram utilizados os equipamentos e estrutura do projeto RMAV-FLN. Para o melhor entendimento do ambiente utilizado dividiu-se o mesmo em duas partes: os sistemas finais e o suporte de comunicação utilizado.

^

4.1.1 Sistemas Finais

Entende-se por sistema final o conjunto formado pelo host, sistema operacional e software utilizado por determinado protótipo.

Para os protótipos a serem apresentados a seguir utilizou-se um conjunto muito heterogêneo de sistemas finais. A heterogeneidade pode ser vista principalmente na capacidade de processamento da CPU, arquitetura e sistema operacional, conforme Tabela 2. Além destes parâmetros, existem outros cujos efeitos de sua heterogeneidade não se mostraram relevantes, como por exemplo, memória física (32MB a 128MB), capacidade de disco rígido, memória de vídeo (1MB a 8MB), entre outros.

Tabela 2 : Heterogeneidade dos Sistemas Finais

Além dos microcomputadores e estações de trabalho utilizadas com kits multimídia suportando áudio e vídeo, utilizou-se ainda toda infra-estrutura do estúdio de vídeo do Departamento de Jornalismo da Universidade Federal de Santa Catarina.

^

4.1.2 Suporte de Comunicação

A fim de prover comunicação entre os sistemas finais utilizou-se a infra-estrutura física da RMAV-FLN, composta por fibras ópticas, comutadores, roteadores e pares trançados que interligam as instituições consorciadas que, em conjunto com as tecnologias, padrões e protocolos utilizados pelo Grupo de Trabalho em Operação e Gerenciamento (GT-Operação) deu origem ao Backbone ATM da RMAV-FLN. O suporte de comunicação utilizado pode ser visto na Figura 5. Pelo fato da maioria dos softwares utilizados não suportarem ATM nativo utilizou-se serviços sem conexão através de abordagem indireta, ou seja, LAN Emulation.

^

4.2 Ferramentas Avaliadas

A fim de encontrar um conjunto de ferramentas que atendesse as necessidades dos protótipos e ambiente pretendidos, avaliou-se várias ferramentas com suporte ao endereçamento multicast, já que a utilização das vantagens oferecidas por este figura como um dos principais objetivos do trabalho. Nesta primeira etapa deu-se especial atenção às ferramentas com código aberto e implementações gratuitas, possibilitando eventual reutilização do código fonte no desenvolvimento e adaptações para implementações de protótipos futuros, conforme Tabela 3.

^

4.3 Protótipos Disponibilizados

Com os objetivos de avaliar as diversas ferramentas multicast testadas e verificar as vantagens do endereçamento multicast, frente às outras tecnologias utilizadas, de disponibilizar um ambiente que permita a realização de reuniões e teleseminários através da Internet, e de dar suporte aos demais sub-projetos que necessitarem fazer uso do endereçamento multicast, desenvolveu-se alguns protótipos, disponibilizados inicialmente apenas no backbone da RMAV-FLN.

Figura 5: Suporte de comunicação da RMAV-FLN

^

4.3.1 Teleseminário Multicast

Para realizar o teleseminário via Internet utilizou-se o backbone da RMAV-FLN e a estrutura disponibilizada pelo Departamento de Jornalismo da UFSC, conforme Figura 6. As ferramentas utilizadas neste experimento foram o VIC 2.8ucl4, RAT 3.0.35 e Relate 2.1. A versão do RAT utilizada não possui implementada a opção de sincronização do áudio com o vídeo. Para transmitir os seminários utilizou-se um PC Pentium II 450MHz/128MB rodando sistema operacional NT, obtendo-se resultados da ordem de 20 a 30fps, com 16bpp e padrão de apresentação CIF (352 x 288). Para aquisição do vídeo e som utilizou-se uma placa de captura de vídeo, baseada no chipset BT848, e uma placa de som. Como pode ser observado na Figura 6, existe a possibilidade do telespectador interagir com o estúdio, através das ferramentas VIC e RAT. A interatividade nos protótipos TV e Teleseminário é foco das atividades atuais em desenvolvimento.

Tabela 3: Ferramentas avaliadas

^

4.3.1.1 Monitoramento Remoto para as Câmeras

O protótipo apresenta uma forma de controlar remotamente uma câmera através de um browser. O sistema é composto por um applet que é executado no navegador do cliente, um programa servidor e um circuito digital para controle de um motor acoplado à câmera. No desenvolvimento do protótipo, foi utilizada a linguagem Java, que oferece um modelo de programação distribuído, simples de programar e robusto.

A Figura 7 apresenta a arquitetura do sistema que controla a câmera. Primeiramente, o usuário recebe a imagem gerada pela câmera. Esta recepção pode ser feita com o VIC. O usuário, com um navegador, tem acesso aos comandos de controle da câmera disponíveis no applet. Este programa comunica-se com a aplicação servidora enviando os comandos de controle para Velocidade e Posição. A aplicação servidora interpreta estes comandos e gera os sinais para o circuito digital. Aplicações como ensino à distância, teleseminários, debates, entre outras, podem beneficiar-se do controle remoto para câmeras, onde um moderador pode alternar entre a imagem dos diversos participantes, de forma bastante versátil, local ou remotamente, sem a necessidade de diversas câmeras e sistemas de cortes.

Figura 6 : Estrutura do Estúdio de TV

Figura 7: Arquitetura do controle remoto para câmeras

^

4.3.2 TV Multicast

O experimento de TV via Internet foi realizado com o auxílio de um sintonizador de TV a partir de um PC Pentium II 300MHz/128MB. O sinal analógico de vídeo composto é aplicado à entrada de uma placa de captura, baseada no chipset BT848. Utilizando-se o VIC 2.8ucl4 e o RAT 3.0.35, obteve-se resultados da ordem de 20 a 30fps utilizando 16bpp e padrão de apresentação CIF, sintonizando uma estação de TV local.

^

4.3.3 Rádio Multicast

Para disponibilizar a versão multicast das rádios UFSC e UDESC (ou de qualquer outra), utilizou-se um sintonizador de rádio analógico e aplicou-se o sinal de áudio na entrada auxiliar de uma estação de trabalho sparc ultra 1 145MHz/64MB. Através da ferramenta RAT 3.0.35 difundiu-se o áudio através da rede RMAV-FLN, utilizando algoritmo PCM codificando em 64Kbps. Atualmente está-se disponibilizando as rádios multicast com o auxílio de microcomputadores conectados ao backbone ATM alocados nos próprios estúdios das rádios UFSC e UDESC. Espera-se, com isso, disponibilizar em breve protótipos de rádios interativas via Internet.

Os experimentos de Teleseminário, Rádio e TV multicast também estão disponíveis a todos os participantes conectados ao backbone ATM a partir da página do sub-projeto Comunicação Multicast. Nestes casos utilizou-se o mecanismo de código móvel, ou seja, applets para viabilizar a recepção deste experimentos, sem a necessidade de instalação de ferramentas ou plug-ins adicionais, conforme http://www.rmav-fln.ufsc.br/multicast/index.html.

^

4.3.4 Rádio MP3 Multicast

Transmite-se, a partir de um PC Pentium 133MHz/48MB, utilizando o software LiveCaster [Live], uma programação MP3 armazenada em disco, utilizando endereçamento multicast. Com este sistema conseguiu-se transmitir áudio com qualidade até 44.1KHz, 1 canal (mono), 64Kbps. Valores acima destes necessitam de uma CPU mais veloz. Espera-se com este mecanismo e com softwares para automação de rádios auxiliar a transmissão da Radio UFSC multicast. A recepção pode ser feita utilizando softwares com Winamp, Freeamp, Realplayer, etc., bastando suportar streaming de MP3 sobre RTP.

^

4.3.5 Teleconferência Multicast

Este experimento, além de ser um dos mais esperados por todos, mostrou-se também o mais complexo de se implementar e também de se analisar. Com a exigência da transmissão bidirecional das mídias envolvidas o número de variáveis envolvidas aumentou. Com os resultados obtidos durante a utilização de diferentes máquinas neste experimento, pôde-se verificar que, na configuração e tráfego atual do suporte de comunicação, os maiores pontos de congestionamento são os sistemas finais. Utilizando as ferramentas VIC, RAT, WBD, NTE, SDR [UCL99], RELATE [Relate], multikit [Live] e CONFMAN [Confm] obteve-se grandes variações das taxas de frames por segundo e perda - como pode ser visto na Figura 8 - dependendo de uma série de fatores a serem vistos a seguir.

^

5 Ensaios e Medidas Realizadas

À medida que se disponibilizou os protótipos apresentados também se realizou vários ensaios a fim de melhorar a qualidade, o desempenho e otimizar a utilização dos recursos dos sistemas finais e recursos da rede. Os primeiros ensaios realizados foram basicamente qualitativos. A partir destes identificou-se que as causas do baixo desempenho de alguns protótipos que utilizam transmissão de vídeo estavam, muitas vezes, localizados nas extremidades do processo ilustrado na Figura 1, ou seja, nos sistemas finais. O parâmetro dos sistemas finais analisado inicialmente, e que se mostrou determinante nos protótipos que utilizam vídeo, foi a capacidade de processamento da CPU do host. Observou-se que os processos de codificação e decodificação, realizados na maioria das vezes por software, demandam alto percentual de ocupação de CPU. Este fato, aliado ao de que os sistemas finais formam um conjunto heterogêneo (principalmente no que diz respeito ao clock da CPU), definiu-se como sendo o próximo ensaio o de Otimização da Utilização dos Recursos dos Sistemas Finais. Em seguida, diante das limitações do ambiente, realizou-se uma série de ensaios a fim de identificar pontos de congestionamento em segmentos ou elementos da rede, ou seja, Avaliação do Suporte de Comunicação. Paralelamente a estas medidas realizaram-se medidas na camada de aplicação visando Melhoria da Qualidade nos Protótipos.

^

5.1 Otimização da Utilização dos Recursos

Como já foi apresentado anteriormente, dentre as ferramentas testadas e avaliadas, decidiu-se pelo uso da ferramenta VIC para a difusão de vídeo através do backbone. A ferramenta VIC suporta vários algoritmos de compressão para o vídeo, entre eles estão NV, NVDCT, MJPEG, H.261, H.263, H.263+, cellb, entre outros, dependendo da implementação utilizada.

Por outro lado, diante de um ambiente heterogêneo, como o apresentado anteriormente, tornou-se necessária a escolha de um algoritmo de compressão de vídeo que levasse em conta as limitações das CPUs de muitos sistemas finais que seriam utilizados nos protótipos apresentados, objetivo deste ensaio.

Figura 8: Exemplo de uma videoconferência na RMAV-FLN

Neste ensaio alguns algoritmos analisados contemplarem compressões espaciais e temporais, utilizou-se um vídeo pré-gravado composto por dois períodos distintos, um com muita e outro com pouca movimentação, cada um com 15 minutos de duração. A quantidade e velocidade de mudança das imagens tornam-se um aspecto muito importante, considerando as métricas CPU Utilizada e Largura de Banda Ocupada quando se utiliza tais algoritmos de compressão.

Inicialmente transmitiu-se este vídeo pré-gravado a partir de um microcomputador Pentium III 500MHz e capturou-se o mesmo vídeo a partir de microcomputadores Pentium 166MHz e Pentium II 450MHz. O segundo passo consistiu em repetir o ensaio, porém transmitindo o vídeo a partir de um microcomputador Pentium 166MHz. Fixou-se ainda o sistema operacional utilizado: Windows NT.

Espera-se que com esta metodologia, e considerando as métricas Utilização da CPU, Largura de banda, Perda e Memória utilizada durante a transmissão, possa se chegar a conclusões sobre quais algoritmos são mais indicados para o ambiente disponível.

No VIC existe a possibilidade de ajuste da qualidade de compressão. Para o caso do H.261 utilizou-se grau de compressão 10, numa faixa que vai de 5 a 95, sendo que quanto maior o grau de compressão pior é a qualidade do vídeo transmitido. Já para o caso do MJPEG realizou-se a avaliação considerando dois casos, 30 e 95, sendo que, para o MJPEG, quanto maior o número escolhido maior é a qualidade do vídeo transmitido, ou seja, menor é a compressão realizada. A qualidade do vídeo apresentado é aproximadamente equivalente para os casos do H.261 (10) e MJPEG (30).

A Figura 9 apresenta uma comparação do desempenho de dois sistemas finais realizando a transmissão de um mesmo vídeo pré-gravado, sem realizar a apresentação ou reprodução de nenhum vídeo na tela do monitor. Observando os gráficos da Figura 9 pode-se concluir que, para a transmissão de um vídeo com muita movimentação a partir de um microcomputador Pentium 166MHz, considerado o sistema final mínimo, a taxa de frames por segundo (fps) é igualmente baixa, entre 6fps e 9fps, para todos os algoritmos de compressão analisados. Já para transmissões com pouca movimentação, ainda na Figura 9, observa-se taxas de transmissão próximas de 20 fps para os algoritmos H.261, NV e NVDCT. Para este caso observa-se ainda, considerando a métrica Ocupação da CPU, que a limitação realmente se encontra no sistema final.

Figura 9: Transmissão de vídeo a partir de Pentium 166MHz e Pentium 500MHz

Para a transmissão a partir de um Pentium III 500MHz os algoritmos H.261 e NV também apresentaram um desempenho melhor que os demais.

Com as conclusões da Figura 9, ou seja, que os melhores algoritmos para transmissão de vídeo utilizando o VIC em sistemas finais conforme apresentados anteriormente são o H.261, NV e NVDCT, pode-se passar a analisar a Figura 10, que apresenta uma rápida comparação da recepção do vídeo, transmitido a partir de um Pentium 500MHz, em sistemas finais compostos por Pentium 166MHz e 450MHz.

Restringindo a análise aos algoritmos selecionados, ou seja, H.261, NV e NVDCT, observa-se na Figura 10 que a melhor opção para o sistema final mínimo apresentar vídeo com muita movimentação é a compressão H.261, que alcança taxas da ordem de 22fps, apresentando em tamanho CIF. Nesse caso também é possível observar que o ponto de congestionamento realmente é o sistema final, considerando a métrica ocupação da CPU. O Sistema Final composto por Pentium III 500MHz também apresenta bom desempenho para tais configurações das aplicações.

Com este ensaio conclui-se que, considerando as limitações dos sistemas finais utilizados, o algoritmo de compressão de vídeo mais indicado para os protótipos é o ITU-T H.261.

^

5.2 Avaliação do Suporte de Comunicação

A vantagem do algoritmo H.261 sobre os demais, considerando o menor custo computacional para codificação e decodificação do vídeo demanda maior largura de banda para transmitir o mesmo vídeo.Com o objetivo de verificar a existência de pontos de congestionamento na estrutura de comunicação utilizada realizou-se uma série de ensaios, durante os quais foram feitas medidas nas camadas de aplicação e de rede durante transmissões de áudio e vídeo multicast através do backbone ATM da RMAV-FLN.

Para coletar dados na camada de aplicação utilizou-se as próprias ferramentas destinadas à comunicação de áudio e vídeo: VIC e RAT. Já para as coletas na camada de rede utilizou-se agentes SNMP distribuídos nos sistemas finais envolvidos nos experimentos e também nos elementos de redes, como comutadores e BUS. As métricas consideradas para este ensaio foram vazão de entrada de dados, vazão de saída de dados, taxa de descarte e taxa de erros.

Figura 10: Recepção de vídeo transmitido a partir de um Pentium 500MHz

Comparando as taxas de vazão de entrada e saída, pode-se concluir que o suporte de comunicação não oferece pontos de congestionamento para a quantidade de dados trafegada em sessões de teleconferência [Bac00a]. Obviamente, à medida que o tráfego do backbone ATM sofrer aumento por conta de novas aplicações, passa-se a necessitar de uma análise mais criteriosa do suporte de comunicação.

^

5.3 Melhoria da Qualidade nos Protótipos

Partindo-se das conclusões dos ensaios anteriores e com o intuito de melhorar a qualidade dos protótipos descritos na seção 4.3 realizou-se uma série de ensaios e análises quantitativas e qualitativas dos protótipos. A Tabela 4 apresenta uma abstração dos sistemas finais utilizados para os ensaios e medições. O objetivo desta abstração é agrupar os diferentes sistemas finais levando em conta basicamente a capacidade de processamento, a fim de diminuir a complexidade da análise dos dados coletados. Baseia-se no fato de que CPUs diferentes, porém consideradas de uma mesma classe, fornecem resultados muito próximos para as métricas consideradas. O sistema operacional utilizado foi fixado em Win NT 4.0 devido a predominância deste.

Tabela 4: Classificação dos sistemas finais

^

5.3.1 TV Multicast

Este experimento objetiva fornecer uma análise quantitativa do experimento TV multicast e também uma comparação do endereçamento multicast frente ao endereçamento unicast empregado pelos softwares desenvolvidos pela REAL Networks, sendo alguns resultados apresentados a seguir. Embora as soluções da Real Networks suportarem endereçamento multicast, os softwares Real Server e Real Producer utilizados foram versões gratuitas, o que implica em algumas restrições durante sua utilização, com endereçamento unicast.

Experiências anteriores mostraram a complexidade de tais avaliações devida principalmente ao grande número de variáveis envolvidas. No presente experimento fixou-se vários parâmetros, conforme Tabela 5.

Tabela 5: Parâmetros fixados durante os ensaios

Durante o experimento foram consideradas as seguintes métricas: Percentual de ocupação da CPU; Largura de banda utilizada; Taxa de frames apresentados por segundo; Percentual de perda do vídeo.

Os gráficos da Figura 11 apresentam os resultados do experimento utilizando VIC e RAT, durante duas etapas distintas do experimento. Para o primeiro gráfico, as métricas Largura de banda, Frames por segundo e perda mostram-se idênticas para as três classes de sistemas finais considerados. A única diferença observada é a CPU utilizada, o que já era esperado. Conclui-se que este ensaio apresenta a configuração próxima do limite aceitável para a recepção de uma videoconferência multicast, com apenas um transmissor de cada vez, sem perdas para sistemas enquadrados na classe C. No segundo gráfico as três classes de sistemas finais para o pior caso, ou seja, onde a quantidade de movimentação do vídeo é alta. Observa-se que as classes B e C tiveram suas CPUs completamente ocupadas pela aplicação, o que indica a provável ocorrência de perdas na recepção. Este fato é comprovado quando se observa a métrica PERDA. As classes C e B apresentam perdas de 20% e 10%, respectivamente. Com esses dados fica evidente a possibilidade da existência de perda em sistemas destas categorias, pelo menos em alguns momentos com muita movimentação da imagem, durante transmissões multicast utilizando configurações supracitadas. Embora não está presente no gráfico, para a classe C, exibindo a janela em tamanho QCIF (144 x 176) a perda cai a zero.

Figura 11: TV Multicast com VIC/RAT

Em relação ao transmissor enquadrado na classe A, pode-se concluir que este não é suficiente para transmitir o vídeo utilizado para este ensaio, já que a taxa máxima especificada foi 30fps e o transmissor, por sua vez, transmitiu apenas 25fps.

Realizou-se o mesmo ensaio utilizando o REAL PRODUCER G2, REAL SERVER G2 e REAL PLAYER 7. Neste ensaio ficou evidente a replicação de pacotes para cada cliente que passa a ser servido pelo REAL SERVER e também o baixo desempenho do conjunto servidor e codificador que limitaram a métrica FPS em torno de 7fps para o vídeo com muita movimentação. Outro fato observado foi o atraso entre cliente e servidor, que foi em torno de dez segundos. As principais vantagens da tecnologia empregada pelos softwares da REAL NETWORKS foram a baixa largura de banda utilizada por transmissão de vídeo e o sincronismo entre áudio e vídeo. Já as ferramentas do MBone apresentaram baixíssimo atraso, permitindo aplicações interativas, melhor qualidade do vídeo, melhor desempenho na recepção do vídeo e melhor utilização da largura de banda disponível na rede, independente do número de participantes.

Repetindo o ensaio com um transmissor da classe C ficou evidente a limitação do transmissor que, transmitiu o vídeo com muita movimentação com codificação em H.261 em tamanho normal, à taxa de 8fps. Esta taxa pode ser aumentada para aproximadamente 30fps alterando-se o tamanho da transmissão para small. Com isso também reduz a largura de banda utilizada para em torno de 500kbps e a ocupação da CPU fica em torno de 95%, mostrando ser realmente o sistema mínimo para transmissões de vídeo com tais configurações.

^

5.3.2 Videoconferência em Desktop

A segunda categoria de experimentos realizados diz respeito a reuniões de pequenos grupos através do backbone ATM. O objetivo deste ensaio é apresentar o aumento da CPU utilizada quando se torna necessário efetuar os processos de codificação e decodificação das mídias simultaneamente, em grupos de reuniões que interagem de forma estreita. Realizou-se este ensaio com apenas uma ou duas janelas de vídeo destacadas em tamanhos CIF ou QCIF. Para se ter uma idéia inicial pode-se observar os percentuais de perda da Figura 12 e da Figura 8. A Figura 12 mostra uma reunião com dois participantes em sistemas finais classe A Pode-se observar que transmitindo em tamanho normal e apresentando as janelas em tamanho CIF, dependendo da quantidade de movimentação da imagem, ocorrerão perdas consideráveis.

Transmitiu-se o mesmo vídeo pré-gravado do ensaio anterior a partir de dois sistemas finais classe A e apresentou-se uma janela do vídeo em tamanho CIF em cada host. Obteve-se taxas de 5fps e 30fps, CPU de 100% e 30% e perda de 80% e 0%, para o período de muita e pouca movimentação, respectivamente. O desempenho cai ainda mais em sistemas classe C. Também ficou evidente que o processo de codificação e envio das mídias tem maior prioridade sobre o processo de decodificação e apresentação das mídias recebidas visto que, mesmo com todas as perdas na recepção, a transmissão ficou em torno de 26fps.

Repetiu-se o mesmo ensaio porém com duas janelas CIF destacadas sendo apresentadas simultaneamente à transmissão do vídeo pré-gravado do sistema local classe A. Nesse caso as métricas fps, perda e ocupação da CPU tiveram um desempenho ainda pior. Por outro lado, alterando o tamanho da janela de vídeo transmitido para small e a apresentação das janelas para QCIF observou-se taxa de recepção 30fps, sem perda e ocupação da CPU em 50%. A diminuição das perdas com estas alterações pode ser observada comparando a Figura 8 com a Figura 13.

^

6 Comentários

No atual estado dos protótipos e das atividades acredita-se que as ferramentas até aqui empregadas, embora necessitem de melhorias, possuam vantagens e grande potencial para aplicações do tipo difusão de mídias para grandes grupos (teleseminário, rádio e TV interativas e suporte ao ensino e treinamento online à distância) e para reuniões de pequenos grupos que interajam de forma mais estreita (CSCW e teleconferências). Para tais aplicações pode-se sugerir os seguintes softwares: SDR, MULTIKIT, CONFMAN, RELATE, VIC, RAT, NTE, WBD e LiveCaster;

É indiscutível a necessidade de utilização de políticas de acesso e de coordenação para a garantia da palavra nas sessões multicast, atualmente não implementadas. Testes realizados mostraram que a falta de um moderador nas sessões acarreta numa perda muito grande de tempo em tais sessões. Outros fatores como falta de conhecimento das ferramentas, falta de equipamento e ambiente adequados também prejudicam as sessões.

Figura 12: Exemplo de reunião com dois participantes

Figura 13: Exemplo de teleconferência na RMAV-FLN

A evolução desigual do meio de comunicação e dos sistemas finais, como o presente ambiente, torna necessárias algumas medidas para otimizar a utilização dos recursos e melhorar o desempenho destes protótipos.

Para reuniões de pequenos grupos é interessante que a imagem de todos os participantes apareça no monitor. Por outro lado, essa prática demanda mais recursos dos sistemas finais. Para minimizar as perdas nestas classes de aplicações pode-se optar por transmitir o vídeo em tamanho small e apresentar as janelas de todos os participantes em tamanho QCIF, como faz o RELATE. Eventuais recepções sem interesse também podem ser desabilitadas através da opção MUTE, o que também ira economizar recursos. Para sistemas finais onde tais medidas não refletem em níveis mínimos de satisfação dos participantes da sessão de teleconferência pode-se obter melhoras na qualidade alterando a apresentação dos vídeos para P&B ou diminuindo a qualidade do vídeo transmitido. Outra opção é, de comum acordo, todos os participantes da sessão limitarem suas taxas de transmissão me valores menores, por exemplo 15fps. Esta prática mostrou-se interessante pois, pela análise de resultados, pôde-se concluir que o descarte de pacotes que chegam após seu deadline também demanda CPU, piorando ainda mais o desempenho da aplicação. Também devem ser evitados ambientes muito movimentados, já que o movimento resulta em maior largura de banda e maior percentual de CPU utilizado.

Pelo fato do áudio ser uma mídia de fundamental importância em sistemas de teleconferência, esta exige uma atenção especial A fim de se obter áudio com o máximo de qualidade também devem ser tomadas algumas medidas preventivas: aos processos envolvidos devem ser atribuídas prioridades de tempo-real no sistema operacional; evitar a opção de supressão de silêncio que eventualmente pode cortar o início e o fim das frases, dificultando o entendimento; utilização de equipamento e ambiente adequado, como microfone direcionado e ambiente silencioso. Outro fator importante é o conhecimento da ferramenta utilizada e o prévio ajuste dos níveis do microfone e fone de ouvido. Não se deve utilizar microfone e caixas de som, a fim de evitar o retorno do som das caixas pelo microfone. Também, durante longos períodos de silêncio local deve-se manter o microfone desligado.

^

7 Conclusões e Perspectivas

Ao fim desta etapa disponibilizou-se um conjunto de protótipos de aplicações interativas [Bac99] na rede metropolitana ATM que fazem uso do endereçamento multicast, além de se ter adquirido noções sobre operação, gerência e aplicações da rede ATM, multimídia, serviços diferenciados e integrados, qualidade de serviço, multimídia, etc. visando futuros desafios nestas áreas.

Espera-se nas próximas etapas refinar os estudos e protótipos já em funcionamento. Os protótipos de TV e Rádio multicast interativos, com participação em tempo-real dos telespectadores e controle de palavra nas sessões, através de mecanismos de floor control e com reserva de recursos estão entre as pretensões futuras.

Com relação à inclusão de um moderador nas sessões de videoconferência, ensino e treinamento a distância via Internet e rádio e TV multicast, atualmente está se empenhado na utilização de ferramentas já implementadas, como o QB, desenvolvido em Berkeley [Mal97], e MinT desenvolvido no GMD Fokus [GMD].

Existe também necessidade de se implementar tais protótipos levando em conta a reserva de recursos da rede para cada aplicação utilizada separadamente, visando atender requisitos de QoS (Quality of Service) [Jain], isto é, qualidade de serviço. Espera-se que através da utilização do MPOA (Multi-Protocol over ATM) estes objetivos possam ser alcançados. Ainda figura como perspectiva protótipos que façam uso dos algoritmos de compressão MPEG melhorando bastante a qualidade do vídeo transmitido. Alguns softwares comerciais com tal suporte já estão em fase de avaliação e testes [Cisco].

^

8 Referências

[Bac00a] F. Bachmann, S. Sari, I. L. Martins; Avaliação da TV Multicast da RMAV-FLN; NURCAD/UFSC; Fpolis, 2000.

[Bac00b] F. Bachmann, I. L. Martins; Teleconferência e Algoritmos de Compressão de Vídeo; NURCAD/UFSC; Fpolis,2000.

[Bac99] F. Bachmann, I. L. Martins; Testes e Protótipos Multicast da RMAV-FLN; NURCAD/UFSC; Fpolis, 1999.

[Banik] M. Banikazemi; "IP Multicasting: Concepts, Algoritms and Protocols", http://www.ohio-state.edu/~jain

[Bor99] D.M. Bortoluzzi; Interconexão Multicast entre MBone e ATM. Trabalho Individual. INE/UFSC 1999.

[Can95] S. McCanne and V. Jacobson; VIC: A Flexible Framework for Packet Video. ACM Multimedia 1995.

[Cisco] Cisco Systems Multicast Page, http://www.cisco.com/warp/public/614/17.html

[Confm] Universidade de Hannover; Confman;http://www.rvs.uni-hannover.de/products/confman/v2.0

[Don99] Hans-Peter Dommel and J.J. Garcia-Luna-Aceves; Group Coordination Support for Synchronous Internet Collaboration; IEEE Internet Computing, March/April 1999.

[Flu95] F. Fluckinger; Understanding Networked Multimedia: Applications and Technology; Prentice Hall, 1995.

[GMD] GMD-FOKUS; Multimedia Internet Terminal; http://www.fokus.gmd.de/research/cc/glone/products/mint

[Gon98] M. Goncalves, K. Niles, "Ip Multicasting: Concepts and Applications," Networking Series, 1998

[Hun99] J. Hunter, V.Witana, M.Antoniades; A Review of Video Streaming over Internet; DSTC SuperNOVA; AU, 1999

[INRIA] INRIA; Rendez-Vouz, the next generation videoconferencing tool; http://www.inria.fr/rodeo

[Jain] IP Multicasting References; http://www.cis.ohio-state.edu/~jain/refs/ipm_refs.htm

[Jonhs] V. Johnson and M. Johnson; "How IP Multicast Works", IPMI - http://www.ipmulticast.com

[Kum95] V. Kumar; "MBone: Interactive Multimedia on The Internet", NewRiders Publishing, 1995.

[LBNL] Lawrence Berkeley National Laboratory; LBNL's Network Research Group; http://www-nrg.ee.lbl.gov

[Liu97] Chunlei Liu, "Multimedia Over IP: RSVP, RTP, RTCP, RTSP", Handbook of Communication Technologies: The Florida, 1999,. http://www.cis.ohio-state.edu/~jain/cis788-97/ip_multimedia/index.htm

[Live] Technology, services, & standards for tomorrow's Internet; http://live.com

[Lou97] C. Lourenço da Silva; Sistema de Teleconferência. Mestrado da PUC-RIO; 1998, RJ. Brasil.

[Mac98] M. Macedonia and D.Brutzman; "MBone Provides Audio and Video Across the Internet",

[Mal97] R. Malpani and L.A. Rowe. Floor Control for Large-Scale MBone Seminars. ACM. Multimedia., November 1997.

[Mbone] MBONE information web, http://www.mbone.com

[Mel97] C.Melchiors, L. M. R.Tarouco; Sistemas Interpessoais de Videoconferência. T. I. N. 596 CPGCC-UFRGS, 1997

[Merit] Mbone Softwares Archives; http://nic.merit.edu/%7Embone/index/titles.html

[NCSA] NCSA; X Web Teach and CCI; http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/x-web-teach.html

[Ott98] Jörg Ott, Colin Perkins; A message Bus For Conferencing Systems; UCL/AC; March 1998

[Par97] Parviainen, R.; Multicast Interactive Radio; LUTH-CDT; http://www.cdt.luth.se/rolle/mIR

[Pat98] A. S. Patrick; The Human Factors of Mbone Videoconferences; Communications Research Centre; March 1998

[Qui98] B. Quinn; IP Multicast Application: Challenges and Solutions, Internet Draft 1998. ftp://www.draft-quinn-multicast-apps-00.txt

[Relate] University of Exeter and University College London; Remote Language Teaching; http://www.ex.ac.uk/pallas/relate

[Sho96] Eve M. Schooler. Conferencing and Collaborative Computing. Multimedia Systems, 4(5):210-225, 1996

[Swa97] Andrew Swan and L.A. Rowe. An Internet MBone Broadcast Management System. Master's Thesis, June 1997.

[UCL99] UCL Mbone Tools Page; http://www-mice.cs.ucl.ac.uk/multimedia/software

[Won98] T. H. Wong, K. Mayer-Patel, D. Simpson and L.A. Rowe. A Software-Only Video Production Switcher for the Internet MBone. SPIE Multimedia Computing and Networking, January 1998.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004