Archive for the ‘Internet’ Category

Globo Vídeos para iPhone

A Globo.com lançou hoje, oficialmente, seu portal de vídeos para iPhone: http://m.video.globo.com. Agora é possível ver os vídeos da Globo.com de qualquer celular que suporte vídeos H.264!!!

Globo Videos para iPhone

Globo Vídeos para iPhone

Foi desenvolvida do zero uma nova versão do site, otimizada para iPhone e iPod Touch, com os já conhecidos efeitos de transição. Todo este trabalho foi realizado em pouco mais de um mês, desde a criação até o desenvolvimento, passando pelo setup da infra-estrututra de distribuição, estudos e pesquisas para otimizar a qualidade dos vídeos, implementação, etc, e isto só foi possível devido à utilização de metodologias ágeis, que definitivamente mudaram a forma como trabalhamos aqui, o que sem dúvida nenhuma permite uma resposta mais eficiente às demandas do mercado de internet.

Além de ver os vídeos no site, é possível reproduzir todos os vídeos do portal, mesmo aqueles que estão embedded em matérias, como os que encontramos no G1 e Globoesporte.com

Com relação à qualidade dos vídeos, posso dizer que conseguimos uma otimização bem legal, onde temos um vídeo de ótima qualidade (33dB) para o bitrate que escolhemos, que é limitado ao throughput máximo das redes 3G.

Video da Globo.com no iPhone

Vídeo da Globo.com no iPhone / iPod Touch

Mais uma vez conseguimos entregar um produto inovador, de qualidade, o que prova que estamos no caminho certo. Parabéns galera!!!

Advertisements

TV Digital e a Interatividade, Portabilidade e Mobilidade

Para quem ainda não sabe, amanhã, dia 16/06, a TV Globo inicia sua transmissão de TV Digital para o Rio de Janeiro, durante a exibição do Jornal Nacional. Depois de mais de 5 anos de muita burocracia governamental finalmente estamos implantando o novo sistema, processo que deve demorar, pelo menos, mais uns dois anos para ter toda a cobertura que a TV analógica possui hoje (99% do território nacional). A pergunta que me faço neste momento é quais serão as reais vantagens do SBTVD, além do ganho de qualidade é claro, considerando o grande atraso no processo de definição/implantação.

O comitê para definição do SBTVD foi criado em 2003 com o objetivo de pesquisar os padrões existentes e escolher um para utilização no Brasil. Depois de muita pesquisa e discussão, chegou-se a conclusão de que o ISDB-T (padrão de TV Digital Terrestre do Japão) era o que oferecia as melhores condições, já que possuía características que permitiam a recepção por dispositivos móveis e portáteis. Porém, o ISDB-T utilizava o MPEG-2 como codec de vídeo, e, devido a demora na definição do padrão brasileiro, já existia uma corrente muito forte em prol da utilização do H.264 como codec de vídeo, devido a melhor eficiência em relação ao MPEG-2. Foi então que decidiu-se pela criação de um sistema híbrido, utilizando a modulação ISDB-T com o H.264 como algoritmo de compressão de vídeo. Esta, no meu ponto de vista, foi a única vantagem de termos demorado tanto em definir um padrão de TVD.

Entretanto, a interatividade, uma das grandes vantagens da TVD além da qualidade, está praticamente esquecida, e, pelo ritmo que as coisas caminham, ainda vai demorar muito para que funcionalidades descentes sejam implementadas. A ausência de um processo interativo mais estruturado na TV acaba abrindo caminho para a expansão da distribuição de vídeo na internet, que já lida com este processo de interação desde seu nascimento, e que ainda pode evoluir bastante.

O problema é que quando a interatividade finalmente chegar à TV pode ser tarde demais. Dizer que a TV vai acabar e que o consumo de conteúdo em vídeo será realizado via internet é ser um tanto quanto radical. Na verdade, acredito em um processo de convergência, onde os grandes broadcasters continuarão gerando conteúdo, que será consumido e distribuído de diversas formas. A única certeza que eu tenho é que o modelo comercial que temos hoje será completamente substituído, já que o processo de consumo de conteúdo será alterado.

Com relação à mobilidade e portabilidade, acredito que a distribuição de vídeos via redes de dados 3G irá predominar sobre a TVD por dois motivos: primeiro, porque as redes 3G já estão sendo implantadas, e existe uma demanda forte que impulsiona a expansão; segundo, pelo processo de consumo “on demand” que já existe na internet e que esta sendo expandido para experiências mobile, e que faz muito mais sentido em relação ao modelo de distribuição da TV, do ponto de vista de consumo de conteúdo em celulares.

