Escola de Engenharia da UFMG

Curso de Engenharia Elétrica

Comunicação Multimídia
em Redes IP

Referência:
Redes de Computadores e a Internet: uma abordagem top-down. J. F.
Kurose e K. W. Ross. Pearson, 2010.
Seções: 7.1 a 7.4

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Multimídia sobre IP
- Princípios -

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Comunicação Multimídia em Redes
Características Fundamentais:

 Tipicamente sensíveis ao atraso.

 Tolerantes a perdas: perdas esparsas causam pequenas falhas

que podem passar desapercebidas.

 Antítese de dados (e-mail, web, download, internet banking, etc.),

que não toleram bem falhas mas aceitam atrasos sem problemas.

 Compreendem hoje aplicações interativas de voz (telefonia),

streamings de áudio e de vídeo, IPTV, videoconferências, jogos
online e controle de dispositivos multimídia via rede.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Classes de Aplicações Multimídia
Mídia armazenada, em tempo
contínuo (streaming):
 Clientes solicitam de servidores
arquivos com áudio e vídeo,
recebem a informação pela rede e
a apresentam.
 Interativo: o usuário pode
controlar a operação (similar a um
tocador de DVD: pausa, toca,
avança, retrocede, etc.).
 Atraso: a partir do pedido do
cliente até o início da
apresentação, pode ser de 1 a 10
segundos (tipicamente).
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica
Tempo-real unidirecional (broadcasting):
 Similar a TV e rádio convencionais,
mas via Internet.
 Conteúdo gravado ou ao vivo.
 Não interativo; apenas escutar e ver.
Tempo-real interativo (conferência):
 Conferência de áudio ou de vídeo.
 Mais exigente nos requisitos de
atraso que o tempo real unidirecional,
devido à interatividade.
 Vídeo: < 150 ms aceitável.
 Áudio: < 150 ms, < 400 ms aceitável.
 Jogos Online: 20-40 ms, < 100 ms
aceitável.
2010
 Multimídia em redes: desafios
 A arquitetura TCP/UDP/IP
oferece “melhor esforço”: não
há garantias sobre o atraso, a
variação do atraso, a vazão
ou as perdas.
 Aplicações de tempo contínuo
com atrasos iniciais de 5-10
segundos são comuns hoje, mas
o desempenho deteriora se os
enlaces estão congestionados.
 Aplicações interativas em tempo
real têm requisitos rígidos para
atraso de pacotes e variação de
atraso (jitter).
 Lembrando: o jitter é a
variabilidade do atraso de
pacotes dentro do mesmo fluxo.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica
 O projeto de aplicações
multimídia seria mais fácil se
houvessem várias classes
de serviço.
 Porém, na Internet todos os
pacotes recebem igual
tratamento.
 Pacotes contendo áudio e
vídeo de streaming ou
comunicação interativa de
tempo real permanecem nas
filas, como todos os outros.
 Redes corporativas podem
prover algum nível de classes
de serviço (QoS).
2010
Aproveitando ao máximo o “melhor esforço”

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

 (nas conferências) Usar preferencialmente o UDP para evitar o TCP e seus

controles de fluxo, erro e congestionamento.

 Armazenar o conteúdo no cliente (buffer) e controlar a apresentação, para

remediar o jitter.

 Acrescentar marcas de tempo nos pacotes, para que o receptor saiba

quando reproduzí-los.

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

 Transmitir pacotes redundantes, para atenuar os efeitos das perdas de

pacotes.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Como a Internet consegue trabalhar para
suportar melhor as aplicações multimídia?

Filosofia “laissez-faire”: Redes privadas virtuais (VPNs):

 Não há reservas, nem
marcações de datagramas.
 Quando a demanda aumenta,
mais banda de transmissão
deve ser provida.
 Coloque armazenadores de
conteúdo nas bordas da rede:
 ISPs e provedores de
backbone acrescentam caches.
 Provedores de conteúdo
armazenam conteúdo em nós
específicos (nós CDN).
 P2P: escolhe o parceiro mais
próximo com o conteúdo
desejado.
 Reserva blocos permanentes de
banda de transmissão para
empresas.
 Roteadores distinguem o tráfego
de cada VPN usando os seus
endereços IP.
 Roteadores usam esquemas de
enfileiramento especiais para
fornecerem a banda de
transmissão reservada.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Transporte
- RTP e RTCP -

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Real-Time Transport Protocol (RTP)
 O RTP especifica uma estrutura de  Interoperabilidade: se duas
