Archive for the ‘Video’ Tag

QoS Parameters for Video Streaming

When we talk about professional media streaming, there is a lot concern with the quality of service, especially when we have large volumes of requests, or when we delivery contents in high definition. In this scenario, is essential to have a fairly clear idea about what is quality of service, and how we can identify, through objective parameters, if we’re or not at an acceptable level, which ensures a high quality experience for end users.

In the case of video streaming, quality of service means that the user should watch a certain content, without interruption (rebuffering), and without degradation of video quality caused by the delivery process (loss of frames, problems in the reconstruction of b-frames and p-frames due packet loss).

Thus, the best known parameter for evaluating the quality of a streaming service is the buffer length, which is the ability to maintain the user’s buffer always at an acceptable level, being greater enough to ensure a continuous experience independent of small variations in bandwidth available, and in the bitrate of the encoded video. Associated with this parameter, we have the average rebuffering rate, which consists of a ratio between the total time used filling the buffer, and the total playing time. This parameter is very interesting to assess the quality of service for live streaming, where users can stay connected for a long time, and, of course, they would like to play the content without interruptions.

A high quality streaming service should always keep the rate of rebuffering below 0.5%, discarding the initial buffer, at normal bandwidth availability. Moreover, this parameter can be very useful to identify network bottlenecks at content distribution process.

Another key parameters are the average frame rate and the rate of frame loss. These two parameters give us an overview of the capacity, of the server to stream the video content, and, of the users to receive and decode the stream. In case of server overloading , one of the first alternatives used to maintain a continuous experience is to reduce the frame rate, or basically, drop frames. These parameters usually indicate that either the server is not able to serve the content, or, the clients do not have the minimum conditions to receive and decode the video. These problems are usually associated with intensive CPU usage, due an excess of clients in the server side, or by lack of resources for decoding the video on the client.

For Flash Media Server specifically, some parameters related with memory usage for input and output buffer, size of buckets, and use of aggregated messages, can influence directly in the video frame rate, but in this case, we can detect the problem even with a small amount of users.

Finally, we have some parameters, not least importants, to complement the set of basic checkpoints to ensure the quality of streaming video service, including, the time to establish the connection, the rate of reconnection, the sync between audio and video, and psnr between the video decoded by the user and the video that comes out of encoder (since the loss of packets may influence the reconstruction of the frames, especially for temporal video compression). Measuring and evaluating all these parameters we can identify with much more efficiency any problem that might compromise the quality of service, which is essential for professional media streaming business.

Advertisements

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!!!

Otimizando um Servidor Web para Download Progressivo

No dia 27 do mês passado estive no Congresso SET, da Sociedade Brasileira de Engenharia de Televisão e Telecomunicações, onde apresentei junto com o Marcello Azambuja um artigo sobre Arquiteturas de Distribuição de Vídeos na Internet. Porém, devido ao tempo bastante limitado da apresentação, não pude entrar em detalhes mais específicos de como otimizar as arquiteturas para obter um melhor desempenho. Por isso, resolvi colocar um pouco do que está no artigo aqui no blog, já que nem todo mundo que tem interesse neste assunto estava na apresentação. (O slides podem ser vistos aqui)

Assim, resolvi começar falando especificamente sobre o Download Progressivo, ou seja, como podemos otimizar um Web Server para que ele seja capaz de servir a maior quantidade de usuários possível. No caso de distribuição de vídeos via Progressive Download temos algumas características básicas que devem ser consideradas para otimização:

  • As conexões com o WebServer são persistentes, ou seja, o usuário fica conectado ao servidor por uma quantidade razoável de tempo, até que o conteúdo seja completamente copiado;
  • Dependendo da quantidade de vídeos diferentes podemos ter diversos conteúdos diferentes sendo acessados simultaneamente;
  • Os arquivos de mídia não estão necessariamente nos discos do servidor. Eles podem estar em um repositório central sendo acessados pelo servidor Web através de NFS/CIFS;
  • A quantidade de acessos ao serviço pode aumentar rapidamente, variando de acordo com o conteúdo disponibilizado;

