Protocolos Multimídia na Internet

(1)

©  Adriano Mauro Cansian

Parte 1 - Conceitos

Redes de Computadores II

Tópicos em Sistemas de Computação

Prof. Dr. Adriano Mauro Cansian [email protected]

unesp - IBILCE - SJRP

Multimídia na Internet (1)

Objetivos:

q Entender os requisitos de serviço para redes com

multimídia •  Atraso.

•  Taxa de transmissão.

•  Perda.

q Aprender sobre aproveitamento máximo do serviço

de melhor esforço da Internet.

(2)

Multimídia na Internet (2)

Veremos:

q Aplicações de rede com multimídia.

q Áudio e vídeo de tempo contínuo armazenados

•  RTSP.

q Aplicações interativas de tempo-real

•  Telefonia na Internet.

q RTP

q H.323 e SIP

3

©  Adriano Mauro Cansian ₄

Características Fundamentais:

1. 

Sensíveis ao atraso.

2. 

Tolerante a perdas

.

•  Perdas ocasionais podem passar desapercebidas.

Multimídia é antítese dos dados binários:

•  Programas, arquivos binários, informações bancárias,

bancos de dados, e outros: não toleram falhas, mas aceitam atrasos.

“mídia de tempo contínuo”. q Existem diferentes tipos de mídias.

(3)

©  Adriano Mauro Cansian ₅

•  Áudio e vídeo de tempo contínuo, armazenados. 2. 

Fluxo contínuo

•  Áudio e vídeo de tempo contínuo, ao vivo.

3. 

Tempo real interativo

•  Vídeo e/ou áudio interativo em tempo real.

Veremos as características de cada uma, a seguir…

©  Adriano Mauro Cansian ₆

1. Mídia armazenada –

on demand

(1)

q  Clientes solicitam arquivos de áudio e vídeo.

•  Armazenados em servidores específicos ou em cloud.

q 

Características:

• Interação ou comando:

•  O usuário pode controlar a operação do player:

pause, resume, fast forward, rewind, etc...

• Atraso de início aceitável:

•  Desde a requisição do cliente até o início da apresentação pode ser de 1 a 10 segundos.

(4)

©  Adriano Mauro Cansian ₇

2. Fluxo contínuo – tempo real

q Em tempo real, unidirecional (broadcast).

•  Similar à TV convencional.

•  Não interativo: apenas para ouvir e ver.

q Atrasos de até 10 segundos para começar a

reprodução são bem aceitos.

q Exemplos:

•  Rádios (RoIP) e TVs (IPTV) via Internet. •  Vários “canais” disponíveis em todo o mundo.

©  Adriano Mauro Cansian ₈

3. Tempo real interativo - Videoconf

q  Fluxo bidirecional de áudio ou de vídeo.

•  Conferência entre duas ou mais pessoas.

q  Mais exigente nos requisitos de atraso devido à

necessidade de interatividade em tempo real.

q  Vídeo:

•  Atraso < 150 ms é aceitável

q  Áudio:

•  Atraso < 150 ms é bom.

•  Atraso entre 150 e 400 ms é aceitável.

q  Exemplos:

•  Skype, Gizmo, Viber, Facetime, diversos aplicativos em redes

sociais, dentre vários outros.

(5)

Obstáculos e desafios

9

©  Adriano Mauro Cansian ₁₀

Obstáculos e desafios para multimídia em redes (1)

q Arquitetura IP não garante nada:

•  É melhor esforço (best effort).

•  Sem garantias sobre o atraso ou variação de atraso.

•  Por outro lado: aplicações Interativas em tempo real têm requisitos rígidos para atraso de pacotes e jitter.

Jitter é a

variação

do atraso de pacotes,

dentro de um mesmo fluxo de pacotes.

q 

Aplicações de tempo contínuo com atrasos

iniciais de

5 a 10 seg

são comuns.

•  Mas o desempenho deteriora se os enlaces estão congestionados ou muito distantes.

(6)

©  Adriano Mauro Cansian ₁₁

Obstáculos e desafios para multimídia em redes (2)

q O projeto de aplicações multimídia seria mais

simples se houvesse várias classes de serviço. •  Mas, na Internet pública, todos os pacotes recebem

