Downloads Telematica Com Dados 2 Leitura Adicional Multimidia

Transmisso multimdia em redes de computadores
Autor: Valter Roesler Universidade: UNISINOS
Data: Julho de 2001
Multimdia em redes de computadores
pg. 2 Valter Roesler
SUMRIO
1 Transmisso multimdia em redes........................................................................................... 3 1.1 Latncia ........................................................................................................................... 4 1.2 Jitter ................................................................................................................................. 4 1.3 Skew ................................................................................................................................ 5 1.4 Tabela comparativa ......................................................................................................... 5 Protocolos de tempo real para transmisses multimdia ......................................................... 6 2.1 RTP.................................................................................................................................. 6 2.1.1 Entidades RTP ......................................................................................................... 7 2.1.2 Cabealho RTP ........................................................................................................ 8 2.1.3 Exemplo: conferncia de udio ............................................................................... 8 2.1.4 Exemplo: videoconferncia ..................................................................................... 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 Restries de tempo nos pacotes RTCP................................................................ 12 Padres de multimdia 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 Sinalizao no H.323............................................................................................. 18 3.1.6 Exemplo de conferncia 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 Comparao entre SIP e H.323 ..................................................................................... 20 3.3.1 Atraso de conexo ................................................................................................. 20 3.3.2 Escalabilidade........................................................................................................ 20 3.3.3 Tamanho da conferncia ....................................................................................... 20 3.3.4 Uso de novos CODECS ........................................................................................ 21 3.3.5 Formato de endereo ............................................................................................. 21 3.3.6 Complexidade........................................................................................................ 21 Compresso de udio e vdeo ................................................................................................ 21 Padres de udio e vdeo ....................................................................................................... 22 5.1 Codificao 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 Codificao de vdeo ..................................................................................................... 26 5.2.1 Codificao de vdeo no M-JPEG......................................................................... 28 5.2.2 Codificao de vdeo no MPEG ............................................................................ 28 5.2.3 Resumo de padres para codificao de vdeo...................................................... 30 Estudo de caso 1: Transmisso multicast ao vivo durante a VI Semana da Qualidade na Unisinos................................................................................................................................ 31
4 5
Multimdia em redes de computadores 7 8
Estudo de caso2: Videoconferncia multicast no Metropoa ................................................. 33 Bibliografia............................................................................................................................ 34
1 Transmisso multimdia em redes

As etapas de uma transmisso multimdia so mostradas na figura a seguir:
Sinal de entrada Digitalizao Compresso Transmisso Perda / atraso
Sinal de sada
Recuperao
Descompresso
Reordenao
O sinal gerado inicialmente digitalizado, para ento passar por um processo de compresso, que diminui seu tamanho, tornando-o vivel para ser transmitido na rede. A rede insere alguns atrasos no sistema. No receptor, os pacotes so reordenados, descomprimidos e reconvertidos ao estado original, normalmente com perdas inseridas no processo de compresso. Esses aspectos sero analisados no decorrer desta apostila. As aplicaes que necessitam transmisso multimdia em redes de computadores se encontram subdivididas em duas partes, como a figura a seguir ilustra: teleconferncia (que requer interatividade) e transmisso unidirecional (que envolve apenas um lado transmitindo e vrios clientes recebendo). Na figura, pode-se ver uma diviso dos dados em udio, vdeo e texto.
Aplicaes multimdia
Conferncias (interatividade)
Transmisso Unidirecional
udio
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.
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
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
1.4 Tabela comparativa

A tabela a seguir apresenta algumas aplicaes tpicas de multimdia em rede, bem como seus fatores crticos. Aplicaes de telefonia (voz) so sensveis latncia e ao jitter. Em termos de velocidade, sua necessidade baixa, variando de 5 Kbps (compresso no padro G.723) a 64Kbps (padro G.711, o mais comum em telefonia atualmente). latncia jitter skew velocidade (largura de banda) Telefone sensvel sensvel baixa TV insensvel sensvel sensvel alta Videoconferncia sensvel sensvel sensvel alta
J em transmisses unilaterais de udio e vdeo (por exemplo, TV), h uma flexibilidade maior quanto latncia. Isso se deve ao fato que, na maioria dos casos, para o usurio no seria relevante a incluso de um pequeno atraso entre o momento em que um evento se d e sua exibio. Entretanto, esse atraso deve se manter fixo at o final e com sincronismo entre udio e vdeo, da a necessidade de jitter e skew baixos. Aplicaes de videoconferncia so muito parecidas com aplicaes de telefonia em termos de latncia e jitter, entretanto, possuem alta largura de banda e devem manter um baixo skew, pois necessitam sincronizao entre udio e vdeo.
2 Protocolos de tempo real para transmisses multimdia

Para transportar dados em tempo real, so necessrios protocolos que levem consigo informaes de sincronismo e de tempo, como o RTP (Real-time Transport Protocol). Para fornecer feedbacks aos participantes da transmisso efetuada pelo RTP, existe o protocolo RTCP (RTP Control Protocol). Ambos so analisados a seguir.
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]: Deteco de perda de pacotes: observando o nmero de seqncia possvel saber se houve perda de pacotes ou no. Isso til para estimar a qualidade da recepo, adaptao da aplicao s caractersticas da rede, recuperao de dados, e assim por diante; Sincronizao intra -mdia: o campo de timestamp do cabealho informa ao receptor o momento exato de passar os dados ao usurio. Essa informao usada pelo receptor absorver o jitter da rede atravs de um buffer auxiliar; Sincronizao inter-mdia: o campo de timestamp do cabealho de diferentes sesses RTP (como udio e vdeo) pode ser usado em conjunto com o protocolo NTP (Network Time Protocol) a fim de sincronizar as diferentes mdias, permitindo ao receptor a adaptao ao skew. Um exemplo tpico o sincronismo voz-lbio. 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 servio da rede no so especificadas no RTP, e devem ser obtidas atravs 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 servio (da sesso e no da rede) e levar informaes sobre os participantes de uma sesso em andamento, como, por exemplo, uma conferncia de udio entre diversos participantes. Em termos do modelo OSI, o RTP se situa acima do nvel 4, no subnvel inferior do nvel de aplicao, como mostra a figura a seguir [PAU 98, pg 194]. O IP pode ser tanto unicast como multicast, e o protocolo de nvel 2 (Ethernet) apenas um exemplo.