Com estas características já podemos identificar alguns gargalos principais:

  • Tráfego de rede: muitos usuários conectados realizando download irão rapidamente ocupar a banda disponível. Além disso, existe a ocupação de banda pela cópia dos arquivos do repositório central para o servidor;
  • IO (Repositório Central e Disco Local): muitos usuários realizando download significa muito IO de leitura, que é maior a medida que temos mais usuários acessando arquivos diferentes;
  • Memória: quanto mais usuários, mais memória o Apache irá precisar para atendê-los, e quanto mais arquivos, mais memória o kernel irá utilizar para cache;
  • CPU: quanto mais usuários mais processamento para organizar e servir as requisições;

Na verdade, se queremos obter o máximo de uma arquitetura não podemos nos limitar a olhar apenas um componente. O primeiro ponto, e mais simples, consiste em alterar as configurações do Apache, escolher a versão correta (2.X), e compilar uma versão do Web Server que tenha apenas aquilo que é relevante para a distribuição de arquivos, ou seja, devemos evitar incluir na configuração de compilação módulos que não serão utilizados, como mod ssl, por exemplo.

Uma vez compilado cabe a nós decidir qual arquitetura interna de funcionamento possui uma performance maior: se é a multi-process (Apache Prefork) ou a multi-process/multi-thread (Apache Worker).

Basicamente, no prefork, para cada conexão será criado um processo específico para atendê-la, de modo que a quantidade de processos httpd será sempre maior ou igual a quantidade de clientes. Nesta arquitetura, temos uma quantidade inicial que processos que são pré-criados para atender as conexões, sendo que a medida que os clientes se conectam, eles são atendidos por estes processos. No prefork, temos basicamente dois problemas em termos de performance:

  • Memória: cada processo criado ocupa uma porção da memória, de modo que a memória disponível para cache do kernel é cada vez menor, ao ponto que toda ela é preenchida pelos processos httpd, momento onde o servidor começa a fazer swap em disco;
  • Load: a criação de novos processos (fork) gera um overhead no sistema, de modo que quanto maior a taxa de conexão, maior será o overhead no fork para atender as novas conexões;

A outra opção de MPM, o worker, trabalha com o conceito multi-thread, onde as requisições são atendidas por threads e não por processos. Assim, teríamos apenas um ou poucos processos com múltiplas threads em cada um deles, atendendo cada uma das conexões. Com o worker, minimizamos a utlização de memória, já que as threads compartilham a mesma área de memória do processo pai, e reduzimos o overhead na criação de processos. Na verdade, no caso do worker, definimos a quantidade de threads por processo de modo que só realizamos um fork quando este limite é atingido.

A escolha entre prefork ou worker deve ser realizada caso a caso, ou seja, dependendo da situação de uso e da configuração de hardware uma escolha poderá ser melhor que a outra. No caso específico de servidores para utilização em distribuição de vídeos em Progressive Download, a escolha do MPM Worker é recomendada, com o objetivo de reduzir a ocupação de memória pelo servidor Web, deixando-a livre para que o kernel possa utilizá-la para cache de conteúdo, reduzindo o IO no disco e conseqüentemente o tempo de resposta da requisição. Uma configuração interessante seria neste caso seria forçar a criação de todos os processos filho (children) e suas threads no momento que o servidor Web for iniciado, reduzindo assim o overhead de controle de threads.

Além de configurar o MPM, o Apache permite diversas outras configurações capazes de aumentar o desempenho do mesmo, como a possibilidade de desabilitar Hostname Lookups e DNS resolving, e outras que podem ser encontradas na documentação do Apache.