Resumindo, é necessário uma mudança de mentalidade daqueles que hoje lidam com TV para que seja possível aproveitar de forma ampla os benefícios que a TV Digital nos oferece, atendendo assim as expectativas de consumo do mercado. Caso contrário, a TV irá perder cada vez mais sua força, abrindo caminho para novas possibilidades e experiências que ela não é capaz de suprir.

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.

VP6?! Não faça isso!

Para quem ainda não sabe, o VP6 (na verdade TrueMotion VP6) é um codec de vídeo utilizado para codificação no formato Flash Vídeo, desenvolvido pela On2 em 1992, e é bastante comum em vídeos distribuídos na internet. A cada dia, mais e mais sites YouTube like passam a utilizar este codec para comprimir seus vídeos, e isso é algo que me deixa bastante curioso: o que as pessoas que tomam estas decisões tem na cabeça, para usarem o VP6??? Por isso, resolvi fazer uma lista de argumentos para aqueles que estão pensando em usar Flash Vídeo para alguma coisa, e para aqueles que usam VP6 poderem me dar bons argumentos para tal escolha.

Antes de entrar nos detalhes de porque eu acho o VP6 ruim, vamos avaliar as opções existentes. Se você quer gerar um vídeo para tocar no Flash Player, você pode escolher entre os seguintes codecs: Sorenson, VP6, e H264. O Sorenson é um codec antigo e não muito eficiente, é o que o YouTube utiliza para seus vídeos de baixa definição e existem diversas implementações open-source. O H264 é um codec excepcional, utilizado para TV Digital Terrestre e bastante eficiente. Além disso, o H264 também possui implementações open-source, porém é necessário pagar royalties para utiliza-lo comercialmente.

Dadas as características das opções, a escolha evidente seria o H264. Entretanto, devemos considerar que somente a versão 9.0.r115 do Flash Player toca vídeos em H264, e apenas uma parcela bem pequena dos usuários tem esta versão instalada. Assim, a opção mais óbvia seria utilizar o VP6, já que é um codec mais eficiente e é capaz de gerar vídeo com ótima qualidade. Entretanto, ele é um codec caro, e para produzir vídeos em larga escala, de forma legal, você terá que desembolsar uma boa grana. A questão então é mais de custo x benefício.

Para codificar vídeos em VP6 você tem algumas opções, como o Flash Media Encoder e o Flix. Entretanto, todas elas são bastante limitadas, para não dizer totalmente, sendo que é possível alterar apenas o target bitrate e alguns parâmetros de tolerância. Para quem está acostumado a utilizar o mencoder e o ffmpeg, onde é possível alterar qualquer parâmetro do codificador, isto deixa muito a desejar. Não podemos, por exemplo, configurar o range de motion estimation, ou o tamanho dos macroblocos, nem sequer o posicionamento dos key-frames, ou seja, não existe margem para otimização. Até existe a possibilidade de gerar VP6 com o mencoder, porém trata-se de um hack com a DLL que implementa o codec, e é bastante bugada.

Por outro lado, podemos gerar Sorenson com estas ferramentas open-source, e podemos otimizar tanto o processo de codificação que o vídeo gerado terá uma qualidade semelhante à do VP6, principalmente quando falamos de bitrates entre 400kbps e 800kbps. Além disso, não será necessário gastar nem um centavo para gerar os vídeos. O único problema, no caso, é encontrar a combinação de parâmetros que tenha como output um vídeo de qualidade comparável ao VP6.

Outro ponto importante é o tempo de codificação, ou seja, o tempo necessário para gerar o vídeo comprimido. O Sorenson é um codec extremamento rápido, e, mesmo utilizando dois passos, é possível obter um tempo de codificação menor que a duração do vídeo. Já o VP6 é bem mais lento, e isto pode ser bem crítico dependendo do volume de vídeos processado e da urgência de exibição dos mesmos.

Assim, a única justificativa que vejo para utilizar VP6 é para vídeos em alta-definição, com grande penetração de usuários, e em cenários com grande disponibilidade de banda. Mas se for este o caso, pense bem, porque o H264 vai dominar o mercado antes que você possa imaginar.

Scaling Down

