Transmissão multimídia em redes de...

$: Transmissão multimídia em redes de computadoresprofessores.unisanta.br/santana/downloads\Telematica\Com_Dados_… · O protocolo RTP (Real-time Transport Protocol), descrito na$
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 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

2 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

3 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

4 Compressão de áudio e vídeo ................................................................................................ 21 5 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

6 Estudo de caso 1: Transmissão multicast ao vivo durante a VI Semana da Qualidade na Unisinos................................................................................................................................ 31


7 Estudo de caso2: Videoconferência multicast no Metropoa ................................................. 33 8 Bibliografia............................................................................................................................ 34

1 Transmissão multimídia em redes As etapas de uma transmissão multimídia são mostradas na figura a seguir:

Digitalização Sinal de

entrada Compressão Transmissão

Perda / atraso

Reordenação Descompressão Recuperação Sinal de saída

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

Vídeo

Conferências (interatividade)

Transmissão Unidirecional

Áudio Texto

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.


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.


t

latência

jitter

N. de Pacotes

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.

skew

N. de Pacoteschegando

t

vídeo áudio

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).

Telefone TV Videoconferência latência sensível insensível sensível jitter sensível sensível sensível skew - sensível sensível velocidade (largura de banda) baixa alta alta


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.


Aplicação

Encapsulamento de mídia

RTP RTCP

UDP

IPv4 / IPv6 Unicast ou multicast

Ethernet

dados controle

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

Sistema origem / destino IP=10.16.165.29 SSRC = 35

Tradutor Multiplexador

PCM

ADPCM IP 10.13.45.6

MP3

MP3 IP 10.18.32.14

SSRC = 46

SSRC = 46

CSRC = 87, 35

Fluxo único Múltiplos fluxos

Troca de codificação

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).


2.1.2 Cabeçalho RTP O cabeçalho do RTP é visto na figura a seguir.

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 1MV=2 CCP X PT Número de seqüência

Timestamp

1 2 3

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;

• Marcador (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


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 inter-mí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;


• 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 | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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;


• 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”;


• 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 momento.

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 Data Descrição H.310 1996 Broadband audiovisual communication systems and terminals:

videoconferência MPEG-2 sobre ATM com alta qualidade H.320 1997 Narrow-band visual telephone systems and terminal equipment:

videoconferência sobre RDSI H.321 1996 Adaptation of H.320 visual telephone terminals to B-ISDN

environments: videoconferência sobre ATM com boa qualidade H.322 1996 Visual telephone systems and terminal equipment for local area

networks which provide a guaranteed quality of service: /**/ H.323 1998 Packet based multimedia communications systems:

videoconferência sobre redes de pacotes, como IP e Ethernet H.324 1996 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;


• 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.310operando nomodo H.321

TerminalH.323

TerminalH.323

GatewayH.323

GatekeeperH.323

MCUH.323

TerminalH.323

HUBRede baseada em pacotes

TerminalH.321

TerminalV.70

TerminalH.324

Terminalde voz

TerminalH.322

Terminalde voz

TerminalH.320

TerminalH.321

GSTNLAN com

QoS RDSI-FE RDSI-FL

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].


Escopo da norma H.323

Eqto de entrada de vídeo Câmera de vídeo, vídeo

cassete)

Aplicações de dados (T.120, etc)

Eqto de entrada de áudio (microfone, vídeo cassete)

Controle do sistema

CODEC de áudio G.711, G.722,

G.723, G.728, G.729

CODEC de vídeo H.261, H.263

Receive

Path

Delay

Camada

H.225.0

Interface

LAN

Controle do sistema

Controle H.245

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


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

HUB HUB

Terminal Gatekeeper Gateway

Terminal Terminal Roteador Roteador

TerminalTerminal

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.


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

Descentralizado

Áudio e Vídeo unicast

Centralizado


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 Origem Destino Descrição T1 G H.225 RAS: Admission Request (ARQ) para T1 1 G T1 H.225 RAS: Admission Confirm (ACF) para T1 T1 T2 TCP SYN para abertura de canal de sinalização Q.931 T2 G H.225 RAS: Admission Request (ARQ) para T2 G T2 H.225 RAS: Admission Confirm (ACF) para T2 T2 T1 TCP SYN ACK para confirmação canal Q.931

2

T1 T2 TCP ACK – estabelece conexão T1 T2 H.225: Q.931: setup 3 T2 T1 H.225: Q.931: connect T1 T2 TCP SYN para abertura de canal de controle H.245 T2 T1 TCP SYN+ACK para confirmação do canal H.245 4 T1 T2 TCP ACK – estabelece conexão H.245 T1 T2 Capabilities Exchange – Mestre/Escravo 5 T2 T1 Capabilities Exchange – Mestre/Escravo T1 T2 H.245: abre canal de áudio (open) 6 T2 T1 H.245: abre canal de áudio (ack+open)

7 T1 T2 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;


• 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.


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


• 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.

Largura de banda

Compressãosem perdas

Compressãocom perdas

baixa alta

baixa

alta

Qualidade

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.

Preparação Source Coding

Entropy Coding

Dados não comprimidos

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.


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ção1, 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).

Vários canais de 4KHz multiplexados na mesma linha

CENTRAL PÚBLICA

CENTRAL PÚBLICA

Limita em 4KHz

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 Amostragem Bit rate Telefonia 8000/8bits/mono 64 Kbit/s Teleconferência 16000/16bits/mono 256 Kbit/s CD rom 44100/16bits/stereo 1.410 Kbit/s Digital Audio Tape 48000/16bits/stereo 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