Entretanto, quando falamos de arquiteturas de distribuição de vídeo que recebem grandes volumes de acesso, devemos nos preocupar um pouco mais em como otimizar o processo de distribuição. Uma das maneiras mais eficientes de aumentar a capacidade de uma infra-estrutura de Download Progressivo consiste em realizar um processo de cache intensivo. Ter uma estratégia de cache de conteúdo é fundamental quando falamos de alta performance com um grande volume de acessos. Quando temos um volume muito grande, temos também diversos requests ao mesmo conteúdo. Processar todo o request para cada cliente consistiria em repetir as mesmas operações diversas vezes, sem aproveitar para um request os dados processados por outro. Assim, fica claro que podemos otimizar este processamento, simplesmente aproveitando aquilo que serve para mais de uma requisição.

Em situações onde temos uma arquitetura onde o Apache funciona como uma espécie de “proxy” entre o usuário e um repositório central de vídeos, essa necessidade é ainda mais latente, uma vez que não faz sentido obter um mesmo arquivo diversas vezes neste repositório para servir para os clientes a cada request semelhante. Uma vez copiado do storage para o Apache, para servir uma requisição, o arquivo pode ser mantido no servidor Web para as requisições posteriores realizadas ao mesmo vídeo. Com essa abordagem, reduzimos a carga no storage e o tráfego de rede e de operações de cópia.

Para realizar o cache de conteúdo existem diversas alternativas, como o Squid e o mod_cache. O mod_cache, por estar integrado ao Apache e por ser bastante conhecido e utilizado, além de apresentar uma ótima performance, é uma excelente opção para cache em arquiteturas de distribuição em Download Progressivo.

O mod_cache permite duas abordagens principais de cache: disco ou memória. O mod_disk_cache é o módulo responsável pelo cache em disco, e funciona da seguinte forma: ao receber um request, o mod_disk_cache verifica se o conteúdo solicitado já está no cache em disco. Se estiver, o módulo valida se o conteúdo não está expirado e serve o mesmo a partir do cache, sem que a requisição seja passada aos demais módulos do Apache. Caso, não esteja cacheado, o request passa pelo path normal de atendimento ao request, sendo que, ao finalizar o processamento, o mod_cache escreve a resposta no cache antes de servir a mesma. Assim, ele cria dois arquivos em disco: o .data, com o conteúdo do request, e o .header com os headers da resposta. O nome dos arquivos criados é criado a partir de um hash, para evitar que o conteúdo seja sobre-escrito.

O mod_mem_cache, é o módulo responsável pelo cache em memória, e funciona de forma semelhante ao mod_disk_cache, porém armazenando o conteúdo em memória.

A escolha de um dos módulos para utilização em um servidor de Download Progressivo também depende da configuração do hardware. Entretanto, em servidores que rodam em Linux, o uso do mod_disk_cache é recomendada, uma vez que o gerenciamento do cache em memória feito pelo kernel é bastante eficiente.

Com um web server bem otimizado e configurado, e com uma estratégia de cache eficiente, temos uma arquitetura de distribuição muito mais robusta e capaz de atender um volume até 70% maior que o volume que atenderíamos utilizando apenas um servidor com as configurações “default”, o que reduz de forma significativa os custos de investimento para expansão da capacidade, tornando esta uma opção bastante interessante para distribuição de vídeos na internet.

Generalizando os conceitos de Integração Contínua

A utilização de processos de integração contínua no desenvolvimento de software, é hoje algo bastante corriqueiro em ambientes onde existe uma preocupação com a qualidade do código. A implementação de testes unitários e a execução dos mesmos de forma periódica, garante que o funcionamento de cada um dos componentes seja validado, o que impede a introdução de bugs, principalmente quando estamos falando do desenvolvimento de novas funcionalidades em uma aplicação já existente. Este conceito de integração contínua é tão importante para o processo de desenvolvimento, que por várias vezes me perguntei como poderíamos generaliza-lo para utilização em situações diferentes.

