I Recorded 50 Hours of Screen Content with 8 Different Tools

# Eu Gravei 50 Horas de Conteúdo de Tela com 8 Ferramentas Diferentes

50 horas gravadas, 8 ferramentas testadas, 3 sistemas operacionais. Os tamanhos de arquivo variaram de 2GB a 47GB para conteúdo idêntico. O uso da CPU variou de 3% a 40%.

Esses números dizem tudo sobre por que o software de gravação de tela é mais importante do que a maioria dos criadores percebe. Tenho produzido tutoriais técnicos há seis anos, e só no mês passado capturei 53 horas de conteúdo de tela em três máquinas diferentes. Quando uma gravação corrompe na marca de 90 minutos, você não apenas perde a filmagem—você perde o estado mental, a explicação perfeita, a clareza espontânea que tornava aquela gravação especial.

Isso não é uma análise onde testei cada ferramenta por vinte minutos. Eu convivi com esses aplicativos através de falhas de kernel, atualizações do Windows que redefiniram configurações de áudio, e migrações de servidores de exibição do Linux. Gravei gameplay em 4K, sessões de terminal com saída rápida de texto e fluxos de trabalho de múltiplos monitores onde uma tela exibe código enquanto outra mostra documentação. Cada ferramenta me decepcionou de maneiras diferentes, e algumas nunca falharam.

Contexto: Por Que Estou Gravando Tanto Conteúdo

Minha jornada de trabalho gira em torno da criação de tutoriais para desenvolvedores em três plataformas diferentes. Um cliente quer conteúdo específico para Windows mostrando fluxos de trabalho do Visual Studio. Outro precisa de tutoriais de linha de comando multiplataforma que funcionem de forma idêntica no Mac e Linux. O terceiro publica conteúdo relacionado ao desenvolvimento de jogos que requer captura em alta taxa de quadros do Unity e Unreal Engine.

Isso significa que não estou apenas gravando—estou gravando sob restrições. Um tutorial de 30 minutos pode exigir 90 minutos de filmagem bruta após contabilizar erros, reexplicações e várias tentativas de sequências complexas. Eu preciso capturar áudio do sistema, entrada do microfone, e às vezes ambos simultaneamente. Eu preciso que a gravação sobreviva se meu gato andar pelo teclado ou se o Windows decidir instalar atualizações.

Os requisitos técnicos rapidamente se tornam específicos. Quando estou gravando sessões de terminal, preciso que cada caractere esteja visível—sem artefatos de compressão transformando `rm -rf` em `rm -r#`. Quando estou capturando visualizações de mecanismos de jogos, preciso de no mínimo 60fps ou o movimento parecerá instável na edição final. Quando estou mostrando ferramentas baseadas em navegador, preciso que o cursor apareça nítido, não como uma mancha borrada que torna confuso qual botão estou clicando.

Comecei a acompanhar métricas detalhadas há seis meses após uma falha catastrófica de gravação. Eu passei duas horas capturando um tutorial complexo de rede Docker, explicando configurações de sub-rede e padrões de comunicação entre contêineres. A gravação parecia bem-sucedida—o software mostrava um arquivo de 47GB. Quando o abri no meu editor, o vídeo estava corrompido além da recuperação. Cada quadro após a marca de 73 minutos era de pixels verdes.

Essa falha me custou um prazo e me ensinou que "funcionou antes" não é uma metodologia de teste. Eu precisava de dados sobre quais ferramentas realmente sobreviveram a padrões de uso do mundo real, não apenas quais tinham as melhores descrições de marketing.

O Dia em Que Três Ferramentas Falharam Simultaneamente

14 de fevereiro. Eu me lembro da data porque estava tentando terminar um projeto de Dia dos Namorados para meu parceiro enquanto também atendia a um prazo de cliente. Tinha três gravações de tela diferentes rodando em três máquinas—um desktop Windows capturando imagens de jogos, um MacBook Pro gravando um fluxo de trabalho de design, e uma estação de trabalho Linux mostrando configuração de servidor.

Todas as três gravações deveriam rodar por cerca de 45 minutos. Já havia feito isso antes sem problemas, usando ferramentas em que confiava há meses. Iniciei as três gravações, comecei minhas apresentações, e entrei no estado focado onde o bom conteúdo de tutoriais acontece.

