Home » Artigos arquivados » 2010 – Transmissão de vídeo em redes

2010 – Transmissão de vídeo em redes

Autor: Laércio Vasconcelos
Data: 03/11/2010

Sinopse:
A transmissão de vídeo digital é cada vez mais popularizada, não só na Internet como também nas redes locais. Neste artigo abordamos alguns conceitos importantes e aplicações.

Vídeo domina a Internet

A CISCO, um dos maiores fabricantes mundiais de equipamentos para redes, divulgou um estudo que prevê um elevado tráfego de dados de vídeo nos próximos anos. A estimativa é que em 2014 o tráfego total de dados representará 91% de todo o volume na Internet. No início da era das redes locais e da Internet, a maior parte do tráfego era formado por arquivos de texto e similares. Com o passar dos anos, este volume aumentou bastante. Nos anos 90 o tráfego aumento devido ao uso de imagens, depois veio a multimídia com arquivos de som, e finalmente vídeo. É preciso tomar alguns cuidados para permitir a transmissão de vídeo com boa qualidade nas redes locais e na Internet. As redes locais, e principalmente a Internet, não foram criadas visando o tráfego de vídeo. Foram necessários melhoramentos adicionais para permitir o tráfego de vídeo. Os resultados obtidos nem sempre são considerados bons.

Usuários comuns já estão acostumados a assistir vídeos via Internet, ou usar aplicações que também operam com vídeo. Casos bastante populares são o Youtube e o Skype, cada um com suas particularidades. O Youtube apresenta vídeo sob demanda, ou seja, não opera em tempo real. O usuário escolhe o vídeo que deseja assistir, que é então baixado para o seu computador e reproduzido. Um mecanismo de buferização permite que o filme seja exibido ao mesmo tempo em que é baixado e armazenado no buffer. Quando assistimos a uma transmissão televisiva através da Internet, o conteúdo é apresentado em tempo real. Esse tipo de exibição tem características diferentes do vídeo sob demanda, como vermos mais adiante neste artigo. Já o vídeo do Skype e programas de comunicação similares, além de operarem em tempo real, são mais rigorosos na questão temporal. Vídeos ao vivo podem ser bufferizados e exibidos, com um retardo de alguns segundos, sem prejudicar a recepção (*). Vídeos como o do Skype e aplicações de videoconferência não devem apresentar um retardo exagerado entre a geração na origem e a recepção do destino, o que prejudicaria a conversação.

(*) OBS: Quem já assistiu eventos esportivos pela Internet convive com alguns problemas. Mesmo que o vídeo seja apresentado com boa qualidade, o retardo de poucos segundos pode ser indesejável. Por exemplo, quando vemos o jogador prestes a chutar para o gol em uma partida de futebol, escutamos os fogos de artifício nas vizinhanças antes de vermos o gol propriamente dito. Perde um pouco a graça, pois antes de vermos o chute para o gol, já sabemos previamente do resultado. O sistema de TV convencional opera com retardo menor que o vídeo recebido pela Internet. Entretanto este retardo não atrapalha a maioria das recepções.

Conceitos sobre vídeo em redes

A transmissão de conteúdo de áudio e vídeo em redes tem características peculiares, diferentes dos demais conteúdos, e por isso requerem um tratamento especial. Por isso vários padrões foram criados a partir do início dos anos 90 (quando ocorreu a popularização da multimídia) pare permitir o seu funcionamento. O primeiro passo no estudo desses padrões é entender as particularidades das transmissões de multimídia.

Tráfego de dados e tráfego de vídeo

Quando estamos copiando arquivos comuns através de uma rede ou baixando arquivos via Internet, estamos lidando com informações com características peculiares:

1) É desejável que a recepção seja rápida, mas isto não é imprescindível

2) A recepção pode sofrer pausas de pequena ou média duração, sem prejudicar o arquivo final. Em um caso extremo, uma recepção pode ser suspensa e retomada horas depois, no caso do uso de programas gerenciadores de download.

3) Os dados devem ser recebidos na íntegra, sem perda de conteúdo.

4) Os dados recebidos devem ser idênticos aos dados enviados.

5) A recepção não precisa ser em tempo real.

01
Figura 1 – Taxa de uso da rede na leitura de um arquivo, sem pausas.

02

Figura 2 – Idem, com pausas na leitura.

Isso pode ser ilustrado com as figuras 1 e 2. Ambas mostram a taxa de utilização da rede durante a leitura de um arquivo inteiro a partir de um servidor, medida com o Gerenciador de Tarefas do Windows XP (o mesmo pode ser visto no Windows NT, 2000, Vista, Seven). Na figura 1 o arquivo foi lido de forma contínua e mais rápida. Na figura 2 a operação foi um pouco mais demorada pois sofreu pequenas pausas, já que o servidor estava mais ocupado. Mesmo com as pausas, o arquivo final é idêntico ao original. Situação semelhante ocorre em downloads da Internet. A recepção pode ter velocidade variável, sofrer pausas e até ser suspensa para continuar mais tarde (através de programas gerenciadores de download, desde que o host origem suporte a suspensão e continuação de downloads).

