A estrutura foi dividida em Encoder e Servidor de entraga do conteúdo. Para o encoder utilizei o Flash Media Encoder,para a parte de entrega de conteúdo foi um serviço contratado da LocaWeb.

A transmissão ocorreu perto das 19:00 horas, com origem em São Paulo capital e com os principais espectadores em Curitiba.

Os principais problemas foram:

• O não suporte ao H.264 pelo serviço de Flash Server disponibilizado pela Loca Web;
• O não suporte do Flash Media Encoder ao sistema operacional Mac OS X;
• Horário da transmissão;

Por não poder utilizar o H.264 tive que efetuar o encoder do vídeo utilizando o VP6, o resultado final foi um maior peso do vídeo e com isso a necessidade de um Link com maior capacidade.
Com relação ao encoder, o problema é a plataforma, tive instabilidades com o Windows, o Flash Media Encoder fechava sem nenhum motivo aparente, ou não fazia o streaming, somente no último minuto antes da transmissão ele estabilizou (foi um sufoco).
Com relação ao horário o impacto é o trafego da Internet no Brasil, aconpanhei através do site da RNP que o horário escolhido pelo pessoal organizador do evento era justamente o horário de pico da Internet do Brasil, não somente por esse problema, mas também por problemas de estreitamento de banda no local do evento, tive problemas com a “up” do conteúdo até a Loca Web.

Mas no final deu tudo certo, a transmissão durante todo o evento não teve problemas de instabilidade, o antes foi muito complicado, o durante e depois fui super tranquilo.

Poderia ter utilizado o Red5, mas o meu principal problema foi conseguir uma documentação explicando como fazer a instação no centOS e a minha falta de tempo. Por esses motivos utilizei o Flash Media da Loca Web, supriu as minhas necessidades.

A aplicação client foi desenvolvida por mim e pela equipe de desenvolvimento web da empresa, utilizando o Adobe Flex 3, a base do código foi o programa postado aqui no blog.

http://fabiotomio.wordpress.com/2008/06/25/adobe-flex-red5-e-streaming/

Qual o meu parecer?

Transmissão utilizando a Internet é extremamente complexa, existem inúmeros fatores que podem afetar a transmissão, não somente sua aplicação ou mesmo o seu serviço de entrega utilizado. A tecnologia em sí e forma de entrega são sim os principais focos na hora de projetar uma transmissão, mas não se pode esquecer os outros fatores que são importantes também, como:

• A entrega dos sinais será feita como? Há a necessidade de um conversor de mídia?
• O audio? como será entregue? há um sistema de compressão de audio? Clips (Overload) no audio geram instabilidades.
• Qual a tecnologia utilizada para acesso a Internet? É estável? ADSL, Fibra, Frame-Relay, Radio? Mais instavel maior a necessidade da largura.
• Nunca utilizar 100% do Link disponível, se necessário diminua a qualidade do vídeo! Existem muitos picos durante a transmissão, se não existir banda disponível há perda de sincronismo.

• Qual o seu público? Onde ele está? Quanto mais proximo a origem da transmissão melhor.
• Qual a distância da origem do sinal e do servidor que irá distribuir o conteúdo? Quanto mais próximo melhor!

Esses são alguns pontos importantes e que devem ser levados em consideração.

As duas últimas questões levam em conta que existam gargalos de comunicação entre uma região e outra. Por exemplo, se o o conteúdo for trafegar na Internet existem diferentes tecnologias de comunicação para entregar a Internet no Brasil, por exemplo, Paraná – São Paulo, o link é DWDM de 2.5 Gps já São Paulo com Manaus são 20 Mbps. Mais informações em RNP. Uma alternativa a esse problema é locar uma rede terceira para trafegar seu conteúdo.

Próxima etapa:

Setembro está chegando e lá vou eu de novo, dessa vez vou mudar muita coisa, ou quase tudo, vou migrar do Flash pro QuickTime, o servidor de streaming do QuickTime tem ume versão Open Source, mais conhecida como Darwin, tem muitos recursos e o melhor, dá suporte ao H.264.