igual tratamento.

•  Pacotes contendo áudio e vídeo interativo de tempo real permanecem nas filas, assim como todos os demais.

q Esforços estão sendo desenvolvidos para prover serviços diferenciados.

•  IPv6 é uma boa opção, mas ainda não necessariamente

disseminado.

©  Adriano Mauro Cansian ₁₂

Aproveitando ao máximo o “melhor esforço”

q  Para reduzir o impacto do serviço de melhor esforço da Internet, é possível:

•  Usar UDP e evitar o TCP com sua fase de partida lenta. •  Armazenar o conteúdo (todo ou em parte) no cliente, e

controlar a apresentação para atenuar o jitter.

•  Acrescentar marcas de tempo nos pacotes, para que o

receptor saiba quando reproduzi-los.

•  Adaptar a compressão à banda de transmissão disponível. •  Transmitir pacotes redundantes para atenuar os efeitos

das perdas de pacotes.

•  Usar todos estes “truques” associados a Cloud.

(7)

suportar melhor as aplicações

multimídia?

Serviços Integrados

&

Serviços Diferenciados

13 unesp - IBILCE - SJRP

©  Adriano Mauro Cansian ₁₄

Filosofia de serviços Integrados:

q Mudar os protocolos da Internet, de forma que as

aplicações possam reservar uma banda de

transmissão fim-a-fim:

•  Necessita de um novo protocolo de rede (IPv6 ?)

•  Modificar as regras de escalonamento nos roteadores. •  Aplicação deveria fornecer à rede uma descrição do

seu tráfego.

q Exige softwares novos e complexos nos hosts e

(8)

©  Adriano Mauro Cansian ₁₅

Filosofia de serviços Diferenciados:

Exige mudanças menores na Internet. •  Datagramas podem ser marcados.

•  Definir serviços de primeira e de segunda classe.

•  Serviços “Platinun” e “Gold”

q  Usuários à poderiam pagar mais para enviar e receber datagramas de primeira classe.

q  ISPs à poderiam pagar mais aos provedores de

backbone para enviar e receber pacotes de primeira classe. •  Novas oportunidades de negócios.

q Problema: lembrar de neutralidade da rede.

•  Marco civil da Internet (2014)

(Voltaremos a serviços diferenciados e integrados mais adiante neste tópico)

©  Adriano Mauro Cansian ₁₆

Codificação e Compressão de

áudio e vídeo

(9)

©  Adriano Mauro Cansian ₁₇

transmissão de textos e imagens estáticas.

•  Para ser transmitido com qualidade de cinema,

sem compressão, um vídeo exigiria 160 Mbps

de banda.

•  Um áudiocom qualidade de CD, sem

compressão, exigiria cerca de 2,8 Mbps.

©  Adriano Mauro Cansian ₁₈

Codificação e exigências de banda

q No estágio tecnológico atual, usuários de “banda

larga” trabalham na maioria de 2 a 10 Mbps no usuário final.

q 

Ou seja, no caso de vídeo, 15 vezes mais

lentos do que seria necessário para uma

perfeita transmissão

•  Portanto, outra solução deve ser adotada.

Obviamente, não se transmite na Internet

sem compressão.

(10)

©  Adriano Mauro Cansian ₁₉

Codificação e

CODECs

q Transmissões de vídeo, pela internet, só são

possíveis graças a dispositivos denominados

codecs.

•  Coder-decoderà codificador-decodificador.

•  São módulos que comprimem arquivos de áudio e vídeo.

•  Permite usar velocidades “lentas” da rede no usuário final.

q Imagens usam vários tipos de codecs.

•  Cada um dos quais otimizado para dado tipo de mídia.

q Todos têm perdas.

©  Adriano Mauro Cansian ₂₀

CODECs e a qualidade de áudio

q A maior parte dos codecs de áudio para a internet:

•  Têm as taxas de compressão baseadas na frequência de

amostragem, e no número de canais.

•  A qualidade é afetada pela “frequência de amostragem”. •  Veremos adiante sobre frequência de amostragem.

q Placas áudio à maioria captura a 44,1 KHz,

•  Ou seja, com qualidade de CD.

