Compactação de Vídeo para Desenvolvedores e QA

Você gravou o bug em trinta segundos. Fazer o upload da reprodução levou mais tempo, falhou duas vezes e o GitHub informou que o arquivo estava muito grande. Ou o QA anexou um MOV que nunca carregou inline, então ninguém assistiu.

Uma gravação de tela é frequentemente a maneira mais rápida de explicar uma regressão, mas só funciona quando os revisores conseguem abri-la rapidamente, ler a interface e reproduzir exatamente o caminho do erro.

Tamanho de arquivos de gravação de tela vs. limites de rastreadores de issues

Rastreadores de issues e hosts de PR limitam o tamanho dos anexos. Um MOV ou MP4 em resolução completa gravado no QuickTime, CleanShot ou OBS costuma ter dezenas ou centenas de megabytes antes de qualquer corte.

Corte primeiro, depois compacte até o limite real do rastreador com margem suficiente para o upload. Preserve o texto da interface antes de buscar o menor número possível. Use um preset de Tamanho de arquivo desejado quando um limite rígido for importante. Converta para um GIF pequeno apenas quando um loop curto e mudo explicar o problema melhor que o vídeo.

Formatos de vídeo, GIF e captura de tela para bug reports

As evidências de bugs vêm em algumas formas, e cada uma exige uma escolha de entrega diferente:

• Vídeo: MOV, MP4, WebM, M4V, MKV e outros de gravadores de tela e ferramentas de demonstração.
• GIF: pequenos glitches de UI, estados de hover e regressões de carregamento que ficam melhores como loop.
• Imagens: capturas de tela em PNG e JPEG quando um frame estático é suficiente para o relatório.

Mesma fila, mesmos presets, seja o QA que enviou o issue ou você anexando a prova ao seu próprio PR.

Anexando vídeos de reprodução em issues e pull requests

Clipes de antes e depois aceleram a revisão. Um MP4 compacto mostrando o bug e depois a correção dá contexto aos revisores sem necessidade de fazer checkout da branch. A aprovação do QA funciona da mesma forma: anexos leves são mais fáceis de pesquisar, reabrir e compartilhar meses depois.

Solte um lote de gravações após uma rodada de testes, ou copie um arquivo e receba uma versão mais leve na área de transferência, pronta para colar na issue.

Criando uma pasta de captura repetível

Use uma pasta previsível por ticket ou execução de teste: source, redacted e attachment. Preserve a captura original, faça a redação aprovada em uma cópia e crie o anexo menor a partir dessa cópia revisada. Um arquivo em attachment deve estar seguro para ser colocado no rastreador nomeado sem outra decisão subjetiva.

Inclua o ID do ticket e a plataforma no nome do arquivo, como GC-142-windows-actual.mp4. Evite nomes de arquivo que exponham nomes de clientes, endereços de e-mail ou hostnames internos.

Limites de anexos em rastreadores de issues na prática

GitHub, Jira, Linear e a maioria dos hosts de PR limitam anexos inline entre 10 e 100 MB, dependendo do plano e do tipo de arquivo. Um MOV de trinta segundos em resolução Retina completa pode exceder esse limite sem parecer “grande” no disco. Veja limites de tamanho de anexos de e-mail para a mesma matemática ao colar clipes de reprodução em threads de e-mail com PMs e suporte.

Presets de Tamanho de arquivo desejado ficam abaixo de um limite conhecido. Para regressões de UI onde um loop de GIF é suficiente, exporte um loop pequeno em vez de um MP4 completo. Compactação com perdas vs. sem perdas importa menos para reproduções em movimento do que para capturas de tela PNG com texto fino; mantenha os presets de captura de tela conservadores para que os leitores do ticket ainda consigam ler os rótulos.

O monitoramento de pastas no diretório de gravações significa que toda nova captura fica leve antes que alguém a anexe. Isso é especialmente útil durante semanas de regressão, quando toda a equipe está jogando arquivos MOV na mesma caixa de entrada.

Uma checklist de pré-voo para evidências úteis de bugs

A compactação não consegue salvar uma gravação desfocada. Antes de anexar o arquivo, verifique a própria evidência:

1. Comece em um estado reconhecível e mostre a ação exata que dispara o problema.
2. Corte login, configuração, tentativas e tempo ocioso, a menos que um deles faça parte do bug.
3. Mantenha o ponteiro visível e aumente a janela do aplicativo antes de gravar controles pequenos.
4. Passe o scrub pela cópia compactada em 100% e confirme que rótulos, texto do console e mensagens de erro permanecem legíveis.
5. Remova notificações não relacionadas, tokens, registros de clientes e abas do navegador.
6. Informe o ambiente, build, resultado esperado e resultado real no texto da issue; o vídeo deve apoiar o relatório, não substituí-lo.

Use H.264 MP4 quando a reprodução ampla em navegadores for importante. Um GIF é útil para um loop mudo muito curto, mas seu limitado conjunto de cores e compressão fraca o tornam uma escolha ruim como padrão para evidências mais longas. Preserve a gravação original até que a issue seja encerrada, caso um revisor precise de um frame mais nítido.

Os limites diferem o suficiente para que as equipes verifiquem o destino, em vez de memorizar um único número. O GitHub documenta uploads de vídeo de 10 MB em repositórios gratuitos e 100 MB em repositórios pagos , enquanto o Jira Cloud define 1 GB por arquivo como padrão e permite que administradores alterem o valor . O alvo prático ainda pode ser muito menor, porque os revisores precisam de reprodução rápida, não apenas de um upload bem-sucedido.

Quando o GetCompress se encaixa nos fluxos de bug report

Os controles de exportação de um gravador são suficientes para um clipe ocasional, e o rastreador de issues continua sendo o lugar para passos, ambiente e comportamento esperado. O GetCompress é a melhor opção quando desenvolvedores e QA preparam repetidamente evidências em MOV, MP4, WebM, capturas de tela e GIF para diferentes limites de rastreadores. Tamanho de vídeo alvo, presets reutilizáveis, filas em lote e monitoramento de pastas eliminam o trabalho de reexportação enquanto as capturas permanecem locais. Ele não substitui o gravador de tela, a issue ou o processo de redação aprovada.