Aplicao Encapsulamento de mdia RTP RTCP dados UDP controle
IPv4 / IPv6 Unicast ou multicast
Ethernet
2.1.1 Entidades RTP

s vezes surgem necessidades na transmisso de sinais em tempo real, como, por exemplo, vrias pessoas participando duma conferncia de udio, sendo que algumas esto em enlaces congestionados ou com mquinas lentas. Para evitar que todos participantes utilizem um algoritmo de compactao de udio de baixa qualidade, pode-se utilizar um tradutor (translator). Outras vezes, pode ser necessrio combinar mltiplos fluxos em um s, a fim de distribuir a um conjunto de receptores, e a se utiliza o multiplexador (mixer). Essas duas entidades so importantes para entender o RTP, e so mostradas na figura [PAU 98, pg 195].
Sistema origem / destino IP=10.16.169.53 SSRC = 87 Troca de codificao Mltiplos fluxos PCM MP3 SSRC = 46 Sistema origem / destino IP=10.16.165.29 SSRC = 35 ADPCM Tradutor MP3 IP 10.18.32.14 IP 10.13.45.6 SSRC = 46 Multiplexador CSRC = 87, 35 Fluxo nico
O tradutor um sistema intermedirio que encaminha os pacotes RTP com o SSRC e timestamp intactos, porm, modifica servios de traduo, como, por exemplo, a converso do formato de codificao (ADPCM para MP3), ou converter um pacote multicast em vrios pacotes unicast, ou efetuar uma conexo segura com mquinas atrs de firewalls. O multiplexador um sistema intermedirio que recebe pacotes RTP de uma ou mais origens, gerando uma nica sada com a combinao das diversas origens (e tambm a traduo de formato de codificao, se necessrio). Como o timestamp das diversas origens pode ser diferente, o multiplexador efetua os ajustes de tempo (buffers) e gera sua prpria seqncia de tempo para o fluxo concatenado. Assim, todas os pacotes de dados originados no multiplexador tero o multiplexador como sua origem de sincronizao (SSRC).
2.1.2 Cabealho RTP

O cabealho do RTP visto na figura a seguir.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
V=2 P X CC M PT 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]: Verso (V): 2 bits : identifica a verso do protocolo RTP; Padding (P): 1 bit: se esse bit estiver ligado, o pacote contm um ou mais bytes de enchimento no final que no fazem parte dos dados teis, devendo ser ignorados. Esses bytes podem ser necessrios por alguns algoritmos de criptografia com tamanhos fixos de blocos, ou para enviar muitos pacotes RTP em um protocolo de nvel inferior; Extenso (X): 1 bit: se esse bit estiver ligado, o cabealho ter uma extenso com o mesmo nmero de bytes, em formato definido na RFC 1889; Contador de CSRC (CC): 4 bits : nmero de identificadores CSRC que seguem o tamanho fixo do cabealho; Marcado r (M): 1 bit: tem o objetivo de permitir eventos significativos, tal como limites de quadro, serem marcados no fluxo de pacotes; Payload Type (PT): 7 bits : identifica o formato da carga til do pacote, de forma que possa ser interpretado pela aplicao. Um exemplo udio codificado em PCM ou ADPCM, ou vdeo codificado em MPEG ou H.263, e assim por diante; Nmero de seqncia: 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 seqncia 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 relgio que incrementa linearmente no tempo a fim de permitir sincronizao e clculo de jitter. A resoluo do relgio deve ser suficiente para a preciso de sincronizao desejada e medio de jitter; SSRC: 32 bits: identifica a origem da sincronizao. Esse nmero escolhido randomicamente, procurando fazer com que todas as fontes de sincronizao tenham identificadores diferentes. Caso haja colises, o SSRC modificado de acordo com um algoritmo determinado na RFC 1889; CSRC: 32 bits cada identificador: mximo de 15 itens : identifica as fontes que contriburam para a carga de dados existente no pacote RTP. Esses campos so inseridos por multiplexadores, usando os SSRCs das fontes contribuintes. Assim, por exemplo, para pacotes de udio de vrias 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: conferncia de udio

Um exemplo de uso do RTP visto na RFC 1889 (pg 5), onde ele utilizado para efetivao de uma conferncia de udio em multicast. No incio so alocados duas portas UDP (uma para dados RTP e outra para controle RTCP) e um endereo IP multicast. Essa informao transmitida para todos os participantes. A aplicao utilizada pelos participantes envia udio
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.1.4 Exemplo: videoconferncia

