A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Multimídia Prof: Ricardo Gonçalves Quintão

Apresentações semelhantes


Apresentação em tema: "Multimídia Prof: Ricardo Gonçalves Quintão"— Transcrição da apresentação:

1 Multimídia Prof: Ricardo Gonçalves Quintão

2 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 6/63 Aplicações Multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 7/63 Aplicações Multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 8/63 Aplicações Multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 9/63 Aplicações Multimídia Á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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 10/63 Aplicações Multimídia Á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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 14/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 15/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 16/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 17/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 18/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 19/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 20/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 21/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia A figura abaixo ilustra este procedimento: Browser Web 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 22/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 23/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 24/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia A figura abaixo ilustra este procedimento: Browser Web 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 25/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 26/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 27/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia A figura abaixo ilustra este procedimento: Browser Web Transdutor Requisição HTTP Resposta HTTP Metarquivo Resposta áudio/vídeo Requisição áudio/vídeo Servidor WEB Servidor de Fluxo Contínuo

28 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 28/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 29/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 30/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 31/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 32/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 33/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 34/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia A figura abaixo ilustra este procedimento: Browser Web Transdutor Requisição HTTP Resposta HTTP Metarquivo SETUP Servidor Web Servidor de Mídia PLAY Corrente de Mídia PAUSE TEAR DOWN

35 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 35/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 36/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 37/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 38/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 39/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 40/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 41/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 42/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 43/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 44/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 45/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 46/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 47/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –Atraso de reprodução fixo (continuação) Pacotes Tempo Pacotes gerados Pacotes recebidos Reprodução perdida Tempo de reprodução p r p p

48 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 48/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 49/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 50/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 51/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 52/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 53/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 54/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 55/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –FEC (continuação) perda Corrente original Redundância Corrente recebida Corrente reconstruída

56 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 56/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –FEC (continuação) 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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 57/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 58/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –Intercalamento (continuação) Corrente original Corrente intercalada Corrente recebida Corrente reconstruída perda

59 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 59/63 Como a Internet deveria se desenvolver para dar melhor suporte à multimídia –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 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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? Resolução Usando a Lei de Shannon

61 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 Usando a Lei de Shannon

62 9/3/2014Pós-Graduação em Gerência e Projeto de Redes de Computadores TCP/IP 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 Usando a Lei de Shannon


Carregar ppt "Multimídia Prof: Ricardo Gonçalves Quintão"

Apresentações semelhantes


Anúncios Google