A transmissão de arquivos de vídeo em uma rede tem características completamente diferentes:

1) Existe um compromisso com o tempo
2) A taxa de recepção não precisa ser muito elevada, mas pausas são indesejáveis
3) Nas recepções ao vivo, trechos perdidos são simplesmente descartados
4) Dependendo da aplicação, o retardo de recepção deve ser minimizado

Não estamos considerando aqui o simples download de arquivos de vídeo para posterior reprodução (Ex: baixar um filme da Internet para gravar no HD e assistir depois). Este tipo de recepção se enquadra nas mesmas características das recepções de dados já abordadas.

A transmissão de vídeo em tempo real por uma rede ou pela Internet envolve a leitura e envio do arquivo para ser imediatamente reproduzido pelos receptores.

03

Figura 3 – Taxa de recepção de dados na exibição de um filme em tempo real, com taxa de dados variável.

04
Figura 4 – Taxa de recepção de dados na recepção de um filme em tempo real, usando um buffer para armazenar dados.

As figuras 3 e 4 mostram medidas de taxas de utilização da interface de rede de um computador durante a exibição de um filme a partir de um servidor de vídeo. No caso da figura 3, a recepção não apresenta pausas, e a taxa de recepção é variável. O vídeo desse exemplo tem taxa de dados variável (VBR). Trechos do filme nos quais existe muito movimento tendem a apresentar picos na taxa de dados. Muitas vezes os filmes são codificados em CBR (Taxa de dados constante), resultando em um fluxo quase constante.

A figura 4 mostra a taxa de utilização da rede por um computador que recebe um vídeo com o uso de um buffer de recepção. Note que os instantes de chegada de dados ocorrem em intervalos aproximadamente constantes. A quantidade de dados nesses instantes tem valor de pico bem maior que no caso da figura 3. Na figura 3, a taxa média de recepção corresponde a uma taxa de utilização de cerca de 1,5% com picos não superiores a 5%. Já na figura 4, os picos representam taxa de utilização da ordem de 15%. Nesses picos (rajadas, ou burst), os dados são recebidos e armazenados em memória, sendo imediatamente exibidos. Antes do buffer ficar vazio são recebidos novos dados. O uso de um buffer de recepção ajuda a eliminar pausas na exibição do vídeo, mas quando a rede está muito congestionada, essas pausas ainda poderão ocorrer. A situação é mais crítica quando existem muitos clientes na rede reproduzindo vídeos.

05
Figura 5 – Recepção de um arquivo de vídeo codificado com CBR.

A figura 5 mostra a taxa de recepção de um fluxo de vídeo que foi codificado com CBR (Constant Bit Rate). Vídeos codificados por este método tendem a exigir recursos da rede de forma mais previsível, já que uma situação indesejável quando vários fluxos atingem valore de pico é evitada. Em geral quando usamos programas para codificação de vídeo, existe um campo de opções para especificar o uso de CBR, e qual o valor a ser utilizado. No exemplo da figura 5, o vídeo usado foi copiado de um DVD, sendo mantida a resolução de 720×480, com 30 fps, e taxa de 1,4 Mbit/s, o que é considerado um vídeo “pesado”. Um filme de DVD, por exemplo, que não tem compromisso com a banda da rede, utiliza uma taxa apenas 3 vezes maior. Para poupar banda da rede, é comum usar taxas e resuluções menores, chegando na faixa de 100 a 500 kbits/s.

A codificação do vídeo da figura 5 foi feita com o programa Real Producer 13, e o formato de arquivo gerado foi o RM, para exibição com o Real Player. A exibição foi feita em um cliente com o programa Real Player, e a transmissão foi feita em um computador operando como servidor de vídeo, com o programa Helix Server, da Real Networks.

Apesar dos vídeos codificados com CBR terem a vantagem de apresentar um comportamento mais previsível no que diz respeito ao uso de banda da rede, têm como desvantagem a perda de qualidade nos trechos de vídeo nos quais existe grande variação de imagem, com muitos movimentos. Nesses instantes, um vídeo codificado com VBR apresenta um pico na taxa de transferência, mas como com CBR esse pico é eliminado, o vídeo aparecerá momentaneamente com baixa qualidade.

Compressão de vídeo

Arquivos de vídeo são volumosos, por isso usam sempre compressão. Dados são comprimidos por métodos lossless (sem perdas), (ex: formatos ZIP, RAR). Vídeos são comprimidos por processos que sacrificam qualidade em benefício das altas taxas de compressão (ex: MPEG). O mesmo ocorre com áudio (ex: MP3).

Além de serem volumosos, arquivos de vídeo quando transmitidos “ao vivo” (streaming) consomem uma parcela fixa da banda disponível. Por exemplo, um vídeo de 10 segundos com tamanho de 2 MB ocupará uma banda de 0,2 MB/s.