pacotes que transportam dados de aplicações usam RTP, então
áudio e vídeo (RFC 3550). elas podem ser capazes de
 O RTP opera apenas nos sistemas trabalhar juntas.
finais (pontas) e seus pacotes são
comumente encapsulados em
datagramas UDP (que oferecem Aplicação
portas e detecção de erro).
OBS.: uso do TCP também é possível. camada de
 Cada pacote RTP oferece: transporte
UDP (ou TCP)
 identificação do tipo de carga;
 numeração da sequência de
pacotes; Enlace
 marcas de tempo (timestamps).
Física

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 RTP - características

 Considere enviar 64 kbps de  O cabeçalho RTP indica o

voz codificada em PCM tipo de codificação de áudio
sobre RTP. em cada pacote.
 A aplicação reúne dados  Os transmissores podem
codificados em blocos - por mudar a codificação durante
exemplo, cada 20 ms = 160 a comunicação.
bytes por bloco.  O cabeçalho RTP também
 O bloco de áudio, junto com contém, para auxiliar no
o cabeçalho RTP, forma o processo de comunicação, o
pacote RTP, o qual é número de sequência e a
encapsulado em um marca de tempo (timestamp).
datagrama UDP.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 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.
 Em geral, os roteadores fornecem o serviço de melhor esforço
tradicional do IP e 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 rede IP deve prover

algum mecanismo de reserva pelas aplicações (tal como o IntServ
ou o DiffServ).

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Fluxos RTP
 O RTP permite atribuir a cada
fonte (por exemplo, uma
câmara ou um microfone) o seu
próprio fluxo independente de
pacotes RTP.
 Por exemplo, para uma
videoconferência entre dois
participantes, quatro fluxos RTP
poderiam ser abertos:
 dois fluxos para transmitir o
áudio (um em cada direção);
 e dois fluxos para o vídeo
(novamente, um em cada
direção).
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica
 Contudo, algumas técnicas de
codificação populares, incluindo
o MPEG2 e o MPEG4, reúnem
o áudio e o vídeo num único
fluxo durante o processo de
codificação. Quando o áudio e o
vídeo já são reunidos pelo
codificador, então apenas um
fluxo RTP é gerado em cada
direção.
 Para uma sessão multicast do
tipo “muitos-para-muitos”, todos
os transmissores e receptores
tipicamente enviam seus fluxos
RTP na mesma árvore de
multicast, com o mesmo
endereço de multicast.
2010
 Cabeçalho RTP
Número de Identif. de fonte Extensões
Diversos Tipo de Carga Marca de Tempo
Sequência de sincronismo (opcionais)

Cabeçalho RTP

Diversos (9 bits): versão, padding, extensão, número de fontes contribuintes

Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que está sendo
usado no momento (e que pode ser modificada pelo transmissor durante a duração da
comunicação). Exemplos:
•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 33: vídeo MPEG2

Número de Sequência (16 bits): o número de sequência é incrementado de um a

cada pacote RTP enviado e pode ser usado para detectar perdas de pacotes e para
recuperar a sequência de pacotes.
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 (p.ex., incremento a cada 125 μs para 8kHz).
Campo SSRC (identificador de fonte de sincronismo) (32 bits): Identifica a
fonte do fluxo RTP. Cada fluxo numa sessão RTP deve ter um SSRC distinto.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Real-Time Control Protocol (RTCP)
 Protocolo que trabalha em  Estas informações de
conjunto com o RTP. realimentação para a aplicação
 Cada participante de uma sessão podem ser usadas tanto para o
RTP transmite periodicamente controle do desempenho quanto
pacotes de controle RTCP para para fins de diagnóstico.
todos os outros participantes.  O transmissor pode mudar
 Cada pacote RTCP contém suas transmissões com
relatórios com estatísticas do base nestas informações de
transmissor e/ou do receptor, que realimentação.
são úteis para a aplicação.
 Estas estatísticas incluem o
número de pacotes enviados, o
número de pacotes perdidos, a
variação de atraso entre
chegadas, etc.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 RTCP

- Para uma sessão RTP existe tipicamente um único endereço de multicast e

todos os pacotes RTP e RTCP pertencentes à sessão usam este endereço de
multicast.
- Os pacotes RTP e RTCP são distintos um dos outros pelo uso de números
de portas diferentes (porta par para o RTP e ímpar seguinte para o RTCP).
- Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando o
número de participantes da conferência aumenta.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Pacotes RTCP

