video-check

Revisión de video: encuentra lo que está mal en un renderizado antes que nadie

Esta es video-check 0.2.3.

La persona recibe un video que ha sido revisado como un editor profesional revisa una exportación, y un breve REVIEW.md que dice qué se midió, qué se miró, qué se corrigió y qué nadie revisó.

Tres cosas son ciertas durante todo el proceso:

• Mide primero, luego mira. Un modelo mirando fotogramas pasa por alto tramos muertos y glitches de un fotograma; FFmpeg no. Ejecuta check.py antes de mirar, y nunca lo saltes porque el video "se veía bien".
• La persona que lo hizo es el peor revisor. Sabes lo que se suponía que mostraba cada toma, así que ves el plan en lugar de la imagen. Haz que alguien sin tu plan mire las hojas (paso 3).
• No puedes oír. El script mide el volumen, los picos y los silencios. Si la música encaja, si un sonido es el correcto y si el habla es clara debe ser escuchado por una persona. Dilo cada vez.

Cuando faltan las entradas

Necesitas el archivo renderizado en esta máquina. Si la persona solo describe un video, o da un enlace a una plataforma, pídele el archivo; no descargues de TikTok, YouTube o Instagram. Si hiciste el video, también conoces el plan: tamaño, fotogramas por segundo, duración, objetivo de volumen y qué tramos congelados y destellos son intencionados. Si la persona trae su propia edición, pregunta para qué es (plataforma, duración) y usa los valores por defecto siguientes para el resto.

Flujo de trabajo

1. Mide. Pasa lo que se planeó, para que el script pueda distinguir un fallo de una elección:

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

   Cuando hiciste el video, o la persona te dijo el plan, agrégalo: por ejemplo --expect 1080x1920 --fps 30 --duration 32 --holds 28.5-32 --flashes 12.4. Nunca adivines el tamaño, la velocidad de fotogramas ni la duración a partir de la plataforma: un archivo de 960x540 que nadie pidió que fuera 1080p no es un fallo de tamaño, así que omite --expect cuando nadie lo planeó. --holds enumera tramos congelados intencionados (una tarjeta final, un título mantenido fijo); --flashes enumera destellos y caídas de un fotograma planificados; --loop para una pieza hecha para bucle; --audio none para una pieza silenciosa. El video en línea se normaliza a aproximadamente -14 LUFS; usa -16 para podcasts y -23 para transmisión. Imprime hallazgos como P0/P1/P2 t=… código: qué -> corrección y escribe check.json, overview_NN.png y findings.png. references/reading-the-checks.md dice qué captura cada verificación y qué omite.

2. Corrige los P0 ahora. Tamaño incorrecto, velocidad de fotogramas incorrecta, duración incorrecta, sin audio cuando debería haberlo, saturación: estos son errores de renderizado, no de gusto. Corrige el comando, renderiza de nuevo y vuelve a ejecutar el paso 1 antes de que nadie mire. Para el volumen, la saturación y el pico verdadero, corrige la mezcla en la edición si la tienes (baja la música, el sonido más fuerte). Si solo tienes el archivo terminado, ejecuta python scripts/fix_sound.py in.mp4 out.mp4 --loudness -14: limita los picos, normaliza en dos pasos y copia la imagen sin cambios, llegando a menos de 0.2 LU del objetivo y por debajo de -1.5 dBTP. loudnorm de un solo paso falla su objetivo de pico y un limitador simple deja la mezcla baja; no ajustes filtros manualmente ronda tras ronda.

3. Mira, con ojos nuevos. Abre cada hoja de vista general y findings.png con la herramienta Read. Luego obtén una segunda mirada de alguien que no haya visto tu plan:

   • Si puedes iniciar un subagente, dale solo las hojas, la plataforma y una oración sobre para qué es el video. No tu plan, no tu código, no tus intenciones. Usa el resumen en references/review-guide.md.
   • Si no puedes, mira tú mismo, pero oculta el plan: describe cada hoja como lo haría un desconocido, una oración por fotograma, antes de juzgarlo. Escribe "un contexto" en REVIEW.md.

   Cada problema se escribe como t=12.4s · dónde en la pantalla · qué está mal → el cambio exacto, con P0 (roto o ilegible), P1 (un espectador lo notará) o P2 (pulido). Sin puntuaciones sobre diez: una puntuación no encuentra nada que arreglar. Revisa la lista en references/review-guide.md, que contiene las cosas que hacen que una edición parezca hecha por una plantilla o una máquina: barras de progreso tipo diapositiva y contadores de pasos, cada línea entrando de la misma manera, texto debajo de los botones de la plataforma, un primer fotograma vacío, números que nadie te dio.

4. Corrige los tres peores, luego revisa otra vez. Toma los P0 y los tres peores P1. Para cada uno, cambia la lista de edición o el comando, no el archivo renderizado. Si la corrección es un método que no conoces, search_techniques el resultado que deseas (por ejemplo "bajar música bajo el habla", "desvanecer audio en un corte") y get_technique su indicación. Renderiza, luego vuelve a ejecutar el paso 1 con --before work/check1/check.json --out work/check2; enumera lo que se corrigió, lo que todavía está y lo que es nuevo, y dibuja before_after.png. Mira los fotogramas que cambiaste.

5. Detente después de tres rondas. Si la ronda tres todavía tiene un P0 o necesita cambios grandes, detente y dile a la persona qué queda y por qué, en lugar de hacer un bucle. Los problemas que necesitan su decisión (una canción diferente, una toma que no existe) van a ellos como preguntas.

Entrega

Primero, una verificación de versión. Si el MCP de EditAtlas está conectado, llama a get_skill sin nombre. Si enumera video-check por encima de 0.2.3, la primera línea de tu respuesta dice que existe una versión más nueva y cómo actualizarla (en Claude Code: /plugin, luego Marketplaces, editatlas-skills, Update marketplace; sin el MCP, salta esto.

Escribe REVIEW.md junto al video, en el idioma de la persona, con la plantilla en references/review-guide.md:

• el veredicto en una línea: listo (no queda nada), listo con notas (las notas nombran cada hallazgo que todavía está, y cada P1 restante necesita algo que no tienes, como el proyecto de edición), o no listo (todavía hay un P0, o un P1 que podrías arreglar);
• qué midió el script (tamaño, fotogramas por segundo, duración, volumen, pico verdadero, cortes por minuto) y los hallazgos corregidos en cada ronda;
• cada hallazgo que queda en su lugar con sus tiempos y su patrón tal como check.py los escribió (por ejemplo "uno cada 12 fotogramas desde 0.4 s; cada 2-6 fotogramas desde 11.7 hasta 14.9 s"), no solo un recuento;
• qué vio el revisor, y si fue un revisor separado o un contexto;
• qué todavía necesita a una persona: escuchar la mezcla y la elección de música, la ortografía y los nombres en pantalla, la sincronización de labios, el color en un teléfono real, y cualquier cosa que no pudiste arreglar. Mantén la frase de que nadie escuchó el sonido, en palabras simples y solo en el idioma de la persona.

Muéstrale a la persona before_after.png de la última ronda. Nunca escribas que el video "no tiene errores": escribe qué se revisó.

Referencias

• references/reading-the-checks.md: cada medición, sus umbrales, qué captura y omite, y los resultados en videos conocidos. Léelo cuando un hallazgo parezca incorrecto o antes de establecer --holds.
• references/review-guide.md: el resumen para el revisor, la lista de indicios, el formato de problema y la plantilla REVIEW.md. Léelo en el paso 3.