Archive for the ‘Compression’ Category

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.

Advertisements

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.

Analisando objetivamente a qualidade de um vídeo

Num post anterior aqui do blog, falei sobre alguns dos desafios de se produzir conteúdo em vídeo para distribuição na internet, principalmente no que se refere à relação bitrate vs. qualidade. Entretanto, não deixei claro como chegar em uma relação ideal, ou seja, o quanto podemos diminuir o bitrate de modo que a qualidade fique dentro de um limite aceitável. Na verdade, toda e qualquer análise de bitrate, codec, filtros, etc, consiste em uma avaliação direta de qualidade do vídeo. Mas como saber, de forma objetiva, se um vídeo tem ou não qualidade, já que cada pessoa tem uma percepção visual diferente?

Normalmente, quando deseja-se saber se um determinado vídeo está ou não bom, mostramos ele para outras pessoas para obter uma opinião comum. Porém, este processo não é confiável uma vez que pessoas diferentes podem ter percepções visuais e critérios de avaliação completamente diferentes. Apesar disso, este tipo de avaliação subjetiva também é importante e foi inclusive utilizado na definição do codec para o Padrão Brasileiro de TV Digital.

O método objetivo de avaliação de qualidade de vídeos e imagens mais aceito na comunidade científica hoje é o PSNR (Peak Signal Noise Ratio). Como o próprio nome já diz, o PSNR é uma relação entre o máximo possível de potência de um sinal, pela potência do ruído, quando comparamos um sinal antes e depois de um processo de degradação, sendo que a unidade utilizada para representa-lo é o dB (decibel). Aplicando este conceito em vídeos e imagens, temos que o PSNR é a relação entre a entrada e a saída de um processo de compressão com perdas, que avalia o quanto a compressão introduziu ruídos na imagem ou frame original. Matematicamente o PSNR de uma imagem de dimensão m por n é representado por:

PSNR

onde MAX é o valor máximo possível de um pixel e MSE (Mean Square Error):

MSE

Desta forma, quanto maior o valor do PSNR, maior é a relação entre a potência do sinal pela potência do ruído, o que significa melhor qualidade. Em termos gerais, valores de PSNR acima de 42dB correspondem à compressões que introduzem perdas imperceptíveis ao olho humano, o que significa uma qualidade excepcional. Podemos considerar que vídeos com PSNR acima de 36dB tem qualidade bastante aceitável, entre 30dB e 36dB teremos uma qualidade mediana e abaixo de 30dB a qualidade já é bem ruim. Abaixo temos uma comparação geral dos codecs mostrando a relação entre PSNR e bitrate:

PSNR vs. Bitrate

Para facilitar a análise do PSNR, dois dos principais softwares Open Source de codificação de vídeos (mencoder e ffmpeg) já possuem esta funcionalidade integrada, basta colocar a opção -psnr que os valores serão exibidos:

Input #0, flv, from 'xxxxxx.mp4':
  Duration: 00:01:58.7, start: 0.000000, bitrate: 128 kb/s
  Stream #0.0: Video: vp6f, yuv420p, 1280x720, 29.97 fps(r)
  Stream #0.1: Audio: mp3, 44100 Hz, stereo, 128 kb/s
Output #0, avi, to 'teste.avi':
  Stream #0.0: Video: mjpeg, yuvj420p, 1280x720, q=2-31, 0 kb/s, 29.97 fps(c)
  Stream #0.1: Audio: mp2, 44100 Hz, stereo, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Press [q] to stop encoding
frame= 434 q=24.8 LPSNR=Y:34.90 U:42.65 V:43.10 *:36.33 size= 14868kB time=14.5 bitrate=8410.7kbits/s

Assim, utilizando o PSNR podemos ter um valor numérico que representa a qualidade geral do vídeo, o que ajuda bastante quando estamos lidando com ajustes finos em parâmetros de encoding.

O Dilema da Qualidade dos Vídeos

