Ao criar vídeos, converter arquivos existentes ou preparar conteúdo audiovisual para um site, uma das decisões mais importantes é escolher o formato e as configurações de compressão adequados. O menor arquivo possível não é necessariamente o melhor. Ele também precisa ser reproduzido de forma confiável nos navegadores, funcionar em smartphones, ser decodificado com eficiência e preservar qualidade visual suficiente para a finalidade prevista.
Investiguei MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, os presets do codificador x264, a compatibilidade com navegadores, a decodificação por hardware em dispositivos móveis e a medição da qualidade de vídeo. Também realizei experiências práticas de compressão, codificando o mesmo vídeo original com vários valores de CRF e comparando os resultados visualmente e por meio de medições objetivas.
A minha decisão final foi dar prioridade a MP4 com H.264 quando um único arquivo de vídeo precisa de funcionar na maior variedade prática de navegadores, telefones e aplicações externas.
Para vídeos curtos destinados sobretudo à visualização em dispositivos móveis, nos quais o carregamento rápido e os arquivos pequenos são mais importantes do que preservar todos os detalhes, escolhi x264 com CRF 30 depois de verificar que não conseguia notar uma diferença visual significativa entre CRF 22 e 30 durante a reprodução normal, mesmo num monitor de computador grande.
Contudo, esta decisão exige uma ressalva importante: CRF 30 não é uma recomendação para filmes, produções de vídeo de qualidade superior ou conteúdos em que a máxima fidelidade visual seja essencial. Nesses casos, um valor bastante mais conservador, frequentemente próximo de CRF 20, pode ser um melhor ponto de partida. Não realizei uma investigação equivalente com longas-metragens ou imagens cinematográficas de alta qualidade, pelo que essas configurações devem ser tratadas como pontos de partida para testes específicos.
Este artigo explica os fundamentos técnicos, os resultados reais de compressão, as limitações desses resultados e como escolher um formato de vídeo e uma configuração de qualidade adequados ao seu projeto.
1. Contêineres e codecs de vídeo são coisas diferentes
Antes de comparar MP4 e WebM, é essencial compreender a diferença entre um contêiner e um codec.
Um contêiner reúne vídeo, áudio, marcas temporais e metadados num arquivo. Um codec de vídeo determina como os quadros do vídeo são comprimidos e decodificados.
Por exemplo, um MP4 pode conter vídeo H.264, HEVC ou AV1. Essas combinações têm características de compressão e requisitos de dispositivo diferentes, apesar de partilharem a mesma extensão de arquivo.
| Componente | Exemplos | Finalidade |
|---|---|---|
| Contêiner de vídeo | MP4, WebM, MOV, MKV | Reúne vídeo, áudio e dados de sincronização |
| Codec de vídeo | H.264, HEVC, VP9, AV1 | Comprime e descomprime os quadros do vídeo |
| Codec de áudio | AAC, Opus, MP3 | Comprime e descomprime o áudio |
| Codificador de vídeo | x264, x265, SVT-AV1, libvpx-vp9 | Implementa a compressão de vídeo |
Mudar a extensão de um arquivo de .webm para .mp4 não converte o codec de vídeo. Da mesma forma, colocar AV1 num contêiner MP4 não permite reproduzir o vídeo em dispositivos sem suporte para decodificação AV1.
Ao discutir a compatibilidade de vídeo, considere sempre a combinação completa: contêiner, codec de vídeo, codec de áudio, perfil do codec, profundidade de bits e ambiente de reprodução.
2. MP4 ou WebM: qual é melhor para vídeo na web?
Tanto MP4 como WebM são contêineres de vídeo modernos e válidos. Nenhum é universalmente superior, pois as suas características práticas dependem dos codecs utilizados.
MP4 com H.264: máxima compatibilidade na prática
O MP4 com vídeo H.264 e áudio AAC tem um histórico de compatibilidade especialmente amplo. É suportado pelos principais navegadores para computadores e dispositivos móveis, pelos reprodutores de vídeo dos sistemas operativos e por muitas aplicações de terceiros.
Também costuma ser suportado pelos decodificadores de vídeo por hardware presentes em smartphones e computadores. Em comparação com a decodificação por software, a decodificação por hardware pode reduzir a utilização da CPU, melhorar a eficiência da reprodução e diminuir o consumo de energia.
A principal desvantagem é a eficiência de compressão. Codecs mais recentes conseguem frequentemente oferecer uma qualidade visual percebida semelhante com taxas de bits inferiores.
No entanto, H.264 continua a ser uma excelente escolha quando a reprodução confiável é mais importante do que obter o menor arquivo possível.
WebM com VP9: eficiente e adequado aos navegadores
O WebM costuma conter vídeo VP8, VP9 ou AV1, com o áudio normalmente codificado em Opus ou Vorbis.
O VP9 oferece frequentemente uma compressão mais eficiente do que o H.264 para uma qualidade visual comparável. É amplamente suportado pelos navegadores atuais, incluindo versões modernas do Safari.
Seria incorreto afirmar que o Safari não suporta WebM ou VP9 de forma alguma. A compatibilidade dos navegadores melhorou significativamente ao longo do tempo.
A limitação mais importante está na compatibilidade fora do navegador. Aplicações nativas dos sistemas operativos, dispositivos antigos e programas de terceiros podem não lidar com WebM de forma tão consistente como com um MP4 convencional em H.264.
Para uma aplicação exclusiva do navegador, em que seja possível controlar as capacidades de reprodução, o WebM é uma opção sólida. Para um vídeo que os visitantes possam transferir e abrir em programas diversos, MP4/H.264 continua a ter um comportamento mais previsível.
A diferença na prática
| Requisito | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Reprodução em navegadores modernos | Excelente | Muito boa |
| Compatibilidade com navegadores e dispositivos antigos | Geralmente superior | Mais dependente do ambiente |
| Compatibilidade dos arquivos transferidos | Geralmente superior | Menos previsível em aplicações nativas |
| Eficiência de compressão | Boa | Frequentemente melhor |
| Decodificação por hardware | Muito difundida | Comum, mas depende do dispositivo |
| Utilização mais adequada | Um único arquivo amplamente compatível | Distribuição eficiente na web com clientes conhecidos |
A questão fundamental não é saber se o WebM é um bom formato, mas se as suas vantagens de compressão compensam as limitações de compatibilidade no ambiente específico em que será utilizado.
3. H.264, H.265, VP9 e AV1: que codec escolher?
Cada codec de vídeo importante representa um equilíbrio diferente entre eficiência de compressão, custo da codificação, suporte por hardware, compatibilidade com software e licenciamento.
| Codec | Eficiência de compressão | Compatibilidade prática | Utilização típica |
|---|---|---|---|
| H.264 / AVC | Boa | Excelente | Vídeo geral na web, reprodução móvel e transferências |
| H.265 / HEVC | Geralmente melhor do que H.264 | Depende do ambiente | Dispositivos Apple compatíveis, ambientes controlados e vídeo de alta resolução |
| VP9 | Geralmente melhor do que H.264 | Muito boa nos navegadores modernos | Distribuição de vídeo por navegador |
| AV1 | Excelente potencial de eficiência | Crescente, com limitações nos dispositivos antigos | Streaming moderno e dispositivos compatíveis |
Estas são comparações qualitativas, não classificações universais por taxa de bits. A eficiência real depende do conteúdo do vídeo, da implementação do codificador, da qualidade pretendida, do preset de codificação e do método de medição.
H.264: maduro, rápido a decodificar e amplamente suportado
O H.264 é muito otimizado e suportado por uma enorme variedade de hardware e software. A sua maturidade é uma vantagem quando um vídeo precisa de funcionar de forma confiável sem exigir uma aplicação de reprodução especial.
A sua fraqueza é que os codecs mais recentes conseguem muitas vezes comprimir vídeo com maior eficiência. O H.264 também está sujeito a questões de patentes e licenciamento que devem ser analisadas nos cenários relevantes de distribuição comercial.
H.265 / HEVC: melhor compressão com limitações de compatibilidade
O HEVC pode reduzir significativamente a taxa de bits relativamente ao H.264 com qualidade semelhante. É particularmente interessante para conteúdo de alta resolução e ambientes em que a compatibilidade dos dispositivos é controlada.
Muitos dispositivos Apple suportam muito bem o HEVC. No entanto, o suporte nos navegadores e em aplicações externas varia consoante o sistema operativo e os componentes de decodificação instalados. O licenciamento é outra questão a considerar.
O HEVC pode ser uma excelente opção, mas eu não o escolheria automaticamente como único formato de vídeo disponível para transferência num site de utilização geral.
VP9: uma alternativa aberta e prática
O VP9 oferece boa compressão e ampla compatibilidade com navegadores modernos. É uma opção interessante quando os vídeos permanecem no navegador e o ambiente de reprodução é previsível.
A sua principal desvantagem, no meu caso, era a incerteza criada quando os utilizadores transferem os vídeos ou os abrem em aplicações nativas que podem não suportar WebM ou VP9 de forma consistente.
AV1: excelente eficiência, mas suporte por hardware ainda não universal
O AV1 é um dos codecs modernos mais promissores. Pode proporcionar reduções consideráveis da taxa de bits em comparação com codecs mais antigos, e o suporte para decodificação por hardware continua a aumentar.
Ainda assim, os dispositivos antigos podem não ter um decodificador AV1 ou podem exigir decodificação por software. A decodificação de vídeo de alta resolução por software pode consumir mais recursos de CPU e bateria e provocar problemas de reprodução em dispositivos menos potentes.
Se controla o ambiente de reprodução, vale a pena considerar seriamente o AV1. Se um único arquivo tiver de funcionar em dispositivos novos e antigos e em reprodutores externos comuns, o H.264 continua a ser a opção padrão mais segura.
O guia de codecs de vídeo da MDN apresenta informações úteis sobre estes codecs e os requisitos de compatibilidade com navegadores.
4. Um único formato de vídeo ou várias versões?
Esta é uma das decisões de arquitetura mais importantes na distribuição de vídeo.
Quando é possível oferecer várias versões, um site pode disponibilizar AV1 ou VP9 para dispositivos compatíveis e utilizar H.264 como alternativa para outros ambientes. Isto pode melhorar a eficiência de compressão e manter uma ampla compatibilidade de reprodução.
Contudo, manter várias versões aumenta a complexidade da codificação, do armazenamento, da cache, da validação e da seleção do formato de reprodução.
Se precisa de exatamente um arquivo de vídeo final por cada original, uma estratégia que dê prioridade à compatibilidade é muitas vezes preferível.
Escolhi MP4/H.264 porque queria um único arquivo que funcionasse nos principais navegadores, em smartphones e nos processos habituais de transferência e reprodução de vídeos, sem depender de formatos alternativos.
Isto não significa que MP4/H.264 ofereça a melhor compressão. Significa que decidi valorizar a previsibilidade da reprodução mais do que a possível vantagem de tamanho de um codec mais recente.
5. Por que os vídeos para dispositivos móveis têm prioridades diferentes
A compressão do vídeo deve refletir a forma como o conteúdo será realmente consumido.
Um vídeo curto visto principalmente num smartphone tem requisitos diferentes dos de uma longa-metragem vista numa televisão grande. No primeiro caso, carregar rapidamente e consumir menos dados móveis pode ser mais valioso do que preservar detalhes visuais subtis. No segundo, a qualidade da imagem pode ser o objetivo principal.
Para vídeos curtos destinados a dispositivos móveis, arquivos menores podem trazer várias vantagens:
- É necessário transferir menos dados antes de iniciar a reprodução.
- As transferências podem terminar mais cedo em ligações limitadas.
- É necessário menos espaço de armazenamento no dispositivo.
- Os utilizadores consomem menos dados móveis.
- A reprodução pode tornar-se mais resistente a limitações de largura de banda quando a taxa de bits do vídeo codificado é menor.
No entanto, um arquivo menor não garante que o vídeo nunca pare para carregar ou fique bloqueado. As variações da rede, os picos de taxa de bits, o comportamento do servidor, o armazenamento temporário para reprodução e o desempenho de decodificação do dispositivo também são importantes.
A compatibilidade com dispositivos móveis depende de muito mais do que a extensão do arquivo: contam a decodificação por hardware, o perfil e o nível do codec, a profundidade de bits, a subamostragem de crominância, a resolução, a taxa de quadros e os picos de taxa de bits. Um vídeo apresentado com 390 pixels CSS de largura pode ocupar substancialmente mais pixels físicos no display de um smartphone de alta densidade. Por isso, examinar um quadro reduzido a 390 pixels de largura não equivale necessariamente a ver o vídeo original nesse telefone. Faça testes em dispositivos reais e em condições reais de reprodução.
O CRF controla a qualidade, mas não impõe uma taxa de bits máxima exata. Mesmo que o tamanho total seja relativamente pequeno, um vídeo complexo pode ter picos exigentes de taxa de bits. Se a reprodução confiável em ligações particularmente lentas for essencial, considere limites explícitos de taxa de bits ou VBV, limites de resolução apropriados e testes em condições de rede realistas.
O princípio central é simples: otimize para a experiência de visualização pretendida, não para uma meta abstrata de qualidade máxima.
6. Compreender o CRF do x264: valores menores dão mais qualidade, valores maiores reduzem o tamanho
Depois de escolher o H.264, o próximo desafio é determinar a intensidade da compressão a aplicar ao vídeo.
No x264, o fator de taxa constante (Constant Rate Factor), ou CRF, controla o equilíbrio entre a preservação dos detalhes visuais e o tamanho do arquivo.
Um CRF menor costuma produzir arquivos maiores e de maior qualidade. Um CRF maior costuma produzir arquivos menores, com mais perda por compressão.
O CRF não define uma taxa de bits ou um tamanho de saída exatos. O codificador distribui os bits conforme o material original; assim, uma cena simples e outra muito detalhada podem gerar arquivos de tamanhos bastante diferentes com o mesmo CRF.
O CRF também não determina a compatibilidade básica de decodificação. Dois vídeos H.264 corretamente codificados com CRF 22 e CRF 30 podem ter o mesmo codec, perfil, nível, formato de pixel, dimensões e taxa de quadros.
A principal diferença está na qualidade de compressão e nas características da taxa de bits.
É importante compreender que os valores de CRF não são diretamente comparáveis entre implementações de codecs diferentes. Um CRF de 30 no x264 não corresponde à mesma qualidade visual que um CRF de 30 num codificador AV1.
7. A minha experiência real de compressão: de CRF 22 a 32
Queria determinar quanto podia comprimir o vídeo antes de a diferença passar a ser importante durante uma reprodução normal.
Utilizei um único vídeo curto, que já tinha sido comprimido anteriormente, e gerei arquivos H.264 para comparação com CRF 22, 24, 26, 28, 29, 30, 31 e 32.
As propriedades principais do vídeo foram preservadas, incluindo resolução, taxa de quadros, duração e número de quadros. A comparação também utilizou configurações consistentes do codificador para permitir avaliar o efeito da alteração do CRF.
Os resultados revelaram diferenças consideráveis no tamanho dos arquivos.
| CRF | Tamanho aproximado relativamente ao original | Significado |
|---|---|---|
| 22 | 63% | Compressão mais conservadora e maior preservação dos detalhes |
| 24 | 49% | Arquivo menor com uma perda adicional de qualidade moderada |
| 26 | 38% | Redução adicional de tamanho, mantendo muitos detalhes |
| 28 | 30% | Resultado compacto com semelhança relativamente elevada ao original |
| 29 | 26% | Compressão mais agressiva |
| 30 | 23% | O equilíbrio que preferi para o conteúdo testado |
| 31 | 21% | Redução adicional com menor fidelidade ao original |
| 32 | 19% | Menor arquivo testado e maior perda de qualidade medida |
Estas percentagens baseiam-se no arquivo original testado e não devem ser interpretadas como reduções típicas para qualquer vídeo. Os valores da tabela foram arredondados de forma independente; para calcular reduções relativas precisas, utilize os tamanhos reais dos arquivos, em vez de dividir as percentagens arredondadas.
O resultado mais surpreendente foi que não consegui perceber uma diferença visual significativa entre CRF 22 e CRF 30 durante a reprodução normal, mesmo num monitor de computador grande.
Também examinei versões comprimidas de forma ainda mais agressiva, incluindo CRF 32, sem notar diferenças importantes durante a reprodução habitual daquele vídeo específico.
Esta observação era importante porque os mesmos vídeos se destinavam sobretudo a displays menores de dispositivos móveis. Se a redução de qualidade não incomodava no meu monitor de computador, havia poucos motivos para aceitar um aumento considerável do tamanho do arquivo para preservar detalhes que não melhoravam a experiência de visualização pretendida.
Contudo, esta foi uma observação subjetiva sobre um tipo específico de material original. Não prova que todos os utilizadores, smartphones ou vídeos apresentem o mesmo resultado. Displays móveis de alta densidade e distâncias de visualização reduzidas podem ainda revelar defeitos, especialmente em detalhes finos ou gradientes.
8. As medições objetivas confirmaram uma perda real de qualidade
Não perceber uma diferença durante a reprodução não significa que dois vídeos sejam matematicamente idênticos.
Também comparei os resultados codificados usando medições objetivas da qualidade de imagem. À medida que o CRF aumentava, a semelhança com o original diminuía.
Numa comparação com redução de resolução consistente, destinada a aproximar as condições de um display móvel de alta densidade, as medições representativas de SSIM foram:
| CRF | SSIM aproximado | Tamanho de saída relativamente a CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
A tendência é clara: uma compressão mais intensa reduziu a fidelidade medida do vídeo codificado. Uma observação atenta também revelou diferenças subtis nas linhas finas e nas texturas.
Apesar disso, a experiência habitual de visualização manteve-se muito semelhante para o material testado. É precisamente por isso que as medições objetivas e a avaliação subjetiva devem ser utilizadas em conjunto.
O SSIM mede a semelhança entre imagens, não a experiência humana de visualização no seu conjunto. Não consegue representar completamente os defeitos temporais, a nitidez percebida, o comportamento do movimento ou a importância subjetiva de cada detalhe visual.
O VMAF é outra métrica útil de qualidade percetiva. A Netflix lançou os modelos VMAF v1 em junho de 2026, incluindo um modelo concebido para condições de visualização em telefones. Estes modelos reconhecem explicitamente que a qualidade percebida depende, em parte, do tamanho do display e da distância relativa de visualização.
Uma amostra codificada de forma conservadora apresentou, segundo o relatório da investigação, um VMAF médio de aproximadamente 95, mas não havia uma série consistente de valores VMAF para todas as configurações agressivas de CRF. Por isso, não utilizei o VMAF para afirmar que CRF 30 ou 32 atingiam um limiar universal de qualidade.
A conclusão prática foi mais limitada: o vídeo curto testado suportou extremamente bem a compressão H.264 agressiva durante a reprodução normal.
9. Por que escolhi CRF 30 para vídeos curtos em dispositivos móveis
Depois de comparar os arquivos, decidi usar CRF 30 para vídeos curtos semelhantes, vistos principalmente em dispositivos móveis.
O raciocínio foi simples:
- Os vídeos eram curtos e não se destinavam a proporcionar qualidade cinematográfica.
- O carregamento rápido e as transferências menores eram importantes.
- Não consegui perceber uma diferença significativa entre CRF 22 e 30 num monitor de computador grande.
- O CRF 30 produziu arquivos muito menores do que as configurações conservadoras.
- O CRF 32 também apresentou qualidade visual aceitável na amostra testada, mas transmitiu menos confiança para materiais mais complexos.
Em comparação com CRF 28, CRF 30 reduziu o tamanho do resultado testado em aproximadamente 21%. Em comparação com CRF 22, a redução foi superior a 60%.
Para vídeos curtos destinados a dispositivos móveis, quando o objetivo é uma imagem agradável, um carregamento rápido e um consumo razoável de largura de banda, esta compensação valeu a pena.
Mas a condição é extremamente importante: escolhi 30 devido à finalidade real de visualização e aos resultados do material testado, não porque 30 seja intrinsecamente o melhor CRF para smartphones.
Um dispositivo móvel não exige CRF 30. Pode reproduzir perfeitamente um vídeo codificado com uma fidelidade muito superior. CRF 30 é uma decisão deliberada de trocar alguma fidelidade ao original por arquivos menores, quando essa troca é aceitável.
Antes de aplicar esse valor a uma coleção de conteúdos substancialmente diferentes, testaria vários vídeos representativos, incluindo movimentos difíceis de codificar, cenas escuras, gradientes, texto e texturas finas.
10. Por que não recomendo CRF 30 para filmes ou vídeos de alta qualidade
Esta é a limitação mais importante da experiência.
Não aplique indiscriminadamente o meu resultado com CRF 30 a longas-metragens, conteúdos de vídeo de qualidade superior, imagens profissionais ou vídeos destinados a displays grandes.
Esses conteúdos podem apresentar gradientes subtis, grão cinematográfico, cenas com pouca luz, movimentos complexos, superfícies com texturas finas e cores cuidadosamente ajustadas. Preservar esses detalhes pode ser mais importante do que poupar uma quantidade relativamente pequena de largura de banda.
Para vídeo convencional de alta qualidade a 1080p, começaria com uma configuração x264 muito mais conservadora, próxima de CRF 20, e avaliaria valores superiores e inferiores de acordo com o material.
Um intervalo inicial prático poderá ser CRF 18–22 quando a fidelidade visual é importante, embora o valor adequado possa ficar fora desse intervalo, dependendo da resolução, do conteúdo e dos requisitos.
Esta sugestão está de acordo com orientações de codificação frequentemente publicadas. Por exemplo, a documentação de qualidade do HandBrake recomenda aproximadamente RF 20–24 para muitos casos de utilização do x264 a 1080p.
Não realizei a mesma investigação controlada com longas-metragens ou conteúdo cinematográfico de qualidade superior. Por isso, não posso afirmar que CRF 20 seja universalmente ideal, que CRF 22 seja sempre suficiente ou que qualquer filme específico tenha necessariamente uma qualidade inaceitável com CRF 30.
O método correto consiste em selecionar cenas representativas, codificar vários níveis de qualidade, compará-los no display previsto e determinar o ponto a partir do qual uma compressão adicional prejudica visivelmente a imagem.
Se o vídeo for arquivado, editado novamente ou utilizado como origem de futuras codificações, deve ser mantido um arquivo mestre de alta qualidade separado da versão comprimida destinada à distribuição.
11. Por que utilizei o preset veryslow do x264
O CRF controla um aspeto da qualidade de compressão, enquanto o preset do x264 determina o esforço dedicado pelo codificador à procura de decisões de codificação eficientes.
O x264 disponibiliza presets desde muito rápidos até muito lentos. Em geral, os presets mais lentos usam mais tempo de CPU e podem oferecer melhor eficiência de compressão com uma qualidade visual comparável.
Comparei os presets medium e veryslow com o mesmo arquivo original. Na configuração de qualidade testada, veryslow produziu um arquivo menor.
Para codificação offline, realizada uma única vez e reutilizada muitas vezes, o tempo adicional de processamento pode compensar.
Foi por isso que escolhi -preset veryslow.
No entanto, não é universalmente ideal. Se os vídeos precisarem de ser processados imediatamente, os recursos de CPU forem caros ou existir uma fila enorme de trabalho pendente, slow ou medium podem oferecer um melhor equilíbrio operacional.
O preset altera principalmente a complexidade da codificação e a eficiência de compressão. Não transforma H.264 noutro codec nem torna o arquivo resultante inerentemente incompatível com dispositivos móveis.
12. Para vídeos de anime, utilizo o ajuste de animação do x264
Quando o vídeo original contém animação desenhada ou imagens de estilo anime, utilizo -tune animation com x264.
Este ajuste é diferente do CRF. Um ajuste específico de otimização modifica determinadas decisões do codificador para se adaptar a características visuais particulares. O ajuste de animação foi concebido para materiais com contornos desenhados, regiões de cores uniformes e movimentos estilizados.
A minha preferência é, portanto, a seguinte:
- Anime ou vídeo de animação desenhada:
-preset veryslow -tune animation. - Vídeo convencional de ação real: não ativar automaticamente o ajuste de animação; começar com as configurações padrão do codificador ou avaliar separadamente um ajuste adequado.
É importante não interpretar mal o que este ajuste faz. -tune animation não garante qualidade visivelmente superior nem arquivos menores. Modifica o comportamento do codificador, e o resultado depende do material.
Realizei uma comparação separada com CRF fixo e o ajuste de animação. Nessa comparação específica, ativar o ajuste tornou o arquivo resultante aproximadamente 6% maior e melhorou ligeiramente a semelhança de imagem medida. A diferença visual foi pequena.
A principal comparação de tamanhos entre CRF 22 e 32 foi realizada sem o ajuste de animação. Por isso, não se deve presumir que os tamanhos e as taxas de compressão exatos dessa experiência se mantenham idênticos quando -tune animation está ativado.
Ainda assim, para vídeos de anime, prefiro utilizar o ajuste específico de animação e avaliar o tamanho e a qualidade resultantes como parte do perfil de codificação desse conteúdo.
A otimização do codificador deve ser entendida como uma adaptação dependente do conteúdo, não como uma melhoria universal de qualidade.
13. As minhas configurações recomendadas de FFmpeg para vídeos curtos de anime destinados a dispositivos móveis
Para um vídeo convencional de anime em SDR que realmente necessite de transcodificação, este comando representa o perfil que utilizaria como ponto de partida:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Este comando torna explícitas as principais escolhas:
-c:v libx264utiliza o codificador H.264 por software.-preset veryslowdá prioridade à eficiência de compressão em detrimento da velocidade de codificação.-tune animationativa ajustes específicos para animação.-crf 30aplica o objetivo agressivo de qualidade constante selecionado para este tipo de vídeo curto.-profile:v highseleciona um perfil H.264 amplamente suportado pelos dispositivos modernos.-pix_fmt yuv420pproduz vídeo de 8 bits com subamostragem 4:2:0.-map 0:v:0seleciona o primeiro fluxo de vídeo.-map '0:a:0?'seleciona opcionalmente o primeiro fluxo de áudio.-c:a aac -b:a 128kcodifica áudio AAC convencional quando existe áudio.-movflags +faststartdesloca os metadados de inicialização do MP4 para perto do início do arquivo.
Este é um exemplo, não um comando universal para qualquer entrada. As necessidades específicas do vídeo original podem exigir tratamento adicional.
Em particular, materiais HDR e de 10 bits não devem ser convertidos indiscriminadamente para SDR de 8 bits sem uma gestão de cores adequada: podem surgir cores incorretas, perda de detalhes nas zonas mais luminosas ou bandas visíveis nos gradientes. Os metadados de rotação, as taxas de quadros variáveis, as proporções dos pixels, as fontes entrelaçadas, os esquemas de áudio invulgares e os limites de resolução incompatíveis também exigem atenção.
Quando a taxa de quadros e as dimensões do vídeo original já são adequadas, preservá-las costuma facilitar a comparação e evitar alterações desnecessárias de escala ou movimento. Evite impor uma taxa de quadros constante a fontes com taxa variável, a menos que seja necessário: essa conversão pode duplicar ou eliminar quadros. Ao redimensionar, preserve a proporção de apresentação e assegure que as dimensões são compatíveis com o formato de pixel 4:2:0 escolhido. Resoluções, taxas de quadros ou níveis H.264 muito elevados podem exceder os limites de decodificação de dispositivos antigos; por isso, a compatibilidade pode exigir uma redução deliberada da resolução ou da taxa de quadros.
14. Um ponto de partida mais conservador no FFmpeg para vídeo de alta qualidade
Se a fidelidade do vídeo for substancialmente mais importante do que o tamanho do arquivo, comece com um CRF menor e avalie o resultado.
Por exemplo, a configuração seguinte é um ponto de partida experimental razoável para vídeo SDR convencional de ação real:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Neste exemplo, o preset slow é um ponto de partida prático e genérico, não uma afirmação de que supera veryslow. Utilizar veryslow também seria razoável quando existe tempo adicional disponível para codificação.
Este perfil de alta qualidade é uma recomendação para testes, não uma configuração comprovada pela minha experiência com vídeos curtos.
Para vídeo de qualidade superior, teste valores de CRF próximos de 18, 20 e 22 e escolha de acordo com os resultados visíveis. Grão ou movimentos difíceis podem exigir configurações diferentes, e os arquivos mestres destinados a arquivo permanente podem precisar de compressão muito menos agressiva.
15. Não volte a codificar um vídeo sem motivo
A compressão de vídeo com perdas tem um custo em qualidade. Voltar a codificar um arquivo que já foi comprimido pode introduzir defeitos adicionais, mesmo quando o novo resultado parece semelhante ao original.
Antes de transcodificar, pergunte se o arquivo original já cumpre os seus requisitos de compatibilidade, tamanho e qualidade.
Se o arquivo já contiver vídeo H.264 e áudio AAC compatíveis, e não for necessária nenhuma transformação visual, copiar os fluxos pode ser melhor do que efetuar outra codificação com perdas.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Esta operação copia os fluxos comprimidos sem os voltar a codificar. Pode alterar a organização do contêiner e evitar outra geração de perdas de qualidade devido à compressão.
Normalmente, não proporciona reduções de tamanho iguais às de uma nova codificação com qualidade inferior.
Se o vídeo existente já for compacto, compatível e visualmente aceitável, mantê-lo pode ser a melhor otimização de todas.
16. Valide os vídeos codificados em vez de confiar apenas no tamanho do arquivo
A conclusão bem-sucedida do FFmpeg não prova automaticamente que um vídeo cumpre todos os requisitos.
Comece por analisar os fluxos de saída com FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Verifique o codec, o formato de pixel, as dimensões, a taxa de quadros, a duração e os fluxos de áudio.
Em seguida, decodifique todo o arquivo de saída para detetar determinados tipos de corrupção ou erros de decodificação:
ffmpeg -v error -xerror -i output.mp4 -f null -Nas experiências de compressão, compare resultados gerados a partir do mesmo arquivo original. Mantenha constantes as variáveis importantes e altere apenas uma configuração principal de cada vez.
Observe o vídeo em movimento, examine os detalhes finos e preste atenção aos gradientes, às zonas escuras, aos objetos em movimento e ao texto.
Se possível, utilize métricas objetivas como SSIM, PSNR ou VMAF para complementar as comparações visuais. Não interprete uma única pontuação elevada como prova de que todos os defeitos são invisíveis.
Por fim, teste o vídeo em dispositivos representativos e nos processos habituais de transferência e abertura dos arquivos. A informação sobre a compatibilidade dos navegadores é útil, mas os testes reais de reprodução são especialmente importantes quando a compatibilidade é uma prioridade.
17. Certifique-se de que os arquivos MP4 são distribuídos corretamente
Boas configurações de codificação não compensam uma distribuição deficiente de vídeo na web.
Para a reprodução progressiva habitual de MP4, configure corretamente o cabeçalho Content-Type: video/mp4 e suporte pedidos HTTP por intervalos de bytes quando for necessário obter partes do arquivo ou avançar para outros pontos do vídeo.
A opção +faststart do FFmpeg desloca as informações de inicialização do MP4 para perto do início de um arquivo convencional. Isto facilita o carregamento progressivo, mas não melhora a qualidade visual nem reduz a taxa de bits.
Um elemento HTML de vídeo simples pode disponibilizar um MP4 em H.264:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>O atributo preload é uma indicação para o navegador, e não um limite rígido de transferência. As políticas de reprodução automática do navegador também podem exigir que o vídeo esteja sem som ou não contenha áudio.
Se uma página contiver vários vídeos, evite transferi-los todos imediatamente. Carregar os vídeos apenas quando necessário pode reduzir o consumo de dados móveis e melhorar a rapidez de resposta percebida.
Para vídeos curtos em dispositivos móveis, otimizar o agendamento das transferências pode ser tão importante como reduzir o tamanho do arquivo codificado.
18. Que formato e qualidade de vídeo deve escolher?
A resposta certa depende do que pretende otimizar.
| O seu objetivo | Ponto de partida recomendado |
|---|---|
| Um único vídeo amplamente compatível para web e transferência | MP4 + H.264 + AAC quando houver áudio |
| Distribuição em navegadores modernos com várias opções de formato | AV1 ou VP9, com H.264 como alternativa |
| Compressão máxima em dispositivos compatíveis | Avaliar AV1 |
| Ambiente de reprodução controlado e compatível com HEVC | Considerar MP4 + HEVC |
| Vídeos curtos para dispositivos móveis em que o tamanho é prioritário | Considerar x264 CRF 30 após testes representativos |
| Anime ou vídeo de animação desenhada | Avaliar x264 com -tune animation |
| Filmes de alta qualidade ou vídeo de qualidade superior | Começar com um CRF mais conservador, próximo de 20, e testar |
| Codificação offline em que o tempo de CPU é menos importante | Considerar x264 slow ou veryslow |
| Processamento rápido com recursos de CPU limitados | Considerar x264 medium ou slow |
| O vídeo existente já cumpre os requisitos | Mantê-lo ou mudar o contêiner sem voltar a codificar |
| Arquivo permanente ou edição futura | Manter um arquivo mestre de alta qualidade separado das versões de distribuição |
19. A minha decisão final e o que a experiência realmente demonstrou
Depois de investigar formatos de vídeo, compatibilidade, eficiência de codificação e resultados reais de compressão, escolhi um perfil prático de distribuição para vídeos curtos destinados a dispositivos móveis.
O formato escolhido foi MP4 com H.264, porque a compatibilidade previsível com navegadores, telefones, transferências e aplicações externas era mais importante do que obter o menor arquivo possível com um codec mais recente.
O codificador escolhido foi libx264 com o preset veryslow, porque o vídeo podia ser codificado offline e o tempo adicional de processamento era aceitável.
Para vídeos de anime, utilizo o ajuste de animação, reconhecendo que este modifica o comportamento do codificador e não garante arquivos menores nem melhores resultados visuais em todos os casos.
Para vídeos curtos destinados a dispositivos móveis, escolhi CRF 30, porque a minha comparação mostrou uma redução considerável do tamanho do arquivo sem diferenças visuais significativas durante a reprodução normal, mesmo num monitor de computador grande.
Esse resultado não significa que CRF 30 seja a configuração ideal para filmes ou imagens de alta qualidade. Para conteúdo em que os detalhes finos, os gradientes, o grão e a fidelidade geral são mais importantes, começaria a testar valores próximos de CRF 20 ou outro valor suficientemente conservador. Não realizei um estudo controlado correspondente com material cinematográfico, pelo que não apresento esse número como um valor ideal comprovado experimentalmente.
A conclusão mais importante é que não existe um único codec, formato ou valor de CRF universalmente melhor para todos os vídeos.
Se a prioridade for a máxima compatibilidade e quiser apenas um arquivo, MP4/H.264 é uma boa opção padrão. Se puder oferecer formatos alternativos e quiser uma compressão melhor, investigue VP9 e AV1. Se estiver a codificar vídeos curtos vistos principalmente em telefones, teste se um CRF maior produz arquivos suficientemente pequenos sem prejudicar a experiência pretendida. Se estiver a codificar filmes ou conteúdo de qualidade superior, utilize configurações de qualidade mais conservadoras e verifique-as cuidadosamente.
Escolha primeiro os requisitos de reprodução, depois o codec e, por último, a qualidade de compressão. Em seguida, teste o resultado nos dispositivos e nas condições que realmente importam. Este método é mais confiável do que adotar cegamente um codec ou valor de CRF apenas por ser mais recente, mais eficiente ou frequentemente recomendado.