video-to-deck

Que fait video-to-deck ?

Créez une présentation à partir d'une vidéo. Vous (le modèle) êtes uniquement textuel — vous ne pouvez pas entendre l'audio ni voir les images. Par conséquent, les scripts de cette compétence voient et entendent à votre place et vous remettent un dossier de preuves textuel (evidence.md). Votre tâche est uniquement la synthèse : lisez les preuves et rédigez un bon diaporama. N'inventez rien que les preuves ne soutiennent pas.

La sortie est Markdown Marp (deck.md) : un .md normal que vous pouvez lire maintenant, et un véritable diaporama (PPTX/PDF/HTML) via une commande render.sh ultérieure.

$SKILL ci-dessous = le répertoire de cette compétence (le dossier contenant ce fichier).

Procédure

1. Installation unique (idempotente)

bash "$SKILL/scripts/setup.sh"

Installe faster-whisper (transcription), tesseract (OCR) et — si npm est présent — marp-cli et mermaid-cli. Sécurisé à réexécuter. ffmpeg doit déjà être installé.

2. Trouver les vidéos

bash "$SKILL/scripts/find_videos.sh" "<dossier>"        # un chemin par ligne, récursif

Pour un fichier nommé unique, ignorez cette étape et utilisez le chemin directement.

3. Construire le dossier de preuves pour chaque vidéo (une à la fois)

bash "$SKILL/scripts/process_video.sh" "<vidéo>" "<rép_sortie>/<nom-vidéo>"

Ceci extrait l'audio → le transcrit, échantillonne les images clés → OCR sur le texte à l'écran, et écrit <rép_sortie>/<nom-vidéo>/evidence.md (ainsi que transcript.txt, segments.tsv, frames/, ocr.txt). Les longues vidéos sur CPU sont lentes ; définissez WHISPER_MODEL=small pour la qualité, ou utilisez un GPU CUDA pour la vitesse (détection automatique ; voir WHISPER_DEVICE dans scripts/transcribe.py). Traitez les vidéos séquentiellement, pas en parallèle.

Passage vision optionnel (Qwen-VL). L'OCR ne lit que le texte. Pour capturer également ce que le texte ne peut pas — graphiques et leur tendance, diagrammes, disposition de l'interface utilisateur, geste d'un orateur — activez un modèle de vision qui légende chaque image clé conservée. Il est désactivé par défaut ; activez-le en définissant VISION_MODEL (et, si nécessaire, VISION_ENDPOINT) dans l'environnement de la même commande :

VISION_MODEL=qwen2.5-vl \
VISION_ENDPOINT=http://127.0.0.1:8081/v1/chat/completions \
  bash "$SKILL/scripts/process_video.sh" "<vidéo>" "<rép_sortie>/<nom-vidéo>"

Lorsqu'il est activé, evidence.md gagne une section « ## Descriptions visuelles » en plus de l'OCR — utilisez-la pour les diapositives de graphiques/diagrammes. Tout point de terminaison de vision compatible OpenAI fonctionne (llama-swap avec un serveur local comme llama.cpp/llama-swap ou Ollama, ou une API hébergée ; VISION_API_KEY si un jeton est nécessaire). Si le point de terminaison est inaccessible, l'exécution se poursuit avec l'OCR uniquement — rien ne casse.

4. Rédiger le diaporama

Lisez l'intégralité du fichier evidence.md. Copiez "$SKILL/templates/deck.marp.md" vers <rép_sortie>/<nom-vidéo>/deck.md et remplissez-le. Règles :

• Conservez le frontmatter marp: true — c'est ce qui en fait un diaporama.
• Utilisez la transcription pour ce qui a été dit ; utilisez l'OCR / le texte à l'écran pour les étiquettes, nombres, titres et codes exacts affichés sur les diapositives ; si une section « Descriptions visuelles » est présente (le passage vision a été activé), utilisez-la pour les graphiques/diagrammes/UI que l'OCR ne peut pas transmettre.
• Marquez une affirmation avec son moment quand c'est utile : [00:04:12].
• Mettez l'image clé de la diapositive sur la diapositive — c'est la valeur PAR DÉFAUT, pas un ornement optionnel. Chaque bloc ### [intervalle] frames/kf_####.jpg dans ocr.txt nomme l'image clé représentative de cette diapositive ; portez-la sur la diapositive du diaporama dans laquelle elle est devenue : ![](frames/kf_0007.jpg). L'image clé est la preuve pour la diapositive, elle montre le diagramme/graphique/UI que les puces ne peuvent que décrire, et elle fait en sorte que le diaporama reflète la présentation source. Omettez-la uniquement lorsque la diapositive est une diapositive de diagramme pur que vous avez redessinée en Mermaid, ou lorsque l'image clé ne porte aucun signal visuel (un buste parlant, une transition vide). Lorsque deux diapositives du diaporama proviennent d'une seule diapositive source, utilisez deux images clés différentes de cette diapositive plutôt que d'en répéter une.
• Incluez uniquement ce que les preuves soutiennent. Si la transcription et l'OCR sont vides, dites que la vidéo n'avait pas de contenu extractible plutôt que d'inventer un diaporama.