A compressão de vídeo reduzirá drasticamente o número de bytes de cada segundo de vídeo. Existem vários métodos de compressão usados em vídeo, e muitos deles possuem características que os torna atrativos para transmissão de vídeo em redes. Alguns exemplos: H.264, MPEG-4. Um software ou hardware que realiza compressão de vídeo é chamado Codificador. Um software ou hardware que realiza o processo inverso (descompressão) é chamado Decodificador. Genericamente chamamos o sistema completo de CODEC (Codificador e Decodificador). Normalmente o codificador é usado no transmissor e o decodificador é usado no receptor. Quase sempre os dois módulos são unidos em um só software ou hardware, permitindo a transmissão nos dois sentidos.

Vários fatores são importantes na escolha de um CODEC de vídeo. Podemos destacar:

1) Velocidade de compressão
2) Velocidadade de descompressão3) Qualidade do vídeo
4) Taxa de compressão

A velocidade de compressão é importante, mas torna-se mais importante ainda quando a codificação é feita em tempo real, por exemplo, a codificação do vídeo recebido de uma câmera analógica para transmissão ao vivo. A velocidade de compressão continua importante, mas torna-se menos crítica quando a transmissão não é em tempo real. Por exemplo, em um sistema de vídeo por demanda, os vídeos originais podem ser previamente codificados e armazenados para posterior transmissão. Nesse caso é bastante razoável que a compressão seja feita sem pressa, permitindo assim outros benefícios como melhor qualidade e uma alta taxa de compressão.

Ao usar um codificador que resulte em alta taxa de compressão e alta qualidade, podemos exigir do transmissor um tempo de processamento muito elevado, inviabilizando seu uso em tempo real. Nesse caso abrimos mão de um pouco da qualidade e compressão para usar um codificador mais rápido, viabilizado seu uso em tempo real.

Uso da banda disponível

As figuras 3, 4 e 5 mostram que uma transmissão de vídeo em rede consumirá uma parcela, muitas vezes fixa, da banda disponível. O aumento da qualidade e do número de transmissões simultâneas aumentará a taxa de utilização da rede, potencialmente levando-a a um estrangulamento. Por exemplo, é possível transmitir um vídeo com qualidade bastante aceitável um pouco inferior à de um DVD mas superior à de uma TV, com taxa de 1,4 Mbits/s. Muitos filmes disponíveis na Internet foram codificados com esta taxa. Uma hora de filme com esta qualidade ocupa cerca de 700 MB (Ex: DIVX, 1400 kbps). 10 filmes sendo transmitidos em uma rede com esta qualidade resultariam em um consumo de banda de cerca de 14 Mbits/s, ou seja, teoricamente 14% da banda total disponível em uma rede local de 100 Mbits/s. Na prática o consumo de banda será maior, devido ao overhead do TCP/IP.

Quando o número de exibições simultâneas é maior, aumentará bastante o uso da banda disponível na rede, podendo chegar a um ponto no qual os vídeos perderão qualidade devido às pausas. Várias providências podem ser tomadas para resolver o problema. Por exemplo, se os vídeos vierem de um servidor centralizado, podemos usar um switch com uma porta Gigabit para a ligação do servidor, mantendo as demais estações em portas de 100 Mbits/s. Esse tipo de switch é muito mais barato que um modelo com todas as portas Gigabit Ethernet.

hard-120
Figura 6 – Estrangulamento dos servidores.

hard-121

Figura 7 – Usando conexões Gigabit Ethernet para os servidores.

O melhoramento resultante do uso de um switch com portas Gigabit Ethernet apenas para os servidores é ilustrado nas figuras 6 e 7. Na figura 6, os servidores estão congestionados porque são acessados por um número grande de clientes. Isso não é um problema exclusivo das transmissões de multimídia, mas de qualquer tipo de dado. Na figura 7 usamos um switch com portas Fast Ethernet (100 Mbits/s) para os clientes e apenas duas portas Gigabit Ethernet (1000 Mbits/s) para os servidores. Ao suportarem um tráfego teoricamente 10 vezes maior, poderão atender a um número maior de clientes, ou então operar com o mesmo número de clientes porém com uso maior da banda, permitindo melhor qualidade nos vídeos.

Em muitos casos esse tipo de solução não pode ser usado. Suponha por exemplo o caso de duas redes locais A e B conectadas por um link ATM de 155 Mbits/s. O tráfego de vídeo neste link poderá consumir uma parcela considerável da sua banda.

O uso de taxas de dados menores, e em conseqüência de vídeos com qualidade inferior, pode ser uma solução de compromisso entre a capacidade total da rede e o tráfego ocupado por vídeo.

Codificação de vídeo