Numa videoconferncia, os pacotes de udio e vdeo so transmitidos em sesses RTP separadas, portanto, existem dois pares diferentes de portas UDP e nmeros IP (unicast ou multicast). A identificao do acoplamento entre as mdias no receptor obtida atravs do nome cannico utilizado pelo protocolo RTCP. Uma das motivaes para esta separao permitir a alguns participantes na conferncia receber somente um meio (udio ou vdeo). A sincronizao entre udio e vdeo pode ser obtida atravs do timestamp de ambas sesses, juntamente com a utilizao do protocolo NTP (Network Time Protocol), enviado pelo RTCP (pacote SR Sender Report). O NTP utiliza um valor de tempo absoluto, que o nmero de segundos relativo 0h de 1o de janeiro de 1900. /**/ /* sniffar videoconferncia identificar pacotes RTCP e forma de sincronizao intermdia. */
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]: Fornecer feedback sobre a qualidade de servio obtida na distribuio de dados RTP. Exemplos de utilizao so: controle de codificadores adaptativos (muda algoritmo de compactao dependendo da qualidade), diagnstico de problemas na rede, e outros; Enviar o nome cannico (CNAME) do transmissor dos dados, utilizado para que todos saibam quem originou a transmisso. O uso do SSRC para identificar a origem no eficaz, visto que pode haver mudana nesse nmero em caso de conflitos. Alm disso, um transmissor com mltiplas sesses RTP (udio e vdeo) utiliza um SSRC para cada sesso, e o receptor precisa um nome cannico para identificar a origem e poder sincronizar as sesses;
Controle da periodicidade de envio dos pacotes RTCP, a fim de permitir a escalabilidade do sistema; Funo opcional para permitir o transporte de informaes mnimas de controle, permitindo, por exemplo, que a identificao de cada participante seja apresentada na interface com o usurio.
Os principais tipos de pacotes utilizados pelo RTCP so o SR (Sender Report), o RR (Receiver Report), o SDES ( Source Description), o BYE e o APP (funes especficas da aplicao). Os itens a seguir analisam cada um deles com mais detalhes.
2.2.1 SR (Sender Report)

Os pacotes SR (Sender Report) so enviados pelos transmissores, e contm informaes de timestamp NTP, timestamp RTP, nmero de pacotes enviados, nmero de bytes enviados, bem como informaes da qualidade dos outros transmissores que chegam a eles. Com os timestamps (NTP e RTP), o receptor consegue sincronizar mais de uma sesso relacionada (como udio e vdeo). A figura a seguir ilustra o formato do pacote SR [RFC 1889, pg 23].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fraction lost | cumulative number of packets lost | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header
sender info
report block 1
report block 2
Os pacotes SR consistem de 3 sees: um cabealho de 8 bytes, uma seo de informaes do transmissor, e uma seo de informaes de outros transmissores. No final, possvel ainda a existncia de uma quarta seo contendo extenses especficas de perfil. Esta seo no ser explicada neste documento. Os principais campos so explicados a seguir. Para maiores informaes, uma referncia a RFC 1889. 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;
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.
/**/ sniffar a rede e capturar pacotes RTCP de uma videoconferncia, identificando os campos */
2.2.2 RR (Receiver Report)

Os pacotes RR (Receiver Report) so enviados pelos receptores das sesses RTP existentes. O formato do pacote RR o mesmo do SR, exceto que o tipo de pacote 201 em vez de 200 e a seo 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) contm informaes especficas do transmissor, identificadas por seu tipo. Esto definidos os seguintes tipos [RFC 1889, pg 34]: Tipo = 1: CNAME: nome cannico, que identifica univocamente o transmissor, como, por exemplo, user@domnio; Tipo = 2: NAME: nome do transmissor, por exemplo Joo da Silva, empresa X; Tipo = 3: EMAIL: e- mail do transmissor, por exemplo jsilva@x.com.br; Tipo = 4: PHONE: telefone do transmissor, identificado com o sinal de + para o cdigo internacional. Por exemplo +55 51 991 56118; Tipo = 5: LOC: localizao geogrfica, por exemplo Porto Alegre, RS; Tipo = 6: TOOL: nome e verso da ferramenta utilizada para transmitir, por exemplo videotool;
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.
2.2.6 Restries de tempo nos pacotes RTCP

O protocolo RTCP gera pacotes de controle, e, caso no houvesse restries, poderia sobrecarregar a rede numa sesso com um grande nmero de participantes. Procurando se adaptar a isso, o trfego de controle RTCP deve se manter em torno de 5% do trfego total de determinada sesso RTP. 25% deste trfego (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 trfego de controle uma frao constante do trfego total, medida que o nmero de receptores aumenta, o nmero de pacotes RTCP por participante diminui [PAU 98, pg 200]. O intervalo mnimo sugerido entre pacotes RTCP de 5 segundos (para evitar excesso de pacotes RTCP), mas numa sesso, o intervalo pode ir de 2 a 5 minutos. Um receptor deve desconsiderar um participante da estatstica caso ele no se manifeste em 30 minutos. Um pacote RTCP transmitido aps o tempo calculado vezes um tempo randmico entre 0,5s e 1,5s. Isso para evitar sincronizao de pacotes entre vrias entidades (transmissores e receptores), o que ocasionaria uma rajada de trfego RTCP naquele mo mento.
3 Padres de multimdia em redes de computadores

Existem muitos padres atualmente para multimdia em redes de computadores, e os mais enfatizados neste documento so os do ITU-T e do IETF. Os padres de multimdia do ITU-T so os da srie H (Sistemas audiovisuais e de multimdia) e esto citados na tabela a seguir. Cada um deles tem uma finalidade especfica, como o H.323, por exemplo, que trata somente da comunicao multimdia em redes de pacotes.
Multimdia em redes de computadores Padro H.310 H.320 H.321 H.322 H.323 H.324 Data 1996 1997 1996 1996 1998 1996
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
Cada um dos protocolos da srie H especifica um conjunto de outros protocolos para resolver funes especficas na rede, como, por exemplo, sinalizao, codificao de udio, codificao de vdeo, 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 i so vai ficar mais s claro. Os padres multimdia do IETF so definidos nas RFCs. A arquitetura global de multimdia do IETF atualmente possui protocolos como os seguintes [RFC 2543, pg 8]: 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.
Os padres do ITU-T e do IETF conseguem conversar entre si atravs de gateways. A seguir ser analisado com maiores detalhes o protocolo do ITU para comunicao multimdia sobre redes de pacotes (o H.323). No item seguinte, o SIP ser analisado, e depois ser feita uma comparao entre SIP e H.323 em relao a sinalizao e controle, pois ambos so equivalentes nesse assunto.
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]: Interoperabilidade : definindo normas de CODECs de udio e vdeo, possvel integrar sistemas de diferentes fabricantes sem problemas; Gerncia de banda : possvel limitar o nmero de conexes H.323 simultneas, bem como a largura de banda utilizada pelas aplicaes;
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 Rede baseada em pacotes
HUB Gatekeeper H.323 Gateway H.323
Terminal H.323
Terminal H.323
GSTN
LAN com QoS
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].