•  Qualidade ótima, mas muito elevada para a internet. •  Por isso, é normal baixar a frequência para 22,05 KHz. •  Se o objetivo for apenas transmitir voz, pode-se abaixar a

(11)

Vejamos como transformar áudio

analógico em sinal digital

Codificação PCM e evolução

21

©  Adriano Mauro Cansian ₂₂

Codificação PCM (1)

q 

Transformando áudio analógico em digital:

Pulse Code Modulation

(PCM)

1º - O sinal analógico de áudio é

amostrado

a

alguma taxa fixa.

Por exemplo: 8.000 amostras / segundo.

•  Valor de cada amostra é um número real

(12)

©  Adriano Mauro Cansian ₂₃

Codificação PCM (2)

Pulse Code Modulation – Transformando áudio analógico em digital

2º - Cada uma das amostras é então

“

arredondada

” para um valor qualquer

dentre um número finito de valores.

• 

Essa operação é chamada de

“

quantização

”.

• 

Tipicamente é uma potência de 2.

•  Por exemplo: usa-se 256 valores de quantização.

(Na figura a seguir o processo fica mais claro)︎

©  Adriano Mauro Cansian ₂₄

(13)

Figura extraída de http://www.qsl.net/py4zbz/teoria/quantiz.htm

©  Adriano Mauro Cansian ₂₆

•  O eixo vertical (Y) da figura é graduado no valor das amostras quantizadas com 8 bits : 0 a 255.

•  O eixo 0 Volts, é deslocado (off-set) para 128 : para representar valores

negativos de -1 até -128, com 127 até 0 respectivamente, sem necessidade de sinal (+/-).

•  A forma de onda quantizada acima, no formato decimal é :

118, 135, 130, 138, 151, 165, 179, 179, 182, 195, 179, 144, 109, 78, 51, 37, 39, 62, 97, 123.

O que representa os seguintes valores quantizados de tensão (em V), supondo deltaVmax=255 V.

-10,+7,+2,+10,+23,+37,+51,+51,+54,+67,+51,+16,-19,-50,-77,-91,-89,-66,-31,-5 . Figura extraída de http://www.qsl.net/py4zbz/teoria/digitaliz.htm

(14)

©  Adriano Mauro Cansian ₂₇

Codificação PCM (3)

3º. Cada um dos valores de quantização é

representado por um número fixo de bits.

•  Por exemplo, se houver 256 valores de

quantização, então cada valor (cada amostra) será representado por 1 byte.

Valor Quantização Representação. Binária

1 00000000 2 00000001 3 00000011 … … … … 256 11111111 unesp - IBILCE - SJRP

©  Adriano Mauro Cansian ₂₈

Codificação PCM (4)

q 

Cada amostra é convertida para sua

representação por bits

.

q 

Em seguida: as representações por bits de

todas as amostras formam a representação

digital do sinal.

(15)

©  Adriano Mauro Cansian ₂₉

Figura extraída de http://www.qsl.net/py4zbz/teoria/quantiz.htm (05/01/15)

©  Adriano Mauro Cansian ₃₀

Exemplo de PCM (1)

q 

Assim, se um sinal de áudio for

amostrado a uma taxa de

8.000 amostras / seg.

•  Se cada amostra representada por 8 bits:

•  O sinal digital resultante terá uma taxa digital de:

•  8.000 amostra/seg x 8 bits = 64.000 bits / seg.

q 

Depois é reconvertido (

decodificado

) em

um sinal analógico, para gerar áudio

novamente.

(16)

©  Adriano Mauro Cansian ₃₁

Exemplo de PCM (2)

q Uma codificação de voz usando PCM, com taxa de 8.000 amostras por segundo e 8 bits de amostra:

resulta numa taxa digital de 64 Kbps.

q CD de áudio também usa PCM.

q  Arquivos ”wave” de CDs são codificados por PCM.

q Mas usam taxa de amostragem de 44.100 amostras por segundo (44,1 KHz) e 16 bits por amostra: •  705,6 Kbps para mono.

•  1,4 Mbps para estéreo →muito alto !

•  Por esta razão, voz e música codificadas em PCM raramente

são usadas na Internet.

