Академический Документы
Профессиональный Документы
Культура Документы
Engenharia de Computao
2
Este trabalho foi analisado e julgado adequado para a obteno do ttulo de Engenheiro de
Computao e aprovado em sua forma final pelo orientador.
________________________________
Prof. Dr. Nelson Lopes Duarte Filho
________________________________
Prof. Dra. Silvia Silva da Costa Botelho
________________________________
Prof. MSc. Ivete Martins Pinto
Banca Examinadora:
3
DEDICATRIA
Dedico este trabalho a todos os que acreditaram em mim e me apoiaram do incio ao fim.
Principalmente a minha querida famlia que sempre esteve do meu lado nos momentos bons e ruins.
Um agradecimento especial em memria a meu pai Carlos Henrique que sempre foi um
exemplo de sabedoria e tranqilidade. Serei feliz se um dia conseguir ser a metade do homem que
ele foi.
Minha me Maria da Graa, pela dedicao extrema quanto aos filhos. Possibilitando assim
todo o meu desenvolvimento como profissional e como pessoa.
Minha irm Raquel, pela ajuda que mesmo a distncia conseguiu transmitir. Sempre
dedicada aos estudos tornou-se para mim um exemplo a ser seguido.
Minha namorada Vanessa, por sempre estar do meu lado me trazendo paz e boa companhia
no desenrolar dos trabalhos que culminaram com esta monografia.
Graas a todos vocs, consegui ultrapassar mais uma barreira em minha vida. E por causa
de vocs que consigo sempre continuar neste caminho to bonito que a vida.
4
AGRADECIMENTOS
Agradeo ao meu orientador Prof. Dr. Nelson Lopes Duarte Filho por ter me ajudado
sempre que pde, mesmo com o pouco tempo que tem devido aos vrios projetos que desenvolve.
Tambm devo muito aos meus colegas de trabalho do NCC (Ncleo de Computao Cientfica) que
sempre procuraram manter um bom ambiente de trabalho e de pesquisa cientfica.
5
SUMRIO
Lista de Figuras..................................................................................................................................8
Lista de Tabelas................................................................................................................................10
Lista de Abreviaturas.......................................................................................................................11
1 INTRODUO.............................................................................................................................15
2 INFRAESTRUTURA DE COMUNICAO............................................................................20
2.1 Endereamento Multicast.............................................................................................................22
2.2 MBONE........................................................................................................................................23
2.4 UDP..............................................................................................................................................25
3 SREAMING...................................................................................................................................28
3.1 Codecs de Vdeo...........................................................................................................................28
3.2 Codecs de udio...........................................................................................................................30
3.3 Mtricas de QoS...........................................................................................................................33
5 ARQUITETURA...........................................................................................................................52
5.1 Mdulo de Configurao..............................................................................................................59
5.2 Mdulo Transmissor.....................................................................................................................61
5.3 Mdulo Receptor..........................................................................................................................65
6
7 TESTES E RESULTADOS..........................................................................................................76
8 CONCLUSO................................................................................................................................79
9 REFERNCIAS BIBLIOGRFICAS........................................................................................81
7
LISTA DE FIGURAS
Figura 1: IGMP...................................................................................................................................17
Figura 2: Transmisso Multimdia.....................................................................................................19
Figura 3: Multicast e Unicast.............................................................................................................21
Figura 4: Endereo Multicast.............................................................................................................22
Figura 5: Multicast Nvel 3 e Nvel 2.................................................................................................23
Figura 6: Multicast MBONE..............................................................................................................24
Figura 7: Datagrama UDP..................................................................................................................25
Figura 8: Datagrama IP......................................................................................................................26
Figura 9: Representao grfica de um sinal sonoro..........................................................................30
Figura 10: Jitter...................................................................................................................................33
Figura 11: Skew..................................................................................................................................33
Figura 12: Modelo ISO OSI...............................................................................................................34
Figura 13: Pilha de Protocolos RTP...................................................................................................35
Figura 14: Cabealho RTP.................................................................................................................36
Figura 15: Cabealho Fixo RTP.........................................................................................................36
Figura 16: Cabealho RTCP...............................................................................................................41
Figura 17: Pacote RTCP Composto...................................................................................................42
Figura 18: Pacote Receiver Report.....................................................................................................43
Figura 19: Pacote Sender Report........................................................................................................45
Figura 20: Item SDES........................................................................................................................46
Figura 21: Pacote SDES.....................................................................................................................47
Figura 22: Pacote BYE.......................................................................................................................47
Figura 23: Pacote APP........................................................................................................................48
Figura 24: Funcionamento do Servidor de Streaming........................................................................53
Figura 25: Localizao do Socket......................................................................................................54
Figura 26: Fragmentao de Pacotes RTP..........................................................................................55
Figura 27: Funcionamento da Aplicao Cliente...............................................................................56
Figura 28: Arquitetura Proposta.........................................................................................................57
Figura 29: Aplicao de Configurao...............................................................................................60
Figura 30: Transmissor FURGTV......................................................................................................61
Figura 31: Selecionando o arquivo atravs do javax.swing.JfileChooser..........................................62
8
Figura 32: Janela de Temporizao....................................................................................................62
Figura 33: Classe Transmissor...........................................................................................................63
Figura 34: Conexo via socket...........................................................................................................64
Figura 35: Janela de Status de Transmisso.......................................................................................65
Figura 36: Aba Sobre..........................................................................................................................65
Figura 37: Abstrao da API JMF......................................................................................................71
Figura 38: Transmisso JMF..............................................................................................................73
Figura 39: Recepo JMF...................................................................................................................74
Figura 40: Arquitetura JMF................................................................................................................75
Figura 41: Modelo de Eventos JMF...................................................................................................68
Figura 42: Diagrama de Classes do Modelo de Eventos JMF............................................................68
Figura 43: Tipos de DataSource.........................................................................................................70
Figura 44: Player FURGTV...............................................................................................................76
Figura 45: Tamanho dos Pacotes........................................................................................................77
Figura 46: Pacotes Recebidos pelo Primeiro Receptor......................................................................78
Figura 47: Pacotes Recebidos pelo Terceiro Receptor.......................................................................78
9
LISTA DE TABELAS
10
LISTA DE ABREVIATURAS
11
RTP Real-Time Transport Protocol
RTT Round-Trip Time
SDES Source Description
SDP Session Description Protocol
SNMP Simple Network Management Protocol
SIP Session Initiation Protocol
SSM Source Specific Multicast
TCP Transmission Control Protocol
TTL Time To Live
UDP User Datagram Protocol
URL Universal Resource Locator
VOD Video-On-Demand
Wi-Fi Wireless Fidelity
12
RESUMO
Um canal de Televiso pode ser disponibilizado atravs da Internet com capacidades plenas.
Para isto, a capacidade de streaming via Multicast deve ser implementada. A comunicao feita de
um transmissor para mltiplos receptores. Como o endereamento Multicast permite enviar pacotes
IP para um determinado grupo de usurios, estes so cadastrados previamente no grupo. Para entrar,
sair e se manter em grupos Multicast, as estaes utilizam o protocolo IGMP. A diferena do
Multicast para unicast e broadcast est no roteamento dos pacotes que so enviados do transmissor
para os receptores. Ele utiliza o maior nmero possvel de rotas coincidentes, economizando assim a
capacidade dos canais de comunicao.
Foram implementados dois mdulos em Java: servidor e cliente. Primeiramente, o aplicativo
servidor abre o arquivo de vdeo e udio que comea a ser transmitido via multicast pela rede. Aps
cria-se um loop que espera conexes via socket. Quando alguma requisio recebida, dispara-se
uma thread para adicionar o cliente em questo no grupo e controlar a permanncia dele atravs de
sesses. O cliente um Applet que roda embutido no servidor Tomcat. Ele ser disponibilizado
atravs de um link na pgina da FURG TV (www.furgtv.furg.br). Desta maneira, ser
disponibilizado o canal de televiso da Fundao Universidade Federal do Rio grande, via
streaming, na Internet.
13
ABSTRACT
A television channel can be set over the Internet with full capacity. For this, the capacity for
streaming with Multicast must be implemented. The communication is done from a transmitter to
multiple receivers. As the Multicast Protocols allows sending IP packets to a specific group of
users, they are registered in advance in a group. To enter, leave and remain in Multicast groups,
stations use the protocol IGMP. The difference of Multicast for unicast and broadcast is in the
routing of packages that are sent to the receivers from the transmiter. Multicast Protocols use the
possible greater number of coincident parcial routes.
Two modules were implemented in java: server and client. Initially, the server application
open the file and begin to transmit video and audio multicast via the network. Then it creates a loop
waiting connections via socket. When a request is received, it fired a thread to add the customer in
question in the group and control its permanence in sessions. The client is an Applet that runs
embedded in a Tomcat server. It can be downloaded from a link on the page of FURG TV
(www.furgtv.furg.br). Thus, the channel of the Fundao Universidade Federal do Rio Grande has
been available with the capacities of streaming multimidia data over the Internet, through multicast.
14
1 INTRODUO
Afora essas, a transmisso de contedo multimdia ao vivo est crescendo cada vez mais
devido popularizao dos links de banda larga. Esse tipo de transmisso est se tornando comum
aos usurios na Internet [1]. Com a televiso na Internet, o usurio solicita apenas os programas de
seu interesse e no precisa ser escravo da programao pr-definida pelas estaes corporativas. A
15
maioria das televises disponibilizados na Internet, hoje em dia, consiste em um decodificador de
sinal capturando sinal de TV e retransmitindo-o para a web atravs de um servidor de streaming.
O modelo utilizado atualmente pelas TVs abertas sofrer uma mudana bastante relevante,
devido s prprias limitaes. A forma de transio provavelmente ser consolidada como digital,
substituindo a atual que analgica. Isto se deve a alguns fatores como melhor definio e maior
nmero de canais disponibilizados. Onde se captava um nico programa por canal, podero existir
vrios (sistema de mltiplos programas). Existem ainda outras vantagens que no sero abordadas
neste trabalho. Como exemplos podem-se citar o T-commerce, o comrcio eletrnico pela TV, e o
T-Banking, servios bancrios tambm pelo aparelho de TV. Isto sem falar na TV interativa que
uma das reas de maior atratividade e de progresso rpido neste contexto.
Uma forma de disponibilizar um canal de TV atravs da Internet com capacidades plenas
atravs da utilizao de dois mdulos, em Java por exemplo, atravs dos quais feito o envio de
dados de um transmissor para mltiplos receptores. Para economizar recursos de comunicao
pode-se utilizar endereamento Multicast, o qual permite o envio de pacotes IP para um
determinado grupo de usurios que previamente se cadastraram neste (identificado por um endereo
IP classe D, ou seja, entre 224.0.0.0 at 239.255.255.255). Para entrar, sair e se manter em grupos
Multicast, as estaes devem utilizar o protocolo IGMP [16]. A diferena entre o Multicast e o
unicast reside no modo como feito o roteamento dos pacotes. Enquanto no unicast a comunicao
feita ponto a ponto, no multicast alguns protocolos de roteamento so utilizados para fazer isso,
como, por exemplo, o DVMRP, o MOSPF e o PIM. Eles usados para troca de informaes entre os
roteadores e definio de quais rotas os pacotes devero seguir e a comunicao feita de um para
muitos.
necessria a manuteno dos grupos multicast. Para isso, utilizado o protocolo IGMP em
hosts IPv4. Esse tipo de gerenciamento feito atravs da notificao aos roteadores vizinhos
quando um host entra ou sai de algum grupo. J em hosts IPv6, o IGMP implementado atravs do
ICMPv6. Existem mensagens caractersticas deste protocolo como, por exemplo, a mensagem
IGMP Host Membership Query que enviada por roteadores, quando querem descobrir quais hosts
esto em seu grupo, para o endereo 224.0.0.1 com TTL igual a 1. Outra mensagem caracterstica
a Host Membership Report. Esta enviada pelos hosts, que participam de algum grupo multicast,
para os roteadores vizinhos. Mensagens peridicas IGMP devem ser enviadas para que seja mantida
a consistncia dos grupos multicast.
16
Figura 1: IGMP
O diagrama na Figura 1 representa os estados dos membros durante uma sesso multicast do
protocolo IGMP, assim como os eventos que causam as transies entre os estados. Os estados
possveis dos membros esto representados pelos crculos cinzas com bordas pretas. A comear
pelo estado No-membro, esse o estado inicial para todos os grupos em todas as interfaces de
rede. Um membro tambm pode pertencer a um grupo numa interface e ter um temporizador de
report executando (membro com temporizador). Alm destes, existe o estado sem temporizador. Os
eventos que causam transies de estado, e podem ocorrer em qualquer das interfaces de rede nele
existentes so:
17
Um dos grandes desafios atuais da Internet o acesso s transmisses multimdia, mesmo na
presena de receptores localizados em redes heterogneas, com diferentes larguras de banda,
velocidade de enlace, condies de acesso e capacidade de processamento. Para resolver esse
problema deve ser implementado algum tipo de controle de banda para disponibilizar a transmisso
igualitria do vdeo entre os receptores. Existem dois tipos de abordagem de controle de
congestionamento: SSM [3] e ALM [4]. A abordagem SSM deve ser escolhida quando apenas uma
fonte pode enviar dados Multicast. J na abordagem ALM, o Multicast implementado na camada
de aplicao para que redes com diferentes topologias possam compartilhar da mesma transmisso
com a mesma qualidade de imagem, o que normalmente gera problemas na distribuio de pacotes.
Alm disso, os protocolos ALM implementam as facilidades de Multicast nos end-hosts ao
invs de nos roteadores da rede. Os dados so replicados nos end-hosts e no dentro da rede como
feito com IP Multicast. O grande problema desta abordagem a utilizao, normalmente,
inadequada da banda. Existem trs protocolos ALM bastante conhecidos: Narada [5], Yoid [6] e
NICE [7].
No trabalho aqui descrito, foram construdos dois mdulos: um cliente e um servidor de
streaming. O sinal multimdia codificado e transmitido pelo servidor para um grupo multicast de
clientes. O sinal multimdia tanto pode ser obtido por uma filmadora ou quanto pode ser lido em um
arquivo, sendo que o transmissor deve encapsular os pacotes utilizando protocolo RTP [8].
A transmisso via Multicast compe uma soluo alternativa ao excesso de trfego
redundante de pacotes que ocorre nas transmisses unicast e broadcast. Multicasting , pois, um
mtodo ou tcnica de transmisso de um pacote de dados para mltiplos destinos ao mesmo tempo,
com otimizao dos recursos de comunicao. Durante este tipo de transmisso, o servidor envia os
pacotes de uma vez, dependendo dos receptores a captura da transmisso e, a partir disto, sua
reproduo. Por exemplo, no caso de um filme a ser enviado por um servidor remoto para vrios
clientes, Multicast a soluo ideal pois diminui bastante o trfego j que no envia pacotes para
cada um dos participantes e sim para todo o grupo de uma s vez. Alm disso, importante
ressaltar que tambm existe o padro H.323 que prov uma base tecnolgica para transmisso de
dados, udio e vdeo [9].
O funcionamento de uma transmisso multimdia bastante simples de compreender: o sinal
gerado inicialmente digitalizado para ento passar por um processo de compresso, o que diminui
a quantidade de dados a ser transmitido, tornando vivel o envio dos dados pela rede. Esta insere
alguns atrasos no sistema, como pode ser visto na Figura 2. No receptor, os pacotes so
reordenados, descomprimidos e reconvertidos ao estado original, normalmente com perdas
inseridas no processo de compresso.
18
Figura 2: Transmisso Multimdia
As mdias, normalmente, so grandes demais para serem enviados diretamente sem nenhum
tipo de tratamento porque geram atrasos demasiados, congestionando a rede envolvida na
comunicao. A soluo para este problema a codificao e decodificao das mdias. Para isto
so utilizados algoritmos de codec que definem o formato no qual sero codificadas e comprimidas
as mdias. Alm de definir como sero decodificadas as informaes no receptor. Tendo isto em
considerao, a escolha do codec crucial para que a transmisso seja eficiente. Tanto a qualidade
de transmisso quanto a quantidade de banda consumida depende do tipo de codec escolhido. Alm
disso, importante ressaltar que tanto na transmisso quanto na recepo devem ser utilizados o
mesmo tipo de codec.
Para que uma comunicao seja considerada em tempo-real, os telespectadores devem ter a
percepo de que esto vendo as imagens no mesmo momento em que esto sendo filmadas ou
lidas de um arquivo. Mas sempre existir algum tipo de atraso ou perda em relao ao que est
sendo produzido. Para minimizar este problema, deve ser adotada alguma alternativa que impea o
usurio de perceber esses atrasos ou perdas. Grandes atrasos prejudicam a caracterstica de tempo
real da comunicao e atrasos variveis prejudicam a continuidade da reproduo da mdia. Muitas
vezes, as comunicaes multimdia em tempo real so consideradas CBR, o que indica que devem
manter uma taxa de bit constante durante a transmisso das mdias. Esta caracterstica deve ser
mantida, mas a manuteno no pode exigir recursos em demasia da rede, pois conseqentemente
ir prejudicar a transmisso.
O funcionamento da nossa arquitetura bastante simples: o aplicativo servidor abre o
arquivo de vdeo e comea a transmitir via multicast pela rede. Aps criado um loop que espera
conexes via socket. Quando alguma requisio recebida, dispara-se uma thread para adicionar o
cliente em questo no grupo e fazer o controle da permanncia nas sesses. O cliente um Applet
que roda embutido no servidor Tomcat. Ele ser disponibilizado atravs de um link na pgina da
FURG TV (www.furgtv.furg.br). Desta maneira, ser disponibilizado o canal de televiso da
Universidade Fundao Universidade Federal do Rio grande via streaming na Internet.
19
2 INFRAESTRUTURA DE COMUNICAO
Existem trs tipos de endereamento que podem ser adotados no protocolo IPv4 para
encaminhar pacotes: unicast, multicast e broadcast. No tipo unicast, a comunicao d-se de um
para um, ou seja, de uma entidade origem para outra destino. No multicast, um para vrios. J no
broadcast um para todos. O endereamento multicast permite enviar pacotes IP para um
determinado grupo de interfaces de rede que estejam previamente cadastradas no grupo. Para entrar,
sair e se manter em grupos multicast, as estaes devem utilizar o protocolo IGMP, que ser
mostrado em maiores detalhes adiante.
Em termos de qualidade de servio, uma transmisso multicast tratada da mesma forma
que unicast, ou seja, possui as mesmas caractersticas de melhor esforo do IP unicast, sofrendo
as mesmas polticas de controle de acesso e confirmao de trfego. Como uma transmisso
multicast possui o mesmo cabealho IP do unicast, os mtodos de garantia de qualidade de servio
so os mesmos e ambos podem usar diffserv, RSVP [17], MPLS, e assim por diante.
No roteamento de pacotes multicast, o roteador deve saber em quais portas existem usurios
cadastrados em grupos. Com isso ele replica os pacotes por todos os caminhos por onde existirem
receptores. Os protocolos de roteamento multicast so os seguintes: DVMRP, o MOSPF e o PIM.
Atravs destes protocolos, os roteadores conversam entre si e descobrem quais rotas devem ser
usadas para encaminhar os pacotes.
O grande ponto a favor do multicast que ele permite uma distribuio simultnea para um
grande nmero de clientes, sem exigir muito dos recursos do servidor e sem gerar muito trfego na
rede. Assim, esta tecnologia facilita a existncia de uma nova gerao de aplicaes um para
muitos em rede, como trfego de vdeo, udio, trabalho colaborativo, transmisso de arquivos
simultaneamente para muitos usurios, e assim por diante. As novas aplicaes podem ou no
exigir confiabilidade, entretanto, para transmisses confiveis existe uma complexidade maior para
controlar fluxo e o feedback dos receptores.
Em resumo:
Trfego unicast: para cada cliente, o transmissor deve gerar um fluxo de pacotes IP
unicast.
20
Trfego broadcast: a rede sobrecarregada pois a mesma mensagem enviada pelo
transmissor para todos os receptores ao mesmo tempo, inundando assim a rede com
pacotes replicados.
21
2.1 Endereamento Multicast
Cada grupo multicast reconhecido como um endereo multicast que tem caractersticas
singulares que o diferenciam de um endereo IP comum. Isto se torna necessrio porque pacotes
enviados a eles no sero enviados a apenas um host, e sim, a vrios destinos ao mesmo tempo.
Desta forma, uma faixa de endereos so reservados para endereamento multicast, como acima
detalhado.
Numa rede local, existe um conjunto de endereos MAC (Mdium Access Control) especial
destinado a multicast. Assim, no protocolo de nvel 2, o host do cliente sabe se a mensagem
destinada a ele ou no. Esse conjunto de nmeros foi reservado pelo IANA e compreende todos os
endereos de 01-00-5E-00-00-00 a 01-00-5E-7F-FF-FF, conforme a Figura 5 (somente 23 bits,
comparado aos 28 do endereo multicast).
22
Existe um processo de mapeamento entre o IP multicast e o Ethernet multicast, que
simplesmente a substituio dos 23 bits menos significativos do Ethernet pelos 23 bits menos
significativos do IP. Assim, quando uma estao cliente se cadastra em determinado grupo
multicast, como, por exemplo, o 238.173.117.105 (EE.AD.75.69), automaticamente o driver da
placa de rede passa a receber mensagens MAC que cheguem no endereo 01-00-5E-2D-75-69,
como mostra a Figura 7. J o transmissor, que criou o grupo 238.173.117.105, quando enviar a
mensagem para a rede, vai encaminh-la ao endereo 01-00-5E-2D-75-69 do nvel 2, como
explicado anteriormente.
2.2 MBONE
23
O MBONE ou backbone multicast da Internet nada mais do que um conjunto de roteadores
interligados a fim de distribuir trfego multicast. Ou seja, uma rede virtual de hosts conectados pela
Internet para comunicao estritamente multicast. Seu tempo de vida tem seus dias contados, pois
quando todos os roteadores da Internet suportarem protocolos de roteamento multicast, no ser
mais necessrio o uso do MBONE.
Desde de 1992, o MBONE encontra-se em funcionamento. Ele foi originado de um esforo
realizado pela IETF para dar suporte de udio e vdeo atravs de multicast para reunies distncia.
A ttulo de curiosidade, certa vez, um show dos Rolling Stones foi transmitido pelo MBONE, como
tambm partes do Festival de Cinema de Cannes [10]. Isto revela sua capacidade de utilizao real.
Atualmente, vrios protocolos esto sendo desenvolvidos sobre o MBONE. Atravs dele, pacotes
so enviados via unicast pela Internet.
Caso os roteadores suportassem roteamento multicast, os tneis (linhas de comunicao
bidirecionais entre hosts) seriam inteis, pois o roteador faria o papel do mrouter. Alm disso, a
manuteno dos tneis um processo bem trabalhoso, ficando bem mais fcil o uso no roteador.
Entretanto, o roteador vai ser afetado no desempenho da entrega de pacotes porque vai ter mais uma
tarefa por fazer.
Os roteadores do MBONE so chamados de mrouters e suportam endereamento multicast.
Todo o funcionamento baseado em tunneling, no qual os pacotes so enviados para as subredes
MBONE por mrouters que no suportam IP Multicast. A estrutura do MBONE est representada na
Figura 6.
24
Um tnel necessita ser configurado em ambos mrouters a fim de que possa ser usado. O
arquivo /etc/mrouted.conf deve ser configurado com os seguintes parmetros: IPs dos tneis,
Threshold (define o valor mnimo de TTL que um pacote multicast deve ter para que seja
encaminhado por determinada interface ou tnel), Metric (define o custo associado a esse tnel) e
Rate_limit (largura de banda, em Kbit/s, do fluxo multicast que passa pelo mrouter).
Em geral, todos os roteadores multicast conectados a um determinado tnel devem usar a
mesma mtrica e threshold para este tnel.
2.3 UDP
Uma aplicao que necessita da comunicao via Internet deve utilizar os protocolos de
transporte como pontos de acesso. Para que esta comunicao seja implementvel, cada ponto de
acesso representado por um endereo de transporte denominada porta. O conceito de porta
tambm utilizado para tornar possvel a multiplexao de vrias comunicaes do nvel de
aplicao de forma independente e simultnea. Os protocolos de transporte denominam-se UDP e
TCP. Na prxima seo ser explicado como funciona o protocolo UDP e porque ele foi o
escolhido para implementar a comunicao proposta neste trabalho.
UDP um protocolo de transporte no qual no existe a verificao do recebimento dos
dados pelo destino, no possui servio de reenvio e nenhum tipo de ordenamento de mensagens.
Sendo assim, as mensagens recebidas so agrupadas da maneira como chegam, sem nenhuma
verificao da ordem de chegada. Alm disso, no existe nenhuma verificao de integridade das
mesmas. Essas caractersticas podem parecer prejudiciais, mas so elas que fazem com que o
protocolo UDP seja muito rpido. Por conseqncia, tornou-se um protocolo extremamente simples
que oferece um servio de pacotes sem conexo.
O funcionamento baseado em portas de comunicao. So definidas portas de origem e de
destino e a comunicao feita atravs do envio de datagramas UDP. O formato dos datagramas
encontra-se na Figura 7.
25
No datagrama UDP, so definidas a porta de origem e a de destino (ambas com 15 bits).
Alm disso, existe um campo de tamanho (15 bits) que descreve quantos bytes o pacote ter, um
campo de checksum (15 bits) que opcional e faz uma soma verificadora para proporcionar a
verificao de erros. Para que seja enviado, o datagrama UDP encapsulado num pacote IP, como
ilustrado na Figura 8.
Figura 8: Datagrama IP
Existem alguns protocolos do nvel de aplicao que fazem uso do protocolo UDP para as
suas implementaes. Um exemplo o protocolo DHCP que, entre outras coisas, utilizado para
distribuio automtica de endereos IPs. Outro protocolo que tambm o utiliza o DNS, adotado
para traduzir nomes de hosts em endereos IPs. Alm desses, o SNMP tambm utiliza o UDP.
Atravs dele, por exemplo, possvel configurar dispositivos como switches ou roteadores.
Possibilitando que enviem informaes de status a outros elementos da rede.
Tendo em vista o que foi explicado sobre o protocolo UDP, fica claro que ele usado
quando se quer implementar uma comunicao em tempo real porque no existe muita sobrecarga
na rede e por causa da caracterstica de poder mandar um pacote para vrios destinos, o que o torna
diferente do outro protocolo de transporte mais popular, o TCP (orientado a conexes). Sendo no
orientado a conexo, pacotes de confirmao de recebimento, por exemplo, no precisam ser
enviados. Ou seja, existem vrios pacotes apenas de verificao que no so enviados quando se
utiliza UDP, pois esta no orientada a conexes. Portanto UDP muito mais rpida que TCP.
Mesmo sendo menos segura, UDP muito mais indicada para transmisses multimdia porque o
que se quer neste tipo de transmisso velocidade.
26
3 STREAMING
H algum tempo atrs, executar um arquivo de vdeo, ou seja, assistir um pequeno clip na
Internet significava um longo perodo de download. Ento, levantou-se a possibilidade de
reproduzir o vdeo desejado antes mesmo que todo o arquivo fosse gravado localmente. Assim,
nasceu a tecnologia de Streaming, que um misto de tcnicas de compresso e armazenamento em
memria temporria (buffering). Ela permite a transmisso de vdeo em tempo real atravs da
Internet.
Na tecnologia streaming, a imagem e som comeam a ser reproduzidos antes mesmo que o
arquivo que os contm seja copiado totalmente para o computador local. Isto reduz a espera inicial a
poucos segundos, um tempo relativamente razovel para o contexto atual da Internet.
Nas transmisses de streaming, a ordem de chegada dos pacotes contendo unidades de um
arquivo fundamental, pois a visualizao ou execuo do contedo do arquivo se inicia antes do
trmino da transmisso, como foi mencionado. Por outro lado, alguns pacotes podem ser
descartados, sendo que em algum nvel razovel de descartes isso se torna praticamente
imperceptvel ao olho humano.
Alm disso, esta tecnologia permite ainda enviar o vdeo de uma forma que ele no pode ser
copiado. Para rodar um vdeo clip em streaming, normalmente necessria a presena de um plug-
in (software especial que trabalha em conjunto com o navegador da Web), o qual manipula o
download e a descompresso do arquivo.
Na compresso do vdeo, a imagem particionada em uma seqncia de quadros
denominados frames. Cada frame quebrado em partes estticas ou dinmicas. Essas partes,
tambm chamadas de objetos, possuem contedo parado ou mvel, respectivamente. Um software
de compresso age sobre estes objetos, atualizando aqueles com contedo mvel e reciclando
aqueles com contedo esttico. Desta forma, se reduz o tamanho e o tempo de transmisso de um
arquivo.
O armazenamento em memria temporria ou bufferizao trata da utilizao de um espao
alocado em memria que visa manter um ritmo constante na reproduo das imagens. Caso a
conexo fique demasiadamente lenta, o buffer fica encarregado de suprir os atrasos e lacunas na
transmisso, esvaziando seu reservatrio de frames.
Um outro aspecto a ser destacado diz respeito aos diferentes tipos de fluxos multimdia. A
Tabela 1 [21], exemplifica alguns desses tipos e as taxas de dados e de quadro por amostragem, por
eles tipicamente utilizadas.
27
Tipo de Fluxo Taxa de Dados Tamanho Freqncia
Vdeo de TV 120 Mbps At 640x480 com 16 bits por pixel 24 frames/s
Vdeo de TV MPEG-1 1,5 Mbps Varivel 24 frames/s
Vdeo HDTV 1000-3000 Mbps At 1920x1080 com 24 bpp 24-60 frames/s
Vdeo HDTV MPEG-2 10-30 Mbps Varivel 24-60 frames/s
Tabela 1: Caractersticas dos fluxos multimdia tpicos
Para que um sinal de vdeo possa ser transmitido atravs de uma rede de comunicao
digital torna-se necessria a sua adequada codificao/decodificao, o que realizada atravs de
codecs. Os codecs de vdeo so utilizados para codificar sinais de vdeo que tanto pode vir de uma
cmera conectada ao computador como de um arquivo de vdeo pr-armazenado. Pela mesma
lgica, o receptor decodifica o vdeo com o mesmo codec para ento apresent-lo. A apresentao
do vdeo recebido pode ser feita tanto em um display apropriado quanto pode ser armazenado em
um arquivo. Como um arquivo de vdeo normalmente bastante grande, ele deve ser divido em
pacotes para que possa ser transmitido sem demora.
Um vdeo nada mais do que uma seqncia de imagens que so exibidas rapidamente,
causando a impresso de movimento. Tendo isto em mente, uma das medidas que devem ser
escolhidas pelo codec o nmero de imagens (quadros) por unidade de tempo que sero enviados
pelo transmissor aos receptores. Esta medida normalmente dada em Frames Per Second (fps). Na
televiso convencional utilizado 30fps. Numa comunicao em tempo real via Internet, esta
medida para ser aceitvel deve estar entre 15 e 30fps. Um codec pode ser considerado melhor que
outro caso consiga enviar mais quadros por segundo, proporcionando assim uma melhor qualidade
na apresentao.
Afora, a resoluo do vdeo adotada pelo codec tambm influi na banda de transmisso.
Algumas resolues especiais foram especificadas para multimdia em tempo real com vistas
manuteno da qualidade e da temporalidade natural do vdeo. Estes padres esto descritos na
Tabela 2.
28
Formato Significado Resoluo
SQCIF Sub-quarter Common Intermediate Format 128 x 96 pixels
QCIF Quarter Common Intermediate Format 176 x 144 pixels
CIF Common Intermediate Format 352 x 288 pixels
4CIF 4 x Common Intermediate Format 704 x 576 pixels
16CIF 16 x Common Intermediate Format 1048 x 1152 pixels
Tabela 2: Tipos de resoluo de vdeo
O vdeo, depois de carregado pelo servidor, deve ser divido em pacotes que iro passar por
um processo de compresso, o que diminui seu tamanho, tornando assim vivel a transmisso pela
rede. No receptor, os pacotes so reordenados, descomprimidos e reconvertidos ao estado original,
normalmente com algumas perdas decorrentes do processo de compresso.
Alguns padres de vdeo possibilitam a interao entre solues de diferentes fabricantes de
forma transparente. As especificaes de maior importncia so apresentadas na Tabela 3, para
diferentes tipos de redes de comunicao.
O padro H.323 a especificao indicada pelo IEEE para transmisses de udio e vdeo
sobre a Internet. Permite tambm que produtos de multimdia e aplicaes de fabricantes diferentes
possam interoperar de forma eficiente e usurios possam se comunicar de forma adaptada
velocidade da rede. Ele um padro para controle de conferncias de vdeo e voz sobre redes
TCP/IP da srie H do ITU-T, um subgrupo do ITU [12] que responsvel por padronizaes. A
ttulo de curiosidade, alguns padres do ITU, associados aos assuntos aqui tratados, so
apresentados na Tabela 4.
29
Padres Descrio
H.100 a H.199 Sistemas de telefonia visual
H.220 a H.229 Transmisso, multiplexao e sincronizao
H.230 a H.239 Caractersticas bsicas dos sistemas multimdia
H.240 a H.259 Controle de procedimentos de comunicao
H.260 a H.279 Codecs de vdeo
H.280 a H.299 Servios de suporte as comunicaes multimdia
H.300 a H.399 Servios audiovisuais
H.450 a H.499 Servios de suporte as comunicaes multimdia
Tabela 4: Padres do ITU
O som, para que possa ser transmitido, deve ser transformado em sinais eltricos que por sua
vez devem ser digitalizados. O microfone transforma as ondas sonoras em tenses eltricas com
amplitudes altas e baixas, correspondendo a sons de maior e menor intensidade. Da mesma maneira,
e com variaes de freqncia mais rpidas ou mais lentas, correspondendo a sons mais agudos e
mais graves. A Figura 9 apresenta a representao grfica de um sinal sonoro, depois de convertido
em tenses eltricas atravs do microfone.
Vrias caractersticas podem ser implementadas atravs dos codecs de udio. Um exemplo
a supresso de silncio que faz com que no seja consumido quase nenhum recurso durante a
ausncia de som em uma comunicao. Apenas transmitido o rudo no momento de silncio. E
isto acontece para que a outra pessoa na linha de comunicao no pense que foi abandonada pelo
outro falante.
30
Outro fator crucial na escolha do codec o valor do MOS, uma medida de qualidade que se
quer implementar para a aplicao. Tal valor pode ser escolhido de modo subjetivo pelo usurio,
dependendo da qualidade percebida pelo mesmo durante a comunicao. Para isto so associados
valores entre zero e um percepo subjetiva da qualidade do som, segundo a Tabela 5.
Normalmente so utilizados codecs com MOS acima de 3,5.
Valores de MOS associados a alguns tipos de codec de udio so mostrados Tabela 6 [21].
Por tratar-se de um codec de domnio pblico e larga utilizao, destaca-se aqui o codec
G.711. Ele foi o precursor nas comunicaes de tempo real na Internet. Baseado no sistema
telefnico convencional, ele obrigatrio na arquitetura H.323. de fcil implementao e oferece
uma boa qualidade de mdia.
O codec G. 711 utiliza o algoritmo PCM para codificar udio e representa cada sinal
amostrado atravs de oito bits, gerando uma stream de udio de 8Kbps. Por se tratar de um
algoritmo leve, sua execuo bastante rpida. Sendo assim, possui uma tima qualidade de
transmisso em redes com pouca perda de pacotes, boa largura de banda e atrasos constantes e
reduzidos. Apesar de estar implementado em quase todas as aplicaes atuais de multimdia, ele
pouco utilizado devido ao atual cenrio da Internet.
31
3.3 Mtricas de QoS
Redes que seguem as diretrizes de transmisso pela regra do melhor esforo, caso das redes IP,
fazem com que os pacotes que as percorrem sejam transmitidos hop a hop na maior velocidade
possvel, independente das aplicaes a que pertenam. Nelas, os pacotes devem chegar aos seus
destinos o mais rpido possvel, mesmo que para isso necessitem utilizar rotas alternativas devido
ao congestionamento da rede. Devem-se, pois, em alguma camada superior dessas redes, introduzir
mecanismos de controle capazes de atribuir prioridades aos fluxos gerados pelas diferentes
aplicaes que se encontrem em execuo corrente.
Considerando a caracterstica iscrona dos pacotes tratados pela aplicao multimdia, foco
desta monografia, e conseqentemente as severas restries a que as entidades que transportam
esses pacotes devem ser submetidas, destacam-se a seguir, para que se possa melhor entender o
funcionamento da proposta, os principais parmetros para controle de qualidade dos fluxos de
dados na Internet.
Latncia
Latncia o tempo que um pacote leva da origem ao destino. Caso esse atraso seja muito
grande, prejudica a troca de dados atravs da rede. 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 (atraso no meio fsico, atrasos de
processamento em roteadores e atraso devido ao tempo de espera nas filas de transmisso
dos equipamentos intermedirios).
Atraso de codificao e decodificao: tempo de processamento na mquina origem e na
mquina destino para codificao e decodificao de sinais. O atraso depende do padro
escolhido.
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.
32
Jitter
Jitter a variao estatstica do retardo entre as chegadas dos pacotes. Deve ser inferior a
50ms para que as comunicaes multimdia no fiquem comprometidam. Para o clculo do jitter
devem-se considerar o atraso do processamento dos codecs e o atraso na transmisso dos pacotes. O
conceito de jitter e latncia so ilustrados na Figura 10.
A soluo para o jitter criar um buffer no destino com tamanho dependente do valor do
mesmo, o que conseqentemente reduz o atraso na transmisso. O buffer serve como uma reserva
para manter a taxa de entrega constante no receptor.
Skew
33
4 TRANSMISSO EM TEMPO REAL
Para transportar dados em tempo real, como o caso da aplicao multimdia tratada no
presente trabalho, so necessrios protocolos que tratem aspectos de sincronismo e de
temporizao. A seguir abordam-se os protocolos RTP e RTCP, que so capazes de dar suporte a
esses tipos de necessidades.
4.1 RTP
34
O RTP utiliza o RTCP, adiante descrito, para monitorar a qualidade de servio e repassar
informaes sobre os participantes de uma sesso em andamento.
Em termos do modelo OSI [10], como foi dito anteriormente, o RTP se situa entre a camada
de aplicao e a de transporte, coforme melhor mostrado na Figura 13. O IP pode ser tanto unicast
como multicast, e o protocolo Ethernet utilizado na figura apenas um exemplo. No caso aqui
tratado, utiliza-se multicast como modo de endereamento e os pacotes RTP so encapsulados em
pacotes UDP, para transmisso via rede.
Uma sesso RTP caracterizada por uma mdia por sesso apenas, podendo ser de udio ou
de vdeo. Tambm so utilizados um conjunto nico de IP, porta e SSRC para cada participante.
Mesmo havendo as sesses distintas, a sincronizao entre udio e vdeo pode ser atingida atravs
do feedback de tempo proporcionado pelos pacotes RTCP, que sero explanados posteriormente.
O pacote RTP composto por um cabealho fixo, uma lista de fontes de contribuio
opcional, um cabealho de extenso opcional e um campo de payload. Esta estrutura pode ser vista
na Figura 14 e o cabealho fixo ser detalhado na prxima subseo. A lista de contribuio ou
CSRC (utilizado para mixers) contm 32 bits, assim tambm como o campo de payload (representa
o contedo do pacote) que tanto pode ser de udio quanto de vdeo e codificado por um codec
(Ex: G.711 ou H.263).
35
Figura 14: Cabealho RTP
Os primeiros doze bytes esto presentes em todos os pacotes RTP, enquanto que a lista dos
identificadores CSRC est presente somente quando inserido por um multiplexador. Os campos tm
o seguinte significado:
Padding (P): Indica a opo de preenchimento do pacote RTP. Se este bit for 1, o pacote
contm um ou mais bytes (octetos) de preenchimento no final do pacote e utilizado para
criptografia. J quando ele setado para 0, no existe nenhum dado til e os dados
complementares devem ser ignorados (1 bit);
Extension (X): Se este bit estiver setado para 1, indica que o cabealho ter uma extenso
com o mesmo nmero de bytes (1 bit). Caso contrrio, o campo de extenso deve ser
desconsiderado;
CSRC Counter(CC): Indica o nmero de identificadores CSRC que seguem o campo fixo do
cabealho (4 bits). E til na unio de vrias fontes de udio em um nico fluxo de dados;
Marker (M): Permite que eventos significativos, tal como limites de quadro, sejam marcados
no fluxo de pacotes (1 bit);
36
Payload Type(PT): Identifica o formato da carga til do pacote, de forma que possa ser
interpretado pela aplicao, ou seja, o tipo de codec utilizado (7 bits);
CSRC: identifica as fontes que contriburam para a carga de dados existente no pacote RTP
e opcional (32 bits). Identifica cada transmissor, durante uma mltipla transmisso. Vrios
participantes de uma sesso RTP podem contribuir para criar pacotes. Quando setado, este
campo adicionado lista de participantes conhecidos.
O cabealho de extenso opcional e contm 32 bits. composto pelo ID do perfil (16 bits),
comprimento (16 bits) e informaes extras de extenso. O perfil RTP estabelece mapeamentos
entre os codecs e os valores do campo PT (Payload Type). Este mapeamento feito com base em
valores constantes de PT que indicam os codecs correspondentes. A Tabela 7 apresenta os codecs
mais conhecidos e utilizados atualmente.
37
PT Formato Especificao
0 PCMU (udio) RFC 1890
3 GSM (udio) RFC 1890
8 PCMA (udio) RFC 1890
14 MPA (udio) RFC 2250
26 JPEG (vdeo) RFC 2435
31 H.261 (vdeo) RFC 2032
32 MPEG I e II (vdeo) RFC 2250
34 H.263 (vdeo) RFC 2190
Tabela 7: RFCs do Perfil RTP
Mesmo sendo a divulgao do tipo de payload esttica (tambm pode ser dinmica),
necessrio que seja feita a descrio da sesso para a aplicao, para que esta possa saber qual o
tipo de payload utilizado. Um dos protocolos mais utilizados para descrio de sesso o SDP ou
Session Description Protocol. Atravs desse protocolo os participantes de uma sesso multimdia
podem padronizar o codec utilizado na comunicao. Alm disso, podem trocar informaes entre
si sobre suas capacidades de processamento de mdia. O SDP faz uso de uma codificao textual
que composta por campos de controle nos quais podem ser descritos o nmero da verso do
protocolo, o identificador de incio de comunicao, nome da sesso, descries da mdia, tempo de
ncio e fim de sesso e informaes de controle. Para isso, seus dados so encapsulados em
mensagens SIP. Mesmo que seja comum o uso de SDP em sesses RTP, seu uso no especificado
como padro.
38
sesso para que possam ser adotados vrios formatos por sesso RTP. Dessa forma, o formato pode
mudar no decorrer do tempo durante uma sesso. Mesmo tendo essa propriedade, o protocolo RTP
especifica que se udio e vdeo sero transmitidos por uma aplicao, devem ser criados duas
sesses. Uma para transmisso de vdeo e outra para a transmisso de udio, em diferentes portas e
endereos. Esta separao necessria para que a aplicao em questo possa requisitar diferentes
QoS para os tipos de mdia. Alm de permitir que o protocolo de controle RTCP possa funcionar
corretamente.
Os formatos de payload de vdeo, normalmente, usam clock de 90kHz. Isto feito para ter
compatibilidade com vdeos MPEG e para incrementar timestamps para quadros de taxa de 24Hz,
25Hz, 29.97Hz e 30Hz. A qualidade de resoluo no implementada pelo protocolo RTP, e deve
ser garantida pela aplicao.
O nmero de seqncia o que identifica cada pacote como nico. atravs dele que o
receptor descobre se pacotes esto sendo perdidos ou entregues fora de ordem. Em uma
comunicao tpica de voz sobre IP, enviando udio em pacotes a perodos de 20 milisegundos, o
nmero de seqncia se sobrepe a cada 20 minutos, aproximadamente. Isso significa que no deve
ser apenas considerado como identificador o nmero de seqncia padro de 16 bits. O
recomendado o uso de nmeros de seqncia estendidos a um inteiro sem sinal de 32 bits ou
maior. Sendo primeiros os 16 bits o nmero de seqncia do RTP, e os 16 bits restantes um
contador do nmero de vezes que o nmero de seqncia foi sobreposto, o que pode ser
representado pela seguinte expresso:
39
atual de seqncia for menor que o nmero mximo de seqncia. O nmero de seqncia pode ser
invlido e isto deve ser tratado tambm na implementao. Caso se decida no levar em conta o
contador de sobreposio, o nmero de pacotes perdidos e dados estatsticos de perda no so
verificados. Mas importante o seu uso estendido, pois bastante comum a ocorrncia de perda de
pacotes ou erros na reordenao dos pacotes durante o momento da sobreposio do nmero de
seqncia.
O nmero de seqncia sempre inicia com um valor randmico. E isto ocorre pela mesma
razo que acontece com o timestamp. Os nmeros de seqncia so reportados nos pacotes de
relatrio de recepo RTCP. Isso feito para controle de erros de transmisso e criao de dados
estatsticos de perda. Alm disso, o nmero de seqncia deve sempre seguir uma ordem crescente,
somando-se um, na medida que os pacotes so transmitidos. Jamais podero existir saltos de valores
tanto para um nmero maior quanto menor. Mesmo quando um vdeo subdividido, o nmero de
seqncia mantido contnuo. Quando detectado um intervalo entre os nmeros de pacotes, o
receptor percebe que houve perdas no envio dos pacotes por parte do transmissor. A partir disso,
pode ser alterada a ordem dos pacotes atravs de uma atualizao.
40
Outra caracterstica do protocolo RTP a possibilidade do uso de cabealhos de extenso.
Para isto deve ser setado para 1 o bit X do cabealho padro. Os tamanhos dos cabealhos de
extenso so variveis. Mas o mnimo de 32 bits, sendo os primeiros 16 bits contendo o tipo e os
16 bits restantes contendo o tamanho do mesmo. Normalmente, no so utilizados, mas foram
criados para uso experimental para novos tipos de formato de payload e para otimizao de alguns
tipos de payload. O contedo do cabealho RTP pode ser tanto esttico como dinmico. No caso
esttico, ele duplicado para toda a sesso que usa um determinado tipo de payload. Normalmente,
tudo o que considerado dinmico em um cabealho RTP configurado pelo SDP.
O campo de payload ou de dados pode suportar vrios frames por pacote. Por isso, o
receptor pode checar o tamanho do pacote caso seja um nmero constante de frames por pacotes.
Alm disso, existem alguns formatos de payload que referem a quantidade de frames. Isso muito
importante para aplicao receptora distinguir qual o ponto de reproduo. Esse caso ocorre quando
o nmero de frames pode ser varivel durante a transmisso.
4.2 RTCP
O protocolo RTCP (RTP Control Protocol) tem como objetivo fornecer feedback sobre a
qualidade de servio oferecida distribuio de dados RTP. Isto obtido atravs de transmisses
peridicas de pacotes de controle a todos participantes da sesso RTP, utilizando o mesmo
mecanismo de distribuio do RTP (no caso deste trabalho, multicast) e possuindo uma porta
especfica de controle na sesso. O pacote RTCP padro pode ser visto na Figura 16.
41
Padding (P): Indica se o tamanho do pacote extrapolou ou no. Caso o bit esteja setado
para 1, isto significa que um ou mais octetos foram adicionados no final do mesmo. J
quando ele setado para 0, no existe nenhum dado til e os dados complementares
devem ser ignorados (1 bit).
Item Count (IC): utilizado para indicar a quantidade da lista de itens que alguns
pacotes tm. Podem ser adicionados at 31 itens em pacotes RTCP. Quando o IC contem
o valor zero, significa que a lista de itens est vazia. Aplicaes que no necessitam
deste campo podem utiliz-lo com outra funo.
Packet Type (PT): Identifica o tipo de informao que est sendo enviada pela rede.
Existem cinco tipos padres que so descritos na especificao RTP. Outras mais
especficas podem ser definidas no futuro.
Length: Este campo contm o comprimento do pacote que vem abaixo do cabealho
padro. So medidos em unidades, pois todos pacotes RTCP so mltiplos de 32. Caso o
campo de Length esteja com o valor zero, o pacote RTCP apenas ter o cabealho
padro.
O encapsulamento do pacote RTCP similar ao RTP. Ele embarcado em pacotes UDP que
por sua vez so empacotados em pacotes IP. Podem ser enviados mais de um pacote RTCP por
pacote IP. Isto chamado de pacote RTCP composto e encontra-se ilustrado na Figura 17. O
primeiro pacote RTCP o que segue o cabealho do UDP, enquanto o segundo pacote RCTP est
imediatamente aps ao primeiro. Um conjunto como esse, com dois pacotes, chama-se pacote
RTCP composto.
42
Existem alguns tipos de aes que podem ser reportados atravs dos pacotes RTCP. Uma
das mais primitivas utilizaes do RTCP para reporte de relatrios sobre qualidade de recepo.
Isso realizado atravs de pacotes RTCP Receiver Report (RR). Qualquer participante de uma
sesso que esteja recebendo dados pode enviar esse tipo de pacote. O valor PT para esse tipo de
relatrio 201 e seu formato pode ser visto em maiores detalhes na Figura 18.
Como pode ser visto na figura, o pacote RR composto por uma srie de itens que
descrevem os dados relacionados qualidade transmisso. O campo RC apresenta o nmero de
blocos reportados. Caso ele seja zero, nenhum item est anexado ao cabealho padro. Mas quando
o campo Length for igual a 1, alm do cabealho padro, o pacote RTCP em questo ter o item
Reporter SSRC de 32 bits. Um pacote RTCP RR pode conter 31 blocos descrevendo a qualidade de
recepo de uma nica fonte de sincronizao. Caso existam mais de trinta e um transmissores, os
receptores devem enviar pacotes RR em um pacote RTCP composto. Cada bloco de relatrio
composto por sete campos num total de vinte e quatro octetos.
O campo Reportee SSRC indica quem o participante do grupo que o dono do bloco de
relatrio que est sendo enviado. Ou seja, quem gerou o pacote RTCP RR e est reportando
informaes para controle de qualidade e criao de estatsticas de transmisso e recepo. Algumas
estatsticas so vlidas apenas durante a existncia da sesso.
43
de nmero de seqncia. J o campo Loss Fraction representa o nmero de pacotes perdidos por
intervalo de relatrio, dividido pelo nmero de pacotes esperado. O valor da frao sempre
multiplicado por 256. Se o nmero de pacotes recebidos for maior que o nmero de pacotes
esperados, o Loss Fraction zerado. E atravs desse valor que o transmissor pode ter uma noo
se a quantidade de pacotes perdidos constante ou varivel. E se a perda transiente ou em longo
prazo. Com isso, possvel fazer a escolha certa sobre o tipo de formato que ser usado para
transmitir a mdia.
O campo LSR representa o timestamp do ltimo relatrio recebido pelo transmissor. Ele
contm trinta e dois dos 64 bits de timestamp do protocolo NTP, includo nos pacotes SR que sero
explicados em maiores detalhes a seguir. Caso no tenha sido recebido nenhum pacote SR do
transmissor, o LSR ter o valor zero. J o campo DLSR indica o tempo de atraso entre o ltimo
pacote RS e tempo de envio do pacote de relatrio de recepo. Ele expresso em unidades de
1/65.536 segundos. Assim como o LSR, o DLSR composto pelo valor zero se nenhum pacote RS
tenha sido recebido. A qualidade de recepo no importante apenas para o transmissor. Porque
atravs do receptor que o transmissor pode ter algum tipo de feedback sobre a qualidade de
transmisso. Dessa forma, o transmissor pode adaptar os seus prprios parmetros s atuais
caractersticas da transmisso. E em geral elas so altamente dinmicas, pois podem se modificar de
vrias formas. Apenas a entrada de um novo participante no grupo multicast pode modificar a
velocidade de transmisso de todos, j que fazem parte do mesmo grupo. Alm disso, atravs desse
tipo de feedback, o transmissor pode verificar se o problema reportado por um receptor tambm
um problema que assola os outros participantes ou se um problema isolado.
O RTT calculado pelo transmissor atravs dos campos LSR e DLSR computados e
enviados em pacotes RR pelo receptor. Podem ser calculados RTTs entre o transmissor e cada um
dos participantes. Alm dos pacotes RR enviados pelos receptores atravs do protocolo RTCP, os
transmissores tambm tm um equivalente. Eles enviam pacotes RS atravs do protocolo de
controle RTP. O formato e campos deste tipo de pacote podem ser vistos na Figura 19.
44
Figura 19: Pacote Sender Report
O campo NTP timestamp composto por um inteiro sem sinal de 64 bits e para que medidas
de tempo possam ser transformadas no tempo NTP, preciso adicionar 2.208.988.800 segundos. J
o RTP timestamp expresso em unidades de clock de mdia RTP, mas representa o mesmo instante
que o NTP timestamp expressa no pacote.
Atravs dos valores fornecidos pelo transmissor pelos pacotes RR, possvel calcular uma
mdia das taxas de pacotes e de payload enviadas em um intervalo de tempo. A razo para o clculo
dessa mdia o tamanho do payload. Assim, o throughput disponvel para o receptor pode ser
calculado pela multiplicao da mdia do tamanho de payload pelo nmero de pacotes recebidos
pelo receptor em questo.
Alm disso, o protocolo RTCP tambm usado na identificao dos usurios que participam
do grupo multicast. O pacote SDES pode conter informaes que vo desde o nmero do telefone
at o e-mail do participante do grupo. Normalmente, contm dados que so informados pelo usurio
e mostrados na aplicao cliente. Como o pacote SDES composto por vrios itens, torna-se
primordial o detalhamento dos itens SDES para que os pacotes SDES possam ser compreendidos
45
em sua plenitude. Na Figura 20 podem ser observados o formato do item e do tamanho e a ordem
de seus componentes internos.
Os itens SDES que compe os pacotes SDES so formados por trs itens. So eles:
Type: Indica o tipo de item que ser descrito ao longo do item SDES.
Length: Contm o tamanho do item de descrio, ou seja, a quantidade de octetos de
texto do campo Value.
Value: o texto que descreve o item e est na codificao UTF-8 [19].
No existe nenhum tipo de separao ou bit de indicao entre os itens contidos nos pacotes
SDES. O que acontece que so colocados um ou mais octetos nulos entre os itens SDES dentro do
pacote SDES. Quando o campo Type for zero, a lista de itens acabou. Os tipos padres atuais de
itens SDES so:
CNAME: um campo que prov um nome cannico para cada participante. Isto faz
com que exista um modo estvel e seguro de identificar, independente do SSRC, os
participantes do grupo multicast. Isto se torna necessrio pois podem existir nomes
iguais e necessrio ser independente do SSRC pois podem haver colises ou a
aplicao pode reiniciar. Nestes casos, o SSRC ser modificado e a identificao ser
perdida. Mas com este campo isto no acontece. Ele composto pelo nome e IP do
usurio e intermediado pelo smbolo @. Quando se faz uso das caixas NAT de traduo,
necessrio que haja tambm a traduo do RTCP CNAME para criar uma nica forma
de identificao. o nico campo exigido pela especificao RTP que deve constar nos
itens SDES (TYPE = 1).
NAME: Contm o nome do participante para ser disposto na lista de participantes como
parte da interface grfica da aplicao cliente (TYPE = 2).
EMAIL: Contm o endereo eletrnico no formato da RFC 822 [20]. Este dado deve ser
validado como e-mail vlido para se certificar de que um usurio idneo (TYPE = 3).
PHONE: Contm o nmero telefnico do participante. A especificao RTP recomenda
que seja um nmero internacional de telefone (TYPE = 4).
LOC: Identifica o local de cada participante. Pode ou no incluir coordenadas GPS para
localizao (TYPE = 5).
TOOL: Inclui o nome e a verso da implementao RTP (TYPE = 6).
46
NOTE: um recado que pode ser escrito pelo usurio para os outros usurios, mas no
prprio para mensagens instantneas (TYPE = 7).
PRIV: um mecanismo de extenso privada, utilizado para extenses especficas de
descrio. So raramente usados, pois podem ser definidos novos itens para extenso ao
invs de utilizar este campo (TYPE = 8).
O exemplo de um pacote SDES RTCP pode ser visto na Figura 21. Neste exemplo,
representado um pacote SDES com os itens CNAME e NAME.
Outro pacote especificado pelo protocolo RTCP o pacote BYE. Este utilizado para
controle de associao de membros. Caso um membro queira sair do grupo, ele deve mandar um
pacote BYE para o grupo. Este tipo de pacote diferenciado dos demais pelo tipo 203 e tem o
formato igual ao da Figura 22. A partir do momento que a aplicao recebe um pacote BYE, ela
obtm o campo RC que contm o nmero SSRC para ignorar qualquer pacote RTP ou RTCP da
fonte especificada. importante manter algum tipo de histrico mesmo algum tempo aps o
recebimento dos pacotes BYE, para permitir a prorrogao dos pacotes de dados.
47
Alm disso, nos pacotes BYE podem existir campos de texto explicando a razo da sada do
grupo. Isto til para mostrar na interface da aplicao para os demais usurios. Porm, trata-se de
campos opcionais. Podendo ser ignorados no recebimento.
Tendo em vista os pacotes RTCP descritos anteriormente neste captulo, torna-se bastante
trivial o entendimento geral do funcionamento do protocolo e de todos as precaues que o
circundam. Caso um participante servidor gere um pacote RTCP composto, este deve comear com
um pacote RTCP SR. Caso seja um cliente, deve iniciar com um pacote RTCP RR. Aps o pacote
RR ou RS, necessrio colocar em seguida um pacote SDES que deve incluir obrigatoriamente um
item CNAME no mnimo. A incluso dos outros itens conduzida em relao ao perfil RTP
escolhido. Por fim, devem ser includos sempre como ltimo pacote o BYE. Os outros pacotes
descritos no necessitam seguir uma ordem de preferncia. Estas regras servem para que exista um
modo de validao de pacotes seguros.
48
Um banco de dados de informaes sobre a sesso e sobre os participantes da mesma
guardado por cada aplicao que est na sesso RTP. Existem algumas variveis que so guardados
para controle de tempo atravs do protocolo RTCP. E so elas:
Alm das variveis descritas anteriormente, outras devem ser mantidas para que possam ser
includas em pacotes RTCP SR. Ou seja, pacotes de controle dos transmissores. E so elas:
Uma aplicao de streaming em tempo real, que utiliza o protocolo RTP e RTCP, segura e
consistente se cada participante mantm o estado dos outros membros da sesso durante o tempo de
vida da mesma. As informaes que os participantes devem manter tambm podem ser guardadas
em variveis e devem conter os seguintes dados:
O identificador SSRC;
49
As informaes de descrio para pacote RTCP SDES: CNAME e outros especficos
dependendo da aplicao necessitada;
Dados que permitem o clculo de estatsticas sobre qualidade de recepo para que seja
possvel a criao e envio de pacotes RTCP RR pelos receptores: jitter e nmero de
pacotes perdidos;
Dados recebidos pelos pacotes RTCP RS que permitem a sincronizao labial entre som
e imagem;
O ltimo momento no qual o participante enviou algum tipo de pacote na rede para o
grupo multicast da sesso para que no hajam participantes inativos. Caso existam
participantes inexistentes (cadastrados no grupo), a largura de banda utilizada ser mal
usada porque pacotes dos demais participantes sero encaminhados pela rede para este
participante inexistente;
Um flag que indica se este participante enviou algum tipo de dado durante o intervalo de
tempo para relatrios RTCP;
O buffers de reproduo de mdia;
O estado do codec utilizado;
Informaes para controle de erros em geral, para que possam ser corrigidos.
Qualquer tipo de estrutura criada a partir dos dados descritos anteriormente, devem ser
indexadas pelo SSRC que o que identifica unicamente cada participante da sesso RTP. Mas para
ser feita a sincronizao labial entre som e imagem, os participantes devem ser encontrados tambm
pelos CNAMEs.
Uma das etapas que devem ser desenvolvidas a etapa de validao dos participantes recm
cadastrados para que apenas participantes vlidos sejam cadastrados. Por isto, antes que um
participante seja aceito pelo grupo multicast que representa a sesso RTP, um pacote de validao
deve ser enviado aos demais. Para isto, no devem ser utilizados apenas pacotes RTP. Portanto,
devem ser usados pacotes RTCP para esta funo para que no seja um mtodo vulnervel de
validao.
Uma das maneiras mais simples manter uma tabela de participantes da sesso que tenham
recebido apenas um pacote RTP com um tamanho fixo. Esta deve ser leve e mantida com um time
out constantemente verificado. Desta forma, usurios inativos podem ser descartados. Cada pacote
RTP que contenha um CSRC vlido, este deve ser adicionado no banco de dados.
Outra forma de descartarem participantes atravs dos pacotes BYE. Quando um destes
recebido, o participante que o enviou decidiu sair da sesso RTP. Como no existe nenhuma
segurana quanto ordem de chegada dos pacotes, j que os pacotes so empacotados em
50
datagramas UDP, um pacote RTCP BYE pode ser recebido como no sendo o ltimo pacote do
participante em questo. Para prevenir este tipo de problema, pode ser usado algum tipo de delay
para o envio da mensagem BYE. Permitindo assim uma sincronizao probabilstica das
mensagens. Tambm deve ser definido algum tipo de tempo limite para inatividade. Caso o
participante fique um tempo maior que o esperado sem mandar pacotes, ele tambm ser
descartado. Outra questo que deve ser tratada quando mais de um membro decide sair da sesso
ao mesmo tempo. Isto pode causar congestionamento na rede com pacotes RTCP BYE. A verso 2
do protocolo RTP permite que pacotes BYE sejam mandados imediatamente apenas se menos que
50 membros decidem sair da sesso. Caso o nmero seja maior, precisar ser utilizado algum tipo
de delay. Este tempo de espera deve ser proporcional ao nmero de membros que est tentando sair
ao mesmo tempo.
51
5 ARQUITETURA
No momento que o mdulos transmissor e receptor iniciam a sua execuo eles acessam o
arquivo texto contendo os parmetros da conexo. Dessa forma possvel ajustar o mesmo
endereo multicast e por isso importante que o mdulo de configurao seja executado antes da
execuo dos demais mdulos. O usurio que transmitir o arquivo multimdia tambm deve
informar o tempo de durao do arquivo que ser transmitido. Esse valor armazenado em um
arquivo texto com o nome de tempo.txt que ser lido pelo mdulo receptor para que seja definido o
tempo de durao do loop de espera por dados.
53
Figura 25: Localizao do Socket
Quando uma requisio de transmisso recebida pelo servidor, disparada uma thread
para adicionar o cliente que a realizou no grupo multicast e fazer todo o controle necessrio para a
permanncia dele atravs da sesso. Tambm implementado um controle da largura de banda para
que no momento da distribuio do vdeo para os clientes no ocorra sobrecarga nem lentido em
demasia. O cliente executado sob a forma um Applet embutido no servidor Tomcat [7].
O Tomcat um servidor de aplicaes Java para web, distribudo como software livre e com
cdigo aberto, dentro do conceituado projeto Apache Jakarta e oficialmente endossado pela Sun
como a Implementao de Referncia para as tecnologias Servlet e JSP. robusto e eficiente,
podendo ser utilizado mesmo em um ambiente de produo. O Tomcat tem a capacidade de atuar
54
tambm como servidor web/HTTP, ou pode funcionar integrado a um servidor web dedicado como
o Apache httpd ou o Microsoft IIS.
Cada pacote a ser transmitido tem um campo de timestamp que representa o instante do
primeiro octeto de dados no frame. Como foi dito anteriormente, ele iniciado a partir de um valor
randmico inicial que incrementado atravs de uma taxa dependente da mdia. Como no nosso
caso, trata-se de um arquivo multimdia pr-gravado em disco, os timestamps criados apenas
representaro a seqncia de tempo de reproduo de cada quadro. Caso um quadro seja
fragmentado em mltiplos arquivos RTP, cada pacote conter o mesmo timestamp. O que de
grande valia no reordenamento de pacotes e seqncia de reproduo. Um exemplo de um pacote
fragmentado pode ser visto na Figura 26.
Como j foi dito anteriormente, o mdulo cliente responsvel por receber os pacotes RTP
provenientes da rede e fazer as correes necessrias para reparar o caso de pacotes perdidos,
recuperao de tempo, descumprimento da mdia e apresentao do arquivo multimdia para o
usurio. Alm disso, deve enviar relatrios sobre a qualidade de recepo para o servidor de
streaming atravs de pacotes RTCP. Desta forma, o mdulo servidor pode adaptar a transmisso
para as caractersticas necessrias da rede em uso. O mdulo cliente tambm mantm um banco de
55
dados sobre os demais participantes da sesso em questo para prover informaes aos usurios,
como pode ser visto na Figura 27, que ilustra o funcionamento do cliente.
56
Figura 28: Arquitetura Proposta
A arquitetura descrita pode ser mais bem observada no exemplo da Figura 28. Parte-se do
pressuposto de que o Cliente A no fez solicitao alguma e que o Cliente B j faz parte do grupo
multicast em questo. O que de grande valia a seqncia de acontecimentos decorrentes do
acesso do Cliente C ao link com o Applet. A partir deste momento, o Applet cria uma conexo via
socket com o Servidor de Streaming que, por sua vez, dispara uma thread e adiciona o Cliente C ao
grupo atual de transmisso.
Outra caracterstica do mdulo cliente que ele deve manter um bom valor dos gargalos
criados entre os pacotes recebidos pela rede. E deve estar preparado para receber pacotes em
rajadas. Alm disso, o cliente guarda o valor exato do tempo de chegada dos pacotes RTP para que
o jitter possa ser calculado. Caso seja mal calculado, existir uma demora demasiada entre cada
jorrada de pacotes, causando um delay de reproduo. Para isto, a taxa de clock de mdia deve ser
somada com o offset para correo de skew entre o clock de referncia e o clock de mdia. O
processamento dos pacotes processado em uma thread separada. Dentro do loop, pacotes so lidos
atravs do socket multicast e inseridos nas filas de espera. A partir da, os pacotes so passados
quando necessrio para reproduo. Caso pacotes cheguem em rajadas, alguns podem continuar nas
filas de espera, dependendo da taxa de reproduo e capacidade de processamento. Sendo assim,
uma thread espera dados do socket e os coloca nas filas de espera. Outra thread remove os dados
das filas para a reproduo da mdia, atravs dos campos timestamps de cada pacote RTP.
Quadros so guardados no buffer de reproduo por um tempo para suavizar as variaes de
tempo causadas pela rede. Alm disso, permite que quadros fragmentados possam ser reagrupados.
Os quadros so descomprimidos, erros so escondidos e a mdia pode ser interpretada pelo usurio.
57
O buffer de reproduo contm uma lista de nodos ordenados pelo tempo. Cada n representa um
quadro de dados de mdia, associado com informaes temporais. Cada n contm uma estrutura de
dados com um ponteiro para o prximo n, o tempo de chegada, o timestamp RTP e o tempo de
reproduo para o quadro.
Quando um pacote RTP chega, o ltimo da fila de espera removido e inserido um novo
nodo no buffer de reproduo e posicionado em relao ao timestamp. Aps todos os fragmentos de
um quadro serem recebidos, o decodificador invocado. Codecs de udio no fragmentam quadros
e cada pacote contm um quadro. J codecs de vdeo, muitas vezes, geram mltiplos pacotes por
quadro de vdeo com o campo Marker (M) do pacote RTP marcando o ltimo fragmento. Mas nem
sempre quando um pacote com o bit M com o valor 1 quer dizer que o quadro completo chegou
completamente, pois pacotes podem chegar em ordens diferentes devido aos pacotes empacotados
em datagramas. Neste caso, so utilizados o mesmo timestamp e o menor nmero de seqncia
utilizado para o ltimo pacote de um quadro completo. Quando o quadro for reproduzido, o n ser
removido. Uma das principais caractersticas que devem ser definidas o delay de reproduo
escolhido. O tempo de espera antes de algum erro de correo nos pacotes recebidos, o tempo de
espera entre o recebimento do primeiro e o ltimo pacote de um frame e a variao de tempo entre
os pacotes, causada pelo jitter, so alguns dos fatores que influem na escolha do delay correto.
O espaamento entre pacotes de um quadro e o tempo de espera entre pacotes de dados e
pacotes de correes de erros controlado pelo servidor de streaming. Quando o cliente for escolher
o tempo de reproduo para cada frame, ele ir seguir alguns passos. Primeiramente, a linha
temporal do servidor ser mapeada na linha temporal local, compensando o offset entre os clocks do
servidor e do cliente. Ento, o cliente ir compensar clock skew do servidor. O tempo de espera de
reproduo da linha temporal local calculado tendo como base um componente do servidor
contendo seu prprio delay de reproduo e o jitter criado pela rede. Aps isto, o tempo de espera
de reproduo ser ajustado caso a rota dos pacotes tenha mudado. Finalmente, o tempo de espera
de reproduo adicionado base temporal para o clculo do tempo de reproduo do quadro atual.
inevitvel que haja variaes na entrega de pacotes pela rede. Com isto, ser escolhido um
valor maior que o jitter da rede para que possa ser esperado antes de ser processado. Alguns
segundos bastam para uma compensao apropriada. Como no possvel descobrir de antemo o
jitter induzido pela rede. Ser escolhido um valor randmico que poder ser ajustado no decorrer da
transmisso atravs de pacotes RTCP. O estimado jitter multiplicado por 3 deve ser somado ao
tempo atual. Isto infere um novo tempo de reproduo. A variao do jitter ir depender tanto do
caminho percorrido pelo trfico da rede quanto o restante de dados trafegando na rede. A adaptao
apenas tentar adaptar o delay do buffer de reproduo caso acontea uma mudana significativa
58
em uma poro de pacotes descartados pela demora na chegada. Tambm ir adapt-lo quando
vrios pacotes forem recebidos do servidor, caso ele esteja inativo por um perodo de tempo.
Alguns eventos de mdia tambm podero aumentar o tempo de espera entre pacotes
consecutivos. Por exemplo, o silncio suprimido no udio pode causar um gargalo entre o ltimo
pacote e o primeiro pacote do prximo frame. Outro exemplo uma variao da taxa do quadro de
vdeo pode causar variaes nos tempos de chegada entre os pacotes.
O processo de reproduo de udio assncrono. Por isso, enquanto um quadro est sendo
reproduzido, outro estar sendo processado em outra thread. Esta caracterstica essencial para
reproduo em sistemas operacionais com suporte limitados para aplicaes multimdia. Isto de
extrema importncia para este trabalho devido ao fato de que o cliente ser acessado via Internet e
ser feito em Java. Ou seja, no existe um conhecimento prvio sobre qual sistema operacional os
clientes estaro executando o mdulo cliente. J o processo de reproduo de vdeo dedicado
atualizao da taxa de exibio, o que determina o tempo mximo entre o cliente escrever no buffer
de sada e a imagem ser exibida ao usurio. Frames (quadros) no so representados
instantaneamente.
O Applet ser disponibilizado atravs de um link na pgina da FURG TV
(www.furgtv.furg.br). Aps fazer a solicitao de conexo por uma porta em um socket, utilizado
uma primitiva receive(), esperando assim a transmisso dos dados. Aps o final da transmisso, o
servidor fechar a conexo atravs da primitiva stop(), terminando assim a sesso. Desta maneira,
ser disponibilizado o canal de televiso da Universidade Fundao Universidade Federal do Rio
Grande via streaming na Internet.
59
determinado grupo de usurios. Pode ir de 224.0.2.0 at 238.255.255.255.
Time To Live (TTL): Parmetro responsvel pelo controle do tempo de vida de um
datagrama, evitando assim a existncia de um loop eterno devido a algum erro de
roteamento.
Existe um sub-menu chamado Sobre contendo informaes para que o usurio do Servidor
de Streaming possa configurar a conexo entre o servidor e os clientes, atravs da modificao dos
parmetros contidos no arquivo texto. Tambm existem outro sub-menu que fecha a aplicao e o
boto Fechar que tem o mesmo objetivo. Todos os componentes so colocados dentro de um
JFrame (container). Para cada campo, existe um texto pop-up de ajuda, descrevendo-o para que
possa haver um entendimento sobre quais valores podem preencher os campos.
60
Para o desenvolvimento da aplicao foram utilizados os seguintes pacotes: javax.swing,
java.awt e java.io. Os dois primeiros pacotes permitem a criao da interface grfica. J o pacote
java.io permite operaes de entrada e sada (por exemplo: criar, editar e destruir arquivos de texto).
Para iniciar o processo de streaming, deve-se clicar no boto Adicionar Vdeo para abrir o
arquivo multimdia em questo para ser enviado pela Internet para os clientes que acessarem o link
na pgina www.furgtv.furg.br para assistir a FURG TV via rede. Aps o clique, aberta uma janela
do tipo javax.swing.JFileChooser, como pode ser observado na Figura 31. A janela principal no
pode ser acessada enquanto no for escolhido um arquivo ou for cancelada a operao.
61
Figura 31: Selecionando o arquivo atravs do javax.swing.JFileChooser
Aps a escolha do arquivo em questo, ele selecionado passado para uma varivel URL
chamada de mediaURL que utilizada para criar o MediaLocator que ser passado como
parmetro, junto aos dados contidos no arquivo parmetros.txt (TTL, IP e Porta), para o objeto
tempo durante sua criao.
A instanciao do objeto tempo se faz necessrio para definir o tempo de durao do arquivo
de vdeo que ser transmitido. Isto til para a definio, tanto no transmissor quanto no receptor,
da temporizao de streaming. A partir deste momento, uma nova janela criada para a
especificao do tempo de durao atravs de trs campos: horas, minutos e segundos. Aps o
preenchimento destes, deve-se clicar no boto OK como mostrado na Figura 32. Isto far com que
seja criado um arquivo chamado tempo.txt com a durao do vdeo. Este arquivo ser acessado
mais tarde pelo mdulo Receptor, durante sua execuo. Com isto, finalizada a janela de
temporizao contida na figura e criada a janela contido na Figura 35.
Aps a confirmao sobre a durao do vdeo, atravs do clique no boto OK, criado um
novo objeto Transmissor (proveniente da classe Transmissor.java). Esta classe a que faz todo o
62
processamento de dados e transmisso via rede. Primeiramente, configurada a interface visual e os
atributos (MediaLocator, IP, TTL e Porta) so preenchidos pelos parmetros passados pelo objeto
tempo. Aps executado o procedimento start(), o que inicia a transmisso de verdade. Caso
acontea um erro durante a transmisso, este mtodo retornar uma String com o erro especificado.
Do caso contrrio, retornar nulo. O procedimento bastante simples: cria-se o processor atravs do
procedimento createProcessor() para o arquivo especificado pelo MediaLocator. Aps, utilizado
o mtodo createTransmiter() para criar as sesses RTP atravs dos RTPManagers. Finalmente,
utilizado a primitiva start() contida na Classe Processor. Os atributos e mtodos da classe
Transmissor.java podem ser vistos em maiores detalhes na Figura 33.
64
Figura 35: Janela de Status de Transmisso
Na janela principal sempre existir uma aba ativa. Na Figura 30, a aba Servidor de Vdeos
a que exibida por padro no momento em que executado o mdulo Transmissor. A segunda aba,
chamada de Sobre, demonstrada na Figura 36. Para que uma aba fique ativa, deve-se apenas clicar
sobre a mesma, em seu ttulo. J a ltima aba apenas um informativo sobre os meus dados
pessoais para futuro contato.
65
segundos no mximo. Enquanto isto est acontecendo, o label status contm o valor sintonizando
para um melhor entendimento do usurio sobre o que est acontecendo durante a transmisso. Caso
nenhum dado tenha sido recebido durante os 30 segundos, o label recebe o valor de canal fora do ar
e os players so fechados, assim tambm como os RTPManagers. Para isto, existe o mtodo close().
Outro mtodo importante da classe PlayerApplet o update() que, dependendo do parmetro
passado, ou adiciona participante ao grupo (SessionEvent) ou recebe streams
(ReceiveStreamEvent). Caso tenha recebido um stream, o evento mapeado para cada um dos
seguintes eventos:
O Mdulo Receptor de utilizao muito simples para o usurio. Basta clicar no link
respectivo ao Applet que ser instantaneamente apresentado, no Player FURGTV, o programa que
est sendo transmitido no exato momento da execuo.
66
6 JAVA MEDIA FRAMEWORK
O JMF tem como funo principal incorporao de mdias iscronas em aplicaes Java
ou em Applets. Alm de servir como um apoio para aplicaes desenvolvidas para streaming de
vdeo e udio, ele prov facilidade para a criao de plug-ins para suportar tipos de mdia que,
atualmente, no so suportados pela API [18].
A API JMF constituda por interfaces que definem o comportamento dos objetos e o modo
como eles interagem para a captura, processamento e apresentao de multimdia. Implementaes
dessas interfaces operam dentro do prprio JMF atravs do uso de objetos chamados Managers.
Dessa forma, torna-se fcil integrar novas implementaes de interfaces para us-las em conjunto
com as atualmente implementadas. Quatro tipos de Managers podem ser usados:
67
MediaTime = TempoInicial + TAXA(TempoBaseAtual TempoBaseInicial)
68
Outro modelo definido pela API JMF o de controle. Quase todos os objetos, e alguns plug-
ins, precisam de algum tipo de controle. Dessa forma, devem ser criados objetos Control que
implementam a interface Controls. Para isto, usada a classe Control. Sua estrutura de classes
composta pelas seguintes subclasses:
StreamWriterControl: interface que deve ser implementada para que objetos, como o
DataSink, possam ler dados de um objeto DataSource e escrever em um destino. Atravs
dela, torna-se possvel limitar o tamanho de cada stream criado para transmisso;
SilenceSuppressionControl: prov a retirada de silncios que causam uma sobrecarga
desnecessria no trfego da rede;
PacketSizeControl: proporciona controle sobre o tamanho dos pacotes enviados pela
rede;
FrameGrabbingControl: prov a facilidade para se obter um quadro isolado do stream de
vdeo;
FramePositionControl: usado para o posicionamento preciso dentro de objetos
transmissores;
QualityControl: possibilita o controle sobre a qualidade de transmisso e recepo
multimdia. Muitas vezes, deve-se ajustar a qualidade ao consumo da CPU e a
performance do codec escolhido;
FormatControl: utiliza uma subclasse chamada TrackControl para controle de trilhas.
Existir normalmente uma trilha de udio e outra de vdeo.
BitRateControl: fornece controle sobre a taxa de bits transmitidos. Tambm utilizado
para controlar a taxa de compresso. Sua especificao informa as taxas em bits por
segundo;
BufferControl: fornece controle sobre o buffer utilizado para suavizao da reproduo;
FrameRateControl: ;az com que seja possvel o controle sobre a taxa de transmisso de
quadros.
CachingControl: controle de cach;
FrameProcessingControl: faz o controle de processamento dos quadros atravs de
parmetros que permitem a otimizao do codec;
H261Control: permite controle sobre o codec de vdeo H.261;
H263Control: permite controle sobre o codec de vdeo H.263;
MpegAudioControl: atravs deste podem ser feitas modificaes nos parmetros do
codec de udio MPEG;
69
KeyFrameControl: modificaes podem ser feitas entre os intervalos dos quadros chave;
MonitorControl: possibilita a pr-visualizao do vdeo que est sendo capturado ou
codificado;
PortControl: utiliza mtodos para o controle de sada do dispositivo de captura.
O Java Media Framework utiliza um modelo de dados intrnseco que permite o uso de
objetos chamados DataSource para transmitir contedos de mdia. Esses objetos tem a localizao e
o protocolo utilizado para transmitir o vdeo. Um DataSource definido por um MediaLocator ou
por uma URL. Caso for um MediaLocator, ele pode ser construdo mesmo se o protocolo
especificado pelo DataSource no for suportado. Alm disso, ele utiliza um vetor de bytes para
transmisso. Podem existir diferentes tipos de DataSources como pode ser visto na estrutura de
classes representada na Figura 37. Elas so classificadas em relao ao modo como a transferncia
de dados iniciada.
70
6.2 Funcionamento da API JMF
A API JMF verso 1.0 (Java Media Player API) possibilita desenvolver programas, na
linguagem Java, capazes de reproduzir mdias. A verso 2.0 do JMF estende esse framework para
prover suporte capturao e o armazenamento de dados de mdia, controlar o tipo de
processamento realizado durante o playback, padronizar o processamento de streams de dados de
mdia. A partir dessa verso foi disponibilizada a extenso de plug-ins JMF para otimizar e
possibilitar o uso de tipos de mdia no suportados pelo JMF.
A Figura 37 ilustra o funcionamento abstrato da API JMF. Entre parnteses so descritos os
nomes das classes, correspondentes aos dos dispositivos por elas abstrados. Ali se pode deparar
que a cmera de vdeo capta imagens para transmisso ao vivo.
O vdeo fonte pode ser um arquivo salvo previamente em disco ou captado ao vivo. Mas o
seu formato deve ter a possibilidade de ser transformado em JPEG/RTP. Alguns exemplos de
formatos que apresentam essa propriedade so Cinepak, RGB, YUV e JPEG. Outros formatos
podem no funcionar corretamente devido a restries da classe Processor, explicada em maiores
detalhes anteriormente. Outra caracterstica importante a ser considerada a dimenso do vdeo que
deve ser mltipla de 8x8. Um exemplo de dimenso admitida seria 320x240.
Cada formato de vdeo tem caractersticas distintas, sendo que os principais formatos
suportados pela API JMF so os apresentados na Tabela 8, onde tambm esto descritas as suas
respectivas caractersticas.
71
Formato Tipo Qualidade Requisitos do CPU Requisitos de
Largura de Banda
Cinepack AVI, Quicktime Mdia Baixo Alto
MPEG-1 MPEG Alta Alto Alto
H.261 AVI, RTP Baixa Mdio Mdio
H.263 AVI, RTP, Quicktime Mdia Mdio Baixo
JPEG RTP, AVI, Quicktime Alta Alto Alto
Tabela 8: Formatos de vdeo suportados pelo JMF
Requisitos de
Formato Tipo Qualidade Requisitos do CPU Largura de
Banda
AVI, WAV,
PCM Quicktime Alta Baixo Alto
AVI,
Mu-Law Quicktime, Baixa Baixo Alto
WAV, RTP
AVI,
ADPCM Quicktime, Mdia Mdio Mdio
WAV, RTP
MPEG1 MPEG Alta Alto Alto
GSM WAV, RTP Baixa Baixo Baixo
G.723 WAV, RTP Mdia Mdio Baixo
Tabela 9: Formatos de udio suportados pelo JMF
O servidor de streaming aceita como entrada o local de onde sero fornecidos os dados a
transmitir, indicado atravs de uma URL. Os seguintes passos so necessrios para que a
transmisso acontea sem problemas:
72
configurar o Content Descriptor de sada contido no Processor;
Verificar se cada formato de trilha de dados est em um formato suportado;
Obter o DataSource de sada e us-lo em conjunto com o Media Locator de sada para
criar o DataSink;
Iniciar o Processor e o DataSink;
Esperar que o evento EndOfStreamEvent provido pelo DataSink ocorra, indicando o
final do arquivo;
Fechar o Processor e o DataSink.
Para transmitir um stream RTP, conforme ilustrado na Figura 38, deve-se usar um Processor
para produzir um DataSource de dados RTP codificados e construir ou um SessionManager ou
outro DataSink (para controlar a transmisso). Existem duas maneiras de enviar dados RTP:
Usar um Media Locator que tm os parmetros da sesso RTP para construir um
DataSink chamando a funo Manager.createDataSink;
Usar um Session Manager para criar e enviar streams de dados e controle.
O Processor tenta carregar o plug-in que suporta o formato escolhido. Caso o formato seja
desconhecido pela API JMF a exceo UnSupportedFormatException ser disparada. O formato de
sada especificado atravs do mtodo setOutputContentDescriptor. Como neste trabalho no foi
necessrio nenhum tipo de multiplexao, j que a aplicao em foco trata apenas uma fonte de
dados (servidor de streaming), o content descriptor de sada ser ContentDescriptor.RAW. Cada
73
trilha (vdeo e udio) transmitida em sesses RTP distintas. Ou seja, criada uma sesso para
transmitir os dados de vdeo e outra para transmitir os dados de udio.
O tempo de espera de um pacote ou intervalo de empatamento o tempo necessrio ao
pacote percorrer a rede e chegar ao destino. Ele determina o mnimo intervalo de tempo fim-a-fim.
Este valor deve estar no intervalo de 0 a 200 ms para dados de udio que sero transmitidos. Essa
restrio permite que o buffer do cliente possa ser redimensionado. Cada codec tem um valor
especfico para o delay respectivo. J para streams de vdeo, um frame de vdeo transmitido em
mltiplos pacotes RTP. O tamanho de cada pacote enviado limitado pelo MTU.
A mdia que ser enviada pela rede via socket para um grupo multicast pode ser manipulada
antes do envio, ou antes de ser apresentada ao usurio. Caso seja um fluxo multiplexado, as trilhas
sero extradas individualmente por um demultiplexador. Se elas estiverem comprimidas sero
decodificadas por um codec e transformadas no formato RAW (prprio para apresentao). Filtros
tambm podem ser aplicados s trilhas decodificadas e transform-las em tipos diferentes,
dependendo das necessidades da aplicao, ou devido a restries da rede. O prximo passo a
entrega das trilhas para o dispositivo de sada.
Durante a recepo de streams de mdia, conforme ilustrado na Figura 39, o Session
Manager poder criar um DataSource para os pacotes que so providos pela rede, que por sua vez
podero criar ou um Processor ou um Player ou um DataSink. Caso o objetivo seja armazenar os
dados de mdia recebidos em um arquivo, deve-se usar ou um Processor ou um DataSink. Se a
escolha for um Processor, dever ser criado outro DataSource que criar o DataSink. Este salvar os
dados em um arquivo.Por outro lado, se o objetivo for reproduzir os dados recebidos pela rede,
deve-se criar um Player.
74
Os filtros podem ser aplicados em um vdeo para produzir alguns efeitos especiais. Tanto
pode ser aplicado antes da mdia ser processada pelo codec ou depois. Normalmente so aplicadas a
dados RAW (descomprimidos).
75
7 TESTES E RESULTADOS
A Figura 44 mostra uma cena da sada de vdeo que foi assistida atravs da execuo do
Mdulo Receptor, durante testes realizados dia 21/12/07, s 15h, no Ncleo de Computao
Cientfica (NCC). Os testes levaram trinta minutos e vinte e dois segundos, durao do vdeo cedido
pela FURGTV. Tratava-se de um programa, chamado MUSIURG 19 dia do rock 1, que tinha
como foco principal a msica regional e da cidade.
Durante a realizao do experimento foi utilizado um Notebook Dell Latitude D520 (Intel
Core 2 Duo, 1.66GHz com 1014 MB de ram) executando o Mdulo Transmissor no Windows Vista
Home Basic. Ou seja, representando o Servidor de Streaming.
Alm disso, foram utilizados trs PCs executando o Mdulo Receptor, na condio de
telespectadores da FURGTV, utilizando o Ubuntu 7.10 como Sistema Operacional.
O tamanho padro do vdeo foi de 320 pixels de largura e 240 pixels de altura.
O valor de jitter (RTPtime) foi escolhido como 77.
Foi utilizado o software Wireshark 0.99.6a (www.wireshark.org) para avaliar os pacotes que
transitaram pela rede atravs do filtro UDP para pacotes enviados para o endereo multicast
230.0.0.1.
Atravs da anlise estatstica mostrada na Figura 45 pode-se perceber que a maior
porcentagem de pacotes enviados para o endereo em questo tinha o tamanho entre 640 e 1279
bytes, totalizando 93,33% do total de pacotes criados e enviados. Tambm foi observado que
existiram vrias faixas de tamanho de pacotes que no foram utilizados, ou seja, no foram criados
pacotes desses tamanhos durante a transmisso.
76
Figura 45: Tamanho dos pacotes
Outro dado importante a ser relatado que foi utilizado o tipo RAW para transmisso, ou
seja, o vdeo foi decodificado para esse padro. Alm disso, foi utilizado o tipo jpeg/rtp para
codificao. A taxa mdia de bits por segundo foi de 780.58 kbps, enquanto a taxa mdia de
quadros por segundo foi de 16.6 fps.
Foram capturados vrios grficos indicando quantos pacotes por segundo eram recebidos
pelos receptores. A Figura 46 mostra a variao dos pacotes para o primeiro receptor, decorridos
950 segundos aps a sua execuo.
Como pode ser visto na figura, o Mdulo receptor estabilizou a transmisso aps o tempo de
950 segundos. Com isso, houve uma suavizao na tramitao dos pacotes e um melhor fluxo de
transmisso por parte do Servidor de Streaming. Para a leitura do grfico, cabe ressaltar que foi
utilizado 1 segundo por tick e foram utilizados 5 pixels por tick (eixo x do grfico). J o eixo y
indica a quantidade de pacotes por tick.
77
No teste, os dois primeiros receptores foram iniciados quase que simultaneamente com o
incio da transmisso. O terceiro receptor foi iniciado e o grfico mostrado na Figura 47 apresenta o
comportamento da recepo dos pacotes nele ocorrido.
78
8 CONCLUSO
79
9 REFERNCIAS BIBLIOGRFICAS
[1] FINZSCH, P., ROESLER, V. "Anlise do mecanismo de pares de pacotes para inferncia de
banda mxima em redes de computadores". UNISINOS - Universidade do Vale do Rio dos Sinos,
Centro de Cincias Exatas e Tecnolgicas, junho de 2003.
[2] KARSTEN, M., VENTER, R."MBone: The Multicasting Backbone". HSN-Team, Department
of Computer Science, University of Pretoria, Pretoria, 2002, South Africa.
[3] VENAAS S., CHOWN T. "Source Specific Multicast (SSM) with IPv6". School of Electronics
and Computer Science, University of Southampton, United Kingdom.
[4] ROESLER, V., GIULIANO G., VALDENI J. "ALM: Adaptive layering Multicast". UNISINOS
-Universidade do Vale do Rio dos Sinos, Centro de Cincias Exatas e Tecnolgicas.
[5] NOGUCHI T., YAMAMOTO M. "Construction of a Robust Multicast Tree for Application-
Level Multicast". EICE TRANS. COMMUN., VOL.E88B, NO.12 DECEMBER 2005.
[6] FRANCIS P. "Yoid: Extending the Internet Multicast Architecture". Em: www.aciri.org. 2 de
Abril, 2000.
[8] SHULZIRINNE, CASNER, FREDERICK, JACOBSON. "RTP: A Transport Protocol for Real-
Time Applications". Columbia U. Internet Engeneering Task Force, maio de 2002.
[9] http://www.protocols.com/pbook/h323.htm
[11] http://www.planet-lab.org
[12] http://www.itu.org
[15] RTP: A Transport Protocol for Real-Time Applications (RFC 3550). Em:
http://www.ietf.org/rfc/rfc3550.txt
[16] IANA: rgo responsvel por estabelecer numeraes padro para a Internet. Em:
http://www.iana.org
80
[19] F. Yergeau. "UTF-8, a Transformation Format of ISO 10646," Internet Engineering Task
Force, RFC 2279, January 1998.
[20] D. Crocker. "Standard for the Format of ARPA Internet Text Messages," Network Working
Group, RFC 822, August 1982.
81
ANEXOS
Parametros.java
/** Pacote Principal */
package configuratv;
Toolkit tk = Toolkit.getDefaultToolkit();
img = tk.getImage("furg.gif");
this.setIconImage(img);
82
/** Insere textos de ajuda */
jLabel1.setToolTipText("Uma aplicao que necessita da comunicao via Internet deve utilizar os protocolos de
transporte como pontos de acesso (udp ou tcp).");
jLabel2.setToolTipText("Uma porta um valor inteiro positivo que representa a ligao entre a camada de
aplicao (usurio) e a camada de transporte (comunicao)");
jLabel3.setToolTipText("O endereamento Multicast permite enviar pacotes IP para um determinado grupo de
usurios. De 224.0.2.0 at 238.255.255.255 (os valores entre pontos vo de 0 at 255).");
jLabel4.setToolTipText("Time To Live = controla o tempo de vida de um datagrama, evitando assim que este
fique \n" + "em um loop eterno devido a algum erro de roteamento.");
try
{
/** abre arquivo parametros.txt */
arq = new BufferedWriter(new FileWriter("C:/parametros.txt"));
arq.write(protocolo+" ");
arq.write(porta+" ");
arq.write(ip+" ");
arq.write(ttl);
arq.close();
}
catch(Exception e){e.printStackTrace();}
}
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
setTitle("Par\u00e2metros - FURGTV");
setBackground(new java.awt.Color(82, 109, 166));
setCursor(new java.awt.Cursor(java.awt.Cursor.DEFAULT_CURSOR));
setForeground(java.awt.Color.lightGray);
setResizable(false);
addWindowListener(new java.awt.event.WindowAdapter() {
public void windowClosed(java.awt.event.WindowEvent evt) {
formWindowClosed(evt);
}
});
83
jLabel4.setForeground(new java.awt.Color(255, 255, 255));
jLabel4.setText("TTL");
jTextField3.setText("232.0.0.1");
jTextField3.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jTextField3ActionPerformed(evt);
}
});
jTextField2.setText("5000");
jTextField2.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jTextField2ActionPerformed(evt);
}
});
jTextField1.setEditable(false);
jTextField1.setText("udp");
jTextField1.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jTextField1ActionPerformed(evt);
}
});
jTextField4.setText("1");
jTextField4.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jTextField4ActionPerformed(evt);
}
});
jButton2.setText("Fechar");
jButton2.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton2ActionPerformed(evt);
}
});
jButton1.setText("Salvar");
jButton1.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton1ActionPerformed(evt);
}
});
84
.add(jLabel2)
.add(jLabel3)
.add(jLabel1)
.add(jButton2))
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING)
.add(jPanel1Layout.createSequentialGroup()
.add(17, 17, 17)
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING)
.add(jTextField2, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, 54, Short.MAX_VALUE)
.add(jTextField1, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, 54, Short.MAX_VALUE)
.add(jTextField4, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, 54, Short.MAX_VALUE)
.add(jTextField3, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE))
.add(52, 52, 52))
.add(org.jdesktop.layout.GroupLayout.TRAILING, jPanel1Layout.createSequentialGroup()
.addPreferredGap(org.jdesktop.layout.LayoutStyle.RELATED)
.add(jButton1)
.add(29, 29, 29))))
);
jPanel1Layout.setVerticalGroup(
jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING)
.add(org.jdesktop.layout.GroupLayout.TRAILING, jPanel1Layout.createSequentialGroup()
.addContainerGap()
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE)
.add(jLabel1)
.add(jTextField1, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE))
.add(16, 16, 16)
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE)
.add(jLabel2)
.add(jTextField2, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE))
.add(15, 15, 15)
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE)
.add(jLabel3)
.add(jTextField3, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE))
.add(14, 14, 14)
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE)
.add(jLabel4)
.add(jTextField4, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE))
.add(26, 26, 26)
.add(jPanel1Layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE)
.add(jButton2)
.add(jButton1))
.addContainerGap())
);
85
public void actionPerformed(java.awt.event.ActionEvent evt) {
jMenuItem1ActionPerformed(evt);
}
});
jMenu1.add(jMenuItem1);
jMenuItem1.getAccessibleContext().setAccessibleParent(jMenu1);
jMenuItem3.setText("Item");
jMenuItem3.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jMenuItem3ActionPerformed(evt);
}
});
jMenu1.add(jMenuItem3);
jMenuItem2.setText("Item");
jMenuItem2.setBorder(javax.swing.BorderFactory.createEtchedBorder());
jMenuItem2.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jMenuItem2ActionPerformed(evt);
}
});
jMenuItem2.addMouseListener(new java.awt.event.MouseAdapter() {
public void mouseClicked(java.awt.event.MouseEvent evt) {
jMenuItem2MouseClicked(evt);
}
});
jMenu1.add(jMenuItem2);
jMenuBar1.add(jMenu1);
setJMenuBar(jMenuBar1);
org.jdesktop.layout.GroupLayout layout = new
org.jdesktop.layout.GroupLayout(getContentPane());
getContentPane().setLayout(layout);
layout.setHorizontalGroup(
layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING)
.add(jPanel1, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE)
);
layout.setVerticalGroup(
layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING)
.add(org.jdesktop.layout.GroupLayout.TRAILING, jPanel1,
org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, 200, Short.MAX_VALUE)
);
pack();
}
status.setForeground(Color.WHITE);
Font fo = new Font ("Arial", Font.BOLD, 12);
status.setFont(fo);
86
painel = new Panel();
f = new JFrame();
painel.add(status);
painel.setBackground(Color.BLACK);
f.setResizable(false);
f.setSize(480,140);
f.add(painel);
f.setTitle("Sobre");
f.setEnabled(true);
f.show(true);
f.setDefaultCloseOperation(f.HIDE_ON_CLOSE);
jPanel1.setEnabled(false);
f.setIconImage(img);
}
try
{
/** abre arquivo parametros.txt */
arq = new BufferedWriter(new FileWriter("parametros.txt"));
try
{
/** abre arquivo parametros.txt */
arq = new BufferedWriter(new FileWriter("C:/parametros.txt"));
87
arq.write(protocolo+" ");
arq.write(porta+" ");
arq.write(ip+" ");
arq.write(ttl);
// Declarao de variveis
private javax.swing.JButton jButton1;
private javax.swing.JButton jButton2;
private javax.swing.JLabel jLabel1;
private javax.swing.JLabel jLabel2;
private javax.swing.JLabel jLabel3;
private javax.swing.JLabel jLabel4;
private javax.swing.JMenu jMenu1;
private javax.swing.JMenuBar jMenuBar1;
private javax.swing.JMenuItem jMenuItem1;
private javax.swing.JMenuItem jMenuItem2;
private javax.swing.JMenuItem jMenuItem3;
private javax.swing.JPanel jPanel1;
private javax.swing.JTextField jTextField1;
private javax.swing.JTextField jTextField2;
private javax.swing.JTextField jTextField3;
private javax.swing.JTextField jTextField4;
private String protocolo;
private String porta;
private String ip;
private String ttl;
private BufferedWriter arq;
private javax.swing.JTextPane status;
private Panel painel;
private JFrame f;
private Image img;
}
Janela.java
88
/** PACOTE PRINCIPAL*/
package transmissor_furgtv;
/** BIBLIOTECAS */
/** Pacote IO */
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.File;
import java.io.FileReader;
89
JPanel panel_sobre = new JPanel();
JPanel panel = new JPanel();
JPanel panel_texto = new JPanel();
JPanel panel_menu = new JPanel();
JPanel panel_equipe = new JPanel();
90
if ( result == JFileChooser.APPROVE_OPTION ) /** se usuario escolheu um arquivo */
{
URL mediaURL = null;
Format fmt = null;
try
{
/** obtm o arquivo como URL */
mediaURL = fileChooser.getSelectedFile().toURL();
final MediaLocator m = new MediaLocator(mediaURL);
int x = 0, y = 0;
y = 0;
while ((linha[x] != ' ')&&(y!=15))
{
protocolo[y] = linha[x];
x++;
y++;
}
x++;
y = 0;
while ((linha[x] != ' ')&&(y!=15))
{
porta[y] = linha[x];
x++;
y++;
}
x++;
y = 0;
while ((linha[x] != ' ')&&(y!=15))
{
ip[y] = linha[x];
x++;
y++;
}
x++;
y = 0;
while ((linha[x] != ' ')&&(y!=15))
{
ttl[y] = linha[x];
x++;
y++;
}
91
final String PORTA = String.valueOf(porta).trim();
f.setVisible(false);
}
catch (IOException e) {System.err.println( "Erro: Arquivo no encontrado!" ); e.printStackTrace();}
92
texto.setFont(new Font("sansserif", Font.BOLD, 17));
texto.setEditable(false);
cor = Color.black;
texto.setBackground(cor);
cor = Color.white;
texto.setForeground(cor);
93
/** Textos de Ajuda dos Botes */
botao1.setToolTipText("Clique neste boto para inserir um novo vdeo de streaming");
botao2.setToolTipText("Clique neste boto para fechar o programa");
f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
f.setSize(700,250); /** configura o tamanho do frame */
f.setVisible( true ); /** exibe o frame */
f.setResizable(false);
f.setTitle("FURG TV na Internet");
}
}
Transmissor.java
/** PACOTE PRINCIPAL*/
package transmissor_furgtv;
/** BIBLIOTECAS */
/** E/S */
import java.io.*;
/** Rede */
import java.net.InetAddress;
94
/** RTP */
import javax.media.rtp.*;
import javax.media.rtp.rtcp.*;
/** PORTA */
private int porta;
/** TTL */
private int t;
/** PROCESSOR */
private Processor processor = null;
f = new JFrame();
f.setBackground(Color.DARK_GRAY);
f.setForeground(Color.WHITE);
//f.setIconImage(img);
f.setSize(300,100);
95
f.add(painel);
f.setTitle("Servidor de Streaming - FURG TV");
f.setDefaultCloseOperation(f.EXIT_ON_CLOSE);
f.setIconImage(icone);
f.show();
this.locator = locator;
this.IP = ip;
this.t = Integer.valueOf(TTL).intValue();
this.porta = Integer.valueOf(pb).intValue();
try
{
Float h = new Float(String.valueOf(horas));
Float min = new Float(String.valueOf(minutos));
Float sec = new Float(String.valueOf(segundos));
System.out.print(tempo + "milisegundos)");
Thread.currentThread().sleep(tempo);
}
catch (InterruptedException ie) {ie.printStackTrace();}
//DADOS ESTATISTICOS
System.out.println("Bytes Recebidos - " + rtpMgrs[0].getGlobalReceptionStats().getBytesRecd());
System.out.println("Bytes Transmitidos - " + rtpMgrs[0].getGlobalTransmissionStats().getBytesSent());
System.out.println("Pacotes RTCP recebidos - " + rtpMgrs[0].getGlobalReceptionStats().getRTCPRecd());
System.out.println("Pacotes RTCP transmitidos - " + rtpMgrs[0].getGlobalTransmissionStats().getRTCPSent());
System.out.println("Pacotes SR recebidos - " + rtpMgrs[0].getGlobalReceptionStats().getSRRecd());
System.out.println("Pacotes RTP transmitidos - " + rtpMgrs[0].getGlobalTransmissionStats().getRTPSent());
System.out.println("Pacotes em loop - " + rtpMgrs[0].getGlobalReceptionStats().getPacketsLooped());
System.out.println("Falhas na Transmisso - " + rtpMgrs[0].getGlobalReceptionStats().getTransmitFailed());
System.out.println("Pacotes Bye mal formados - " + rtpMgrs[0].getGlobalReceptionStats().getMalformedBye());
System.out.println("Pacotes RR mal formados - " + rtpMgrs[0].getGlobalReceptionStats().getMalformedRR());
System.out.println("Pacotes SDES mal formados - " +
rtpMgrs[0].getGlobalReceptionStats().getMalformedSDES());
System.out.println("Pacotes SR mal formados - " + rtpMgrs[0].getGlobalReceptionStats().getMalformedSR());
96
System.out.println("============= FIM DE TRANSMISSO ===============");
System.exit(0);
}
/** CRIA UMA SESSAO RTP PARA TRANSMITIR A SAIDA DO processor PARA O IP E PORTA */
result = createTransmitter();
if (result != null)
{
processor.close();
processor = null;
return result;
}
/** INICIA A TRANSMISSAO = start()*/
processor.start();
status2.setText("STATUS: Transmitindo....");
synchronized (this)
{
if (processor != null)
{
processor.stop();
processor.close();
processor = null;
97
private String createProcessor()
{
if (locator == null)
return "ERRO: locator null!";
DataSource ds;
DataSource clone;
Format supported[];
Format chosen;
boolean atLeastOneTrack = false;
if (tracks[i].isEnabled())
{
supported = tracks[i].getSupportedFormats();
if (supported.length > 0)
{
if (supported[0] instanceof VideoFormat)
{
/** CHECA O TAMANHO PORQUE NEM TODOS OS FORMATOS FUNCIONAM
COM TODOS OS TAMANHOS*/
chosen = checkForVideoSizes(tracks[i].getFormat(), supported[0]);
}
else
chosen = supported[0];
tracks[i].setFormat(chosen);
System.out.println("Trilha " + i + " setado para transmitir: " + chosen);
atLeastOneTrack = true;
}
else
tracks[i].setEnabled(false);
98
}
else
tracks[i].setEnabled(false);
}
if (!atLeastOneTrack)
{
//status2.setText("ERRO: Nenhuma trilha pde ser setada para um formato RTP vlido");
return "ERRO: Nenhuma trilha pde ser setada para um formato RTP vlido";
}
//System.out.println(dataOutput.getContentType());
return null;
}
/** USA O RTPManager PARA CRIAR UMA SESSAO PARA CADA MDIA (AUDIO E VIDEO) */
private String createTransmitter()
{
PushBufferDataSource pbds = (PushBufferDataSource)dataOutput;
PushBufferStream pbss[] = pbds.getStreams();
IP = IP.trim();
/** JPEG e H263, apenas funcionam para determinados tamanhos (verifica se tamanhos esto corretos novamente) */
Format checkForVideoSizes(Format original, Format supported)
{
99
int width, height;
Dimension size = ((VideoFormat)original).getSize();
Format jpegFmt = new Format(VideoFormat.JPEG_RTP);
Format h263Fmt = new Format(VideoFormat.H263_RTP);
if (supported.matches(jpegFmt))
{
/** Para JPEG, a largura e a altura devem ser divisiveis por 8 */
width = (size.width % 8 == 0 ? size.width : (int)(size.width / 8) * 8);
height = (size.height % 8 == 0 ? size.height : (int)(size.height / 8) * 8);
}
else /** Para H.263, apenas alguns tamanhos so suportados */
if (supported.matches(h263Fmt))
{
if (size.width < 128)
{
width = 128;
height = 96;
}
else
if (size.width < 176)
{
width = 176;
height = 144;
}
else
if (size.width > 400)
{
width = 800;
height = 600;
}
else
{
width = 352;
height = 288;
}
}
else
{
return supported;
}
return (new VideoFormat(null, new Dimension(width, height),
Format.NOT_SPECIFIED, null,
Format.NOT_SPECIFIED)).intersects(supported);
}
/** SETANDO A QUALIDADE DE CODIFICAO PARA 0.5 OU OUTRO VALOR (JPEG encoder) */
void setJPEGQuality(Player p, float val)
{
Control cs[] = p.getControls();
QualityControl qc = null;
VideoFormat jpegFmt = new VideoFormat(VideoFormat.JPEG);
100
Format fmts[] = ((Codec)owner).getSupportedOutputFormats(null);
for (int j = 0; j < fmts.length; j++)
{
if (fmts[j].matches(jpegFmt))
{
qc = (QualityControl)cs[i];
qc.setQuality(val);
System.out.println("Setando qualidade para " + val + " no " + qc);
break;
}
}
}
if (qc != null) break;
}
}
}
/** ESPERA ATE QUE CHEGUE UM EVENTO CONFIRMANDO O STATUS DO METODO (olhar classe
StateListener inner)*/
while (p.getState() < state && !failed)
{
synchronized (getStateLock())
{
try {getStateLock().wait();} catch (InterruptedException ie) {return false;}
}
}
if (failed) return false;
else return true;
}
101
}
}
}
}
Conexao.java
/** PACOTE PRINCIPAL*/
package transmissor_furgtv;
/** REDE */
import java.net.*;
/** RTP */
import javax.media.protocol.DataSource;
import javax.media.protocol.PushSourceStream;
import javax.media.protocol.ContentDescriptor;
import javax.media.protocol.SourceTransferHandler;
import javax.media.rtp.RTPConnector;
import javax.media.rtp.OutputDataStream;
/** Porta */
int port;
102
/** se inscreve no grupo multicast da trilha 0*/
dataSock0.joinGroup(this.addr);
dataSock0.setTimeToLive(TTL);
this.port = porta;
}
/** RETORNA UM input stream PARA RECEBER DADOS RTP da trilha 0*/
public PushSourceStream getDataInputStream() throws IOException
{
if (dataInStrm0 == null)
{
dataInStrm0 = new SockInputStream(dataSock0, addr, port);
dataInStrm0.start();
}
return dataInStrm0;
}
/** RETORNA UM output stream PARA ENVIAR DADOS RTP da trilha 0*/
public OutputDataStream getDataOutputStream() throws IOException
{
if (dataOutStrm0 == null) dataOutStrm0 = new SockOutputStream(dataSock0, addr, port);
return dataOutStrm0;
}
/** RETORNA UM input stream PARA RECEBER DADOS RTP da trilha 1*/
public PushSourceStream getControlInputStream() throws IOException
{
if (dataInStrm1 == null)
{
dataInStrm1 = new SockInputStream(dataSock1, addr, port+2);
dataInStrm1.start();
}
return dataInStrm1;
}
if (dataInStrm1 != null)
dataInStrm1.kill();
dataSock0.close();
dataSock1.close();
}
103
/** SETA O TAMANHO DO BUFFER DE RECEPO DO CANAL DE DADOS RTP. */
public void setReceiveBufferSize( int size) throws IOException
{dataSock0.setReceiveBufferSize(size); }
/** Uma classe inner para implementar um OutputDataStream baseado em Sockets UDP */
class SockOutputStream implements OutputDataStream
{
DatagramSocket sock;
InetAddress addr;
int port;
/**envia pacote*/
public int write(byte data[], int offset, int len)
{
try {sock.send(new DatagramPacket(data, offset, len, addr, port));}
catch (Exception e) {return -1;}
return len;
}
}
/** uma classe inner para implementar um PushSourceStream baseado em Sockets UDP.*/
class SockInputStream extends Thread implements PushSourceStream
{
DatagramSocket sock;
InetAddress addr;
int port;
boolean done = false;
boolean dataRead = false;
SourceTransferHandler sth = null;
104
/** cria socket de entrada */
public SockInputStream(DatagramSocket sock, InetAddress addr, int port)
{
this.sock = sock;
this.addr = addr;
this.port = port;
}
/** L pacote */
public int read(byte buffer[], int offset, int length)
{
DatagramPacket p = new DatagramPacket(buffer, offset, length, addr, port);
try {sock.receive(p);}
catch (IOException e) {return -1;}
synchronized (this)
{
dataRead = true;
notify();
}
return p.getLength();
}
public synchronized void start()
{
super.start();
if (sth != null)
{
dataRead = true;
notify();
}
}
public synchronized void kill()
{
done = true;
notify();
}
public int getMinimumTransferSize()
{
return 2 * 1024;
}
public synchronized void setTransferHandler(SourceTransferHandler sth)
{
this.sth = sth;
dataRead = true;
notify();
}
105
}
if (sth != null && !done) {sth.transferData(this);}
}
}
}
}
tempo.java
/** PACOTE PRINCIPAL*/
package transmissor_furgtv;
import java.awt.Image;
import java.awt.Toolkit;
import javax.media.MediaLocator;
//Inicializa atributos
video = v;
IP = i;
Porta = p;
TTL = t;
}
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
setTitle("Temporiza\u00e7\u00e3o");
jPanel1.setBackground(new java.awt.Color(0, 51, 102));
jPanel1.setBorder(javax.swing.BorderFactory.createLineBorder(new java.awt.Color(0, 0, 0)));
jPanel1.setToolTipText("Insira a dura\u00e7\u00e3o do v\u00eddeo em quest\u00e3o");
106
jLabel2.setText("Minutos");
jButton1.setText("OK");
jButton1.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton1ActionPerformed(evt);
}
});
jButton2.setText("Cancelar");
jButton2.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton2ActionPerformed(evt);
}
});
107
.addComponent(jLabel3))
.addGap(49, 49, 49)
.addGroup(jPanel1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELINE)
.addComponent(jButton1)
.addComponent(jButton2))
.addContainerGap(21, Short.MAX_VALUE))
);
javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane());
getContentPane().setLayout(layout);
layout.setHorizontalGroup(
layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
.addComponent(jPanel1, javax.swing.GroupLayout.PREFERRED_SIZE,
javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE)
);
layout.setVerticalGroup(
layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
.addComponent(jPanel1, javax.swing.GroupLayout.PREFERRED_SIZE,
javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE)
);
pack();
}
this.setVisible(false);
108
public static void main(String argv[])
{
/** cria o applet */
Applet principal = new PlayerApplet();
Receptor.java
/** PACOTE PRINCIPAL */
package receptor_furgtv;
/** BIBLIOTECAS */
/** E/S */
import java.io.*;
import java.io.FileReader;
/** GRAFICO */
import java.awt.*;
import java.awt.event.*;
/** REDE */
import java.net.*;
/** UTILIDADES */
import java.util.Vector;
import java.util.Properties;
/** Applet */
import java.applet.Applet;
/** Lang */
import java.lang.String;
/** Swing */
import javax.swing.*;
109
Label status;
SessionLabel session;
BufferControl bc = (BufferControl)mgrs[i].getControl("javax.media.control.BufferControl");
if (bc != null)bc.setBufferLength(350);
}
}
catch (Exception e)
{
status.setText("ERRO: Sintonizao mal sucedida!!");
System.err.println("ERRO: No foi possvel criar a sesso RTP: ");e.printStackTrace();
return false;
}
try
{
synchronized (dataSync)
{
while (!dataReceived && System.currentTimeMillis() - then < waitingPeriod)
{
if (!dataReceived)
{
System.out.println(" Esperando dados RTP...");
status.setText("Sintonizando canal FURG TV....");
}
dataSync.wait(1000);
}
}
}
catch (Exception e) {}
110
if (!dataReceived)
{
status.setText("ERRO: Canal fora do ar!");
System.err.println("Nenhum dado RTP foi recebido.");
close();
return false;
}
return true;
}
playerWindows.removeAllElements();
PlayerWindow find(Player p)
{
for (int i = 0; i < playerWindows.size(); i++)
{
pw = (PlayerWindow)playerWindows.elementAt(i);
pw.setTitle("FURG TV");
pw.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
status.setText("FURG TV");
Toolkit tk = Toolkit.getDefaultToolkit();
Image icone = tk.getImage("furg.gif");
pw.setIconImage(icone);
if (pw.p == p) return pw;
}
return null;
}
/** SessionListener*/
111
public synchronized void update(SessionEvent evt)
{
if (evt instanceof NewParticipantEvent)
{
Participant pa = ((NewParticipantEvent)evt).getParticipant();
System.err.println(" Um novo participante foi adicionado ao grupo: " + pa.getCNAME());
}
}
/** ReceiveStreamListener*/
public synchronized void update( ReceiveStreamEvent evt)
{
RTPManager mgr = (RTPManager)evt.getSource();
Participant participant = evt.getParticipant();
ReceiveStream stream = evt.getReceiveStream();
if (participant == null)
System.out.println(" O transmissor do stream deve ser identificado.");
else
{
System.out.println(" O stream vem de: " + participant.getCNAME());
}
p.addControllerListener(this);
p.realize();
pw = new PlayerWindow(p, stream);
playerWindows.addElement(pw);
112
catch (Exception e)
{
System.err.println("ERRO: NewReceiveStreamEvent exception " + e.getMessage());
return;
}
}
else
if (evt instanceof StreamMappedEvent)
{
if (ctl != null)
System.err.println(" " + ctl.getFormat());
System.out.println(" foi enviado por: " + participant.getCNAME());
}
}
else
if (evt instanceof ByeEvent)
{
if (pw != null)
{
pw.close();
playerWindows.removeElement(pw);
}
}
}
if (p == null)
return;
if (pw == null)
{
System.err.println("ERRO: problema interno!");
System.exit(-1);
}
status.setText("www.furgtv.furg.br");
pw.add("South",status);
pw.initialize();
pw.setVisible(true);
p.start();
}
113
{
p.removeControllerListener(this);
pw = find(p);
if (pw != null)
{
pw.close();
playerWindows.removeElement(pw);
}
System.err.println("ERRO: " + ce);
}
}
// se tem um endereo
off = session.indexOf('/');
if (off == -1)
{
if (!session.equals(""))
addr = session;
}
else
{
addr = session.substring(0, off);
session = session.substring(off + 1);
if (off == -1)
{
if (!session.equals(""))
portStr = session;
}
else
{
portStr = session.substring(0, off);
session = session.substring(off + 1);
// se tem um TTL
off = session.indexOf('/');
if (off == -1)
{
if (!session.equals(""))
ttlStr = session;
114
}
else
{
ttlStr = session.substring(0, off);
}
}
}
}
if (addr == null)
throw new IllegalArgumentException();
if (portStr != null)
{
try
{
Integer integer = Integer.valueOf(portStr);
if (integer != null)
port = integer.intValue();
}
catch (Throwable t)
{
throw new IllegalArgumentException();
}
}
else
throw new IllegalArgumentException();
if (ttlStr != null)
{
try
{
Integer integer = Integer.valueOf(ttlStr);
if (integer != null)
ttl = integer.intValue();
}
catch (Throwable t)
{
throw new IllegalArgumentException();
}
}
}
}
115
dispose();
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
PlayerPanel(Player p) {
setLayout(new BorderLayout());
if ((vc = p.getVisualComponent()) != null) add("Center", vc);
if ((cc = p.getControlPanelComponent()) != null) add("South", cc);
}
116
Integer p = Integer.valueOf(PORTA).intValue();p = p + 2;PORTA = String.valueOf(p);
sessao[1] = new String(IP+"/"+PORTA+"/"+TTL);
this.sessions = sessao;
if (!initialize()) {
System.err.println("ERRO: Sesses no inicializadas!");
System.exit(-1);
}
System.out.println("====== Cliente Sintonizado na FURGTV =====");
// Checa se acabou a recepo
try {while (!isDone()) Thread.sleep(2000000000);} catch (Exception e) {e.printStackTrace();}
System.out.println("============= FIM DE PROGRAMA ============");
System.exit(0);
}
}
117