Em qualquer caso, o sinal de vídeo a ser transmitido precisa ser digitalizado e codificado, usando compressão. Não é nosso objetivo discutir detalhadamente os métodos para compressão de vídeo. Em linhas gerais, qualquer vídeo é formado por uma seqüência de quadros chamados frames. Para ter uma sensação visual de continuidade de movimentos é preciso ter 30 frames por segundo (fps). Mais que isso não é usado, pois não produz melhoramentos na percepção da visão humana. Essa é a taxa de quadros usada por vários sistemas de TV, como o PAL. Também é comum a taxa de 24 fps em outros sistemas de vídeo, como o NTSC, e nas películas de cinema. Filmes em DVD operam com 24 ou 30 fps. Valores inferiores são percebidos pela vista humana como falta de continuidade de movimentos. É aceitável usar taxas entre 10 e 15 fps para videoconferência. Câmeras de vigilância quase sempre operam entre 5 e 10 fps. O uso de taxas de quadros menores diminui o tráfego de dados.

A compressão de vídeo converte os dados originais, organizados em frames, em novos frames codificados. Não é necessário transmitir frames inteiros, pois existe pouca diferença entre frames consecutivos. A figura 8 mostra dois tipos de frames usados em vídeo digital. Os I-frames são imagens completas, como se fossem arquivos JPEG. Os P-frames possuem apenas a diferença em relação ao frame anterior. Partes da imagem que não variam de um frame para outro não precisam ser transmitidas, resultando em redução na quantidade de dados. Para reconstituir um frame a ser exibido, o receptor deve tomar como base o último I-frame recebido e adicionar os dados recebidos nos P-frames.

hard-122
Figura 8 – Frames em uma compressão de vídeo.

Como a compressão de vídeo descarta informação, com o passar do tempo os erros existentes nos P-frames são acumulados e a imagem é degradada. Para resolver o problema, novos I-frames (também chamados de key frames) são periodicamente transmitidos. Normalmente são transmitidos um ou dois I-frames a cada segundo, o que é suficiente para manter a qualidade da imagem. Por exemplo, em uma codificação a 30 fps, seriam enviado os frames na seqüência:

IPPPPPPPPPPPPPPIPPPPPPPPPPPPPP…

Quanto maior é a quantidade de movimentos, maior será a quantidade de dados a serem transmitidos. Além disso, os métodos de compressão de vídeo eliminam informações que a vista humana não consegue perceber. Por exemplo, nossa visão não percebe mudanças rápidas de cor, mas consegue perceber variações rápidas de luminância (mais claro, mais escuro). Sendo assim, pode-se usar uma taxa alta para a luminância e uma taxa mais baixa para a crominância (informação de cor).

Existem vários padrões para codificação de vídeo, como MPEG, MPEG-2, MPEG-4, H.261, H.263, H.264, etc.. Esses padrões dão origem aos respectivos CODECs. Esses padrões usam diferentes métodos de compressão e suas variações.

Tempo de compressão

Quando um vídeo analógico deve ser digitalizado em tempo real, é preciso levar em conta o compromisso entre velocidade, qualidade e taxa de compressão. Por exemplo, se um CODEC demora 2 segundos para codificar 1 segundo de vídeo, não poderá ser usado em tempo real. Em geral quando necessitamos de alta taxa de compressão e/ou alta qualidade, o CODEC requer muito processamento. Mesmo quando não podem ser usados em tempo real, os CODECs podem gerar os arquivos previamente para serem transmitidos depois (vídeo sob demanda). É o caso típico dos vídeos do Youtube, vídeos gravados em DVD, vídeos disponíveis na Internet em geral.

Quando o vídeo deve ser gerado em tempo real, a compressão precisa ser rápida, mesmo que para isso seja preciso reduzir a sua qualidade. Nessa categoria estão incluídos os sistemas de monitoramento (câmeras de vigilância), teleconferência, tele-presença e similares.

Resolução e formato de vídeo

Assim como alguns formatos de vídeo são padrão em telas de computadores, outros são típicos de transmissões de vídeo digital. As resoluções típicas para computadores são:

640×480 (VGA)
800×600 (Super VGA)
1024×768 (XGA, também é um tipo de Super VGA)
1280×960
1280×1024

Já as resoluções usadas pelos diversos formatos de vídeo são um pouco diferentes:

704×576 (4CIF)
352×288 (FCIF)
176×144 (QCIF)
704×480 (4SIF)
352×240 (SIF)
176×120 (QSIF)

Algumas aplicações de vídeo em tempo real

As aplicações em tempo real são críticas porque o CODEC sofre limitações na sua performance. Isso pode ser refletido na taxa de compressão, ou seja, pode ser possível obter uma taxa de compressão não tão pequena quanto seria desejado. Teríamos que escolher entre aceitar o aumento do tráfego na rede ou reduzir a qualidade do vídeo.

