WebMedia

Esta semana sairam várias notícias sobre a possibilidade de sair uma versão do Flash Player para o iPhone. Estas interpretações foram tiradas do discurso do CEO da Adobe, Shantanu Narayen, que disse que estariam estudando o desenvolvimento de uma versão do Player para o aparelho da Apple.

Na Terça-Feira, Narayen disse, “We are also committed to bringing the Flash experience to the iPhone and we will work with Apple. We’ve evaluated the SDK, we can now start to develop the Flash player ourselves and we think it benefits our joint customers.”

A Adobe se esqueceu que o Flash é um plugin que estaria intimamente ligado ao Mobile Safari e que isso só poderia ser efetivamente oferecido para os usuários se a Apple aprova-se, não é a mesma coisa que desenvolver um RSS reader ou um jogo, é preciso o aval de Steve Jobs para conseguir fazer isso.

Na quarta-feira, a Adobe acabou soltando uma nota onde descreve que avaliou o SDK do iPhone e que infelizmente vai precisar de mais ferramentas para poder desenvolver uma versão do Flash Player para o iPhone.

Segue um trecho da nota:

“Adobe has evaluated the iPhone SDK and can now start to develop a way to bring Flash Player to the iPhone. However, to bring the full capabilities of Flash to the iPhone Web-browsing experience we do need to work with Apple beyond and above what is available through the SDK and the current license around it.”

O mesmo aconteceu com a Sun, que anunciou que estaria desenvolvendo uma versão do Java para o iPhone e logo depois deu para trás e cancelou a iniciativa.

Mas com certeza haverá uma versão do Flash Player para o iPhone em um futuro não muito distante, resta saber qual versao será essa, o Player Full ou uma versão do Flash Lite.

A DoubleClick anunciou ontem a disponibilidade de anúncios de vídeo em HD (DoubleClick HD Video) usando o CODEC H.264 com o Flash Player 9.0.115+.

Para os usuários que não tiverem a versão do Flash Player com suporte ao H.264 o fall-back exibe a propaganda na versão não-HD. Veja o Ad em HD e a alternativa de Ad não-HD.

Reparei, entretanto, que o consumo de CPU na minha nova máquina com Core 2 Duo 2.13GHz foi consideravelmente mais alto, como era de se esperar.

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.

Como alguns de vocês já sabem, subimos no último sprint do Globo Vídeos um módulo de segurança para os vídeos em Flash que impede que o usuário consiga copiar nossos vídeos de forma trivial. Basicamente, criamos um hash de segurança que impede usuários mal intensionados de realizarem o download de um vídeo baseado no request feito pelo player. Acredito que este é o método mais trivial e mais utilizado de realizar um download de um flash vídeo, entregue via progressive download, onde o usuário, ou um programa específico, analisa os headers HTTP e identifica aquele referente ao FLV que foi feito pelo player. A partir daí, basta extrair o GET que foi feito e em seguida repetir o request manualmente, sem passar pelo player. Este é o famos método de “replay catcher”. O usuário simula um replay para realizar o download do arquivo. Para impedir essa modalidade de cópia, nosso hash é único, e só é válido se tiver a origem correta. Assim fica bem difícil enganar a validação.

Logo após a subida, identificamos nos logs dos servidores Flash Vídeo uma série de fraudes sendo bloqueadas… requests sem hash, com hash corrompido, com hash sem assinatura correta, expirado, etc… e o mais legal é que grande parte destes requests tinha a origem bem duvidosa, tipo MEGAUPLOAD, extensões de Firefox, Video Downloader, etc:

"GET /entretenimento/.../EF_BBB_T_789713_flvbl.flv?031... HTTP/1.1" 403 - “Portal/videos/cda/player/player.swf” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; fdnet; MEGAUPLOAD 1.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705; InfoPath.1; FileDownloader 1.9; MEGAUPLOAD 2.0; fdnet)” “RMID=bd12437e473a5860″i - 0

"GET /jornalismo/.../EFCGJ_T_790082_flvbl.flv?0312030... HTTP/1.1" 403 - “-” “RMA/1.0 (compatible; RealMedia)” “-”i - 0

Pegamos também possíveis bots que estavam fazendo download dos vídeos, já que em alguns casos tínhamos 1 request por segundo vindo do mesmo IP, com o mesmo Hash, e sem a assinatura correta!

Assim que colocamos o módulo em produção, nossa taxa de bloqueio era de 4%, porém atualmente estamos com algo em torno de 2,5%, 3%, mostrando que a taxa de fraudes vem diminuindo a medida que as tentativas estão sendo frustradas. Acredito que iremos estabilizar em algo por volta de 2%.

Agora vamos pensar em soluções para outros tipos de fraudes!

Agora é a vez da MSNBC.com anunciar que esta usando Flash Video e tb de permitir que os usuários coloquem seus videos embedded onde quiserem.

http://www.onlinevideowatch.com/msnbc-opens-embed-code/

