multimídia prof: ricardo gonçalves quintão e-mail: [email protected]

Multimídia

Prof: Ricardo Gonçalves Quintão

http://paginas.terra.com.br/relacionamento/rgquintao

E-mail: [email protected]

04/11/23 Pós-Graduação em Gerência e Projeto de Redes de ComputadoresTCP/IP

2/63

Bibliografia

• Redes de Computadores e a Internet – Uma Nova Abordagem– Autores: James F. Kurose; Keith W. Ross

– Editora Pearson Education

• Redes de Computadores– Autor: Andrew S. Tanenbaum

– Editora Campus


3/63

Introdução

• Grande desenvolvimento e ampla disseminação das aplicações em rede que transmitem e recebem conteúdo de áudio e vídeo pela Internet.

– Vídeos de entretenimento;– Telefonia IP;– Rádio por Internet;– Teleconferências;– Jogos Interativos;– Mundos Virtuais;– Ensino à Distância;– etc.


4/63

Introdução

• As exigências de serviço dessas aplicações diferem de modo significativo daquelas das aplicações tradicionais orientadas a dados.

• Estas aplicações são muito sensíveis ao atraso fim a fim, a variação de atraso (jitter) mas podem tolerar perdas de dados ocasionais.

• Essas exigências de serviços fundamentalmente diferentes sugerem que a arquitetura de rede projetada de início para a comunicação de dados pode não se adaptar bem para o suporte de aplicações multimídia.


5/63

Aplicações Multimídia

• Características importantes:– Temporização;– Tolerância à perda de dados.

• Como vimos, aplicações multimídia são altamente sensíveis ao atraso, porém, são tolerantes à perda.

• Perdas ocasionais causam ligeiras perturbações na recepção de áudio e vídeo e estas perdas podem ser parcialmente ou totalmente escondidas.


6/63


• As aplicações multimídia dividem-se em três classes:– Fluxo contínuo de áudio e vídeo armazenados;– Áudio e Vídeo de fluxo contínuo ao vivo;– Áudio e Vídeo interativos em tempo real.


7/63


Fluxo contínuo de áudio e vídeo armazenados.

Definição:Nesta classe o cliente solicita a qualquer momento arquivos de áudio e vídeo comprimidos que estão armazenados nos servidores.

• Os arquivos de áudio armazenados podem conter:– Áudio de uma conferência, Músicas, Programas de rádio famosos, etc

• Os arquivos de vídeo armazenados podem conter:– Vídeo de uma palestra, Filmes de longa duração, Programas de televisão

gravados, Documentários, Eventos históricos, Desenhos animados, Videoclipes, etc.


8/63


• Aspectos-chave distintos nessa classe de aplicação:– Mídia Armazenada:

O conteúdo multimídia foi pré gravado e está armazenado no servidor; O usuário pode realizar pausa, retroceder, avançar e escolher itens no conteúdo da

apresentação. O tempo entre a solicitação do usuário e a sua manifestação deve ser de no máximo 10

segundos para ser considerada aceitável.

– Fluxo contínuo: Enquanto a transferência dos dados ocorre, a reprodução é feita no cliente. A reprodução pode ficar em um ponto diferente em relação à transferência de dados. Não é necessário fazer o download completo do arquivo para então reproduzi-lo.

– Reprodução contínua: Assim que se inicia a reprodução, ela deve prosseguir de acordo com a temporização

original da gravação. Possui grandes restrições ao atraso na entrega de dados. Os dados devem ser recebidos do servidor a tempo de serem reproduzidos no cliente,

caso contrário serão considerados inúteis.


9/63


Áudio e vídeo de fluxo contínuo ao vivo

Definição:Nesta classe o cliente recebe uma transmissão de dados que não estão armazenados, e sim sendo gerados no “mesmo” momento.

• Temos como exemplo:– Transmissão de rádio e televisão ao vivo.

• Como o fluxo contínuo de áudio e vídeo ao vivo não é armazenado, o cliente não pode adiantar o programa que está recebendo, contudo, com o armazenamento local de dados recebidos, outras operações interativas, como pausa e retrocesso em multimídia ao vivo são possíveis.

• Normalmente este tipo de transmissão é feita para diversos clientes, o que leva ao uso da técnica de multicasting.


10/63


Áudio e vídeo interativos em tempo real

Definição:Nesta classe os clientes podem se comunicar um com os outros interativamente usando áudio/vídeo.

• Temos como exemplo:– Telefone pela Internet;

– Videoconferências.

• Para estas aplicações, o atraso deve ser mínimo para que não haja desconforto na comunicação. Para o caso da voz temos:– Atrasos inferiores a 150 milissegundos: imperceptíveis ao ouvido humano;

– Atrasos entre 150 e 400 milissegundos: aceitáveis;

– Atrasos superiores a 400 milissegundos: conversação inisteligível.


11/63

Obstáculos para a multimídia na Internet de hoje

• A camada de rede da Internet oferece um serviço de melhor esforço para todos os datagramas que transporta.

