Escolar Documentos
Profissional Documentos
Cultura Documentos
Downloads Telematica Com Dados 2 Leitura Adicional Multimidia
Downloads Telematica Com Dados 2 Leitura Adicional Multimidia
computadores
pg. 2
Valter Roesler
SUMRIO
1
4
5
pg. 3
Valter Roesler
Digitalizao
Compresso
Transmisso
Perda / atraso
Sinal de
sada
Recuperao
Descompresso
Reordenao
Conferncias
(interatividade)
udio
Transmisso
Unidirecional
Texto
Vdeo
Apesar das aplicaes possurem necessidades diferentes, existe uma tendncia atualmente
para sua convergncia em um nico meio fsico. Assim, se unificaria o meio fsico, que
compartilharia a transmisso de voz, vdeo, dados, imagens, msicas, e tudo que possa ser
transformado em bits.
Entretanto, as aplicaes tm caractersticas e requisitos bem diferentes umas das outras.
Aplicaes de teleconferncia possuem necessidades mais rgidas em relao latncia e jitter
do que aplicaes de transmisso unidirecional. Da mesma forma, transmisses de vdeo
necessitam uma largura de banda muito maior que transmisses de udio ou texto.
A seguir sero definidos trs conceitos fundamentais para o entendimento da transmisso
multimdia nas redes de computadores: latncia, jitter e skew. Em seguida esses conceitos sero
comparados entre si dentro das necessidades das aplicaes.
pg. 4
Valter Roesler
1.1 Latncia
Latncia o tempo que um pacote leva da origem ao destino. Caso esse atraso seja muito
grande, prejudica uma conversao atravs da rede, tornando difcil o dilogo e a interatividade
necessria para certas aplicaes. Segundo [PAS 97a] e [PAU 98, pg 9], um atraso confortvel
para o ser humano fica na ordem de 100ms.
Suponha duas pessoas conversando atravs da Internet. medida que o atraso aumenta, as
conversas tendem a se entrelaar, ou seja, uma pessoa no sabe se o outro a ouviu e continua
falando. Aps alguns milisegundos, vem a resposta do interlocutor sobre a primeira pergunta
efetuada, misturando as vozes. Num atraso muito grande, as pessoas devem comear a conversar
utilizando cdigos, tipo cmbio, quando terminam de falar e passam a palavra ao outro.
Os principais responsveis pela latncia so o atraso de transmisso, de codificao e de
empacotamento, que podem ser definidos da seguinte forma:
Atraso de transmisso: 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 srie de fatores, como por exemplo:
1. Atraso no meio fsico: o atraso de propagao da mensagem no meio de
transmisso, e varia bastante. Por exemplo, num enlace de satlite o tempo tpico
de 250ms, e numa fibra tica ou UTP o atraso na ordem de 5s/Km [TAN 97,
pg 107] e [SPU 00, pg /**/].
2. Atrasos de processamento nos equipamentos intermedirios, como roteadores e
switches;
3. Atraso devido ao tempo de espera nas filas de transmisso dos equipamentos
intermedirios: 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 codificao e decodificao: tempo de processamento na mquina origem na
mquina destino para codificao e decodificao de sinais, respectivamente. Voz e vdeo
normalmente so codificados em um padro, tal como PCM (G.711 a 64Kbps) para voz,
ou H.261 para vdeo. O atraso varia com o padro adotado; por exemplo, o G.711 ocupa
menos de 1ms de codificao ([PAS 97a]), porm requer 64Kbps de banda. Um
protocolo de voz como o G.729 requer 25ms de codificao, mas ocupa apenas 8Kbps de
banda ([PAS 97a]);
Atraso de empacotamento e desempacotamento: depois de codificado, o dado deve ser
empacotado atravs dos nveis na pilha de protocolos a fim de ser transmitido na rede.
Por exemplo, numa transmisso 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
sero necessrios no destino a fim de desempacotar os dados.
Alm disso, dependendo do jitter da transmisso, a aplicao de tempo real dever criar um
buffer para homogeneizar a entrega de pacotes ao usurio, criando um novo atraso no sistema.
1.2 Jitter
Apenas latncia no suficiente para definir a qualidade de uma transmisso, pois as redes
no conseguem garantir uma entrega constante de pacotes ao destino. O jitter a variao
estatstica do retardo, que altera o fluxo de chegada dos pacotes. O conceito de jitter e latncia
ilustrado na figura a seguir.
N. de
Pacotes
pg. 5
Valter Roesler
latncia
jitter
t
A conseqncia do jitter que a aplicao no destino deve criar um buffer cujo tamanho
vai depender do jitter, gerando mais atraso na conversao (aplicao de voz, por exemplo). Esse
buffer vai servir como uma reserva para manter a taxa de entrega constante no interlocutor. Da a
importncia de latncia e jitter baixos em determinadas aplicaes sensveis a esses fatores,
como teleconferncia.
1.3 Skew
O skew um parmetro utilizado para medir a diferena entre os tempos de chegada de
diferentes mdias que deveriam estar sincronizadas, como mostra a figura a seguir. Em diversas
aplicaes existe uma dependncia entre duas mdias, como udio e vdeo, ou vdeo e dados.
Assim, numa transmisso de vdeo, o udio deve estar sincronizado com o movimento dos lbios
(ou levemente atrasado, visto que a luz viaja mais rpido que o som, e o ser humano percebe o
som levemente atrasado em relao viso). Outro exemplo em que sincronizao necessria
na transmisso de udio (manual explicativo, por exemplo) acompanhada de uma seta
percorrendo a imagem associada.
N. de Pacotes
chegando
skew
vdeo
udio
Telefone
sensvel
sensvel
baixa
TV
insensvel
sensvel
sensvel
alta
Videoconferncia
sensvel
sensvel
sensvel
alta
pg. 6
Valter Roesler
2.1 RTP
O protocolo RTP (Real-time Transport Protocol), descrito na RFC 1889, especifica um
formato para transmisso de dados em tempo real, tais como udio, vdeo ou dados de
simulao. Alguns benefcios obtidos por esse protocolo (que sero detalhados no decorrer deste
item) so [PAU 98, pg 197]:
pg. 7
Valter Roesler
Aplicao
Encapsulamento de
mdia
RTP
RTCP
dados
controle
UDP
IPv4 / IPv6
Unicast ou multicast
Ethernet
Troca de codificao
Mltiplos 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
pg. 8
Valter Roesler
CC
PT
Nmero de seqncia
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
tm o seguinte significado [RFC 1889, pg 10]:
pg. 9
Valter Roesler
em pequenos pedaos de 20ms de durao, cada um deles com um cabealho RTP, que
transmitido via UDP na porta especificada anteriormente.
O cabealho RTP indica o tipo de codificao de udio (PCM, ADPCM, MP3) que est
contida no pacote, a fim de que os participantes possam trocar a codificao para permitir a
entrada de um novo participante que est conectado atravs de uma linha lenta.
Para pacotes que chegam em ordem trocada, o nmero de seqncia ajuda na
reorganizao da informao. J para atrasos variveis na rede, a informao de timestamp vai
ajudar o receptor a dimensionar o buffer de recepo, a fim de evitar truncamentos na conversa.
Alm disso, o receptor sabe que cada nmero de seqncia corresponde a 20ms nesse exemplo,
permitindo a ele reconstruir o tempo produzido pela fonte.
Para saber quem est participando da conferncia e quo bem est recebendo udio, a
aplicao 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 informao.
Para deixar a conferncia, a aplicao envia um pacote RTCP BYE, indicando que est
saindo.
/**/ sniffar uma conferncia de udio com RTP e colocar figura aqui.
2.2 RTCP
O protocolo RTCP (RTP Control Protocol) tem por objetivo fornecer feedback sobre a
qualidade de servio obtida na distribuio de dados RTP, e consegue isso atravs de
transmisses peridicas de pacotes de controle a todos participantes da sesso RTP, utilizando o
mesmo mecanismo de distribuio do RTP (unicast ou multicast), e possuindo uma porta
especfica de controle na sesso, conforme descrito anteriormente. Suas funes so [RFC 1889,
pg 15]:
pg. 10
Valter Roesler
header
sender
info
report
block
1
report
block
2
Verso (V): 2 bits: Identifica a verso do RTP, que a mesma do RTCP, que 2;
Padding (P): 1 bit: ver RFC 1889;
Reception Report Count (RC): 5 bits: nmero de blocos de informaes 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 cabealho;
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 correspondncia do tempo
entre NTP e RTP, possvel efetuar sincronizao intermdia;
Senders packet count: 32 bits: o nmero total de pacotes de dados transmitidos desde o
incio da transmisso;
Senders octet count: 32 bits: nmero total de bytes de dados teis (i.e., sem incluir
cabealho) transmitidos desde o incio da transmisso. Este campo pode ser usado para
estimar a taxa de transmisso mdia 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 estatsticas de cada
transmissor que ele ouviu desde o ltimo report.
Fraction lost: 8 bits: frao de pacotes de dados perdidos desde o ltimo report. Esta
frao igual a nmero de pacotes perdidos dividido pelo nmero de pacotes
esperado;
Cumulative number of packets lost: 24 bits: o nmero total de pacotes de dados RTP
perdidos desde o incio da recepo;
Extended highest sequence number received: 32 bits: ver RFC 1889;
Interarrival jitter: 32 bits: estimativa da variao 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.
pg. 12
Valter Roesler
Tipo = 7: NOTE: informao a ser transmitida no momento, como por exemplo, para
enviar o ttulo da palestra sendo efetuada. Essa informao dependente de perfil, e pode
ser mudada dependendo da aplicao;
Tipo = 8: PRIV: extenses privativas para testes.
2.2.4 BYE
O pacote de BYE indica que um transmissor est deixando a sesso. Existe um campo
opcional de comprimento varivel para indicar o motivo da sada.
2.2.5 APP
Pacote destinado a uso experimental medida que novas aplicaes surgem, possuindo um
tipo=204 e um subtipo descrevendo o tipo de aplicao experimental.
Data
1996
H.320
1997
H.321
1996
H.322
1996
H.323
1998
H.324
1996
pg. 13
Valter Roesler
Descrio
Broadband audiovisual communication systems and terminals:
videoconferncia MPEG-2 sobre ATM com alta qualidade
Narrow-band visual telephone systems and terminal equipment:
videoconferncia sobre RDSI
Adaptation of H.320 visual telephone terminals to B-ISDN
environments: videoconferncia 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:
videoconferncia sobre redes de pacotes, como IP e Ethernet
Terminal for low bit rate multimedia communication:
videoconferncia sobre sistema telefnico
SIP (Session Initiation Protocol RFC 2543): estabelece, mantm e encerra chamadas ou
sesses multimdia;
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 atravs do RTCP (RTP Control Protocol), conforme
descrito anteriormente;
RTSP (Real Time Streaming Protocol RFC 2326): controla entrega de mdia atravs de
streaming;
SDP (Session Description Protocol RFC 2327): descreve sesses multimdia.
3.1 H.323
A recomendao H.323 especifica um conjunto de protocolos de udio, vdeo 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 no precisam necessariamente prover garantia de qualidade de servio
(QoS) [ITU 98]. Essa recomendao teve sua segunda verso aprovada em fevereiro de 1998,
pelo grupo de estudos 16 do ITU-T.
As principais caractersticas do H.323 so as seguintes [PRI 99]:
pg. 14
Valter Roesler
Suporte a multiponto: embora H.323 possa suportar conferncias com trs ou mais
pontos, especificado um componente chamado MCU (Multipoint Control Unit) a fim de
tornar mais poderosas e flexveis tais conferncias;
Suporte a multicast: extremamente importante para economizar banda em conferncias
e transmisses multiponto;
Flexibilidade : Uma conferncia H.323 pode incluir equipamentos e redes com diferentes
caractersticas. Por exemplo, um participante pode entrar na conferncia somente com
udio, e outro somente com dados, via um terminal que fale a recomendao T.120 do
ITU-T (Data protocols for multimedia conferencing).
A figura a seguir mostra uma viso geral da arquitetura H.323, sua interoperabilidade com
outros terminais e seus principais componentes, que so 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 traduo de padres,
ligando a zona H.323 com outros servios, tais como o GSTN (General Switched Telephone
Network ), o RDSI (Rede Digital de Servios 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
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 so os componentes responsveis pela comunicao bidirecional em tempo real
com outro terminal, gateway ou MCU. Um terminal pode oferecer somente voz, voz e vdeo, voz
e dados ou voz, dados e vdeo. A norma definiu que voz obrigatrio, mas dados e vdeo so
opcionais. A figura a seguir mostra a recomendao H.323 para terminais [ITU 98, pg 13].
pg. 15
Valter Roesler
CODEC de udio
G.711, G.722,
G.723, G.728, G.729
Receive
Path
CODEC de vdeo
H.261, H.263
Aplicaes 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
Sinalizao 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 vdeo e as
aplicaes de dados so opcionais [ITU 98, pg 13]. O canal de controle H.245, os canais de
dados e o canal de sinalizao da chamada precisam obrigatoriamente de um protocolo confivel
(por exemplo, TCP ou SPX). J os protocolos de udio, vdeo e RAS (Registration, Admission
and Status) precisam de um protocolo no confivel (por exemplo, UDP ou IPX). A seguir uma
definio dos elementos da figura anterior (posteriormente os principais protocolos sero
detalhados):
CODEC de vdeo (H.261, H.263): codifica o vdeo vindo da fonte (por exemplo, placa
de captura de vdeo) para transmisso. O receptor joga o sinal decodificado para a tela de
vdeo do usurio. A transmisso de vdeo e, conseqentemente, esse CODEC, opcional,
mas caso exista, o terminal deve prover, no mnimo, 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 transmisso. No receptor joga o sinal decodificado
para o alto- falante do sistema. Todo terminal H.323 deve ter, no mnimo, o CODEC para
a recomendao G.711, entretanto, em linhas de baixa velocidade (<56Kbps), o G.711
no funciona, portanto, tais terminais devem suportar ou o G.723 ou o G.729 [ITU 98, pg
16];
Canal de dados: suporta aplicaes tipo whiteboard, transferncia de imagens estticas,
transferncia de arquivos, acesso a banco de dados, e outros;
Unidade de controle do sistema (H.245, H.225.0): fornece sinalizao para operao do
terminal H.323. Fornece controle de chamada, sinalizao de comandos e indicaes, e
assim por diante. Atravs da negociao do protocolo H.245, possvel usar outros
CODECs de vdeo e outros formatos de imagem. Alm disso, mais de um canal de vdeo
pode ser transmitido ou recebido (para enviar o palestrante e a platia simultaneamente,
ou para receber todos os participantes de uma conferncia). Durante o estabelecimento da
pg. 16
Valter Roesler
3.1.2 Gatekeepers
O gatekeeper opcional em um sistema H.323, provendo, quando utilizado, os seguintes
servios de controle de chamada para componentes H.323:
Gatekeeper
Gateway
Terminal
HUB
Terminal
Terminal
Terminal
HUB
Roteador
Roteador
MCU
3.1.3 Gateways
O Gateway tambm opcional em um sistema H.323, sendo utilizado quando necessrio
efetuar converso entre formatos para permitir a comunicao entre terminais H.323 e outros
tipos. Essa funo inclui converso de formatos de transmisso (por exemplo, H.225 para/de
H.221), e formatos de comunicao (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 pblica.
pg. 17
Valter Roesler
3.1.4 MCUs
O Multipoint Control Unit tambm um elemento opcional, seu objetivo permitir
conferncias entre trs ou mais usurios. No H.323, um MCU consiste de um Multipoint
Controller (MC) e zero ou mais Multipoint Processors (MPs). Isso importante principalmente
para conferncias multicast, que so controladas por ele. O fluxo de udio e vdeo processado
pelo MP.
MC e MP podem existir como componentes separados ou serem implementados junto com
outros componentes H.323. Pode haver conferncias de dois tipos: centralizada e
descentralizada [ITU 98, pg 5].
Uma conferncia multiponto descentralizada utiliza multicast para enviar dados entre os
participantes, no necessitando MP para isso, entretanto, a parte de controle feita utilizando o
protocolo H.245 para um MC, que gerencia a conferncia.
Uma conferncia multiponto centralizada aquela onde cada um dos terminais
participantes envia sinalizao de controle, udio, vdeo e dados para o MCU. O MC do MCU
gerencia a conferncia, e o MP processa o udio, vdeo e dados, retornando os fluxos
processados a cada terminal.
Na figura a seguir tem uma ilustrao de conferncia centralizada e descentralizada.
Descentralizado
Centralizado
pg. 18
Valter Roesler
A tabela a seguir mostra com maiores detalhes o fluxo de mensagens para efetuar uma
conferncia de udio no H.323 [SCH 99]. T1=Terminal1, T2=Terminal2, G=gatekeeper,
RTT=Round Trip Time.
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
Descrio
H.225 RAS: Admission Request (ARQ) para T1
H.225 RAS: Admission Confirm (ACF) para T1
TCP SYN para abertura de canal de sinalizao Q.931
H.225 RAS: Admission Request (ARQ) para T2
H.225 RAS: Admission Confirm (ACF) para T2
TCP SYN ACK para confirmao canal Q.931
TCP ACK estabelece conexo
H.225: Q.931: setup
H.225: Q.931: connect
TCP SYN para abertura de canal de controle H.245
TCP SYN+ACK para confirmao do canal H.245
TCP ACK estabelece conexo 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.2 SIP
O protocolo SIP (Session Initiation Protocol), definido na RFC 2543, um protocolo da
camada de aplicao que tem por objetivo prover a sinalizao necessria para estabelecer,
modificar e terminar chamadas ou sesses multimdia. Tais sesses multimdia incluem
conferncias, ensino a distncia, voz sobre IP, distribuio de vdeo e outras aplicaes similares.
Os participantes podem se comunicar via multicast, unicast ou de ambas formas, e tambm via
TCP ou UDP.
No protocolo, so definidas cinco funes para iniciar e terminar comunicaes
multimdia:
pg. 20
Valter Roesler
3.3.2 Escalabilidade
O H.323 necessita de um nvel de transporte confivel para o H.245 e Q.931, levando a
problemas de escalabilidade. O SIP pode usar tanto UDP como TCP. Se desejado, pode tambm
utilizar ATM AAL5, IPX ou X.25, sem mudanas no protocolo.
pg. 21
Valter Roesler
3.3.6 Complexidade
A especificao do SIP bem menor que a das sinalizaes Q.931 e H.245, tornando mais
simples o sistema. Para se ter uma idia, a especificao do SIP tem um total de 128 pginas,
enquanto a soma das especificaes base de sinalizao do H.323 d um total de 736 pginas
[SCH 99a]. H.323 define centenas de elementos, enquanto o SIP define somente 37 cabealhos.
Uma implementao bsica do SIP funciona com quatro cabealhos (To, From, Call-ID e Cseq)
e trs tipos (INVITE, ACK e BYE).
Existem outras diferenas entre SIP e H.323 que no sero analisadas neste documento,
mas podem ser encontradas nas referncias passadas no incio deste item.
pg. 22
Valter Roesler
A compresso sem perdas gera arquivos maiores (no comprime tanto), entretanto,
consegue uma qualidade maior, pois o receptor consegue obter uma imagem idntica que foi
transmitida. A figura a seguir mostra a relao entre qualidade e largura de banda para
compresso com e sem perdas.
Qualidade
alta
Compresso
com perdas
Compresso
sem perdas
baixa
baixa
alta
Largura de
banda
Preparao
Source
Coding
Entropy
Coding
Dados
comprimidos
pg. 23
Valter Roesler
CENTRAL
PBLICA
Vrios canais de 4KHz
multiplexados na mesma linha
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
pg. 24
Valter Roesler
G.722
1988,
1993
G.723
1996
G.728
1992,
1997
G.729
1996
MP3
1992
AAC
1998
Descrio
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 transmisso de 64Kbps. Feito para freqncias de voz, ou seja, at 4KHz [ITU 93]. A latncia
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 tcnica sub-band ADPCM, gera taxa de transmisso 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 transmisso de voz (4KHz). O CODEC para a taxa de 6,3Kbps MLQ
multipulso, e para a de 5,3Kbps o ACELP. Ambos utilizam a tcnica de previso linear (linear
predictive analysis by synthesis coding). Esse tipo de algoritmo utiliza muito clculo em ponto
flutuante, requerendo um poder computacional bem maior do que os baseados em PCM puro. A
latncia 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 mantm a essncia do CELP, entretanto, utiliza uma anlise de ganho e
previso linear para reduzir a latncia do algoritmo, que fica em 0,625ms [ITU 92]. O anexo H
da norma [ITU 97] mostra uma tcnica para usar CELP de baixo atraso com uma largura de
banda ainda menor, provocando uma taxa de bits varivel de at 12,8Kbps ou 9,6Kbps,
dependendo da tcnica 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 latncia
gerada fica em torno de 25ms [PAS 97a].
O MP3 (ou MPEG udio layer 3) um algoritmo de compresso de voz utilizado no MPEG-1 ou
no MPEG-2 BC (Backward Compatible), e layer representa uma famlia de algoritmos de
codificao que prov sons de alta qualidade necessitando de uma baixa largura de banda, com
taxa de bits varivel [THO 98]. A largura de banda e a qualidade do sistema podem ser
especificados na codificao do arquivo de udio. As taxas de bit variam de 8Kbps a 320Kbps
[FAQ 98], gerando qualidade de CD estreo em taxas de 128Kbps. Devido complexidade do
algoritmo, a latncia terica de 59ms, mas na prtica superior a 150ms [FAQ 98].
A codificao 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,
eliminao de redundncias, diminuio de rudo, previso linear, codificao de Huffmann e
codificao estreo [THO 98]. O resultado uma taxa de bits 30% menos do que para uma
qualidade equivalente de MP3. Esse tipo de codificao no compatvel com verses anteriores
de udio, ou seja, um decodificador MPEG-1 no vai conseguir decodificar um udio AAC. As
taxas de bit variam de 8Kbps a 160Kbps [MPE 99].
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 transmisso utilizou pacotes UDP + IP + Ethernet, com tamanho total de 126 bytes
(sem contar prembulo nem CRC). Ethernet = 14 bytes, IP=20 bytes, UDP=8 bytes,
udio e nveis superiores=84 bytes;
Atraso de um segundo;
No mudou a taxa de transmisso, independente do CODEC, provavelmente devido a
alguma caracterstica do aplicativo.
A seguir uma descrio dos testes. Evidentemente existe alguma condio no software que
decide utilizar o que bem entende, e no aceita a configurao da interface.
CODEC Microsoft ADPCM, 8000Hz, 4bit, mono : Taxa de 11,54 quadros Ethe rnet por
segundo; Taxa de transmisso: 11,54*84 = 8Kbps.
CODEC Microsoft G.723.1, 8000Hz, mono, 6400 bps : Taxa de 11,54 quadros Ethernet
por segundo; Taxa de transmisso: 11,54*84 = 8Kbps.
CODEC Microsoft G.723.1, 8000Hz, mono, 5333 bps : Taxa de 11,54 quadros Ethernet
por segundo; Taxa de transmisso: 11,54*84 = 8Kbps.
CODEC Lernout&Hauspie SBC 16Kbps, 8000Hz, 16 bits, mono : Taxa de 11,54
quadros Ethernet por segundo; Taxa de transmisso: 11,54*84 = 8Kbps.
Pacotes UDP + IP + Ethernet. Tamanho total sem contar prembulo nem CRC. Ethernet
= 14 bytes, IP=20 bytes, UDP=8 bytes, udio e nveis superiores=resto do pacote.
A qualidade foi muito parecida com todos CODECS, exceto o LPC.
A seguir uma descrio dos testes. Pode-se ver que neste caso a taxa de transmisso
respeitou a configurao da interface com o usurio, 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 nveis superiores=332 bytes. Taxa de transmisso: 25,6*332 = 65Kbps.
Pacote com 20ms : Taxa de 50 quadros Ethernet por segundo. udio e nveis
superiores=172 bytes. Taxa de transmisso: 50*172=65Kbps.
CODEC DVI 40ms : Atraso de 0,8s; Taxa de 25,5 quadros Ethernet por segundo.
udio e nveis superiores=176 bytes; Taxa de transmisso: 25,5*176 = 34Kbps.
CODEC 16 bit linear 40ms : Atraso de 0,8s; Taxa de 25,7 quadros Ethernet por
segundo. udio e nveis superiores=652 bytes. Taxa de transmisso: 25,7*652 =
130Kbps.
CODEC GSM 40ms: Atraso de 0,7s; Taxa de 25,5 quadros Ethernet por segundo.
udio e nveis superiores=88 bytes. Taxa de transmisso: 25,5*88 = 16Kbps.
CODEC LPC 40ms : Atraso de 0,9s; No dava para entender as palavras... Muito ruim.
Taxa de 25 quadros Ethernet por segundo. udio e nveis superiores=40 bytes. Taxa de
transmisso: 25*8 = 8Kbps.
pg. 26
Valter Roesler
8bits, 8000am/s, mono, 5s : arquivo = 40.000 bytes. Terico = 8000x1x5 = 40.000 bytes.
8bits, 16000am/s, mono, 5s : arquivo=80.000 bytes. Terico = 8000x2x5 = 80.000 bytes.
16bits, 44100am/s, stereo, 5s: arquivo=882000 bytes. Terico = 44100x2x2x5 =
882.000 bytes.
Resoluo espacial: significa o tamanho do quadro, ou seja, a relao entre sua largura e
altura. Em meios digitais, para permitir que uma recomendao possa ser utilizada em
tanto em regies 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 vdeo e alguns padres onde
esses formatos so utilizados [PRI 99], [SHA 96], [MCG 99];
Nmero de pixels
128x96
176x144
352x288
702x576
1408x1152
Padres
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 nmero de quadros sucessivos por segundo. Para uma
boa qualidade, o ideal utilizar acima de 24 quadros por segundo (padro atual dos
cinemas). Em termos de compresso da imagem, quanto mais quadros por segundo
melhor a taxa de compresso, pois possvel codificar somente as mudanas entre
quadros. Isso permite a padres que exploram essa caracterstica, como o MPEG,
comprimir 50 a 70 vezes uma transmisso 352x240 30 quadros por segundo, enquanto
padres que no 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 diferena na compresso entre MPEG e M-JPEG no significativa;
Passo de quantizao: quanto maior o nmero de amostras de um vdeo por segundo,
maior a sua qualidade, da mesma forma que foi visto na parte de udio.
A largura de banda necessria para transmisso de vdeo 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 transmisso pela rede, so necessrios aproximadamente
100Kbytes (352x288x1). Para enviar o peixinho se movendo a 30 quadros por segundo sem
compresso alguma, seria necessrio 30 vezes esse tamanho, ou 3Mbytes (24Mbit/s).
Uma figura vale mais que mil palavras, mas uma figura no comprimida vale muitos
megabytes. A tabela a seguir mostra algumas taxas de vdeo no 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 tcnicas de compresso de vdeo que sero vistas em seguida consegue-se
uma qualidade muito boa a taxas bem razoveis. O MPEG-1, por exemplo, foi feito para
produzir sons e imagens de mdia 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 ttulo:
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 transmisses em diversas taxas, tanto
menores como maiores, at 5 Mbps [SHA 96]. J o H.261 consegue transmitir vdeo a
px64Kbps, com p variando de 1 a 30.
A compresso do vdeo no linear de acordo com a taxa de quadros por segundo e sua
resoluo espacial, ou seja, se no formato QCIF a 30 quadros por segundo obtinha-se uma taxa
de transmisso de 1Mbps, no quer dizer que se utilizando o formato CIF a taxa suba para
4Mbps (com a mesma qualidade). Isso porque as tcnicas de compresso exploram as
ambigidades entre pixels adjacentes, bem como redundncias no quadro. Com mais pixels, a
tendncia ter mais ambigidades, e obter-se taxas de compresso maiores.
A seguir ser analisada a codificao de vdeo no MPEG, pois suas tcnicas tambm so
utilizadas em outros padres, mostrando alguns conceitos importantes para comp reender a
compresso e codificao de vdeo. Alm disso, as normas H.261 e H.263 do ITU-T so muito
similares ao MPEG, possuindo as mesmas vantagens e desvantagens, entretanto, o MPEG
consegue uma taxa de compresso ligeiramente superior [MCG 99].
pg. 29
Valter Roesler
I-Frame
B-Frame
P-Frame
> compresso
Na figura acima, uma possvel ordem de apresentao seria:
I B B P B B I
J a ordem de transmisso seria:
I
P B B I B B
Pelo fato da atualizao de um frame ser feita atravs da composio de vrios frames, o
MPEG considerado um formato de edio "Linear", dificultando a edio de imagens, pois tem
que ser sempre baseada num quadro tipo I.
Alm dos tipos de quadros, existem outras duas tcnicas importantes de entender na
compresso MPEG: compensao de movimento e redundncia espacial. A figura a seguir
[CHI 96] mostra um grupo de imagens que sero 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 vrios quadros
tipo P e B.
pg. 30
Valter Roesler
H.263
M-JPEG
MPEG-1
MPEG-2
MPEG-4
Cinepak
Data
Descrio
1993 Video CODEC for audiovisual services at p x 64 kbit/s: com p variando de 1 a 30, utiliza a
unidade bsica de transmisso sendo 64Kbps [ITU 93b]. Seus CODECS devem ter formato
QCIF obrigatoriamente e CIF opcionalmente. Utiliza DCT e compensao de movimento para
compresso de vdeo.
1996 Video coding for low bit rate communication: destinado a taxas menores. A norma H.263
consegue qualidade utilizando tcnicas de estimativa de movimento, previso de quadros e
codificao de Huffmann [PRI 99]. Seus CODECS devem ter formato sub-QCIF e QCIF
obrigatoriamente, e CIF, 4CIF e 16 CIF opcionalmente. Utiliza DCT e compensao de
movimento para compresso de vdeo.
Trabalha com a compresso de cada quadro individualmente, facilitando a edio, mas gerando
uma largura de banda maior por no se valer de tcnicas interframe.
Utilizado para taxas de transmisso de udio e vdeo at 1,5Mbps, chegando a 5 Mbps. Utiliza
DCT e compensao de movimento para compresso de vdeo.
Utilizado para transmisso de vdeo com maior qualidade, de 3 a 10Mbps [SHA 96]. Utiliza
DCT e compensao de movimento para compresso de vdeo.
Permite taxas de bits bastante variadas, dependendo da aplicao. Pode ir de 5 a 64Kbps, em
taxas muito baixas (Very Low Bit Rate Video), mas aumentando a qualidade se a aplicao
permitir, chegando a 4Mbps [CHI 98]. Utiliza DCT e compensao de movimento para
compresso de vdeo.
CODEC utilizado pelo padro video for windows, da Microsoft [MOU 99]. Da mesma forma que
o M-JPEG, trabalha com compresso de cada quadro individualmente.
pg. 31
Valter Roesler
CODEC para codificao de vdeo desenvolvido pela Intel [MOU 99]. A verso Indeo 5.1 utiliza
compresso de vdeo baseada em Wavelets, e consegue uma compresso quase o dobro do que
MPEG, JPEG e H.26x [MCG 99].
pg. 32
Valter Roesler
A figura a seguir (que est na parte inferior da interface via Web), mostra com mais
detalhes a tela de interatividade com o palestrante, atravs da qual as pessoas que estavam
assistindo em um PC podiam enviar perguntas a um mediador no Auditrio Padre Werner.
A tela de interatividade mostrada na figura servia apenas para quem estava assistindo no
PC. As pessoas localizadas no Auditrio Central podiam fazer perguntas em tempo real ao
2
pg. 33
Valter Roesler
palestrante (no Auditrio Padre Werner) atravs de videoconferncia. Como ferramenta foi
utilizado o VIC; conseguiu-se uma tima qualidade de transmisso. As mquinas utilizadas na
videoconferncia foram Pentium II 400 MHz e a velocidade configurada no VIC foi de 3 Mbps,
protocolo de vdeo H.261 e udio mono com taxa de amostragem de 8 kHz. No primeiro dia,
foram utilizadas mquinas Pentium 233 MHz, mas elas mostraram-se lentas para codificar e
decodificar as imagens transmitidas a 3 Mbps.
vide http://www.whitepine.com
pg. 34
Valter Roesler
8 Bibliografia
[CHI 96]
[FAQ 98]
[ITU 98]
[ITU 98a]
[ITU 97]
[ITU 96]
[ITU 96a]
[ITU 93]
[ITU 93a]
[ITU 93b]
[ITU 92]
[SHA 96]
[SPU 00]
[TAN 97]
[THO 98]
pg. 35
Valter Roesler