Transmissão Multimídia em redes de computadores: um relato para redes locais e Internet2

Valter Roesler <roesler@exatas.unisinos.br>

Universidade do Vale do Rio dos Sinos (UNISINOS)
Pesquisa em Redes de Alta Velocidade (PRAV)
Rede Metropolitana da Grande Porto Alegre (MetroPoa) - RMAV-RS

Resumo
Abstract
1. Introdução
2. Transmissão ao vivo da Semana da Qualidade na Unisinos
2.1 VI Semana da Qualidade - Problemas encontrados
2.1.1 Problemas gerais
2.1.2 Problemas nos centros de ensino
3. Videoconferência na RMAV-RS
4. Transmissão da TV Unisinos na RMAV-RS
5. Conclusão
6. Sites Relacionados
Notas

Resumo

O presente artigo relata alguns projetos feitos em transmissão de multimídia na Unisinos (Universidade do Vale do Rio dos Sinos) e na RMAV-RS (Rede Metropolitana de Alta Velocidade do Rio Grande do Sul) (1)

A rede interna da Unisinos é baseada em Ethernet/Fast-Ethernet/ATM 155Mbps, e o backbone da RMAV-RS em ATM 155Mbps. No nível 3, procurou-se utilizar multicast, devido à sua vantagem em consumo de banda. Os projetos analisados são os seguintes:

Transmissão de palestras ao vivo na Semana da Qualidade com interatividade;
Videoconferência na RMAV-RS ;
Transmissão multimídia da TV Unisinos na RMAV-RS.

Palavras-chave: multimídia, ensino a distância, transmissão de áudio e vídeo, tempo real.

Abstract

This article reports some projects done on multimedia transmission at the Jesuitic University in Southern Brazil (Unisinos) and at the Metropolitan Network of Porto Alegre (Metropoa), also known as Rio Grande do Sul´s High Speed Metropolitan Network (RMAV-RS).

Unisinos´s intranet is based on Ethernet/Fast-Ethernet/ATM 155Mbps, and RMAV-RS´s backbone is based on ATM 155Mbps. Multicast was used at layer 3, due to its better band usage. The main results analyzed in this paper are:

Live transmissions of speeches at "Semana da Qualidade", with interactivity;
Videoconference on RMAV-RS;
Multimedia transmission of the Unisinos´s TV station.

Keywords: multimedia, distance learning, audio and video transmission, real time.

1. Introdução

Diversas experiências em transmissão de áudio e vídeo foram realizadas no consórcio RMAV-RS, devido à importância dessa área atualmente nas seguintes aplicações:

Ensino a distância: tendência mundial e interesse de vários consorciados no RS, principalmente as Universidades (Unisinos, UFRGS e PUC), o Estado (Procergs), o Município (Procempa) e a companhia de comunicação de dados (CRT);
Transmissão unidirecional de áudio e vídeo ao vivo: utilizado para transmissão de shows ao vivo, palestras, TV, rádio, monitoramento remoto e assim por diante;
Videoconferência: utilizado para efetuar reuniões ou encontros a distância. Sua principal diferença em relação ao item anterior é que necessita interatividade, demandando uma latência baixa na rede;
Vídeo sob demanda: importante para ensino a distância e em geral, quando um usuário deseja assistir algum evento que já aconteceu e encontra-se gravado num servidor de vídeo, como por exemplo shows, palestras, operações, documentários e outros;
Telemedicina: interesse das entidades que possuem hospital, como a UFRGS, a PUC e o Município (Procempa).

O Metropoa - Rede Metropolitana da Grande Porto Alegre (2) é o nome dado ao RMAV-RS, que é uma rede de alta velocidade (155 Mbps) interligando os seguintes participantes: CRT (Companhia Riograndense de Telecomunicações), Procempa (Companhia de Processamento de Dados do Município de Porto Alegre), Procergs (Companhia de Processamento de Dados do Estado do RS), PUC-RS (Pontifícia Universidade Católica do RS), UFRGS (Universidade Federal do RS) e Unisinos (Universidade do Vale do Rio dos Sinos). A figura 7 ilustra a topologia da rede.

