WebMedia

Muita gente reclama que o mecanismo de busca do Wiki é lento e, em alguns momentos, apresenta resultados inconsistentes.

O Wiki utilizado na Globo.com é o TWiki, software open source que não usa banco de dados, ao contrário de outros Wikis, como o MediaWiki, usado pela Wikipedia (o site WikiMatrix permite comparar os vários softwares de Wiki disponíveis). No TWiki, cada tópico é um arquivo texto, e estes arquivos são organizados numa estrutura de diretórios, refletindo a estrutura de webs. Em função desta característica, o mecanismo de busca original executa simplesmente um grep nesses arquivos texto. Apesar da simplicidade, isto traz como principais desvantagens a lentidão e a limitação no número máximo de tópicos - que é o limite de parâmetros aceitos na linha de comando do grep.

Para otimizar a pesquisa no Wiki, foi instalado o plugin SearchEngineKinoSearchAddOn. Este plugin permite o uso da biblioteca KinoSearch, que é um port em Perl do Lucene. Este software é um indexador de documentos desenvolvido em Java, que acelera bastante a pesquisa - o trabalho mais pesado de pesquisar documento por documento é feito pelo indexador, e a pesquisa acessa diretamente o índice. O site do KinoSearch traz mais detalhes, incluindo um benchmark comparando-o com o Lucene e o Plucene (outro port do Lucene para Perl, que não é atualizado há algum tempo) e uma apresentação feita na OSCON 2006.

Através deste plugin, é executado de hora em hora um script no servidor do Wiki. Este script verifica a data de última atualização de cada web (tópicos criados, editados e excluídos). Caso esta seja mais recente que a data de última execução do indexador, o script atualiza o índice desta web. Como desvantagem, as atualizações mais recentes só aparecerão nos resultados da busca após a próxima atualização do índice.

Outra vantagem da pesquisa pelo plugin do KinoSearch é que além dos tópicos, ele também indexa os anexos. O conteúdo dos anexos nos formatos DOC, PPT, XLS, PDF, XML, TXT e HTML também é indexado, e estes são incluídos nos resultados da busca. Os resultados são ordenados por relevância, e não mais separados por web.

Uma característica da pesquisa é que as palavras são pesquisadas pelo radical, ou seja, quando é pesquisada a palavra “testes”, por exemplo, os resultados incluem as palavras “teste”, “testar” e “testando”. A sintaxe da pesquisa é semelhante à do Google: termos precedidos por “+” e “-” são respectivamente incluídos e excluídos da pesquisa. Além disso, é possível pesquisar por título, texto, autor, web, tópico e outros parâmetros específicos, e não é permitido o uso de wildcards. O tópico do KinoSearch no Wiki descreve estas opções em mais detalhes.

Agora os vídeos da TV Globo podem estar em todos os lugares! Acabamos de lançar uma nova versão do player do Globo Vídeos, e a partir de hoje os usuários podem embeddar vídeos em seus sites. Além disso, agora temos uma tela no fim dos vídeos onde são sugeridos vídeos relacionados e disponibilizadas algumas opções para compartilhamento, como o código para colocar o player em um site e o link para o vídeo no Globo Vídeos.

O player embedded já existe internamente na Globo.com há algum tempo e muito sites já o usam, como o G1 e o GloboEsporte.com, por exemplo. Porém, ele nunca esteve oficialmente disponível para os usuários e essa era uma das features mais requisitadas da nossa fila. Espero que gostem!

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.

O projeto de vídeos de usuários da DivX, o Stage6, fechou oficialmente segundo press release da empresa, como já sabiamos a matemática de concorrer com o YouTube é um jogo para poucos e a DivX não conseguiu bancar a operação por muito tempo.

“So why are we shutting the service down? Well, the short answer is that the continued operation of Stage6 is a very expensive enterprise that requires an enormous amount of attention and resources that we are not in a position to continue to provide. There are a lot of other details involved, but at the end of the day it’s really as simple as that.”

http://www.onlinevideowatch.com/divx-shutters-stage6/

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.

A Nielsen Online, divulgou recentemente um estudo interessante que mostra um pouco do demografics do público que utiliza sites de vídeo online. YouTube é Marte e Streaming Video é Vênus
Resumidamente a pesquisa mostra:

• Mulheres preferem mais assistir vídeos em sites de Redes de TV  e Homens preferem mais vídeos gerados pelos usuários
• Os maiores acessos aos sites de conteúdo do usuários acontecem durante a noite e madrugada e nos finais de semana e os maiores acessos em sites de vídeo de redes de TV acontece na hora do almoço

Estes dados foram gerados através do produto da Nielsen chamado de VideoCensus que foi lançado em meados de 2007, e tem como principal target os advertisers e empresas que possuem iniciativas de distribuição de vídeo online e que agora possuem uma empresa de respeito em analises de audiência para poder distribuir melhor suas campanhas de marketing e adaptar suas programações.

Este produto ainda não esta disponível no Brasil (aqui a Nielsen fez uma parceria com o IBO{E) mas esperamos que deva acontecer em breve, já que acessos à vídeo online está crescendo em todas as partes do mundo.

Um outro estudo feito pela ComScore, mostra outros dados interessantes, como por exemplo, heavy users de video online assistem em torno de 250 vídeos  por mês, enquanto usuários mais light assistem apenas 8 vídeos.

A comScore também classificou o público que acessa vídeos online em quatro grupos distintos: On demanders, Sight & Sounders, Television Devotees e Content Explorers.

E por fim um outro artigo interessante, feito em meados do ano passado e divulgado pela Broadcasting and Cable, uma renomada revista da área de Televisão mostra que 63% dos usuários banda larga nos Estados Unidos acessam algum tipo de conteúdo em vídeo na Internet, um crescimento de 16% em 6 meses. Este estudo conclui ainda que, esta audiência online não “canibaliza” a audiência da TV, ou seja, as pessoas não deixam de assistir TV para acessar vídeos online, os usuários estão cada vez mais fazendo as duas coisas ao mesmo tempo.

Na última semana estive na JBoss World 2008, um evento da Red Hat que discute várias ferramentas e soluções baseadas em produtos JBoss. Fiz uma série de posts no meu blog sobre as apresentações que achei mais interessantes, sugiro que dêem uma olhada. Além disso, todas as apresentações estão disponíveis para download no site do evento.

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!