©  Adriano Mauro Cansian ₃₂

Compressão de áudio (1)

q 

Na Internet: ao invés de PCM, utiliza-se

técnicas de compressão para reduzir a

taxa de bits.

•  GSM à usa 13 Kbps. •  G.729 à usa 8 Kbps. •  G.723.3 à 6,4 e 5,3 Kbps.

•  Além de um grande número de técnicas

(17)

©  Adriano Mauro Cansian ₃₃

•  Popularmente chamada de “MP3”.

•  Taxa de bits comprimida para 128 ou 96 Kbps. •  Baixa degradação de áudio.

q Princípio de funcionamento do MP3:

•  Achar e eliminar todos os sinais redundantes e

irrelevantes, que não sejam audíveis.

•  Geralmente aplicado sobre uma codificação PCM.

q MP3 é um padrão MUITO complexo.

©  Adriano Mauro Cansian ₃₄

MP3

q 

Algoritmo de compactação do MP3 elimina

frequências muito altas, acima dos

20kHz.

•  Que não são audíveis pelo ouvido humano, e

que estão presentes numa codificação PCM.

•  Economiza-se muitos bytes.

q 

A técnica usada pelo MP3 é denominada

(18)

©  Adriano Mauro Cansian ₃₅

MP3 e Perceptual Noise Shaping

q  Conjunto de filtros extrai pequenas amostras do sinal.

•  E, através do algoritmo de compactação, gera um novo sinal

diferente deste original.

•  Novo sinal é “menor” em termos de amostras, mas que soa

aos nossos ouvidos como muito semelhante ao original. q  Na música, se duas frequências muito próximas soam ao

mesmo tempo, o ouvido somente ouvirá a mais forte.

q  Ou seja, o mp3 simplesmente diminui o número de bits desse sinal mais fraco e mantém os bits do sinal mais forte.

q  Diminuindo assim o tamanho final do arquivo PCM na proporção 12:1, mantendo uma qualidade semelhante ao CD, eliminando as redundâncias.

©  Adriano Mauro Cansian ₃₆

Aprofundamento de MP3

q 

http://www.mp3-tech.org

q 

http://www.iis.fraunhofer.de

q 

http://pt.wikipedia.org/wiki/MP3

(19)

©  Adriano Mauro Cansian ₃₇

Vídeos na Internet

©  Adriano Mauro Cansian ₃₈

Vídeos na Internet (1)

q 

O olho humano é

sensível

a imagens de

frequência inferior a 16 fps.

•  Ou seja: se for mais devagar do que 16 fps, o

olho percebe a passagem de um frame para outro.

(20)

©  Adriano Mauro Cansian ₃₉

Vídeos na Internet (2)

q 

Vídeos para internet podem ser

transmitidos numa

fração da sua

frequência original

.

• 

Por exemplo:

•  vídeos capturados a 30 fps podem ser transmitidos a 30, 15, 10, 7.5, 6 e 5 fps.

– Se inferior a 16 fps percebe-se transição (saltos) nos frames.

•  Padrão cinema, as frequências serão de 24

fps, e pode-se utilizar 24, 12, 8, 6 e 4 fps, na transmissão.

©  Adriano Mauro Cansian ₄₀

Compressão de vídeo

q Os padrões de compressão MPEG são os mais

populares.

•  Derivados da compressão de imagens JPEG.

q MPEG1: para vídeos com qualidade média.

•  Necessidade de banda: 1,5 Mbps

q MPEG2: para vídeos DVD de alta qualidade.

•  Necessidade de banda: 3 a 6 Mbps

q MPEG4: compressão de vídeo orientada a objeto.

(21)

©  Adriano Mauro Cansian ₄₁

Fluxo contínuo de áudio e

vídeo armazenados

©  Adriano Mauro Cansian ₄₂

Transdutor ou player

q Conceito de Player ou “Transdutor de Mídia”:

q Software com funções específicas:

•  Remove jitter. •  Descomprime.

•  Faz correção de erros.

•  Tem interface gráfica de usuário para interatividade.

q 

Plug-ins podem ser usados para embutir o

transdutor de mídia num browser.

•  Ou podem funcionar independentemente.

(22)

