video-check

Verificação de vídeo: encontre o que está errado em uma renderização antes de qualquer outra pessoa

Esta é a versão video-check 0.2.3.

A pessoa recebe um vídeo que foi verificado como um editor profissional verifica uma exportação, e um breve REVIEW.md que diz o que foi medido, o que foi analisado, o que foi corrigido e o que ninguém verificou.

Três coisas são verdadeiras durante todo o processo:

• Meça primeiro, depois olhe. Um modelo analisando quadros perde trechos mortos e glitches de um quadro; o FFmpeg não. Execute check.py antes de olhar, e nunca pule porque o vídeo "parecia bom".
• Quem fez o vídeo é o pior revisor. Você sabe o que cada cena deveria mostrar, então vê o planejamento em vez da imagem. Peça a alguém sem o seu planejamento para olhar as folhas (passo 3).
• Você não pode ouvir. O script mede intensidade, picos e silêncios. Se a música se encaixa, se um som é o som certo e se a fala é clara, deve ser ouvido por uma pessoa. Diga isso todas as vezes.

Quando as entradas estão faltando

Você precisa do arquivo renderizado nesta máquina. Se a pessoa apenas descrever um vídeo, ou fornecer um link para uma plataforma, peça o arquivo; não faça download do TikTok, YouTube ou Instagram. Se você fez o vídeo, você também conhece o planejamento: tamanho, taxa de quadros, duração, alvo de intensidade e quais trechos parados e flashs são intencionais. Se a pessoa trouxer sua própria edição, pergunte para que serve (plataforma, duração) e use os padrões abaixo para o resto.

Fluxo de trabalho

1. Meça. Informe o que foi planejado, para que o script possa distinguir uma falha de uma escolha:

   python scripts/check.py final.mp4 --out work/check1 --loudness -14
   

   Quando você fez o vídeo, ou a pessoa informou o planejamento, adicione-o: por exemplo --expect 1080x1920 --fps 30 --duration 32 --holds 28.5-32 --flashes 12.4. Nunca adivinhe tamanho, taxa de quadros ou duração a partir da plataforma: um arquivo 960x540 que ninguém pediu para ser 1080p não é uma falha de tamanho, então deixe --expect de fora quando ninguém planejou. --holds lista trechos parados intencionais (um cartão final, um título mantido parado); --flashes lista flashes de um quadro e mergulhos planejados; --loop para uma peça feita para loop; --audio none para uma peça silenciosa. O vídeo online é normalizado para cerca de -14 LUFS; use -16 para podcasts e -23 para transmissão. Ele imprime resultados como P0/P1/P2 t=… código: o que -> correção e escreve check.json, overview_NN.png e findings.png. references/reading-the-checks.md diz o que cada verificação detecta e o que perde.

2. Corrija os P0s agora. Tamanho errado, taxa de quadros errada, duração errada, sem áudio quando deveria ter, clipping: estes são erros de renderização, não de gosto. Corrija o comando, renderize novamente e execute novamente o passo 1 antes de alguém olhar. Para intensidade, clipping e pico verdadeiro, corrija a mixagem na edição se você a tiver (abaixe a música, o som mais alto). Se você tiver apenas o arquivo finalizado, execute python scripts/fix_sound.py in.mp4 out.mp4 --loudness -14: ele limita os picos, normaliza em duas passagens e copia a imagem intocada, chegando a 0.2 LU do alvo e abaixo de -1.5 dBTP. loudnorm de passagem única perde seu alvo de pico e um limitador simples deixa a mixagem baixa; não ajuste filtros manualmente rodada após rodada.

3. Olhe, com olhos novos. Abra cada folha de visão geral e findings.png com a ferramenta Read. Em seguida, obtenha uma segunda opinião de alguém que não viu seu planejamento:

   • Se você puder iniciar um subagente, forneça a ele apenas as folhas, a plataforma e uma frase sobre para que serve o vídeo. Não seu planejamento, não seu código, não suas intenções. Use o resumo em references/review-guide.md.
   • Se não puder, olhe você mesmo, mas cubra o planejamento: descreva cada folha como um estranho faria, uma frase por quadro, antes de julgá-la. Escreva "um contexto" em REVIEW.md.

   Cada problema é escrito como t=12.4s · onde na tela · o que está errado → a mudança exata, com P0 (quebrado ou ilegível), P1 (um espectador notará) ou P2 (polimento). Sem notas de zero a dez: uma nota não encontra nada para corrigir. Verifique a lista em references/review-guide.md, que contém as coisas que fazem uma edição parecer feita por um template ou uma máquina: barras de progresso tipo slide e contadores de etapas, cada linha entrando da mesma forma, texto abaixo dos botões da plataforma, um primeiro quadro vazio, números que ninguém forneceu.

4. Corrija os três piores e verifique novamente. Pegue os P0s e os três piores P1s. Para cada um, altere a lista de edição ou o comando, não o arquivo renderizado. Se a correção for um método que você não conhece, search_techniques pelo resultado que você deseja (por exemplo "duck music under speech", "fade audio at a cut") e get_technique seu prompt. Renderize e execute novamente o passo 1 com --before work/check1/check.json --out work/check2; ele lista o que foi corrigido, o que ainda está lá e o que é novo, e desenha before_after.png. Olhe os quadros que você alterou.

5. Pare após três rodadas. Se a terceira rodada ainda tiver um P0 ou precisar de grandes mudanças, pare e informe a pessoa sobre o que resta e por que, em vez de continuar em loop. Problemas que precisam de decisão dela (uma música diferente, um take que não existe) vão para ela como perguntas.

Entregue

Primeiro, uma verificação de versão. Se o MCP do EditAtlas estiver conectado, chame get_skill sem um nome. Se ele listar video-check acima de 0.2.3, a primeira linha da sua resposta diz que uma versão mais recente existe e como atualizá-la (no Claude Code: /plugin, depois Marketplaces, editatlas-skills, Update marketplace; em outros lugares get_skill com o nome video-check fornece o passo). Sem o MCP, pule.

Escreva REVIEW.md ao lado do vídeo, no idioma da pessoa, com o modelo em references/review-guide.md:

• o veredito em uma linha: pronto (nada resta), pronto com observações (as observações nomeiam cada achado ainda presente, e cada P1 restante precisa de algo que você não tem, como o projeto de edição), ou não pronto (um P0 ainda está lá, ou um P1 que você poderia corrigir);
• o que o script mediu (tamanho, taxa de quadros, duração, intensidade, pico verdadeiro, cortes por minuto) e os achados corrigidos em cada rodada;
• cada achado restante com seus tempos e seu padrão conforme check.py os escreveu (por exemplo "um a cada 12 quadros a partir de 0,4 s; a cada 2-6 quadros de 11,7 a 14,9 s"), não apenas uma contagem;
• o que o revisor viu, e se foi um revisor separado ou um contexto;
• o que ainda precisa de uma pessoa: ouvir a mixagem e a escolha musical, ortografia e nomes na tela, sincronia labial, cor em um celular real, e qualquer coisa que você não pôde corrigir. Mantenha a frase de que ninguém ouviu o som, em palavras simples e apenas no idioma da pessoa.

Mostre à pessoa before_after.png da última rodada. Nunca escreva que o vídeo "não tem erros": escreva o que foi verificado.

Referências

• references/reading-the-checks.md: cada medição, seus limites, o que detecta e perde, e os resultados em vídeos conhecidos. Leia quando um achado parecer errado ou antes de definir --holds.
• references/review-guide.md: o resumo para o revisor, a lista de sinais, o formato do problema e o modelo de REVIEW.md. Leia no passo 3.