Escopo da norma H.323 Eqto de entrada de udio (microfone, vdeo cassete) Eqto de entrada de vdeo Cmera de vdeo, vdeo cassete) CODEC de udio G.711, G.722, G.723, G.728, G.729 Receive Path CODEC de vdeo H.261, H.263 Delay
Aplicaes de dados (T.120, etc) Controle do sistema Controle H.245 Controle de chamada H.225.0 Controle RAS H.225.0 Sinalizao Q.931
Camada H.225.0
Interface LAN
Controle do sistema
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
conexo, so trocadas mensagens de sinalizao H.245 capability exchange, para descobrir a capacidade dos terminais, o que permite a escolha da taxa de transmisso em bits/s, o formato da imagem, algoritmo de compactao, e assim por diante [ITU 98, pg 15]; Controle de RAS (Registration, Admission and Status): utiliza mensagens H.225.0 para fazer funes de registro, admisso, mudana de largura de banda, status e desligamento entre Gatekeepers e terminais. Em ambientes que no tem Gatekeeper, o RAS no utilizado; Camada H.225.0: formata as informaes (vdeo, udio, dados) a serem transmitidas ou recebidas da interface de rede. Alm disso, faz controle de erros e numerao de seqncia, dependendo do meio. A norma H.225.0 [ITU 98a] utiliza os protocolos RTP e RTCP [RFC 1889] para sincronizao e montagem dos pacotes; Receive Path Delay: um atraso includo no fluxo de entrada de dados a fim de manter a sincronizao e controlar o jitter, conseguindo assim, por exemplo, sincronizao labial.
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: Traduo de endereo: necessrio traduzir o endereo LAN dos terminais e gateways (aliases mais fceis de decorar) para endereos IP ou IPX, conforme a especificao do RAS; Controle de admisso: Autorizao de acesso LAN usando mensagens de admission request, confirm e reject (ARQ, ARC, ARJ); Gerncia de zona : o gatekeeper prov as funes 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 Gerncia de banda : se um gerente especificou um nmero mximo de conferncias na rede, o gatekeeper pode deixar de aceitar conexes aps esse mximo ter sido atingido, limitando a largura de banda utilizada pelo H.323 como um todo;
Zona H.323 Terminal Gatekeeper Gateway Terminal Terminal
HUB
HUB
Terminal
Terminal
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.
As principais aplicaes do gateway so as seguintes [PRI 99]: Estabelecer links com terminais analgicos da telefonia pblica; Estabelecer links atravs de redes RDSI com terminais compatveis H.320; Estabelecer links atravs de redes pblicas de telefonia com terminais compatveis H.324.
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.
udio e Vdeo multicast Descentralizado
udio e Vdeo unicast Centralizado
3.1.5 Sinalizao no H.323

O H.323 utiliza uma srie de protocolos de sinalizao, conforme mostrado na figura a seguir. A explicao a seguir assume a existncia do gatekeeper, mas caso ele no exista, as mensagens de sinalizao so trocadas diretamente entre origem e destino [SCH 99], [ITU 98]. Inicialmente, so 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 no mostra, mas o destino tambm deve se registrar no seu gatekeeper (visto na tabela aps a figura). Logo em seguida, deve ser estabelecido o canal confivel (TCP) de sinalizao ( all c signalling channel) para trocar mensagens de controle H.225.0 (que, por sua vez, utiliza mensagens Q.931 para sinalizao). Da mesma forma que foi estabelecido um canal confivel de sinalizao H.225.0 (via Q.931), deve ser estabelecido um canal confivel (TCP) de controle para o H.245. A sinalizao 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 vdeo, e assim por diante.
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.

RTT 1 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
3 4 5 6 7
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.1.6 Exemplo de conferncia 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 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: Localizao de usurio: determinao do endereo a ser usado para comunicao. O endereo SIP da forma user@host. A parte User um nome de usurio ou nmero de telefone, e a parte host um nome de domnio ou nmero de rede. Em redes heterogneas, SIP pode ser usado para determinar que o interlocutor pode ser encontrado via H.323, obter o endereo do usurio e endereo do gateway via H.245 e usar o H.225.0 para estabelecer a chamada; Capacidades do usurio: determinao da mdia e seus parmetros;
Disponibilidade do usurio: determinao da vontade do interlocutor de entrar na comunicao; Estabelecimento da chamada (call setup): estabelecimento dos parmetros de chamada entre participantes. Utiliza para isso os mtodos INVITE e ACK. O mtodo INVITE contm, normalmente, uma descrio da sesso, sendo utilizado um formato especfico, como o SDP, descrito na RFC 2327; Tratamento da chamada (call handling): inclui transferncia e trmino de chamadas. O trmino de chamadas com o mtodo BYE.
3.3 Comparao 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 sinalizao de dados, possvel fazer uma comparao entre ambos, como pode ser visto em [SCH 99] e [SCH 99a]. H.323 compreende uma srie de protocolos, como RTP para transporte de dados, H.225.0 (com sinalizao RAS e Q.931) para configurao, H.245 para negociao de formato, H.450 para servios suplementares e H.332 para conferncias 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 conexo

Dependendo do uso ou no de um gatekeeper, o estabelecimento de conexo 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 conexo (isso foi visto anteriormente). No H.323 v2 com fast connect , o atraso reduzido para 2,5 RTTs. A adio do anexo E (UDP -based signalling), pode reduzir para 1,5 RTTs [SCH 99]. O estabelecimento de conexo 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 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.
3.3.3 Tamanho da conferncia