Outro problema do vídeo em tempo real é que retardos grandes podem ser inaceitáveis. A transmissão de um evento esportivo ao vivo, por exemplo, pode não ser prejudicada quando a rede produz um retardo de vários segundos. Já em uma conversação ou outra aplicação interativa (ex: videoconferência), poucos segundos de retardo podem atrapalhar o entendimento dos participantes e resultar em longas pausas durante a conversação.

A Internet não foi projetada para transmitir vídeo em tempo real, nem mesmo em garantir qualidade de serviço para conteúdos de vídeo e áudio. Dentro de uma rede, o ambiente é mais controlado, e existem tecnologias para garantir a qualidade de serviço. Se o tráfego de vídeo e áudio passa pela Internet, está entrando em um ambiente não controlado, e toda a garantia de qualidade é comprometida. No vídeo em tempo real, a qualidade diz respeito não só à resolução e à “perfeição” das imagens, mas também à ausência de pausas. Não é o caso de vídeos que não são em tempo real, como os do Youtube. Lá podemos encontrar vários vídeos com resolução de até 720×480, mas a exibição em geral apresenta pausas. Temos que “esperar o filme carregar” para exibi-lo com qualidade, coisa que não é possível nas transmissões de vídeo em tempo real.

Em muitos casos, ligações de longa distância são feitas entre redes diferentes dentro de uma corporação, porém usando conexões próprias (Ex: ATM, ISDN). Quando é inevitável passar pela Internet é necessário reduzir a resolução e a qualidade do vídeo para reduzir a possibilidade de ocorrerem problemas.

Monitoramento

Muitos sistemas de vigilância em condomínios e empresas operam com vídeo analógico. Várias câmeras analógicas, normalmente em vídeo composto padrão NTSC, são ligadas a um computador com uma placa digitalizadora de vídeo com múltiplas entradas. Este computador faz a digitalização, armazena os vídeos e apresenta na tela os sinais vindos das câmeras.

Mais avançados são os sistemas de monitoramento baseados em câmeras digitais. Essas câmeras fazem sozinhas a digitalização de vídeo e o transmitem em formato digital. As WebCams são exemplos baratos e simples dessas câmeras, porém operam com baixa qualidade. Nos sistemas mais sofisticados são usadas câmeras IP, que transmitem o conteúdo de vídeo continuamente através de uma rede local. Existem ainda modelos Wi-Fi.

Câmeras IP são encontradas em vários modelos, com diferentes características. São comuns os modelos que operam com resolução de 640×480, que é próxima da usada pelos televisores convencionais. Existem câmeras com resoluções mais altas, como 1280×720. As câmeras AXIS A1755 (figura 9) operam com resolução de até 1920×1080. Pode ser configurada para operar de 5 fps a 30 fps. Obviamente maior resolução e maior taxa de quadros resultará em maior tráfego na rede.

hard-123
Figura 9 – Câmera AXIS Q1755.

A figura 10 mostra o gráfico do tráfego de dados de uma câmeras de monitoramento. A câmera opera com 1280×720, mas foi ajustada para 7 fps, resultando na taxa média de 375 kbits/s, ou seja, consome menos de 1% da banda disponível da rede, além de resultar em arquivos de gravação de vídeo com menor tamanho.

hard-124
Figura 10 – Monitoramento de tráfego de uma câmera IP. (CLIQUE PARA AMPLIAR)

Mesmo câmeras analógicas podem ser usadas na formação de um sistema digital de monitoramento. Basta usar um aparelho autônomo que faça a digitalização de vídeo e transmita os dados continuamente por uma rede. O aparelho mostrado na figura 11 pode ser ligado a quatro câmeras analógicas e transmite o resultado pela rede, através do seu conector RJ-45.

hard-125
Figura 11 – Digitalizador de sinais de vídeo com interface de rede.

Videoconferência

Este é um recurso que foi popularizado entre os usuários de computadores graças ao Skype. Antes dele, outros programas menos populares e de uso não tão fácil foram usados, como o NetMeeting, da Microsoft. A videoconferência pode envolver duas ou mais pessoas, e a comunicação pode ser feita em rede local ou pela Internet.

hard-126
Figura 12 – Videoconferência com o Skype.

Para uso profissional, existem sistemas de videoconferência mais sofisticados. Um sistema de videoconferência pode ser baseado apenas em software, usando a infraestrutura de rede já existente. Cada computador tem sua câmera e microfone e usa um software cliente. Em geral existe um servidor centralizado que coordenará as ligações. Usando uma rede comum, os resultados podem ser insatisfatórios em termos de qualidade visual conforme o número de usuários conectados aumenta. Podem ocorrer pausas no fluxo de vídeo que prejudicam a sua compreensão.

13
Figura 13 – Videoconferência com múltiplos participantes.

Um sistema mais avançado para videoconferência pode usar câmeras de alta resolução, um servidor especializado e equipamentos de rede (switches, roteadores) que oferecem recursos apropriados para o tráfego de vídeo.

Tele-presença

