O retorno do Xvid

Return of the Xvid: check your outputs!
Autor original: Mitch Meyran
Publicado originalmente no: freesoftwaremagazine.com
Tradução: Roberto Bechtlufft

Muito tempo atrás, em um post não muito distante…

Uma vez eu escrevi um artigo sobre o Xvid 1.1.3, e sobre o ganho de velocidade que poderia ser obtido habilitando-se o código otimizado em assembly. Acontece que com a nova versão, no meu caso específico, o feitiço virou contra o feiticeiro.

Resumindo, a lei de Murphy atacou novamente. Mas para começar, um não tão breve resumo para aqueles que não querem ler posts antigos.

De volta ao Mayo

Alguns anos atrás, o Motion Picture Expert Group decidiu criar um novo padrão de compressão de vídeo que substituísse o judiado e limitado padrão ISO/IEC 13818, também conhecido como h.262 e publicado carinhosamente com o nome MPEG-2. Em um momento de grande inspiração ele foi chamado de h.263 – sendo apelidado de MPEG-4 graças à limitação de alguns sistemas em lidar com extensões de arquivo, que fez com que os arquivos de áudio MPEG-1 layer 3 fossem chamados de mp3 ou MPEG3.

A criação do h.263 não foi instantânea: várias empresas começaram a criar suas próprias implementações, dando seu toque pessoal. Dentre elas a Microsoft, que publicou alguns codecs que se tornariam os Windows Media Video 7 e 8. Esses primeiros codecs foram hackeados e aperfeiçoados pelo hoje famoso hacker Gej, que os lançou com o nome de DivX 3.11 😉 (sim, o risinho aí do lado é parte do nome).

Mas Gej, que era um garoto responsável e não queria os cães da Microsoft em seu encalço, decidiu jogar seus codecs fora e usar rascunhos mais recentes do h.263; ele começou a implementar seu próprio codec, com alguns ajustes para obter compatibilidade com o DivX 3 😉 no chamado Projeto Mayo (Gej é francês, e “Mayo” é abreviação de “maionese” em francês).

O projeto teve êxito na criação de um codec MPEG-4, mas alguns desenvolvedores decidiram manter modificações posteriores para si mesmos (o código do Projeto Mayo não foi lançado sob a GPL) e criaram a empresa DivX, que vende o codec DivX e várias ferramentas. Eles têm raízes no software livre, e oferecem binários do codec para Linux (não com muita freqüência, porque a demanda é baixa) para promover a ferramenta de codificação Virtualdub, além de terem lançado sua ferramenta principal, o Doctor DivX, sob a GPL algum tempo atrás. O Dr. DivX funciona com outros codecs além do DivX, como o Xvid.

O Projeto Mayo praticamente desapareceu quando o DivX 4 saiu. Alguns desenvolvedores obstinados decidiram pegar o código existente e criar um projeto que tinha como nome a grafia inversa de Divx, o Xvid.

Não pense que eles não foram bem sucedidos: embora a princípio o Xvid não tenha tido tanto desenvolvimento quanto o DivX e sua equipe assalariada, os desenvolvedores eram muito bons, e vários deles estavam entre os desenvolvedores de codecs mais brilhantes. Logo o Xvid atingiu um nível de qualidade que rivalizava, e às vezes até excedia, o do DivX, mantendo uma alta compatibilidade (o h.263 é muito complexo, e havia casos de implementações compatíveis que não eram capazes de reproduzir fluxos vindo de um codificador diferente), enquanto o DivX se mantinha disparado na frente do resto do mercado em termos de qualidade e velocidade.

Chegou-se ao consenso de que o DivX era um grupo de ferramentas poderoso e fácil de usar para a codificação MPEG-4 no Windows e no Mac, enquanto o Xvid era a melhor opção para trabalhos de codificação mais extremos e nítidos no formato h.263.