Quando conhecemos a complexidade dos processos de codificação de vídeos, nos deparamos com uma imensa quantidade de variáveis que podem interferir na qualidade do vídeo codificado, de modo que é praticamente impossível garantir que um determinado processo de codificação sempre irá gerar resultados satisfatórios. Além disso, fatores externos, como sistema operacional, hardware, etc, também influenciam nos resultados obtidos, seja na velocidade de codificação, seja na própria integridade do conteúdo.

Em ambientes de produção de vídeo em alta escala, é fundamental garantir que todas as variáveis que influenciam no processo de codificação estejam sob controle, de modo que os impactos de qualquer alteração sejam rapidamente identificados, antes que elas sejam efetivamente aplicadas no ambiente de produção. Se fizermos um paralelo com os processos de desenvolvimento de software, o que precisamos é exatamente o que a execução contínua de build e testes faz, ou seja, garante que não houve quebra de funcionalidades gerada por alterações no software.

Para exemplificar, podemos citar um processo de codificação com o Windows Media Encoder (Para quem não conhece, o Windows Media Encoder é um codificador WMV da Microsoft, bastante popular para quem usa Windows Media Video). Devido à uma alteração nas bibliotecas utilizadas pelo WME feita pela atualização do SP2 do Windows XP, podemos ter um aumento no tempo de codificação, além de alguns erros com arquivos específicos. Isto significa que a simples atualização do Service Pack do sistema operacional pode influenciar bastante no processo de codificação. Se, neste cenário, temos um processo de codificação contínuo, então essas diferenças seriam facilmente identificadas, antes que esta atualização fosse efetivamente aplicada.

Entretanto, ter simplesmente um processo de codificação que roda constantemente não é o suficiente para garantirmos a integridade de um ambiente. É de fundamental importância ter uma quantidade grande de mídias de diferentes perfis, ou seja, ter diversas mídias, de diversas durações, com vários tipos de conteúdo distintos e de várias fontes diferentes. Desta forma, com uma biblioteca de conteúdo diversificada e com um processo de verificação contínuo, temos como analisar de forma eficiente um ambiente de codificação.

Outro ponto importante no processo de codificação de vídeos é que a maioria deles não é “binário”, ou seja, se você codificar o mesmo vídeo 100 vezes, você não terá a mesma saída 100 vezes. Por isso, além de codificar continuamente diversos vídeos diferentes, é bastante importante codificar o mesmo vídeo repetidamente, sendo que este vídeo deve ser escolhido dentre um universo por ser aquele que apresenta a maior taxa de erros. Desta forma, estamos introduzindo mais uma validação de integridade.

Não conheço nenhuma ferramenta pronta para execução de testes desta natureza, porém, é relativamente simples escrever uma. Claro que se você deseja um output gráfico, em tempo real, é necessário dedicar um tempo razoável para isto, mas nada que não seja justificado pelos ótimos benefícios obtidos com esta prática.

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.

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.

[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.

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.

God Damm Flickering!

Nos últimos dias, estava realizando uns testes de reprodução de vídeo no flash player, e percebi algo extremamente desagradável: havia um flickering absolutamente irritante quando estávamos reproduzindo um vídeo de alta qualidade, com grandes dimensões, e com bastante movimento, principalmente vertical. Certo de que este era um problema específico da minha máquina (Linux Ubuntu), não me preocupei muito, e continuei meus testes, até que resolvi testar um vídeo em um Windows rodando em um Dual Quad Core com placa de vídeo de 256MB. Por incrível que pareça, o maldito flickering ainda estava lá.

Reproduzindo os mesmos vídeos em outros players não obtive problemas, o que me leva a desconfiar bastante do flash player. Finalmente, para ter certeza de que não estava fazendo nada errado, resolvi testar as versões HD dos principais sites de vídeo (YouTube, Vimeo, etc)  vendo vídeos com bastante movimento, e o que eu descobri é que todos eles tem o mesmo problema.

Flickering

Se for realmente um problema de Flash Player, aí as coisas ficam realmente complicadas. Como a Adobe quer que as pessoas utilizem o flash player para distribuição de H264 se o vídeo fica flickando?

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.