Densité — le diaporama doit CONDENSER les preuves, pas les résumer. L'échec le plus courant est un diaporama mince : 20 diapositives avec des puces de quatre mots qui jettent la majeure partie de ce que la vidéo contenait réellement. Le dossier de preuves est coûteux à construire ; le diaporama est ce que les gens lisent.

• Une diapositive du diaporama par diapositive source. Chaque bloc ### [intervalle] frames/… dans la section OCR correspond à une véritable diapositive de la vidéo — cette liste est votre liste de contrôle et approximativement votre nombre de diapositives. Ne fusionnez pas trois diapositives sources en une seule puce. Une conférence de 40 minutes compte normalement 30 à 45 diapositives.
• Portez les détails sur la diapositive. Chaque nombre, métrique, seuil, pourcentage, nom de produit, CRD, clé de configuration et étiquette présents dans les preuves appartient à la diapositive elle-même. Si la diapositive source avait six puces et quatre statistiques, votre diapositive a six puces et quatre statistiques — pas « précision améliorée ».
• Les puces sont une ligne complète (~15-20 mots), pas quatre mots. 5 à 8 par diapositive est normal. Le laconisme n'est correct que lorsque la source était laconique.
• Utilisez un tableau chaque fois que la source est tabulaire — matrices de routage, grilles de benchmarks, définitions de niveaux, règles de priorité. Reproduisez chaque ligne et colonne, pas un échantillon.
• Les notes du présentateur sont additives, pour ce qui a été dit et qui n'est pas sur la diapositive : mises en garde, anecdotes, le « pourquoi », détails des questions-réponses. Elles ne sont pas l'endroit pour cacher du contenu qui appartient à la diapositive.
• Vérification de couverture avant de terminer. Parcourez les blocs ### [..] dans ocr.txt dans l'ordre et confirmez que chacun est représenté. Si vous avez sauté un bloc, soit c'était un doublon/animation de la diapositive précédente, soit une image de démonstration — soyez capable de dire lequel.

5. Passage diagramme (la vérification « est-ce que cela peut être un diagramme ? »)

Pour chaque sujet, demandez : est-ce structurel (composants + connexions, interactions entre acteurs, un processus/flux, états + transitions, entités + relations) ? Si oui, dessinez-le sous forme de diagramme Mermaid (par défaut) ou PlantUML sur sa propre diapositive au lieu de puces. Consultez "$SKILL/references/diagrams-cheatsheet.md" pour le tableau de décision contenu→type et les squelettes copier-coller. Ne forcez pas un diagramme lorsque le contenu est simplement narratif.

6. (Optionnel) Exporter le diaporama réel

bash "$SKILL/scripts/render.sh" "<rép_sortie>/<nom-vidéo>/deck.md" pptx   # ou pdf | html | all

Ceci pré-rend les blocs de diagrammes en images, puis produit le PPTX/PDF. Si marp/mermaid ne sont pas installés, le diaporama reste simplement en .md (toujours valide et consultable).

Pour un arbre entier en une fois, ajoutez --pdf au pilote par lots (ci-dessous) au lieu d'appeler render.sh pour chaque diaporama.

Par lots / dossiers imbriqués

Pour un dossier entier — en particulier un arborescence de cours imbriquée — préférez scripts/drive_decks.sh <racine> : il boucle en bash et génère un agent frais par vidéo (ne dépasse jamais le contexte du modèle) et reflète les sous-dossiers source dans la sortie, de sorte que la hiérarchie parent→enfant soit préservée. scripts/rename_by_topic.sh <diaporamas> transforme ensuite chaque feuille en slug par son thème dans son dossier de cours. Ajoutez --pdf pour exporter chaque diaporama en PDF une fois la rédaction terminée — Mermaid est pré-rendu en images, et le dossier feuille est réduit de sorte que chaque PDF atterrisse dans son parent (<out>/CoursA/lecon/deck.md → <out>/CoursA/lecon.pdf), évitant un sous-dossier par PDF. Pour reconstruire la hiérarchie des diaporamas qui ont été produits à plat par une exécution plus ancienne, utilisez scripts/regroup_by_source.sh <diaporamas> — il lit la ligne Source: de chaque evidence.md pour placer chaque diaporama sous son parent de cours (les doublons sont mis en quarantaine dans _duplicates/), puis exécutez le renommage. Voir README.md pour le guide complet par lots.

Références

• references/marp-cheatsheet.md — Syntaxe des diapositives Marp (séparateurs, images, notes, colonnes).
• references/diagrams-cheatsheet.md — Quand dessiner un diagramme et la syntaxe pour chaque type.

Remarques

• L'OCR capture bien le texte à l'écran pour les screencasts / vidéos de diapositives. Pour les séquences en prise de vue réelle, la transcription porte la majeure partie du signal — appuyez-vous dessus et ne faites pas de déclarations excessives sur les visuels.
• La transcription, l'OCR et le rendu sont toujours locaux. La question de savoir si l'étape de rédaction quitte la machine dépend entièrement de l'agent vers lequel vous pointez --agent-cmd.
• La conception est indépendante du modèle : tout agent textuel capable d'exécuter bash et de lire des fichiers peut utiliser cette compétence.