Mas o Xvid acabou vítima do próprio sucesso: muitos de seus principais desenvolvedores foram contratados por empresas que produzem codificadores MPEG-4, afastando-os do projeto, e com isso o Xvid aparentemente estacionou no meio de 2007. Após a revisão 1.1.3, que era uma versão de correção de bugs, o código principal manteve-se praticamente o mesmo de 2006, quando saiu a versão 1.1.0.

Na época os processadores de núcleo duplo começavam a se popularizar, e os sistemas de 64 bits foram aparecendo lentamente. Isso trouxe novas oportunidades aos desenvolvedores:

• usar várias threads paralelas para codificar quadros mais rapidamente,
• usar extensões de 64 bits e fazer uso de um grupo maior de funções de ponto flutuante nos processadores mais poderosos.

Até então, a maioria dos codificadores se baseavam no conjunto de instruções do Pentium Pro, e alguns haviam começado a incluir o suporte a MMX e SSE (principalmente FPSSE), usando uma única thread; otimizar o codec para 64 bits, SSE2 e SMP significava rescrever tudo praticamente do zero. Isso foi feito na versão 6 do DivX (o DivX 5 basicamente incluiu melhor detecção de movimentos e compressão de macroblocos); no Xvid a idéia era fazer isso na versão 1.2… que saiu em dezembro de 2008.

Competição, e o poder do software livre

Um dos últimos desenvolvedores do Xvid a seguir firme é Koepi, muito conhecido na internet por manter o binário para Windows (por questões de patentes, o Xvid distribuiu apenas o código fonte por muito tempo). Outros, como Plugh, Isibaar e skal criam a maior parte do código, mas são mais reservados. Eles não ficaram de braços cruzados nesses dois anos: um cuidava das correções de bugs (que eram incluídas no pacote tar compactado não oficial e nos binários), outro fazia avanços rumo ao Xvid 1.2, outro se preocupava em compartilhar código entre o x264 e o Xvid… vale mencionar que devido à compatibilidade e à qualidade, o Xvid ganhou fama na indústria, e uma pequena empresa foi erguida em torno do projeto, fornecendo especificações, definições de perfis e suporte profissional.

Como eu já disse, sim, saiu o Xvid 1.2 (a versão 1.2.1 é a mais nova); ele traz:

• Otimizações para SSE2 e SSE3: essas tecnologias existem, então é uma boa usá-las. Esse suporte não é indispensável e há como contornar a falta dele, mas com o suporte o Xvid fica muito mais rápido.
• Otimizações para assembly em 64 bits: o Xvid 1.1.3 funcionava em plataformas de 64 bits, mas não era otimizado para elas.
• Suporte parcial a threads múltiplas paralelas, com detecção otimizada de threads: em versões anteriores era preciso especificar o número de threads desejado, agora o Xvid cuida disso.
• Detecção de movimentos recriada; embora ainda não seja como a do x264, ela melhorou, e alguns testes rápidos foram feitos para portar a detecção de movimentos do x264 para o Xvid. Talvez na versão 1.3…

A especificação MPEG-4 divide a imagem em quadrados, e analisa como esses quadrados mudam de um quadro para o próximo (ou para o anterior, em perfis avançados), compactando simultaneamente o conteúdo dos quadrados: dessa maneira, no compressor de macroblocos, boa parte da compressão provém da precisão com que um codec pode detectar a movimentação, a rotação e as alterações dos macroblocos. A parte mais exigente da compressão é a detecção de movimentos, e é aqui que entram as otimizações:

• O assembly ajuda a economizar ciclos da CPU: como a detecção de movimentos exige a repetição do mesmo procedimento várias vezes, ganhar um único ciclo em uma única operação pode resultar em uma enorme economia de tempo. Comparando a implementação em C do Xvid com a versão otimizada em assembly, há uma redução de 1/3 no tempo, ou seja, uma compressão que levaria uma hora leva apenas 20 minutos.
• As imagens representam muitos dados, e operações de 64 bits podem ajudar a reduzir o tempo de codificação: onde processadores de 32 bits precisam de três ciclos para realizar uma operação, um de 64 bits pode fazer a mesma coisa em um ciclo, em alguns casos.
• O SSE2 e o SSE3 oferecem extensões que permitem que um processador faça em poucos ciclos o que antes exigiria várias centenas de ciclos no SSE1 ou milhares no FPU.