• Não existe promessa em relação ao atraso fim a fim para um pacote individual.

• Não existe promessa em relação à variação do atraso de pacote dentro de uma corrente de pacotes.

• Como tanto o TCP como o UDP rodam sobre o IP, nenhum desses protocolos dará alguma garantia às aplicações requisitantes.

• Devida à falta de qualquer esforço especial para entregar pacotes a tempo, é um problema extremamente desafiador desenvolver aplicações de rede multimídia de sucesso na Internet.


12/63

Obstáculos para a multimídia na Internet de hoje

• O telefone por Internet e o vídeo interativo em tempo real alcançaram, até agora, sucesso bem menor do que o fluxo contínuo de áudio/vídeo armazenado.

• Voz e vídeo interativos em tempo real impõem rígidas limitações ao atraso de pacote e à variação de atraso do pacote.

• Voz e vídeo interativos em tempo real funcionam bem em regiões onde a oferta de largura de banda é abundante e, portanto, o atraso e a variação de atraso são mínimos.

• Devida a tolerância a perda de pacotes, o uso do UDP se torna interessante, pois o seu overhead é menor, aumentando o fluxo de dados.

• No caso de comunicações não interativas, podemos retardar a reprodução no receptor para diminuir o efeito da variação do atraso.

• Inserção de marcas de tempo para que o receptor saiba quando reproduzi-los.


13/63

Como a Internet deveria se desenvolver para dar melhor suporte à multimídia

• Existem três vertentes para o desenvolvimento da Internet para os serviços multimídia.

• Aumento da largura de banda: Existe um grupo de pesquisadores que defendem a idéia de que basta aumentar a largura de banda, sem fazer qualquer mudança na estratégia de roteamento, que os problemas com a multimídia seriam resolvidos.

• Mudanças na estratégia de roteamento: Um outro grupo de pesquisadores argumentam que devem ser feitas modificações fundamentais na Internet para que as aplicações possam reservar explicitamente uma largura de banda fim a fim.

Eles acham que se um usuário quiser realizar uma chamada telefônica pela Internet do Host A para o Host B, a aplicação de telefone do usuário deverá reservar explicitamente a largura de banda necessária em cada enlace que conecta o Host A ao Host B.


14/63


Para permitir que as aplicações façam as reservas e exigir que a rede honre essas reservas, são necessária algumas grandes mudanças:– Precisa-se de um protocolo que reserve largura de banda dos remetentes e seus

receptores em nome das aplicações;

– Deve-se modificar as regras de programação nas filas dos roteadores, de modo que as reservas de largura de banda possam ser honradas;

Com esta nova política de programação, nem todos os pacotes receberiam tratamento igual, ao invés disso, quem reservar (e pagar) mais, recebe mais.

– Para honrar as reservas, as aplicações devem dar à rede a descrição do tráfego que pretendem enviar para dentro dela. A rede deve, então, regular o tráfego de cada aplicação para assegurar que ela cumpra o que descreveu.

– A rede deve dispor de meios para determinar se tem largura de banda suficiente para suportar qualquer nova solicitação de reserva.

– Esses mecanismos, quando combinados, exigem novos e complexos softwares nos Hosts e roteadores.


15/63


• Serviços diferenciados: Outro grupo de pesquisadores defendem que mudanças relativamente pequenas na rede e nas camadas de transporte e a introdução de esquemas simples de preço e regulagem na borda da rede (entre o usuário e o seu ISP) são suficientes.

A idéia é introduzir um pequeno número de classes (possivelmente apenas duas), atribuir a cada datagrama uma dessas classes, oferecer aos datagramas diferentes níveis de serviço nas filas dos roteadores segundo sua classe, e cobrar dos usuários de acordo com a classe dos pacotes que estão enviando


16/63


• Grande aumento no uso de aplicações de fluxo contínuo.– Custo de armazenamento em disco está decrescendo rapidamente.

– Aumento na quantidade de áudio e vídeo armazenados.

– Melhorias na infra-estrutura da Internet (banda larga doméstica).

– Armazenamento intermediário de vídeo na rede.

– Novos protocolos de Internet orientados à QoS.

– Demanda reprimida por vídeo de alta qualidade.


17/63


• Solicitação de áudio e vídeo comprimidos que residem em servidores.– Servidores Web comum.

– Servidores especiais para fluxo contínuo.

• Etapas para a transferência de áudio/vídeo armazenados:– A solicitação do cliente chega ao servidor.

– Os arquivos de áudio/vídeo são segmentados.

– Cada segmento é encapsulado com cabeçalhos especiais apropriados para o tráfego de áudio/vídeo (protocolo RTP – Real Time Protocol).

– Assim que o cliente começa a receber, em alguns segundos ele começa a reproduzi–lo.

– Se a aplicação oferecer interatividade (pausa, retrocesso, avanço na imagem) será necessário o uso de um outro protocolo (RTSP – Real Time Streaming Protocol).

