e Protocolos de Streaming Aplicações Multimídia Multimídia Aplicações jitter Variação de retardo Efeito do jitter

(1)

1

Fundamentos de Sistemas Multim Fundamentos de Sistemas Multimíídiadia

Aplicações Multimídia e

Protocolos de Streaming

Profa. Débora Christina Muchaluat Saade

deborams@telecom.uff.br

Aplica

ç

ões Multim

í

dia

e

Protocolos

de Streaming

Profa. Débora Christina Muchaluat Saade

deborams@telecom.uff.br

Departamento de Engenharia de Telecomunica

Departamento de Engenharia de Telecomunicaçções ões --UFFUFF

3

Aplica

ç

ões

Multim

í

dia

Aplicações multimídia (mídia contínua)

• Sensíveis ao retardo e variação do retardo (jitter) – Pacotes que sofrem retardos de centenas de ms (telefonia

IP) até poucos segundos (recepção de mídia armazenada) são inúteis

• Tolerantes a perdas

– Perdas ocasionais causam pequenas perturbações na recepção de áudio e vídeo

Essas características diferem das aplicações tradicionais (mídia discreta)

4

jitter

Variação de retardo

Efeito do jitter

5

Aplica

ç

ões

Multim

í

dia

Classificação das aplicações multimídia:

• Transmissão de mídia contínua armazenada

• Transmissão de mídia contínua ao vivo

(2)

6

Aplica

ç

ões

Multim

í

dia

Aplicações Multimídia com mídia contínua armazenada

• Conteúdo foi pré-gravado e armazenado em um servidor

• Clientes solicitam arquivos de aúdio e vídeo de servidores, recebem a informação pela rede e a apresentam

• Usuário pode controlar a operação

– similar a um VCR: pause, resume, fast forward, rewind, etc.

• Fluxo contínuo:

– Clientes reproduzem parte do conteúdo ao mesmo tempo em que recebem o restante pela rede

• Reprodução contínua:

– Assim que se inicia a reprodução da mídia, ela deve prosseguir de acordo com a temporização original da gravação

– Restrições ao atraso na entrega dos dados

• Retardo:

– Resposta considerada aceitável se o tempo a partir do pedido do cliente até o início da apresentação for de 1 a 10 segundos

7

Aplica

ç

ões

Multim

í

dia

Aplicações Multimídia com mídia contínua transmitida ao vivo

• tempo-real unidirecional

• similar à difusão de rádio e TV convencional, mas a transferência de informação é feita pela Internet

• Se armazenar o fluxo no cliente, pode pausar e retroceder

• Muitos clientes recebem o mesmo conteúdo simultaneamente

– Distribuição eficiente precisa de comunicação multicast

• Retardo:

– Resposta considerada aceitável se o tempo a partir do pedido do cliente até o início da apresentação for de 1 a 10 segundos

8

Aplica

ç

ões

Multim

í

dia

Aplicações Multimídia com mídia contínua interativa

• Tempo-real interativo

• Conferência de aúdio ou de vídeo

• Mais exigente nos requisitos de retardo e variação do retardo que o tempo-real unidirecional por causa da necessidade de interatividade em tempo-real

• Retardos: – Aúdio:

• < 150 ms bom

• de 150 a 400 ms aceitável

9

Limita

ç

ões

da

Internet

Atual

Arquitetura Internet fornece serviço de melhor esforço

Não há garantias sobre o retardo ou sobre a variação do retardo

• Congestionamento na rede causa problema

• na Internet pública todos os pacotes recebem tratamento igual

• Pacotes contendo aúdio e vídeo interativo de tempo-real permanecem nas filas, como todos os outros.

Projeto de aplicações multimídia seria mais fácil se houvesse várias classes de serviço

• Esforços vêm sendo desenvolvidos para prover serviços diferenciados com garantias de QoS – qualidade de serviço.

(3)

10

Aproveitando

ao

m

á

ximo

o

“

melhor

esfor

ç

o

”

Para reduzir o impacto do serviço de melhor esforço da Internet, nós podemos:

Usar UDP para evitar o TCP e sua fase de partida lenta…

Armazenar o conteúdo no cliente e controlar a apresentação para remediar o jitter

Acrescentar marcas de tempo nos pacotes para que o receptor saiba quando reproduzi-los.

Adaptar o nível de compressão à taxa de transmissão disponível

Nós podemos transmitir pacotes redundantes para atenuar os efeitos das perdas de pacotes.

25

Aplica

ç

ões

interativas

em

tempo

-

real

Exemplo:

• Telefonia IP

26

Telefonia

Internet

sobre

melhor

-

esfor

ç

o

Serviço de Melhor esforço

Acarreta atraso de pacotes, perdas e variação de retardo (jitter)