Pacotes de relatório do receptor: Pacotes de descrição da fonte:

 fração de pacotes perdidos,
último número de sequê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.
 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.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Sincronização de Fluxos
 RTCP pode ser usado para
sincronizar diferentes fluxos
de mídia numa sessão RTP.
 Considere uma aplicação de
videoconferência para a qual
cada transmissor gera um
fluxo RTP para áudio e um
outro para vídeo.
 As marcas de tempo nestes
pacotes são vinculadas aos
relógios de amostragem de
vídeo e de áudio, mas não
são vinculadas a um relógio
de tempo real (isto é, a um
relógio de parede).
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica
 Cada pacote relatório-do-
transmissor RTCP contém
para o último pacote gerado
no fluxo RTP associado, a
marca de tempo do pacote
RTP e o instante de tempo
real no qual o pacote foi
criado.
 Desta forma o pacote RTCP
relatório-do-transmissor
associa o relógio de
amostragem com o relógio de
tempo real.
 Receptores podem usar esta
associação para sincronizar a
reprodução de áudio e vídeo.
2010
 Controle de Banda do RTCP
 O RTCP procura limitar seu
tráfego a 5% da banda
passante da sessão.
 Por exemplo, suponha que
existe um transmissor enviando
vídeo com uma taxa de 2 Mbps.
Então o RTCP procura limitar
seu tráfego a 100 Kbps.
 O protocolo dá 75% desta taxa,
ou 75 kbps, para os receptores;
ele dá os 25% restantes da
taxa, isto é, 25 kbps, para o
transmissor.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica
 Os 75 kbps dedicados aos
receptores são divididos de forma
igual entre todos os receptores.
Assim, se existem R receptores,
cada receptor consegue enviar
tráfego RTCP a uma taxa de 75/R
kbps e o transmissor envia tráfego
RTCP a uma taxa de 25 kbps.
 Um participante (um transmissor
ou receptor) determina o período de
transmissão de pacotes RTCP
dinamicamente calculando o
tamanho médio do pacote (durante
toda a sessão) e dividindo o
tamanho médio do pacote RTCP
pela sua taxa alocada.
2010
Mídia armazenada, em tempo
contínuo (streaming)

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Áudio e Vídeo em Tempo Contínuo
Mídia armazenada em tempo Transdutor de Mídia (player):
contínuo (streaming):
 remove jitter (via buffer);
 Arquivos de áudio e de vídeo são  descomprime;
armazenados em servidores.  corrige erros;
 Usuários solicitam os arquivos de  oferece interface gráfica para
áudio e de vídeo por demanda. o usuário, com controles
 O áudio ou vídeo inicia a para interatividade.
reprodução cerca de 10 s após o
pedido.
 Plug-ins ou HTML5 podem ser
 Uma vez iniciada, a reprodução usados para embutir o acesso ao
tem que se manter sem falhas. transdutor de mídia na janela de
 Interatividade (pausas, avanços, um browser (navegador de web).
retrocessos, saltos) é possível na
reprodução .
 Na rede podem ocorrer atrasos
variáveis, perdas e retransmissões.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Fluxo de tempo contínuo em servidores Web (I)
 Os arquivos de áudio e de vídeo são armazenados em Servidores Web.

Abordagem simplória:
 Browser envia mensagem HTTP do tipo pedido, para obter o arquivo de mídia.
 Servidor Web envia o arquivo de mídia na mensagem HTTP do tipo resposta,
onde o cabeçalho “content-type” indica a codificação apropriada.
 Browser dispara o Transdutor de Mídia e passa o arquivo para ele.
 Maior problema: o Browser é um gargalo entre o Transdutor de Mídia e o
Servidor Web.

cliente servidor

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Fluxo de tempo contínuo em servidores Web (II)
Alternativa 1 - estabelecer conexão direta entre o servidor e o transdutor:
 Browser solicita e recebe um meta arquivo (um arquivo descrevendo o
objeto), ao invés de receber o próprio arquivo.
 O cabeçalho “content-type” indica a codificação apropriada para áudio/vídeo.
 Browser dispara o Transdutor de Mídia e passa o meta arquivo para ele.
 Transdutor estabelece uma conexão TCP com o servidor e obtém dele o
