Pôr um vídeo abaixo do limite de envio sem adivinhar

O tamanho é débito vezes duração, e quase mais nada

Um ficheiro de vídeo é um fluxo de bits reproduzido a um certo ritmo. Multiplique esse ritmo pelo tempo de reprodução e tem o ficheiro, tirando a contabilidade do próprio contentor, que num MP4 normal é uma fração de por cento. É por isso que o tamanho não é bem uma propriedade que se defina. É um resultado. As duas coisas que controla de facto são quantos bits passam por segundo e quantos segundos existem, e tudo o que um compressor faz é uma forma de empurrar a primeira.

Vale a pena decorar a conversão, porque é o método inteiro. Um megabyte são oito milhões de bits, logo um megabyte são 8 000 kilobits. Multiplique o limite em megabytes por 8 000, divida pelo número de segundos, e o resultado é o débito total em kilobits por segundo que cabe. Um limite de 25 MB num clipe de 60 segundos permite 3 333 kbit/s. O mesmo limite num clipe de 10 minutos permite 333 kbit/s. O mesmo limite, vinte vezes menos espaço, e toda a diferença está na duração.

Uma armadilha nesse cálculo é o próprio megabyte. Uns sistemas entendem 1 000 000 de bytes e outros 1 048 576, uma diferença de 4,9 %, e um serviço raramente diz qual usa. Calcular com o valor decimal — 8 000 kilobits por megabyte — é o lado certo por onde errar: se o serviço queria dizer o megabyte grande, o seu ficheiro entra sob o limite com folga.

O CRF pede uma qualidade, não um tamanho

O cursor de qualidade desta ferramenta define um fator de qualidade constante. A escala vai de 0 a 51 no codificador; o cursor expõe de 18 a 34, que é a parte usada por qualquer pessoa sensata, e arranca em 28. Um número mais baixo significa melhor qualidade e mais bits. O guia do FFmpeg chama a 17 ou 18 visualmente sem perdas ou quase, e descreve de 17 a 28 como a gama subjetivamente razoável. A propriedade decisiva é o que o número significa: é uma instrução sobre quanta degradação tolerar em cada fotograma, não sobre quantos bits produzir.

É por isso que o mesmo CRF dá tamanhos muito diferentes em clipes diferentes. Dois minutos de uma entrevista estática em CRF 23 podem acabar em poucos megabytes; dois minutos de chuva sobre a água, confetes ou uma caminhada com câmara à mão por um mercado, no mesmo CRF, podem pesar dez vezes mais, porque manter a mesma qualidade visual através de todo esse movimento custa mesmo mais bits. O codificador faz o que lhe pediu. Pediu um aspeto, não um peso. A documentação do FFmpeg di-lo por palavras claras: neste modo não se lhe pode impor um tamanho concreto nem um teto de débito.

Existe uma regularidade em que se apoiar, e é a razão por que duas tentativas convergem tão depressa. A escala CRF é exponencial: subi-la seis pontos reduz o débito quase a metade, baixá-la seis quase o duplica. Só essa regra transforma um cursor cego num instrumento de pontaria. Na gama exposta por esta ferramenta, de 18 a 34, isso dá um fator de cerca de 6,3 entre o maior e o menor ficheiro que um mesmo clipe pode produzir.

Recuar a partir do limite, com um exemplo real

Pegue num clipe de três minutos que queira enviar por correio. O Gmail declara um limite de anexo de 25 MB em contas pessoais, portanto: 25 × 8 000 = 200 000 kilobits, a dividir por 180 segundos, dá 1 111 kbit/s no total. Subtraia os 128 kbit/s que esta ferramenta dá ao áudio e sobram 983 kbit/s para a imagem. A recomendação publicada pelo YouTube para 1080p a cadência normal é de 8 000 kbit/s. Estão a pedir-lhe que o faça com um oitavo. O clipe vai codificar, e vai parecer filmado através de uma janela à chuva.

