Archive for the ‘Compression’ Tag

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

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!