A tele-presença é uma tecnologia que vai além da videconferência. O usuário não apenas vê uma imagem na tela, mas pode ainda:

  • Ter uma sensação maior de imersão no ambiente remoto
  • Interagir com elementos do ambiente remoto

A tele-presença pode ser implementada em diversos níveis. O caso extremo seria o exemplo do filme AVATAR. Na vida real, a tele-presença é implementada através de sensores e atuadores, através dos quais recebemos a imagem, som e outras informações de um ambiente remoto e podemos interagir com seus elementos. Em um caso mais simples, podemos ter uma videoconferência avançada, na qual temos a sensação que estamos ocupando a mesma mesa que as pessoas nas diferentes localidades remotas, como o sistema de telepresença da CISCO.

hard-127
Figura 14 – Videoconferência com tele-presença.

Apesar de não interagirmos fisicamente com as pessoas dos ambientes remotos, esse sistema dá uma sensação de imersão no ambiente, vai um passo além da videoconferência.

 hard-128
Figura 15 – Robô controlado por sistema de tele-presença.  hard-129 Figura 16 – Contolando um robô por tele-presença.

Controlar um robô à distância também é uma aplicação de tele-presença (figuras 15 e 16). Através de um visor especial, vemos as imagens captadas pela câmera do robô. Controles especiais nos braços e nas mãos permitem comandar os elementos manuseados pelo robô. Existem aplicações semelhantes na área militar. A figura 17 mostra um sistema que controla os movimentos do robô de acordo com os movimentos da cabeça do usuário, que tem a sensação de estar presente no ambiente remoto no qual está o robô.

hard-130
Figura 17 – Aplicação militar de tele-presença.

Note que a tele-presença reúne elementos de videoconferência e de realidade virtual. Uma diferença importante é que a tele-presença não usa realidade virtual. Estamos realmente interagindo com um ambiente remoto real, mas muitas das técnicas empregadas na sua implementação são originárias dos sistemas de realidade virtual.

Como vemos, a tele-presenca utiliza diversas tecnologias. A transmissão de vídeo em tempo real é um elemento comum em importantíssimo em todas as implementações de tele-presença. Para o escopo deste trabalho, nos concentraremos em discutir os requisitos e as características da transmissão de vídeo em tempo real para atender a esta e a outras aplicações de vídeo em tempo real. Uma característica importantíssima nas aplicações de tele-presença é que o retardo de transmissão deve ser reduzidíssimo quando é preciso interagir fisicamente com o meio remoto. Por exemplo, será muito difícil controlar um robô se os movimentos que comandamos só aparecem na tela meio segundo depois.

Parâmetros de desempenho

As transmissões de vídeo em redes requerem quatro parâmetros importantes relacionados com o seu desempenho:

  • Taxa de transmissão
  • Retardo
  • Variação do retardo (jitter)
  • Taxa de erros

Esses parâmetros são muito mais críticos na transmissão de vídeo em tempo real, que são na transmissão de dados comuns. Uma taxa de transmissão baixa prejudica, mas em geral não inviabiliza uma transmissão de dados. O retardo na chegada de pacotes, bem como a variação desse retardo, não têm influência nos dados recebidos. Eventuais erros como pacotes perdidos podem ser tratados em protocolos superiores (TCP, UDP). Já as transmissões de vídeo em tempo real são extremamente exigentes em relação a esses parâmetros.

Taxa de transmissão

Cada fonte de vídeo gera dados com uma determinada taxa de transmissão. Isso depende da resolução, da qualidade e do CODEC empregado. É possível fazer uma estimativa aproximada da banda a ser utilizada por vídeo em uma rede. Somamos as taxas de transmissão de todos os sinais que passam por um canal e adicionamos 20% como margem de segurança devido ao overhead do TCP/IP. Por exemplo, se um sistema de videoconferência transmite o sinal em UNICAST para 10 estações, e o vídeo tem taxa de 1,4 Mbits/s, a banda total será 1,4 x 10 x 1,2 = 16,8 Mbits/s.

Retardo

Ao passar por switches e roteadores, um sinal de vídeo sofrerá retardo. Sempre chegará ao destino com uma diferença temporal. Se essa diferença for grande poderá prejudicar aplicações que exigem interatividade.

Jitter

O jitter é a variação do retardo. Prejudicará as transmissões do tipo streaming, nas quais os dados são exibidos imediatamente após a recepção, com pouca ou nenhuma buferização. A variação do retardo fará com que o vídeo recebido apresente pequenas pausas. Uma solução é usar um buffer maior para compatibilizar a chegada dos dados, com taxa variável, com a exibição a uma taxa constante. O problema aqui é que o uso do buffer maior também resultará em aumento do retardo, apesar de permanecer constante.

Taxa de erros

