13_dados4

1

Fundamentos de Sistemas MultimFundamentos de Sistemas Multimíídiadia

Aplicações Multimídia eProtocolos de Streaming

Profa. Débora Christina Muchaluat [email protected]

AplicaAplicaçções Multimões Multimíídiadia eeProtocolosProtocolos de Streamingde Streaming

Profa. Débora Christina Muchaluat [email protected]

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

3


AplicaAplicaççõesões MultimMultimíídiadia

� 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 (telefoniaIP) 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çõestradicionais (mídia discreta)

4


jitterjitter

� Variação de retardo

� Efeito do jitter

5



� Classificação das aplicações multimídia:• Transmissão de mídia contínua armazenada• Transmissão de mídia contínua ao vivo• Transmissão de mídia contínua interativa

6



� 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 querecebem 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 com mídia contínua transmitida aovivo • 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 com mídia contínuainterativa• 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 danecessidade de interatividade em tempo-real

• Retardos:– Aúdio:

• < 150 ms bom• de 150 a 400 ms aceitável

9


LimitaLimitaççõesões dada Internet Internet AtualAtual

� 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.– Modelos intserv e diffserv

10


AproveitandoAproveitando aoao mmááximoximo o o ““melhormelhor esforesforççoo””

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

� Usar UDP para evitar o TCP e sua fase de partidalenta…

� 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ãodisponível

� Nós podemos transmitir pacotes redundantes paraatenuar os efeitos das perdas de pacotes.

25


AplicaAplicaççõesões interativasinterativas emem tempotempo--real real

� Exemplo:• Telefonia IP

26


TelefoniaTelefonia Internet Internet sobresobre melhormelhor--esforesforççoo

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 maiscabeç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


RealReal--Time Protocol (RTP)Time Protocol (RTP)

� RTP especifica uma estrutura de pacotes que transportam dados deaú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: seduas aplicações detelefonia IP usam RTP,então elas podem sercapazes de trabalharjuntas

41


RTP RTP roda em cimaroda em cima do UDPdo UDP

As bibliotecas do RTP fornecem umainterface que estende o UDP:

• número de portas, endereços IP• identificação do tipo de carga • numeração da seqüência depacotes• marcas de tempo

Aplicação

Enlace

Física

camada detransporte

RTP é um protocolo de aplicaçãoAlguns autores o colocam como subcamada de transporte

42


RTP: RTP: ExemploExemplo

� Considere enviar 64 kbps de voz codificada emPCM sobre RTP.

� A aplicação reúne dadoscodificados em blocos,por exemplo, a cada 20 ms = 160 bytes por bloco.

� O bloco de aúdio, juntocom o cabeçalho RTP forma o pacote RTP, queé encapsulado numsegmento UDP.

� O cabeçalho RTP indica otipo de codificação deaúdio em cada pacote, os transmissores podem mudar a codificação durante a conferência. Ocabeçalho RTP também contém os números deseqüência e marcas de tempo.

44


CabeCabeççalhoalho RTP RTP

Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que está sendo usado nomomento. 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 CargaNúmero deSeqüência Marca de tempo

Identificadorsincronismo fonte

campos de miscelânias

Cabeçalho RTP

45


� Campo de marca de tempo (32 bits). Reflete o instante deamostragem do primeiro byte no pacote de dados RTP. O receptorpode usar esta marca de tempo para remover o jitter do pacote e para obter o sincronismo de reprodução. A marca de tempo é derivada doreló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. Oreló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 terum SSRC distinto (atribuído aleatoriamente pela fonte). (serve para multiplexar vários fluxos de mídia em um único fluxo UDP)

CabeCabeççalhoalho RTP RTP

46


RealReal--Time Control Protocol (RTCP)Time Control Protocol (RTCP)

� Trabalha em conjunto com o RTP.

� Cada participante de uma sessão RTP transmite periodicamente pacotes decontrole RTCP para todos os outros participantes. Cada pacote RTCP contém relatórios do transmissor e/oudo receptor que são úteis paraa aplicação.

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

� Esta informação derealimentação para aaplicação pode ser usada para controle dodesempenho e para fins de diagnóstico. • O transmissor pode

mudar suas transmissõescom base nestas informações derealimentação.

47


RTCP RTCP -- ContinuaContinuaççãoã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 onúmero de participantes da conferência aumenta.

48


PacotesPacotes RTCPRTCP

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 dotransmissor:

� SSRC do fluxo RTP, marca de tempo e o tempo corrente real do pacote mais recente, onúmero de pacotes enviados e o número de bytes enviados.

Pacotes de descrição da fonte:

� endereço de e-mail dotransmissor, o nome dotransmissor, o SSRC do fluxo RTP associado.Esses pacotes fornecemum mapeamento entre o SSRC e o nome dousuário ou do host.

52


RTP e RTP e QoSQoS

� RTP não fornece nenhum mecanismo para assegurar aentrega dos pacotes e dados no tempo correto, nem fornece outras garantias de qualidadede 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 RTPcheguem no destino nomomento correto.

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

• Intserv• Diffserv

13_dados4

Documents

Transcript of 13_dados4