anthonytrance/editor-de-video

Editor de vídeo

Transforma uma pasta de clipes em um vídeo curto finalizado. O agente é o editor: decide a história e escreve o plano de edição, e os scripts executam as partes mecânicas com precisão, garantindo que os cortes caiam na batida, nada se repita acidentalmente e nada fique com letterbox.

Leia LOCAL.md primeiro, se existir: ele contém o Python desta máquina, o arquivo de marca e as pastas de mídia. O proprietário, fontes da marca, logotipos e visual padrão ficam em um arquivo de marca (~/.video-editor/brand.json, veja references/brand.md), nunca nos scripts.

Clipes únicos que precisam apenas de corte ou recorte simples, legendas em um clipe e publicação pertencem à skill social da instalação (para XNP: xnp-social). Esta skill faz a edição; aquela skill revisa, legenda, planeja e publica.

Não há lista de tipos de vídeo

Toda solicitação é uma mistura. Não procure por um modelo correspondente. Em vez disso, decida quatro coisas a partir do briefing, por seção, se o vídeo mudar de caráter no meio:

1. A espinha: o que define o ritmo. Música: cortes em barras e batidas, cenas escolhidas pela energia, o drop é o pico (len em "2bar", "1beat"). Fala: as palavras determinam a duração, a imagem corta no final das frases, a música faz duck sob a voz (audio_db no plano de fala, durações em segundos). História ou cronologia: chegada, construção, momento, rescaldo; corta por ação e mudança de lugar, a música é um fundo. Um híbrido troca de espinha por seção: uma saudação de 6 segundos cortada pela fala, depois cenas de show na batida; ou uma história de viagem cronológica com montagem na batida durante o show.
2. Destino e design. Onde vai (Reel, Story, carrossel, feed, TikTok, Shorts, YouTube) e como usar aquele espaço: full bleed, um quadrado emoldurado ou imagem 4:5 sobre um fundo desenhado, ou ambos alternando por cena. Escolha a partir do material e do propósito, não por hábito; um momento widescreen que um corte 9:16 prejudicaria pode pedir um Reel emoldurado, um carrossel ou um resumo 16:9. Leia references/formats.md para saber o que cada plataforma faz com a imagem e quando cada design se encaixa. A duração segue o destino e o material.
3. Obrigatoriedades. Pessoas mencionadas que devem aparecer e ser reconhecíveis, um logotipo, uma data, um agradecimento, um momento específico, uma linha de legenda. Pergunte apenas se o briefing realmente deixar uma em aberto.
4. Camadas de áudio. Somente música; música com plateia ou ambiente aparecendo; fala com música por baixo; somente fala. Fala recebe legendas (veja Legendas abaixo).

Depois, escreva o plano, com "destination" definida para que o canvas, a área segura e o limite de duração sejam aplicados. references/examples.md mostra quatro briefings trabalhados (reel de afterparty, saudação, saudação com cenas de show, história de viagem) como raciocínio, não como tipos a copiar. references/craft.md contém as regras de edição que se aplicam a todos.

Fluxo de Trabalho

Os scripts estão em scripts/; execute-os com o Python de LOCAL.md, PYTHONUTF8=1 PYTHONIOENCODING=utf-8, FFmpeg e ffprobe no PATH. Trabalhe em uma pasta de projeto fora da skill (src/, audio/, log/, proxy/, out/, review/, edit.json).