Este artigo procura relatar com mais detalhes o que foi efetuado na Unisinos e na RMAV-RS para implementar algumas aplicações acima, especificamente na transmissão unidirecional de áudio e vídeo ao vivo e videoconferência. Os testes foram efetuados por toda a equipe (3), cujos nomes estão na página principal da Unisinos no Metropoa (4).

Inicialmente será descrita a solução para transmissão ao vivo de shows e palestras (com interatividade via chat e videoconferência). Em seguida, será analisado um teste de videoconferência na rede metropolitana e, finalmente, a transmissão ao vivo do sinal da TV Unisinos para a rede interna e metropolitana. As soluções se basearam fortemente em multicast, devido à sua economia em termos de largura de banda.

2. Transmissão ao vivo da Semana da Qualidade na Unisinos

Durante a Semana da Qualidade, realizada no campus da Unisinos no mês de outubro de 1999, foram instaladas máquinas para recepção e transmissão das palestras que estariam sendo apresentadas por convidados da Universidade. Dentro de algumas subredes foram instalados túneis multicast, e qualquer pessoa nessas subredes podia assistir as palestras de seu PC (com interatividade ao palestrante via web). Além disso, tinha um auditório no qual a interatividade era por videoconferência.

Esse projeto foi realizado dentro da Unisinos, mas os resultados e as ferramentas se encaixam perfeitamente na rede metropolitana, podendo-se expandir a abrangência do sistema facilmente. Um sistema muito parecido é utilizado hoje em dia para transmitir o sinal da TV Unisinos para a rede metropolitana (Internet2) e rede interna. O Laboratório de Pesquisa em Redes de Alta Velocidade (PRAV) e a Produtora da TV Unisinos foram as duas equipes encarregadas da criação, supervisão e manutenção desse sistema, ilustrado na figura 1.

Figura 1: Topologia da Transmissão de Vídeo - Semana da Qualidade

O sistema era composto dos seguintes itens e recursos:

Câmeras analógicas (controladas pela equipe da Produtora da TV Unisinos) que filmavam as palestras;
Antenas de microondas que transmitiam o sinal das câmeras da Produtora da TV Unisinos para o auditório central e o PRAV;
Uma estação multimídia Pentium III 500MHz rodando o encoder do Windows Technologies localizada no PRAV, que recebia via antena de microondas o sinal da palestra e o codificava em arquivos ASF, repassando-o para o servidor;
Um servidor Pentium 233MHz com Windows NT, localizado no PRAV, destinado a transmitir o sinal em multicast, tornando-o acessível para qualquer estação cliente dentro da rede multicast criada na Universidade. Foram disponibilizadas até duas conexões unicast, caso a estação remota não estivesse servida com túneis multicast;
Máquinas Pentium 100MHz e Pentium 233MHz rodando sistema operacional FreeBSD, responsáveis pela formação de túneis multicast (serviço de mrouter), a fim de enviar o sinal para diversas subredes da Universidade;
Estações de trabalho que acessavam o conteúdo de multimídia transmitido na rede em multicast a partir da página do PRAV;
Uma câmera analógica responsável por filmar perguntas e/ou comentários realizados por uma platéia remota (auditório central da Unisinos), ligada em uma máquina Pentium II 400MHz com placa de captura de vídeo (BT848), a qual transmitia as perguntas através de videoconferência para o auditório Pe. Werner, onde se encontrava o palestrante (software VIC e RAT);
Uma máquina multimídia Pentium II 400MHz (colocada no auditório Pe. Werner) que recebia o sinal da máquina do auditório central e o repassava ao sistema analógico, a fim de reproduzir as perguntas em um telão.

O auditório Pe. Werner foi o local destinado às palestras realizadas na Semana da Qualidade da Unisinos. Devido à grande procura pelos estudantes e funcionários da Universidade, foi alocado outro auditório, onde o restante da platéia assistia às palestras remotamente.