– Apesar da maioria das requisições ser feita por browsers, a sua reprodução necessita de uma aplicação auxiliar chamada de transdutor.


18/63


• Função dos transdutores:– Descompressão: Áudio e vídeo quase sempre são comprimidos para economizar

espaço de armazenamento em disco e largura de banda de rede. Um transdutor deve descomprimir áudio e vídeo enquanto são reproduzidos.

– Remoção de Variação de Atraso: O transdutor colocará os pacotes recebidos em um buffer durante um curto período de tempo para remover essa variação.

– Correção de erros: Devida à imprevisibilidade do congestionamento na Internet, uma fração de pacotes da corrente de pacotes pode ser perdida. Muitos sistemas tentam recuperar essas perdas:

Reconstruindo os pacotes perdidos por meio da transmissão de pacotes redundantes. Fazendo com que o cliente solicite explicitamente a retransmissão de pacotes perdidos. Mascarando as perdas pela interpolação dos dados que faltam nas mensagens recebidas.

– Interface gráfica de interação: É através desta interface que o usuário irá interagir com o controle de volume, retrocesso, avanço e outros.


19/63


• Com o uso de plug-ins, pode-se inserir a interface gráfica do transdutor dentro da janela do browser Web. Neste caso, o browser apenas reserva o espaço de tela na página corrente e o transdutor fica incumbido de gerenciar o espaço de tela. Independente de onde apareça a imagem, o transdutor está sendo executado separadamente do browser.


20/63


• Como se trata de um servidor Web, o arquivo de áudio/vídeo não passa de um objeto comum como arquivos HTML e JPEG.

• Quando um usuário quer ouvir um arquivo de áudio, o host do usuário estabelece uma conexão TCP com o servidor Web e envia um requisição HTTP para o objeto.

• Ao receber a requisição, o servidor Web anexa o arquivo de áudio a uma mensagem de resposta e devolve a mensagem de resposta à conexão TCP.

• Para o vídeo, isso pode ser um pouco mais delicado, porque as partes de áudio e vídeo podem estar armazenados em arquivos diferentes.

• Neste caso, são feitas duas requisições TCP separadas e os arquivos são enviados em paralelo.

• Cabe ao cliente gerenciar a sincronização das duas correntes.

• Também é possível que o áudio e vídeo estejam intercalados no mesmo arquivo, simplificando a transferência.


21/63


• A figura abaixo ilustra este procedimento:

BrowserWeb

Transdutor

Requisição

Resposta

• Embora a abordagem seja muito simples, ela tem uma desvantagem importante: o transdutor deve interagir com o servidor por intermédio de um browser Web.


22/63


• Esta abordagem traz alguns problemas:– Normalmente, quando o browser é o intermediário, o objeto inteiro precisa ser

transferido antes de o browser passá-lo a uma aplicação auxiliar.

– O atraso resultante antes do início da reprodução é tipicamente inaceitável para clipes de áudio/vídeo de tamanho moderado.

• Uma outra abordagem é realizar a transferência diretamente para o processo transdutor, em outras palavras, é feita uma conexão direta entre o processo servidor e o processo transdutor.

• Esta técnica é feita através de um metarquivo, isto é, um arquivo que fornece informações (por exemplo, URL, tipo de codificação) sobre o arquivo de áudio/vídeo de fluxo contínuo a ser entregue.


23/63


• Neste caso, uma transferência direta entre o servidor e o transdutor segue os seguintes passos:– O usuário clica sobre um hiperlink de um arquivo de áudio/vídeo.

– O hiperlink não aponta diretamente para o arquivo de áudio/vídeo, mas para um metarquivo. O metarquivo contém o URL do arquivo de áudio/vídeo.

– A mensagem de resposta HTTP que encapsula o metarquivo contém uma linha de cabeçalho de tipo de conteúdo que indica a aplicação de áudio/vídeo específica.

– O browser cliente examina a linha de cabeçalho de tipo de conteúdo da mensagem de resposta, lança o transdutor associado e passa todo o corpo da mensagem de resposta (isto é, o metarquivo) para o transdutor.

– O transdutor estabelece uma conexão TCP diretamente com o servidor HTTP e envia uma mensagem de requisição HTML do arquivo de áudio/vídeo pela conexão TCP.

– O arquivo de áudio/vídeo é enviado ao transdutor dentro de uma mensagem de resposta HTTP. O transdutor exibe o arquivo de áudio/vídeo de fluxo contínuo.


24/63



BrowserWeb

Transdutor

Requisição do metarquivo

Resposta do metarquivo

• A importância da etapa intermediária de requisição do metarquivo é clara. Quando o browser vê o tipo de conteúdo para o arquivo, ele pode lançar o transdutor adequado e, dessa maneira, fazer com que o transdutor entre em contato direto com o servidor.

Metarquivo

Resposta áudio/vídeo

Requisição áudio/vídeo


25/63


• Como toda a comunicação é feita em um servidor Web usando HTTP, a transmissão será feita sobre o TCP.