1. Briefing. Quem e o que está no material, como reconhecer cada pessoa, o evento, o propósito, as quatro decisões acima. Escreva em brief.txt; o Gemini lê.
2. Registrar o material. gemini.py log WORKDIR src/*.mp4 --context brief.txt --ratio 9:16 escreve log/NOME.json por clipe: momentos com quem está onde (x como fração para corte), ação, emoção, energia, som, fala, qualidade, se uma janela 9:16 segura os sujeitos, o melhor centro de corte e um uso (abertura, pico, reação...). Cerca de um centavo de dólar por clipe. Os logs são pistas: confirme rostos, centros de corte e "melhores momentos" em frames antes de construir sobre eles.
3. Olhar. sheet.py faz folhas de contato rotuladas em uma só execução do FFmpeg: --every 2 por um clipe, --times, comparação de candidatos com a.mp4@3 [email protected], --crop 9:16 --cx 0.4 para ver uma fonte como será enquadrada, --grid 10 para planejamento de corte. Leia a imagem você mesmo; nunca peça ao proprietário para olhar.
4. Plano. Escreva edit.json (references/edit-format.md). Cada plano nomeia um momento diferente; dê a cada um uma nota dizendo por que está ali.
5. Verificar. validate.py edit.json (render.py também executa e recusa em erros). Erros: o mesmo material usado duas vezes, fonte muito curta, movimento desconhecido, fit bloqueado sem permissão, texto nas zonas de interface da plataforma, arquivos faltando, música muito curta. Avisos: planos do mesmo clipe com menos de 2s de diferença, planos parecidos, cortes fora da batida, bordas pretas dentro da fonte emoldurada, logotipos perto das zonas de interface. Leia cada aviso e decida; não apenas silencie.
6. Renderização de rascunho. render.py edit.json --out out/v1-draft.mp4 --draft (metade do tamanho, rápido). Depois sheet.py out/v1-draft.mp4 --plan edit.json --out review/v1.png mostra o início, meio e fim de cada plano: verifique enquadramento, cabeças, posicionamento de texto e se cada plano é o que a nota diz.
7. Renderização completa. render.py edit.json --out out/v1.mp4. Predefinição lenta, cerca de 5 minutos para 30 segundos de fontes 4K; render.py então verifica tamanho, duração, som, barras pretas por plano, frames pretos e o max_mb do plano.
8. Crítica. gemini.py review out/v1.mp4 --context brief.txt --plan edit.json --out review/v1.json (menos de um centavo). Trate cada nota como uma alegação: verifique-a contra frames ou o plano antes de mudar algo. Já chamou texto correto de "inseguro" e uma data correta de "erro de digitação". Suas capturas reais foram planos com aparência repetida, uma mão bloqueando um gesto-chave, um telefone no quadro, um flash que parecia uma falha.
9. Itere com novos números de versão; nunca sobrescreva um arquivo entregue. Mantenha edit.json por versão (copie para edit-v2.json) para que qualquer versão possa ser re-renderizada.
10. Entregue da forma que LOCAL.md diz, descreva o que está na edição em palavras (plano por plano, o que o texto diz, onde a música atinge o pico) e passe o arquivo para a skill social revisar, legendar e publicar. Publicação sempre precisa da aprovação explícita do proprietário.

Legendas

Legendas de fala são trabalho da skill social: renderize a edição primeiro, depois execute o auxiliar de legendas (para XNP: xnp-social/scripts/captions.py transcribe na renderização final, para que os tempos das palavras coincidam com a edição), siga sua etapa de aprovação obrigatória, depois queime. Se um arquivo .srt ou .ass aprovado já existir para a linha do tempo final, o captions.file do plano queima durante a renderização.

Limites honestos

A verificação de planos parecidos é um hash de imagem mais cor média: pega o mesmo momento duas vezes, não "a mesma pessoa do mesmo ângulo" em momentos diferentes. Essa verificação semântica vem dos logs e revisão do Gemini e da leitura da folha de contato. Não há detecção automática de batida: forneça o BPM e um ponto de início em uma batida forte (music.start), então a grade é exata. Não há rastreamento facial: panorâmicas e centros de corte vêm dos logs e folhas. Os timecodes do Gemini podem variar em clipes longos; os proxies carregam um timecode queimado para mantê-los honestos, e log avisa quando momentos ultrapassam o clipe.

Arquivos

scripts/common.py carregador de plano, matemática de tempo, sonda, marca, correção de cor. scripts/render.py o renderizador de uma passada. scripts/validate.py o verificador. scripts/sheet.py folhas de contato. scripts/gemini.py registro e revisão. Referências: formats.md, edit-format.md, craft.md, examples.md, brand.md.