Mude então a pergunta. Em 720p a recomendação do YouTube é de 5 000 kbit/s e tem 983 — ainda um quinto. Em 480p é de 2 500 e tem 983, ou seja 39 %: agressivo, visivelmente mais mole, mas visível para um plano falado ou uma gravação de ecrã. Essa comparação é a decisão a sério, e chegou-se lá com uma divisão. Se o clipe tiver de ficar em 1080p, a única alavanca que resta é a duração: corte-o para 45 segundos e os mesmos 25 MB dão-lhe 4 444 kbit/s no total e 4 316 para a imagem — perto da recomendação de 720p e pouco mais de metade da de 1080p, que é o ponto a partir do qual subir o CRF deixa de ser uma crueldade.

Quando a aritmética diz que não

Faça a divisão numa gravação de trinta minutos contra um limite de 25 MB e obtém 111 kbit/s no total — menos do que o áudio sozinho precisa. O orçamento de imagem é negativo. Nenhum ajuste de compressão resolve isso, e nenhuma paciência o arranjará, porque o pedido é aritmeticamente impossível antes mesmo de o codificador entrar em cena. É o resultado mais útil que o método produz, e vale a pena chegar lá antes de passar vinte minutos a codificar.

As respostas honestas nessa altura são todas sobre a duração ou sobre o destino. Corte a gravação para a parte que interessa — a ferramenta de corte fá-lo em segundos sem recodificar nada, ao custo de aterrar num fotograma-chave e não exatamente onde pediu. Divida-a em partes. Ou mude de canal: as páginas de ajuda da WhatsApp declaram um limite de vídeo por omissão de 100 MB e 720p numa ligação rápida, e de 64 MB e 480p numa ligação lenta, enquanto os documentos enviados pela mesma aplicação chegam a 2 GB — mandar um vídeo como documento contorna assim o limite de tamanho e a recompressão da aplicação.

A opção que move o índice para o início

Cada MP4 que esta ferramenta produz é escrito com +faststart, e isso merece um parágrafo, porque é a diferença entre um ficheiro que toca e um que parece avariado. Um MP4 guarda os seus dados de média numa caixa e o seu índice — a tabela que diz onde vive cada fotograma, chamada átomo moov — noutra. Por omissão o codificador escreve o índice no fim, porque não pode conhecer a disposição final antes do último fotograma. Um leitor que leia esse ficheiro a partir de um servidor web tem de chegar ao fim do descarregamento antes de poder arrancar.

A opção faststart faz o codificador dar uma segunda passagem sobre o ficheiro terminado e mover esse índice para o início. A documentação do FFmpeg descreve-a exatamente assim, e nota que não está ligada por omissão porque essa passagem extra demora. O YouTube pede o mesmo nas suas recomendações de envio: o átomo moov à cabeça do ficheiro, a que chama Fast Start. O efeito prático é que o seu vídeo começa a tocar enquanto ainda está a chegar, em vez de mostrar um retângulo preto até ao último byte — que é o que farão uma pré-visualização de envio, um cliente de mensagens ou uma página web com um ficheiro que não o tenha.

O que a ferramenta executa realmente, e onde

Não há mistério na cadeia, por isso aqui vai inteira. O compressor codifica a imagem com libx264 na predefinição veryfast e no CRF que escolheu, codifica o som em AAC a 128 kbit/s, e escreve o resultado como MP4 com a opção faststart. É todo o comando. A predefinição é um botão de velocidade contra eficiência e não de qualidade: uma predefinição mais lenta daria um ficheiro ligeiramente menor no mesmo CRF, e veryfast é o compromisso que evita que uma codificação no navegador leve a tarde inteira.