Foram escolhidas algumas subredes para a transmissão multicast, como por exemplo PRAV, Pascal, Turing e Helios. Cada subrede possui aproximadamente 80 máquinas. As linhas em vermelho da figura 1 demonstram a transmissão de vídeo que ocorria durante a Semana da Qualidade. Já as ligações em verde ilustram a videoconferência, utilizada para que as pessoas localizadas no auditório central fizessem perguntas ao vivo. Finalmente, as linhas em azul pontilhado representam conexões via chat que existiam entre os telespectadores da rede e o palestrante.

O atraso médio observado entre a transmissão do vídeo e sua reprodução nos computadores cliente foi de aproximadamente 18 segundos, o que é aceitável para uma "transmissão de vídeo unidirecional". Na videoconferência, o atraso ficou em torno de 500 ms a 1 s, o que se julgou aceitável para o objetivo proposto, mas o ideal era manter abaixo de 100ms.

A qualidade da transmissão foi considerada satisfatória, com som MP3 codificado em 32KHz de taxa de amostragem, vídeo a 30 quadros por segundo na resolução de 320x240 pixels, podendo ser visto em tela cheia com interpolação para suavizar a imagem. A largura de banda utilizada ficou em torno de 750Kbps e o protocolo de compressão utilizado foi o MPEG-4 v2. Como a rede da Unisinos tem no mínimo 10Mbps no desktop, o impacto é absorvido bem. A seguir serão mostradas algumas imagens obtidas da transmissão.

A figura 2 mostra um exemplo de transmissão da palestra do Sr Carlos Eduardo Hilsdorf (5), sendo assistida confortavelmente por uma pessoa no seu micro pessoal, no próprio local de trabalho.

Figura 2: palestra sendo assistida individualmente

A figura 3 mostra um exemplo da interface com o usuário, onde pode-se ver que o acesso era via web. A figura 4 mostra com mais detalhes a tela de interatividade com o palestrante (que está na parte inferior da interface via web), onde as pessoas que estavam assistindo no computador podiam fazer perguntas a um mediador no auditório Pe. Werner.

Figura 3: Exemplo do acesso via web - interface com o usuário

Figura 4: tela de interatividade via chat com o palestrante

A tela de interatividade mostrada na figura 4 servia apenas para quem estava assistindo no computador. As pessoas localizadas no auditório central podiam fazer perguntas em tempo real ao palestrante (auditório Pe Werner) através de videoconferência. O software utilizado foi o VIC, e conseguiu-se uma ótima qualidade de transmissão. As máquinas utilizadas na videoconferência foram Pentium II 400MHz e a velocidade configurada no VIC foi de 3Mbps, protocolo de vídeo H.261 e áudio mono com taxa de amostragem de 8KHz. No primeiro dia, foram utilizadas máquinas Pentium 233MHz, mas elas mostraram-se lentas para codificar e decodificar as imagens, transmitindo a 3Mbps.

Durante a Semana da Qualidade, ocorreu a monitoração do desempenho das transmissões a fim de que se conhecesse o impacto na rede e a qualidade do serviço prestado. Esses relatórios foram gerados pela própria aplicação VIC, e gravados em alguns arquivos do tipo "log", os quais apresentavam as seguintes informações:

Endereço origem da transmissão;
Unidade de tempo gerada pela própria aplicação, que compreende a representação do relógio em um número inteiro;
O número de quadros por segundo transmitidos;
A largura de banda utilizada (expressa em bits por segundo).

Nas figuras 5 e 6 são ilustrados dois gráficos com dados estatísticos colhidos nas amostras, referentes às máquinas transmissora (Piolho) e receptora (Vídeo).

Figura 5 e Figura6:: largura de banda e taxa de quadros por segundo

O gráfico da figura 5 faz uma comparação entre as larguras de banda registradas em ambas as máquinas - transmissora e receptora. A evolução dos números é bastante próxima, apresentando pequenas diferenças em função de variações decorrentes da própria rede num determinado momento da transmissão.