q  Armazenamento em servidores Web: “abordagem ingênua”.

•  Browser pede o arquivo com uma mensagem http-request.

•  Servidor Web envia o arquivo na mensagem http-response.

•  O cabeçalho “content-type” do http indica uma codificação apropriada

para áudio e vídeo.

•  Browser chama o transdutor de mídia, e entrega o arquivo para ele.

•  Transdutor de mídia

apresenta o arquivo.

•  Mas há Problemas…

43

Vídeo

on-demand

em servidores Web (1)

©  Adriano Mauro Cansian ₄₄

Vídeo

on-demand

em servidores Web (2)

•  Maior problema: o transdutor de mídia interage com o servidor WEB através do browser, que atua como

intermediário.

•  Vários fatores indesejáveis causados pelo http e TCP.

Alternativa possível: estabelecer conexão entre o

(23)

©  Adriano Mauro Cansian ₄₅ •  Um arquivo descrevendo o objeto,

ao invés de receber o próprio arquivo.

q  O cabeçalho “Content-type” específica aplicação de áudio e vídeo.

q  Browser dispara o transdutor de mídia, e entrega o meta-arquivo para ele.

q  Transdutor estabelece uma conexão TCP com o servidor, e envia a ele a mensagem HTTP do tipo http-request.

Problema:

q  O transdutor de mídia se

comunica usando HTTP, que não foi projetado para suportar comandos de controle de apresentação.

(3) arquivo solicitado é enviado usando o HTTP

transdutor de mídia

©  Adriano Mauro Cansian ₄₆

Vídeo

on-demand

em servidores Web (4)

q 

Melhor abordagem

: transdutor solicita

direto

ao servidor (ou cloud) de vídeo.

q 

Esta arquitetura permite o uso de outros

protocolos (além do HTTP/TCP) entre o

servidor

e o

transdutor de mídia

.

(24)

©  Adriano Mauro Cansian ₄₇

Protocolos de aplicação para Mídia:

RTSP

Real Time Streaming Protocol

(Aqui começa a sopa de letras...)

©  Adriano Mauro Cansian ₄₈

Real Time Streaming Protocol: RTSP (1)

HTTP:

q  Projetistas do HTTP tinham em mente mídias estáticas:

•  HTML, imagens, applets, etc…

•  HTTP não foi projetado para tratar mídia contínua armazenada(áudio, vídeo, apresentações, etc…).

Alternativa: RTSP (RFC 2326):

q Protocolo de aplicação, tipo cliente-servidor.

q Protocolo para CONTROLE DE MÍDIA:

•  Permite ao usuário controlar apresentações de mídia

contínua: voltar ao início, avançar, “pausar”, continuar, seleção de faixa, etc…

(25)

©  Adriano Mauro Cansian ₄₉

q Não é um protocolo de transporte de mídia

•  Não define como o fluxo de mídia contínua é transportado.

q Não especifica se/como receptor deve armazenar a mídia.

Exemplos:

q Helix DNA Server (RealNetworks) e Realplayer

q  Quick Time Streaming Server e Quick Time Player.

q  Plex Media server e Plexa Player

•  Servidor e transdutor usam RTSP para informações de.

q  Lista em http://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol

©  Adriano Mauro Cansian ₅₀

RTSP: controle fora da banda (1)

Recordando:

FTP usa um canal de controle “fora-da-banda”.

q 

O arquivo é transferido

sobre um canal

.

q 

Informações de

controle

são enviadas

sobre outro canal

.

•  Operações de mudanças de diretório, remoção de

arquivos, trocas de nomes, dentre outras.

q 

Os canais “dentro-da-banda”e

“fora-da-banda” usam números de portas

diferentes.

(26)

©  Adriano Mauro Cansian ₅₁

RTSP: controle fora da banda (2)

q Mensagens RTSP são enviadas “fora-da-banda”.

q As mensagens de controle RTSP usam números

de portas diferentes das portas do fluxo de

dados de mídia contínua.

q O fluxo de dados de mídia contínua é enviado

em separado, considerada “dentro-da-banda”. •  Estrutura de pacotes do fluxo de dados não é definida

pelo RTSP,

©  Adriano Mauro Cansian ₅₂