Quando falamos de arquiteturas escaláveis, a primeira coisa que nos vem a mente é ter um projeto de hardware/software que permita o aumento da capacidade de processamento de acordo com o aumento da demanda. Isto significa que o esforço para atender uma demanda crescente deve ser o mínimo possível, limitando-se, na maioria das vezes, apenas em investimento em infra-estrutura de hardware. Entretanto, o conceito de escalabilidade é muito mais amplo que isto, e não deve ser limitado às condições de crescimento da demanda, mas também deve considerar uma redução significativa desta. O problema é que a grande maioria das pessoas que projetam arquiteturas estão preocupadas apenas com o scaling up e se esquecem totalmente do scaling down, e isto pode ser bastante arriscado também. Theo Schlossnagle, no seu livro Scalable Internet Architectures, nos dá inúmeros exemplos de empresas que, por não possuirem uma arquitetura totalmente escalável, simplesmente faliram durante o estouro da bolha da Internet por não serem capazes de cortar seus custos operacionais.

O problema de scaling down geralmente é mais comum em empresas de médio e grande porte, uma vez que a demanda inicial já é bastante grande, o que exige uma arquitetura inicial mais robusta e complexa. Porém, todo software tem um ciclo de vida, e existe uma probabilidade grande de que após alguns anos a demanda torne-se cada vez menor. Neste ponto, quando a demanda atual passa a ser menor que a inicial, muitas vezes a estrutura torna-se super dimensionada, e os custos de operação não são mais justificáveis. Além disso, nem sempre é interessante, do ponto de vista de posicionamento de negócios, tirar o software do ar. É aí que a necessidade de reduzir a estrutura vira uma questão de sobrevivência (sendo um pouco radical).

Você pode estar se perguntando agora: Se eu tenho uma arquitetura que é facilmente “escalável para cima”, porque ela não seria “escalável para baixo”? Quais são as características necessárias para um scaling down? Na verdade, em qualquer arquitetura existe um limite de quão simples e barata ela pode ser. O princípio geral da escalabilidade nos diz que quanto melhor for o isolamento entre as diferentes camadas do software, mais fácil é expandir a capacidade dos gargalos existentes nele. Para um scale down eficiente, também é fundamental que os componentes que foram isolados sejam construídos de forma uniforme, e rodem em plataformas compatíveis, de modo que todos os componentes possam coexistir em um único ambiente, que, no caso mais extremo, seria uma máquina Google Like. Esta é a visão ideal de escalabilidade: ter um software (inclusive com suas dependências), que seja capaz de rodar em uma máquina de supermercado, e que também possa funcionar perfeitamente em 50 servidores Dual Quad Core em cluster, e que a quantidade de informação processada varie linearmente de acordo com o aumento da capacidade.

Para que isto seja viável, é fundamental considerar os requisitos mínimos de cada componente, avaliando a compatibilidade destes requisitos com os demais componentes. Por exemplo, se um determinado componente só roda em Solaris, e o outro só em Windows, a coexistência dos dois em um único hardware fica comprometida. Atualmente, ainda temos a saída da virtualização, mas pode ser que nem todos os componentes rodem sem problemas em ambientes virtualizados. Além disso, requisitos mínimos de memória, disco e processamento irão delimitar o quão simples poderá ser a estrutura.

Resumindo, temos todos que nos preocupar não somente com o que fazer quando as coisas estão se expandindo, mas também é muito importante ter um plano claro de o que pode ser feito para enxugar a estrutura, direcionando os recursos para pontos mais prioritários. Quando você estiver projetando uma arquitetura, lembre-se de que em algum momento o scaling down pode ser a única alternativa para manter um produto no ar.

Vídeos no Flickr!!!!

O Flickr liberou hoje pela manhã a possibilidade de upload de vídeos, além das fotos que já conhecemos. Com isso, não precisamos mais subir nossos vídeos para o YouTube, e podemos deixar tudo junto em um lugar só. Essa feature era uma das mais esperadas de todos os tempos, e não sei porque eles demoraram tanto para implementar essa funcionalidade (provavelmente devido aos investimentos em infra!!!). Talvez pela falta de uma infra-estrutura robusta existe um limite de 90seg por vídeo, o que é ruim, mas já dá para quebrar o galho.

Eles também estão utilizando Flash Vídeo em progressive download, o que já é mais do que padrão no mercado. O codec de vídeo escolhido foi o VP6, com 800kbps (muito alto para os padrões brasileiros), sem conversão de aspect ratio ou frame rate. Já para o áudio, temos 64kbps MP3, com 44100Hz, stereo.

Este é sem dúvida nenhuma um passo importantíssimo do Flickr, sendo mais um diferencial bastante considerável em relação aos seus concorrentes.

Para saber mais, é só ir no Blog do Flickr

MTV lança novo player de Vídeo