O segundo gráfico (figura 6), por sua vez, ilustra uma comparação entre a taxa de quadros por segundo transmitida pela máquina "Piolho" no intervalo de tempo levantado na amostra, com a taxa de quadros por segundo recebida pela máquina "Vídeo" no mesmo intervalo de tempo. Pode-se notar que houveram, tal como no caso da largura de banda, pequenas variações, causadas por perdas de pacotes durante a transmissão. Essa perda de pacotes pode ser atribuída a duas hipóteses:

Carência no poder de processamento da máquina receptora. Com a chegada de uma carga muito pesada de pacotes, a máquina Vídeo se via obrigada a descartar alguns pacotes devido à falta de velocidade de processamento e, por conseqüência, dificuldade de interpretação e decodificação de todo o tráfego recebido.
Perda de pacotes na rede, devido ao aumento do tráfego no backbone da Universidade. A transmissão multimídia na rede funciona por UDP, que tem uma transmissão não confiável, e pacotes perdidos não são recuperados.

Não foi medido o número de usuários que estavam assistindo à transmissão nas estações cliente (com o Windows Media Player), pois o tráfego estava ocorrendo em multicast. Futuramente, pretende-se obter tal informação através do número de acessos por IPs diferentes ao arquivo ".nsc", que informa os dados da transmissão e o grupo multicast que o cliente deve se integrar. Teve-se, contudo, a possibilidade de observar que a transmissão que chegava até os clientes Media Player apresentava áudio e vídeo de boa qualidade, salvo em raros momentos do evento, quando ocorreram quedas de desempenho.

2.1 VI Semana da Qualidade - Problemas encontrados

O objetivo desse item é relatar alguns problemas encontrados na transmissão de vídeo da VI Semana da Qualidade, a fim de procurar evitar que os mesmos se repitam no futuro, bem como alertar outras pessoas que pretendem disponibilizar um sistema semelhante para que se previnam contra esses casos.

2.1.1 Problemas gerais

Máquinas com pouco poder de processamento para decodificar sinal da videoconferência: efetuou-se a videoconferência no primeiro dia com máquinas Pentium 233MHz MMX com 32MRAM, e não se mostraram suficientes para codificar/decodificar o sinal de áudio e vídeo, gerando a perda de frames. No segundo dia passou-se a usar Pentium II 400MHz com 64MRAM, e as máquinas se mostraram suficientes, transmitindo sem problemas 3Mbps e 30fps.
Dificuldade de instalação de plug-in: máquinas de laboratório protegidas. Na Unisinos as máquinas do laboratório estavam com protect, impedindo a instalação da nova versão do Media Player. Houve um trabalho burocrático para fazer os administradores de rede instalarem os plug-ins corretos.
Atraso diferenciado nas máquinas do laboratório: a transmissão possui um atraso global em torno de 18s (causado pelo Media Player e Media Server), mas esse tempo é variável de máquina a máquina, pois depende da bufferização no computador. Assim, nas aulas onde várias máquinas no mesmo laboratório estão recebendo a transmissão, ocorria de um cliente assistir a apresentação 5 segundos antes do outro, gerando problemas com o áudio, pois cada máquina tem seu alto-falante. Nesses casos é importante a disponibilização de fones de ouvido individuais para cada usuário.

2.1.2 Problemas nos centros de ensino

Centro 3: disputa entre tomada da cafeteira e hub do mrouter. O mrouter foi desligado uma vez. O Hub também, em outra ocasião.
Centro 5: projetor ruim: de 30 em 30 minutos desligava.
Centro 6: máquina com screen saver: quando o screen saver era ativado, a transmissão era interrompida. Era necessário dar play novamente. É bom retirar sempre a proteção de tela para não dar esse tipo de problema.
TV Unisinos: faltava ponto de rede para colocar mrouter.

3. Videoconferência na RMAV-RS

