Transmissão multimídia em redes de computadores

Transcrição

Transmissão multimídia em redes de
computadores
Autor: Valter Roesler
Universidade: UNISINOS
Data: Julho de 2001
Multimídia em redes de computadores
pg. 2
Valter Roesler
SUMÁRIO
1
2
3
4
5
6
Transmissão multimídia em redes........................................................................................... 3
1.1
Latência ........................................................................................................................... 4
1.2
Jitter ................................................................................................................................. 4
1.3
Skew ................................................................................................................................ 5
1.4
Tabela comparativa ......................................................................................................... 5
Protocolos de tempo real para transmissões multimídia ......................................................... 6
2.1
RTP.................................................................................................................................. 6
2.1.1
Entidades RTP ......................................................................................................... 7
2.1.2
Cabeçalho RTP ........................................................................................................ 8
2.1.3
Exemplo: conferência de áudio ............................................................................... 8
2.1.4
Exemplo: videoconferência ..................................................................................... 9
2.2
RTCP ............................................................................................................................... 9
2.2.1
SR (Sender Report) ............................................................................................... 10
2.2.2
RR (Receiver Report) ............................................................................................ 11
2.2.3
SDES (Source Description) .................................................................................. 11
2.2.4
BYE....................................................................................................................... 12
2.2.5
APP........................................................................................................................ 12
2.2.6
Restrições de tempo nos pacotes RTCP................................................................ 12
Padrões de multimídia em redes de computadores ............................................................... 12
3.1
H.323 ............................................................................................................................. 13
3.1.1
Terminais............................................................................................................... 14
3.1.2
Gatekeepers ........................................................................................................... 16
3.1.3
Gateways ............................................................................................................... 16
3.1.4
MCUs .................................................................................................................... 17
3.1.5
Sinalização no H.323............................................................................................. 18
3.1.6
Exemplo de conferência H.323 ............................................................................. 19
3.1.6.1 Exemplos de Terminais H.323 .......................................................................... 19
3.1.6.2 Exemplos de Gatekeepers ................................................................................. 19
3.1.6.3 Exemplos de Gateways ..................................................................................... 19
3.1.6.4 Exemplos de MCUs........................................................................................... 19
3.2
SIP ................................................................................................................................. 19
3.3
Comparação entre SIP e H.323 ..................................................................................... 20
3.3.1
Atraso de conexão ................................................................................................. 20
3.3.2
Escalabilidade........................................................................................................ 20
3.3.3
Tamanho da conferência ....................................................................................... 20
3.3.4
Uso de novos CODECS ........................................................................................ 21
3.3.5
Formato de endereço ............................................................................................. 21
3.3.6
Complexidade........................................................................................................ 21
Compressão de áudio e vídeo ................................................................................................ 21
Padrões de áudio e vídeo ....................................................................................................... 22
5.1
Codificação de áudio ..................................................................................................... 23
5.1.1
Testes de áudio com Netmeeting .......................................................................... 24
5.1.2
Testes de áudio com o RAT (Robust Audio Tool) ................................................ 25
5.1.3
Teste de tamanho de arquivo de áudio com o Goldwave ...................................... 26
5.2
Codificação de vídeo ..................................................................................................... 26
5.2.1
Codificação de vídeo no M-JPEG......................................................................... 28
5.2.2
Codificação de vídeo no MPEG ............................................................................ 28
5.2.3
Resumo de padrões para codificação de vídeo...................................................... 30
Estudo de caso 1: Transmissão multicast ao vivo durante a VI Semana da Qualidade na
Unisinos................................................................................................................................ 31
7
8
pg. 3
Valter Roesler
Estudo de caso2: Videoconferência multicast no Metropoa ................................................. 33
Bibliografia............................................................................................................................ 34
1 Transmissão multimídia em redes
As etapas de uma transmissão multimídia são mostradas na figura a seguir:
Sinal de
entrada
Digitalização
Compressão
Transmissão
Perda / atraso
Sinal de
saída
Recuperação
Descompressão
Reordenação
O sinal gerado é inicialmente digitalizado, para então passar por um processo de
compressão, que diminui seu tamanho, tornando-o viável para ser transmitido na rede. A rede
insere alguns atrasos no sistema. No receptor, os pacotes são reordenados, descomprimidos e
reconvertidos ao estado original, normalmente com perdas inseridas no processo de compressão.
Esses aspectos serão analisados no decorrer desta apostila.
As aplicações que necessitam transmissão multimídia em redes de computadores se
encontram subdivididas em duas partes, como a figura a seguir ilustra: teleconferência (que
requer interatividade) e transmissão unidirecional (que envolve apenas um lado transmitindo e
vários clientes recebendo). Na figura, pode-se ver uma divisão dos dados em áudio, vídeo e
texto.
Aplicações multimídia
Conferências
(interatividade)
Áudio
Transmissão
Unidirecional
Texto
Vídeo
Apesar das aplicações possuírem necessidades diferentes, existe uma tendência atualmente
para sua convergência em um único meio físico. Assim, se unificaria o meio físico, que
compartilharia a transmissão de voz, vídeo, dados, imagens, músicas, e tudo que possa ser
transformado em bits.
Entretanto, as aplicações têm características e requisitos bem diferentes umas das outras.
Aplicações de teleconferência possuem necessidades mais rígidas em relação à latência e jitter
do que aplicações de transmissão unidirecional. Da mesma forma, transmissões de vídeo
necessitam uma largura de banda muito maior que transmissões de áudio ou texto.
A seguir serão definidos três conceitos fundamentais para o entendimento da transmissão
multimídia nas redes de computadores: latência, jitter e skew. Em seguida esses conceitos serão
comparados entre si dentro das necessidades das aplicações.
pg. 4
Valter Roesler
1.1 Latência
Latência é o tempo que um pacote leva da origem ao destino. Caso esse atraso seja muito
grande, prejudica uma conversação através da rede, tornando difícil o diálogo e a interatividade
necessária para certas aplicações. Segundo [PAS 97a] e [PAU 98, pg 9], um atraso confortável
para o ser humano fica na ordem de 100ms.
Suponha duas pessoas conversando através da Internet. À medida que o atraso aumenta, as
conversas tendem a se entrelaçar, ou seja, uma pessoa não sabe se o outro a ouviu e continua
falando. Após alguns milisegundos, vem a resposta do interlocutor sobre a primeira pergunta
efetuada, misturando as vozes. Num atraso muito grande, as pessoas devem começar a conversar
utilizando códigos, tipo “câmbio”, quando terminam de falar e passam a palavra ao outro.
Os principais responsáveis pela latência são o atraso de transmissão, de codificação e de
empacotamento, que podem ser definidos da seguinte forma:
•
•
•
Atraso de transmissão: tempo que leva para o pacote sair da placa de rede do
computador origem e chegar na placa de rede do computador destino. Esse tempo
envolve uma série de fatores, como por exemplo:
1. Atraso no meio físico: é o atraso de propagação da mensagem no meio de
transmissão, e varia bastante. Por exemplo, num enlace de satélite o tempo típico
é de 250ms, e numa fibra ótica ou UTP o atraso é na ordem de 5µs/Km [TAN 97,
pg 107] e [SPU 00, pg /**/].
2. Atrasos de processamento nos equipamentos intermediários, como roteadores e
switches;
3. Atraso devido ao tempo de espera nas filas de transmissão dos equipamentos
intermediários: esse valor depende do congestionamento da rede no momento, e
varia bastante, dependendo do tamanho da fila. Quanto menor a fila, menor o
atraso, mas aumenta a probabilidade de descarte do pacote no caso de
congestionamento;
Atraso de codificação e decodificação: tempo de processamento na máquina origem na
máquina destino para codificação e decodificação de sinais, respectivamente. Voz e vídeo
normalmente são codificados em um padrão, tal como PCM (G.711 a 64Kbps) para voz,
ou H.261 para vídeo. O atraso varia com o padrão adotado; por exemplo, o G.711 ocupa
menos de 1ms de codificação ([PAS 97a]), porém requer 64Kbps de banda. Um
protocolo de voz como o G.729 requer 25ms de codificação, mas ocupa apenas 8Kbps de
banda ([PAS 97a]);
Atraso de empacotamento e desempacotamento: depois de codificado, o dado deve ser
empacotado através dos níveis na pilha de protocolos a fim de ser transmitido na rede.
Por exemplo, numa transmissão de voz a 64Kbps, ou 8000 bytes por segundo, o
preenchimento de um pacote de dados com apenas 100 bytes toma 12,5ms. Mais 12,5ms
serão necessários no destino a fim de desempacotar os dados.
Além disso, dependendo do jitter da transmissão, a aplicação de tempo real deverá criar um
buffer para homogeneizar a entrega de pacotes ao usuário, criando um novo atraso no sistema.
1.2 Jitter
Apenas latência não é suficiente para definir a qualidade de uma transmissão, pois as redes
não conseguem garantir uma entrega constante de pacotes ao destino. O jitter é a variação
estatística do retardo, que altera o fluxo de chegada dos pacotes. O conceito de jitter e latência é
ilustrado na figura a seguir.
N. de
Pacotes
pg. 5
Valter Roesler
latência
jitter
t
A conseqüência do jitter é que a aplicação no destino deve criar um buffer cujo tamanho
vai depender do jitter, gerando mais atraso na conversação (aplicação de voz, por exemplo). Esse
buffer vai servir como uma reserva para manter a taxa de entrega constante no interlocutor. Daí a
importância de latência e jitter baixos em determinadas aplicações sensíveis a esses fatores,
como teleconferência.
1.3 Skew
O skew é um parâmetro utilizado para medir a diferença entre os tempos de chegada de
diferentes mídias que deveriam estar sincronizadas, como mostra a figura a seguir. Em diversas
aplicações existe uma dependência entre duas mídias, como áudio e vídeo, ou vídeo e dados.
Assim, numa transmissão de vídeo, o áudio deve estar sincronizado com o movimento dos lábios
(ou levemente atrasado, visto que a luz viaja mais rápido que o som, e o ser humano percebe o
som levemente atrasado em relação à visão). Outro exemplo em que sincronização é necessária é
na transmissão de áudio (manual explicativo, por exemplo) acompanhada de uma seta
percorrendo a imagem associada.
N. de Pacotes
chegando
skew
vídeo
áudio
t
1.4 Tabela comparativa
A tabela a seguir apresenta algumas aplicações típicas de multimídia em rede, bem como
seus fatores críticos. Aplicações de telefonia (voz) são sensíveis à latência e ao jitter. Em termos
de velocidade, sua necessidade é baixa, variando de 5 Kbps (compressão no padrão G.723) a
64Kbps (padrão G.711, o mais comum em telefonia atualmente).
latência
jitter
skew
velocidade (largura de banda)
Telefone
sensível
sensível
baixa
TV
insensível
sensível
sensível
alta
Videoconferência
sensível
sensível
sensível
alta
pg. 6
Valter Roesler
Já em transmissões unilaterais de áudio e vídeo (por exemplo, TV), há uma flexibilidade
maior quanto à latência. Isso se deve ao fato que, na maioria dos casos, para o usuário não seria
relevante a inclusão de um pequeno atraso entre o momento em que um evento se dá e sua
exibição. Entretanto, esse atraso deve se manter fixo até o final e com sincronismo entre áudio e
vídeo, daí a necessidade de jitter e skew baixos.
Aplicações de videoconferência são muito parecidas com aplicações de telefonia em
termos de latência e jitter, entretanto, possuem alta largura de banda e devem manter um baixo
skew, pois necessitam sincronização entre áudio e vídeo.
2 Protocolos de tempo real para transmissões multimídia
Para transportar dados em tempo real, são necessários protocolos que levem consigo
informações de sincronismo e de tempo, como o RTP (Real-time Transport Protocol). Para
fornecer feedbacks aos participantes da transmissão efetuada pelo RTP, existe o protocolo RTCP
(RTP Control Protocol). Ambos são analisados a seguir.
2.1 RTP
O protocolo RTP (Real-time Transport Protocol), descrito na RFC 1889, especifica um
formato para transmissão de dados em tempo real, tais como áudio, vídeo ou dados de
simulação. Alguns benefícios obtidos por esse protocolo (que serão detalhados no decorrer deste
item) são [PAU 98, pg 197]:
•
•
•
Detecção de perda de pacotes: observando o número de seqüência é possível saber se
houve perda de pacotes ou não. Isso é útil para estimar a qualidade da recepção,
adaptação da aplicação às características da rede, recuperação de dados, e assim por
diante;
Sincronização intra -mídia: o campo de timestamp do cabeçalho informa ao receptor o
momento exato de passar os dados ao usuário. Essa informação é usada pelo receptor
absorver o jitter da rede através de um buffer auxiliar;
Sincronização inter-mídia: o campo de timestamp do cabeçalho de diferentes sessões
RTP (como áudio e vídeo) pode ser usado em conjunto com o protocolo NTP (Network
Time Protocol) a fim de sincronizar as diferentes mídias, permitindo ao receptor a
adaptação ao skew. Um exemplo típico é o sincronismo voz-lábio. Outro é o sincronismo
de uma seta na tela apontando objetos de acordo com um texto falado.
A garantia de entrega do pacote ou a qualidade de serviço da rede não são especificadas no
RTP, e devem ser obtidas através de outro mecanismo de entrega, como o RSVP, Diffserv ou
outro.
O RTP é utilizado para transportar dados em tempo real, e utiliza o RTCP para
monitorar a qualidade de serviço (da sessão e não da rede) e levar informações sobre os
participantes de uma sessão em andamento, como, por exemplo, uma conferência de áudio entre
diversos participantes.
Em termos do modelo OSI, o RTP se situa acima do nível 4, no subnível inferior do nível
de aplicação, como mostra a figura a seguir [PAU 98, pg 194]. O IP pode ser tanto unicast como
multicast, e o protocolo de nível 2 (Ethernet) é apenas um exemplo.
pg. 7
Valter Roesler
Aplicação
Encapsulamento de
mídia
RTP
RTCP
dados
controle
UDP
IPv4 / IPv6
Unicast ou multicast
Ethernet
2.1.1 Entidades RTP
Às vezes surgem necessidades na transmissão de sinais em tempo real, como, por exemplo,
várias pessoas participando duma conferência de áudio, sendo que algumas estão em enlaces
congestionados ou com máquinas lentas. Para evitar que todos participantes utilizem um
algoritmo de compactação de áudio de baixa qualidade, pode-se utilizar um tradutor (translator).
Outras vezes, pode ser necessário combinar múltiplos fluxos em um só, a fim de distribuir a um
conjunto de receptores, e aí se utiliza o multiplexador (mixer). Essas duas entidades são
importantes para entender o RTP, e são mostradas na figura [PAU 98, pg 195].
Sistema origem / destino
IP=10.16.169.53
SSRC = 87
Troca de codificação
Múltiplos fluxos
Fluxo único
PCM
MP3
SSRC = 46
Sistema origem / destino
IP=10.16.165.29
SSRC = 35
Tradutor
Multiplexador
CSRC = 87, 35
MP3
IP 10.18.32.14
ADPCM
IP 10.13.45.6
SSRC = 46
O tradutor é um sistema intermediário que encaminha os pacotes RTP com o SSRC e
timestamp intactos, porém, modifica serviços de tradução, como, por exemplo, a conversão do
formato de codificação (ADPCM para MP3), ou converter um pacote multicast em vários
pacotes unicast, ou efetuar uma conexão segura com máquinas atrás de firewalls.
O multiplexador é um sistema intermediário que recebe pacotes RTP de uma ou mais
origens, gerando uma única saída com a combinação das diversas origens (e também a tradução
de formato de codificação, se necessário). Como o timestamp das diversas origens pode ser
diferente, o multiplexador efetua os ajustes de tempo (buffers) e gera sua própria seqüência de
tempo para o fluxo concatenado. Assim, todas os pacotes de dados originados no multiplexador
terão o multiplexador como sua origem de sincronização (SSRC).
pg. 8
Valter Roesler
2.1.2 Cabeçalho RTP
O cabeçalho do RTP é visto na figura a seguir.
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
V=2 P X
CC
M
PT
Número de seqüência
Timestamp
Synchronization Source (SSRC) identifier
Contributing Source (CSRC) identifiers
Os primeiros doze bytes existem em todo pacote RTP, enquanto que a lista dos
identificadores CSRC está presente somente quando inserido por um multiplexador. Os campos
têm o seguinte significado [RFC 1889, pg 10]:
•
•
•
•
•
•
•
•
•
•
Versão (V): 2 bits : identifica a versão do protocolo RTP;
Padding (P): 1 bit: se esse bit estiver ligado, o pacote contém um ou mais bytes de
enchimento no final que não fazem parte dos dados úteis, devendo ser ignorados. Esses
bytes podem ser necessários por alguns algoritmos de criptografia com tamanhos fixos de
blocos, ou para enviar muitos pacotes RTP em um protocolo de nível inferior;
Extensão (X): 1 bit: se esse bit estiver ligado, o cabeçalho terá uma extensão com o
mesmo número de bytes, em formato definido na RFC 1889;
Contador de CSRC (CC): 4 bits : número de identificadores CSRC que seguem o
tamanho fixo do cabeçalho;
Marcado r (M): 1 bit: tem o objetivo de permitir eventos significativos, tal como limites
de quadro, serem marcados no fluxo de pacotes;
Payload Type (PT): 7 bits : identifica o formato da carga útil do pacote, de forma que
possa ser interpretado pela aplicação. Um exemplo é áudio codificado em PCM ou
ADPCM, ou vídeo codificado em MPEG ou H.263, e assim por diante;
Número de seqüência: 16 bits : incrementa de um a cada pacote RTP transmitido, e pode
ser usado pelo receptor para detectar perda de pacotes, bem como para restaurar a
seqüência correta do fluxo;
Timestamp: 32 bits : reflete o instante de amostragem do primeiro byte no pacote de
dados do RTP. O instante de amostragem deve derivar de um relógio que incrementa
linearmente no tempo a fim de permitir sincronização e cálculo de jitter. A resolução do
relógio deve ser suficiente para a precisão de sincronização desejada e medição de jitter;
SSRC: 32 bits: identifica a origem da sincronização. Esse número é escolhido
randomicamente, procurando fazer com que todas as fontes de sincronização tenham
identificadores diferentes. Caso haja colisões, o SSRC é modificado de acordo com um
algoritmo determinado na RFC 1889;
CSRC: 32 bits cada identificador: máximo de 15 itens : identifica as fontes que
contribuíram para a carga de dados existente no pacote RTP. Esses campos são inseridos
por multiplexadores, usando os SSRCs das fontes contribuintes. Assim, por exemplo,
para pacotes de áudio de várias fontes que foram multiplexados em pacotes únicos RTP,
o receptor utiliza esse campo para colocar de forma correta quem falou o quê.
2.1.3 Exemplo: conferência de áudio
Um exemplo de uso do RTP é visto na RFC 1889 (pg 5), onde ele é utilizado para
efetivação de uma conferência de áudio em multicast. No início são alocados duas portas UDP
(uma para dados RTP e outra para controle RTCP) e um endereço IP multicast. Essa informação
é transmitida para todos os participantes. A aplicação utilizada pelos participantes envia áudio
pg. 9
Valter Roesler
em pequenos pedaços de 20ms de duração, cada um deles com um cabeçalho RTP, que é
transmitido via UDP na porta especificada anteriormente.
O cabeçalho RTP indica o tipo de codificação de áudio (PCM, ADPCM, MP3) que está
contida no pacote, a fim de que os participantes possam trocar a codificação para permitir a
entrada de um novo participante que está conectado através de uma linha lenta.
Para pacotes que chegam em ordem trocada, o número de seqüência ajuda na
reorganização da informação. Já para atrasos variáveis na rede, a informação de timestamp vai
ajudar o receptor a dimensionar o buffer de recepção, a fim de evitar truncamentos na conversa.
Além disso, o receptor sabe que cada número de seqüência corresponde a 20ms nesse exemplo,
permitindo a ele reconstruir o tempo produzido pela fonte.
Para saber quem está participando da conferência e quão bem está recebendo áudio, a
aplicação de cada pessoa envia uma mensagem multicast periodicamente para a porta RTCP do
grupo, indicando seu nome e a qualidade com que está recebendo a informação.
Para deixar a conferência, a aplicação envia um pacote RTCP BYE, indicando que está
saindo.
/**/ sniffar uma conferência de áudio com RTP e colocar figura aqui.
2.1.4 Exemplo: videoconferência
Numa videoconferência, os pacotes de áudio e vídeo são transmitidos em sessões RTP
separadas, portanto, existem dois pares diferentes de portas UDP e números IP (unicast ou
multicast). A identificação do acoplamento entre as mídias no receptor é obtida através do nome
canônico utilizado pelo protocolo RTCP.
Uma das motivações para esta separação é permitir a alguns participantes na conferência
receber somente um meio (áudio ou vídeo). A sincronização entre áudio e vídeo pode ser obtida
através do timestamp de ambas sessões, juntamente com a utilização do protocolo NTP (Network
Time Protocol), enviado pelo RTCP (pacote SR – Sender Report).
O NTP utiliza um valor de tempo absoluto, que é o número de segundos relativo à 0h de 1o
de janeiro de 1900.
/**/ /* sniffar videoconferência – identificar pacotes RTCP e forma de sincronização intermídia. */
2.2 RTCP
O protocolo RTCP (RTP Control Protocol) tem por objetivo fornecer feedback sobre a
qualidade de serviço obtida na distribuição de dados RTP, e consegue isso através de
transmissões periódicas de pacotes de controle a todos participantes da sessão RTP, utilizando o
mesmo mecanismo de distribuição do RTP (unicast ou multicast), e possuindo uma porta
específica de controle na sessão, conforme descrito anteriormente. Suas funções são [RFC 1889,
pg 15]:
•
•
Fornecer feedback sobre a qualidade de serviço obtida na distribuição de dados RTP.
Exemplos de utilização são: controle de codificadores adaptativos (muda algoritmo de
compactação dependendo da qualidade), diagnóstico de problemas na rede, e outros;
Enviar o nome canônico (CNAME) do transmissor dos dados, utilizado para que todos
saibam quem originou a transmissão. O uso do SSRC para identificar a origem não é
eficaz, visto que pode haver mudança nesse número em caso de conflitos. Além disso,
um transmissor com múltiplas sessões RTP (áudio e vídeo) utiliza um SSRC para cada
sessão, e o receptor precisa um nome canônico para identificar a origem e poder
sincronizar as sessões;
•
•
pg. 10
Valter Roesler
Controle da periodicidade de envio dos pacotes RTCP, a fim de permitir a escalabilidade
do sistema;
Função opcional para permitir o transporte de informações mínimas de controle,
permitindo, por exemplo, que a identificação de cada participante seja apresentada na
interface com o usuário.
Os principais tipos de pacotes utilizados pelo RTCP são o SR (Sender Report), o RR
(Receiver Report), o SDES (Source Description), o BYE e o APP (funções específicas da
aplicação). Os itens a seguir analisam cada um deles com mais detalhes.
2.2.1 SR (Sender Report)
Os pacotes SR (Sender Report) são enviados pelos transmissores, e contém informações de
timestamp NTP, timestamp RTP, número de pacotes enviados, número de bytes enviados, bem
como informações da qualidade dos outros transmissores que chegam a eles. Com os timestamps
(NTP e RTP), o receptor consegue sincronizar mais de uma sessão relacionada (como áudio e
vídeo). A figura a seguir ilustra o formato do pacote SR [RFC 1889, pg 23].
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|
RC
|
PT=SR=200
|
length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SSRC of sender
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
NTP timestamp, most significant word
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
NTP timestamp, least significant word
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
RTP timestamp
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sender's packet count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
sender's octet count
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
SSRC_1 (SSRC of first source)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost |
cumulative number of packets lost
|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
extended highest sequence number received
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
interarrival jitter
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
last SR (LSR)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
delay since last SR (DLSR)
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
SSRC_2 (SSRC of second source)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
...
:
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
profile-specific extensions
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header
sender
info
report
block
1
report
block
2
Os pacotes SR consistem de 3 seções: um cabeçalho de 8 bytes, uma seção de informações
do transmissor, e uma seção de informações de outros transmissores. No final, é possível ainda a
existência de uma quarta seção contendo extensões específicas de perfil. Esta seção não será
explicada neste documento. Os principais campos são explicados a seguir. Para maiores
informações, uma referência é a RFC 1889.
•
•
•
Versão (V): 2 bits: Identifica a versão do RTP, que é a mesma do RTCP, que é 2;
Padding (P): 1 bit: ver RFC 1889;
Reception Report Count (RC): 5 bits: número de blocos de informações de outros
transmissores;
•
•
•
•
•
•
•
•
•
•
•
•
•
pg. 11
Valter Roesler
Packet Type (PT): 8 bits: valor “200”, identifica pacote RTCP SR;
Length: 16 bits: tamanho deste pacote em palavras de 32 bits menos uma. Este tamanho
inclui o cabeçalho;
SSRC: 32 bits: identificador SSRC do transmissor deste pacote;
NTP timestamp: 64 bits: indica o tempo NTP do momento que este pacote foi enviado;
RTP timestamp: 32 bits: corresponde ao mesmo momento do campo NTP, mas nas
mesmas unidades e offset dos pacotes de dados RTP. Com a correspondência do tempo
entre NTP e RTP, é possível efetuar sincronização intermídia;
Sender’s packet count: 32 bits: o número total de pacotes de dados transmitidos desde o
início da transmissão;
Sender’s octet count: 32 bits: número total de bytes de dados úteis (i.e., sem incluir
cabeçalho) transmitidos desde o início da transmissão. Este campo pode ser usado para
estimar a taxa de transmissão média dos dados úteis;
SSRC_n (source identifier): 32 bits: indica o SSRC do transmissor para o qual este
report está sendo gerado. O transmissor envia um bloco com estatísticas de cada
transmissor que ele ouviu desde o último report.
Fraction lost: 8 bits: fração de pacotes de dados perdidos desde o último report. Esta
fração é igual a “número de pacotes perdidos” dividido pelo “número de pacotes
esperado”;
Cumulative number of packets lost: 24 bits: o número total de pacotes de dados RTP
perdidos desde o início da recepção;
Extended highest sequence number received: 32 bits: ver RFC 1889;
Interarrival jitter: 32 bits: estimativa da variação do tempo de chegada dos pacotes
RTP, medido em unidades do timestamp e expresso em um valor inteiro.
Last SR timestamp (LSR) e outros campos: ver RFC 1889.
/**/ sniffar a rede e capturar pacotes RTCP de uma videoconferência, identificando os
campos */
2.2.2 RR (Receiver Report)
Os pacotes RR (Receiver Report) são enviados pelos receptores das sessões RTP
existentes. O formato do pacote RR é o mesmo do SR, exceto que o tipo de pacote é “201” em
vez de “200” e a seção “sender info” é eliminada (cinco palavras contendo os timestamps NTP e
RTP, bem como a contagem de pacotes e bytes enviados pelo transmissor).
2.2.3 SDES (Source Description)
Pacotes SDES (Source Description) contêm informações específicas do transmissor,
identificadas por seu tipo. Estão definidos os seguintes tipos [RFC 1889, pg 34]:
•
•
•
•
•
•
Tipo = 1: CNAME: nome canônico, que identifica univocamente o transmissor, como,
por exemplo, user@domínio;
Tipo = 2: NAME: nome do transmissor, por exemplo “João da Silva, empresa X”;
Tipo = 3: EMAIL: e- mail do transmissor, por exemplo [email protected];
Tipo = 4: PHONE: telefone do transmissor, identificado com o sinal de “+” para o código
internacional. Por exemplo +55 51 991 56118;
Tipo = 5: LOC: localização geográfica, por exemplo “Porto Alegre, RS”;
Tipo = 6: TOOL: nome e versão da ferramenta utilizada para transmitir, por exemplo
“videotool”;
•
•
pg. 12
Valter Roesler
Tipo = 7: NOTE: informação a ser transmitida no momento, como por exemplo, para
enviar o título da palestra sendo efetuada. Essa informação é dependente de perfil, e pode
ser mudada dependendo da aplicação;
Tipo = 8: PRIV: extensões privativas para testes.
2.2.4 BYE
O pacote de BYE indica que um transmissor está deixando a sessão. Existe um campo
opcional de comprimento variável para indicar o motivo da saída.
2.2.5 APP
Pacote destinado a uso experimental à medida que novas aplicações surgem, possuindo um
tipo=“204” e um subtipo descrevendo o tipo de aplicação experimental.
2.2.6 Restrições de tempo nos pacotes RTCP
O protocolo RTCP gera pacotes de controle, e, caso não houvesse restrições, poderia
sobrecarregar a rede numa sessão com um grande número de participantes. Procurando se
adaptar a isso, o tráfego de controle RTCP deve se manter em torno de 5% do tráfego total de
determinada sessão RTP. 25% deste tráfego (1,25% do total) é destinado aos transmissores
(pacotes SR+RR+SDES) e os 75% restantes (3,75% do total) aos receptores (pacotes RR).
Como o tráfego de controle é uma fração constante do tráfego total, à medida que o
número de receptores aumenta, o número de pacotes RTCP por participante diminui [PAU 98,
pg 200].
O intervalo mínimo sugerido entre pacotes RTCP é de 5 segundos (para evitar excesso de
pacotes RTCP), mas numa sessão, o intervalo pode ir de 2 a 5 minutos. Um receptor deve
desconsiderar um participante da estatística caso ele não se manifeste em 30 minutos.
Um pacote RTCP é transmitido após o tempo calculado vezes um tempo randômico entre
0,5s e 1,5s. Isso é para evitar sincronização de pacotes entre várias entidades (transmissores e
receptores), o que ocasionaria uma rajada de tráfego RTCP naquele mo mento.
3 Padrões de multimídia em redes de computadores
Existem muitos padrões atualmente para multimídia em redes de computadores, e os mais
enfatizados neste documento são os do ITU-T e do IETF.
Os padrões de multimídia do ITU-T são os da série H (“Sistemas audiovisuais e de
multimídia”) e estão citados na tabela a seguir. Cada um deles tem uma finalidade específica,
como o H.323, por exemplo, que trata somente da comunicação multimídia em redes de pacotes.
Padrão
H.310
Data
1996
H.320
1997
H.321
1996
H.322
1996
H.323
1998
H.324
1996
pg. 13
Valter Roesler
Descrição
Broadband audiovisual communication systems and terminals:
videoconferência MPEG-2 sobre ATM com alta qualidade
Narrow-band visual telephone systems and terminal equipment:
videoconferência sobre RDSI
Adaptation of H.320 visual telephone terminals to B-ISDN
environments: videoconferência sobre ATM com boa qualidade
Visual telephone systems and terminal equipment for local area
networks which provide a guaranteed quality of service: /**/
Packet based multimedia communications systems:
videoconferência sobre redes de pacotes, como IP e Ethernet
Terminal for low bit rate multimedia communication:
videoconferência sobre sistema telefônico
Cada um dos protocolos da série H especifica um conjunto de outros protocolos para
resolver funções específicas na rede, como, por exemplo, sinalização, codificação de áudio,
codificação de vídeo, e assim por diante. É como se fosse um guarda-chuva, ou seja, um
protocolo que aponta para diversos outros. Quando o H.323 for analisado isso vai ficar mais
claro.
Os padrões multimídia do IETF são definidos nas RFCs. A arquitetura global de
multimídia do IETF atualmente possui protocolos como os seguintes [RFC 2543, pg 8]:
•
•
•
•
•
SIP (Session Initiation Protocol – RFC 2543): estabelece, mantém e encerra chamadas ou
sessões multimídia;
RSVP (Resource Reservation Protocol – RFC 2205): reserva recursos da rede;
RTP (Real-time Transport Protocol – RFC 1889): transporta dados em tempo real,
proporcionando feedback de QoS através do RTCP (RTP Control Protocol), conforme
descrito anteriormente;
RTSP (Real Time Streaming Protocol – RFC 2326): controla entrega de mídia através de
streaming;
SDP (Session Description Protocol – RFC 2327): descreve sessões multimídia.
Os padrões do ITU-T e do IETF conseguem conversar entre si através de gateways. A
seguir será analisado com maiores detalhes o protocolo do ITU para comunicação multimídia
sobre redes de pacotes (o H.323). No item seguinte, o SIP será analisado, e depois será feita uma
comparação entre SIP e H.323 em relação a sinalização e controle, pois ambos são equivalentes
nesse assunto.
3.1 H.323
A recomendação H.323 especifica um conjunto de protocolos de áudio, vídeo e dados a
serem utilizados sobre redes baseadas em pacotes, sejam elas LANs, MANs ou WANs.
Exemplos podem ser redes TCP/IP, tipo a Internet, ATM, ou redes locais Ethernet, Fast- Ethernet
e Token Ring. Essas redes não precisam necessariamente prover garantia de qualidade de serviço
(QoS) [ITU 98]. Essa recomendação teve sua segunda versão aprovada em fevereiro de 1998,
pelo grupo de estudos 16 do ITU-T.
As principais características do H.323 são as seguintes [PRI 99]:
•
•
Interoperabilidade : definindo normas de CODECs de áudio e vídeo, é possível integrar
sistemas de diferentes fabricantes sem problemas;
Gerência de banda : é possível limitar o número de conexões H.323 simultâneas, bem
como a largura de banda utilizada pelas aplicações;
•
•
•
pg. 14
Valter Roesler
Suporte a multiponto: embora H.323 possa suportar conferências com três ou mais
pontos, é especificado um componente chamado MCU (Multipoint Control Unit) a fim de
tornar mais poderosas e flexíveis tais conferências;
Suporte a multicast: extremamente importante para economizar banda em conferências
e transmissões multiponto;
Flexibilidade : Uma conferência H.323 pode incluir equipamentos e redes com diferentes
características. Por exemplo, um participante pode entrar na conferência somente com
áudio, e outro somente com dados, via um terminal que fale a recomendação T.120 do
ITU-T (Data protocols for multimedia conferencing).
A figura a seguir mostra uma visão geral da arquitetura H.323, sua interoperabilidade com
outros terminais e seus principais componentes, que são os Terminais, Gateways, Gatekeepers e
MCUs (Multipoint Control Units) [PRI 99].
O conjunto de terminais H.323, gateways e MCUs controlados por um Gatekeeper é
conhecido como zona H.323, e é mostrado na figura. O Gateway serve para tradução de padrões,
ligando a zona H.323 com outros serviços, tais como o GSTN (General Switched Telephone
Network ), o RDSI (Rede Digital de Serviços Integrados faixa estreita ou faixa larga), e redes
locais com QoS (Quality of Service).
A seguir cada um desses componentes será explicado com maiores detalhes.
Terminal
H.323
MCU
H.323
HUB
Gatekeeper
H.323
Gateway
H.323
LAN com
QoS
GSTN
Rede baseada em pacotes
Terminal
H.323
Terminal
H.323
RDSI-FE
RDSI-FL
Terminal H.310
operando no
modo H.321
Terminal
V.70
Terminal
H.324
Terminal
de voz
Terminal
H.322
Terminal
de voz
Terminal
H.320
Terminal
H.321
Terminal
H.321
3.1.1 Terminais
Terminais são os componentes responsáveis pela comunicação bidirecional em tempo real
com outro terminal, gateway ou MCU. Um terminal pode oferecer somente voz, voz e vídeo, voz
e dados ou voz, dados e vídeo. A norma definiu que voz é obrigatório, mas dados e vídeo são
opcionais. A figura a seguir mostra a recomendação H.323 para terminais [ITU 98, pg 13].
pg. 15
Valter Roesler
Escopo da norma H.323
Eqto de entrada de áudio
(microfone, vídeo cassete)
CODEC de áudio
G.711, G.722,
G.723, G.728, G.729
Receive
Path
Eqto de entrada de vídeo
Câmera de vídeo, vídeo
cassete)
CODEC de vídeo
H.261, H.263
Aplicações de dados
(T.120, etc)
Delay
Camada
Interface
H.225.0
LAN
Controle do sistema
Controle H.245
Controle do sistema
Controle de
chamada
H.225.0
Controle RAS
H.225.0
Sinalização Q.931
Todos terminais H.323 devem ter uma camada H.225.0, uma unidade de controle do
sistema (H245, RAS), uma interface LAN e CODEC de áudio. O CODEC de vídeo e as
aplicações de dados são opcionais [ITU 98, pg 13]. O canal de controle H.245, os canais de
dados e o canal de sinalização da chamada precisam obrigatoriamente de um protocolo confiável
(por exemplo, TCP ou SPX). Já os protocolos de áudio, vídeo e RAS (Registration, Admission
and Status) precisam de um protocolo não confiável (por exemplo, UDP ou IPX). A seguir uma
definição dos elementos da figura anterior (posteriormente os principais protocolos serão
detalhados):
•
•
•
•
CODEC de vídeo (H.261, H.263): codifica o vídeo vindo da fonte (por exemplo, placa
de captura de vídeo) para transmissão. O receptor joga o sinal decodificado para a tela de
vídeo do usuário. A transmissão de vídeo e, conseqüentemente, esse CODEC, é opcional,
mas caso exista, o terminal deve prover, no mínimo, H.261 QCIF (Quarter Common
Intermediate Format);
CODEC de áudio (G.711, G.722, G.723, G.728, G.729): codifica o áudio vindo da
fonte (por exemplo, microfone) para transmissão. No receptor joga o sinal decodificado
para o alto- falante do sistema. Todo terminal H.323 deve ter, no mínimo, o CODEC para
a recomendação G.711, entretanto, em linhas de baixa velocidade (<56Kbps), o G.711
não funciona, portanto, tais terminais devem suportar ou o G.723 ou o G.729 [ITU 98, pg
16];
Canal de dados: suporta aplicações tipo whiteboard, transferência de imagens estáticas,
transferência de arquivos, acesso a banco de dados, e outros;
Unidade de controle do sistema (H.245, H.225.0): fornece sinalização para operação do
terminal H.323. Fornece controle de chamada, sinalização de comandos e indicações, e
assim por diante. Através da negociação do protocolo H.245, é possível usar outros
CODECs de vídeo e outros formatos de imagem. Além disso, mais de um canal de vídeo
pode ser transmitido ou recebido (para enviar o palestrante e a platéia simultaneamente,
ou para receber todos os participantes de uma conferência). Durante o estabelecimento da
•
•
•
pg. 16
Valter Roesler
conexão, são trocadas mensagens de sinalização H.245 “capability exchange”, para
descobrir a capacidade dos terminais, o que permite a escolha da taxa de transmissão em
bits/s, o formato da imagem, algoritmo de compactação, e assim por diante [ITU 98, pg
15];
Controle de RAS (Registration, Admission and Status): utiliza mensagens H.225.0 para
fazer funções de registro, admissão, mudança de largura de banda, status e desligamento
entre Gatekeepers e terminais. Em ambientes que não tem Gatekeeper, o RAS não é
utilizado;
Camada H.225.0: formata as informações (vídeo, áudio, dados) a serem transmitidas ou
recebidas da interface de rede. Além disso, faz controle de erros e numeração de
seqüência, dependendo do meio. A norma H.225.0 [ITU 98a] utiliza os protocolos
RTP e RTCP [RFC 1889] para sincronização e montagem dos pacotes;
Receive Path Delay: é um atraso incluído no fluxo de entrada de dados a fim de manter a
sincronização e controlar o jitter, conseguindo assim, por exemplo, sincronização labial.
3.1.2 Gatekeepers
O gatekeeper é opcional em um sistema H.323, provendo, quando utilizado, os seguintes
serviços de controle de chamada para componentes H.323:
•
•
•
•
Tradução de endereço: é necessário traduzir o endereço LAN dos terminais e gateways
(aliases mais fáceis de decorar) para endereços IP ou IPX, conforme a especificação do
RAS;
Controle de admissão: Autorização de acesso à LAN usando mensagens de “admission
request, confirm e reject” (ARQ, ARC, ARJ);
Gerência de zona : o gatekeeper provê as funções acima para sua zona. O conjunto de
todos terminais, gateways e MCUs controlados por um gatekeeper é conhecido como
zona H.323, como mostra a figura a seguir [PRI 99].
Controle e Gerência de banda : se um gerente especificou um número máximo de
conferências na rede, o gatekeeper pode deixar de aceitar conexões após esse máximo ter
sido atingido, limitando a largura de banda utilizada pelo H.323 como um todo;
Zona H.323
Terminal
Gatekeeper
Gateway
Terminal
HUB
Terminal
Terminal
Terminal
HUB
Roteador
Roteador
MCU
3.1.3 Gateways
O Gateway também é opcional em um sistema H.323, sendo utilizado quando é necessário
efetuar conversão entre formatos para permitir a comunicação entre terminais H.323 e outros
tipos. Essa função inclui conversão de formatos de transmissão (por exemplo, H.225 para/de
H.221), e formatos de comunicação (por exemplo, H.245 para/de H.242). A figura a seguir
mostra um exemplo de uso do gateway interligando um terminal H.323 e a telefonia pública.
pg. 17
Valter Roesler
As principais aplicações do gateway são as seguintes [PRI 99]:
•
•
•
Estabelecer links com terminais analógicos da telefonia pública;
Estabelecer links através de redes RDSI com terminais compatíveis H.320;
Estabelecer links através de redes públicas de telefonia com terminais compatíveis H.324.
3.1.4 MCUs
O Multipoint Control Unit também é um elemento opcional, seu objetivo é permitir
conferências entre três ou mais usuários. No H.323, um MCU consiste de um Multipoint
Controller (MC) e zero ou mais Multipoint Processors (MPs). Isso é importante principalmente
para conferências multicast, que são controladas por ele. O fluxo de áudio e vídeo é processado
pelo MP.
MC e MP podem existir como componentes separados ou serem implementados junto com
outros componentes H.323. Pode haver conferências de dois tipos: centralizada e
descentralizada [ITU 98, pg 5].
Uma conferência multiponto descentralizada utiliza multicast para enviar dados entre os
participantes, não necessitando MP para isso, entretanto, a parte de controle é feita utilizando o
protocolo H.245 para um MC, que gerencia a conferência.
Uma conferência multiponto centralizada é aquela onde cada um dos terminais
participantes envia sinalização de controle, áudio, vídeo e dados para o MCU. O MC do MCU
gerencia a conferência, e o MP processa o áudio, vídeo e dados, retornando os fluxos
processados a cada terminal.
Na figura a seguir tem uma ilustração de conferência centralizada e descentralizada.
Áudio e Vídeo multicast
Áudio e Vídeo unicast
Descentralizado
Centralizado
pg. 18
Valter Roesler
3.1.5 Sinalização no H.323
O H.323 utiliza uma série de protocolos de sinalização, conforme mostrado na figura a
seguir. A explicação a seguir assume a existência do gatekeeper, mas caso ele não exista, as
mensagens de sinalização são trocadas diretamente entre origem e destino [SCH 99], [ITU 98].
Inicialmente, são trocadas mensagens H.225 ARQ (Admission Request) e ACF (Admission
Confirm) para registro no gatekeeper (mensagens utilizando o canal RAS - Registration,
Admission and Status - do gatekeeper). Na figura não mostra, mas o destino também deve se
registrar no seu gatekeeper (visto na tabela após a figura).
Logo em seguida, deve ser estabelecido o canal confiável (TCP) de sinalização (call
signalling channel) para trocar mensagens de controle H.225.0 (que, por sua vez, utiliza
mensagens Q.931 para sinalização).
Da mesma forma que foi estabelecido um canal confiável de sinalização H.225.0 (via
Q.931), deve ser estabelecido um canal confiável (TCP) de controle para o H.245. A sinalização
do H.245 efetua a troca de capacidades entre origem e destino, determinando mestre e escravo
(para controle MCU), formato do fluxo de áudio, formato do fluxo de vídeo, e assim por diante.
A tabela a seguir mostra com maiores detalhes o fluxo de mensagens para efetuar uma
conferência de áudio no H.323 [SCH 99]. T1=Terminal1, T2=Terminal2, G=gatekeeper,
RTT=Round Trip Time.
RTT
1
2
3
4
5
6
7
Origem
T1
G
T1
T2
G
T2
T1
T1
T2
T1
T2
T1
T1
T2
T1
T2
T1
Destino
G
T1
T2
G
T2
T1
T2
T2
T1
T2
T1
T2
T2
T1
T2
T1
T2
pg. 19
Valter Roesler
Descrição
H.225 RAS: Admission Request (ARQ) para T1
H.225 RAS: Admission Confirm (ACF) para T1
TCP SYN para abertura de canal de sinalização Q.931
H.225 RAS: Admission Request (ARQ) para T2
H.225 RAS: Admission Confirm (ACF) para T2
TCP SYN ACK para confirmação canal Q.931
TCP ACK – estabelece conexão
H.225: Q.931: setup
H.225: Q.931: connect
TCP SYN para abertura de canal de controle H.245
TCP SYN+ACK para confirmação do canal H.245
TCP ACK – estabelece conexão H.245
Capabilities Exchange – Mestre/Escravo
Capabilities Exchange – Mestre/Escravo
H.245: abre canal de áudio (open)
H.245: abre canal de áudio (ack+open)
H.245: abre canal de áudio (ack)
3.1.6 Exemplo de conferência H.323
3.1.6.1 Exemplos de Terminais H.323
/**/ /* falar do Netmeeting, VIC??, CU-Seeme */
3.1.6.2 Exemplos de Gatekeepers
/**/ /* procurar gatekeepers H.323 comerciais */
3.1.6.3 Exemplos de Gateways
/**/ /* procurar gateways H.323 comerciais */
3.1.6.4 Exemplos de MCUs
/**/ /* procurar MCUs H.323 comerciais */
3.2 SIP
O protocolo SIP (Session Initiation Protocol), definido na RFC 2543, é um protocolo da
camada de aplicação que tem por objetivo prover a sinalização necessária para estabelecer,
modificar e terminar chamadas ou sessões multimídia. Tais sessões multimídia incluem
conferências, ensino a distância, voz sobre IP, distribuição de vídeo e outras aplicações similares.
Os participantes podem se comunicar via multicast, unicast ou de ambas formas, e também via
TCP ou UDP.
No protocolo, são definidas cinco funções para iniciar e terminar comunicações
multimídia:
•
•
Localização de usuário: determinação do endereço a ser usado para comunicação. O
endereço SIP é da forma user@host. A parte User é um nome de usuário ou número de
telefone, e a parte host é um nome de domínio ou número de rede. Em redes
heterogêneas, SIP pode ser usado para determinar que o interlocutor pode ser encontrado
via H.323, obter o endereço do usuário e endereço do gateway via H.245 e usar o H.225.0
para estabelecer a chamada;
Capacidades do usuário: determinação da mídia e seus parâmetros;
•
•
•
pg. 20
Valter Roesler
Disponibilidade do usuário: determinação da vontade do interlocutor de entrar na
comunicação;
Estabelecimento da chamada (call setup): estabelecimento dos parâmetros de chamada
entre participantes. Utiliza para isso os métodos INVITE e ACK. O método INVITE
contém, normalmente, uma descrição da sessão, sendo utilizado um formato específico,
como o SDP, descrito na RFC 2327;
Tratamento da chamada (call handling): inclui transferência e término de chamadas. O
término de chamadas é com o método BYE.
3.3 Comparação entre SIP e H.323
O H.323 está sendo padronizado pelo ITU-T, e o SIP faz parte da trilha do IETF. Em
termos de sinalização de dados, é possível fazer uma comparação entre ambos, como pode ser
visto em [SCH 99] e [SCH 99a].
H.323 compreende uma série de protocolos, como RTP para transporte de dados, H.225.0
(com sinalização RAS e Q.931) para configuração, H.245 para negociação de formato, H.450
para serviços suplementares e H.332 para conferências tipo “painel” [SCH 99].
O SIP oferece uma funcionalidade similar ao H.225.0, Q.931, RAS, H.245 e H.450.
3.3.1 Atraso de conexão
Dependendo do uso ou não de um gatekeeper, o estabelecimento de conexão no H.323
pode levar de 6 a 7 RTTs (Round Trip Times), que significa todas as vezes que o origem tem que
ficar esperando pelo interlocutor para continuar o estabelecimento de conexão (isso foi visto
anteriormente). No H.323 v2 com “fast connect ”, o atraso é reduzido para 2,5 RTTs. A adição do
anexo E (UDP -based signalling), pode reduzir para 1,5 RTTs [SCH 99].
O estabelecimento de conexão com o SIP via UDP necessita de 1,5 RTTs. Um pacote
INVITE do terminal origem, seguido de um 200 OK do destino e um CONNECTED do origem,
como mostra a figura a seguir.
INVITE
200 OK
CONNECTED
3.3.2 Escalabilidade
O H.323 necessita de um nível de transporte confiável para o H.245 e Q.931, levando a
problemas de escalabilidade. O SIP pode usar tanto UDP como TCP. Se desejado, pode também
utilizar ATM AAL5, IPX ou X.25, sem mudanças no protocolo.
3.3.3 Tamanho da conferência
O H.323 permite conferências através do MCU (Multipoint Control Unit), até mesmo para
conferências pequenas. Caso o usuário de uma pequena conferência esteja sendo o MC
(Multipoint Controller), e desligue sua máquina, a conferência inteira termina. O uso obrigatório
de MCs provoca problemas de escalabilidade.
pg. 21
Valter Roesler
O SIP não necessita do MC, suportando conferências através de multicast diretamente
pelos terminais, permitindo uma escalabilidade de 2 a milhões de membros [SCH 99a].
3.3.4 Uso de novos CODECS
SIP funciona com qualquer tipo de CODEC, utilizando SDP (Session Description
Protocol) para informar os CODECS suportados por uma entidade. Os CODECS são
identificados por strings, e podem ser registrados por qualquer pessoa ou grupo no IANA.
No H.323, cada CODEC deve ser registrado centralmente e normalizado. Atualmente,
somente os CODECS desenvolvidos pelo ITU possuem códigos. Como a maioria deles possuem
direitos de propriedade intelectual, não existem CODECS free abaixo de 28,8 Kbit/s que possam
ser usados num sistema H.323 [SCH 99a, pg 2].
3.3.5 Formato de endereço
O destinatário de uma conexão SIP pode ser qualquer URL, incluindo mailto, phone,
H.323 e http. H.323 v1 permite endereçar qualquer host diretamente (mas sem nome de usuário),
ou usar um alias. Todos aliases devem ser resolvidos pelo gatekeeper.
3.3.6 Complexidade
A especificação do SIP é bem menor que a das sinalizações Q.931 e H.245, tornando mais
simples o sistema. Para se ter uma idéia, a especificação do SIP tem um total de 128 páginas,
enquanto a soma das especificações base de sinalização do H.323 dá um total de 736 páginas
[SCH 99a]. H.323 define centenas de elementos, enquanto o SIP define somente 37 cabeçalhos.
Uma implementação básica do SIP funciona com quatro cabeçalhos (To, From, Call-ID e Cseq)
e três tipos (INVITE, ACK e BYE).
Existem outras diferenças entre SIP e H.323 que não serão analisadas neste documento,
mas podem ser encontradas nas referências passadas no início deste item.
4 Compressão de áudio e vídeo
Os itens a seguir resumem algumas técnicas de compressão de áudio e vídeo. Os itens em
azul se referem a vídeo, os em vermelho a áudio e vídeo, e em verde se refere a somente áudio.
•
•
•
•
•
Redundância Espacial: valores dos pixels próximos são bastante correlacionados
Redundância em escala: bordas retas e regiões constantes são invariáveis quando
reescalando
Redundância em freqüência: um sinal mais forte pode mascarar sinais de mesma
freqüência mais fracos
Redundância temporal: quadros adjacentes de vídeo normalmente possuem pouca
mudança
Redundância estéreo: existem correlações entre canais de áudio estéreo que podem ser
comprimidas
A compressão tem algumas características, citadas a seguir:
•
•
•
•
•
•
Sem perdas: dados originais podem ser recuperados precisamente
Com perdas: ocorrem perdas na compressão
Intraframe: quadros são codificados independentemente
Interframe: leva em conta quadros anteriores e futuros
Simétrica: tempos de codificação e decodificação iguais
Assimétrica: tempo de codificação maior que decodificação
•
•
pg. 22
Valter Roesler
Tempo real: atraso de codificação não deve exceder 50ms
Escalável: quadros codificados em níveis de resolução diferentes
A compressão sem perdas gera arquivos maiores (não comprime tanto), entretanto,
consegue uma qualidade maior, pois o receptor consegue obter uma imagem idêntica à que foi
transmitida. A figura a seguir mostra a relação entre qualidade e largura de banda para
compressão com e sem perdas.
Qualidade
alta
Compressão
com perdas
Compressão
sem perdas
baixa
baixa
alta
Largura de
banda
Dependendo do tipo de compressão desejada, deve-se utilizar o algoritmo correspondente,
como mostram os itens a seguir:
•
•
•
Entropy coding (sem perdas): Aritmética, huffman, run- length
Source coding (com perdas): Differencial Pulse Code Modulation, Discrete Cosine
Transform, Discrete Wavelet Transform, Fourier Transform, Motion-compensated
prediction
Hybrid coding (combinação dos dois): Fractal, H.261, H.263, JPEG, MPEG vídeo,
MPEG áudio, Perceptual audio coder, wavelet image compression.
A codificação híbrida consegue as melhores taxas de compressão, pois efetua inicialmente
uma compressão com perdas (a fim de aproveitar bem as redundâncias do sinal), e em seguida
aplica uma compressão sem perdas, a fim de explorar outras características que podem ainda ser
comprimidas. A figura a seguir ilustra o processo.
Dados não
comprimidos
Preparação
Source
Coding
Entropy
Coding
Dados
comprimidos
Um exemplo de compressão pode ser o DPCM (PCM diferencial). Para a seqüência de
amostras 10,12,14,16,18 e 20, o DPCM forma 10,2,2,2,2,2. Aplicando posteriormente o método
run- length encoding, fica 10!52.
5 Padrões de áudio e vídeo
A seguir serão analisados alguns padrões e aspectos relevantes para a transmissão de áudio
e vídeo, base para as comunicações multimídia em rede. O conhecimento de tais padrões é
importante para adaptar as condições da rede à aplicação.
pg. 23
Valter Roesler
5.1 Codificação de áudio
Os sinais de voz que partem do ser humano e de instrumentos musicais são analógicos e
sonoros, ou seja, o ar é empurrado com mais ou menos intensidade, um determinado número de
vezes por segundo, gerando uma onda que se propaga. Quando atinge o ouvido, este decodifica
as ondas sonoras e as transforma em percepções ao cérebro, que identifica um padrão e monta
uma mensagem.
A freqüência da voz humana, ou seja, o número de vezes por segundo que o ar é
empurrado, é dada pelas cordas vocais, gerando um som mais agudo (de maior freqüência), ou
mais grave (de menor freqüência). Normalmente, o ser humano consegue emitir sinais sonoros
entre 100 Hz e 8.000 Hz (8KHz), aproximadamente. Um ouvido humano perfeito consegue
captar de 16 Hz a 18.000 Hz, aproximadamente.
Entretanto, numa conversação normal, as freqüências estão entre 300Hz e 3400Hz. Assim,
visando utilizar melhor o canal, criou-se uma largura de banda de 4KHz para canais de telefonia,
que é o que se utiliza atualmente nas ligações. Isso foi feito para conseguir mais ligações entre
centrais públicas utilizando o mesmo meio físico, que é o princípio da multiplexação 1 , visto
através da figura a seguir. Já instrumentos musicais atingem freqüências bem mais altas. O
piano, por exemplo, vai normalmente de 20Hz a 7KHz (chegando a 18KHz), e o violino vai de
200Hz a 10KHz (chegando a 20KHz).
Limita em 4KHz
CENTRAL
PÚBLICA
CENTRAL
PÚBLICA
Vários canais de 4KHz
multiplexados na mesma linha
Para transmissão de áudio em redes de computadores, vale ressaltar os seguintes itens:
•
•
Digitalização: é necessário digitalizar o sinal para transformar os sinais analógicos em
bits, necessário para transmissão em redes de computadores;
Compressão: a compressão é usada para minimizar o uso de largura de banda. O padrão
PCM (G.711 do ITU-T) necessita 64Kbps para transmissão, enquanto o G.729 utiliza
apenas 8Kbps. Uma transmissão com duração de 30 segundos no padrão G.711
demandaria 240.000 bytes, enquanto que a mesma transmissão com o G729 iria
necessitar de 30.000 bytes, ou 1/8 da anterior. A tabela a seguir mostra algumas taxas de
transmissão sem compressão;
Formato
Telefonia
Teleconferência
CD rom
Digital Audio Tape
•
1
Amostragem
8000/8bits/mono
16000/16bits/mono
44100/16bits/stereo
48000/16bits/stereo
Bit rate
64 Kbit/s
256 Kbit/s
1.410 Kbit/s
1.536 Kbit/s
Qualidade do sinal: a qualidade do sinal está relacionada com a freqüência de
amostragem e número de bits gerados por amostra. Para sinais de voz até 4KHz, é
suficiente utilizar 8000 amostras por segundo a 8 bits por amostra (resultando em
64Kbps), pois, segundo Nyquist, é necessário o dobro da freqüência para poder recuperar
Multiplexar é utilizar a mesma linha física para transmitir vários canais
•
pg. 24
Valter Roesler
completamente o sinal. Entretanto, o mesmo número de amostras não é suficiente para
uma qualidade de CD, e na prática utiliza-se 44,1KHz com 16 bits por amostra estéreo,
gerando a necessidade de mais de 1,4Mbps (44100x16x2). Na prática, utiliza-se algum
algoritmo de compressão do sinal, como o MP3, que consegue qualidade de CD com
128Kbps, ou qualidade de FM com 56Kbps;
Latência de codificação: em aplicações que exigem interatividade, como, por exe mplo,
uma conversa telefônica, manter a latência baixa é muito importante. O G.711 possui
uma latência de codificação desprezível, enquanto que o MP3 precisa de mais de 50ms
para codificar o áudio.
A tabela a seguir mostra um resumo de alguns padrões utilizados atualmente para
codificação e transmissão de áudio.
Padrão Data
G.711 1988,
1993
G.722
1988,
1993
G.723
1996
G.728
1992,
1997
G.729
1996
MP3
1992
AAC
1998
Descrição
Pulse Code Modulation (PCM) of voice frequencies: utiliza 8000 amostras por segundo, onde
cada amostra tem 13 bits que, comprimindo de acordo com a lei A ou µ, fica 8 bits, gerando taxa
de transmissão de 64Kbps. Feito para freqüências de voz, ou seja, até 4KHz [ITU 93]. A latência
do algoritmo é menor que 1ms.
7 kHz audio-coding within 64 kbit/s: utiliza 16000 amostras por segundo, onde cada amostra
tem 14 bits que, comprimindo na técnica sub-band ADPCM, gera taxa de transmissão de
64Kbps. Pode operar a 56Kbps com um canal de dados auxiliar de 8Kbps, ou 48Kbps com canal
de dados auxiliar de 16Kbps [ITU 93a].
Speech coders: dual rate speech coder for multimedia communications transmitting at 5.3 and
6.3 kbit/s: utilizado para transmissão de voz (4KHz). O CODEC para a taxa de 6,3Kbps é MLQ
multipulso, e para a de 5,3Kbps é o ACELP. Ambos utilizam a técnica de previsão linear (linear
predictive analysis by synthesis coding). Esse tipo de algoritmo utiliza muito cálculo em ponto
flutuante, requerendo um poder computacional bem maior do que os baseados em PCM puro. A
latência do algoritmo é de 37,5ms [ITU 96] ou 100ms, no caso do Internet Phone da Intel, que
utiliza G.723 para codificar áudio [PAS 97a].
Coding of speech at 16 kbit/s using low-delay code excited linear prediction: utilizado para voz
(4KHz), esse algoritmo mantém a essência do CELP, entretanto, utiliza uma análise de ganho e
previsão linear para reduzir a latência do algoritmo, que fica em 0,625ms [ITU 92]. O anexo H
da norma [ITU 97] mostra uma técnica para usar CELP de baixo atraso com uma largura de
banda ainda menor, provocando uma taxa de bits variável de até 12,8Kbps ou 9,6Kbps,
dependendo da técnica usada.
Coding of speech at 8 kbit/s using Conjugate Structure Algebraic-Code-Excited LinearPrediction (CS-ACELP): utilizado para voz (4KHz), recebe um sinal digital codificado segundo
a norma G.712 e o codifica em 8Kbps segundo o algoritmo CS-ACELP [ITU 96a]. A latência
gerada fica em torno de 25ms [PAS 97a].
O MP3 (ou MPEG áudio layer 3) é um algoritmo de compressão de voz utilizado no MPEG-1 ou
no MPEG-2 BC (Backward Compatible), e layer representa uma família de algoritmos de
codificação que provê sons de alta qualidade necessitando de uma baixa largura de banda, com
taxa de bits variável [THO 98]. A largura de banda e a qualidade do sistema podem ser
especificados na codificação do arquivo de áudio. As taxas de bit variam de 8Kbps a 320Kbps
[FAQ 98], gerando qualidade de CD estéreo em taxas de 128Kbps. Devido à complexidade do
algoritmo, a latência teórica é de 59ms, mas na prática é superior a 150ms [FAQ 98].
A codificação MPEG-2 AAC (Advanced Audio Coding) permite uma alta qualidade de som com
taxas menores que MP3. Para tanto, utiliza alguns algoritmos modernos para filtragem,
eliminação de redundâncias, diminuição de ruído, previsão linear, codificação de Huffmann e
codificação estéreo [THO 98]. O resultado é uma taxa de bits 30% menos do que para uma
qualidade equivalente de MP3. Esse tipo de codificação não é compatível com versões anteriores
de áudio, ou seja, um decodificador MPEG-1 não vai conseguir decodificar um áudio AAC. As
taxas de bit variam de 8Kbps a 160Kbps [MPE 99].
5.1.1 Testes de áudio com Netmeeting
Em 10/7/00 foram efetuados alguns testes de transmissão de áudio com o netmeeting. O
ambiente consistia de 2 computadores (PIII 450MHz e K6-2 350MHz) ligados via cabo cross,
pg. 25
Valter Roesler
com o Netmeeting configurado para rede local. O K6II transmite áudio e mais nada passa na
rede. Foi utilizado um sniffer de redes para analisar os pacotes. Um resumo dos resultados foi:
•
•
•
A transmissão utilizou pacotes UDP + IP + Ethernet, com tamanho total de 126 bytes
(sem contar preâmbulo nem CRC). Ethernet = 14 bytes, IP=20 bytes, UDP=8 bytes,
áudio e níveis superiores=84 bytes;
Atraso de um segundo;
Não mudou a taxa de transmissão, independente do CODEC, provavelmente devido a
alguma característica do aplicativo.
A seguir uma descrição dos testes. Evidentemente existe alguma condição no software que
decide utilizar o que bem entende, e não aceita a configuração da interface.
•
•
•
•
CODEC Microsoft ADPCM, 8000Hz, 4bit, mono : Taxa de 11,54 quadros Ethe rnet por
segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
CODEC Microsoft G.723.1, 8000Hz, mono, 6400 bps : Taxa de 11,54 quadros Ethernet
por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
CODEC Microsoft G.723.1, 8000Hz, mono, 5333 bps : Taxa de 11,54 quadros Ethernet
por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
CODEC Lernout&Hauspie SBC 16Kbps, 8000Hz, 16 bits, mono : Taxa de 11,54
quadros Ethernet por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
5.1.2 Testes de áudio com o RAT (Robust Audio Tool)
Em 10/7/00 foram efetuados alguns testes de transmissão de áudio com o RAT (Robust
Audio Tool). O ambiente consistia de 2 computadores (PIII 450MHz e K6-2 350MHz) ligados
via cabo cross, com o RAT configurado para rede local. O K6II transmite áudio e mais nada
passa na rede. Foi utilizado um sniffer de redes para analisar os pacotes. Um resumo dos
resultados foi:
•
•
Pacotes UDP + IP + Ethernet. Tamanho total sem contar preâmbulo nem CRC. Ethernet
= 14 bytes, IP=20 bytes, UDP=8 bytes, áudio e níveis superiores=resto do pacote.
A qualidade foi muito parecida com todos CODECS, exceto o LPC.
A seguir uma descrição dos testes. Pode-se ver que neste caso a taxa de transmissão
respeitou a configuração da interface com o usuário, entretanto, a taxa em bit/s foi muito superior
à do Netmeeting, e a única equivalente (LPC) ficou muito ruim.
•
•
•
•
•
CODEC – Lei A: Atraso de 0,8s; Pacote com 40ms : Taxa de 25,6 quadros Ethernet por
segundo. Áudio e níveis superiores=332 bytes. Taxa de transmissão: 25,6*332 = 65Kbps.
Pacote com 20ms : Taxa de 50 quadros Ethernet por segundo. Áudio e níveis
superiores=172 bytes. Taxa de transmissão: 50*172=65Kbps.
CODEC DVI – 40ms : Atraso de 0,8s; Taxa de 25,5 quadros Ethernet por segundo.
Áudio e níveis superiores=176 bytes; Taxa de transmissão: 25,5*176 = 34Kbps.
CODEC 16 bit linear – 40ms : Atraso de 0,8s; Taxa de 25,7 quadros Ethernet por
segundo. Áudio e níveis superiores=652 bytes. Taxa de transmissão: 25,7*652 =
130Kbps.
CODEC GSM – 40ms: Atraso de 0,7s; Taxa de 25,5 quadros Ethernet por segundo.
Áudio e níveis superiores=88 bytes. Taxa de transmissão: 25,5*88 = 16Kbps.
CODEC LPC – 40ms : Atraso de 0,9s; Não dava para entender as palavras... Muito ruim.
Taxa de 25 quadros Ethernet por segundo. Áudio e níveis superiores=40 bytes. Taxa de
transmissão: 25*8 = 8Kbps.
pg. 26
Valter Roesler
5.1.3 Teste de tamanho de arquivo de áudio com o Goldwave
Em 11/7/00 efetuou-se um teste com o aplicativo goldwave a fim de ver o tamanho dos
arquivos de áudio gerados com qualidades diferentes. Todos os testes geraram um arquivo com 5
segundos de áudio. O resultado pode ser visto a seguir, onde se pode ver que a teoria confere
com a prática.
•
•
•
8bits, 8000am/s, mono, 5s : arquivo = 40.000 bytes. Teórico = 8000x1x5 = 40.000 bytes.
8bits, 16000am/s, mono, 5s : arquivo=80.000 bytes. Teórico = 8000x2x5 = 80.000 bytes.
16bits, 44100am/s, stereo, 5s: arquivo=882000 bytes. Teórico = 44100x2x2x5 =
882.000 bytes.
5.2 Codificação de vídeo
Vídeo pode ser definido como uma seqüência de imagens paradas que, quando
apresentadas em uma taxa suficientemente rápida, dão a impressão de movimento ao ser
humano, como, por exemplo, os seguintes sistemas analógicos:
•
•
NTSC (National Television Standards Committee) 525x60: 30 quadros por segundo,
sendo apresentados em 525 linhas e, de forma entrelaçada, 60 vezes por segundo (cada
quadro é dividido em linhas pares e ímpares) para melhorar a sensação de movimento;
PAL (Phase Alternation Line) 625x50: 25 quadros por segundo, sendo apresentados em
625 linhas e, de forma entrelaçada, 50 vezes por segundo (cada quadro é dividido em
linhas pares e ímpares) para melhorar a sensação de movimento.
Para apresentar a imagem em meios digitais, é necessária a conversão entre os padrões
analógicos (25 ou 30 quadros por segundo entrelaçados) e digitais (freqüência de atualização de
tela no computador é normalmente entre 60 e 80Hz). O resultado é que no computador o quadro
é apresentado mais de uma vez, de acordo com a freqüência do monitor (60Hz, 75Hz, etc).
O PAL (Phase Alternation Line) utiliza 625 linhas e 25 qps. A resolução espacial da TV é
4x3, resultando 833x625 (nem tudo visível). O equivalente digital no PAL é o CIF (Common
Intermediate Format), equivalente a um quarto do tamanho da área visível da imagem PAL
(352x288)
O NTSC (National Television Standards Committee) utiliza 525 linhas e 30qps. Mantendo
o aspecto da TV de 4x3, o resultado é 700x525 (nem tudo visível). O equivalente CIF no NTSC
é 320x240.
Da mesma forma que no áudio, os fatores digitalização, compressão, qualidade do sinal e
latência são extremamente importantes na transmissão de vídeo. Basicamente, existem três
pontos que podem ser ajustados para modificar a qualidade e a taxa de transmissão: a resolução
espacial (largura x altura) da imagem, a taxa de quadros e os passos de quantização [MCG 99].
•
Resolução espacial: significa o tamanho do quadro, ou seja, a relação entre sua largura e
altura. Em meios digitais, para permitir que uma recomendação possa ser utilizada em
tanto em regiões do planeta que utilizam NTSC como as que utilizam PAL, normalmente
se utiliza o formato CIF (Common Intermediate Format) [ITU 93b] ou SIF (Standard
Interchange Format). A tabela a seguir mostra formatos de vídeo e alguns padrões onde
esses formatos são utilizados [PRI 99], [SHA 96], [MCG 99];
Formato
Sub-QCIF
QCIF
CIF
4CIF
16CIF
Número de pixels
128x96
176x144
352x288
702x576
1408x1152
Padrões
H.263
H.261, H.263
Opcional no H.261 e H.263
Opcional no H.263
Opcional no H.263
Sub-QSIF
QSIF
SIF
CCIR-601
88x60
176x120
352x240
720x480
1280x720
MPEG
MPEG
MPEG-1, MPEG-2
MPEG-2
Grand Alliance High Definition
Television Standard
Grand Alliance High Definition
Television Standard
1920x1080
•
•
pg. 27
Valter Roesler
Taxa de quadros : representa o número de quadros sucessivos por segundo. Para uma
boa qualidade, o ideal é utilizar acima de 24 quadros por segundo (padrão atual dos
cinemas). Em termos de compressão da imagem, quanto mais quadros por segundo
melhor a taxa de compressão, pois é possível codificar somente as mudanças entre
quadros. Isso permite a padrões que exploram essa característica, como o MPEG,
comprimir 50 a 70 vezes uma transmissão 352x240 30 quadros por segundo, enquanto
padrões que não exploram, como o M-JPEG, comprimem apenas 15 a 30 vezes [MCG
99]. Entretanto, quando a taxa de quadros é baixa, como, por exemplo, 1 quadro por
segundo, a diferença na compressão entre MPEG e M-JPEG não é significativa;
Passo de quantização: quanto maior o número de amostras de um vídeo por segundo,
maior a sua qualidade, da mesma forma que foi visto na parte de áudio.
A largura de banda necessária para transmissão de vídeo é maior que para o áudio, como
pode ser visto no exemplo a seguir.
A figura a seguir possui um formato de 352x288 pixels com 256 cores (cada pixel precisa
de um byte). Para efetuar sua transmissão pela rede, são necessários aproximadamente
100Kbytes (352x288x1). Para enviar o peixinho se movendo a 30 quadros por segundo sem
compressão alguma, seria necessário 30 vezes esse tamanho, ou 3Mbytes (24Mbit/s).
Uma figura vale mais que mil palavras, mas uma figura não comprimida vale muitos
megabytes. A tabela a seguir mostra algumas taxas de vídeo não comprimido.
1 seg
1 min
1 hora
640x480
27 Mbytes
1,6 Gbytes
96 Gbytes
pg. 28
Valter Roesler
320x240
6,75 Mbytes
400 Mbytes
24 Gbytes
160x120
1,68 Mbytes
100 Mbytes
6 Gbytes
Felizmente com técnicas de compressão de vídeo que serão vistas em seguida consegue-se
uma qualidade muito boa a taxas bem razoáveis. O MPEG-1, por exemplo, foi feito para
produzir sons e imagens de média qualidade a taxas de aproximadamente 1,5 Mbps, ou seja, que
sejam suportadas por um CD-ROM. A norma que descreve o MPEG-1 tem o seguinte título:
Coding of moving pictures and associated audio for digital storage media at up to about 1,5
Mbit/s [CHI 96] (entretanto, ele pode ser configurado para transmissões em diversas taxas, tanto
menores como maiores, até 5 Mbps [SHA 96]. Já o H.261 consegue transmitir vídeo a
px64Kbps, com p variando de 1 a 30.
A compressão do vídeo não é linear de acordo com a taxa de quadros por segundo e sua
resolução espacial, ou seja, se no formato QCIF a 30 quadros por segundo obtinha-se uma taxa
de transmissão de 1Mbps, não quer dizer que se utilizando o formato CIF a taxa suba para
4Mbps (com a mesma qualidade). Isso porque as técnicas de compressão exploram as
ambigüidades entre pixels adjacentes, bem como redundâncias no quadro. Com mais pixels, a
tendência é ter mais ambigüidades, e obter-se taxas de compressão maiores.
A seguir será analisada a codificação de vídeo no MPEG, pois suas técnicas também são
utilizadas em outros padrões, mostrando alguns conceitos importantes para comp reender a
compressão e codificação de vídeo. Além disso, as normas H.261 e H.263 do ITU-T são muito
similares ao MPEG, possuindo as mesmas vantagens e desvantagens, entretanto, o MPEG
consegue uma taxa de compressão ligeiramente superior [MCG 99].
5.2.1 Codificação de vídeo no M-JPEG
Muitos CODECs de vídeo utilizados hoje em dia são baseados no JPEG (Joint
Photographic Experts Group) que, como o nome indica, encaram o vídeo como uma seqüência
de quadros ou imagens estáticas. Dentro dessa linha ficam o Motion-JPEG, e o Cinepak. A
compressão nessa linha é intraframe, ou seja, pode-se comprimir cada quadro isoladamente na
hora da transmissão.
O M-JPEG utiliza a mesma codificação do JPEG, não fazendo codificação entre os frames,
assim, o formato da edição é “não linear”, facilitando assim a edição de imagens.
Um exemplo de seqüência de quadros M-JPEG é “I I I I I I ...”, ou seja, todos quadros são
do tipo “I” (intra frames, ou quadros completos, como será definido adiante).
5.2.2 Codificação de vídeo no MPEG
O MPEG trabalha de uma forma bem mais complicada que o M-JPEG, introduzindo a
noção de seqüência de quadros, ou seja, permite a comparação entre o quadro atual e o seguinte,
fazendo com que somente a diferença entre eles seja armazenada. Isso garante taxas de
compressão muito mais altas. A compressão dessa forma é dita interframes [SHA 96]. Assim,
MPEG não precisa armazenar todo quadro, mas somente o que é único em cada quadro.
Um fluxo MPEG efetua compressão através de três tipos de quadros: I (intra frames), P
(predicted frames) e B (bi-direcional frames), que são configurados no CODEC. A figura a
seguir mostra um exemplo genérico de funcionamento, e o significado de cada quadro é o
seguinte:
•
Tipo I (intra frames): são os quadros completos, ou seja, os quadros contendo toda a
informação, tornando-os aptos a serem o ponto de partida para a decodificação. Os
quadros I possuem o maior tamanho de todos, e são codificados com JPEG.
•
•
pg. 29
Valter Roesler
Tipo P (predicted frames): são os quadros baseados no anterior (ou intra ou predicted).
Eles também podem ser referência para o próximo quadro do tipo predicted, caso
necessário. Como só é necessário salvar as alterações com relação ao último quadro,
possuem uma alta compressão.
Tipo B (bi-direcional frames): referem-se a um quadro anterior e um possível quadro
futuro, sendo os mais comprimidos na stream. Eles contêm tão pouca informação que
nunca são usados como referência para outros quadros.
I-Frame
B-Frame
P-Frame
> compressão
Na figura acima, uma possível ordem de apresentação seria:
I B B P B B I
Já a ordem de transmissão seria:
I
P B B I B B
Pelo fato da atualização de um frame ser feita através da composição de vários frames, o
MPEG é considerado um formato de edição "Linear", dificultando a edição de imagens, pois tem
que ser sempre baseada num quadro tipo I.
Além dos tipos de quadros, existem outras duas técnicas importantes de entender na
compressão MPEG: compensação de movimento e redundância espacial. A figura a seguir
[CHI 96] mostra um grupo de imagens que serão decompostas quadro a quadro, sendo que cada
quadro será decomposto em macro blocos (explicados a seguir) e cada macro bloco decomposto
em blocos. Um grupo de imagens (group of pictures) é o menor componente de um fluxo MPEG
que pode ser completamente decodificado, sendo composto de um quadro tipo I e vários quadros
tipo P e B.
pg. 30
Valter Roesler
Compensação de movimento é a técnica que determina como os tipos de quadros se
relacionam entre si. Primeiramente divide-se um quadro ou imagem em unidades de 16x16
pixels chamados macro blocos. Comparando-se os macro blocos de um quadro com os do quadro
anterior pode-se chegar a grandes similaridades (fundos que não mudam, por exemplo). Essas
similaridades são ignoradas, reduzindo a quantidade de dados que necessita ser armazenada. Se
tais macro blocos mudam de posição dentro do quadro, isso também é analisado, sendo
armazenados somente os vetores do movimento efetuado.
A redundância espacial é então utilizada, comprimindo ainda mais os dados através da
descrição da diferença entre os macro blocos. Usando a transformada discreta do coseno
(Discrete Cosine Transform - DCT), os macro blocos são divididos em blocos 8x8, onde são
pesquisadas mudanças na cor e brilho ao longo do tempo [SHA 96].
5.2.3 Resumo de padrões para codificação de vídeo
A tabela a seguir mostra um resumo de alguns padrões utilizados atualmente para
codificação e transmissão de vídeo.
Padrão
H.261
H.263
M-JPEG
MPEG-1
MPEG-2
MPEG-4
Cinepak
Data
Descrição
1993 Video CODEC for audiovisual services at p x 64 kbit/s: com p variando de 1 a 30, utiliza a
unidade básica de transmissão sendo 64Kbps [ITU 93b]. Seus CODECS devem ter formato
QCIF obrigatoriamente e CIF opcionalmente. Utiliza DCT e compensação de movimento para
compressão de vídeo.
1996 Video coding for low bit rate communication: destinado a taxas menores. A norma H.263
consegue qualidade utilizando técnicas de estimativa de movimento, previsão de quadros e
codificação de Huffmann [PRI 99]. Seus CODECS devem ter formato sub-QCIF e QCIF
obrigatoriamente, e CIF, 4CIF e 16 CIF opcionalmente. Utiliza DCT e compensação de
movimento para compressão de vídeo.
Trabalha com a compressão de cada quadro individualmente, facilitando a edição, mas gerando
uma largura de banda maior por não se valer de técnicas interframe.
Utilizado para taxas de transmissão de áudio e vídeo até 1,5Mbps, chegando a 5 Mbps. Utiliza
DCT e compensação de movimento para compressão de vídeo.
Utilizado para transmissão de vídeo com maior qualidade, de 3 a 10Mbps [SHA 96]. Utiliza
DCT e compensação de movimento para compressão de vídeo.
Permite taxas de bits bastante variadas, dependendo da aplicação. Pode ir de 5 a 64Kbps, em
taxas muito baixas (Very Low Bit Rate Video), mas aumentando a qualidade se a aplicação
permitir, chegando a 4Mbps [CHI 98]. Utiliza DCT e compensação de movimento para
compressão de vídeo.
CODEC utilizado pelo padrão video for windows, da Microsoft [MOU 99]. Da mesma forma que
o M-JPEG, trabalha com compressão de cada quadro individualmente.
Indeo
pg. 31
Valter Roesler
CODEC para codificação de vídeo desenvolvido pela Intel [MOU 99]. A versão Indeo 5.1 utiliza
compressão de vídeo baseada em Wavelets, e consegue uma compressão quase o dobro do que
MPEG, JPEG e H.26x [MCG 99].
6 Estudo de caso 1: Transmissão multicast ao vivo durante
a VI Semana da Qualidade na Unisinos
Em outubro de 1999, a Unisinos promoveu em seu campus a Semana da Qualidade. Um
auditório da Unisinos (Padre Werner) foi o local destinado às palestras realizadas. Devido à
grande procura por estudantes e funcionários, um segundo auditório (Central) foi preparado de
forma a permitir que um número maior de pessoas assistisse às palestras presencial e
remotamente.
Foram instaladas máquinas para transmissão e recepção das palestras a serem apresentadas
por convidados da Universidade. Dentro de algumas sub-redes foram instalados túneis multicast,
permitindo a qualquer pessoa locada em um computador nessas sub-redes assistir às palestras em
seu PC. Nesse caso, a interação com o palestrante ocorreu através da Web, e no auditório Central
via videoconferência.
Esse projeto foi realizado dentro da Unisinos, mas os resultados e as ferramentas se
encaixam perfeitamente em qualquer rede metropolitana de alta velocidade, podendo-se expandir
a abrangência do sistema facilmente. O Laboratório de Pesquisa em Redes de Alta Velocidade
(PRAV), localizado no Centro de Ciências Exatas e Tecnológicas, e a Produtora da TV Unisinos,
localizada no Centro de Comunicações, foram as duas equipes encarregadas da criação,
supervisão e manutenção desse sistema, ilustrado na figura a seguir.
Foram escolhidas algumas sub-redes para a transmissão multicast, como, por exemplo,
PRAV, Pascal, Turing e Helios. Cada sub-rede (com exceção do PRAV) possuía
aproximadamente 80 máquinas. As linhas partindo do mrouter e das antenas na figura a seguir
demonstram o fluxo unidirecional de vídeo transmitido. A ligação entre os dois PCs através de
SDR possibilitou que as pessoas localizadas no Auditório Central fizessem perguntas ao vivo
(videoconferência). Finalmente, as linhas pontilhadas entre os PCs dos telespectadores e o PC do
Auditório Padre Werner representam conexões via chat, utilizadas para perguntas em texto.
O atraso médio observado entre a transmissão do vídeo e sua reprodução nos
computadores cliente foi de aproximadamente 18 segundos, sendo regulável no encoder. Tal
atraso é aceitável para uma “transmissão de vídeo unidirecional”. Na videoconferência, o atraso
ficou em torno de 500 ms a 1 s, o que se julgou aceitável para o objetivo proposto (idealmente,
deveria estar abaixo de 100 ms).
pg. 32
Valter Roesler
A qualidade da transmissão foi considerada satisfatória, com som MP3 codificado em
32 kHz de taxa de amostragem, vídeo a 30 quadros por segundo na resolução de 320x240
pontos, podendo ser visto em tela cheia com interpolação para suavizar a imagem. A largura de
banda necessária foi de aproximadamente 750 Kbps, com o protocolo de compressão MPEG-4
v2; não houve impacto substancial nas redes locais, uma vez que a capacidade nas redes em
questão era de no mínimo 10 Mbps.
A figura a seguir ilustra uma das palestras 2 , quando apresentada em um dos PCs, e a
interface com o usuário, baseada na Web.
A figura a seguir (que está na parte inferior da interface via Web), mostra com mais
detalhes a tela de interatividade com o palestrante, através da qual as pessoas que estavam
assistindo em um PC podiam enviar perguntas a um mediador no Auditório Padre Werner.
A tela de interatividade mostrada na figura servia apenas para quem estava assistindo no
PC. As pessoas localizadas no Auditório Central podiam fazer perguntas em tempo real ao
2
Uso da imagem cedido por Carlos Eduardo Hilsdorf – http://www.smagicas.com.br
pg. 33
Valter Roesler
palestrante (no Auditório Padre Werner) através de videoconferência. Como ferramenta foi
utilizado o VIC; conseguiu-se uma ótima qualidade de transmissão. As máquinas utilizadas na
videoconferência foram Pentium II 400 MHz e a velocidade configurada no VIC foi de 3 Mbps,
protocolo de vídeo H.261 e áudio mono com taxa de amostragem de 8 kHz. No primeiro dia,
foram utilizadas máquinas Pentium 233 MHz, mas elas mostraram-se lentas para codificar e
decodificar as imagens transmitidas a 3 Mbps.
7 Estudo de caso2: Videoconferência multicast no Metropoa
O Metropoa é uma rede metropolitana na grande Porto Alegre. O protocolo utilizado é o
ATM na velocidade de 155 Mbps, e a topologia é estrela, conforme visto na figura a seguir.
Foram testadas na rede algumas ferramentas de videoconferência, sendo que os principais
foram o sdr (com VIC/RAT) e o CU-Seeme 3 . A figura a seguir ilustra uma videoconferência
utilizando sdr, VIC e RAT.
Para fazer parte do Mbone, estabeleceu-se manualmente um túnel multicast entre um
mrouter no PRAV e outro no POP-RS. Conforme explicado na apostila de multicast, os mrouters
utilizam o protocolo DVMRP para roteamento multicast, e os túneis são necessários pois nem
todos os roteadores da Internet estão configurados para suportar multicast. Com o túnel ativado,
bastava um cliente entrar no sdr para que aparecessem as sessões multicast que estavam sendo
anunciadas no momento (vide figura a seguir). No caso, todos os participantes da
videoconferência escolheram a sessão “Metropoa - entrem aqui!!!”, que foi previamente criada
numa máquina com FreeBSD na Unisinos.
3
vide http://www.whitepine.com
pg. 34
Valter Roesler
Ao selecionar a sessão da videoconferência, escolhe-se o protocolo de compressão de
vídeo (no caso, H.261, utilizado pelo VIC no endereço multicast 239.255.155.106 – definido
pela sessão). Similarmente, o protocolo de áudio utilizado pelo RAT foi 8 kHz mono, no
endereço multicast 239.255.6.35. Cada participante da videoconferência efetua o “join”, e
gradativamente eles vão se integrando à sessão. A figura anterior apresenta a interface do VIC
com 5 participantes, um na UFRGS, três em locais diferentes da UNISINOS e um na
PROCERGS.
8 Bibliografia
[CHI 96]
[FAQ 98]
[ITU 98]
[ITU 98a]
[ITU 97]
[ITU 96]
[ITU 96a]
[ITU 93]
[ITU 93a]
[ITU 93b]
[ITU 92]
CHIARIGLIONE, Leonardo. Short MPEG-1 description. http://rtlab.kaist.
ac.kr/~gunhan/MPEG1/mpeg1desc.html.
FAQ. Frequently Asked Questions About MPEG Audio Layer 3. version 3.0,
1998. http://www.iis.fhg.de/amm/techinf/layer3/layer3 faq/index.html.
ITU-T. Recommendation H.323 – Packet-based Multimedia Communications
Systems . Genebra. 1998.
ITU-T. Recommendation H.225.0 - Call signalling Protocols and Media Stream
Packetization for Packet Based Multimedia Communications Systems. Genebra.
1998.
ITU-T. Recommendation G728 anexo H - Coding of speech at 16 kbit/s using
low-delay code excited linear prediction. Annex H: Variable bit rate LD-CELP
operation mainly for DCME at rates less than 16 kbit/s. Genebra. 1997.
ITU-T. Recommendation G.723 – Speech coders: dual rate speech coder for
multimedia communications transmitting at 5.3 and 6.3 kbit/s. Genebra. 1996.
ITU-T. Recommendation G.729 - Coding of speech at 8 kbit/s using Conjugate
Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP). Genebra.
1996.
ITU-T. Recommendation G.711 - Pulse Code Modulation (PCM) of voice
frequencies. Genebra. 1993.
ITU-T. Recommendation G.722 – 7 kHz audio-coding within 64 kbit/s.
Genebra. 1993.
ITU-T. Recommendation H.261 – Video CODEC Audiovisual Services at p ×
64 kbits. Genebra. 1993.
ITU-T. Recommendation G.728 - Coding of speech at 16 kbit/s using low-delay
code excited linear prediction. Genebra. 1992.
[MCG 99]
[MOU 99]
[MPE 99]
[PAS 97a]
[PAU 98]
[PRI 99]
[RFC 1700]
[RFC 1889]
[RFC 2543]
[RFC 2327]
[SCH 99]
[SCH 99a]
[SHA 96]
[SPU 00]
[TAN 97]
[THO 98]
pg. 35
Valter Roesler
MCGOWAN, John F. White Paper on Video Technologies for Mars Airplane.
California: NAS A Ames Research Center, 1999.
MOURA. César Olavo de M. Filho, OLIVEIRA, Mauro. Videoconferência em
Educação a Distância. Ceará: ETFCE. 1999.
MPEG. MPEG Audio Web Page. 1999. http://www.tnt.unihannover.
de/project/mpeg/audio.
PASSMORE, David. Delayed Voice-over-IP. Business Communications Review.
Dez, 1997. http://www.netreference.com/PublishedArchive/Articles/BCR/BCR.12.97.html
PAUL, Sanjoy. Multicasting on the Internet and its applications. Kluwer
Academic Publishers: Massachussets. 1998. 421p.
PRIMER on the H.323 Series Standard - Em http://www.databeam.com/
h323/h323primer.html. 1999.
REYNOLDS, J. POSTEL, J. Assigned Numbers. RFC 1700 (Standards Track).
California: IETF. Oct, 1994.
SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time
Applications. RFC 1889 (Standards Track). California: IETF. Jan, 1996.
HANDLEY, M. et al. SIP: Session Initiation Protocol . RFC 2543 (Standards
Track). California: IETF. Mar, 1999.
HANDLEY, M. JACOBSON, V. SDP: Session Description Protocol. RFC 2327
(Standards Track). California: IETF. Apr, 1998.
SCHULZRINNE, H. Comparison of H.323 and SIP. 1999. Em
http://www.cs.columbia.edu/~hgs/sip/h323-comparison.html.
SCHULZRINNE, H. ROSENBERG, J. A Comparison of SIP and H.323 for
Internet Telephony. 1999. Em
http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf.
SHAPE of MPEG. DV Magazine . Vol 4 n. 12. 1996. Em
http://livedv.com/Mag/Dec96/Contents/mpeg/mpeg.html.
SPURGEON, Charles E. Ethernet, the definitive guide . Sebastopol: O’reilly.
February, 2000. 500p.
TANENBAUM, Andrew C. Redes de Computadores - 3a edição. Ed. Campus,
Rio de Janeiro, 1997. 923p.
THOM, D. PURNHAGEN, H. MPEG Audio FAQ Version 10. ISO/IEC
JTC1/SC29/WG11 – Audio subgroup. Seoul. Em http://www.tnt.unihannover.de/project/mpeg/audio/faq. 1998.

Transmissão multimídia em redes de computadores

Transcrição

Documentos relacionados

Datasheet Acopladores MTCLPRET

Monitor HD 32" Profissional

0,00 - FJMPC

datasheet modelo proi-1167 - speed dome ip cam

SOLUÇÕES MOTOROLA PARA O SETOR DE SAÚDE

CV em Português

Monitor HD 42" Profissional

Manual para a conversão de AVI`s a KVCD por Nómada

Final Cut Pro X (24 horas, 3 dia)

Placas de distribuição de série digital