• O HTTP é muitas vezes considerado insuficientemente rico para permitir interação satisfatória do usuário com o servidor, em particular, não é fácil para o HTTP permitir que um usuário envie por meio do transdutor comandos de pausa/reinício, avanço, retrocesso, etc.

• É por isso que muitos fabricantes de produtos multimídia não recomendam esta arquitetura e sim, o uso de um servidor de fluxo contínuo.


26/63


• Com o objetivo de evitar o HTTP e/ou o TCP, áudio e vídeo podem ser armazenados em um servidor de fluxo contínuo e enviados a partir deste ao transdutor.

• Com um servidor de fluxo contínuo, áudio e vídeo podem ser enviados sobre UDP.

• Essa arquitetura exige dois servidores (serviços):– Um dos servidores, o servidor HTTP, serve páginas Web (incluindo os

metarquivos).

– O segundo servidor, o servidor de fluxo contínuo, serve os arquivos de áudio/vídeo.

• Os dois servidores podem rodar no mesmo sistema final ou em dois sistemas finais distintos.

• As etapas dessa arquitetura são semelhantes às descritas para a arquitetura anterior. Contudo, nesse caso o transdutor requisita o arquivo de um servidor de fluxo contínuo, e não de um servidor Web.


27/63



BrowserWeb

Transdutor

Requisição HTTP

Resposta HTTP

Metarquivo

Resposta áudio/vídeo

Requisição áudio/vídeo

Servidor WEB

Servidor deFluxo Contínuo


28/63


• Na arquitetura que acabamos de ver, há muitas opções para a entrega de áudio/vídeo do servidor de fluxo contínuo ao transdutor. Abaixo segue a descrição de três delas.1. O áudio/vídeo é enviado sobre UDP a uma taxa constante igual à taxa de

reprodução do receptor (que é a taxa codificada para áudio/vídeo). Por exemplo, se o áudio for comprimido usando GSM a uma taxa de 13 Kbps, então o servidor transmitirá o arquivo comprimido de áudio a uma taxa de 13 Kbps. Logo que o cliente tenha recebido o áudio/vídeo comprimido da rede, ele o descomprime e o reproduz.

2. É igual à opção 1, mas o transdutor atrasa a reprodução de dois a cinco segundos para eliminar a variação de atraso induzida pela rede. O cliente realiza essa tarefa colocando a mídia comprimida que recebe da rede em um buffer cliente. Assim que o cliente tiver ‘pré-capturado’ alguns poucos segundos de mídia, ele começa a utilizar a informação do buffer. Para essa opção e também para a anterior, a taxa de preenchimento é igual à taxa de saída, exceto quando há perda de pacotes, caso em que a taxa de preenchimento é momentaneamente menor que a taxa de saída.


29/63


3. A mídia é enviada sobre TCP. O servidor lança o arquivo de mídia para dentro da porta TCP o mais rápido possível; o cliente (isto é, o transdutor) lê da porta TCP o mais rápido possível e coloca o vídeo comprimido no buffer do transdutor. Após um atraso inicial de dois a cinco segundos, o transdutor lê, a partir do seu buffer, a uma taxa d e repassa a mídia comprimida para descompressão e reprodução. Como o TCP retransmite pacotes perdidos, ele tem o potencial de fornecer melhor qualidade de som do que o UDP. Por outro lado, a taxa de preenchimento x(t) varia com o tempo devido ao controle de congestionamento e ao controle de fluxo do TCP. De fato, após a perda de pacotes, o controle de congestionamento TCP pode reduzir a taxa instantânea a valores menores do que d por longos períodos de tempo. Isso pode esvaziar o buffer cliente e introduzir indesejáveis pausas na saída de uma corrente de áudio/vídeo no cliente.


30/63


• Para a terceira opção, o comportamento de x(t) vai depender muitíssimo do tamanho do buffer cliente (que não deve ser confundido com o buffer TCP de recepção). Se o buffer for grande o suficiente para conter todo o arquivo de mídia (possivelmente por armazenagem em disco), então o TCP vai fazer uso de toda a largura de banda instantânea disponível para a conexão, de modo que x(t) pode se tornar muito maior do que d. Se x(t) permanecer muito maior do que d por longos períodos de tempo, então uma grande porção da mídia será pré-capturada para dentro do cliente e um subseqüente inanição do cliente será pouco provável. Se, por outro lado, o buffer cliente for pequeno, então x(t) flutuará ao redor da taxa de saída d. O risco de inanição do cliente é maior nesse caso.


31/63


• Muitos usuários de multimídia pela Internet (em especial aqueles que cresceram com um controle remoto de TV na mão) vão querer controlar a reprodução de mídia de taxa constante fazendo pausa na reprodução, reposicionando a reprodução em um ponto de tempo futuro ou passado, avançando ou atrasando a reprodução em modo rápido e assim por diante.

• Essa funcionalidade é semelhante ao que um aparelho de DVD ou Videocassete oferecem ao usuário.