arquivo de mídia na mensagem HTTP do tipo resposta.
 Problemas: o HTTP não foi projetado para suportar comandos de controle de
apresentação; o HTTP opera sobre o TCP, que varia muito a taxa de
comunicação devido ao seu controle de congestionamento.

Web (1) pedido/resposta HTTP

por um meta arquivo
Browser

(2) meta Web

arquivo Server
transdutor
(3) arquivo solicitado é enviado
de mídia
usando o HTTP

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Fluxo de tempo contínuo em servidores Web (III)
Alternativa 2 – servidor de mídia separado do servidor web:
 Browser solicita e recebe um meta arquivo (um arquivo descrevendo o
objeto), ao invés de receber o próprio arquivo.
 Browser dispara o Transdutor de Mídia e passa o meta arquivo para ele.
 Transdutor estabelece comunicação direta com um Servidor de Mídia, sem
usar o HTTP; o mais comum é usar UDP.
 Problemas: o UDP não tem comandos de controle de apresentação (exige
RTSP - a seguir); comunicação UDP pode ser bloqueada por firewalls;
recuperação de erros fica por conta da aplicação; UDP não realiza controle
de congestionamento.
(1) pedido/resposta via
HTTP para o meta
arquivo

(2) meta
arquivo

transdutor servidor
de mídia (3) arquivo de áudio ou de vídeo
vídeo pedido e enviado

cliente servidores
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Questões ao usar um servidor dedicado de mídia
buffer
cliente

taxa de chegada da rede taxa de leitura

= x(t) =d
decodificação
e apresentação

área com
mídia
 via UDP:
 Fonte envia a uma taxa constante (= taxa de codificação) sobre o UDP.
 Para reduzir os efeitos do jitter, deve-se armazenar e exibir com um atraso de 1 a 10 s.
 Taxa de leitura = d, tem que ser igual à taxa de codificação.
 Taxa de enchimento x(t) é igual a d, exceto quando há jitter e perdas.

 via TCP:
 TCP envia na máxima taxa possível sobre a rede, mas evitando congestionamento.
 TCP retransmite quando um erro é encontrado, garantindo a recuperação de erros.
 x(t) agora varia e pode tornar-se muito diferente de d.
 Destino deve usar um buffer muito maior, para compensar a variação na taxa de
entrega do TCP, assim como um atraso inicial maior na reprodução.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Real Time Streaming Protocol (RTSP)
RTSP (RFC 2326):
 Protocolo de aplicação, do tipo cliente-servidor, que permite ao usuário controlar
apresentações de mídia contínua: voltar ao início, avançar, pausar, continuar, pular,
selecionar trilha, etc…

O que o RTSP não faz:

 não define como a mídia é encapsulada para transmissão sobre a rede; o fluxo de
dados de mídia é enviado em um canal de dados (“dentro da banda” de informação),
por um protocolo de transporte (tipo RTP ou outro, sobre UDP ou TCP).
 não especifica como o receptor armazena o áudio ou o vídeo (problema da aplicação
final).

Controle “fora da banda” do RTSP:

 As mensagens de controle do RTSP usam um número de porta diferente do fluxo de
dados de mídia contínua e, portanto, são enviadas em um canal diferente (“fora da
banda” de informação).
 As mensagens de controle do RTSP incluem mudanças de diretório, remoção de
arquivos, trocas de nomes, etc.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Operação do RTSP e controles de entrega
 O cliente obtém uma descrição da
apresentação multimídia, que pode consistir
de vários fluxos de dados.
HTTP GET  O browser chama o transdutor de mídia
Web Web
browser descr. apresent.
presentation desc. server (aplicação auxiliar) com base no tipo de
SETUP conteúdo da descrição da apresentação.
 A descrição da apresentação inclui
PLAY referências aos fluxos de mídia usando o
método rtsp://
media
Transdutor fluxo
mediade mídia
stream Servidor
media
de mídia
player
de mídia
server  Transdutor envia o comando RTSP SETUP;
PAUSE
servidor envia a resposta RTSP SETUP.
TEARDOWN  Transdutor envia o comando RTSP PLAY;
servidor envia a resposta RTSP PLAY.
cliente
client servidor
server  O servidor de mídia descarrega o fluxo de
mídia.
 Transdutor envia o comando RTSP PAUSE;
 O número default de porta do RTSP é 554.