O H.323 permite conferncias atravs do MCU (Multipoint Control Unit), at mesmo para conferncias pequenas. Caso o usurio de uma pequena conferncia esteja sendo o MC (Multipoint Controller), e desligue sua mquina, a conferncia inteira termina. O uso obrigatrio de MCs provoca problemas de escalabilidade.
O SIP no necessita do MC, suportando conferncias atravs de multicast diretamente pelos terminais, permitindo uma escalabilidade de 2 a milhes 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 so 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 cdigos. Como a maioria deles possuem direitos de propriedade intelectual, no 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 endereo

O destinatrio de uma conexo SIP pode ser qualquer URL, incluindo mailto, phone, H.323 e http. H.323 v1 permite enderear qualquer host diretamente (mas sem nome de usurio), ou usar um alias. Todos aliases devem ser resolvidos pelo gatekeeper.
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.
4 Compresso de udio e vdeo

Os itens a seguir resumem algumas tcnicas de compresso de udio e vdeo. Os itens em azul se referem a vdeo, os em vermelho a udio e vdeo, e em verde se refere a somente udio. Redundncia Espacial: valores dos pixels prximos so bastante correlacionados Redundncia em escala: bordas retas e regies constantes so invariveis quando reescalando Redundncia em freqncia: um sinal mais forte pode mascarar sinais de mesma freqncia mais fracos Redundncia temporal: quadros adjacentes de vdeo normalmente possuem pouca mudana Redundncia estreo: existem correlaes entre canais de udio estreo que podem ser comprimidas A compresso tem algumas caractersticas, citadas a seguir: Sem perdas: dados originais podem ser recuperados precisamente Com perdas: ocorrem perdas na compresso Intraframe: quadros so codificados independentemente Interframe: leva em conta quadros anteriores e futuros Simtrica: tempos de codificao e decodificao iguais Assimtrica: tempo de codificao maior que decodificao
Multimdia em redes de computadores Tempo real: atraso de codificao no deve exceder 50ms Escalvel: quadros codificados em nveis de resoluo diferentes
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
Dependendo do tipo de compresso desejada, deve-se utilizar o algoritmo correspondente, como mostram os itens a seguir: Entropy coding (sem perdas): Aritmtica, huffman, run- length Source coding (com perdas): Differencial Pulse Code Modulation, Discrete Cosine Transform, Discrete Wavelet Transform, Fourier Transform, Motion-compensated prediction Hybrid coding (combinao dos dois): Fractal, H.261, H.263, JPEG, MPEG vdeo, MPEG udio, Perceptual audio coder, wavelet image compression.
A codificao hbrida consegue as melhores taxas de compresso, pois efetua inicialmente uma compresso com perdas (a fim de aproveitar bem as redundncias do sinal), e em seguida aplica uma compresso sem perdas, a fim de explorar outras caractersticas que podem ainda ser comprimidas. A figura a seguir ilustra o processo.
Dados no comprimidos Source Coding Entropy Coding Dados comprimidos
Preparao
Um exemplo de compresso pode ser o DPCM (PCM diferencial). Para a seqncia de amostras 10,12,14,16,18 e 20, o DPCM forma 10,2,2,2,2,2. Aplicando posteriormente o mtodo run- length encoding, fica 10!52.
5 Padres de udio e vdeo

A seguir sero analisados alguns padres e aspectos relevantes para a transmisso de udio e vdeo, base para as comunicaes multimdia em rede. O conhecimento de tais padres importante para adaptar as condies da rede aplicao.
5.1 Codificao de udio

Os sinais de voz que partem do ser humano e de instrumentos musicais so analgicos e sonoros, ou seja, o ar empurrado com mais ou menos intensidade, um determinado nmero de vezes por segundo, gerando uma onda que se propaga. Quando atinge o ouvido, este decodifica as ondas sonoras e as transforma em percepes ao crebro, que identifica um padro e monta uma mensagem. A freqncia da voz humana, ou seja, o nmero de vezes por segundo que o ar empurrado, dada pelas cordas vocais, gerando um som mais agudo (de maior freqncia), ou mais grave (de menor freqncia). 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 conversao normal, as freqncias esto 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 ligaes. Isso foi feito para conseguir mais ligaes entre centrais pblicas utilizando o mesmo meio fsico, que o princpio da multiplexao 1 , visto atravs da figura a seguir. J instrumentos musicais atingem freqncias bem mais altas. O piano, por exemplo, vai normalmente de 20Hz a 7KHz (chegando a 18KHz), e o violino vai de 200Hz a 10KHz (chegando a 20KHz).
Limita em 4KHz CENTRAL PBLICA Vrios canais de 4KHz multiplexados na mesma linha CENTRAL PBLICA
Para transmisso de udio em redes de computadores, vale ressaltar os seguintes itens: Digitalizao: necessrio digitalizar o sinal para transformar os sinais analgicos em bits, necessrio para transmisso em redes de computadores; Compresso: a compresso usada para minimizar o uso de largura de banda. O padro PCM (G.711 do ITU-T) necessita 64Kbps para transmisso, enquanto o G.729 utiliza apenas 8Kbps. Uma transmisso com durao de 30 segundos no padro G.711 demandaria 240.000 bytes, enquanto que a mesma transmisso com o G729 iria necessitar de 30.000 bytes, ou 1/8 da anterior. A tabela a seguir mostra algumas taxas de transmisso sem compresso;
Formato Telefonia Teleconferncia CD rom Digital Audio Tape Amostragem 8000/8bits/mono 16000/16bits/mono 44100/16bits/stereo 48000/16bits/stereo Bit rate 64 Kbit/s 256 Kbit/s 1.410 Kbit/s 1.536 Kbit/s
Qualidade do sinal: a qualidade do sinal est relacionada com a freqncia de amostragem e nmero 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, necessrio o dobro da freqncia para poder recuperar
Multiplexar utilizar a mesma linha fsica para transmitir vrios canais
completamente o sinal. Entretanto, o mesmo nmero de amostras no suficiente para uma qualidade de CD, e na prtica utiliza-se 44,1KHz com 16 bits por amostra estreo, gerando a necessidade de m de 1,4Mbps (44100x16x2). Na prtica, utiliza-se algum ais algoritmo de compresso do sinal, como o MP3, que consegue qualidade de CD com 128Kbps, ou qualidade de FM com 56Kbps; Latncia de codificao: em aplicaes que exigem interatividade, como, por exe mplo, uma conversa telefnica, manter a latncia baixa muito importante. O G.711 possui uma latncia de codificao desprezvel, enquanto que o MP3 precisa de mais de 50ms para codificar o udio.
A tabela a seguir mostra um resumo de alguns padres utilizados atualmente para codificao e transmisso de udio.
Padro Data G.711 1988, 1993 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].
G.722
1988, 1993
G.723
1996
G.728
1992, 1997
G.729
1996
MP3
1992
AAC
1998
5.1.1 Testes de udio com Netmeeting