O Xvid é software livre, e sendo assim pode ser executado em várias plataformas: x86-32, x86-64, Power, ARM… E como o assembly é específico para cada plataforma, os desenvolvedores do Xvid decidiram compartilhar o máximo possível de trabalho entre elas. Para isso, usaram uma plataforma e uma linguagem intermediária que pudesse ser passada para assembly com o mínimo de perda. A plataforma é o NASM. Resumindo, o Xvid roda mais rápido nas plataformas suportadas pelo NASM. Para as outras, existe a implementação de referência comum em C.

Na época do Xvid 1.1, o NASM não suportava o SSE2, muito menos o SSE3, e também não suportava x86-64; por isso, o Xvid usou por uns tempos o YASM (uma implementação bastante compatível do NASM com suporte a 64 bits) em sistemas AMD e Intel de 64 bits . De lá para cá, o Xvid abandonou o suporte ao YASM e foi para o NASM. Só que o suporte a 64 bits do NASM ainda é muito recente.

Percebeu onde eu quero chegar?

O NASM ataca

Assim que o Xvid 1.2.1 saiu eu tente compilá-lo. Na etapa de configuração, vi de relance a linha ‘no assembly’, então eu removi o YASM e instalei o NASM. Estava claro que o suporte ao YASM já era, e que o NASM vinha com força total. Depois eu dei um configure novamente, e um make. A compilação foi em frente numa boa, eu compilei a nova biblioteca, criei os links e comecei a comprimir um vídeo. Codifiquei só uma pequena parte e fui ver o resultado.

Grandes borrões de cor magenta sobre a imagem.

Fui desabilitando opções de codificação aqui e ali, testei aplicativos diferentes, verifiquei os links com a libxvidcore, tentei com outros vídeos, mas até uma codificação sem opções e de thread única levou ao mesmo problema. Sabendo onde ocorreram as maiores rescritas de código no Xvid, fiz uma nova compilação com suporte ao C.

Lá se foram os borrões (e a velocidade).

Fiz a minha parte e relatei o bug; recebi uma resposta da XvidSolutions, que ficou bastante alarmada (afinal de contas, é um bug crítico). Depois de muitas tentativas, depurações e testes, decidi experimentar algo diferente: atualizei o NASM para a última versão lançada (2.05.1 no momento da escrita deste artigo), recompilei o Xvid e acabei determinando a origem do problema.

O NASM 2.04, fornecido pela minha distribuição (o Suse traz a versão 2.02, por exemplo), trouxe uma regressão na conformidade com o ELF64 que escapava aos testes automatizados; sendo assim o bug não aparecia nas plataformas de 32 bits, não aparecia no Xvid 1.1.3 e não aparecia nos computadores dos desenvolvedores.

O script de configuração da próxima versão do Xvid deve incluir uma pequena verificação para se certificar de que o NASM instalado não seja o 2.04. E sim, eu notifiquei os desenvolvedores da minha distribuição, então vocês podem esperar pelo NASM 2.05.1 no Mandriva 2009.0 muito em breve.

Conclusão

A nova versão do Xvid codifica muito mais rápido. Não notei nenhum ganho na qualidade ou no tamanho dos arquivos em comparação à versão 1.1.3, mas se você tiver um processador dual core vai notar a diferença na velocidade. Só que o escalonamento não é bom, então não espere conseguir 100% de uso de CPU e velocidade quatro vezes maior no seu quad core malvadão; é mais provável que você consiga uns 40% de velocidade em um dual core, mas preste atenção na hora de compilar.

No final das contas, isso poupa bastante tempo. Agora, vamos ver se há interesse pelo h.264 e pelo x264…

A maior parte dos dados foi reunida em discussões e posts nos sites do Doom9 e do Koepi.

Créditos a Mitch Meyran – freesoftwaremagazine.com
Tradução por Roberto Bechtlufft <roberto at bechtranslations.com>