O engraçado é que a Microsoft anunciou no dia 06/01 na CES que a MSNBC vai transmitir as olimpiadas de Pequim usando o Silverlight.

Com o anúncio da BBC em Outubro oassado de que adotaria o padrão Flash Video (com codec H.264) era só uma questão de tempo até que ela lançasse seu primeiro player usando a tecnologia da Adobe.

Claro que não é lá grande coisa, mas para uma empresa tradicional, apesar de ser inovadora, como a BBC isso deve ter sido um imenso passo e várias discussões deve ter ocorrido até que esta iniciativa fosse aprovada, mas (felizmente) é inevitável. A distribuição do conteúdo em diversos sites e devices é uma realidade sem volta e este deve ser o caminho que os grandes grupos de mídia devem seguir.

Link para saber como colocar o vídeo embedded:
http://www.bbc.co.uk/later/series30/episode07/kt_tunstall/

Link para o site oficial de share de videos da BBC:
http://www.bbc.co.uk/later/share_video/

Orgulhosamente anuncio que o Globo Vídeos está entregando vídeos em Flash!

Desde às 05:53 da manhã de hoje toda a nova infraestrutura de Flash Vídeo está em produção e funcionando sem nenhum imprevisto. Com isso nós nos igualamos aos maiores players do mercado como YouTube, Yahoo! Video, Metacafe e blip.tv.

Como se o projeto de migrar a infraestrutura do maior portal de vídeos do Brasil já não fosse desafiador o suficiente, todo o projeto foi implementado em tempo recorde! O projeto durou menos de 4 semanas desde estudar Flash até a migração de toda a infraestrutura, re-programação do site, produção de vídeos no novo formato, confecção do player e etc.

Utilizar um processo de desenvolvimento ágil como Scrum foi essencial para organizar e planejar nosso trabalho, bem como possibilitou a façanha de fazer uma quantidade de trabalho considerável em apenas 4 semanas. Além disso a integração da equipe de testes no projeto agilizou significativamente a homologação (que aliás foi perfeita e terminamos QA1 ontem sem nenhum bug encontrado). Mais uma vez tivemos uma prova viva de que com um mínimo esforço de organização e comprometimento de todos conseguimos entregar um projeto grande dentro do prazo e com qualidade.

Parabéns a todos os envolvidos no projeto!!!

Dada a complexidade dos codificadores de vídeo atuais, senti a necessidade de automatizar o processo de seleção de um novo perfil de codifição, coisa que pretendemos fazer com mais frequência, já que estamos expandindo as nossas frentes para novos formatos.

O protótipo desse sistema foi concebido para ser um agente que automatiza o processo manual e me ajuda a tomar decisões quando a parâmetros obscuros, para maximizar a qualidade do vídeo, enquanto minimizamos tempo de codificação e o peso do arquivo codificado. Logo na primeira noite que esse avaliador rodou conseguimos resultados animadores — no grafico abaixo, a linha verde mostra o aumento de qualidade e a vermelha como o tempo de codificação se mantem baixo.

Tinhamos um perfil rápido de qualidade mediana e um de boa qualidade que demorava muito para processar os vídeos; alimentei o algoritimo com esses dois perfis e vários outros gerados aleatóriamente. Pelo gráfico vemos que pouco a pouco ele vai encontrando parâmetros que proporcionam um aumento notável de qualidade e esse vai passando para quase toda a população (por exemplo próximo ao indivíduo 1000 acontece uma grande melhora no qualidade/PSNR e depois de estabilizar por um bom tempo ele encontra outro próximo ao 5000)

Esse protótipo foi escrito em Perl, com uma versão levemente alterada do AI::Genetic, que logo planejamos alterar ainda mais para paralelizar o processo, que ainda é um tanto demorado por causa da fila de codificação usada para verificar os perfis produzidos pelo algoritmo genético. Para isso temos a intenção de integrar a nova geração do sistema de codificação e de controle de qualidade, que usam a EFMod2ZeroConf (projeto pessoal do Fernando), com esse avaliador de perfis de codificação. E dessa forma otimizar os recursos entre as nossas máquinas de teste (que são usadas para todos esses projetos independentes) e, possivelmente, entre as de produção, que poderiam facilmente usar a mesma infra-estrutura para produzir e verificar a qualidade.

Extrapolando essa ideia, poderiamos fazer o que já queriamos a algum tempo criar profiles especializados para cada tipo de conteudo, mas era inviável, dada a complexidade que era criar e testar novos profiles. Com essa tecnologia poderiamos deixar o sistema se auto-avaliando e otimizando diariamente, no periodo noturno que atualmente é inativo, e tudo isso individualmente, para cada tipo de conteúdo (telejornais, novelas, futebol, basquete, …), cada programa, até mesmo para cada uma da midias, usando o tempo do agendamento ou regerando mais tarde as que não tenham ficado tão boas.

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.