Adicionei mais uma camada para a entrega do conteúdo, é um serviço que faz cache do conteúdo e utiliza rede própria para trafegar o conteúdo, e faz a entrega do conteúdo utilizando várias conexões simultâneas, sabe o superdownload ou getright? é o mesmo conceito, só que em vez de ser na aquisição do conteúdo, é na entrega. Este serviço é utilizado pelos maiores sites e portais do mundo, como Apple, Adobe, CNN, etc. Segue abaixo uma imagem exemplificando o funcionamento. Quem fornece esse serviço no mundo é a Akamai, seu representante no Brasil é a Exceda.

Estou efetuando testes, sem o serviço da Akamai a princípio, procurando o melhor configuração entre qualidade do vídeo e consumo de banda, essa semana ainda começamos os testes com a Akamai distribuindo o conteúdo.

Vamos ver os resultados, para quem quizer fazer testes com o QuikTime/Darwin, os sites são:

Darwin

Instalar Darwin on centOS

Assim que tiver outras novidades posto aqui…

Abraços a todos, e se pintar alguma dúvida, é só enviar um email para fabiotomio@gmail.com

Links:

• http://www.adobe.com/products/flashmediaserver/flashmediaencoder/
• http://www.locaweb.com.br/flashcom/default.asp
• http://www.rnp.br/backbone/index.php
• http://www.akamai.com
• http://exceda.com
• http://developer.apple.com/opensource/server/streaming/index.html
• http://streaming411.com/wiki/Darwin_Streaming_Server

