FURGTV: Streaming Vídeo via Multicast

Este trabalho apresenta a proposta do desenvolvimento de uma ferramenta que disponibilize a televisão local da Fundação Universidade Federal do Rio Grande na Internet, através de streaming de vídeo e áudio via uma rede multicast.

por Rafael Vieira Coelho

Rafael V. Coelho
Fundação Universidade Federal do Rio Grande (FURG) – Rio Grande - RS
rafaelvc2@gmail.com

Resumo. Este trabalho apresenta a proposta do desenvolvimento de uma ferramenta que disponibilize a televisão local da Fundação Universidade Federal do Rio Grande na Internet, através de streaming de vídeo e áudio via uma rede multicast. Todos os principais fatores necessários para o desenvolvimento desta ferramenta serão esclarecidos ao decorrer do artigo. Também será especificada a arquitetura do sistema a ser desenvolvido.

1. INTRODUÇÃO

O modelo utilizado na televisão atualmente está preste a sofrer uma metamorfose bastante relevante, devido às suas limitações. A forma de transição provavelmente será consolidada como digital, substituindo a atual que é analógica. Isto se deve a alguns fatores como melhor definição e maior número de canais disponibilizados.

Além disso, a transmissão de conteúdo multimídia ao vivo vem crescendo com a popularização dos links de banda larga. Cada vez mais este tipo de transmissão se torna comum ao dia-a-dia dos usuários na Internet [1]. Com a televisão na Internet, o usuário solicita algum programa de seu interesse e não precisa ser escravo da programação pré-definida pelas estações corporativas. A maioria das televisões disponibilizados na Internet, hoje em dia, consiste em um decodificador de sinal capturando sinal de TV e retransmitindo-o para a web através de um servidor de streaming.

Para disponibilizar um canal de TV através da Internet com capacidades plenas, deverá ser implementado a capacidade de streaming via Multicast [2] no qual a comunicação é feita de um transmissor para múltiplos receptores.

