Archive for May, 2008|Monthly archive page

DimP – A Direct Manipulation Video Player

DimPO Aviz, um time de pesquisa do INRIA (Instituto Nacional de Pesquisa em Informática e Automação da França), divulgou recentemente na SIGCHI Conference, um protótipo de um player de vídeo que permite a navegação no vídeo através da manipulação direta do conteúdo. Isto significa que, para realizar um “seek” no vídeo, o usuário pode simplesmente clicar em um objeto do mesmo, e, em seguida, arrastá-lo na direção desejada.

Para implementar este novo tipo de navegação, o player identifica os objetos de uma determinada cena, e, em seguida, mapeia o movimento para cada frame de vídeo, estabelecendo um caminho ao longo do tempo. Assim, ao contrário do que parece, os objetos não são “destacados” do vídeo.

Este conceito de navegação é extremamente interessante, principalmente por ser muito mais intuitivo que o seek tradicional. Para quem quiser mais informações, recomendo bastante a leitura do artigo Video browsing by direct manipulation, que explica com detalhes a implementação.

Advertisements

[Streaming Media East 2008] Novidades e Resumo do Evento

Na última semana estive no Streaming Media East 2008, em Nova York, para conferir as novidades sobre streaming de mídia na internet, e posso dizer que o evento foi bem legal, e bastante proveitoso, mesmo tendo algumas sessões lamentáveis. Porém, antes de mais nada, gostaria de pedir desculpas pois não consegui atualizar o blog com a freqüência que eu queria, já que, por incrível que pareça, existem mais hot-spots abertos no Rio que em NYC!!!

No primeiro dia de evento, assisti dois workshops de 3hrs cada: “Comparing and Using Video Codecs” e “Microsoft Silverlight”. Estava especialmente interessado no primeiro deles, já que a descrição do workshop dizia que seria apresentada uma comparação entre WMV, VP6 e H.264. Infelizmente fiquei bastante frustrado, e acredito que esta tenha sido a apresentação sobre codecs de vídeo mais rídicula e inútil que eu já vi. O palestrante foi totalmente superficial, não entrando em nenhum detalhe mais específico de nenhum dos codecs. Durante a apresentação, ele ignorou toda e qualquer solução open-source, de qualquer codec, inclusive a libx264, que é sem dúvida nenhuma a melhor implementação de H.264, inclusive quando comparamos com implementações proprietárias. Não citou o ffmpeg ou o mencoder, e ainda desconversou quando foi perguntado à respeito delas. Finalmente, para perder completamente o crédito, apresentou um comparativo de encoders com notas dadas subjetivamente para critérios que ele definiu como importante, ignorando absolutamente todos os métodos objetivos/científicos de avaliação de qualidade (PSNR, SSIM, MSE, etc). Ele ainda criticou bastante o Sorenson, e parecia um representante comercial da On2 querendo vender o VP6, apesar de não ter argumentos quando questionaram sua posição dizendo que o YouTube usa Sorenson.

O segundo workshop, de Silverlight, foi bastante proveitoso, já que confirmou todas as críticas que faço, além de reforçar minhas convicções de que ele é uma porcaria que a Microsoft está tentando empurrar para o mercado. Durante 3hrs, o Silverlight Evangelist não conseguiu fazer sequer um exemplo, conseguiu crashear o IE duas vezes, e desconversou quando pediram um comparativo com o Flash. Como mais da metade dos presentes foi embora antes de 2hrs, acho que todos estão convencidos de que não dá para fazer muita coisa com o Silverlight não, então, se vocês querem um conselho, esqueçam que ele existe.

Apesar de um primeiro dia terrível, o segundo dia valeu por cada centavo pago na inscrição. O keynote de abertura, com o CDO da NBC, foi bem legal, principalmente para saber o que grandes broadcasters como a NBC estão fazendo, e o que eles esperam do mercado. Em seguida, assisti uma mesa redonda sobre a convergência H.264, onde estavam presentes o Product Manager do Flash Media Server e o Video Architect do Yahoo!, além de um representante da Akamai e um da Move Networks. O grande ponto desta sessão foi opinião unânime de que o H.264 é o formato da nova geração de vídeos que irá ser responsável pela convergência de conteúdo entre TV, Internet e Celular. A Adobe está apostando bastante nisso, e certamente a parte de streaming/vídeo vai receber bastante investimento nos próximos anos. Um ponto importante que todos lembraram é a questão do licenciamento do H.264, que será revisado pelo MPEG/LA em dezembro de 2010, e pode impactar bastante à indústria.

Outra sessão bem interessante foi sobre os preços de CDN’s e sobre P2P, onde houve muita discussão sobre a queda que vem ocorrendo nos preços para utilização de CDN’s, e sobre as alternativas para delivery de vídeos, como P2P. Na verdade, o grande problema que todos enxergam no P2P é a necessidade de instalação de um software adicional, que realmente prejudica a experiência do usuário.

