sistemas multim ídia - hostel.ufabc.edu.br
Post on 27-Feb-2022
5 Views
Preview:
TRANSCRIPT
INFINF--207207
Sistemas ComputacionaisSistemas Computacionais
para Processamento Multimpara Processamento Multimíídiadia
SistemasSistemas MultimMultimíídiadiaAulaAula 04 04 –– RedesRedes MultimMultimíídiadia –– ParteParte 11
22°°°°°°°°QQ--20102010
Prof. Roberto Prof. Roberto JacobeJacobe (roberto.jacobe@gmail.com)
Prof. Marcelo Z. do Prof. Marcelo Z. do NascimentoNascimento ((marcelo.ufabc@gmail.com)
Roteiro
• Aplicações de rede multimídia
• Transmissão em fluxo contínuo de áudio e vídeo
armazenados
• Protocolos para aplicações interativas em tempo real:
• RTP
• RTCP
• Leitura Sugerida
• Aplicações multimídia: áudio e vídeoem rede (“mídia contínua”)
• Fatores como temporização(sensíveis aoatraso) e tolerância a perda.
QoS
rede provê aplicações com nível de desempenhonecessário para o funcionamento da aplicação.
Aplicações de rede multimídia
As Classes de aplicações multimídia:
1) Transmissão em fluxo contínuo de áudio e vídeoarmazenados.
• Exemplo: Palestras, filmes de longa duração, videoclipes
2) Transmissão em fluxo contínuo de áudio e vídeo ao vivo• Exemplo: Emissora de rádio
3) Áudio e vídeo interativos em tempo real• Exemplo: NetMeeting da Microsoft
Jitter é a variação de atrasos dos pacotes dentrodo mesmo fluxo de pacotes
Aplicações de Redes Multimídia
Características fundamentais em multimídia:
•Se a aplicação é:• Tipicamente sensível a atraso
• Atraso fim-a-fim• Jitter do atraso
• Mas é tolerante a perdas: perdas infreqüentes causam
interrupções aleatórias menores na recepção de áudio e vídeo
• Em aplicações eláticas (web, email, telnet), atrasoslognos são incômodos, mas não prejudiciais e a integridade dos dados são de suma importância
Aplicações de Redes Multimídia
• Clientes requisitam sobre demanda arquivos que estão armazenados em servidores
• Essa transmissão em fluxo contínuo tem características:
• Mídia armazenada na origem (funções => pausa, voltar)
• Transmitida para o cliente• Fluxo contínuo: cliente começa a reprodução antes que todos os dados tenham chegado• Usa aplicações => RealPlayer, QuickTime, etc.
• Confinamento de tempo para os dados que ainda serão transmitidos:• Em tempo para a reprodução.
Transmissão em fluxo contínuode multimídia armazenada
Vídeogravado
2. Vídeoenviado
3. Vídeo recebido,executado no cliente
dado
s cu
mulativos
Fluxo contínuo: o clienteexecuta a parte inicial do vídeo, enquanto o servidor ainda está enviandosua parte final
atrasoda rede
tempo
Transmissão em fluxo contínuode multimídia armazenada:
Aplicações: telefonia IP, videoconferência e mundos interativos distribuídos
• Permite que utilizem áudio e vídeo para comunicação entre si em tempo real;
•Requisitos de atraso fim-a-fim:• Áudio: < 150 mseg bom e < 400 mseg aceitáveis• Inclui atrasos do nível de aplicação (empacotamento) e da estrutura de rede
• Atrasos maiores notáveis, danificam a interatividade
•Inicialização da sessão• Na comunicação: endereço IP, número de porta, algoritmos de codificação:
• TCP/UDP/IP: “serviço de melhor esforço” => nenhumagarantia contra atrasos e perdas
Multimídia interativa emtempo real
Filosofia de serviços integrados: • Mudanças fundamentais na Internet para que as aplicações
possam fazer reserva de banda fim-a-fim;
• Requer softwares novos e complexos em hosts e roteadores;
Não intervenção• Sem maiores mudanças;
• Maior largura de banda quando necessário;
• Distribuição de conteúdo => multicast em nível de aplicação;
• Camada de aplicação.
A evolução da Internet parasuporte adequado a multimídia?
Filosofia de serviços diferenciados:
•Se houvesse uma definição de classes de serviços:
• Roteadores antendesse pacotes de classe (prioridade)
• Poucas mudanças na infra-estrutura da Internet ainda
provêem serviços de 1a e 2a classes
• Quais mecanismos temos para trabalhar:
• Enviar áudio e vídeo com UDP e/ou retardo de reprodução
Qual é a sua opinião?
A evolução da Internet parasuporte adequado a multimídia?
•Áudio ou vídeo armazenado em arquivo => é devem ser segmentados e os segmentos devem ser encapsulados com cabeçalhos especiais apropriado para trafego de áudio e vídeo – RTP (protocolo de tempo real)
• Se houver interatividade com usuário => saltos, avanço, rebobinação => RTSP (protocolo de fluxo contínuo em tempo real);
•Usa uma aplicação auxiliar (usuário)-> transdutor• Estabelece-se uma conexão TCP
•Mensagem: Arquivos transferidos como objeto HTTP• Recebidos por inteiro no cliente• Então iniciam a execução!
Multimídia da Internet: abordagem mais simples
•O transdutor interage com o servidor por meio do browser
•Áudio e vídeo sem fluxo contínuo:
•Longos atrasos até a reprodução!
•Problema:•Deve descarrega-lo antes de passar para aplicação auxiliar;
•Isso é inaceitável para clipes de áudio/vídeo de tamanho moderado
Multimídia da Internet: abordagem mais simples
• Para fluxo contínuo ocorrer => deve ser estabelecido um conexão direta entre processo servidor e o processo transdutor
• O browser obtém (GET) => o metarquivo• Aciona o player => passando o metarquivo.• O player contata o servidor.
• O servidor transmite em fluxo contínuo=> o áudio/vídeo para o player
• Nem sempre é uma boa solução, pois o transdutor a se comunicar com o servidor por HTTP, e portanto, também por TCP.
• Complexo trabalhar com HTTP enviar comando de pausa/reinício e salto temporal.
Multimídia da Internet: fluxo contínuo
•Uso de uma aplicação auxiliar:
•Necessidade de 2 servidores: 1 para páginas e outro para fluxo contínuo;
•Esta arquitetura permite protocolo não HTTP entre o servidor e o media player;
• Também pode usar UDP em vez de TCP;
Multimídia : abordagem de fluxo contínuo
Transmissão devídeo em taxa
constante de bit
dado
s cu
mul
ativ
os
tempo
Atrasode redevariável
Recepção devídeo no cliente
Reprodução no clienteem taxa constantede bit
Atraso dereprodução no
clienteví
deo
embu
ffer
• Um buffer é usado para armazenar a mídia;• Atraso de 2 a 5 segundos para eliminar variação de atraso induzido pela rede;
• Após pré-capturar algum pouco segundos, começa a descarregar.
Fluxo contínuo : buffer no cliente
• Taxa de preenchimento x(t) = taxa de saída d, exceto perda de pacote que x(t) é momentaneamente menor que d
Fluxo contínuo : buffer no cliente
UDP • Servidor envia na taxa apropriada para o cliente (indiferente aocongestionamento da rede) – define-se o tamanho• Taxa de envio frequente = taxa de codificação = taxa constante• Então, taxa de chegada = taxa constante — perda de pacotes
• Pequeno atraso de reprodução (entre 2~5 s) para compensar o atraso de jitter da rede.
TCP• Envia na máxima taxa possível sobre TCP• Taxa de chegada flutua devido ao controle do congestionamento do TCP
• Maior atraso de execução: suaviza a taxa de entrega do TCP
Fluxo contínuo de multimídia: UDP ou TCP?
RTSP: RFC 2326• Protocolo da camada de aplicação cliente-servidor• Permite ao usuário controlar a apresentação: voltar ao início, avançar, parar, continuar etc. …
O que ele não faz:• Não define como o áudio e o vídeo são encapsulados paratransmissão sobre a rede
• Não restringe como a mídia contínua é transportada: pode usarUDP ou TCP
• Não especifica como o receptor armazena o áudio e o vídeo
Controle de usuário no fluxocontínuo de mídia: RTSP
• O RTSP permite de o transdutor controle a transmissão de uma corrente de mídia:
• Um arquivo é transferido sobre um canal• Informação de controle (mudanças de diretório, remoção de arquivos, etc.) é enviada sobre uma conexão TCP separada
• Os canais “dentro da banda” e “fora da banda” usam diferentesnúmeros de portas
• Mensagens RTSP também são enviadas “fora da banda”:• As mensagens de controle RTSP usam diferentes números de portasem relação ao fluxo de dados de mídia contínua, e, portanto, sãoenviados “fora da banda”
• Usa a porta 554• O fluxo contínuo de mídia é considerado “dentro da banda”
RTSP: controle fora da banda
Cenário:• Metarquivo comunicado ao browser Web• Browser aciona o player• Player estabelece uma conexão de controle RTSP, conexão de dados ao servidor de fluxo contínuo
RTSP: exemplo
Servidor web
Servidor de mídia
Browser
Transdutor
HTTP GET
Setup
Play
Arquivo de descrição da apresentação
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
<track type="vídeo/jpeg"
src="rtsp://vídeo.example.com/twister/vídeo">
Exemplo de metarquivo
Exemplo de troca RTSP
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=0-
C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
Multimídia interativa: telefoniaInternet
Exemplo: telefonia Internet
•Transmissor=>Áudio alterna períodos de fala e períodosde silêncio;
• 64 kbps durante o intervalo de atividade
•Pacotes são gerados apenas durante períodos de fala:• Blocos de 20 mseg a 8 Kbytes/s => 160 bytes
• Um cabeçalho da camada de aplicação é adicionado a cada bloco
•O Bloco e ocabeçalhos encapsulados dentro do segmentoUDP
• Aplicação envia o segmento UDP para o socket a cada20 mseg durante o intervalo de tempo.
Perda de pacotes e atrasos
•Perda pela rede:• O datagrama IP é perdido devido ao congestionamentoda rede (sobrecarga do buffer do roteador)
•Perda por atraso:• O datagrama IP chega muito atrasado para a reproduçãono receptor
• Atrasos: processamento, fila na rede; atrasos no sistemafinal (transmissor, receptor)
• Máxima tolerância de atraso: 400 ms
•Tolerância de perda: • dependendo da codificação de voz, as perdas ficam ocultas,
taxas de perda de pacotes entre 1% e 10% podem ser toleradas
Transmissão emtaxa de bitconstante
dado
s cu
mul
ativ
os
tempo
Atrasovariávelda rede(jitter)
Recepçãono cliente
Reprodução no clienteem taxa de bitconstante
Atraso dereprodução no
clienteD
ado
s n
ob
uffe
r
• Considere os atrasos fim-a-fim de dois pacotes consecutivos: diferença pode ser mais ou menos do que 20 mseg, mas roteadorese caminhos podem influenciar a entrega
Perda de pacotes e atrasos
Recuperação de perdas de pacotes
Correção de erro de envio (FEC): esquema simples
• Para cada grupo de n blocos, cria-se um blocoredundante realizando uma operação OU exclusivoentre os n blocos originais
• Envia os n + 1 blocos aumentando a banda passante porum fator de 1/n
• Pode reconstruir os n blocos originais se houver no máximo um bloco perdido nos n+1 blocos enviados
• Atraso de reprodução precisa ser definido parareceber todos os n + 1 pacotes
• 2o esquema FEC• Enviar um fluxo demenor qualidade como“carona”
• Envia fluxo de áudiode menor resolução comoa informação redundante
• Por exemplo, um fluxoPCM nominal a 64 kbpse um fluxo GSM redun-dante a 13 kbps
• Sempre que ocorre perda não consecutiva, o receptor pode escondera perda
• Pode também anexar os blocos (n — 1) e (n — 2) do fluxo de baixaqualidade
Recuperação de perdas de pacotes
Protocolo de tempo real (RTP)
•RTP especifica uma estrutura de pacotes quetransportam dados de áudio e vídeo:
•RFC 1889
•Pacote RTP oferece:• Identificação do tipo de carga• Numeração da seqüência de pacotes• Marcas de tempo
• RTP roda nos sistemas terminais.• Os pacotes RTP são encapsulados em segmentos UDP
•Interoperabilidade: •Se duas aplicações de telefonia IP usam RTP, então elas podemser capazes de trabalhar juntas
RTP roda em cima do UDP
As bibliotecas do RTP fornecem uma interface de camada de transporte que estendem o UDP:
• Número de portas, endereços IP• Identificação do tipo de carga• Numeração da seqüência de pacotes• Marcas de tempo
RTP: Exemplo
• Considere enviar 64 kbps de voz codificada em PCM sobre RTP;
•A aplicação reúne dados codificados em blocos:•Exemplo: 20 ms = 160 bytes por bloco
• O bloco de áudio, junto com o cabeçalho RTP, forma o pacote RTP, que é encapsulado num segmento UDP;
•O cabeçalho RTP indica o tipo de codificação de áudioem cada pacote
• Os transmissores podem mudar a codificação durante a conferência
• O cabeçalho RTP também contém os números de seqüência e marcas de tempo.
RTP e QoS
•RTP não fornece nenhum mecanismo:
• Assegurar a entrega dos pacotes
• Dados no tempo correto
• Fornece garantias de qualidade de serviço
•O encapsulamento RTP => apenas tratado nos sistemasfinais;
• Equipamamentos de camada 1, 2 e 3 não entendem
•Roteadores fornecem o serviço de melhor esforço daInternet. • Não fazem nenhum esforço especial para assegurar que os
pacotes RTP cheguem ao destino
Cabeçalho RTP
Tipo de carga (7 bits): utilizado para indicar o tipo de codificação:
• Tipo de carga 0: PCM mu-law, 64 kbps• Tipo de carga 3, GSM, 13 kbps• Tipo de carga 7, LPC, 2.4 kbps• Tipo de carga 26, Motion JPEG• Tipo de carga 31. H.261• Tipo de carga 33, MPEG2 vídeo
Número de seqüência (16 bits): O número de sequência éincrementado de um a cada pacote RTP enviado; pode ser usado paradetectar perdas de pacotes e para recuperar a seqüência de pacotes.
Cabeçalho RTP
Cabeçalho RTP
• Timestamp field (32 bytes long). Reflete o instante de amostragem
do primeiro byte no pacote de dados RTP
• Para áudio, o relógio de marca de tempo incrementa de um a cada
intervalo de amostragem (por exemplo, cada 125 us para uma taxa
de amostagem de 8 KHz)
• Campo SSRC (32 bits). Identifica a fonte do fluxo RTP. Cada fluxo
numa sessão RTP deve ter um SSRC distinto
Real-Time Control Protocol (RTCP)
• Trabalha em conjunto com o RTP• Cada participante de uma sessão RTP transmite
periodicamente pacotes de controle RTCP para todos os outrosparticipantes.
•Cada pacote RTCP contém relatórios do transmissor e/oudo receptor => Estatísticas são úteis para a aplicação;
• As estatísticas incluem o número de pacotes enviados, o número de pacotes perdidos, a variação de atraso entrechegadas etc.
•Esta informação pode ser usada para controle do desempenho e para fins de diagnóstico
•O transmissor pode mudar suas transmissões com base nestas informações de realimentação
RTCP•Para uma sessão RTP, existetipicamente um único endereço de multicast;
•Os pertencentes à sessão usameste endereço de multicast
• Os pacotes RTP e RTCP sãodistintos um dos outros pelo uso de números de portas diferentes
• Para limitar o tráfego, cadaparticipante reduz seu tráfegoRTCP quando o número de participantes da conferênciaaumenta
Pacotes RTCPPacotes de relatório do receptor:• Fração de pacotes perdidos, último número de seqüência, variância média do atraso entre chegadas
Pacotes de relatório do transmissor: • SSRC do fluxo RTP, o tempo corrente, o número de pacotes enviados e o número de bytes enviados
Pacotes de descrição da fonte: • Endereço de e-mail do transmissor, o nome do transmissor, o SSRC do fluxo RTP associado
• Fornecem um mapeamento entre o SSRC e o nome do usuário ou do hospedeiro
Sincronização de fluxos
•Pode ser aplicado na sincronização de diferentes fluxosde mídia numa sessão RTP:
•Videoconferência => cada transmissor gera um fluxo RTP paraáudio e um para vídeo
•As marcas de tempo nesses pacotes são vinculadas aos relógiosde amostragem de vídeo e de áudio;
•Cada pacote relatório do transmissor RTCP contém (para o último pacote gerado no fluxo RTP associado):
•Marca de tempo do pacote RTP=> instante de tempo real no qual o pacote foi criado
• Então, os receptores podem usar esta associação parasincronizar a reprodução de áudio e de vídeo
Controle de Banda do RTCP
• O RTCP procura limitar seu tráfego a 5% da banda passante da sessão
Exemplo
•Um transmissor enviando vídeo com uma taxa de 2 Mbps.
•O RTCP procura limitar seu tráfego a 100 kbps
Controle de Banda do RTCP
•RTCP dá 75% dessa taxa para os receptores e 25% do restante para o transmissor
•Os 75 kbps dedicados aos receptores são divididos de forma igual entre os receptores: •Com R receptores=> cada receptor consegue enviar tráfego RTCP a uma taxa de 75/R kbps •Transmissor envia tráfego RTCP a uma taxa de 25 kbps
• Um participante determina o período de transmissão de pacotes RTCP dinamicamente calculando o tamanho médio do pacote e dividindo o tamanho médio do pacote RTCP pela sua taxa alocada
Roteiro
• Aplicações de rede multimídia
• Transmissão em fluxo contínuo de áudio e vídeo
armazenados
• Protocolos para aplicações interativas em tempo real:
• RTP,
• RTCP
• Computer Networking, A Top-Down Featuring the Internet by James F.Kurose & Keith W.Ross.
Leitura Sugerida
top related