A máquina Windows falhou primeiro. Eu estava a 31 minutos explicando otimização de texturas no Unity quando o software de gravação travou. Sem aviso, sem mensagem de erro—simplesmente desapareceu. O aplicativo sumiu da minha barra de tarefas. Quando o reabri, não havia arquivo de recuperação, sem salvamento automático, nada. 31 minutos de explicação detalhada sobre compressão de mapas normais e geração de mipmaps, perdidos.

Eu ainda não sabia sobre a falha do Windows porque estava focado na gravação do Mac. Essa chegou a 38 minutos antes que a bola de praia aparecesse. O software de gravação congelou. O cronômetro parou de atualizar. Eu ainda conseguia mover o mouse e trocar de aplicativos, mas a ferramenta de gravação estava totalmente travada. Eu forcei o fechamento. O arquivo resultante estava corrompido—ele reproduzia os primeiros 12 minutos, depois pulava para um quadro congelado que durou o restante da gravação.

A gravação do Linux realmente foi concluída. Termine meu tutorial de 47 minutos sobre configuração de servidor, parei a gravação, e o software relatou sucesso. O tamanho do arquivo parecia correto, com 8.3GB. Copiei para meu NAS para backup. Quando o abri naquela noite para começar a editar, descobri que o áudio estava completamente desincronizado. Começou bem, mas na marca de 20 minutos, minha voz descrevia coisas que não apareceriam na tela por mais 8 segundos. No final, a desincronização ultrapassava 15 segundos.

Três gravações, três modos de falha diferentes, três ferramentas diferentes. Esse foi o dia em que parei de confiar em qualquer solução única e comecei este projeto de teste sistemático.

Dados de Performance: Os Números Que Importam

Gravei o mesmo segmento de tutorial de 30 minutos oito vezes, uma vez com cada ferramenta, em hardware idêntico. O conteúdo era um tutorial de web scraping em Python—muitos saídas de terminal, interação com o navegador e edição de código. Aqui estão as medições que fiz:

A variação no tamanho do arquivo é absurda. O arquivo de 47.3GB do Camtasia continha informações visuais idênticas ao arquivo de 2.1GB do Windows Game Bar. Ambos estavam em 1080p a 30fps. Ambos capturaram os mesmos 30 minutos de conteúdo. A diferença? O Camtasia estava gravando em um formato não comprimido projetado para edição, enquanto o Game Bar estava utilizando codificação H.264 acelerada por hardware.

O uso da CPU conta uma história diferente. O uso de 40% da CPU do Kazam em um processador de 6 núcleos significava que ele estava consumindo mais de dois núcleos inteiros apenas para gravar. Durante essa gravação, eu podia ouvir os ventiladores do meu laptop acelerando. O sistema parecia lento. Quando tentei compilar código enquanto gravava, a compilação levou 3x mais tempo do que o normal.

O uso de 3% da CPU do Windows Game Bar é o resultado da codificação por hardware. O codificador de vídeo dedicado da GPU lida com a compressão, liberando a CPU para outras tarefas. Gravei esse mesmo tutorial enquanto rodava uma construção de contêiner Docker em segundo plano— a gravação foi perfeita, e a construção foi concluída no tempo normal.

Quadros perdidos são o assassino silencioso. Os 3 quadros perdidos do ShareX podem não parecer significativos, mas essas quedas ocorreram durante a saída rápida do terminal quando eu estava demonstrando um script que imprimia centenas de linhas. Os quadros perdidos fizeram o texto parecer pular, pulando várias linhas de uma vez. No vídeo final, os espectadores não conseguiram ler a saída claramente.

Os 127 quadros perdidos do Kazam tornaram a gravação inutilizável. O vídeo gaguejou constantemente. Os movimentos do mouse não eram suaves. As transições de janelas pareciam bruscas. Isso não foi uma falha ocasional— eu testei o Kazam três vezes, e ele perdeu quadros todas as vezes.

Insights: O Que os Dados Não Mostram

"A melhor ferramenta de gravação é aquela que desaparece. Você deve esquecer que está gravando em 30 segundos após começar."

Esse é o insight que mudou a forma como eu avalio software de gravação de tela. Os números naquela tabela importam, mas não capturam a carga cognitiva de usar cada ferramenta.

O OBS Studio tem a interface mais complexa. Existem cenas, fontes, filtros e misturadores de áudio. Na primeira vez que você o abre, você é confrontado com uma tela em branco.