• Para permitir que um usuário controle a reprodução, o transdutor e o servidor precisam de um protocolo para trocar informações de controle de reprodução.

• O RTSP (Real Time Streaming Protocol) é esse protocolo.


32/63


• O que o RTSP não faz!– O RTSP não define esquemas de compressão para áudio e vídeo.

– O RTSP não define como áudio e vídeo são encapsulados em pacotes para transmissão sobre uma rede; o encapsulamento para mídia de fluxo constante pode ser fornecido por RTP ou por um protocolo proprietário.

– O RTSP não restringe o modo como a mídia de fluxo contínuo é transportada; ela pode ser transportada sobre UDP ou TCP.

– O RTSP não restringe o modo como o transdutor armazena o áudio/vídeo. O áudio/vídeo pode ser reproduzido logo que começa a chegar cliente, após um atraso de alguns segundos, ou pode ser descarregado na íntegra antes de ser reproduzido.


33/63


• Qual a finalidade do RTSP?– O RTSP é um protocolo que permite que um transdutor controle a transmissão

de uma corrente de mídia, isto é: pausa, retrocesso, avanço, etc.

– As mensagens RTSP são enviadas através de uma conexão extra à conexão de corrente de dados. Por esse motivo é chamado de protocolo fora da banda.

– As mensagens RTSP podem ser enviadas sobre o TCP ou UDP.


34/63



BrowserWeb

Transdutor

Requisição HTTP

Resposta HTTP

MetarquivoSETUP

ServidorWeb

Servidor deMídia

PLAY

Corrente de Mídia

PAUSE

TEAR DOWN


35/63


• O protocolo IP da Internet presta um serviço de melhor esforço.

• A Internet faz seu melhor esforço para transportar cada datagrama da fonte ao destino o mais rápido possível.

• Contudo, o serviço de melhor esforço nada promete quanto ao atraso fim a fim de um pacote individual, muito menos quanto a variação de atraso em uma corrente de pacotes.

• As aplicações de multimídia interativas em tempo real (telefone e videoconferência) são muito sensíveis ao atraso, à variação de atraso e à perda.

• Existem mecanismos que podem úteis que conseguem preservar a boa qualidade do áudio e do vídeo para que o atraso, variação do atraso e perda não sejam excessivos.

• Utilizaremos uma aplicação de telefone por Internet como exemplo de uso destes mecanismos.


36/63


• Características:– O interlocutor de nossa aplicação de telefone por Internet gera um sinal de áudio

constituído de rajadas de voz alternadas com períodos de silêncio.

– A fim de conservar a largura de banda, nossa aplicação de telefone por Internet gera pacotes somente durante as rajadas de voz.

– Durante uma rajada de voz, o remetente gera bytes a uma taxa de 8 Kbytes por segundo (64 Kbps) e, a cada 20 milissegundos, junta os bytes em porções. Assim, o total de bytes em uma porção é de:

Total de bytes da porção = (20 ms) x (8 Kbytes/s) = 160 bytes.

– Um cabeçalho especial é agregado a cada porção.

– A porção, juntamente com seu cabeçalho, é encapsulada em um datagrama UDP e, em seguida, o datagrama UDP é enviado para dentro da porta da interface.

– Logo, durante uma rajada de voz, um datagrama UDP é enviado a cada 20 milissegundos.


37/63


– Se cada pacote conseguir chegar ao receptor e se tiver um atraso fim a fim pequeno e constante, então um pacote chegará ao receptor periodicamente, a cada 20 milissegundos, durante um rajada de voz.

– Nessas condições ideais, o receptor pode simplesmente reproduzir cada porção assim que ela chega.

– Mas, infelizmente, alguns pacotes podem ser perdidos e a maioria dos pacotes não sofrerá idêntico atraso fim a fim, mesmo quando a Internet estiver apenas levemente congestionada.

– Por essa razão, o receptor deve tomar mais cuidado ao:

1. Determinar quando reproduzir uma rajada;

2. Estabelecer o que fazer com uma porção perdida.


38/63


• Limitações de um serviço de melhor esforço (perdas de pacotes, atraso fim a fim e variação de atraso)– Perdas de pacotes:

Considere um dos segmentos UDP gerados por nossa aplicação de telefone por Internet.

O segmento UDP é encapsulado em um datagrama IP. Enquanto o datagrama vagueia pela rede, ele passa por buffers (isto é, por filas) nos roteadores, para poder alcançar os enlaces de saída.

É possível que um ou mais dos buffers na rota entre o remetente e o destinatário estejam lotados e não possam aceitar o datagrama IP.

Nesse caso, o datagrama IP será descartado e nunca chegará à aplicação receptora.


39/63


– Perdas de pacotes (continuação):

A perda pode ser eliminada enviando os pacotes sobre TCP, em vez de sobre UDP.

Lembre-se de que o TCP retransmite pacotes que não chegam ao destino.