Esse codificador é o FFmpeg compilado para WebAssembly e corre dentro da página, na sua máquina. O motor pesa cerca de 32 MB e é servido a partir do endereço deste próprio site e não de uma rede de terceiros, por isso a única coisa que viaja é o motor a vir ter consigo — o vídeo não vai a lado nenhum. A compilação é de uma só linha de execução, e é por isso que é mais lenta do que um codificador de secretária que reparte o trabalho por todos os seus núcleos, e por isso um clipe longo é mesmo uma espera longa. Mantenha o separador em primeiro plano enquanto trabalha: a tarefa vive na página e nenhum servidor lhe guarda o lugar.

Perguntas frequentes

Porque não posso simplesmente escrever o tamanho que quero?

Porque acertar num tamanho exato exige que o codificador veja o clipe inteiro antes de decidir como gastar os seus bits, ou seja, codificá-lo duas vezes. É isso que faz o modo de duas passagens: a primeira mede onde estão os momentos difíceis, a segunda reparte o orçamento em conformidade. É a resposta certa quando o tamanho é um requisito rígido, e custa cerca do dobro do tempo. Esta ferramenta faz uma só passagem a qualidade constante, que é o compromisso adequado para um codificador no navegador, onde a segunda passagem duplicaria uma espera já longa. A aritmética deste artigo serve para fazer o CRF de uma passagem aterrar onde as duas passagens aterrariam.

O meu ficheiro comprimido saiu maior do que o original. Como?

Porque o CRF que pediu era mais generoso do que a qualidade que o ficheiro já tinha. A compressão não é um roquete: o codificador não sabe nem se importa com quanto pesava a entrada, apenas produz o que custa um dado nível de qualidade. Um clipe já muito espremido, uma transferência de uma aplicação de mensagens ou uma gravação de ecrã de conteúdo quase estático pode precisar de mais bits em CRF 23 do que ocupa atualmente. Suba o CRF. A outra causa comum é uma faixa de áudio originalmente inferior a 128 kbit/s, já que esta ferramenta a recodifica sempre a esse débito.

Baixar a resolução ou subir o CRF?

Compare o seu orçamento com o que a resolução pede e deixe a diferença decidir. Se o orçamento estiver a um fator de dois da recomendação, suba o CRF: a imagem amolece mas mantém contornos nítidos. Se for um quinto ou menos, baixe antes a resolução: um codificador tão esfomeado produz blocos e arrastos bem mais feios do que o mesmo material representado honestamente num tamanho menor. A regra é que uma imagem com poucos píxeis parece pequena, e uma imagem com poucos bits parece avariada, e o espectador perdoa muito mais depressa a primeira.

O ajuste de áudio tem alguma importância?

Importa exatamente quando o clipe é longo e o limite é pequeno. A 128 kbit/s o som custa cerca de 0,96 MB por minuto, por isso um clipe de dois minutos gasta menos de 2 MB em áudio e ninguém liga, enquanto uma gravação de vinte minutos gasta mais de 19 MB só em áudio — e é por isso que a linha dos trinta minutos da tabela é impossível a 25 MB. Esta ferramenta não expõe um controlo de áudio, por isso quando o som é o problema a resposta é encurtar a gravação, ou aceitar que uma fala longa pede outro formato e extrair a faixa de áudio sozinha.

O envio falhou apesar de o ficheiro estar abaixo do limite indicado.

Três coisas provocam isto com frequência. O limite indicado pode aplicar-se à mensagem inteira e não a cada anexo, por isso os seus outros ficheiros também contam. O serviço pode medir o envio codificado em vez do ficheiro em disco, o que acrescenta cerca de um terço num anexo de correio. E os números publicados envelhecem: a página de ajuda da Discord sobre anexos, consultada a 13 de agosto de 2026, diz que o limite gratuito é agora de 20 MB, subido de 10 MB em agosto de 2026, com 50 MB no Nitro Basic e até 500 MB no Nitro — enquanto um parágrafo mais antigo da mesma página ainda diz 10 MB. Quando uma página se contradiz, aponte abaixo do número menor.