Em 10/7/00 foram efetuados alguns testes de transmisso 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 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.
5.1.2 Testes de udio com o RAT (Robust Audio Tool)

Em 10/7/00 foram efetuados alguns testes de transmisso 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 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.
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 prtica. 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.
5.2 Codificao de vdeo

Vdeo pode ser definido como uma seqncia de imagens paradas que, quando apresentadas em uma taxa suficientemente rpida, do a impresso de movimento ao ser humano, como, por exemplo, os seguintes sistemas analgicos: NTSC (National Television Standards Committee) 525x60: 30 quadros por segundo, sendo apresentados em 525 linhas e, de forma entrelaada, 60 vezes por segundo (cada quadro dividido em linhas pares e mpares) para melhorar a sensao de movimento; PAL (Phase Alternation Line) 625x50: 25 quadros por segundo, sendo apresentados em 625 linhas e, de forma entrelaada, 50 vezes por segundo (cada quadro dividido em linhas pares e mpares) para melhorar a sensao de movimento.
Para apresentar a imagem em meios digitais, necessria a converso entre os padres analgicos (25 ou 30 quadros por segundo entrelaados) e digitais (freqncia de atualizao 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 freqncia do monitor (60Hz, 75Hz, etc). O PAL (Phase Alternation Line) utiliza 625 linhas e 25 qps. A resoluo espacial da TV 4x3, resultando 833x625 (nem tudo visvel). O equivalente digital no PAL o CIF (Common Intermediate Format), equivalente a um quarto do tamanho da rea visvel 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 visvel). O equivalente CIF no NTSC 320x240. Da mesma forma que no udio, os fatores digitalizao, compresso, qualidade do sinal e latncia so extremamente importantes na transmisso de vdeo. Basicamente, existem trs pontos que podem ser ajustados para modificar a qualidade e a taxa de transmisso: a resoluo espacial (largura x altura) da imagem, a taxa de quadros e os passos de quantizao [MCG 99]. 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];

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

640x480 27 Mbytes 1,6 Gbytes 96 Gbytes 320x240 6,75 Mbytes 400 Mbytes 24 Gbytes 160x120 1,68 Mbytes 100 Mbytes 6 Gbytes
1 seg 1 min 1 hora
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].
5.2.1 Codificao de vdeo no M-JPEG

Muitos CODECs de vdeo utilizados hoje em dia so baseados no JPEG (Joint Photographic Experts Group) que, como o nome indica, encaram o vdeo como uma seqncia de quadros ou imagens estticas. Dentro dessa linha ficam o Motion-JPEG, e o Cinepak. A compresso nessa linha intraframe, ou seja, pode-se comprimir cada quadro isoladamente na hora da transmisso. O M-JPEG utiliza a mesma codificao do JPEG, no fazendo codificao entre os frames, assim, o formato da edio no linear, facilitando assim a edio de imagens. Um exemplo de seqncia de quadros M-JPEG I I I I I I ..., ou seja, todos quadros so do tipo I (intra frames, ou quadros completos, como ser definido adiante).
5.2.2 Codificao de vdeo no MPEG

O MPEG trabalha de uma forma bem mais complicada que o M-JPEG, introduzindo a noo de seqncia de quadros, ou seja, permite a comparao entre o quadro atual e o seguinte, fazendo com que somente a diferena entre eles seja armazenada. Isso garante taxas de compresso muito mais altas. A compresso dessa forma dita interframes [SHA 96]. Assim, MPEG no precisa armazenar todo quadro, mas somente o que nico em cada quadro. Um fluxo MPEG efetua compresso atravs de trs tipos de quadros: I (intra frames), P (predicted frames) e B (bi-direcional frames), que so configurados no CODEC. A figura a seguir mostra um exemplo genrico de funcionamento, e o significado de cada quadro o seguinte: Tipo I (intra frames): so os quadros completos, ou seja, os quadros contendo toda a informao, tornando-os aptos a serem o ponto de partida para a decodificao. Os quadros I possuem o maior tamanho de todos, e so codificados com JPEG.
Tipo P (predicted frames): so os quadros baseados no anterior (ou intra ou predicted). Eles tambm podem ser referncia para o prximo quadro do tipo predicted, caso necessrio. Como s necessrio salvar as alteraes com relao ao ltimo quadro, possuem uma alta compresso. Tipo B (bi-direcional frames): referem-se a um quadro anterior e um possvel quadro futuro, sendo os mais comprimidos na stream. Eles contm to pouca informao que nunca so usados como referncia para outros quadros.
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.
Compensao de movimento a tcnica 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 no mudam, por exemplo). Essas similaridades so ignoradas, reduzindo a quantidade de dados que necessita ser armazenada. Se tais macro blocos mudam de posio dentro do quadro, isso tambm analisado, sendo armazenados somente os vetores do movimento efetuado. A redundncia espacial ento utilizada, comprimindo ainda mais os dados atravs da descrio da diferena entre os macro blocos. Usando a transformada discreta do coseno (Discrete Cosine Transform - DCT), os macro blocos so divididos em blocos 8x8, onde so pesquisadas mudanas na cor e brilho ao longo do tempo [SHA 96].
5.2.3 Resumo de padres para codificao de vdeo