1 Multiplexar é utilizar a mesma linha física para transmitir vários canais


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 exemplo, 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 Descrição G.711 1988,

1993 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.

G.722 1988, 1993

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].

G.723 1996 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].

G.728 1992, 1997

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.

G.729 1996 Coding of speech at 8 kbit/s using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (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].

MP3 1992 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].

AAC 1998 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,


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 Ethernet 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.


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 Número de pixels Padrões Sub-QCIF 128x96 H.263 QCIF 176x144 H.261, H.263 CIF 352x288 Opcional no H.261 e H.263 4CIF 702x576 Opcional no H.263 16CIF 1408x1152 Opcional no H.263 Sub-QSIF 88x60 MPEG QSIF 176x120 MPEG SIF 352x240 MPEG-1, MPEG-2 CCIR-601 720x480 MPEG-2 1280x720 Grand Alliance High Definition

Television Standard 1920x1080 Grand Alliance High Definition

Television Standard

• 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.


640x480 320x240 160x120 1 seg 27 Mbytes 6,75 Mbytes 1,68 Mbytes 1 min 1,6 Gbytes 400 Mbytes 100 Mbytes 1 hora 96 Gbytes 24 Gbytes 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 compreender 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.


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

Já a ordem de transmissão seria:

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.

I B B P B B I

I P B B I B B


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 Data Descrição H.261 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.

H.263 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.

M-JPEG 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 .

MPEG-1 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.

MPEG-2 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.

MPEG-4 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.

Cinepak CODEC utilizado pelo padrão v ideo for windows, da Microsoft [MOU 99]. Da mesma forma que o M-JPEG, trabalha com compressão de cada quadro individualmente.


Indeo 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).


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 palestras2, 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


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-Seeme3. 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


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] CHIARIGLIONE, Leonardo. Short MPEG-1 description. http://rtlab.kaist.

ac.kr/~gunhan/MPEG1/mpeg1desc.html. [FAQ 98] 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 98] ITU-T. Recommendation H.323 – Packet-based Multimedia Communications

Systems . Genebra. 1998. [ITU 98a] ITU-T. Recommendation H.225.0 - Call signalling Protocols and Media Stream

Packetization for Packet Based Multimedia Communications Systems. Genebra. 1998.

[ITU 97] 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 96] 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 96a] 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 93] ITU-T. Recommendation G.711 - Pulse Code Modulation (PCM) of voice frequencies. Genebra. 1993.

[ITU 93a] ITU-T. Recommendation G.722 – 7 kHz audio-coding within 64 kbit/s. Genebra. 1993.

[ITU 93b] ITU-T. Recommendation H.261 – Video CODEC Audiovisual Services at p × 64 kbits. Genebra. 1993.

[ITU 92] ITU-T. Recommendation G.728 - Coding of speech at 16 kbit/s using low-delay code excited linear prediction. Genebra. 1992.


[MCG 99] MCGOWAN, John F. White Paper on Video Technologies for Mars Airplane. California: NASA Ames Research Center, 1999.

[MOU 99] MOURA. César Olavo de M. Filho, OLIVEIRA, Mauro. Videoconferência em Educação a Distância. Ceará: ETFCE. 1999.

[MPE 99] MPEG. MPEG Audio Web Page. 1999. http://www.tnt.uni-hannover. de/project/mpeg/audio.

[PAS 97a] PASSMORE, David. Delayed Voice-over-IP. Business Communications Review. Dez, 1997. http://www.netreference.com/PublishedArchive/Articles/BCR/BCR.12.97.html

[PAU 98] PAUL, Sanjoy. Multicasting on the Internet and its applications. Kluwer Academic Publishers: Massachussets. 1998. 421p.

[PRI 99] PRIMER on the H.323 Series Standard - Em http://www.databeam.com/ h323/h323primer.html. 1999.

[RFC 1700] REYNOLDS, J. POSTEL, J. Assigned Numbers. RFC 1700 (Standards Track). California: IETF. Oct, 1994.

[RFC 1889] SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. RFC 1889 (Standards Track). California: IETF. Jan, 1996.

[RFC 2543] HANDLEY, M. et al. SIP: Session Initiation Protocol . RFC 2543 (Standards Track). California: IETF. Mar, 1999.

[RFC 2327] HANDLEY, M. JACOBSON, V. SDP: Session Description Protocol. RFC 2327 (Standards Track). California: IETF. Apr, 1998.

[SCH 99] SCHULZRINNE, H. Comparison of H.323 and SIP. 1999. Em http://www.cs.columbia.edu/~hgs/sip/h323-comparison.html.

[SCH 99a] 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.

[SHA 96] SHAPE of MPEG. DV Magazine . Vol 4 n. 12. 1996. Em http://livedv.com/Mag/Dec96/Contents/mpeg/mpeg.html.

[SPU 00] SPURGEON, Charles E. Ethernet, the definitive guide . Sebastopol: O’reilly. February, 2000. 500p.

[TAN 97] TANENBAUM, Andrew C. Redes de Computadores - 3a edição. Ed. Campus, Rio de Janeiro, 1997. 923p.

[THO 98] THOM, D. PURNHAGEN, H. MPEG Audio FAQ Version 10. ISO/IEC JTC1/SC29/WG11 – Audio subgroup. Seoul. Em http://www.tnt.uni-hannover.de/project/mpeg/audio/faq. 1998.

Transmissão multimídia em redes de...

Documents

Transcript of Transmissão multimídia em redes de...