Multimidia em Redes de
Computadores
Ricardo Couto A. da Rocha
2015
Roteiro
Aplicações Multimídia
Técnicas de Digitalização
Implementação em Melhor Esforço
Protocolos para Multimidia
Aplicações de Multimídia em
Rede
Streaming de midia (midia/fluxo contínua)
→ precisa ser reproduzida durante um
intervalo de tempo
Tipos de Aplicações
– Streaming de midia armazenada
– Streaming de midia ao vivo
Streaming de audio/video
armazenado
Midia armazenada
– Conteúdo pré-gravado e armazenado no servidor. Resposta
aceitável de 1 a 2 s.
Cliente pode adiantar conteúdo
.
Fluxo continuo (
streaming
)
– Reprodução de conteúdo recebido ao mesmo tempo em
que se recebe novas porções da mídia. Ex: Youtube,
RealPlayer, QuickTime, Windows Media, Flash Player
Reprodução contínua
– Reprodução deve obedecer a temporização original da
gravação.
Limitações de atraso fim-a-fim menos severas
.
Streaming de audio/video ao
vivo
Transmissão de midia não armazenada
–
Transmissão da midia recém produzida.
Não há
adiantamento de conteúdo ou retrocesso
(apenas
local no cliente).
–
Podem ocorrer atrasos no inicio da reprodução
(como no armazenado), mas reprodução é contínua.
Disseminação pode ser otimizada
–
Diversos clientes recebendo o mesmo conteúdo:
uso de multicast (ao invés de unicast) é preferível
Audio/Video interativos em
tempo real
Midia gerada e imediatamente transmitida
(como ao vivo)
– Interação bidirecional via midia → telefone
VoIP, video-conferência
Atrasos entre geração e reprodução com
fortes restrições
Roteiro
Aplicações Multimídia
Técnicas de Digitalização de Multimidia
Implementação em Melhor Esforço
Protocolos para Multimidia
Audio Digital (1)
ADC (Conversor analógico-digital) produz audio de um
microfone
– Telefone: 8000 8-bit amostras/s (64 Kbps); áudio de
com-putador é usualmente de melhor qualidade (e.g., 16 bit)
Audio contínuo (onda senoidal) Audio Digital (amostrado, quantizado em 4 bits) ADC
Áudio Digital (2)
Sensibilidade do ouvido varia com frequência
Um tom alto pode marcarar tons próximos
Áudio digital é tipicamente comprimido antes do envio
– Codificadores com perda (como MP3 e AAC) exploram a
percepção humana
Video Digital (1)
Video é digitalizado como pixels (amostrado, quantizado)
– Qualidade TV: 640x480 pixels, cores 24 bits, 30 times/sec
(
exige 200 Mbps!
)
Video é enviado comprimido devido à alta largura de
banda requerida
– Compressão com perdas explora a percepção humana
• E.g., JPEG para imagens estátivas, MPEG, H.264 para video
– Altas taxas de compressão (comum 50X para video)
– Video é normalmente > 1 Mbps, contra >10 kbps para fala e
>100 kbps para música
Video Digital (2)
Sequência para compressão JPEG com
perdas para uma imagem
Passo 1
Video Digital (3)
Input 24-bit RGB pixels 8-bit luminance
pixels
8-bit chrominances for every 4 pixels
Passo 1: Pixels são mapeados para espaço de cores
luminescência/crominância (Y/Cb/Cr) e crominância é
sub-digitalizada
Video Digital (4)
Bloco de um componente
Bloco transformado
Passo 2: Cada componente do bloco é transformado para
frequência espacial com DCT (Discrete Cosine
Transformation)
Video Digital (5)
/
=
Input
Thresholds
Output
Passo 3: Coeficientes DCT são quantizados
dividindo-os peldividindo-os limiares (threasholds); reduz dividindo-os bits em
frequências espaciais altas
– Elemento do topo (esquerda) é diferenciado
dos outros blocos (Passo 4)
Video Digital (5.b)
Passo 4: O valor de cada bloco é
substituído pela diferença entre ele e o
elemento correspondente no bloco
Video Digital (6)
Passo 5: O bloco é codificado
run-length
(RLE)
em zigue-zague. Então o código de Huffman é
usado antes de enviar (Passo 6)
Ordem no qual o coeficiente dos blocos é enviado
Ordem no qual o coeficiente dos blocos é enviado
Video Digital (7)
MPEG comprime sobre uma sequência de frames,
considerando rastreamento de movimento para remover
redundância temporal
– I (Intra-coded) frames são autocontidos
– P (Predictive) frames usam predições de movimento em blocos
– B (Bidirectional) frames podem basear predição em frames
futuros
Três frames consecutivos com componentes estáticos e em movimento
Três frames consecutivos com componentes estáticos e em movimento
Roteiro
Aplicações Multimídia
Técnicas de Digitalização de Multimidia
Implementação em Melhor Esforço
Protocolos para Multimidia
Multimidia e Melhor Esforço
Protocolo IP provê serviço de melhor esforço
–
Faz o melhor para transportar os datagramas IP
–
Não oferece nenhuma garantia sobre o atraso
fim-a-fim dos pacotes
TCP e UDP herdam a limitação → não podem
prover essa garantia se o IP também não provê.
Sem garantia de vazão de transmissão e de
atrasos dos pacotes
Desafios para Tráfego
Multimidia
Jitter
(variação do atraso)
é forte limitador
das
aplicações, particularmente
video/audio
interativo em tempo real
.
Adiante veremos mecanismos e protocolos
para comportar as aplicações multimidia em
serviços de melhor esforço.
Existem propostas de evolução da Internet
para comportar tais requisitos.
Abordagens das Propostas de
Mudanças na Internet
Modificação
central no funcionamento da Internet
– Reserva de largura de banda
– Políticas de escalonamento em filas de roteadores
– Descrição do tráfego pelas aplicações (natureza, requisitos)
Manutenção do melhor esforço e serviços complementares
– Ampliação de capacidade da rede pelos ISP – Redes de Distribuição de Conteúdo (CDN)
– Redes de Multicast de sobreposição → para streaming ao vivo
Abordagens intermediárias
– Serviços diferenciados (Diffserv) → classificar o tráfego, políticas de roteadores de acordo com o tráfego e cobrança por classe
Roteiro
Aplicações Multimídia
Técnicas de Digitalização de Multimidia
Implementação em Melhor Esforço
Protocolos para Multimidia
Streaming de Midia
Armazenada (1)
Método simplista de armazenar midia (e.g. para video
sobre demanda), é carregá-lo como download de um
arquivo
–
Problema
: grande atraso de inicio de reprodução, exceto
em arquivos curtos
Streaming de Midia
Armazenada (2)
Streaming efetivo inicia a execução durante o transporte
Streaming de Midia
Armazenada (2)
Tarefas do player de midia:
– Administrar a interface com o usuário e reprodução
– Tratar os erros de transmissão:
verificação
,
correção
e
adaptação
(com RTSP)
– Descomprimir o conteúdo
Streaming de Midia
Armazenada (3)
Problema comum
: como tratar os erros de
transmissão?
Estratégia Vantagem Desvantagem
Usar transporte confiável (TCP)
Corrige todos os erros Aumenta jitter significativamente Adicionar FEC
(e.g., paridade)
Corrige maioria dos erros
Aumenta overhead,
complexidade decoding e jitter
Midia intercalada Mascara maioria dos erros
Levemente aumenta a com-plexidade de decoding e jitter
Streaming de Midia
Armazenada (4)
Pacote de
paridade
pode reparar um
pacote perdido em grupo de N
Streaming de Midia
Armazenada - FEC
Streaming de Midia
Armazenada (5)
Intercalação
espalha parte da midia próximas sobre
diferentes transmissões para reduzir impacto da
perda
Perda reduz resolução temporal; não deixa um buraco
Fluxo Pacotes
Trechos da Midia
Streaming de Midia
Margem segura para evitar
congelamento
Pode parar servidor (ou adiatar ou gravar em disco)
Streaming de Midia
Armazenada (6)
Problema-chave
: midia pode não chegar a tempo para
reprodução devido a largura de banda variável e
perdas/retransmissões
–
Buffers
de midia
no cliente absorvem jitter
; ainda é
Streaming de Midia
Armazenada (6)
Transporte com UDP
– Permite implementar os próprios mecanismos de correção – Permite o envio de pacotes sob demanda → velocidade de
transmissão próxima à reprodução, mas exigiria largura de banda grande
Transporte com TCP
– Permite explorar a velocidade máxima, inclusive maior que o
reprodutor → exige que a largura de banda seja bem maior que a taxa de midia
– Exige buffer maior (jitter observado é maior) – Facilita a reprodução
Streaming de Midia
Armazenada (7)
Comandos RTSP
– Enviados do cliente (player) para o servidor
para ajustar o streaming
Comando Ação do Servidor
DESCRIBE Lista os parâmetros da midia
SETUP Estabelece um canal lógico entre player e servidor
PLAY Inicia o envio de dados para o cliente
RECORD Inicia a aceitação de dados do cliente
PAUSE Temporariamente para o envio de dados
Streaming de Midia ao Vivo (1)
Similar ao caso de midia armazenada
mas ainda
:
– Não pode transmitir mais rápido que a
taxa de geração
para adiantar midia
• Usualmente precisam de buffer maiores para absorver jitter
– Frequentemente possuem
muitos usuários visualizando
a
midia ao mesmo tempo
• UDP com multicast aumenta enormemente a eficiência (uso
IGMP). É raramente disponível, e por isso muitas conexões TCP são usadas.
• Para número grande de usuários, distribuição de conteúdo é usada (último assunto do tópico)
Streaming de Midia ao Vivo (2)
Com transmissão de midia usando multicast, paridade é
efetiva
Conferência em Tempo Real
Dois grandes problemas a resolver
–
Restrições de desempenho
da rede
mais
severas
que as demais aplicações
– Mecanismos para
estabelecer e finalizar
chamadas
→ H.323, SIP, ...
Conferência em tempo real (1)
Conferência em tempo real possui dois ou mais streams
de midia ao vivo. Exemplo: VoIP, video-chamada por
Skype
Questão-chave
:
baixa latência (interativa), <150ms
– Precisa reduzir o atraso ao próximo da propagação
– Benefícios do suporte de rede, e.g., QoS
– Ou benefícios da largura de banda ampla (sem
congestionamento)
– Pacotes grandes (para aumentar eficiência da rede) não é
uma boa resposta. Ex: audio 64Kbps
Por que buffering não resolve?
Conferência em tempo real (2)
Arquitetura H.323 para telefonia Internet
permite chamadas entre computadores
Internet e telefones PSTN.
Gatekeeper controla chamadas na LAN Internet VoIP call Internet/PSTNConferência em Tempo Real
H.323
: referencia diversos protocolos específicos
para
codificação de voz
,
configuração de
chamadas
,
sinalização
,
transporte de dados
, etc.
G.711
→ representação de voz em 64 kbps.
MPEG e H.264 são admitidos para video
H.245
→ negociação de algoritmos
Q.931
→ gerencia conexões
Conferência em tempo real (3)
Pilha do protocolo H.323:
– Chamada é audio/video digital sobre RTP/UDP/IP
– Inicio de chamada é tratado por outros protocolos (e.g.
Q.931)
Conferência em tempo real (4)
Conferência em tempo real (5)
SIP
(Session Initiation Protocol) é alternativa a H.323 para
configurar chamadas em tempo real
– Simples, protocolo textual com URLs como endereços
– Dados são carregados em RTP/RTCP como
anteriormente
Método Descrição
INVITE Requisita o início da sessão
ACK Confirma que a sessão foi iniciada
BYE Requisita o término da sessão
OPTIONS Consulta a estação sobre suas funcionalidades
CANCEL Cancela uma requisição pendente
REGISTER Informa um servidor de indireção sobre localização atual do usuário
Conferência em tempo real
Endereços SIP
Conferência em tempo real (6)
Configurar uma chamada com o three-way handshake do
SIP
– Servidor proxy faz o
chamado
(
callee
) ficar conectado
– Fluxo de dados da chamada flui diretamente entre
chamador/chamado
Chamador (Caller) Chamado (Callee) Proxy Servidor LocalizaçãoComparação SIP e H.323
Conferência em tempo real (7)
Item H.323 SIP
Projetado por ITU IETF
Compatibilidade com PSTN Sim Ampla
Compatibilidade com
Internet Sim, ao longo do tempo Sim Arquitetura Monolítica Modular
Completude Pilha completa SIP apenas mantém configuração
Negociação de parâmetros Sim Sim
Sinalização de chamada Q.931 sobre TCP SIP sobre TCP ou UDP
Formato mensagens Binário ASCII (textual)
Transporte de midia RTP/RTCP RTP/RTCP
Chamadas multidestinos Sim Sim
Conferência multimidia Sim Não
Endereçamento URL ou número de telefone URL
Terminação chamada Explícito ou liberação TCP Sim
Mensagens instantâneas Não Sim
Encriptação Sim Sim
Tamanho do padrão 1400 páginas 250 páginas
Implementação Grande e complexo Moderado
Roteiro
Aplicações Multimídia
Implementação em Melhor Esforço
Protocolos para Multimidia
Redes de Distribuição de
Conteúdo
Entrega de conteúdo, especialmente web e
video, é o maior componente do tráfego
Internet
– Tráfego Internet e Conteúdo
– Fábricas de servidores e proxies web
–
Redes de Entrega de Conteúdo
Conteúdo e Tráfego Internet
Tráfego Internet:
1.Expande exponencialmente
(email/FTP/Web/P2P/video)
2.Possui muitos fluxos pequenos/não-populares e
poucos grandes/populares
Fábrica de Servidores e Proxy
Web (1)
Fábricas de servidores permite servidores web em larga
escalada:
– Requisições em Front-end (fachada) balanceia as
requisições entre servidores
Fábrica de Servidores e Proxy
Web (2)
Caches em
servidores proxy
ajuda as organizações a
prover escalabilidade à web
– Cache de conteúdo no servidor ao invés dos clientes para
aumentar desempenho
– Implementa políticas da organização (e.g., controle de
acesso)
CDN – Redes de Entrega de
Conteúdo (1)
CDNs
escalam servidores web permitindo a clientes
recuperar o conteúdo de um nó CDN próximo
CDN – Redes de Entrega de
Conteúdo (2)
Clientes direcionados para nós CDN próximos por meio de
DNS:
– Consulta cliente retorna nó CDN local como resposta
– Nó CDN local implementa cache de conteúdo para
CDN – Redes de Entrega de
Conteúdo (3)
Servidor de
origem
reescreve
páginas para
servidor
conteúdo via
CDN
Página com conteúdo distribuído por CDN Página web tradicional no servidor