o servidor envia a resposta RTSP PAUSE.
 RTSP pode ser usado sobre UDP ou TCP.
Cada mensagem RTSP pode ser enviada  Transdutor envia o comando RTSP
numa conexão TCP separada. TEARDOWN; servidor envia a resposta
RTSP TEARDOWN.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Exemplo de um Meta-Arquivo
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<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>

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 RTSP: exemplo de mensagens
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
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Fluxo de tempo contínuo em servidores Web (IV)
Alternativa 3 - DASH: Dynamic, Adaptive Streaming over HTTP:
 Servidor Web armazena várias codificações para a mesma mídia, com
diferentes qualidades e taxas de transmissão, sendo que cada codificação
é dividida em blocos de poucos segundos de duração (chunks).
 Browser solicita e recebe um manifesto (arquivo listando as URLs das
codificações e os blocos disponíveis), ao invés de receber o próprio
arquivo.
 Browser dispara o Transdutor de Mídia e passa o manifesto para ele.

 Transdutor periodicamente avalia a banda disponível entre ele e o servidor.

 Consultando o manifesto, Transdutor solicita um bloco por vez, na melhor

codificação possível dada a banda disponível.
 Transdutor pode mudar a codificação escolhida para o próximo bloco,
dependendendo da banda disponível a cada momento.
 Transdutor obtém os blocos do Servidor Web via HTTP (sobre TCP).

 O HLS (HTTP Live Streaming) da Apple opera de modo semelhante.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Fluxo de tempo contínuo em servidores Web (IV)
Alternativa 3 - DASH: Dynamic, Adaptive Streaming over HTTP (cont.):
 A inteligência fica no cliente (Transdutor):
 Cliente determina quando solicitar um bloco, evitando overflow ou esvaziamento
total do buffer.
 Cliente determina qual codificação solicitar, levando a melhor qualidade se mais
banda estiver disponível.
 Cliente escolhe de onde solicitar o bloco, de modo a acessar um servidor que
está mais próximo ou que oferece mais banda (p.ex., usando CDNs).
 Os comandos de controle de apresentação podem ser fornecidos pelo
HTML5 (sem necessidade do RTSP).
 Transmissões HTTP sobre TCP passam melhor por firewalls.

 O TCP garante a recuperação de erro, mas exige atraso inicial de

reprodução mais longo e buffer maior.
 Ideal para distribuição de vídeo armazenado, mas inadequado para
transmissões ao vivo ou comunicação interativa.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Mídia interativa em tempo
real (conferência)

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Aplicações interativas em tempo-real

 Telefonia VoIP PC-a-PC

 Telefonia VoIP PC-a-telefone
 Audioconferência
 Videoconferência

 Como exemplo, vamos examinar em detalhes

uma comunicação de telefonia VoIP do tipo PC-
a-PC na Internet.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Telefonia IP: cenário
Serviço “melhor esforço”:
 atraso de pacotes, perdas e variação de atraso (jitter).

Telefonia IP (comunicação interativa de voz sobre IP):

 aplicações de Telefonia IP geram pacotes durante momentos de
atividade da voz;
 taxa de bits é 64 kbps nos intervalos de atividade – supondo PCM;
 durante os intervalos de atividade a aplicação produz um bloco de
160 bytes a cada 20 ms (8 KBytes/s * 20 ms) – supondo PCM;
 um cabeçalho é acrescentado a cada bloco e bloco mais cabeçalho
são encapsulados num pacote UDP e enviados;
 alguns pacotes podem ser perdidos e o atraso de chegada de
pacotes é variável;
 receptor deve determinar quando reproduzir um bloco e o que fazer
com blocos faltantes.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Telefonia IP: desafios
Perda de pacotes:
 O datagrama UDP é encapsu-
lado num datagrama IP, o qual
pode ser descartado por falta
de espaço num roteador.
 Com o TCP se poderia eliminar
perdas, mas retransmissões
aumentariam o atraso e o
controle de congestionamento
do TCP limitaria a taxa de
transmissão.
 Pacotes redundantes podem
ajudar.
 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica
Atraso fim-a-fim:
 Acúmulo dos atrasos de trans-
missão, propagação, proces-
samento e filas.
 Mais que 400 ms de atraso fim-
a-fim comprometem a interativi-
dade; menor atraso é melhor.
Variação de atraso (jitter):
 Pacotes consecutivos num
