WebMedia

Como o foco deste blog é falar sobre tudo o que a equipe WebMedia esta atuando nada como comentar um pouco das movimentações de grandes player do mercado Americano no que diz respeito a vídeo na Internet. Todos devem ter ouvido há agum tempo que a NBC e a Apple estão de mal, com isso a NBC tirou toda a sua programação do iTunes e resolveu desenvolver uma solução sua para distribuir seus vídeos.

Em março deste ano a NEWS CORP juntou-se a NBC UNIVERSAL formando uma JV (Joint venture) para lançar um portal que disponibilizará conteúdos premium da NBC Universal e da FOX (News Corp) para serem “estremados” gratuitamente com uso de propaganda para pagar por esta distribuição, o nome escolhido para o portal é HULU.COM.

O conteúdo a ser disponibilizado nesta primeira fase será apenas on demand com Series, Filmes e pequenos clipes, não havendo restrição de quantas vezes se pode assistir cada vídeo.

No modelo de negócios do Hulu, este também funciona como uma empresa de distribuição online, e fechou parcerias para distribuir seu conteúdo com AOL, MSN, MySpace, Comcast e Yahoo, mas o conteúdo será distribuido pelos players propreitários destas empresas. Os vídeos podem ser sindicalizados e colocados em qq blog ou site com um player embedded, usando um dos fundamentos básicos de Web 2.0, a viralidade. O modelo é todo baseado em advertising e as peças podem, ficam em volta ou dentro do vídeo.

Do ponto de vista tecnológico eles estão usando Flash Video, provavelmente VP6, usando taxas de 480kbps e 700kbps em streaming com certeza usando FMS com alguma CDN, com a intenção de usar H.264 depois que o novo Flash Player (moviestar) sair.

Ainda não configurei um proxy para poder acessar os vídeos (o acesso é restrito a usuários dos Estados Unidos), mas quem estiver disposto aqui segue um exemplo do vídeo embedded, que é possivel ser visto sem ter o convite:

http://www.techcrunch.com/2007/10/29/more-hulu-goodness-embeded-video/

Uma análise mais profunda foi feita pelo Tech Crunch:

http://www.techcrunch.com/2007/10/28/hulu-launches-private-beta-first-impressions-very-good/

Wiki de Benchmarks da WebMedia:

http://wiki.globoi.com/view/WebMedia/BenchMark

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.

O código do OAS sempre me incomodou pelo fato de ser muito confuso, com aquelas funções e variáveis globais. Com o desenvolvimento do GloboVideos 4.2 surgiu um requisito para garantir que o layout das páginas não quebrassem no caso da não existência de alguma propaganda. Foi essa a deixa que me incentivou a encapsular este código em uma classe bem organizada.

Com essa classe a inserção de propaganda em uma página fica muito mais simples. Em primeiro lugar deve-se preparar o OAS informando-o qual sitepage e quais posições existem na página.

<script type=”text/javascript”>
var propaganda = new Propaganda();
propaganda.url = ‘http://ads.globo.com/RealMedia/ads/’;
propaganda.listpos = ‘Left1,Right1′;
propaganda.sitepage = ‘globovideo/catalogos/canais/redeglobo’;
propaganda.prepara();
</script>

A classe propaganda então fará a importação daquele famoso javascript do OAS que possui aquelas dezenas de document.write. Depois, no local onde deseja-se inserir uma determinada propaganda, basta mandar a propaganda ser exibida:

<div id=”propagandaNoCatalogo”>
<p>oferecimento</p>
<div class=”banner”>
<script type=”text/javascript”>
propaganda.exibe(”Right1″);
</script>
</div>
</div>

Bem mais simples não acham? Além disso, seguindo o requisito que me incentivou a criar esta classe, é possível verificar se algum banner foi exibido ou não utilizando o método exibiu. No caso abaixo, se a propaganda não existir eu mando esconder o div que o conteria.

<div id=”propagandaNoCatalogo”>
<p>oferecimento</p>
<div class=”banner”>
<script type=”text/javascript”>
propaganda.exibe(”Right1″);
if( !propaganda.exibiu(”propagandaNoCatalogo”) ) {
document.getElementById(”propagandaNoCatalogo”).style.display = “none”;
}
</script>
</div>
</div>

Não consegui postar aqui o código da classe, pois perde todo o alinhamento. Mas ele pode ser obtido pelo CVS no projeto GMC4. A classe encontra-se no arquivo /Portal/videos/cda/js/glb_videos.js. Caso você não tenha acesso ao projeto GMC4 deixe um comentário aqui que eu te passo o arquivo por Yahoo ou por e-mail.

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.

    O peso das páginas web sempre foi para mim um assunto de grande interesse e preocupação. Soluções simples como compressores de conteúdo web são capazes de reduzir muito o tamanho de uma página, ou qualquer outro tipo de conteúdo. O problema é que a utilização destes compressores pode gerar um overhead possivelmente impeditivo. Por exemplo, a principal ferramenta de compressão do Apache, o módulo mod_gzip, que usa a técnica gzip de compressão de conteúdo, comprime logo antes da entrega do conteúdo ao usuário, levando de 100 a 1000 milissegundos, dependendo do tipo e do tamanho do conteúdo a ser entregue. O browser do usuário precisa ainda aceitar, neste caso, o encoding gzip.

    Tirando proveito do fato de a Globo.com cachear seus templates, resolvi implementar uma solução neste sentido, usando uma técnica um pouco diferente, bem simples e performática. Numa das minhas madrugadas insones, fiz uma extensão para o Apache que comprime apenas páginas no exato momento em que são cacheadas. Note que, em termos de custo computacional, isto é bem diferente de comprimir quando o usuário faz um request. Na verdade, não é bem uma técnica compressão, como as usuais. O algoritmo simplesmente retira white spaces, caracteres de tabulação e caracteres return dispensáveis do html cacheado, sem prejudicar, no entanto, a legibilidade do source da página.

    Esta solução foi desenvolvida a partir do módulo apache desenvolvido pelo Luiz Silva, que está em vias de substituir o módulo proprietário da Vignette em produção. Chegou a reduzir de 104 para 74 KBytes o peso do html da home do G1, por exemplo. Levando em consideração o número de page views dos nossos produtos, não só melhoraríamos a experiência do usuário, como também deixaríamos de transmitir centenas de GBytes diariamente.

    A má notícia, no entanto, é que, para comprimir uma página no momento em que é cacheada, o algoritmo leva em média 7 milissegundos na minha máquina de desenvolvimento, o que, a pesar de ser um tempo relativamente pequeno, pode representar um custo muito elevado, dependendo da taxa de cache dos sites. Não tenho noções quanto ao comportamento deste custo durante um teste de carga, por exemplo. Mas considerando as enormes proporções do nosso portal, acredito que infelizmente uma solução deste gênero tem grandes chances de não ser aplicável a nossa realidade.

    Bom pessoal, espero que tenham achado interessante este teste. Postem aqui bastantes sugestões e idéias. Mas também estou pronto para ser apedrejado agora: não exite em registrar o seu protesto.

Documentação Wiki:
http://wiki.globoi.com/view/WebMedia/MinimizacaoHTML

Links relacionados:

http://www.websiteoptimization.com
Livro sobre métodos de otimização de HTML, CSS, JavaScript e multimídia.

http://www.webperformance.org/compression/
Coleção de artigos e links sobre compressão de conteúdo.

http://www.innerjoin.org/apache-compression/
Ferramentas de compressão para o Apache e IIS.

http://perl.apache.org/docs/tutorials/client/compression/compression.html
Um FAQ sobre Web compression.