Contudo, os mecanismos de retransmissão freqüentemente são considerados inaceitáveis para aplicações interativas de áudio em tempo real, como o telefone por Internet, porque aumentam o atraso fim a fim.

Além disso, devido ao controle de congestionamento do TCP, após a perda de pacote, a taxa de transmissão pode ser reduzida a uma taxa mais baixa do que a taxa de reprodução no receptor.

Isso pode causar um forte impacto sobre a inteligibilidade da voz no receptor.

Por essas razões, quase todas as aplicações de telefone por Internet existentes rodam sobre UDP e não se preocupam em retransmitir pacotes perdidos.


40/63


– Perdas de pacotes (continuação):

Perder pacotes não é necessariamente tão grave quanto se possa imaginar.

Na verdade, taxas de perda de pacotes entre 1% e 20% podem ser toleradas, dependendo de como a voz é codificada e transmitida e de como a perda é ocultada do receptor.

Por exemplo, o mecanismo de correção de erros de repasse (FEC – forward error correction) pode ajudar a ocultar a perda de pacotes.

Se um ou mais dos enlaces entre o remetente e o receptor estiverem fortemente congestionados e a perda de pacotes exceder 20%, então nada poderá, de fato, ser feito para conseguir uma qualidade de som aceitável.

Assim, fica claro que o serviço de melhor esforço tem sua limitações.


41/63


– Atraso fim a fim:

O atraso fim a fim é o acúmulo de atrasos de processamento de transmissão e de formação de filas nos roteadores, atrasos de propagação e atrasos de processamento nos sistemas finais ao longo do trajeto da fonte ao destino.

Para as aplicações de áudio altamente interativas, como o telefone por Internet, atrasos fim a fim menores do que 150 milissegundos não são percebidos pelo ouvido humano.

Atrasos entre 150 e 400 milissegundos podem ser aceitáveis, mas não são o ideal.

Atrasos que excedem 400 milissegundos podem atrapalhar seriamente a interatividade nas conversações.

O receptor da aplicação de telefone por Internet em geral desconsiderará quaisquer pacotes cujos atrasos ultrapassarem um determinado patamar.

Logo, os pacotes cujos atrasos ultrapassem este patamar são efetivamente perdidos.


42/63


– Variação de Atraso:

Um componente importante do atraso fim a fim são os atrasos aleatórios de fila nos roteadores.

Por causa desses atrasos variáveis dentro da rede, o tempo decorrido entre o momento em que um pacote é gerado na fonte e o momento em que é recebido no destinatário pode variar de pacote para pacote.

Como exemplo, considere dois pacotes consecutivos dentro de uma rajada de voz em nossa aplicação de telefone por Internet.

O remetente envia o segundo pacote 20 milissegundos após ter enviado o primeiro.

Mas, no receptor, o espaçamento entre esses pacotes pode ficar maior do que 20 milissegundos.

Para observar isso, suponha que o primeiro pacote chegue a uma fila de roteador praticamente vazia, mas que, exatamente antes de o segundo pacote chegar à fila, um grande número de pacotes vindos de outras fontes chegue à mesma fila.


43/63


– Variação de Atraso (continuação):

Como o segundo pacote sofre um grande atraso de fila, o primeiro e o segundo pacotes ficam espaçados em mais de 20 milissegundos.

O espaçamento entre pacotes consecutivos também pode ficar menor do que 20 milissegundos.

Para observar isso, considere novamente dois pacotes consecutivos dentro de uma rajada de voz.

Suponha que o primeiro pacote se junte ao final de uma fila com um grande número de pacotes e que o segundo pacote chegue à fila antes dos pacotes da outra fonte.

Nesse caso, nossos dois pacotes se encontram um exatamente atrás do outro na fila.

Se o tempo que leva para transmitir um pacote no roteador de entrada for menor do que 20 milissegundos, então o primeiro e o segundo pacotes ficarão espaçados em menos de 20 milissegundos.


44/63


– Variação de Atraso (continuação):

Se o receptor ignorar a presença de variação de atraso e reproduzir as porções assim que elas chegam, então a qualidade de áudio resultante poderá facilmente se tornar ininteligível no receptor.

Felizmente, a variação de atraso pode, com freqüência, ser removida usando-se números de seqüência, marcas de tempo e atraso de reprodução.


45/63


• Remoção da variação de atraso no receptor de áudio

Para uma aplicação de voz como o telefone por Internet ou o áudio sob demanda, o receptor deve tentar fornecer uma reprodução sincronizada de porções de voz combinando os seguintes mecanismos:– Preceder cada porção com um número de seqüência. O remetente aumenta

em um o número de seqüência para cada um dos pacotes que gera.

– Preceder cada porção com uma marca de tempo. O remetente marca cada porção com o tempo em que ela foi gerada.

– Atrasar a reprodução das porções no receptor. O atraso da reprodução das porções de áudio recebidas deve ser suficientemente longo para que a maioria dos pacotes seja recebida antes de seu tempo de reprodução programado.