Exemplo de telefone Internet

As aplicações de telefonia na Internet geram pacotes durante momentos de atividade da voz

• Rajadas de voz alternadas com períodos de silêncio

cabeçalho RTP é acrescentado ao bloco; então bloco mais cabeçalho são encapsulados num pacote UDP e enviados alguns pacotes podem ser perdidos e o retardo de um pacote irá

flutuar.

• Técnicas de FEC (forward error correction) e de compensação do jitter

40

Real

-

Time Protocol (RTP)

RTP especifica uma estrutura de pacotes que transportam dados de aúdio 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 podem ser capazes de trabalhar juntas

(4)

41

RTP

roda em cima

do UDP

As bibliotecas do RTP fornecem uma interface que estende 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 Aplicação Enlace Física camada de transporte RTP é um protocolo de aplicação

Alguns autores o colocam como subcamada de transporte

42

RTP:

Exemplo

Considere enviar 64 kbps

de voz codificada em PCM sobre RTP.

A aplicação reúne dados codificados em blocos, por exemplo, a cada 20 ms = 160 bytes por bloco. O bloco de aúdio, 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 aúdio em 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. 44

Cabe

ç

alho

RTP

Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que está sendo usado no

momento.

Se um transmissor muda o tipo de codificação durante uma conferência, o transmissor informa o receptor através deste campo de tipo de carga.

•Tipo de carga 0: PCM mu-law, 64 Kbps •Tipo de carga 7, LPC, 2.4 Kbps •Tipo de carga 9, G.722, 48-64 Kbps •Tipo de carga 14, MPEG1 áudio •Tipo de carga 26, Motion JPEG •Tipo de carga 31. H.261 •Tipo de carga 32, MPEG1 vídeo •Tipo de carga 33, MPEG2 vídeo

Número de Seqüência (16 bits): O número de seqüência é incrementado de um a cada

pacote RTP enviado; pode ser usado para detectar perdas de pacotes e ocultar os dados perdidos.

Tipo de Carga Número de_Seqüência Marca de tempo _{sincronismo fonte}Identificador campos de _miscelânias

Cabeçalho RTP

45

Campo de marca de tempo (32 bits). Reflete o instante de

amostragem do primeiro byte no pacote de dados RTP. O receptor pode usar esta marca de tempo para remover o jitter do pacote e para obter o sincronismo de reprodução. A marca de tempo é derivada do relógio de amostragem no transmissor.

• Como exemplo, para aúdio o relógio de marca de tempo incrementa de um a cada intervalo de amostragem (por exemplo, cada 125 microsseg para uma taxa de amostagem de 8 KHz); se a aplicação de aúdio gera blocos contendo 160 amostras codificadas, então a marca de tempo do RTP aumenta de 160 para cada pacote RTP quando a fonte está ativa. O relógio de marca de tempo continua a aumentar numa taxa constante mesmo quando a fonte está inativa.

campo SSRC (identificador de sincronismo fonte) (32 bits).

Identifica a fonte do fluxo RTP. Cada fluxo numa sessão RTP deve ter um SSRC distinto (atribuído aleatoriamente pela fonte). (serve para multiplexar vários fluxos de mídia em um único fluxo UDP)

Cabe

(5)

46

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 outros participantes. Cada pacote RTCP contém

relatórios do transmissor e/ou do receptor que são úteis para a aplicação.

As estatísticas incluem o número de pacotes enviados, número de pacotes perdidos, variação de retardo entre chegadas, etc.

Esta informação de realimentação para a aplicaçã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.

47

RTCP

-

Continua

ç

ão

- Para uma sessão RTP existe tipicamente um único endereço multicast, todos os pacotes RTP e RTCP pertencentes à sessão usam este endereço multicast. - Os pacotes RTP e RTCP são distintos uns dos outros pelo uso de números de portas diferentes.

- Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando o número de participantes da conferência aumenta.

48

Pacotes

RTCP

Pacotes 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, marca de tempo e o tempo corrente real do pacote mais recente, 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. Esses pacotes fornecem um mapeamento entre o SSRC e o nome do

usuário ou do host.

52

RTP e

QoS

RTP não fornece nenhum mecanismo para assegurar a entrega dos pacotes e dados no tempo correto, nem fornece outras garantias de qualidade de serviço.

O encapsulamento RTP é visto apenas nos sistemas finais --ele não é percebido pelos roteadores intermediários.

• Roteadores fornecem o serviço de melhor-esforço tradicional da Internet. Eles não fazem nenhum esforço especial para assegurar que os pacotes RTP cheguem no destino no momento correto.

A fim de fornecer QoS para uma aplicação, a Internet deve prover mecanismos especiais:

• Intserv • Diffserv