Iniciação do RTSP e controles de entrega

q  Cliente obtém uma descrição do conteúdo

multimídia, que pode consistir de vários fluxos de dados.

q  O browser chama o transdutor de mídia com

base no tipo de conteúdo descrito.

q  A descrição da apresentação inclui referências

aos fluxos de mídia usando o método rtsp://

q  Transdutor envia o comando RTSP SETUP e servidor envia a resposta RTSP SETUP.

q  Transdutor envia o comando RTSP PLAY; servidor envia a resposta RTSP PLAY.

q  O servidor de mídia descarrega o fluxo de mídia.

q  Transdutor envia o comando RTSP PAUSE; o

servidor envia a resposta RTSP PAUSE.

q  Transdutor envia o comando RTSP

TEARDOWN; servidor envia a resposta RTSP TEARDOWN. HTTP GET SETUP PLAY media stream PAUSE TEARDOWN media player Web server media server Web browser client server presentation desc. Transdutor

de mídia Servidor de mídia

cliente servidor

descr. apresent.

(27)

©  Adriano Mauro Cansian ₅₃ <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"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session> unesp - IBILCE - SJRP

©  Adriano Mauro Cansian ₅₄

Sessão

RTSP

q Cada sessão RTSP tem um identificador de

sessão (escolhido pelo servidor).

•  Cliente inicia a sessão com o comando SETUP, e o

servidor responde ao comando com um identificador. q Cliente repete o identificador em cada comando,

•  Até que o cliente encerrar a sessão com o comando.

q  O número de porta do RTSP é TCP/554.

q  RTSP é encapsulado em TCP para transporte.

•  Cada mensagem RTSP pode ser enviada numa conexão TCP

(28)

©  Adriano Mauro Cansian ₅₅

RTSP: exemplo de mensagens

CLIENT: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY SERVER: RTSP/1.0 200 1 OK

Session 4231

CLIENT: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

Range: npt=0-

CLIENT: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

Range: npt=37

CLIENT: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

SERVER: 200 3 OK

Comandos

Session ID

RTP: veremos mais adiante

©  Adriano Mauro Cansian ₅₆

Aplicações

interativas

em

tempo-real

Fazendo o (im)possível

com o “melhor esforço”

(29)

©  Adriano Mauro Cansian ₅₇ •  Skype •  Gizmo •  Viber •  Facetime •  Net2phone •  Muitos outros... q  Videoconferência. q  Live Webcams.

Como exemplo, vamos agora examinar um produto de

telefone da Internet em detalhes…

©  Adriano Mauro Cansian ₅₈

Telefonia Internet sobre melhor-esforço (1)

Usando melhor esforço:

q 

Temos problemas de:

• 

Atraso

• 

Perdas

• 

Jitter

q 

Usando um exemplo de telefonia IP, vamos

examinar como estes problemas são

tratados.

(30)

Telefonia Internet sobre melhor-esforço (2)

q As aplicações de telefonia na Internet geram

pacotes SOMENTE durante momentos de atividade da voz.

q Considere uma taxa de bits PCM de 64 kbps ou 8 kbytes / seg durante atividade.

•  Ou seja, 8 kbytes / seg por rajada.

(na verdade é uma taxa muito alta - na prática as taxas serão

menores e deve-se usar compressão).

q Como a aplicação funciona:

•  Junta as partes de atividade, e gera uma porção de

dados a cada 20 ms (por padrão).

q 

Continuando...

Telefonia Internet sobre melhor-esforço (3)

q  Junta tudo, e gera uma porção de dados a cada 20 ms.

Ou seja: durante períodos de atividade, a aplicação produz um bloco de 160 bytes.

8 kb/seg x 20 ms = 160 bytes

q  Além disso: um cabeçalho é acrescentado ao bloco.

•  Bloco + cabeçalho são encapsulados num pacote UDP, e enviados.

q  Alguns pacotes podem ser perdidos à oatraso irá variar. •  Receptor deve determinar quando reproduzir um bloco, e

determinar o que fazer com um bloco faltante.

(31)

•  Retransmissões aumentam o atraso.

•  Sliding window do TCP limita a taxa de transmissão.

