O post abaixo foi publicado originalmente no blog Diary Of An x264 Developer (Diário de um desenvolvedor de x264- em referência ao codec livre de vídeo). No espaço atualizado por Jason Garrett-Glaser, também desenvolvedor de ffmpeg, o autor mostra seu ponto de vista sobre o futuro do vídeo na internet, levando em consideração os avanços no suporte ao HTML5, as ações do Google, da Adobe, a possibilidade de adoção de vídeo livre pelas empresas e, é claro, o desenvolvimento do x264.
Replicamos o conteúdo devido à argumentação e sustentação dos pontos de vista defendidos pelo autor. O que não significa estarmos de acordo com eles. A tradução foi incluída na pesquisa por mostrar uma visão em relação ao que pode acontecer com o mercado de vídeo online. Outras opiniões são possíveis. Deixamos aberto aqui o debate.
Flash, Google, VP8 e o futuro do vídeo na internet
Publicado originalmente em: http://x264dev.multimedia.cx/?p=292
Há tempos se vê na internet um grande número de posts reclamando do Flash. A posição é válida: o Flash tem uma performance horrível em qualquer sistema diferente do Windows 86 e a Adobe parece não se importar com isso. Mas, em vez de repetir as críticas, vamos tentar aprofundar um pouco e entender o que acontece.
A popularidade do Flash se deve ao seu poder e flexibilidade. Na época, era a única opção para vetores gráficos animados e conteúdo interativo (como, por exemplo, o VMRL- Linguagem para Modelagem de Realidade Virtual, um padrão de formato de arquivo para realidade virtual). Além disso, antes do Flash, as opções de vídeo eram Windows Media, Real e Quicktime: todos proprietários, sem codificadores ou decodificadores de software livre, e (exceto o Windows Media) era necessário ao usuário instalar um aplicativo externo e não apenas um plugin. Dado tudo isso, fica claro porque o Flash ganhou: ele suportava os formatos multimídia abertos como H.263 e MP3, usando um formato contêiner ultra-simples que qualquer um poderia escrever (FLV), e trabalhava de forma mais fácil e segura às outras alternativas que se tinha.
Assim, a Adobe (na época, Macromedia) conseguiu 98% de sua base. E com isso, começaram a se tornar complacentes. Qualquer sugestão de um concorrente era imediatamente descartada: como alguém poderia, eventualmente, competir com a Adobe, dada a grande base instalada? Isso seria insano, ninguém seria capaz de fazê-lo. Eles cometeram o pecado original de desenvolvimento de software: acreditar que um concorrente ser melhor era perdoável. No x264, se encontrarmos um concorrente que faz algo melhor, nós imediatamente olhamos para tentar nos colocar de volta no topo. É por isso que x264 é o melhor encoder de vídeo do mundo. Mas na Adobe, esta atitude claramente caiu depois que virou um monopólio. E este é o verdadeiro perigo dos monopólios: eles impedem o desenvolvimento, porque o monpolista não tem incentivo para melhorar o seu produto.
Em suma, eles viveram a maré alta, mas estavam errados em alguns pontos críticos:
O primeiro erro foi supor que Linux e OS X não importavam. Linux é um sistema operacional usado por uma minúscula minoria de usuários finais, mas essas pessoas formam uma parcela enorme de desenvolvedores web e de software do mundo. Apenas olhando para o número de usuários, pode-se pensar que não vale a pena otimizar. Então, a Adobe colocou apenas um desenvolvedor para a plataforma Linux inteira. Em termos de OS X, o Mac se tornou muito popular nos últimos anos – especialmente entre esse mesmo grupo de desenvolvedores. E além disso, a Apple é uma empresa enorme. Flash funcionando terrivelmente em sua plataforma é um grande incentivo para a Apple ficar na posição. Assim, a Adobe criou como inimigo a Apple e os desenvolvedores.
O segundo erro foi atacar o software livre. Praticamente todos os sites na internet usam soluções livres em seus servidores – e não apenas no LAMP (Linux Apache Mysql Php)– ['padrão' de aplicativos opensource usado para rodar paginas web]. Youtube, Facebook, Hulu e Vimeo todos usam ffmpeg e o x264. Codificador H.264 no Adobe Flash Media Encoder é tão horrível que é muito pior do que H.263 ffmpeg ou Theora, eles estão praticamente assumindo que os usuários irão utilizar x264 no lugar. Para software de servidor real, o software livre Red5 é extremamente popular para sistemas baseados em RTMP. E, além de tudo isso, a Adobe enviou um pedido para parar as atividades dos servidores de hospedagem RTMPdump, alegando (absurdamente) que eles violavam a DMCA ao permitir aos usuários salvarem streams de vídeo em seu disco rígido. RTMPdump não morreu, é claro, e era apenas um programa, mas esse ataque permaneceu na mente dos desenvolvedores de todo o mundo. Ficou claro para eles que a Adobe não era amigo do software livre.
O terceiro erro é não ter apoiado uma implementação em software livre do Flash. A falta de um bom Flash em software livre não é culpa da Adobe; ficou ainda claro que os seguidores do Gnash são incompetentes e não despertou o interesse de muita gente. O desenvolvedor Cody Brocious escreveu seu próprio código renderizado de Flash em questão de dias para propor um aplicativo de conversão do Flash para o iPhone. Ele só parou porque a Adobe lançou sua própria versão poucos dias antes dele lançar a sua. A especificação do Flash é aberta, e não há registro de implementações de software livre de algum codec em Flash: não há nada impedindo uma boa implementação gratuita. Mas o erro da Adobe é o da falta de ação: eles não pressionam para isso porque não é importante para eles.
Por comparação, olhe a Moonlight, a implementação em software livre do Silverlight. A Microsoft tem trabalhado ativamente com a comunidade de software livre para ajudar a produzir Moonlight. Pense em como isso soa absurdo; Microsoft – bane o do software livre e tem apoiado ativamente uma LGPL projeto de software livre, enquanto a Adobe não! O maior problema que isso cria é de um monopólio: as pessoas se sentem inseguras usando Flash porque há apenas uma aplicação, deixando-as à mercê da Adobe. Em qualquer situação, quando existem várias implementações populares de um formato de arquivo, é muito mais difícil de se cometer abusos. Evidentemente, isso é intencional por parte da Adobe: eles querem ter o poder de abuso, o que explica por que eles não suportam uma aplicação alternativa.
Agora fica claro por que o Flash é tão detestado. É longe o mais inseguro de plugins do browser popular; Java tem muito mais vulnerabilidades de acordo com a Secunia. Não é certamente o menos confiável, nem é totalmente proprietári— como mencionado anteriormente, a especificação é pública. No entanto, por causa dos três erros acima a Adobe tem se tornado inimiga de desenvolvedores no mundo inteiro.
Mas e agora? Flash é horrível, nós odiamos o Flash. Mas como se livrar dele pelo menos no que diz respeito ao vídeo na internet?
Vamos começar com HTML5 . É evidente que, salvo um ato de Deus (ou o Google, mais cedo ou mais tarde), se o Flash for suvstituído num futuro próximo esta será a forma. No momento, ainda existem muitos problemas, a maioria dos quais devem ser resolvidos para que exista alguma chance:
1. Características ausentes. Desenvolvedores que não trabalharam com o Flash, muitas vezes, subestimam suas capacidades e assumem que exibir um vídeo é tão simples como exibir imagens. Mas há muitas coisas que são úteis para o controle. O Flash permite dizer ao cliente quanto tempo terá que esperar antes de começar o stream (muito importante para a reprodução de qualquer vídeo ao vivo). Ele fornece sinalização de volta ao servidor de taxas de perda de pacotes, de modo a permitir o servidor acelerar a banda de acordo.
Há dezenas de outras, essas são apenas alguns exemplos. Mas este é o principal problema mencionado no início deste artigo, o problema que atingiu a Adobe tão fortemente: “acreditar que ter um concorrente melhor é desculpável”. Muitos defensores do software livre promovem o HTML5 declarando que a falta desses recursos não é um grande problema e que podemos viver sem eles. Isso não é desculpável! Se você quiser desbancar a Adobe, você precisa fornecer um superconjunto de todos os recursos mais usados.
2. Vídeo/ áudio /formato de contêiner. Theora é difícil de vender para a maioria das empresas, dada a sua compressão muito pior do x264 e H.264 e da falta de direitos de vídeo na web. É complicado tentar convencer o mercado de alguma coisa com benefícios nebuloso. Ser “patente-livre” pode soar agradável para os defensores do software livre como nós, mas a maioria das pessoas de negócios só se preocupam com a linha de frente, e se ser “patente-livre” não resolve seus problemas, eles provavelmente não vão se importar. (Nota: um comentarista observou que o H.264 tem licença livre apenas para o conteúdo livre e não para o conteúdo pago. Isso provavelmente não é um grande problema, uma vez que a porcentagem de royalties é muito pequena para conteúdos pagos, e se você está cobrando por conteúdo pode provavelmente ter recursos para pagar os honorários de pequeno porte. Mas, obviamente, é uma situação um pouco diferente.).
Mas mesmo se você ignorar a questão da compressão, a maioria das empresas não gostam de guardar várias versões de cada vídeo – eles ainda precisam H.264 para suporte do iPhone. Fazendo uma observação, Dirac é uma opção potencial de patente livre e pode fornecer uma melhor compressão, mas é mais lento para decodificar quando comparado ao Theora. É definitivamente uma opção a considerar, e que muitas vezes é ignorada quando se fala em formatos de vídeo para HTML5.
O Youtube, por exemplo, tem jogado fora petabytes de largura de banda na busca de versões menores de cada vídeo: o padrão “baixa qualidade H.264″, que agora usa o x264, é o básico no perfil. Oferecer uma alternativa maior poderia salvá-los 30-50% de banda para os usuários de desktop, que compõem a grande maioria dos usuários do YouTube. Mas seria necessário armazenar uma outra cópia do vídeo (já que é necessário para iPhones), o que é muito caro para eles. Para duplicar cada vídeo novamente seria necessário algum benefício – e, aparentemente, o Google acredita que uma melhor compressão de 30-50% não é suficiente, e parece haver algo estranho acontecendo com os 360p/480p que recentemente desenrolaram (que nem High Profile é).
Claro que, apesar de receber 50 milhões dólares a cada ano do Google, a Mozilla nunca vai pagar as taxas de licença H.264, nem eles provavelmente vão apoiar os usuários a instalar os seus próprios codecs. Assim, estamos em um impasse. Se a Microsoft suportar o HTML5 no IE9, o que é perfeitamente possível, é quase certo que vão suportar o H.264 e não o Theora. Então, mesmo ignorando o caso de dispositivos móveis como o iPhone, nem H.264 nem Theora abrangerá todo o mercado. O que as empresas vão escolher? A maioria vai enxergar a divisão de mercado como razão para evitar o completamente e voltar para o Flash.
3. Ubiquidade. Flash tem 98% da base de instalação do mercado, uma força poderosa. Até o Internet Explorer tornar-se um navegador da baixa popularidade -(improvável no curto prazo) ou suportar o HTML5, o Flash simplesmente não será substituído. Além disso, isso efetivamente força os sites a usar H.264: se quiserem apoiar o Flash e o HTML5, usar Theora irá forçá-los a armazenar duas cópias redundantes dos vídeos, que o Flash não suporta Theora.
4. Qualidade de implementações. As implementações do HTML5 existentes variam de mau a pior, apesar dos anos que os desenvolvedores estão batendo no Flash. Muitas das implementações são mais lentas que os players de mídia nativos, usam escala pixelada (por exemplo, o Chrome), estão cheios de bugs ou tem todos esses problemas citados. Não são apenas as implementações que são ruin, muitas vezes a concepção já é inconsistente. E mesmo que algumas funcionem bem, não adianta se muitas outras não.
Com todos esses problemas, HTML 5 parece estar em grave perigo apesar das promessa. E isso nos leva ao tema principal: o que aconteceu com o Google, On2, e VP8? Se, como a FSF defende freneticamente, o Google coloca o VP8, que problemas isso resolve equais problemas que se criam? E quais os benefícios que isso traz para o Google?
VP8 resolve o problema de compressão: que ainda provavelmente não é tão boa como a do x264 (ver a adendo no final para obter mais detalhes sobre essa previsão), mas a diferença já é muito menor do que com Theora, o suficiente para que a compressão não seja mais uma questão. Mas também traz uma série de novos problemas:
1. Anos atrás, a Microsoft relançou o WMV9 proprietário como o software VC-1, alegando ser livre. Alguns meses depois, dezenas de empresas se pronunciaram dizendo ter a patente do VC-1. Em um ano, o lincenciamento do VC-1 foi instituído e as patentes “livre” deixaram de existir. Qualquer suposição de que o VP8 está completamente livre de patentes é provavelmente um pouco prematura. Mesmo se isso não acontecer imediatamente, muitas empresas não vão querer incluir decodificadores VP8 em seu software até que eles estejam confiantes de que isso não é ilícito. Theora vem sendo feito há 6 anos e ainda há muitas empresas (principalmente Nokia e Apple), que ainda se recusam a incluí-lo! Claro que esta atitude pode parecer absurda, mas é preciso entender a estratégia de marketing. Uma pessoa não pode se livrar dos empresários com medo de patentes ignorando-os.
2. VP8 é proprietário, e mesmo se abrir, ainda vai ter muitos dos problemas de um formato proprietário. Provavelmente existirão bugs que nunca serão revistos porque apenas uma implementação foi escrita (veja RealVideo para ter um exemplo disso). Haverá apenas uma aplicação por algum tempo; Theora vem sendo desenvolvido há 6 anos e até agora há apenas um codificador. A falta implementações competitivas gera complacência e estagna o progresso. E dada a qualidade do On2 lançado no passado, eu não tenho muita esperança para o código-fonte real do VP8, ele provavelmente terá que ser totalmente reescrito para obter uma alta qualidade compativel a uma implementação em software livre.
3. Ele não resolve os problemas de compatibilidade de hardware: a maioria dos dispositivos móveis utiliza ASICs para decodificação de vídeo, os quais provavelmente não podem ser facilmente redirecionado para VP8. Esse pode ser um problema menor se eles focarem em implementações de software para isso, o que poderia gastar mais bateria e ser limitado por dispositivos móveis com processadores poderosos. Não seria razoável reproduzir VP8 em um chip ARM rápido (veja o adendo para saber mais sobre isso).
A grande vantagem do VP8 é que resolve um problema insolúvel para Theora: Theora está para sempre prejudicada pela sua tecnologia obsoleta e conjunto fraco de recursos. Com RD e otimização de psy, como no x264, Theora pode provavelmente tornar-se competitivo com Xvid ou mesmo com WMV9, mas provavelmente não com x264. A única maneira de corrigir isso seria um “Theora 2″, mas garantir a patente livre do Theora e adicionar novos recursos seria muito difícil no atual ambiente de patentes de software. VP8, por outro lado, oferece um salto imediato para o que se espera de H.264, em relação a nível comparável de compressão.
E agora a grande questão: por que o Google pretende abrir VP8 e, se o fizerem, como será? O Google provavelmente não quer pagar um centavo das taxas de licença para Youtube. H.264 é gratuito, pelo menos até 2016 para distribuição pela Internet, mas taxas de codificador se aplicam a quem tiver mais de 100.000 servidores de codificação. O custo das licença para Chrome são mínimos (alguns milhões de dólares por ano, no máximo). Mas, apesar disso, há realmente alguns bons motivos para a ação do Google:
1. Controle. Google pode ver o controle de outras empresas sobre o H.264 como uma ameaça: embora H.264 é licenciado em termos RAND (razoáveis e não discriminatórios, que legalmente não podem ser anti-competitiva), há muitas razões para que o Google queira mais controle. Se eles empurram o VP8, eles podem competir com o Flash pelo HTML5 e também impedir o Flash de rodarem seus vídeos. Como é improvável (pelas razões mencionadas no início do artigo) que a Adobe embarque no VP8, isso cria uma janela de oportunidade para o Google roubar o controle da Adobe.
2. Guerra-relâmpago. A coisa mais arriscada e também mais poderosa que o Google pode fazer é mudar o Youtube exclusivamente para VP8 e criar um novo plugin no browser para suportá-lo (o suporte ao HTML5 é permitido). Dada a popularidade do YouTube, isso provavelmente levará a instalação a 80% da base instalada em questão de um um ou dois meses, efetivamente uma guerra roubando fatias de mercado da Adobe. Este seria poderoso porque não teriam que esperar os navegadores existentes (especialmente o Internet Explorer) passar ao VP8.
3. Trunfo. O Google pode estar preocupado com o futuro. Se o H.264 tiver êxito em eliminar toda a concorrência no mercado web, será bem possível que o MPEG-LA tente abusar da sua posição e comece a cobrar taxas para o uso da web. Talvez MPEG-AL precise de um bom susto para se certificar de que eles nunca consideraram tal coisa. Monocultura de software é perigoso.
Esses parecem ser motivos suficientes, embora um pouco traiçoeiros (especialmente o 2), para o Google fazer esse ataque. Mas nós queremos realmente que o Google tenha tanto controle? Não tenho certeza, mas é uma opção melhor que a Adobe. E vai realmente acontecer? Muito possível, a outra única explicação plausível para uma aquisição de US$ 100 milhões seria a de adquirir patentes para usar em processos de patentes. Daria certo? Dependeria de como eles fizessem isso e o que outras empresas teriam como plano. Depende também do que estão mirando: será que estão tentando empurrar o suporte a hardware também?
Onde o x264 se encaixa em tudo isso? O H.264 certamente não irá acabar, não por agora. Na maior parte do mundo, as patentes de software não são problema. Mas no final, nada disso importa para x264 : vamos continuar nossa missão de criar o melhor software de compressão de vídeo na Terra. Diferentemente da Adobe, não ficamos satisfeito quando somos os melhores, nós mantemos tentando ser ainda melhor. Nós adicionamos novos recursos, melhoramos a compressão, suportamos novas plataformas, melhoramos o desempenho, e há muito mais por vir. Nós não nos importamos que muitos codificadores H.264 estão tão ruins que podem ser batidos por Theora ou Xvid. Nós não nos importamos se VP8 sai; esse é só mais um codificador para bater. Nós estamos aqui para garantir que a melhor escolha é o software livre fazendo constantemente o software livre ser melhor.
E, é claro, nós apoiamos a busca por licença livre, fomatos livres de software multimídia. Existem muitos casos em que ser livre de patentes é mais importante do que compressão, qualidade, desempenho ou até mesmo alguns recursos. Bink Video é um exemplo incrivelmente popular: o uso em dezenas de milhares de jogos, apesar da compressão 10 vezes pior aos formatos modernos de vídeo- se deve à sua licença-livre (embora o software seja proprietário). Se chegar o dia em que o Bink seja substituido por uma alternativa em software livre, nós saberemos que a busca por um software livre de vídeo sem patentes amplamente aceito terã chegado ao fim. Até lá, eu desejo sorte para todos aqueles que perseguem essa meta.
Adendo: O conjunto de recursos do VP8 e a sua capacidade de compressão
Muitas pessoas têm pensado o que é a realidade por trás do VP8, por trás do marketing usual que essas empresas divulgam. Como não há especificação do público e até mesmo o próprio codificador ainda não é liberado, tudo isso é um palpite baseado nas informações que tenho.
O VP8 está sendo divulgado pela assessoria de imprensa como basicamente uma “melhoria do VP7″, com o objetivo de ser mais rápido para decodificar em software nos dispositivos móveis, especialmente aqueles sem SIMD (ARM11, por exemplo). Assim, é razoável começar a abordar VP8 comentando o VP7. O VP7 foi lançado em 2003, na mesma época que os codificadores H.264. Fez sucesso por estar muito melhor do que praticamente todos os codificadores H.264, na época. O motivo não era o VP7 ser melhor ao H.264, mas sim que o On2 tinha um código base bem mais maduro: foi desenvolvido por anos, enquanto a maioria dos codificadores H.264 ficaram prontos nos meses seguintes à finalização da especificação. Mas, o VP7 nunca pegou porque era completamente proprietário; ninguém mais quer ter um codec proprietário. Com o passar dos anos, a On2 nunca atualizou o VP7 e os melhores encoders H.264, como o x264, foram para frente. O VP7 foi em grande parte esquecido, exceto por uma alguns aplicativos como o Skype, que o licenciou.
Agora, vamos analisar o VP7 tecnicamente. Embora eu não saiba muito sobre o processo interno, VP7 é notável em confiar pesadamente em filtros de pós-processamento. Ele não é o único, praticamente todos os codecs da On2 tem isso. Mesmo Theora tem um filtro opcional pós-processamento herdado da VP3. Os filtros de pós-processamento da On2 geralmente trabalham com três categorias: desbloqueio, nitidez, e pontilhado. Este último é útil para evitar o bloqueio em áreas escuras e planas, semelhantes aos efeitos do filtro gradfun do mplayer. O filtro de sharpening ajuda a compensar o efeito natural, a indefinição dos codificadores, que não são muito otimizados visualmente. O filtro de desbloqueio é notório para mexer nas enormes quantidades de texturas e detalhes (exemplo: VP7, x264). E isso também fornece uma vantagem significativa: ao mover muitas características do codec para o pós-processamento, o vídeo passa a ser escalável; um decodificador pode fazer “menos trabalho” enquanto continua reproduzindo o arquivo, embora em menor qualidade. Isso não funcionar se todas as etapas são obrigatórias
Como o VP8 é divulgado como menos complexo que o VP7, é provável que ainda não contenha codificação aritmética, B-frames, ou outros recursos de computação intensiva. Sabemos a partir do material de marketing produzido que uma dos grandes chamarizes era permitir que o codificador escolha entre os modos de interpolação para ter decodificação rápida, se necessário. Claramente, VP8 é mais rápido – o que significa provavelmente não ter um monte de novos recursos de compressão relacionados. Se ele melhorou muito do VP7, será provavelmente devido a otimizações psicovisuais no codificador. Mas, segundo o último press release que mostrava uma comparação com x264, é claro que eles não fizeram isso. A imagem do VP8 é desfocada, sem detalhes, ao contrário ds imagem do x264, que realmente parecia melhor para muitos no Doom9, apesar dos testes obviamente encenados.
No geral, acredito que o VP8 é melhor do que o MPEG-4 ASP (Xvid / DivX) e WMV9/VC-1. Ele provavelmente vai ser quase tão bom quanto o codificador do Mainconcept H.264 (um dos melhores não-x264 codificadores), mas assumindo que ainda acreditam que borrar a imagem inteira é uma boa ideia, provavelmente é inferior ao x264.
Tags: codec, flash, futuro, Google, VP8, x264
Pesquisador multimídia e VJ, Pixel passou a usar software livre em suas performances em 2003 quando se tornou o primeiro VJ brasileiro a trabalhar em plataforma inteiramente aberta. Participou da estruturação e coordenação da 
Rodrigo Savazoni
andredeak
Pedro Markun
Gabriela Agustini
liarangel
VJ pixel
Henrique Costa
furtaacor
fabiano-rangel