A tabela a seguir mostra um resumo de alguns padres utilizados atualmente para codificao e transmisso de vdeo.
Padro H.261 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.
H.263
M-JPEG MPEG-1 MPEG-2 MPEG-4
Cinepak

Indeo
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].
6 Estudo de caso 1: Transmisso 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 auditrio da Unisinos (Padre Werner) foi o local destinado s palestras realizadas. Devido grande procura por estudantes e funcionrios, um segundo auditrio (Central) foi preparado de forma a permitir que um nmero maior de pessoas assistisse s palestras presencial e remotamente. Foram instaladas mquinas para transmisso e recepo das palestras a serem apresentadas por convidados da Universidade. Dentro de algumas sub-redes foram instalados tneis multicast, permitindo a qualquer pessoa locada em um computador nessas sub-redes assistir s palestras em seu PC. Nesse caso, a interao com o palestrante ocorreu atravs da Web, e no auditrio Central via videoconferncia. 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 abrangncia do sistema facilmente. O Laboratrio de Pesquisa em Redes de Alta Velocidade (PRAV), localizado no Centro de Cincias Exatas e Tecnolgicas, e a Produtora da TV Unisinos, localizada no Centro de Comunicaes, foram as duas equipes encarregadas da criao, superviso e manuteno desse sistema, ilustrado na figura a seguir. Foram escolhidas algumas sub-redes para a transmisso multicast, como, por exemplo, PRAV, Pascal, Turing e Helios. Cada sub-rede (com exceo do PRAV) possua aproximadamente 80 mquinas. As linhas partindo do mrouter e das antenas na figura a seguir demonstram o fluxo unidirecional de vdeo transmitido. A ligao entre os dois PCs atravs de SDR possibilitou que as pessoas localizadas no Auditrio Central fizessem perguntas ao vivo (videoconferncia). Finalmente, as linhas pontilhadas entre os PCs dos telespectadores e o PC do Auditrio Padre Werner representam conexes via chat, utilizadas para perguntas em texto. O atraso mdio observado entre a transmisso do vdeo e sua reproduo nos computadores cliente foi de aproximadamente 18 segundos, sendo regulvel no encoder. Tal atraso aceitvel para uma transmisso de vdeo unidirecional. Na videoconferncia, o atraso ficou em torno de 500 ms a 1 s, o que se julgou aceitvel para o objetivo proposto (idealmente, deveria estar abaixo de 100 ms).
A qualidade da transmisso foi considerada satisfatria, com som MP3 codificado em 32 kHz de taxa de amostragem, vdeo a 30 quadros por segundo na resoluo de 320x240 pontos, podendo ser visto em tela cheia com interpolao para suavizar a imagem. A largura de banda necessria foi de aproximadamente 750 Kbps, com o protocolo de compresso MPEG-4 v2; no houve impacto substancial nas redes locais, uma vez que a capacidade nas redes em questo era de no mnimo 10 Mbps. A figura a seguir ilustra uma das palestras 2 , quando apresentada em um dos PCs, e a interface com o usurio, 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, 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
Uso da imagem cedido por Carlos Eduardo Hilsdorf http://www.smagicas.com.br
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.
7 Estudo de caso2: Videoconferncia 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 videoconferncia, sendo que os principais foram o sdr (com VIC/RAT) e o CU-Seeme 3 . A figura a seguir ilustra uma videoconferncia utilizando sdr, VIC e RAT. Para fazer parte do Mbone, estabeleceu-se manualmente um tnel 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 tneis so necessrios pois nem todos os roteadores da Internet esto configurados para suportar multicast. Com o tnel ativado, bastava um cliente entrar no sdr para que aparecessem as sesses multicast que estavam sendo anunciadas no momento (vide figura a seguir). No caso, todos os participantes da videoconferncia escolheram a sesso Metropoa - entrem aqui!!!, que foi previamente criada numa mquina com FreeBSD na Unisinos.
vide http://www.whitepine.com
Ao selecionar a sesso da videoconferncia, escolhe-se o protocolo de compresso de vdeo (no caso, H.261, utilizado pelo VIC no endereo multicast 239.255.155.106 definido pela sesso). Similarmente, o protocolo de udio utilizado pelo RAT foi 8 kHz mono, no endereo multicast 239.255.6.35. Cada participante da videoconferncia efetua o join, e gradativamente eles vo se integrando sesso. A figura anterior apresenta a interface do VIC com 5 participantes, um na UFRGS, trs em locais diferentes da UNISINOS e um na PROCERGS.
8 Bibliografia
[CHI 96] [FAQ 98] [ITU 98] [ITU 98a] CHIARIGLIONE, Leonardo. Short MPEG-1 description. http://rtlab.kaist. ac.kr/~gunhan/MPEG1/mpeg1desc.html. FAQ. Frequently Asked Questions About MPEG Audio Layer 3. version 3.0, 1998. http://www.iis.fhg.de/amm/techinf/layer3/layer3 faq/index.html. ITU-T. Recommendation H.323 Packet-based Multimedia Communications Systems . Genebra. 1998. ITU-T. Recommendation H.225.0 - Call signalling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems. Genebra. 1998. ITU-T. Recommendation G728 anexo H - Coding of speech at 16 kbit/s using low-delay code excited linear prediction. Annex H: Variable bit rate LD-CELP operation mainly for DCME at rates less than 16 kbit/s. Genebra. 1997. ITU-T. Recommendation G.723 Speech coders: dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s. Genebra. 1996. ITU-T. Recommendation G.729 - Coding of speech at 8 kbit/s using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP). Genebra. 1996. ITU-T. Recommendation G.711 - Pulse Code Modulation (PCM) of voice frequencies. Genebra. 1993. ITU-T. Recommendation G.722 7 kHz audio-coding within 64 kbit/s. Genebra. 1993. ITU-T. Recommendation H.261 Video CODEC Audiovisual Services at p 64 kbits. Genebra. 1993. ITU-T. Recommendation G.728 - Coding of speech at 16 kbit/s using low-delay code excited linear prediction. Genebra. 1992.
[ITU 97]
[ITU 96] [ITU 96a]
[ITU 93] [ITU 93a] [ITU 93b] [ITU 92]
Multimdia em redes de computadores [MCG 99] [MOU 99] [MPE 99] [PAS 97a] [PAU 98] [PRI 99] [RFC 1700] [RFC 1889] [RFC 2543] [RFC 2327] [SCH 99] [SCH 99a]
[SHA 96] [SPU 00] [TAN 97] [THO 98]
MCGOWAN, John F. White Paper on Video Technologies for Mars Airplane. California: NAS A Ames Research Center, 1999. MOURA. Csar Olavo de M. Filho, OLIVEIRA, Mauro. Videoconferncia em Educao a Distncia. Cear: ETFCE. 1999. MPEG. MPEG Audio Web Page. 1999. http://www.tnt.unihannover. de/project/mpeg/audio. PASSMORE, David. Delayed Voice-over-IP. Business Communications Review. Dez, 1997. http://www.netreference.com/PublishedArchive/Articles/BCR/BCR.12.97.html PAUL, Sanjoy. Multicasting on the Internet and its applications. Kluwer Academic Publishers: Massachussets. 1998. 421p. PRIMER on the H.323 Series Standard - Em http://www.databeam.com/ h323/h323primer.html. 1999. REYNOLDS, J. POSTEL, J. Assigned Numbers. RFC 1700 (Standards Track). California: IETF. Oct, 1994. SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. RFC 1889 (Standards Track). California: IETF. Jan, 1996. HANDLEY, M. et al. SIP: Session Initiation Protocol . RFC 2543 (Standards Track). California: IETF. Mar, 1999. HANDLEY, M. JACOBSON, V. SDP: Session Description Protocol. RFC 2327 (Standards Track). California: IETF. Apr, 1998. SCHULZRINNE, H. Comparison of H.323 and SIP. 1999. Em http://www.cs.columbia.edu/~hgs/sip/h323-comparison.html. SCHULZRINNE, H. ROSENBERG, J. A Comparison of SIP and H.323 for Internet Telephony. 1999. Em http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.pdf. SHAPE of MPEG. DV Magazine . Vol 4 n. 12. 1996. Em http://livedv.com/Mag/Dec96/Contents/mpeg/mpeg.html. SPURGEON, Charles E. Ethernet, the definitive guide . Sebastopol: Oreilly. February, 2000. 500p. TANENBAUM, Andrew C. Redes de Computadores - 3a edio. Ed. Campus, Rio de Janeiro, 1997. 923p. THOM, D. PURNHAGEN, H. MPEG Audio FAQ Version 10. ISO/IEC JTC1/SC29/WG11 Audio subgroup. Seoul. Em http://www.tnt.unihannover.de/project/mpeg/audio/faq. 1998.