Ainda lembro a minha primeira quase “transmissão” de um evento pela Internet, um festival de dublagem na minha cidade natal (litoral do Paraná) em meados de 1997/1998, o objetivo era enviar para o site do colégio imagens das apresentações. Na época a conexão mais rápida era de 56Kbps, é isso mesmo, linha discada, um modem externo US. Robotics que se conectava com o PC pela porta paralela, um servidor Linux para compartilhamento da conexão. Conexões USB`s não eram muito utilizadas, a Web Cam utilizava a interface paralela e também a conexão do teclado, nem perto da qualidade da imagem das Web Cams atuais. Bom, com toda essa limitação tecnológica e os meus 15 anos o que consegui foi, fazer capturas das apresentações utilizando a Web Cam, (demorava um bocadinho), e com um programa FTP eu enviava essas imagens para o host onde o site do colégio estava hospedado. Só foi possível porque o software de captura da câmera podia ser configurada para capturar as imagens quando detectava movimento, e o software FTP possibilitava o agendamento de upload toda vez que um arquivo era modificado. Foi divertido, um desafio, que foi solucionado com o pouco conhecimento e os poucos recursos disponíveis na época.

Por que tudo isso?

Em um passeio para ir pegar café, e dar um out do computador pra respirar um pouco, fui informado que o próximo evento da empresa que será em setembro será transmitido pela Internet, e que a responsabilidade de levantar o Know How estava nas minhas mãos. Gostei, mais um desafio para ser superado, e mais conhecimento para ser adquirido. Voltei pra minha mesa já pensando em mil possibilidade e entendendo a complexidade de concretizar tudo isso.

Realidade

Muitas pessoas já pensaram, é fácil, mas vamos a realidade, fatos que devemos levar em consideração:

• A captura da imagens é feita em HD (High Quality), 1080p pra ser mais preciso;
• O evento não tem um local fixo para acontecer;
• Levar em consideração a possibilidade de envio de audio/vídeos simultâneos (vários “canais”);
• Prever como enviar ao servidor de Streaming o conteúdo (acesso à Internet);
• A mesa de corte utilizada não possui saida de vídeo em FireWire, somente em Y,B,R e SDI;
• Custos tendendo a zero, principalmente no que se diz respeito à Infra-estrutura e Softwares.

Tecnologia

Levando em consideração esses pontos semana passada, mais exatamente na quinta-feira comecei um estudo sobre transmissão de audio/vídeo utilizando FMS (Flash Media Server), já tinha visto a algum tempo o RED5 (osflash.org/red5) achei interessante pois é Open Source (custos reduzidos) e utilizando o Java, é possivel criar os serviços e mais, montar serviços que interajam com outras aplicações, interfaces, dispositivos, tudo que o Java possibilita, isso é interessante quando se precisa de flexibilidade, característica essa que o Open Source carrega no sangue.

Comecei o estudo, baixei sua versão para o MAC OSX, e instalei. Sua instalação no Mac é simples, não tive problemas, o RED5 vem com uns demos, todos funcionaram perfeitamente. Bom o servidor estava rodando, agora faltava a aplicação.

Para a construção das aplicações decidí utilizar o Adobe Flex 3, pois já desenvolvo aplicações com ele a algum tempo, isso facilita bastante =). Não achei muita documentação do RED5 e o Flex, foi dificil fazer com que a aplicação conversasse com o RED5, mas funcionou. Primeiramente tentei reescrever as classes que vieram nos exemplos do RED5 de (Flash) ActionScript2 para (Flex) ActionScript3, foi sinistro e frustrante, dai pesquisando um pouco mais, consegui somente a classe de conexão pro RED5 em ActionScript3 (http://www.vadus.de/uni/red5/AS_red5_Connection.zip). Foi aí que a conexão funcionou.

Transmissão

Com a conexão em pé era a hora de tentar enviar o vídeo, trabalhar com as classes Video, Camera, NetStream no Flex não foi tão complicado, o Google ajudou bastante, foi atravéz dele que cheguei ao site www.rafaeldohms.com.br muito bom o artigo, e o Source Code disponibilizado pelo Rafael me ajudou muuuuito. Utilizei o código do Rafael como base pra montagem da classe de envio de recepção de audio/vídeo.
Mas faltava uma coisa ainda, o serviço no RED5 que ficaria responsável recebimento e distribuição do audio/vídeo. Tentei algumas vezes montar um novo serviço, sem sucesso. Foi então que tive a brilhante, ou nem tão brilhante idéia de utilizar o serviço da apicação demo. Um Chat com Vídeo que vem junto com o RED5. Depois de ler e re-ler o Java do serviço identifiquei o funcionamento do serviço e consegui enviar o conteúdo. Utilizei a própria interface do chat pra ver o resultado da transmissão. Faltava a última coisa agora, a parte de recepção do conteúdo. Essa não foi tão difícil, mais um pouco de leitura do Java do serviço do RED5 e, pronto, funcionando.

Testes

Testes de preformance e consumo de banda, na rede da minha casa, apontaram uma boa qualidade e um consumo de banda próximo a 250Kbps, isso efetuando a transmissão de uma camera (Web Cam) com audio. Mais testes, dessa vez na empresa, conectei uma camera de vídeo no meu note utilizando a interface FireWire, o sinal que estava sendo injetado era HDV, 60fps, [16:9]. O Flash Player não detectou o sinal, tive que configurar a camera pra DV, 60 fps, 16:9, menos qualidade, e o Flash Player detectou. Comecei as transmissões, não sei se é pelo fato da minha aplicação pegar a imagem gerada pela câmera e reduzir o tamanho dela, mas a imagem ficou bem ruim, o interlaçado quando o movimento era rápido, era mais do que visível. Fiz vários testes esperimentando reconfigurar o FPS da aplicação, o Bandwidth, a qualidade do vídeo, o Frame Interval, e quando cheguei a um resultado satisfatório, fui verificar a utilização da banda. É definitivamente não vai dar pra utilizar o RED5. Se fosse uma Web Cam as coisas já estariam resolvidas, mas como a realidade é outra, vou ter mais trabalho pela frente.

Encoder

Comecei pesquisas sobre a utilização de um Encoder no RED5 e ví que não é possivel a utilização de um.
Vou seguir com o projeto e pesquisar agora o Flash Media Server (Adobe) e o Wonza Media Server (Wonza) esses possibilitam a utilização de um Encoder.

Código

Vou disponibilizar o código das aplicações pro pessoal que precisar montar uma aplicação Flex utilizando recursos de audio/vídeo e o RED5, como por exemplo um software de Vídeo conferência. Eu montei a aplicação pra suportar vários streams, a qualidade é setada toda na aplicação, dando flexibilidade pra configurar como quizer.

Vai aqui o meu agradecimento ao Rafael por disponibilizar o conteúdo da aplicação dele, achei uma ótima iniciativa e seguindo este exemplo, também vou disponibilizar os códigos.

Abraços a todos…. qualquer dúvida estou a disposição…. fabiotomio@gmail.com

Source Code

Links:

http://osflash.org/red5

http://www.adobe.com/products/flashmediaserver/

http://www.rafaeldohms.com.br/pt/

http://www.wowzamedia.com/