q  Pacotes redundantes podem ajudar (veremos mais adiante)

2. Atraso fim-a-fim:

q  Causa: acúmulo da soma dos atrasos

•  transmissão, propagação, processamento, e de filas.

q  Se há mais que 400 ms de atraso fim-a-fim:

•  compromete a interatividade.

q  Quanto menor o atraso, melhor.

Tratando problemas em rede best-effort (2)

1. Perda de pacotes:

q  Segmento UDP à encapsulado num datagrama IP.

q  Datagrama pode ser descartado num roteador.

q  Uso de TCP poderia eliminar perdas.

•  Mas tem efeitos colaterais:

•  Retransmissões aumentam o atraso.

•  Sliding window do TCP limita a taxa de transmissão.

q  Pacotes redundantes podem ajudar (veremos mais adiante)

2. Atraso fim-a-fim:

q  Causa: acúmulo da soma dos atrasos

•  Atrasos: transmissão, propagação, processamento, e de filas.

q  Se há mais que 400 ms de atraso fim-a-fim:

•  Conforme já visto: compromete a interatividade.

(32)

Tratando problemas em rede best-effort (3)

3. Jitter ou Variação de atraso:

q Considere dois pacotes consecutivos num intervalo

de atividade.

•  Espaçamento inicialé de 20 ms.

•  Mas o espaçamento no receptor pode ser maior ou

menor que 20 ms à devido ao JITTER.

Para remover o jitter, utiliza-se, ao mesmo tempo:

1. 

Marcas de tempo.

2. 

Atrasos na reprodução.

3. 

Números de sequência.

1. Uso de marcas de tempo (timestamp)

q Emissor coloca uma marca de tempo t no bloco.

q Receptor tenta reproduzir cada bloco exatamente q ms depois que o bloco é gerado.

•  Se o bloco tem marca de tempot, receptor usa o

bloco no instante (t+q) .

•  Se o bloco chega após o instante (t+q), receptor o

descarta.

q Números de sequência não são necessários aqui.

q Esta estratégia permite perder pacotes.

(33)

•  q pequeno: melhor controle da interatividade.

2. Atraso de reprodução (fixo)

q  Transmissor gera pacotes a cada 20 ms durante os intervalos de atividade.

q  Atrasa o início por um fator fixo.

q  Primeiro pacote é recebido no instante r.

q  Primeira programação de reprodução: começa em p.

q  Uma segunda programação de reprodução poderia começar em p’.

q  Deve-se escolher p ou p’ adequadamente.

tempo packets time packets generated packets received loss r p p' playout schedule p - r playout schedule p' - r

(34)

2. Atraso de reprodução (adaptativo) (1)

pacote ésimo -o receber após rede na atraso do estimativa pacote ésimo -o para rede da atraso receptor no o reproduzid é pacote o qual no instante receptor pelo recebido é pacote o qual no instante pacote ésimo do tempo de marca i d i t r i p i r i t i i i i i i = = − = = − =

•  Estima o atraso da rede, e ajusta o atraso de reprodução no início de cada intervalo de atividade.

•  Intervalos de silêncio são aumentados e diminuídos de forma

dinâmica à com base na média estatística dos atrasos.

•  Blocos ainda são gerados a cada 20 ms nos intervalos de atividade.

Estimativa dinâmica do atraso médio no receptor: ₍₁ ₎ ₍ ₎

1 i i i

i u d u r t

d = − − + −

onde u é uma constante fixa (ex: u = 0,01).

É também usual estimar a variância média do atraso, vi :

