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.

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.

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!

Volta e meia me passa essa ideia de por legendas nos nosso vídeos — bom, sempre que falam em aumentar a audiência; foi o caso dessa última apresentação para a tecnologia –, me parace tão simples em relação as altenativas que não vejo porque não.

Tudo bem, precisa de alguns tradutores, mas nada tão grande porque já temos closed-caption para uma grande quantidade de conteudo da TV, que pode ser capturado em nossos sinais de vídeo;

as placas que usamos capturam closed-captions

Podemos usar programas de tradução para fazer boa parte do serviço, creio que existam versões profissionais de alta qualidade e então precisariamos de tradutores apenas para revisar e publicar o resultado final.

sistema de tradução de legenda

As vantagens das legendas seriam a exposição do nosso conteúdo para um público muito maior, a melhoria do acesso site para deficientes auditivos e o despertar do interesse de anunciantes mutinacionais.

Está dada a idéia, postei para saber se alguém mais se interessa e gostaria de pesquisar comigo e, claro, se a empresa pode fazer e tem interesse nisso.

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.

Os resultados preliminares dos testes de codificação de vídeo por GPU são animadores.

Verificamos que a codificações de alta resolução, com codecs da próxima geração, pode ser feita em menos da metade da duração do vídeo; quando com a tecnologia atual, para obter qualidade semelhante, gastaríamos algo como quatro vezes o tempo do vídeo.

Esses testes são tão necessários porque a próxima geração de codificação de vídeo é extremamente onerosa, e mais ainda, se pretendemos acompanhar a tendência de convergência precisamos gerar mais formatos para os diversos aparelhos capazes de consumir vídeo, aumentando ainda mais o custo de codificação.

Para isso temos pesquisado formas de codificar mais rápido, assim como adiar certas codificações menos prioritárias para depois, no caso dos formatos periféricos (como por exemplo: PSP, iPhone, MP4 players, …)

—

A pesquisa começou sabendo da possibilidade de executar códigos genéricos nas GPUs e tendo em mente que com uma placa dessas um computador simples pode-se tornar mais poderoso que um super computador de alguns anos atrás. Tendo visto vários pequenos projetos para filtros de tirar ruídos de vídeo usando a GPU e outras pequenas coisas.

Logo apareceu nas buscas as tecnologias da ATI e NVIDIA, respectivamente AVIVO e PureVideo. Ambas capazes de decodificar vídeo de alta definição (HD) para que fosse possível aos computadores acompanharem as tendências que alcançam os Home Teathers.

Mas, pra nós, tem uma diferença fundamental entre elas, a AVIVO também codifica vídeo, o que simplifica muito nosso trabalho de usar a GPU para nosso benefício.

Então nos pusemos a testar uma Radeon X300 (chipset RV370). Encadeamos então os filtros DirectShow disponibilizados pela ATI com o graphedit, para decodificar, filtrar ruído, redimensionar o vídeo, codificar no formato final e empacotá-lo no “envelope” final. O resultado foi impressionante, com qualidade equivalente, a codificação terminava em um quinto do tempo, e alem de usar a GPU os drivers da ATI faziam um uso bem melhor da CPU. Mas a placa de vídeo era obviamente inferior, quando aplicados filtros mais sofisticados o kernel time no gráfico de utilização subia desproporcionalmente, indicando que o sistema estava esperando pelo processamento da placa de vídeo.

—

Recentemente testamos com a Radeon HD 2900 XT (chipset R600), uma placa de vídeo da ATI que ocupa 2 slots e usa 2 cabos de força extra, o que a torna um pouco complicada de ligar num gabinete convencional. Por isso tivemos que fazer um adaptador que tirar energia dos conectores de força para disco que estavam sobrando, já que a fonte utilizada no teste tinha apenas um conector de força extra para PCI-e 2×3 (3xterra, 3×12V) e a placa de vídeo não liga sem ao menos 6 entradas de 12V extra .

É preciso tomar muito cuidado porque existem muitos conectores incorretos no mercado, alguns ligando 1 cabo de 12V em 3 pinos, obviamente sobrecarregando o cabo; outras invertendo o terra com o 12V, o que queimaria a placa; ainda outras com ligações esquisitas, como um par de pinos com terras dos dois lados, no que se esperaria 12V e no que seria terra mesmo.

Tendo resolvido isso notamos que a HD2900 codificava na metade do tempo da X300, mas parece claro que falta CPU para acompanhar o poder de processamento dessa GPU mais nova, então testamos os filtros de redução de ruído mais pesados, para tentar extrair o máximo da placa de vídeo, e obtivemos um resultado bastante satisfatório o vídeo foi processado em real-time para a melhor combinação de filtros que temos.

—

Ainda estamos muito no começo na pesquisa de codificação por GPU, mas creio que essa seja uma alternativa essencial para reduzir custos e tempo para a próxima geração de vídeo na web.

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.