Quando a Unisinos se conectou à rede do Metropoa, em dezembro de 1999, começaram os testes na rede metropolitana completa. O protocolo utilizado entre os parceiros é ATM na velocidade de 155Mbps, e a topologia é estrela, conforme visto na figura 7. A distância entre a Unisinos e a CRT é de aproximadamente 60Km de fibra, passando pelo sistema SDH ativo (esse fato provocou a demora na interligação da Universidade ao grupo). As outras entidades estão conectadas através de fibra escura numa distância menor que 15Km.

Figura 7: Rede Metropolitana da Grande Porto Alegre - RMAV-RS

Um dos testes iniciais efetuados foi videoconferência, onde foram testados alguns softwares, incluindo o SDR (com VIC/RAT) [5], o CU-Seeme (6) e o Netmeeting (7). O problema que se viu no Netmeeting é que ele só suporta dois interlocutores simultaneamente. Já o CU-seeme se portou bem, sendo utilizado com um reflector na UFRGS, conseguindo-se aproximadamente 15 fps para cada participante. O SDR também se portou bem, com taxas de 15 fps, mostrando algumas instabilidades seguidamente, tanto em Linux como em Windows. O teste a seguir mostra uma videoconferência utilizando o SDR, VIC e RAT.

Para entrar no Mbone, utilizou-se um mrouter (no PRAV) fazendo um túnel com outro mrouter (no POP-RS) a fim de passar por roteadores não multicast, formando uma topologia determinada manualmente. Os mrouters instalados utilizam o protocolo DVMRP para roteamento multicast, e os túneis são necessários pois nem todos os roteadores da Internet estão configurados para suportar multicast. Futuramente, espera-se que os protocolos de multicast, como o MOSPF, o PIM e o DVMRP, sejam habilitados em todos roteadores e tornem transparente o acesso multicast aos usuários. No caso do Rio Grande do Sul, existe um túnel do POP-RS com a FAPESP em São Paulo (rede ANSP), e a Unisinos estabeleceu um túnel com o POP-RS através da rede ATM do Metropoa, tornando-se assim o ponto de entrada do Mbone para a rede metropolitana.

Com o túnel ativado, basta um cliente entrar no SDR para que apareçam as sessões multicast que estão sendo anunciadas no momento, conforme mostra a figura 8. No caso, todos os participantes da videoconferência escolheram a sessão "Metropoa - entrem aqui!!!", que foi previamente criada numa máquina com FreeBSD na Unisinos.

Figura 8: tela inicial do SDR para escolha da sessão a participar

Ao escolher a sessão da videoconferência, como mostra a figura 9, pode-se ver que o protocolo de compressão de vídeo foi o H.261, que será utilizado pelo VIC no endereço multicast 239.255.155.106. Similarmente, o protocolo de áudio utilizado é o do RAT, cujo default é de 8KHz mono, e seu endereço multicast é 239.255.6.35.

Figura 9: tela inicial do SDR para entrar na sessão escolhida

Cada participante da videoconferência efetua o "join" na sessão, e gradativamente eles vão se integrando. A figura 10 mostra uma tela do VIC com 5 participantes, que são, de cima para baixo: UFRGS, PRAV, Laboratório de Redes da Unisinos (2 máquinas) e Procergs.

Figura 10: tela do VIC mostrando as diversas pessoas na videoconferência

O Metropoa possui uma faixa de 256 endereços IP verdadeiros, sendo o 200.132.73.x, como pode-se ver na figura 10. Algumas máquinas estavam ligadas diretamente no ATM, outras através do switch 8271. Os participantes estavam transmitindo a uma taxa relativamente baixa, de 100 a 500Kbps. Encontrou-se problemas novamente quanto à velocidade das máquinas. Com um Pentium III 500MHz, conseguiu-se mostrar 4 participantes em tela maior sem problemas, enquanto que com Pentium II 400, o máximo era dois, e menos que isso permitia uma só visualização em tela maior.