Ele pode ser fixado para todo o período de duração de uma conferência ou pode variar de maneira adaptativa durante o período útil da conferência.

Os pacotes que não chegarem antes de seu tempo de reprodução programado serão considerados perdidos e esquecidos.


46/63


– Atraso de reprodução fixo:

Com a estratégia do atraso fixo, o receptor tenta reproduzir cada porção exatamente q milissegundos após a porção ter sido gerada.

Assim, se uma porção tem marca de tempo t, o receptor reproduz a porção no tempo t + q, presumindo que a porção já tenha chegado naquele tempo.

Os pacotes que chegam após seu tempo de reprodução programada são descartados e considerados perdidos.

Qual é uma boa escolha para q?

O telefone por Internet pode suportar atrasos de até cerca de 400 milissegundos, embora com valores menores que q a experiência interativa resultante seja mais satisfatória.

Por outro lado, caso se escolha um q muito menor do que 400 milissegundos, muitos pacotes podem perder seus tempos de reprodução programados devido à variação de atraso induzida pela rede.

Em termos gerais, se grandes variações no atraso também forem pequenas, será preferível usar um q pequeno, talvez menor do que 150 milissegundos.


47/63


– Atraso de reprodução fixo (continuação)

Pacotes

Tempo

Pacotesgerados

Pacotesrecebidos

Reproduçãoperdida

Tempo de reprodução p

Tempo de reprodução p’

rp p’


48/63


– Atraso de reprodução fixo (continuação):

O compromisso entre o atraso de reprodução e a perda de pacotes foi ilustrado na figura anterior.

A figura mostra os tempos em que os pacotes são gerados e reproduzidos para uma única rajada de voz.

Dois atrasos iniciais de reprodução distintos são considerados.

Como mostram os degraus mais à esquerda do gráfico, o remetente gera pacotes a intervalos regulares, digamos, a cada 20 milissegundos.

O primeiro pacote dessa rajada de voz é recebido no tempo r.

Como mostra a figura, as chegadas dos pacotes subseqüentes não são espaçadas regularmente devida à variação de atraso da rede.


49/63


– Atraso de reprodução fixo (continuação):

Para o primeiro esquema de reprodução, o atraso inicial de reprodução está estabelecido em p – r.

Com esse esquema, o quarto pacote não chega dentro de seu atraso de reprodução programado e o receptor o considera perdido.

Pelo segundo esquema de reprodução, o atraso inicial de reprodução fixo está estabelecido em p’ – r.

Por esse esquema, todos os pacotes chegam antes de seu tempo de reprodução e, portanto, não há perda.


50/63


– Atraso de reprodução adaptativo:

O exemplo anterior demonstra um importante compromisso entre atraso e perda que surge ao se projetar uma estratégia de reprodução com atrasos de reprodução fixos.

Ao se decidir por um atraso inicial de reprodução grande, a maioria dos pacotes vai cumprir suas programações e, portanto, haverá perda insignificante;

Contudo, para serviços interativos como o telefone por Internet, atrasos longos podem se tornar incômodos, se não intoleráveis.

Idealmente, gostaríamos que o atraso de reprodução fosse minimizado, mas que mantivesse a limitação de perda abaixo de uns poucos por cento.


51/63


– Atraso de reprodução adaptativo (continuação):

A maneira natural de tratar esse problema é estimar o atraso de rede e a variação de atraso de rede e ajustar o atraso de reprodução de acordo com o resultado, no início de cada rajada de voz.

Esse ajuste adaptativo de atrasos de reprodução no início das rajadas de voz fará com que os períodos de silêncio no receptor sejam comprimidos e alongados;

Contudo, a compressão e o alongamento de silêncio em pequenas quantidades não serão percebidos durante a fala.


52/63


– Recuperação de perda de pacotes:

Como já foi mencionado, a retransmissão de pacotes perdidos não é apropriada para aplicações interativas em tempo real como o telefone por Internet.

Na verdade, a retransmissão do pacote que perdeu seu prazo de reprodução não serve para absolutamente nada.

E a retransmissão de um pacote que transbordou de uma fila de roteador normalmente não pode ser feita com a rapidez necessária.

Devida a essas considerações, as aplicações de telefone por Internet usam, com freqüência, um tipo de esquema de recuperação pró-ativa da perda.

Veremos dois desses esquemas: FEC e Intercalamento.


53/63


– FEC (Forward Error Correction – Correção de Erro de Repasse)

A idéia básica do FEC é adicionar informações redundantes à corrente de pacotes original.

Ao custo de aumentar marginalmente a taxa de transmissão do áudio da corrente, a informação redundante pode ser usada para reconstruir ‘aproximações’ ou versões exatas de alguns pacotes perdidos.

Um exemplo de FEC é enviar uma corrente de áudio de resolução mais baixa como informação redundante.

O remetente pode criar uma corrente de áudio normal e uma corrente de áudio correspondente de qualidade mais baixa.