Como o endereçamento Multicast permite enviar pacotes IP para um determinado grupo de usuários, estes devem estar cadastrados previamente no grupo (identificado por um 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 estações devem utilizar o protocolo IGMP (Internet Group Management Protocol). A diferença do Multicast para unicast e broadcast está no roteamento dos pacotes que serão enviados do transmissor para os receptores.

Existem alguns protocolos de roteamento para fazer isso, como, por exemplo, o DVMRP (Distance Vector Multicast Routing Protocol), o MOSPF (Multicast extensions to Open Shortest Path First) e o PIM (Protocol-Independent Multicast), usados para troca de informações entre os roteadores e definição de quais rotas os pacotes deverão seguir.

2. STREAMING

Há algum tempo atrás, executar um arquivo de vídeo, ou seja, assistir um pequeno clip na Internet, significava um longo período de download. Então, levantou-se a possibilidade de reproduzir o vídeo desejado antes mesmo que todo o arquivo fosse gravado localmente. Assim, nasceu a Tecnologia de Streaming, que é um misto de técnicas de compressão e armazenamento em memória temporária (buffering). Ela permite a transmissão de vídeo em tempo real através da Internet.

Na tecnologia streaming, começa a ser exibido qualquer tipo de imagem ou som antes mesmo que o arquivo seja copiado totalmente para o computador local. Isto reduz a espera inicial a poucos segundos, um tempo relativamente razoável para o contexto atual da Internet.

Nas transmissões streaming, a ordem de chegada dos pacotes contendo unidades de um arquivo é fundamental, pois a visualização ou execução do conteúdo do arquivo se inicia antes do término da transmissão. Alguns pacotes podem ser descartados, sendo praticamente imperceptível ao olho humano.

A comunicação entre clientes e servidor apenas se torna possível quando é utilizada uma série de protocolos de transmissão multimídia de tempo real que ditam as regras de controle de tráfego, tipo de comunicação, etc. O principal exemplo deste tipo de protocolo é o RTP (Real-time Transport Protocol) [3] , o qual especifica um formato para transmissão de dados em tempo real, tais como áudio, vídeo ou dados. Através deste protocolo pode ser obtida a detecção de perda de pacotes. Isto é possível através dos números de seqüência dos pacotes.

Além disso, são feitas a sincronização intermídia e intramídia. O campo de timestamp do cabeçalho informa ao receptor o momento exato de passar os dados ao usuário. Essa informação é usada pelo receptor absorver o jitter da rede através de um buffer auxiliar. Este campo também é usado em conjunto com o protocolo NTP (Network Time Protocol) a fim de sincronizar as diferentes mídias, permitindo ao receptor a adaptação ao skew.

O RTP utiliza o RTCP para monitorar a qualidade de serviço e repassar informações sobre os participantes de uma sessão em andamento. Em termos do modelo OSI [4], o RTP se situa acima do nível quatro, no subnível inferior do nível de aplicação, como mostra a figura a seguir. O IP pode ser tanto unicast como multicast, e o protocolo de nível dois (Ethernet) é apenas um exemplo.

O vídeo, depois de carregado pelo servidor, deve ser divido em pacotes de bytes que então irão passar por um processo de compressão, o que diminui seu tamanho, tornando assim viável a transmissão destes pela rede. No receptor, os pacotes são reordenados, descomprimidos e reconvertidos ao estado original, normalmente com perdas inseridas no processo de compressão.

3. MULTICAST

A transmissão de pacotes por multicast compõe uma solução alternativa ao excesso de tráfego redundante de pacotes. Multicasting é um método ou técnica de transmissão de um pacote de dados para múltiplos destinos ao mesmo tempo. Durante este tipo de transmissão, o servidor envia os pacotes e depende dos receptores a captura da transmissão e partir disto, sua reprodução.

O endereçamento multicast é caracterizado por IPs classe D. Ou seja, são reservados para comunicação multicast os IPs de 224.0.2.0 até 238.255.255.255. Os endereços reservados para protocolo de roteamento, descobrimento de topologia, etc. estão na faixa de 224.0.0.0 até 224.0.0.255. Já em aplicações desenvolvidas para criar um novo tipo de protocolo deve-se utilizar a faixa 224.0.1.0 até 224.0.1.255. Os endereços IPs restantes da classe D são reservados para fins administrativos (239.0.0.0 até 239.255.255.255).

Em termos de qualidade de serviço (QoS), uma transmissão multicast é tratada da mesma forma que unicast, ou seja, possui as mesmas características de "melhor esforço" do IP unicast, sofrendo as mesmas políticas de controle de acesso e conformação de tráfego.Como a transmissão multicast possui o mesmo cabeçalho IP do unicast, os métodos de garantia de qualidade de serviço são os mesmos, e ambos podem usar diffserv, RSVP, MPLS, entre outros.

A diferença entre o multicast e o unicast está no roteamento dos pacotes, pois vai exigir uma certa inteligência do roteador para saber por quais portas existem usuários cadastrados em grupos, fazendo com que ele replique os pacotes multicast por todos os caminhos que possuem receptores. Existem alguns protocolos de roteamento para fazer isso, como, por exemplo, o DVMRP (Distance Vector Multicast Routing Protocol), o MOSPF (Multicast extensions to Open Shortest Path First) e o PIM (Protocol-Independent Multicast), usados para os roteadores se conversarem entre si e descobrirem por quais rotas devem ser encaminhados os pacotes.

O transmissor gera um fluxo de pacotes IP multicast, que distribui para todas suas portas (inclusive a do roteador). Os clientes cadastrados no grupo multicast pegam a informação e a apresentam na tela. O roteador, por sua vez, verifica se tem alguma de suas portas com clientes cadastrados no grupo multicast. Caso tenha, envia um fluxo multicast para essa porta.

No nosso caso: um canal de televisão sendo transmitido para vários clientes por um servidor de vídeo, multicast é a solução ideal, pois diminui significantemente o tráfego.

4. ARQUITETURA PROPOSTA

Para isto, serão implementados dois módulos em Java [5]: servidor e cliente. Primeiramente, o aplicativo servidor abrirá o arquivo de vídeo e começará a transmitir via multicast pela rede. Para isto, o arquivo de vídeo é divido em um vetor de bytes que é encapsulado à medida que é enviado. Estes bytes são agrupados em um pacote RTP que é transmitido via UDP pela rede. Após é criado um loop que espera conexões via socket[6].

Os recursos fundamentais de redes em Java são proporcionados pelo pacote java.net, pelo qual é disponibilizada a comunicação baseada em fluxos. Isto significa que os aplicativos podem visualizar as redes como fluxos de dados. Além disso, este pacote também proporciona a visão de comunicação baseada em pacotes, o que proporciona a aplicações a possibilidade de transmissão de pacotes individuais, normalmente utilizados para a transmissão de vídeo e áudio pela Internet. Através dos sockets (também disponibilizado pelo Java.net), um processo pode estabelecer uma conexão com outro. E faz tamanha abstração a ponto de que a rede seja vista como uma E/S de um arquivo, porque um programa pode ler ou escrever em um socket como o faz com um arquivo. Mas ao invés de salvar localmente o arquivo, esse fluxo é enviado até outro processo. No caso de streaming, é utilizado sockets de datagrama, que utiliza o protocolo de transporte UDP (User Datagram Protocol) que faz uso de um serviço sem conexão. Ou seja, não garante que os pacotes enviados chegarão e que chegarão na ordem certa. Sendo assim, não bloqueante e mais veloz. Este tipo de conexão pode ser comparada com o serviço postal. A maneira como o correio envia suas cartas se assemelha bastante ao modo de comunicação UDP. Como pode ser visto na figura abaixo, é necessário fazer um bind para associar um socket a uma porta.

Quando alguma requisição for recebida, será disparada uma thread para adicionar o cliente em questão no grupo e fazer todos o controle necessário para a permanência dele através da sessão. Também será implementado um controle da largura de banda para que no momento da distribuição do vídeo para os clientes, não ocorra sobrecarga nem lentidão em demasia.

O cliente será um JSP (Java Server Page) que rodará embutido no servidor Tomcat [7].

O Tomcat é um servidor de aplicações Java para web. É distribuído como software livre e desenvolvido como código aberto dentro do conceituado projeto Apache Jakarta e oficialmente endossado pela Sun como a Implementação de Referência (RI) para as tecnologias Servlet e JSP. É robusto e eficiente, podendo ser utilizado mesmo em um ambiente de produção. O Tomcat tem a capacidade de atuar também como servidor web/HTTP, ou pode funcionar integrado a um servidor web dedicado como o Apache httpd ou o Microsoft IIS.

Os JSPs simplificam o fornecimento de conteúdo Web dinâmico. Com este, além de poder utilizar componentes pré-definidos em Java, também pode ser utilizadas as facilidades de script no lado servidor. Quando um servidor com JSP recebe a primeira solicitação para um JSP, o contêiner de JSP traduz JSP em um servlet [8] Java que trata a solicitação atual e as futuras solicitações para o JSP. O texto literal em um JSP torna-se literais de string no servlet que representa o JSP traduzido. Todo erro de compilação no servlet criado resulta em erro em tempo de tradução. Caso ocorram erros após a compilação, estes são chamados de erros em tempo de solicitação.

A arquitetura descrita acima pode ser mais bem observada na figura abaixo. Parte-se do pressuposto de que o cliente A não fez solicitação alguma e que o Cliente B já faz parte do grupo multicast em questão. O que é de grande valia é a seqüência de acontecimentos decorrentes do acesso do Cliente C a página JSP. A partir deste momento, o JPS cria uma conexão via socket com o Servidor de Streaming que, por sua vez, dispara uma thread e adiciona o Cliente C ao grupo atual de transmissão.

O Java Server Page será disponibilizado através de um link na página da FURG TV (www.furgtv.furg.br). Após fazer a solicitação de conexão por uma porta em um socket, é utilizado uma primitiva receive(), esperando assim a transmissão dos dados. Após o final da transmissão, o servidor fechará a conexão, terminando assim a sessão. Desta maneira, será disponibilizado o canal de televisão da Universidade Fundação Universidade Federal do Rio grande via streaming na Internet.

5. CONCLUSÃO

Tendo em vista todos os dados demonstrados neste artigo, pode-se verificar todas as facilidades disponibilizadas pela comunicação multicast na comunicação entre grupos de redes diferentes para a troca de dados, áudio e vídeo. Sendo assim, todo o desenvolvimento do aplicativo que disponibilizará a televisão da universidade na Internet será baseado na comunicação multicast e nos protocolos envolvidos neste tipo de comunicação.

A intenção deste trabalho é ser de real utilidade para o futuro e não mais um projeto de pesquisa sem fim pré-definido. O objetivo principal é que a televisão local da Universidade Federal do Rio Grande funcione plenamente via Web e que testes sejam realizados no final da implementação do mesmo no PlanetLab [9].

O PlanetLab funciona como uma camada externa, apoiada sobre a Internet atual. É uma rede aberta e escalável com nodos em várias partes do Mundo, com o intuito de ser um laboratório global para testes mais amplos e reais de protocolos inovadores que poderão revolucionar a Internet atual. É importante que se consiga estabilidade e taxas de transmissão razoáveis na transmissão de vídeo e áudio.

A combinação dos dois meios de comunicação mais conhecidos e divulgados no Mundo será o futuro das redes de comunicação para a troca de dados segura e mais rápida e seletiva possível. A idéia da transmissão de vídeo via multicast vem crescendo absurdamente nos últimos anos e, com certeza, é uma tecnologia que estará concretizada no mercado em um futuro próximo.

Um dos fatores que facilitou esse crescimento foi à disseminação da banda larga no mercado, tornando assim possível à transmissão de vídeo sob a Internet. A união entre a televisão e a Internet irá revolucionar o modo como as pessoas vêem o Mundo e como as informações são repassadas para as mesmas.

REFERÊNCIAS

[1] FINZSCH, P., ROESLER, V. "Análise do mecanismo de pares de pacotes para inferência de banda máxima em redes de computadores". UNISINOS - Universidade do Vale do Rio dos Sinos, Centro de Ciências Exatas e Tecnológicas, junho de 2003.

[2] Gouveia Costa D. "Comunicações Multimídia na Internet - Da Teoria à Prática". Ciência Moderna.

[3] SHULZIRINNE, CASNER, FREDERICK, JACOBSON. "RTP: A Transport Protocol for Real-Time Applications". Columbia U. Internet Engeneering Task Force, maio de 2002.

[4] TANENBAUM A. (2003). "Redes de Computadores". Campus, Edição 4.

[5] http://java.sun.com

[6] DEITEL H., DEITEL P. (2005). "Java: Como Programar". Prentice-Hall, Edição 6.

[7] Goodwill J. "Apache Jakarta-Tomcat". Apress, 2001.

[8] Hunter J. "Java Servlet Programming, 2nd Edition". O"Reilly Media, Inc.

[9] http://www.planet-lab.org