Freqüentemente, quando encontro alguém que eu não conheço, e digo que trabalho na área de mídia da Globo.com, a primeira pergunta que me fazem é se eu edito os vídeos e coloco eles na internet. Daí eu explico um pouco melhor, dizendo que não, que desenvolvo novos projetos e tecnologias para diferentes etapas do processo de captura/produção/publicação dos vídeos, daí então a segunda pergunta sempre é relacionada a qualidade dos vídeos. Ou perguntam porque não melhoramos a qualidade (essa pergunta já foi bem mais freqüente, e hoje caiu em desuso), ou dizem que demora para carregar, ou dizem que o vídeo é pequeno, ou trava toda hora, etc. De uns tempos pra cá, depois que passamos a utilizar Flash Vídeo, até que as perguntas estão mudando, porque ficou melhor pra muita gente! Em suma, é bem comum que as pessoas questionem a qualidade, até porque elas estão acostumadas com a excelente qualidade da TV Globo.

Outra observação importante que eu fiz é que a maioria das pessoas que fazem essas perguntas não entendem nada de internet, elas são apenas usuários leigos, sem formação ou vocação tecnológica. Então, resolvi escrever um post para tentar explicar de forma bem clara como as coisas funcionam, e como lidamos com o “cobertor curto” diariamente.

Para que um vídeo seja disponibilizado na internet, é necessário percorrer um caminho relativamente simples. Primeiramente, precisamos capturar o sinal de TV e digitalizar ele em arquivos de vídeo. Esse arquivo é o vídeo bruto, em excelente qualidade, que será editado (cortado, etc). Uma vez editado, o vídeo é preparado para distribuição na internet, ou seja, ele é transcodificado. Neste momento, transformamos o vídeo editado de altíssima qualidade para um formato padrão de distribuição na internet. Atualmente utilizamos Flash Vídeo, porém, poderíamos utilizar Windows Media, Real, etc. Uma vez transformado, o vídeo é colocado nos servidores para que os usuários possam acessar.

De todo esse processo, basicamente o que define a qualidade final do vídeo é a transcodificação. Nela não só alteramos o formato (chamado encapsulamento), como também aplicamos uma compressão, e é aí que mora o problema. Se pensarmos um pouco e fizermos uma conta simples, iremos ver que a quantidade de informação de um vídeo de alta qualidade é imensa, e seria impossível transmitir este vídeo na internet. Vejamos: supondo um vídeo com 320 pixels de largura por 240 de altura, teremos por frame de vídeo 76800 pixels; considerando que o vídeo tem 30 frames por segundo; e considerando uma resolução de 8 bits por pixel; desconsiderando o áudio, as cores, etc, teremos:

76800 x 30 x 8 = 18432000 bits/segundo de vídeo = 17.57Mbps

Agora eu pergunto quantas pessoas no Brasil tem 17.57Mbps de conexão de internet?!

A solução para este problema consiste em comprimir a informação do vídeo, retirando as redundâncias existentes nele. Quanto mais redundância tirarmos, menos bits por segundo serão necessários, mais fácil fica ver o vídeo, menos qualidade teremos na imagem. Esta é a relação da discordia. Além disso, existem diferentes forma de retirar a redundância de um vídeo, umas mais e outras menos eficientes. Estas diferentes maneiras são os famigerados codecs (VP6, H264, WMV9, MPEG2, MJPEG, DV, etc ), que implementam os algoritmos de compressão dos vídeos. Atualmente o algoritmo mais eficiente de compressão é o H264, que é inclusive utilizado nas transmissão de TV Digital no Brasil.

Assim, dada que a taxa média de velocidade do usuário brasileiro fica em torno de 300kbps (o que é ridículo!!!), é necessário comprimir bastante, muito mesmo, o que acaba degradando a qualidade. Por outro lado, para ter uma qualidade mais razoável, precisamos de algo em torno de 600kbps, 800kbps, porém iremos onerar a velocidade com que o usuário carrega o vídeo. Conciliar velocidade e qualidade é uma tarefa difícil, mas não impossível. Podemos utilizar uma série de filtros e algoritmos de processamento de imagens para maximizar a percepção de qualidade, e, a medida que a tecnologia avança, podemos melhorar os próprios algoritmos de compressão do vídeo. De qualquer forma, não existe milagre! Maior qualidade, maior tamanho, etc, ocasiona em mais bitrate.

O que eu posso dizer a respeito dos vídeos da Globo.com, é que temos um processo de avaliação de qualidade bastante rígido e objetivo, dentro das limitações de bitrate que definimos. E podem esperar, porque ainda teremos muitas novidades este ano!