Converter GIF para WebM

O motivo de escolher WebM em vez de MP4 não é ele ser melhor no abstrato; é que um elemento de vídeo pode listar mais de uma fonte, e o navegador pega a primeira que entende. Coloque o WebM primeiro e o MP4 depois, e cada visitante recebe o arquivo menor onde o navegador suporta, e um arquivo que funciona onde não suporta.

Isso só funciona se você é dono do HTML. Um GIF enviado a um cliente, postado num fórum ou colado numa apresentação de slides não tem mecanismo de fallback, e ali o WebM é uma escolha pior que o MP4 por um motivo que nada tem a ver com o codec. Esta página assume que você mesmo está editando o HTML.

Os dois codecs funcionam do mesmo jeito no esboço: guardam um quadro completo e depois guardam as diferenças. O VP9 chegou cerca de uma década depois e gasta consideravelmente mais esforço por quadro decidindo como particionar a imagem e onde procurar correspondências, o que compra bytes reais em material que se repete.

Material de GIF é incomumente favorável a isso. Cor plana, bordas duras, regiões grandes sem mudança e movimento sintético são todos casos em que uma busca maior encontra mais, então a diferença entre VP9 e H.264 num GIF convertido é maior que a diferença em filmagem de câmera. O custo é tempo de codificação, que você paga uma vez, nesta aba, não a cada carregamento de página.

O registro deste contêiner lista ele como transmissível em fluxo, e essa é a segunda economia numa página. Um navegador consegue começar a tocar um WebM a partir dos primeiros bytes, então a animação começa enquanto o resto ainda está chegando.

Um GIF não consegue fazer isso de forma útil. Navegadores mostram os primeiros quadros conforme chegam, mas o loop não roda direito até o arquivo inteiro ter aterrissado, o que numa conexão lenta significa um primeiro quadro estático parado ali por segundos. Trocar um GIF por um WebM muda a forma dessa espera, além do tamanho dela.

O WebM é um dos poucos formatos de vídeo capazes de guardar transparência, e o registro deste site diz isso. Essa capacidade é real, e vale saber dela porque é o que torna o WebM o formato que as pessoas buscam quando querem um vídeo flutuando sobre o fundo de uma página.

O arquivo que esta conversão escreve não usa isso. A trilha de vídeo é opaca, então um GIF cujo fundo foi declarado transparente perde isso no caminho, e não há ajuste de cor de fundo nesta dupla para controlar o que substitui. Se transparência é o ponto da animação, WebP animado é a recomendação honesta: mantém o canal alfa e toca em todo lugar.

Todo quadro de um GIF vem de uma paleta de no máximo 256 cores. Qualquer degradê suave ou sombra macia que a animação começou com foi reduzido a isso quando o GIF foi escrito, muitas vezes com dithering aplicado para esconder os degraus.

O VP9 guarda o que recebe e não impõe paleta nenhuma própria, então a animação não piora. Também não consegue melhorar, e o dithering é caro: é ruído, e ruído é justamente o que derrota a busca de redundância de um codec de vídeo. Um GIF com muito dithering produz um WebM maior que um plano do mesmo tamanho.

Atrasos de GIF são por quadro, guardados em centésimos de segundo, então um GIF frequentemente roda em taxas que nenhuma câmera jamais produziu — 12,5 quadros por segundo, ou várias taxas diferentes dentro de um mesmo arquivo. A conversão carrega a duração de cada quadro para o vídeo em vez de reamostrar numa taxa constante.

Um atraso zero armazenado é comum e significa "o mais rápido que a tela permitir"; navegadores tratam isso como 100 milissegundos há muito tempo, e esta conversão também. O resultado prático é que uma animação cronometrada no olho num editor de GIF toca na mesma velocidade como WebM.

Os dois codecs de vídeo usados neste site querem dimensões pares em pixels, e um GIF não tem obrigação nenhuma disso. Largura e altura são arredondadas para cima até o próximo número par antes de o primeiro quadro ser desenhado, então um GIF de 405 pixels de largura produz um WebM de 406.

Arredondar para cima acrescenta uma coluna em vez de remover uma, o que mantém a borda da animação. Se o vídeo está diagramado com uma largura CSS fixa, o pixel extra nunca aparece; se você está comparando pixel a pixel contra uma imagem de fundo, vale saber que o número mudou.

Trocar um elemento de imagem por um elemento de vídeo não é uma troca direta, e é o passo mais provável de dar errado. O vídeo precisa de uma largura e altura explícitas ou uma regra de aspect-ratio, senão a página realoca layout quando carrega — trocando um problema de banda por um problema de deslocamento de layout.

Um quadro de pôster é a outra coisa que vale acrescentar. Sem um, existe um retângulo em branco até os primeiros quadros decodificarem, onde o GIF pelo menos mostrava algo. Exportar o primeiro quadro como um WebP ou PNG pequeno cobre isso.

Os quadros são lidos pelo próprio decodificador de imagem do navegador e codificados pelo próprio codificador de vídeo dele, na aba que você está olhando. Não há servidor no caminho, sem fila, sem conta e sem limite diário, e um lote processa cem arquivos de uma vez.

Esse decodificador não está presente em todo lugar. Onde falta, a página avisa e nomeia navegadores que têm, em vez de silenciosamente enviar o arquivo para outro lugar terminar — o que seria a única coisa capaz de tornar essa afirmação falsa.