A MTV lançou recentemente a nova versão de seu Player de Video na Internet exclusiva para Full Episodes. Utilizando streaming via Flash Media Server, ela abandona o delivery via progressive download, o que definitivamente é uma evolução em termos de segurança, já que não há cache local, e de “qualidade”, uma vez que eles utilizam um processo de detecção de banda para servir um target bitrate mais adequado para a conexão do usuário (temos variações desde 350kbps até 1.2Mbps). Apesar disso, essa “qualidade” está entre aspas porque todos sabemos que a experiência do usuário em delivery via streaming pode ser terrivelmente ruim, principalmente se você estiver próximo do target e se sua velocidade não é suficientemente estável. Nestas circunstâncias, o vídeo irá fazer rebuffering constantemente, o que é absolutamente irritante. Além disso, a possibilidade de pausar e aguardar o carregamento para uma reprodução contínua não é possível, o que vai contra ao comportamento do usuário, principalmente devido à experiência proporcionada pelo YouTube.

Com relação à qualidade do vídeo, ela está realmente muito boa, e melhorou bastante em relação à versão antiga. A imagem está mais nítida, com menos blur, o que indica um processo de codificação mais eficiente. Como o Flash 9.r115 não é um requisito mínimo, acredito que eles estão utilizando VP6 para codificar os vídeos. Entretanto, dada a qualidade da imagem em relação ao bitrate utilizado, não duvido nada que também exista uma versão H264 que é enviada apenas para os usuários com esta versão de Flash Player. Infelizmente não podemos saber ao certo, já que não consegui copiar o vídeo para minha máquina 😦

Antes:

MTV Before

Depois:

MTV After

Outra observação interessante é a utilização de inserções comerciais ao longo do vídeo, que são representadas na barra de progresso com pequenas barras cinza. Eu particularmente achei que ficou meio ruim de ver as marcações, além de que a interrupção da reprodução para exibição de um comercial é extremamente inconveniente do ponto de vista do usuário. A verdade é que os grandes players do mercado ainda estão estudando a melhor forma de realizar publicidade em vídeo distribuído na internet, mas isso é um assunto para um outro post.

Por favor, organizem a internet!

The WWW around wikipediaPra começar os meus posts aqui no blog, resolvi escolher um assunto que vai ser bastante popular (se já não é), em um futuro bem próximo: a imensa quantidade de informações disponíveis na web, e como organizar isso de forma eficiente. Apesar de ir contra ao conceito inicial da internet, que é uma rede um tanto quanto caótica de informação interligada, a imensa quantidade de conteúdo existente hoje dificulta a seleção daquilo que é realmente relevante para o usuário. Quantas vezes por dia não recorremos ao Google e temos que ficar abrindo os resultados de busca para encontrar o que realmente estamos procurando? Tirando as buscas mais genéricas, como “esporte, flamengo, vídeo, etc”, os resultados retornados estão sempre poluídos com itens que não nos interessam. Desta forma, cabe ao usuário, na maioria das vezes, aprimorar sua busca, adicionando mais palavras, operadores lógicos, etc. O problema é que nem todos os usuários conseguem estruturar sua “query” de busca de uma forma mais complexa.

Outro ponto importante é que este não é um problema apenas dos mecanismos de buscas. A grande maioria dos sites e portais está repleta de informação considerada inútil para o usuário. A verdade é que cada tipo de informação possui uma relevância diferente para cada um, e não é eficiente tratar todos usuários da mesma forma. Isto é tão óbvio que todos os sistemas de publicidade levam em consideração o perfil do usuário para verificar a forma de comunicar com ele. Agora, porque os sites não se preocupam com isso? Se uma determinada pessoa, 90% das vezes, acessa apenas conteúdo jornalístico, porque distribuir de forma uniforme diferentes categorias de conteúdo? Se você entrar na home de qualquer portal, lá vão estar informações de diferentes assuntos, sejam eles relevantes ou não para o usuário que acessa a página.

A solução para este problema consiste na utilização cada vez maior de mecanismos de IA para analisar o comportamento de um usuário específico, entregando então apenas o que ele considera relevante. Os conceitos de Web Semântica, e interligação lógica de informação, estão cada vez mais fortes na web, e serão fundamentais para o processo de organização e para a eficiência na troca de informações. Esta nova abordagem na manipulação da informação, ou Web 3.0, promete revolucionar a forma como o conteúdo é exibido para o usuário, otimizando a maneira como a informação é transmitida. Espero que essa revolução aconteça as soon as possible porque do jeito que está, não pode ficar.