| | ) 1 ( _i ₁ _i _i _i i u v u r t d v = − − + − −

As estimativas de di e vi são calculadas para cada pacote recebido, embora

elas sejam usadas apenas no início de um intervalo de atividade.

Para o primeiro pacote de um intervalo de atividade, o instante de reprodução é:

i i i

i t d Kv

p = + +

onde K é uma constante positiva. Para este mesmo pacote, o atraso de reprodução é:

i i

i p t

q = −

Para o pacote j no mesmo intervalo de atividade, o pacote deve ser reproduzido em:

i j

j t q

p = +

(35)

q 

Se

nunca houvesse perdas

o receptor

poderia simplesmente olhar nas marcas de

tempo sucessivas.

• 

Se a diferença de marcas de tempo

sucessivas

for

maior que 20 ms

, então

é o início de silêncio (intervalo).

• Mas as perdas podem ocorrer.

q 

Uma vez que as perdas podem ocorrer:

q 

O receptor deve olhar tanto as marcas de

tempo como os números de sequência dos

pacotes.

Se a diferença de marcas de tempo

sucessivas for

maior que 20 ms,

e

não há

saltos nos números de sequência

, então

éo

início de um silêncio

.

(36)

Recuperação de perdas

Perdas: pacote nunca chega, ou

chega

depois

do seu tempo de

reprodução programado

71

Recuperação de perdas de pacotes (1)

Correção de erro de envio (FEC) - esquema simples:

q  Recuperação antecipada.

q  Para cada grupo de n blocos, cria um bloco redundante.

q  Envia os n+1 blocos.

q  Aumenta o uso banda por um fator de 1/n.

q  Assim, é possível reconstruir os n blocos originais, se

houver no máximo um bloco perdido nos n+1 blocos enviados.

FEC = Forward Error Correction

Similar ao método de paridade.

Ver seção 5.2.1 Kurose &Ross. Exercício: “OU exclusivo” (XOR) entre os n blocos originais.

(37)

Recuperação de perdas de pacotes (2)

q Enviar, junto com o fluxo original, um fluxo de

menor qualidade adicional, como “carona”.

q Isto é, enviar fluxo de áudio de menor resolução como informação redundante.

•  Por exemplo, um fluxo PCM nominal a 64 kbps e um fluxo GSM redundante a 13 kbps.

q Transmissor cria pacote tomando o bloco n do

fluxo nominal, e anexando a ele o bloco (n-1) do fluxo redundante.

(38)

Esquema FEC:

•  Enviar um fluxo de menor qualidade como “carona”.

•  Envia fluxo de áudio de menor resolução como a informação redundante.

•  Por exemplo, um fluxo PCM nominal a 64 kbps e um fluxo GSM redundante a 13 kbps. •  Transmissor cria pacote tomando o bloco n do fluxo nominal, e anexando a ele o bloco (n-1) do fluxo redundante

•  Sempre que ocorre perda não-consecutiva, o receptor pode esconder a perda.

•  Apenas dois pacotes precisam ser recebidos antes do início da reprodução

•  Pode também anexar os blocos (n-1) e (n-2) do fluxo de baixa qualidade.

Recuperação de perdas de pacotes (3)

Fluxo original

Redundância

Perda de Pacote

Fluxo reconstruído

Recuperação de perdas de pacotes (4)

q 

Outra técnica:

intercalação

.

q 

Blocos são

quebrados

em unidades

menores.

q 

Por exemplo,

4 blocos de 5 ms cada

.

q 

Intercalar

os blocos como mostrado no

diagrama (a seguir).

q 

Cada pacote agora contém unidades

(39)

©  Adriano Mauro Cansian ₇₇ quebrados em unidades menores. q  Por exemplo, 4 blocos de 5 ms cada. q  Intercalar os blocos como mostrado no diagrama.

q  Pacote agora contém unidades menores

de diferentes blocos.

q Remontar os blocos no

receptor.

q Se o pacote é perdido,

ainda resta mais de cada bloco.

Perda de pacote

Fluxo reconstruído

q Técnicas para recuperação pelo receptor de fluxos de áudio danificados:

q Produzir uma substituição para um pacote

perdido que seja similar ao pacote original. •  Pode produzir bons resultados para baixas taxas de

perdas, e pacotes pequenos (4 ~ 40 ms). •  Estratégia mais simples: repetição de n. •  Estratégia mais complexa: interpolação.

Recuperação de perdas de pacotes (6)

Resumo

(40)

Até aqui vimos:

q Conceitos fundamentais e características da

Mídia na Internet.

q Problemas e desafios.

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

q Codificação de áudio e vídeo, PCM e MP3.

q Controle de mídia com RTSP.

q Aplicações interativas em tempo real.

q A seguir: protocolos para transportar mídia

•  RTP, RTCP, VoIP, H323, SIP, e outros....