Um outro problema enfrentado foi a falta de estabilidade do VIC/RAT, com "penduradas" freqüentes em todos os participantes da conferência. Num teste nos últimos dias, parece que a versão 4.12 do RAT, versão 2.8ucl-1.1.3 do VIC com Linux encontra-se mais estável, mas é necessário uma bateria maior de testes para chegar a uma conclusão. Esse problema é muito sério, pois inviabiliza qualquer utilização dessas ferramentas num ambiente mais profissional e menos acadêmico.

4. Transmissão da TV Unisinos na RMAV-RS

Uma outra experiência interessante que está começando é a transmissão do sinal da TV Unisinos via rede interna (tal qual feito na Semana da Qualidade) e também via rede metropolitana, através de multicast.

A TV efetuou sua primeira transmissão experimental em 31 de março de 2000, e no mesmo dia o sinal foi transmitido para a rede interna e metropolitana. A topologia física utilizada foi a mesma da figura 1, sendo que o link de rádio com o PRAV partia do Centro 3, onde se localiza a transmissora da TV, e não houve interatividade, devido ao tipo de sinal ser broadcast, não se aplicando interatividade nesse caso.

Quanto à transmissão através da rede metropolitana, surgiu um problema: a Unisinos internamente utiliza endereços IP falsos (10.x.x.x), e a rede metropolitana utiliza IPs verdadeiros (200.132.73.x), gerando um problema de roteamento que força a utilização da rede Internet1 para acessar o arquivo que resolve o número IP multicast e os protocolos de compressão de áudio e vídeo da transmissão do sinal da TV.

A figura 11 ilustra o problema encontrado. Quando um cliente da rede metropolitana clica no link que direciona para o arquivo de configuração do grupo multicast, localizado em http://aranha.metropoa.tche.br, o servidor de DNS vai traduzir para o IP 200.132.73.100, e vai buscar o documento nesse endereço. Já o cliente interno da Universidade também deve buscar o mesmo arquivo no mesmo endereço, e como o número é IP verdadeiro, ele vai passar pela Internet1 para isso, já que o acesso à rede metropolitana não está configurado nos roteadores da Universidade, por se tratar de uma rede de testes que seguidamente sai do ar para a realização de experimentos, não se adequando ainda à produção. Após receber o arquivo de configuração, os clientes ingressam no grupo multicast referenciado pelo arquivo, utilizando os protocolos de compressão de áudio e vídeo indicados.

Figura 11: acesso via web para clientes internos e na rede metropolitana

Uma alternativa para não ter que passar pela Internet1 seria a existência de dois links na página de acesso ao vídeo, um para a rede interna e outro para a rede metropolitana. Isso não foi feito para não replicar a página na web, que já estava no contexto da TV, como mostra a figura 12. Como pode ser visto, quando o usuário clica em "Assista aqui a transmissão em tempo real", é aberta uma janela do Media Player no navegador, iniciando a recepção do vídeo. Para tanto, o link busca um arquivo ".nsf", que tem informações sobre o grupo multicast que o cliente deve se cadastrar, bem como os protocolos de compressão de áudio e vídeo que devem ser utilizados. Após o início da recepção de vídeo, o usuário pode exibir em tela cheia, melhorando a visualização do sinal.

Figura 12: página web de acesso pelo usuário à transmissão da TV

O roteamento multicast entre a rede interna da Universidade e a rede metropolitana é através de um túnel a partir do PRAV, que simplesmente estende o modelo visto anteriormente, na figura 1, com um túnel multicast adicional, direcionado para a rede metropolitana.

A qualidade do sinal foi semelhante à da transmissão da Semana da Qualidade, sendo que o CODEC de áudio utilizado foi o MP3 com 32KHz de taxa de amostragem e o de vídeo foi o MPEG-4 v3. O acesso através da UFRGS tinha a mesma qualidade do que o acesso via rede local da Universidade, visto que a largura de banda utilizada era baixa em relação ao total da rede metropolitana (em torno de 750Kbps). O atraso do servidor e bufferização do cliente (em torno de 18 s) não causam problema numa transmissão unidirecional.