Downloads Telematica Com Dados 2 Leitura Adicional Multimidia

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Downloads Telematica Com Dados 2 Leitura Adicional Multimidia

Încărcat de

Drepturi de autor:

Formate disponibile

Transmisso multimdia em redes de computadores

Autor: Valter Roesler Universidade: UNISINOS

Data: Julho de 2001

Multimdia em redes de computadores

pg. 2 Valter Roesler

Multimdia em redes de computadores 7 8

pg. 3 Valter Roesler

Estudo de caso2: Videoconferncia multicast no Metropoa ................................................. 33 Bibliografia............................................................................................................................ 34

1 Transmisso multimdia em redes

Multimdia em redes de computadores

pg. 4 Valter Roesler

Multimdia em redes de computadores

pg. 5 Valter Roesler

1.4 Tabela comparativa

Multimdia em redes de computadores

pg. 6 Valter Roesler

2 Protocolos de tempo real para transmisses multimdia

Multimdia em redes de computadores

pg. 7 Valter Roesler

IPv4 / IPv6 Unicast ou multicast

2.1.1 Entidades RTP

Multimdia em redes de computadores

pg. 8 Valter Roesler

2.1.2 Cabealho RTP

2.1.3 Exemplo: conferncia de udio

Multimdia em redes de computadores

pg. 9 Valter Roesler

2.1.4 Exemplo: videoconferncia

Multimdia em redes de computadores

pg. 10 Valter Roesler

2.2.1 SR (Sender Report)

Multimdia em redes de computadores

pg. 11 Valter Roesler

2.2.2 RR (Receiver Report)

2.2.3 SDES (Source Description)

Multimdia em redes de computadores

pg. 12 Valter Roesler

2.2.6 Restries de tempo nos pacotes RTCP

3 Padres de multimdia em redes de computadores

pg. 13 Valter Roesler

Multimdia em redes de computadores

pg. 14 Valter Roesler

HUB Gatekeeper H.323 Gateway H.323

LAN com QoS

Multimdia em redes de computadores

pg. 15 Valter Roesler

Multimdia em redes de computadores

pg. 16 Valter Roesler

Multimdia em redes de computadores

pg. 17 Valter Roesler

udio e Vdeo multicast Descentralizado

udio e Vdeo unicast Centralizado

Multimdia em redes de computadores

pg. 18 Valter Roesler

3.1.5 Sinalizao no H.323

Multimdia em redes de computadores

pg. 19 Valter Roesler

3.1.6 Exemplo de conferncia H.323

3.1.6.1 Exemplos de Terminais H.323

3.1.6.2 Exemplos de Gatekeepers

3.1.6.3 Exemplos de Gateways

3.1.6.4 Exemplos de MCUs

Multimdia em redes de computadores