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

7 - 22

RTSP: Operação

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

Outras informações sobre essa disciplina podem ser obtidas:

http://hostel.ufabc.edu.br/~marcelo.nascimento/

Mais Informações