A corrente de baixa taxa de bits é chamada de corrente redundante.


54/63


– FEC (continuação)

Como mostra a figura a seguir, o remetente constrói o enésimo pacote tomando a enésima porção da corrente normal e anexando a ela a porção anterior da corrente redundante.

Dessa maneira, sempre que houver uma perda de pacote não consecutiva, o receptor pode ocultar a perda reproduzindo a porção de baixa taxa de bits que chega, juntamente com o pacote subseqüente.

É evidente que as porções de baixa taxa de bits conferem qualidade mais baixa do que as porções nominais.

Contudo, uma corrente constituída de uma maioria de porções de alta qualidade, ocasionais porções de baixa qualidade e nenhuma porção perdida oferece, no geral, uma boa qualidade de áudio.


55/63



11 22 33 44

11

11

11

11 22 22 33 33 44

11 22 perdaperda 33 44

22 33 44

Correnteoriginal

Redundância

Correnterecebida

Correntereconstruída


56/63



Note que, nesse esquema, o receptor tem de receber somente dois pacotes antes da reprodução, de modo que o aumento no atraso de reprodução é pequeno.

Além disso, se a codificação de baixa taxa de bits for muito menor do que a codificação nominal, o aumento marginal da taxa de transmissão será pequeno.


57/63


– Intercalamento

Como alternativa à transmissão redundante, uma aplicação de telefone por Internet pode enviar áudio intercalado.

Como mostra a figura a seguir, o remetente rearranja a seqüência das unidade de dados de áudio antes da transmissão, de modo que as unidades originalmente adjacentes fiquem separadas por uma certa distância na corrente transmitida.

O intercalamento pode atenuar o efeito da perda de pacotes. Se, por exemplo, as unidades têm comprimento de 5 milissegundos e as porções são de 20 milissegundos, então a primeira porção pode conter unidades 1, 5, 9, 13; a segunda porção pode conter unidade 2, 6, 10, 14, e assim por diante.

A perda de um único pacote de uma corrente intercalada resulta em múltiplas pequenas lacunas na corrente reconstruída, em vez de em uma única lacuna grande que ocorreria com um sistema não intercalado.


58/63


– Intercalamento (continuação)

Correnteoriginal

Correnteintercalada

Correnterecebida

Correntereconstruída

11 22 33 44 55 66 77 88 99 1010 1111 1212 1313 1414 1515 1616

11 55 99 1313 22 66 1010 1414 33 77 1111 1515 44 88 1212 1616

11 55 99 1313 22 66 1010 1414 perdaperda 44 88 1212 1616

11 22 44 55 66 88 99 1010 1212 1313 1414 1616


59/63


– Intercalamento (continuação)

O intercalamento pode melhorar de modo significativo a qualidade percebida de uma corrente de áudio.

Além disso, o ‘overhead – sobrecarga’ é baixo.

A desvantagem óbvia do intercalamento é que ele aumenta a latência.

Isso limita seu uso em aplicações interativas, como o telefone por Internet, embora possa funcionar bem para fluxo contínuo de áudio armazenado.

Uma importante vantagem do intercalamento é que ele não aumenta as exigências de largura de banda de uma corrente.


60/63

Exercício

1) Em um determinado meio de transmissão, existe uma relação sinal-ruído (S/N) de 20 dB. Qual seria a taxa máxima de transferência possível em bits por segundo considerando que este meio possua uma largura de banda de 5 KHz?

dBNS dB 20)(

Resolução

KHz 5B

?max D

20)(log10 10 NS

2log10 )NS(

210NS

100NS

Usando a Lei de Shannon

)1(log 2max NSBD

)1001(logK5 2max D

)101(logK5 2max D

6,6582K5max D

Kbps 29,33max D


61/63

Exercício

2) Considerando que um determinado meio de transmissão permita que seja transmitida uma taxa de 26,58 Kbps, e que a relação sinal-ruído (S/N) seja de 40 dB, qual é a largura de banda utilizada?

Resolução

40)(log10 10 NS

4log10 )NS(

410NS

000.10NS


)1(log 2max NSBD

Kbps 58,26max D

dBNS dB 40)(

?B)1(log 2

max

NS

DB

)001.10(log

K 58,26

2

B

2878,13

K 58,26B

KHz 2B


62/63

Exercício

3) Quanto tempo será necessário para realizar a transferência de uma informação de 1 Mbyte em uma conexão onde a largura de banda é de 4 KHz e a relação sinal-ruído é de 60 dB?

Resolução

60)(log10 10 NS

6log10 )NS(

610NS

000.000.1NS


)1(log 2max NSBD

Mbyte 1DADOS

KHz 4B

dBNS dB 60)(

?Tempo

)000.000.11(logK4 2max D

)001.000.1(logK4 2max D

19,9315K4max D

Kbps 726,79max D

maxD

DadosTempo

726.79

8220 Tempo

segundos 22,105Tempo

multimídia prof: ricardo gonçalves quintão e-mail: [email protected]

Documents