Em transmissão de dados comuns, eventuais erros não recuperados nas camadas inferiores são solucionados por protocolos de camada superior, como TCP e UDP, mediante retransmissões. Em uma transmissão de vídeo em streaming ou multicast, não é possível retransmitir os dados, já que o vídeo não pode parar ou voltar no tempo, precisa continuar. Tipicamente pacotes de vídeo perdidos são descartados, resultando em pequenos cortes no vídeo recebido. Cortes de curta duração são tolerados até certo ponto, mas se forem muitos prejudicarão bastante a qualidade do vídeo recebido.

Terminologia, padrões e protocolos

É preciso conhecer alguns padrões aplicados em sistemas de multimídia em redes. Alguns dizem respeito à codificação de vídeo, outros aos protocolos que procuram garantir a qualidade de serviço e ao estabelecimento das conexões.

H.323

Especificação da ITU para sistemas de comunicação em multimídia em redes baseadas em pacotes que não oferecem QoS. É um conjunto de especificações para formatos de áudio, vídeo e dados, e os respectivos controles necessários ao funcionamento dessa comunicação. São suportadas transmissões de áudio, áudio/vídeo, e áudio/vídeo/dados. Dentro do padrão estão incluídas especificações para:

  • Áudio: G.711, G.723.1, G.722.1
  • Vídeo: H.261, H.263, H.264
  • Dados: T.120
  • Controle e gerenciamento: H.255.0, H.245, H.225.0
  • Controle de mídia: RTP e RTCP

As transmissões de áudio e vídeo usam UDP, e as transmissões de dados, gerenciamento e controle usam TCP. A figura 18 mostra como estão relacionados os protocolos do padrão H.323.

18
Figura 18 – Protocolos do padrão H.323.

Produtos baseados no H.323 foram lançados pela IBM, Intel, Microsoft e CISCO. Atualmente existem inúmeros outros fabricantes que o adotam em seus produtos. Um exemplo é o sistema Vega X3. É baseada no padrão H.323 e utiliza diveros dos recursos apresentados neste artigo.

hard-131
Figura 19 – Câmera Veja X3, segue o padrão H.323.

H.261, H.263, H.264

Padrões para compressão de vídeo. São usados em diversos sistemas de multimídia, em redes locais, videoconferência, etc.

PIP e PAP

PIP significa “picture in picture”. É um modo de exibição no qual uma pequena janela de vídeo é exibida dentro de uma tela com o vídeo principal. É bastante comum nos aparelhos de TV modernos. PAP significa “picture and picture”, e consiste em exibir as duas janelas de vídeo lado a lado, com tamanhos iguais.

MCU – Multipoint Control Unit

Dentro do padrão H.323, este é um elemento da rede que permite a três ou mais terminais participarem de uma videoconferência. É formado por um MC (Multipoint Controller) e um MP (Multipoint Processor) que é opcional. O MC coordena as sessões de comunicação entre os diversos terminais envolvidos em uma multiconferência. O MP realiza processamento de fluxos de áudio, vídeo e dados. O funcionamento da MCU é definido pelos padrões H.243 e H.231, que fazem parte do padrão H.323.

Terminal

É uma estação da rede capaz de participar de uma videoconferência, tipicamente um comptuador.

Gatekeeper

Dentro do padrão H.323, o gatekeeper tem funções que se confundem com o módulo MC da MCU. Realiza tradução de enderços e acesso à rede para os terminais e para a MCU.

Gateway

É um elemento da rede que permite o acesso a outras redes, por exemplo, ATM ou ISDN. A figura 20 mostra como esses elementos (Gateway, Gatekeeper, MCU e Terminais) estão relacionados no padrão H.323.

RTP – Real Time Protocol

Protocolo para transporte de áudio e vídeo pela Internet e em redes locais. No padrão H.323, recebe fluxos de áudio (G.711, G.723.1, G.722.1) e vídeo (H.261, H.263, H.264) e os encapsula em UDP. Opera em conjunto com o RTCP.

RTCP – Real Time Control Protocol

Opera juntamente com o RTP. Enquanto o RTP é encarregado da transmissão e recepção, o RTCP realiza monitoramento e estatísticas de QoS.

20

Figura 20 – Elementos de uma rede para videoconferência padrão H.323.

RSVP – Resource Reservation Protocol (RFC 2205)

É um protocolo de transporte que permite realizar a reserva de recursos em uma rede. É usado tipicamente para transmissões de multimídia em tempo real. Os recursos reservados são a banda e o delay. Para que a reserva seja possível, é necessário que os roteadores possuam suporte a RSVP. Quando o roteador suporta reserva de banda e RSVP, responderá ao terminal solicitante, caso contrário simplesmente passará a requisição adiante. Este recurso não faz parte do padrão H.323.

DiffServ (Differential Service) e IntServ (Integrated Services)

São duas arquiteturas para QoS usadas na Internet, com abordagens diferentes. Na arquitetura DiffServ, os pacotes são marcados com números que definem a sua prioridade no tráfego. Pacotes relativos a transmissões de multimídia recebem um tratamento diferenciado nos roteadores, sendo encaminhados antes dos pacotes normais (melhor esforço). A arquitetura IntServ é baseada no protocolo RSVP para fazer reserva de banda específica para a conexão em andamento, na qual será enviado o fluxo de multimídia.