intervalo de atividade saem com
espaçamento de 20 ms, mas o
espaçamento no receptor pode
ser maior ou menor que 20 ms.
 Remoção do jitter:
 use números de sequência;
 use marcas de tempo;
 adie o momento da reprodução.
2010
Telefonia IP com atraso fixo de reprodução
 Transmissor gera pacotes a cada 20 ms durante os intervalos de
atividade.
 Primeiro pacote é recebido no instante r
 Primeira programação de reprodução: começa em p
 Segunda programação de reprodução: começa em p’
pacotes
packets

pacotes
packets perda
loss
gerados
generated
pacotes
packets progr.schedule
reprodução
recebidos playout
p -pr - r
received

progr.
playoutreprodução
schedule
p’ --rr
p'

tempo
time

r
p p'

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Atraso de reprodução adaptativo (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.

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

ti  marca de tempo do i  ésimo pacote

ri  instante no qual o pacote i é recebido pelo receptor
pi  instante no qual o pacote i é reproduzido no receptor
ri  ti  atraso da rede para o i - ésimo pacote
d i  estimativa do atraso na rede após receber o i - ésimo pacote

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

di  (1  u)di 1  u(ri  ti )

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

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Atraso de reprodução adaptativo (II)
É também usual estimar a variância média do atraso, vi :

vi  (1  u)vi 1  u | ri  ti  di |
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 é:
pi  ti  di  Kvi
onde K é uma constante positiva. Para este mesmo pacote, o atraso de
reprodução é:
qi  pi  ti
Para o pacote j no mesmo intervalo de atividade, o pacote deve ser
reproduzido em:
p j  t j  qi

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Atraso de reprodução adaptativo (III)
Como saber se um pacote é o primeiro de um intervalo de atividade?

 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 temos o início de um intervalo de atividade.

 Mas porque as perdas são possíveis, 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á pulos nos números de sequência, então tem-se o
início de um intervalo de atividade.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Recuperação de perdas de pacotes (I)
 Perdas: pacote nunca chega ou chega depois do seu tempo de
reprodução programado.

Esquema simples de FEC (correção de erro de envio):

 para cada grupo de n blocos cria um bloco redundante, usando uma
operação XOR entre os n blocos originais;
 envia os n+1 blocos, exigindo banda passante maior por um fator de 1/n;
 consegue reconstruir os n blocos originais se houver no máximo um bloco
perdido nos n+1 blocos enviados;
 o atraso de reprodução precisa ser suficiente para receber todos os n+1
pacotes;
 compromissos:
 aumentando n, maior desperdício de banda;
 aumentando n, maior atraso de reprodução;
 aumentando n, maior a probabilidade que dois ou mais blocos sejam
perdidos.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
 Recuperação de perdas de pacotes (II)
2º esquema de FEC: Fluxo original

• envia fluxo de áudio de

menor resolução como
informação redundante Redundância
(de “carona”);
• por exemplo, um fluxo
Perda de Pacote
PCM nominal a 64 kbps
e um fluxo GSM redun-
dante a 13 kbps;
Fluxo reconstruído
• em caso de perda, o
transmissor pega o bloco
n-1 do fluxo redundante •Sempre que ocorre perda não-consecutiva, o
que veio no pacote do receptor consegue se recuperar.
bloco n do fluxo nominal. • Pode também anexar os blocos n-1 e n-2 do
fluxo de baixa qualidade.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Recuperação de perdas de pacotes (III)
3º esquema de FEC
(Intercalação): Fluxo original

 blocos são quebrados em

unidades menores; Fluxo intercalado

 por exemplo, em 4 blocos

de 5 ms cada; Perda de pacote
 intercalam-se os blocos
como mostrado no
diagrama; Fluxo reconstruído

 o pacote agora contém

unidades menores de
diferentes blocos;
 blocos são remontados no
receptor;
 se um pacote é perdido,
ainda restam porções de
cada bloco.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010
Recuperação de perdas de pacotes (IV)
Recuperação exclusivamente no receptor:

 produzir uma substituição para o pacote perdido que seja similar

ao pacote original;
 pode produzir bons resultados para baixas taxas de perdas e
pacotes pequenos (4-40 ms);
 estratégias mais simples: repetição; inserção de ruído de conforto;
 estratégia mais complexa: interpolação.

 UFMG
© UFMG – Depto
- Depto Engenharia Eletrônica –- Prof. Luciano de Errico - 2022
de Eng. Eletrônica 2010