5. Conclusão

Os testes relatados neste artigo mostram um dos focos de estudo sendo desenvolvidos na Unisinos e RMAV-RS, que é a parte de transmissão de áudio e vídeo em tempo real. O que foi feito é a ponta do iceberg, e o foco da equipe de multimídia em redes de computadores visa desenvolver as seguintes questões:

Qualidade de serviço: fazer com que as aplicações mais críticas tenham preferência sobre as outras nos equipamentos da rede, como por exemplo, fazer com que o áudio e o vídeo tenham preferência na transmissão de dados em relação a mensagens de correio eletrônico e download de arquivos na Internet (que podem esperar sem maiores problemas). Atualmente existe uma linha de pesquisa no PRAV visando inserir qualidade de serviço em determinadas aplicações. Já foi feito um teste com políticas de fila após um curso realizado na FAPESP [1]. O teste efetuado envolveu instalar ALTQ com CBQ e RED num FreeBSD funcionando como roteador, com uma placa de rede a 10Mbps e uma a 100Mbps, a fim de gerar um gargalo [4]. Duas máquinas linux, uma em cada lado do roteador, se conversarem através de 3 conexões TTCP, cada uma com uma política de prioridade diferente, como mostra a figura 13. O sistema funcionou, privilegiando a conexão com a maior prioridade, mas ainda se está no início dos trabalhos nessa linha.
Transmissão com criptografia e muitos participantes: as experiências com videoconferência tem diversos testes a serem desenvolvidos, como o de usar criptografia para transmissão dos dados. Pretende-se fazer esse teste buscando medir as diferenças de atraso entre uma transmissão com e sem criptografia, bem como as necessidades de máquina devido à carga extra de processamento. Além disso, pretende-se incluir muitos participantes, visando testar se existe algum limite prático no sistema.
Medição da disponibilidade do sistema: é importante saber quanto tempo as máquinas ficam sem apresentar falha, bem como analisar o motivo das mesmas, a fim de dimensionar e procurar melhorar o período de funcionamento das transmissões.
Medição do número de acessos nas transmissões em tempo real: pretende-se medir o número de pessoas que estão assistindo às transmissões multicast, e para isso a idéia é verificar o número de IPs diferentes que acessaram o arquivo ".nsc".
Transmissão de áudio e vídeo com alta qualidade: com placas de captura e compressão MPEG-2, pode-se conseguir qualidade de transmissão superior à TV e fitas VHS. Em fevereiro de 2000 foi feito um teste com placas Optibase MPEG-1 e MPEG-2, mostrando resultados bem animadores.

Figura 13: configuração montada para teste de priorização de filas

6. Sites Relacionados

[1] !o Workshop de Differentiated Services, por Reinaldo Penno Filho, João Carlos Mendes Luís e Luis Cordeiro. Disponível em http://www.gt-er.cg.org.br/sgt-qos/10a-reuniao/ diffserv.pdf, outubro de 1999.

[2] Metropoa: http://www.metropoa.tche.br

[3] PRAV - Unisinos: http://prav.unisinos.br

[4] Qualidade de Serviço sobre IP: http://qos.ittc.ukans.edu/

[5] Ferramentas do Mbone: http://www-mice.cs.ucl.ac.uk/multimedia/software/

Notas

1 Projeto do Edital RNP-PROTEM-CNPq de Redes Metropolitanas de Alta Velocidade - RNP/Internet2

2 http://www.metropoa.tche.br

3 David Birck, Eduardo Bastos, Eduardo Schneider, Fábio Mello, Gaspare Bruno, José Gossler, Luis Balbinot, Maiko de Andrade, Peter Finzsch, Valter Roesler

4 http://prav.unisinos.br

5 Uso da imagem cedido por Carlos Eduardo Hilsdorf - http://www.smagicas.com.br

6 http://www.whitepine.com

7 http://ww.microsoft.com