WebMedia

Na semana passada a Adobe soltou alguns dados dos benchmarks que realizou na sua nova versão do Flash Media Server 3.0, para quem não sabe este é o software da Adobe que concorre com Windows Media Services e com o Real Server, além de ter ainda o Darwin Streaming Server e o Helix Server como opções open source.

A diferença entre todos estes softwares é grande e todos tem pontos positivos, negativos e peculiaridades, e não é o foco deste post fazer esta comparação. O grande fato é que o FMS3 é a grande aposta da Adobe para disseminar ainda mais o formato Flash Video, principalmente no segmento em que ela é mais fraca, transmissões ao vivo. Recentemente o Yahoo se juntou a diversas outras Start Ups (JustinTV, UStream, BlogTV, LiveUniverse, Mogulus, etc) e lançou seu produto de self-broadcast chamado Yahoo Live!, que é baseado no FMS.

Outra grande preocupação com o software da Adobe é o suporte ao sistema operacional Linux, na versão 2.0 do FMS a performance quando rodando no Linux era bem sofrível e notadamente inferior a versão Windows rodando no mesmo hardware, o que geralmente não se observa em nenhum outro software.

Enfim, parece que a Adobe acertou os ponteiros e finalmente deu um pouco de prioridade a versão do FMS para o Linux, segue um resumo do resultado do benckmark do novo FMS 3.0 em comparação com a versão 2.0 rodando no mesmo hardware

• 200% de melhora no Windows 2003 (SP1; Standard) na distribuição Live e VOD
• No Linux, melhora de mais 300% em performance.
• 20% CPU no Linux são suficientes para distribuir 1Gbps de tráfego.
• Ao usar o RTMPE ou RTMPS (novo protocolo de streaming da Adobe para conteúdo Encriptado) adiciona em torno de 10% to the CPU, o que é BEM razoável.

Claro que nem tudo são maravilhas, a Adobe acabou dividindo seus produtos de servidor de media e agora há duas opções: o Flash Media Interactive Server e o Flash Media Streaming Server, sendo este segundo uma versão “capada”, onde não é possível escalar a infra estrutura com servidores de borda(edge) e origem, por isso ela conseguiu reduzir o preço do FMS em 80% mas mantendo o preço do FMIS.

Outro dado interessante é que o FMS3 agora suporta encriptação através do RTMPE e RTMPS (com suporte a SSL) e controle de acesso aos conteúdos que distribui e adicionalmente a estas características quando o Flash Player acessa um conteúdo distribuído através de um destes dois protocolos ele não faz cache local, o que dificulta o acesso ao arquivo fisicamente, como acontece ao se usar o HTTP progressive download.

Hoje foi mais um dia batendo cabeça com a Osprey e a snapshot e o programa de flash ao vivo.

A Osprey precisa de um driver especial que só funciona no kernel 2.6.9, mas não houve esforços pra migrar esse driver para as versões mais novas.

Esse kernel gerou um problema que eu nunca pude esperar que fosse acontecer, ele requer que um unnamed fifo (aquele que a gente cria usando a função pipe()) requer um reader e um feeder síncronos, e eu usava esse esquema de forma assíncrona, por exemplo.

for (;;) { write(fifo); read(fifo); }

No kernel 2.6.9 eu tenho que ter threads distintas para realizar essa função, o que me obrigou a mudar o programa que já estava funcionando para embutir 1 thread só pra ficar gravando no pipe pra eu poder funcionar como eu já funcionava antes com o kernel 2.6.20. Assim, ficou algo do tipo:

thread1: for (;;) { write (fifo); }

thread2: for (;;) { read (fifo);}

A alteração funcionou como esperado, não tive mais problemas. A única coisa que aconteceu com a mudança da PixelView para a Osprey é que a imagem é bem mais nítida, gerando menos keyframes que antes e assim está demorando um pouco mais de tempo para sincronizar as conexões novas. Da primeira vez que fiz o teste imaginei que o programa tivesse travado, mas na verdade é que demorou um certo tempo para vir um keyframe.

Mas no final de tudo eu terminei com um RPM para o CentOS 4 do kernel 2.6.9 com os drivers da Osprey para quando alguém precisar deles no futuro não precisar compilar tudo na mão e com o flash ao vivo funcionando na Osprey.

Fica faltando ver se essas mudanças vão criar o famigerado problema de lipsync que tinha com a PixelView. A priore estou usando os mesmo parametros de antes, V4L 1.x mas usando drivers OSS e não ALSA como era na PixelView.