No segundo dia, fui à um keynote com o responsável pelo CNNMoney.com, onde ele apresentou como é a estrutura de publicação/produção deles. Apesar de ter uma produção bem pequena (20 vídeos por dia), foi legal ver como é o processo desde a captura no estúdio (com câmeras HD da Sony e Anycast) até a publicação na internet, depois de editar o conteúdo no Final Cut Pro.

Além disso, a pergunta que eu mais ouvi durante todo o evento é como ganhar dinheiro com vídeo na internet, ou seja, como transformar todas as iniciativas, desde VoD até Lifecasting, em um negócio rentável, principalmente através de publicidade. A verdade é que ninguém sabe ao certo como transformar toda a audiência dos sites de vídeo em dinheiro, e estão todos experimentando suas soluções. Neste ponto específico, acho que a Globo.com está com um modelo bem interessante, que deve se firmar no mercado.

Em resumo, valeu bastante a ida ao evento, e recomendo para todos que tiverem algum interesse no mercado de streaming, principalmente para aqueles que estão começando agora.

Se alguém tiver interesse, algumas apresentações do evento estão aqui.

Streaming Media East 2008

Streaming Media East 2008Nesta sexta-feira (16/05) estarei embarcando para Nova York, para o Streaming Media East 2008, um evento voltado para o mercado de distribuição de mídia na internet, e acho que será bastante proveitoso. Este ano a agenda está especialmente interessante, já que teremos mais discussões sobre H.264, o que comprova mais uma vez que este será o codec da nova geração de vídeos na Web e responsável pela tão esperada convergência entre TV e Internet. Além disso, outro assunto que será bastante falado é sobre como ganhar dinheiro com a distribuição de vídeos na internet, ou seja, qual é a melhor forma de inserir peças publicitárias sem prejudicar a experiência do usuário.

Também devo assistir sessões de CDN e P2P, já que em termos de delivery o mercado ainda está bem atrasado, e, usar HTTP unicast certamente não vai atender a crescente demanda existente.

Finalmente, para ninguém dizer que eu tenho má vontade e preconceito com as soluções da Microsoft, devo assistir um workshop de Silverlight. Ainda tenho esperanças de que alguém encontre um argumento à favor do Silverlight, porque até agora está bem difícil.

Bom, irei postar diariamente sobre as novidades, então, podem conferir o que está rolando por aqui.

Scrum, e os benefícios para os Team Members

Freqüentemente leio posts e artigos sobre a utilização do Scrum, entretanto, na maioria das vezes, existe uma grande ênfase nos benefícios obtidos com ele do ponto de vista da empresa, como o aumento na velocidade das entregas, e nem sempre é discutido sobre o que os team members ganham, quais as vantagens para as pessoas que efetivamente desenvolvem as tarefas. Desta forma, achei que seria interessante expor aqui um pouco da experiência que estou tendo na Globo.com, onde atuo como team member de uma equipe desde que adotamos o Scrum oficialmente.

Algumas pessoas, em um primeiro contato com o Scrum, podem apresentar um certo receio sobre uma das prerrogativas propostas pelo framework, que é a disseminação de conhecimento por todo time, com o objetivo de reduzir as chamadas “ilhas de conhecimento” nas equipes. Isto é excelente do ponto de vista da empresa, porém, infelizmente alguns profissionais que detém um conhecimento específico pensam que seu emprego estará “garantido” enquanto ele for o único a dominar determinado assunto. Entretanto, a disseminação do conhecimento por todo time é extremamente positiva para o desenvolvimento profissional de cada um, uma vez que o conhecimento específico de cada membro é compartilhado, estabelecendo uma “via de mão dupla”.

Além disso, cada componente do time é livre para executar qualquer tarefa, seja ele ou não o especialista no assunto. Desta forma, esta transferência de conhecimento pode ser realizada de acordo com a vontade de cada um, até o ponto que o desenvolvedor irá fazer tarefas simples de design, e o designer irá implementar trechos simples de código.

Outro benefício bastante importante é a existência um escopo claro e bem definido daquilo que deve ser realizado, o que evita uma série de transtornos. Ninguém vira a noite se matando para implementar uma funcionalidade não prevista, ou alterando o que foi feito pois houve uma mudança de idéia. No Scrum existe um “compromisso público” que define o que será realizado, não existe margem para alterações não aprovadas pelo próprio time. Além disso, a existência de um backlog priorizado permite uma visão mais clara daquilo que deverá ser realizado, qual é a estratégia e os objetivos existentes.

A existência de reuniões diárias (daily meetings), também ajuda bastante no processo de comunicação entre os membros do time, sendo que cada um sabe exatamente o que o outro fez, e o que irá fazer, e isto é extremamente importante para todos tenham uma visão bem clara do que está sendo feito, quais foram os desafios e como eles foram superados. Finalmente, ao término de cada ciclo (sprint), cada um pode expressar o que foi bom ou ruim no último sprint o que facilita bastante a resolução de problemas de qualquer natureza.

Em suma, o Scrum pode ser bastante positivo também para os profissionais, basta saber aproveitar as novas oportunidades abertas por este modelo de desenvolvimento, em vez de ficar com medo das mudanças que naturalmente vão acontecer.

Escolhendo a melhor arquitetura para delivery de vídeos