Broadcasting, Unicasting, Multicasting

Broadcasting é o ato de enviar um fluxo multimídia para múltiplos receptores. A técnica mais simples para realizar isso é o Unicasting, no qual um transmissor envia os dados individualmente para cada receptor. Esta técnica tende a consumir muita banda na rede. No Unicasting, cada receptor (cliente, ou player) está conectado ao transmissor (servidor) e recebe seu fluxo de forma individual. O tráfego de dados em um broadcasting implementado dessa forma é simular ao tráfego resultante quando os inúmeros clientes recebem fluxos diferentes.

hard-132
Figura 21 – Unicasting.

O multicasting reduz a utilização da banda tirando proveito do fato do mesmo conteúdo ser enviado para múltiplos receptores. Como existe somente uma transmissão em andamento, o consumo de banda será muito menor. Cada receptor, ao invés de estabelecer uma conexão com o servidor, estabelece uma conexão com o fluxo de dados e daí recebe o conteúdo desejado.

hard-133
Figura 22 – Multicasting.

O multicasting pode ser usado somente em rede local, já que a Internet não o suporta. Também é preciso que a infraestrutura de rede possua o suporte adequado. Os switches utilizados têm que ser compatíveis com multicasting.

RTSP – Real Time Streaming Protocol

É um protocolo que permite que clientes enviem a um servidor de vídeo sob demanda, comandos no estilo VCR, como Play, Pause, Stop, etc. Este protocolo é usado em programas como o Real Player.

Exemplo: Helix Server, da Real Networks

Este software é um servidor de vídeo, produzida pela Real Networks, a mesma empresa que produz o popular Real Player. O software é instalado em um servidor com Windows 2003/2008 ou Linux, e disponibiliza os vídeos armazenados para os clientes da rede. Funciona em rede local ou na Internet.

hard-134
Figura 23 – Tipos de vídeos suportados pela plataforma Helix.

O Helix Server suporta vários tipos de arquivos de áudio e vídeo. Os fluxos de multimídia podem ser transmitidos para vários players e dispositivos (PCs e portáteis). O tráfego de dados pode ser em Unicasting e Multicasting, suporta streaming e transmissões ao vivo. É facilemente integrado a players como o Windows Media Player, Apple Quicktime e Real Player. Outros produtos são usados para conversão de vídeos para os formatos RM e RMVB, da Real Networks, mas outros formatos também podem ser usados, como o WMV e o WMA, da Microsoft.

A configuração do Helix Server é muito simples. Devemos armazenar em uma pata CONTENT no servidor, os vídeos a serem transmitidos. A seguir, criamos um link nos clientes para os vídeos armazenados. Suponha que queremos exibir um vídeo armazenado no servidor com nome INDIANA3.RM, e suponha que o nome do nosso servidor na rede seja serv-2003. Criamos então um arquivo de extensão .RAM, com o bloco de notas ou outro editor para texto puro (.txt) com uma única linha:

rtsp://serv-2003/indiana3.rm

A comunicação entre o cliente e o servidor é feita pelo protocolo RTSP (Real Time Streaming Protocol). Usamos então “rtsp://”, seguido do nome do servidor e do arquivo de vídeo a ser usado. No nosso caso usamos para o servidor o nome “serv-2003” na rede local, mas em seu lugar pode ser usado o domínio do host na Internet.

hard-135
Figura 24 – Filme exibido com o Real Player, a partir de um servidor de vídeos com o Helix Server.

O Helix Server é acompanhado de um programa de gerenciamento e monitoração. No exemplo da figura 25 são mostradas algumas atividades do servidor. No momento vemos por exemplo o número de clientes (4) exibindo vídeos. É mostrado ainda o gráfico com o número de clientes em função do tempo. Podemos obter várias outras informações, como por exemplo, o uso da banda (no momento, 11.181 kbps).

hard-136
Figura 25 – Uma das informações do programa de gerenciamento do Helix Server.

Conclusões

Este trabalho pode ser visto como uma introdução a um tópico bastante extenso dentro da tecnologia de redes. O grande número de protocolos e padrões dá uma certa idéia de redundância ou desorganização. É preciso entender que as redes e a Internet não foram criadas inicialmente para transportar vídeo, depois foram adaptadas para atender a essas novas necessidades. É fato que o tráfego de vídeo na Internet vai aumentar bastante nos próximos anos, e é preciso que os padrões que dão suporte a esta tecnologia sejam empregados.

É preciso dar uma atenção especial ao padrão H.323, dominante nas aplicações de videoconferência. Em relação à transmissão de vídeo em tempo real, é fundamental o suporte à qualidade de serviço, área na qual se destacam as arquiteturas InteServ (RSVP) e DiffServ.