Felizmente o mencoder não teve problemas em sincronizar os frames de áudio e vídeo, é possível ter uma prévia do que estamos fazendo em flashlive.

O próximo passo é conseguir integrar a lógica no Apache, de forma a ter uma arquitetura de distribuição de vídeo mais robusta.

Nesse último techtalk gravei a minha palestra sobre o OLPC com uma solução de cortes ao vivo que me deixaria muito feliz de apresentar também, mas como a coisa toda ainda está em sendo lapidada achamos ainda inoportuno preparar um techtalk sobre o assunto. Então, para matar a vontade, escrevo um pouco aqui sobre as novas possibilidades dessa ferramenta, que surgiu da crença de que poderiamos, como uma empresa de internet, encontrar uma forma mais viável, que as tradicionais herdadas da TV, para fazer nossas transmissões ao vivo.

As metas eram as seguintes:

• Encontrar um programa que fizesse uso da nova arquitetura das placas gráficas, capazes de processar bilhões de pixels por segundo, para nosso proveito — edição de multiplas fontes de vídeo com cortes suaves, aplicação de logo marcas, gerador de caracteres e até propaganda, como notado mais tarde — tudo isso ao vivo.
• Esse programa também teria que fazer um uso eficiente do processador para codificar todo esse sinal processado em streams windows média, do mesmo formato que fazemos atualmente.
• Que fosse possível gravar o mesmo sinal codificado para o ar, para possíveis edições posteriores e se possível, ainda, que não houvesse necessidade de transcodificar novamente para fazer esses cortes.

Existem muitas soluções em hardware, que fazem a força bruta com o trabalho em circuitos especializados para tratamento de vídeo digital de alta qualidade, mas todos muito acima do nosso orçamento de pequenas produções. Que diga-se de passagem, é como a internet deve ser usada — lembremos do long-tail da amazon.com — o objetivo não é transmitir para mais gente que a TV, isso é inviavel, porque logo a nossa infra-estrutura despencaria e nossos gastos iriam para o espaço, mas transmitir mais conteudo que a TV jamais poderá na sua forma de broadcast e manter consumidores fieis a essa tremenda variedade.

Então se passaram muitas madrugadas de pesquisa para provar que já era possível para computadores pessoais comuns produzirem vídeos digitais de alta qualidade, que já seriam melhores que os vídeos analógicos dos quais nos alimentamos da TV hoje. Depois de muito custo o primeiro programa que encontrei foi o Visual Communicator da finada Serious Magic, comprada pela Adobe o logo tirado do ar, confesso que fiquei desanimado, por achar que seria o primeiro e único a fazer isso, e começava a avaliar as complicações de implementar eu mesmo o que eu sabia que era possível… Quando encontrei o Wirecast, muito mais simples e dinâmico que o Visual Communicator, fiquei bastante empolgado e cri firmemente que essa era a solução para as inumeras requisições de pequenos estúdios que recememos mensalmente.

Na Palestra do OLPC fiz o seguinte, em apenas um laptop rodei o Wirecast, capturando de uma camera por DV, o Desktop Presenter (programa que captura a tela do desktop de um computador e envia pela rede para o Wirecast como se fosse mais uma camera) capturando desktop extendido que tinha um Acrobat Reader (para a própria apresentação) e mais tarde um VNC Viewer conectado com o XO (laptop do OLPC) e no final um VMWare Player (com a versão mais nova do Sugar, sistema operacional do XO) nesse ponto a memória do computador acabou e mais nada acontecia, o Wirecast se mostrou robusto por, apesar de não ter condições de continuar com o processamento do vídeo, parar a gravação fechando o arquivo corretamente. Como já estava nas perguntas não me importei mais com o laptop e continuei respondendo ao público. Apesar do final desastrado e so som mal ajustado não é preciso muita imaginação para ver as possibilidades dessa solução simples e barata nas nossas produções reais.

Palestra sobre o Laptop de 100 Dólares gravada em WMV com o Wirecast e posteriormente codificada em Flash Vídeo

Fico muito feliz de ver essa solução indo adiante, pois ela se encontra em Teste Beta no Estúdio do Chat no Downtown e com boas perspectivas de ser usada em vários outros lugares. Lembro o quanto a defendi frente a todos que não acreditavam que uma solução de 500 dólares poderia ser de maior qualidade que as de milhares de dólares disponíveis no mercado; fico feliz por não te-los decepcionado ainda e espero que possamos fazer todos os ajustes necessários para tornar essa a nova maneira de produzir vídeos na globo.com.