Departamento de Engenharia de Telecomunicaç

Telecomunicações - UFF Aplicações Multimídia

Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
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)
Aplica ções Multim
Aplicações ídia ee
Multimídia são inúteis
• Tolerantes a perdas
Protocolos
Protocolos de
de Streaming
Streaming – Perdas ocasionais causam pequenas perturbações na
recepção de áudio e vídeo
Profa.
Profa.Débora
DéboraChristina
ChristinaMuchaluat
MuchaluatSaade
Saade
Essas características diferem das aplicações
tradicionais (mídia discreta)
deborams@telecom.uff.br
deborams@telecom.uff.br

1 3

jitter Aplicações Multimídia

Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia

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

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

Efeito do jitter
• Transmissão de mídia contínua interativa

4 5
 Aplicações Multimídia Aplicações Multimídia
Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
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

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

6 7

Aplicações Multimídia Limitações da Internet Atual

Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia

Aplicações Multimídia com mídia contínua
Arquitetura Internet fornece serviço de melhor esforço
interativa
Não há garantias sobre o retardo ou sobre a variação do retardo
• Congestionamento na rede causa problema
• Tempo-real interativo
• na Internet pública todos os pacotes recebem tratamento igual
• Conferência de aúdio ou de vídeo • Pacotes contendo aúdio e vídeo interativo de tempo-real permanecem
• Mais exigente nos requisitos de retardo e variação do nas filas, como todos os outros.
retardo que o tempo-real unidirecional por causa da
Projeto de aplicações multimídia seria mais fácil se houvesse várias
necessidade de interatividade em tempo-real classes de serviço
• Retardos: • Esforços vêm sendo desenvolvidos para prover serviços diferenciados
com garantias de QoS – qualidade de serviço.
– Aúdio:
– Modelos intserv e diffserv
• < 150 ms bom
• de 150 a 400 ms aceitável

8 9
 Aproveitando ao máximo o “melhor esforço” Aplicações interativas em tempo-real
Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia

Para reduzir o impacto do serviço de melhor esforço da

Internet, nós podemos:
Exemplo:

Usar UDP para evitar o TCP e sua fase de partida • Telefonia IP
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.
10 25

Telefonia Internet sobre melhor-esforço Real-Time Protocol (RTP)

Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia

Serviço de Melhor esforço
RTP especifica uma
RTP roda nos sistemas

Acarreta atraso de pacotes, perdas e variação de retardo (jitter) estrutura de pacotes que terminais.
Exemplo de telefone Internet transportam dados de
os pacotes RTP são

As aplicações de telefonia na Internet geram pacotes durante aúdio e vídeo: RFC 1889. encapsulados em
momentos de atividade da voz

pacote RTP oferece segmentos UDP
• Rajadas de voz alternadas com períodos de silêncio
• identificação do tipo de
Interoperabilidade: se

cabeçalho RTP é acrescentado ao bloco; então bloco mais
cabeçalho são encapsulados num pacote UDP e enviados carga duas aplicações de

alguns pacotes podem ser perdidos e o retardo de um pacote irá • numeração da seqüência telefonia IP usam RTP,
flutuar. de pacotes então elas podem ser
• Técnicas de FEC (forward error correction) e de compensação do jitter • marcas de tempo capazes de trabalhar
juntas

26 40
 RTP roda em cima do UDP RTP: Exemplo
Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia

RTP é um protocolo de aplicação
Considere enviar 64 kbps
O cabeçalho RTP indica o

Alguns autores o colocam como subcamada de transporte de voz codificada em tipo de codificação de
PCM sobre RTP. aúdio em cada pacote, os
As bibliotecas do RTP fornecem uma
A aplicação reúne dados
Aplicação
transmissores podem
interface que estende o UDP: codificados em blocos, mudar a codificação
• número de portas, endereços IP camada de por exemplo, a cada 20
• identificação do tipo de carga transporte
durante a conferência. O
ms = 160 bytes por bloco.
• numeração da seqüência de cabeçalho RTP também

O bloco de aúdio, junto contém os números de
pacotes com o cabeçalho RTP
• marcas de tempo Enlace seqüência e marcas de
forma o pacote RTP, que
Física é encapsulado num tempo.
segmento UDP.

41 42

Cabeçalho RTP Cabeçalho RTP

Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia
Número de Identificador campos de
Tipo de Carga Seqüência Marca de tempo
sincronismo fonte miscelânias
Campo de marca de tempo (32 bits). Reflete o instante de
Cabeçalho RTP
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
Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que está sendo usado no obter o sincronismo de reprodução. A marca de tempo é derivada do
momento. relógio de amostragem no transmissor.
Se um transmissor muda o tipo de codificação durante uma conferência, o transmissor
• Como exemplo, para aúdio o relógio de marca de tempo incrementa de
informa o receptor através deste campo de tipo de carga.
um a cada intervalo de amostragem (por exemplo, cada 125 microsseg
•Tipo de carga 0: PCM mu-law, 64 Kbps
para uma taxa de amostagem de 8 KHz); se a aplicação de aúdio gera
•Tipo de carga 7, LPC, 2.4 Kbps
blocos contendo 160 amostras codificadas, então a marca de tempo do
•Tipo de carga 9, G.722, 48-64 Kbps
RTP aumenta de 160 para cada pacote RTP quando a fonte está ativa. O
•Tipo de carga 14, MPEG1 áudio
relógio de marca de tempo continua a aumentar numa taxa constante
•Tipo de carga 26, Motion JPEG
mesmo quando a fonte está inativa.
•Tipo de carga 31. H.261
•Tipo de carga 32, MPEG1 vídeo
•Tipo de carga 33, MPEG2 vídeo
campo SSRC (identificador de sincronismo fonte) (32 bits).
Identifica a fonte do fluxo RTP. Cada fluxo numa sessão RTP deve ter
Número de Seqüência (16 bits): O número de seqüência é incrementado de um a cada um SSRC distinto (atribuído aleatoriamente pela fonte). (serve para
pacote RTP enviado; pode ser usado para detectar perdas de pacotes e ocultar os dados multiplexar vários fluxos de mídia em um único fluxo UDP)
perdidos. 44 45
 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.
46
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.
48
RTCP - Continuação
Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia

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
- Para uma sessão RTP existe tipicamente um único endereço multicast, todos os
com base nestas
pacotes RTP e RTCP pertencentes à sessão usam este endereço multicast.
informações de
- Os pacotes RTP e RTCP são distintos uns dos outros pelo uso de números de
realimentação. portas diferentes.
- Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando o
número de participantes da conferência aumenta.
47
RTP e QoS
Fundamentos de Sistemas Multimí
Multimídia Fundamentos de Sistemas Multimí
Multimídia
Pacotes de descrição da
RTP não fornece nenhum
A fim de fornecer QoS
mecanismo para assegurar a
fonte: entrega dos pacotes e dados no para uma aplicação, a
Internet deve prover

endereço de e-mail do tempo correto, nem fornece
outras garantias de qualidade
transmissor, o nome do mecanismos especiais:
de serviço. • Intserv
transmissor, o SSRC do
O encapsulamento RTP é visto • Diffserv
fluxo RTP associado. apenas nos sistemas finais --
Esses pacotes fornecem ele não é percebido pelos
roteadores intermediários.
um mapeamento entre o
• Roteadores fornecem o serviço
SSRC e o nome do de melhor-esforço tradicional
da Internet. Eles não fazem
usuário ou do host.
nenhum esforço especial para
assegurar que os pacotes RTP
cheguem no destino no
momento correto.
52