Apesar de parecer algo simples, a escolha correta de uma arquitetura de delivery de mídia é tão fundamental para o serviço quanto a definição dos parâmetros de codificação, isto porque ela também pode impactar de forma decisiva na qualidade da experiência do usuário. Distribuir um vídeo que demora muito para carregar, ou que “trava” constantemente, muitas vezes é pior do que ter uma experiência contínua porém com pior qualidade. Por isso, a escolha da arquitetura de delivery está fortemente atrelada ao target bitrate escolhido.

Existem duas formas básicas de se distribuir vídeos na internet: via Streaming ou Progressive Download. O streaming é a tecnologia que permite o envio de informação através de pacotes, que são solicitados sob demanda pelo cliente, ou seja, o cliente solicita ao servidor apenas os pacotes necessários para exibir o conteúdo em um determinado momento. Uma vez consumidos, os pacotes deixam de existir na máquina do cliente. O progressive download, nada mais é que um simples download, porém com a vantagem de que o usuário pode começar a reproduzir o conteúdo sem que seja necessário que o download esteja finalizado. No progressive download, o conteúdo é efetivamente copiado para a máquina do usuário, e, de acordo com as diretivas de cache, pode ficar armazenado lá por um determinado período de tempo.

Vocês agora podem se perguntar qual dessas duas opções é melhor, e a resposta é simples: depende dos seus objetivos e das características do cenário em que a solução será utilizada. Simplificando, você deve se fazer as seguintes perguntas antes de escolher qual modelo de distribuição será utilizado:

  • Qual o target bitrate total dos vídeos que serão distribuídos?
  • Qual é a largura de banda disponível média dos usuários que irão acessar o conteúdo?
  • A segurança do conteúdo é uma prioridade? (Pirataria)
  • Os custos da infra-estrutura são um fator limitante?

Se suas respostas indicam que a largura de banda disponível média dos usuários é pelo menos 20% maior que o target bitrate total dos vídeos que serão distribuídos, então a situação é bastante confortável, e a escolha entre streaming e progressive download será decidida nas outras duas questões. Caso a segurança seja uma preocupação primordial, ou seja, o conteúdo oferecido é altamente sensível à pirataria, então recomendo fortemente a utilização do streaming. Isto porque o conteúdo distribuído via streaming não fica armazenado no cliente após a reprodução, o que dificulta um pouco as coisas para o lado de quem quer copiar. Além disso, não é possível fazer o download do arquivo através de um simples GET HTTP, já que a maioria dos servidores de streaming utilizam protocolos diferentes (rtmp para Flash e rtsp para WMV). Entretanto, não pense que será impossível copiar o conteúdo, já que existem alguns programas que “tocam” o vídeo como se fossem um player, mas na verdade estão copiando o bitstream para um arquivo local (WMRecoder, etc).

Por outro lado, ainda no cenário ideal onde a disponibilidade de banda é maior que o target bitrate, caso os custos sejam uma preocupação crítica, então a melhor opção seria o progressive download, já que podemos montar um servidor utilizando apenas tecnologias open-source (Apache), e podemos compartilhar os recursos com outras aplicações, como um web-server. Desta forma, não é necessário um hardware dedicado ao serviço, o que pode acontecer utilizando streaming, principalmente em Windows Media. Além disso, um servidor de progressive download suporta, naturalmente, mais conexões que um servidor de streaming, já que ele dispensa uma série de controles do fluxo de bits de cada conexão.

Voltando ao mundo real, o que acontece quando a disponibilidade de banda dos usuários não é lá grandes coisas? Neste caso, a melhor opção é sem dúvidas o progressive download. Caso o usuário não tenha uma banda disponível suficiente e a distribuição seja feita via streaming, a reprodução do conteúdo será interrompida constantemente para rebufferings, já que o fluxo de bits de saída é maior que o de entrada, e não há nada mais irritante para o usuário do que interrupções na reprodução. O mesmo problema acontece para o progressive download, com um porém: o YouTube ensinou uma valiosa lição para o usuário, “aperte o pause e espere carregar”! Assim, a diferença, neste caso, entre o streaming e o progressive download, está na possibilidade de pausar a reprodução até que o conteúdo esteja suficientemente carregado para uma reprodução contínua. Esta é uma “feature” que definitivamente faz toda diferença quando falamos na satisfação do usuário.

Um bom argumento daqueles que defendem o uso do streaming é a possibilidade de seek para qualquer posição do vídeo, independente da necessidade de carregamento. Entretanto, se estivermos falando de Flash Vídeo, este argumento é totalmente inválido. Com Flash Vídeo podemos implementar de forma relativamente simples uma solução de seek para qualquer posição, sem que seja necessário que a posição desejada já tenha sido recebida (mod_flv_streaming).

Resumindo, a escolha entre progressive download e streaming deve ser feita baseada nas características específicas de cada situação, e não podemos dizer para usar sempre um ou outro, pois ambos possuem vantagens e desvantagens. Na verdade, a chave para escolha da melhor arquitetura consiste na avaliação correta de todos os pontos envolvidos no processo de delivery, considerando assim os trade-offs de cada solução.